Woops! Looks like the admin here at freeshell recently made some changes that took our site down. Things have been restored now.
Seems that spammers wanting to sell you all pills and take your money at online blackjack have taken hold in my comments and trackbacks here. I've had to disable them both as I'm currently too busy at my job to code up a solution for this abuse. You people make me sick, you know that?
I just tried out a Sanyo 8200 last night with my Linux laptop and confirmed that it, like the Sanyo 4900 and friends, works great for data access under Linux using Sprint's PCS Vision service.
Or: Stopping Windows from freaking out ancient or non-standard serial peripherals...
Recently, I ran into a problem where an XP box, during bootup, was freaking out a peripheral attached to the box via a COM port. I won't get into the details of why the device is so sensitive, but I'll simply say that the usual RS232 flow control lines were not used for flow control, but instead to do some very delicate operations. During bootup, XP was pulsing the DTR and RTS lines, perhaps looking for a serial mouse or modem or to do something else. We didn't know why or how to make it stop. This short article describes the cause and how to fix it.
My first thought was that XP was looking for a serial mouse. That seems to be a common problem with old serial devices attached to an XP and 2000 boxen, especially where those devices are continuously outputting data. XP often detects them as serial mice incorrectly. However, no such device showed up in the device manager and we didn't notice any weirdness associated with the mouse, which I would have expected if XP was interpreting random incoming data as a serial mouse—the mouse should be jumping around on the screen or acting weird. But it wasn't.
Serial mice in NT/2000/XP can be detected by the NTDETECT.COM program, run by the NTLDR (NT Loader) before the kernel has taken control. In NT4, this could be disabled by passing the /NOSERIALMICE flag in boot.ini, and in 2000/XP by the /FASTDETECT flag.
/fastdetect:comnumber
This switch turns off serial and bus mouse detection in the Ntdetect.com file for the specified port. Use this switch if you have a component other than a mouse that is attached to a serial port during the startup process. For example, type /fastdetect:comnumber, where number is the number of the serial port. Ports may be separated with commas to turn off more than one port. If you use /fastdetect, and you do not specify a communications port, serial mouse detection is turned off on all communications ports.Note In earlier versions of Windows, including Windows NT 4.0, this switch was named /noserialmice.
On this XP box, by default, we always passed in /FASTDETECT in boot.ini, so this wasn't the problem. Something else had to be causing the behavior I was seeing.
The only other method I could find to possibly stop Windows from probing devices on this serial port was to monkey with the Serenum service. Apparently in 2000/XP, code was added to check a registry value called SkipEnumerations in a specific key on a per-port basis. Setting this value would keep Windows from probing devices on this COM port.
Additional Features in Serenum.sys
Windows supports a variety of multiport serial adapters through third-party drivers from manufacturers. In the case of high-capacity adapters (16 ports or more), boot time can be delayed on Windows 2000 when Serenum.sys scans each port for attached devices. To improve the boot time and the related user experience, expanded control over the serial port scanning has been added to Serenum.sys in Windows XP. These options can be controlled by a new REG_DWORD registry value, SkipEnumerations, as described in this article.
Serenum Features in Windows XP
>Windows XP addresses issues with the Serenum driver and reduces the boot time required to start machines, even with high-capacity adapters (16 ports or more) attached. An additional registry key is also defined in Windows XP, allowing hardware vendors to control Serenum.sys, forcing it to skip port scanning during system startup. This feature is achieved by setting the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\%Enumerator%\%Device_ID%\%Instance_ID%\Device Parameters\SkipEnumerationsThe use of SkipEnumerations in the Device Parameters key must be used on a per-port basis. There is no global option to change the behavior of all ports at once.
The REG_DWORD value name, SkipEnumerations, can contain the following data:Zero or non-existent: Default Serenum behavior; each port will be scanned during every system boot.
For example: SkipEnumerations\REG_DWORD\0x00000000 (0)0xffffffff: Serenum will never scan the ports, either automatically or through user-initiated scans in Device Manager or Hardware Wizard. Any device attached to a port with this value in the registry will need to be installed manually.
For example: SkipEnumerations\REG_DWORD\0xffffffff (4294967295)If any other value is used, Serenum will skip that number of scans (boots or user-initiated). The successive scan will behave normally (similar to the setting of zero). Once the value goes to zero, it will stay at zero until Serenum.sys is unloaded and reloaded. At this point, it will be reset to the original registry value.
For example: SkipEnumerations\REG_DWORD\0x00000003 (3)In this example, the data value is set to 3. Serenum will skip 3 scans. After the 3 scans, it will perform a normal scan.
The Windows XP version of Serenum.sys has been enhanced to automatically speed up the boot process when high-capacity multiport serial adapters are installed. With the addition of SkipEnumerations support in Serenum.sys, vendors have greater control over how COM ports behave during the boot process. Vendors should examine these new registry options and evaluate whether the user experience can be improved.
The technique was clear on everything except for exactly what key
to put the SkipEnumerations value in. What key was this?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\%Enumerator%\%Device_ID%\%Instance_ID%\Device Parameters
What were the values of %Enumerator%, %Device_ID%, and
%Instance_ID% supposed to be? I found these values by looking in the
key following key for Serenum.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\serenum\Enum
In this key there is one value per COM port on the system. Each value had a name of just a single digit, starting at 0. The below image shows the registry editor with the Enum key selected and the various values that it contains.
The values named 0 through 3 corresponded to the COM ports on
the box. The box in question had one on-board serial port, two serial
ports on a PCI card, and one USB-to-serial adapter for a 4th port.
Notice the values of 0-3—these values are the
%Enumerator%\%Device_ID%\%Instance_ID% that I needed to identify where
to put the SkipEnumerations value. So, looking at 0, the value was
PCI\VEN_1407&DEV_0110&SUBSYS_00000000&REV_00\4&2af9ed5&0&00F0
Breaking this down, the %Enumerator% is PCI, the %Device_ID% is
"VEN_1407&DEV_0110&SUBSYS_00000000&REV_00", and the
%Instance_ID% is 4&2af9ed5&0&00F0. This means if I
wanted to disable probing on this port, I needed to
create the SkipEnumerations value in the following key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_1407&DEV_0110&SUBSYS_00000000&REV_00\4&2af9ed5&0&00F0\Device Parameters
As an aside, looking at the enumerator value of PCI, I knew that
this corresponded to one of the serial ports on the PCI card I had,
but I didn't know which one, because there are two. The numbers in
the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\serenum\Enum
don't correspond to the COM port numbers we are used to dealing with
as users, like COM1, COM4, COM8, etc. I'll show how to identify the
COM port number associated with this serial port in a minute. Before
that, look at the 2 value in the serenum\Enum key:
ACPI\PNP0501\1
Because the enumerator here was ACPI, that indicated that the port
was on the motherboard. The other value, 3, was for the USB port.
It's enumerator is (surprise) USB. Easy enough. Now how could I
figure out which COM port number I needed to set the SkipEnumerations
value in? I only knew that COM1 was the port on which the probing was
causing problems.
To find which COM port number I needed, I looked at all of the "Device Parameters" keys identified numbered values in the serenum\Enum key.
0: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_1407&DEV_0110&SUBSYS_00000000&REV_00\4&2af9ed5&0&00F0\Device Parameters
1: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_1407&DEV_0111&SUBSYS_00000000&REV_00\4&2af9ed5&0&01F0\Device Parameters
2: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\PNP0501\1\Device Parameters
3: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_067b&Pid_2303\5&287ed76f&0&2\Device Parameters
Each of these keys had a value in them named "PortName", which had the COM port number. The following image shows the first of these keys as an example. Notice the PortName value.
So using this information, I figured out that COM1 was the on-board serial port and that I needed to create the SkipEnumerations value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\PNP0501\1\Device Parameters key. Doing this stopped Windows from pulsing the DTR and RTS lines during bootup, which caused my device to freak out.
The XP box in question already skipped detecting a serial mouse via the flags in boot.ini. The offending service was Serenum, which in XP respects the SkipEnumerations registry value to avoid probing particular serial ports for attached devices.
Is this true? Is Advantech pushing EWF as a replacement for virus protection? Still a bad idea, right?
I just got back from the Seattle area, taking a Microsoft training class with one of their partner/reseller's in the Bellevue area on Windows CE. Interesting stuff. They pointed me to a lot of resources out there covering CE.
Some Windows CE debugging fun for you tonight...
First, sharpen your "ninja debugging skillz" by understanding VM layout on CE (read: recognizing the location of an address just by looking at it--wha*ta!). Then learn how to figure out which freaking function of which DLL threw that exception with Sue Loh's write-up on manual address to symbol resolution.
I'm not a big Windows CE fan, but I work with it every day, and I can't tell you the number of times I've needed to do this very process. Sue's article does a good job of breaking this down.
I've been meaning to do a lot of things around here, but I haven't had the time. Things like fixing the default style sheet to render properly in Firefox, removing a lot of unused content to make space, cutting out crufty backend-code, etc. Unfortunately, I've been way to busy for these things to even register on my radar.
Thanks goes out to Greg Danielius (despam the address) for his report of Linux compatilibity for the Sanyo MM-7400 phone. It works for data access under Linux with Sprint's PCS Vision service. Report posted in the list.
Just added the Nokia 3588i to the database of Sprint Phones known to work with Linux for data access. The info comes from a post over at PeerFear
I'm starting this thread tonight that I'll be updating after I go to the mechanic this week. My 1999 Ford Escort SE started stuttering and riding hard last night on the way up to see my fiance. I hit some extremely heavy rain and very light flooding on a major interstate on the way, as I was coming through one of the cities halfway between us. That's when it started.
When I would accelerate from around 40 MPH to 60 MPH, the car would start to ride hard, almost stuttering or shuttering. Like a quick series of hesitations, the car would feel like it was jerking a bit. It would clear up around 65 MPH or so, but I did experience it between 70 - 80 MPH for a few minutes.
I'm at about 82K miles on the thing, after being bought around 40K. Never had any serious problem with my fuel injectors sticking, and I just had the engine decoked at around 70K. Other than some problems with an improperly installed fuel filter, an IAC valve that wanted to go bad a lot, and one leak in my EVAP system, the car didn't give me much trouble.
I stopped during the rain, after feeling it stutter a few times, filled up the tank, and put in an engine treatment that would remove water, an STP brand I believe. Didn't do any good. It still stuttered in that MPH range on the rest of the way up, but the rain slacked off, so I could easily keep it above 70 MPH for the rest of the trip, letting it ride smooth.
On the way back down, it kept stuttering in the same MPH range. Then it got bad and the Check Engine Light started flashing, indicating the engine was misfiring.
A friend of mine theorized that perhaps the Escort took up some of the water and maybe it got in the distributor. I did a quick bit of research about that, consulting the Haynes manual for Ford Escorts & and Mercury Tracers, 1991 - 2000. However, The engine, a 2.0L SPI (Slit Port Injection?) engine that 1999 Ford Escort SEs have, doesn't have an distributor, like many newer engines. However, the theory may still be helpful—I may have water in my ignition system.
Of course, it could be many other things causing me to misfire. As long as I drive it smooth it seems okay.
I'm going to see a local mechanic tomorrow and I'll probably update this entry with any details.
The problem was caused by faulty spark plug wires. A tune-up seemed to do the job and the car seems to be riding a lot smoother. Cost: $150.
Current total: $1665
I just added up a compatibility report to the list of Sprint Phones known to work with Linux for data access, specifically for the Sanyo RL-4920. I tested it personally with the data cable I use with my 4900 and it worked great.
This weekend I asked my girlfriend of almost 2 years (and friend of around 8 years) to marry me, and she accepted. For collateral, I offered her a expensive lump of crystalline carbon on a white gold band, a questionable tradition at best. But you have to do what you have to do to get the girl you want to marry you.
Do you run Mozilla or Firefox? Do you want to know what Google thinks about the pages you visit (including perhaps your own)? Then check out Pagerank extention for Mozilla and Firefox browsers. Finally, a cross-platform browser extention to view standings in the greatest popularity contenst of the digital era. I'm using it here under Gentoo Linux with Mozilla 1.6 and it works great.