USB regression (and other failures) in 2.6.2[45]*

USB regression (and other failures) in 2.6.2[45]*

[Andrew Buehler]

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

Re: USB regression (and other failures) in 2.6.2[45]*

[Oliver Pinter]

add CC (Andrew, Greg and linux-usb)

On 2/15/08, Andrew Buehler <abuehler.kernel@gmail.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Thanks,
Oliver

Re: USB regression (and other failures) in 2.6.2[45]*

[Alan Stern]

On Sat, 16 Feb 2008, Oliver Pinter wrote:

> On 2/15/08, Andrew Buehler <abuehler.kernel@gmail.com> 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.

...

To make a long story short, the USB symptoms you describe indicate a
problem with interrupt routing.  This could well explain the other
difficulties too.  There are various kernel parameters you can try
putting on the boot command line to work around it:  acpi=noirq or
acpi=off or pci=noacpi or a few others.

Alan Stern

Re: USB regression (and other failures) in 2.6.2[45]*

[Andrew Buehler]

(Note: I consider it blatantly incorrect to send a reply both to a
mailing list and directly to the address of someone who is subscribed to
that list unless you have reason to believe that that someone will not
see the message otherwise, but in this case I am doing so anyway because
I see no way to avoid it and still make sure all relevant people receive
the message.)

On 2/16/2008 10:20 AM, Alan Stern wrote:

> On Sat, 16 Feb 2008, Oliver Pinter wrote:
> 
>> On 2/15/08, Andrew Buehler <abuehler.kernel@gmail.com> 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.
> 
> ...
> 
> To make a long story short, the USB symptoms you describe indicate a
> problem with interrupt routing.  This could well explain the other
> difficulties too.  There are various kernel parameters you can try
> putting on the boot command line to work around it:  acpi=noirq or
> acpi=off or pci=noacpi or a few others.

I have now tried all three of these, with no apparent effect; the USB
drive is still not detected when plugged in after boot. A naive search
on Google provides no indication of other possible parameters to try;
the only list I have found of ACPI-related kernel parameters includes no
others which seem likely to be helpful without more knowledge of the
specifics of the situation (and the subsystem) than I have.

What would the next step be?

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]*

[Alan Stern]

On Sat, 16 Feb 2008, Andrew Buehler wrote:

> (Note: I consider it blatantly incorrect to send a reply both to a
> mailing list and directly to the address of someone who is subscribed to
> that list unless you have reason to believe that that someone will not
> see the message otherwise, but in this case I am doing so anyway because
> I see no way to avoid it and still make sure all relevant people receive
> the message.)

I (and a lot of other people as well, to judge by the email I receive) 
don't think this is incorrect.  For one thing, it's not always possible 
to tell whether or not the recipient is subscribed to any of the lists.  
For another, getting two copies of a message is no big deal -- more 
irritating (IMO) is getting a rejection message as a result of replying 
to message which was cross-posted to a closed list.  But in each case, 
hitting the "d" key will delete the unwanted message.

In fact, the thing that bothers me the most is when people reply to a 
long email with just a few lines of new text but don't bother to prune 
the long message down to its essential parts.  This forces me to read 
through hundreds of lines containing nothing new or of interest in 
order to obtain a minimal amount of useful information.

> On 2/16/2008 10:20 AM, Alan Stern wrote:

> > To make a long story short, the USB symptoms you describe indicate a
> > problem with interrupt routing.  This could well explain the other
> > difficulties too.  There are various kernel parameters you can try
> > putting on the boot command line to work around it:  acpi=noirq or
> > acpi=off or pci=noacpi or a few others.
> 
> I have now tried all three of these, with no apparent effect; the USB
> drive is still not detected when plugged in after boot. A naive search
> on Google provides no indication of other possible parameters to try;
> the only list I have found of ACPI-related kernel parameters includes no
> others which seem likely to be helpful without more knowledge of the
> specifics of the situation (and the subsystem) than I have.
> 
> What would the next step be?

People on LKML who are more familiar with interrupt routing problems 
might be able to offer more help.  For now, you can try things like 
turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting the 
contents of /proc/interrupts (say before and after a new USB device is 
plugged in).

Assuming that the 2.6.23 kernel works on your computer, you can go the 
extreme route of installing git and doing a bisection to find the first 
patch causing your difficulty.

Alan Stern

Re: USB regression (and other failures) in 2.6.2[45]*

[Andrew Buehler]

