Re: Getting CPU usage in FreeBSD

[Arun Sharma]

> On Linux this is what I do to get this value:  Measure the number of
> scheduled jiffies (hundreths of second), measure elapsed time since last
> measurement, divide.

I ran into the same problem as you - and took the time to implement it.
My patches fix the SMP case as well as getting it via sysctl instead of
kvm_read.

See:

http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=169412+180922+/usr/local/www/db/text/1999/freebsd-hackers/19991212.freebsd-hackers

http://www.freebsd.org/cgi/getmsg.cgi?fetch=293002+0+/usr/local/www/db/text/1999/freebsd-hackers/19991226.freebsd-hackers

-Arun


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

Re: Is FreeBSD dead? Well, not in theory...

[Wes Peters]

Chuck Robey wrote:
> 
> On Sun, 12 Mar 2000, Nate Williams wrote:
> 
> > > >That's also why I am wasting my time slowly documenting the FreeBSD
> > > >internals in my spare time.
> > >
> > > "slowly" is the key word here. Real products are documented before they are
> > > in commercial use.
> >
> > Really?  That's very different from my experience as a commercial
> > software developer.
> >
> > And, it's not the experience I had from using your products as well.
> > Documentation was as sparse as the FreeBSD documentation, but this is
> > typical of most projects, except for government projects which requires
> > truckloads of documentation.
> >
> > That's the main reason that government projects are rarely on time and
> > budget, and never end up with the features that are desired.  They spend
> > all their time documenting, and no time implementing. :)
> 
> You ever see those docs they write?  Generally, it's an odd case of
> nothing actually being better than something.

Hey!  Some of my past work resembles that remark!

> I did once see a company that did the docs first, and then used those docs
> as the design template.  Any changes in the design had to be modified in
> the docs first, and the docs were under a version control system.
> 
> That was the one and only time I ever saw that.  Dennis is living on
> another planet than we do.  And don't call the stuff that comes with
> consumer products docs, because they are usually written by marketing, and
> usually largely a work of fiction.

I actually work for a company that writes both software and hardware
design specs before plunging off into development work.  Of course, the
specs are never updated after the fact, so they're completely worthless
for any follow-on work.  In effect, the C, asm, and VHDL becomes the
as-built documentation, which is quite horrid.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


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

Re: 5.0 features?

[Wes Peters]

Mark Hittinger wrote:
> 
> Something that the old DEC took a few stabs at was the idea of a
> "checkpoint" feature where a process or a series of processes could be
> put in a quiesced state.  This would page out the process or processes
> into the swap space, allow a hardware shutdown, and after a reboot allow
> the restart of the checkpointed process(es).

Actually checkpoint/restart worked pretty well under both VMS and ELN.
The core file code gives us a reasonable starting point for doing the
same; the Emacs "loadup/dump" initialization essentially does a check-
point of Emacs following elisp initialization.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


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

Re: Is FreeBSD documented? Well, not in theory...

[Wes Peters]

Jeroen Ruigrok/Asmodai wrote:
> 
> -On [20000312 00:00], Joe Abley ([EMAIL PROTECTED]) wrote:
> >On Sat, Mar 11, 2000 at 01:36:31PM -0500, Dennis wrote:
> 
> >> Another point is that Open Source is virtually synonomous with "Totally
> >> undocumented".
> >
> >This is sillier.
> 
> Exactly, and it also slightly pisses me off...
> 
> Then I guess I wrote all the manpages and documents for nothing.
> 
> elf.5 comes to mind for a very handy resource.
> 
> http://home.wxs.nl/~asmodai/newbus-draft.txt comes to mind.  And when
> that is finished the manpages will follow.
> 
> That's also why I am wasting my time slowly documenting the FreeBSD
> internals in my spare time.

And I want you to know that NONE of us appreciate this or ever use
your non-existant documentation.  I give you exactly 27 years to
stop wasting your time like this.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


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

Re: 5.0 features?

[Patryk Zadarnowski]

> Mark Hittinger writes:
> >
> >Something that the old DEC took a few stabs at was the idea of a
> >"checkpoint" feature where a process or a series of processes could be
> >put in a quiesced state.  This would page out the process or processes
> >into the swap space, allow a hardware shutdown, and after a reboot allow
> >the restart of the checkpointed process(es).
> >
> 
> I did something like this for Philips while I was at UniSoft. It
> depended on some special hardware features (turning off/losing power
> generated an interrupt, there was a small UPS in the box along with
> battery-backed SRAM to save various kernel structures).
> 
> Turning off the power caused all memory to be saved to disk (the kernel
> turned off the UPS after it was done). Upon a restart the kernel noticed
> that memory had been saved, read the contents in from disk, futzed around
> with some structures, and restarted what was curproc at the time of
> shutdown. It even worked ;-)
> 
> Philips never did anything with it.

Out of pure curiosity, what did you do with pending interrupts, partially
completed DMA transfers and other such state information?

Pat.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk Zadarnowski <[EMAIL PROTECTED]>   University of New South Wales
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


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

Re: Buffer Problems and hangs in 4.0-CURRENT..

[Alfred Perlstein]

