Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Andrew Morton]

Begin forwarded message:

Date: Thu, 19 Feb 2004 00:37:24 +0100
From: "Dr. Ernst Molitor" <molitor@cfce.de>
To: linux-kernel@vger.kernel.org
Cc: molitor@uni-bonn.de
Subject: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time


Dear Linux gurus,

thank you very much for your work on Linux. Today, I came across a
problem; sorry, I have failed in trying to spot the cause...

[1.] Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used
for aha1542" at boot time on my box.

[2.] Up to Linux-2.6.1-rc2, everything went fine on my somewhat aged box
with both AHA1542 and AIC7xxx-based SCSI controllers. After upgrading to
Linux-2.6.3 (essentially with the same .config file, using make
oldconfig), my box failed to boot with this message:

buf vaddress e7f8be5c paddress 0x27f8be5c length 16
Kernel panic: Buffers at physical address >16Mb used for aha1542

Nothing short of a hard reset let out of this...

[3.] AHA1542, DMA (?)

[7.1] before the upgrade to 2.6.3, ver_linux showed:
Linux felicia 2.6.1-rc2 #1 SMP Thu Jan 8 22:23:49 CET 2004 i686 unknown
  
Gnu C                  3.3.2
Gnu make               3.80
util-linux             2.12
mount                  2.12
module-init-tools      0.9.13-pre
e2fsprogs              1.30
reiserfsprogs          3.6.9
isdn4k-utils           isdnctrl)
nfs-utils              0.1.9.1
Linux C Library        2.3.2
Dynamic linker (ldd)   2.3.2
Linux C++ Library      5.0.5
Procps                 3.1.15
Net-tools              1.54
Console-tools          0.2.3
Sh-utils               2.0
Modules Loaded

[7.2]  cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 7
model name      : Pentium III (Katmai)
stepping        : 3
cpu MHz         : 451.058
cache size      : 512 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 mmx fxsr sse
bogomips        : 888.83
 
[7.3] no modules loaded
[7.4]  cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
02f8-02ff : serial
0330-0333 : aha1542
0378-037a : parport0
03c0-03df : vga+
03f8-03ff : serial
0cf8-0cff : PCI conf1
4000-403f : 0000:00:07.3
5000-501f : 0000:00:07.3
c000-cfff : PCI Bus #01
  c000-c0ff : 0000:01:00.0
d000-d01f : 0000:00:07.2
  d000-d01f : uhci_hcd
d400-d4ff : 0000:00:08.0
  d400-d4ff : 8139too
d800-d8ff : 0000:00:09.0
dc00-dcff : 0000:00:0a.0
  dc00-dcff : 8139too
e000-e0ff : 0000:00:0b.0
f000-f00f : 0000:00:07.1

 cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000cc000-000d17ff : Extension ROM
000d2000-000d27ff : Extension ROM
000dc000-000dffff : Extension ROM
000f0000-000fffff : System ROM
00100000-27feffff : System RAM
  00100000-003f5bac : Kernel code
  003f5bad-0052257f : Kernel data
27ff0000-27ff2fff : ACPI Non-volatile Storage
27ff3000-27ffffff : ACPI Tables
e0000000-e3ffffff : 0000:00:00.0
e4000000-e5ffffff : PCI Bus #01
  e5000000-e5000fff : 0000:01:00.0
e6000000-e6ffffff : PCI Bus #01
  e6000000-e6ffffff : 0000:01:00.0
e9000000-e90000ff : 0000:00:08.0
  e9000000-e90000ff : 8139too
e9001000-e90010ff : 0000:00:0a.0
  e9001000-e90010ff : 8139too
e9002000-e9002fff : 0000:00:0b.0
  e9002000-e9002fff : aic7xxx
e9003000-e9003fff : 0000:00:09.0
  e9003000-e9003fff : aic7xxx
ffff0000-ffffffff : reserved
ernst@felicia:/e/linux$

[7.5] lspci -vvv: 
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
        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: 64 set
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 1.0
                Status: RQ=31 SBA+ 64bit- FW- Rate=21
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=
 
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge
(rev 03) (prog-if 00 [Normal decode])
        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: 64 set
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: e4000000-e5ffffff
        Prefetchable memory behind bridge: e6000000-e6ffffff
        BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B+
 
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
        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 set
 
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
(prog-if 80 [Master])
        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-
        Region 4: I/O ports at f000 [size=16]
 
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
(prog-if 00 [UHCI])
        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: 64 set
        Interrupt: pin D routed to IRQ 15
        Region 4: I/O ports at d000 [size=32]
 
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
        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 ? routed to IRQ 9
 
