linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
@ 2006-01-20 12:32 Carlo E. Prelz
  2006-01-21  9:09 ` Andrew Morton
  0 siblings, 1 reply; 22+ messages in thread
From: Carlo E. Prelz @ 2006-01-20 12:32 UTC (permalink / raw)
  To: linux-kernel

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

Best regards to all and everyone. I just purchased a new RS480 (Radeon
XPress200)-based motherboard. It is a Sapphire Pure Performance
PP-A9RS480. Mine is equipped with an Athlon64 3200+. I am attaching
the output of lspci -v

When booting with kernels from 2.6.15-rc1 up (tested with 2.6.15-rc1,
2.6.15-rc5, 2.6.15 and 2.6.16-rc1), the boot process freezes after
displaying messages retated to registering io schedulers:

...
...
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered

There is no OOPS of any kind. The disk activity led remains on. With
both 2.6.14 and 2.6.14.6, boot regularly continues with:

Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
nbd: registered device at major 43
...
...

I tried to enable all debug options in configure, but no new message
appears. 

Important: I obtain the same result (frozen after "io scheduler cfq
registered") when booting with a 100MB netinst debian sid bootdisk,
downloaded last night. An older (9 month old) Ubuntu bootdisk boots
perfectly. Both cd's are AMD64-specific.

I will be very happy to provide any further info, or to make any
test. Please CC me in your answers if you can.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

[-- Attachment #2: lspciout --]
[-- Type: text/plain, Size: 7405 bytes --]

0000:00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01)
	Subsystem: ATI Technologies Inc RS480 Host Bridge
	Flags: bus master, 66MHz, medium devsel, latency 64

0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f (prog-if 00 [Normal decode])
	Flags: bus master, 66MHz, medium devsel, latency 99
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: fde00000-fdefffff
	Prefetchable memory behind bridge: 00000000d8000000-00000000dff00000
	Capabilities: <available only to root>

0000:00:11.0 IDE interface: ATI Technologies Inc ATI 437A Serial ATA Controller (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: ATI Technologies Inc ATI 437A Serial ATA Controller
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5
	I/O ports at ff00 [size=8]
	I/O ports at fe00 [size=4]
	I/O ports at fd00 [size=8]
	I/O ports at fc00 [size=4]
	I/O ports at fb00 [size=16]
	Memory at fe02f000 (32-bit, non-prefetchable) [size=512]
	Expansion ROM at 40000000 [disabled] [size=512K]
	Capabilities: <available only to root>

0000:00:12.0 IDE interface: ATI Technologies Inc ATI 4379 Serial ATA Controller (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: ATI Technologies Inc ATI 4379 Serial ATA Controller
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
	I/O ports at fa00 [size=8]
	I/O ports at f900 [size=4]
	I/O ports at f800 [size=8]
	I/O ports at f700 [size=4]
	I/O ports at f600 [size=16]
	Memory at fe02e000 (32-bit, non-prefetchable) [size=512]
	Expansion ROM at 40080000 [disabled] [size=512K]
	Capabilities: <available only to root>

0000:00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
	Memory at fe02d000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <available only to root>

0000:00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
	Memory at fe02c000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <available only to root>

0000:00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (prog-if 20 [EHCI])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
	Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <available only to root>

0000:00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 10)
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: 66MHz, medium devsel
	I/O ports at 0400 [size=16]
	Memory at fe02a000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <available only to root>

0000:00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI (prog-if 8a [Master SecP PriP])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at f400 [size=16]
	Capabilities: <available only to root>

0000:00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 0

0000:00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge (prog-if 01 [Subtractive decode])
	Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: fdd00000-fddfffff
	Prefetchable memory behind bridge: fdc00000-fdcfffff

0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 01)
	Subsystem: PC Partner Limited: Unknown device 5215
	Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 11
	Memory at fe029000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <available only to root>

0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
	Flags: fast devsel
	Capabilities: <available only to root>

0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
	Flags: fast devsel

0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
	Flags: fast devsel

0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
	Flags: fast devsel

0000:01:05.0 VGA compatible controller: ATI Technologies Inc RS480 [Radeon Xpress 200G Series] (prog-if 00 [VGA])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 11
	Memory at d8000000 (32-bit, prefetchable) [size=128M]
	I/O ports at ee00 [size=256]
	Memory at fdef0000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at fde00000 [disabled] [size=128K]
	Capabilities: <available only to root>

0000:01:05.1 Display controller: ATI Technologies Inc: Unknown device 5854
	Subsystem: PC Partner Limited: Unknown device 0a57
	Flags: 66MHz, medium devsel
	Memory at <unassigned> (32-bit, prefetchable) [disabled]
	Memory at fde20000 (32-bit, non-prefetchable) [disabled] [size=64K]
	Capabilities: <available only to root>

0000:02:05.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
	Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget / Hauppauge WinTV-NOVA-S DVB card
	Flags: bus master, medium devsel, latency 64, IRQ 10
	Memory at fddff000 (32-bit, non-prefetchable) [size=512]

0000:02:06.0 Multimedia controller: Philips Semiconductors SAA7133 Video Broadcast Decoder (rev d0)
	Subsystem: Pinnacle Systems Inc.: Unknown device 002e
	Flags: bus master, medium devsel, latency 64, IRQ 11
	Memory at fddfe000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <available only to root>

0000:02:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c810 (rev 23)
	Subsystem: LSI Logic / Symbios Logic LSI53C810AE PCI to SCSI I/O Processor
	Flags: bus master, medium devsel, latency 64, IRQ 11
	I/O ports at da00 [size=256]
	Memory at fddfd000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <available only to root>

0000:02:08.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
	Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
	Flags: bus master, slow devsel, latency 64, IRQ 11
	I/O ports at df00 [size=64]
	Capabilities: <available only to root>

0000:02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
	Subsystem: PC Partner Limited: Unknown device 8169
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 3
	I/O ports at dc00 [size=256]
	Memory at fddfc000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at fdc00000 [disabled] [size=128K]
	Capabilities: <available only to root>

0000:02:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI])
	Subsystem: PC Partner Limited: Unknown device 3044
	Flags: bus master, stepping, medium devsel, latency 64, IRQ 11
	Memory at fddfb000 (32-bit, non-prefetchable) [size=2K]
	I/O ports at de00 [size=128]
	Capabilities: <available only to root>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-20 12:32 ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1 Carlo E. Prelz
@ 2006-01-21  9:09 ` Andrew Morton
  2006-01-21 12:57   ` Carlo E. Prelz
  0 siblings, 1 reply; 22+ messages in thread
From: Andrew Morton @ 2006-01-21  9:09 UTC (permalink / raw)
  To: Carlo E. Prelz; +Cc: linux-kernel

"Carlo E. Prelz" <fluido@fluido.as> wrote:
>
> Best regards to all and everyone. I just purchased a new RS480 (Radeon
>  XPress200)-based motherboard. It is a Sapphire Pure Performance
>  PP-A9RS480. Mine is equipped with an Athlon64 3200+. I am attaching
>  the output of lspci -v
> 
>  When booting with kernels from 2.6.15-rc1 up (tested with 2.6.15-rc1,
>  2.6.15-rc5, 2.6.15 and 2.6.16-rc1), the boot process freezes after
>  displaying messages retated to registering io schedulers:
> 
>  ...
>  ...
>  io scheduler noop registered
>  io scheduler anticipatory registered
>  io scheduler deadline registered
>  io scheduler cfq registered
> 
>  There is no OOPS of any kind. The disk activity led remains on. With
>  both 2.6.14 and 2.6.14.6, boot regularly continues with:
> 
>  Floppy drive(s): fd0 is 1.44M
>  FDC 0 is a post-1991 82077
>  loop: loaded (max 8 devices)
>  pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
>  nbd: registered device at major 43
>  ...
>  ...
> 
>  I tried to enable all debug options in configure, but no new message
>  appears. 
> 
>  Important: I obtain the same result (frozen after "io scheduler cfq
>  registered") when booting with a 100MB netinst debian sid bootdisk,
>  downloaded last night. An older (9 month old) Ubuntu bootdisk boots
>  perfectly. Both cd's are AMD64-specific.
> 

Can you please add `initcall_debug' to the kernel boot command line? 
That'll tell us which function got stuck.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-21  9:09 ` Andrew Morton
@ 2006-01-21 12:57   ` Carlo E. Prelz
  2006-01-21 20:58     ` Andrew Morton
  0 siblings, 1 reply; 22+ messages in thread
From: Carlo E. Prelz @ 2006-01-21 12:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Carlo E. Prelz, linux-kernel

	Subject: Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: sab 21 gen 06 01:09:32 -0800

Quoting Andrew Morton (akpm@osdl.org):

