login
Search
Hi.
I would like to present for testing and feedback present state of my and
Scott work on extending CAM subsystem to support ATA in addition to
SCSI. At this moment we have:
- CAM transport separated on common and SCSI-specific parts, last one
wrapped with small API that allows switching;
- implemented SATA-specific transport, that is automatically used when
controller reports SATA bus attached to it. It supports both single
drive and Port Multiplier modes. The only parts unfinished yet is the
automatic hot-plug (you have to do reset/rescan manually) and heavy
errors recovery;
- implemented ATA disk driver for CAM infrastructure to natively
operate ATA disks. It already supports most of required functionality:
identify, read, write, flush, dump, NCQ;
- ATAPI devices handled natively by existing SCSI peripherals drivers,
by tunneling SCSI commands over ATA bus by PACKET ATA extension;
- implemented AHCI controller driver, supporting most of tasty
hardware features (controller command queuing, NCQ, Port Multiplier,
MSI). Only some features from latest AHCI specifications for which I
have no hardware left unimplemented.
- camcontrol took minor changes to be able to report ATA devices.To test our work you should:
- have any AHCI compatible controller configured to native AHCI mode
(not a COMPATIBLE or RAID or whatever else) by BIOS;
- have some Serial ATA/ATAPI drives connected to AHCI controller;
- patch your recently updated 8-CURRENT with this patch:
http://people.freebsd.org/~mav/cam-ata.20090626.patch
- rebuild and install world and kernel;
- read new ahci man page;
- make sure that you will be able to boot if your SATA disk devices
name change from some ad4 to ada0;
- load ahci kernel module using loader prompt or loader.conf;
- boot.This change does not breaks existing ATA infrastructure, it just
provides higher priority driver for the same hardware. So you should be
able get back at any time by just not loading ahci module.To ho...
Alexander Motin schrieb am 26.06.2009 20:47 (localtime):
Late, but now I'd like to jump in.
I have a gournaled FS whoch lists it's consumer as ad12p6
Otherwise I only use labels (ufs) for quiet some time, so I thought=20
testing would be painless...
Can I safely remove glabel from the unmounted fs and relabel the new devi=
ce?Any Experiences?
Thanks,
-Harry
It's never late. I have just uploaded fresh patch:
You mean gjournal has provider names hardcoded to it's meta data? It
could be a problem. If it detects it's parts freely, then it should notI don't very understand whet you mean by "safe"? Safe for what?
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Alexander Motin schrieb am 05.07.2009 09:18 (localtime):
I tuned off journaling in UFS and removed the journal from the=20
partition. Although gjournal told me that the existing filesystem will=20
be destroyed this didn't happen since I did the newfs on the .journal=20
partition originally.
That's what I meant as "safe". In theory it was clear that I can safely=20
relabel the partition, but I was not sure if I understood everything=20
correctly.So far I have not had any problems with ahci, works great! (ich9)
At least with HDs, haven't tested ODDs yet. (I'm having burning problems =for a long time so I'm not used to use ODDs with FreeBSD)
One thing I'm missing is the possibility to spin down the drive.
I have my system on a SSD, the HD is just for ports nad stuff which=20
usually I don't make use of.
Is that planned to be integrated?Another question is why "camcontrol tur ada0" returns "Unit is not ready"=
readcap also doesn't work.
My SSD reports write and read cache present, but disabled. Is the report =or the status bad?
camcontrol iden ada0
pass1: <OCZ SOLID SSD 02.10104> ATA/ATAPI-8 SATA 2.x deviceProtocol SATA revision 2.x
device model OCZ SOLID SSD
serial number MK0508480C17B0004
firmware revision 02.10104
cylinders 16383
heads 16
sectors/track 63
lba supported 62586880 sectors
lba48 not supported
dma supported
overlap not supportedFeature Support Enable Value Vendor
write cache yes no
read ahead yes no
Native Command Queuing (NCQ) no - 0/0x00
Tagged Command Queuing (TCQ) no no 0/0x00
SMART yes yes
microcode download no no
security no no
power management yes yes
advanced power management no no 0/0x00
automatic acoustic management no no 254/0xFE 128/0x80Thansk for your great work so far!
Best reg...
There is no problem, it just wasn't done yet. It should be possible to
submit respective ATA command via CAM pass interface to spin-down drive
immediately or to set wanted power management level, but respectiveIt is all SCSI commands. This implementation expects real direct ATA
operation without SCSI emulation parts. But this commands should workIt is probably the truth. Existing ATA driver enables this features
during drive reset sequence. New one doesn't do it yet.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Alexander Motin schrieb am 07.07.2009 21:06 (localtime):
=2E..Ic, but my "real" HD ast it enabled:
camcontrol iden ada1
pass2: <SAMSUNG HD322HJ 1AG01113> ATA/ATAPI-7 SATA 2.x deviceProtocol SATA revision 2.x
device model SAMSUNG HD322HJ
serial number S17AJ9AS305229
firmware revision 1AG01113
cylinders 16383
heads 16
sectors/track 63
lba supported 268435455 sectors
lba48 supported 625142448 sectors
dma supported
overlap not supportedFeature Support Enable Value Vendor
write cache yes yes
read ahead 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 yes no 0/0x00
automatic acoustic management yes no 0/0x00 254/0xFEDoes the old school HD enable caches itself?
Thanks,
-Harry
Yes. At least this specific one.
My OCZ Vertex SSD also has them enabled by default.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Hi Alexander.
"make buildworld" with this patch stops in my configuration with:
(cd /usr/src/rescue/rescue/../../usr.sbin/chown &&
/usr/obj/usr/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE
DIRPRFX=rescue/rescue/chown/ depend && /usr/obj/usr/src/make.i386/make
-DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ chown.o)
`chown.o' is up to date.
cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo
date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo
kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo
realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo
rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo
clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo
fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo
ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo
ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo
mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo
mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo
nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo
rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo
tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo
bsdlabel.lo sconfig.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo
tail.lo tee.lo gzip.lo bzip2.lo tar.lo vi.lo id.lo chroot.lo chown.lo
/usr/obj/usr/src/rescue/rescue/../librescue/exec.o
/usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o
/usr/obj/usr/src/rescue/rescue/../librescue/login_class.o
/usr/obj/usr/src/rescue/rescue/../librescue/popen.o
/usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o
/usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o
/usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit
-lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec
-lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv
-lmd -lreadline -lsbuf -lufs -lz -lbz2 -larchive -l...
Thanks.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I tried this on the box with that optical drive that head no
longer likes (fails to be probed and generates an irq storm, see
http://docs.freebsd.org/cgi/mid.cgi?20090628101656.GA38983
), and with ahci.ko loaded by loader.conf I got timeouts followed by
a panic:
http://people.freebsd.org/~nox/cam-ata.20090704-panic1.jpg
http://people.freebsd.org/~nox/cam-ata.20090704-panic2.jpgThe panic seems to be in cam_periph_lock:
(kgdb) l *(cdioctl+0x4e)
0xffffffff801a937e is in cdioctl (cam_periph.h:183).
178 u_int32_t sense_flags, union ccb *save_ccb);
179
180 static __inline void
181 cam_periph_lock(struct cam_periph *periph)
182 {
183 mtx_lock(periph->sim->mtx);
184 }
185
186 static __inline void
187 cam_periph_unlock(struct cam_periph *periph)
(kgdb)Without ahci.ko loaded it boots, but the original problems remain,
here is the dmesg from that boot: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-CURRENT #0: Mon Jul 6 21:22:05 CEST 2009
nox@triton.kn-bremen.de:/usr/obj/usr/home/nox/src8camata/src/sys/TRITON8
WARNING: WITNESS option enabled, expect reduced performance.
Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81025000.
module_register: module probe already exists!
Module probe failed to register: 17
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2812820279 Hz
CPU: AMD Phenom(tm) II X4 920 Processor (2812.82-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0x100f42 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=0x802009<SSE3,MON,CX16,POPCNT>
AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,...
I'm using your 29-june patch (including the ALL_SLOTS_BUSY fix) since
yesterday without any problems!I use GUID partitioned gmirror and zfs on a AMD780G based mainboard.
The only irritating thing is that the zpool now shows gptid's instead of
the partition names.Boris
ahci0: <AHCI controller> port
0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f
mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0
ahci0: [ITHREAD]
ahci0: AHCI v1.10 controller with 4 3Gbps ports, PM 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]
atapci0: <ATI IXP700/800 UDMA133 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
ahcich0: Poll timeout on slot 2
(probe0:ahcich0:0:0:0): SIGNATURE: 0000
ahcich1: Poll timeout on slot 2
(probe0:ahcich1:0:0:0): SIGNATURE: 0000
ahcich2: Poll timeout on slot 2
(probe0:ahcich2:0:0:0): SIGNATURE: 0000
ada0 at ahcich0 bus 0 target 0 lun 0
ada0: <ST3320620NS 3.AEK> ATA/ATAPI-7 SATA 2.x device
ada0: 300.000MB/s transfers
ada0: 305244MB (625140335 512 byte sectors: 16H 63S/T 16383C)
ada0: Native Command Queueing Enabled
ada1 at ahcich1 bus 0 target 0 lun 0
ada1: <SAMSUNG HD322HJ 1AC01112> ATA/ATAPI-7 SATA 2.x device
ada1: 300.000MB/s transfers
ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
ada1: Native Command Queueing Enabled
ada2 at ahcich2 bus 0 target 0 lun 0
ada2: <ST3320620NS 3.AEG> ATA/ATAPI-7 SATA 2.x device
ada2: 300.000MB/s transfers
ada2: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
ada2: Native Command Queueing Enabled
GEOM_MIRROR: Device mirror/root launched (2/2).
...
No luck with an ICH10 board
I did a buildworld/kernel
BTX loader 1.00 BTX version is
1.02
Consoles: internal
video/keyboard
BIOS drive C: is
disk0
BIOS 632kB/3136000kB available
memoryFreeBSD/i386 bootstrap loader, Revision
1.1
(mdtancsa@i7.sentex.ca, Fri Jun 26 08:24:30 EDT
2009)
**28 ops 7 bypasses 93 hits 31 misses 1
flushes
Consoles: internal
video/keyboard
BIOS drive C: is
disk0
BIOS 632kB/3136000kB available
memoryFreeBSD/i386 bootstrap loader, Revision
1.1
(mdtancsa@i7.sentex.ca, Fri Jun 26 08:24:30 EDT
2009)
Can't work out which disk we are booting
from.
Guessed BIOS device 0xffffffff not found by probes, defaulting to
disk0:can't load
'kernel'Type '?' for a list of commands, 'help' for more detailed
help.
OKOK
lsdev
cd
devices:
disk
devices:
disk0: BIOS drive
C:
pxe
devices:
OKOK
ls
open '/' failed: input/output
error
OKI tried with both a module and it built into the kernel
but no luck. putting it back into regular IDE mode allows it to boot
with the patched kernelatapci0: <Intel ICH10 SATA300 controller> port
0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb48f,0xb400-0xb40f
irq 19 at device 31.2 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480
atapci0: [MPSAFE]
atapci0: [ITHREAD]
atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xb400
ata2: <ATA channel 0> on atapci0
atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000
atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00
ata2: reset tp1 mask=03 ostat0=50 ostat1=10
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
ata2: [MPSAFE]
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880
atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800
ata3: reset tp1 mask=03 ostat0=7f ostat1=7f
ata3: stat0=...
I see no any relation to the patch here. I would say it is some
BIOS/loader problem, as kernel wasn't yet booted. Have you been ever
able to boot this system with AHCI enabled before?--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I re-installed the OS on a new drive with a 200906 snapshot, and can
now boot with AHCI enabled in the BIOS. The original image was a
RELENG_7 box that I upgraded to HEAD some time ago. Is there
something that needs to be manually updated that would not have been
done as part of the normal buildworld/buildkernel ? Re-install the
boot blocks perhaps ?ahci0: <AHCI controller> port
0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f
mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0
ahci0: [ITHREAD]
ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM not 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]
ahcich4: <AHCI channel> at channel 4 on ahci0
ahcich4: [ITHREAD]
ahcich5: <AHCI channel> at channel 5 on ahci0
ahcich5: [ITHREAD]On the ich10 board, its trying to boot up now, but I am getting
uhub8: 4 ports with 4 removable, self powered
(probe2:ahcich2:0:0:0): SIGNATURE: eb14
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
ahcich2: Timeout on slot 4
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
ahcich2: Timeout on slot 5
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config
ahcich2: Timeout on slot 6
run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config
ahcich2: Timeout on slot 7
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
ahcich2: Timeout on slot 8
ada0 at ahcich1 bus 0 target 0 lun 0
ada0: <ST3500410AS CC34> ATA/ATAPI-8 SATA 2.x device
ada0: 300.000MB/s transfers
ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada0: Native Command Queueing Enabledmountroot> ufs:/dev/ada0s1
Trying to mount root from ufs:/dev/ada0s1
GEO...
I've found how to make this DVD work. It refused to process PACKET
command until I have explicitly set it's PATA-legacy transfer mode to
the maximal supported.%camcontrol devlist
<ST3500410AS CC34> at scbus0 target 0 lun 0 (pass0,ada0)
<MATSHITA DVD-ROM UJDA780 1.50> at scbus2 target 0 lun 0 (cd0,pass1)Patch committed to P4.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I mentioned this a few months ago. Both atapi and ata devices need a
state machine to set their max transfer parameters, regardless if they
are sata or pata. Newer sata devices might not need it, but older
ones definitely do. IMHO, it's easiest to just do the negotiation for
all sata devices instead of trying to be selective about it.Scott
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
mergemaster?
Can you try to disconnect CD?
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Actually, It went to single user mode on the console (I was logged in
via serial console). However, I could not mount anything for some
reason. Going in /dev, only /dev/ada0 and /dev/ada0s1 were there. The
disk slices were not for some reason. This was on an AMD64 kernel BTW.But, going back to the original i386 image, with the boot blocks
reinstalled and using your latest patch, it seems to work! (however,
the same 300sec delay due to the cdrom ? )mountroot> ufs:/dev/ada0s1a
Trying to mount root from ufs:/dev/ada0s1a
dumpon: /dev/ad4s1b: No such file or directory
/etc/rc: WARNING: unable to specify /dev/ad4s1b as a dump device
Entropy harvesting: interrupts ethernet point_to_point kickstart.
swapon: /dev/ad4s1b: No such file or directory
/dev/ada0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ada0s1a: clean, 259768 free (1048 frags, 32340 blocks, 0.2% fragmentation)
Can't stat /dev/ad4s1d: No such file or directorJul 1 08:07:58 init:
/bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:
# ls -l /dev/ad*
crw-r----- 1 root operator 0, 111 Jul 1 08:02 /dev/ada0
crw-r----- 1 root operator 0, 112 Jul 1 08:02 /dev/ada0s1
crw-r----- 1 root operator 0, 113 Jul 1 08:02 /dev/ada0s1a
crw-r----- 1 root operator 0, 114 Jul 1 08:02 /dev/ada0s1b
crw-r----- 1 root operator 0, 115 Jul 1 08:02 /dev/ada0s1d
crw-r----- 1 root operator 0, 116 Jul 1 08:02 /dev/ada0s1e
crw-r----- 1 root operator 0, 117 Jul 1 08:02 /dev/ada0s1f
#And, after its booted up,
ahci0: <AHCI controller> port
0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f
mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0
ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfadd6000
ahci0: attempting to allocate 1 MSI vectors (16 supported)
msi: routing MSI IRQ 262 to local APIC 0 vector 64
ahci0: using IRQ 262 for MSI
ahci0: [MPSAFE]
ahci0: [ITHREAD]
ahci0: AHCI v1.20 contr...
At first, I thought something was a miss speed wise, but it looks
like this hardware is either having issues, or something is wrong in
general as its the same no matter which driver is used. Usually the
speeds are much quicker than whats below on block writesSeeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1 4000 39798 20.8 39725 4.3 17776 3.4 40269 27.1 42085 4.2 255.8 0.6
2 4000 38827 20.3 40116 4.4 18068 3.4 40227 27.3 42266 4.3 244.8 0.5
3 4000 39748 20.8 40166 4.4 17952 3.3 40192 27.3 42259 4.3 243.4 0.5
4 4000 39855 20.8 40066 4.4 18017 3.3 40206 27.1 42401 4.2 264.2 0.61=AHCI in bios, AHCI.ko loaded
2=AHCI in bios, plain old ata driver used post patch
3=IDE in bios, plain old ata driver used post patch
4=IDE in bios, plain old ata driver from the cvsNote, with 2 dmesg shows
acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00
acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00the boot process then hangs for about 5 seconds, and then proceeds
with 3, the boot process hangs a total of about 2 min.
---Mike
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
This test looks inadequate. there is almost no modern SATA HDDs having
only 40MB/s of linear read/write speed. Usual values now are 60-100MB/s
and they should be reached with almost any working driver. Can you try
simple `dd if=/dev/ada0 of=/dev/null bs=1m count=1000`?To obtain any measurable benefit from NCQ usage you should have many
random requests to the drive running simultaneously. Not sure how this
specific test works. Also NCQ depends on effective disk firmware toIf you have issues with old driver also, then it is probably some drive
specifics, but not a bug of the new implementation. There was no changes
to the old ATA.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Something about this particular disk perhaps
0[i7]# dd if=/dev/ad4 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 14.933896 secs (70214497 bytes/sec)Using a different seagate disk,
0[i7]# dd if=/dev/ad6 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 7.542932 secs (139014377 bytes/sec)
0[i7]#I will re-run the tests with the newer seagate.
Perhaps a firmware update to the 'slow' one might help
Protocol SATA revision 2.x
device model ST380811AS
serial number 6PS03G9Z
firmware revision 3.AAE
cylinders 16383
heads 16
sectors/track 63
lba supported 156301488 sectors
lba48 supported 156301488 sectors
dma supported
overlap not supportedFeature Support Enable Value Vendor
write cache yes yes
read ahead 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/0xFEFEYes, it certainly seems so. This DVD is off the PATA bus
0[i7]# atacontrol list
ATA channel 0:
Master: no device present
Slave: no device present
ATA channel 1:
Master: no device present
Slave: no device present
ATA channel 2:
Master: no device present
Slave: acd0 <DVD-ROM UJDA780/1.50> ATA/ATAPI revision 7
ATA channel 3:
Master: ad6 <ST380811AS/3.AAE> SATA revision 2.x
Slave: no device present
ATA channel 4:
Master: no device present
Slave: no device present
ATA channel 5:
Master: no device present
Slave: ...
Wait! Stop! I have got lost in what we are testing. In some of your your
previous messages today I have seen:(probe2:ahcich2:0:0:0): SIGNATURE: eb14
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
ahcich2: Timeout on slot 4
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
ahcich2: Timeout on slot 5First line means that it is ATAPI drive on AHCI SATA controller and
latest lines mean that it is not working properly. Now you are talking
that this is PATA drive. Could you please somehow identify each of your
system to let me identify problems and solutions separately.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Sorry, I just opened up the case to confirm, and it is indeed a SATA
DVD drive.---Mike
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Messages like "it's just not working" will not give anything except
upsetting me. Usually I need more information. So if you are really what
to track and fix some problem, please, identify it somehow, to be able
to send more follow-ups later and compare to different user's results.
Open cases one by one in separate emails.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Sorry again for the confusion. I am trying a *different* motherboard
(INTEL DX58SO) and drive now with your 0629 patch as well as the diff below.--- ahci.c.prev 2009-06-29 12:48:45.000000000 +0300
+++ ahci.c 2009-06-29 17:25:29.000000000 +0300
@@ -986,7 +986,7 @@ ahci_begin_transaction(device_t dev, uni
if (ch->slot[tag].state == AHCI_SLOT_EMPTY)
break;
} while (tag != ch->lastslot);
- if (tag == ch->lastslot)
+ if (ch->slot[tag].state != AHCI_SLOT_EMPTY)
device_printf(ch->dev, "ALL SLOTS BUSY!\n");
ch->lastslot = tag;
/* Occupy chosen slot. */Without the diff, I was getting a steady stream of
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!
ahcich0: ALL SLOTS BUSY!With the above diff, all seems to work well.
Full verbose dmesg and pciconf -lvc at
http://www.tancsa.com/ahci/DX58SO.txt
Read/Write speed looks good with a more modern disk as well
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
4000 103884 51.4 109344 9.7 42048 6.0 91201 59.0
116723 8.5 1123.4 2.0
0(ich10)# dd if=/dev/ada0 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 7.562206 secs (138660068 bytes/sec)
0(ich10)#The eSata port does not work, but it never did under the old driver
either. I think it has a separate controller ? At the BIOS boot up
time, it shows some Marvell controller talking to the eSata attached
drive, and pciconf does show a separate ATA controller
...
Fine. But first test still looks like bound by something. Or this test
requires some tuning, or it is used over file system, your system may
require tuning.It would be more interesting to investigate benefits on NCQ suitable
workload, as that are new for us. Something like unpacking a lot of
small files to normal or async-mounted or gjournalled FS, or some
multi-threaded read, or something else. Would be nice to understand on
which types of workload NCQ could give us visible effects.You can track real requests parallelism by looking on dev_active field
But this device, implementing both PATA and SATA ports, report itself as
PATA controller. It's SATA part may be AHCI compatible, but driver
unable to attach it due to incorrect device identification. Alike
happens to my JMicron controllers, but in that case system BIOS is able
to switch it into the right mode with separate PATA and AHCI SATA
controllers devices.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
We dont have too many disk I/O bound apps here. Where we do, we
typically have used raid controllers in RAID10. But I will
experiment a little more over the weekend. For us, we are interested
in large amounts of storage for backup purposes. Having things like
port multiplier features are very nice to have. But I will try someLooking in the BIOS, I am able to toggle IDE and RAID mode only for
the eSata controller portion, where as I have IDE, AHCI and RAID for
the onboard Intel controller.---Mike
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Actually, I had never tried before. It does not work either with a
generic kernel. Its a supermicro board. I will see if I can find a BIOS update---Mike
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
On Fri, 26 Jun 2009 21:47:26 +0300
- remove atapicam from you kernel config file, otherwise the kernel
---
Gary Jennejohn
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Thank you for report. Problem is that atapicam provides fake emulated
SPI transport, but not a native ATA in terms of updated CAM. Small
attached patch fixes this for me:# camcontrol devlist
<OCZ-VERTEX 1.30> at scbus0 target 0 lun 0 (pass0,ada0)
<Slimtype DVD A DS8A1P CA11> at scbus3 target 0 lun 0 (cd0,pass1)--
Alexander Motin
On Sat, 27 Jun 2009 20:22:04 +0300
Thanks a lot. This patch fixed the problem for me too.
Any plans to update your original patch?
---
Gary Jennejohn
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Sure I will in few days. Just not after every single change. I am still
investigating this issue to find real crash reason, that was triggered
by this mistake.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I, personally, think this is not very good idea. People are used to
CAM-devices getting enumerated as da0, da1, etc. All the documentation
talks about ad0 for ATA and da0 (plus camcontrol) for SCSI, USB,
Firewire devices. We also have fd0 and cd0 and should stick to
two-letter-plus-number codes. So either make them all ad0 or da0. I'd
vote for the latter, as that is what Linux is doing (more or less) and
people are already familiar with USB drives or new SATA drives showing
up as "SCSI drives, so they get the SCSI names".Anyway, thanks for the work and your consideration! The sooner we can
unify the disk drive namespace, the better.Unrelated question: will it be possible to assign/reserve daX for
specific busses? Like say all USB/Firewire devices will start at da9?Cheers,
Ulrich Spörlein
--
http://www.dubistterrorist.de/
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
We should understand difference between transport and command set. SPI,
SAS, USB and FireWire are all just a transports for SCSI commands, and
their disk devices use the same SCSI-command disk driver "da". ATA disks
in this implementation are still use their native ATA commands, without
translating to SCSI. So "ada" is a completely separate driver, operating
disk devices supporting ATA, but _not_ a SCSI, command set.Whatever name we would use for it, "ada" still will be separate driver.
It is not my whim. IMHO having two drivers with the same name is just a
time bomb, which will create problems in future. If somebody sure that
it won't, I will be glad to hear his technical opinion about how toThe main difference is that in our case SATA is not SCSI! We are not
doing any emulation. CAM != SCSI any more! CAM = SCSI + ATA + whatever!--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Hello, hope you're having a nice day,
This poses the question of daXX enumeration order. I've already had some
'fun' with an IBM server which has an LVD/320 SCSI controller. While the
controller's bus was enumerated properly, somehow if you attach an USB
mass storage device before the system boot that said mass storage could
suddenly appear earlier than one of the SCSI disks (that was on
7.0-RELEASE) thus breaking the boot process sometimes (when it appeared
as da0).--
Kamigishi Rei
KREI-RIPE
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
7.2 has UFSID in GENERIC so you can mount your disks that way which is=20
non-ambiguous.Unfortunately you can't specify swap this way because it has no ID, I=20
don't know how hard it would be to add such a thing (which would=20
require a mkswap or somesuch, and modification to the dump & swap=20
code..)=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
On Sat, Jun 27, 2009 at 8:17 PM, Daniel O'Connor<doconnor@gsoft.com.au> wrote:
You can use glabel to add a label to the raw swap partition. I use to
have a line containing/dev/label/BSDSWAP none swap sw 0 0
in /etc/fstab.
--
My preferred quotation of Robert Louis Stevenson is "You cannot
make an omelette without breaking eggs". Not because I like the
omelettes, but because I like the sound of eggs being broken.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Or you can use GPT-specific labels, as well. They would look like
/dev/gpt/swap1
/dev/gptid/adec0ea7-642e-11de-85dc-000476911739
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Yes. I've hit this problem. I haven't tried yet, but probably marking
the whole disk with glabel could be an option now.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Louis' glabel solution works for me so far :)
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
I've experienced many weird things while trying to use glabel for swap
partitions. I wonder where does GEOM store the label, because doingglabel create swap /dev/ad0s1b
successfully adds a label, it shows up on boot:
GEOM_LABEL: Label for provider /dev/ad0s1a is label/swap
however, after a while the label is lost. Maybe the metadata is stored
in the last sector of the swap space, and the swap data overwrites it, I
don't know.There's even funnier thing about UFS labels. Let's say we have a gmirror
device gm0.# gmirror create -v -b round-robin gm0 /dev/ad0
# gmirror insert gm0 /dev/ad2
# reboot
# tunefs -L root /dev/mirror/gm0s1a
*GEOM_LABEL: Label for provider /dev/mirror/gm0s1a is ufs/root*
# vim /etc/fstab
/dev/ufs/root / ..........
# rebootIt might work for a while, but usually almost on the next boot I see:
ad0: <STwhateverAS SD15> TOOMANYMB on ata0-master SATA300
ad2: <STwhateverAS SD15> TOOMANYMB on ata1-master SATA300
*GEOM_LABEL: Label for provider /dev/ad0s1a is ufs/root*
GEOM_MIRROR: Provider gm0 started (2/2)
Trying to mount root from ufs:/dev/ufs/root...Manual root filesystem specification:
And the system wants me to enter the root FS name manually because ad0
is locked by GEOM and ad0s1a can't be mounted therefore. GEOM_LABEL
finds the label before GEOM_MIRROR is started properly.I've experienced this behaviour on both 7.2 and, I think, 8.0 too (May
snapshot).
I know we don't really need labels on a gmirror because a gmirror is a
'label' in itself and will always appear as /dev/mirror/device-name no
matter how we swap HDDs and no matter in which order they are probed,
however this is still a bit strange.--
Kamigishi Rei
KREI-RIPE
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I think you want glabel label swap /dev/ad0s1b
'create' is the manual method which won't store any metadata - 'label'=20
I think if you use label you'd be OK (but you'd need to newfs because=20
the created provider is 1 sector smaller). The other alternative is to=20
use /dev/ufsid/xxx which won't require a newfs as your existing FS's=20
have an ID already (presuming you are using GENERIC).=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Hello, hope you're having a nice day,
I might be mistaken here as I tried that in May, when I upgraded my
production server to 7.2; I probably tried using the 'label' subcommand
or it wouldn't show up on boot, right? (There was a mistype in my
earlier message; should be "label for provider ad0s1b is label/swap",
The problem with ufsids is that unlike a manually set label, you can't
really distinguish between them (as opposed to the default scheme of sXY
where for a boot device you can be almost 80% certain that ad0s1a is /,
f is /usr, etc etc - especially if the default number of partitions was
created).--
Kamigishi Rei
KREI-RIPE
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I guess I'll find out tomorrow when I reboot my laptop and see what=20
happens.The UFSID is unique for a given newfs (mostly - it is the timestamp I=20
believe).=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Hello, hope you're having a nice day,
It is unique; however, I'm not talking about it being unique. More like
from a console standpoint.
Imagine your system's asking for manual input for the root partition;
what's easier to type - /dev/ufs/root,
/dev/ufsid/{inserthugenumberinhexhere} or /dev/physical-device?
Reading through /etc/fstab when it uses ufsids is a pain as well.By the way, in my opinion the current freebsd install system should
allow running GEOM commands before partitioning/labelling devices. And
should also recognize GEOM devices, as well, since for a clean install
the transition to labels & gmirror is either 'not safe'
(kern.geom.debugflags=16, then label the live system's drive) OR
requires a dump/restore (label the 2nd drive, label the partitions, then
copy data there, reboot to the 2nd drive, add the first to the mirror).P.S. Also, bsdlabel and glabel seem like ambiguous names (as well as
using the term 'label' for both slice layout and GEOM labels) - so I see
no problems naming AHCI devices "daX". ;)
--
Kamigishi Rei
KREI-RIPE
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Hello, hope you're having a nice day,
It is unique; however, I'm not talking about it being unique. More like
from a console standpoint.
Imagine your system's asking for manual input for the root partition;
what's easier to type - /dev/ufs/root,
/dev/ufsid/{inserthugenumberinhexhere} or /dev/physical-device?
Reading through /etc/fstab when it uses ufsids is a pain as well.By the way, in my opinion the current freebsd install system should
allow running GEOM commands before partitioning/labelling devices. And
should also recognize GEOM devices, as well, since for a clean install
the transition to labels & gmirror is either 'not safe'
(kern.geom.debugflags=16, then label the live system's drive) OR
requires a dump/restore (label the 2nd drive, label the partitions, then
copy data there, reboot to the 2nd drive, add the first to the mirror).P.S. Also, bsdlabel and glabel seem like ambiguous names (as well as
using the term 'label' for both slice layout and GEOM labels) - so I see
no problems naming AHCI devices "daX". ;)
--
Kamigishi Rei
KREI-RIPE
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
The latter obviously, however that situation is rare, and you can list=20
sysinstall is fun like that, it has many limitations..
bsdlabel is a historic, and glabel is a fairly intuitive name..
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
I use glabel to create containers with named labels that I then
reference as swap devices. (e.g., /dev/label/swap0, etc.)# swapinfo
Device 1024-blocks Used Avail Capacity
/dev/label/swap2 1044192 0 1044192 0%
/dev/label/swap3 1044192 0 1044192 0%
/dev/label/swap4 1044192 0 1044192 0%
Total 3132576 0 3132576 0%louie
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Ahh, of course, like this?
glabel label swap0 /dev/ad0s1b
(well that works for me but I'd like to check ;)Any idea if that works with dumping? dumpon accepts it but..
Thanks!
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
On Sun, 28 Jun 2009 14:30:02 +0930
It does for sure.
--=20
Stanislav Sedov
ST4096-RIPE
CAM allows you to statically set the enumeration order via hints in
either the kernel config file or in /boot/loader.conf. /sys/conf/NOTES
contains information and examples of this.Scott
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
On Sat, 27 Jun 2009 18:19:38 +0400
This is why I always wire down my SCSI devices in devices.hint.
---
Gary Jennejohn
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Excellent stuff.
I've installed the patch and it works fine. Excerpt from dmesg:nox# dmesg | grep -E "(ahci|ada|ata)"
ahci0: <AHCI controller> mem 0xfc000000-0xfc001fff irq 19 at device 0.0 on pci3
ahci0: [ITHREAD]
ahci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich0: [ITHREAD]
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich1: [ITHREAD]
atapci0: <JMicron JMB363 UDMA133 controller> port 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 16 at device 0.1 on pci3
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ahci1: <AHCI controller> port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfc106000-0xfc1067ff irq 19 at device 31.2 on pci0
ahci1: [ITHREAD]
ahci1: AHCI v1.20 controller with 6 3Gbps ports, PM supported
ahcich2: <AHCI channel> at channel 0 on ahci1
ahcich2: [ITHREAD]
ahcich3: <AHCI channel> at channel 1 on ahci1
ahcich3: [ITHREAD]
ahcich4: <AHCI channel> at channel 2 on ahci1
ahcich4: [ITHREAD]
ahcich5: <AHCI channel> at channel 3 on ahci1
ahcich5: [ITHREAD]
ahcich6: <AHCI channel> at channel 4 on ahci1
ahcich6: [ITHREAD]
ahcich7: <AHCI channel> at channel 5 on ahci1
ahcich7: [ITHREAD]
(probe1:ahcich1:0:15:0): SIGNATURE: 0000
(probe0:ahcich1:0:0:0): SIGNATURE: 0000
(probe7:ahcich7:0:15:0): SIGNATURE: 0000
(probe0:ahcich7:0:0:0): SIGNATURE: 0000
ada0 at ahcich1 bus 0 target 0 lun 0
ada0: <WDC WD6400AAKS-00A7B0 01.03B01> ATA/ATAPI-8 SATA 2.x device
ada0: 300.000M...
Thank you for report. I have missed this due to increased DFLTPHYS value
This is not a problem. ATA disks does not have SCSI INQUIRY command.
They use own IDENTIFY instead. inquiry should work for ATAPI devices, as
they are SCSI deep inside.--
Alexander Motin
This should be addressed via multi-part transfers at some point.
This is really the big missing piece in camcontrol; we need to add
support for getting the IDENT info and getting/setting various
attributes, as well as sending ATA commands over passthrough.Scott
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Hi Scott,
not sure if this is related, but I always wondered why tools like
smartctl never work with USB attached ATA disks. Is it missing support
in our drivers and smartctl or is it simply impossible?Cheers,
Ulrich Spörlein
--
http://www.dubistterrorist.de/
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
The possibility depends on several hardware and software factors. If
the USB disk enclosure was speaking ATA all the way up to the umass
driver, then it could be possible to add some extra intelligence to the
driver to make SMART work. However, if the enclosure chip is speaking
anything else, then probably not. As an alternative, you might try to
the ata-usb module instead and see if that works.Scott
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
It also depends heavily on which USB bridge chip is in your external
enclosure. See these links for a table of known good/bad enclosures:http://smartmontools.wiki.sourceforge.net/USB
http://smartmontools.wiki.sourceforge.net/overview_USB-Support--
Dan Nelson
dnelson@allantgroup.com
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I don't know much about USB storages and protocols used there, but I
think it is the ATA->SCSI protocol conversion done by ATA->USB adapter
limits functionality. If this is correct:
http://en.wikipedia.org/wiki/USB_mass_storage_device_class
, it is impossible to avoid this conversion in common case.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Thanks for the link! I guess my next external HDD will have an eSATA
interface then :/Cheers,
Ulrich Spörlein
--
http://www.dubistterrorist.de/
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
On Fri, 26 Jun 2009 21:47:26 +0300 Alexander Motin <mav@FreeBSD.org>
wrote:[ATA via CAM]
Will it stay at adaX, or is it planned to move it to daX like other
harddisks attached via SCSI? If it stays like it is now: what's the
rationale to use a different name?Bye,
Alexander.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
It is still point of discussion. I have arguments for 3 different options:
da - PRO: habitual CAM/SCSI disk name; CONTRA: ATA disk uses
completely separate ATA-native peripheral driver, it is difficult use
the same name for two drivers and it IMHO looks ugly:
ad - PRO: habitual ATA disk name; CONTRA: heavily conflicts with
ATA_STATIC_ID ata(4) option device unit numbering, also the same driver
name conflict, but a bit easier due to different parent bus;
ada - PRO: perfect from internal infrastructure PoV; CONTRA: just
unhabitual.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
On Sat, 27 Jun 2009 14:22:00 +0300 Alexander Motin <mav@FreeBSD.org>
One could argue that the USB stuff which identifies itself as daX is a
completely separate peripheral driver too, but we have daX for it...For an user it is not really interesting if it is via ATA, SCSI, or
whatever, if he wants a harddisk, he wants a harddisk and normally doesFrom a personal POV, I do not care much, but from an usability POV I
don't think it's a good idea.Bye,
Alexander.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
this is awesome! do you plan to add support for the TRIM command support?
what would it take to teach FreeBSD to use the TRIM?
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
GEOM knows the BIO_DELETE command, which is supposed to do what TRIM
does but is currently mostly unused. I think tree things need to happen
to use TRIM effectively:1) Investigate the conditions of use of TRIM - e.g. must TRIM be applied
at special alignment on media (i.e. flash block-size?), because
BIO_DELETE has no alignment requirements.2) Translate BIO_DELETE into appropriate IO command(s) in the driver(s)
3) Make file systems use BIO_DELETE (or whatever comes from it). AFAIK
it has been started for UFS, I have no idea about ZFS.3a) See if existing GEOM classes support BIO_DELETE properly (i.e.
passthrough to the lower classes)_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I haven't looked on it yet, but I think should be really easy from disk
driver point ov view. After last firmware update, my SSD should now
support TRIM, so I will look on it closer, as time permit.The main question is to implement BIO_DELETE in filesystems code. I have
seen in lists that UFS patches were made long time ago, but they are
still not committed. Now practically the only BIO_DELETE consumer is
newfs with -E option, which I have successfully used with mmcsd driver.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Hi Alexander,
Thanks a lot for working on this. I can't wait to see this code land
into the tree somewhere in the future. Have you folks thought about a
way to integrate this? Are the CAM changes going to be committed to the
tree on beforehand?Yours,
--=20
Ed Schouten <ed@80386.nl>
WWW: http://80386.nl/
We have thought about it. This patch is not very invasive. It does not
touch existing ATA code and not so much change existing CAM code. Scott
even discussed it with re@ and got permission to integrate it, if we
will be ready to do it before BETA3. So, testers are welcome, also SCSI
and umass ones, to be completely sure that we are not breaking any
existing functionality.--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Rafael J. Wysocki | [Bug #11204] Commit 76a2a6ee8a0660a29127f05989ac59ae1ce865fa breaks PXA270 (at lea... |
git: | |
| Gerrit Renker | [PATCH 34/37] dccp: Auto-load (when supported) CCID plugins for negotiation |
| Corey Minyard | [PATCH 3/3] Convert the UDP hash lock to RCU |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
