ahci doesn't work with qemu emulation
From dmesg:
[snip]
ahci0: Intel ICH9 AHCI SATA controller mem 0xfebf1000-0xfebf1fff irq 11 at
device 4.0 on pci0
ahci0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 256 to local APIC 0 vector 51
ahci0: using IRQ 256 for MSI
ahci0: AHCI v1.00 with 6 1.5Gbps ports, Port Multiplier not supported
ahci0: Caps: NCQ 1.5Gbps 32cmd 6ports
ahcich0: AHCI channel at channel 0 on ahci0
ahcich0: Caps:
ahcich1: AHCI channel at channel 1 on ahci0
ahcich1: Caps:
ahcich2: AHCI channel at channel 2 on ahci0
ahcich2: Caps:
ahcich3: AHCI channel at channel 3 on ahci0
ahcich3: Caps:
ahcich4: AHCI channel at channel 4 on ahci0
ahcich4: Caps:
ahcich5: AHCI channel at channel 5 on ahci0
ahcich5: Caps:
[snip]
ahcich0: AHCI reset...
ahcich0: SATA connect time=0us status=0113
ahcich0: AHCI reset: device found
ahcich0: AHCI reset: device ready after 0ms
(aprobe0:ahcich0:0:0:0): SIGNATURE:
ahcich1: AHCI reset...
ahcich1: SATA connect timeout time=1us status=
ahcich1: AHCI reset: device not found
uhub0: 3 ports with 3 removable, self powered
ahcich2: AHCI reset...
ahcich2: SATA connect timeout time=1us status=
ahcich2: AHCI reset: device not found
ahcich3: AHCI reset...
ahcich3: SATA connect timeout time=1us status=
ahcich3: AHCI reset: device not found
ahcich4: AHCI reset...
ahcich4: SATA connect timeout time=1us status=
ahcich4: AHCI reset: device not found
ahcich5: AHCI reset...
ahcich5: SATA connect timeout time=1us status=
ahcich5: AHCI reset: device not found
[snip]
[this takes a lot of time]
ahcich0: Timeout on slot 0 port 0
ahcich0: is 0005 cs ss rs 0001 tfd 50 serr
cmd 1000c017
ahcich0: AHCI reset...
ahcich0: SATA connect time=0us status=0113
ahcich0: AHCI reset: device found
ahcich0: AHCI reset: device ready after 0ms
(aprobe0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahcich0:0:0:0): CAM status: Command timeout
(aprobe0:ahcich0:0:0:0): SIGNATURE:
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
ahcich0: Timeout on slot 0 port 0
ahcich0: is 0005 cs ss rs 0001 tfd 50 serr
cmd 1000c017
ahcich0: AHCI reset...
ahcich0: SATA connect time=0us status=0113
ahcich0: AHCI reset: device found
ahcich0: AHCI reset: device ready after 0ms
(aprobe0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahcich0:0:0:0): CAM status: Command timeout
I guess that this is a problem with the emulation - some unsupported command or
reliance on some specific behavior of a driver (e.g. a Linux driver), but still
would be nice to have it working for testing / experimentation purposes.
Example of how a disk behind an AHCI controller can be specified to qemu-devel:
qemu-system-x86_64 ... -drive id=disk,file=disk.img,if=none -device ahci,id=ahci
-device ide-drive,drive=disk,bus=ahci.0
Please note that SeaBIOS image that is distrbuted with qemu-devel doesn't
support booting from AHCI. So either kernel should be on a different disk on an
emulated legacy controller or a newer SeaBIOS should be used. I utilized the
latter approach:
- got sources via git, instructions here http://www.seabios.org/Download
- built it with gmake
- the only porting change needed is s/elf_i386/elf_i386_fbsd/ in the makefile
- installed out/bio.bin to ${LOCALBASE}/share/qemu/seabios.bin for convenience
- used it with -bios seabios.bin option to qemu
--
Andriy Gapon
___
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: newnfs user setup
On Fri, Sep 02, 2011 at 08:25:05PM -0400, Rick Macklem wrote: Brandon Gooch wrote: On Thu, Sep 1, 2011 at 8:09 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Fri, May 27, 2011 at 8:09 AM, Rick Macklem rmack...@uoguelph.ca wrote: On Thu, 26 May 2011, Rick Macklem wrote: ... ??http://people.freebsd.org/~rmacklem/dtrace.patch Hmm. Is it just me? Trying to test the patch I get: (fs)(root) patch -C dtrace.patch Hmm... I can't seem to find a patch in there anywhere. Here's how I apply the patch. - download dtrace.patch to somewhere, lets say /tmp, then # cd /usr/src/sys -- sys subdirectory of a current head, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? which you don't mind messing up ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? doesn't have to be at /usr/src/sys, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? of course. # patch -p1 /tmp/dtrace.patch rick What's the status on this patch? It would be nice to get dtrace/newnfs going for 9.0...it's not too late, right? I'll test the patch too BTW :) -Brandon So it looks like the patch was committed to HEAD, but the bits to support the New NFS implementation were never flipped on -- is that for a good reason? I know nothing about Dtrace, so if something needs to be changed/fixed, someone who understands these things will have to let me know. When I built a kernel with options KDTRACE_HOOKS and set dtraceall_load=YES in /etc/rc.conf, it booted and # dtrace -l - seemed to find the stuff (it's called dtnfscl, btw). Someone told me that's how you check it's loaded and that's all I know how to do w.r.t. dtrace. If you can test/debug it, that would be great, rick Actually, the problem is not with DTrace functioning, but with the dtnfsclient.ko module: brandon@m6500:~$ sudo kldload dtnfsclient kldload: can't load dtnfsclient: Exec format error brandon@m6500:~$ dmesg ... link_elf_obj: symbol nfsclient_accesscache_flush_done_id undefined linker_load_file: Unsupported file type ... Any hints on debugging undefined symbols? -Brandon ___ 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
BETA2 panic
Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg -- Joel ___ 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: BETA2 panic
On Sun, Sep 4, 2011 at 10:04 AM, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Is your wireless turned off? If so, it looks like the state transition code isn't being handled properly between bwn(4) and net80211(4), in particular because your wireless card was still in 'scan' mode. 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: newnfs user setup
Brandon Gooch wrote: On Fri, Sep 02, 2011 at 08:25:05PM -0400, Rick Macklem wrote: Brandon Gooch wrote: On Thu, Sep 1, 2011 at 8:09 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Fri, May 27, 2011 at 8:09 AM, Rick Macklem rmack...@uoguelph.ca wrote: On Thu, 26 May 2011, Rick Macklem wrote: ... ??http://people.freebsd.org/~rmacklem/dtrace.patch Hmm. Is it just me? Trying to test the patch I get: (fs)(root) patch -C dtrace.patch Hmm... I can't seem to find a patch in there anywhere. Here's how I apply the patch. - download dtrace.patch to somewhere, lets say /tmp, then # cd /usr/src/sys -- sys subdirectory of a current head, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? which you don't mind messing up ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? doesn't have to be at /usr/src/sys, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? of course. # patch -p1 /tmp/dtrace.patch rick What's the status on this patch? It would be nice to get dtrace/newnfs going for 9.0...it's not too late, right? I'll test the patch too BTW :) -Brandon So it looks like the patch was committed to HEAD, but the bits to support the New NFS implementation were never flipped on -- is that for a good reason? I know nothing about Dtrace, so if something needs to be changed/fixed, someone who understands these things will have to let me know. When I built a kernel with options KDTRACE_HOOKS and set dtraceall_load=YES in /etc/rc.conf, it booted and # dtrace -l - seemed to find the stuff (it's called dtnfscl, btw). Someone told me that's how you check it's loaded and that's all I know how to do w.r.t. dtrace. If you can test/debug it, that would be great, rick Actually, the problem is not with DTrace functioning, but with the dtnfsclient.ko module: brandon@m6500:~$ sudo kldload dtnfsclient kldload: can't load dtnfsclient: Exec format error brandon@m6500:~$ dmesg ... link_elf_obj: symbol nfsclient_accesscache_flush_done_id undefined linker_load_file: Unsupported file type ... Any hints on debugging undefined symbols? dtnfsclient.ko is for the old nfs client. You either need to build a kernel with: options NFSCLIENT OR kldload nfsclient.ko However, if you want to test dtrace with the new (default for 9) NFS client, the dtrace module is dtnfscl.ko. rick ps: The above only applies to 9/-current, of course. -Brandon ___ 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 ___ 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: newnfs user setup
On Sun, Sep 4, 2011 at 9:28 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Fri, Sep 02, 2011 at 08:25:05PM -0400, Rick Macklem wrote: Brandon Gooch wrote: On Thu, Sep 1, 2011 at 8:09 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Fri, May 27, 2011 at 8:09 AM, Rick Macklem rmack...@uoguelph.ca wrote: On Thu, 26 May 2011, Rick Macklem wrote: ... ??http://people.freebsd.org/~rmacklem/dtrace.patch Hmm. Is it just me? Trying to test the patch I get: (fs)(root) patch -C dtrace.patch Hmm... I can't seem to find a patch in there anywhere. Here's how I apply the patch. - download dtrace.patch to somewhere, lets say /tmp, then # cd /usr/src/sys -- sys subdirectory of a current head, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? which you don't mind messing up ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? doesn't have to be at /usr/src/sys, ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? of course. # patch -p1 /tmp/dtrace.patch rick What's the status on this patch? It would be nice to get dtrace/newnfs going for 9.0...it's not too late, right? I'll test the patch too BTW :) -Brandon So it looks like the patch was committed to HEAD, but the bits to support the New NFS implementation were never flipped on -- is that for a good reason? I know nothing about Dtrace, so if something needs to be changed/fixed, someone who understands these things will have to let me know. When I built a kernel with options KDTRACE_HOOKS and set dtraceall_load=YES in /etc/rc.conf, it booted and # dtrace -l - seemed to find the stuff (it's called dtnfscl, btw). Someone told me that's how you check it's loaded and that's all I know how to do w.r.t. dtrace. If you can test/debug it, that would be great, rick Actually, the problem is not with DTrace functioning, but with the dtnfsclient.ko module: brandon@m6500:~$ sudo kldload dtnfsclient kldload: can't load dtnfsclient: Exec format error brandon@m6500:~$ dmesg ... link_elf_obj: symbol nfsclient_accesscache_flush_done_id undefined linker_load_file: Unsupported file type ... After fixing a DTrace module related build bug (see kern/160463), I was able to build and install dtrace and both the old and new NFS client dtrace providers were loaded: $ sudo dtrace -l | grep nfs | wc -l 2472 $ kldstat -v | grep dtnfs 22 1 0x8133d000 57ca dtnfscl.ko (/boot/kernel/dtnfscl.ko) 234 dtnfscl 24 1 0x81385000 4f64 dtnfsclient.ko (/boot/kernel/dtnfsclient.ko) 237 dtnfsclient Be sure to read through what's required to get DTrace going from the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dtrace-enable.html . Any hints on debugging undefined symbols? This is a runtime linker error because it can't find the symbol -- in particular if you don't define some of the required options (like DDB_CTF, WITH_CTF=1), things don't load too terribly well. HTH, -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: BETA2 panic
On 04-09-2011 10:56, Garrett Cooper wrote: On Sun, Sep 4, 2011 at 10:04 AM, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Is your wireless turned off? If so, it looks like the state transition code isn't being handled properly between bwn(4) and net80211(4), in particular because your wireless card was still in 'scan' mode. No, it's always on. I can ping over the wireless for a few minutes, until it panics. Any particular commit you think I should try to back out? -- Joel ___ 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: BETA2 panic
On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Thanks, Adrian ___ 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: BETA2 panic
On Sun, Sep 4, 2011 at 1:22 PM, Joel Dahl j...@vnode.se wrote: On 04-09-2011 10:56, Garrett Cooper wrote: On Sun, Sep 4, 2011 at 10:04 AM, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Is your wireless turned off? If so, it looks like the state transition code isn't being handled properly between bwn(4) and net80211(4), in particular because your wireless card was still in 'scan' mode. No, it's always on. I can ping over the wireless for a few minutes, until it panics. Hmm.. and the wireless card always appears on? Assuming the firmware isn't buggy (did you update it recently? have you booted other OSes, i.e. Windows or Linux that could be updating the firmware automatically on load?), it should keep the light for the wireless NIC properly lit. Any particular commit you think I should try to back out? Not in particular (in fact if_bwn has been untouched after 9.0-BETA1 was cut), but as Adrian suggested you should bisect the source of failure.. it would be a wise idea to load if_bwn as a module after boot to see if the behavior persists; next I would try out a revision sometime between r18 (9.0 Beta1) and your head revision. Some commits of interest that you might want to try backing out and testing are: - 224717 - 225139 HTH, -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
panic: sched_priority: invalid priority 3990 on r225375
I've gotten the following panic twice while running recent builds of head under VirtualBox(FreeBSD 8.2 host). panic: sched_priority: invalid priority 3990: nice 0, ticks 1227873280 ftick 175669871 ltick 175679894 tick pri 3818 The crashes happened while I was running a stress test of the network stack. I have a client machine and a server machine. The client is running head with a patch that I'm trying to prove out; the server should be running with basically stock head as of r225375(I think that there's a couple of minor changes in the tree I used to build the server with, but I've gotten the crash on the client and the server, and neither have any uncommitted patches in common). The server is running several netcat instances in listen mode; the client has a script sitting in a loop starting netcat instances that connect to instances running on the server and send data from client - server. The client also has a script that changes the routing tables periodically. Both the client and the server have crashed once so far. I haven't been running any tests on actual hardware so I can't say whether this is a FreeBSD problem or a VirtualBox problem. I'm going to start running the same tests against VMs running some version of FreeBSD 8 to see if I can reproduce the problem there. In the meantime, I've made a core.txt accessible in case anybody wants to take a look. You can find it at: http://people.freebsd.org/~rstone/sched_priority/core.txt.0.bz2 Please let me know if you need any more information. ___ 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: Compiling BETA2 with clang fails
04.09.2011 00:15, Dimitry Andric wrote:
On 2011-09-03 22:58, Volodymyr Kostyrko wrote:
03.09.2011 23:43, Dimitry Andric ???(??):
On 2011-09-03 22:22, Volodymyr Kostyrko wrote:
...
.if ${CC:T} == clang
CFLAGS+= -Qunused-arguments -fPIC
.endif
You should not unconditionally add -fPIC. Remove it, and try again.
(The -Qunused-arguments is fine, btw.)
0k, here you go. Just as you say - no -fPIC, no ccache, no anything.
=== libexec/atrun (all)
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c
clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\
-DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1
-DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil
clang: warning: argument unused during compilation: '-std=gnu99'
/usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1':
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x7d): undefined reference to
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x84): undefined reference to
`_init_tls'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x90): undefined reference to
`atexit'
/usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to
`exit'
atrun.o: In function `perr':
/usr/src/libexec/atrun/atrun.c:(.text+0x12): undefined reference to `strlen'
/usr/src/libexec/atrun/atrun.c:(.text+0x45): undefined reference to `vwarn'
/usr/src/libexec/atrun/atrun.c:(.text+0x6d): undefined reference to
`snprintf'
/usr/src/libexec/atrun/atrun.c:(.text+0x8a): undefined reference to
`vsyslog'
/usr/src/libexec/atrun/atrun.c:(.text+0x9c): undefined reference to `exit'
atrun.o: In function `perrx':
/usr/src/libexec/atrun/atrun.c:(.text+0xd3): undefined reference to `vwarnx'
/usr/src/libexec/atrun/atrun.c:(.text+0xdf): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0xf3): undefined reference to
`vsyslog'
/usr/src/libexec/atrun/atrun.c:(.text+0xff): undefined reference to `exit'
atrun.o: In function `main':
/usr/src/libexec/atrun/atrun.c:(.text+0x160): undefined reference to
`geteuid'
/usr/src/libexec/atrun/atrun.c:(.text+0x174): undefined reference to
`getegid'
/usr/src/libexec/atrun/atrun.c:(.text+0x186): undefined reference to
`setegid'
/usr/src/libexec/atrun/atrun.c:(.text+0x193): undefined reference to
`seteuid'
/usr/src/libexec/atrun/atrun.c:(.text+0x1af): undefined reference to
`openlog'
/usr/src/libexec/atrun/atrun.c:(.text+0x1b5): undefined reference to
`opterr'
/usr/src/libexec/atrun/atrun.c:(.text+0x1e6): undefined reference to
`getopt'
/usr/src/libexec/atrun/atrun.c:(.text+0x1fe): undefined reference to
`optarg'
/usr/src/libexec/atrun/atrun.c:(.text+0x212): undefined reference to
`sscanf'
/usr/src/libexec/atrun/atrun.c:(.text+0x250): undefined reference to
`__stderrp'
/usr/src/libexec/atrun/atrun.c:(.text+0x270): undefined reference to
`fwrite'
/usr/src/libexec/atrun/atrun.c:(.text+0x27c): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0x290): undefined reference to
`syslog'
/usr/src/libexec/atrun/atrun.c:(.text+0x29c): undefined reference to `exit'
/usr/src/libexec/atrun/atrun.c:(.text+0x2a8): undefined reference to `chdir'
/usr/src/libexec/atrun/atrun.c:(.text+0x2bc): undefined reference to
`opendir'
/usr/src/libexec/atrun/atrun.c:(.text+0x2e0): undefined reference to `time'
/usr/src/libexec/atrun/atrun.c:(.text+0x312): undefined reference to
`_CurrentRuneLocale'
/usr/src/libexec/atrun/atrun.c:(.text+0x34f): undefined reference to
`unlink'
/usr/src/libexec/atrun/atrun.c:(.text+0x35d): undefined reference to
`readdir'
/usr/src/libexec/atrun/atrun.c:(.text+0x379): undefined reference to `stat'
/usr/src/libexec/atrun/atrun.c:(.text+0x3b4): undefined reference to
`sscanf'
/usr/src/libexec/atrun/atrun.c:(.text+0x3e8): undefined
