Re: FBSD82 sec patch -p4, uname still -p3
On 07.10.2011 09:01, Jason Helfman wrote: If your kernel wasn't touched during the update, then uname won't bump. but as -p4 for 8.2 fixes FreeBSD-SA-11:05.unix, it should have touched the kernel, shouldn't it? regards - Michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FBSD82 sec patch -p4, uname still -p3
well I know about the newvers.sh. But as far as I understand the advisory (and the patch) the file sys/kern/uipc_usrreq.c is modified. I'm not that much into the FreeBSD kernel code. However, isn't this affecting the kernel image? regards - Michael On 07.10.2011 13:33, n dhert wrote: I believe the reason is the following: The changes were to /boot/GENERIC/linux.ko and /boot/GENERIC/linux.ko.symbols and NOT to the *freebsd* kernel /boot/GENERIC/kernel ... So,the freebsd kernel didn't change, uname -a gets its info from the linux kernel (not directly from the /usr/src/sys/conf/newvers.sh file), this is unchanged, hence it still reports -p3 On another system where I have a custom kernel (QUOTA support), as always, I did a makebuild from sources (although stricktly spreaking it in *this* case it was not necessary), did a makeinstall, rebooted, and there uname -a is -p4, which makes sense, since rebuilding the kernel from source files wrote the information contained in /usr/src/sys/conf/newvers.sh into the kernel binary, from which uname -a extracts the patch version .. 2011/10/7 Michael Schaefer utf...@googlemail.com On 07.10.2011 09:01, Jason Helfman wrote: If your kernel wasn't touched during the update, then uname won't bump. but as -p4 for 8.2 fixes FreeBSD-SA-11:05.unix, it should have touched the kernel, shouldn't it? regards - Michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
massive hdd/geli problems after upgrade to 8.1-RELEASE
Hey folks, some days ago i upgraded my FreeBSD 8.0-RELEASE-p4 system to 8.1-RELEASE using freebsd-update. I'm using a generic kernel so the upgrade process was just straight forward. However I encountered massive problems with my hdd which I now found out are attributed to this upgrade. I'm using a WD15EARS Caviar Green 1.5TB for data which is formated with ufs inside a geli container. The system itself runs on a 1GB CF card. Both is attached to a VIA EPIA Mini ITX platform. After the upgrade every read or write operation on the WD drive results in very slow performance (100k/s up to 2mb/s with significant lags) and dmesg is flooded with messages like the following: ad4: FAILURE - READ_MUL48 status=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=594632984 bt kernel: GEOM_ELI: g_eli_read_done() failed ad4p1.eli[READ(offset=304452055040, length=4096)] bt kernel: g_vfs_done():ad4p1.eli[READ(offset=304452055040, length=4096)]error = 5 bt kernel: ad4: FAILURE - READ_MUL48 status=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=2452694208 bt kernel: GEOM_ELI: g_eli_read_done() failed ad4p1.eli[READ(offset=1255779401728, length=131072)] bt kernel: g_vfs_done():ad4p1.eli[READ(offset=1255779401728, length=131072)]error = 5 bt kernel: ad4: TIMEOUT - READ_MUL48 retrying (1 retry left) LBA=2452698560 A filesystem check on the attached geli container reports thousands of errors and unreadable sectors. In the end every read or write operation (such as copying a larger file over the network) results in freezing the system after several minutes. So does the fsck which I didn't manage to perform completely. files transferred are mostly broken. As the messages look like a dying hdd I replaced the cable, checked connection, etc. Nothing changes. Have been fiddling around for one day now and was close to file an RMA request. But just to make sure I did a rollback using freebsd-udpate back to 8.0-RELEASE-p4. Behold now everything goes smooth again and no errors occur at all. performance stability - everything back to normal. Any ideas on this? Since 8.0 is approaching end-of-life I would really like to upgrade to 8.1.. thx a lot Michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: massive hdd/geli problems after upgrade to 8.1-RELEASE
Hi Mike and thank you for your response please find the smartctl output here: http://pastecode.org/index.php/view/27349679 will do the atacontrol comparison later on since I would ahve to upgrade the system again. I stressed the hdd now with the old kernel for several hours copying reading/writing large amounts of data without any error. even the filesystem check ran through with just some softupdate inconsistencies but without sector errors... don't know what to think about all this.. Well maybe I should mention that I formatted the hard disk according to this discussion http://forums.freebsd.org/showthread.php?t=12088page=3 aligned with the 4k sector size of the drive... regards Michael On 04.12.2010 20:19, Mike Tancsa wrote: On 12/4/2010 12:08 PM, Michael Schaefer wrote: ad4: FAILURE - READ_MUL48 status=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=594632984 Those do seem like hardware errors on the disk. But going back to the old kernel however should not make a difference. Try (/usr/ports/sysutiles/smartmontools and do a smartctl -x /dev/ad4 and see if the drive thinks it has any errors. Does atacontrol cap ad4 show any differences between the two kernels ? perhaps something new is enabled or disabled between versions like the power management ? ---Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Last login message
On 04.12.2009 00:16, Nerius Landys wrote: I was wondering what controls this, meaning if I get an IP or a hostname, and why it's being truncated. don't know about the truncating, but this behavior of displaying the last login time and host is handled by pam_lastlog(8). i guess the FQHN is just displayed if a reverse dns entry exists for the corresponding ip. regards - michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rTorrent + FreeBSD + pf = freeze?
Hi Michael, On 24.11.2009 00:41, Michael K. Smith wrote: We had similar crashes with PF, although not related to rtorrent specifically. However, we use the following sysctl values that have helped stability and performance immensely. net.inet.carp.preempt=1 net.inet.carp.arpbalance=0 net.inet.icmp.icmplim=2000 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=65536 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.somaxconn=32768 net.inet.tcp.mssdflt=1460 kern.ipc.maxsockbuf=16777216 kern.ipc.nmbclusters=32768 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.maxvnodes=60 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65536 net.local.stream.recvspace=65536 net.inet.tcp.sendbuf_max=16777216 thank you for the hint. I tried those values which seem to affect the traffic class i'm talking about. So what I actually changed is listed below: sysctl kern.ipc.somaxconn=512 sysctl net.inet.tcp.sendspace=65536 sysctl kern.ipc.maxsockbuf=1048576 sysctl kern.ipc.nmbclusters=32768 sysctl kern.maxvnodes=20 sysctl net.inet.tcp.recvbuf_max=16777216 sysctl net.local.stream.recvspace=65536 Interesting enough I really was able to start the mentioned rtorrent instance without crashing the machine. but unfortunately the crash just was delayed so that the machine rebooted after ~3hours. However these values seemed to affect the stability and are somehow related with the problem. For now i'm just upgrading to 8.0-RELEASE and will see how things change.. regards - michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rTorrent + FreeBSD + pf = freeze?
On 22.11.2009 23:11, cpghost wrote: Have you tried to run rtorrent and the router on two different FreeBSD machines? Does it lock the router, or does it crash the rtorrent box only, or both? even though i haven't been asked i might want to answer ;) Since my box really exclusively does rtorrent i don't think it's related to routing or NAT. pf is not active at all. Routing and NAT for my setup is done by a dedicated different box (which isn't affected by all this, apart from that it doesn't run freebsd). so for me this really looks like a /networking/ issue, which is not dedicated to routing or NAT in particular.. for me this now becomes kinda problematic, since i cannot even start the second rtorrent instance without crashing the machine immediately.. :( regards - michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rTorrent + FreeBSD + pf = freeze?
On 22.11.2009 23:11, cpghost wrote: Have you tried to run rtorrent and the router on two different FreeBSD machines? Does it lock the router, or does it crash the rtorrent box only, or both? even though i haven't been asked i might want to answer ;) Since my box really exclusively does rtorrent i don't think it's related to routing or NAT. pf is not active at all. Routing and NAT for my setup is done by a dedicated different box (which isn't affected by all this, apart from that it doesn't run freebsd). so for me this really looks like a /networking/ issue, which is not dedicated to routing or NAT in particular.. for me this now becomes kinda problematic, since i cannot even start the second rtorrent instance without crashing the machine immediately.. :( regards - michael ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rTorrent + FreeBSD + pf = freeze?
well.. i think this is really something to escalate now since there is obviously a problem. today again i tried a little bit and as told, the isntance B crashes the system reproducible. In my opinion something like this should really be examined further, since a userspace program shouldn't kill the hole system... for me this really looks like several people have similar problems but so far there's no investigation since nobody knows what the actual problem. any ideas how to proceed? can i provide any additional information? since the system reboots immediately it's hard to investigate the process of crashing itself.. at least for me. regards - michael On 20.11.2009 01:08, Peter Kieser wrote: Hello, This problem has been going on for at least the past 2 years. I've had the exact same issue with rtorrent locking up or restarting machines running FreeBSD, regardless of the hardware used. I did not have any sort of firewall installed (neither pf, or ipfw). If I loaded up rtorrent and had a number of torrents open the machines would lock up or restart. It was reproducible at the time, but I could never get anyone to admit there was a bug and I'm unable to find the initial posting. Regards, -Peter Michael Schaefer wrote: Hello everybody, I encountered same problems and am kinda glad to see I'm not alone. I use FreeBSD 7.1-RELEASE-p8 (GENERIC) on a VIA EPIA board (800MHz C3). This box for the moment does nothing but torrent. I use two instances of rtorrent. Each with an own user and in its own screen session. Let's name them A and B. A seeds around 300 torrents and B around 500 (each rtorrent instance communicates just to one specific tracker). The configuration is exactly the same, except B communicates with the track only using https (A does plain http). While A works 100% perfect an stable, B crashes the machine reproducible. When using rtorrent 0.8.3/0.12.3 this happened only about once a month. After upgrading to 0.8.4/0.12.4 the rate of crashes increased to about once a week. now i upgraded to 0.8.5/0.12.5 and cannot even start instance B without crashing the machine immediately just several minutes after I started it. Sometimes it somehow survives the starting procedure (where actually all seeding torrents are registered at the tracker at more or less the same time) but then it takes about 10min - 2 hours after the hole systems crashes again. Like I mentioned: instance B works perfectly without any problems. I'm pretty sure I encountered the problem also (even not the heavily) during times instance B was only seeding about 300 torrents... For me the system simply reboots and doesn't freeze. The logs are clear and show no advice concerning the problem. It's not a matter of hardware since I changed the board (which included CPU, RAM, NIC,...) and also the hard disc month ago. Also a heat problem can be excluded. Any clou about all that? btw: I don't use PF at all... regards - Michael On Wed, 21 Oct 2009, cpghost wrote: Hi, could a resource leak or bug in pf(4) crash a RELENG_7 router (as of Oct 6th)? I'm experiencing frequent crashes on my soekris net4801 home router for some months now, and I'm wondering if it could be some kind of pf-related bug similar to this on OpenBSD: http://www.mail-archive.com/m...@openbsd.org/msg58042.html More precisely, when I fire up rtorrent-devel on some *other* machine (not the router!), everything runs fine at first. It could also run very fine for many days. BUT should I start a torrent with a large number of seeders which could saturate my link for an extended period of time, the soekris router would suddenly freeze... but not immediately: more like a few hours (3 to 6) or so of relatively heavy traffic. Only a hard reboot of the router would help. Please note that rtorrent is NOT running on the router, only its traffic is being redirected through the router. So I'm suspecting some bug / resource leak in pf that would bring the kernel down somehow. What kind of resources should I monitor (and how)? Maybe that could bring some clues? Oh, before anybody asks: I have no crashdumps, the router freezes totally without panicking. And it doesn't recover automatically even after many hours. Any ideas? Thanks, -cpghost. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rTorrent + FreeBSD + pf = freeze?
Hello everybody, I encountered same problems and am kinda glad to see I'm not alone. I use FreeBSD 7.1-RELEASE-p8 (GENERIC) on a VIA EPIA board (800MHz C3). This box for the moment does nothing but torrent. I use two instances of rtorrent. Each with an own user and in its own screen session. Let's name them A and B. A seeds around 300 torrents and B around 500 (each rtorrent instance communicates just to one specific tracker). The configuration is exactly the same, except B communicates with the track only using https (A does plain http). While A works 100% perfect an stable, B crashes the machine reproducible. When using rtorrent 0.8.3/0.12.3 this happened only about once a month. After upgrading to 0.8.4/0.12.4 the rate of crashes increased to about once a week. now i upgraded to 0.8.5/0.12.5 and cannot even start instance B without crashing the machine immediately just several minutes after I started it. Sometimes it somehow survives the starting procedure (where actually all seeding torrents are registered at the tracker at more or less the same time) but then it takes about 10min - 2 hours after the hole systems crashes again. Like I mentioned: instance B works perfectly without any problems. I'm pretty sure I encountered the problem also (even not the heavily) during times instance B was only seeding about 300 torrents... For me the system simply reboots and doesn't freeze. The logs are clear and show no advice concerning the problem. It's not a matter of hardware since I changed the board (which included CPU, RAM, NIC,...) and also the hard disc month ago. Also a heat problem can be excluded. Any clou about all that? btw: I don't use PF at all... regards - Michael On Wed, 21 Oct 2009, cpghost wrote: Hi, could a resource leak or bug in pf(4) crash a RELENG_7 router (as of Oct 6th)? I'm experiencing frequent crashes on my soekris net4801 home router for some months now, and I'm wondering if it could be some kind of pf-related bug similar to this on OpenBSD: http://www.mail-archive.com/m...@openbsd.org/msg58042.html More precisely, when I fire up rtorrent-devel on some *other* machine (not the router!), everything runs fine at first. It could also run very fine for many days. BUT should I start a torrent with a large number of seeders which could saturate my link for an extended period of time, the soekris router would suddenly freeze... but not immediately: more like a few hours (3 to 6) or so of relatively heavy traffic. Only a hard reboot of the router would help. Please note that rtorrent is NOT running on the router, only its traffic is being redirected through the router. So I'm suspecting some bug / resource leak in pf that would bring the kernel down somehow. What kind of resources should I monitor (and how)? Maybe that could bring some clues? Oh, before anybody asks: I have no crashdumps, the router freezes totally without panicking. And it doesn't recover automatically even after many hours. Any ideas? Thanks, -cpghost. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org