Jim MacBaine writes:
Hi,
Recently I'm experiencing strange sata errors on my desktop system.
The system was recently equipped with three 250 GB SATA drives from
Clue #1: added drives
three different manufacturers and I'm having an identical problem on
two of them. The drives are
$ hdparm --Istdin hdparm.out
ATA device, with non-removable media
Model Number: Integrated Technology Express Inc
Serial Number: G!
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
Other than that, I guess the solutions would be to just set a 32-bit
mask on the device if either port has an ATAPI device connected (which
is fairly ugly, considering that you could do things like hotplug an
ATAPI device when the other port was in use, for example), or do
something to
On Sun, 13 Jan 2008, Alan Cox wrote:
$ hdparm --Istdin hdparm.out
ATA device, with non-removable media
Model Number: Integrated Technology Express Inc
Serial Number: G!
Standards:
Likely used: 1
Configuration:
Logical max current
On Sun, 2008-01-13 at 13:33 +, Alan Cox wrote:
Other than that, I guess the solutions would be to just set a 32-bit
mask on the device if either port has an ATAPI device connected (which
is fairly ugly, considering that you could do things like hotplug an
ATAPI device when the
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with this one, you know everything will work.
The different device one is
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote:
Yes, I concur for the short term. The other two possible courses of
action either involve long discussions (the different device one) or
you'll never quite be sure you got all the paths (the GFP_DMA32 one).
At least with this one, you
http://bugzilla.kernel.org/show_bug.cgi?id=5911
--- Comment #12 from [EMAIL PROTECTED] 2008-01-13 11:05 ---
Created an attachment (id=14437)
-- (http://bugzilla.kernel.org/attachment.cgi?id=14437action=view)
copy of minicom bootlog panic.txt
2.6.24-r6-mm1 does not seem quite ready
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 26 +++---
1 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 2b9885f..7648684 100644
--- a/drivers/ide/ide-floppy.c
+++
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 90 ++---
1 files changed, 36 insertions(+), 54 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 7648684..06d83cb 100644
---
Also,
- remove the accompanying 4 byte idefloppy_capacity_header.
- rename functions from idefloppy_... to ide_floppy_... after cleanup.
- simplify loop in ide_floppy_get_capacity() by reversing if-test condition
logically.
- finally, fix white space and checkpatch.pl issues
Signed-off-by:
By passing idefloppy_floppy_t *floppy to the factored out functions, we get
rid of (almost) all local vars so stack usage should be at minimum here. Also,
we merge idefloppy_begin_format() into idefloppy_format_start() since it is its
only user. Also, rename idefloppy_format_start() to
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 00ea8d6..5004773 100644
--- a/drivers/ide/ide-floppy.c
+++
We merge idefloppy_{input,output}_buffers() into idefloppy_io_buffers() by
introducing a 4th arg. called direction. According to its value
we atapi_input_bytes() or atapi_output_bytes(). Also, this simplifies the
interrupt handler logic a bit. Finally, rename idefloppy_io_buffers() to
This info is already available through ioctl() and /proc
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 63 +
1 files changed, 13 insertions(+), 50 deletions(-)
diff --git a/drivers/ide/ide-floppy.c
In addition to shortening the function name, move the printk-call into the
function thereby saving some code lines. Also, make the function out_of_line
since it is not on a performance critical path. Finally, rename the reworked
function to ide_floppy..().
Signed-off-by: Borislav Petkov [EMAIL
This flag is not being set anywhere in the driver so it can go.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index
Hi Bart,
here are the remaining patches which had issues to be worked out. I decided
to keep the Flexible Disk Page and Capacity Descriptor in
idefloppy_floppy_t for the sake of the two printk calls for which they are
used. Otherwise, we'll be changing long-known driver behavior and this won't
be
..and replace them with flag enums.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 132 +
1 files changed, 73 insertions(+), 59 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index
such as
ERROR: switch and case should be at the same indent
ERROR: need spaces around that '=' (ctx:VxV)
ERROR: trailing statements should be on next line
WARNING: no space between function name and open parenthesis '('
WARNING: printk() should include KERN_ facility level
ERROR: That open brace {
Hello,
During heavy disk load on my laptop, sometimes the IDE disk will pause for a
second and then continue. I get this in my kernel log:
[ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb
Hi,
I've just tried the 2.6.24-rc7 kernel (from Debian's experimental kernel
archive), running the x86_64 kernel.
I keep getting things like this in my log:
Jan 13 19:21:10 intrepid kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0
action 0xa frozen
Jan 13 19:21:10 intrepid kernel: ata2:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ
write switching problem we've been trying to solve, and it
doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which prevented
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ
write switching problem we've been trying to solve, and it
doesn't look
like it fixes that one - if I apply this patch and then remove the
udelay(20) in sata_nv.c that I added which
Robert Hancock wrote:
As I mentioned, this doesn't seem to resolve the problem we're seeing
with rapidly intermixed NCQ commands and cache flushes (at
least, if I
take out the arbitrary 20usec delay from the driver and add
this patch,
the problem still shows up). It could be a similar
25 matches
Mail list logo
