Re: VM_METER no longer defined?

[Matthew Dillon]

:> >#define VM_METER VM_TOTAL

This change was part of a larger patch set.  I have no particular 
objection to adding the #define or renaming VM_TOTAL back to VM_METER,
but I *WILL* point out that even without a name change the VM cnt 
structure has changed so often that for all intents and purposes the
API has changed with or without the name change, on many occassions,
and is likely to continue to change in the future.  

Because of this there isn't much point keeping name compatibility and
unless you can point to some piece of third party software that
is so adversely effected that the name must be changed back, I would
not recommend changing it back.  But if you want to do it, I will not
stop you.

-Matt


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

Re: make buildworld stopped at libexec/getty/main.c

[Peter Haight]

I get exactly the same error. I'm building on a 4.7-STABLE built on
11/29/02.

>root@leafy:/usr/src/libexec/getty# make
>cc -O -pipe -march=pentium3-c /usr/src/libexec/getty/main.c
>/usr/src/libexec/getty/main.c: In function `main':
>/usr/src/libexec/getty/main.c:335: syntax error before '!' token
>*** Error code 1
>
>Stop in /usr/src/libexec/getty.


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

Re: STABLE->CURRENT rl fails

[Terry Lambert]

"Russell L. Carter" wrote:
> Ok-dokey, over to linux it goes.  Rats.
> : Perhaps there's a nice search string that will cough up what
> : to do, if there's hope?  This laptop is perfectly stable with
> : STABLE.  (But no sound or acpi...)
> : : Trial upgrade from a laptop running stable just fine for the last
> : : six months to current (GENERIC) is still failing with the same symptoms:

Suggestion #1:  Try running 5.0-RELEASE, now that it's out, and
tell us if it has the same problems

Suggestion #2:  Disable the ACPI loading

Suggestion #3:  Discable the AGP loading

Suggestion #4:  The damn thing runs fine under -STABLE; is there
someone pointing a gun at your head forcing you
you upgrade to 5.0 or Linux, or is it possible to
*keep running stable*?

-- Terry

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

Re: kern/46619: Installation hangs on IBM Thinkpad T23

[Arun Sharma]

Actually, a simpler workaround is to set:

hw.eisa_slots=0

in the boot loader. This machine also requires:

unset acpi_load

in order to boot.

	-Arun


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

i386 tinderbox failure

[Dag-Erling Smorgrav]

/home/des/tinderbox/tinderbox.sh: /home/des/tinderbox/whereintheworld: not found

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

ia64 tinderbox failure

[Peter Wemm]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating 
>/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
===> libexec/getty
/home/tinderbox/ia64/src/libexec/getty/main.c: In function `main':
/home/tinderbox/ia64/src/libexec/getty/main.c:335: syntax error before '!' token
*** Error code 1

Stop in /home/tinderbox/ia64/src/libexec/getty.
*** Error code 1

Stop in /home/tinderbox/ia64/src/libexec.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

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

Re: How to build -current and install to empty slice?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Ray Kohler <[EMAIL PROTECTED]> writes:
: > # cd /5/usr/src && MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make buildworld
: > # MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make kernel
: > # MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make installworld
: > # cd /5/usr/src/etc && DESTDIR=/5 make distribution
: 
: MAKEOBJDIRPREFIX is probably redundant here, but I don't know.

I don't think so.  I think you need it for all the commands that have
it.

Warner



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

IBM Thinkpad 600E

[Michael Lamb]

First time poster and susbscriber, someone suggested that I email my
findings to the freebsd-current list, so hopefully this is the right
place.

I have been playing with FreeBSD 5.0 on my Thinkpad 600E and could not
get the pccard to work at at all. So I searched thru some of the
archives and pieced some information together enough to get it working.

I was able to get it working by disabling acpi by adding the following
in /boot/device.hints:

hint.acpi.0.disabled="1"

And it was also recommended in some resent posts to the list to add this
to the same file to get pccard cardbus to work:

hw.cbb.start_memory="0x2000"

>From there I just added the following to /etc/rc.conf:
apm_enable="YES"
apmd_enable="YES"

Hopefully someone might find this information helpful if it has not
already been brought up.

-- 
Michael Lamb - [EMAIL PROTECTED]
Sr. Network Engineer - O1 Communications

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

make buildworld stopped at libexec/getty/main.c

[leafy]