* Howard Leadmon <[EMAIL PROTECTED]> [000312 15:56] wrote:
> 
> > > Copyright (c) 1992-2000 The FreeBSD Project.
> > ...
> > > real memory  = 402587648 (393152K bytes)
> > > config> q
> > > avail memory = 387334144 (378256K bytes)
> > > Programming 24 pins in IOAPIC #0
> > > IOAPIC #0 intpin 2 -> irq 0
> > > FreeBSD/SMP: Multiprocessor motherboard
> > >  cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
> > >  cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
> > >  io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
> > > 
> > > Did I miss anything important you need??
> > 
> > No that's fine, I run several machines with maxusers at 512 and
> > NMBCLUSTERS at 32768 (although the ram is usually at 512 to a 1024),
> > let me know if you have any problems with those settings though as
> > I'd like to know if they are set too high for heavy load.
> > 
> > I would also suggest using fxp cards (Intel Ether Express Pro) in
> > the future, they are definetly my favorite.
> > 
> > --
> > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> 
> 
> I'll let you know how things pan out, but I just did a cvsup to the 
> current code as of today, and also changed the MAXUSERS to 256, and
> the NMBCLUSTERS to 20480 in the current kernel.
> 
> I did do a netstat -m on the box and see:
> 
> u2.abs.net$ netstat -m   
> 3798/4800/81920 mbufs in use (current/peak/max):
> 2179 mbufs allocated to data
> 1619 mbufs allocated to packet headers
> 784/1152/20480 mbuf clusters in use (current/peak/max)
> 2904 Kbytes allocated to network (70% in use)
> 0 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines
> 
> 
> Though the box is not even close to full load, that I will see later on 
> tonight when everyone gets on to chat.  I don't remember it ever having
> 81k mbufs available, so guess changing MAXUSERS set that one up.  Anyhow
> I'll try and keep an eye on it, the real problem is that it just dies and
> needs a reboot at times, so I don't get to see if I had any failures.. :(
> 
> As for the EEpro, I thought Intel had dropped that card, but maybe I am
> wrong.  I used the DEC based cards as I had seen so many people raving
> about them, and at least under Solaris they claim the DEC tulip based 
> boards are the hot ticket.  Do you think the Intel board would really work
> that much better under FBSD, as I can always try and find one to try out..

Use what works for you.  Please make sure to follow up even if everything
works out smoothly, it's great to hear about success stories. :)

thanks,
-Alfred


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

Re: 5.0 features?

[Gary Jennejohn]

Mark Hittinger writes:
>
>Something that the old DEC took a few stabs at was the idea of a
>"checkpoint" feature where a process or a series of processes could be
>put in a quiesced state.  This would page out the process or processes
>into the swap space, allow a hardware shutdown, and after a reboot allow
>the restart of the checkpointed process(es).
>

I did something like this for Philips while I was at UniSoft. It
depended on some special hardware features (turning off/losing power
generated an interrupt, there was a small UPS in the box along with
battery-backed SRAM to save various kernel structures).

Turning off the power caused all memory to be saved to disk (the kernel
turned off the UPS after it was done). Upon a restart the kernel noticed
that memory had been saved, read the contents in from disk, futzed around
with some structures, and restarted what was curproc at the time of
shutdown. It even worked ;-)

Philips never did anything with it.

---
Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]




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

Re: Buffer Problems and hangs in 4.0-CURRENT..

[Howard Leadmon]

> > Copyright (c) 1992-2000 The FreeBSD Project.
> ...
> > real memory  = 402587648 (393152K bytes)
> > config> q
> > avail memory = 387334144 (378256K bytes)
> > Programming 24 pins in IOAPIC #0
> > IOAPIC #0 intpin 2 -> irq 0
> > FreeBSD/SMP: Multiprocessor motherboard
> >  cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
> >  cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
> >  io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
> > 
> > Did I miss anything important you need??
> 
> No that's fine, I run several machines with maxusers at 512 and
> NMBCLUSTERS at 32768 (although the ram is usually at 512 to a 1024),
> let me know if you have any problems with those settings though as
> I'd like to know if they are set too high for heavy load.
> 
> I would also suggest using fxp cards (Intel Ether Express Pro) in
> the future, they are definetly my favorite.
> 
> --
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


I'll let you know how things pan out, but I just did a cvsup to the 
current code as of today, and also changed the MAXUSERS to 256, and
the NMBCLUSTERS to 20480 in the current kernel.

I did do a netstat -m on the box and see:

u2.abs.net$ netstat -m   
3798/4800/81920 mbufs in use (current/peak/max):
2179 mbufs allocated to data
1619 mbufs allocated to packet headers
784/1152/20480 mbuf clusters in use (current/peak/max)
2904 Kbytes allocated to network (70% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


Though the box is not even close to full load, that I will see later on 
tonight when everyone gets on to chat.  I don't remember it ever having
81k mbufs available, so guess changing MAXUSERS set that one up.  Anyhow
I'll try and keep an eye on it, the real problem is that it just dies and
needs a reboot at times, so I don't get to see if I had any failures.. :(

As for the EEpro, I thought Intel had dropped that card, but maybe I am
wrong.  I used the DEC based cards as I had seen so many people raving
about them, and at least under Solaris they claim the DEC tulip based 
boards are the hot ticket.  Do you think the Intel board would really work
that much better under FBSD, as I can always try and find one to try out..



---
Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net
ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162



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

Re: 5.0 features?

[Jonathan Lemon]

In article [EMAIL PROTECTED]> you 
write:
>
>Something that the old DEC took a few stabs at was the idea of a
>"checkpoint" feature where a process or a series of processes could be
>put in a quiesced state.  This would page out the process or processes
>into the swap space, allow a hardware shutdown, and after a reboot allow
>the restart of the checkpointed process(es).

You might want to look at Condor ,
which does something similar; processes are allowed to be checkpointed
and "migrated" to another machine.  Sounds similar to what you
describe above.  It's fairly useful for high-throughput computing
(making use of all/any idle CPU cycles).
--
Jonathan


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

Re: Getting CPU usage in FreeBSD

[Andrzej Bialecki]

On Sun, 12 Mar 2000, Jordan K. Hubbard wrote:

> > I'm definitely for it... If I can get permission from Jordan, perhaps the
> > attached patches can make it into upcoming release.
> 
> I think it's a fine idea, I'm just not sure one day before release
> is the time to be talking about it.  It should have been raised
> before now. :(

I understand your concern. I don't think the sky will fall on our heads if
these patches will be integrated after the release. :-) They are more like
a convenience, not a must.

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: Is FreeBSD dead? Well, not in theory...

[Chuck Robey]

On Sun, 12 Mar 2000, Nate Williams wrote:

> > >That's also why I am wasting my time slowly documenting the FreeBSD
> > >internals in my spare time.
> > 
> > "slowly" is the key word here. Real products are documented before they are
> > in commercial use.
> 
> Really?  That's very different from my experience as a commercial
> software developer.
> 
> And, it's not the experience I had from using your products as well.
> Documentation was as sparse as the FreeBSD documentation, but this is
> typical of most projects, except for government projects which requires
> truckloads of documentation.
> 
> That's the main reason that government projects are rarely on time and
> budget, and never end up with the features that are desired.  They spend
> all their time documenting, and no time implementing. :)

You ever see those docs they write?  Generally, it's an odd case of
nothing actually being better than something.

I did once see a company that did the docs first, and then used those docs
as the design template.  Any changes in the design had to be modified in
the docs first, and the docs were under a version control system.

That was the one and only time I ever saw that.  Dennis is living on
another planet than we do.  And don't call the stuff that comes with
consumer products docs, because they are usually written by marketing, and
usually largely a work of fiction.


Chuck Robey| Interests include C & Java programming, FreeBSD,
[EMAIL PROTECTED]  | electronics, communications, and signal processing.

New Year's Resolution:  I will not sphroxify gullible people into looking up
fictitious words in the dictionary.




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

Re: Buffer Problems and hangs in 4.0-CURRENT..

[Alfred Perlstein]

* Howard Leadmon <[EMAIL PROTECTED]> [000312 13:50] wrote:
> 
> > >  Not a whole lot done, I had the MAXUSERS set to 128, though am about to
> > > bump it to 256 when I rebuild to see if that helps.  I used to have some
> > > tunables for BSDI when I used it, but when I tried to apply them to FBSD
> > > it bitched about them being unknown so I just left them out.  Was also 
> > > going to move NMBCLUSTERS up to 20480, not sure if thats the solution or
> > > not.  I can post the whole config if desired, but really it's very close
> > > to the GENERIC except I added SOFTUPDATES, and removed all the drivers I
> > > didn't need for my system to hopefully slim it down some..
> > 
> > g, you _still_ haven't even told me how much RAM is in the box
> > and what else it does if anything.
> > 
> > Without that kind of information I'm not too comfortable giving
> > advice on tuneables because I DON'T KNOW WHAT I'M TUNING :), when
> > I've just blindly told people to increase NMBCLUSTERS they've had
> > other problems because the kernel's network buffers wired down all
> > the machine's memory.
> > 
> > Yes, increasing NMBLCUSTERS is a good thing, but without your
> > configuration it's hard to say how much to increase it.
> > 
> > -- 
> > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> 
> 
> Sorry, thought you were asking about the kernel configs, not the 
> hardware configs.  Here is my current running config via dmesg, as
> I think that covers it all..
> 
> 
> Copyright (c) 1992-2000 The FreeBSD Project.
...
> real memory  = 402587648 (393152K bytes)
> config> q
> avail memory = 387334144 (378256K bytes)
> Programming 24 pins in IOAPIC #0
> IOAPIC #0 intpin 2 -> irq 0
> FreeBSD/SMP: Multiprocessor motherboard
>  cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
>  cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
>  io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
> 
> Did I miss anything important you need??

No that's fine, I run several machines with maxusers at 512 and
NMBCLUSTERS at 32768 (although the ram is usually at 512 to a 1024),
let me know if you have any problems with those settings though as
I'd like to know if they are set too high for heavy load.

I would also suggest using fxp cards (Intel Ether Express Pro) in
the future, they are definetly my favorite.

--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


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

Re: Is FreeBSD dead? Well, not in theory...

[Nate Williams]

> >That's also why I am wasting my time slowly documenting the FreeBSD
> >internals in my spare time.
> 
> "slowly" is the key word here. Real products are documented before they are
> in commercial use.

Really?  That's very different from my experience as a commercial
software developer.

And, it's not the experience I had from using your products as well.
Documentation was as sparse as the FreeBSD documentation, but this is
typical of most projects, except for government projects which requires
truckloads of documentation.

That's the main reason that government projects are rarely on time and
budget, and never end up with the features that are desired.  They spend
all their time documenting, and no time implementing. :)


Nate


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

Re: Buffer Problems and hangs in 4.0-CURRENT..

[Howard Leadmon]

