Thanks for the detailed response. I thought I had gotten to the bottom of my problems when I found that udev workaround, I guess I was naive.
I did the two tests you described and they predictably caused the hard hangs. I needed to run the port80 program only once to get the hard hang. The output of the dmidecode commands were : Quanta 30B7 I applied the patch you provided ( luckily I am using 2.6.24-rc6-git3 kernel because I need the b43 driver ), added these values and compiled. { .callback = dmi_io_delay_port_alt, .ident = "Compaq Presario v6000", .matches = { DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"), DMI_MATCH(DMI_BOARD_NAME, "30B7") } }, I was able to boot without the udev workaround and can now use hwclock without hanging the system. In dmesg I can see this new line : On Sat, 2007-12-29 at 09:43 -0500, David P. Reed wrote: > Islam Amer wrote: > > Hello. > > I was interested in getting dynticks to work on my compaq presario v6000 > > to help with the 1 hour thirty minutes battery time, but after this > > discussion I lost interest. > > > > I too had the early boot time hang, and found it was udev triggering the > > bug. > > > This early boot time hang is *almost certainly* due to the in/out port > 80 bug, which I discovered a few weeks ago, which affects hwclock and > other I/O device drivers on a number of HP/Compaq machines in exactly > this way. The proper fix for this bug is in dispute, and will probably > not occur in the 2.6.24 release because it touches code in many, many > drivers. The simplest way to test if you have a problem of this sort is > to try this shell line as root, after you boot successfully. If your > machine hangs hard, you have a problem that really looks like the port > 80 problem. > > for ((i = 0; i < 1000; i = i + 1)); do cat /dev/nvram > /dev/null; done > > I have also attached a c program that only touches port 80. Compile it > for 32-bit mode (see comment), run it as root, and after two or three > runs, it will hang a system that has the port 80 bug. > > If you then run: > > dmidecode -s baseboard-manufacturer > dmidecode -s baseboard-product-name > > are the values you should plug into the .matches field in the > dmi_system_id struct in the attached patch. It would be great if you > could do that, test, and post back with those values so they can be > accumulated. HP/Compaq machines with quanta m/b's are very popular, and > very common - so at least a quirk patch for all the broken models would > be worth doing in 2.6.25 or downstream in the distros. The right > patches will probably take a long time - there is a dispute as to what > the semantics of port 80 writes even mean among the core kernel > developers, because the hack is lost in the dim dark days of history, > and safe resolution will take time > > There is also a C1E issue with the BIOS in my machine (an HP Pavilion > dv9000z). I don't know if it is a bug, yet, but that's a different > problem - associated with dynticks, perhaps. I have to say that > researching the AMD Kernel/BIOS docs on C1E (a very new feature in the > last year on AMD) leaves me puzzled as to whether the dynticks problem > exists on my machine at all, but the patch for it turns off dynticks! > > > > > Changing the /etc/init.d/udev script so that the line containing > > > > /sbin/udevtrigger > > > > to > > > > /sbin/udevtrigger --subsystem-nomatch="*misc*" > > > > seemed to fix things. > > > > the hang is triggered specifically by > > > > echo add > /sys/class/misc/rtc/uevent > > after inserting rtc.ko > > > > Also using hwclock to set the rtc , will cause a hard hang, if you are > > using 64bit linux. Disable the init scripts that set the time, or use > > the 32bit binary, as suggested here : > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg41964.html > > > > I hope this helps. But your hardware is slightly different though. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/