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 ?
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:
> 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
2
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
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
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
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
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
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
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'
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
This is not new, but exists as far back as 2.6.17. I haven't reported
it before because I figured that surely someone else had noticed it, but
since it's still unfixed and I cannot find any mention of it on LKML,
here we go.
I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is
drivers/built-in.o: In function `acpi_pci_choose_state':
pci-acpi.c:(.text+0xdccf): undefined reference to
`acpi_pm_device_sleep_state'
drivers/built-in.o: In function `pnpacpi_suspend':
core.c:(.text+0x35a7c): undefined reference to `acpi_pm_device_sleep_state'
Config file attached.
#
#
drivers/built-in.o: In function `acpi_pci_choose_state':
pci-acpi.c:(.text+0xdccf): undefined reference to
`acpi_pm_device_sleep_state'
drivers/built-in.o: In function `pnpacpi_suspend':
core.c:(.text+0x35a7c): undefined reference to `acpi_pm_device_sleep_state'
Config file attached.
#
#
This is not new, but exists as far back as 2.6.17. I haven't reported
it before because I figured that surely someone else had noticed it, but
since it's still unfixed and I cannot find any mention of it on LKML,
here we go.
I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is
I complained about this very problem months ago. Tejun Heo responded
with the attached patch which does indeed fix the problem for me.
Unfortunately, this patch hasn't made it into the kernel yet. I have no
idea why.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index
I complained about this very problem months ago. Tejun Heo responded
with the attached patch which does indeed fix the problem for me.
Unfortunately, this patch hasn't made it into the kernel yet. I have no
idea why.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index
All appears to work fine, until I try to boot a kernel with a Reiser4 /
partition. Then I get endless errors of the sort:
[ 206.349450] sd 1:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
(See attached dmesg for more, I only sent the first 1,000 lines, it goes
on
All appears to work fine, until I try to boot a kernel with a Reiser4 /
partition. Then I get endless errors of the sort:
[ 206.349450] sd 1:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
(See attached dmesg for more, I only sent the first 1,000 lines, it goes
on
Tejun Heo wrote:
> Hmmm... Once properly initialized, ahci is highly unlikely to cause
> runaway IRQs which results in nobody cared. It has proper IRQ mask and
> pending bits allowing the driver to reliably detect when and why the
> controller is raising interrupt and disable it if necessary.
Tejun Heo wrote:
Hmmm... Once properly initialized, ahci is highly unlikely to cause
runaway IRQs which results in nobody cared. It has proper IRQ mask and
pending bits allowing the driver to reliably detect when and why the
controller is raising interrupt and disable it if necessary. Can
Tejun Heo wrote:
> Please test this one instead. Thanks.
Yup, the second patch fixes it.
-Berck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Tejun Heo wrote:
Please test this one instead. Thanks.
Yup, the second patch fixes it.
-Berck
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Kernel panic on boot, console output attached.
[14316256.221707] Linux version 2.6.21-rc7-mm1 ([EMAIL PROTECTED]) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue Apr 24 12:09:02 MDT
2007
[14316256.221707] Command line: root=/dev/sdc1 ro console=tty0
Kernel panic on boot, console output attached.
[14316256.221707] Linux version 2.6.21-rc7-mm1 ([EMAIL PROTECTED]) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue Apr 24 12:09:02 MDT
2007
[14316256.221707] Command line: root=/dev/sdc1 ro console=tty0
I get the following OOPS on boot, presumably connected with USB driver
loading. I've attached the entire log. Please CC on replies as I'm not
subscribed.
[ 149.525742] Unable to handle kernel NULL pointer dereference at
0008 RIP:
[ 149.531302] [] :cdc_acm:acm_probe+0x1dd/0x741
[
I get the following OOPS on boot, presumably connected with USB driver
loading. I've attached the entire log. Please CC on replies as I'm not
subscribed.
[ 149.525742] Unable to handle kernel NULL pointer dereference at
0008 RIP:
[ 149.531302] [8887eec3]
Tejun Heo wrote:
> Berck E. Nash wrote:
>> [ 68.242305] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> [ 98.221334] ata2.00: qc timeout (cmd 0xec)
>> [ 98.225467] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104)
>> [ 108.063137] ata2: port
Tejun Heo wrote:
Berck E. Nash wrote:
[ 68.242305] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 98.221334] ata2.00: qc timeout (cmd 0xec)
[ 98.225467] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104)
[ 108.063137] ata2: port is slow to respond, please be patient
Tejun Heo wrote:
Hmm... this is difficult. The problem is that everything looks normal
until command is issued. My primary suspect still is ahci powering down
phy during initialization. Can you please test the attached patch again?
No significant difference that I can tell. I've attached
Tejun Heo wrote:
Hmm... this is difficult. The problem is that everything looks normal
until command is issued. My primary suspect still is ahci powering down
phy during initialization. Can you please test the attached patch again?
No significant difference that I can tell. I've attached
Tejun Heo wrote:
Yeah, I did and forgot about this thread too. Sorry. This is on the
top of my to-do list now. I'm attaching the patch. TIA.
That didn't fix the problem, but did change the messages. I've attached
the entire log, including the weird errors on power-off from the same
Tejun Heo wrote:
Yeah, I did and forgot about this thread too. Sorry. This is on the
top of my to-do list now. I'm attaching the patch. TIA.
That didn't fix the problem, but did change the messages. I've attached
the entire log, including the weird errors on power-off from the same
2.6.12-rc2-mm1 fails to build for me with the following error:
arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page'
include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page'
make[1]: *** [arch/i386/lib/mmx.o] Error 1
make: *** [arch/i386/lib] Error 2
I hope this is
2.6.12-rc2-mm1 fails to build for me with the following error:
arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page'
include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page'
make[1]: *** [arch/i386/lib/mmx.o] Error 1
make: *** [arch/i386/lib] Error 2
I hope this is
38 matches
Mail list logo
