Linking STAGE 2 boot, directly to the kernel (skipping loader)
After I do it via /boot.config, it fails, with an error: Invalid format, in cases when: a) kernel is gzip-ed b) kernel has statically compiled md root, which was gzip-ed, before being embedded into kernel c) kernel has statically compiled md root, which was uzip-ed, before being embedded into kernel d) kernel has statically compiled md root, which wasn't compress-ed, before being embedded into kernel It works, only with regular kernel. Is this a bug or what? I suspect size of a kernel, confuses STAGE 2 boot, in non-a) cases. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS mount inside jail fails
Alexander Leidinger writes: | Quoting Doug Ambrisko ambri...@ambrisko.com (from Thu, 19 May 2011 | 14:38:40 -0700 (PDT)): | | Alexander Leidinger writes: | | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko | | ambri...@ambrisko.com wrote: | | | | doesn't have access to it anymore either. Running an X server in a | | vimage has some issues. Most are pretty easy to over-come. | | | | Are you using my patch | | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a | | custom devfs.rules to get the 2D part (the last time I tried the DRI | | part of my patch, it paniced the machine) of the X server working in a | | jail, or did you come up with something yourself? If it is the later, I | | would be interested how you did it. | | Nope, didn't know about it when I played with it. I should try it. | I added | case PRIV_IO: | return (0); | | to kern_jail.c to get X to work. This was with the Intel graphics. | The main problem I have now is on resume the X server dies and restarts. | I use xdm. Without jail with vimage then it works okay. | | I use it without vimage in a jail. This is with a radeon card | (corresponding kernel module loaded at boot to get 2D acceleration, as | the X server obviously can not load modules in a jail). | | My laptop can use either Intel or ATI graphics. I just switched it to | ATI to see what happens. I should try some more tests. It seems | my BIOS likes to reset this setting and enable both :-( | | I don't seem to have panics. This is with a month or so old -current. | | You do not allow access to the dri device, so I do not expect a panic. | If you give access to the dri device (which can be enabled separately | in my patch), I would not be surprised to see a panic (the last time I | tried it is a year or two ago, I didn't take the time to investigate | why it panics). Okay, I have an update. With Intel graphics and using dri things work better and I don't get panics. I load drm.ko i915.ko before starting the vimage jail. X sees it and uses it. This solves the suspend/resume issue I had. The dri issue also prevented suspend and resume fail to work in a chroot. I have not tried switching to using the ATI option. On a plus side my laptop is running cooler and faster now. Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
DEBUG - analysing core dumps
Hello list, We've got these boxes at work running FreeBSD 8.1-STABLE amd64 and serving as firewalls and openvpn gateways. We use CARP interfaces to provide an active-passive fault tolerant system. Today, we received a nagios alert from the master box saying it's rsyslogd process had crashed. I logged on to it and tried to relaunch it, to no avail: pid 2303 (rsyslogd), uid 0: exited on signal 11 (core dumped) I would like advice on how to debug the output from the core dump. This is what I get from gdb: # gdb 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. (gdb) core rsyslogd.core Core was generated by `rsyslogd'. Program terminated with signal 11, Segmentation fault. #0 0x004258ec in ?? () Sadly, getting a backtrace with bt gives me more lines with ??, which is totally not helpful: [SNIP] #13 0x7f1f9d70 in ?? () #14 0x in ?? () #15 0x6f70732f7261762f in ?? () #16 0x6c737973722f6c6f in ?? () #17 0x5f6e70766f2f676f in ?? () #18 0x746174732e676f6c in ?? () #19 0x0065 in ?? () #20 0x in ?? () [SNIP] I am not sure what steps I should follow to get more information ? Also, I believe that often, core dumps with signal 11 = RAM problems and I would like a confirmation here. I am concerned because rsyslogd is the only process that crashes in this way, even after I rebooted the firewall. Thanks for your input :) -- dfl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: DEBUG - analysing core dumps
Damien Fleuriot wrote: Hello list, We've got these boxes at work running FreeBSD 8.1-STABLE amd64 and serving as firewalls and openvpn gateways. We use CARP interfaces to provide an active-passive fault tolerant system. Today, we received a nagios alert from the master box saying it's rsyslogd process had crashed. I logged on to it and tried to relaunch it, to no avail: pid 2303 (rsyslogd), uid 0: exited on signal 11 (core dumped) I would like advice on how to debug the output from the core dump. This is what I get from gdb: # gdb 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. (gdb) core rsyslogd.core Core was generated by `rsyslogd'. Program terminated with signal 11, Segmentation fault. #0 0x004258ec in ?? () Sadly, getting a backtrace with bt gives me more lines with ??, which is totally not helpful: [SNIP] #13 0x7f1f9d70 in ?? () #14 0x in ?? () #15 0x6f70732f7261762f in ?? () #16 0x6c737973722f6c6f in ?? () #17 0x5f6e70766f2f676f in ?? () #18 0x746174732e676f6c in ?? () #19 0x0065 in ?? () #20 0x in ?? () [SNIP] I am not sure what steps I should follow to get more information ? Also, I believe that often, core dumps with signal 11 = RAM problems and I would like a confirmation here. I am concerned because rsyslogd is the only process that crashes in this way, even after I rebooted the firewall. Thanks for your input :) For what it's worth, the addresses shown in frames 15, 16, 17, and 18 are ASCII: ops/rav/ lsysr/lo _npvo/go tats.gol /Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: DEBUG - analysing core dumps
Le Wed, 25 May 2011 18:36:49 +0200, Damien Fleuriot m...@my.gd a écrit : Hello, Sadly, getting a backtrace with bt gives me more lines with ??, which is totally not helpful: [SNIP] #13 0x7f1f9d70 in ?? () #14 0x in ?? () #15 0x6f70732f7261762f in ?? () #16 0x6c737973722f6c6f in ?? () #17 0x5f6e70766f2f676f in ?? () #18 0x746174732e676f6c in ?? () #19 0x0065 in ?? () #20 0x in ?? () [SNIP] I am not sure what steps I should follow to get more information ? You have to build the binary with debug symbols included. The rsyslog port provides an option for this. Did you see this notice in the port's makefile? # XXX: 5.5.6+ seem to crash frequently with low-mid load # on FreeBSD, temporailiy enable debugging by default. # Now we can send gdb backtraces into the list: # rsyslog-users rsys...@lists.adiscon.com OPTIONS=DEBUG Enable debugging on Good luck... Regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: DEBUG - analysing core dumps
On Wed, May 25, 2011 at 06:36:49PM +0200, Damien Fleuriot wrote: I am not sure what steps I should follow to get more information ? Rebuild the port with debug information, as in # cd /usr/ports/sysutils/rsyslog4 # WITH_DEBUG=1 make package And install that on the target host. Then repeat the gdb backtrace. If you are using disk spool files, try removing them before the start, I've seen rsyslogd die like that due to corrupted spool files... HTH, Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Possible bug in gdb-6.1.1 (it leaves zombie processes)
Hello hackers, I think I found a bug in base gdb-6.1.1 on FreeBSD-8.2. Below is how you can reproduce it. I run sleep 10 command under control of gdb-6.1.1 as follows $ gdb --args sleep 10 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...(no debugging symbols found)... (gdb) r Starting program: /bin/sleep 10 (no debugging symbols found)...(no debugging symbols found)... Program exited normally. (gdb) q $ During execution of sleep I saw: $ ps auxw | grep sleep krived 2951 0.0 1.1 15836 5520 0 S 4:14PM 0:00.04 gdb --args sleep 10 krived 2952 0.0 0.2 2764 840 0 SX+ 4:14PM 0:00.01 /bin/sleep 10 $ As expected, once sleep exited and got $ ps auxw | grep sleep krived 2951 0.0 1.1 15836 5520 0 S+4:14PM 0:00.04 gdb --args sleep 10 $ However, I found that sleep process became a zombie: $ ps auxw | grep 2952 krived 2952 0.0 0.0 0 0 0 Z 4:14PM 0:00.01 defunct $ Then I closed gdb and zombie process went away: $ ps auxw | grep 2952 $ I did a quick search through the Google and found that other people also encountered this problem before: https://bugzilla.redhat.com/show_bug.cgi?id=243845 I tried the same test with gdb-7.2 installed from ports and there was no zombie process. I didn't find any reports on this problem in PR database. Can this problem be classified as a bug in base gdb-6.1.1? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Problem with running simple pthreads program under gdb-7.2 (Invalid selected thread)
Hello,
I wrote very simple Pthreads program to demonstrate the problem with
gdb-7.2 installed from
ports on my FreeBSD-8.2 (amd64).
///
#include pthread.h
#include assert.h
#include stdlib.h
void* run(void* arg)
{
return 0;
}
int main(int argc, char** argv)
{
pthread_t tid;
int r;
r = pthread_create(tid, NULL, run, NULL);
assert(!r);
r = pthread_join(tid, NULL);
assert(!r);
return 0;
}
///
I compiled it as follows
$ gcc -Wall -g -O0 -pthread -o t t.c
$
and then run under base gdb-6.1.1
$ gdb --args t
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...
(gdb) r
Starting program: /big/work/coverage/csxroot/src/t/t
[New LWP 100071]
[New Thread 800a041c0 (LWP 100071)]
[New Thread 800a0ae40 (LWP 100170)]
[Thread 800a0ae40 (LWP 100170) exited]
Program exited normally.
(gdb) q
$
As you can see program exited normally w/o any errors.
Then I run the same program under gdb-7.2
$ /usr/local/bin/gdb72 --args t
GNU gdb (GDB) 7.2 [GDB v7.2 for FreeBSD]
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-portbld-freebsd8.2.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /big/work/coverage/csxroot/src/t/t...done.
(gdb) r
Starting program: /big/work/coverage/csxroot/src/t/t
[New LWP 100162]
[New Thread 800a041c0 (LWP 100162)]
[New Thread 800a0ae40 (LWP 100171)]
[Thread 800a0ae40 (LWP 100171) exited]
Invalid selected thread.
(gdb) q
A debugging session is active.
Inferior 1 [process 7756] will be killed.
Quit anyway? (y or n) y
$
In this case I got Invalid selected thread. right after the thread has exited.
Looks like gdb is unable to switch to another thread.
What's wrong here?
Thanks!
--
Sincerely yours, Dmitry V. Krivenok
e-mail: krivenok.dmi...@gmail.com
skype: krivenok_dmitry
jabber: krivenok_dmi...@jabber.ru
icq: 242-526-443
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Problem with running simple pthreads program under gdb-7.2 (Invalid selected thread)
Dmitry Krivenok krivenok.dmi...@gmail.com writes: As you can see program exited normally w/o any errors. Then I run the same program under gdb-7.2 $ /usr/local/bin/gdb72 --args t GNU gdb (GDB) 7.2 [GDB v7.2 for FreeBSD] Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-portbld-freebsd8.2. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /big/work/coverage/csxroot/src/t/t...done. (gdb) r Starting program: /big/work/coverage/csxroot/src/t/t [New LWP 100162] [New Thread 800a041c0 (LWP 100162)] [New Thread 800a0ae40 (LWP 100171)] [Thread 800a0ae40 (LWP 100171) exited] Invalid selected thread. (gdb) q A debugging session is active. Inferior 1 [process 7756] will be killed. Quit anyway? (y or n) y $ In this case I got Invalid selected thread. right after the thread has exited. Looks like gdb is unable to switch to another thread. In my case, I get the following error when running your program (and many others) with the gdb72 package (installed via portmaster -PP devel/gdb): (gdb) r Starting program: /tmp/test-base [New LWP 100315] Cannot get thread info, Thread ID=100315, generic error (gdb) q A debugging session is active. Inferior 1 [process 84832] will be killed. Quit anyway? (y or n) y If I compile the port myself, I can't run any binary (PR ports/152896, which has been unanswered despite my efforts): Reading symbols from /usr/local/bin/gdb72...I'm sorry, Dave, I can't do that. Symbol format `elf64-x86-64-freebsd' unknown. This is 8.2-STABLE. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
