Re: Can't boot on ZFS -- /boot/zfsloader not found
On Thu, Jan 12, 2017 at 10:55 PM, Steven Hartland <kill...@multiplay.co.uk> wrote: > On 12/01/2017 21:12, Jeremie Le Hen wrote: > > Hey Steven, > > (Please cc: me on reply) > > On Thu, Jan 12, 2017 at 1:32 AM, Steven Hartlan > > The reason I'd recommend 512k for boot is to provide room for expansion > moving forward, as repartitioning to upgrade is a scary / hard thing to do. > Remember it wasn't long ago when it was well under 64k and that's what was > recommend, its not like with disk sizes these days you'll miss the extra > 384k ;-) > > Yeah, that's wise you're right. > > Boot to a live cd, I'd recommend mfsbsd, and make sure the boot loader was > written to ALL boot disks correctly e.g. > if you have a mirrored pool with ada0 and ada1: > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > > If this doesn't help the output from gpart show, uname -a and zpool status > would also be helpful. > > This is all assuming standard BIOS mode and not UEFI which is done > differently. > > I just use the installation media on an USB key and then drop to the > shell. This is a full FreeBSD running, so that's fine. > > % # gpart show ada0 > % => 40 312581728 ada0 GPT (149G) > % 40 1024 1 freebsd-boot (512K) > % 10648387840 2 freebsd-swap (4.0G) > %8388904 304192864 3 freebsd-zfs (145G) > % > % # uname -a > % FreeBSD 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep > 29 01:43:23 UTC 2016 % % > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > % > % # zpool status > % pool: zroot > % state: ONLINE > % scan: none requested > % config: > % > %NAME STATE READ > WRITE CKSUM > %zroot ONLINE 0 >0 0 > % gptid/1c387d3b-d892-11e6-944b-f44d30620eeb ONLINE 0 >0 0 > % > % errors: No known data errors > > Here are the steps to write the bootloader: > > % # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > % partcode written to ada0p1 > % bootcode written to ada0 > % # zpool get bootfs zroot > % NAME PROPERTY VALUE SOURCE > % zroot bootfszroot local > > Two things spring to mind > > Idea 1: > Is your root fs actually your direct pool or is it actually /root off your > pool. > If so you want to run: > zpool set bootfs=zroot/root zroot That was it. My boot volume is "zroot/root" and I was just following brainlessly the doc which said to use "zroot". This didn't shock me because this at least points to the right pool > > Idea 2: > You mentioned in your original post and you used zfs send / recv to restore > the pool, so I wonder if your cache file is out of date. > > Try the following: > zpool export zroot > zpool import -R /mnt -o cachefile=/boot/zfs/zpool.cache zroot > cp /boot/zfs/zpool.cache /mnt/boot/zfs/zpool.cache > zpool set bootfs=zroot/root zroot I think that was wrong too, but this would probably have caused problems later in the boot I think. Anyway, thanks a lot for your help. I'll give a quick lifting to the wiki page. -jlh > > Regards > Steve -- Jeremie Le Hen j...@freebsd.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't boot on ZFS -- /boot/zfsloader not found
Hey Steven, (Please cc: me on reply) On Thu, Jan 12, 2017 at 1:32 AM, Steven Hartlan > The reason I'd recommend 512k for boot is to provide room for expansion > moving forward, as repartitioning to upgrade is a scary / hard thing to do. > Remember it wasn't long ago when it was well under 64k and that's what was > recommend, its not like with disk sizes these days you'll miss the extra > 384k ;-) Yeah, that's wise you're right. > Boot to a live cd, I'd recommend mfsbsd, and make sure the boot loader was > written to ALL boot disks correctly e.g. > if you have a mirrored pool with ada0 and ada1: > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > > If this doesn't help the output from gpart show, uname -a and zpool status > would also be helpful. > > This is all assuming standard BIOS mode and not UEFI which is done > differently. I just use the installation media on an USB key and then drop to the shell. This is a full FreeBSD running, so that's fine. % # gpart show ada0 % => 40 312581728 ada0 GPT (149G) % 40 1024 1 freebsd-boot (512K) % 10648387840 2 freebsd-swap (4.0G) %8388904 304192864 3 freebsd-zfs (145G) % % # uname -a % FreeBSD 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 % % r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 % % # zpool status % pool: zroot % state: ONLINE % scan: none requested % config: % %NAME STATE READ WRITE CKSUM %zroot ONLINE 0 0 0 % gptid/1c387d3b-d892-11e6-944b-f44d30620eeb ONLINE 0 0 0 % % errors: No known data errors Here are the steps to write the bootloader: % # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 % partcode written to ada0p1 % bootcode written to ada0 % # zpool get bootfs zroot % NAME PROPERTY VALUE SOURCE % zroot bootfszroot local -- Jeremie Le Hen j...@freebsd.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't boot on ZFS -- /boot/zfsloader not found
(Sorry I had to copy-paste this email from the archives to a new thread, because I'm not subscribed to -stable@. Would you mind cc:ing me next time please?) > As your not at the boot loader stage yet for keyboard enabling legacy > USB keyboard / mouse support in BIOS may help. That worked, thanks for the tip. > If you see issues with keyboard after the kernel takes over setting > hint.ehci.0.disabled=1 may help. > > If your installing 11.x then the guides boot partition size is out of > date and you should use 512K for your freebsd-boot partition. Oh, really? I'll update it once I'll have figure it all out. That's weird though because /boot/gptzfsboot is less than 90 KB. > For the GPT version (I've never used MBR one) what actual error do you get? When I just start up the NUC, I get: """ \Can't find /boot/zfsloader FreeBSD/x86 boot Default: zroot:/boot/kernel/kernel boot: \ Can't find /boot/kernel/kernel """ I though it was the first stage boot loader, but it may be the second stage. -jlh > > On 11/01/2017 19:22, Jeremie Le Hen wrote: > > Hi, > > > > I'm in the process of transferring my home server to an Intel NUC. I've zfs > > send/receive'd the whole pool to the new drive and first followed > > [ZfsOnGpt] but it fails in the first stage boot loader. The USB keyboard > > doesn't seem to be recognized so I can't really debug anything. > > > > Then I tried both [ZfsInMbrSlice] > > but it complains that it can't find /boot/zfsloader. Again USB keyboard > > doesn't work. > > > > Both times I've been very careful to install the bootcodes at the right > > place. > > > > 1. Any idea why the USB keyboard doesn't work? > > 2. Any idea what can be wrong in the setups I tried? How can I debug this? > > > > [ZfsOnGpt] https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot > > [ZfsInMbrSlice] https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition > > > > -jlh > > ___ > > freebsd-stable at freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" -- Jeremie Le Hen j...@freebsd.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Can't boot on ZFS -- /boot/zfsloader not found
Hi, I'm in the process of transferring my home server to an Intel NUC. I've zfs send/receive'd the whole pool to the new drive and first followed [ZfsOnGpt] but it fails in the first stage boot loader. The USB keyboard doesn't seem to be recognized so I can't really debug anything. Then I tried both [ZfsInMbrSlice] but it complains that it can't find /boot/zfsloader. Again USB keyboard doesn't work. Both times I've been very careful to install the bootcodes at the right place. 1. Any idea why the USB keyboard doesn't work? 2. Any idea what can be wrong in the setups I tried? How can I debug this? [ZfsOnGpt] https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot [ZfsInMbrSlice] https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition -jlh ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On Thu, Mar 21, 2013 at 06:46:57PM -0600, Jamie Gritton wrote: It's not fixed anywhere yet - it sometimes works in current, and sometimes doesn't. I've been meaning to patch it up, but it the problem is what I think it is, the patching up is a pretty big operation. It doesn't mean you can't use jails with devfs in 9.1, just that you can't use them with jail.conf. The old jail rc file that's all shell-based is still the official jail startup method, and that one still works. So existing systems will still work as expected, hence no errata. Shouldn't we warn the user about that in the manpage though? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gdb broken on 9.1/amd64?
(Please Cc: me on reply.) On Wed, Mar 06, 2013 at 10:50:59PM +0200, Konstantin Belousov wrote: On Wed, Mar 06, 2013 at 07:02:22PM +0100, Jeremie Le Hen wrote: root@ingwe:~ # gdb -p 521 Try to specify the executable binary on the command line. It works better indeed! Now I can get a backtrace for sleep(1), but I am experiencing difficulties to debug OpenSTMPD: # gdb /usr/local/sbin/smtpd 25442 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Attaching to program: /usr/local/sbin/smtpd, process 25442 Reading symbols from /usr/local/lib/libsqlite3.so.8...done. Loaded symbols for /usr/local/lib/libsqlite3.so.8 Reading symbols from /usr/local/lib/libevent-1.4.so.4...done. Loaded symbols for /usr/local/lib/libevent-1.4.so.4 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /usr/lib/libssl.so.6...done. Loaded symbols for /usr/lib/libssl.so.6 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libutil.so.9...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libcrypt.so.5...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /usr/lib/libpam.so.5...done. Loaded symbols for /usr/lib/libpam.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libthr.so.3...done. Error while reading shared library symbols: Cannot get thread info: invalid key Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x00080ce4281c in kevent () from /lib/libc.so.7 (gdb) bt #0 0x00080ce4281c in kevent () from /lib/libc.so.7 #1 0x000803104070 in kq_dispatch () from /usr/local/lib/libevent-1.4.so.4 #2 0x0008030f802a in event_base_loop () from /usr/local/lib/libevent-1.4.so.4 #3 0x0042fd7f in smtp () at smtp.c:295 #4 0x00436c0f in fork_peers () at smtpd.c:983 #5 0x0043686d in main (argc=0, argv=0x7fff77e8) at smtpd.c:904 (gdb) c Continuing. no thread to satisfy query 0x00080ce4281c in kevent () from /lib/libc.so.7 The problem is that the process seems hung here, despite the continue. When I am connecting to it, I say HELO but I don't get any reply if gdb(1) is attached. Also, the following might be relevant? (gdb) thread apply all c Cannot get thread info: invalid key Any idea? Thanks. Cheers, -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
gdb broken on 9.1/amd64?
Hi guys, (Can you please Cc: me on reply, I am not subscribed to this list.) I have two different stable/9.1 amd64 machines which show the following error message upon gdb startup: /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1444: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. Can you check if you have the same problem (same or other arch)? Thanks. Example below: root@ingwe:~ # sleep 3600 [1] 521 root@ingwe:~ # gdb -p 521 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. Attaching to process 521 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1444: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1444: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Reading symbols from /bin/sleep...(no debugging symbols found)...done. Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 0x0008059f188c in nanosleep () from /lib/libc.so.7 (gdb) bt #0 0x0008059f188c in nanosleep () from /lib/libc.so.7 #1 0x00400883 in ?? () #2 0x004006f1 in ?? () #3 0x00080189 in ?? () #4 0x in ?? () -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: new jail(8) ignoring devfs_ruleset?
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that devfs_ruleset seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set devfs_ruleset = 4; and enforce_statfs = 1; in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes 1. But like mentioned, I can access all devices... Thanks for any help, -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is 4 by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with mount - and noticed the non-reverted umounting. Look at what's in /dev from you jail. There should a few pseudo devices (see below), but no real devices: $ ls /dev crypto log ptmxrandom stdin urandom zfs fd nullpts stderr stdout zero -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CLANG and -fstack-protector
Hi Kimmo, On Thu, Feb 07, 2013 at 10:06:49PM +0100, Dimitry Andric wrote: On 2013-02-07 20:42, Kimmo Paasiala wrote: Does the -fstack-protector option work on CLANG 3.1 and 3.2? Yes, it works with both clang and gcc. There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 That thread seems to be full of confusion. :-) The base system is mostly built with -fstack-protector, except for the ia64, arm and mips arches, and for some specific cases where it is not necessary, or unwanted. Ports are largely independent of the base system, and their compilation flags are different from port to port. You could set -fstack-protector for your ports in either make.conf or ports.conf, if you wanted. You can do this, it will work for most of the ports but some ports do not honor CFLAGS. If those ports happen to be linked againsst libraries that were compiled with -fstack-protector, you will get a missing symbol error. Well, to be honest, I don't remember enough details, they faded from my memory, I need to check this. So if you care about security enough, go for it! If you meet weird error like a missing stack_chk_fail symbol for some ports (lang/perl might be a candidate in my memory), then look at the PR below, it will probably solve your problem. Time has passed and I am interested in your feedback without the patch (and then with, if relevant). Basically the following PR contains a patch that waits for an exp run to be committed into the base system. This just turns libc.so into an ld script that pulls in libssp_nonshared.a. You just have to run make all install in src/lib/libc after applying it. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168010 I run it on my servers with -fstack-protector enabled for ports without any problem. Cheers! -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: File too large error when appending to a file of 130 MB
On Mon, Feb 20, 2012 at 06:05:16PM -0500, Rick Macklem wrote: Sorry, I have no idea. Maybe one of the ZFS folks knows when ACLs are generated. (It might happen as a side effect of a chmod. You could experiment with that?) Interestingly, such ACLs only appear on my nullfs mounted ZFS dataset. If I look directly at the underlying ZFS dataset, there is no ACL. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: File too large error when appending to a file of 130 MB
Hi Phil, On Tue, Feb 21, 2012 at 02:24:39PM +1300, Phil Murray wrote: On 20/02/2012, at 10:36 AM, Jeremie Le Hen wrote: I have a problem with procmail which gets a File too large error when it tries to write at the end of some mailbox file. Is procmail running from Postfix (or some other MTA)? I've hit this problem where Postfix has set a filesize ulimit, which all the scripts spawned from Postfix will inherit. In my case, I had a script that was hitting the filesize limit trying to log it's results to a logfile that doesn't get rotated. I imagine the same thing could happen with procmail, if postfix was calling it. Yes that was the problem indeed. Someone already contacted me (privately, but I didn't notice at that time) pointing out the problem. I've disabled the mailbox_size_limit in Postfix and the problem vanished. Thanks for your help. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: File too large error when appending to a file of 130 MB
Hi Rick, On Sun, Feb 19, 2012 at 07:46:42PM -0500, Rick Macklem wrote: This is a 8.2 32 bits jail on a 8.2 amd64 host. In the jail, /home is a nullfs mounted ZFS filesystem. The mailbox is not that big: % felucia:jlh$ ls -l Mail/mbox1 % -rw---+ 1 jlh jlh 138744672 Feb 19 11:46 Mail/mbox1 (( For some unknown reason some ACL keep appearing, but the problem if still there anyway if I do setfacl -b on it: % felucia:jlh$ getfacl Mail/mbox1 % # file: Mail/mbox1 % # owner: jlh % # group: jlh % owner@:rw-p--aARWcCos:--:allow % group@:--a-R-c--s:--:allow % everyone@:--a-R-c--s:--:allow )) Does anyone have an idea about this error? Besides, if someone knows why those ACLs keep appearing, I would be glad to know it :). AFAIK, NFSv4 style ACLs are always enabled for ZFS and cannot be turned off. Weirdly, some of my mailboxes don't have such ACLs, including some I've recently written into. How is it possible? -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
File too large error when appending to a file of 130 MB
Hi list,
Can you please Cc: me when replying as I'm not subscribed, thanks.
I have a problem with procmail which gets a File too large error when
it tries to write at the end of some mailbox file.
I truss'ed it and I found the following:
% stat(/home/jlh/Mail//mbox1,{ mode=-rw---
,inode=336983,size=138744672,blksize=131072 }) = 0 (0x0)
% open(/home/jlh/Mail//mbox1,O_WRONLY|O_APPEND|O_CREAT,0667) = 5 (0x5)
% lseek(5,0x0,SEEK_END)= 138744672 (0x8451360)
% wait4(0x,0x0,0x1,0x0,0x3,0x5)ERR#10 'No child processes'
% lseek(5,0x0,SEEK_CUR)= 138744672 (0x8451360)
% fcntl(5,F_SETLKW,0xd9a4) = 0 (0x0)
% lseek(5,0x0,SEEK_END)= 138744672 (0x8451360)
% write(5,F,1) ERR#27 'File too large'
% fstat(5,{ mode=-rw--- ,inode=336983,size=138744672,blksize=131072 }) = 0
(0x0)
% write(5,rom lionel.messien+caf_=jlh=chch...,3627) ERR#27 'File too large'
I can append something to the file manually. I wonder if the error
doesn't come from the SETLKW fnctl(2) call, but I cannot experiment it
because truss(1) doesn't show the content of the flock structure.
If I change the procmail recipe to write to another file (which doesn't
exist), the file is successfully created and messages can be appended.
I narrowed down the failure threshold between 48 MB and 49 MB (in steps
of 64 KB, it failed between 781 and 782 blocks).
This is a 8.2 32 bits jail on a 8.2 amd64 host. In the jail, /home is a
nullfs mounted ZFS filesystem. The mailbox is not that big:
% felucia:jlh$ ls -l Mail/mbox1
% -rw---+ 1 jlh jlh 138744672 Feb 19 11:46 Mail/mbox1
(( For some unknown reason some ACL keep appearing, but the problem if still
there
anyway if I do setfacl -b on it:
% felucia:jlh$ getfacl Mail/mbox1
% # file: Mail/mbox1
% # owner: jlh
% # group: jlh
% owner@:rw-p--aARWcCos:--:allow
% group@:--a-R-c--s:--:allow
% everyone@:--a-R-c--s:--:allow
))
Does anyone have an idea about this error? Besides, if someone knows
why those ACLs keep appearing, I would be glad to know it :).
Thanks.
--
Jeremie Le Hen
Men are born free and equal. Later on, they're on their own.
Jean Yanne
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Panic in ZFS layer on 8.1-STABLE
Hi, [ Please Cc: me when replying, as I'm not subscribed to -sta...@. ] My filer at home runs FreeBSD. A single data RAID-1 zpool with 10~15 datasets, two of them using compression. Over the night, I got the following panic: Tracing pid 0 tid 100111 td 0x86393a00 kdb_enter(809faa5b,809faa5b,80a12e84,cb114aec,0,...) at kdb_enter+0x3a panic(80a12e84,1c000,2e3e8000,80a12e7e,7d0,...) at panic+0x131 kmem_malloc(8169008c,1c000,2,cb114b6c,80909a99,...) at kmem_malloc+0x285 page_alloc(0,1c000,cb114b5f,2,2f0c800,...) at page_alloc+0x27 uma_large_malloc(1c000,2,0,8609b3f0,30,...) at uma_large_malloc+0x4a malloc(1c000,860b2120,2,cb114bb0,8601d36d,...) at malloc+0x7c zfs_kmem_alloc(1c000,2,cb114bf0,8601f77b,1c000,...) at zfs_kmem_alloc+0x20 zio_buf_alloc(1c000,cb114c30,86008817,92c33bd0,cb114bf0,...) at zio_buf_alloc+0x44 zio_compress_data(3,b4264000,2,0,cb114c58,...) at zio_compress_data+0x8b zio_write_bp_init(92c339c0,92bba254,cb114c80,8071a322,cb114ca0,...) at zio_write_bp_init+0xff zio_execute(92c339c0,8638e0c0,cb114cd0,8071c5f4,92c33c14,...) at zio_execute+0xab taskq_run_safe(92c33c14,1,0,80a8429c,0,...) at taskq_run_safe+0x13 taskqueue_run(8638e0c0,8638e0d8,0,809ef596,0,...) at taskqueue_run+0x15d taskqueue_thread_loop(8638c3d0,cb114d38,8071c72a,0,cb114d20,...) at taskqueue_thread_loop+0xbd fork_exit(8071c72a,8638c3d0,cb114d38) at fork_exit+0x91 fork_trampoline() at fork_trampoline+0x8 I couldn't get a crash dump, sorry. However, I'm still using the same kernel so I can probably use addr2line(1) if you need it. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Panic in ZFS layer on 8.1-STABLE
On Wed, Dec 15, 2010 at 07:28:57PM +0200, Andriy Gapon wrote: on 15/12/2010 10:28 Jeremie Le Hen said the following: Hi, [ Please Cc: me when replying, as I'm not subscribed to -sta...@. ] My filer at home runs FreeBSD. A single data RAID-1 zpool with 10~15 datasets, two of them using compression. Over the night, I got the following panic: Thanks for the stack trace! But where is the promised panic message? :) Eheh, sorry for this :-). I suspect that you ran out of kernel address space. You'd probably have to tune your system and/or add more memory. Please research this topic via mailing lists archives. You guessed right! panic: kmem_malloc(114688): kmem_map too small: 775847936 total allocated I think running a 64 bits kernel would help a lot in that case. Unfortunately I don't think my CPU supports the instruction set: CPU: Intel(R) Core(TM)2 CPU 6320 @ 1.86GHz (1869.88-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF TSC: P-state invariant I will look into the wiki about ZFS tuning. Thanks, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cannot install using serial console
Hi, On Thu, Sep 09, 2010 at 06:48:11PM +0400, pluknet wrote: On 7 September 2010 18:50, Jeremie Le Hen jere...@le-hen.org wrote: Hi list, = Please Cc: me when replying, as I am not subscribed. = I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think it's important here) in a KVM-backed virtual machine on a headless Linux host, following section 2.12.1 of the handbook. http://www.freebsd.org/doc/handbook/install-advanced.html I've rebuilt the ISO image with the following lines in boot/loader.conf: console=comconsole beastie_disable=YES The kernel boots correctly (see output below) but the output invariably stalls after the following lines: Trying to mount root from ufs:/dev/md0 /stand/sysinstal (Yes, only one `l'.) Any idea? [strip] WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/md0 As far as I know you need also to enable a serial terminal in /etc/ttys. Yeah, this came to my mind too but I check on the installation CD, there is no /etc/ttys. -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cannot install using serial console
Hi Jeremy, On Fri, Sep 10, 2010 at 04:27:26AM -0700, Jeremy Chadwick wrote: As far as I know you need also to enable a serial terminal in /etc/ttys. Yeah, this came to my mind too but I check on the installation CD, there is no /etc/ttys. This is normal. Can you try hacking up a solution for yourself based on what I've documented with regards to PXE booting? There will be pieces which obviously don't apply to you because you're booting from physical media, but some of the adjustments (to the bootloader, etc.) you can try. http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html But as far as I understand the handbook, this is not required to perform the installation through sysinstall(8) on a serial console. Modifying /boot/loader.conf on the installation media is enough according to chapter 2.12.1. Am I wrong? One thing worth pointing out is that you stated the system that you're trying to use serial console on is actually running under a VM on Linux: I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think it's important here) in a KVM-backed virtual machine on a headless Linux host, following section 2.12.1 of the handbook. Can you provide a full dmesg prior to the /stand/sysinstal output happening? You don't need to boot verbose (yet), but it would help with regards to determining what the kernel is seeing device-wise. Yes it matters. Yes, I've actually already posted it in my original message: http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058703.html Thanks for you attention. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Cannot install using serial console
-- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Panic in destroy_dev_sched_cb() for tty
On Tue, Jul 06, 2010 at 12:54:36AM +0200, Ed Schouten wrote: * Jeremie Le Hen jere...@le-hen.org wrote: I've got a panic obviously from the tty layer but I couldn't get the panic string as no remote system was connected using serial console, and I don't know how to print it from DDB. Hmmm... This is a tricky one, but I think I do understand what's going on here. If you close and revoke a TTY at the very exact moment, it may call destroy_dev_sched_cb() twice, where the second time it gets called on a null pointer. === --- sys/kern/tty.c(revision 209570) +++ sys/kern/tty.c(working copy) @@ -1040,7 +1040,8 @@ tp-t_dev = NULL; tty_unlock(tp); - destroy_dev_sched_cb(dev, tty_dealloc, tp); + if (dev != NULL) + destroy_dev_sched_cb(dev, tty_dealloc, tp); } void I guess it's very hard to reproduce, right? If so, I'll just commit it to SVN. Thanks for reporting! Sure it is. I use screen heavily and this is the first time I get it. Please go forward, I will update my kernel after it has been MFC and I won't miss informing you if it occurs again. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Panic in destroy_dev_sched_cb() for tty
Hi Ed, I've got a panic obviously from the tty layer but I couldn't get the panic string as no remote system was connected using serial console, and I don't know how to print it from DDB. However here is the relevant stuff I could get: db show pcpu cpuid= 0 dynamic pcpu= 0x5a0600 curthread= 0x87cae240: pid 7701 screen curpcb = 0xcb1ebd90 fpcurthread = none idlethread = 0x85544900: pid 11 idle: cpu0 APIC ID = 0 currentldt = 0x50 db trace Tracing pid 7701 tid 100302 td 0x87cae240 destroy_dev_sched_cb(0,807137fb,9eff1200,9eff1254) at destroy_dev_sched_cb+0x10 tty_rel_free(9eff1290,0,1,0) at tty_rel_free+0xc7 ttydev_leave(9eff1290,0,0,0,0,...) at ttydev_leave+0x136 ttydev_close(9c756d00,7,2000,87cae240,cb1ebb14,...) at ttydev_close+0xf4 devfs_close(cb1ebb2c,cb1ebb50,80760b10,80a48120,cb1ebb2c,...) at devfs_close+0x3ae VOP_CLOSE_APV(80a48120,cb1ebb2c,809d7133,128,80a84000,...) at VOP_CLOSE_APV+0x44 vn_close(87cee648,7,8a965780,87cae240,80a84300,...) at vn_close+0xd1 vn_closefile(8788f658,87cae240,8788f658,0,cb1ebbe0,...) at vn_closefile+0xfe devfs_close_f(8788f658,87cae240,cb1ebc18,0,1,...) at devfs_close_f+0x27 _fdrop(8788f658,87cae240,8a965780,87cae240,865b7310,...) at _fdrop+0x43 closef(8788f658,87cae240,900fed48,2,876511d0,...) at closef+0x31b kern_close(87cae240,4,cb1ebd2c,8096147c,87cae240,...) at kern_close+0x16d close(87cae240,cb1ebcf8,4,c,c,...) at close+0x1a syscall(cb1ebd38) at syscall+0x320 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2821b63f, esp = 0x7fbfe1bc, ebp = 0x7fbfe1c8 --- The system is running 8.0-STABLE from around 2009/12/06. Thanks. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cannot list a particular directory through NFS with UDP
Rick, Thanks for your time on this. On Thu, Dec 31, 2009 at 02:23:32PM -0500, Rick Macklem wrote: [stuff snipped] This appears to be the reply to the nfs readdir request, which is what would be expected. It could be a problem with the content or the reply or a NetBSD client issue. If you were to email me the raw tcpdump capture for the above, I could take a look at it in wireshark (which knows how to interpret nfs) and see if there is anything bogus looking in the reply. (tcpdump -s 0 -w file host 192.168.1.1 and then email me file as an attachment, should do it) You will find the pcap file attached. Well, I looked at it under wireshark and the readdir reply looks fine. (It is made up of two IP fragments, but wireshark reassembles them ok and says the checksums are ok. The contents look like a valid Readdir RPC reply.) Maybe NetBSD doesn't reassemble the IP fragments correctly or has an issue w.r.t. the checksum, but Wireshark thinks it's aok. I will reduce the MTU and see if the problem arises with directories that could be read correctly otherwise. I will keep you informed. Does NFS permit to fragment/reassemble at the application layer? ps: I vaguely recall that the problem went away when you used TCP instead. Is that correct? Yes this is correct. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than the others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cannot list a particular directory through NFS with UDP
Hi Rick, Sorry for the delayed reply, but I have had little time available with Christmas. On Fri, Dec 18, 2009 at 03:23:44PM -0500, Rick Macklem wrote: 00:00:01.953196 IP (tos 0x0, ttl 64, id 48966, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 192.168.1.222.2049: 140 readdir [|nfs] 00:00:01.953665 IP (tos 0x0, ttl 64, id 27028, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 00:00:01.953711 IP (tos 0x0, ttl 64, id 27028, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 192.168.1.1: udp This appears to be the reply to the nfs readdir request, which is what would be expected. It could be a problem with the content or the reply or a NetBSD client issue. If you were to email me the raw tcpdump capture for the above, I could take a look at it in wireshark (which knows how to interpret nfs) and see if there is anything bogus looking in the reply. (tcpdump -s 0 -w file host 192.168.1.1 and then email me file as an attachment, should do it) You will find the pcap file attached. FYI, I've tried to use rdirplus option from NetBSD NFS client as a workaround but the mount stalls in UDP (works in TCP). If you are also interested in this problem, I can provide a trace quickly this time :). Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than the others. Coluche pcap.nfs-udp Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cannot list a particular directory through NFS with UDP
On Mon, Dec 14, 2009 at 10:50:40AM -0500, John Baldwin wrote: It looks like the NFS client does not like the replies to the 3819288094 request. Can you grab nfsstat output before and after a retransmit of the request and reply to see which counters are increased? This might indicate why the reply is not being accepted. Premices (replayed each time to have the exact same cache): # umount /mnt/repos # mount -t nfs -o intr,soft obiwan:/data/repos /mnt/repos # cd /mnt/repos/netbsd-cvsroot # ls Running ls(1) on a good directory shows the following difference: # ls src Server: Client: - +3 getattr- +3 getattr - +1 lookup - +1 lookup - +1 readdir- +1 readdir - +1 access - +1 access Client cache: - +9 attrcache - +2 lookupcache - +2 readdir - +2 direofcache Running ls(1) on the bad directory shows the following difference: # ls pkgsrc Server: Client: - +3 getattr- +3 getattr - +1 lookup - +1 lookup - +1 readdir- +1 readdir - +3 access - +3 access Client cache: - +5 attrcache - +1 lookupcache Both scenarios show no error. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cannot list a particular directory through NFS with UDP
Hi Rick, On Mon, Dec 14, 2009 at 11:14:06AM -0500, Rick Macklem wrote: My NFS server is running FreeBSD 8.0 from December 6th. The client is a NetBSD 5.0. The directory exported is /data/repos on the server (192.168.1.222) and is mounted on /mnt/repos on the client (192.168.1.1). The problem exists in /data/repos/netbsd-cvsroot/pkgsrc when using NFS over UDP: ls(1) stalls. OTOH, for instance, listing another directory or using NFS over TCP work flawlessly. I'll take a look and let you know if I can think of anything. A couple of things: - What arch/net interface is the server running? - I haven't seen any issues w.r.t. i386, so I'm thinking it might be some sort of 64bit/alignment problem. (dfr@ replaced the RPC transport code with a new krpc subsystem for FreeBSD8.0 and known issues w.r.t. alignment were fixed, but there may be more) Both are i386. If you wanted to, you could try using the experimental server instead (-e option for mountd and nfsd), just to see if that makes the problem go away. (It handles mbuf lists/alignment somewhat differently.) I think I have to recompile my kernel, don't I? I tried to set nfsv4_server_enable=YES in my rc.conf, but it refused to start. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than the others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Cannot list a particular directory through NFS with UDP
1500) 192.168.1.222.2049 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 23:59:17.046538 IP (tos 0x0, ttl 64, id 53175, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 192.168.1.1: udp 00:00:01.953196 IP (tos 0x0, ttl 64, id 48966, offset 0, flags [none], proto UDP (17), length 168) 192.168.1.1.3819288094 192.168.1.222.2049: 140 readdir [|nfs] 00:00:01.953665 IP (tos 0x0, ttl 64, id 27028, offset 0, flags [+], proto UDP (17), length 1500) 192.168.1.222.2049 192.168.1.1.3819288094: reply ok 1472 readdir POST: DIR 755 ids 0/0 [|nfs] 00:00:01.953711 IP (tos 0x0, ttl 64, id 27028, offset 1480, flags [none], proto UDP (17), length 632) 192.168.1.222 192.168.1.1: udp Regards, -- Jeremie Le Hen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Cannot allocate system-mode PMC with spec. instructions
Hi list, Joseph, __ Please Cc: me when replying, as I'm not subscribed. __ I've tried to sample my system while performing a big copy between UFS to ZFS using the following command: % # pmcstat -v -S instructions -O $PWD/sample.out % pmcstat: ERROR: Cannot allocate system-mode pmc with specification instructions: Invalid argument Oddly, other generic events lead to different errors: % obiwan:~/tmp# pmcstat -vv -S cycles -O $PWD/sample.out % pmcstat: ERROR: Cannot allocate system-mode pmc with specification cycles: Operation not supported But for instance the following works: % obiwan:~/tmp# pmcstat -vv -S branches -O $PWD/sample.out % ^Cobiwan:~/tmp# pmcstat -R sample.out -g % CONVERSION STATISTICS: % #samples/total 3110 % #samples/unclaimed 87 % #callchain/dubious-frames87 Additional useful informations are: % CPU: Intel(R) Core(TM)2 CPU 6320 @ 1.86GHz (1869.87-MHz 686-class CPU) % Origin = GenuineIntel Id = 0x6f6 Stepping = 6 % Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE % Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM % AMD Features=0x2000LM % AMD Features2=0x1LAHF % TSC: P-state invariant % hwpmc: TSC/1/64/0x20REA IAP/2/40/0x3ffINT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC IAF/0/0/0x61INT,REA,WRI Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: The Design and Implementation of the FreeBSD Operating System
Hi, On Fri, Mar 14, 2008 at 07:41:30AM -0700, Unga wrote: Is the following book still relevant to FreeBSD 7.X and upcoming FreeBSD 8.X? Is there a 2nd edition coming soon? The Design and Implementation of the FreeBSD Operating System By Marshall Kirk McKusick, George V. Neville-Neil Published Aug 2, 2004 by Addison Wesley Professional. 1st. Edition ISBN-10: 0-201-70245-2 http://www.informit.com/title/0201702452 FWIW there has been rumours about the next edition of this book covering a recenter version. That's all I know :). Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cu: Got hangup signal on sio0 probe
Hi Jeremy, On Wed, May 09, 2007 at 04:06:19PM -0700, Jeremy Chadwick wrote: On Thu, May 10, 2007 at 12:19:27AM +0200, Jeremie Le Hen wrote: % obiwan:root# cat /boot.config % -D % obiwan:root# grep ttyd0 /etc/ttys % ttyd0 /usr/libexec/getty std.9600 dialup on secure This works correctly but on startup, when the kernel probes sio0, I get Got hangup signal. Is it expected? I wonder if that's some sort of reference to carrier detect being wired wrong on whatever device or adapter you have connected to your serial port. However, I can't find this string referenced anywhere in the kernel source code for RELENG_6. An (admittedly bad) egrep shows: $ egrep -r Got .+ signal /usr/src /usr/src/contrib/amd/amd/nfs_start.c:/* Got a signal */ /usr/src/usr.bin/make/job.c: * Got a signal. Set global variables and hope that someone will /usr/src/usr.sbin/bluetooth/bthidd/bthidd.c:syslog(LOG_NOTICE, Got signal %d, total number of signals %d, /usr/src/usr.sbin/bluetooth/hcsecd/hcsecd.c:syslog(LOG_DEBUG, Got signal %d, total number of signals %d, /usr/src/usr.sbin/bluetooth/sdpd/main.c:log_notice(Got signal %d. Total number of signals received %d, What version of FreeBSD are you referring to? cu(1) was running on RELENG_4 :-). But I expected to problem to be on the remote side, a RELENG_6 box. Consider using uart(4) as a possible alternative, but depending upon the answer to the above question, this might not be applicable. I wrote some directions on how to get uart(4) to work, and one caveat I found when attempting to use it. Those docs are here: http://jdc.parodius.com/freebsd_uart.txt Do you mean on the client or server side? Thank you. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
cu: Got hangup signal on sio0 probe
Hi there, Please Cc: me when replying. % obiwan:root# cat /boot.config % -D % obiwan:root# grep ttyd0 /etc/ttys % ttyd0 /usr/libexec/getty std.9600 dialup on secure This works correctly but on startup, when the kernel probes sio0, I get Got hangup signal. Is it expected? I think I can understand this, but is there any way to workaround this? Thank you. -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Hi Colin, On Thu, Jan 11, 2007 at 04:51:02PM -0800, Colin Percival wrote: Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the NOTE WELL part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail), make an assumption about how systems are configured (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). While this is not ideal, this security issue was extraordinarily messy due to the power and flexibility of the jails and the jail rc.d script. I can't recall any other time when the security team has spent this long trying to find a working patch for a security issue. I'd like to publicly thank Simon Nielsen for the many many hours he spent working on this issue, as well as the release engineering team for being very patient with us and delaying the upcoming release to give us time to fix this. Thank you very much to Simon Nielsen for the work being accomplished. According to the patch itself, it is clear he should have spent much time to resolve this issue. However both Pawel and Dirk seem to have proposed less limitating solutions. I understand we are talking about security and we may not have much time experimenting every solutions on RELENG_6. Nonetheless CURRENT the one place to experiment such solutions with a larger audience and I would be very pleased to see a less restrictive workaround for this problem. Indeed I'm using the same setup as Pawel (/jail - /usr/jail). Thank you for your work as a security officer. Best regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
Hi list, On Wed, Oct 11, 2006 at 03:15:25PM -0700, Doug Barton wrote: In order to facilitate this effort, I'd like to suggest that a new mailing list be created, freebsd-releng4. That would allow the interested folks to get together, pool resources, and decide what is possible. I am all for it. According to this thread, it appears the 4.x branch is still used for whatever reasons, may they be perceived good or bad depends on one's own consideration and feeling. If the FreeBSD Project is going to relinquish RELENG_4 support because of lack of interest from the developpers -- and I can understand this --, it would not hurt though to arrange a place where people still interrested in RELENG_4 could talk together, exchange tricks and patches and so to continue a kind of unofficial support. Although this may appear as a loose and slack support, it is yet better than having nothing, IMHO. Best regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
Hi, On Sun, Oct 01, 2006 at 12:30:22AM -0700, FreeBSD Security Officer wrote: Users of FreeBSD 4.11 systems are also reminded that that FreeBSD 4.11 will reach its End of Life at the end of January 2007 and that they should be making plans to upgrade or replace such systems. Though I admit RELENG_4 is getting dusty, it is not rusty. I believe it is still used in many places because of its stability and performance. For instance, according to Julian Elischer's posts, it seems he is still working on it. Is it envisageable to extend the RELENG_4's and RELENG_4_11's EoL once more ? Thank you. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6-STABLE panic: unusable core file
Hi list, [ please Cc: me in your reply as I am not subscribed to this list ] my 6-STABLE box panic()'ed and generated a crash dump. Once the box was online again, I wanted to get the backtrace with kgdb(1) in order to post here there. Unfortunately, I get the following endless error, as if kgdb(1) entered in an infinite loop : % obiwan:crash# kgdb kernel.debug vmcore.17 % kgdb: kvm_read: invalid address (0x190011) % kgdb: kvm_read: invalid address (0x1000) % kgdb: kvm_read: invalid address (0x113) % kgdb: kvm_read: invalid address (0x113) % kgdb: kvm_read: invalid address (0x113) % ... What am I supposed to do ? Is there a fix to get in HEAD sources or am I doing things in the wrong way ? Thank you. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] 6-STABLE panic: unusable core file
Hi, % obiwan:crash# kgdb kernel.debug vmcore.17 % kgdb: kvm_read: invalid address (0x190011) % kgdb: kvm_read: invalid address (0x1000) % kgdb: kvm_read: invalid address (0x113) % kgdb: kvm_read: invalid address (0x113) % kgdb: kvm_read: invalid address (0x113) % ... What am I supposed to do ? Is there a fix to get in HEAD sources or am I doing things in the wrong way ? My kernel.debug files was not the good one, sorry for the noise. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6-STABLE: panic: vinvalbuf: dirty bufs
Hi guys, [ please Cc: me in your replies as I am not subscribed to this list ] I have a 6-STABLE box : % FreeBSD obiwan.tataz.chchile.org 6.0-STABLE FreeBSD 6.0-STABLE #0: Mon Nov 7 11:50:33 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I got a panic as stated in the subject. In order to not overload the mailing list, I put the dmesg extracted from the core as well as the kgdb(1) backtrace in the following files on my webserver. Note that the dmesg contains errors I got just before the box panic()'ed. http://jeremie.le-hen.org/~tataz/dumps/dmesg.panic.vinvalbuf-dirty_bufs.txt http://jeremie.le-hen.org/~tataz/dumps/kgdb.panic.vinvalbuf-dirty_bufs.txt If you need it, here is a dmesg of an alive system : http://jeremie.le-hen.org/~tataz/dumps/dmesg.no_panic.txt I hope this will help to sweep out the bug. In case you need more things, such as a full backtrace or verbose boot dmesg, please, let me know. FWIW, does the following error means my disk is dead ? % unknown: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=487055103 Thank you. Best regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
unmount pending error on 6.0
Hi, [ Please Cc: me in replies, I'm not subscribed to this list. ] I run a recent RELENG_6 from three days ago. This is my file server and all my drives are doubled. I made a small script that mounts the mirror disk, rsync all files to it and finally unmount it. While testing this script, I interrupted the rsync and the script's trap tried to unmount the filesystem. umount(8) seemed to stall for a couple of minutes (I didn't mesure precisely) and finally I get the following error message : % /mnt/mp3-mirror: unmount pending error: blocks 0 files 10 What is this ? How can I debug it ? Thanks. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BETA4: Panic and can't cleanup filesystem
Hi, [ please avoid cross-posting, RELENG_6 is still in its beta stage, so -current@ should be use for now. ] When trying to unmount my flash drive with force (#umount -f /flash) machine hardlocked. After restart, when fsck-ing in background, computer panicked. Machine is SMP 2x500MHz PIII with Asus P2B-DS motherboard cvsuped and updated to RELENG_6 (BETA4) on 14 september with SHED_ULE and PREEMPTION panic is written on hand: panic: handle_written_inodeblock: live inodedep cpuid=0 KDB: enter: panic [thread pid3 tid 100033] stopped atkdb_enter+0x2b:nop db where Tracing pid 3 tid 100033 td 0xc15d17d0 kdb_enter(c062b964) at kdb_enter+0x2b panic(c063a716,0,2,0,0) at panic+0x127 handle_written_inodeblock(c1809a00,cbc1a738) at handle_written_inodeblock+0x533 softdep_disk_write_complete(cbc1a738) at softdep_disk_write_complete+0xb6 bufdone(cbc1a738) at bufdone+0x160 g_vfs_done(c1825ad4) at g_vfs_done+0x8a biodone(c1825ad4,d42e8cc4,0,c062632c,1ea) at biodone+0x57 g_io_shedule_up(c15d17d0) at g_io_shedule_up+0xb5 g_up_procbody(0,d42e8d38,0,c04be5c0,0) at g_up_procbody+0x5a fork_exit(c04be5c0,0,d42e8d38 at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1,eip=0,esp=0xd42e8d6c,ebp=0 --- dbshow alllocks Process 3 (g_up) thread 0xc15d17d0 (100033) exclusive sleep mutex SoftdepLock r=0 (0xc06dbda0) locked @ /usr/src/sys/ufs/ffs/ffs_softdep.c:4075 exclusive sleep mutex g_xup r=0 (0xd42e8cc4) locked @ /usr/src/sys/geom/geom_io.c:490 Process 31 (irq20:acpi0) thread 0xc15cd320 (100021) exclusive sleep mutex acpica subsystem lock r=0 (0xc15c0280) locked @ /usr/src/sys/modules/acpi/../../../dev/acpica/Osd/Osdynch.c:361 db panic Dump... This panic should certainly be studied by a kernel hacker. You should keep the kernel dump. I'm not enough experienced to help you here, maybe jeff, tegge or truckman could help you here. after restart, system stoped and entered in single mode with inconsistency in /var after fsck, there was message: BAD SUPERBLOCK: VALUES IN SUPERBLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE then search for SUPERBLOCK failed, and fsck don't have option -b... tried to mount all filesystems and got another panic: # /var: bad dir ino 2 at offset 0: mangled entry panic: ufs_dirbad: bad dir cpuid=0 KDB: enter: panic [thread pid 133 tid 100063] stoped at kdb_enter+0x2b: nop dbwhere Tracing pid 133 tid 100063 td 0xc18554000 kdb_enter(c062b964) at kdb_enter+0x2b panic(c063b64c,c1829800,da96c904,c059eb66,c18866b4) at panic+0x127 ufs_dirbad(c18866b4,0,c063b606,c1854000,0) at ufs_dirbad+0x3a ufs_lookup(da96c92c) at ufs_lookup+0x36a VOP_CACHEDLOOKUP_APV(c066fd80,da96c92c) at VOP_CACHEDLOOKUP_APV+0x87 lookup(da96cbcc,c0515064,0,c1854000,c06bc7c0) at lookup+0x3d6 namei(da96cbcc,c062cf75,267,c1854000,da96ca68) at namei+0x35a vn_open_cred(da96cbcc,da96,0,c15c9a80,3) at vn_open_cred+0x277 vn_open(da96cbcc,da96,0,3,c062cf75) at vn_open+0x1e kern_open(c185400,28065e40,0,1,0) at kern_open+0xb6 open(c185400,da96cd04,3,1,296) at open+0x1a syscall(3b,3b,3b,2807,80486b1) at syscall+0x27f xint0x80_syscall() at xint0x80_syscall+0x1f --- syscall(5,FreeBSD ELF32,open), eip=0x28054e67,esp=0xbfbfebcc,ebp=0xbfbfec78 --- With every restart, system going in single mode. What can i do to clean /var filesystem and to debug these panics? Any help are welcome... Did you try the -b flag from fsck_ffs(8) ? You can get the location of other superblocks with the dumpfs(8) utility. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD6.0 and VMWare 5.0.. No go
Hi Edwin, [ Please either post on -stable@ or -current@, not both. In this case you should have post on -current@ only, since 6.0 isn't stable yet. ] This morning I tried to install FreeBSD6.0 under VMWare 5. I got the following message when it was extracting the base into \ directory: Panic: duplicate free of item 0xc1c5a210 from zone 0xc143f000(g_bio) cpuid=0 KDB: enter: panic [thread pid 3 tid 100034 ] stopped at kdb_enter+0x2b: nop db Is this a known issue? Don't know if it's a known issue, but can you use the trace DDB command and post the output here please, this will greatly help debugging for kernel hackers. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Aspire 1300
[ Moved to freebsd-stable@ ] Hi Ola, I've been trying to install the latest version (5.4) of FreeBsd on my laptop an Acer Aspire 1300. It seams impossible, it hangs during istallation. I've tried to get some info on the Web but there is no help. So please can you help me. I'm realy feed up with microsoft Xp and looking for a new OS. I tried the livecd from Freesbie and liked it thats why I'm trying to install FreeBsd. This is a question related to FreeBSD 5.x, also known as FreeBSD -STABLE, so you should post to [EMAIL PROTECTED] Where does your installation hangs ? Try booting in safe mode to see if things go better. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA
Gleb, What about fixing it step by step? The patch attached to my previous message fixes the panic report by Jeremie, I suppose. It is race between output path and input path, that can occur anytime in runtime. FYI, I compiled my kernel with your patch and I have had no panic since then. Note that my previous uptime was multiple tens of days and I haven't done stress tests. But anyway I think your massively parallel arp -d/ping tests are far more significative than my box which only communicates with a couple of settled machines. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in RELENG_5 UMA
})
at ../../../i386/i386/trap.c:1009
params = 0xbfbfe500 Address 0xbfbfe500 out of bounds
callp = (struct sysent *) 0xc0744960
td = (struct thread *) 0xc205ec00
p = (struct proc *) 0xc2b04a98
orig_tf_eflags = 518
sticks = 113
error = 0
narg = 3
args = {4, 134729728, 144, 0, -1077942928, 0, 113, -1028633960}
code = 4
#36 0xc06c46bf in Xint0x80_syscall () at ../../../i386/i386/exception.s:201
%%%
Regards,
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA
Hi,
I caught a panic this night on my RELENG_5. The kernel was compiled on
2005/05/21. Please, feel free to ask for further informations (and
include me explicitely in the recipients list since I'm not subscribed
to this list).
kgdb stacktrace:
%%%
[snip]
%%%
I was a little bit sleepy earlier this morning. I forgot to tell that
my kernel is compiled with INVARIANTS and PREEMPTION.
%%%
(kgdb) up 26
#26 0xc05ee0d5 in arpresolve (ifp=0xc1a5b000, rt0=0xc1d44000, m=0xc1be7200,
dst=0xd6d3fa94, desten=0xd6d3fa2c /æ]ÀäµwÀ)
at ../../../netinet/if_ether.c:442
442 m_freem(la-la_hold);
(kgdb) l
437 * There is an arptab entry, but no ethernet address
438 * response yet. Replace the held mbuf with this
439 * latest one.
440 */
441 if (la-la_hold)
442 m_freem(la-la_hold);
443 la-la_hold = m;
444 if (rt-rt_expire) {
445 RT_LOCK(rt);
446 rt-rt_flags = ~RTF_REJECT;
(kgdb) print *la
$1 = {la_le = {le_next = 0xc1e74400, le_prev = 0xc077aa68},
la_rt = 0xc1d44000, la_hold = 0x0, la_preempt = 5, la_asked = 0}
%%%
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in RELENG_5 UMA
Hi Gleb, IMHO, this looks like a race. The route is not locked, when its llinfo is edited. Probably the mbuf was freed when arp reply arrived and la_hold was send. Look into in_arpinput() near 736: (*ifp-if_output)(ifp, la-la_hold, rt_key(rt), rt); la-la_hold = 0; Yeah, I have just triggered another panic running 15 instances of this script on SMP box: ( while (true); do arp -d 81.19.64.111 /dev/null 21; ping -c 1 -t 1 81.19.64.111 /dev/null 21; done ) But my duplicate free is in fxp_txeof(). This means that output thread has won the race. This explanation sounds good but my box is an UP with PREEMPTION. Is is supposed to be also possible in this case ? Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in recent RELENG_5 tcp code path
Hi Gleb, according to the fact that the panic occured in dereferncing mbuf pointer your kernel is compiled without INVARIANTS. Please compile it with INVARIANTS. This will probably help to trigger panic earlier, and it will be more clear. a quick look at src/conf/NOTES reveals the following : %%% # # The INVARIANTS option is used in a number of source files to enable # extra sanity checking of internal structures. This support is not # enabled by default because of the extra time it would take to check # for these conditions, which can only occur as a result of # programming errors. # %%% I'm going to recompile my kernel with INVARIANTS but I wonder in which order of magniture it will slow my kernel down. In other words, what does INVARIANTS do concretely, shall I expect a performance drop like WITNESS does ? Best regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in recent RELENG_5 tcp code path
Hi Doug, thanks for your answer.
Can you load a kernel.debug into gdb and do l *(tcp_output+0xb49) and
post the output? that offset isn't a function call in my kernel.
tcp_output() doesn't call m_copypacket directly so the exact spot is
difficult to find.
%%%
(gdb) l *(tcp_output+0xb49)
0xc061b63d is in tcp_output (../../../netinet/tcp_output.c:813).
808 m-m_data += max_linkhdr;
809 m-m_len = hdrlen;
810 if (len = MHLEN - hdrlen - max_linkhdr) {
811 m_copydata(so-so_snd.sb_mb, off, (int) len,
812 mtod(m, caddr_t) + hdrlen);
813 m-m_len += len;
814 } else {
815 m-m_next = m_copy(so-so_snd.sb_mb, off,
(int) len);
816 if (m-m_next == 0) {
817 SOCKBUF_UNLOCK(so-so_snd);
%%%
tcp_output.c rev 1.100.2.7.
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in recent RELENG_5 tcp code path
Sorry, I couldn't get a dump. %%% obiwan:tataz$ uname -a FreeBSD obiwan.tataz.chchile.org 5.4-STABLE FreeBSD 5.4-STABLE #16: Fri May 13 01:01:50 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OBIWAN i386 %%% %%% Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc05aa4e0 stack pointer = 0x10:0xd6dbfaa4 frame pointer = 0x10:0xd6dbfabc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 25637 (sshd) [thread pid 25637 tid 100131 ] Stopped at m_copydata+0x28:movl0xc(%esi),%ebx db trace Tracing pid 25637 tid 100131 td 0xc23bc180 m_copydata(c211aa00,0,40,c211aaa8,c21422ec) at m_copydata+0x28 tcp_output(c1d74534,c211aa00,c211aa30,40,0) at tcp_output+0xb49 tcp_usr_send(c1ec9144,0,c211aa00,0,0) at tcp_usr_send+0x1ca sosend(c1ec9144,0,d6dbfc6c,c211aa00,0) at sosend+0x6dc soo_write(c21422ec,d6dbfc6c,c2c2dd89,0,c23bc180) at soo_write+0x9e dofilewrite(c23bc180,c21422ec,4,807d000,40) at dofilewrite+0xb6 write(c23bc180,d6dbfd04,c,c23bc180,c21264b0) at write+0x6a syscall(807002f,bfbf002f,bfbf002f,806eca8,40) at syscall+0x340 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0x2826cd0b, esp = 0xbfbfe4fc, ebp = 0xbfbfr518 --- %%% Please Cc: me in replies, I'm not subscribed to this list. -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_em int_throttle_ceil patch
On Fri, Dec 10, 2004 at 12:00:21PM +0900, Shunsuke SHINOMIYA wrote: The previous patch to change if_em's int_throttle_ceil into sysctl-able cause a kernel panic. If you set em's int_throttle_ceil=0 and then reconfigure the em, it cause a diveded by zero panic. This patch for original if_em.[ch] which is attached to this mail is corrected this problem. Great work Shunsuke, thank you ! Any chance to get this patch reviewed and commited ? Although Bjoern Zeeb proposed to use a global way to control interrupt moderation among network drivers, there was no proposition to unify it. It would be a pity if this patch gets lost in the archives without being either commited or submited as a PR. Regards, -- Jeremie Le Hen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD sound distortion problems with SB Live! fixed with PREEMPTION
[ freebsd-stabl@ is now the right place for RELENG_5 ]. On Tue, Dec 07, 2004 at 11:48:40PM -0700, Travis Poppe wrote: Hello all, Back in October, I contacted the list and described a problem I was having with FreeBSD 5.X (now 5.3-RELEASE) and sound. I will reiterate the problem one more time for those of you who did not follow the posts. I was using FreeBSD 5.3-BETA7 at the time (as far as I know, all of 5.x has this problem) and have an SB Live! 5.1 which uses the emu10k1 driver. I've been told that this problem may be specific to my driver (and possibly others). The problem: When playing music with XMMS after my box had been up for at least a day or two, I'd hear these random skips and sound distortions that can be described as the sound being slowed down for 1/4th of a second and then back to normal again (a lagged sound skip). I have *exactly* the same problem on a 5.3 box (branch RELENG_5 after RELENG_5_3_BP). FreeBSD obiwan 5.3-STABLE FreeBSD 5.3-STABLE #3: Sun Nov 21 17:22:54 CET 2004 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OBIWAN i386 A much more severe version of this can easily be reproduced by extracting the firefox source code from bz2 while playing music and can be witnessed for as long as it takes to extract the archive. Note that these are not just skips but complete sound distortion as well. If you hear very minor brief skips when running this test but no distortion, you are not witnessing the same problem. In the previous posts to -CURRENT, I was advised to increase the sound buffer which did HELP, but the problem was still there. Increasing the buffer also caused de-synced sound in games. This was not a good workaround. Anyway, today I was playing around with a few patches derived from DragonFly that make it possible to use high resolution VESA modes with syscons. I was using a 1024x768 VESA text console when I noticed that if a lot of text were to be scrolled on the screen at once, I'd hear the same sound problem described above. Frustrated, I began conversation on IRC and described my problem. A friend of mine suggested something no one else had before, and that suggestion was to enable PREEMPTION in the kernel. A GNU/Linux user in another channel also said this to me: Sounds like FreeBSD needs a preemptable kernel. So, I decided to give it a try. To my amazement, it worked completely. Enabling PREEMPTION in the kernel completely fixes this problem to the fullest extent. I have not been able to reproduce the problem since using any of the methods described above. I'm hoping that with this new information someone might be able to figure out what is truly causing this problem and can come up with a solution (or is PREEMPTION a good solution?). It seems that only a handful of drivers (emu10k1 is the one I'm having problems with) have this problem. For the record, I am not the only one who has reported this problem to the lists. You make me happy ! I noticed this problem yesterday evening, and I did'nt have time to investigate yet. It definitely seems that PREEMPTION is the good solution since these small breaks in sounds indicates that, coarsely, the kernel does not have enough time to do what it wants between two sound frames. Basically, PREEMPTION allows to interrupt the kernel in its current task if there is something more important to do, like pushing a new sound frame. (If someone wants to make a more precise description -- or even correct me if I'm wrong --, I would be graceful.) FIY, Linux folks have a dedicated preemption patch which was initially started to make things such as Jack Audio Connection Kit [1] and related softwares work fine. Regards, [1] http://jackit.sf.net/ -- Jeremie Le Hen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious networking (em) performance (ggate and NFS) problem
if you suppose your computer has sufficient performance, please try to disable or adjust parameters of Interrupt Moderation of em. Nice ! It would be even better if there was a boot-time sysctl to configure the behaviour of this feature, or something like ifconfig link0 option of the fxp(4) driver. -- Jeremie Le Hen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious networking (em) performance (ggate and NFS) problem
Hi, Jeremie, how is this? To disable Interrupt Moderation, sysctl hw.em?.int_throttle_valve=0. Great, I would have called it int_throttle_ceil, but that's a detail and my opinion is totally subjective. However, because this patch is just made now, it is not fully tested. I'll give it a try this weekend although I won't be able to make performance mesurements. -- Jeremie Le Hen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
