[PATCH 2.6.23-rc4] sata_promise: FastTrack TX4200 is a second-generation chip

2007-08-29 Thread Mikael Pettersson
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

Re: [PATCH] Prefix each line of multiline printk(KERN_level foo\nbar) with KERN_level

2007-08-29 Thread Maciej W. Rozycki
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

[1/2] 2.6.23-rc3: known regressions with patches

2007-08-29 Thread Michal Piotrowski
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

hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }

2007-08-29 Thread John Sigler
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

Re: hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }

2007-08-29 Thread Alan Cox
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

HSM violation spew.

2007-08-29 Thread Dave Jones
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

Re: HSM violation spew.

2007-08-29 Thread Dave Jones
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

[PATCH 1/10] ide: use pci_dev-revision

2007-08-29 Thread Bartlomiej Zolnierkiewicz
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

[PATCH 2/10] ide: use I/O ops directly part #2

2007-08-29 Thread Bartlomiej Zolnierkiewicz
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

[PATCH 3/10] aec62xx: remove -init_setup

2007-08-29 Thread Bartlomiej Zolnierkiewicz
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

[PATCH 4/10] cmd64x: remove -init_setup

2007-08-29 Thread Bartlomiej Zolnierkiewicz
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:

[PATCH 6/10] pdc202xx_new: remove -init_setup

2007-08-29 Thread Bartlomiej Zolnierkiewicz
* 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]

[PATCH 5/10] hpt366: remove -init_setup

2007-08-29 Thread Bartlomiej Zolnierkiewicz
* 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

[PATCH 7/10] pdc202xx_old: remove -init_setup

2007-08-29 Thread Bartlomiej Zolnierkiewicz
* 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 +

[PATCH 9/10] serverworks: remove -init_setup

2007-08-29 Thread Bartlomiej Zolnierkiewicz
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 |

[PATCH 10/10] ide: remove .init_setup from ide_pci_device_t

2007-08-29 Thread Bartlomiej Zolnierkiewicz
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 === ---

Re: [PATCH 1/10] ide: use pci_dev-revision

2007-08-29 Thread Kok, Auke
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

Re: [PATCH 1/10] ide: use pci_dev-revision

2007-08-29 Thread Bartlomiej Zolnierkiewicz
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

ATAPI tape drives broken with libata

2007-08-29 Thread Chuck Ebbert
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

Re: ATAPI tape drives broken with libata

2007-08-29 Thread Alan Cox
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

Port Multiplier Patch 2.6.22.1 on Alpha

2007-08-29 Thread Tom Evans
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

Re: ATAPI tape drives broken with libata

2007-08-29 Thread Jeff Garzik
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

Re: Port Multiplier Patch 2.6.22.1 on Alpha

2007-08-29 Thread Jeff Garzik
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

Re: Port Multiplier Patch 2.6.22.1 on Alpha

2007-08-29 Thread Tom Evans
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 /