Re: rev 1.61 of /sys/netinet/in.c breaks ISDN

[Ruslan Ermilov]

On Sat, Dec 08, 2001 at 11:44:47PM +0100, Joerg Wunsch wrote:
> As Ruslan Ermilov wrote:
> 
> > > You need to configure /some/ interface address for the remote end
> > > anyway, and it must not clash with any other routing table entry,
> > > since "ifconfig ... up" always adds an entry for the remote IP address
> > > for p2p interfaces.
> 
> > Only if you have INET address configured on an interface.
> 
> That's the purpose of an sppp interface.  You can't do anything with
> it unless an INET address has been configured to it.  (In the case of
> an automatic dialer -- which is what many ISDN users are using -- you
> need the IP traffic generated by normal routing in order to trigger
> the ISDN dialout.)
> 
ifconfig isp0 up
route add default -iface isp0

Won't this work, without prior configuring any INET addresses?
This will definitely trigger a traffic through the interface.

> > Why not just bring the interface up first, then negotiate an address,
> > then add it to interface?
> 
> Because it'll become a chicken-and-egg problem: the interface would
> never start negotiating PPP in that case.
> 
Still don't get it, sorry.  :-)


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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)

[Mike Smith]

> >>> 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.

You can't substantiate your argument by closing your eyes, Greg.

There's a wealth of evidence against your stance, and frankly, none that 
supports it other than myopic bigotry ("I don't want to do this because 
Microsoft use this format").  Are you going to stop using all of the 
other techniques that we share with them?


-- 
... 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

[Joerg Wunsch]

As Peter Wemm wrote:

> 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.

And you call that a "design"?  I call it a poor hack, nothing else.

The restriction to whatever the BIOS believes to be a "cylinder"
boundary is one of my gripes with fdisk tables; you obviously missed
that (or you don't argue about it -- can i take this as silent
agreement?).  It imposes a geometry that is not even remotely there,
with the drawbacks that a number of sectors can never be assigned (OK,
no big deal these days), but even worse, disks are non-portable
between different BIOSes that perform different "intuition" about how
to obtain the "geometry" from those poorly chosen values that are
included in fdisk tables.

/The/ major advantage of DD mode was that all BIOSes (so far :) at
least agree on how to access block 0 and the adjacent blocks, so
starting our own system there makes those disks portable.

> [...] 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've read this, and yes, i never argued about fixing /that/.  Since
those values chosen by our grandfather Bill Jolitz have been just
`magic' numbers only, it's unfortunate they eventually turned out to
be such bad magic about a decade later.

> 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.

Probably, i think i could live with that.

> 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.

That disk wouldn't boot at all, you know that.

Yes, i prefer my disks to be called da0a...daNP.

>> 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.

You're narrow minded here, Peter, this time about in the same way as
Windoze is narrow minded: "All the world's a graphical console
produced by XXX."  No, all the world's not like that.  You might
consider my pcvt console obsolete, OK, but did you ever think about a
plain VT220 on a serial console?  They don't have /any/ scrollback
buffer.  (And you can't even stop the output with ^S while FreeBSD is
booting.)  Also, i think that:

uriah /boot/kernel/kernel: da0: invalid primary partition table: Dangerously Dedicated 
(ignored)
uriah last message repeated 5 times
uriah /boot/kernel/kernel: da1: invalid primary partition table: Dangerously Dedicated 
(ignored)
uriah last message repeated 34 times
uriah /boot/kernel/kernel: da2: invalid primary partition table: Dangerously Dedicated 
(ignored)
uriah last message repeated 34 times

...73 of those silly messages are just beyond any form of usefulness.
Either we hide this completely behind bootverbose (back to the root of
this thread) since it bears no information at all (i already knew what
is written there, since it was my deliberate decision, and it could
not have happened unless being my deliberate decision), or we at least
ensure any of those messages is emitted at most once per drive.

-- 
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: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

[Greg Lehey]

On Monday, 10 December 2001 at  0:17:14 -0800, Mike Smith 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.
>
> You can't substantiate your argument by closing your eyes, Greg.

No, of course not.  I also can't substantiate my arguments by sticking
my fingers down my throat and shouting "dangerously dedicated!".  But
then, I wasn't doing either.  Read back this thread for the evidence I
have given and which you apparently choose to ignore.

> There's a wealth of evidence against your stance,

Possibly, you just haven't shown it.  What we know so far is that
there are some kludges in the boot loader which can confuse BIOSes;
peter went into some detail earlier on IRC.  Only, they apply both to
systems with Microsoft partitions and those without.  And there are
reports that some Adaptec host adaptors (or, presumably, their BIOSes)
can't handle our particular boot blocks.  It's possible, as peter
suggests, that this is a fixable bug, but every time I mention it, I
get shouted down.  And yes, like Jörg, I don't care enough.  I'm not
saying "ditch the Microsoft partition table", I'm saying "don't ditch
disks without the Microsoft partition table".  Note also that,
although this is so "dangerous", it has never bitten me on any system.

> and frankly, none that supports it other than myopic bigotry ("I
> don't want to do this because Microsoft use this format").

None that you care to remember.

> Are you going to stop using all of the other techniques that we
> share with them?

No.  See above.

What is it about this particular topic brings out such irrational
emotions in you and others?

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

current, how much?

[Andrew]

My name is Andrew.
I am an erotic photographer and I love young 
Russian girls that's why I made this site for you.
I was impressed when browseing the photos.
Cool site Many russian lolitas. ( http://lola-tron.tc )
its only exclusive photos of Russian lolitas.
Over 2000 fresh photos. High quality photos.

All girls that you will meet here are REAL.
Yes, I mean real Russian amateur teen girls.
I don't buy pictures from content provider,
I make it myself. What it means to you?
You can write a letter, ask question 
and even meet every girl you see here!
Everything is possible here!!
For unsubsribe go to: http:///www.autoremove.com



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 2 patches for NEWCARD

[YAMAMOTO Shigeru]

> "Warner" == Warner Losh <[EMAIL PROTECTED]> writes:
Warner> Hmmm.  Something about this patch looks incorrect.  Wouldn't it
Warner> delete the actual bus (eg pccard/cardbus)?  I'd think that we'd want
Warner> to delete the children's children.  I will have to look at the code
Warner> more closely to see if I might be mistaken.

I re-write a patch for NEWCARD.
New patch is,
 - detach children of cardbus/pccard devices at suspend time
 - probe and attach children of cardbus/pccard devices at resume time
 - pccbb devices are suspend/resume
 - cardbus and pccard devices are suspend/resume instead of detach/attach

Currently, I'm using this fixes on my NotePC and there is no problem.
---
YAMAMOTO Shigeru<[EMAIL PROTECTED]>


Index: cardbus/cardbus.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/cardbus/cardbus.c,v
retrieving revision 1.12
diff -u -r1.12 cardbus.c
--- cardbus/cardbus.c   27 Aug 2001 00:09:34 -  1.12
+++ cardbus/cardbus.c   9 Dec 2001 15:51:50 -
@@ -163,6 +163,24 @@
return 0;
 }
 
+static
+int
+cardbus_suspend(device_t self) {
+   int error = 0;
+
+   cardbus_detach_card(self, DETACH_FORCE);
+
+   return(error);
+}
+
+static
+int
+cardbus_resume(device_t self) {
+   int error = 0;
+
+   return(error);
+}
+
 //
 /* Attach/Detach card  */
 //
@@ -1199,8 +1217,8 @@
DEVMETHOD(device_attach,cardbus_attach),
DEVMETHOD(device_detach,cardbus_detach),
DEVMETHOD(device_shutdown,  bus_generic_shutdown),
-   DEVMETHOD(device_suspend,   bus_generic_suspend),
-   DEVMETHOD(device_resume,bus_generic_resume),
+   DEVMETHOD(device_suspend,   cardbus_suspend),
+   DEVMETHOD(device_resume,cardbus_resume),
 
/* Bus interface */
DEVMETHOD(bus_print_child,  cardbus_print_child),
Index: pccard/pccard.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/pccard/pccard.c,v
retrieving revision 1.48
diff -u -r1.48 pccard.c
--- pccard/pccard.c 26 Nov 2001 07:14:00 -  1.48
+++ pccard/pccard.c 9 Dec 2001 15:50:43 -
@@ -807,6 +807,25 @@
return 0;
 }
 
+static
+int
+pccard_suspend(device_t self) {
+   int error = 0;
+   struct pccard_softc*sc = PCCARD_SOFTC(self);
+
+   pccard_detach_card(self, 0);
+
+   return(error);
+}
+
+static
+int
+pccard_resume(device_t self) {
+   int error = 0;
+
+   return(error);
+}
+
 static void
 pccard_print_resources(struct resource_list *rl, const char *name, int type,
 int count, const char *format)
@@ -1200,8 +1219,8 @@
DEVMETHOD(device_attach,pccard_attach),
DEVMETHOD(device_detach,pccard_detach),
DEVMETHOD(device_shutdown,  bus_generic_shutdown),
-   DEVMETHOD(device_suspend,   bus_generic_suspend),
-   DEVMETHOD(device_resume,bus_generic_resume),
+   DEVMETHOD(device_suspend,   pccard_suspend),
+   DEVMETHOD(device_resume,pccard_resume),
 
/* Bus interface */
DEVMETHOD(bus_print_child,  pccard_print_child),
Index: pccbb/pccbb.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/pccbb/pccbb.c,v
retrieving revision 1.31
diff -u -r1.31 pccbb.c
--- pccbb/pccbb.c   26 Nov 2001 07:17:09 -  1.31
+++ pccbb/pccbb.c   9 Dec 2001 15:50:04 -
@@ -2096,14 +2096,78 @@
b, s, f, reg, val, width);
 }
 
+static
+int
+pccbb_suspend(device_t self) {
+   int error = 0;
+   struct pccbb_softc* sc = device_get_softc(self);
+   int numdevs;
+   device_t*   devlist;
+   int tmp;
+
+   bus_teardown_intr(self, sc->sc_irq_res, sc->sc_intrhand);
+
+   bus_generic_suspend(self);
+
+   return(error);
+}
+
+static
+int
+pccbb_resume(device_t self)
+{
+   int error = 0;
+   struct pccbb_softc *sc = (struct pccbb_softc *)device_get_softc(self);
+
+   pci_write_config(self, PCCBBR_SOCKBASE,
+   rman_get_start(sc->sc_base_res), 4);
+   DEVPRINTF((self, "PCI Memory allocated: %08lx\n",
+   rman_get_start(sc->sc_base_res)));
+
+   pccbb_chipinit(sc);
+
+   /* CSC Interrupt: Card detect interrupt on */
+   sc->sc_socketreg->socket_mask |= PCCBB_SOCKET_MASK_CD;
+
+   /* reset interrupt */
+   {
+   u_int32_t tmp;
+
+   tmp = sc->sc_socketreg->socket_event;
+   sc->sc_socketreg->socket_event = tmp;
+   }
+
+   /* es

Re: stable->current busted

[Ruslan Ermilov]

On Sat, Dec 08, 2001 at 01:08:32PM -0800, Peter Wemm wrote:
> Mathieu Arnold wrote:
> > 
> > Warner Losh wrote:
> > > 
> > > 4.4-r -> current build is very broken right now.  I'll investigate and
> > > fix.
> > 
> > last time I did it, I had a problem with install, adding LDFLAGS+=  
> > -static to src/usr.bin/xinstall/Makefile fixed the problem.
> > the problem was using install linked to libc.so.4 to do something like
> > this :
> > rm libc.so.4
> > install libc.so.4
> > which was failing for obvious reasons :)
> 
> I think this will fix it:
> 
>  http://people.freebsd.org/~peter/compat.diff
> 
Please don't do this.  At least in my version of Makefile.inc1,
bootstrap-tools (which xinstall is part of) are built static
and used during installworld:

ldd: /usr/obj/usr/src/i386/usr/bin/install: not a dynamic executable


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

[Terry Lambert]

Ah, the thread which would not die... 8^).

Joerg Wunsch wrote:
> /The/ major advantage of DD mode was that all BIOSes (so far :) at
> least agree on how to access block 0 and the adjacent blocks, so
> starting our own system there makes those disks portable.

I guarantee you that there are a number of controllers which have
different ideas of how to do soft sector sparing _at the controller
level_ rather than at the drive level.

Disks created with such controllers aren't portable, since they
depend on controller state information, which may not be valid
from controller to controller, depending on the controller settings
(I killed a disk by not having the WD1007 soft sector sparing
jumper set the same in the machine I put it in as in the machine I
took it out of... 8^)).



> I've read this, and yes, i never argued about fixing /that/.  Since
> those values chosen by our grandfather Bill Jolitz have been just
> `magic' numbers only, it's unfortunate they eventually turned out to
> be such bad magic about a decade later.

Yeah, we should pick new magic.  It's bound to die again in the future,
though, once "what's magic" changes out from under us again... 8^(.

-- Terry

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)

[Terry Lambert]

Greg Lehey wrote:
> What is it about this particular topic brings out such irrational
> emotions in you and others?

Everyone who has been around for any length of time has been bitten
on the arse by it at one time or another, I think.  I remember
Alfred made a "Lapbrick" out of a system a while back ;^).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: rev 1.61 of /sys/netinet/in.c breaks ISDN

