Re: Anyone working on the Marvell 88se64xx sas/sata chip driver?
On 15.11.2014 21:08, Bill Pechter wrote: > I've got a really nice Lenovo D20 that I need to share between > FreeBSD/Linux and Windows Server 2012 for some testing. > > I've got the Marvell driver up on Linux and Windows but it appears that I > have to move the SATA drives to the Intel SATA chips if I want to share > between FreeBSD/Linux/Windows. > > I hate to have to rebuild this all... Is there a test driver for the > 88se63xx/64xx drivers available in 10.1 or -stable? I'm afraid there is no such one. That family of controllers is neither mvs(4) nor ahci(4). It is completely separate design, providing quite low-level interface to SAS ports (that means that support for wide ports, expanders, target mapping, etc. should be done manually inside the driver). I had a wish to implement it at some point, but had no documentation. Now I have some documentation and even some (old now) hardware, but not sure how much widespread/applicable are those chips now. Complains like that happen not so often and I am not sure I want to spend few months of work on discontinued hardware. Has Marvell released anything new from that line, like 12Gbps SAS, that could be interesting? -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Are there still cd(4) changers?
Hi. Does anybody still use CD changer supported by cd(4) driver in FreeBSD, not ch(4)? Those changers have single drive, but report multiple LUNs with one LUN per CD slot. One device like I have in my table is 17 year old. All devices I can find with Google or eBay are CD, not even DVD, and are parallel ATA or parallel SCSI. Is there anything relevant still on market? I am asking this because code supporting that hardware in FreeBSD is heavily broken in head and stable/10 branches for several months now, and fix seems to be non-trivial. So my question is: does it worth bothering with rewrite, or we can just drop ~20KB of unused and quite complicated code? Dropping code does not mean those devices will be unusable, but only that _simultaneous_ access to different LUNs will become much slower due to inefficient scheduling of disk loads/unloads. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Reset Problem with SATA Port Multiplier
On 28.07.2013 03:08, Dieter BSD wrote: Bob writes: After a few hours of a database-like workload A faster way to trigger the problem would be useful. We're actually more interested in archive type workloads than this database workload and we have not observed the problem with an archive workload. So perhaps something about the timing triggers the bug? Sam writes if you have a script or a way to build a kernel to help debug this I will run it if you post it here... I have the same issue on a 3 port multiplier using -HEAD Can you share the make and model of this 3 port multiplier? If it is happening with more than one model of pm, it is more likely some generic problem, rather than triggering some model-specific quirk/bug. Has anyone seen this problem with an older OS release? (say 7.x or 8.x?) If the problem was introduced recently, we might be able to find it by looking at what changed in the source code. I haven't seen the problem with 8.2 or earlier. Looks like a verbose boot will give a little more info. But I suspect that adding more log(9) statements will be needed. Unless mav has a better idea? There are two sides of this problem: original issue and imperfect error recovery. First one is a big question. I can't say what is actually going on there that causes the problem. Just recently I've made one more attempt to get some documentation on SATA controllers from Marvell. But even after signing NDA process again stopped since I am neither buying thousands of their chips as vendor nor they are supporting for end-users. The alike situation is with other vendors. What's about the recovery, problem is that neither CAM nor mvs driver now track faulty status of the devices. So if some disk's firmware stuck and start causing infinite timeouts, that will substantially interrupt operation of other devices sharing that SATA port. Probably the mechanism of dropping faulty device could be improved somehow. What is about SAS, mentioned here -- that is quite different more expensive market. And even while protocols are much more sophisticated and hardware, firmware and software there are much better tested, there also situations happen sometimes when single misbehaving device may put down whole fabric. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Rocket Raid 622 in AHCI mode
On 28.05.2013 20:46, Mike Tancsa wrote: On 5/28/2013 12:33 PM, Alexander Motin wrote: # Any ideas on how to fix this controller to make it work better with ZFS and get better speeds ? Good question. One of several about these Marvell controllers, caused by lack of any public documentation. :( OK, thanks for responding. I figured if anyone knew definitively, it would be you :) I will just use the 3124 for now. It has been pretty reliably for me to make these large storage appliances. Other than the 3124, do you recommend anything else ? I want to put together another 20TB storage appliance. Faster is nicer, but cost is a constraining factor. Aside from these Marvell's I don't know any other AHCI HBA with FBS support. And HBAs without FBS are by definition are not suitable for simultaneous access to devices on PMP. Aside from AHCI, older Marvell's supported by mvs(4) like 88SX7042 can do FBS, but IIRC they are also not very fast and I don't trues them much either. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Rocket Raid 622 in AHCI mode
On 28.05.2013 16:38, Mike Tancsa wrote: I picked up an external PMP/Cage/RR6622 combo that claims to be Sata III. From the BIOS, the card implies it does indeed see the SATA III drives Pic of the BIOS here http://tancsa.com/rr.jpg I am not sure what does that number on photo mean, but I haven't even heard about any SATA3.x port multipliers yet. SiI3826 (as I can identify it from below) is not a new one and AFAIK only SATA 2.x. ahci0: port 0x4090-0x4097,0x4080-0x4083,0x4070-0x4077,0x4060-0x4063,0x4050-0x405f mem 0xc243-0xc24307ff irq 16 at device 0.0 on pci1 ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 Yes, "2 6Gbps ports, Port Multiplier supported with FBS" is what this line of Marvell chip formally reports and it sounds great. I've tested it quite a long ago, but IIRC while it was fast enough with direct disk connection, it was quite slow working with port multipliers. However, performance is abysmal and worse than using a regular sii based SATA II card. SiI3124 still was not beaten. It sees the PMP and cage as pmp0 at ahcich1 bus 0 scbus1 target 15 lun 0 pmp0: ATA-0 device pmp0: 300.000MB/s transfers (SATA 2.x, NONE, PIO 8192bytes) pmp0: 5 fan-out ports ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich1 bus 0 scbus1 target 1 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad7 ada3 at ahcich1 bus 0 scbus1 target 2 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada4 at ahcich1 bus 0 scbus1 target 3 lun 0 ada4: ATA-8 SATA 3.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5 at ahcich1 bus 0 scbus1 target 4 lun 0 ada5: ATA-8 SATA 3.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: Command Queueing enabled ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) # camcontrol devlist at scbus1 target 0 lun 0 (ada1,pass2) at scbus1 target 1 lun 0 (ada2,pass3) at scbus1 target 2 lun 0 (ada3,pass4) at scbus1 target 3 lun 0 (ada4,pass5) at scbus1 target 4 lun 0 (ada5,pass6) at scbus1 target 15 lun 0 (pmp0,pass1) at scbus2 target 0 lun 0 (pass0,ada0) Writing to the individual disks seems fine, but when all the disks are engaged, its very slow # zpool create -f tank raidz ada1 ada2 ada3 ada4 ada5 # dd if=/dev/zero of=/tank/test1 bs=2048k count=10 10+0 records in 10+0 records out 20971520 bytes transferred in 60.370025 secs (347383 bytes/sec) # zpool export tank; zpool import tank # dd if=/tank/test1 of=/dev/null bs=2048k 10+0 records in 10+0 records out 20971520 bytes transferred in 7.678915 secs (2731052 bytes/sec) ZFS in RAIDZ does simultaneous I/O to all disks, that is probably the most complicated case. Though I can hardly believe it can be that slow. Even without any FBS support in HBA I would expected at least 100MB/s / 5 = 20MB/s, but definitely not 350KB/s. # for i in `jot 5 1`; do dd if=/dev/ada$i of=/dev/null count=200 bs=2048k;done 200+0 records in 200+0 records out 419430400 bytes transferred in 3.211699 secs (130594554 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 3.034111 secs (138238327 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 3.639701 secs (115237601 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 2.841386 secs (147614716 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 3.020611 secs (138856154 bytes/sec) # # for i in `jot 5 1`; do dd if=/dev/zero of=/dev/ada$i count=200 bs=2048k;done 200+0 records in 200+0 records out 419430400 bytes transferred in 3.285333 secs (127667539 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 3.043410 secs (137815945 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 3.611478 secs (116138154 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 2.830386 secs (148188414 bytes/sec) 200+0 records in 200+0 records out 419430400 bytes transferred in 2.987366 secs (140401412 bytes/sec) # Any ideas on how to fix this controller to make it work better with ZFS and get better speeds ? Good question. One of several about these Marvell controllers, caused by lack of any public documentation. :(
Re: FreeBSD compatible PCI-E SSD drives
Vlad Galu wrote: > Any particular $subj you can recommend? I've been looking at OCZ's > RevoDrive X2 for a while, but the FreeBSD is quite unclear. As far as I know, that OCZ RevoDrive X2 is just SiI3124 4-port SATA controller combined with 4 SATA SSDs in RAID0. If I am right, that controller should be well supported by siis(4) driver. Silicon Image RAIDs supported by raid(8) and with some luck (if OCZ haven't reinvented the wheel) should also work. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: ahci.ko / geom_mirror / zfs hangs up system when one of HDDs fauilts.
Lev Serebryakov wrote:
> You wrote 24 июля 2011 г., 2:29:12:
>>> I'm not sure, that it is possible to update firmware on these
>>> drives. And MoBo BIOS looks like latest one.
>> Then I have no idea what to do about the cause of errors. What's about
>> consequences, I've tried to simulate alike problem (device detected, but
>> doesn't respond). Recovery (dropping failed device) took a lot of time,
>> but finally (after about 10 minutes) it succeeded and ZFS continued
>> operation without that drive. After that I've just committed one patch
>> to the HEAD and sent another one to freebsd-scsi@ for review. That, I
>> hope, should significantly (down to 1-2 minutes) speedup that process.
>
>> How long have you waited before and after making that screenshot?
> About one and half hour -- server stopped to respond on
> HTTP/SSH/SMTP/POP3 (but responded to pings and traceroute), I've
> requested access to remote console, tech support provide such access
> and all this process takes more than hour.
Not sure it is related to your case, but attached patch fixes timeout
handling problem I've found while testing Marvell 88SE912x controller.
In my test scenario without this patch some commands could stuck inside
controller infinitely.
--
Alexander Motin
Index: dev/ahci/ahci.c
===
--- dev/ahci/ahci.c (revision 224305)
+++ dev/ahci/ahci.c (working copy)
@@ -1879,12 +1879,13 @@
device_printf(dev, "Poll timeout on slot %d port %d\n",
slot->slot, port);
device_printf(dev, "is %08x cs %08x ss %08x "
- "rs %08x tfd %02x serr %08x\n",
+ "rs %08x tfd %02x serr %08x cmd %08x\n",
ATA_INL(ch->r_mem, AHCI_P_IS),
ATA_INL(ch->r_mem, AHCI_P_CI),
ATA_INL(ch->r_mem, AHCI_P_SACT), ch->rslots,
ATA_INL(ch->r_mem, AHCI_P_TFD),
- ATA_INL(ch->r_mem, AHCI_P_SERR));
+ ATA_INL(ch->r_mem, AHCI_P_SERR),
+ ATA_INL(ch->r_mem, AHCI_P_CMD));
et = AHCI_ERR_TIMEOUT;
}
@@ -1960,8 +1961,12 @@
ccs = (ATA_INL(ch->r_mem, AHCI_P_CMD) & AHCI_P_CMD_CCS_MASK)
>> AHCI_P_CMD_CCS_SHIFT;
if ((sstatus & (1 << slot->slot)) != 0 || ccs == slot->slot ||
- ch->fbs_enabled)
+ ch->fbs_enabled || ch->wrongccs)
slot->state = AHCI_SLOT_EXECUTING;
+ else if ((ch->rslots & (1 << ccs)) == 0) {
+ ch->wrongccs = 1;
+ slot->state = AHCI_SLOT_EXECUTING;
+ }
callout_reset(&slot->timeout,
(int)slot->ccb->ccb_h.timeout * hz / 2000,
@@ -1971,10 +1976,12 @@
device_printf(dev, "Timeout on slot %d port %d\n",
slot->slot, slot->ccb->ccb_h.target_id & 0x0f);
- device_printf(dev, "is %08x cs %08x ss %08x rs %08x tfd %02x serr
%08x\n",
+ device_printf(dev, "is %08x cs %08x ss %08x rs %08x tfd %02x "
+ "serr %08x cmd %08x\n",
ATA_INL(ch->r_mem, AHCI_P_IS), ATA_INL(ch->r_mem, AHCI_P_CI),
ATA_INL(ch->r_mem, AHCI_P_SACT), ch->rslots,
- ATA_INL(ch->r_mem, AHCI_P_TFD), ATA_INL(ch->r_mem, AHCI_P_SERR));
+ ATA_INL(ch->r_mem, AHCI_P_TFD), ATA_INL(ch->r_mem, AHCI_P_SERR),
+ ATA_INL(ch->r_mem, AHCI_P_CMD));
/* Handle frozen command. */
if (ch->frozen) {
@@ -1987,7 +1994,7 @@
}
xpt_done(fccb);
}
- if (!ch->fbs_enabled) {
+ if (!ch->fbs_enabled && !ch->wrongccs) {
/* Without FBS we know real timeout source. */
ch->fatalerr = 1;
/* Handle command with timeout. */
@@ -2585,6 +2592,7 @@
xpt_release_simq(ch->sim, TRUE);
ch->eslots = 0;
ch->toslots = 0;
+ ch->wrongccs = 0;
ch->fatalerr = 0;
/* Tell the XPT about the event */
xpt_async(AC_BUS_RESET, ch->path, NULL);
Index: dev/ahci/ahci.h
===
--- dev/ahci/ahci.h (revision 224305)
+++ dev/ahci/ahci.h (working copy)
@@ -426,6 +426,7 @@
int resetting; /* Hard-reset in progress. */
int resetpolldiv; /* Hard-reset poll div
Re: ahci.ko / geom_mirror / zfs hangs up system when one of HDDs fauilts.
Lev Serebryakov wrote: > Hello, Alexander. > You wrote 22 июля 2011 г., 20:22:46: > >>> Screenshot of LARA console in such case is attached. >> Kernel messages look like if controller or device stuck, unable to >> complete some command and can't recover from that condition even after >> device hard reset. I don't see what driver can do about it, except being >> more aggressive in dropping faulty device after several consecutive >> timeouts. If that is not a wanted way out, start from updating card BIOS >> and devices firmware. > It is very common hardware: ICH10 on MS-7522 (MSI X58 Platinum) motherboard: > > ahci0: port > 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem > 0xf9ffa000-0xf9ffa7ff irq 19 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported > > And Samsung F3 drive: > > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > > I'm not sure, that it is possible to update firmware on these > drives. And MoBo BIOS looks like latest one. Then I have no idea what to do about the cause of errors. What's about consequences, I've tried to simulate alike problem (device detected, but doesn't respond). Recovery (dropping failed device) took a lot of time, but finally (after about 10 minutes) it succeeded and ZFS continued operation without that drive. After that I've just committed one patch to the HEAD and sent another one to freebsd-scsi@ for review. That, I hope, should significantly (down to 1-2 minutes) speedup that process. How long have you waited before and after making that screenshot? -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: ahci.ko / geom_mirror / zfs hangs up system when one of HDDs fauilts.
Lev Serebryakov wrote: > I've have two identical live locks when HDD becomes broken on > 8.2-STABLE system with two SATA HDDs withgmirror and ZFS on them. > > It is Hetzner-based server, so only access I have is LARA console, > but symptoms are identical in both cases: HDD becomes bad, ahci.ko > complains about timeouts, and after that server stops to respond on > high-level access attempts (ssh/HTTP/SMTP), but can be pinged both > with IPv4 and IPv6 addresses. > > HDDs are identical, and they are splitted into several (BSD)partions. > Some partitions are mirrired with geom_mirror and one pair of > partitions are added to (mirrored) ZFS pool like this (I proved output > on rebooted one-HDD-only system, but, I think, it is clear how it > looks when both HDDs are Ok): > > Screenshot of LARA console in such case is attached. Kernel messages look like if controller or device stuck, unable to complete some command and can't recover from that condition even after device hard reset. I don't see what driver can do about it, except being more aggressive in dropping faulty device after several consecutive timeouts. If that is not a wanted way out, start from updating card BIOS and devices firmware. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
USB HID support for xf86-input-mouse (including digitizers and touchscreens)
Hi. Looking on xf86-input-mouse, I've found that it includes some code to support USB HID pointing devices directly using libusbhid library. But that code seemed like newer worked (at least on FreeBSD) and is quite limited. Same time that approach would allow us to override different limitation, now imposed by sysmouse protocol. For example, to support absolute coordinates, pressure force, multiple touches, etc. I've made a patch, rewriting it to support wide range of pointing devices. I've tested it with few mouses, digitizer and two touchscreens. To use it, you may: 1. Update installed packages to have x11-drivers/xf86-input-mouse of the version 1.6.0. 2. Download patch http://people.freebsd.org/~mav/patch-zz-input-mouse8 and put it into /usr/ports/x11-drivers/xf86-input-mouse/files 3. Rebuild and reinstall the driver. 4. Release the pointing device of ums driver, if needed (build kernel without ums). Device should be reported as uhidX. 5. Add to Xorg configuration: Section "InputDevice" Identifier "Panel1" Driver "mouse" Option "Protocol" "usb" Option "Device" "/dev/uhidX" EndSection ... Section "ServerLayout" ... InputDevice "Panel1" ... EndSection Some HID devices provide several first-level logical collections (subdevices), supported by the driver. In that case several of above devices should be added with different Identifier but same Device. For example, my Asus T101MT laptop's touchscreen has two usable logical collections: multi-touch touchscreen and it's mouse emulation. 6. In different operation modes device may report events via different of these collections. Due to present uhid(4) driver API limitation, it is impossible for the driver to switch them now. The only way now is to switch them directly via libusb with command line usbconfig -u 1 -a 3 do_request 0x21 0x09 0x0305 0x 0x0002 0x05 0x0Z where Z is value from 0 to 2, where 0 is a mouse emulation, 1 is a single-touch touch-screen and 2 -- native mode. And 05 is a feature report ID that includes the switch for my touchscreen. 7. Due to missing multitouch support in present Xorg (XInput 2.1 required), multiple touches are now mapped to right button press now. As any other button, it can be mapped to mouse wheel emulation by adding into the device section: Option "EmulateWheel" "on" Option "EmulateWheelButton" "3" <- right button Option "EmulateWheelInertia" "500" <- this may be tuned Option "XAxisMapping" "7 6" Option "YAxisMapping" "5 4" It allows to scroll with two fingers. 8. I was experimenting with a hack, mapping multiple touches into different pointers, using Multi-Pointer X technology, added from present Xinput 2.0. I indeed successfully had several separate pointers on screen, so multitouch touch screen itself is working fine. But I haven't found any practical use for it. If somebody heard about any application that has some useful support for MPX -- tell me please. I am not sure it will be the permanent solution and what are the chances to commit it upstream now. I am thinking about further changes at kernel level to implement it other way. But for existing systems I think it is an acceptable way to go. On any problems, send me Xorg.0.log and `usbhidctl -f /dev/uhidX -r` outputs. Thank you. Comments welcome. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
SES/SAF-TE + SATA == SEMB!
Hi. As probably not many know, SATA specification defines the way to talk to SES/SAF-TE enclosures -- Serial ATA Enclosure Management Bridge (SEMB). It can be either separate device or built-in to SATA Port Multiplier. I know at leat two models of Port Multipliers including SEMB and having I2C interfaces to talk to SEP (backplane): SiI3726 and SiI4726. Unluckily such combination of hardware is not widely spread (backplanes are rarely used in desktops, while PMPs are rarely used in servers), but finally I've built such setup! I've connected SuperMicro SAS815TQ backplane to the SiI3726 multiplier with I2C cable and it works like a charm! I've made a patch for HEAD to support it. It adds SEMB devices support to the ATA/SATA XPT probe code, some glue to handle one more ATA-based command protocol and some changes to ses(4) driver to teach it talk to such devices: http://people.freebsd.org/~mav/semb.patch As result I've got: %dmesg |grep ses0 ses0 at ahcich8 bus 0 scbus8 target 5 lun 0 ses0: SEMB S-E-S 2.00 device ses0: Serial Number 50030481 ses0: 150.000MB/s transfers (SATA 1.x, NONE, PIO 8192bytes) ses0: SEMB SES Device ses0: GenCode 0 0 Subenclosures ses0: SubEnclosure ID 0, 4 Types With this ID, Enclosure Length 36 ses0: WWN: 3530303330343831 ses0: Type Desc[0]: Type 0x17, MaxElt 4, In Subenc 0, Text Length 0 ses0: Type Desc[1]: Type 0x4, MaxElt 1, In Subenc 0, Text Length 0 ses0: Type Desc[2]: Type 0xe, MaxElt 1, In Subenc 0, Text Length 0 ses0: Type Desc[3]: Type 0x6, MaxElt 1, In Subenc 0, Text Length 0 %camcontrol devlist at scbus8 target 0 lun 0 (ada0,pass1) at scbus8 target 1 lun 0 (ada1,pass2) at scbus8 target 2 lun 0 (pass5,ada2) at scbus8 target 3 lun 0 (pass6,ada3) at scbus8 target 5 lun 0 (ses0,pass3) at scbus8 target 15 lun 0 (pass4,pmp0) %getencstat -v /dev/ses0 /dev/ses0: Enclosure Status Element 0x0: Array device OK (Status=ok (bytes=0x11 0x00 0x00 0x00)) Element 0x1: Array device OK (Status=ok (bytes=0x11 0x00 0x00 0x00)) Element 0x2: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x3: Array device OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x4: Temperature sensors OK (Status=ok (bytes=0x01 0x00 0x32 0x00)) Element 0x5: Enclosure OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Element 0x6: Audible alarm OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) YAY! So now three questions: 1. Does anybody else have alike hardware and wish to test it? 2. Patch reviews are welcome. 3. Is there any software except share/examples/ses working with ses(4) and/or some good use practices? -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: SES/SAF-TE + SATA == SEMB!
Hans Petter Selasky wrote: > On Friday 27 May 2011 09:00:51 Alexander Motin wrote: >> YAY! >> >> So now three questions: >> 1. Does anybody else have alike hardware and wish to test it? >> 2. Patch reviews are welcome. >> 3. Is there any software except share/examples/ses working with ses(4) >> and/or some good use practices? > > Does it work with USB? SEMB is ATA-specific. I've never heard about SES/SAF-TE on USB, but I think more likely it will be reported as usual SCSI Enclosure Services device -- there is no need to invent something new. Technically for ATA it also could be made as regular ATAPI (SCSI) device, but for some reason it was made in custom way. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Advanced disk format at WD20EARS: what should "camcontrol identify" show?
Hi. On 04.04.2011 09:10, Lev Serebryakov wrote: I'm replacing old WD500AAKS HDDs in my (software) RAID5 with new WD20EARS, which are advanced format. And speed is terrible. RAID5 rebuilding shows about 8MiB/s (55MiB/s is typical speed for old AAKSes)... I'm affraid, that my HDD is in some strange mode with 512 byte sectors emulation: blob# camcontrol identify /dev/ada5 pass5: ATA-8 SATA 2.x device pass5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model WDC WD20EARS-00MVWB0 firmware revision 51.0AB51 serial number WD-WMAZA2743249 WWN 50014ee6ab72f596 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 3907029168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Should "camcontrol identify" shows "physical 4096" in "sector size"? Some Alexander Motin's posts to mailing lists says "yes", but I can not find what should I think (do) if it doesn't. Unluckily present 4K driver don't usually honor specification in part of reporting physical sector sizes. I haven't seen supporting ones myself actually. So I wouldn't trust those 512/512/0 numbers. It is 8-STABLE (after 8.2-RELEASE) system. RAID stripes are 128KiB, and RAID is built from whole drives (no partitions), so, write requests should not be misaligned. At least first 4K WD disks had a jumper to add offset of 63 sectors. Make sure that you don't have one set. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Sil 3726 PortMultiplier Failed
Hi. Mickaël Maillot wrote: > i have an external e-sata enclose: > http://www.istarusa.com/storage/esata/iage1020espm.aspx > composed by: 2 x Sil 3726 on a SiI3132 PCI-Express card. > > i plugged 2 eSATA cables and 6 x 2 To disk. > > http://forums.freebsd.org/showthread.php?t=9353 > > i tried: 9-CURRENT november snapshot with ahci and siis > > siisch0: Timeout on slot 30 > siisch0: siis_timeout is 0004 ss 4000 rs 4000 es > sts 801e2000 serr > siisch1: Timeout on slot 30 > siisch1: siis_timeout is 0004 ss 4000 rs 4000 es > sts 801e serr > siisch0: Timeout on slot 30 > siisch0: siis_timeout is 0004 ss 4000 rs 4000 es > sts 801e2000 serr > siisch1: Timeout on slot 30 > siisch1: siis_timeout is 0004 ss 4000 rs 4000 es > sts 801e serr > siisch1: Timeout on slot 30 > siisch1: siis_timeout is 0004 ss 4000 rs 4000 es > sts 801e serr > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > siisch1: Timeout on slot 30 > siisch1: siis_timeout is 0004 ss 4000 rs 4000 es > sts 801e serr > > > full dmesg: > http://fneu.fr/freebsd/dmesg.freebsd9.verbose.log > http://fneu.fr/freebsd/dmesg.freebsd9.log > > with 8-STABLE and SiI 3726 directly on motherboard: > > ahcich0: Poll timeout on slot 0 > ahcich0: is cs 0001 ss rs 0001 tfd 1d0 serr > (aprobe0:ahcich0:0:15:0): Command timed out > (aprobe0:ahcich0:0:15:0): Error 5, Retries exhausted > ahcich0: Poll timeout on slot 0 > ahcich0: is cs 0001 ss rs 0001 tfd 1d0 serr > (aprobe0:ahcich0:0:0:0): Command timed out > (aprobe0:ahcich0:0:0:0): Error 5, Retries exhausted > > dmesg: > http://fneu.fr/freebsd/dmesg.verbose.siis.log As I can see, timeouts starting very early: in first case at Port Multiplier probing, in second - even earlier - at soft reset. It makes me think that there could be some hardware problem. Alike configurations working fine for many people. Have you tried to attach some disks to the controllers directly (if there are internal connectors or you have respective external cables)? Have you tried other (shorter/better) eSATA cables? Not all eSATA cables I have tested were working fine with all controllers, especially at higher speeds. You may try to limit speed to 1.5Gbps with loader tunable hint.siisch.X.sata_rev. Have you tried this enclosure/cables with any other controller/OS/...? PS: If transfer speed is important to you - I would recommend to replace SiI3132 controller with SiI3124. Even though it is older - board with good PCIe x4/x8 bridge can be much faster. If still stay with SiI3132 - I would recommend to use separate controller for each Port Multiplier, if possible. Even except that SiI3132 is not fast by itself, single PCIe x1 bus used by it is insufficient for two SATA 3Gbps ports. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: siis(4) questions
Dieter wrote: > The siis(4) man page promises a ada(4) man page, but > I can't find it. Even tried the online man page tool. > > dmesg says: > > ada0 at siisch0 bus 0 target 0 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing enabled Looking on this you are probably using 8.0-RELEASE or quite old 8-STABLE. Try to update your system. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: SATA regression with 7.2
Andrea Venturoli wrote: > I've got a box with a VIA VT8251 chipset and a single SATA HD, running > 6.3/i386. > I'm trying to upgrade it to 7.2, but, when booting with the new kernel, > it won't detect any HD. > In my BIOS I can set the controller to SATA, RAID or AHCI, but that > doesn't matter. > > Here's what I see when booting 6.3: > > atapci0: port > 0xe880-0xe887,0xe800-0xe803,0xe480-0xe487,0xe400-0xe403,0xe080-0xe08f > mem 0xfebfec00-0xfebfefff irq 21 at device 15.0 on pci0 > atapci0: AHCI Version 01.00 controller with 4 ports detected > ata2: on atapci0 > ata3: on atapci0 > ata4: on atapci0 > ata5: on atapci0 > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 > ata0: on atapci1 > ata1: on atapci1 > ... > ad4: 152627MB at ata2-master SATA300 > Trying to mount root from ufs:/dev/ad4s1a > > On 7.2 the output is roughly the same (I couldn't save it), but it won't > find ad4 and prompt me for a boot device (with none available). To get more info you may try to boot with verbose kernel messages enabled. Also as soon as you are updating, I would suggest you to try new 7.3, or even better 8-STABLE. 8-STABLE includes significant changes in ATA subsystem, including completely new AHCI driver ahci(4). -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Marvell MV88SX6081 on FreeBSD 8.0-RELEASE
Stephane LAPIE wrote: > Dieter wrote: >> In message <4b13159d.9010...@darkbsd.org>, Stephane LAPIE writes: >> And there are these, which you didn't mention: >>> ad1: FAILURE - SET_MULTI status=3D51 error=3D4 >>> ad12: FAILURE - SET_MULTI status=3D51 error=3D4 >> (No, I don't know what that means, sorry.) > > Ah, actually I do have an idea as to what these are about : These two > disks are SSDs I'm using in my ZFS pool as cache devices. So I guess > this is the kind of error that says "I tried to use an access mode this > device was not designed for". It is probably result of bug in ata(4) code. It was fixed recently by r199749. It is not critical when drive operates in DMA mode. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Hardware Support for new MB
Oliver Lehmann wrote: > I wonder if FreeBSD supports > > Audio: > - ALC690 (ASRock) > - ALC88S / ALC889 (MSI) > > SATA > - ICH10R Southbridge > > I guess since the ICH10R also can do AHCI this is at least supported by > the new (and old) ahci driver. It is supported by both old ata(4) drives, and new ahci(4). I've recently tested it in my lab. > But what about sound? All Realtek HDA codecs are supported fine. There can be some surprises from motherboard vendor, but usually they work out of the box. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: PCIe-x1 SATA controllers (was: Re: Adaptec 1405 on FreeBSD )
Dieter wrote: >>From what I can see, FreeBSD does not support the Marvell 88SE61xx > SATA controllers? > > For example, the SATA2-PCIE1x12 has 4 SATA ports + 1 PATA channel, > for US$30.13 > http://www.span.com/product_info.php?cPath=24_714_2502&products_id=16957 > There is a similar SATA2-PCIE1X11 board with all ports internal. > > http://en.wikipedia.org/wiki/List_of_Marvell_Technology_Group_chipsets > points to a patch for OpenBSD: > http://www.webservertalk.com/message2133676.html > and apparently penguinix supports them. I have merged support for 88SE61xx SATA to 8-STABLE last days. I have no plans to merge it lower. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Adaptec 1405 on FreeBSD
Dieter wrote: > In message <4b0176e7.7080...@freebsd.org>, Alexander Motin writes: >>>>> - SiI3124-based - fast and functional. It is actually PCI-X one, but >>>>> there are many boards with built-in PCIe bridges. >>> Do any of these fit in a x1 slot? >> I was surprised, but yes. > > My google-fu fails me. Any make/model, URLs, or keywords? Syba PCI Express SATA II 4 x Ports RAID Controller Card SY-PEX40008 http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8&s=electronics&qid=1258452902&sr=1-22 >> And as expected, bus limits it performance >> badly. But it is still works much faster then 3132 at the same bus. > > Hmmm, I must not have tested both disks at once before on the 3132: > > One at a time: > >dd if=/dev/ad18 bs=1m count=1000 of=/dev/null >1048576000 bytes transferred in 8.807009 secs (119061534 bytes/sec) > >dd if=/dev/ad20 bs=1m count=1000 of=/dev/null >1048576000 bytes transferred in 8.800526 secs (119149243 bytes/sec) > > Two at once: > >dd if=/dev/ad18 bs=1m count=1000 of=/dev/null & dd if=/dev/ad20 bs=1m > count=1000 of=/dev/null >1048576000 bytes transferred in 13.766050 secs (76171160 bytes/sec) >1048576000 bytes transferred in 13.799268 secs (75987799 bytes/sec) > > so 152 MB/s total rather than the expected ~238. PCIe x1 slot is supposed to > be good for 250 MB/s, so it ought to be able to max out both disks at once, > or at least get close. I have close numbers. 250MB/s is actually performance of the physical level. Logical level also creates overhead of somewhere about 30-40 bytes per transfer. As soon as most of desktop chipsets limited with 128bytes transfers, it also shouldn't be forgotten. The interesting fact I have seen yesterday, SiI3132 is able to read 150MB/s, but write 170MB/s. I am not PCIe expert, but looks like transfer capabilities could be asymmetric. Also, and as soon as PCIe is duplex, I've also seen 110MB/s read from one drive, plus 100MB/s write to another, running at the same time. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Adaptec 1405 on FreeBSD
Dieter wrote: >>> - SiI3124-based - fast and functional. It is actually PCI-X one, but >>> there are many boards with built-in PCIe bridges. > > Do any of these fit in a x1 slot? I was surprised, but yes. And as expected, bus limits it performance badly. But it is still works much faster then 3132 at the same bus. >>> - First generation of SiI chips (SiI3114). They are quite old - SATA1 >>> and PCI, but they are long-time supported and they take all possible >>> from PCI bus, and in 66MHz PCI-X slot can give even more. But I have >>> heard some negative comments about them. > > I have a 3512 card in a NetBSD box and it is slow but otherwise works fine. > I have read various complaints about 1st gen SiL chips with FreeBSD, > so do your homework before getting one for a FreeBSD box. Perhaps the > new drivers in 8.0 will fix these problems? I haven't seen original chip errata to be sure, but ata(4) driver now includes some workarounds for this chip. Same time, there is no such quirks for 3114. > 7.x doesn't support NCQ either. :-( I'm waiting impatiently for > 8.0 to come out. as I need NCQ. Speaking of which, I've read that > some controller/disk combinations have problems with NCQ? Is there > a way to turn NCQ on/off on a per-disk basis? It is already possible in HEAD to write quirks for specific device models and firmware revisions. Also to control NCQ usage. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Adaptec 1405 on FreeBSD
Patrick Proniewski wrote: > On 13 nov. 2009, at 21:03, Alexander Motin wrote: > >> Alexander Motin wrote: >>> Patrick Proniewski wrote: >>>> Any PCIe card suggestion is appreciated. >>> >>> FreeBSD 6.x is already legacy. If you are building something new, you >>> should look forward. What I have tested: >>> - SiI3124-based - fast and functional. It is actually PCI-X one, but >>> there are many boards with built-in PCIe bridges. >>> - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe x1 >> >> Oops, I meant Adaptec 1220SA here ^^^. >> >>> alternative (max 150MB/s per card). These two better supported with new >>> siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't >>> looked lower. >>> - First generation of SiI chips (SiI3114). They are quite old - SATA1 >>> and PCI, but they are long-time supported and they take all possible >>> from PCI bus, and in 66MHz PCI-X slot can give even more. But I have >>> heard some negative comments about them. >>> - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, supported >>> in 7.x and probably before. Adaptec 1420SA is from the same series. But >>> they are PCI-X (tested it in PCI). >>> - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic >>> support recently to 8-STABLE. Not supported before. >>> - most of chipset-integrated controllers (Intel, NVidia) are really not >>> bad when working in AHCI mode (they are not limited by bus speed). >>> - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and >>> not so bad, but limited by bus speed at about 180MB/s per card. > > I've just found this: > <http://catalog.belkin.com/IWCatProductPage.process?Product_Id=249090#> > > Does anybody has given this card a try? > Unfortunately I can't find the brand of the chip they are using… Looking on picture, I would surmise it can be SiI3132, but price is twice bigger then I would expect from that chip. SiI3132-based ST-Lab A-410 controller in my city costs $29. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Adaptec 1405 on FreeBSD
Patrick Proniewski wrote: > PCI-x and PCI are not an option for me. > In fact, everything comes from the fact my system behaves strangely from > time to time. > Long explanation here: > http://lists.freebsd.org/pipermail/freebsd-hardware/2007-June/004541.html > > This problem disappeared for a long time, but came back just today. My > wifi card is PCI, and according to the motherboard setup, PCI bus is on > the same controller as on board SATA (with PCI-X too). The only slots > that sit on a different chip are the two PCIe. I think that if I could > move my HDs on the PCIe buses, it might resolve my problem. Even if it > does solve this issue, it'll give me SATA II, in replacement of SATA I > motherboard connectors. Either way, I win :) I am not sure it is productive way. There is too many assumptions. Even if it fix problems with disk, I am not sure your WiFi will work after that. Even if assume that problem is localized inside south bridge (you can't know that), there could be problems with other devices (LAN, for example). What's about changing SATA1 with SATA2 - I think you won't notice any difference. Most of disks are not so fast to congest SATA1, while other bonuses like NCQ are not supported by 6.4 any way. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Adaptec 1405 on FreeBSD
Alexander Motin wrote: > Patrick Proniewski wrote: >> Any idea about the FreeBSD support for Adaptec 1405 (ASC-1405)? > > I doubt. It is more SAS then SATA card. > >> Any PCIe card suggestion is appreciated. > > FreeBSD 6.x is already legacy. If you are building something new, you > should look forward. What I have tested: > - SiI3124-based - fast and functional. It is actually PCI-X one, but > there are many boards with built-in PCIe bridges. > - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe x1 Oops, I meant Adaptec 1220SA here ^^^. > alternative (max 150MB/s per card). These two better supported with new > siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't > looked lower. > - First generation of SiI chips (SiI3114). They are quite old - SATA1 > and PCI, but they are long-time supported and they take all possible > from PCI bus, and in 66MHz PCI-X slot can give even more. But I have > heard some negative comments about them. > - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, supported > in 7.x and probably before. Adaptec 1420SA is from the same series. But > they are PCI-X (tested it in PCI). > - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic > support recently to 8-STABLE. Not supported before. > - most of chipset-integrated controllers (Intel, NVidia) are really not > bad when working in AHCI mode (they are not limited by bus speed). > - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and > not so bad, but limited by bus speed at about 180MB/s per card. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Adaptec 1405 on FreeBSD
Patrick Proniewski wrote: > Any idea about the FreeBSD support for Adaptec 1405 (ASC-1405)? I doubt. It is more SAS then SATA card. > Any PCIe card suggestion is appreciated. FreeBSD 6.x is already legacy. If you are building something new, you should look forward. What I have tested: - SiI3124-based - fast and functional. It is actually PCI-X one, but there are many boards with built-in PCIe bridges. - two SiI3132-based (Adaptec 1420SA and many others) - as cheap PCIe x1 alternative (max 150MB/s per card). These two better supported with new siis(4) driver on 8.0, but should work on 7.x with ata(4), haven't looked lower. - First generation of SiI chips (SiI3114). They are quite old - SATA1 and PCI, but they are long-time supported and they take all possible from PCI bus, and in 66MHz PCI-X slot can give even more. But I have heard some negative comments about them. - Supermicro SAT2-MV8 on Marvell - recently tested it on 8.0, supported in 7.x and probably before. Adaptec 1420SA is from the same series. But they are PCI-X (tested it in PCI). - Adaptec 1430SA - PCIe, based on newer Marvell chip. Added basic support recently to 8-STABLE. Not supported before. - most of chipset-integrated controllers (Intel, NVidia) are really not bad when working in AHCI mode (they are not limited by bus speed). - JMicron-based PCIe x1 adapters. They are cheap, AHCI-compatible and not so bad, but limited by bus speed at about 180MB/s per card. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Generic Marvell 88SX7042 Cards
Adam Stylinski wrote: > I've been scouring through the Hardware Support list to find that > nothing under this chipset seems to be supported. Linux recently supports > this with the sata_mv module and I was wondering if there was any effort to > port a driver to BSD. I have a Rosewill RC-218 card, which is a non-raid > SATA-II Controller with 4 ports. I would like to expand my zraid with this > card. Any more information to the progress of this would be extremely > appreciated. Thanks. I've just committed basic Marvell 6042/7042 support into HEAD. Testers are welcome. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: > I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: > Alexander Motin wrote: >>> If your conditions permit, you can try to upgrade to recent HEAD to look >>> how will it go with newer code. I am periodically merging my work there >>> from Perforce. Also I am going to generate new test patch for HEAD, >>> which includes reworked PMP support, tomorrow. >> >> You can try this patch against today's HEAD: >> http://people.freebsd.org/~mav/cam-ata.20091022.patch >> > I tried the patch this morning against a fresh checkout of HEAD. > Immediately after boot only one device per PM was detected (I have two > hooked up at the moment, 5 drives on one, 1 on the other). However, > about two minutes later all of the drives showed up! I've just committed to HEAD new reset sequence for siis. Try please new HEAD with new patch and show me full results. Patch: http://people.freebsd.org/~mav/cam-ata.20091023.patch Thanks. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: > Alexander Motin wrote: >>> If your conditions permit, you can try to upgrade to recent HEAD to look >>> how will it go with newer code. I am periodically merging my work there >>> from Perforce. Also I am going to generate new test patch for HEAD, >>> which includes reworked PMP support, tomorrow. >> >> You can try this patch against today's HEAD: >> http://people.freebsd.org/~mav/cam-ata.20091022.patch >> > I tried the patch this morning against a fresh checkout of HEAD. > Immediately after boot only one device per PM was detected (I have two > hooked up at the moment, 5 drives on one, 1 on the other). However, > about two minutes later all of the drives showed up! > > camcontrol also rescans the entire bus *very* quickly now, and discovers > all changes (new/missing disks and port multipliers). > > Here's some verbose info from /var/log/messages immediately after boot: > Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 > Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is ss > 0800 rs 0800 es sts 801b2000 serr > Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms > Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms > Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... > Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms > Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... > Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout > status=0001 > Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset > found no device > Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out > Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 > Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted > Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested What was before that? Can you send me full verbose boot messages? -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: FreeBSD and SATA Port Multipliers
Alexander Motin wrote: > If your conditions permit, you can try to upgrade to recent HEAD to look > how will it go with newer code. I am periodically merging my work there > from Perforce. Also I am going to generate new test patch for HEAD, > which includes reworked PMP support, tomorrow. You can try this patch against today's HEAD: http://people.freebsd.org/~mav/cam-ata.20091022.patch -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: > Alexander Motin wrote: >> Have you tried new CAM-based ATA subsystem present in 8.x by siis(4) >> driver? Work is still in progress there, but it should work with port >> multipliers much better then previous implementation. > > Indeed, the siis(4) driver works MUCH better. However, it's still not > always detecting every drive if I fill a port multiplier with 5/5 > drives. Sometimes it boots up with 4, sometimes with 5. > > Snippet from the dmesg in my other reply: > siisch4: Timeout on slot 25 > siisch4: siis_timeout is ss 0200 rs 0200 es > sts 80192000 serr > (aprobe0:siisch4:0:1:0): SIGNATURE: > (aprobe0:siisch4:0:2:0): SIGNATURE: > (aprobe0:siisch4:0:3:0): SIGNATURE: > (aprobe0:siisch4:0:4:0): SIGNATURE: > ada0 at siisch4 bus 0 target 1 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing enabled > > siisch4 bus 0 target 0 lun 0 is missing here, due to some kind of > timeout. The drives are fine and the missing device does not follow a > specific physical drive. Lastly, using camcontrol to rescan port > multipliers and attached drives only leads to failure. Rescanning > everythign simply loses all but one drive attached to each port multiplier. As I have said, infrastructure is not finished yet, especially part of recovery from timeout state. That's why probably rescan does not solve situation. From other side, this timeout may be called by some driver issue, as it looks too repeatable. If your conditions permit, you can try to upgrade to recent HEAD to look how will it go with newer code. I am periodically merging my work there from Perforce. Also I am going to generate new test patch for HEAD, which includes reworked PMP support, tomorrow. I will put it to http://people.freebsd.org/~mav/ as usual, so you can test it. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: > I have a system running FreeBSD 8.0-RC1 that contains 3x Sil3124 PCI-E > SATA controller cards. Each card has 3x Sil3726 Port Multipliers > attached (5 slots per SATA PM). The problem is that the disks are often > not all detected by FreeBSD, even though the controller Option ROMs list > all of the installed physical disks. Which drive(s) are not detected > seems to vary with each boot. All of the port multipliers are detected > every boot, it's just the drives which aren't getting probed. > > I've tried the following patch, > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129784 , which may have > helped - it picks up 6-8 out of 9 disks, but obviously that's not > ideal. The motherboard BIOS version is current, as is the firmware for > the SATA controllers. > > Does anyone have any ideas or other patches that I may try? Have you tried new CAM-based ATA subsystem present in 8.x by siis(4) driver? Work is still in progress there, but it should work with port multipliers much better then previous implementation. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Only one sysctl node if two battery on the laptop ?
Lagrange Marc wrote:
> Why only one battery shown in sysctl and not hw.acpi.battery. number>.{life,time,...} ?
Why not? Applications that want to have full information could use acpi
interface to obtain it, just like `acpiconf -i X` does.
--
Alexander Motin
___
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Small SATA performance contest
I've just made several tests, comparing older SATA 1.x SiI3114 (32bit/66MHz PCIX), newer SATA 2.x JMicron JMB363 and SiI3132 (PCIe x1) cards and on-board ICH8 AHCI with two fast drives connected to each: Linear read with 1MB block from two drives, summary: SiI3114 in PCI 32/33 slot: 120MB/s. SiI3114 in PCIX 32/66 slot: 190MB/s. <-- near to SATA 1.x limit SiI3132 in PCIe x1 slot: 150MB/s JMB363 in PCIe x1 slot: 188MB/s ICH8 AHCI on-board: 310MB/s <-- drives limit So, faster bus can be a significant bonus even to old card. Inefficient design can kill even new bus. Same time fastest internal connections of ICH8, combined with effective design can give unique results. Linear read with 512B block: SiI3114 in PCIX 32/66 slot: 16Ktps. SiI3132 in PCIe x1 slot: 17Ktps ICH8 AHCI on-board: 17Ktps 10 streams linear reads with 512B block: SiI3114 in PCIX 32/66 slot: 10Ktps. SiI3132 in PCIe x1 slot: 25Ktps ICH8 AHCI on-board: 25Ktps But even slower newer card can win in some situations, just because of additional functionality, such as command queuing in this case. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Do we still need ATA disk CHS addressing?
M. Warner Losh wrote: > In message: <4a807bdd.6040...@freebsd.org> > Alexander Motin writes: > : Warner Losh wrote: > : > My question, and maybe I missed this earlier in the thread, is what's > : > the benefit to removing this support? How much code is saved? > : > : It is not about code size, but about code structurization. ATA(4) has > : too much cross-level relations, making it cryptic. I am trying to unroll > : some of them to simplify code. > > Can you explain a bit more here... How pervasive is it, etc... I'm > not saying this is a bad change, but I think people wishing to remove > stuff should at least have a good result that's expected... Do you really wish to touch it? Fine... CHS translation is now done on ATA controller drivers level. To work properly it needs data from drive IDENTIFY structure fetched from drive and stored on higher level. To wrap legacy ATA into CAM SIM I need to break that dependency either with dropping this functionality or reimplementing it on higher level. I would prefer first. > : > Having said all that, I think it is OK, but I'd definitely poll the > : > pc98 guys first... Just to make sure they don't need it and re-fork > : > the ata driver to get it :) > : > : GEOM has no terms of cylinders/heads/sectors, in fact it works only with > : LBA. CHS translation is only needed for drives, that have no native LBA > : support. It is not about disk partitioning or label format. It is just a > : method to linearize nonlinear address space of ancient drives. For last > : 10 years, since drives lost their classic geometry, drives are doing > : this translation on firmware level. > > GEOM does have terms of CHS when it reports the classic geometry of > the device. That can't be lost, or pc98 partitioning breaks. And the > geometry reported must be massaged too, but that's a different issue. That's completely different, and I am not going to touch it. > The disk requests can be LBA, since the driver is responsible for > changing that anyway... I don't think that there's any supported > pc98 hardware that would break, but I'm not 100% sure... > > There's also some oddities at the lowest levels for pc98 controllers, > but I don't think this change would affect that. However, like I > said, ask the pc98 guys for sure. As you could see reading above thread, I have agreed keep it in legacy ATA mode. But it looks pointless to support it in new development. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Do we still need ATA disk CHS addressing?
Warner Losh wrote: My question, and maybe I missed this earlier in the thread, is what's the benefit to removing this support? How much code is saved? It is not about code size, but about code structurization. ATA(4) has too much cross-level relations, making it cryptic. I am trying to unroll some of them to simplify code. Having said all that, I think it is OK, but I'd definitely poll the pc98 guys first... Just to make sure they don't need it and re-fork the ata driver to get it :) GEOM has no terms of cylinders/heads/sectors, in fact it works only with LBA. CHS translation is only needed for drives, that have no native LBA support. It is not about disk partitioning or label format. It is just a method to linearize nonlinear address space of ancient drives. For last 10 years, since drives lost their classic geometry, drives are doing this translation on firmware level. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Do we still need ATA disk CHS addressing?
Julian H. Stacey wrote: Julian H. Stacey wrote: Have anybody seen ATA drive without LBA support in last years? Yes What it is? Some ancient HDD or flash card? I run 20+ assorted hosts from 4.11 to 7.2 Uni & Dual proc, i386 (real 386!) to 686 & amd64, so I guess I'm A) Pretty vulnerable to legacy scare. B) A litmus tesst for a wider community of others, some with older kit, not on lists or with bleeding edge latest hardware, but will get hit when stuff eg HCS gets declared legacy=dumped. (hardware@ & arch@ are more likely mostly high enders, lower percentage of legacy hardware users I guess) Are you administering computer hardware museum? ;) I have tested all drives I have and found none requiring CHS support. Even most ancient 850MB HDD and 16MB CompactFlash card I have support LBA. I have doubts that something even older that this is still working in production and require system there to be upgraded to 8.x. If I have to pull the lid on 20/25 hosts, to check disk sticky labels, I will if I must, but could you please reccomend people syntax to run on 4 5 6 7 RELEASES to check if a host is susceptible ? (Yes I know 4 is declares dead, but I still have lots of hosts with it & I suspect quite a lot of others do, be nice to know if any of those boxes are doomed to only upgarde to 7 not 8 ) `atacontrol cap adX` can show you if LBA is supported. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Do we still need ATA disk CHS addressing?
Julian H. Stacey wrote: >> Have anybody seen ATA drive without LBA support in last years? > Yes What it is? Some ancient HDD or flash card? -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Do we still need ATA disk CHS addressing?
Ed Schouten wrote: * Takahashi Yoshihiro wrote: In article <4a7df076.4070...@freebsd.org> Alexander Motin writes: While preparing wrapping ATA(4) low-level drivers code into CAM SIM, I would like to remove CHS addressing support to make code cleaner. CHS addressing is officially declared obsoleted and replaced by LBA. Since ATA/ATAPI-6 specification (October 2001) it is even no longer documented. Have anybody seen ATA drive without LBA support in last years? Any other objections against removing it? PC98 uses CHS addressing because the internal interface works for very old HDD only, so I hope it remains if possible. But if you need a lot of works for CHS support, I agree to remove it. Wouldn't it be possible to keep the old ATA code in the tree for users who want to use stuff like this? I am going to make it switchable via kernel option, until new code completely settle. It should be possible to keep CHS support in this legacy mode. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Do we still need ATA disk CHS addressing?
While preparing wrapping ATA(4) low-level drivers code into CAM SIM, I would like to remove CHS addressing support to make code cleaner. CHS addressing is officially declared obsoleted and replaced by LBA. Since ATA/ATAPI-6 specification (October 2001) it is even no longer documented. Have anybody seen ATA drive without LBA support in last years? Any other objections against removing it? -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: ata only getting 33 instead of 133
dalibor kollar wrote: I'm using PC-BSD 7.1 based on FreeBSD 7.2-PRERELEASE #12 dvd burner: ASUS DRW-1814BL - http://www.asus.com/product.aspx?P_ID=0S8SJw9jibmKbMn5 MB: ASUS K8V-X SE - http://www.asus.com/product.aspx?P_ID=lzDXlbBVHkdckHVr The question: how do I enable full speed of UDMA133? Is it possible at all? Are you sure this device really supports that speed? -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: Getting jack automute working in M1330 + SND_HDA + 7.1-p3
Hi. Guillermo Antonio Amaral Bastidas wrote: My GF keeps bugging me because I can't mute the internal speakers in my Dell M1330 and she doesn't dig the sweet sweet sounds of heavy metal ( not at 2 AM anyway ), I have tried many hints to try and get it working but I think the examples found on the interwebs are a bit dated or my install might be I'm really not sure compared to what I get back from the snd_hda driver in my install. It would be wonderfull if I could get jack sense working but just muting the speakers will do for now. * uname -a: FreeBSD localhost 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3 #0: Wed Mar 11 12:33:44 PST 2009 r...@localhost:/usr/obj/usr/src/sys/GENERIC i386 Update your system to recent 7-STABLE. New snd_hda driver imported there is much more suitable in this and many other aspects. Read updated man page if any questions. -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
Re: 3ware 9550XU-4LP
FreeBSD Daemon wrote: i the 3ware 9550SXU-4LP controller supported in 6.2R? 3ware device driver for 9000 series storage controllers, version: 3.60.03.006 twa0: <3ware 9000 series Storage Controller> port 0x2000-0x203f mem 0xd800-0xd9ff,0xda10-0xda100fff irq 16 at device 1.0 on pci5 twa0: [FAST] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SXU-8LP, 8 ports, Firmware FE9X 3.04.00.005, BIOS BE9X 3.04.00.002 Works fine for last two months. $ uname -r 6.2-STABLE -- Alexander Motin ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "[EMAIL PROTECTED]"
