Re: fxp lockups on 5.4-RC1
On Wed, 13 Apr 2005, Michiel Boland wrote: > 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. you appear to be running low on kenrel memory. the only msleep in uma_zone_slab is for zonelimit and that gets triggered when kernel memroy runs low. > > 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. Probably the right thing to do. > > 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 [
Re: reliable "panic: isa_dmastart: bad bounce buffer"
On Tue, 12 Apr 2005, Mikhail Teterin wrote: > Hello! > > Whenever I try to mount a floppy disk: > >mount -t msdosfs /dev/fd0 /mnt > > I get: > > panic: isa_dmastart: bad bounce buffer > > The OS is FreeBSD-5.4-STABLE from last night, amd64. dmesg attached. Probably related to: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 isa_dmainit(2, 40960) failed fd0: <1440-KB 3.5" drive> on fdc0 drive 0 That message is printed by isa_dmainit() in src/sys/amd64/isa/isa_dma.c. You might instrument that function and see where its blowing up. I suspect its getting the buffer from malloc() but the range check below it fails. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Deadlock in 5.3p5
My son's computer deadlocked last night. "show lockedvnods" in DDB showed: Locked vnodes 0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, flags (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 (pid 9666) with 7 pending ino 2, on dev ad0s1g (4, 25) 0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 15686) with 1 pending ino 23552, on dev ad0s1g (4, 25) 0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid 9075) with 1 pending ino 122986, on dev ad0s1g (4, 25) 0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid 9067) with 1 pending ino 142022, on dev ad0s1g (4, 25) 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending ino 142169, on dev ad0s1g (4, 25) After poking around in the crashdump for a while, I've worked out that the process holding each of the above exclusive locks is waiting on the next lock in the list. Unfortunately, there doesn't appear to be any way to work out which process is holding the shared lock unless DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly downgraded by a process calling lockmgr(LK_SHARED) when it holds an exclusive lock). FWIW, the affected inodes are: 2 /usr 23552 /usr/local 122986 /usr/local/OpenOffice.org1.1.4 142022 /usr/local/OpenOffice.org1.1.4/program 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so Does anyone have any ideas on how to track this further (or so I just write it off as a glitch). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic in uma_dbg_free (pfil hooks related?)
Hi, Same situation like the panic i reported last month (http://lists.freebsd.org/pipermail/freebsd-stable/2005-March/013066.html ) but this time without ipl(4) in the kernel. I closed my laptop lid without closing the ssh session and boom the NAT gateway (running 5.4-PRERELEASE) crashed. db> where Tracing pid 27 tid 100021 td 0xc107f190 kdb_enter(c06ca9e8) at kdb_enter+0x2b panic(c06e1733,c1346a00,c0c6aae0,c06c929b,c06e1717) at panic+0xbb uma_dbg_free(c0c6aae0,0,c1346a00) at uma_dbg_free+0x110 uma_zfree_arg(c0c6aae0,c1346a00,0) at uma_zfree_arg+0xf3 m_freem(c1346a00,c1346a00,c1598a00,4,41) at m_freem+0x36 fr_check(c1346a50,14,c112,0,ca8a8c88) at fr_check+0xce8 fr_check_wrapper(0,ca8a8c88,c112,1,0) at fr_check_wrapper+0x2a pfil_run_hooks(c075f8a0,ca8a8cd4,c112,1,0) at pfil_run_hooks+0xbd ip_input(c1346a00) at ip_input+0x231 netisr_processqueue(c075eb38) at netisr_processqueue+0x6e swi_net(0) at swi_net+0x88 ithread_loop(c1074500,ca8a8d48,c1074500,c0520610,0) at ithread_loop+0x124 fork_exit(c0520610,c1074500,ca8a8d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 Unfortunately still no gdb dump... regards tilman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge0 watchdog timeout
On Mar 22, 2005, at 1:24 PM, Vivek Khera wrote: Twice today during very heavy network I/O (dumping a large postgres database over the ethernet to another machine on the same switch) I got this error: Mar 22 03:42:22 d01 kernel: bge0: watchdog timeout -- resetting Mar 22 10:28:24 d01 kernel: bge0: watchdog timeout -- resetting For the archives: I punted and installed an em based NIC and disabled the bge on board via BIOS. Stable ever since. See thread in freebsd-amd64 list "tyan k8sr lockups" for full gory details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with SoundBlaster Audigy on FreeBSD 5.4-STABLE
On 4/14/05, Alexander Chamandy <[EMAIL PROTECTED]> wrote: > I'm having problems after a recent upgrade to FreeBSD 5.4-STABLE. > RC-1 seemed to work fine, but now my media files (audio and video > alike) are not properly playing. And I get this error: > > pcm0:play:0: play interrupt timeout, channel dead This problem seems to be directly related to ACPI being enabled. Once I disable it sound works fine. > > Has anyone experienced this and if so, know of a reasonable workaround? > > dmesg: > > FreeBSD 5.4-STABLE #14: Thu Apr 14 16:29:53 EDT 2005 > [EMAIL PROTECTED]:/usr/src/sys/amd64/compile/vetra > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.15-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0xf48 Stepping = 8 > Features=0x78bfbff > AMD Features=0xe0500800 > real memory = 2147418112 (2047 MB) > avail memory = 2064994304 (1969 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf0-0xcf3,0xcf8-0xcff on acpi0 > pci0: on pcib0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > ohci0: mem 0xfc003000-0xfc003fff irq > 22 at device 2.0 on pci0 > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 3 ports with 3 removable, self powered > ohci1: mem 0xfc004000-0xfc004fff irq > 21 at device 2.1 on pci0 > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 3 ports with 3 removable, self powered > pci0: at device 2.2 (no driver attached) > pci0: at device 5.0 (no driver attached) > pci0: at device 6.0 (no driver attached) > atapci0: port > 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on > pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pcib1: at device 10.0 on pci0 > pci1: on pcib1 > pcm0: port 0xa000-0xa01f irq 19 at device > 7.0 on pci1 > pcm0: > pci1: at device 7.2 (no driver attached) > ahc0: port 0xa800-0xa8ff mem > 0xfb004000-0xfb004fff irq 16 at device 8.0 on pci1 > aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs > atapci1: port > 0xbc00-0xbc0f,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xac00-0xac07 > mem 0xfb006000-0xfb0061ff irq 17 at device 13.0 on pci1 > ata2: channel #0 on atapci1 > ata3: channel #1 on atapci1 > pcib2: at device 11.0 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > pci2: at device 0.1 (no driver attached) > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > orm0: at iomem > 0xd8000-0xdd7ff,0xd-0xd7fff,0xc-0xccfff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > uhub2: vendor 0x0543 product 0x1167, class 9/0, rev 2.00/ff.ff, addr 2 > uhub2: 4 ports with 4 removable, self powered > ugen0: Saitek Saitek X45, rev 1.00/0.02, addr 3 > ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.00, addr 4, iclass 3/1 > ums0: 3 buttons and Z dir. > Timecounter "TSC" frequency 2009148084 Hz quality 800 > Timecounters tick every 1.000 msec > ad2: 58644MB [119150/16/63] at ata1-master UDMA100 > acd0: DVDR at ata1-slave PIO4 > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit) > da0: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) > Mounting root from ufs:/dev/ad2s1a > nv0: port 0xd000-0xd007 mem > 0xfc00-0xfc000fff irq 22 at device 5.0 on pci0 > nv0: Ethernet address 00:0d:61:14:6f:39 > nv0: Ethernet address: 00:0d:61:14:6f:39 > miibus0: on nv0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > -- > Best wishes, > > Alexander G. Chamandy > Webmaster > www.bsdfreak.org > Your Source For BSD News! > -- Best wishes, Alexander G. Chamandy Webmaster www.bsdfreak.org Your Source For BSD News! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: merging locale stuff in mtree?
On 4/15/05, Joel <[EMAIL PROTECTED]> wrote: > Just finished rebuilding and installing the world and the kernel by the > "canonical" method. > > In using mergemaster, I find myself puzzled by the locale stuff in mtree. > I have not installed a lot of locales, haven't even started X11 at all > yet, but the updates seem to want to put a lot of stuff about locales in > BSD.X11-4.dist and BSD.local.dist. Is all that locale stuff necessary > there if you haven't installed all those locales? > The locale stuff in the BSD.*.dist files is used to create standard directories and permissions. This way when you install a port/package it doesn't need to create the missing locale directories, instead mtree will create them. > (I tried to merge BSD.local.dist, and I think I botched it.) > Just copy the src/etc/mtree/BSD.local.dist to /etc/mtree to fix it. > I'm not really clear on what mtree does, in case that isn't obvious. > Search the web only turned up stuff about an alternative to tripwire, > but I suppose it might be mergemaster's db configuration? (Scanned man > on mtree and /usr/src/etc/mtree/README, but it hasn't sunk it yet.) > mtree is used to create standard permissions (directories and files) and default directories that should exist. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
merging locale stuff in mtree?
Just finished rebuilding and installing the world and the kernel by the (B"canonical" method. (B (BIn using mergemaster, I find myself puzzled by the locale stuff in mtree. (BI have not installed a lot of locales, haven't even started X11 at all (Byet, but the updates seem to want to put a lot of stuff about locales in (BBSD.X11-4.dist and BSD.local.dist. Is all that locale stuff necessary (Bthere if you haven't installed all those locales? (B (B(I tried to merge BSD.local.dist, and I think I botched it.) (B (BI'm not really clear on what mtree does, in case that isn't obvious. (BSearch the web only turned up stuff about an alternative to tripwire, (Bbut I suppose it might be mergemaster's db configuration? (Scanned man (Bon mtree and /usr/src/etc/mtree/README, but it hasn't sunk it yet.) (B (BAppreciate a cluestick if anyone cares to hit me with one. (B (B-- (BJoel Rees <[EMAIL PROTECTED]> (Bdigitcom, inc. $B3t<02qhttp://www.ddcom.co.jp> ** (B (B___ (Bfreebsd-stable@freebsd.org mailing list (Bhttp://lists.freebsd.org/mailman/listinfo/freebsd-stable (BTo unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xl0: transmission error: 90
On Fri, Apr 15, 2005 at 08:27:13AM -0400, Mike Jakubik wrote: > On Fri, April 15, 2005 5:13 am, Ulrik Guenther said: > > on my 5.4-RC1 installation with a 3com 3c905B NIC I got the following > > messages while transferring a big file (31GByte) over 100MBit ethernet: > > > > Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 > > Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start > > > > So, okay the threshold was increaed in 60byte steps from 120 to 420 > > bytes, then it stopped. This procedure took place only during the first > > gigabytes of the transmission. I noticed no negative side effects (say: > > the file arrived completely on the other computer, checksum was okay as > > well). Transmission was done via SSH/SCP. > > > > Now my question: What do these messages from the xl(4) mean? > > Im assuming the xl cards default tx buffer is too low, or something of > that nature. I get the same messages, but everything works fine. I've been getting them for a few years now, always after a reboot: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 120 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes (not exactly all at the same time of course). Machine functions just fine as far as I can tell. --Stijn -- Coughlin's law: never tell tales about a woman no matter how far away she is, she'll always hear you. -- Cocktail pgpwm6LE4sK0P.pgp Description: PGP signature
Re: xl0: transmission error: 90
On Fri, April 15, 2005 5:13 am, Ulrik Guenther said: > on my 5.4-RC1 installation with a 3com 3c905B NIC I got the following > messages while transferring a big file (31GByte) over 100MBit ethernet: > > Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 > Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start > > So, okay the threshold was increaed in 60byte steps from 120 to 420 > bytes, then it stopped. This procedure took place only during the first > gigabytes of the transmission. I noticed no negative side effects (say: > the file arrived completely on the other computer, checksum was okay as > well). Transmission was done via SSH/SCP. > > Now my question: What do these messages from the xl(4) mean? Im assuming the xl cards default tx buffer is too low, or something of that nature. I get the same messages, but everything works fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alternate menu logos
On Apr 14 at 10:13, Doug White spoke: > I I have an idea and the patch in PR 74577 is about halfway there. I > suggest providing a script that forth-ifies a provided ASCII logo, and a > loader option to load a banner file from disk. This way, if, say, an OEM > wanted to put contact information in there, they could put in loader.conf: > > banner_enable="YES" > banner_file="/boot/oem.banner" > > and have that displayed instead of the beastie. Is it acceptable that the banner_file is just an include file or should the program open the banner_file itself? -Hanspeter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_5 broken?
> > > FWIW, you are just in time anyway because they added a security (B> > > notice and if you cvsup now, you will also get that fix. (B (BAnd it's nice to have that out of the way. (B (B> > So the system is not in an unstable situation such that repeating the (B> > cvsup would have me trying to build from inconsistent libraries or (B> > anything like that? (B> (B> When you do the buildworld, you get a new world and then the kernel will (B> build. This is one of the reasons to buildworld, buildkernel, and (B> install kernel. (B (BI'm just a following the instructions in the on-line manual. Well, (BI used sudo from the main admin account while in multi-user mode, except (BI forgot that a couple of times and had to break out. And I forgot to (Bgrab it at the beastie menu on the reboot just now, but it seems to be (Binstalling world okay after a second reboot to single-user. (B (B> Since the buildkernel died, your libraries haven't been (B> updated. You wouldn't do that until after you have booted the new (B> kernel in single user mode. The sequence may be awkward at times but it (B> saves you from the little disasters :). (B (BNo problem with that. Just wanted to make sure the libraries would not (Bbe in a half-way state from not having completed the previous build. (B (B> > What the heck, I'll take a backup and give it a spin. (B> (B> Just remember you build and install the world and the kernel. I just got (B> through upgrading to get the ifconf fix. No, problem. (B> (B> Kent (B (BThanks again. It just finished the install, so I'll see what happens in (Bthe second pass of mergemaster (That looks like it could be a very (Buseful tool.) and then build ports. (B (BI guess it's obvious I haven't done this very much on freeBSD. (B (B-- (BJoel Rees <[EMAIL PROTECTED]> (Bdigitcom, inc. $B3t<02qhttp://www.ddcom.co.jp> ** (B (B___ (Bfreebsd-stable@freebsd.org mailing list (Bhttp://lists.freebsd.org/mailman/listinfo/freebsd-stable (BTo unsubscribe, send any mail to "[EMAIL PROTECTED]"
xl0: transmission error: 90
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, on my 5.4-RC1 installation with a 3com 3c905B NIC I got the following messages while transferring a big file (31GByte) over 100MBit ethernet: Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 120 bytes Apr 15 08:46:18 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:18 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 180 bytes Apr 15 08:46:19 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:19 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 240 bytes Apr 15 08:46:19 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:19 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 300 bytes Apr 15 08:46:21 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:46:21 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 360 bytes Apr 15 08:47:29 verleihnix kernel: xl0: transmission error: 90 Apr 15 08:47:29 verleihnix kernel: xl0: tx underrun, increasing tx start threshold to 420 bytes So, okay the threshold was increaed in 60byte steps from 120 to 420 bytes, then it stopped. This procedure took place only during the first gigabytes of the transmission. I noticed no negative side effects (say: the file arrived completely on the other computer, checksum was okay as well). Transmission was done via SSH/SCP. Now my question: What do these messages from the xl(4) mean? Thanks in advance, Ulrik Guenther -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX4Wdy06DkvPH780RAqnLAKCHdbJGj8obBnHpyj7BHvWGeNbf6QCgm/lK FEnMYakL4j4YcH/vUaPGGbA= =ghm3 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 rc2 problems with tftpd service
Hi Problem was caused by net.inet.udp.blackhole=1. It looks like -l or -s does not work with this option. Regards, Thomas Thomas wrote: Hello I can't download files via tftp. The tftp client gets a timeout and the written file is 0 bytes. I've done all my test on a local machine. No network was involved. System information: FreeBSD lizard 5.4-RC2 Wed Apr 13 15:04:30 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UP i386 inetd.conf contains tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /var/tftpboot /var/tftpboot permission is set to 755 (root:wheel). I tried the -u root option for tftpd too but it didn't work either. Also changed ownership to nobody:nobody for /var/tftpboot but no luck. There is no error message in xferlog. I always get tftpd[47744]: 127.0.0.1: read request for //test: success. But the file was not transferred. Everything works fine if I remove the -l option or the -s option in inetd.conf for tftpd. Is this "strange" behavior with -l as option intended? Regards, Thomas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- My blog: http://www.bsdunix.ch ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.4/amd64 console hang
Hi, I'm using a Pentium Xeon 3.2G * 2 running 5.3/5.4 amd54 RELEASE. Recently, I have frequently hang, say 4 in 3 days. Originally, I'm using 5.3-RELEASE-p5 or so, and it happens, so I decided upgrade to 5.4-RC1/RC2 and disable HTT in BIOS. Somehow, I noticed that this situation happens more frequently after upgrade to 5.4-RC1/RC2. This is a Mail server running Postifx with clamd/amavisd and apache2 with some webmail applications. All users home directory (toatl 10) is mounted from another NFS server running 5.4-PRELEASE/i386. I have few ddb output and kernel config here: http://rafan.infor.org/tmp/5.4-hang/ I executes ps, show threads, show lockedvn. when console hangs, serial console does not response, front console, I can use alt+f? to switch vty, caps/numlock led is fine, but keyboard does not response. can break to ddb. any suggestions? Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