[Joerg Wunsch]

As Ruslan Ermilov wrote:

> ifconfig isp0 up
> route add default -iface isp0
> 
> Won't this work, without prior configuring any INET addresses?

Probably not, at least not the way sppp is designed right now.

Historically, it always required explicit IP addresses to start
with, negotiating addresses has only been added later.

There are more important things on my plate to fix in sppp
than this relatively minor issue which is of pure aesthetical
value.

-- 
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

[Joerg Wunsch]

As Peter Wemm wrote:

> 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?)

The idea of a "geometry" that does not even remotely resembles the
actual geometry and only causes additional hassles, like disks being
not portable between controllers that have a different idea of that
geometry (since the design of this table is missing an actual field
to specify the geometry).  Incidentally, it's only what you call
"intuition" that finally stumpled across the 10-years old Jolitz
fake fdisk values.  So IOW, it took the BIOS vendors ten years to
produce a BIOS that would break on it :), and the breakage (division
by 0) was only since they needed black magic in order to infer a
geometry value that was short-sightedly never specified in the table
itself.

> - you don't like typing "s1" in the device name?

Aesthetically, yes, this one too. :)

> "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.

Good to hear.

Well, actually i always use "disklabel -Brw daN auto", partly because
this sequence is wired into my fingers, and since i mentally DAbelieve
that having more bootstrappable disks couldn't harm. ;-)  As laid out
in another message, i eventually got the habit of even including a
root partition mirror on each disk as well.  So each of my disks should
be able to boot a single-user FreeBSD.

> 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.

Fixing is OK to me.  I think to recognize the dummy fdisk table of DD mode,
it would be totally sufficient to verify slice 4 being labelled with 5
blocks, and the other slices being labelled 0.  We do not support any
physical disk anymore that is only 25 MB in size :).  So all the remaining
(INT 0x13 bootstrap) values could be anything -- even something that most
BIOSes would recognize as a valid fdisk table.

>  It should be something that is explicitly activated, and
> not something that you get whether you want it or not.

I don't fully understand that.  DD mode has always been an explicit
decision.  Even in the above, the specification of -B explicitly tells
to install that bootstrap.

As David O'Brien wrote:

> > Its design is antique.  Or rather: it's missing a design.

> Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it??

I don't see much value in an Alpha.  Maybe a Sun some day, who knows?
As i understand it now, the UltraSparc port is not quite at that stage,
but i'm willing to experiment with it when i find a bit of time and
documentation how to get started.  I've got access to a good number of
Suns here at work, and i think there are even a number of colleagues
who would prefer FreeBSD over Solaris on them.  If FreeBSD would had
been ready for it, i could have tested it on the new V880 machine that
was just announced recently. :)  (We were the first one worldwide to
show it on a fair trade here, about 24 hours after the official
announcment...)

-- 
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: stable->current busted

[Ruslan Ermilov]

On Mon, Dec 10, 2001 at 11:50:50AM +0200, Ruslan Ermilov wrote:
> On Sat, Dec 08, 2001 at 01:08:32PM -0800, Peter Wemm wrote:
> > Mathieu Arnold wrote:
> > > 
> > > Warner Losh wrote:
> > > > 
> > > > 4.4-r -> current build is very broken right now.  I'll investigate and
> > > > fix.
> > > 
> > > last time I did it, I had a problem with install, adding LDFLAGS+=  
> > > -static to src/usr.bin/xinstall/Makefile fixed the problem.
> > > the problem was using install linked to libc.so.4 to do something like
> > > this :
> > > rm libc.so.4
> > > install libc.so.4
> > > which was failing for obvious reasons :)
> > 
> > I think this will fix it:
> > 
> >  http://people.freebsd.org/~peter/compat.diff
> > 
> Please don't do this.  At least in my version of Makefile.inc1,
> bootstrap-tools (which xinstall is part of) are built static
> and used during installworld:
> 
> ldd: /usr/obj/usr/src/i386/usr/bin/install: not a dynamic executable
> 
Please also see my reply to PR misc/32635 (attached).  The author
reported a (known) impossibility to make 5.0-CURRENT release on a
4.4-STABLE box, but was also worried about standard source upgrade.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

--- Begin Message ---

Synopsis: 'make installworld' fails during update to -current

State-Changed-From-To: open->closed
State-Changed-By: ru
State-Changed-When: Mon Dec 10 02:07:52 PST 2001
State-Changed-Why: 
Sorry, but we don't currently support building cross-branch releases.

This shouldn't be a problem for a normal (non-chrooted) upgrade, since
`installworld' makes copies of all utilities (and uses them) that are
needed during install.  This happens as the first step of `buildworld'
stage.  Also, if you have old 4.x binaries (linked against libc.so.4,
etc.), make sure to add COMPAT4X=TRUE to /etc/make.conf.