> Can you please add `initcall_debug' to the kernel boot command line? 
> That'll tell us which function got stuck.

I photographed the screen. I am copying here the last few lines. I
hope I make no errors in copying...

...
...
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Calling initcall 0xffffffff806de042: init_nlm+0x0/0x21()
Calling initcall 0xffffffff806de063: init_nls_cp437+0x0/0xc()
Calling initcall 0xffffffff806de06f: init_nls_cp850+0x0/0xc()
Calling initcall 0xffffffff806de07b: init_nls_cp852+0x0/0xc()
Calling initcall 0xffffffff806de087: init_nls_iso8859_1+0x0/0xc()
Calling initcall 0xffffffff806de093: init_nls_iso8859_15+0x0/0xc()
Calling initcall 0xffffffff806de09f: init_nls_utf8+0x0/0x1f()
Calling initcall 0xffffffff806de0be: init_autofs4_fs+0x0/0xc()
Calling initcall 0xffffffff806de0ca: init_udf_fs+0x0/0x53()
Calling initcall 0xffffffff806de11d: ipc_init+0x0/0x14()
Calling initcall 0xffffffff806de2ea: init_mqueue_fs+0x0/0xc7()
Calling initcall 0xffffffff806de51d: key_proc_init+0x0/0x52()
Calling initcall 0xffffffff806de67c: init_crypto+0x0/0x18()
Initializing Cryptographic API
Calling initcall 0xffffffff806de6b4: init+0x0/0xc()
Calling initcall 0xffffffff806de6c0: init+0x0/0xc()
Calling initcall 0xffffffff806de6cc: init+0x0/0xc()
Calling initcall 0xffffffff806de6d8: init+0x0/0xc()
Calling initcall 0xffffffff806de6e4: init+0x0/0x35()
Calling initcall 0xffffffff806de719: init+0x0/0x5a()
Calling initcall 0xffffffff806de773: init+0x0/0x5a()
Calling initcall 0xffffffff806de7cd: init+0x0/0x35()
Calling initcall 0xffffffff806de802: init+0x0/0xc()
Calling initcall 0xffffffff806de80e: init+0x0/0xc()
Calling initcall 0xffffffff806de81a: init+0x0/0x35()
Calling initcall 0xffffffff806de84f: init+0x0/0xc()
Calling initcall 0xffffffff806de85b: init+0x0/0xc()
Calling initcall 0xffffffff806de867: arc4_init+0x0/0xc()
Calling initcall 0xffffffff806de873: init+0x0/0x5a()
Calling initcall 0xffffffff806de8cd: init+0x0/0xc()
Calling initcall 0xffffffff806de8d9: init+0x0/0xc()
Calling initcall 0xffffffff806de8e5: init+0x0/0xc()
Calling initcall 0xffffffff806de8f1: michael_mic_init+0x0/0xc()
Calling initcall 0xffffffff806de8fd: init+0x0/0xc()
Calling initcall 0xffffffff806dea0a: noop_init+0x0/0xc()
Scheduler noop registered
Calling initcall 0xffffffff806dea16: as_init+0x0/0x4f()
Scheduler anticipatory registered
Calling initcall 0xffffffff806dea65: deadline_init+0x0/0x4f()
Scheduler deadline registered
Calling initcall 0xffffffff806deab4: cfq_init+0x0/0xc4()
Scheduler cfq registered
Calling initcall 0xffffffff8026836c: pci_init+0x0/0x2b()


And then the machine freezes. I may add that, with 2.6.14.6, I am
getting errors like:

APIC error on CPU0: 04(40)

or, more often

APIC error on CPU0: 40(40)

I tried either to pass noapic, or to disable apic in bios, and the
kernel entered a slow process of testing and refusing all addresses of
my SCSI card (I tried both an Advansys and a NCR: the result has been
the same) and then eventually gave an oops in ifconfig. I haven't
photographed those messages, but I will do so if needed. 

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-21 12:57   ` Carlo E. Prelz
@ 2006-01-21 20:58     ` Andrew Morton
  2006-01-21 21:28       ` Erwin Rol
  2006-01-22  7:40       ` Carlo E. Prelz
  0 siblings, 2 replies; 22+ messages in thread
From: Andrew Morton @ 2006-01-21 20:58 UTC (permalink / raw)
  To: Carlo E. Prelz; +Cc: fluido, linux-kernel

"Carlo E. Prelz" <fluido@fluido.as> wrote:
>
> 	Subject: Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
> 	Date: sab 21 gen 06 01:09:32 -0800
> 
> Quoting Andrew Morton (akpm@osdl.org):
> 
> > Can you please add `initcall_debug' to the kernel boot command line? 
> > That'll tell us which function got stuck.
> 
> I photographed the screen. I am copying here the last few lines. I
> hope I make no errors in copying...

Thanks.  That's probably more lines than we needed ;)

If you have a web server somewhere, just upload the .jpg file.  Or send it
to me and I can do that.

> ...
> ...
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> Calling initcall 0xffffffff806de042: init_nlm+0x0/0x21()
> Calling initcall 0xffffffff806de063: init_nls_cp437+0x0/0xc()
> Calling initcall 0xffffffff806de06f: init_nls_cp850+0x0/0xc()
> Calling initcall 0xffffffff806de07b: init_nls_cp852+0x0/0xc()
> Calling initcall 0xffffffff806de087: init_nls_iso8859_1+0x0/0xc()
> Calling initcall 0xffffffff806de093: init_nls_iso8859_15+0x0/0xc()
> Calling initcall 0xffffffff806de09f: init_nls_utf8+0x0/0x1f()
> Calling initcall 0xffffffff806de0be: init_autofs4_fs+0x0/0xc()
> Calling initcall 0xffffffff806de0ca: init_udf_fs+0x0/0x53()
> Calling initcall 0xffffffff806de11d: ipc_init+0x0/0x14()
> Calling initcall 0xffffffff806de2ea: init_mqueue_fs+0x0/0xc7()
> Calling initcall 0xffffffff806de51d: key_proc_init+0x0/0x52()
> Calling initcall 0xffffffff806de67c: init_crypto+0x0/0x18()
> Initializing Cryptographic API
> Calling initcall 0xffffffff806de6b4: init+0x0/0xc()
> Calling initcall 0xffffffff806de6c0: init+0x0/0xc()
> Calling initcall 0xffffffff806de6cc: init+0x0/0xc()
> Calling initcall 0xffffffff806de6d8: init+0x0/0xc()
> Calling initcall 0xffffffff806de6e4: init+0x0/0x35()
> Calling initcall 0xffffffff806de719: init+0x0/0x5a()
> Calling initcall 0xffffffff806de773: init+0x0/0x5a()
> Calling initcall 0xffffffff806de7cd: init+0x0/0x35()
> Calling initcall 0xffffffff806de802: init+0x0/0xc()
> Calling initcall 0xffffffff806de80e: init+0x0/0xc()
> Calling initcall 0xffffffff806de81a: init+0x0/0x35()
> Calling initcall 0xffffffff806de84f: init+0x0/0xc()
> Calling initcall 0xffffffff806de85b: init+0x0/0xc()
> Calling initcall 0xffffffff806de867: arc4_init+0x0/0xc()
> Calling initcall 0xffffffff806de873: init+0x0/0x5a()
> Calling initcall 0xffffffff806de8cd: init+0x0/0xc()
> Calling initcall 0xffffffff806de8d9: init+0x0/0xc()
> Calling initcall 0xffffffff806de8e5: init+0x0/0xc()

Oh dear.  We have 394 funtions all called 'init()' in the kernel. 
netfilter is a prime source.

> Calling initcall 0xffffffff806de8f1: michael_mic_init+0x0/0xc()
> Calling initcall 0xffffffff806de8fd: init+0x0/0xc()
> Calling initcall 0xffffffff806dea0a: noop_init+0x0/0xc()
> Scheduler noop registered
> Calling initcall 0xffffffff806dea16: as_init+0x0/0x4f()
> Scheduler anticipatory registered
> Calling initcall 0xffffffff806dea65: deadline_init+0x0/0x4f()
> Scheduler deadline registered
> Calling initcall 0xffffffff806deab4: cfq_init+0x0/0xc4()
> Scheduler cfq registered
> Calling initcall 0xffffffff8026836c: pci_init+0x0/0x2b()
> 
> 
> And then the machine freezes. I may add that, with 2.6.14.6, I am
> getting errors like:

OK, it looks like a PCI initcall went South.  Can you please add this, then
when it hangs, record the last few lines then send us those, as well as the
output of `lspci -vx'?

--- devel/drivers/pci/pci.c~a	2006-01-21 12:55:38.000000000 -0800
+++ devel-akpm/drivers/pci/pci.c	2006-01-21 12:56:51.000000000 -0800
@@ -886,6 +886,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("pci_init: %04x%04x\n", dev->vendor, dev->device);
 		pci_fixup_device(pci_fixup_final, dev);
 	}
 	return 0;
_


> APIC error on CPU0: 04(40)
> 
> or, more often
> 
> APIC error on CPU0: 40(40)
> 
> I tried either to pass noapic, or to disable apic in bios, and the
> kernel entered a slow process of testing and refusing all addresses of
> my SCSI card (I tried both an Advansys and a NCR: the result has been
> the same) and then eventually gave an oops in ifconfig. I haven't
> photographed those messages, but I will do so if needed. 
> 

Is this new behaviour?  If so, are you able to pinpoint the latest kernel
which didn't have such problems?


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-21 20:58     ` Andrew Morton
@ 2006-01-21 21:28       ` Erwin Rol
  2006-01-21 22:04         ` Dave Jones
  2006-01-22  7:40       ` Carlo E. Prelz
  1 sibling, 1 reply; 22+ messages in thread
From: Erwin Rol @ 2006-01-21 21:28 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Carlo E. Prelz, linux-kernel, Dave Jones

I had also had the problem that my Shuttle ST20G5 (a RS480 IGP based
system) hung in pci_init. This was with one of the Fedora Rawhide
kernels, after reporting it  Dave Jones fixed it cause the next rawhide
kernel worked again, maybe he could explain what it was, and where the
fix is (if it is the same thing, but it really looks like it).

- Erwin




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-21 21:28       ` Erwin Rol
@ 2006-01-21 22:04         ` Dave Jones
  2006-01-22  4:14           ` Kurt Wall
  0 siblings, 1 reply; 22+ messages in thread
