Date: Tue, 30 Nov 2004 14:05:24 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: FreeBSD Firewire Developers <freebsd-firewire@freebsd.org> Subject: Firewire/USB conflicting number of sectors for certain drives Message-ID: <200411301305.iAUD5Ot01166@Mail.NOSPAM.DynDNS.dK>
next in thread | raw e-mail | index | archive | help
Salut, First a quick question -- I've noticed that a few soundcards exist (external) with Firewire interfaces, and I wonder what the chances of FreeBSD being able to support such a device might be, if anyone might be able to comment. Thanks... Now, the issue at hand: I have three different disks in front of me, all equipped with both USB and Firewire connectors. Two of the three report a different number of sectors -- one fewer -- when connected via firewire, than when connected via USB1 (UHCI and apparently OHCI though I know of access problems with the latter; have not checked against EHCI). The third disk, however, reports the same sectors in `dmesg', and I initially set it up connected with Firewire, while the other drives have been set up over USB1 as the hardware which I had at hand. The two drives are Western Digital, hidden behind something as you can see in the below dmesg snippets. Here the reported sectors from them: USB: da1: 238475MB (488397169 512 byte sectors: 255H 63S/T 30401C) FW: da1: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) and USB: da1: 190782MB (390721969 512 byte sectors: 255H 63S/T 24321C) FW: da1: 190782MB (390721968 512 byte sectors: 255H 63S/T 24321C) Too bad I disklabel'ed and whatnot the disk when connected via USB, so that any Firewire access fails to report the actual partition where I expect to find the data (it now appears to extend beyond the end of the disk). Hmmm. da1s1: slice extends beyond end of disk: truncating from 488397106 to 488397105 sectors The third drive -- the first one I acquired -- is a Maxtor, and does not have this issue. I'm using kernel modules on FreeBSD 4.x, modules built on 11.05.2004, which otherwise work splendidly, though I may have one or two minor hacks compiled in. I haven't tried more recent source or anything based on -current. It's probably a known issue that (as you see below), the drive attached by USB is identified by what the actual drive is, whereas when connected via firewire, it appears to be identified as the chipset that interfaces from firewire to the drive's ATA -- at least with my modules. Here's a bit of some `dmesg' concerning the drives, although it's not comprehensive, in case there's something to be seen below: exhibit 1 on usb: umass0: ASSMANN Electronic GmbH product 0x3507, rev 2.00/0.01, addr 4 umass0:3:0:-1: Attached to scbus3 pass1 at umass-sim0 bus 0 target 0 lun 0 pass1: <WDC WD25 00JB-00GVA0 08.0> Fixed Direct Access SCSI-0 device pass1: 1.000MB/s transfers Creating DISK da1 da1 at umass-sim0 bus 0 target 0 lun 0 da1: <WDC WD25 00JB-00GVA0 08.0> Fixed Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 238475MB (488397169 512 byte sectors: 255H 63S/T 30401C) exhibit 1 then connected via firewire: pass1 at sbp0 bus 0 target 1 lun 0 pass1: <ASSMANN 0102> Fixed Simplified Direct Access SCSI-4 device pass1: Serial Number \^_ pass1: 50.000MB/s transfers Creating DISK da1 sbp0:1:0 sbp_cam_scan_lun da1 at sbp0 bus 0 target 1 lun 0 da1: <ASSMANN 0102> Fixed Simplified Direct Access SCSI-4 device da1: Serial Number \^_ da1: 50.000MB/s transfers da1: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da1s1: type 0xa5, start 63, end = 488397168, size 488397106 : OK da1s1: slice extends beyond end of disk: truncating from 488397106 to 488397105 sectors da1: raw partition size != slice size da1: start 63, end 488397167, size 488397105 da1c: start 63, end 488397168, size 488397106 exhibit 2 connected via usb: umass1: Generic USB 2.0 Storage Device, rev 2.00/0.01, addr 5 umass1:4:1:-1: Attached to scbus4 pass1 at umass-sim1 bus 1 target 0 lun 0 pass1: <WDC WD20 00JB-00GVA0 08.0> Fixed Direct Access SCSI-0 device pass1: 1.000MB/s transfers Creating DISK da1 da1 at umass-sim1 bus 1 target 0 lun 0 da1: <WDC WD20 00JB-00GVA0 08.0> Fixed Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 190782MB (390721969 512 byte sectors: 255H 63S/T 24321C) and then via firewire: da1 at sbp0 bus 0 target 1 lun 0 da1: < 1394 to ATA 2804> Fixed Simplified Direct Access SCSI-4 device da1: Serial Number ^_ da1: 50.000MB/s transfers da1: 190782MB (390721968 512 byte sectors: 255H 63S/T 24321C) for reference, the Maxtor drive appears comparable with both: usb: umass1: Maxtor 5000XT v01.00.00, rev 2.00/1.00, addr 5 umass1: Get Max Lun not supported (STALLED) umass1:4:1:-1: Attached to scbus4 pass1 at umass-sim1 bus 1 target 0 lun 0 pass1: <Maxtor 5000XT v01.00.00 0100> Fixed Direct Access SCSI-0 device pass1: Serial Number A80A06AE pass1: 1.000MB/s transfers Creating DISK da1 da1 at umass-sim1 bus 1 target 0 lun 0 da1: <Maxtor 5000XT v01.00.00 0100> Fixed Direct Access SCSI-0 device da1: Serial Number A80A06AE da1: 1.000MB/s transfers da1: 239371MB (490232832 512 byte sectors: 255H 63S/T 30515C) firewire: pass1 at sbp0 bus 0 target 0 lun 0 pass1: <Maxtor 5000XT v1.00.00 0000> Fixed Simplified Direct Access SCSI-4 devi ce pass1: Serial Number A80A06AE pass1: 50.000MB/s transfers Creating DISK da1 sbp0:0:0 sbp_cam_scan_lun da1 at sbp0 bus 0 target 0 lun 0 da1: <Maxtor 5000XT v1.00.00 0000> Fixed Simplified Direct Access SCSI-4 device da1: Serial Number A80A06AE da1: 50.000MB/s transfers da1: 239371MB (490232832 512 byte sectors: 255H 63S/T 30515C) I'll be rebuilding my modules with the latest source Real Soon Now, to see if this is still an issue, and would be happy to provide any needed info. thanks barry bouwsma
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411301305.iAUD5Ot01166>