help, after cvsup - erros on HDD and ICH5, FAILURE READ_DMA48
Hi, ALL! On Friday has made CVSUP (RELENG_6) has received - 6.1-RC. Has updated system. After that, I have many errors: - # grep -i error /var/log/messages kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=380951327 kernel: g_vfs_done ():ad0s1f [READ (offset=188067725312, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=380951327 kernel: g_vfs_done ():ad0s1f [READ (offset=188067725312, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=380951327 kernel: g_vfs_done ():ad0s1f [READ (offset=188067725312, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 -- I have thought, what is it because of updating. Has made: reboot -k /boot/kernel.last (the Kernel from February, 1) But, errors too: --- kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=380951327 kernel: g_vfs_done ():ad0s1f [READ (offset=188067725312, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285279 kernel: g_vfs_done ():ad0s1f [READ (offset=182094708736, length=16384)] error = 5 kernel: ad0: FAILURE - READ_DMA48 status=51 error=40 LBA=369285183 -- *Prompt, it at me HDD fell down or mistakes in the new driver?* This disk is connected to ICH5 udma100 Just in case I bring a configuration below: --- #dmesg | grep ata atapci0: port 0xdf00-0xdf3f, 0xdfa0-0xdfaf, 0xdc00-0xdc7f mem 0xfe6fe000-0xfe6fefff, 0xfe6c-0xfe6d irq 23 at device 4.0 on pci3 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci1 ata1: on atapci1 ad0: 194481MB at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 ad4: 305245MB at ata2-master SATA150 ad6: 305245MB at ata3-master SATA150 ad8: 305245MB at ata4-master UDMA100 ad9: 305245MB at ata4-slave UDMA100 ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (master) using ad6 at ata3-master ar0: disk2 READY (mirror) using ad8 at ata4-master ar0: disk3 READY (mirror) using ad9 at ata4-slave Best regards, GreenX. ___ 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
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: 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]"
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
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-current&a=2004-10&m=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]"
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]"
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-current&a=2004-10&m=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]"
[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 usbd_do_request_flags_pi
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]"