From: Dave Jones @ 2006-01-21 22:04 UTC (permalink / raw)
  To: Erwin Rol; +Cc: Andrew Morton, Carlo E. Prelz, linux-kernel

On Sat, Jan 21, 2006 at 10:28:46PM +0100, Erwin Rol wrote:
 > I had also had the problem that my Shuttle ST20G5 (a RS480 IGP based
 > system) hung in pci_init. This was with one of the Fedora Rawhide
 > kernels, after reporting it  Dave Jones fixed it cause the next rawhide
 > kernel worked again, maybe he could explain what it was, and where the
 > fix is (if it is the same thing, but it really looks like it).

That was due to us carrying one of the 'make the clock not tick
at twice the speed on ati chipsets' patches. Matthew Garrett's variant iirc.
It worked fine in .14, but caused havoc in .15+

I put it down to the problem being fixed in other ways upstream.

		Dave


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-21 22:04         ` Dave Jones
@ 2006-01-22  4:14           ` Kurt Wall
  0 siblings, 0 replies; 22+ messages in thread
From: Kurt Wall @ 2006-01-22  4:14 UTC (permalink / raw)
  To: Dave Jones, Erwin Rol, Andrew Morton, Carlo E. Prelz, linux-kernel

On Sat, Jan 21, 2006 at 05:04:02PM -0500, Dave Jones took 21 lines to write:
> On Sat, Jan 21, 2006 at 10:28:46PM +0100, Erwin Rol wrote:
>  > I had also had the problem that my Shuttle ST20G5 (a RS480 IGP based
>  > system) hung in pci_init. This was with one of the Fedora Rawhide
>  > kernels, after reporting it  Dave Jones fixed it cause the next rawhide
>  > kernel worked again, maybe he could explain what it was, and where the
>  > fix is (if it is the same thing, but it really looks like it).
> 
> That was due to us carrying one of the 'make the clock not tick
> at twice the speed on ati chipsets' patches. Matthew Garrett's variant iirc.
> It worked fine in .14, but caused havoc in .15+
> 
> I put it down to the problem being fixed in other ways upstream.

Heh. I think you mean s/fixed/worked around/.

The bugme tracking this, 3927, is a joyous muddle of patches, 
patches to patches, workarounds, and dueling command line options. 
I ported this patch,
http://www.ussg.iu.edu/hypermail/linux/kernel/0504.0/1625.html,
to 2.6.16-rc1 to fix my pain, but 1) it didn't work without the
disable_timer_pin_1 kernel option and, 2) I don't think it's a fix 
so much as a workaround.

Kurt
-- 
I can read your mind, and you should be ashamed of yourself.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-21 20:58     ` Andrew Morton
  2006-01-21 21:28       ` Erwin Rol
@ 2006-01-22  7:40       ` Carlo E. Prelz
  2006-01-22  7:55         ` Andrew Morton
  1 sibling, 1 reply; 22+ messages in thread
From: Carlo E. Prelz @ 2006-01-22  7:40 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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

	Subject: Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: sab 21 gen 06 12:58:22 -0800

Quoting Andrew Morton (akpm@osdl.org):

> If you have a web server somewhere, just upload the .jpg file.  Or send it
> to me and I can do that.

The latest screenshot can be found at
http://www.fluido.as/files/images/screenshot.jpg

