PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Elliot Mackenzie]

Dear Penguins:

We have a problem booting vanilla 2.6.2 and 2.6.3 kernels from a USB
disk (Transcend JetFlash, both 128MB USB 2 and 256MB USB 1). During what
appears to be PCI device enumeration, we get the following panic:

kernel BUG at arch/i386/mm/ioremap.c:81!
invalid operand: 0000 [#1]
CPU: 0
EIP:	0060:[<c011913c>]		Not tainted
EFLAGS: 00010206
EIP is at remap_area_pages+0x34/0x1f1
eax: c0101000    ebx: edeb0000   ecx: bc6b0000   edx: c0101ce8
esi: 0dffc0000   edi: ce800000   ebp: 00000000   esp: cde55f48
ds:  007b    es: 007b   ss: 0068
Process swapper (pid: 1, theadinfo=cde54000 task=cdfb3900)
Stack:  c01490cd cdffb100 000000d0 c0101cec edeb0000 0dffc000 bc6b0000
c0101ce8
        c014913d edeb0000 0dffc000 ce800000 00000000 c01193d3 ce800000
3f7fc000
        edeb0000 00000000 00000000 00000024 ce800000 edeafed7 c03e9249
0dffc000
Call Trace:
 [<c01490cd>] __get_vm_area+0xb5/0xf3
 [<c014913d>] get_vm_area+0x32/0x36
 [<c01193d3>] __ioremap+0xda/0x104
 [<c03e9249>] sbf_init+0x167/0x180
 [<c03e46f1>] do_init_calls+0x28/0x93
 [<c012ca28>] init_workqueues+0xf/0x27
 [<c01050bc>] init+0x30/0x134
 [<c010508c>] init+0x0/0x134
 [<c0109255>] kernel_thread_helper+0x5/0xb

Code: 0f 0b 51 00 8b 4d 32 c0 ba 00 e0 ff ff 21 e0 83 40 14 01 8b
 <0>Kernel panic: Attempted to kill init!

This does not occur when booting from the hard disk, or when booting 2.4
series kernels (tried 2.4.18 through 2.4.22).

Hardware info: P4-based Intel Celeron, motherboard is SiS chipset.

We have tried to circumvent the problem by changing the kernel PCI
probing from "Any" to "BIOS" and "Direct".

The bootloader is SysLinux (1.66), using an initrd image.  Kernel
parameters are set to run a serial console, but other than that, it's
just kernel and initrd.

Output from lspci (-vvv), /proc/cpuinfo and /proc/iomem from a working
2.4 kernel on the same machine is below.  The kernel was compiled with
gcc 3.2.

Can anyone provide some further insight into this problem, point us in
the right direction, or let us know if this is indeed a bug?

Cheers,
Elliot Mackenzie & Doug Turk.


===IOMEM===
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-0dffbfff : System RAM
  00100000-0022e791 : Kernel code
  0022e792-00286343 : Kernel data
0dffc000-0dffefff : ACPI Tables
0dfff000-0dffffff : ACPI Non-volatile Storage
e5800000-e5800fff : PCI device 1039:0900
  e5800000-e5800fff : sis900
e6000000-e6000fff : PCI device 1039:7002
  e6000000-e6000fff : ehci-hcd
e6800000-e6800fff : PCI device 1039:7001
  e6800000-e6800fff : usb-ohci
e7000000-e7000fff : PCI device 1039:7001
  e7000000-e7000fff : usb-ohci
e7800000-e7ffffff : PCI Bus #01
  e7800000-e781ffff : PCI device 1039:6325
e8000000-ebffffff : PCI device 1039:0650
f0000000-febfffff : PCI Bus #01
  f0000000-f7ffffff : PCI device 1039:6325
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved

===CPUINFO===
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Intel(R) Celeron(R) CPU 2.60GHz
stepping	: 9
cpu MHz		: 2600.205
cache size	: 8 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips	: 5190.45

===LSPCI===
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 650 Host (rev 80)
	Subsystem: Asustek Computer, Inc.: Unknown device 8079
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
	Latency: 32
	Region 0: Memory at e8000000 (32-bit, non-prefetchable)
[size=64M]
	Capabilities: [c0] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual
PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: e7800000-e7ffffff
	Prefetchable memory behind bridge: f0000000-febfffff
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL
Media IO] (rev 25)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
(prog-if 80 [Master])
	Subsystem: Asustek Computer, Inc.: Unknown device 807a
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 128
	Interrupt: pin ? routed to IRQ 11
	Region 4: I/O ports at a400 [size=16]

