Testing CAM wrapper for ata(4) controller drivers
Alexander Motin
I would like to present for testing patch, turning ata(4) controllers
drivers into native SIMs of new CAM ATA infrastructure. This patch adds
new ATA_CAM kernel option, which allows switching between legacy and new
CAM-based operation modes. To enable new mode you should add
options ATA_CAM
line to the kernel configuration file in addition to the ones required
by CAM infrastructure and rebuild/reinstall the kernel.
In legacy mode, the only difference will be - the way in which SATA
speeds reported. Instead of mixing SATA revisions with PATA modes, they
were separated, as they should be, allowing, for example, DMA-incapable
or buggy SATA devices (usually PATA devices with built-in PATA/SATA
converter) to work in PIO mode.
While doing it, I had to completely rewrite ata(4) mode setting code, so
legacy operation also need to be tested. I have successfully tested it
on Intel, NVidia, VIA, Marvell, JMicron PATA controllers with all
PIO/DMA modes. Different controllers feedbacks are especially welcome.
In new mode, everything becomes different. atacontrol tool will not
report ATA buses any more. All management should be done via camcontrol
tool now. atadisk, ataraid, atapicd, atapifd, atapist and atapicam
kernel options and respective code are useless now. Instead of ad, acd,
afd, ast devices you'll get ada, cd, da, sa.
The main regression of the new mode is a lack of ataraid alternative, to
support cheap BIOS-based ATA RAIDs. If somebody has time and wish to
port that code from inside ata(4) into GEOM module, to make it work over
CAM also, I would appreciate that and propose a help, if needed.
In new mode some tools, like burncd, using legacy ata(4) interfaces
(acd), are no longer applicable and should be replaced by alternatives,
working via SCSI interfaces (cd). SMART support for new mode implemented
in smartmontools SVN, and will be present in next release.
New mode at this moment won't give much benefits to the old controllers,
not supported by new ahci(4) and siis(4) drivers, may be just more fair
scheduling for PATA devices sharing cable. But it is required step to
unify infrastructure. After this step will be done, it will be possible
to improve functionality, where it is supported by hardware. Until that
time it would require too much extra work to keep compatibility with
both world.
Present patch can be found here:
http://people.freebsd.org/~mav/ata-wrap.20091202.patch
It applies to both recent HEAD and 8-STABLE. To work in new mode on
8-STABLE it requires recent SVN revision 200008 to be merged from HEAD.
Respective patch for now could be found here:
http://people.freebsd.org/~mav/r200008.patch
Feedbacks are welcome. On any problems, don't forget to enable verbose
kernel debug messages to obtain more information.
--
Alexander Motin
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Gary Jennejohn
Alexander Motin <m...@FreeBSD.org> wrote:
> While doing it, I had to completely rewrite ata(4) mode setting code, so
> legacy operation also need to be tested. I have successfully tested it
> on Intel, NVidia, VIA, Marvell, JMicron PATA controllers with all
> PIO/DMA modes. Different controllers feedbacks are especially welcome.
>
Works for me with this (non-legacy) controller
ahci0: <ATI IXP700 AHCI SATA controller> port
0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f
mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0
The only difference I see is
[old]
cd0: <HL-DT-ST DVD-RAM GSA-H54N 1.00> Removable CD-ROM SCSI-0 device
cd0: 66.000MB/s transfers
[new]
cd0: <HL-DT-ST DVD-RAM GSA-H54N 1.00> Removable CD-ROM SCSI-0 device
cd0: 66.700MB/s transfers (UDMA4, PIO size 8192bytes)
and the fact that /dev/acd* has disappeared.
---
Gary Jennejohn
Alexander Best
FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r200046M: Wed Dec 2 22:53:25
CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL amd64
ahci0: <JMicron JMB363 AHCI SATA controller> mem 0xf8000000-0xf8001fff irq 19
at device 0.0 on pci3
ahci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xf8000000
ahci0: [MPSAFE]
ahci0: [ITHREAD]
ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
ahci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports
ahci1: <Intel ICH9 AHCI SATA controller> port
0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem
0xf8206000-0xf82067ff irq 19 at device 31.2 on pci0
ahci1: Reserved 0x800 bytes for rid 0x24 type 3 at 0xf8206000
ahci1: attempting to allocate 1 MSI vectors (16 supported)
ahci1: using IRQ 257 for MSI
ahci1: [MPSAFE]
ahci1: [ITHREAD]
ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported
ahci1: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC EM
6ports
ahci1: Caps2:
(aprobe2:ata2:0:0:0): SIGNATURE: 0000
(aprobe3:ahcich2:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich2:0:0:0): SIGNATURE: 0000
(aprobe1:ata2:0:1:0): SIGNATURE: eb14
ada0 at ata2 bus 0 scbus2 target 0 lun 0
ada0: <HDS722516VLAT80 V34OA63A> ATA/ATAPI-6 device
ada0: Serial Number VNR43EC4GYNGAM
ada0: 100.000MB/s transfers (UDMA5, PIO size 8192bytes)
ada0: 157066MB (321672960 512 byte sectors: 16H 63S/T 16383C)
ada1 at ahcich2 bus 0 scbus3 target 0 lun 0
ada1: <SAMSUNG SP2504C VT100-50> ATA/ATAPI-7 SATA 2.x device
ada1: Serial Number S09QJ1GLB35451
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
ada1: Command Queueing enabled
ada1: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C)
ata2: reset tp1 mask=03 ostat0=50 ostat1=51
ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata2: reset tp2 stat0=50 stat1=00 devices=0x20001
(cd0:ata2:0:1:0): Command timed out
(cd0:ata2:0:1:0): Retrying Command
cd0 at ata2 bus 0 scbus2 target 1 lun 0
cd0: <HL-DT-ST DVDRAM GSA-H10N JL12> Removable CD-ROM SCSI-0 device
cd0: Serial Number 788B80B2769C
cd0: 33.300MB/s transfers (UDMA2, PIO size 8192bytes)
cd0: cd present [2292640 x 2048 byte records]
the dvd-drive is running with DMA disables and is also causing error messages
with ATA. i think this is a problem in the jmicron driver (see kern/133122).
cheers.
alex
Alexander Kabaev
Alexander Motin <m...@FreeBSD.org> wrote:
> Hi.
>
> I would like to present for testing patch, turning ata(4) controllers
> drivers into native SIMs of new CAM ATA infrastructure. This patch
> adds new ATA_CAM kernel option, which allows switching between legacy
> and new CAM-based operation modes. <SKIP>
Works on AMD8111 here <apologies for line wrapping>:
atapci0: <AMD 8111 UDMA133 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
(aprobe0:ata0:0:0:0): SIGNATURE: 0000
(aprobe1:ata1:0:0:0): SIGNATURE: eb14
(aprobe0:ata1:0:1:0): SIGNATURE: 0000
cd0 at ata1 bus 0 scbus1 target 0 lun 0
cd0: <IDE DVD-ROM 16X 7.50> Removable CD-ROM SCSI-0 device
cd0: 33.300MB/s transfers (UDMA2, PIO size 8192bytes)
cd0: Attempt to query device size failed: UNIT ATTENTION, Power on,
reset, or bus device reset occurred
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: <Maxtor 6Y160P0 YAR41BW0> ATA/ATAPI-7 device
ada0: 133.000MB/s transfers (UDMA6, PIO size 8192bytes)
ada0: 156334MB (320173056 512 byte sectors: 16H 63S/T 16383C)
ada1 at ata1 bus 0 scbus1 target 1 lun 0
ada1: <IBM-DTLA-307030 TX4OA50C> ATA/ATAPI-5 device
ada1: 100.000MB/s transfers (UDMA5, PIO size 8192bytes)
ada1: 29314MB (60036480 512 byte sectors: 16H 63S/T 16383C)
--
Alexander Kabaev
Goran Lowkrantz
<m...@FreeBSD.org> wrote:
> Hi.
>
> I would like to present for testing patch, turning ata(4) controllers
> drivers into native SIMs of new CAM ATA infrastructure. This patch adds
> new ATA_CAM kernel option, which allows switching between legacy and new
> CAM-based operation modes. To enable new mode you should add
> options ATA_CAM
> line to the kernel configuration file in addition to the ones required
> by CAM infrastructure and rebuild/reinstall the kernel.
>
===
Tested on a ASUSTeK M2N-VM DVI with good results. Only problem found was
with a CF card in a SATA-CF adapter. It lies that it can handle DMA but
fails miserably. Searched the web but could find no way to disable DMA when
using CAM-ATA.
Here is the inital rescan result after attaching it and the timeout when
doing an identify:
(aprobe0:ahcich1:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich2:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich1:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich2:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich0:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich0:0:0:0): SIGNATURE: 0000
ada2 at ahcich0 bus 0 scbus2 target 0 lun 0
ada2: <SanDisk SDCFX-1024 HDX 3.17> ATA/ATAPI-4 device
ada2: 150.000MB/s transfers (SATA 1.x, PIO4, PIO size 2048bytes)
ada2: 977MB (2001888 512 byte sectors: 16H 63S/T 1986C)
(aprobe0:ahcich1:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich2:0:15:0): SIGNATURE: 0000
ahcich0: Timeout on slot 0
ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd d0 serr
00000000
ahcich0: port is not ready (timeout 10000ms) tfd = 00000080
ahcich0: device ready timeout
ahcich0: Timeout on slot 0
ahcich0: is 00000000 cs 00000003 ss 00000000 rs 00000003 tfd 00 serr 000000
# camcontrol readcap ada2
(pass5:ahcich0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0
(pass5:ahcich0:0:0:0): CAM Status: Unconditionally Re-queue Request
When mounted and trying to write atime this happens:
g_vfs_done():ada2a[WRITE(offset=114688, length=16384)]error = 5
ahcich0: Timeout on slot 0
ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 80 serr
00000000
ahcich0: port is not ready (timeout 10000ms) tfd = 00000080
ahcich0: device ready timeout
ahcich0: Timeout on slot 0
ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 80 serr
00000000
ahcich0: port is not ready (timeout 10000ms) tfd = 00000080
ahcich0: device ready timeout
ahcich0: Timeout on slot 0
ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 80 serr
00000000
ahcich0: port is not ready (timeout 10000ms) tfd = 00000080
ahcich0: device ready timeout
ahcich0: Timeout on slot 0
ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 80 serr
00000000
ahcich0: port is not ready (timeout 10000ms) tfd = 00000080
ahcich0: device ready timeout
ahcich0: Timeout on slot 0
ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 80 serr
00000000
ahcich0: port is not ready (timeout 10000ms) tfd = 00000080
ahcich0: device ready timeout
g_vfs_done():ada2a[WRITE(offset=114688, length=16384)]error = 5
fsync: giving up on dirty
0xffffff00068e9760: tag devfs, type VCHR
usecount 1, writecount 0, refcount 5 mountedhere 0xffffff0006bff600
flags ()
v_object 0xffffff0004e40438 ref 0 pages 6
lock type devfs: EXCL by thread 0xffffff0006389390 (pid 1946)
dev ada2a
ahcich0: Timeout on slot 0
Rest of it:
atapci0@pci0:0:6:0: class=0x01018a card=0x82b31043 chip=0x056010de
rev=0xa1 hdr=0x00
vendor = 'Nvidia Corp'
device = 'MCP67 PATA Controller (MCP67)'
class = mass storage
subclass = ATA
ahci0@pci0:0:9:0: class=0x010601 card=0x82b31043 chip=0x055410de
rev=0xa2 hdr=0x00
vendor = 'Nvidia Corp'
device = 'MCP67 AHCI Controller'
class = mass storage
subclass = SATA
# camcontrol devlist
<DVD-16X DVD1648/BKH A001> at scbus0 target 0 lun 0 (cd0,pass0)
<LITE-ON DVDRW SOHW-1653S CS09> at scbus0 target 1 lun 0 (cd1,pass1)
<SanDisk SDCFX-1024 HDX 3.17> at scbus2 target 0 lun 0 (ada2,pass5)
<ST380815AS 3.AAD> at scbus3 target 0 lun 0 (pass2,ada0)
<ST380815AS 3.AAD> at scbus4 target 0 lun 0 (pass3,ada1)
<Kingston DataTraveler G2 PMAP> at scbus6 target 0 lun 0 (da0,pass4)
# camcontrol identify ada0
pass2: <ST380815AS 3.AAD> ATA/ATAPI-7 SATA 2.x device
pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
protocol ATA/ATAPI-7 SATA 2.x
device model ST380815AS
firmware revision 3.AAD
serial number 5QZ2XRWG
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 512, offset 0
LBA supported 156301488 sectors
LBA48 supported 156301488 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
overlap not supported
Feature Support Enable Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
Native Command Queuing (NCQ) yes 31/0x1F
Tagged Command Queuing (TCQ) no no 31/0x1F
SMART yes yes
microcode download yes yes
security yes no
power management yes yes
advanced power management no no 65278/0xFEFE
automatic acoustic management no no 0/0x00 208/0xD0
media status notification no no
power-up in Standby no no
write-read-verify yes no 0/0x0
unload no no
free-fall no no
# camcontrol identify ada1
pass3: <ST380815AS 3.AAD> ATA/ATAPI-7 SATA 2.x device
pass3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
protocol ATA/ATAPI-7 SATA 2.x
device model ST380815AS
firmware revision 3.AAD
serial number 5QZ2XRWZ
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 512, offset 0
LBA supported 156301488 sectors
LBA48 supported 156301488 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
overlap not supported
Feature Support Enable Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
Native Command Queuing (NCQ) yes 31/0x1F
Tagged Command Queuing (TCQ) no no 31/0x1F
SMART yes yes
microcode download yes yes
security yes no
power management yes yes
advanced power management no no 65278/0xFEFE
automatic acoustic management no no 0/0x00 208/0xD0
media status notification no no
power-up in Standby no no
write-read-verify yes no 0/0x0
unload no no
free-fall no no
Boot dmesg:
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-STABLE #71: Wed Dec 2 22:26:06 CET 2009
ro...@skade.glz.hidden-powers.com:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2600.26-MHz K8-class
CPU)
Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
Features2=0x2001<SSE3,CX16>
AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
AMD Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch>
TSC: P-state invariant
real memory = 4294967296 (4096 MB)
avail memory = 4105179136 (3915 MB)
ACPI APIC Table: <082708 APIC1437>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
ioapic0 <Version 1.1> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <082708 XSDT1437> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of fefe1000, 1000 (3) failed
acpi0: reservation of fee01000, ff000 (3) failed
acpi0: reservation of fec00000, 1000 (3) failed
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
acpi0
Timecounter "HPET" frequency 25000000 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: <memory, RAM> at device 0.0 (no driver attached)
isab0: <PCI-ISA bridge> port 0x900-0x9ff at device 1.0 on pci0
isa0: <ISA bus> on isab0
pci0: <serial bus, SMBus> at device 1.1 (no driver attached)
ohci0: <OHCI (generic) USB controller> mem 0xf9eff000-0xf9efffff irq 21 at
device 2.0 on pci0
ohci0: [ITHREAD]
usbus0: <OHCI (generic) USB controller> on ohci0
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xf9efec00-0xf9efecff irq 22
at device 2.1 on pci0
ehci0: [ITHREAD]
usbus1: EHCI version 1.0
usbus1: <EHCI (generic) USB 2.0 controller> on ehci0
ohci1: <OHCI (generic) USB controller> mem 0xf9efd000-0xf9efdfff irq 23 at
device 4.0 on pci0
ohci1: [ITHREAD]
usbus2: <OHCI (generic) USB controller> on ohci1
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xf9efe800-0xf9efe8ff irq 20
at device 4.1 on pci0
ehci1: [ITHREAD]
usbus3: EHCI version 1.0
usbus3: <EHCI (generic) USB 2.0 controller> on ehci1
atapci0: <nVidia nForce MCP67 UDMA133 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <multimedia, HDA> at device 7.0 (no driver attached)
pcib1: <ACPI PCI-PCI bridge> at device 8.0 on pci0
pci1: <ACPI PCI bus> on pcib1
fwohci0: <VIA Fire II (VT6306)> port 0xcc00-0xcc7f mem
0xf9fff800-0xf9ffffff irq 16 at device 7.0 on pci1
fwohci0: [ITHREAD]
fwohci0: OHCI version 1.0 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 20:00:00:00:03:00:0a:a6
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0x2584000
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 22:00:00:00:0a:a6
fwe0: Ethernet address: 22:00:00:00:0a:a6
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 20:00:00:00:03:00:0a:a6 @ 0xfffe00000000, S400,
maxrec 2048
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER
mode
ahci0: <NVIDIA MCP67 AHCI SATA controller> port
0xb480-0xb487,0xb400-0xb403,0xb080-0xb087,0xb000-0xb003,0xac00-0xac0f mem
0xf9ef6000-0xf9ef7fff irq 22 at device 9.0 on pci0
ahci0: [ITHREAD]
ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich0: [ITHREAD]
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich1: [ITHREAD]
ahcich2: <AHCI channel> at channel 2 on ahci0
ahcich2: [ITHREAD]
ahcich3: <AHCI channel> at channel 3 on ahci0
ahcich3: [ITHREAD]
nfe0: <NVIDIA nForce MCP67 Networking Adapter> port 0xa880-0xa887 mem
0xf9efc000-0xf9efcfff,0xf9efe400-0xf9efe4ff,0xf9efe000-0xf9efe00f irq 23 at
device 10.0 on pci0
miibus0: <MII bus> on nfe0
atphy0: <Atheros F1 10/100/1000 PHY> PHY 1 on miibus0
atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
nfe0: Ethernet address: 00:1d:60:9a:8f:4e
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
pcib2: <ACPI PCI-PCI bridge> at device 11.0 on pci0
pci2: <ACPI PCI bus> on pcib2
vgapci0: <VGA-compatible display> port 0xdc00-0xdc7f mem
0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq 17 at
device 0.0 on pci2
pcib3: <ACPI PCI-PCI bridge> at device 12.0 on pci0
pci3: <ACPI PCI bus> on pcib3
em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port 0xec00-0xec1f mem
0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 18 at device 0.0 on pci3
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:1b:21:2e:7d:3c
pcib4: <PCI-PCI bridge> at device 13.0 on pci0
pci4: <PCI bus> on pcib4
pcib5: <PCI-PCI bridge> at device 14.0 on pci0
pci5: <PCI bus> on pcib5
pcib6: <PCI-PCI bridge> at device 15.0 on pci0
pci6: <PCI bus> on pcib6
pcib7: <PCI-PCI bridge> at device 16.0 on pci0
pci7: <PCI bus> on pcib7
pcib8: <PCI-PCI bridge> at device 17.0 on pci0
pci8: <PCI bus> on pcib8
amdtemp0: <AMD K8 Thermal Sensors> on hostb3
acpi_button0: <Power Button> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71 on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
cpu0: <ACPI CPU> on acpi0
powernow0: <PowerNow! K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <PowerNow! K8> on cpu1
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
ppc0: cannot reserve I/O port range
ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is
present;
to enable, add "vfs.zfs.prefetch_disable=0" to
/boot/loader.conf.
ZFS filesystem version 13
ZFS storage pool version 13
Timecounters tick every 1.000 msec
Waiting 5 seconds for SCSI devices to settle
firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me)
firewire0: bus manager 0
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 480Mbps High Speed USB v2.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 480Mbps High Speed USB v2.0
ugen0.1: <nVidia> at usbus0
uhub0: <nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <nVidia> at usbus1
uhub1: <nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
ugen2.1: <nVidia> at usbus2
uhub2: <nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
ugen3.1: <nVidia> at usbus3
uhub3: <nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3
uhub0: 6 ports with 6 removable, self powered
uhub2: 6 ports with 6 removable, self powered
uhub1: 6 ports with 6 removable, self powered
uhub3: 6 ports with 6 removable, self powered
ugen3.2: <vendor 0x0424> at usbus3
uhub4: <vendor 0x0424 product 0x2524, class 9/0, rev 2.00/0.00, addr 2> on
usbus3
ugen1.2: <Kingston> at usbus1
umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/1.10, addr 2> on
usbus1
umass0: SCSI over Bulk-Only; quirks = 0x0000
uhub4: 4 ports with 2 removable, self powered
umass0:6:0:-1: Attached to scbus6
(aprobe0:ata0:0:0:0): SIGNATURE: eb14
(aprobe0:ata0:0:1:0): SIGNATURE: eb14
(aprobe3:ahcich1:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich1:0:0:0): SIGNATURE: 0000
(aprobe4:ahcich2:0:15:0): SIGNATURE: 0000
(aprobe0:ahcich2:0:0:0): SIGNATURE: 0000
ada0 at ahcich1 bus 0 scbus3 target 0 lun 0
ada0: <ST380815AS 3.AAD> ATA/ATAPI-7 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
ada0: Command Queueing enabled
ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C)
ada1 at ahcich2 bus 0 scbus4 target 0 lun 0
ada1: <ST380815AS 3.AAD> ATA/ATAPI-7 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
ada1: Command Queueing enabled
ada1: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C)
cd0 at ata0 bus 0 scbus0 target 0 lun 0
cd0: <DVD-16X DVD1648/BKH A001> Removable CD-ROM SCSI-0 device
cd0: 33.300MB/s transfers (UDMA2, PIO size 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <Kingston DataTraveler G2 PMAP> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 15320MB (31375360 512 byte sectors: 255H 63S/T 1953C)
cd1 at ata0 bus 0 scbus0 target 1 lun 0
cd1: <LITE-ON DVDRW SOHW-1653S CS09> Removable CD-ROM SCSI-0 device
cd1: 66.700MB/s transfers (UDMA4, PIO size 8192bytes)
cd1: Attempt to query device size failed: NOT READY, Medium not present
SMP: AP CPU #1 Launched!
ugen3.3: <Belkin Corporation> at usbus3
uhid0: <Flip CC Device> on usbus3
(da0:umass-sim0:0:0:0): unsupportable block size 83886080
Root mount waiting for: usbus3
ugen3.4: <Tablet> at usbus3
ums0: <Tablet XD-0608-U, class 0/0, rev 1.10/1.26, addr 4> on usbus3
ums0: 3 buttons and [XYZ] coordinates ID=1
Root mount waiting for: usbus3
ugen3.5: <vendor 0x046d> at usbus3
ukbd0: <vendor 0x046d product 0xc30e, class 0/0, rev 1.10/1.80, addr 5> on
usbus3
kbd2 at ukbd0
uhid1: <vendor 0x046d product 0xc30e, class 0/0, rev 1.10/1.80, addr 5> on
usbus3
Trying to mount root from zfs:system
Thanks.
/glz
---
"There is hopeful symbolism in the fact that flags do not wave in a vacuum."
-- Arthur C. Clarke
Stefan Bethke
> Feedbacks are welcome. On any problems, don't forget to enable verbose
> kernel debug messages to obtain more information.
Working fine in VMware:
atapci0: <Intel ATA controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x10c0-
0x10cf at device 7.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
..
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: <VMware Virtual IDE Hard Drive 00000001> ATA/ATAPI-4 device
ada0: 33.300MB/s transfers (UDMA2, PIO size 8192bytes)
ada0: 20480MB (41943040 512 byte sectors: 15H 63S/T 16383C)
cd0 at ata1 bus 0 scbus1 target 0 lun 0
cd0: <NECVMWar VMware IDE CDR10 1.00> Removable CD-ROM SCSI-0 device
cd0: 33.300MB/s transfers (UDMA2, PIO size 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
Copied a bunch of data between my regular mpt hosted disk and this one, as well as the cd, and eveything seems to be working just fine. I did not test performance, but I did not notice any problems.
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
Alexander Motin
> Tested on a ASUSTeK M2N-VM DVI with good results. Only problem found was
> with a CF card in a SATA-CF adapter. It lies that it can handle DMA but
> fails miserably. Searched the web but could find no way to disable DMA
> when using CAM-ATA.
I have also seen problems with DMA on SATA-CF adapters. What's
interesting is that same cards in PATA-CF adapter are working fine. Will
try them more.
Generally modes can be controlled via `camcontrol negotiate ...`.
To change SATA connection speed (in addition to driver hints) you may do:
camcontrol negotiate ada0 -U -R 1500
camcontrol reset X
camcontrol rescan X
camcontrol negotiate ada0
To change PATA mode you may do now:
camcontrol negotiate ada0 -U -M WDMA0
camcontrol rescan X
camcontrol negotiate ada0
But now it is impossible to switch between PIO and DMA PATA modes after
device was probed. This part is to be implemented yet.
> Here is the inital rescan result after attaching it and the timeout when
> doing an identify:
> (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000
> ada2 at ahcich0 bus 0 scbus2 target 0 lun 0
> ada2: <SanDisk SDCFX-1024 HDX 3.17> ATA/ATAPI-4 device
> ada2: 150.000MB/s transfers (SATA 1.x, PIO4, PIO size 2048bytes)
It reported itself as working in PIO mode ^^^. It is some different case.
> ada2: 977MB (2001888 512 byte sectors: 16H 63S/T 1986C)
> (aprobe0:ahcich1:0:15:0): SIGNATURE: 0000
> (aprobe0:ahcich2:0:15:0): SIGNATURE: 0000
> ahcich0: Timeout on slot 0
> ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd d0 serr
> 00000000
Looks like card doesn't dropped BUSY flag (tfd d0). Or SATA adapter
haven't translated it properly.
> # camcontrol readcap ada2
> (pass5:ahcich0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0
> (pass5:ahcich0:0:0:0): CAM Status: Unconditionally Re-queue Request
readcap uses SCSI command to read capacity. It won't work for ATA
devices, only for ATAPI.
Thanks.
--
Alexander Motin
Alexander Best
not able to access any other cam members (ada* e.g.).
when i issue the following command:
`cdrecord dev=2,1,0 blank=all'
binaries such as ls, top or vmstat simply stall until cdrecord finishes.
this is the output of `camcontrol devlist -v':
scbus0 on ahcich0 bus 0:
<> at scbus0 target -1 lun -1 ()
scbus1 on ahcich1 bus 0:
<> at scbus1 target -1 lun -1 ()
scbus2 on ata2 bus 0:
<HDS722516VLAT80 V34OA63A> at scbus2 target 0 lun 0 (ada0,pass0)
<HL-DT-ST DVDRAM GSA-H10N JL12> at scbus2 target 1 lun 0 (pass1,cd0)
<> at scbus2 target -1 lun -1 ()
scbus3 on ahcich2 bus 0:
<SAMSUNG SP2504C VT100-50> at scbus3 target 0 lun 0 (ada1,pass2)
<> at scbus3 target -1 lun -1 ()
scbus4 on ahcich3 bus 0:
<> at scbus4 target -1 lun -1 ()
scbus5 on ahcich4 bus 0:
<> at scbus5 target -1 lun -1 ()
scbus6 on ahcich5 bus 0:
<> at scbus6 target -1 lun -1 ()
scbus7 on ahcich6 bus 0:
<> at scbus7 target -1 lun -1 ()
scbus8 on ahcich7 bus 0:
<> at scbus8 target -1 lun -1 ()
scbus-1 on xpt0 bus 0:
<> at scbus-1 target -1 lun -1 (xpt0)
i'm running r200176 (amd64).
cheers.
alex
b. f.
>not able to access any other cam members (ada* e.g.).
>
>when i issue the following command:
>
>`cdrecord dev=2,1,0 blank=all'
>
>binaries such as ls, top or vmstat simply stall until cdrecord finishes.
Try using cdrecord from sysutils/cdrtools-devel with the -immed flag.
Does the problem still occur?
Regards,
b.
Alexander Best
> >i've stumbled over a problem with ATA_CAM. when i accessing my
> >dvd-drive i'm
> >not able to access any other cam members (ada* e.g.).
> >when i issue the following command:
> >`cdrecord dev=2,1,0 blank=all'
> >binaries such as ls, top or vmstat simply stall until cdrecord
> >finishes.
> Try using cdrecord from sysutils/cdrtools-devel with the -immed flag.
> Does the problem still occur?
> Regards,
> b.
that solved the issue.
thanks.
alex
Alexander Best
> Alexander Best wrote:
> > i've stumbled over a problem with ATA_CAM. when i accessing my
> > dvd-drive i'm
> > not able to access any other cam members (ada* e.g.).
> > when i issue the following command:
> > `cdrecord dev=2,1,0 blank=all'
> > binaries such as ls, top or vmstat simply stall until cdrecord
> > finishes.
> > this is the output of `camcontrol devlist -v':
> > scbus2 on ata2 bus 0:
> > <HDS722516VLAT80 V34OA63A> at scbus2 target 0 lun 0
> > (ada0,pass0)
> > <HL-DT-ST DVDRAM GSA-H10N JL12> at scbus2 target 1 lun 0
> > (pass1,cd0)
> > <> at scbus2 target -1 lun -1 ()
> It was always bad idea to put CD and disk, which need to be used
> simultaneously, to the same PATA channel. PATA channel can execute
> only
> one command at a time, without using special technique, named overlap
> (part of TCQ), which is usually not supported by devices. When your
> blank command occupied CD, disk became inaccessible, until it
> complete.
thanks for the explanation. unfortunately my mothboard only comes with a
single PATA bus, but i'm trying to completely move from a SATA/PATA mixed
setup to a pure SATA setup this month. that should solve the issue then. i
just thought this was an issue introduced by ATA_CAM.
i would also like to ask: what will become of burncd in the future? will it be
adjusted to work with CAM? will it be removed/moved to ports? or will we
replace it with cdrecord/something else?
cheers.
Alexander Motin
> i would also like to ask: what will become of burncd in the future? will it be
> adjusted to work with CAM? will it be removed/moved to ports? or will we
> replace it with cdrecord/something else?
I don't know. In won't work any more in present state, and I don't see
much reasons to update it, as cdrecord seems to work fine.
--
Alexander Motin
Bernd Walter
> Goran Lowkrantz wrote:
> > Tested on a ASUSTeK M2N-VM DVI with good results. Only problem found was
> > with a CF card in a SATA-CF adapter. It lies that it can handle DMA but
> > fails miserably. Searched the web but could find no way to disable DMA
> > when using CAM-ATA.
>
> I have also seen problems with DMA on SATA-CF adapters. What's
> interesting is that same cards in PATA-CF adapter are working fine. Will
> try them more.
Just in case you are not aware of the CF DMA history.
CF slots originally had not DMA support and support including pins
had been assigned in a later revision.
Now it can happen that a card is DMA capable, but if placed into a non
DMA aware Slot the wiring is missing.
Because of this you can buy CF cards, which had been setup by the
vendor to not report DMA ability.
Some vendors offer tools to toogle this feature.
The only way to handle this automatically is to try DMA and fall back
to non DMA.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Alexander Best
before the ATA_CAM changes:
removing a cd/dvd and inserting a new one doesn't update the label in
/dev/iso9660.
`file -s /dev/iso9660/CD1` says:
/dev/iso9660/CD1: ISO 9660 CD-ROM filesystem data 'CD2
'
cheers.
alex
Wes Morgan
> i'm not sure if this issue is directly linked to ATA_CAM, but i've not seen it
> before the ATA_CAM changes:
>
> removing a cd/dvd and inserting a new one doesn't update the label in
> /dev/iso9660.
>
> `file -s /dev/iso9660/CD1` says:
> /dev/iso9660/CD1: ISO 9660 CD-ROM filesystem data 'CD2
> '
Nay, I've seen this kind of behavior for ages. I just assumed that the
cd9660 labels never updated.
Garrett Wollman
<permail-200912082339158...@message-id.uni-muenster.de>,
alexb...@wwu.de writes:
>removing a cd/dvd and inserting a new one doesn't update the label in
>/dev/iso9660.
>
>`file -s /dev/iso9660/CD1` says:
>/dev/iso9660/CD1: ISO 9660 CD-ROM filesystem data 'CD2
>'
That's always been true. glabel only notices a changed label on taste
events, and those only happen when the underlying provider is either
initialized for the first time, or closed after being open for write.
As root, you can force a retaste with
: 3>/dev/acd0
(That's the ':' command, not punctuation. Any command would do.)
-GAWollman
Alexander Best
nice if this would be fixed at some point. i believe the problem also applies
to tape drives, usb memory card readers, etc.? so generally speaking: any
devices which allow new media insertion, but don't disconnect/re-attach
from/to CAM.
cheers.
alex
Alexander Motin
> The main regression of the new mode is a lack of ataraid alternative, to
> support cheap BIOS-based ATA RAIDs. If somebody has time and wish to
> port that code from inside ata(4) into GEOM module, to make it work over
> CAM also, I would appreciate that and propose a help, if needed.
May be it would be easier to just teach gmirror, gstripe and gconcat to
handle ATA RAIDs metadata formats, to not duplicate and support the rest
of code.
Alexander Motin
> on 10/12/2009 01:07 Alexander Best said the following:
>> ah. i see. thanks for the hint. sorry mav for blaming ATA_CAM. ;) would be
>> nice if this would be fixed at some point. i believe the problem also applies
>> to tape drives, usb memory card readers, etc.? so generally speaking: any
>> devices which allow new media insertion, but don't disconnect/re-attach
>> from/to CAM.
>
> action. Right now there is no notification from hardware in most cases and there
> is no support for handling that in drivers, AFAIK. Maybe ahci driver starts to
> add support for that. So either something needs to poll media for changes or a
> user has to trigger some action explicitly. No magic.
Both ahci and siis drivers already have SATA Asynchronous Notifications
support, that was especially made to do that. Now AN used to receive
messages from PMP about fan-out ports physical events and working fine.
What is needed: SATA ATAPI device with AN support (haven't checked if
there are ones on the market), enable these messages, improve cd driver
to make some useful activity (have no idea how) on such events.
--
Alexander Motin
Alexander Motin
> Andriy Gapon wrote:
>> on 10/12/2009 01:07 Alexander Best said the following:
>>> ah. i see. thanks for the hint. sorry mav for blaming ATA_CAM. ;) would be
>>> nice if this would be fixed at some point. i believe the problem also applies
>>> to tape drives, usb memory card readers, etc.? so generally speaking: any
>>> devices which allow new media insertion, but don't disconnect/re-attach
>>> from/to CAM.
>> Yes, we need to get some notification that media is changed and then trigger geom
>> action. Right now there is no notification from hardware in most cases and there
>> is no support for handling that in drivers, AFAIK. Maybe ahci driver starts to
>> add support for that. So either something needs to poll media for changes or a
>> user has to trigger some action explicitly. No magic.
>
> Both ahci and siis drivers already have SATA Asynchronous Notifications
> support, that was especially made to do that. Now AN used to receive
> messages from PMP about fan-out ports physical events and working fine.
>
> What is needed: SATA ATAPI device with AN support (haven't checked if
> there are ones on the market), enable these messages, improve cd driver
> to make some useful activity (have no idea how) on such events.
With "how" I've meant "how to properly report it to GEOM".
Scott Long
> Alexander Motin wrote:
>> The main regression of the new mode is a lack of ataraid
>> alternative, to
>> support cheap BIOS-based ATA RAIDs. If somebody has time and wish to
>> port that code from inside ata(4) into GEOM module, to make it work
>> over
>> CAM also, I would appreciate that and propose a help, if needed.
>
> May be it would be easier to just teach gmirror, gstripe and gconcat
> to
> handle ATA RAIDs metadata formats, to not duplicate and support the
> rest
> of code.
>
The existing graid modules are not well suited for learning new
metadata. I have plans for restructuring them into a stack within
GEOM that handles metadata separate from the transforms.
Scott
Juergen Lock
>Andriy Gapon wrote:
>> on 10/12/2009 01:07 Alexander Best said the following:
>>> nice if this would be fixed at some point. i believe the problem also applies
>>> to tape drives, usb memory card readers, etc.? so generally speaking: any
>>> devices which allow new media insertion, but don't disconnect/re-attach
>>> from/to CAM.
>>
>> action. Right now there is no notification from hardware in most cases and there
>> is no support for handling that in drivers, AFAIK. Maybe ahci driver starts to
>> add support for that. So either something needs to poll media for changes or a
>> user has to trigger some action explicitly. No magic.
>
>Both ahci and siis drivers already have SATA Asynchronous Notifications
>support, that was especially made to do that. Now AN used to receive
>messages from PMP about fan-out ports physical events and working fine.
>
>What is needed: SATA ATAPI device with AN support (haven't checked if
>there are ones on the market), enable these messages, improve cd driver
>to make some useful activity (have no idea how) on such events.
Doesn't scsi have `unit attention' to notify media changes? Or does
that not work as expected with atapi?
Just wondering... :)
Juergen
Alexander Motin
> In article <4B20EDD2...@FreeBSD.org> you write:
>> Andriy Gapon wrote:
>>> on 10/12/2009 01:07 Alexander Best said the following:
>>>> ah. i see. thanks for the hint. sorry mav for blaming ATA_CAM. ;) would be
>>>> nice if this would be fixed at some point. i believe the problem also applies
>>>> to tape drives, usb memory card readers, etc.? so generally speaking: any
>>>> devices which allow new media insertion, but don't disconnect/re-attach
>>>> from/to CAM.
>>> Yes, we need to get some notification that media is changed and then trigger geom
>>> action. Right now there is no notification from hardware in most cases and there
>>> is no support for handling that in drivers, AFAIK. Maybe ahci driver starts to
>>> add support for that. So either something needs to poll media for changes or a
>>> user has to trigger some action explicitly. No magic.
>> Both ahci and siis drivers already have SATA Asynchronous Notifications
>> support, that was especially made to do that. Now AN used to receive
>> messages from PMP about fan-out ports physical events and working fine.
>>
>> What is needed: SATA ATAPI device with AN support (haven't checked if
>> there are ones on the market), enable these messages, improve cd driver
>> to make some useful activity (have no idea how) on such events.
>
> Doesn't scsi have `unit attention' to notify media changes? Or does
> that not work as expected with atapi?
Haven't checked. Will try it tomorrow. But any way it require device
polling. SATA AN same time is device-initiated real-time event.
--
Alexander Motin
Juergen Lock
Ah ok.
Cheers,
Juergen
Tom Uffner
> Hi.
>
> I would like to present for testing patch, turning ata(4) controllers
> drivers into native SIMs of new CAM ATA infrastructure. This patch adds
> new ATA_CAM kernel option, which allows switching between legacy and new
> CAM-based operation modes. To enable new mode you should add
> options ATA_CAM
> line to the kernel configuration file in addition to the ones required
> by CAM infrastructure and rebuild/reinstall the kernel.
>
> In legacy mode, the only difference will be - the way in which SATA
> speeds reported. Instead of mixing SATA revisions with PATA modes, they
> were separated, as they should be, allowing, for example, DMA-incapable
> or buggy SATA devices (usually PATA devices with built-in PATA/SATA
> converter) to work in PIO mode.
>
> While doing it, I had to completely rewrite ata(4) mode setting code, so
> legacy operation also need to be tested. I have successfully tested it
> on Intel, NVidia, VIA, Marvell, JMicron PATA controllers with all
> PIO/DMA modes. Different controllers feedbacks are especially welcome.
this change breaks my Promise SATA card
atapci0: <Promise PDC20771 SATA300 controller> port
0xdc00-0xdc7f,0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xfeac0000-0xfeadffff
irq 23 at device 11.0 on pci2
kernels from after the commit on 12/6 are unable to mount my drives.
i get (from memory, since i can't even get to single user mode)
WARNING - READ_DMA UDMA ICRC error
followed by lots of SETFEATURE foo errors then a READ_DMA timeout
followed by a bus reset and the cycle repeats...
before this commit it worked fine.
this is in the legacy mode. i am building a kernel with "options ATA_CAM"
now
tom
Alexander Motin
> this change breaks my Promise SATA card
Are you sure that it was this change?
> atapci0: <Promise PDC20771 SATA300 controller> port
> 0xdc00-0xdc7f,0xd800-0xd8ff mem
> 0xfeaff000-0xfeafffff,0xfeac0000-0xfeadffff irq 23 at device 11.0 on pci2
>
> kernels from after the commit on 12/6 are unable to mount my drives.
> i get (from memory, since i can't even get to single user mode)
> WARNING - READ_DMA UDMA ICRC error
> followed by lots of SETFEATURE foo errors then a READ_DMA timeout
> followed by a bus reset and the cycle repeats...
>
> before this commit it worked fine.
How long ago?
> this is in the legacy mode. i am building a kernel with "options ATA_CAM"
> now
OK. Tell me if there any difference.
Send me please full _verbose_ dmesg with original kernel and if possible
with new. If you can't get full with new, enable verbose messages and
make screenshots of drives detection and first errors.
--
Alexander Motin
Jaakko Heinonen
> Alexander Best wrote:
> > i would also like to ask: what will become of burncd in the future? will it be
> > adjusted to work with CAM? will it be removed/moved to ports? or will we
> > replace it with cdrecord/something else?
>
> I don't know. In won't work any more in present state, and I don't see
> much reasons to update it, as cdrecord seems to work fine.
I did some work to port acd(4) functionality needed by burncd(8) to
user space. My version of burncd can now burn a CD using a pass(4)
device but there's still a fair amount of work to do to make it
releasable.
I am not sure if I have interest to develop it further. If someone wants
to get the source, please contact me privately.
--
Jaakko
Tom Uffner
> Tom Uffner wrote:
>> this change breaks my Promise SATA card
>
> Are you sure that it was this change?
>
>> atapci0: <Promise PDC20771 SATA300 controller> port
>> 0xdc00-0xdc7f,0xd800-0xd8ff mem
>> 0xfeaff000-0xfeafffff,0xfeac0000-0xfeadffff irq 23 at device 11.0 on pci2
>>
>> kernels from after the commit on 12/6 are unable to mount my drives.
>> i get (from memory, since i can't even get to single user mode)
>> WARNING - READ_DMA UDMA ICRC error
>> followed by lots of SETFEATURE foo errors then a READ_DMA timeout
>> followed by a bus reset and the cycle repeats...
>>
>> before this commit it worked fine.
>
> How long ago?
kernel built from cvs update to D2009.12.05.05.00.00 boots & works
fine. kernels from cvs updates after the dev/ata commit on 12/6 can
not mount my ufs partitions in either legacy or w/ options ATA_CAM
>> this is in the legacy mode. i am building a kernel with "options ATA_CAM"
>> now
>
> OK. Tell me if there any difference.
>
> Send me please full _verbose_ dmesg with original kernel and if possible
> with new. If you can't get full with new, enable verbose messages and
> make screenshots of drives detection and first errors.
here is verbose dmesg from kernel built w/ sources updated to 12/5/2009 at
midnight EST: http://xiombarg.uffner.com/dmesg_20091205.txt
as soon as i can set up another PC & serial console i'll get you a verbose
boot from new kernel.
tom
Alexander Motin
> here is verbose dmesg from kernel built w/ sources updated to 12/5/2009 at
> midnight EST: http://xiombarg.uffner.com/dmesg_20091205.txt
>
> as soon as i can set up another PC & serial console i'll get you a verbose
> boot from new kernel.
Try please that patch:
--- ata-promise.c.prev 2009-12-15 21:35:43.000000000 +0200
+++ ata-promise.c 2009-12-15 21:35:24.000000000 +0200
@@ -957,6 +957,7 @@ ata_promise_mio_dmainit(device_t dev)
ata_dmainit(dev);
/* note start and stop are not used here */
ch->dma.setprd = ata_promise_mio_setprd;
+ ch->dma.max_iosize = 65536;
}
--
Alexander Motin