* RE: 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
@ 2006-07-14 15:54 Andy Chittenden
2006-07-14 16:30 ` Andrew Morton
0 siblings, 1 reply; 9+ messages in thread
From: Andy Chittenden @ 2006-07-14 15:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
> > On Thu, 13 Jul 2006 08:56:01 +0100
> > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> >
> > > > On Wed, 12 Jul 2006 08:58:52 +0100
> > > > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> > > >
> > > > > I tried to install the linux-image-2.6.17-1-amd64-k8-smp
> > > > debian package
> > > > > on a ASUS M2NPV-VM motherboard based system and it hung
> > > > during boot. The
> > > > > last message on the console was:
> > > > >
> > > > > io scheduler cfq registered
> > > >
> > > > Suggest you add initcall_debug to the kernel boot command
> > > > line. That'll
> > > > tell us which initcall got stuck.
> > >
> > > I was only able to scrounge 5 minutes on this system this morning.
> > > Here's the last few messages output with initcall_debug on:
> > >
> > > Calling initcall .... init+0x0/0xc()
> > > Calling initcall .... noop_init+0x0/0xc()
> > > io scheduler noop registered
> > > Calling initcall .... as_init+0x0/0x4f()
> > > io scheduler anticipatory registered (default)
> > > Calling initcall .... deadline_init+0x0/0x4f()
> > > io scheduler deadline registered
> > > Calling initcall .... cfq_init+0x0/0xcc()
> > > io scheduler cfq registered
> > > Calling initcall .... pci_init+0x0/0x2b()
> > >
> > > What other info can I grab? (Although I have to fit in with that
> > > system's production schedule so I may not be able to come
> > back with that
> > > until later on today/tomorrow).
> >
> > Seems one of the quirks has gone bad. The below should tell
> > us which one.
> > You'll need to correlate it with the machine's lspci output please.
> >
> >
> > --- a/drivers/pci/pci.c~a
> > +++ a/drivers/pci/pci.c
> > @@ -925,6 +925,7 @@ static int __devinit pci_init(void)
> > struct pci_dev *dev = NULL;
> >
> > while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID,
> > dev)) != NULL) {
> > + printk("%s: fix up %s\n", __FUNCTION__, pci_name(dev));
> > pci_fixup_device(pci_fixup_final, dev);
> > }
> > return 0;
>
> Having applied that patch, I get:
>
> pci_init: fix up 0000:00:00.0
> pci_init: fix up 0000:00:00.1
> pci_init: fix up 0000:00:00.2
> pci_init: fix up 0000:00:00.3
> pci_init: fix up 0000:00:00.4
> pci_init: fix up 0000:00:00.5
> pci_init: fix up 0000:00:00.6
> pci_init: fix up 0000:00:00.7
> pci_init: fix up 0000:00:02.0
> pci_init: fix up 0000:00:03.0
> pci_init: fix up 0000:00:04.0
> pci_init: fix up 0000:00:05.0
> pci_init: fix up 0000:00:09.0
> pci_init: fix up 0000:00:0a.0
> pci_init: fix up 0000:00:0a.1
> pci_init: fix up 0000:00:0a.2
> pci_init: fix up 0000:00:0b.0
>
> lspci -v gives:
>
> 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0
> Capabilities: [44] HyperTransport: Slave or Primary Interface
> Capabilities: [e0] HyperTransport: MSI Mapping
>
> 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller
> 0 (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: 66MHz, fast devsel
>
> 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller
> 1 (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: 66MHz, fast devsel
>
> 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller
> 5 (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: 66MHz, fast devsel
>
> 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller
> 4 (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0
>
> 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0
> Capabilities: [44] #00 [00fe]
> Capabilities: [fc] #00 [0000]
>
> 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller
> 3 (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: 66MHz, fast devsel
>
> 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller
> 2 (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: 66MHz, fast devsel
>
> 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge
> (rev a1) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 0000a000-0000afff
> Memory behind bridge: fd800000-fd8fffff
> Prefetchable memory behind bridge:
> 00000000fd700000-00000000fd700000
> Capabilities: [40] #0d [0000]
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Message Signalled Interrupts:
> 64bit+ Queue=0/1 Enable+
> Capabilities: [60] HyperTransport: MSI Mapping
> Capabilities: [80] Express Root Port (Slot+) IRQ 0
> Capabilities: [100] Virtual Channel
>
> 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge
> (rev a1) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
> I/O behind bridge: 00008000-00008fff
> Memory behind bridge: fde00000-fdefffff
> Prefetchable memory behind bridge:
> 00000000fdd00000-00000000fdd00000
> Capabilities: [40] #0d [0000]
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Message Signalled Interrupts:
> 64bit+ Queue=0/1 Enable+
> Capabilities: [60] HyperTransport: MSI Mapping
> Capabilities: [80] Express Root Port (Slot+) IRQ 0
> Capabilities: [100] Virtual Channel
>
> 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge
> (rev a1) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
> I/O behind bridge: 0000b000-0000bfff
> Memory behind bridge: fdc00000-fdcfffff
> Prefetchable memory behind bridge:
> 00000000fd900000-00000000fd900000
> Capabilities: [40] #0d [0000]
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Message Signalled Interrupts:
> 64bit+ Queue=0/1 Enable+
> Capabilities: [60] HyperTransport: MSI Mapping
> Capabilities: [80] Express Root Port (Slot+) IRQ 0
> Capabilities: [100] Virtual Channel
>
> 00:05.0 VGA compatible controller: nVidia Corporation C51PV
> [GeForce 6150] (rev a2) (prog-if 00 [VGA])
> Subsystem: ASUSTeK Computer Inc. Unknown device 81cd
> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 58
> Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
> Memory at e0000000 (64-bit, prefetchable) [size=256M]
> Memory at fb000000 (64-bit, non-prefetchable) [size=16M]
> [virtual] Expansion ROM at dc000000 [disabled] [size=128K]
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Message Signalled Interrupts:
> 64bit+ Queue=0/0 Enable-
>
> 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0
> Capabilities: [44] HyperTransport: Slave or Primary Interface
> Capabilities: [e0] HyperTransport: MSI Mapping
>
> 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0
>
> 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: 66MHz, fast devsel, IRQ 255
> I/O ports at 4c00 [size=64]
> I/O ports at 4c40 [size=64]
> Capabilities: [44] Power Management version 2
>
> 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory
> Controller 0 (rev a3)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: 66MHz, fast devsel
>
> 00:0b.0 USB Controller: nVidia Corporation MCP51 USB
> Controller (rev a3) (prog-if 10 [OHCI])
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 233
> Memory at fe02f000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [44] Power Management version 2
>
> 00:0b.1 USB Controller: nVidia Corporation MCP51 USB
> Controller (rev a3) (prog-if 20 [EHCI])
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
> Memory at fe02e000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [44] Debug port
> Capabilities: [80] Power Management version 2
>
> 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
> (prog-if 8a [Master SecP PriP])
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0
> I/O ports at f400 [size=16]
> Capabilities: [44] Power Management version 2
>
> 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA
> Controller (rev a1) (prog-if 85 [Master SecO PriO])
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 50
> I/O ports at 09f0 [size=8]
> I/O ports at 0bf0 [size=4]
> I/O ports at 0970 [size=8]
> I/O ports at 0b70 [size=4]
> I/O ports at e000 [size=16]
> Memory at fe02d000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [44] Power Management version 2
> Capabilities: [b0] Message Signalled Interrupts:
> 64bit+ Queue=0/2 Enable-
> Capabilities: [cc] HyperTransport: MSI Mapping
>
> 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA
> Controller (rev a1) (prog-if 85 [Master SecO PriO])
> Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
> I/O ports at 09e0 [size=8]
> I/O ports at 0be0 [size=4]
> I/O ports at 0960 [size=8]
> I/O ports at 0b60 [size=4]
> I/O ports at cc00 [size=16]
> Memory at fe02c000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [44] Power Management version 2
> Capabilities: [b0] Message Signalled Interrupts:
> 64bit+ Queue=0/2 Enable-
> Capabilities: [cc] HyperTransport: MSI Mapping
>
> 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev
> a2) (prog-if 01 [Subtractive decode])
> Flags: bus master, 66MHz, fast devsel, latency 0
> Bus: primary=00, secondary=04, subordinate=04, sec-latency=128
> I/O behind bridge: 00009000-00009fff
> Memory behind bridge: fdb00000-fdbfffff
> Prefetchable memory behind bridge: fda00000-fdafffff
> Capabilities: [b8] #0d [0000]
> Capabilities: [8c] HyperTransport: MSI Mapping
>
> 00:10.1 Audio device: nVidia Corporation MCP51 High
> Definition Audio (rev a2)
> Subsystem: ASUSTeK Computer Inc. Unknown device 81cb
> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
> Memory at fe024000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [44] Power Management version 2
> Capabilities: [50] Message Signalled Interrupts:
> 64bit+ Queue=0/0 Enable-
> Capabilities: [6c] HyperTransport: MSI Mapping
>
> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
> Subsystem: ASUSTeK Computer Inc. Unknown device 816a
> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
> Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
> I/O ports at c800 [size=8]
> Capabilities: [44] Power Management version 2
>
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] HyperTransport Technology Configuration
> Flags: fast devsel
> Capabilities: [80] HyperTransport: Host or Secondary Interface
>
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] Address Map
> Flags: fast devsel
>
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] DRAM Controller
> Flags: fast devsel
>
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] Miscellaneous Control
> Flags: fast devsel
> Capabilities: [f0] #0f [0010]
>
> 04:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A
> IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
> Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
> Flags: bus master, medium devsel, latency 32, IRQ 209
> Memory at fdbff000 (32-bit, non-prefetchable) [size=2K]
> Memory at fdbf8000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [44] Power Management version 2
>
> So I guess there's something awry with the USB controller driver?
>
Is there any other info that someone wants to track this down? Or has
someone got a fix?
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
2006-07-14 15:54 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard Andy Chittenden
@ 2006-07-14 16:30 ` Andrew Morton
2006-07-14 18:50 ` [linux-usb-devel] " Alan Stern
2006-07-14 19:37 ` David Brownell
0 siblings, 2 replies; 9+ messages in thread
From: Andrew Morton @ 2006-07-14 16:30 UTC (permalink / raw)
To: Andy Chittenden
Cc: linux-kernel, linux-usb-devel, Alan Stern, David Brownell, Greg KH
On Fri, 14 Jul 2006 16:54:25 +0100
"Andy Chittenden" <AChittenden@bluearc.com> wrote:
>
>
> > > On Thu, 13 Jul 2006 08:56:01 +0100
> > > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> > >
> > > > > On Wed, 12 Jul 2006 08:58:52 +0100
> > > > > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> > > > >
> > > > > > I tried to install the linux-image-2.6.17-1-amd64-k8-smp
> > > > > debian package
> > > > > > on a ASUS M2NPV-VM motherboard based system and it hung
> > > > > during boot. The
> > > > > > last message on the console was:
> > > > > >
> > > > > > io scheduler cfq registered
> > > > >
> > > > > Suggest you add initcall_debug to the kernel boot command
> > > > > line. That'll
> > > > > tell us which initcall got stuck.
> > > >
> > > > I was only able to scrounge 5 minutes on this system this morning.
> > > > Here's the last few messages output with initcall_debug on:
> > > >
> > > > Calling initcall .... init+0x0/0xc()
> > > > Calling initcall .... noop_init+0x0/0xc()
> > > > io scheduler noop registered
> > > > Calling initcall .... as_init+0x0/0x4f()
> > > > io scheduler anticipatory registered (default)
> > > > Calling initcall .... deadline_init+0x0/0x4f()
> > > > io scheduler deadline registered
> > > > Calling initcall .... cfq_init+0x0/0xcc()
> > > > io scheduler cfq registered
> > > > Calling initcall .... pci_init+0x0/0x2b()
> > > >
> > > > What other info can I grab? (Although I have to fit in with that
> > > > system's production schedule so I may not be able to come
> > > back with that
> > > > until later on today/tomorrow).
> > >
> > > Seems one of the quirks has gone bad. The below should tell
> > > us which one.
> > > You'll need to correlate it with the machine's lspci output please.
> > >
> > >
> > > --- a/drivers/pci/pci.c~a
> > > +++ a/drivers/pci/pci.c
> > > @@ -925,6 +925,7 @@ static int __devinit pci_init(void)
> > > struct pci_dev *dev = NULL;
> > >
> > > while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID,
> > > dev)) != NULL) {
> > > + printk("%s: fix up %s\n", __FUNCTION__, pci_name(dev));
> > > pci_fixup_device(pci_fixup_final, dev);
> > > }
> > > return 0;
> >
> > Having applied that patch, I get:
> >
> > pci_init: fix up 0000:00:00.0
> > pci_init: fix up 0000:00:00.1
> > pci_init: fix up 0000:00:00.2
> > pci_init: fix up 0000:00:00.3
> > pci_init: fix up 0000:00:00.4
> > pci_init: fix up 0000:00:00.5
> > pci_init: fix up 0000:00:00.6
> > pci_init: fix up 0000:00:00.7
> > pci_init: fix up 0000:00:02.0
> > pci_init: fix up 0000:00:03.0
> > pci_init: fix up 0000:00:04.0
> > pci_init: fix up 0000:00:05.0
> > pci_init: fix up 0000:00:09.0
> > pci_init: fix up 0000:00:0a.0
> > pci_init: fix up 0000:00:0a.1
> > pci_init: fix up 0000:00:0a.2
> > pci_init: fix up 0000:00:0b.0
> >
> > lspci -v gives:
> >
> > 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0
> > Capabilities: [44] HyperTransport: Slave or Primary Interface
> > Capabilities: [e0] HyperTransport: MSI Mapping
> >
> > 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller
> > 0 (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: 66MHz, fast devsel
> >
> > 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller
> > 1 (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: 66MHz, fast devsel
> >
> > 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller
> > 5 (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: 66MHz, fast devsel
> >
> > 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller
> > 4 (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0
> >
> > 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0
> > Capabilities: [44] #00 [00fe]
> > Capabilities: [fc] #00 [0000]
> >
> > 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller
> > 3 (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: 66MHz, fast devsel
> >
> > 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller
> > 2 (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: 66MHz, fast devsel
> >
> > 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge
> > (rev a1) (prog-if 00 [Normal decode])
> > Flags: bus master, fast devsel, latency 0
> > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> > I/O behind bridge: 0000a000-0000afff
> > Memory behind bridge: fd800000-fd8fffff
> > Prefetchable memory behind bridge:
> > 00000000fd700000-00000000fd700000
> > Capabilities: [40] #0d [0000]
> > Capabilities: [48] Power Management version 2
> > Capabilities: [50] Message Signalled Interrupts:
> > 64bit+ Queue=0/1 Enable+
> > Capabilities: [60] HyperTransport: MSI Mapping
> > Capabilities: [80] Express Root Port (Slot+) IRQ 0
> > Capabilities: [100] Virtual Channel
> >
> > 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge
> > (rev a1) (prog-if 00 [Normal decode])
> > Flags: bus master, fast devsel, latency 0
> > Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
> > I/O behind bridge: 00008000-00008fff
> > Memory behind bridge: fde00000-fdefffff
> > Prefetchable memory behind bridge:
> > 00000000fdd00000-00000000fdd00000
> > Capabilities: [40] #0d [0000]
> > Capabilities: [48] Power Management version 2
> > Capabilities: [50] Message Signalled Interrupts:
> > 64bit+ Queue=0/1 Enable+
> > Capabilities: [60] HyperTransport: MSI Mapping
> > Capabilities: [80] Express Root Port (Slot+) IRQ 0
> > Capabilities: [100] Virtual Channel
> >
> > 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge
> > (rev a1) (prog-if 00 [Normal decode])
> > Flags: bus master, fast devsel, latency 0
> > Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
> > I/O behind bridge: 0000b000-0000bfff
> > Memory behind bridge: fdc00000-fdcfffff
> > Prefetchable memory behind bridge:
> > 00000000fd900000-00000000fd900000
> > Capabilities: [40] #0d [0000]
> > Capabilities: [48] Power Management version 2
> > Capabilities: [50] Message Signalled Interrupts:
> > 64bit+ Queue=0/1 Enable+
> > Capabilities: [60] HyperTransport: MSI Mapping
> > Capabilities: [80] Express Root Port (Slot+) IRQ 0
> > Capabilities: [100] Virtual Channel
> >
> > 00:05.0 VGA compatible controller: nVidia Corporation C51PV
> > [GeForce 6150] (rev a2) (prog-if 00 [VGA])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81cd
> > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 58
> > Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
> > Memory at e0000000 (64-bit, prefetchable) [size=256M]
> > Memory at fb000000 (64-bit, non-prefetchable) [size=16M]
> > [virtual] Expansion ROM at dc000000 [disabled] [size=128K]
> > Capabilities: [48] Power Management version 2
> > Capabilities: [50] Message Signalled Interrupts:
> > 64bit+ Queue=0/0 Enable-
> >
> > 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0
> > Capabilities: [44] HyperTransport: Slave or Primary Interface
> > Capabilities: [e0] HyperTransport: MSI Mapping
> >
> > 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0
> >
> > 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: 66MHz, fast devsel, IRQ 255
> > I/O ports at 4c00 [size=64]
> > I/O ports at 4c40 [size=64]
> > Capabilities: [44] Power Management version 2
> >
> > 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory
> > Controller 0 (rev a3)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: 66MHz, fast devsel
> >
> > 00:0b.0 USB Controller: nVidia Corporation MCP51 USB
> > Controller (rev a3) (prog-if 10 [OHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 233
> > Memory at fe02f000 (32-bit, non-prefetchable) [size=4K]
> > Capabilities: [44] Power Management version 2
> >
> > 00:0b.1 USB Controller: nVidia Corporation MCP51 USB
> > Controller (rev a3) (prog-if 20 [EHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
> > Memory at fe02e000 (32-bit, non-prefetchable) [size=256]
> > Capabilities: [44] Debug port
> > Capabilities: [80] Power Management version 2
> >
> > 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
> > (prog-if 8a [Master SecP PriP])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0
> > I/O ports at f400 [size=16]
> > Capabilities: [44] Power Management version 2
> >
> > 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA
> > Controller (rev a1) (prog-if 85 [Master SecO PriO])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 50
> > I/O ports at 09f0 [size=8]
> > I/O ports at 0bf0 [size=4]
> > I/O ports at 0970 [size=8]
> > I/O ports at 0b70 [size=4]
> > I/O ports at e000 [size=16]
> > Memory at fe02d000 (32-bit, non-prefetchable) [size=4K]
> > Capabilities: [44] Power Management version 2
> > Capabilities: [b0] Message Signalled Interrupts:
> > 64bit+ Queue=0/2 Enable-
> > Capabilities: [cc] HyperTransport: MSI Mapping
> >
> > 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA
> > Controller (rev a1) (prog-if 85 [Master SecO PriO])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81c0
> > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
> > I/O ports at 09e0 [size=8]
> > I/O ports at 0be0 [size=4]
> > I/O ports at 0960 [size=8]
> > I/O ports at 0b60 [size=4]
> > I/O ports at cc00 [size=16]
> > Memory at fe02c000 (32-bit, non-prefetchable) [size=4K]
> > Capabilities: [44] Power Management version 2
> > Capabilities: [b0] Message Signalled Interrupts:
> > 64bit+ Queue=0/2 Enable-
> > Capabilities: [cc] HyperTransport: MSI Mapping
> >
> > 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev
> > a2) (prog-if 01 [Subtractive decode])
> > Flags: bus master, 66MHz, fast devsel, latency 0
> > Bus: primary=00, secondary=04, subordinate=04, sec-latency=128
> > I/O behind bridge: 00009000-00009fff
> > Memory behind bridge: fdb00000-fdbfffff
> > Prefetchable memory behind bridge: fda00000-fdafffff
> > Capabilities: [b8] #0d [0000]
> > Capabilities: [8c] HyperTransport: MSI Mapping
> >
> > 00:10.1 Audio device: nVidia Corporation MCP51 High
> > Definition Audio (rev a2)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 81cb
> > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
> > Memory at fe024000 (32-bit, non-prefetchable) [size=16K]
> > Capabilities: [44] Power Management version 2
> > Capabilities: [50] Message Signalled Interrupts:
> > 64bit+ Queue=0/0 Enable-
> > Capabilities: [6c] HyperTransport: MSI Mapping
> >
> > 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 816a
> > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
> > Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
> > I/O ports at c800 [size=8]
> > Capabilities: [44] Power Management version 2
> >
> > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
> > [Athlon64/Opteron] HyperTransport Technology Configuration
> > Flags: fast devsel
> > Capabilities: [80] HyperTransport: Host or Secondary Interface
> >
> > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
> > [Athlon64/Opteron] Address Map
> > Flags: fast devsel
> >
> > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
> > [Athlon64/Opteron] DRAM Controller
> > Flags: fast devsel
> >
> > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
> > [Athlon64/Opteron] Miscellaneous Control
> > Flags: fast devsel
> > Capabilities: [f0] #0f [0010]
> >
> > 04:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A
> > IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
> > Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
> > Flags: bus master, medium devsel, latency 32, IRQ 209
> > Memory at fdbff000 (32-bit, non-prefetchable) [size=2K]
> > Memory at fdbf8000 (32-bit, non-prefetchable) [size=16K]
> > Capabilities: [44] Power Management version 2
> >
> > So I guess there's something awry with the USB controller driver?
> >
>
> Is there any other info that someone wants to track this down? Or has
> someone got a fix?
>
Best we can do is cc various USB people then wait. Things are slow at
present due to summer migratory activity towards Ottawa.
But when the flock returns, hopefully they will remember that we have a
straightforward box-killing regression in the 2.6.17 OHCI controller quirk
handling.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
2006-07-14 16:30 ` Andrew Morton
@ 2006-07-14 18:50 ` Alan Stern
2006-07-14 19:00 ` Andrew Morton
2006-07-14 19:37 ` David Brownell
1 sibling, 1 reply; 9+ messages in thread
From: Alan Stern @ 2006-07-14 18:50 UTC (permalink / raw)
To: Andy Chittenden
Cc: Andrew Morton, David Brownell, Greg KH, Kernel development list,
USB development list
On Fri, 14 Jul 2006, Andrew Morton wrote:
> On Fri, 14 Jul 2006 16:54:25 +0100
> "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> > > So I guess there's something awry with the USB controller driver?
> > >
> >
> > Is there any other info that someone wants to track this down? Or has
> > someone got a fix?
It's hard to come up with a fix without knowing what's wrong. The current
development version of that subroutine is essentially the same as the
version in 2.6.17.
If you want to pin down the problem more precisely, try adding a whole
bunch of printk() statements to the quirk_usb_handoff_ohci() function in
drivers/usb/host/pci-quirks.c.
Alan Stern
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
2006-07-14 18:50 ` [linux-usb-devel] " Alan Stern
@ 2006-07-14 19:00 ` Andrew Morton
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Morton @ 2006-07-14 19:00 UTC (permalink / raw)
To: Alan Stern; +Cc: AChittenden, david-b, greg, linux-kernel, linux-usb-devel
On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 14 Jul 2006, Andrew Morton wrote:
>
> > On Fri, 14 Jul 2006 16:54:25 +0100
> > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
>
> > > > So I guess there's something awry with the USB controller driver?
> > > >
> > >
> > > Is there any other info that someone wants to track this down? Or has
> > > someone got a fix?
>
> It's hard to come up with a fix without knowing what's wrong. The current
> development version of that subroutine is essentially the same as the
> version in 2.6.17.
>
> If you want to pin down the problem more precisely, try adding a whole
> bunch of printk() statements to the quirk_usb_handoff_ohci() function in
> drivers/usb/host/pci-quirks.c.
>
Andy, please add the below, work out what line it gets stuck at and then
let us know? Thanks.
(bear in mind that our line numbers will usually be different from yours,
so please don't use line numbers to ifdentify where it hung).
diff -puN drivers/usb/host/pci-quirks.c~a drivers/usb/host/pci-quirks.c
--- a/drivers/usb/host/pci-quirks.c~a
+++ a/drivers/usb/host/pci-quirks.c
@@ -164,38 +164,50 @@ static int __devinit mmio_resource_enabl
return pci_resource_start(pdev, idx) && mmio_enabled(pdev);
}
+#define D() printk("%s:%d\n", __FILE__, __LINE__);
+
static void __devinit quirk_usb_handoff_ohci(struct pci_dev *pdev)
{
void __iomem *base;
+ D();
+
if (!mmio_resource_enabled(pdev, 0))
return;
+ D();
+
base = ioremap_nocache(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
if (base == NULL) return;
-
+ D();
/* On PA-RISC, PDC can leave IR set incorrectly; ignore it there. */
#ifndef __hppa__
{
u32 control = readl(base + OHCI_CONTROL);
+ D();
if (control & OHCI_CTRL_IR) {
int wait_time = 500; /* arbitrary; 5 seconds */
+ D();
writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
+ D();
writel(OHCI_OCR, base + OHCI_CMDSTATUS);
+ D();
while (wait_time > 0 &&
readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
wait_time -= 10;
msleep(10);
}
+ D();
if (wait_time <= 0)
printk(KERN_WARNING "%s %s: BIOS handoff "
"failed (BIOS bug ?) %08x\n",
pdev->dev.bus_id, "OHCI",
readl(base + OHCI_CONTROL));
-
+ D();
/* reset controller, preserving RWC */
writel(control & OHCI_CTRL_RWC, base + OHCI_CONTROL);
+ D();
}
}
#endif
@@ -203,10 +215,13 @@ static void __devinit quirk_usb_handoff_
/*
* disable interrupts
*/
+ D();
writel(~(u32)0, base + OHCI_INTRDISABLE);
+ D();
writel(~(u32)0, base + OHCI_INTRSTATUS);
-
+ D();
iounmap(base);
+ D();
}
static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)
_
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
2006-07-14 16:30 ` Andrew Morton
2006-07-14 18:50 ` [linux-usb-devel] " Alan Stern
@ 2006-07-14 19:37 ` David Brownell
1 sibling, 0 replies; 9+ messages in thread
From: David Brownell @ 2006-07-14 19:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Andy Chittenden, linux-kernel, linux-usb-devel, Alan Stern, Greg KH
On Friday 14 July 2006 9:30 am, Andrew Morton wrote:
>
> But when the flock returns, hopefully they will remember that we have a
> straightforward box-killing regression in the 2.6.17 OHCI controller quirk
> handling.
More likely in some other code, since that "quirk" handling code hasn't
changed in forever. Sometimes BIOS changes hurt (including setup/config),
sometimes pci/acpi init is a factor.
- Dave
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
2006-07-27 8:29 Andy Chittenden
@ 2006-07-27 14:27 ` Alan Stern
0 siblings, 0 replies; 9+ messages in thread
From: Alan Stern @ 2006-07-27 14:27 UTC (permalink / raw)
To: Andy Chittenden
Cc: Andrew Morton, david-b, greg, linux-kernel, linux-usb-devel
On Thu, 27 Jul 2006, Andy Chittenden wrote:
> > So why did putting in the initial lot of debug alter where
> > the kernel hung? And what's next?
I don't know why the location of the hang changed. It suggests you're up
against some kind of race against the hardware.
The new location you found is in the driver core, and a bug was fixed in
that region just about at the same time as you ran your test. You might
try redoing everything with the current -mm tree plus hotfixes.
And try running each test a few times. If there is a race, you could get
different results each time.
Alan Stern
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
@ 2006-07-27 8:29 Andy Chittenden
2006-07-27 14:27 ` Alan Stern
0 siblings, 1 reply; 9+ messages in thread
From: Andy Chittenden @ 2006-07-27 8:29 UTC (permalink / raw)
To: Andrew Morton, Alan Stern; +Cc: david-b, greg, linux-kernel, linux-usb-devel
> > On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
> > Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > > On Fri, 14 Jul 2006, Andrew Morton wrote:
> > >
> > > > On Fri, 14 Jul 2006 16:54:25 +0100
> > > > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> > >
> > > > > > So I guess there's something awry with the USB
> > controller driver?
> > > > > >
> > > > >
> > > > > Is there any other info that someone wants to track
> > this down? Or has
> > > > > someone got a fix?
> > >
> > > It's hard to come up with a fix without knowing what's
> > wrong. The current
> > > development version of that subroutine is essentially the
> > same as the
> > > version in 2.6.17.
> > >
> > > If you want to pin down the problem more precisely, try
> > adding a whole
> > > bunch of printk() statements to the
> > quirk_usb_handoff_ohci() function in
> > > drivers/usb/host/pci-quirks.c.
> > >
> >
> > Andy, please add the below, work out what line it gets stuck
> > at and then
> > let us know? Thanks.
>
> Well I did that and the kernel got a lot further! It ran
> through the pci_init stuff without a hitch and then hung just
> after this line was output:
>
> ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI)
> Driver (PCI)
>
> So I littered drivers/usb/host/ohci-pci.c with similar
> debugging and the last line it printed was from (marked with --->):
>
> static int __init ohci_hcd_pci_init (void)
> {
> int ret;
> printk (KERN_DEBUG "%s: " DRIVER_INFO " (PCI)\n", hcd_name);
> if (usb_disabled())
> return -ENODEV;
>
> D();
>
> pr_debug ("%s: block sizes: ed %Zd td %Zd\n", hcd_name,
> sizeof (struct ed), sizeof (struct td));
> ---> D();
>
> ret = pci_register_driver (&ohci_pci_driver);
> D();
> return ret;
>
> }
>
> IE it never returned from pci_register_driver.
>
> A bit more sprinkling of debugging showed it got to
> drivers/base/bus.c (bus_add_driver()):
>
> D();
>
> driver_attach(drv);
> D();
>
> It never returned from driver_attach().
>
> More debugging in drivers/base/dd.c showed the last output to
> be (marked with --->):
>
> static int __driver_attach(struct device * dev, void * data)
> {
> struct device_driver * drv = data;
>
> /*
> * Lock device and try to bind to it. We drop the error
> * here and always return 0, because we need to keep trying
> * to bind to devices and some drivers will return an error
> * simply if it didn't support the device.
> *
> * driver_probe_device() will spit a warning if there
> * is an error.
> */
>
> ---> D();
>
> if (dev->parent) /* Needed for USB */
> down(&dev->parent->sem);
> D();
>
> IE it never returned from down.
>
> So why did putting in the initial lot of debug alter where
> the kernel hung? And what's next?
>
> NB a reminder: 2.6.16 boots up fine on this machine.
Any progress? FWIW I did notice a pause at:
Booting processor 1/2 APIC 0x1
on 2.6.17 - the pause isn't present on 2.6.16.
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
@ 2006-07-19 13:00 Andy Chittenden
0 siblings, 0 replies; 9+ messages in thread
From: Andy Chittenden @ 2006-07-19 13:00 UTC (permalink / raw)
To: Andrew Morton, Alan Stern; +Cc: david-b, greg, linux-kernel, linux-usb-devel
> > On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
> > Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > > On Fri, 14 Jul 2006, Andrew Morton wrote:
> > >
> > > > On Fri, 14 Jul 2006 16:54:25 +0100
> > > > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> > >
> > > > > > So I guess there's something awry with the USB
> > controller driver?
> > > > > >
> > > > >
> > > > > Is there any other info that someone wants to track
> > this down? Or has
> > > > > someone got a fix?
> > >
> > > It's hard to come up with a fix without knowing what's
> > wrong. The current
> > > development version of that subroutine is essentially the
> > same as the
> > > version in 2.6.17.
> > >
> > > If you want to pin down the problem more precisely, try
> > adding a whole
> > > bunch of printk() statements to the
> > quirk_usb_handoff_ohci() function in
> > > drivers/usb/host/pci-quirks.c.
> > >
> >
> > Andy, please add the below, work out what line it gets stuck
> > at and then
> > let us know? Thanks.
>
> Well I did that and the kernel got a lot further! It ran
> through the pci_init stuff without a hitch and then hung just
> after this line was output:
>
> ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI)
> Driver (PCI)
>
> So I littered drivers/usb/host/ohci-pci.c with similar
> debugging and the last line it printed was from (marked with --->):
>
> static int __init ohci_hcd_pci_init (void)
> {
> int ret;
> printk (KERN_DEBUG "%s: " DRIVER_INFO " (PCI)\n", hcd_name);
> if (usb_disabled())
> return -ENODEV;
>
> D();
>
> pr_debug ("%s: block sizes: ed %Zd td %Zd\n", hcd_name,
> sizeof (struct ed), sizeof (struct td));
> ---> D();
>
> ret = pci_register_driver (&ohci_pci_driver);
> D();
> return ret;
>
> }
>
> IE it never returned from pci_register_driver.
>
> A bit more sprinkling of debugging showed it got to
> drivers/base/bus.c (bus_add_driver()):
>
> D();
>
> driver_attach(drv);
> D();
>
> It never returned from driver_attach().
>
> More debugging in drivers/base/dd.c showed the last output to
> be (marked with --->):
>
> static int __driver_attach(struct device * dev, void * data)
> {
> struct device_driver * drv = data;
>
> /*
> * Lock device and try to bind to it. We drop the error
> * here and always return 0, because we need to keep trying
> * to bind to devices and some drivers will return an error
> * simply if it didn't support the device.
> *
> * driver_probe_device() will spit a warning if there
> * is an error.
> */
>
> ---> D();
>
> if (dev->parent) /* Needed for USB */
> down(&dev->parent->sem);
> D();
>
> IE it never returned from down.
>
> So why did putting in the initial lot of debug alter where
> the kernel hung? And what's next?
>
> NB a reminder: 2.6.16 boots up fine on this machine.
Any progress?
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard
@ 2006-07-17 10:44 Andy Chittenden
0 siblings, 0 replies; 9+ messages in thread
From: Andy Chittenden @ 2006-07-17 10:44 UTC (permalink / raw)
To: Andrew Morton, Alan Stern; +Cc: david-b, greg, linux-kernel, linux-usb-devel
> On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
>
> > On Fri, 14 Jul 2006, Andrew Morton wrote:
> >
> > > On Fri, 14 Jul 2006 16:54:25 +0100
> > > "Andy Chittenden" <AChittenden@bluearc.com> wrote:
> >
> > > > > So I guess there's something awry with the USB
> controller driver?
> > > > >
> > > >
> > > > Is there any other info that someone wants to track
> this down? Or has
> > > > someone got a fix?
> >
> > It's hard to come up with a fix without knowing what's
> wrong. The current
> > development version of that subroutine is essentially the
> same as the
> > version in 2.6.17.
> >
> > If you want to pin down the problem more precisely, try
> adding a whole
> > bunch of printk() statements to the
> quirk_usb_handoff_ohci() function in
> > drivers/usb/host/pci-quirks.c.
> >
>
> Andy, please add the below, work out what line it gets stuck
> at and then
> let us know? Thanks.
Well I did that and the kernel got a lot further! It ran through the
pci_init stuff without a hitch and then hung just after this line was
output:
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
(PCI)
So I littered drivers/usb/host/ohci-pci.c with similar debugging and the
last line it printed was from (marked with --->):
static int __init ohci_hcd_pci_init (void)
{
int ret;
printk (KERN_DEBUG "%s: " DRIVER_INFO " (PCI)\n", hcd_name);
if (usb_disabled())
return -ENODEV;
D();
pr_debug ("%s: block sizes: ed %Zd td %Zd\n", hcd_name,
sizeof (struct ed), sizeof (struct td));
---> D();
ret = pci_register_driver (&ohci_pci_driver);
D();
return ret;
}
IE it never returned from pci_register_driver.
A bit more sprinkling of debugging showed it got to drivers/base/bus.c
(bus_add_driver()):
D();
driver_attach(drv);
D();
It never returned from driver_attach().
More debugging in drivers/base/dd.c showed the last output to be (marked
with --->):
static int __driver_attach(struct device * dev, void * data)
{
struct device_driver * drv = data;
/*
* Lock device and try to bind to it. We drop the error
* here and always return 0, because we need to keep trying
* to bind to devices and some drivers will return an error
* simply if it didn't support the device.
*
* driver_probe_device() will spit a warning if there
* is an error.
*/
---> D();
if (dev->parent) /* Needed for USB */
down(&dev->parent->sem);
D();
IE it never returned from down.
So why did putting in the initial lot of debug alter where the kernel
hung? And what's next?
NB a reminder: 2.6.16 boots up fine on this machine.
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-07-27 14:27 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-07-14 15:54 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard Andy Chittenden
2006-07-14 16:30 ` Andrew Morton
2006-07-14 18:50 ` [linux-usb-devel] " Alan Stern
2006-07-14 19:00 ` Andrew Morton
2006-07-14 19:37 ` David Brownell
2006-07-17 10:44 [linux-usb-devel] " Andy Chittenden
2006-07-19 13:00 Andy Chittenden
2006-07-27 8:29 Andy Chittenden
2006-07-27 14:27 ` Alan Stern
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.