root@leafy:/usr/src/libexec/getty# make
cc -O -pipe -march=pentium3-c /usr/src/libexec/getty/main.c
/usr/src/libexec/getty/main.c: In function `main':
/usr/src/libexec/getty/main.c:335: syntax error before '!' token
*** Error code 1

Stop in /usr/src/libexec/getty.

-- 
"Without the userland, the kernel is useless."
 --inspired by The Tao of Programming

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

Re: new wi0 slowness

[Sam Leffler]

> I have noticed the following with the new wi0.  I have the 802.11
connection
> between my laptop running XP and my current box running as a hostap.  I
also
> have a IPSec tunnel between the current box and the laptop, but I don't
> think this could be causing the problems.
> While transferring files from samba on the current box to the laptop I got
> the following results:
>
> With the old wi0:
>   average 5120.3Kb/s
>   peak 7326.5Kb/s
>   With top -S
> 85% interrupt
> cpu - 58%  swi1: net
>  21.8% irq10: wi0
>
> With the new wi0:
>   average 877.0Kb/s
>   peak 902.4Kb/s
>   With top -S
> 11.6% interrupt
> cpu - 9%  swi1: net
>  0.88% irq10: wi0
>
> I am also getting hundreds of: "wi0: tx failed, retry limit exceeded" with
> the new driver under heavy load.  In addition it get many random
disconnects
> which I would not notice, except AIM gets logged out.  I don't think it
has
> anything to do with the ipsec tunnel as the SAD entries are still there
and
> it only happen with the new wi kernel.  I have tried FAST_IPSEC and it
does
> work with the new wi0 driver where it would temporarily lock up the
machine
> with the old one, but I'm not using it since I thought it may be causing a
> problem and its ends up that it did not make a difference.  I am going to
> try it later without IPSec just to be sure.
>

Ignore IPsec; in fact don't configure it.

I just changed the default setting of kern.wi_txerate to 0 to suppress
printing tx error messages; do likewise:

sysctl kern.wi_txerate=0

This is the way the old driver worked.

> Under the new driver my card which sold as a D-link DWL-520 2.4GHz
Wireless
> PCI card is shown as a:
> dmesg 
> wi0:  mem 0xe600-0xe6000fff irq 10 at device 15.0
on
> pci0
> wi0: 802.11 address: 00:05:5d:fa:0e:b0
> wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI)
> wi0: Intersil Firmware: Primary (1.0.7), Station (1.3.6)
> wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> 
> I can change the media through ifconfig to DS/11Mbps or whatever, but it
> does not seem to change anything other then ifconfig will show "media:
IEEE
> 802.11 Wireless Ethernet DS/11Mbps  (DS/2Mbps )" rather
then
> autoselect.  The same slowness is still there.  wicontrol shows it as
having
> a TX rate (actual speed) of 2 no matter what.  I can set the (selection)
to
> anything such as 11, and again no change in the throughput or anything.  I
> have also changed things with the old driver, and nothing changed with the
> throughput, and it also shows the (actual speed) as 2 but I get higher
> throughput.  It seems to kinda have a mind of its own.  Well if you need
> anymore info, just drop me a message.  I enabled debugging for wi0 as a
> earlier post showed, but I had no idea what I was looking at :).
>

You've said nothing about how your interface is configured except that it's
running in hostap mode; start by giving the output of ifconfig wi0.  The
output of netstat -i might indicate the error rate on your Dlink card (tx
errors show up as output errors).

Finally, you may want to try different station firmware in your Dlink card.
I run 1.4.9 in my Senao (Prism 2.5) cards with good success.  I don't recall
whether there were issues with 1.3.6 (I know some of the intermediate
versions had problems especially in hostap mode).  You can get 1.4.9
firmware at http://www.netgate.com/support/prism_firmware/.

Sam


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

Re: STABLE->CURRENT rl fails

[Russell L. Carter]

Thanks Robert,
I'm looking into this now.  Unfortunately, now the symptom is a
hard wedge on "large" transfers over rl0, no response to
anything obvious, other than hard reset.  So I'm seeing what I
can do to tickle it into something more informative.  That previous
dmesg quoted below I think was the result of leaving the system (in disgust)
wedged overnight.

Nope, any large transfers wedge the system tight, which ever 
side initiates.  I waited for the background disk checks to
complete and then rebooted clean in between tests.  Very tedious.

Constant pings with occasional ntpd and dns client traffic
succeed fine overnight (last night) though.

System configured per advice...

I've run quite large transfers through this system on stable with
no issues at all, since June '02.

Best,
Russell

"large transfer" is $ cd /usr/ports/distfiles ; scp *.gz target:/usr/tmp

: 
: On Fri, 17 Jan 2003, Russell L. Carter wrote:
: 
: > rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514)
: > rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514)
: > rl0: discard oversize frame (ether type 2e3d flags 3 len 55442 > max 1514)
: > rl0: discard oversize frame (ether type 904 flags 3 len 36106 > max 1514)
: > 
: > Fatal trap 12: page fault while in kernel mode
: > fault virtual address   = 0x46
: > fault code  = supervisor read, page not present
: > instruction pointer = 0x8:0xc02f19c0
: > stack pointer   = 0x10:0xd9344ca4
: > frame pointer   = 0x10:0xd9344cbc
: > 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 = 832 (reboot)
: > trap number = 12
: > panic: page fault
: 
: I'm probably no good on the if_rl and ACPI issues, but I can give this one
: a try.  This panic is a NULL pointer dereference, apparently in the
: shutdown.  If this is reproduceable, here's what would be most helpful to
: debug it: take a copy of the GENERIC kernel config, and make sure it
: contains debugging symbols.  I.e., the kernel configuration contains
: "makeoptions DEBUG=-g".  Configure kernel dumps using the dumpdev option
: in /etc/rc.conf -- typically people use their swap device.  You may
: already have debugging symbols for your kernel if you're using GENERIC
: from -current.  When the crash occurs, a dump will be performed, and then
: when you boot up next, it will be saved in /var/crash (assuming you have
: room -- if it's smaller than your system memory, symlink to /usr/crash and
: create an appropriate target directory).  Finally, run:
: 
:   gdb /usr/obj/.../kernel.debug /var/crash/vmcore.0
: 
: (replace the first path with the path to your kernel target build
: directory)
: (replace the second path with the most recent kernel dump)
: 
: Type in "backtrace" to generate a trace, and respond to this e-mail with
: the trace.
: 
: Another popular debugging option is to compile your kernel with "options
: DDB" which will allow you access to the live kernel debugger, which can be
: used to generate traces on a panic.  However, that's most useful if you
: have a serial console, and can copy/paste the results into an e-mail. 
: There should be a fair amount of information on kernel debugging in the
: handbook if you need guidance on the details on how to do the above.
: 
: Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
: [EMAIL PROTECTED]  Network Associates Laboratories
: 
: 
: 
: 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: alpha tinderbox failure

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Kris Kennaway <[EMAIL PROTECTED]> writes:
: On Fri, Jan 17, 2003 at 04:16:14PM -0800, Dag-Erling Smorgrav wrote:
: 
: > ===> vinum
: > "Makefile", line 4437: warning: duplicate script for target "geom_bsd.o"  [...]
: > /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver i [...]
: > /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
: > /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...]
: > /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver i [...]
: > /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is b [...]
: > cc1: warnings being treated as errors
: > /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe':
: > /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit  [...]
: > *** Error code 1
: 
: Am I the only one who thinks that the error message truncation makes
: it difficult to see the error?

Yes.  At the very least we should also truncate the /h/des/src from
the front which gives 10 more characters.  However, even that might
not be enough...

Warner

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

Re: new wi0 slowness

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"Matt Haught" <[EMAIL PROTECTED]> writes:
: I can change the media through ifconfig to DS/11Mbps or whatever, but it
: does not seem to change anything other then ifconfig will show "media: IEEE
: 802.11 Wireless Ethernet DS/11Mbps  (DS/2Mbps )" rather then
: autoselect.  The same slowness is still there.  wicontrol shows it as having
: a TX rate (actual speed) of 2 no matter what.  I can set the (selection) to
: anything such as 11, and again no change in the throughput or anything.  I
: have also changed things with the old driver, and nothing changed with the
: throughput, and it also shows the (actual speed) as 2 but I get higher
: throughput.  It seems to kinda have a mind of its own.  Well if you need
: anymore info, just drop me a message.  I enabled debugging for wi0 as a
: earlier post showed, but I had no idea what I was looking at :).

This has nothing to do with your slowness.  The firmware in the card
always reports 2Mbps to the driver.  The slowdown comes from
elsewhere.

Warner

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

Re: 4.7-amd cannot mount exports from 5.0-RELEASE

[Masafumi NAKANE]

I've been encountering the exact same problem past a few days.  My
-CURRENT box is -CURRENT as of 01/18.

Another thing is that, I can mount filesystems via NFS from a -CURRENT
box if I execute the mount command manually.  But it fails to mount
them via AMD.  So it doesn't look like it is the problem specific to
4.7-STABLE and 5.0-CURRENT combination.  It just seems that NFS
exported filesystems on 5.0-CURRENT cannot be mounted via AMD even
though they are statically mountable.

 Cheers,
Max


On Sun, 19 Jan 2003 20:28:25 +0100,
Michael Nottebrock <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1

> I have upgraded a box from 4.7-p1 to 5.0-RELEASE. It exports all its
> filesystems ( /, /usr, /var ) via NFS. A 4.7-STABLE client used to mount
> in those exports on demand with amd, with the default amd-map and /net
> and /host. Since the upgrade to 5.0-RELEASE on the server, amd cannot
> mount the exports anymore. It hangs and after a while throws an error
> similar to

> amd[345]: mountd rpc failed: RPC: Timed out

> in the syslog. Let me stress that the configurations of both the server
> and client have not changed at all and are almost factory defaults - yet
> it just ceased working. The most peculiar thing is that the 4.7-STABLE
> client also mounts in /usr/ports/distfiles from the server statically -
> and that still works. ..

> (not subscribed to list - please CC me)

> - --
> Regards,
>   Michael Nottebrock

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.1 (FreeBSD)
> Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

> iD8DBQE+KvxZXhc68WspdLARAm/ZAJ99pJMyz/PjM6bx5Uuc7nLFhHg5yQCbBg3a
> IaiXOMjN0iBiuCOQElnnxM4=
> =FYbe
> -END PGP SIGNATURE-


> 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: How to build -current and install to empty slice?

[Ray Kohler]

On Sun, Jan 19, 2003 at 05:05:37PM -0800, Darren Pilgrim wrote:
> 
> How do tell make to use /5/usr/obj instead of /usr/obj?  Will 
> MAKEOBJDIRPREFIX=/5/usr/obj do this?
> 
> I have more questons:
> 
> Can I force make to ignore /etc/make.conf and /etc/defaults/make.conf and
> read another set of config files?  Would it be safe to use 
> /5/usr/src/etc/defaults/make.conf?
> 
> Will DESTDIR=/5 cause the new build tools to install under /5 as well, or 
> do I need to set something else to avoid having my 4.7p3 build tools 
> clobbered?
> 
> So far I have this set of commands:
> 
> # cd /5/usr/src && MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make buildworld
> # MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make kernel
> # MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make installworld
> # cd /5/usr/src/etc && DESTDIR=/5 make distribution

MAKEOBJDIRPREFIX is probably redundant here, but I don't know.

> # cd /5/usr/src/release/sysinstall && make clean && make all install

sysinstall now lives in usr/sbin, so it'll be taken care of by the
regular build/installworld.

> # install -o root -g wheel -m 0555 /5/usr/src/etc/MAKEDEV /5/dev/MAKEDEV
> # cd /5/dev && ./MAKEDEV all ad4 ad4s2h ad4s3h ad4s4h ums1 vn1 vty16

Don't do these two, MAKEDEV isn't needed in 5.0, even though it still
exists, and when DEVFS is mounted on /dev, this stuff will get lost
anyway (and take up disk space).

> # disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /dev/ad4s3

Don't you mean
# disklabel -B -b /5/boot/boot1 -s /5/boot/boot2 /dev/ad4s3
?

-- 
Ray Kohler <[EMAIL PROTECTED]>
After living in New York, you trust nobody, but you believe
everything.  Just in case.

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

Re: STABLE->CURRENT rl fails

[Robert Watson]

On Fri, 17 Jan 2003, Russell L. Carter wrote:

> rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514)
> rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514)
> rl0: discard oversize frame (ether type 2e3d flags 3 len 55442 > max 1514)
> rl0: discard oversize frame (ether type 904 flags 3 len 36106 > max 1514)
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x46
> fault code= supervisor read, page not present
> instruction pointer   = 0x8:0xc02f19c0
> stack pointer = 0x10:0xd9344ca4
> frame pointer = 0x10:0xd9344cbc
> 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   = 832 (reboot)
> trap number   = 12
> panic: page fault

I'm probably no good on the if_rl and ACPI issues, but I can give this one
a try.  This panic is a NULL pointer dereference, apparently in the
shutdown.  If this is reproduceable, here's what would be most helpful to
debug it: take a copy of the GENERIC kernel config, and make sure it
contains debugging symbols.  I.e., the kernel configuration contains
"makeoptions DEBUG=-g".  Configure kernel dumps using the dumpdev option
in /etc/rc.conf -- typically people use their swap device.  You may
already have debugging symbols for your kernel if you're using GENERIC
from -current.  When the crash occurs, a dump will be performed, and then
when you boot up next, it will be saved in /var/crash (assuming you have
room -- if it's smaller than your system memory, symlink to /usr/crash and
create an appropriate target directory).  Finally, run:

  gdb /usr/obj/.../kernel.debug /var/crash/vmcore.0

(replace the first path with the path to your kernel target build
directory)
(replace the second path with the most recent kernel dump)

Type in "backtrace" to generate a trace, and respond to this e-mail with
the trace.

Another popular debugging option is to compile your kernel with "options
DDB" which will allow you access to the live kernel debugger, which can be
used to generate traces on a panic.  However, that's most useful if you
have a serial console, and can copy/paste the results into an e-mail. 
There should be a fair amount of information on kernel debugging in the
handbook if you need guidance on the details on how to do the above.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories



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

Re: STABLE->CURRENT rl fails

[Russell L. Carter]

Ok-dokey, over to linux it goes.  Rats.

Russell


: 
: 
: Perhaps there's a nice search string that will cough up what
: to do, if there's hope?  This laptop is perfectly stable with 
: STABLE.  (But no sound or acpi...)
: 
: Thanks,
: Russell
: 
: 
: 
: : Trial upgrade from a laptop running stable just fine for the last
: : six months to current (GENERIC) is still failing with the same symptoms:
: : 
: : On board rl0 comes up just fine, but a transfer hangs 
: : after about 150KB or so.  After a minute or two, the laptop reboots.
: : 
: : That's at 100BaseTX, plus the various mediaopts.  At 10BaseT,
: : it takes longer during a file transfer to trigger the problem, but
: : it gets there after a megabyte or so.
: : 
: : I've attached a dmesg, interesting "lock order reversal" item in it.
: : 
: : I'm willing to dedicate a week or so to get this thing up because it's
: : one of those ACPI only laptops.
: : 
: : Tell me what to do to get better info...
: : 
: : Thank you,
: : Russell
: : 
: : 
: : Copyright (c) 1992-2003 The FreeBSD Project.
: : Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
: : The Regents of the University of California. All rights reserved.
: : FreeBSD 5.0-CURRENT #0: Fri Jan 17 08:55:47 MST 2003
: : [EMAIL PROTECTED]:/usr/obj/usr/src-current/src/sys/GENERIC
: : Preloaded elf kernel "/boot/kernel/kernel" at 0xc06c3000.
: : Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06c30a8.
: : Timecounter "i8254"  frequency 1193182 Hz
: : Timecounter "TSC"  frequency 1991920132 Hz
: : CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1991.92-MHz 686-class CPU)
: :   Origin = "GenuineIntel"  Id = 0xf24  Stepping = 4
: :   Features=0x3febf9ff
: : real memory  = 520093696 (496 MB)
: : avail memory = 497917952 (474 MB)
: : Initializing GEOMetry subsystem
: : Pentium Pro MTRR support enabled
: : npx0:  on motherboard
: : npx0: INT 16 interface
: : acpi0:  on motherboard
: : ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
: : ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31
: : Using $PIR table, 7 entries at 0xc00fdf50
: : Timecounter "ACPI-fast"  frequency 3579545 Hz
: : acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
: : acpi_cpu0:  on acpi0
: : acpi_tz0:  on acpi0
: : pcib0:  port 0xcf8-0xcff on acpi0
: : pci0:  on pcib0
: : agp0:  mem 0xe800-0xe8ff at device 0.0 
: : on pci0
: : pcib1:  at device 1.0 on pci0
: : pci1:  on pcib1
: : pci1:  at device 0.0 (no driver attached)
: : isab0:  at device 2.0 on pci0
: : isa0:  on isab0
: : ohci0:  mem 0xe900-0xe9000fff irq 11 at device 
: : 2.2 on pci0
: : usb0: OHCI version 1.0, legacy support
: : usb0: SMM does not respond, resetting
: : usb0:  on ohci0
: : usb0: USB revision 1.0
: : uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
: : uhub0: 2 ports with 2 removable, self powered
: : ums0: Mitsumi Mitsumi Quick Scroll Mouse (USB), rev 1.00/1.05, addr 2, iclass 
: : 3/1
: : ums0: 3 buttons and Z dir.
: : ohci1:  mem 0xe9001000-0xe9001fff irq 10 at device 
: : 2.3 on pci0
: : usb1: OHCI version 1.0, legacy support
: : usb1:  on ohci1
: : usb1: USB revision 1.0
: : uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
: : uhub1: 2 ports with 2 removable, self powered
: : atapci0:  port 0x1000-0x100f at device 2.5 on pci0
: : ata0: at 0x1f0 irq 14 on atapci0
: : ata1: at 0x170 irq 15 on atapci0
: : pci0:  at device 2.7 (no driver attached)
: : rl0:  port 0x1400-0x14ff mem 0x6004800-0x60048ff 
: : irq 11 at device 10.0 on pci0
: : rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode
: : rl0: Ethernet address: 00:90:f5:12:59:3b
: : miibus0:  on rl0
: : rlphy0:  on miibus0
: : rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
: : pci0:  at device 11.0 (no driver attached)
: : cbb0:  mem 0x8800-0x88000fff irq 5 at device 
: : 12.0 on pci0
: : cardbus0:  on cbb0
: : pccard0: <16-bit PCCard bus> on cbb0
: : acpi_button0:  on acpi0
: : acpi_button1:  on acpi0
: : acpi_acad0:  on acpi0
: : acpi_cmbat0:  on acpi0
: : acpi_lid0:  on acpi0
: : atkbdc0:  port 0x64,0x60 irq 1 on acpi0
: : atkbd0:  flags 0x1 irq 1 on atkbdc0
: : kbd0 at atkbd0
: : psm0:  irq 12 on atkbdc0
: : psm0: model Generic PS/2 mouse, device ID 0
: : sio0 port 0x3f8-0x3ff irq 4 on acpi0
: : sio0: type 16550A
: : acpi_ec0:  port 0x66,0x62 on acpi0
: : orm0:  at iomem 0xdc000-0xd,0xc-0xcbfff on isa0
: : pmtimer0 on isa0
: : fdc0: cannot reserve I/O port range (6 ports)
: : ppc0: parallel port not found.
: : sc0:  at flags 0x100 on isa0
: : sc0: VGA <16 virtual consoles, flags=0x300>
: : sio1: configured irq 3 not in bitmap of probed irqs 0
: : sio1: port may not be enabled
: : vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
: : Timecounters tick every 10.000 msec
: : acpi_cpu: CPU throttling available, 8 steps from 100% to 12.5%
: : ad0: 28615MB  [58140/16/63] at ata0-master UDMA100
: : acd0: CD-RW  at ata1-master PIO4
: : Mounting root from ufs:

Re: How to build -current and install to empty slice?

[Darren Pilgrim]

Dag-Erling Smorgrav wrote:> "Kevin Oberman" <[EMAIL PROTECTED]> writes:



The first question is a bit tougher.



Not at all.  Just prepare the slice so that it contains at least an
'a' partition (so you can boot from it), mount the fresh partitions in
the correct places in relation to eachother (e.g. ad0s2a on /mnt,
ad0s2d on /mnt/var, ad0s2e on /mnt/usr), then install 5.0 on the
appropriate partitions.  There are a number of ways to do the latter:

 - if you have successfully built a 5.0 world, do an installworld with
   DESTDIR set to the root of the empty partitions (/mnt in our
   example).  Then go into the 'etc' directory in your 5.0 source tree
   and do 'make distribution', again with DESTDIR set to the root of
   the appropriate partitions.  You will also need to build and
   install a kernel, and install the first- and second-stage loaders
   (using disklabel -B); the 4.x loaders should work fine, but you can
   force disklabel to use the 5.0 loaders:

# disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 ad0s2


[For reference, I moved the base mountpoint to /5.]

How do tell make to use /5/usr/obj instead of /usr/obj?  Will 
MAKEOBJDIRPREFIX=/5/usr/obj do this?

I have more questons:

Can I force make to ignore /etc/make.conf and /etc/defaults/make.conf and
read another set of config files?  Would it be safe to use 
/5/usr/src/etc/defaults/make.conf?

Will DESTDIR=/5 cause the new build tools to install under /5 as well, or do 
I need to set something else to avoid having my 4.7p3 build tools clobbered?

So far I have this set of commands:

# cd /5/usr/src && MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make buildworld
# MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make kernel
# MAKEOBJDIRPREFIX=/5/usr/obj DESTDIR=/5 make installworld
# cd /5/usr/src/etc && DESTDIR=/5 make distribution
# cd /5/usr/src/release/sysinstall && make clean && make all install
# install -o root -g wheel -m 0555 /5/usr/src/etc/MAKEDEV /5/dev/MAKEDEV
# cd /5/dev && ./MAKEDEV all ad4 ad4s2h ad4s3h ad4s4h ums1 vn1 vty16
# disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /dev/ad4s3


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

FreeBSD panic with umass

[Kenneth Culver]

Hi,
I just tried to use a Genesys Logic USB Compact Flash card reader,
and the following messages come up, followed by a panic:

Jan 19 19:41:30 kenshin kernel: umass0: Genesys Logic USB Storage Device,
rev 1.
10/1.13, addr 2
Jan 19 19:41:30 kenshin kernel: umass0: Get Max Lun not supported
(STALLED)
Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:30 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): got CAM status 0x4
Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): fatal error,
failed to a
ttach to device
Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): lost device
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB reset failed, IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-in clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: umass0: BBB bulk-out clear stall failed,
IOERROR
Jan 19 19:41:31 kenshin kernel: (da0:umass-sim0:0:0:0): removing device
entry
Jan 19 19:41:31 kenshin kernel: Opened disk da0 -> 5

After this, FreeBSD panics. I havn't had time to get a full backtrace, but
I'll send that once I get it. In the mean-time, is there any fix for the
error I'm getting?


Ken


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

if_sis.c 1.61 breaks support for SiS630 chipset

[Mikko Työläjärvi]

Hello,

Version 1.61 of if_sis.c breaks support for SiS630, or at least the
one on my laptop. This has been noted before, in

I just though I'd add some more details.

The device probe fails with:

  sis0: MII without any PHY!

pciconf reports the chip as:

 sis0@pci0:1:1:  class=0x02 card=0x020114ff chip=0x09001039 rev=0x82 hdr=0x00
vendor   = 'Silicon Integrated Systems (SiS)'
device   = 'SiS900 Fast Ethernet/Home Networking Ctrlr'
class= network
subclass = ethernet

Things start to go bad when sis_mii_readreg() ends up in the ack
failure case (around line 622):

/*
 * Now try reading data bits. If the ack failed, we still
 * need to clock through 16 cycles to keep the PHY(s) in sync.
 */
if (ack) {
for(i = 0; i < 16; i++) {
SIO_CLR(SIS_MII_CLK);
DELAY(1);
SIO_SET(SIS_MII_CLK);
DELAY(1);
}
goto fail;
}


Conditionally reverting part of sis_miibus_readreg() to r1.60 is
sufficient to make things work again:

--- if_sis.c.1.62   Sun Jan 19 14:35:57 2003
+++ if_sis.cSun Jan 19 15:14:54 2003
@@ -735,6 +735,39 @@
sc->sis_rev < SIS_REV_635 && phy != 0)
return(0);

+#if 1
+   /*
+* Hack: The new code below does not work with my sis630S.
+*   Revive working code from r1.60
+*/
+
+   if (sc->sis_type == SIS_TYPE_900 && sc->sis_rev <= SIS_REV_630S) {
+   int i, val = 0;
+
+   CSR_WRITE_4(sc, SIS_PHYCTL,
+   (phy << 11) | (reg << 6) | SIS_PHYOP_READ);
+   SIS_SETBIT(sc, SIS_PHYCTL, SIS_PHYCTL_ACCESS);
+
+   for (i = 0; i < SIS_TIMEOUT; i++) {
+   if (!(CSR_READ_4(sc, SIS_PHYCTL) & SIS_PHYCTL_ACCESS))
+   break;
+   }
+
+   if (i == SIS_TIMEOUT) {
+   printf("sis%d: PHY failed to come ready\n",
+  sc->sis_unit);
+   return(0);
+   }
+
+   val = (CSR_READ_4(sc, SIS_PHYCTL) >> 16) & 0x;
+
+   if (val == 0x)
+   return(0);
+
+   return(val);
+   }
+#endif
+
bzero((char *)&frame, sizeof(frame));

frame.mii_phyaddr = phy;


If anyone has theories for a more correct patch, I'll be happy to try
them out.

   $.02,
   /Mikko


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

new wi0 slowness

[Matt Haught]

I have noticed the following with the new wi0.  I have the 802.11 connection
between my laptop running XP and my current box running as a hostap.  I also
have a IPSec tunnel between the current box and the laptop, but I don't
think this could be causing the problems.
While transferring files from samba on the current box to the laptop I got
the following results:

With the old wi0:
  average 5120.3Kb/s
  peak 7326.5Kb/s
  With top -S
85% interrupt
cpu - 58%  swi1: net
 21.8% irq10: wi0

With the new wi0:
  average 877.0Kb/s
  peak 902.4Kb/s
  With top -S
11.6% interrupt
cpu - 9%  swi1: net
 0.88% irq10: wi0

I am also getting hundreds of: "wi0: tx failed, retry limit exceeded" with
the new driver under heavy load.  In addition it get many random disconnects
which I would not notice, except AIM gets logged out.  I don't think it has
anything to do with the ipsec tunnel as the SAD entries are still there and
it only happen with the new wi kernel.  I have tried FAST_IPSEC and it does
work with the new wi0 driver where it would temporarily lock up the machine
with the old one, but I'm not using it since I thought it may be causing a
problem and its ends up that it did not make a difference.  I am going to
try it later without IPSec just to be sure.

Under the new driver my card which sold as a D-link DWL-520 2.4GHz Wireless
PCI card is shown as a:
dmesg 
wi0:  mem 0xe600-0xe6000fff irq 10 at device 15.0 on
pci0
wi0: 802.11 address: 00:05:5d:fa:0e:b0
wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI)
wi0: Intersil Firmware: Primary (1.0.7), Station (1.3.6)
wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps

I can change the media through ifconfig to DS/11Mbps or whatever, but it
does not seem to change anything other then ifconfig will show "media: IEEE
802.11 Wireless Ethernet DS/11Mbps  (DS/2Mbps )" rather then
autoselect.  The same slowness is still there.  wicontrol shows it as having
a TX rate (actual speed) of 2 no matter what.  I can set the (selection) to
anything such as 11, and again no change in the throughput or anything.  I
have also changed things with the old driver, and nothing changed with the
throughput, and it also shows the (actual speed) as 2 but I get higher
throughput.  It seems to kinda have a mind of its own.  Well if you need
anymore info, just drop me a message.  I enabled debugging for wi0 as a
earlier post showed, but I had no idea what I was looking at :).

--Matt

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

Dummynet messages

[Wiktor Niesiobedzki]

Hi,

sys/netinet/ip_dummynet.c:
975:   if (q->avg >= fs->max_th) { /* average queue >=  max threshold */
(...)
984:} else {
985:q->count = -1;
986:   printf("- drop");
987:return 1 ;
989:}

is quite meaningless. Shouldn't be it at least DEB(printf("- drop")? Or 
better "drop - max_th exceeded"?

Just a small proposition, I was quite confused, when I saw this message.

Best regards,

Wiktor Niesiobedzki

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

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
===> libexec/getty
/h/des/src/libexec/getty/main.c: In function `main':
/h/des/src/libexec/getty/main.c:335: syntax error before '!' token
*** Error code 1

