'machine/param.h' required for 'sys/socket.h'

[Nickolay Dudorov]

After the following commit:

shin2000/03/03 03:13:13 PST

  Modified files:
lib/libc/net rthdr.c 
sys/sys  socket.h 
sys/kern uipc_socket2.c 
sys/netinet6 ip6_output.c 
usr.bin/telnet   commands.c 
sbin/pingping.c 
  Log:
  CMSG_XXX macros alignment fixes to follow RFC2292.
  
  Approved by: jkh
  
  Submitted by: Partly from tech@openbsd
  Reviewed by: itojun
  
  Revision  ChangesPath
  1.2   +19 -7 src/lib/libc/net/rthdr.c
  1.38  +8 -13 src/sys/sys/socket.h
  1.55  +4 -5  src/sys/kern/uipc_socket2.c
  1.12  +3 -3  src/sys/netinet6/ip6_output.c
  1.21  +13 -15src/usr.bin/telnet/commands.c
  1.52  +2 -2  src/sbin/ping/ping.c

'sys/scocket.h' header file start using ALIGN macro 
defined in 'machine/param.h' header file while the man page
for "socket" only mentioned 'sys/types.h' as the prerequisite
for 'sys/socket.h'.

As a result the 'net/pchar' port is now broken.

What must be done to solve this ? 
Is it possible to '#include sys/param.h' in 'sys/socket.h' OR
the man page must be corrected to explicitly state 'param.h'
(sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and
all the programms using it patched accordingly ?

N.Dudorov


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

Floating point exceptions.

[David Malone]

Floating point exceptions seem to have been turned off by default:

gonzo 13% uname -r
5.0-CURRENT
gonzo 14% cat a.c
double div(double x,double y) { return x/y; }
int main() { double x; x = div(1.0,0.0); printf("%f\n",x); }
gonzo 15% gcc -o a a.c
gonzo 16% ./a
Inf

This seems to produce an SIGFPE on 3.0, which I would have thought
was the correct thing to do:

walton 12% uname -r
3.4-STABLE
walton 13% cat a.c
double div(double x,double y) { return x/y; }
int main() { double x; x = div(1.0,0.0); printf("%f\n",x); }
walton 14% gcc -o a a.c
walton 15% ./a
Floating exception (core dumped)

There was a discussion on one of the list about what to do for
floating point excpetions recently, and I thought people decided
that causing a signal by default was a right thing? I presume this
was caused by the commit below?

David.

cracauer2000/03/10 09:56:33 PST

  Modified files:
sys/i386/include npx.h 
  Log:
  Change the default FPU control word so that exceptions for new
  processes are now masked until set by fpsetmask(3).
  
  Submitted by: bde
  Approved by:  jkh, bde
  
  Revision  ChangesPath
  1.18  +5 -35 src/sys/i386/include/npx.h



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

Re: Floating point exceptions.

[Martin Cracauer]

In [EMAIL PROTECTED], David Malone wrote: 
 Floating point exceptions seem to have been turned off by default:
[...]
 There was a discussion on one of the list about what to do for
 floating point excpetions recently, and I thought people decided
 that causing a signal by default was a right thing?

The outcome was that applications that care must set the control word
themself and that we go the way of least resistance for the rest.

Martin
-- 
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


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

Re: B_WRITE cleanup patch, please test!

[Julian Elischer]

Poul-Henning Kamp wrote:
 
 In message [EMAIL PROTECTED], Matthew Dillon writes:
 I think the biggest win in regards to being able to arbitrarily stack
 devices is to NOT attempt to forward struct buf's between devices when
 non-trivial manipulation is required, and instead to make struct buf's
 cheap enough that a device can simply allocate a new one and copy the
 appropriate fields.
 
 In particular I really hate all the various b_*blkno fields.  b_lblkno,
 b_blkno, and b_pblkno.  It is precisely due to the existance of these
 hacks that arbitrary device stacking is difficult.
 
 This is basically what the stuff I'm doing addresses.

I have been advocating since 1991 that the memory involved with IO
should be referenced as a vector of page/offset/length
triplets (physical addresses), and that all drivers should take
that as input. IF he driver needs to do programmed IO only then should
it map the page into KV space.

 
 --
 Poul-Henning Kamp FreeBSD coreteam member
 [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
 FreeBSD -- It will take a long time before progress goes too far!

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
--- X_.---._/  presently in:  Perth
v


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

Re: XFree86 under -current - a bug report

[Dominic Mitchell]

On Mon, Mar 20, 2000 at 11:48:16PM +0300, Ilya Naumov wrote:
 i've tried to build XFree86 4.0 on my 5.0-CURRENT and 4.0-RELEASE box, and 
encountered
 a problem.
 
 "make all" finishes successfully, but "make install" fails with the
 following error message:
 
 making all in programs/Xserver/hw/xfree86/os-support/bsd...
 rm -f bsd_mouse.o
 cc -c -O -pipe  -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith   -I../../../.
 ./../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/
 hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include
   -I../../../../../../exports/include/X11 -I../../../../../../include/extensions
  -I../../../../../../programs/Xserver/mi -I   -I../../../../../.. -I../.
 ./../../../../exports/include  -DCSRG_BASED -DSHAPE  -DXKB -DLBX -DXAPPGROUP -DX
 CSECURITY -DTOGCUP  -DXF86BIGFONT -DDPMSExtension  -DPIXPRIV -DPANORAMIX  -DGCCU
 SESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFre
 e86LOADER  -DXFree86Server -DXF86VIDMODE  -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART
 _SCHEDULE -DNDEBUG   -DFUNCPROTO=15 -DNARROWPROTO   -DPCCONS_SUPPORT -DSYSCONS_S
 UPPORT -DPCVT_SUPPORT  -DUSE_DEV_IO -DUSESTDRES   -DHAS_MTRR_SUPPORT   b
 sd_mouse.c
 In file included from bsd_mouse.c:11:
 ../../../../../../programs/Xserver/hw/xfree86/common/xf86Xinput.h:99: syntax err
 or before `xDeviceCtl'
 *** Error code 1
 
 Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support/
 bsd.
 *** Error code 1

Try enabling the XIE (or was it XInput) extension when you configure it.
That seemed to do the trick for me.  After that, it's all up and running
nicely.  Finally, I can easily get at TT fonts! (just wish they included
ttkmfdir...)

-- 
Dom Mitchell -- Palmer  Harvey McLane -- Unix Systems Administrator

``Putting the doh! into dot-com.''


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

Re: Floating point exceptions.

[David Malone]

  There was a discussion on one of the list about what to do for
  floating point excpetions recently, and I thought people decided
  that causing a signal by default was a right thing?
 
 The outcome was that applications that care must set the control word
 themself and that we go the way of least resistance for the rest.

OK - I just did a quick scout around. Digital Unix gives a SIGFPE;
Solaris, AIX and Redhat print some captalisation of "Inf"; HP/UX
prints "++.00" ;-)

Is there a way of setting the control word which is in any sense
portable? Most machines I've looked at seem to have no documented
way of setting what exceptions should be masked, and each one that
does has a different set of calls.

David.


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

Re: Floating point exceptions.

[Martin Cracauer]

In [EMAIL PROTECTED], David Malone wrote: 
   There was a discussion on one of the list about what to do for
   floating point excpetions recently, and I thought people decided
   that causing a signal by default was a right thing?
  
  The outcome was that applications that care must set the control word
  themself and that we go the way of least resistance for the rest.
 
 OK - I just did a quick scout around. Digital Unix gives a SIGFPE;
 Solaris, AIX and Redhat print some captalisation of "Inf"; HP/UX
 prints "++.00" ;-)
 
 Is there a way of setting the control word which is in any sense
 portable? 

It is an i386 assembler instruction. Obviously, operating system
vendors thought it's not their business, but the compiler's.
Unfortunately, gcc doesn't care (although most other native compilers
like SRC m3, CMUCL, SML/NJ do).

FreeBSD's fpsetmask(3) stuff is simple inline assembler that I
personally used in Linux, it should be relativly easy to carry it
around with your application on i386 machines.

Martin
-- 
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


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

Reading from bad disk ?

[Luigi Rizzo]

Hi,

sometimes i get IDE disks with hard errors on some sectors

(status 59rdy,seekdone,drq,err error 40uncorr)

and of course this makes it problematic to use a filesystem on it.
I wonder, is there a way to fetch the data from these sectors
(even if partly erroneous) ?

I am asking because a strategy which often 'fixes' the
problem for me is to overwrite the erroneous sector with some data.
Of course i can use a zero-filled block but this is kind of risky,
and maybe it is preferable to use a portion of the original data
and hope that fsck is able to fix this.

And related: is there a way to tell fsck that in such cases
it should try and adopt the same method ? Otherwise it is
really boring to run my locally modified version of dd
(which is able to use 'skip' over character devices) to
try read the bad sector and write it back.

cheers
luigi
---+-
  Luigi RIZZO, [EMAIL PROTECTED]  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
---+-


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

Re: Mylex Support

[Matthew Sean Thyer]

Are there any particular preparation processes one should go through
when setting up a Mylex DAC960 RAID array ?
(if so give me a pointer to the docs)

Can I just purchase all the hardware, plug in the disks and boot the
FreeBSD-4 install floppies ?  (for a system to be booting from the
array with no internal ATA devices)

or Should I have an internal ATA hard disk with some evil OS on it
such as Lose 9X or NT so as to run any kind of Mylex DOS/Windows
preparation utilities ?

On Fri, 10 Mar 2000, Mike Smith wrote:

  I have 4 different Mylex DAC960 controllers that I cannot install Current
  onto. (Tried from Late December to 2307). Sysinstall seems to get the
  geometry wrong, and even telling sysinstall the "correct" geometry, it gives
  a "tied to write beyond end of drive" error. Booting from a running -current
  and formatting does the same. They all have the latest BIOS, and they have
  been tried with various drive combinations. Has anyone else got this to work
  successfully or is it just me?.
 
 Obviously; you're actually the _only_ person I've heard from with this 
 problem.
 
  And if it is just me, anyone got any ideas? I have been pestering Mike Smith
  about this for ages, and have probably driven him mad!
 
 More or less.  As I've said - I have no idea what's going on for you at 
 the moment; everything here "just works" like it should.
 
 



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

Re: AMI MegaRAID lockup? not accepting commands.

[Brad Knowles]

At 7:25 PM -0800 2000/3/20, Mike Smith wrote:

  Not that I consider this particuarly optimal; busy-waiting for the
  controller is a terrible waste of the host CPU.  A better solution would
  probably defer the command and try again a short time later, but let's
  see if this works first.

Since this is a device driver, I guess you can't usleep() and 
then check again?  Is there anything else useful you could be doing 
during that period of time -- other than busy waiting?

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

Re: Floating point exceptions.

[Brad Knowles]

At 10:28 AM +0100 2000/3/21, Martin Cracauer wrote:

  It is an i386 assembler instruction. Obviously, operating system
  vendors thought it's not their business, but the compiler's.
  Unfortunately, gcc doesn't care (although most other native compilers
  like SRC m3, CMUCL, SML/NJ do).

Note that I have recently heard some complaints about Perl in 
this respect -- Perl considers it to be a hardware issue, and code 
that depends on a SIGFPE will not necessarily function the same under 
the same version of Perl, running on different OSes.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

Re: Reading from bad disk ?

[Soren Schmidt]

It seems Luigi Rizzo wrote:
 Hi,
 
 sometimes i get IDE disks with hard errors on some sectors
 
   (status 59rdy,seekdone,drq,err error 40uncorr)
 
 and of course this makes it problematic to use a filesystem on it.
 I wonder, is there a way to fetch the data from these sectors
 (even if partly erroneous) ?
 
 I am asking because a strategy which often 'fixes' the
 problem for me is to overwrite the erroneous sector with some data.
 Of course i can use a zero-filled block but this is kind of risky,
 and maybe it is preferable to use a portion of the original data
 and hope that fsck is able to fix this.

Erhm, I would get a new disk :), you dont intend to trust any
data to this setup do you ??

Anyhow, I dont remember if it is possible to actually get at the data on
a transfer that the drive marked bad, but I can check up when I get 
to my doc shelf. But I wouldn't trust that data for _anything_ it is 
likely to be totally corrupted due to the drive trying to ECC correct 
it and what not...

-Søren


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

Re: Reading from bad disk ?

[Luigi Rizzo]

  I am asking because a strategy which often 'fixes' the
...
 Erhm, I would get a new disk :), you dont intend to trust any
 data to this setup do you ??

of course, but i need to recover the old stuff first!

A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
to become very hot compared to other disks when mounted in the
same machine (on a removable frame). Do others have the same
experience ?

 Anyhow, I dont remember if it is possible to actually get at the data on
 a transfer that the drive marked bad, but I can check up when I get 
 to my doc shelf. But I wouldn't trust that data for _anything_ it is 
 likely to be totally corrupted due to the drive trying to ECC correct 
 it and what not...

still might be useful for visual inspection.

cheers
luigi
---+-
  Luigi RIZZO, [EMAIL PROTECTED]  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
---+-


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

Re: Reading from bad disk ?

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Luigi Rizzo writes:
  I am asking because a strategy which often 'fixes' the
...
 Erhm, I would get a new disk :), you dont intend to trust any
 data to this setup do you ??

of course, but i need to recover the old stuff first!

A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
to become very hot compared to other disks when mounted in the
same machine (on a removable frame). Do others have the same
experience ?

You need a fan in the removable frame for those, they do run very hot.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Reading from bad disk ?

[Soren Schmidt]

It seems Luigi Rizzo wrote:
   I am asking because a strategy which often 'fixes' the
 ...
  Erhm, I would get a new disk :), you dont intend to trust any
  data to this setup do you ??
 
 of course, but i need to recover the old stuff first!

Hmm, right...

 A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
 to become very hot compared to other disks when mounted in the
 same machine (on a removable frame). Do others have the same
 experience ?

If that is a plastic frame and there is no fan in the drawer it
will get hot, in my boxes its enough to take of top and bottom
covers on the drawers, that allows enough airflow to keep the
disks at an accceptable temp...

-Søren


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

Re: syslogd_flags in /etc/defaults/rc.conf

[Will Andrews]

On Mon, Mar 20, 2000 at 09:45:49AM -0800, Nick Johnson wrote:
 I'm curious to see if anyone is like-minded with me that syslogd_flags in
 /etc/defaults/rc.conf should be "-ss" instead of "".  I reasoned that it
 should be, considering:
 
   1. Most people don't direct syslogs at other machines in my experience.
   2. Someone could conceivably DOS a machine by directing tons of crap at 
  port 121, which is also noted in the BUGS section of the syslogd
  manpage.
   3. Syslogd runs as root, and while it is a mature piece of code, I think
  it preferable to minimize the number of root applications listening
  on sockets.

This seems like a reasonable change. Thanks for pointing this out! :)

-- 
Will Andrews [EMAIL PROTECTED]
GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ 
G+ e- h! r--+++ y?


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

Re: Floating point exceptions.

[Bruce Evans]

On Tue, 21 Mar 2000, David Malone wrote:

 Is there a way of setting the control word which is in any sense
 portable? Most machines I've looked at seem to have no documented
 way of setting what exceptions should be masked, and each one that
 does has a different set of calls.

No.  C99 provides an (optional) portable way of setting the rounding
mode (fesetround() corresponds to fpsetround()), but doesn't provide
a portable way to set the precision or exception masks.  It only
provides fesetenv(), and the only portable args for fesetenv() are
FE_DFL_ENV (which gives the default environment) and a pointer to
a result filled in by a previous call to fegetenv().

Bruce



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

can't dump vinum volumes after upgrading

[Palle Girgensohn]

Hi!

I'm having a strange problem after upgrading: There are no raw
devices created for vinum volumes. This makes dump(8) puke.


This is a 3.4 system:

ls -laF /dev/vinum
...
crwxr-xr--  1 root  wheel   91,   1  2 Jul  1999 rusr*
drwxr-xr-x  2 root  wheel   512  2 Jul  1999 rvol/
...
brwxr-xr--  1 root  wheel   25,   1  2 Jul  1999 usr*
drwxr-xr-x  4 root  wheel   512  2 Jul  1999 vol/
...

and here's a 4.0:

crw-r-   1 root  wheel   91,   0 21 Mar 13:40 usr
drwxr-xr-x  11 root  wheel   512 21 Mar 13:40 vol/


vinum makedev doesn't help. what gives?

/Palle


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

Re: emu10k1 (SB Live!) support under FreeBSD?

[Thomas T. Veldhouse]

What kind of drivers are these?  Are these ports of the ALSA drivers, or are
they more OSS?

Tom Veldhouse
[EMAIL PROTECTED]

 I applied the patch to a machine which is *just* pre 4/5 split and it
patched
 fine.

 I used it to get my ALS120 to work.





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

Re: -current sudden panics :(

[Yoshinobu Inoue]

Hello,

 Fatal 12 trap: page fault while in kernel mode
 fault virtual address   = 0x8
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc01843fc
 stack pointer   = 0x10:0xc026bd64 
 frame pointer   = 0x10:0xc026bd64 
 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 = Idle
 interrupt mask  =
 kernel: type 12 trap, code=0
 Stopped at  arpintr+0x9c:  movl0x8(%ebx),%ecx
 
 trace gave this:
 arpint(c022537b,0,10,10,c0220010) at arpintr+0x9c
 swi_net_next() at awi_net_next
 
 I'm sending kernel config and dmesg in the attachment. I have INET6 there,
 but it is not configured by ifconfig.
 
 What's this and how can i avoid this panics?

Do you have any other hints for the problem?, because at least
I couldn't reproduce it in my 4.0 and 5.0 machines.

  -Any kernel crash dump?
  -Is there any typical situation or condition where the
   problem happens?
  -What is your LAN card?


Thanks,
Yoshinobu Inoue


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

breakage on amd in latest current

[Jason Garman]

From today's -current:

cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -ansi  -nostdinc -I- -I. -I../..
-I../../../include  -D_KERNEL -include opt_global.h -elf
-mpreferred-stack-boundary=2  ../../pci/amd.c
../../pci/amd.c:168: variable `amd_device' has initializer but incomplete
type
../../pci/amd.c:170: warning: excess elements in struct initializer
../../pci/amd.c:170: warning: (near initialization for `amd_device')
../../pci/amd.c:171: warning: excess elements in struct initializer
../../pci/amd.c:171: warning: (near initialization for `amd_device')
../../pci/amd.c:172: warning: excess elements in struct initializer
../../pci/amd.c:172: warning: (near initialization for `amd_device')
../../pci/amd.c:173: warning: excess elements in struct initializer
../../pci/amd.c:173: warning: (near initialization for `amd_device')
../../pci/amd.c:175: warning: excess elements in struct initializer
../../pci/amd.c:175: warning: (near initialization for `amd_device')
../../pci/amd.c:899: warning: `amd_timeout' defined but not used
../../pci/amd.c:857: warning: `amd_reset' defined but not used
*** Error code 1

Stop in /usr/src/sys/compile/JASONLAP.


-- 
Jason Garman http://web.wedgie.org/
Student, University of Maryland  [EMAIL PROTECTED]
From fortune(1):  Whois: JAG145
  "... Had this been an actual emergency, we would have fled in terror,
   and you would not have been informed."


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

No Subject

[Jeremiah Gowdy]

subscribe [EMAIL PROTECTED]



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

/boot/loader is making my VAIO reboot

[Ollivier Robert]

Since after the Feb. 25th, /boot/loader is rebooting the machine during
boot. I can't get to the prompt at all. The only version that works is the
25th one (I didn't upgrade between the Feb. 25th and March, 17th).

Nothing in the BIOS configuration changed during that period...

-r-xr-xr-x  1 root  wheel  143360 Mar 21 16:39 loader   REBOOTS
-r-xr-xr-x  2 root  wheel  143360 Feb 25 20:03 loader.old   WORKS

This is on my VAIO laptop (Z505SX, PII/366, 128 MB).

Any idea ?
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- [EMAIL PROTECTED]
The Postman hits! The Postman hits! You have new mail.


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

Re: -current sudden panics :(

[Nikolai Saoukh]

On Wed, Mar 22, 2000 at 12:51:36AM +0900, Yoshinobu Inoue wrote:

  trace gave this:
  arpint(c022537b,0,10,10,c0220010) at arpintr+0x9c
  swi_net_next() at awi_net_next
  
  I'm sending kernel config and dmesg in the attachment. I have INET6 there,
  but it is not configured by ifconfig.
  
  What's this and how can i avoid this panics?
 
 Do you have any other hints for the problem?, because at least
 I couldn't reproduce it in my 4.0 and 5.0 machines.
 
   -Any kernel crash dump?
   -Is there any typical situation or condition where the
problem happens?
   -What is your LAN card?

The driver for his card does not set packet header pointer, thus
arp stuff see NULL pointer. small patch will cure this problem
(at least I hope so).

*** if_ed.c.old Tue Mar 21 19:21:40 2000
--- if_ed.c Tue Mar 21 19:23:27 2000
***
*** 2728,2733 
--- 2728,2734 
 */
m-m_pkthdr.len = m-m_len = len - sizeof(struct ether_header);
m-m_data += sizeof(struct ether_header);
+   m-m_pkthdr.header = (void *)eh;
  
ether_input(sc-arpcom.ac_if, eh, m);
return;


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

Re: -current sudden panics :(

[Yoshinobu Inoue]

-What is your LAN card?

Woops, I often do a needless query. That should be using rl
driver as the kernel log.

 The driver for his card does not set packet header pointer, thus
 arp stuff see NULL pointer. small patch will cure this problem
 (at least I hope so).
 
 *** if_ed.c.old   Tue Mar 21 19:21:40 2000
 --- if_ed.c   Tue Mar 21 19:23:27 2000
 ***
 *** 2728,2733 
 --- 2728,2734 
*/
   m-m_pkthdr.len = m-m_len = len - sizeof(struct ether_header);
   m-m_data += sizeof(struct ether_header);
 + m-m_pkthdr.header = (void *)eh;
   
   ether_input(sc-arpcom.ac_if, eh, m);
   return;

But shouldn't it be sys/pci/if_rl.c ?

Yoshinobu Inoue


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

Re: -current sudden panics :(

[Nikolai Saoukh]

On Wed, Mar 22, 2000 at 01:51:53AM +0900, Yoshinobu Inoue wrote:

 But shouldn't it be sys/pci/if_rl.c ?

Sorry,
it is mea culpa. I mixed his case with my (token ring).


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

Re: Voxware is toast. Get used to it. (Re: Suggestions for improving newpcm performance?)

[Thomas T. Veldhouse]

This is an old debate.  However, if the user is not smart enough to know
that a "not" release is new and should be tested, well, that speaks volumes
itself doesn't it?

Tom Veldhouse
[EMAIL PROTECTED]

- Original Message -
From: David Murphy [EMAIL PROTECTED]
To: Brad Knowles [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, March 21, 2000 10:37 AM
Subject: Re: Voxware is toast. Get used to it. (Re: Suggestions for
improving newpcm performance?)


 Quoting v04220821b4fd4f825554@[195.238.1.121]
 by Brad Knowles [EMAIL PROTECTED]:

  We just got our official shrink-wrapped versions of Solaris 8 from
  Sun.  Do you think we're actually going to be stupid enough to try
  to put this into production any time within the next few months?

  It's an x.0 release from Sun, and we're going to treat it just like
  we do with x.0 releases from *any* vendor.  We may play with it on
  our desktops, we may do some prototyping with it, etc

 Right, and if you try to upgrade your Solaris 7 desktop, which, while
 not a production server, is a machine you personally need to do your
 job, to Solaris 8, and it fails, and you call Sun about it, and they
 tell you "Hey, what do you think you're doing? That's not ready for
 real use yet!". You wouldn't be too impressed, would you? That's
 basically the scenario I'm seeing with FreeBSD.

  Thing is, it's *not* a beta anymore.  It's more like a gamma
  version.

 Call it -GAMMA then. Bascially, I'm saying I think it should be called
 something other than -RELEASE until the average user can install it,
 and upgrade to it from the prior version.

  The *only* way to proceed from here is to actually release the
  thing, let people start trying to use it, and then report bugs back.
  But we wouldn't be acting in good faith if we didn't at least warn
  people that it's not quite ready for use on production servers.

 IMHO the place for that warning is the release announcement and the
 release notes, and it wasn't in either last I looked.




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

Re: 'machine/param.h' required for 'sys/socket.h'

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

 
  'sys/scocket.h' header file start using ALIGN macro 
  defined in 'machine/param.h' header file while the man page
  for "socket" only mentioned 'sys/types.h' as the prerequisite
  for 'sys/socket.h'.
  
  As a result the 'net/pchar' port is now broken.
 
 Yes, this problem is already found by Bruce A. Mah and some
 mail is exchanged between related people.

I'm doing a pointrev to pchar to "fix" this problem...see below.

  What must be done to solve this ? 
  Is it possible to '#include sys/param.h' in 'sys/socket.h' OR
  the man page must be corrected to explicitly state 'param.h'
  (sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and
  all the programms using it patched accordingly ?
 
 As itojun's experience, including machine/param.h in socket.h
 also cause problems in some other apps.
 
 I feel requesting inclusion of machine/param.h for any apps
 which use socket is better. But if there are any other smarter
 solution, please let me know and I'll appreciate it much.

Just speaking as the slightly whiny developer of pchar:  What bothers me
is that out of all the platforms where pchar can do IPv6 support, recent
FreeBSD versions seem the *only* case where I need to include machine/
param.h in order to use the CMSG* macros.  This means that FreeBSD is
forcing me to make some code changes that aren't required for *any*
other platform.  According to itojun's earlier mail, I can't just
blindly include machine/param.h either.  So I need to figure out at
compile-time or configure-time whether or not I need machine/param.h.

Personally, I think this is a lose.  Unfortunately I don't have any
better suggestion than "back out your last commit".

In the specific case of pchar, I need to make code changes in order to
work with 4.0-RELEASE, now that it's been shipped with the header files
as we've discussed.  So I wrote a bunch of autoconf code to detect this
breakage and fix it.  I'll probably roll in some Solaris fixes also and
call this pchar-1.1.2 or something like that.

Bruce.




 PGP signature

Re: AMI MegaRAID lockup? not accepting commands.

[Matthew Dillon]

:At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
:
:  Not that I consider this particuarly optimal; busy-waiting for the
:  controller is a terrible waste of the host CPU.  A better solution would
:  probably defer the command and try again a short time later, but let's
:  see if this works first.
:
:   Since this is a device driver, I guess you can't usleep() and 
:then check again?  Is there anything else useful you could be doing 
:during that period of time -- other than busy waiting?
:
:--
:   These are my opinions -- not to be taken as official Skynet policy
:==
:Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV
:Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124

For situations that aren't in the critical path and don't happen often,
it may be beneficial to do a voluntary context switch inside the loop.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Crash on current at cvs-cur.6182

[Stephen Hocking-Senior Programmer PGS SPS Perth]

The back trace reads ...

#0  boot (howto=260) at ../../kern/kern_shutdown.c:304
#1  0xc013d7e5 in panic (fmt=0xc0273514 "from debugger")
at ../../kern/kern_shutdown.c:554
#2  0xc01265bd in db_panic (addr=-1071292651, have_addr=0, count=-1, 
modif=0xc5ec6ce4 "") at ../../ddb/db_command.c:433
#3  0xc012655d in db_command (last_cmdp=0xc02abc0c, cmd_table=0xc02aba6c, 
aux_cmd_tablep=0xc02e4514) at ../../ddb/db_command.c:333
#4  0xc0126622 in db_command_loop () at ../../ddb/db_command.c:455
#5  0xc0128733 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6  0xc0255cb5 in kdb_trap (type=3, code=0, regs=0xc5ec6dec)
at ../../i386/i386/db_interface.c:158
#7  0xc0262680 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, 
  tf_esi = 256, tf_ebp = -974361036, tf_isp = -974361064, 
  tf_ebx = -1071048832, tf_edx = 0, tf_ecx = -1070604608, tf_eax = 18, 
  tf_trapno = 3, tf_err = 0, tf_eip = -1071292651, tf_cs = 8, 
  tf_eflags = 582, tf_esp = -1070994113, tf_ss = -1071158909})
at ../../i386/i386/trap.c:549
#8  0xc0255f15 in Debugger (msg=0xc0276983 "panic") at machine/cpufunc.h:64
#9  0xc013d7dc in panic (
fmt=0xc0291780 "vm_object_terminate: freeing busy page %p\n")
at ../../kern/kern_shutdown.c:552
#10 0xc02143f3 in vm_object_terminate (object=0xc5ebee40)
at ../../vm/vm_object.c:442
#11 0xc0214314 in vm_object_deallocate (object=0xc5ebee40)
at ../../vm/vm_object.c:377
#12 0xc02117f7 in vm_map_entry_delete (map=0xc5982980, entry=0xc5ec2270)
at ../../vm/vm_map.c:1727
#13 0xc0211979 in vm_map_delete (map=0xc5982980, start=0, end=3217031168)
at ../../vm/vm_map.c:1830
#14 0xc0211a06 in vm_map_remove (map=0xc5982980, start=0, end=3217031168)
at ../../vm/vm_map.c:1855
#15 0xc0136908 in exit1 (p=0xc597d860, rv=0) at ../../kern/kern_exit.c:216
#16 0xc01366e8 in exit1 (p=0xc597d860, rv=-979883648)
at ../../kern/kern_exit.c:103
#17 0xc0262f22 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = 0, tf_esi = -1, tf_ebp = -1077937864, tf_isp = -974360620, 
  tf_ebx = 405762436, tf_edx = 405819424, tf_ecx = 10, tf_eax = 1, 
  tf_trapno = 12, tf_err = 2, tf_eip = 405482552, tf_cs = 31, 
  tf_eflags = 647, tf_esp = -1077937908, tf_ss = 47})
at ../../i386/i386/trap.c:1073


Machine was under heavy NFS  disk load. Have also noticed odd problems,
such as X refusing to allow connections and then crashing.


Stephen
(who has been away for 2months and just came back to a bad spot. Sigh)


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

Re: patches for test / review

[Matthew Dillon]

: Hm. But I'd think that even with modern drives a smaller number of bigger
: I/Os is preferable over lots of very small I/Os.
:
:Not necessarily. It depends upon overhead costs per-i/o. With larger I/Os, you
:do pay in interference costs (you can't transfer data for request N because
:the 256Kbytes of request M is still in the pipe).

This problem has scaled over the last few years.  With 5 MB/sec SCSI
busses it was a problem.  With 40, 80, and 160 MB/sec it isn't as big
an issue any more.

256K @ 40 MBytes/sec = 6.25 mS.
256K @ 80 MBytes/sec = 3.125 mS.

When you add in write-decoupling (take softupdates, for example), the
issue become even less of a problem.

The biggest single item that does not scale well is command/response 
overhead.  I think it has been successfully argued (but I forgot who
made the point) that 64K is not quite into the sweet spot - that 256K
is closer to the mark.  But one has to be careful to only issue large
requests for things that are actually going to be used.  If you read
256K but only use 8K of it, you just wasted a whole lot of cpu and bus
bandwidth.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: patches for test / review

[Matthew Dillon]

: 
: I would think that track-caches and intelligent drives would gain
: much if not more of what clustering was designed to do gain.
:
:Hm. But I'd think that even with modern drives a smaller number of bigger
:I/Os is preferable over lots of very small I/Os. Or have I missed the point?
:
:-- 
:Wilko BulteArnhem, The Netherlands   
:http://www.tcja.nl The FreeBSD Project: http://www.freebsd.org

As long as you do not blow away the drive's cache with your big I/O's,
and as long as you actually use all the returned data, it's definitely 
more efficient to issue larger I/O's.

If you generate requests that are too large - say over 1/4 the size of
the drive's cache, the drive will not be able to optimize parallel 
requests as well.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: 'machine/param.h' required for 'sys/socket.h'

[Bruce Evans]

On Wed, 22 Mar 2000, Yoshinobu Inoue wrote:

 I feel requesting inclusion of machine/param.h for any apps
 which use socket is better. But if there are any other smarter
 solution, please let me know and I'll appreciate it much.

machine/param.h should never be included by applications since
it is an implementation detail.

Specify including sys/param.h in apps which use the CMSG*() macros.
sys/socket.h doesn't depend on */param.h unless these macros are used.
Since these macros are undocumented, applications that use them should
expect problems :-).

Bruce



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

Re: 'machine/param.h' required for 'sys/socket.h'

[Yoshinobu Inoue]

  I feel requesting inclusion of machine/param.h for any apps
  which use socket is better. But if there are any other smarter
  solution, please let me know and I'll appreciate it much.
 
 machine/param.h should never be included by applications since
 it is an implementation detail.
 
 Specify including sys/param.h in apps which use the CMSG*() macros.
 sys/socket.h doesn't depend on */param.h unless these macros are used.
 Since these macros are undocumented, applications that use them should
 expect problems :-).
 
 Bruce

After reading bmah's message, now I am inclined to including
machine/param.h from sys/socket.h for maximum portability, if
there is no spec for it, and if all other platforms doing it.

Of course, I think enough testing for it is necessary.  I can
test make world for it. And if it is OK, then I think it
should be once just committed and checked if any other ports
build problem happens for it, or any other person claim
another problem.

Any more comments for this approach?

Yoshinobu Inoue


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

Re: can't dump vinum volumes after upgrading

[Greg Lehey]

On Tuesday, 21 March 2000 at 14:48:55 +0100, Palle Girgensohn wrote:
 Hi!

 I'm having a strange problem after upgrading: There are no raw
 devices created for vinum volumes.

Indeed there are.  You list them below.  There are no longer any block
devices.

 This makes dump(8) puke.

 This is a 3.4 system:

 ls -laF /dev/vinum
 ...
 crwxr-xr--  1 root  wheel   91,   1  2 Jul  1999 rusr*
 drwxr-xr-x  2 root  wheel   512  2 Jul  1999 rvol/
 ...
 brwxr-xr--  1 root  wheel   25,   1  2 Jul  1999 usr*

This was a block device.

 drwxr-xr-x  4 root  wheel   512  2 Jul  1999 vol/
 ...

 and here's a 4.0:

 crw-r-   1 root  wheel   91,   0 21 Mar 13:40 usr

This is now a character device.

 drwxr-xr-x  11 root  wheel   512 21 Mar 13:40 vol/

 vinum makedev doesn't help. what gives?

You don't describe what dump has to say.  I know that they put in a
fix recently, but you don't say how old your system is.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
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: can't dump vinum volumes after upgrading

[Palle Girgensohn]

Hello again.

I did some rtfm and src digging, it appears the listing I gave is
correct; the raw devices are in the rvinum dircetory. Problem is,
dump looks in vinum/r*. There seems that vinum introduces a bug
here, since dump's rawname function replaces the last '/' in the
device name with '/r'. In my 3.4 systems I have both rvinum and
vinum/r* in my /dev directory.

One solution is for vinum to create symlinks /dev/vinum/rplex -
/dev/rvinum/plex, to help dump find the raw device from the fstab
entry. That's what I'm doing manually now to get my filesystems
dumped. This should probably be handled by vinum somehow?

/Palle


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

Re: can't dump vinum volumes after upgrading

[Palle Girgensohn]

This fixes it for me. Is my installation faulty, or is this
something that vinum fails to do when creating its devices?

#! /bin/sh
cd /dev/vinum
for i in ../rvinum/*; do ln -s $i r`basename $i`; done


/Palle


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

Re: patches for test / review

[Wilko Bulte]

On Mon, Mar 20, 2000 at 11:54:58PM -0800, Matthew Jacob wrote:
  
  Hm. But I'd think that even with modern drives a smaller number of bigger
  I/Os is preferable over lots of very small I/Os.
 
 Not necessarily. It depends upon overhead costs per-i/o. With larger I/Os, you
 do pay in interference costs (you can't transfer data for request N because
 the 256Kbytes of request M is still in the pipe).

OK. 256K might be a bit on the high side. 

-- 
Wilko Bulte Arnhem, The Netherlands   
http://www.tcja.nl  The FreeBSD Project: http://www.freebsd.org


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

Problems with vinum and/or rawio?

[Brad Knowles]

Greg,

Running 4.0-STABLE (cvsup'ed a couple of days ago), I'm having a 
problem with a vinum striped volume that I've set up.  The machine is 
a dual-CPU Pentium III/450 (Dell 1300) with 1GB of RAM and 512KB L2 
cache per processor, on an IBM DDRS-39130D DC2 8GB hard drive.

The external drive array is a Comparex D1400 (Hitachi DF400), 
with four separate logical units (one for each row of disks), and two 
logical units exported exclusively through one interface on one 
controller, which is attached exclusively to one Adaptec 2940U2W host 
adaptor.  The IBM drive with the OS, etc... is attached to the 
on-board Adaptec AIC-7980 controller chip.


The command I had run was:

rawio -c 128 -p 16 -n 65536 -r -R  /dev/vinum/news

I got part way through the output being generated, when I started 
getting a lot of errors like this:

Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): BDR message in message buffer
Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): BDR message in message buffer
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): no longer in 
timeout, status = 34b
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): no longer in 
timeout, status = 34b
Mar 21 20:48:48 audrey /kernel: ahc1: Issued Channel A Bus Reset. 11 
SCBs aborted
Mar 21 20:48:48 audrey /kernel: ahc1: Issued Channel A Bus Reset. 11 
SCBs aborted

Once this happened, all of the rawio processes were in "physst", 
but the system had 100% idle time.


Do you need to see my kernel configuration?  Beyond the vinum 
configuration and the output of dmesg, is there any other 
configuration details you need?


Thanks!




My /etc/vinum.conf:

drive d1 device /dev/da2s1e
drive d2 device /dev/da3s1e
drive d3 device /dev/da4s1e
drive d4 device /dev/da5s1e
volume news
plex org striped 512k
sd length 0 drive d1
sd length 0 drive d2
sd length 0 drive d3
sd length 0 drive d4

dmesg:

$ dmesg
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-STABLE #0: Mon Mar 20 21:06:56 CET 2000
 [EMAIL PROTECTED]:/usr/src/sys/compile/AUDREY
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon (448.62-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x673  Stepping = 3
 
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG 
E,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM
real memory  = 1073741824 (1048576K bytes)
config di sn0
No such device: sn0
Invalid command or syntax.  Type `?' for help.
config di lnc0
No such device: lnc0
Invalid command or syntax.  Type `?' for help.
config di le0
No such device: le0
Invalid command or syntax.  Type `?' for help.
config di ie0
No such device: ie0
Invalid command or syntax.  Type `?' for help.
config di fe0
No such device: fe0
Invalid command or syntax.  Type `?' for help.
config di ed0
No such device: ed0
Invalid command or syntax.  Type `?' for help.
config di cs0
No such device: cs0
Invalid command or syntax.  Type `?' for help.
config q
avail memory = 1038483456 (1014144K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor motherboard
  cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee0
  cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee0
  io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc0399000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc039909c.
ccd0-3: Concatenated disk drivers
Pentium Pro MTRR support enabled
md1: Malloc disk
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: ATI Mach64-GW graphics accelerator at 0.0
pcib2: DEC 21152 PCI-PCI bridge at device 2.0 on pci0
pci2: PCI bus on pcib2
ahc0: Adaptec 2940 Ultra2 SCSI adapter port 0xdc00-0xdcff mem 
0xf9fff000-0xf9ff irq 21 at device 9.0 on pci2
ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc1: Adaptec 2940 Ultra2 SCSI adapter port 0xd800-0xd8ff mem 
0xf9ffe000-0xf9ffefff irq 22 at device 10.0 on pci2
ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc2: Adaptec aic7890/91 Ultra2 SCSI 

Re: /boot/loader is making my VAIO reboot

[Guido van Rooij]

On Tue, Mar 21, 2000 at 05:19:55PM +0100, Ollivier Robert wrote:
 Since after the Feb. 25th, /boot/loader is rebooting the machine during
 boot. I can't get to the prompt at all. The only version that works is the
 25th one (I didn't upgrade between the Feb. 25th and March, 17th).
 
 Nothing in the BIOS configuration changed during that period...
 
 -r-xr-xr-x  1 root  wheel  143360 Mar 21 16:39 loader   REBOOTS
 -r-xr-xr-x  2 root  wheel  143360 Feb 25 20:03 loader.old   WORKS
 
 This is on my VAIO laptop (Z505SX, PII/366, 128 MB).
 
 Any idea ?

Strange. I have just done a make install with the new loader and it works
for me:
-r-xr-xr-x  1 root  wheel  143360 Mar 21 19:50 loader 

made with todays cvsup. Perhaps you have some non default config files in
there?

-Guido


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

Re: patches for test / review

[Wilko Bulte]

On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
 : 
 : I would think that track-caches and intelligent drives would gain
 : much if not more of what clustering was designed to do gain.
 :
 :Hm. But I'd think that even with modern drives a smaller number of bigger
 :I/Os is preferable over lots of very small I/Os. Or have I missed the point?

 As long as you do not blow away the drive's cache with your big I/O's,
 and as long as you actually use all the returned data, it's definitely 
 more efficient to issue larger I/O's.

Prefetching data that is never used is obviously a waste. 256K might be a
bit big, I was thinking of something like 64-128Kb 

Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 

I happen to hate write-caching on disk drives so I did not consider that as
a factor.

 If you generate requests that are too large - say over 1/4 the size of
 the drive's cache, the drive will not be able to optimize parallel 
 requests as well.

True.

-- 
Wilko Bulte Arnhem, The Netherlands   
http://www.tcja.nl  The FreeBSD Project: http://www.freebsd.org


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

Re: SCSI errors from xmcd

[Kenneth D. Merry]

On Tue, Mar 21, 2000 at 20:15:29 +, Mark Ovens wrote:
 Since u/g to 4.0 I've had problems with audio CD players and my
 Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
 the cd devices has got cdcontrol working but still xmcd (v2.6)
 doesn't. It all worked fine under 3.4-STABLE
 
 Starting it with ``-debug'' yields a constant (one every few seconds)
 stream  of:
 
 SCSI CDB bytes (dev=/dev/rcd0c rw=0 to=20):
 00 00 00 00 00 00 -- --  -- -- -- -- -- -- -- --
 CD audio: SCSI command fault on /dev/rcd0c:
 Status=0x16
 
 Is this because xmcd needs updating to work with the new CAM system,
 or something else?

You need to recompile xmcd.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]


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

Re: SCSI errors from xmcd

[Kenneth D. Merry]

On Tue, Mar 21, 2000 at 20:57:17 +, Mark Ovens wrote:
 On Tue, Mar 21, 2000 at 01:50:46PM -0700, Kenneth D. Merry wrote:
  On Tue, Mar 21, 2000 at 20:15:29 +, Mark Ovens wrote:
   Is this because xmcd needs updating to work with the new CAM system,
   or something else?
  
  You need to recompile xmcd.
  
 
 In that case I need to wait for the package to be updated. xmcd needs
 Motif, which I don't have, so I use the binary package.

There's an xmcd package for 4.0 here:

ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/i386/packages-4.0-release/audio/xmcd-2.6.tgz

What package are you waiting for?

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]


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

Supported CardBus controllers?

[m . papezik]

 Hi all,

I saw a few messages about missing CardBus support in current
and I am wondering what is current status?

If someone is activelly working on this
I can try to test things on ThinkPad 600E
(with TI 1251 controller and SMC/Megahertz NIC).

Pehaps the list of PCcard and CardBus controllers used
in ThinkPad systems will help too:

http://www.pc.ibm.com/qtechinfo/YAST-3JZU4X.html?selectarea=SUPPORTbrand=rootx=0y=4

Thanks in advance,
Milon
--
[EMAIL PROTECTED]





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

Re: patches for test / review

[Rodney W. Grimes]

 On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
  : 
  : I would think that track-caches and intelligent drives would gain
  : much if not more of what clustering was designed to do gain.
  :
  :Hm. But I'd think that even with modern drives a smaller number of bigger
  :I/Os is preferable over lots of very small I/Os. Or have I missed the point?
 
  As long as you do not blow away the drive's cache with your big I/O's,
  and as long as you actually use all the returned data, it's definitely 
  more efficient to issue larger I/O's.
 
 Prefetching data that is never used is obviously a waste. 256K might be a
 bit big, I was thinking of something like 64-128Kb 
 
 Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 

Your a bit behind the times with that set of numbers for modern SCSI
drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
most common.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: /boot/loader is making my VAIO reboot

[Daniel C. Sobral]

Ollivier Robert wrote:
 
 Since after the Feb. 25th, /boot/loader is rebooting the machine during
 boot. I can't get to the prompt at all. The only version that works is the
 25th one (I didn't upgrade between the Feb. 25th and March, 17th).
 
 Nothing in the BIOS configuration changed during that period...
 
 -r-xr-xr-x  1 root  wheel  143360 Mar 21 16:39 loader   REBOOTS
 -r-xr-xr-x  2 root  wheel  143360 Feb 25 20:03 loader.old   WORKS
 
 This is on my VAIO laptop (Z505SX, PII/366, 128 MB).

This is not enough information. You might want to reverse src/sys/boot
to RELENG_4_BP, and test that version, though.

--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone bind them.


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

Re: problem with reboot on 5.0-current with VAIO

[Nate Williams]

 When I use reboot(8) to reboot my Vaio z505sx, it waits nicely for
 the bufdaeon and the syncer to stop. Then the screen goes blank
 and the system completely hangs. Unplugging the battery and power
 is the only way to gte it booting again. It used to work fine with a 
 4.0-current of some 3 weeks ago but a 5.0-current from today gives the above
 result. 
 Does anyone have a clue?

Is this use VM86?  The Thinkpads have this problem when the amount of
memory that FreeBSD expects is larger than what actually exists, due to
memory sizing issues.  VM86 is supposed to fix this, although I've not
run 5.0 to check it...




Nate


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

Re: Mylex Support

[Mike Smith]

 Are there any particular preparation processes one should go through
 when setting up a Mylex DAC960 RAID array ?
 (if so give me a pointer to the docs)

Documentation typically ships with the adapter.

 Can I just purchase all the hardware, plug in the disks and boot the
 FreeBSD-4 install floppies ?  (for a system to be booting from the
 array with no internal ATA devices)

You'll need to configure the array first.

 or Should I have an internal ATA hard disk with some evil OS on it
 such as Lose 9X or NT so as to run any kind of Mylex DOS/Windows
 preparation utilities ?

Only for the very old adapters.

-- 
\\ 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-current" in the body of the message

Re: AMI MegaRAID lockup? not accepting commands.

[Mike Smith]

 At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
 
   Not that I consider this particuarly optimal; busy-waiting for the
   controller is a terrible waste of the host CPU.  A better solution would
   probably defer the command and try again a short time later, but let's
   see if this works first.
 
   Since this is a device driver, I guess you can't usleep() and 
 then check again?  Is there anything else useful you could be doing 
 during that period of time -- other than busy waiting?

Well, I call amr_done() to collect completed commands.  There's not much 
other housekeeping that's possible at that point.

-- 
\\ 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-current" in the body of the message

Re: SCSI errors from xmcd

[Mark Ovens]

On Tue, Mar 21, 2000 at 02:02:57PM -0700, Kenneth D. Merry wrote:
 On Tue, Mar 21, 2000 at 20:57:17 +, Mark Ovens wrote:
  On Tue, Mar 21, 2000 at 01:50:46PM -0700, Kenneth D. Merry wrote:
   On Tue, Mar 21, 2000 at 20:15:29 +, Mark Ovens wrote:
Is this because xmcd needs updating to work with the new CAM system,
or something else?
   
   You need to recompile xmcd.
   
  
  In that case I need to wait for the package to be updated. xmcd needs
  Motif, which I don't have, so I use the binary package.
 
 There's an xmcd package for 4.0 here:
 
 ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/i386/packages-4.0-release/audio/xmcd-2.6.tgz
 
 What package are you waiting for?
 

This one I guess :). Just d/l it and installed it; works a treat.
Thanks.

FWIW, I got the original from
ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/packages/audio/



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

-- 
Seminars, n.:
   From "semi" and "arse", hence, any half-assed discussion.

  FreeBSD - The Power To Serve http://www.freebsd.org
  My Webpage http://ukug.uk.freebsd.org/~mark/
mailto:[EMAIL PROTECTED] http://www.radan.com



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

Re: SCSI errors from xmcd

[Daniel Eischen]

On Tue, 21 Mar 2000, Kenneth D. Merry wrote:
 On Tue, Mar 21, 2000 at 20:15:29 +, Mark Ovens wrote:
  Since u/g to 4.0 I've had problems with audio CD players and my
  Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
  the cd devices has got cdcontrol working but still xmcd (v2.6)
  doesn't. It all worked fine under 3.4-STABLE
  
  Starting it with ``-debug'' yields a constant (one every few seconds)
  stream  of:
  
  SCSI CDB bytes (dev=/dev/rcd0c rw=0 to=20):
  00 00 00 00 00 00 -- --  -- -- -- -- -- -- -- --
  CD audio: SCSI command fault on /dev/rcd0c:
  Status=0x16
  
  Is this because xmcd needs updating to work with the new CAM system,
  or something else?
 
 You need to recompile xmcd.

Also be sure you have an imake that doesn't use cpp:

  strings /usr/X11R6/bin/imake | grep cpp
  /usr/libexec/cpp

That would be wrong, and if you rebuilt xmcd with that imake
it wouldn't work.  To get xmcd to build correctly, set
IMAKECPP=/usr/bin/cpp in your environment before building
xmcd.

Dan Eischen
[EMAIL PROTECTED]



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

Re: patches for test / review

[Wilko Bulte]

On Tue, Mar 21, 2000 at 01:14:45PM -0800, Rodney W. Grimes wrote:
  On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
   : 
   : I would think that track-caches and intelligent drives would gain
   : much if not more of what clustering was designed to do gain.
   :
   :Hm. But I'd think that even with modern drives a smaller number of bigger
   :I/Os is preferable over lots of very small I/Os. Or have I missed the point?
  
   As long as you do not blow away the drive's cache with your big I/O's,
   and as long as you actually use all the returned data, it's definitely 
   more efficient to issue larger I/O's.
  
  Prefetching data that is never used is obviously a waste. 256K might be a
  bit big, I was thinking of something like 64-128Kb 
  
  Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 
 
 Your a bit behind the times with that set of numbers for modern SCSI
 drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
 most common.

Your drives are more modern than mine ;-) What drive has 16 Mb? Curious
here..

-- 
Wilko Bulte Arnhem, The Netherlands   
http://www.tcja.nl  The FreeBSD Project: http://www.freebsd.org


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

Re: AMI MegaRAID lockup? not accepting commands.

[Matthew Dillon]

: For situations that aren't in the critical path and don't happen often,
: it may be beneficial to do a voluntary context switch inside the loop.
:
:Is it possible/legal to do this inside a strategy() routine?

Yes, though it isn't playing nice if the caller was trying to issue
an asynchronous I/O.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

pstat -s error message

[Bill Pechter]

I've done two make worlds and can't seem to get rid of the following
error... I had it on my home system, but didn't log what I did to 
correct it...

I just upgraded a 4.0-CURRENT (from around Jan 26) to the 4.0-STABLE
from yesterday.

when running pstat -s I get the following:
pstat: undefined symbol: _numvnodes

I rebuilt world and the kernel twice... I must be missing something.

Bill
+---+
| Bill Pechter | Lucent Technologies | Voice 732-949-1417 | Fax 732-949-5477|
| 101 Crawfords Corner Road, Holmdel, NJ 07733  | [EMAIL PROTECTED]|
| This message brought to you by the letters PDP and the numbers 11 and 45  |
+---+


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

emu10k1 driver

[Thomas T. Veldhouse]

I just tried it against 4.0-STABLE (03222000).  The patch
(http://www.freebsd.org/~cg/current.diff.gz) applied 100% successfully
(I assume sound has not yet diverged much in 5.0 except for Voxware).  I
don't get any sound when using KMP3.  I just get a pulse sound  in the
speaker when the app starts though and then a pulse again when I shut
the app down.

Here is the relavent dmesg output:

pcm0: Creative EMU10K1 port 0x1400-0x141f irq 11 at device 3.0 on pci0

pcm0: ac97 codec reports dac not ready

Is there something that needs to enable the PCI card properly?  I do not
have the option to shut Plug-N-Play off on my system (nice Compaq-ism).

It looks like it is very close.

Thanks in advance,

Tom Veldhouse
[EMAIL PROTECTED]


 Subject:  Re: emu10k1 (SB Live!) support under FreeBSD?
 From: Dan Moschuk
 Date: 2000/03/20
 Message-ID:   [EMAIL PROTECTED]
 Newsgroups:   sol.lists.freebsd.current
 [More Headers]

 | | I would love to help out, but I don't know where to start, and I have no
 | | kernel programming experience.  There are reference drivers available for
 | | linux via http://opensource.creative.com or http://www.alsa-project.org
 | | (my preference).
 |
 | One is on the way...

 Cam's boredom out-weighed my initiative. 8)

 http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1
 driver (minus recording) which is need of debugging.  Give it a try!




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

Re: patches for test / review

[Rodney W. Grimes]

 On Tue, Mar 21, 2000 at 01:14:45PM -0800, Rodney W. Grimes wrote:
   On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
: 
: I would think that track-caches and intelligent drives would gain
: much if not more of what clustering was designed to do gain.
:
:Hm. But I'd think that even with modern drives a smaller number of bigger
:I/Os is preferable over lots of very small I/Os. Or have I missed the point?
   
As long as you do not blow away the drive's cache with your big I/O's,
and as long as you actually use all the returned data, it's definitely 
more efficient to issue larger I/O's.
   
   Prefetching data that is never used is obviously a waste. 256K might be a
   bit big, I was thinking of something like 64-128Kb 
   
   Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 
  
  Your a bit behind the times with that set of numbers for modern SCSI
  drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
  most common.
 
 Your drives are more modern than mine ;-) What drive has 16 Mb? Curious
 here..

Seagates latest and greatest drives have a 4MB cache standard and an option
for 16MB.  These are 10K RPM chetta drives.  


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: Reading from bad disk ?

[Warner Losh]

: A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
: to become very hot compared to other disks when mounted in the
: same machine (on a removable frame). Do others have the same
: experience ?

Yes.  They run very hot.  I had to steal an old powersupply fan and
mount it in front of the drive to get it to run at  a reasonable
temperature.  W/o the fan, it was running at 58C or so.  With the fan
it runs at 39C or so.  I've included the script that I use to find
this information out.  Ken Merry sent it to me.  It works on some IBM
drives.

Warner

#!/bin/sh

TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`

TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc`

echo "The temperature is: $TEMPF F $TEMPC C"


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

Re: -current sudden panics :(

[Warner Losh]

In message [EMAIL PROTECTED] Nikolai Saoukh writes:
:  But shouldn't it be sys/pci/if_rl.c ?
: 
: Sorry,
: it is mea culpa. I mixed his case with my (token ring).

Do you have the patch to if_rl.c.  I looked at it for all of 10
seconds and it wasn't immediately obvious to me.

Warner


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

FreeBSD random I/O performance issues

[Richard Wendland]

Paul Richards said in "Re: patches for test / review":

 Richard, do you want to post a summary of your tests?

Well I'd best post the working draft of my report on the issues
I've seen, as I'm not going to have time to work on it in the near
future, and it raises serious performance issues that are best
looked at soon.  Note none of these detailed results are from
current, but Paul Richards has checked that these issues are still
present in current.

There are still issues to be explored so this report isn't in a
complete state, and not polished.  It's grown in 3 stages:

- initial Berkeley DB (random I/O) performance problem analysis
- side-issue of ATA outperforming SCSI systems at my synthetic benchmark
- interesting dramatic performance changes from changing seek multiple
  and I/O block size one byte from 8192

Note I've cc'd freebsd-fs, as this raises issues in the filesystem
area.  I've also changed the subject since I think there are broader
issues here than the clustering algorithm, and this email is rather
large to drop into an ongoing discussion.

The benchmark program source code is available, and easy to run,
the bottom of the report has links.

I don't have an explanation for the behaviour I have been measuring,
but I hope these quite extensive results will enable someone to
explain and perhaps suggest improvements.

Richard.


Folks,

I appear to have found a serious performance problem with random
access file I/O in FreeBSD, and have a simple C benchmark program
which reproducibly demonstrates it.  In that the benchmark demonstrates
very poor non-async performance, this touches on the age-old
sync/async filesystem argument, and FreeBSD vs Linux debates.

I originally observed this problem with perl DB_File (Berkeley DB),
and with the help of truss have synthesised this benchmark as a
much simplified model of heavy Berkeley DB update behaviour.  Quite
probably other database-like software will have similar performance
issues.

This issue appears to be related to the traditional BSD behaviour
of immediately scheduling full disc block writes.  I think this
benchmark must be showing up a related bug.  But it is conceivable
that this is intended noasync behaviour, in which case the implications
need to be thought through.

The program does simple random I/O within a 64KB file, which should
I hope be fully cached so hardly any real I/O would be done.  Other
than mtime, this program makes no file meta-data or directory
changes; and the file remains the same size.

The file is used as 8 8KB blocks, and for each block in the order
0,5,2,7,4,1,6,3,0,... 10,000 lseek/read/lseek/write block updates
are done, much like updating 10,000 non-localised Berkeley DB file
records.

Using a tiny 64KB file is just to simplify and make a point.  My
original perl performance problems were with multi-megabyte files,
but still small enough to be fully cached.

I ran this on a large range of lightly loaded or idle machines,
which gave reproducible results.  Results and a summary of the
machines, which unless otherwise noted use SCSI 7200 RPM discs and
Adaptec controllers, are given in descending performance order
below.


  OSElapse secs, system

  FreeBSD 3.2-RELEASE, async mount  1  (cheap ATA C433, 5400 RPM)
  Linux 2.2.13  1  (Dell 1300, PIII 450MHz)
  Linux 2.0.36  3   (old ATA P200, 5400 RPM)
  Linux 2.0.36, sync [meta-data] mount  3   (old ATA P200, 5400 RPM)
  SunOS 5.5.1 (Solaris 2.5.1)   7   (old SS4/110, 5400 RPM)
  FreeBSD 2.2.7-RELEASE+CAM, ccd stripe=5   15  (PII 450MHz, 512MB, 10k RPM)
  FreeBSD 2.2.7-RELEASE+CAM 21  (PII 400MHz, 512MB)
  FreeBSD 2.1.6.1-RELEASE   32  (old P100, 64MB)
  FreeBSD 2.2.7-RELEASE+CAM, ccd stripe=2   39  (PII 400MHz, 512MB)
  FreeBSD 3.4-STABLE, vinum stripe+mirr=4   41  (dual PIII 500MHz, 1GB)
  FreeBSD 3.4-STABLE41  (dual PIII 500MHz, 1GB)
  FreeBSD 2.1.6.1-RELEASE, ccd stripe=2 52  (old P100, 64MB)
  FreeBSD 3.3-RELEASE, ccd stripe=2 53  (Dell 1300, PIII 450MHz)
  FreeBSD 3.2-RELEASE   55  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.2-RELEASE, noatime mount55  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.2-RELEASE, noclusterr mount 55  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.2-RELEASE, noclusterw mount 58  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.3-RELEASE   63  (Dell 1300, PIII 450MHz)
  FreeBSD 3.3-RELEASE, softupdates  63  (Dell 1300, PIII 450MHz)
  FreeBSD 3.2-RELEASE, sync mount   105 (cheap ATA C433, 5400 RPM)


I also have a range of results from an ATA (IDE) cheap deskside
Dell system running FreeBSD 3.3-RELEASE, with a range of wd(4)
flags.  This system exhibits much better performance than the SCSI
systems above at this 

Re: 4.0-RELEASE boot.flp fails to boot on K6/2

[Doug White]

On Tue, 21 Mar 2000, Thierry.herbelot wrote:

 I had the exact same error message trying to boot from a floppy where I
 had tried to dd the full boot.flp (2,8 Megs is just too much for a
 normal floppy), instead of kern.flp (and dd does not give error messages
 ..)

I would be in favor of renaming the boot.flp to something obviously
different, like 288boot.flp, to untrain us 2.x heads that got used to the
single-floppy installer of yore. :)  I still reach for 'boot.flp' and have
to kick myself to grab kern/mfsroot instead.

Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED] |  www.FreeBSD.org



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

Re: FreeBSD random I/O performance issues

[Matthew Dillon]

:Paul Richards said in "Re: patches for test / review":
:
: Richard, do you want to post a summary of your tests?
:
:Well I'd best post the working draft of my report on the issues
:I've seen, as I'm not going to have time to work on it in the near
:future, and it raises serious performance issues that are best
:looked at soon.  Note none of these detailed results are from
:current, but Paul Richards has checked that these issues are still
:present in current.
:
: (lots of good stuff)

Interesting.  The behavior is probably related closely to the
write-behind methodology that UFS uses.

A while back while fixing an O(N^2) degenerate condition in the buffer
cache queueing code, DG and I had a long discussion of the write_behind
behavior.  I added a sysctl to 4.x that changes the write_behind
behavior:

sysctl vfs.write_behind

0   Turned off
1   Normal  (default)
2   Backed off

It would be interesting to see how the benchmark performs with 
write_behind turned off (set to 0).  Note that a setting of 2
is highly experimental and will probably suffer from the same problem(s)
that normal mode suffers from.  (see below, I ran the benchmark)

In general turning off write behind is *NOT* a good idea, because
it saturates the buffer cache with dirty blocks and can lead to seriously
degraded performance on a normal system due to write hogging.   On the
flip side, this was all before I put in the new buffer cache flushing code
so it is possible that 4.x will not degrade as seriously with write
behind turned off.  I haven't run saturation tests recently with 
write_behind turned off.

A secondary issue -- actually the reason *why* performance is so bad, is
that the buffer cache nominally locks the underlying VM pages when issuing
a write and this is almost certainly the cause of the program stalls.
When a program writes a piece of data (and I/O is started immediately),
and then reads it back later on, the read operation may stall even though
the data is in the cache due to the write not having yet completed.  The
write operation might also stall if another nearby write is in progress
(I'm not sure on that last point).

Kirk has made significant improvements to stalls related to bitmap 
operations.  I'm not sure if softupdates must be turned on or not to
get these improvements.  The data blocks can still stall, though, but 
part of the plan for later this year is to fix that too.

:The benchmark program source code is available, and easy to run,
:the bottom of the report has links.

test3:/test/tmp# sysctl -w vfs.write_behind=0   (turned off)
test3:/test/tmp# time ./seekreadwrite xxx 1
0.125u 0.807s 0:00.93 98.9% 5+181k 0+0io 0pf+0w

test3:/test/tmp# sysctl -w vfs.write_behind=1   (normal)
test3:/test/tmp# time ./seekreadwrite xxx 1
0.040u 1.709s 0:32.57 5.3%  4+174k 0+8750io 0pf+0w


:I also have a range of results from an ATA (IDE) cheap deskside
:Dell system running FreeBSD 3.3-RELEASE, with a range of wd(4)
:flags.  This system exhibits much better performance than the SCSI
:systems above at this benchmark, perhaps related to better DMA
:ability.
:
:ATA being faster than SCSI on this benchmark is a bit of a side-issue
:to the thrust of this report, but the performance numbers may give
:hints diagnosing the problem.

IDE drives sometimes appear to be faster because they fake the 
write-completion response (they return the response prior to the
write actually completing).  It could also simply be that the 
lack of any real mixed I/O (due to the file being so small) is
a slightly faster operation on an IDE drive.  I wouldn't read much
into it... where SCSI really shines is in more heavily loaded 
environments.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

:Thanks,
:   Richard
:-
:Richard Wendland   [EMAIL PROTECTED]



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

Re: Floating point exceptions.

[Matthew Hunt]

On Tue, Mar 21, 2000 at 10:28:43AM +0100, Martin Cracauer wrote:

 FreeBSD's fpsetmask(3) stuff is simple inline assembler that I
 personally used in Linux, it should be relativly easy to carry it
 around with your application on i386 machines.

fpsetmask(3) also exists on Solaris.

-- 
Matthew Hunt [EMAIL PROTECTED] * Stay close to the Vorlon.
http://www.pobox.com/~mph/   *


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

Re: Floating point exceptions.

[Garrett Wollman]

On Tue, 21 Mar 2000 17:11:30 -0800, Matthew Hunt [EMAIL PROTECTED] said:

 fpsetmask(3) also exists on Solaris.

fpsetmask(3) was copied from System V.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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

Re: can't dump vinum volumes after upgrading

[Palle Girgensohn]

Greg Lehey wrote:
 
 On Tuesday, 21 March 2000 at 14:48:55 +0100, Palle Girgensohn wrote:
  Hi!
 
  I'm having a strange problem after upgrading: There are no raw
  devices created for vinum volumes.
 
 Indeed there are.  You list them below.  There are no longer any block
 devices.
 
 
 This was a block device.
 
...
 
 This is now a character device.

OK. Of course. Cool!

 You don't describe what dump has to say.  I know that they put in a
 fix recently, but you don't say how old your system is.

The system is 4.0-STABLE, which is more or less 4.0-RELEASE right
now.

dump fails at the point were it is trying to convert the block
device listed in fstab to a raw device, by inserting a 'r' after
the last '/' in the pathname. This part of dump wasn't changed
since the initial import :)

in sbin/dump/main.c:546:

char *
rawname(cp)
char *cp;
{
static char rawbuf[MAXPATHLEN];
char *dp = strrchr(cp, '/');

if (dp == NULL)
return (NULL);
*dp = '\0';
(void)strncpy(rawbuf, cp, MAXPATHLEN - 1);
rawbuf[MAXPATHLEN-1] = '\0';
*dp = '/';
(void)strncat(rawbuf, "/r", MAXPATHLEN - 1 -
strlen(rawbuf));
(void)strncat(rawbuf, dp + 1, MAXPATHLEN - 1 -
strlen(rawbuf));
return (rawbuf);
}

So, here what dump says:
trumpet:vinum# dump 0af /dev/null /cluster1
  DUMP: Date of this level 0 dump: Wed Mar 22 02:10:20 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/vinum/rcluster1 (/cluster1) to /dev/null
  DUMP: Cannot open /dev/vinum/rcluster1

which is rather expected.

My fstab has the line:
/dev/vinum/cluster1  /cluster1  ufs  rw  2  2

Since you've enlighted me with the fact that there are only
character devices in vinum nowadays, my suggestion is putting a
symlink rfilesys-filesys in /dev/vinum for each filesystem, or
creating device nodes named rfilesys as well. This would make
dump(8) happy anyway.

Also, the manual pages (both vinum(4) vinum(8)) seem to be a bit
off here, since they mention both raw devices,
/dev/rvinum/rfilesys and /dev/vinum/rfilesys, none of which I
have (I do have /dev/rvinum/filesys, but they were probably made
under 3.4, right? Can I remove them?).

Oh, by the way, I love vinum. Thanks for all the hard work!

Cheers,
Palle


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

Re: Another current crash (cvs-cur.6183

[Peter Wemm]

Stephen Hocking-Senior Programmer PGS SPS Perth wrote:

This one you need to tell phk about: this is one of his sanity checks
that trapped and found an insane value. (and then crashed since you didn't
have DDB)

 #8  0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")
 at machine/cpufunc.h:64
 #9  0xc017385e in spec_strategy (ap=0xc5988df8)
 at ../../miscfs/specfs/spec_vnops.c:438
 #10 0xc0173325 in spec_vnoperate (ap=0xc5988df8)
 at ../../miscfs/specfs/spec_vnops.c:117
 #11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8)
 at ../../ufs/ufs/ufs_vnops.c:2301
 #12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923
 #13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
 count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923
 #14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
 c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133
 #15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0)
 at ../../vm/vm_pager.h:145
 #16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:33
8
 #17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914
 #18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350
 #19 0xc02565e0 in fork_trampoline ()


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: Mylex Support

[Mike Tancsa]

On 21 Mar 2000 06:37:33 -0500, in sentex.lists.freebsd.current you wrote:

or Should I have an internal ATA hard disk with some evil OS on it
such as Lose 9X or NT so as to run any kind of Mylex DOS/Windows
preparation utilities ?

With the old adaptors that do not have the RAID config built into the BIOS,
a DOS boot disk is enough.  Make a couple to gaurd against bad floppies and
you should be fine.

---Mike

Mike Tancsa  ([EMAIL PROTECTED])  
Sentex Communications Corp, 
Waterloo, Ontario, Canada
"Given enough time, 100 monkeys on 100 routers 
could setup a national IP network." (KDW2)


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

Re: FreeBSD random I/O performance issues

[Paul Richards]

Richard Wendland wrote:
 

I spent a bit of time analysing these results when I first saw them. I
don't think it has anything to do with the cache, it has to do with how
we write out blocks.

 One interesting observation is that for non sync, async or noclusterw
 mounts ~8750 I/O operations are done, which is 7/8ths of the 10,000
 writes.  If I change the program to use 16 blocks there are ~9375
 I/O operations which is 15/16ths of the 10,000 writes.  Guessing,
 this is as if writes are forced for all blocks but one.

This is due to a quirk of the clustering algorithm. See below or my
previous email.

 With async filesystem mounts very little I/O occurs, and with
 noclusterw there are ~10,000 operations matching the number of
 writes.
 
 With sync it's ~20,000 operations matching the total of reads 
 writes.  This demonstrates another aspect of the bug, sync behaviour
 should cause 10,000 operations; the reads aren't being cached.

This isn't quite true. It's 20,000 *write* operations. I put this down
to the mtime update for each write doubling the number of actual write
operations. No read operations take place, the data *does* come out of
the cache. There's nothing wrong with reading as far as I can tell.
  
 Another aspect of this issue is the effect of changing the seek
 blocksize, and write blocksize, by 1 byte each way from 8192, thus
 doing block unaligned I/O.  In some cases this changes the amount
 of I/O recorded by getrusage to zero, and drops elapse time from
 half a minute or so to less than 1 second.
 
 Thanks to Paul Richard for noticing this.  I've not spent much time
 researching this, so can only present my small set of measurements.
 To do these tests you have to recompile my test program each time eg
 
 gcc -O4 -DBLOCKSIZE=8191 -DWRITESIZE=8193 seekreadwrite.c

This is because of the fact that if the filesystem block is full it is
written immediately, or rather the clustering code is called
immediately. The rationale is that a full block isn't likely to be
written to again so it might as well be pushed out to disk. Richard's
program deliberately writes full blocks, which is apparently what db
does, so it always forces a write to take place. Given the behaviour of
db it might be more sensible to remove this feature and just mark full
blocks dirty the same as other blocks since it's likely that they will
be written to again shortly if the db record is written to frequently.

The clustering code has a bug in that an old cluster is not pushed out
if the block no is 0 because the code that would do so never gets
reached.

if (lbn == 0)
vp-v_lasta = vp-v_clen = vp-v_cstart = vp-v_lastw = 0;


if (vp-v_clen == 0 || lbn != vp-v_lastw + 1 ||
(bp-b_blkno != vp-v_lasta + btodb(lblocksize))) {
maxclen = vp-v_mount-mnt_iosize_max / lblocksize - 1;
if (vp-v_clen != 0) {
/*
 * Next block is not sequential.
 *
 * If we are not writing at end of file, the process
 * seeked to another point in the file since its last
 * write, or we have reached our maximum cluster size,
 * then push the previous cluster. Otherwise try
 * reallocating to make it sequential.
 */

 

In Richard's program the next block is never sequential so the previous
cluster is always pushed *except* that when the program seeks back to
block zero the
"if (vp-v_clen != 0)" fails and a new cluster is started without
pushing out the previously started one. That dirty block in the previous
cluster then hangs around until it is flushed as dirty blocks normally
would be.

It is the combination of this clustering behaviour and the fact that the
program always writes full blocks that causes the 8750 writes below.
Since the blocks are full file system blocks rather than mark them dirty
they are immediately passed to the clustering code, because they are
never in sequence the clustering code always starts a new cluster and
flushes the previous one except for 1 in every 8 blocks that doesn't
happen because when block 0 is written the previous cluster is not
pushed out but hangs around.  The end result is that 7/8 blocks get
written immediately which is 8750/1 writes.

When the write size drops below the filesystem block size then the
clustering code never gets called because the buffers are just marked
dirty and cached.

I think if we fixed the issue of writing out full blocks this behviour
would stop but I also think the clustering code could do with a fix. It
should at least check to see if there is a cluster being built when the
blockno is 0 and push it out. Possibly though it'd be better to not push
out clusters of only one block and just leave them in the cache.

 
 Sorry it's that crude.  These results are from a FreeBSD
 2.2.7-RELEASE+CAM, ccd stripe=2 (PII 400MHz, 512MB) system,
 though exactly the same pattern is apparent with 3.4-STABLE.
 "" indicate sub-second 

Re: Another current crash (cvs-cur.6183

[Paul Richards]

Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
 
 cvs-cur.6183 appeared to fix the crash I reported under disk activity  NFS
 but another one has reared its face, when using java with tya15 jit, running
 the Together java IDE.
 
 #0  boot (howto=256) at ../../kern/kern_shutdown.c:304
 #1  0xc013d7e5 in panic (fmt=0xc0273534 "from debugger")
 at ../../kern/kern_shutdown.c:554
 #2  0xc01265bd in db_panic (addr=-1071292639, have_addr=0, count=-1,
 modif=0xc5988c64 "") at ../../ddb/db_command.c:433
 #3  0xc012655d in db_command (last_cmdp=0xc02abc2c, cmd_table=0xc02aba8c,
 aux_cmd_tablep=0xc02e4578) at ../../ddb/db_command.c:333
 #4  0xc0126622 in db_command_loop () at ../../ddb/db_command.c:455
 #5  0xc0128733 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
 #6  0xc0255cc1 in kdb_trap (type=3, code=0, regs=0xc5988d6c)
 at ../../i386/i386/db_interface.c:158
 #7  0xc0262690 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
   tf_esi = -979913536, tf_ebp = -979857996, tf_isp = -979858024,
   tf_ebx = -1044942540, tf_edx = 0, tf_ecx = -1070604512, tf_eax = 26,
   tf_trapno = 3, tf_err = 0, tf_eip = -1071292639, tf_cs = 8,
   tf_eflags = 12870, tf_esp = -1070994081, tf_ss = -1071140376})
 at ../../i386/i386/trap.c:549
 #8  0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")


I've got a different but I think related panic.

#9  0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
busy!!!")
at ../../kern/kern_shutdown.c:552
#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
at ../../vm/vm_page.h:346
#11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
#12 0xc0126b8d in dadone (periph=0xc092e380, done_ccb=0xc093f400)
at ../../cam/scsi/scsi_da.c:1230
#13 0xc0122acb in camisr (queue=0xc029def0) at ../../cam/cam_xpt.c:6298
#14 0xc01228dd in swi_cambio () at ../../cam/cam_xpt.c:6201
#15 0xc021188b in doreti_swi ()

A few more details

#11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
2706(*b_iodone) (bp);

#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
at ../../vm/vm_page.h:346
346 KASSERT(m-flags  PG_BUSY, ("vm_page_wakeup: page not busy!!!"));


I've got the dump if you want more diagnostics. It's hitting the KASSERT
on the second of 16 pages in the buf but none of them have PG_BUSY set
and it's only not panicing on the first page because
bp-b_pager.pg_reqpage is 0 and the call to vm_page_wakeup is skipped.



Paul.


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

Re: 'machine/param.h' required for 'sys/socket.h'

[nnd]

In [EMAIL PROTECTED] Bruce A. Mah [EMAIL PROTECTED] 
wrote:
 --==_Exmh_789141986P
 Content-Type: text/plain; charset=us-ascii
 
 If memory serves me right, Yoshinobu Inoue wrote:
   I feel requesting inclusion of machine/param.h for any apps
   which use socket is better. But if there are any other smarter
   solution, please let me know and I'll appreciate it much.
  
  machine/param.h should never be included by applications since
  it is an implementation detail.
  
  Specify including sys/param.h in apps which use the CMSG*() macros.
  sys/socket.h doesn't depend on */param.h unless these macros are used.
  Since these macros are undocumented, applications that use them should
  expect problems :-).
  
  Bruce
 
 After reading bmah's message, now I am inclined to including
 machine/param.h from sys/socket.h for maximum portability, if
 there is no spec for it, and if all other platforms doing it.
 
 Arrgh.  Now it seems I might need to reverse my position.  I looked
 through some code fragments in UNIX Network Programming (Volume 1,
 Second Edition, pp. 362-365), and there's some precedent for needing
 sys/param.h with the CMSG*() macros.
 
 On the other hand, RFC 2292 and draft-ietf-ipngwg-rfc2292bis (the
 references I was originally working from) don't mention this requirement
 at all; they just say that CMSG*() are defined with sys/socket.h.  I'm
 slightly confused by now.
 
 I'm going to send off a note to the authors of 
 draft-ietf-ipngwg-rfc229bis asking for some clarification.  In the 
 meantime, maybe we should hold off on doing any changes.

Can we (temporary) unbroke 'net/pchar' port in FreeBSD
with the next patch (until the Perfect Solution will be found :-) :

===
diff -ruN pchar.orig/patches/patch-aa pchar/patches/patch-aa
--- pchar.orig/patches/patch-aa Thu Jan  1 07:00:00 1970
+++ pchar/patches/patch-aa  Wed Mar 22 09:36:04 2000
@@ -0,0 +1,10 @@
+--- PctestIpv6Udp.h.ORIG   Wed Jan 19 23:14:42 2000
 PctestIpv6Udp.hWed Mar 22 09:31:19 2000
+@@ -29,6 +29,7 @@
+ #endif /* STDC_HEADERS */
+ 
+ #include sys/types.h
++#include sys/param.h
+ #include sys/socket.h
+ #include netinet/in.h
+ 


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

Re: suggestion: a g77 - f77 link

[David O'Brien]

On Mon, Mar 20, 2000 at 06:44:04PM +0100, Jose M. Alcaide wrote:
  What part about "NO" was unclear?
 
 Hey, OK, don't get upset! :-) You are the maintainer, so you have the

Not upset.  I was just surprised by the request again.

-- 
-- David([EMAIL PROTECTED])


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

Re: SCSI errors from xmcd

[Mark Ovens]

On Tue, Mar 21, 2000 at 01:50:46PM -0700, Kenneth D. Merry wrote:
 On Tue, Mar 21, 2000 at 20:15:29 +, Mark Ovens wrote:
  Since u/g to 4.0 I've had problems with audio CD players and my
  Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
  the cd devices has got cdcontrol working but still xmcd (v2.6)
  doesn't. It all worked fine under 3.4-STABLE
  
  Starting it with ``-debug'' yields a constant (one every few seconds)
  stream  of:
  
  SCSI CDB bytes (dev=/dev/rcd0c rw=0 to=20):
  00 00 00 00 00 00 -- --  -- -- -- -- -- -- -- --
  CD audio: SCSI command fault on /dev/rcd0c:
  Status=0x16
  
  Is this because xmcd needs updating to work with the new CAM system,
  or something else?
 
 You need to recompile xmcd.
 

In that case I need to wait for the package to be updated. xmcd needs
Motif, which I don't have, so I use the binary package.

Thanks for the quick response.

 Ken
 -- 
 Kenneth Merry
 [EMAIL PROTECTED]

-- 
Seminars, n.:
   From "semi" and "arse", hence, any half-assed discussion.

  FreeBSD - The Power To Serve http://www.freebsd.org
  My Webpage http://ukug.uk.freebsd.org/~mark/
mailto:[EMAIL PROTECTED] http://www.radan.com



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

Re: -current sudden panics :(

[Ilmar S. Habibulin]

On Wed, 22 Mar 2000, Yoshinobu Inoue wrote:

 Do you have any other hints for the problem?, because at least
 I couldn't reproduce it in my 4.0 and 5.0 machines.
   -Any kernel crash dump?
Can you tell me ddb command to make a kernel dump?

   -Is there any typical situation or condition where the
problem happens?
I don't know. uptime between panics is from 5 minutes to 10 hours. They
are sudden as i sayd. :(

   -What is your LAN card?
Something on realtek chiset(rl8139), maybe acorp. I don't remember. The
card worked fine for about one year.



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

Re: -current sudden panics :(

[Ilmar S. Habibulin]

On Tue, 21 Mar 2000, Nikolai Saoukh wrote:

 The driver for his card does not set packet header pointer, thus
 arp stuff see NULL pointer. small patch will cure this problem
 (at least I hope so).
 
 *** if_ed.c.old   Tue Mar 21 19:21:40 2000
 --- if_ed.c   Tue Mar 21 19:23:27 2000
 ***
 *** 2728,2733 
 --- 2728,2734 
*/
   m-m_pkthdr.len = m-m_len = len - sizeof(struct ether_header);
   m-m_data += sizeof(struct ether_header);
 + m-m_pkthdr.header = (void *)eh;
   
   ether_input(sc-arpcom.ac_if, eh, m);
   return;
This is driver for ed(ne2000) cards. I have realtek(rl driver). I took a
look at his source and didn't find such strings. There is comment there
about cutting off mbuf header before passing it to ether_input - what's
this?



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

Re: Another current crash (cvs-cur.6183

[Christopher Masto]

On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
 I've got a different but I think related panic.
 
 #9  0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
 busy!!!")
 at ../../kern/kern_shutdown.c:552
 #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
 at ../../vm/vm_page.h:346

I've been playing around with one of those iopener things and got
myself into a state I thought I could get out of with the help of a
USB Zip drive.  Unfortunately, upon purchasing and connecting one,
I discovered that I can't access it without a panic, which I
point out here on the chance it's also related.

#7  0xc024ac2c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, 
  tf_edi = -1018879976, tf_esi = 256, tf_ebp = -919618472, tf_isp = -919618500, 
  tf_ebx = -1071201278, tf_edx = 0, tf_ecx = -1070746656, tf_eax = 18, 
  tf_trapno = 3, tf_err = 0, tf_eip = -1071396739, tf_cs = 8, tf_eflags = 582, 
  tf_esp = -1071099905, tf_ss = -1071212893}) at ../../i386/i386/trap.c:549
#8  0xc023c87d in Debugger (msg=0xc02696a3 "panic") at machine/cpufunc.h:64
#9  0xc01549e8 in panic (fmt=0xc026c402 "allocbuf: buffer too small")
at ../../kern/kern_shutdown.c:552
#10 0xc0178f5a in allocbuf (bp=0xc3452018, size=83886080) at ../../kern/vfs_bio.c:2346
#11 0xc0178f01 in geteblk (size=83886080) at ../../kern/vfs_bio.c:2315
#12 0xc025cb57 in dsinit (dev=0xc0be1e00, lp=0xc0c490f4, sspp=0xc0c490f0)
at ../../kern/subr_diskmbr.c:186
#13 0xc015eec6 in dsopen (dev=0xc0be1e00, mode=8192, flags=0, sspp=0xc0c490f0, 
lp=0xc0c490f4) at ../../kern/subr_diskslice.c:683
#14 0xc015dfbf in diskopen (dev=0xc0be1e00, oflags=1, devtype=8192, p=0xc88be860)
at ../../kern/subr_disk.c:146
#15 0xc018ae65 in spec_open (ap=0xc92fbe10) at ../../miscfs/specfs/spec_vnops.c:191
#16 0xc018ad65 in spec_vnoperate (ap=0xc92fbe10)
at ../../miscfs/specfs/spec_vnops.c:117
#17 0xc01ff2e9 in ufs_vnoperatespec (ap=0xc92fbe10) at ../../ufs/ufs/ufs_vnops.c:2301
#18 0xc018595f in vn_open (ndp=0xc92fbedc, fmode=1, cmode=0) at vnode_if.h:189
#19 0xc0181951 in open (p=0xc88be860, uap=0xc92fbf80) at ../../kern/vfs_syscalls.c:994
#20 0xc024b4ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = -1077937212, tf_esi = 134894800, tf_ebp = -1077937132, 
  tf_isp = -919617580, tf_ebx = 0, tf_edx = 8, tf_ecx = 134894828, tf_eax = 5, 
  tf_trapno = 12, tf_err = 2, tf_eip = 672026540, tf_cs = 31, tf_eflags = 642, 
  tf_esp = -1077937316, tf_ss = 47}) at ../../i386/i386/trap.c:1073
#21 0xc023cf26 in Xint0x80_syscall ()

I'm not intimately familiar with the function involved, and I'm out of
time tonight, so I'm backing up a few days to see if it goes away.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


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

Re: 4.0-RELEASE boot.flp fails to boot on K6/2

[Jordan K. Hubbard]

Good idea, terrible name.  Can't you guys some up with something better? :)

 On Tue, Mar 21, 2000 at 04:32:35PM -0800, Doug White wrote:
  I would be in favor of renaming the boot.flp to something obviously
  different, like 288boot.flp, to untrain us 2.x heads that got used to the
 
 Great idea.  Would you be able to make the changes locally and test a
 `make release'?  Then all we need to do is pass the patch pass JKH.
 (harder to say "NO" to working code)
 
 -- 
 -- David([EMAIL PROTECTED])
 
 
 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: -current sudden panics :(

[Ilmar S. Habibulin]

On Tue, 21 Mar 2000, Warner Losh wrote:

 In message [EMAIL PROTECTED] Nikolai Saoukh writes:
 :  But shouldn't it be sys/pci/if_rl.c ?
 : 
 : Sorry,
 : it is mea culpa. I mixed his case with my (token ring).
 
 Do you have the patch to if_rl.c.  I looked at it for all of 10
 seconds and it wasn't immediately obvious to me.

But why there is such a sudden change? Everything worked just fine a week
before 5-current.



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

Re: -current sudden panics :(

[Yoshinobu Inoue]

  The driver for his card does not set packet header pointer, thus
  arp stuff see NULL pointer. small patch will cure this problem
  (at least I hope so).
  
  *** if_ed.c.old Tue Mar 21 19:21:40 2000
  --- if_ed.c Tue Mar 21 19:23:27 2000
  ***
  *** 2728,2733 
  --- 2728,2734 
   */
  m-m_pkthdr.len = m-m_len = len - sizeof(struct ether_header);
  m-m_data += sizeof(struct ether_header);
  +   m-m_pkthdr.header = (void *)eh;

  ether_input(sc-arpcom.ac_if, eh, m);
  return;
 This is driver for ed(ne2000) cards. I have realtek(rl driver). I took a
 look at his source and didn't find such strings. There is comment there
 about cutting off mbuf header before passing it to ether_input - what's
 this?

I think this fix is only necessary for token-ring case (as he
say in his following mail), and not related to ethernet.

Yoshinobu Inoue


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

Re: FreeBSD random I/O performance issues

[Matthew Dillon]

:written immediately which is 8750/1 writes.
:
:When the write size drops below the filesystem block size then the
:clustering code never gets called because the buffers are just marked
:dirty and cached.
:
:I think if we fixed the issue of writing out full blocks this behviour
:would stop but I also think the clustering code could do with a fix. It
:should at least check to see if there is a cluster being built when the
:blockno is 0 and push it out. Possibly though it'd be better to not push
:out clusters of only one block and just leave them in the cache.

Hmm.  Your analysis is correct but I don't think it's worth
fixing the block-is-0 case.   It may be worth revisiting the
write-behind code to try to give it the ability to better discern
random I/O from sequential I/O (e.g. perhaps it should ignore unaligned
full blocks).

It is perfectly ok for dirty blocks to remain in the buffer cache.  In
fact, it's *optimal* to leave them in the buffer cache as long as the
buffer cache does not get saturated with them.  The buffer cache is
perfectly capable of clustering delayed writes.  Also, the filesystem 
syncer comes along every 30 seconds or so anyway and flushes everything
out.

What the write-behind code tries to do is to prevent the buffer cache 
from being saturated with dirty buffers and to smooth out disk write
I/O.  It makes the assumption that write-behind data is not typically
accessed by the program immediately after being written -- an assumption
that winds up being incorrect in the DBM case you tested and resulting
in stalls due to the buffer / VM pages being locked during the write I/O.
The stalls are *not* due to the I/O itself but instead are due to side
effects of the I/O being in-progress.  If a user program doesn't access
any of the information it recently wrote the whole mechanism winds up
operating asynchronously in the background.  If a user program does, 
then the write behind mechanism breaks down and you get a stall.

The most common dirty-data case the filesystem has to deal with is 
appending to a file -- that is, doing piecemeal sequential writes.  There
are virtually no other cases which have the ability to saturate the
buffer cache.  This is why the write-behind code only tries to handle
the piecemeal-write-flush-full-blocks case.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]



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

Re: -current sudden panics :(

[Yoshinobu Inoue]

-Any kernel crash dump?
 Can you tell me ddb command to make a kernel dump?

 -Please confirm that your /var/crash has enough size for your
  machine's memory.

 -Please check your swap device using "swapinfo" etc.
  In case of my machine,

   % swapinfo
   Device  1K-blocks UsedAvail Capacity  Type
   /dev/wd0s2b26214475612   18640429%Interleaved

 -Please sepcify it as dumpdev in your /etc/rc.conf

   dumpdev="/dev/wd0s2b"

Then at the reboot of after a panic, crash dump will be
written to files under /var/crash/.

Cheers,
Yoshinobu Inoue


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

Re: Another current crash (cvs-cur.6183

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Paul Richards writes:
Paul Richards wrote:
 
 
 A few more details
 
 #11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
 2706(*b_iodone) (bp);
 
 #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
 at ../../vm/vm_page.h:346
 346 KASSERT(m-flags  PG_BUSY, ("vm_page_wakeup: page not busy!!!"));


I meant to add, people developing current should have INVARIANTS set and
then they'd spot panics like these before I do :-)

Paul, what on earth makes you think we don't run with INVARIANTS ?  :-)


But it might actually make a lot of sense to make INVARIANTS the
default this early in the -CURRENT cycle, protests ?

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

ARP issues (Arcnet)

[Max Khon]

hi, there!

Once again I'm trying to port Arcnet driver from NetBSD/amiga to
FreeBSD/i386 (like I did more than a year ago for 3.x). The problem is in
ARP stuff -- should I port if_arp.c from NetBSD or should I make changes
in if_ether.c for arcnet stuff like Token Ring support did?
Any suggestions are appreciated.

/fjoe



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

Re: 4.0-RELEASE boot.flp fails to boot on K6/2

[Alex Zepeda]

On Tue, 21 Mar 2000, Jordan K. Hubbard wrote:

 Good idea, terrible name.  Can't you guys some up with something better? :)

reallybigbootthing.flp?

- alex



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

ucontext

[Arun Sharma]

On Tue, Sep 07, 1999 at 01:21:59PM +0200, Marcel Moolenaar wrote:
 Peter Wemm wrote:
  
  Before getting too far here, can we consider some other standard interfaces?
  
   #include ucontext.h
  
   int getcontext(ucontext_t *ucp);
   int setcontext(const ucontext_t *ucp);
   void makecontext(ucontext_t *ucp, (void *func)(), int argc, ...);
   int swapcontext(ucontext_t *oucp, const ucontext_t *ucp);
  
  http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html
  
  setjmp,longjmp,sigreturn,etc can all be done with this interface and it can
  be used for libc_r and future kernel-assisted threading.
 
 We're at a point where the discussion, altough meaningful and important,
 has no direct impact on the sigset_t change. I agree with Peter that we
 should as well consider the ucontext interface, but prefer to stay focussed
 on changing sigset_t. So, here's where I shut up and let you discuss the
 matter further :-)

Is anyone working on this ? Porting JDKs to FreeBSD would be a lot easier
if these routines are implemented.

-Arun


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

Re: -current sudden panics :(

[Warner Losh]

In message [EMAIL PROTECTED] "Ilmar S. 
Habibulin" writes:
: But why there is such a sudden change? Everything worked just fine a week
: before 5-current.

No it didn't.  I've been seeing panics like this for about two weeks,
but it hadn't been a priority until this week for me.  And I'm not
seeing it on lightly loaded networks, but am on heavily loaded ones.
Since our product's network port is just for debugging, it isn't a big
deal to me

It is definitely a load related problem for me.  It usually works just
fine, but sometimes there's a packet that gets to arp that arp barfs
on.

Warner


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

$B%0%l!<%H%8%c%K!<(B NEWS $B!J(Bvol.19$B!K(B 03221009

[$B%0%l!<%H%8%c!<%K!<(B]

$B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B
$BFMA3$N%a!<%k$9$k$3$H$r$*5v$72<$5$$!#(B
$B8fLBOG$N$+$+$C$F$7$^$C$?J}!"$3$N%a!<%k$,ITMW$JJ}$XFO$$$F(B
$B$7$^$C$F$$$^$7$?$i?<$/$*OM$S?=$7>e$2$^$9!#(B
$B8fMF$N$40FFb$G$9!#(B

$BEv"!!~(B---

http://www.001.co.jp/mic/gj/beach/supuringkyanpen3.html

$B-!(B $BF|K\9R6uMxMQ!A%"%8%"$NN9!A!!(B
$B!J9a9A!&%7%s%,%]!<%k!&%^%l!<%7%"!&%?%$!&%U%#%j%T%s!&%;%V(B
$B!&%P%j!&%Y%H%J%`!&4Z(B
$B9q!K(B

$B-"(B $B%b%k%G%#%V%D%"!<(B
$B#37nCf$K$4M=Ls$rD:$$$?J}$K$O!"0lN'!o#5!"#0#0#0$N%G%#%9%+(B
$B%&%s%H!*!*(B

$B-#(B $B%S%s%?%sEg!u%7%s%,%]!<%k#5F|4V(B
$B!A:#$A$g$C$H$7$?%V!<%`$K$J$C$F$^$9!A(B


$B$*Ld$$9g$o$;$r?4$h$j$*BT$A?=$7>e$2$F$*$j$^$9!#(B

$B3t<02q

Re: SCSI errors from xmcd

[Andy Sparrow]

Your message dated: Tue, 21 Mar 2000 20:57:17 GMT

  Is this because xmcd needs updating to work with the new CAM system,
  or something else?
 
 You need to recompile xmcd.
 

In that case I need to wait for the package to be updated. xmcd needs
Motif, which I don't have, so I use the binary package.

I find a lot of stuff which "needs" Motif (including 'xmcd') builds and 
works just great with Lesstif, and there's a port for that. You might like
to set 'HAVE_MOTIF=yes' manually in '/etc/make.conf' after installing. :-)


Something else that sometimes causes problems might be having old-as-dirt 
libraries kicking around from aeons ago - sometimes these seem to get used 
if they're present on the system, and not much cleans them out except
operator intervention...


Cheers,

AS



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

Re: Reading from bad disk ?

[Soren Schmidt]

It seems Warner Losh wrote:
 : A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
 : to become very hot compared to other disks when mounted in the
 : same machine (on a removable frame). Do others have the same
 : experience ?
 
 Yes.  They run very hot.  I had to steal an old powersupply fan and
 mount it in front of the drive to get it to run at  a reasonable
 temperature.  W/o the fan, it was running at 58C or so.  With the fan
 it runs at 39C or so.  I've included the script that I use to find
 this information out.  Ken Merry sent it to me.  It works on some IBM
 drives.
 
 Warner
 
 #!/bin/sh
 
 TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`
 
 TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc`
 
 echo "The temperature is: $TEMPF F $TEMPC C"

Hmm, wonder if one can get that info from their ATA disks as well...

-Søren


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

Re: Reading from bad disk ?

[Warner Losh]

In message [EMAIL PROTECTED] Soren Schmidt writes:
:  TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`

: Hmm, wonder if one can get that info from their ATA disks as well...

Don't know.  You'd have to ask IBM.  All the above camcontrol is doing
is reading a special mode page (I'm sure ken will correct me if I'm
wrong)...  Do ata drives have this concept?

Warner



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

Re: FreeBSD random I/O performance issues

[Chris Wasser]

On Wed, Mar 22, 2000 at 12:22:42AM +, Richard Wendland wrote:
 Any views gratefully received.  A fix would be much better :-)

Not sure if my meager setup helps any, but in the interests in providing
results to help the cause so-to-speak, I ran the test on my own machine
(followed the instructions in the source file to the letter):

(/tmp)[13]# time ./seekreadwrite xxx 1

real0m4.462s
user0m0.018s
sys 0m1.204s


Hardware information:

FreeBSD 4.0-STABLE #4: Thu Mar 16 15:15:07 MST 2000

CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)

real memory  = 134217728 (131072K bytes)

atapci1: HighPoint HPT366 ATA66 controller port
0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 4 at device 19.0 on pci0
ata2: at 0xd800 on atapci1
atapci2: HighPoint HPT366 ATA66 controller port
0xec00-0xecff,0xe800-0xe803,0xe400-0xe407 irq 4 at device 19.1 on pci0
ata3: at 0xe400 on atapci2

ad4: 12416MB QUANTUM FIREBALL CR13.0A [25228/16/63] at ata2-master
using UDMA66

/dev/ad4s2f on /tmp (ufs, local, soft-updates, writes: sync 19 async
10197, reads: sync 169 async 0)

(/tmp)[19]# sysctl -a | grep -i vfs.write_behind
vfs.write_behind: 1

Mem: 58M Active, 29M Inact, 24M Wired, 4248K Cache, 11M Buf, 8860K Free
Swap: 257M Total, 257M Free

12:36AM  up 1 day,  9:54, 7 users, load averages: 0.10, 0.04, 0.01

The HDD is a 5400RPM ATA-66 drive (to state the obvious) this test was
conducted while I was in X (su'd to root) so there was some load on the
machine. Hope this helps in some way.


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

Re: Reading from bad disk ?

[Luigi Rizzo]

 Don't know.  You'd have to ask IBM.  All the above camcontrol is doing
 is reading a special mode page (I'm sure ken will correct me if I'm
 wrong)...  Do ata drives have this concept?

i think they do.
cheers
luigi



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

Re: Davicam dc0 driver

[Matthew Dillon]

:I have a BookPC with a built in Davi Comm 10/100 ethernet card.
:
:I am always getting
:
:/kernel: dc0: watchdog timeout
:
:every few minutes..
:
:Can thease errors be stopped?
:
:
:Thank you for any reply
:
:RP
:[EMAIL PROTECTED]

If you've got a kernel build environment setup, try the following
patch to if_dc (suggested to me by Bill Paul a few months ago).  I
would be interested in knowing if it reduces the number of wdog 
timeouts you get.  It seems to help mine.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

Index: if_dc.c
===
RCS file: /home/ncvs/src/sys/pci/if_dc.c,v
retrieving revision 1.7
diff -u -r1.7 if_dc.c
--- if_dc.c 2000/01/24 17:19:37 1.7
+++ if_dc.c 2000/01/26 23:27:20
@@ -1548,7 +1548,7 @@
break;
case DC_DEVICEID_82C115:
sc-dc_type = DC_TYPE_PNICII;
-   sc-dc_flags |= DC_TX_POLL|DC_TX_USE_TX_INTR;
+   sc-dc_flags |= DC_TX_POLL|DC_TX_INTR_ALWAYS;
break;
case DC_DEVICEID_82C168:
sc-dc_type = DC_TYPE_PNIC;


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

subscribe

[alterego]

subscribe



-
Get Your e-mail at http://www.freemail.ru


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

Re: 'machine/param.h' required for 'sys/socket.h'

[Yoshinobu Inoue]

Hello,

   'sys/scocket.h' header file start using ALIGN macro 
 defined in 'machine/param.h' header file while the man page
 for "socket" only mentioned 'sys/types.h' as the prerequisite
 for 'sys/socket.h'.
 
   As a result the 'net/pchar' port is now broken.

Yes, this problem is already found by Bruce A. Mah and some
mail is exchanged between related people.

   What must be done to solve this ? 
 Is it possible to '#include sys/param.h' in 'sys/socket.h' OR
 the man page must be corrected to explicitly state 'param.h'
 (sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and
 all the programms using it patched accordingly ?

As itojun's experience, including machine/param.h in socket.h
also cause problems in some other apps.

I feel requesting inclusion of machine/param.h for any apps
which use socket is better. But if there are any other smarter
solution, please let me know and I'll appreciate it much.

Thanks,
Yoshinobu Inoue



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