Re: 2.6.15-mm3

Re: 2.6.15-mm3

[Andrew Morton]

Reuben Farrelly <reuben-lkml-MwA23MxOyI4@public.gmane.org> wrote:
>
> 
> 
> On 12/01/2006 1:21 a.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15/2.6.15-mm3/
> > 
> > - New config options (VMSPLIT_*) to permit non-standard user/kernel
> >   splitting on x86.  Needs testing please.
> > 
> > - Lots of updates to the USB, PCI, driver and I2C trees.  This is usually a
> >   worry.
> > 
> > - Multiblock allocation speedup for ext3.  This is only used by direct-IO at
> >   present.
> > 
> > - Reminder: -mm kernel commit activity can be reviewed by subscribing to the
> >   mm-commits mailing list.
> > 
> >   echo "subscribe mm-commits" | mail marordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > 
> > - If you hit a bug in -mm and it's not obvious which patch caused it, it is
> >   most valuable if you can perform a bisection search to identify which patch
> >   introduced the bug.  Instructions for this process are at
> > 
> > 	http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
> > 
> >   But beware that this process takes some time (around ten rebuilds and
> >   reboots), so consider reporting the bug first and if we cannot immediately
> >   identify the faulty patch, then perform the bisection search.
> 
> I'm not sure if this is new to -mm3, but it's the first time I have seen it.
> 
> The sequence of events leading up to this was to reboot the machine, it came up 
> and crashed:
> 
> Call Trace:
>   [<c0103c5d>] show_stack+0x9b/0xc0
>   [<c0103de4>] show_registers+0x162/0x1e7
>   [<c0103f8f>] die+0x126/0x231
>   [<c01140db>] do_page_fault+0x271/0x5b9
>   [<c01037df>] error_code+0x4f/0x54
>   [<c023cabd>] class_device_del+0xa3/0x156
>   [<c023cb7b>] class_device_unregister+0xb/0x15
>   [<c0255dbf>] scsi_remove_host+0xb4/0xef
> 

There's some trace missing here.  I assume it's the same ata_device_add()
thing.

> uhci_hcd 0000:00:1d.2: irq 185, io base 0x0000d400
> usb usb4: configuration #1 chosen from 1 choice
> hub 4-0:1.0: USB hub found
> hub 4-0:1.0: 2 ports detected
> ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 169
> uhci_hcd 0000:00:1d.3: UHCI Host Controller
> uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
> uhci_hcd 0000:00:1d.3: irq 169, io base 0x0000d800
> usb usb5: configuration #1 chosen from 1 choice
> hub 5-0:1.0: USB hub found
> hub 5-0:1.0: 2 ports detected
> Initializing USB Mass Storage driver...
> irq 193: nobody cared (try booting with the "irqpoll" option)
>   [<c01041d9>] dump_stack+0x17/0x19
>   [<c0139f47>] __report_bad_irq+0x27/0x83
>   [<c013a021>] note_interrupt+0x7e/0x21d
>   [<c0139af4>] __do_IRQ+0xd3/0xef
>   [<c0105038>] do_IRQ+0x3d/0x57
>   =======================
>   [<c0103686>] common_interrupt+0x1a/0x20
>   [<c0101bc4>] cpu_idle+0x63/0x78
>   [<c0100615>] rest_init+0x23/0x2e
>   [<c03d070f>] start_kernel+0x2ca/0x34b
>   [<c0100210>] 0xc0100210
> handlers:
> [<c027017e>] (usb_hcd_irq+0x0/0x56)
> Disabling IRQ #193

USB lost its interrupt.  Could be USB, more likely ACPI.

> md: Autodetecting RAID arrays.
> md: autorun ...
> md: ... autorun DONE.
> ReiserFS: md0: warning: sh-2006: read_super_block: bread failed (dev md0, block 
> 2, size 4096)
> ReiserFS: md0: warning: sh-2006: read_super_block: bread failed (dev md0, block 
> 16, size 4096)
> EXT3-fs: unable to read superblock
> EXT2-fs: unable to read superblock
> isofs_fill_super: bread failed, dev=md0, iso_blknum=16, block=32
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0)
> 

