On a number of boards the current prereset logic seems to misbehave:
scsi0 : pata_platform
ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
ata1: device not ready (errno=-19), forcing hardreset
ata1: BUG: prereset() requested invalid reset type
This triggers when there is
Thanks for fixing this. Can you post with proper subject line and
Signed-off-by?
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Mundt wrote:
On a number of boards the current prereset logic seems to misbehave:
scsi0 : pata_platform
ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
ata1: device not ready (errno=-19), forcing hardreset
ata1: BUG: prereset() requested invalid reset type
On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote:
Paul Mundt wrote:
On a number of boards the current prereset logic seems to misbehave:
scsi0 : pata_platform
ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
ata1: device not ready (errno=-19), forcing
Tomasz Chmielewski schrieb:
Today at night, I had a serious sata_mv driver failure on one of the
servers.
I tested the drive in question with both smart and badblocks, but none
shown any errors - so my quick conclusion is that something is not right
with the sata_mv driver.
The server has
Some SATA controllers (sata_sil) use 0xff to indicate port not ready
status, not port empty. As libata interprets 0xff as port empty, this
causes unnecessary reset failure and retry. Don't consider 0xff as
port empty if SStatus is available and indicates that port is online.
Signed-off-by:
Hi Bart,
I have resent four patches for the ATI SB700 chipset, could you please help me
check if these patches are applied?
I list all patches as following, Thanks for your help!
BRs,
Henry
[PATCH 1/4] add the SMBus device ID for ATI SB700
From: [EMAIL PROTECTED]
add the SMBUS device id for
Paul Mundt wrote:
On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote:
Paul Mundt wrote:
On a number of boards the current prereset logic seems to misbehave:
scsi0 : pata_platform
ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
ata1: device not ready
On Wed, May 23, 2007 at 11:29:37AM +0200, Tejun Heo wrote:
Paul Mundt wrote:
On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote:
Paul Mundt wrote:
On a number of boards the current prereset logic seems to misbehave:
scsi0 : pata_platform
ata1: PATA max PIO0 cmd 0xb06001f0 ctl
During prereset, -ENODEV return from ata_wait_ready() is not an error.
This causes unnecessary bug message on controllers which uses 0xff to
indicate empty port. Fix it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
---
This one is for 2.6.22 too. Thanks.
Everyone, I tried rebuilding 2.6.22-rc2 last night with CONFIG_IDE
disabled, but it still produces the same problem. The relevant config
options:
# CONFIG_IDE is not set
CONFIG_ATA=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
CONFIG_ATA_PIIX=y
CONFIG_PATA_JMICRON=y
Ethan, you mention that
Tomasz Chmielewski wrote:
..
The error I mentioned before - BUG: at drivers/ata/sata_mv.c:1236
mv_qc_issue() - happened on /dev/sda drive.
As it appears, my /dev/sdb drive just dies (has multiple badblocks). It
causes similar errors when I tried to dd if=/dev/ero of=/dev/sdb.
It triggered
On Tue, 15 May 2007 16:14:57 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
That one is the right one. I think the only diffs vs. the previous
one that was missing a quilt ref are I wasn't initializing altstatus
address and I turned some printk's into dev_dbg() as that's really
what
I'd be interested in feedback on the effects of the following
particularly on systems that currently fail with libata, and especially
on non-PC systems where the firmware hasn't neccessarily initialized the
disk before Linux takes control
diff -u --new-file --recursive --exclude-from
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
Send an uevent to user space to indicate that a media change event has
occurred.
Signed-off-by: Kristen Carlson Accardi [EMAIL
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
Send an uevent to user space to indicate that a media change
On Wed, 23 May 2007 12:03:55 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi [EMAIL
On Wed, 2007-05-23 at 11:26 -0700, Kristen Carlson Accardi wrote:
On Wed, 23 May 2007 12:03:55 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
On Tue, 22 May 2007 14:12:11 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 23 May 2007 13:51:51 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 11:26 -0700, Kristen Carlson Accardi wrote:
On Wed, 23 May 2007 12:03:55 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
The motherboard has 4 ide controllers total; two olde-fashioned
ones (PIIX4, using the original 40-pin IDE ribbon cable) and two
HighPoint HPT366 controllers, taking the 80-pin
On Wed, 23 May 2007 15:11:18 -0500
[EMAIL PROTECTED] (Linas Vepstas) wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
HPT366 fixes were posted here earlier. It doesn't in fact have reliable
enable bits.
-
To unsubscribe
Hello.
Linas Vepstas wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
The motherboard has 4 ide controllers total; two olde-fashioned
ones (PIIX4, using the original 40-pin IDE ribbon cable) and two
You should have
Hello.
Alan Cox wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
HPT366 fixes were posted here earlier. It doesn't in fact have reliable
enable bits.
HPT36x either didn't have them yet or they were located in
On 05/23/2007 04:24 PM, Alan Cox wrote:
On Wed, 23 May 2007 15:11:18 -0500
[EMAIL PROTECTED] (Linas Vepstas) wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
HPT366 fixes were posted here earlier. It doesn't in fact
On Thu, May 24, 2007 at 12:26:29AM +0400, Sergei Shtylyov wrote:
Hello.
Linas Vepstas wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
The motherboard has 4 ide controllers total; two olde-fashioned
ones (PIIX4, using
On Wed, 2007-05-23 at 14:42 +0100, Alan Cox wrote:
I'm going to have to NAK this on further review as it will break SRST
handling in some cases. Until ata_bus_softreset has been fixed (see
FIXME: entries) we shouldn't push this patch mainstream, or if we have
then someone should fix the
Hrm... so all MMIO drivers (PDC, etc...) are broken you think ?
If they use the SRST and the chipset does more than tiny amounts of mmio
posting then yes.
What would be the solution there ? A read to flush the posted write to
the control register would work in the middle of a soft reset ? If
The sata_sis driver supports SATA and PATA ports. The broken support
of both types in one controller is fixed.
the pata133 sis controllers does not support a drive present status
in the pci configspace like the older sis controllers, check removed.
Signed-off-by: Uwe Koziolek [EMAIL PROTECTED]
On Thu, 2007-05-24 at 00:31 +0100, Alan Cox wrote:
Anything non taskfile, which is tricky to do arbitarily for all
controllers - this is why I didn't just stuff in a simple fix and post it.
We might have to provide an optional -flush() that is device specific ?
Config space access would do
On Thu, May 24, 2007 at 09:43:39AM +1000, Benjamin Herrenschmidt wrote:
We might have to provide an optional -flush() that is device specific ?
Probably
Config space access would do the job nicely in most cases though. If
it's really only for SRST which can be slow. If it's for the 400ns of
the pata133 sis controllers does not support a drive present status
in the pci configspace like the older sis controllers, check removed.
Are you sure about this - I've no idea about the SATA/PATA combo but the
pure PATA 133Mhz (MuTOL 96x) chipsets seem to do so correctly.
Signed-off-by: Uwe
Hi,
On Wednesday 16 May 2007, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
There's no reason to have the speedproc() method wrapper for the two quite
different chip families, so just get rid of it.
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
applied
I
On Wednesday 16 May 2007, Alan Cox wrote:
It turns out from customer reports to Red Hat and some PCI dumps that the
MegaIDE in RAID mode doesn't provide the drive tuning data that the
serverworks driver expects but sometimes does provide something that
fools the code.
For the RAID class
Hi,
On Wednesday 16 May 2007, Adrian Bunk wrote:
On Tue, May 15, 2007 at 08:19:14PM -0700, Andrew Morton wrote:
...
- Added an i386 early-startup development tree, as git-newsetup.patch (H.
Peter Anvin [EMAIL PROTECTED])
...
Changes since 2.6.21-mm2:
...
git-newsetup.patch
...
On Tuesday 22 May 2007, Junio C Hamano wrote:
There are a few entries in ata_device_blacklist[] in libata-core.c
marked with HORKAGE_NODMA but are missing from drive_blacklist[]
in ide-dma.c. This patch makes the lists in sync.
Also remove a duplicated entry for SanDisk SDP3B-64.
On Monday 21 May 2007, Dave Jones wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=1044
has been open for _four_ years with a patch available.
Here's a rediffed version of the same.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
Uh, it seems that this fix got stuck in the kernel black hole
On Friday 18 May 2007, Mika Kukkonen wrote:
Compiling with '-Wswitch-enum' I noticed following:
CC drivers/ide/ide-proc.o
drivers/ide/ide-proc.c: In function ‘proc_ide_read_imodel’:
drivers/ide/ide-proc.c:54: warning: enumeration value ‘ide_etrax100’ not
handled in switch
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ide/ide-dma.c |4 +++-
drivers/ide/ide-proc.c|2 ++
drivers/ide/pci/atiixp.c |1 +
drivers/ide/pci/serverworks.c | 14 ++
On Thu, 24 May 2007, Bartlomiej Zolnierkiewicz wrote:
diff --git a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
index 6234f80..47bcd91 100644
--- a/drivers/ide/pci/serverworks.c
+++ b/drivers/ide/pci/serverworks.c
@@ -173,7 +179,7 @@ dma_pio:
On Wed, 23 May 2007, Linus Torvalds wrote:
So please, please, please, realize that the compiler is _stupid_, and
fixing warnings without understanding the code is bad.
Btw, this is fundamental. If you don't need to understand the code, then
the compiler could have just fixed it for you,
40 matches
Mail list logo
