Re: ENE 4-in-1 card reader
In message: <[EMAIL PROTECTED]> Lars Eggert <[EMAIL PROTECTED]> writes: : Hi, : : we've got an Asus Pundit here that has an onboard 4-in-1 memory card reader: : : [EMAIL PROTECTED]:16:1:class=0x050100 card=0x17241043 chip=0x05101524 : rev=0x00 : hdr=0x00 : vendor = 'ENE Technology Inc' : class= memory : subclass = flash : : Is there a driver for this under -current yet? What's at device 16.0? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1-RELEASE is coming
On Thu, Aug 21, 2003 at 09:40:42PM -0700, Alexander Kabaev wrote: > On Thu, Aug 21, 2003 at 07:55:00PM -0700, Alexander Kabaev wrote: > > I am about to import an official GCC 3.3.1-release into our > > source tree. Please hold your updates until 'all clear' message > > is posted. > > Done. > Does it serve as "all clear" too? ;-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: status of nsswitch.conf in current?
On Fri, Aug 22, 2003 at 12:33:45AM -0400, Richard Coleman wrote: > What is the status of nsswitch.conf in current? > > I noticed that there is a man page for "nsswitch.conf". But there is no > such file installed in /etc, nor is there an example copy in > /usr/share/examples/etc. > > I just cvsup'ed tonight (Thursday) and built world. So, I'm up to date. > Please see the ``Default source lists'' section of the nsswitch.conf(5) manpage that talks about this case. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Regarding recent spam on the list
From: "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]> > On Tue, 2003-08-19 at 18:03, Bill Moran wrote: > > Just curious if anyone knows the origin of all these auto-responses, etc. > > > > I'm seeing a lot of these on every list I'm subscribed to (not all of them > > FreeBSD related) so I was wondering if some Windows trojan is running rampant > > and using these list addresses as return addys? > > It's W32/[EMAIL PROTECTED] It's spreading *fast* > The first day it appeared, I received 8000+ virus and virus warning messages in my inbox. The only way I could stop it from filling my inbox was to change my e-mail address, and place a permanent failure code in the access table for the old address. But, our mail server was still getting a Denial of Service, since it would max out the connections to both our primary and secondary mail servers. Today I believe I have solved the problem. I wrote a couple of scripts, that retrieves the IP address from the maillog for all servers/virus infected systems that are using the old email address. Then I setup IPFW to deny access to port 25 for these IP addresses. So far IPFW is dening access to our mail servers for 30,000 Class C's (/24). Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ENE 4-in-1 card reader
Hi, we've got an Asus Pundit here that has an onboard 4-in-1 memory card reader: [EMAIL PROTECTED]:16:1:class=0x050100 card=0x17241043 chip=0x05101524 rev=0x00 hdr=0x00 vendor = 'ENE Technology Inc' class= memory subclass = flash Is there a driver for this under -current yet? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: cdcontrol no longer needs 'c' partition?
On Sun, 17 Aug 2003, 17:21-0400, Craig Rodrigues wrote: > Hi, > > With GEOM in place, is the 'c' partition for a CD device no > longer necessary for cdcontrol? At least on my system, > the CD shows up as /dev/acd0, not as /dev/acd0c. What's about CDROM environment var defined in login.conf? [ patch ] -- Maxim Konovalov, [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: GCC 3.3.1-RELEASE is coming
On Thu, Aug 21, 2003 at 07:55:00PM -0700, Alexander Kabaev wrote: > I am about to import an official GCC 3.3.1-release into our > source tree. Please hold your updates until 'all clear' message > is posted. Done. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
status of nsswitch.conf in current?
What is the status of nsswitch.conf in current? I noticed that there is a man page for "nsswitch.conf". But there is no such file installed in /etc, nor is there an example copy in /usr/share/examples/etc. I just cvsup'ed tonight (Thursday) and built world. So, I'm up to date. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
password problem with rsync
Somewhere along the line, rsync quit using the --password-file=/file/with/pw option. I have not used my script in months, and now it is not working. I pulled out the part that does the rsync, and here it is: #!/usr/local/bin/bash RSYNC_PROXY=873 passwordfile=/path/to/file/.password RSYNC_PASSWORD=`cat $passwordfile` echo "=-=-=-=-=" echo "[$RSYNC_PROXY] [$passwordfile] [$RSYNC_PASSWORD]" echo "=-=-=-=-=" rsync \ --password-file="$passwordfile" \ --archive \ --exclude="man" \ --exclude="batchftp*" \ --exclude="packages*" \ --delete \ --delete-excluded \ --perms \ --stats \ --verbose \ /source-dir-1 \ /source-dir-2 \ [EMAIL PROTECTED]:/target/dir The script works, except I continue to get the password prompt. I have tried it: * with/without "-e ssh", * with/without /source-dir-2, * as root and as myself, * moving the "--password-file" line to the first, last, middle, * both "--password-file=whatever" and "--password-file whatever" options, * removing the "--password-file" so the "RSYNC_PASSWORD" env variable work, as well as several other options. It still asks me for the password. I stay up-to-date with CVSup (tag=.), including the re-build/install, and have kept the ports as current as possible. rsync is 2.5.6_1... So was there some change in the port in the previous, say 9 months that would have chance this behavior? I don't need the daemon running, so I don't have the rsync.conf file set up -- but I didn't back when it was working. Any clues? Lee ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GCC 3.3.1-RELEASE is coming
I am about to import an official GCC 3.3.1-release into our source tree. Please hold your updates until 'all clear' message is posted. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Recent changes to AC97 files breaks sound
After the changes to: ac97.c ac97.h ac97_patch.c ac97_patch.h sound no longer works. I reverted to the previous versions of these files to get sound back. pcm0: port 0xdc00-0xdc3f,0xd800-0xd8ff mem 0xfc002000-0xfc0020ff,0xfc001000-0xfc0011ff irq 10 at device 31.5 on pci0 pcm0: -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cdcontrol no longer needs 'c' partition?
On Sun, Aug 17, 2003 at 11:27:23PM +0200, Poul-Henning Kamp wrote:
>
> Yes, the 'a' and 'c' partitions on CD drives are bogus, but this
> has nothing directly to do with GEOM, it is only a sideeffect
> of the semantic cleanups that went ahead of GEOM.
>
> The patch looks good to me, but I'd like somebody to test it
> before it gets committed. Any takers ?
Well, I tested it and it worked for me. :)
> >--- src/usr.sbin/cdcontrol/cdcontrol.c.orig Sun Aug 17 17:25:46 2003
> >+++ src/usr.sbin/cdcontrol/cdcontrol.c Sun Aug 17 17:27:49 2003
> >@@ -52,10 +52,6 @@
> > # define DEFAULT_CD_DRIVE "/dev/cd0"
> > #endif
> >
> >-#ifndef DEFAULT_CD_PARTITION
> >-# define DEFAULT_CD_PARTITION "c"
> >-#endif
> >-
> > #define CMD_DEBUG 1
> > #define CMD_EJECT 2
> > #define CMD_HELP3
> >@@ -1248,11 +1244,6 @@
> > }
> >
> > fd = open (devbuf, O_RDONLY);
> >-
> >-if (fd < 0 && errno == ENOENT) {
> >-strcat (devbuf, DEFAULT_CD_PARTITION);
> >-fd = open (devbuf, O_RDONLY);
> >-}
> >
> > if (fd < 0) {
> > if (errno == ENXIO) {
> >--- src/usr.sbin/cdcontrol/cdcontrol.1.orig Sun Aug 17 17:25:39 2003
> >+++ src/usr.sbin/cdcontrol/cdcontrol.1 Sun Aug 17 17:26:27 2003
> >@@ -185,10 +185,10 @@
> > .Ev CDROM .
> > .El
> > .Sh FILES
> >-.Bl -tag -width ".Pa /dev/mcd0c" -compact
> >-.It Pa /dev/cd0c
> >-.It Pa /dev/mcd0c
> >-.It Pa /dev/acd0c
> >+.Bl -tag -width ".Pa /dev/mcd0" -compact
> >+.It Pa /dev/cd0
> >+.It Pa /dev/mcd0
> >+.It Pa /dev/acd0
> > .El
> > .Sh AUTHORS
> > .An Jean-Marc Zucconi
> >
> >
> >
> >
> >--
> >Craig Rodrigues
> >http://crodrigues.org
> >[EMAIL PROTECTED]
> >___
> >[EMAIL PROTECTED] mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: softdep_setup_inomapdep: found inode
Hi,
my current just panicked. I think it's caused by me running
$ cdparanoia -BX 8
a bit sooner than optimal (the CD's TOC was being read by the CD-ROM drive).
FreeBSD hood.oook.cz 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Aug 19
23:53:22 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PAV i386
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0234e39 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0235218 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0324e86 in softdep_setup_inomapdep (bp=0xc7739eb0, ip=0x0, newinum=0) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:1278
#4 0xc0316682 in ffs_nodealloccg (ip=0xc27164ec, cg=0, ipref=27, mode=33188) at
/usr/src/sys/ufs/ffs/ffs_alloc.c:1611
#5 0xc0315427 in ffs_hashalloc (ip=0xc27164ec, cg=0, pref=0, size=33188,
allocator=0xc0316390 ) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1155
#6 0xc0314b3e in ffs_valloc (pvp=0xc2793000, mode=33188, cred=0xc2f69980,
vpp=0xdaf438b8) at /usr/src/sys/ufs/ffs/ffs_alloc.c:857
#7 0xc033f3a9 in ufs_makeinode (mode=33188, dvp=0xc2793000, vpp=0xdaf43be0,
cnp=0xdaf43bf4) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2357
#8 0xc033b8c9 in ufs_create (ap=0xdaf43a40) at /usr/src/sys/ufs/ufs/ufs_vnops.c:199
#9 0xc033fb78 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2792
#10 0xc029ec9e in vn_open_cred (ndp=0xdaf43bcc, flagp=0xdaf43ccc, cmode=420,
cred=0xc2f69980, fdidx=0) at vnode_if.h:118
#11 0xc029eaf0 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0) at
/usr/src/sys/kern/vfs_vnops.c:93
#12 0xc0297cb3 in kern_open (td=0xc39004c0, path=0x0, pathseg=UIO_USERSPACE,
flags=1539, mode=438) at /usr/src/sys/kern/vfs_syscalls.c:688
#13 0xc0297b40 in open (td=0x0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:654
#14 0xc03944c0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 458129845, tf_esi = 1954687339,
tf_ebp = -1077937860, tf_isp = -621527692, tf_ebx = -1077940844, tf_edx = 134528442,
tf_ecx = -1077940828, tf_eax = 5, tf_trapno = 0, tf_err = 2, tf_eip = 672039919, tf_cs
= 31, tf_eflags = 662, tf_esp = -1077941268, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1005
#15 0xc0383bad in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
#3 0xc0324e86 in softdep_setup_inomapdep (bp=0xc7739eb0, ip=0x0, newinum=0) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:1278
(kgdb) list
1273 * the cylinder group map from which it was allocated.
1274 */
1275ACQUIRE_LOCK(&lk);
1276if ((inodedep_lookup(ip->i_fs, newinum, DEPALLOC|NODELAY, &inodedep)))
{
1277FREE_LOCK(&lk);
1278panic("softdep_setup_inomapdep: found inode");
1279}
1280inodedep->id_buf = bp;
1281inodedep->id_state &= ~DEPCOMPLETE;
1282bmsafemap = bmsafemap_lookup(bp);
I have a vmcore and kernel.debug handy, can provide any information on
request.
--
Pav Lucistnik <[EMAIL PROTECTED]>
What do we know about love? Love is like a pear. Pear is sweet and have
a specific shape. Try to exactly define the shape of a pear.
-- Marigold: 50 Years Of Poetry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-CURRENT + IDE CD-burner + cdrecord = panic
Hello, Since Aug 13 or 14 (perhaps earlier but that was when I've rebuilt world/kernel and the problem started) any attempt to use cdrecord even in simulation mode leads to panic with vm_fault_copy_wired: page missing. This happens only when using cdrecord, from both ports/sysutils/cdrtools and from ports/sysutils/cdrtools-devel (both cdrdao and burncd work fine). GDB backtrace attached, though it hardly tells me anything :-( "uname -a" output: FreeBSD kushnir1.kiev.ua 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Aug 20 13:18:17 EEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KUSHNIR i386 (rebuilt last night) Regards, Vladimir ~> gdb -k /usr/obj/usr/src/sys/KUSHNIR/kernel.debug /usr/crash/vmcore.1 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: vm_fault_copy_wired: page missing panic messages: --- panic: vm_fault_copy_wired: page missing syncing disks, buffers remaining... 673 673 673 673 673 673 673 673 673 673 673 673 673 673 673 673 673 673 673 673 giving up on 566 buffers Uptime: 4m0s acd0: timeout waiting for cmd=e7 s=01 e=04 acd0: flushing device failed Dumping 191 MB ata2: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/vesa/vesa.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/vesa/vesa.ko.debug Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/if_tun/if_tun.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/if_tun/if_tun.ko.debug Reading symbols from /boot/kernel/snd_ds1.ko...done. Loaded symbols for /boot/kernel/snd_ds1.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/random/random.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/random/random.ko.debug Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/fdc/fdc.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/fdc/fdc.ko.debug Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/lpt/lpt.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/lpt/lpt.ko.debug Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/ppi/ppi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/ppi/ppi.ko.debug Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/pps/pps.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/pps/pps.ko.debug ---Type to continue, or q to quit--- Reading symbols from /boot/kernel/mga.ko...done. Loaded symbols for /boot/kernel/mga.ko Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/procfs/procfs.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/procfs/procfs.ko.debug Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/pseudofs/pseudofs.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/pseudofs/pseudofs.ko.debug Reading symbols from /boot/kernel/green_saver.ko...done. Loaded symbols for /boot/kernel/green_saver.ko Reading symbols from /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KUSHNIR/modules/usr/src/sys/modules/linux/linux.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc01aa9d0 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc01aadb8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc029a859 in vm_fault_copy_entry (dst_map=0xc0d49100, src_map=0xc0d48500, dst_entry=0xc2102d5c, src_entry=0x0) at /usr/src/sys/vm/vm_fault.c:1088 #4 0xc02a1b11 in vm_map_copy_entry (src_map=0xc0d48500, dst_map=0xc0d49100, src_entry=0xc2257528, dst_entry=0xc2102d5c) at /usr/src/sys/vm/vm_map.c:2376 #5 0xc02a1e59 in vmspace_fork (vm1=0xc0d48500) at /usr/src/sys/vm/vm_map.c:2491 #6 0xc029c32e in vm_forkproc (td=0xc1f44ab0, p2=0xc2253790, td2=0xc2250980, flags=20) at /us
Re: malloc message with nfs transfer
On Thu, 21 Aug 2003, cosmin wrote: > > Sorry, just to be clear -- is the message you're getting on the NFS > > client, or the NFS server? Could you turn on debug.witness_ddb and get a > > stack trace for the warning? > > This is on the NFS server. I turned on debug.witness_ddb, but I'm not > sure if this will help, because the system isn't locking up, or > otherwise stopping. I have tried setting a breakpoint in ddb for > 0xcef0, but it starts breaking right away. The malloc() messages > are many minutes apart. With witness_ddb turned on, the kernel should drop into ddb whenever there's a witness-related warning, which should include the warnings you mentioned in your previous e-mail. > I'm not sure if these messages indicate anything critical. I was mainly > concerned with the nfs performance. Generally speaking, WITNESS warns about potential problems, as opposed to actual problems: i.e., it warns when a deadlock "would have occurred", if the timing had been just right. This was a warning that a potentially blocking activity was performed while holding a mutex, which is generally a bad idea. A little bit more detail on the strack trace should be sufficient to track it down. Turning off WITNESS should dramatically improve performance at the risk of lowering debugging output (maybe that's not a risk :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: malloc message with nfs transfer
On Thu, Aug 21, 2003 at 02:37:34PM -0400, Robert Watson wrote: > > On Thu, 21 Aug 2003, cosmin wrote: > > > malloc() of "64" with the following non-sleepable locks held: exclusive > > sleep mutex inpr = 0 (0xcef0) locked @ > > /usr/src/sys/netinet/udp_usrreq.c:378 exclusive sleep mutex netisr lock > > r = 0 (0xc061be80) locked @ /usr/src/sys/net/netisr.c:215 > > > > I'm getting those on the console, and it seems that they only happen > > when users start an nfs transfer to the nfs exported filesystem. The > > exported filesystem is a vinum raid5 array but I don't know if that has > > anything to do with the messages. > > Sorry, just to be clear -- is the message you're getting on the NFS > client, or the NFS server? Could you turn on debug.witness_ddb and get a > stack trace for the warning? This is on the NFS server. I turned on debug.witness_ddb, but I'm not sure if this will help, because the system isn't locking up, or otherwise stopping. I have tried setting a breakpoint in ddb for 0xcef0, but it starts breaking right away. The malloc() messages are many minutes apart. I'm not sure if these messages indicate anything critical. I was mainly concerned with the nfs performance. I tried reading the developer's handbook to figure out how to make it break only when there's a malloc message but right now I'm stuck. > > > Before I upgraded from 4.8, I used to be able to send at about 8mb/s to > > the nfs exported raid5. After upgrading to 5.1-CURRENT, the maximum > > speed has been only 4mb/s. I'm wondering if the messages above have > > anything to do with the performance drop. > > You appear to have the kernel debugging features turned to high (which > will be useful for resolving this problem :-). Turn off WITNESS and > INVARIANTS and you should see a substantial performance improvement. It > may not be back up to 4.x levels -- we hope that with ongoing network > stack locking work we'll be back to 4.x (and exceed them) in the next few > months. > > Thanks, > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Lucent Technologies Orinoco Gold WiFi errors
Does anyone know if Orinoco Gold cards just don't work in 5.1-current, or if there is something special you have to do? I had the card working when I had 5.0-release without having to compile with OLDCARD. That install got really bad so I went to 5.1-release and cvsup'd to 5.1-current this morning compiling without OLDCARD. When I kill dhclient, set my ssid, then attempt to run dhclient again, it fails. I have received several error messages about bytes not clearing, the device being busy, and the input type being wrong. I'm using an IBM thinkpad T20. Any ideas on how to get the card to work? Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: malloc message with nfs transfer
On Thu, 21 Aug 2003, cosmin wrote: > malloc() of "64" with the following non-sleepable locks held: exclusive > sleep mutex inpr = 0 (0xcef0) locked @ > /usr/src/sys/netinet/udp_usrreq.c:378 exclusive sleep mutex netisr lock > r = 0 (0xc061be80) locked @ /usr/src/sys/net/netisr.c:215 > > I'm getting those on the console, and it seems that they only happen > when users start an nfs transfer to the nfs exported filesystem. The > exported filesystem is a vinum raid5 array but I don't know if that has > anything to do with the messages. Sorry, just to be clear -- is the message you're getting on the NFS client, or the NFS server? Could you turn on debug.witness_ddb and get a stack trace for the warning? > Before I upgraded from 4.8, I used to be able to send at about 8mb/s to > the nfs exported raid5. After upgrading to 5.1-CURRENT, the maximum > speed has been only 4mb/s. I'm wondering if the messages above have > anything to do with the performance drop. You appear to have the kernel debugging features turned to high (which will be useful for resolving this problem :-). Turn off WITNESS and INVARIANTS and you should see a substantial performance improvement. It may not be back up to 4.x levels -- we hope that with ongoing network stack locking work we'll be back to 4.x (and exceed them) in the next few months. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
malloc message with nfs transfer
malloc() of "64" with the following non-sleepable locks held: exclusive sleep mutex inpr = 0 (0xcef0) locked @ /usr/src/sys/netinet/udp_usrreq.c:378 exclusive sleep mutex netisr lock r = 0 (0xc061be80) locked @ /usr/src/sys/net/netisr.c:215 I'm getting those on the console, and it seems that they only happen when users start an nfs transfer to the nfs exported filesystem. The exported filesystem is a vinum raid5 array but I don't know if that has anything to do with the messages. Before I upgraded from 4.8, I used to be able to send at about 8mb/s to the nfs exported raid5. After upgrading to 5.1-CURRENT, the maximum speed has been only 4mb/s. I'm wondering if the messages above have anything to do with the performance drop. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wine fails to compile on 5.1?
Here it is: cc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O -pipe -mcpu=pentiumpro -g -o table.o table.c byacc -d -t ./sql.y byacc: e - line 69 of "./sql.y", syntax error %pure-parser ^ gmake[2]: *** [y.tab.c] Error 1 gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-20030813/dlls/msi' gmake[1]: *** [msi] Error 2 gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-20030813/dlls' gmake: *** [dlls] Error 2 *** Error code 2 :( I tried to look at this file, and I must say, I had no clue what I was looking at. Definately not C :) I'm using FreeBSD 5.1-RELEASE-p2. Ran cvsup at 8:30am PDT. Any ideas? --Charlie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ath driver still buggy.
Me and a couple of my friends work on small freebsd version for embedded systems. We all noticed that our wifi cards with atheros chip have problems with the ath driver. The system keeps on spitting out following messages before the link, that is already very slow dies: ath_rate_ctl: 54M -> 48M (0 ok, 3 err, 3 retr) ath_rate_ctl: 48M -> 36M (0 ok, 1 err, 1 retr) ath_rate_ctl: 36M -> 24M (0 ok, 1 err, 1 retr) ath_rate_ctl: 24M -> 36M (11 ok, 0 err, 0 retr) ath_rate_ctl: 36M -> 48M (23 ok, 0 err, 0 retr) ath_rate_ctl: 48M -> 36M (0 ok, 2 err, 2 retr) ath_rate_ctl: 36M -> 24M (3 ok, 7 err, 7 retr) ath_rate_ctl: 24M -> 18M (0 ok, 1 err, 1 retr) And ping requests end up with following message: ping: sendto: No buffer space available This was tested running 11a and 11g with PCMCIA and mini-PCI cards. hw.ath.hal.version: 0.9.5.2 ath0: mem 0x8801-0x8801 irq 11 at device 0.0 on cardbus1 FreeBSD 5.1-CURRENT #0: Wed Aug 20 16:59:24 CEST 2003 Any solution for that Sam? I can remember you mentioned you have fix for that a couple of weeks ago and that you will submit it in a week time or so. I have seen the problem but have been unable to resolve it. Grab a copy of /usr/src/tools/tools/ath/athstats and use it to look at the statistics kept by the driver when this happens. They may give a hint but unfortunately I think it's a problem with the anti-noise-immunity (ANI) code in the HAL and I have no time right now to dig into that. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current panic in pmap/VM
On 20-Aug-2003 Mark Murray wrote:
> John Baldwin writes:
>> > pmap_ts_referenced()
>> > vm_pageout_scan()
>> > vm_pageout()
>> > fork_exit()
>> > fork_trampoline()
>> >
>> > I'm happy to try patches if anyone has ideas.
>>
>> Having the fault address as well as the source file/line of
>> where the fault occurs could be helpful.
>
> From 2 panics, I have 2 addresses - 0xc02cbbab and 0xc02cfb9b (Custom
> kernels, so I doubt those will help).
Those are code addresses, not the faulting virtual addresses.
> The source file is src/sys/i386/i386/pmap.c, and it is in the
> pmap_ts_referenced() function (a short function) at about line 2895.
Line 2895 in my pmap.c is:
int
pmap_ts_referenced(vm_page_t m)
{
register pv_entry_t pv, pvf, pvn;
pt_entry_t *pte; here
That's not code. :) Pop up gdb -k on your kernel.debug and do
'l *0xc02cbbab' and 'l *0xc02cfb9b' to get the exact line it
faulted at.
> I'll need to put a serial debugger on to go any further. Does this
> work, or will I be wasting effort? (Getting that cable in is going
> to be a _pain_).
I don't think you need serial ddb yet.
s
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
trap 12 while installing -current
On my system -current lived for the last 2 years quite good (ok, not for my last USB probs). I thought it's time to cleanly install my system from root. So i took one of those jpsnap iso images and boot from it. Installing in the same partition (removing old slice, creating new etc). My new fs is UFS2 with soft updates (but without it crashes, too). After about 2% of copying the base files, the kernel panics with trap type 12 code=0. This is reproducable here all the time. Cause i dont know how to get a kernel backtrace while booting from iso image, i took my pencil and paper. Here is the result (without the stack content) from yesterdays -current iso image (but all from the last 4 days looks the same). _mtx_lock_flags + 0x43 vfs_setdirty + 0x79 bdwrite + 0x358 ffs_update + 0x333 ffs_fsync + 0x42f ffs_fsync + 0x1a3 ffs_fsync + 0x16a shed_sync + 0x182 fork_exit + 0xcf fork_trampoline + 0x8 Anyone can fix this ? Jan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
On Thu, Aug 21, 2003 at 10:26:08AM +0200, Christian Brueffer wrote: > On Thu, Aug 21, 2003 at 05:57:28PM +1000, Tim Robbins wrote: > > Did one of the servers go down shortly before the panic, then? The last few > > lines of dmesg might be useful. > > > > No indication for that in the logs. I would have noticed anyway, as I was > playing music from one of the shares. > One of the shared file systems was full (besides the reserved space) at the > time of the panic. Could that have to do something with it? Perhaps. On closer examination, the backtrace doesn't match exactly the problem I'd seen and worked around in NTFS, but it seems to be related to it. Bad things happen when the cache can't write a dirty buffer back to disk -- in the NTFS case, this was triggered by another buffer cache bug that caused it to try to write a non-dirty buffer back to a read-only disk[*]. I would have thought that disk space on the server would have already been allocated for the buffer, so I'm not sure whether the filesystem being full could have caused a write error. But in any case, I'm not sure how to fix the bug you encountered, even if my speculations turn out to be correct. At one stage I thought I had found a logic error in brelse()'s handling of write errors, but I don't remember the specifics anymore. Tim [*] vfs_bio.c:getblk():gbincore(...) != NULL && bp->b_bcount != size && !(bp->b_flags & B_VMIO) && !(bp->b_flags & B_DELWRI) -> write non-dirty buffer to disk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
On Wed, 20 Aug 2003, M. Warner Losh wrote: > Looks like 1.91,1.92 broke things, and 1.93 fixes it. Please let me > know if I'm smoking the happy weed or not :-) Yay, it works! :-) regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ath driver still buggy.
Hi. Me and a couple of my friends work on small freebsd version for embedded systems. We all noticed that our wifi cards with atheros chip have problems with the ath driver. The system keeps on spitting out following messages before the link, that is already very slow dies: ath_rate_ctl: 54M -> 48M (0 ok, 3 err, 3 retr) ath_rate_ctl: 48M -> 36M (0 ok, 1 err, 1 retr) ath_rate_ctl: 36M -> 24M (0 ok, 1 err, 1 retr) ath_rate_ctl: 24M -> 36M (11 ok, 0 err, 0 retr) ath_rate_ctl: 36M -> 48M (23 ok, 0 err, 0 retr) ath_rate_ctl: 48M -> 36M (0 ok, 2 err, 2 retr) ath_rate_ctl: 36M -> 24M (3 ok, 7 err, 7 retr) ath_rate_ctl: 24M -> 18M (0 ok, 1 err, 1 retr) And ping requests end up with following message: ping: sendto: No buffer space available This was tested running 11a and 11g with PCMCIA and mini-PCI cards. hw.ath.hal.version: 0.9.5.2 ath0: mem 0x8801-0x8801 irq 11 at device 0.0 on cardbus1 FreeBSD 5.1-CURRENT #0: Wed Aug 20 16:59:24 CEST 2003 Any solution for that Sam? I can remember you mentioned you have fix for that a couple of weeks ago and that you will submit it in a week time or so. Cheers, YazzY ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Your details
Thank you for contacting Metro Link. This is an auto-response message with important instructions. Due to an inordinate amount of spam sent to "[EMAIL PROTECTED]", we have eliminated this address and created a new one. Please resend your message to the following address, changing the words to symbols where obvious: TellMeMore AT metrolink DOT com Or, if you prefer, you can call us at either of these numbers: +1 954-660-2500 +1 800-821-8315 We apologize for this inconvenience and appreciate your persistence in reaching us. The Officers and Staff of Metro Link Incorporated ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (2) 5.1-R-p2 crashes on SMP with AMI RAID and Intel 1000/Pro
Related to the em driver, 82540M has not worked since sometime in
5.1-BETA time,
I filed a pr on that a few months ago but it seems the fault might be
with PCI IRQ routing,
not the em driver itself.
Pete
Hartmann, O. wrote:
On Wed, 20 Aug 2003, Colin Faber wrote:
Hi.
I first swapped the Intel 1000/PRO server NIC into the next slot and up then the
machine seems to be 'stable'. Then, two days later, I changed the PSU to 400W
units.
I think it's a IRQ routing problem since we have had this problem (spontanous reboots)
from FreeBSD 4.0 on). Changing the slot for the NIC helped, but this is a very bad
state.
I can not remember the error message I got when the system crashed, but it lookes like
yours and I always say the amr0-text in that message. ACPI is not working on the old
TYAN Thunder 2500 (S1867) main PCB.
I also changed machdep.cpu_idle_hlt = 0, but with no effect.
At the moment, I do not dare swapping the NIC again due to the fact the machine is in
a preliminary production state.
I also realized some weird things when creating and deleting files when the system
crashed.
Crashes always could be forced by accessing samba services from a PC. Crashes always
occured when heavy IO was done, but this also could be a evidence for an IRQ problem,
I think.
I do not know. The machine was 'stable' (it means: when the NIC was at the
crash-causing
slot) a whole night, but whenever our department 'got started' in the morning time and
heavy
IO was done, the machine froze. This changed when I swapped the NIC to another slot
And now I also have two 400W PSUs.
FreeBSD 5.1-p2 on the TYAN S1867 seems to have much more problems, but I do not know
whether I
should mention this here. truss for instance crashes. We use afbackup for backing up,
but
afbackup core dumps on this machine and it does not on a UP machine also running
FreeBSD 5.1-p2.
It also crashes on a UP kernel on this machine.
I tried to 'truss' an afrestore call, but I had to start the tracing three or four
times
because I got this error first time:
truss: PIOCWAIT: Input/output error
or something like this
root: /usr/local/samba/lib: truss -fae -o /tmp/afrestore afrestore -v -p
"/usr/homes/kurs*" -C /
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
or sometimes truss stops lacking in a /proc/PID-XXX/mem file.
But calling it more times will 'solve' the problem.
While writing this, I crashed the system with the above showed command, this is the
error message from the kernel when the system froze (I wrote it down from the screen):
Fatal trap 12 : page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01b29db
stack pointer = 0x10:0xe8ff3b70
frame pointer = 0x10:0xe8ff3b84
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def 32, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 27510 (bunzip2)
trap number = 12
panic: page fault
cpuid = 1, lapic.id =
boot() called on cpu#1
syncing disks, buffers remaining ... panic: absolutely cannot call
smp_ipi_shutdown with interrupts already disabled
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime 1d20h18m55s
pfs_vncache_unload(): 6 entried remaining
Fatal double fault:
eip = 0xc03134ic
esp = 0xe8ff1ff8
ebp = 0xe8ff2014
cpuid = 1, lapic.id =
panic: double fault
cpuid = 1, lapic.id =
boot() called on cpu#1
Uptime: 1d20h18m55s
pfs_vncache_unload(): 6 entries remaining
After this, the machine was dead.
:>Hi,
:>
:>I've got nearly the same setup in a Dell 1600SC with a gig of ram and a PERC4/Sc
(LSI MegaRAID) card.
:>
:>Dual 2.4GHz Xeon P4 HT CPU's and I've discovered I can lock up FreeBSD
5.1-RELEASE-p2 on command
:>simply by running something to quickly create and remove a directory. i.e.:
:>
:> perl -e 'for(my $i = 0 ; $i < ; $i++){ mkdir("abc"); rmdir("abc"); }'
:>
:>
:>Having machdep.cpu_idle_hlt = 0 makes no difference.
:>
:>
:>Kernel:
:> FreeBSD 5.1-RELEASE-p2 FreeBSD 5.1-RELEASE-p2 #0: Mon Aug 11 21:40:47 MDT 2003
i386
:>
:>Raid:
:> amr0: mem 0xfcd0-0xfcd0 irq 3 at device 2.0 on pci1
:> amrd0: on amr0
:> amrd0: 34556MB (70770688 sectors) RAID 5 (optimal)
:>
:>
:>I suspect that your and my problems are more driver related to the amr driver and
may be exposing
:>some other problem with in the kernels fs locking. I don't think (as others have
suggested) that
:>your issue is power related, or related to the combination of hardware you're using.
(Other than
:>the fact that you've got a MegaRAID card).
:>
:>The exact crash message I'm seeing is:
:>
:>panic: lockmgr: locking agains
Re: (2) 5.1-R-p2 crashes on SMP with AMI RAID and Intel 1000/Pro
On Wed, 20 Aug 2003, Colin Faber wrote:
Hi.
I first swapped the Intel 1000/PRO server NIC into the next slot and up then the
machine seems to be 'stable'. Then, two days later, I changed the PSU to 400W
units.
I think it's a IRQ routing problem since we have had this problem (spontanous reboots)
from FreeBSD 4.0 on). Changing the slot for the NIC helped, but this is a very bad
state.
I can not remember the error message I got when the system crashed, but it lookes like
yours and I always say the amr0-text in that message. ACPI is not working on the old
TYAN Thunder 2500 (S1867) main PCB.
I also changed machdep.cpu_idle_hlt = 0, but with no effect.
At the moment, I do not dare swapping the NIC again due to the fact the machine is in
a preliminary production state.
I also realized some weird things when creating and deleting files when the system
crashed.
Crashes always could be forced by accessing samba services from a PC. Crashes always
occured when heavy IO was done, but this also could be a evidence for an IRQ problem,
I think.
I do not know. The machine was 'stable' (it means: when the NIC was at the
crash-causing
slot) a whole night, but whenever our department 'got started' in the morning time and
heavy
IO was done, the machine froze. This changed when I swapped the NIC to another slot
And now I also have two 400W PSUs.
FreeBSD 5.1-p2 on the TYAN S1867 seems to have much more problems, but I do not know
whether I
should mention this here. truss for instance crashes. We use afbackup for backing up,
but
afbackup core dumps on this machine and it does not on a UP machine also running
FreeBSD 5.1-p2.
It also crashes on a UP kernel on this machine.
I tried to 'truss' an afrestore call, but I had to start the tracing three or four
times
because I got this error first time:
truss: PIOCWAIT: Input/output error
or something like this
root: /usr/local/samba/lib: truss -fae -o /tmp/afrestore afrestore -v -p
"/usr/homes/kurs*" -C /
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
truss: PIOCWAIT top of loop: Input/output error
or sometimes truss stops lacking in a /proc/PID-XXX/mem file.
But calling it more times will 'solve' the problem.
While writing this, I crashed the system with the above showed command, this is the
error message from the kernel when the system froze (I wrote it down from the screen):
Fatal trap 12 : page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01b29db
stack pointer = 0x10:0xe8ff3b70
frame pointer = 0x10:0xe8ff3b84
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def 32, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 27510 (bunzip2)
trap number = 12
panic: page fault
cpuid = 1, lapic.id =
boot() called on cpu#1
syncing disks, buffers remaining ... panic: absolutely cannot call
smp_ipi_shutdown with interrupts already disabled
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime 1d20h18m55s
pfs_vncache_unload(): 6 entried remaining
Fatal double fault:
eip = 0xc03134ic
esp = 0xe8ff1ff8
ebp = 0xe8ff2014
cpuid = 1, lapic.id =
panic: double fault
cpuid = 1, lapic.id =
boot() called on cpu#1
Uptime: 1d20h18m55s
pfs_vncache_unload(): 6 entries remaining
After this, the machine was dead.
:>Hi,
:>
:>I've got nearly the same setup in a Dell 1600SC with a gig of ram and a PERC4/Sc
(LSI MegaRAID) card.
:>
:>Dual 2.4GHz Xeon P4 HT CPU's and I've discovered I can lock up FreeBSD
5.1-RELEASE-p2 on command
:>simply by running something to quickly create and remove a directory. i.e.:
:>
:> perl -e 'for(my $i = 0 ; $i < ; $i++){ mkdir("abc"); rmdir("abc"); }'
:>
:>
:>Having machdep.cpu_idle_hlt = 0 makes no difference.
:>
:>
:>Kernel:
:> FreeBSD 5.1-RELEASE-p2 FreeBSD 5.1-RELEASE-p2 #0: Mon Aug 11 21:40:47 MDT 2003
i386
:>
:>Raid:
:> amr0: mem 0xfcd0-0xfcd0 irq 3 at device 2.0 on pci1
:> amrd0: on amr0
:> amrd0: 34556MB (70770688 sectors) RAID 5 (optimal)
:>
:>
:>I suspect that your and my problems are more driver related to the amr driver and
may be exposing
:>some other problem with in the kernels fs locking. I don't think (as others have
suggested) that
:>your issue is power related, or related to the combination of hardware you're using.
(Other than
:>the fact that you've got a MegaRAID card).
:>
:>The exact crash message I'm seeing is:
:>
:>panic: lockmgr: locking against myself
:>cpuid = 0; lapic.id
:>boot() called on cpu#0
:>
:>syncing disks, buffers remaining... panic: ffs_copyonwrite: recursive call
:>cpuid = 0; lapic.id
:>boot() called
Re: [current tinderbox] failure on i386/i386
Tinderbox <[EMAIL PROTECTED]> writes: > [nothing] The tinderbox is failing to start because it tries to acquire a lock file in the sandbox, which is currently on an NFS partition. I've therefore disabled it while John is working on getting more local disk space online for the tinderbox to use. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
--Mh8CTEa8Ax54aLHp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2003 at 05:57:28PM +1000, Tim Robbins wrote: > On Thu, Aug 21, 2003 at 08:14:45AM +0200, Christian Brueffer wrote: >=20 > > On Thu, Aug 21, 2003 at 01:40:54PM +1000, Tim Robbins wrote: > > > On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: > > >=20 > > > > Hi, > > > >=20 > > > > just got a panic on following 5.1-CURRENT machine: > > > >=20 > > > > FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu = Aug > > > > 7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr= /obj/usr/src/sys/GONDOR i386 > > > >=20 > > > > A dump is available if anyone needs specific information. > > > [...] > > > > panic: bundirty: buffer 0xc776e118 still on queue 2^M > > > [...] > > > > #2 0xc0254007 in panic (fmt=3D0xc03cc0ef "bundirty: buffer %p stil= l on queue %d")^M > > > > at /usr/src/sys/kern/kern_shutdown.c:550^M > > > > #3 0xc029b291 in bundirty (bp=3D0xc776e118) at /usr/src/sys/kern/v= fs_bio.c:1121^M > > > > #4 0xc029bde1 in brelse (bp=3D0xc776e118) at /usr/src/sys/kern/vfs= _bio.c:1436^M > > > > #5 0xc02efcb8 in nfs_writebp (bp=3D0xc776e118, force=3D1, td=3D0xc= 2c17e40)^M > > > > at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M > > > > #6 0xc02e02c3 in nfs_bwrite (bp=3D0x0) at /usr/src/sys/nfsclient/n= fs_bio.c:76^M > > > > #7 0xc029dd41 in getblk (vp=3D0xc2c77b68, blkno=3D400, size=3D1536= 0, slpflag=3D256, slptimeo=3D0, flags=3D0)^M > > > > at /usr/src/sys/kern/vfs_bio.c:2512^M > > > > #8 0xc02e21e5 in nfs_getcacheblk (vp=3D0xc2c77b68, bn=3D400, size= =3D15360, td=3D0xc2c17e40)^M > > > > at /usr/src/sys/nfsclient/nfs_bio.c:1037^M > > >=20 > > > I think I recognise this backtrace. Did you have a read-only NFS mount > > > active at the time of the crash? In any case, a copy of your NFS entr= ies from > > > /etc/fstab (with any private data removed) would be helpful in tracki= ng this > > > problem down. > > >=20 > >=20 > > No, all mounts were read-write. >=20 > Did one of the servers go down shortly before the panic, then? The last f= ew > lines of dmesg might be useful. >=20 No indication for that in the logs. I would have noticed anyway, as I was playing music from one of the shares. One of the shared file systems was full (besides the reserved space) at the time of the panic. Could that have to do something with it? - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --Mh8CTEa8Ax54aLHp Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/RIIgbHYXjKDtmC0RAqdEAKC4O3m7T3Gnl0WGDQ2LI8iyf2f2xQCfdeZ8 iOmwx948dfY0k1j9NSW65RM= =6VOi -END PGP SIGNATURE- --Mh8CTEa8Ax54aLHp--
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
On Thu, Aug 21, 2003 at 08:14:45AM +0200, Christian Brueffer wrote: > On Thu, Aug 21, 2003 at 01:40:54PM +1000, Tim Robbins wrote: > > On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: > > > > > Hi, > > > > > > just got a panic on following 5.1-CURRENT machine: > > > > > > FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug > > > 7 21:32:39 CEST 2003 [EMAIL PROTECTED] > > > konia.hitnet.rwth-aachen.de:/usr/obj/usr/src/sys/GONDOR i386 > > > > > > A dump is available if anyone needs specific information. > > [...] > > > panic: bundirty: buffer 0xc776e118 still on queue 2^M > > [...] > > > #2 0xc0254007 in panic (fmt=0xc03cc0ef "bundirty: buffer %p still on queue > > > %d")^M > > > at /usr/src/sys/kern/kern_shutdown.c:550^M > > > #3 0xc029b291 in bundirty (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1121^M > > > #4 0xc029bde1 in brelse (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1436^M > > > #5 0xc02efcb8 in nfs_writebp (bp=0xc776e118, force=1, td=0xc2c17e40)^M > > > at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M > > > #6 0xc02e02c3 in nfs_bwrite (bp=0x0) at /usr/src/sys/nfsclient/nfs_bio.c:76^M > > > #7 0xc029dd41 in getblk (vp=0xc2c77b68, blkno=400, size=15360, slpflag=256, > > > slptimeo=0, flags=0)^M > > >at /usr/src/sys/kern/vfs_bio.c:2512^M > > > #8 0xc02e21e5 in nfs_getcacheblk (vp=0xc2c77b68, bn=400, size=15360, > > > td=0xc2c17e40)^M > > >at /usr/src/sys/nfsclient/nfs_bio.c:1037^M > > > > I think I recognise this backtrace. Did you have a read-only NFS mount > > active at the time of the crash? In any case, a copy of your NFS entries from > > /etc/fstab (with any private data removed) would be helpful in tracking this > > problem down. > > > > No, all mounts were read-write. Did one of the servers go down shortly before the panic, then? The last few lines of dmesg might be useful. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting from 5.1-RELEASE to RELENG_5_1
On Thu, Aug 21, 2003 at 07:34:09AM +1000, Peter Jeremy typed: > I am looking at moving various hosts from 4.x to 5.1 but have run into > a problem with my test machine. I've successfully installed > 5.1-RELEASE (from CD) but want to rebuild the system to customise it > to its environment. > > The machine in question does not have enough local disk space to hold > both /usr/src and /usr/obj. When I tried to NFS mount the space, the > 'make buildworld' would consistently wedge the machine in "stage 1: > bootstrap tools" building games/fortune/strfile. I tried using local > disk for /usr/obj and NFS mounting just /usr/src. This got somewhat > further but again wedged the machine. "Wedged" means no response via > network or local keyboard, needing reset to recover. > > Has anyone else seen NFS problems with 5.1-RELEASE? The client is a > P-133 with 96MB RAM. The server is a PIII running roughly 4.6. They > are both using 100baseTX full-duplex 802.1Q trunks to a common switch. > > My alternative (preferred) option is to do a build world/kernel on > another faster machine (the NFS server used above). This fails with > multiple definitions of _sigaction and _sigprocmask building > libpthread. Looking back thru the archives, I gather this has been > fixed in -CURRENT but it's not in RELENG_5_1 because it's not > security-related. > > Any suggestions for a way forward? I just successfully upgraded releng_4 -> releng_5_1 by using: make NOLIBPTHREAD=true buildworld ... make NOLIBPTHREAD=true installworld ... Maybe there should be a note about this in UPDATING ? Ruben > > Peter > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