> > Calling initcall 0xffffffff8026836c: pci_init+0x0/0x2b()
> > 
> > 
> > And then the machine freezes. I may add that, with 2.6.14.6, I am
> > getting errors like:
> 
> OK, it looks like a PCI initcall went South.  Can you please add this, then
> when it hangs, record the last few lines then send us those, as well as the
> output of `lspci -vx'?

These lines appear at the end of the logfile:

pci_init: 10025950
pci_init: 10025a3f
pci_init: 1002437a
pci_init: 10024379
pci_init: 10024374
pci_init: 10024375
pci_init: 10024373

and 1002:4373 is the USB2 (EHCI) controller. I attach the output of
lspci -vx. Even with 2.6.14.6, I have problems with USB. It did not
work at all, then I downloaded the latest bios, and now, right after
boot, usb works OK. But after some time (possibly after the first APIC
error message), newly inserted USB disks are not detected anymore, and
I had one case in which a mounted disk was not accessible anymore. 

I just bought the motherboard - I did not make too many tests.

> Is this new behaviour?  If so, are you able to pinpoint the latest kernel
> which didn't have such problems?

The motherboard is new. With the previous motherboard (via k8t88
based), using the same processor and most of the same boards, I did
not have any of these problems.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

[-- Attachment #2: lspciout2 --]
[-- Type: text/plain, Size: 12003 bytes --]

0000:00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01)
	Subsystem: ATI Technologies Inc RS480 Host Bridge
	Flags: bus master, 66MHz, medium devsel, latency 64
00: 02 10 50 59 06 00 20 22 01 00 00 06 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 50 59
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f (prog-if 00 [Normal decode])
	Flags: bus master, 66MHz, medium devsel, latency 99
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: fde00000-fdefffff
	Prefetchable memory behind bridge: 00000000d8000000-00000000dff00000
	Capabilities: [44] #08 [a803]
	Capabilities: [b0] #0d [0000]
00: 02 10 3f 5a 07 00 30 02 00 00 04 06 00 63 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 44 e1 e1 20 02
20: e0 fd e0 fd 01 d8 f1 df 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 08 00

0000:00:11.0 IDE interface: ATI Technologies Inc ATI 437A Serial ATA Controller (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: ATI Technologies Inc ATI 437A Serial ATA Controller
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
	I/O ports at ff00 [size=8]
	I/O ports at fe00 [size=4]
	I/O ports at fd00 [size=8]
	I/O ports at fc00 [size=4]
	I/O ports at fb00 [size=16]
	Memory at fe02f000 (32-bit, non-prefetchable) [size=512]
	Expansion ROM at 40000000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 2
	Capabilities: [50] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
00: 02 10 7a 43 07 00 b0 02 00 8f 01 01 08 40 00 00
10: 01 ff 00 00 01 fe 00 00 01 fd 00 00 01 fc 00 00
20: 01 fb 00 00 00 f0 02 fe 00 00 00 00 02 10 7a 43
30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 00 00

0000:00:12.0 IDE interface: ATI Technologies Inc ATI 4379 Serial ATA Controller (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: ATI Technologies Inc ATI 4379 Serial ATA Controller
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5
	I/O ports at fa00 [size=8]
	I/O ports at f900 [size=4]
	I/O ports at f800 [size=8]
	I/O ports at f700 [size=4]
	I/O ports at f600 [size=16]
	Memory at fe02e000 (32-bit, non-prefetchable) [size=512]
	Expansion ROM at 40080000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 2
	Capabilities: [50] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
00: 02 10 79 43 07 00 b0 02 00 8f 01 01 08 40 00 00
10: 01 fa 00 00 01 f9 00 00 01 f8 00 00 01 f7 00 00
20: 01 f6 00 00 00 e0 02 fe 00 00 00 00 02 10 79 43
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 00 00

0000:00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
	Memory at fe02d000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
00: 02 10 74 43 07 00 b0 02 00 10 03 0c 10 40 80 00
10: 00 d0 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 56 0a
30: 00 00 00 00 d0 00 00 00 00 00 00 00 0a 01 00 00

0000:00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
	Memory at fe02c000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
00: 02 10 75 43 07 00 b0 02 00 10 03 0c 10 40 00 00
10: 00 c0 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 56 0a
30: 00 00 00 00 d0 00 00 00 00 00 00 00 0a 01 00 00

0000:00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (prog-if 20 [EHCI])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
	Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [dc] Power Management version 2
	Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
00: 02 10 73 43 17 00 b0 02 00 20 03 0c 10 40 00 00
10: 00 b0 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 56 0a
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 00 00

0000:00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 10)
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: 66MHz, medium devsel
	I/O ports at 0400 [size=16]
	Memory at fe02a000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [b0] #08 [a802]
00: 02 10 72 43 03 04 30 02 10 00 05 0c 00 00 80 00
10: 01 04 00 00 00 a0 02 fe 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 56 0a
30: 00 00 00 00 b0 00 00 00 00 00 00 00 00 00 00 00

0000:00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI (prog-if 8a [Master SecP PriP])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at f400 [size=16]
	Capabilities: [70] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
00: 02 10 76 43 05 00 30 02 00 8a 01 01 00 40 00 00
10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
20: 01 f4 00 00 00 00 00 00 00 00 00 00 4b 17 56 0a
30: 00 00 00 00 70 00 00 00 00 00 00 00 ff 01 00 00

0000:00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 0
00: 02 10 77 43 0f 00 20 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 56 0a
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge (prog-if 01 [Subtractive decode])
	Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64
	Bus: primary=00, secondary=02, subordinate=03, sec-latency=64
	I/O behind bridge: 0000c000-0000dfff
	Memory behind bridge: fdc00000-fddfffff
	Prefetchable memory behind bridge: fdb00000-fdbfffff
00: 02 10 71 43 27 00 a0 02 00 01 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 00 02 03 40 c1 d1 80 22
20: c0 fd d0 fd b0 fd b0 fd 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 01)
	Subsystem: PC Partner Limited: Unknown device 5215
	Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 17
	Memory at fe029000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [40] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
00: 02 10 70 43 07 00 30 04 01 00 01 04 08 40 80 00
10: 00 90 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 15 52
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 02 02 00

0000:01:05.0 VGA compatible controller: ATI Technologies Inc RS480 [Radeon Xpress 200G Series] (prog-if 00 [VGA])
	Subsystem: PC Partner Limited: Unknown device 0a56
	Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 11
	Memory at d8000000 (32-bit, prefetchable) [size=128M]
	I/O ports at ee00 [size=256]
	Memory at fdef0000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at fde00000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 2
00: 02 10 54 59 07 00 b0 02 00 00 00 03 08 ff 00 00
10: 08 00 00 d8 01 ee 00 00 00 00 ef fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 56 0a
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 08 00

0000:02:05.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
	Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget / Hauppauge WinTV-NOVA-S DVB card
	Flags: bus master, medium devsel, latency 64, IRQ 16
	Memory at fddff000 (32-bit, non-prefetchable) [size=512]
00: 31 11 46 71 06 00 80 02 01 00 80 04 00 40 00 00
10: 00 f0 df fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 c2 13 03 10
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 0f 26

0000:02:06.0 Multimedia controller: Philips Semiconductors SAA7133 Video Broadcast Decoder (rev d0)
	Subsystem: Pinnacle Systems Inc.: Unknown device 002e
	Flags: bus master, medium devsel, latency 64, IRQ 17
	Memory at fddfe000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [40] Power Management version 2
00: 31 11 33 71 06 00 90 02 d0 00 80 04 00 40 00 00
10: 00 e0 df fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 bd 11 2e 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 54 20

0000:02:07.0 PCI bridge: PicoPower Technology PT86C525 [Nile-II] PCI-to-PCI Bridge (rev 01) (prog-if 00 [Normal decode])
	Flags: bus master, medium devsel, latency 64
	Bus: primary=02, secondary=03, subordinate=03, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fdc00000-fdcfffff
	Prefetchable memory behind bridge: fdb00000-fdbfffff
00: 66 10 04 00 07 00 80 02 01 00 04 06 08 40 01 00
10: 00 00 00 00 00 00 00 00 02 03 03 20 c0 c0 80 02
20: c0 fd c0 fd b0 fd b0 fd 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00

0000:02:08.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
	Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
	Flags: bus master, slow devsel, latency 64, IRQ 17
	I/O ports at df00 [size=64]
	Capabilities: [dc] Power Management version 1
00: 74 12 71 13 05 01 10 04 06 00 01 04 00 40 00 00
10: 01 df 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 74 12 71 13
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 0c 80

0000:02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
	Subsystem: PC Partner Limited: Unknown device 8169
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
	I/O ports at dc00 [size=256]
	Memory at fddfd000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at fdd00000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
00: ec 10 69 81 17 00 b0 82 10 00 00 02 10 40 00 00
10: 01 dc 00 00 00 d0 df fd 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 69 81
30: 00 00 00 00 dc 00 00 00 00 00 00 00 03 01 20 40

0000:02:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI])
	Subsystem: PC Partner Limited: Unknown device 3044
	Flags: bus master, stepping, medium devsel, latency 64, IRQ 17
	Memory at fddfc000 (32-bit, non-prefetchable) [size=2K]
	I/O ports at de00 [size=128]
	Capabilities: [50] Power Management version 2
00: 06 11 44 30 87 00 10 02 80 10 00 0c 08 40 00 00
10: 00 c0 df fd 01 de 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 44 30
30: 00 00 00 00 50 00 00 00 00 00 00 00 01 01 00 20

0000:03:08.0 SCSI storage controller: Advanced System Products, Inc ABP940-U / ABP960-U (rev 03)
	Subsystem: Advanced System Products, Inc ASC1300 SCSI Adapter
	Flags: bus master, medium devsel, latency 64, IRQ 11
	I/O ports at ce00 [size=256]
	Memory at fdcff000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at fdb00000 [disabled] [size=64K]
00: cd 10 00 13 07 00 80 02 03 00 00 01 08 40 00 00
10: 01 ce 00 00 00 f0 cf fd 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 3f 00 00 00 cd 10 10 13
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 04 04

0000:03:09.0 Multimedia video controller: Zoran Corporation ZR36057PQC Video cutting chipset (rev 02)
	Subsystem: Iomega Corporation JPEG/TV Card
	Flags: bus master, fast devsel, latency 32, IRQ 18
	Memory at fdcfe000 (32-bit, non-prefetchable) [size=4K]
00: de 11 57 60 06 00 00 00 02 00 00 04 00 20 00 00
10: 00 e0 cf fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ca 13 31 42
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 02 10


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-22  7:40       ` Carlo E. Prelz
@ 2006-01-22  7:55         ` Andrew Morton
  2006-01-22  8:30           ` Carlo E. Prelz
                             ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Andrew Morton @ 2006-01-22  7:55 UTC (permalink / raw)
  To: Carlo E. Prelz; +Cc: linux-kernel, linux-usb-devel

"Carlo E. Prelz" <fluido@fluido.as> wrote:
>
> 	Subject: Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
> 	Date: sab 21 gen 06 12:58:22 -0800
> 
> Quoting Andrew Morton (akpm@osdl.org):
> 
> > If you have a web server somewhere, just upload the .jpg file.  Or send it
> > to me and I can do that.
> 
> The latest screenshot can be found at
> http://www.fluido.as/files/images/screenshot.jpg
> 
> > > Calling initcall 0xffffffff8026836c: pci_init+0x0/0x2b()
> > > 
> > > 
> > > And then the machine freezes. I may add that, with 2.6.14.6, I am
> > > getting errors like:
> > 
> > OK, it looks like a PCI initcall went South.  Can you please add this, then
> > when it hangs, record the last few lines then send us those, as well as the
> > output of `lspci -vx'?
> 
> These lines appear at the end of the logfile:
> 
> pci_init: 10025950
> pci_init: 10025a3f
> pci_init: 1002437a
> pci_init: 10024379
> pci_init: 10024374
> pci_init: 10024375
> pci_init: 10024373
> 
> and 1002:4373 is the USB2 (EHCI) controller. I attach the output of
> lspci -vx. Even with 2.6.14.6, I have problems with USB. It did not
> work at all, then I downloaded the latest bios, and now, right after
> boot, usb works OK.

OK, so it sounds like quirk_usb_disable_ehci() caused your machine to hang
with the old BIOS.  That's fairly bad behaviour from the kernel, even
though the BIOS presumably had some problems.

> But after some time (possibly after the first APIC
> error message), newly inserted USB disks are not detected anymore, and
> I had one case in which a mounted disk was not accessible anymore. 

Can you please gather some more details on this and prepare a new report? 
The full demsg output, machine description, etc.  It might be best to do
this via a new bugzilla.kernel.org record so we know where to find it.

Thanks.

> I just bought the motherboard - I did not make too many tests.
> 
> > Is this new behaviour?  If so, are you able to pinpoint the latest kernel
> > which didn't have such problems?
> 
> The motherboard is new. With the previous motherboard (via k8t88
> based), using the same processor and most of the same boards, I did
> not have any of these problems.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-22  7:55         ` Andrew Morton
@ 2006-01-22  8:30           ` Carlo E. Prelz
  2006-01-22 11:11           ` Carlo E. Prelz
  2006-01-23 19:01           ` David Brownell
  2 siblings, 0 replies; 22+ messages in thread
From: Carlo E. Prelz @ 2006-01-22  8:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-usb-devel

	Subject: Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: sab 21 gen 06 11:55:46 -0800

Quoting Andrew Morton (akpm@osdl.org):

> > and 1002:4373 is the USB2 (EHCI) controller. I attach the output of
> > lspci -vx. Even with 2.6.14.6, I have problems with USB. It did not
> > work at all, then I downloaded the latest bios, and now, right after
> > boot, usb works OK.
> 
> OK, so it sounds like quirk_usb_disable_ehci() caused your machine to hang
> with the old BIOS.  That's fairly bad behaviour from the kernel, even
> though the BIOS presumably had some problems.

It did not hang. When inserting USB disks, I got messages like:

ehci_hcd 0000:00:13.2: Unlink after no-IRQ?  Controller is probably using the wrong IRQ.
usb 1-1: device not accepting address 2, error -110

and the usb-storage module was not loaded. But the kernel went on
working. After upgrading the BIOS, with the same kernel, the USB disk
was recognized. But I now notice that the log file, with both old and
new BIOS, contains these lines:

ehci_hcd 0000:00:13.2: BIOS handoff failed (160, 01010001)
ehci_hcd 0000:00:13.2: continuing after BIOS bug...
ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:13.2: irq 18, io mem 0xfe02b000
ehci_hcd 0000:00:13.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004

(only, the IRQ number changed from 10 to 18 after changing BIOS)

> Can you please gather some more details on this and prepare a new report? 
> The full demsg output, machine description, etc.  It might be best to do
> this via a new bugzilla.kernel.org record so we know where to find
> it.

I will try that. I saw on apic.c that APIC error 40 should mean
'received illegal vector,' but I have no clue about how to interpret
this. 

I will now play a bit with BIOS USB parameters.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-22  7:55         ` Andrew Morton
  2006-01-22  8:30           ` Carlo E. Prelz
@ 2006-01-22 11:11           ` Carlo E. Prelz
  2006-02-05 10:33             ` Carlo E. Prelz
  2006-01-23 19:01           ` David Brownell
  2 siblings, 1 reply; 22+ messages in thread