Looks like RAID0 keeled over.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.15-mm3

[Reuben Farrelly]

On 12/01/2006 5:33 p.m., Andrew Morton wrote:
> Reuben Farrelly <reuben-lkml-MwA23MxOyI4@public.gmane.org> wrote:
>>
>>
>> On 12/01/2006 1:21 a.m., Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15/2.6.15-mm3/
>>>
>>> - New config options (VMSPLIT_*) to permit non-standard user/kernel
>>>   splitting on x86.  Needs testing please.
>>>
>>> - Lots of updates to the USB, PCI, driver and I2C trees.  This is usually a
>>>   worry.
>>>
>>> - Multiblock allocation speedup for ext3.  This is only used by direct-IO at
>>>   present.
>>>
>>> - Reminder: -mm kernel commit activity can be reviewed by subscribing to the
>>>   mm-commits mailing list.
>>>
>>>   echo "subscribe mm-commits" | mail marordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>
>>> - If you hit a bug in -mm and it's not obvious which patch caused it, it is
>>>   most valuable if you can perform a bisection search to identify which patch
>>>   introduced the bug.  Instructions for this process are at
>>>
>>> 	http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
>>>
>>>   But beware that this process takes some time (around ten rebuilds and
>>>   reboots), so consider reporting the bug first and if we cannot immediately
>>>   identify the faulty patch, then perform the bisection search.
>> I'm not sure if this is new to -mm3, but it's the first time I have seen it.
>>
>> The sequence of events leading up to this was to reboot the machine, it came up 
>> and crashed:
>>
>> Call Trace:
>>   [<c0103c5d>] show_stack+0x9b/0xc0
>>   [<c0103de4>] show_registers+0x162/0x1e7
>>   [<c0103f8f>] die+0x126/0x231
>>   [<c01140db>] do_page_fault+0x271/0x5b9
>>   [<c01037df>] error_code+0x4f/0x54
>>   [<c023cabd>] class_device_del+0xa3/0x156
>>   [<c023cb7b>] class_device_unregister+0xb/0x15
>>   [<c0255dbf>] scsi_remove_host+0xb4/0xef
>>
> 
> There's some trace missing here.  I assume it's the same ata_device_add()
> thing.

Correct.  I included it to suggest a possible link with the other ATA problems I 
am having and to show it's a separate report.

The important bit in this report was the SATA timing out - which it should not 
be doing.  There are three disks all hooked up and (most of the time) working. 
Box is locked in a cabinet so it's not like any hardware had mysteriously come 
loose or been bumped.

>> uhci_hcd 0000:00:1d.2: irq 185, io base 0x0000d400
>> usb usb4: configuration #1 chosen from 1 choice
>> hub 4-0:1.0: USB hub found
>> hub 4-0:1.0: 2 ports detected
>> ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 169
>> uhci_hcd 0000:00:1d.3: UHCI Host Controller
>> uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
>> uhci_hcd 0000:00:1d.3: irq 169, io base 0x0000d800
>> usb usb5: configuration #1 chosen from 1 choice
>> hub 5-0:1.0: USB hub found
>> hub 5-0:1.0: 2 ports detected
>> Initializing USB Mass Storage driver...
>> irq 193: nobody cared (try booting with the "irqpoll" option)
>>   [<c01041d9>] dump_stack+0x17/0x19
>>   [<c0139f47>] __report_bad_irq+0x27/0x83
>>   [<c013a021>] note_interrupt+0x7e/0x21d
>>   [<c0139af4>] __do_IRQ+0xd3/0xef
>>   [<c0105038>] do_IRQ+0x3d/0x57
>>   =======================
>>   [<c0103686>] common_interrupt+0x1a/0x20
>>   [<c0101bc4>] cpu_idle+0x63/0x78
>>   [<c0100615>] rest_init+0x23/0x2e
>>   [<c03d070f>] start_kernel+0x2ca/0x34b
>>   [<c0100210>] 0xc0100210
>> handlers:
>> [<c027017e>] (usb_hcd_irq+0x0/0x56)
>> Disabling IRQ #193
> 
> USB lost its interrupt.  Could be USB, more likely ACPI.
> 
>> md: Autodetecting RAID arrays.
>> md: autorun ...
>> md: ... autorun DONE.
>> ReiserFS: md0: warning: sh-2006: read_super_block: bread failed (dev md0, block 
>> 2, size 4096)
>> ReiserFS: md0: warning: sh-2006: read_super_block: bread failed (dev md0, block 
>> 16, size 4096)
>> EXT3-fs: unable to read superblock
>> EXT2-fs: unable to read superblock
>> isofs_fill_super: bread failed, dev=md0, iso_blknum=16, block=32
>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0)
>>
> 
> Looks like RAID0 keeled over.

