Re: [Re: NFS -current

[Steve Sizemore]

On Wed, Mar 26, 2003 at 12:18:11AM -0800, Terry Lambert wrote:
> 
> In fact, the only legitimate argument I have ever heard for UDP
> has been "I have an old Linux install that can't talk TCP, as
> only UDP was implemented at the time I installed it".

Hi, Terry -

Have you already forgotten the locking problem that you were
helping me with last week? The only solution was to use UDP.

Steve
-- 
Steve Sizemore <[EMAIL PROTECTED]>, (510) 642-8570
Unix System Manager
Dept. of Mathematics and College of Letters and Science
University of California, Berkeley
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: AC97 sound problems with current

[Scott Long]

Orion Hodson wrote:
Kevin Oberman writes:
|
| After upgrading my laptop from STABLE to CURRENT on 3/14 I have been
| having problems with GnomeMeeting. Often the sound is badly broken with
| 'spurts' of sound with silent gaps in between. This was never the case
| with STABLE. Other times it's fine.
|
| When I looked at my dmesg output I noticed some changes between STABLE
| and CURRENT for the pcm0 device. Under STABLE I only got two messages:
| pcm0:  port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at 
device 31.5 on pci0
| pcm0: 
| Under CURRENT I get a third:
|
| pcm0: measured ac97 link rate at 51200 Hz

There is a calibration step in the driver to determine the clock rate of the 
AC97 link.  What you are seeing is the calibration step failing and setting a 
bogus ac97 link rate.  I took a cursory look a couple of weeks back and it 
smelt like the timecounter initialization point changed, but haven't gotten 
around to looking closer and fixing the driver.
If this were true then I'd be very concerned.  Let me know what you
find.  For what it's worth, my ICH3 setup is still working fine when
loaded at boot, though my kernel is about 2 weeks old.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: AC97 sound problems with current

[Orion Hodson]

Kevin Oberman writes:
|
| After upgrading my laptop from STABLE to CURRENT on 3/14 I have been
| having problems with GnomeMeeting. Often the sound is badly broken with
| 'spurts' of sound with silent gaps in between. This was never the case
| with STABLE. Other times it's fine.
|
| When I looked at my dmesg output I noticed some changes between STABLE
| and CURRENT for the pcm0 device. Under STABLE I only got two messages:
| pcm0:  port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at 
device 31.5 on pci0
| pcm0: 
| Under CURRENT I get a third:
|
| pcm0: measured ac97 link rate at 51200 Hz

There is a calibration step in the driver to determine the clock rate of the 
AC97 link.  What you are seeing is the calibration step failing and setting a 
bogus ac97 link rate.  I took a cursory look a couple of weeks back and it 
smelt like the timecounter initialization point changed, but haven't gotten 
around to looking closer and fixing the driver.  It's on the todo list... I've 
also been wondering if it's possible to ditch the calibration entirely, but 
this is an involved AC97 question and I don't have easy access to the relevant 
h/w and it's a different q.

Anyway, whilst it remains broken you can set the ac97 clock rate by hand.  The 
sysctl variable hw.snd.pcmX.ac97rate exists specifically for times when the 
calibration test fails (X = 0 if no other cards installed).  Depending on 
which clock source is being used by the codec you'll want to set the variable 
to 48000 or around 55913.  YMMV, but kldloading the driver rather than having 
it compiled into the kernel will probably result in the correct calibration.

- Orion


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bluetooth on IBM T30 (USB device problem)

[Lee Damon]

Max,
(Copied to current as Max requests)

ugen is loaded at boot by default.  When I try to manually load it I get the
(expected) response:

Mar 26 16:46:47 tylendel kernel: module_register: module uhub/ugen already 
exists!
Mar 26 16:46:47 tylendel kernel: Module uhub/ugen failed to register: 17

However, the BDC isn't attaching when I press the bluetooth button.

: || tylendel.castle.org [17] ; sudo usbdevs -v -d
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x), rev 1.00
  uhub0
 port 1 powered
 port 2 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x), rev 1.00
  uhub1
 port 1 powered
 port 2 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x), rev 1.00
  uhub2
 port 1 powered
 port 2 powered


So, we're back to the USB problem.  I think maybe I should table this for a
while in the hopes that someone, somewhere, looks at and fixes the USB
problem.  (I'll be happy to help run tests and such, but I am *not* a kernel
hacker.)

nomad

> Lee,
> 
> > Kernel recompiled and now no more "_mtx_assert undefined" errors. 
> > Continuing with the directions at :
> > 
> > When I press the T30's bluetooth button I get the known USB problem, 
> > but never see the ubt0 device defined.  Instead of getting
> > 
> > ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
> > ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
> > ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3;
> >   wMaxPacketSize=49; nframes=6, buffer size=294
> > 
> > I get dead silence.  Grep'ing for it in dmesg renders:
> > 
> > : || tylendel.castle.org [8] ; dmesg | grep ubt
> > Preloaded elf module "/boot/kernel/ng_ubt.ko" at 0xc06e60a8.
> 
> Of course. Because ng_ubt(4) driver *does not* know about Bluetooth
> device inside your T30. That is why you need to find out VendorID and
> Product ID for the Bluetooth device inside your T30. You can use
> ugen(4) for that. ugen(4) driver *must* be loaded *before* you press
> the Bluetooth button. Once you press the Bluetooth button ugen(4)
> driver *must* attach to it, because it is the default driver for
> the USB devices. That is *if* USB will attach the device and you
> do not get "device problem, disabling port 1" error.
> 
> Once you have ugen(4) attached to the device run
> 
> # usbdevs -v -d
> 
> This will give you VendorID/ProductID pair. Now you are ready to
> patch ng_ubt(4) driver. Just add VendorID/ProductID to the list
> of supported devices inside USB_MATCH function (in ng_ubt.c file).
> 
> Now
> 
> 1) Recompile ng_ubt(4) module
> 2) Turn off your Bluetooth device
> 3) unload ng_ubt(4) (and ugen(4) if you loaded it by hand)
> 4) load *new* ng_ubt(4) driver
> 5) Press the Bluetooth button to activate device
> 
> If everything is working then you should get the messages from the
> ng_ubt(4) driver.
> 
> > I am presuming pressing the bluetooth button is like adding a bluetooth
> > USB device but I am lacking in actual real knowledge here.  Their
> 
> right, i think it more like plugging a new USB device.
> 
> > documentation has things like "Power on the BDC by pressing Bluetooth power 
> > switch if the Bluetooth LED is off." (BDC = Bluetooth Daughter Card).
> > When I press the button the LED does not come on.  If I press and
> > hold the button the LED will eventually flash once and then I get the
> > "uhub2: device problem, disabling port 1" message on the console yet again.
> 
> Well, it seem like when LED is on then the device is plugged, but you
> still getting the "device problem, disabling port 1" message and that
> means USB stack/hub *did not* attach/activate the device and hence no
> driver was attached to it.
> 
> You *must* get the device to attach, otherwise you can not use the
> driver. For now just try to make ugen(4) attach to the device. Once
> you get the ugen(4) to recognize the device then you should move to
> ng_ubt(4).
> 
> > In searching IBM's documentation I found that they have updated firmware 
> > for the BDC, but you have to be running windows to install it. :/  
> > 
> > Kernel source was sup'd Monday evening, US Pacific time.  Bluetooth
> > bundle is ngbt-fbsd-20030305.tar.gz.
> 
> It all does not matter at this point. Again USB *did not* attach (and
> activate) the device. The firmware inside the card and other stuff does
> not event come into play.  The simple fact that you have plugged device
> into hub does not indicate that device is working.
> 
> > I went ahead and tried to run rc.bluetooth start ubt0 in debug mode
> > and got pretty much what you'd expect when the device isn't there:
> 
> [...]
> 
> > + setup_stack ubt0 hook
> > + dev=ubt0
> > + shift
> > + hook=hook
> > + shift
> > + /usr/sbin/ngctl mkpeer ubt0: hci hook drv
> > ngctl: send msg: No such file or directory
> > + exit 1
> 
> No devic

