This is at
http://zeniv.linux.org.uk/~alan/IDE
Some more fixes, and the ALi driver should now work although I've yet to
finish the MWDMA work or finish chasing down the slow performance.
[email protected] (Alan Cox) writes:
> Some more fixes, and the ALi driver should now work although I've yet to
> finish the MWDMA work or finish chasing down the slow performance.
What does your roadmap look like now? Will you feed these patches to Jeff
Garzik when 2.6.17 opens or will you wait to have most of the stuff you
labelled "core features" completed?
--
Mathieu Chouquet-Stringer
Hi,
Le Mon, 27 Feb 2006 15:32:50 +0000, Alan Cox a ?crit?:
> This is at
> http://zeniv.linux.org.uk/~alan/IDE
>
> Some more fixes, and the ALi driver should now work although I've yet to
> finish the MWDMA work or finish chasing down the slow performance.
Is there some hardware that need more testing than others ?
I have machines with
VIA + SIL680
PIIX + CMD648
PIXX
CMD640 + ISAPnp
But I am quite busy and can't test on all of them.
Matthieu
On Llu, 2006-02-27 at 18:55 +0100, Mathieu Chouquet-Stringer wrote:
> What does your roadmap look like now? Will you feed these patches to Jeff
> Garzik when 2.6.17 opens or will you wait to have most of the stuff you
> labelled "core features" completed?
On the whole I'd like to see the core and most of the drivers pushed to
2.6.17 as experimental and merged with the main tree. The DMA CRC
changedown work is important before it leaves "experimental" status.
Up to Jeff and I need to discuss it with him next week.
Alan
On Mon, Feb 27, 2006 at 03:32:50PM +0000, Alan Cox wrote:
> This is at
> http://zeniv.linux.org.uk/~alan/IDE
>
Got this working like a charm, although I had to add the promise 20269's
PCI IDs to ata_generic.c to make it tick. I only regard this as an
interim solution, but wanted to try out getting rid of IDE altogether.
So far it "feels" alright, using pata_via and ata_generic. Thanks a
bunch!
Regards,
Chris
Btw, here's the diff for convenience, in case of "interest":
--- a/drivers/scsi/ata_generic.c 2006-02-27 22:15:31.000000000 +0100
+++ b/drivers/scsi/ata_generic.c 2006-02-28 00:16:17.447430304 +0100
@@ -207,6 +207,7 @@
{ PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO), },
{ PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO_1), },
{ PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO_2), },
+ { PCI_DEVICE(PCI_VENDOR_ID_PROMISE,PCI_DEVICE_ID_PROMISE_20269), },
/* Must come last. If you add entries adjust this table appropriately */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE << 8, 0xFFFFFF00UL, 1},
{ 0, },
On Maw, 2006-02-28 at 01:30 +0100, Christian Trefzer wrote:
> On Mon, Feb 27, 2006 at 03:32:50PM +0000, Alan Cox wrote:
> > This is at
> > http://zeniv.linux.org.uk/~alan/IDE
> >
>
> Got this working like a charm, although I had to add the promise 20269's
> PCI IDs to ata_generic.c to make it tick. I only regard this as an
> interim solution, but wanted to try out getting rid of IDE altogether.
> So far it "feels" alright, using pata_via and ata_generic. Thanks a
> bunch!
Thanks for the report. The PDC20268 and 2027x are driven by Albert Lee's
Promise driver which should end up in the main tree soon, probably
before my PATA bits.
On Tue, Feb 28, 2006 at 09:49:49AM +0000, Alan Cox wrote:
>
> Thanks for the report. The PDC20268 and 2027x are driven by Albert Lee's
> Promise driver which should end up in the main tree soon, probably
> before my PATA bits.
>
That's weird, pata_pdc2027x.c is in the -rc5 tree, or at least after
applying your -ide1 patch, but the references in Kconfig and Makefile
are missing. Is this intentional? I'll try and scribble something up,
diff is about to follow.
Thanks for the pointer!
Chris
On Tue, Feb 28, 2006 at 09:49:49AM +0000, Alan Cox wrote:
> Thanks for the report. The PDC20268 and 2027x are driven by Albert Lee's
> Promise driver which should end up in the main tree soon, probably
> before my PATA bits.
>
And this patch activates the thing in Kconfig. Build tested already,
boot test is yet to come. Will report back in a few minutes - if I did
not entirely mess up my boot environment, that is.
Regards,
Chris
--- a/drivers/scsi/Kconfig 2006-02-28 04:01:31.000000000 +0100
+++ b/drivers/scsi/Kconfig 2006-02-28 11:10:18.959828288 +0100
@@ -823,6 +823,15 @@
If unsure, say N.
+config SCSI_PATA_PDC
+ tristate "Newer Promise PATA controller support (Raving Lunatic)"
+ depends on SCSI_SATA && PCI && EXPERIMENTAL
+ help
+ This option enables support for the Promise 20268 through 20277
+ adapters.
+
+ If unsure, say N.
+
config SCSI_PATA_QDI
tristate "QDI VLB PATA support"
depends on SCSI_SATA
--- a/drivers/scsi/Makefile 2006-02-28 04:01:31.000000000 +0100
+++ b/drivers/scsi/Makefile 2006-02-28 11:07:11.751066376 +0100
@@ -162,6 +162,7 @@
obj-$(CONFIG_SCSI_PATA_OPTI) += libata.o pata_opti.o
obj-$(CONFIG_SCSI_PATA_PCMCIA) += libata.o pata_pcmcia.o
obj-$(CONFIG_SCSI_PATA_PDC_OLD) += libata.o pata_pdc202xx_old.o
+obj-$(CONFIG_SCSI_PATA_PDC) += libata.o pata_pdc2027x.o
obj-$(CONFIG_SCSI_PATA_QDI) += libata.o pata_qdi.o
obj-$(CONFIG_SCSI_PATA_RADISYS) += libata.o pata_radisys.o
obj-$(CONFIG_SCSI_PATA_RZ1000) += libata.o pata_rz1000.o
Hi Alan,
the pata_pdc2027x driver works flawlessly AFAICT - the only weird thing about it would
be some duplicated init messages in dmesg:
pata_pdc2027x 0000:00:0c.0: version 0.73
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKD] -> GSI 3 (level, low) -> IRQ 3
pata_pdc2027x 0000:00:0c.0: PLL input clock 20020 kHz
ata3: PATA max UDMA/133 cmd 0xF08217C0 ctl 0xF0821FDA bmdma 0xF0821000 irq 3
ata4: PATA max UDMA/133 cmd 0xF08215C0 ctl 0xF0821DDA bmdma 0xF0821008 irq 3
ata3: dev 0 cfg 49:2f00 82:346b 83:7f01 84:4003 85:3c69 86:3e01 87:4003 88:407f
ata3: dev 0 ATA-7, max UDMA/133, 234493056 sectors: LBA48
ata3: dev 0 configured for UDMA/133
scsi2 : pata_pdc2027x
ata4: dev 0 cfg 49:2f00 82:346b 83:7f01 84:4003 85:3c69 86:3e01 87:4003 88:407f
ata4: dev 0 ATA-7, max UDMA/133, 234493056 sectors: LBA48
ata4: dev 0 configured for UDMA/133
scsi3 : pata_pdc2027x
Vendor: ATA Model: SAMSUNG SV1203N Rev: TQ10
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 234493056 512-byte hdwr sectors (120060 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 234493056 512-byte hdwr sectors (120060 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2
sd 2:0:0:0: Attached scsi disk sda
Vendor: ATA Model: SAMSUNG SV1203N Rev: TQ10
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdb: 234493056 512-byte hdwr sectors (120060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234493056 512-byte hdwr sectors (120060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2
sd 3:0:0:0: Attached scsi disk sdb
It appears to me that some part of drive detection is done twice - at
least the output is generated redundantly. If this is a bug and not a
feature, maybe one issue of the output could be trimmed in the end.
There have been rumours about some Promise controller having trouble
with UDMA6 and the Linux drivers, but I am running this configuration
for quite some time now and never had the slightest problem.
Thanks, everyone, for the good stuff : )
Chris
On Tue, Feb 28, 2006 at 11:41:23AM +0100, Christian Trefzer wrote:
> If this is a bug and not a feature,
^^^ ^^^^^^^
Please switch these. Damn, I really need to get some sleep - this is
_bad_ timing...
Sorry for the fuss,
Chris
Alan Cox <[email protected]> writes:
> On the whole I'd like to see the core and most of the drivers pushed to
> 2.6.17 as experimental and merged with the main tree. The DMA CRC
> changedown work is important before it leaves "experimental" status.
That would be nice.
BTW: with rc5 and patch-2.6.16-rc5-ide1.gz I get MWDMA2 (VIA EPIA-M,
I've sent you details with rc2-ide2 report):
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xE000 irq 14
via_do_set_mode: Mode=8 ast broken=Y udma=133 mul=4
ata1: dev 0 cfg 49:0b00 82:0210 83:4000 84:4000 85:0000 86:0000 87:4000 88:0407
ata1: dev 0 ATAPI, max UDMA/33
via_do_set_mode: Mode=8 ast broken=Y udma=133 mul=4
via_do_set_mode: Mode=12 ast broken=Y udma=133 mul=4
via_do_set_mode: Mode=34 ast broken=Y udma=133 mul=4
ata1: dev 0 configured for MWDMA2
scsi0 : pata_via
Vendor: LITE-ON Model: DVD SOHD-16P9SV Rev: F$01
Type: CD-ROM ANSI SCSI revision: 05
instead of UDMA/33 with patch-2.6.16-rc2-ide2.gz which does:
via_do_set_mode: Mode=12 ast broken=Y udma=133 mul=4
via_do_set_mode: Mode=66 ast broken=Y udma=133 mul=4
ata1: dev 0 configured for UDMA/33
"rmmod sr_mod" assertion warning is gone.
"rmmod pata_via" and then "modprobe pata_via" is still there:
ata3: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xE000 irq 14
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c01d0121
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: pata_via cdrom libata scsi_mod lirc_serial lirc_dev via_agp agpgart via_rhine
CPU: 0
EIP: 0060:[<c01d0121>] Not tainted VLI
EFLAGS: 00010206 (2.6.16-rc5-term-via #29)
EIP is at make_class_name+0x31/0xb0
eax: 00000000 ebx: ffffffff ecx: ffffffff edx: 00000000
esi: 00000009 edi: 00000000 ebp: 00000000 esp: c6f83ca8
ds: 007b es: 007b ss: 0068
Process insmod (pid: 382, threadinfo=c6f83000 task=c6165a30)
Stack: <0>00000044 c618f1f0 000200d0 c02a8680 00000010 c10a9fa0 c6f83000 c7926204
c618f1f0 c7926204 c792620c c01d0226 c79261a0 00000000 00000246 c618f1f0
c618f000 c618f028 c618f280 c01d02e8 c618f0d0 c790edcd c618f280 00000000
Call Trace:
[<c01d0226>] class_device_del+0x86/0x140
[<c01d02e8>] class_device_unregister+0x8/0x10
[<c790edcd>] scsi_remove_host+0x7d/0xc0 [scsi_mod]
[<c78fb99e>] ata_host_remove+0xe/0x20 [libata]
[<c78ff40d>] ata_device_add+0x2fd/0xb80 [libata]
[<c021a02f>] pci_read+0x1f/0x30
[<c02188f9>] pcibios_set_master+0x19/0xa0
[<c78fffe4>] ata_pci_init_one+0x354/0x390 [libata]
[<c01cf860>] __driver_attach+0x0/0x60
[<c01cf860>] __driver_attach+0x0/0x60
[<c78ef688>] via_init_one+0x138/0x2a0 [pata_via]
[<c018995b>] pci_device_probe+0x4b/0x70
[<c01cf778>] driver_probe_device+0x38/0xb0
[<c01cf8ba>] __driver_attach+0x5a/0x60
[<c01ceda8>] bus_for_each_dev+0x38/0x70
[<c01cf651>] driver_attach+0x11/0x20
[<c01cf860>] __driver_attach+0x0/0x60
[<c01cf0da>] bus_add_driver+0x6a/0x130
[<c01cfbd0>] klist_devices_get+0x0/0x10
[<c018953e>] __pci_register_driver+0x4e/0x90
[<c01292df>] sys_init_module+0x12f/0x1690
[<c0138e0e>] __handle_mm_fault+0x3ce/0x570
[<c010e2c0>] do_page_fault+0x210/0x5fa
[<c0102889>] syscall_call+0x7/0xb
Code: 1c 89 44 24 04 8b 40 3c 8b 10 31 ed bb ff ff ff ff 89 d9 89 d7 89 e8 f2 ae f7 d1 49 89 ce 8b 44 24 04 8b 50 08 89 d9 89 d7 89 e8 <f2> ae f7 d1 49 8d 44 0e 02 ba d0 00 00 00 e8 cc f5 f6 ff 89 04
Of course additional details are available on request.
Thanks,
--
Krzysztof Halasa
On Maw, 2006-02-28 at 13:12 +0100, Krzysztof Halasa wrote:
> "rmmod pata_via" and then "modprobe pata_via" is still there:
>
> ata3: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xE000 irq 14
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
This appears to be a bug in the libata core code. I can duplicate it
with a NULL driver that simply fakes no devices attached. It definitely
needs looking at but I don't think its PATA caused at this moment. Of
course I may yet be wrong 8)
Alan
On Maw, 2006-02-28 at 13:12 +0100, Krzysztof Halasa wrote:
> BTW: with rc5 and patch-2.6.16-rc5-ide1.gz I get MWDMA2 (VIA EPIA-M,
> I've sent you details with rc2-ide2 report):
Fixed in my tree. Thanks for noticing that.
Alan
On Monday 27 February 2006 16:32, Alan Cox wrote:
> This is at
> http://zeniv.linux.org.uk/~alan/IDE
>
> Some more fixes, and the ALi driver should now work although I've yet to
> finish the MWDMA work or finish chasing down the slow performance.
>
Hello Alan,
on ALi here devices are now recognized successfully. Some excerpts from the
logs:
libata version 1.20 loaded.
ACPI: PCI Interrupt 0000:00:10.0[A]: no GSI
ata1: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x2040 irq 14
ata1: dev 0 cfg 49:0f00 82:746b 83:7fe8 84:4023 85:f469 86:3e48 87:4023
88:203f
ata1: dev 0 ATA-6, max UDMA/100, 78140160 sectors: LBA48
ata1: dev 0 configured for UDMA/100
scsi0 : ali
Vendor: ATA Model: IC25N040ATMR04-0 Rev: MO2O
Type: Direct-Access ANSI SCSI revision: 05
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x2048 irq 15
ata2: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000
88:0000
ata2: dev 0 ATAPI, max MWDMA2
ata2: dev 0 configured for PIO4
scsi1 : ali
Vendor: HL-DT-ST Model: RW/DVD GCC-4241N Rev: 0C29
Type: CD-ROM ANSI SCSI revision: 05
SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 < sda5 sda6 > sda4
sd 0:0:0:0: Attached scsi disk sda
sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
The improvement from the previous patch is that the cdrom is seen as "sr0" now
(instead of "sdb") and the bogus warnings have disappeared. Performances are
still low, as expected. Please tell me if I can do something else.
Thanks and regards,
Francesco
--
Dr. Francesco Biscani
Dipartimento di Astronomia
Universit? di Padova
[email protected]
I don't know if this is to be expected, but blanking of a cdrw fails here.
Output of cdrecord is:
Cdrecord-Clone 2.01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J�g Schilling
cdrecord: Warning: Running on Linux-2.6.16-rc5-morph1
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
scsidev: '/dev/sr0'
devname: '/dev/sr0'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'HL-DT-ST'
Identifikation : 'RW/DVD GCC-4241N'
Revision : '0C29'
Device seems to be: Generic mmc2 DVD-ROM.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
cdrecord: Input/output error. test unit ready: scsi sendcmd: no error
CDB: 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00
Sense Key: 0x2 Not Ready, Segment 0
Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.008s timeout 40s
cdrecord: No disk / Wrong disk
Regards,
Francesco
--
Dr. Francesco Biscani
Dipartimento di Astronomia
Università di Padova
[email protected]
Christian Trefzer wrote:
> It appears to me that some part of drive detection is done twice - at
> least the output is generated redundantly. If this is a bug and not a
> feature, maybe one issue of the output could be trimmed in the end.
That was a long standing bug (or feature in some twisted sense) of
SCSI midlayer. I think it's gone now.
> There have been rumours about some Promise controller having trouble
> with UDMA6 and the Linux drivers, but I am running this configuration
> for quite some time now and never had the slightest problem.
Looks like you're running quite old kernel.
--
tejun
Hi Tejun,
On Tue, Oct 14, 2008 at 10:28:20AM +0900, Tejun Heo wrote:
> Looks like you're running quite old kernel.
Not for some time now, it appears some ancient email might have popped
up on top. My outbox archive says it went out on
Tue, 28 Feb 2006 11:41:23 +0100.
--
Kind regards,
Chris
Christian Trefzer wrote:
> Hi Tejun,
>
> On Tue, Oct 14, 2008 at 10:28:20AM +0900, Tejun Heo wrote:
>> Looks like you're running quite old kernel.
>
> Not for some time now, it appears some ancient email might have popped
> up on top. My outbox archive says it went out on
> Tue, 28 Feb 2006 11:41:23 +0100.
Aieee... I just rebuilt the INBOX index and thunderbird thought it would
be fun to mark a mail from 2006. Sorry about the noise. :-)
--
tejun