md0 is the root partition, I assume because the SATA crapped out the box was 
unable to assemble the raid arrays, find root on md0 and so it panic'd.

reuben

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.15-mm3 [USB lost interrupt bug]

[Reuben Farrelly]

On 12/01/2006 5:33 p.m., Andrew Morton wrote:

>> hub 5-0:1.0: USB hub found
>> hub 5-0:1.0: 2 ports detected
>> Initializing USB Mass Storage driver...
>> irq 193: nobody cared (try booting with the "irqpoll" option)
>>   [<c01041d9>] dump_stack+0x17/0x19
>>   [<c0139f47>] __report_bad_irq+0x27/0x83
>>   [<c013a021>] note_interrupt+0x7e/0x21d
>>   [<c0139af4>] __do_IRQ+0xd3/0xef
>>   [<c0105038>] do_IRQ+0x3d/0x57
>>   =======================
>>   [<c0103686>] common_interrupt+0x1a/0x20
>>   [<c0101bc4>] cpu_idle+0x63/0x78
>>   [<c0100615>] rest_init+0x23/0x2e
>>   [<c03d070f>] start_kernel+0x2ca/0x34b
>>   [<c0100210>] 0xc0100210
>> handlers:
>> [<c027017e>] (usb_hcd_irq+0x0/0x56)
>> Disabling IRQ #193
> 
> USB lost its interrupt.  Could be USB, more likely ACPI.

I've seen this one happen nearly every boot since then including bootups that 
are otherwise OK (no oopses), so it's probably worth more looking into rather 
than being written off as a 'once off':

uhci_hcd 0000:00:1d.3: Unlink after no-IRQ?  Controller is probably using the 
wrong IRQ.

Details:

dmesg-

ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 169, io base 0x0000d800


lspci -vv

00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
USB UHCI #4 (rev 03) (prog-if 00 [UHCI])
         Subsystem: Intel Corporation Unknown device 4356
         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 0
         Interrupt: pin D routed to IRQ 169
         Region 4: I/O ports at d800 [size=32]


It's a new regression to -mm3.

For the ACPI people - I can't test with ACPI off because the machine won't boot 
without ACPI :(  [see 
http://www.ussg.iu.edu/hypermail/linux/kernel/0601.1/0044.html for what happens 
with acpi=off].
I'm not even sure if inability to boot with acpi=off is a bug or not - would 
appreciate if someone can let me know.

reuben
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Alan Stern]

On Thu, 12 Jan 2006, Reuben Farrelly wrote:

> >> Initializing USB Mass Storage driver...
> >> irq 193: nobody cared (try booting with the "irqpoll" option)

> >> handlers:
> >> [<c027017e>] (usb_hcd_irq+0x0/0x56)
> >> Disabling IRQ #193
> > 
> > USB lost its interrupt.  Could be USB, more likely ACPI.
> 
> I've seen this one happen nearly every boot since then including bootups that 
> are otherwise OK (no oopses), so it's probably worth more looking into rather 
> than being written off as a 'once off':
> 
> uhci_hcd 0000:00:1d.3: Unlink after no-IRQ?  Controller is probably using the 
> wrong IRQ.

> It's a new regression to -mm3.

Did the same IRQ get assigned to that controller in earlier kernel 
versions?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Reuben Farrelly]

