Re: Latest stable (r287104) bash leaves zombies on exit
On 08/29/2015 15:41, Konstantin Belousov wrote: On Sat, Aug 29, 2015 at 03:01:38PM +0200, Jilles Tjoelker wrote: Looks good to me, except that I think a vforked child (in system() and posix_spawn*()) should use the system calls and not libthr's wrappers. This reduces the probability of weird things happening between vfork and exec, and also avoids an unexpected error when posix_spawnattr_setsigdefault()'s mask contains SIGTHR. Thank you for the review, I agree with the note about vfork. Updated patch is below. Also, I removed the PIC_PROLOGUE from the i386 setjmp, it has no use after the plt calls are removed. I verified the patch. The getumask part of lib/libc/gen/setmode.c part was rejected on stable/10 (probably due to other changes in ^/head.) Cheers Michiel ___ 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: Latest stable (r287104) bash leaves zombies on exit
On 08/28/2015 18:18, Konstantin Belousov wrote:
On Fri, Aug 28, 2015 at 05:52:42PM +0200, Michiel Boland wrote:
set -e
for a in `seq 1000`
do
echo -n $a
xterm -e ssh nonexisting
done
echo
(The idea here is that 'ssh nonexisting' should do some work and then exit,
xterm -e false, etc. don't appear to trigger the bug.)
Prior to the patch, one of the xterms would hang after the counter reaches a
random (reasonably small) number.
After the patch the script runs till completion.
Thank you for testing. Funny detail is that your loop does not hangs for
me, I see flapping xterms until the completion. How many cpus does your
machine have ?
I have a Q8300 (4 cpus) - I guess the timing matters.
Do I understand correctly that the problem is that if you install a signal
handler with signal() (which is what xterm does) and pull in libthr.so somehow,
then there is no thr_sighandler inserted?
I condensed the xterm problem into a small C program. Compile in such a way that
the delay loop does not get optimized out, and link with -lpthread. Eventually,
when executed often enough, this will hang in the same fashion as xterm does.
#include sys/types.h
#include sys/wait.h
#include unistd.h
#include signal.h
#include stdio.h
#include stdlib.h
#include string.h
static void reapchild(int sig __unused)
{
wait(NULL);
}
static void delay(void)
{
long i, n;
n = random() % 100;
if (n 0) {
n = -n;
}
for (i = 0; i n; i++)
;
}
int main()
{
int p[2];
char dummy;
srandomdev();
if (signal(SIGCHLD, reapchild) == SIG_ERR) {
perror(signal);
exit(1);
}
if (pipe(p) == -1) {
perror(pipe);
exit(1);
}
switch (fork()) {
case -1:
perror(fork);
exit(1);
case 0:
close(p[1]);
read(p[0], dummy, 1);
_exit(0);
}
close(p[1]);
read(p[0], dummy, 1);
delay();
exit(0);
}
Below is a slightly improved version of the change, to avoid unnecessary
relocations. Would be good to rebuild the world and confirm that you
see no regression (the patch also affects rtld in some way).
Ok, I will try this patch later today.
Cheers,
Michiel
___
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: Latest stable (r287104) bash leaves zombies on exit
On 08/27/2015 22:16, Konstantin Belousov wrote: [...] I just verified that the signal handler is correctly wrapped for me, on the latest stable/10. Both with the pre-linked libthr.so and with the library loaded dynamically at runtime. I used the test program at the end of the message, put breakpoint on the sigusr2_handler, and looked at the backtrace, which must include thr_sighandler(). It did in my case, for binary built with and without -lpthread. Can you verify the presence of thr_sighandler() in the backtrace for this test program, on your system ? Verified, see below. Cheers Michiel Breakpoint 1, sigusr2_handler (signo=31, si=0x7fffe430, u=0x7fffe0c0) at rtld_sigresolv.c:24 24 wait(NULL); Current language: auto; currently minimal (gdb) bt #0 sigusr2_handler (signo=31, si=0x7fffe430, u=0x7fffe0c0) at rtld_sigresolv.c:24 #1 0x00080100d947 in handle_signal (actp=value optimized out, sig=31, info=0x7fffe430, ucp=0x7fffe0c0) at /usr/src/lib/libthr/thread/thr_sig.c:243 #2 0x00080100d158 in thr_sighandler (sig=value optimized out, info=value optimized out, _ucp=value optimized out) at /usr/src/lib/libthr/thread/thr_sig.c:188 #3 signal handler called #4 thr_kill () at thr_kill.S:3 #5 0x000800965066 in __raise (s=value optimized out) at /usr/src/lib/libc/gen/raise.c:51 #6 0x00400c72 in atexit_code () at rtld_sigresolv.c:31 #7 0x00080093d406 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:200 #8 0x0008008de92c in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:67 #9 0x00400946 in _start (ap=value optimized out, cleanup=value optimized out) at /usr/src/lib/csu/amd64/crt1.c:78 #10 0x000800621000 in ?? () #11 0x in ?? () ___ 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: Latest stable (r287104) bash leaves zombies on exit
On 08/28/2015 12:01, Konstantin Belousov wrote:
[...]
I probably have an idea what is going wrong. Please try the patch
below. Libc does not used interposed sig{procmask,action,suspend}
entries itself, which resulted in e.g. signal(3) breaking libthr
hooks.
I'm trying now, and it did appear to get rid of the zombies.
Here's a quick test.
set -e
for a in `seq 1000`
do
echo -n $a
xterm -e ssh nonexisting
done
echo
(The idea here is that 'ssh nonexisting' should do some work and then exit,
xterm -e false, etc. don't appear to trigger the bug.)
Prior to the patch, one of the xterms would hang after the counter reaches a
random (reasonably small) number.
After the patch the script runs till completion.
Cheers
Michiel
___
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: Latest stable (r287104) bash leaves zombies on exit
The xterm program has a SIGCHLD signal handler that calls wait(). If the handler is invoked while xterm is exiting, a deadlock occurs in rtld. Cheers Michiel #0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x00080305a2b0 in __thr_rwlock_rdlock (rwlock=0x803272980, flags=value optimized out, tsp=value optimized out) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #2 0x00080306179c in _thr_rtld_rlock_acquire (lock=0x803272980) at thr_umtx.h:196 #3 0x0008006a72c2 in rlock_acquire (lock=0x8008ba860, lockstate=0x7fffd5b8) at /usr/src/libexec/rtld-elf/rtld_lock.c:201 #4 0x0008006a0c8d in _rtld_bind (obj=0x8006bc000, reloff=6840) at /usr/src/libexec/rtld-elf/rtld.c:701 #5 0x00080069e46d in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 #6 0x00445d34 in reapchild (n=20) at main.c:5177 #7 signal handler called #8 objlist_call_fini () at /usr/src/libexec/rtld-elf/rtld.c:769 #9 0x0008006a0c2b in rtld_exit () at /usr/src/libexec/rtld-elf/rtld.c:2710 #10 0x0008024e5406 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:200 #11 0x00080248692c in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:67 #12 0x00445f35 in Exit (n=0) at main.c:5078 #13 0x00456020 in Cleanup (code=0) at misc.c:5238 #14 0x0044da49 in NormalExit () at misc.c:5222 #15 0x0045a616 in readPtyData (xw=0x804cdc000, select_mask=0x6add80, data=0x804d64000) at ptydata.c:221 #16 0x00421c48 in in_put (xw=0x804cdc000) at charproc.c:4700 #17 0x00421b6a in doinput () at charproc.c:4856 #18 0x0041d992 in VTparse (xw=0x804cdc000) at charproc.c:4382 #19 0x0041d87a in VTRun (xw=0x804cdc000) at charproc.c:6997 #20 0x00442c01 in main (argc=3, argv=0x7fffe6d0) at main.c:2607 #6 0x00445d34 in reapchild (n=20) at main.c:5177 5177pid = wait(NULL); Current language: auto; currently minimal (gdb) l 5172int olderrno = errno; 5173int pid; 5174 5175DEBUG_MSG(handle:reapchild\n); 5176 5177pid = wait(NULL); 5178 ___ 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: FreeBSD 9.1 ix driver vlan problem
On 09/25/2013 20:03, Daniel Corbe wrote: Why would disabling STP on the switch *shorten* the amount of time it takes for the port to come up? At least on Cisco switches, it takes ~45 seconds for the switching topology to converge with STP disabled. Shorter periods if you enable portfast or uplinkfast. What is meant, I believe, is that the port should be configured as an edge port (spanning-tree portfast [trunk] in cisco lingo, set edge for junipers). You don't ever want to disable STP anywhere - that's just a recipe for disaster. Cheers Michiel ___ 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: 9.2-RC1 sparc install via network problems
On 08/06/2013 03:53, Marius Strobl wrote: [...] U10 are still supported, why should they have been dropped? :) Turns out the panic is caused by a Performance Technologies SCSI PCI card. I didn't check the exact model, but has a Qlogic 1040B chip on it. (vendor=0x1077, dev=0x1020, revid=0x05) Sometimes it crashes, sometimes not. (But more often than not.) If I remove the card booting proceeds without problems. Difference betweeen normal boot (with -v) and crash: --- boot.ok 2013-08-06 18:50:40.484988096 +0200 +++ boot.notok 2013-08-06 18:59:04.801005172 +0200 @@ -175,7 +175,7 @@ eeprom0: EEPROM/clock addr 0x14-0x141fff on ebus0 eeprom0: model mk48t59 eeprom0: registered as a time-of-day clock (resolution 100us, adjustment 0.5s) -eeprom0: current time: 1375793620.0 +eeprom0: current time: 1375794253.0 ebus0: flashprom addr 0x10-0x1f (no driver attached) pcm0: Sun Audiocs addr 0x140020-0x14002000ff,0x1400702000-0x140070200f,0x1400704000-0x140070400f,0x1400722000-0x1400722003 irq 35,36 on ebus0 pcm0: CS4231A Codec Id. 10 @@ -205,49 +205,11 @@ isp0: Qlogic ISP 1020/1040 PCI SCSI Adapter port 0x400-0x4ff mem 0x2000-0x2fff at device 1.0 on pci2 isp0: using Memory space register mapping isp0: loaded firmware isp_1040 -isp0: Ultra Mode Capable -isp0: Board Type 1040B, Chip Revision 0x5, loaded F/W Revision 4.66.0 -isp0: 512 max I/O command limit set -isp0: Chan 0 Initiator ID is 7 -syscons0: System console on nexus0 -syscons0: Unknown 16 virtual consoles, flags=0x100 -syscons0: fb0, kbd0, terminal emulator: scteken (teken terminal) -procfs registered -Timecounter tick frequency 44000 Hz quality 1000 -Event timer tick frequency 44000 Hz quality 1000 -Timecounters tick every 1.000 msec -vlan: initialized, using hash tables with chaining -lo0: bpf attached -ata2: reset tp1 mask=03 ostat0=50 ostat1=00 -ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 -ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 -ata2: reset tp2 stat0=50 stat1=00 devices=0x1 -ata3: reset tp1 mask=03 ostat0=00 ostat1=00 -ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb -ata3: stat1=0x00 err=0x04 lsb=0x00 msb=0x00 -ata3: reset tp2 stat0=00 stat1=00 devices=0x1 -isp0: driver initiated bus reset of bus 0 -(noperiph:isp0:0:-1:-1): reset bus on channel 0 -ada0 at ata2 bus 0 scbus0 target 0 lun 0 -GEOM: new disk ada0 -ada0: ST39111A 3.21 ATA-4 device -ada0: Serial Number 3CM0NK7P -ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) -ada0: 8693MB (17803297 512 byte sectors: 16H 63S/T 17662C) -ada0: Previously was known as ad0 -pass0 at ata2 bus 0 scbus0 target 0 lun 0 -pass0: ST39111A 3.21 ATA-4 device -pass0: Serial Number 3CM0NK7P -pass0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) -pass1 at ata3 bus 0 scbus1 target 0 lun 0 -pass1: LG CD-ROM CRD-8322B 1.05 Removable CD-ROM SCSI-0 device -pass1: Serial Number 1998/09/24 -pass1: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) -cd0 at ata3 bus 0 scbus1 target 0 lun 0 -cd0: LG CD-ROM CRD-8322B 1.05 Removable CD-ROM SCSI-0 device -cd0: Serial Number 1998/09/24 -cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) -cd0: cd present [323350 x 2048 byte records] -nfs_diskless: no NFS handle -GEOM: new disk cd0 - +panic: trap: data access error (kernel) +cpuid = 0 +KDB: stack backtrace: +#0 0xc08588b4 at trap+0x554 +Uptime: 1s +Automatic reboot in 15 seconds - press a key on the console to abort +Rebooting... +Resetting ... ___ 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
9.2-RC1 sparc install via network problems
Hi. I have some problems installing 9.2-RC1 on sparc64 via the network I have a dhcp server, and an NFS server that exports the disc1 ISO. Relevant portions of dhcpd.conf: filename boot/loader; option root-path ip-address-of-nfs-server:/cdrom; The boot/loader was copied from the install image. The tftpboot directory is otherwise empty. (So no loader.conf etc.) First I tried booting an Ultra10. That paniced immediately isp0: Qlogic ISP 1020/1040 PCI SCSI Adapter port 0x1000-0x10ff mem 0x2808000-0x2808fff at device 4.0 on pci3 isp0: invalid NVRAM header isp1: Qlogic ISP 1020/1040 PCI SCSI Adapter port 0x2000-0x20ff mem 0x290-0x2900fff at device 2.0 on pci2 panic: trap: data access error (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08588b4 at trap+0x554 Uptime: 1s This may be a hardware thing so I did not pursue this further. Maybe Ultra10 is no longer supported, I don't know. (Ultra10s are crap anyway :) Next I tried netbooting a V-120. That at least did not panic, but instead of starting the installer it produced this message on the console cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]... mountroot: waiting for device /dev/iso9660/FREEBSD_INSTALL ... Mounting from cd9660:/dev/iso9660/FREEBSD_INSTALL failed with error 19. Trying to mount root from nfs: []... At which point all I get is a single-user shell. Is installing via the network supported at all with the new bsd installer? Any magic loader options I need to get this to work? Cheers Michiel ___ 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: 9.2-RC1 sparc install via network problems
On 08/06/2013 03:53, Marius Strobl wrote: On Mon, Aug 05, 2013 at 07:36:40PM +0200, Michiel Boland wrote: Hi. I have some problems installing 9.2-RC1 on sparc64 via the network I have a dhcp server, and an NFS server that exports the disc1 ISO. Relevant portions of dhcpd.conf: filename boot/loader; option root-path ip-address-of-nfs-server:/cdrom; The boot/loader was copied from the install image. The tftpboot directory is otherwise empty. (So no loader.conf etc.) Do you also have 'next-server' in there? I'm buffled how TFTPing the loader could work without one ... There is a next-server line; it was in another location in the dhcpd.conf, so I did not think to copy that, sorry. [...] U10 are still supported, why should they have been dropped? :) In fact, the 9.2 images have been tested on a U10 before they were published. I also found an ISP 1040 card, which works just fine here. So this indeed could be a hardware problem causing a PCI access to fail, which typically causes very strange backtraces like the incomplete one above. Ok. I'll take out the pci cards - let's see if I can get it to boot then. So far, that's expected as you seem to also have copied over the /etc/fstab from disc1. Right. I thought I could take a shortcut by just mdconfig-ing the install image and mounting and exporting that. Cheers Michiel ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On 06/18/2013 13:28, Javad Kouhi wrote: Hi, I have exactly the same problem. I've tried to apply the above patch but it refused. I've checked out the last revision (251934) of -STABLE branch using Subversion. % git apply --check patch error: patch failed: sys/dev/drm2/i915/intel_fb.c:207 error: sys/dev/drm2/i915/intel_fb.c: patch does not apply error: patch failed: sys/dev/syscons/scvgarndr.c:445 error: sys/dev/syscons/scvgarndr.c: patch does not apply How can I apply this patch? I think you want to lose the '--check' option here. Cheers Michiel ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On 06/16/2013 17:11, Michiel Boland wrote: Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server with Intel driver has some issues that make it unusable for me. The new X server and Intel driver works extremely well, so kudos to whoever made this possible. Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the system randomly freezes after [...] syslogd: exiting on signal 15 I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to stop messages, but these never arrive. So it turns out that init hangs because vga_txtmouse (draw_txtmouse in fact) is hogging the clock swi. The routine is waiting for a vertical retrace which never arrives. (The new intel driver can't return to text console, so the screen just goes blank when X exits.) Some workarounds: - don't run moused (i.e. disable it in rc.conf and devd.conf) instead run the X server in combination with hald - do run moused, but then either - unplug the mouse before shutting down - build a kernel with VGA_NO_FONT_LOADING Of course the long-term fix is to remove the possibly infinite loop in draw_txtmouse. Thanks to Konstantin for his patience in helping me track this down. Cheers Michiel ___ 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
system sporadically hangs on shutdown after switching to WITH_NEW_XORG
Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server with Intel driver has some issues that make it unusable for me. The new X server and Intel driver works extremely well, so kudos to whoever made this possible. Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the system randomly freezes after [...] syslogd: exiting on signal 15 I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to stop messages, but these never arrive. I paniced the machine in ddb, so I have a crash dump if someone want to look at it. The crashinfo is at http://barrytown.boland.org/core.txt (I would have pasted it here but it is a bit verbose.) Machine has an Intel G41 chipset, with a SAMSUNG SSD 830 Series HD, running 9.1-STABLE r251803. Serial console. GENERIC kernel, expect for options DDB and ALT_BREAK_TO_DEBUGGER. Who knows what's going on here? Cheers Michiel ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On 06/16/2013 17:37, Konstantin Belousov wrote: On Sun, Jun 16, 2013 at 05:11:15PM +0200, Michiel Boland wrote: Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server with Intel driver has some issues that make it unusable for me. The new X server and Intel driver works extremely well, so kudos to whoever made this possible. Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the system randomly freezes after [...] syslogd: exiting on signal 15 I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to stop messages, but these never arrive. I paniced the machine in ddb, so I have a crash dump if someone want to look at it. The crashinfo is at http://barrytown.boland.org/core.txt (I would have pasted it here but it is a bit verbose.) Machine has an Intel G41 chipset, with a SAMSUNG SSD 830 Series HD, running 9.1-STABLE r251803. Serial console. GENERIC kernel, expect for options DDB and ALT_BREAK_TO_DEBUGGER. Who knows what's going on here? I do not see anything related to i915 in the core.txt you provided. Next time the machine hangs, start with the output of ps command from ddb and 'show allpcpu', together with 'alltrace'. Ok. I appended 'thread apply all bt' from kgdb to the core.txt, maybe there is something interesting in there. I did notice the following Thread 17 (Thread 17): #0 cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1392 #1 0x80cbebbd in ipi_nmi_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1374 #2 0x80ccc159 in trap (frame=0x81424890) at /usr/src/sys/amd64/amd64/trap.c:211 #3 0x80cb55af in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:501 #4 0x80d0c029 in vga_txtmouse (scp=0xfe0005586600, x=320, y=200, on=value optimized out) at cpufunc.h:186 Previous frame inner to this frame (corrupt stack?) Maybe the hang is caused by the removal of the text mouse cursor? (Just guessing here.) Cheers Michiel ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On 06/16/2013 17:55, Jeremy Chadwick wrote: [...] Are you running moused(8)? Actually, I can see quite clearly that you are in your core.txt: Starting ums0 moused. Try turning that off. Don't ask me how, because devd(8) / devd.conf(5) might be involved. The moused is started by devd - I don't see a quick way of turning that off. As a workaround I'm trying to run a kernel with options SC_NO_SYSMOUSE to see if the hangs go away. Cheers Michiel ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On 06/16/2013 17:37, Konstantin Belousov wrote: [...] I do not see anything related to i915 in the core.txt you provided. Next time the machine hangs, start with the output of ps command from ddb and 'show allpcpu', together with 'alltrace'. Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdown. I've appended it to my core.txt. (See previous e-mail.) (Note that the ddb commands are from a different session - so the ddb output may not match with the kgdb output.) ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On 06/16/2013 19:46, Konstantin Belousov wrote: On Sun, Jun 16, 2013 at 07:12:33PM +0200, Michiel Boland wrote: On 06/16/2013 17:37, Konstantin Belousov wrote: [...] I do not see anything related to i915 in the core.txt you provided. Next time the machine hangs, start with the output of ps command from ddb and 'show allpcpu', together with 'alltrace'. Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdown. I've appended it to my core.txt. (See previous e-mail.) (Note that the ddb commands are from a different session - so the ddb output may not match with the kgdb output.) Hm, how do you initiate the shutdown ? Show the exact command. Also, from the same moment of the hung system, enter the ddb and again do ps, alltrace and 'x rebooting'. The exact command to generate the hangs from which I created the reports was 'shutdown -r now' FWIW - the saved core from the ddb-induced panic has (kgdb) print rebooting $1 = 1 ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
On 06/16/2013 20:06, Michiel Boland wrote: FWIW - the saved core from the ddb-induced panic has (kgdb) print rebooting $1 = 1 I realised instantly after I sent my message that this is meaningless - so please ignore that. ___ 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: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
So apparently the value of 'rebooting' is 0 at the time of the hang... db x rebooting rebooting: 0 ___ 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: mergemaster -p / installkernel problem
On 01/28/2013 13:59, David Demelier wrote: What did you have in your mergemaster.rc ? To help next people who may have the same problem :) The mergemaster.rc that caused the problem has this IGNORE_FILES='/etc/group /etc/hosts.allow /etc/mail/* /etc/master.passwd /etc/motd /etc/passwd /etc/sysctl.conf /etc/ttys /etc/namedb/*' Obviously ignoring /etc/master.passwd et al isn't a good idea if you want to upgrade. Maybe there could be a warning added to mergemaster -p if it would skip essential steps because of IGNORE_FILES. (Then at least some good can come out of this. :) Cheers Michiel ___ 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
mergemaster -p / installkernel problem
# mergemaster -p *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot *** Beginning comparison *** Comparison complete *** /var/tmp/temproot is empty, deleting # make installkernel ERROR: Required auditdistd user is missing, see /usr/src/UPDATING. *** [installcheck_UGID] Error code 1 Stop in /usr/src. *** [installkernel] Error code 1 Stop in /usr/src. Why doesn't mergemaster find the updated master.password file? # grep FreeBSD /etc/master.passwd # $FreeBSD: stable/9/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $ # grep FreeBSD /usr/src/etc/master.passwd # $FreeBSD: stable/9/etc/master.passwd 243947 2012-12-06 11:52:31Z rwatson $ ___ 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: mergemaster -p / installkernel problem
On 01/28/2013 02:10, Kevin Oberman wrote: You don't by any chance have a mergemaster.rc in /etc or .mergemasterrc in $HOME? Duh... I'll go stand in the corner for the next 37 years. Cheers Michiel ___ 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: sendmail vs ipv6 broken after upgrade to 9.1
On 01/08/2013 23:33, Hiroki Sato wrote:
Ulrich Spörlein u...@freebsd.org wrote
in 20130108184051.gi35...@acme.spoerlein.net:
uq After setting this, it now looks like this:
uq root@acme: ~# ip6addrctl
uq Prefix Prec Label Use
uq ::1/128 50 00
uq ::/0 40 10
uq 2002::/16 30 20
uq ::/96 20 30
uq :::0.0.0.0/96 10 40
uq
uq And even sendmail is happily finding the sockets to bind to. Thanks for the
hint!
I think this just hides the problem. If gshapiro@'s explanation is
correct, no :::0.0.0.0/96 address should be returned if the name
resolution works fine...
-- Hiroki
getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:-
If a host has both IPv6 and IPv4 addresses, both are returned.
The IPv4 address is presented as a mapped address.
The order in which the addresses are returns depends on the
address selection policy (_hpreorder in lib/libc/net/name6.c)
#include netinet/in.h
#include netdb.h
#include resolv.h
#include stdio.h
static void resolve(const char *);
int main(int argc, char *argv[])
{
int i;
for (i = 1; i argc; i++) {
resolve(argv[i]);
}
return 0;
}
static void resolve(const char *hostname)
{
struct hostent *h;
char **a;
int i;
int e = 0;
h = getipnodebyname(hostname, AF_INET6, AI_DEFAULT|AI_ALL, e);
if (!h) {
return;
}
printf(h_name: %s\n, h-h_name);
for (a = h-h_aliases; *a; a++) {
printf( alias: %s\n, *a);
}
printf(h_addrtype: %d\n, h-h_addrtype);
printf(h_length: %d\n, h-h_length);
for (a = h-h_addr_list; *a; a++) {
printf(h_length: %d\n, h-h_length);
printf( address: 0x);
for (i = 0; i h-h_length; i++) {
printf(%02x, (unsigned char)(*a)[i]);
}
printf(\n);
}
}
prefer_ipv4:
$ ./a.out youtube.com
h_name: youtube.com
h_addrtype: 28
h_length: 16
h_length: 16
address: 0xadc241be
h_length: 16
address: 0xadc2415b
h_length: 16
address: 0xadc2415d
h_length: 16
address: 0xadc24188
h_length: 16
address: 0x2a00145040130c5b
prefer_ipv6:
$ ./a.out youtube.com
h_name: youtube.com
h_addrtype: 28
h_length: 16
h_length: 16
address: 0x2a00145040130c5b
h_length: 16
address: 0xadc2415b
h_length: 16
address: 0xadc2415d
h_length: 16
address: 0xadc24188
h_length: 16
address: 0xadc241be
___
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: sendmail vs ipv6 broken after upgrade to 9.1
On 01/08/2013 16:18, Ulrich Spörlein wrote:
[...]
98054 sendmail CALL bind(0x7,0x708dbc,0x1c)
98054 sendmail STRU struct sockaddr { AF_INET6, [:::88.198.49.12]:587 }
98054 sendmail RET bind -1 errno 49 Can't assign requested address
Yeah right ... I don't want an IPv6-mapped-IPv4 address, I want it to bind to
the real thing.
Sendmail uses the first address returned by gethostbyname, rather than scan for
a 'real' ipv6 address instead of a mapped ipv4 address.
My guess is that things will improve once you do '/etc/rc.d/ip6addrctl
prefer_ipv6'. This will cause gethostbyname to return the real ipv6 address first.
___
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: dc(1) fails with big number failure on 2^64
On 11/08/2012 03:06, Jan Mikkelsen wrote: Hi, I am seeing this in dc: janm@gray: dc $ dc 18446744073709551616 18446744073709551616 / ps dc: big number failure 306b06b: No such file or directory That number is 2^64. The error is coming from BN_check in bdiv(), which is complaining about the number at the top of the stack being uninitialised. Looking at the data, after the second pop in bdiv() in bdata.c, b-number-d[b-number-top - 1] == 0. After a while poking around in a debugger, it looks like the first word of the second number (a-number-d) is being allocated at the same location as the last word of the second number, it gets zeroed, and then looks uninitialised. All of this seems to be happening in the BN_* routines in openssl. I am seeing this on my builds for 9.1-RC3 and 9.0-p3, as well as the CDROM shell on the 9.1-RC3 ISO, so I'm pretty sure it isn't my build process or compiler flags. I have checked an OpenBSD 5.2 installation, and it works fine. Can anyone confirm this? Am I just seeing things? Is there an obvious fix? No fix, but I see a problem in the BN_add_word function in /usr/src/crypto/openssl/crypto/bn/bn_word.c /* Only expand (and risk failing) if it's possibly necessary */ if (((BN_ULONG)(a-d[a-top - 1] + 1) == 0) (bn_wexpand(a,a-top+1) == NULL)) return(0); This can't possibly work, since it never calls bn_wexpand if, for example, you add 6 to the number 18446744073709551610 Cheers Michiel ___ 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: dc(1) fails with big number failure on 2^64
On 11/08/2012 19:32, Michiel Boland wrote:
[...]
No fix, but I see a problem in the BN_add_word function in
/usr/src/crypto/openssl/crypto/bn/bn_word.c
Small test case:-
#include openssl/bn.h
#include limits.h
int main()
{
BIGNUM *n;
n = BN_new();
BN_set_word(n, ULONG_MAX - 1);
BN_add_word(n, 2);
BN_free(n);
return 0;
}
$ gcc x.c -lcrypto
$ valgrind ./a.out
==30682== Memcheck, a memory error detector
==30682== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30682== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30682== Command: ./a.out
==30682==
==30682== Invalid write of size 8
==30682==at 0x1328EA8: BN_add_word (bn_word.c:158)
==30682==by 0x40076E: main (in /usr/home/boland/a.out)
==30682== Address 0x18fc0a8 is 0 bytes after a block of size 8 alloc'd
==30682==at 0x100410B: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==30682==by 0x1331B82: CRYPTO_malloc (mem.c:328)
==30682==by 0x1330F76: ??? (bn_lib.c:317)
==30682==by 0x13310C7: bn_expand2 (bn_lib.c:432)
==30682==by 0x133121C: BN_set_word (bn_lib.c:570)
==30682==by 0x400760: main (in /usr/home/boland/a.out)
___
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
interleaving messages on umass detach
Hi. No biggie, but when I remove a umass device it appears that two kernel messages are being written at the same time. (da4:umass-sim1:1:0:0): lost device - 0 outstanding, 1 refs (da4:(pass6:umass-sim1:1:umass-sim1:1:0:0:0): removing device entry 0): passdevgonecb: devfs entry is gone (FreeBSD 9.1-PRERELEASE #0 r241067) Cheers Michiel ___ 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 BSD Installer
On 02/17/2012 16:21, Freddie Cash wrote: [...] The problem with mirroring partitions is that you thrash the disk during the rebuild after replacing a failed disk. And the more partitions you have, the worse it gets. I guess that if you do per-slice mirroring you should turn off autosync, right? Cheers Michiel ___ 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: x11/sessreg: build fails with CLANG in FreeBSD 9.0-PRERELEASE
On 12/20/2011 11:13, O. Hartmann wrote: On a freshly updated box the installation of x11/sessreg fails with the shown message below. On all boxes I run with FBSD 9 or 10 (all amd64, CLANG build) the build and installation works fine. Since I update the box from 8.2-STABLE to 9.0-PRE last night, cleaning up all ports and having them rebuilt from scratch, I guess I have a problem with remnants (or missing compatibility?) in the system. Where to start looking? ttyslot looks like a base system function. Looks like you still have /usr/include/utmp.h Do 'make delete-old' in /usr/src Cheers Michiel ___ 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: fsck_ufs out of swapspace
Problem solved - it was indeed an endian thing. The problem is that fsck uses a real_dev_bsize variable that is declared long, but the DIOCGSECTORSIZE ioctl takes an u_int argument. A PR has been submitted. Cheers Michiel ___ 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
fsck_ufs out of swapspace
FreeBSD 9.0-PRERELEASE locked up while into some heavy I/O and failed to shut down properly, so I had to power-cycle. After it came back up it said Starting file system checks: ** SU+J Recovering /dev/ada0a ** Reading 33554432 byte journal from inode 4. swap_pager: out of swap space swap_pager_getswapspace(16): failed pid 67 (fsck_ufs), uid 0, was killed: out of swap space fsck: /dev/ada0a: Killed: 9 Script /etc/rc.d/fsck running Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! The only way to continue was to do a full fsck (with no journal) This is a Sun Blade 100 (sparc64) with 768M of RAM. So the fsck is taking up all of this? That can't be right. What can I do to troubleshoot this further? Cheers Michiel ___ 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
installing 9.0-RC1 via netboot still fails
Installing 9.0-RC1 via netbooting still fails, at least on sparc64. See also http://www.freebsd.org/cgi/getmsg.cgi?fetch=41704+0+/usr/local/www/db/text/2011/freebsd-sparc64/20111016.freebsd-sparc64 for a possible fix/workaround. Cheers Michiel ___ 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
CAM_VERSION bump
I see CAM_VERSION has been bumped in RELENG_9, but there is no note to this effect in /usr/src/UPDATING or /usr/ports/UPDATING. Should there not be one? (cdda2wav stopped working - so I had to do some source grepping to debug.) ___ 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: /usr/bin/script eating 100% cpu with portupgrade and xargs
On 10/04/2011 13:15, Mikolaj Golub wrote: On Sun, Sep 18, 2011 at 1:58 PM, Mikolaj Golubtroc...@freebsd.org wrote: [...] I believe the behaviour is after this commit: http://svnweb.freebsd.org/base?view=revisionrevision=125848 I think we should skip select on STDIN after reading EOF from it, like in the patch below. For the record. The issue has been fixed in CURRENT and the fix has been merged to STABLE. Thanks Kostik and Chris for their comments and suggestions. Does this mean that bin/72501 can be closed? Cheers Michiel ___ 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: 7.3 + kqueue + apache/php + DNS lookup problem
On 10/02/2011 12:10, Matthew Seaman wrote: On 01/10/2011 02:18, Doug Barton wrote: Does this happen when httpd tries to do DNS resolution for, say, an incoming connection to the web server (e.g. trying to resolve the incoming IP address of the client to an FQDN), or is it happening within some PHP code (assuming PHP is installed/used as an Apache module) that's trying to do DNS resolution of some kind? It's a php module doing a lookup for the hostname of the back-end mysql server. Hmmm... Is this a function of DNS traffic being via UDP? Presumably you're not seeing the same sort of delays when eg. apache connects to mysql via TCP. Hard to think of another UDP protocol you could use to test -- SNMP perhaps? Or somehow forcing the DNS traffic to go via TCP? Tricky to make that happen when the resolver is on localhost. Of course, since DNS will only fall back to TCP after trying UDP, that's going to be even slower overall than your current situation, but the point here is to examine the truss output for timing details specifically around where the TCP query is issued. Cheers, Matthew What is the exact query issued and what was the response? I see recvfrom returned 30 bytes in Doug's original mail which seems awfully short for a meaningful DNS response. Cheers Michiel ___ 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: 5.4-RELEASE-p4: shutdown hangs after rebuiding gmirror
[recap: machine hangs on shutdown - see original message for more details] Syncing disks, vnodes remaining...1 1 0 1 1 0 0 0 done No buffers busy after final sync Uptime: 55m39s GEOM_MIRROR: Device raid1: provider mirror/raid1 destroyed. GEOM_MIRROR: Device raid1 destroyed. FWIW the hangs occur regardless of whether I rebuild a mirror. The problem is that the box sometimes hangs and sometimes not. Of course this makes the whole gmirror totally useless (as opposed to a bit of a nuisance) It appears that the hang occurs somewhere between destruction of raid1 and 'raid1.sync'. (whatever that is) Does anyone have any clue as to what is going on or how I can debug this further? Please don't make me put solaris on this box. :) Cheers Michiel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_6: panic in mpt_attach (amd64)
RELENG_6 on amd64 (Sun V20Z), cvsupped today GENERIC kernel, except for additions of GEOM_MIRROR and BREAK_TO_DEBUGGER Crashes immeately on boot mpt0: LSILogic 1030 Ultra4 Adapter port 0x2000-0x20ff mem 0xfe85-0xfe85,0xfe84-0xfe84 irq 27 at device 4.0 on pci2 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.12.0 mpt0: Unhandled Event Notify Frame. Event 0xa. mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 0 Active Volumes (1 Max) mpt0: 0 Hidden Drive Members (6 Max) Memory modified after free 0xff00f3dec540(8) val=0 @ 0xff00f3dec540 panic: Most recently used by bus cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2f: nop db tr Tracing pid 0 tid 0 td 0x8081e380 kdb_enter() at kdb_enter+0x2f panic() at panic+0x249 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x2c6 malloc() at malloc+0xa3 mpt_core_attach() at mpt_core_attach+0x71a mpt_attach() at mpt_attach+0x49 mpt_pci_attach() at mpt_pci_attach+0x895 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pci_attach() at acpi_pci_attach+0xf1 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pcib_attach() at acpi_pcib_attach+0xf0 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x97 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pci_attach() at acpi_pci_attach+0xf1 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pcib_attach() at acpi_pcib_attach+0xf0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0xdb device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_attach() at acpi_attach+0x7f1 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x292 root_bus_configure() at root_bus_configure+0x1e configure() at configure+0xa mi_startup() at mi_startup+0xd3 btext() at btext+0x2c ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nextboot and gmirror
Hi. If nextboot_enable=YES, the loader scribbles in /boot/netxtboot.conf. But how exactly does this work on gmirror-ed disks? Does /boot/nextboot.conf get written on one disk only? How does the other disk know that /boot/nextboot.conf got changed? I am confused. Cheers Michiel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.4-RELEASE-p4: shutdown hangs after rebuiding gmirror
Hi. I am running FreeBSD 5.4-RELEASE-p4 on a sun V20Z. It has two seagate ST373307LC disks. The disks are mirrored with gmirror: NameStatus Components mirror/raid1 COMPLETE da0 da1 I unplugged one of the disks, then rebooted to see if it would boot from just the one disk. Of course there was no problem there. I then inserted the other disk back in, followed by camcontrol rescan all gmirror forget raid1 gmirror insert raid1 da1 After a while the mirror was OK again. I then rebooted for a second time. But the machine would not come up. The last lines printed on the console were Syncing disks, vnodes remaining...1 1 0 1 1 0 0 0 done No buffers busy after final sync Uptime: 55m39s GEOM_MIRROR: Device raid1: provider mirror/raid1 destroyed. GEOM_MIRROR: Device raid1 destroyed. So it was stuck somewhere in the shutdown sequence between the gmirror destruction and the Shutting down ACPI bit. Sending a break to the console did not produce a DDB prompt, whereas during normal operation it would. I had to power-cycle to get the boot to work again. If I leave the disks alone, rebooting does not hang the machine. This is a bit of a nuisance. Who has any idea where to look to troubleshoot this? Cheers Michiel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fxp lockups on 5.4-RC1
Hi. I was using a small test program to generate artificial network load on 5.4-RC1. The program sets up 1000 sockets that all connect, send a number of pipelined request, and then read the response from a nearby web server. After a short while the machine locked up, even the console was dead. Luckily DDB worked, so I was able to gather some backtraces (see below). Looks like something is stuck in the fxp process. Being a bit impatient, I did not check to see if the lockup would go away after some time. The problem went away after I increased nmbclusters to 32768. If more info is needed I can provide this of course. Cheers Michiel tr Tracing pid 23 tid 100017 td 0xc157da80 kdb_enter(c05d55bb) at kdb_enter+0x2b siointr1(c167f000) at siointr1+0xce siointr(c167f000) at siointr+0x38 intr_execute_handlers(c05ffac0,d4000bd8,0,c0c46460,c0c45240) at intr_execute_handlers+0x7d atpic_handle_intr(4) at atpic_handle_intr+0x96 Xatpic_intr4() at Xatpic_intr4+0x20 --- interrupt, eip = 0xc057ff87, esp = 0xd4000c1c, ebp = 0xd4000c28 --- uma_zfree_internal(c0c45240,c4173418,0,0,80) at uma_zfree_internal+0x153 bucket_free(c4173418,1,80,f3c8,c0c45bd8) at bucket_free+0x22 uma_zalloc_bucket(c0c45ba0,1) at uma_zalloc_bucket+0x263 uma_zalloc_arg(c0c45ba0,d4000c9c,1) at uma_zalloc_arg+0x274 fxp_add_rfabuf(c1616000,c16165d0) at fxp_add_rfabuf+0x2a fxp_intr_body(c1616000,c1616000,50,) at fxp_intr_body+0xd4 fxp_intr(c1616000) at fxp_intr+0xf4 ithread_loop(c1576800,d4000d48) at ithread_loop+0x151 fork_exit(c04838a0,c1576800,d4000d48) at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd4000d7c, ebp = 0 --- db ps pid proc uid ppid pgrp flag stat wmesgwchan cmd 375 c1731388 1001 370 375 0004002 [SLPQ zonelimit 0xc0c1f460][SLP] kqmaps 370 c1731c5c 1001 369 370 0004002 [SLPQ wait 0xc1731c5c][SLP] bash 369 c1731e200 1 369 0004102 [SLPQ wait 0xc1731e20][SLP] login 368 c18b50000 1 368 0004002 [SLPQ ttyin 0xc1574e10][SLP] getty 367 c18b51c40 1 367 0004002 [SLPQ ttyin 0xc1683010][SLP] getty 366 c18b53880 1 366 0004002 [SLPQ ttyin 0xc1683210][SLP] getty 365 c18b554c0 1 365 0004002 [SLPQ ttyin 0xc1683410][SLP] getty 364 c18b57100 1 364 0004002 [SLPQ ttyin 0xc1573010][SLP] getty 363 c18b58d40 1 363 0004002 [SLPQ ttyin 0xc1573210][SLP] getty 362 c172d54c0 1 362 0004002 [SLPQ ttyin 0xc1573410][SLP] getty 361 c172d7100 1 361 0004002 [SLPQ ttyin 0xc1573610][SLP] getty 321 c15c7e200 1 321 100 [SLPQ select 0xc060f364][SLP] sshd 199 c172d1c40 1 199 000 [SLPQ select 0xc060f364][SLP] devd 38 c172d8d40 0 0 204 [SLPQ - 0xd5445d18][SLP] schedcpu 37 c172da980 0 0 204 [SLPQ syncer 0xc060baec][SLP] syncer 36 c172dc5c0 0 0 204 [SLPQ vlruwt 0xc172dc5c][SLP] vnlru 35 c172de200 0 0 204 [SLPQ psleep 0xc060f84c][SLP] bufdaemon 9 c17310000 0 0 20c [SLPQ pgzero 0xc0616ed4][SLP] pagezero 8 c15b654c0 0 0 204 [SLPQ psleep 0xc0616f28][SLP] vmdaemon 7 c15b67100 0 0 204 [SLPQ psleep 0xc0616ee4][SLP] pagedaemon 34 c15b68d40 0 0 204 [IWAIT] swi0: sio 33 c15b6a980 0 0 204 [IWAIT] swi6: task queue 6 c15b6c5c0 0 0 204 [SLPQ - 0xc15e7e00][SLP] kqueue taskq 32 c15b6e200 0 0 204 [IWAIT] swi6:+ 5 c15c70000 0 0 204 [SLPQ - 0xc15f5000][SLP] thread taskq 31 c15c71c40 0 0 204 [IWAIT] swi6:+ 30 c15c73880 0 0 204 [SLPQ - 0xc0603a40][SLP] yarrow 4 c15c754c0 0 0 204 [SLPQ - 0xc0606428][SLP] g_down 3 c15c77100 0 0 204 [SLPQ - 0xc0606424][SLP] g_up 2 c15c78d40 0 0 204 [SLPQ - 0xc060641c][SLP] g_event 29 c15801c40 0 0 204 [IWAIT] swi1: net 28 c15803880 0 0 204 [IWAIT] swi4: vm 27 c158054c0 0 0 20c [RUNQ] swi5: clock sio 26 c15807100 0 0 204 [IWAIT] irq15: ata1 25 c15808d40 0 0 204 [IWAIT] irq14: ata0 24 c1580a980 0 0 204 [IWAIT] irq13: 23 c1580c5c0 0 0 204 [CPU 0] irq12: fxp0 22 c1580e200 0 0 204 [IWAIT] irq11: 21 c15b60000 0 0 204 [IWAIT] irq10: 20 c15b61c40 0 0 204 [IWAIT] irq9: 19 c15b63880 0 0 204 [IWAIT] irq8: rtc 18 c15780000 0 0 204 [IWAIT] irq7: 17 c15781c40 0 0 204 [IWAIT] irq6: 16 c15783880 0 0 204 [IWAIT] irq5: 15 c157854c0 0 0 204 [IWAIT] irq4: sio0 14 c15787100 0 0 204 [IWAIT] irq3: sio1 13 c15788d40 0 0 204 [IWAIT] irq1: atkbd0 12 c1578a980 0 0 204 [IWAIT] irq0: clk 11 c1578c5c0 0 0
Re: strange ATA behavior with -STABLE
On Wed, 10 Jul 2002, Mike Tancsa wrote: At 10:50 AM 10/07/2002 -0700, Bill Jones wrote: The obvious answer to me is Most common platform someone installs FreeBSD on for the first time. ... Then its good that Soren committed his changes. The misplaced splx() patch corrected the problem for some but not all which is in the .1 release. Please correct me if I'm wrong but I don't think the splx patch does anything to help people with broken CD-ROM drives. Cheers Michiel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