[-- Attachment #1: Type: text/plain, Size: 6776 bytes --]

On 2/16/2008 12:16 PM, Alan Stern wrote:

> On Sat, 16 Feb 2008, Andrew Buehler wrote:
> 
>> (Note: I consider it blatantly incorrect to send a reply both to a
>> mailing list and directly to the address of someone who is
>> subscribed to that list unless you have reason to believe that that
>> someone will not see the message otherwise, but in this case I am
>> doing so anyway because I see no way to avoid it and still make
>> sure all relevant people receive the message.)

(I did not expect to receive any significant response to this part of
the message, and any discussion ensuing from it is unquestionably
offtopic for the kernel mailing lists. I will respond here for the
moment rather than sending a separate, private mail, but I am more than
willing to take further responses on this topic offlist or drop the
subject entirely as soon as that is requested.)

> I (and a lot of other people as well, to judge by the email I
> receive) don't think this is incorrect.  For one thing, it's not
> always possible to tell whether or not the recipient is subscribed to
> any of the lists.

This is indeed why I did not see any way to avoid it in this instance.
However, that has no bearing on the question of whether or not it is
correct or appropriate to do so, only whether or not it is avoidable.

> For another, getting two copies of a message is no big deal --

I disagree.

(For that matter, I am not in fact getting two copies; in fact, I am not
receiving through the list either messages which I send to the list or
messages which are sent both to the list and to me. Whether this is the
list's fault or Gmail's I don't know, though I suspect the former - but
it is very irritating, because it means that I do not see this thread on
the mailing list itself and have to carry on list-related discussion
from my Inbox.)

> more irritating (IMO) is getting a rejection message as a result of
> replying to message which was cross-posted to a closed list.  But in
> each case, hitting the "d" key will delete the unwanted message.

I keep complete archives of everything I receive except for spam and (in
some cases) duplicates. Deleting received mail is a highly unpalatable
option, and in any case the ability to delete it is not the point; the
important question is whether it should have been there to begin with.

When I receive a message sent directly to me in a discussion which is on
a list, I expect that it is because someone either considered it
important enough to warrant making certain it came to my attention
specifically, or wanted to continue the discussion but felt that it
should not continue to take place on the mailing list.

> In fact, the thing that bothers me the most is when people reply to a
> long email with just a few lines of new text but don't bother to
> prune the long message down to its essential parts.  This forces me
> to read through hundreds of lines containing nothing new or of
> interest in order to obtain a minimal amount of useful information.

On the matter of quoting correctly and snipping correctly, you are
preaching to the choir where I am concerned. My standards for how much
context to leave in before beginning to snip are perhaps a bit looser
than those of some people (I leave up to three levels of quote in total
unless more is strictly necessary, since I find that fewer than that
frequently does not provide enough context if one does not have the
discussion in recent memory), but in principle I agree with you
completely.

>> On 2/16/2008 10:20 AM, Alan Stern wrote:
> 
>>> To make a long story short, the USB symptoms you describe
>>> indicate a problem with interrupt routing.  This could well
>>> explain the other difficulties too.  There are various kernel
>>> parameters you can try putting on the boot command line to work
>>> around it:  acpi=noirq or acpi=off or pci=noacpi or a few others.
>> 
>> I have now tried all three of these, with no apparent effect; the
>> USB drive is still not detected when plugged in after boot. A naive
>> search on Google provides no indication of other possible
>> parameters to try; the only list I have found of ACPI-related
>> kernel parameters includes no others which seem likely to be
>> helpful without more knowledge of the specifics of the situation
>> (and the subsystem) than I have.
>> 
>> What would the next step be?
> 
> People on LKML who are more familiar with interrupt routing problems
> might be able to offer more help.  For now, you can try things like
> turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting
> the contents of /proc/interrupts (say before and after a new USB
> device is plugged in).

In my current testing kernel, which I believe is the one with which I
captured the sole successful non-2.6.23.1 dmesg so far, CONFIG_USB_DEBUG
is on. The associated dmesg (obtained yesterday from booting with the
Flash drive connected) is attached. (The flood of 'no version magic,
tainting kernel' messages between line 600 and line 1160 are a side
effect of Novell's custom environment which I have not yet made the
effort to fix; the boot scripts attempt to detect the network card by
modprobing every network driver available until they find one which
works. Here, because the correct one fails, they wind up trying each one
twice.)

I have transcribed the contents of /proc/interrupts both before and
after plugging in the Flash drive I have been using for testing, and
they are also attached. I have been as careful as I could to be sure
that the contents of the attached 'r61-interrupts-[12].txt' files is the
same as what was shown on the laptop, but cannot absolutely guarantee
that I have not missed something. For the record, the '1' is from before
connecting the drive, and the '2' is from after.

I did try booting again with the Flash drive attached, in hopes of being
able to mount it and dump the contents of /proc/interrupts there to
obtain them with guaranteed accuracy, but it was not recognized after
being disconnected and reconnected again.

> Assuming that the 2.6.23 kernel works on your computer, you can go
> the extreme route of installing git and doing a bisection to find the
> first patch causing your difficulty.

That would require me to learn enough of how git works, as distinct from
more traditional VCSes, to be able to use it with some confidence. This
is not impossible - indeed I want to do it at some point - but for the
time being I have no idea where to start, and indeed I am not especially
clear on exactly what (from a user's perspective) the differences been
git and e.g. CVS or Subversion are. I know that the entire concept
relies around a lack of centralization, but I have not been able to get
my head around what that means in a practical sense.

-- 
    Andrew Buehler

[-- Attachment #2: r61-dmesg-usb_drive_during_boot-2.6.25-rc1.txt --]
[-- Type: text/plain, Size: 55616 bytes --]

Linux version 2.6.25-rc1 (root@zenboot) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Fri Feb 15 14:18:51 EST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009d800 (usable)
 BIOS-e820: 000000000009d800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001e6b0000 (usable)
 BIOS-e820: 000000001e6b0000 - 000000001e6cd000 (ACPI data)
 BIOS-e820: 000000001e6cd000 - 000000001e700000 (ACPI NVS)
 BIOS-e820: 000000001e700000 - 000000001f000000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
 BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
486MB LOWMEM available.
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
found SMP MP-table at [c00f6900] 000f6900
Entering add_active_range(0, 0, 124592) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   124592
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   124592
On node 0 totalpages: 124592
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 941 pages used for memmap
  Normal zone: 119555 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
DMI present.
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: INTEL    Product ID: Napa ERB     APIC at: 0xFEE00000
Processor #0 6:6 APIC version 20
I/O APIC #1 Version 32 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 20000000 (gap: 1f000000:d1000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 123619
Kernel command line: 5 initrd=initrd.gz reboot=w root=/dev/ram rw ccps BOOT_IMAGE=Kernel 
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 1861.995 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 470824k/498368k available (3451k kernel code, 26956k reserved, 1024k data, 240k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb9000 - 0xfffff000   ( 280 kB)
    vmalloc : 0xdf000000 - 0xfffb7000   ( 527 MB)
    lowmem  : 0xc0000000 - 0xde6b0000   ( 486 MB)
      .init : 0xc0568000 - 0xc05a4000   ( 240 kB)
      .data : 0xc045ef18 - 0xc055f2f8   (1024 kB)
      .text : 0xc0100000 - 0xc045ef18   (3451 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 16 of 16 pages preallocated
Calibrating delay using timer specific routine.. 3728.64 BogoMIPS (lpj=7457282)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 1024K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
using mwait in idle threads.
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 22k freed
CPU0: Intel(R) Celeron(R) CPU          540  @ 1.86GHz stepping 01
Total of 1 processors activated (3728.64 BogoMIPS).
ExtINT not setup in hardware but reported by MP table
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
Brought up 1 CPUs
net_namespace: 164 bytes
NET: Registered protocol family 16
PCI: PCI BIOS revision 3.00 entry at 0xfdda7, last bus=24
PCI: Using configuration type 1
Setting up standard PCI resources
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
PCI: Bridge: 0000:00:1c.0
  IO window: 2000-2fff
  MEM window: 0xfc000000-0xfdffffff
  PREFETCH window: 0x00000000f8000000-0x00000000f80fffff
PCI: Bridge: 0000:00:1c.1
  IO window: 3000-3fff
  MEM window: 0xdc000000-0xdf3fffff
  PREFETCH window: 0x00000000dfe00000-0x00000000dfefffff
PCI: Bridge: 0000:00:1c.2
  IO window: 4000-4fff
  MEM window: 0xd8000000-0xd9ffffff
  PREFETCH window: 0x00000000dfb00000-0x00000000dfbfffff
PCI: Bridge: 0000:00:1c.3
  IO window: 5000-5fff
  MEM window: 0xd4000000-0xd5ffffff
  PREFETCH window: 0x00000000df800000-0x00000000df8fffff
PCI: Bridge: 0000:00:1c.4
  IO window: 6000-6fff
  MEM window: 0xd0000000-0xd1ffffff
  PREFETCH window: 0x00000000df500000-0x00000000df5fffff
PCI: Bus 22, cardbus bridge: 0000:15:00.0
  IO window: 0x00007000-0x000070ff
  IO window: 0x00007400-0x000074ff
  PREFETCH window: 0xf4000000-0xf7ffffff
  MEM window: 0x20000000-0x23ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 7000-afff
  MEM window: 0xf8300000-0xfbffffff
  PREFETCH window: 0x00000000f4000000-0x00000000f7ffffff
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1c.2 to 64
PCI: Setting latency timer of device 0000:00:1c.3 to 64
PCI: Setting latency timer of device 0000:00:1c.4 to 64
PCI: Enabling device 0000:00:1e.0 (0005 -> 0007)
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PCI: Setting latency timer of device 0000:15:00.0 to 64
NET: Registered protocol family 2
Time: tsc clocksource has been installed.
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 16382k freed
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
NTFS driver 2.1.29 [Flags: R/W].
JFS: nTxBlock = 3808, nTxLock = 30464
SGI XFS with large block numbers, no debug enabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:00:02.0: Boot video device
pci 0000:00:1a.0: uhci_check_and_reset_hc: legsup = 0x003b
pci 0000:00:1a.0: Performing full reset
pci 0000:00:1a.1: uhci_check_and_reset_hc: legsup = 0x0010
pci 0000:00:1a.1: Performing full reset
pci 0000:00:1a.7: EHCI: BIOS handoff
pci 0000:00:1a.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
pci 0000:00:1d.0: uhci_check_and_reset_hc: legsup = 0x003b
pci 0000:00:1d.0: Performing full reset
pci 0000:00:1d.1: uhci_check_and_reset_hc: legsup = 0x0010
pci 0000:00:1d.1: Performing full reset
pci 0000:00:1d.2: uhci_check_and_reset_hc: legsup = 0x0010
pci 0000:00:1d.2: Performing full reset
pci 0000:00:1d.7: EHCI: BIOS handoff
pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.1:pcie00]
Allocate Port Service[0000:00:1c.1:pcie02]
PCI: Setting latency timer of device 0000:00:1c.2 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.2:pcie00]
Allocate Port Service[0000:00:1c.2:pcie02]
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.3:pcie00]
Allocate Port Service[0000:00:1c.3:pcie02]
PCI: Setting latency timer of device 0000:00:1c.4 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.4:pcie00]
Allocate Port Service[0000:00:1c.4:pcie02]
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
toshiba: not a supported Toshiba laptop
brd: module loaded
Compaq SMART2 Driver (v 2.6.0)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH8M: IDE controller (0x8086:0x2850 rev 0x03) at  PCI slot 0000:00:1f.1
ICH8M: not 100% native mode: will probe irqs later
ICH8M: IDE port disabled
    ide0: BM-DMA at 0x1c00-0x1c07, BIOS settings: hda:DMA, hdb:PIO
Probing IDE interface ide0...
hda: HL-DT-STCD-RW/DVD DRIVE GCC-T10N, ATAPI CD/DVD-ROM drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/33 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
ide-floppy driver 1.00
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
ahci 0000:00:1f.2: version 3.0
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 3 ports 1.5 Gbps 0x1 impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part 
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
ata1: SATA max UDMA/133 abar m2048@0xfe226000 port 0xfe226100 irq 10
ata2: DUMMY
ata3: DUMMY
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1: failed to recover some devices, retrying in 5 secs
ata1: port is slow to respond, please be patient (Status 0x80)
ata1: COMRESET failed (errno=-16)
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1: failed to recover some devices, retrying in 5 secs
ata1: port is slow to respond, please be patient (Status 0x80)
ata1: COMRESET failed (errno=-16)
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1: failed to recover some devices, retrying in 5 secs
ata1: port is slow to respond, please be patient (Status 0x80)
ata1: COMRESET failed (errno=-16)
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
usbmon: debugfs is not available
ehci_hcd: block sizes: qh 128 qtd 96 itd 160 sitd 96
PCI: Setting latency timer of device 0000:00:1a.7 to 64
ehci_hcd 0000:00:1a.7: EHCI Host Controller
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file 'devices'
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1a.7: reset hcs_params 0x102204 dbg=1 cc=2 pcc=2 ordered !ppc ports=4
ehci_hcd 0000:00:1a.7: reset hcc_params 16871 thresh 7 uframes 1024 64 bit addr
ehci_hcd 0000:00:1a.7: reset command 080022 (park)=0 ithresh=8 Async period=1024 Reset HALT
PCI: cache line size of 32 is not supported by device 0000:00:1a.7
ehci_hcd 0000:00:1a.7: supports USB remote wakeup
ehci_hcd 0000:00:1a.7: irq 11, io mem 0xfe226c00
ehci_hcd 0000:00:1a.7: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:00:1a.7: init command 010001 (park)=0 ithresh=1 period=1024 RUN
ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: default language 0x0409
usb usb1: uevent
usb usb1: usb_probe_device
usb usb1: configuration #1 chosen from 1 choice
usb usb1: adding 1-0:1.0 (config #1, interface 0)
usb 1-0:1.0: uevent
hub 1-0:1.0: usb_probe_interface
hub 1-0:1.0: usb_probe_interface - got id
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
hub 1-0:1.0: standalone hub
hub 1-0:1.0: no power switching (usb 1.0)
hub 1-0:1.0: individual port over-current protection
hub 1-0:1.0: Single TT
hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
hub 1-0:1.0: power on to power good time: 20ms
hub 1-0:1.0: local power source is good
hub 1-0:1.0: trying to enable port power on non-switchable hub
hub 1-0:1.0: state 7 ports 4 chg 0000 evt 0000
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.25-rc1 ehci_hcd
usb usb1: SerialNumber: 0000:00:1a.7
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '002'
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:1d.7: reset hcs_params 0x103206 dbg=1 cc=3 pcc=2 ordered !ppc ports=6
ehci_hcd 0000:00:1d.7: reset hcc_params 16871 thresh 7 uframes 1024 64 bit addr
ehci_hcd 0000:00:1d.7: reset command 080022 (park)=0 ithresh=8 Async period=1024 Reset HALT
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: supports USB remote wakeup
ehci_hcd 0000:00:1d.7: irq 11, io mem 0xfe227000
ehci_hcd 0000:00:1d.7: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:00:1d.7: init command 010001 (park)=0 ithresh=1 period=1024 RUN
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb2: default language 0x0409
usb usb2: uevent
usb usb2: usb_probe_device
usb usb2: configuration #1 chosen from 1 choice
usb usb2: adding 2-0:1.0 (config #1, interface 0)
usb 2-0:1.0: uevent
hub 2-0:1.0: usb_probe_interface
hub 2-0:1.0: usb_probe_interface - got id
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
hub 2-0:1.0: standalone hub
hub 2-0:1.0: no power switching (usb 1.0)
hub 2-0:1.0: individual port over-current protection
hub 2-0:1.0: Single TT
hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns)
hub 2-0:1.0: power on to power good time: 20ms
hub 2-0:1.0: local power source is good
hub 2-0:1.0: trying to enable port power on non-switchable hub
hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0000
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.25-rc1 ehci_hcd
usb usb2: SerialNumber: 0000:00:1d.7
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 2-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
116x: driver isp116x-hcd, 03 Nov 2005
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd: block sizes: ed 64 td 64
USB Universal Host Controller Interface driver v3.0
PCI: Setting latency timer of device 0000:00:1a.0 to 64
uhci_hcd 0000:00:1a.0: UHCI Host Controller
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '003'
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1a.0: detected 2 ports
uhci_hcd 0000:00:1a.0: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1a.0: Performing full reset
uhci_hcd 0000:00:1a.0: irq 11, io base 0x00001860
usb usb3: default language 0x0409
usb usb3: uevent
usb usb3: usb_probe_device
usb usb3: configuration #1 chosen from 1 choice
usb usb3: adding 3-0:1.0 (config #1, interface 0)
usb 3-0:1.0: uevent
hub 3-0:1.0: usb_probe_interface
hub 3-0:1.0: usb_probe_interface - got id
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
hub 3-0:1.0: standalone hub
hub 3-0:1.0: no power switching (usb 1.0)
hub 3-0:1.0: individual port over-current protection
hub 3-0:1.0: power on to power good time: 2ms
hub 3-0:1.0: local power source is good
hub 3-0:1.0: trying to enable port power on non-switchable hub
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.25-rc1 uhci_hcd
usb usb3: SerialNumber: 0000:00:1a.0
PCI: Setting latency timer of device 0000:00:1a.1 to 64
uhci_hcd 0000:00:1a.1: UHCI Host Controller
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '004'
uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1a.1: detected 2 ports
uhci_hcd 0000:00:1a.1: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1a.1: Performing full reset
uhci_hcd 0000:00:1a.1: irq 11, io base 0x00001880
usb usb4: default language 0x0409
usb usb4: uevent
usb usb4: usb_probe_device
usb usb4: configuration #1 chosen from 1 choice
usb usb4: adding 4-0:1.0 (config #1, interface 0)
usb 4-0:1.0: uevent
hub 4-0:1.0: usb_probe_interface
hub 4-0:1.0: usb_probe_interface - got id
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
hub 4-0:1.0: standalone hub
hub 4-0:1.0: no power switching (usb 1.0)
hub 4-0:1.0: individual port over-current protection
hub 4-0:1.0: power on to power good time: 2ms
hub 4-0:1.0: local power source is good
hub 4-0:1.0: trying to enable port power on non-switchable hub
hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.25-rc1 uhci_hcd
usb usb4: SerialNumber: 0000:00:1a.1
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '005'
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.0: detected 2 ports
uhci_hcd 0000:00:1d.0: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1d.0: Performing full reset
uhci_hcd 0000:00:1d.0: irq 10, io base 0x000018a0
usb usb5: default language 0x0409
usb usb5: uevent
usb usb5: usb_probe_device
usb usb5: configuration #1 chosen from 1 choice
usb usb5: adding 5-0:1.0 (config #1, interface 0)
usb 5-0:1.0: uevent
hub 5-0:1.0: usb_probe_interface
hub 5-0:1.0: usb_probe_interface - got id
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
hub 5-0:1.0: standalone hub
hub 5-0:1.0: no power switching (usb 1.0)
hub 5-0:1.0: individual port over-current protection
hub 5-0:1.0: power on to power good time: 2ms
hub 5-0:1.0: local power source is good
hub 5-0:1.0: trying to enable port power on non-switchable hub
usb 2-2: new high speed USB device using ehci_hcd and address 2
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.25-rc1 uhci_hcd
usb usb5: SerialNumber: 0000:00:1d.0
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '006'
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
uhci_hcd 0000:00:1d.1: detected 2 ports
uhci_hcd 0000:00:1d.1: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1d.1: Performing full reset
uhci_hcd 0000:00:1d.1: irq 11, io base 0x000018c0
usb usb6: default language 0x0409
usb usb6: uevent
usb usb6: usb_probe_device
usb usb6: configuration #1 chosen from 1 choice
usb usb6: adding 6-0:1.0 (config #1, interface 0)
usb 6-0:1.0: uevent
hub 6-0:1.0: usb_probe_interface
hub 6-0:1.0: usb_probe_interface - got id
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 2 ports detected
hub 6-0:1.0: standalone hub
hub 6-0:1.0: no power switching (usb 1.0)
hub 6-0:1.0: individual port over-current protection
hub 6-0:1.0: power on to power good time: 2ms
hub 6-0:1.0: local power source is good
hub 6-0:1.0: trying to enable port power on non-switchable hub
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb6: Product: UHCI Host Controller
usb usb6: Manufacturer: Linux 2.6.25-rc1 uhci_hcd
usb usb6: SerialNumber: 0000:00:1d.1
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '007'
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
uhci_hcd 0000:00:1d.2: detected 2 ports
uhci_hcd 0000:00:1d.2: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1d.2: Performing full reset
uhci_hcd 0000:00:1d.2: irq 11, io base 0x000018e0
usb usb7: default language 0x0409
usb usb7: uevent
usb usb7: usb_probe_device
usb usb7: configuration #1 chosen from 1 choice
usb usb7: adding 7-0:1.0 (config #1, interface 0)
usb 7-0:1.0: uevent
hub 7-0:1.0: usb_probe_interface
hub 7-0:1.0: usb_probe_interface - got id
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 2 ports detected
hub 7-0:1.0: standalone hub
hub 7-0:1.0: no power switching (usb 1.0)
hub 7-0:1.0: individual port over-current protection
hub 7-0:1.0: power on to power good time: 2ms
hub 7-0:1.0: local power source is good
hub 7-0:1.0: trying to enable port power on non-switchable hub
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '001'
usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb7: Product: UHCI Host Controller
usb usb7: Manufacturer: Linux 2.6.25-rc1 uhci_hcd
usb usb7: SerialNumber: 0000:00:1d.2
sl811: driver sl811-hcd, 19 May 2005
/usr/src/linux-2.6.25-rc1/drivers/usb/host/r8a66597-hcd.c: driver r8a66597_hcd, 29 May 2007
usb usb3: suspend_rh (auto-stop)
usb usb4: suspend_rh (auto-stop)
usb usb6: suspend_rh (auto-stop)
usb usb7: suspend_rh (auto-stop)
ehci_hcd 0000:00:1d.7: Unlink after no-IRQ?  Controller is probably using the wrong IRQ.
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802d cmd 10021
usb 2-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802d cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802f cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
usb 2-2: device not accepting address 2, error -110
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 2-2: new high speed USB device using ehci_hcd and address 3
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802f cmd 10021
usb 2-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
ehci_hcd 0000:00:1d.7: IAA watchdog: status a02f cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802f cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
usb 2-2: device not accepting address 3, error -110
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 2-2: new high speed USB device using ehci_hcd and address 4
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802f cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802f cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
usb 2-2: device not accepting address 4, error -110
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 2-2: new high speed USB device using ehci_hcd and address 5
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802f cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
ehci_hcd 0000:00:1d.7: IAA watchdog: status 802f cmd 10021
usb 2-2: khubd timed out on ep0out len=0/0
usb 2-2: device not accepting address 5, error -110
hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0004
uhci_hcd 0000:00:1d.0: port 2 portsc 0093,00
hub 5-0:1.0: port 2, status 0101, change 0001, 12 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
usb 5-2: new full speed USB device using uhci_hcd and address 2
usb 5-2: not running at top speed; connect to a high speed hub
usb 5-2: default language 0x0409
usb 5-2: uevent
usb 5-2: usb_probe_device
usb 5-2: configuration #1 chosen from 1 choice
usb 5-2: adding 5-2:1.0 (config #1, interface 0)
usb 5-2:1.0: uevent
/usr/src/linux-2.6.25-rc1/drivers/usb/core/inode.c: creating file '002'
usb 5-2: New USB device found, idVendor=08ec, idProduct=0020
usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-2: Product: U3 smart 512MB
usb 5-2: Manufacturer: Ativa
usb 5-2: SerialNumber: 02D1EA6171E018E7
hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000
hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000
libusual 5-2:1.0: usb_probe_interface
libusual 5-2:1.0: usb_probe_interface - got id
usbcore: registered new interface driver libusual
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
Synaptics Touchpad, model: 1, fw: 6.2, id: 0x81a0b1, caps: 0xa04793/0x300000
serio: Synaptics pass-through port at isa0060/serio1/input0
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input1
IBM TrackPoint firmware: 0x0e, buttons: 3/3
input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input2
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 240k freed
ISO 9660 Extensions: RRIP_1991A
hda: UDMA/33 mode selected
st: Version 20080117, fixed bufsize 32768, s/g segs 256
Driver 'st' needs updating - please use bus_type methods
usb 1-0:1.0: uevent
usb 2-0:1.0: uevent
usb 3-0:1.0: uevent
usb 4-0:1.0: uevent
usb 5-0:1.0: uevent
usb 5-2: uevent
usb 5-2:1.0: uevent
usb 6-0:1.0: uevent
usb 7-0:1.0: uevent
usb usb1: uevent
usb usb2: uevent
usb usb3: uevent
usb usb4: uevent
usb usb5: uevent
usb usb6: uevent
usb usb7: uevent
usb usb1: uevent
usb usb2: uevent
usb usb3: uevent
usb usb4: uevent
usb usb5: uevent
usb 5-2: uevent
usb usb6: uevent
usb usb7: uevent
BIOS EDD facility v0.16 2004-Jun-25, 6 devices found
zdisk[1069]: segfault at 0 ip b7d02bb0 sp bfab1ed0 error 4 in libc.so.6[b7c9c000+10b000]
mii: no version for "struct_module" found: kernel tainted.
mii: no version magic, tainting kernel.
ssb: no version magic, tainting kernel.
b44: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
8139too: no version magic, tainting kernel.
8139too Fast Ethernet driver 0.9.28
mii: no version magic, tainting kernel.
3c59x: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
eepro100: no version magic, tainting kernel.
eepro100.c:v1.09j-t 9/29/99 Donald Becker
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
ni52: no version magic, tainting kernel.
ni52: Autoprobing not allowed for modules.
ni52: Set symbols 'io' 'irq' 'memstart' and 'memend'
mii: no version magic, tainting kernel.
8139cp: no version magic, tainting kernel.
8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
eth16i: no version magic, tainting kernel.
eth16i.c: Presently autoprobing (not recommended) for a single card.
eth16i.c No Eth16i card found (i/o = 0x0).
e1000e: no version magic, tainting kernel.
e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0
e1000e: Copyright (c) 1999-2007 Intel Corporation.
PCI: Setting latency timer of device 0000:00:19.0 to 64
0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1c:25:12:d2:65
0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
0000:00:19.0: eth0: MAC: 4, PHY: 6, PBA No: ffffff-0ff
mii: no version magic, tainting kernel.
ssb: no version magic, tainting kernel.
b44: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
8139too: no version magic, tainting kernel.
8139too Fast Ethernet driver 0.9.28
mii: no version magic, tainting kernel.
3c59x: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
eepro100: no version magic, tainting kernel.
eepro100.c:v1.09j-t 9/29/99 Donald Becker
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
ni52: no version magic, tainting kernel.
ni52: Autoprobing not allowed for modules.
ni52: Set symbols 'io' 'irq' 'memstart' and 'memend'
mii: no version magic, tainting kernel.
8139cp: no version magic, tainting kernel.
8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
eth16i: no version magic, tainting kernel.
eth16i.c: Presently autoprobing (not recommended) for a single card.
eth16i.c No Eth16i card found (i/o = 0x0).
mii: no version magic, tainting kernel.
ipg: no version magic, tainting kernel.
xircom_cb: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
winbond_840: no version magic, tainting kernel.
winbond-840.c:v1.01-e (2.4 port) Sep-11-2006  Donald Becker <becker@scyld.com>
  http://www.scyld.com/network/drivers.html
de4x5: no version magic, tainting kernel.
de2104x: no version magic, tainting kernel.
de2104x PCI Ethernet driver v0.7 (Mar 17, 2004)
dmfe: no version magic, tainting kernel.
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
uli526x: no version magic, tainting kernel.
uli526x: ULi M5261/M5263 net driver, version 0.9.3 (2005-7-29)
tulip: no version magic, tainting kernel.
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
mii: no version magic, tainting kernel.
hamachi: no version magic, tainting kernel.
hamachi.c:v2.1 Sept 11, 2006  Written by Donald Becker
   Some modifications by Eric kasten <kasten@nscl.msu.edu>
   Further modifications by Keith Underwood <keithu@parl.clemson.edu>
via_velocity: no version magic, tainting kernel.
82596: no version magic, tainting kernel.
ns83820: no version magic, tainting kernel.
ns83820.c: National Semiconductor DP83820 10/100/1000 driver.
mii: no version magic, tainting kernel.
amd8111e: no version magic, tainting kernel.
netxen_nic: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
8139too: no version magic, tainting kernel.
8139too Fast Ethernet driver 0.9.28
lance: no version magic, tainting kernel.
lance.c: Module autoprobing not allowed. Append "io=0xNNN" value(s).
mii: no version magic, tainting kernel.
via_rhine: no version magic, tainting kernel.
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
igb: no version magic, tainting kernel.
Intel(R) Gigabit Ethernet Network Driver - version 1.0.8-k2
Copyright (c) 2007 Intel Corporation.
niu: no version magic, tainting kernel.
8390: no version magic, tainting kernel.
3c503: no version magic, tainting kernel.
3c503.c: Presently autoprobing (not recommended) for a single card.
3c503.c: No 3c503 card found (i/o = 0x0).
ewrk3: no version magic, tainting kernel.
olympic: no version magic, tainting kernel.
lanstreamer: no version magic, tainting kernel.
smctr: no version magic, tainting kernel.
smctr.c: v1.4 7/12/00 by jschlst@samba.org
3c359: no version magic, tainting kernel.
ibmtr: no version magic, tainting kernel.
ibmtr: register_netdev() returned non-zero.
mii: no version magic, tainting kernel.
eepro100: no version magic, tainting kernel.
eepro100.c:v1.09j-t 9/29/99 Donald Becker
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
sky2: no version magic, tainting kernel.
skge: no version magic, tainting kernel.
e1000: no version magic, tainting kernel.
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
Copyright (c) 1999-2006 Intel Corporation.
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: no version magic, tainting kernel.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ipw2100: no version magic, tainting kernel.
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2
ipw2100: Copyright(c) 2003-2006 Intel Corporation
ieee80211_crypt: unregistered algorithm 'NULL'
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
hostap: no version magic, tainting kernel.
hostap_cs: no version magic, tainting kernel.
ieee80211_crypt: unregistered algorithm 'NULL'
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
hostap: no version magic, tainting kernel.
ieee80211_crypt: unregistered algorithm 'NULL'
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
hostap: no version magic, tainting kernel.
hostap_pci: no version magic, tainting kernel.
ieee80211_crypt: unregistered algorithm 'NULL'
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
hostap: no version magic, tainting kernel.
hostap_plx: no version magic, tainting kernel.
ieee80211_crypt: unregistered algorithm 'NULL'
hermes: no version magic, tainting kernel.
orinoco: no version magic, tainting kernel.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
spectrum_cs: no version magic, tainting kernel.
spectrum_cs 0.15 (Pavel Roskin <proski@gnu.org>, David Gibson <hermes@gibson.dropbear.id.au>, et al)
eeprom_93cx6: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
rtl8180: no version magic, tainting kernel.
prism54: no version magic, tainting kernel.
Loaded prism54 driver, version 1.2
Unloaded prism54 driver
atmel: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
ssb: no version magic, tainting kernel.
b43: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
zd1211rw: no version magic, tainting kernel.
usbcore: registered new interface driver zd1211rw
usbcore: deregistering interface driver zd1211rw
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: no version magic, tainting kernel.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ipw2200: no version magic, tainting kernel.
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmq
ipw2200: Copyright(c) 2003-2006 Intel Corporation
ieee80211_crypt: unregistered algorithm 'NULL'
netwave_cs: no version magic, tainting kernel.
atmel: no version magic, tainting kernel.
atmel_cs: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
cdc_ether: no version magic, tainting kernel.
usbcore: registered new interface driver cdc_ether
rndis_host: no version magic, tainting kernel.
usbcore: registered new interface driver rndis_host
rndis_wlan: no version magic, tainting kernel.
usbcore: registered new interface driver rndis_wlan
usbcore: deregistering interface driver rndis_wlan
usbcore: deregistering interface driver rndis_host
usbcore: deregistering interface driver cdc_ether
airo: no version magic, tainting kernel.
airo(): Probing for PCI adapters
airo(): Finished probing for PCI adapters
airo_cs: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
ath5k: no version magic, tainting kernel.
PCI: Setting latency timer of device 0000:03:00.0 to 64
ath5k_pci 0000:03:00.0: registered as 'phy0'
ath5k phy0: failed to resume the MAC Chip
ath5k_pci: probe of 0000:03:00.0 failed with error -5
mac80211: no version magic, tainting kernel.
iwl3945: no version magic, tainting kernel.
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.23k
iwl3945: Copyright(c) 2003-2007 Intel Corporation
mac80211: no version magic, tainting kernel.
iwl4965: no version magic, tainting kernel.
iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.2.23k
iwl4965: Copyright(c) 2003-2007 Intel Corporation
mac80211: no version magic, tainting kernel.
p54common: no version magic, tainting kernel.
p54usb: no version magic, tainting kernel.
usbcore: registered new interface driver prism54usb
usbcore: deregistering interface driver prism54usb
hermes: no version magic, tainting kernel.
orinoco: no version magic, tainting kernel.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_plx: no version magic, tainting kernel.
orinoco_plx 0.15 (Pavel Roskin <proski@gnu.org>, David Gibson <hermes@gibson.dropbear.id.au>, Daniel Barlow <dan@telent.net>)
hermes: no version magic, tainting kernel.
orinoco: no version magic, tainting kernel.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
hermes: no version magic, tainting kernel.
orinoco: no version magic, tainting kernel.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_cs: no version magic, tainting kernel.
orinoco_cs 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
mac80211: no version magic, tainting kernel.
p54common: no version magic, tainting kernel.
p54pci: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
p54common: no version magic, tainting kernel.
hermes: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
ssb: no version magic, tainting kernel.
b43legacy: no version magic, tainting kernel.
hermes: no version magic, tainting kernel.
orinoco: no version magic, tainting kernel.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_pci: no version magic, tainting kernel.
orinoco_pci 0.15 (Pavel Roskin <proski@gnu.org>, David Gibson <hermes@gibson.dropbear.id.au> & Jean Tourrilhes <jt@hpl.hp.com>)
atmel: no version magic, tainting kernel.
atmel_pci: no version magic, tainting kernel.
eeprom_93cx6: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
adm8211: no version magic, tainting kernel.
wl3501_cs: no version magic, tainting kernel.
arlan: no version magic, tainting kernel.
arlan: No Arlan devices found 
eeprom_93cx6: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
rtl8187: no version magic, tainting kernel.
usbcore: registered new interface driver rtl8187
usbcore: deregistering interface driver rtl8187
zd1201: no version magic, tainting kernel.
usbcore: registered new interface driver zd1201
usbcore: deregistering interface driver zd1201
wavelan: no version magic, tainting kernel.
WaveLAN init_module(): doing device probing (bad !)
Specify base addresses while loading module to correct the problem
WaveLAN init_module(): no device found
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: no version magic, tainting kernel.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
libertas: no version magic, tainting kernel.
usb8xxx: no version magic, tainting kernel.
usbcore: registered new interface driver usb8xxx
usbcore: deregistering interface driver usb8xxx
ieee80211_crypt: unregistered algorithm 'NULL'
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: no version magic, tainting kernel.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
libertas: no version magic, tainting kernel.
ieee80211_crypt: unregistered algorithm 'NULL'
ieee80211_crypt: no version magic, tainting kernel.
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: no version magic, tainting kernel.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ieee80211softmac: no version magic, tainting kernel.
bcm43xx: no version magic, tainting kernel.
bcm43xx driver
ieee80211_crypt: unregistered algorithm 'NULL'
hermes: no version magic, tainting kernel.
orinoco: no version magic, tainting kernel.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_tmd: no version magic, tainting kernel.
orinoco_tmd 0.15 (Joerg Dorchain <joerg@dorchain.net>)
airo: no version magic, tainting kernel.
airo(): Probing for PCI adapters
airo(): Finished probing for PCI adapters
wavelan_cs: no version magic, tainting kernel.
hermes: no version magic, tainting kernel.
orinoco: no version magic, tainting kernel.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_nortel: no version magic, tainting kernel.
orinoco_nortel 0.15 (Tobias Hoffmann & Christoph Jungegger <disdos@traum404.de>)
mac80211: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
rt2x00pci: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
rt2x00usb: no version magic, tainting kernel.
rt73usb: no version magic, tainting kernel.
usbcore: registered new interface driver rt73usb
usbcore: deregistering interface driver rt73usb
eeprom_93cx6: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
rt2x00pci: no version magic, tainting kernel.
rt2400pci: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
rt2x00usb: no version magic, tainting kernel.
eeprom_93cx6: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
rt2x00pci: no version magic, tainting kernel.
rt61pci: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
rt2x00usb: no version magic, tainting kernel.
rt2500usb: no version magic, tainting kernel.
usbcore: registered new interface driver rt2500usb
usbcore: deregistering interface driver rt2500usb
eeprom_93cx6: no version magic, tainting kernel.
mac80211: no version magic, tainting kernel.
crc_itu_t: no version magic, tainting kernel.
input_polldev: no version magic, tainting kernel.
rfkill: no version magic, tainting kernel.
rt2x00lib: no version magic, tainting kernel.
rt2x00pci: no version magic, tainting kernel.
rt2500pci: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
ssb: no version magic, tainting kernel.
b44: no version magic, tainting kernel.
natsemi: no version magic, tainting kernel.
natsemi dp8381x driver, version 2.1, Sept 11, 2006
  originally by Donald Becker <becker@scyld.com>
  2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
seeq8005: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
sundance: no version magic, tainting kernel.
sundance.c:v1.2 11-Sep-2006  Written by Donald Becker
8390: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
pcnet32: no version magic, tainting kernel.
pcnet32.c:v1.34 14.Aug.2007 tsbogend@alpha.franken.de
cs89x0: no version magic, tainting kernel.
cs89x0.c: Module autoprobing not allowed.
cs89x0.c: Append io=0xNNN
eepro: no version magic, tainting kernel.
eepro_init_module: Probe is very dangerous in ISA boards!
eepro_init_module: Please add "autodetect=1" to force probe
bnx2x: no version magic, tainting kernel.
3c589_cs: no version magic, tainting kernel.
fmvj18x_cs: no version magic, tainting kernel.
nmclan_cs: no version magic, tainting kernel.
axnet_cs: no version magic, tainting kernel.
8390: no version magic, tainting kernel.
pcnet_cs: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
smc91c92_cs: no version magic, tainting kernel.
xirc2ps_cs: no version magic, tainting kernel.
ibmtr_cs: no version magic, tainting kernel.
3c574_cs: no version magic, tainting kernel.
atp: no version magic, tainting kernel.
atp.c:v1.09=ac 2002/10/01 Donald Becker <becker@scyld.com>
depca: no version magic, tainting kernel.
hp100: no version magic, tainting kernel.
3c501: no version magic, tainting kernel.
8390: no version magic, tainting kernel.
smc_ultra: no version magic, tainting kernel.
smc-ultra.c: Presently autoprobing (not recommended) for a single card.
smc-ultra.c: No SMC Ultra card found (i/o = 0x0).
sc92031: no version magic, tainting kernel.
Silan SC92031 PCI Fast Ethernet Adapter driver 2.0c
3c515: no version magic, tainting kernel.
3c515.c:v0.99t-ac 28-Oct-2002 becker@scyld.com and others
s2io: no version magic, tainting kernel.
tehuti: no version magic, tainting kernel.
tehuti: Tehuti Networks(R) Network Driver, 7.29.3
tehuti: Options: hw_csum 
3c509: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
3c59x: no version magic, tainting kernel.
tg3: no version magic, tainting kernel.
at1700: no version magic, tainting kernel.
3c505: no version magic, tainting kernel.
3c505.c: warning, using default DMA channel,
3c505.c: module autoprobe not recommended, give io=xx.
3c505.c: Failed to register card at 0x0.
slhc: no version magic, tainting kernel.
ppp_generic: no version magic, tainting kernel.
PPP generic driver version 2.4.2
8390: no version magic, tainting kernel.
e2100: no version magic, tainting kernel.
e2100.c: Presently autoprobing (not recommended) for a single card.
e2100.c: No E2100 card found (i/o = 0x0).
de600: no version magic, tainting kernel.
eth%d: D-Link DE-600 pocket adapter: not at I/O 0x378.
bnx2: no version magic, tainting kernel.
sungem_phy: no version magic, tainting kernel.
smc9194: no version magic, tainting kernel.
SMC9194: You shouldn't use auto-probing with insmod!
mii: no version magic, tainting kernel.
8390: no version magic, tainting kernel.
hp_plus: no version magic, tainting kernel.
hp-plus.c: Presently autoprobing (not recommended) for a single card.
hp-plus.c: No HP-Plus card found (i/o = 0x0).
sungem_phy: no version magic, tainting kernel.
sungem: no version magic, tainting kernel.
inet_lro: no version magic, tainting kernel.
myri10ge: no version magic, tainting kernel.
myri10ge: Version 1.3.2-1.287
ni65: no version magic, tainting kernel.
cxgb3: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
starfire: no version magic, tainting kernel.
starfire.c:v1.03 7/26/2000  Written by Donald Becker <becker@scyld.com>
 (unofficial 2.2/2.4 kernel port, version 2.0, June 27, 2006)
starfire: polling (NAPI) disabled
8390: no version magic, tainting kernel.
ne: no version magic, tainting kernel.
ne.c: You must supply "io=0xNNN" value(s) for ISA cards.
eexpress: no version magic, tainting kernel.
eexpress.c: Module autoprobe not recommended, give io=xx.
eexpress.c: Failed to register card at 0x0.
mii: no version magic, tainting kernel.
epic100: no version magic, tainting kernel.
epic100.c:v1.11 1/7/2001 Written by Donald Becker <becker@scyld.com>
  (unofficial 2.4.x kernel port, version 2.1, Sept 11, 2006)
qla3xxx: no version magic, tainting kernel.
sk98lin: no version magic, tainting kernel.
sk98lin: driver has been replaced by the skge driver and is scheduled for removal
mii: no version magic, tainting kernel.
e100: no version magic, tainting kernel.
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
sunhme: no version magic, tainting kernel.
tlan: no version magic, tainting kernel.
ThunderLAN driver v1.15
TLAN: 0 devices installed, PCI: 0  EISA: 0
mii: no version magic, tainting kernel.
sis190: no version magic, tainting kernel.
slhc: no version magic, tainting kernel.
8390: no version magic, tainting kernel.
wd: no version magic, tainting kernel.
wd.c: Presently autoprobing (not recommended) for a single card.
wd.c: No wd80x3 card found (i/o = 0x0).
typhoon: no version magic, tainting kernel.
forcedeth: no version magic, tainting kernel.
de620: no version magic, tainting kernel.
D-Link DE-620 pocket adapter not identified in the printer port
mii: no version magic, tainting kernel.
sis900: no version magic, tainting kernel.
sis900.c: v1.08.10 Apr. 2 2006
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
cdc_ether: no version magic, tainting kernel.
usbcore: registered new interface driver cdc_ether
rndis_host: no version magic, tainting kernel.
usbcore: registered new interface driver rndis_host
usbcore: deregistering interface driver rndis_host
usbcore: deregistering interface driver cdc_ether
kaweth: no version magic, tainting kernel.
/usr/src/linux-2.6.25-rc1/drivers/net/usb/kaweth.c: Driver loading
usbcore: registered new interface driver kaweth
usbcore: deregistering interface driver kaweth
mii: no version magic, tainting kernel.
pegasus: no version magic, tainting kernel.
pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new interface driver pegasus
usbcore: deregistering interface driver pegasus
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
plusb: no version magic, tainting kernel.
usbcore: registered new interface driver plusb
usbcore: deregistering interface driver plusb
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
cdc_ether: no version magic, tainting kernel.
usbcore: registered new interface driver cdc_ether
zaurus: no version magic, tainting kernel.
usbcore: registered new interface driver zaurus
usbcore: deregistering interface driver zaurus
usbcore: deregistering interface driver cdc_ether
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
asix: no version magic, tainting kernel.
usbcore: registered new interface driver asix
usbcore: deregistering interface driver asix
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
net1080: no version magic, tainting kernel.
usbcore: registered new interface driver net1080
usbcore: deregistering interface driver net1080
rtl8150: no version magic, tainting kernel.
/usr/src/linux-2.6.25-rc1/drivers/net/usb/rtl8150.c: rtl8150 based usb-ethernet driver v0.6.2 (2004/08/27)
usbcore: registered new interface driver rtl8150
usbcore: deregistering interface driver rtl8150
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
cdc_subset: no version magic, tainting kernel.
usbcore: registered new interface driver cdc_subset
usbcore: deregistering interface driver cdc_subset
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
gl620a: no version magic, tainting kernel.
usbcore: registered new interface driver gl620a
usbcore: deregistering interface driver gl620a
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
cdc_ether: no version magic, tainting kernel.
usbcore: registered new interface driver cdc_ether
usbcore: deregistering interface driver cdc_ether
mii: no version magic, tainting kernel.
usbnet: no version magic, tainting kernel.
dl2k: no version magic, tainting kernel.
ixgbe: no version magic, tainting kernel.
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 1.1.18
ixgbe: Copyright (c) 1999-2007 Intel Corporation.
lp486e: no version magic, tainting kernel.
eth%d: i82596 initialization timed out
ixgb: no version magic, tainting kernel.
Intel(R) PRO/10GbE Network Driver - version 1.0.126-k4
Copyright (c) 1999-2006 Intel Corporation.
r8169: no version magic, tainting kernel.
cxgb: no version magic, tainting kernel.
mii: no version magic, tainting kernel.
fealnx: no version magic, tainting kernel.
fealnx.c:v2.52 Sep-11-2006
mii: no version magic, tainting kernel.
r6040: no version magic, tainting kernel.
3c507: no version magic, tainting kernel.
8390: no version magic, tainting kernel.
hp: no version magic, tainting kernel.
hp.c: Presently autoprobing (not recommended) for a single card.
hp.c: No HP card found (i/o = 0x0).
acenic: no version magic, tainting kernel.
znet: no version magic, tainting kernel.
8390: no version magic, tainting kernel.
ne2k_pci: no version magic, tainting kernel.
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
Initializing USB Mass Storage driver...
usb-storage 5-2:1.0: usb_probe_interface
usb-storage 5-2:1.0: usb_probe_interface - got id
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
scsi 3:0:0:0: Direct-Access     Ativa    U3 smart 512MB   6.50 PQ: 0 ANSI: 0 CCS
sd 3:0:0:0: [sda] 984063 512-byte hardware sectors (504 MB)
sd 3:0:0:0: [sda] Write Protect is off
sd 3:0:0:0: [sda] Mode Sense: 45 00 00 08
sd 3:0:0:0: [sda] Assuming drive cache: write through
sd 3:0:0:0: [sda] 984063 512-byte hardware sectors (504 MB)
sd 3:0:0:0: [sda] Write Protect is off
sd 3:0:0:0: [sda] Mode Sense: 45 00 00 08
sd 3:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1
sd 3:0:0:0: [sda] Attached SCSI removable disk
sd 3:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
ReiserFS: sda1: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on sda1
VFS: Can't find ext3 filesystem on dev sda1.
cramfs: wrong magic

[-- Attachment #3: r61-interrupts-1.txt --]
[-- Type: text/plain, Size: 721 bytes --]

           CPU0
  0:         90   IO-APIC-edge      timer
  1:         33   IO-APIC-edge      i8042
  2:          0    XT-PIC-XT        cascade
 10:          0   IO-APIC-edge      ahci, uhci_hcd:usb5
 11:          0   IH-APIC-edge      ehci_hcd:usb1, ehci_hcd:usb2, uhci_hcd:usb3,uhci_hcd:usb4, uhci_hcd:usb6, uhci_hcd:usb7
 12:       2332   IO-APIC-edge      i8042
 14:        152   IO-APIC-edge      ide0
NMI:          0   Non-maskable interrupts
LOC:      95075   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

[-- Attachment #4: r61-interrupts-2.txt --]
[-- Type: text/plain, Size: 721 bytes --]

           CPU0
  0:         90   IO-APIC-edge      timer
  1:         39   IO-APIC-edge      i8042
  2:          0    XT-PIC-XT        cascade
 10:          0   IO-APIC-edge      ahci, uhci_hcd:usb5
 11:          0   IH-APIC-edge      ehci_hcd:usb1, ehci_hcd:usb2, uhci_hcd:usb3,uhci_hcd:usb4, uhci_hcd:usb6, uhci_hcd:usb7
 12:       2332   IO-APIC-edge      i8042
 14:        152   IO-APIC-edge      ide0
NMI:          0   Non-maskable interrupts
LOC:      97683   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

Re: USB regression (and other failures) in 2.6.2[45]*

[Alan Stern]

On Sat, 16 Feb 2008, Andrew Buehler wrote:

> > For another, getting two copies of a message is no big deal --
> 
> I disagree.

Everyone has his own taste.  Obviously there's no world-wide consensus,
possibly because different people have different workflow habits and so
are affected by duplicate messages to varying extents.

> When I receive a message sent directly to me in a discussion which is on
> a list, I expect that it is because someone either considered it
> important enough to warrant making certain it came to my attention
> specifically, or wanted to continue the discussion but felt that it
> should not continue to take place on the mailing list.

Sometimes that is the case but often it isn't.  Your expectations are
at variance with other people's behavior; you shouldn't expect everyone
else to change just to match your personal ideals.

On the other hand, I would be perfectly happy to edit your name out of 
the reply list -- but since you said you aren't receiving all the 
messages in this thread via the list that might not be a good thing to 
do at the moment...


> > People on LKML who are more familiar with interrupt routing problems
> > might be able to offer more help.  For now, you can try things like
> > turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting
> > the contents of /proc/interrupts (say before and after a new USB
> > device is plugged in).
> 
> In my current testing kernel, which I believe is the one with which I
> captured the sole successful non-2.6.23.1 dmesg so far, CONFIG_USB_DEBUG
> is on. The associated dmesg (obtained yesterday from booting with the
> Flash drive connected) is attached. (The flood of 'no version magic,
> tainting kernel' messages between line 600 and line 1160 are a side
> effect of Novell's custom environment which I have not yet made the
> effort to fix; the boot scripts attempt to detect the network card by
> modprobing every network driver available until they find one which
> works. Here, because the correct one fails, they wind up trying each one
> twice.)

The line saying:

> ehci_hcd 0000:00:1d.7: Unlink after no-IRQ?  Controller is probably using the wrong IRQ.

is an indication that interrupt routing is indeed not working right.  
Or possibly your EHCI controller isn't working.  You could try 
blacklisting or unloading ehci-hcd to see if that helps.  Of course 
then none of your USB devices would be able to run at high speed.

> I have transcribed the contents of /proc/interrupts both before and
> after plugging in the Flash drive I have been using for testing, and
> they are also attached. I have been as careful as I could to be sure
> that the contents of the attached 'r61-interrupts-[12].txt' files is the
> same as what was shown on the laptop, but cannot absolutely guarantee
> that I have not missed something. For the record, the '1' is from before
> connecting the drive, and the '2' is from after.

Notice that the interrupt count for IRQ 11 doesn't change when you plug 
in the device.  Obviously something is wrong there.

In fact, it's a little surprising that almost all the USB controllers
are routed to the same IRQ.  However this is beyond my area of 
expertise.  You could try posting a message on the linux-acpi mailing 
list; the people there should know a lot more about these issues.


> > Assuming that the 2.6.23 kernel works on your computer, you can go
> > the extreme route of installing git and doing a bisection to find the
> > first patch causing your difficulty.
> 
> That would require me to learn enough of how git works, as distinct from
> more traditional VCSes, to be able to use it with some confidence. This
> is not impossible - indeed I want to do it at some point - but for the
> time being I have no idea where to start, and indeed I am not especially
> clear on exactly what (from a user's perspective) the differences been
> git and e.g. CVS or Subversion are. I know that the entire concept
> relies around a lack of centralization, but I have not been able to get
> my head around what that means in a practical sense.

There are some excellent tutorials on the web, with detailed
explanations of how to do a bisection to track down a kernel bug.

Alan Stern

Re: USB regression (and other failures) in 2.6.2[45]*

[Andrew Buehler]

On 2/16/2008 6:11 PM, Alan Stern wrote:

> On Sat, 16 Feb 2008, Andrew Buehler wrote:
> 
>>> For another, getting two copies of a message is no big deal --
>> 
>> I disagree.
> 
> Everyone has his own taste.  Obviously there's no world-wide
> consensus, possibly because different people have different workflow
> habits and so are affected by duplicate messages to varying extents.

I am well aware that this particular point is opinion. I have had
justifications for and arguments in favor of it in the past, but none of
them come readily to mind at the moment, except for the one gone over
briefly below.

>> When I receive a message sent directly to me in a discussion which
>> is on a list, I expect that it is because someone either considered
>> it important enough to warrant making certain it came to my
>> attention specifically, or wanted to continue the discussion but
>> felt that it should not continue to take place on the mailing list.
>> 
> 
> Sometimes that is the case but often it isn't.  Your expectations are
> at variance with other people's behavior; you shouldn't expect
> everyone else to change just to match your personal ideals.

Messages sent to my address directly are explicitly not filtered into
the folders I have set up for various mailing lists, so that if someone
does send me a "heads up" reply for a specific topic on a list to which
I am subscribed it does not get caught by the list filter and fail to
come to my attention. If a message fails to be filtered into any
mailing-list folder, then I should be able to conclude that it is
specifically intended for me, and not part of normal mailing-list
traffic. The practice of sending replies to both addresses renders this
an invalid conclusion. I do not think that it is unreasonable to expect
that conclusion to be valid.

> On the other hand, I would be perfectly happy to edit your name out
> of the reply list -- but since you said you aren't receiving all the
> messages in this thread via the list that might not be a good thing
> to do at the moment...

It's not that I'm not receiving all of this thread's messages via the
list - it's that I'm not receiving *any* of them via the list, and I
suspect that the reason is that my address is in both the To:/Cc: and
the list itself. Something is filtering it such that I do not receive
"duplicate" replies in this way, but it is doing so by filtering out the
list copy rather than the direct copy. I have seen mailing lists which
do this before, but I see no other indication that the LKML is one of
them, and I would not be in the least surprised if this turned out to be
yet one more problem with gmail.

As far as I am aware, I am seeing all messages posted to the list which
do not have me in To: or Cc:. I suspect that if a reply in this thread
were posted to the list but not sent to me, I would see it on the list.
It might be worth an experiment, but since it would increase traffic for
other list members to no purpose it is probably not worth it overall.

>>> People on LKML who are more familiar with interrupt routing
>>> problems might be able to offer more help.  For now, you can try
>>> things like turning on CONFIG_USB_DEBUG, posting the output from
>>> dmesg, posting the contents of /proc/interrupts (say before and
>>> after a new USB device is plugged in).
>> 
>> In my current testing kernel, which I believe is the one with which
>> I captured the sole successful non-2.6.23.1 dmesg so far,
>> CONFIG_USB_DEBUG is on. The associated dmesg (obtained yesterday
>> from booting with the Flash drive connected) is attached. (The
>> flood of 'no version magic, tainting kernel' messages between line
>> 600 and line 1160 are a side effect of Novell's custom environment
>> which I have not yet made the effort to fix; the boot scripts
>> attempt to detect the network card by modprobing every network
>> driver available until they find one which works. Here, because the
>> correct one fails, they wind up trying each one twice.)
> 
> The line saying:
> 
>> ehci_hcd 0000:00:1d.7: Unlink after no-IRQ?  Controller is probably
>> using the wrong IRQ.
> 
> is an indication that interrupt routing is indeed not working right.
> Or possibly your EHCI controller isn't working.  You could try
> blacklisting or unloading ehci-hcd to see if that helps.  Of course
> then none of your USB devices would be able to run at high speed.

ehci-hcd is not modular in my current kernel, and if there is a way to
turn it off without its being modular I am not aware of it. I will have
to jump through a few hoops to be able to obtain a copy of the boot CD
with an updated kernel while not at work, but I will try to do so
sometime tomorrow.

In practical terms, I am frankly not especially bothered by the lack of
support for high-speed USB in Linux on this machine; the primary reason
I am interested in USB there at the moment, aside from a general
philosophy of "unsupported devices are bad and anything I can do to help
them become supported is good", is because getting it working would
allow me to easily get the necessary information out to be able to
properly report the other problems, with AHCI and networking.

>> I have transcribed the contents of /proc/interrupts both before and
>> after plugging in the Flash drive I have been using for testing,
>> and they are also attached. I have been as careful as I could to be
>> sure that the contents of the attached 'r61-interrupts-[12].txt'
>> files is the same as what was shown on the laptop, but cannot
>> absolutely guarantee that I have not missed something. For the
>> record, the '1' is from before connecting the drive, and the '2' is
>> from after.
> 
> Notice that the interrupt count for IRQ 11 doesn't change when you
> plug in the device.  Obviously something is wrong there.
> 
> In fact, it's a little surprising that almost all the USB controllers
> are routed to the same IRQ.  However this is beyond my area of
> expertise.  You could try posting a message on the linux-acpi mailing
> list; the people there should know a lot more about these issues.

Until this thread, I was not even aware that ACPI was related to USB; I
had largely conflated it with a similar acronym which I think is related
to power management and which I can suddenly not even find in my kernel
config. I will, however, look into linux-acpi.

>>> Assuming that the 2.6.23 kernel works on your computer, you can
>>> go the extreme route of installing git and doing a bisection to
>>> find the first patch causing your difficulty.
>> 
>> That would require me to learn enough of how git works, as distinct
>> from more traditional VCSes, to be able to use it with some
>> confidence. This is not impossible - indeed I want to do it at some
>> point - but for the time being I have no idea where to start, and
>> indeed I am not especially clear on exactly what (from a user's
>> perspective) the differences been git and e.g. CVS or Subversion
>> are. I know that the entire concept relies around a lack of
>> centralization, but I have not been able to get my head around what
>> that means in a practical sense.
> 
> There are some excellent tutorials on the web, with detailed
> explanations of how to do a bisection to track down a kernel bug.

I have found at least a place to start, and am reading up on the
subject. I will most likely not be able to make a practical start on
this until at least Tuesday, as not having direct access to the machine
I will in the long term be building on makes some things impractical,
but if no solution is forthcoming in the meantime I will expect to do this.

That will not be helpful for the other two problems, however, since
neither of them was ever working as far as I am aware. That also leaves
me hesitant to conclude that they are rooted in the same IRQ issue as
the USB problem appears to be.

Which lists or other addresses would be appropriate for reporting
problems with AHCI/libata and with networking, specifically with the
e1000/e1000e drivers? I see a mailing list for e1000 in MAINTAINERS, but
only the maintainer's address for SATA/libata/whatever else may be
involved there, and I am reflexively reluctant to bother a maintainer
directly with as little information as I presently have.

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]*

[Alan Stern]

On Sat, 16 Feb 2008, Andrew Buehler wrote:

> Messages sent to my address directly are explicitly not filtered into
> the folders I have set up for various mailing lists, so that if someone
> does send me a "heads up" reply for a specific topic on a list to which
> I am subscribed it does not get caught by the list filter and fail to
> come to my attention. If a message fails to be filtered into any
> mailing-list folder, then I should be able to conclude that it is
> specifically intended for me, and not part of normal mailing-list
> traffic. The practice of sending replies to both addresses renders this
> an invalid conclusion. I do not think that it is unreasonable to expect
> that conclusion to be valid.

It's not unreasonable.  Neither is Aristotelian physics.  Nevertheless, 
neither one is a good match to reality.

Why not arrange instead that messages sent from a mailing list server
_do_ get filtered into the corresponding folder, even if they were also
sent to your address?  This certainly should make your assumption (that
messages not filtered into any mailing-list folder are specifically
intended for you) much more valid than it is now.

> It's not that I'm not receiving all of this thread's messages via the
> list - it's that I'm not receiving *any* of them via the list, and I
> suspect that the reason is that my address is in both the To:/Cc: and
> the list itself. Something is filtering it such that I do not receive
> "duplicate" replies in this way, but it is doing so by filtering out the
> list copy rather than the direct copy. I have seen mailing lists which
> do this before, but I see no other indication that the LKML is one of
> them, and I would not be in the least surprised if this turned out to be
> yet one more problem with gmail.

Well, I _am_ receiving your messages by way of linux-usb as well as
directly, for whatever that's worth.


> > is an indication that interrupt routing is indeed not working right.
> > Or possibly your EHCI controller isn't working.  You could try
> > blacklisting or unloading ehci-hcd to see if that helps.  Of course
> > then none of your USB devices would be able to run at high speed.
> 
> ehci-hcd is not modular in my current kernel, and if there is a way to
> turn it off without its being modular I am not aware of it.

Go into the /sys/bus/pci/drivers/ehci_hcd directory.  Then for each 
symbolic link to a controller device listed there, write the device's 
name (with "echo -n") to the "unbind" file.  For example,

	echo -n 0000:00:1d.7 >unbind

That will have nearly the same effect as unloading ehci-hcd.

> Until this thread, I was not even aware that ACPI was related to USB; I
> had largely conflated it with a similar acronym which I think is related
> to power management and which I can suddenly not even find in my kernel
> config. I will, however, look into linux-acpi.

ACPI isn't directly related to USB; rather it has to do with
transferring information between the OS and the
BIOS/vendor-specific-hardware.  Power management is example where such
a transfer is needed.  In your case, the relevant information is which
IRQ is connected to which motherboard device.  If you don't have ACPI
enabled in your configuration, then perhaps that's the problem -- try
enabling it.

> That will not be helpful for the other two problems, however, since
> neither of them was ever working as far as I am aware. That also leaves
> me hesitant to conclude that they are rooted in the same IRQ issue as
> the USB problem appears to be.

Maybe they aren't.  But when you have multiple bugs, you have to fix
them one at a time.

> Which lists or other addresses would be appropriate for reporting
> problems with AHCI/libata and with networking, specifically with the
> e1000/e1000e drivers? I see a mailing list for e1000 in MAINTAINERS, but
> only the maintainer's address for SATA/libata/whatever else may be
> involved there, and I am reflexively reluctant to bother a maintainer
> directly with as little information as I presently have.

I don't know, but you should wait until the simpler problem is sorted 
out before tackling the more complicated ones.

Alan Stern

[OT] GMail (was USB regression (and other failures)...)

[Joseph Fannin]

On Sat, Feb 16, 2008 at 08:12:40PM -0500, Andrew Buehler wrote:
> [...] and I would not be in the least surprised if this turned out to
> be yet one more problem with gmail

It is; Gmail will refuse to POP more than one copy of a mail to you,
no matter how many copies it recieves via different paths.  Which copy
you get seems to be dependant on which arrives first, so you can't
even hope a mail exchange will consistently arrive in one mailbox or
another.

Note that this also applies to mails cross-posted to multiple lists
you maybe be suscribed to; this breaks threading fantastically.

Google is aware of the issue, and considers it a feature.  If you find
another free mail service which isn't so broken, I'd love to hear
about it.

---

That said, netiquette on the kernel lists is to *never* drop CC's.
Too much traffic crosses the lists for anyone to read it all and note
anything they might be interested and/or implicated in.  Never
dropping CC's allows busy people to keep track of conversations
they've taken part in or that someone thinks they should see
without the worry of missing any important parts of one.

Or at least it does if your mail system isn't broken.  We get what we
pay for.  :-/

--
Joseph Fannin
jfannin@gmail.com

Re: USB regression (and other failures) in 2.6.2[45]*

[Paul Jackson]

Andrew wrote:
> (Note: I consider it blatantly incorrect to send a reply both to a
> mailing list and directly to the address of someone who is subscribed to
> that list

Regardless of how you consider it, that is how responding to these big
lists -must- work.

There is no practical way for respondents to know, without spending at
a minimum several minutes of their time per reply, whether or not the
explicit receipients of a message are or are not also on one or more of
the receiving lists.

Do you really expect, Andrew, that I should examine the membership lists
of each of linux-scsi, linux-usb and linux-kernel (if they are even open
to the public) to see if you're subscribed to them, before responding to
a message addressed such as this?

As subscribers and submitters to such lists, we just have to learn to
deal with this reality.  For example, I receive an average of a 100
messages per hour on this email address, -after- my employers spam
filters have knocked off over 90% of the incoming.

May I recommend you become an expert in procmail?  That or speed
reading (and speed ignoring ;).

In a separate reply to this message, Alan Stern wrote:
> Everyone has his own taste.

This is not a matter of taste on these big lists.  There is no other
practical alternative.  Most of the burden of ultimate filtering must
be shifted to the recipients, and the senders asked only that they
err on the side of including every individual list or person already
on the address lists.

Joseph Fannin also replied:
> another free mail service which isn't so broken,

I'd recommend fastmail.fm as one of the least broken, most tech savvy
mail services.  I believe that their free side includes IMAP, though
not POP support.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: USB regression (and other failures) in 2.6.2[45]*

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Sat, Feb 16, 2008 at 04:33:41PM -0500, Andrew Buehler wrote:
> The associated dmesg (obtained yesterday from booting with the
> Flash drive connected) is attached.

This dmesg shows that ACPI is not enabled in your kernel config - most
likely this is the problem.  Try to enable it:

 1) In the "Power management options" submenu enable the "Power
    Management support" option (CONFIG_PM) - if this option is
    disabled, you will not see the option to enable ACPI below.

 2) In the same submenu enable the "ACPI (Advanced Configuration and
    Power Interface) Support" option (CONFIG_ACPI).

Without ACPI support the kernel can use legacy interrupt routing
tables from BIOS, but on new systems these tables are often broken due
to lack of testing (because all modern operating systems use ACPI
instead of these legacy tables).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: USB regression (and other failures) in 2.6.2[45]*

[Andrew Buehler]

On 2/17/2008 2:20 AM, Paul Jackson wrote:

> Andrew wrote:

(Since there are multiple Andrews on just the LKML, and at least two -
one of whom is much more prominent than I am - in the direct address
list for this discussion, I'm not sure whether or not this is a
sufficient attribution. If it works for you, though...)

>> (Note: I consider it blatantly incorrect to send a reply both to a
>> mailing list and directly to the address of someone who is
>> subscribed to that list
> 
> Regardless of how you consider it, that is how responding to these
> big lists -must- work.
> 
> There is no practical way for respondents to know, without spending
> at a minimum several minutes of their time per reply, whether or not
> the explicit receipients of a message are or are not also on one or
> more of the receiving lists.

As I have now acknowledged twice (and this makes three times), there
does not seem to be a practical way to avoid it in this instance. That
does not make it any less incorrect to send a duplicate private copy to
the person in question.

> Do you really expect, Andrew, that I should examine the membership
> lists of each of linux-scsi, linux-usb and linux-kernel (if they are
> even open to the public) to see if you're subscribed to them, before
> responding to a message addressed such as this?

Of course not.

> As subscribers and submitters to such lists, we just have to learn to
> deal with this reality. For example, I receive an average of a 100
> messages per hour on this email address, -after- my employers spam
> filters have knocked off over 90% of the incoming.
> 
> May I recommend you become an expert in procmail? That or speed
> reading (and speed ignoring ;).

AFAIRK (though I could be mistaken), procmail is not available under
Windows, which is what I have to use for work purposes. I have an
interest in learning it form my own purposes, but it is very much on the
back burner.

> In a separate reply to this message, Alan Stern wrote:
> 
>> Everyone has his own taste.
> 
> This is not a matter of taste on these big lists. There is no other
> practical alternative.

I'm not disputing that. I just consider it incorrect anyway.

> Joseph Fannin also replied:
> 
>> another free mail service which isn't so broken,
> 
> I'd recommend fastmail.fm as one of the least broken, most tech savvy
> mail services. I believe that their free side includes IMAP, though
> not POP support.

I'm not as fond of IMAP as I used to be, though I no longer remember
exactly why, but I thank you for the recommendation. When I have
opportunity I will check it out, though that will probably not be this
week. (I also thank Joseph for the confirmation that the problem does
lie with Gmail.)



And, since there is no longer anything specifically kernel-related in
this subthread, I do not intend to reply publicly in it again unless
requested to do so.

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]*

[Paul Jackson]

Andrew B wrote:
> Windows, which is what I have to use for work purposes.

aha -- my condolences ;)

Take care.  Your last reply made as much sense
as we're likely to make of this one.  Thanks.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: USB regression (and other failures) in 2.6.2[45]*

[Andrew Buehler]

On 2/16/2008 10:35 PM, Alan Stern wrote:

> On Sat, 16 Feb 2008, Andrew Buehler wrote:
> 
>> Messages sent to my address directly are explicitly not filtered
>> into the folders I have set up for various mailing lists, so that
>> if someone does send me a "heads up" reply for a specific topic on
>> a list to which I am subscribed it does not get caught by the list
>> filter and fail to come to my attention. If a message fails to be
>> filtered into any mailing-list folder, then I should be able to
>> conclude that it is specifically intended for me, and not part of
>> normal mailing-list traffic. The practice of sending replies to
>> both addresses renders this an invalid conclusion. I do not think
>> that it is unreasonable to expect that conclusion to be valid.
> 
> It's not unreasonable.  Neither is Aristotelian physics.
> Nevertheless, neither one is a good match to reality.
> 
> Why not arrange instead that messages sent from a mailing list server
> _do_ get filtered into the corresponding folder, even if they were
> also sent to your address?  This certainly should make your
> assumption (that messages not filtered into any mailing-list folder
> are specifically intended for you) much more valid than it is now.

Two reasons that I can think of off the top of my head.

One of them I mentioned above: because that precludes the possibility of
someone sending me a direct copy to draw my attention to something which
they think needs it, unless they send it separately from the list copy.
(This does not especially apply on the kernel-related mailing lists,
since no one is likely to think I am particularly worth drawing in to
any discussion there anytime soon, but it has come up elsewhere and the
basic principle is the same.)

The other is that this would lead to duplicate copies of the same reply
in the mailing list folder, which is ugly at best, especially with
respect to proper threading.

>> Until this thread, I was not even aware that ACPI was related to
>> USB; I had largely conflated it with a similar acronym which I
>> think is related to power management and which I can suddenly not
>> even find in my kernel config. I will, however, look into
>> linux-acpi.
> 
> ACPI isn't directly related to USB; rather it has to do with
> transferring information between the OS and the 
> BIOS/vendor-specific-hardware.  Power management is example where
> such a transfer is needed.  In your case, the relevant information is
> which IRQ is connected to which motherboard device.  If you don't
> have ACPI enabled in your configuration, then perhaps that's the
> problem -- try enabling it.

It is indeed not enabled, and when I check the config for the 2.6.23.1
kernel where USB works, I find that it is enabled there. I will test the
result of enabling it in the current kernel. If I don't have an answer
by the end of the day, I probably won't be able to get one until at
least Tuesday.

>> That will not be helpful for the other two problems, however, since
>> neither of them was ever working as far as I am aware. That also
>> leaves me hesitant to conclude that they are rooted in the same IRQ
>> issue as the USB problem appears to be.
> 
> Maybe they aren't.  But when you have multiple bugs, you have to fix
> them one at a time.

Oh, I agree - that is a large part of why I posted a "full" description
of only one problem initially, rather than all three in a single mail.

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Andrew Buehler]

On 2/16/2008 10:35 PM, Alan Stern wrote:

> On Sat, 16 Feb 2008, Andrew Buehler wrote:

>> Until this thread, I was not even aware that ACPI was related to
>> USB; I had largely conflated it with a similar acronym which I
>> think is related to power management and which I can suddenly not
>> even find in my kernel config. I will, however, look into
>> linux-acpi.
> 
> ACPI isn't directly related to USB; rather it has to do with
> transferring information between the OS and the
> BIOS/vendor-specific-hardware. Power management is example where such
> a transfer is needed. In your case, the relevant information is
> which IRQ is connected to which motherboard device. If you don't have
> ACPI enabled in your configuration, then perhaps that's the problem
> -- try enabling it.

Apparently it was the problem; enabling ACPI has fixed not only the USB
problem but also the network problem (somewhat miraculously, since I'm
quite certain that I had ACPI enabled in a 2.6.23.x kernel where the
network did not work despite an apparently matching driver).

I feel somewhat foolish for having reported a regression over what turns
out to have been a simple misconfiguration, but I still do think it's
somewhat misleading at best for something so potentially important to
completely non-power-related things to be buried under the heading of
power management... I would suggest moving it somewhere else in the
config and the dependencies, except that I have neither a suggestion for
a possible place nor any idea of how much actual work that would
involve.



With those two problems out of the way, what is left is the hard-drive
issue, and that is also halfway fixed by enabling ACPI. Specifically, it
is "fixed" in that the kernel sees the hard drive and I can mount it,
but it is not fixed in that the program we need to use in this
environment does not see the drive.

I have a config from a boot disc running 2.6.5 (that's not a typo) under
which the program in question *does* see the drive, but there are
massive differences between that config and the one I am using now, and
narrowing the critical difference down is likely to be somewhat
difficult - particularly since some of the "differences" are merely
renamed config symbols (i.e. the CONFIG_SCSI_SATA_*->CONFIG_SATA_*
switchover), and I have limited ability to tell which without intensive
investigation. Are there any established techniques for simplifying this
kind of comparison?

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Alan Stern]

On Tue, 19 Feb 2008, Andrew Buehler wrote:

> With those two problems out of the way, what is left is the hard-drive
> issue, and that is also halfway fixed by enabling ACPI. Specifically, it
> is "fixed" in that the kernel sees the hard drive and I can mount it,
> but it is not fixed in that the program we need to use in this
> environment does not see the drive.

What do you mean by "does not see the drive"?

> I have a config from a boot disc running 2.6.5 (that's not a typo) under
> which the program in question *does* see the drive, but there are
> massive differences between that config and the one I am using now, and
> narrowing the critical difference down is likely to be somewhat
> difficult - particularly since some of the "differences" are merely
> renamed config symbols (i.e. the CONFIG_SCSI_SATA_*->CONFIG_SATA_*
> switchover), and I have limited ability to tell which without intensive
> investigation. Are there any established techniques for simplifying this
> kind of comparison?

The only established technique is to run various kernels intermediate 
between the one that works and the one that fails.

Alan Stern

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Andrew Buehler]

(I suspect that some of the existing CC:s can now be dropped, and others
might need to be added if indeed this is worth discussing on kernel
lists at all, but I don't know what the protocol on that is so I have
left all of them in for the moment.)

On 2/20/2008 10:50 AM, Alan Stern wrote:

> On Tue, 19 Feb 2008, Andrew Buehler wrote:
> 
>> With those two problems out of the way, what is left is the
>> hard-drive issue, and that is also halfway fixed by enabling ACPI.
>> Specifically, it is "fixed" in that the kernel sees the hard drive
>> and I can mount it, but it is not fixed in that the program we need
>> to use in this environment does not see the drive.
> 
> What do you mean by "does not see the drive"?

Its detect-hardware-and-report mode shows a HD size of 0 (which is what
it has showed in cases where the kernel has not detected the drive), its
detect-partitions-and-report mode shows no partitions and no devices
which can have partitions, and attempting to actually use it to pull
down a drive image (it's a disk-imaging program) causes it to hang at
the point where it would begin to write.

Hmm. One thing which just sprang to mind, in the stab-in-the-dark
category: in 2.6.24.2, launching the program on some machines gave
warnings along the lines of "this program is using a deprecated ioctl,
please convert it to SG_IO" (which I naturally cannot do since it's
closed and I don't have the source), but IIRC in the 2.5.25-rc2-based
disc with ACPI enabled no such message appears. If the reason that there
are no longer such messages is that the ioctl in question has now been
removed, that might explain why the program does not see the drive.

I have suspected that I might eventually need to port the old interface
forwards to be able to continue to use this program, but I did not
expect it to happen this soon...

>> I have a config from a boot disc running 2.6.5 (that's not a typo)
>> under which the program in question *does* see the drive, but there
>> are massive differences between that config and the one I am using
>> now, and narrowing the critical difference down is likely to be
>> somewhat difficult - particularly since some of the "differences"
>> are merely renamed config symbols (i.e. the
>> CONFIG_SCSI_SATA_*->CONFIG_SATA_* switchover), and I have limited
>> ability to tell which without intensive investigation. Are there
>> any established techniques for simplifying this kind of comparison?
> 
> The only established technique is to run various kernels intermediate
> between the one that works and the one that fails.

I'm not sure I expressed myself clearly. I do not think the problem is
with the different kernels. I think the problem is with the different
configurations. I am asking if there are any established techniques for
comparing differences between config files from widely different
kernels.

Or, if you're suggesting running various kernels with configs which are
hybrids of the config which works and the current one which does not: in
order to do that I have to be able to tell what the actual differences
are, and at minimum the renamed symbols (not all of which I expect to be
able to identify at a glance) would make that quite difficult to do, so
I remain with the same problem and the same question.

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Alan Stern]

On Wed, 20 Feb 2008, Andrew Buehler wrote:

> > What do you mean by "does not see the drive"?
> 
> Its detect-hardware-and-report mode shows a HD size of 0 (which is what
> it has showed in cases where the kernel has not detected the drive), its
> detect-partitions-and-report mode shows no partitions and no devices
> which can have partitions, and attempting to actually use it to pull
> down a drive image (it's a disk-imaging program) causes it to hang at
> the point where it would begin to write.
> 
> Hmm. One thing which just sprang to mind, in the stab-in-the-dark
> category: in 2.6.24.2, launching the program on some machines gave
> warnings along the lines of "this program is using a deprecated ioctl,
> please convert it to SG_IO" (which I naturally cannot do since it's
> closed and I don't have the source),

You can ask the program's author to update it.

> but IIRC in the 2.5.25-rc2-based
> disc with ACPI enabled no such message appears. If the reason that there
> are no longer such messages is that the ioctl in question has now been
> removed, that might explain why the program does not see the drive.

Could be.  You can use strace to find out what system calls the program 
is making.


> I'm not sure I expressed myself clearly. I do not think the problem is
> with the different kernels. I think the problem is with the different
> configurations. I am asking if there are any established techniques for
> comparing differences between config files from widely different
> kernels.

Not as far as I know.

Alan Stern

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Andrew Buehler]

On 2/20/2008 12:15 PM, Alan Stern wrote:

> On Wed, 20 Feb 2008, Andrew Buehler wrote:

>> Hmm. One thing which just sprang to mind, in the stab-in-the-dark
>> category: in 2.6.24.2, launching the program on some machines gave
>> warnings along the lines of "this program is using a deprecated
>> ioctl, please convert it to SG_IO" (which I naturally cannot do
>> since it's closed and I don't have the source),
> 
> You can ask the program's author to update it.

It's provided by Novell, with whom I have no direct contact and am not
presently authorized to speak on behalf of my organization. From what I
have read about the history of their support on this program and these
discs, I do not expect that they would be willing to support it except
in environments which they provide in monolithic form; it would be
possible for me to copy an updated version of the program out of such an
environment to use in my own customized one, but I am not certain that
they have even created such an updated version, and in any case
obtaining it would almost certainly require buying the latest version of
Novell ZENworks - which my organization is certainly not prepared to do
at the present time.

In other words: I don't think that's likely to be practical in the
present instance. If you have reason to believe otherwise (past positive
experience with Novell, for instance), I'd be glad to hear it.

>> I'm not sure I expressed myself clearly. I do not think the problem
>> is with the different kernels. I think the problem is with the
>> different configurations. I am asking if there are any established
>> techniques for comparing differences between config files from
>> widely different kernels.
> 
> Not as far as I know.

Oh, well... thanks anyway.

Is there any place (aside from maybe the kernel changelog, which
contains a whole lot - if not several lots - of unrelated information)
where I could find a list of config-symbol name additions, changes,
deletions and meaning changes by version or by date? That would at least
let me build a mapping between the symbols in the older config and the
ones in the new one, which is about where I would have to start.

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Alan Stern]

On Wed, 20 Feb 2008, Andrew Buehler wrote:

> In other words: I don't think that's likely to be practical in the
> present instance. If you have reason to believe otherwise (past positive
> experience with Novell, for instance), I'd be glad to hear it.

Greg KH may be able to help in that respect.

> Is there any place (aside from maybe the kernel changelog, which
> contains a whole lot - if not several lots - of unrelated information)
> where I could find a list of config-symbol name additions, changes,
> deletions and meaning changes by version or by date? That would at least
> let me build a mapping between the symbols in the older config and the
> ones in the new one, which is about where I would have to start.

Not as far as I know.

Alan Stern

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Andrew Buehler]

On 2/20/2008 2:29 PM, Alan Stern wrote:

> On Wed, 20 Feb 2008, Andrew Buehler wrote:
> 
>> In other words: I don't think that's likely to be practical in the
>> present instance. If you have reason to believe otherwise (past
>> positive experience with Novell, for instance), I'd be glad to hear
>> it.
> 
> Greg KH may be able to help in that respect.

I know he's in the CC:, but I'm not sure he's reading this thread, and
I'm hesitant to bother people about things out of the blue unless I have
reason to expect that it's something they're going to care about. (Just
because it's a big deal for me doesn't mean it makes one whit of
difference to anyone else, and from what little I've seen on
linux-kernel he seems to be somewhat important and fairly busy...)

>> Is there any place (aside from maybe the kernel changelog, which
>> contains a whole lot - if not several lots - of unrelated
>> information) where I could find a list of config-symbol name
>> additions, changes, deletions and meaning changes by version or by
>> date? That would at least let me build a mapping between the
>> symbols in the older config and the ones in the new one, which is
>> about where I would have to start.
> 
> Not as far as I know.

Then I suppose I'm reduced to browsing the Kconfig files, reading old
changelogs, and trying a lot of different configs... thanks anyway.

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Alan Stern]

On Thu, 21 Feb 2008, Andrew Buehler wrote:

> On 2/20/2008 2:29 PM, Alan Stern wrote:
> 
> > On Wed, 20 Feb 2008, Andrew Buehler wrote:
> > 
> >> In other words: I don't think that's likely to be practical in the
> >> present instance. If you have reason to believe otherwise (past
> >> positive experience with Novell, for instance), I'd be glad to hear
> >> it.
> > 
> > Greg KH may be able to help in that respect.
> 
> I know he's in the CC:, but I'm not sure he's reading this thread, and
> I'm hesitant to bother people about things out of the blue unless I have
> reason to expect that it's something they're going to care about. (Just
> because it's a big deal for me doesn't mean it makes one whit of
> difference to anyone else, and from what little I've seen on
> linux-kernel he seems to be somewhat important and fairly busy...)

In this case you shouldn't worry about it.  I don't know whether Greg
has been following this thread either, but I do know that he spends a
lot of time and effort trying to improve vendors' support for Linux.  
This is right up his alley.  What I'm not sure about is the extent of
his influence over Novell...

Alan Stern

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Greg KH]

On Thu, Feb 21, 2008 at 11:36:23AM -0500, Alan Stern wrote:
> On Thu, 21 Feb 2008, Andrew Buehler wrote:
> 
> > On 2/20/2008 2:29 PM, Alan Stern wrote:
> > 
> > > On Wed, 20 Feb 2008, Andrew Buehler wrote:
> > > 
> > >> In other words: I don't think that's likely to be practical in the
> > >> present instance. If you have reason to believe otherwise (past
> > >> positive experience with Novell, for instance), I'd be glad to hear
> > >> it.
> > > 
> > > Greg KH may be able to help in that respect.
> > 
> > I know he's in the CC:, but I'm not sure he's reading this thread, and
> > I'm hesitant to bother people about things out of the blue unless I have
> > reason to expect that it's something they're going to care about. (Just
> > because it's a big deal for me doesn't mean it makes one whit of
> > difference to anyone else, and from what little I've seen on
> > linux-kernel he seems to be somewhat important and fairly busy...)
> 
> In this case you shouldn't worry about it.  I don't know whether Greg
> has been following this thread either, but I do know that he spends a
> lot of time and effort trying to improve vendors' support for Linux.  
> This is right up his alley.  What I'm not sure about is the extent of
> his influence over Novell...

Heh, yes, I've been reading this.

It sounds like an old version of a Novell product is making a newer
kernel spit out a warning message.  Odds are this is fixed in a newer
one, as well as the basic issue that Novell doesn't even ship anything
based on the 2.6.24 kernel yet, so perhaps the Zenworks developers don't
even know of the issue, that's what bugzilla.novell.com is for :)

thanks,

greg k-h

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Andrew Buehler]

On 2/21/2008 12:17 PM, Greg KH wrote:

> On Thu, Feb 21, 2008 at 11:36:23AM -0500, Alan Stern wrote:
> 
>> On Thu, 21 Feb 2008, Andrew Buehler wrote:

[Greg KH]
>>> I know he's in the CC:, but I'm not sure he's reading this
>>> thread, and I'm hesitant to bother people about things out of the
>>> blue unless I have reason to expect that it's something they're
>>> going to care about. (Just because it's a big deal for me doesn't
>>> mean it makes one whit of difference to anyone else, and from
>>> what little I've seen on linux-kernel he seems to be somewhat
>>> important and fairly busy...)
>> 
>> In this case you shouldn't worry about it.  I don't know whether
>> Greg has been following this thread either, but I do know that he
>> spends a lot of time and effort trying to improve vendors' support
>> for Linux. This is right up his alley.  What I'm not sure about is
>> the extent of his influence over Novell...
> 
> Heh, yes, I've been reading this.
> 
> It sounds like an old version of a Novell product is making a newer
> kernel spit out a warning message.

Originally that was all that it was, but now I am seeing the product in
question not even see the hard drive despite the fact that it is
mountable with standard utilities. Whether the failure is in the program
or elsewhere I don't know, but I'm hoping it's in the program, because
if it's elsewhere I have a *lot* of tedious digging and testing ahead of
me and little real idea of where to start.

> Odds are this is fixed in a newer one,

I haven't been able to find a newer version of the program, and do not
have the standing with my organization to contact Novell on their
behalf. (When I brought the idea up with the people who do have such
standing, in another context, the answer I received was essentially
"wait until we upgrade the servers to that version, which will not be
soon".) I also have not been able to find a clear contact path in any
case.

> as well as the basic issue that Novell doesn't even ship anything
> based on the 2.6.24 kernel yet, so perhaps the Zenworks developers
> don't even know of the issue, that's what bugzilla.novell.com is for
> :)

The problem has been present at least since 2.6.23.x and I think since
2.6.18, but from what I've been able to find Novell's last kernel was
based on 2.6.16.

I didn't even know there *was* a bugzilla.novell.com - and I've been
digging around Novell's site (and Googling around it from outside) for
what seems to me like quite a while. From the looks of things, however,
they don't have a category for ZENworks or for imaging, and the Linux
I'm using is not one of the SUSE-based distros they do list. (The
environment on the boot disc itself doesn't really qualify as any kind
of distro at all.)

Unfortunately, from what I've seen elsewhere it looks as if they are A:
not interested in supporting use any Linux except for their own SUSE for
this purpose and B: not likely to be open to supporting or even helping
with a customized environment; all of their technical documentation on
the subject is geared towards adding files and drivers to their existing
environment, not to replacing the entire kernel of that environment or
working with the results. Given that I'm building complete replacement
kernels and customizing rather a number of other things in the end
product, I'm rather inclined to suspect that even if I got into contact
with them about this they would say something to the effect of "since
you're not using our official environment, we won't/can't spend time and
effort trying to help you".

-- 
    Andrew Buehler

Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

[Alan Stern]

On Thu, 21 Feb 2008, Andrew Buehler wrote:

> > It sounds like an old version of a Novell product is making a newer
> > kernel spit out a warning message.
> 
> Originally that was all that it was, but now I am seeing the product in
> question not even see the hard drive despite the fact that it is
> mountable with standard utilities. Whether the failure is in the program
> or elsewhere I don't know, but I'm hoping it's in the program, because
> if it's elsewhere I have a *lot* of tedious digging and testing ahead of
> me and little real idea of where to start.

You could start by running the program under strace.  That should give 
you a good idea of where the problem begins.

Alan Stern