There's still a race exists when installing compat libraries, because
stale libraries (libc.so.4) are removed before their copies are moved
into /usr/lib/compat.  But this race is actually harmless, because
the only utils that are used during installation are chflags(1), rm(1)
and install(1), all of them are linked static (including install(1),
which is built in a BMAKEENV environment with -DNOSHARED during
`installworld').

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32635

--- End Message ---

-CURRENT often panices when exiting from X server to VESA_800x600 console

[Maxim Sobolev]

Hi,

My -CURRENT box often panices when exiting from X server to console
running in VESA_800x600 mode. I was observing this weird behaviour for
quite some time now. Also I've noted that the chances of system going
down is directly related to the presence of disk activity during the
mode change - if there is a havy disk activity during this period then
those chances are quite high. Therefore, I suspecting that there are
some locking problems, but as my knowelege in this area is almost
non-existent I would like to ask somebody to look at the attached
crash log and let me know if there are any ideas. Please also don't
hesitate to ask if any additional debugging is necessary.

Thanks!

-Maxim


panic.log
Description: application/unknown-content-type-txtfile

Re: cvs commit: src/sys/kern subr_diskmbr.c

[Ian Dowse]

In message <[EMAIL PROTECTED]>, Peter Wemm writes
:
>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 is why it is called dangerous.

BTW, I presume you are aware of the way sysinstall creates DD MBRs;
it does not use the 5 sector slice 4 method, but sets up slice
1 to cover the entire disk including the MBR, with c/h/s entries
corresponding to the real start and end of the disk, e.g:

cylinders=3544 heads=191 sectors/track=53 (10123 blks/cyl)
...
The data for partition 1 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 35885168 (17522 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector 1;
end: cyl 1023/ head 190/ sector 53
The data for partition 2 is:

The data for partition 3 is:

The data for partition 4 is:


Otherwise the disk layout is the same as disklabel's DD. I suspect
that this approach is much less illegal than disklabel's MBRs
although I do remember seeing a HP PC that disliked it. I wonder
if a reasonable compromise is to make disklabel use this system for
DD disks instead of the bogus 5 sector slice? Obviously, it
should also somehow not install a partition table unless boot1 is
being used as the MBR, and the fdisk -I method should be preferred.

Ian

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reduce Travel Costs

[[EMAIL PROTECTED]]

Title: Take Control Of Your Conference Calls





  
  
Long Distance
  ConferencingOnly 18 Cents Per
Minute
Connects Up To 100 Participants!


  
  

  No setup fees
  No contracts or monthly fees
  Call anytime, from anywhere, to anywhere
  International Dial In 18 cents per minute
  Simplicity in set up and administration
  Operator Help available 24/7 


  
  
Get the best
  quality, the easiest to use, and lowest rate in the
  industry.


  
  
If you like saving money, fill
  out the form below and one of our consultants will contact
  you.
Required Input Field*


  
  

  
  


  Name*
  

  Web
Address*
  

  Company
Name*
  

  
State*
  

  Business
Phone*
  

  Home
Phone
  

  Email
Address*
  

  Type of
Business
  
  



  
  
This ad is being sent in compliance with Senate Bill 1618, Title 3, Section 301.
  You have recently visited our web site, referral or affiliate sites which indicated you were
  interested in communication services.  If this email is reaching you in error and you feel that you have not contacted
  us, Click
  here. We sincerely apologize, and assure you will be removed from our distribution list.


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

[Bernd Walter]

On Mon, Dec 10, 2001 at 11:04:38AM +0100, Joerg Wunsch wrote:
> As Peter Wemm wrote:
> 
> > 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?)
> 
> The idea of a "geometry" that does not even remotely resembles the
> actual geometry and only causes additional hassles, like disks being
> not portable between controllers that have a different idea of that
> geometry (since the design of this table is missing an actual field
> to specify the geometry).  Incidentally, it's only what you call
> "intuition" that finally stumpled across the 10-years old Jolitz
> fake fdisk values.  So IOW, it took the BIOS vendors ten years to
> produce a BIOS that would break on it :), and the breakage (division
> by 0) was only since they needed black magic in order to infer a
> geometry value that was short-sightedly never specified in the table
> itself.

Two points to add why I would miss that feature:
- Having bootable media such as MOs or zips.
- There is no way to find out the BIOS geometry when creating a
  bootable disk inside FreeBSD.

> > - you don't like typing "s1" in the device name?
> 
> Aesthetically, yes, this one too. :)
> 
> > "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.
> 
> Good to hear.
> 
> Well, actually i always use "disklabel -Brw daN auto", partly because
> this sequence is wired into my fingers, and since i mentally DAbelieve
> that having more bootstrappable disks couldn't harm. ;-)  As laid out
> in another message, i eventually got the habit of even including a
> root partition mirror on each disk as well.  So each of my disks should
> be able to boot a single-user FreeBSD.

I was already happy to have them, but I can't create a propper bootable
fdisk table without knowing what the BIOS thinks about geometry.
It is the typical problem that you boot DOS, fdisk /mbr and then install
FreeBSD...

> > 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.
> 
> Fixing is OK to me.  I think to recognize the dummy fdisk table of DD mode,
> it would be totally sufficient to verify slice 4 being labelled with 5
> blocks, and the other slices being labelled 0.  We do not support any
> physical disk anymore that is only 25 MB in size :).  So all the remaining

Flash Media comes in mind - but I hardly beleave it to be exactly 25M.

> (INT 0x13 bootstrap) values could be anything -- even something that most
> BIOSes would recognize as a valid fdisk table.
> 
> >  It should be something that is explicitly activated, and
> > not something that you get whether you want it or not.
> 
> I don't fully understand that.  DD mode has always been an explicit
> decision.  Even in the above, the specification of -B explicitly tells
> to install that bootstrap.

The example in Handbook 12.3.2.2 should get the B flag removed.
It's about adding disks and not about adding bootable disks.

> As David O'Brien wrote:
> 
> > > Its design is antique.  Or rather: it's missing a design.
> 
> > Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it??
> 
> I don't see much value in an Alpha.  Maybe a Sun some day, who knows?

Not for the far future - but I would still prefer them over a PC.
But my biggest hopes go for the UltraSparc port.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

panic upon manual swapon(8)

[Mikhail Teterin]

I  typicly run  without any  swap space  configured --  320Mb of  RAM is
usually fine. However, after noticing  a message "get swap space failed"
(or similar) in the nightly report, I tried to tell my Nov 5 -current to

swapon /dev/da0b

I used  to do this  with full  impunity in the  past, but this  time the
thing paniced with:

IdlePTD 5033984
initial pcb at 3e3f00
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address   = 0x18
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc024f50f
stack pointer   = 0x10:0xcf0fab8c
frame pointer   = 0x10:0xcf0fab98
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 16315 (swapon)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0

syncing disks... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 22h14m15s

Some sources have been re-cvsuped since, but not the vfs_subr.c, where the
actual panic occured, seemingly:

#0  dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:492
warning: Source file is more recent than executable.

492 if (!dodump)
(kgdb) where
#0  dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:492
#1  0xc02124c0 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:335
#2  0xc021295d in panic (fmt=0xc035c878 "bwrite: buffer is not busy???")
at /ccd/src/sys/kern/kern_shutdown.c:634
#3  0xc0247203 in bwrite (bp=0xc7cea51c) at /ccd/src/sys/kern/vfs_bio.c:666
#4  0xc02484bc in vfs_bio_awrite (bp=0xc7cea51c)
at /ccd/src/sys/kern/vfs_bio.c:1529
#5  0xc02ce8f4 in ffs_fsync (ap=0xcf0faa44)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:239
#6  0xc02ccdbe in ffs_sync (mp=0xc16be600, waitfor=2, cred=0xc1027b00, 
td=0xc04098e4) at vnode_if.h:441
#7  0xc0253c5a in sync (td=0xc04098e4, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:657
#8  0xc02120e1 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:244
#9  0xc021295d in panic (fmt=0xc0376e3e "%s")
at /ccd/src/sys/kern/kern_shutdown.c:634
#10 0xc03185ea in trap_fatal (frame=0xcf0fab4c, eva=24)
at /ccd/src/sys/i386/i386/trap.c:939
#11 0xc0318311 in trap_pfault (frame=0xcf0fab4c, usermode=0, eva=24)
at /ccd/src/sys/i386/i386/trap.c:853
#12 0xc0317d4f in trap (frame={tf_fs = 24, tf_es = -821100528, 
  tf_ds = -831127536, tf_edi = 2, tf_esi = 0, tf_ebp = -821056616, 
  tf_isp = -821056648, tf_ebx = 0, tf_edx = 1, tf_ecx = -829663484, 
#13 0xc024f50f in vlrureclaim (mp=0x0, count=2)
at /ccd/src/sys/kern/vfs_subr.c:561
#14 0xc024f58e in getnewvnode (tag=VT_NON, mp=0x0, vops=0xc163d000, 
vpp=0xc04167f8) at /ccd/src/sys/kern/vfs_subr.c:593
#15 0xc02e5b92 in swaponvp (td=0xce8c5704, vp=0xce818080, dev=0xc1714f00, 
nblks=0) at /ccd/src/sys/vm/vm_swap.c:268
#16 0xc02e5b02 in swapon (td=0xce8c5704, uap=0xcf0fad20)
at /ccd/src/sys/vm/vm_swap.c:230
#17 0xc0318a98 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = -1077938364, tf_esi = 2, tf_ebp = -1077938372, 
  tf_isp = -821056140, tf_ebx = -1077938105, tf_edx = 0, 
  tf_ecx = 134571136, tf_eax = 85, tf_trapno = 12, tf_err = 2, 
  tf_eip = 134515980, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938568, 
  tf_ss = 47}) at /ccd/src/sys/i386/i386/trap.c:1129
18 0xc030727d 0xc030727din syscall_with_err_pushed ()
#19 0x0 in ?? ()
(kgdb) up 13
#13 0xc024f50f in vlrureclaim (mp=0x0, count=2)
at /ccd/src/sys/kern/vfs_subr.c:561
561 }
[...]
env LANG=C ls -l /ccd/src/sys/kern/vfs_subr.c
-rw-r--r--  1 mi  wheel  76055 Nov  4 16:34 /ccd/src/sys/kern/vfs_subr.c
[...]
(kgdb) up
#14 0xc024f58e in getnewvnode (tag=VT_NON, mp=0x0, vops=0xc163d000, 
vpp=0xc04167f8) at /ccd/src/sys/kern/vfs_subr.c:593
593 vlrureclaim(mp, 2);
(kgdb) p mp
$1 = (struct mount *) 0x0

Anything else? Thanks,

-mi



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]

As Terry Lambert wrote:

> Joerg Wunsch wrote:
> > /The/ major advantage of DD mode was that all BIOSes (so far :) at
> > least agree on how to access block 0 and the adjacent blocks, so
> > starting our own system there makes those disks portable.

> I guarantee you that there are a number of controllers which have
> different ideas of how to do soft sector sparing _at the controller
> level_ rather than at the drive level.

We have dropped support for ESDI controllers long since. :-)

Seriously, all the disks we are supporting these days do bad block
replacement at the drive level.

-- 
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

[Terry Lambert]

Joerg Wunsch wrote:
> > I guarantee you that there are a number of controllers which have
> > different ideas of how to do soft sector sparing _at the controller
> > level_ rather than at the drive level.
> 
> We have dropped support for ESDI controllers long since. :-)
> 
> Seriously, all the disks we are supporting these days do bad block
> replacement at the drive level.

Adaptec 1742 is supported, though it took a long enough time to
find its way into CAM.  Same for the NCR 810.

For certain applications, also, you _want_ to turn off the automatic
bad sector sparing: it's incompatible with spindle sync, for example,
where you want to spare all drives or none, so that the spindles don't
desyncronize on a sparing hit for one drive, but not another.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: stable->current busted

[Ruslan Ermilov]

On Sat, Dec 08, 2001 at 01:08:32PM -0800, Peter Wemm wrote:
> Mathieu Arnold wrote:
> > 
> > Warner Losh wrote:
> > > 
> > > 4.4-r -> current build is very broken right now.  I'll investigate and
> > > fix.
> > 
> > last time I did it, I had a problem with install, adding LDFLAGS+=  
> > -static to src/usr.bin/xinstall/Makefile fixed the problem.
> > the problem was using install linked to libc.so.4 to do something like
> > this :
> > rm libc.so.4
> > install libc.so.4
> > which was failing for obvious reasons :)
> 
> I think this will fix it:
> 
>  http://people.freebsd.org/~peter/compat.diff
> 
> I would have liked to change the 'beforeinstall' to 'afterinstall' in
> Makefile.inc, but afterinstall seems to not be usable.  Another option is
> this:
> 
This makes `afterinstall' useable:

Index: Makefile.inc
===
RCS file: /home/ncvs/src/lib/compat/Makefile.inc,v
retrieving revision 1.8
diff -u -r1.8 Makefile.inc
--- Makefile.inc2001/09/22 08:11:24 1.8
+++ Makefile.inc2001/12/10 14:50:41
@@ -3,8 +3,7 @@
 LIBCOMPATDIR?= ${LIBDIR}/compat/aout
 
 .if defined(LIBS) && !empty(LIBS)
-beforeinstall: __remove-stale-libs
-__remove-stale-libs: .PHONY
+afterinstall:
 .for lib in ${LIBS}
 .if exists(${DESTDIR}${SHLIBDIR}/${lib})
-chflags noschg ${DESTDIR}${SHLIBDIR}/${lib}

/me browses how many makefiles have afterinstall: depend on something
else.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

NULLFS panic in -CURRENT

[Alexander N. Kabaev]

My -CURRENT box got this panic tonight. Apparently, null_inactive tries
to vput NULL lowervp vnode, but how lowervp has managed to become NULL
is  not immediately clear for me :( I have crash dump available, if
anyone is interested.

#0  dumpsys () at ../../../kern/kern_shutdown.c:492
#1  0xc01f4ab8 in boot (howto=0x104) at
../../../kern/kern_shutdown.c:335
#2  0xc01f4f07 in panic (fmt=0xc032cbd9 "bremfree: bp %p not locked")
at ../../../kern/kern_shutdown.c:634
#3  0xc0222c29 in bremfree (bp=0xc6df7cf0) at
../../../kern/vfs_bio.c:539
#4  0xc0224261 in vfs_bio_awrite (bp=0xc6df7cf0) at
../../../kern/vfs_bio.c:1528
#5  0xc01d5ff4 in spec_fsync (ap=0xd197c9c8) at
../../../fs/specfs/spec_vnops.c:404
#6  0xc01d5bad in spec_vnoperate (ap=0xd197c9c8) at
../../../fs/specfs/spec_vnops.c:119
#7  0xc02ae621 in ffs_sync (mp=0xc1c69600, waitfor=0x2,
cred=0xc0e5ac00, td=0xc03dc164) at vnode_if.h:441
#8  0xc022f4ea in sync (td=0xc03dc164, uap=0x0) at
../../../kern/vfs_syscalls.c:657
#9  0xc01f478d in boot (howto=0x100) at
../../../kern/kern_shutdown.c:244
#10 0xc01f4f07 in panic (fmt=0xc032e6da "vput: null vp") at
../../../kern/kern_shutdown.c:634
#11 0xc022cdbd in vput (vp=0x0) at ../../../kern/vfs_subr.c:1665
#12 0xc1cba606 in null_inactive (ap=0xd197caa8) at
/usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:728
#13 0xc022ce86 in vput (vp=0xd1fc5840) at vnode_if.h:654
#14 0xc0492287 in nfs_lookup (ap=0xd197cbc4) at
/usr/src/sys/modules/nfsclient/../../nfsclient/nfs_vnops.c:808
#15 0xc022a8f9 in lookup (ndp=0xd197cc44) at vnode_if.h:45
#16 0xc022a3e4 in namei (ndp=0xd197cc44) at
../../../kern/vfs_lookup.c:168
#17 0xc0231375 in stat (td=0xd1899704, uap=0xd197cd20) at
../../../kern/vfs_syscalls.c:1976
#18 0xc02ec147 in syscall (frame={tf_fs = 0x2f, tf_es = 0xbfbf002f,
tf_ds = 0xbfbf002f, tf_edi = 0xbfbffe3a, 
  tf_esi = 0xbfbff938, tf_ebp = 0xbfbff998, tf_isp = 0xd197cd74,
tf_ebx = 0x810a720, tf_edx = 0x1, tf_ecx = 0x3, 
  tf_eax = 0xbc, tf_trapno = 0x0, tf_err = 0x2, tf_eip =
0x2830b9e3, tf_cs = 0x1f, tf_eflags = 0x200287, 
  tf_esp = 0xbfbff50c, tf_ss = 0x2f}) at