> >  Not a whole lot done, I had the MAXUSERS set to 128, though am about to
> > bump it to 256 when I rebuild to see if that helps.  I used to have some
> > tunables for BSDI when I used it, but when I tried to apply them to FBSD
> > it bitched about them being unknown so I just left them out.  Was also 
> > going to move NMBCLUSTERS up to 20480, not sure if thats the solution or
> > not.  I can post the whole config if desired, but really it's very close
> > to the GENERIC except I added SOFTUPDATES, and removed all the drivers I
> > didn't need for my system to hopefully slim it down some..
> 
> g, you _still_ haven't even told me how much RAM is in the box
> and what else it does if anything.
> 
> Without that kind of information I'm not too comfortable giving
> advice on tuneables because I DON'T KNOW WHAT I'M TUNING :), when
> I've just blindly told people to increase NMBCLUSTERS they've had
> other problems because the kernel's network buffers wired down all
> the machine's memory.
> 
> Yes, increasing NMBLCUSTERS is a good thing, but without your
> configuration it's hard to say how much to increase it.
> 
> -- 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


Sorry, thought you were asking about the kernel configs, not the 
hardware configs.  Here is my current running config via dmesg, as
I think that covers it all..


Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #3: Tue Mar  7 04:20:22 EST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/U2
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (551.25-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x665  Stepping = 5
  
Features=0x183fbff
real memory  = 402587648 (393152K bytes)
config> q
avail memory = 387334144 (378256K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc02cc000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02cc09c.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
pci0:  at 7.2 irq 5
Timecounter "PIIX"  frequency 3579545 Hz
chip1:  port 0x5000-0x500f at device 7.3 on 
pci0
dc0:  port 0xd400-0xd47f mem 0xd541-0xd54103ff irq 17 at 
device 13.0 on pci0
dc0: Ethernet address: 00:c0:f0:3b:a7:eb
miibus0:  on dc0
ukphy0:  on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci0:  at 15.0 irq 16
atapci1:  port 
0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 18 at device 19.0 on pci0
atapci2:  port 
0xec00-0xecff,0xe800-0xe803,0xe400-0xe407 irq 18 at device 19.1 on pci0
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0:  at port 0x60-0x6f on isa0
atkbd0:  irq 1 on atkbdc0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppi0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
plip0:  on ppbus0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
SMP: AP CPU #1 Launched!
ad0: 8693MB  [17662/16/63] at ata0-master using UDMA33
Mounting root from ufs:/dev/ad0s1a
WARNING: / was not properly dismounted
dc0: TX underrun -- increasing TX threshold


Did I miss anything important you need??


---
Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net
ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162



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

Re: Detecting ECC errors

[Doug Barton]

CC'ing -hackers in case we can scare up some interest . . .

Mike Smith wrote:
> 
> >   Hi.  I took a look over the archives and noticed this ancient
> > thread.  (1998)  However, I checked the handbook and LINT for options on
> > how FreeBSD logs ECC errors, but I could not find anything.  Has this
> > finally been implemented?  Or is there currently no way for the OS to
> > detect the # of corrections / detections of errors by DIMM slot?
> 
> You're correct; there isn't.  It's a relatively simple task that's been
> waiting for a junior hacker to come along and take it up.  It's also
> devillishly difficult to _test_ such code...

This would be a very valuable thing to have though (just to restate the
obvious). We had a sun machine go down at work with no symptoms at
all... other than the log which showed that ECC errors were being caught
and corrected (mostly) at a furious pace. If not for that log we would
have spent hours testing possible reasons for the crash.

Doug
-- 
"Welcome to the desert of the real." 

- Laurence Fishburne as Morpheus, "The Matrix"


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

Re: Is FreeBSD dead? Well, not in theory...

[Andrew Reilly]

On Mon, Mar 13, 2000 at 04:14:34AM -0500, Dennis wrote:
> At 09:19 AM 3/13/00 +1300, Joe Abley wrote:
> >I have yet to find a "real product" with good documentation.
> 
> I hate when these discussions get so out of context. The original point
> regarded source code, and whether it was useful enough to allow end-users
> to maintain their own systems simply by having it, since many of the
> caveats and "code tricks" are known only to the authors, or because of the
> substantial learning curve of fully understanding a hardware device.

Well, I've been able to get several problems "fixed" as a result
of having the source code.  I might not be able to fix the problem
myself, but I can usually (a) work around it and (b) submit a
detailed-enough PR or message to the author, including a pointer
to the problem piece of code and what I think's wrong with it, that
a fix has been installed in very short order.

How much better would I have fared with Solaris, SCO or NT?

What does it matter if there are users that can't derive even this
level of utility from the source, when there _arent_ any better
alternatives.

Again, your complaint has no positive arguments for ways to
improve the situation, or alternative scenarios that would be
better.  It is just an unhelpful whinge.

-- 
Andrew


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

re: 5.0 features?

[Mark Hittinger]

Something that the old DEC took a few stabs at was the idea of a
"checkpoint" feature where a process or a series of processes could be
put in a quiesced state.  This would page out the process or processes
into the swap space, allow a hardware shutdown, and after a reboot allow
the restart of the checkpointed process(es).

(Not as fun as SMP but fairly slick)

Later

Mark Hittinger
Earthlink!Mindspring!Netcom!Dallas
[EMAIL PROTECTED]


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

Re: Is FreeBSD dead? Well, not in theory...

[Andrew Reilly]

On Sat, Mar 11, 2000 at 01:36:31PM -0500, Dennis wrote:
[open source is irrelevant because none but but the authors can
 really fix things]
[open source _means_ that it's never finished]
[the existing commercial support sucks]

Seems like a pretty pointless and content-free set of remarks to
be making on the mailing lists of a successful open-source project.
Particularly from someone who obviously _does_ use and support open
source projects.

Go on, what's your real point?

-- 
Andrew


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

Re: Buffer Problems and hangs in 4.0-CURRENT..

[Alfred Perlstein]

* Howard Leadmon <[EMAIL PROTECTED]> [000312 13:20] wrote:
> 
> > >   Hello,
> > >  
> > >  I am getting the following errors out of FreeBSD 4.0-CURRENT trying to
> > > run an IRC server, and was wondering if anyone had any ideas or recommended
> > > tunables I should set??
> > >  
> > >  
> > > Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
>[@163.152.216.46]:No buffer space available
> > > Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
>[@208.164.193.201]:No buffer space available
> > > Mar  9 22:33:00 u syslogd: sendto: No buffer space available
> > 
> > I'm assuming you haven't tuned a single thing, therefor you'll want
> > to double "maxusers" in your kernel config file.
> > 
> > It would help if you told us the configuration of the machine so that
> > I felt comfortable giving more specific tunables without worrying
> > about them causing other problems because of lack of RAM.
> > 
> > -Alfred
> 
> 
>  Howdy,
> 
>  Not a whole lot done, I had the MAXUSERS set to 128, though am about to
> bump it to 256 when I rebuild to see if that helps.  I used to have some
> tunables for BSDI when I used it, but when I tried to apply them to FBSD
> it bitched about them being unknown so I just left them out.  Was also 
> going to move NMBCLUSTERS up to 20480, not sure if thats the solution or
> not.  I can post the whole config if desired, but really it's very close
> to the GENERIC except I added SOFTUPDATES, and removed all the drivers I
> didn't need for my system to hopefully slim it down some..

g, you _still_ haven't even told me how much RAM is in the box
and what else it does if anything.

Without that kind of information I'm not too comfortable giving
advice on tuneables because I DON'T KNOW WHAT I'M TUNING :), when
I've just blindly told people to increase NMBCLUSTERS they've had
other problems because the kernel's network buffers wired down all
the machine's memory.

Yes, increasing NMBLCUSTERS is a good thing, but without your
configuration it's hard to say how much to increase it.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


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

Re: Buffer Problems and hangs in 4.0-CURRENT..

[Howard Leadmon]

> >   Hello,
> >  
> >  I am getting the following errors out of FreeBSD 4.0-CURRENT trying to
> > run an IRC server, and was wondering if anyone had any ideas or recommended
> > tunables I should set??
> >  
> >  
> > Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
>[@163.152.216.46]:No buffer space available
> > Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
>[@208.164.193.201]:No buffer space available
> > Mar  9 22:33:00 u syslogd: sendto: No buffer space available
> 
> I'm assuming you haven't tuned a single thing, therefor you'll want
> to double "maxusers" in your kernel config file.
> 
> It would help if you told us the configuration of the machine so that
> I felt comfortable giving more specific tunables without worrying
> about them causing other problems because of lack of RAM.
> 
> -Alfred


 Howdy,

 Not a whole lot done, I had the MAXUSERS set to 128, though am about to
bump it to 256 when I rebuild to see if that helps.  I used to have some
tunables for BSDI when I used it, but when I tried to apply them to FBSD
it bitched about them being unknown so I just left them out.  Was also 
going to move NMBCLUSTERS up to 20480, not sure if thats the solution or
not.  I can post the whole config if desired, but really it's very close
to the GENERIC except I added SOFTUPDATES, and removed all the drivers I
didn't need for my system to hopefully slim it down some..


---
Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net
ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162



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

Re: Is FreeBSD dead? Well, not in theory...

[Dennis]

At 09:19 AM 3/13/00 +1300, Joe Abley wrote:
>On Mon, Mar 13, 2000 at 03:44:04AM -0500, Dennis wrote:
>> At 07:32 PM 3/12/00 +0100, Jeroen Ruigrok/Asmodai wrote:
>> >That's also why I am wasting my time slowly documenting the FreeBSD
>> >internals in my spare time.
>> 
>> "slowly" is the key word here. Real products are documented before they are
>> in commercial use. Plus by the time you're done they will be
>> outdated...another common problem.
>
>I have yet to find a "real product" with good documentation.

I hate when these discussions get so out of context. The original point
regarded source code, and whether it was useful enough to allow end-users
to maintain their own systems simply by having it, since many of the
caveats and "code tricks" are known only to the authors, or because of the
substantial learning curve of fully understanding a hardware device.

The discussion about general docs for the OS is a completely different matter.

DB


-


http://www.etinc.com
T1/T3 boards for FreeBSD and Linux
Multiport T1/T3 Routers
Full-Featured Bandwidth Manager




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

5.0 features?

[Ted Sikora]

Excerpt from Slashdot interview:
David Greenman and Mike Karels will be working together as
co-architects for the new system. As features are merged in, they will
be available for download at www.freebsd.org, and on "snapshot" CDROMs.
The completely merged system will be released as FreeBSD 5.0.

What kind of features and additions can we expect from the merged
systems in 5.0? It looks as though this has been in 
the works for sometime. I think I read somewhere that SMP support would
be much improved?

Regards,
--
Ted Sikora
Jtl Development Group 
[EMAIL PROTECTED]
http://powerusersbbs.com


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

Re: Buffer Problems and hangs in 4.0-CURRENT..

[Alfred Perlstein]

* Howard Leadmon <[EMAIL PROTECTED]> [000312 12:51] wrote:
> 
>   Hello,
>  
>  I am getting the following errors out of FreeBSD 4.0-CURRENT trying to
> run an IRC server, and was wondering if anyone had any ideas or recommended
> tunables I should set??
>  
>  
> Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
>[@163.152.216.46]:No buffer space available
> Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
>[@208.164.193.201]:No buffer space available
> Mar  9 22:33:00 u syslogd: sendto: No buffer space available

I'm assuming you haven't tuned a single thing, therefor you'll want
to double "maxusers" in your kernel config file.

It would help if you told us the configuration of the machine so that
I felt comfortable giving more specific tunables without worrying
about them causing other problems because of lack of RAM.

-Alfred


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

Re: Is FreeBSD dead? Well, not in theory...

[Joe Abley]

On Mon, Mar 13, 2000 at 03:44:04AM -0500, Dennis wrote:
> At 07:32 PM 3/12/00 +0100, Jeroen Ruigrok/Asmodai wrote:
> >That's also why I am wasting my time slowly documenting the FreeBSD
> >internals in my spare time.
> 
> "slowly" is the key word here. Real products are documented before they are
> in commercial use. Plus by the time you're done they will be
> outdated...another common problem.

I have yet to find a "real product" with good documentation.

> Why are you arguing this point? Is there anyone that believes that Linux
> and FreeBSD are well documented?

Yes.

> Please. The books are out of date before they hit the stores.

Books?



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

Buffer Problems and hangs in 4.0-CURRENT..

[Howard Leadmon]

  Hello,
 
 I am getting the following errors out of FreeBSD 4.0-CURRENT trying to
run an IRC server, and was wondering if anyone had any ideas or recommended
tunables I should set??
 
 
Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
[@163.152.216.46]:No buffer space available
Mar  9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for 
[@208.164.193.201]:No buffer space available
Mar  9 22:33:00 u syslogd: sendto: No buffer space available
 
 
 
 I have actually been fighting a problem with this machine locking up, and 
requiring a hard reset, and this is the only type errors I am actually seeing
in the messages file.  Not sure if this can cause such problems, so kind
of grasping at straws to try and correct it.
 
 FYI, the IRC machine supports 4000+ clients connected at the same time, so
if anyone has recommended tunables for this type of setup with so many 
active connections I would love to hear about it..
 
 
---
Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net
ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162



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

Re: Is FreeBSD dead? Well, not in theory...

[Dennis]

At 07:32 PM 3/12/00 +0100, Jeroen Ruigrok/Asmodai wrote:
>-On [2312 00:00], Joe Abley ([EMAIL PROTECTED]) wrote:
>>On Sat, Mar 11, 2000 at 01:36:31PM -0500, Dennis wrote:
>
>>> Another point is that Open Source is virtually synonomous with "Totally
>>> undocumented".
>>
>>This is sillier.
>
>Exactly, and it also slightly pisses me off...
>
>Then I guess I wrote all the manpages and documents for nothing.
>
>elf.5 comes to mind for a very handy resource.
>
>http://home.wxs.nl/~asmodai/newbus-draft.txt comes to mind.  And when
>that is finished the manpages will follow.
>
>That's also why I am wasting my time slowly documenting the FreeBSD
>internals in my spare time.

"slowly" is the key word here. Real products are documented before they are
in commercial use. Plus by the time you're done they will be
outdated...another common problem.

Why are you arguing this point? Is there anyone that believes that Linux
and FreeBSD are well documented? Please. The books are out of date before
they hit the stores.

DB
.



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

Re: Getting CPU usage in FreeBSD

[Jordan K. Hubbard]

> I'm definitely for it... If I can get permission from Jordan, perhaps the
> attached patches can make it into upcoming release.

I think it's a fine idea, I'm just not sure one day before release
is the time to be talking about it.  It should have been raised
before now. :(

- Jordan


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

Re: Getting CPU usage in FreeBSD

[Andrzej Bialecki]

On Sun, 12 Mar 2000, Oliver Fromme wrote:

> Kris Kennaway <[EMAIL PROTECTED]> wrote in list.freebsd-hackers:
>  > On Sun, 12 Mar 2000, Oliver Fromme wrote:
>  > > Then look up the definition of kread() in the same file, and
>  > > how the contents of cur.cp_time are used in the cpustats()
>  > > function.  Note that "cur" is a "struct statinfo", which is
>  > > defined in /usr/include/devstat.h.  The CPU states are defined
>  > > in /usr/include/sys/dkstat.h.
>  > 
>  > We probably should make this into a sysctl to divorce the binaries from
>  > having to read kvm.
> 
> Sounds like a good idea.  But then again, vmstat.c uses kvm
> for about a dozen different things.  Shouldn't they all be
> made into sysctls then?  Just wondering...

Many of them can already be obtained via sysctl (e.g. vmtotal, proc
list). This is rather historical dependency, or one related to very rare
uses (like reading VM statistics from post mortem dump).

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: Is FreeBSD dead? Well, not in theory...

[Jeroen Ruigrok/Asmodai]

-On [2312 00:00], Joe Abley ([EMAIL PROTECTED]) wrote:
>On Sat, Mar 11, 2000 at 01:36:31PM -0500, Dennis wrote:

>> Another point is that Open Source is virtually synonomous with "Totally
>> undocumented".
>
>This is sillier.

Exactly, and it also slightly pisses me off...

Then I guess I wrote all the manpages and documents for nothing.

elf.5 comes to mind for a very handy resource.

http://home.wxs.nl/~asmodai/newbus-draft.txt comes to mind.  And when
that is finished the manpages will follow.

That's also why I am wasting my time slowly documenting the FreeBSD
internals in my spare time.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
You prayed before, who are the prayers for..?


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

Re: Dennis' inability to fix the eepro driver

[Dennis]

At 03:29 PM 3/12/00 +0200, Narvi wrote:
>
>On Sat, 11 Mar 2000, Mike Smith wrote:
>
>[snip]
>
>> > Why haven't you considered hiring somebody to document the parts you are
>> > intersted in? Would solve at least half the problem...
>> 
>> To be fair to Dennis, it's not the cost of paying the dropout to fix this 
>> driver that's at issue here.  
>> 
>> Documentation for the eepro parts is not easy to get; I only have one 
>> outdated hardcopy, and I get all sorts of weird stuff thrown at me.
>> 
>
>Nah. It wasn't in response to anything that dealt with the driver. Nothing
>to do with eepro at all.
>
>It was in response to the rant about how everything was undocumented
>spaghetty code so few people could make any sense of that people were
>virtually dependant on those few. 

More communist propaganda :-)

My *point* was simply that, not only is it difficult to make major changes
to critical code without substantial documentation (all of us know that
something that *looks* wrong may very will be there for an obscure reason),
but when you do you lose the benefits of code improvements in the next
release unless you do it again. Its not realistic.

Plus, when you make a change, ANY problem with that driver, even if it has
nothing to do with the change, is your problem. So, by making even a minor
improvement, you take on a support responsibilty (as a commercial vendor)
for code that isnt yours and may be extremely difficult to debug.


dennis



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

WRT `Is FreeBSD dead?'

[Jeroen Ruigrok/Asmodai]

Could we place relocate this topic to -chat or -advocacy, since it
doesn't seem that correct to be discussed on -hackers.

Hackers was meant for quality technical discussion, not discussions
about FUD, stupidity of people whom don't read official messages posted
prior to stating things, spinning off and more of that non-technical
crap.

Thanks,

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
I must be cruel, only to be kind...


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

Re: FreeBSD is dead! Long live FreeBSD!

[Dennis]

>
>I think this is an exciting period in FreeBSD's development, I personally
>am very excited. 

I think it *could* be a "good" thing, but the proof of the pudding is in
the taste. Just keep a bag packed in case.

DB



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

Re: Getting CPU usage in FreeBSD

[Oliver Fromme]

Kris Kennaway <[EMAIL PROTECTED]> wrote in list.freebsd-hackers:
 > On Sun, 12 Mar 2000, Oliver Fromme wrote:
 > > Then look up the definition of kread() in the same file, and
 > > how the contents of cur.cp_time are used in the cpustats()
 > > function.  Note that "cur" is a "struct statinfo", which is
 > > defined in /usr/include/devstat.h.  The CPU states are defined
 > > in /usr/include/sys/dkstat.h.
 > 
 > We probably should make this into a sysctl to divorce the binaries from
 > having to read kvm.

Sounds like a good idea.  But then again, vmstat.c uses kvm
for about a dozen different things.  Shouldn't they all be
made into sysctls then?  Just wondering...

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


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

Re: Getting CPU usage in FreeBSD

[Andrzej Bialecki]

On Sat, 11 Mar 2000, Kris Kennaway wrote:

> On Sun, 12 Mar 2000, Oliver Fromme wrote:
> 
> > Then look up the definition of kread() in the same file, and
> > how the contents of cur.cp_time are used in the cpustats()
> > function.  Note that "cur" is a "struct statinfo", which is
> > defined in /usr/include/devstat.h.  The CPU states are defined
> > in /usr/include/sys/dkstat.h.
> 
> We probably should make this into a sysctl to divorce the binaries from
> having to read kvm.

I'm definitely for it... If I can get permission from Jordan, perhaps the
attached patches can make it into upcoming release.

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 


Index: sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.25
diff -u -r1.25 sysctl.c
--- sysctl.c1999/11/22 08:43:00 1.25
+++ sysctl.c2000/03/12 15:35:12
@@ -46,6 +46,7 @@
 #endif /* not lint */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -219,6 +220,29 @@
 /* These functions will dump out various interesting structures. */
 
 static int
+S_cpu_time(int l2, void *p)
+{
+   long *cpt=(long *)p;
+   double d,total;
+   int i;
+
+   total=0;
+   for(i=0;i

Index: kern_clock.c
===
RCS file: /home/ncvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.105
diff -u -r1.105 kern_clock.c
--- kern_clock.c2000/02/13 10:56:32 1.105
+++ kern_clock.c2000/03/12 15:35:44
@@ -105,6 +105,9 @@
 SYSCTL_STRUCT(_kern, KERN_BOOTTIME, boottime, CTLFLAG_RD,
 &boottime, timeval, "System boottime");
 
+SYSCTL_OPAQUE(_kern, OID_AUTO, cpu_time, CTLFLAG_RD, &cp_time,
+   sizeof(cp_time), "S,cpu_time", "CPU times");
+
 /*
  * Which update policy to use.
  *   0 - every tick, bad hardware may fail with "calcru negative..."

FreeBSD is dead! Long live FreeBSD!

[Pat Lynch]

heh, having read over the responses of the people "in the know" (and I've
only known about this for a month or two and only by guessing ;)) I think
this is very beneficial.

Jordan, as always has thought about everything, contingency plans, and has
made it very clear that the aquisition of WCCDROM is not one of FreeBSD as
well. 

However the FreeBSD team benefits from having several key BSD developers
whom we all look up to getting involved. I already have seen posts from
Sam Leffler, Kirk has been involved for a while with FreeBSD and I know
for a fact this is a vote of confidence on his part about the business
viability of FreeBSD as well as its technical merits. 

I think this is an exciting period in FreeBSD's development, I personally
am very excited. 

if FreeBSD is dead, Long live FreeBSD.

-Pat

__

Pat Lynch   [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Systems Administrator   Rush Networking



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

Re: ATA-disk question

[Soren Schmidt]

It seems Sitaram Iyer wrote:
> (kernel 4.0-2208-CURRENT)
> 
> I have a question about adstrategy() in ata-disk.c: it says
> 
>   bufqdisksort() -- which appends to the drive queue using CSCAN,
> 
> and immediately, without a check for adp->active, there is
> 
>   ad_start() -- which removes it from there and puts it into the
> controller queue, thereby nullifying CSCAN's effect
> completely (drive queue length always = 0 or 1) and
> blowing up the controller TAILQ to occasional spurts
> with tens of requests (I measured this).
> 
> on browsing through cvsweb, I find that such a check used to be there
> earlier ( bufqdisksort(&adp->queue, bp); if (!adp->active) ad_start(adp); )
> till "1.14 Fri Jun 25 9:02:59 1999 UTC by sos" (the 9th ATA update), and the
> only thing in the commit log that's making sense to me is:
> 
>   "The disk driver has been changed a bit to prepare for tagged
>   queing, which is next on my list." -- sos
> 
> What's the exact rationale behind doing away with CSCAN? is it temporary?
> Its not entirely clear to me how "tagged queueing" (whatever that is) would
> remedy the fact that requests are taken away from drive queues as soon as
> they're put there.

This was part of the code for tagged queueing, but since that has been
put on hold for now, this is clearly a bug. Tagged queueing is the term
for having multiple outstanding requests on the disk, and let the disk
sort out in which ord to complete them.

-Søren


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

Re: Dennis' inability to fix the eepro driver

[Narvi]

Uhhh... 

And before anybody gets all kinds of funny ideas, no, i am not trying to
blackmail Dennis.

On Sun, 12 Mar 2000, Narvi wrote:

> 
> On Sat, 11 Mar 2000, Mike Smith wrote:
> 
> [snip]
> 
> > > Why haven't you considered hiring somebody to document the parts you are
> > > intersted in? Would solve at least half the problem...
> > 
> > To be fair to Dennis, it's not the cost of paying the dropout to fix this 
> > driver that's at issue here.  
> > 
> > Documentation for the eepro parts is not easy to get; I only have one 
> > outdated hardcopy, and I get all sorts of weird stuff thrown at me.
> > 
> 
> Nah. It wasn't in response to anything that dealt with the driver. Nothing
> to do with eepro at all.
> 
> It was in response to the rant about how everything was undocumented
> spaghetty code so few people could make any sense of that people were
> virtually dependant on those few. 
> 
> [snip]
> 
> > 
> > -- 
> > \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> > \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> > \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> > 
> > 
> 
> 



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

Re: Dennis' inability to fix the eepro driver

[Narvi]

On Sat, 11 Mar 2000, Mike Smith wrote:

[snip]

> > Why haven't you considered hiring somebody to document the parts you are
> > intersted in? Would solve at least half the problem...
> 
> To be fair to Dennis, it's not the cost of paying the dropout to fix this 
> driver that's at issue here.  
> 
> Documentation for the eepro parts is not easy to get; I only have one 
> outdated hardcopy, and I get all sorts of weird stuff thrown at me.
> 

Nah. It wasn't in response to anything that dealt with the driver. Nothing
to do with eepro at all.

It was in response to the rant about how everything was undocumented
spaghetty code so few people could make any sense of that people were
virtually dependant on those few. 

[snip]

> 
> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
> 
> 



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

Re: Is FreeBSD dead? Well, not in theory...

[W Gerald Hicks]

Once again I must ask... What do you know of Open Source?

Aside from your enlightened criticisms I've seen nothing in
the way of any sort of contribution.  No ports maintenance,
no code contribution. Nothing other than pure profiteering
and never returning anything but a kick in the nuts.

Thanks (not)

--

Jerry Hicks
[EMAIL PROTECTED]

From: Dennis <[EMAIL PROTECTED]>
Subject: Re: Is FreeBSD dead? Well, not in theory... 
Date: Sat, 11 Mar 2000 13:36:31 -0500

> [EMAIL PROTECTED] writes...
> 
> >The very fact that source is available means that you can pay any scruffy
> >unshaven hacker to fix it for you, instead of suffering at the hands and
> >whims of, say, a FreeBSD "vendor" as you are doing. I would figure that at
> >least you (of all people) realize that someone else can come in and get it
> >done, and that you could optionally pay someone to do this.
> 
> Not realistically. First of all, most "scruffy unshaven hackers" are not
> qualified to...

[rant and shameless self-promotion elided]


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