Re: sata_sil24 broken since 2.6.23-rc4-mm1

["Torsten Kaiser" <just.for.lkml@googlemail.com>]

On 10/1/07, Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> On 9/30/07, Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> > On 9/30/07, Tejun Heo <htejun@gmail.com> wrote:
> > > Torsten Kaiser wrote:
> To make that comment "cmd part of the output was always the same" more
> clear: I did not only mean that the first (cmd-)byte was the same, but
> the whole line:
> cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
>
> I did find ATA_CMD_FPDMA_WRITE = 0x61in ata.h, but I don't find a good
> hint for the 08 that follows. The interpretation XFER_PIO_0 = 0x08
> seems wrong...

Even all of the last bisect steps still showed the same line...

> If I look at what patches remain, it seems that some other (earlier)
> patch that is new in 2.6.23-rc4-mm1 is the trigger, but it will only
> fail together with a second patch.

I'm now finished with bisecting, still 2 patches, but I don't want to
spend another two hours waiting...

And the winners are: (from broken-out patchset of 2.6.23-rc4-mm1)
maps2-simplify-interdependence-of-proc-pid-maps-and-smaps.patch
maps2-move-clear_refs-code-to-task_mmuc.patch

Before these patches I have never seen the bug, with these I only got
two good boots when trying to recreate the problem. But even the
kernels that did one good boot failed on the second try.

> > As for you printk:
>From the last testkernel (up to incl.
maps2-move-clear_refs-code-to-task_mmuc.patch)

Good:
Oct  3 15:50:39 treogen [    3.780000] XXX sil24 cb=ffff810005dd0000
cb_dma=5dd0000
Oct  3 15:50:39 treogen [    3.790000] XXX sil24 cb=ffff810005de0000
cb_dma=5de0000

Bad:
Oct  3 16:56:46 treogen [    3.750000] XXX sil24 cb=ffff810005de0000
cb_dma=5de0000
Oct  3 16:56:46 treogen [    3.760000] XXX sil24 cb=ffff810005df0000
cb_dma=5df0000

I have *NO* clue how these procfs changes can kill the sata_sil24
driver, but all bisect steps point to these two patches as cause or
trigger of the bug.

Torsten