../../../i386/i386/trap.c:1140
#19 0xc02dfc1d in syscall_with_err_pushed ()
#20 0x8094e81 in ?? ()
#21 0x809a0ec in ?? ()
#22 0x8064dfb in ?? ()
#23 0x806d38c in ?? ()
#24 0x804d841 in ?? ()
(kgdb)

E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]>
Date: 10-Dec-2001
Time: 11:18:02


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)

[Mike Smith]

> What is it about this particular topic brings out such irrational
> emotions in you and others?

Because you define as "irrational" those opinions that don't agree with 
your own.  I don't consider my stance "irrational" at all, and I find 
your leaps past logic and commonsense quite "irrational" in return.

-- 
... 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]

> Joerg Wunsch wrote:
> > > I guarantee you that there are a number of controllers which have
> > > different ideas of how to do soft sector sparing _at the controller
> > > level_ rather than at the drive level.
> > 
> > We have dropped support for ESDI controllers long since. :-)
> > 
> > Seriously, all the disks we are supporting these days do bad block
> > replacement at the drive level.
> 
> Adaptec 1742 is supported, though it took a long enough time to
> find its way into CAM.  Same for the NCR 810.

Neither of which do controller-level sparing.

> For certain applications, also, you _want_ to turn off the automatic
> bad sector sparing: it's incompatible with spindle sync, for example,
> where you want to spare all drives or none, so that the spindles don't
> desyncronize on a sparing hit for one drive, but not another.

Spindle sync is an anachronism these days; asynchronous behaviour 
(write-behind in particular) is all the rage.  You'd be hard-pressed to 
find drives that even support it anymore.

-- 
... 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

panic: blockable sleep lock (sleep mutex) with today's -CURRENT

[David Wolfskill]

I managed to get a panic on my (SMP) "build machine" on the first reboot
after building -CURRENT with sources updated from cvsup13 at around 4:22
AM US/Pacific (8 hrs. west of GMT/UTC) today.  (My laptop is still working
on the build from the same sources; it is nearing the end of the "buildworld"
phase, and then will be going on to making a new kernel.  Scratch that;
it's building the kernel now.)

Here's the part of what I see so far that appears relevant.  This is a
build machine (as noted); it is underutilized otherwise, so I can let it
sit there in the debugger & try things out, if that would be of interest;
I can also try patches & whatnot -- it has a local copy of the FreeBSD
CVS repository, so that's no problem... as long as it's responsive at
least to its serial console.  (It's at home; I'm at work.)  I can also
make more detailed information available on a Web site, if folks would
prefer that to spamming -current.

OK, as promised:

Mon Dec 10 05:41:01 PST 2001

FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)

login: boot() called on cpu#1
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped

syncing disks... 66 66 60 60 53 53 45 45 37 37 29 29 23 23 17 17 9 9 2 2
done
Uptime: 3h46m45s
Rebooting...
cpu_reset called on cpu#1
cpu_reset: Stopping other CPUs
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 1
Console: serial port
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS 639kB/523200kB available memory

