add CC (Andrew, Greg and linux-usb) On 2/15/08, Andrew Buehler <[EMAIL PROTECTED]> wrote: > In my workplace, I use a customized version of Novell's ZENworks imaging > boot CD, which is based off of Linux. I have one particular model of > laptop - the IBM/Lenovo R61 - on which three different things fail > completely in current kernels (tested with 2.6.24.2 and 2.6.25-rc1): > USB, AHCI (and thus access to the SATA drive), and networking. As a > consequence of all three failing in parallel, I have no practical way to > get logs and other information off of the machine to help with tracking > down the bugs. > > I am primarily concerned about the AHCI and networking issues, since > they are what need to be working in order for us to do what we need to > with these boot discs and these laptops. However, I intend to focus on > the USB issue first, because it seems slightly more tractable and fixing > it would allow me to reliably get logs off of the computer so as to > provide information to help track down and fix the other problems. > > Specifically, the USB issue is more tractable in that I have found one > narrow set of circumstances in which I *can* get it to work, and so have > been able to obtain an lspci log and a dmesg log from the failing > laptop. I seem to remember the lkml FAQ advising not to simply attach > such files unsolicited, so I have not provided them here, but I am more > than willing to send them (and the matching .config file) along upon > request. Instead, I will do my best to summarize the errors as I have > observed them, though that best may be somewhat poor. In the following, > unless explicitly specified, I am using 2.6.25-rc1, simply because I > expect that it will be more likely to get attention and fixes than > earlier (released) versions. > > > Early in the boot process, immediately after the 'io scheduler foobar > registered' lines, the message > > ==== > 0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug?) 01010001 > ==== > > appears twice. Despite the parenthetical suggestion, I do not believe > that the problem could be a bug in the BIOS, because Windows is able to > access all of the hardware on these laptops - including USB devices, > which is what I understand EHCI to involve - without the slightest > difficulty. > > If there is no USB Flash drive is connected during the boot process, > there are no further apparently-USB-related errors during boot that I > can recognize, and various messages about USB host controllers being > detected appear; they seem to be perfectly normal. When the boot process > completes, connecting such a drive produces no visible response > whatsoever. > > If on the other hand there *is* a USB Flash drive connected during the > boot process, there are many other USB-related messages, some of which > appear to be errors. I am not certain which are in fact relevant, and > would prefer not to simply copy-and-paste blindly from the log; if the > information is necessary, I would prefer to simply provide the entire > log rather than risk missing something important. However, when the boot > process is done and the usb-storage module is loaded, the drive is in > fact recognized and can be mounted, though it is very slow to respond; > in my one test it took ~20+ seconds to mount the drive (512MB, vfat), an > unmeasured but quite long time to dump dmesg into a file on that drive, > a barely noticeable but still present blink to copy /proc/config.gz to > the drive, and four seconds to unmount afterwards. > > > For reference, I have on hand a version of this same boot disc built > using kernel 2.6.23.1, which does not produce the EHCI errors, and on > which the USB drive is usable in exactly the way I expect from a Linux > system. I have not made a significant attempt to narrow down the point > at which the functionality broke, but I can do so if desired, though it > will take some time - the more so as I can test this only while at work, > and am facing an impending three-day weekend. > > (I do not have a working git environment, and do not understand well how > to set one up, as the mechanics and to some extent the interface > semantics of git seem to be rather different from those of any VCS with > which I am familiar. That is, however, the only reason - aside from the > time involved - why I would be unwilling to track down the exact change > which caused the regression.) > > I am quite certain that I have not provided enough information to > address the problem. Please let me know what would be necessary, and I > will do my best to provide it. Additionally, if I have made any major > flubs (of etiquette or otherwise), please do point them out so that I > can avoid them in future. > > -- > Andrew Buehler > -- > 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/ >
-- Thanks, Oliver -- 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/