On 13/01/2006 4:53 a.m., Alan Stern wrote:
> On Thu, 12 Jan 2006, Reuben Farrelly wrote:
> 
>>>> Initializing USB Mass Storage driver...
>>>> irq 193: nobody cared (try booting with the "irqpoll" option)
> 
>>>> handlers:
>>>> [<c027017e>] (usb_hcd_irq+0x0/0x56)
>>>> Disabling IRQ #193
>>> USB lost its interrupt.  Could be USB, more likely ACPI.
>> I've seen this one happen nearly every boot since then including bootups that 
>> are otherwise OK (no oopses), so it's probably worth more looking into rather 
>> than being written off as a 'once off':
>>
>> uhci_hcd 0000:00:1d.3: Unlink after no-IRQ?  Controller is probably using the 
>> wrong IRQ.
> 
>> It's a new regression to -mm3.
> 
> Did the same IRQ get assigned to that controller in earlier kernel 
> versions?
> 
> Alan Stern

Hi Alan,

If it's any use, here's some simply and easy-to-get information which may even 
be what you are looking for:

[root@tornado dovecot]# uname -a
Linux tornado.reub.net 2.6.15-mm1 #1 SMP Sun Jan 8 03:42:25 NZDT 2006 i686 i686 
i386 GNU/Linux
[root@tornado ~]# cat /proc/interrupts
            CPU0       CPU1
   0:   21638510          0    IO-APIC-edge  timer
   4:        356          0    IO-APIC-edge  serial
   8:          1          0    IO-APIC-edge  rtc
   9:          0          0   IO-APIC-level  acpi
  14:          1          0    IO-APIC-edge  ide0
  50:          3          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
169:        120          0   IO-APIC-level  uhci_hcd:usb5
177:    2837992          0   IO-APIC-level  sky2
185:      61450          0   IO-APIC-level  uhci_hcd:usb4, serial
193:    4722447          0   IO-APIC-level  libata, uhci_hcd:usb3
NMI:          0          0
LOC:   21638418   21638338
ERR:          0
MIS:          0
[root@tornado ~]#
[root@tornado ~]# lspci
00:00.0 Host bridge: Intel Corporation 925X/XE Memory Controller Hub (rev 04)
00:01.0 PCI bridge: Intel Corporation 925X/XE PCI Express Root Port (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI 
Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI 
Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI 
Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI 
Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface 
Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE 
Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA 
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus 
Controller (rev 03)
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8050 PCI-E ASF 
Gigabit Ethernet Controller (rev 17)
06:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] 
(rev 01)
06:02.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) 
(rev 01)
[root@tornado ~]#

I guess this looks like it was assigned the same IRQ ?

Currently booted into -mm1 which is OK and hasn't shown any nasty symptoms yet.

Reuben




-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Alan Stern]

On Mon, 16 Jan 2006, Reuben Farrelly wrote:

> On 13/01/2006 4:53 a.m., Alan Stern wrote:
> > On Thu, 12 Jan 2006, Reuben Farrelly wrote:
> > 
> >>>> Initializing USB Mass Storage driver...
> >>>> irq 193: nobody cared (try booting with the "irqpoll" option)
> > 
> >>>> handlers:
> >>>> [<c027017e>] (usb_hcd_irq+0x0/0x56)
> >>>> Disabling IRQ #193
> >>> USB lost its interrupt.  Could be USB, more likely ACPI.
> >> I've seen this one happen nearly every boot since then including bootups that 
> >> are otherwise OK (no oopses), so it's probably worth more looking into rather 
> >> than being written off as a 'once off':
> >>
> >> uhci_hcd 0000:00:1d.3: Unlink after no-IRQ?  Controller is probably using the 
> >> wrong IRQ.

Note the PCI ID is 1d.3 and the IRQ is 193.