00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev
10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        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 min, 64 max, 64 set
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at d400 [size=256]
        Region 1: Memory at e9000000 (32-bit, non-prefetchable)
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 
00:09.0 SCSI storage controller: Adaptec AHA-2940U2/W
        Subsystem: Adaptec: Unknown device 2180
        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: 39 min, 25 max, 64 set, cache line size 08
        Interrupt: pin A routed to IRQ 14
        BIST result: 00
        Region 0: I/O ports at d800 [disabled] [size=256]
        Region 1: Memory at e9003000 (64-bit, non-prefetchable)
[size=4K]
        Expansion ROM at e7000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev
10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        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 min, 64 max, 64 set
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at dc00 [size=256]
        Region 1: Memory at e9001000 (32-bit, non-prefetchable)
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 
00:0b.0 SCSI storage controller: Adaptec AHA-294x / AIC-7871
        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: 8 min, 8 max, 64 set, cache line size 08
        Interrupt: pin A routed to IRQ 15
        Region 0: I/O ports at e000 [disabled] [size=256]
        Region 1: Memory at e9002000 (32-bit, non-prefetchable)
[size=4K]
        Expansion ROM at e8000000 [disabled] [size=64K]
 
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP
(rev 7a) (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc: Unknown device 0084
        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: 8 min, 64 set, cache line size 08
        Interrupt: pin A routed to IRQ 0
        Region 0: Memory at e6000000 (32-bit, prefetchable) [size=16M]
        Region 1: I/O ports at c000 [size=256]
        Region 2: Memory at e5000000 (32-bit, non-prefetchable)
[size=4K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [5c] Power Management version 1
                Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 
[7.6]  cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 02 Lun: 00
  Vendor: TEAC     Model: CD-ROM CD-532S   Rev: 1.0A
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: DCAS-34330       Rev: S65A
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 02 Lun: 00
  Vendor: QUANTUM  Model: FIREBALL_TM3200S Rev: 300X
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 03 Lun: 00
  Vendor: YAMAHA   Model: CRW8424S         Rev: 1.0d
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 04 Lun: 00
  Vendor: CONNER   Model: CP30200-212MB    Rev: 4343
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 05 Lun: 00
  Vendor: IBM      Model: DORS-32160       Rev: WA6A
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 08 Lun: 00
  Vendor: IBM      Model: DNES-309170W     Rev: SA30
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi2 Channel: 00 Id: 09 Lun: 00
  Vendor: IBM      Model: DPSS-318350N     Rev: S80D
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi2 Channel: 00 Id: 15 Lun: 00
  Vendor: FUJITSU  Model: MAN3184MP        Rev: 0109
  Type:   Direct-Access                    ANSI SCSI revision: 03

I'd very much appreciate any suggestion as to how to solve this problem.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[James Bottomley]

On Wed, 2004-02-18 at 20:12, Andrew Morton wrote:
> thank you very much for your work on Linux. Today, I came across a
> problem; sorry, I have failed in trying to spot the cause...
> 
> [1.] Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used
> for aha1542" at boot time on my box.

Could you replace the panic with a BUG() statement and make sure you
have CONFIG_KALLSYMS set, that should give us a backtrace showing where
the bad kernel allocation is.

Thanks,

James

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Dr. Ernst Molitor]

Dear James Bottomley, 

thank you very much for looking into the problem I have seen. 

Following to your kind suggestion, I have commented out the two "panic
(... Buffers and physical address > 16Mb ...)" lines in the aha1542.c
source and added "BUG();"-lines in their places. Booting the kernel
built afterwards resulted in a bunch of messages; I haven't been able to
read the first lines; this is what I could copy:

[<c02ee972>] scsi_request_fn+0x1c2/0x310
[<c02aa35d>] __elv_add_request+0x2d/0x50
[<c02aca14>] blk_insert_request+0x84/0xc0
[<c02ed679>] scsi_insert_special_req+0x39/0x40
[<c02ed8a9>] scsi_wait_req+0x69/0xb0
[<c02ed7c0>] scsi_wait_done+0x0/0x80
[<c0319980>] sr_do_ioctl+0x90/0x290
[<c0319735>] sr_packet+0x25/0x40
[<c0320262>] cdrom_is_mrw+0x52/0x80
[<c03194b0>] get_capabilities+0x1d0/0x430
[<c023d87f>] sprintf+0x1f/0x30
[<c0318fd1>] sr_probe+0x1f/0x30
[<c02a736d>] bus_match+0x3d/0x70
[<c02a74ac>] driver_attach+0x5c/0xa0
[<c02a77c6>] bus_add_driver+0xa6/0xc0
[<c05422ff>] init_sr+0x2f/0x40
[<c05289db>] do_initcalls+0x2b/0xa0
[<c01317d2>] init_workqueues+0x12/0x29
[<c01050ec>] init+0x4c/0x150
[<c01050a0>] init+0x0/0x150
[<c010719d>] kernel_thread_helper+0x5/0x18
 
Code: 0f 0b 3e 00 c2 5a 43 c0 89 ec 5d c3 8d 76 00 8d bc 28 00 00
<0>Kernel panic: Attempted to kill init!

Please don't hesitate to contact me if I can be of any further help in
this matter.

Best wishes and regards, 

Ernst


On Thu, 2004-02-19 at 21:18 -0500, James Bottomley wrote:

> On Wed, 2004-02-18 at 20:12, Andrew Morton wrote:
> > thank you very much for your work on Linux. Today, I came across a
> > problem; sorry, I have failed in trying to spot the cause...
> > 
> > [1.] Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used
> > for aha1542" at boot time on my box.
> 
> Could you replace the panic with a BUG() statement and make sure you
> have CONFIG_KALLSYMS set, that should give us a backtrace showing where
> the bad kernel allocation is.
> 
> Thanks,
> 
> James
> 
> 
> 
> ______________________________________
> Inflex - installed on mailserver for domain @mibi03.meb.uni-bonn.de
> Queries to: postmaster@mibi03.meb.uni-bonn.de

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Jens Axboe]

