On 10/11/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> >>> That missing +1 would explain, why the SGE_TRM never gets set.
> >> Thanks a lot for tracking this down. Does changing the above code fix
> >> your problem?
> >
> > I did not try it.
> > I'm not an libata expert and
On Thu, Oct 11 2007, Tejun Heo wrote:
> Jens Axboe wrote:
> > This is the old ata_sg_is_last:
> >
> > static inline int
> > ata_sg_is_last(struct scatterlist *sg, struct ata_queued_cmd *qc)
> > {
> > if (sg == >pad_sgent)
> > return 1;
> > if (qc->pad_len)
> >
Jens Axboe wrote:
> This is the old ata_sg_is_last:
>
> static inline int
> ata_sg_is_last(struct scatterlist *sg, struct ata_queued_cmd *qc)
> {
> if (sg == >pad_sgent)
> return 1;
> if (qc->pad_len)
> return 0;
> if (((sg - qc->__sg) + 1)
On Thu, Oct 11 2007, Tejun Heo wrote:
> Torsten Kaiser wrote:
> > Looking closer at
> > http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
> > the change to libata.h seems bogus :
> >
> > in ata_qc_first_sg:
> > old
Torsten Kaiser wrote:
>>> That missing +1 would explain, why the SGE_TRM never gets set.
>> Thanks a lot for tracking this down. Does changing the above code fix
>> your problem?
>
> I did not try it.
> I'm not an libata expert and while this change looks suspicios, I
> can't be 100% sure if
Torsten Kaiser wrote:
That missing +1 would explain, why the SGE_TRM never gets set.
Thanks a lot for tracking this down. Does changing the above code fix
your problem?
I did not try it.
I'm not an libata expert and while this change looks suspicios, I
can't be 100% sure if that change
On Thu, Oct 11 2007, Tejun Heo wrote:
Torsten Kaiser wrote:
Looking closer at
http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
the change to libata.h seems bogus :
in ata_qc_first_sg:
old
Jens Axboe wrote:
This is the old ata_sg_is_last:
static inline int
ata_sg_is_last(struct scatterlist *sg, struct ata_queued_cmd *qc)
{
if (sg == qc-pad_sgent)
return 1;
if (qc-pad_len)
return 0;
if (((sg - qc-__sg) + 1) ==
On Thu, Oct 11 2007, Tejun Heo wrote:
Jens Axboe wrote:
This is the old ata_sg_is_last:
static inline int
ata_sg_is_last(struct scatterlist *sg, struct ata_queued_cmd *qc)
{
if (sg == qc-pad_sgent)
return 1;
if (qc-pad_len)
return
On 10/11/07, Tejun Heo [EMAIL PROTECTED] wrote:
Torsten Kaiser wrote:
That missing +1 would explain, why the SGE_TRM never gets set.
Thanks a lot for tracking this down. Does changing the above code fix
your problem?
I did not try it.
I'm not an libata expert and while this change
On 10/11/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> > Looking closer at
> > http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
> > the change to libata.h seems bogus :
> >
> > in ata_qc_first_sg:
> >
Torsten Kaiser wrote:
> Looking closer at
> http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
> the change to libata.h seems bogus :
>
> in ata_qc_first_sg:
> oldnew
> return qc->__sg
Torsten Kaiser wrote:
Looking closer at
http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
the change to libata.h seems bogus :
in ata_qc_first_sg:
oldnew
return qc-__sg
On 10/11/07, Tejun Heo [EMAIL PROTECTED] wrote:
Torsten Kaiser wrote:
Looking closer at
http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
the change to libata.h seems bogus :
in ata_qc_first_sg:
old
[Adding Jens Axboe, the author of what looks like the probable cause]
On 10/7/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> My sil24_fill_sg now looks like this:
> static inline void sil24_fill_sg(struct ata_queued_cmd *qc,
> struct sil24_sge *sge)
> {
>
On 10/5/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> So I will use the weekend to see if I can find out who issues this
> command and add more debug to that place...
I added some DPRINTK to sil24_qc_issue and sil24_fill_sg, but I only
found one suspicious thing.
My sil24_fill_sg now looks
On 10/5/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
So I will use the weekend to see if I can find out who issues this
command and add more debug to that place...
I added some DPRINTK to sil24_qc_issue and sil24_fill_sg, but I only
found one suspicious thing.
My sil24_fill_sg now looks like
[Adding Jens Axboe, the author of what looks like the probable cause]
On 10/7/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
My sil24_fill_sg now looks like this:
static inline void sil24_fill_sg(struct ata_queued_cmd *qc,
struct sil24_sge *sge)
{
struct
On 10/4/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 04, 2007 at 07:32:52AM +0200, Torsten Kaiser wrote:
> > So now I'm rather out of ideas what to test... :(
>
> I'd give your previous bisect step another try.
Yes, I thought about that too. But I never seemed to need more than
two
On 10/4/07, Matt Mackall [EMAIL PROTECTED] wrote:
On Thu, Oct 04, 2007 at 07:32:52AM +0200, Torsten Kaiser wrote:
So now I'm rather out of ideas what to test... :(
I'd give your previous bisect step another try.
Yes, I thought about that too. But I never seemed to need more than
two tries to
On Thu, Oct 04, 2007 at 07:32:52AM +0200, Torsten Kaiser wrote:
> On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > Well I can see no reason why the vma we just got to by the mm->mmap
> > would have a vm_mm != mm, but I've certainly been wrong before.
> >
> > Try changing it to:
> >
> >
On Thu, Oct 04, 2007 at 07:32:52AM +0200, Torsten Kaiser wrote:
On 10/3/07, Matt Mackall [EMAIL PROTECTED] wrote:
Well I can see no reason why the vma we just got to by the mm-mmap
would have a vm_mm != mm, but I've certainly been wrong before.
Try changing it to:
for (vma =
On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> Well I can see no reason why the vma we just got to by the mm->mmap
> would have a vm_mm != mm, but I've certainly been wrong before.
>
> Try changing it to:
>
> for (vma = mm->mmap; vma; vma = vma->vm_next)
> if
On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 07:36:55PM +0200, Torsten Kaiser wrote:
> > Of note might be, that at the time of this error init has not been
> > started. I'm using a program from initramfs to start the RAID.
> > The initramfs was primarily build
On Wed, Oct 03, 2007 at 07:36:55PM +0200, Torsten Kaiser wrote:
> On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
> > > This patch removes clear_refs_smap() from fs/proc/task_mmu.c by moving
> > > its code to a new function.
On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
> > This patch removes clear_refs_smap() from fs/proc/task_mmu.c by moving
> > its code to a new function. But during the move the main for-loop from
> > clear_refs_smap was
On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
> [CC added to author of the bad patch]
>
> Short recap:
> Since 2.6.23-rc4-mm1 all mm-kernel randomly fail one of two drives on
> my Silicon Image 3132. This failure happens when my initramfs wants to
> start the RAID that is on
[CC added to author of the bad patch]
Short recap:
Since 2.6.23-rc4-mm1 all mm-kernel randomly fail one of two drives on
my Silicon Image 3132. This failure happens when my initramfs wants to
start the RAID that is on these drives.
The first error libata throws is:
Oct 3 16:56:46 treogen [
On 10/1/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On 9/30/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > On 9/30/07, Tejun Heo <[EMAIL PROTECTED]> 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
On 10/1/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
On 9/30/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
On 9/30/07, Tejun Heo [EMAIL PROTECTED] 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
[CC added to author of the bad patch]
Short recap:
Since 2.6.23-rc4-mm1 all mm-kernel randomly fail one of two drives on
my Silicon Image 3132. This failure happens when my initramfs wants to
start the RAID that is on these drives.
The first error libata throws is:
Oct 3 16:56:46 treogen [
On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
[CC added to author of the bad patch]
Short recap:
Since 2.6.23-rc4-mm1 all mm-kernel randomly fail one of two drives on
my Silicon Image 3132. This failure happens when my initramfs wants to
start the RAID that is on these
On 10/3/07, Matt Mackall [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
This patch removes clear_refs_smap() from fs/proc/task_mmu.c by moving
its code to a new function. But during the move the main for-loop from
clear_refs_smap was changed:
On Wed, Oct 03, 2007 at 07:36:55PM +0200, Torsten Kaiser wrote:
On 10/3/07, Matt Mackall [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
This patch removes clear_refs_smap() from fs/proc/task_mmu.c by moving
its code to a new function. But during
On 10/3/07, Matt Mackall [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 07:36:55PM +0200, Torsten Kaiser wrote:
Of note might be, that at the time of this error init has not been
started. I'm using a program from initramfs to start the RAID.
The initramfs was primarily build using the
On 10/3/07, Matt Mackall [EMAIL PROTECTED] wrote:
Well I can see no reason why the vma we just got to by the mm-mmap
would have a vm_mm != mm, but I've certainly been wrong before.
Try changing it to:
for (vma = mm-mmap; vma; vma = vma-vm_next)
if
On 9/30/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On 9/30/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Torsten Kaiser wrote:
> > > What I find kind of interessing is, that while I got three different
> > > error codes the cmd part of the output was always the same.
> >
> > That's NCQ write
On 9/30/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
On 9/30/07, Tejun Heo [EMAIL PROTECTED] wrote:
Torsten Kaiser wrote:
What I find kind of interessing is, that while I got three different
error codes the cmd part of the output was always the same.
That's NCQ write command. You'll
On 9/30/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> > What I find kind of interessing is, that while I got three different
> > error codes the cmd part of the output was always the same.
>
> That's NCQ write command. You'll be using it a lot if you're rebuilding
> md5.
Torsten Kaiser wrote:
> That boot ended in a minimal initrd environment that normally only
> starts the RAID5 and then opens contained encrypted real root.
> I was just able to push the output from dmesg through the serial link,
> but had no man pages to tell me about -s ...
> And that kind of
On 9/30/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, Torsten.
>
> Torsten Kaiser wrote:
> > On 9/28/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> >> So in case of -rc3-mm1 I'm pretty sure that it works.
> >
> > That's still the case.
>
> Ah... that's weird. It would be much better if
Hello, Torsten.
Torsten Kaiser wrote:
> On 9/28/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
>> So in case of -rc3-mm1 I'm pretty sure that it works.
>
> That's still the case.
Ah... that's weird. It would be much better if -rc3-mm1 is broken too. :-P
>> Not completely sure is if
On 9/28/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> So in case of -rc3-mm1 I'm pretty sure that it works.
That's still the case.
> Not completely sure is if 2.6.23-rc7-sglist kernel works. I booted
> that 9 times, but from a quick look in /var/log/messages, I might not
> have hit the
On 9/28/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
So in case of -rc3-mm1 I'm pretty sure that it works.
That's still the case.
Not completely sure is if 2.6.23-rc7-sglist kernel works. I booted
that 9 times, but from a quick look in /var/log/messages, I might not
have hit the correct
Hello, Torsten.
Torsten Kaiser wrote:
On 9/28/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
So in case of -rc3-mm1 I'm pretty sure that it works.
That's still the case.
Ah... that's weird. It would be much better if -rc3-mm1 is broken too. :-P
Not completely sure is if 2.6.23-rc7-sglist
On 9/30/07, Tejun Heo [EMAIL PROTECTED] wrote:
Hello, Torsten.
Torsten Kaiser wrote:
On 9/28/07, Torsten Kaiser [EMAIL PROTECTED] wrote:
So in case of -rc3-mm1 I'm pretty sure that it works.
That's still the case.
Ah... that's weird. It would be much better if -rc3-mm1 is broken too.
Torsten Kaiser wrote:
That boot ended in a minimal initrd environment that normally only
starts the RAID5 and then opens contained encrypted real root.
I was just able to push the output from dmesg through the serial link,
but had no man pages to tell me about -s ...
And that kind of error
On 9/30/07, Tejun Heo [EMAIL PROTECTED] wrote:
Torsten Kaiser wrote:
What I find kind of interessing is, that while I got three different
error codes the cmd part of the output was always the same.
That's NCQ write command. You'll be using it a lot if you're rebuilding
md5.
It's not
On 9/27/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> > Known good is for me 2.6.23-rc3-mm1, the first known bad is 2.6.23-rc4-mm1.
> > I will try to look at the diff between these revisions some more, but
> > the change in sata_sil24.c looked like a perfect match for the
> >
Torsten Kaiser wrote:
> Known good is for me 2.6.23-rc3-mm1, the first known bad is 2.6.23-rc4-mm1.
> I will try to look at the diff between these revisions some more, but
> the change in sata_sil24.c looked like a perfect match for the
> symptoms I was seeing.
I think the first thing to do here
On 9/27/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> > I compared the dmesg form good and bad boots with -rc7-mm1 but could
> > not see any difference, so do you think that these additional
> > diagnostics could show a difference?
> > Or could you suggest any other
Torsten Kaiser wrote:
On 9/27/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Tejun Heo wrote:
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
On 9/27/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Tejun Heo wrote:
> > Torsten Kaiser wrote:
> >> Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
> >> following change looked the most suspicions to me:
> >>
On 9/27/07, Tejun Heo [EMAIL PROTECTED] wrote:
Tejun Heo wrote:
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
Torsten Kaiser wrote:
On 9/27/07, Tejun Heo [EMAIL PROTECTED] wrote:
Tejun Heo wrote:
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
On 9/27/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Torsten Kaiser wrote:
I compared the dmesg form good and bad boots with -rc7-mm1 but could
not see any difference, so do you think that these additional
diagnostics could show a difference?
Or could you suggest any other debugging options I
Torsten Kaiser wrote:
Known good is for me 2.6.23-rc3-mm1, the first known bad is 2.6.23-rc4-mm1.
I will try to look at the diff between these revisions some more, but
the change in sata_sil24.c looked like a perfect match for the
symptoms I was seeing.
I think the first thing to do here is
On 9/27/07, Tejun Heo [EMAIL PROTECTED] wrote:
Torsten Kaiser wrote:
Known good is for me 2.6.23-rc3-mm1, the first known bad is 2.6.23-rc4-mm1.
I will try to look at the diff between these revisions some more, but
the change in sata_sil24.c looked like a perfect match for the
symptoms I
Tejun Heo wrote:
> Torsten Kaiser wrote:
>> Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
>> following change looked the most suspicions to me:
>>
Torsten Kaiser wrote:
> Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
> following change looked the most suspicions to me:
>
As reported in the "2.6.23-rc4-mm1"-thread and the "What's in
linux-2.6-block.git for 2.6.24"-thread I'm having trouble that
sometimes on bootup one drive from the SiI-3132 throws errors and
becomes inaccesible.
The latest kernel I have seen this error was 2.6.23-rc7-mm1.
>From 7 boots 2 times
As reported in the 2.6.23-rc4-mm1-thread and the What's in
linux-2.6-block.git for 2.6.24-thread I'm having trouble that
sometimes on bootup one drive from the SiI-3132 throws errors and
becomes inaccesible.
The latest kernel I have seen this error was 2.6.23-rc7-mm1.
From 7 boots 2 times the
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
Tejun Heo wrote:
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
64 matches
Mail list logo
