This patch corrects sata_promise to classify FastTrack TX4200
(DID 3515/3519) as a second-generation chip. Promise's partial-
source FT TX4200 driver confirms this classification.
Treating it as a first-generation chip causes several problems:
1. Detection failures. This is a recent regression
On Sun, 26 Aug 2007, Geert Uytterhoeven wrote:
What I mean is that probably there used to be a printk() call starting with
`\n'. Then someone added a `KERN_ERR' in front of it.
I gather '\n' at the beginning is to assure the following line is output
on a separate line rather than as a
Hi all,
Here is a list of some known regressions in 2.6.23-rc4
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
Hello,
When my system boots, I get several set_drive_speed_status errors.
(Please see attached dmesg output.)
Can someone explain what they mean? How do I get rid of them?
Is there something I need to set in the config? or something I should
not have set?
Bonus question: is there some way
Standards:
Likely used: 1
Prehistory
LBA, IORDY not likely
No DMA, nothing above PIO2
Buffer type: 0002: dual port, multi-sector
Buffer size: 1.0kB bytes avail on r/w long: 4
Cannot perform double-word IO
Can't even do double word I/O
Just noticed this in dmesg..
ata3.00: exception Emask 0x2 SAct 0x1fffd SErr 0x0 action 0x2 frozen
ata3.00: spurious completions during NCQ issue=0x0 SAct=0x1fffd
FIS=004040a1:0004
ata3.00: cmd 61/08:00:d9:f7:09/00:00:24:00:00/40 tag 0 cdb 0x0 data 4096 out
res
On Wed, Aug 29, 2007 at 02:49:25PM -0400, Dave Jones wrote:
Just noticed this in dmesg..
ata3.00: exception Emask 0x2 SAct 0x1fffd SErr 0x0 action 0x2 frozen
ata3.00: spurious completions during NCQ issue=0x0 SAct=0x1fffd
FIS=004040a1:0004
There's a bunch of these that have been
Some places were using PCI_CLASS_REVISION instead of PCI_REVISION_ID so
they were not converted by commit 44c10138fd4bbc4b6d6bff0873c24902f2a9da65.
Cc: Auke Kok [EMAIL PROTECTED]
Cc: Greg Kroah-Hartman [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
Quick grep
Cc: Sergei Shtylyov [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/hpt366.c | 43 ---
drivers/ide/pci/piix.c |4 ++--
drivers/ide/pci/tc86c001.c | 12 ++--
3 files changed, 28
Merge init_setup_{aec62xx,aec6x80}() into aec62xx_init_one().
While at it:
* Use id-driver_data instead of dev-device.
* Use ATA_UDMA6 define.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/aec62xx.c | 39 ++-
1 file
Merge init_setup_{cmd64x,cmd646}() into cmd64x_init_one().
Cc: Sergei Shtylyov [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/cmd64x.c | 39 ---
1 file changed, 12 insertions(+), 27 deletions(-)
Index:
* Split off pdc20270_get_dev2() helper from init_setup_pdc20270().
* Merge init_setup_{pdcnew,pdc20270,pdc20276}() into pdc202new_init_one().
While at it:
* Change KERN_ level of interrupt fixup message from KERN_WARNING to KERN_INFO.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
* Split off hpt{374,371,366}_init() helper from init_setup_hpt{374,371,366}().
* Merge init_setup_{374,372n,371,372a,302,366}() into hpt366_init_one().
While at it:
* Use HPT36x name for HPT366/HPT368 chipsets.
* Add .chip_name to struct hpt_info and use it to set set d-name.
* Convert
* Split off pdc202ata4_fixup_irq() helper from init_setup_pdc202ata4().
* Merge init_setup_{pdc202ata4,pdc20265,pdc202xx}() into pdc202xx_init_one().
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/pdc202xx_old.c | 57 +
Merge init_setup_{svwks,csb6}() into svwks_init_one().
While at it:
* Remove redundant dev-device checks.
* Operate on a local copy of serverworks_chipsets[] entry.
* Use pci_resource_start().
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/serverworks.c |
Now that all users were fixed we can safely remove it.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
include/linux/ide.h |1 -
1 file changed, 1 deletion(-)
Index: b/include/linux/ide.h
===
---
Bartlomiej Zolnierkiewicz wrote:
Some places were using PCI_CLASS_REVISION instead of PCI_REVISION_ID so
they were not converted by commit 44c10138fd4bbc4b6d6bff0873c24902f2a9da65.
that's actually another effort that I'm working on atm. You can either hold off
on your patch or we'll see how
On Wednesday 29 August 2007, Kok, Auke wrote:
Bartlomiej Zolnierkiewicz wrote:
Some places were using PCI_CLASS_REVISION instead of PCI_REVISION_ID so
they were not converted by commit 44c10138fd4bbc4b6d6bff0873c24902f2a9da65.
that's actually another effort that I'm working on atm. You
https://bugzilla.redhat.com/show_bug.cgi?id=243568
Using kernel 2.6.22:
Aug 29 17:08:11 itox kernel: ata2.00: ATAPI: Seagate STT8000A, 5.51, max MWDMA2
Aug 29 17:08:11 itox kernel: ata2.00: configured for MWDMA2
Aug 29 17:08:11 itox kernel: scsi 1:0:0:0: Sequential-Access Seagate STT8000A
On Wed, 29 Aug 2007 18:55:55 -0400
Chuck Ebbert [EMAIL PROTECTED] wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=243568
Using kernel 2.6.22:
Aug 29 17:08:11 itox kernel: ata2.00: ATAPI: Seagate STT8000A, 5.51, max
MWDMA2
Aug 29 17:08:11 itox kernel: ata2.00: configured for MWDMA2
Hi Tejun and all -
I have applied the libata-tj-stable patch to the 2.6.22.1 kernel and am
having some issues.
I'm not certain if it is the PMP patches, or my platform.
I have a Silicon Images 3124-2 based PCI-X card (Norco 4618) for my
Alpha system .
I realize this is not the usual test
Chuck Ebbert wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=243568
Using kernel 2.6.22:
Aug 29 17:08:11 itox kernel: ata2.00: ATAPI: Seagate STT8000A, 5.51, max MWDMA2
Aug 29 17:08:11 itox kernel: ata2.00: configured for MWDMA2
Aug 29 17:08:11 itox kernel: scsi 1:0:0:0: Sequential-Access
Tom Evans wrote:
Have you heard of such and issue with the 3124-2/4276 combination?
Is anyone else trying this driver on an Alpha?
Alpha should not be operationally much different from other little
endian 64-bit platforms.
The PCI swizzle might be weird (what is your Alpha platform?), is
Thanks for the response Jeff !
Jeff Garzik wrote:
Alpha should not be operationally much different from other little
endian 64-bit platforms.
The PCI swizzle might be weird (what is your Alpha platform?), is the
only Alpha-specific thing that comes to mind.
I am using a DS20 (Tsunami /
24 matches
Mail list logo