On Fri, Feb 20 2004, Dr. Ernst Molitor wrote:
> Dear James Bottomley, 
> 
> thank you very much for looking into the problem I have seen. 
> 
> Following to your kind suggestion, I have commented out the two "panic
> (... Buffers and physical address > 16Mb ...)" lines in the aha1542.c
> source and added "BUG();"-lines in their places. Booting the kernel
> built afterwards resulted in a bunch of messages; I haven't been able to
> read the first lines; this is what I could copy:
> 
> [<c02ee972>] scsi_request_fn+0x1c2/0x310
> [<c02aa35d>] __elv_add_request+0x2d/0x50
> [<c02aca14>] blk_insert_request+0x84/0xc0
> [<c02ed679>] scsi_insert_special_req+0x39/0x40
> [<c02ed8a9>] scsi_wait_req+0x69/0xb0
> [<c02ed7c0>] scsi_wait_done+0x0/0x80
> [<c0319980>] sr_do_ioctl+0x90/0x290
> [<c0319735>] sr_packet+0x25/0x40
> [<c0320262>] cdrom_is_mrw+0x52/0x80
> [<c03194b0>] get_capabilities+0x1d0/0x430
> [<c023d87f>] sprintf+0x1f/0x30
> [<c0318fd1>] sr_probe+0x1f/0x30
> [<c02a736d>] bus_match+0x3d/0x70
> [<c02a74ac>] driver_attach+0x5c/0xa0
> [<c02a77c6>] bus_add_driver+0xa6/0xc0
> [<c05422ff>] init_sr+0x2f/0x40
> [<c05289db>] do_initcalls+0x2b/0xa0
> [<c01317d2>] init_workqueues+0x12/0x29
> [<c01050ec>] init+0x4c/0x150
> [<c01050a0>] init+0x0/0x150
> [<c010719d>] kernel_thread_helper+0x5/0x18
>  
> Code: 0f 0b 3e 00 c2 5a 43 c0 89 ec 5d c3 8d 76 00 8d bc 28 00 00
> <0>Kernel panic: Attempted to kill init!
> 
> Please don't hesitate to contact me if I can be of any further help in
> this matter.

