Hello list,
I'm running Gentoo Linux with kernel 2.6.29 on a PPC9600 with a G3
processor upgrade.
My boot drive is on the internal "mesh" SCSI-controller. Self-compiled
kernel 2.6.29 is running fine for quite some time.
However, after compiling 2.6.30 (with more or less the same
configuration), I get this BUG (typed over from a picture, sorry for
possible typos):
kernel BUG at
/usr/src/linux-2.6.30-gentoo-r3/arch/powerpc/include/asm/dma-mapping.h:218!
Oops: Exception in kernel mode, sig: 5 [#1]
PowerMac
Modules linked in:
NIP: c01bb4cc LR: c01c01cc CTR: c01c01
REGS: ...
MSR: ...
TASK = c030f500[0] 'swapper' THREAD: ...
GPR00: ...
GPR08: ...
GPR16: ...
GPR24: ...
NIP [c01bb4cc] scsi_dma_map+0x4c/0x7c
LR [c01c01cc] start_phase+0x3a0/0x5c8
I found on the list a patch by Benjamin :
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073468.html
I applied this patch to the 2.6.30 source-tree.
After applying this patch, the BUG dissapears, but the mesh controller
still is not able to read any data from disk. The screen output is:
mesh: performing initial bus reset...
ADB mouse at 3, handler set to 2
input: ADB mouse as /devices/virtual/input/input2
adb: finished probe task...
scsi0: MESH
mesh: target 0 synchronous at 10MB/s
scsi 0:0:0:0: Direct-Access ...
mesh: target 1 synchronous at 10 MB/s
scsi 0:0:1:0: Direct-Access ...
mesh: target 3 synchronous at 10 MB/s
scsi 0:0:3:0: CD-ROM ...
mice: PS/2 mouse device common for all mice
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
[there's a long time-out here]
mesh_abort(ef8501e0)
mesh: state at ef868a4c, regs at f1010000, dma at
ct= 1 seq=5a bs=4023 fc= 0 exc= 0 err= 0 in=
dma stat=e0 cmdptr=2f8d4010
phase=6 msgphase=4 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=0
target 0: req=ef8501e0 goes_out=0 saved_ptr=0
mesh_abort(ef850280)
(continues some times, to finally panic because the root-device cannot
be found)
I tried the latest 2.6.31-rc3-git3 (without any other patch).
However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
but the mesh_abort messages).
Anybody knows what's going wrong, and how to fix it? I've read the
history of this list of June and July ... but I didn't find any other
reports of the problem I'm encountering...
Thank you for your help.
Kind regards
Stef Simoens
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2009-07-24 08:52:40
On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
I tried the latest 2.6.31-rc3-git3 (without any other patch).
However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
but the mesh_abort messages).
Anybody knows what's going wrong, and how to fix it? I've read the
history of this list of June and July ... but I didn't find any other
reports of the problem I'm encountering...
Would it be possible for you to roughly find out at what kernel version
it stopped working ? (Some kernels may need my patch to avoid crashing)
I have a machine with a MESH here that -appears- to work, at least it
did last time I tried it which was a couple of weeks ago, I'll try again
just to be sure.
Cheers,
Ben.
On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
quoted
I tried the latest 2.6.31-rc3-git3 (without any other patch).
However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
but the mesh_abort messages).
Would it be possible for you to roughly find out at what kernel version
it stopped working ? (Some kernels may need my patch to avoid crashing)
I am currently running 2.6.29-gentoo-r5 (that's somewhere at the end of
2.6.29, probably 2.6.29.5).
I compiled 2.6.30 as soon as it came 'stable'.
In any version of 2.6.30, I encounter the BUG (dma-mapping.h:218).
I didn't react immediately, I actually guessed that the problem would have
been reported and solved in another 2.6.30.x.
Because it didn't, I started browsing the mailing-list (and found your
patch).
2.6.30-gentoo-r3 with your patch applied doesn't give the bug,
but gives the mesh_abort.
Before asking the question, I wanted to build the latest 2.6.31-rc
available to make sure my problem didn't get solved in the meantime.
2.6.31-rc3 gives the same mesh_abort.
Would you like me to try all the linux-2.6.30-rc?
Could you give me your best guess starting-point?
I know that there exists something as git-disect ... but I have never used
git (there always needs to be the first time, of course).
Kind regards,
Stef
On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
quoted
I tried the latest 2.6.31-rc3-git3 (without any other patch).
However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
but the mesh_abort messages).
Would it be possible for you to roughly find out at what kernel version
it stopped working ? (Some kernels may need my patch to avoid crashing)
2.6.29 works OK
2.6.30-rc1 doesn't work (BUG...)
2.6.30-rc1 with your patch ... seems to hang when it should be mounting
the root directory.
Is it worthwhile doing a git bisect?
--
Kind regards,
Stef Simoens
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2009-07-29 23:32:44
On Wed, 2009-07-29 at 20:22 +0200, Stef Simoens wrote:
2.6.29 works OK
2.6.30-rc1 doesn't work (BUG...)
2.6.30-rc1 with your patch ... seems to hang when it should be
mounting the root directory.
Is it worthwhile doing a git bisect?
It probably is, since it should work with my patch, so something else
changed, maybe in the SCSI stack.
One thing I know is that the MESH HW has "issues" that make it very
sensitive to alignment DMA buffers, it's possible that the SCSI stack no
longer aligns some stuff ?
Cheers,
Ben.
On Wed, 2009-07-29 at 20:22 +0200, Stef Simoens wrote:
quoted
2.6.29 works OK
2.6.30-rc1 doesn't work (BUG...)
2.6.30-rc1 with your patch ... seems to hang when it should be
mounting the root directory.
Is it worthwhile doing a git bisect?
It probably is, since it should work with my patch, so something else
changed, maybe in the SCSI stack.
What would be the best approach?
- if the kernel boots, it's obviously 'good'
- but what if the kernel hits the 'BUG', should I apply your patch then?
If it doesn't work with your patch, would it be 'bad' then?
One thing I know is that the MESH HW has "issues" that make it very
sensitive to alignment DMA buffers, it's possible that the SCSI stack no
longer aligns some stuff ?
Hmm, great... how can I verify this?
--
Regards,
Stef Simoens
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2009-07-30 00:52:38
On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
What would be the best approach?
- if the kernel boots, it's obviously 'good'
- but what if the kernel hits the 'BUG', should I apply your patch
then? If it doesn't work with your patch, would it be 'bad' then?
Yes.
quoted
One thing I know is that the MESH HW has "issues" that make it very
sensitive to alignment DMA buffers, it's possible that the SCSI stack no
longer aligns some stuff ?
Hmm, great... how can I verify this?
I will once we get a closer idea of where the bug started to happen.
Thanks !
Cheers,
Ben.
On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
quoted
What would be the best approach?
- if the kernel boots, it's obviously 'good'
- but what if the kernel hits the 'BUG', should I apply your patch
then? If it doesn't work with your patch, would it be 'bad' then?
A few reboots later...
As you said, during my bisecting, at a certain moment I needed your
patch (I booted, got a problem, patched the tree with your patch,
rebooted, it worked).
Then, git says:
f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit
commit f078727b250c2653fc9a564f15547c17ebac3f99
Author: FUJITA Tomonori [off-list ref]
Date: Sun Dec 14 01:23:45 2008 +0900
[SCSI] remove scsi_req_map_sg
No one uses scsi_execute_async with data transfer now. We can remove
scsi_req_map_sg.
Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door
doesn't handle sense and the callback. So we can remove
scsi_io_context too.
Signed-off-by: FUJITA Tomonori [off-list ref]
Signed-off-by: James Bottomley [off-list ref]
:040000 040000 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44
3ffca800399e52ef12f1001721c0c7ff431efafd M drivers
:040000 040000 805c02c4ad3c63c45dffa18f413e92bfca99caf6
6fb58bb5fb19c4198fa7d626d6241086655c6307 M include
At this moment, the reason for the crash is different then in v2.6.30
I noted the following (I hope to have written the most important stuff).
driver 'sd' needs update
mesh: lost arbitration
sd 0:0:0:0 sda read CAPACITY failed
sd ...
sd 0:0:0:0 sdb read CAPACITY failed
sd ...
mice
sd ...
mice: PS/2 ...
TCP cubic ...
Initializing XFRM ...
NET ... protcol 17
XFS ...
VFS : unable to mount root FS
If you want more input ... please let me know.
--
Kr,
Stef Simoens
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2009-08-02 23:13:57
On Sun, 2009-08-02 at 10:52 +0200, Stef Simoens wrote:
Hey Benjamin,
Thanks for the bisection. I'll have a look when I'm back from skiing :-)
In the meantime, maybe Fujita has an idea ?
Mesh is an old crappy piece of HW with an old driver full of dark
secrets that Paulus wrote eons ago, so I'd rather avoid cracking it
open :-)
Cheers,
Ben.
Benjamin Herrenschmidt schreef:
quoted
On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
quoted
What would be the best approach?
- if the kernel boots, it's obviously 'good'
- but what if the kernel hits the 'BUG', should I apply your patch
then? If it doesn't work with your patch, would it be 'bad' then?
A few reboots later...
As you said, during my bisecting, at a certain moment I needed your
patch (I booted, got a problem, patched the tree with your patch,
rebooted, it worked).
Then, git says:
f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit
commit f078727b250c2653fc9a564f15547c17ebac3f99
Author: FUJITA Tomonori [off-list ref]
Date: Sun Dec 14 01:23:45 2008 +0900
[SCSI] remove scsi_req_map_sg
No one uses scsi_execute_async with data transfer now. We can
remove
scsi_req_map_sg.
Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door
doesn't handle sense and the callback. So we can remove
scsi_io_context too.
Signed-off-by: FUJITA Tomonori [off-list ref]
Signed-off-by: James Bottomley
[off-list ref]
:040000 040000 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44
3ffca800399e52ef12f1001721c0c7ff431efafd M drivers
:040000 040000 805c02c4ad3c63c45dffa18f413e92bfca99caf6
6fb58bb5fb19c4198fa7d626d6241086655c6307 M include
At this moment, the reason for the crash is different then in v2.6.30
I noted the following (I hope to have written the most important
stuff).
driver 'sd' needs update
mesh: lost arbitration
sd 0:0:0:0 sda read CAPACITY failed
sd ...
sd 0:0:0:0 sdb read CAPACITY failed
sd ...
mice
sd ...
mice: PS/2 ...
TCP cubic ...
Initializing XFRM ...
NET ... protcol 17
XFS ...
VFS : unable to mount root FS
If you want more input ... please let me know.
--
Kr,
Stef Simoens
plain text document attachment (git-bisect-log)
git bisect start
# good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
# bad: [577c9c456f0e1371cbade38eaf91ae8e8a308555] Linux 2.6.30-rc1
git bisect bad 577c9c456f0e1371cbade38eaf91ae8e8a308555
# bad: [5658ae9007490c18853fbf112f1b3516f5949e62] V4L/DVB (10342): gspca - stv06xx: Add ctrl caching to the vv6410.
git bisect bad 5658ae9007490c18853fbf112f1b3516f5949e62
# good: [08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
git bisect good 08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6
# good: [6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2
git bisect good 6e15cf04860074ad032e88c306bea656bbdd0f22
# bad: [eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30] Merge git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-for-30
git bisect bad eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30
# good: [0870352bc6e0dee485c86a0c99dd60e7089c8917] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
git bisect good 0870352bc6e0dee485c86a0c99dd60e7089c8917
# good: [febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect good febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a
# bad: [21283916322f579a580e413652cdefbfa3ec676f] [SCSI] zfcp: remove undefined subtype for status read response
git bisect bad 21283916322f579a580e413652cdefbfa3ec676f
# good: [6864abd8b730435d6ae9cb061095229a5a85153f] [SCSI] osd: Kconfig file for in-tree builds
git bisect good 6864abd8b730435d6ae9cb061095229a5a85153f
# bad: [b3f1f9aa082b2ab86dec4db3d8b1566af345387e] [SCSI] ses: code_set == 1 is tested twice
git bisect bad b3f1f9aa082b2ab86dec4db3d8b1566af345387e
# bad: [ea41e41588c248ee8b8162869c1e1c0565a4b3f6] [SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler
git bisect bad ea41e41588c248ee8b8162869c1e1c0565a4b3f6
# bad: [f078727b250c2653fc9a564f15547c17ebac3f99] [SCSI] remove scsi_req_map_sg
git bisect bad f078727b250c2653fc9a564f15547c17ebac3f99
# good: [78a42ce8fb2604c459e9ebb2a4f2d546b8250111] [SCSI] osst: make all the buffer the same size
git bisect good 78a42ce8fb2604c459e9ebb2a4f2d546b8250111
# good: [26243043f207b3faa00594a33e10b2103205f27b] [SCSI] osst: replace scsi_execute_async with the block layer API
git bisect good 26243043f207b3faa00594a33e10b2103205f27b
On Mon, 03 Aug 2009 09:13:37 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
On Sun, 2009-08-02 at 10:52 +0200, Stef Simoens wrote:
quoted
Hey Benjamin,
Thanks for the bisection. I'll have a look when I'm back from skiing :-)
In the meantime, maybe Fujita has an idea ?
The commit just removes the unused functions. So I'm not sure how this
patch could cause any regression.
Looks like that READ CAPACITY fails. We use kmalloc'ed buffer for READ
CAPACITY so I'm not sure about an alignment issue that you mentioned
in this thread earlier.
You said your machine with a MESH appears to work. Did you confirm it?
Mesh is an old crappy piece of HW with an old driver full of dark
secrets that Paulus wrote eons ago, so I'd rather avoid cracking it
open :-)
Cheers,
Ben.
quoted
Benjamin Herrenschmidt schreef:
quoted
On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
quoted
What would be the best approach?
- if the kernel boots, it's obviously 'good'
- but what if the kernel hits the 'BUG', should I apply your patch
then? If it doesn't work with your patch, would it be 'bad' then?
A few reboots later...
As you said, during my bisecting, at a certain moment I needed your
patch (I booted, got a problem, patched the tree with your patch,
rebooted, it worked).
Then, git says:
f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit
commit f078727b250c2653fc9a564f15547c17ebac3f99
Author: FUJITA Tomonori [off-list ref]
Date: Sun Dec 14 01:23:45 2008 +0900
[SCSI] remove scsi_req_map_sg
No one uses scsi_execute_async with data transfer now. We can
remove
scsi_req_map_sg.
Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door
doesn't handle sense and the callback. So we can remove
scsi_io_context too.
Signed-off-by: FUJITA Tomonori [off-list ref]
Signed-off-by: James Bottomley
[off-list ref]
:040000 040000 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44
3ffca800399e52ef12f1001721c0c7ff431efafd M drivers
:040000 040000 805c02c4ad3c63c45dffa18f413e92bfca99caf6
6fb58bb5fb19c4198fa7d626d6241086655c6307 M include
At this moment, the reason for the crash is different then in v2.6.30
I noted the following (I hope to have written the most important
stuff).
driver 'sd' needs update
mesh: lost arbitration
sd 0:0:0:0 sda read CAPACITY failed
sd ...
sd 0:0:0:0 sdb read CAPACITY failed
sd ...
mice
sd ...
mice: PS/2 ...
TCP cubic ...
Initializing XFRM ...
NET ... protcol 17
XFS ...
VFS : unable to mount root FS
If you want more input ... please let me know.
--
Kr,
Stef Simoens
plain text document attachment (git-bisect-log)
git bisect start
# good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
# bad: [577c9c456f0e1371cbade38eaf91ae8e8a308555] Linux 2.6.30-rc1
git bisect bad 577c9c456f0e1371cbade38eaf91ae8e8a308555
# bad: [5658ae9007490c18853fbf112f1b3516f5949e62] V4L/DVB (10342): gspca - stv06xx: Add ctrl caching to the vv6410.
git bisect bad 5658ae9007490c18853fbf112f1b3516f5949e62
# good: [08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
git bisect good 08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6
# good: [6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2
git bisect good 6e15cf04860074ad032e88c306bea656bbdd0f22
# bad: [eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30] Merge git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-for-30
git bisect bad eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30
# good: [0870352bc6e0dee485c86a0c99dd60e7089c8917] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
git bisect good 0870352bc6e0dee485c86a0c99dd60e7089c8917
# good: [febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect good febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a
# bad: [21283916322f579a580e413652cdefbfa3ec676f] [SCSI] zfcp: remove undefined subtype for status read response
git bisect bad 21283916322f579a580e413652cdefbfa3ec676f
# good: [6864abd8b730435d6ae9cb061095229a5a85153f] [SCSI] osd: Kconfig file for in-tree builds
git bisect good 6864abd8b730435d6ae9cb061095229a5a85153f
# bad: [b3f1f9aa082b2ab86dec4db3d8b1566af345387e] [SCSI] ses: code_set == 1 is tested twice
git bisect bad b3f1f9aa082b2ab86dec4db3d8b1566af345387e
# bad: [ea41e41588c248ee8b8162869c1e1c0565a4b3f6] [SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler
git bisect bad ea41e41588c248ee8b8162869c1e1c0565a4b3f6
# bad: [f078727b250c2653fc9a564f15547c17ebac3f99] [SCSI] remove scsi_req_map_sg
git bisect bad f078727b250c2653fc9a564f15547c17ebac3f99
# good: [78a42ce8fb2604c459e9ebb2a4f2d546b8250111] [SCSI] osst: make all the buffer the same size
git bisect good 78a42ce8fb2604c459e9ebb2a4f2d546b8250111
# good: [26243043f207b3faa00594a33e10b2103205f27b] [SCSI] osst: replace scsi_execute_async with the block layer API
git bisect good 26243043f207b3faa00594a33e10b2103205f27b
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2009-08-05 01:11:50
On Wed, 2009-08-05 at 10:04 +0900, FUJITA Tomonori wrote:
Looks like that READ CAPACITY fails. We use kmalloc'ed buffer for READ
CAPACITY so I'm not sure about an alignment issue that you mentioned
in this thread earlier.
You said your machine with a MESH appears to work. Did you confirm it?
Not yet. It's a fishy machine that needs other patches to get back to
working condition, I haven't had time yet (everybody's sick at home so
I've been mostly off the office and the machine is there).
I'm pretty sure the MESH will have issues though if the DMA buffers
aren't at least 16 (or maybe it's 32) bytes aligned. I don't think it's
a cache alignment issue, I suspect it's an issue with the DBDMA engine
queue on those chips though (it -could- be cache coherency bugs too,
never know with those old Apple home made chipsets).
I remember we had problems in the past with IDENTIFY iirc, which would
work normally as kmalloc() would return something cache line aligned...
until one enabled SLAB debugging.
Cheers,
Ben.
Hello,
Some time ago (July 24th 2009 my mailbox says) I emailed you and the
linuxppc-dev list about my problems booting from the mesh SCSI controller.
I just compiled 2.6.31 (actually, gentoo-sources-2.6.31-r10); but the
problem remains
I know that 2.6.33 is out, but as I didn't see any changes to the
mesh-driver I guess that the problem is still there ...
This is the logging I get when I boot (2.6.31):
mesh_abort(ef8501e0)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
dma stat=e0 cmdptr=2f8c2010
phase=5 msgphase=0 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=0
target 0: req=ef85901e0 goes_out=0 saved_ptr=0
mesh_abort(ef850280)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
dma stat=e0 cmdptr=2f8c2010
phase=5 msgphase=0 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=0
target 0: req=ef8501e0 goes_out=0 saved_ptr=0
mesh_host_reset
mesh_abort(ef8501e0)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 0 seq=6a bs=4026 fc= 5 exc= 0 err= 0 im= 7 int= 0 sp= 2
fifo data=c0
fifo data=01
fifo data=03
fifo data=01
fifo data=19
dma stat=e0 cmdptr=2f8c2010
phase=3 msgphase=1 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=6
target 0: req=ef8501e0 goes_out=0 saved_ptr=0
mesh_host_reset
...
[afterwards, it "disconnects" all the disks and then it panics as it
cannot find the root partition]
2.6.29 runs fine ... but I guess that at some point, I would like to
upgrade to the latest stable kernel.
The machine is a PowerPC9600 with a 740 upgrade card, 1GB memory, kernel
compiled with GCC 4.3.4 ...
Of course I am willing to offer you all assistance you need to help you
pin-point the problem...
Thanks for your help
Stef
Stef Simoens schreef:
Hello Ben,
Thank you for your reply.
quoted
On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
quoted
I tried the latest 2.6.31-rc3-git3 (without any other patch).
However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
but the mesh_abort messages).
Would it be possible for you to roughly find out at what kernel version
it stopped working ? (Some kernels may need my patch to avoid crashing)
I am currently running 2.6.29-gentoo-r5 (that's somewhere at the end of
2.6.29, probably 2.6.29.5).
I compiled 2.6.30 as soon as it came 'stable'.
In any version of 2.6.30, I encounter the BUG (dma-mapping.h:218).
I didn't react immediately, I actually guessed that the problem would have
been reported and solved in another 2.6.30.x.
Because it didn't, I started browsing the mailing-list (and found your
patch).
2.6.30-gentoo-r3 with your patch applied doesn't give the bug,
but gives the mesh_abort.
Before asking the question, I wanted to build the latest 2.6.31-rc
available to make sure my problem didn't get solved in the meantime.
2.6.31-rc3 gives the same mesh_abort.
Would you like me to try all the linux-2.6.30-rc?
Could you give me your best guess starting-point?
I know that there exists something as git-disect ... but I have never used
git (there always needs to be the first time, of course).
Kind regards,
Stef
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2010-03-18 23:35:31
On Fri, 2010-03-19 at 00:21 +0100, Stef Simoens wrote:
Hello,
Some time ago (July 24th 2009 my mailbox says) I emailed you and the
linuxppc-dev list about my problems booting from the mesh SCSI
controller.
I just compiled 2.6.31 (actually, gentoo-sources-2.6.31-r10); but the
problem remains
I know that 2.6.33 is out, but as I didn't see any changes to the
mesh-driver I guess that the problem is still there ...
Sadly I haven't had a chance to look. The MESH driver is a pretty
complicated thing that I didn't write and am not familiar with, so it's
going to take some work to sort out what's going on, and so far I
haven't had time to dedicate to this.
Cheers,
Ben.
This is the logging I get when I boot (2.6.31):
mesh_abort(ef8501e0)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
dma stat=e0 cmdptr=2f8c2010
phase=5 msgphase=0 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=0
target 0: req=ef85901e0 goes_out=0 saved_ptr=0
mesh_abort(ef850280)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
dma stat=e0 cmdptr=2f8c2010
phase=5 msgphase=0 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=0
target 0: req=ef8501e0 goes_out=0 saved_ptr=0
mesh_host_reset
mesh_abort(ef8501e0)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 0 seq=6a bs=4026 fc= 5 exc= 0 err= 0 im= 7 int= 0 sp= 2
fifo data=c0
fifo data=01
fifo data=03
fifo data=01
fifo data=19
dma stat=e0 cmdptr=2f8c2010
phase=3 msgphase=1 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=6
target 0: req=ef8501e0 goes_out=0 saved_ptr=0
mesh_host_reset
...
[afterwards, it "disconnects" all the disks and then it panics as it
cannot find the root partition]
2.6.29 runs fine ... but I guess that at some point, I would like to
upgrade to the latest stable kernel.
The machine is a PowerPC9600 with a 740 upgrade card, 1GB memory,
kernel compiled with GCC 4.3.4 ...
Of course I am willing to offer you all assistance you need to help
you pin-point the problem...
Thanks for your help
Stef
Stef Simoens schreef:
quoted
Hello Ben,
Thank you for your reply.
quoted
On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
quoted
I tried the latest 2.6.31-rc3-git3 (without any other patch).
However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
but the mesh_abort messages).
Would it be possible for you to roughly find out at what kernel version
it stopped working ? (Some kernels may need my patch to avoid crashing)
I am currently running 2.6.29-gentoo-r5 (that's somewhere at the end of
2.6.29, probably 2.6.29.5).
I compiled 2.6.30 as soon as it came 'stable'.
In any version of 2.6.30, I encounter the BUG (dma-mapping.h:218).
I didn't react immediately, I actually guessed that the problem would have
been reported and solved in another 2.6.30.x.
Because it didn't, I started browsing the mailing-list (and found your
patch).
2.6.30-gentoo-r3 with your patch applied doesn't give the bug,
but gives the mesh_abort.
Before asking the question, I wanted to build the latest 2.6.31-rc
available to make sure my problem didn't get solved in the meantime.
2.6.31-rc3 gives the same mesh_abort.
Would you like me to try all the linux-2.6.30-rc?
Could you give me your best guess starting-point?
I know that there exists something as git-disect ... but I have never used
git (there always needs to be the first time, of course).
Kind regards,
Stef