From: Carlo E. Prelz @ 2006-01-22 11:11 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-usb-devel

	Subject: Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: sab 21 gen 06 11:55:46 -0800

Quoting Andrew Morton (akpm@osdl.org):

> Can you please gather some more details on this and prepare a new report? 
> The full demsg output, machine description, etc.  It might be best to do
> this via a new bugzilla.kernel.org record so we know where to find it.

I filed bug #5935.

The BIOS contains 4 fields related to USB. In the 'Integrated
peripherals' menu:

USB EHCI Controller
Onchip USB Controller
Onchip USB KBC Controller

In the 'PnP/PCI configurations' menu: 

Assign IRQ for USB

All four only allow a choice between enable/disable. As expected,
disabling the first one makes the 0000:00:13.2 pci device
disappear. This results in the completing of the boot process. I am
writing this from a working 2.6.15 kernel, and I can mount my USB hard
disk. It probably works in 1.1 mode. 

I noticed that the new motherboard's USB device is OHCI-based, while
the previous one was UHCI-based. The OHCI driver was previously not
compiled in. EHCI was functional even without a working OHCI module
(in 2.6.14). Compiling in the OHCI driver has had no effect in the
boot hang with EHCI enabled - the machine still hangs, and the output
is identical.

Disabling the second field (Onchip USB Controller) makes all USB
devices disappear - boot is OK, but there is no usb activity at all.

The third field has no evident effect. This is true of the fourth one
too (the one about IRQ assignment). I saw no change in boot logs. 

Complete dmesg output for the successful 2.6.15 boot with EHCI
disabled can be downloaded from http://www.fluido.as/files/dmesg.txt. 

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-22  7:55         ` Andrew Morton
  2006-01-22  8:30           ` Carlo E. Prelz
  2006-01-22 11:11           ` Carlo E. Prelz
@ 2006-01-23 19:01           ` David Brownell
  2006-01-23 21:47             ` Carlo E. Prelz
  2006-01-24  4:42             ` Greg KH
  2 siblings, 2 replies; 22+ messages in thread
From: David Brownell @ 2006-01-23 19:01 UTC (permalink / raw)
  To: linux-usb-devel; +Cc: Andrew Morton, Carlo E. Prelz, linux-kernel

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


> OK, so it sounds like quirk_usb_disable_ehci() caused your machine to hang
> with the old BIOS.  That's fairly bad behaviour from the kernel, even
> though the BIOS presumably had some problems.

I think what happened is the "always run quirks" code got turned into
the default too early, before the EHCI "quirk" version of the handoff
code got checked against what most systems have been using for the past
several years.

I noticed at least one suspicous thing:  it enables an SMI IRQ.
Even in cases when the boot firmware says it's not using EHCI ...
easy to imagine that causing hangage.


Maybe this time it'd help to tell your BIOS "yes, DO use USB".
Or, the attached patch might help.  Please try both experiments.

- Dave



[-- Attachment #2: ehci-handoff.patch --]
[-- Type: text/x-diff, Size: 7247 bytes --]

This moves the previously widely-used ehci-pci.c BIOS handoff
code into the pci-quirks.c file, replacing the less widely used
"early handoff" version that seems to cause problems lately.

One notable change:  the "early handoff" version always enabled
an SMI IRQ ... and did so even if the pre-Linux code said it was
not using EHCI (and not expecting EHCI SMIs).  Looks like a goof
in a workaround for some unknown BIOS version.

This merged version only forcibly enables those IRQs when pre-Linux
code says it's using EHCI.  And now it always forces them off "just
in case".

EXPERIMENTAL


Index: g26/drivers/usb/host/ehci-pci.c
===================================================================
--- g26.orig/drivers/usb/host/ehci-pci.c	2006-01-15 12:59:13.000000000 -0800
+++ g26/drivers/usb/host/ehci-pci.c	2006-01-22 09:17:54.000000000 -0800
@@ -24,40 +24,6 @@
 
 /*-------------------------------------------------------------------------*/
 
-/* EHCI 0.96 (and later) section 5.1 says how to kick BIOS/SMM/...
- * off the controller (maybe it can boot from highspeed USB disks).
- */
-static int bios_handoff(struct ehci_hcd *ehci, int where, u32 cap)
-{
-	struct pci_dev *pdev = to_pci_dev(ehci_to_hcd(ehci)->self.controller);
-
-	/* always say Linux will own the hardware */
-	pci_write_config_byte(pdev, where + 3, 1);
-
-	/* maybe wait a while for BIOS to respond */
-	if (cap & (1 << 16)) {
-		int msec = 5000;
-
-		do {
-			msleep(10);
-			msec -= 10;
-			pci_read_config_dword(pdev, where, &cap);
-		} while ((cap & (1 << 16)) && msec);
-		if (cap & (1 << 16)) {
-			ehci_err(ehci, "BIOS handoff failed (%d, %08x)\n",
-				where, cap);
-			// some BIOS versions seem buggy...
-			// return 1;
-			ehci_warn(ehci, "continuing after BIOS bug...\n");
-			/* disable all SMIs, and clear "BIOS owns" flag */
-			pci_write_config_dword(pdev, where + 4, 0);
-			pci_write_config_byte(pdev, where + 2, 0);
-		} else
-			ehci_dbg(ehci, "BIOS handoff succeeded\n");
-	}
-	return 0;
-}
-
 /* called after powerup, by probe or system-pm "wakeup" */
 static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
 {
@@ -84,32 +50,9 @@ static int ehci_pci_reinit(struct ehci_h
 		}
 	}
 
-	temp = HCC_EXT_CAPS(readl(&ehci->caps->hcc_params));
-
-	/* EHCI 0.96 and later may have "extended capabilities" */
-	while (temp && count--) {
-		u32		cap;
-
-		pci_read_config_dword(pdev, temp, &cap);
-		ehci_dbg(ehci, "capability %04x at %02x\n", cap, temp);
-		switch (cap & 0xff) {
-		case 1:			/* BIOS/SMM/... handoff */
-			if (bios_handoff(ehci, temp, cap) != 0)
-				return -EOPNOTSUPP;
-			break;
-		case 0:			/* illegal reserved capability */
-			ehci_dbg(ehci, "illegal capability!\n");
-			cap = 0;
-			/* FALLTHROUGH */
-		default:		/* unknown */
-			break;
-		}
-		temp = (cap >> 8) & 0xff;
-	}
-	if (!count) {
-		ehci_err(ehci, "bogus capabilities ... PCI problems!\n");
-		return -EIO;
-	}
+	/* we expect static quirk code to handle the "extended capabilities"
+	 * (currently just BIOS handoff) allowed starting with EHCI 0.96
+	 */
 
 	/* PCI Memory-Write-Invalidate cycle support is optional (uncommon) */
 	retval = pci_set_mwi(pdev);
Index: g26/drivers/usb/host/pci-quirks.c
===================================================================
--- g26.orig/drivers/usb/host/pci-quirks.c	2006-01-05 17:35:38.000000000 -0800
+++ g26/drivers/usb/host/pci-quirks.c	2006-01-22 11:20:52.000000000 -0800
@@ -190,7 +190,7 @@ static void __devinit quirk_usb_handoff_
 			msleep(10);
 		}
 		if (wait_time <= 0)