Re: Kernel panic - never had one before, what do I do?

[Greg 'groggy' Lehey]

On Wednesday, 26 March 2003 at 13:35:28 +, Jason Morgan wrote:
> I just got a panic. As I have never had one before, I don't know what to
> do. It's on another system so I don't have to reboot immediately (that
> would solve the problem temporarily, wouldn't it?) if someone would give
> me some advice, I could try to help debug it; however, as I'm not a
> coder (not a real one anyway), I don't know how much help I would be.
>
> It's a 5.0-CURRENT system, just installed and built last week. It
> paniced right after doing a source update (not a build, just cvsup).
> The panic error is as follows:
>
> panic: mtx_lock() of spin mutex vnode interlock @
> /usr/src/sys/kern/vfs_subr.c:3187

Take a look at http://www.lemis.com/texts/panic.txt or
http://www.lemis.com/texts/panic.pdf and tell me if that helps.  This
will be going into the new edition of "The Complete FreeBSD" in a few
days time, so I'm interested in getting something which is helpful.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bluetooth on IBM T30 (USB device problem)

[Maksim Yevmenkin]

Lee,

Kernel recompiled and now no more "_mtx_assert undefined" errors. 
Continuing with the directions at 
:

When I press the T30's bluetooth button I get the known USB problem, 
but never see the ubt0 device defined.  Instead of getting

ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3;
  wMaxPacketSize=49; nframes=6, buffer size=294
I get dead silence.  Grep'ing for it in dmesg renders:

: || tylendel.castle.org [8] ; dmesg | grep ubt
Preloaded elf module "/boot/kernel/ng_ubt.ko" at 0xc06e60a8.


Of course. Because ng_ubt(4) driver *does not* know about Bluetooth
device inside your T30. That is why you need to find out VendorID and
Product ID for the Bluetooth device inside your T30. You can use
ugen(4) for that. ugen(4) driver *must* be loaded *before* you press
the Bluetooth button. Once you press the Bluetooth button ugen(4)
driver *must* attach to it, because it is the default driver for
the USB devices. That is *if* USB will attach the device and you
do not get "device problem, disabling port 1" error.
Once you have ugen(4) attached to the device run

# usbdevs -v -d

This will give you VendorID/ProductID pair. Now you are ready to
patch ng_ubt(4) driver. Just add VendorID/ProductID to the list
of supported devices inside USB_MATCH function (in ng_ubt.c file).
Now

1) Recompile ng_ubt(4) module
2) Turn off your Bluetooth device
3) unload ng_ubt(4) (and ugen(4) if you loaded it by hand)
4) load *new* ng_ubt(4) driver
5) Press the Bluetooth button to activate device
If everything is working then you should get the messages from the
ng_ubt(4) driver.
I am presuming pressing the bluetooth button is like adding a bluetooth
USB device but I am lacking in actual real knowledge here.  Their
right, i think it more like plugging a new USB device.

documentation has things like "Power on the BDC by pressing Bluetooth 
power switch if the Bluetooth LED is off." (BDC = Bluetooth Daughter 
Card).
When I press the button the LED does not come on.  If I press and
hold the button the LED will eventually flash once and then I get the
"uhub2: device problem, disabling port 1" message on the console yet 
again.
Well, it seem like when LED is on then the device is plugged, but you
still getting the "device problem, disabling port 1" message and that
means USB stack/hub *did not* attach/activate the device and hence no
driver was attached to it.
You *must* get the device to attach, otherwise you can not use the
driver. For now just try to make ugen(4) attach to the device. Once
you get the ugen(4) to recognize the device then you should move to
ng_ubt(4).
In searching IBM's documentation I found that they have updated 
firmware for the BDC, but you have to be running windows to install 
it. :/ 
Kernel source was sup'd Monday evening, US Pacific time.  Bluetooth
bundle is ngbt-fbsd-20030305.tar.gz.
It all does not matter at this point. Again USB *did not* attach (and
activate) the device. The firmware inside the card and other stuff does
not event come into play.  The simple fact that you have plugged device
into hub does not indicate that device is working.
I went ahead and tried to run rc.bluetooth start ubt0 in debug mode
and got pretty much what you'd expect when the device isn't there:
[...]