00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
SiS7012 PCI Audio Accelerator (rev a0)
	Subsystem: Asustek Computer, Inc.: Unknown device 80b0
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (13000ns min, 2750ns max)
	Interrupt: pin C routed to IRQ 10
	Region 0: I/O ports at 9400 [size=256]
	Region 1: I/O ports at 9000 [size=128]
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=55mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:03.0 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB
Controller (rev 0f) (prog-if 10 [OHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 807a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (20000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 3
	Region 0: Memory at e7000000 (32-bit, non-prefetchable)
[size=4K]

00:03.1 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB
Controller (rev 0f) (prog-if 10 [OHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 807a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (20000ns max), cache line size 08
	Interrupt: pin B routed to IRQ 5
	Region 0: Memory at e6800000 (32-bit, non-prefetchable)
[size=4K]

00:03.3 USB Controller: Silicon Integrated Systems [SiS] SiS7002 USB 2.0
(prog-if 20 [EHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 807a
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (20000ns max), cache line size 08
	Interrupt: pin D routed to IRQ 9
	Region 0: Memory at e6000000 (32-bit, non-prefetchable)
[size=4K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900
10/100 Ethernet (rev 91)
	Subsystem: Asustek Computer, Inc.: Unknown device 80a7
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (13000ns min, 2750ns max)
	Interrupt: pin A routed to IRQ 12
	Region 0: I/O ports at 8800 [size=256]
	Region 1: Memory at e5800000 (32-bit, non-prefetchable)
[size=4K]
	Expansion ROM at effe0000 [disabled] [size=128K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]
SiS650/651/M650/740 PCI/AGP VGA Display Adapter (prog-if 00 [VGA])
	Subsystem: Asustek Computer, Inc.: Unknown device 8079
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 11
	BIST result: 00
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at e7800000 (32-bit, non-prefetchable)
[size=128K]
	Region 2: I/O ports at d800 [size=128]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] AGP version 2.0
		Status: RQ=15 SBA+ 64bit- FW- Rate=x1,x2,x4
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

Re: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Randy.Dunlap]

On Sat, 21 Feb 2004 01:37:47 +1000 "Elliot Mackenzie" <macka@adixein.com> wrote:

| Dear Penguins:
| 
| We have a problem booting vanilla 2.6.2 and 2.6.3 kernels from a USB
| disk (Transcend JetFlash, both 128MB USB 2 and 256MB USB 1). During what
| appears to be PCI device enumeration, we get the following panic:
| 
| kernel BUG at arch/i386/mm/ioremap.c:81!
| invalid operand: 0000 [#1]
| CPU: 0
| EIP:	0060:[<c011913c>]		Not tainted
| EFLAGS: 00010206
| EIP is at remap_area_pages+0x34/0x1f1
| eax: c0101000    ebx: edeb0000   ecx: bc6b0000   edx: c0101ce8
| esi: 0dffc0000   edi: ce800000   ebp: 00000000   esp: cde55f48
| ds:  007b    es: 007b   ss: 0068
| Process swapper (pid: 1, theadinfo=cde54000 task=cdfb3900)
| Stack:  c01490cd cdffb100 000000d0 c0101cec edeb0000 0dffc000 bc6b0000
| c0101ce8
|         c014913d edeb0000 0dffc000 ce800000 00000000 c01193d3 ce800000
| 3f7fc000
|         edeb0000 00000000 00000000 00000024 ce800000 edeafed7 c03e9249
| 0dffc000
| Call Trace:
|  [<c01490cd>] __get_vm_area+0xb5/0xf3
|  [<c014913d>] get_vm_area+0x32/0x36
|  [<c01193d3>] __ioremap+0xda/0x104
|  [<c03e9249>] sbf_init+0x167/0x180
|  [<c03e46f1>] do_init_calls+0x28/0x93
|  [<c012ca28>] init_workqueues+0xf/0x27
|  [<c01050bc>] init+0x30/0x134
|  [<c010508c>] init+0x0/0x134
|  [<c0109255>] kernel_thread_helper+0x5/0xb
| 
| Code: 0f 0b 51 00 8b 4d 32 c0 ba 00 e0 ff ff 21 e0 83 40 14 01 8b
|  <0>Kernel panic: Attempted to kill init!
| 
| This does not occur when booting from the hard disk, or when booting 2.4
| series kernels (tried 2.4.18 through 2.4.22).
| 
| Hardware info: P4-based Intel Celeron, motherboard is SiS chipset.
| 
| We have tried to circumvent the problem by changing the kernel PCI
| probing from "Any" to "BIOS" and "Direct".
| 
| The bootloader is SysLinux (1.66), using an initrd image.  Kernel
| parameters are set to run a serial console, but other than that, it's
| just kernel and initrd.
| 
| Output from lspci (-vvv), /proc/cpuinfo and /proc/iomem from a working
| 2.4 kernel on the same machine is below.  The kernel was compiled with
| gcc 3.2.
| 
| Can anyone provide some further insight into this problem, point us in
| the right direction, or let us know if this is indeed a bug?

The call trace must be missing some helpful info, then.
I say that only because the data supplied does not look usb-device
specific.

Please apply the patch below (for 2.6.3) and reboot that kernel
with "initcall_debug" added to the kernel boot command line,
and send the resulting (failing) output back to us.

--
~Randy


applies_to:	linux-263

diffstat:=
 arch/i386/mm/ioremap.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletion(-)

diff -Naurp ./arch/i386/mm/ioremap.c~sbfinit ./arch/i386/mm/ioremap.c
--- ./arch/i386/mm/ioremap.c~sbfinit	2004-02-17 19:57:20.000000000 -0800
+++ ./arch/i386/mm/ioremap.c	2004-02-20 11:29:41.000000000 -0800
@@ -77,8 +77,12 @@ static int remap_area_pages(unsigned lon
 	phys_addr -= address;
 	dir = pgd_offset(&init_mm, address);
 	flush_cache_all();
-	if (address >= end)
+	if (address >= end) {
+		printk("remap_area_pages BUG: address=0x%lx, size=0x%lx, end=0x%lx\n",
+				address, size, end);
+		dump_stack();
 		BUG();
+	}
 	spin_lock(&init_mm.page_table_lock);
 	do {
 		pmd_t *pmd;

RE: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Elliot Mackenzie]

OK, I have done that, and I recompiled an identical kernel with spinlock
support (first incarnation did not have it).

Files on syslinux USB disk include vmlinuz (2.6.3), initrd and syslinux
config.

Cheers,
Elliot.

Now we get this:
==========================
Calling initcall 0xc03f7e19
Calling initcall 0xc03f819c
Calling initcall 0xc03f1e7c
Calling initcall 0xc03e7084
Calling initcall 0xc03e7101
Calling initcall 0xc03e90e2
remap_area_pages BUG: address=0xce800000, size=0xedeb0000,
end=0xbc6b0000
Call Trace:
 [<c0119318>] remap_area_pges+0x210/0x21d
 [<c0149169>] get_vm_area+0x32/0x36
 [<c01193ff>] __ioremap+0xda/0x104
 [<c03e9249>] sbf_init+0x167/0x180
 [<c03e46f1>] do_init_calls+0x28/0x93 
 [<c03e90e2>] sbf_init+0x0/0x180
 [<c012ca54>] init_workqueues+0xf/0x27
 [<c01050bc>] init+0x30/0x134
 [<c010508c>] init+0x0/0x134
 [<c0109255>] kernel_thread_helper+0x5/0xb
------------[ cut here ]------------
kernel BUG at arch/i386/mm/ioremap.c:84!
invalid operand: 0000 [#1]
CPU: 0
EIP:	0060:[<c0119318>]		Not tainted
EFLAGS: 00010292
EIP is at remap_area_pages+0x210/0x21d
eax: c0000001    ebx: edeb0000   ecx: c0369a50   edx: 00000282
esi: 0dffc0000   edi: ce800000   ebp: 00000000   esp: cde55f3c
ds:  007b    es: 007b   ss: 0068
Process swapper (pid: 1, theadinfo=cde54000 task=cdfb3900)
Stack:  c03250e0 ce800000 edeb0000 bc6b0000 cdffb100 000000d0 c0101cec
edeb0000 0dffc000 bc6b0000 c0101ce8 c0149169 edeb0000 0dffc000 ce800000
00000000 c01193ff ce800000 3f7fc000 edeb0000 00000000 00000000 00000024
ce800000
Call Trace:
 [<c0149169>] get_vm_area+0x32/0x36
 [<c01193ff>] __ioremap+0xda/0x104
 [<c03e9249>] sbf_init+0x167/0x180
 [<c03e46f1>] do_init_calls+0x28/0x93 
 [<c03e90e2>] sbf_init+0x0/0x180
 [<c012ca54>] init_workqueues+0xf/0x27
 [<c01050bc>] init+0x30/0x134
 [<c010508c>] init+0x0/0x134
 [<c0109255>] kernel_thread_helper+0x5/0xb

Code: 0f 0b 54 00 ab 4d 32 c0 e9 1d fe ff ff 83 ec 20 89 5c 24 10
 <0>Kernel panic: Attempted to kill init!
==========================
<snip>
|
| The call trace must be missing some helpful info, then.
| I say that only because the data supplied does not look usb-device
| specific.

| Please apply the patch below (for 2.6.3) and reboot that kernel
| with "initcall_debug" added to the kernel boot command line,
| and send the resulting (failing) output back to us.
|
| --
| ~Randy
<snip>

Re: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Randy.Dunlap]

On Sat, 21 Feb 2004 10:11:24 +1000 "Elliot Mackenzie" <macka@adixein.com> wrote:

| OK, I have done that, and I recompiled an identical kernel with spinlock
| support (first incarnation did not have it).
| 
| Files on syslinux USB disk include vmlinuz (2.6.3), initrd and syslinux
| config.
| 
| Cheers,
| Elliot.

Duh, I forgot.  Please look up these initcall addresses in your
System.map file (or post it on the web or mail it).

But that size=0xedeb0000 is a problem... just to figure out where
it's coming from, using the initcall symbols.



| Now we get this:
| ==========================
| Calling initcall 0xc03f7e19
| Calling initcall 0xc03f819c
| Calling initcall 0xc03f1e7c
| Calling initcall 0xc03e7084
| Calling initcall 0xc03e7101
| Calling initcall 0xc03e90e2
| remap_area_pages BUG: address=0xce800000, size=0xedeb0000,
| end=0xbc6b0000
| Call Trace:
|  [<c0119318>] remap_area_pges+0x210/0x21d
|  [<c0149169>] get_vm_area+0x32/0x36
|  [<c01193ff>] __ioremap+0xda/0x104
|  [<c03e9249>] sbf_init+0x167/0x180
|  [<c03e46f1>] do_init_calls+0x28/0x93 
|  [<c03e90e2>] sbf_init+0x0/0x180
|  [<c012ca54>] init_workqueues+0xf/0x27
|  [<c01050bc>] init+0x30/0x134
|  [<c010508c>] init+0x0/0x134
|  [<c0109255>] kernel_thread_helper+0x5/0xb
| ------------[ cut here ]------------
| kernel BUG at arch/i386/mm/ioremap.c:84!
| invalid operand: 0000 [#1]
| CPU: 0
| EIP:	0060:[<c0119318>]		Not tainted
| EFLAGS: 00010292
| EIP is at remap_area_pages+0x210/0x21d
| eax: c0000001    ebx: edeb0000   ecx: c0369a50   edx: 00000282
| esi: 0dffc0000   edi: ce800000   ebp: 00000000   esp: cde55f3c
| ds:  007b    es: 007b   ss: 0068
| Process swapper (pid: 1, theadinfo=cde54000 task=cdfb3900)
| Stack:  c03250e0 ce800000 edeb0000 bc6b0000 cdffb100 000000d0 c0101cec
| edeb0000 0dffc000 bc6b0000 c0101ce8 c0149169 edeb0000 0dffc000 ce800000
| 00000000 c01193ff ce800000 3f7fc000 edeb0000 00000000 00000000 00000024
| ce800000
| Call Trace:
|  [<c0149169>] get_vm_area+0x32/0x36
|  [<c01193ff>] __ioremap+0xda/0x104
|  [<c03e9249>] sbf_init+0x167/0x180
|  [<c03e46f1>] do_init_calls+0x28/0x93 
|  [<c03e90e2>] sbf_init+0x0/0x180
|  [<c012ca54>] init_workqueues+0xf/0x27
|  [<c01050bc>] init+0x30/0x134
|  [<c010508c>] init+0x0/0x134
|  [<c0109255>] kernel_thread_helper+0x5/0xb
| 
| Code: 0f 0b 54 00 ab 4d 32 c0 e9 1d fe ff ff 83 ec 20 89 5c 24 10
|  <0>Kernel panic: Attempted to kill init!
| ==========================
| <snip>
| |
| | The call trace must be missing some helpful info, then.
| | I say that only because the data supplied does not look usb-device
| | specific.
| 
| | Please apply the patch below (for 2.6.3) and reboot that kernel
| | with "initcall_debug" added to the kernel boot command line,
| | and send the resulting (failing) output back to us.
| |
| | --
| | ~Randy
| <snip>

--
~Randy

Re: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Randy.Dunlap]

On Sat, 21 Feb 2004 10:25:09 +1000 "Elliot Mackenzie" <macka@adixein.com> wrote:

| c03e46c9 t do_initcalls, if I got the one you are looking for...
| 
Nope, this list:

| Calling initcall 0xc03f7e19
| Calling initcall 0xc03f819c
| Calling initcall 0xc03f1e7c
| Calling initcall 0xc03e7084
| Calling initcall 0xc03e7101
| Calling initcall 0xc03e90e2

Thanks.

| 
| 
| | Duh, I forgot.  Please look up these initcall addresses in your
| | System.map file (or post it on the web or mail it).
| |
| | But that size=0xedeb0000 is a problem... just to figure out where
| | it's coming from, using the initcall symbols.
| <snip>


--
~Randy

RE: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Elliot Mackenzie]

c03e46c9 t do_initcalls, if I got the one you are looking for...

Cheers,
Elliot.


| Duh, I forgot.  Please look up these initcall addresses in your
| System.map file (or post it on the web or mail it).
|
| But that size=0xedeb0000 is a problem... just to figure out where
| it's coming from, using the initcall symbols.
<snip>

RE: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Elliot Mackenzie]

As enumerated below:
| Calling initcall 0xc03f7e19 pcibios_init
| Calling initcall 0xc03f819c netdev_init
| Calling initcall 0xc03f1e7c chr_dev_init
| Calling initcall 0xc03e7084 i8259_init_sysfs
| Calling initcall 0xc03e7101 init_timer_sysfs
| Calling initcall 0xc03e90e2 sbf_init

Cheers,
Elliot.

RE: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Randy.Dunlap]

As enumerated below:
| Calling initcall 0xc03f7e19 pcibios_init
| Calling initcall 0xc03f819c netdev_init
| Calling initcall 0xc03f1e7c chr_dev_init
| Calling initcall 0xc03e7084 i8259_init_sysfs
| Calling initcall 0xc03e7101 init_timer_sysfs
| Calling initcall 0xc03e90e2 sbf_init


I still don't see how USB enters into it, but please try the patch
below to see if I'm on the right track or not.
It looks like sbf_init() is finding an invalid ACPI RSDT length field.
This patch will telll us if that's the case or not.

--
~Randy


// Linux 2.6.3
// handle a garbage RSDT length field;

diffstat:=
 arch/i386/kernel/bootflag.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletion(-)


diff -Naurp ./arch/i386/kernel/bootflag.c~sbfinit ./arch/i386/kernel/bootflag.c
--- ./arch/i386/kernel/bootflag.c~sbfinit	2004-02-17 19:59:06.000000000 -0800
+++ ./arch/i386/kernel/bootflag.c	2004-02-20 21:26:51.000000000 -0800
@@ -193,7 +193,8 @@ static int __init sbf_init(void)
 	if(i>0xFFFE0)
 		return 0;
 		
-		
+	printk(KERN_ERR "SBF: remap rsdt to 0x%x, len=0x%x\n",
+			rsdtbase, rsdtlen);
 	rsdt = ioremap(rsdtbase, rsdtlen);
 	if(rsdt == 0)
 		return 0;
@@ -208,6 +209,11 @@ static int __init sbf_init(void)
 	{
 		rsdtlen = i;
 		iounmap(rsdt);
+		if (rsdtlen > 0x1000) {	/* arbitrary for now */
+			printk(KERN_ERR "SBF: invalid rsdtlen = 0x%x\n",
+					rsdtlen);
+			return 0;
+		}
 		rsdt = ioremap(rsdtbase, rsdtlen);
 		if(rsdt == 0)
 			return 0;

RE: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Elliot Mackenzie]

Randy:

This issue just got a lot weirder but I have some more information.  

This is the weird part:
I applied the patch you suggested, and the system stopped panicking at
that point.  Instead, it just hung for about 10 minutes, eventually
kicking off again and finishing bootup.  To be sure, I then removed the
code and recompiled (clean), and now the original code started doing
that too (without your patch).  To my knowledge I changed nothing (not
even in BIOS), but I rebuilt the kernel again from the raw 2.6.3 source
to be sure - same result.

The interesting part (more information):
If we bypass the bootflag.c code (simply by putting "return 0;" as the
first line), the system will boot normally.  On shutdown we seem to be
getting a system jumping to maintenance mode, but I am not sure if its
related.  It appears you are right in assuming that the problem is
related to the bios sbf rather than the usb.  Doug pointed out to me
that looking through the stack trace, sbf_init is giving an rsdt_length
of something in the order of 1GB, and somehow the checks are not picking
it up.

Since it is now relevant, the BIOS is flashed to the most recent stable
BIOS for the ASUS P4SGX-MX motherboard (1005).

This is the tricky part:
When we bypass the bootflag code, and boot the "working" kernel, I am
able to capture a serial transcript.  However, I have been unsuccessful
in establishing a serial console for the broken 2.6.3 kernel to date.
It's possible I have done something strange while building one of the
kernels, but I am just trying to verify that now.  Are there
alternatives?

Currently the text on screen comes up way to quickly for me to capture,
and since I don't have a working serial console for the broken kernel
yet, I am not able to capture a transcript.  Previously I could just
type to you what I saw, but the kernel is now booting to the same point,
hanging 10 minutes then continuing.

Kind regards,
Elliot.

-----Original Message-----
From: Randy.Dunlap [mailto:rddunlap@osdl.org] 
Sent: Saturday, 21 February 2004 3:32 PM
To: macka@adixein.com
Cc: lkml
Subject: RE: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)


As enumerated below:
| Calling initcall 0xc03f7e19 pcibios_init
| Calling initcall 0xc03f819c netdev_init
| Calling initcall 0xc03f1e7c chr_dev_init
| Calling initcall 0xc03e7084 i8259_init_sysfs
| Calling initcall 0xc03e7101 init_timer_sysfs
| Calling initcall 0xc03e90e2 sbf_init


I still don't see how USB enters into it, but please try the patch
below to see if I'm on the right track or not.
It looks like sbf_init() is finding an invalid ACPI RSDT length field.
This patch will telll us if that's the case or not.

--
~Randy

Re: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Randy.Dunlap]

On Sun, 22 Feb 2004 22:02:22 +1000 Elliot Mackenzie wrote:

| Randy:
| 
| This issue just got a lot weirder but I have some more information.  
| 
| This is the weird part:
| I applied the patch you suggested, and the system stopped panicking at
| that point.  Instead, it just hung for about 10 minutes, eventually
| kicking off again and finishing bootup.  To be sure, I then removed the
| code and recompiled (clean), and now the original code started doing
| that too (without your patch).  To my knowledge I changed nothing (not
| even in BIOS), but I rebuilt the kernel again from the raw 2.6.3 source
| to be sure - same result.

During the 10 minutes or so, does the keyboard work?
Can you do Alt-SysRq-T, or just Alt-SysRq-P multiple times to see
what code is executing?

| The interesting part (more information):
| If we bypass the bootflag.c code (simply by putting "return 0;" as the
| first line), the system will boot normally.  On shutdown we seem to be
| getting a system jumping to maintenance mode, but I am not sure if its
| related.  It appears you are right in assuming that the problem is
| related to the bios sbf rather than the usb.  Doug pointed out to me
| that looking through the stack trace, sbf_init is giving an rsdt_length
| of something in the order of 1GB, and somehow the checks are not picking
| it up.

There wasn't any checking for an invalid RSDT length at all.
There should be IMO.

| Since it is now relevant, the BIOS is flashed to the most recent stable
| BIOS for the ASUS P4SGX-MX motherboard (1005).
| 
| This is the tricky part:
| When we bypass the bootflag code, and boot the "working" kernel, I am
| able to capture a serial transcript.  However, I have been unsuccessful
| in establishing a serial console for the broken 2.6.3 kernel to date.
| It's possible I have done something strange while building one of the
| kernels, but I am just trying to verify that now.  Are there
| alternatives?

The "magic sysrq" keys...

| Currently the text on screen comes up way to quickly for me to capture,
| and since I don't have a working serial console for the broken kernel
| yet, I am not able to capture a transcript.  Previously I could just
| type to you what I saw, but the kernel is now booting to the same point,
| hanging 10 minutes then continuing.

Maybe just add more printk()s to bootflag.c to see what code it is
executing...?

--
~Randy

Oh, your other email didn't help me any.


| Kind regards,
| Elliot.
| 
| -----Original Message-----
| From: Randy.Dunlap [mailto:rddunlap@osdl.org] 
| Sent: Saturday, 21 February 2004 3:32 PM
| To: macka@adixein.com
| Cc: lkml
| Subject: RE: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)
| 
| 
| As enumerated below:
| | Calling initcall 0xc03f7e19 pcibios_init
| | Calling initcall 0xc03f819c netdev_init
| | Calling initcall 0xc03f1e7c chr_dev_init
| | Calling initcall 0xc03e7084 i8259_init_sysfs
| | Calling initcall 0xc03e7101 init_timer_sysfs
| | Calling initcall 0xc03e90e2 sbf_init
| 
| 
| I still don't see how USB enters into it, but please try the patch
| below to see if I'm on the right track or not.
| It looks like sbf_init() is finding an invalid ACPI RSDT length field.
| This patch will telll us if that's the case or not.

Re: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Len Brown]

bootflag.c should not use its own private ACPI table parser/mapper --
this is a bug:

http://bugme.osdl.org/show_bug.cgi?id=1922

Elliot,
If you add your system info to that bug report and volunteer to help
test the fix, I'll be delighted to use your system as an excuse to
address this issue promptly.

thanks,
-Len

ps.
The reason you enter diag mode when SBF is disabled is because w/o SBF,
the BOOTING flag doesn't get cleared, so the BIOS assumes the system
didn't boot correctly and when entered next it is in DIAG mode.  This is
expected.

IMO, module load time is probably too early to clear the BOOTING flag
anyway.  It should be cleared upon completion of successful boot --
though I'm not sure how to identify that point.  Come to think about it,
maybe we should delay clearing the BOOTING flag until Linux initiates a
graceful shutdown, sleep, or reboot?  If the system died b/c of bad RAM
or something, that would make it run through DIAGS when it next enters
POST.

[PATCH]: PROBLEM: Panic booting from USB disk in ioremap.c (line 81)

[Elliot Mackenzie]

Kernel-devs:

This patch simply adds a sanity check to bootflag.c to detect a bad RSDT
pointer and avoids a kernel panic on boot with some buggy BIOSes.  The
patch is an "interim" patch, as we believe Len Brown has plans to use
the ACPI code to manage SBF in future.

Initial post:
>We have a problem booting vanilla 2.6.2 and 2.6.3 kernels from a USB
disk >(Transcend JetFlash, both 128MB USB 2 and 256MB USB 1). During
what appears >to be PCI device enumeration, we get the following panic:

Len Brown:
>bootflag.c should not use its own private ACPI table parser/mapper --
>this is a bug:
>http://bugme.osdl.org/show_bug.cgi?id=1922

This is an interim patch for anyone that is wrestling with the same
issue.  
Thank you to Randy Dunlap for his helpful assistance early in the
process (and for some of the code below).  

Kind regards,
Doug Turk and Elliot Mackenzie.


========================================================================
====
--- linux-2.6.3/arch/i386/kernel/bootflag.c	Wed Feb 18 13:59:06 2004
+++ linux-2.6.3-doug/arch/i386/kernel/bootflag.c	Tue Feb 24
23:18:51 2004
@@ -192,22 +192,37 @@
 	}
 	if(i>0xFFFE0)
 		return 0;
-		
-		
+
 	rsdt = ioremap(rsdtbase, rsdtlen);
 	if(rsdt == 0)
 		return 0;
-		
-	i = readl(rsdt + 4);
+
+	/* Check the RSDT signature */
+	if (memcmp(rsdt, "RSDT", 4))
+	{
+		iounmap(rsdt);
+		printk(KERN_WARNING "SBF: Could not map RSDT: bad
signature\n");
+		return 0;
+	}
+
 	
 	/*
 	 *	Remap if needed
 	 */
-	 
+	i = readl(rsdt + 4);
+
 	if(i > rsdtlen)
 	{
 		rsdtlen = i;
 		iounmap(rsdt);
+		/* Verify that the RSDT length is sane. */
+		if (rsdtlen > 0x1000) {	/* arbitrary for now */
+			printk(KERN_ERR "SBF: invalid rsdtlen = 0x%x\n",
+					rsdtlen);
+			return 0;
+		}
+
 		rsdt = ioremap(rsdtbase, rsdtlen);
 		if(rsdt == 0)
 			return 0;