Stop in /h/des/src/libexec/getty.
*** Error code 1

Stop in /h/des/src/libexec.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

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

Re: OpenOffice swriter working on -CURRENT

[walt]

Sheldon Hearn wrote:

Hi folks,

Could someone with an up-to-date -CURRENT (as of anything since
Wednesday last week) and OpenOffice let me know whether OpenOffice's
swriter works?


Mine definitely works okay, but I recompiled mine on Jan 14 just after
Martin applied some patches.  You may get better results if you rebuild
OpenOffice.


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

Re: [CFR] IPv6 support for Linux sym

[David Malone]

On Mon, Jan 20, 2003 at 12:49:26AM +0900, Hajimu UMEMOTO wrote:
> I wrote an IPv6 support for Linux sym.  I've tested it with RHL8's
> ftp(1) and ports/www/linux-phoenix, and it seems nicely running with
> both an IPv4 and an IPv6.
> You can obtain my patch from:
> 
>   http://www.imasy.or.jp/~ume/FreeBSD/linux-ipv6.diff

I have a patch which is quite similar to this, but also reduces the
use of the stackgap in the Linux networking code and breaks out
things like socket, bind and listen into an implimentation and a
syscall wrapper (extending Ian's work in this area). I took these
patches far enough to get the linux version of telnet to speak IPv6.

I was going to commit the patch, but there were two things holding
me back:

1) I hadn't figured out the best way to deal with syscalls
which copyout a sockaddr - I suspect we need a per-sysvec
sockaddr copyout function to do this cleanly, but I'm open
to suggestion.

