Oddities in -current post-eventtimer
OK, this has happened a couple times now. I'm running a mid-Oct -CURRENT, and at around 25 days uptime (not exact but consistently in that vicinity), things start getting very choppy. It's easily visible in playing videos; things get very jerky and slow, but all sorts of things start acting like they're happening in little chunks of time; keyboard repeats get very slow, things that often take notable time take much more, etc. It's accompanied by a big spat of calcru: runtime went backwards messages (presumably just another symptom). The only fix I've found is to reboot, and then it's good for another 25ish days. As a workaround, enabling kern.eventtimer.idletick sets things rightish. A look at the interrupts turns up a hint; while vmstat says the overall average for cpu0 is just under 300/s, systat -vmstat shows that it's currnetly running around 20-some. The other CPU's also settle at much lower levels. Another more tiring workaround is just slinging the mouse around real fast; that seems to hint to the system to keep checking stuff. Watching systat, that doesn't seem to bring the cpuX interrupt rate up very much, but the videos start playing smoothly. FreeBSD 9.0-CURRENT #0 r214107: Wed Oct 20 06:25:50 CDT 2010 Quad-core running amd64. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Oddities in -current post-eventtimer
On 03.01.2011 12:28, Matthew D. Fuller wrote: OK, this has happened a couple times now. I'm running a mid-Oct -CURRENT, and at around 25 days uptime (not exact but consistently in that vicinity), things start getting very choppy. It's easily visible in playing videos; things get very jerky and slow, but all sorts of things start acting like they're happening in little chunks of time; keyboard repeats get very slow, things that often take notable time take much more, etc. It's accompanied by a big spat of calcru: runtime went backwards messages (presumably just another symptom). The only fix I've found is to reboot, and then it's good for another 25ish days. As a workaround, enabling kern.eventtimer.idletick sets things rightish. A look at the interrupts turns up a hint; while vmstat says the overall average for cpu0 is just under 300/s, systat -vmstat shows that it's currnetly running around 20-some. The other CPU's also settle at much lower levels. Another more tiring workaround is just slinging the mouse around real fast; that seems to hint to the system to keep checking stuff. Watching systat, that doesn't seem to bring the cpuX interrupt rate up very much, but the videos start playing smoothly. FreeBSD 9.0-CURRENT #0 r214107: Wed Oct 20 06:25:50 CDT 2010 Quad-core running amd64. Symptoms look very alike to ones fixed at r214597 on 2010-10-31: Fix callout_tickstofirst() behavior after signed integer ticks overflow. This should fix callout precision drop to 1/4s after 25 days of uptime with HZ = 1000. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Oddities in -current post-eventtimer
On Mon, Jan 03, 2011 at 01:21:10PM +0200 I heard the voice of Alexander Motin, and lo! it spake thus: Symptoms look very alike to ones fixed at r214597 on 2010-10-31: Shoot, I missed that going by. Sorry for the noise; I guess I've got a good excuse to go upgrade now 8-} -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
On 12/29/10 11:32, David Demelier wrote: Hello, Sometimes when I use my external harddrive I get these awful message : g_vfs_done():da1[WRITE(offset=34590720, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34656256, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34721792, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34787328, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34852864, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: g_vfs_done():ufs/public[WRITE(offset=244271529984, length=16384)]error = 5 /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: g_vfs_done():ufs/public[READ(offset=244563705856, length=131072)]error = 5 /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I Would a better message be WRITE error on da0, offset=34590720. length=65536, errno=5? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: jailing MYSQL error [SOLVED]
Hello, SOLVED ! But the problem was in another place. Host world and kernel were build with src r215329 (patched with head-v28-v2.patch from Martin Matuska), but ezjail buildworld was made using more recent sources with no patch (in fact I was trying to apply the same patch to more recent sources, but it doesn't work ... but that's another issue). Mysql seems to have problems in this case (kernel and world based on different versions of src). But other stuff work just fine. So, first I've made a jail (standard steps from the handbook) using the same src r215329 (patched for zfs v28). Mysql works fine under this jail. After this step, I've updated the ezjail basejail (ezjail-admin update -i). Now, Mysql works just fine under ezjail too. Thanks for your time and help. Regards, Lulu -Original Message- From: J. Hellenthal [mailto:jhellent...@gmail.com] On Behalf Of J. Hellenthal Sent: Monday, January 03, 2011 12:24 AM To: dsc fbsd.current Cc: freebsd-current@freebsd.org Subject: Re: jailing MYSQL error -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Just to be sure as the long detailed information that you laid before can lead to confusion, lets take this one step at a time. Assuming all your bases are covered and it sinks down to a permissions issue try this: chown root:wheel /path/to/jail/tmp /path/to/jail/var/tmp chmod 1777 /path/to/jail/tmp /path/to/jail/var/tmp rm -rf /path/to/jail/var/db/mysql - -Login to the jail here- make sure that rc.conf* only contains mysql_enable=YES service mysql-server start ls -ld /var/db/mysql should convey mode 700 or drwx-- and uid/88 gid/88 mysql/mysql At this point your mysql server should be running and fully working. Another thing to make sure you eliminate just in case... would be any my.cnf files in /etc or /usr/local/etc Good luck - -- Regards, jhell,v JJH48-ARIN -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJNIPrkAAoJEJBXh4mJ2FR+fLEH/0N91782PKGna/DZNoRF4hWJ 8tTh9bPFaHGjRu2ITC08gFJBLaAK8hE5oh9Tg5k6eysyzjE1EEHXUAJaL6B8Rg+N w5m66OGtvunX8JQqwu8d6ulDLk4EHex7Aaf0G2wfpW2OBDP4oCbeXxaakDJp+dzB GGf4a4ezODgQsr8Hxva71bgesfQ6a1BEirf/pwGcaQs9y1lCgoRK6M+iKDKqruLM Vyp4oNCHX52GTKa/cpx2VveZG/F21RabYtCVrBhU3Xq0EbDeDkiP2JjZt0xNPJVA dnCfCtTRECeruqlFHekH7MayF7uZ5nZIjJ3SEA6xHTCyt3PVC7oxr1NCmaETWJQ= =HFv4 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
Am 03.01.2011 14:14, schrieb Ivan Voras: On 12/29/10 11:32, David Demelier wrote: Hello, Sometimes when I use my external harddrive I get these awful message : g_vfs_done():da1[WRITE(offset=34590720, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34656256, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34721792, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34787328, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34852864, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: g_vfs_done():ufs/public[WRITE(offset=244271529984, length=16384)]error = 5 /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: g_vfs_done():ufs/public[READ(offset=244563705856, length=131072)]error = 5 /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I Would a better message be WRITE error on da0, offset=34590720. length=65536, errno=5? nah, strerror(errno) isn't that much of an effort ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: Am 03.01.2011 14:14, schrieb Ivan Voras: On 12/29/10 11:32, David Demelier wrote: /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I Would a better message be WRITE error on da0, offset=34590720. length=65536, errno=5? nah, strerror(errno) isn't that much of an effort In kernel ? There is no strerror, and there is no great need to import the sys_errlist. pgpQs7tVRFpdU.pgp Description: PGP signature
Another virtio drivers for FreeBSD
Hi freebsd-current, I noticed there are some threads about virtio drivers for FreeBSD and NetBSD on this mailing list, so I would like to post my virtio drivers. I've worked on these drivers for a few months to understand para-virtalized drivers. I sent early versions to Rusty Russel, the author of virtio, since I attended to Rusty's virtio session at LinuxCon 2010 Tokyo and decided to work on it. My virtio-net virtio-blk driver is not complete just now, but it looks working fine. I confirmed these drivers working with FreeBSD 8.1-R on Fedora 14 KVM. Both driver can deliver better performance than h/w emulation. http://ysr.jp/~hasegaw/virtio-20110103-2316.tar.gz I'm sorry for very nasty code; I am newbie in both of C and kernel-space code. ;) Now I am suffering with performance problem with virtio-blk driver. I've heard some people said FreeBSD's disk I/O on KVM is very poor so I have implemented block I/O, but the paravirtual driver's performance is still very bad - almost same with SCSI emulation, expecting CPU stress. http://ysr.jp/~hasegaw/20101203virtio-blk5.txt Now I am doubting FreeBSD and qemu-kvm's storage layer may not be compatible so well. Anyone is examining about this? I especially thank to Noriyuki Soda soda at netbsd dot org because he gave me a lot of advices when I was suffering with usage of bus_dma framework and some other issues. For NetBSD, it looks Makoto Minoura minoura at netbsd dot org has already ported virtio drivers. (I'm not sure these are already commited to main tree or not) http://www.minoura.org/~minoura/virtio-100605/ -- Takeshi HASEGAWA hase...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
Wiadomość napisana przez Kostik Belousov w dniu 2011-01-03, o godz. 15:18: On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: Am 03.01.2011 14:14, schrieb Ivan Voras: On 12/29/10 11:32, David Demelier wrote: /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I Would a better message be WRITE error on da0, offset=34590720. length=65536, errno=5? nah, strerror(errno) isn't that much of an effort In kernel ? There is no strerror, and there is no great need to import the sys_errlist. I had code that adds strerror() to the kernel in one of my old p4 branches. Error messages like the one above look much better this way, but I didn't have time to push it into the tree, and there is a risk of yet another i18n discussion. If someone is interested - let me know; I'll try to find it. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
On Jan 3, 2011, at 8:33 AM, Edward Tomasz Napierała tr...@freebsd.org wrote: Wiadomość napisana przez Kostik Belousov w dniu 2011-01-03, o godz. 15:18: On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: Am 03.01.2011 14:14, schrieb Ivan Voras: On 12/29/10 11:32, David Demelier wrote: /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I Would a better message be WRITE error on da0, offset=34590720. length=65536, errno=5? nah, strerror(errno) isn't that much of an effort In kernel ? There is no strerror, and there is no great need to import the sys_errlist. I had code that adds strerror() to the kernel in one of my old p4 branches. Error messages like the one above look much better this way, but I didn't have time to push it into the tree, and there is a risk of yet another i18n discussion. If someone is interested - let me know; I'll try to find it. Some thoughts: - It's a pain to parse (before I just had to scan for an int -- now it's a string?!?) - It slows down printing (slow kernel - dog slow system). - Fills up logs quicker if a subsystem or piece of hardware is going south and these messages slam syslog, which means I have to scan more logs looking for useful data, the likelihood of messages being lost in various buffers is higher, etc. Why not just provide a more standard sensical printout for the messages and provide a secret decoder ring in userland or something for interested parties the don't know that error is an errno value (eg my mom and dad because they're unix illiterate), or just copyout all of the error data via an ioctl, print out the ioctl failures, and skip the kernel level printing altogether? Thanks! -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
Garrett Cooper yaneg...@gmail.com writes: On Jan 3, 2011, at 8:33 AM, Edward Tomasz Napierała tr...@freebsd.org wrote: Wiadomość napisana przez Kostik Belousov w dniu 2011-01-03, o godz. 15:18: On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: Am 03.01.2011 14:14, schrieb Ivan Voras: On 12/29/10 11:32, David Demelier wrote: /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I Would a better message be WRITE error on da0, offset=34590720. length=65536, errno=5? nah, strerror(errno) isn't that much of an effort In kernel ? There is no strerror, and there is no great need to import the sys_errlist. I had code that adds strerror() to the kernel in one of my old p4 branches. Error messages like the one above look much better this way, but I didn't have time to push it into the tree, and there is a risk of yet another i18n discussion. If someone is interested - let me know; I'll try to find it. Some thoughts: - It's a pain to parse (before I just had to scan for an int -- now it's a string?!?) - It slows down printing (slow kernel - dog slow system). - Fills up logs quicker if a subsystem or piece of hardware is going south and these messages slam syslog, which means I have to scan more logs looking for useful data, the likelihood of messages being lost in various buffers is higher, etc. Why not just provide a more standard sensical printout for the messages and provide a secret decoder ring in userland or something Do you mean perror(1)? $ perror 5 Input/output error for interested parties the don't know that error is an errno value (eg my mom and dad because they're unix illiterate), or just copyout all of the error data via an ioctl, print out the ioctl failures, and skip the kernel level printing altogether? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
On Jan 3, 2011, at 10:20 AM, Anonymous wrote: Garrett Cooper yaneg...@gmail.com writes: On Jan 3, 2011, at 8:33 AM, Edward Tomasz Napierała tr...@freebsd.org wrote: Wiadomość napisana przez Kostik Belousov w dniu 2011-01-03, o godz. 15:18: On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: Am 03.01.2011 14:14, schrieb Ivan Voras: On 12/29/10 11:32, David Demelier wrote: /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I Would a better message be WRITE error on da0, offset=34590720. length=65536, errno=5? nah, strerror(errno) isn't that much of an effort In kernel ? There is no strerror, and there is no great need to import the sys_errlist. I had code that adds strerror() to the kernel in one of my old p4 branches. Error messages like the one above look much better this way, but I didn't have time to push it into the tree, and there is a risk of yet another i18n discussion. If someone is interested - let me know; I'll try to find it. Some thoughts: - It's a pain to parse (before I just had to scan for an int -- now it's a string?!?) - It slows down printing (slow kernel - dog slow system). - Fills up logs quicker if a subsystem or piece of hardware is going south and these messages slam syslog, which means I have to scan more logs looking for useful data, the likelihood of messages being lost in various buffers is higher, etc. Why not just provide a more standard sensical printout for the messages and provide a secret decoder ring in userland or something Do you mean perror(1)? $ perror 5 Input/output error Heh -- didn't realize that someone made a userland app for that libcall already :D... You learn new things everyday I guess :). In that case IMO nothing needs to be done minus (if you're interested) creating a parser that data mines stuff to make it more human readable in a common format, i.e. error: 5 (Input/output error) subsystem specific information does here that would make life when reporting PRs or issues on the list a lot more uniform and easier to follow, and could apply to several utilities (atacontrol, camcontrol, etc). My company has a similar in-house tool that does that, but it's not necessarily the easiest tool to deal with nor the most correct when it comes to some issues in FreeBSD. for interested parties the don't know that error is an errno value (eg my mom and dad because they're unix illiterate), or just copyout all of the error data via an ioctl, print out the ioctl failures, and skip the kernel level printing altogether? Thanks! -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous swel...@gmail.com wrote:
Do you mean perror(1)?
$ perror 5
Input/output error
I prefer mine:
$ errno () { grep ^#.*\\$*\\ /usr/include/sys/errno.h }
$ errno 5
#define EIO 5 /* Input/output error */
$ errno EIO
#define EIO 5 /* Input/output error */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
Bakul Shah ba...@bitblocks.com writes:
On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous swel...@gmail.com wrote:
Do you mean perror(1)?
$ perror 5
Input/output error
I prefer mine:
$ errno () { grep ^#.*\\$*\\ /usr/include/sys/errno.h }
$ errno 5
#define EIO 5 /* Input/output error */
$ errno EIO
#define EIO 5 /* Input/output error */
perror(1) displays localized messages
$ LANG=ja_JP.UTF-8 perror 5
入出力エラーです
$ LANG=uk_UA.UTF-8 perror 5
Помилка вводу-виводу
but I have to agree that knowing errno macro is useful
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No human readable message with g_vfs
On Mon, 03 Jan 2011 22:21:51 +0300 Anonymous swel...@gmail.com wrote:
Bakul Shah ba...@bitblocks.com writes:
On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous swel...@gmail.com wrote:
=20
Do you mean perror(1)?
=20
$ perror 5
Input/output error
I prefer mine:
$ errno () { grep ^#.*\\$*\\ /usr/include/sys/errno.h }
$ errno 5
#define EIO 5 /* Input/output error */
$ errno EIO
#define EIO 5 /* Input/output error */
perror(1) displays localized messages
$ LANG=3Dja_JP.UTF-8 perror 5
=E5=85=A5=E5=87=BA=E5=8A=9B=E3=82=A8=E3=83=A9=E3=83=BC=E3=81=A7=E3=81=99
$ LANG=3Duk_UA.UTF-8 perror 5
=D0=9F=D0=BE=D0=BC=D0=B8=D0=BB=D0=BA=D0=B0 =D0=B2=D0=B2=D0=BE=D0=B4=D1=83=
-=D0=B2=D0=B8=D0=B2=D0=BE=D0=B4=D1=83
Yes, definitely useful. Perhaps strerror would be a better name?
but I have to agree that knowing errno macro is useful
And you can use grep tricks :-)
$ errno '[dD]evice'
#define ENXIO 6 /* Device not configured */
#define ENOTBLK 15 /* Block device required */
#define EBUSY 16 /* Device busy */
#define EXDEV 18 /* Cross-device link */
#define ENODEV 19 /* Operation not supported by device */
#define ENOTTY 25 /* Inappropriate ioctl for device */
#define ENOSPC 28 /* No space left on device */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
AMD X2/Opteron Rev E workaround ?
Hi, it's been a while since this topic was touched, see http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013129.html. I coulnd't find anything more recent than the following commit, which prints a warning message, if a suspectible CPU model is detected: http://svn.freebsd.org/viewvc/base?view=revisionrevision=198868 If someone has any patches, even very preliminary ones, I'd be more than happy to give them a thorough try on otherwise unused machines. MfG CoCo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