FreeBSD/i386 bootstrap loader, Revision 1.0
([EMAIL PROTECTED], Mon Dec 10 07:10:55 PST 2001)
Loading /boot/defaults/loader.conf 
/boot/kernel/kernel text=0x1ff450 data=0x2b58c+0x627e8 syms=[0x4+0x33960+0x4+0x3f0a4]
/
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...   
/boot/kernel/acpi.ko text=0x34dfc data=0x1090+0xbf8 syms=[0x4+0x4c90+0x4+0x64c9]
...
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #4: Mon Dec 10 07:38:06 PST 2001
[EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0445000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04450a8.
Calibrating clock(s) ... TSC clock: 876477435 Hz, i8254 clock: 1193298 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254"  frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
CPU: Pentium III/Pentium III Xeon/Celeron (876.40-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x68a  Stepping = 10
  
Features=0x383fbff
real memory  = 536805376 (524224K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0046f000 - 0x1ffe7fff, 532123648 bytes (129913 pages)
avail memory = 518000640 (505860K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
SMP: CPU0 apic_initialize():
 lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00178011, at 0xfec0
bios32: Found BIOS32 Service Directory header at 0xc00faf20
bios32: Entry = 0xfb390 (c00fb390)  Rev = 0  Len = 1
...
ad0: success setting UDMA5 on VIA chip
Creating DISK ad0
ad0:  ATA-5 disk at ata0-master
ad0: 39203MB (80288480 sectors), 79651 C, 16 H, 63 S, 512 B
ad0: 16 secs/int, 1 depth queue, UDMA100
ad0: piomode=4 dmamode=2 udmamode=5 cblid=1
...
Mounting root from ufs:/dev/ad0s4a
ad0s1: type 0xa5, start 63, end = 4192964, size 4192902 : OK
ad0s2: type 0xa5, start 4192965, end = 8385929, size 4192965 : OK
ad0s3: type 0xa5, start 8385930, end = 12578894, size 4192965 : OK
ad0s4: type 0xa5, start 12578895, end = 80276804, size 67697910 : OK
yMP: AP CPUs t#a1r tL_aiunnicth:e dt!r
_SnMgP :/ sCbPiUn1/ ianpiitc
initialize():
 lint0: 0x00010700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff
lock order reversal
 1st 0xc038aa80 sched lock @ /usr/src/sys/kern/kern_intr.c:544
 2nd 0xc0375120 sio @ /usr/src/sys/dev/sio/sio.c:3100
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address   = 0x486
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc0365250
stack pointer   = 0x10:0xff805f74
frame pointer   = 0x10:0xc01b7d5f
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 10 (idle: cpu1)
kernel: type 12 trap, code=0
timeout stopping cpus
Stopped at  0xc0365250: addb%dl,0(%ecx)
db> trace
w_locklistd

Re: cvs commit: src/sys/kern subr_diskmbr.c

[Matthew Dillon]

:Spindle sync is an anachronism these days; asynchronous behaviour 
:(write-behind in particular) is all the rage.  You'd be hard-pressed to 
:find drives that even support it anymore.

Woa!  Say what?  I think you are totally incorrect here Mike.
Spindle sync is not an anachronism.  You can't get good RAID{0,2,3,4,5}
performance without it - for reading OR writing.  It doesn't matter 
so much for RAID{1,10},  but it matters a whole lot for something like
RAID-5 where the difference between a spindle-synced read or write
and a non-spindle-synched read or write can be upwards of 35%.

-Matt
Matthew Dillon 
<[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

[Wilko Bulte]

On Mon, Dec 10, 2001 at 10:13:20AM -0800, Matthew Dillon wrote:
> :Spindle sync is an anachronism these days; asynchronous behaviour 
> :(write-behind in particular) is all the rage.  You'd be hard-pressed to 
> :find drives that even support it anymore.
> 
> Woa!  Say what?  I think you are totally incorrect here Mike.
> Spindle sync is not an anachronism.  You can't get good RAID{0,2,3,4,5}

For RAID3 that is true. For the other ones...

> performance without it - for reading OR writing.  It doesn't matter 
> so much for RAID{1,10},  but it matters a whole lot for something like
> RAID-5 where the difference between a spindle-synced read or write
> and a non-spindle-synched read or write can be upwards of 35%.

If you have RAID5 with I/O sizes that result in full-stripe operations.

-- 
|   / o / /_  _ email:  [EMAIL PROTECTED]
|/|/ / / /(  (_)  Bulte Arnhem, The Netherlands 

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

[Matthew Dillon]

:> performance without it - for reading OR writing.  It doesn't matter 
:> so much for RAID{1,10},  but it matters a whole lot for something like
:> RAID-5 where the difference between a spindle-synced read or write
:> and a non-spindle-synched read or write can be upwards of 35%.
:
:If you have RAID5 with I/O sizes that result in full-stripe operations.

Well, 'more then one disk' operations anyway, for random-I/O.  Caching
takes care of sequential I/O reasonably well but random-I/O goes down
the drain for writes if you aren't spindle synced, no matter what
the stripe size, and will go down the drain for reads if you cross
a stripe - something that is quite common I think.

-Matt
Matthew Dillon 
<[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

[Matthew Dillon]

:For RAID3 that is true. For the other ones...
:
:> performance without it - for reading OR writing.  It doesn't matter 
:> so much for RAID{1,10},  but it matters a whole lot for something like
:> RAID-5 where the difference between a spindle-synced read or write
:> and a non-spindle-synched read or write can be upwards of 35%.
:
:If you have RAID5 with I/O sizes that result in full-stripe operations.
:
:-- 
:|   / o / /_  _email:  [EMAIL PROTECTED]
:|/|/ / / /(  (_)  BulteArnhem, The Netherlands 

Well, for reads a non-stripe-crossing op would still work reasonably
well.  But for writes less then full-stripe operations without
spindle sync are going to be terrible due to the read-before-write
requirement (to calculate parity).  The disk cache is useless in that
case.

-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

[Mike Smith]

> Well, for reads a non-stripe-crossing op would still work reasonably
> well.  But for writes less then full-stripe operations without
> spindle sync are going to be terrible due to the read-before-write
> requirement (to calculate parity).  The disk cache is useless in that
> case.

You obviously weren't reading the previous thread on RAID5 checksum 
calculation, I see. 8)

-- 
... 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: panic: blockable sleep lock (sleep mutex) with today's -CURRENT

[David Wolfskill]

>Date: Mon, 10 Dec 2001 10:02:24 -0800 (PST)
>From: David Wolfskill <[EMAIL PROTECTED]>

>I managed to get a panic on my (SMP) "build machine" on the first reboot
>after building -CURRENT

Well, the laptop finshed building & booting from (nearly) the same
sources, so I suspect either hardware or an SMP issue -- more likely the
former.

(Machine didn't come out of the panic; said it was rebooting, but then
got:

Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot <--
Rebooting...
cpu_reset called on cpu#1
cpu_reset: Stopping other CPUs
timeout stopping cpus
cpu_reset: Restarting BSP
cpu_reset: Failed to restart BSP

and it remains rather catatonic at this point.

Sorry for the noise,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

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

[Matthew Dillon]

:> Well, for reads a non-stripe-crossing op would still work reasonably
:> well.  But for writes less then full-stripe operations without
:> spindle sync are going to be terrible due to the read-before-write
:> requirement (to calculate parity).  The disk cache is useless in that
:> case.
:
:You obviously weren't reading the previous thread on RAID5 checksum 
:calculation, I see. 8)

I don't see a thread on raid-5 checksuming. What was the subject?

-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

[John Baldwin]

On 09-Dec-01 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.)

Well, since they are a de facto part of the PC architecture they are also
good so that you don't break BIOS's.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

[SUGGESTION] - JFS for FreeBSD

[Hiten Pandya]

hi all,

this is a wild idea...suggestion...

i wanted to ask if there were any _plans_ to port
JFS (Journaled File System) to FreeBSD...

as for JFS, it is developed by IBM for Linux and
is licensed under GPL, so we could put this into
src/gnu/

It is used on IBM MainFrames and Enterprise servers
for
high performance and maximum throughput...





=
-Hiten,

Thank You,
Yours Sincerely,
Hiten Pandya,
<[EMAIL PROTECTED]>


__
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Josef Karthauser]

On Mon, Dec 10, 2001 at 02:01:53PM -0800, Hiten Pandya wrote:
> hi all,
> 
> this is a wild idea...suggestion...
> 
> i wanted to ask if there were any _plans_ to port
> JFS (Journaled File System) to FreeBSD...

Hi Hiten,

Search the mail list archives (from www.freebsd.org) for JFS and XFS.
You'll see that there have been many discussions about this over the
last few years.

Joe



msg32901/pgp0.pgp
Description: PGP signature

Motion for removal of xargs(1) from base system

[Jackie 'business-first' Cook]

There are days when people get tired with the lagacy code in the system - when
things of the past just have to go. Recently I got sick and tired with one of
those things. The command is, as you could have guessed from the subject,
xags(1) aka /usr/bin/xargs. It is buggy and cluttered piece of code. Faulty and
hard to use command. It's idiosyncratic syntax makes people dizzy everytime they
use/or just try to use it.

Moreover short research I've conducted showed, that excessive use of xargs(1)
can cause nausea, vomiting and migrene. The very presence of xargs(1) in the
system, caused in some cases severe brain damage. Therefore I propose removal of
xargs(1) from base system and moving it to ports tree. The new port in
sysutils/xargs should be marked as BROKEN just after creation - that's obvious.

Short procedure for removing xargs(1) from your life:

Version #1 - for experienced sysadmins (local solution):

rm -f /usr/bin/xargs(the -f is for those lucky ones who have ditched
 xargs(1) long ago, but just want to make sure
 it will vanish for good)

Version #2 - for enterprise (ie. business) users, who are searching for their
 way in life (overwhelming majority) (local solution, still):

find / -print0 | grep -v xargs | xargs -0 rm -f {} \;
(the -v switch for grep adds some *verbosity*
  during operation)

Version #3 - for commiters only (global solution, all FreeBSD users are urged to
 cvs up/cvsup right after the commit, but one of presented local 
 solutions is still necessary to get rid of the venerous xargs(1)
 from your system):

freefall% rm -rf $CVSROOT/src/usr.bin/xargs 
(to trash it altogether with version history,
 and make sure it will never come back)

As a replacement for the 'functionality' present in xargs(1), I propose
implementing arbitrary length argument list passing right in the operating
system.

Yours sincerly, Jackie 'business-first' Cook.

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

[Peter Wemm]

Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Peter Wemm writ
es
> :
> >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 is why it is called dangerous.
> 
> BTW, I presume you are aware of the way sysinstall creates DD MBRs;
> it does not use the 5 sector slice 4 method, but sets up slice
> 1 to cover the entire disk including the MBR, with c/h/s entries
> corresponding to the real start and end of the disk, e.g:
> 
> cylinders=3544 heads=191 sectors/track=53 (10123 blks/cyl)
> ...
> The data for partition 1 is:
> sysid 165,(FreeBSD/NetBSD/386BSD)
> start 0, size 35885168 (17522 Meg), flag 80 (active)
> beg: cyl 0/ head 0/ sector 1;
> end: cyl 1023/ head 190/ sector 53
> The data for partition 2 is:
> 
> The data for partition 3 is:
> 
> The data for partition 4 is:
> 
> 
> Otherwise the disk layout is the same as disklabel's DD. I suspect
> that this approach is much less illegal than disklabel's MBRs
> although I do remember seeing a HP PC that disliked it. I wonder
> if a reasonable compromise is to make disklabel use this system for
> DD disks instead of the bogus 5 sector slice? Obviously, it
> should also somehow not install a partition table unless boot1 is
> being used as the MBR, and the fdisk -I method should be preferred.

Yes, that is much safer, however there are certain bioses that have
interesting quirks that the MBR has to work around.  The problem when
overlapping mbr and boot1 into the same block is that we no longer have the
space to do that.  boot1.s has got *3* bytes free.

For example, we dont have space to fix the case where the drive number is
passed through incorrectly to the mbr.  Some older Intel boards have this
problem (Phoenix derived bios).  See boot0's setdrv option.

Also (and I think this is more likely to be the problem you ran into) many
newer PC's are looking at the partition tables for a suspend-to-disk
partition or a FAT filesystem with a suspend-to-disk dump file.  For better
or worse, PC architecture dictates that boot disk partitions start and end
on cylinder boundaries (except for the first one which starts on the second
head in the first cylinder).  When we break those rules, we have to be
prepared for the consequences.

However, there is light at the end of the tunnel.  EFI GPT is pretty clean.
It supports up to something like 16384 partitions and it has all the useful
stuff we could possibly want including unique ID's, no CHS (pure 64 bit
LBA), volume tags (you can name partitions etc), and so on.  It is clean
enough that we could almost get away with doing away with disklabel as
well.  "Coming soon to a PC near you."
(http://developer.intel.com/technology/efi/index.htm)

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: Motion for removal of xargs(1) from base system

[Alfred Perlstein]

* Jackie 'business-first' Cook <[EMAIL PROTECTED]> [011210 16:19] wrote:
> 
> As a replacement for the 'functionality' present in xargs(1), I propose
> implementing arbitrary length argument list passing right in the operating
> system.

Nice proposal, where's the diff?

> Yours sincerly, Jackie 'business-first' Cook.
> 

-- 
-Alfred 'patches-first' Perlstein

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Brandon D. Valentine]

On Mon, 10 Dec 2001, Alfred Perlstein wrote:

>* Jackie 'business-first' Cook <[EMAIL PROTECTED]> [011210 16:19] wrote:
>>
>> As a replacement for the 'functionality' present in xargs(1), I propose
>> implementing arbitrary length argument list passing right in the operating
>> system.
>
>Nice proposal, where's the diff?

I'd like to preempt the ensuing bikeshed by voting for green.

>> Yours sincerly, Jackie 'business-first' Cook.

You don't by chance sell used cars, do you?

Brandon D. Valentine
-- 
"Iam mens praetrepidans avet vagari."
- G. Valerius Catullus, Carmina, XLVI


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Julian Elischer]

ummm, what are my scripts that use it going to use instead?
it seems to work fine, and it's pretty much an expected
base utility. Removing it is going to cause quite a bit of confusion.


On Mon, 10 Dec 2001, Jackie 'business-first' Cook wrote:

> There are days when people get tired with the lagacy code in the
> system - when things of the past just have to go. Recently I got sick
> and tired with one of those things. The command is, as you could have
> guessed from the subject, xags(1) aka /usr/bin/xargs. It is buggy and
> cluttered piece of code. Faulty and hard to use command. It's
> idiosyncratic syntax makes people dizzy everytime they use/or just try
> to use it.
> 
> Moreover short research I've conducted showed, that excessive use of
> xargs(1) can cause nausea, vomiting and migrene. The very presence of
> xargs(1) in the system, caused in some cases severe brain damage.
> Therefore I propose removal of xargs(1) from base system and moving it
> to ports tree. The new port in sysutils/xargs should be marked as
> BROKEN just after creation - that's obvious.
> 
> Short procedure for removing xargs(1) from your life:
> 
> Version #1 - for experienced sysadmins (local solution):
>   
>   rm -f /usr/bin/xargs(the -f is for those lucky ones who have ditched
>xargs(1) long ago, but just want to make sure
>it will vanish for good)
> 
> Version #2 - for enterprise (ie. business) users, who are searching for their
>way in life (overwhelming majority) (local solution, still):
> 
>   find / -print0 | grep -v xargs | xargs -0 rm -f {} \;
>   (the -v switch for grep adds some *verbosity*
> during operation)
> 
> Version #3 - for commiters only (global solution, all FreeBSD users are urged to
>cvs up/cvsup right after the commit, but one of presented local 
>solutions is still necessary to get rid of the venerous xargs(1)
>from your system):
> 
>   freefall% rm -rf $CVSROOT/src/usr.bin/xargs 
>   (to trash it altogether with version history,
>and make sure it will never come back)
> 
> As a replacement for the 'functionality' present in xargs(1), I propose
> implementing arbitrary length argument list passing right in the operating
> system.

that wouldn't do what I want to do with xargs.

It may not be wonderful but it's expected..
If you wna to get ugliness out of the system, how about starting with 
Perl :-)