> Hi Alan,
> 
> If it's any use, here's some simply and easy-to-get information which may even 
> be what you are looking for:
> 
> [root@tornado dovecot]# uname -a
> Linux tornado.reub.net 2.6.15-mm1 #1 SMP Sun Jan 8 03:42:25 NZDT 2006 i686 i686 
> i386 GNU/Linux
> [root@tornado ~]# cat /proc/interrupts
>             CPU0       CPU1
>    0:   21638510          0    IO-APIC-edge  timer
>    4:        356          0    IO-APIC-edge  serial
>    8:          1          0    IO-APIC-edge  rtc
>    9:          0          0   IO-APIC-level  acpi
>   14:          1          0    IO-APIC-edge  ide0
>   50:          3          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
> 169:        120          0   IO-APIC-level  uhci_hcd:usb5
> 177:    2837992          0   IO-APIC-level  sky2
> 185:      61450          0   IO-APIC-level  uhci_hcd:usb4, serial
> 193:    4722447          0   IO-APIC-level  libata, uhci_hcd:usb3

Note that in the earlier kernel, IRQ 193 is assigned to usb3.  That's the 
second UHCI controller, since usb1 is EHCI.

> [root@tornado ~]# lspci

> 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
> USB UHCI #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
> USB UHCI #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
> USB UHCI #3 (rev 03)
> 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
> USB UHCI #4 (rev 03)
> 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
> USB2 EHCI Controller (rev 03)

Note that 1d.3 is the fourth UHCI controller; the second is 1d.1.

> I guess this looks like it was assigned the same IRQ ?

I don't think so.  To be certain you'd have to check the boot-up log and
verify that 1d.1 is usb3 and 1d.3 is usb5.

>From the information presented here, it looks like -mm1 correctly routes
the 1d.1 controller to IRQ 193 and the 1d.3 controller to IRQ 169, whereas
-mm3 incorrectly routes the 1d.3 controller to IRQ 193.  That would make 
it an ACPI problem.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Reuben Farrelly]

On 16/01/2006 4:22 p.m., Alan Stern wrote:
> On Mon, 16 Jan 2006, Reuben Farrelly wrote:
> 
>> On 13/01/2006 4:53 a.m., Alan Stern wrote:
>>> On Thu, 12 Jan 2006, Reuben Farrelly wrote:
>>>
>>>>>> Initializing USB Mass Storage driver...
>>>>>> irq 193: nobody cared (try booting with the "irqpoll" option)
>>>>>> handlers:
>>>>>> [<c027017e>] (usb_hcd_irq+0x0/0x56)
>>>>>> Disabling IRQ #193
>>>>> USB lost its interrupt.  Could be USB, more likely ACPI.
>>>> I've seen this one happen nearly every boot since then including bootups that 
>>>> are otherwise OK (no oopses), so it's probably worth more looking into rather 
>>>> than being written off as a 'once off':
>>>>
>>>> uhci_hcd 0000:00:1d.3: Unlink after no-IRQ?  Controller is probably using the 
>>>> wrong IRQ.
> 
> Note the PCI ID is 1d.3 and the IRQ is 193.
> 
>> Hi Alan,
>>
>> If it's any use, here's some simply and easy-to-get information which may even 
>> be what you are looking for:
>>
>> [root@tornado dovecot]# uname -a
>> Linux tornado.reub.net 2.6.15-mm1 #1 SMP Sun Jan 8 03:42:25 NZDT 2006 i686 i686 
>> i386 GNU/Linux
>> [root@tornado ~]# cat /proc/interrupts
>>             CPU0       CPU1
>>    0:   21638510          0    IO-APIC-edge  timer
>>    4:        356          0    IO-APIC-edge  serial
>>    8:          1          0    IO-APIC-edge  rtc
>>    9:          0          0   IO-APIC-level  acpi
>>   14:          1          0    IO-APIC-edge  ide0
>>   50:          3          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
>> 169:        120          0   IO-APIC-level  uhci_hcd:usb5
>> 177:    2837992          0   IO-APIC-level  sky2
>> 185:      61450          0   IO-APIC-level  uhci_hcd:usb4, serial
>> 193:    4722447          0   IO-APIC-level  libata, uhci_hcd:usb3
> 
> Note that in the earlier kernel, IRQ 193 is assigned to usb3.  That's the 
> second UHCI controller, since usb1 is EHCI.
> 
>> [root@tornado ~]# lspci
> 
>> 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
>> USB UHCI #1 (rev 03)
>> 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
>> USB UHCI #2 (rev 03)
>> 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
>> USB UHCI #3 (rev 03)
>> 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
>> USB UHCI #4 (rev 03)
>> 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) 
>> USB2 EHCI Controller (rev 03)
> 
> Note that 1d.3 is the fourth UHCI controller; the second is 1d.1.
> 
>> I guess this looks like it was assigned the same IRQ ?
> 
> I don't think so.  To be certain you'd have to check the boot-up log and
> verify that 1d.1 is usb3 and 1d.3 is usb5.
> 
> From the information presented here, it looks like -mm1 correctly routes
> the 1d.1 controller to IRQ 193 and the 1d.3 controller to IRQ 169, whereas
> -mm3 incorrectly routes the 1d.3 controller to IRQ 193.  That would make 
> it an ACPI problem.

