Re: Disappointed
On Wed, 5 Apr 2006, Kris Kennaway wrote: On Wed, Apr 05, 2006 at 10:37:41PM +0200, Albert Shih wrote: OK I just do it. I just hope the maintainer can understand me... As a first step: you say your server crashed. Did it panic? Do you have debugging settings (INVARIANTS, WITNESS) enabled? Do you have DDB enabled? Read through the chapter on kernel debugging in the developers' handbook and reconfigure your kernel accordingly, then proceed from there. Well it's no so easy. I can try but there least 600 users waiting the big fsck when the server crash. I'm not sure I can spend many time to try this.. But I promise you I will try. Thanks. You need to evaluate whether it's more important for you to try to get the problem fixed, or to keep dealing with the downtime from the crashes. Trying to reproduce on a test machine is also a good idea. Unfortunately, debugging system problems does take work, but at the same time if you can't put the work in, it's not so likely you'll be able to resolve the problem. NB: Why this kind of problem can happen ? I ask this because until 6. I never have this kind of problem. All software has bugs, and sometimes hardware has bugs too. I can not provide you much either... But I have similar problem. But for me it crashes within a couple of days. The system is a HP Proliant DL380 G3. Which mean it runs ciss(4) and bge(4). Its a generic SMP kernel, but I have tried without SMP enabled before. The system is running the news software Diablo and are set up as a feeder. Give or take aprox 100 incoming connections feeding aprox 200Mbp and 20 outgoing feeding aprox 200Mbps. I have tried to follow the docs about creating a dump into /var/crash. But there is none to be seen. Perhaps I have missed something, or it is actually not created. I will go through those again once I am back at work on tuesday. It feels like its just freezes and reboots without any warnings at all. If someone will give me a simple step by step walkthrough, I can make it in whatever way you want me to. /Bjorn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[LOR] bpf vs. USB (perhaps #147?)
Hello again, found some other LORs on 6.1-PRERELEASE while running kismet and tcpdump on ural0 at the same time. They all look very similar, though one is in usb_read, the other in usb_write. Sleeping on usbsyn with the following non-sleepable locks held: exclusive sleep mutex bpf global lock r = 0 (0xc079c280) locked @ /usr/src/sys/net/bpf.c:425 KDB: stack backtrace: kdb_backtrace(1,c5a8ac48,c5a8c300,2,ef53f894) at kdb_backtrace+0x29 witness_warn(5,0,c06d7bd4,c06cf607) at witness_warn+0x18e msleep(c5c49c00,0,4c,c06cf607,0) at msleep+0x42 usbd_transfer(c5c49c00,ef53f8f4,c04d6b05,c5c49c00,278940c2) at usbd_transfer+0x121 usbd_sync_transfer(c5c49c00,278940c2,c5a8acf0,c5a8c300,c4c26000) at usbd_sync_transfer+0x11 usbd_do_request_flags_pipe(c4bf7580,c4bf7500,ef53f950,ef53f94e,0) at usbd_do_request_flags_pipe+0x5d usbd_do_request_flags(c4bf7580,ef53f950,ef53f94e,0,0) at usbd_do_request_flags+0x20 usbd_do_request(c4bf7580,ef53f950,ef53f94e) at usbd_do_request+0x1a ural_read(c4c26000,444,c4c26000,0,ef53f990) at ural_read+0x42 ural_update_promisc(c4c26000) at ural_update_promisc+0x16 ural_ioctl(c4c1bc00,80206910,ef53f9ac,1,108903) at ural_ioctl+0x55 if_setflag(c4c1bc00,100,2,c4c1bc44,0) at if_setflag+0x120 ifpromisc(c4c1bc00,0) at ifpromisc+0x23 bpf_detachd(c52b6a00) at bpf_detachd+0xae bpfclose(c5c49100,7,2000,c5a8c300,c07502c0) at bpfclose+0x83 giant_close(c5c49100,7,2000,c5a8c300,c5c49100) at giant_close+0x30 devfs_close(ef53fab4) at devfs_close+0x2db VOP_CLOSE_APV(c071cd40,ef53fab4) at VOP_CLOSE_APV+0x7e vn_close(c5ef6dd0,7,c52d2e00,c5a8c300,0) at vn_close+0x8b vn_closefile(c5c83cf0,c5a8c300,ef53fb6c,c0508328,c5c83cf0) at vn_closefile+0xca devfs_close_f(c5c83cf0,c5a8c300) at devfs_close_f+0xf fdrop_locked(c5c83cf0,c5a8c300,c4ae9640,0,c06d3ea7) at fdrop_locked+0x88 fdrop(c5c83cf0,c5a8c300,6b2,c07555c0,0) at fdrop+0x24 closef(c5c83cf0,c5a8c300) at closef+0x367 fdfree(c5a8c300) at fdfree+0x4a3 exit1(c5a8c300,0,ef53fd30,c069a577,c5a8c300) at exit1+0x438 exit1(c5a8c300,ef53fd04,1,6d,292) at exit1 syscall(3b,3b,3b,bfbf8f90,1) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x482d4027, esp = 0xbfbf8f5c, ebp = 0xbfbf8f78 --- lock order reversal: (Giant after non-sleepable) 1st 0xc079c280 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:425 2nd 0xc07502c0 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:216 KDB: stack backtrace: kdb_backtrace(0,,c075f100,c075f588,c0724364) at kdb_backtrace+0x29 witness_checkorder(c07502c0,9,c06d7c0d,d8) at witness_checkorder+0x578 _mtx_lock_flags(c07502c0,0,c06d7c0d,d8) at _mtx_lock_flags+0x5b msleep(c5c49c00,0,4c,c06cf607,0) at msleep+0x2d2 usbd_transfer(c5c49c00,ef53f8f4,c04d6b05,c5c49c00,278940c2) at usbd_transfer+0x121 usbd_sync_transfer(c5c49c00,278940c2,c5a8acf0,c5a8c300,c4c26000) at usbd_sync_transfer+0x11 usbd_do_request_flags_pipe(c4bf7580,c4bf7500,ef53f950,ef53f94e,0) at usbd_do_request_flags_pipe+0x5d usbd_do_request_flags(c4bf7580,ef53f950,ef53f94e,0,0) at usbd_do_request_flags+0x20 usbd_do_request(c4bf7580,ef53f950,ef53f94e) at usbd_do_request+0x1a ural_read(c4c26000,444,c4c26000,0,ef53f990) at ural_read+0x42 ural_update_promisc(c4c26000) at ural_update_promisc+0x16 ural_ioctl(c4c1bc00,80206910,ef53f9ac,1,108903) at ural_ioctl+0x55 if_setflag(c4c1bc00,100,2,c4c1bc44,0) at if_setflag+0x120 ifpromisc(c4c1bc00,0) at ifpromisc+0x23 bpf_detachd(c52b6a00) at bpf_detachd+0xae bpfclose(c5c49100,7,2000,c5a8c300,c07502c0) at bpfclose+0x83 giant_close(c5c49100,7,2000,c5a8c300,c5c49100) at giant_close+0x30 devfs_close(ef53fab4) at devfs_close+0x2db VOP_CLOSE_APV(c071cd40,ef53fab4) at VOP_CLOSE_APV+0x7e vn_close(c5ef6dd0,7,c52d2e00,c5a8c300,0) at vn_close+0x8b vn_closefile(c5c83cf0,c5a8c300,ef53fb6c,c0508328,c5c83cf0) at vn_closefile+0xca devfs_close_f(c5c83cf0,c5a8c300) at devfs_close_f+0xf fdrop_locked(c5c83cf0,c5a8c300,c4ae9640,0,c06d3ea7) at fdrop_locked+0x88 fdrop(c5c83cf0,c5a8c300,6b2,c07555c0,0) at fdrop+0x24 closef(c5c83cf0,c5a8c300) at closef+0x367 fdfree(c5a8c300) at fdfree+0x4a3 exit1(c5a8c300,0,ef53fd30,c069a577,c5a8c300) at exit1+0x438 exit1(c5a8c300,ef53fd04,1,6d,292) at exit1 syscall(3b,3b,3b,bfbf8f90,1) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x482d4027, esp = 0xbfbf8f5c, ebp = 0xbfbf8f78 --- Sleeping on usbsyn with the following non-sleepable locks held: exclusive sleep mutex bpf global lock r = 0 (0xc079c280) locked @ /usr/src/sys/net/bpf.c:425 KDB: stack backtrace: kdb_backtrace(1,c5a8ac48,c5a8c300,0,ef53f894) at kdb_backtrace+0x29 witness_warn(5,0,c06d7bd4,c06cf607) at witness_warn+0x18e msleep(c5c49c00,0,4c,c06cf607,0) at msleep+0x42 usbd_transfer(c5c49c00,ef53f8f4,c04d6b05,c5c49c00,278940c2) at usbd_transfer+0x121 usbd_sync_transfer(c5c49c00,278940c2,c5a8acf0,c5a8c300,c4c26000) at usbd_sync_transfer+0x11 usbd_do_request_flags_pipe(c4bf7580,c4bf7500,ef53f94c,0,0) at
CPUTYPE=athlon-xp and loader
Hello, I have a problem which I have found out from mailing lists that some other people had. However there is no clear solution. The CPUTYPE=athlon-xp in make.conf breaks /boot/loader that system instant reboots. I am using 6-stable and from what I can see the problem goes back till about 5.3... Sometime between Oct 12-15, 2005 http://archive.netbsd.se/?ml=freebsd-currenta=2004-10m=435817 I wonder if this will ever be fixed or I shouldnt use CPUTYPE=athlon-xp anymore on FreeBSD because of this? Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
[Moved to -stable] On Sunday 16 April 2006 07:04, Søren Schmidt wrote: = I just tried this on a system as close to the one you have as possible You are welcome to visit my machine and take a look. Use the same ssh key as for the FreeBSD cluster and connect to aldan.algebra.com. = That makes me *seriously* doubt that ATA is at fault here... What else can it be? The main disks are SCSI and work well. The video sucks, but that's a problem common to many -- nobody can get their PCI-Radeons up with DRI. What else can be wrong? Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=athlon-xp and loader
Evren Yurtesen wrote:
Hello,
I have a problem which I have found out from mailing lists that some
other people had. However there is no clear solution.
The CPUTYPE=athlon-xp in make.conf breaks /boot/loader that system
instant reboots. I am using 6-stable and from what I can see the problem
goes back till about 5.3... Sometime between Oct 12-15, 2005
http://archive.netbsd.se/?ml=freebsd-currenta=2004-10m=435817
I wonder if this will ever be fixed or I shouldnt use CPUTYPE=athlon-xp
anymore on FreeBSD because of this?
I have the same problem with CPUTYPE=pentium-m and there is an easy
solution. I have the following lines in my /etc/make.conf:
# /boot/loader crashs with pentium-m
.if ${.CURDIR:M*/src/sys/boot/i386/loader*}
CPUTYPE=pentium3
.endif
Exchange pentium3 with something that works for you, i.e. athlon and it
should be fine for you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Tyan K8WE BIOS v1.03 and -STABLE
I tried updating the BIOS on my K8WE (S2895) yesterday to 1.03, but after the update, FreeBSD (RELENG_6 dated March 26) would randomly freeze after booting. As I was updating from v1.01, I suspect it may be the updates to the nVidia SATA firmware that caused the issue, as things generally froze shortly after the background fsck processed kicked in (with, obviously, the exception of the first boot, and a few others). It may be worth noting that Windows, though booting fine, did complain that the ATA driver was mis-matched for the firmware of the ATA controller. Is anyone else successfully running -STABLE with v1.03 on a K8WE? Just wondering if this is something specific to the options I've chosen, or if it's an interaction issue between FreeBSD and this BIOS revision. (No, I haven't tried just going to 1.02, as I needed the machine. Though that should be a fairly good test to narrow down what the problem is.) - Damian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=athlon-xp and loader
I filed a bug report for this in January of 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=75898 - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
disklabel backups
Hi, Just a thought... Twice I've needed a backup of disklabel... the first instance was user error, and the second was due to a failing hard drive that needed information to be retrieved from it. Both times after getting the disklabel set correctly, I was able to remount the filesystems and use them as normal. However getting the details right was difficult. I now backup disklabel in my backup procedures. However, I understand OpenBSDs /etc/periodic does a backup of disklabel to the filesystem. A feature like this would be great on FreeBSD, as in the event of a future failure I could retrieve the disklabel from backups. Not sure if this is the right mailing list to send this to, so let me know if it isn't. Regards, Peter Hoskin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to change hardware clock
On Monday 17 April 2006 02:25, Mare Negrocan wrote: I repeat, I have trouble with hardware clock! Ntpd, ntpdate, rdate don't update my hardware clock. No error messages. No idea. Maybe your hardware is broken? You haven't supplied any information about your hardware. What do you mean exactly? When you reboot the BIOS time is unchanged? Does the clock change in FreeBSD when you use those? Also, don't drop the CC. -Original Message- From: Daniel O'Connor [mailto:[EMAIL PROTECTED] Sent: Saturday, April 15, 2006 11:36 PM To: Mare Negrocan Subject: Re: How to change hardware clock On Sunday 16 April 2006 00:33, Mare Negrocan wrote: Ntpd is running. If ntpd is running then ntpdate won't be able to run at the same time. Stop ntpd, run ntpdate, then restart ntpd. Also, please don't drop CC in future. PS your aparent lazyness in only answering one of my questions does not bode well for finding out answers on a mailing list. -Original Message- From: Daniel O'Connor [mailto:[EMAIL PROTECTED] Sent: Saturday, April 15, 2006 5:01 PM To: freebsd-stable@freebsd.org Cc: Mare Negrocan Subject: Re: How to change hardware clock On Saturday 15 April 2006 23:27, Mare Negrocan wrote: How to change hardware clock? I can't update clock with rdate, ntpdate. Care to provide any error messages? Or even what you tried? Is ntpd running? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpr5XW4psPYC.pgp Description: PGP signature