+ setup_stack ubt0 hook
+ dev=ubt0
+ shift
+ hook=hook
+ shift
+ /usr/sbin/ngctl mkpeer ubt0: hci hook drv
ngctl: send msg: No such file or directory
+ exit 1
No device - no driver - no "ubt0" Netgraph node - no Bluetooth :( Sorry

In fact, just activate the Bluetooth device (LED on) and run

# usbdevs -v -d

If device *was* activated you *must* see it, otherwise you will only
see USB hubs (and possibly other devices that have been attached).
thanks,
max
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

NIS/ssh problem -CURRENT client to 4.8-RC2 server

[Rob B]

Not sure where to send this one, but this used to work when the client was 
5.0-RC1.  The server hasn't been modified at all since the client was upped 
to -CURRENT.

Basically, the user I'm trying to logon as only exists locally on the 
server, and via NIS on the client

Client:
aylee# uname -a
FreeBSD aylee.number6 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Mar 27 
00:57:40 ES
T 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYLEE  alpha

Server:
FreeBSD erwin.number6 4.8-RC FreeBSD 4.8-RC #2: Sun Mar 16 03:35:25 EST 
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ERWIN  alpha

Logging in locally on the client is fine, as the NIS user, but I can't log 
in as the same user via ssh.
Heres the corresponding  logs from erwin (server) and aylee (client):

Mar 27 09:46:05 erwin ypserv[92]: access to master.passwd.byuid denied -- 
client
+192.168.100.30:49180 not privileged

Mar 27 09:46:04 aylee sshd[23711]: fatal: login_get_lastlog: cannot find 
account for uid[1000]

cheers,
Rob
--
A beautiful woman will enrich your life soon.
This is random quote 120 of 1254.

Distance from the centre of the brewing universe
[15200.8 km (8207.8 mi), 262.8 deg](Apparent) Rennerian
Public Key fingerprint = 6219 33BD A37B 368D 29F5  19FB 945D C4D7 1F66 D9C5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bluetooth on IBM T30 (USB device problem)

[Lee Damon]

Hi Max,

Kernel recompiled and now no more "_mtx_assert undefined" errors. 
Continuing with the directions at :

When I press the T30's bluetooth button I get the known USB problem, 
but never see the ubt0 device defined.  Instead of getting

ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3;
  wMaxPacketSize=49; nframes=6, buffer size=294

I get dead silence.  Grep'ing for it in dmesg renders:

: || tylendel.castle.org [8] ; dmesg | grep ubt
Preloaded elf module "/boot/kernel/ng_ubt.ko" at 0xc06e60a8.

I am presuming pressing the bluetooth button is like adding a bluetooth
USB device but I am lacking in actual real knowledge here.  Their
documentation has things like "Power on the BDC by pressing Bluetooth power 
switch if the Bluetooth LED is off." (BDC = Bluetooth Daughter Card).
When I press the button the LED does not come on.  If I press and
hold the button the LED will eventually flash once and then I get the
"uhub2: device problem, disabling port 1" message on the console yet again.

In searching IBM's documentation I found that they have updated firmware 
for the BDC, but you have to be running windows to install it. :/  

Kernel source was sup'd Monday evening, US Pacific time.  Bluetooth
bundle is ngbt-fbsd-20030305.tar.gz.

I went ahead and tried to run rc.bluetooth start ubt0 in debug mode
and got pretty much what you'd expect when the device isn't there:

+ logger=/usr/bin/logger -i -s -p user.err
+ kldstat=/sbin/kldstat
+ kldload=/sbin/kldload
+ sysctl=/sbin/sysctl
+ ngctl=/usr/sbin/ngctl
+ hcseriald=/usr/sbin/hcseriald
+ hccontrol=/usr/sbin/hccontrol
+ hci_debug_level=3
+ l2cap_debug_level=3
+ [ 2 -lt 2 ]
+ startstop=start
+ shift
+ dev=ubt0
+ shift
+ load_module ng_bluetooth
+ module=ng_bluetooth
+ shift
+ /sbin/kldstat -n ng_bluetooth
+ [ 1 -ne 0 ]
+ /sbin/kldload ng_bluetooth
+ [ 0 -ne 0 ]
+ load_module ng_hci
+ module=ng_hci
+ shift
+ /sbin/kldstat -n ng_hci
+ [ 1 -ne 0 ]
+ /sbin/kldload ng_hci
+ [ 0 -ne 0 ]
+ load_module ng_l2cap
+ module=ng_l2cap
+ shift
+ /sbin/kldstat -n ng_l2cap
+ [ 1 -ne 0 ]
+ /sbin/kldload ng_l2cap
+ [ 0 -ne 0 ]
+ load_module ng_btsocket
+ module=ng_btsocket
+ shift
+ /sbin/kldstat -n ng_btsocket
+ [ 1 -ne 0 ]
+ /sbin/kldload ng_btsocket
+ [ 0 -ne 0 ]
+ ./src/share/examples/netgraph/bluetooth/rc.bluetooth stop ubt0
+ hook=hook
+ expr ubt0 : ubt\([0-9]\{1,\}\)
+ unit=0
+ [ -z 0 ]
+ setup_stack ubt0 hook
+ dev=ubt0
+ shift
+ hook=hook
+ shift
+ /usr/sbin/ngctl mkpeer ubt0: hci hook drv
ngctl: send msg: No such file or directory
+ exit 1

nomad


> Lee Damon wrote:
> > first pass at trying to follow Pav's directions.  I get as far as trying
> > to run rc.bluetooth and get the following in syslog:
> > 
> > Mar 26 11:18:34 tylendel kernel: link_elf: symbol _mtx_assert undefined
> > Mar 26 11:18:34 tylendel nomad[576]: Failed to load ng_btsocket
> 
> your kernel options do not match options in Makefile. please
> 
> 1) edit snapshot Makefile's for the modules and remove
> -DWITNESSxxx and -DINVARIANTxxx
> 
> or
> 
> 2) add options WITNESS, options WITNESS_SKIPSPIN,
> options INVARIANTS and options INVARIANTS_SUPPORT to
> your kernel config.
> 
> this is an intergration issue. i use this option to catch
> locking bugs. once code is commited this will be resolved
> automatically. some people choose to disable them because
> it improves performance.
> 
> thanks,
> max
> 
nomad
 ---   - Lee "nomad" Damon -  \
play: [EMAIL PROTECTED]or castle!nomad  \
work: [EMAIL PROTECTED]   \
/\
Seneschal, Castle PAUS./  \
"Celebrate Diversity" /\




___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

kernel broken at linux_sysvec.c

[walt]

cc1: warnings being treated as errors
/usr/src/sys/i386/linux/linux_sysvec.c: In function `linux_elf_modevent':
/usr/src/sys/i386/linux/linux_sysvec.c:928: warning: implicit declaration of function 
`linux_mib_destroy'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: gnuls-4.0_1 coredumps on CURRENT

[Claude Buisson]

Martin Moeller wrote:
> 
> The gnuls-4.0_1 program coredumps when invoked with '-l' parameter.
> Debugging shows a problem with libc:
> 
> -- BEGIN LOG --
> 
> bsdsi# gdb /usr/local/bin/gnuls
> GNU gdb 5.2.1 (FreeBSD)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386-undermydesk-freebsd"...(no debugging
> symbols found)...
> (gdb) set args -l
> (gdb) run
> Starting program: /usr/local/bin/gnuls -l
> (no debugging symbols found)...(no debugging symbols found)...
> Program received signal SIGSEGV, Segmentation fault.
> 0x28109c46 in strcasecmp () from /usr/lib/libc.so.5
> 
> -- END LOG --
> 
> Is anyone experiencing the same problem?
> 

Me too...

I get rid of this problem by forcing the use of gettext from ports,
with the following patch to the Makefile:


--- Makefile.orig   Wed Mar 26 23:59:02 2003
+++ MakefileWed Mar 26 23:59:50 2003
@@ -16,7 +16,12 @@
 MAINTAINER=[EMAIL PROTECTED]
 COMMENT=   GNU colorized `ls'
 
+LIB_DEPENDS=   intl.4:${PORTSDIR}/devel/gettext
+
 GNU_CONFIGURE= yes
+CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
+   LDFLAGS="-L${LOCALBASE}/lib"
+
 MAN1=  gnuls.1 dircolors.1 dir.1 vdir.1
 
 .include 


> Regards,
> Martin
> 

Hope this help,

Claude Buisson
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: "READ_BIG command timeout" on CDROM drive

[BelletJr]

>> Hi all!
>> 
>> When I read cdroms with fbsd 5.0, the following message appears in the 
>> console very often (it seems to happen with every cdrom I try):
>> 
>>>acd0: READ_BIG command timeout - resetting
>>>ata0: resetting devices ..
>>>done
>> 
>> 
>> It is repeated indefinitely and I can't kill -9 the process that is trying 
to 
>> read the cdrom.
>> "umount -f /cdrom" also gets stuck and doesn't write any error messages.
>> 
>> The driver in use is cd9660: RockRidge Extension.
>> 
>> I have to reboot to have access to the cdrom drive again. And besides, the 
>> shutdown process does not end every time when the system is in this state.
>> 
>> Is there a means to have access to the cdrom drive again without rebooting?
>> I have not seen any bug report for this problem; am I right?
>
>Just wanted to report that I fixed this problem by adding:
>
>hw.ata.atapi_dma="1"# Run the CD-ROM/DVD in DMA mode
>
>to /boot/loader.conf.  The system was trying to access the drive using 
>PIO4 rather than DMA and crapping out.  I got the idea from another 
>thread today with the subject "playing mp3's and burning a cd".  Just an 
>FYI.
>
>-Scott

Thanks for the tip, Scott.

I added the line to loader.conf, rebooted and verified the value with sysctl. 
After plenty of successful read accesses to cdroms, I was about to think it 
corrected the problem on my box too. But unfortunately, it occured again.
It does not happen as often as before; it seems it happens only with cdroms 
holding errors. But the symptoms and the solution (shutdown and reboot) 
remain the same :-(



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: optimization/10189: pentium4 breaks suns libm code for__ieee754_pow(double x, double y)

[Alexander Leidinger]

On 26 Mar 2003 13:01:18 -
[EMAIL PROTECTED] wrote:

> Synopsis: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)

[...]

>  FreeBSD src tree; and (c) that really cares about building FreeBSD
>  src with special CPU settings (do you guys really see enough speedup
>  to warrant this extra nightmare? ;-)

Without knowing anything about the FreeBSD related PRs in the gcc PR
database I just comment on the last part of the quoted sentence...

The official "allowed" optimization is "-O". But it is as easy as
setting 'CFLAGS=-my-special-optim' in /etc/make.conf and start "make
buildworld" in /usr/src to rebuild the userland with new optimizations.
And trust me, as long as gcc ships with a description of other
optimizations beneath "-O" there will be (clueless or smart... does it
really matter here?) people which will try those optimizations on
everything (after I managed to convince the Linux version of icc to
generate FreeBSD object files and committed a port into our ports
collection one of the first questions was "Are we are able to build the
userland/kernel with it?", and now after icc is also able to link files
without the help of gcc they ask "How much does it gain us to build the
userland/kernel with icc?", even if it isn't possible to use icc to
build the entire (or even large parts of the) kernel/userland yet). So
it isn't a matter of "does it improve things if I do it this way" or "is
it possible to do it this way", it's a matter of "how many PRs does it
generate when -march=pentium4 breaks something but other -march=pentiumX
optimizations don't"...

Thanks for your insightful mail,
Alexander.

-- 
0 and 1. Now what could be so hard about that?

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

AC97 sound problems with current

[Kevin Oberman]

After upgrading my laptop from STABLE to CURRENT on 3/14 I have been
having problems with GnomeMeeting. Often the sound is badly broken with
'spurts' of sound with silent gaps in between. This was never the case
with STABLE. Other times it's fine.

When I looked at my dmesg output I noticed some changes between STABLE
and CURRENT for the pcm0 device. Under STABLE I only got two messages:
 pcm0:  port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at device 31.5 
on pci0
 pcm0: 
Under CURRENT I get a third:

 pcm0: measured ac97 link rate at 51200 Hz
But the link rate jumps all over the place:
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 5595 Hz
 pcm0: measured ac97 link rate at 51200 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 102400 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 5976 Hz
 pcm0: measured ac97 link rate at 95997 Hz
 pcm0: measured ac97 link rate at 96051 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 1534082 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 1541008 Hz
 pcm0: measured ac97 link rate at 1527218 Hz
 pcm0: measured ac97 link rate at 1536384 Hz
 pcm0: measured ac97 link rate at 1526080 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 95997 Hz
 pcm0: measured ac97 link rate at 96028 Hz
 pcm0: measured ac97 link rate at 95961 Hz
 pcm0: measured ac97 link rate at 96033 Hz
 pcm0: measured ac97 link rate at 95961 Hz
 pcm0: measured ac97 link rate at 90331 Hz
 pcm0: measured ac97 link rate at 22755 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 20480 Hz
 pcm0: measured ac97 link rate at 25600 Hz

While I don't know anything about DSPs in general or the AC97, this
looks most odd. The ones around 96 KHz look reasonable, I guess, but I
have a hard time believing >200 MHz or <6 KHz.

Has anyone else with an ICH3 chip set seen this? Any idea what might be
going on here?

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: optimization/10189: pentium4 breaks suns libm code for__ieee754_pow(double x, double y)

[Loren James Rittle]

> Beautiful email!!

Thanks David but, although the exact words are mine, I felt deja vu
while writing them.  I have been asked to contribute it to the gcc bug
reporting docs as a warning against using the compiler in novel modes
unless you actually first test it as I will describe.  Then we will
ask all reporters of CPU switch PRs whether they did or can do that
test before attempting to stare at a full package/kernel failure mode.

I will attempt to be a little more pro-active in watching the GNATS at
gcc.gnu.org for FreeBSD.  There appears to be an near endless supply
of people that wish to add these CPU flags to kernel builds. ;-)

>> Special secret #2:  Although the FSF-side does want to improve all
>> code generation (and I think proper PRs RE CPU switches will be
>> looked at by someone given enough time) be aware that -O2 without
>> special arch flags is probably the most stable for any given CPU
>> for any given gcc release.  Do you really want to trust a kernel
>> built with optimization flags and arch flags that near zero or zero
>> people have fully tested?  Doubtful.  However, inline with secret
>> #1 and by virtual of being digital, if even one person tests it
>> (i.e. yourself) and it appears OK, then it is probably safe to at
>> least attempt to build a kernel and run it.
 
> FreeBSD has for years recommended -O[1] vs. -O2.  Do you think there is
> value in having the GCC test suite runs you do at FreeBSD.org do runs
> with both settings?

Actually (slight backpettle), all of the modern DG test suite in gcc
are run at the broad range of -O0,1,2,3.  OTOH, by default, everyone
is bootstrapping the compiler at -O2 everyday.

> To also do runs with the newer CPU types?

This would be quite revealing.  I would like to extend the automatic
regression checkers to cover that but, yow, I'm already eating a lot
of cycles on those machines.  Added to list of things to check.

Regards,
Loren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IP stack problem -- possibly mac-related

[Daniel C. Sobral]

X marks the spot.

Robert Watson wrote:
On Mon, 24 Mar 2003, Daniel C. Sobral wrote:


The messages below are from today's kernel + mac_mls and mac_biba
kld-loaded from loader(8). None of the warning appear if these modules
are not loaded (I haven't tried not loading one and then the other, but
I can do it on request) 
...

malloc() of "128" with the following non-sleepablelocks held:
exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ 
/usr/src/sys/netinet/udp_usrreq.c:1034
exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ 
/usr/src/sys/netinet/udp_usrreq.c:1027


Hmm.  I think there's a witness flag to generate stack traces when giving
out these sorts of warnings -- debug.witness_trace I think.  Can you try
turning that on in loader.conf and see if we get some additional
information?  The only MAC call in udp_output() is
mac_create_mbuf_from_socket(), which isn't supposed to result in memory
allocation.  That should only happen when the mbuf itself is allocated.  A
stack trace might narrow down the source of the problem.
Thanks,

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


--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"I didn't know it was impossible when I did it."
malloc() of "128" with the following non-sleepablelocks held:
exclusive sleep mutex radix node head r = 1 (0xc262507c) locked @ /usr/src/sys/n
et/route.c:549
Debugger("witness_warn")
Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db> trace
Debugger(c031017c,cdccd920,1,c01e1a5d,c0472780) at Debugger+0x54
witness_warn(5,0,c033579a,c0324ee1,c03290a8) at witness_warn+0x1a0
uma_zalloc_arg(c083cd80,0,104,246,c0353260) at uma_zalloc_arg+0x53
malloc(70,c0472780,104,cdccd98c,c046ed20) at malloc+0xd4
mls_alloc(4,c0472a60,c0ee3d30,cdccd9b0,c01d1776) at mls_alloc+0x26
mac_mls_init_label_waitcheck(c0ee3d30,4,c0324cf0,2d0,c0ee3d00) at mac_mls_init_l
abel_waitcheck+0x20
mac_init_mbuf(c0ee3d00,4,1,0,0) at mac_init_mbuf+0xb6
m_gethdr(4,1,cdccd9f0,cdccda4c,5c) at m_gethdr+0x7f
rt_msg1(1,cdccda50,20005,0,c26c2500) at rt_msg1+0x79
rt_missmsg(1,cdccda50,20405,0,0) at rt_missmsg+0x2a
rtalloc1(c25fc7ec,1,1,cdccdacc,c01dfd54) at rtalloc1+0x165
rt_setgate(c26c2400,c25fc7dc,c25fc7ec,225,3) at rt_setgate+0x1d8
rtrequest1(1,cdccdb40,cdccdb38,c25fc800,0) at rtrequest1+0x2c9
route_output(c0ee3e00,c280d700,80,c0ee3e00,1f80) at route_output+0x246
raw_usend(c280d700,0,c0ee3e00,0,0) at raw_usend+0x7d
rts_send(c280d700,0,c0ee3e00,0,0) at rts_send+0x35
sosend(c280d700,0,cdccdc7c,c0ee3e00,0) at sosend+0x4bd
soo_write(c26dab04,cdccdc7c,c0eca100,0,c256c3c0) at soo_write+0x97
dofilewrite(c256c3c0,c26dab04,3,80b7340,80) at dofilewrite+0xe8
write(c256c3c0,cdccdd10,c0339162,404,3) at write+0x69
syscall(2f,2f,2f,80b739c,80) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4, FreeBSD ELF32, write), eip = 0x804b90f, esp = 0xbfbffd0c, ebp =
0xbfbffd28 ---
db> c
malloc() of "128" with the following non-sleepablelocks held:
exclusive sleep mutex radix node head r = 1 (0xc262507c) locked @ /usr/src/sys/n
et/route.c:549
Debugger("witness_warn")
Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db> trace
Debugger(c031017c,cdccd920,1,c0353260,c046a2e0) at Debugger+0x54
witness_warn(5,0,c033579a,c0324ee1,167) at witness_warn+0x1a0
uma_zalloc_arg(c083cd80,0,104,e0,c25fc700) at uma_zalloc_arg+0x53
malloc(70,c046a2e0,104,cdccd98c,c0466fa0) at malloc+0xd4
biba_alloc(4,c046a5c0,c0ee3d30,cdccd9b0,c01d1776) at biba_alloc+0x26
mac_biba_init_label_waitcheck(c0ee3d30,4,c0324cf0,2d0,c0ee3d00) at mac_biba_init
_label_waitcheck+0x20
mac_init_mbuf(c0ee3d00,4,1,0,0) at mac_init_mbuf+0xb6
m_gethdr(4,1,cdccd9f0,cdccda4c,5c) at m_gethdr+0x7f
rt_msg1(1,cdccda50,20005,0,c26c2500) at rt_msg1+0x79
rt_missmsg(1,cdccda50,20405,0,0) at rt_missmsg+0x2a
rtalloc1(c25fc7ec,1,1,cdccdacc,c01dfd54) at rtalloc1+0x165
rt_setgate(c26c2400,c25fc7dc,c25fc7ec,225,3) at rt_setgate+0x1d8
rtrequest1(1,cdccdb40,cdccdb38,c25fc800,0) at rtrequest1+0x2c9
route_output(c0ee3e00,c280d700,80,c0ee3e00,1f80) at route_output+0x246
raw_usend(c280d700,0,c0ee3e00,0,0) at raw_usend+0x7d
rts_send(c280d700,0,c0ee3e00,0,0) at rts_send+0x35
sosend(c280d700,0,cdccdc7c,c0ee3e00,0) at sosend+0x4bd
soo_write(c26dab04,cdccdc7c,c0eca100,0,c256c3c0) at soo_write+0x97
dofilewrite(c256c3c0,c26dab04,3,80b7340,80) at dofilewrite+0xe8
write(c256c3c0,cdccdd10,c0339162,404,3) at write+0x69
syscall(2f,2f,2f,80b739c,80) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4, FreeBSD ELF32, write), eip = 0x804b90f, esp = 0xbfbffd0c, ebp =
0xbfbffd28 ---
db> c
add net default: gateway 10.0.7.21

gnuls-4.0_1 coredumps on CURRENT

[Martin Moeller]

The gnuls-4.0_1 program coredumps when invoked with '-l' parameter.
Debugging shows a problem with libc:

-- BEGIN LOG --

bsdsi# gdb /usr/local/bin/gnuls
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-undermydesk-freebsd"...(no debugging
symbols found)...
(gdb) set args -l
(gdb) run
Starting program: /usr/local/bin/gnuls -l
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x28109c46 in strcasecmp () from /usr/lib/libc.so.5

-- END LOG --

Is anyone experiencing the same problem?

Regards,
Martin

-- 
Martin Möller http://www.bsdsi.com/
GnuPG/PGP DSA ID: 0x3C979285  ICQ # 82221572
I do not accept unsolicited commercial mail. Do not spam me!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic - never had one before, what do I do?

[Jason Morgan]

On Wed, Mar 26, 2003 at 07:49:40PM +0100, Simon L. Nielsen wrote:
> On 2003.03.26 13:35:28 +, Jason Morgan wrote:
> 
> > I just got a panic. As I have never had one before, I don't know what to 
> > do. It's on another system so I don't have to reboot immediately (that 
> Have a look at
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING
> for information on how to get more information from a panic.

OK, so I'll set up my system to capture the crash dump for next time, 
but is there anything I can do right now? I'm at the db> debugging 
prompt, but I have not been provided with a panic message as shown in 
the first example. Is there a command to get this output?

Jason

> 
> -- 
> Simon L. Nielsen


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic - never had one before, what do I do?

[Simon L. Nielsen]

On 2003.03.26 13:35:28 +, Jason Morgan wrote:

> I just got a panic. As I have never had one before, I don't know what to 
> do. It's on another system so I don't have to reboot immediately (that 
Have a look at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING
for information on how to get more information from a panic.

-- 
Simon L. Nielsen


pgp0.pgp
Description: PGP signature
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bluetooth on IBM T30 (USB device problem)

[The Anarcat]

On mer mar 26, 2003 at 09:38:57 -0800, Maksim Yevmenkin wrote:
> Hello Lee,
> 
> >I'm playing with Bluetooth on my T30 as well.  I've activated legacy
> >USB support in BIOS, but still get
> >
> >   Mar 26 08:41:03 tylendel kernel: uhub2: device problem, disabling port 1

Just a "me too".. somehow: I've seen this happen with my Acer Flatbed
scanner. It would just jam while scanning, xscanimage would hang and
I'd see that exact same message on my console.

Nothing short of rebooting would solve this.

A.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Kernel panic - never had one before, what do I do?

[Jason Morgan]

I just got a panic. As I have never had one before, I don't know what to 
do. It's on another system so I don't have to reboot immediately (that 
would solve the problem temporarily, wouldn't it?) if someone would give 
me some advice, I could try to help debug it; however, as I'm not a 
coder (not a real one anyway), I don't know how much help I would be.

It's a 5.0-CURRENT system, just installed and built last week. It 
paniced right after doing a source update (not a build, just cvsup). 
The panic error is as follows:

panic: mtx_lock() of spin mutex vnode interlock @ 
/usr/src/sys/kern/vfs_subr.c:3187

Thanks,
Jason
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: optimization/10189: pentium4 breaks suns libm code for__ieee754_pow(double x, double y)

[David O'Brien]

On Wed, Mar 26, 2003 at 01:01:18PM -, [EMAIL PROTECTED] wrote:
> Synopsis: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)

Beautiful email!!
 
> Special secret #2:  Although the FSF-side does want to improve all
> code generation (and I think proper PRs RE CPU switches will be
> looked at by someone given enough time) be aware that -O2 without
> special arch flags is probably the most stable for any given CPU
> for any given gcc release.  Do you really want to trust a kernel
> built with optimization flags and arch flags that near zero or zero
> people have fully tested?  Doubtful.  However, inline with secret
> #1 and by virtual of being digital, if even one person tests it
> (i.e. yourself) and it appears OK, then it is probably safe to at
> least attempt to build a kernel and run it.

FreeBSD has for years recommended -O[1] vs. -O2.  Do you think there is
value in having the GCC test suite runs you do at FreeBSD.org do runs
with both settings?  To also do runs with the newer CPU types?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bluetooth on IBM T30 (USB device problem)

[Maksim Yevmenkin]

Hello Lee,

I'm playing with Bluetooth on my T30 as well.  I've activated legacy
USB support in BIOS, but still get
   Mar 26 08:41:03 tylendel kernel: uhub2: device problem, disabling port 1

maybe 45-60 seconds after pressing the Bluetooth button.

I'm running a kernel and world sup'd yesterday afternoon.  ugen is
included in the kernel config.   I will be heading to the archives 
of the mobile list in a second to see if I'm missing anything else.
just like i said, this is a USB issue, not Bluetooth.

could anyone from FreeBSD USB people *please* comment on that?
i still have all traces available at
http://www.geocities.com/m_evmenkin/usb/

in fact this option stop working for me today :( i do not know what
happend but it worked a couple of times yesterday and now i'm back
to "device problem, disabling port 1"
thanks,
max
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bluetooth on IBM T30 (USB device problem)

[Lee Damon]

I'm playing with Bluetooth on my T30 as well.  I've activated legacy
USB support in BIOS, but still get

   Mar 26 08:41:03 tylendel kernel: uhub2: device problem, disabling port 1

maybe 45-60 seconds after pressing the Bluetooth button.

I'm running a kernel and world sup'd yesterday afternoon.  ugen is
included in the kernel config.   I will be heading to the archives 
of the mobile list in a second to see if I'm missing anything else.

nomad

> --On Tuesday, March 25, 2003 13:25:47 -0800 Maksim Yevmenkin 
> <[EMAIL PROTECTED]> wrote:
> 
> > Tobias,
> >
> >>> yes it is a CSR chip based device. can you tell if its a USB device?
> >>
> >> yes, it is usb. windows clearly states it as usb.
> >
> > good. then you will most likely get it to work. if you
> > get it to attach (see below).
> >
> >>> 1) at loader prompt type (without quotes) "boot -v"
> >>> 2) do not press the Bluetooth button just yet
> >>> 3) wait until system is fully loaded
> >>> 4) kldload ugen (this is only required if you do not have
> >>>   "device ugen" the in the kernel config file)
> >>> 5) press the Bluetooth button
> >>
> >> did 1), then 5)
> >>
> >> ugen did not attach, instead I got an error. see the attached
> >> files, the error is at the bottom of dmesg.
> >
> > Mar 25 21:59:36 angel5 kernel: uhub2: device problem, disabling port 1
> I had a similar (USB) issue on my Fujitsu Laptop, until I **ENABLED** the 
> USB Floppy
> option in my BIOS.  Don't ask me why that fixed it, but ANY USB device I 
> plugged in would
> garner the above response without that option being set.
> 
> Just another data point.  (BTW, 4-STABLE, if it matters).
> 
> 
> 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
nomad
 ---   - Lee "nomad" Damon -  \
play: [EMAIL PROTECTED]or castle!nomad  \
work: [EMAIL PROTECTED]   \
/\
Seneschal, Castle PAUS./  \
"Celebrate Diversity" /\


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

dump -L / restore question

[Bjoern A. Zeeb]

Hi,

I had tried a full dump , newfs and retore cycle on one of my HEAD
machine.

As the file systems were mounted I used dump -L.

On restore I got one of these per file system:

expected next file 23553, got 7809

I know what this meens (according to man pages and sources [though the
assumption that next incremental will pick it in restore sources is a
bit misleading as if this is the last dump this will not happen at the
time we restore ;-) ]).

My question is

a) why does this still happen with -L ? Is this ok ?
b) as this is excatly one single file per file system - what is it ?

-- 
Greetings

Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: several background fsck panics

[Matthias Schuendehuette]

Terry Lambert wrote:

> The issue with the repeating background fsck's is important.
> I suggest a counter that gets reset to zero each time the
> FS is marked clean by fsck, and incremented each time the
> background fsck process is started.

> When this counter reaches a predefined value (I sugest a
> command line option to background fsck, which defaults to
> "3", if left unspecified), then the fsck is automatically
> converted to a foreground fsck.

> This counter would be recorded in the superblock.

This sounds like a good idea! I vote for a counter of "2"... :-)

Also I suggest to mention as clearly as possible, that operating Soft 
Updates with Write Cache enabled is kind of 'out of specs'. This cannot 
work when crashing! (As you stated clearly!) So I'm also voting for 'WC 
disable' for any kind of disks. SCSI-disks don't need it because of 
Tagged Queuing and only those ATA-Disks that *have* TQ can/should be 
operated 'the fast way' - hoping that Soeren gets it working again... 
:-/
-- 
Ciao/BSD - Matthias

Matthias Schuendehuette , Berlin (Germany)
Powered by FreeBSD 5.0-CURRENT

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

softupdates panic?

[Maxim Konovalov]

Hello,

Today -current, 100% reproducable.

Script started on Wed Mar 26 18:17:44 2003
golf# gdb kernel.2603 -k vmcore.29
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x000a
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc02efaf0
stack pointer   = 0x10:0xe1dfea88
frame pointer   = 0x10:0xe1dfea8c
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 = 3463 (zsh)
trap number = 12
panic: page fault
Uptime: 5m52s
Dumping 511 MB
ata0: resetting devices ..
done
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]  16[CTRL-C to abort] [CTRL-C to 
abort] [CTRL-C to abort]  32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 
288 304 320 336 352 368 384 400 416 432 448 464 480 496
---

warning: cannot find file for module nvidia.ko

Error while mapping shared library sections:
nvidia.ko: No such file or directory.
Reading symbols from /boot/kernel/if_fxp.ko...done.
Loaded symbols for /boot/kernel/if_fxp.ko
Reading symbols from /boot/kernel/miibus.ko...done.
Loaded symbols for /boot/kernel/miibus.ko
Reading symbols from /boot/kernel/random.ko...done.
Loaded symbols for /boot/kernel/random.ko
Error while reading shared library symbols:
nvidia.ko: No such file or directory.
Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/sysvshm.ko...done.
Loaded symbols for /boot/kernel/sysvshm.ko
Reading symbols from /boot/kernel/sysvsem.ko...done.
Loaded symbols for /boot/kernel/sysvsem.ko
Reading symbols from /boot/kernel/sysvmsg.ko...done.
Loaded symbols for /boot/kernel/sysvmsg.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/ipfw.ko...done.
Loaded symbols for /boot/kernel/ipfw.ko
Reading symbols from /boot/kernel/nfsserver.ko...done.
Loaded symbols for /boot/kernel/nfsserver.ko
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt full
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:239
No locals.
#1  0xc023614a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
No locals.
#2  0xc02363f3 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
td = (struct thread *) 0xc477b3c0
bootopt = 260
newpanic = 1
buf = "page fault", '\0' 
#3  0xc0353bf2 in trap_fatal (frame=0xe1dfea48, eva=0)
at /usr/src/sys/i386/i386/trap.c:843
code = 16
type = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27,
  ssd_dpl = 0, ssd_p = 1, ssd_xx = 3, ssd_xx1 = 2, ssd_def32 = 1, ssd_gran = 1}
#4  0xc03538d2 in trap_pfault (frame=0xe1dfea48, usermode=0, eva=4294901770)
at /usr/src/sys/i386/i386/trap.c:757
va = 4294901760
vm = (struct vmspace *) 0x0
map = (struct vm_map *) 0xc082f000
rv = 1
---Type  to continue, or q  to quit---
ftype = 1 '\001'
td = (struct thread *) 0xc477b3c0
p = (struct proc *) 0xc478d800
#5  0xc035346d in trap (frame=
  {tf_fs = 24, tf_es = -1069547504, tf_ds = -505479152, tf_edi = 0, tf_esi = 0, 
tf_ebp = -505419124, tf_isp = -505419148, tf_ebx = -65536, tf_edx = -998168100, tf_ecx 
= -65536, tf_eax = -998168192, tf_trapno = 12, tf_err = 0, tf_eip = -1070662928, tf_cs 
= 8, tf_eflags = 66195, tf_esp = 0, tf_ss = -505419092})
at /usr/src/sys/i386/i386/trap.c:444
td = (struct thread *) 0xc477b3c0
p = (struct proc *) 0xc478d800
sticks = 0
i = 0
ucode = 0
type = 12
code = 0
eva = 4294901770
#6  0xc0344078 in calltrap () at {standard input}:96
No locals.
#7  0xc02f6928 in softdep_update_inodeblock (ip=0x, bp=0xce643030,
waitfor=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4681
inodedep = (struct inodedep *) 0xc4812980
wk = (struct worklist *) 0x
---Type  to continue, or q  to quit---
error = 0
gotit = -65536
#8  0xc02e7702 in ffs_update (vp=0xc4636490, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:109
fs = (struct fs *) 0xc41a7000
bp = (struct buf *) 0xce643030
ip = (struct inode *) 0xc4632990
error = 0
#9  0xc03018c8 in ufs_inactiv

Re: optimization/10189: pentium4 breaks suns libm code for__ieee754_pow(double x, double y)

[ljrittle]

Synopsis: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)

State-Changed-From-To: open->feedback
State-Changed-By: ljrittle
State-Changed-When: Wed Mar 26 13:01:17 2003
State-Changed-Why:
(Noting where this response was set to go, I decided to indulged to send an 
updated general statement on this matter of when it is even sane to set the exact CPU. 
 It is not my goal to stop the flow of related PRs from the [EMAIL PROTECTED] to the 
[EMAIL PROTECTED]  Rather, I hope it will help those that bother to read and fully 
understand it since there is a minor disconnect between expectations and SOPs.  I feel 
I know much less about any one piece than many others, but I think there is a basic 
outline of steps and points of information that will help improve the PR flow from 
freebsd.org to gcc.gnu.org.  I am speaking for myself here but I am speaking after 
having personally gone through all the open PRs registered in the gcc GNATs which 
matched FreeBSD.)

FYI, this PR (which looks somewhat important to me) would probably not be looked 
at by anyone at this end since it is in the wrong form.  The PR submitter that helps 
himself gets more help. (This is the same informal rule as the freebsd.org side but 
you must assume that people that can really help you at this end don't even have full 
and direct access to freebsd-src.  I estimate that maybe 3 people who read gcc.gnu.org 
GNATs will have the access and the skill set to review a freebsd PR which requires any 
construction; however, if it is a CPU-specific problem or in any way "below the libc" 
line, then the number drops to about 1 or more likely zero.)  You need to provide a 
complete, self-contained test case (this usually means "preprocessed").  Once you do 
that, the number of people that can easily look at your test case increases *greatly* 
(anything over 0 is a great increase ;-).  Now, in this particular case, I'd be 
capable of putting it in the right form and reposting i
 t since I have the freebsd-src CVS repo handy; however, I am not capable of seeing 
the problem since I don't have a P4 (thus nor the real motivation).  Someone with (a) 
a P4; (b) easy access to full FreeBSD src tree; and (c) that really cares about 
building FreeBSD src with special CPU settings (do you guys really see enough speedup 
to warrant this extra nightmare? ;-)

I will now reveal the special secret #1: Have you (I mean all of you that wish to 
build FreeBSD kernels, libm, libc and/or FreeBSD applications with non-standard CPU 
settings) actually run the entire gcc testsuite with the extra CPU options?  I suggest 
that if you see *any* extra failures between 'make -sk check' and e.g.
make -sk check 'RUNTESTFLAGS=--target_board unix{-march=pentium4}'
then it is quite likely you have a basic problem to address before you ever 
possibly consider trusting a kernel, library or application built with the pet CPU 
switch.  As a bonus, your test case is much smaller.  E.g. (no basis in fact) 
"gcc.dg/20011214-1.c fails with -march=pentium4"
is a very concise statement of a problem.  A gcc maintainer that cares about, e.g. 
P4 but perhaps not FreeBSD, may take an interest in that report whereas "pentium4 
breaks suns libm code for __ieee754_pow"
really has little or no contextual meaning over here especially when the referred 
test case is not easy to assemble outside your environment.  It might also be the case 
that there is a problem with the mapping to the arch-layer in gcc from the OS-support 
layer that is royally breaking just one CPU (it has been known to happen ;-).  If you 
run the testsuite, then it will stick out like like a sore thumb.  Now, I grant it is 
possible that there will be no extra gcc testsuite failures for a CPU arch flag even 
when the kernel would be subtly broken when built with that arch flag.  This is 
actually unlikely in my experience, a whole profile of gcc test cases will light up 
when I break something.

Special secret #2:  Although the FSF-side does want to improve all code generation 
(and I think proper PRs RE CPU switches will be looked at by someone given enough 
time) be aware that -O2 without special arch flags is probably the most stable for any 
given CPU for any given gcc release.  Do you really want to trust a kernel built with 
optimization flags and arch flags that near zero or zero people have fully tested?  
Doubtful.  However, inline with secret #1 and by virtual of being digital, if even one 
person tests it (i.e. yourself) and it appears OK, then it is probably safe to at 
least attempt to build a kernel and run it.

Perhaps I have a misconception but are the mass of people attempting
to build random applications from ports or libraries or the kernel with special 
flags actually first testing as I propose above?  I have to doubt it given the form of 
PR submissions.  What looks like a bit of extra work on your end (actually testing the 
base compil

Re: NFS -current

[Ian Dowse]

In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>Ian Dowse wrote:
>> It is normal enough to get the above 'not responding' errors
>> occasionally on a busy fileserver, but only if they are almost
>> immediately followed by 'is alive again' messages.
>
>This is arguably a bug in the FreeBSD UDP packet reassembly code
...

Actually, I was referring here to an effect that occurs when the
time taken by the server to complete requests varies in a particular
way. The NFS client may observe a large number of requests all
answered within a few milliseconds, so it starts using short timeouts.

Then for some reason (usually a long list of outstanding disk-intensive
operations), the server takes a few seconds to complete the next
request. Within this time, the client repeatedly times out, retransmits
the request, backs off and repeats, and in extreme cases it is
possible for the client to reach the limit that triggers the "not
responding" warning.

Ian
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NFS -current

[Patric Mrawek]

Ian Dowse wrote:

> >On several clients (-DP1, -DP2, 4-stable) mounting a nfs-share
> >(mount_nfs -i -U -3 server:/nfs /mnt) and then copying data from that
> >share to the local disk (find -x -d /mnt | cpio -pdumv /local) results
> >in lost NFS-mount.
> >
> >client kernel: nfs server server:/nfs: not responding 10 > 9
> 
> I'm not sure what you mean by a "lost" mount. Do all further accesses
> to the filesystem hang?

I meant there's no response from the nfs-server. I can interrupt the
»find | cpio« and restart it. When restarting directly after that it
will hang too, but if I wait for about 30 seconds and restart it, the
same amount of data is copied.

> It is normal enough to get the above 'not responding' errors
> occasionally on a busy fileserver, but only if they are almost
> immediately followed by 'is alive again' messages.

There's only one client and the server isn't busy.

> If the filesystem stops working and doesn't recover, could you run
> `tcpdump -nepX -s 1600 udp port 2049' when it hangs and record a
> few packets?