-			printk(KERN_WARNING "%s %s: early BIOS handoff "
+			printk(KERN_WARNING "%s %s: BIOS handoff "
 					"failed (BIOS bug ?)\n",
 					pdev->dev.bus_id, "OHCI");
 
@@ -212,8 +212,9 @@ static void __devinit quirk_usb_disable_
 {
 	int wait_time, delta;
 	void __iomem *base, *op_reg_base;
-	u32 hcc_params, val, temp;
-	u8 cap_length;
+	u32	hcc_params, val;
+	u8	offset, cap_length;
+	int	count = 256/4;
 
 	if (!mmio_resource_enabled(pdev, 0))
 		return;
@@ -224,51 +225,80 @@ static void __devinit quirk_usb_disable_
 
 	cap_length = readb(base);
 	op_reg_base = base + cap_length;
+
+	/* EHCI 0.96 and later may have "extended capabilities"
+	 * spec section 5.1 explains the bios handoff, e.g. for
+	 * booting from USB disk or using a usb keyboard
+	 */
 	hcc_params = readl(base + EHCI_HCC_PARAMS);
-	hcc_params = (hcc_params >> 8) & 0xff;
-	if (hcc_params) {
-		pci_read_config_dword(pdev,
-					hcc_params + EHCI_USBLEGSUP,
-					&val);
-		if (((val & 0xff) == 1) && (val & EHCI_USBLEGSUP_BIOS)) {
-			/*
-			 * Ok, BIOS is in smm mode, try to hand off...
-			 */
-			pci_read_config_dword(pdev,
-						hcc_params + EHCI_USBLEGCTLSTS,
-						&temp);
-			pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGCTLSTS,
-						temp | EHCI_USBLEGCTLSTS_SOOE);
-			val |= EHCI_USBLEGSUP_OS;
-			pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGSUP,
-						val);
+	offset = (hcc_params >> 8) & 0xff;
+	while (offset && count--) {
+		u32		cap;
+		int		msec;
+
+		pci_read_config_dword(pdev, offset, &cap);
+		switch (cap & 0xff) {
+		case 1:			/* BIOS/SMM/... handoff support */
+			if ((cap & EHCI_USBLEGSUP_BIOS)) {
+				pr_debug("%s %s: BIOS handoff\n",
+						pdev->dev.bus_id, "EHCI");
 
-			wait_time = 500;
-			do {
-				msleep(10);
-				wait_time -= 10;
+				/* BIOS workaround (?): be sure the
+				 * pre-Linux code receives the SMI
+				 */
 				pci_read_config_dword(pdev,
-						hcc_params + EHCI_USBLEGSUP,
+						offset + EHCI_USBLEGCTLSTS,
 						&val);
-			} while (wait_time && (val & EHCI_USBLEGSUP_BIOS));
-			if (!wait_time) {
-				/*
-				 * well, possibly buggy BIOS...
+				pci_write_config_dword(pdev,
+						offset + EHCI_USBLEGCTLSTS,
+						val | EHCI_USBLEGCTLSTS_SOOE);
+			}
+
+			/* always say Linux will own the hardware
+			 * by setting EHCI_USBLEGSUP_OS.
+			 */
+			pci_write_config_byte(pdev, offset + 3, 1);
+
+			/* if boot firmware now owns EHCI, spin till
+			 * it hands it over.
+			 */
+			msec = 5000;
+			while ((cap & EHCI_USBLEGSUP_BIOS) && (msec > 0)) {
+				msleep(10);
+				msec -= 10;
+				pci_read_config_dword(pdev, offset, &cap);
+			}
+
+			if (cap & EHCI_USBLEGSUP_BIOS) {
+				/* well, possibly buggy BIOS... try to shut
+				 * it down, and hope nothing goes too wrong
 				 */
-				printk(KERN_WARNING "%s %s: early BIOS handoff "
+				printk(KERN_WARNING "%s %s: BIOS handoff "
 						"failed (BIOS bug ?)\n",
 					pdev->dev.bus_id, "EHCI");
-				pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGSUP,
-						EHCI_USBLEGSUP_OS);
-				pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGCTLSTS,
-						0);
+				pci_write_config_byte(pdev, offset + 2, 0);
 			}
+
+			/* just in case, always disable EHCI SMIs */
+			pci_write_config_dword(pdev,
+					offset + EHCI_USBLEGCTLSTS,
+					0);
+			break;
+		case 0:			/* illegal reserved capability */
+			cap = 0;
+			/* FALLTHROUGH */
+		default:
+			printk(KERN_WARNING "%s %s: unrecognized "
+					"capability %02x\n",
+					pdev->dev.bus_id, "EHCI",
+					cap & 0xff);
+			break;
 		}
+		offset = (cap >> 8) & 0xff;
 	}
+	if (!count)
+		printk(KERN_DEBUG "%s %s: capability loop?\n",
+				pdev->dev.bus_id, "EHCI");
 
 	/*
 	 * halt EHCI & disable its interrupts in any case

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-23 19:01           ` David Brownell
@ 2006-01-23 21:47             ` Carlo E. Prelz
  2006-01-24  4:42             ` Greg KH
  1 sibling, 0 replies; 22+ messages in thread
From: Carlo E. Prelz @ 2006-01-23 21:47 UTC (permalink / raw)
  To: David Brownell; +Cc: linux-usb-devel, Andrew Morton, linux-kernel

	Subject: Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: lun 23 gen 06 11:01:25 -0800

Quoting David Brownell (david-b@pacbell.net):

> Maybe this time it'd help to tell your BIOS "yes, DO use USB".

That I am doing. And I now have the appropriate OHCI module
loaded. USB 1.1 works apparently quite OK. 

> Or, the attached patch might help.  

I applied the patch. The three changes to the second file applied with
an offset of 6 lines (to 2.6.15 vanilla). Nothing changed: the booting
process hung at the same place, generating the same printout as
before. I have now booted the new kernel with EHCI disabled, and saved
the dmesg oputput to http://www.fluido.as/files/dmesg2.txt (here,
USB1.1 is active).

It is time for sleep for me. I will perform any new test tomorrow
morning.

Carlo


-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-23 19:01           ` David Brownell
  2006-01-23 21:47             ` Carlo E. Prelz
@ 2006-01-24  4:42             ` Greg KH
  2006-01-24 15:15               ` David Brownell
  1 sibling, 1 reply; 22+ messages in thread
From: Greg KH @ 2006-01-24  4:42 UTC (permalink / raw)
  To: David Brownell
  Cc: linux-usb-devel, Andrew Morton, Carlo E. Prelz, linux-kernel

On Mon, Jan 23, 2006 at 11:01:25AM -0800, David Brownell wrote:
> This moves the previously widely-used ehci-pci.c BIOS handoff
> code into the pci-quirks.c file, replacing the less widely used
> "early handoff" version that seems to cause problems lately.
> 
> One notable change:  the "early handoff" version always enabled
> an SMI IRQ ... and did so even if the pre-Linux code said it was
> not using EHCI (and not expecting EHCI SMIs).  Looks like a goof
> in a workaround for some unknown BIOS version.
> 
> This merged version only forcibly enables those IRQs when pre-Linux
> code says it's using EHCI.  And now it always forces them off "just
> in case".

Thanks for posting this, it fixes my EHCI + APIC error, and makes my
laptop work just fine.

Turns out that 2.6.14 worked for it, but 2.6.15 didn't.  git bisect a
zillion times later narrowed it down to the usb early handoff stuff but
due to merge issues, it was tough to track down the exact patch.

For fun I tried this one on top of the latest -mm, and it works!

So, care to clean it up to make it feel better to you and send it to me
again so I can add it to my tree?  I know the next SuSE kernel will need
it :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-24  4:42             ` Greg KH
@ 2006-01-24 15:15               ` David Brownell
  0 siblings, 0 replies; 22+ messages in thread
From: David Brownell @ 2006-01-24 15:15 UTC (permalink / raw)
  To: linux-usb-devel; +Cc: Greg KH, Andrew Morton, Carlo E. Prelz, linux-kernel

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

On Monday 23 January 2006 8:42 pm, Greg KH wrote:
> On Mon, Jan 23, 2006 at 11:01:25AM -0800, David Brownell wrote:
> > This moves the previously widely-used ehci-pci.c BIOS handoff
> > code into the pci-quirks.c file, replacing the less widely used
> > "early handoff" version that seems to cause problems lately.
> > 
> > One notable change:  the "early handoff" version always enabled
> > an SMI IRQ ... and did so even if the pre-Linux code said it was
> > not using EHCI (and not expecting EHCI SMIs).  Looks like a goof
> > in a workaround for some unknown BIOS version.
> > 
> > This merged version only forcibly enables those IRQs when pre-Linux
> > code says it's using EHCI.  And now it always forces them off "just
> > in case".
> 
> Thanks for posting this, it fixes my EHCI + APIC error, and makes my
> laptop work just fine.

OK, here's a version with a Signed-Off-By; against current GIT.

I'm mildly surprised it helps that laptop, but not surprised that
it helps _some_ of those "ehci init goofs" cases.  :)

- Dave




[-- Attachment #2: ehci-handoff.patch --]
[-- Type: text/x-diff, Size: 7297 bytes --]

This moves the previously widely-used ehci-pci.c BIOS handoff
code into the pci-quirks.c file, replacing the less widely used
"early handoff" version that seems to cause problems lately.

One notable change:  the "early handoff" version always enabled
an SMI IRQ ... and did so even if the pre-Linux code said it was
not using EHCI (and not expecting EHCI SMIs).  Looks like a goof
in a workaround for some unknown BIOS version.

This merged version only forcibly enables those IRQs when pre-Linux
code says it's using EHCI.  And now it always forces them off "just
in case".

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Index: g26/drivers/usb/host/ehci-pci.c
===================================================================
--- g26.orig/drivers/usb/host/ehci-pci.c	2006-01-15 12:59:13.000000000 -0800
+++ g26/drivers/usb/host/ehci-pci.c	2006-01-22 09:17:54.000000000 -0800
@@ -24,40 +24,6 @@
 
 /*-------------------------------------------------------------------------*/
 
-/* EHCI 0.96 (and later) section 5.1 says how to kick BIOS/SMM/...
- * off the controller (maybe it can boot from highspeed USB disks).
- */
-static int bios_handoff(struct ehci_hcd *ehci, int where, u32 cap)
-{
-	struct pci_dev *pdev = to_pci_dev(ehci_to_hcd(ehci)->self.controller);
-
-	/* always say Linux will own the hardware */
-	pci_write_config_byte(pdev, where + 3, 1);
-
-	/* maybe wait a while for BIOS to respond */
-	if (cap & (1 << 16)) {
-		int msec = 5000;
-
-		do {
-			msleep(10);
-			msec -= 10;
-			pci_read_config_dword(pdev, where, &cap);
-		} while ((cap & (1 << 16)) && msec);
-		if (cap & (1 << 16)) {
-			ehci_err(ehci, "BIOS handoff failed (%d, %08x)\n",
-				where, cap);
-			// some BIOS versions seem buggy...
-			// return 1;
-			ehci_warn(ehci, "continuing after BIOS bug...\n");
-			/* disable all SMIs, and clear "BIOS owns" flag */
-			pci_write_config_dword(pdev, where + 4, 0);
-			pci_write_config_byte(pdev, where + 2, 0);
-		} else
-			ehci_dbg(ehci, "BIOS handoff succeeded\n");
-	}
-	return 0;
-}
-
 /* called after powerup, by probe or system-pm "wakeup" */
 static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
 {
@@ -84,32 +50,9 @@ static int ehci_pci_reinit(struct ehci_h
 		}
 	}
 
-	temp = HCC_EXT_CAPS(readl(&ehci->caps->hcc_params));
-
-	/* EHCI 0.96 and later may have "extended capabilities" */
-	while (temp && count--) {
-		u32		cap;
-
-		pci_read_config_dword(pdev, temp, &cap);
-		ehci_dbg(ehci, "capability %04x at %02x\n", cap, temp);
-		switch (cap & 0xff) {
-		case 1:			/* BIOS/SMM/... handoff */
-			if (bios_handoff(ehci, temp, cap) != 0)
-				return -EOPNOTSUPP;
-			break;
-		case 0:			/* illegal reserved capability */
-			ehci_dbg(ehci, "illegal capability!\n");
-			cap = 0;
-			/* FALLTHROUGH */
-		default:		/* unknown */
-			break;
-		}
-		temp = (cap >> 8) & 0xff;
-	}
-	if (!count) {
-		ehci_err(ehci, "bogus capabilities ... PCI problems!\n");
-		return -EIO;
-	}
+	/* we expect static quirk code to handle the "extended capabilities"
+	 * (currently just BIOS handoff) allowed starting with EHCI 0.96
+	 */
 
 	/* PCI Memory-Write-Invalidate cycle support is optional (uncommon) */
 	retval = pci_set_mwi(pdev);
Index: g26/drivers/usb/host/pci-quirks.c
===================================================================
--- g26.orig/drivers/usb/host/pci-quirks.c	2006-01-05 17:35:38.000000000 -0800
+++ g26/drivers/usb/host/pci-quirks.c	2006-01-22 11:20:52.000000000 -0800
@@ -190,7 +190,7 @@ static void __devinit quirk_usb_handoff_
 			msleep(10);
 		}
 		if (wait_time <= 0)
-			printk(KERN_WARNING "%s %s: early BIOS handoff "
+			printk(KERN_WARNING "%s %s: BIOS handoff "
 					"failed (BIOS bug ?)\n",
 					pdev->dev.bus_id, "OHCI");
 
@@ -212,8 +212,9 @@ static void __devinit quirk_usb_disable_
 {
 	int wait_time, delta;
 	void __iomem *base, *op_reg_base;
-	u32 hcc_params, val, temp;
-	u8 cap_length;
+	u32	hcc_params, val;
+	u8	offset, cap_length;
+	int	count = 256/4;
 
 	if (!mmio_resource_enabled(pdev, 0))
 		return;
@@ -224,51 +225,80 @@ static void __devinit quirk_usb_disable_
 
 	cap_length = readb(base);
 	op_reg_base = base + cap_length;
+
+	/* EHCI 0.96 and later may have "extended capabilities"
+	 * spec section 5.1 explains the bios handoff, e.g. for
+	 * booting from USB disk or using a usb keyboard
+	 */
 	hcc_params = readl(base + EHCI_HCC_PARAMS);
-	hcc_params = (hcc_params >> 8) & 0xff;
-	if (hcc_params) {
-		pci_read_config_dword(pdev,
-					hcc_params + EHCI_USBLEGSUP,
-					&val);
-		if (((val & 0xff) == 1) && (val & EHCI_USBLEGSUP_BIOS)) {
-			/*
-			 * Ok, BIOS is in smm mode, try to hand off...
-			 */
-			pci_read_config_dword(pdev,
-						hcc_params + EHCI_USBLEGCTLSTS,
-						&temp);
-			pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGCTLSTS,
-						temp | EHCI_USBLEGCTLSTS_SOOE);
-			val |= EHCI_USBLEGSUP_OS;
-			pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGSUP,
-						val);
+	offset = (hcc_params >> 8) & 0xff;
+	while (offset && count--) {
+		u32		cap;
+		int		msec;
+
+		pci_read_config_dword(pdev, offset, &cap);
+		switch (cap & 0xff) {
+		case 1:			/* BIOS/SMM/... handoff support */
+			if ((cap & EHCI_USBLEGSUP_BIOS)) {
+				pr_debug("%s %s: BIOS handoff\n",
+						pdev->dev.bus_id, "EHCI");
 
-			wait_time = 500;
-			do {
-				msleep(10);
-				wait_time -= 10;
+				/* BIOS workaround (?): be sure the
+				 * pre-Linux code receives the SMI
+				 */
 				pci_read_config_dword(pdev,
-						hcc_params + EHCI_USBLEGSUP,
+						offset + EHCI_USBLEGCTLSTS,
 						&val);
-			} while (wait_time && (val & EHCI_USBLEGSUP_BIOS));
-			if (!wait_time) {
-				/*
-				 * well, possibly buggy BIOS...
+				pci_write_config_dword(pdev,
+						offset + EHCI_USBLEGCTLSTS,
+						val | EHCI_USBLEGCTLSTS_SOOE);
+			}
+
+			/* always say Linux will own the hardware
+			 * by setting EHCI_USBLEGSUP_OS.
+			 */
+			pci_write_config_byte(pdev, offset + 3, 1);
+
+			/* if boot firmware now owns EHCI, spin till
+			 * it hands it over.
+			 */
+			msec = 5000;
+			while ((cap & EHCI_USBLEGSUP_BIOS) && (msec > 0)) {
+				msleep(10);
+				msec -= 10;
+				pci_read_config_dword(pdev, offset, &cap);
+			}
+
+			if (cap & EHCI_USBLEGSUP_BIOS) {
+				/* well, possibly buggy BIOS... try to shut
+				 * it down, and hope nothing goes too wrong
 				 */
-				printk(KERN_WARNING "%s %s: early BIOS handoff "
+				printk(KERN_WARNING "%s %s: BIOS handoff "
 						"failed (BIOS bug ?)\n",
 					pdev->dev.bus_id, "EHCI");
-				pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGSUP,
-						EHCI_USBLEGSUP_OS);
-				pci_write_config_dword(pdev,
-						hcc_params + EHCI_USBLEGCTLSTS,
-						0);
+				pci_write_config_byte(pdev, offset + 2, 0);
 			}
+
+			/* just in case, always disable EHCI SMIs */
+			pci_write_config_dword(pdev,
+					offset + EHCI_USBLEGCTLSTS,
+					0);
+			break;
+		case 0:			/* illegal reserved capability */
+			cap = 0;
+			/* FALLTHROUGH */
+		default:
+			printk(KERN_WARNING "%s %s: unrecognized "
+					"capability %02x\n",
+					pdev->dev.bus_id, "EHCI",
+					cap & 0xff);
+			break;
 		}
+		offset = (cap >> 8) & 0xff;
 	}
+	if (!count)
+		printk(KERN_DEBUG "%s %s: capability loop?\n",
+				pdev->dev.bus_id, "EHCI");
 
 	/*
 	 * halt EHCI & disable its interrupts in any case

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-01-22 11:11           ` Carlo E. Prelz
@ 2006-02-05 10:33             ` Carlo E. Prelz
  2006-02-05 19:45               ` [linux-usb-devel] " David Brownell
  0 siblings, 1 reply; 22+ messages in thread
From: Carlo E. Prelz @ 2006-02-05 10:33 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel, linux-usb-devel

Time has passed without further mention of this problem. Today I took
some time to discover exactly where the boot process was hanging. I
found the place. 

In drivers/usb/host/pci-quirks.c, in function quirk_usb_disable_ehci
(should start around line 211) there is a stanza that reads:

			/* always say Linux will own the hardware
			 * by setting EHCI_USBLEGSUP_OS.
			 */

			pci_write_config_byte(pdev, offset + 3, 1);

On my sapphire athlon64 motherboard (see the thread for more details),
this call never returns (without generating any output). I commented
it out, and now the EHCI subsystem works OK (currently running
2.6.16rc2).

I do not know what the right patch should be. 

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-02-05 10:33             ` Carlo E. Prelz
@ 2006-02-05 19:45               ` David Brownell
  2006-02-06  8:02                 ` Carlo E. Prelz
  0 siblings, 1 reply; 22+ messages in thread
From: David Brownell @ 2006-02-05 19:45 UTC (permalink / raw)
  To: linux-usb-devel; +Cc: Carlo E. Prelz, Andrew Morton, linux-kernel

On Sunday 05 February 2006 2:33 am, Carlo E. Prelz wrote:
> In drivers/usb/host/pci-quirks.c, in function quirk_usb_disable_ehci
> (should start around line 211) there is a stanza that reads:
> 
> 			/* always say Linux will own the hardware
> 			 * by setting EHCI_USBLEGSUP_OS.
> 			 */
> 			pci_write_config_byte(pdev, offset + 3, 1);
> 
> On my sapphire athlon64 motherboard (see the thread for more details),
> this call never returns (without generating any output). I commented
> it out, and now the EHCI subsystem works OK (currently running
> 2.6.16rc2).

Interesting ... feels like a BIOS problem.  If you want to experiment,
there's a right bracket -- "}" -- immediately before that.  Try moving
it right after that write, so that write_config_byte is covered by the
preceding "if LEGSUP_BIOS" test; or copying the much later "disable SMI"
clause into an "else" for that "if".

- Dave

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-02-05 19:45               ` [linux-usb-devel] " David Brownell
@ 2006-02-06  8:02                 ` Carlo E. Prelz
  2006-02-06 16:24                   ` David Brownell
  0 siblings, 1 reply; 22+ messages in thread
From: Carlo E. Prelz @ 2006-02-06  8:02 UTC (permalink / raw)
  To: David Brownell; +Cc: linux-usb-devel, Andrew Morton, linux-kernel

	Subject: Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: dom 05 feb 06 11:45:22 -0800

Quoting David Brownell (david-b@pacbell.net):

> Interesting ... feels like a BIOS problem.  If you want to experiment,
> there's a right bracket -- "}" -- immediately before that.  Try moving
> it right after that write, so that write_config_byte is covered by the
> preceding "if LEGSUP_BIOS" test; or copying the much later "disable SMI"
> clause into an "else" for that "if".

The first one would be useless - I inserted lots of printouts to find
out where the freeze took place, and I know that the 
EHCI_USBLEGSUP_BIOS flag is on (cap is 0x10001). The value remains the
same after the 'spin till it hands it over' loop - so that this
printout appears:

0000:00:13.2 EHCI: BIOS handoff failed (BIOS bug ?)

About the second thing you suggest: do you refer to this call?

			/* just in case, always disable EHCI SMIs */
			pci_write_config_dword(pdev,
					offset + EHCI_USBLEGCTLSTS,
					0);

In my machine, the write takes place without apparent ill effects. If
I add it as an else clause to the "if LEGSUP_BIOS" test, it won't
execute, because the EHCI_USBLEGSUP_BIOS flag is on.

In case you need it: hcc_params is 0xa012. 

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-02-06  8:02                 ` Carlo E. Prelz
@ 2006-02-06 16:24                   ` David Brownell
  2006-02-06 16:50                     ` Carlo E. Prelz
  0 siblings, 1 reply; 22+ messages in thread
From: David Brownell @ 2006-02-06 16:24 UTC (permalink / raw)
  To: Carlo E. Prelz; +Cc: linux-usb-devel, Andrew Morton, linux-kernel

On Monday 06 February 2006 12:02 am, Carlo E. Prelz wrote:
> 
> > Interesting ... feels like a BIOS problem.  If you want to experiment,
> > there's a right bracket -- "}" -- immediately before that.  Try moving
> > it right after that write, so that write_config_byte is covered by the
> > preceding "if LEGSUP_BIOS" test; or copying the much later "disable SMI"
> > clause into an "else" for that "if".
> 
> The first one would be useless - I inserted lots of printouts to find
> out where the freeze took place, and I know that the 
> EHCI_USBLEGSUP_BIOS flag is on (cap is 0x10001). The value remains the
> same after the 'spin till it hands it over' loop - so that this
> printout appears:
> 
> 0000:00:13.2 EHCI: BIOS handoff failed (BIOS bug ?)

If it printed that, then how is it possible that it hung _before_ printing
that message???  Your reports are not making any sense to me.

Maybe that whole "if" block that turns that SMI _on_ is the problem; it
was part of the "early handoff" code, which came from who knows where,
was clearly buggy, and was never widely used until recently.  Enabling
the SMI seemed pretty dubious to me, but I suspect that some undescribed
buggy BIOS really does need it ... maybe whoever provided that "early"
handoff version could report what they were trying to do by enabling
the SMI?

- Dave


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-02-06 16:24                   ` David Brownell
@ 2006-02-06 16:50                     ` Carlo E. Prelz
  2006-02-06 17:31                       ` David Brownell
  0 siblings, 1 reply; 22+ messages in thread
From: Carlo E. Prelz @ 2006-02-06 16:50 UTC (permalink / raw)
  To: David Brownell; +Cc: linux-usb-devel, Andrew Morton, linux-kernel

	Subject: Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: Mon 06 Feb 06 08:24:04AM -0800

Quoting David Brownell (david-b@pacbell.net):

> If it printed that, then how is it possible that it hung _before_ printing
> that message???

I already wrote that I had commented out the line that caused the
hangup:

//			pci_write_config_byte(pdev, offset + 3, 1);

After commenting out this line, the machine boots OK and EHCI works
fine. It does print the BIOS handoff failed message. 

If I do not comment out the above line, the machine hangs, and,
obviously, no BIOS handoff failed message is printed.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-02-06 16:50                     ` Carlo E. Prelz
@ 2006-02-06 17:31                       ` David Brownell
  2006-02-06 17:45                         ` Carlo E. Prelz
  0 siblings, 1 reply; 22+ messages in thread
From: David Brownell @ 2006-02-06 17:31 UTC (permalink / raw)
  To: linux-usb-devel; +Cc: Carlo E. Prelz, Andrew Morton, linux-kernel


> > If it printed that, then how is it possible that it hung _before_ printing
> > that message???
> 
> I already wrote that I had commented out the line that caused the
> hangup:
> 
> //			pci_write_config_byte(pdev, offset + 3, 1);
> 
> After commenting out this line, the machine boots OK and EHCI works
> fine. It does print the BIOS handoff failed message. 

Then if disabling that code which enables the SMI doesn't work,
you have only one real option other than telling your BIOS not
to support USB keyboards/mice/disks:  replace your BIOS.

The reason it prints the BIOS handoff message is because you
completely disabled the handoff, so your BIOS still thinks it
owns that controller.  Commenting out that line is not good.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
  2006-02-06 17:31                       ` David Brownell
@ 2006-02-06 17:45                         ` Carlo E. Prelz
  0 siblings, 0 replies; 22+ messages in thread
From: Carlo E. Prelz @ 2006-02-06 17:45 UTC (permalink / raw)
  To: David Brownell; +Cc: linux-usb-devel, Andrew Morton, linux-kernel

	Subject: Re: [linux-usb-devel] Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
	Date: Mon 06 Feb 06 09:31:14AM -0800

Quoting David Brownell (david-b@pacbell.net):

> Then if disabling that code which enables the SMI doesn't work,
> you have only one real option other than telling your BIOS not
> to support USB keyboards/mice/disks:  replace your BIOS.

Sapphire has no newer bios than the one I am using. But I am saying
that USB works with that line commented out. I tried a couple of USB
disks, a USB mouse and my palm pilot - all seem to work quite OK. No
angry messages.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2006-02-06 17:45 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-20 12:32 ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1 Carlo E. Prelz
2006-01-21  9:09 ` Andrew Morton
2006-01-21 12:57   ` Carlo E. Prelz
2006-01-21 20:58     ` Andrew Morton
2006-01-21 21:28       ` Erwin Rol
2006-01-21 22:04         ` Dave Jones
2006-01-22  4:14           ` Kurt Wall
2006-01-22  7:40       ` Carlo E. Prelz
2006-01-22  7:55         ` Andrew Morton
2006-01-22  8:30           ` Carlo E. Prelz
2006-01-22 11:11           ` Carlo E. Prelz
2006-02-05 10:33             ` Carlo E. Prelz
2006-02-05 19:45               ` [linux-usb-devel] " David Brownell
2006-02-06  8:02                 ` Carlo E. Prelz
2006-02-06 16:24                   ` David Brownell
2006-02-06 16:50                     ` Carlo E. Prelz
2006-02-06 17:31                       ` David Brownell
2006-02-06 17:45                         ` Carlo E. Prelz
2006-01-23 19:01           ` David Brownell
2006-01-23 21:47             ` Carlo E. Prelz
2006-01-24  4:42             ` Greg KH
2006-01-24 15:15               ` David Brownell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).