Re: fdisk -BI ob clean disk broken - but 1.64 works
On my system, FreeBSD 5.0-CURRENT #1: Mon Nov 4 21:00:50 CET 2002 fdisk ceased to work after a recent upgrade. It used to work fine under GEOMized kernel with both internal ATA disks and external IDE drive attached via fireware or USB (tested both). I had to switch to non-GEOM kernel (my disklabels give my warnings), updated everything, and fdisk ceased to work. I reverted fdisk.c to 1.64 (used to be 1.66) and now fdisk works fine again (with a non-GEOM kernel). Disk layouts below. Another question, can I geomize existing disk? I keep getting disklabel warnings about mismatched partitions and slices. -- Marcin Cieslak // [EMAIL PROTECTED] *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=2432 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=2432 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 14474502 (7067 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 900/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 14474565, size 4192965 (2047 Meg), flag 80 (active) beg: cyl 901/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 18667530, size 20402550 (9962 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: UNUSED *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=7297 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=7297 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 6136641 (2996 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 381/ head 252/ sector 63 The data for partition 2 is: sysid 14 (0x0e),(Primary 'big' DOS (= 32MB, LBA)) start 6136704, size 2087568 (1019 Meg), flag 0 beg: cyl 381/ head 253/ sector 1; end: cyl 511/ head 238/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 8224272, size 4450320 (2173 Meg), flag 80 (active) beg: cyl 511/ head 239/ sector 1; end: cyl 788/ head 243/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 12674592, size 41930343 (20473 Meg), flag 80 (active) beg: cyl 788/ head 244/ sector 1; end: cyl 1023/ head 254/ sector 63 msg46136/pgp0.pgp Description: PGP signature
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
USB is only the transport. It doesn't add or remove functionality (the only exception being probing for LUNs on CBI devices). If you want to determine the geometry you will have to do this through SCSI commands. I was hoping that the CAM code would be smart enough to request the details from the drive itself, but perhaps there is a good reason for asking the controller for this. It did work without, so it hasn't been implemented yet. Feel free to suggest a SCSI command together with the logic. What is the GET_GEOMETRY used for anyway? Well the short version of the problem is that fdisk -BI disk works on -stable to get a FreeBSD partition on the Compact Flash. This does not work on -current anymore. I have traced that back to the commit in umass.c rev 1.61 that removed the fake geometry setting and just leave the cylinders, heads and sectors_per_track zero. This cause fdisk to coredump with a floating point error. In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : We should obviously fix it. I have no idea what is possible in USB : devices in this respect. Nor do I. Maybe there's some SCSI command that we can send that is well defined enough to work often enough. However, I'm not clueful enough about SCSI to know if this can be done (likely reading some mode page will do it in real SCSI), nor about USB's mass storage devices, nor about all the wonderful and weird variations that one might find in the wild... John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
Well the short version of the problem is that fdisk -BI disk works on -stable to get a FreeBSD partition on the Compact Flash. This does not work on -current anymore. I have traced that back to the commit in umass.c rev 1.61 that removed the fake geometry setting and just leave the cylinders, heads and sectors_per_track zero. This cause fdisk to coredump with a floating point error. Hm, strange. I would think that a compact flasg is an ATAPI over CBI device (see attach message in your dmesg). If that is the case, the 'fake setting' was not done in STABLE either and I would expect the problem to be somewhere else. But that would contradict your research. Maybe the short version was too short. :-) The CF is behind a SanDisk ImageMate (I have two different ones), which emulates SCSI according to dmesg. I don't know if they use BBB or CBI. I don't know what the difference is either. :-) umass0: SanDisk ImageMate CF-SD, rev 1.10/0.12, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk ImageMate CF-SD1 0100 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 61MB (125440 512 byte sectors: 0H 0S/T 0C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2 umass0: Get Max Lun not supported (STALLED) da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 61MB (125441 512 byte sectors: 0H 0S/T 0C) # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
Let's work on the 'proper' solution first.
What SCSI commands are suitable for getting the geometry, generically
on a device?
Hmmm, I made an interesting discovery. I searched through some of the
scsi drivers, sys/dev/{aha|ahb|aic*|sym}, looking for XPT_CALC_GEOMETRY
and they all fake the geometry. :-/
fdisk likely should do something sane in the face of such insanity,
but it is unclear what and fdisk is a royal pita to work on anyway :-(
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
In message [EMAIL PROTECTED], John Hay wri
tes:
Let's work on the 'proper' solution first.
What SCSI commands are suitable for getting the geometry, generically
on a device?
Hmmm, I made an interesting discovery. I searched through some of the
scsi drivers, sys/dev/{aha|ahb|aic*|sym}, looking for XPT_CALC_GEOMETRY
and they all fake the geometry. :-/
I noticed this too recently when studying PC98 related disk code.
Solaris on the other hand, pokes some random mode-page which contains
some numbers which may, but more likely may not, have any relationship
to the real hardwares format. Few if any drives have constant number
of sectors per track these days.
At least our scsi code never returns degenerate numbers.
Anyway, what I really wanted to say is that the reason I put the
FW in the name of the DIOCGFW{SECTORS,HEADS} ioctls was that at
this time and date, the only possible utility of such archaic values
are to avoid breaking stupid firmware.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: fdisk -BI ob clean disk broken
On Sat, 2 Nov 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], John Hay wri tes: Hmmm. I just noticed that the disks probe with zero values for the heads, sectors/track and cylinders. I have tried two different USB CF readers and both do it. On 4.x it probes with the correct values on the same machine and the same devices. So why do they probe wrong? I have no idea either, but the answer must be somewhere in the da driver... Please don't assume. It's up to the transport driver to support the XPT_CALC_GEOMETRY command and umass removed its preliminary support without providing a working alternative. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
In message [EMAIL PROTECTED], Nate Lawson writ es: It might be more useful for GEOM to query the BIOS for the physical values and provide a way for upper levels (like CAM) to retrieve this. This is a driver task. besides GEOM is above CAM, not below it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
In message [EMAIL PROTECTED], Nate Lawson writ es: On Mon, 4 Nov 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Nate Lawson writ es: It might be more useful for GEOM to query the BIOS for the physical values and provide a way for upper levels (like CAM) to retrieve this. This is a driver task. besides GEOM is above CAM, not below it. Ok. There are two things that would be useful: 1. Merging the multiple LBA to C/H/S calculations (aic7xxx, umass, ...) to one CAM convenience routine. Well, it will have to be MD, because PC98 seems to prefer different geometries than PC bios. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
umass CF geometry problems, was Re: fdisk -BI ob clean disk broken
: Hmmm. I just noticed that the disks probe with zero values for the
: heads, sectors/track and cylinders. I have tried two different USB
: CF readers and both do it. On 4.x it probes with the correct values
: on the same machine and the same devices. So why do they probe
: wrong?
Don't know. I've had problems with CF readers returning the wrong
geometry values in 4.3, but never 0's
Ok, I found it. It is part of the rev 1.61 change to umass.c. It was
made in June. :-/ The relevant piece is this:
###
Index: umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- umass.c 11 Apr 2002 21:09:41 - 1.60
+++ umass.c 16 Jun 2002 20:53:35 - 1.61
...
@@ -2445,35 +2441,16 @@
}
case XPT_CALC_GEOMETRY:
{
+#ifdef UMASS_DEBUG
struct ccb_calc_geometry *ccg = ccb-ccg;
-
+#endif
DPRINTF(UDMASS_SCSI, (%s:%d:%d:%d:XPT_CALC_GEOMETRY:
- Volume size = %d\n,
+ Volume size = %d (unimplemented)\n,
USBDEVNAME(sc-sc_dev), cam_sim_path(umass_sim),
ccb-ccb_h.target_id, ccb-ccb_h.target_lun,
ccg-volume_size));
- /* XXX We should probably ask the drive for the details
-* instead of cluching them up ourselves
-*/
- if (sc-drive == ZIP_100) {
- ccg-heads = 64;
- ccg-secs_per_track = 32;
- ccg-cylinders = ccg-volume_size / ccg-heads
- / ccg-secs_per_track;
- ccb-ccb_h.status = CAM_REQ_CMP;
- break;
- } else if (sc-proto PROTO_UFI) {
- ccg-heads = 2;
- if (ccg-volume_size == 2880)
- ccg-secs_per_track = 18;
- else
- ccg-secs_per_track = 9;
- ccg-cylinders = 80;
- break;
- } else {
- ccb-ccb_h.status = CAM_REQ_CMP_ERR;
- }
+ ccb-ccb_h.status = CAM_REQ_CMP_ERR;
xpt_done(ccb);
break;
..
###
If I understand this correctly, it means it just faked the geometry, which
explains Warner's comment that it didn't get the geometry always right.
So the question now is do we just leave umass like this, which means we
can't do low level disk stuff on umass devices, or do we add something
like this back or is there another way? Is there a way to get the real
geometry of the device?
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: fdisk -BI ob clean disk broken
In message: [EMAIL PROTECTED]
John Hay [EMAIL PROTECTED] writes:
: On 4.x I have been using a slightly modified version of Warner's diskprep
: to write new compact flashes. On -current fdisk die with signal 8 (Floating
: point exception) when this part of the script runs:
:
: $dev = /dev/r${drive};
: system /bin/dd if=/dev/zero of=$dev count=128 /dev/null 21;
: system /sbin/fdisk -BI $drive;
:
: $dev is normally da0, which is the compact flash plugged into a Sandisk
: usb CF reader.
:
: So is there a better way in the GEOM world to achieve the same thing?
The reason that I do a dd first is to obliterate any MBR that's
there. The intent is to force fdisk to fetch the actual disk geometry
from the disk so that the fdisk lable that is placed on there will
work as a boot disk. Before I added the dd in 4.x, I found that many
CF came with MBRs that didn't match their actual geometry, so when I
tried to boot them, things failed.
Does removing the dd eliminate the problem? If so, that's likely a
bug in GEOMification of fdisk.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: fdisk -BI ob clean disk broken
: On 4.x I have been using a slightly modified version of Warner's diskprep
: to write new compact flashes. On -current fdisk die with signal 8 (Floating
: point exception) when this part of the script runs:
:
: $dev = /dev/r${drive};
: system /bin/dd if=/dev/zero of=$dev count=128 /dev/null 21;
: system /sbin/fdisk -BI $drive;
:
: $dev is normally da0, which is the compact flash plugged into a Sandisk
: usb CF reader.
The reason that I do a dd first is to obliterate any MBR that's
there. The intent is to force fdisk to fetch the actual disk geometry
from the disk so that the fdisk lable that is placed on there will
work as a boot disk. Before I added the dd in 4.x, I found that many
CF came with MBRs that didn't match their actual geometry, so when I
tried to boot them, things failed.
Does removing the dd eliminate the problem? If so, that's likely a
bug in GEOMification of fdisk.
Hmmm. I just noticed that the disks probe with zero values for the
heads, sectors/track and cylinders. I have tried two different USB
CF readers and both do it. On 4.x it probes with the correct values
on the same machine and the same devices. So why do they probe
wrong?
#
umass0: SanDisk ImageMate CF-SD, rev 1.10/0.12, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SanDisk ImageMate CF-SD1 0100 Removable Direct Access SCSI-0 device
da0: 1.000MB/s transfers
da0: 61MB (125440 512 byte sectors: 0H 0S/T 0C)
umass0: at uhub0 port 1 (addr 2) disconnected
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
umass0: detached
umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2
umass0: Get Max Lun not supported (STALLED)
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: 61MB (125441 512 byte sectors: 0H 0S/T 0C)
###
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: fdisk -BI ob clean disk broken
In message: [EMAIL PROTECTED] John Hay [EMAIL PROTECTED] writes: : Hmmm. I just noticed that the disks probe with zero values for the : heads, sectors/track and cylinders. I have tried two different USB : CF readers and both do it. On 4.x it probes with the correct values : on the same machine and the same devices. So why do they probe : wrong? Don't know. I've had problems with CF readers returning the wrong geometry values in 4.3, but never 0's Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fdisk -BI ob clean disk broken
In message [EMAIL PROTECTED], John Hay wri
tes:
: On 4.x I have been using a slightly modified version of Warner's diskprep
: to write new compact flashes. On -current fdisk die with signal 8 (Floating
: point exception) when this part of the script runs:
:
:$dev = /dev/r${drive};
:system /bin/dd if=/dev/zero of=$dev count=128 /dev/null 21;
:system /sbin/fdisk -BI $drive;
:
: $dev is normally da0, which is the compact flash plugged into a Sandisk
: usb CF reader.
The reason that I do a dd first is to obliterate any MBR that's
there. The intent is to force fdisk to fetch the actual disk geometry
from the disk so that the fdisk lable that is placed on there will
work as a boot disk. Before I added the dd in 4.x, I found that many
CF came with MBRs that didn't match their actual geometry, so when I
tried to boot them, things failed.
Does removing the dd eliminate the problem? If so, that's likely a
bug in GEOMification of fdisk.
Hmmm. I just noticed that the disks probe with zero values for the
heads, sectors/track and cylinders. I have tried two different USB
CF readers and both do it. On 4.x it probes with the correct values
on the same machine and the same devices. So why do they probe
wrong?
I have no idea either, but the answer must be somewhere in the da driver...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
