Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: > There shouldn't *be* bootblocks on non-boot disks. > > dd if=/dev/zero of=/dev/da$n count=1 > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". All my disks have bootblocks and (spare) boot partitions. All the bootblocks are DD mode. I don't see any point in using obsolete fdisk tables. (There's IMHO only one purpose obsolete fdisk tables are good for, co-operation with other operating systems in the same machine. None of my machines uses anything else than FreeBSD.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
freebsd-current@freebsd.org
$B$"$C$?$+$$29$b$j;}$C$F$^$9$+!)(B
$B4($$?4$rKd$a$F$/$l$k$=$s$J=P2q$$$,$3$3$K$O$"$j$^$9!#(B
$B$?$a$7$K$"$J$?$N5$;}$A$r=q$-9~$s$G$4$i$s(B
$B4j$$$O$+$J$i$:3p$$$^$9$h!*(B
Http://www.if-j.net
$B=P2q$$7O%5%$%H!V%$%U!W$G$9!#(B
$B$"$J$?$KKbK!$r%F%/%^%/%^%d%3%s{(B
$B=w@-L5NA$5$i$K%-%c%C%7%g%P%C%/!*(B
$BCK@-$b#3#0%]%$%s%HL5NACf!*(B
$B7HBSEEOC$+$4<+Bp$NEEOCHV9f$GEPO?$7$F$/$@$5$$!#(B
$B%"%I%l%9EyHs8x3+$G$9$N$G0B?4$7$F$4MxMQ$/$@$5$$!#(B
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: send_packet: No buffer space available
Andrea Campi wrote: > > Well, you're sending out packets faster than your hardware can > > transmit them. > So, at least now we know what to answer if the question arises again (I > has several people who send 'me too' emails to me). I was having the same problem on my 4.4-RELEASE box. After swapping the Digital (dc) ethernet card for a 3COM (xl) one (and getting rid of a few bogus route entries), the messages stopped appearing and the system has been running fine ever since. I haven't checked if the digital card works well in another box, so I'm not sure if it's the driver, the card or the route entries. Cheers, Walter. -- Walter Belgers "Si hoc signum legere potes, operis boni in rebus [EMAIL PROTECTED] Latinis alacribus et fructuosis potiri potes!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) There are very good reasons NOT to use DD mode if you use certain types of Adaptec SCSI controllers - they simply won't boot from DD. Aside from that, FreeBSD needs to have *one* recommendation for disks, anything else creates too much confusion. It is certainly my impression that the recommendation has been NOT using DD for the IA32 architecture for quite a while now. (The other day a coworker of mine wanted to use DD for some IBM DTLA disks, because he'd heard that the disks performed better that way - something to do with scatter-gather not working right unless you used DD. I'm highly skeptical about this since I have my own measurements from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they show the disks performing extremely well. Anybody else want to comment on this?) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On 09-Dec-2001 [EMAIL PROTECTED] wrote: > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you used > DD. I'm highly skeptical about this since I have my own measurements > from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they > show the disks performing extremely well. Anybody else want to comment > on this?) Sounds like an Old Wives Tale to me. I don't understand the need some people have for using something that is labelled as DANGEROUS. No, it won't hurt your cats but you may lose hair from using it, and for what benefit? NONE! --- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patch to cp to correct PR#27970 and PR#31633, for review
Hi!
Normally, I'd just commit this and wait for the flak, but since I'm changing
the default behaviour when copying directories, I thought people might care.
This patch fixes PR#27970 (directory times not preserved with -p) and
PR#31633 (non-empty read-only directories not copied). It does so by
setting times and permissions on directories in the post-order phase of
the file hierarchy traversal.
Review point 1: there is a minor functional change with this patch:
umask is now applied to copied directories (assuming -p not specified)
$ umask 027
$ mkdir foo
$ chmod 777 foo
$ cp -r foo bar1
$ patchedcp -r foo bar2
$ ls -ld foo bar?
drwxrwxrwx 2 mckay wheel 512 10 Dec 00:29 foo
drwxrwxrwx 2 mckay wheel 512 10 Dec 00:29 bar1
drwxr-x--- 2 mckay wheel 512 10 Dec 00:29 bar2
$
I believe the new behaviour is correct. It follows SUSv2, and matches
GNU cp. I know of nothing that will fail with this change.
Review point 2: in order to avoid a chmod() per directory in the normal
case, there is a complicated conditional to set curr->fts_number. If
I changed this to simply:
curr->fts_number = dne;
then readability and testability would be enhanced, at the cost of a
couple of unnecessary chmod() system calls. I'm leaning towards ditching
the conditional. Anybody against?
I'll commit this is a day or two, unless there are any problems. Also,
there are a number of other open PRs against cp which I hope to commit
fixes for. In particular PR#17389 should be fixed. Oh, and the typo
fix to util.c is sort of a freebie. :-)
Stephen.
PS Some people use -audit for code reviews. But the charter claims it
is for security auditing. Which is right?
Index: cp.c
===
RCS file: /cvs/src/bin/cp/cp.c,v
retrieving revision 1.27
diff -u -r1.27 cp.c
--- cp.c2001/06/19 15:41:54 1.27
+++ cp.c2001/12/09 14:50:39
@@ -248,7 +248,15 @@
FTSENT *curr;
int base = 0, dne, badcp, nlen, rval;
char *p, *target_mid;
+ mode_t mask;
+ /*
+* Keep an inverted copy of the umask, for use in correcting
+* permissions on created directories when not using -p.
+*/
+ mask = ~umask(0777);
+ umask(~mask);
+
if ((ftsp = fts_open(argv, fts_options, mastercmp)) == NULL)
err(1, NULL);
for (badcp = rval = 0; (curr = fts_read(ftsp)) != NULL; badcp = 0) {
@@ -264,8 +272,6 @@
warnx("%s: directory causes a cycle", curr->fts_path);
badcp = rval = 1;
continue;
- case FTS_DP:/* Ignore, continue. */
- continue;
}
/*
@@ -323,6 +329,25 @@
STRIP_TRAILING_SLASH(to);
}
+ if (curr->fts_info == FTS_DP) {
+ /*
+* We are finished copying to this directory. If
+* -p is in effect, set permissions and timestamps.
+* Otherwise, if we created this directory, set the
+* correct permissions, limited by the umask.
+*/
+ if (pflag)
+ rval = setfile(curr->fts_statp, 0);
+ else if (curr->fts_number) {
+ mode_t perm = curr->fts_statp->st_mode & mask;
+ if (chmod(to.p_path, perm)) {
+ warn("chmod: %s", to.p_path);
+ rval = 1;
+ }
+ }
+ continue;
+ }
+
/* Not an error but need to remember it happened */
if (stat(to.p_path, &to_stat) == -1)
dne = 1;
@@ -376,16 +401,19 @@
err(1, "%s", to.p_path);
}
/*
-* If not -p and directory didn't exist, set it to be
-* the same as the from directory, umodified by the
- * umask; arguably wrong, but it's been that way
- * forever.
+* Arrange to correct directory permissions later
+* (in the post-order phase) if this is a new
+* directory and the permissions aren't the final
+* ones we want yet. Note that mkdir() does not
+* honour setuid, setgid nor sticky bits, but we
+* normally want to preserve them on directories.
*/
- if (pflag && setfile(curr->fts_statp, 0))
- badcp = rval = 1;
- else if (dne)
-
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Daniel O'Connor wrote: > I don't understand the need some people have for using something > that is labelled as DANGEROUS. Historically, it hasn't been labelled that, it only later became common terminology for it -- in the typical half-joking manner. > No, it won't hurt your cats but you may lose hair from using it, and > for what benefit? NONE! See my other reply about fdisk tables: they are a misdesign from the beginning. The single most wanted feature it buys you is the ability to completely forget the term `geometry' with your disks: the very first sectors of a disk always have the same BIOS int 0x13 representation, regardless of what your BIOS/controller thinks the `geometry' might be. Thus, those disks are basically portable between controller BIOSes. (Modulo those newer broken BIOSes that believe eggs must be smarter than hens -- see my other article for an opinion.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As [EMAIL PROTECTED] wrote: > There are very good reasons NOT to use DD mode if you use certain > types of Adaptec SCSI controllers - they simply won't boot from DD. Never seen. All my SCSI controllers so far booted from my disks (obviously :). I figure from Peter's comment in that piece of code that the original (386BSD 0.0 inherited) DD mode fake fdisk table apparently had some poor (faked) values inside that could upset some BIOSes. That's bad, and IMHO we should fix what could be fixed, but without dropping that feature entirely (see below). Still, it's my opinion that these BIOSes are simply broken: interpretation of the fdisk table has always been in the realm of the boot block itself. The BIOS should decide whether a disk is bootable or not by looking at the 0x55aa signature at the end, nothing else. Think of the old OnTrack Disk Manager that extended the fdisk table to 16 slots -- nothing the BIOS could ever even handle. It was in the realm of the boot block to interpret it. > Aside from that, FreeBSD needs to have *one* recommendation for > disks, anything else creates too much confusion. DD mode has never been a recommendation. It is for those who know what it means. I'm only against the idea to silently drop support for it... fdisk tables are something that has been designed in the previous millenium, and i think nobody is going to argue about it that they are rather a mis-design from the beginning (or even no design at all, but an ad-hoc implementation). Two different values for the same (which could become conflicting, thus making disks unportable between different controllers), not enough value space to even remotely cover the disks of our millenium, enforcement of something they call `geometry' which isn't even remotely related to the disks' geometry anymore at all, far too few possible entries anyway, ... FreeBSD is in a position where it doesn't strictly require the existence of such an obsoleted implementation detail, so we should users leave the freedom of decision. Again, it has never been the recommendation (well, at least not after 386BSD 0.0 :), and i normally wouldn't recommend it to the innocent user. But we should not break it either. > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you > used DD. [...]) As much as i personally prefer DD mode: that's an urban legend. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> As Peter Wemm wrote: > > > There shouldn't *be* bootblocks on non-boot disks. > > > > dd if=/dev/zero of=/dev/da$n count=1 > > > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) Since I tire of seeing people hit this ignorant opinion in the list archives, I'll just offer the rational counterpoints. - The MBR partition table is not "obsolete", it's a part of the PC architecture specification. - You omit the fact that many peripheral device vendors' BIOS code looks for the MBR partition table, and will fail if it's not present or incorrect. You do realise that "DD" mode does include a (invalid) MBR partition table (now valid, courtesy of a long-needed fix), right? I'd love to never hear those invalid, unuseful, misleading opinions from you again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you used > DD. I'm highly skeptical about this since I have my own measurements > from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they > show the disks performing extremely well. Anybody else want to comment > on this?) Since scatter-gather has nothing to do with the disk (it's a feature of the disk controller's interface to host memory), I think this coworker of yours is delusional. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Question about Freebsd driver
> I have a question about Freebsd driver. If we want to support some > options in driver(like speed and duplex mode setting) , user can use this > option to change driver configurations. I am not sure whether freebsd > driver support driver parameter or something else. Can you give me some > suggestions? Thanks!! >From the question, I infer that you are referring to Ethernet device drivers. In the FreeBSD model, devices fit into one or more of a set of classes. Each class has an established, device-independant mechanism for controlling driver parameters. In the case of Ethernet drivers, parameters are controlled via the driver's ioctl interface. You should be able to find good examples of this in the source for other drivers similar to your own. If you have more specific questions, please feel free to ask them here. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Mike Smith <[EMAIL PROTECTED]> wrote: > - The MBR partition table is not "obsolete", it's a part of the PC >architecture specification. Its design is antique. Or rather: it's missing a design. See other mail for the reasons. For FreeBSD, it's obsolete since we don't need to rely on fdisk slices. (Or rather: it's optional. We can make good use of it when it's there, but we don't need to insist on it being there.) > You do realise that "DD" mode does include a (invalid) MBR partition > table (now valid, courtesy of a long-needed fix), right? Yes, of course, one that is basically ignored by everything. It has always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize fdisk tables at all, but could only live on a disk by its own (as any other BSD before used to). > I'd love to never hear those invalid, unuseful, misleading opinions > from you again. ETOOMANYATTRIBUTES? :-) As long as you keep the feature of DD mode intact, i won't argue. If people feel like creating disks that aren't portable to another controller, they should do. I don't like this idea. But to be honest, see my other article: i never argued to make this the default or a recommended strategy in any form. It should only remain intact at all. Back to the subject, the current warning however, is pointless, and has the major drawback to potentially hide important console messages. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
*HEADS UP!* This means you!
Hi Now that I have your attention, please listen up, this may have some far-reaching consequences. We currently have 2 telnet sources in the src/ tree; src/crypto/telnet and the "base" telnet spread around in (src/*/*telnet*/). The "base" telnet is a complete subset of src/crypto telnet, and as a consequence of this, I want to remove the base telnet bits from the src/ tree. (Just the source, not the build infrastructure). This will be accomplished by removing the "base" sources, and building telnet without defining the AUTHENTICATION and ENCRYPTION macros. These macros are currently used with unifdef to make (by hand) the "base" telnet stuff). I'm not sure when I'll make the commit, but it will be soonish, with due fanfare. Those of you who believe that you may be in trouble with your government by having crypto in your posession (as opposed to using it), please let me know ASAP! This will make src/crypto mandatory if you want telnet(d). This will _not_ make crypto _use_ mandatory. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 22:52:58 +1030, Daniel O'Connor wrote: > > On 09-Dec-2001 [EMAIL PROTECTED] wrote: >> (The other day a coworker of mine wanted to use DD for some IBM DTLA >> disks, because he'd heard that the disks performed better that way - >> something to do with scatter-gather not working right unless you used >> DD. I'm highly skeptical about this since I have my own measurements >> from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they >> show the disks performing extremely well. Anybody else want to comment >> on this?) > > Sounds like an Old Wives Tale to me. > > I don't understand the need some people have for using something that is > labelled as DANGEROUS. I don't understand the need some people have for labelling something as DANGEROUS when it works nearly all the time. We don't have many disks which are shared between different platforms, but that will change. As you know, I have the ability to hot swap disks between an RS/6000 platform and an ia32 platform. The RS/6000 disks will never have a Microsoft partition table on them. They will have BSD partition tables on them. Why call this dangerous? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 12:15:19 -0800, Mike Smith wrote: >> As Peter Wemm wrote: >> >>> There shouldn't *be* bootblocks on non-boot disks. >>> >>> dd if=/dev/zero of=/dev/da$n count=1 >>> >>> Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". >> >> All my disks have bootblocks and (spare) boot partitions. All the >> bootblocks are DD mode. I don't see any point in using obsolete fdisk >> tables. (There's IMHO only one purpose obsolete fdisk tables are good >> for, co-operation with other operating systems in the same machine. >> None of my machines uses anything else than FreeBSD.) > > Since I tire of seeing people hit this ignorant opinion in the list > archives, I'll just offer the rational counterpoints. > > - The MBR partition table is not "obsolete", it's a part of the PC >architecture specification. And if it's part of the PC architecture specification, it can't be obsolete? I dont see any contradiction here. > - You omit the fact that many peripheral device vendors' BIOS code looks >for the MBR partition table, and will fail if it's not present or >incorrect. What do you mean by "peripheral device"? I've never heard of disk drives having a BIOS. If you're talking about host adaptors, it's you who omit what Jörg says about it: No, on the contrary, he went into some detail on this point: On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: > > > Still, it's my opinion that these BIOSes are simply broken: > interpretation of the fdisk table has always been in the realm of the > boot block itself. The BIOS should decide whether a disk is bootable > or not by looking at the 0x55aa signature at the end, nothing else. > Think of the old OnTrack Disk Manager that extended the fdisk table to > 16 slots -- nothing the BIOS could ever even handle. It was in the > realm of the boot block to interpret it. > I agree with Jörg on this. > I'd love to never hear those invalid, unuseful, misleading opinions > from you again. I'd love to never have to see this level of invective poured onto what was previously a calm discussion. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wi driver: firmware %i.%i problem?
In message <[EMAIL PROTECTED]> "Alan Edmonds" writes: : I'm not sure if the %i is a problem the kernel printf or I didn't checkin the small patch to the kernel printf for %i support yet. Ignore it for now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wi driver: firmware %i.%i problem?
In message <[EMAIL PROTECTED]> Alfred Perlstein writes: : %i is because I lost a flamewar to get %i added to kernel printf, : it has been fixed. I was thinking of just committing the one line change and avoiding the flamewar :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > As Peter Wemm wrote: > > > There shouldn't *be* bootblocks on non-boot disks. > > > > dd if=/dev/zero of=/dev/da$n count=1 > > > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) The problem is, that you **are** using fdisk tables, you have no choice. DD mode included a *broken* fdisk table that specified an illegal geometry. This illegal geometry was the reason why Thinkpad Laptops would wedge solid when you installed FreeBSD on it. This illegal geometry is the reason why FreeBSD disks wedge solid any EFI system unless you remove the illegal geometry tables. This illegal geometry causes divide by zero errors in a handful of scsi bioses from Adaptec. This illegal geometry causes divide by zero errors in a handful of scsi bioses from NCR/Symbios. This is why it is called dangerous. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
:This illegal geometry causes divide by zero errors in a handful of scsi :bioses from Adaptec. : :This illegal geometry causes divide by zero errors in a handful of scsi :bioses from NCR/Symbios. : :This is why it is called dangerous. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Handful? I'm taking my life in my hands if I DD a DELL machine. BEWM! As I found out the hard way about a year ago. (Probably the Adaptec firmware but every Dell rack-mount has one so...). The machines wouldn't boot again until I pulled the physical drives and then camcontrol rescan'd them in after a CD boot. Joy. This is why I fixed disklabel -B to operate properly on slices and added a whole section to the end of 'man disklabel' to describe how to do it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > Mike Smith <[EMAIL PROTECTED]> wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > >architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) No, it isn't. We specifically have a copy of both the broken and fixed fdisk tables in the kernel and do a bcmp() to see if the fdisk table that is included in /boot/boot1 **uncoditionally** is in fact the dangerously dedicated table. If it is, then we specifically reject it or we end up with a disk size of 25MB (5 sectors). > > You do realise that "DD" mode does include a (invalid) MBR partition > > table (now valid, courtesy of a long-needed fix), right? > > Yes, of course, one that is basically ignored by everything. It has > always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize > fdisk tables at all, but could only live on a disk by its own (as any > other BSD before used to). No, it isn't ignored, BIOS'es "know" that fdisk partitions end on cylinder boundaries, and therefore can intuit what the expected geometry is for the disk in question. It does this in order to allow the CHS int 0x13 calls to work. The problem is that the int13 code only allowed for 255 heads, and the fake "end of disk" entry that is unconditionally in /boot/boot1 specified an ending head number 255 (ie: 256 heads). When this gets put into a byte register it is truncated to zero and we get divide by zero errors. > > I'd love to never hear those invalid, unuseful, misleading opinions > > from you again. > > ETOOMANYATTRIBUTES? :-) > > As long as you keep the feature of DD mode intact, i won't argue. If > people feel like creating disks that aren't portable to another > controller, they should do. I don't like this idea. We can just as easily have bootable-DD mode with a real MBR and have freebsd start on sector #2 instead of overlapping boot1 and mbr. This costs only one sector instead of 64 sectors (a whopping 32K, I'm sure that is going to break the bank on today's disks). I'd rather that we be specific about this. If somebody wants ad2e or da2e then they should not be using *any* fdisk tables at all. Ie: block 0 should be empty. The problem is that if you put /boot/boot1 in there, then suddenly it looks like a fdisk disk and we have to have ugly magic to detect it and prevent the fake table from being used. I would prefer that the fdisk table come out of /boot/boot1 so that we dont have to have it by default, and we use fdisk to install the "DD magic table" if somebody wants to make it bootable. > But to be honest, see my other article: i never argued to make this > the default or a recommended strategy in any form. It should only > remain intact at all. Back to the subject, the current warning > however, is pointless, and has the major drawback to potentially hide > important console messages. The console buffer is 32K these days. You'd have to have around 300 disks to have any real effect on the kernel. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *HEADS UP!* This means you!
Mark Murray wrote: > Hi > > Now that I have your attention, please listen up, this may have some > far-reaching consequences. > > We currently have 2 telnet sources in the src/ tree; src/crypto/telnet > and the "base" telnet spread around in (src/*/*telnet*/). > > The "base" telnet is a complete subset of src/crypto telnet, and as > a consequence of this, I want to remove the base telnet bits from > the src/ tree. (Just the source, not the build infrastructure). > > This will be accomplished by removing the "base" sources, and building > telnet without defining the AUTHENTICATION and ENCRYPTION macros. These > macros are currently used with unifdef to make (by hand) the "base" > telnet stuff). > > I'm not sure when I'll make the commit, but it will be soonish, with > due fanfare. > > Those of you who believe that you may be in trouble with your > government by having crypto in your posession (as opposed to using > it), please let me know ASAP! This will make src/crypto mandatory > if you want telnet(d). This will _not_ make crypto _use_ mandatory. I for one will miss it. I used libexec/telnetd extensively during ia64 bootstrap (and still use it) before we had the crypto stuff going. This was all built by hand, 'make world' still isn't an option there. I also use usr.bin/telnet on other systems where SRA is constantly getting in my face and annoying the !^@#%!@^#!# out of me. I really dont see that this has to be done this way. FreeBSD committers catch on to quirks in the tree pretty quickly. I would much rather that the unifdef step marked the generated files more prominantly so that we didn't have accidents. It would be a shame to complicate things when it just takes a bit of committer education. How about making the unifdef: targets whack on large "BEWARE! GENERATED FILE!" warnings all over the beginning and end of each of them instead? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
> On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: > > > > > > Still, it's my opinion that these BIOSes are simply broken: Joerg's personal opinion can go take a hike. The reality of the situation is that this table is required, and we're going to put it there. End of story. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 18:32:38 -0800, Mike Smith wrote: >> On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: >>> >>> >>> Still, it's my opinion that these BIOSes are simply broken: > > Joerg's personal opinion can go take a hike. The reality of the > situation is that this table is required, and we're going to put it there. The reality of the situation is far from being clear. The only thing I can see is that you're trying to dictate things without adequate justification. You should reconsider that attitude. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
Greg Lehey wrote: [ ... IBM DTLA drives ... ] IBM DTLA drives are known to rotate fast enough near the spindle that the sustained write speed exceeds the ability of the controller electronics to keep up, and results in crap being written to disk. This is not often a problem with windows, the FS of shich fills sectors in towards the spindle, so you only hit the problem when you near the "disk full" state. Do a Google/Tom's Hardware search to reassure yourself that I am not smoking anything. > > I don't understand the need some people have for using something that is > > labelled as DANGEROUS. > > I don't understand the need some people have for labelling something > as DANGEROUS when it works nearly all the time. It's because you have to reinstall, should you want to add a second OS at a later date (e.g. Linux, or Windows). > We don't have many disks which are shared between different platforms, > but that will change. As you know, I have the ability to hot swap > disks between an RS/6000 platform and an ia32 platform. The RS/6000 > disks will never have a Microsoft partition table on them. They will > have BSD partition tables on them. Why call this dangerous? Your use is orthogonal to the most common expected usage, which is disks shared between OSs on a single platform, rather than disks shared between a single OS on multiple platforms. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> Joerg Wunsch wrote: > > Mike Smith <[EMAIL PROTECTED]> wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > > >architecture specification. > > > > Its design is antique. Or rather: it's missing a design. See other > > mail for the reasons. For FreeBSD, it's obsolete since we don't need > > to rely on fdisk slices. (Or rather: it's optional. We can make good > > use of it when it's there, but we don't need to insist on it being > > there.) FWIW: The MBR layout is documented in great gory detail in chapter 6 of the PReP specififcation, which I believe is now available on line from the PowerPC folks, Apple, and Motorolla, and also as an IBM "redbook". It discusses everything, including the LBA fields, and sharing disks between PPC (running in Motorolla byte order) and x86 machines (running a DOS-derived OS). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *HEADS UP!* This means you!
On Sun, 9 Dec 2001, Peter Wemm wrote: > Mark Murray wrote: > > Hi > > > > Now that I have your attention, please listen up, this may have some > > far-reaching consequences. > > > > We currently have 2 telnet sources in the src/ tree; src/crypto/telnet > > and the "base" telnet spread around in (src/*/*telnet*/). > > > > The "base" telnet is a complete subset of src/crypto telnet, and as > > a consequence of this, I want to remove the base telnet bits from > > the src/ tree. (Just the source, not the build infrastructure). > > > > This will be accomplished by removing the "base" sources, and building > > telnet without defining the AUTHENTICATION and ENCRYPTION macros. These > > macros are currently used with unifdef to make (by hand) the "base" > > telnet stuff). > > > > I'm not sure when I'll make the commit, but it will be soonish, with > > due fanfare. > > > > Those of you who believe that you may be in trouble with your > > government by having crypto in your posession (as opposed to using > > it), please let me know ASAP! This will make src/crypto mandatory > > if you want telnet(d). This will _not_ make crypto _use_ mandatory. > > I for one will miss it. I used libexec/telnetd extensively during ia64 > bootstrap (and still use it) before we had the crypto stuff going. This > was all built by hand, 'make world' still isn't an option there. I also > use usr.bin/telnet on other systems where SRA is constantly getting in > my face and annoying the !^@#%!@^#!# out of me. I agree. SRA is really annoying. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *HEADS UP!* This means you!
Peter Wemm writes: | I for one will miss it. I used libexec/telnetd extensively during ia64 | bootstrap (and still use it) before we had the crypto stuff going. This | was all built by hand, 'make world' still isn't an option there. I also | use usr.bin/telnet on other systems where SRA is constantly getting in | my face and annoying the !^@#%!@^#!# out of me. Well, for the SRA thing you can do a "-X SRA" now that it doesn't core-dump if you do that (I submited that patch a year ago or so since it was pretty annoying!). I setup my telnetd servers with "-X SRA" so that I don't have to do it via command line. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 18:46:24 -0800, Terry Lambert wrote: > Greg Lehey wrote: > > [ ... IBM DTLA drives ... ] No, that wasn't me. > IBM DTLA drives are known to rotate fast enough near the spindle > that the sustained write speed exceeds the ability of the controller > electronics to keep up, and results in crap being written to disk. What about the cache? > This is not often a problem with windows, the FS of shich fills > sectors in towards the spindle, so you only hit the problem when you > near the "disk full" state. This sounds very unlikely. > Do a Google/Tom's Hardware search to reassure yourself that I am not > smoking anything. I think I'd rather put the shoe on the other foot. This looks like high-grade crack. Who was smoking it? >>> I don't understand the need some people have for using something that is >>> labelled as DANGEROUS. >> >> I don't understand the need some people have for labelling something >> as DANGEROUS when it works nearly all the time. I *did* write this. > It's because you have to reinstall, should you want to add a second > OS at a later date (e.g. Linux, or Windows). So all dedicated installations are dangerous? I would have to do that whether I had a Microsoft partition table or not if I had already used the entire disk for FreeBSD. >> We don't have many disks which are shared between different platforms, >> but that will change. As you know, I have the ability to hot swap >> disks between an RS/6000 platform and an ia32 platform. The RS/6000 >> disks will never have a Microsoft partition table on them. They will >> have BSD partition tables on them. Why call this dangerous? > > Your use is orthogonal to the most common expected usage, which is > disks shared between OSs on a single platform, rather than disks > shared between a single OS on multiple platforms. Expected usage is to install once and then never change it. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
Greg Lehey wrote: > > [ ... IBM DTLA drives ... ] > > No, that wasn't me. I didn't quote the full thing; that's what the brackets and ellipsis was for. > > IBM DTLA drives are known to rotate fast enough near the spindle > > that the sustained write speed exceeds the ability of the controller > > electronics to keep up, and results in crap being written to disk. > > What about the cache? Good point. The cache is known to not actually flush to disk when ordered to do so. See the EXT3FS article on www.ibm.com/developerworks for more details. > > This is not often a problem with windows, the FS of shich fills > > sectors in towards the spindle, so you only hit the problem when you > > near the "disk full" state. > > This sounds very unlikely. I know, doesn't it? Good thing Tom's Hardware is so thorough, or we might never have known this, with everyone on the verge of discovering it simply dismissing it as "very unlikely". 8^). > > Do a Google/Tom's Hardware search to reassure yourself that I am not > > smoking anything. > > I think I'd rather put the shoe on the other foot. This looks like > high-grade crack. Who was smoking it? Tom's Hardware, IBM, CNET, Storave Review, etc.. http://www6.tomshardware.com/storage/00q3/000821/ibmdtla-07.html http://www.storage.ibm.com/hdd/prod/deskstar.htm http://computers.cnet.com/hardware/0-1092-418-1664463.html?pn=3&lb=2&ob=0&tag=st\.co.1092.bottom.1664463-3 http://www.storagereview.com/welcome.pl?/http://www.storagereview.com/jive/sr/thread.jsp?forum=2&thread=12485 I suggest the search: http://google.yahoo.com/bin/query?p=DTLA+drive+problem&hc=0&hs=0 > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > So all dedicated installations are dangerous? I would have to do > that whether I had a Microsoft partition table or not if I had already > used the entire disk for FreeBSD. Yes. I don't understand your point. > > Your use is orthogonal to the most common expected usage, which is > > disks shared between OSs on a single platform, rather than disks > > shared between a single OS on multiple platforms. > > Expected usage is to install once and then never change it. No, expected usage is to purchase a machine with an OS preinstalled, and then install FreeBSD/Linux/BeOS/other third party OS as an "also ran", rather than the primary OS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
Greg Lehey wrote: [ ... DTLA drives ... ] > > Do a Google/Tom's Hardware search to reassure yourself that I am not > > smoking anything. > > I think I'd rather put the shoe on the other foot. This looks like > high-grade crack. Who was smoking it? For your further amusement, here is a pointer to the class action lawsuit against IBM on the 75GXP DTLA drives: http://www.tech-report.com/news_reply.x/3035/3/ It includes a pointer to the PDF of the complaint form. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On google search for: deskstar 75gxp class action http://www.theregister.co.uk/content/54/22412.html http://www.pcworld.com/news/article/0,aid,67608,00.asp etc... So apparently my warning about these drives in 'man tuning' is still appropriate :-) -Matt :> > IBM DTLA drives are known to rotate fast enough near the spindle :> > that the sustained write speed exceeds the ability of the controller :> > electronics to keep up, and results in crap being written to disk. :> :> What about the cache? : :Good point. The cache is known to not actually flush to disk when :ordered to do so. See the EXT3FS article on www.ibm.com/developerworks :for more details. : :> > This is not often a problem with windows, the FS of shich fills :> > sectors in towards the spindle, so you only hit the problem when you :> > near the "disk full" state. :> :> This sounds very unlikely. : :I know, doesn't it? Good thing Tom's Hardware is so thorough, or we :might never have known this, with everyone on the verge of discovering :it simply dismissing it as "very unlikely". 8^). :... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kernsubr_diskmbr.c)
On Sun, 9 Dec 2001, Matthew Dillon wrote: > On google search for: > > deskstar 75gxp class action > > http://www.theregister.co.uk/content/54/22412.html > http://www.pcworld.com/news/article/0,aid,67608,00.asp > > etc... So apparently my warning about these drives in 'man tuning' is > still appropriate :-) > > -Matt > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > :> > that the sustained write speed exceeds the ability of the controller > :> > electronics to keep up, and results in crap being written to disk. I would adssume it actually the tracks FURTHEREST from the spindle.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Sun, Dec 09, 2001 at 11:00:19PM +0100, Joerg Wunsch wrote: > Mike Smith <[EMAIL PROTECTED]> wrote: > > - The MBR partition table is not "obsolete", it's a part of the PC > >architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? You will get the traditional Unix workstation partitioning you so much long for. It really seems your arguments are nothing more than "MBR's are a M$ and IBM PeeCee thing, and I hate anything PeeCee". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > Mike Smith <[EMAIL PROTECTED]> wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > >architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) Can you please clarify for me what specifically you do not like.. Is it: - the cost of 32K of disk space on an average disk these days? (and if so, is reducing that to one sector instead of 62 sufficient?) - you don't like typing "s1" in the device name? Dont forget, there is quite a bit of confusion about what "DD" means. "disklabel -rw ad2 auto" is one form. That should not use fdisk at all. This is quite fine, and nobody wants that to go away. But the abomination is the form that is pseudo-bootable. We fill up boot1.s with a fake fdisk table and crap to try and work around cases where we are called either as the partition boot sector, or as a global MBR. This one should be taken out and shot. If you are going to make a bootable disk, you had better play by the rules of the environment that is booting it. At the very least, the fdisk table should be valid! I advocate that the bootable form (where boot1.s is expected to do the job of both the mbr *and* the partition boot) is evil and should at the very least be fixed. It should be something that is explicitly activated, and not something that you get whether you want it or not. This would have solved the Thinkpad and does solve the EFI problem. There are lots of ways that it can be fixed without forcing an "s1" into your device names if that's what is really upsetting you. > As long as you keep the feature of DD mode intact, i won't argue. If > people feel like creating disks that aren't portable to another > controller, they should do. I don't like this idea. Which "DD" mode? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kernsubr_diskmbr.c)
:> etc... So apparently my warning about these drives in 'man tuning' is :> still appropriate :-) :> :> -Matt :> :> :> > IBM DTLA drives are known to rotate fast enough near the spindle :> :> > that the sustained write speed exceeds the ability of the controller :> :> > electronics to keep up, and results in crap being written to disk. : : :I would adssume it actually the tracks FURTHEREST from the spindle.. This is the first I've heard of the alleged controller electronics performance problem. My understanding is that the failures are due to manufacturing problems, but people have apparently experienced software lockups as well. What is not in doubt is that there have been some severe problems with this model. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IBM DTLA drives (was: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) )
Matthew Dillon wrote: > :> etc... So apparently my warning about these drives in 'man tuning' is > :> still appropriate :-) > :> > :>-Matt > :> > :> :> > IBM DTLA drives are known to rotate fast enough near the spindle > :> :> > that the sustained write speed exceeds the ability of the controller > :> :> > electronics to keep up, and results in crap being written to disk. > : > : > :I would adssume it actually the tracks FURTHEREST from the spindle.. > > This is the first I've heard of the alleged controller electronics > performance problem. My understanding is that the failures are due > to manufacturing problems, but people have apparently experienced > software lockups as well. > > What is not in doubt is that there have been some severe problems with > this model. Yes there are two problems. The physical failure problem seems to be mostly restricted to the 75GXP. However the electronics/bandwidth/ density/whatever-it-is problem is uniform across the entire DTLA line. We stopped using 75GXP's at work a while back, but we still regularly suffer from the electronics/bandwidth/whatever-it-is problem on 30G DTLA drives on a daily basis. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM DTLA drives (was: Re: "Dangerously dedicated" yet again (was:cvs commit: src/sys/kern subr_diskmbr.c) )
It seems Peter Wemm wrote: > > Yes there are two problems. The physical failure problem seems to > be mostly restricted to the 75GXP. However the electronics/bandwidth/ > density/whatever-it-is problem is uniform across the entire DTLA line. > We stopped using 75GXP's at work a while back, but we still regularly > suffer from the electronics/bandwidth/whatever-it-is problem on 30G DTLA > drives on a daily basis. It seems this problem only affects the newer versions of the DTLA, the first models (of which type most of mine are) doesn't seem to suffer from this problem. The first models looks like the older DPTA drives, whereas the newer ones has at least a different top cover. Anyhow, the problem seem to be an electronics malfunction (IBM doesn't tell exactly) and it is triggered by the drive being very sensitive to the power supply being top quality. At any rate I think the hysteria about these drives is somewhat overrated, but thats only my oppinion... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Six-figure income from home, guaranteed!
Below is the result of your feedback form. It was submitted by ([EMAIL PROTECTED]) on Sunday, December 9, 2001 at 14:13:28 --- To whom it may concern: Are you looking to make money online? If you're either looking for a job, tired of your existing job, eager for more pay, or just anxious to have the added freedom and independence that comes with working at home, this email could change your life. We can teach you (in under a half-hour) how to pull in a six-figure income from home... GUARANTEED, or your money back. Click below for more info http://www.instantempires.net/money2/ --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > It's because you have to reinstall, should you want to add a second > OS at a later date (e.g. Linux, or Windows). I think it has more to do with the drive going on a new motherboard that might not boot with dangerously dedicated than the above. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
"David W. Chapman Jr." wrote: > On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > I think it has more to do with the drive going on a new motherboard > that might not boot with dangerously dedicated than the above. The concept of "dangerously dedicated" significantly predates BIOS being unable to boot such drives, either because of "antivirus" checks, or because of automatic fictitious geometry determination by Adaptec or NCR (now Symbios) controllers, which end up getting "divide by zero" errors when parsing the fictitious partition table that the FreeBSD "dangerously dedicate" mode includes in its boot block. In fact, I remember installing 386BSD "dangerously dedicated" on an AT&T WGS 386 ESDI drive, back in 1992. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
> > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > :> > that the sustained write speed exceeds the ability of the controller > > :> > electronics to keep up, and results in crap being written to disk. > > > I would adssume it actually the tracks FURTHEREST from the spindle.. Wouldn't the linear speed be faster closer to the spindle at 7200 RPM than at the edge? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
"David W. Chapman Jr." wrote: > > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > > :> > that the sustained write speed exceeds the ability of the controller > > > :> > electronics to keep up, and results in crap being written to disk. > > > > > > I would adssume it actually the tracks FURTHEREST from the spindle.. > > Wouldn't the linear speed be faster closer to the spindle at 7200 RPM > than at the edge? This particular tangent of the disk partitioning thread has gone *way* off topic. :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
"David W. Chapman Jr." wrote: > On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > I think it has more to do with the drive going on a new motherboard > that might not boot with dangerously dedicated than the above. .. And the mere presence of one of the disks that causes the bios to lock up at boot. Note that this is a particularly bad thing in laptops. There are three classes of behavior: 1) You luck out and it works 2) You get a bios divide-by-zero fault when you *boot* of the disk. This shows up as a 'BTX fault'. If you check the lists, a good number of btx faults posted to the lists have int=0 (divide by zero) in them. The problem is more widespread than it appears. 3) You get a system lockup when booting the *computer* if *any* DD disk is attached anywhere at all. This is what killed the Thinkpad T20*, A20*, 600X etc. After all the yelling we did at IBM, it turned out to be FreeBSD's fault. It also happens on Dell systems. It kills all IA64 boxes if a FreeBSD/i386 disk is attached anywhere. An additional problem is that because boot1 has got a fdisk table embedded in it unconditionally, a freebsd partition *looks* like it has got a recursive MBR in it. This is what is really bad and is what is killing us on newer systems. What really sucks is that there is **NO WAY** to remove it with the tools that we have except a hex editor. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
+---[ David W. Chapman Jr. ]-- | > > :> > IBM DTLA drives are known to rotate fast enough near the spindle | > > :> > that the sustained write speed exceeds the ability of the controller | > > :> > electronics to keep up, and results in crap being written to disk. | > | > | > I would adssume it actually the tracks FURTHEREST from the spindle.. | | | Wouldn't the linear speed be faster closer to the spindle at 7200 RPM | than at the edge? er no. The circumference of a circle is 2 PI r. So as your distance from the spindle increases the amount of physical real estate you're traversing increases. Since you are turning at a constant angular velocity, your linear velocity increases as the distance from the spindle increases by a factor of PI (or around 3 if you're not a maths person). Even been at one of those carnivals where they have a spinning thing? It's easier to stay near the centre, than near the edges, because you are moving a *lot* quicker at the edges. And just for the hell of it; If you have a 3 unit disc doing 1 RPM If you're 1/2 unit out you're doing ~3 units/sec If you're one unit out, you're doing ~6 units/sec If you're two units out you're doing ~12 units/sec at three;~18 units/sec Multiply by 7200 and s/units/inches/ The outside of your disk is really moving The density of the sectors at the outer edge is lighter than near the centre, which mitigates the speed some what. See Also: artficial gravity in space stations/ships/objects -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 22:44:52 -0800, Peter Wemm wrote: > 3) You get a system lockup when booting the *computer* if *any* DD disk >is attached anywhere at all. This is what killed the Thinkpad T20*, >A20*, 600X etc. After all the yelling we did at IBM, it turned out >to be FreeBSD's fault. It also happens on Dell systems. It kills >all IA64 boxes if a FreeBSD/i386 disk is attached anywhere. What are you talking about? The IBM lockup was due to the presence of *Microsoft partition* of type 0xn5, for any value of n. If these systems also lock up with a dedicated disk, it's due to some other bug. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