Hmm... James, sr_do_ioctl() used to do bouncing for private commands,
any reason it doesn't do that anymore?

-- 
Jens Axboe

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[James Bottomley]

On Fri, 2004-02-20 at 00:30, Dr. Ernst Molitor wrote:
> Please don't hesitate to contact me if I can be of any further help in
> this matter.

The problem seems to be a non-GFP_DMA allocation in sr.c.  Could you try
this patch?

Thanks,

James

===== drivers/scsi/sr.c 1.98 vs edited =====
--- 1.98/drivers/scsi/sr.c	Mon Feb  9 12:59:10 2004
+++ edited/drivers/scsi/sr.c	Fri Feb 20 08:47:55 2004
@@ -716,7 +716,7 @@
 	set_disk_ro(cd->disk, 1);
 
 	/* allocate a request for the TEST_UNIT_READY */
-	SRpnt = scsi_allocate_request(cd->device, GFP_KERNEL);
+	SRpnt = scsi_allocate_request(cd->device, GFP_KERNEL | GFP_DMA);
 	if (!SRpnt) {
 		printk(KERN_WARNING "(get_capabilities:) Request allocation "
 		       "failure.\n");

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Mike Anderson]

James Bottomley [James.Bottomley@steeleye.com] wrote:
> On Fri, 2004-02-20 at 00:30, Dr. Ernst Molitor wrote:
> > Please don't hesitate to contact me if I can be of any further help in
> > this matter.
> 
> The problem seems to be a non-GFP_DMA allocation in sr.c.  Could you try
> this patch?
> 
> Thanks,
> 

What about the buffer off the stack that cdrom_is_mrw uses? cgc->buffer
is set to this stack buffer which is used directly in sr_do_ioctl when
scsi_wait_req is called.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[James Bottomley]

On Fri, 2004-02-20 at 09:52, Mike Anderson wrote:
> What about the buffer off the stack that cdrom_is_mrw uses? cgc->buffer
> is set to this stack buffer which is used directly in sr_do_ioctl when
> scsi_wait_req is called.

Well, OK, I stopped after I found one problem ...

James

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[James Bottomley]

On Fri, 2004-02-20 at 00:38, Jens Axboe wrote:
> Hmm... James, sr_do_ioctl() used to do bouncing for private commands,
> any reason it doesn't do that anymore?

OK, I've looked through the file history, I can't find anywhere that it
used to do this.

However, the true solution is to see if we can get scsi_wait_req to go
through the sg_io code path...that way the block layer will bounce for
us and we can kill the use_sg == 0 code path in all the drivers.

James

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Jens Axboe]

On Fri, Feb 20 2004, James Bottomley wrote:
> On Fri, 2004-02-20 at 00:38, Jens Axboe wrote:
> > Hmm... James, sr_do_ioctl() used to do bouncing for private commands,
> > any reason it doesn't do that anymore?
> 
> OK, I've looked through the file history, I can't find anywhere that it
> used to do this.
> 
> However, the true solution is to see if we can get scsi_wait_req to go
> through the sg_io code path...that way the block layer will bounce for
> us and we can kill the use_sg == 0 code path in all the drivers.

Yep that'd be my preferred solution as well. Requires bio backing
everything though. I'll hack this up over the weekend.

-- 
Jens Axboe

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Jens Axboe]

On Fri, Feb 20 2004, James Bottomley wrote:
> On Fri, 2004-02-20 at 00:38, Jens Axboe wrote:
> > Hmm... James, sr_do_ioctl() used to do bouncing for private commands,
> > any reason it doesn't do that anymore?
> 
> OK, I've looked through the file history, I can't find anywhere that it
> used to do this.

BTW, it used to do this inside sr_do_ioctl() as I wrote:

	SRpnt->sr_request.buffer = buffer;
        if (buffer && SRpnt->sr_host->unchecked_isa_dma &&
            (virt_to_phys(buffer) + buflength - 1 > ISA_DMA_THRESHOLD)) {
                bounce_buffer = (char *) scsi_malloc((buflength + 511) & ~511);
                if (bounce_buffer == NULL) {
                        printk("SCSI DMA pool exhausted.");
                        return -ENOMEM;
                }
                memcpy(bounce_buffer, (char *) buffer, buflength);
                buffer = bounce_buffer;
        }

