BUG in dma-mapping.h:218 // MESH SCSI driver not working

BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Stef Simoens]

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

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Benjamin Herrenschmidt]

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.

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Stef Simoens]

Hello Ben,

Thank you for your reply.

> 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).
> 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

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Stef Simoens]

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

Hello,

Benjamin Herrenschmidt schreef:
> 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).
>>     
> 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



[-- Attachment #2: Type: text/html, Size: 1112 bytes --]

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Benjamin Herrenschmidt]

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.

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Stef Simoens]

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

Benjamin Herrenschmidt schreef:
> 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.
>   
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


[-- Attachment #2: Type: text/html, Size: 1422 bytes --]

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Benjamin Herrenschmidt]

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.

> > 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.

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Stef Simoens]

[-- Attachment #1.1: Type: text/plain, Size: 1877 bytes --]

Hey Benjamin,

Benjamin Herrenschmidt schreef:
> 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? 
>>     
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 <fujita.tomonori@lab.ntt.co.jp>
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 <fujita.tomonori@lab.ntt.co.jp>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

: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


[-- Attachment #1.2: Type: text/html, Size: 3005 bytes --]

[-- Attachment #2: git-bisect-log --]
[-- Type: text/plain, Size: 2477 bytes --]

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

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Benjamin Herrenschmidt]

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: 
> > 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? 
> > >     
> 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 <fujita.tomonori@lab.ntt.co.jp>
> 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 <fujita.tomonori@lab.ntt.co.jp>
>     Signed-off-by: James Bottomley
> <James.Bottomley@HansenPartnership.com>
> 
> :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

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Benjamin Herrenschmidt]

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: 
> > 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? 
> > >     
> 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 <fujita.tomonori@lab.ntt.co.jp>
> 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 <fujita.tomonori@lab.ntt.co.jp>
>     Signed-off-by: James Bottomley
> <James.Bottomley@HansenPartnership.com>
> 
> :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

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[FUJITA Tomonori]

On Mon, 03 Aug 2009 09:13:37 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 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 ?

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.
> 
> > Benjamin Herrenschmidt schreef: 
> > > 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? 
> > > >     
> > 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 <fujita.tomonori@lab.ntt.co.jp>
> > 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 <fujita.tomonori@lab.ntt.co.jp>
> >     Signed-off-by: James Bottomley
> > <James.Bottomley@HansenPartnership.com>
> > 
> > :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

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Benjamin Herrenschmidt]

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.

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Stef Simoens]

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

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.
>   
>> 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).
>>>       
>> 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
>   
-- 
Stef Simoens                                 stef.simoens@numericable.be
+32 486 577 963                         http://users.numericable.be/stef


[-- Attachment #2: Type: text/html, Size: 4652 bytes --]

Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working

[Benjamin Herrenschmidt]

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: 
> > Hello Ben,
> > 
> > Thank you for your reply.
> >   
> > > 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).
> > > >       
> > > 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
> >   
> -- 
> Stef Simoens                                 stef.simoens@numericable.be
> +32 486 577 963                         http://users.numericable.be/stef