Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... 4WARNING: CPU#0: NMI appears
to be stuck (0-0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0-0)!
Oops, missed that. I'll see whether there's IRQ storm going on.
I made the nv irq handler to print message every 100th time
Tom Evans wrote:
I'm also seeing this with 2.6.23-rc3 on my Alpha system - sata_sil24 and
a SiliconImage PMP.
Gaston, Tom, can you guys please apply the attached patch on top of
2.6.24-rc7 and see whether the problem goes away.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c
Tejun Heo wrote:
Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... 4WARNING: CPU#0: NMI appears
to be stuck (0-0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0-0)!
Oops, missed that. I'll see whether there's IRQ storm going on.
I made the nv irq handler to print message
On Tue, 08 Jan 2008 22:19:38 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Implement libata.force_cbl parameter to work around incorrect PATA
cable detection.
This seems to be a pretty hopeless hack as it assumes all your devices
are on the same cable (most boxes now have SATA and PATA). If we are
On Tue, 8 Jan 2008 17:26:05 +0100
Maciej Rutecki [EMAIL PROTECTED] wrote:
I have this message when resume from suspend to disk:
Looks fine to me.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I have this message when resume from suspend to disk:
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: MWDMA2 mode selected
sd 0:0:0:0: [sda] Starting disk
[...]
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
ata1.00: ACPI
Is there a workaround for the long ugly boot messages on sees
with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks
quite ugly.
I suppose that's a qemu device model bug or could it be a Linux
problem?
-Andi
Driver 'sd' needs updating - please use bus_type methods
Driver
Andi Kleen wrote:
Is there a workaround for the long ugly boot messages on sees
with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks
quite ugly.
I suppose that's a qemu device model bug or could it be a Linux
problem?
I believe this has been fixed in QEMU CVS:
On Tue, 8 Jan 2008 20:23:52 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Is there a workaround for the long ugly boot messages on sees
with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks
quite ugly.
I suppose that's a qemu device model bug or could it be a Linux
On Tue, Jan 08, 2008 at 09:04:28PM +, Alan Cox wrote:
On Tue, 8 Jan 2008 20:23:52 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Is there a workaround for the long ugly boot messages on sees
with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks
quite ugly.
I
Since I assume that qemu code base is wide spread and if a workaround
is not too ugly I think it would be nice if the kernel handled that.
Qemu behaves exactly the same way as a broken device in a situation where
data corruption may occur. It would be extremely bad to remove sanity
checking in
On Tue, Jan 08, 2008 at 09:19:31PM +, Alan Cox wrote:
Since I assume that qemu code base is wide spread and if a workaround
is not too ugly I think it would be nice if the kernel handled that.
Qemu behaves exactly the same way as a broken device in a situation where
data corruption may
On Tue, 8 Jan 2008 22:37:16 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
On Tue, Jan 08, 2008 at 09:19:31PM +, Alan Cox wrote:
Since I assume that qemu code base is wide spread and if a workaround
is not too ugly I think it would be nice if the kernel handled that.
Qemu behaves
On Tue, Jan 08, 2008 at 07:50:47PM -0400, Kevin Winchester wrote:
Andi Kleen wrote:
Here's a proposal for some useful code transformations the kernel janitors
could do as opposed to running checkpatch.pl.
snip
I notice that every driver in drivers/ata uses a .ioctl that points to
-Original Message-
From: Tejun Heo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 4:28 AM
To: Tom Evans
Cc: Gaston, Jason D; linux-ide@vger.kernel.org
Subject: Re: SATA PMP support in 2.6.24-rc3?
Tom Evans wrote:
I'm also seeing this with 2.6.23-rc3 on my Alpha system -
Sorry about the noise here - I now notice that not all .ioctl function
pointers have the option of changing to .unlocked_ioctl. In this case,
the ioctl is in the struct scsi_host_template, rather than struct
file_operations.
I'll try to be a little more careful about the git grepping in
-Original Message-
From: Gaston, Jason D
Sent: Tuesday, January 08, 2008 4:21 PM
To: 'Tejun Heo'; Tom Evans
Cc: linux-ide@vger.kernel.org
Subject: RE: SATA PMP support in 2.6.24-rc3?
-Original Message-
From: Tejun Heo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 4:28
Alan Cox wrote:
On Tue, 08 Jan 2008 22:19:38 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Implement libata.force_cbl parameter to work around incorrect PATA
cable detection.
This seems to be a pretty hopeless hack as it assumes all your devices
are on the same cable (most boxes now have SATA
Alan Cox wrote:
This only forces PATA controllers to certain cable type. It's a last
resort method for installation or live media - just enough to get things
going.
In which case we only need to be able to force UDMA33 or less ?
Cable detection goes wrong and 40c is detected as 80c.
Maciej Rutecki wrote:
I have this message when resume from suspend to disk:
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: MWDMA2 mode selected
sd 0:0:0:0: [sda] Starting disk
[...]
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd
Robert Hancock wrote:
Tejun Heo wrote:
Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... 4WARNING: CPU#0: NMI appears
to be stuck (0-0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0-0)!
Oops, missed that. I'll see whether there's IRQ storm going on.
I made the nv irq
This only forces PATA controllers to certain cable type. It's a last
resort method for installation or live media - just enough to get things
going.
In which case we only need to be able to force UDMA33 or less ?
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body
Gwendal Grignou wrote:
Fix commands timeout with Sil3124/3132 based HBA when pass-through ATA
commands [where ATA_QCFLAG_RESULT_TF is set] are used while other
commands are active on other devices
connected to the same port with a Port Multiplier.
Due to a hardware bug, these commands must be
James Bottomley wrote:
ATA requires that all DMA transfers begin and end on word boundaries.
Because of this, a large amount of machinery grew up in ide to adjust
scatterlists on this basis. However, as of 2.5, the block layer has a
dma_alignment variable which ensures both the beginning and
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... 4WARNING: CPU#0: NMI appears
to be stuck (0-0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0-0)!
Oops, missed that. I'll see whether there's IRQ storm going on.
I
Fajun Chen wrote:
Hi All,
Has anyone seen this kernel error before? The controller is Sil3124
and kernel version 2.6.18-rc2. This seems to happen very rarely since
this is the first time I 've seen this error message. Thanks for your
feedback!
2.6.18? Sadly, you're on your own there
Alan Cox wrote:
It is legitimate (although annoying and silly) for a PCI IDE controller
not to be assigned an interrupt and to be polled. The libata-sff code
should therefore not try and request IRQ 0 in this case.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive
Ondrej Zary wrote:
Hello,
I switched to libata drivers for my onboard PATA controller (PIIX4) recently.
Everything works fine except that kernel tries to start not only my hard
drive (sda) but also LS-120 floppy drive (sdb) which does not like it:
sd 0:0:0:0: [sda] Starting disk
ata1.00:
In which case we only need to be able to force UDMA33 or less ?
Cable detection goes wrong and 40c is detected as 80c. However, we got
In which case we only (see first question). I don't see why we need to
force anything but max speed UDMA 33
-
To unsubscribe from this list: send the line
Linda Walsh wrote:
Is 'main' diff between NCQ/TCQ that TCQ can re-arrange 'write'
priority under driver control, whereas NCQ is mostly a FIFO queue?
No, NCQ can reorder although I recently heard that windows issues
overlapping NCQ commands and expects them to be processed in order (what
were
Tejun Heo wrote:
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... 4WARNING: CPU#0: NMI appears
to be stuck (0-0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0-0)!
Oops, missed that. I'll see whether there's IRQ
On Wed, 2008-01-09 at 11:10 +0900, Tejun Heo wrote:
James Bottomley wrote:
ATA requires that all DMA transfers begin and end on word boundaries.
Because of this, a large amount of machinery grew up in ide to adjust
scatterlists on this basis. However, as of 2.5, the block layer has a
Alan Cox wrote:
In which case we only need to be able to force UDMA33 or less ?
Cable detection goes wrong and 40c is detected as 80c. However, we got
In which case we only (see first question). I don't see why we need to
force anything but max speed UDMA 33
Ah.. yeah, right. I somehow
Robert Hancock wrote:
Tejun Heo wrote:
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Tejun Heo wrote:
[ 34.466899] testing NMI watchdog ... 4WARNING: CPU#0: NMI
appears
to be stuck (0-0)!
[ 34.555056] WARNING: CPU#1: NMI appears to be stuck (0-0)!
Oops, missed that. I'll
James Bottomley wrote:
Also, DMA alignment at
block layer isn't enough for ATA. ATA needs drain buffers for ATAPI
commands with variable length response. :-(
OK, where is this in the libata code? The dma_pad size is only 4 bytes,
so this drain, I assume is only a word long? Given the
[cc'ing linux-ide]
Jonathan Woithe wrote:
Hi guys
I was wondering whether anyone can shed any light on the status of SATA tape
drives. There's very little info on the net about this at least in the
places I've checked; the only thing of any significance I've found thus far
is a note in a
Gaston, Jason D wrote:
For reference, here is the dmesg output from the 2.6.24-rc7 kernel W/O
the patch applied.
Man, this is weird. Do you happen to have a addonics device too? I
have one 4726 and two 3726s here and none shows such problem. Also,
there are quite a few people confirming that
Please apply the attached patch on top of 2.6.24-rc7 and report the
result. Thanks.
--
tejun
diff --git a/drivers/ata/libata-pmp.c b/drivers/ata/libata-pmp.c
index c0c4dbc..c07566c 100644
--- a/drivers/ata/libata-pmp.c
+++ b/drivers/ata/libata-pmp.c
@@ -467,7 +467,8 @@ static void
Paul Neuwirth wrote:
Hallo,
i hope I am here at the right address. I am using a Silicon Image 3124
SATA-Controller with the Silicon Image 4726 pm /
hardware-RAID product, using the sata_sil24 driver.
The pm is also a hardware raid-controller (not SATARAID - fake, see
docs on
Tejun Heo wrote:
[cc'ing linux-ide]
Jonathan Woithe wrote:
Hi guys
I was wondering whether anyone can shed any light on the status of SATA tape
drives. There's very little info on the net about this at least in the
places I've checked; the only thing of any significance I've found thus far
Mark Lord wrote:
I wouldn't buy anything with Sony on it,
Any particular reason?
but Albert thinks ATAPI tapes should be working now
(he has my old drive now).
Thanks for the info.
Regards
jonathan
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a
41 matches
Mail list logo