> 
> Yours sincerly, Jackie 'business-first' Cook.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Emiel Kollof]

* Julian Elischer ([EMAIL PROTECTED]) wrote:
> ummm, what are my scripts that use it going to use instead?
> it seems to work fine, and it's pretty much an expected
> base utility. Removing it is going to cause quite a bit of confusion.

I have to concurr here. Who knows what's going to break when this is 
removed. It seems to have an established place on every UNIX workalike 
out there. I say keep it. If you don't like it, then don't use it. 

Cheers,
Emiel (who hopes for not another flamewar. One at a time is enough :)
-- 
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
-- Johnny Hart

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Gordon Tetlow]

If this isn't a troll, I don't know what is

On Mon, 10 Dec 2001, Jackie 'business-first' Cook wrote:

> There are days when people get tired with the lagacy code in the
> system - when things of the past just have to go. Recently I got sick
> and tired with one of those things. The command is, as you could have
> guessed from the subject, xags(1) aka /usr/bin/xargs. It is buggy and
> cluttered piece of code. Faulty and hard to use command. It's
> idiosyncratic syntax makes people dizzy everytime they use/or just try
> to use it.

Well, in that case, find(1) needs to be pitched as well for it's 
"idiosyncratic syntax" as well. Besides xargs is part of the POSIX 1003.2 
Standard. Since we are trying to be POSIX compliant, xargs should stay. If 
you think the code is ugly, please feel free to fix it. Patches are most 
welcome.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: Motion for removal of xargs(1) from base system

[John Baldwin]

On 10-Dec-01 Jackie 'business-first' Cook wrote:
> There are days when people get tired with the lagacy code in the system -
> when
> things of the past just have to go. Recently I got sick and tired with one of
> those things. The command is, as you could have guessed from the subject,
> xags(1) aka /usr/bin/xargs. It is buggy and cluttered piece of code. Faulty
> and
> hard to use command. It's idiosyncratic syntax makes people dizzy everytime
> they
> use/or just try to use it.

Buggy?  I haven't had problems with xargs(1).  I think a more useful use of
your time would be to actually describe the problems you have so they can be
addressed.  What Unix command doesn't have idiosyncratic syntax anyways?

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Wilko Bulte]

On Mon, Dec 10, 2001 at 11:55:36PM +0100, Emiel Kollof wrote:
> * Julian Elischer ([EMAIL PROTECTED]) wrote:
> > ummm, what are my scripts that use it going to use instead?
> > it seems to work fine, and it's pretty much an expected
> > base utility. Removing it is going to cause quite a bit of confusion.
> 
> I have to concurr here. Who knows what's going to break when this is 
> removed. It seems to have an established place on every UNIX workalike 
> out there. I say keep it. If you don't like it, then don't use it. 
> 
> Cheers,
> Emiel (who hopes for not another flamewar. One at a time is enough :)

Thanks to progress we can now have multi-threaded flamewars ;)

Wilko
[likes to keep xargs btw]

-- 
|   / o / /_  _ email:  [EMAIL PROTECTED]
|/|/ / / /(  (_)  Bulte Arnhem, The Netherlands 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Brian F. Feldman]

"Brandon D. Valentine" <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Dec 2001, Alfred Perlstein wrote:
> 
> >* Jackie 'business-first' Cook <[EMAIL PROTECTED]> [011210 16:19] wrote:
> >>
> >> As a replacement for the 'functionality' present in xargs(1), I propose
> >> implementing arbitrary length argument list passing right in the operating
> >> system.
> >
> >Nice proposal, where's the diff?
> 
> I'd like to preempt the ensuing bikeshed by voting for green.

I'd like to accept your nomination.  People, I know you won't regret 
choosing the right person for the job!

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Andrea Campi]

Either this is a troll, or it's an attempt at the very first layer 8 (between
chair and keyboard) exploit:

> Version #2 - for enterprise (ie. business) users, who are searching for their
>way in life (overwhelming majority) (local solution, still):
> 
>   find / -print0 | grep -v xargs | xargs -0 rm -f {} \;
>   (the -v switch for grep adds some *verbosity*
> during operation)

This doesn't quite do what he says; let's hope nobody tried to run it AND let
it run to its unpleasant end: passing the paths to all the files on your system
down the pipes on a single line, for rm to delete... Too bad the machine would
slow down to a crawl...

nice try anyway ;-)
Andrea


[luckily the rm wouldn't work for at least a reason which is left as an exercise
to the reader]

-- 
   Intel: where Quality is job number 0.9998782345!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Emiel Kollof]

* Jordan Hubbard ([EMAIL PROTECTED]) wrote:
> My, is it April 1st already?  How quickly time flies!  December feels
> like it was just yesterday!

You can say that again... I missed my birthday and the new-years party
too. I'm such a geek... 

:-)

Cheers,
Emiel
-- 
No man is an island, but some of us are long peninsulas.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Jordan Hubbard]

My, is it April 1st already?  How quickly time flies!  December feels
like it was just yesterday!

- Jordan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[John Baldwin]

On 10-Dec-01 Brian F. Feldman wrote:
> "Brandon D. Valentine" <[EMAIL PROTECTED]> wrote:
>> On Mon, 10 Dec 2001, Alfred Perlstein wrote:
>> 
>> >* Jackie 'business-first' Cook <[EMAIL PROTECTED]> [011210 16:19]
>> >wrote:
>> >>
>> >> As a replacement for the 'functionality' present in xargs(1), I propose
>> >> implementing arbitrary length argument list passing right in the
>> >> operating
>> >> system.
>> >
>> >Nice proposal, where's the diff?
>> 
>> I'd like to preempt the ensuing bikeshed by voting for green.
> 
> I'd like to accept your nomination.  People, I know you won't regret 
> choosing the right person for the job!

So I can cut you up into little places, grind those up in a blender, mix with
the appropriate substances and use the result to paint bikesheds?  Hmmm..

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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]

> 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.

All that will happen, is that the "usual" sources will be gone, and
a .PATH: will point to effectively the same code (with some crypto
in it, wrapped in #ifdefs that won't apply, like ENCRYPTION and
AUTHENTICATION). The code this actually compiled will not change
_at_all_.

There will be no SRA unless you install secure/ telnet.

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

Re: [SUGGESTION] - JFS for FreeBSD

[Greg Lehey]