I'll send you private email.

(Doing the same on an loopback mounted filesystem on the server itself
works fine.)

Patric
-- 
The problem with troubleshooting is that trouble shoots back.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vinum broken by devstat changes?

[Harti Brandt]

On Tue, 25 Mar 2003, Kenneth D. Merry wrote:

KDM>On Wed, Mar 26, 2003 at 11:06:52 +1030, Greg 'groggy' Lehey wrote:
KDM>> On Tuesday, 25 March 2003 at 18:44:03 +0100, Hartmut Brandt wrote:
KDM>> >
KDM>> > Hi,
KDM>> >
KDM>> > when calling 'vinum start' it responds with
KDM>> >
KDM>> > usage: read drive [drive ...]
KDM>> >
KDM>> > from looking at the code, it appears that it cannot find the disk drives
KDM>> > to read the configuration from.
KDM>> >
KDM>> > vinum read da0 da1
KDM>> >
KDM>> > just works.
KDM>> >
KDM>> > So what's the problem? (kernel and user land from today)
KDM>>
KDM>> Check vinum(8), function vinum_start (in
KDM>> /usr/src/sbin/vinum/commands.c).  It's possible that the changes have
KDM>> broken some of the tests, probably of stat->device_type.  I can't
KDM>> think it's too difficult to fix.
KDM>
KDM>disk_create() now creates the devstat entry for disks, but defaults
KDM>everything to be a direct access (with no interface type).
KDM>
KDM>I've got patches in progress to fix that, but it looks like things should
KDM>work with the current state of affairs.
KDM>
KDM>Have you rebuilt world?