Is this likely to be the same or similar issue to the IRQ 0 problem I see quite 
frequently on the SATA ports on later -mm releases?
(see http://www.ussg.iu.edu/hypermail/linux/kernel/0601.1/1851.html)

Reuben

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Alan Stern]

On Mon, 16 Jan 2006, Reuben Farrelly wrote:

> > From the information presented here, it looks like -mm1 correctly routes
> > the 1d.1 controller to IRQ 193 and the 1d.3 controller to IRQ 169, whereas
> > -mm3 incorrectly routes the 1d.3 controller to IRQ 193.  That would make 
> > it an ACPI problem.
> 
> Is this likely to be the same or similar issue to the IRQ 0 problem I see quite 
> frequently on the SATA ports on later -mm releases?
> (see http://www.ussg.iu.edu/hypermail/linux/kernel/0601.1/1851.html)

I doubt they are at all related.  In the USB problem the resource is there 
but ACPI is routing it wrongly.  In the SATA problem the resource isn't 
there to begin with.

But then I know almost nothing about ACPI, so I could be wrong...

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Reuben Farrelly]

On 16/01/2006 4:46 p.m., Alan Stern wrote:
> On Mon, 16 Jan 2006, Reuben Farrelly wrote:
> 
>>> From the information presented here, it looks like -mm1 correctly routes
>>> the 1d.1 controller to IRQ 193 and the 1d.3 controller to IRQ 169, whereas
>>> -mm3 incorrectly routes the 1d.3 controller to IRQ 193.  That would make 
>>> it an ACPI problem.
>> Is this likely to be the same or similar issue to the IRQ 0 problem I see quite 
>> frequently on the SATA ports on later -mm releases?
>> (see http://www.ussg.iu.edu/hypermail/linux/kernel/0601.1/1851.html)
> 
> I doubt they are at all related.  In the USB problem the resource is there 
> but ACPI is routing it wrongly.  In the SATA problem the resource isn't 
> there to begin with.
> 
> But then I know almost nothing about ACPI, so I could be wrong...
> 
> Alan Stern

Some good news.  I think it's fixed in 2.6.16-rc1-mm2.  In fact a whole boatload 
of problems I was having are fixed in this -mm release, including a nasty libata 
oops that seemed to have a few people scratching their heads.

I've now done in excess of 20 reboots with this code and haven't had either 
problem show up at all.

So for now I'll keep a record of things for a bit longer, but I guess I've 
reason to be fairly confident that both this USB/IRQ problem and my ATA/IRQ 
problem are now fixed.

It does make me wonder if the ACPI update in rc1-mm2 fixed it, and was actually 
the cause of most of my problems......it would be nice to know for sure.

Thanks,
Reuben

Re: Re: 2.6.15-mm3 [USB lost interrupt bug]

[Andrew Morton]

Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
> 
> 
> On 16/01/2006 4:46 p.m., Alan Stern wrote:
> > On Mon, 16 Jan 2006, Reuben Farrelly wrote:
> > 
> >>> From the information presented here, it looks like -mm1 correctly routes
> >>> the 1d.1 controller to IRQ 193 and the 1d.3 controller to IRQ 169, whereas
> >>> -mm3 incorrectly routes the 1d.3 controller to IRQ 193.  That would make 
> >>> it an ACPI problem.
> >> Is this likely to be the same or similar issue to the IRQ 0 problem I see quite 
> >> frequently on the SATA ports on later -mm releases?
> >> (see http://www.ussg.iu.edu/hypermail/linux/kernel/0601.1/1851.html)
> > 
> > I doubt they are at all related.  In the USB problem the resource is there 
> > but ACPI is routing it wrongly.  In the SATA problem the resource isn't 
> > there to begin with.
> > 
> > But then I know almost nothing about ACPI, so I could be wrong...
> > 
> > Alan Stern
> 
> Some good news.  I think it's fixed in 2.6.16-rc1-mm2.  In fact a whole boatload 
> of problems I was having are fixed in this -mm release, including a nasty libata 
> oops that seemed to have a few people scratching their heads.

OK, but probably that libata error-path bug is still in there.  It's just
that you're no longer taking the error paths.  And now we've lost our means
to reproduce it.

> I've now done in excess of 20 reboots with this code and haven't had either 
> problem show up at all.
> 
> So for now I'll keep a record of things for a bit longer, but I guess I've 
> reason to be fairly confident that both this USB/IRQ problem and my ATA/IRQ 
> problem are now fixed.
> 
> It does make me wonder if the ACPI update in rc1-mm2 fixed it, and was actually 
> the cause of most of my problems......it would be nice to know for sure.

We probably won't know.  Did you ever test 2.6.16-rc1 plus 2.6.16-rc1-mm1's
acpi.patch?  If that plays up we'd have confirmation.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Reuben Farrelly]

On 21/01/2006 6:47 p.m., Andrew Morton wrote:

>> I've now done in excess of 20 reboots with this code and haven't had either 
>> problem show up at all.
>>
>> So for now I'll keep a record of things for a bit longer, but I guess I've 
>> reason to be fairly confident that both this USB/IRQ problem and my ATA/IRQ 
>> problem are now fixed.
>>
>> It does make me wonder if the ACPI update in rc1-mm2 fixed it, and was actually 
>> the cause of most of my problems......it would be nice to know for sure.
> 
> We probably won't know.  Did you ever test 2.6.16-rc1 plus 2.6.16-rc1-mm1's
> acpi.patch?  If that plays up we'd have confirmation.

It has been OK over 15x reboots (just tested now).  2.6.16-rc1-mm1 wasn't the 
usual standard award winning release for me because of the reiserfs problems so 
I only booted into it once and ran it for a couple of hours before retreating to 
2.6.15-rc1.

Last *known* problematic release on that box was 2.6.15-mm4.

[PATCH] Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Jeff Garzik]

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


On the libata side of things, does this patch produce any useful results?

	Jeff




[-- Attachment #2: patch.pci-region-check --]
[-- Type: text/plain, Size: 1544 bytes --]

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 46c4cdb..4691f8d 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -4794,7 +4794,14 @@ ata_pci_init_native_mode(struct pci_dev 
 			pci_resource_start(pdev, 1) | ATA_PCI_CTL_OFS;
 		probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4);
 		ata_std_ports(&probe_ent->port[p]);
-		p++;
+
+		if (pci_resource_start(pdev, 0) &&
+		    pci_resource_len(pdev, 0) &&
+		    pci_resource_start(pdev, 1) &&
+		    pci_resource_len(pdev, 1) &&
+		    pci_resource_start(pdev, 4) &&
+		    pci_resource_len(pdev, 4))
+			p++;
 	}
 
 	if (ports & ATA_PORT_SECONDARY) {
@@ -4804,10 +4811,23 @@ ata_pci_init_native_mode(struct pci_dev 
 			pci_resource_start(pdev, 3) | ATA_PCI_CTL_OFS;
 		probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4) + 8;
 		ata_std_ports(&probe_ent->port[p]);
-		p++;
+
+		if (pci_resource_start(pdev, 2) &&
+		    pci_resource_len(pdev, 2) &&
+		    pci_resource_start(pdev, 3) &&
+		    pci_resource_len(pdev, 3) &&
+		    pci_resource_start(pdev, 4) &&
+		    pci_resource_len(pdev, 4) > 8)
+			p++;
 	}
 
 	probe_ent->n_ports = p;
+
+	if (p == 0) {
+		kfree(probe_ent);
+		probe_ent = NULL;
+	}
+
 	return probe_ent;
 }
 
