Berck E. Nash wrote:
Greetings,
I get a few million of these on boot-- the system never actually boots.
Works fine in 2.6.23-rc7.
[ 50.456012] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 50.462484] ata2.00: irq_stat 0x4001
[ 50.466441] ata2.00: cmd
Berck E. Nash wrote:
Greetings,
I get a few million of these on boot-- the system never actually boots.
Works fine in 2.6.23-rc7.
[ 50.456012] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 50.462484] ata2.00: irq_stat 0x4001
[ 50.466441] ata2.00: cmd
Berck E. Nash wrote:
> Bernd Schmidt wrote:
>> One of these appears in my system as well (ASUS P5W-DH Deluxe
>> mainboard). Here's the hdparm output:
>
> Yup, same mainboard here.
>
>> Since about 2.6.17 or 2.6.18, it has been causing long delays while
>> booting:
>> ata2: SATA link up 3.0 Gbps
Bernd Schmidt wrote:
> One of these appears in my system as well (ASUS P5W-DH Deluxe
> mainboard). Here's the hdparm output:
Yup, same mainboard here.
> Since about 2.6.17 or 2.6.18, it has been causing long delays while
> booting:
> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>
Jeff Garzik wrote:
> Would it also be possible for you to send along 'hdparm --Istdout'
> output for your config disk thingy, /dev/sdd ?
Sure, just don't ask me what it is! (I've generally assumed that
writing to it would be a bad idea.)
Berck
/dev/sdd:
0040 3fff c837 0010 003f
Jeff Garzik wrote:
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
/dev/sdb:
0040 3fff c837 0010 003f
Jeff Garzik wrote:
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
/dev/sdb:
0040 3fff c837 0010 003f
Jeff Garzik wrote:
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
Sure, just don't ask me what it is! (I've generally assumed that
writing to it would be a bad idea.)
Berck
/dev/sdd:
0040 3fff c837 0010 003f
Bernd Schmidt wrote:
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
Yup, same mainboard here.
Since about 2.6.17 or 2.6.18, it has been causing long delays while
booting:
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00:
Berck E. Nash wrote:
Bernd Schmidt wrote:
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
Yup, same mainboard here.
Since about 2.6.17 or 2.6.18, it has been causing long delays while
booting:
ata2: SATA link up 3.0 Gbps (SStatus 123
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Berck E. Nash wrote:
Jeff Garzik wrote:
Does the attached patch change behavior at all? You should be able to
apply it on top of libata-dev.git#upstream or -mm.
Still broken, dmesg with ATA_DEBUG defined, attached.
Great, this will be useful output. It will probably be a couple days
Berck E. Nash wrote:
Jeff Garzik wrote:
Once the blame has been squared fixed upon me :) you can use git-bisect
to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit
Robert Hancock wrote:
ATA spec says "The device shall return command aborted if the device
does not support the Power Management feature set." Whereas TEST UNIT
READY is required for SCSI. It seems the SAT authors didn't consider
this case.
Dumb me -- I misread that as mandatory.
Berck E. Nash wrote:
> hdparm output attached.
Whoops, it really is this time.
/dev/sde:
427a 3fff 0010 e100 0258 003f
000e 5744 2d57 4d41 4b48 3131 3235
3131 3700 0003 4000 004a 3331
2e30 3846 3331 5744 4320 5744 3336 3047
442d 3030 464c 4132 2020 2020 2020 2020
2020
Jeff Garzik wrote:
Berck E. Nash wrote:
Jeff Garzik wrote:
Once the blame has been squared fixed upon me :) you can use git-bisect
to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit
Jeff Garzik wrote:
> Can you tell me something about this device?
>
> [ 49.045635] ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133
> [ 49.051677] ata2.00: 640 sectors, multi 1: LBA
> [ 49.056321] ata2.00: configured for UDMA/133
>
> It seems like it does not support the 'check power
Berck E. Nash wrote:
Jeff Garzik wrote:
Once the blame has been squared fixed upon me :) you can use git-bisect
to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit
Jeff Garzik wrote:
> Once the blame has been squared fixed upon me :) you can use git-bisect
> to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit 268fe6f9f15551be9abedd44a237392675d529d5
Author: Jeff
On Tue, Sep 25 2007, Berck E. Nash wrote:
> Jens Axboe wrote:
> > On Tue, Sep 25 2007, Berck E. Nash wrote:
> >> Jeff Garzik wrote:
> >>
> >>> The first step would be to clone the "upstream" branch of
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> >>>
> >>> and see if
Jens Axboe wrote:
> On Tue, Sep 25 2007, Berck E. Nash wrote:
>> Jeff Garzik wrote:
>>
>>> The first step would be to clone the "upstream" branch of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>>
>>> and see if the problem is reproducible there. If yes, then you have
On Tue, Sep 25 2007, Berck E. Nash wrote:
> Jeff Garzik wrote:
>
> > The first step would be to clone the "upstream" branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> >
> > and see if the problem is reproducible there. If yes, then you have
> > narrowed down
Jeff Garzik wrote:
> The first step would be to clone the "upstream" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
> and see if the problem is reproducible there. If yes, then you have
> narrowed down the problem to something my ATA devel tree has introduced
Jeff Garzik wrote:
The first step would be to clone the upstream branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
and see if the problem is reproducible there. If yes, then you have
narrowed down the problem to something my ATA devel tree has introduced
into
On Tue, Sep 25 2007, Berck E. Nash wrote:
Jeff Garzik wrote:
The first step would be to clone the upstream branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
and see if the problem is reproducible there. If yes, then you have
narrowed down the problem to
Jens Axboe wrote:
On Tue, Sep 25 2007, Berck E. Nash wrote:
Jeff Garzik wrote:
The first step would be to clone the upstream branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
and see if the problem is reproducible there. If yes, then you have
narrowed down the
On Tue, Sep 25 2007, Berck E. Nash wrote:
Jens Axboe wrote:
On Tue, Sep 25 2007, Berck E. Nash wrote:
Jeff Garzik wrote:
The first step would be to clone the upstream branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
and see if the problem is
Jeff Garzik wrote:
Once the blame has been squared fixed upon me :) you can use git-bisect
to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit 268fe6f9f15551be9abedd44a237392675d529d5
Author: Jeff
Berck E. Nash wrote:
Jeff Garzik wrote:
Once the blame has been squared fixed upon me :) you can use git-bisect
to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit
Jeff Garzik wrote:
Can you tell me something about this device?
[ 49.045635] ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133
[ 49.051677] ata2.00: 640 sectors, multi 1: LBA
[ 49.056321] ata2.00: configured for UDMA/133
It seems like it does not support the 'check power mode'
Jeff Garzik wrote:
Berck E. Nash wrote:
Jeff Garzik wrote:
Once the blame has been squared fixed upon me :) you can use git-bisect
to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit
Berck E. Nash wrote:
hdparm output attached.
Whoops, it really is this time.
/dev/sde:
427a 3fff 0010 e100 0258 003f
000e 5744 2d57 4d41 4b48 3131 3235
3131 3700 0003 4000 004a 3331
2e30 3846 3331 5744 4320 5744 3336 3047
442d 3030 464c 4132 2020 2020 2020 2020
2020
Robert Hancock wrote:
ATA spec says The device shall return command aborted if the device
does not support the Power Management feature set. Whereas TEST UNIT
READY is required for SCSI. It seems the SAT authors didn't consider
this case.
Dumb me -- I misread that as mandatory.
Berck E. Nash wrote:
Jeff Garzik wrote:
Once the blame has been squared fixed upon me :) you can use git-bisect
to locate the precise change that broke your setup.
Okay, here's the problem:
268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit
commit
Berck E. Nash wrote:
Jeff Garzik wrote:
Does the attached patch change behavior at all? You should be able to
apply it on top of libata-dev.git#upstream or -mm.
Still broken, dmesg with ATA_DEBUG defined, attached.
Great, this will be useful output. It will probably be a couple days
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Berck E. Nash wrote:
Greetings,
I get a few million of these on boot-- the system never actually boots.
Works fine in 2.6.23-rc7.
[ 50.456012] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 50.462484] ata2.00: irq_stat 0x4001
[ 50.466441] ata2.00: cmd
Berck E. Nash wrote:
Greetings,
I get a few million of these on boot-- the system never actually boots.
Works fine in 2.6.23-rc7.
[ 50.456012] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 50.462484] ata2.00: irq_stat 0x4001
[ 50.466441] ata2.00: cmd
38 matches
Mail list logo