I haven't looked through BK to see where this got removed, it's clearly
a bug since noone this is basically the last place where you could
bounce.

-- 
Jens Axboe

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Dr. Ernst Molitor]

Dear James Bottomley, 

thank you very much for your patch; I have applied it, but it does not
appreciably change things. The messages (as far as I can read it - I'm
still missing the first few lines...) have not changed at all, and
booting still ends up in a kernel panic. 

I'd be more than happy to check out additional patches ...

Best wishes and regards, 

Ernst

On Fri, 2004-02-20 at 08:49 -0800, James Bottomley wrote:

> On Fri, 2004-02-20 at 00:30, Dr. Ernst Molitor wrote:
> > Please don't hesitate to contact me if I can be of any further help in
> > this matter.
> 
> The problem seems to be a non-GFP_DMA allocation in sr.c.  Could you try
> this patch?
> 
> Thanks,
> 
> James
> 
> ===== drivers/scsi/sr.c 1.98 vs edited =====
> --- 1.98/drivers/scsi/sr.c	Mon Feb  9 12:59:10 2004
> +++ edited/drivers/scsi/sr.c	Fri Feb 20 08:47:55 2004
> @@ -716,7 +716,7 @@
>  	set_disk_ro(cd->disk, 1);
>  
>  	/* allocate a request for the TEST_UNIT_READY */
> -	SRpnt = scsi_allocate_request(cd->device, GFP_KERNEL);
> +	SRpnt = scsi_allocate_request(cd->device, GFP_KERNEL | GFP_DMA);
>  	if (!SRpnt) {
>  		printk(KERN_WARNING "(get_capabilities:) Request allocation "
>  		       "failure.\n");
> 
> 
> ______________________________________
> Inflex - installed on mailserver for domain @mibi03.meb.uni-bonn.de
> Queries to: postmaster@mibi03.meb.uni-bonn.de

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Jens Axboe]

On Fri, Feb 20 2004, James Bottomley wrote:
> On Fri, 2004-02-20 at 00:38, Jens Axboe wrote:
> > Hmm... James, sr_do_ioctl() used to do bouncing for private commands,
> > any reason it doesn't do that anymore?
> 
> OK, I've looked through the file history, I can't find anywhere that it
> used to do this.
> 
> However, the true solution is to see if we can get scsi_wait_req to go
> through the sg_io code path...that way the block layer will bounce for
> us and we can kill the use_sg == 0 code path in all the drivers.

The SCSI code is still pretty fucked up wrt clean use of struct
request... REQ_SPECIAL should just mean that ->special is assigned (and
holds a struct scsi_request), not be a request type on its own. That
fact alone makes it impossible to cleanly do REQ_BLOCK_PC conversions.
Add to that, that gendisk are inside the drivers and it's even worse.

Something half-assed like this should work as an immediate fix...

===== drivers/scsi/scsi_lib.c 1.118 vs edited =====
--- 1.118/drivers/scsi/scsi_lib.c	Mon Feb  2 17:14:22 2004
+++ edited/drivers/scsi/scsi_lib.c	Mon Feb 23 17:44:09 2004
@@ -954,7 +960,8 @@
 			cmd = scsi_get_command(sreq->sr_device, GFP_ATOMIC);
 			if (unlikely(!cmd))
 				goto defer;