2) The patches wouldn't compile on the alpha 'cos of some
ifdefs in the linux emulation code. I just hadn't got around
to resolving this.

Maybe we could see if we could combine these patches? My patch is
available at:

http://www.maths.tcd.ie/~dwmalone/linux-socket

David.

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

4.7-amd cannot mount exports from 5.0-RELEASE

[Michael Nottebrock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have upgraded a box from 4.7-p1 to 5.0-RELEASE. It exports all its
filesystems ( /, /usr, /var ) via NFS. A 4.7-STABLE client used to mount
in those exports on demand with amd, with the default amd-map and /net
and /host. Since the upgrade to 5.0-RELEASE on the server, amd cannot
mount the exports anymore. It hangs and after a while throws an error
similar to

amd[345]: mountd rpc failed: RPC: Timed out

in the syslog. Let me stress that the configurations of both the server
and client have not changed at all and are almost factory defaults - yet
it just ceased working. The most peculiar thing is that the 4.7-STABLE
client also mounts in /usr/ports/distfiles from the server statically -
and that still works. ..

(not subscribed to list - please CC me)

- --
Regards,
	Michael Nottebrock

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE+KvxZXhc68WspdLARAm/ZAJ99pJMyz/PjM6bx5Uuc7nLFhHg5yQCbBg3a
IaiXOMjN0iBiuCOQElnnxM4=
=FYbe
-END PGP SIGNATURE-


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

FreeBSD 5.0 Available

[Scott Long]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



It is my privilege and pleasure to announce the availability of FreeBSD
5.0-RELEASE.  The culmination of nearly three years of work, this
release starts FreeBSD on the path of advanced multiprocessor and
application thread support and introduces support for the sparc64 and
ia64 platforms.  Among the long list of new and improved features:

  - UFS2, the second generation UFS filesystem, shatters the current 1TB
filesystem barrier.
  - Background filesystem checking (bgfsck) and filesystem snapshots
eliminate the need for downtime to do filesystem repair and backup
tasks.
  - Experimental support for Mandatory Access Controls (MAC) provide
an extensible and flexible means for administrators to define system
security policies.
  - Fine-grained locking in the kernel paves the road for much higher
efficiency of multi-processor systems.
  - Support for Bluetooth, ACPI, CardBus, IEEE 1394, and experimental
hardware crypto acceleration keeps FreeBSD at the forefront of new
technology.
  - The GCC 3.2.1 compiler provides the latest installment of the
ever-improving GNU Compiler Collection.
  - GEOM, the extensible and flexible storage framework, and DEVFS,
the device virtual filesystem, simplify storage and device
management while opening the door for new enterprise storage
technologies.
  - Support for the sparc64 and ia64 platforms expands FreeBSD's
support of advanced 64-bit computing platforms.

Although FreeBSD 5.0 contains a number of new and exciting features, it
may not be suitable for all users.  More conservative users may prefer
to continue using FreeBSD 4.X.  Information on the various trade-offs
involved, as well as some notes on future plans for both FreeBSD 4.X
and 5.X, can be found in the Early Adopter's Guide, available here:

http://www.FreeBSD.org/releases/5.0R/early-adopter.html

For a complete list of new features and known problems, please see the
release notes and errata list, available here:

  http://www.FreeBSD.org/releases/5.0R/relnotes.html
  http://www.FreeBSD.org/releases/5.0R/errata.html

For more information about FreeBSD release engineering activities,
please see:

  http://www.FreeBSD.org/releng/

Availability
- 

FreeBSD 5.0-RELEASE supports the i386, pc98, alpha, sparc64, and
ia64 architectures and can be installed directly over the net using the
boot floppies or copied to a local NFS/FTP server.  Distributions for
all architectures are available now.

Please continue to support the FreeBSD Project by purchasing media
from one of our supporting vendors.  The following companies will be
offering FreeBSD 5.0 based products:

   FreeBSD Mall, Inc.http://www.freebsdmall.com/
   Daemonnews, Inc.  http://www.bsdmall.com/freebsd1.html

If you can't afford FreeBSD on media, are impatient, or just want to
use it for evangelism purposes, then by all means download the ISO
images.  We can't promise that all the mirror sites will carry the
larger ISO images, but they will at least be available from:

   ftp://ftp.FreeBSD.org/pub/FreeBSD/
   ftp://ftp12.FreeBSD.org/pub/FreeBSD/
   ftp://ftp.tw.FreeBSD.org/pub/FreeBSD/
   ftp://ftp{2,3,4,5}.jp.freebsd.org/pub/FreeBSD/
   ftp://ftp.cz.FreeBSD.org/pub/FreeBSD/
   ftp://ftp7.de.FreeBSD.org/pub/FreeBSD/
   ftp://ftp.lt.FreeBSD.org/pub/FreeBSD/
   ftp://ftp2.za.FreeBSD.org/pub/FreeBSD/
   ftp://ftp.se.FreeBSD.org/pub/FreeBSD/
   ftp://ftp{1,2,4}.ru.FreeBSD.org/pub/FreeBSD/

FreeBSD is also available via anonymous FTP from mirror sites in the
following countries: Argentina, Australia, Brazil, Bulgaria, Canada,
China, Czech Republic, Denmark, Estonia, Finland, France, Germany,
Hong Kong, Hungary, Iceland, Ireland, Japan, Korea, Lithuania,
Mitchistan, the Netherlands, New Zealand, Poland, Portugal, Romania,
Russia, Saudi Arabia, South Africa, Slovak Republic, Slovenia, Spain,
Sweden, Taiwan, Thailand, Ukraine, and the United Kingdom.

Before trying the central FTP site, please check your regional
mirror(s) first by going to:

ftp://ftp..FreeBSD.org/pub/FreeBSD

Any additional mirror sites will be labeled ftp2, ftp3 and so on.

More information about FreeBSD mirror sites can be found at:

http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.ht
ml

For instructions on installing FreeBSD, please see Chapter 2 of The
FreeBSD Handbook.  It provides a complete installation walk-through
for users new to FreeBSD, and can be found online at:

http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html

Acknowledgments
- ---

Many companies donated equipment, network access, or man-hours to
finance the release engineering activities for FreeBSD 5.0 including
The FreeBSD Mall, Compaq, Yahoo!, Sentex Communications, and
NTT/Verio.

The release engineering team for 5.0-RELEASE includes:

  Scott Long <[EMAIL PROTECTED]> Release Engineering and Building
  Bruce A. Mah <[

How to use atacontrol rebuild

[Harald Schmalzbauer]

Hello all,

I have a Dawicontrol DC100 ATA-RAIDController (HPT370).
I built a RAID1 mirror, installed FreeBSD 5.0 RC3, everithing is working
fine.
But I wanted to test this RAID1, so I unplugged the power from one dirve (2
IBM IC, 80GB).
After reconnecting the power a "atacontrol attach" didn't help. I rebooted
and rebuilt the array with the BIOS.
Then I made a "atacontrol detach 3", the drive vansihed but when I used
"atacontrol attach" I got "no drives" (the disk was physically untouched!).
Also "reinit" didn't help. Same with "rebuild". I don't get any error but
nothing happens!

Any hint appreciated!

-Harry


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

[CFR] IPv6 support for Linux sym

[Hajimu UMEMOTO]

Hi,

I wrote an IPv6 support for Linux sym.  I've tested it with RHL8's
ftp(1) and ports/www/linux-phoenix, and it seems nicely running with
both an IPv4 and an IPv6.
You can obtain my patch from:

http://www.imasy.or.jp/~ume/FreeBSD/linux-ipv6.diff

Please review it.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

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

Re: OpenOffice swriter working on -CURRENT

[Patrick Hartling]

Based on your definition of "works," I would say that mine does not.  :( 
 I just updated my -current system about 12 hours ago.

 -Patrick

Sheldon Hearn wrote:
Hi folks,

Could someone with an up-to-date -CURRENT (as of anything since
Wednesday last week) and OpenOffice let me know whether OpenOffice's
swriter works?

For me, works just implies that it starts up on a blank document before
core dumping, and then accepts at least one character of input.

Thanks,
Sheldon.

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



--
Patrick L. Hartling			| Research Assistant, VRAC
[EMAIL PROTECTED]| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/


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

Re: alpha tinderbox failure

[Mike Barcroft]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> --
> >>> Kernel build for LINT started on Sun Jan 19 03:36:18 PST 2003
> --
> ===> vinum
> "Makefile", line 4437: warning: duplicate script for target "geom_bsd.o" ignored
> /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken 
>and is not compiled with LINT"
> /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
> /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer 
>target type
> /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken 
>and is not compiled with LINT"
> /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is broken and 
>is not compiled with LINT"
> cc1: warnings being treated as errors
> /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe':
> /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant 
>conversion
> *** Error code 1

Fixed.  Peter fixed the same problem elsewhere, but must have missed
this one.

Best regards,
Mike Barcroft

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

OpenOffice swriter working on -CURRENT

[Sheldon Hearn]

Hi folks,

Could someone with an up-to-date -CURRENT (as of anything since
Wednesday last week) and OpenOffice let me know whether OpenOffice's
swriter works?

For me, works just implies that it starts up on a blank document before
core dumping, and then accepts at least one character of input.

Thanks,
Sheldon.

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

HEADSUP: CCD(4) hackery...

[Poul-Henning Kamp]

--- Forwarded Message

From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Date: Sun, 19 Jan 2003 07:00:58 -0800 (PST)
To: [EMAIL PROTECTED], [EMAIL PROTECTED]

phk 2003/01/19 07:00:58 PST

  Modified files:
sys/sys  ccdvar.h 
sys/dev/ccd  ccd.c 
  Log:
  Finally give CCD the disk mini-layer treatment:
  
  CAUTION:
  
  Previously CCD would be different from all other disks in
  the system in that there were no "ccd0" device, only a
  "ccd0c" device.
  
  This is no longer so after this commit.  If you access a
  ccd device through the "/dev/ccd0c" device _and_ have not
  actually put a BSD disklabel on the device, you will have
  to use the name "/dev/ccd0".  If your CCD device contains
  a BSD disklabel there should be no difference.
  
  You need to recompile ccdconfig(8) using the changed
  src/sys/sys/ccdvar.h for the -g "show me" option to work.
  
  I have run the regression test I created before I started
  overhauling CCD and it flags no problems, but this code
  is mildly evil, so take care.  If you would cry if you lost
  what's on CCD, make a back before you upgrade.
  
  Create separate cdevsw for the /dev/ccd.ctl device.
  
  Remove the cloning function, the disk-minilayer will do all naming
  for us.
  
  Remove the ccdunit and ccdpart functions and carry the softc pointer
  in the relevant dev_t's and structures.
  
  Release all memory when a CCD device is unconfigured, previously
  the softc would linger behind.
  
  Remove all traces of BSD disklabel fiddling code.
  
  Remove ccdpsize, the disk mini-layer does this for us.
  
  Don't allocate memory with M_WAITOK in ccdstrategy().
  
  Remove boundary checks which the disk mini-layer does for us.
  
  Don't allocate space for more than 2 ccdbuf, RAID was never implemented.
  
  NB: I have not tried to address any of the preexisting ailments of CCD.
  
  Revision  ChangesPath
  1.121 +143 -431  src/sys/dev/ccd/ccd.c
  1.15  +2 -1  src/sys/sys/ccdvar.h


--- End of Forwarded Message


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

Re: HEADS UP: new wi driver

[Magnus B{ckstr|m]

> : dstumbler breaks; on startup it reports
> : "unable to ioctl device socket: Input/output error".
>
> As root or no?

As root, with interface up and configured.

Magnus


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

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Sun Jan 19 03:03:41 PST 2003
--
>>> Kernel build for GENERIC completed on Sun Jan 19 03:36:18 PST 2003
--
>>> Kernel build for LINT started on Sun Jan 19 03:36:18 PST 2003
--
===> vinum
"Makefile", line 4437: warning: duplicate script for target "geom_bsd.o" ignored
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and 
is not compiled with LINT"
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer 
target type
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and 
is not compiled with LINT"
/h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is broken and is 
not compiled with LINT"
cc1: warnings being treated as errors
/h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe':
/h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant 
conversion
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

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

Re: MSDOS fs install problem

[Giovanni P. Tirloni]

* Anti ([EMAIL PROTECTED]) wrote:
> On Sun, 19 Jan 2003 01:25:12 -0200
> "Giovanni P. Tirloni" <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> >  I was trying to install FreeBSD -CURRENT snapshot from
> >  2003-01-16 (current.freebsd.org snapshots) and got this
> >  error
> >  
> >Error mounting /dev/ad0s1 on /dist: Operation not \
> >supported by device (19)
> >
> >  while trying to mount the slice that had FreeBSD/ on
> >  it. It happened with other snapshots too.
> >  
> >  Is it still possible to install from a MSDOS partition
> >  by default ? 
>
> sysinstall in -current could never find my msdos partition to
> install from...
 
 The partition it found (ad0s1) is the right one but it couldn't
 mount it.

 --
 Giovanni P. Tirloni
 [EMAIL PROTECTED]

 You can have anything you want if you will give up the
 belief that you can't have it. -- Robert Anthony

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