Re: 7.1-stable (righ after release) locks up on soekris net5501 every day
And it seems, that my USB2Serial cable can not generate BREAK. When I press ~# in cu it output ~ and doesn't go to debugger (yse, I have BREAK_TO_DEBUGGER option)... Have you changed the ssh escape char? It defaults to ~ so if you haven't, ssh eats the ~ before cu sees it. Rather than changing the ssh escape char, it may be easier to just type ~~#. ssh should transform the ~~ into a single ~. ___ 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[2]: 7.1-stable (righ after release) locks up on soekris net5501 every day
Hello, Perryh. You wrote 4 февраля 2009 г., 11:12:26: And it seems, that my USB2Serial cable can not generate BREAK. When I press ~# in cu it output ~ and doesn't go to debugger (yse, I have BREAK_TO_DEBUGGER option)... Have you changed the ssh escape char? It defaults to ~ so if you haven't, ssh eats the ~ before cu sees it. Rather than changing the ssh escape char, it may be easier to just type ~~#. ssh should transform the ~~ into a single ~. doesn't work too, it seems, that my USB2Serial cable really can not send breaks. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
fun with if_re
Hi folks, I have several routers here which are based on Jetway J7F4 ITX boards that come with two onboard re-interfaces. I run 7-stable on them via nanobsd and update them about once in three or four months. After the last update (11th December 2008) I have noticed the following strange behaviour on at least two machines (identical hard- and software): After weeks of flawless operation, the network connection on both interfaces suddenly starts to mangle packages. Even a simple ping can show up to 50% or so package loss. The machine is mostly unreachable via net. ifconfig up/down did not cure this, turning off checksum-offloading and stuff did not help. Even simply rebooting the machine did not make the problem go away! I had to power-cycle them by unplugging all cables to get back to normal operation. I have seen this behaviour on two different machines, so I can most probably rule out a hardware issue. It does not appear to happen often, though. I did not see this with an earlier image of 7-stable from June 2008, and probably even an image from early September was working fine (although I did not use that one for such a long time). Visiting the webcvs I noticed that there are a lot of patches for if_re in December 2008 and January 2009. The revision I'm having problems with is tagged 1.95.2.37 2008/12/09 11:01:17. Does anyone have an idea what broke if_re for me, and how I can get back to stable operation? Is it possible to use if_re from head as drop-in replacement to test the patches available after 12/09? I would prefer not to move the machines completely from -stable to -current. Here some further information about the NICs: ---pciconf--- r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet r...@pci0:0:11:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet --- ---dmesg--- re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 10 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:ab:d0:19 re0: [FILTER] re1: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 10 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x miibus1: MII bus on re1 rgephy1: RTL8169S/8110S/8211B media interface PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:ab:d0:1a re1: [FILTER] --- cu Gerrit ___ 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: fun with if_re
On Wed, Feb 04, 2009 at 10:05:07AM +0100, Gerrit K?hn wrote: Hi folks, I have several routers here which are based on Jetway J7F4 ITX boards that come with two onboard re-interfaces. I run 7-stable on them via nanobsd and update them about once in three or four months. After the last update (11th December 2008) I have noticed the following strange behaviour on at least two machines (identical hard- and software): After weeks of flawless operation, the network connection on both interfaces suddenly starts to mangle packages. Even a simple ping can show up to 50% or so package loss. The machine is mostly unreachable via net. ifconfig up/down did not cure this, turning off checksum-offloading and stuff did not help. Even simply rebooting the machine did not make the problem go away! I had to power-cycle them by unplugging all cables to get back to normal operation. I have seen this behaviour on two different machines, so I can most probably rule out a hardware issue. It does not appear to happen often, though. I did not see this with an earlier image of 7-stable from June 2008, and probably even an image from early September was working fine (although I did not use that one for such a long time). Visiting the webcvs I noticed that there are a lot of patches for if_re in December 2008 and January 2009. The revision I'm having problems with is tagged 1.95.2.37 2008/12/09 11:01:17. Does anyone have an idea what broke if_re for me, and how I can get back to stable operation? Is it possible to use if_re from head as drop-in replacement to test the patches available after 12/09? I would prefer not to move the machines completely from -stable to -current. Here some further information about the NICs: ---pciconf--- r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet r...@pci0:0:11:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet --- ---dmesg--- re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 10 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:ab:d0:19 re0: [FILTER] re1: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 10 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x miibus1: MII bus on re1 rgephy1: RTL8169S/8110S/8211B media interface PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:ab:d0:1a re1: [FILTER] --- Since you're using RTL8169SC it could be related with my commit r180519(cvs rev 1.95.2.22). It seems that RTL8169SC does not like memory mapped register access and I think jkim@ committed patch for the issue. Would you try re(4) in HEAD? (Just copying if_re.c, if_rlreg.h and if_rl.c from HEAD to stable would be enough to build re(4) on stable). ___ 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: problem with acd udma mode
Marat N.Afanasyev wrote: i cannot read or write any disk inserted in my acd0 PIONEER DVD-RW DVR-111D/1.29 when this device in udma mode. kernel endlessly repeat that acd0: setting up DMA failed and I can access my data on dvd or cd only if I set atacontrol mode acd0 pio4 Does anybody have such a problem too? is there any ways to bring this device into udma mode again? dmesg: ... atapci1: ATI IXP600 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: ATA channel 0 on atapci1 ata0: [ITHREAD] ... acd0: DVDR PIONEER DVD-RW DVR-111D/1.29 at ata0-master UDMA66 ... uname -a: FreeBSD zealot.ksu.ru 7.1-STABLE FreeBSD 7.1-STABLE #1: Tue Jan 20 05:47:24 MSK 2009 r...@zealot.ksu.ru:/usr/obj/usr/src/sys/ZEALOT amd64 grep -A 1 DMA /var/log/messages: Jan 27 22:12:19 zealot kernel: acd0: setting up DMA failed Jan 27 22:12:30 zealot last message repeated 3623 times -- Jan 27 22:12:30 zealot kernel: acd0: setting up DMA failed Jan 27 22:12:33 zealot last message repeated 919 times -- Jan 27 22:12:33 zealot kernel: acd0: setting up DMA failed Jan 27 22:12:45 zealot last message repeated 4021 times -- Jan 27 22:12:45 zealot kernel: acd0: setting up DMA failed Jan 27 22:13:05 zealot last message repeated 6571 times -- Jan 31 21:41:48 zealot kernel: acd0: setting up DMA failed Jan 31 21:42:10 zealot last message repeated 7531 times -- Feb 1 08:24:59 zealot kernel: acd0: setting up DMA failed Feb 1 08:25:09 zealot last message repeated 10 times I've found a workaround: replace /sys/dev/ata/* with files from RELENG_7_1 DMA modes work again -- SY, Marat ___ 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.1-RELEASE I/O hang
On Wed, Feb 04, 2009 at 12:46:53PM +, Matt Burke wrote:
I have a machine with a PERC6/e controller. Attached to that are 3 disk
shelves, each configured as individual 14-disk RAID10 arrays (the PERC
annoyingly only lets you use 8 spans per array)
I can run bonnie++ on the arrays individually with no problem.
I can also run it across a gstripe of the arrays with no problem.
However running it over the 3 arrays in parallel causes something I/O
related in the kernel to hang.
To define 'hang' better:
It appears anything which needs disk io, even on a different controller
(albeit the same mfi driver), will hang. A command like 'ps' cached in
ram will work but bash hangs after execution, presumably while trying to
write ~/.bash_history
'sysctl -a' works but trying to run 'sysctl kern.msgbuf' also hangs
I've done some research and it seems the usual cause of bonnie++
crashing a system is due to overflowing TCQ. camcontrol doesn't see any
disks, so I've tried setting hw.mfi.max_cmds=32 in /boot/loader.conf but
it hadn't made any difference.
The bonnie++ invocation is this:
(newfs devices mfid[2-3], mount)
bonnie++ -s 64g -u root -p3
bonnie++ -d /data/2 -s 64g -u root -y s b2 21
bonnie++ -d /data/3 -s 64g -u root -y s b3 21
bonnie++ -d /data/4 -s 64g -u root -y s b4 21
and it always hangs on Rewriting It's a fresh 7.1-RELEASE with
nothing else running (devd, sshd, syslogd, etc)
Any ideas?
Compile ddb into the kernel, and do ps from the ddb prompt. If there
are processes hung in the nbufkv state, then the patch below might
help.
Index: gnu/fs/xfs/FreeBSD/xfs_buf.c
===
--- gnu/fs/xfs/FreeBSD/xfs_buf.c(revision 188080)
+++ gnu/fs/xfs/FreeBSD/xfs_buf.c(working copy)
@@ -81,7 +81,7 @@
{
struct buf *bp;
- bp = geteblk(0);
+ bp = geteblk(0, 0);
if (bp != NULL) {
bp-b_bufsize = size;
bp-b_bcount = size;
@@ -101,7 +101,7 @@
if (len = MAXPHYS)
return (NULL);
- bp = geteblk(len);
+ bp = geteblk(len, 0);
if (bp != NULL) {
KASSERT(BUF_REFCNT(bp) == 1,
(xfs_buf_get_empty: bp %p not locked,bp));
Index: ufs/ffs/ffs_vfsops.c
===
--- ufs/ffs/ffs_vfsops.c(revision 188080)
+++ ufs/ffs/ffs_vfsops.c(working copy)
@@ -1747,7 +1747,9 @@
(bufwrite: needs chained iodone (%p), bp-b_iodone));
/* get a new block */
- newbp = geteblk(bp-b_bufsize);
+ newbp = geteblk(bp-b_bufsize, GB_NOWAIT_BD);
+ if (newbp == NULL)
+ goto normal_write;
/*
* set it to be identical to the old block. We have to
@@ -1787,6 +1789,7 @@
}
/* Let the normal bufwrite do the rest for us */
+normal_write:
return (bufwrite(bp));
}
Index: kern/vfs_bio.c
===
--- kern/vfs_bio.c (revision 188080)
+++ kern/vfs_bio.c (working copy)
@@ -105,7 +105,8 @@
static void vfs_vmio_release(struct buf *bp);
static int vfs_bio_clcheck(struct vnode *vp, int size,
daddr_t lblkno, daddr_t blkno);
-static int flushbufqueues(int, int);
+static int buf_do_flush(struct vnode *vp);
+static int flushbufqueues(struct vnode *, int, int);
static void buf_daemon(void);
static void bremfreel(struct buf *bp);
@@ -258,6 +259,7 @@
#define QUEUE_DIRTY_GIANT 3/* B_DELWRI buffers that need giant */
#define QUEUE_EMPTYKVA 4 /* empty buffer headers w/KVA assignment */
#define QUEUE_EMPTY5 /* empty buffer headers */
+#define QUEUE_SENTINEL 1024/* not an queue index, but mark for sentinel */
/* Queues for free buffers with various properties */
static TAILQ_HEAD(bqueues, buf) bufqueues[BUFFER_QUEUES] = { { 0 } };
@@ -1703,21 +1705,23 @@
*/
static struct buf *
-getnewbuf(int slpflag, int slptimeo, int size, int maxsize)
+getnewbuf(struct vnode *vp, int slpflag, int slptimeo, int size, int maxsize,
+int gbflags)
{
+ struct thread *td;
struct buf *bp;
struct buf *nbp;
int defrag = 0;
int nqindex;
static int flushingbufs;
+ td = curthread;
/*
* We can't afford to block since we might be holding a vnode lock,
* which may prevent system daemons from running. We deal with
* low-memory situations by proactively returning memory and running
* async I/O rather then sync I/O.
*/
-
atomic_add_int(getnewbufcalls, 1);
atomic_subtract_int(getnewbufrestarts, 1);
restart:
@@ -1949,8 +1953,9 @@
*/
if (bp == NULL) {
- int flags;
+ int flags, norunbuf;
char *waitmsg;
+ int
Re: X.Org/xdm 'frozen' after installworld (7-stable)
On Tue, Feb 03, 2009 at 10:58:42AM -0800, Kent Stewart wrote: On Tuesday 03 February 2009 09:29:05 am Steve Franks wrote: This is a new weird one I've never had before. Consoles work fine, but the mouse and keyboard won't move/type when xdm pops up. ctrl-alt-F2 takes you right to a working console, and the mouse works fine in the console...ctrl-alt-backspace no longer kills X either... The option that I found the easiest was to add Option AutoAddDevices off To the ServerFlags section. I was told in the ports list that you can add it to the ServerLayout section but I could never make that work. I had the same problem yesterday after updating X. For me, adding dbus_enable=YES and hald_enable=YES to rc.conf and restarting solved the problem. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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
Free memory after upgrade to 7.1
Hello, I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I can see strange behavior after upgrade from 7.0: Apache does not free memory, for example: CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse then apachectl graceful CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free Swap: 4096M Total, 1844K Used, 4094M Free Some graph: http://max.af.czu.cz/memoryload.png I know before upgrade was memory using about 2,5GB, now much more, apache sometimes crash. Thanks for some help Tomas Randa ___ 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
7.1-RELEASE I/O hang
I have a machine with a PERC6/e controller. Attached to that are 3 disk shelves, each configured as individual 14-disk RAID10 arrays (the PERC annoyingly only lets you use 8 spans per array) I can run bonnie++ on the arrays individually with no problem. I can also run it across a gstripe of the arrays with no problem. However running it over the 3 arrays in parallel causes something I/O related in the kernel to hang. To define 'hang' better: It appears anything which needs disk io, even on a different controller (albeit the same mfi driver), will hang. A command like 'ps' cached in ram will work but bash hangs after execution, presumably while trying to write ~/.bash_history 'sysctl -a' works but trying to run 'sysctl kern.msgbuf' also hangs I've done some research and it seems the usual cause of bonnie++ crashing a system is due to overflowing TCQ. camcontrol doesn't see any disks, so I've tried setting hw.mfi.max_cmds=32 in /boot/loader.conf but it hadn't made any difference. The bonnie++ invocation is this: (newfs devices mfid[2-3], mount) bonnie++ -s 64g -u root -p3 bonnie++ -d /data/2 -s 64g -u root -y s b2 21 bonnie++ -d /data/3 -s 64g -u root -y s b3 21 bonnie++ -d /data/4 -s 64g -u root -y s b4 21 and it always hangs on Rewriting It's a fresh 7.1-RELEASE with nothing else running (devd, sshd, syslogd, etc) Any ideas? -- ___ 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: fun with if_re
Am 04.02.2009 um 10:05 schrieb Gerrit Kühn: After the last update (11th December 2008) I have noticed the following strange behaviour on at least two machines (identical hard- and software): After weeks of flawless operation, the network connection on both interfaces suddenly starts to mangle packages. Even a simple ping can show up to 50% or so package loss. The machine is mostly unreachable via net. ifconfig up/down did not cure this, turning off checksum-offloading and stuff did not help. Even simply rebooting the machine did not make the problem go away! I had to power-cycle them by unplugging all cables to get back to normal operation. I've seen a similar, but fully reproducible behavior on this ethernet hardware. It turned out to be not a problem of the driver: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/130957 Is it possible to use if_re from head as drop-in replacement to test the patches available after 12/09? The other way, using an older if_re, worked by replacing sys/dev/re/ if_re.c, sys/pci/if_rlreg.h and sys/pci/if_rl.c, so the answer ist likely yes. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ 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: Free memory after upgrade to 7.1
On Wed, 2009-02-04 at 17:08 +0100, Tomas Randa wrote: Hello, I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I can see strange behavior after upgrade from 7.0: Apache does not free memory, for example: CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse then apachectl graceful CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free Swap: 4096M Total, 1844K Used, 4094M Free Some graph: http://max.af.czu.cz/memoryload.png I know before upgrade was memory using about 2,5GB, now much more, apache sometimes crash. Thanks for some help Tomas Randa What is apache doing to use so much memory? This looks more like a memory leak in PHP, which is reclaimed after apache restarts its children. When you upgraded the OS, did you also upgrade ports? Could a new version of PHP be at fault here? Cheers Tom ___ 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: Free memory after upgrade to 7.1
Yes, I do portupgrade -Rrfia after upgrade of course. I don`t think it is some new PHP bug, because my friend have same problem with memory and he do not upgraded ports. But his box do not free memory after apache reload, my yes Any other suggestions ? Thanks TR Tom Evans napsal(a): On Wed, 2009-02-04 at 17:08 +0100, Tomas Randa wrote: Hello, I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I can see strange behavior after upgrade from 7.0: Apache does not free memory, for example: CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse then apachectl graceful CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free Swap: 4096M Total, 1844K Used, 4094M Free Some graph: http://max.af.czu.cz/memoryload.png I know before upgrade was memory using about 2,5GB, now much more, apache sometimes crash. Thanks for some help Tomas Randa What is apache doing to use so much memory? This looks more like a memory leak in PHP, which is reclaimed after apache restarts its children. When you upgraded the OS, did you also upgrade ports? Could a new version of PHP be at fault here? Cheers Tom ___ 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 ___ 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: fun with if_re
Hey. I have had similar symptoms on a dedicated server with the re driver. What I did was grab more recent drivers (which might be redundant now) and disable a set of features that weren't stable at the time. Please have a look at this PR that I submitted back then: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125805 On Wed, Feb 04, 2009 at 10:05:07AM +0100, Gerrit Kühn wrote: Hi folks, I have several routers here which are based on Jetway J7F4 ITX boards that come with two onboard re-interfaces. I run 7-stable on them via nanobsd and update them about once in three or four months. After the last update (11th December 2008) I have noticed the following strange behaviour on at least two machines (identical hard- and software): After weeks of flawless operation, the network connection on both interfaces suddenly starts to mangle packages. Even a simple ping can show up to 50% or so package loss. The machine is mostly unreachable via net. ifconfig up/down did not cure this, turning off checksum-offloading and stuff did not help. Even simply rebooting the machine did not make the problem go away! I had to power-cycle them by unplugging all cables to get back to normal operation. I have seen this behaviour on two different machines, so I can most probably rule out a hardware issue. It does not appear to happen often, though. I did not see this with an earlier image of 7-stable from June 2008, and probably even an image from early September was working fine (although I did not use that one for such a long time). Visiting the webcvs I noticed that there are a lot of patches for if_re in December 2008 and January 2009. The revision I'm having problems with is tagged 1.95.2.37 2008/12/09 11:01:17. Does anyone have an idea what broke if_re for me, and how I can get back to stable operation? Is it possible to use if_re from head as drop-in replacement to test the patches available after 12/09? I would prefer not to move the machines completely from -stable to -current. Here some further information about the NICs: ---pciconf--- r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet r...@pci0:0:11:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet --- ---dmesg--- re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 10 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:ab:d0:19 re0: [FILTER] re1: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 10 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x miibus1: MII bus on re1 rgephy1: RTL8169S/8110S/8211B media interface PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:ab:d0:1a re1: [FILTER] --- cu Gerrit ___ 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 ___ 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
FREEBSD 7.1-STABLE crashes when trying to mount USB device of solaris UFS filesystem
Hi everybody, today I met the following problems on my freebsd box. I had a USB stick of opensolaris bootable USB image and tried to mount it on my fbsd box. The first time, when I tried to mount the usb device, my system freezed and then rebooted giving me one core in my dumpdev. When I tried to redo the mounting, the kernel informed me that the filesystem needed to be fsck'd before mounted, or else I should have tried to mount it ro. When I tried to mount it with the read-only option set, the kernel panicked once more, and another core was dumped on my dumpdev. Recently, I keep having problems with USB disks. For instance, yesterday night I left an msdosfs USB partition mounted on my pc. This morning, the first thing I did was to check my emails through Thunderbird. When I clicked on the first unread message, everything freezed. There was no keyboard or mouse interaction whatsoever (both USB devices), and I had to shutdown my box via the shutdown button (hence and no core dumped, unfortunately). Another time, my kernel panicked exactly when I connected my USB external disk to my box while the kernel was loading. Since my box crashed thrice today (once due to the since-yesterday-mounted-msdosfs filesystem, and twice due to the opensolaris ufs filesystem) I decided to send you this bug report; so here is the thing: 1) # uname -a FreeBSD myhost 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Jan 15 21:47:42 EET 2009 r...@myhost:/usr/obj/usr/src/sys/KERNEL i386 2) My differences from GENERIC are: cpu I686_CPU # only i686 support options SCHED_ULE # I think now it's the default options QUOTA options MAC options AUDIT options KDTRACE_HOOKS options DDB_CTF options SMP device apic device pf device pflog device pfsync device atapicam options VESA 3) And my three core dumps are: vmcore.2: MAY be the core created when I plugged in the USB disk while the kernel was loading (sorry guys, not sure, hadn't payed too much attention at that moment, and don't remember if this is the correct dump): # kgdb kernel.debug vmcore.2 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... warning: kld_current_sos: Can't read filename: Input/output error #0 0x in ?? () (kgdb) vmcore.3 is the first core created when I tried to mount opensolaris ufs for the first time (without using mount -o ro) # kgdb kernel.debug vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: e9dee000 cpuid = 0 Uptime: 7h13m53s Physical memory: 2026 MB Dumping 224 MB: 209 193 177 (CTRL-C to abort) 161 (CTRL-C to abort) 145 129 113 97 81 65 49 33 17 1 Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from /boot/kernel/if_wpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_wpi.ko Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from /boot/kernel/wpifw.ko.symbols...done. done. Loaded symbols for /boot/kernel/wpifw.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/msdosfs_iconv.ko...Reading symbols from
Re: Free memory after upgrade to 7.1
Tomas Randa wrote: Hello, I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I can see strange behavior after upgrade from 7.0: Apache does not free memory, for example: CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse then apachectl graceful CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free Swap: 4096M Total, 1844K Used, 4094M Free Some graph: http://max.af.czu.cz/memoryload.png Please interpret this graph. When did you upgrade FreeBSD? On the 27th? What are the dips on the 30th and 2nd? Apache restarts? I know before upgrade was memory using about 2,5GB, now much more, apache sometimes crash. Please post several lines from top describing the processes you think are using up memory. For what it's worth, I have a similar situation: i386/PAE, upgraded from 7.0 to 7.1 on a machine with 4 GB RAM (3 GB accessible without PAE). I see no anomalies, *but* I'm using FastCGI with PHP and apache22-worker. I think this is the major change in malloc between 7.0 and 7.1: http://svn.freebsd.org/viewvc/base?view=revisionrevision=184602 You can test if it's the cause of your problem by toggling between 'D' and 'M' options to malloc.conf (see malloc(3), don't forget to restart apache). signature.asc Description: OpenPGP digital signature
Re: Can't get if_txp(4) to attach to a 3CR990B-TXM NIC
On Fri, Jun 08, 2007 at 09:13:37AM -0700, Freddie Cash wrote: Good morning, I'm having a bit of an issue getting a 3CR990B-TXM NIC detected and usable. Just wondering if anyone knows of any issues with this NIC chipset and/or with the motherboard chipset. The motherboard is a Biostar GeForce 6100 AM2 using an nVidia nForce 410 chipset and nVidia GeForce 6100 vide chipset. I've tried FreeBSD 6.1, 6.2, 6-STABLE (from Wed), and 7-CURRENT (from Thu) on this system. Everything installs nicely, everything on the board is detected correctly and usable. It's just the PCI NIC that doesn't work. If I compile a custom kernel without any network drivers in it, and then kldload if_txp, the following appears (same message on all 4 versions): txp0: 3Com 3cR990B-TXM Etherlink with 3XP Processor port 0xbc00-0xbc7f mem 0xfdcff000-0xfdcff07f irq 16 at device 8.0 on pci3 txp0: not waiting for boot device_attach: txp0 attach returned -1 If I reboot and load if_nve (on 6.2 and 6-stable), then I get: nve0: NVIDIA nForce MCP13 Networking Adapter port 0xdc00-0xdc07 mem 0xfe02d000-0xfe02dfff irq 22 at device 20.0 on pci0 nve0: Ethernet address 00:19:21:37:d5:60 Followed by the above messages for txp0 (it seems to detect and load if_txp automativally when loading if_nve). I've updated the BIOS on the motherboard. I've tried different PCI slots on the motherboard. Nothing changes. The not waiting for boot message keeps appearing. Attached are dmesg output from: 6.1-RELEASE GENERIC kerneldmesg_6.1.txt 6.2-RELEASE GENERIC kerneldmesg_6.2.txt 6.2-RELEASE GENERIC kernel verbose boot dmesg_6.2_verbose.txt 6-STABLE GENERIC kerneldmesg_6_generic.txt 6-STABLE TEST kernel (no NIC drivers) dmesg_6_custom.txt 7-CURRENTGENERIC kerneldmesg_7_generic.txt 7-CURRENTTEST kernel (no NIC drivers) dmesg_7_custom.txt I've looked through the cvsweb entries for txp and didn't see anything related to this issue. Reading the man page for if_txp(4) doesn't show anything about this error. I tried reading the source, but C is pretty much Greek to me. Everything I've read online says this NIC should work, and other are using it successfully. My gut feeling is that it's something to do with the motherboard chipset and the way it detects the NIC. But I could be way off. (As a test, I popped in a Kanotix LiveCD and the 3Com NIC is detected and usable, so it's [hopefully] not a defective NIC.) Anyone have any suggestions? Comments? Methods to destroy the NIC as an act of defiance? :) Now I've encountered similar issue. See http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003033.html for possible fix. ___ 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: FreeBSD 7.1 on MacBook Pro: sysinstall keyboard problems
I get the same effect, but with completely different hardware. This is on an AMD desktop system, with a Logitech wireless keyboard plugged in via USB. I don't have X installed, only trying to use it at the console. On 3-Feb-09, at 2:05 AM, Florian Smeets wrote: On 02.02.2009 21:37 Uhr, Arjan van Leeuwen wrote: Hi, I'm trying to install FreeBSD 7.1-RELEASE/i386 on a MacBook Pro (October 2008 model) with a US international keyboard. The DVD boots fine, but once I get into sysinstall, it's like the Ctrl key is stuck. Whenever I type 'C' it actually does Ctrl+C (and exits the install), and I can't even get a dmesg from fixit because 'D' acts like Ctrl+D and logs me out. Has anyone seen this before, any ideas on how to fix this? Yes, I've seen this. It's the same in recent HEAD (both with old USB and USB2). This started to happen with the MacBook Pros 4,1. The keyboard does work in X but not on the console. (i installed using a USB keyboard). I would very much like to see this working, but i have absolutely no clue where to start looking... Cheers, Florian ___ 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 ___ 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: fun with if_re
On Wed, Feb 04, 2009 at 06:37:53PM +0100, Henrik Friedrichsen wrote: Hey. I have had similar symptoms on a dedicated server with the re driver. What I did was grab more recent drivers (which might be redundant now) and disable a set of features that weren't stable at the time. re(4) had several issues for PCIe based controllers on 7.0-RELEASE and I believe most issues were resolved in HEAD/stable so I think you can safely turn checksum offloading, VLAN hardware assistance features. You can also enable TSO(default off) but I remember some users reported issues for TSO, I didn't encounter TSO issues though. If you can still reproduce the issue please let me know. Please have a look at this PR that I submitted back then: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125805 ___ 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: Free memory after upgrade to 7.1
Ivan Voras wrote: I think this is the major change in malloc between 7.0 and 7.1: http://svn.freebsd.org/viewvc/base?view=revisionrevision=184602 You can test if it's the cause of your problem by toggling between 'D' and 'M' options to malloc.conf (see malloc(3), don't forget to restart apache). Revision 184602 reverted the behavior so that malloc behaves the *same* for the 7.0 and 7.1 releases, with respect to DSS versus heap allocation. Jason ___ 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: fun with if_re
On Wed, 4 Feb 2009 19:46:55 +0900 Pyun YongHyeon pyu...@gmail.com wrote about Re: fun with if_re: PY Since you're using RTL8169SC it could be related with my commit PY r180519(cvs rev 1.95.2.22). It seems that RTL8169SC does not like PY memory mapped register access and I think jkim@ committed patch PY for the issue. Would you try re(4) in HEAD? PY (Just copying if_re.c, if_rlreg.h and if_rl.c from HEAD to PY stable would be enough to build re(4) on stable). Thanks for the advice. I did build new nanobsd images with these patches meanwhile and will start using them today. However, as it has worked without problems for weeks with the buggy version before, I will not be able to say if it is really working until next month or so. Or do you know any method to reliably trigger such errors? cu Gerrit ___ 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