-			scsi_init_cmd_from_req(cmd, sreq);
+			if (!blk_pc_request(req))
+				scsi_init_cmd_from_req(cmd, sreq);
 		} else
 			cmd = req->special;
 	} else if (req->flags & (REQ_CMD | REQ_BLOCK_PC)) {
===== drivers/scsi/sr.c 1.98 vs edited =====
--- 1.98/drivers/scsi/sr.c	Mon Feb  9 21:59:10 2004
+++ edited/drivers/scsi/sr.c	Mon Feb 23 15:03:57 2004
@@ -557,20 +559,22 @@
 
 	sdev->sector_size = 2048;	/* A guess, just in case */
 
-	/* FIXME: need to handle a get_capabilities failure properly ?? */
-	get_capabilities(cd);
-	sr_vendor_init(cd);
-
 	snprintf(disk->devfs_name, sizeof(disk->devfs_name),
 			"%s/cd", sdev->devfs_name);
 	disk->driverfs_dev = &sdev->sdev_gendev;
-	register_cdrom(&cd->cdi);
 	set_capacity(disk, cd->capacity);
 	disk->private_data = &cd->driver;
 	disk->queue = sdev->request_queue;
 
 	dev_set_drvdata(dev, cd);
 	add_disk(disk);
+
+	/* FIXME: need to handle a get_capabilities failure properly ?? */
+	get_capabilities(cd);
+	sr_vendor_init(cd);
+
+	if (register_cdrom(&cd->cdi))
+		goto fail_put;
 
 	printk(KERN_DEBUG
 	    "Attached scsi CD-ROM %s at scsi%d, channel %d, id %d, lun %d\n",
===== drivers/scsi/sr_ioctl.c 1.31 vs edited =====
--- 1.31/drivers/scsi/sr_ioctl.c	Mon Aug 25 15:37:40 2003
+++ edited/drivers/scsi/sr_ioctl.c	Mon Feb 23 17:44:44 2004
@@ -90,14 +90,35 @@
         }
 	SRpnt->sr_data_direction = cgc->data_direction;
 
+	/* map cgc to a REQ_BLOCK_PC command. in the future cgc will
+	 * disappear, the uniform layer can place REQ_BLOCK_PC commands
+	 * directly on ide-cd/sr target queues
+	 */
+	req = SRpnt->sr_request;
+
+	req->cmd_len = COMMAND_SIZE(cgc->cmd[0]);
+	memcpy(req->cmd, cgc->cmd, req->cmd_len);
+	req->data = cgc->buffer;
+	req->data_len = cgc->buflen;
+	req->timeout = cgc->timeout;
+	req->sense = SRpnt->sr_sense_buffer;
+	req->sense_len = 0;
+	if (cgc->quiet)
+		req->flags |= REQ_QUIET;
+	if (cgc->data_direction == CGC_DATA_WRITE)
+		req->flags |= REQ_RW;
+	req->flags |= REQ_BLOCK_PC;
+	req->rq_disk = cd->disk;
+
       retry:
 	if (!scsi_block_when_processing_errors(SDev)) {
 		err = -ENODEV;
 		goto out_free;
 	}
 
-	scsi_wait_req(SRpnt, cgc->cmd, cgc->buffer, cgc->buflen,
-		      cgc->timeout, IOCTL_RETRIES);
+	/* we have no real use of the passed in data pointers... */
+	scsi_wait_req(SRpnt, req->cmd, req->data, req->data_len,
+		      req->timeout, IOCTL_RETRIES);
 
 	req = SRpnt->sr_request;
 	if (SRpnt->sr_buffer && req->buffer && SRpnt->sr_buffer != req->buffer) {


-- 
Jens Axboe

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[James Bottomley]

On Mon, 2004-02-23 at 10:48, Jens Axboe wrote:
> Something half-assed like this should work as an immediate fix...

But I don't see how this bounces the buffer?  Without a bio, this simply
passes req->data (which is cgc->buffer) into cmd->request_buffer in
scsi_init_io(); but the problem was that this buffer is outside the
dma_mask.


James

Re: Fw: PROBLEM: Linux V. 2.6.3 panics with "Buffers at physical address >16Mb used for aha1542" at boot time

[Jens Axboe]

On Mon, Feb 23 2004, James Bottomley wrote:
> On Mon, 2004-02-23 at 10:48, Jens Axboe wrote:
> > Something half-assed like this should work as an immediate fix...
> 
> But I don't see how this bounces the buffer?  Without a bio, this simply
> passes req->data (which is cgc->buffer) into cmd->request_buffer in
> scsi_init_io(); but the problem was that this buffer is outside the
> dma_mask.

Duh you are right, I completely forgot about that. Well that really
settles the fact that it must be bio backed, and that use_sg should just
die in the same iteration.

It was a step in the wrong direction regardless, I'd love to kill ->data
eventually.

Anyways, I have another way to solve this without shaking
scsi_wait_req() up too much. The way I see it, you cannot implement what
you want there, you simply don't have access to everything you need to
make it possible. The best way is to add a few helpers to map to a (bio
backed) request and have sr/sd/st call these to set things up. I'll give
that a go.

-- 
Jens Axboe