Re: recent 5.4-PRE regression: Could not resync/reset buffers
On Sat, Apr 02, 2005 at 03:44:53PM -0800, Kris Kennaway wrote: # On Sun, Apr 03, 2005 at 01:39:50AM +0200, Shaun Jurrens wrote: # # The trace doesn't look too wierd, otherwise. There was a warning about # having libm.so.2 and libm.so.3 causing a potential conflict during # compile... It seems to find the correct lib, but later also opens libm.so.2 # # That's a problem on your system that you should fix, then. It may not # be the cause of this problem, but it can definitely cause problems and # you need to rule it out. Ok, I've cleaned all of the relevant apps av libm.so.2 . The behavior still exihibits itself very often (90% of the time) but I can't catch it with ktrace. I've started playing with malloc.conf options to see if I can see if there's a problem there. It doesn't appear to be the correct approach yet, but... I can't kill then hanging mpg123 from the same tty either. It has to be killed from another prompt. # # Kris -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent 5.4-PRE regression: Could not resync/reset buffers
On Sat, Apr 02, 2005 at 03:44:53PM -0800, Kris Kennaway wrote: # On Sun, Apr 03, 2005 at 01:39:50AM +0200, Shaun Jurrens wrote: # # The trace doesn't look too wierd, otherwise. There was a warning about # having libm.so.2 and libm.so.3 causing a potential conflict during # compile... It seems to find the correct lib, but later also opens libm.so.2 # # That's a problem on your system that you should fix, then. It may not # be the cause of this problem, but it can definitely cause problems and # you need to rule it out. I am in agreement with you here in general terms. Specifically though, there's not much chance of getting rid of libm.so.2, because half the system uses it in some way (I just mv'd it once and things we very pear shaped fast). This, iirc, was some problem at 5.3-R with a version bump that broke things on amd64 at least. One noticed quickly that the binary pkg for cvsup needed this library, iirc. my /lib directory has what appears to be at least two such instances of stale libraries: -r--r--r-- 1 root wheel 125920 Sep 21 2004 libm.so.2 -r--r--r-- 1 root wheel 233624 Sep 21 2004 libreadline.so.4 which haven't been touched by further upgrades (I use 'INSTALL=install' instead of 'INSTALL=install -C' in /etc/make.conf). At this point, I haven't yet discovered how to solve this predicament. Even portupgrade is tied to libm.so.2 via ruby. This all seems to be a sort of timing issue anyway. As soon as I give the box something to do (compile something or other), mpg123 starts to work again as expected. # # Kris -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] [EMAIL PROTECTED] Blomsterkroken 44B 1344 Haslum Norway Tel. Mobil: +47 9268 0049 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent 5.4-PRE regression: Could not resync/reset buffers
On Fri, Apr 01, 2005 at 07:06:30PM -0800, Doug White wrote: # On Fri, 1 Apr 2005, Shaun Jurrens wrote: # # Hi guys, # # I'm resending this mail again with the hopes of finding someone who is also # seeing this problem. I know that mail isn't the best method perhaps, but # before I open a PR, I thought I'd try again... # # My last recent update revealed a bug perhaps. I'm now running: # # FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #28: Wed Mar 23 # 20:38:58 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 # # The system seems to have problems with filedescriptors. It's not otherwise # loaded and it's happed enough that I thought I should mention it before 5.4 # goes out the door (around 50% of the time). # # How to repeat: mpg123 -b 1024 --list playlist (where playlist is a simple # list of .mp3 files) # # I get this error message: # Could not resync/reset buffers: Interrupted system call # # and the program simply hangs using 90%+ cpu # # Try upgrading mpg123, for starters. Not handling ERESTART is generally a # bug. That said, I wonder if some syscall that was uninterrupible before # is now not. Can you ktrace mpg123 and try to capture one of the ERESTART # returns? I've recompiled mpg123 but cannot repoduce the hang if I start the program with the same arguments via ktrace (and if I start ktrace after the fact, I just get what I posted in the last mail). It seems to happen about 100% of the time now. I just upgraded world as well: FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #29: Fri Apr 1 23:55:02 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 The trace doesn't look too wierd, otherwise. There was a warning about having libm.so.2 and libm.so.3 causing a potential conflict during compile... It seems to find the correct lib, but later also opens libm.so.2 After we get all the libs loaded (or not, not using esd and friends) An excerpt of the ktrace: 3107 mpg123 CALL write(0x3,0x7fffe2a0,0x80) 3107 mpg123 GIO fd 3 wrote 128 bytes mpg123\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 3107 mpg123 RET write 128/0x80 3107 mpg123 CALL setsockopt(0x3,0x,0x1001,0x7fffe27c,0x4) 3107 mpg123 RET setsockopt 0 3107 mpg123 CALL setsockopt(0x3,0x,0x1002,0x7fffe27c,0x4) 3107 mpg123 RET setsockopt 0 3107 mpg123 CALL sigaction(0xd,0x7fffe250,0x7fffe230) 3107 mpg123 RET sigaction 0 3107 mpg123 CALL close(0x3) 3107 mpg123 RET close 0 3107 mpg123 CALL sigaction(0x2,0x7fffe3f0,0x7fffe3d0) 3107 mpg123 RET sigaction 0 3107 mpg123 CALL open(0x7fffe827,0,0x7fffe827) 3107 mpg123 NAMI 11_Wishlist.mp3 3107 mpg123 RET open 3 3107 mpg123 CALL lseek(0x3,0,0,0x2) 3107 mpg123 RET lseek 4943025/0x4b6cb1 3107 mpg123 CALL lseek(0x3,0,0xff80,0x2) 3107 mpg123 RET lseek 4942897/0x4b6c31 3107 mpg123 CALL read(0x3,0x7fffe350,0x80) 3107 mpg123 GIO fd 3 read 128 bytes 0x 5441 4757 6973 686c 6973 7400 |TAGWishlist.| 0x0010 || 0x0020 0050 6561 726c 204a 616d |.Pearl Jam..| 0x0030 0052 |...R| 0x0040 6561 7276 6965 776d 6972 726f 7220 2867 |earviewmirror (g| 0x0050 7265 6174 6573 7420 6869 7473 2032 3030 |reatest hits 200| 0x0060 3465 7820 4772 6970 2076 6961 2063 6464 |4ex Grip via cdd| 0x0070 6132 7761 7620 616e 6420 6c61 6d65 0b11 |a2wav and lame..| 3107 mpg123 RET read 128/0x80 3107 mpg123 CALL lseek(0x3,0,0,0) 3107 mpg123 RET lseek 0 3107 mpg123 CALL mmap(0,0x4b6c31,0x1,0x1,0x3,0,0) 3107 mpg123 RET mmap 13312000/0x800cb2000 3107 mpg123 CALL write(0x2,0x7fffdba0,0x3b) 3107 mpg123 GIO fd 2 wrote 59 bytes Title : WishlistArtist: Pearl Jam 3107 mpg123 RET write 59/0x3b 3107 mpg123 CALL write(0x2,0x7fffdba0,0x36) 3107 mpg123 GIO fd 2 wrote 54 bytes Album : Rearviewmirror (greatest hits Year : 2004 3107 mpg123 RET write 54/0x36 3107 mpg123 CALL write(0x2,0x7fffdba0,0x36) 3107 mpg123 GIO fd 2 wrote 54 bytes 0x 436f 6d6d 656e 743a 2065 7820 4772 6970 |Comment: ex Grip| 0x0010 2076 6961 2063 6464 6132 7761 7620 616e | via cdda2wav an| 0x0020 6420 6c61 6d65 0b20 2047 656e 7265 203a |d lame. Genre :| 0x0030 2052 6f63 6b0a | Rock.| 3107 mpg123 RET write 54/0x36 3107 mpg123 CALL write(0x2,0x7fffdc90,0x2e) 3107 mpg123 GIO fd 2 wrote 46 bytes
recent 5.4-PRE regression: Could not resync/reset buffers
Hi guys, I'm resending this mail again with the hopes of finding someone who is also seeing this problem. I know that mail isn't the best method perhaps, but before I open a PR, I thought I'd try again... My last recent update revealed a bug perhaps. I'm now running: FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #28: Wed Mar 23 20:38:58 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 The system seems to have problems with filedescriptors. It's not otherwise loaded and it's happed enough that I thought I should mention it before 5.4 goes out the door (around 50% of the time). How to repeat: mpg123 -b 1024 --list playlist (where playlist is a simple list of .mp3 files) I get this error message: Could not resync/reset buffers: Interrupted system call and the program simply hangs using 90%+ cpu I've ktraced the hanging binary, but the result is sort of monotonous. The ktrace.out file is filled with this simple set of lines: 94680 mpg123 RET read 0 94680 mpg123 CALL select(0x400,0x7fffe310,0,0,0) 94680 mpg123 RET select 1 94680 mpg123 CALL read(0x5,0x7fffe2ff,0x1) 94680 mpg123 GIO fd 5 read 0 bytes I haven't done the legwork yet to track this down to a closer time period than sometime since my last kernelworld, 25 december 04. (cc: me, I'm not on the list) -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
recent 5.4-PRE regression: Could not resync/reset buffers
Hi guys, My last recent update revealed a bug perhaps. I'm now running: FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #28: Wed Mar 23 20:38:58 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 The system seems to have problems with filedescriptors. It's not otherwise loaded and it's happed enough that I thought I should mention it before 5.4 goes out the door (around 50% of the time). How to repeat: mpg123 -b 1024 --list playlist (where playlist is a simple list of .mp3 files) I get this error message: Could not resync/reset buffers: Interrupted system call and the program simply hangs using 90%+ cpu I've ktraced the hanging binary, but the result is sort of monotonous. The ktrace.out file is filled with this simple set of lines: 94680 mpg123 RET read 0 94680 mpg123 CALL select(0x400,0x7fffe310,0,0,0) 94680 mpg123 RET select 1 94680 mpg123 CALL read(0x5,0x7fffe2ff,0x1) 94680 mpg123 GIO fd 5 read 0 bytes I haven't done the legwork yet to track this down to a closer time period than sometime since my last kernelworld, 25 december 04. (cc: me, I'm not on the list) -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Squid restarting often?
Ventsislav, Squid is simply growing beyond normal process size limits. The answer to your problem is easily found on squid-cache.org. See /sys/i386/conf/LINT especially: options MAXDSIZ=(256*1024*1024) options MAXSSIZ=(256*1024*1024) options DFLDSIZ=(256*1024*1024) and read the related text. IIRC there's a boot-time tunable via loader.conf as well. I'd go into more detail, but it's late and i gotta get some sleep. BTW, the 4x Xeons are overkill, and you'll need more mem for that much disk, but that's another ballgame alltogether. -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] [EMAIL PROTECTED] IRCNET nick: shamz #chillout #unix #FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