@@ -4815,6 +4835,10 @@ static struct ata_probe_ent *ata_pci_ini
 {
 	struct ata_probe_ent *probe_ent;
 
+	if (!pci_resource_start(pdev, 4) ||
+	    !pci_resource_len(pdev, 4))
+		return NULL;
+
 	probe_ent = ata_probe_ent_alloc(pci_dev_to_dev(pdev), port);
 	if (!probe_ent)
 		return NULL;

Re: [PATCH] Re: [linux-usb-devel] Re: 2.6.15-mm3 [USB lost interrupt bug]

[Reuben Farrelly]

On 21/01/2006 9:32 p.m., Jeff Garzik wrote:
> 
> On the libata side of things, does this patch produce any useful results?
> 
>     Jeff
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> index 46c4cdb..4691f8d 100644
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -4794,7 +4794,14 @@ ata_pci_init_native_mode(struct pci_dev 
>  			pci_resource_start(pdev, 1) | ATA_PCI_CTL_OFS;
>  		probe_ent->port[p].bmdma_addr = pci_resource_start(pdev, 4);
>  		ata_std_ports(&probe_ent->port[p]);
> -		p++;

I've patched 2.6.15-mm4 with this, and yes, this patch changed the behaviour:

OK TIMEOUT OK OK TIMEOUT TIMEOUT TIMEOUT TIMEOUT OK TIMEOUT TIMEOUT OK TIMEOUT 
TIMEOUT TIMEOUT

OK was when we got through to completion of single user mode, TIMEOUT - see below.

So no oopsing with that patch applied, which is a definite improvement. 
Previously to this I was seeing the OOPSing most of the time and the TIMEOUTS 
more occasionally.

---

Now, looking at the timeouts, here's the log from a boot:

ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 193
ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led slum part
ata1: SATA max UDMA/133 cmd 0xF8804D00 ctl 0x0 bmdma 0x0 irq 50
ata2: SATA max UDMA/133 cmd 0xF8804D80 ctl 0x0 bmdma 0x0 irq 50
ata3: SATA max UDMA/133 cmd 0xF8804E00 ctl 0x0 bmdma 0x0 irq 50
ata4: SATA max UDMA/133 cmd 0xF8804E80 ctl 0x0 bmdma 0x0 irq 50
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1 is slow to respond, please be patient
ata1 failed to respond (30 secs)
scsi0 : ahci
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2 is slow to respond, please be patient
ata2 failed to respond (30 secs)
scsi1 : ahci
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3 is slow to respond, please be patient
ata3 failed to respond (30 secs)
scsi2 : ahci
ata4: SATA link down (SStatus 0)
scsi3 : ahci

When there is no timeout it looks like this:

ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 193
ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq led slum part
ata1: SATA max UDMA/133 cmd 0xF8804D00 ctl 0x0 bmdma 0x0 irq 193
ata2: SATA max UDMA/133 cmd 0xF8804D80 ctl 0x0 bmdma 0x0 irq 193
ata3: SATA max UDMA/133 cmd 0xF8804E00 ctl 0x0 bmdma 0x0 irq 193
ata4: SATA max UDMA/133 cmd 0xF8804E80 ctl 0x0 bmdma 0x0 irq 193
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ahci
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : ahci
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 ATA-6, max UDMA/133, 156299375 sectors: LBA48
ata3: dev 0 configured for UDMA/133
scsi2 : ahci
ata4: SATA link down (SStatus 0)
scsi3 : ahci

Note the different IRQ numbers (50, 193) and how when it breaks, the ATA 
interfaces have a different IRQ to the AHCI controller.

There's a full log up at http://lkml.org/lkml/2006/1/11/492 from when I posted 
on lkml and at http://www.reub.net/files/kernel/ when the box isn't down for 
testing ;-)

This may be a separate but related problem to the oops, I guess.

reuben