[Format recovered--see http://www.lemis.com/email/email-format.html]

Long-short syndrome in first message.

On Monday, 10 December 2001 at 14:01:53 -0800, Hiten Pandya wrote:
> hi all,
>
> this is a wild idea...suggestion...
>
> i wanted to ask if there were any _plans_ to port
> JFS (Journaled File System) to FreeBSD...
>
> as for JFS, it is developed by IBM for Linux and is licensed under
> GPL, so we could put this into src/gnu/

Well, JFS was developed by IBM for AIX.  If you look at the header
files, it is clearly derived from UFS.  They later developed a
completely new file system, JFS2, for OS/2, and later ported this
version to Linux.  It's also available for AIX, but the standard AIX
file system is still the old JFS1.

> It is used on IBM MainFrames and Enterprise servers for high
> performance and maximum throughput...

I don't think the zSeries (System/390) runs JFS.  As I said above, the
RS/6000 uses a different JFS file system.

On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote:
>> * Hiten Pandya <[EMAIL PROTECTED]> [011210 16:02] wrote:
>>> hi all,
>>>
>>> this is a wild idea...suggestion...
>>>
>>> i wanted to ask if there were any _plans_ to port
>>> JFS (Journaled File System) to FreeBSD...
>>>
>>> as for JFS, it is developed by IBM for Linux and
>>> is licensed under GPL, so we could put this into
>>> src/gnu/
>>>
>>> It is used on IBM MainFrames and Enterprise servers
>>> for
>>> high performance and maximum throughput...
>>
>> I'm glad you took the time to read the marketting literature.
>>
>> The problem is that porting it is going to be a bit more complicated
>> than just dumping it into src/gnu.
>>
>> Feel free to take a shot at porting it though, let us know
>> when you're done.
>
> I'm gainfully employed by IBM (although not for FreeBSD pursuits),
> and have had this on my TODO list for a while.

Well, I'm gainfully employed by IBM, both for FreeBSD and JFS.  I've
thought (and spoken) about this from time to time.  It would be a lot
of work.

> The licence issue is a real sticky point, especially since the GPL
> and BSD licences are like oil and water.  Because of the GPL
> licence, JFS support can never become part of the GENERIC kernel,
> and any related support tools will have to exist as separate
> binaries (newfs.jfs, fsck.jfs), as is currently done with the EXT2FS
> filesystem.

As others have pointed out, this is a detail.  The real question is:
will JFS2 buy anything?  The only real way to find out is to try it. 

On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote:
> I'm no expert on journaled filesystems, but isn't the freebsd softupdates
> option similar?

No, at least not from a technical standpoint.  From a user standpoint,
they both try to make things faster and more reliable, but they do it
in very different ways.

>  perhaps there could be an upgrade to offer
>   options SOFTERUPDATES
> as an equal-but-different alternative to jfs?

And what would that do?

Greg
--
When replying to this message, please take care not to mutilate the
original text.  
For more information, see http://www.lemis.com/email.html
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: [SUGGESTION] - JFS for FreeBSD

[Greg Lehey]

On Tuesday, 11 December 2001 at 10:56:17 +1030, Greg Lehey wrote:
> On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote:
>>> * Hiten Pandya <[EMAIL PROTECTED]> [011210 16:02] wrote:
 hi all,

 this is a wild idea...suggestion...

 i wanted to ask if there were any _plans_ to port
 JFS (Journaled File System) to FreeBSD...

 as for JFS, it is developed by IBM for Linux and
 is licensed under GPL, so we could put this into
 src/gnu/

 It is used on IBM MainFrames and Enterprise servers
 for
 high performance and maximum throughput...
>>>
>>> I'm glad you took the time to read the marketting literature.
>>>
>>> The problem is that porting it is going to be a bit more complicated
>>> than just dumping it into src/gnu.
>>>
>>> Feel free to take a shot at porting it though, let us know
>>> when you're done.
>>
>> I'm gainfully employed by IBM (although not for FreeBSD pursuits),
>> and have had this on my TODO list for a while.
>
> Well, I'm gainfully employed by IBM, both for FreeBSD and JFS.  I've
> thought (and spoken) about this from time to time.  It would be a lot
> of work.

BTW, if anybody wants to do it anyway, let me know.  I'm in a position
to help with information, though possibly not with coding.

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: [SUGGESTION] - JFS for FreeBSD

[Brandon D. Valentine]

On Tue, 11 Dec 2001, Greg Lehey wrote:

>On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote:
>>  perhaps there could be an upgrade to offer
>>  options SOFTERUPDATES
>> as an equal-but-different alternative to jfs?
>
>And what would that do?

SOFTERUPDATES includes a switch to diffused gallery lighting and
enhanced mood music.  For the hacker in touch with his feminine side, it
offers the ultimate in warm fuzzies.

Brandon D. Valentine
-- 
"Iam mens praetrepidans avet vagari."
- G. Valerius Catullus, Carmina, XLVI


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

[Greg Lehey]

On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
>
>>> performance without it - for reading OR writing.  It doesn't matter
>>> so much for RAID{1,10},  but it matters a whole lot for something like
>>> RAID-5 where the difference between a spindle-synced read or write
>>> and a non-spindle-synched read or write can be upwards of 35%.
>>
>> If you have RAID5 with I/O sizes that result in full-stripe operations.
>
> Well, 'more then one disk' operations anyway, for random-I/O.  Caching
> takes care of sequential I/O reasonably well but random-I/O goes down
> the drain for writes if you aren't spindle synced, no matter what
> the stripe size,

Can you explain this?  I don't see it.  In FreeBSD, just about all I/O
goes to buffer cache.

> and will go down the drain for reads if you cross a stripe -
> something that is quite common I think.

I think this is what Mike was referring to when talking about parity
calculation.  In any case, going across a stripe boundary is not a
good idea, though of course it can't be avoided.  That's one of the
arguments for large stripes.

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 Dedicated" (was: cvs commit: src/sys/kern subr_diskmbr.c)

[Greg Lehey]

On Sunday,  9 December 2001 at 16:59:28 -0800, Peter Wemm wrote:
> Joerg Wunsch wrote:
>> Mike Smith <[EMAIL PROTECTED]> wrote:
>>> 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 would seem to be a reasonable alternative.  

> 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).

Well, the real question is the space wasted at the end, which can be
up to a megabyte.  Still not going to kill you, but it's aesthetically
displeasing.

> 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.

So where would you put the bootstrap?  In sector 2?

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: cvs commit: src/sys/kern subr_diskmbr.c

[Greg Lehey]

On Monday, 10 December 2001 at  9:11:03 +0100, Joerg Wunsch wrote:
>  Also, i think that:
>
> uriah /boot/kernel/kernel: da0: invalid primary partition table: Dangerously 
>Dedicated (ignored)
> uriah last message repeated 5 times
>
> ...73 of those silly messages are just beyond any form of usefulness.
> Either we hide this completely behind bootverbose (back to the root of
> this thread) since it bears no information at all (i already knew what
> is written there, since it was my deliberate decision, and it could
> not have happened unless being my deliberate decision), or we at least
> ensure any of those messages is emitted at most once per drive.

Hadn't we agreed to do this?  I'm certainly in favour of the
bootverbose approach.

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: [SUGGESTION] - JFS for FreeBSD

[Anthony Schneider]

> On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote:
> > I'm no expert on journaled filesystems, but isn't the freebsd softupdates
> > option similar?
> 
> No, at least not from a technical standpoint.  From a user standpoint,
> they both try to make things faster and more reliable, but they do it
> in very different ways.
> 

Well, perhaps I should have made that clearer:  I am not an expert on either
journaled filesystems not am I an expert on FreeBSD's softupdates option,
technically or other.

> >  perhaps there could be an upgrade to offer
> > options SOFTERUPDATES
> > as an equal-but-different alternative to jfs?
> 
> And what would that do?

My thoughts were that if the two were similar in effect that it might be
a relatively easy project to escalate towards achieving the same effects
in one as the other.  I understand that this is not necessarily the case.
 
> Greg

-Anthony.




msg32923/pgp0.pgp
Description: PGP signature

Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

[Bernd Walter]

On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
> >
> >>> performance without it - for reading OR writing.  It doesn't matter
> >>> so much for RAID{1,10},  but it matters a whole lot for something like
> >>> RAID-5 where the difference between a spindle-synced read or write
> >>> and a non-spindle-synched read or write can be upwards of 35%.
> >>
> >> If you have RAID5 with I/O sizes that result in full-stripe operations.
> >
> > Well, 'more then one disk' operations anyway, for random-I/O.  Caching
> > takes care of sequential I/O reasonably well but random-I/O goes down
> > the drain for writes if you aren't spindle synced, no matter what
> > the stripe size,
> 
> Can you explain this?  I don't see it.  In FreeBSD, just about all I/O
> goes to buffer cache.

After waiting for the drives and not for vinum parity blocks.

> > and will go down the drain for reads if you cross a stripe -
> > something that is quite common I think.
> 
> I think this is what Mike was referring to when talking about parity
> calculation.  In any case, going across a stripe boundary is not a
> good idea, though of course it can't be avoided.  That's one of the
> arguments for large stripes.

striped:
If you have 512byte stripes and have 2 disks.
You access 64k which is put into 2 32k transactions onto the disk.
The wait time for the complete transaction is the worst of both,
which is more than the average of a single disk.
With spindle syncronisation the access time for both disks are beleaved
to be identic and you get the same as with a single disk.
Linear speed could be about twice the speed of a single drive.
But this is more theoretic today than real.
The average transaction size per disk decreases with growing number
of spindles and you get more transaction overhead.
Also the voice coil technology used in drives since many years add a
random amount of time to the access time, which invalidates some of
the spindle sync potential.
Plus it may break some benefits of precaching mechanisms in drives.
I'm almost shure there is no real performance gain with modern drives.

raid5:
For a write you have two read transactions and two writes.
The two read are at the same position on two different spindless and
there the same access time situation exists as in the case above.
We don't have the problem with decreased transaction sizes.
But we have the same problem with seek time and modern disks as
in the case above plus we have the problem that the drives are not
exactly equaly loaded which randomizes the access times again.
I doubt that we have a performance gain with modern disks in the
general case, but there might be some special uses.

The last drives I saw which could do spindle sync was the IBM DCHS
series.