That was just a fresh world and kernel. It took me some time to get it up
again - the vinum partition holds the ports for my other machines. I just
have no time to work on this...

KDM>It looks like vinum(8) doesn't include a call to devstat_checkversion(), so
KDM>it's possible you've got a version mismatch but no way to know it.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Returned mail--"window.open("

[Peter Wemm]

postmaster wrote:
> 
>The following mail can't be sent to [EMAIL PROTECTED]:
>From: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: window.open(
>The file is the original mail

OK, thats impressive.. :-]

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

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [Re: NFS -current

[Terry Lambert]

Dan Nelson wrote:
> UDP works just fine on a switched network.  On my NFS servers I use an
> 8k rsize/wsize and UDP mounts on everything and have relatively few
> dropped fragments.

I'm not sure Ian's network is as reliable.  8-).

Nevertheless, you really do not want to use UDP for NFS with
a packet size larger than the MTU, relying on the fragment
reassembly, if you can avoid it.

The first problem is that the only NAK mechanism require that
the entire set of datagrams be discarded, and there is no
proactive discard for the datagrams in the reassembly queue
for the partial set that was received previously, prior to
an explicit request for retransmission.

Even assuming a perfect delivery media, such as in a switched
network in an area without electrical interference, and no
overloading to result in dropped packets, UDP is less efficient,
with an overdriven window, than TCP.

The main reason for this is that the TCP window is generally
larger than the commonly used rsize/wsize of 8K.  In addition,
with UDP, the transactions are all request/response, which
means you can't go onto the next 8K until the prior 8K was
received, whereas with TCP, you can have a full windowsize of
data in the pipe.

Server based predictive read-ahead works with TCP.

UDP packets are much easier for an attacker to spoof.

UDP packets are harder to get through firewalls.

UDP is not stateful, so it renders stateful firewalls vulnerable,
if it's allowed through.

In fact, the only legitimate argument I have ever heard for UDP
has been "I have an old Linux install that can't talk TCP, as
only UDP was implemented at the time I installed it".

I can't really understand the attraction to UDP.  Maybe it has
to do with the people involved being netrek players from way
back...

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Returned mail--"window.open("

[postmaster]

   The following mail can't be sent to [EMAIL PROTECTED]:
   From: [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Subject: window.open(
   The file is the original mail
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"