Hi Tejun,
Yeah, things like these are tricky. SATA is usually the first one to
suffer from hardware defect including power fluctuation due to input
power, PSU or on-board voltage regulator problems because the link is
relatively long and runs at very high speed. I also heard that SATA
cables
OoO En ce début de soirée du vendredi 22 juin 2007, vers 21:13, Willy
Tarreau [EMAIL PROTECTED] disait:
This is a SATA CDROM. There is no PATA controller on the motherboard.
I've never tested any SATA CDROM yet. I don't even know if they work with
2.4 libata. So most likely you have more
Reloading the pata_pdc2027x module then the problem goes away.
I guess maybe somehow mdelay() is not as precise as before...
It's not the most accurate of things once power management and the like
get invovled. HT doesn't help it either. You should have get much more
accurate timing information
Does piix driver work? If so, can you post boot dmesg and the result
of
'hdparm -I /dev/hdX'?
I've still been battling to get this hardware detected with any of the
drivers mentioned previously except the newer libata piix driver. However
when using the old driver and using all-generic-ide
Hi all,
Here is a list of some known regressions in 2.6.22-rc6.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
*STATISTICS* (a.k.a. list of aces)
NameRegressions fixed since 21-Jun-2007
Andi Kleen 1
Albert Lee wrote:
Mark Lord wrote:
...
Mmm.. I don't know about the first failure there,
but after that it gets into the stuck DRQ state
which libata makes no attempt to handle at present.
It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert
could try the following
Robert de Rooy wrote:
Albert Lee wrote:
Mark Lord wrote:
...
Mmm.. I don't know about the first failure there,
but after that it gets into the stuck DRQ state
which libata makes no attempt to handle at present.
It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe
There's no reason to print out hpa related messages when HPA is not
active. Kill the unconditional message and add a warning message
which is printed if HPA size is smaller than the current size.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c | 11 +--
1 file
On Mon, 25 Jun 2007 20:45:54 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
There's no reason to print out hpa related messages when HPA is not
active. Kill the unconditional message and add a warning message
which is printed if HPA size is smaller than the current size.
Signed-off-by: Tejun Heo
prereset() is now allowed to set flag for unsupported reset method.
EH layer is responsible for selecting the fallback. Remove non-sense
warning message.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-eh.c |2 --
1 file changed, 2 deletions(-)
diff --git
Alan Cox wrote:
On Mon, 25 Jun 2007 20:45:54 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
There's no reason to print out hpa related messages when HPA is not
active. Kill the unconditional message and add a warning message
which is printed if HPA size is smaller than the current size.
The infamous abnormal status message triggers on not so abnormal cases
including empty port and even when it's being triggered on actual
errors the info it provides is redundant and out of context - higher
level functions will print the info in better safe later anyway.
Also, by being triggered
On Mon, 25 Jun 2007 21:31:05 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
The infamous abnormal status message triggers on not so abnormal cases
including empty port and even when it's being triggered on actual
errors the info it provides is redundant and out of context - higher
level functions
When EH gives up after repeated exceptions, it doesn't't clear the
PENDING bit on exit which leaves PENDING bit set without EH actually
scheduled. This makes ata_port_wait_eh() to wait forever makes rmmod
hang on such port. Fix it by clearing the flag.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Removed unused variable did_followup_srst from ata_eh_reset().
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-eh.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index d807098..48d2d54 100644
---
Fix silly condition check bug in ata_dev_disable().
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..09ade2a 100644
---
r93072 wrote:
On Mon, 25 Jun 2007 22:17:42 +0900, Tejun Heo wrote
Tejun Heo wrote:
r93072 wrote:
Hello,
I have some questions when using sata_sil24 for silicon image 3132.
One port of this chip connects to silicon image 5723. My kernel
version is 2.6.18.6. When I turn on my
From: Randy Dunlap [EMAIL PROTECTED]
Fix section mismatch when CONFIG_HOTPLUG=n (but functions are used
for resume):
WARNING: drivers/ata/pata_it821x.o(.text+0x3f): Section mismatch: reference to
.init.text: (between 'it821x_reinit_one' and 'it821x_program_udma')
WARNING:
Oops had done a reply instead of a reply to all...
---BeginMessage---
Albert Lee wrote:
The patch just workarounds the lost irq problem by polling; not real
fix. We still need to find out why irq is lost per Mark's comment:
This proves that the device does work correctly in most respects
Changed PATA handler for PATA-ports used by sata_sis.
This patch was originally submitted by Jeff Garzik.
Added PCI-ID 1180 for SiS966 Controller in pata_sis.
The 1180 mode is fully compatible to other SiS PATA-controller.
The PCI-ID 1183 is SATA in PATA-emulation, but not fully compatible
to
On Sat, Jun 23, 2007 at 10:10:34PM +0400, Sergei Shtylyov wrote:
Now I'm confused too -- did you get any DMA timeouts this time?
No. And yes, this is confusing, as the initial hang that I was seeing
was preceeded by DMA timeout messages on the screen (as posted in the
initial email). Now,
This patch was found to fix some of the problems with the
pata_ali driver. Is it going to be merged in 2.6.22?
[https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156482]
--- linux-2.6.22-rc4/drivers/ata/pata_ali.c 2007-06-04 23:05:17.0
-0700
+++ devel/drivers/ata/pata_ali.c
On Mon, Jun 25, 2007 at 10:42:22AM -0700, Randy Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
Fix section mismatch when CONFIG_HOTPLUG=n (but functions are used
for resume):
WARNING: drivers/ata/pata_it821x.o(.text+0x3f): Section mismatch: reference
to .init.text: (between
Hello,
Phil Armsdon wrote:
ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt :00:1f.2[C] - GSI 20 (level, low) - IRQ 18
ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 18
ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA8 irq 18
scsi0 : ata_piix
Alan Cox wrote:
Reloading the pata_pdc2027x module then the problem goes away.
I guess maybe somehow mdelay() is not as precise as before...
It's not the most accurate of things once power management and the like
get invovled. HT doesn't help it either. You should have get much more
Recently the PLL input clock of pata_pdc2027x is sometimes detected
higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
It seems sometimes the mdelay() function is not as precise as it
used to be. Per Alan's advice, HT or power management might affect
the precision of mdelay().
This
26 matches
Mail list logo