There are easier things to raise performance.
Ever wondered why people claim vinums raid5 writes are slow?
The answer is astonishing simple:
Vinum does striped based locking, while the ufs tries to lay out data
mostly ascending sectors.
What happens here is that the first write has to wait for two reads
and two writes.
If we have an ascending write it has to wait for the first write to
finish, because the stripe is still locked.
The first is unlocked after both physical writes are on disk.
Now we start our two reads which are (thanks to drives precache)
most likely in the drives cache - than we write.

The problem here is that physical writes gets serialized and the drive
has to wait a complete rotation between each.
If we had a fine grained locking which only locks the accessed sectors
in the parity we would be able to have more than a single ascending
write transaction onto a single drive.
At best the stripe size is bigger than the maximum number of parallel
ascending writes the OS does on the volume.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Alfred Perlstein]

* Brian F. Feldman <[EMAIL PROTECTED]> [011210 17:11] wrote:
> "Brandon D. Valentine" <[EMAIL PROTECTED]> wrote:
> > On Mon, 10 Dec 2001, Alfred Perlstein wrote:
> > 
> > >* Jackie 'business-first' Cook <[EMAIL PROTECTED]> [011210 16:19] wrote:
> > >>
> > >> As a replacement for the 'functionality' present in xargs(1), I propose
> > >> implementing arbitrary length argument list passing right in the operating
> > >> system.
> > >
> > >Nice proposal, where's the diff?
> > 
> > I'd like to preempt the ensuing bikeshed by voting for green.
> 
> I'd like to accept your nomination.  People, I know you won't regret 
> choosing the right person for the job!

I figured you'd be ok with removing xargs pfft.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
   http://www.morons.org/rants/gpl-harmful.php3

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

[Bernd Walter]

On Mon, Dec 10, 2001 at 10:49:28AM -0800, Matthew Dillon wrote:
> 
> :For RAID3 that is true. For the other ones...
> :
> :> performance without it - for reading OR writing.  It doesn't matter 
> :> so much for RAID{1,10},  but it matters a whole lot for something like
> :> RAID-5 where the difference between a spindle-synced read or write
> :> and a non-spindle-synched read or write can be upwards of 35%.
> :
> :If you have RAID5 with I/O sizes that result in full-stripe operations.
> :
> :-- 
> :|   / o / /_  _  email:  [EMAIL PROTECTED]
> :|/|/ / / /(  (_)  Bulte  Arnhem, The Netherlands 
> 
> Well, for reads a non-stripe-crossing op would still work reasonably
> well.  But for writes less then full-stripe operations without
> spindle sync are going to be terrible due to the read-before-write
> requirement (to calculate parity).  The disk cache is useless in that
> case.

Modern disks do prereads and writes are streamed by tagged command
queueing which invalidates this for linear access.
For non linear access the syncronisation is shadowed partly by different
seek times and different load on the spindles.
The chance that the data and parity spindle have the heads on the same
track is absolutely small for random access.
With 15000 upm drives the maximum rotational delay is 4ms and the
average is 2ms which gives you an maximum of only 1ms to gain under
ideal conditions - which we don't have as I stated above.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sbin/reboot boot_i386.8 src/sys/boot/i386/libi386 bootinfo.c src/sys/i386/i386 autoconf.c src/sys/kern tty_cons.c src/sys/sys cons.h reboot.h

[Nickolay Dudorov]

In article <[EMAIL PROTECTED]>
Guido van Rooij <[EMAIL PROTECTED]> wrote:
> guido   2001/12/10 12:02:22 PST
> 
>  Modified files:
>sbin/reboot  boot_i386.8 
>sys/boot/i386/libi386 bootinfo.c 
>sys/i386/i386autoconf.c 
>sys/kern tty_cons.c 
>sys/sys  cons.h reboot.h 
>  Log:
>  Add new boot flag to i386 boot: -p.
>  This flag adds a pausing utility. When ran with -p, during the kernel
>  probing phase, the kernel will pause after each line of output.
>  This pausing can be ended with the '.' key, and is automatically
>  suspended when entering ddb.
>  
>  This flag comes in handy at systems without a serial port that either hang
>  during booting or reser.
>  Reviewed by:(partly by jlemon)
>  MFC after:  1 week
>  
>  Revision  ChangesPath
>  1.32  +3 -1  src/sbin/reboot/boot_i386.8
>  1.31  +3 -0  src/sys/boot/i386/libi386/bootinfo.c
>  1.160 +1 -1  src/sys/i386/i386/autoconf.c
>  1.97  +24 -0 src/sys/kern/tty_cons.c
>  1.27  +1 -0  src/sys/sys/cons.h
>  1.20  +1 -0  src/sys/sys/reboot.h

CURRENT kernel is not buildable (in fact "linkable")
after this commit without DDB option.
 There is unguarded by "ifdef DDB" usage of 'db_active'
variable at line 552 of 'src/sys/kern/tty_cons.c'.

I know that using CURRENT without 'options DDB' is
not recomended, but there is "MFC after: 1 week" in this
commit, so this error must be corrected before this time.

N.Dudorov

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Motion for removal of xargs(1) from base system

[Terry Lambert]

Jackie 'business-first' Cook wrote:
[ ... plot to murder innocent xargs command ... ]

Please don't.  I use this on a daily basis.  It is a much faster
way to use find than "exec", since it doesn't require a billion
instances of "grep".


> As a replacement for the 'functionality' present in xargs(1), I propose
> implementing arbitrary length argument list passing right in the operating
> system.

I would like to see how you propose to do this without making
the kernel stack arbirarily large... and hacking up every shell,
perl, mush, etc..

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Hiten Pandya wrote:
> i wanted to ask if there were any _plans_ to port
> JFS (Journaled File System) to FreeBSD...

Not unless you have plans.  When I was an IBM employee, they would
not change the license, and so it's impossible to ship a CDROM
where it's the boot FS, or boxes on which it is the boot FS, and
still have it be legal, because of the license conflicts.

I fought this for about a year within IBM, before I gave up.


> It is used on IBM MainFrames and Enterprise servers
> for high performance and maximum throughput...

No, it's not.  The Linux JFS is derived from the OS/2 JFS code, not
the good AIX JFS code.

-- 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]

As Peter Wemm wrote:

> Yes, that is much safer, however there are certain bioses that have
> interesting quirks that the MBR has to work around.  The problem
> when overlapping mbr and boot1 into the same block is that we no
> longer have the space to do that.  boot1.s has got *3* bytes free.

Too bad.

Peter, do you care to update the section about DD mode (and its
dangers) in the FAQ after all this discussion?  I could probably do
it, too (the original entry is mine), but i had to quote your
arguments only anyway.

> Also (and I think this is more likely to be the problem you ran
> into) many newer PC's are looking at the partition tables for a
> suspend-to-disk partition or a FAT filesystem with a suspend-to-disk
> dump file.

Seems i really love my Toshiba (Libretto) that simply hibernates to
the last nnn MB of the physical disk. ;-)  (I have reserved a FreeBSD
partition as a placeholder for the hibernation data.)

> However, there is light at the end of the tunnel.  EFI GPT is pretty
> clean.

Good to hear.  While this sounds like dedicated disks will be gone
then :), at least the format looks rationale enough.

> It supports up to something like 16384 partitions ...

It would be interesting to see how Windoze will arrange for 16K
"drive" letters. :-))

The day vinum is up and ready to also cover the root FS, i won't need
/any/ partition at all anymore. ;-)

As Greg Lehey wrote:

> > ...73 of those silly messages are just beyond any form of usefulness.

> Hadn't we agreed to do this?  I'm certainly in favour of the
> bootverbose approach.

I can't remember any agreement so far.  But thinking a bit more about
it, it sounds like the best solution to me, too.  The only other
useful option would be to restrict the message to once per drive, but
that'll cost an additional per-drive flag, which is probably too much
effort just for that message.

-- 
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: [SUGGESTION] - JFS for FreeBSD

[Greg Lehey]

On Monday, 10 December 2001 at 22:45:22 -0800, Terry Lambert wrote:
> Hiten Pandya wrote:
>> i wanted to ask if there were any _plans_ to port
>> JFS (Journaled File System) to FreeBSD...
>
> Not unless you have plans.  When I was an IBM employee, they would
> not change the license, and so it's impossible to ship a CDROM
> where it's the boot FS, or boxes on which it is the boot FS, and
> still have it be legal, because of the license conflicts.
>
> I fought this for about a year within IBM, before I gave up.

Since then, it has become possible for the loader to load modules
before booting the kernel.  This means that, theoretically, it would
be possible to have a JFS root file system.  Given the strong
opposition to the GPL in some factions of the FreeBSD project, I don't
see this happening any time soon, especially since we still don't know
if it will buy us anything.

>> It is used on IBM MainFrames and Enterprise servers
>> for high performance and maximum throughput...
>
> No, it's not.  The Linux JFS is derived from the OS/2 JFS code, not
> the good AIX JFS code.

That's correct, but note that AIX is moving to this code base too, so
it's not as if it's second-rate.  From what I've seen of the
structures, JFS2 is *much* better than JFS1.  I haven't compared
performance.

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)

[Mike Smith]

> > > :> > 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..

With ZBR, anything is possible.

> Wouldn't the linear speed be faster closer to the spindle at 7200 RPM 
> than at the edge?

The stunning ignorance being displayed in this thread appears to have 
reached an all-time low.

*sigh*

-- 
... 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 dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

[Matthew Dillon]

:> Wouldn't the linear speed be faster closer to the spindle at 7200 RPM 
:> than at the edge?
:
:The stunning ignorance being displayed in this thread appears to have 
:reached an all-time low.
:
:*sigh*

Ah, another poor soul who didn't read the first sentence of
tuning(7).

-Matt


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)

[Terry Lambert]

"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?

Linear speed is closes at the edge, but magnetic domain density
is higher at the spindle, for a uniform rotation rate.

I think that the electronics ended up being designed for the
average rate.

PS: The encoding frequency is higher at the spindle, as well.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: NCP Broken ?

[Kaltashkin Eugene]

On Fri, 7 Dec 2001 10:55:03 -0800 (PST)
Julian Elischer <[EMAIL PROTECTED]> wrote:

JE: yes ncp and nwfs are broken in -current

Hm, and when this be work ?


--
Best Regards
Kaltashkin Eugene
ZHECKA-RIPN



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message