From gerrit at pmp.uni-hannover.de Mon Dec 1 00:26:08 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Mon Dec 1 00:26:17 2008 Subject: Curious failure of ZFS snapshots In-Reply-To: <20081129104640.GB1494@garage.freebsd.pl> References: <20081121151518.9f4f6af8.gerrit@pmp.uni-hannover.de> <20081121154153.a741e391.gerrit@pmp.uni-hannover.de> <200811210816.35573.fjwcash@gmail.com> <20081129104640.GB1494@garage.freebsd.pl> Message-ID: <20081201092604.da46d948.gerrit@pmp.uni-hannover.de> On Sat, 29 Nov 2008 11:46:40 +0100 Pawel Jakub Dawidek wrote about Re: Curious failure of ZFS snapshots: PJD> > > GK> mclane# ll /tank/home/pt/.zfs/ PJD> > > GK> ls: snapshot: Bad file descriptor PJD> > > GK> total 0 PJD> Is there a way for me to reproduce that? None that I could tell you right now. This was on a machine which uses zfs send/receive to backup its zfs filesystem to a backup server. Only one out of 6 or 7 zfs filesystems showed this problem. After rebooting it went away and did not appear again since then. cu Gerrit From gerrit at pmp.uni-hannover.de Mon Dec 1 00:32:36 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Mon Dec 1 00:32:47 2008 Subject: Curious failure of ZFS snapshots In-Reply-To: References: <20081130000059.GC1494@garage.freebsd.pl> Message-ID: <20081201093232.59394eec.gerrit@pmp.uni-hannover.de> On Sun, 30 Nov 2008 01:05:48 +0000 Pete French wrote about Re: Curious failure of ZFS snapshots: PF> Here is what I am doing - this script is run with an argument '7am' or PF> '7pm' once per day. the mysql database is a slave replication from a PF> master, so there is a continuous trickle of data into it. The symbolic PF> links are there so you can connect to the mysql server and access PF> 'xxx-7am' or 'xxx-7pm' to get a previous version of database 'xxx'. PF> In case its not obvious, the filesystem 'tank/zfs' is mounted on the PF> director '/var/db/mysql'. If you run this for a few cycles it should PF> preseumably break for you too. If you think it will be useful I can also post my scripts. However, as I did not see the problem again so far, it might be the case that I messed something up manually while developing the scripts one or two weeks ago. As mentioned, even the unaccessible zfs snapshots did send/receive fine, so internally zfs seems to be happy (only unmounting them was a bad idea :-). cu Gerrit From vulture at netvulture.com Mon Dec 1 00:46:50 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Mon Dec 1 00:46:57 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge Message-ID: <4933A00E.7080201@netvulture.com> Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Thanks, -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- A non-text attachment was scrubbed... Name: dhclient_badcsum.cap Type: application/octet-stream Size: 1098 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081201/e2429cf4/dhclient_badcsum.obj From dewayne_freebsd at yahoo.com Mon Dec 1 03:13:44 2008 From: dewayne_freebsd at yahoo.com (Dewayne Geraghty) Date: Mon Dec 1 03:13:52 2008 Subject: make distribution halts during install (7.1Prerelease today) In-Reply-To: <20081201092604.da46d948.gerrit@pmp.uni-hannover.de> Message-ID: <478434.94854.qm@web46412.mail.sp1.yahoo.com> The "make distribution" phase of a full build of 7.1 Prerelease, sourced today (Mon Dec 1 10:34:45 UTC 2008), unfortunately failed. make distribution DESTDIR=/differentplace failed (see below), however the following worked ok: buildkernel, installkernerl, buildworld, installworld. Two systems (a Uni and Dual processor) were used and both failed at the same point. Both building systems were successful in building/installing kernel and world for themselves and for a different DESTDIR (per the Handbook). Only the make distribution failed (a clue?) The repeated attempts to make distribution DESTDIR=X failed at the same location (see below). The error message suggestions incorrect parameters to "install". Advise/guidance welcome. #cd /usr/src && make DESTDIR=/usr/k_brfw-d distribution cd /usr/src/etc; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make distribution cd /usr/src/etc; install -o root -g wheel -m 644 amd.map apmd.conf auth.conf crontab csh.cshrc csh.login csh.logout devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab freebsd-update.conf ftpusers gettytab group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf libalias.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf nsswitch.conf portsnap.conf pf.os phones profile protocols rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells snmpd.config sysctl.conf syslog.conf etc.i386/ttys /usr/src/etc/../gnu/usr.bin/man/manpath/manpath.config /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/src/etc/../usr.bin/locate/locate/locate.rc nscd.conf /usr/k_brfw-d/etc; cap_mkdb -l /usr/k_brfw-d/etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /usr/k_brfw-d/etc; install -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /usr/k_brfw-d/etc; pwd_mkdb -L -i -p -d /usr/k_brfw-d/etc /usr/k_brfw-d/etc/master.passwd install: wrong number or types of arguments usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-v] [-g group] [-m mode] [-o owner] directory ... *** Error code 64 Stop in /usr/src/etc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I also tried various CPUTYPES to ensure that all parameters to make, were populated. Having spent most of the day building kernels/worlds and gstripping, gjournalling and building a lot of ports, the package is looking pretty good. I hope that my explanation is concise it's been a long day and I'm stuck. Regards, Dewayne. Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline From janm at transactionware.com Mon Dec 1 06:17:44 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Mon Dec 1 06:17:53 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem Message-ID: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> Hi, I am seeing extremely poor performance (~100kB/s) when untaring large tar files into fresh ufs filesystems. I see the problem with softupdates and without softupdates but with an async mount. This is a Supermicro X7DB8 board, 4GB, 2 x Xeon 5140. Sample gstat output: dT: 1.033s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 585 61 0 0 0.0 61 170 13812.0 100.1| da2 I see ms/w start at about 200ms with a ~3MB/s throughput, and then I see ms/w rise and kBps drop. ms/w goes as high as 16-20s, and then suddenly drops back down to about 200ms. Using iostat, while the performance is high(er), kb/t is 64kB, as the problem starts it drops towards 2kB. Copying a single large file doesn't exhibit this problem, although throughput isn't great (~3-5MB/s). However, that's better that 100kB/s. arcmsr0: mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq 16 at device 14.0 > on pci10 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2008-08-06 arcmsr0: [ITHREAD] There are eight disks connected in a RAID-6 configuration. The controller's cache is write-through and the disks' write caches are disabled. NCQ is enabled on the drives. The same hardware when it ran 6.3-p1 didn't have this problem. However, the system BIOS was updated at the same time as the operating system (in an attempt to solve a recent em problem), so it is possible that it is a BIOS related problem. The same build on an entirely different machine with an aac controller and SAS disks also doesn't show this problem. Running 'devinfo -r' doesn't list arcmsr as having an interrupt at all. (see below). That strikes me as odd; checking another machine that is still running 6.2 with an arcmsr controller, I can see the interrupt just fine. So: - Does anyone have any suggestions? - Is it normal for arcmsr to not show an interrupt in the output from devinfo in 7.1? Full dmesg, devinfo below. Thanks, Jan Mikkelsen Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Mon Dec 1 14:53:12 EST 2008 root@valhalla.transactionware.com:/home/janm/p4/freebsd-image-std-2008.2/work/base-freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/TW-SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2333.35-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4280651776 (4082 MB) avail memory = 4117843968 (3927 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] 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 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 ahd0: port 0x2400-0x24ff,0x2000-0x20ff mem 0xd8500000-0xd8501fff irq 16 at device 2.0 on pci4 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x2c00-0x2cff,0x2800-0x28ff mem 0xd8502000-0xd8503fff irq 17 at device 2.1 on pci4 ahd1: [ITHREAD] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs pcib5: at device 0.2 on pci3 pci5: on pcib5 bge0: mem 0xd8600000-0xd860ffff irq 16 at device 1.0 on pci5 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:40:f4:66:b1:56 bge0: [ITHREAD] pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x3000-0x301f mem 0xd8400000-0xd841ffff irq 18 at device 0.0 on pci6 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:31:67:86 em1: port 0x3020-0x303f mem 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:31:67:87 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pcib10: at device 0.0 on pci9 pci10: on pcib10 arcmsr0: mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq 16 at device 14.0 > on pci10 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2008-08-06 arcmsr0: [ITHREAD] pcib11: at device 0.2 on pci9 pci11: on pcib11 pci0: at device 8.0 (no driver attached) pcib12: irq 17 at device 28.0 on pci0 pci12: on pcib12 uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8c00400-0xd8c007ff irq 17 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib13: at device 30.0 on pci0 pci13: on pcib13 vgapci0: port 0x4000-0x40ff mem 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at device 1.0 on pci13 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA66 Waiting 5 seconds for SCSI devices to settle (probe46:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 77247MB (158201856 512 byte sectors: 255H 63S/T 9847C) da1 at arcmsr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: 953673MB (1953122304 512 byte sectors: 255H 63S/T 121576C) da2 at arcmsr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da2: 800131MB (1638669312 512 byte sectors: 255H 63S/T 102002C) sa0 at ahd1 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/da0s2a This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 bge0: link state changed to UP em0: link state changed to UP em1: link state changed to UP nexus0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x24-0x25 0x28-0x29 0x2c-0x2d 0x2e-0x2f 0x30-0x31 0x34-0x35 0x38-0x39 0x3c-0x3d 0x4e-0x4f 0x50-0x53 0x63 0x65 0x67 0x72-0x77 0x80 0x90-0x9f 0xa4-0xa5 0xa8-0xa9 0xac-0xad 0xb0-0xb5 0xb8-0xb9 0xbc-0xbd 0x295-0x296 0x4d0-0x4d1 0x800-0x80f 0xca2-0xca3 0xca8-0xcaf 0x1000-0x107f 0x1180-0x11bf 0xfe00 I/O memory addresses: 0xe0000000-0xefffffff 0xfe000000-0xfe01ffff 0xfe600000-0xfe6fffff 0xfec80000-0xfec80fff 0xfed1c000-0xfed1ffff 0xfee00000-0xfee0ffff cpu0 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 acpi_perf1 est1 p4tcc1 cpufreq1 cpu2 acpi_perf2 est2 p4tcc2 cpufreq2 cpu3 acpi_perf3 est3 p4tcc3 cpufreq3 pcib0 pci0 hostb0 pcib1 pci1 pcib2 pci2 pcib3 pci3 pcib4 pci4 ahd0 Interrupt request lines: 16 I/O ports: 0x2000-0x20ff 0x2400-0x24ff I/O memory addresses: 0xd8500000-0xd8501fff ahd1 Interrupt request lines: 17 I/O ports: 0x2800-0x28ff 0x2c00-0x2cff I/O memory addresses: 0xd8502000-0xd8503fff pcib5 pci5 bge0 I/O memory addresses: 0xd8600000-0xd860ffff miibus0 brgphy0 pcib6 pci6 em0 Interrupt request lines: 256 I/O ports: 0x3000-0x301f I/O memory addresses: 0xd8400000-0xd841ffff em1 Interrupt request lines: 257 I/O ports: 0x3020-0x303f I/O memory addresses: 0xd8420000-0xd843ffff pcib7 pci7 pcib8 pci8 pcib9 pci9 pcib10 pci10 arcmsr0 I/O memory addresses: 0xd8000000-0xd83fffff 0xd8900000-0xd8900fff pcib11 pci11 hostb1 hostb2 hostb3 hostb4 hostb5 hostb6 hostb7 pcib12 pci12 uhci0 I/O ports: 0x1800-0x181f usb0 uhub0 uhci1 Interrupt request lines: 19 I/O ports: 0x1820-0x183f usb1 uhub1 uhci2 Interrupt request lines: 18 I/O ports: 0x1840-0x185f usb2 uhub2 ehci0 I/O memory addresses: 0xd8c00400-0xd8c007ff usb3 uhub3 pcib13 pci13 vgapci0 I/O ports: 0x4000-0x40ff I/O memory addresses: 0xd0000000-0xd7ffffff 0xd8800000-0xd880ffff isab0 isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 I/O memory addresses: 0xc0000-0xcafff atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0x1860-0x186f ata0 Interrupt request lines: 14 acd0 acpi_sysresource0 atdma0 fpupnp0 attimer0 attimer1 pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 psm0 Interrupt request lines: 12 psmcpnp0 sio0 Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff sio1 Interrupt request lines: 3 I/O ports: 0x2f8-0x2ff fdc0 Interrupt request lines: 6 DMA request lines: 2 I/O ports: 0x3f0-0x3f5 0x3f7 ppc0 Interrupt request lines: 7 DMA request lines: 3 I/O ports: 0x378-0x37f ppbus0 plip0 lpt0 ppi0 acpi_button0 acpi_timer0 ACPI I/O ports: 0x1008-0x100b apic0 I/O memory addresses: 0xfec00000-0xfec0001f ram0 I/O memory addresses: 0x0-0x9dfff 0x100000-0xcff4ffff 0x100000000-0x12fffffff From jrhett at netconsonance.com Mon Dec 1 10:20:39 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon Dec 1 10:20:46 2008 Subject: Can I get a committer to mark this bug as blocking 6.4-RELEASE ? In-Reply-To: <1227733967.83059.1.camel@neo.cse.buffalo.edu> References: <84E1EC10-5323-4A8C-AD60-31142621DB32@netconsonance.com> <200810271151.47366.jhb@freebsd.org> <280616DD-A58F-4AE5-AB03-92C5F2C244EC@netconsonance.com> <1227733967.83059.1.camel@neo.cse.buffalo.edu> Message-ID: On Nov 26, 2008, at 1:12 PM, Ken Smith wrote: > Unfortunately no. As John indicated in the earlier thread BIOS > issues tend to be extremely hard to diagnose and so far it seems > like its specific to this one motherboard. > > Given this problem does cause issues with installs I'd be willing > to provide ISOs built at the point we've done the Errata Notice that > fixes the problem. But its too nebulous an issue to hold up the > release itself for. It does *not* cause an issue with installs. Installs work fine. It prevents booting an installed operating system. This appears to affect *ALL* of the Intel multi-cpu motherboards, including 3 generations of Rackable systems. The only reason it is nebulous is because absolutely nobody bothered to investigate the issue. I've been asking for what information would help. I've offered to setup serial consoles, or even ship systems, to anyone who would work on this problem. This is very big problem that will affect thousands of freebsd servers. Ken, the complete lack of action taken by FreeBSD to even CONSIDER investigating a significant bug reported during the testing process is shocking. And it truly puts a lie to those who continue to claim that we should be more active in the testing process. Every time I have done this, I'd found significant issues that affect a significant portion of the user base and COMPLETELY prevent deployment of a given release, and absolutely nothing has been done to even investigate the reports, nevermind address them. Congradulations. Good Job. If you aren't going to accept bug reports, why exactly do you release testing candidates at all? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Mon Dec 1 10:22:39 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon Dec 1 10:22:46 2008 Subject: usb keyboard dying at loader prompt In-Reply-To: <492FF127.807@icyb.net.ua> References: <4912E462.4090608@icyb.net.ua> <491586B9.2020303@vwsoft.com> <4919851B.7050800@icyb.net.ua> <492FF127.807@icyb.net.ua> Message-ID: <31DE68A5-D3CB-4C33-86E6-515581B425E1@netconsonance.com> Just FYI we are seeing the exact same problem with PS/2 keyboards and the 6.4 loader, so this may not be a USB-only issue. The complete lack of response to serious bug reports about 6.4-REL is fairly shocking. On Nov 28, 2008, at 5:24 AM, Andriy Gapon wrote: > I did more testing and it seems that our loader does have something to > do with the problem. > > If I boot to memtest86 the keyboard keeps working. > If I pause boot menu, wait for many minutes, the keyboard still works. > If I escape to loader prompt, this when the keyboard stops working > after > a few seconds. > > Not sure how to explain this. > I think I've seen some changes to reduce memory usage of loader, I > will > try them to see if that would make any difference for my situation. > > > -- > Andriy Gapon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From kensmith at cse.Buffalo.EDU Mon Dec 1 11:30:30 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Mon Dec 1 11:30:37 2008 Subject: Can I get a committer to mark this bug as blocking 6.4-RELEASE ? In-Reply-To: References: <84E1EC10-5323-4A8C-AD60-31142621DB32@netconsonance.com> <200810271151.47366.jhb@freebsd.org> <280616DD-A58F-4AE5-AB03-92C5F2C244EC@netconsonance.com> <1227733967.83059.1.camel@neo.cse.buffalo.edu> Message-ID: <1228159822.15856.45.camel@bauer.cse.buffalo.edu> On Mon, 2008-12-01 at 10:20 -0800, Jo Rhett wrote: > On Nov 26, 2008, at 1:12 PM, Ken Smith wrote: > > Unfortunately no. As John indicated in the earlier thread BIOS > > issues tend to be extremely hard to diagnose and so far it seems > > like its specific to this one motherboard. > > > > Given this problem does cause issues with installs I'd be willing > > to provide ISOs built at the point we've done the Errata Notice that > > fixes the problem. But its too nebulous an issue to hold up the > > release itself for. > > It does *not* cause an issue with installs. Installs work fine. It > prevents booting an installed operating system. This appears to > affect *ALL* of the Intel multi-cpu motherboards, including 3 > generations of Rackable systems. Understood, I guess I wasn't quite specific enough. The machine not being able to boot what got installed on its disk I consider an install problem. To date this is the first mention I've seen of it affecting more than one specific machine type. I might have missed it but I can't recall you mentioning this affected more than one particular machine. And it does not seem to affect *ALL* of the Intel multi-cpu motherboards. > The only reason it is nebulous is because absolutely nobody bothered > to investigate the issue. I've been asking for what information would > help. I've offered to setup serial consoles, or even ship systems, to > anyone who would work on this problem. Both John and Xin Li have chimed in on the two threads I've seen that are related to this specific topic. John diagnosed it as a issue with the BIOS. That's what makes it a nebulous problem. When working on those sorts of things most people liken it to "Whack-a-mole". > This is very big problem that will affect thousands of freebsd servers. Its still not clear it will affect thousands of servers. The same set of changes got made to stable/7 as were done to stable/6, and the test builds for the 7.1 release have been seeing much more testing than the test builds for the 6.4 release. If the problem was as wide-spread as you're suggesting we'd likely have seen a lot more reports and that factored into the decision about whether to go ahead or not. This all left me with a decision. My choices were to back out the BTX changes that were known to fix boot issues with certain motherboards and enabled booting from USB devices or leave things as they are. The motherboards that didn't boot with the older code had no work-around. The motherboards that did boot with the older code but not the newer code do have a work-around (use the old loader). Decisions like that suck, no matter which choice I make it's wrong. Holding the release until all bios issues get resolved isn't a viable option because of the "Whack-a-mole" thing mentioned above. Fix it for one and two break. It takes a lot of time/work to settle into what seems to work for the widest set of machines. > Ken, the complete lack of action taken by FreeBSD to even CONSIDER > investigating a significant bug reported during the testing process is > shocking. And it truly puts a lie to those who continue to claim that > we should be more active in the testing process. Every time I have > done this, I'd found significant issues that affect a significant > portion of the user base and COMPLETELY prevent deployment of a given > release, and absolutely nothing has been done to even investigate the > reports, nevermind address them. > > Congradulations. Good Job. If you aren't going to accept bug > reports, why exactly do you release testing candidates at all? So you're saying John and Xin Li's responses (Xin Li's questions still un-answered) to you show a complete lack to even consider investigating it? I know from past email threads your preference is for 6.X right now but as a test point if you aren't totally fried over this whole thing it would still be useful to know for sure if the issue exists with 7.1 test builds. If yes it eliminates a variety of possibilities and helps focus on the exact problem. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081201/15d949ce/attachment.pgp From jrhett at netconsonance.com Mon Dec 1 12:12:06 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon Dec 1 12:12:18 2008 Subject: Can I get a committer to mark this bug as blocking 6.4-RELEASE ? In-Reply-To: <1228159822.15856.45.camel@bauer.cse.buffalo.edu> References: <84E1EC10-5323-4A8C-AD60-31142621DB32@netconsonance.com> <200810271151.47366.jhb@freebsd.org> <280616DD-A58F-4AE5-AB03-92C5F2C244EC@netconsonance.com> <1227733967.83059.1.camel@neo.cse.buffalo.edu> <1228159822.15856.45.camel@bauer.cse.buffalo.edu> Message-ID: On Dec 1, 2008, at 11:30 AM, Ken Smith wrote: > Both John and Xin Li have chimed in on the two threads I've seen that > are related to this specific topic. John diagnosed it as a issue with > the BIOS. That's what makes it a nebulous problem. When working on > those sorts of things most people liken it to "Whack-a-mole". Diagnosed without testing. John never asked for any more information than the page fault description from me. When I asked what else to test and offered to supply systems for testing he stopped responding. Xin Li proposed a work-around that would have castrated the systems. It might work, but it wasn't a useful workaround so I deferred testing and focused on trying to get someone to address the real problem. >> This is very big problem that will affect thousands of freebsd >> servers. > > Its still not clear it will affect thousands of servers. Um... Rackable. Rackable ships cabinets full of systems to people that run FreeBSD. They don't sell to home or small corporate users, period. Any problem that affects a standard Rackable build will by definition affect thousands of systems. (much like any standard Dell or HP server build) > This all left me with a decision. My choices were to back out the BTX > changes that were known to fix boot issues with certain motherboards > and > enabled booting from USB devices or leave things as they are. Or do some more testing and determine the problem and fix it. I had a stack of systems demonstrating the problem. I could have shipped one to each freebsd developer you wanted to work on it. If you were willing to identify the affect source code and relevant gdb traps I would have happily worked on the source directly if that is what it took. I would test. I would supply console access and build systems. I would ship them to anyone who wanted one in their hot little hands. I would investigate the source code myself with a mere hour of "here's the relevant bits you need to consider" training. You could have done *anything* that suited your needs for testing. Instead you did nothing. > The > motherboards that didn't boot with the older code had no work-around. > The motherboards that did boot with the older code but not the newer > code do have a work-around (use the old loader). Not true. I tested this, installing the old loader and it did not change the problem. As reported. > Decisions like that > suck, no matter which choice I make it's wrong. Holding the release > until all bios issues get resolved isn't a viable option because of > the > "Whack-a-mole" thing mentioned above. Fix it for one and two > break. It > takes a lot of time/work to settle into what seems to work for the > widest set of machines. Break the boot loader for a very wide variety of systems rather than spend EVEN A SINGLE HOUR trying to diagnose the boot problem? Ken, your diagnosis here would make sense if ANY diagnosis had been attempted. This could be a trivial problem. It could be solved with 5 minutes of actually looking at it. What happened here is that you proceeded WITHOUT EVEN TRYING. > So you're saying John and Xin Li's responses (Xin Li's questions still > un-answered) to you show a complete lack to even consider > investigating > it? No actual diagnosis was done. I'm sorry, but if I pull my car up to my mechanic's garage and he makes a diagnosis of "no idea what's wrong" without even popping the hood, yeah that counts as "didn't even consider investigating" Worse yet, I would happily have done all of the grunt work for the investigation. But I'm not going to start by reading the source tree and making guesses where to look. If someone had given me some useful tests to do, I would have done them. > I know from past email threads your preference is for 6.X right now Not my preference, my ability to justify the evaluation and testing costs based on the support available for a given release. 7.0 doesn't work on this hardware at all. No, I haven't tested 7.1 because 6.4 was the easier testing target and I had thought that the security team was working on fixing the support model. So now we have the brilliance strategy of a long-term support -REL that we will never be able to use. The same stupid stunt that gave us 6.1 which was unusable and 6.2 which worked great but expired at the same time as 6.1. Etc and such forth. 6.5 will likely be short term support again, but the first release we can consider for deployment. > but as a test point if you aren't totally fried over this whole > thing it > would still be useful to know for sure if the issue exists with 7.1 > test > builds. If yes it eliminates a variety of possibilities and helps > focus > on the exact problem. I'm not burnt, but testing 7.1 has no meaningful relevance to my day job until we have a reasonable and working support mechanism. And given that I really pulled out the stops to make sure we had hardware for testing 6.4 (I went a bought a whole stack of systems *JUST FOR THIS*) and filed PRs and followed up, and couldn't get much more than "it sounds like this" kind of response ... seriously, would you invest a lot of time testing a very unstable release under those conditions? I mean jesus, 6.4 is supposed to be truly stable and yet you're willing to ship it not working with dozens of nearly identical reports of the same symptoms for both 6.4 and 7.1? Think seriously about what happened here, and how exactly I'm supposed to convince any executive of the logic of trying to test 7.1, when we're stuck on 6.3 until/if 6.5, which will be screwed for support? I mean seriously? The problem BTW is *EXACTLY* why I proposed the revisions to the support policy I did. Now you're stuck supporting 6.4 for 2 years, and you won't want to release 6.5 because you'll end up supporting three 6.x releases at the same time. Which would suck. Which is exactly what my proposed change to the policy would have fixed. FreeBSD has usually been a solid product on the more stable releases. It's really unfortunate that the release management is so willing to ignore the evidence which leads to major releases with serious flaws, and on top of that seems to take delight in marking the known flawed releases as the long support releases. Brilliance. Just plain brilliant, top to bottom. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From delphij at delphij.net Mon Dec 1 12:26:00 2008 From: delphij at delphij.net (Xin LI) Date: Mon Dec 1 12:26:08 2008 Subject: Can I get a committer to mark this bug as blocking 6.4-RELEASE ? In-Reply-To: References: <84E1EC10-5323-4A8C-AD60-31142621DB32@netconsonance.com> <200810271151.47366.jhb@freebsd.org> <280616DD-A58F-4AE5-AB03-92C5F2C244EC@netconsonance.com> <1227733967.83059.1.camel@neo.cse.buffalo.edu> <1228159822.15856.45.camel@bauer.cse.buffalo.edu> Message-ID: <4934484C.7060106@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jo Rhett wrote: > On Dec 1, 2008, at 11:30 AM, Ken Smith wrote: >> Both John and Xin Li have chimed in on the two threads I've seen that >> are related to this specific topic. John diagnosed it as a issue with >> the BIOS. That's what makes it a nebulous problem. When working on >> those sorts of things most people liken it to "Whack-a-mole". > > Diagnosed without testing. John never asked for any more information > than the page fault description from me. When I asked what else to test > and offered to supply systems for testing he stopped responding. Xin Li > proposed a work-around that would have castrated the systems. It might > work, but it wasn't a useful workaround so I deferred testing and > focused on trying to get someone to address the real problem. What I proposed is, to *narrow down* the problem so we can diagnose further, since nobody has idea at the moment about how the problem was, we do need to have further information, or, to get the whole 6.3->6.4 diff reviewed, which is (in my opinion) not an optimal use of developers' time. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk0SEwACgkQi+vbBBjt66AbmACeLJgUrf3fp9yNyUXV/T/YvCxT WDkAoL745HKpJw0CogTcZDdvbkMck3uG =0Fg4 -----END PGP SIGNATURE----- From jrhett at netconsonance.com Mon Dec 1 12:28:05 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon Dec 1 12:28:12 2008 Subject: confirming bugs is bad behavior, etc. In-Reply-To: References: <4912E462.4090608@icyb.net.ua> <491586B9.2020303@vwsoft.com> <4919851B.7050800@icyb.net.ua> <492FF127.807@icyb.net.ua> <31DE68A5-D3CB-4C33-86E6-515581B425E1@netconsonance.com> Message-ID: <7A8CC4E4-D59A-4841-8800-A3509C9DB68E@netconsonance.com> On Dec 1, 2008, at 11:59 AM, George V. Neville-Neil wrote: > I have mostly stayed away from these threads because they've often > devolved into unproductive finger pointing. > > Please leave the hyperbole out of your posts, or at least attempt to > cut it back. People on these lists are working quite hard to solve > problems for the whole of the FreeBSD community and your posts, such > as this one, are not helping us to move forward. My posts have always been directed at solving very real, operational problems with using FreeBSD on server platforms, which is exactly the stated goal for freebsd. I have always offered not only problems, but resources to help test or evaluate the issues, and serious considerations for ways to improve the process. Yes, you're right. Threads I start about real problems always devolve into unproductive finger pointing. That would be the freebsd developers attacking the reporter for identifying a real, operational problem. Take a look at the posts of the FreeBSD developers, and view for yourself the unprofessional attacks and personal insults hurled by them at people who are simply trying to get real problems resolved. And yet, instead of asking your developers to stop violating the posted rules of the mailing list, you are asking a bug reporter who simply informed another bug reporter that their problem was both widespread and not limited to USB devices to stop posting to the list. Because god knows that "yes we saw it too and it's widely reported" is bad behavior. Much worse that personal attacks which are strictly against the list rules. Yes, I'm sure that the personal attacks really do help drive freebsd development forward. Much more so than me bringing resources and actually testing things does. Now that Core has clearly spoken their mind on this issue, by refusing to ask freebsd developers to avoid violating the list charter and then publicly calling out someone for just saying "yeah, it's a widely reported problem" ... leaves any doubt that positive change is going to happen here. Your request is accepted. I'm unsubscribing now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Mon Dec 1 12:34:07 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon Dec 1 12:34:14 2008 Subject: Can I get a committer to mark this bug as blocking 6.4-RELEASE ? In-Reply-To: <4934484C.7060106@delphij.net> References: <84E1EC10-5323-4A8C-AD60-31142621DB32@netconsonance.com> <200810271151.47366.jhb@freebsd.org> <280616DD-A58F-4AE5-AB03-92C5F2C244EC@netconsonance.com> <1227733967.83059.1.camel@neo.cse.buffalo.edu> <1228159822.15856.45.camel@bauer.cse.buffalo.edu> <4934484C.7060106@delphij.net> Message-ID: On Dec 1, 2008, at 12:25 PM, Xin LI wrote: > What I proposed is, to *narrow down* the problem so we can diagnose > further, since nobody has idea at the moment about how the problem > was, > we do need to have further information, or, to get the whole 6.3->6.4 > diff reviewed, which is (in my opinion) not an optimal use of > developers' time. I got your request at the beginning of a vacation period where I was out of town. I had explicitly requested that 6.4 be blocked for this issue. I didn't think that "just my problem" would be enough to hold it up, but I apparently never even considered that -REL would happen without even responding to my request. Since nobody had responded to my request, and several posts had gone out about more testing for 7.1 (which had the same loader and the same problems) I assumed that 6.4 was similarly delayed. Had anyone said you needed this information pronto I would have canceled my Thanksgiving plans and spent the day in the lab testing this for you. For that matter, I had already pulled a diff of 6.3 to 6.4 and was working my way through it trying to find the relevant parts. If you would have identified the relevant portions, I would have happily tried backing out some of the changes on a per-component basis to figure it out. In short, tell me what you wanted/needed, and I would have done it ASAP. It's apparently irrelevant now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From gnn at neville-neil.com Mon Dec 1 12:40:47 2008 From: gnn at neville-neil.com (George V. Neville-Neil) Date: Mon Dec 1 12:40:58 2008 Subject: usb keyboard dying at loader prompt In-Reply-To: <31DE68A5-D3CB-4C33-86E6-515581B425E1@netconsonance.com> References: <4912E462.4090608@icyb.net.ua> <491586B9.2020303@vwsoft.com> <4919851B.7050800@icyb.net.ua> <492FF127.807@icyb.net.ua> <31DE68A5-D3CB-4C33-86E6-515581B425E1@netconsonance.com> Message-ID: At Mon, 1 Dec 2008 10:22:31 -0800, Jo Rhett wrote: > > Just FYI we are seeing the exact same problem with PS/2 keyboards and > the 6.4 loader, so this may not be a USB-only issue. > > The complete lack of response to serious bug reports about 6.4-REL is > fairly shocking. > Jo, I have mostly stayed away from these threads because they've often devolved into unproductive finger pointing. Please leave the hyperbole out of your posts, or at least attempt to cut it back. People on these lists are working quite hard to solve problems for the whole of the FreeBSD community and your posts, such as this one, are not helping us to move forward. Thanks, George Neville-Neil From gnn at freebsd.org Mon Dec 1 12:46:10 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Mon Dec 1 12:46:16 2008 Subject: confirming bugs is bad behavior, etc. In-Reply-To: <7A8CC4E4-D59A-4841-8800-A3509C9DB68E@netconsonance.com> References: <4912E462.4090608@icyb.net.ua> <491586B9.2020303@vwsoft.com> <4919851B.7050800@icyb.net.ua> <492FF127.807@icyb.net.ua> <31DE68A5-D3CB-4C33-86E6-515581B425E1@netconsonance.com> <7A8CC4E4-D59A-4841-8800-A3509C9DB68E@netconsonance.com> Message-ID: At Mon, 1 Dec 2008 12:27:57 -0800, Jo Rhett wrote: > > Now that Core has clearly spoken their mind on this issue, by refusing > to ask freebsd developers to avoid violating the list charter and then > publicly calling out someone for just saying "yeah, it's a widely > reported problem" ... leaves any doubt that positive change is going > to happen here. > Note that my mail was not marked in any way "From core" but was merely as a list participant. I've always been all for people finding and helping to work through bugs. What I object to is hyperbole and passive aggressiveness. For more on this see here: http://video.google.com/videoplay?docid=-4216011961522818645 If we can identify the issue let's fix it, but let's do it without lots of emotional stuff. Best, George From janm at transactionware.com Mon Dec 1 14:27:15 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Mon Dec 1 14:27:22 2008 Subject: usb keyboard dying at loader prompt In-Reply-To: <31DE68A5-D3CB-4C33-86E6-515581B425E1@netconsonance.com> Message-ID: <459EF5063D85400CB8D57DE9529A4D04@STUDYPC> Hi, > Just FYI we are seeing the exact same problem with PS/2 > keyboards and > the 6.4 loader, so this may not be a USB-only issue. > > [ ... ] > > On Nov 28, 2008, at 5:24 AM, Andriy Gapon wrote: > > I did more testing and it seems that our loader does have > something to > > do with the problem. > > > > If I boot to memtest86 the keyboard keeps working. > > If I pause boot menu, wait for many minutes, the keyboard > still works. > > If I escape to loader prompt, this when the keyboard stops working > > after > > a few seconds. > > > > Not sure how to explain this. > > I think I've seen some changes to reduce memory usage of loader, I > > will > > try them to see if that would make any difference for my situation. I have seen a similar problem on a Sun X4240 with 7.1-PRE. Using the ILOM remote keyboard works at the loader prompt but fails at the root filesystem prompt. I could work around the problem by attaching a different keyboard to the front USB port. Have you tried different keyboards? Regards, Jan. From janm at transactionware.com Mon Dec 1 14:41:34 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Mon Dec 1 14:41:41 2008 Subject: no priority on the console? Message-ID: <1A7634CAC3E147CB8B5CDA853E4856D7@STUDYPC> Hi, > As per my previous message, I've spent about 3 months trying to debug > a problem that was causing all disk I/O to go very slowly. A first glance this sounds similar to the problem I am having with very slow I/O on the Areca controller. (see: "7.1-PRERELEASE: arcmsr write performance problem") What controller are you using? Is the write cache enabled? > One of the things which made this nearly impossible to diagnose was > the absolute lack of priority given to the console. Logging in on the > console would take 12-15 minutes. Hitting enter on the console would > usually take between 3 and 5 minutes. Yes, I see this when I get the slow I/O problem. I think this has been a problem for some time; I have also seen "console freezes" (ssh, console, etc.) on 6.0 and 6.1 systems under SATA load. That was a while ago now (2006?). I also recall others reporting have seen the same problem intermittently. > This doesn't seem right to me. Can someone explain why the console > isn't given a very high priority? Why not? What other mechanism does > the sysadmin have for debugging, at a time when SSH logins either > fail, or take up to an hour to complete? In my case I could log into the system and start things like iostat and gstat and they kept running while the problem occurred so that I could see some of what was going on. I could also have what seemed like a reasonable ssh session with a jail on the same machine. This indicates to me that it is not the console that is the issue, but rather that the process of logging into the main machine touches some file that causes it to get caught up in the slow I/O quagmire. If the problem I am seeing now is the same as the one I saw a few years ago then I think the nature might have changed. My recollection is that utilities like iostat would also freeze back then, but I can't be sure. I'd like to resolve this problem too. Regards, Jan. From dewayne_freebsd at yahoo.com Mon Dec 1 18:34:25 2008 From: dewayne_freebsd at yahoo.com (Dewayne Geraghty) Date: Mon Dec 1 18:34:32 2008 Subject: make distribution halts during install (7.1Prerelease today) In-Reply-To: <478434.94854.qm@web46412.mail.sp1.yahoo.com> Message-ID: <798506.9689.qm@web46409.mail.sp1.yahoo.com> My earlier post falls into the embarrassing, wish that I hadn't category. To prevent anyone wasting effort, I'm replying. make distribution DESTDIR=/newplace requires a make world DESTDIR=/newplace as a prerequisite. The earlier post, caused me to believe that there was an error in /usr/bin/install, when using: make distribution DESTDIR=/differentplace The granularity of my testing was inappropriate. Apologies for the distraction. Dewayne Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline From vulture at netvulture.com Mon Dec 1 21:27:12 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Mon Dec 1 21:27:19 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <4933A00E.7080201@netvulture.com> References: <4933A00E.7080201@netvulture.com> Message-ID: <4934C733.4020506@netvulture.com> Can someone please confirm or rule out my issue with dhclient sending bad IP checksum packets. It would really suck if 7.1 was released with a broken DHCP client. Jonathan Feally wrote: > Sorry for the cross-post, but this could be either lists problem. > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from > make world. > > The server is refusing to answer the DISCOVER request, as it thinks > the IP checksum is wrong, which tcpdump also confirms. Other DHCP > clients are working fine on this network, so I do not believe it to be > the network, server or dhcpd. > > Server is running a 2 Port Intel card - em driver. > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > I have tried turning off both RXCSUM and TXCSUM on both the client and > server machines with no luck. I also tried the second NIC on the > server with the same result. > > This setup was working just a couple of weeks ago, and the only thing > that has changed is updating the src for a make world. PXE booting > this server does result in an IP being issued, so it is pointing > towards something new/changed in 7-STABLE. > > I have attached a 3 packet dump of the DISCOVER requests. > > Can anybody shed some light on this for me? > > Thanks, -Jon > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From janm at transactionware.com Mon Dec 1 21:45:31 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Mon Dec 1 21:45:40 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> Message-ID: <4934CB77.30906@transactionware.com> Replying to my own post ... I have done a test on the same machine comparing 6.3-p1 to 7.1-PRE. The performance is the expected ~6MB/s (because of the lack of cache) on 6.3-p1, so the BIOS change doesn't seem to be at fault. This seems to be a regression somewhere between 6.3 to 7.1. The Areca driver is the same in 6.3 and 7.1, so the problem seems to be elsewhere. I think this is more than just a "performance" problem. The observations with gstat showing extremely high ms/w values (I have seen them as high as 22000) makes it look like IO completion interrupts are being lost. Any suggestions on where to look next? Are there obvious candidates? Jan Mikkelsen wrote: > Hi, > > I am seeing extremely poor performance (~100kB/s) when untaring large > tar files into fresh ufs filesystems. I see the problem with > softupdates and without softupdates but with an async mount. This is a > Supermicro X7DB8 board, 4GB, 2 x Xeon 5140. > > Sample gstat output: > > dT: 1.033s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 585 61 0 0 0.0 61 170 13812.0 100.1| da2 > > I see ms/w start at about 200ms with a ~3MB/s throughput, and then I see > ms/w rise and kBps drop. ms/w goes as high as 16-20s, and then suddenly > drops back down to about 200ms. Using iostat, while the performance is > high(er), kb/t is 64kB, as the problem starts it drops towards 2kB. > > Copying a single large file doesn't exhibit this problem, although > throughput isn't great (~3-5MB/s). However, that's better that 100kB/s. > > arcmsr0: > mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq 16 at device 14.0 >> on pci10 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2008-08-06 > arcmsr0: [ITHREAD] > > There are eight disks connected in a RAID-6 configuration. The > controller's cache is write-through and the disks' write caches are > disabled. NCQ is enabled on the drives. > > The same hardware when it ran 6.3-p1 didn't have this problem. However, > the system BIOS was updated at the same time as the operating system (in > an attempt to solve a recent em problem), so it is possible that it is a > BIOS related problem. The same build on an entirely different machine > with an aac controller and SAS disks also doesn't show this problem. > > Running 'devinfo -r' doesn't list arcmsr as having an interrupt at all. > (see below). That strikes me as odd; checking another machine that is > still running 6.2 with an arcmsr controller, I can see the interrupt > just fine. > > So: > > - Does anyone have any suggestions? > > - Is it normal for arcmsr to not show an interrupt in the output from > devinfo in 7.1? > > Full dmesg, devinfo below. > > Thanks, > > Jan Mikkelsen > > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-PRERELEASE #0: Mon Dec 1 14:53:12 EST 2008 > > root@valhalla.transactionware.com:/home/janm/p4/freebsd-image-std-2008.2/work/base-freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/TW-SMP > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2333.35-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > Features=0xbfebfbff > > Features2=0x4e3bd > > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4280651776 (4082 MB) > avail memory = 4117843968 (3927 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > 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 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: irq 16 at device 0.0 on pci1 > pci2: on pcib2 > pcib3: irq 16 at device 0.0 on pci2 > pci3: on pcib3 > pcib4: at device 0.0 on pci3 > pci4: on pcib4 > ahd0: port > 0x2400-0x24ff,0x2000-0x20ff mem 0xd8500000-0xd8501fff irq 16 at device > 2.0 on pci4 > ahd0: [ITHREAD] > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs > ahd1: port > 0x2c00-0x2cff,0x2800-0x28ff mem 0xd8502000-0xd8503fff irq 17 at device > 2.1 on pci4 > ahd1: [ITHREAD] > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs > pcib5: at device 0.2 on pci3 > pci5: on pcib5 > bge0: mem > 0xd8600000-0xd860ffff irq 16 at device 1.0 on pci5 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: Ethernet address: 00:40:f4:66:b1:56 > bge0: [ITHREAD] > pcib6: irq 18 at device 2.0 on pci2 > pci6: on pcib6 > em0: port 0x3000-0x301f mem > 0xd8400000-0xd841ffff irq 18 at device 0.0 on pci6 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:30:48:31:67:86 > em1: port 0x3020-0x303f mem > 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:30:48:31:67:87 > pcib7: at device 0.3 on pci1 > pci7: on pcib7 > pcib8: at device 4.0 on pci0 > pci8: on pcib8 > pcib9: at device 6.0 on pci0 > pci9: on pcib9 > pcib10: at device 0.0 on pci9 > pci10: on pcib10 > arcmsr0: > mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq 16 at device 14.0 >> on pci10 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2008-08-06 > arcmsr0: [ITHREAD] > pcib11: at device 0.2 on pci9 > pci11: on pcib11 > pci0: at device 8.0 (no driver attached) > pcib12: irq 17 at device 28.0 on pci0 > pci12: on pcib12 > uhci0: port > 0x1800-0x181f irq 17 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port > 0x1820-0x183f irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port > 0x1840-0x185f irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem 0xd8c00400-0xd8c007ff irq > 17 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self powered > pcib13: at device 30.0 on pci0 > pci13: on pcib13 > vgapci0: port 0x4000-0x40ff mem > 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at device 1.0 on pci13 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > p4tcc3: on cpu3 > orm0: at iomem 0xc0000-0xcafff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > acd0: DVDR at ata0-master UDMA66 > Waiting 5 seconds for SCSI devices to settle > (probe46:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da0: 77247MB (158201856 512 byte sectors: 255H 63S/T 9847C) > da1 at arcmsr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da1: 953673MB (1953122304 512 byte sectors: 255H 63S/T 121576C) > da2 at arcmsr0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-5 device > da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da2: 800131MB (1638669312 512 byte sectors: 255H 63S/T 102002C) > sa0 at ahd1 bus 0 target 6 lun 0 > sa0: Removable Sequential Access SCSI-2 > device > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > Trying to mount root from ufs:/dev/da0s2a > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > ZFS filesystem version 6 > ZFS storage pool version 6 > bge0: link state changed to UP > em0: link state changed to UP > em1: link state changed to UP > > > nexus0 > acpi0 > Interrupt request lines: > 9 > I/O ports: > 0x10-0x1f > 0x24-0x25 > 0x28-0x29 > 0x2c-0x2d > 0x2e-0x2f > 0x30-0x31 > 0x34-0x35 > 0x38-0x39 > 0x3c-0x3d > 0x4e-0x4f > 0x50-0x53 > 0x63 > 0x65 > 0x67 > 0x72-0x77 > 0x80 > 0x90-0x9f > 0xa4-0xa5 > 0xa8-0xa9 > 0xac-0xad > 0xb0-0xb5 > 0xb8-0xb9 > 0xbc-0xbd > 0x295-0x296 > 0x4d0-0x4d1 > 0x800-0x80f > 0xca2-0xca3 > 0xca8-0xcaf > 0x1000-0x107f > 0x1180-0x11bf > 0xfe00 > I/O memory addresses: > 0xe0000000-0xefffffff > 0xfe000000-0xfe01ffff > 0xfe600000-0xfe6fffff > 0xfec80000-0xfec80fff > 0xfed1c000-0xfed1ffff > 0xfee00000-0xfee0ffff > cpu0 > acpi_perf0 > est0 > p4tcc0 > cpufreq0 > cpu1 > acpi_perf1 > est1 > p4tcc1 > cpufreq1 > cpu2 > acpi_perf2 > est2 > p4tcc2 > cpufreq2 > cpu3 > acpi_perf3 > est3 > p4tcc3 > cpufreq3 > pcib0 > pci0 > hostb0 > pcib1 > pci1 > pcib2 > pci2 > pcib3 > pci3 > pcib4 > pci4 > ahd0 > Interrupt request lines: > 16 > I/O ports: > 0x2000-0x20ff > 0x2400-0x24ff > I/O memory addresses: > 0xd8500000-0xd8501fff > ahd1 > Interrupt request lines: > 17 > I/O ports: > 0x2800-0x28ff > 0x2c00-0x2cff > I/O memory addresses: > 0xd8502000-0xd8503fff > pcib5 > pci5 > bge0 > I/O memory addresses: > 0xd8600000-0xd860ffff > miibus0 > brgphy0 > pcib6 > pci6 > em0 > Interrupt request lines: > 256 > I/O ports: > 0x3000-0x301f > I/O memory addresses: > 0xd8400000-0xd841ffff > em1 > Interrupt request lines: > 257 > I/O ports: > 0x3020-0x303f > I/O memory addresses: > 0xd8420000-0xd843ffff > pcib7 > pci7 > pcib8 > pci8 > pcib9 > pci9 > pcib10 > pci10 > arcmsr0 > I/O memory addresses: > 0xd8000000-0xd83fffff > 0xd8900000-0xd8900fff > pcib11 > pci11 > hostb1 > hostb2 > hostb3 > hostb4 > hostb5 > hostb6 > hostb7 > pcib12 > pci12 > uhci0 > I/O ports: > 0x1800-0x181f > usb0 > uhub0 > uhci1 > Interrupt request lines: > 19 > I/O ports: > 0x1820-0x183f > usb1 > uhub1 > uhci2 > Interrupt request lines: > 18 > I/O ports: > 0x1840-0x185f > usb2 > uhub2 > ehci0 > I/O memory addresses: > 0xd8c00400-0xd8c007ff > usb3 > uhub3 > pcib13 > pci13 > vgapci0 > I/O ports: > 0x4000-0x40ff > I/O memory addresses: > 0xd0000000-0xd7ffffff > 0xd8800000-0xd880ffff > isab0 > isa0 > sc0 > vga0 > I/O ports: > 0x3c0-0x3df > I/O memory addresses: > 0xa0000-0xbffff > orm0 > I/O memory addresses: > 0xc0000-0xcafff > atapci0 > I/O ports: > 0x170-0x177 > 0x1f0-0x1f7 > 0x376 > 0x3f6 > 0x1860-0x186f > ata0 > Interrupt request lines: > 14 > acd0 > acpi_sysresource0 > atdma0 > fpupnp0 > attimer0 > attimer1 > pci_link0 > pci_link1 > pci_link2 > pci_link3 > pci_link4 > pci_link5 > pci_link6 > pci_link7 > atkbdc0 > I/O ports: > 0x60 > 0x64 > atkbd0 > Interrupt request lines: > 1 > psm0 > Interrupt request lines: > 12 > psmcpnp0 > sio0 > Interrupt request lines: > 4 > I/O ports: > 0x3f8-0x3ff > sio1 > Interrupt request lines: > 3 > I/O ports: > 0x2f8-0x2ff > fdc0 > Interrupt request lines: > 6 > DMA request lines: > 2 > I/O ports: > 0x3f0-0x3f5 > 0x3f7 > ppc0 > Interrupt request lines: > 7 > DMA request lines: > 3 > I/O ports: > 0x378-0x37f > ppbus0 > plip0 > lpt0 > ppi0 > acpi_button0 > acpi_timer0 > ACPI I/O ports: > 0x1008-0x100b > apic0 > I/O memory addresses: > 0xfec00000-0xfec0001f > ram0 > I/O memory addresses: > 0x0-0x9dfff > 0x100000-0xcff4ffff > 0x100000000-0x12fffffff > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From awd at awdcomp.net Mon Dec 1 22:50:54 2008 From: awd at awdcomp.net (Andrew) Date: Mon Dec 1 22:51:02 2008 Subject: exim 4.69 freebsd 7.0 locking issues Message-ID: <4934D5C5.4030302@awdcomp.net> Hi all, Running Exim 4.69 on 7.0-RELEASE-p6 FreeBSD. The box has been recently upgraded from 6.3 (like 24 hours ago). Currently Exim is sending the following lines to the log files. 2008-12-01 19:02:35 Failed to get write lock for /var/spool/exim/db/callout.lockfile: Invalid argument 2008-12-01 19:02:35 Failed to get write lock for /var/spool/exim/db/callout.lockfile: Invalid argument 2008-12-01 19:02:35 1L74Cp-000GRN-3R Cannot lock /var/spool/exim/input//1L74Cp-000GRN-3R-D (22): Invalid argument The permissions are all correct for the spool directories and for Exim itself. It is creating stacks and stacks of 0 byte files in the message spool directory. I have recompiled all the ports but to no avail. I've upgraded 2 other machines with 99.0% the same setup with no issues. The only difference is hostnames/ips and that this machine is running mysql on it. Everything else on the machine (spam-assassin, clamav, mysql) is working fine. Has anybody got any ideas, other than downgrade back to fbsd 6.3? Cheers cya Andrew From doconnor at gsoft.com.au Mon Dec 1 22:53:41 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Dec 1 22:53:54 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <4934C733.4020506@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> Message-ID: <200812021703.44935.doconnor@gsoft.com.au> On Tuesday 02 December 2008 15:57:15 Jonathan Feally wrote: > Can someone please confirm or rule out my issue with dhclient sending > bad IP checksum packets. It would really suck if 7.1 was released with a > broken DHCP client. I had 7.1-PRE (early Octover) send out DHCP requests without issue, although I don't have that system available now. It was using em card. I have a 7.0-STABLE system with an sk card from July that does DHCP requests just fine too.. I don't have any bge systems running 7 to test with though sorry.. Does it always give dud packets or just DHCP? Can you try another card in the client? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081202/93b9145d/attachment.pgp From dgeo at ec-marseille.fr Tue Dec 2 02:13:30 2008 From: dgeo at ec-marseille.fr (Geoffroy Desvernay) Date: Tue Dec 2 02:13:37 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? Message-ID: <4935069A.8060209@ec-marseille.fr> Since last upgrade, I see much more CPU time "eated" by interrupts (at least 10% cpu in top) (see http://dgeo.perso.ec-marseille.fr/cpu-week.png) The server behave correctly (Or seems to?), and high interrupt number seems to come from bce cards (source: systat -vmstat) I just upgraded from "RELENG_7 Mon Sep 8 12:33:06 CEST 2008" to "RELENG_7_1 Sat Nov 29 16:20:35 CET 2008" We have the same machine (dell PE 1950) which have not been upgraded (production use - the two machine are carp(4)-redundant) I don't know if it is related to "SVN rev 184826 on 2008-11-10 22:40:16Z by delphij" patch to sys/dev/bce/if_bce.c If I can help debugging something? These are production machines, but I may test patches or ? on the faulty system. Some clues: Under the very same load (carp interfaces down on other machine), vmstat shows: for newer system: procs memory page disk faults cpu r b w avm fre flt re pi po fr sr mf0 in sy cs us sy id 0 1 1 4806M 460M 649 0 0 0 582 2 0 21770 1270 13653 1 15 85 and for older: procs memory page disk faults cpu r b w avm fre flt re pi po fr sr mf0 in sy cs us sy id 0 1 0 3694M 414M 236 0 0 0 199 17 0 286 317 386 1 1 97 bce-related part of dmesg for the newer system: bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 miibus0: on bce0 bce0: Ethernet address: 00:15:c5:f1:56:f4 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( SPLT MFW MSI ) bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 miibus1: on bce1 bce1: Ethernet address: 00:15:c5:f1:56:f2 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( SPLT MFW MSI ) And on the older system: bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 miibus0: on bce0 bce0: Ethernet address: 00:15:c5:f1:6a:47 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW MSI ) bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 miibus1: on bce1 bce1: Ethernet address: 00:15:c5:f1:6a:45 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW MSI ) -- Geoffroy Desvernay Ecole Centrale de Marseille -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081202/b9fe1c12/signature.pgp From rajkumars at gmail.com Tue Dec 2 03:47:57 2008 From: rajkumars at gmail.com (Rajkumar S) Date: Tue Dec 2 03:48:04 2008 Subject: ioctl DIOCSMBR: Inappropriate ioctl for device In-Reply-To: <64de5c8b0811242310l14932467kdcef55ab48322b23@mail.gmail.com> References: <64de5c8b0811242310l14932467kdcef55ab48322b23@mail.gmail.com> Message-ID: <64de5c8b0812020347v2c8eb928q48de999292681378@mail.gmail.com> On Tue, Nov 25, 2008 at 12:40 PM, Rajkumar S wrote: > boot0cfg: /dev/ad2: Class not found > boot0cfg: /dev/ad2: ioctl DIOCSMBR: Inappropriate ioctl for device I found the reason for this error: I need to set kern.geom.debugflags=16 before executing this command. raj From danny at cs.huji.ac.il Tue Dec 2 04:27:40 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Dec 2 04:30:04 2008 Subject: btx/pxeboot problem Message-ID: latest pxeboot (7.1): mother-board NIC/LOM CPU ------------- ------- --- Intel SWV25 em xeon works fine SUN X2200 bge amd works fine DELL PE 2950 bce xeon failes 95% of the times hangs or goes into btx dump regs. mode :-) Intel SE7320VP21 msk xeon failes 50% of the times - hangs pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine. so it seems that changes since 1.45 have fixed it for some, but it brakes for others :-). I can help testing, but btx is way out of my league. danny From dkelly at hiwaay.net Tue Dec 2 04:41:05 2008 From: dkelly at hiwaay.net (David Kelly) Date: Tue Dec 2 04:41:11 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <4934CB77.30906@transactionware.com> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> Message-ID: <34C71E28-F128-4F83-80EF-75768172A59D@hiwaay.net> On Dec 1, 2008, at 11:45 PM, Jan Mikkelsen wrote: > Replying to my own post ... > > I have done a test on the same machine comparing 6.3-p1 to 7.1- > PRE. The performance is the expected ~6MB/s (because of the lack > of cache) on 6.3-p1, so the BIOS change doesn't seem to be at fault. > > This seems to be a regression somewhere between 6.3 to 7.1. The > Areca driver is the same in 6.3 and 7.1, so the problem seems to be > elsewhere. > > I think this is more than just a "performance" problem. The > observations with gstat showing extremely high ms/w values (I have > seen them as high as 22000) makes it look like IO completion > interrupts are being lost. > > Any suggestions on where to look next? Are there obvious candidates? ATA maximum block transfer has dropped from 128k to 64k in 7.x. Am not sure where the handle is to tweak it back up but has slowed peak thruput on my Dell PE400SC. Can watch with "systat -v" Worse, I have a stripped array of 2 drives that won't transfer more than 43k at a chunk because apparently the stripe metadata didn't align nicely on 64k multiples. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From mike at sentex.net Tue Dec 2 05:19:20 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 2 05:19:27 2008 Subject: repeatable crash on RELENG7 Message-ID: <200812021319.mB2DJGJx003807@lava.sentex.ca> While trying to speed up nanobsd builds, I mounted /usr/obj on a ramdisk and found my box crashing. Thinking it might be hardware, I tried a separate machine, but with the same results. I have 4G of ram (i386). Am I just running out of some kernel memory ? If so, is there anything I can adjust to prevent this, yet still use mfs in this way ? mdconfig -a -t malloc -s 1800M newfs /dev/md0 mount /dev/md0 /usr/obj/ time make -j4 buildworld > /var/log/build.out in the middle of the buildworld on the serial console (after adding witness etc) g_vfs_done():md0[WRITE(offset=1752924160, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=1752952832, length=4096)]error = 28 g_vfs_done():md0[WRITE(offset=1753006080, length=14336)]error = 28 g_vfs_done():md0[WRITE(offset=1753020416, length=2048)]error = 28 g_vfs_done():md0[WRITE(offset=1753202688, length=81920)]error = 28 g_vfs_done():md0[WRITE(offset=1191755776, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1191886848, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1192017920, length=131072)]error = 28 panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated cpuid = 1 KDB: enter: panic [thread pid 15139 tid 100160 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> db> bt Tracing pid 15139 tid 100160 td 0xc7a85af0 kdb_enter_why(3231417278,3231417278,3231555983,3911968708,1,...) at kdb_enter_why+58 panic(3231555983,4096,335544320,3231555977,2000,...) at panic+310 kmem_malloc(3242659980,4096,258,3911968860,3230390816,...) at kmem_malloc+640 page_alloc(3242544416,4096,3911968847,258,3242544416,...) at page_alloc+39 slab_zalloc(3228209884,3242551688,8,3231552877,1878,...) at slab_zalloc+192 uma_zone_slab(3242551688,0,3231552877,1878,4,...) at uma_zone_slab+324 uma_zalloc_arg(3242544416,0,258,3349699312,3911969228,...) at uma_zalloc_arg+1395 ffs_vget(3333761124,922776,2,3911969228,3911969240,...) at ffs_vget+168 ufs_lookup(3911969308,3343471972,3911969744,3343471972,3911969340,...) at ufs_lookup+2555 VOP_CACHEDLOOKUP_APV(3232100544,3911969308,3911969744,3911969724,3335025920,...) at VOP_CACHEDLOOKUP_APV+165 vfs_cache_lookup(3911969440,3911969440,3911969704,3343471972,2,...) at vfs_cache_lookup+208 VOP_LOOKUP_APV(3232100544,3911969440,3349699312,3231462256,681,...) at VOP_LOOKUP_APV+165 lookup(3911969704,3231462256,198,191,3343637548,...) at lookup+1422 namei(3911969704,3911969608,96,0,3349699312,...) at namei+843 kern_stat(3349699312,672272928,0,3911969816,93,...) at kern_stat+61 stat(3349699312,3911970044,8,3231440732,3231973120,...) at stat+47 syscall(3911970104) at syscall+691 Xint0x80_syscall() at Xint0x80_syscall+32 --- syscall (188, FreeBSD ELF32, stat), eip = 134726611, esp = 3217021740, ebp = 3217021864 --- db> -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From kostikbel at gmail.com Tue Dec 2 05:38:32 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Dec 2 05:38:40 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <200812021319.mB2DJGJx003807@lava.sentex.ca> References: <200812021319.mB2DJGJx003807@lava.sentex.ca> Message-ID: <20081202133812.GY3045@deviant.kiev.zoral.com.ua> On Tue, Dec 02, 2008 at 08:19:17AM -0500, Mike Tancsa wrote: > While trying to speed up nanobsd builds, I mounted /usr/obj on a > ramdisk and found my box crashing. Thinking it might be hardware, I > tried a separate machine, but with the same results. I have 4G of > ram (i386). Am I just running out of some kernel memory ? If so, is > there anything I can adjust to prevent this, yet still use mfs in this way ? > > mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. > newfs /dev/md0 > mount /dev/md0 /usr/obj/ > time make -j4 buildworld > /var/log/build.out > > > in the middle of the buildworld on the serial console (after adding > witness etc) > > g_vfs_done():md0[WRITE(offset=1752924160, length=6144)]error = 28 > g_vfs_done():md0[WRITE(offset=1752952832, length=4096)]error = 28 > g_vfs_done():md0[WRITE(offset=1753006080, length=14336)]error = 28 > g_vfs_done():md0[WRITE(offset=1753020416, length=2048)]error = 28 > g_vfs_done():md0[WRITE(offset=1753202688, length=81920)]error = 28 > g_vfs_done():md0[WRITE(offset=1191755776, length=131072)]error = 28 > g_vfs_done():md0[WRITE(offset=1191886848, length=131072)]error = 28 > g_vfs_done():md0[WRITE(offset=1192017920, length=131072)]error = 28 > panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated > cpuid = 1 > KDB: enter: panic > [thread pid 15139 tid 100160 ] > Stopped at kdb_enter_why+0x3a: movl $0,kdb_why > db> > db> bt > Tracing pid 15139 tid 100160 td 0xc7a85af0 > kdb_enter_why(3231417278,3231417278,3231555983,3911968708,1,...) at > kdb_enter_why+58 > panic(3231555983,4096,335544320,3231555977,2000,...) at panic+310 > kmem_malloc(3242659980,4096,258,3911968860,3230390816,...) at > kmem_malloc+640 > page_alloc(3242544416,4096,3911968847,258,3242544416,...) at page_alloc+39 > slab_zalloc(3228209884,3242551688,8,3231552877,1878,...) at slab_zalloc+192 > uma_zone_slab(3242551688,0,3231552877,1878,4,...) at uma_zone_slab+324 > uma_zalloc_arg(3242544416,0,258,3349699312,3911969228,...) at > uma_zalloc_arg+1395 > ffs_vget(3333761124,922776,2,3911969228,3911969240,...) at ffs_vget+168 > ufs_lookup(3911969308,3343471972,3911969744,3343471972,3911969340,...) > at ufs_lookup+2555 > VOP_CACHEDLOOKUP_APV(3232100544,3911969308,3911969744,3911969724,3335025920,...) > at VOP_CACHEDLOOKUP_APV+165 > vfs_cache_lookup(3911969440,3911969440,3911969704,3343471972,2,...) > at vfs_cache_lookup+208 > VOP_LOOKUP_APV(3232100544,3911969440,3349699312,3231462256,681,...) > at VOP_LOOKUP_APV+165 > lookup(3911969704,3231462256,198,191,3343637548,...) at lookup+1422 > namei(3911969704,3911969608,96,0,3349699312,...) at namei+843 > kern_stat(3349699312,672272928,0,3911969816,93,...) at kern_stat+61 > stat(3349699312,3911970044,8,3231440732,3231973120,...) at stat+47 > syscall(3911970104) at syscall+691 > Xint0x80_syscall() at Xint0x80_syscall+32 > --- syscall (188, FreeBSD ELF32, stat), eip = 134726611, esp = > 3217021740, ebp = 3217021864 --- > db> > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081202/a363549f/attachment.pgp From mike at sentex.net Tue Dec 2 06:12:59 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 2 06:13:06 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <20081202133812.GY3045@deviant.kiev.zoral.com.ua> References: <200812021319.mB2DJGJx003807@lava.sentex.ca> <20081202133812.GY3045@deviant.kiev.zoral.com.ua> Message-ID: <200812021412.mB2ECsEp004018@lava.sentex.ca> At 08:38 AM 12/2/2008, Kostik Belousov wrote: > > > > mdconfig -a -t malloc -s 1800M >You cannot have ~ 2Gb of kernel memory allocated for md, at least not on >i386. Thanks, how do I find out what the limit is on a machine ? Is it vm.kvm_size ? ---Mike From kostikbel at gmail.com Tue Dec 2 06:20:59 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Dec 2 06:25:09 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <200812021412.mB2ECsEp004018@lava.sentex.ca> References: <200812021319.mB2DJGJx003807@lava.sentex.ca> <20081202133812.GY3045@deviant.kiev.zoral.com.ua> <200812021412.mB2ECsEp004018@lava.sentex.ca> Message-ID: <20081202142045.GA3045@deviant.kiev.zoral.com.ua> On Tue, Dec 02, 2008 at 09:12:54AM -0500, Mike Tancsa wrote: > At 08:38 AM 12/2/2008, Kostik Belousov wrote: > >> > >> mdconfig -a -t malloc -s 1800M > >You cannot have ~ 2Gb of kernel memory allocated for md, at least not on > >i386. > > Thanks, how do I find out what the limit is on a machine ? Is it > vm.kvm_size ? It is much less, and highly depends on your load, since KVA is used for all kind of allocations made by kernel. I think either md(4) or mdconfig(8) have a warning about malloc backing for md. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081202/6bb0d3a0/attachment.pgp From pluknet at gmail.com Tue Dec 2 07:02:18 2008 From: pluknet at gmail.com (pluknet) Date: Tue Dec 2 07:02:24 2008 Subject: ipfw2.c,v 1.76.2.17 Message-ID: Hi. Since this revision (appeared in 6.3) I think ipfw violates POLA. I mean "ipfw table N list" shows values of table in Internet '.' notation. A friend of mine was surprised to found Internet representation of this "optional 32-bit unsigned value". For example security/bruteblock stores unix timestamps here and AFAICS there is no possibility to come back to the previous output format (other than reverting this revision). -- wbr, pluknet From eugen at kuzbass.ru Tue Dec 2 07:41:38 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Dec 2 07:41:46 2008 Subject: ipfw2.c,v 1.76.2.17 In-Reply-To: References: Message-ID: <20081202154134.GA73002@svzserv.kemerovo.su> On Tue, Dec 02, 2008 at 06:02:16PM +0300, pluknet wrote: > Since this revision (appeared in 6.3) I think ipfw violates POLA. > I mean "ipfw table N list" shows values of table in Internet '.' notation. > > A friend of mine was surprised to found Internet representation > of this "optional 32-bit unsigned value". > > For example security/bruteblock stores unix timestamps here > and AFAICS there is no possibility to come back to the previous > output format (other than reverting this revision). That was fixed 8 months ago. Just upgrade to 6.4. Eugene Grosbein From brooks at freebsd.org Tue Dec 2 07:45:06 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue Dec 2 07:45:18 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge In-Reply-To: <4933A00E.7080201@netvulture.com> References: <4933A00E.7080201@netvulture.com> Message-ID: <20081202154550.GA91152@lor.one-eyed-alien.net> On Mon, Dec 01, 2008 at 12:27:58AM -0800, Jonathan Feally wrote: > Sorry for the cross-post, but this could be either lists problem. > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make > world. > > The server is refusing to answer the DISCOVER request, as it thinks the IP > checksum is wrong, which tcpdump also confirms. Other DHCP clients are > working fine on this network, so I do not believe it to be the network, > server or dhcpd. > > Server is running a 2 Port Intel card - em driver. > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > I have tried turning off both RXCSUM and TXCSUM on both the client and > server machines with no luck. I also tried the second NIC on the server > with the same result. > > This setup was working just a couple of weeks ago, and the only thing that > has changed is updating the src for a make world. PXE booting this server > does result in an IP being issued, so it is pointing towards something > new/changed in 7-STABLE. > > I have attached a 3 packet dump of the DISCOVER requests. > > Can anybody shed some light on this for me? Where are you running tcpdump? If on the host with the bge0 device, the checksums are probably useless due to checksum offloading. They should be valid on the server end of things. You might try disabling checksum offloading on the nic and see if that changes the results. It's possible the change to bpf.c to send packets through a socket when reassociateing isn't working correctly in that case. You might try backing out this change and seeing if the problem goes away (this will cause problems on some networks). http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?revision=178675&view=markup -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081202/64aa3bba/attachment.pgp From rizzo at iet.unipi.it Tue Dec 2 07:45:13 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Dec 2 07:45:30 2008 Subject: btx/pxeboot problem In-Reply-To: References: Message-ID: <20081202153408.GC54445@onelab2.iet.unipi.it> On Tue, Dec 02, 2008 at 01:48:17PM +0200, Danny Braniss wrote: > latest pxeboot (7.1): > mother-board NIC/LOM CPU > ------------- ------- --- > Intel SWV25 em xeon works fine > SUN X2200 bge amd works fine > DELL PE 2950 bce xeon failes 95% of the times > hangs or goes into btx dump regs. mode :-) > Intel SE7320VP21 msk xeon failes 50% of the times - hangs > > pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine. > so it seems that changes since 1.45 have fixed it for some, but it > brakes for others :-). I can help testing, but btx is way out of > my league. interesting, so this is the same problem i was seeing on the Asus/amd machines here... the commit log for 1.47 mention interrupt issues which are consistent with the random hangs or errors that I see while booting over the network. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.46;r2=1.47 I wonder if the hangs are related to interrupts coming in at the wrong time. I also wonder whether the same symptoms might also affect the standard loader and not just pxeloader, in which case the problem would be slightly more serious. I am afraid my ability to debug the problem isn't going much beyond this... cheers luigi From pluknet at gmail.com Tue Dec 2 07:58:28 2008 From: pluknet at gmail.com (pluknet) Date: Tue Dec 2 07:58:34 2008 Subject: ipfw2.c,v 1.76.2.17 In-Reply-To: <427101228232910@webmail19.yandex.ru> References: <427101228232910@webmail19.yandex.ru> Message-ID: 2008/12/2 Andrey V. Elsukov : > 02.12.08, 18:02, "pluknet" : >> Since this revision (appeared in 6.3) I think ipfw violates POLA. >> I mean "ipfw table N list" shows values of table in Internet '.' notation. >> A friend of mine was surprised to found Internet representation >> of this "optional 32-bit unsigned value". >> For example security/bruteblock stores unix timestamps here >> and AFAICS there is no possibility to come back to the previous >> output format (other than reverting this revision). > > It fixed in 1.76.2.21. > > -- > WBR, Andrey V. Elsukov > Andrey, Eugene. Thank you all! And please forgive me my laziness, not allowed to check up last revisions of ipfw2.c. -- wbr, pluknet From mikej at rogers.com Tue Dec 2 08:01:00 2008 From: mikej at rogers.com (Mike Jakubik) Date: Tue Dec 2 08:01:09 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4935069A.8060209@ec-marseille.fr> References: <4935069A.8060209@ec-marseille.fr> Message-ID: On Tue, December 2, 2008 4:57 am, Geoffroy Desvernay wrote: > Since last upgrade, I see much more CPU time "eated" by interrupts (at > least 10% cpu in top) > (see http://dgeo.perso.ec-marseille.fr/cpu-week.png) I am also seeing the same behavior on a farm of Dell servers. root@web.local:~# vmstat -i interrupt total rate irq1: atkbd0 18 0 irq14: ata0 176 0 irq16: mfi0 67924 1 irq20: uhci1 uhci3 1 0 irq21: uhci0 uhci+ 5 0 cpu0: timer 132244117 1997 irq257: bce1 3366039632 50853 cpu1: timer 132244053 1997 cpu2: timer 132244053 1997 cpu3: timer 132244053 1997 Total 3895084032 58846 Not only this, but i have also noticed that there are a number of errors reported by netstat now. before the drivers update, i would not get these errors. root@web.local:~# netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll 0 bce1 1500 00:1e:c9:b5:cc:b6 1848959 2197 1357031 0 0 From bu7cher at yandex.ru Tue Dec 2 08:01:52 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Tue Dec 2 08:01:59 2008 Subject: ipfw2.c,v 1.76.2.17 In-Reply-To: References: Message-ID: <427101228232910@webmail19.yandex.ru> 02.12.08, 18:02, "pluknet" : > Since this revision (appeared in 6.3) I think ipfw violates POLA. > I mean "ipfw table N list" shows values of table in Internet '.' notation. > A friend of mine was surprised to found Internet representation > of this "optional 32-bit unsigned value". > For example security/bruteblock stores unix timestamps here > and AFAICS there is no possibility to come back to the previous > output format (other than reverting this revision). It fixed in 1.76.2.21. -- WBR, Andrey V. Elsukov From mike at sentex.net Tue Dec 2 08:03:43 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 2 08:03:50 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <20081202142045.GA3045@deviant.kiev.zoral.com.ua> References: <200812021319.mB2DJGJx003807@lava.sentex.ca> <20081202133812.GY3045@deviant.kiev.zoral.com.ua> <200812021412.mB2ECsEp004018@lava.sentex.ca> <20081202142045.GA3045@deviant.kiev.zoral.com.ua> Message-ID: <200812021603.mB2G3eb9004481@lava.sentex.ca> At 09:20 AM 12/2/2008, Kostik Belousov wrote: >On Tue, Dec 02, 2008 at 09:12:54AM -0500, Mike Tancsa wrote: > > At 08:38 AM 12/2/2008, Kostik Belousov wrote: > > >> > > >> mdconfig -a -t malloc -s 1800M > > >You cannot have ~ 2Gb of kernel memory allocated for md, at least not on > > >i386. > > > > Thanks, how do I find out what the limit is on a machine ? Is it > > vm.kvm_size ? > >It is much less, and highly depends on your load, since KVA is used for all >kind of allocations made by kernel. I think either md(4) or mdconfig(8) have >a warning about malloc backing for md. Thanks! A warning might be helpful to prevent such foot shooting :) ---Mike From danny at cs.huji.ac.il Tue Dec 2 08:08:24 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Dec 2 08:09:30 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <4934C733.4020506@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> Message-ID: > Can someone please confirm or rule out my issue with dhclient sending > bad IP checksum packets. It would really suck if 7.1 was released with a > broken DHCP client. > I've had many problems lately, but none involved checksum nor the dhcpd (btw, I assume that you are seeing bad checksum on the receiving server) could you add a nic to your PE1750? danny > Jonathan Feally wrote: > > Sorry for the cross-post, but this could be either lists problem. > > > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from > > make world. > > > > The server is refusing to answer the DISCOVER request, as it thinks > > the IP checksum is wrong, which tcpdump also confirms. Other DHCP > > clients are working fine on this network, so I do not believe it to be > > the network, server or dhcpd. > > > > Server is running a 2 Port Intel card - em driver. > > > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > > > I have tried turning off both RXCSUM and TXCSUM on both the client and > > server machines with no luck. I also tried the second NIC on the > > server with the same result. > > > > This setup was working just a couple of weeks ago, and the only thing > > that has changed is updating the src for a make world. PXE booting > > this server does result in an IP being issued, so it is pointing > > towards something new/changed in 7-STABLE. > > > > I have attached a 3 packet dump of the DISCOVER requests. > > > > Can anybody shed some light on this for me? > > > > Thanks, -Jon > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From samflanker at gmail.com Tue Dec 2 08:51:23 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Tue Dec 2 08:51:30 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE Message-ID: <49356162.8070609@gmail.com> crossmessage http://lists.freebsd.org/pipermail/freebsd-pf/2008-November/004881.html hello I tried to rule with `synproxy state` uname FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 29 12:47:36 UTC 2008 (amd64 & i386 arch) the `synproxy state` is not working (web-browser does not receive the html-page) uname FreeBSD 7.0-RELEASE GENERIC (amd64 & i386 arch) the `synproxy state` is working # cat /etc/pf.conf pass on em0 proto tcp from any to 192.168.0.1 port 80 synproxy state to all, please check and confirm or deny /Vladimir Ermakov From pahom.rt at gmail.com Tue Dec 2 08:55:55 2008 From: pahom.rt at gmail.com (Alexandr Pakhomov) Date: Tue Dec 2 08:56:46 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <200812021412.mB2ECsEp004018@lava.sentex.ca> References: <200812021319.mB2DJGJx003807@lava.sentex.ca> <20081202133812.GY3045@deviant.kiev.zoral.com.ua> <200812021412.mB2ECsEp004018@lava.sentex.ca> Message-ID: On Tue, Dec 2, 2008 at 5:12 PM, Mike Tancsa wrote: > At 08:38 AM 12/2/2008, Kostik Belousov wrote: > >> > >> > mdconfig -a -t malloc -s 1800M >> You cannot have ~ 2Gb of kernel memory allocated for md, at least not on >> i386. >> > > Thanks, how do I find out what the limit is on a machine ? Is it > vm.kvm_size ? > > > ---Mike > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Try tune both vm.kmem_size and vm.kmem_size_max via /boot/loader.conf. They are equal to 330M by default. From samflanker at gmail.com Tue Dec 2 09:08:12 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Tue Dec 2 09:08:19 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE In-Reply-To: <20081202165601.GA55067@zero.nohack.se> References: <49356162.8070609@gmail.com> <20081202165601.GA55067@zero.nohack.se> Message-ID: <49356B87.6020201@gmail.com> Jesper Wallin wrote: > think this is because you also do filtering on the loopback interface and therefore block the initial handshake. Try with "set skip on lo0". :-) > > > Regards, > Jesper > > > Thank you, but I did not use blocking rules. /Vladimir Ermakov From vulture at netvulture.com Tue Dec 2 09:40:53 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 09:41:00 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> Message-ID: <49357329.9000107@netvulture.com> I will try another em card in that server to confirm/rule out the nic driver. I am seeing the same checksum number on both the source machine, the dhcp server machine, and a 3rd windows xp machine sniffing the traffic with etherreal/wireshark. The windows xp box is running an intel nic as well, and those 0.0.0.0.67 -> 255.255.255.255.68 packets as seen by the server do have the correct checksum. After the nic test, if no change from one driver to the other, then I'll try to un-patch the bpf.c change. At this point it is acting like the checksum offloading (which I did disable on both the client and server) just isn't working. Will let you know. -Jon Danny Braniss wrote: >> Can someone please confirm or rule out my issue with dhclient sending >> bad IP checksum packets. It would really suck if 7.1 was released with a >> broken DHCP client. >> >> > I've had many problems lately, but none involved checksum nor the dhcpd > (btw, I assume that you are seeing bad checksum on the receiving server) > could you add a nic to your PE1750? > > danny > > > >> Jonathan Feally wrote: >> >>> Sorry for the cross-post, but this could be either lists problem. >>> >>> I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is >>> running ISC DHCPD 3.0.x from recent ports, and the other dhclient from >>> make world. >>> >>> The server is refusing to answer the DISCOVER request, as it thinks >>> the IP checksum is wrong, which tcpdump also confirms. Other DHCP >>> clients are working fine on this network, so I do not believe it to be >>> the network, server or dhcpd. >>> >>> Server is running a 2 Port Intel card - em driver. >>> >>> Client is a Dell PE1750 with 2 onboard NIC's - bge driver. >>> >>> I have tried turning off both RXCSUM and TXCSUM on both the client and >>> server machines with no luck. I also tried the second NIC on the >>> server with the same result. >>> >>> This setup was working just a couple of weeks ago, and the only thing >>> that has changed is updating the src for a make world. PXE booting >>> this server does result in an IP being issued, so it is pointing >>> towards something new/changed in 7-STABLE. >>> >>> I have attached a 3 packet dump of the DISCOVER requests. >>> >>> Can anybody shed some light on this for me? >>> >>> Thanks, -Jon >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From delphij at delphij.net Tue Dec 2 10:18:08 2008 From: delphij at delphij.net (Xin LI) Date: Tue Dec 2 10:18:16 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: References: <4935069A.8060209@ec-marseille.fr> Message-ID: <49357BD0.4000008@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can anyone try reverting the changeset itself? There are two recent changesets: http://www.delphij.net/bce-185161.diff.bz2 http://www.delphij.net/bce-184826.diff.bz2 You can revert the change by doing this: cd /usr/src fetch http://www.delphij.net/bce-185161.diff.bz2 fetch http://www.delphij.net/bce-184826.diff.bz2 bzcat bce-185161.diff.bz2 | patch -R bzcat bce-184826.diff.bz2 | patch -R I'll check what's happening ASAP. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk1e88ACgkQi+vbBBjt66AsYACfXPwMnWtUsCeae/pBDOIav1Hd JN8AoL5cm8ZHYY0dKutRljtxRsiVYco0 =v1VF -----END PGP SIGNATURE----- From mikej at rogers.com Tue Dec 2 10:47:18 2008 From: mikej at rogers.com (Mike Jakubik) Date: Tue Dec 2 10:47:25 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <49357BD0.4000008@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> Message-ID: <577b277aabfaf99e2d0e33f3d8572cf7.squirrel@wettoast.dyndns.org> On Tue, December 2, 2008 1:17 pm, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Can anyone try reverting the changeset itself? There are two recent > changesets: > > http://www.delphij.net/bce-185161.diff.bz2 > http://www.delphij.net/bce-184826.diff.bz2 Thanks for the info, the exact card that i use is the following, it is shipped with Dell servers. --- bce1@pci0:3:0:0: class=0x020000 card=0x01b31028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = '5708C Broadcom NetXtreme II Gigabit Ethernet Adapter' class = network subclass = ethernet --- From vulture at netvulture.com Tue Dec 2 11:09:04 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 11:09:11 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <49357329.9000107@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> Message-ID: <493587D4.5000400@netvulture.com> Jonathan Feally wrote: > I will try another em card in that server to confirm/rule out the nic > driver. I am seeing the same checksum number on both the source > machine, the dhcp server machine, and a 3rd windows xp machine > sniffing the traffic with etherreal/wireshark. The windows xp box is > running an intel nic as well, and those 0.0.0.0.67 -> > 255.255.255.255.68 packets as seen by the server do have the correct > checksum. After the nic test, if no change from one driver to the > other, then I'll try to un-patch the bpf.c change. > > At this point it is acting like the checksum offloading (which I did > disable on both the client and server) just isn't working. > > Will let you know. > > -Jon > > Danny Braniss wrote: Tried a add-in em0 card - intel pro/1000 XT server card - 82544E chip - no change. also tried with ifconfig em0 -rxcsum ifconfig em0 -txcsum dhclient em0 No change. Packets still received with bad IP checksum. Went back to bge0 now and reversed rev 178675 back to 172506 care of patch via http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?r1=172506&r2=178675&view=patch Also no change. So this change to dhclient doesn't seem to be the issue. >From looking at http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/ this patch I took out is 7 months old, and I had this system running on 7-STABLE just fine about as of about 2-3 weeks ago. So it must have been something else in the sys/net or sys/netinet. I do seem some changes that are 3 weeks old, 4 weeks, and 6 days for these directories on files that would effect the packet assembly. Authors are julian, rwatson, and bz. I'm going to look through these recent changes to try to find some that has to do with the checksum process. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dgeo at ec-marseille.fr Tue Dec 2 12:02:27 2008 From: dgeo at ec-marseille.fr (geoffroy desvernay) Date: Tue Dec 2 12:02:35 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <49357BD0.4000008@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> Message-ID: <4935944A.9090509@ec-marseille.fr> Xin LI a ?crit : > Can anyone try reverting the changeset itself? There are two recent > changesets: > > http://www.delphij.net/bce-185161.diff.bz2 > http://www.delphij.net/bce-184826.diff.bz2 > > You can revert the change by doing this: > > cd /usr/src > fetch http://www.delphij.net/bce-185161.diff.bz2 > fetch http://www.delphij.net/bce-184826.diff.bz2 > bzcat bce-185161.diff.bz2 | patch -R > bzcat bce-184826.diff.bz2 | patch -R > > I'll check what's happening ASAP. > Done: I'd say it seems to be related... Before applying your patches: # vmstat -i interrupt total rate irq1: atkbd0 18 0 irq14: ata0 58 0 irq20: uhci1 96 0 irq21: uhci0 uhci+ 5 0 irq78: mfi0 539747 3 cpu0: timer 350029937 1999 irq256: bce0 6757905080 38611 irq259: bce1 8296789513 47403 cpu1: timer 350029945 1999 cpu2: timer 350030010 1999 cpu3: timer 350030025 1999 Total 16455354434 94018 After patch, make buildkernel && make reinstallkernel and reboot interrupt total rate irq1: atkbd0 18 0 irq14: ata0 58 0 irq20: uhci1 2 0 irq21: uhci0 uhci+ 5 0 irq78: mfi0 3947 24 cpu0: timer 320361 1989 irq256: bce0 6658 41 irq259: bce1 1428 8 cpu1: timer 320320 1989 cpu2: timer 320380 1989 cpu3: timer 320507 1990 Total 1293684 8035 -- geoffroy desvernay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081202/42039be0/signature.pgp From peters at netreconsys.com Tue Dec 2 15:21:35 2008 From: peters at netreconsys.com (Peter Sprokkelenburg) Date: Tue Dec 2 15:21:41 2008 Subject: Freebsd 7 STABLE 200807 amd64 - Realtek 8168 not working Message-ID: <11EA14E6-BF73-4D67-B287-45B76208BE11@netreconsys.com> I have an Asus P5Q-WS running FreeBSD 7 and the onboard Realtek NIC's are not being detected. No Kernel modifications as this is a fresh install. pciconf -lv : re0@pci0:3:0:0: class=0x020000 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet re1@pci0:2:0:0: class=0x020000 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet /var/log/messages: pci3: on pcib6 Dec 2 17:37:21 nas kernel: re0: port 0xc800-0xc8ff mem 0xfe5ff000-0xfe5fffff,0xfdef 0000-0xfdefffff irq 16 at device 0.0 on pci3 Dec 2 17:37:21 nas kernel: re0: Unknown H/W revision: 3c400000 Dec 2 17:37:21 nas kernel: device_attach: re0 attach returned 6 Dec 2 17:37:21 nas kernel: pcib7: irq 18 at device 28.5 on pci0 Dec 2 17:37:21 nas kernel: pci2: on pcib7 Dec 2 17:37:21 nas kernel: re1: port 0xb800-0xb8ff mem 0xfe4ff000-0xfe4fffff,0xfddf 0000-0xfddfffff irq 17 at device 0.0 on pci2 Dec 2 17:37:21 nas kernel: re1: Unknown H/W revision: 3c400000 Dec 2 17:37:21 nas kernel: device_attach: re1 attach returned 6 Is anymore info need to generate a patch? let me know. ------------------ Peter Sprokkelenburg mailto:peters@netreconsys.com From delphij at delphij.net Tue Dec 2 15:27:29 2008 From: delphij at delphij.net (Xin LI) Date: Tue Dec 2 15:27:37 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4935944A.9090509@ec-marseille.fr> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> Message-ID: <4935C453.8070301@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here is a patch that adjusts parameters of the interrupt handler, which reduces interrupts. These parameters are obtained from DragonFly, FYI. Note that this does not restore previous behavior, say, few interrupt if no traffic. I'm still looking into the real cause. geoffroy desvernay wrote: > Xin LI a ?crit : >> Can anyone try reverting the changeset itself? There are two recent >> changesets: >> >> http://www.delphij.net/bce-185161.diff.bz2 >> http://www.delphij.net/bce-184826.diff.bz2 >> >> You can revert the change by doing this: >> >> cd /usr/src >> fetch http://www.delphij.net/bce-185161.diff.bz2 >> fetch http://www.delphij.net/bce-184826.diff.bz2 >> bzcat bce-185161.diff.bz2 | patch -R >> bzcat bce-184826.diff.bz2 | patch -R >> >> I'll check what's happening ASAP. >> > Done: > > I'd say it seems to be related... > > Before applying your patches: > # vmstat -i > interrupt total rate > irq1: atkbd0 18 0 > irq14: ata0 58 0 > irq20: uhci1 96 0 > irq21: uhci0 uhci+ 5 0 > irq78: mfi0 539747 3 > cpu0: timer 350029937 1999 > irq256: bce0 6757905080 38611 > irq259: bce1 8296789513 47403 > cpu1: timer 350029945 1999 > cpu2: timer 350030010 1999 > cpu3: timer 350030025 1999 > Total 16455354434 94018 > > > After patch, make buildkernel && make reinstallkernel and reboot > interrupt total rate > irq1: atkbd0 18 0 > irq14: ata0 58 0 > irq20: uhci1 2 0 > irq21: uhci0 uhci+ 5 0 > irq78: mfi0 3947 24 > cpu0: timer 320361 1989 > irq256: bce0 6658 41 > irq259: bce1 1428 8 > cpu1: timer 320320 1989 > cpu2: timer 320380 1989 > cpu3: timer 320507 1990 > Total 1293684 8035 > - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk1xFMACgkQi+vbBBjt66DgRwCfRTItoRYMYtyWywXfa4arKl8n +usAoLUBSnifVZhK5wmENCpOAngI10WB =tLQJ -----END PGP SIGNATURE----- -------------- next part -------------- --- if_bce.c 2008-12-02 14:02:30.078918595 -0800 +++ .#if_bce.c.1.34.2.3.2.1 2008-12-02 13:49:07.000000000 -0800 @@ -925,15 +925,15 @@ sc->bce_rx_ticks = 0; #else /* Improve throughput at the expense of increased latency. */ - sc->bce_tx_quick_cons_trip_int = 20; - sc->bce_tx_quick_cons_trip = 20; - sc->bce_tx_ticks_int = 80; - sc->bce_tx_ticks = 80; - - sc->bce_rx_quick_cons_trip_int = 6; - sc->bce_rx_quick_cons_trip = 6; - sc->bce_rx_ticks_int = 18; - sc->bce_rx_ticks = 18; + sc->bce_tx_quick_cons_trip_int = 255; + sc->bce_tx_quick_cons_trip = 255; + sc->bce_tx_ticks_int = 1022; + sc->bce_tx_ticks = 1022; + + sc->bce_rx_quick_cons_trip_int = 128; + sc->bce_rx_quick_cons_trip = 128; + sc->bce_rx_ticks_int = 125; + sc->bce_rx_ticks = 125; #endif /* Update statistics once every second. */ @@ -2555,7 +2555,7 @@ } else if (BCE_CHIP_BOND_ID(sc) & BCE_CHIP_BOND_ID_SERDES_BIT) sc->bce_phy_flags |= BCE_PHY_SERDES_FLAG; - if (sc->bce_phy_flags && BCE_PHY_SERDES_FLAG) { + if (sc->bce_phy_flags & BCE_PHY_SERDES_FLAG) { sc->bce_flags |= BCE_NO_WOL_FLAG; if (BCE_CHIP_NUM(sc) != BCE_CHIP_NUM_5706) { sc->bce_phy_addr = 2; From jason.chambers at earthlink.net Tue Dec 2 15:30:56 2008 From: jason.chambers at earthlink.net (Jason Chambers) Date: Tue Dec 2 15:31:30 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? Message-ID: <4935C051.4060400@earthlink.net> Hello, There is already a PR for this issue. #122572 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/122572 Regards, --Jason ######################################### Fernan Aguero fernan at iib.unsam.edu.ar Fri Oct 17 13:37:16 UTC 2008 Previous message: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? Next message: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > On Friday 10 October 2008 01:11:17 pm Fernan Aguero wrote: > > > John, > > > > > > thanks for the tip. I have now successfully gone through > > > the process of making a new bootable CD using the ATA_HT1000 > > > patched kernel. [snipped] > So far everything seems to be working OK ... compiled and > installed a couple of ports (vim, screen, apache, > portupgrade), and everything looks fine. > > I can run more thourough tests if you want. Just let me know > what those are and guide me through them ... are we still on > time for including this patch in the upcoming 7.1? Will > there be a new beta or RC? > > Fernan I have already built world + kernel and installed some more ports. Again, everything works fine. Should I submit a PR asking for inclusion of this patch? This platform (ServerWorks HT1000, and the Dell PowerEdge SC1435) would not boot 7.0 nor 7.1-BETA. If the patch does not affect other chipsets, it would be good to include it in 7.1-RELEASE. Fernan From pyunyh at gmail.com Tue Dec 2 16:30:35 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Dec 2 16:30:49 2008 Subject: Freebsd 7 STABLE 200807 amd64 - Realtek 8168 not working In-Reply-To: <11EA14E6-BF73-4D67-B287-45B76208BE11@netreconsys.com> References: <11EA14E6-BF73-4D67-B287-45B76208BE11@netreconsys.com> Message-ID: <20081203003026.GA9639@cdnetworks.co.kr> On Tue, Dec 02, 2008 at 06:05:19PM -0500, Peter Sprokkelenburg wrote: > I have an Asus P5Q-WS running FreeBSD 7 and the onboard Realtek NIC's > are not being detected. > > No Kernel modifications as this is a fresh install. > > pciconf -lv : > > re0@pci0:3:0:0: class=0x020000 card=0x82c61043 chip=0x816810ec > rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > re1@pci0:2:0:0: class=0x020000 card=0x82c61043 chip=0x816810ec > rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > /var/log/messages: > > pci3: on pcib6 > Dec 2 17:37:21 nas kernel: re0: Ethernet> port 0xc800-0xc8ff mem 0xfe5ff000-0xfe5fffff,0xfdef > 0000-0xfdefffff irq 16 at device 0.0 on pci3 > Dec 2 17:37:21 nas kernel: re0: Unknown H/W revision: 3c400000 > Dec 2 17:37:21 nas kernel: device_attach: re0 attach returned 6 > Dec 2 17:37:21 nas kernel: pcib7: irq 18 at > device 28.5 on pci0 > Dec 2 17:37:21 nas kernel: pci2: on pcib7 > Dec 2 17:37:21 nas kernel: re1: Ethernet> port 0xb800-0xb8ff mem 0xfe4ff000-0xfe4fffff,0xfddf > 0000-0xfddfffff irq 17 at device 0.0 on pci2 > Dec 2 17:37:21 nas kernel: re1: Unknown H/W revision: 3c400000 > Dec 2 17:37:21 nas kernel: device_attach: re1 attach returned 6 > > Is anymore info need to generate a patch? > Please use latest stable/7 or 7.1-BETA2. re(4) will recognize your 8168C controller. -- Regards, Pyun YongHyeon From peter at simons-rock.edu Tue Dec 2 16:30:41 2008 From: peter at simons-rock.edu (Peter C. Lai) Date: Tue Dec 2 16:30:50 2008 Subject: Freebsd 7 STABLE 200807 amd64 - Realtek 8168 not working In-Reply-To: <11EA14E6-BF73-4D67-B287-45B76208BE11@netreconsys.com> References: <11EA14E6-BF73-4D67-B287-45B76208BE11@netreconsys.com> Message-ID: <20081203002705.GO27780@cesium.hyperfine.info> You need to move up to at least 20080716... On 2008-12-02 06:05:19PM -0500, Peter Sprokkelenburg wrote: > I have an Asus P5Q-WS running FreeBSD 7 and the onboard Realtek NIC's are > not being detected. > > No Kernel modifications as this is a fresh install. > > pciconf -lv : > > re0@pci0:3:0:0: class=0x020000 card=0x82c61043 chip=0x816810ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > re1@pci0:2:0:0: class=0x020000 card=0x82c61043 chip=0x816810ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > /var/log/messages: > > pci3: on pcib6 > Dec 2 17:37:21 nas kernel: re0: > port 0xc800-0xc8ff mem 0xfe5ff000-0xfe5fffff,0xfdef > 0000-0xfdefffff irq 16 at device 0.0 on pci3 > Dec 2 17:37:21 nas kernel: re0: Unknown H/W revision: 3c400000 > Dec 2 17:37:21 nas kernel: device_attach: re0 attach returned 6 > Dec 2 17:37:21 nas kernel: pcib7: irq 18 at device > 28.5 on pci0 > Dec 2 17:37:21 nas kernel: pci2: on pcib7 > Dec 2 17:37:21 nas kernel: re1: > port 0xb800-0xb8ff mem 0xfe4ff000-0xfe4fffff,0xfddf > 0000-0xfddfffff irq 17 at device 0.0 on pci2 > Dec 2 17:37:21 nas kernel: re1: Unknown H/W revision: 3c400000 > Dec 2 17:37:21 nas kernel: device_attach: re1 attach returned 6 > > Is anymore info need to generate a patch? > > let me know. > > > ------------------ > Peter Sprokkelenburg > mailto:peters@netreconsys.com > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From delphij at delphij.net Tue Dec 2 16:44:58 2008 From: delphij at delphij.net (Xin LI) Date: Tue Dec 2 16:45:06 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4935C453.8070301@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> Message-ID: <4935D67E.4070204@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I think I got a real fix. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk11n0ACgkQi+vbBBjt66Dy6wCfSl3eLRhj5TVs24Q+8ao5Mcz0 FNQAoK8KvziiXFoanhSlWv636o+HfYIj =AixC -----END PGP SIGNATURE----- -------------- next part -------------- Index: if_bce.c =================================================================== --- if_bce.c (revision 185565) +++ if_bce.c (working copy) @@ -7030,13 +7030,14 @@ /* Was it a link change interrupt? */ if ((status_attn_bits & STATUS_ATTN_BITS_LINK_STATE) != - (sc->status_block->status_attn_bits_ack & STATUS_ATTN_BITS_LINK_STATE)) + (sc->status_block->status_attn_bits_ack & STATUS_ATTN_BITS_LINK_STATE)) { bce_phy_intr(sc); - /* Clear any transient status updates during link state change. */ - REG_WR(sc, BCE_HC_COMMAND, - sc->hc_command | BCE_HC_COMMAND_COAL_NOW_WO_INT); - REG_RD(sc, BCE_HC_COMMAND); + /* Clear any transient status updates during link state change. */ + REG_WR(sc, BCE_HC_COMMAND, + sc->hc_command | BCE_HC_COMMAND_COAL_NOW_WO_INT); + REG_RD(sc, BCE_HC_COMMAND); + } /* If any other attention is asserted then the chip is toast. */ if (((status_attn_bits & ~STATUS_ATTN_BITS_LINK_STATE) != From kris at FreeBSD.org Tue Dec 2 18:52:49 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Dec 2 18:53:55 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <200812021603.mB2G3eb9004481@lava.sentex.ca> References: <200812021319.mB2DJGJx003807@lava.sentex.ca> <20081202133812.GY3045@deviant.kiev.zoral.com.ua> <200812021412.mB2ECsEp004018@lava.sentex.ca> <20081202142045.GA3045@deviant.kiev.zoral.com.ua> <200812021603.mB2G3eb9004481@lava.sentex.ca> Message-ID: <4935F481.6060407@FreeBSD.org> Mike Tancsa wrote: > At 09:20 AM 12/2/2008, Kostik Belousov wrote: >> On Tue, Dec 02, 2008 at 09:12:54AM -0500, Mike Tancsa wrote: >> > At 08:38 AM 12/2/2008, Kostik Belousov wrote: >> > >> >> > >> mdconfig -a -t malloc -s 1800M >> > >You cannot have ~ 2Gb of kernel memory allocated for md, at least >> not on >> > >i386. >> > >> > Thanks, how do I find out what the limit is on a machine ? Is it >> > vm.kvm_size ? >> >> It is much less, and highly depends on your load, since KVA is used >> for all >> kind of allocations made by kernel. I think either md(4) or >> mdconfig(8) have >> a warning about malloc backing for md. > > Thanks! A warning might be helpful to prevent such foot shooting :) malloc Storage for this type of memory disk is allocated with malloc(9). This limits the size to the malloc bucket limit in the kernel. If the -o reserve option is not set, creating and filling a large malloc-backed memory disk is a very easy way to panic a system. You almost never want to use malloc backing for a md, in favour of swap backing. Kris From vulture at netvulture.com Tue Dec 2 19:17:40 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 19:17:46 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper?? NOPE - We're OK) In-Reply-To: <493587D4.5000400@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> <493587D4.5000400@netvulture.com> Message-ID: <4935FA57.6080106@netvulture.com> OK, so I installed a different PE1750 with BETA2 and then updated the source via cvsup RELENG_7 from cvsup3 and all is ok now on that box. Went back the first box and cvsup'ed the src again into an empty directory and it compiled and worked fine. Looks like my updating of the source along the way missed http://svn.freebsd.org/viewvc/base?view=revision&revision=182924 as that is the only diff between the 2 local source trees. Sorry for the confusion. I've never had this issue before with cvsup, but guess there's always a first time. Thanks to all for checking my own bad testing work. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From janm at transactionware.com Tue Dec 2 20:05:55 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Tue Dec 2 20:06:03 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <34C71E28-F128-4F83-80EF-75768172A59D@hiwaay.net> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <34C71E28-F128-4F83-80EF-75768172A59D@hiwaay.net> Message-ID: <4936059E.4050905@transactionware.com> David Kelly wrote: > > On Dec 1, 2008, at 11:45 PM, Jan Mikkelsen wrote: > >> Replying to my own post ... >> >> I have done a test on the same machine comparing 6.3-p1 to 7.1-PRE. >> The performance is the expected ~6MB/s (because of the lack of cache) >> on 6.3-p1, so the BIOS change doesn't seem to be at fault. >> >> This seems to be a regression somewhere between 6.3 to 7.1. The Areca >> driver is the same in 6.3 and 7.1, so the problem seems to be elsewhere. >> >> I think this is more than just a "performance" problem. The >> observations with gstat showing extremely high ms/w values (I have >> seen them as high as 22000) makes it look like IO completion >> interrupts are being lost. >> >> Any suggestions on where to look next? Are there obvious candidates? > > > ATA maximum block transfer has dropped from 128k to 64k in 7.x. Am not > sure where the handle is to tweak it back up but has slowed peak thruput > on my Dell PE400SC. Can watch with "systat -v" Interesting, thanks. > Worse, I have a stripped array of 2 drives that won't transfer more than > 43k at a chunk because apparently the stripe metadata didn't align > nicely on 64k multiples. I know the partitions start at 64kB multiples in my case. I did, however, reduce the RAID-6 stripe size to 4kB (from 64kB) and that improved things slightly, but the throughput on 7.1 is still slower by about a factor of a about 6 (measured by untaring ~3GB across ~167k files into a fresh filesystem). And on 7.1 the machine is unusable during much of the time. > -- > David Kelly N4HHE, dkelly@HiWAAY.net > ======================================================================== > Whom computers would destroy, they must first drive mad. From n-butcher at fusiongol.com Tue Dec 2 22:56:54 2008 From: n-butcher at fusiongol.com (Nathan Butcher) Date: Tue Dec 2 22:57:01 2008 Subject: sysinstall automatic partition labelling/sizing problem Message-ID: <49362A3C.7060204@fusiongol.com> Automatic labelling on 7.0 created about 360MB for my root partition on a 8GB disk. After a buildkernel into 7.1-PRERELEASE, the root partition was exhausted during the installkernel. Maybe automatic labelling in sysinstall needs to allocate more than 360MB in the root (/) partition if it's going to stay big enough to accomodate a buildkernel and installkernel from source. From vulture at netvulture.com Tue Dec 2 23:09:08 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 23:09:21 2008 Subject: dhclient doing DISCOVER with bad IP checksum - compile optimization issue In-Reply-To: <4935FA57.6080106@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> <493587D4.5000400@netvulture.com> <4935FA57.6080106@netvulture.com> Message-ID: <49363099.5040701@netvulture.com> Ok, I managed to cause it again. dhclient was the problem. My source tree was fine. Turns out that it is my make.conf CFLAGS=-O3 setting. When compiled with -O3 it will generate packets with bad checksums. Simply recompiling it with -O2 did not cause this issue and dhclient works fine. So the question becomes, what is happening with -O3 that is breaking it? So far I am not having any other issues with -O3 on the rest of the system. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From demon at freebsd.org Wed Dec 3 01:02:31 2008 From: demon at freebsd.org (Dmitry Sivachenko) Date: Wed Dec 3 01:03:02 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4935D67E.4070204@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> Message-ID: <20081203082733.GA48143@m4-new.master-telecom.ru> On Tue, Dec 02, 2008 at 04:44:46PM -0800, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi guys, > > I think I got a real fix. > I tried that patch with very recent 7-STABLE. I does fix the problem for me. Thanks a lot! > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAkk11n0ACgkQi+vbBBjt66Dy6wCfSl3eLRhj5TVs24Q+8ao5Mcz0 > FNQAoK8KvziiXFoanhSlWv636o+HfYIj > =AixC > -----END PGP SIGNATURE----- > Index: if_bce.c > =================================================================== > --- if_bce.c (revision 185565) > +++ if_bce.c (working copy) > @@ -7030,13 +7030,14 @@ > > /* Was it a link change interrupt? */ > if ((status_attn_bits & STATUS_ATTN_BITS_LINK_STATE) != > - (sc->status_block->status_attn_bits_ack & STATUS_ATTN_BITS_LINK_STATE)) > + (sc->status_block->status_attn_bits_ack & STATUS_ATTN_BITS_LINK_STATE)) { > bce_phy_intr(sc); > > - /* Clear any transient status updates during link state change. */ > - REG_WR(sc, BCE_HC_COMMAND, > - sc->hc_command | BCE_HC_COMMAND_COAL_NOW_WO_INT); > - REG_RD(sc, BCE_HC_COMMAND); > + /* Clear any transient status updates during link state change. */ > + REG_WR(sc, BCE_HC_COMMAND, > + sc->hc_command | BCE_HC_COMMAND_COAL_NOW_WO_INT); > + REG_RD(sc, BCE_HC_COMMAND); > + } > > /* If any other attention is asserted then the chip is toast. */ > if (((status_attn_bits & ~STATUS_ATTN_BITS_LINK_STATE) != From richardtector at thekeelecentre.com Wed Dec 3 01:28:22 2008 From: richardtector at thekeelecentre.com (Richard Tector) Date: Wed Dec 3 01:28:29 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <34C71E28-F128-4F83-80EF-75768172A59D@hiwaay.net> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <34C71E28-F128-4F83-80EF-75768172A59D@hiwaay.net> Message-ID: <4936512F.5060406@thekeelecentre.com> David Kelly wrote: > > On Dec 1, 2008, at 11:45 PM, Jan Mikkelsen wrote: > >> Replying to my own post ... >> >> I have done a test on the same machine comparing 6.3-p1 to 7.1-PRE. >> The performance is the expected ~6MB/s (because of the lack of cache) >> on 6.3-p1, so the BIOS change doesn't seem to be at fault. >> >> This seems to be a regression somewhere between 6.3 to 7.1. The Areca >> driver is the same in 6.3 and 7.1, so the problem seems to be elsewhere. >> >> I think this is more than just a "performance" problem. The >> observations with gstat showing extremely high ms/w values (I have >> seen them as high as 22000) makes it look like IO completion >> interrupts are being lost. >> >> Any suggestions on where to look next? Are there obvious candidates? > > > ATA maximum block transfer has dropped from 128k to 64k in 7.x. Am not > sure where the handle is to tweak it back up but has slowed peak thruput > on my Dell PE400SC. Can watch with "systat -v" > > Worse, I have a stripped array of 2 drives that won't transfer more than > 43k at a chunk because apparently the stripe metadata didn't align > nicely on 64k multiples. Would changes to ATA have affected arcmsr? As far as I know it is not linked to the ATA subsystem at all, though it would explain some odd instances of one of my machines becoming unresponsive a couple of times a day. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2709 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081203/5236f7dc/smime.bin From dudu at dudu.ro Wed Dec 3 02:08:42 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Dec 3 02:08:50 2008 Subject: Weird truss output Message-ID: Hello, I'm running a statically linked binary, which I've built inside a jail. The jail's libc & co are in sync with the host's. Truss then shows this: -- cut here -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048524 -- -- UNKNOWN SYSCALL 1048516 -- -- UNKNOWN SYSCALL 1048572 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048556 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048524 -- -- UNKNOWN SYSCALL 1048564 -- -- UNKNOWN SYSCALL 1048548 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048532 -- -- UNKNOWN SYSCALL 1048564 -- -- and here -- Is this a bug or a feature? -- ~/.signature: no such file or directory From spry at anarchy.in.the.ph Wed Dec 3 06:48:08 2008 From: spry at anarchy.in.the.ph (Mars G Miro) Date: Wed Dec 3 06:48:15 2008 Subject: GIF parallel tunnels Message-ID: Hi, I have a GIF tunnel w/c has a v4 RFC1918 and v6 on it (both over public IPv4). In 7.0, even if I haven't set to 1 net.link.gif.parallel_tunnels, it would seem okay. But recent 7.1 just csup'd a few hours ago, if this sysctl is not set, recreating the GIF will crash the box (it will only crash upon re-creating). This is now the behavior? I'll try to do more tests tomorrow. Thanks. -- cheers mars From dudu at dudu.ro Wed Dec 3 07:45:34 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Dec 3 07:45:42 2008 Subject: Weird truss output In-Reply-To: <20081203152330.GD22076@dan.emsphone.com> References: <20081203152330.GD22076@dan.emsphone.com> Message-ID: On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson wrote: > In the last episode (Dec 03), Vlad GALU said: >> I'm running a statically linked binary, which I've built inside a >> jail. The jail's libc & co are in sync with the host's. Truss then >> shows this: >> >> -- cut here -- >> -- UNKNOWN SYSCALL 1048532 -- >> -- UNKNOWN SYSCALL 1048532 -- > > Is this a threaded app that you attached truss to after it was started? > The method that truss uses to catch syscall enter/exit events doesn't > indicate whether the event is an enter or an exit, so if you attach > while a syscall is active, truss handles the exit event as if it were a > syscall entry event, and never gets back in synch. It gets worse with > threaded apps because each thread is another chance to get out of > synch. Try this patch: > > Index: i386-fbsd.c > =================================================================== > RCS file: /home/ncvs/src/usr.bin/truss/i386-fbsd.c,v > retrieving revision 1.29 > diff -u -p -r1.29 i386-fbsd.c > --- i386-fbsd.c 28 Jul 2007 23:15:04 -0000 1.29 > +++ i386-fbsd.c 3 Dec 2008 15:20:09 -0000 > @@ -149,7 +149,14 @@ i386_syscall_entry(struct trussinfo *tru > fsc.name = > (syscall_num < 0 || syscall_num > nsyscalls) ? NULL : syscallnames[syscall_num]; > if (!fsc.name) { > - fprintf(trussinfo->outfile, "-- UNKNOWN SYSCALL %d --\n", syscall_num); > + fprintf(trussinfo->outfile, "-- UNKNOWN SYSCALL %u (0x%08x) --\n", syscall_num, syscall_num); > + if ((unsigned int)syscall_num > 0x1000) { > + /* When attaching to a running process, we have a 50-50 chance > + of attaching to a process waiting in a syscall, which means > + our first trap is an exit instead of an entry and we're out > + of synch. Reset our flag */ > + trussinfo->curthread->in_syscall = 0; > + } > } > > if (fsc.name && (trussinfo->flags & FOLLOWFORKS) > > > -- > Dan Nelson > dnelson@allantgroup.com > Hi Dan, You were right, this application was indeed threaded. The messages still occur, although at a slightly lower rate. One other thing that's not particularly helpful is this: -- cut here-- read(1074283119,"\M-Ry\^A\0",7356800) = 4 (0x4) -- and here -- I obviously don't have that many descriptors in my process. I can live with the malformed message, but it's a PITA not to know which fd the read was actually made from :( -- ~/.signature: no such file or directory From mikej at rogers.com Wed Dec 3 07:48:14 2008 From: mikej at rogers.com (Mike Jakubik) Date: Wed Dec 3 07:48:21 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <20081203082733.GA48143@m4-new.master-telecom.ru> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <20081203082733.GA48143@m4-new.master-telecom.ru> Message-ID: <8746e280e0118383ab37e9454199d06b.squirrel@wettoast.dyndns.org> On Wed, December 3, 2008 3:27 am, Dmitry Sivachenko wrote: > On Tue, Dec 02, 2008 at 04:44:46PM -0800, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi guys, >> >> I think I got a real fix. >> > > > I tried that patch with very recent 7-STABLE. > I does fix the problem for me. Good to hear. I will have to wait a few days before i update the code as these systems are in production. Thanks guys. From dnelson at allantgroup.com Wed Dec 3 08:00:42 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Dec 3 08:00:49 2008 Subject: Weird truss output In-Reply-To: References: Message-ID: <20081203152330.GD22076@dan.emsphone.com> In the last episode (Dec 03), Vlad GALU said: > I'm running a statically linked binary, which I've built inside a > jail. The jail's libc & co are in sync with the host's. Truss then > shows this: > > -- cut here -- > -- UNKNOWN SYSCALL 1048532 -- > -- UNKNOWN SYSCALL 1048532 -- Is this a threaded app that you attached truss to after it was started? The method that truss uses to catch syscall enter/exit events doesn't indicate whether the event is an enter or an exit, so if you attach while a syscall is active, truss handles the exit event as if it were a syscall entry event, and never gets back in synch. It gets worse with threaded apps because each thread is another chance to get out of synch. Try this patch: Index: i386-fbsd.c =================================================================== RCS file: /home/ncvs/src/usr.bin/truss/i386-fbsd.c,v retrieving revision 1.29 diff -u -p -r1.29 i386-fbsd.c --- i386-fbsd.c 28 Jul 2007 23:15:04 -0000 1.29 +++ i386-fbsd.c 3 Dec 2008 15:20:09 -0000 @@ -149,7 +149,14 @@ i386_syscall_entry(struct trussinfo *tru fsc.name = (syscall_num < 0 || syscall_num > nsyscalls) ? NULL : syscallnames[syscall_num]; if (!fsc.name) { - fprintf(trussinfo->outfile, "-- UNKNOWN SYSCALL %d --\n", syscall_num); + fprintf(trussinfo->outfile, "-- UNKNOWN SYSCALL %u (0x%08x) --\n", syscall_num, syscall_num); + if ((unsigned int)syscall_num > 0x1000) { + /* When attaching to a running process, we have a 50-50 chance + of attaching to a process waiting in a syscall, which means + our first trap is an exit instead of an entry and we're out + of synch. Reset our flag */ + trussinfo->curthread->in_syscall = 0; + } } if (fsc.name && (trussinfo->flags & FOLLOWFORKS) -- Dan Nelson dnelson@allantgroup.com From webmaster at kibab.com Wed Dec 3 08:23:28 2008 From: webmaster at kibab.com (Ilya Bakulin) Date: Wed Dec 3 08:23:36 2008 Subject: re0 problem In-Reply-To: <20081030051017.GB78796@cdnetworks.co.kr> References: <755632516.20081018001504@rulez.sk> <20081018020248.GB31303@cdnetworks.co.kr> <20081020012504.95adc0ca.nork@FreeBSD.org> <20081020071155.GH38923@cdnetworks.co.kr> <20081020132827.edbb2c53.webmaster@kibab.com> <20081021043152.GE43039@cdnetworks.co.kr> <20081030001123.cb1ebd9c.webmaster@kibab.com> <20081030051017.GB78796@cdnetworks.co.kr> Message-ID: <20081203192335.1da94c73.webmaster@kibab.com> On Thu, 30 Oct 2008 14:10:17 +0900 Pyun YongHyeon wrote: > > Please make sure you've (cold/warm) rebooted several times with > this patch. Just applying the patch and using it without reboots > doesn't necessary mean a working fix. Since it's hard to reproduce > the issue even on a system with problematic controllers I'd like to > have confidence in the patch. > > -- > Regards, > Pyun YongHyeon I've been using patched driver for a month, without any problems. Cold/warm reboots, panics, shutdowns occured regularly, but - no problems. Yesterday I've updated kernel to latest 7-STABLE & forgot to apply patch, and errors are here :-) Applying patch once more fixed problems. I think that perfect working of patched driver during past month definitely proves that your patch corrects incorrect behavior of re(4). Thank you very much! -- Ilya Bakulin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081203/ad69a08e/attachment.pgp From henrik at 50hz.ws Wed Dec 3 09:08:40 2008 From: henrik at 50hz.ws (Henrik Friedrichsen) Date: Wed Dec 3 09:08:46 2008 Subject: re0 problem In-Reply-To: <20081203192335.1da94c73.webmaster@kibab.com> References: <755632516.20081018001504@rulez.sk> <20081018020248.GB31303@cdnetworks.co.kr> <20081020012504.95adc0ca.nork@FreeBSD.org> <20081020071155.GH38923@cdnetworks.co.kr> <20081020132827.edbb2c53.webmaster@kibab.com> <20081021043152.GE43039@cdnetworks.co.kr> <20081030001123.cb1ebd9c.webmaster@kibab.com> <20081030051017.GB78796@cdnetworks.co.kr> <20081203192335.1da94c73.webmaster@kibab.com> Message-ID: <20081203165156.GA91351@dsp.50hz.ws> On Wed, Dec 03, 2008 at 07:23:35PM +0300, Ilya Bakulin wrote: > On Thu, 30 Oct 2008 14:10:17 +0900 > Pyun YongHyeon wrote: > > > > Please make sure you've (cold/warm) rebooted several times with > > this patch. Just applying the patch and using it without reboots > > doesn't necessary mean a working fix. Since it's hard to reproduce > > the issue even on a system with problematic controllers I'd like to > > have confidence in the patch. > > > > -- > > Regards, > > Pyun YongHyeon > > I've been using patched driver for a month, without any problems. Cold/warm reboots, panics, shutdowns occured regularly, but - no problems. Yesterday I've updated kernel to latest 7-STABLE & forgot to apply patch, and errors are here :-) > Applying patch once more fixed problems. > I think that perfect working of patched driver during past month definitely proves that your patch corrects incorrect behavior of re(4). Thank you very much! > > -- > Ilya Bakulin Here's another proof: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125805 From dnelson at allantgroup.com Wed Dec 3 09:09:00 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Dec 3 09:09:07 2008 Subject: Weird truss output In-Reply-To: References: <20081203152330.GD22076@dan.emsphone.com> Message-ID: <20081203170857.GE22076@dan.emsphone.com> In the last episode (Dec 03), Vlad GALU said: > On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson wrote: > > In the last episode (Dec 03), Vlad GALU said: > >> I'm running a statically linked binary, which I've built inside a > >> jail. The jail's libc & co are in sync with the host's. Truss then > >> shows this: > >> > >> -- cut here -- > >> -- UNKNOWN SYSCALL 1048532 -- > >> -- UNKNOWN SYSCALL 1048532 -- > > > > Is this a threaded app that you attached truss to after it was > > started? The method that truss uses to catch syscall enter/exit > > events doesn't indicate whether the event is an enter or an exit, > > so if you attach while a syscall is active, truss handles the exit > > event as if it were a syscall entry event, and never gets back in > > synch. It gets worse with threaded apps because each thread is > > another chance to get out of synch. Try this patch: > > You were right, this application was indeed threaded. The messages > still occur, although at a slightly lower rate. One other thing > that's not particularly helpful is this: > > -- cut here-- > read(1074283119,"\M-Ry\^A\0",7356800) = 4 (0x4) > -- and here -- > > I obviously don't have that many descriptors in my process. I can > live with the malformed message, but it's a PITA not to know which fd > the read was actually made from :( It looks like there's some other problem where truss either drops a syscall event, or puts some status fields into the wrong thread's structure. It seems to happen when two threads call blocking syscalls, and when they return, truss gets confused as to which thread called which syscall. The read syscall is probably still pending, and you're getting the arguments of the syscall that returned, printed as if it was the read syscall. When the read call completes, you'll probably get an --UNKNOWN SYSCALL-- line, or another mismatched syscall output line. An alternative it to use ktrace/kdump to trace the process; it's more cumbersome to use, but doesn't have problems with threaded processes. -- Dan Nelson dnelson@allantgroup.com From wearabnet at yahoo.ca Wed Dec 3 09:29:28 2008 From: wearabnet at yahoo.ca (Abdullah Ibn Hamad Al-Marri) Date: Wed Dec 3 09:29:36 2008 Subject: Can't installworld for latest RELENG_7 Message-ID: <755219.38504.qm@web111308.mail.gq1.yahoo.com> Hello, install -o root -g wheel -m 444 la_LN.ISO8859-1.out /usr/share/locale/la_LN.ISO8859-1/LC_TIME install -o root -g wheel -m 444 lt_LT.ISO8859-4.out /usr/share/locale/lt_LT.ISO8859-4/LC_TIME install -o root -g wheel -m 444 lt_LT.ISO8859-13.out /usr/share/locale/lt_LT.ISO8859-13/LC_TIME install -o root -g wheel -m 444 lt_LT.UTF-8.out /usr/share/locale/lt_LT.UTF-8/LC_TIME install -o root -g wheel -m 444 mn_MN.UTF-8.out /usr/share/locale/mn_MN.UTF-8/LC_TIME install -o root -g wheel -m 444 nb_NO.ISO8859-1.out /usr/share/locale/nb_NO.ISO8859-1/LC_TIME install: /usr/share/locale/nb_NO.ISO8859-1/LC_TIME: Too many levels of symbolic links *** Error code 71 Stop in /usr/src/share/timedef. *** Error code 1 Stop in /usr/src/share. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From dudu at dudu.ro Wed Dec 3 10:06:25 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Dec 3 10:06:32 2008 Subject: Weird truss output In-Reply-To: <20081203170857.GE22076@dan.emsphone.com> References: <20081203152330.GD22076@dan.emsphone.com> <20081203170857.GE22076@dan.emsphone.com> Message-ID: On Wed, Dec 3, 2008 at 7:08 PM, Dan Nelson wrote: > In the last episode (Dec 03), Vlad GALU said: >> On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson wrote: >> > In the last episode (Dec 03), Vlad GALU said: >> >> I'm running a statically linked binary, which I've built inside a >> >> jail. The jail's libc & co are in sync with the host's. Truss then >> >> shows this: >> >> >> >> -- cut here -- >> >> -- UNKNOWN SYSCALL 1048532 -- >> >> -- UNKNOWN SYSCALL 1048532 -- >> > >> > Is this a threaded app that you attached truss to after it was >> > started? The method that truss uses to catch syscall enter/exit >> > events doesn't indicate whether the event is an enter or an exit, >> > so if you attach while a syscall is active, truss handles the exit >> > event as if it were a syscall entry event, and never gets back in >> > synch. It gets worse with threaded apps because each thread is >> > another chance to get out of synch. Try this patch: >> >> You were right, this application was indeed threaded. The messages >> still occur, although at a slightly lower rate. One other thing >> that's not particularly helpful is this: >> >> -- cut here-- >> read(1074283119,"\M-Ry\^A\0",7356800) = 4 (0x4) >> -- and here -- >> >> I obviously don't have that many descriptors in my process. I can >> live with the malformed message, but it's a PITA not to know which fd >> the read was actually made from :( > > It looks like there's some other problem where truss either drops a > syscall event, or puts some status fields into the wrong thread's > structure. It seems to happen when two threads call blocking syscalls, > and when they return, truss gets confused as to which thread called > which syscall. The read syscall is probably still pending, and you're > getting the arguments of the syscall that returned, printed as if it > was the read syscall. When the read call completes, you'll probably > get an --UNKNOWN SYSCALL-- line, or another mismatched syscall output > line. > > An alternative it to use ktrace/kdump to trace the process; it's more > cumbersome to use, but doesn't have problems with threaded processes. Now why didn't I think of that? :/ Thanks for the suggestion! -- ~/.signature: no such file or directory From marius at nuenneri.ch Wed Dec 3 10:36:50 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Wed Dec 3 10:36:58 2008 Subject: Weird truss output In-Reply-To: <20081203170857.GE22076@dan.emsphone.com> References: <20081203152330.GD22076@dan.emsphone.com> <20081203170857.GE22076@dan.emsphone.com> Message-ID: On Wed, Dec 3, 2008 at 6:08 PM, Dan Nelson wrote: > In the last episode (Dec 03), Vlad GALU said: >> On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson wrote: >> > In the last episode (Dec 03), Vlad GALU said: >> >> I'm running a statically linked binary, which I've built inside a >> >> jail. The jail's libc & co are in sync with the host's. Truss then >> >> shows this: >> >> >> >> -- cut here -- >> >> -- UNKNOWN SYSCALL 1048532 -- >> >> -- UNKNOWN SYSCALL 1048532 -- >> > >> > Is this a threaded app that you attached truss to after it was >> > started? The method that truss uses to catch syscall enter/exit >> > events doesn't indicate whether the event is an enter or an exit, >> > so if you attach while a syscall is active, truss handles the exit >> > event as if it were a syscall entry event, and never gets back in >> > synch. It gets worse with threaded apps because each thread is >> > another chance to get out of synch. Try this patch: >> >> You were right, this application was indeed threaded. The messages >> still occur, although at a slightly lower rate. One other thing >> that's not particularly helpful is this: >> >> -- cut here-- >> read(1074283119,"\M-Ry\^A\0",7356800) = 4 (0x4) >> -- and here -- >> >> I obviously don't have that many descriptors in my process. I can >> live with the malformed message, but it's a PITA not to know which fd >> the read was actually made from :( > > It looks like there's some other problem where truss either drops a > syscall event, or puts some status fields into the wrong thread's > structure. It seems to happen when two threads call blocking syscalls, > and when they return, truss gets confused as to which thread called > which syscall. The read syscall is probably still pending, and you're > getting the arguments of the syscall that returned, printed as if it > was the read syscall. When the read call completes, you'll probably > get an --UNKNOWN SYSCALL-- line, or another mismatched syscall output > line. > > An alternative it to use ktrace/kdump to trace the process; it's more > cumbersome to use, but doesn't have problems with threaded processes. Maybe DTrace will help you but I don't know if there is enough ported yet. From dnelson at allantgroup.com Wed Dec 3 10:56:25 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Dec 3 10:56:33 2008 Subject: Weird truss output In-Reply-To: <20081203170857.GE22076@dan.emsphone.com> References: <20081203152330.GD22076@dan.emsphone.com> <20081203170857.GE22076@dan.emsphone.com> Message-ID: <20081203185622.GF22076@dan.emsphone.com> In the last episode (Dec 03), Dan Nelson said: > It looks like there's some other problem where truss either drops a > syscall event, or puts some status fields into the wrong thread's > structure. It seems to happen when two threads call blocking > syscalls, and when they return, truss gets confused as to which > thread called which syscall. The read syscall is probably still > pending, and you're getting the arguments of the syscall that > returned, printed as if it was the read syscall. When the read call > completes, you'll probably get an --UNKNOWN SYSCALL-- line, or > another mismatched syscall output line. It turns out that was the problem. There was a global structure that held syscall information. Converting it to a per-thread structure makes it work much better :) If you're adventurous, try applying the patch at http://www.evoy.net/FreeBSD/truss.diff , which fixes that problem plus a bunch of other stuff. If you're not adventurous, try the following instead, which just fixes the per-thread problem. Index: i386-fbsd.c =================================================================== RCS file: /home/ncvs/src/usr.bin/truss/i386-fbsd.c,v retrieving revision 1.29 diff -u -r1.29 i386-fbsd.c --- i386-fbsd.c 28 Jul 2007 23:15:04 -0000 1.29 +++ i386-fbsd.c 3 Dec 2008 18:48:23 -0000 @@ -49,6 +49,7 @@ #include #include +#include #include #include #include @@ -77,29 +78,29 @@ * 'struct syscall' describes the system call; it may be NULL, however, * if we don't know about this particular system call yet. */ -static struct freebsd_syscall { +struct freebsd_syscall { struct syscall *sc; const char *name; int number; unsigned long *args; int nargs; /* number of arguments -- *not* number of words! */ char **s_args; /* the printable arguments */ -} fsc; +}; /* Clear up and free parts of the fsc structure. */ static __inline void -clear_fsc(void) { - if (fsc.args) { - free(fsc.args); +clear_fsc(struct freebsd_syscall *fsc) { + if (fsc->args) { + free(fsc->args); } - if (fsc.s_args) { + if (fsc->s_args) { int i; - for (i = 0; i < fsc.nargs; i++) - if (fsc.s_args[i]) - free(fsc.s_args[i]); - free(fsc.s_args); + for (i = 0; i < fsc->nargs; i++) + if (fsc->s_args[i]) + free(fsc->s_args[i]); + free(fsc->s_args); } - memset(&fsc, 0, sizeof(fsc)); + memset(fsc, 0, sizeof(*fsc)); } /* @@ -117,9 +118,20 @@ unsigned int parm_offset; struct syscall *sc = NULL; struct ptrace_io_desc iorequest; + struct freebsd_syscall *fsc; + cpid = trussinfo->curthread->tid; - clear_fsc(); + fsc = trussinfo->curthread->fsc; + if (fsc == NULL) + { + fsc = malloc(sizeof(*fsc)); + if (fsc == NULL) + errx(1, "cannot allocate syscall struct"); + memset(fsc, 0, sizeof(*fsc)); + trussinfo->curthread->fsc = fsc; + } else + clear_fsc(fsc); if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) { @@ -145,17 +157,24 @@ break; } - fsc.number = syscall_num; - fsc.name = + fsc->number = syscall_num; + fsc->name = (syscall_num < 0 || syscall_num > nsyscalls) ? NULL : syscallnames[syscall_num]; - if (!fsc.name) { - fprintf(trussinfo->outfile, "-- UNKNOWN SYSCALL %d --\n", syscall_num); + if (!fsc->name) { + fprintf(trussinfo->outfile, "-- UNKNOWN SYSCALL %u (0x%08x) --\n", syscall_num, syscall_num); + if ((unsigned int)syscall_num > 0x1000) { + /* When attaching to a running process, we have a 50-50 chance + of attaching to a process waiting in a syscall, which means + our first trap is an exit instead of an entry and we're out + of synch. Reset our flag */ + trussinfo->curthread->in_syscall = 0; + } } - if (fsc.name && (trussinfo->flags & FOLLOWFORKS) - && ((!strcmp(fsc.name, "fork") - || !strcmp(fsc.name, "rfork") - || !strcmp(fsc.name, "vfork")))) + if (fsc->name && (trussinfo->flags & FOLLOWFORKS) + && ((!strcmp(fsc->name, "fork") + || !strcmp(fsc->name, "rfork") + || !strcmp(fsc->name, "vfork")))) { trussinfo->curthread->in_fork = 1; } @@ -163,30 +182,30 @@ if (nargs == 0) return; - fsc.args = malloc((1+nargs) * sizeof(unsigned long)); + fsc->args = malloc((1+nargs) * sizeof(unsigned long)); iorequest.piod_op = PIOD_READ_D; iorequest.piod_offs = (void *)parm_offset; - iorequest.piod_addr = fsc.args; + iorequest.piod_addr = fsc->args; iorequest.piod_len = (1+nargs) * sizeof(unsigned long); ptrace(PT_IO, cpid, (caddr_t)&iorequest, 0); if (iorequest.piod_len == 0) return; - if (fsc.name) - sc = get_syscall(fsc.name); + if (fsc->name) + sc = get_syscall(fsc->name); if (sc) { - fsc.nargs = sc->nargs; + fsc->nargs = sc->nargs; } else { #if DEBUG fprintf(trussinfo->outfile, "unknown syscall %s -- setting args to %d\n", - fsc.name, nargs); + fsc->name, nargs); #endif - fsc.nargs = nargs; + fsc->nargs = nargs; } - fsc.s_args = malloc((1+fsc.nargs) * sizeof(char*)); - memset(fsc.s_args, 0, fsc.nargs * sizeof(char*)); - fsc.sc = sc; + fsc->s_args = malloc((1+fsc->nargs) * sizeof(char*)); + memset(fsc->s_args, 0, fsc->nargs * sizeof(char*)); + fsc->sc = sc; /* * At this point, we set up the system call arguments. @@ -196,21 +215,21 @@ * passed in *and* out, however. */ - if (fsc.name) { + if (fsc->name) { #if DEBUG - fprintf(stderr, "syscall %s(", fsc.name); + fprintf(stderr, "syscall %s(", fsc->name); #endif - for (i = 0; i < fsc.nargs; i++) { + for (i = 0; i < fsc->nargs; i++) { #if DEBUG fprintf(stderr, "0x%x%s", sc - ? fsc.args[sc->args[i].offset] - : fsc.args[i], - i < (fsc.nargs - 1) ? "," : ""); + ? fsc->args[sc->args[i].offset] + : fsc->args[i], + i < (fsc->nargs - 1) ? "," : ""); #endif if (sc && !(sc->args[i].type & OUT)) { - fsc.s_args[i] = print_arg(&sc->args[i], fsc.args, 0, trussinfo); + fsc->s_args[i] = print_arg(&sc->args[i], fsc->args, 0, trussinfo); } } #if DEBUG @@ -222,23 +241,23 @@ fprintf(trussinfo->outfile, "\n"); #endif - if (fsc.name != NULL && - (!strcmp(fsc.name, "execve") || !strcmp(fsc.name, "exit"))) { + if (fsc->name != NULL && + (!strcmp(fsc->name, "execve") || !strcmp(fsc->name, "exit"))) { /* XXX * This could be done in a more general * manner but it still wouldn't be very pretty. */ - if (!strcmp(fsc.name, "execve")) { + if (!strcmp(fsc->name, "execve")) { if ((trussinfo->flags & EXECVEARGS) == 0) - if (fsc.s_args[1]) { - free(fsc.s_args[1]); - fsc.s_args[1] = NULL; + if (fsc->s_args[1]) { + free(fsc->s_args[1]); + fsc->s_args[1] = NULL; } if ((trussinfo->flags & EXECVEENVS) == 0) - if (fsc.s_args[2]) { - free(fsc.s_args[2]); - fsc.s_args[2] = NULL; + if (fsc->s_args[2]) { + free(fsc->s_args[2]); + fsc->s_args[2] = NULL; } } @@ -262,9 +281,14 @@ int i; int errorp; struct syscall *sc; + struct freebsd_syscall *fsc; - if (fsc.name == NULL) + fsc = trussinfo->curthread->fsc; + if (fsc == NULL || fsc->name == NULL) { + fprintf(trussinfo->outfile, "No syscall?\n"); + fflush(trussinfo->outfile); return (-1); + } cpid = trussinfo->curthread->tid; if (ptrace(PT_GETREGS, cpid, (caddr_t)®s, 0) < 0) @@ -281,10 +305,10 @@ * stand some significant cleaning. */ - sc = fsc.sc; + sc = fsc->sc; if (!sc) { - for (i = 0; i < fsc.nargs; i++) - asprintf(&fsc.s_args[i], "0x%lx", fsc.args[i]); + for (i = 0; i < fsc->nargs; i++) + asprintf(&fsc->s_args[i], "0x%lx", fsc->args[i]); } else { /* * Here, we only look for arguments that have OUT masked in -- @@ -298,10 +322,10 @@ * it may not be valid. */ if (errorp) - asprintf(&temp, "0x%lx", fsc.args[sc->args[i].offset]); + asprintf(&temp, "0x%lx", fsc->args[sc->args[i].offset]); else - temp = print_arg(&sc->args[i], fsc.args, retval, trussinfo); - fsc.s_args[i] = temp; + temp = print_arg(&sc->args[i], fsc->args, retval, trussinfo); + fsc->s_args[i] = temp; } } } @@ -312,15 +336,15 @@ * The nargs check is so we don't have to do yet another strcmp on every * syscall. */ - if (!errorp && fsc.nargs == 0 && fsc.name && strcmp(fsc.name, "pipe") == 0) { - fsc.nargs = 1; - fsc.s_args = malloc((1+fsc.nargs) * sizeof(char*)); - asprintf(&fsc.s_args[0], "[%d,%d]", (int)retval, regs.r_edx); + if (!errorp && fsc->nargs == 0 && fsc->name && strcmp(fsc->name, "pipe") == 0) { + fsc->nargs = 1; + fsc->s_args = malloc((1+fsc->nargs) * sizeof(char*)); + asprintf(&fsc->s_args[0], "[%d,%d]", (int)retval, regs.r_edx); retval = 0; } - if (fsc.name != NULL && - (!strcmp(fsc.name, "execve") || !strcmp(fsc.name, "exit"))) { + if (fsc->name != NULL && + (!strcmp(fsc->name, "execve") || !strcmp(fsc->name, "exit"))) { trussinfo->curthread->in_syscall = 1; } @@ -329,8 +353,8 @@ * but that complicates things considerably. */ - print_syscall_ret(trussinfo, fsc.name, fsc.nargs, fsc.s_args, errorp, retval); - clear_fsc(); + print_syscall_ret(trussinfo, fsc->name, fsc->nargs, fsc->s_args, errorp, retval); + clear_fsc(fsc); return (retval); } Index: setup.c =================================================================== RCS file: /home/ncvs/src/usr.bin/truss/setup.c,v retrieving revision 1.24 diff -u -r1.24 setup.c --- setup.c 26 Jun 2007 22:42:37 -0000 1.24 +++ setup.c 3 Dec 2008 18:49:06 -0000 @@ -166,6 +166,7 @@ np->tid = lwpid; np->in_fork = 0; np->in_syscall = 0; + np->fsc = NULL; SLIST_INSERT_HEAD(&info->threadlist, np, entries); info->curthread = np; } Index: truss.h =================================================================== RCS file: /home/ncvs/src/usr.bin/truss/truss.h,v retrieving revision 1.8 diff -u -r1.8 truss.h --- truss.h 10 Apr 2007 04:03:34 -0000 1.8 +++ truss.h 3 Dec 2008 18:42:54 -0000 @@ -38,6 +38,7 @@ { SLIST_ENTRY(threadinfo) entries; lwpid_t tid; + void *fsc; int in_syscall; int in_fork; }; -- Dan Nelson dnelson@allantgroup.com From dimitry at andric.com Wed Dec 3 11:01:21 2008 From: dimitry at andric.com (Dimitry Andric) Date: Wed Dec 3 11:01:29 2008 Subject: device_attach: acpi_hpet0 attach returned 12 Message-ID: <4936D781.8090907@andric.com> Hi, Apparently there's a HPET on one of my 7.1-ALMOST-STABLE machines, and it's enabled in the BIOS too, but it fails to attach: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Fri Nov 28 16:04:48 CET 2008 dim@vfbsd7.home.andric.com:/usr/obj/usr/src/sys/TENSOR Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: VIA Esther processor 1200MHz (1200.01-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6a9 Stepping = 9 Features=0xa7c9baff Features2=0x181 VIA Padlock Features=0x3fcc real memory = 518914048 (494 MB) avail memory = 498270208 (475 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard padlock0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1ede0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfe800000-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 [...] It looks like the HPET should be at address 0xfe800000-0xfe8003ff, but if I look in the output of "devinfo -rv", I see the following: nexus0 cryptosoft0 padlock0 apic0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x74-0x7f 0x91-0x93 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x400-0x47f 0x4d0-0x4d1 0x500-0x50f 0x800-0x805 I/O memory addresses: 0xf0000-0xfffff 0x1eee0000-0x1eefffff 0xfe800000-0xfe8000ff [...] So apparently the ACPI memory range information says the HPET only uses 256 bytes of iomem, while FreeBSD assumes 1024. The latter is correct, at least according to the Intel HPET spec I dug up somewhere. When I dump ACPI info using acpidump -dt, I see: [...] /* HPET: Length=56, Revision=1, Checksum=196, OEMID=CN700, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31, Creator ID=AWRD, Creator Revision=0x98 HPET Number=0 ADDR=0xfe800000:0[0] (Memory) HW Rev=0x1 Comparitors=2 Counter Size=0 Legacy IRQ routing capable={TRUE} PCI Vendor ID=0x1106 Minimal Tick=144 */ [...] Device (MEM) { Name (_HID, EisaId ("PNP0C01")) Method (_CRS, 0, NotSerialized) { Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadOnly, 0x000F0000, // Address Base 0x00010000, // Address Length ) Memory32Fixed (ReadWrite, 0xFE800000, // Address Base 0x00000100, // Address Length ) [...] Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (ATT3, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadWrite, 0xFE800000, // Address Base 0x00000400, // Address Length ) }) [...] So apparently the devinfo information is gotten from ACPI's "Device (MEM)" declaration, which seems to be inconsistent with the "Device (HPET)" declaration later on. My question is therefore: is this just buggy ACPI information in the BIOS, and can I override it with a custom DSDT file in the boot loader? Or is there some other workaround? From frode at nordahl.net Wed Dec 3 11:36:36 2008 From: frode at nordahl.net (Frode Nordahl) Date: Wed Dec 3 11:36:42 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: <20081203173939.GA2401@deviant.kiev.zoral.com.ua> References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> Message-ID: (moved to freebsd-stable) On 3. des.. 2008, at 18.39, Kostik Belousov wrote: >> db> where >> Tracing pid 41111 tid 100199 td 0xffffff0056f1f370 >> kdb_enter_why() at kdb_enter_why+0x3d >> panic() at panic+0x17b >> dqget() at dqget+0xaa4 >> getinoquota() at getinoquota+0x5b >> ufs_access() at ufs_access+0x28c >> ufs_lookup() at ufs_lookup+0x9fe >> vfs_cache_lookup() at vfs_cache_lookup+0xf8 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 >> lookup() at lookup+0x531 >> namei() at namei+0x35d >> kern_rmdir() at kern_rmdir+0xbd >> syscall() at syscall+0x256 >> Xfast_syscall() at Xfast_syscall+0xab > > For the start, I want to see the content of the *dq in the dqget() > frame. I am unable to get to *dq :-( (kgdb) frame 10 #10 0xffffffff806dbc54 in dqget (vp=0xffffff011e0767e0, id=419444, ump=0xffffff00038a9000, type=0, dqp=0xffffff0122e47268) at /usr/src/sys/ufs/ufs/ufs_quota.c:1210 1210 panic("dqget: free dquot isn't"); (kgdb) print dq Variable "dq" is not available. I will try to provoke the panic again and see if I can get more info from DDB. (Any hints as to what to ask ddb to get the information you requested?) (I'll put my kernel.debug and vmcore.0 in an archve somewhere and mail you the URL privately if you are up to download 126MB) -- Frode Nordahl From kostikbel at gmail.com Wed Dec 3 11:43:54 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Dec 3 11:44:01 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> Message-ID: <20081203194348.GB2401@deviant.kiev.zoral.com.ua> On Wed, Dec 03, 2008 at 08:12:22PM +0100, Frode Nordahl wrote: > (moved to freebsd-stable) > > On 3. des.. 2008, at 18.39, Kostik Belousov wrote: > > >>db> where > >>Tracing pid 41111 tid 100199 td 0xffffff0056f1f370 > >>kdb_enter_why() at kdb_enter_why+0x3d > >>panic() at panic+0x17b > >>dqget() at dqget+0xaa4 > >>getinoquota() at getinoquota+0x5b > >>ufs_access() at ufs_access+0x28c > >>ufs_lookup() at ufs_lookup+0x9fe > >>vfs_cache_lookup() at vfs_cache_lookup+0xf8 > >>VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 > >>lookup() at lookup+0x531 > >>namei() at namei+0x35d > >>kern_rmdir() at kern_rmdir+0xbd > >>syscall() at syscall+0x256 > >>Xfast_syscall() at Xfast_syscall+0xab > > > >For the start, I want to see the content of the *dq in the dqget() > >frame. > > > I am unable to get to *dq :-( > > (kgdb) frame 10 > #10 0xffffffff806dbc54 in dqget (vp=0xffffff011e0767e0, id=419444, > ump=0xffffff00038a9000, type=0, dqp=0xffffff0122e47268) > at /usr/src/sys/ufs/ufs/ufs_quota.c:1210 > 1210 panic("dqget: free dquot isn't"); If this is repeatable, change panic to panic("dqget: free dquot isn't %p", dq); and then in kgdb p/x *(struct dquot *) > (kgdb) print dq > Variable "dq" is not available. > > I will try to provoke the panic again and see if I can get more info > from DDB. (Any hints as to what to ask ddb to get the information you > requested?) > > (I'll put my kernel.debug and vmcore.0 in an archve somewhere and mail > you the URL privately if you are up to download 126MB) > > -- > Frode Nordahl > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081203/0437b35a/attachment.pgp From dudu at dudu.ro Wed Dec 3 11:48:11 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Dec 3 11:48:17 2008 Subject: Weird truss output In-Reply-To: <20081203185622.GF22076@dan.emsphone.com> References: <20081203152330.GD22076@dan.emsphone.com> <20081203170857.GE22076@dan.emsphone.com> <20081203185622.GF22076@dan.emsphone.com> Message-ID: On Wed, Dec 3, 2008 at 8:56 PM, Dan Nelson wrote: [...] Am I doing something wrong? I've applied the full diff, rebuilt truss, now I get this: -- cut here -- root@goofy / # truss -p 52731 SIGNAL 17 (SIGSTOP) -- UNKNOWN SYSCALL 1048535 -- -- UNKNOWN SYSCALL 1048496 -- -- UNKNOWN SYSCALL 1048559 -- -- UNKNOWN SYSCALL 1048559 -- -- UNKNOWN SYSCALL -8464 -- -- UNKNOWN SYSCALL -8464 -- -- UNKNOWN SYSCALL 527 -- -- UNKNOWN SYSCALL 527 -- /100084: read(1074283119,"\M-|\M^WP\^A",7356800) = 4 (0x4) -- UNKNOWN SYSCALL 527 -- -- UNKNOWN SYSCALL 7385248 -- -- and here -- Perhaps I should mention that I block all signals from all threads, except for one, where I do all the handling/cleanup. -- ~/.signature: no such file or directory From fernan at iib.unsam.edu.ar Wed Dec 3 12:18:15 2008 From: fernan at iib.unsam.edu.ar (Fernan Aguero) Date: Wed Dec 3 12:18:24 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <20081029170522.GH47829@iib.unsam.edu.ar> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200810011134.49795.jhb@freebsd.org> <48EBDE69.1030609@delphij.net> <200810271251.28411.kirk@strauser.com> <20081029170522.GH47829@iib.unsam.edu.ar> Message-ID: <20081203201735.GJ59053@iib.unsam.edu.ar> +----[ To Kirk Strauser (29.Oct.2008 14:05): | | > On Tuesday 07 October 2008 17:10:49 Xin LI wrote: | > > Did anyone who can trigger the data corruption has tried John's patch | > > and let us know if it worked? | > > | > > Cheers, | > | > I can confirm that it works on my PowerEdge SC1435. With both controllers | > running in SATA150 mode, I have an uptime of 101 days with moderately heavy | > load. | > -- | > Kirk Strauser | | Same here. The ata_ht1000.patch referenced in this thread | works, in my case at least with 1 controller running in | SATA150 mode (I have only 1 disk). | | However, the recent 7.1-BETA2 does not work for me, contrary | to reports saying that this BETA contains the patch. Looking | at the sources, it seems evident that the patch applied is | not identical to the ata_ht1000.patch in this thread. | | This patch: | http://people.freebsd.org/~jhb/patches/ata_ht1000.patch | is the only requirement to turn a broken 7.1-BETA1 into a | working 7.1 for a Dell PowerEdge SC1435. | | The recent 7.1-BETA2, does not work! | | Fernan | +----] Hi, I've been tracking the 7.1 release page but so far I haven't seen any update lately ... any news on when a new BETA/RC will be out for testing? Fernan From dgeo at ec-marseille.fr Wed Dec 3 13:23:29 2008 From: dgeo at ec-marseille.fr (geoffroy desvernay) Date: Wed Dec 3 13:23:38 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4935D67E.4070204@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> Message-ID: <4936F8C4.6090006@ec-marseille.fr> Xin LI a ?crit : > Hi guys, > > I think I got a real fix. > It seems to "work for me?" too Server under normal charge (smtp/imap/Maildir for ~1000 users, NFS filer), everything seems ok... (1h uptime for now) Thank you ! -- geoffroy desvernay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081203/2fd06398/signature.pgp From kensmith at cse.Buffalo.EDU Wed Dec 3 13:55:10 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Wed Dec 3 13:55:19 2008 Subject: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? In-Reply-To: <20081203201735.GJ59053@iib.unsam.edu.ar> References: <520894aa0809301434h68b94628x54ec08fd48785feb@mail.gmail.com> <200810011134.49795.jhb@freebsd.org> <48EBDE69.1030609@delphij.net> <200810271251.28411.kirk@strauser.com> <20081029170522.GH47829@iib.unsam.edu.ar> <20081203201735.GJ59053@iib.unsam.edu.ar> Message-ID: <1228341282.23618.3.camel@neo.cse.buffalo.edu> On Wed, 2008-12-03 at 17:17 -0300, Fernan Aguero wrote: > I've been tracking the 7.1 release page but so far I haven't > seen any update lately ... any news on when a new BETA/RC > will be out for testing? A couple of days. Problems with an interface that was added after 7.0 were found. Since a release hasn't been done with that interface its being fixed so we can avoid needing to provide some ugly compatibility goo down the road. The code is in head now, hopefully it can be moved into stable/7 and releng/7.1 within the next day or two. Between 7.1-BETA2 and now we've had two show-stoppers that have been addressed and one security advisory that we needed to hold for, followed by this nit that's being worked on now. Hopefully that's the last big nit. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081203/fcf2f45a/attachment.pgp From josh.carroll at gmail.com Wed Dec 3 14:53:46 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Wed Dec 3 14:53:53 2008 Subject: ext2 inode size patch - RE: PR kern/124621 In-Reply-To: <20081125150342.GL2042@deviant.kiev.zoral.com.ua> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125140601.GH2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250617q5fffb41exe20dfb8314fc4a9d@mail.gmail.com> <20081125142827.GI2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250657q6fdf08b0x1e94f35fd0a7ed4f@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> Message-ID: <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> > Ok, I describe my concern once more. I do not object against the checking > of the inode size. But, if inode size is changed, then some data is added > to the inode, that could (and usually does, otherwise why extend it ?) > change intrerpetation of the inode. Thus, we need a verification of the > fact that simply ignoring added fields does not damage filesystem or > cause user data corruption. Verification != testing. Let me take another crack at explaining why I think this patch is not dangerous. The inode size is determined by reading the following member: __u16 s_inode_size; of the ext2_super_block structure. I took a look at the Linux 2.6.27.7 kernel source, and indeed they do something very similar if not the same: #define EXT2_INODE_SIZE(s) (EXT2_SB(s)->s_inode_size) If you compare to what I did: #define EXT2_INODE_SIZE(s) ((s)->u.ext2_sb.s_inode_size) This is really the same thing, since EXT2_SB is defined (in the Linux kernel src as): #ifdef __KERNEL__ #include static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb) { return sb->s_fs_info; } And struct ext2_sb_info has the following member: int s_inode_size; Essentially, the changes I made simply query the existing information from the filesystem, which is what the Linux kernel does as well. The inode size, blocks per group, etc are all defined at filesystem creation time by mke2fs and it ensures the sanity of the relationship between the inodes/blocks/block groups. The first diagram here: http://sunsite.nus.sg/LDP/LDP/tlk/node95.html Makes it clear that as long as the number of inodes per block and the blocks per group is is sane during fs creation, looking up the inode size as my patch does is fine, since the creation of the filesystem is ensures a correct by construction situation. We're simply reading the size of the inode based on the filesystem. I hope this is sufficient to convince some further thought about committing this. For those interested in the relevant Linux kernel source, you can have a look at line 105 of include/linux/ext2_fs.h from the linux-2.6.27.7 kernel source. Thanks, Josh From dnelson at allantgroup.com Wed Dec 3 14:55:45 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Dec 3 14:55:53 2008 Subject: Weird truss output In-Reply-To: References: <20081203152330.GD22076@dan.emsphone.com> <20081203170857.GE22076@dan.emsphone.com> <20081203185622.GF22076@dan.emsphone.com> Message-ID: <20081203225542.GG22076@dan.emsphone.com> In the last episode (Dec 03), Vlad GALU said: > On Wed, Dec 3, 2008 at 8:56 PM, Dan Nelson wrote: > [...] > > Am I doing something wrong? I've applied the full diff, rebuilt > truss, now I get this: > -- cut here -- > root@goofy / # truss -p 52731 > SIGNAL 17 (SIGSTOP) > > -- UNKNOWN SYSCALL 1048535 -- > -- UNKNOWN SYSCALL 1048496 -- > -- UNKNOWN SYSCALL 1048559 -- > -- UNKNOWN SYSCALL 1048559 -- > -- UNKNOWN SYSCALL -8464 -- > -- UNKNOWN SYSCALL -8464 -- > -- UNKNOWN SYSCALL 527 -- > -- UNKNOWN SYSCALL 527 -- > /100084: read(1074283119,"\M-|\M^WP\^A",7356800) = 4 (0x4) > -- UNKNOWN SYSCALL 527 -- > -- UNKNOWN SYSCALL 7385248 -- > -- and here -- > > Perhaps I should mention that I block all signals from all threads, > except for one, where I do all the handling/cleanup. So you're back to your original behaviour basically? Not sure what's wrong; it all works great on my machine... Are you on a 64-bit system? I only have a Pentium-III here, so the big patch isn't guaranteed to work on anything except i386. The little patch inlined in my previous email is for i386-fbsd.c, but you should be able to make similar changes to amd64-fbsd.c (most of the diff just replaces "fsc." with "fsc->" ). -- Dan Nelson dnelson@allantgroup.com From frode at nordahl.net Wed Dec 3 23:12:48 2008 From: frode at nordahl.net (Frode Nordahl) Date: Wed Dec 3 23:12:55 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: <20081203194348.GB2401@deviant.kiev.zoral.com.ua> References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> <20081203194348.GB2401@deviant.kiev.zoral.com.ua> Message-ID: <8A6A8FA5-07A6-4A12-B9AD-6E77E534CED7@nordahl.net> On 3. des.. 2008, at 20.43, Kostik Belousov wrote: > On Wed, Dec 03, 2008 at 08:12:22PM +0100, Frode Nordahl wrote: >> (moved to freebsd-stable) >> >> On 3. des.. 2008, at 18.39, Kostik Belousov wrote: >> >>>> db> where >>>> Tracing pid 41111 tid 100199 td 0xffffff0056f1f370 >>>> kdb_enter_why() at kdb_enter_why+0x3d >>>> panic() at panic+0x17b >>>> dqget() at dqget+0xaa4 >>>> getinoquota() at getinoquota+0x5b >>>> ufs_access() at ufs_access+0x28c >>>> ufs_lookup() at ufs_lookup+0x9fe >>>> vfs_cache_lookup() at vfs_cache_lookup+0xf8 >>>> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 >>>> lookup() at lookup+0x531 >>>> namei() at namei+0x35d >>>> kern_rmdir() at kern_rmdir+0xbd >>>> syscall() at syscall+0x256 >>>> Xfast_syscall() at Xfast_syscall+0xab >>> >>> For the start, I want to see the content of the *dq in the dqget() >>> frame. >> >> >> I am unable to get to *dq :-( >> >> (kgdb) frame 10 >> #10 0xffffffff806dbc54 in dqget (vp=0xffffff011e0767e0, id=419444, >> ump=0xffffff00038a9000, type=0, dqp=0xffffff0122e47268) >> at /usr/src/sys/ufs/ufs/ufs_quota.c:1210 >> 1210 panic("dqget: free dquot isn't"); > If this is repeatable, change panic to > panic("dqget: free dquot isn't %p", dq); > > and then in kgdb p/x *(struct dquot *) Got it! panic: dqget: free dquot isn't dq=0xffffff00b3d27000 (kgdb) p/x *(struct dquot *)0xffffff00b3d27000 $1 = {dq_hash = {le_next = 0x0, le_prev = 0xffffff010b9da700}, dq_freelist = { tqe_next = 0xffffff0055e2de00, tqe_prev = 0xffffffff80b03710}, dq_lock = { lock_object = {lo_name = 0xffffffff8088c21c, lo_type = 0xffffffff8088c21c, lo_flags = 0x1030000, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 0x4, mtx_recurse = 0x0}, dq_flags = 0xc, dq_type = 0x0, dq_cnt = 0x0, dq_id = 0x16a37d, dq_ump = 0xffffff00038e1600, dq_dqb = {dqb_bhardlimit = 0x0, dqb_bsoftlimit = 0x0, dqb_curblocks = 0x0, dqb_ihardlimit = 0x0, dqb_isoftlimit = 0x0, dqb_curinodes = 0x1, dqb_btime = 0x493ef2b5, dqb_itime = 0x493ef2b5}} Let me know if I can provide any more information! Updated the crashinfo archive you got an URL to yesterday if you want to poke around yourself. -- Frode Nordahl From bms at FreeBSD.org Wed Dec 3 23:31:04 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Dec 3 23:31:16 2008 Subject: ext2 inode size patch - RE: PR kern/124621 In-Reply-To: <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125140601.GH2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250617q5fffb41exe20dfb8314fc4a9d@mail.gmail.com> <20081125142827.GI2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250657q6fdf08b0x1e94f35fd0a7ed4f@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> Message-ID: <49378379.5050900@FreeBSD.org> Hi, The inode size for the ext3 filesystem which Gentoo created for my last install defaulted to 256 bytes, so I got bit by this problem. I can't speak for the write path. but the read path looks just fine to me, and the patch should go in ASAP. Josh Carroll wrote: >> Ok, I describe my concern once more. I do not object against the checking >> of the inode size. But, if inode size is changed, then some data is added >> to the inode, that could (and usually does, otherwise why extend it ?) >> change intrerpetation of the inode. Thus, we need a verification of the >> fact that simply ignoring added fields does not damage filesystem or >> cause user data corruption. Verification != testing. >> If folk are paranoid, then add a check for dynamic inode size and disable ext2fs writes by downgrading the mount in that case (We can do that, right? Can someone make sure Josh gets the help he needs here?) As Josh points out, the ext2 inode size is stored in the superblock. Whilst it may vary between ext2 filesystems, *the inode size itself does not appear to be something which one can modify in an existing ext2/3 filesystem*. Older ext2 filesystems may not contain the inode size field in the superblock, and the patch appears to default to 128 for that case. The double indirection thus introduced doesn't concern me, our ext2fs is not performance critical code, and the superblock is likely to sit in L2/L3 cache anyway (note: content free argument). Thanks to Josh for fixing this problem. cheers BMS From dudu at dudu.ro Thu Dec 4 00:29:15 2008 From: dudu at dudu.ro (Vlad GALU) Date: Thu Dec 4 00:29:21 2008 Subject: Weird truss output In-Reply-To: <20081203225542.GG22076@dan.emsphone.com> References: <20081203152330.GD22076@dan.emsphone.com> <20081203170857.GE22076@dan.emsphone.com> <20081203185622.GF22076@dan.emsphone.com> <20081203225542.GG22076@dan.emsphone.com> Message-ID: On Thu, Dec 4, 2008 at 12:55 AM, Dan Nelson wrote: > In the last episode (Dec 03), Vlad GALU said: >> On Wed, Dec 3, 2008 at 8:56 PM, Dan Nelson wrote: >> [...] >> >> Am I doing something wrong? I've applied the full diff, rebuilt >> truss, now I get this: >> -- cut here -- >> root@goofy / # truss -p 52731 >> SIGNAL 17 (SIGSTOP) >> >> -- UNKNOWN SYSCALL 1048535 -- >> -- UNKNOWN SYSCALL 1048496 -- >> -- UNKNOWN SYSCALL 1048559 -- >> -- UNKNOWN SYSCALL 1048559 -- >> -- UNKNOWN SYSCALL -8464 -- >> -- UNKNOWN SYSCALL -8464 -- >> -- UNKNOWN SYSCALL 527 -- >> -- UNKNOWN SYSCALL 527 -- >> /100084: read(1074283119,"\M-|\M^WP\^A",7356800) = 4 (0x4) >> -- UNKNOWN SYSCALL 527 -- >> -- UNKNOWN SYSCALL 7385248 -- >> -- and here -- >> >> Perhaps I should mention that I block all signals from all threads, >> except for one, where I do all the handling/cleanup. > > So you're back to your original behaviour basically? Not sure what's > wrong; it all works great on my machine... Are you on a 64-bit system? > I only have a Pentium-III here, so the big patch isn't guaranteed to > work on anything except i386. The little patch inlined in my previous > email is for i386-fbsd.c, but you should be able to make similar > changes to amd64-fbsd.c (most of the diff just replaces "fsc." with > "fsc->" ). > Duh, I'm dumb, I didn't take a moment to check whether there was a 64-bit specific implementation. My initial thought was that the "i386" in the i386-fbsd.c referred to the CPU arch :) I'll try patching the other file today and get back with the results. And next time I'll make sure I've had my daily coffee before posting to the list :) > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- ~/.signature: no such file or directory From mail25 at bzerk.org Thu Dec 4 01:09:06 2008 From: mail25 at bzerk.org (Ruben de Groot) Date: Thu Dec 4 01:09:13 2008 Subject: sysinstall automatic partition labelling/sizing problem In-Reply-To: <49362A3C.7060204@fusiongol.com> References: <49362A3C.7060204@fusiongol.com> Message-ID: <20081204090859.GA16512@ei.bzerk.org> /boot/kernel is ~118 MB on my system (including debugging symbols). Default size of the root partition created by sysinstall is 512 MB, in your case downsized to 360 to accomodate other partitions on your 8GB disk. Should still be enough though. Do you have any other big files hanging around in your root partition? Ruben On Wed, Dec 03, 2008 at 03:42:04PM +0900, Nathan Butcher typed: > Automatic labelling on 7.0 created about 360MB for my root partition on > a 8GB disk. After a buildkernel into 7.1-PRERELEASE, the root partition > was exhausted during the installkernel. > > Maybe automatic labelling in sysinstall needs to allocate more than > 360MB in the root (/) partition if it's going to stay big enough to > accomodate a buildkernel and installkernel from source. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From peter at simons-rock.edu Thu Dec 4 01:24:08 2008 From: peter at simons-rock.edu (Peter C. Lai) Date: Thu Dec 4 01:24:16 2008 Subject: sysinstall automatic partition labelling/sizing problem In-Reply-To: <1660_1228381770_49379E4A_1660_278_1_20081204090859.GA16512@ei.bzerk.org> References: <49362A3C.7060204@fusiongol.com> <1660_1228381770_49379E4A_1660_278_1_20081204090859.GA16512@ei.bzerk.org> Message-ID: <20081204092024.GW27780@cesium.hyperfine.info> Might be helpful to remember that /root is on /, so if you're in the habit of leaving stuff in /root for doing sysadmin tasks, it can kill / pretty quickly... On 2008-12-04 10:08:59AM +0100, Ruben de Groot wrote: > > /boot/kernel is ~118 MB on my system (including debugging symbols). > Default size of the root partition created by sysinstall is 512 MB, in your > case downsized to 360 to accomodate other partitions on your 8GB disk. > Should still be enough though. Do you have any other big files hanging > around in your root partition? > > Ruben > > On Wed, Dec 03, 2008 at 03:42:04PM +0900, Nathan Butcher typed: > > Automatic labelling on 7.0 created about 360MB for my root partition on > > a 8GB disk. After a buildkernel into 7.1-PRERELEASE, the root partition > > was exhausted during the installkernel. > > > > Maybe automatic labelling in sysinstall needs to allocate more than > > 360MB in the root (/) partition if it's going to stay big enough to > > accomodate a buildkernel and installkernel from source. > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From admin at kkip.pl Thu Dec 4 01:48:57 2008 From: admin at kkip.pl (Bartosz Stec) Date: Thu Dec 4 01:49:06 2008 Subject: Burning DVD with files>4GB from console Message-ID: <4937A786.9080403@kkip.pl> My backup script split filesystem dumps to files with size of 4,37 GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At this moment I have to burn them from windows via smb-link becuase I didn't manage to do this task from FreeBSD console due to 2GB/4GB filesize restrictions (growisofs). I'm using freeware CDBurnerXP to burn my backups (ISO9660/UDF/Joliet), and they mount without problems on my FreeBSD BOX, files are fully readable too. However, burning gigabytes of data via slow (about 3.5MB/s) SMB network is just annoing. Is there *any* way to burn DVDs with files>4GB from FreeBSD console? cheers! -- Bartosz Stec From avg at icyb.net.ua Thu Dec 4 02:31:53 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Dec 4 02:32:09 2008 Subject: rc.firewall: default loopback rules are set up even for custom file Message-ID: <4937B194.1020606@icyb.net.ua> I've just realized that I see in releng/7 something that I did not see in releng/6 - even if I use a file with custom rules in firewall_type I still get default loopback rules installed. I think that this is not correct, I am using custom rules exactly because I want to control *everything* (e.g. all deny rules come with log logamount xxx). -- Andriy Gapon From gandalf at shopzeus.com Thu Dec 4 02:50:30 2008 From: gandalf at shopzeus.com (Laszlo Nagy) Date: Thu Dec 4 02:50:37 2008 Subject: Kernel panic, Trap 12, page fault while in kernel mode and freeing free frag on 7.0 p5 amd64 Message-ID: <4937B23A.5060507@shopzeus.com> We have a production server which keeps crashing. Hardware: two Quad Core Xeons (5420), 8GB ECC ram, Intel S5000 motherboard, Areca 1680-ix12 RAID card. The memory have been replaced three times. Memtest runs OK. The motherboard was replaced, all firmwares updated to the latest version (last time an Intel engineer did this for us.) Machine is running postgresql, postfix, apache, mod_php, dovecot. Kernel was compiled with debug symbols. Machine configuration can be found here: http://195.228.74.135/info Core dumps are here (not all of them): http://195.228.74.135/crash In most cases, the error message is "page fault" but there is also a "freeing free frag". When there is no big load (weekends) then it runs for two or three days. It crashes only when there is bigger load on the server. On very busy days, it can crash three times a day. I have installed exactly the same software on a desktop computer with amd X2 BE2350 processor and 3GB non-ecc RAM, and it ran for 6 days without crashing. (Unfortunately, I cannot use that computer in production because it is incredibly slow...) I have found some other posts about a similar problem, but that issue was closed. Unfortunately, I'm not familiar with kernel debugging. Is this the right place to ask for help? Thanks, Laszlo From kostikbel at gmail.com Thu Dec 4 02:51:34 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Dec 4 02:52:05 2008 Subject: ext2 inode size patch - RE: PR kern/124621 In-Reply-To: <49378379.5050900@FreeBSD.org> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125140601.GH2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250617q5fffb41exe20dfb8314fc4a9d@mail.gmail.com> <20081125142827.GI2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250657q6fdf08b0x1e94f35fd0a7ed4f@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <49378379.5050900@FreeBSD.org> Message-ID: <20081204105129.GA2246@deviant.kiev.zoral.com.ua> On Thu, Dec 04, 2008 at 07:15:05AM +0000, Bruce M. Simpson wrote: > Hi, > > The inode size for the ext3 filesystem which Gentoo created for my last > install defaulted to 256 bytes, so I got bit by this problem. > > I can't speak for the write path. but the read path looks just fine to > me, and the patch should go in ASAP. > > Josh Carroll wrote: > >>Ok, I describe my concern once more. I do not object against the checking > >>of the inode size. But, if inode size is changed, then some data is added > >>to the inode, that could (and usually does, otherwise why extend it ?) > >>change intrerpetation of the inode. Thus, we need a verification of the > >>fact that simply ignoring added fields does not damage filesystem or > >>cause user data corruption. Verification != testing. > >> > > If folk are paranoid, then add a check for dynamic inode size and > disable ext2fs writes by downgrading the mount in that case (We can do > that, right? Can someone make sure Josh gets the help he needs here?) > > As Josh points out, the ext2 inode size is stored in the superblock. > Whilst it may vary between ext2 filesystems, *the inode size itself does > not appear to be something which one can modify in an existing ext2/3 > filesystem*. > > Older ext2 filesystems may not contain the inode size field in the > superblock, and the patch appears to default to 128 for that case. The > double indirection thus introduced doesn't concern me, our ext2fs is not > performance critical code, and the superblock is likely to sit in L2/L3 > cache anyway (note: content free argument). > > Thanks to Josh for fixing this problem. Bruce, feel free to commit the patch. I do not want to spend time on ext2 in any form, and due to our (only partly jokingly) rule of the "last committer is the owner", I do not want to analyze ext2 bug reports after. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081204/61a1b7d2/attachment-0001.pgp From kostikbel at gmail.com Thu Dec 4 04:07:42 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Dec 4 04:07:49 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: <8A6A8FA5-07A6-4A12-B9AD-6E77E534CED7@nordahl.net> References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> <20081203194348.GB2401@deviant.kiev.zoral.com.ua> <8A6A8FA5-07A6-4A12-B9AD-6E77E534CED7@nordahl.net> Message-ID: <20081204120736.GC2038@deviant.kiev.zoral.com.ua> On Thu, Dec 04, 2008 at 08:12:45AM +0100, Frode Nordahl wrote: > On 3. des.. 2008, at 20.43, Kostik Belousov wrote: > > >On Wed, Dec 03, 2008 at 08:12:22PM +0100, Frode Nordahl wrote: > >>(moved to freebsd-stable) > >> > >>On 3. des.. 2008, at 18.39, Kostik Belousov wrote: > >> > >>>>db> where > >>>>Tracing pid 41111 tid 100199 td 0xffffff0056f1f370 > >>>>kdb_enter_why() at kdb_enter_why+0x3d > >>>>panic() at panic+0x17b > >>>>dqget() at dqget+0xaa4 > >>>>getinoquota() at getinoquota+0x5b > >>>>ufs_access() at ufs_access+0x28c > >>>>ufs_lookup() at ufs_lookup+0x9fe > >>>>vfs_cache_lookup() at vfs_cache_lookup+0xf8 > >>>>VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 > >>>>lookup() at lookup+0x531 > >>>>namei() at namei+0x35d > >>>>kern_rmdir() at kern_rmdir+0xbd > >>>>syscall() at syscall+0x256 > >>>>Xfast_syscall() at Xfast_syscall+0xab > >>> > >>>For the start, I want to see the content of the *dq in the dqget() > >>>frame. > >> > >> > >>I am unable to get to *dq :-( > >> > >>(kgdb) frame 10 > >>#10 0xffffffff806dbc54 in dqget (vp=0xffffff011e0767e0, id=419444, > >> ump=0xffffff00038a9000, type=0, dqp=0xffffff0122e47268) > >> at /usr/src/sys/ufs/ufs/ufs_quota.c:1210 > >>1210 panic("dqget: free dquot isn't"); > >If this is repeatable, change panic to > > panic("dqget: free dquot isn't %p", dq); > > > >and then in kgdb p/x *(struct dquot *) > > Got it! > > panic: dqget: free dquot isn't dq=0xffffff00b3d27000 > (kgdb) p/x *(struct dquot *)0xffffff00b3d27000 > $1 = {dq_hash = {le_next = 0x0, le_prev = 0xffffff010b9da700}, > dq_freelist = { > tqe_next = 0xffffff0055e2de00, tqe_prev = 0xffffffff80b03710}, > dq_lock = { > lock_object = {lo_name = 0xffffffff8088c21c, lo_type = > 0xffffffff8088c21c, > lo_flags = 0x1030000, lo_witness_data = {lod_list = {stqe_next > = 0x0}, > lod_witness = 0x0}}, mtx_lock = 0x4, mtx_recurse = 0x0}, > dq_flags = 0xc, dq_type = 0x0, dq_cnt = 0x0, dq_id = 0x16a37d, > dq_ump = 0xffffff00038e1600, dq_dqb = {dqb_bhardlimit = 0x0, > dqb_bsoftlimit = 0x0, dqb_curblocks = 0x0, dqb_ihardlimit = 0x0, > dqb_isoftlimit = 0x0, dqb_curinodes = 0x1, dqb_btime = 0x493ef2b5, > dqb_itime = 0x493ef2b5}} > > Let me know if I can provide any more information! > > Updated the crashinfo archive you got an URL to yesterday if you want > to poke around yourself. Please, try the patch below, it should fix a race I see. Quite possible, this is what you tripped over. On the other hand, dq_id == 1483645 looks very suspicious. Do you actually have such large uid in the system ? Could it be that you have file on fs owned by such uid ? diff --git a/sys/ufs/ufs/ufs_quota.c b/sys/ufs/ufs/ufs_quota.c index e5cb956..0c8209a 100644 --- a/sys/ufs/ufs/ufs_quota.c +++ b/sys/ufs/ufs/ufs_quota.c @@ -1262,7 +1262,7 @@ dqrele(struct vnode *vp, struct dquot *dq) return; } DQH_UNLOCK(); - +sync: (void) dqsync(vp, dq); DQH_LOCK(); @@ -1271,6 +1271,18 @@ dqrele(struct vnode *vp, struct dquot *dq) DQH_UNLOCK(); return; } + + /* + * The dq may become dirty after it is synced but before it is + * put to the free list. Checking the DQ_MOD there without + * locking dq should be safe since no other references to the + * dq exist. + */ + if ((dq->dq_flags & DQ_MOD) != 0) { + dq->dq_cnt++; + DQH_UNLOCK(); + goto sync; + } TAILQ_INSERT_TAIL(&dqfreelist, dq, dq_freelist); DQH_UNLOCK(); } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081204/f1ef145d/attachment.pgp From frode at nordahl.net Thu Dec 4 04:20:38 2008 From: frode at nordahl.net (Frode Nordahl) Date: Thu Dec 4 04:20:46 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: <20081204120736.GC2038@deviant.kiev.zoral.com.ua> References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> <20081203194348.GB2401@deviant.kiev.zoral.com.ua> <8A6A8FA5-07A6-4A12-B9AD-6E77E534CED7@nordahl.net> <20081204120736.GC2038@deviant.kiev.zoral.com.ua> Message-ID: <576BB990-78D8-4CE8-9660-55EB989EE3BA@nordahl.net> On 4. des.. 2008, at 13.07, Kostik Belousov wrote: > On Thu, Dec 04, 2008 at 08:12:45AM +0100, Frode Nordahl wrote: >> Got it! >> >> panic: dqget: free dquot isn't dq=0xffffff00b3d27000 >> (kgdb) p/x *(struct dquot *)0xffffff00b3d27000 >> $1 = {dq_hash = {le_next = 0x0, le_prev = 0xffffff010b9da700}, >> dq_freelist = { >> tqe_next = 0xffffff0055e2de00, tqe_prev = 0xffffffff80b03710}, >> dq_lock = { >> lock_object = {lo_name = 0xffffffff8088c21c, lo_type = >> 0xffffffff8088c21c, >> lo_flags = 0x1030000, lo_witness_data = {lod_list = {stqe_next >> = 0x0}, >> lod_witness = 0x0}}, mtx_lock = 0x4, mtx_recurse = 0x0}, >> dq_flags = 0xc, dq_type = 0x0, dq_cnt = 0x0, dq_id = 0x16a37d, >> dq_ump = 0xffffff00038e1600, dq_dqb = {dqb_bhardlimit = 0x0, >> dqb_bsoftlimit = 0x0, dqb_curblocks = 0x0, dqb_ihardlimit = 0x0, >> dqb_isoftlimit = 0x0, dqb_curinodes = 0x1, dqb_btime = 0x493ef2b5, >> dqb_itime = 0x493ef2b5}} >> >> Let me know if I can provide any more information! >> >> Updated the crashinfo archive you got an URL to yesterday if you want >> to poke around yourself. > > Please, try the patch below, it should fix a race I see. Quite > possible, > this is what you tripped over. Thanks! I will apply the patch and retry the steps that lead to the panic! > On the other hand, dq_id == 1483645 looks very suspicious. Do you > actually have such large uid in the system ? Could it be that you have > file on fs owned by such uid ? Yes. The system has uids ranging from 0 to 3152039 :-) -- Frode Nordahl From cyb. at gmx.net Thu Dec 4 04:36:25 2008 From: cyb. at gmx.net (Andreas Rudisch) Date: Thu Dec 4 04:36:32 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <4937A786.9080403@kkip.pl> References: <4937A786.9080403@kkip.pl> Message-ID: <20081204130940.b8a4acf8.cyb.@gmx.net> On Thu, 04 Dec 2008 10:48:54 +0100 Bartosz Stec wrote: > My backup script split filesystem dumps to files with size of 4,37 GB (4 > 588 544 kB). It's just an optimal size to fill out DVDs. At this moment > I have to burn them from windows via smb-link becuase I didn't manage to > do this task from FreeBSD console due to 2GB/4GB filesize restrictions > (growisofs). I'm using freeware CDBurnerXP to burn my backups > (ISO9660/UDF/Joliet), and they mount without problems on my FreeBSD BOX, > files are fully readable too. However, burning gigabytes of data via > slow (about 3.5MB/s) SMB network is just annoing. Is there *any* way to > burn DVDs with files>4GB from FreeBSD console? As a work around you could simply tell your backup script to spilt the data at about 1GB and burn 4 files to one DVD. Andreas -- GnuPG key : 0x2A573565 | http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081204/dd8832aa/attachment.pgp From admin at kkip.pl Thu Dec 4 04:52:01 2008 From: admin at kkip.pl (Bartosz Stec) Date: Thu Dec 4 04:52:09 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <4937CBBC.1020406@smo.de> References: <4937A786.9080403@kkip.pl> <4937CBBC.1020406@smo.de> Message-ID: <4937D26D.60408@kkip.pl> Philipp Ost pisze: > Hi, > > Bartosz Stec wrote: >> [...] Is there *any* way to burn DVDs with files>4GB from FreeBSD >> console? > > I succesfully used growisofs for exactly this task ;-) > > What I did is (for DL-DVDs): > # growisofs -dvd-compat -Z /dev/cd0=$file.iso -speed=2 > > I had to limit the speed, else it wouldn't do anything. If I burn > "normal" DVDs I don't need the speed limit. > > HTH, > Philipp But doesn't that command expecting file.iso being already premastered ISO image? OK, that's *some* way, but to be clear - I want to avoid preparing ISO images too ;) -- Bartosz Stec From bms at FreeBSD.org Thu Dec 4 05:16:19 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Dec 4 05:16:25 2008 Subject: ext2 inode size patch - RE: PR kern/124621 In-Reply-To: <20081204105129.GA2246@deviant.kiev.zoral.com.ua> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125140601.GH2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250617q5fffb41exe20dfb8314fc4a9d@mail.gmail.com> <20081125142827.GI2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250657q6fdf08b0x1e94f35fd0a7ed4f@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <49378379.5050900@FreeBSD.org> <20081204105129.GA2246@deviant.kiev.zoral.com.ua> Message-ID: <4937D820.8080803@FreeBSD.org> Kostik Belousov wrote: > ... > Bruce, feel free to commit the patch. > > I do not want to spend time on ext2 in any form, and due to our (only > partly jokingly) rule of the "last committer is the owner", I do not > want to analyze ext2 bug reports after. > Yes, development resource is limited here too, and any involvement on my part here DOES NOT constitute any commitment, express or implied, to maintaining the ext2fs module beyond the change being considered right now. I find that this often has to be reiterated as people are prone to confusing the concepts "open source" and "free", basic economics dictates infinite demand for free goods, and we've all got lives to live. As per our off-list discussion: It's a damned if we do and damned if we don't situation. Take the patch and it eats someone's lunch, and our reptuation suffers. Don't take the patch and look like patriarchal killjoys, and our reputation siffers. Your specific objection is that the testing is insufficient to exercise the patch, and there could be an area of ext2 which this patch doesn't address. That can never be said with 100% certainty, but I agree with you. Content free argument: Based on my reading of the code, the patch must be considered experimental. Whilst the scope of the patch appears to be small, the symbol space of ext2 is bigger -- a case of feeping creaturism due to ext2 itself, but hey, that's evolution for you. If folk are happy with it going in, let it go in, but remember, you get the system you apply effort to. I myself consider the patch experimental -- but HEAD is an experiment, is it not? Reality is what you can get away with. cheers BMS From pj at smo.de Thu Dec 4 05:40:54 2008 From: pj at smo.de (Philipp Ost) Date: Thu Dec 4 05:44:03 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <4937A786.9080403@kkip.pl> References: <4937A786.9080403@kkip.pl> Message-ID: <4937CBBC.1020406@smo.de> Hi, Bartosz Stec wrote: > [...] Is there *any* way to > burn DVDs with files>4GB from FreeBSD console? I succesfully used growisofs for exactly this task ;-) What I did is (for DL-DVDs): # growisofs -dvd-compat -Z /dev/cd0=$file.iso -speed=2 I had to limit the speed, else it wouldn't do anything. If I burn "normal" DVDs I don't need the speed limit. HTH, Philipp From samflanker at gmail.com Thu Dec 4 07:24:12 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Thu Dec 4 07:24:24 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE Message-ID: <4937F627.8080602@gmail.com> problem is fixed in OpenBSD 4.4 http://www.openbsd.org/plus44.html /Vladimir Ermakov From max at love2party.net Thu Dec 4 07:47:16 2008 From: max at love2party.net (Max Laier) Date: Thu Dec 4 07:47:24 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE In-Reply-To: <4937F627.8080602@gmail.com> References: <4937F627.8080602@gmail.com> Message-ID: <200812041647.14049.max@love2party.net> On Thursday 04 December 2008 16:24:23 Vladimir Ermakov wrote: > problem is fixed in OpenBSD 4.4 > http://www.openbsd.org/plus44.html The bug this note refers to was introduced after OpenBSD 4.1 (our last import) and should not be present in the FreeBSD code. I'll double check in a bit to make sure synproxy is working, but I don't think it was broken after my last import ... do you have a particular test case that I could reproduce? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From dkelly at hiwaay.net Thu Dec 4 08:11:49 2008 From: dkelly at hiwaay.net (David Kelly) Date: Thu Dec 4 08:11:56 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <4937A786.9080403@kkip.pl> References: <4937A786.9080403@kkip.pl> Message-ID: <20081204154507.GA18645@Grumpy.DynDNS.org> On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: > My backup script split filesystem dumps to files with size of 4,37 GB (4 > 588 544 kB). It's just an optimal size to fill out DVDs. At this moment > I have to burn them from windows via smb-link becuase I didn't manage to > do this task from FreeBSD console due to 2GB/4GB filesize restrictions > (growisofs). Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I have burned 4.3GB DVDs several times. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From stephen at math.missouri.edu Thu Dec 4 08:27:08 2008 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Thu Dec 4 08:27:15 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <20081204154507.GA18645@Grumpy.DynDNS.org> References: <4937A786.9080403@kkip.pl> <20081204154507.GA18645@Grumpy.DynDNS.org> Message-ID: <493801F5.2050009@math.missouri.edu> David Kelly wrote: > On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: >> My backup script split filesystem dumps to files with size of 4,37 GB (4 >> 588 544 kB). It's just an optimal size to fill out DVDs. At this moment >> I have to burn them from windows via smb-link becuase I didn't manage to >> do this task from FreeBSD console due to 2GB/4GB filesize restrictions >> (growisofs). > > Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I > have burned 4.3GB DVDs several times. I never had a problem writing huge files. But I did have a problem subsequently reading it with Windows XP. Maybe the file size restriction is a Windows thing. From josh.carroll at gmail.com Thu Dec 4 09:06:49 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Thu Dec 4 09:06:56 2008 Subject: ext2 inode size patch - RE: PR kern/124621 In-Reply-To: <200812041747.09040.gnemmi@gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> Message-ID: <8cb6106e0812040902g69ec2f84t814c2f2b5cdb33f6@mail.gmail.com> > Could you please point me to your patch and an explanation on how to apply it > and test it? You can grab the patch here: http://pflog.net/~floyd/ext2fs.diff To apply it: cd /usr/src/sys/gnu/fs patch < /path/to/ext2fs.diff cd /usr/src/sys/modules/ext2fs make clean && make kldload ./ext2fs.ko Then umount and mount again your ext2 file systems. This should apply cleanly to RELENG_7_0, RELENG_7_1 and RELENG_7 source. I'm not sure if it'll apply cleanly to -CURRENT or not (I can provide an updated patch if you need it). Note: if you have ext2fs built into your kernel, you'll have to build and install your kernel as usual after patching, instead of building the module separately. Also, if you already have ext2fs loaded, you'll need to kldunload it first of course. If you want to update the ext2fs.ko in your installed kernel in /boot/kernel, after a make in .../modules/ext2fs, you can "make install". Thanks, Josh From gnemmi at gmail.com Thu Dec 4 09:09:12 2008 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Thu Dec 4 09:09:19 2008 Subject: ext2 inode size patch - RE: PR kern/124621 In-Reply-To: <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> Message-ID: <200812041747.09040.gnemmi@gmail.com> On Wednesday 03 December 2008 8:53:43 pm Josh Carroll wrote: > > Ok, I describe my concern once more. I do not object against the checking > > of the inode size. But, if inode size is changed, then some data is added > > to the inode, that could (and usually does, otherwise why extend it ?) > > change intrerpetation of the inode. Thus, we need a verification of the > > fact that simply ignoring added fields does not damage filesystem or > > cause user data corruption. Verification != testing. > > Let me take another crack at explaining why I think this patch is not > dangerous. > > The inode size is determined by reading the following member: > > __u16 s_inode_size; > > of the ext2_super_block structure. > > I took a look at the Linux 2.6.27.7 kernel source, and indeed they do > something very similar if not the same: > > #define EXT2_INODE_SIZE(s) (EXT2_SB(s)->s_inode_size) > > If you compare to what I did: > > #define EXT2_INODE_SIZE(s) ((s)->u.ext2_sb.s_inode_size) > > This is really the same thing, since EXT2_SB is defined (in the Linux > kernel src as): > > #ifdef __KERNEL__ > #include > static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb) > { > return sb->s_fs_info; > } > > And struct ext2_sb_info has the following member: > > int s_inode_size; > > Essentially, the changes I made simply query the existing information > from the filesystem, which is what the Linux kernel does as well. > > The inode size, blocks per group, etc are all defined at filesystem > creation time by mke2fs and it ensures the sanity of the relationship > between the inodes/blocks/block groups. > > The first diagram here: > > http://sunsite.nus.sg/LDP/LDP/tlk/node95.html > > Makes it clear that as long as the number of inodes per block and the > blocks per group is is sane during fs creation, looking up the inode > size as my patch does is fine, since the creation of the filesystem is > ensures a correct by construction situation. We're simply reading the > size of the inode based on the filesystem. > > I hope this is sufficient to convince some further thought about > committing this. > > For those interested in the relevant Linux kernel source, you can have > a look at line 105 of include/linux/ext2_fs.h from the linux-2.6.27.7 > kernel source. > > Thanks, > Josh Could you please point me to your patch and an explanation on how to apply it and test it? I've been following your las emails referencing it ( on @questions and @hackers or current i think it was ... ) and I'd like to give it a spin in here ... I've followed the "can't mount ext2/3" problem for a time (since I have that problem) and would like to know to what extent for patch solves the problem. Here are some of the references: mounting linux partitions Fri May 9 18:05:26 UTC 2008 http://lists.freebsd.org/pipermail/freebsd-questions/2008-May/174588.html bad file descriptor when mounting an ext2fs. Tue Jun 10 11:08:46 UTC 2008 http://lists.freebsd.org/pipermail/freebsd-questions/2008-June/176506.html mounting ext2fs partitions on FBSD7 ( third time a charm?) Fri Jul 4 23:33:53 UTC 2008 http://lists.freebsd.org/pipermail/freebsd-questions/2008-July/178219.html My case: root@inferna:~ # ls -l /dev/ad4s ad4s1% ad4s2% ad4s3% ad4s3a% ad4s3b% ad4s3c% ad4s3d% ad4s3e% ad4s3f% ad4s4% ad4s5% ad4s6% ad4s7% ad4s8% root@inferna:~ # ls -l /dev/ad4s root@inferna:~ # tune2fs -l /dev/ad4s1 | grep "Inode size" Inode size: 256 root@inferna:~ # tune2fs -l /dev/ad4s6 | grep "Inode size" Inode size: 256 root@inferna:~ # tune2fs -l /dev/ad4s7 | grep "Inode size" Inode size: 256 root@inferna:~ # tune2fs -l /dev/ad4s8 | grep "Inode size" Inode size: 256 root@inferna:~ # tune2fs -l /dev/ad4s9 | grep "Inode size" BTW: I'm willing to run any tests you need me too, even if they imply a serious risk of loosing data on the 256 inode partitions. Regards -- Blessings Gonzalo Nemmi From max at love2party.net Thu Dec 4 09:28:37 2008 From: max at love2party.net (Max Laier) Date: Thu Dec 4 09:28:43 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE In-Reply-To: <200812041647.14049.max@love2party.net> References: <4937F627.8080602@gmail.com> <200812041647.14049.max@love2party.net> Message-ID: <200812041828.34033.max@love2party.net> On Thursday 04 December 2008 16:47:13 Max Laier wrote: > On Thursday 04 December 2008 16:24:23 Vladimir Ermakov wrote: > > problem is fixed in OpenBSD 4.4 > > http://www.openbsd.org/plus44.html > > The bug this note refers to was introduced after OpenBSD 4.1 (our last > import) and should not be present in the FreeBSD code. I'll double check > in a bit to make sure synproxy is working, but I don't think it was broken > after my last import ... do you have a particular test case that I could > reproduce? Okay ... here is the story: First off, "synproxy state" is *NOT* broken! But you need to be careful how you use it. If you - like the OP - intend to use it to protect a service running on the same box as your pf, you must make sure to "set skip on lo0" or it will not work. If you are protecting a box behind the pf box, there is no need for that. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From korvus at comcast.net Thu Dec 4 09:54:36 2008 From: korvus at comcast.net (Steve Polyack) Date: Thu Dec 4 09:54:47 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <493801F5.2050009@math.missouri.edu> References: <4937A786.9080403@kkip.pl> <20081204154507.GA18645@Grumpy.DynDNS.org> <493801F5.2050009@math.missouri.edu> Message-ID: <493816EE.8010408@comcast.net> Not too say you're .iso images can't be >2GB/4GB, but I'm pretty sure the ISO9660 standard is limited to a 2GB maximum file size (for files within the .iso). You must use UDF to burn files of greater size. mkisofs(8) seems to support this, if only in alpha/hybrid stage: -udf Include UDF support in the generated filesystem image. UDF sup- port is currently in alpha status and for this reason, it is not possible to create UDF only images. Stephen Montgomery-Smith wrote: > David Kelly wrote: >> On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: >>> My backup script split filesystem dumps to files with size of 4,37 >>> GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At >>> this moment I have to burn them from windows via smb-link becuase I >>> didn't manage to do this task from FreeBSD console due to 2GB/4GB >>> filesize restrictions (growisofs). >> >> Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I >> have burned 4.3GB DVDs several times. > > I never had a problem writing huge files. But I did have a problem > subsequently reading it with Windows XP. Maybe the file size > restriction is a Windows thing. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From avg at icyb.net.ua Thu Dec 4 10:41:18 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Dec 4 10:41:25 2008 Subject: ichwd problem: watchdog doesn't "bark" In-Reply-To: <49300020.6060603@icyb.net.ua> References: <49300020.6060603@icyb.net.ua> Message-ID: <49382449.80002@icyb.net.ua> on 28/11/2008 16:28 Andriy Gapon said the following: > uname: > FreeBSD 7.1-PRERELEASE r185311 amd64 > > dmesg: > ichwd0: on isa0 > ichwd0: Intel ICH9R watchdog timer (ICH9 or equivalent) > ichwd0: timer disabled > > pciconf: > isab0@pci0:0:31:0: class=0x060100 card=0x50448086 chip=0x29168086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IR (ICH9R) LPC Interface Controller' > class = bridge > subclass = PCI-ISA > > > When I start watchdogd I see the following messages: > timer enabled > timeout set to 28 ticks > and then a flow of messages: > timer reloaded > > Then I kill -9 watchdogd. > "timer reloded" messages are no longer produced. > And there are no other messages. > > But nothing happens for many minutes that I waited. > BTW, can someone knowledgeable tell me if watchdog better be firing SMI or NMI when it runs down? My bet is on NMI, but who knows. Thanks! Or maybe I am trying to ask a different question. I see that NMI2SMI_EN bit of TCO1_CNT is set 1 on my machine and our watchdog driver is careful to preserve this bit unmodified. This means that watchdog would try to cause SMI instead of NMI. On the other hand I see that bit GBL_SMI_EN of SMI_EN is set to zero, which means that chipset would never generate an SMI. So I think this is why I don't see anything happening. Now, would should try first - reset NMI2SMI_EN to zero or set GBL_SMI_EN to 1? As additional data points: I see that TCO_EN bit of SMI_EN is 1 and it is locked to that value because TCO_LOCK bit of TCO1_CNT is 1. SMI_LOCK in PCI config register GEN_PMCON_1 is not set. -- Andriy Gapon From peterjeremy at optushome.com.au Thu Dec 4 11:16:48 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Dec 4 11:16:59 2008 Subject: sysinstall automatic partition labelling/sizing problem In-Reply-To: <49362A3C.7060204@fusiongol.com> References: <49362A3C.7060204@fusiongol.com> Message-ID: <20081204191640.GH58682@server.vk2pj.dyndns.org> On 2008-Dec-03 15:42:04 +0900, Nathan Butcher wrote: >Automatic labelling on 7.0 created about 360MB for my root partition on >a 8GB disk. After a buildkernel into 7.1-PRERELEASE, the root partition >was exhausted during the installkernel. Are you running i386 or amd64? 360MB _is_ a very tight fit for amd64 but you should make it unless you have some large, unexpected files lying around in your root partition. As a workaround, you could remove *.symbols from the old kernel files. >Maybe automatic labelling in sysinstall needs to allocate more than >360MB in the root (/) partition if it's going to stay big enough to >accomodate a buildkernel and installkernel from source. Looking at sysinstall, the default size is currently 512MB unless you have less than ~20GB, when it will start scaling down. Your options are: 1) Expand root (maybe use growfs and eat into your swap) 2) Avoid building unwanted modules via MODULES_OVERRIDE. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081204/1b870567/attachment.pgp From dkelly at hiwaay.net Thu Dec 4 11:20:00 2008 From: dkelly at hiwaay.net (David Kelly) Date: Thu Dec 4 11:20:07 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <493816EE.8010408@comcast.net> References: <4937A786.9080403@kkip.pl> <20081204154507.GA18645@Grumpy.DynDNS.org> <493801F5.2050009@math.missouri.edu> <493816EE.8010408@comcast.net> Message-ID: <20081204191957.GA32007@Grumpy.DynDNS.org> On Thu, Dec 04, 2008 at 12:44:14PM -0500, Steve Polyack wrote: > Not too say you're .iso images can't be >2GB/4GB, but I'm pretty sure > the ISO9660 standard is limited to a 2GB maximum file size (for files > within the .iso). You must use UDF to burn files of greater size. > mkisofs(8) seems to support this, if only in alpha/hybrid stage: > > -udf Include UDF support in the generated filesystem image. UDF sup- > port is currently in alpha status and for this reason, it is not > possible to create UDF only images. It would seem then that the O.P. who is already splitting his backup into 4.3GB chunks should split backups into sub-2GB chunks. 4,700,000,000 is the standard DVD size, I'd shoot for chunks of 4.5E9/3 so as to have about 200MB of headroom per DVD. growisofs will write 3 files to the DVD just as easily as one. The magic of growisofs is that it invokes mkisofs on the fly. And also that cdrecord had obnoxious (and broken) licensing in years past when I last tried it. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From oberman at es.net Thu Dec 4 12:48:04 2008 From: oberman at es.net (Kevin Oberman) Date: Thu Dec 4 12:48:11 2008 Subject: repeatable crash on RELENG7 In-Reply-To: Your message of "Tue, 02 Dec 2008 19:33:00 +0300." Message-ID: <20081204204803.EB8D34500F@ptavv.es.net> > Date: Tue, 2 Dec 2008 19:33:00 +0300 > From: "Alexandr Pakhomov" > Sender: owner-freebsd-stable@freebsd.org > > On Tue, Dec 2, 2008 at 5:12 PM, Mike Tancsa wrote: > > > At 08:38 AM 12/2/2008, Kostik Belousov wrote: > > > >> > > >> > mdconfig -a -t malloc -s 1800M > >> You cannot have ~ 2Gb of kernel memory allocated for md, at least not on > >> i386. > >> > > > > Thanks, how do I find out what the limit is on a machine ? Is it > > vm.kvm_size ? > > > > > > ---Mike > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > Try tune both vm.kmem_size and vm.kmem_size_max via /boot/loader.conf. They > are equal to 330M by default. Mike, Let me second Kris's suggestion. I can think of very few cases where malloc backed is in any way better than swap backed. Many people assume that swap-backed performance is better, but this is only the case if you run out of memory (and that is full memory, not kvm). md is still RAM based and very fast. The current mdconfig should be defaulting to swap-backed devices, but I don't see any indication of that in the man page, so I may be wrong. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081204/ef7cc1d7/attachment.pgp From korvus at comcast.net Thu Dec 4 13:28:43 2008 From: korvus at comcast.net (Steve Polyack) Date: Thu Dec 4 13:28:50 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <20081204204803.EB8D34500F@ptavv.es.net> References: <20081204204803.EB8D34500F@ptavv.es.net> Message-ID: <49384863.9040807@comcast.net> Kevin Oberman wrote: >> Date: Tue, 2 Dec 2008 19:33:00 +0300 >> From: "Alexandr Pakhomov" >> Sender: owner-freebsd-stable@freebsd.org >> >> On Tue, Dec 2, 2008 at 5:12 PM, Mike Tancsa wrote: >> >> >>> At 08:38 AM 12/2/2008, Kostik Belousov wrote: >>> >>> >>>>> mdconfig -a -t malloc -s 1800M >>>>> >>>> You cannot have ~ 2Gb of kernel memory allocated for md, at least not on >>>> i386. >>>> >>>> >>> Thanks, how do I find out what the limit is on a machine ? Is it >>> vm.kvm_size ? >>> >>> >>> ---Mike >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>> >>> >> Try tune both vm.kmem_size and vm.kmem_size_max via /boot/loader.conf. They >> are equal to 330M by default. >> > > Mike, > > Let me second Kris's suggestion. I can think of very few cases where > malloc backed is in any way better than swap backed. Many people assume > that swap-backed performance is better, but this is only the case if you > run out of memory (and that is full memory, not kvm). > > md is still RAM based and very fast. The current mdconfig should be > defaulting to swap-backed devices, but I don't see any indication of > that in the man page, so I may be wrong. > I agree here. Using mdconfig(8) in malloc-backed mode may lead to unpredictable results when attempting to use large amounts of memory. mdconfig(8) seems to allow you to "reserve" more kernel memory than may be appropriate, and as in Mike's experience, causes a kernel panic upon writing enough data to the malloc'd md(4) device. It seems that the term "swap-backed" is misleading for some people. It does NOT mean your md(4) device will be constantly swapping to disk (and the man page does an alright job of relaying this). It simply means that generally available memory will be used, and so will swap iff available memory happens to drop low enough. The bottom line in my experience with md(4) devices greater than ~100MB is that "swap-backed" is always reliable, while malloc'd md(4) devices will cause unpredictable kernel panics. From josh.carroll at gmail.com Thu Dec 4 14:11:48 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Thu Dec 4 14:11:54 2008 Subject: repeatable crash on RELENG7 In-Reply-To: <49384863.9040807@comcast.net> References: <20081204204803.EB8D34500F@ptavv.es.net> <49384863.9040807@comcast.net> Message-ID: <8cb6106e0812041411t13ca9ffcjc4cc66a33ef43133@mail.gmail.com> > It seems that the term "swap-backed" is misleading for some people. It does > NOT mean your md(4) device will be constantly swapping to disk (and the man > page does an alright job of relaying this). It simply means that generally > available memory will be used, and so will swap iff available memory happens > to drop low enough. > > The bottom line in my experience with md(4) devices greater than ~100MB is > that "swap-backed" is always reliable, while malloc'd md(4) devices will > cause unpredictable kernel panics. Using -t swap instead of -t malloc will prevent a panic, but creating an md greater than the size of the VM available and filling it will cause resource exhaustion and OOM will kick in and start killing processes, right? So while it won't panic the box, I still wouldn't consider it safe to use unless the size of the md is chosen carefully. Someone please correct me if I'm wrong, but I think that'd be the behavior if an md with -t swap is used, right? Regards, Josh From zbeeble at gmail.com Thu Dec 4 14:34:43 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Thu Dec 4 14:34:50 2008 Subject: SATA CD fail. Message-ID: <5f67a8c40812041432y13793ee5k1d2526c9829dc16f@mail.gmail.com> I've got an HP DL-360 1U here that has a slim SATA CDROM. I've (so far) tried booting FreeBSD-7.0-RELEASE and FreeBSD-7.1-BETA2. I've tried both rewritable media (my first choice) and write-once media. The kernel loads fine, but multiuser fails with "acd0: TIMEOUT - READ_BIG retrying" ... twice, followed by "timed out". From oberman at es.net Thu Dec 4 15:20:22 2008 From: oberman at es.net (Kevin Oberman) Date: Thu Dec 4 15:20:29 2008 Subject: repeatable crash on RELENG7 In-Reply-To: Your message of "Thu, 04 Dec 2008 17:11:46 EST." <8cb6106e0812041411t13ca9ffcjc4cc66a33ef43133@mail.gmail.com> Message-ID: <20081204232020.7289A45019@ptavv.es.net> > Date: Thu, 4 Dec 2008 17:11:46 -0500 > From: "Josh Carroll" > > > It seems that the term "swap-backed" is misleading for some people. It does > > NOT mean your md(4) device will be constantly swapping to disk (and the man > > page does an alright job of relaying this). It simply means that generally > > available memory will be used, and so will swap iff available memory happens > > to drop low enough. > > > > The bottom line in my experience with md(4) devices greater than ~100MB is > > that "swap-backed" is always reliable, while malloc'd md(4) devices will > > cause unpredictable kernel panics. > > Using -t swap instead of -t malloc will prevent a panic, but creating > an md greater than the size of the VM available and filling it will > cause resource exhaustion and OOM will kick in and start killing > processes, right? So while it won't panic the box, I still wouldn't > consider it safe to use unless the size of the md is chosen carefully. > Someone please correct me if I'm wrong, but I think that'd be the > behavior if an md with -t swap is used, right? Yes, but the VM available is just a bit larger than the amount of KVM. you still need at least a bit of sanity when you create (and fill) an MD device. For performance reasons, I suggest keeping the size of an MD so that it will fit in RAM. Paging in and out is rather painfully slow. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081204/2cdc6f3e/attachment.pgp From fbsdlists at gmail.com Thu Dec 4 16:41:30 2008 From: fbsdlists at gmail.com (Bob Johnson) Date: Thu Dec 4 16:41:37 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <4937D26D.60408@kkip.pl> References: <4937A786.9080403@kkip.pl> <4937CBBC.1020406@smo.de> <4937D26D.60408@kkip.pl> Message-ID: <54db43990812041614h62f2608bua8462341a59c8626@mail.gmail.com> On 12/4/08, Bartosz Stec wrote: > Philipp Ost pisze: >> Hi, >> >> Bartosz Stec wrote: >>> [...] Is there *any* way to burn DVDs with files>4GB from FreeBSD >>> console? >> >> I succesfully used growisofs for exactly this task ;-) >> >> What I did is (for DL-DVDs): >> # growisofs -dvd-compat -Z /dev/cd0=$file.iso -speed=2 >> >> I had to limit the speed, else it wouldn't do anything. If I burn >> "normal" DVDs I don't need the speed limit. >> >> HTH, >> Philipp > But doesn't that command expecting file.iso being already premastered > ISO image? OK, that's *some* way, but to be clear - I want to avoid > preparing ISO images too ;) > Some thoughts that might be useful: 1) I expect the problem is with mkisofs version 2.01 that is used in FreeBSD (at least in 7.0), but I haven't attempted to confirm this. Growisofs is supposed to handle large files, and so are recent versions of mkisofs. The author of mkisofs considers 2.01 to be obsolete. Perhaps installing a newer mkisofs is the solution (e.g. sysutils/cdrtools-devel appears to be fairly recent)? 2) Perhaps you could do what I do and write tar files directly to DVD with no filesystem. I use burncd to write the file to the DVD, but I don't remember if I've tried to exceed 4 GiB per file. You might need growisofs in premastered image mode instead of burncd. To read the file later use something like 'tar -xf /dev/cd0'. Might have a problem with this in Windows, but maybe that's not really a problem? 3) You could modify your script to use mkisofs to create the ISO image as part of the process of splitting your files into (smaller) chunks. Then use growisofs in premastered image mode, as already suggested. If you want to do this, look at the -stream-media-size option in mkisofs. 4) The 4 GiB limit on file size is built into the ISO 9660 filesystem prior to Level 3. Level 3 allows larger files by allowing files to have multiple extents (each extent must still be < 4 GiB). You may need to explicitly specify ISO Level 3 to get the correct behavior (i.e. use the '-iso-level 3' option with growisofs or mkisofs). -- Bob Johnson fbsdlists@gmail.com From lists-freebsd-stable at biaix.org Thu Dec 4 17:42:16 2008 From: lists-freebsd-stable at biaix.org (Joan Picanyol i Puig) Date: Thu Dec 4 17:42:27 2008 Subject: can't freebsd-update from 7.1-PRERELEASE Message-ID: <20081205011412.GA3515@grummit.biaix.org> Hi, Apparently 7.1-PRERELEASE has been pulled from freebsd-update's server while I was being lazy: calvin% sudo freebsd-update --debug upgrade -r 7.1-BETA2 Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 7.1-PRERELEASE from update1.FreeBSD.org... fetch: http://update1.FreeBSD.org/7.1-PRERELEASE/i386/latest.ssl: Not Found failed. No mirrors remaining, giving up. Any workarounds? -- pica From ari at ish.com.au Thu Dec 4 18:53:49 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Thu Dec 4 18:53:57 2008 Subject: can't freebsd-update from 7.1-PRERELEASE In-Reply-To: <20081205011412.GA3515@grummit.biaix.org> References: <20081205011412.GA3515@grummit.biaix.org> Message-ID: On 05/12/2008, at 12:14 PM, Joan Picanyol i Puig wrote: > Hi, > > Apparently 7.1-PRERELEASE has been pulled from freebsd-update's server > while I was being lazy: > > calvin% sudo freebsd-update --debug upgrade -r 7.1-BETA2 > Looking up update.FreeBSD.org mirrors... 1 mirrors found. > Fetching metadata signature for 7.1-PRERELEASE from > update1.FreeBSD.org... > fetch: http://update1.FreeBSD.org/7.1-PRERELEASE/i386/latest.ssl: > Not Found > failed. > No mirrors remaining, giving up. Yeah, this seems to be a problem in freebsd-update. You can workaround like this: # env UNAME_r=7.1-BETA freebsd-update upgrade -r 7.1-BETA2 Something got mixed up in the naming of the releases and freebsd- update gets confused. Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From n-butcher at fusiongol.com Thu Dec 4 19:04:11 2008 From: n-butcher at fusiongol.com (Nathan Butcher) Date: Thu Dec 4 19:04:20 2008 Subject: sysinstall automatic partition labelling/sizing problem In-Reply-To: <20081204191640.GH58682@server.vk2pj.dyndns.org> References: <49362A3C.7060204@fusiongol.com> <20081204191640.GH58682@server.vk2pj.dyndns.org> Message-ID: <49389A27.8040704@fusiongol.com> > Are you running i386 or amd64? 360MB _is_ a very tight fit for amd64 > but you should make it unless you have some large, unexpected files > lying around in your root partition. As a workaround, you could > remove *.symbols from the old kernel files. Running amd64. The install was fresh so there were no extra files in / > Looking at sysinstall, the default size is currently 512MB unless you > have less than ~20GB, when it will start scaling down. maybe it needs to scale down just a little bit less than it already does.... although granted, not every install is going to experience a kernal recompile from source - well, ones that expect to be maintained anyway. > Your options are: > 1) Expand root (maybe use growfs and eat into your swap) > 2) Avoid building unwanted modules via MODULES_OVERRIDE. Fair enough. This issue just bit me in the behind because I was expecting the 7.1 kernal and modules to take up about as much space as 7.0 ... but then I remember that dtrace found it's way into 7.1 plus a whole lotta code.... From jesper at nohack.se Thu Dec 4 20:34:07 2008 From: jesper at nohack.se (Jesper Wallin) Date: Thu Dec 4 20:34:14 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE In-Reply-To: <200812041828.34033.max@love2party.net> References: <4937F627.8080602@gmail.com> <200812041647.14049.max@love2party.net> <200812041828.34033.max@love2party.net> Message-ID: <20081205041433.GA35652@zero.nohack.se> * Max Laier [2008-12-04 18:28:33 +0100]: > On Thursday 04 December 2008 16:47:13 Max Laier wrote: > > On Thursday 04 December 2008 16:24:23 Vladimir Ermakov wrote: > > > problem is fixed in OpenBSD 4.4 > > > http://www.openbsd.org/plus44.html > > > > The bug this note refers to was introduced after OpenBSD 4.1 (our last > > import) and should not be present in the FreeBSD code. I'll double check > > in a bit to make sure synproxy is working, but I don't think it was broken > > after my last import ... do you have a particular test case that I could > > reproduce? > > Okay ... here is the story: First off, "synproxy state" is *NOT* broken! But > you need to be careful how you use it. If you - like the OP - intend to use > it to protect a service running on the same box as your pf, you must make sure > to "set skip on lo0" or it will not work. If you are protecting a box behind > the pf box, there is no need for that. Without getting too far off-topic here. I personally find synproxy (or any stateful firewall for that matter) useless. The idea behind synproxy is to protect the actual server from a SYN-flood, which would cause all sockets to be filled up and the service would be unavailable. With this "protection" enabled, you simply limit the amount of SYN packets to respond to, to the amount of what your state-table allow. When the state-table is full, you're service will still be unavailable. During my personal testing, I could easily make a service hosted on a machine with a gigabit connection unavailable with approximenty 250kb/s of SYN-packets with random source addresses, using some lines of simple perl code. I would rather suggest using the "no state" option and use syncookies, as it's *way* more effective against this kind of attack. You can easily limit the outbound traffic using altq if needed. Using synstate will only make the real users fight against the attacker for an open spot in the states-table, where an attacker easily can create ~200k states a sec, using very little bandwidth. (note that pf's default size of the states-table is 10000) I would love if someone (I would do it myself if I had the knowledge of C/C++) could add some sort of "syn-cookies + pf" support, where pf took advantage of the syn-cookie feature when deciding if the states-table is full or not. Making it responding with SYN/ACK's even if the states-table is full, and use the syn-cookies algorithm when an ACK is recieved, and re-add the SYN-state into the table if the syn-cookie is valid. Regards, Jesper Wallin ps, seems like I forgot to forward this to the list. ;-) From david at esn.org.za Thu Dec 4 21:53:46 2008 From: david at esn.org.za (David Peall) Date: Thu Dec 4 21:53:55 2008 Subject: rtfree: 0xffffff00013797c0 has 1 refs Message-ID: <0807767D2D53E649827BC55A3A53B06709C6C04BFE@exchange.ct.esn.org.za> Hi I'm getting some strange messages: Dec 5 07:49:19 jonny kernel: rtfree: 0xffffff0001379d90 has 1 refs Dec 5 07:49:19 jonny kernel: rtfree: 0xffffff000a1784d8 has 1 refs Dec 5 07:49:28 jonny kernel: rtfree: 0xffffff000198a7c0 has 1 refs Dec 5 07:49:31 jonny kernel: rtfree: 0xffffff00013797c0 has 1 refs Dec 5 07:49:35 jonny kernel: rtfree: 0xffffff00013797c0 has 1 refs Dec 5 07:49:37 jonny kernel: rtfree: 0xffffff0001c233e0 has 1 refs Dec 5 07:49:43 jonny kernel: rtfree: 0xffffff00013797c0 has 1 refs Dec 5 07:49:47 jonny kernel: rtfree: 0xffffff0001b3bc98 has 1 refs I've tried google but couldn't find anything usefull. Uname -a FreeBSD jonny.esn.org.za 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Nov 26 08:03:32 UTC 2008 root@:/usr/obj/usr/src/sys/GENERIC amd64 Is there some other output that would be useful please let me know. -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From samflanker at gmail.com Thu Dec 4 23:16:03 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Thu Dec 4 23:16:15 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE In-Reply-To: <200812041828.34033.max@love2party.net> References: <4937F627.8080602@gmail.com> <200812041647.14049.max@love2party.net> <200812041828.34033.max@love2party.net> Message-ID: <4938D540.4080304@gmail.com> Max Laier wrote: > > > Okay ... here is the story: First off, "synproxy state" is *NOT* broken! But > you need to be careful how you use it. If you - like the OP - intend to use > it to protect a service running on the same box as your pf, you must make sure > to "set skip on lo0" or it will not work. If you are protecting a box behind > the pf box, there is no need for that. > > Max, sorry for your time. Thanks, i solved the problem. /Vladimir Ermakov From pluknet at gmail.com Fri Dec 5 00:00:51 2008 From: pluknet at gmail.com (pluknet) Date: Fri Dec 5 00:01:19 2008 Subject: SATA CD fail. In-Reply-To: <5f67a8c40812041432y13793ee5k1d2526c9829dc16f@mail.gmail.com> References: <5f67a8c40812041432y13793ee5k1d2526c9829dc16f@mail.gmail.com> Message-ID: 2008/12/5 Zaphod Beeblebrox : > I've got an HP DL-360 1U here that has a slim SATA CDROM. I've (so far) > tried booting FreeBSD-7.0-RELEASE and FreeBSD-7.1-BETA2. I've tried both > rewritable media (my first choice) and write-once media. The kernel loads > fine, but multiuser fails with "acd0: TIMEOUT - READ_BIG retrying" ... > twice, followed by "timed out". I workarounded this by ejecting CD after kernel is loaded but before probing media, then installing from sysinstall via NFS from this CD inserted on nearby with IDE CDROM computer. -- wbr, pluknet From admin at kkip.pl Fri Dec 5 00:33:02 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Dec 5 00:33:09 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <20081204154507.GA18645@Grumpy.DynDNS.org> References: <4937A786.9080403@kkip.pl> <20081204154507.GA18645@Grumpy.DynDNS.org> Message-ID: <4938E73A.5070304@kkip.pl> David Kelly pisze: > On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: > >> My backup script split filesystem dumps to files with size of 4,37 GB (4 >> 588 544 kB). It's just an optimal size to fill out DVDs. At this moment >> I have to burn them from windows via smb-link becuase I didn't manage to >> do this task from FreeBSD console due to 2GB/4GB filesize restrictions >> (growisofs). >> > > Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I > have burned 4.3GB DVDs several times. > > Just look, here is example: fbsd# growisofs -Z /dev/cd0 -R -J -udf -iso-level 3 -dry-run somefile Executing 'mkisofs -R -J -udf -iso-level 3 somefile | builtin_dd of=/dev/pass0 obs=32k seek=0' mkisofs: Value too large to be stored in data type. File somefile is too large - ignoring I'm not talking about restriction of DVD size, but restriction to filesize wchich I want to place on DVD: fbsd# cat somefile | split -b 2G fbsd# rm somefile fbsd# ls -lh total 4590848 -rw-r--r-- 1 root operator 2,0G 5 gru 09:18 xaa -rw-r--r-- 1 root operator 2,0G 5 gru 09:24 xab -rw-r--r-- 1 root operator 385M 5 gru 09:26 xac fbsd# growisofs -v -Z /dev/cd0 -R -J -udf -dry-run ./ Executing 'mkisofs -v -R -J -udf ./ | builtin_dd of=/dev/pass0 obs=32k seek=0' mkisofs 2.01 (i386-unknown-freebsd7.0) Scanning ./ Writing: Initial Padblock Start Block 0 Done with: Initial Padblock Block(s) 16 Writing: Primary Volume Descriptor Start Block 16 Done with: Primary Volume Descriptor Block(s) 1 Writing: Joliet Volume Descriptor Start Block 17 Done with: Joliet Volume Descriptor Block(s) 1 Writing: End Volume Descriptor Start Block 18 Done with: End Volume Descriptor Block(s) 1 Writing: UDF volume recognition area Start Block 19 Done with: UDF volume recognition area Block(s) 3 Writing: Version block Start Block 22 Done with: Version block Block(s) 1 Writing: UDF pad to sector 32 Start Block 23 Done with: UDF pad to sector 32 Block(s) 9 Writing: UDF main seq Start Block 32 When I split that file there are no errors and DVD is 4,3GB size. -- Bartosz Stec From admin at kkip.pl Fri Dec 5 01:00:31 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Dec 5 01:00:37 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <20081204191957.GA32007@Grumpy.DynDNS.org> References: <4937A786.9080403@kkip.pl> <20081204154507.GA18645@Grumpy.DynDNS.org> <493801F5.2050009@math.missouri.edu> <493816EE.8010408@comcast.net> <20081204191957.GA32007@Grumpy.DynDNS.org> Message-ID: <4938EDAB.70809@kkip.pl> David Kelly pisze: > On Thu, Dec 04, 2008 at 12:44:14PM -0500, Steve Polyack wrote: > >> Not too say you're .iso images can't be >2GB/4GB, but I'm pretty sure >> the ISO9660 standard is limited to a 2GB maximum file size (for files >> within the .iso). You must use UDF to burn files of greater size. >> mkisofs(8) seems to support this, if only in alpha/hybrid stage: >> >> -udf Include UDF support in the generated filesystem image. UDF sup- >> port is currently in alpha status and for this reason, it is not >> possible to create UDF only images. >> > > It would seem then that the O.P. who is already splitting his backup > into 4.3GB chunks should split backups into sub-2GB chunks. > 4,700,000,000 is the standard DVD size, I'd shoot for chunks of 4.5E9/3 > so as to have about 200MB of headroom per DVD. > > growisofs will write 3 files to the DVD just as easily as one. The magic > of growisofs is that it invokes mkisofs on the fly. And also that > cdrecord had obnoxious (and broken) licensing in years past when I last > tried it. > > Yes, I know that. My reasons for keeping one file on DVD are just for making my life easier. If I want to restore some files from filesystem backup (they are made via pipeline dump | gunzip | split) I have to copy all files from DVDs wchich includes needed filesystem and then I type: cat file1 file2 file3 ... fileN | gunzip | restore -if - And yes, I know that tapes are much better for tasks like this but for now I just have to use DVDs :) Now imagine backup placed on 10 DVDs. With single file on DVD I have 10 files to manage, not 30. I know there're workarounds but with more files I probably will need some script to restore files rather than do it manually. That's the reason I asked if there's a possibility to burn it this way from FreeBSD. -- Bartosz Stec From admin at kkip.pl Fri Dec 5 01:02:13 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Dec 5 01:02:20 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <493801F5.2050009@math.missouri.edu> References: <4937A786.9080403@kkip.pl> <20081204154507.GA18645@Grumpy.DynDNS.org> <493801F5.2050009@math.missouri.edu> Message-ID: <4938EE12.4060609@kkip.pl> Stephen Montgomery-Smith pisze: > David Kelly wrote: >> On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: >>> My backup script split filesystem dumps to files with size of 4,37 >>> GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At >>> this moment I have to burn them from windows via smb-link becuase I >>> didn't manage to do this task from FreeBSD console due to 2GB/4GB >>> filesize restrictions (growisofs). >> >> Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I >> have burned 4.3GB DVDs several times. > > I never had a problem writing huge files. But I did have a problem > subsequently reading it with Windows XP. Maybe the file size > restriction is a Windows thing. Nope. I am burning my backups from Windows, and they're readable both from Windows and FreeBSD. FreeBSD just doesn't let me burn them directly :) -- Bartosz Stec From admin at kkip.pl Fri Dec 5 01:02:51 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Dec 5 01:03:09 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <493816EE.8010408@comcast.net> References: <4937A786.9080403@kkip.pl> <20081204154507.GA18645@Grumpy.DynDNS.org> <493801F5.2050009@math.missouri.edu> <493816EE.8010408@comcast.net> Message-ID: <4938EE38.2000504@kkip.pl> Steve Polyack pisze: > Not too say you're .iso images can't be >2GB/4GB, but I'm pretty sure > the ISO9660 standard is limited to a 2GB maximum file size (for files > within the .iso). You must use UDF to burn files of greater size. > mkisofs(8) seems to support this, if only in alpha/hybrid stage: > > -udf Include UDF support in the generated filesystem image. > UDF sup- > port is currently in alpha status and for this reason, it > is not > possible to create UDF only images. > Indeed. I'm using -udf switch, no success. -- Bartosz Stec From admin at kkip.pl Fri Dec 5 01:23:37 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Dec 5 01:23:44 2008 Subject: Burning DVD with files>4GB from console In-Reply-To: <54db43990812041614h62f2608bua8462341a59c8626@mail.gmail.com> References: <4937A786.9080403@kkip.pl> <4937CBBC.1020406@smo.de> <4937D26D.60408@kkip.pl> <54db43990812041614h62f2608bua8462341a59c8626@mail.gmail.com> Message-ID: <4938F316.9010403@kkip.pl> Bob Johnson pisze: > On 12/4/08, Bartosz Stec wrote: > >> Philipp Ost pisze: >> >>> Hi, >>> >>> Bartosz Stec wrote: >>> >>>> [...] Is there *any* way to burn DVDs with files>4GB from FreeBSD >>>> console? >>>> >>> I succesfully used growisofs for exactly this task ;-) >>> >>> What I did is (for DL-DVDs): >>> # growisofs -dvd-compat -Z /dev/cd0=$file.iso -speed=2 >>> >>> I had to limit the speed, else it wouldn't do anything. If I burn >>> "normal" DVDs I don't need the speed limit. >>> >>> HTH, >>> Philipp >>> >> But doesn't that command expecting file.iso being already premastered >> ISO image? OK, that's *some* way, but to be clear - I want to avoid >> preparing ISO images too ;) >> >> > > Some thoughts that might be useful: > > 1) I expect the problem is with mkisofs version 2.01 that is used in > FreeBSD (at least in 7.0), but I haven't attempted to confirm this. > Growisofs is supposed to handle large files, and so are recent > versions of mkisofs. The author of mkisofs considers 2.01 to be > obsolete. Perhaps installing a newer mkisofs is the solution (e.g. > sysutils/cdrtools-devel appears to be fairly recent)? > > 2) Perhaps you could do what I do and write tar files directly to DVD > with no filesystem. I use burncd to write the file to the DVD, but I > don't remember if I've tried to exceed 4 GiB per file. You might need > growisofs in premastered image mode instead of burncd. To read the > file later use something like 'tar -xf /dev/cd0'. Might have a > problem with this in Windows, but maybe that's not really a problem? > > 3) You could modify your script to use mkisofs to create the ISO image > as part of the process of splitting your files into (smaller) chunks. > Then use growisofs in premastered image mode, as already suggested. If > you want to do this, look at the -stream-media-size option in mkisofs. > > 4) The 4 GiB limit on file size is built into the ISO 9660 filesystem > prior to Level 3. Level 3 allows larger files by allowing files to > have multiple extents (each extent must still be < 4 GiB). You may > need to explicitly specify ISO Level 3 to get the correct behavior > (i.e. use the '-iso-level 3' option with growisofs or mkisofs). > > > -- Bob Johnson > fbsdlists@gmail.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Thanks a lot! Upgrading to sysutils/cdrtools-devel solves my problem! :) -- Bartosz Stec From des at des.no Fri Dec 5 02:04:57 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Dec 5 02:05:04 2008 Subject: ichwd problem: watchdog doesn't "bark" In-Reply-To: <49382449.80002@icyb.net.ua> (Andriy Gapon's message of "Thu, 04 Dec 2008 20:41:13 +0200") References: <49300020.6060603@icyb.net.ua> <49382449.80002@icyb.net.ua> Message-ID: <86wsefgcon.fsf@ds4.des.no> Andriy Gapon writes: > When I start watchdogd I see the following messages: > timer enabled > timeout set to 28 ticks > and then a flow of messages: > timer reloaded > > Then I kill -9 watchdogd. > "timer reloded" messages are no longer produced. > And there are no other messages. > > But nothing happens for many minutes that I waited. The watchdog may be disabled, either in hardware or by the BIOS at boot time, but the driver should have detected that. It is also possible that the BIOS catches the SMI but ignores it. > BTW, can someone knowledgeable tell me if watchdog better be firing SMI > or NMI when it runs down? It should fire SMI, IIRC. Read the comments at the top of the code for references to the relevant Intel documentation, which you can download for free. DES -- Dag-Erling Sm?rgrav - des@des.no From bms at FreeBSD.org Fri Dec 5 02:11:19 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Dec 5 02:11:31 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <200812041747.09040.gnemmi@gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> Message-ID: <4938FE44.9090608@FreeBSD.org> Hi, I just tested the ext2fuse project on FreeBSD 7.1-PRERELEASE as of today and found that it works for read/write on an ext3 filesystem. The inode size was 128 -- I haven't exercised dynamic inode sizes. ext2fuse project: http://sourceforge.net/projects/ext2fuse Required FreeBSD patches: http://people.freebsd.org/~bms/dump/ext2fuse-freebsd.patch Steps: 1. fetch http://ovh.dl.sourceforge.net/sourceforge/ext2fuse/ext2fuse-src-0.8.1.tar.gz 2. tar xvf ext2fuse-src-0.8.1.tar.gz 3. patch -i ext2fuse-0.8.1-freebsd.patch 4. cd ext2fuse-src-0.8.1 5. aclocal ; automake ; autoconf 6. ./configure && gmake Performance seems quite slow, it could probably benefit from being ported to use UBLIO as ntfs-3g for FreeBSD has. I'm going to leave this thing for others to play with, this was a 20 minute bunk-off from other work. It shouldn't take much effort to create a port around it. cheers BMS From Joerg.Schilling at fokus.fraunhofer.de Fri Dec 5 02:35:59 2008 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri Dec 5 02:36:08 2008 Subject: Burning DVD with files>4GB from console Message-ID: <4938fd0b.OhN+VuuHXZBfyAPp%Joerg.Schilling@fokus.fraunhofer.de> >My backup script split filesystem dumps to files with size of 4,37 GB (4 >588 544 kB). It's just an optimal size to fill out DVDs. At this moment >I have to burn them from windows via smb-link becuase I didn't manage to >do this task from FreeBSD console due to 2GB/4GB filesize restrictions >(growisofs). I'm using freeware CDBurnerXP to burn my backups What "limitations" are you thinking of? Growisofs is based on mkisofs which is part of cdrtools. Mkisofs supports large files since a long time (~ 8 years). >I never had a problem writing huge files. But I did have a problem >subsequently reading it with Windows XP. Maybe the file size >restriction is a Windows thing. >From the information I have, MS-WIN handles large files correctly. What problems do you have? >Not too say you're .iso images can't be >2GB/4GB, but I'm pretty sure >the ISO9660 standard is limited to a 2GB maximum file size (for files >within the .iso). You must use UDF to burn files of greater size. >mkisofs(8) seems to support this, if only in alpha/hybrid stage: The ISO-9660 standard is limited to 8 TB for the max. filesystem size as well as for the size of a single file. Mkisofs supports single files up to 4 GB since ~ Y2000 and it suppports files up to 8 TB since 2 years. >growisofs will write 3 files to the DVD just as easily as one. The magic >of growisofs is that it invokes mkisofs on the fly. And also that >cdrecord had obnoxious (and broken) licensing in years past when I last >tried it. Cdrecord alwas had and still has a free license. There is nothing broken with cdrtools/cdrecord. There is however a big social problem with the anti-social habbit and propaganda from Debian. Fortunately, cdrtools is not related to Debian, so where is your problem? Growisofs depends on mkisofs and mkisofs is part of cdrtools, so you need cdrtools anyway. >1) I expect the problem is with mkisofs version 2.01 that is used in >FreeBSD (at least in 7.0), but I haven't attempted to confirm this. >Growisofs is supposed to handle large files, and so are recent >versions of mkisofs. The author of mkisofs considers 2.01 to be >obsolete. Perhaps installing a newer mkisofs is the solution (e.g. >sysutils/cdrtools-devel appears to be fairly recent)? mkisofs-2.01 is more than 4 years old. It is not just obsolete but extremely outdated. Since mkisofs-2.01 30-50% of the code has been replaced or added. Cdrtools is only a few weeks from the next major release and it would be silly not to use a recent version. J?rg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From bms at FreeBSD.org Fri Dec 5 03:40:49 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Dec 5 03:41:00 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <4938FE44.9090608@FreeBSD.org> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> Message-ID: <4939133E.2000701@FreeBSD.org> Bruce M. Simpson wrote: > ... > Performance seems quite slow, it could probably benefit from being > ported to use UBLIO as ntfs-3g for FreeBSD has. > > I'm going to leave this thing for others to play with, this was a 20 > minute bunk-off from other work. It shouldn't take much effort to > create a port around it. P.S. Ale's patch to use libublio for fusefs-ntfs is here, if anyone picks up on ext2fuse before I do: http://people.freebsd.org/~alepulver/fusefs-ntfs.diff This contains the necessary diffs for UBLIO. cheers BMS From bms at incunabulum.net Fri Dec 5 03:41:34 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri Dec 5 03:41:41 2008 Subject: Issues with mount(8) and FUSE in 7.1-PRERELEASE Message-ID: <4939136C.3000500@incunabulum.net> Hi all, I noticed when porting ext2fuse to run on 7.1-PRERELEASE, that the port sysutils/fusefs-ntfs needs some additional steps in order to mount user-space FUSE filesystems on startup. These steps weren't necessary in 6.x. It seems mount(8) can't deal with new mount binaries unless it has been explicitly built with support for them; please see /usr/local/share/doc/ntfs-3g/README.FreeBSD for more info where the problem is described in more detail. There is a comment which reads as follows in the mount.c code: /* XXX: We need to get away from implementing external mount * programs for every filesystem, and move towards having * each filesystem properly implement the nmount() system call. */ Unfortunately, this assumption seems to be grounded in a very restricted picture of the filesystem world. FUSE is clearly something which doesn't fit a limited use case of "let's only mount stuff which the FreeBSD base system supports", and, to my mind, is applicable to the vast majority of FreeBSD desktop users. This seems like an inflexible approach, and I'm curious why this design choice persists. I understand the technical arguments for nmount() and I do support them, but not at the expense of functional utility. How can we make this work for users out-of-the-box? thanks, BMS P.S. There is a patch by Ale Pulver to change some of this hardcoded logic, however it doesn't seem complete: http://people.freebsd.org/~alepulver/current-7.0-mount.diff From bseklecki at collaborativefusion.com Fri Dec 5 04:34:23 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Fri Dec 5 04:34:30 2008 Subject: lagg(4) and failover In-Reply-To: <20080812120307.GD64458@server.vk2pj.dyndns.org> References: <20080812120307.GD64458@server.vk2pj.dyndns.org> Message-ID: <1228480461.2805.469.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Tue, 2008-08-12 at 22:03 +1000, Peter Jeremy wrote: > >Thats unfortunate... > > I tend to agree. > > >bonding in Linux is capable of doing this and solaris too. > Well ... name a price for the development; HA L1/L2 is a feature the community would gladly sponsor the development of. Also, Peter, you should put a page up on the FreeBSD wiki with some of those multi-catalyst LACP IOS config examples. Maybe write an article for BSDMag. I always just counted that idea out (LACP against two switches) since LACP doesn't have any inter-component transport protocol a la pfsync(4). But if the backplanes of Cat 37xx`s can be merged at a lower level, then then yea, fuck. Lets have it. ~BAS P.S., in my experience, system level redundancy/HA with a load balancer is almost always less expensive then excessive component-level redundancy/ha (RAID Disk, RAID RAM, Dual Power Supplies, Dual Backplanes...) > It shouldn't be too difficult to create something that behaves > functionally similarly to Slowaris ipmpd (and with marginally more > effort, you could create something that could be configured to behave > sensibly). -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081205/83e38aaf/attachment.pgp From frode at nordahl.net Fri Dec 5 11:11:06 2008 From: frode at nordahl.net (Frode Nordahl) Date: Fri Dec 5 11:11:14 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: <576BB990-78D8-4CE8-9660-55EB989EE3BA@nordahl.net> References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> <20081203194348.GB2401@deviant.kiev.zoral.com.ua> <8A6A8FA5-07A6-4A12-B9AD-6E77E534CED7@nordahl.net> <20081204120736.GC2038@deviant.kiev.zoral.com.ua> <576BB990-78D8-4CE8-9660-55EB989EE3BA@nordahl.net> Message-ID: On 4. des.. 2008, at 13.20, Frode Nordahl wrote: > On 4. des.. 2008, at 13.07, Kostik Belousov wrote: > >> On Thu, Dec 04, 2008 at 08:12:45AM +0100, Frode Nordahl wrote: >>> Got it! >>> >>> panic: dqget: free dquot isn't dq=0xffffff00b3d27000 >>> (kgdb) p/x *(struct dquot *)0xffffff00b3d27000 >>> $1 = {dq_hash = {le_next = 0x0, le_prev = 0xffffff010b9da700}, >>> dq_freelist = { >>> tqe_next = 0xffffff0055e2de00, tqe_prev = 0xffffffff80b03710}, >>> dq_lock = { >>> lock_object = {lo_name = 0xffffffff8088c21c, lo_type = >>> 0xffffffff8088c21c, >>> lo_flags = 0x1030000, lo_witness_data = {lod_list = {stqe_next >>> = 0x0}, >>> lod_witness = 0x0}}, mtx_lock = 0x4, mtx_recurse = 0x0}, >>> dq_flags = 0xc, dq_type = 0x0, dq_cnt = 0x0, dq_id = 0x16a37d, >>> dq_ump = 0xffffff00038e1600, dq_dqb = {dqb_bhardlimit = 0x0, >>> dqb_bsoftlimit = 0x0, dqb_curblocks = 0x0, dqb_ihardlimit = 0x0, >>> dqb_isoftlimit = 0x0, dqb_curinodes = 0x1, dqb_btime = 0x493ef2b5, >>> dqb_itime = 0x493ef2b5}} >>> >>> Let me know if I can provide any more information! >>> >>> Updated the crashinfo archive you got an URL to yesterday if you >>> want >>> to poke around yourself. >> >> Please, try the patch below, it should fix a race I see. Quite >> possible, >> this is what you tripped over. > > Thanks! I will apply the patch and retry the steps that lead to the > panic! Good news! I have run through two and have started on the third iteration of the test that lead to the panic without your patch, and no panic so far! I will let it run through the weekend, it prooves usefull as a burn-in- test as well :-) Will this patch make it into 7.1-RELEASE? -- Frode Nordahl From kostikbel at gmail.com Fri Dec 5 11:59:32 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Dec 5 11:59:39 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> <20081203194348.GB2401@deviant.kiev.zoral.com.ua> <8A6A8FA5-07A6-4A12-B9AD-6E77E534CED7@nordahl.net> <20081204120736.GC2038@deviant.kiev.zoral.com.ua> <576BB990-78D8-4CE8-9660-55EB989EE3BA@nordahl.net> Message-ID: <20081205195922.GP2038@deviant.kiev.zoral.com.ua> On Fri, Dec 05, 2008 at 08:11:02PM +0100, Frode Nordahl wrote: > > On 4. des.. 2008, at 13.20, Frode Nordahl wrote: > > >On 4. des.. 2008, at 13.07, Kostik Belousov wrote: > > > >>On Thu, Dec 04, 2008 at 08:12:45AM +0100, Frode Nordahl wrote: > >>>Got it! > >>> > >>>panic: dqget: free dquot isn't dq=0xffffff00b3d27000 > >>>(kgdb) p/x *(struct dquot *)0xffffff00b3d27000 > >>>$1 = {dq_hash = {le_next = 0x0, le_prev = 0xffffff010b9da700}, > >>>dq_freelist = { > >>> tqe_next = 0xffffff0055e2de00, tqe_prev = 0xffffffff80b03710}, > >>>dq_lock = { > >>> lock_object = {lo_name = 0xffffffff8088c21c, lo_type = > >>>0xffffffff8088c21c, > >>> lo_flags = 0x1030000, lo_witness_data = {lod_list = {stqe_next > >>>= 0x0}, > >>> lod_witness = 0x0}}, mtx_lock = 0x4, mtx_recurse = 0x0}, > >>>dq_flags = 0xc, dq_type = 0x0, dq_cnt = 0x0, dq_id = 0x16a37d, > >>>dq_ump = 0xffffff00038e1600, dq_dqb = {dqb_bhardlimit = 0x0, > >>> dqb_bsoftlimit = 0x0, dqb_curblocks = 0x0, dqb_ihardlimit = 0x0, > >>> dqb_isoftlimit = 0x0, dqb_curinodes = 0x1, dqb_btime = 0x493ef2b5, > >>> dqb_itime = 0x493ef2b5}} > >>> > >>>Let me know if I can provide any more information! > >>> > >>>Updated the crashinfo archive you got an URL to yesterday if you > >>>want > >>>to poke around yourself. > >> > >>Please, try the patch below, it should fix a race I see. Quite > >>possible, > >>this is what you tripped over. > > > >Thanks! I will apply the patch and retry the steps that lead to the > >panic! > > > Good news! I have run through two and have started on the third > iteration of the test that lead to the panic without your patch, and > no panic so far! > > I will let it run through the weekend, it prooves usefull as a burn-in- > test as well :-) > > Will this patch make it into 7.1-RELEASE? There is a possibility. Please inform me about the weekend burn-test results. If results are encouranging, I am almost sure that I can squeeze it into the release. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081205/2e986a0a/attachment.pgp From delphij at delphij.net Fri Dec 5 13:40:01 2008 From: delphij at delphij.net (Xin LI) Date: Fri Dec 5 13:40:09 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4936F8C4.6090006@ec-marseille.fr> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> Message-ID: <49399FA6.3060108@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, I have committed the patch as r185653 (stable/7) and r185654 (releng/7.1) so new build would get this issue fixed. Thanks goes to David who gave review for the changes and all who tested the earlier patches. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk5n6YACgkQi+vbBBjt66BToACfTp+1hqno30HTpNfcvMn7SpAF 6XoAn1St590CMK2Lz9jLwlnTLDKGW8cV =/FVN -----END PGP SIGNATURE----- From healthy-wealthy-tea at freemail.lt Sat Dec 6 07:42:34 2008 From: healthy-wealthy-tea at freemail.lt (healthy-wealthy-tea freebsd-stable) Date: Sat Dec 6 07:42:46 2008 Subject: Your friend healthy-wealthy-tea freebsd-stable has recommended this great product from Green Tea & Me Message-ID: <3oUmtk-1L8z6X2yfm-0005VX@infong660.perfora.net> Hi freebsd-stable! Your friend, healthy-wealthy-tea freebsd-stable, thought that you would be interested in Matcha from Green Tea & Me. healthy-wealthy-tea freebsd-stable sent a note saying: Amazing News, Get Paid, Look Smart And Stay Healthy! Hi Friend, Here's how it works... First, we detoxifies your body. Second, we burn your unwanted fats. Thus, we make all your friends jealous because you will actually lose weight the first day. And Third, you'll be paid the moment you start spreading the good news for others to try themselves with this extraordinary product. Visit this very important link below now!. http://123redirect.com/healthy-and-wealthy-tea So Goodluck, Look Good And Be Healthy, Associates http://123redirect.com/healthy-and-wealthy-tea Online Promoter P.S. Dr. Miller's Iaso Tea - formulated by Dr. Bill Miller (Bs.Ms.Ph.D. Nutritional Science) of Tennessee, USA - is a unique herbal blend of safe, all-natural ingredients designed to gently cleanse the digestive tract and detoxify the whole body. Iaso Tea is like a white tea, a green tea, a weight loss tea, and a great-tasting herbal tea - all wrapped up in each unbleached tea bag. But, most of all, Dr. Miller's Iaso Tea is a healing tea. Remarkable things happen when you drink Iaso Tea every day. It is gentle, yet surprisingly powerful as a colon cleanse, parasite cleanse, Candida cleanse, blood purifier, and whole body detoxifier. It acts like a general health tonic and a home remedy for many ailments like the ones mentioned below. Some want to call it a "miracle tea", but this cleansing and slimming tea is really just a special blend of high-quality herbs, tested and refined over time, which produce fast and effective results that no imitator has been able to copy. ------------------------------ Email here: healthy-wealthy-tea@freemail.lt and add "Not interested" ---------------------------------------------------------------------------------------- To view the product, click on the link below or copy and paste the link into your web browser: http://www.greenteame.com/store/index.php?main_page=product_info&products_id=1 Regards, Green Tea & Me http://www.greenteame.com/store/ ----- IMPORTANT: For your protection and to prevent malicious use, all emails sent via this web site are logged and the contents recorded and available to the store owner. If you feel that you have received this email in error, please send an email to customersupport@greenteame.com From peterjeremy at optushome.com.au Sat Dec 6 13:03:42 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Dec 6 13:03:50 2008 Subject: lagg(4) and failover In-Reply-To: <1228480461.2805.469.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> References: <20080812120307.GD64458@server.vk2pj.dyndns.org> <1228480461.2805.469.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <20081206210316.GP58682@server.vk2pj.dyndns.org> On 2008-Dec-05 07:34:21 -0500, "Brian A. Seklecki" wrote: >Well ... name a price for the development; HA L1/L2 is a feature the >community would gladly sponsor the development of. net/ifstated covers at least some of this. >Also, Peter, you should put a page up on the FreeBSD wiki with some of >those multi-catalyst LACP IOS config examples. This appears to be aimed at Pete French - I'm using stacked Alcatel-Lucent OS6850's which appear as single switches to LACP. >P.S., in my experience, system level redundancy/HA with a load balancer >is almost always less expensive then excessive component-level >redundancy/ha (RAID Disk, RAID RAM, Dual Power Supplies, Dual >Backplanes...) That's a different topic, but yes, you should evaluate your requirements at a system level, rather than just making every component HA. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081206/dab51cc2/attachment.pgp From csjp at freebsd.org Sat Dec 6 13:41:10 2008 From: csjp at freebsd.org (Christian Peron) Date: Sat Dec 6 13:41:17 2008 Subject: rtfree: 0xffffff00013797c0 has 1 refs In-Reply-To: <0807767D2D53E649827BC55A3A53B06709C6C04BFE@exchange.ct.esn.org.za> References: <0807767D2D53E649827BC55A3A53B06709C6C04BFE@exchange.ct.esn.org.za> Message-ID: <20081206211344.GA60861@jnz.sqrt.ca> I have just fixed a similar (possibly the same) issue in -CURRENT. Please try the patch at: http://people.freebsd.org/~csjp/if_ether.1228494489.diff (Fetch it into /usr/src/sys/netinet and apply there). Let me know if this solves your problem, if it does I will try to get it in for the release. Thanks! On Fri, Dec 05, 2008 at 07:53:37AM +0200, David Peall wrote: > Hi > > I'm getting some strange messages: > > Dec 5 07:49:19 jonny kernel: rtfree: 0xffffff0001379d90 has 1 refs > Dec 5 07:49:19 jonny kernel: rtfree: 0xffffff000a1784d8 has 1 refs > Dec 5 07:49:28 jonny kernel: rtfree: 0xffffff000198a7c0 has 1 refs > Dec 5 07:49:31 jonny kernel: rtfree: 0xffffff00013797c0 has 1 refs > Dec 5 07:49:35 jonny kernel: rtfree: 0xffffff00013797c0 has 1 refs > Dec 5 07:49:37 jonny kernel: rtfree: 0xffffff0001c233e0 has 1 refs > Dec 5 07:49:43 jonny kernel: rtfree: 0xffffff00013797c0 has 1 refs > Dec 5 07:49:47 jonny kernel: rtfree: 0xffffff0001b3bc98 has 1 refs > > I've tried google but couldn't find anything usefull. > > Uname -a > FreeBSD jonny.esn.org.za 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Nov 26 08:03:32 UTC 2008 root@:/usr/obj/usr/src/sys/GENERIC amd64 > > Is there some other output that would be useful please let me know. > > -- > David Peall :: IT Manager > e-Schools' Network :: http://www.esn.org.za/ > Phone +27 (021) 674-9140 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From lists at aquezada.com Sat Dec 6 19:45:12 2008 From: lists at aquezada.com (Julian C. Dunn) Date: Sat Dec 6 19:45:18 2008 Subject: bsnmpd hrProcessorLoad results (still) incorrect Message-ID: <1228620544.2949.3.camel@jupiter.acf.aquezada.com> After seeing that my CPU utilization is constantly "100%" according to bsnmpd, I Googled and found this thread: http://kerneltrap.org/mailarchive/freebsd-current/2008/5/7/1747854/thread It seems to have gone nowhere. Any idea if a fix is in the works? - Julian -- [ Julian C. Dunn * Sorry, I'm ] [ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ] [ gopher://sdf.lonestar.org/11/users/keymaker * compliant! ] [ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ] From bms at incunabulum.net Sat Dec 6 22:18:33 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Sat Dec 6 22:18:41 2008 Subject: ext2 inode size patch - RE: PR kern/124621 In-Reply-To: <8cb6106e0812040902g69ec2f84t814c2f2b5cdb33f6@mail.gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <8cb6106e0812040902g69ec2f84t814c2f2b5cdb33f6@mail.gmail.com> Message-ID: <493B6AB6.2040704@incunabulum.net> FYI: The ext2 IFS driver for Windows v1.11a also appears to have the inode size issue: http://www.fs-driver.org/ I was not able to mount an ext2 filesystem with 256 byte inode size using this driver. Its installer will see that the filesystem exists, that it's ext2, but whenever you try to mount, you get nothing -- a very similar failure mode to the FreeBSD ext2fs driver. Again, it sounds like the author is actively maintaining it, so it might be worth contacting him to pool resources. cheers, BMS From danielgonzalesn at gmail.com Sun Dec 7 11:36:38 2008 From: danielgonzalesn at gmail.com (DanielX) Date: Sun Dec 7 11:36:45 2008 Subject: Error install FreeBSD 7.0 Message-ID: <993c11f30812071104x3751b4a3g1ba39417eda68a12@mail.gmail.com> hello, I had problems when trying to install FreeBSD 7.0 (amd and i386) to my dv2125nr HP Pavilion laptop and other HP Pavilion dv9700t laptop comes this error, install succeed, but I doubt it comes out that error: loading required module `pci` ACPI autoload failed - no search file or directory int=00000006 en=000000000 efl=00010882 eip=00460da8 ?.. BTX halted Thank you -- DanielX H. Gonzales Nu?ez Est. Ing. Sistemas Uni. Privada del Norte From david at esn.org.za Sun Dec 7 12:24:04 2008 From: david at esn.org.za (David Peall) Date: Sun Dec 7 12:24:12 2008 Subject: rtfree: 0xffffff00013797c0 has 1 refs In-Reply-To: <20081206211344.GA60861@jnz.sqrt.ca> References: <0807767D2D53E649827BC55A3A53B06709C6C04BFE@exchange.ct.esn.org.za> <20081206211344.GA60861@jnz.sqrt.ca> Message-ID: <0807767D2D53E649827BC55A3A53B06709C6C0DD9C@exchange.ct.esn.org.za> > -----Original Message----- > From: Christian Peron [mailto:csjp@freebsd.org] > Sent: 06 December 2008 11:14 PM > To: David Peall > Cc: 'freebsd-stable@freebsd.org' > Subject: Re: rtfree: 0xffffff00013797c0 has 1 refs > > I have just fixed a similar (possibly the same) issue in -CURRENT. > > Please try the patch at: > > http://people.freebsd.org/~csjp/if_ether.1228494489.diff > > (Fetch it into /usr/src/sys/netinet and apply there). > > Let me know if this solves your problem, if it does I will try to get > it > in for the release. Patch is applied, messages seem to have stopped I was getting every few seconds. I will keep an eye on it and let you know if anything pops up. Thanks! -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 From frode at nordahl.net Mon Dec 8 00:50:19 2008 From: frode at nordahl.net (Frode Nordahl) Date: Mon Dec 8 00:50:26 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: <20081205195922.GP2038@deviant.kiev.zoral.com.ua> References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> <20081203173939.GA2401@deviant.kiev.zoral.com.ua> <20081203194348.GB2401@deviant.kiev.zoral.com.ua> <8A6A8FA5-07A6-4A12-B9AD-6E77E534CED7@nordahl.net> <20081204120736.GC2038@deviant.kiev.zoral.com.ua> <576BB990-78D8-4CE8-9660-55EB989EE3BA@nordahl.net> <20081205195922.GP2038@deviant.kiev.zoral.com.ua> Message-ID: On 5. des.. 2008, at 20.59, Kostik Belousov wrote: > On Fri, Dec 05, 2008 at 08:11:02PM +0100, Frode Nordahl wrote: >> >> On 4. des.. 2008, at 13.20, Frode Nordahl wrote: >> >>> On 4. des.. 2008, at 13.07, Kostik Belousov wrote: >>> >>>> On Thu, Dec 04, 2008 at 08:12:45AM +0100, Frode Nordahl wrote: >>>>> Got it! >>>>> >>>>> panic: dqget: free dquot isn't dq=0xffffff00b3d27000 >>>>> (kgdb) p/x *(struct dquot *)0xffffff00b3d27000 >>>>> $1 = {dq_hash = {le_next = 0x0, le_prev = 0xffffff010b9da700}, >>>>> dq_freelist = { >>>>> tqe_next = 0xffffff0055e2de00, tqe_prev = 0xffffffff80b03710}, >>>>> dq_lock = { >>>>> lock_object = {lo_name = 0xffffffff8088c21c, lo_type = >>>>> 0xffffffff8088c21c, >>>>> lo_flags = 0x1030000, lo_witness_data = {lod_list = {stqe_next >>>>> = 0x0}, >>>>> lod_witness = 0x0}}, mtx_lock = 0x4, mtx_recurse = 0x0}, >>>>> dq_flags = 0xc, dq_type = 0x0, dq_cnt = 0x0, dq_id = 0x16a37d, >>>>> dq_ump = 0xffffff00038e1600, dq_dqb = {dqb_bhardlimit = 0x0, >>>>> dqb_bsoftlimit = 0x0, dqb_curblocks = 0x0, dqb_ihardlimit = 0x0, >>>>> dqb_isoftlimit = 0x0, dqb_curinodes = 0x1, dqb_btime = 0x493ef2b5, >>>>> dqb_itime = 0x493ef2b5}} >>>>> >>>>> Let me know if I can provide any more information! >>>>> >>>>> Updated the crashinfo archive you got an URL to yesterday if you >>>>> want >>>>> to poke around yourself. >>>> >>>> Please, try the patch below, it should fix a race I see. Quite >>>> possible, >>>> this is what you tripped over. >>> >>> Thanks! I will apply the patch and retry the steps that lead to the >>> panic! >> >> >> Good news! I have run through two and have started on the third >> iteration of the test that lead to the panic without your patch, and >> no panic so far! >> >> I will let it run through the weekend, it prooves usefull as a burn- >> in- >> test as well :-) >> >> Will this patch make it into 7.1-RELEASE? > > There is a possibility. Please inform me about the weekend burn-test > results. If results are encouranging, I am almost sure that I can > squeeze it into the release. The test has run trough the weekend without any incidents! I really hope this patch will make it into the release. Thank you for your help solving this issue! -- Frode Nordahl From bms at FreeBSD.org Mon Dec 8 01:53:23 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Dec 8 01:53:42 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <4939133E.2000701@FreeBSD.org> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> Message-ID: <493CEE90.7050104@FreeBSD.org> I have rolled a port for ext2fuse: http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar I look forward to your feedback. thanks, BMS From slayer at yandex-team.ru Mon Dec 8 01:53:34 2008 From: slayer at yandex-team.ru (Oleg Gorokhov) Date: Mon Dec 8 01:53:43 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <49399FA6.3060108@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> Message-ID: <493CE8F7.5010204@yandex-team.ru> This patch committed fixes the issue reported earlier with interruptions but there is one more problem discussed here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-11/msg00144.html We also have observed similar bad behavior for network (especially ssl-based) operations: imaps, ssh and smtp starttls connections - all of them were failed to establish after a day of successful operation: Dec 7 23:32:41 imaps[62530]: accepted connection Dec 7 23:32:41 imaps[62530]: SSL_accept() incomplete -> wait Dec 7 23:32:41 imaps[62530]: wrong version number in SSL_accept() -> fail Dec 7 23:32:41 master[3930]: process 62530 exited, status 75 Dec 7 23:32:41 master[3930]: service imaps pid 62530 in BUSY state: terminated abnormally Dec 7 23:39:26 imaps[91999]: SSL_accept() incomplete -> wait Dec 7 23:39:26 imaps[91999]: decryption failed or bad record mac in SSL_accept() -> fail Dec 7 23:32:44 lmtp[77715]: [lmtpd] STARTTLS failed: gamgee.yandex.ru [77.88.19.54] We have reverted back to stable before the last bce driver update was commited to releng branch and now hope that the system should run as expected. Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FYI, I have committed the patch as r185653 (stable/7) and r185654 > (releng/7.1) so new build would get this issue fixed. Thanks goes to > David who gave review for the changes and all who tested the earlier > patches. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAkk5n6YACgkQi+vbBBjt66BToACfTp+1hqno30HTpNfcvMn7SpAF > 6XoAn1St590CMK2Lz9jLwlnTLDKGW8cV > =/FVN > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Oleg Gorokhov System Administrator, Yandex Tel.: +7 (495) 739-7000 (+7166) From ari at ish.com.au Mon Dec 8 01:57:42 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Mon Dec 8 01:57:49 2008 Subject: visibility of release process Message-ID: I've resisted sending this email for a while since I really don't want to start a bikeshed nor a flame. However there comes a time to express my thoughts over the lack of visibility of the release process for FreeBSD 7.1. Here are the resources I am aware of: * release timeline [1]. This page makes no mention of beta 2 which is now some weeks old, so I assume the page is not actively used as a communication tool for the status of the release. * this list [2]. Although betas are announced here, there is no information about what is happening next. * subversion. Without checking out the whole repository, it is a little hard to use this as a news source and emails to the commit list still look more like cvs than svn so it is a bit hard to see which branch commits are going to. [3] * the bug tracker. Let's just say that FreeBSD's bug tracker is fairly primitive and 'target release' is not an option. I'd like to make several suggestions which could improve the transparency of the release process: 1. Short term fix: re could make a progress announcement on the appropriate lists every 14 days during the release process. Just a short summary of URLs pointing to the bug tracker. 2. Some web based friendly end-user visibility on the commit process, per branch. People can see what is going in and being fixed, but not what is left outstanding. Fisheye is an option because it costs nothing except the small load on the svn server. 3. Improvements to the bug tracker. Personally I'd love to see something like Jira used [4] with all the sophistication of workflow, release notes, voting for bugs, etc, etc. I'm happy to help with 2 and/or 3 in terms of contribution of my time and experience. Cheers Ari Maniatis [1] http://www.freebsd.org/releases/7.1R/schedule.html [2] That is FreeBSD-stable [3] I've also made an attempt to have Atlassian use Fisheye to produce an friendly overview of the repository, however I need to get permission from FreeBSD for this to happen before Atlassian will go ahead and index the whole svn repository. I've been unable to get anyone to respond to my requests in that regard. The result might look a bit like this: http://fisheye6.atlassian.com/ [4] Disclaimer: I am an Atlassian partner and like their products, but stand to gain nothing by the decision FreeBSD core make, I just think it is the best product for FreeBSD's requirements and it works well over at Apache. --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From avg at icyb.net.ua Mon Dec 8 03:51:31 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Dec 8 03:51:39 2008 Subject: Attempt to write outside dump device boundaries Message-ID: <493D0A3F.5060705@icyb.net.ua> System: FreeBSD 7.1-PRERELEASE r185725 amd64 Peculiarities: ZFS, GPART There is 4GB of RAM and 4GB swap/dump partition. The partition is typical swap partition only created via GPART. minidumps are enabled. I had a crash recently and here's a message from it: Dec 6 10:23:17 odyssey kernel: Uptime: 7d20h12m51s Dec 6 10:23:17 odyssey kernel: Physical memory: 4009 MB Dec 6 10:23:17 odyssey kernel: Dumping 2110 MB: 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 91 1 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15Attempt to write outside dump device boundaries. Dec 6 10:23:17 odyssey kernel: Dec 6 10:23:17 odyssey kernel: ** DUMP FAILED (ERROR 6) ** Dec 6 10:23:17 odyssey kernel: Automatic reboot in 15 seconds - press a key on the console to abort I guess the large size of the dump is because of the ZFS but I wonder why enough room for the dump could not be found. -- Andriy Gapon From avg at icyb.net.ua Mon Dec 8 03:52:13 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Dec 8 03:52:20 2008 Subject: rc.firewall: default loopback rules are set up even for custom file In-Reply-To: <4937B194.1020606@icyb.net.ua> References: <4937B194.1020606@icyb.net.ua> Message-ID: <493D0A6A.7060102@icyb.net.ua> on 04/12/2008 12:31 Andriy Gapon said the following: > I've just realized that I see in releng/7 something that I did not see > in releng/6 - even if I use a file with custom rules in firewall_type I > still get default loopback rules installed. > I think that this is not correct, I am using custom rules exactly > because I want to control *everything* (e.g. all deny rules come with > log logamount xxx). > Comments? -- Andriy Gapon From ivoras at freebsd.org Mon Dec 8 04:36:17 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Dec 8 04:36:25 2008 Subject: rc.firewall: default loopback rules are set up even for custom file In-Reply-To: <493D0A6A.7060102@icyb.net.ua> References: <4937B194.1020606@icyb.net.ua> <493D0A6A.7060102@icyb.net.ua> Message-ID: Andriy Gapon wrote: > on 04/12/2008 12:31 Andriy Gapon said the following: >> I've just realized that I see in releng/7 something that I did not see >> in releng/6 - even if I use a file with custom rules in firewall_type I >> still get default loopback rules installed. >> I think that this is not correct, I am using custom rules exactly >> because I want to control *everything* (e.g. all deny rules come with >> log logamount xxx). >> > > Comments? I agree with you - I also see them, and I'd rather not :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081208/8fea302b/signature.pgp From bseklecki at collaborativefusion.com Mon Dec 8 06:36:26 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Mon Dec 8 06:36:50 2008 Subject: lagg(4) and failover In-Reply-To: <20081206210316.GP58682@server.vk2pj.dyndns.org> References: <20080812120307.GD64458@server.vk2pj.dyndns.org> <1228480461.2805.469.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20081206210316.GP58682@server.vk2pj.dyndns.org> Message-ID: <1228746983.2805.567.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Sun, 2008-12-07 at 08:03 +1100, Peter Jeremy wrote: > On 2008-Dec-05 07:34:21 -0500, "Brian A. Seklecki" > wrote: > >Well ... name a price for the development; HA L1/L2 is a feature the > >community would gladly sponsor the development of. > > net/ifstated covers at least some of this. I was thinking something like a heartbeat protocol could work well w/o LACP hacking on mid-range switches. I think that's how Dell does it with the RHEL crap for Broadcom. Send multicast packets on both an active/standby link. If either node discontinues to see the others packets, some admin-configurable logic promotes (Metric/Bias/Weighting). ~BAS -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081208/ecad0f77/attachment.pgp From bms at incunabulum.net Mon Dec 8 06:47:26 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Dec 8 06:47:34 2008 Subject: Experience with RDX removable backup drives? Message-ID: <493D337B.1020204@incunabulum.net> Are these any good? Has anyone tried them with FreeBSD and/or bacula? For small office, these look like where the price point is for backups... cheers BMS From kensmith at cse.Buffalo.EDU Mon Dec 8 08:25:25 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Mon Dec 8 08:25:32 2008 Subject: visibility of release process In-Reply-To: References: Message-ID: <1228753517.56532.25.camel@bauer.cse.buffalo.edu> On Mon, 2008-12-08 at 20:57 +1100, Aristedes Maniatis wrote: > I've resisted sending this email for a while since I really don't want > to start a bikeshed nor a flame. However there comes a time to express > my thoughts over the lack of visibility of the release process for > FreeBSD 7.1. Here are the resources I am aware of: [ Readers' Digest Version: Known problem. Unfortunately very slowly being worked on... ] Bottom line is my communication skills suck and of the bazillion other things I could do with my time these sorts of housekeeping chores wind up at a low enough priority they don't get done. But as you and others have made clear the priority needs to get raised and I need to deal with it. That's the part being worked on. > I'd like to make several suggestions which could improve the > transparency of the release process: > > 1. Short term fix: re could make a progress announcement on the > appropriate lists every 14 days during the release process. Just a > short summary of URLs pointing to the bug tracker. That's what I'll be working on fixing short-term. Weekly status reports here. One coming tomorrow (not coincidentally likely to include 7.1-RC1 is ready, that's why its not coming today; if you look around you can probably find it but a few misc. tidbits aren't ready yet). > 2. Some web based friendly end-user visibility on the commit process, > per branch. People can see what is going in and being fixed, but not > what is left outstanding. Fisheye is an option because it costs > nothing except the small load on the svn server. > > 3. Improvements to the bug tracker. Personally I'd love to see > something like Jira used [4] with all the sophistication of workflow, > release notes, voting for bugs, etc, etc. Those aren't really something I'd be likely to address any time in the near future mostly because there are other folks around who are involved in those areas. They both look like they require hooks into the guts of various systems I'm more than happy other folks are much more involved in. So comments on those likely need to come from someone else(s). -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081208/4fcf4e3d/attachment.pgp From peterjeremy at optushome.com.au Mon Dec 8 10:21:16 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Dec 8 10:21:23 2008 Subject: visibility of release process In-Reply-To: References: Message-ID: <20081208182112.GW58682@server.vk2pj.dyndns.org> On 2008-Dec-08 20:57:37 +1100, Aristedes Maniatis wrote: >* subversion. Without checking out the whole repository, it is a >little hard to use this as a news source and emails to the commit list >still look more like cvs than svn so it is a bit hard to see which >branch commits are going to. [3] I'm not sure what you want here. The branch is clearly indicated in both the subject and body of commit messages. What do you mean as "news source"? Commits are inherently low level and it's difficult to see how a commit could be massaged into some sort of press release without a fair amount of meta information in the commit log. >* the bug tracker. Let's just say that FreeBSD's bug tracker is fairly >primitive and 'target release' is not an option. Agreed. This is an issue that comes up regularly but I don't believe a solution has been identified. I suspect one of the requirements would be that it be FOSS. >2. Some web based friendly end-user visibility on the commit process, >per branch. I presume you're aware of svn.freebsd.org. > People can see what is going in and being fixed, but not >what is left outstanding. If you mean open PRs, lists are regularly reported to various mailing lists and can be accessed via http://www.freebsd.org/cgi/query-pr.cgi Better integration of the PR and commit process might be nice but I'm not sure if it's practical with gnats. >[3] I've also made an attempt to have Atlassian use Fisheye to >produce an friendly overview of the repository, I've had a look at several of the fisheye sites and am not sure what it would buy the Project, other than some pretty graphs. I don't see how this is any more "friendly" than svn.freebsd.org. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081208/0b103437/attachment.pgp From mikej at rogers.com Mon Dec 8 11:46:08 2008 From: mikej at rogers.com (Mike Jakubik) Date: Mon Dec 8 11:46:16 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <493CE8F7.5010204@yandex-team.ru> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> Message-ID: <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> On Mon, December 8, 2008 4:29 am, Oleg Gorokhov wrote: > This patch committed fixes the issue reported earlier with interruptions > but there is one more problem discussed here: > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-11/msg00144.html > > We also have observed similar bad behavior for network (especially > ssl-based) operations: imaps, ssh and smtp starttls connections - all of > them were failed to establish after a day of successful operation: > I wonder if my problem is related to this. I have a java chat service application that starts dropping connections after about 4 days of uptime. There is nothing in the applications logs, and i know this works fine on Linux. Will try updating to the latest bce patch tonight to see if it helps. From ivoras at freebsd.org Mon Dec 8 12:13:15 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Dec 8 12:13:22 2008 Subject: visibility of release process In-Reply-To: <1228753517.56532.25.camel@bauer.cse.buffalo.edu> References: <1228753517.56532.25.camel@bauer.cse.buffalo.edu> Message-ID: Ken Smith wrote: > On Mon, 2008-12-08 at 20:57 +1100, Aristedes Maniatis wrote: >> I've resisted sending this email for a while since I really don't want >> to start a bikeshed nor a flame. However there comes a time to express >> my thoughts over the lack of visibility of the release process for >> FreeBSD 7.1. Here are the resources I am aware of: > > [ Readers' Digest Version: Known problem. Unfortunately very slowly > being worked on... ] > > Bottom line is my communication skills suck and of the bazillion other > things I could do with my time these sorts of housekeeping chores wind > up at a low enough priority they don't get done. But as you and others > have made clear the priority needs to get raised and I need to deal with > it. That's the part being worked on. Hmm, would something twitter-like + a cron-job reminding you to write something help? :) . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081208/e71b9fc9/signature.pgp From delphij at delphij.net Mon Dec 8 14:12:43 2008 From: delphij at delphij.net (Xin LI) Date: Mon Dec 8 14:12:52 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> Message-ID: <493D9BC6.8050902@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Jakubik wrote: > On Mon, December 8, 2008 4:29 am, Oleg Gorokhov wrote: >> This patch committed fixes the issue reported earlier with interruptions >> but there is one more problem discussed here: >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-11/msg00144.html >> >> We also have observed similar bad behavior for network (especially >> ssl-based) operations: imaps, ssh and smtp starttls connections - all of >> them were failed to establish after a day of successful operation: >> > > I wonder if my problem is related to this. I have a java chat service > application that starts dropping connections after about 4 days of uptime. > There is nothing in the applications logs, and i know this works fine on > Linux. Will try updating to the latest bce patch tonight to see if it > helps. Which version are you currently using? My previous commit only fixes the excessive interrupt issue, I think this could be a different problem, I'm taking a look at the code to see if I can have something for you. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk9m8UACgkQi+vbBBjt66DAEQCeNHjriIsvmEB252283KhW2gvt 2WcAoKM5uQ30+mLJPgON+XdTG6qoH1uX =tGel -----END PGP SIGNATURE----- From mikej at rogers.com Mon Dec 8 14:22:27 2008 From: mikej at rogers.com (Mike Jakubik) Date: Mon Dec 8 14:22:35 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <493D9BC6.8050902@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> <493D9BC6.8050902@delphij.net> Message-ID: <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> On Mon, December 8, 2008 5:12 pm, Xin LI wrote: > Which version are you currently using? My previous commit only fixes > the excessive interrupt issue, I think this could be a different > problem, I'm taking a look at the code to see if I can have something > for you. I was running on the version just prior to the latest interrupt commit. I have now updated to the one with the interrupt fix. Will let you know if things change. Thank You. From ubm.freebsd at googlemail.com Mon Dec 8 14:40:50 2008 From: ubm.freebsd at googlemail.com (Marc UBM Bocklet) Date: Mon Dec 8 14:40:57 2008 Subject: Promise TX4302 working with -stable? Message-ID: <20081208231633.89943a49.ubm.freebsd@gmail.com> Hiho! :-) I'm planning to buy a Promise TX4302. The idea is to just plug in some disks via esata and then put zfs on them. Anybody got some experience with the TX4302? Googling didn't really turn up much, so I guess the controller "just works"? :-) Greetings, Marc From bf2006a at yahoo.com Mon Dec 8 16:32:47 2008 From: bf2006a at yahoo.com (bf) Date: Mon Dec 8 16:33:19 2008 Subject: visibility of release process Message-ID: <382641.82375.qm@web39103.mail.mud.yahoo.com> I'd also appreciate a little more frequent updating of the release schedule, maybe with some terse "we're waiting on this ... " notes, like there were for some past releases. I'd guess the amount of time involved in doing so would be modest. > * subversion. Without checking out the whole repository, it is a > little hard to use this as a news source and emails to the commit list > still look more like cvs than svn so it is a bit hard to see which > branch commits are going to. [3] Other than the comments that have already been made about the subject and the body of the messages, what's the matter with the other svn-src-stable-* or other svn-src-* mailing lists, some of which will focus more closely on those commits affecting the release(s)? Or, as someone suggested recently on one of the lists, something like: svn log -v -r '{2008-2-27}:HEAD' svn://svn.freebsd.org/base/stable/7/ Regards, b. From linimon at lonesome.com Mon Dec 8 18:18:18 2008 From: linimon at lonesome.com (Mark Linimon) Date: Mon Dec 8 18:18:24 2008 Subject: visibility of release process In-Reply-To: References: Message-ID: <20081209015832.GA25363@soaustin.net> On Mon, Dec 08, 2008 at 08:57:37PM +1100, Aristedes Maniatis wrote: > 3. Improvements to the bug tracker. Personally I'd love to see > something like Jira used [4] with all the sophistication of workflow, > release notes, voting for bugs, etc, etc. I have some notes for some prototyping ideas, but I've been involved in package building issues more than bugbusting issues lately. I think it's time to task-switch ... mcl From tom at samplonius.org Tue Dec 9 00:35:09 2008 From: tom at samplonius.org (Tom Samplonius) Date: Tue Dec 9 00:35:16 2008 Subject: lagg(4) and failover In-Reply-To: <1228746983.2805.567.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <11397385.9861228809480949.JavaMail.root@ly.sdf.com> ----- "Brian A. Seklecki" wrote: > On Sun, 2008-12-07 at 08:03 +1100, Peter Jeremy wrote: > > On 2008-Dec-05 07:34:21 -0500, "Brian A. Seklecki" > > wrote: > > >Well ... name a price for the development; HA L1/L2 is a feature > the > > >community would gladly sponsor the development of. > > > > net/ifstated covers at least some of this. > > I was thinking something like a heartbeat protocol could work well > w/o > LACP hacking on mid-range switches. > > I think that's how Dell does it with the RHEL crap for Broadcom. > > Send multicast packets on both an active/standby link. If either > node > discontinues to see the others packets, some admin-configurable logic > promotes (Metric/Bias/Weighting). I don't know if that is such a great idea, as that would only test the switch that you are connected to. The Linux bonding driver supports probing the default gateway. Now, it uses ARP for this (probably because the ARP who-has code is also in the kernel and easily accessible), which also not so great, as a ARP who-has is a broadcast. So if you have lots of servers on the LAN using the bonding driver, you get a lot of broadcast traffic. ICMP echo-request would be a better approach, but my take on this, is that the echo-request/reply handling code would have to be written, so this hasn't been done yet. But ultimately, gateway probing is the best, as not only does it verify the directly connected switch, but also that you can get from that switch to the outside world. lagg is ultimately a problem as a high-availability solution since most switches do not support multi-switch 802.3ad yet, and most probably never well. So you are limited to a single switch. So 802.3ad is good only for aggregation, and not for high availability. So an active-standby system with probing is the way to go for high-availability. It seems that FreeBSD has most of the components of this already. ng_one2many was a possible base for this. > ~BAS > > -- > Brian A. Seklecki > Collaborative Fusion, Inc. Tom From peterjeremy at optushome.com.au Tue Dec 9 01:02:12 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Dec 9 01:02:24 2008 Subject: lagg(4) and failover In-Reply-To: <11397385.9861228809480949.JavaMail.root@ly.sdf.com> References: <1228746983.2805.567.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <11397385.9861228809480949.JavaMail.root@ly.sdf.com> Message-ID: <20081209090208.GZ58682@server.vk2pj.dyndns.org> Please wrap your mail before 80 columns. On 2008-Dec-08 23:58:00 -0800, Tom Samplonius wrote: > The Linux bonding driver supports probing the default gateway. This is the same brokenness as Solaris IPMP. I agree that probing an external IP address (probably, but not necessarily a gateway) is the way to go but you need to be able to configure this. Otherwise you need to jump through hoops where the interfaces you are protecting is not the default route (or there are multiple independent groups of interfaces being protected). > Now, it uses ARP for this (probably because the ARP who-has code is >also in the kernel and easily accessible), which also not so great, I don't see that it's necessary to have the interface failover code in the kernel. The kernel needs hooks to allow a daemon to bind to the physical interfaces and control which one is active, but the actual code that decides how to determine which interface is active should be in userland. (Note that routing works this way). >switches do not support multi-switch 802.3ad yet, and most probably >never well. So you are limited to a single switch. So 802.3ad is >good only for aggregation, and not for high availability. Keep in mind that higher-end switches as well as stacked lower-end switches have a reasonable amount of internal redundancy so 802.3ad within one distinct components of one physical switch may be adequate for many purposes. Keep in mind that you'll still need multiple FreeBSD boxes to prevent them being a single point of failure. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081209/5a3be750/attachment.pgp From goran.lowkrantz at ismobile.com Tue Dec 9 01:34:59 2008 From: goran.lowkrantz at ismobile.com (Goran Lowkrantz) Date: Tue Dec 9 01:35:07 2008 Subject: Regression in vr - not receiveing multicast Message-ID: Hi, in July, vr had this problem and was fixed: but now it's back again! On a system with the following: 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 I have to set all vr interfaces in promisc to get routing info. Using Quagga # pkg_info -Ix uagga quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software on an inner network using RIPv2 # ifmcstat -i vr0 vr0: inet xxx.xxx.xxx.xxx group 224.0.0.9 igmpv2 mcast-macaddr 01:00:5e:00:00:09 refcnt 1 group 224.0.0.1 mcast-macaddr 01:00:5e:00:00:01 refcnt 1 On the same box, we have some em devices also and they work without any problems. Let me know what I can do to help fix this. /glz ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule?, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From andrew at modulus.org Tue Dec 9 01:37:43 2008 From: andrew at modulus.org (Andrew Snow) Date: Tue Dec 9 01:37:52 2008 Subject: lagg(4) and failover In-Reply-To: <11397385.9861228809480949.JavaMail.root@ly.sdf.com> References: <11397385.9861228809480949.JavaMail.root@ly.sdf.com> Message-ID: <493E38B5.30608@modulus.org> > lagg is ultimately a problem as a high-availability solution since most switches do not support multi-switch 802.3ad yet, and most probably never well. So you are limited to a single switch. So 802.3ad is good only for aggregation, and not for high availability. What about using STP or RSTP instead of lagg? Which L2 managed switches like 3com and HP support. Then you could connect each of two NICs to a different switch, as well as connect the switches to each other. From ari at ish.com.au Tue Dec 9 01:56:27 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Tue Dec 9 01:56:35 2008 Subject: visibility of release process In-Reply-To: <20081208182112.GW58682@server.vk2pj.dyndns.org> References: <20081208182112.GW58682@server.vk2pj.dyndns.org> Message-ID: On 09/12/2008, at 5:21 AM, Peter Jeremy wrote: > What do you mean as "news source"? Commits are inherently low level > and it's difficult to see how a commit could be massaged into some > sort of press release without a fair amount of meta information in > the commit log. Well, I use this as a way of tracking activity sometimes: http://news.gmane.org/gmane.os.freebsd.devel.cvs And indeed, I notice now it has been improved recently. The commit messages now include full paths and diffs. Very helpful. >> * the bug tracker. Let's just say that FreeBSD's bug tracker is >> fairly >> primitive and 'target release' is not an option. > > Agreed. This is an issue that comes up regularly but I don't believe > a solution has been identified. I suspect one of the requirements > would be that it be FOSS I don't understand why it should be necessarily FOSS. I believe the best solution should be chosen by those people who would use it most: the core developers. I know for a fact that many non-free providers would give FreeBSD a free perpetual license for the goodwill it would create, as for instance Atlassian do for Jira at Apache and other open source projects. Is it also a requirement that FreeBSD only be hosted on servers with FOSS bios? What about P4? My personal wish list would be: * rich search interface * workflow (eg. if a critical task remains open for more than x days without attention, it is automatically escalated) * svn integration (so that commit messages reference the task and vice versa) * release notes and roadmap * ease of integration with multiple front end tools, so developers can comment on issues from the command line or their iphone >> I've had a look at several of the fisheye sites and am not sure what > it would buy the Project, other than some pretty graphs. I don't see > how this is any more "friendly" than svn.freebsd.org. Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/ and see commit log per branch or any other way to see what is going on in a branch. Fisheye gives you that in a really clear way and it costs nothing to add another option for users. Cheers Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From glz at hidden-powers.com Tue Dec 9 01:59:27 2008 From: glz at hidden-powers.com (Goran Lowkrantz) Date: Tue Dec 9 01:59:36 2008 Subject: Regression in vr - not receiveing multicast Message-ID: Hi, in July, vr had this problem and was fixed: but now it's back again! On a system with the following: 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 I have to set all vr interfaces in promisc to get routing info. Using Quagga # pkg_info -Ix uagga quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software on an inner network using RIPv2 # ifmcstat -i vr0 vr0: inet xxx.xxx.xxx.xxx group 224.0.0.9 igmpv2 mcast-macaddr 01:00:5e:00:00:09 refcnt 1 group 224.0.0.1 mcast-macaddr 01:00:5e:00:00:01 refcnt 1 On the same box, we have some em devices also and they work without any problems. Let me know what I can do to help fix this. /glz ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule?, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... --- "There is hopeful symbolism in the fact that flags do not wave in a vacuum." -- Arthur C. Clarke From ruben at verweg.com Tue Dec 9 02:17:12 2008 From: ruben at verweg.com (Ruben van Staveren) Date: Tue Dec 9 02:17:18 2008 Subject: visibility of release process In-Reply-To: References: <20081208182112.GW58682@server.vk2pj.dyndns.org> Message-ID: <02D7BFFB-7B09-42DB-BBDF-F83AFDE45BD3@verweg.com> On 9 Dec 2008, at 10:56, Aristedes Maniatis wrote: > Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/ > and see commit log per branch or any other way to see what is going > on in a branch. Fisheye gives you that in a really clear way and it > costs nothing to add another option for users. Though experimental, I'm greatly enjoying http://www.secnetix.de/olli/FreeBSD/svnews/?p=/stable/7 Maybe it is worth considering to team up and bring this under the freebsd.org umbrella ? Regards, Ruben -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081209/080670d2/PGP.pgp From glz at hidden-powers.com Tue Dec 9 03:53:08 2008 From: glz at hidden-powers.com (Goran Lowkrantz) Date: Tue Dec 9 03:53:16 2008 Subject: Regression in vr - not receiveing multicast In-Reply-To: <20081209114723.GE33723@cdnetworks.co.kr> References: <20081209114723.GE33723@cdnetworks.co.kr> Message-ID: <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]> --On December 9, 2008 20:47:23 +0900 Pyun YongHyeon wrote: > On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote: > > Hi, > > > > in July, vr had this problem and was fixed: > > > > > > > > but now it's back again! > > > > There was just one bug fix since then and I guess the fix is not > related with your issue. > > > On a system with the following: > > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 > > > > I have to set all vr interfaces in promisc to get routing info. > > > > Using Quagga > > # pkg_info -Ix uagga > > quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route > software > > > on an inner network using RIPv2 > > # ifmcstat -i vr0 > > vr0: > > inet xxx.xxx.xxx.xxx > > group 224.0.0.9 > > igmpv2 > > mcast-macaddr 01:00:5e:00:00:09 refcnt 1 > > group 224.0.0.1 > > mcast-macaddr 01:00:5e:00:00:01 refcnt 1 > > > > > > On the same box, we have some em devices also and they work without > any > problems. > > > > There is fundamental differences between em(4) and vr(4). The > vr(4) for VT6105M takes advantage of perfect multicast filtering > feature which is not present on all em(4) interface. Perfect > multicast filtering can reduce unwanted multicast traffics such > that it could save a lot of CPU cycles. The downside is that vr(4) > cannot accept multicast frames for a multicast group without > joining the multicast group first. > For multicast routing purpose I guess 'options MROUTING' kernel > option should be enabled to accept all multicast frames. > Does your kernel have that option? No it has not. I will create such a beast and return with stories. /glz From pyunyh at gmail.com Tue Dec 9 04:08:58 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Dec 9 04:09:04 2008 Subject: Regression in vr - not receiveing multicast In-Reply-To: References: Message-ID: <20081209114723.GE33723@cdnetworks.co.kr> On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote: > Hi, > > in July, vr had this problem and was fixed: > > > > but now it's back again! > There was just one bug fix since then and I guess the fix is not related with your issue. > On a system with the following: > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 > > I have to set all vr interfaces in promisc to get routing info. > > Using Quagga > # pkg_info -Ix uagga > quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software > > on an inner network using RIPv2 > # ifmcstat -i vr0 > vr0: > inet xxx.xxx.xxx.xxx > group 224.0.0.9 > igmpv2 > mcast-macaddr 01:00:5e:00:00:09 refcnt 1 > group 224.0.0.1 > mcast-macaddr 01:00:5e:00:00:01 refcnt 1 > > > On the same box, we have some em devices also and they work without any > problems. > There is fundamental differences between em(4) and vr(4). The vr(4) for VT6105M takes advantage of perfect multicast filtering feature which is not present on all em(4) interface. Perfect multicast filtering can reduce unwanted multicast traffics such that it could save a lot of CPU cycles. The downside is that vr(4) cannot accept multicast frames for a multicast group without joining the multicast group first. For multicast routing purpose I guess 'options MROUTING' kernel option should be enabled to accept all multicast frames. Does your kernel have that option? > Let me know what I can do to help fix this. > > /glz > -- Regards, Pyun YongHyeon From onemda at gmail.com Tue Dec 9 05:57:10 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Dec 9 05:57:16 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <493CEE90.7050104@FreeBSD.org> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> <493CEE90.7050104@FreeBSD.org> Message-ID: <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> On 12/8/08, Bruce M. Simpson wrote: > I have rolled a port for ext2fuse: > http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar Ignoring fact that is buggy, slooow and port doesnt have any cache implemented and port leaves files behind in share/doc/ext2fuse when package deleted it looks fine. -- Paul From bseklecki at collaborativefusion.com Tue Dec 9 07:34:49 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Tue Dec 9 07:34:57 2008 Subject: lagg(4) and failover In-Reply-To: <11397385.9861228809480949.JavaMail.root@ly.sdf.com> References: <11397385.9861228809480949.JavaMail.root@ly.sdf.com> Message-ID: <1228836887.2805.697.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Mon, 2008-12-08 at 23:58 -0800, Tom Samplonius wrote: > I don't know if that is such a great idea, as that would only test > the switch that you are connected to. Heatbeats (STP,CARP) and active sanity checking (Nagios, ifwatchd(8)) are the two main options. Results may vary in every system/network device permutation. At least we're talking about it -- even if just for the sake of the archives -- that wasn't happening before. -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081209/b4640bee/attachment.pgp From mike at sentex.net Tue Dec 9 08:55:39 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 9 08:55:48 2008 Subject: sio vs uart vs ucomm problems / differences In-Reply-To: <200811260219.mAQ2JFEL065881@lava.sentex.ca> References: <200811260219.mAQ2JFEL065881@lava.sentex.ca> Message-ID: <200812091655.mB9GtapH048081@lava.sentex.ca> At 09:19 PM 11/25/2008, Mike Tancsa wrote: >We are in the process of migrating one of our embedded apps to use >uart by default instead of sio in RELENG_7 in prep for the day when >sio eventually disappears. Unfortunately, the application doesnt >want to work with uart >with puc backed devices, but still works with sio. Stranger still, the app For the archives, We were sort of able to figure it out in http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001052.html and http://lists.freebsd.org/pipermail/freebsd-usb/2008-December/005817.html ---Mike From fernan.aguero at gmail.com Tue Dec 9 09:27:42 2008 From: fernan.aguero at gmail.com (Fernan Aguero) Date: Tue Dec 9 09:27:55 2008 Subject: update release schedule information? Message-ID: <520894aa0812090927h4034e7ecnff5d05d2d6138554@mail.gmail.com> Hi, the release schedule information available in http://www.freebsd.org/releases/7.1R/schedule.html is outdated. You probably already know about this ... and I also know 7.1-RELEASE is delayed, but the schedule page does not provide any useful information on what's going to happen next. BETA2 has already passed but it has not been mentioned in this document. The front page for the project (www.freebsd.org) links to ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/7.1/ with the text 'Upcoming Release 7.1 - BETA2' (but BETA2 is not mentioned in schedule.html) If you navigate to the FTP site using that link now, you'll find that the images for the RC1 are already available (Dec 7th). But the 'actual' dates for the RC1 builds are missing from schedule.html. I'm not familiar with the docproj procedures, but have tried to help by editing the release.ent and schedule.sgml files (patches attached), which looked as the obvious candidates to me. If someone can check them, complete the missing dates in schedule.sgml, and commit the changes, that would be great! Cheers, -- fernan -------------- next part -------------- A non-text attachment was scrubbed... Name: release.ent.diff Type: text/x-patch Size: 73 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081209/ca5e0b91/release.ent.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: schedule.sgml.diff Type: text/x-patch Size: 632 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081209/ca5e0b91/schedule.sgml.bin From alfred at freebsd.org Tue Dec 9 09:50:36 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Dec 9 09:50:43 2008 Subject: confirming bugs is bad behavior, etc. In-Reply-To: <7A8CC4E4-D59A-4841-8800-A3509C9DB68E@netconsonance.com> References: <4912E462.4090608@icyb.net.ua> <491586B9.2020303@vwsoft.com> <4919851B.7050800@icyb.net.ua> <492FF127.807@icyb.net.ua> <31DE68A5-D3CB-4C33-86E6-515581B425E1@netconsonance.com> <7A8CC4E4-D59A-4841-8800-A3509C9DB68E@netconsonance.com> Message-ID: <20081209173053.GZ27096@elvis.mu.org> Jo, I'm trying to get FreeBSD to consider not supporting another "6.4" or "5.5" as both seems to have some of the problems you're describing due to a the next gen -stable being out for so long sucking away developer time. As a user, what do you think about this? I hate to force users to upgrade, but I also hate to potentially be falsly advertising "stability" when there might not be enough maintainers to keep that true. Thoughts? -Alfred * Jo Rhett [081201 12:28] wrote: > On Dec 1, 2008, at 11:59 AM, George V. Neville-Neil wrote: > >I have mostly stayed away from these threads because they've often > >devolved into unproductive finger pointing. > > > >Please leave the hyperbole out of your posts, or at least attempt to > >cut it back. People on these lists are working quite hard to solve > >problems for the whole of the FreeBSD community and your posts, such > >as this one, are not helping us to move forward. > > > My posts have always been directed at solving very real, operational > problems with using FreeBSD on server platforms, which is exactly the > stated goal for freebsd. I have always offered not only problems, but > resources to help test or evaluate the issues, and serious > considerations for ways to improve the process. > > Yes, you're right. Threads I start about real problems always devolve > into unproductive finger pointing. That would be the freebsd > developers attacking the reporter for identifying a real, operational > problem. Take a look at the posts of the FreeBSD developers, and view > for yourself the unprofessional attacks and personal insults hurled by > them at people who are simply trying to get real problems resolved. > > And yet, instead of asking your developers to stop violating the > posted rules of the mailing list, you are asking a bug reporter who > simply informed another bug reporter that their problem was both > widespread and not limited to USB devices to stop posting to the > list. Because god knows that "yes we saw it too and it's widely > reported" is bad behavior. Much worse that personal attacks which are > strictly against the list rules. > > Yes, I'm sure that the personal attacks really do help drive freebsd > development forward. Much more so than me bringing resources and > actually testing things does. > > Now that Core has clearly spoken their mind on this issue, by refusing > to ask freebsd developers to avoid violating the list charter and then > publicly calling out someone for just saying "yeah, it's a widely > reported problem" ... leaves any doubt that positive change is going > to happen here. > > Your request is accepted. I'm unsubscribing now. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- - Alfred Perlstein From victor at bsdes.net Tue Dec 9 10:52:43 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Tue Dec 9 10:52:52 2008 Subject: [ATA] and re(4) stability issues Message-ID: <20081209185236.GA1320@alf.bsdes.net> Hello, I got various machines[1] at hetzner.de and I've been having problems with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've been trying to narrow the problem so someone more knowledgeable than me is able to fix it. This mail is an other attempt to ask a question with regards ATA code to see if this time i got something. For the ones that don't actually know what happened: With FreeBSD 7.0 -RELEASE for amd64 and default kernel the system shared re0 interrupt with OHCI and this caused re(4) to corrupt packets and create interrupt storms. Tried updating to 7.1 -BETA2 and still had some problems with it. I've opened the PR kern/128287[2] and Remko quickly answered with a workaround: that workaround was removing USB support from my kernel. I did it and re(4) wasn't sharing interrupts anylonger, and the interrupt storms were gone. Now sometime later the interface goes up and down from time to time, but less often. Also sometimes the machine losts the network interface but continues to work. I know it continues to work because some days later i can see that it tried to deliver the status reports but was unable to resolve the aliases hostnames. I can't ping the machine and i know the network is OK. If i reboot the machine everything is working again. When switched from 7.0 to 7.1 BETA2 i also found that under load after some hours the machine created interrupt storms on ATA disks. Digging at linux source code i've found that they do some special things for this chipset that i've been unable to find on our code. This is linux code for my chipset: 371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | 372 AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI | 373 AHCI_HFLAG_SECT255), File and the rest of the code in here[3]. As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could think of, switching MSI and MSI-x off for the whole system, so i added to /boot/loader.conf this tunables: hw.pci.enable_msix="0" hw.pci.enable_msi="0" And then rebooted the machine. After various hours of doing almost nothing i've found that the machine answered ping but was unable to answer any request (eg, ssh, nagios nrpe, etc). The machine recovered itself after some minutes and when i was able to ssh into i saw the following in dmesg: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly ad4: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=1463123158 and a lot more errors like that. I didn't get this errors with MSI enabled. I see WRITE_DMA48 and in linux code i saw AHCI_HFLAG_32BIT_ONLY which is later used for DMA related things. Could someone who is more knowledgeable check if we're doing the right thing? I've attached verbose dmesg of a machine that's like this one with 7.1 -BETA2, MSI enabled and GENERIC kernel minus USB and firewrire. Also, please, could someone give me a hand on how could i continue debugging this interrupt issues? I'm a bit lost and digging code and posting each time i think i've found something is not going to go anywhere. I would also like to say that i've seen reports of this kind of problems on amd64 machines in the lists since various years ago, so i don't think this is just a problem with this BIOS/motherboard (MSI K9AG Neo2 Digital) on the lists Thanks in advance for any help. Regards. [1]: http://www.hetzner.de/hosting/produkte_rootserver/ds7000/ [2]: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128287 [3]: http://fxr.watson.org/fxr/source/drivers/ata/ahci.c?v=linux-2.6#L369 -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. -------------- next part -------------- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-BETA2 #1: Wed Oct 22 13:19:14 CEST 2008 victor@foo.bar.com:/usr/obj/usr/src/sys/NOUSB Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80c12000. Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0xffffffff80c121a8. Preloaded elf obj module "/boot/kernel/accf_data.ko" at 0xffffffff80c12818. Preloaded elf obj module "/boot/kernel/accf_http.ko" at 0xffffffff80c12cc8. Preloaded elf obj module "/boot/kernel/k8temp.ko" at 0xffffffff80c13238. Preloaded elf obj module "/boot/kernel/geom_journal.ko" at 0xffffffff80c13720. Calibrating clock(s) ... i8254 clock: 1193242 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2999975813 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (2999.98-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 6395625472 (6099 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000d13000 - 0x00000000d1c6bfff, 3505754112 bytes (855897 pages) 0x0000000100000000 - 0x000000019ffeffff, 2684289024 bytes (655344 pages) avail memory = 6179069952 (5892 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf98a0/0x0014 (v 0 ACPIAM) ACPI: RSDT @ 0x0xddfd0000/0x003C (v 1 M S I OEMRSDT 0x10000731 MSFT 0x00000097) ACPI: FACP @ 0x0xddfd0200/0x0084 (v 2 M S I OEMFACP 0x10000731 MSFT 0x00000097) ACPI: DSDT @ 0x0xddfd0430/0x40D9 (v 1 1ADNC 1ADNC000 0x00000000 INTL 0x20051117) ACPI: FACS @ 0x0xddfde000/0x0040 ACPI: APIC @ 0x0xddfd0390/0x005C (v 1 M S I OEMAPIC 0x10000731 MSFT 0x00000097) ACPI: MCFG @ 0x0xddfd03f0/0x003C (v 1 M S I OEMMCFG 0x10000731 MSFT 0x00000097) ACPI: OEMB @ 0x0xddfde040/0x0060 (v 1 M S I AMI_OEM 0x10000731 MSFT 0x00000097) ACPI: EPTH @ 0x0xddfd4510/0x0038 (v 1 M S I OEMHPET 0x10000731 MSFT 0x00000097) ACPI: SSDT @ 0x0xddfd4550/0x030E (v 1 A M I POWERNOW 0x00000001 AMD 0x00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 wlan_amrr: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Oct 22 2008 13:19:08) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.RS48.NB2_ -> bus 0 dev 0 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ddf00000 (3) failed ACPI timer: 0/838 0/839 0/841 0/895 0/842 0/840 0/837 0/890 0/836 0/837 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 7 10 11 12 14 15 Validation 0 7 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 3 4 5 7 10 11 12 14 15 Validation 0 4 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x7910, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7912, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7917, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x1002, dev=0x4380, revid=0x00 domain=0, bus=0, slot=18, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xa000, size 2, enabled map[18]: type I/O Port, range 32, base 0x9000, size 3, enabled map[1c]: type I/O Port, range 32, base 0x8000, size 2, enabled map[20]: type I/O Port, range 32, base 0x7000, size 4, enabled map[24]: type Memory, range 32, base 0xfe7ff800, size 10, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4387, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0517, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe7fe000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4388, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0517, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[10]: type Memory, range 32, base 0xfe7fd000, size 12, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4389, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe7fc000, size 12, enabled pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 18 found-> vendor=0x1002, dev=0x438a, revid=0x00 domain=0, bus=0, slot=19, func=3 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[10]: type Memory, range 32, base 0xfe7fb000, size 12, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x438b, revid=0x00 domain=0, bus=0, slot=19, func=4 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe7fa000, size 12, enabled pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4386, revid=0x00 domain=0, bus=0, slot=19, func=5 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0517, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe7ff000, size 8, enabled pcib0: matched entry for 0.19.INTD pcib0: slot 19 INTD hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x14 domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0401, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0xb00, size 4, enabled found-> vendor=0x1002, dev=0x438c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xff00, size 4, enabled found-> vendor=0x1002, dev=0x438d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfe800000-0xfe9fffff pcib1: prefetched decode 0xfc000000-0xfdffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x791e, revid=0x00 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xfc000000, size 25, enabled pcib1: requested memory range 0xfc000000-0xfdffffff: good map[18]: type Memory, range 64, base 0xfe9f0000, size 16, enabled pcib1: requested memory range 0xfe9f0000-0xfe9fffff: good map[20]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib1: requested I/O range 0xc000-0xc0ff: in range map[24]: type Memory, range 32, base 0xfe800000, size 20, enabled pcib1: requested memory range 0xfe800000-0xfe8fffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x7919, revid=0x00 domain=0, bus=1, slot=5, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe9e8000, size 14, enabled pcib1: requested memory range 0xfe9e8000-0xfe9ebfff: good pcib1: matched entry for 1.5.INTB pcib1: slot 5 INTB hardwired to IRQ 19 vgapci0: port 0xc000-0xc0ff mem 0xfc000000-0xfdffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pci1: at device 5.2 (no driver attached) pcib2: at device 7.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x01 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type Memory, range 64, base 0xfeaff000, size 12, enabled pcib2: requested memory range 0xfeaff000-0xfeafffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfeaff000 re0: MSI count : 2 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:21:85:15:30:14 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 re0: [MPSAFE] re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x7000 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe7ff800 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: SATA connect time=0ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect time=0ms ata3: SIGNATURE: 00000101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: SATA connect status=00000000 ata4: ahci_reset devices=0x0 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: SATA connect status=00000000 ata5: ahci_reset devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] pci0: at device 19.0 (no driver attached) pci0: at device 19.1 (no driver attached) pci0: at device 19.2 (no driver attached) pci0: at device 19.3 (no driver attached) pci0: at device 19.4 (no driver attached) pci0: at device 19.5 (no driver attached) pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xff00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 k8temp0: on hostb4 acpi_button0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 52 sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 53 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xcd800-0xce7ff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 235635 -> 100000 procfs registered lapic: Divisor 2, Frequency 99999202 hz Timecounter "TSC" frequency 2999975813 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 715404MB at ata2-master SATA300 ad4: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Silicon Image check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 715404MB at ata3-master SATA300 ad6: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Silicon Image check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 GEOM_MIRROR: Device mirror/os launched (2/2). GEOM_JOURNAL: Journal 647493113: mirror/oss1g contains data. GEOM_JOURNAL: Journal 647493113: mirror/oss1g contains journal. GEOM_JOURNAL: Journal mirror/oss1g clean. Trying to mount root from ufs:/dev/mirror/oss1a start_init: trying /sbin/init re0: link state changed to UP From patfbsd at davenulle.org Tue Dec 9 12:17:24 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Tue Dec 9 12:17:31 2008 Subject: visibility of release process In-Reply-To: <02D7BFFB-7B09-42DB-BBDF-F83AFDE45BD3@verweg.com> References: <20081208182112.GW58682@server.vk2pj.dyndns.org> <02D7BFFB-7B09-42DB-BBDF-F83AFDE45BD3@verweg.com> Message-ID: <20081209205806.6e3f0c5e@baby-jane> Le Tue, 9 Dec 2008 11:16:57 +0100, Ruben van Staveren a ?crit : > > Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/ > > and see commit log per branch or any other way to see what is > > going on in a branch. Fisheye gives you that in a really clear way > > and it costs nothing to add another option for users. > > Though experimental, I'm greatly enjoying > http://www.secnetix.de/olli/FreeBSD/svnews/?p=/stable/7 Nice. There is also http://freshbsd.org/ (really cool IMHO). Regards. From toasty at dragondata.com Tue Dec 9 13:20:02 2008 From: toasty at dragondata.com (Kevin Day) Date: Tue Dec 9 13:20:15 2008 Subject: visibility of release process In-Reply-To: <1228753517.56532.25.camel@bauer.cse.buffalo.edu> References: <1228753517.56532.25.camel@bauer.cse.buffalo.edu> Message-ID: <55FAF790-6169-42BE-9285-1217C3284CDB@dragondata.com> On Dec 8, 2008, at 10:25 AM, Ken Smith wrote: > > Bottom line is my communication skills suck and of the bazillion other > things I could do with my time these sorts of housekeeping chores wind > up at a low enough priority they don't get done. But as you and > others > have made clear the priority needs to get raised and I need to deal > with > it. That's the part being worked on. Personally, as a end user, developer and cluster manager there are a few things that I would find extremely useful. I mean no disrespect to you or any of the work anyone on the team is putting forth for this - it's way more than I'm contributing so I'm grateful of what's being done now. This is just a wishlist. :) * Make the release notes a working document throughout the development cycle. Major caveats that anything in it before it's actually released is subject to change, but until the release notes are published I have a really tough time knowing what the next release even has in it. Is it worth holding off upgrading 50 servers for something we'd actually use, or are the changes of no concern? Is it something I didn't even know was in the tree that I might backport myself? If the release notes actually are available somewhere before the final stages of a release, I haven't been able to find them. * More notice to hubs@ before the release notes are generated. The releases always come with a "At the time of this writing, these mirrors have the full distribution" list. If it was announced to us mirror operators before that list is made, we could make sure we were synced in time to be included. Maybe even a semi-shaming of "These mirrors do not appear to have the required bits:". The difference in bandwidth we see on our public mirror (ftp3.us) is pretty extreme if we're listed there or not, which seems to be a 50/50 coin-toss on the last few releases. I'm honestly not sure why, since we can easily pull >50mbps from ftp-master. * The published release schedules are usually pretty far out of date. Beta/RCs get put up but the schedule says they haven't been, schedules sometimes have obviously slipped but it's unclear if it's affecting the final release date or not, etc. I know there aren't always answers to the unknowns, but more information would help. * Where are the BETA/RCs announced? Taking a page from apple, a mini- release notes saying "These items have changed since the last release/ beta/rc:" "These areas could use additional testing:" "These bugs are believed to be fixed, if you're still experiencing them let us know:" would probably get more people testing them. and give more insight into what's new. On anything other than a -RELEASE, make mention of this document in /etc/motd. I understand this would require effort from people working on those features, but if the beta readme file was in CVS and it was easier for developers to add to it themselves... If I'm not on the right mailing list, I won't see the "Call for testers" email that some send out. * Non FreeBSD users have a tough time with understanding that FreeBSD 6.4 was released after 7.0. I don't think the version numbering system should change, but new/novice users need a clearer guide as to which version to install on a fresh system. For example, the /releases/ page says: Release 7.0 (February 2008) Release 6.4 (November 2008) Which one of those is considered stable? If I know nothing about FreeBSD which one is "better" for me? Maybe a page that lists new features in rows, and a column/notes about its status in each version. FreeBSD has support for the Q1235 RAID controller from FooWare, but what version did it gain that? I'd love to help, but I'm not sure how/were an outsider can really make much impact here. But, I'm semi-volunteering. :) -- Kevin From confirm-s2-yvl4asaeasr2mkc2uta5qvz53fy2pwjx-stable=FreeBSD.org at yahoogroups.com Tue Dec 9 15:58:22 2008 From: confirm-s2-yvl4asaeasr2mkc2uta5qvz53fy2pwjx-stable=FreeBSD.org at yahoogroups.com (Yahoo! Groups) Date: Tue Dec 9 15:58:28 2008 Subject: Please confirm your request to join SKATINGEXTREME Message-ID: <1228866308.86.30548.w126@yahoogroups.com> Hello stable@FreeBSD.org, We have received your request to join the SKATINGEXTREME group hosted by Yahoo! Groups, a free, easy-to-use community service. This request will expire in 7 days. TO BECOME A MEMBER OF THE GROUP: 1) Go to the Yahoo! Groups site by clicking on this link: http://groups.yahoo.com/i?i=yvl4asaeasr2mkc2uta5qvz53fy2pwjx&e=stable%40FreeBSD%2Eorg (If clicking doesn't work, "Cut" and "Paste" the line above into your Web browser's address bar.) -OR- 2) REPLY to this email by clicking "Reply" and then "Send" in your email program If you did not request, or do not want, a membership in the SKATINGEXTREME group, please accept our apologies and ignore this message. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From kensmith at cse.Buffalo.EDU Tue Dec 9 18:39:34 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Tue Dec 9 18:39:41 2008 Subject: FreeBSD 7.1-RC1 Available... Message-ID: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> So... Two show-stoppers, one Security Advisory, and one "Gee. Did we really implement that new interface that way? That needs a bit more work." later... FreeBSD 7.1-RC1 is now available, the first of the Release Candidates. There will be at least one more Release Candidate before the release so the release itself is likely around 3 weeks from now IF no new show-stoppers are uncovered during testing. In addition to general testing we're looking for information about potential problems with the boot loader. There has been traffic here about problems but the reports haven't helped narrow down the causes yet. So far it seems to be related to USB keyboards and at least so far systems with more than one processor in them. More data points like cases where a USB keyboard was not involved as well as if possible things like which motherboard it is might help us narrow down the cause. Testing on a variety of motherboards, of varying ages and manufacturers would help. And a late arrival that's not possible to test without the packages, sysinstall's issues with excessive disc swapping when installing large sets of packages off the CDROMs should be fixed. Given the package layout it should ask for a disc no more than once. Testing to make sure that's working would be appreciated. NOTE: If updating from a 7.0 or earlier system due to a change in the Vendor's drivers certain Intel NICs will now come up as igb(4) instead of em(4). We normally try to avoid changes like that in stable branches but the vendor felt it necessary in order to support the new adapters. See the UPDATING entry dated 20080811 for details. There are only 3 PCI ID's that should have their name changed from em(4) to igb(4): 0x10A7, 0x10A9, and 0x10D6. You should be able to determine if your card will change names by running the command "pciconf -l", and for the line representing your NIC (should be named em on older systems, e.g. em0 or em1, etc) check the fourth column. If it says "chip=0x10a7" (or one of the other two IDs given above) you will have the adapter's name change. The ISO images and FTP install trees are available on the FreeBSD Mirror sites. Using the primary site as an example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.1/ where ${arch} is one of amd64, i386, ia64, pc98, powerpc, or sparc64. The ISOs for amd64, i386, and sparc64 include what is expected to be the final package set. For all architectures the ISOs with "disc" in their names are CDROM-sized, if you intend to install a variety of packages during installation you will need all three. For amd64 and i386 there is a gzip-ed iso with "dvd" in its name which is DVD-sized. It contains everything (install bits, livefs, docs, and packages) and can be used if your machine has a DVD drive in it. If you would like to do a source-based update to 7.1-RC1 from an already installed machine you can update your tree to RELENG_7_1 using normal cvsup/csup methods. Note that due to an unfortunate side-effect of the "real" source code repository now being in SVN it will look like all files have a new version so mergemaster may be a bit tedious. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-BETA, or 7.1-BETA2 can upgrade as follows: # freebsd-update upgrade -r 7.1-RC1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of Intel network interfaces which are changing their name from "em" to "igb" should make necessary changes to configuration files BEFORE running freebsd-update, since otherwise the network interface will not be configured appropriately after rebooting for the first time. Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to upgrade to FreeBSD 7.1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 6.x and FreeBSD 7.x. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081210/62a84079/attachment.pgp From kensmith at cse.Buffalo.EDU Tue Dec 9 18:49:12 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Tue Dec 9 18:49:20 2008 Subject: FreeBSD 7.1-RC1 Available... In-Reply-To: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> Message-ID: <1228877345.35416.27.camel@bauer.cse.buffalo.edu> Sigh. Sorry, did it again... Note the checksum for the dvd1 images is for them in their ungzip-ed form so uncompress them before trying to verify the checksums. Checksums: MD5 (7.1-RC1-amd64-bootonly.iso) = de6338599df1be6915dd01001c1ef4e5 MD5 (7.1-RC1-amd64-disc1.iso) = 116d0dbff53871778fb0e1e90ce4f2a6 MD5 (7.1-RC1-amd64-disc2.iso) = 2fb908291c90330b665098bb785d0746 MD5 (7.1-RC1-amd64-disc3.iso) = 1aecb94dbdc8cce4e1d793d308d32364 MD5 (7.1-RC1-amd64-docs.iso) = 440b5eb826a710d5e07f579d31142551 MD5 (7.1-RC1-amd64-dvd1.iso) = 205147c332524d49521f3b98c8b1b73b MD5 (7.1-RC1-amd64-livefs.iso) = 1972008c2b34eb3e51074ebd61a4a454 MD5 (7.1-RC1-i386-bootonly.iso) = e12d84609a00bdc6f996e77eff77226a MD5 (7.1-RC1-i386-disc1.iso) = 8743fff3a445d99b36772ff9984f7cae MD5 (7.1-RC1-i386-disc2.iso) = 4dabd0b245e42c2eb88a89ac4e132bad MD5 (7.1-RC1-i386-disc3.iso) = 63860e393c8001015c38cceb263b9ac7 MD5 (7.1-RC1-i386-docs.iso) = 57bfd48213da28789af84ea10301895a MD5 (7.1-RC1-i386-dvd1.iso) = e5acb528569ca5cc7fbc5d41fc2ae636 MD5 (7.1-RC1-i386-livefs.iso) = b261a6d73a491d188ac2dd1f913a86ef MD5 (7.1-RC1-ia64-bootonly.iso) = 07dfef578edb3aab31c2389c7f2d2bbe MD5 (7.1-RC1-ia64-disc1.iso) = 332009d292433d9232c0e4c906ee69c7 MD5 (7.1-RC1-ia64-disc2.iso) = f217c565ee264d883de71ccc3c94f91a MD5 (7.1-RC1-ia64-disc3.iso) = 15b8393ea09706ee7715bfdd62f11071 MD5 (7.1-RC1-ia64-docs.iso) = 16d95be27399605a487b1c1b61b02be5 MD5 (7.1-RC1-ia64-livefs.iso) = 15069a0e7142791a35fc25b64bf1d16c MD5 (7.1-RC1-pc98-bootonly.iso) = be89ea6f9010c86839815ebb6d5d29df MD5 (7.1-RC1-pc98-disc1.iso) = ff94a112a96cc5c7f1f9ca8039106a7d MD5 (7.1-RC1-pc98-livefs.iso) = 2cc908c7f9449256eb807782229f7288 MD5 (7.1-RC1-powerpc-bootonly.iso) = e87dcd0649e66743ee54a461669f3401 MD5 (7.1-RC1-powerpc-disc1.iso) = 5109252f3fa6b42458c1a01692b37833 MD5 (7.1-RC1-powerpc-disc2.iso) = 9870248b2ebce575e675541ade94f4eb MD5 (7.1-RC1-powerpc-disc3.iso) = 42b5a3c0228860d161679fd8c54c2266 MD5 (7.1-RC1-powerpc-docs.iso) = 81272f56de121e9491f3aeb48f7eb2cc MD5 (7.1-RC1-sparc64-bootonly.iso) = d65c6d0120e17661b50593cf1cea35a0 MD5 (7.1-RC1-sparc64-disc1.iso) = 47990a92b36bfcbb8fc10e8fa33ea16a MD5 (7.1-RC1-sparc64-disc2.iso) = a5debb7feab8e21870f46ea0dc689e1a MD5 (7.1-RC1-sparc64-disc3.iso) = b3c1e1b3aa26c71b91c68e89c57661d8 MD5 (7.1-RC1-sparc64-docs.iso) = 01d2184ae88c1a94403ee63de7333f18 SHA256 (7.1-RC1-amd64-bootonly.iso) = be7d99f1f29c56ea107eb41feb78683359379a82d6ce80dbcd0fc3126f5b7ec4 SHA256 (7.1-RC1-amd64-disc1.iso) = 3be67ca088868059df0790251e0484ec67f617fdd04a382e91ca0bae239c9d87 SHA256 (7.1-RC1-amd64-disc2.iso) = 91ba01dade4d37245ff5a5ff23d4a9b62d99e41decd1958389d078e3b400309e SHA256 (7.1-RC1-amd64-disc3.iso) = 301e34f1ff84acdf568abd7a298eb16d9d41e7362d6814137ad888c046930b7e SHA256 (7.1-RC1-amd64-docs.iso) = f783cefa13144062d14db44ddb44969a571f1b298930a8a544c7ac5e50e12cc3 SHA256 (7.1-RC1-amd64-dvd1.iso) = 971b8a21b53eaf583a4bb02c63a5eaba73dc29eaa638d5712805ffc933eb643e SHA256 (7.1-RC1-amd64-livefs.iso) = b81e4b42fa8e908eb9d75708daae4cb8b92e373e1e58fea306502920b7b52b33 SHA256 (7.1-RC1-i386-bootonly.iso) = b40e292d89c3e7167524bc9a9db54375188160e7e5855530471e8b2454727c11 SHA256 (7.1-RC1-i386-disc1.iso) = 13b88f219569748b5f760e190948e87a0febc3824278909d96db4173d6858820 SHA256 (7.1-RC1-i386-disc2.iso) = be7d09d59f921f121b3bb31e6d642f7b9a17a79bd15e2c4ae0f2c25ba041cbba SHA256 (7.1-RC1-i386-disc3.iso) = 70c2fe469b0d99e73e711d11542bf303a3d8193eae22c35e7187c79aa22d1a41 SHA256 (7.1-RC1-i386-docs.iso) = 64b96484e324d8cfec79c894f259dc3f1dfeb55f87ecd59c1c6049b59e8cfbc9 SHA256 (7.1-RC1-i386-dvd1.iso) = 5a265d19a6d8ed410e0e91d53cbf358bfa7b7e7e168cd6332a21dcdfddd0d37d SHA256 (7.1-RC1-i386-livefs.iso) = ba8be5619e0de22a5c69d5f8e245e7547cf5e3b1a5a6047ecdc71a5d3444ee4b SHA256 (7.1-RC1-ia64-bootonly.iso) = 413a31029e32c64cc137cb3e2c6dfddac10779bef17e2de0f7ed3a02cc2dff9a SHA256 (7.1-RC1-ia64-disc1.iso) = 2f5fe288fcb5312347c89e147a78a634d906b575104692a28b016b7514f5b541 SHA256 (7.1-RC1-ia64-disc2.iso) = 282fc15c7c2b594eff5041d5bd75337218f64ef41f1d97e991a2bc8c125a8e7c SHA256 (7.1-RC1-ia64-disc3.iso) = d4eada87243a20c7d2645096442e85e11717977bfff6f30d98766a09f31c66c1 SHA256 (7.1-RC1-ia64-docs.iso) = b5ec27943a48588c12678c8653553e5eff1d0a382ccc26ce1aa0b642310eee2d SHA256 (7.1-RC1-ia64-livefs.iso) = 33dfe5eada1d01bf8ed7c3093561eb5d92d4bed6a2dd2c5c69c50abe4db1523c SHA256 (7.1-RC1-pc98-bootonly.iso) = f5aa07453a9a4444b84e26949d70bb5b2982778724afbd74553678e2142e2950 SHA256 (7.1-RC1-pc98-disc1.iso) = 24cf624b2edc719452da4ddfcf961dfb40bbc8964321ee10c7d3af1715ec6f74 SHA256 (7.1-RC1-pc98-livefs.iso) = ffd6d1065f3d991b0676a18e8ff4b2c69647e69eda9c980510a25415bf65fcab SHA256 (7.1-RC1-powerpc-bootonly.iso) = 779110e8d426f5847fc2a89e273641933cdb2c1b535a8f8cb5b7d94bbe62b6d0 SHA256 (7.1-RC1-powerpc-disc1.iso) = 5cab6aa5bb22e25fc30ebd4909de2df005cc070f5338175446d721ef0fac662f SHA256 (7.1-RC1-powerpc-disc2.iso) = 487722bef61d3bfd1bf9d507b1cd98f5e7a22a0629ce3f6548e5394f3831189b SHA256 (7.1-RC1-powerpc-disc3.iso) = 07eb57953c2f62e32320af835fbc27809c33ab1b9d07adeb90f4e94f89265815 SHA256 (7.1-RC1-powerpc-docs.iso) = fbe50671e2c49f83cd9aace1d008daed19a2a022536a27ffabb1b4d426cda633 SHA256 (7.1-RC1-sparc64-bootonly.iso) = 12d65300c950b6661d16715cdad902acafc5cf892731655082a2190707195225 SHA256 (7.1-RC1-sparc64-disc1.iso) = bc54c89619c3e99d57c94dc244fdc0fe71d57093bcf12041abe5bf8c9e6d63d2 SHA256 (7.1-RC1-sparc64-disc2.iso) = 1242751d9c0a2f82923904f09fca0f4a63041f3d68e3287963f1f48d81013ff2 SHA256 (7.1-RC1-sparc64-disc3.iso) = 216db6bf1123de281affa6d2ce1cea13f63fbe41bee0f825bc51d13b01411dcc SHA256 (7.1-RC1-sparc64-docs.iso) = c7a904e4897e8f5c16fbb2f66dd6e59c5436658f55c24648e5f3fb11e5986c8e -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081210/e2e2f1ba/attachment.pgp From pyunyh at gmail.com Tue Dec 9 22:12:38 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Dec 9 22:12:45 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> Message-ID: <20081210061226.GC37837@cdnetworks.co.kr> On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > Hello, > > I got various machines[1] at hetzner.de and I've been having problems > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > been trying to narrow the problem so someone more knowledgeable than me > is able to fix it. This mail is an other attempt to ask a question > with regards ATA code to see if this time i got something. > > For the ones that don't actually know what happened: > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > the system shared re0 interrupt with OHCI and this caused > re(4) to corrupt packets and create interrupt storms. Tried re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily triggered on systems with > 4GB memory. But I dont' know whether this is related with interrupt storms. > updating to 7.1 -BETA2 and still had some problems with it. > > I've opened the PR kern/128287[2] and Remko quickly answered > with a workaround: that workaround was removing USB support from > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > and the interrupt storms were gone. Now sometime later the interface > goes up and down from time to time, but less often. Also sometimes > the machine losts the network interface but continues to work. > It seems that your controller supports MSI so you can set a tunable hw.re.msi_disable to 0 to enable MSI. With MSI you can remove interrupt sharing(e.g. add hw.re.msi_disable="0" to /boot/loader.conf file.) However there were several issues on re(4) w.r.t MSI so it was off by default. > I know it continues to work because some days later i can see that > it tried to deliver the status reports but was unable to resolve the > aliases hostnames. I can't ping the machine and i know the network > is OK. If i reboot the machine everything is working again. > Recently I've made small changes to re(4) which may help to detect link state change event. Would you try re(4) in HEAD? -- Regards, Pyun YongHyeon From goran.lowkrantz at ismobile.com Tue Dec 9 23:06:20 2008 From: goran.lowkrantz at ismobile.com (Goran Lowkrantz) Date: Tue Dec 9 23:06:27 2008 Subject: Regression in vr - not receiveing multicast In-Reply-To: <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]> References: <20081209114723.GE33723@cdnetworks.co.kr> <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]> Message-ID: --On December 9, 2008 12:53:05 +0100 Goran Lowkrantz wrote: > --On December 9, 2008 20:47:23 +0900 Pyun YongHyeon > wrote: > >> On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote: >> > Hi, >> > >> > in July, vr had this problem and was fixed: >> > >> > >> > >> > but now it's back again! >> > >> >> There was just one bug fix since then and I guess the fix is not >> related with your issue. >> >> > On a system with the following: >> > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 >> > >> > I have to set all vr interfaces in promisc to get routing info. >> > >> > Using Quagga >> > # pkg_info -Ix uagga >> > quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route >> software > >> > on an inner network using RIPv2 >> > # ifmcstat -i vr0 >> > vr0: >> > inet xxx.xxx.xxx.xxx >> > group 224.0.0.9 >> > igmpv2 >> > mcast-macaddr 01:00:5e:00:00:09 refcnt 1 >> > group 224.0.0.1 >> > mcast-macaddr 01:00:5e:00:00:01 refcnt 1 >> > >> > >> > On the same box, we have some em devices also and they work without >> any > problems. >> > >> >> There is fundamental differences between em(4) and vr(4). The >> vr(4) for VT6105M takes advantage of perfect multicast filtering >> feature which is not present on all em(4) interface. Perfect >> multicast filtering can reduce unwanted multicast traffics such >> that it could save a lot of CPU cycles. The downside is that vr(4) >> cannot accept multicast frames for a multicast group without >> joining the multicast group first. >> For multicast routing purpose I guess 'options MROUTING' kernel >> option should be enabled to accept all multicast frames. >> Does your kernel have that option? > > No it has not. I will create such a beast and return with stories. > I have tried with 'options MROUTING' and it didn't work. Did I miss something? Do I have to install and run mrouted also? It seems like maybe the first two packages are accepted after registration as I don't lose the routes until after about 6 min uptime. But to get further updates, I need the interfaces in promisc. So, next step? /glz From pyunyh at gmail.com Tue Dec 9 23:19:44 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Dec 9 23:19:50 2008 Subject: Regression in vr - not receiveing multicast In-Reply-To: References: <20081209114723.GE33723@cdnetworks.co.kr> <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]> Message-ID: <20081210071932.GD37837@cdnetworks.co.kr> On Wed, Dec 10, 2008 at 08:06:16AM +0100, Goran Lowkrantz wrote: > --On December 9, 2008 12:53:05 +0100 Goran Lowkrantz > wrote: > > >--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon > >wrote: > > > >>On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote: > >> > Hi, > >> > > >> > in July, vr had this problem and was fixed: > >> > > >> > > >> > > >> > but now it's back again! > >> > > >> > >>There was just one bug fix since then and I guess the fix is not > >>related with your issue. > >> > >> > On a system with the following: > >> > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 > >> > > >> > I have to set all vr interfaces in promisc to get routing info. > >> > > >> > Using Quagga > >> > # pkg_info -Ix uagga > >> > quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route > >>software > > >> > on an inner network using RIPv2 > >> > # ifmcstat -i vr0 > >> > vr0: > >> > inet xxx.xxx.xxx.xxx > >> > group 224.0.0.9 > >> > igmpv2 > >> > mcast-macaddr 01:00:5e:00:00:09 refcnt 1 > >> > group 224.0.0.1 > >> > mcast-macaddr 01:00:5e:00:00:01 refcnt 1 > >> > > >> > > >> > On the same box, we have some em devices also and they work without > >>any > problems. > >> > > >> > >>There is fundamental differences between em(4) and vr(4). The > >>vr(4) for VT6105M takes advantage of perfect multicast filtering > >>feature which is not present on all em(4) interface. Perfect > >>multicast filtering can reduce unwanted multicast traffics such > >>that it could save a lot of CPU cycles. The downside is that vr(4) > >>cannot accept multicast frames for a multicast group without > >>joining the multicast group first. > >>For multicast routing purpose I guess 'options MROUTING' kernel > >>option should be enabled to accept all multicast frames. > >>Does your kernel have that option? > > > >No it has not. I will create such a beast and return with stories. > > > > > I have tried with 'options MROUTING' and it didn't work. > > Did I miss something? Do I have to install and run mrouted also? > > It seems like maybe the first two packages are accepted after registration > as I don't lose the routes until after about 6 min uptime. But to get > further updates, I need the interfaces in promisc. > > So, next step? > Can you see ALLMULTI flag from the output of "ifconfig vr0"? -- Regards, Pyun YongHyeon From goran.lowkrantz at ismobile.com Tue Dec 9 23:25:59 2008 From: goran.lowkrantz at ismobile.com (Goran Lowkrantz) Date: Tue Dec 9 23:26:06 2008 Subject: Regression in vr - not receiveing multicast In-Reply-To: <20081210071932.GD37837@cdnetworks.co.kr> References: <20081209114723.GE33723@cdnetworks.co.kr> <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]> <20081210071932.GD37837@cdnetworks.co.kr> Message-ID: <47381931A80CB93CADD10DC7@[172.16.2.128]> --On December 10, 2008 16:19:33 +0900 Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 08:06:16AM +0100, Goran Lowkrantz wrote: > > --On December 9, 2008 12:53:05 +0100 Goran Lowkrantz > > wrote: > > > > >--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon > > >wrote: > > > > > >>On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote: > > >> > Hi, > > >> > > > >> > in July, vr had this problem and was fixed: > > >> > > > >> > > > >> > > > >> > but now it's back again! > > >> > > > >> > > >>There was just one bug fix since then and I guess the fix is not > > >>related with your issue. > > >> > > >> > On a system with the following: > > >> > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC > 2008 > >> > > > >> > I have to set all vr interfaces in promisc to get routing info. > > >> > > > >> > Using Quagga > > >> > # pkg_info -Ix uagga > > >> > quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route > > >>software > > > >> > on an inner network using RIPv2 > > >> > # ifmcstat -i vr0 > > >> > vr0: > > >> > inet xxx.xxx.xxx.xxx > > >> > group 224.0.0.9 > > >> > igmpv2 > > >> > mcast-macaddr 01:00:5e:00:00:09 refcnt 1 > > >> > group 224.0.0.1 > > >> > mcast-macaddr 01:00:5e:00:00:01 refcnt 1 > > >> > > > >> > > > >> > On the same box, we have some em devices also and they work > without > >>any > problems. > > >> > > > >> > > >>There is fundamental differences between em(4) and vr(4). The > > >>vr(4) for VT6105M takes advantage of perfect multicast filtering > > >>feature which is not present on all em(4) interface. Perfect > > >>multicast filtering can reduce unwanted multicast traffics such > > >>that it could save a lot of CPU cycles. The downside is that vr(4) > > >>cannot accept multicast frames for a multicast group without > > >>joining the multicast group first. > > >>For multicast routing purpose I guess 'options MROUTING' kernel > > >>option should be enabled to accept all multicast frames. > > >>Does your kernel have that option? > > > > > >No it has not. I will create such a beast and return with stories. > > > > > > > > > I have tried with 'options MROUTING' and it didn't work. > > > > Did I miss something? Do I have to install and run mrouted also? > > > > It seems like maybe the first two packages are accepted after > registration > as I don't lose the routes until after about 6 min > uptime. But to get > further updates, I need the interfaces in promisc. > > > > So, next step? > > > > Can you see ALLMULTI flag from the output of "ifconfig vr0"? > No -> # ifconfig vr0 vr0: flags=8943 metric 0 mtu 1500 options=284b ether 00:00:24:c8:e0:9c inet xxx.xxx.xxx.xxx netmask 0xfffffff8 broadcast xxx.xxx.xxx.yyy media: Ethernet autoselect (100baseTX ) status: active /glz From bu7cher at yandex.ru Wed Dec 10 00:58:27 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Dec 10 00:58:34 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> Message-ID: <493F84A4.1080308@yandex.ru> Victor Balada Diaz wrote: > Digging at linux source code i've found that they do some special things > for this chipset that i've been unable to find on our code. This is > linux code for my chipset: > > 371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | > 372 AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI | > 373 AHCI_HFLAG_SECT255), > > File and the rest of the code in here[3]. > > As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could > think of, switching MSI and MSI-x off for the whole system, so > i added to /boot/loader.conf this tunables: FreeBSD's ata(4) driver doesn't support MSI. This flag in linux's libata used in if ((hpriv->flags & AHCI_HFLAG_NO_MSI) || pci_enable_msi(pdev)) pci_intx(pdev, 1); In FreeBSD's code we have the same: /* enable PCI interrupt */ pci_write_config(dev, PCIR_COMMAND, pci_read_config(dev, PCIR_COMMAND, 2) & ~0x0400, 2); AHCI_HFLAG_IGN_SERR_INTERNAL flag targeted to ignore SERR_INTERNAL errors. FreeBSD's ata(4) driver ignores they too. AHCI_HFLAG_32BIT_ONLY flag limits to use 32-bit DMA only. If AHCI CAP register reports that controller supports 64-bit DMA driver will use 64-bit. So i think there can be added one quirk for you, but i'm not sure that problem is here.. AHCI_HFLAG_SECT255 flag limits I/O operation to 255 sectors, FreeBSD uses 128-limit by default. -- WBR, Andrey V. Elsukov From victor at bsdes.net Wed Dec 10 00:59:38 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Wed Dec 10 00:59:51 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210061226.GC37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> Message-ID: <20081210085934.GB1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > Hello, > > > > I got various machines[1] at hetzner.de and I've been having problems > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > been trying to narrow the problem so someone more knowledgeable than me > > is able to fix it. This mail is an other attempt to ask a question > > with regards ATA code to see if this time i got something. > > > > For the ones that don't actually know what happened: > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > the system shared re0 interrupt with OHCI and this caused > > re(4) to corrupt packets and create interrupt storms. Tried > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > triggered on systems with > 4GB memory. But I dont' know whether > this is related with interrupt storms. > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > with a workaround: that workaround was removing USB support from > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > and the interrupt storms were gone. Now sometime later the interface > > goes up and down from time to time, but less often. Also sometimes > > the machine losts the network interface but continues to work. > > > > It seems that your controller supports MSI so you can set a tunable > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > interrupt sharing(e.g. add hw.re.msi_disable="0" to > /boot/loader.conf file.) However there were several issues on re(4) > w.r.t MSI so it was off by default. This is undocumented and with sysctl -a i can't find the tunable. Is this a HEAD feature or it's also in 7.1 -BETA2? Should i add hw.re_msi_disable="0" to /boot/loader.conf? This was sharing interrupt with USB, does USB need any special MSI handling or with re using MSI is enough to not share the interrupt? > > > I know it continues to work because some days later i can see that > > it tried to deliver the status reports but was unable to resolve the > > aliases hostnames. I can't ping the machine and i know the network > > is OK. If i reboot the machine everything is working again. > > > > Recently I've made small changes to re(4) which may help to detect > link state change event. Would you try re(4) in HEAD? Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that or do i need to test the whole HEAD kernel? Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From victor at bsdes.net Wed Dec 10 01:11:09 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Wed Dec 10 01:11:21 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <493F84A4.1080308@yandex.ru> References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> Message-ID: <20081210091107.GC1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 11:58:12AM +0300, Andrey V. Elsukov wrote: > Victor Balada Diaz wrote: > >Digging at linux source code i've found that they do some special things > >for this chipset that i've been unable to find on our code. This is > >linux code for my chipset: > > > >371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | > >372 AHCI_HFLAG_32BIT_ONLY | > >AHCI_HFLAG_NO_MSI | > >373 AHCI_HFLAG_SECT255), > > > >File and the rest of the code in here[3]. > > > >As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could > >think of, switching MSI and MSI-x off for the whole system, so > >i added to /boot/loader.conf this tunables: > > FreeBSD's ata(4) driver doesn't support MSI. This flag in linux's libata > used in > > if ((hpriv->flags & AHCI_HFLAG_NO_MSI) || pci_enable_msi(pdev)) > pci_intx(pdev, 1); > > In FreeBSD's code we have the same: > > /* enable PCI interrupt */ > pci_write_config(dev, PCIR_COMMAND, > pci_read_config(dev, PCIR_COMMAND, 2) & ~0x0400, 2); > > AHCI_HFLAG_IGN_SERR_INTERNAL flag targeted to ignore SERR_INTERNAL errors. > FreeBSD's ata(4) driver ignores they too. > > AHCI_HFLAG_32BIT_ONLY flag limits to use 32-bit DMA only. > If AHCI CAP register reports that controller supports 64-bit DMA driver > will use 64-bit. > So i think there can be added one quirk for you, but i'm not sure that > problem is here.. > > AHCI_HFLAG_SECT255 flag limits I/O operation to 255 sectors, FreeBSD uses > 128-limit > by default. Thanks for explaining me what the flags do. I'm not skilled enough to create the DMA quirks but if you could give me some patches i'll test them. Also if you have any other idea on what could i test or how can i debug this it would be more than welcome. Thanks. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From sos at FreeBSD.ORG Wed Dec 10 01:55:40 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Wed Dec 10 01:55:53 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210091107.GC1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> <20081210091107.GC1320@alf.bsdes.net> Message-ID: On 10Dec, 2008, at 10:11 , Victor Balada Diaz wrote: > > Thanks for explaining me what the flags do. I'm not skilled enough > to create > the DMA quirks but if you could give me some patches i'll test them. > Also > if you have any other idea on what could i test or how can i debug > this > it would be more than welcome. Comment out the following two lines in ata_ahci_dmainit(): if (ATA_INL(ctlr->r_res2, ATA_AHCI_CAP) & ATA_AHCI_CAP_64BIT) ch->dma->max_address = BUS_SPACE_MAXADDR; And you will not use 64bit DMA even if the chipset supports it. However I have not seen any chipsets supporting this fail, YMMV as usual :) -S?ren From pyunyh at gmail.com Wed Dec 10 02:28:15 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Dec 10 02:28:25 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210085934.GB1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> Message-ID: <20081210102800.GH37837@cdnetworks.co.kr> On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > Hello, > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > been trying to narrow the problem so someone more knowledgeable than me > > > is able to fix it. This mail is an other attempt to ask a question > > > with regards ATA code to see if this time i got something. > > > > > > For the ones that don't actually know what happened: > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > the system shared re0 interrupt with OHCI and this caused > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > triggered on systems with > 4GB memory. But I dont' know whether > > this is related with interrupt storms. > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > with a workaround: that workaround was removing USB support from > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > and the interrupt storms were gone. Now sometime later the interface > > > goes up and down from time to time, but less often. Also sometimes > > > the machine losts the network interface but continues to work. > > > > > > > It seems that your controller supports MSI so you can set a tunable > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > /boot/loader.conf file.) However there were several issues on re(4) > > w.r.t MSI so it was off by default. > > This is undocumented and with sysctl -a i can't find the tunable. Is this > a HEAD feature or it's also in 7.1 -BETA2? Should i add Yeah it's an undocmented feature. But most drivers written by me have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have the tunable. > hw.re_msi_disable="0" to /boot/loader.conf? ^^^^^^^^^^^^^^^^^^^^^ Shoule be hw.re.msi_disable="0" > Yes, just add it to /boot/loader.conf. Note, you should not disable system-wide MSI control(e.g. hw.pci.enable_msi == 1). > This was sharing interrupt with USB, does USB need any special MSI handling > or with re using MSI is enough to not share the interrupt? If re(4) can use MSI, you don't need to worry about interrupt sharing with USB. Check the output of "vmstat -i". You normally get an irq256 or higher for MSI enabled driver. > > > > > > > I know it continues to work because some days later i can see that > > > it tried to deliver the status reports but was unable to resolve the > > > aliases hostnames. I can't ping the machine and i know the network > > > is OK. If i reboot the machine everything is working again. > > > > > > > Recently I've made small changes to re(4) which may help to detect > > link state change event. Would you try re(4) in HEAD? > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that Yes, you can. It should build without problems. Just replace re(4) on stable/7 with HEAD version. > or do i need to test the whole HEAD kernel? > No you don't have to that. -- Regards, Pyun YongHyeon From victor at bsdes.net Wed Dec 10 03:32:28 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Wed Dec 10 03:32:36 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210102800.GH37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> Message-ID: <20081210113225.GD1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 07:28:00PM +0900, Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > > Hello, > > > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > > been trying to narrow the problem so someone more knowledgeable than me > > > > is able to fix it. This mail is an other attempt to ask a question > > > > with regards ATA code to see if this time i got something. > > > > > > > > For the ones that don't actually know what happened: > > > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > > the system shared re0 interrupt with OHCI and this caused > > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > > triggered on systems with > 4GB memory. But I dont' know whether > > > this is related with interrupt storms. > > > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > > with a workaround: that workaround was removing USB support from > > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > > and the interrupt storms were gone. Now sometime later the interface > > > > goes up and down from time to time, but less often. Also sometimes > > > > the machine losts the network interface but continues to work. > > > > > > > > > > It seems that your controller supports MSI so you can set a tunable > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > /boot/loader.conf file.) However there were several issues on re(4) > > > w.r.t MSI so it was off by default. > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > Yeah it's an undocmented feature. But most drivers written by me > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > the tunable. I think it could be great if you could document it or at least show it by default when you do sysctl -ad with a small description. > > > hw.re_msi_disable="0" to /boot/loader.conf? > ^^^^^^^^^^^^^^^^^^^^^ > Shoule be hw.re.msi_disable="0" > > > > Yes, just add it to /boot/loader.conf. Note, you should not disable > system-wide MSI control(e.g. hw.pci.enable_msi == 1). > > > This was sharing interrupt with USB, does USB need any special MSI handling > > or with re using MSI is enough to not share the interrupt? > > If re(4) can use MSI, you don't need to worry about interrupt > sharing with USB. Check the output of "vmstat -i". You normally get > an irq256 or higher for MSI enabled driver. > > > > > > > > > > > > I know it continues to work because some days later i can see that > > > > it tried to deliver the status reports but was unable to resolve the > > > > aliases hostnames. I can't ping the machine and i know the network > > > > is OK. If i reboot the machine everything is working again. > > > > > > > > > > Recently I've made small changes to re(4) which may help to detect > > > link state change event. Would you try re(4) in HEAD? > > > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that > > Yes, you can. It should build without problems. Just replace re(4) on > stable/7 with HEAD version. > > > or do i need to test the whole HEAD kernel? > > > > No you don't have to that. Backporting the changes i've found that it didn't compile so in the end i got from HEAD the following files: base/head/sys/dev/re/if_re.c base/head/sys/pci/if_rl.c base/head/sys/pci/if_rlreg.h After that i've recompiled 7.1 -BETA2 GENERIC kernel and enabled the knob you suggested in /boot/loader.conf. With the new kernel and MSI the interrupts are like this: # vmstat -i interrupt total rate irq9: acpi0 1 0 irq16: ohci0 1 0 irq17: ohci1 ohci3 1 0 irq18: ohci2 ohci4 1 0 irq22: atapci0 19215 15 cpu0: timer 2502718 1998 irq256: re0 4967726 3967 cpu1: timer 2502525 1998 Total 9992188 7980 The high interrupt numbers are because i've been running iperf to check everything it's fine, not because of interrupt storms. So far i didn't find any interrupt storms related to USB or re(4) driver but while doing the tests i've found this error: re0: watchdog timeout (missed Tx interrupts) -- recovering This didn't create any error on the interfaces (netstat -i). Also i didn't see any problem with interfaces going up and down, but that usually happen after some hours of uptime, so i'll let you know if the error happens again. As these seems to improve the current situation, is there any chance of merging -current driver in 7.1 before release? Thanks! Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From pyunyh at gmail.com Wed Dec 10 04:07:29 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Dec 10 04:07:42 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210113225.GD1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> Message-ID: <20081210120719.GK37837@cdnetworks.co.kr> On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 07:28:00PM +0900, Pyun YongHyeon wrote: > > On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > > > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > > > Hello, > > > > > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > > > been trying to narrow the problem so someone more knowledgeable than me > > > > > is able to fix it. This mail is an other attempt to ask a question > > > > > with regards ATA code to see if this time i got something. > > > > > > > > > > For the ones that don't actually know what happened: > > > > > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > > > the system shared re0 interrupt with OHCI and this caused > > > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > > > triggered on systems with > 4GB memory. But I dont' know whether > > > > this is related with interrupt storms. > > > > > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > > > with a workaround: that workaround was removing USB support from > > > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > > > and the interrupt storms were gone. Now sometime later the interface > > > > > goes up and down from time to time, but less often. Also sometimes > > > > > the machine losts the network interface but continues to work. > > > > > > > > > > > > > It seems that your controller supports MSI so you can set a tunable > > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > > /boot/loader.conf file.) However there were several issues on re(4) > > > > w.r.t MSI so it was off by default. > > > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > > > Yeah it's an undocmented feature. But most drivers written by me > > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > > the tunable. > > I think it could be great if you could document it or at least > show it by default when you do sysctl -ad with a small description. > If MSI worked as expected I would have documented it as I did in msk(4)/nfe(4)/ale(4)/age(4)/jme(4) etc. Using MSI on RealTek does not seem to stable. I tried hard to fix that but some users still reported watchdog timeouts. Working without documentation and hardware also made it hard to complete the work. This was the main reason why MSI was disabled on re(4). > > > > > hw.re_msi_disable="0" to /boot/loader.conf? > > ^^^^^^^^^^^^^^^^^^^^^ > > Shoule be hw.re.msi_disable="0" > > > > > > > Yes, just add it to /boot/loader.conf. Note, you should not disable > > system-wide MSI control(e.g. hw.pci.enable_msi == 1). > > > > > This was sharing interrupt with USB, does USB need any special MSI handling > > > or with re using MSI is enough to not share the interrupt? > > > > If re(4) can use MSI, you don't need to worry about interrupt > > sharing with USB. Check the output of "vmstat -i". You normally get > > an irq256 or higher for MSI enabled driver. > > > > > > > > > > > > > > > > > I know it continues to work because some days later i can see that > > > > > it tried to deliver the status reports but was unable to resolve the > > > > > aliases hostnames. I can't ping the machine and i know the network > > > > > is OK. If i reboot the machine everything is working again. > > > > > > > > > > > > > Recently I've made small changes to re(4) which may help to detect > > > > link state change event. Would you try re(4) in HEAD? > > > > > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that > > > > Yes, you can. It should build without problems. Just replace re(4) on > > stable/7 with HEAD version. > > > > > or do i need to test the whole HEAD kernel? > > > > > > > No you don't have to that. > > Backporting the changes i've found that it didn't compile so in > the end i got from HEAD the following files: > > base/head/sys/dev/re/if_re.c > base/head/sys/pci/if_rl.c > base/head/sys/pci/if_rlreg.h > Ah,, sorry about that. Recently there was some changes. I forgot that. > After that i've recompiled 7.1 -BETA2 GENERIC kernel and enabled > the knob you suggested in /boot/loader.conf. > > With the new kernel and MSI the interrupts are like this: > > # vmstat -i > interrupt total rate > irq9: acpi0 1 0 > irq16: ohci0 1 0 > irq17: ohci1 ohci3 1 0 > irq18: ohci2 ohci4 1 0 > irq22: atapci0 19215 15 > cpu0: timer 2502718 1998 > irq256: re0 4967726 3967 > cpu1: timer 2502525 1998 > Total 9992188 7980 > > The high interrupt numbers are because i've been running iperf to > check everything it's fine, not because of interrupt storms. So far > i didn't find any interrupt storms related to USB or re(4) driver > but while doing the tests i've found this error: > > re0: watchdog timeout (missed Tx interrupts) -- recovering > > This didn't create any error on the interfaces (netstat -i). > This was triggered by new code in HEAD. It indicates re(4) missed Tx completion interrupt. It could be a bug in driver or hardware bug. If you can live with that message you can safely ignore that as now re(4) does not reinitialize the hardware if it detect missing Tx completion interrupt. > Also i didn't see any problem with interfaces going up and down, > but that usually happen after some hours of uptime, so i'll let > you know if the error happens again. > Ok. > As these seems to improve the current situation, is there any > chance of merging -current driver in 7.1 before release? > I think re(4) in HEAD needs more testing. As you might know RealTek produced too many chipsets. :-( -- Regards, Pyun YongHyeon From kensmith at cse.Buffalo.EDU Wed Dec 10 04:11:01 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Wed Dec 10 04:11:08 2008 Subject: visibility of release process In-Reply-To: <55FAF790-6169-42BE-9285-1217C3284CDB@dragondata.com> References: <1228753517.56532.25.camel@bauer.cse.buffalo.edu> <55FAF790-6169-42BE-9285-1217C3284CDB@dragondata.com> Message-ID: <1228911052.57305.15.camel@bauer.cse.buffalo.edu> On Tue, 2008-12-09 at 15:19 -0600, Kevin Day wrote: [ Other points were not ignored, just nothing to really say about them other than "Yes" and/or "Will try", etc. ] > * More notice to hubs@ before the release notes are generated. The > releases always come with a "At the time of this writing, these > mirrors have the full distribution" list. If it was announced to us > mirror operators before that list is made, we could make sure we were > synced in time to be included. Maybe even a semi-shaming of "These > mirrors do not appear to have the required bits:". The difference in > bandwidth we see on our public mirror (ftp3.us) is pretty extreme if > we're listed there or not, which seems to be a 50/50 coin-toss on the > last few releases. I'm honestly not sure why, since we can easily pull > >50mbps from ftp-master. I have absolutely no clue how to fairly handle what needs to be done with this so, as you noted, its something of a coin toss at the moment. The issue is that the Release Announcement needs to include a list of FTP sites, but the list can't be "too long" (as in can't be every mirror site we've got). The Release Announcement should be relatively short and to the point. An exhaustive list of every mirror is a bit too much in that regard. Ideally we'd just say "Its available on a mirror site, get it from there.". But people want easy so we need to include something to click on. With the 7.0 release I tried giving just the URL of the primary site (ftp.freebsd.org) but that proved people don't just want easy - they're lazy. For the most part they just clicked on that and didn't look around for a mirror. Hence your observation about the difference in bandwidth when you're listed versus when you're not listed. Since we don't have any sort of "click here and automagically land on a nice fast mirror real close to you" I basically make a quick survey of some FTP sites shooting for having several of the primary mirror sites (ftpX.freebsd.org) and a sampling of geographically diverse country mirrors (ftpX.au.freebsd.org, ftpX.ru.freebsd.org, etc.). If you're one of the ones I check and if you've got the right sparc64 checksum file (I'm looking for sites that carry everything, and since sparc64 is usually the last to get loaded on ftp-master ...) you make the list. Sorry, I know it sucks. Until we've got something automagic I'm not quite sure how to fairly handle having a list that's not "too long" for a release announcement but still providing a reasonable starting point for people who want something to click on in the release announcement. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081210/9deb1c8b/attachment.pgp From arnaud.houdelette at tzim.net Wed Dec 10 04:18:06 2008 From: arnaud.houdelette at tzim.net (Arnaud Houdelette) Date: Wed Dec 10 04:18:37 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> Message-ID: <493FB378.5030106@tzim.net> Victor Balada Diaz a ?crit : > Hello, > > I got various machines[1] at hetzner.de and I've been having problems > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > been trying to narrow the problem so someone more knowledgeable than me > is able to fix it. This mail is an other attempt to ask a question > with regards ATA code to see if this time i got something. > > For the ones that don't actually know what happened: > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > the system shared re0 interrupt with OHCI and this caused > re(4) to corrupt packets and create interrupt storms. Tried > updating to 7.1 -BETA2 and still had some problems with it. > > I've opened the PR kern/128287[2] and Remko quickly answered > with a workaround: that workaround was removing USB support from > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > and the interrupt storms were gone. Now sometime later the interface > goes up and down from time to time, but less often. Also sometimes > the machine losts the network interface but continues to work. > > I know it continues to work because some days later i can see that > it tried to deliver the status reports but was unable to resolve the > aliases hostnames. I can't ping the machine and i know the network > is OK. If i reboot the machine everything is working again. > > When switched from 7.0 to 7.1 BETA2 i also found that under load > after some hours the machine created interrupt storms on ATA disks. > > Digging at linux source code i've found that they do some special things > for this chipset that i've been unable to find on our code. This is > linux code for my chipset: > > 371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | > 372 AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI | > 373 AHCI_HFLAG_SECT255), > > File and the rest of the code in here[3]. > > As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could > think of, switching MSI and MSI-x off for the whole system, so > i added to /boot/loader.conf this tunables: > > hw.pci.enable_msix="0" > hw.pci.enable_msi="0" > > And then rebooted the machine. After various hours of doing almost nothing > i've found that the machine answered ping but was unable to answer any > request (eg, ssh, nagios nrpe, etc). The machine recovered itself after > some minutes and when i was able to ssh into i saw the following in dmesg: > > ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad4: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=1463123158 > > and a lot more errors like that. I didn't get this errors with MSI enabled. > I see WRITE_DMA48 and in linux code i saw AHCI_HFLAG_32BIT_ONLY which is later > used for DMA related things. Could someone who is more knowledgeable check > if we're doing the right thing? > > I've attached verbose dmesg of a machine that's like this one with > 7.1 -BETA2, MSI enabled and GENERIC kernel minus USB and firewrire. > > Also, please, could someone give me a hand on how could i continue debugging > this interrupt issues? I'm a bit lost and digging code and posting each > time i think i've found something is not going to go anywhere. > > I would also like to say that i've seen reports of this kind of problems > on amd64 machines in the lists since various years ago, so i don't think > this is just a problem with this BIOS/motherboard (MSI K9AG Neo2 Digital) > on the lists > > > Thanks in advance for any help. > Regards. > > > [1]: http://www.hetzner.de/hosting/produkte_rootserver/ds7000/ > [2]: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128287 > [3]: http://fxr.watson.org/fxr/source/drivers/ata/ahci.c?v=linux-2.6#L369 > Sorry I didn't take the time to read all the thread, but I got similar problem with the same IXP600 chipset. Only it was'nt with a Realtek NIC (re) but with a Ralink wireless one. The simptoms where similar : interrupt 22 was shared between the sata controler and the wireless card. And I got Interrupt Storms at random times when using the wireless network. No problem since I removed the ral(4) NIC (got a real access point now). You might not want to point the finger at the re(4) driver too fast. Arnaud Houdelette From lists at peter.de.com Wed Dec 10 04:25:43 2008 From: lists at peter.de.com (Oliver Peter) Date: Wed Dec 10 04:25:50 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> Message-ID: <20081210120840.GA36443@nemesis.frida.mouhaha.de> On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > Hello, > > I got various machines[1] at hetzner.de and I've been having problems > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > been trying to narrow the problem so someone more knowledgeable than me > is able to fix it. This mail is an other attempt to ask a question > with regards ATA code to see if this time i got something. Just want to add a quick note and say that I'm having the same problem with my 7.0-RELEASE-p6/amd64 hetzner machine: http://lists.freebsd.org/pipermail/freebsd-acpi/2008-September/005095.html I would be happy to test patches as well. Thanks. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From SKATINGEXTREME-owner at yahoogroups.com Wed Dec 10 05:14:54 2008 From: SKATINGEXTREME-owner at yahoogroups.com (SKATINGEXTREME Moderator) Date: Wed Dec 10 05:15:01 2008 Subject: Yahoo! Groups: Welcome to SKATINGEXTREME. Visit today! Message-ID: <1228914131.1611.89729.w111@yahoogroups.com> Hello, Thank you for being a subscriber to this list. I hope that you get a chance to check out my web sites. I have one at http://www.howard.net/hilary and one also at http://www.webpost.net/sk/SkatersChoice . I will try to be in the chat room on Thursday evenings. Go to Hilarys Skating Center then if you want to try to chat. I would love to get a lot of skaters out there in a chat. Pass the word and lets find some skaters eh. Thanks, Hilary Complete your Yahoo! Groups account: ---------------------------------------------------------------------- Your email address has been added to the email list of a Yahoo! Group. To gain access to all of your group's web features (previous messages, photos, files, calendar, etc.) and easier control of your message delivery options, we highly recommend that you complete your account by connecting your email address to Yahoo account. It is easy and free. Please visit: http://groups.yahoo.com/convacct?email=stable%40FreeBSD.org&list=SKATINGEXTREME Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ From skip at menantico.com Wed Dec 10 06:00:53 2008 From: skip at menantico.com (Skip Ford) Date: Wed Dec 10 06:01:00 2008 Subject: visibility of release process In-Reply-To: <1228911052.57305.15.camel@bauer.cse.buffalo.edu> References: <1228753517.56532.25.camel@bauer.cse.buffalo.edu> <55FAF790-6169-42BE-9285-1217C3284CDB@dragondata.com> <1228911052.57305.15.camel@bauer.cse.buffalo.edu> Message-ID: <20081210140636.GA31418@menantico.com> Ken Smith wrote: > With the 7.0 release I tried giving just the URL > of the primary site (ftp.freebsd.org) but that proved people don't just > want easy - they're lazy. For the most part they just clicked on that > and didn't look around for a mirror. Hence your observation about the > difference in bandwidth when you're listed versus when you're not > listed. Any idea if most of those ISO downloaders are really installing a fresh system or are just updating from a previous release by reinstalling? It seems to me many more people could be using freebsd-update(8) so the announcement really could focus on upgrades rather than fresh installs. I obviously like FreeBSD myself, but how many new users who need to download ISOs really come on board with each new release? The freebsd-update(8) portion of "Updating existing systems" could be the main focus of the announcement, and the "Availability" section and "updating existing systems from source" sections could just contain a link pointing to the web site since (I believe) the number of users needing those should be limited. No FTP listing in the announcement at all. I guess freebsd-update(8) currently has some limitations that make it not so cut-and-dry. But I'm a little confused anyway at this point as to what the long-term plans are. There's a CVS repo, SVN repo which appears to be the way things will be, a "projects" svn repo, a "projects" p4 repo, cvs(1) in base, csup(1) in base which is still being worked on even though there appears to be a slow migration to svn, svn(1) is in ports, there's no SVN repo for the ports tree but there is for src, freebsd-update(8) exists for binary upgrades which seems to be the way of the future for a huge majority of end-users, and yet the official mirrors are missing both the SVN src repo and binary update files. It seems to me the mirrors and release announcement are behind the times by pointing to source upgrades and ISO downloads, or maybe I'm just a little too early. I hope core has a plan for all of this. :) -- Skip From victor at bsdes.net Wed Dec 10 06:01:32 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Wed Dec 10 06:01:46 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210120840.GA36443@nemesis.frida.mouhaha.de> References: <20081209185236.GA1320@alf.bsdes.net> <20081210120840.GA36443@nemesis.frida.mouhaha.de> Message-ID: <20081210140129.GE1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 12:08:40PM +0000, Oliver Peter wrote: > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > Hello, > > > > I got various machines[1] at hetzner.de and I've been having problems > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > been trying to narrow the problem so someone more knowledgeable than me > > is able to fix it. This mail is an other attempt to ask a question > > with regards ATA code to see if this time i got something. > > Just want to add a quick note and say that I'm having the same problem > with my 7.0-RELEASE-p6/amd64 hetzner machine: > > http://lists.freebsd.org/pipermail/freebsd-acpi/2008-September/005095.html > > I would be happy to test patches as well. Thanks. Hello Oliver, What i did so far and improved a lot the experience was: 1) Upgrade at least the if_re code to RELENG_7. This fixes issues of packet corruption on ssh sessions. 2) Delete from your kernel config USB and firewire. This prevents the realtek interrupt to be shared. After this, with 7.1 -BETA2 the systems are more or less stable, but after a while the ATA controller starts to create interrupt storms. I wasn't able to find why. With the help that i've received in this thread from Pyun YongHyeon (Thanks!!) i'm also trying this suggestions: 3) Backport this 3 files from current to 7.1 -BETA2: base/head/sys/dev/re/if_re.c base/head/sys/pci/if_rl.c base/head/sys/pci/if_rlreg.h You can fetch them from http://svn.freebsd.org/. With them and adding to /boot/loader.conf this tunable: hw.re.msi_disable="0" I can use GENERIC kernel again (ie, USB enabled) and so far i didn't find any problem yet. No more interface up/down problems and no more interrupt storms. I must say that i haven't tested this enough, because the interrupt storms in ATA code start to happen after a few days of uptime load, but at least the problems with the realtek seem to be gone. If you upgrade to 7.1 -BETA2 you'll also get SATA support for the IXP card. With 7.0 it will work as ATA 33 in compatibility mode. Maybe someone with write access to the wiki could add it somewhere so that other hetzner users that are having the same problems could use the same workarounds :) I hope this helps you. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From gary.jennejohn at freenet.de Wed Dec 10 06:02:14 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Dec 10 06:02:34 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210120719.GK37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> Message-ID: <20081210150207.4951a157@ernst.jennejohn.org> On Wed, 10 Dec 2008 21:07:19 +0900 Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > As these seems to improve the current situation, is there any > > chance of merging -current driver in 7.1 before release? > > > > I think re(4) in HEAD needs more testing. As you might know RealTek > produced too many chipsets. :-( > FYI I've now turned MSI on in HEAD and will see what happens. Before my re0 was sharing interrupts with 3 USB controllers. Now it's all by itself on irq256. I'm running amd64 with re0: port 0xde00-0xdeff mem 0xfdaff000-0xfdafffff, 0xfdae0000-0xfdaeffff irq 18 at device 0.0 on pci2 --- Gary Jennejohn From victor at bsdes.net Wed Dec 10 06:08:26 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Wed Dec 10 06:08:33 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210120719.GK37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> Message-ID: <20081210140823.GF1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > On Wed, Dec 10, 2008 at 07:28:00PM +0900, Pyun YongHyeon wrote: > > > On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > > > > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > > > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > > > > Hello, > > > > > > > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > > > > been trying to narrow the problem so someone more knowledgeable than me > > > > > > is able to fix it. This mail is an other attempt to ask a question > > > > > > with regards ATA code to see if this time i got something. > > > > > > > > > > > > For the ones that don't actually know what happened: > > > > > > > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > > > > the system shared re0 interrupt with OHCI and this caused > > > > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > > > > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > > > > triggered on systems with > 4GB memory. But I dont' know whether > > > > > this is related with interrupt storms. > > > > > > > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > > > > with a workaround: that workaround was removing USB support from > > > > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > > > > and the interrupt storms were gone. Now sometime later the interface > > > > > > goes up and down from time to time, but less often. Also sometimes > > > > > > the machine losts the network interface but continues to work. > > > > > > > > > > > > > > > > It seems that your controller supports MSI so you can set a tunable > > > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > > > /boot/loader.conf file.) However there were several issues on re(4) > > > > > w.r.t MSI so it was off by default. > > > > > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > > > > > Yeah it's an undocmented feature. But most drivers written by me > > > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > > > the tunable. > > > > I think it could be great if you could document it or at least > > show it by default when you do sysctl -ad with a small description. > > > > If MSI worked as expected I would have documented it as I did > in msk(4)/nfe(4)/ale(4)/age(4)/jme(4) etc. > Using MSI on RealTek does not seem to stable. I tried hard to fix > that but some users still reported watchdog timeouts. Working > without documentation and hardware also made it hard to complete > the work. This was the main reason why MSI was disabled on re(4). What do you think about adding a note in the man page telling that it's experimental and in some cases it could improve the situation but in others it will give errors? > > > > > > > > hw.re_msi_disable="0" to /boot/loader.conf? > > > ^^^^^^^^^^^^^^^^^^^^^ > > > Shoule be hw.re.msi_disable="0" > > > > > > > > > > Yes, just add it to /boot/loader.conf. Note, you should not disable > > > system-wide MSI control(e.g. hw.pci.enable_msi == 1). > > > > > > > This was sharing interrupt with USB, does USB need any special MSI handling > > > > or with re using MSI is enough to not share the interrupt? > > > > > > If re(4) can use MSI, you don't need to worry about interrupt > > > sharing with USB. Check the output of "vmstat -i". You normally get > > > an irq256 or higher for MSI enabled driver. > > > > > > > > > > > > > > > > > > > > > > I know it continues to work because some days later i can see that > > > > > > it tried to deliver the status reports but was unable to resolve the > > > > > > aliases hostnames. I can't ping the machine and i know the network > > > > > > is OK. If i reboot the machine everything is working again. > > > > > > > > > > > > > > > > Recently I've made small changes to re(4) which may help to detect > > > > > link state change event. Would you try re(4) in HEAD? > > > > > > > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that > > > > > > Yes, you can. It should build without problems. Just replace re(4) on > > > stable/7 with HEAD version. > > > > > > > or do i need to test the whole HEAD kernel? > > > > > > > > > > No you don't have to that. > > > > Backporting the changes i've found that it didn't compile so in > > the end i got from HEAD the following files: > > > > base/head/sys/dev/re/if_re.c > > base/head/sys/pci/if_rl.c > > base/head/sys/pci/if_rlreg.h > > > > Ah,, sorry about that. Recently there was some changes. I forgot > that. > > > After that i've recompiled 7.1 -BETA2 GENERIC kernel and enabled > > the knob you suggested in /boot/loader.conf. > > > > With the new kernel and MSI the interrupts are like this: > > > > # vmstat -i > > interrupt total rate > > irq9: acpi0 1 0 > > irq16: ohci0 1 0 > > irq17: ohci1 ohci3 1 0 > > irq18: ohci2 ohci4 1 0 > > irq22: atapci0 19215 15 > > cpu0: timer 2502718 1998 > > irq256: re0 4967726 3967 > > cpu1: timer 2502525 1998 > > Total 9992188 7980 > > > > The high interrupt numbers are because i've been running iperf to > > check everything it's fine, not because of interrupt storms. So far > > i didn't find any interrupt storms related to USB or re(4) driver > > but while doing the tests i've found this error: > > > > re0: watchdog timeout (missed Tx interrupts) -- recovering > > > > This didn't create any error on the interfaces (netstat -i). > > > > This was triggered by new code in HEAD. It indicates re(4) missed > Tx completion interrupt. It could be a bug in driver or hardware > bug. If you can live with that message you can safely ignore that > as now re(4) does not reinitialize the hardware if it detect > missing Tx completion interrupt. Yeah, just happened once, and i'm used to receiving a lot of interface UP/DOWN messages that now are gone, so this is an improvement. > > > Also i didn't see any problem with interfaces going up and down, > > but that usually happen after some hours of uptime, so i'll let > > you know if the error happens again. > > > > Ok. > > > As these seems to improve the current situation, is there any > > chance of merging -current driver in 7.1 before release? > > > > I think re(4) in HEAD needs more testing. As you might know RealTek > produced too many chipsets. :-( Ok, i'll use the backported driver as it works better for me :-) If i can help you testing any patches i'm more than welcome to do it. Thanks a lot for your help Pyun YongHyeon. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From rebehn at ant.uni-bremen.de Wed Dec 10 06:17:03 2008 From: rebehn at ant.uni-bremen.de (Heinrich Rebehn) Date: Wed Dec 10 06:17:10 2008 Subject: iir(4) support under 7.1 Message-ID: Hi list, i am planning to upgrade our main server from 6.1 to 7.1. The machine has a ICP Vortex GDT8524RZ raid controller which is handled buy the iir(4) driver. Since i have seen various discussions in the past about Adaptec no longer supporting these controllers, driver reaching EOE, data corruption in 64bit configurtions with > 4G RAM and so on, i just wanted to ask what the current state of the driver is. Thanks for your help, Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-4664 Fax : -3341 From lists at peter.de.com Wed Dec 10 06:18:47 2008 From: lists at peter.de.com (Oliver Peter) Date: Wed Dec 10 06:19:01 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210140129.GE1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210120840.GA36443@nemesis.frida.mouhaha.de> <20081210140129.GE1320@alf.bsdes.net> Message-ID: <20081210141834.GB36443@nemesis.frida.mouhaha.de> On Wed, Dec 10, 2008 at 03:01:30PM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 12:08:40PM +0000, Oliver Peter wrote: > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: ... > I can use GENERIC kernel again (ie, USB enabled) and so far > i didn't find any problem yet. No more interface up/down problems > and no more interrupt storms. I must say that i haven't tested > this enough, because the interrupt storms in ATA code start to > happen after a few days of uptime load, but at least the problems > with the realtek seem to be gone. I found out that I'm able to 'force' the interrupt storm by provoking higher disk I/O. Just let dd write to a file in a loop for some hours and watch vmstat: while true; do dd if=/dev/zero of=BLA bs=1M count=1000; done First you'll see that the throughput will decrease, and a few hours later you'll have /var/log/messages / dmesg full of interrupt storm messages. > If you upgrade to 7.1 -BETA2 you'll also get SATA support for > the IXP card. With 7.0 it will work as ATA 33 in compatibility mode. Wow! That's good to hear as well. I'll definitely switch to -STABLE or 7.1-PRERELASE sooner or later. I'll just give it a try on my other machines at first. > I hope this helps you. Absolutely, cheers mate. I owe you one! ~ollie -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From victor at bsdes.net Wed Dec 10 06:21:08 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Wed Dec 10 06:21:16 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <493FB378.5030106@tzim.net> References: <20081209185236.GA1320@alf.bsdes.net> <493FB378.5030106@tzim.net> Message-ID: <20081210142107.GG1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 01:18:00PM +0100, Arnaud Houdelette wrote: > Victor Balada Diaz a ?crit : > >Hello, > > > >I got various machines[1] at hetzner.de and I've been having problems > >with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > >been trying to narrow the problem so someone more knowledgeable than me > >is able to fix it. This mail is an other attempt to ask a question > >with regards ATA code to see if this time i got something. > > > >[...] > > Sorry I didn't take the time to read all the thread, but I got similar > problem with the same IXP600 chipset. > Only it was'nt with a Realtek NIC (re) but with a Ralink wireless one. > The simptoms where similar : interrupt 22 was shared between the sata > controler and the wireless card. And I got Interrupt Storms at random > times when using the wireless network. > > No problem since I removed the ral(4) NIC (got a real access point now). > You might not want to point the finger at the re(4) driver too fast. > > Arnaud Houdelette Hello Arnaud, I didn't say the problem was just because of re(4). Actually i think the there were two problems, one with re(4) and other with ata(4). The reason why i talked about both of them in the same mail is because i thought that as two drivers were affected, maybe the problem was in other part of the operating system and that could help the developers to debug the problem. My re(4) card isn't sharing the interrupt with IXP600, it's sharing the interrupt with USB controller. In this case i think the problem is fixed with the advices from Pyun YongHyeon (backporting the driver from HEAD and using MSI for interrupts). I think the problems with ata(4) code will appear again after a few days of load, as they always do, so i'll keep trying to debug them. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From dudu at dudu.ro Wed Dec 10 06:59:27 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Dec 10 06:59:34 2008 Subject: bce(4) and rx errors Message-ID: Hello. Sorry for crossposting, but I wasn't sure which mailing list was the most appropriate for this email. I have an application pulling about 220Kpps from a bce(4) card (details below). At what seems to be random times, errors start showing up on that interface (I'm watching it with netstat -w1 -I), so about 10% of the initial 220Kpps is reported as errors. Bringing the interface down and then back up clears the errors, but they do reappear at a later time. Before they reappear, the systems manages to pull the full 220Kpps as before. This is a temporary setup, we'll very soon use an Intel fiber card, but I thought this issue was worth mentioning, as I don't think it's a hardware problem (the switch also reports no errors). The system is running a fresh (yesterday's) RELENG_7. The card is onboard, on a HP DL380 G5. Here's the pciconf output: -- cut here -- pcib13@pci0:2:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xc3 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5715 Broadcom dual gigabit, pci bridge' class = bridge subclass = PCI-PCI bce0@pci0:3:0:0: class=0x020000 card=0x7038103c chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = '5708C Broadcom NetXtreme II Gigabit Ethernet Adapter' class = network subclass = ethernet -- and here -- Regards, Vlad -- ~/.signature: no such file or directory From killing at multiplay.co.uk Wed Dec 10 07:05:10 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Wed Dec 10 07:05:23 2008 Subject: 7.0 unusual performance issue - vmdaemon hang? Message-ID: <38D2AA3D46354E8EA3EE2A1056A1BE4A@multiplay.co.uk> Just had one of hour webservers flag as down here and on investigation the machine seems to be struggling due to a hung vmdaemon process. top is reporting vmdaemon as using a constant 55.57% CPU yet CPU time is not increasing:- last pid: 36492; load averages: 0.04, 0.05, .11 up 89+19:53:21 14:36:08 223 processes: 9 running, 201 sleeping, 13 waiting CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 644M Active, 2780M Inact, 480M Wired, 249M Cache, 214M Buf, 3759M Free Swap: 4096M Total, 537M Used, 3559M Free, 13% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K CPU7 7 2116.4 100.00% idle: cpu7 12 root 1 171 ki31 0K 16K CPU6 6 2059.5 100.00% idle: cpu6 13 root 1 171 ki31 0K 16K CPU5 5 2029.3 100.00% idle: cpu5 14 root 1 171 ki31 0K 16K CPU4 4 1977.8 100.00% idle: cpu4 15 root 1 171 ki31 0K 16K CPU3 3 1912.0 100.00% idle: cpu3 16 root 1 171 ki31 0K 16K CPU2 2 1835.2 100.00% idle: cpu2 17 root 1 171 ki31 0K 16K CPU1 1 1763.1 100.00% idle: cpu1 18 root 1 171 ki31 0K 16K RUN 0 1727.6 100.00% idle: cpu0 37 root 1 20 - 0K 16K psleep 5 0:56 55.57% vmdaemon 60198 www 1 4 0 98M 13516K sbwait 2 35:21 1.46% httpd 60264 www 1 4 0 133M 9248K sbwait 0 21:21 0.39% httpd 30 root 1 -68 - 0K 16K - 7 18.3H 0.00% em1 taskq 29 root 1 -68 - 0K 16K - 6 330:21 0.00% em0 taskq 41 root 1 20 - 0K 16K syncer 1 212:42 0.00% syncer 21 root 1 -44 - 0K 16K WAIT 0 201:02 0.00% swi1: net 19 root 1 -32 - 0K 16K WAIT 0 120:15 0.00% swi4: clock 22 root 1 44 - 0K 16K - 5 73:00 0.00% yarrow I've tried to ktrace the process and it produced nothing, also tried gdb and it failed to attach. Is there anything else I can try before we reboot the machine to help determine what the problem is? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From danny at cs.huji.ac.il Wed Dec 10 07:28:55 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Dec 10 07:29:03 2008 Subject: zfs panics Message-ID: hi, from a solaris or linux client, doing a ls(1) of a nfs exported zfs file, for example: ls /net/zfs-server/h/.zfs/snapshot, panics the server. The server is running latest 7.1-prerelease. when client is freebsd, it mostly works, but in a few cases the server just goes into comma. btw, the server is running vanilla zfs, no tunning, and the server is 64bit with 8gb of memory and quad core (dell-pe2950) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x168 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff804a9175 stack pointer = 0x10:0xffffffffb71fc550 frame pointer = 0x10:0xffffffffb71fc560 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 802 (nfsd) [thread pid 802 tid 100185 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x50(%rdi) db> tr Tracing pid 802 tid 100185 td 0xffffff0004d576e0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vput() at vput+0x45 nfsrv_readdirplus() at nfsrv_readdirplus+0x83e nfssvc() at nfssvc+0x400 syscall() at syscall+0x1bb Xfast_syscall() at Xfast_syscall+0xab --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x8006885cc, rsp = 0x7fffffffea2 From jh at saunalahti.fi Wed Dec 10 08:18:20 2008 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Wed Dec 10 08:18:27 2008 Subject: zfs panics In-Reply-To: References: Message-ID: <20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi> Hi, On 2008-12-10, Danny Braniss wrote: > from a solaris or linux client, doing a ls(1) of a nfs exported zfs file, > for example: ls /net/zfs-server/h/.zfs/snapshot, > panics the server. The server is running latest 7.1-prerelease. This has been reported as PR kern/125149. I have described the problem in this message: http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html See the PR for RELENG_7 patches. (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149) -- Jaakko From jb000003 at mr-happy.com Wed Dec 10 08:20:18 2008 From: jb000003 at mr-happy.com (Jeff Blank) Date: Wed Dec 10 08:20:30 2008 Subject: bce(4) and rx errors In-Reply-To: References: Message-ID: <20081210160325.GA72838@mr-happy.com> On Wed, Dec 10, 2008 at 04:59:26PM +0200, Vlad GALU wrote: > I have an application pulling about 220Kpps from a bce(4) card > (details below). At what seems to be random times, errors start > showing up on that interface (I'm watching it with netstat -w1 -I), so > about 10% of the initial 220Kpps is reported as errors. I'm also seeing a pretty steady stream of errors on both bce interfaces in a Dell PowerEdge 2950 III. In my case, the source is RELENG_7_1 from ~14:00 UTC yesterday (9 Dec). Throughput does not seem to be affected. "sysctl -a | egrep -i 'bce.*err'" yields all zeroes, for whatever that's worth. hostb0@pci0:0:0:0: class=0x060000 card=0x80868086 chip=0x25c08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000X Chipset Memory Controller Hub' class = bridge subclass = HOST-PCI pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x25e28086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 2' class = bridge subclass = PCI-PCI pcib7@pci0:0:3:0: class=0x060400 card=0x00000000 chip=0x25e38086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 3' class = bridge subclass = PCI-PCI pcib8@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x25f88086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x8 Port 4-5' class = bridge subclass = PCI-PCI pcib12@pci0:0:5:0: class=0x060400 card=0x00000000 chip=0x25e58086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 5' class = bridge subclass = PCI-PCI pcib13@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x25f98086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x8 Port 6-7' class = bridge subclass = PCI-PCI pcib16@pci0:0:7:0: class=0x060400 card=0x00000000 chip=0x25e78086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 7' class = bridge subclass = PCI-PCI hostb1@pci0:0:16:0: class=0x060000 card=0x01b21028 chip=0x25f08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Error Reporting Registers' class = bridge subclass = HOST-PCI hostb2@pci0:0:16:1: class=0x060000 card=0x01b21028 chip=0x25f08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Error Reporting Registers' class = bridge subclass = HOST-PCI hostb3@pci0:0:16:2: class=0x060000 card=0x01b21028 chip=0x25f08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Error Reporting Registers' class = bridge subclass = HOST-PCI hostb4@pci0:0:17:0: class=0x060000 card=0x80868086 chip=0x25f18086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Reserved Registers' class = bridge subclass = HOST-PCI hostb5@pci0:0:19:0: class=0x060000 card=0x80868086 chip=0x25f38086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Reserved Registers' class = bridge subclass = HOST-PCI hostb6@pci0:0:21:0: class=0x060000 card=0x80868086 chip=0x25f58086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset FBD Registers' class = bridge subclass = HOST-PCI hostb7@pci0:0:22:0: class=0x060000 card=0x80868086 chip=0x25f68086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset FBD Registers' class = bridge subclass = HOST-PCI pcib17@pci0:0:28:0: class=0x060400 card=0x01b21028 chip=0x26908086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 PCIe Root Port 1' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x01b21028 chip=0x26888086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x01b21028 chip=0x26898086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x01b21028 chip=0x268a8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x01b21028 chip=0x268b8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x01b21028 chip=0x268c8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB2 Enhanced Host Controller' class = serial bus subclass = USB pcib19@pci0:0:30:0: class=0x060401 card=0x00000000 chip=0x244e8086 rev=0xd9 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x26708086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x01b21028 chip=0x269e8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Ultra ATA Storage Controller' class = mass storage subclass = ATA pcib2@pci0:4:0:0: class=0x060400 card=0x00000000 chip=0x35008086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe Upstream Port' class = bridge subclass = PCI-PCI pcib6@pci0:4:0:3: class=0x060400 card=0x00000000 chip=0x350c8086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe to PCI-X Bridge' class = bridge subclass = PCI-PCI pcib3@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x35108086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe Downstream Port E1' class = bridge subclass = PCI-PCI pcib5@pci0:5:1:0: class=0x060400 card=0x00000000 chip=0x35148086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe Downstream Port E2' class = bridge subclass = PCI-PCI pcib4@pci0:6:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xc3 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5715 Broadcom dual gigabit, pci bridge' class = bridge subclass = PCI-PCI bce0@pci0:7:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = '5708C Broadcom NetXtreme II Gigabit Ethernet Adapter' class = network subclass = ethernet mpt0@pci0:1:0:0: class=0x010000 card=0x1f101028 chip=0x00581000 rev=0x08 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS 3000 series, 8-port with 1068E -StorPort' class = mass storage subclass = SCSI pcib9@pci0:10:0:0: class=0x060400 card=0x00000000 chip=0x8018111d rev=0x0e hdr=0x01 vendor = 'Integrated Device Technology Inc.' class = bridge subclass = PCI-PCI pcib10@pci0:11:2:0: class=0x060400 card=0x00000000 chip=0x8018111d rev=0x0e hdr=0x01 vendor = 'Integrated Device Technology Inc.' class = bridge subclass = PCI-PCI pcib11@pci0:11:4:0: class=0x060400 card=0x00000000 chip=0x8018111d rev=0x0e hdr=0x01 vendor = 'Integrated Device Technology Inc.' class = bridge subclass = PCI-PCI igb0@pci0:12:0:0: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb1@pci0:12:0:1: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb2@pci0:13:0:0: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb3@pci0:13:0:1: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet pcib14@pci0:15:0:0: class=0x060400 card=0x00000000 chip=0x03298086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6700PXH PCI Express-to-PCI Express Bridge A' class = bridge subclass = PCI-PCI pcib15@pci0:15:0:2: class=0x060400 card=0x00000000 chip=0x032a8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6700PXH PCI Express-to-PCI Express Bridge B' class = bridge subclass = PCI-PCI pcib18@pci0:2:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xc3 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5715 Broadcom dual gigabit, pci bridge' class = bridge subclass = PCI-PCI bce1@pci0:3:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = '5708C Broadcom NetXtreme II Gigabit Ethernet Adapter' class = network subclass = ethernet vgapci0@pci0:19:13:0: class=0x030000 card=0x01b21028 chip=0x515e1002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon ES1000 Radeon ES1000' class = display subclass = VGA From mikej at rogers.com Wed Dec 10 08:59:52 2008 From: mikej at rogers.com (Mike Jakubik) Date: Wed Dec 10 08:59:59 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> <493D9BC6.8050902@delphij.net> <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> Message-ID: <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> On Mon, December 8, 2008 5:22 pm, Mike Jakubik wrote: > On Mon, December 8, 2008 5:12 pm, Xin LI wrote: > >> Which version are you currently using? My previous commit only fixes >> the excessive interrupt issue, I think this could be a different >> problem, I'm taking a look at the code to see if I can have something >> for you. > > I was running on the version just prior to the latest interrupt commit. I > have now updated to the one with the interrupt fix. Will let you know if > things change. > > Thank You. The interrupt rate has decreased significantly, however i am still having having problem with applications that hold stateful connections. The rx errors are also still showing, i suspect this is related to the problem. How can i roll back this driver to the last known good version? Thanks. From mikej at rogers.com Wed Dec 10 09:01:14 2008 From: mikej at rogers.com (Mike Jakubik) Date: Wed Dec 10 09:01:21 2008 Subject: bce(4) and rx errors In-Reply-To: <20081210160325.GA72838@mr-happy.com> References: <20081210160325.GA72838@mr-happy.com> Message-ID: On Wed, December 10, 2008 11:03 am, Jeff Blank wrote: > On Wed, Dec 10, 2008 at 04:59:26PM +0200, Vlad GALU wrote: >> I have an application pulling about 220Kpps from a bce(4) card >> (details below). At what seems to be random times, errors start >> showing up on that interface (I'm watching it with netstat -w1 -I), so >> about 10% of the initial 220Kpps is reported as errors. > > I'm also seeing a pretty steady stream of errors on both bce > interfaces in a Dell PowerEdge 2950 III. In my case, the source > is RELENG_7_1 from ~14:00 UTC yesterday (9 Dec). Throughput does not > seem to be affected. "sysctl -a | egrep -i 'bce.*err'" yields all > zeroes, for whatever that's worth. See the "RELENG_7_1: bce driver change generating too much interrupts ?" thread. This problem as surfaced since the recent bce driver changes. From delphij at delphij.net Wed Dec 10 09:47:31 2008 From: delphij at delphij.net (Xin LI) Date: Wed Dec 10 09:47:40 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> <493D9BC6.8050902@delphij.net> <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> Message-ID: <494000A5.2050107@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Jakubik wrote: > On Mon, December 8, 2008 5:22 pm, Mike Jakubik wrote: >> On Mon, December 8, 2008 5:12 pm, Xin LI wrote: >> >>> Which version are you currently using? My previous commit only fixes >>> the excessive interrupt issue, I think this could be a different >>> problem, I'm taking a look at the code to see if I can have something >>> for you. >> I was running on the version just prior to the latest interrupt commit. I >> have now updated to the one with the interrupt fix. Will let you know if >> things change. >> >> Thank You. > > The interrupt rate has decreased significantly, however i am still having > having problem with applications that hold stateful connections. The rx > errors are also still showing, i suspect this is related to the problem. > How can i roll back this driver to the last known good version? If you are using CVS to track the -stable tree: cd /usr/src/sys/dev/bce cvs -q up -rRELENG_7 -D2008/11/01 If not, then the process would be a bit complicated. You need to checkout from anoncvs, e.g.: cvs -q -d anoncvs@anoncvs.freebsd.org:/home/ncvs login cvs -q -d anoncvs@anoncvs.freebsd.org:/home/ncvs co -rRELENG_7 - -D2008/11/01 sys/dev/bce cd sys/dev/bce cp * /sys/dev/bce Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklAAKUACgkQi+vbBBjt66AhrwCfXI5aPX3q/E26KcW7HovtPSct LnoAn0QNK/l65eYMiUvGBDUfHDyeXJ9Z =r8So -----END PGP SIGNATURE----- From peterjeremy at optushome.com.au Wed Dec 10 10:06:03 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Dec 10 10:06:17 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> <20081210091107.GC1320@alf.bsdes.net> Message-ID: <20081210180559.GC58682@server.vk2pj.dyndns.org> On 2008-Dec-10 10:55:35 +0100, S?ren Schmidt wrote: >And you will not use 64bit DMA even if the chipset supports it. >However I have not seen any chipsets supporting this fail, YMMV as >usual :) There's a reference in wikipedia pointing to http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06694.html that claims the AMD/ATI SB600 lies about supporting 64-bit DMA in AHCI mode. I have a SB600 but it doesn't have >4GB to test on. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081210/08e2de87/attachment.pgp From dudu at dudu.ro Wed Dec 10 10:52:58 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Dec 10 10:53:05 2008 Subject: bce(4) and rx errors In-Reply-To: References: <20081210160325.GA72838@mr-happy.com> Message-ID: On 12/10/08, Mike Jakubik wrote: > On Wed, December 10, 2008 11:03 am, Jeff Blank wrote: > > On Wed, Dec 10, 2008 at 04:59:26PM +0200, Vlad GALU wrote: > >> I have an application pulling about 220Kpps from a bce(4) card > >> (details below). At what seems to be random times, errors start > >> showing up on that interface (I'm watching it with netstat -w1 -I), so > >> about 10% of the initial 220Kpps is reported as errors. > > > > I'm also seeing a pretty steady stream of errors on both bce > > interfaces in a Dell PowerEdge 2950 III. In my case, the source > > is RELENG_7_1 from ~14:00 UTC yesterday (9 Dec). Throughput does not > > seem to be affected. "sysctl -a | egrep -i 'bce.*err'" yields all > > zeroes, for whatever that's worth. > > > See the "RELENG_7_1: bce driver change generating too much interrupts ?" > thread. This problem as surfaced since the recent bce driver changes. Thanks Mike, I'll give it a shot. -- ~/.signature: no such file or directory From dudu at dudu.ro Wed Dec 10 11:27:50 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Dec 10 11:27:58 2008 Subject: bce(4) and rx errors In-Reply-To: References: <20081210160325.GA72838@mr-happy.com> Message-ID: On 12/10/08, Vlad GALU wrote: > On 12/10/08, Mike Jakubik wrote: > > On Wed, December 10, 2008 11:03 am, Jeff Blank wrote: > > > On Wed, Dec 10, 2008 at 04:59:26PM +0200, Vlad GALU wrote: > > >> I have an application pulling about 220Kpps from a bce(4) card > > >> (details below). At what seems to be random times, errors start > > >> showing up on that interface (I'm watching it with netstat -w1 -I), so > > >> about 10% of the initial 220Kpps is reported as errors. > > > > > > I'm also seeing a pretty steady stream of errors on both bce > > > interfaces in a Dell PowerEdge 2950 III. In my case, the source > > > is RELENG_7_1 from ~14:00 UTC yesterday (9 Dec). Throughput does not > > > seem to be affected. "sysctl -a | egrep -i 'bce.*err'" yields all > > > zeroes, for whatever that's worth. > > > > > > See the "RELENG_7_1: bce driver change generating too much interrupts ?" > > thread. This problem as surfaced since the recent bce driver changes. > > > Thanks Mike, I'll give it a shot. Indeed, the errors seem to have gone away after rolling back the driver, as Xin Li suggested in another thread. Sorry for the noise! -- ~/.signature: no such file or directory From bahamasfranks at gmail.com Wed Dec 10 13:15:11 2008 From: bahamasfranks at gmail.com (Steve Franks) Date: Wed Dec 10 13:15:18 2008 Subject: why can't multiple programs listen to cuaXYZ anymore? (7-stable) Message-ID: <539c60b90812101248x2a964288w4e310a536c8b0fc@mail.gmail.com> Before my last cvsup, I could have cutecom & a custom configuration app (i.e gpsd) running at the same time on the same serial port. Any incoming data, both would echo it, and as long as only one was outputting data, that worked fine too. Now it's 'broke'. I hear noise about TTY changes, I assume that changed the underlying devices, as well? This used to be a major perk over windows for embedded systems guys like me....makes debugging serial devices a snap. Steve From pyunyh at gmail.com Wed Dec 10 18:49:43 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Dec 10 18:49:56 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210140823.GF1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081210140823.GF1320@alf.bsdes.net> Message-ID: <20081211024932.GC42370@cdnetworks.co.kr> On Wed, Dec 10, 2008 at 03:08:24PM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: [...] > > > > > > It seems that your controller supports MSI so you can set a tunable > > > > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > > > > /boot/loader.conf file.) However there were several issues on re(4) > > > > > > w.r.t MSI so it was off by default. > > > > > > > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > > > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > > > > > > > Yeah it's an undocmented feature. But most drivers written by me > > > > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > > > > the tunable. > > > > > > I think it could be great if you could document it or at least > > > show it by default when you do sysctl -ad with a small description. > > > > > > > If MSI worked as expected I would have documented it as I did > > in msk(4)/nfe(4)/ale(4)/age(4)/jme(4) etc. > > Using MSI on RealTek does not seem to stable. I tried hard to fix > > that but some users still reported watchdog timeouts. Working > > without documentation and hardware also made it hard to complete > > the work. This was the main reason why MSI was disabled on re(4). > > What do you think about adding a note in the man page telling that > it's experimental and in some cases it could improve the situation > but in others it will give errors? Based on the your testing I have idea how to mitigate the missing Tx completion interrupt. If all goes well re(4) could reliably take advantage of MSI on RealTek controllers. If that miserably fail I would do as you suggested. > > > > I think re(4) in HEAD needs more testing. As you might know RealTek > > produced too many chipsets. :-( > > Ok, i'll use the backported driver as it works better for me :-) > > If i can help you testing any patches i'm more than welcome to do it. > > Thanks a lot for your help Pyun YongHyeon. > You're welcome. -- Regards, Pyun YongHyeon From tom.hurst at clara.net Wed Dec 10 19:21:41 2008 From: tom.hurst at clara.net (Thomas Hurst) Date: Wed Dec 10 19:21:48 2008 Subject: visibility of release process In-Reply-To: <20081209205806.6e3f0c5e@baby-jane> References: <20081208182112.GW58682@server.vk2pj.dyndns.org> <02D7BFFB-7B09-42DB-BBDF-F83AFDE45BD3@verweg.com> <20081209205806.6e3f0c5e@baby-jane> Message-ID: <20081211025632.GA69815@voi.aagh.net> * Patrick Lamaizi?re (patfbsd@davenulle.org) wrote: > Ruben van Staveren a ?crit : > > Though experimental, I'm greatly enjoying > > http://www.secnetix.de/olli/FreeBSD/svnews/?p=/stable/7 > > Nice. There is also http://freshbsd.org/ (really cool IMHO). Thanks; I write/run that. I'm currently developing version 2, which should bring much better performance and more powerful filtering; e.g. by filename, multiple committers, branches, etc, as well as history all the way back to r1. Since it's working off a local SVN mirror rather than commit emails, it's also feasable to support things like local copies of diffs. Of course, now I need to generalize it back to the other BSD's -- Thomas 'Freaky' Hurst http://hur.st/ From victor at bsdes.net Wed Dec 10 23:57:10 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Wed Dec 10 23:57:18 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210120719.GK37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> Message-ID: <20081211075707.GH1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > Also i didn't see any problem with interfaces going up and down, > > but that usually happen after some hours of uptime, so i'll let > > you know if the error happens again. > > After writing to the HD with dd for a few hours and using stress -i 10 -d 10 the machine lost connectivity. I waited until today to be sure if the machine hung, paniced or just lost network connectivity. I don't have local access or serial access, so this is the only way i could do it. I've seen in the logs during the night various messages of: Dec 10 00:33:49 yac kernel: re0: watchdog timeout Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN Dec 10 00:33:52 yac kernel: re0: link state changed to UP The interface never recovered and i wasn't able to ping the machine until i rebooted. Nagios was checking all the time and no recovery happened. The netstat -i in daily scripts shows just one Oerrs. I'm used to have a lot of them, but seems this time the card didn't recover from the only one. I also want to say that this is not a regression, as it happened before with 7.1 -BETA 2 code. Is there anything more i can try? Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From victor at bsdes.net Thu Dec 11 00:00:27 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Thu Dec 11 00:00:45 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081210180559.GC58682@server.vk2pj.dyndns.org> References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> <20081210091107.GC1320@alf.bsdes.net> <20081210180559.GC58682@server.vk2pj.dyndns.org> Message-ID: <20081211080026.GI1320@alf.bsdes.net> On Thu, Dec 11, 2008 at 05:05:59AM +1100, Peter Jeremy wrote: > On 2008-Dec-10 10:55:35 +0100, S?ren Schmidt wrote: > >And you will not use 64bit DMA even if the chipset supports it. > >However I have not seen any chipsets supporting this fail, YMMV as > >usual :) > > There's a reference in wikipedia pointing to > http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06694.html > that claims the AMD/ATI SB600 lies about supporting 64-bit DMA in AHCI > mode. I have a SB600 but it doesn't have >4GB to test on. I have 6 GB of RAM and can test patches, so once i'm done with the re(4) side of things i'll try commenting the code Soren's suggested and see if that improves the situation. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From victor at bsdes.net Thu Dec 11 00:10:47 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Thu Dec 11 00:10:55 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081211075707.GH1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> Message-ID: <20081211081045.GJ1320@alf.bsdes.net> On Thu, Dec 11, 2008 at 08:57:07AM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > > Also i didn't see any problem with interfaces going up and down, > > > but that usually happen after some hours of uptime, so i'll let > > > you know if the error happens again. > > > > > After writing to the HD with dd for a few hours and using > stress -i 10 -d 10 the machine lost connectivity. I waited until > today to be sure if the machine hung, paniced or just lost network > connectivity. I don't have local access or serial access, so this > is the only way i could do it. I've seen in the logs during the > night various messages of: > > > Dec 10 00:33:49 yac kernel: re0: watchdog timeout > Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN > Dec 10 00:33:52 yac kernel: re0: link state changed to UP > > The interface never recovered and i wasn't able to ping the machine > until i rebooted. Nagios was checking all the time and no recovery > happened. > > The netstat -i in daily scripts shows just one Oerrs. I'm used to > have a lot of them, but seems this time the card didn't recover from > the only one. I also want to say that this is not a regression, as > it happened before with 7.1 -BETA 2 code. > > Is there anything more i can try? Sorry it's too early in the morning and i thought today was 10 instead of 11. I don't even know the day i'm today. Looking at today's log i see no link state changed messages but i see this other messages that started happening more or less at the same time i lost connectivity to the server: Dec 10 18:20:32 yac kernel: re0: link state changed to DOWN Dec 10 18:20:32 yac kernel: re0: PHY read failed Sorry for the noise. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From pyunyh at gmail.com Thu Dec 11 01:01:08 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Dec 11 01:01:15 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081211081045.GJ1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> Message-ID: <20081211090056.GH42370@cdnetworks.co.kr> On Thu, Dec 11, 2008 at 09:10:45AM +0100, Victor Balada Diaz wrote: > On Thu, Dec 11, 2008 at 08:57:07AM +0100, Victor Balada Diaz wrote: > > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > > > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > > > Also i didn't see any problem with interfaces going up and down, > > > > but that usually happen after some hours of uptime, so i'll let > > > > you know if the error happens again. > > > > > > > > After writing to the HD with dd for a few hours and using > > stress -i 10 -d 10 the machine lost connectivity. I waited until > > today to be sure if the machine hung, paniced or just lost network > > connectivity. I don't have local access or serial access, so this > > is the only way i could do it. I've seen in the logs during the > > night various messages of: > > > > > > Dec 10 00:33:49 yac kernel: re0: watchdog timeout > > Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN > > Dec 10 00:33:52 yac kernel: re0: link state changed to UP > > > > The interface never recovered and i wasn't able to ping the machine > > until i rebooted. Nagios was checking all the time and no recovery > > happened. > > > > The netstat -i in daily scripts shows just one Oerrs. I'm used to > > have a lot of them, but seems this time the card didn't recover from > > the only one. I also want to say that this is not a regression, as > > it happened before with 7.1 -BETA 2 code. > > > > Is there anything more i can try? > > Sorry it's too early in the morning and i thought today was 10 > instead of 11. I don't even know the day i'm today. > > Looking at today's log i see no link state changed messages > but i see this other messages that started happening more or > less at the same time i lost connectivity to the server: > > Dec 10 18:20:32 yac kernel: re0: link state changed to DOWN > Dec 10 18:20:32 yac kernel: re0: PHY read failed > I've reverted r185756 which caused GMII access issues on some controllers. If you are brave enough to try beta code, you can get latest re(4) in the following URL. Note, I don't have PCIe based RealTek controllers so the code was not tested at all. http://people.freebsd.org/~yongari/re/if_re.c http://people.freebsd.org/~yongari/re/if_rlreg.h -- Regards, Pyun YongHyeon From danny at cs.huji.ac.il Thu Dec 11 01:08:56 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Thu Dec 11 01:09:09 2008 Subject: zfs panics In-Reply-To: <20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi> References: <20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi> Message-ID: > > Hi, > > On 2008-12-10, Danny Braniss wrote: > > from a solaris or linux client, doing a ls(1) of a nfs exported zfs file, > > for example: ls /net/zfs-server/h/.zfs/snapshot, > > panics the server. The server is running latest 7.1-prerelease. > > This has been reported as PR kern/125149. I have described the problem > in this message: > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html > > See the PR for RELENG_7 patches. > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149) > > -- > Jaakko Hi Jaakko, did you apply the patches and it solved the problem? and, btw, which patch? To Jeremy, How about adding a line explaining that it would be prudent to 'zfs set snapdir=hidden' ..., or, of cource fix the bug :-) I will apply the patch/es and see what happens. cheers, danny From victor at bsdes.net Thu Dec 11 01:50:23 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Thu Dec 11 01:50:39 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081211090056.GH42370@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> Message-ID: <20081211095021.GL1320@alf.bsdes.net> On Thu, Dec 11, 2008 at 06:00:56PM +0900, Pyun YongHyeon wrote: > On Thu, Dec 11, 2008 at 09:10:45AM +0100, Victor Balada Diaz wrote: > > On Thu, Dec 11, 2008 at 08:57:07AM +0100, Victor Balada Diaz wrote: > > > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > > > > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > > > > Also i didn't see any problem with interfaces going up and down, > > > > > but that usually happen after some hours of uptime, so i'll let > > > > > you know if the error happens again. > > > > > > > > > > > After writing to the HD with dd for a few hours and using > > > stress -i 10 -d 10 the machine lost connectivity. I waited until > > > today to be sure if the machine hung, paniced or just lost network > > > connectivity. I don't have local access or serial access, so this > > > is the only way i could do it. I've seen in the logs during the > > > night various messages of: > > > > > > > > > Dec 10 00:33:49 yac kernel: re0: watchdog timeout > > > Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN > > > Dec 10 00:33:52 yac kernel: re0: link state changed to UP > > > > > > The interface never recovered and i wasn't able to ping the machine > > > until i rebooted. Nagios was checking all the time and no recovery > > > happened. > > > > > > The netstat -i in daily scripts shows just one Oerrs. I'm used to > > > have a lot of them, but seems this time the card didn't recover from > > > the only one. I also want to say that this is not a regression, as > > > it happened before with 7.1 -BETA 2 code. > > > > > > Is there anything more i can try? > > > > Sorry it's too early in the morning and i thought today was 10 > > instead of 11. I don't even know the day i'm today. > > > > Looking at today's log i see no link state changed messages > > but i see this other messages that started happening more or > > less at the same time i lost connectivity to the server: > > > > Dec 10 18:20:32 yac kernel: re0: link state changed to DOWN > > Dec 10 18:20:32 yac kernel: re0: PHY read failed > > > > I've reverted r185756 which caused GMII access issues on some > controllers. If you are brave enough to try beta code, you can > get latest re(4) in the following URL. Note, I don't have PCIe > based RealTek controllers so the code was not tested at all. > > http://people.freebsd.org/~yongari/re/if_re.c > http://people.freebsd.org/~yongari/re/if_rlreg.h I've recompiled the kernel with the first file in sys/dev/re/ and the second one in sys/pci/. I'm still testing with MSI enabled. So far tried rebooting using nextboot(8) (just in case i lost the network card i could boot again) and the card seems to work but i'll continue stress testing the machine with stress + dd + iperf and see if i can take it down. I'll let you know how it goes. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From danny at cs.huji.ac.il Thu Dec 11 02:28:34 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Thu Dec 11 02:28:41 2008 Subject: zfs panics In-Reply-To: References: <20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi> Message-ID: > > > > Hi, > > > > On 2008-12-10, Danny Braniss wrote: > > > from a solaris or linux client, doing a ls(1) of a nfs exported zfs file, > > > for example: ls /net/zfs-server/h/.zfs/snapshot, > > > panics the server. The server is running latest 7.1-prerelease. > > > > This has been reported as PR kern/125149. I have described the problem > > in this message: > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html > > > > See the PR for RELENG_7 patches. > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149) > > > > -- > > Jaakko > > Hi Jaakko, > did you apply the patches and it solved the problem? > and, btw, which patch? > > To Jeremy, > How about adding a line explaining that it would be > prudent to 'zfs set snapdir=hidden' ..., or, of cource > fix the bug :-) > I will apply the patch/es and see what happens. > > cheers, > danny the patch to nfs_server.c does indeed prevent the panics. danny From arno at heho.snv.jussieu.fr Thu Dec 11 15:16:53 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Thu Dec 11 15:17:00 2008 Subject: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze Message-ID: hello, yet another powerd SOS : on an ASUS M3A78-EM MB with Phenom 9750 and 8 gig memory, starting powerd freezes the box after slowing down a bit cpu frequency. [IMHO] usefull bit of info : FreeBSD m34.scito.local 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Thu Dec 11 14:24:39 CET 2008 root@m34.scito.local:/usr/obj/raid1/bsd/src7/sys/M3A78-EM amd64 CPU: AMD Phenom(tm) 9750 Quad-Core Processor (2410.66-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009> AMD Features=0xee500800 AMD Features2=0x7ff,,,Prefetch,,> Cores per package: 4 usable memory = 8547172352 (8151 MB) avail memory = 8268722176 (7885 MB) ACPI APIC Table: <102408 APIC2239> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <102408 XSDT2239> on motherboard ... cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 dev.cpu.0.freq_levels: 2398/-1 2098/-1 1798/-1 1498/-1 1199/-1 899/-1 599/-1 299/-1 further : - I set debug.cpufreq.lowest superior to 1500 : system remains up but only when pushing really slightly - I set debug.cpufreq.lowest inferior to 1100 : freeze garantueed - I define hint.acpi_throttle.0.disabled="1" in loader.conf then no dev.cpu.0.freq is showing up ... (as if only acpi_throttle is attaching and not powernow) Let me know what I can test further. Best, Arno From ghelmer at palisadesys.com Thu Dec 11 15:18:34 2008 From: ghelmer at palisadesys.com (Guy Helmer) Date: Thu Dec 11 15:18:42 2008 Subject: 7.1RC1: system hang Message-ID: <49419BE0.2070502@palisadesys.com> I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. I've dropped into the kernel debugger on the VGA console and transcribed the following information (if I omit anything critical, let me know -- the machine is still sitting at the debugger prompt) : > where pid 20 tid 100018 td 0xc45008c0 kdb_enter_why scgetc sckdbevent kdbmux_intr kdbmux_kdb_intr taskqueue_run taskqueue_swi_giant_run ithread_loop fork_exit(c063cce0, c44ac590, e4a36d38) at 0xc063a624 = fork_exit+0x94 fork_trampoline() at 0xc07e41a0 = fork_trampoline+0x8 > show allpcpu cpuid 0 in idle cpuid 1: proc 23457 cpuid 2: idle cpuid 3: swi6 proc 20 > show alllocks pid 23708 vmstat: shared sx allproc, exclusive sx sysctl pid 23675 php: exclusive sx user map pid 4630 tcsh: shared sx proctree pid 3838 sshd: shared sx proctree pid 2139 icapd: shared sx proctree pid 1425 postgres: shared sx proctree pid 20 swi6: exclusive sleep mtx Giant > show sleepchain 23708 thread 100050 (pid 23708, vmstat) blocked on sx "user map" XLOCK thread 100056 (pid 23675, initial thread) is on a run queue > show sleepchain 4630 thread 100093 (pid 4630, tcsh) blocked on sx "allproc" SLOCK (count 1) > show sleepchain 3838 thread 100065 (pid 3838, sshd) blocked on sx "allproc" SLOCK (count 1) > show sleepchain 2139 thread 100136 (pid 2139, icapd) blocked on sx "allproc" SLOCK (count 1) > show sleepchain 1425 thread 100140 (pid 1425, initial thread) blocked on sx "allproc" SLOCK (count 1) > where 23708 ... syscall 202 sysctl > where 23675 ... trap 0xc > where 4630 ... syscall 66 vfork > where 3838 ... syscall 2 fork > where 2139 ... syscall 2 fork > where 1425 ... syscall 2 fork Kernel configuration file: ident PALISADE-DEBUG options MUTEX_DEBUG options WITNESS options WITNESS_KDB options WITNESS_SKIPSPIN options KDB options KDB_TRACE options DDB options DDB_NUMSYM options GDB cpu I686_CPU # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols #options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options SHMMAXPGS=4096 # max shared mem pages (4k on i386) options SHMSEG=256 # max shared mem segments per process options SEMMNI=256 # number of semaphore identifiers options SEMMNS=512 # number of semaphores options SEMMNU=256 # number of undo structures options SEMMAP=256 # entries in semaphore map options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options DEVICE_POLLING options MAXDSIZ=(1024UL*1024*1024) # See /sys/conf/NOTES for info options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_FORWARD #packet destination changes options DUMMYNET #Packet shaping # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # AMRR transmit rate control algorithm #device wlan_scan_ap # 802.11 AP mode scanning #device wlan_scan_sta # 802.11 STA mode scanning #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" #device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device rum # Ralink Technology RT2501USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons From m4gicite at gmail.com Thu Dec 11 16:22:34 2008 From: m4gicite at gmail.com (Ryan) Date: Thu Dec 11 16:22:41 2008 Subject: Install issues with 7.x In-Reply-To: <49103869.3080709@FreeBSD.org> References: <490F40CB.8040605@FreeBSD.org> <49103869.3080709@FreeBSD.org> Message-ID: Finally had time to understand some how release works and made some new cds. Some new updates to the situation since as I am still having issues. I was not able to figure out how to make release with a custom kernel, would always fail that step so I had to stick with GENERIC. To simulate taking out firewire support I just deleted the corresponding kernel modules in /boot/kernel and remade the iso. Stable as of 12-07-2008 is giving the same feedback as 7.1-B2 but actually gives a panic screen. panic: run_interrupt_driven_config_hooks: waited too long cpuid = 0 KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> There has been a bios update recently and have applied it, but there has been no change in any of the tests by a quick glance. If it makes a difference the cds I create with cdrecord generate the added errors acd0: FAILURE - READ BIG timed out. I don't think that has anything to do with it, just saying it for full disclosure. Disregard if irrelevant. That error applies to only the stable builds I made. On Tue, Nov 4, 2008 at 11:56 AM, Joel Dahl wrote: > Ryan skrev: >> >> Sadly with the quality of BIOS recently, that is not an option. Not >> much to offer. Attached is a picture of what I have to change. Other >> and XP are the same, Vista unlocks AHCI. >> >> Another way of accomplishing disabling firewire is to remake the >> install CD with a different kernel and not quite sure how to do that. > > Take a look at the release(7) manpage for information about building your > own customized release CD. > > -- > Joel > > From pyunyh at gmail.com Thu Dec 11 17:31:17 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Dec 11 17:31:24 2008 Subject: Regression in vr - not receiveing multicast In-Reply-To: References: <20081209114723.GE33723@cdnetworks.co.kr> <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]> Message-ID: <20081212013110.GF46707@cdnetworks.co.kr> On Wed, Dec 10, 2008 at 08:06:16AM +0100, Goran Lowkrantz wrote: > --On December 9, 2008 12:53:05 +0100 Goran Lowkrantz > wrote: > > >--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon > >wrote: > > > >>On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote: > >> > Hi, > >> > > >> > in July, vr had this problem and was fixed: > >> > > >> > > >> > > >> > but now it's back again! > >> > > >> > >>There was just one bug fix since then and I guess the fix is not > >>related with your issue. > >> > >> > On a system with the following: > >> > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 > >> > > >> > I have to set all vr interfaces in promisc to get routing info. > >> > > >> > Using Quagga > >> > # pkg_info -Ix uagga > >> > quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route > >>software > > >> > on an inner network using RIPv2 > >> > # ifmcstat -i vr0 > >> > vr0: > >> > inet xxx.xxx.xxx.xxx > >> > group 224.0.0.9 > >> > igmpv2 > >> > mcast-macaddr 01:00:5e:00:00:09 refcnt 1 > >> > group 224.0.0.1 > >> > mcast-macaddr 01:00:5e:00:00:01 refcnt 1 > >> > > >> > > >> > On the same box, we have some em devices also and they work without > >>any > problems. > >> > > >> > >>There is fundamental differences between em(4) and vr(4). The > >>vr(4) for VT6105M takes advantage of perfect multicast filtering > >>feature which is not present on all em(4) interface. Perfect > >>multicast filtering can reduce unwanted multicast traffics such > >>that it could save a lot of CPU cycles. The downside is that vr(4) > >>cannot accept multicast frames for a multicast group without > >>joining the multicast group first. > >>For multicast routing purpose I guess 'options MROUTING' kernel > >>option should be enabled to accept all multicast frames. > >>Does your kernel have that option? > > > >No it has not. I will create such a beast and return with stories. > > > > > I have tried with 'options MROUTING' and it didn't work. > > Did I miss something? Do I have to install and run mrouted also? > > It seems like maybe the first two packages are accepted after registration > as I don't lose the routes until after about 6 min uptime. But to get > further updates, I need the interfaces in promisc. > > So, next step? FYI: I've disabled multicast perfect filtering(r185962). -- Regards, Pyun YongHyeon From onemda at gmail.com Thu Dec 11 19:00:43 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Dec 11 19:00:51 2008 Subject: 7.1RC1: system hang In-Reply-To: <49419BE0.2070502@palisadesys.com> References: <49419BE0.2070502@palisadesys.com> Message-ID: <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> On 12/12/08, Guy Helmer wrote: > I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout > as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. I've dropped > into the kernel debugger on the VGA console and transcribed the > following information (if I omit anything critical, let me know -- the > machine is still sitting at the debugger prompt) : > > > where > pid 20 tid 100018 td 0xc45008c0 > kdb_enter_why > scgetc > sckdbevent > kdbmux_intr > kdbmux_kdb_intr > taskqueue_run > taskqueue_swi_giant_run > ithread_loop > fork_exit(c063cce0, c44ac590, e4a36d38) at 0xc063a624 = fork_exit+0x94 > fork_trampoline() at 0xc07e41a0 = fork_trampoline+0x8 > > > show allpcpu > cpuid 0 in idle > cpuid 1: proc 23457 > cpuid 2: idle > cpuid 3: swi6 proc 20 what is proc 23457? -- Paul From rebehn at ant.uni-bremen.de Fri Dec 12 01:27:43 2008 From: rebehn at ant.uni-bremen.de (Heinrich Rebehn) Date: Fri Dec 12 01:27:50 2008 Subject: iir(4) support under 7.1 In-Reply-To: References: Message-ID: <903DEF0D-724B-4A56-95DC-A557F203E5E1@ant.uni-bremen.de> On Dec 10, 2008, at 2:54 PM, Heinrich Rebehn wrote: > Hi list, > > i am planning to upgrade our main server from 6.1 to 7.1. > The machine has a ICP Vortex GDT8524RZ raid controller which is > handled buy the iir(4) driver. > > Since i have seen various discussions in the past about Adaptec no > longer supporting these controllers, driver reaching EOE, data > corruption in 64bit configurtions with > 4G RAM and so on, i just > wanted to ask what the current state of the driver is. > > Thanks for your help, > Hmmm? nobody using this stuff anymore??? -Heinrich From rink at FreeBSD.org Fri Dec 12 01:49:05 2008 From: rink at FreeBSD.org (Rink Springer) Date: Fri Dec 12 01:49:13 2008 Subject: iir(4) support under 7.1 In-Reply-To: <903DEF0D-724B-4A56-95DC-A557F203E5E1@ant.uni-bremen.de> References: <903DEF0D-724B-4A56-95DC-A557F203E5E1@ant.uni-bremen.de> Message-ID: <20081212094912.GA54988@rink.nu> Hi Heinrich, On Fri, Dec 12, 2008 at 10:27:41AM +0100, Heinrich Rebehn wrote: > Hmmm? nobody using this stuff anymore??? FWIW, we have some IBM servers which feature an iir(4) too and they are unusuable on >=7.0 - the iir(4) does not initialize correctly anymore. I don't have details since I am seldomly near the machines, but if anyone is willing to aid, I'm willing to look into it. Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From victor at bsdes.net Fri Dec 12 04:13:12 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Fri Dec 12 04:13:20 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081211095021.GL1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> <20081211095021.GL1320@alf.bsdes.net> Message-ID: <20081212121309.GM1320@alf.bsdes.net> On Thu, Dec 11, 2008 at 10:50:21AM +0100, Victor Balada Diaz wrote: > On Thu, Dec 11, 2008 at 06:00:56PM +0900, Pyun YongHyeon wrote: > > > > I've reverted r185756 which caused GMII access issues on some > > controllers. If you are brave enough to try beta code, you can > > get latest re(4) in the following URL. Note, I don't have PCIe > > based RealTek controllers so the code was not tested at all. > > > > http://people.freebsd.org/~yongari/re/if_re.c > > http://people.freebsd.org/~yongari/re/if_rlreg.h > > I've recompiled the kernel with the first file in sys/dev/re/ > and the second one in sys/pci/. I'm still testing with MSI enabled. > > So far tried rebooting using nextboot(8) (just in case i lost the > network card i could boot again) and the card seems to work > but i'll continue stress testing the machine with stress + dd + > iperf and see if i can take it down. I'll let you know how it goes. After a day of stress testing the machine haven't got errors, interrupt storms or interface up/down problems. Everything seems fine. I'll continue stress testing the machine during the weekend, but i would say that this time it's fixed. Seems lately there have been a lot of testing of this driver. Is there any chance of it being on 7.1 or being MFCed after the release to RELENG_7? Thanks a lot. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From rebehn at ant.uni-bremen.de Fri Dec 12 05:00:32 2008 From: rebehn at ant.uni-bremen.de (Heinrich Rebehn) Date: Fri Dec 12 05:00:39 2008 Subject: iir(4) support under 7.1 In-Reply-To: <20081212094912.GA54988@rink.nu> References: <903DEF0D-724B-4A56-95DC-A557F203E5E1@ant.uni-bremen.de> <20081212094912.GA54988@rink.nu> Message-ID: On Dec 12, 2008, at 10:49 AM, Rink Springer wrote: > Hi Heinrich, > > On Fri, Dec 12, 2008 at 10:27:41AM +0100, Heinrich Rebehn wrote: >> Hmmm? nobody using this stuff anymore??? > > FWIW, we have some IBM servers which feature an iir(4) too and they > are > unusuable on >=7.0 - the iir(4) does not initialize correctly anymore. > > I don't have details since I am seldomly near the machines, but if > anyone is willing to aid, I'm willing to look into it. > Huh, that does sound like a showstopper :-( But thanks for that warning anyway! -Heinrich From bengta at sics.se Fri Dec 12 05:07:56 2008 From: bengta at sics.se (Bengt Ahlgren) Date: Fri Dec 12 05:08:29 2008 Subject: Proper use of LD_LIBRARY_PATH for Linux progs? Message-ID: Hi! I ran into a problem with programs exec:ed by print/acroread8 picking up Linux libraries and thus failed to run. This includes the print program in the print dialogue and the browser configured in edit/preferences/internet. The reason is that the acroread launch script sets LD_LIBRARY_PATH which is propagated to its childs. See this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/129553 Question 1: anybody else that sees this problem? Question 2: what is the "proper" way to fix this problem? (specifically for acroread8, but also in general.) Bengt Ps. Sorry for cross-posting - don't know which list to use for this issue. From ghelmer at palisadesys.com Fri Dec 12 05:34:58 2008 From: ghelmer at palisadesys.com (Guy Helmer) Date: Fri Dec 12 05:35:06 2008 Subject: 7.1RC1: system hang In-Reply-To: <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> References: <49419BE0.2070502@palisadesys.com> <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> Message-ID: <49426880.40302@palisadesys.com> Paul B. Mahol wrote: > On 12/12/08, Guy Helmer wrote: > >> I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout >> as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. I've dropped >> into the kernel debugger on the VGA console and transcribed the >> following information (if I omit anything critical, let me know -- the >> machine is still sitting at the debugger prompt) : >> >> > where >> pid 20 tid 100018 td 0xc45008c0 >> kdb_enter_why >> scgetc >> sckdbevent >> kdbmux_intr >> kdbmux_kdb_intr >> taskqueue_run >> taskqueue_swi_giant_run >> ithread_loop >> fork_exit(c063cce0, c44ac590, e4a36d38) at 0xc063a624 = fork_exit+0x94 >> fork_trampoline() at 0xc07e41a0 = fork_trampoline+0x8 >> >> > show allpcpu >> cpuid 0 in idle >> cpuid 1: proc 23457 >> cpuid 2: idle >> cpuid 3: swi6 proc 20 >> > > > what is proc 23457? > proc 23457 is "filter", an Autonomy KeyView Filter API program (extracts text out of various document formats) that is being run using FreeBSD 6 compatibility libraries. Guy From rink at FreeBSD.org Fri Dec 12 05:54:08 2008 From: rink at FreeBSD.org (Rink Springer) Date: Fri Dec 12 05:54:15 2008 Subject: iir(4) support under 7.1 In-Reply-To: <20081212094912.GA54988@rink.nu> References: <903DEF0D-724B-4A56-95DC-A557F203E5E1@ant.uni-bremen.de> <20081212094912.GA54988@rink.nu> Message-ID: <20081212135415.GB26330@rink.nu> On Fri, Dec 12, 2008 at 10:49:12AM +0100, Rink Springer wrote: > Hi Heinrich, > > On Fri, Dec 12, 2008 at 10:27:41AM +0100, Heinrich Rebehn wrote: > > Hmmm? nobody using this stuff anymore??? > > FWIW, we have some IBM servers which feature an iir(4) too and they are > unusuable on >=7.0 - the iir(4) does not initialize correctly anymore. Err, I meant "Intel" servers... -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From onemda at gmail.com Fri Dec 12 07:29:32 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Dec 12 07:29:40 2008 Subject: 7.1RC1: system hang In-Reply-To: <49426880.40302@palisadesys.com> References: <49419BE0.2070502@palisadesys.com> <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> <49426880.40302@palisadesys.com> Message-ID: <3a142e750812120729v478d850do93e31e5d8502ef68@mail.gmail.com> On 12/12/08, Guy Helmer wrote: > Paul B. Mahol wrote: >> On 12/12/08, Guy Helmer wrote: >> >>> I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout >>> as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. I've dropped >>> into the kernel debugger on the VGA console and transcribed the >>> following information (if I omit anything critical, let me know -- the >>> machine is still sitting at the debugger prompt) : >>> >>> > where >>> pid 20 tid 100018 td 0xc45008c0 >>> kdb_enter_why >>> scgetc >>> sckdbevent >>> kdbmux_intr >>> kdbmux_kdb_intr >>> taskqueue_run >>> taskqueue_swi_giant_run >>> ithread_loop >>> fork_exit(c063cce0, c44ac590, e4a36d38) at 0xc063a624 = fork_exit+0x94 >>> fork_trampoline() at 0xc07e41a0 = fork_trampoline+0x8 >>> >>> > show allpcpu >>> cpuid 0 in idle >>> cpuid 1: proc 23457 >>> cpuid 2: idle >>> cpuid 3: swi6 proc 20 >>> >> >> >> what is proc 23457? >> > proc 23457 is "filter", an Autonomy KeyView Filter API program (extracts > text out of various document formats) that is being run using FreeBSD 6 > compatibility libraries. > > Guy > > Could you give most interesting part of "ps" output. -- Paul From cpghost at cordula.ws Fri Dec 12 08:12:51 2008 From: cpghost at cordula.ws (cpghost) Date: Fri Dec 12 08:13:04 2008 Subject: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze In-Reply-To: References: Message-ID: <20081212161248.GA5905@phenom.cordula.ws> On Fri, Dec 12, 2008 at 12:01:29AM +0100, Arno J. Klaassen wrote: > yet another powerd SOS : on an ASUS M3A78-EM MB with > Phenom 9750 and 8 gig memory, starting powerd freezes > the box after slowing down a bit cpu frequency. (... snip ...) > dev.cpu.0.freq_levels: 2398/-1 2098/-1 1798/-1 1498/-1 1199/-1 899/-1 599/-1 299/-1 > > further : > > - I set debug.cpufreq.lowest superior to 1500 : system remains > up but only when pushing really slightly > > - I set debug.cpufreq.lowest inferior to 1100 : freeze > garantueed Same here. Running with debug.cpufreq.lowest="1240" in /boot/loader.conf to prevent freezes. This is a FreeBSD 7.1-PRERELEASE #0: Sat Nov 8 14:18:05 CET 2008 root@textbox:/usr/obj/usr/src/sys/GENERIC running in amd64 and i386 mode with ACPI enabled (default): CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009> AMD Features=0xee500800 AMD Features2=0x7ff,,, Prefetch,,> Cores per package: 4 using an MSI board with SB600 chipset and newest BIOS. No idea why the system freezes below approx 1200 MHz. But apparently, this bug is quite common and affects a lot of systems with Phenoms. :( > - I define hint.acpi_throttle.0.disabled="1" in loader.conf > then no dev.cpu.0.freq is showing up ... (as if > only acpi_throttle is attaching and not powernow) > > Let me know what I can test further. > > Best, Arno Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From njaguar at d2jsp.org Fri Dec 12 10:17:32 2008 From: njaguar at d2jsp.org (Paul Taulborg) Date: Fri Dec 12 10:17:41 2008 Subject: Adaptec AIC-9410 Message-ID: Hello, I just recently purchased two new Supermicro servers: SYS-6025B-3R SYS-6015B-3R Both of these have an Adaptec AIC-9410 SAS controller in them, that is apparently not detected (or supported?) by FreeBSD (amd64) (7.0 or 7.1 RC1) Is there any way to get FreeBSD to detect this controller (and drives on it)? I found some conversations from 2006 about this, but no updates since. Thanks in advance, and hoping to be able to get this working. From ghelmer at palisadesys.com Fri Dec 12 11:54:38 2008 From: ghelmer at palisadesys.com (Guy Helmer) Date: Fri Dec 12 11:54:45 2008 Subject: 7.1RC1: system hang In-Reply-To: <3a142e750812120729v478d850do93e31e5d8502ef68@mail.gmail.com> References: <49419BE0.2070502@palisadesys.com> <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> <49426880.40302@palisadesys.com> <3a142e750812120729v478d850do93e31e5d8502ef68@mail.gmail.com> Message-ID: <4942C178.2030206@palisadesys.com> Paul B. Mahol wrote: > On 12/12/08, Guy Helmer wrote: > >> Paul B. Mahol wrote: >> >>> On 12/12/08, Guy Helmer wrote: >>> >>> >>>> I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout >>>> as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. I've dropped >>>> into the kernel debugger on the VGA console and transcribed the >>>> following information (if I omit anything critical, let me know -- the >>>> machine is still sitting at the debugger prompt) : >>>> >>>> > where >>>> pid 20 tid 100018 td 0xc45008c0 >>>> kdb_enter_why >>>> scgetc >>>> sckdbevent >>>> kdbmux_intr >>>> kdbmux_kdb_intr >>>> taskqueue_run >>>> taskqueue_swi_giant_run >>>> ithread_loop >>>> fork_exit(c063cce0, c44ac590, e4a36d38) at 0xc063a624 = fork_exit+0x94 >>>> fork_trampoline() at 0xc07e41a0 = fork_trampoline+0x8 >>>> >>>> > show allpcpu >>>> cpuid 0 in idle >>>> cpuid 1: proc 23457 >>>> cpuid 2: idle >>>> cpuid 3: swi6 proc 20 >>>> >>>> >>> what is proc 23457? >>> >>> >> proc 23457 is "filter", an Autonomy KeyView Filter API program (extracts >> text out of various document formats) that is being run using FreeBSD 6 >> compatibility libraries. >> >> Guy >> >> >> > > Could you give most interesting part of "ps" output. > I've hooked up a serial console and I'll wait for the problem to occur again to to get the "ps" output -- there's about 70 active processes on the system, and transcribing from the VGA console is taking forever... Guy From pepe at rdc.cl Fri Dec 12 11:56:47 2008 From: pepe at rdc.cl (Jose Amengual M) Date: Fri Dec 12 11:56:54 2008 Subject: intel dp45sg and Intel Matrix Raid 5 problem Message-ID: Hi guys. I'm not pretty sure is this is the correct list but here we go. I have a intel dp45sg with RAID 5 on 4 hard drives of 160 gb each and FreeBSD 7.0-p5. It was working fine until two hours ago, the last message on the console after the server got frozen was "ad8 Detached" or something like that and "ar0 in Degraded mode". So, the server was not responding so I reboot it then I enter to the Intel Matrix console menu ( ctrl + I ) and the Raid was degraded, so I identify the disk I turn off the server then connect the new hard drive and then boot up again, after that in the Intel MAtrix console ask me that the new hard drive was not in the RAID so I I want to add to it, I sat "Yes" and then in the status tab appear "Rebuild". Before rebooting again I took a look to the documentation of intel matrix and they say that after the boot of the operating system, the rebuild process will start, So I reboot it again and I saw the "FreeBSD F1" menu and then I got "No boot loader". no /boot/loader After that I boot from the cd and I realize that the partition and the Slices are there, but the serve does not boot. I found a link about "Vital intel ICH7 patches for freebsd 6 and 7", but how can I apply the patches is I can boot ? Can some one help me please!!!! Thanks a lot. From arno at heho.snv.jussieu.fr Fri Dec 12 12:36:48 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Fri Dec 12 12:37:00 2008 Subject: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze In-Reply-To: <20081212161248.GA5905@phenom.cordula.ws> References: <20081212161248.GA5905@phenom.cordula.ws> Message-ID: cpghost writes: > On Fri, Dec 12, 2008 at 12:01:29AM +0100, Arno J. Klaassen wrote: > > yet another powerd SOS : on an ASUS M3A78-EM MB with > > Phenom 9750 and 8 gig memory, starting powerd freezes > > the box after slowing down a bit cpu frequency. > > (... snip ...) > > > dev.cpu.0.freq_levels: 2398/-1 2098/-1 1798/-1 1498/-1 1199/-1 899/-1 599/-1 299/-1 > > > > further : > > > > - I set debug.cpufreq.lowest superior to 1500 : system remains > > up but only when pushing really slightly > > > > - I set debug.cpufreq.lowest inferior to 1100 : freeze > > garantueed > > Same here. Running with > debug.cpufreq.lowest="1240" > in /boot/loader.conf to prevent freezes. > > This is a FreeBSD 7.1-PRERELEASE #0: Sat Nov 8 14:18:05 CET 2008 > root@textbox:/usr/obj/usr/src/sys/GENERIC > running in amd64 and i386 mode with ACPI enabled (default): > > CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 > Features=0x178bfbff PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x802009> > AMD Features=0xee500800 3DNow!+,3DNow!> > AMD Features2=0x7ff,,, > Prefetch,,> > Cores per package: 4 > > using an MSI board with SB600 chipset and newest BIOS. > > No idea why the system freezes below approx 1200 MHz. But apparently, > this bug is quite common and affects a lot of systems with Phenoms. :( do Phenoms not support powernow? I am a bit puzzled by the differnce with two X2 boards I have around here : FreeBSD 7.1-PRERELEASE #0: Tue Dec 2 20:09:28 ... CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (2992.52-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 ... cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 FreeBSD 7.1-PRERELEASE #1: Mon Nov 17 14:40:26 ... CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-62 (2109.70-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 ... cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 powernow1: on cpu1 whereas the Phenom says : CPU: AMD Phenom(tm) 9750 Quad-Core Processor (2410.66-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009> AMD Features=0xee500800 AMD Features2=0x7ff,,,Prefetch,,> ... cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 my conclusion : acpi_throttle attaches a X4 (why not) and not at X2 (thought the Turion seems to detect it but fails to attach), powernow does not seem to attach to X4 ... Best regards, Arno > > - I define hint.acpi_throttle.0.disabled="1" in loader.conf > > then no dev.cpu.0.freq is showing up ... (as if > > only acpi_throttle is attaching and not powernow) > > > > Let me know what I can test further. > > > > Best, Arno > > Regards, > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ From jkim at FreeBSD.org Fri Dec 12 13:27:08 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Dec 12 13:27:15 2008 Subject: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze In-Reply-To: References: <20081212161248.GA5905@phenom.cordula.ws> Message-ID: <200812121626.56590.jkim@FreeBSD.org> On Friday 12 December 2008 03:36 pm, Arno J. Klaassen wrote: > cpghost writes: > > On Fri, Dec 12, 2008 at 12:01:29AM +0100, Arno J. Klaassen wrote: > > > yet another powerd SOS : on an ASUS M3A78-EM MB with > > > Phenom 9750 and 8 gig memory, starting powerd freezes > > > the box after slowing down a bit cpu frequency. > > > > (... snip ...) > > > > > dev.cpu.0.freq_levels: 2398/-1 2098/-1 1798/-1 1498/-1 1199/-1 > > > 899/-1 599/-1 299/-1 > > > > > > further : > > > > > > - I set debug.cpufreq.lowest superior to 1500 : system remains > > > up but only when pushing really slightly > > > > > > - I set debug.cpufreq.lowest inferior to 1100 : freeze > > > garantueed > > > > Same here. Running with > > debug.cpufreq.lowest="1240" > > in /boot/loader.conf to prevent freezes. > > > > This is a FreeBSD 7.1-PRERELEASE #0: Sat Nov 8 14:18:05 CET 2008 > > root@textbox:/usr/obj/usr/src/sys/GENERIC > > running in amd64 and i386 mode with ACPI enabled (default): > > > > CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz > > K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = > > 3 > > > > Features=0x178bfbff >TRR, PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > Features2=0x802009> > > AMD > > Features=0xee500800 > 3DNow!+,3DNow!> > > AMD Features2=0x7ff,,, > > Prefetch,,> > > Cores per package: 4 > > > > using an MSI board with SB600 chipset and newest BIOS. > > > > No idea why the system freezes below approx 1200 MHz. But > > apparently, this bug is quite common and affects a lot of systems > > with Phenoms. :( > > do Phenoms not support powernow? [SNIP] "Phenom" is 10H family processor and it has Cool`n'Quiet 2.0. Someone wrote a driver for it and it was posted on freebsd-current in September: http://lists.freebsd.org/pipermail/freebsd-current/2008-September/088330.html http://lists.freebsd.org/pipermail/freebsd-current/2008-September/088803.html http://lists.freebsd.org/pipermail/freebsd-current/2008-September/088806.html Jung-uk Kim From jkim at FreeBSD.org Fri Dec 12 13:39:15 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Dec 12 13:39:22 2008 Subject: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze In-Reply-To: <200812121626.56590.jkim@FreeBSD.org> References: <200812121626.56590.jkim@FreeBSD.org> Message-ID: <200812121639.06698.jkim@FreeBSD.org> On Friday 12 December 2008 04:26 pm, Jung-uk Kim wrote: > On Friday 12 December 2008 03:36 pm, Arno J. Klaassen wrote: > > cpghost writes: > > > On Fri, Dec 12, 2008 at 12:01:29AM +0100, Arno J. Klaassen wrote: > > > > yet another powerd SOS : on an ASUS M3A78-EM MB with > > > > Phenom 9750 and 8 gig memory, starting powerd freezes > > > > the box after slowing down a bit cpu frequency. > > > > > > (... snip ...) > > > > > > > dev.cpu.0.freq_levels: 2398/-1 2098/-1 1798/-1 1498/-1 > > > > 1199/-1 899/-1 599/-1 299/-1 > > > > > > > > further : > > > > > > > > - I set debug.cpufreq.lowest superior to 1500 : system > > > > remains up but only when pushing really slightly > > > > > > > > - I set debug.cpufreq.lowest inferior to 1100 : freeze > > > > garantueed > > > > > > Same here. Running with > > > debug.cpufreq.lowest="1240" > > > in /boot/loader.conf to prevent freezes. > > > > > > This is a FreeBSD 7.1-PRERELEASE #0: Sat Nov 8 14:18:05 CET > > > 2008 root@textbox:/usr/obj/usr/src/sys/GENERIC > > > running in amd64 and i386 mode with ACPI enabled (default): > > > > > > CPU: AMD Phenom(tm) 9350e Quad-Core Processor (2000.08-MHz > > > K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping > > > = 3 > > > > > > Features=0x178bfbff > >,M TRR, PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > Features2=0x802009> > > > AMD > > > Features=0xee500800 > > 3DNow!+,3DNow!> > > > AMD Features2=0x7ff,,, > > > Prefetch,,> > > > Cores per package: 4 > > > > > > using an MSI board with SB600 chipset and newest BIOS. > > > > > > No idea why the system freezes below approx 1200 MHz. But > > > apparently, this bug is quite common and affects a lot of > > > systems with Phenoms. :( > > > > do Phenoms not support powernow? > > [SNIP] > > "Phenom" is 10H family processor and it has Cool`n'Quiet 2.0. > Someone wrote a driver for it and it was posted on freebsd-current > in September: > > http://lists.freebsd.org/pipermail/freebsd-current/2008-September/0 >88330.html > http://lists.freebsd.org/pipermail/freebsd-current/2008-September/0 >88803.html > http://lists.freebsd.org/pipermail/freebsd-current/2008-September/0 >88806.html I forgot there is a PR with the latest driver: http://www.freebsd.org/cgi/query-pr.cgi?pr=128575 Jung-uk Kim From arno at heho.snv.jussieu.fr Fri Dec 12 13:49:45 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Fri Dec 12 13:49:52 2008 Subject: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze In-Reply-To: <200812121639.06698.jkim@FreeBSD.org> References: <200812121626.56590.jkim@FreeBSD.org> <200812121639.06698.jkim@FreeBSD.org> Message-ID: Jung-uk Kim writes: > On Friday 12 December 2008 04:26 pm, Jung-uk Kim wrote: > > On Friday 12 December 2008 03:36 pm, Arno J. Klaassen wrote: > > > cpghost writes: > > > > On Fri, Dec 12, 2008 at 12:01:29AM +0100, Arno J. Klaassen > wrote: > > > > > > > > [ .. stuff deleted .. ] > > > > > > > do Phenoms not support powernow? > > > > [SNIP] > > > > "Phenom" is 10H family processor and it has Cool`n'Quiet 2.0. > > Someone wrote a driver for it and it was posted on freebsd-current > > in September: > > > > http://lists.freebsd.org/pipermail/freebsd-current/2008-September/0 > >88330.html > > http://lists.freebsd.org/pipermail/freebsd-current/2008-September/0 > >88803.html > > http://lists.freebsd.org/pipermail/freebsd-current/2008-September/0 > >88806.html > > I forgot there is a PR with the latest driver: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128575 ah, I see. Thank you very much. I'll give it a try this WE Best, Arno From pyunyh at gmail.com Fri Dec 12 17:42:40 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Dec 12 17:42:47 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081212121309.GM1320@alf.bsdes.net> References: <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> <20081211095021.GL1320@alf.bsdes.net> <20081212121309.GM1320@alf.bsdes.net> Message-ID: <20081213014229.GC51320@cdnetworks.co.kr> On Fri, Dec 12, 2008 at 01:13:09PM +0100, Victor Balada Diaz wrote: > On Thu, Dec 11, 2008 at 10:50:21AM +0100, Victor Balada Diaz wrote: > > On Thu, Dec 11, 2008 at 06:00:56PM +0900, Pyun YongHyeon wrote: > > > > > > I've reverted r185756 which caused GMII access issues on some > > > controllers. If you are brave enough to try beta code, you can > > > get latest re(4) in the following URL. Note, I don't have PCIe > > > based RealTek controllers so the code was not tested at all. > > > > > > http://people.freebsd.org/~yongari/re/if_re.c > > > http://people.freebsd.org/~yongari/re/if_rlreg.h > > > > I've recompiled the kernel with the first file in sys/dev/re/ > > and the second one in sys/pci/. I'm still testing with MSI enabled. > > > > So far tried rebooting using nextboot(8) (just in case i lost the > > network card i could boot again) and the card seems to work > > but i'll continue stress testing the machine with stress + dd + > > iperf and see if i can take it down. I'll let you know how it goes. > > After a day of stress testing the machine haven't got errors, interrupt > storms or interface up/down problems. Everything seems fine. > I'll continue stress testing the machine during the weekend, but > i would say that this time it's fixed. > Thanks for testing! > Seems lately there have been a lot of testing of this driver. Is > there any chance of it being on 7.1 or being MFCed after the release > to RELENG_7? > It's too early to say MFC but I think MFC would be done after releasing 7.1-RELEASE if all goes well. -- Regards, Pyun YongHyeon From arno at heho.snv.jussieu.fr Sat Dec 13 06:26:53 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sat Dec 13 06:27:02 2008 Subject: 7.1-PRERELEASE: asus M3A / Phenom X4 / powerd freeze In-Reply-To: <200812121639.06698.jkim@FreeBSD.org> References: <200812121626.56590.jkim@FreeBSD.org> <200812121639.06698.jkim@FreeBSD.org> Message-ID: Jung-uk Kim writes: > On Friday 12 December 2008 04:26 pm, Jung-uk Kim wrote: > > On Friday 12 December 2008 03:36 pm, Arno J. Klaassen wrote: > > > cpghost writes: > > > > On Fri, Dec 12, 2008 at 12:01:29AM +0100, Arno J. Klaassen > wrote: > > > > > yet another powerd SOS : on an ASUS M3A78-EM MB with > > > > > Phenom 9750 and 8 gig memory, starting powerd freezes > > > > > the box after slowing down a bit cpu frequency. > > > > > > > > (... snip ...) > > > > > I forgot there is a PR with the latest driver: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128575 yes, this works better : kldload cpufreq : hwpstate0: on cpu0 hwpstate0: SVI mode hwpstate0: you have 2 P-state. hwpstate0: freq=2400MHz volts=1300mV hwpstate0: freq=1200MHz volts=1050mV hwpstate0: Now P0-state. hwpstate1: on cpu1 hwpstate1: SVI mode hwpstate1: you have 2 P-state. hwpstate1: freq=2400MHz volts=1300mV hwpstate1: freq=1200MHz volts=1050mV hwpstate1: Now P0-state. hwpstate2: on cpu2 hwpstate2: SVI mode hwpstate2: you have 2 P-state. hwpstate2: freq=2400MHz volts=1300mV hwpstate2: freq=1200MHz volts=1050mV hwpstate2: Now P0-state. hwpstate3: on cpu3 hwpstate3: SVI mode hwpstate3: you have 2 P-state. hwpstate3: freq=2400MHz volts=1300mV hwpstate3: freq=1200MHz volts=1050mV hwpstate3: Now P0-state. however, I need to disable acpi_throttle; standard, I get : [root@m34 ~]# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2398/-1 2098/-1 1798/-1 1498/-1 1199/-1 899/-1 599/-1 299/-1 [root@m34 ~]# kldload cpufreq [root@m34 ~]# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 1050/-1 900/-1 750/-1 600/-1 450/-1 300/-1 150/-1 [root@m34 ~]# powerd -v powerd: unable to determine AC line status idle time > 90%, decreasing clock speed from 2398 MHz to -1 MHz powerd: error setting CPU frequency -1: Invalid argument idle time > 90%, decreasing clock speed from 2398 MHz to -1 MHz powerd: error setting CPU frequency -1: Invalid argument rebooting with hint.acpi_throttle.0.disabled="1" gives : [root@m34 ~]# sysctl dev.cpu.0.freq_levels sysctl: unknown oid 'dev.cpu.0.freq_levels' [root@m34 ~]# kldload cpufreq [root@m34 ~]# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2400/-1 1200/-1 [root@m34 ~]# powerd -v powerd: unable to determine AC line status idle time > 90%, decreasing clock speed from 2400 MHz to 1200 MHz Thanx, Arno From bms at incunabulum.net Sat Dec 13 09:43:30 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Dec 13 09:43:37 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> <493CEE90.7050104@FreeBSD.org> <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> Message-ID: <4943F43B.4060105@incunabulum.net> Paul B. Mahol wrote: > On 12/8/08, Bruce M. Simpson wrote: > >> I have rolled a port for ext2fuse: >> http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar >> > > Ignoring fact that is buggy, slooow and port doesnt have any cache implemented > and port leaves files behind in share/doc/ext2fuse when package > deleted it looks fine. > Can you please relay this feedback to the authors of ext2fuse? As mentioned earlier in the thread, the ext2fuse code could benefit from UBLIO-ization. Are you or any other volunteers happy to help out here? Can you elaborate further on the files being left behind by the port? I didn't see this issue in my own testing. thank you BMS From bms at incunabulum.net Sat Dec 13 09:55:37 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Dec 13 09:55:44 2008 Subject: FreeBSD 7.1-RC1 Available... In-Reply-To: <1228877345.35416.27.camel@bauer.cse.buffalo.edu> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> <1228877345.35416.27.camel@bauer.cse.buffalo.edu> Message-ID: <4943F715.9030008@incunabulum.net> I've been tracking 7.1 on 3 separate machines since around September without any issues (1 server, 1 desktop, 1 laptop). Thank you for all your hard work on this. cheers BMS From bms at incunabulum.net Sat Dec 13 10:01:26 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Dec 13 10:01:34 2008 Subject: Regression in vr - not receiveing multicast In-Reply-To: <47381931A80CB93CADD10DC7@[172.16.2.128]> References: <20081209114723.GE33723@cdnetworks.co.kr> <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]> <20081210071932.GD37837@cdnetworks.co.kr> <47381931A80CB93CADD10DC7@[172.16.2.128]> Message-ID: <4943F872.9080009@incunabulum.net> Goran Lowkrantz wrote: >> >> Can you see ALLMULTI flag from the output of "ifconfig vr0"? >> > No -> > # ifconfig vr0 > vr0: flags=8943 metric > 0 mtu 1500 > options=284b > ether 00:00:24:c8:e0:9c > inet xxx.xxx.xxx.xxx netmask 0xfffffff8 broadcast xxx.xxx.xxx.yyy > media: Ethernet autoselect (100baseTX ) > status: active Only a client of the MROUTING socket-level API (e.g. mrouted, XORP, pimdd, pimsd) is able to cause the kernel to enable ALLMULTI on an interface by itself. You will need to get a multicast routing daemon of some kind running to test this. mrouted is OK for testing very simple configurations, although it has been de-orbitted as far as the 'Net itself is concerned. thanks BMS From Alexander at Leidinger.net Sat Dec 13 12:26:54 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Dec 13 12:27:00 2008 Subject: Proper use of LD_LIBRARY_PATH for Linux progs? In-Reply-To: <20081213211115.1274360bbklovuas@webmail.leidinger.net> References: <20081213211115.1274360bbklovuas@webmail.leidinger.net> Message-ID: <20081213211753.172124oke0p9oqdc@webmail.leidinger.net> Quoting Alexander Leidinger (from Sat, 13 Dec 2008 21:11:15 +0100): > Quoting Bengt Ahlgren (from Fri, 12 Dec 2008 > 13:37:25 +0100): > >> The reason is that the acroread launch script sets LD_LIBRARY_PATH >> which is propagated to its childs. See this PR: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/129553 > >> Question 2: what is the "proper" way to fix this problem? >> (specifically for acroread8, but also in general.) > > Search the archive for the ports mailinglist, in the mail > "print/acroread8: LD_LIBRARY_PATH breaks helper programs" is a fix > for the problem. ROTFL... this mail on ports@ is from you... :-) I suggest to contact the port maintainer with the fix. If he doesn't answer, send a PR. As soon as someone (maintainer / other committer in the PR case) has time and motivation, the fix will get committed. Bye, Alexander (ENOTIME ATM, else I would have taken care about this already). -- Gordon's first law: If a research project is not worth doing, it is not worth doing well. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Sat Dec 13 12:26:54 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Dec 13 12:27:08 2008 Subject: Proper use of LD_LIBRARY_PATH for Linux progs? In-Reply-To: References: Message-ID: <20081213211115.1274360bbklovuas@webmail.leidinger.net> Quoting Bengt Ahlgren (from Fri, 12 Dec 2008 13:37:25 +0100): > The reason is that the acroread launch script sets LD_LIBRARY_PATH > which is propagated to its childs. See this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/129553 > Question 2: what is the "proper" way to fix this problem? > (specifically for acroread8, but also in general.) Search the archive for the ports mailinglist, in the mail "print/acroread8: LD_LIBRARY_PATH breaks helper programs" is a fix for the problem. In general: there's no general fix. It all depends why LD_LIBRARY_PATH is used and what is done. There are multiple ways, some are workarounds ("env LD_LIBRARY_PATH='' lpr ..." ), some (like the one for acroread in the mail) are good fixes. Bye, Alexander. -- Disclose classified information only when a NEED TO KNOW exists. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From onemda at gmail.com Sat Dec 13 14:03:54 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Dec 13 14:04:02 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <4943F43B.4060105@incunabulum.net> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> <493CEE90.7050104@FreeBSD.org> <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> <4943F43B.4060105@incunabulum.net> Message-ID: <3a142e750812131403p31841403ub9d5693278c74111@mail.gmail.com> On 12/13/08, Bruce Simpson wrote: > Paul B. Mahol wrote: >> On 12/8/08, Bruce M. Simpson wrote: >> >>> I have rolled a port for ext2fuse: >>> http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar >>> >> >> Ignoring fact that is buggy, slooow and port doesnt have any cache >> implemented >> and port leaves files behind in share/doc/ext2fuse when package >> deleted it looks fine. >> > > Can you please relay this feedback to the authors of ext2fuse? > > As mentioned earlier in the thread, the ext2fuse code could benefit from > UBLIO-ization. Are you or any other volunteers happy to help out here? Well, first higher priority would be to fix existing bugs. It would be very little gain with user cache, because it is already too much IMHO slow and adding user cache will not make it faster, but that is not port problem. > Can you elaborate further on the files being left behind by the port? I > didn't see this issue in my own testing. It install files in this way: test -z "/usr/local/share/doc/ext2fuse" || ./install-sh -c -d "/usr/local/share/doc/ext2fuse" make deinstall and pkg_delete doesnt not remove that files/dir, -- Paul From bms at incunabulum.net Sat Dec 13 16:15:30 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat Dec 13 16:15:37 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <3a142e750812131403p31841403ub9d5693278c74111@mail.gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125150342.GL2042@deviant.kiev.zoral.com.ua> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> <493CEE90.7050104@FreeBSD.org> <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> <4943F43B.4060105@incunabulum.net> <3a142e750812131403p31841403ub9d5693278c74111@mail.gmail.com> Message-ID: <4944501E.40900@incunabulum.net> Paul B. Mahol wrote: >> Can you please relay this feedback to the authors of ext2fuse? >> >> As mentioned earlier in the thread, the ext2fuse code could benefit from >> UBLIO-ization. Are you or any other volunteers happy to help out here? >> > > Well, first higher priority would be to fix existing bugs. It would be > very little > gain with user cache, because it is already too much IMHO slow and > adding user cache > will not make it faster, but that is not port problem. > I'm not aware of bugs with ext2fuse itself; my work on the port was merely to try to raise awareness that a user-space project for ext2 filesystem access existed. Can you elaborate further on your experience with ext2fuse which seems to you to be buggy, i.e. symptoms, root cause analysis etc. ? Have you reported these to the author(s)? Have you measured the performance? Is the performance sufficient for the needs of an occasional desktop user? I realise we are largely involved in content-free argument here, however the trade-off of ext2fuse vs ext2fs in the FreeBSD kernel source tree, is that of a hopefully more actively maintained implementation vs one which is not maintained at all, and any alternatives for FreeBSD users would be welcome. thanks BMS From delphij at delphij.net Sun Dec 14 01:36:47 2008 From: delphij at delphij.net (Xin LI) Date: Sun Dec 14 01:36:56 2008 Subject: bce(4) and rx errors In-Reply-To: References: <20081210160325.GA72838@mr-happy.com> Message-ID: <4944D3A3.8040505@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Gents, I have not yet talked this with David but it looks like this patch would make it disappear. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklE06IACgkQi+vbBBjt66DwjgCeJ1RO+gL3mu13zAzXpPsbDi/R /BwAmQFAij74yusRq+KbcSNb3BMbLzNX =1zx3 -----END PGP SIGNATURE----- -------------- next part -------------- Index: if_bce.c =================================================================== --- if_bce.c (revision 186076) +++ if_bce.c (working copy) @@ -7408,7 +7408,6 @@ (u_long) sc->stat_IfInMBUFDiscards + (u_long) sc->stat_Dot3StatsAlignmentErrors + (u_long) sc->stat_Dot3StatsFCSErrors + - (u_long) sc->stat_IfInFramesL2FilterDiscards + (u_long) sc->stat_IfInRuleCheckerDiscards + (u_long) sc->stat_IfInFTQDiscards + (u_long) sc->com_no_buffers; From delphij at delphij.net Sun Dec 14 01:57:53 2008 From: delphij at delphij.net (Xin LI) Date: Sun Dec 14 01:57:59 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> <493D9BC6.8050902@delphij.net> <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> Message-ID: <4944D894.6070306@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Jakubik wrote: > On Mon, December 8, 2008 5:22 pm, Mike Jakubik wrote: >> On Mon, December 8, 2008 5:12 pm, Xin LI wrote: >> >>> Which version are you currently using? My previous commit only fixes >>> the excessive interrupt issue, I think this could be a different >>> problem, I'm taking a look at the code to see if I can have something >>> for you. >> I was running on the version just prior to the latest interrupt commit. I >> have now updated to the one with the interrupt fix. Will let you know if >> things change. >> >> Thank You. > > The interrupt rate has decreased significantly, however i am still having > having problem with applications that hold stateful connections. The rx > errors are also still showing, i suspect this is related to the problem. > How can i roll back this driver to the last known good version? Hi, Mike, I think they are different problems. Could you, please, give me feedback about whether: - The old driver does not trigger the problem? - The patched driver restore all the old driver behavior? ============= Rationale for my patch. To say it simply, it removes "Received L2 packets discarded" value from being counted from ierror. In the past, we count the following: - Undersize packets - Oversized packets - Received packets discarded due to lack of controller buffer memory - Alignment errors - Frame check sequence errors Now, it counts the following four stuff as well: - Received L2 packets discarded ** removed - Received packets discarded by rule - Received packet FTQ discards - Valid packets received but no RX buffers available I have checked the old FreeBSD driver and the Linux driver, both have the "Received L2 packets discarded" value increasing every second, so I don't believe that this is a real problem. I'll double check with David to make sure about this. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklE2JQACgkQi+vbBBjt66Bl0gCfZ6NVNXpC2ynUZjaZButg+4jo vgYAnAzE2iFWcZMZ29j3qtpwQ5f0xh9V =3l8f -----END PGP SIGNATURE----- -------------- next part -------------- Index: if_bce.c =================================================================== --- if_bce.c (revision 186076) +++ if_bce.c (working copy) @@ -7408,7 +7408,6 @@ (u_long) sc->stat_IfInMBUFDiscards + (u_long) sc->stat_Dot3StatsAlignmentErrors + (u_long) sc->stat_Dot3StatsFCSErrors + - (u_long) sc->stat_IfInFramesL2FilterDiscards + (u_long) sc->stat_IfInRuleCheckerDiscards + (u_long) sc->stat_IfInFTQDiscards + (u_long) sc->com_no_buffers; From onemda at gmail.com Sun Dec 14 07:47:29 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Dec 14 07:47:42 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <4944501E.40900@incunabulum.net> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> <493CEE90.7050104@FreeBSD.org> <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> <4943F43B.4060105@incunabulum.net> <3a142e750812131403p31841403ub9d5693278c74111@mail.gmail.com> <4944501E.40900@incunabulum.net> Message-ID: <3a142e750812140747r2eb5ebadp7ac2b2c8ae357bae@mail.gmail.com> On 12/14/08, Bruce M Simpson wrote: > Paul B. Mahol wrote: >>> Can you please relay this feedback to the authors of ext2fuse? >>> >>> As mentioned earlier in the thread, the ext2fuse code could benefit from >>> UBLIO-ization. Are you or any other volunteers happy to help out here? >>> >> >> Well, first higher priority would be to fix existing bugs. It would be >> very little >> gain with user cache, because it is already too much IMHO slow and >> adding user cache >> will not make it faster, but that is not port problem. >> > > I'm not aware of bugs with ext2fuse itself; my work on the port was > merely to try to raise awareness that a user-space project for ext2 > filesystem access existed. > > Can you elaborate further on your experience with ext2fuse which seems > to you to be buggy, i.e. symptoms, root cause analysis etc. ? Have you > reported these to the author(s)? I have read TODO. > Have you measured the performance? Is the performance sufficient for the > needs of an occasional desktop user? Performance was not sufficient, and adding user cache will not improve access speed on first read. After mounting ext2fs volume (via md(4)) created with e2fsprogs port and copying data from ufs to ext2, reading was quite slow. Also ext2fuse after mount doesnt exits it is still running displaying debug data - explaining why project itselfs is in alpha state. > I realise we are largely involved in content-free argument here, however > the trade-off of ext2fuse vs ext2fs in the FreeBSD kernel source tree, > is that of a hopefully more actively maintained implementation vs one > which is not maintained at all, and any alternatives for FreeBSD users > would be welcome. Project itself doesnt look very active, but I may be wrong. It is in alpha state as reported on SF. IMHO it is better to maintain our own because it is in better shape, but I'm not intersted in ext* as developer. -- Paul From jb000003 at mr-happy.com Sun Dec 14 13:06:56 2008 From: jb000003 at mr-happy.com (Jeff Blank) Date: Sun Dec 14 13:07:03 2008 Subject: bce(4) and rx errors In-Reply-To: <4944D3A3.8040505@delphij.net> References: <20081210160325.GA72838@mr-happy.com> <4944D3A3.8040505@delphij.net> Message-ID: <20081214204738.GA35372@mr-happy.com> On Sun, Dec 14, 2008 at 01:36:35AM -0800, Xin LI wrote: > I have not yet talked this with David but it looks like this patch would > make it disappear. Applied to 7.1-RC1, and rx errors are gone. Thank you! Jeff From davidn04 at gmail.com Mon Dec 15 00:24:02 2008 From: davidn04 at gmail.com (David N) Date: Mon Dec 15 00:24:12 2008 Subject: Running rsnapshot via cron reboots the machine Message-ID: <4d7dd86f0812142358t714cb96erdf269573ac86ba30@mail.gmail.com> Hi, I have a machine AMD Sepron LE-1150 ASUS M2A-VM 1GB RAM ECC 2x SATA 300GB in a RAID 1 (gmirror). 7.0-RELEASE-p2 AMD64 generic kernel it was doing backups via bacula to an external disk USB 2.0 SATA disk, and it was working well. (GLabel) /dev/ufs/BackupDisk I changed to rsnapshot recently, with the External HDD in glabel + gjournal (/dev/da0s1.journal -> /dev/ufs/BackupDisk) and it will reboot the machine roughly 30 minutes after the rsnapshot starts via CRON. If i run rsnapshot without CRON, eg. via the command line it works fine. (I'm compiling the new kernel p6 whilst doing an rsnapshot via the command line) I have changed the time it does the rsnapshot, from 3AM (reboots at 3:30-3:40AM roughly) to 4:30AM (reboots at 5AM roughly). So its nothing running on the system doing it. If i remove the rsnapshot from the CRON, the computer stays on and doesn't reboot. Its not the power supply, and the computer is on a UPS and the UPS log hasn't reported any blackouts. (There are 2 other servers that doesn't turn off so its not a blackout). I left gstat and top running L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| acd0 0 125 125 4164 5.5 0 0 0.0 29.9| ad4 0 0 0 0 0.0 0 0 0.0 0.0| ad4s1 0 0 0 0 0.0 0 0 0.0 0.0| ad4s2 0 125 125 4164 5.6 0 0 0.0 30.5| ad4s3 34 142 71 9079 9.4 71 8697 212.0 99.3| da0 34 142 71 9079 9.6 71 8697 213.5 99.3| da0s1 0 0 0 0 0.0 0 0 0.0 0.0| da0s1c 7 135 71 9079 9.7 64 8184 33.0 85.1| da0s1.journal 0 125 125 4164 9.2 0 0 0.0 39.8| ad6 7 135 71 9079 9.7 64 8184 36.2 91.9| ufs/BackupDisk 0 0 0 0 0.0 0 0 0.0 0.0| ad6s1 0 0 0 0 0.0 0 0 0.0 0.0| ad6s2 0 125 125 4164 9.3 0 0 0.0 40.4| ad6s3 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s2 0 125 125 8328 9.9 0 0 0.0 43.9| mirror/gm0s3 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1a 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1b 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1c 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1d 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s2c 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s2d 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s3c 0 125 125 8328 10.2 0 0 0.0 45.2| mirror/gm0s3d last pid: 18829; load averages: 0.29, 0.45, 0.50 up 1+01:31:23 05:01:50 64 processes: 1 running, 63 sleeping CPU states: 16.5% user, 0.0% nice, 25.2% system, 3.0% interrupt, 55.3% idle Mem: 69M Active, 436M Inact, 395M Wired, 44M Cache, 108M Buf, 3944K Free Swap: 2048M Total, 308K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 18634 root 1 -4 0 15224K 2244K getblk 0:45 9.47% rsync 18633 root 1 98 0 18296K 4576K select 0:45 4.69% rsync 18375 root 1 8 0 20556K 8412K wait 7:20 0.00% perl 4447 root 1 -64 0 7656K 2036K RUN 1:21 0.00% top 4321 root 1 8 0 11784K 2008K nanslp 0:45 0.00% gstat 18627 root 1 96 0 15224K 2596K select 0:36 0.00% rsync 4219 evxadmin 1 96 0 32936K 3220K select 0:07 0.00% sshd 3800 evxadmin 1 96 0 32936K 3164K select 0:06 0.00% sshd 18629 root 1 96 0 32868K 3964K select 0:04 0.00% sshd 18628 root 1 96 0 23764K 7664K select 0:04 0.00% ssh 851 root 1 96 0 12476K 1832K select 0:04 0.00% nmbd 1788 root 1 96 0 10576K 2812K select 0:02 0.00% sendmail 1147 root 1 96 0 24456K 2404K select 0:01 0.00% nmbd 1346 root 1 96 0 22224K 2504K select 0:01 0.00% nmbd 3957 evxadmin 1 96 0 32936K 3220K select 0:01 0.00% sshd 1800 root 1 8 0 5736K 1032K nanslp 0:01 0.00% cron 1754 root 1 8 0 5736K 980K nanslp 0:00 0.00% cron 1557 root 1 8 0 5736K 980K nanslp 0:00 0.00% cron 1387 root 1 8 0 5736K 980K nanslp 0:00 0.00% cron 1192 root 1 8 0 5736K 980K nanslp 0:00 0.00% cron 4646 root 1 96 0 36968K 4892K select 0:00 0.00% smbd 775 root 1 96 0 4684K 1064K select 0:00 0.00% syslogd Nothing else seems to be running. Its driving me insane! any help would be appreciated. smart says the HDD are fine. Regards David N From victor at bsdes.net Mon Dec 15 01:02:10 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Mon Dec 15 01:02:18 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081212121309.GM1320@alf.bsdes.net> References: <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> <20081211095021.GL1320@alf.bsdes.net> <20081212121309.GM1320@alf.bsdes.net> Message-ID: <20081215090207.GN1320@alf.bsdes.net> On Fri, Dec 12, 2008 at 01:13:09PM +0100, Victor Balada Diaz wrote: > On Thu, Dec 11, 2008 at 10:50:21AM +0100, Victor Balada Diaz wrote: > > On Thu, Dec 11, 2008 at 06:00:56PM +0900, Pyun YongHyeon wrote: > > > > > > I've reverted r185756 which caused GMII access issues on some > > > controllers. If you are brave enough to try beta code, you can > > > get latest re(4) in the following URL. Note, I don't have PCIe > > > based RealTek controllers so the code was not tested at all. > > > > > > http://people.freebsd.org/~yongari/re/if_re.c > > > http://people.freebsd.org/~yongari/re/if_rlreg.h > > > > I've recompiled the kernel with the first file in sys/dev/re/ > > and the second one in sys/pci/. I'm still testing with MSI enabled. > > > > So far tried rebooting using nextboot(8) (just in case i lost the > > network card i could boot again) and the card seems to work > > but i'll continue stress testing the machine with stress + dd + > > iperf and see if i can take it down. I'll let you know how it goes. > > After a day of stress testing the machine haven't got errors, interrupt > storms or interface up/down problems. Everything seems fine. > I'll continue stress testing the machine during the weekend, but > i would say that this time it's fixed. Stopped stress testing this morning. After all the weekend testing seems the re(4) problems were fixed. No single interface up/down error. netstat -i reports no errors and everything is fine. Thanks a lot! I'm going to deploy the patches on our production machines. I've been able to trigger interrupt storms with ATA code, though. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From victor at bsdes.net Mon Dec 15 01:07:12 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Mon Dec 15 01:07:25 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> <20081210091107.GC1320@alf.bsdes.net> Message-ID: <20081215090710.GO1320@alf.bsdes.net> On Wed, Dec 10, 2008 at 10:55:35AM +0100, S?ren Schmidt wrote: > On 10Dec, 2008, at 10:11 , Victor Balada Diaz wrote: > > > >Thanks for explaining me what the flags do. I'm not skilled enough > >to create > >the DMA quirks but if you could give me some patches i'll test them. > >Also > >if you have any other idea on what could i test or how can i debug > >this > >it would be more than welcome. > > > Comment out the following two lines in ata_ahci_dmainit(): > > if (ATA_INL(ctlr->r_res2, ATA_AHCI_CAP) & ATA_AHCI_CAP_64BIT) > ch->dma->max_address = BUS_SPACE_MAXADDR; > > And you will not use 64bit DMA even if the chipset supports it. > However I have not seen any chipsets supporting this fail, YMMV as > usual :) > Hello S?ren, I'm triggering interrupt storms with this chipset after a few days of stressing the HD calling sysutils/stress with stress -d 10 -i 10 and in other term, doing: while true; do dd if=/dev/zero of=BAH bs=1M count=1024; done; Right now, as reported by systat -vmstat i have 578k interrupts in atapci and the machine is idle. Do you have any idea on how could i debug this? any advice would be much more than welcome. Thanks a lot. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From uspoerlein at gmail.com Mon Dec 15 01:30:23 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Mon Dec 15 01:30:31 2008 Subject: moused(8) ate my umass(4) devices, it's true! Message-ID: <20081215093019.GB1496@roadrunner.spoerlein.net> Hey all, I've observed a very weird behaviour with my USB stick for quite a while now (probably 4 months; sadly, I don't have any dates handy). Anyway, I have this weird SUN Keyboard -> USB adapter, which offers an ukbd(4) and ums(4) device to the system, although there is no mouse attached to the Sun keyboard I'm using. ukbd0: on uhub4 kbd2 at ukbd0 ums0: on uhub4 ums0: 3 buttons. This worked fine on RELENG_7 till somewhere around summer. Now, whenever there is a moused(8) listening on this fake ums(4) port, the umass(4) device will get stuck somewhere in CAM-land. It probes fine: Dec 14 10:24:49 roadrunner kernel: umass0: on uhub4 but then only BBB bulk transfer timeout messages follow every so often. The da0 device never shows up. Dec 14 10:26:59 roadrunner kernel: umass0: BBB reset failed, TIMEOUT Dec 14 10:27:04 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:27:04 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:28:09 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:28:09 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:28:09 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:29:14 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:29:14 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:29:14 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:30:19 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:30:19 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:30:19 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:31:24 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:31:24 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:31:24 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR I cannot unplug the USB stick (instant panic) and kldunloading umass is also bad (instant panic). I have to reboot the system and remove the device then. Today, I figured out that it depends wholly on moused(8) running on that unpopulated mouse port. Killing the moused process, which will start automatically when ums0 attaches, before plugging in the umass device and everybody is happy. I'm glad I found this workaround, but the situation sucks anyway. Other than binary searching the offending commit, what debugging could I do? Would a ktrace of the moused(8) be helpful when attaching umass? Is it perhaps polling the port too often waiting for a mouse to appear? Also, can I somehow blacklist the mouse-port of this adapter? I do not intend to use a 3 button Sun mouse, ever. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From mikej at rogers.com Mon Dec 15 08:47:29 2008 From: mikej at rogers.com (Mike Jakubik) Date: Mon Dec 15 08:47:36 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <4944D894.6070306@delphij.net> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> <493D9BC6.8050902@delphij.net> <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> <4944D894.6070306@delphij.net> Message-ID: <400809c165ecedf8a0b7bc6b569e1289.squirrel@wettoast.dyndns.org> On Sun, December 14, 2008 4:57 am, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mike Jakubik wrote: >> On Mon, December 8, 2008 5:22 pm, Mike Jakubik wrote: >>> On Mon, December 8, 2008 5:12 pm, Xin LI wrote: >>> >>>> Which version are you currently using? My previous commit only fixes >>>> the excessive interrupt issue, I think this could be a different >>>> problem, I'm taking a look at the code to see if I can have something >>>> for you. >>> I was running on the version just prior to the latest interrupt commit. >>> I >>> have now updated to the one with the interrupt fix. Will let you know >>> if >>> things change. >>> >>> Thank You. >> >> The interrupt rate has decreased significantly, however i am still >> having >> having problem with applications that hold stateful connections. The rx >> errors are also still showing, i suspect this is related to the problem. >> How can i roll back this driver to the last known good version? > > Hi, Mike, > > I think they are different problems. Could you, please, give me > feedback about whether: > > - The old driver does not trigger the problem? > > - The patched driver restore all the old driver behavior? - Old driver. I have been running the system for 4 days now with this driver. My application has not stopped accepting connections, irq rate is low, and there are no rx/tx errors reported. Everything looks good. - Patched driver. Your initial import plus the IRQ fix still shows rx errors, and my application had stopped accepting connections. I have not tried the patch in your last email, and im not sure when i will be able to to as these systems are in production. Perhaps someone else could test it? As soon as i get a chance i will let you know how it goes. Thanks for the work on this. From ghelmer at palisadesys.com Mon Dec 15 09:12:11 2008 From: ghelmer at palisadesys.com (Guy Helmer) Date: Mon Dec 15 09:12:23 2008 Subject: 7.1RC1: system hang In-Reply-To: <4942C178.2030206@palisadesys.com> References: <49419BE0.2070502@palisadesys.com> <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> <49426880.40302@palisadesys.com> <3a142e750812120729v478d850do93e31e5d8502ef68@mail.gmail.com> <4942C178.2030206@palisadesys.com> Message-ID: <49468FE2.4040007@palisadesys.com> I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. Here is the output from ps/m, show allpcpu, show locks, show alllocks, allt, show allchains, and show lockedvnods commands in the debugger. I'm suspicious of the vmstat process's locking -- it has shown up in each of the hangs I've seen so far. Any help would be appreciated. Guy db> ps /m pid ppid pgrp uid state wmesg wchan cmd 96381 96369 96364 0 S user map 0xc610d86c vmstat 96378 96368 96365 0 R sysctl 96369 96364 96364 0 S piperd 0xc4928c60 perl5.8.8 96368 96365 96365 0 S piperd 0xc75ec630 perl5.8.8 96367 96362 96362 1001 R initial thread 96365 96361 96365 0 Ss wait 0xc5cd42b8 sh 96364 96360 96364 0 Ss wait 0xc6131570 sh 96362 96359 96362 1001 Ss wait 0xc7478828 sh 96361 3851 3851 0 S piperd 0xc4986dec cron 96360 3851 3851 0 S piperd 0xc5dcf948 cron 96359 3851 3851 0 S piperd 0xc74b8000 cron 96358 1424 96358 70 Ss sbwait 0xc60a073c postgres 96215 96203 2054 1001 RL filter 96212 96209 2054 1001 R kvoop 96209 96201 2054 1001 R CPU 1 filter 96203 2055 2054 1001 S piperd 0xc5bf5948 perform_ca 96201 2055 2054 1001 S piperd 0xc61b94a4 perform_ca 92421 3821 3821 1001 S proctree 0xc0928754 httpd 92417 3821 3821 1001 R httpd 50637 1424 50637 70 Ss sbwait 0xc772c8dc postgres 50633 1441 1440 1001 S proctree 0xc0928754 ph_alert_mgr 4611 4602 4611 1001 Ss+ allproc 0xc092873c tcsh 4602 4550 4550 1001 S select 0xc097a77c sshd 4550 3836 4550 0 Ss sbwait 0xc5ebd3fc sshd 4459 4201 4459 1001 S+ allproc 0xc092873c tcsh 4202 1 4202 0 Ss sysctl l 0xc0928c34 ntpd 4201 1 4201 0 Ss+ wait 0xc48d8828 login 4200 1 4200 0 Ss+ ttyin 0xc4594010 getty 4199 1 4199 0 Ss+ ttyin 0xc4595810 getty 4198 1 4198 0 Ss+ ttyin 0xc45a3c10 getty 4197 1 4197 0 Ss+ ttyin 0xc45a3810 getty 3851 1 3851 0 Ss nanslp 0xc0928dc4 cron 3845 1 3845 25 Ss pause 0xc5cd3318 sendmail 3836 1 3836 0 Ss select 0xc097a77c sshd 3821 1 3821 0 Ss proctree 0xc0928754 initial thread 3813 1 3813 0 Ss sysctl l 0xc0928c34 sendmail 2463 2213 2463 100 Ss piperd 0xc47b1948 unlinkd 2225 1 2225 1001 Ss (threaded) proxsmtpd 100120 S accept 0xc5cdfd3a proxsmtpd 2219 1 50 0 S+ select 0xc097a77c snmpd 2213 2211 2211 100 S select 0xc097a77c squid 2211 1 2211 100 Ss wait 0xc5cd3570 squid 2189 1 2188 0 S nanslp 0xc0928dc4 smartd 2175 2167 2167 1001 S accept 0xc5c5a37a imspector 2174 2167 2167 1001 S accept 0xc48cc85a imspector 2168 2167 2167 1001 S accept 0xc5c5a6ba imspector 2167 1 2167 1001 Ss select 0xc097a77c imspector 2166 1424 2166 70 Ss sbwait 0xc4be30bc postgres 2162 2161 2161 1001 S nanslp 0xc0928dc4 initial thread 2161 1 2161 0 Ss wait 0xc5bf8570 sys-monitor 2154 2153 2153 1001 S proctree 0xc0928754 initial thread 2153 1 2153 0 Ss wait 0xc47f2ae0 sys-monitor 2138 2137 2137 1001 S proctree 0xc0928754 icapd 2137 1 2137 0 Ss wait 0xc5bf8ae0 sys-monitor 2127 2126 2126 1001 S select 0xc097a77c perl5.8.8 2126 1 2126 0 Ss wait 0xc4a70828 sys-monitor 2063 2062 2062 1001 S accept 0xc48d203a initial thread 2062 1 2062 0 Ss wait 0xc5bf72b8 sys-monitor 2055 2054 2054 1001 S proctree 0xc0928754 perform_ca 2054 1 2054 0 Ss wait 0xc5bf7000 sys-monitor 2052 1 2052 0 Ss sysctl l 0xc0928c34 sys-ifmonitor 1789 1424 1789 70 Ss sbwait 0xc4be38dc postgres 1746 1745 1745 1001 S select 0xc097a77c initial thread 1745 1 1745 0 Ss wait 0xc47f3828 sys-monitor 1738 1737 1737 1001 S select 0xc097a77c user_manager 1737 1 1737 0 Ss wait 0xc47262b8 sys-monitor 1730 1729 1729 1001 R (threaded) ph 100185 S ucond 0xc49a5440 ph 100184 S ucond 0xc49a5400 ph 100183 S ucond 0xc49a53c0 ph 100182 S ucond 0xc49a5380 ph 100082 RunQ initial thread 1729 1 1729 0 Ss wait 0xc4a6f828 sys-monitor 1441 1440 1440 1001 S accept 0xc48cd51a initial thread 1440 1 1440 0 Ss wait 0xc47f3570 sys-monitor 1429 1424 1429 70 Ss select 0xc097a77c postgres 1428 1424 1428 70 Ss select 0xc097a77c postgres 1427 1424 1427 70 Ss select 0xc097a77c postgres 1426 1424 1426 70 Ss select 0xc097a77c postgres 1424 1422 1422 70 S allproc 0xc092873c initial thread 1422 1 1422 0 Ss wait 0xc48da828 sys-monitor 1345 1 1345 0 Ss select 0xc097a77c syslogd 1316 0 0 0 SL - 0xc0926a60 [accounting] 465 1 465 0 Ss select 0xc097a77c devd 120 1 120 0 Ss pause 0xc47b55d0 adjkerntz 49 0 0 0 SL sdflush 0xc09836c8 [softdepflush] 48 0 0 0 SL vlruwt 0xc4722828 [vnlru] 47 0 0 0 SL syncer 0xc0928bec [syncer] 46 0 0 0 SL psleep 0xc097ac04 [bufdaemon] 45 0 0 0 SL pollid 0xc0928318 [idlepoll] 44 0 0 0 SL pgzero 0xc09842a0 [pagezero] 43 0 0 0 SL psleep 0xc0983eb8 [vmdaemon] 42 0 0 0 SL psleep 0xc0983e80 [pagedaemon] 41 0 0 0 SL - 0xc46c6480 [dummynet] 40 0 0 0 WL [irq7: ppbus0 ppc0] 39 0 0 0 SL - 0xc456a83c [fdc0] 38 0 0 0 WL [swi0: sio] 37 0 0 0 WL [irq1: atkbd0] 36 0 0 0 WL [irq15: ata1] 35 0 0 0 WL [irq14: ata0] 34 0 0 0 SL usbevt 0xc455d210 [usb2] 33 0 0 0 WL [irq18: uhci2] 32 0 0 0 SL usbevt 0xc453e210 [usb1] 31 0 0 0 WL [irq19: uhci1] 30 0 0 0 SL usbtsk 0xc0925bd4 [usbtask-dr] 29 0 0 0 SL usbtsk 0xc0925bc0 [usbtask-hc] 28 0 0 0 SL usbevt 0xc4544210 [usb0] 27 0 0 0 WL [irq16: uhci0] 26 0 0 0 SL - 0xc4523a00 [em1 taskq] 25 0 0 0 SL - 0xc4523c00 [em0 taskq] 24 0 0 0 WL [irq9: acpi0] 23 0 0 0 SL - 0xc446ed80 [kqueue taskq] 22 0 0 0 WL [swi2: cambio] 9 0 0 0 SL ccb_scan 0xc090c954 [xpt_thrd] 21 0 0 0 WL [swi6: task queue] 20 0 0 0 WL [swi6: Giant taskq] 8 0 0 0 SL - 0xc44b3280 [acpi_task_2] 7 0 0 0 SL - 0xc44b3280 [acpi_task_1] 6 0 0 0 SL - 0xc44b3280 [acpi_task_0] 5 0 0 0 SL - 0xc44b3300 [thread taskq] 19 0 0 0 WL [swi5: +] 18 0 0 0 SL - 0xc0928bf4 [yarrow] 4 0 0 0 SL - 0xc092634c [g_down] 3 0 0 0 SL - 0xc0926348 [g_up] 2 0 0 0 SL - 0xc0926340 [g_event] 17 0 0 0 WL [swi3: vm] 16 0 0 0 WL [swi4: clock sio] 15 0 0 0 WL [swi1: net] 14 0 0 0 RL CPU 0 [idle: cpu0] 13 0 0 0 RL [idle: cpu1] 12 0 0 0 RL CPU 2 [idle: cpu2] 11 0 0 0 RL CPU 3 [idle: cpu3] 1 0 1 0 SLs wait 0xc442bae0 [init] 10 0 0 0 SL audit_wo 0xc0983114 [audit] 0 0 0 0 SLs sched 0xc0926400 [swapper] 95907 1441 1440 1001 Z ph_alert_mgr 95900 1441 1440 1001 Z ph_alert_mgr 95901 1441 1440 1001 Z ph_alert_mgr 95891 1441 1440 1001 Z ph_alert_mgr 95899 1441 1440 1001 Z ph_alert_mgr 95898 1441 1440 1001 Z ph_alert_mgr 95902 1441 1440 1001 Z ph_alert_mgr db> show allpcpu Current CPU: 0 cpuid = 0 curthread = 0xc442d460: pid 14 "idle: cpu0" curpcb = 0xe300ad90 fpcurthread = none idlethread = 0xc442d460: pid 14 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: cpuid = 1 curthread = 0xc7904230: pid 96209 "filter" curpcb = 0xe72f8d90 fpcurthread = none idlethread = 0xc442d690: pid 13 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: cpuid = 2 curthread = 0xc442d8c0: pid 12 "idle: cpu2" curpcb = 0xe3004d90 fpcurthread = none idlethread = 0xc442d8c0: pid 12 "idle: cpu2" APIC ID = 6 currentldt = 0x50 spin locks held: cpuid = 3 curthread = 0xc442daf0: pid 11 "idle: cpu3" curpcb = 0xe3001d90 fpcurthread = none idlethread = 0xc442daf0: pid 11 "idle: cpu3" APIC ID = 7 currentldt = 0x50 spin locks held: db> show locks db> show alllocks Process 96381 (vmstat) thread 0xc756caf0 (100276) shared sx allproc r = 0 (0xc092873c) locked @ vm/vm_meter.c:130 exclusive sx sysctl lock r = 0 (0xc0928c34) locked @ kern/kern_sysctl.c:1396 Process 96358 (postgres) thread 0xc7551460 (100275) exclusive sx so_rcv_sx r = 0 (0xc60a070c) locked @ kern/uipc_sockbuf.c:148 Process 96215 (filter) thread 0xc613b230 (100228) exclusive sleep mutex vm object (standard object) r = 0 (0xc5de84d8) locked @ vm/vm_fault.c:886 exclusive sx user map r = 0 (0xc610d86c) locked @ vm/vm_map.c:3111 Process 50637 (postgres) thread 0xc613b8c0 (100225) exclusive sx so_rcv_sx r = 0 (0xc772c8ac) locked @ kern/uipc_sockbuf.c:148 Process 4611 (tcsh) thread 0xc47fc230 (100097) shared sx proctree r = 0 (0xc0928754) locked @ kern/kern_fork.c:300 Process 4550 (sshd) thread 0xc4a74000 (100170) exclusive sx so_rcv_sx r = 0 (0xc5ebd3cc) locked @ kern/uipc_sockbuf.c:148 Process 4459 (tcsh) thread 0xc4822af0 (100107) shared sx proctree r = 0 (0xc0928754) locked @ kern/kern_fork.c:300 Process 2166 (postgres) thread 0xc48db8c0 (100086) exclusive sx so_rcv_sx r = 0 (0xc4be308c) locked @ kern/uipc_sockbuf.c:148 Process 1789 (postgres) thread 0xc47bad20 (100051) exclusive sx so_rcv_sx r = 0 (0xc4be38ac) locked @ kern/uipc_sockbuf.c:148 Process 1424 (postgres) thread 0xc4822690 (100109) shared sx proctree r = 0 (0xc0928754) locked @ kern/kern_fork.c:300 db> show sleepchain 96381 thread 100276 (pid 96381, vmstat) blocked on sx "user map" XLOCK thread 100228 (pid 96215, filter) is on a run queue db> show sleepchain 96358 thread 100275 (pid 96358, postgres) sleeping on 0xc60a073c "sbwait" db> show sleepchain 96215 thread 100228 (pid 96215, filter) is on a run queue db> show sleepchain 50637 thread 100225 (pid 50637, postgres) sleeping on 0xc772c8dc "sbwait" db> show sleepchain 4611 thread 100097 (pid 4611, tcsh) blocked on sx "allproc" SLOCK (count 1) db> show sleepchain 4550 thread 100170 (pid 4550, sshd) sleeping on 0xc5ebd3fc "sbwait" db> show sleepchain 4459 thread 100107 (pid 4459, tcsh) blocked on sx "allproc" SLOCK (count 1) db> show sleepchain 2166 thread 100086 (pid 2166, postgres) sleeping on 0xc4be30bc "sbwait" db> show sleepchain 1789 thread 100051 (pid 1789, postgres) sleeping on 0xc4be38dc "sbwait" db> show sleepchain 1424 thread 100109 (pid 1424, initial thread) blocked on sx "allproc" SLOCK (count 1) db> allt Tracing command vmstat pid 96381 tid 100276 td 0xc756caf0 sched_switch(c756caf0,0,1,24b,d2bf8efc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c756caf0,c756caf0,c756caf0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c756caf0,0,c085c813,243,c610d86c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c610d86c,0,c086e83c,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c610d86c,c756caf0,0,c086e932,ba,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c610d86c,0,c086e932,ba,e709cb58,...) at 0xc0660b6b = _sx_xlock+0x6b _vm_map_lock_read(c610d828,c086e932,ba,b1,c47bbd98,...) at 0xc07ab7a0 = _vm_map_lock_read+0x50 vmtotal(c08fcb60,0,30,e709cba4,e709cba4,...) at 0xc07ae75b = vmtotal+0x29b sysctl_root(e709cba4,0,c085a213,574,c756caf0,...) at 0xc0662977 = sysctl_root+0x127 userland_sysctl(c756caf0,e709cc14,2,bfbfe4dc,bfbfe520,...) at 0xc0662aa5 = userland_sysctl+0x115 __sysctl(c756caf0,e709ccfc,18,c085df3a,c08e2af0,...) at 0xc0662eec = __sysctl+0xbc syscall(e709cd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x4817dc1f, esp = 0xbfbfe32c, ebp = 0xbfbfe358 --- Tracing command sysctl pid 96378 tid 100194 td 0xc5e27000 sched_switch(c5e27000,0,1,c068abe0,a9326472,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085ccbb,2e3,c09339c4,...) at 0xc06611d3 = mi_switch+0x143 turnstile_wait(c4bc61e0,c5f80af0,0,c75ec7a0,3d0,...) at 0xc068b404 = turnstile_wait+0x234 _mtx_lock_sleep(c75ec7a0,c5e27000,0,c085d7a2,3d0,...) at 0xc064d51e = _mtx_lock_sleep+0x10e _mtx_lock_flags(c75ec7a0,0,c085d7a2,3d0,8,...) at 0xc064d5a7 = _mtx_lock_flags+0x67 pipe_write(c5ebbdf4,e6f8ac60,c6c25a00,0,c5e27000,...) at 0xc0691e80 = pipe_write+0x40 dofilewrite(e6f8ac60,ffffffff,ffffffff,0,c5ebbdf4,...) at 0xc068fd65 = dofilewrite+0x95 kern_writev(c5e27000,1,e6f8ac60,bfbfd560,1,...) at 0xc068ffe8 = kern_writev+0x58 write(c5e27000,e6f8acfc,c,c084f1db,c08e1860,...) at 0xc069005f = write+0x4f syscall(e6f8ad38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (4, FreeBSD ELF32, write), eip = 0x4815a963, esp = 0xbfbfd3dc, ebp = 0xbfbfd3f8 --- Tracing command perl5.8.8 pid 96369 tid 100188 td 0xc5e27d20 sched_switch(c5e27d20,0,1,24b,cf951454,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5ff0840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5ff0840,0,c085c813,19e,c4928c60,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5e27d20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4928c60,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4928c60,c4928dd0,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c493689c,e6f78c60,c62ca500,0,c5e27d20,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e6f78c60,ffffffff,ffffffff,0,c493689c,...) at 0xc0690106 = dofileread+0x96 kern_readv(c5e27d20,3,e6f78c60,48305000,1000,...) at 0xc0690478 = kern_readv+0x58 read(c5e27d20,e6f78cfc,c,c5e27d20,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6f78d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x482a2983, esp = 0xbfbfca6c, ebp = 0xbfbfca88 --- Tracing command perl5.8.8 pid 96368 tid 100477 td 0xc5f80af0 sched_switch(c5f80af0,0,1,24b,a93390e4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5c642d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5c642d0,0,c085c813,19e,c75ec630,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5f80af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c75ec630,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c75ec630,c75ec7a0,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c4a00c78,e7395c60,c6c25a00,0,c5f80af0,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e7395c60,ffffffff,ffffffff,0,c4a00c78,...) at 0xc0690106 = dofileread+0x96 kern_readv(c5f80af0,4,e7395c60,48305000,1000,...) at 0xc0690478 = kern_readv+0x58 read(c5f80af0,e7395cfc,c,c082c73d,c08e1848,...) at 0xc069055f = read+0x4f syscall(e7395d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x482a2983, esp = 0xbfbfcb0c, ebp = 0xbfbfcb28 --- Tracing command php pid 96367 tid 100284 td 0xc7569d20 sched_switch(c7569d20,0,2,b4,994e18fa,...) at 0xc0676004 = sched_switch+0x324 mi_switch(2,0,c085cb08,ec,10004,...) at 0xc06611d3 = mi_switch+0x143 ast(e70b4d38) at 0xc0689c9b = ast+0x23b doreti_ast() at 0xc07e4aed = doreti_ast+0x17 Tracing command sh pid 96365 tid 100148 td 0xc4bc8af0 sched_switch(c4bc8af0,0,1,24b,7e398e8e,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5cd42d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5cd42d0,0,c085c813,19e,c5cd42b8,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c4bc8af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5cd42b8,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5cd42b8,c5cd4348,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c4bc8af0,ffffffff,e6eb8c2c,2,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c4bc8af0,e6eb8cfc,10,c4bc8af0,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6eb8d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x4814658b, esp = 0xbfbfebdc, ebp = 0xbfbfebf8 --- Tracing command sh pid 96364 tid 100231 td 0xc613aaf0 sched_switch(c613aaf0,0,1,24b,7ecc5d46,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c6131588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c6131588,0,c085c813,19e,c6131570,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c613aaf0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c6131570,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c6131570,c6131600,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c613aaf0,ffffffff,e7015c2c,2,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c613aaf0,e7015cfc,10,c613aaf0,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e7015d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x4814658b, esp = 0xbfbfebdc, ebp = 0xbfbfebf8 --- Tracing command sh pid 96362 tid 100283 td 0xc756c000 sched_switch(c756c000,0,1,24b,7e295ce4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c7478840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c7478840,0,c085c813,19e,c7478828,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c756c000,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c7478828,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c7478828,c74788b8,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c756c000,ffffffff,e70b1c2c,2,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c756c000,e70b1cfc,10,c756c000,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e70b1d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x4814658b, esp = 0xbfbfebdc, ebp = 0xbfbfebf8 --- Tracing command cron pid 96361 tid 100239 td 0xc60f1690 sched_switch(c60f1690,0,1,24b,7d08d224,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c61672d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c61672d0,0,c085c813,19e,c4986dec,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c60f1690,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4986dec,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4986dec,c4986f5c,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c4a000e4,e702dc60,c5cf2b00,0,c60f1690,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e702dc60,ffffffff,ffffffff,0,c4a000e4,...) at 0xc0690106 = dofileread+0x96 kern_readv(c60f1690,5,e702dc60,48221000,1000,...) at 0xc0690478 = kern_readv+0x58 read(c60f1690,e702dcfc,c,c085da67,c08e1848,...) at 0xc069055f = read+0x4f syscall(e702dd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x48174983, esp = 0xbfbfe6fc, ebp = 0xbfbfe718 --- Tracing command cron pid 96360 tid 100210 td 0xc600d460 sched_switch(c600d460,0,1,24b,7d8dcb66,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c60ed840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c60ed840,0,c085c813,19e,c5dcf948,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c600d460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5dcf948,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5dcf948,c5dcfab8,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c6108d10,e6fbac60,c5cf2b00,0,c600d460,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e6fbac60,ffffffff,ffffffff,0,c6108d10,...) at 0xc0690106 = dofileread+0x96 kern_readv(c600d460,5,e6fbac60,48221000,1000,...) at 0xc0690478 = kern_readv+0x58 read(c600d460,e6fbacfc,c,c085da67,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6fbad38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x48174983, esp = 0xbfbfe6fc, ebp = 0xbfbfe718 --- Tracing command cron pid 96359 tid 100227 td 0xc613b460 sched_switch(c613b460,0,1,24b,7cf981f6,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c61322d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c61322d0,0,c085c813,19e,c74b8000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c613b460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c74b8000,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c74b8000,c74b8170,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c5ebb428,e7009c60,c5cf2b00,0,c613b460,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e7009c60,ffffffff,ffffffff,0,c5ebb428,...) at 0xc0690106 = dofileread+0x96 kern_readv(c613b460,5,e7009c60,48221000,1000,...) at 0xc0690478 = kern_readv+0x58 read(c613b460,e7009cfc,c,c085da67,c08e1848,...) at 0xc069055f = read+0x4f syscall(e7009d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x48174983, esp = 0xbfbfe6fc, ebp = 0xbfbfe718 --- Tracing command postgres pid 96358 tid 100275 td 0xc7551460 sched_switch(c7551460,0,1,24b,93a11dd4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c753a588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c753a588,0,c085c813,19e,c60a073c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c7551460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c60a073c,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c60a073c,c60a06f4,158,c08601ab,0,...) at 0xc0661707 = _sleep+0x307 sbwait(c60a06d0,0,c0860221,592,c60a06f4,...) at 0xc06a8a42 = sbwait+0x52 soreceive_generic(c60a0680,0,e7099c60,0,0,...) at 0xc06ad7ac = soreceive_generic+0x3bc soreceive(c60a0680,0,e7099c60,0,0,...) at 0xc06a98c8 = soreceive+0x38 soo_read(c5ebb6d4,e7099c60,c49b1500,0,c7551460,...) at 0xc0694bdb = soo_read+0x3b dofileread(e7099c60,ffffffff,ffffffff,0,c5ebb6d4,...) at 0xc0690106 = dofileread+0x96 kern_readv(c7551460,7,e7099c60,48970000,5,...) at 0xc0690478 = kern_readv+0x58 read(c7551460,e7099cfc,c,c084f1db,c08e1848,...) at 0xc069055f = read+0x4f syscall(e7099d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x4878a983, esp = 0xbfbfd7dc, ebp = 0xbfbfd7f8 --- Tracing command filter pid 96215 tid 100228 td 0xc613b230 sched_switch(c613b230,0,1,c068abe0,44a5e66a,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085ccbb,2e3,c09338c8,...) at 0xc06611d3 = mi_switch+0x143 turnstile_wait(c787a820,c7903af0,0,c0983e5c,377,...) at 0xc068b404 = turnstile_wait+0x234 _mtx_lock_sleep(c0983e5c,c613b230,0,c086e39f,377,...) at 0xc064d51e = _mtx_lock_sleep+0x10e _mtx_lock_flags(c0983e5c,0,c086e39f,377,0,...) at 0xc064d5a7 = _mtx_lock_flags+0x67 vm_fault(c610d828,4826a000,1,0,4826a928,...) at 0xc07a765b = vm_fault+0x1b1b trap_pfault(5,0,c0877641,c613b230,c,...) at 0xc07fbe89 = trap_pfault+0xf9 trap(e700cd38) at 0xc07fc6fd = trap+0x25d calltrap() at 0xc07e41cb = calltrap+0x6 --- trap 0xc, eip = 0x4826a928, esp = 0xbfbfda0c, ebp = 0xbfbfda38 --- Tracing command kvoop pid 96212 tid 100243 td 0xc60f0d20 sched_switch(c60f0d20,0,1,24b,2eb909b6,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c6166588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c6166588,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e7039ad8,c064d2b9,c097a764,c60f0d20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,ea61,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,ea61,3bb,2,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 poll(c60f0d20,e7039cfc,c,c085e083,c08e2b98,...) at 0xc068eec4 = poll+0x554 syscall(e7039d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x48226bb7, esp = 0x8068f3c, ebp = 0x8068f98 --- Tracing command filter pid 96209 tid 100437 td 0xc7904230 cpustop_handler(2,e72f8d2c,c07fc4d0,23,3,...) at 0xc07f2c52 = cpustop_handler+0x32 ipi_nmi_handler(23,3,c0676004,c7904230,13,...) at 0xc07f2cdf = ipi_nmi_handler+0x2f trap(e72f8d38) at 0xc07fc4d0 = trap+0x30 calltrap() at 0xc07e41cb = calltrap+0x6 --- trap 0x13, eip = 0x480a96d5, esp = 0xbfbfcf70, ebp = 0xbfbfcf78 --- Tracing command perform_ca pid 96203 tid 100203 td 0xc600e460 sched_switch(c600e460,0,1,24b,41c7c61c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c60ef018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c60ef018,0,c085c813,19e,c5bf5948,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c600e460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5bf5948,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5bf5948,c5bf5ab8,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c4b7b4c0,e6fa5c60,c4978100,0,c600e460,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e6fa5c60,ffffffff,ffffffff,0,c4b7b4c0,...) at 0xc0690106 = dofileread+0x96 kern_readv(c600e460,d,e6fa5c60,839b1db,1,...) at 0xc0690478 = kern_readv+0x58 read(c600e460,e6fa5cfc,c,c600e460,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6fa5d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x820c56f, esp = 0xbfbf998c, ebp = 0xbfbf99b8 --- Tracing command perform_ca pid 96201 tid 100481 td 0xc77d2af0 sched_switch(c77d2af0,0,1,24b,26596dcc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c78fa588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c78fa588,0,c085c813,19e,c61b94a4,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c77d2af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c61b94a4,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c61b94a4,c61b9614,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c5ebb63c,e73b7c60,c4978100,0,c77d2af0,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e73b7c60,ffffffff,ffffffff,0,c5ebb63c,...) at 0xc0690106 = dofileread+0x96 kern_readv(c77d2af0,d,e73b7c60,839b1db,1,...) at 0xc0690478 = kern_readv+0x58 read(c77d2af0,e73b7cfc,c,c77d2af0,c08e1848,...) at 0xc069055f = read+0x4f syscall(e73b7d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x820c56f, esp = 0xbfbf998c, ebp = 0xbfbf99b8 --- Tracing command httpd pid 92421 tid 100300 td 0xc754f690 sched_switch(c754f690,0,1,24b,f0f9ecd8,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c754f690,c754f690,c754f690,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c754f690,0,c085c813,243,c0928754,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928754,0,c0859453,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928754,c754f690,0,c0852b41,1a0,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928754,0,c0852b41,1a0,1002,...) at 0xc0660b6b = _sx_xlock+0x6b devfs_close(e70efb30,e70efb54,c06d91c7,c08de5e0,e70efb30,...) at 0xc05f29af = devfs_close+0x3f VOP_CLOSE_APV(c08de5e0,e70efb30,c754f690,c086269f,120,...) at 0xc080ff52 = VOP_CLOSE_APV+0x42 vn_close(c63ffbdc,1,c48c2900,c754f690,c068e3e2,...) at 0xc06d91c7 = vn_close+0x87 vn_closefile(c4b7b260,c754f690,c4b7b260,0,e70efbe8,...) at 0xc06d92d7 = vn_closefile+0xe7 devfs_close_f(c4b7b260,c754f690,c0856ae5,8c6,e70efbe8,...) at 0xc05f031b = devfs_close_f+0x2b fdrop(c4b7b260,c754f690,c0856aee,c068d7b8,0,c090c2e0,c63ffbdc,c75182b8,2,e70efc1c,40,0,0,0,0,8,2,463) at 0xc062df71 = fdrop+0xf1 closef(c4b7b260,c754f690,463,448,c4b7b260,...) at 0xc062faf2 = closef+0x252 kern_close(c754f690,10,e70efd2c,c07fc233,c754f690,...) at 0xc062fe9d = kern_close+0x11d close(c754f690,e70efcfc,4,16,c08e1890,...) at 0xc062ff3a = close+0x1a syscall(e70efd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x48501943, esp = 0xbfbfe9bc, ebp = 0xbfbfe9d8 --- Tracing command httpd pid 92417 tid 100328 td 0xc77e0000 sched_switch(c77e0000,0,2,b4,9534efa6,...) at 0xc0676004 = sched_switch+0x324 mi_switch(2,0,c085cb08,ec,10004,...) at 0xc06611d3 = mi_switch+0x143 ast(e7154d38) at 0xc0689c9b = ast+0x23b doreti_ast() at 0xc07e4aed = doreti_ast+0x17 Tracing command postgres pid 50637 tid 100225 td 0xc613b8c0 sched_switch(c613b8c0,0,1,24b,f2b10170,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c6132840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c6132840,0,c085c813,19e,c772c8dc,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c613b8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c772c8dc,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c772c8dc,c772c894,158,c08601ab,0,...) at 0xc0661707 = _sleep+0x307 sbwait(c772c870,0,c0860221,592,c772c894,...) at 0xc06a8a42 = sbwait+0x52 soreceive_generic(c772c820,e7003be8,e7003bf4,0,0,...) at 0xc06ad7ac = soreceive_generic+0x3bc soreceive(c772c820,e7003be8,e7003bf4,0,0,...) at 0xc06a98c8 = soreceive+0x38 kern_recvit(c613b8c0,7,e7003c60,0,0,...) at 0xc06af145 = kern_recvit+0x155 recvit(0,e7003c80,c06b1868,8382ea0,2000,0,0,e7003c58,1,0,4879bb98,0) at 0xc06af351 = recvit+0x31 recvfrom(c613b8c0,e7003cfc,18,c085dd08,c08e1ab8,...) at 0xc06af4c6 = recvfrom+0x76 syscall(e7003d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x487439a7, esp = 0xbfbfd97c, ebp = 0xbfbfd9a8 --- Tracing command ph_alert_mgr pid 50633 tid 100445 td 0xc7903460 sched_switch(c7903460,0,1,24b,854fdf38,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c7903460,c7903460,c7903460,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c7903460,0,c085c813,243,c0928754,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928754,0,c0859453,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928754,c7903460,0,c0856f85,2cb,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928754,0,c0856f85,2cb,c068c95e,...) at 0xc0660b6b = _sx_xlock+0x6b kern_wait(c7903460,ffffffff,e7318c2c,1,0,...) at 0xc0638838 = kern_wait+0x128 wait4(c7903460,e7318cfc,10,c085dc7c,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e7318d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x4854a58b, esp = 0xbfbfe1dc, ebp = 0xbfbfe1f8 --- Tracing command tcsh pid 4611 tid 100097 td 0xc47fc230 sched_switch(c47fc230,0,1,24b,365f0754,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c47fc230,c47fc230,c47fc230,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47fc230,0,c085c813,243,c092873c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c092873c,0,c085944b,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c092873c,c47fc230,0,c085706f,135,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c092873c,0,c085706f,135,0,...) at 0xc0660b6b = _sx_xlock+0x6b fork1(c47fc230,80000034,0,e6df3c78,c47fc230,...) at 0xc063aa6b = fork1+0x2eb vfork(c47fc230,e6df3cfc,c08775cf,c085da12,c08e1e30,...) at 0xc063bc29 = vfork+0x29 syscall(e6df3d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (66, FreeBSD ELF32, vfork), eip = 0x48164e9c, esp = 0xbfbfe760, ebp = 0xbfbfe858 --- Tracing command sshd pid 4602 tid 100094 td 0xc47fc8c0 sched_switch(c47fc8c0,0,1,24b,a9b0257c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47f72d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47f72d0,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6dcca84,c064d2b9,c097a764,0,c47fc8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c097a77c,c097a764,c086acda,101,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _cv_wait_sig(c097a77c,c097a764,c085d774,30f,386,...) at 0xc06262a8 = _cv_wait_sig+0x198 kern_select(c47fc8c0,b,485030c0,485030c4,0,0,0,480eaa88) at 0xc068f6dc = kern_select+0x6cc select(c47fc8c0,e6dcccfc,14,c084f1db,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6dccd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x48391903, esp = 0xbfbfe5dc, ebp = 0xbfbfe628 --- Tracing command sshd pid 4550 tid 100170 td 0xc4a74000 sched_switch(c4a74000,0,1,24b,84d1e618,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5e23018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5e23018,0,c085c813,19e,c5ebd3fc,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c4a74000,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5ebd3fc,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5ebd3fc,c5ebd3b4,158,c08601ab,0,...) at 0xc0661707 = _sleep+0x307 sbwait(c5ebd390,0,c0860221,592,c5ebd3b4,...) at 0xc06a8a42 = sbwait+0x52 soreceive_generic(c5ebd340,0,e6f42c60,0,0,...) at 0xc06ad7ac = soreceive_generic+0x3bc soreceive(c5ebd340,0,e6f42c60,0,0,...) at 0xc06a98c8 = soreceive+0x38 soo_read(c4a1c558,e6f42c60,c4774c00,0,c4a74000,...) at 0xc0694bdb = soo_read+0x3b dofileread(e6f42c60,ffffffff,ffffffff,0,c4a1c558,...) at 0xc0690106 = dofileread+0x96 kern_readv(c4a74000,5,e6f42c60,bfbfe62c,4,...) at 0xc0690478 = kern_readv+0x58 read(c4a74000,e6f42cfc,c,c08691e4,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6f42d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x48391983, esp = 0xbfbfe5cc, ebp = 0xbfbfe608 --- Tracing command tcsh pid 4459 tid 100107 td 0xc4822af0 sched_switch(c4822af0,0,1,24b,861167f4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4822af0,c4822af0,c4822af0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4822af0,0,c085c813,243,c092873c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c092873c,0,c085944b,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c092873c,c4822af0,0,c085706f,135,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c092873c,0,c085706f,135,0,...) at 0xc0660b6b = _sx_xlock+0x6b fork1(c4822af0,80000034,0,e6e29c78,c4822af0,...) at 0xc063aa6b = fork1+0x2eb vfork(c4822af0,e6e29cfc,c08775cf,c085da12,c08e1e30,...) at 0xc063bc29 = vfork+0x29 syscall(e6e29d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (66, FreeBSD ELF32, vfork), eip = 0x48164e9c, esp = 0xbfbfe910, ebp = 0xbfbfea08 --- Tracing command ntpd pid 4202 tid 100114 td 0xc47fdaf0 sched_switch(c47fdaf0,0,1,24b,21106ddc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c47fdaf0,c47fdaf0,c47fdaf0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47fdaf0,0,c085c813,243,c0928c34,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928c34,0,c085a2de,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928c34,c47fdaf0,0,c085a213,574,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928c34,0,c085a213,574,c47fdaf0,...) at 0xc0660b6b = _sx_xlock+0x6b userland_sysctl(c47fdaf0,e6e3ec14,6,0,bfbfe7e8,...) at 0xc0662a81 = userland_sysctl+0xf1 __sysctl(c47fdaf0,e6e3ecfc,18,0,c08e2af0,...) at 0xc0662eec = __sysctl+0xbc syscall(e6e3ed38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x48326c1f, esp = 0xbfbfe70c, ebp = 0xbfbfe738 --- Tracing command login pid 4201 tid 100088 td 0xc48db460 sched_switch(c48db460,0,1,24b,8a494678,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d8840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d8840,0,c085c813,19e,c48d8828,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c48db460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c48d8828,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c48d8828,c48d88b8,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c48db460,116b,e6dadc2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c48db460,e6dadcfc,10,c48db460,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6dadd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x4810558b, esp = 0xbfbfed9c, ebp = 0xbfbfedb8 --- Tracing command getty pid 4200 tid 100050 td 0xc47afd20 sched_switch(c47afd20,0,1,24b,fba606b8,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4722018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4722018,0,c085c813,19e,c4594010,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47afd20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4594010,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4594010,0,159,c085f2e6,0,...) at 0xc0661707 = _sleep+0x307 ttysleep(c4594000,c4594010,159,c085f2e6,0,...) at 0xc0699499 = ttysleep+0x39 ttread(c4594000,e6cfbc60,0,e6cfbb90,c05a9e4d,...) at 0xc069cce7 = ttread+0x4e7 ttyread(c4570000,e6cfbc60,0,e6cfbbb4,c0626f10,...) at 0xc06997c8 = ttyread+0x38 scread(c4570000,e6cfbc60,0,1a7,0,...) at 0xc05a9e4d = scread+0x2d giant_read(c4570000,e6cfbc60,0,0,1,...) at 0xc0626f10 = giant_read+0x60 devfs_read_f(c47ac4c0,e6cfbc60,c43f5b00,0,c47afd20,...) at 0xc05f08fd = devfs_read_f+0x7d dofileread(e6cfbc60,ffffffff,ffffffff,0,c47ac4c0,...) at 0xc0690106 = dofileread+0x96 kern_readv(c47afd20,0,e6cfbc60,bfbfee4b,1,...) at 0xc0690478 = kern_readv+0x58 read(c47afd20,e6cfbcfc,c,c087a7d6,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6cfbd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x4816a983, esp = 0xbfbfee2c, ebp = 0xbfbfee58 --- Tracing command getty pid 4199 tid 100084 td 0xc48dbd20 sched_switch(c48dbd20,0,1,24b,fbca346c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d9588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d9588,0,c085c813,19e,c4595810,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c48dbd20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4595810,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4595810,0,159,c085f2e6,0,...) at 0xc0661707 = _sleep+0x307 ttysleep(c4595800,c4595810,159,c085f2e6,0,...) at 0xc0699499 = ttysleep+0x39 ttread(c4595800,e6da1c60,0,e6da1b90,c05a9e4d,...) at 0xc069cce7 = ttread+0x4e7 ttyread(c456fb00,e6da1c60,0,e6da1bb4,c0626f10,...) at 0xc06997c8 = ttyread+0x38 scread(c456fb00,e6da1c60,0,1a7,0,...) at 0xc05a9e4d = scread+0x2d giant_read(c456fb00,e6da1c60,0,0,1,...) at 0xc0626f10 = giant_read+0x60 devfs_read_f(c4b546d4,e6da1c60,c43f5b00,0,c48dbd20,...) at 0xc05f08fd = devfs_read_f+0x7d dofileread(e6da1c60,ffffffff,ffffffff,0,c4b546d4,...) at 0xc0690106 = dofileread+0x96 kern_readv(c48dbd20,0,e6da1c60,bfbfee4b,1,...) at 0xc0690478 = kern_readv+0x58 read(c48dbd20,e6da1cfc,c,c087a7d6,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6da1d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x4816a983, esp = 0xbfbfee2c, ebp = 0xbfbfee58 --- Tracing command getty pid 4198 tid 100150 td 0xc5ce5000 sched_switch(c5ce5000,0,1,24b,fbb5700c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5cd3af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5cd3af8,0,c085c813,19e,c45a3c10,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5ce5000,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c45a3c10,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c45a3c10,0,159,c085f2e6,0,...) at 0xc0661707 = _sleep+0x307 ttysleep(c45a3c00,c45a3c10,159,c085f2e6,0,...) at 0xc0699499 = ttysleep+0x39 ttread(c45a3c00,e6ebec60,0,e6ebeb90,c05a9e4d,...) at 0xc069cce7 = ttread+0x4e7 ttyread(c456fc00,e6ebec60,0,e6ebebb4,c0626f10,...) at 0xc06997c8 = ttyread+0x38 scread(c456fc00,e6ebec60,0,1a7,0,...) at 0xc05a9e4d = scread+0x2d giant_read(c456fc00,e6ebec60,0,0,1,...) at 0xc0626f10 = giant_read+0x60 devfs_read_f(c49a79cc,e6ebec60,c43f5b00,0,c5ce5000,...) at 0xc05f08fd = devfs_read_f+0x7d dofileread(e6ebec60,ffffffff,ffffffff,0,c49a79cc,...) at 0xc0690106 = dofileread+0x96 kern_readv(c5ce5000,0,e6ebec60,bfbfee4b,1,...) at 0xc0690478 = kern_readv+0x58 read(c5ce5000,e6ebecfc,c,c087a7d6,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6ebed38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x4816a983, esp = 0xbfbfee2c, ebp = 0xbfbfee58 --- Tracing command getty pid 4197 tid 100115 td 0xc47fd8c0 sched_switch(c47fd8c0,0,1,24b,fb9ab2e0,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a6eaf8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a6eaf8,0,c085c813,19e,c45a3810,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47fd8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c45a3810,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c45a3810,0,159,c085f2e6,0,...) at 0xc0661707 = _sleep+0x307 ttysleep(c45a3800,c45a3810,159,c085f2e6,0,...) at 0xc0699499 = ttysleep+0x39 ttread(c45a3800,e6e41c60,0,e6e41b90,c05a9e4d,...) at 0xc069cce7 = ttread+0x4e7 ttyread(c456fd00,e6e41c60,0,e6e41bb4,c0626f10,...) at 0xc06997c8 = ttyread+0x38 scread(c456fd00,e6e41c60,0,1a7,0,...) at 0xc05a9e4d = scread+0x2d giant_read(c456fd00,e6e41c60,0,0,1,...) at 0xc0626f10 = giant_read+0x60 devfs_read_f(c4b545f0,e6e41c60,c43f5b00,0,c47fd8c0,...) at 0xc05f08fd = devfs_read_f+0x7d dofileread(e6e41c60,ffffffff,ffffffff,0,c4b545f0,...) at 0xc0690106 = dofileread+0x96 kern_readv(c47fd8c0,0,e6e41c60,bfbfee4b,1,...) at 0xc0690478 = kern_readv+0x58 read(c47fd8c0,e6e41cfc,c,c087a7d6,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6e41d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x4816a983, esp = 0xbfbfee2c, ebp = 0xbfbfee58 --- Tracing command cron pid 3851 tid 100130 td 0xc4823af0 sched_switch(c4823af0,0,1,24b,fad6651c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf9588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf9588,0,c085c813,19e,c0928dc4,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6e82bc8,c064d06d,c09310c0,8,c4823af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c0928dc4,0,c085a1a5,d8,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _sleep(c0928dc4,0,15c,c085a708,ea61,...) at 0xc06616e1 = _sleep+0x2e1 kern_nanosleep(c4823af0,e6e82c64,e6e82c6c,3c,0,...) at 0xc0667de1 = kern_nanosleep+0xc1 nanosleep(c4823af0,e6e82cfc,8,c085dc7c,c08e2e80,...) at 0xc066978f = nanosleep+0x6f syscall(e6e82d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x4815636f, esp = 0xbfbfed0c, ebp = 0xbfbfed38 --- Tracing command sendmail pid 3845 tid 100153 td 0xc5ce38c0 sched_switch(c5ce38c0,0,1,24b,fd068e0,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5cd32d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5cd32d0,0,c085c813,19e,c5cd3318,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5ce38c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5cd3318,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5cd3318,c5cd3348,168,c083407d,0,...) at 0xc0661707 = _sleep+0x307 kern_sigsuspend(c5ce38c0,0,0,0,0,...) at 0xc065b8f4 = kern_sigsuspend+0xe4 sigsuspend(c5ce38c0,e6ec7cfc,4,c085da12,c08e37f8,...) at 0xc065b97d = sigsuspend+0x4d syscall(e6ec7d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (341, FreeBSD ELF32, sigsuspend), eip = 0x4830f5cb, esp = 0xbfbfdb1c, ebp = 0xbfbfdb48 --- Tracing command sshd pid 3836 tid 100164 td 0xc4bc7000 sched_switch(c4bc7000,0,1,24b,7f7d5490,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4bc1018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4bc1018,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6f30a84,c064d2b9,c097a764,0,c4bc7000,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c097a77c,c097a764,c086acda,101,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _cv_wait_sig(c097a77c,c097a764,c085d774,30f,e6f30afc,...) at 0xc06262a8 = _cv_wait_sig+0x198 kern_select(c4bc7000,6,48509098,0,0,0,c,e6f30c98) at 0xc068f6dc = kern_select+0x6cc select(c4bc7000,e6f30cfc,14,c4bc7000,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6f30d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x48391903, esp = 0xbfbfe6ac, ebp = 0xbfbfee98 --- Tracing command httpd pid 3821 tid 100096 td 0xc47fc460 sched_switch(c47fc460,0,1,24b,87edc028,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c47fc460,c47fc460,c47fc460,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47fc460,0,c085c813,243,c0928754,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928754,0,c0859453,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928754,c47fc460,0,c0856f85,2cb,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928754,0,c0856f85,2cb,c80,...) at 0xc0660b6b = _sx_xlock+0x6b kern_wait(c47fc460,ffffffff,e6dd8c2c,3,0,...) at 0xc0638838 = kern_wait+0x128 wait4(c47fc460,e6dd8cfc,10,c086acda,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6dd8d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x4848158b, esp = 0xbfbfec2c, ebp = 0xbfbfec48 --- Tracing command sendmail pid 3813 tid 100074 td 0xc47b7690 sched_switch(c47b7690,0,1,24b,edd789bc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c47b7690,c47b7690,c47b7690,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47b7690,0,c085c813,243,c0928c34,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928c34,0,c085a2de,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928c34,c47b7690,0,c085a213,574,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928c34,0,c085a213,574,c47b7690,...) at 0xc0660b6b = _sx_xlock+0x6b userland_sysctl(c47b7690,e6d5ec14,2,bfbfcf00,bfbfcf18,...) at 0xc0662a81 = userland_sysctl+0xf1 __sysctl(c47b7690,e6d5ecfc,18,c085dc7c,c08e2af0,...) at 0xc0662eec = __sysctl+0xbc syscall(e6d5ed38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x483a5c1f, esp = 0xbfbfceac, ebp = 0xbfbfced8 --- Tracing command unlinkd pid 2463 tid 100154 td 0xc5ce3690 sched_switch(c5ce3690,0,1,24b,df670e74,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5cd3018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5cd3018,0,c085c813,19e,c47b1948,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5ce3690,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c47b1948,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c47b1948,c47b1ab8,14c,c085d7ef,0,...) at 0xc0661707 = _sleep+0x307 pipe_read(c47ab8e8,e6ecac60,c4760e00,0,c5ce3690,...) at 0xc06915b9 = pipe_read+0x389 dofileread(e6ecac60,ffffffff,ffffffff,0,c47ab8e8,...) at 0xc0690106 = dofileread+0x96 kern_readv(c5ce3690,0,e6ecac60,4827f7e3,1,...) at 0xc0690478 = kern_readv+0x58 read(c5ce3690,e6ecacfc,c,c5ce3690,c08e1848,...) at 0xc069055f = read+0x4f syscall(e6ecad38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x4826e983, esp = 0xbfbfe87c, ebp = 0xbfbfe898 --- Tracing command proxsmtpd pid 2225 tid 100120 td 0xc4a74af0 sched_switch(c4a74af0,0,1,24b,24717858,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47f32d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47f32d0,0,c085c813,19e,c5cdfd3a,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c4a74af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5cdfd3a,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5cdfd3a,c097aa78,158,c085dba8,0,...) at 0xc0661707 = _sleep+0x307 kern_accept(c4a74af0,3,0,0,0,...) at 0xc06afe4b = kern_accept+0x12b accept(c4a74af0,e6e5ecfc,c,c085e815,c08e1ad0,...) at 0xc06b0241 = accept+0x41 syscall(e6e5ed38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x4811166f, esp = 0xbfbfedac, ebp = 0xbfbfedc8 --- Tracing command snmpd pid 2219 tid 100157 td 0xc5ce3000 sched_switch(c5ce3000,0,1,24b,ebf7950a,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5cd2588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5cd2588,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6ed3a84,c064d2b9,c097a764,0,c5ce3000,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c097a77c,c097a764,c086acda,101,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _cv_wait_sig(c097a77c,c097a764,c085d774,30f,c0926b14,...) at 0xc06262a8 = _cv_wait_sig+0x198 kern_select(c5ce3000,7,bfbfedbc,bfbfed3c,bfbfecbc,0,4942c32f,48428b98) at 0xc068f6dc = kern_select+0x6cc select(c5ce3000,e6ed3cfc,14,c085dc7c,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6ed3d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x48417903, esp = 0xbfbfddfc, ebp = 0xbfbfee68 --- Tracing command squid pid 2213 tid 100058 td 0xc47af460 sched_switch(c47af460,0,1,24b,977af504,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47f2588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47f2588,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6d1fad8,c064d2b9,c097a764,c47af460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,3e8,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,3e8,3bb,46,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 poll(c47af460,e6d1fcfc,c,c085dc7c,c08e2b98,...) at 0xc068eec4 = poll+0x554 syscall(e6d1fd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x485ebbbf, esp = 0xbfbf0b7c, ebp = 0xbfbfec38 --- Tracing command squid pid 2211 tid 100152 td 0xc5ce3af0 sched_switch(c5ce3af0,0,1,24b,5a100a8,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5cd3588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5cd3588,0,c085c813,19e,c5cd3570,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5ce3af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5cd3570,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5cd3570,c5cd3600,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c5ce3af0,ffffffff,e6ec4c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c5ce3af0,e6ec4cfc,10,c085e362,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6ec4d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x485c058b, esp = 0xbfbfec6c, ebp = 0xbfbfec88 --- Tracing command smartd pid 2189 tid 100143 td 0xc5bfa690 sched_switch(c5bfa690,0,1,24b,c4c958a4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4bc3af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4bc3af8,0,c085c813,19e,c0928dc4,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6ea9bc8,c064d06d,c09310c0,8,c5bfa690,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c0928dc4,0,c085a1a5,d8,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _sleep(c0928dc4,0,15c,c085a708,1b7359,...) at 0xc06616e1 = _sleep+0x2e1 kern_nanosleep(c5bfa690,e6ea9c64,e6ea9c6c,707,0,...) at 0xc0667de1 = kern_nanosleep+0xc1 nanosleep(c5bfa690,e6ea9cfc,8,c085dc7c,c08e2e80,...) at 0xc066978f = nanosleep+0x6f syscall(e6ea9d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x4829036f, esp = 0xbfbfec2c, ebp = 0xbfbfec58 --- Tracing command imspector pid 2175 tid 100119 td 0xc4a74d20 sched_switch(c4a74d20,0,1,24b,581b1dac,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a6e018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a6e018,0,c085c813,19e,c5c5a37a,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c4a74d20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5c5a37a,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5c5a37a,c097aa78,158,c085dba8,0,...) at 0xc0661707 = _sleep+0x307 kern_accept(c4a74d20,6,e6e4dc70,e6e4dc6c,e6e4dc68,...) at 0xc06afe4b = kern_accept+0x12b accept(c4a74d20,e6e4dcfc,c,c4a74d20,c08e1ad0,...) at 0xc06b028f = accept+0x8f syscall(e6e4dd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x4826c66f, esp = 0xbfbfeabc, ebp = 0xbfbfeb18 --- Tracing command imspector pid 2174 tid 100140 td 0xc5bfad20 sched_switch(c5bfad20,0,1,24b,61a5fa24,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf7588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf7588,0,c085c813,19e,c48cc85a,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5bfad20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c48cc85a,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c48cc85a,c097aa78,158,c085dba8,0,...) at 0xc0661707 = _sleep+0x307 kern_accept(c5bfad20,4,e6ea0c70,e6ea0c6c,e6ea0c68,...) at 0xc06afe4b = kern_accept+0x12b accept(c5bfad20,e6ea0cfc,c,c5bfad20,c08e1ad0,...) at 0xc06b028f = accept+0x8f syscall(e6ea0d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x4826c66f, esp = 0xbfbee99c, ebp = 0xbfbee9e8 --- Tracing command imspector pid 2168 tid 100087 td 0xc48db690 sched_switch(c48db690,0,1,24b,34204670,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d8af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d8af8,0,c085c813,19e,c5c5a6ba,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c48db690,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5c5a6ba,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5c5a6ba,c097aa78,158,c085dba8,0,...) at 0xc0661707 = _sleep+0x307 kern_accept(c48db690,4,e6daac70,e6daac6c,e6daac68,...) at 0xc06afe4b = kern_accept+0x12b accept(c48db690,e6daacfc,c,c085dbef,c08e1ad0,...) at 0xc06b028f = accept+0x8f syscall(e6daad38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x4826c66f, esp = 0xbfbee9cc, ebp = 0xbfbeea18 --- Tracing command imspector pid 2167 tid 100089 td 0xc48db230 sched_switch(c48db230,0,1,24b,aca4d95c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d8588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d8588,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6db0a84,c064d2b9,c097a764,c48db230,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,493e1,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,493e1,30f,e6db0afc,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 kern_select(c48db230,400,bfbfeb9c,0,0,e6db0c70,12c,0) at 0xc068f6c4 = kern_select+0x6b4 select(c48db230,e6db0cfc,14,c086acda,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6db0d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x482cf903, esp = 0xbfbfeb1c, ebp = 0xbfbfee38 --- Tracing command postgres pid 2166 tid 100086 td 0xc48db8c0 sched_switch(c48db8c0,0,1,24b,9a89b5d4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d9018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d9018,0,c085c813,19e,c4be30bc,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c48db8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4be30bc,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4be30bc,c4be3074,158,c08601ab,0,...) at 0xc0661707 = _sleep+0x307 sbwait(c4be3050,0,c0860221,592,c4be3074,...) at 0xc06a8a42 = sbwait+0x52 soreceive_generic(c4be3000,e6da7be8,e6da7bf4,0,0,...) at 0xc06ad7ac = soreceive_generic+0x3bc soreceive(c4be3000,e6da7be8,e6da7bf4,0,0,...) at 0xc06a98c8 = soreceive+0x38 kern_recvit(c48db8c0,7,e6da7c60,0,0,...) at 0xc06af145 = kern_recvit+0x155 recvit(0,4,0,8382ea0,2000,0,0,e6da7c58,1,0,4879bb98,0) at 0xc06af351 = recvit+0x31 recvfrom(c48db8c0,e6da7cfc,18,c085e374,c08e1ab8,...) at 0xc06af4c6 = recvfrom+0x76 syscall(e6da7d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x487439a7, esp = 0xbfbfd97c, ebp = 0xbfbfd9a8 --- Tracing command php pid 2162 tid 100134 td 0xc5bfbaf0 sched_switch(c5bfbaf0,0,1,24b,b9b6edd4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf8840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf8840,0,c085c813,19e,c0928dc4,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6e8ebc8,c064d06d,c09310c0,8,c5bfbaf0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c0928dc4,0,c085a1a5,d8,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _sleep(c0928dc4,0,15c,c085a708,3e9,...) at 0xc06616e1 = _sleep+0x2e1 kern_nanosleep(c5bfbaf0,e6e8ec64,e6e8ec6c,1,0,...) at 0xc0667de1 = kern_nanosleep+0xc1 nanosleep(c5bfbaf0,e6e8ecfc,8,c08691e4,c08e2e80,...) at 0xc066978f = nanosleep+0x6f syscall(e6e8ed38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x4858e36f, esp = 0xbfbfcecc, ebp = 0xbfbfcef8 --- Tracing command sys-monitor pid 2161 tid 100135 td 0xc5bfb8c0 sched_switch(c5bfb8c0,0,1,24b,d6e11ac2,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf8588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf8588,0,c085c813,19e,c5bf8570,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c5bfb8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5bf8570,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5bf8570,c5bf8600,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c5bfb8c0,872,e6e91c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c5bfb8c0,e6e91cfc,10,c5bfb8c0,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e91d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed3c, ebp = 0xbfbfed58 --- Tracing command ph_citrix pid 2154 tid 100069 td 0xc4598460 sched_switch(c4598460,0,1,24b,8298e718,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4598460,c4598460,c4598460,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4598460,0,c085c813,243,c0928754,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928754,0,c0859453,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928754,c4598460,0,c0856f85,2cb,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928754,0,c0856f85,2cb,c80,...) at 0xc0660b6b = _sx_xlock+0x6b kern_wait(c4598460,ffffffff,e6d4bc2c,1,0,...) at 0xc0638838 = kern_wait+0x128 wait4(c4598460,e6d4bcfc,10,c086acda,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6d4bd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x482c658b, esp = 0xbfbfd47c, ebp = 0xbfbfd498 --- Tracing command sys-monitor pid 2153 tid 100056 td 0xc47af8c0 sched_switch(c47af8c0,0,1,24b,ce3d041c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47f2af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47f2af8,0,c085c813,19e,c47f2ae0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47af8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c47f2ae0,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c47f2ae0,c47f2b70,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c47af8c0,86a,e6d17c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c47af8c0,e6d17cfc,10,c47af8c0,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6d17d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed4c, ebp = 0xbfbfed68 --- Tracing command icapd pid 2138 tid 100138 td 0xc5bfb230 sched_switch(c5bfb230,0,1,24b,854f92b0,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c5bfb230,c5bfb230,c5bfb230,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bfb230,0,c085c813,243,c0928754,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928754,0,c0859453,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928754,c5bfb230,0,c0856f85,2cb,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928754,0,c0856f85,2cb,4,...) at 0xc0660b6b = _sx_xlock+0x6b kern_wait(c5bfb230,0,e6e9ac2c,1,0,...) at 0xc0638838 = kern_wait+0x128 wait4(c5bfb230,e6e9acfc,10,c085e083,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e9ad38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x806d1ef, esp = 0xbfbfe16c, ebp = 0xbfbfe188 --- Tracing command sys-monitor pid 2137 tid 100133 td 0xc5bfbd20 sched_switch(c5bfbd20,0,1,24b,a5dda348,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf8af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf8af8,0,c085c813,19e,c5bf8ae0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c5bfbd20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5bf8ae0,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5bf8ae0,c5bf8b70,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c5bfbd20,85a,e6e8bc2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c5bfbd20,e6e8bcfc,10,c5bfbd20,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e8bd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed5c, ebp = 0xbfbfed78 --- Tracing command perl5.8.8 pid 2127 tid 100144 td 0xc5bfa460 sched_switch(c5bfa460,0,1,24b,ad899330,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4bc3840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4bc3840,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6eaca84,c064d2b9,c097a764,c5bfa460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,3e9,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,3e9,30f,3e0,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 kern_select(c5bfa460,8,81c2668,0,0,e6eacc70,1,0) at 0xc068f6c4 = kern_select+0x6b4 select(c5bfa460,e6eaccfc,14,16,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6eacd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x482a2903, esp = 0xbfbfed0c, ebp = 0xbfbfed88 --- Tracing command sys-monitor pid 2126 tid 100106 td 0xc4822d20 sched_switch(c4822d20,0,1,24b,99d965b0,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a70840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a70840,0,c085c813,19e,c4a70828,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c4822d20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4a70828,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4a70828,c4a708b8,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c4822d20,84f,e6e26c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c4822d20,e6e26cfc,10,c4822d20,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e26d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed3c, ebp = 0xbfbfed58 --- Tracing command imfilterd pid 2063 tid 100137 td 0xc5bfb460 sched_switch(c5bfb460,0,1,24b,835ec9f4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf8018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf8018,0,c085c813,19e,c48d203a,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5bfb460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c48d203a,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c48d203a,c097aa78,158,c085dba8,0,...) at 0xc0661707 = _sleep+0x307 kern_accept(c5bfb460,3,e6e97c70,e6e97c6c,e6e97c68,...) at 0xc06afe4b = kern_accept+0x12b accept(c5bfb460,e6e97cfc,c,c085dbef,c08e1ad0,...) at 0xc06b028f = accept+0x8f syscall(e6e97d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x80f01a7, esp = 0xbfbfedac, ebp = 0xbfbfedc8 --- Tracing command sys-monitor pid 2062 tid 100141 td 0xc5bfaaf0 sched_switch(c5bfaaf0,0,1,24b,639cd318,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf72d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf72d0,0,c085c813,19e,c5bf72b8,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c5bfaaf0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5bf72b8,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5bf72b8,c5bf7348,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c5bfaaf0,80f,e6ea3c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c5bfaaf0,e6ea3cfc,10,c5bfaaf0,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6ea3d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed5c, ebp = 0xbfbfed78 --- Tracing command perform_ca pid 2055 tid 100139 td 0xc5bfb000 sched_switch(c5bfb000,0,1,24b,850654bc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c5bfb000,c5bfb000,c5bfb000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bfb000,0,c085c813,243,c0928754,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928754,0,c0859453,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928754,c5bfb000,0,c0856f85,2cb,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928754,0,c0856f85,2cb,c61dd400,...) at 0xc0660b6b = _sx_xlock+0x6b kern_wait(c5bfb000,ffffffff,e6e9dc2c,1,0,...) at 0xc0638838 = kern_wait+0x128 wait4(c5bfb000,e6e9dcfc,10,c085e083,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e9dd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x81d662f, esp = 0xbfbfdc5c, ebp = 0xbfbfdc78 --- Tracing command sys-monitor pid 2054 tid 100142 td 0xc5bfa8c0 sched_switch(c5bfa8c0,0,1,24b,5b133bc8,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c5bf7018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c5bf7018,0,c085c813,19e,c5bf7000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c5bfa8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c5bf7000,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c5bf7000,c5bf7090,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c5bfa8c0,807,e6ea6c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c5bfa8c0,e6ea6cfc,10,c5bfa8c0,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6ea6d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed3c, ebp = 0xbfbfed58 --- Tracing command sys-ifmonitor pid 2052 tid 100066 td 0xc47fd000 sched_switch(c47fd000,0,1,24b,f46e91dc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c47fd000,c47fd000,c47fd000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47fd000,0,c085c813,243,c0928c34,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928c34,0,c085a2de,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c0928c34,c47fd000,0,c085a213,574,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c0928c34,0,c085a213,574,c47fd000,...) at 0xc0660b6b = _sx_xlock+0x6b userland_sysctl(c47fd000,e6d3fc14,6,0,bfbfe578,...) at 0xc0662a81 = userland_sysctl+0xf1 __sysctl(c47fd000,e6d3fcfc,18,c085d9c6,c08e2af0,...) at 0xc0662eec = __sysctl+0xbc syscall(e6d3fd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x4815cc1f, esp = 0xbfbfe49c, ebp = 0xbfbfe4c8 --- Tracing command postgres pid 1789 tid 100051 td 0xc47bad20 sched_switch(c47bad20,0,1,24b,9a801f78,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47b6588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47b6588,0,c085c813,19e,c4be38dc,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47bad20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4be38dc,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4be38dc,c4be3894,158,c08601ab,0,...) at 0xc0661707 = _sleep+0x307 sbwait(c4be3870,0,c0860221,592,c4be3894,...) at 0xc06a8a42 = sbwait+0x52 soreceive_generic(c4be3820,e6d00be8,e6d00bf4,0,0,...) at 0xc06ad7ac = soreceive_generic+0x3bc soreceive(c4be3820,e6d00be8,e6d00bf4,0,0,...) at 0xc06a98c8 = soreceive+0x38 kern_recvit(c47bad20,7,e6d00c60,0,0,...) at 0xc06af145 = kern_recvit+0x155 recvit(0,4,0,8382ea0,2000,0,0,e6d00c58,1,0,4879bb98,0) at 0xc06af351 = recvit+0x31 recvfrom(c47bad20,e6d00cfc,18,c085e374,c08e1ab8,...) at 0xc06af4c6 = recvfrom+0x76 syscall(e6d00d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x487439a7, esp = 0xbfbfd97c, ebp = 0xbfbfd9a8 --- Tracing command user_ldap_mgr pid 1746 tid 100121 td 0xc4bc88c0 sched_switch(c4bc88c0,0,1,24b,b90dd744,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4bc32d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4bc32d0,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6e61a84,c064d2b9,c097a764,c4bc88c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,7e,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,7e,30f,c06752c0,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 kern_select(c4bc88c0,5,bfbfd100,bfbfd0e0,bfbfd0c0,e6e61c70,0,1e848) at 0xc068f6c4 = kern_select+0x6b4 select(c4bc88c0,e6e61cfc,14,c085dc7c,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6e61d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x481d4903, esp = 0xbfbfd084, ebp = 0xbfbfd128 --- Tracing command sys-monitor pid 1745 tid 100102 td 0xc47f9690 sched_switch(c47f9690,0,1,24b,cd039b8e,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47f3840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47f3840,0,c085c813,19e,c47f3828,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47f9690,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c47f3828,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c47f3828,c47f38b8,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c47f9690,6d2,e6e02c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c47f9690,e6e02cfc,10,c47f9690,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e02d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed4c, ebp = 0xbfbfed68 --- Tracing command user_manager pid 1738 tid 100104 td 0xc4823230 sched_switch(c4823230,0,1,24b,bb01f09c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a71018,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a71018,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6e20ad8,c064d2b9,c097a764,c4823230,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,7e,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,7e,3bb,e6e20b44,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 poll(c4823230,e6e20cfc,c,c085dc7c,c08e2b98,...) at 0xc068eec4 = poll+0x554 syscall(e6e20d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x48123bbf, esp = 0xbfbfe1fc, ebp = 0xbfbfee78 --- Tracing command sys-monitor pid 1737 tid 100075 td 0xc47b7460 sched_switch(c47b7460,0,1,24b,c6064244,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47262d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47262d0,0,c085c813,19e,c47262b8,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47b7460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c47262b8,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c47262b8,c4726348,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c47b7460,6ca,e6d62c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c47b7460,e6d62cfc,10,c47b7460,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6d62d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed4c, ebp = 0xbfbfed68 --- Tracing command ph pid 1730 tid 100185 td 0xc4bc4460 sched_switch(c4bc4460,0,1,24b,3f6a4254,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d9af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d9af8,0,c085c813,19e,c49a5440,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(0,c085c813,155,c4bc4460,c4bc4460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c49a5440,c0929e38,c085a966,100,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c49a5440,c0929e38,100,c085a966,0,...) at 0xc0661707 = _sleep+0x307 __umtx_op_cv_wait(c4bc4460,e6f6fcfc,e6f6fd2c,c07fc233,c4bc4460,...) at 0xc066e439 = __umtx_op_cv_wait+0x2d9 _umtx_op(c4bc4460,e6f6fcfc,14,c085e80c,c08e4290,...) at 0xc066aac7 = _umtx_op+0x27 syscall(e6f6fd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x48152037, esp = 0xbf6fbebc, ebp = 0xbf6fbed8 --- Tracing command ph pid 1730 tid 100184 td 0xc4bc4690 sched_switch(c4bc4690,0,1,24b,37bba2a0,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d9af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d9af8,0,c085c813,19e,c49a5400,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(0,c085c813,155,c4bc4690,c4bc4690,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c49a5400,c0929b28,c085a966,100,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c49a5400,c0929b28,100,c085a966,0,...) at 0xc0661707 = _sleep+0x307 __umtx_op_cv_wait(c4bc4690,e6f6ccfc,e6f6cd2c,c07fc233,c4bc4690,...) at 0xc066e439 = __umtx_op_cv_wait+0x2d9 _umtx_op(c4bc4690,e6f6ccfc,14,c085e80c,c08e4290,...) at 0xc066aac7 = _umtx_op+0x27 syscall(e6f6cd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x48152037, esp = 0xbf7fcebc, ebp = 0xbf7fced8 --- Tracing command ph pid 1730 tid 100183 td 0xc4bc48c0 sched_switch(c4bc48c0,0,1,24b,39c4dc98,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d9af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d9af8,0,c085c813,19e,c49a53c0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(0,c085c813,155,c4bc48c0,c4bc48c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c49a53c0,c0929850,c085a966,100,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c49a53c0,c0929850,100,c085a966,0,...) at 0xc0661707 = _sleep+0x307 __umtx_op_cv_wait(c4bc48c0,e6f69cfc,e6f69d2c,c07fc233,c4bc48c0,...) at 0xc066e439 = __umtx_op_cv_wait+0x2d9 _umtx_op(c4bc48c0,e6f69cfc,14,c085e80c,c08e4290,...) at 0xc066aac7 = _umtx_op+0x27 syscall(e6f69d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x48152037, esp = 0xbf8fdebc, ebp = 0xbf8fded8 --- Tracing command ph pid 1730 tid 100182 td 0xc4bc4af0 sched_switch(c4bc4af0,0,1,24b,3f68f566,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d9af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d9af8,0,c085c813,19e,c49a5380,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(0,c085c813,155,c4bc4af0,c4bc4af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c49a5380,c0929ea8,c085a966,100,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c49a5380,c0929ea8,100,c085a966,0,...) at 0xc0661707 = _sleep+0x307 __umtx_op_cv_wait(c4bc4af0,e6f66cfc,e6f66d2c,c07fc233,c4bc4af0,...) at 0xc066e439 = __umtx_op_cv_wait+0x2d9 _umtx_op(c4bc4af0,e6f66cfc,14,c085e80c,c08e4290,...) at 0xc066aac7 = _umtx_op+0x27 syscall(e6f66d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x48152037, esp = 0xbf9feebc, ebp = 0xbf9feed8 --- Tracing command ph pid 1730 tid 100082 td 0xc48dc230 sched_switch(c48dc230,0,1,24b,3f619f36,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48d9af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48d9af8,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6d9aad8,c064d2b9,c097a764,c48dc230,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,2,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,2,3bb,92,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 poll(c48dc230,e6d9acfc,c,c085e083,c08e2b98,...) at 0xc068eec4 = poll+0x554 syscall(e6d9ad38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x48233bbf, esp = 0xbfbfdf6c, ebp = 0xbfbfdf88 --- Tracing command sys-monitor pid 1729 tid 100111 td 0xc4822230 sched_switch(c4822230,0,1,24b,c0c2b368,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a6f840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a6f840,0,c085c813,19e,c4a6f828,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c4822230,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c4a6f828,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c4a6f828,c4a6f8b8,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c4822230,6c2,e6e35c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c4822230,e6e35cfc,10,c4822230,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e35d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed4c, ebp = 0xbfbfed68 --- Tracing command ph_alert_mgr pid 1441 tid 100105 td 0xc4823000 sched_switch(c4823000,0,1,24b,f3dcfad4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a70af8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a70af8,0,c085c813,19e,c48cd51a,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c4823000,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c48cd51a,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c48cd51a,c097aa78,158,c085dba8,0,...) at 0xc0661707 = _sleep+0x307 kern_accept(c4823000,3,e6e23c70,e6e23c6c,e6e23c68,...) at 0xc06afe4b = kern_accept+0x12b accept(c4823000,e6e23cfc,c,c085d947,c08e1ad0,...) at 0xc06b028f = accept+0x8f syscall(e6e23d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x4856766f, esp = 0xbfbfe1fc, ebp = 0xbfbfee88 --- Tracing command sys-monitor pid 1440 tid 100103 td 0xc47f9460 sched_switch(c47f9460,0,1,24b,6364a10c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47f3588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47f3588,0,c085c813,19e,c47f3570,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c47f9460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c47f3570,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c47f3570,c47f3600,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c47f9460,5a1,e6e05c2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c47f9460,e6e05cfc,10,c47f9460,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6e05d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfed4c, ebp = 0xbfbfed68 --- Tracing command postgres pid 1429 tid 100116 td 0xc47fd690 sched_switch(c47fd690,0,1,24b,7b5d0310,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a6e840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a6e840,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6e44ad8,c064d2b9,c097a764,c47fd690,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,7d1,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,7d1,3bb,c0861f5f,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 poll(c47fd690,e6e44cfc,c,c085d9cb,c08e2b98,...) at 0xc068eec4 = poll+0x554 syscall(e6e44d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x48735bbf, esp = 0xbfbfd3bc, ebp = 0xbfbfd3d8 --- Tracing command postgres pid 1428 tid 100061 td 0xc47ba460 sched_switch(c47ba460,0,1,24b,91426808,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47b5840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47b5840,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6d2ba84,c064d2b9,c097a764,c47ba460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,3e9,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,3e9,30f,41c,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 kern_select(c47ba460,0,0,0,0,e6d2bc70,1,0) at 0xc068f6c4 = kern_select+0x6b4 select(c47ba460,e6d2bcfc,14,c085d9cb,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6d2bd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x4878a903, esp = 0xbfbfd76c, ebp = 0xbfbfd798 --- Tracing command postgres pid 1427 tid 100118 td 0xc47fd230 sched_switch(c47fd230,0,1,24b,b7f580a4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a6e2d0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a6e2d0,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6e4aa84,c064d2b9,c097a764,c47fd230,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,c9,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,c9,30f,0,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 kern_select(c47fd230,0,0,0,0,e6e4ac70,0,30d40) at 0xc068f6c4 = kern_select+0x6b4 select(c47fd230,e6e4acfc,14,c085d9cb,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6e4ad38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x4878a903, esp = 0xbfbfd6ec, ebp = 0xbfbfd718 --- Tracing command postgres pid 1426 tid 100065 td 0xc4598af0 sched_switch(c4598af0,0,1,24b,bd0178dc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47f1840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47f1840,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c097a77c,e6d3ba84,c064d2b9,c097a764,c4598af0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_timedwait_sig(c097a77c,c9,c086acda,101,0,...) at 0xc0687f57 = sleepq_timedwait_sig+0x17 _cv_timedwait_sig(c097a77c,c097a764,c9,30f,e6d3bb48,...) at 0xc0625df8 = _cv_timedwait_sig+0x1a8 kern_select(c4598af0,0,0,0,0,e6d3bc70,0,30d40) at 0xc068f6c4 = kern_select+0x6b4 select(c4598af0,e6d3bcfc,14,16,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6d3bd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x4878a903, esp = 0xbfbfd6cc, ebp = 0xbfbfd6f8 --- Tracing command postgres pid 1424 tid 100109 td 0xc4822690 sched_switch(c4822690,0,1,24b,7f6ac758,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4822690,c4822690,c4822690,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4822690,0,c085c813,243,c092873c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c092873c,0,c085944b,3,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sx_xlock_hard(c092873c,c4822690,0,c085706f,135,...) at 0xc066092e = _sx_xlock_hard+0x22e _sx_xlock(c092873c,0,c085706f,135,0,...) at 0xc0660b6b = _sx_xlock+0x6b fork1(c4822690,14,0,e6e2fc78,c4822690,...) at 0xc063aa6b = fork1+0x2eb fork(c4822690,e6e2fcfc,c08775cf,c085da12,c08e1830,...) at 0xc063bc79 = fork+0x29 syscall(e6e2fd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip = 0x4870a5ab, esp = 0xbfbfd82c, ebp = 0xbfbfd858 --- Tracing command sys-monitor pid 1422 tid 100078 td 0xc47b7000 sched_switch(c47b7000,0,1,24b,e0b3308c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48da840,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48da840,0,c085c813,19e,c48da828,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47b7000,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c48da828,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c48da828,c48da8b8,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c47b7000,590,e6d8ec2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c47b7000,e6d8ecfc,10,c47b7000,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e6d8ed38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x480dc58b, esp = 0xbfbfecdc, ebp = 0xbfbfecf8 --- Tracing command syslogd pid 1345 tid 100110 td 0xc4822460 sched_switch(c4822460,0,1,24b,d28deacc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c4a6faf8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4a6faf8,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6e32a84,c064d2b9,c097a764,0,c4822460,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c097a77c,c097a764,c086acda,101,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _cv_wait_sig(c097a77c,c097a764,c085d774,30f,41c,...) at 0xc06262a8 = _cv_wait_sig+0x198 kern_select(c4822460,8,4821e090,0,0,0,0,4817eb98) at 0xc068f6dc = kern_select+0x6cc select(c4822460,e6e32cfc,14,c085da12,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6e32d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x4816d903, esp = 0xbfbfdf3c, ebp = 0xbfbfee88 --- Tracing command accounting pid 1316 tid 100055 td 0xc47afaf0 sched_switch(c47afaf0,0,1,24b,101c8510,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c47afaf0,c47afaf0,c47afaf0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47afaf0,0,c085c813,266,c47afaf0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c0926a60,e6d13aec,e6d13ae8,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c0926a60,c0926a48,0,c0853461,3a98,...) at 0xc06616f4 = _sleep+0x2f4 acct_thread(0,e6d13d38,c085706f,31c,c47f3000,...) at 0xc06252ae = acct_thread+0x32e fork_exit(c0624f80,0,e6d13d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe6d13d70, ebp = 0 --- Tracing command devd pid 465 tid 100079 td 0xc48dc8c0 sched_switch(c48dc8c0,0,1,24b,32cb3dfc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c48da588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c48da588,0,c085c813,19e,c097a77c,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(e6d91a84,c064d2b9,c097a764,0,c48dc8c0,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c097a77c,c097a764,c086acda,101,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _cv_wait_sig(c097a77c,c097a764,c085d774,30f,c0934030,...) at 0xc06262a8 = _cv_wait_sig+0x198 kern_select(c48dc8c0,5,bfbfedf8,0,0,0,3cd,8) at 0xc068f6dc = kern_select+0x6cc select(c48dc8c0,e6d91cfc,14,c082c73d,c08e20b8,...) at 0xc068f8ae = select+0x5e syscall(e6d91d38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x8086b3f, esp = 0xbfbfe9bc, ebp = 0xbfbfee98 --- Tracing command adjkerntz pid 120 tid 100062 td 0xc47ba230 sched_switch(c47ba230,0,1,24b,bce4a928,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c47b5588,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c47b5588,0,c085c813,19e,c47b55d0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c0931040,8,c085a1a5,c47ba230,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c47b55d0,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c47b55d0,c47b5600,168,c083407d,0,...) at 0xc0661707 = _sleep+0x307 kern_sigsuspend(c47ba230,0,0,0,0,...) at 0xc065b8f4 = kern_sigsuspend+0xe4 sigsuspend(c47ba230,e6d2fcfc,4,c092ac40,c08e37f8,...) at 0xc065b97d = sigsuspend+0x4d syscall(e6d2fd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (341, FreeBSD ELF32, sigsuspend), eip = 0x480c35cb, esp = 0xbfbfedcc, ebp = 0xbfbfee98 --- Tracing command softdepflush pid 49 tid 100048 td 0xc45598c0 sched_switch(c45598c0,0,1,24b,8ff927e8,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c45598c0,c45598c0,c45598c0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c45598c0,0,c085c813,266,c45598c0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c09836c8,3e8,c086c62b,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c09836c8,c0983688,44,c086c62b,3e8,...) at 0xc06616f4 = _sleep+0x2f4 softdep_flush(0,e4b08d38,c085706f,31c,c4722570,...) at 0xc0785b02 = softdep_flush+0x2c2 fork_exit(c0785840,0,e4b08d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4b08d70, ebp = 0 --- Tracing command vnlru pid 48 tid 100047 td 0xc4559af0 sched_switch(c4559af0,0,1,24b,9cba887c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4559af0,c4559af0,c4559af0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4559af0,0,c085c813,266,c4559af0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c4722828,3e8,c0862300,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c4722828,c097aeb8,250,c0862300,3e8,...) at 0xc06616f4 = _sleep+0x2f4 vnlru_proc(0,e4b05d38,c085706f,31c,c4722828,...) at 0xc06cddd5 = vnlru_proc+0x115 fork_exit(c06cdcc0,0,e4b05d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4b05d70, ebp = 0 --- Tracing command syncer pid 47 tid 100046 td 0xc4559d20 sched_switch(c4559d20,0,1,24b,b7dc9f2c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4559d20,c4559d20,c4559d20,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4559d20,0,c085c813,243,c4559d20,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0928bec,0,c08622ba,0,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c0928bec,c097aee4,68,c08622ba,0,...) at 0xc0661716 = _sleep+0x316 sched_sync(0,e4b02d38,c085706f,31c,c4722ae0,...) at 0xc06cd4b4 = sched_sync+0x6f4 fork_exit(c06ccdc0,0,e4b02d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4b02d70, ebp = 0 --- Tracing command bufdaemon pid 46 tid 100045 td 0xc4597000 sched_switch(c4597000,0,1,24b,bcb768dc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4597000,c4597000,c4597000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4597000,0,c085c813,266,c4597000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c097ac04,3e8,c0860b21,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c097ac04,c097ac08,44,c0860b21,3e8,...) at 0xc06616f4 = _sleep+0x2f4 buf_daemon(0,e4affd38,c085706f,31c,c4725000,...) at 0xc06bab4e = buf_daemon+0x21e fork_exit(c06ba930,0,e4affd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4affd70, ebp = 0 --- Tracing command idlepoll pid 45 tid 100044 td 0xc4597230 sched_switch(c4597230,0,1,24b,a233ae50,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4597230,c4597230,c4597230,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4597230,0,c085c813,266,c4597230,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c0928318,bb8,c085905c,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c0928318,0,0,c085905c,bb8,...) at 0xc06616f4 = _sleep+0x2f4 poll_idle(0,e4afcd38,c085706f,31c,c47252b8,...) at 0xc064ec3a = poll_idle+0x13a fork_exit(c064eb00,0,e4afcd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4afcd70, ebp = 0 --- Tracing command pagezero pid 44 tid 100043 td 0xc4597460 sched_switch(c4597460,0,1,24b,2ab64234,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4597460,c4597460,c4597460,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4597460,0,c085c813,266,c4597460,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c09842a0,493e0,c086fa26,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c09842a0,c0983e44,0,c086fa26,493e0,...) at 0xc06616f4 = _sleep+0x2f4 vm_pagezero(0,e4af9d38,c085706f,31c,c4725570,...) at 0xc07ba093 = vm_pagezero+0xb3 fork_exit(c07b9fe0,0,e4af9d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4af9d70, ebp = 0 --- Tracing command vmdaemon pid 43 tid 100042 td 0xc4597690 sched_switch(c4597690,0,1,24b,d4dd7378,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4597690,c4597690,c4597690,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4597690,0,c085c813,243,c4597690,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0983eb8,0,c085a1a5,d8,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c0983eb8,c0983ebc,68,c0860b21,0,...) at 0xc0661716 = _sleep+0x316 vm_daemon(0,e4af6d38,c085706f,31c,c4725828,...) at 0xc07b5f19 = vm_daemon+0x59 fork_exit(c07b5ec0,0,e4af6d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4af6d70, ebp = 0 --- Tracing command pagedaemon pid 42 tid 100041 td 0xc45978c0 sched_switch(c45978c0,0,1,24b,5b3a8c6c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c45978c0,c45978c0,c45978c0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c45978c0,0,c085c813,266,c45978c0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c0983e80,1388,c0860b21,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c0983e80,c0983e44,44,c0860b21,1388,...) at 0xc06616f4 = _sleep+0x2f4 vm_pageout(0,e4af3d38,c085706f,31c,c4725ae0,...) at 0xc07b6beb = vm_pageout+0x2bb fork_exit(c07b6930,0,e4af3d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4af3d70, ebp = 0 --- Tracing command dummynet pid 41 tid 100040 td 0xc4597af0 sched_switch(c4597af0,0,1,24b,be92c06e,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4597af0,c4597af0,c4597af0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4597af0,0,c085c813,243,c46c6480,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c46c6480,0,c085a1dd,c0853461,0,...) at 0xc06880b6 = sleepq_wait+0x36 msleep_spin(c46c6480,c46c649c,c0853461,0,c085706f,...) at 0xc0661a0d = msleep_spin+0x1bd taskqueue_thread_loop(c097bf70,e4af0d38,c085706f,31c,c4726000,...) at 0xc068929a = taskqueue_thread_loop+0x8a fork_exit(c0689210,c097bf70,e4af0d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4af0d70, ebp = 0 --- Tracing command irq7: ppbus0 ppc0 pid 40 tid 100039 td 0xc4597d20 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command fdc0 pid 39 tid 100038 td 0xc4598000 sched_switch(c4598000,0,1,24b,b93dcf8c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4598000,c4598000,c4598000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4598000,0,c085c813,266,c4598000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c456a83c,3e8,c0853461,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c456a83c,c456a8f0,4c,c0853461,3e8,...) at 0xc06616f4 = _sleep+0x2f4 fdc_thread(c456a800,e4aead38,c085706f,31c,c455a2b8,...) at 0xc07ca578 = fdc_thread+0x2b8 fork_exit(c07ca2c0,c456a800,e4aead38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4aead70, ebp = 0 --- Tracing command swi0: sio pid 38 tid 100037 td 0xc4500d20 sched_switch(c4500d20,0,1,8,1df7c480,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085723f,4a1,c4591be8,...) at 0xc06611d3 = mi_switch+0x143 ithread_loop(c458b0c0,e4addd38,c085706f,31c,c455a570,...) at 0xc063cfe0 = ithread_loop+0x2a0 fork_exit(c063cd40,c458b0c0,e4addd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4addd70, ebp = 0 --- Tracing command irq1: atkbd0 pid 37 tid 100036 td 0xc4558000 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command irq15: ata1 pid 36 tid 100035 td 0xc4558230 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command irq14: ata0 pid 35 tid 100034 td 0xc4558460 sched_switch(c4558460,0,1,8,9a53a2d0,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085723f,4a1,c4427ce8,...) at 0xc06611d3 = mi_switch+0x143 ithread_loop(c456e950,e4ac1d38,c085706f,31c,c455b000,...) at 0xc063cfe0 = ithread_loop+0x2a0 fork_exit(c063cd40,c456e950,e4ac1d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4ac1d70, ebp = 0 --- Tracing command usb2 pid 34 tid 100033 td 0xc4558690 sched_switch(c4558690,0,1,24b,5c98da84,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4558690,c4558690,c4558690,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4558690,0,c085c813,266,c4558690,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c455d210,ea60,c0851f70,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c455d210,0,5c,c0851f70,ea60,...) at 0xc06616f4 = _sleep+0x2f4 usb_event_thread(c4532880,e4aabd38,c085706f,31c,c455b2b8,...) at 0xc05e34ea = usb_event_thread+0xca fork_exit(c05e3420,c4532880,e4aabd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4aabd70, ebp = 0 --- Tracing command irq18: uhci2 pid 33 tid 100032 td 0xc45588c0 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command usb1 pid 32 tid 100031 td 0xc4558af0 sched_switch(c4558af0,0,1,24b,5cfa515c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4558af0,c4558af0,c4558af0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4558af0,0,c085c813,266,c4558af0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c453e210,ea60,c0851f70,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c453e210,0,5c,c0851f70,ea60,...) at 0xc06616f4 = _sleep+0x2f4 usb_event_thread(c45511c0,e4aa4d38,c085706f,31c,c455b828,...) at 0xc05e34ea = usb_event_thread+0xca fork_exit(c05e3420,c45511c0,e4aa4d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4aa4d70, ebp = 0 --- Tracing command irq19: uhci1 pid 31 tid 100030 td 0xc4558d20 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command usbtask-dr pid 30 tid 100029 td 0xc4559000 sched_switch(c4559000,0,1,24b,c926f954,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4559000,c4559000,c4559000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4559000,0,c085c813,243,c4559000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0925bd4,0,c085a1a5,d8,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c0925bd4,0,5c,c0851f7e,0,...) at 0xc0661716 = _sleep+0x316 usb_task_thread(c0925bd4,e4a9dd38,c085706f,31c,c44fd2b8,...) at 0xc05e3b1e = usb_task_thread+0x5e fork_exit(c05e3ac0,c0925bd4,e4a9dd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a9dd70, ebp = 0 --- Tracing command usbtask-hc pid 29 tid 100028 td 0xc4559230 sched_switch(c4559230,0,1,24b,c926d768,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4559230,c4559230,c4559230,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4559230,0,c085c813,243,c4559230,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0925bc0,0,c085a1a5,d8,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c0925bc0,0,5c,c0851f7e,0,...) at 0xc0661716 = _sleep+0x316 usb_task_thread(c0925bc0,e4a9ad38,c085706f,31c,c44fd570,...) at 0xc05e3b1e = usb_task_thread+0x5e fork_exit(c05e3ac0,c0925bc0,e4a9ad38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a9ad70, ebp = 0 --- Tracing command usb0 pid 28 tid 100027 td 0xc4559460 sched_switch(c4559460,0,1,24b,5cb14f58,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4559460,c4559460,c4559460,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4559460,0,c085c813,266,c4559460,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c4544210,ea60,c0851f70,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c4544210,0,5c,c0851f70,ea60,...) at 0xc06616f4 = _sleep+0x2f4 usb_event_thread(c4551e80,e4a97d38,c085706f,31c,c44fd828,...) at 0xc05e34ea = usb_event_thread+0xca fork_exit(c05e3420,c4551e80,e4a97d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a97d70, ebp = 0 --- Tracing command irq16: uhci0 pid 27 tid 100026 td 0xc4472690 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command em1 taskq pid 26 tid 100025 td 0xc44728c0 sched_switch(c44728c0,0,1,24b,bfb11454,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c44728c0,c44728c0,c44728c0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c44728c0,0,c085c813,243,c4523a00,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c4523a00,0,c085a1dd,c0853461,0,...) at 0xc06880b6 = sleepq_wait+0x36 msleep_spin(c4523a00,c4523a1c,c0853461,0,c085706f,...) at 0xc0661a0d = msleep_spin+0x1bd taskqueue_thread_loop(c453d35c,e4a90d38,c085706f,31c,c450f000,...) at 0xc068929a = taskqueue_thread_loop+0x8a fork_exit(c0689210,c453d35c,e4a90d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a90d70, ebp = 0 --- Tracing command em0 taskq pid 25 tid 100024 td 0xc4472af0 sched_switch(c4472af0,0,1,24b,c06d3b40,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4472af0,c4472af0,c4472af0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4472af0,0,c085c813,243,c4523c00,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c4523c00,0,c085a1dd,c0853461,0,...) at 0xc06880b6 = sleepq_wait+0x36 msleep_spin(c4523c00,c4523c1c,c0853461,0,c085706f,...) at 0xc0661a0d = msleep_spin+0x1bd taskqueue_thread_loop(c453735c,e4a6dd38,c085706f,31c,c450f2b8,...) at 0xc068929a = taskqueue_thread_loop+0x8a fork_exit(c0689210,c453735c,e4a6dd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a6dd70, ebp = 0 --- Tracing command irq9: acpi0 pid 24 tid 100023 td 0xc4472d20 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command kqueue taskq pid 23 tid 100022 td 0xc4500000 sched_switch(c4500000,0,1,24b,c9467de4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4500000,c4500000,c4500000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4500000,0,c085c813,243,c4500000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c446ed80,c446ed9c,c0853461,0,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c446ed80,c446ed9c,0,c0853461,0,...) at 0xc0661716 = _sleep+0x316 taskqueue_thread_loop(c0926b9c,e4a42d38,c085706f,31c,c450f828,...) at 0xc06892c4 = taskqueue_thread_loop+0xb4 fork_exit(c0689210,c0926b9c,e4a42d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a42d70, ebp = 0 --- Tracing command swi2: cambio pid 22 tid 100021 td 0xc4500230 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command xpt_thrd pid 9 tid 100020 td 0xc4500460 sched_switch(c4500460,0,1,24b,c92689dc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4500460,c4500460,c4500460,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4500460,0,c085c813,243,c4500460,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c090c954,0,c085a1a5,d8,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c090c954,c090c96c,4c,c0829a04,0,...) at 0xc0661716 = _sleep+0x316 xpt_scanner_thread(0,e4a3cd38,c085706f,31c,c446f828,...) at 0xc0454301 = xpt_scanner_thread+0x41 fork_exit(c04542c0,0,e4a3cd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a3cd70, ebp = 0 --- Tracing command swi6: task queue pid 21 tid 100019 td 0xc4500690 sched_switch(c4500690,0,1,8,c4c7a8dc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085723f,4a1,c44b30e8,...) at 0xc06611d3 = mi_switch+0x143 ithread_loop(c44ac590,e4a39d38,c085706f,31c,c446fae0,...) at 0xc063cfe0 = ithread_loop+0x2a0 fork_exit(c063cd40,c44ac590,e4a39d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a39d70, ebp = 0 --- Tracing command swi6: Giant taskq pid 20 tid 100018 td 0xc45008c0 sched_switch(c45008c0,0,1,8,6eb5da0c,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085723f,4a1,c44b31e8,...) at 0xc06611d3 = mi_switch+0x143 ithread_loop(c44ac5a0,e4a36d38,c085706f,31c,c44fc000,...) at 0xc063cfe0 = ithread_loop+0x2a0 fork_exit(c063cd40,c44ac5a0,e4a36d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a36d70, ebp = 0 --- Tracing command acpi_task_2 pid 8 tid 100017 td 0xc4500af0 sched_switch(c4500af0,0,1,24b,c9465d00,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4500af0,c4500af0,c4500af0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4500af0,0,c085c813,243,c4500af0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c44b3280,c44b329c,c0853461,0,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c44b3280,c44b329c,0,c0853461,0,...) at 0xc0661716 = _sleep+0x316 taskqueue_thread_loop(c0b2bebc,e4a33d38,c085706f,31c,c44fc2b8,...) at 0xc06892c4 = taskqueue_thread_loop+0xb4 fork_exit(c0689210,c0b2bebc,e4a33d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a33d70, ebp = 0 --- Tracing command acpi_task_1 pid 7 tid 100016 td 0xc442f230 sched_switch(c442f230,0,1,24b,c9463cc8,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c442f230,c442f230,c442f230,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c442f230,0,c085c813,243,c442f230,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c44b3280,c44b329c,c0853461,0,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c44b3280,c44b329c,0,c0853461,0,...) at 0xc0661716 = _sleep+0x316 taskqueue_thread_loop(c0b2bebc,e4a30d38,c085706f,31c,c44fc570,...) at 0xc06892c4 = taskqueue_thread_loop+0xb4 fork_exit(c0689210,c0b2bebc,e4a30d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a30d70, ebp = 0 --- Tracing command acpi_task_0 pid 6 tid 100015 td 0xc442f460 sched_switch(c442f460,0,1,24b,c9461c40,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c442f460,c442f460,c442f460,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c442f460,0,c085c813,243,c442f460,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c44b3280,c44b329c,c0853461,0,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c44b3280,c44b329c,0,c0853461,0,...) at 0xc0661716 = _sleep+0x316 taskqueue_thread_loop(c0b2bebc,e4a2dd38,c085706f,31c,c44fc828,...) at 0xc06892c4 = taskqueue_thread_loop+0xb4 fork_exit(c0689210,c0b2bebc,e4a2dd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a2dd70, ebp = 0 --- Tracing command thread taskq pid 5 tid 100014 td 0xc442f690 sched_switch(c442f690,0,1,24b,cf283398,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c442f690,c442f690,c442f690,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c442f690,0,c085c813,243,c442f690,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c44b3300,c44b331c,c0853461,0,0,...) at 0xc06880b6 = sleepq_wait+0x36 _sleep(c44b3300,c44b331c,0,c0853461,0,...) at 0xc0661716 = _sleep+0x316 taskqueue_thread_loop(c093319c,e4a2ad38,c085706f,31c,c44fcae0,...) at 0xc06892c4 = taskqueue_thread_loop+0xb4 fork_exit(c0689210,c093319c,e4a2ad38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a2ad70, ebp = 0 --- Tracing command swi5: + pid 19 tid 100013 td 0xc442f8c0 sched_switch(c442f8c0,0,1,8,52e8b408,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085723f,4a1,c44b33e8,...) at 0xc06611d3 = mi_switch+0x143 ithread_loop(c44ac5d0,e4a27d38,c085706f,31c,c44fd000,...) at 0xc063cfe0 = ithread_loop+0x2a0 fork_exit(c063cd40,c44ac5d0,e4a27d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a27d70, ebp = 0 --- Tracing command yarrow pid 18 tid 100012 td 0xc442faf0 sched_switch(c442faf0,0,1,24b,bcdbd8c8,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c442faf0,c442faf0,c442faf0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c442faf0,0,c085c813,266,c442faf0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c0928bf4,64,c0853461,2,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c0928bf4,0,0,c0853461,64,...) at 0xc06616f4 = _sleep+0x2f4 pause(c0853461,64,c084c2fe,113,0,...) at 0xc0661810 = pause+0x30 random_kthread(0,e4a24d38,c085706f,31c,c442c2b8,...) at 0xc059a0f4 = random_kthread+0x1b4 fork_exit(c0599f40,0,e4a24d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a24d70, ebp = 0 --- Tracing command g_down pid 4 tid 100011 td 0xc442fd20 sched_switch(c442fd20,0,1,24b,bc9ef280,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c442fd20,c442fd20,c442fd20,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c442fd20,0,c085c813,266,c442fd20,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c092634c,64,c0853461,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c092634c,c0926268,24c,c0853461,64,...) at 0xc06616f4 = _sleep+0x2f4 g_io_schedule_down(c442fd20,0,c08542bf,74,0,...) at 0xc060ac0b = g_io_schedule_down+0x6b g_down_procbody(0,e4a21d38,c085706f,31c,c442c570,...) at 0xc060b2e9 = g_down_procbody+0x69 fork_exit(c060b280,0,e4a21d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a21d70, ebp = 0 --- Tracing command g_up pid 3 tid 100010 td 0xc4472000 sched_switch(c4472000,0,1,24b,bcab16d4,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4472000,c4472000,c4472000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4472000,0,c085c813,266,c4472000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c0926348,64,c0853461,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c0926348,c09262a8,24c,c0853461,64,...) at 0xc06616f4 = _sleep+0x2f4 g_io_schedule_up(c4472000,0,c08542bf,5d,0,...) at 0xc060af12 = g_io_schedule_up+0xd2 g_up_procbody(0,e4a1ed38,c085706f,31c,c442c828,...) at 0xc060b359 = g_up_procbody+0x69 fork_exit(c060b2f0,0,e4a1ed38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a1ed70, ebp = 0 --- Tracing command g_event pid 2 tid 100009 td 0xc4472230 sched_switch(c4472230,0,1,24b,bb0d1288,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c4472230,c4472230,c4472230,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c4472230,0,c085c813,266,c4472230,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c0926340,64,c0853461,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c0926340,0,4c,c0853461,64,...) at 0xc06616f4 = _sleep+0x2f4 g_event_procbody(0,e4a1bd38,c085706f,31c,c442cae0,...) at 0xc060b407 = g_event_procbody+0xa7 fork_exit(c060b360,0,e4a1bd38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a1bd70, ebp = 0 --- Tracing command swi3: vm pid 17 tid 100008 td 0xc4472460 fork_trampoline() at 0xc07e4238 = fork_trampoline Tracing command swi4: clock sio pid 16 tid 100007 td 0xc442d000 sched_switch(c442d000,0,1,8,be9261ec,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085723f,4a1,c446d8e8,...) at 0xc06611d3 = mi_switch+0x143 ithread_loop(c442a480,e4a15d38,c085706f,31c,c446f2b8,...) at 0xc063cfe0 = ithread_loop+0x2a0 fork_exit(c063cd40,c442a480,e4a15d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a15d70, ebp = 0 --- Tracing command swi1: net pid 15 tid 100006 td 0xc442d230 sched_switch(c442d230,0,1,8,417ebe60,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c085723f,4a1,c446d968,...) at 0xc06611d3 = mi_switch+0x143 ithread_loop(c442a490,e4a12d38,c085706f,31c,c446f570,...) at 0xc063cfe0 = ithread_loop+0x2a0 fork_exit(c063cd40,c442a490,e4a12d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4a12d70, ebp = 0 --- Tracing command idle: cpu0 pid 14 tid 100005 td 0xc442d460 kdb_enter_why(c082fb36,c084fd03,8,872014,c458e08c,...) at 0xc0680b4a = kdb_enter_why+0x3a siointr1(c09861cc,0,c0872014,56f,e300ac48,...) at 0xc07d5836 = siointr1+0xe6 siointr(c458e000,c092ac40,c442d460,c442d460,c4428280,...) at 0xc07d6512 = siointr+0x32 intr_execute_handlers(c4410cd0,e300ac68,e300acac,c07e4594,39,...) at 0xc07e922c = intr_execute_handlers+0xec lapic_handle_intr(39,e300ac68) at 0xc07ec81f = lapic_handle_intr+0x3f Xapic_isr1() at 0xc07e4594 = Xapic_isr1+0x34 --- interrupt, eip = 0xc07efe7b, esp = 0xe300aca8, ebp = 0xe300acac --- spinlock_exit(c0931040,8,c085adbe,32d) at 0xc07efe7b = spinlock_exit+0x2b _mtx_unlock_spin_flags(c0931040,0,c085adbe,32d,c092ac40,...) at 0xc064d06d = _mtx_unlock_spin_flags+0x4d sched_idletd(0,e300ad38,c085706f,31c,c442b000,...) at 0xc067662f = sched_idletd+0x21f fork_exit(c0676410,0,e300ad38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe300ad70, ebp = 0 --- Tracing command idle: cpu1 pid 13 tid 100004 td 0xc442d690 sched_switch(c442d690,0,6,8,2e3c1ab2,...) at 0xc0676004 = sched_switch+0x324 mi_switch(6,0,c0876302,47e,1,...) at 0xc06611d3 = mi_switch+0x143 ipi_bitmap_handler(8,c4420028,28,0,f,...) at 0xc07f1b72 = ipi_bitmap_handler+0x72 Xipi_intr_bitmap_handler() at 0xc07e48be = Xipi_intr_bitmap_handler+0x2e --- interrupt, eip = 0xc07f1562, esp = 0xe3007cbc, ebp = 0xe3007cc0 --- mp_grab_cpu_hlt(e3007cf8,c0676639,c0931040,0,c085adbe,...) at 0xc07f1562 = mp_grab_cpu_hlt+0x22 cpu_idle(c0931040,0,c085adbe,32d,c092b280,...) at 0xc07eeed8 = cpu_idle+0x8 sched_idletd(0,e3007d38,c085706f,31c,c442b2b8,...) at 0xc0676639 = sched_idletd+0x229 fork_exit(c0676410,0,e3007d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3007d70, ebp = 0 --- Tracing command idle: cpu2 pid 12 tid 100003 td 0xc442d8c0 cpustop_handler(4,e3004c68,c07fc4d0,c442b570,c09310c0,...) at 0xc07f2c52 = cpustop_handler+0x32 ipi_nmi_handler(c442b570,c09310c0,0,c442d8c0,13,...) at 0xc07f2cdf = ipi_nmi_handler+0x2f trap(e3004c74) at 0xc07fc4d0 = trap+0x30 calltrap() at 0xc07e41cb = calltrap+0x6 --- trap 0x13, eip = 0xc064d068, esp = 0xe3004cb4, ebp = 0xe3004cc8 --- _mtx_unlock_spin_flags(c09310c0,0,c085adbe,32d,c092b8c0,...) at 0xc064d068 = _mtx_unlock_spin_flags+0x48 sched_idletd(0,e3004d38,c085706f,31c,c442b570,...) at 0xc067662f = sched_idletd+0x21f fork_exit(c0676410,0,e3004d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3004d70, ebp = 0 --- Tracing command idle: cpu3 pid 11 tid 100002 td 0xc442daf0 cpustop_handler(8,e3001c70,c07fc4d0,c0675428,87,...) at 0xc07f2c52 = cpustop_handler+0x32 ipi_nmi_handler(c0675428,87,c0676004,c442daf0,13,...) at 0xc07f2cdf = ipi_nmi_handler+0x2f trap(e3001c7c) at 0xc07fc4d0 = trap+0x30 calltrap() at 0xc07e41cb = calltrap+0x6 --- trap 0x13, eip = 0xc07f1562, esp = 0xe3001cbc, ebp = 0xe3001cc0 --- mp_grab_cpu_hlt(e3001cf8,c0676639,c09310c0,0,c085adbe,...) at 0xc07f1562 = mp_grab_cpu_hlt+0x22 cpu_idle(c09310c0,0,c085adbe,32d,c092bf00,...) at 0xc07eeed8 = cpu_idle+0x8 sched_idletd(0,e3001d38,c085706f,31c,c442b828,...) at 0xc0676639 = sched_idletd+0x229 fork_exit(c0676410,0,e3001d38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3001d70, ebp = 0 --- Tracing command init pid 1 tid 100001 td 0xc442dd20 sched_switch(c442dd20,0,1,24b,b0c7b6fc,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,8,c085c813,c442baf8,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c442baf8,0,c085c813,19e,c442bae0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_catch_signals(c064d06d,c09310c0,8,c085a1a5,c442dd20,...) at 0xc0687ba5 = sleepq_catch_signals+0x1e5 sleepq_wait_sig(c442bae0,0,c085a1a5,d8,0,...) at 0xc0688034 = sleepq_wait_sig+0x14 _sleep(c442bae0,c442bb70,15c,c085db38,0,...) at 0xc0661707 = _sleep+0x307 kern_wait(c442dd20,ffffffff,e2ffdc2c,0,0,...) at 0xc0639156 = kern_wait+0xa46 wait4(c442dd20,e2ffdcfc,10,c085d947,c08e18a8,...) at 0xc06391cb = wait4+0x3b syscall(e2ffdd38) at 0xc07fc233 = syscall+0x2b3 Xint0x80_syscall() at 0xc07e4230 = Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x805455f, esp = 0xbfbfe97c, ebp = 0xbfbfe998 --- Tracing command audit pid 10 tid 100000 td 0xc442f000 sched_switch(c442f000,0,1,24b,c9210ba0,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c442f000,c442f000,c442f000,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c442f000,0,c085c813,243,c442f000,...) at 0xc06879af = sleepq_switch+0xcf sleepq_wait(c0983114,c09830f4,c086a770,1,0,...) at 0xc06880b6 = sleepq_wait+0x36 _cv_wait(c0983114,c09830f4,c086adb0,18b,0,...) at 0xc0626708 = _cv_wait+0x198 audit_worker(0,e2ffad38,c085706f,31c,c442c000,...) at 0xc076d1a0 = audit_worker+0x50 fork_exit(c076d150,0,e2ffad38) at 0xc063a684 = fork_exit+0x94 fork_trampoline() at 0xc07e4240 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2ffad70, ebp = 0 --- Tracing command swapper pid 0 tid 0 td 0xc09266c0 sched_switch(c09266c0,0,1,24b,1584d894,...) at 0xc0676004 = sched_switch+0x324 mi_switch(1,0,c09266c0,c09266c0,c09266c0,...) at 0xc06611d3 = mi_switch+0x143 sleepq_switch(c09266c0,0,c085c813,266,c09266c0,...) at 0xc06879af = sleepq_switch+0xcf sleepq_timedwait(c0926400,2710,c085b288,0,0,...) at 0xc0687feb = sleepq_timedwait+0x3b _sleep(c0926400,0,44,c085b288,2710,...) at 0xc06616f4 = _sleep+0x2f4 scheduler(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc07a905e = scheduler+0x25e mi_startup() at 0xc0623816 = mi_startup+0x96 begin() at 0xc0446225 = begin+0x2c db> show allchains db> ~ [EOT] capella:~ (502) exit exit Script done on Mon Dec 15 10:58:13 2008 show lockedvnods Locked vnodes 0xc63ffbdc: tag devfs, type VCHR usecount 1, writecount 0, refcount 1 mountedhere 0xc4470100 flags () lock type devfs: EXCL (count 1) by thread 0xc754f690 (pid 92421) dev random 0xc5ed5e04: tag ufs, type VREG usecount 11, writecount 0, refcount 13 mountedhere 0 flags () v_object 0xc5de84d8 ref 10 pages 130 lock type ufs: SHARED (count 1) ino 3297435, on dev ad0s1e From bsdlist at cogeco.ca Mon Dec 15 10:10:26 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Mon Dec 15 10:10:34 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <4934CB77.30906@transactionware.com> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> Message-ID: <494698E4.2070406@cogeco.ca> > Replying to my own post ... > > I have done a test on the same machine comparing 6.3-p1 to 7.1-PRE. > The performance is the expected ~6MB/s (because of the lack of cache) > on 6.3-p1, so the BIOS change doesn't seem to be at fault. > > This seems to be a regression somewhere between 6.3 to 7.1. The Areca > driver is the same in 6.3 and 7.1, so the problem seems to be elsewhere. > > I think this is more than just a "performance" problem. The > observations with gstat showing extremely high ms/w values (I have > seen them as high as 22000) makes it look like IO completion > interrupts are being lost. > > Any suggestions on where to look next? Are there obvious candidates? Hi, I too am having a terrible time with this. I have a server with 7.0 (FreeBSD 7.0-STABLE#0: Sun Jun 29 00:32:38 EDT 2008) that I do not believe the system has the same problem so the 7.1 STABLE and I am looking into downgrading to this version as a possible short term solution. To give you an idea of how slow it gets the two systems are nearly identical in hardware and a "make buildworld" on the 7.1 (FreeBSD 7.1-PRERELEASE #0: Sun Dec 14 09:25:21 EST 2008) took over 10 hours!!! On the machine without the problem and which has a much higher load it took about 2 hours. Both systems have 16gb of RAM with 2 quad core cpus (8 cpus@ 2.33GHz) on a S5000PAL (SR2500ALBRPNA) motherboard. There is a slight difference in the raid card but both use the same raid driver (arcmsr). The system with the problems has a ARC-1130 with a 1 GIG cache chip in a Raid1+0 with 4 drives. So one system took over 8 hours longer to build the world and it was visually slow on the console when building. No errors are tracked at all in the raid card or in the S5000PAL motherboard for the hardware. After weeks of working on this I now believe that anything that taxes the writing to the hard drives causes the system CPU numbers to spike through the roof (approx 80% usage) and the server grinds to a halt. And I also see wide swings in the System CPU usage. It reminds me of the QUOTA issue I had with 6.2 where the system usage was really high and it was the QUOTA code that was broken. I have Polling, Quota, and the Lagg system enabled on both of the systems and have tried to make them as similar as possible in the setup. If I can do any diagnosing on this assuming someone is interested in looking into this issue then let me know what to look for and test. Otherwise, I will have to shortly move back to 7.0 or 6.4 to try to solve the issue. I am very worried about updating to 7.1 in the future and on the other machine as I really have not seen a lot of other people with these problems being discussed. It effectively makes the system mostly unusable as a webserver when it happens as apache ends up needing to be stopped and restarted to get it going again. To this point I have shut off anything I can shut off to try to limit how often it happens. Thanks, Paul From mike at sentex.net Mon Dec 15 11:00:23 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 15 11:00:30 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <494698E4.2070406@cogeco.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> Message-ID: <200812151900.mBFJ0Jom084267@lava.sentex.ca> At 12:50 PM 12/15/2008, Paul MacKenzie wrote: > > Any suggestions on where to look next? Are there obvious candidates? > >After weeks of working on this I now believe that anything that taxes >the writing to the hard drives causes the system CPU numbers to spike >through the roof (approx 80% usage) and the server grinds to a halt. And >I also see wide swings in the System CPU usage. It reminds me of the >QUOTA issue I had with 6.2 where the system usage was really high and it >was the QUOTA code that was broken. Hi, I dont have a box in the lab I can test a lot with right now, but I do have a couple of these cards in customer servers and write performance seems ok This is an AMD64 box, 8G RAM 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Sep 23 09:25:02 EDT 2008 running a lot of postgres queries right now [ns8]# dd if=/dev/zero of=/var/tmp/test count=1000 bs=1024k 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 10.265211 secs (102148508 bytes/sec) [ns8]# which seems reasonable for raw write performance. If you bring up the little Areca web app, are there any errors about the array? When you created the raid sets, what params did you use ? The above is on Volume Capacity 320.0GB SCSI Ch/Id/Lun 0/0/0 Raid Level Raid 1+0 Stripe Size 64KBytes Block Size 512Bytes Member Disks 4 Cache Mode Write Back Tagged Queuing Enabled Volume State Normal [ns8]# vmstat -i interrupt total rate irq4: sio0 57065 0 irq17: em1 3989494045 554 irq18: arcmsr0 558098657 77 cpu0: timer 14381393929 2000 irq256: em0 22763077 3 cpu1: timer 14381384902 1999 Total 33333191675 4635 [ns8]# arcmsr0: mem 0xe8600000-0xe8600fff,0xe8000000-0xe83fffff irq 18 at device 14.0 on pci2 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 arcmsr0: [ITHREAD] ..... Waiting 5 seconds for SCSI devices to settle (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 305175MB (624999424 512 byte sectors: 255H 63S/T 38904C) SMP: AP CPU #1 Launched! From mike at sentex.net Mon Dec 15 12:10:50 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 15 12:10:56 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <4946B6EF.5080806@cogeco.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> Message-ID: <200812152010.mBFKAlZf084580@lava.sentex.ca> At 02:58 PM 12/15/2008, Paul MacKenzie wrote: >This used to be on a 4.11x system with 1 cpu and only 1gb of ram and >ran flawlessly with much less resources with the same web site code >for a long time. I do not have this problem on the other 7.0 >machine. I originally thought it was just a cpu issue but it is very >closely tied to when something is trying to use the raid arrays and >this seems to be the way to reproduce it. > >I am having a hard time determining why the system load is so high. >Can you recommend the best way to identify the culprit? What does top -S show ? Most of the load is in system. Does the machine in question have a rather large master.passwd file by chance ? (http://www.freebsd.org/cgi/query-pr.cgi?pr=75855) ---Mike From mike at sentex.net Mon Dec 15 12:16:52 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 15 12:16:58 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <494698E4.2070406@cogeco.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> Message-ID: <200812152016.mBFKGnN6084606@lava.sentex.ca> At 12:50 PM 12/15/2008, Paul MacKenzie wrote: >I have Polling, Quota, and the Lagg system enabled on both of the >systems and have tried to make them as similar as possible in the setup. I would also try disabling polling. Is you scheduler ULE or BSD? For an 8 core box, it should be ULE ---Mike From mike at sentex.net Mon Dec 15 12:35:49 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 15 12:35:55 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <4946BDB1.8060208@cogeco.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> <4946BDB1.8060208@cogeco.ca> Message-ID: <200812152035.mBFKZkj4084689@lava.sentex.ca> At 03:27 PM 12/15/2008, Paul MacKenzie wrote: > > What does top -S show ? Most of the load is in system. Does the > > machine in question have a rather large master.passwd file by chance ? > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=75855) > > ---Mike > > >Thanks for your quick reply: > >master.passwd is only 9467 (with a ls-l) I would try the change to /etc/nsswitch.conf so that group and passwd read group: files passwd: files At that file size, it sounds like you only have about 200 entries ? I doubt its the issue, but its worth a try. I know at around 9,000 files anything to do with UID lookups (e.g. ls -l) takes forever. > PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT >COMMAND > 54 root 2 0 0 7 0 7 100.00% syncer Do you have any other special tuning other than polling ? Any in /boot/loader.conf or /etc/sysctl.conf ? Does gstat show the disks busy ? ---Mike From bsdlist at cogeco.ca Mon Dec 15 12:48:09 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Mon Dec 15 12:48:16 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <200812152035.mBFKZkj4084689@lava.sentex.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> <4946BDB1.8060208@cogeco.ca> <200812152035.mBFKZkj4084689@lava.sentex.ca> Message-ID: <4946C2FF.3080900@cogeco.ca> > I would try the change to /etc/nsswitch.conf so that group and passwd > read > > group: files > passwd: files > > At that file size, it sounds like you only have about 200 entries ? I > doubt its the issue, but its worth a try. I know at around 9,000 > files anything to do with UID lookups (e.g. ls -l) takes forever. > > >> PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT >> COMMAND >> 54 root 2 0 0 7 0 7 100.00% >> syncer > > Do you have any other special tuning other than polling ? Any in > /boot/loader.conf or /etc/sysctl.conf ? > > Does gstat show the disks busy ? > > ---Mike > Hi Mike, You were close. There are 109 entries. I too found the same problem on another server and I already changed this to files when I was trying to figure it all out. in boot/loader.conf I have: accf_http_load="YES". I tried turning this off but the same problems were seen so I moved on. In /etc/sysctl.conf I have: kern.maxvnodes=400000 kern.ipc.somaxconn=1024 vfs.ufs.dirhash_maxmem=10485760 I added these based on other posts of people's troubles or recommendations in other threads. For the gstat it does not really which was leading me elsewhere about a week: I stopped these at almost the same time and polling is now disabled with a -polling on both interfaces as part of the lagg0: dT: 1.110s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| acd0 0 2 2 173 4.4 0 0 0.0 0.8| da0 0 2 2 173 15.5 0 0 0.0 2.8| da0s1 0 0 0 0 0.0 0 0 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0.0| da0s1a 0 0 0 0 0.0 0 0 0.0 0.0| da0s1b 0 0 0 0 0.0 0 0 0.0 0.0| da0s1c 0 0 0 0 0.0 0 0 0.0 0.0| da0s1d 0 0 0 0 0.0 0 0 0.0 0.0| da0s1e 0 2 2 173 15.9 0 0 0.0 2.9| da0s1f 0 0 0 0 0.0 0 0 0.0 0.0| da1s1 0 0 0 0 0.0 0 0 0.0 0.0| da1s1c 0 0 0 0 0.0 0 0 0.0 0.0| da1s1d top -SI last pid: 56352; load averages: 14.64, 8.57, 6.38 up 0+10:59:33 15:45:32 287 processes: 22 running, 251 sleeping, 14 waiting CPU: 19.6% user, 0.0% nice, 60.2% system, 0.5% interrupt, 19.7% idle Mem: 705M Active, 3290M Inact, 492M Wired, 6888K Cache, 214M Buf, 11G Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56070 www 1 104 0 193M 61040K CPU3 3 1:32 37.89% httpd 1490 mysql 97 4 -5 406M 189M sbwait 7 0:31 37.35% mysqld 14 root 1 171 ki31 0K 16K RUN 4 507:42 30.86% idle: cpu4 17 root 1 171 ki31 0K 16K RUN 1 459:32 30.76% idle: cpu1 11 root 1 171 ki31 0K 16K RUN 7 545:35 30.47% idle: cpu7 16 root 1 171 ki31 0K 16K RUN 2 459:31 28.56% idle: cpu2 13 root 1 171 ki31 0K 16K RUN 5 526:39 24.27% idle: cpu5 15 root 1 171 ki31 0K 16K RUN 3 481:30 23.39% idle: cpu3 56331 samfilter 1 -4 0 14448K 4836K ufs 2 0:05 20.90% perl5.8.8 56201 www 1 -4 0 146M 25472K ufs 3 1:11 14.45% httpd 18 root 1 171 ki31 0K 16K RUN 0 454:31 13.77% idle: cpu0 56321 www 1 -4 0 147M 25728K ufs 2 0:03 11.38% httpd 56343 www 1 -4 0 144M 22772K CPU5 1 0:02 10.79% httpd 56327 www 1 20 0 145M 24408K lockf 7 0:03 10.60% httpd 56339 www 1 54 0 144M 22732K CPU7 1 0:02 10.35% httpd 56266 www 1 -4 0 153M 30560K ufs 2 0:14 10.16% httpd 56186 www 1 -4 0 156M 32720K RUN 4 0:59 9.86% httpd 56095 www 1 -4 0 146M 25700K RUN 1 0:58 9.77% httpd 56189 www 1 -4 0 147M 25620K RUN 5 0:47 9.67% httpd 56260 www 1 -4 0 146M 24748K ufs 2 0:13 9.57% httpd 56185 www 1 -4 0 154M 31068K ufs 2 0:50 9.47% httpd 56345 www 1 -4 0 144M 22732K ufs 3 0:02 9.47% httpd 56205 www 1 -4 0 153M 30840K ufs 2 0:24 9.28% httpd 56277 www 1 -4 0 153M 30228K ufs 2 0:10 9.28% httpd 56297 www 1 4 0 145M 24372K kqread 5 0:04 9.28% httpd 56292 www 1 -4 0 145M 24400K ufs 2 0:06 9.18% httpd 56325 www 1 -4 0 144M 23140K ufs 6 0:03 9.18% httpd 56301 www 1 -4 0 146M 25208K ufs 2 0:05 9.08% httpd 56326 www 1 4 0 144M 23320K sbwait 5 0:03 8.98% httpd 56099 www 1 -4 0 147M 26460K ufs 2 1:43 8.69% httpd 56287 www 1 -4 0 146M 24404K ufs 2 0:11 8.69% httpd 56294 www 1 -4 0 147M 25952K RUN 4 0:09 8.69% httpd 56298 www 1 -4 0 144M 23340K ufs 6 0:07 8.69% httpd 56322 www 1 -4 0 147M 25600K ufs 3 0:03 8.59% httpd 56175 www 1 -4 0 151M 29140K ufs 2 1:26 8.25% httpd 56169 www 1 -4 0 155M 32016K ufs 2 0:57 8.25% httpd 56261 www 1 -4 0 149M 27048K ufs 2 0:13 8.25% httpd 56323 www 1 -4 0 144M 23296K ufs 2 0:03 8.25% httpd 56115 www 1 -4 0 155M 32244K ufs 2 0:55 7.86% httpd 56168 www 1 -4 0 147M 26368K ufs 2 0:42 7.76% httpd 56202 www 1 -4 0 154M 31096K ufs 6 0:24 7.76% httpd 56338 root 1 48 0 8112K 2592K CPU4 4 0:02 7.76% top 56263 www 1 -4 0 150M 28044K ufs 3 0:10 7.67% httpd 56254 www 1 -4 0 145M 24476K ufs 2 0:08 7.67% httpd 56094 www 1 -4 0 155M 31984K ufs 2 0:48 7.57% httpd 56328 www 1 -4 0 144M 23120K CPU0 0 0:02 7.57% httpd Thanks, Paul From kostikbel at gmail.com Mon Dec 15 13:33:42 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Dec 15 13:33:49 2008 Subject: 7.1RC1: system hang In-Reply-To: <49468FE2.4040007@palisadesys.com> References: <49419BE0.2070502@palisadesys.com> <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> <49426880.40302@palisadesys.com> <3a142e750812120729v478d850do93e31e5d8502ef68@mail.gmail.com> <4942C178.2030206@palisadesys.com> <49468FE2.4040007@palisadesys.com> Message-ID: <20081215213332.GQ2038@deviant.kiev.zoral.com.ua> On Mon, Dec 15, 2008 at 11:12:02AM -0600, Guy Helmer wrote: > I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout > as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. Here is the > output from ps/m, show allpcpu, show locks, show alllocks, allt, show > allchains, and show lockedvnods commands in the debugger. Can you show me the source line for vm_fault+0x1b1b ? Do the l *(vm_fault+0x1b1b) at the kgdb prompt, you do not need the core, only the same debugging kernel as was booted on deadlocked machine. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081215/0e857c89/attachment.pgp From ghelmer at palisadesys.com Mon Dec 15 14:13:08 2008 From: ghelmer at palisadesys.com (Guy Helmer) Date: Mon Dec 15 14:13:15 2008 Subject: 7.1RC1: system hang In-Reply-To: <20081215213332.GQ2038@deviant.kiev.zoral.com.ua> References: <49419BE0.2070502@palisadesys.com> <3a142e750812111900u1d9264bh27d39092f5dcc4bf@mail.gmail.com> <49426880.40302@palisadesys.com> <3a142e750812120729v478d850do93e31e5d8502ef68@mail.gmail.com> <4942C178.2030206@palisadesys.com> <49468FE2.4040007@palisadesys.com> <20081215213332.GQ2038@deviant.kiev.zoral.com.ua> Message-ID: <4946D670.40402@palisadesys.com> Kostik Belousov wrote: > On Mon, Dec 15, 2008 at 11:12:02AM -0600, Guy Helmer wrote: > >> I have a recurring hang on FreeBSD 7.1 roughly-RC1 (releng_7_1 checkout >> as of 2008-12-08) on a dual-CPU hyperthreaded Xeon i386. Here is the >> output from ps/m, show allpcpu, show locks, show alllocks, allt, show >> allchains, and show lockedvnods commands in the debugger. >> > Can you show me the source line for vm_fault+0x1b1b ? > Do the l *(vm_fault+0x1b1b) at the kgdb prompt, you do not need the core, > only the same debugging kernel as was booted on deadlocked machine. > (kgdb) l *(vm_fault+0x1b1b) 0xc07a765b is in vm_fault (../../../vm/vm_fault.c:888). 883 if (((fault_flags & VM_FAULT_WIRE_MASK) == 0) && (wired == 0)) { 884 vm_fault_prefault(fs.map->pmap, vaddr, fs.entry); 885 } 886 VM_OBJECT_LOCK(fs.object); 887 vm_page_lock_queues(); 888 vm_page_flag_set(fs.m, PG_REFERENCED); 889 890 /* 891 * If the page is not wired down, then put it where the pageout daemon 892 * can find it. Thanks! Let me know if there is anything else you need, Guy From bsdlist at cogeco.ca Mon Dec 15 14:27:04 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Mon Dec 15 14:27:12 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <200812152035.mBFKZkj4084689@lava.sentex.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> <4946BDB1.8060208@cogeco.ca> <200812152035.mBFKZkj4084689@lava.sentex.ca> Message-ID: <4946DA2F.7090508@cogeco.ca> > I would try the change to /etc/nsswitch.conf so that group and passwd > read > > group: files > passwd: files > > At that file size, it sounds like you only have about 200 entries ? I > doubt its the issue, but its worth a try. I know at around 9,000 > files anything to do with UID lookups (e.g. ls -l) takes forever. > > >> PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT >> COMMAND >> 54 root 2 0 0 7 0 7 100.00% >> syncer > > Do you have any other special tuning other than polling ? Any in > /boot/loader.conf or /etc/sysctl.conf ? > > Does gstat show the disks busy ? > > ---Mike > The next thing I am doing is going to be removing the QUOTA feature to see if this has any bearing on this problem. It does not appear to be even writing at a heavy load as you can see (almost nothing) but the processes are mostly in UFS when it spirals out of control. I moved the processing of amavisd-new into a memory drive to at least take that off the IO and this seems to have helped a bit. There is not a lot of mail going through the system but every little bit helps. I suspect this is one other reason that is bringing the problem to the forefront as amavisd-new can use the disks a bit to process each e-mail. Thanks for your help so far, Paul From bsdlist at cogeco.ca Mon Dec 15 15:43:58 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Mon Dec 15 15:44:08 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <200812152016.mBFKGnN6084606@lava.sentex.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812152016.mBFKGnN6084606@lava.sentex.ca> Message-ID: <4946BEDE.2000709@cogeco.ca> > > I would also try disabling polling. Is you scheduler ULE or BSD? For > an 8 core box, it should be ULE > > ---Mike Hi Mike, Thanks I will try this now as I have not tried this yet. Here is the current custom kernel and it is using ULE: cpu HAMMER ident MYCOMPUTER makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options SMP # Symmetric MultiProcessor Kernel options IPFIREWALL # Ip Firewall options IPFIREWALL_VERBOSE # Verbose options IPFIREWALL_VERBOSE_LIMIT=5000 # limit verbosity options QUOTA # Disk Quota options DEVICE_POLLING device cpufreq device acpi device pci device fdc device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device arcmsr # Areca SATA II RAID device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device agp # support several AGP chipsets device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device device em # Intel PRO/1000 adapter Gigabit Ethernet Card device miibus # MII bus support device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device lagg # lagg interface for shared multi homed network connection device bpf # Berkeley packet filter device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device uplcom device ucom From victor at bsdes.net Mon Dec 15 23:19:22 2008 From: victor at bsdes.net (Victor Balada Diaz) Date: Mon Dec 15 23:19:30 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081215090207.GN1320@alf.bsdes.net> References: <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> <20081211095021.GL1320@alf.bsdes.net> <20081212121309.GM1320@alf.bsdes.net> <20081215090207.GN1320@alf.bsdes.net> Message-ID: <20081216071919.GR1320@alf.bsdes.net> On Mon, Dec 15, 2008 at 10:02:07AM +0100, Victor Balada Diaz wrote: > Stopped stress testing this morning. After all the weekend testing > seems the re(4) problems were fixed. No single interface up/down error. > netstat -i reports no errors and everything is fine. Thanks a lot! > > I'm going to deploy the patches on our production machines. > > I've been able to trigger interrupt storms with ATA code, though. After deploying it in various machines this night i've found in the logs messages like this one: re0: watchdog timeout (missed Tx interrupts) -- recovering I know you told me this is harmless, so this is just so you know it's happening. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From pyunyh at gmail.com Mon Dec 15 23:49:00 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Dec 15 23:49:08 2008 Subject: [ATA] and re(4) stability issues In-Reply-To: <20081216071919.GR1320@alf.bsdes.net> References: <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> <20081211095021.GL1320@alf.bsdes.net> <20081212121309.GM1320@alf.bsdes.net> <20081215090207.GN1320@alf.bsdes.net> <20081216071919.GR1320@alf.bsdes.net> Message-ID: <20081216074851.GD62771@cdnetworks.co.kr> On Tue, Dec 16, 2008 at 08:19:19AM +0100, Victor Balada Diaz wrote: > On Mon, Dec 15, 2008 at 10:02:07AM +0100, Victor Balada Diaz wrote: > > Stopped stress testing this morning. After all the weekend testing > > seems the re(4) problems were fixed. No single interface up/down error. > > netstat -i reports no errors and everything is fine. Thanks a lot! > > > > I'm going to deploy the patches on our production machines. > > > > I've been able to trigger interrupt storms with ATA code, though. > > After deploying it in various machines this night i've found in the > logs messages like this one: > > re0: watchdog timeout (missed Tx interrupts) -- recovering > > I know you told me this is harmless, so this is just so you Yes, it's not real watchdog timeout as long as re(4) still works correctly. > know it's happening. > Ok. I'll update re(4) when I find spare time. -- Regards, Pyun YongHyeon From danny at cs.huji.ac.il Mon Dec 15 23:52:23 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Dec 15 23:52:30 2008 Subject: bce reporting fantom input errors? Message-ID: Hi, After changing cables,switches,ports, I came to the conclusion that bce is reporting input errors that are not there, or creating them. I checked this with 3 different boxes, all Dell-2950/Broadcom NetXtreme II BCM5708 1000Base-T (B2), and one of them, while running Solaris, reported 0 errors after a week, and freebsd after a few minutes its count was > 100. The errors appear under 7.-PRERELEASE, but not under 7.0 Anybody else seeing this? danny From delphij at delphij.net Tue Dec 16 00:23:26 2008 From: delphij at delphij.net (Xin LI) Date: Tue Dec 16 00:23:33 2008 Subject: bce reporting fantom input errors? In-Reply-To: References: Message-ID: <4947656E.4050904@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny Braniss wrote: > Hi, > After changing cables,switches,ports, I came to the conclusion > that bce is reporting input errors that are not there, or creating them. > I checked this with 3 different boxes, all Dell-2950/Broadcom NetXtreme II > BCM5708 1000Base-T (B2), and one of them, while running Solaris, reported > 0 errors after a week, and freebsd after a few minutes its count was > 100. > The errors appear under 7.-PRERELEASE, but not under 7.0 > > Anybody else seeing this? Please apply this patch, it was committed as revision 186169 about 3 hours ago against -HEAD. I'll MFC it after 3 days. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklHZWsACgkQi+vbBBjt66CHxgCfQhUCadChP7mtyoOD4Wg4cP/k lAUAnj1S2vh/TtmnKZAaczJvx7V/XR4x =fdk+ -----END PGP SIGNATURE----- -------------- next part -------------- Index: if_bce.c =================================================================== --- if_bce.c (revision 186076) +++ if_bce.c (working copy) @@ -7408,7 +7408,6 @@ (u_long) sc->stat_IfInMBUFDiscards + (u_long) sc->stat_Dot3StatsAlignmentErrors + (u_long) sc->stat_Dot3StatsFCSErrors + - (u_long) sc->stat_IfInFramesL2FilterDiscards + (u_long) sc->stat_IfInRuleCheckerDiscards + (u_long) sc->stat_IfInFTQDiscards + (u_long) sc->com_no_buffers; From danny at cs.huji.ac.il Tue Dec 16 02:25:07 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Dec 16 02:25:22 2008 Subject: bce reporting fantom input errors? In-Reply-To: <4947656E.4050904@delphij.net> References: <4947656E.4050904@delphij.net> Message-ID: > This is a multi-part message in MIME format. > --------------070205030901020808000803 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Danny Braniss wrote: > > Hi, > > After changing cables,switches,ports, I came to the conclusion > > that bce is reporting input errors that are not there, or creating them. > > I checked this with 3 different boxes, all Dell-2950/Broadcom NetXtreme II > > BCM5708 1000Base-T (B2), and one of them, while running Solaris, reported > > 0 errors after a week, and freebsd after a few minutes its count was > 100. > > The errors appear under 7.-PRERELEASE, but not under 7.0 > > > > Anybody else seeing this? > > Please apply this patch, it was committed as revision 186169 about 3 > hours ago against -HEAD. I'll MFC it after 3 days. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAklHZWsACgkQi+vbBBjt66CHxgCfQhUCadChP7mtyoOD4Wg4cP/k > lAUAnj1S2vh/TtmnKZAaczJvx7V/XR4x > =fdk+ > -----END PGP SIGNATURE----- > > --------------070205030901020808000803 > Content-Type: text/plain; > name="bce-noL2Filter.diff" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="bce-noL2Filter.diff" > > Index: if_bce.c > =================================================================== > --- if_bce.c (revision 186076) > +++ if_bce.c (working copy) > @@ -7408,7 +7408,6 @@ > (u_long) sc->stat_IfInMBUFDiscards + > (u_long) sc->stat_Dot3StatsAlignmentErrors + > (u_long) sc->stat_Dot3StatsFCSErrors + > - (u_long) sc->stat_IfInFramesL2FilterDiscards + > (u_long) sc->stat_IfInRuleCheckerDiscards + > (u_long) sc->stat_IfInFTQDiscards + > (u_long) sc->com_no_buffers; > > --------------070205030901020808000803-- thanks! so actually it was counting IfInFramesL2FilterDiscards. btw, it worked, it's now 0 input errors. danny From mike at sentex.net Tue Dec 16 07:56:14 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 16 07:56:21 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <4946DA2F.7090508@cogeco.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> <4946BDB1.8060208@cogeco.ca> <200812152035.mBFKZkj4084689@lava.sentex.ca> <4946DA2F.7090508@cogeco.ca> Message-ID: <200812161556.mBGFuB7n089368@lava.sentex.ca> At 05:29 PM 12/15/2008, Paul MacKenzie wrote: >The next thing I am doing is going to be removing the QUOTA feature >to see if this has any bearing >on this problem. It does not appear to be even writing at a heavy >load as you can see (almost >nothing) but the processes are mostly in UFS when it spirals out of control. Whats strange is that the output from gstat shows the disks hardly active at all.... Yet why is the syncer at 100% ? Do you have write caching disabled on the array ? What does the raw throughput look like to the disks ? e.g. if you try a simple dd if=/dev/zero of=/var/tmp bs=1024k count=1000 ? >I moved the processing of amavisd-new into a memory drive to at >least take that off the IO and this >seems to have helped a bit. There is not a lot of mail going through >the system but every little bit >helps. I suspect this is one other reason that is bringing the >problem to the forefront as >amavisd-new can use the disks a bit to process each e-mail. Is the high load average simply a function of processes blocking on network io ? On our av/spam scanners for example show a high load avg because there are many processes waiting on network io to complete (e.g. talking to RBL lists, waiting for DCC servers to complete etc) Also, is it really related to the arcmsr driver ? i.e. if you did the same tasks on a single IDE drive, is the performance profile going to be the same ? ---Mike From danny at cs.huji.ac.il Tue Dec 16 08:22:52 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Dec 16 08:23:00 2008 Subject: more zfs/nfs panics Message-ID: Hi, I'm trying to tar a rather big directory via nfs (some 800gb), it has many subdirectories, some of them with many files (close to 10^6 :-) just before the server panics, the tar (on the client) starts complaining about lost files, or permition denied, but not in the pathological directories. panic: kmem_malloc(-1661382656): kmem_map too small: 645009408 total allocated cpuid = 3 KDB: enter: panic [thread pid 881 tid 100112 ] Stopped at kdb_enter_why+0x3d: movq $0,0x5ef3e8(%rip) db> tr Tracing pid 881 tid 100112 td 0xffffff0004ba2000 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x17b kmem_malloc() at kmem_malloc+0x565 uma_large_malloc() at uma_large_malloc+0x4a malloc() at malloc+0xd7 nfsrv_readdir() at nfsrv_readdir+0x4e1 nfssvc() at nfssvc+0x400 syscall() at syscall+0x1bb Xfast_syscall() at Xfast_syscall+0xab --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x8006885cc, rsp = 0x7fffffffea28, rbp = 0 --- I have increased vm.kmem_size_max="1024M" vm.kmem_size="1024M" vfs.zfs.arc_max="800M" it just seems to delay the panic though, it smells like some memory leak ... the host is running amd64 quad core, 7.1-prerelease and 8GB. danny From ivoras at freebsd.org Tue Dec 16 10:21:46 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Dec 16 10:22:01 2008 Subject: more zfs/nfs panics In-Reply-To: References: Message-ID: Danny Braniss wrote: > Hi, > I'm trying to tar a rather big directory via nfs (some 800gb), it > has many subdirectories, some of them with many files (close to 10^6 :-) > > just before the server panics, the tar (on the client) starts complaining > about lost > files, or permition denied, but not in the pathological directories. > panic: kmem_malloc(-1661382656): kmem_map too small: 645009408 total allocated > cpuid = 3 > KDB: enter: panic > [thread pid 881 tid 100112 ] > Stopped at kdb_enter_why+0x3d: movq $0,0x5ef3e8(%rip) > db> tr > Tracing pid 881 tid 100112 td 0xffffff0004ba2000 > kdb_enter_why() at kdb_enter_why+0x3d > panic() at panic+0x17b > kmem_malloc() at kmem_malloc+0x565 > uma_large_malloc() at uma_large_malloc+0x4a > malloc() at malloc+0xd7 > nfsrv_readdir() at nfsrv_readdir+0x4e1 > nfssvc() at nfssvc+0x400 > syscall() at syscall+0x1bb > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x8006885cc, rsp = > 0x7fffffffea28, rbp = 0 --- > > I have increased > vm.kmem_size_max="1024M" > vm.kmem_size="1024M" > vfs.zfs.arc_max="800M" > it just seems to delay the panic though, it smells like some memory leak ... Well, the canonical fix seems be to DECREASE vfs.zfs.arc_max to something like 100M and keep decreasing until it works. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081216/5054df09/signature.pgp From m4gicite at gmail.com Tue Dec 16 14:23:04 2008 From: m4gicite at gmail.com (Ryan) Date: Tue Dec 16 14:23:33 2008 Subject: Install issues with 7.x Message-ID: Ok, message didn't send entire post history, this should be it. Hopefully it's readable enough. Hello, I purchased a new Clevo M860TU on the account that it ran linux very well and was hoping it would fair the same on FreeBSD. Not so much, little help? I posted this in mobile originally but though stable would be a better choice. Don't know if it is more appropriate here or ACPI. I'm giving you as much information as I know how to get. as I cannot get sysinstall to load I am having to type all these dmesg. The boot process is hanging. This is all with 7.x, I can give 6.x if needed. Hardware: Intel P9500 4gb DDR3-1066 Nvidia 9800M GT Atheros AR5006e FreeBSD 7.1-BETA2 These snippets of dmesg happen around the end where it hangs. 1. Default ... cpu0: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a02d40 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU0._OSC] (Node 0xc68556e0), AE_AML_INTERNAL est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a0e300 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 0xc685560), AE_AML_INTERNAL est1: on cpu1 p4tcc1: on cpu1 ... cpu0: Cx states changed cpu1: Cx states changed unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Then just stalls 2. No ACPI ... unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Then just stalls 3. Safe Mode I can only tell you a little because console is spammed. It is the same as no ACPI, but with an interrupt storm. ... unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config When it gets to the unknowns, this is spammed. interrupt storm detected on "irq10:"; throttling interrupt source Other than the interrupt storm spam, it is halted like the others. 4. Single User Mode Same as 1, Default 5. Verbose All I can tell you is what is spammed at the end. acpi: bad write to port 0x080 (32), val hex Where hex is ever increasing and loops when it hits 0xff01. I can also see run_interrupt_driven_hooks message in all the spam. Using some googling if you add the sysctl before boot debug.acpi.block_bad_io=1 it might be of some help. This just leads to a never ending loop of acpi errors - the scroll very fast and difficult to record might I add! ... acpi: bad write to port 0x080 (32), val hex ACPI Exception (evregion-0529): AE_BAD_PARAMETER, Returned by handler for [SystemIO] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\P8XH] (Node 0xc6850a60), AE_BAD_PARAMETER ACPI Error (psparse-0626): Method parse/execution failed [\_GPE._L01] [20070320] ACPI Exception (evgpe-0687): AE_BAD_PARAMETER, while evauating GPE method [_L01] [20070320] --repeat-- ... FreeBSD 7.0-REL 7.0 is a little different than 7.1. Messages are somewhat the same but they happen near the beginning of dmesg instead of around the end. The run_interrupt_driven_hooks issue is nonexistant as well, but it still hangs. I'm guessing that's a debug tool more than an error. 1. Default ... cpu0: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6862580 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU0._OSC] (Node 0xc682d580), AE_AML_INTERNAL est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6861100 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 0xc682d4a0), AE_AML_INTERNAL est1: on cpu1 p4tcc1: on cpu1 ... cpu0: Cx states changed cpu1: Cx states changed unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install Hangs. 2. No ACPI .. unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ .. Hangs. 3. Safe Mode Same interrupt storm as 7.1-BETA2. ... interrupt storm detected on "irq10:"; throttling interrupt source --repeat-- 4. Single User Mode Same as 1. Default. 5. Verbose Hang like normal, cannot see the ACPI errors since they fly off the scroll lock buffer. ... cpu0: Cx states changed cpu1: Cx states changed ... unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ ... Thanks again. On Wed, 29 Oct 2008, Ryan wrote: Hello, I purchased a new Clevo M860TU on the account that it ran linux very well and was hoping it would fair the same on FreeBSD. Not so much, little help? I posted this in mobile originally but though stable would be a better choice. Don't know if it is more appropriate here or ACPI. I'm giving you as much information as I know how to get. as I cannot get sysinstall to load I am having to type all these dmesg. The boot process is hanging. This is all with 7.x, I can give 6.x if needed. xpt_config is the CAM configuration wait, so basically the system is waiting for a storage device to report back on whether it could be used as a root file system. I recently saw a similar report of problems involving a firewire controller on an nvidia motherboard following an upgrade to 7.x, and I wonder if you might try the following: see if 6.4 will install, and if so, install it. Then cvsup 7.x, and do a buildworld but not an installworld. This will let you build and experiment with 7.x kernels from a known-working environment. Make sure to keep a working 6.x kernel around -- I suggest something like "cp -r /boot/kernel /boot/kernel.good" before starting so you can always fall back to a good kernel. Now try building a 7.x kernel without USB or firewire support, and booting that? Also, it's worth checking there are no BIOS upgrades available for the motherboard... Robert N M Watson Computer Laboratory University of Cambridge Thanks for your interest Robert, unfortunately it was a no-go. I went ahead and tested 6.4RC1 and 6.3. Now all I am getting are ACPI errors which I would think I could get the installer going by disabling ACPI. And yes, I'm running on the latest - and only - bios revision for the laptop. The following were done under default boot option. No ACPI did not generate any error messages and hung, single user mode acted the same as default, and safe mode created an interrupt storm like 7.x did. 6.4-RC1 ... acpi_timer0: <24-bit timer at 3.579545 MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62, 0x66 on acpi0 cpu0: on acpi0 ACPI-0328: *** Error: No pointer back to NS node in buffer obj 0xc85c87c0 ACPI-1304: *** Error: Method execution failed [\_PR_.CPU0._OSC] (Node 0xc84e2580), AE_AML_INTERNAL acpi_throttle0: on cpu0 ... then this gets spammed 6 times at the end ACPI-0438: *** Error: Looking up [\_PR_.CPU0._PPC] in name space, AE_NOT_FOUND SearchNode 0xc84cdcc0 StartNode 0xc84cdcc0 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\_SB_.AC__.ADJP] (Node 0xc84cdcc0), AE_NOT_FOUND ACPI-1304: *** Error: Method execution failed [\_SB.AC__._PSR] (Node 0xc84cdd00), AE_NOT_FOUND 6.3-REL 6.3 gives the same errors but with different node addresses. ... acpi_timer0: <24-bit timer at 3.579545 MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62, 0x66 on acpi0 cpu0: on acpi0 ACPI-0328: *** Error: No pointer back to NS node in buffer obj 0xc85c94c0 ACPI-1304: *** Error: Method execution failed [\_PR_.CPU0._OSC] (Node 0xc84e3780), AE_AML_INTERNAL acpi_throttle0: on cpu0 ... spammed again 6 times at the end ACPI-0438: *** Error: Looking up [\_PR_.CPU0._PPC] in name space, AE_NOT_FOUND SearchNode 0xc84cdd20 StartNode 0xc84cdd20 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\_SB_.AC__.ADJP] (Node 0xc84cdd20), AE_NOT_FOUND ACPI-1304: *** Error: Method execution failed [\_SB.AC__._PSR] (Node 0xc84e3780), AE_NOT_FOUND Help at all? Ryan skrev: - Show quoted text - Hello, I purchased a new Clevo M860TU on the account that it ran linux very well and was hoping it would fair the same on FreeBSD. Not so much, little help? I posted this in mobile originally but though stable would be a better choice. Don't know if it is more appropriate here or ACPI. I'm giving you as much information as I know how to get. as I cannot get sysinstall to load I am having to type all these dmesg. The boot process is hanging. This is all with 7.x, I can give 6.x if needed. Hardware: Intel P9500 4gb DDR3-1066 Nvidia 9800M GT Atheros AR5006e FreeBSD 7.1-BETA2 These snippets of dmesg happen around the end where it hangs. 1. Default ... cpu0: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a02d40 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU0._OSC] (Node 0xc68556e0), AE_AML_INTERNAL est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a0e300 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 0xc685560), AE_AML_INTERNAL est1: on cpu1 p4tcc1: on cpu1 ... cpu0: Cx states changed cpu1: Cx states changed unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Disabling firewire completely in BIOS might at least get the machine booting. You should try that if you haven't already. I've seen this problem on at least two different systems... -- Joel Sadly with the quality of BIOS recently, that is not an option. Not much to offer. Attached is a picture of what I have to change. Other and XP are the same, Vista unlocks AHCI. Another way of accomplishing disabling firewire is to remake the install CD with a different kernel and not quite sure how to do that. Ryan skrev: Sadly with the quality of BIOS recently, that is not an option. Not much to offer. Attached is a picture of what I have to change. Other and XP are the same, Vista unlocks AHCI. Another way of accomplishing disabling firewire is to remake the install CD with a different kernel and not quite sure how to do that. Take a look at the release(7) manpage for information about building your own customized release CD. -- Joel Finally had time to understand some how release works and made some new cds. Some new updates to the situation since as I am still having issues. I was not able to figure out how to make release with a custom kernel, would always fail that step so I had to stick with GENERIC. To simulate taking out firewire support I just deleted the corresponding kernel modules in /boot/kernel and remade the iso. Stable as of 12-07-2008 is giving the same feedback as 7.1-B2 but actually gives a panic screen. panic: run_interrupt_driven_config_hooks: waited too long cpuid = 0 KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> There has been a bios update recently and have applied it, but there has been no change in any of the tests by a quick glance. If it makes a difference the cds I create with cdrecord generate the added errors acd0: FAILURE - READ BIG timed out. I don't think that has anything to do with it, just saying it for full disclosure. Disregard if irrelevant. That error applies to only the stable builds I made. From bsdlist at cogeco.ca Tue Dec 16 15:03:31 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Tue Dec 16 15:03:39 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <200812161556.mBGFuB7n089368@lava.sentex.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> <4946BDB1.8060208@cogeco.ca> <200812152035.mBFKZkj4084689@lava.sentex.ca> <4946DA2F.7090508@cogeco.ca> <200812161556.mBGFuB7n089368@lava.sentex.ca> Message-ID: <4947E03F.8070408@cogeco.ca> >> The next thing I am doing is going to be removing the QUOTA feature >> to see if this has any bearing >> on this problem. It does not appear to be even writing at a heavy >> load as you can see (almost >> nothing) but the processes are mostly in UFS when it spirals out of >> control. > > > Whats strange is that the output from gstat shows the disks hardly > active at all.... Yet why is the syncer at 100% ? Do you have write > caching disabled on the array ? What does the raw throughput look > like to the disks ? e.g. if you try a simple dd if=/dev/zero > of=/var/tmp bs=1024k count=1000 ? > >> I moved the processing of amavisd-new into a memory drive to at least >> take that off the IO and this >> seems to have helped a bit. There is not a lot of mail going through >> the system but every little bit >> helps. I suspect this is one other reason that is bringing the >> problem to the forefront as >> amavisd-new can use the disks a bit to process each e-mail. > > > Is the high load average simply a function of processes blocking on > network io ? On our av/spam scanners for example show a high load avg > because there are many processes waiting on network io to complete > (e.g. talking to RBL lists, waiting for DCC servers to complete etc) > > Also, is it really related to the arcmsr driver ? i.e. if you did the > same tasks on a single IDE drive, is the performance profile going to > be the same ? > > ---Mike > Hi Mike, Well I tried to remove both the USB com ports drivers and the QUOTA out of the kernel last night and this has not solved it but it seems a bit more stable today. The HTTP only had a problem two times last night. I am not sure if it is specifically related to the arcmsr driver but unfortunately I am unable to try a single IDE setup at the moment. If I can get to the bottom of why it is locking then it might point us in the right direction.I was told that Jan downgraded to 6.4 as she could never resolve her issue and worked on it for a very long time. Write caching is enabled on the array which was the first thing I checked and I have the battery backup installed and I confirm it shows up in the areca-cli as 100% charged. Do you think it may be hardware related even though there are no errors at all? I have checked the event log in the S50000PAL which is very sensitive to errors I have found in the past as well as the event log of the areca-cli. Both are error free. With regards to the e-mail scanning waiting for RBL completion there is only usually one e-mail per minute approximately to give you an idea of the load with regards to the e-mail so this is not really a reliable test and I don't see how this is an overall contributing factor as there seem to be many ways to bring the locking forward including running a dump being one of them in my experience. What I have found is the more I take off the load of the system writing seems to help a bit so I have been doing everything I can to help with this until I can find a workable solution. I have recompiled all the ports a few times over the past month in hopes that something might get fixed if it was a port issue and all ports are as up-to-date as possible using portupgrade and tracking the port tree. The primary problem is what you said above the gstat shows very little activity but the system seems to be "stuck". The syncer is not always at 100% as it comes and goes I grabbed that at one time when watching it but it did show how "little" activity there was from the reports. Here is the output of dd on the WORKING server: dd if=/dev/zero of=/usr/test bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 17.874501 secs (58663232 bytes/sec) Here is the output of dd on the one not working right but NOT "locked" right now. I need to wait for it to "lock" again before I can test this again. dd if=/dev/zero of=/usr/test bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 34.270080 secs (30597419 bytes/sec) The numbers are pretty reasonable albeit half on one compare to the other. I did notice on the non-working server the system numbers were always much higher when I ran the dd. This could be a coincidence but the syncer was not seen in the list of the working server but it was on the list on the one with the problem when running both with top -IS which the dd was running. I also noticed the system number s are always much higher on the one with the problem. I am waiting for the system to lock again to try and see what it shows when it is locked. I suppose I will work on getting 7.0 running (downgrade) next to see if I have the same problem on this version as another clue to the problem. Thanks again for your help so far. Paul From bsdlist at cogeco.ca Tue Dec 16 15:36:52 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Tue Dec 16 15:37:00 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <200812152010.mBFKAlZf084580@lava.sentex.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> Message-ID: <4946BDB1.8060208@cogeco.ca> > What does top -S show ? Most of the load is in system. Does the > machine in question have a rather large master.passwd file by chance ? > (http://www.freebsd.org/cgi/query-pr.cgi?pr=75855) > ---Mike > Thanks for your quick reply: master.passwd is only 9467 (with a ls-l) TOP -ISM at times shows syncer at the top but this ranges and is not always near the top. last pid: 55084; load averages: 17.74, 10.08, 5.58 up 0+10:19:24 15:05:23 290 processes: 50 running, 218 sleeping, 14 waiting, 8 lock CPU: 15.4% user, 0.0% nice, 68.3% system, 3.0% interrupt, 13.2% idle Mem: 795M Active, 3279M Inact, 492M Wired, 6116K Cache, 214M Buf, 11G Free Swap: 8192M Total, 8192M Free PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 54 root 2 0 0 7 0 7 100.00% syncer Here is a top with it not fully locked but high system usage. last pid: 55468; load averages: 9.93, 11.31, 8.99 up 0+10:32:58 15:18:57 259 processes: 19 running, 215 sleeping, 14 waiting, 11 lock CPU: 19.1% user, 0.0% nice, 58.2% system, 1.9% interrupt, 20.8% idle Mem: 635M Active, 3258M Inact, 481M Wired, 6856K Cache, 214M Buf, 11G Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 18 root 1 171 ki31 0K 16K RUN 0 439:32 31.15% idle: cpu0 55422 www 1 102 0 193M 59632K RUN 5 0:26 30.96% httpd 12 root 1 171 ki31 0K 16K RUN 6 522:14 28.37% idle: cpu6 54 root 1 20 - 0K 16K syncer 2 81:19 28.37% syncer 15 root 1 171 ki31 0K 16K RUN 3 465:15 26.56% idle: cpu3 55411 www 1 -4 0 157M 33704K *vnode 1 0:21 26.17% httpd 55388 www 1 -4 0 160M 35940K *vnode 1 0:14 26.17% httpd 13 root 1 171 ki31 0K 16K RUN 5 509:35 25.98% idle: cpu5 11 root 1 171 ki31 0K 16K RUN 7 525:53 25.88% idle: cpu7 14 root 1 171 ki31 0K 16K RUN 4 491:32 25.29% idle: cpu4 55453 www 1 101 0 157M 33608K CPU7 7 0:08 24.76% httpd 55365 www 1 -4 0 157M 33408K ufs 3 0:23 24.56% httpd 55440 www 1 69 0 154M 31180K CPU2 7 0:09 24.37% httpd 55412 www 1 -4 0 153M 30156K *vnode 3 0:07 23.97% httpd 16 root 1 171 ki31 0K 16K CPU2 2 444:38 23.88% idle: cpu2 55376 www 1 -4 0 158M 34776K *vnode 0 0:26 23.88% httpd 55459 www 1 -4 0 145M 23920K *vnode 1 0:07 23.49% httpd 55467 www 1 70 0 154M 31056K *vnode 7 0:09 22.66% httpd 17 root 1 171 ki31 0K 16K CPU1 1 443:27 20.90% idle: cpu1 55374 www 1 -4 0 146M 25312K *vnode 7 0:09 13.38% httpd 55418 www 1 -4 0 145M 24192K ufs 0 0:18 12.89% httpd 55400 www 1 58 0 146M 25460K select 5 0:20 12.79% httpd 55443 www 1 -4 0 148M 25788K *vnode 1 0:03 12.50% httpd 55410 www 1 -4 0 147M 25700K *vnode 7 0:05 12.26% httpd 55438 www 1 -4 0 145M 24148K RUN 4 0:08 11.96% httpd 21 root 1 -44 - 0K 16K WAIT 0 34:45 11.77% swi1: net 55451 www 1 -4 0 144M 22704K *vnode 7 0:02 10.99% httpd 55447 www 1 60 0 145M 24008K select 2 0:07 10.50% httpd 55406 www 1 53 0 146M 25324K select 2 0:19 9.77% httpd 55433 www 1 49 0 146M 24912K select 2 0:11 8.06% httpd 55448 www 1 52 0 144M 22972K RUN 6 0:03 8.06% httpd 55383 www 1 45 0 145M 24284K select 2 0:12 7.96% httpd 55446 www 1 44 0 146M 24988K select 3 0:09 7.96% httpd 55430 www 1 4 0 145M 24136K kqread 0 0:03 6.69% httpd 55432 www 1 20 0 146M 24324K lockf 3 0:04 6.05% httpd 55464 www 1 -4 0 145M 23464K RUN 0 0:02 5.66% httpd 55424 www 1 45 0 146M 24876K select 6 0:08 3.66% httpd 55442 www 1 47 0 145M 23852K select 3 0:03 3.56% httpd 55373 www 1 48 0 146M 25364K select 5 0:07 3.17% httpd 55375 www 1 46 0 146M 25420K select 2 0:15 3.08% httpd 19 root 1 -32 - 0K 16K *Giant 2 9:02 2.98% swi4: clock sio 48518 wusage 1 46 0 10424K 2632K select 4 2:50 2.78% wusage 1490 mysql 97 4 -5 402M 184M sbwait 4 0:29 2.78% mysqld 55372 www 1 47 0 144M 22136K CPU6 0 0:01 2.59% httpd 55437 root 1 -32 0 9136K 2940K CPU4 4 0:01 2.59% top 55387 www 1 45 0 144M 22196K CPU5 1 0:02 2.39% httpd 55468 www 1 20 0 144M 21904K lockf 4 0:00 1.56% httpd 55441 www 1 45 0 144M 22088K select 5 0:01 1.46% httpd 51563 root 1 4 0 11848K 5540K connec 5 0:09 1.37% sendmail 55458 www 1 45 0 144M 22140K select 6 0:01 1.17% httpd 55336 root 1 51 0 144M 21888K CPU0 0 0:05 1.07% httpd 55455 www 1 45 0 144M 21992K select 0 0:01 1.07% httpd 55425 www 1 20 0 146M 25304K lockf 3 0:07 0.78% httpd 55415 www 1 45 0 144M 22192K select 7 0:01 0.68% httpd 55439 www 1 44 0 144M 22308K select 1 0:01 0.49% httpd 51561 root 1 45 0 11848K 5400K select 0 0:13 0.29% sendmail 54666 root 1 4 0 10824K 4496K connec 3 0:04 0.20% sendmail 55469 root 1 51 0 144M 21888K CPU3 3 0:00 0.00% httpd From jcw at highperformance.net Tue Dec 16 20:22:31 2008 From: jcw at highperformance.net (Jason C. Wells) Date: Tue Dec 16 20:22:37 2008 Subject: Heimdal Breakage Message-ID: <49487A89.80608@highperformance.net> After installing 6.4-RELEASE on my secondary KDC I decided to test the secondary KDC. When trying kinit I get this error: jcw@w17 ~ $ kinit jcw@STRADAMOTORSPORTS.COM's Password: kinit: krb5_get_init_creds: Key size is incompatible with encryption type One post on the net says that Heimdal changed the key format to add some padding or somesuch. I haven't gone about fixing the problem yet so maybe that post is not applicable to FreeBSD. Just the same I thought I would let folks know that their key databases are probably not forward compatible with 6.4-RELEASE. This would be a pretty big deal for some users. It would be nice to see this in UPDATING. Thanks, Jason From crapsh at monkeybrains.net Tue Dec 16 23:24:20 2008 From: crapsh at monkeybrains.net (Rudy) Date: Tue Dec 16 23:24:27 2008 Subject: more zfs/nfs panics In-Reply-To: References: Message-ID: <4948A91E.3050200@monkeybrains.net> >> it just seems to delay the panic though, it smells like some memory leak ... >> > > Well, the canonical fix seems be to DECREASE vfs.zfs.arc_max to > something like 100M and keep decreasing until it works. > More info here: http://wiki.freebsd.org/ZFSQuickStartGuide Once you tune, your problems will go away. The default install should not need tuning (so people stop posting this panic problem)... will that be fixed in the next stable release? Rudy From nawfal at gmail.com Wed Dec 17 22:00:43 2008 From: nawfal at gmail.com (Nawfal bin Mohmad Rouyan) Date: Wed Dec 17 22:00:50 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <400809c165ecedf8a0b7bc6b569e1289.squirrel@wettoast.dyndns.org> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> <493D9BC6.8050902@delphij.net> <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> <4944D894.6070306@delphij.net> <400809c165ecedf8a0b7bc6b569e1289.squirrel@wettoast.dyndns.org> Message-ID: <1229578180.6319.21.camel@nawfal-desktop> On Mon, 2008-12-15 at 11:47 -0500, Mike Jakubik wrote: > On Sun, December 14, 2008 4:57 am, Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Mike Jakubik wrote: > >> On Mon, December 8, 2008 5:22 pm, Mike Jakubik wrote: > >>> On Mon, December 8, 2008 5:12 pm, Xin LI wrote: > >>> > >>>> Which version are you currently using? My previous commit only fixes > >>>> the excessive interrupt issue, I think this could be a different > >>>> problem, I'm taking a look at the code to see if I can have something > >>>> for you. > >>> I was running on the version just prior to the latest interrupt commit. > >>> I > >>> have now updated to the one with the interrupt fix. Will let you know > >>> if > >>> things change. > >>> > >>> Thank You. > >> > >> The interrupt rate has decreased significantly, however i am still > >> having > >> having problem with applications that hold stateful connections. The rx > >> errors are also still showing, i suspect this is related to the problem. > >> How can i roll back this driver to the last known good version? > > > > Hi, Mike, > > > > I think they are different problems. Could you, please, give me > > feedback about whether: > > > > - The old driver does not trigger the problem? > > > > - The patched driver restore all the old driver behavior? > > - Old driver. > > I have been running the system for 4 days now with this driver. My > application has not stopped accepting connections, irq rate is low, and > there are no rx/tx errors reported. Everything looks good. > > - Patched driver. > > Your initial import plus the IRQ fix still shows rx errors, and my > application had stopped accepting connections. I have not tried the patch > in your last email, and im not sure when i will be able to to as these > systems are in production. Perhaps someone else could test it? As soon as > i get a chance i will let you know how it goes. > > Thanks for the work on this. I have been using a Dell machine with 2 bce interfaces as a bridge between my LAN and Firewall to shape the traffic. Since after the update, the machine can only run for a few minutes and after that no more connection can go through. Ping from LAN to Internet is OK but when I telnet say to www.yahoo.com at port 80 and issue "GET / HTTP/1.0" I can see the data of different application including the HTML text. For example, I can see uTorrent packets with binaries and also the HTML page being cut short. It's as if, I'm seeing packets jumbled together from different application. I'm using PF to shape the traffic. If I reboot the server, it will panic and I have about 3 different vmcores in /var/crash and not sure what to do with it :( . I've tested the patch to remove stat_IfInFramesL2FilterDiscards but the problem still occurs. As for now, I'm not using the server to shape the traffic because I suspect the driver isn't reliable. I'm going to revert back to the previous driver and hopes its going to work. Sorry if there is not much detail since I'm not sure what to provide. Just tell me what to provide and I'd be happy to do so. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081218/33878435/attachment.pgp From paul at elehost.com Wed Dec 17 22:52:57 2008 From: paul at elehost.com (Paul MacKenzie) Date: Wed Dec 17 22:53:12 2008 Subject: freebsd-stable@freebsd.org Message-ID: <4949673B.2070701@elehost.com> > > [ns8]# vmstat -i > > interrupt total rate > > irq4: sio0 57065 0 > > irq17: em1 3989494045 554 > > irq18: arcmsr0 558098657 77 > > cpu0: timer 14381393929 2000 > > irq256: em0 22763077 3 > > cpu1: timer 14381384902 1999 > > Total 33333191675 4635 > > [ns8]# > > > > arcmsr0: >> > > mem 0xe8600000-0xe8600fff,0xe8000000-0xe83fffff irq 18 at device >> > > 14.0 on pci2 > > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 > > arcmsr0: [ITHREAD] > > ..... > > Waiting 5 seconds for SCSI devices to settle > > (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > > da0 at arcmsr0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-5 device > > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > > da0: 305175MB (624999424 512 byte sectors: 255H 63S/T 38904C) > > SMP: AP CPU #1 Launched! > Hi and thanks for your reply. I do not believe the interrupts are the problem at the moment as the stats. Here is a vmstat when the system usage is spiking and just before http needs to be killed to get going again most recently. vmstat -i interrupt total rate irq1: atkbd0 2 0 irq4: sio0 22880 0 irq14: ata0 58 0 irq22: uhci1 uhci3 18068 0 irq23: uhci0 uhci+ 1 0 irq26: arcmsr0 496094 14 cpu0: timer 61769334 1791 irq256: em0 1 0 irq258: em2 48505 1 irq259: em3 1 0 cpu1: timer 61762043 1791 cpu3: timer 61299367 1777 cpu2: timer 61299179 1777 cpu4: timer 61326132 1778 cpu7: timer 60845245 1764 cpu5: timer 61326513 1778 cpu6: timer 60845018 1764 Total 491058441 14243 There are no errors en the event console for the areca-cli. ARC-1130-VOL#00 Main Raid Array Raid1+0 1000.0GB 00/00/00 Normal Main Raid Array 4 2000.0GB 0.0GB 1234 Normal Main Processor : 500MHz CPU ICache Size : 32KB CPU DCache Size : 32KB CPU SCache Size : 0KB System Memory : 1024MB/333MHz/ECC Firmware Version : V1.44 2008-2-1 BOOT ROM Version : V1.44 2008-1-28 The buildworld taking a really long time was just an example of the problem I am seeing that is easy to quantify. If I run boxbackup, dump, clamscan or a few other IO intensive everything gets VERY slow even when reading files from the server. When the HTTP locks up (another issue that is seen and is connected to the same issue in my view) this is what it looks like. It is almost as if the http gets backed up from what I can tell and I need a plunger to clean out the blockage :) I have to kill it and then restart it to get things back to normal for a bit. last pid: 46013; load averages: 105.30, 67.67, 34.45 up 4+23:59:42 19:08:40 629 processes: 89 running, 540 sleeping CPU: 21.9% user, 0.0% nice, 74.5% system, 3.1% interrupt, 0.4% idle Mem: 1538M Active, 11G Inact, 898M Wired, 303M Cache, 214M Buf, 1346M Free Swap: 8192M Total, 1036K Used, 8191M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 46000 www 1 65 0 86728K 15008K RUN 1 0:01 12.06% httpd 45994 www 1 56 0 86728K 15008K CPU1 3 0:01 10.16% httpd 46002 www 1 -4 0 150M 20648K RUN 3 0:00 6.98% httpd 45195 www 1 68 0 121M 19748K RUN 1 0:29 6.88% httpd 45991 www 1 53 0 150M 21060K select 3 0:01 6.59% httpd 45997 www 1 -4 0 150M 20992K ufs 5 0:01 6.59% httpd 45950 www 1 57 0 153M 23388K RUN 2 0:01 6.49% httpd 45999 www 1 -4 0 150M 20640K ufs 6 0:00 5.96% httpd 45189 www 1 66 0 161M 29660K RUN 6 0:26 5.76% httpd 45974 www 1 -4 0 151M 21564K ufs 3 0:01 5.76% httpd 45984 www 1 -4 0 151M 21376K ufs 5 0:01 5.66% httpd 45998 www 1 -4 0 150M 20652K ufs 3 0:00 5.57% httpd 45780 www 1 -4 0 153M 23516K ufs 6 0:06 5.37% httpd 45972 www 1 -4 0 151M 21332K RUN 4 0:01 5.37% httpd 46001 www 1 20 0 150M 20568K lockf 4 0:00 5.37% httpd 45425 www 1 60 0 164M 31516K RUN 7 0:15 5.18% httpd 45995 www 1 63 0 150M 20820K RUN 2 0:00 5.18% httpd 45845 www 1 -4 0 151M 21692K ufs 6 0:02 4.98% httpd 45854 www 1 52 0 151M 22080K CPU6 0 0:02 4.88% httpd 45977 root 1 47 0 10160K 3260K CPU2 6 0:01 4.88% top 45509 www 1 56 0 155M 25028K RUN 0 0:14 4.79% httpd 45735 www 1 -4 0 158M 27096K RUN 3 0:07 4.79% httpd 45730 www 1 20 0 151M 21728K lockf 2 0:04 4.79% httpd 45847 www 1 -4 0 150M 21092K RUN 5 0:02 4.69% httpd 85338 root 1 46 0 150M 20560K select 7 5:03 4.59% httpd 45835 www 1 -4 0 150M 21100K ufs 0 0:02 4.59% httpd 45443 www 1 -4 0 151M 22220K ufs 6 0:12 4.49% httpd 45699 www 1 -4 0 157M 26528K RUN 0 0:07 4.39% httpd 45722 www 1 -4 0 152M 22908K RUN 0 0:05 4.39% httpd 45701 www 1 -4 0 152M 22268K RUN 2 0:07 4.30% httpd 45849 www 1 -4 0 151M 21748K ufs 6 0:02 4.30% httpd 46010 nagios 1 -4 0 7684K 1136K ufs 5 0:00 4.30% check_ping 45515 www 1 -4 0 160M 29048K ufs 5 0:13 4.20% httpd 45606 www 1 -4 0 152M 22420K ufs 0 0:09 4.20% httpd vfs.numvnodes: 355382 kern.maxvnodes: 400000 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 3239015 vfs.ufs.dirhash_maxmem: 10485760 vfs.ufs.dirhash_minsize: 2560 kern.ipc.nsfbufs: 0 kern.openfiles: 3395 kern.maxfiles: 12328 Results from netstat -m ------------------------ 1185/3360/4545 mbufs in use (current/cache/total) 1062/2856/3918/25600 mbuf clusters in use (current/cache/total/max) 1062/1556 mbuf+clusters out of packet secondary zone in use (current/cache) 10/1550/1560/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2460K/12752K/15212K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 46262 requests for I/O initiated by sendfile 0 calls to protocol drain routines Results from vmstat -m ------------------------ Type InUse MemUse HighUse Requests Size(s) cdev 22 6K - 22 256 acd_driver 1 2K - 1 2048 sigio 1 1K - 1626 64 filedesc 684 941K - 1199696 16,32,64,128,256,512,1024,2048,4096 kenv 68 11K - 70 16,32,64 kqueue 368 414K - 1740632 256,2048,4096 proc-args 52 4K - 5389885 16,32,64,128,256 ithread 99 19K - 99 32,128,256 acpisem 13 2K - 13 128 CAM queue 12 1K - 302 16,32,64,128,256 KTRACE 100 13K - 100 128 linker 45 4K - 71 16,32,64,128,512 lockf 314 38K - 16413112 64,128,256,512,1024,2048,4096 scsi_da 0 0K - 65 16 ip6ndp 7 1K - 7 64,128 ip6opt 1 1K - 50503 256 temp 66 222K - 6704801 16,32,64,128,256,512,1024,2048,4096 devbuf 16781 35476K - 108258 16,32,64,128,256,512,1024,2048,4096 CAM SIM 2 1K - 2 256 module 204 26K - 204 128 acpidev 78 5K - 78 64 mtx_pool 1 8K - 1 subproc 1111 1606K - 1045562 512,4096 proc 2 16K - 2 session 34 5K - 20772 128 pgrp 39 5K - 158890 128 cred 24950 6238K - 11839905 256 uidinfo 13 3K - 7337 64,2048 plimit 24 6K - 226179 256 CAM periph 7 2K - 45 16,32,64,128,256 sysctltmp 0 0K - 215050 16,32,64,128,256 sysctloid 4373 216K - 4373 16,32,64,128 sysctl 0 0K - 828292 16,32,64 umtx 1692 212K - 1692 128 p1003.1b 1 1K - 1 16 SWAP 2 1097K - 2 64 CAM XPT 51 24K - 19790153 32,64,128,256,1024 bus-sc 111 101K - 1879 16,32,64,128,256,512,1024,2048,4096 bus 804 77K - 5926 16,32,64,128,256,1024 devstat 10 21K - 10 32,4096 eventhandler 57 5K - 57 64,128 kobj 125 500K - 160 4096 kbdmux 6 9K - 6 16,256,512,2048,4096 rman 168 21K - 576 16,64,128 sbuf 0 0K - 840 16,32,64,128,256,512,1024,2048,4096 pci_link 16 2K - 16 16,128 stack 0 0K - 14 256 taskqueue 19 2K - 19 16,32,128 Unitno 16 1K - 22074 32,64 iov 0 0K - 12126863 16,64,128,256,512 ioctlops 0 0K - 388714 16,32,64,128,256,512,1024,2048 msg 4 30K - 4 2048,4096 sem 4 8K - 4 512,1024,2048,4096 shm 1 16K - 1 ttys 1170 169K - 80824 128,1024 ptys 5 2K - 5 256 accf 3 1K - 301 32,64 mbuf_tag 0 0K - 520852 32,128 pcb 47 158K - 1332310 16,32,128,1024,2048,4096 soname 187 23K - 10680643 16,32,128 biobuf 1 2K - 143707 2048 vfscache 1 1024K - 1 cl_savebuf 0 0K - 154293 64,128 vfs_hash 1 512K - 1 vnodes 2 1K - 3 32,256 vnodemarker 1 1K - 124142 512 mount 111 6K - 495 16,32,64,128,256,2048 acpi_perf 8 1K - 8 64 BPF 6 1K - 6 128 ether_multi 29 2K - 32 16,32,64 ifaddr 136 48K - 136 32,64,128,256,512,4096 ifnet 7 13K - 7 256,2048 clone 6 24K - 6 4096 arpcom 5 1K - 5 16 lo 1 1K - 1 32 acpica 3057 292K - 68659 16,32,64,128,256,512,1024 routetbl 303 86K - 1027 32,64,128 ,256,512 in_multi 4 1K - 4 64 IpFw/IpAcct 60 9K - 60 64,128,2048 sctp_iter 0 0K - 65 256 sctp_ifn 4 1K - 4 128 sctp_ifa 66 9K - 66 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 65 16 hostcache 1 36K - 1 entropy 1024 64K - 1024 64 syncache 1 100K - 1 in6_multi 16 1K - 16 32,64,128 audit_evclass 150 5K - 187 32 savedino 0 0K - 406078 256 newdirblk 0 0K - 5047 64 dirrem 18 2K - 2259617 64 mkdir 1 1K - 283528 64 diradd 183 12K - 3426340 64 freefile 55 4K - 1081462 64 freeblks 26 7K - 792864 256 freefrag 2 1K - 781740 64 allocindir 5 1K - 2842332 128 indirdep 4 1K - 116594 64 allocdirect 62 16K - 4832896 256 bmsafemap 12 2K - 271759 128 newblk 1 1K - 7675229 64,512 inodedep 270 580K - 2593883 256 pagedep 12 130K - 318828 128 ufs_dirhash 2848 1230K - 42435 16,32,64,128,256,512,1024,2048,4096 ufs_quota 1 512K - 1 ufs_mount 15 241K - 51 128,256,512,2048,4096 UMAHash 5 572K - 33 512,1024,2048,4096 USBHC 0 0K - 660 16 USBdev 22 10K - 682 16,128,512 USB 761 683K - 4079 16,32,64,128,256,1024 vm_pgdata 2 129K - 2 128 DEVFS1 115 58K - 115 512 DEVFS3 250 63K - 251 256 DEVFS2 115 2K - 115 16 DEVFS_RULE 36 17K - 36 64,512 DEVFS 30 1K - 31 16,128 io_apic 2 4K - 2 2048 pfs_nodes 20 5K - 20 256 memdesc 1 4K - 2 4096 msi 4 1K - 4 128 nexusdev 4 1K - 4 16 acpitask 0 0K - 9 64 GEOM 104 20K - 882 16,32,64,128,256,512,1024,2048 atkbddev 2 1K - 2 64 isadev 7 1K - 7 128 CAM dev queue 2 1K - 2 128 ata_generic 1 1K - 1 1024 ata_dma 1 1K - 1 256 Results from systat -v ----------------------- 1 users Load 143 90.86 47.13 Nov 21 19:10 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 1754100 25964 4719924 55728 1551492 count All 1916252 113912 9413004 269144 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 179 cow 16002 total 73 133 454 2 32k 816 2520 3 29k 726 504 zfod atkbd0 1 ozfod sio1 irq3 86.8%Sys 3.5%Intr 9.2%User 0.0%Nice 0.6%Idle %ozfod sio0 irq4 | | | | | | | | | | | daefr ata0 irq14 ===========================================++>>>>> 16 prcfr uhci1 uhci 314 dtbuf 90 totfr uhci0 uhci Namei Name-cache Dir-cache 400000 desvn react 2 arcmsr0 26 Calls hits % hits % 355344 numvn pdwak 2004 cpu0: time 76763 76730 100 24902 frevn pdpgs em0 irq256 intrn 1 em2 irq258 Disks da0 da1 pass0 pass1 pass2 934624 wire em3 irq259 KB/t 9.00 0.00 0.00 0.00 0.00 1697060 act 2000 cpu1: time tps 1 0 0 0 0 12038912 inact 1996 cpu2: time MB/s 0.01 0.00 0.00 0.00 0.00 308732 cache 2000 cpu3: time %busy 0 0 0 0 0 1244784 free 2001 cpu7: time 219632 buf 1999 cpu4: time 1999 cpu6: time 2000 cpu5: time Here is a "normal" sysstat -v to compare when there are no "visible" problems: 3 users Load 1.67 1.03 1.02 Nov 25 22:12 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 797576 31388 2318500 57324 4051340 count All 952256 114916 6781828 226696 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 556 cow 16001 total 1 6 474 5463 1602 3387 1 31k 1567 853 zfod atkbd0 1 ozfod sio1 irq3 8.4%Sys 4.0%Intr 2.8%User 0.0%Nice 84.8%Idle %ozfod sio0 irq4 | | | | | | | | | | | daefr ata0 irq14 ====++>> 602 prcfr uhci1 uhci 125 dtbuf 1443 totfr uhci0 uhci Namei Name-cache Dir-cache 400000 desvn react arcmsr0 26 Calls hits % hits % 328748 numvn pdwak 2026 cpu0: time 52734 52660 100 24705 frevn pdpgs em0 irq256 intrn 1 em2 irq258 Disks da0 da1 pass0 pass1 pass2 857028 wire em3 irq259 KB/t 0.00 0.00 0.00 0.00 0.00 750716 act 2026 cpu1: time tps 0 0 0 0 0 10564316 inact 1975 cpu2: time MB/s 0.00 0.00 0.00 0.00 0.00 303468 cache 1977 cpu3: time %busy 0 0 0 0 0 3748056 free 1999 cpu7: time 219632 buf 2000 cpu4: time 1997 cpu6: time 2000 cpu5: time ---------------------------------- Here are the results of vmstat -w 1 during the problem: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 da1 in sy cs us sy id 157 110 13 5544M 1111M 1141 0 0 0 1100 44 0 0 47 115 8744 7 14 79 146 34 98 5546M 1099M 4191 0 0 0 729 0 2 0 17 18583 102586 9 91 0 224 33 15 5548M 1091M 3825 0 0 0 664 0 0 0 7 14115 141707 10 90 0 165 103 11 5633M 1064M 12222 0 0 0 6745 0 2 0 42 41519 403437 14 86 0 214 73 4 5653M 1044M 4539 0 0 0 959 0 0 0 7 15698 94269 11 88 1 260 30 1 5664M 1034M 8457 0 0 0 2171 0 0 0 14 36978 248202 12 87 0 57 182 45 5667M 1029M 4761 0 0 0 2535 0 0 0 6 21004 133617 10 90 0 55 24 16 2152M 2454M 7993 0 0 0 3135 0 0 0 13 20263 173347 13 81 7 20 15 2 1972M 2537M 93820 0 0 0 465955 0 10 0 588 99274 716238 23 76 1 13 11 0 1877M 2581M 7820 0 0 0 31044 0 6 0 38 7859 76120 16 83 1 9 12 1 1816M 2599M 6889 0 0 0 14550 0 20 0 79 359198 21333 14 79 7 11 13 0 1797M 2613M 6542 0 0 0 8416 0 3 0 17 606119 15341 18 61 21 1 9 1 1740M 2636M 1744 0 0 0 6267 0 2 0 14 11617 15322 8 63 29 2 3 0 1694M 2657M 3417 0 0 0 8669 0 15 0 52 50341 12045 6 29 65 Here is another view of top at a later date with the same problem happening focusing on IO setting in Top: -------------------------------------------------------------- last pid: 17984; load averages: 39.26, 37.68, 24.75 up 8+09:25:55 04:34:53 539 processes: 59 running, 480 sleeping CPU: 9.8% user, 0.5% nice, 87.0% system, 2.3% interrupt, 0.4% idle Mem: 1146M Active, 9663M Inact, 875M Wired, 582M Cache, 214M Buf, 3577M Free Swap: 8192M Total, 1036K Used, 8191M Free PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 17587 www 446 62 0 0 0 0 0.00% httpd 17763 www 515 37 0 0 0 0 0.00% httpd 17860 www 538 47 0 0 0 0 0.00% httpd 17703 www 457 43 0 0 0 0 0.00% httpd 17701 www 485 34 0 0 0 0 0.00% httpd 17550 www 423 29 0 0 0 0 0.00% httpd 17579 www 0 0 0 0 0 0 0.00% httpd 17864 www 495 39 0 0 0 0 0.00% httpd 17836 www 520 36 0 0 0 0 0.00% httpd 17847 www 451 28 0 0 0 0 0.00% httpd 17756 www 462 29 0 0 0 0 0.00% httpd 17982 www 445 63 0 0 0 0 0.00% httpd 17581 www 451 60 0 0 0 0 0.00% httpd 17761 www 449 37 0 0 0 0 0.00% httpd 17582 www 509 30 0 0 0 0 0.00% httpd 17709 www 447 28 0 0 0 0 0.00% httpd 17705 www 515 30 0 0 0 0 0.00% httpd 17704 www 469 38 0 0 0 0 0.00% httpd 17706 www 508 53 0 0 0 0 0.00% httpd 17833 www 483 34 0 0 0 0 0.00% httpd 17834 www 499 43 0 0 0 0 0.00% httpd 17974 www 489 38 0 0 0 0 0.00% httpd 17978 www 467 45 0 0 0 0 0.00% httpd 17576 www 447 32 0 0 0 0 0.00% httpd 17570 www 443 37 0 0 0 0 0.00% httpd 17762 www 476 31 0 0 0 0 0.00% httpd 17837 www 508 44 0 0 0 0 0.00% httpd 17548 www 443 32 0 0 0 0 0.00% httpd 17783 www 390 22 0 0 0 0 0.00% httpd 17961 www 534 57 0 0 0 0 0.00% httpd 17590 www 498 50 0 0 0 0 0.00% httpd 17700 www 471 35 0 0 0 0 0.00% httpd 17580 www 438 41 0 0 0 0 0.00% httpd This used to be on a 4.11x system with 1 cpu and only 1gb of ram and ran flawlessly with much less resources with the same web site code for a long time. I do not have this problem on the other 7.0 machine. I originally thought it was just a cpu issue but it is very closely tied to when something is trying to use the raid arrays and this seems to be the way to reproduce it. I am having a hard time determining why the system load is so high. Can you recommend the best way to identify the culprit? Thanks, Paul From paul at elehost.com Wed Dec 17 22:52:58 2008 From: paul at elehost.com (Paul MacKenzie) Date: Wed Dec 17 22:53:13 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem Message-ID: <494967A9.3000503@elehost.com> > > [ns8]# vmstat -i > > interrupt total rate > > irq4: sio0 57065 0 > > irq17: em1 3989494045 554 > > irq18: arcmsr0 558098657 77 > > cpu0: timer 14381393929 2000 > > irq256: em0 22763077 3 > > cpu1: timer 14381384902 1999 > > Total 33333191675 4635 > > [ns8]# > > > > arcmsr0: >> > > mem 0xe8600000-0xe8600fff,0xe8000000-0xe83fffff irq 18 at device >> > > 14.0 on pci2 > > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 > > arcmsr0: [ITHREAD] > > ..... > > Waiting 5 seconds for SCSI devices to settle > > (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > > da0 at arcmsr0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-5 device > > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > > da0: 305175MB (624999424 512 byte sectors: 255H 63S/T 38904C) > > SMP: AP CPU #1 Launched! > Hi and thanks for your reply. I do not believe the interrupts are the problem at the moment as the stats. Here is a vmstat when the system usage is spiking and just before http needs to be killed to get going again most recently. vmstat -i interrupt total rate irq1: atkbd0 2 0 irq4: sio0 22880 0 irq14: ata0 58 0 irq22: uhci1 uhci3 18068 0 irq23: uhci0 uhci+ 1 0 irq26: arcmsr0 496094 14 cpu0: timer 61769334 1791 irq256: em0 1 0 irq258: em2 48505 1 irq259: em3 1 0 cpu1: timer 61762043 1791 cpu3: timer 61299367 1777 cpu2: timer 61299179 1777 cpu4: timer 61326132 1778 cpu7: timer 60845245 1764 cpu5: timer 61326513 1778 cpu6: timer 60845018 1764 Total 491058441 14243 There are no errors en the event console for the areca-cli. ARC-1130-VOL#00 Main Raid Array Raid1+0 1000.0GB 00/00/00 Normal Main Raid Array 4 2000.0GB 0.0GB 1234 Normal Main Processor : 500MHz CPU ICache Size : 32KB CPU DCache Size : 32KB CPU SCache Size : 0KB System Memory : 1024MB/333MHz/ECC Firmware Version : V1.44 2008-2-1 BOOT ROM Version : V1.44 2008-1-28 The buildworld taking a really long time was just an example of the problem I am seeing that is easy to quantify. If I run boxbackup, dump, clamscan or a few other IO intensive everything gets VERY slow even when reading files from the server. When the HTTP locks up (another issue that is seen and is connected to the same issue in my view) this is what it looks like. It is almost as if the http gets backed up from what I can tell and I need a plunger to clean out the blockage :) I have to kill it and then restart it to get things back to normal for a bit. last pid: 46013; load averages: 105.30, 67.67, 34.45 up 4+23:59:42 19:08:40 629 processes: 89 running, 540 sleeping CPU: 21.9% user, 0.0% nice, 74.5% system, 3.1% interrupt, 0.4% idle Mem: 1538M Active, 11G Inact, 898M Wired, 303M Cache, 214M Buf, 1346M Free Swap: 8192M Total, 1036K Used, 8191M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 46000 www 1 65 0 86728K 15008K RUN 1 0:01 12.06% httpd 45994 www 1 56 0 86728K 15008K CPU1 3 0:01 10.16% httpd 46002 www 1 -4 0 150M 20648K RUN 3 0:00 6.98% httpd 45195 www 1 68 0 121M 19748K RUN 1 0:29 6.88% httpd 45991 www 1 53 0 150M 21060K select 3 0:01 6.59% httpd 45997 www 1 -4 0 150M 20992K ufs 5 0:01 6.59% httpd 45950 www 1 57 0 153M 23388K RUN 2 0:01 6.49% httpd 45999 www 1 -4 0 150M 20640K ufs 6 0:00 5.96% httpd 45189 www 1 66 0 161M 29660K RUN 6 0:26 5.76% httpd 45974 www 1 -4 0 151M 21564K ufs 3 0:01 5.76% httpd 45984 www 1 -4 0 151M 21376K ufs 5 0:01 5.66% httpd 45998 www 1 -4 0 150M 20652K ufs 3 0:00 5.57% httpd 45780 www 1 -4 0 153M 23516K ufs 6 0:06 5.37% httpd 45972 www 1 -4 0 151M 21332K RUN 4 0:01 5.37% httpd 46001 www 1 20 0 150M 20568K lockf 4 0:00 5.37% httpd 45425 www 1 60 0 164M 31516K RUN 7 0:15 5.18% httpd 45995 www 1 63 0 150M 20820K RUN 2 0:00 5.18% httpd 45845 www 1 -4 0 151M 21692K ufs 6 0:02 4.98% httpd 45854 www 1 52 0 151M 22080K CPU6 0 0:02 4.88% httpd 45977 root 1 47 0 10160K 3260K CPU2 6 0:01 4.88% top 45509 www 1 56 0 155M 25028K RUN 0 0:14 4.79% httpd 45735 www 1 -4 0 158M 27096K RUN 3 0:07 4.79% httpd 45730 www 1 20 0 151M 21728K lockf 2 0:04 4.79% httpd 45847 www 1 -4 0 150M 21092K RUN 5 0:02 4.69% httpd 85338 root 1 46 0 150M 20560K select 7 5:03 4.59% httpd 45835 www 1 -4 0 150M 21100K ufs 0 0:02 4.59% httpd 45443 www 1 -4 0 151M 22220K ufs 6 0:12 4.49% httpd 45699 www 1 -4 0 157M 26528K RUN 0 0:07 4.39% httpd 45722 www 1 -4 0 152M 22908K RUN 0 0:05 4.39% httpd 45701 www 1 -4 0 152M 22268K RUN 2 0:07 4.30% httpd 45849 www 1 -4 0 151M 21748K ufs 6 0:02 4.30% httpd 46010 nagios 1 -4 0 7684K 1136K ufs 5 0:00 4.30% check_ping 45515 www 1 -4 0 160M 29048K ufs 5 0:13 4.20% httpd 45606 www 1 -4 0 152M 22420K ufs 0 0:09 4.20% httpd vfs.numvnodes: 355382 kern.maxvnodes: 400000 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 3239015 vfs.ufs.dirhash_maxmem: 10485760 vfs.ufs.dirhash_minsize: 2560 kern.ipc.nsfbufs: 0 kern.openfiles: 3395 kern.maxfiles: 12328 Results from netstat -m ------------------------ 1185/3360/4545 mbufs in use (current/cache/total) 1062/2856/3918/25600 mbuf clusters in use (current/cache/total/max) 1062/1556 mbuf+clusters out of packet secondary zone in use (current/cache) 10/1550/1560/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2460K/12752K/15212K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 46262 requests for I/O initiated by sendfile 0 calls to protocol drain routines Results from vmstat -m ------------------------ Type InUse MemUse HighUse Requests Size(s) cdev 22 6K - 22 256 acd_driver 1 2K - 1 2048 sigio 1 1K - 1626 64 filedesc 684 941K - 1199696 16,32,64,128,256,512,1024,2048,4096 kenv 68 11K - 70 16,32,64 kqueue 368 414K - 1740632 256,2048,4096 proc-args 52 4K - 5389885 16,32,64,128,256 ithread 99 19K - 99 32,128,256 acpisem 13 2K - 13 128 CAM queue 12 1K - 302 16,32,64,128,256 KTRACE 100 13K - 100 128 linker 45 4K - 71 16,32,64,128,512 lockf 314 38K - 16413112 64,128,256,512,1024,2048,4096 scsi_da 0 0K - 65 16 ip6ndp 7 1K - 7 64,128 ip6opt 1 1K - 50503 256 temp 66 222K - 6704801 16,32,64,128,256,512,1024,2048,4096 devbuf 16781 35476K - 108258 16,32,64,128,256,512,1024,2048,4096 CAM SIM 2 1K - 2 256 module 204 26K - 204 128 acpidev 78 5K - 78 64 mtx_pool 1 8K - 1 subproc 1111 1606K - 1045562 512,4096 proc 2 16K - 2 session 34 5K - 20772 128 pgrp 39 5K - 158890 128 cred 24950 6238K - 11839905 256 uidinfo 13 3K - 7337 64,2048 plimit 24 6K - 226179 256 CAM periph 7 2K - 45 16,32,64,128,256 sysctltmp 0 0K - 215050 16,32,64,128,256 sysctloid 4373 216K - 4373 16,32,64,128 sysctl 0 0K - 828292 16,32,64 umtx 1692 212K - 1692 128 p1003.1b 1 1K - 1 16 SWAP 2 1097K - 2 64 CAM XPT 51 24K - 19790153 32,64,128,256,1024 bus-sc 111 101K - 1879 16,32 ,64,128,256,512,1024,2048,4096 bus 804 77K - 5926 16,32,64,128,256,1024 devstat 10 21K - 10 32,4096 eventhandler 57 5K - 57 64,128 kobj 125 500K - 160 4096 kbdmux 6 9K - 6 16,256,512,2048,4096 rman 168 21K - 576 16,64,128 sbuf 0 0K - 840 16,32,64,128,256,512,1024,2048,4096 pci_link 16 2K - 16 16,128 stack 0 0K - 14 256 taskqueue 19 2K - 19 16,32,128 Unitno 16 1K - 22074 32,64 iov 0 0K - 12126863 16,64,128,256,512 ioctlops 0 0K - 388714 16,32,64,128,256,512,1024,2048 msg 4 30K - 4 2048,4096 sem 4 8K - 4 512,1024,2048,4096 shm 1 16K - 1 ttys 1170 169K - 80824 128,1024 ptys 5 2K - 5 256 accf 3 1K - 301 32,64 mbuf_tag 0 0K - 520852 32,128 pcb 47 158K - 1332310 16,32,128,1024,2048,4096 soname 187 23K - 10680643 16,32,128 biobuf 1 2K - 143707 2048 vfscache 1 1024K - 1 cl_savebuf 0 0K - 154293 64,128 vfs_hash 1 512K - 1 vnodes 2 1K - 3 32,256 vnodemarker 1 1K - 124142 512 mount 111 6K - 495 16,32,64,128,256,2048 acpi_perf 8 1K - 8 64 BPF 6 1K - 6 128 ether_multi 29 2K - 32 16,32,64 ifaddr 136 48K - 136 32,64,128,256,512,4096 ifnet 7 13K - 7 256,2048 clone 6 24K - 6 4096 arpcom 5 1K - 5 16 lo 1 1K - 1 32 acpica 3057 292K - 68659 16,32,64,128,256,512,1024 routetbl 303 86K - 1027 32,64,128 ,256,512 in_multi 4 1K - 4 64 IpFw/IpAcct 60 9K - 60 64,128,2048 sctp_iter 0 0K - 65 256 sctp_ifn 4 1K - 4 128 sctp_ifa 66 9K - 66 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 65 16 hostcache 1 36K - 1 entropy 1024 64K - 1024 64 syncache 1 100K - 1 in6_multi 16 1K - 16 32,64,128 audit_evclass 150 5K - 187 32 savedino 0 0K - 406078 256 newdirblk 0 0K - 5047 64 dirrem 18 2K - 2259617 64 mkdir 1 1K - 283528 64 diradd 183 12K - 3426340 64 freefile 55 4K - 1081462 64 freeblks 26 7K - 792864 256 freefrag 2 1K - 781740 64 allocindir 5 1K - 2842332 128 indirdep 4 1K - 116594 64 allocdirect 62 16K - 4832896 256 bmsafemap 12 2K - 271759 128 newblk 1 1K - 7675229 64,512 inodedep 270 580K - 2593883 256 pagedep 12 130K - 318828 128 ufs_dirhash 2848 1230K - 42435 16,32,64,128,256,512,1024,2048,4096 ufs_quota 1 512K - 1 ufs_mount 15 241K - 51 128,256,512,2048,4096 UMAHash 5 572K - 33 512,1024,2048,4096 USBHC 0 0K - 660 16 USBdev 22 10K - 682 16,128,512 USB 761 683K - 4079 16,32,64,128,256,1024 vm_pgdata 2 129K - 2 128 DEVFS1 115 58K - 115 512 DEVFS3 250 63K - 251 256 DEVFS2 115 2K - 115 16 DEVFS_RULE 36 17K - 36 64,512 DEVFS 30 1K - 31 16,128 io_apic 2 4K - 2 2048 pfs_nodes 20 5K - 20 256 memdesc 1 4K - 2 4096 msi 4 1K - 4 128 nexusdev 4 1K - 4 16 acpitask 0 0K - 9 64 GEOM 104 20K - 882 16,32,64,128,256,512,1024,2048 atkbddev 2 1K - 2 64 isadev 7 1K - 7 128 CAM dev queue 2 1K - 2 128 ata_generic 1 1K - 1 1024 ata_dma 1 1K - 1 256 Results from systat -v ----------------------- 1 users Load 143 90.86 47.13 Nov 21 19:10 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 1754100 25964 4719924 55728 1551492 count All 1916252 113912 9413004 269144 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 179 cow 16002 total 73 133 454 2 32k 816 2520 3 29k 726 504 zfod atkbd0 1 ozfod sio1 irq3 86.8%Sys 3.5%Intr 9.2%User 0.0%Nice 0.6%Idle %ozfod sio0 irq4 | | | | | | | | | | | daefr ata0 irq14 ===========================================++>>>>> 16 prcfr uhci1 uhci 314 dtbuf 90 totfr uhci0 uhci Namei Name-cache Dir-cache 400000 desvn react 2 arcmsr0 26 Calls hits % hits % 355344 numvn pdwak 2004 cpu0: time 76763 76730 100 24902 frevn pdpgs em0 irq256 intrn 1 em2 irq258 Disks da0 da1 pass0 pass1 pass2 934624 wire em3 irq259 KB/t 9.00 0.00 0.00 0.00 0.00 1697060 act 2000 cpu1: time tps 1 0 0 0 0 12038912 inact 1996 cpu2: time MB/s 0.01 0.00 0.00 0.00 0.00 308732 cache 2000 cpu3: time %busy 0 0 0 0 0 1244784 free 2001 cpu7: time 219632 buf 1999 cpu4: time 1999 cpu6: time 2000 cpu5: time Here is a "normal" sysstat -v to compare when there are no "visible" problems: 3 users Load 1.67 1.03 1.02 Nov 25 22:12 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 797576 31388 2318500 57324 4051340 count All 952256 114916 6781828 226696 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 556 cow 16001 total 1 6 474 5463 1602 3387 1 31k 1567 853 zfod atkbd0 1 ozfod sio1 irq3 8.4%Sys 4.0%Intr 2.8%User 0.0%Nice 84.8%Idle %ozfod sio0 irq4 | | | | | | | | | | | daefr ata0 irq14 ====++>> 602 prcfr uhci1 uhci 125 dtbuf 1443 totfr uhci0 uhci Namei Name-cache Dir-cache 400000 desvn react arcmsr0 26 Calls hits % hits % 328748 numvn pdwak 2026 cpu0: time 52734 52660 100 24705 frevn pdpgs em0 irq256 intrn 1 em2 irq258 Disks da0 da1 pass0 pass1 pass2 857028 wire em3 irq259 KB/t 0.00 0.00 0.00 0.00 0.00 750716 act 2026 cpu1: time tps 0 0 0 0 0 10564316 inact 1975 cpu2: time MB/s 0.00 0.00 0.00 0.00 0.00 303468 cache 1977 cpu3: time %busy 0 0 0 0 0 3748056 free 1999 cpu7: time 219632 buf 2000 cpu4: time 1997 cpu6: time 2000 cpu5: time ---------------------------------- Here are the results of vmstat -w 1 during the problem: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 da1 in sy cs us sy id 157 110 13 5544M 1111M 1141 0 0 0 1100 44 0 0 47 115 8744 7 14 79 146 34 98 5546M 1099M 4191 0 0 0 729 0 2 0 17 18583 102586 9 91 0 224 33 15 5548M 1091M 3825 0 0 0 664 0 0 0 7 14115 141707 10 90 0 165 103 11 5633M 1064M 12222 0 0 0 6745 0 2 0 42 41519 403437 14 86 0 214 73 4 5653M 1044M 4539 0 0 0 959 0 0 0 7 15698 94269 11 88 1 260 30 1 5664M 1034M 8457 0 0 0 2171 0 0 0 14 36978 248202 12 87 0 57 182 45 5667M 1029M 4761 0 0 0 2535 0 0 0 6 21004 133617 10 90 0 55 24 16 2152M 2454M 7993 0 0 0 3135 0 0 0 13 20263 173347 13 81 7 20 15 2 1972M 2537M 93820 0 0 0 465955 0 10 0 588 99274 716238 23 76 1 13 11 0 1877M 2581M 7820 0 0 0 31044 0 6 0 38 7859 76120 16 83 1 9 12 1 1816M 2599M 6889 0 0 0 14550 0 20 0 79 359198 21333 14 79 7 11 13 0 1797M 2613M 6542 0 0 0 8416 0 3 0 17 606119 15341 18 61 21 1 9 1 1740M 2636M 1744 0 0 0 6267 0 2 0 14 11617 15322 8 63 29 2 3 0 1694M 2657M 3417 0 0 0 8669 0 15 0 52 50341 12045 6 29 65 Here is another view of top at a later date with the same problem happening focusing on IO setting in Top: -------------------------------------------------------------- last pid: 17984; load averages: 39.26, 37.68, 24.75 up 8+09:25:55 04:34:53 539 processes: 59 running, 480 sleeping CPU: 9.8% user, 0.5% nice, 87.0% system, 2.3% interrupt, 0.4% idle Mem: 1146M Active, 9663M Inact, 875M Wired, 582M Cache, 214M Buf, 3577M Free Swap: 8192M Total, 1036K Used, 8191M Free PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 17587 www 446 62 0 0 0 0 0.00% httpd 17763 www 515 37 0 0 0 0 0.00% httpd 17860 www 538 47 0 0 0 0 0.00% httpd 17703 www 457 43 0 0 0 0 0.00% httpd 17701 www 485 34 0 0 0 0 0.00% httpd 17550 www 423 29 0 0 0 0 0.00% httpd 17579 www 0 0 0 0 0 0 0.00% httpd 17864 www 495 39 0 0 0 0 0.00% httpd 17836 www 520 36 0 0 0 0 0.00% httpd 17847 www 451 28 0 0 0 0 0.00% httpd 17756 www 462 29 0 0 0 0 0.00% httpd 17982 www 445 63 0 0 0 0 0.00% httpd 17581 www 451 60 0 0 0 0 0.00% httpd 17761 www 449 37 0 0 0 0 0.00% httpd 17582 www 509 30 0 0 0 0 0.00% httpd 17709 www 447 28 0 0 0 0 0.00% httpd 17705 www 515 30 0 0 0 0 0.00% httpd 17704 www 469 38 0 0 0 0 0.00% httpd 17706 www 508 53 0 0 0 0 0.00% httpd 17833 www 483 34 0 0 0 0 0.00% httpd 17834 www 499 43 0 0 0 0 0.00% httpd 17974 www 489 38 0 0 0 0 0.00% httpd 17978 www 467 45 0 0 0 0 0.00% httpd 17576 www 447 32 0 0 0 0 0.00% httpd 17570 www 443 37 0 0 0 0 0.00% httpd 17762 www 476 31 0 0 0 0 0.00% httpd 17837 www 508 44 0 0 0 0 0.00% httpd 17548 www 443 32 0 0 0 0 0.00% httpd 17783 www 390 22 0 0 0 0 0.00% httpd 17961 www 534 57 0 0 0 0 0.00% httpd 17590 www 498 50 0 0 0 0 0.00% httpd 17700 www 471 35 0 0 0 0 0.00% httpd 17580 www 438 41 0 0 0 0 0.00% httpd This used to be on a 4.11x system with 1 cpu and only 1gb of ram and ran flawlessly with much less resources with the same web site code for a long time. I do not have this problem on the other 7.0 machine. I originally thought it was just a cpu issue but it is very closely tied to when something is trying to use the raid arrays and this seems to be the way to reproduce it. I am having a hard time determining why the system load is so high. Can you recommend the best way to identify the culprit? Thanks, Paul From delphij at delphij.net Wed Dec 17 23:21:26 2008 From: delphij at delphij.net (Xin LI) Date: Wed Dec 17 23:21:34 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: <1229578180.6319.21.camel@nawfal-desktop> References: <4935069A.8060209@ec-marseille.fr> <49357BD0.4000008@delphij.net> <4935944A.9090509@ec-marseille.fr> <4935C453.8070301@delphij.net> <4935D67E.4070204@delphij.net> <4936F8C4.6090006@ec-marseille.fr> <49399FA6.3060108@delphij.net> <493CE8F7.5010204@yandex-team.ru> <3a6fb7145a0a6c8af136ea1a0824e5ed.squirrel@wettoast.dyndns.org> <493D9BC6.8050902@delphij.net> <4fe0419b44a3a4c4a28b1e60fbb3a3c8.squirrel@wettoast.dyndns.org> <56272b131067237ccabd23de5f669458.squirrel@wettoast.dyndns.org> <4944D894.6070306@delphij.net> <400809c165ecedf8a0b7bc6b569e1289.squirrel@wettoast.dyndns.org> <1229578180.6319.21.camel@nawfal-desktop> Message-ID: <4949F9E7.6030906@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Nawfal, Nawfal bin Mohmad Rouyan wrote: > I have been using a Dell machine with 2 bce interfaces as a bridge > between my LAN and Firewall to shape the traffic. Since after the > update, the machine can only run for a few minutes and after that no > more connection can go through. > > Ping from LAN to Internet is OK but when I telnet say to www.yahoo.com > at port 80 and issue "GET / HTTP/1.0" I can see the data of different > application including the HTML text. > > For example, I can see uTorrent packets with binaries and also the HTML > page being cut short. It's as if, I'm seeing packets jumbled together > from different application. > > I'm using PF to shape the traffic. If I reboot the server, it will panic > and I have about 3 different vmcores in /var/crash and not sure what to > do with it :( . I've tested the patch to remove > stat_IfInFramesL2FilterDiscards but the problem still occurs. The last patch is not a functional change, but a behavior change that removes the L2FilterDiscards from being counted to match previous behavior. Would you please do this: script bt.txt kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 Then, do 'bt', press enter until all display has finished, then exit kgdb, and send me the result (bt.txt)? > As for now, I'm not using the server to shape the traffic because I > suspect the driver isn't reliable. I'm going to revert back to the > previous driver and hopes its going to work. > > Sorry if there is not much detail since I'm not sure what to provide. > Just tell me what to provide and I'd be happy to do so. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklJ+eYACgkQi+vbBBjt66AM9wCePPUHQYhaW07lyhEzDIOqDEri da4AoKsXxzqjKZiJIAmlGaNaKmPCZboi =mdH7 -----END PGP SIGNATURE----- From test1000 at cogeco.ca Thu Dec 18 00:48:29 2008 From: test1000 at cogeco.ca (test1000@cogeco.ca) Date: Thu Dec 18 00:48:36 2008 Subject: Test Message-ID: <4949636d.3da.4bc2.9176@cogeco.ca> This is a test message from Cogeco Cable. No reply is necessary. From ivoras at freebsd.org Thu Dec 18 01:55:46 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Dec 18 01:55:53 2008 Subject: freebsd-stable@freebsd.org In-Reply-To: <4949673B.2070701@elehost.com> References: <4949673B.2070701@elehost.com> Message-ID: Paul MacKenzie wrote: > last pid: 46013; load averages: 105.30, 67.67, > 34.45 up 4+23:59:42 19:08:40 > 629 processes: 89 running, 540 sleeping > CPU: 21.9% user, 0.0% nice, 74.5% system, 3.1% interrupt, 0.4% idle > Mem: 1538M Active, 11G Inact, 898M Wired, 303M Cache, 214M Buf, 1346M Free > Swap: 8192M Total, 1036K Used, 8191M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 46000 www 1 65 0 86728K 15008K RUN 1 0:01 12.06% httpd > 45994 www 1 56 0 86728K 15008K CPU1 3 0:01 10.16% httpd > 46002 www 1 -4 0 150M 20648K RUN 3 0:00 6.98% httpd > 45195 www 1 68 0 121M 19748K RUN 1 0:29 6.88% httpd > 45991 www 1 53 0 150M 21060K select 3 0:01 6.59% httpd > 45997 www 1 -4 0 150M 20992K ufs 5 0:01 6.59% httpd > 45950 www 1 57 0 153M 23388K RUN 2 0:01 6.49% httpd > 45999 www 1 -4 0 150M 20640K ufs 6 0:00 5.96% httpd > 45189 www 1 66 0 161M 29660K RUN 6 0:26 5.76% httpd > 45974 www 1 -4 0 151M 21564K ufs 3 0:01 5.76% httpd The number of httpd processes in "ufs" state is too high. Are you using PHP? And if you do, check how large is your PHP sessions' directory. Use a "sharded" layout if it's of any significant size (see php.ini for details). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081218/2b10a507/signature.pgp From killing at multiplay.co.uk Thu Dec 18 02:00:33 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Dec 18 02:00:41 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem References: <494967A9.3000503@elehost.com> Message-ID: <42A989748EC74EB3A6520F7845446360@multiplay.co.uk> Just to confirm we see something similar on the box which runs our stats. We have updated from 5.4 -> 6.0 -> 6.2 -> 7.0 all have had no effect on the lockups which happen when the stats run. This box is also on an areca controller but it was on an Adaptec and we saw pretty much the same thing so I suspect its not related to the controller more to the way things are read from and flushed to disk. When we see this problem any ssh sessions become totally unresponsive. The stats we are running are a combination of rrdtool updates from a mysql DB and rrdtool backed mrtg for network stats. This is very reproducible here as it "stalls" the box every few mins when the stats kick off so if there needs to be more investigation we should be able to help. Regards Steve ----- Original Message ----- From: "Paul MacKenzie" >> > 14.0 on pci2 >> > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 >> > arcmsr0: [ITHREAD] >> > ..... >> > Waiting 5 seconds for SCSI devices to settle >> > (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> > da0 at arcmsr0 bus 0 target 0 lun 0 >> > da0: Fixed Direct Access SCSI-5 device >> > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> > da0: 305175MB (624999424 512 byte sectors: 255H 63S/T 38904C) >> > SMP: AP CPU #1 Launched! ... ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From danny at cs.huji.ac.il Thu Dec 18 02:49:51 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Thu Dec 18 02:49:59 2008 Subject: RELENG_7_1: bce driver change generating too much interrupts ? In-Reply-To: Your message of Wed, 17 Dec 2008 23:21:11 -0800 . Message-ID: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Nawfal, > > Nawfal bin Mohmad Rouyan wrote: > > I have been using a Dell machine with 2 bce interfaces as a bridge > > between my LAN and Firewall to shape the traffic. Since after the > > update, the machine can only run for a few minutes and after that no > > more connection can go through. > > > > Ping from LAN to Internet is OK but when I telnet say to www.yahoo.com > > at port 80 and issue "GET / HTTP/1.0" I can see the data of different > > application including the HTML text. > > > > For example, I can see uTorrent packets with binaries and also the HTML > > page being cut short. It's as if, I'm seeing packets jumbled together > > from different application. > > > > I'm using PF to shape the traffic. If I reboot the server, it will panic > > and I have about 3 different vmcores in /var/crash and not sure what to > > do with it :( . I've tested the patch to remove > > stat_IfInFramesL2FilterDiscards but the problem still occurs. > > The last patch is not a functional change, but a behavior change that > removes the L2FilterDiscards from being counted to match previous behavior. > > Would you please do this: > > script bt.txt kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 > > Then, do 'bt', press enter until all display has finished, then exit > kgdb, and send me the result (bt.txt)? > > > As for now, I'm not using the server to shape the traffic because I > > suspect the driver isn't reliable. I'm going to revert back to the > > previous driver and hopes its going to work. > > > > Sorry if there is not much detail since I'm not sure what to provide. > > Just tell me what to provide and I'd be happy to do so. I don't know if the following is related, but: - while stress testing nfs/zfs, I get many weird things on the server (dell-2950/bce) example: impossible packet length (33555456) from nfs server fr-01:/vol/system/share impossible packet length (1792323116) from nfs server fr-01:/vol/system/share ... and things get worse soon after. Now, there are no input errors, so it seems some memory starvation are not properly handled ... cheers, danny From utisoft at googlemail.com Thu Dec 18 02:57:07 2008 From: utisoft at googlemail.com (Chris Rees) Date: Thu Dec 18 02:57:14 2008 Subject: Test In-Reply-To: <4949636d.3da.4bc2.9176@cogeco.ca> References: <4949636d.3da.4bc2.9176@cogeco.ca> Message-ID: 2008/12/17 : > This is a test message from Cogeco Cable. No reply is necessary. What's wrong with http://lists.freebsd.org/mailman/listinfo/freebsd-test ? -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From bsdlist at cogeco.ca Thu Dec 18 06:30:44 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Thu Dec 18 06:30:52 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <42A989748EC74EB3A6520F7845446360@multiplay.co.uk> References: <494967A9.3000503@elehost.com> <42A989748EC74EB3A6520F7845446360@multiplay.co.uk> Message-ID: <494A5F11.5080701@cogeco.ca> > Just to confirm we see something similar on the box which runs our stats. > > We have updated from 5.4 -> 6.0 -> 6.2 -> 7.0 all have had no effect on > the lockups which happen when the stats run. > > This box is also on an areca controller but it was on an Adaptec and we > saw pretty much the same thing so I suspect its not related to the > controller more to the way things are read from and flushed to disk. > > When we see this problem any ssh sessions become totally unresponsive. > > The stats we are running are a combination of rrdtool updates from a > mysql DB and rrdtool backed mrtg for network stats. > > This is very reproducible here as it "stalls" the box every few mins > when the stats kick off so if there needs to be more investigation > we should be able to help. > > Regards > Steve Hi Steve, Thanks for your message. Do your processes also lock in UFS state? Well I went and bought a new Areca controller to see if this would fix it. It is quicker and seems to work much better but unfortunately I am still seeing the locking. I moved from a PCI-X Areca controller w/ 1 GB of Cache to a PCI-Express controller w/ 2 GB of cache. Main Processor : 800MHz CPU ICache Size : 32KB CPU DCache Size : 32KB CPU SCache Size : 512KB System Memory : 2048MB/533MHz/ECC Firmware Version : V1.46 2008-08-06 BOOT ROM Version : V1.45 2008-08-26 Controller Name : ARC-1231 As I try to see if there is a hardware connection to this I will let you know. I guess I am going to have to replace the full chassis SR2500ALBRPNA and mainboard S5000PAL next. If no solution is found with hardware replacement then am I out of options with using Freebsd? I wonder would there be any need to also try to replace the ram and cpus given there are no errors? Thanks, Paul From bms at incunabulum.net Thu Dec 18 07:43:18 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Dec 18 07:43:26 2008 Subject: Q: eSATA Hot Swap supported? Message-ID: <494A6F93.7040806@incunabulum.net> Hi, Does FreeBSD 7.1 support eSATA hot swappable disks? cheers BMS From bms at incunabulum.net Thu Dec 18 07:44:34 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Dec 18 07:44:46 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <3a142e750812140747r2eb5ebadp7ac2b2c8ae357bae@mail.gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <8cb6106e0812031453j6dc2f2f4i374145823c084eaa@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> <493CEE90.7050104@FreeBSD.org> <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> <4943F43B.4060105@incunabulum.net> <3a142e750812131403p31841403ub9d5693278c74111@mail.gmail.com> <4944501E.40900@incunabulum.net> <3a142e750812140747r2eb5ebadp7ac2b2c8ae357bae@mail.gmail.com> Message-ID: <494A6FDF.8030103@incunabulum.net> Paul B. Mahol wrote: > Project itself doesnt look very active, but I may be wrong. It is in alpha state > as reported on SF. > IMHO it is better to maintain our own because it is in better shape, but I'm not > intersted in ext* as developer. > Shelved due to lack of interest, then... others can feel free to pick up. thanks BMS From aragon at phat.za.net Thu Dec 18 08:38:25 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Thu Dec 18 08:38:33 2008 Subject: FreeBSD 7.1-RC1 Available... In-Reply-To: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> Message-ID: <20081218161103.GA52173@phat.za.net> Hi, | By Ken Smith | [ 2008-12-10 04:40 +0200 ] > In addition to general testing we're looking for information about > potential problems with the boot loader. There has been traffic here > about problems but the reports haven't helped narrow down the causes > yet. So far it seems to be related to USB keyboards and at least so far > systems with more than one processor in them. More data points like > cases where a USB keyboard was not involved as well as if possible > things like which motherboard it is might help us narrow down the cause. > Testing on a variety of motherboards, of varying ages and manufacturers > would help. I have been experiencing problems with loader(8) on my system. Essentially it freezes the system if "too much" keyboard input is given. Please see these posts for more background: http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046176.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046189.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046337.html I've just tested booting up with an i386 RC1 disc and the problem is still there. My motherboard is an Intel DG33BU. Regards, Aragon From crapsh at monkeybrains.net Thu Dec 18 14:58:04 2008 From: crapsh at monkeybrains.net (Rudy) Date: Thu Dec 18 14:58:11 2008 Subject: Q: eSATA Hot Swap supported? In-Reply-To: <494A6F93.7040806@incunabulum.net> References: <494A6F93.7040806@incunabulum.net> Message-ID: <494AD575.2060008@monkeybrains.net> Bruce Simpson wrote: > Does FreeBSD 7.1 support eSATA hot swappable disks? Answer: Yes. I have a hot-swap case and can swap my internal SATA disks. Your eSATA's show up as 'ad' devices, correct? You may need to run atacontrol to get the drives to show up after you hot-plug them. atacontrol list *find the channel* atacontrol attach ata3 (or whatever number...) "man atacontrol" for lots of useful info. Rudy From bruce at cran.org.uk Thu Dec 18 16:34:42 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Dec 18 16:34:48 2008 Subject: Request for testing - top 3.8b1 in the base system In-Reply-To: <20080928054620.GA80250@k7.mavetju> References: <20080928054620.GA80250@k7.mavetju> Message-ID: <20081219001709.GA32031@muon.cran.org.uk> On Sun, Sep 28, 2008 at 03:46:20PM +1000, Edwin Groothuis wrote: > I have made an update for the top(1) utility in the FreeBSD base > system to get it from the 3.5b12 version to the 3.8b1 version. > [...] > Please report any issues with it (compile time, run time) and a way > to reproduce it (if possible). Thanks for your help! > There's an overflow bug in format_k2 in 3.5b12 that means that top can corrupt the SIZE field of processes which allocate 2TB or more of memory; that seems to be fixed in 3.8b1 but I've noticed that if a process allocates over 2TB then it doesn't show up at the top of the display when sorting by SIZE in 3.8b1; I suspect there must be another overflow somewhere. I'm sure it'll be a good few years before anyone actually hits this bug running real programs, but I don't know if it might affect other things. -- Bruce Cran -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081219/fe38a1a6/attachment.pgp From bsdlist at cogeco.ca Thu Dec 18 16:38:56 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Thu Dec 18 16:39:03 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: References: <4949673B.2070701@elehost.com> Message-ID: <494AED9E.9090900@cogeco.ca> >> last pid: 46013; load averages: 105.30, 67.67, >> 34.45 up 4+23:59:42 19:08:40 >> 629 processes: 89 running, 540 sleeping >> CPU: 21.9% user, 0.0% nice, 74.5% system, 3.1% interrupt, 0.4% idle >> Mem: 1538M Active, 11G Inact, 898M Wired, 303M Cache, 214M Buf, 1346M Free >> Swap: 8192M Total, 1036K Used, 8191M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 46000 www 1 65 0 86728K 15008K RUN 1 0:01 12.06% httpd >> 45994 www 1 56 0 86728K 15008K CPU1 3 0:01 10.16% httpd >> 46002 www 1 -4 0 150M 20648K RUN 3 0:00 6.98% httpd >> 45195 www 1 68 0 121M 19748K RUN 1 0:29 6.88% httpd >> 45991 www 1 53 0 150M 21060K select 3 0:01 6.59% httpd >> 45997 www 1 -4 0 150M 20992K ufs 5 0:01 6.59% httpd >> 45950 www 1 57 0 153M 23388K RUN 2 0:01 6.49% httpd >> 45999 www 1 -4 0 150M 20640K ufs 6 0:00 5.96% httpd >> 45189 www 1 66 0 161M 29660K RUN 6 0:26 5.76% httpd >> 45974 www 1 -4 0 151M 21564K ufs 3 0:01 5.76% httpd >> > > The number of httpd processes in "ufs" state is too high. Are you using > PHP? And if you do, check how large is your PHP sessions' directory. Use > a "sharded" layout if it's of any significant size (see php.ini for > details). > Sorry for the messed up posts and thanks for your suggestion. I apologize if any posts have been duplicated as there seems to be an issue with delivery from cogeco at times. Yes I was thinking the same thing and It was actually one of the first things I looked. I found in the temporary folder there are only about 50-200 there at any one time approximately and most of the time 5-15 files. PHP seems to be only one way to bring it forward. I increased the dirhash when I first started on this problem but the numbers of files in the folders were not nearly like some of the other people reporting a similar connection and I seem to be able to get the system into the state a number of ways. Do you think I should still do this even with the small number of files? vfs.ufs.dirhash_maxmem=10485760 I actually find that running Wusage 8.0 a few times even with nice-19 may be implicated in getting the system to spiral downwards. I hesitate to mention this as it seems to be working fine on another 7.X server. I believe that Wusage is tied to 6.X libraries and I wonder if somehow this may initiate the problem. I also have another sio/com based program running every few minutes which is also connected to the 6.X library (scom thermal application for temperature monitoring) and turning both of these off seems to help. I am going to try a 24 hour period without either of these two running after a fresh reboot and we will see if this is indeed one source to my abominable problem. Once the system spirals down into its locking then the io performance never seems to recover unless I reboot it or somehow find the process that is locked and kill it. I wondered if possibly my problem is related to this identified issue 104406? [ufs] Processes get stuck in "ufs" state under persistent CPU load http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= As the processes do get stuck in the ufs mode from what I can tell I thought this was an interesting connection. When the system is in this state even a simple make depend is agonizingly slow. If so I wondered if there was any way to quickly determine via programming which process is stuck and to get it unstuck as a temporary workaround? The problem reports mentions using 'kill -STOP' and continued with 'kill -CONT', which allows other processes to access the filesystem (until another such failure occurs). I have tried a number of things but so far no luck. Thanks, Paul From yohimba at mail.ru Thu Dec 18 23:02:10 2008 From: yohimba at mail.ru (Vyacheslav I.) Date: Thu Dec 18 23:02:17 2008 Subject: Problem with FreeBSD for AMD64 & Mylex AcceleRAID Message-ID: Hi! I used to use the FreeBSD on i386 architecture together with the controller Mylex AcceleRAID 170.There was RAID 0+1 configured on it out of 5 discs (Enhanced Mirroring). # pciconf -lvc ... mly0@pci0:6:1:0: class=0x010400 card=0x00521069 chip=0x00501069 rev=0x02 hdr=0x00 vendor = 'Mylex Corp' device = 'AcceleRAID Disk Array' class = mass storage subclass = RAID cap 01[80] = powerspec 2 supports D0 D3 current D0 I used this configuration on i386 architecture with the following versions FreeBSD: 4.x, 5.x, 6.x and 7.0. It always worked perfectly. But recently I got needed 8 GB RAM so I had to install the version FreeBSD for AMD64. First I tried the 7.0, and after all - RELENG_7_1 dated 12.12.2008. Both these systems work with the files system located on RAID unstabl?! Meanwhile the same hardware on i386 architecture works with RELENG_7_1 perfectly. Hardware: MB INTEL DG33FB, CPU Intel(R) Core(TM)2 Quad CPU @ 2.40 GHz, RAM 8 GB. The base system is installed on a separate IDE disc. # df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad4s1a 496M 111M 345M 24% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad4s1d 3.9G 22K 3.6G 0% /tmp /dev/ad4s1f 333G 52G 255G 17% /usr /dev/ad4s1e 15G 41M 14G 0% /var /dev/da0s1d 70.7G 410K 70.1G 0% /mnt/da0/d I carried out the following test by creating 3 big sized files of 1 GB each, and then deleting them: # cd /mnt/da0/d # dd if=/dev/zero of=test1 bs=1024k count=1024 # dd if=/dev/zero of=test2 bs=1024k count=1024 # dd if=/dev/zero of=test5 bs=1024k count=1024 # rm test* After that I tried to unmount the files system, but I get a message of the kernel panic: # cd / # umount /mnt/da0/d ... bad block 123456789, ino 176 dev = da0s1d, block = 4, fs = /mnt/da0/d panic: ffs_blkfree: freeing free block cpuid = 3 Uptime: 34 min... The test was successful when using the i386 architecture with the same hardware Taking a piece of advice of my friend, I used a dirty patch: === [code] === diff -Nru src.orig/sys/cam/scsi/scsi_da.c src/sys/cam/scsi/scsi_da.c --- src.orig/sys/cam/scsi/scsi_da.c 2008-12-10 10:01:40.000000000 +0800 +++ src/sys/cam/scsi/scsi_da.c 2008-12-19 12:18:27.000000000 +0800 @@ -1187,7 +1187,7 @@ if (match != NULL) softc->quirks = ((struct da_quirk_entry *)match)->quirks; else - softc->quirks = DA_Q_NONE; + softc->quirks = DA_Q_NO_SYNC_CACHE; // Dirty hack for AMD64 /* Check if the SIM does not want 6 byte commands */ xpt_setup_ccb(&cpi.ccb_h, periph->path, /*priority*/1); === [/code] === This patch solved the problem and the systems stopped being panicking. But I assume that this solution is wrong as the hardware works on i386 architecture without this patch well. From bsdlist at cogeco.ca Fri Dec 19 01:15:16 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Fri Dec 19 01:15:30 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <200812161556.mBGFuB7n089368@lava.sentex.ca> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com> <494698E4.2070406@cogeco.ca> <200812151900.mBFJ0Jom084267@lava.sentex.ca> <4946B6EF.5080806@cogeco.ca> <200812152010.mBFKAlZf084580@lava.sentex.ca> <4946BDB1.8060208@cogeco.ca> <200812152035.mBFKZkj4084689@lava.sentex.ca> <4946DA2F.7090508@cogeco.ca> <200812161556.mBGFuB7n089368@lava.sentex.ca> Message-ID: <49494FE0.4040400@cogeco.ca> > Is the high load average simply a function of processes blocking on > network io ? On our av/spam scanners for example show a high load avg > because there are many processes waiting on network io to complete > (e.g. talking to RBL lists, waiting for DCC servers to complete etc) > > Also, is it really related to the arcmsr driver ? i.e. if you did the > same tasks on a single IDE drive, is the performance profile going to > be the same ? > > ---Mike > I wondered if possibly my problem is related to this issue 104406? [ufs] Processes get stuck in "ufs" state under persistent CPU load http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= As the processes do get stuck in the ufs mode from what I can tell. I am going to be replacing the RAID card tomorrow to make sure it is not the card despite the lack of errors. If so I wondered if there was any way to quickly determine via programming which process is stuck and to get it unstuck as a temporary workaround? The problem reports mentions using 'kill -STOP' and continued with 'kill -CONT', which allows other processes to access the filesystem (until another such failure occurs). I just need to be able to determine which process is the one stuck in a relatively easy manner. Thanks, Paul From bsdlist at cogeco.ca Fri Dec 19 01:15:18 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Fri Dec 19 01:15:31 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: References: <4949673B.2070701@elehost.com> Message-ID: <494A6F36.9040507@cogeco.ca> >> last pid: 46013; load averages: 105.30, 67.67, >> 34.45 up 4+23:59:42 19:08:40 >> 629 processes: 89 running, 540 sleeping >> CPU: 21.9% user, 0.0% nice, 74.5% system, 3.1% interrupt, 0.4% idle >> Mem: 1538M Active, 11G Inact, 898M Wired, 303M Cache, 214M Buf, 1346M Free >> Swap: 8192M Total, 1036K Used, 8191M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 46000 www 1 65 0 86728K 15008K RUN 1 0:01 12.06% httpd >> 45994 www 1 56 0 86728K 15008K CPU1 3 0:01 10.16% httpd >> 46002 www 1 -4 0 150M 20648K RUN 3 0:00 6.98% httpd >> 45195 www 1 68 0 121M 19748K RUN 1 0:29 6.88% httpd >> 45991 www 1 53 0 150M 21060K select 3 0:01 6.59% httpd >> 45997 www 1 -4 0 150M 20992K ufs 5 0:01 6.59% httpd >> 45950 www 1 57 0 153M 23388K RUN 2 0:01 6.49% httpd >> 45999 www 1 -4 0 150M 20640K ufs 6 0:00 5.96% httpd >> 45189 www 1 66 0 161M 29660K RUN 6 0:26 5.76% httpd >> 45974 www 1 -4 0 151M 21564K ufs 3 0:01 5.76% httpd >> > > The number of httpd processes in "ufs" state is too high. Are you using > PHP? And if you do, check how large is your PHP sessions' directory. Use > a "sharded" layout if it's of any significant size (see php.ini for > details). > Sorry for the messed up posts and thanks for your suggestion. I apologize if any posts have been duplicated as there seems to be an issue with delivery from cogeco at times. Yes I was thinking the same thing and It was actually one of the first things I looked. I found in the temporary folder there are only about 50-200 there at any one time approximately and most of the time 5-15 files. PHP seems to be only one way to bring it forward. I increased the dirhash when I first started on this problem but the numbers of files in the folders were not nearly like some of the other people reporting a similar connection and I seem to be able to get the system into the state a number of ways. Do you think I should still do this even with the small number of files? vfs.ufs.dirhash_maxmem=10485760 I actually find that running Wusage 8.0 a few times even with nice-19 may be implicated in getting the system to spiral downwards. I hesitate to mention this as it seems to be working fine on another 7.X server. I believe that Wusage is tied to 6.X libraries and I wonder if somehow this may initiate the problem. I also have another sio/com based program running every few minutes which is also connected to the 6.X library (scom thermal application for temperature monitoring) and turning both of these off seems to help. I am going to try a 24 hour period without either of these two running after a fresh reboot and we will see if this is indeed one source to my abominable problem. Once the system spirals down into its locking then the io performance never seems to recover unless I reboot it or somehow find the process that is locked and kill it. I wondered if possibly my problem is related to this identified issue 104406? [ufs] Processes get stuck in "ufs" state under persistent CPU load http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= As the processes do get stuck in the ufs mode from what I can tell I thought this was an interesting connection. When the system is in this state even a simple make depend is agonizingly slow. If so I wondered if there was any way to quickly determine via programming which process is stuck and to get it unstuck as a temporary workaround? The problem reports mentions using 'kill -STOP' and continued with 'kill -CONT', which allows other processes to access the filesystem (until another such failure occurs). I have tried a number of things but so far no luck. Thanks, Paul From marius at nuenneri.ch Fri Dec 19 02:19:10 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Dec 19 02:19:17 2008 Subject: Kernel not mounting root Message-ID: Hi all, I did cvsup to 7-STABLE yesterday, build, installed and booted a new kernel then buildworld. Then I noticed that my PS/2 keyboard is not working at the loader menu so I booted multiuser and did the make installworld part from there. Then I tried to reboot but now it hangs after the line Trying to mount root from ufs:/dev/ad4s1a It sits there for at least 10min. I tried so far: - Installing 7.1-beta2 on another hd and booting it, it works. - Copied that kernel to the old hd - Moved kernel.old to kernel - fsck everything - mounted everything from the old hd under /mnt, chroot into that, installworld Anyone else seeing this or has an idea what to do next? Kind regards Marius From me at janh.de Fri Dec 19 07:23:24 2008 From: me at janh.de (Jan Henrik Sylvester) Date: Fri Dec 19 07:23:32 2008 Subject: iwn on 7.1-RC1 Message-ID: <494BB96F.2040702@janh.de> Short version: Is there any chance to get iwn working on 7.1-RC1 reliably? I have got one problem with the initial perforce version and the backport from gavin always crashes. Long version: I have been using the initial perforce version of iwn on 7-STABLE for a few month now, since the next version is already "vap'ify iwn". Usually, the connection to my WPA2 ap is established on boot, but pretty often I get an error instead: iwn0: error, INTR=82000000 STATUS=0x10000 iwn0: iwn_config: could not set power mode, error 35 Doing one or two "kldunload if_iwn" fixes the problem. Rarely, I had crashes (on boot). Today, I found that gavin did a backport of iwn in September: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045234.html As it had some changes compared to the initial perforce version, I tried that version instead. I always get a crash on boot: [...] iwn0: iwn_read_eeprom_ht40: no entry for channel 10 iwn0: iwn_read_eeprom_ht40: no entry for channel 11 iwn0: iwn_read_eeprom_ht40: no entry for channel 12 iwn0: iwn_read_eeprom_ht40: no entry for channel 13 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc5bb5004 fault code = supervisor read, page not present instruction pointer = 0x20:0xc1543935 stack pointer = 0x28:0xc18207f8 frame pointer = 0x28:0xc1820858 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processsor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort I do not remember, if the crash is the same as I had with the initial perforce version, which I cannot reproduce. Does anyone have a better version of iwn without vap? Does anyone know which current / perforce change could address the error mentioned above? There are only a few differences between the initial perforce version and the backport by gavin (besides man page). I will attach them below. Cheers, Jan Henrik diff -u perforce/sys/dev/iwn/if_iwn.c gavin/sys/dev/iwn/if_iwn.c --- perforce/sys/dev/iwn/if_iwn.c 2008-12-19 15:19:14.000000000 +0100 +++ gavin/sys/dev/iwn/if_iwn.c 2008-12-19 15:16:57.000000000 +0100 @@ -124,6 +124,7 @@ void iwn_rx_statistics(struct iwn_softc *, struct iwn_rx_desc *); void iwn_tx_intr(struct iwn_softc *, struct iwn_rx_desc *); void iwn_cmd_intr(struct iwn_softc *, struct iwn_rx_desc *); +static void iwn_bmiss(void *, int); void iwn_notif_intr(struct iwn_softc *); void iwn_intr(void *); void iwn_read_eeprom(struct iwn_softc *); @@ -292,7 +293,8 @@ taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq", device_get_nameunit(dev)); - TASK_INIT(&sc->sc_opstask, 0, iwn_ops, sc ); + TASK_INIT(&sc->sc_ops_task, 0, iwn_ops, sc ); + TASK_INIT(&sc->sc_bmiss_task, 0, iwn_bmiss, sc ); /* * Put adapter into a known state. @@ -379,6 +381,8 @@ #endif | IEEE80211_C_WME /* WME */ ; +#if 0 + /* XXX disable until HT channel setup works */ ic->ic_htcaps = IEEE80211_HTCAP_SMPS_ENA /* SM PS mode enabled */ | IEEE80211_HTCAP_CHWIDTH40 /* 40MHz channel width */ @@ -391,7 +395,7 @@ | IEEE80211_HTC_AMPDU /* tx A-MPDU */ | IEEE80211_HTC_AMSDU /* tx A-MSDU */ ; - +#endif /* read supported channels and MAC address from EEPROM */ iwn_read_eeprom(sc); @@ -1594,6 +1598,15 @@ wakeup(&ring->cmd[desc->idx]); } +static void +iwn_bmiss(void *arg, int npending) +{ + struct iwn_softc *sc = arg; + struct ieee80211com *ic = sc->sc_ifp->if_l2com; + + ieee80211_beacon_miss(ic); +} + void iwn_notif_intr(struct iwn_softc *sc) { @@ -1652,7 +1665,8 @@ if (ic->ic_state == IEEE80211_S_RUN && misses > 5) (void) iwn_init_sensitivity(sc); if (misses >= ic->ic_bmissthreshold) - ieee80211_beacon_miss(ic); + taskqueue_enqueue(taskqueue_swi, + &sc->sc_bmiss_task); break; } case IWN_UC_READY: { @@ -2398,7 +2412,7 @@ static const struct iwn_chan_band iwn_bands[] = { { IWN_EEPROM_BAND1, IEEE80211_CHAN_G, 14, { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 } }, - { IWN_EEPROM_BAND2, IEEE80211_CHAN_A, 13, +/* { IWN_EEPROM_BAND2, IEEE80211_CHAN_A, 13, { 183, 184, 185, 187, 188, 189, 192, 196, 7, 8, 11, 12, 16 } }, { IWN_EEPROM_BAND3, IEEE80211_CHAN_A, 12, { 34, 36, 38, 40, 42, 44, 46, 48, 52, 56, 60, 64 } }, @@ -2406,11 +2420,11 @@ { 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140 } }, { IWN_EEPROM_BAND5, IEEE80211_CHAN_A, 6, { 145, 149, 153, 157, 161, 165 } }, - { IWN_EEPROM_BAND6, IEEE80211_CHAN_G | IEEE80211_CHAN_HT40, 7, +*/ { IWN_EEPROM_BAND6, IEEE80211_CHAN_G | IEEE80211_CHAN_HT40, 7, { 1, 2, 3, 4, 5, 6, 7 } }, - { IWN_EEPROM_BAND7, IEEE80211_CHAN_A | IEEE80211_CHAN_HT40, 11, +/* { IWN_EEPROM_BAND7, IEEE80211_CHAN_A | IEEE80211_CHAN_HT40, 11, { 36, 44, 52, 60, 100, 108, 116, 124, 132, 149, 157 } } - }; +*/ }; struct ieee80211com *ic = &sc->sc_ic; int i; @@ -2651,14 +2665,14 @@ /* XXX all wrong */ /* compute remaining time until next beacon */ val = (uint64_t)ni->ni_intval * 1024; /* msecs -> usecs */ - DPRINTF(sc, IWN_DEBUG_ANY, "%s: val = %llu %s\n", __func__, + DPRINTF(sc, IWN_DEBUG_ANY, "%s: val = %ju %s\n", __func__, val, val == 0 ? "correcting" : ""); if (val == 0) val = 1; mod = le64toh(tsf.tstamp) % val; tsf.binitval = htole32((uint32_t)(val - mod)); - DPRINTF(sc, IWN_DEBUG_RESET, "TSF bintval=%u tstamp=%llu, init=%u\n", + DPRINTF(sc, IWN_DEBUG_RESET, "TSF bintval=%u tstamp=%ju, init=%u\n", ni->ni_intval, le64toh(tsf.tstamp), (uint32_t)(val - mod)); if (iwn_cmd(sc, IWN_CMD_TSF, &tsf, sizeof tsf, 1) != 0) @@ -4243,7 +4257,7 @@ sc->sc_cmd_arg[sc->sc_cmd_next] = arg; sc->sc_cmd_next = (sc->sc_cmd_next + 1) % IWN_CMD_MAXOPS; } - taskqueue_enqueue(sc->sc_tq, &sc->sc_opstask); + taskqueue_enqueue(sc->sc_tq, &sc->sc_ops_task); IWN_CMD_UNLOCK(sc); return 0; } --- perforce/sys/dev/iwn/if_iwnvar.h 2008-12-19 15:19:14.000000000 +0100 +++ gavin/sys/dev/iwn/if_iwnvar.h 2008-12-19 15:16:57.000000000 +0100 @@ -197,7 +197,8 @@ struct taskqueue *sc_tq; /* Main command task queue */ /* Tasks used by the driver */ - struct task sc_opstask; /* operation handling task */ + struct task sc_ops_task; /* operation handling task */ + struct task sc_bmiss_task; /* beacon miss task */ /* Thermal calibration */ struct callout calib_to; --- perforce/sys/modules/iwn/Makefile 2008-12-19 15:19:14.000000000 +0100 +++ gavin/sys/modules/iwn/Makefile 2008-12-19 15:16:57.000000000 +0100 @@ -3,6 +3,6 @@ .PATH: ${.CURDIR}/../../dev/iwn KMOD = if_iwn -SRCS = if_iwn.c opt_bdg.h device_if.h bus_if.h pci_if.h -CFLAGS += -g -DWITNESS -DINVARIANT_SUPPORT -DINVARIANTS -I${.CURDIR}/../../ +SRCS = if_iwn.c device_if.h bus_if.h pci_if.h + .include From bahamasfranks at gmail.com Fri Dec 19 13:51:57 2008 From: bahamasfranks at gmail.com (Steve Franks) Date: Fri Dec 19 13:52:03 2008 Subject: ext2fuse: user-space ext2 implementation In-Reply-To: <3a142e750812140747r2eb5ebadp7ac2b2c8ae357bae@mail.gmail.com> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <200812041747.09040.gnemmi@gmail.com> <4938FE44.9090608@FreeBSD.org> <4939133E.2000701@FreeBSD.org> <493CEE90.7050104@FreeBSD.org> <3a142e750812090553l564bff84pe1f02cd1b03090ff@mail.gmail.com> <4943F43B.4060105@incunabulum.net> <3a142e750812131403p31841403ub9d5693278c74111@mail.gmail.com> <4944501E.40900@incunabulum.net> <3a142e750812140747r2eb5ebadp7ac2b2c8ae357bae@mail.gmail.com> Message-ID: <539c60b90812191351i6090f24ejb9006471f74f01b9@mail.gmail.com> On Sun, Dec 14, 2008 at 8:47 AM, Paul B. Mahol wrote: > On 12/14/08, Bruce M Simpson wrote: >> Paul B. Mahol wrote: >>>> Can you please relay this feedback to the authors of ext2fuse? >>>> >>>> As mentioned earlier in the thread, the ext2fuse code could benefit from >>>> UBLIO-ization. Are you or any other volunteers happy to help out here? >>>> >>> >>> Well, first higher priority would be to fix existing bugs. It would be >>> very little >>> gain with user cache, because it is already too much IMHO slow and >>> adding user cache >>> will not make it faster, but that is not port problem. >>> >> >> I'm not aware of bugs with ext2fuse itself; my work on the port was >> merely to try to raise awareness that a user-space project for ext2 >> filesystem access existed. >> >> Can you elaborate further on your experience with ext2fuse which seems >> to you to be buggy, i.e. symptoms, root cause analysis etc. ? Have you >> reported these to the author(s)? > > I have read TODO. > >> Have you measured the performance? Is the performance sufficient for the >> needs of an occasional desktop user? > > Performance was not sufficient, and adding user cache will not improve access > speed on first read. > After mounting ext2fs volume (via md(4)) created with e2fsprogs port > and copying data > from ufs to ext2, reading was quite slow. Also ext2fuse after mount > doesnt exits it > is still running displaying debug data - explaining why project > itselfs is in alpha > state. > >> I realise we are largely involved in content-free argument here, however >> the trade-off of ext2fuse vs ext2fs in the FreeBSD kernel source tree, >> is that of a hopefully more actively maintained implementation vs one >> which is not maintained at all, and any alternatives for FreeBSD users >> would be welcome. > > Project itself doesnt look very active, but I may be wrong. It is in alpha state > as reported on SF. > IMHO it is better to maintain our own because it is in better shape, but I'm not > intersted in ext* as developer. AFAIK our ext* either barfs or corrupts ext3, and since linux is pretty much all using ext3 these days, we're stuck in read-only for ext3, which is rather undesirable, methinks (seems everyone's using fuse's ntfs for this same reason [which is stable, however]). Which is not to say stealing the ext3 (journal?) implementation and putting it in our code isn't a better choice, I'm just pointing out there is no good choice right now... Steve From gmiller at classic-games.com Sat Dec 20 09:47:13 2008 From: gmiller at classic-games.com (Greg Miller) Date: Sat Dec 20 09:47:20 2008 Subject: Lockups and panics during multiuser boot Message-ID: <494D2C64.1030105@classic-games.com> After upgrading to 7.1RC1, I found I could only boot single-user without a panic or a lockup. After bisecting recent changes on RELENG_7, I found that the problem occurs after 2008.10.29.15.00.00 and before 2008.10.29.18.00.00 -- http://www.velocityvector.com/ | http://www.classic-games.com/ Any government that can give you everything you want can take everything you have. From kostikbel at gmail.com Sat Dec 20 14:33:24 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Dec 20 14:33:31 2008 Subject: Lockups and panics during multiuser boot In-Reply-To: <494D2C64.1030105@classic-games.com> References: <494D2C64.1030105@classic-games.com> Message-ID: <20081220223319.GE2038@deviant.kiev.zoral.com.ua> On Sat, Dec 20, 2008 at 11:33:24AM -0600, Greg Miller wrote: > > After upgrading to 7.1RC1, I found I could only boot single-user without > a panic or a lockup. After bisecting recent changes on RELENG_7, I > found that the problem occurs after 2008.10.29.15.00.00 and before > 2008.10.29.18.00.00 You forgot to add the actual panic messages and backtraces. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081220/a69a4f1f/attachment.pgp From nslay at comcast.net Sat Dec 20 22:08:00 2008 From: nslay at comcast.net (Nathan Lay) Date: Sat Dec 20 22:08:07 2008 Subject: Very serious cooling issues CURRENT/STABLE Message-ID: <494DDA1B.6050206@comcast.net> Hi list(s) Early in the year I noticed CURRENT failed to cool my frankenstein Thinkpad T40 (built from T40/40p parts) under load. The system would shut down from critically high temperatures while building a port. I did nothing special with ACPI. I thought nothing of it since, after all, I rebuilt a broken T40 from T40p parts. Today, however, I noticed that a very recent STABLE build failed to keep my T43 cool while building ports. It reached temperatures of 97, 98, 99C. It used to reach a max temperature of 80C while building a port (idling temperature is ~ 45C). It behaved normally from 5.3 all the way through 7.0. To remedy both issues, I had to underclock the processor (via dev.cpu) and force the fan to its highest (I'm running 533MHz shy of the processor's full potential, with a fan level of 7 to keep the temperature at ~75C). I've always suspected FreeBSD's ACPI didn't work properly on Thinkpad T series laptops (I have T40, T41, T42 and T43) as it could never fully use the fan (Windows XP can rev the fan far higher than acpi_ibm's level 7). Between STABLE and CURRENT...something seems very wrong. These systems never had cooling issues with FreeBSD before. I attached my dmesg and sysctl for hw.acpi, dev.acpi_ibm, and dev.cpu for both machines. I don't think the latter three pieces of information will be useful but I could be wrong. Let me know if there is any other information I can provide. Best Regards, Nathan Lay -------------- next part -------------- hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 76.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 94.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 99.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 600 hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 hw.acpi.cpu.cx_lowest: C1 -------------- next part -------------- dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 415 dev.acpi_ibm.0.lcd_brightness: 7 dev.acpi_ibm.0.volume: 12 dev.acpi_ibm.0.mute: 1 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4684 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 0 dev.acpi_ibm.0.thermal: 76 51 40 61 35 -1 28 -1 -------------- next part -------------- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Wed Dec 10 04:09:36 EST 2008 nslay@LIGHTBULB.LOCAL:/usr/obj/usr/src/sys/LIGHTBULB module_register: module g_journal already exists! Module g_journal failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.86GHz (1862.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x100000 real memory = 1609433088 (1534 MB) avail memory = 1567776768 (1495 MB) This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ kbd1 at kbdmux0 netsmb_dev: loaded ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 5ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 11 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xc0000000-0xc7ffffff,0xb0100000-0xb010ffff irq 11 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] Initialized radeon 1.25.0 20060524 pcib2: irq 11 at device 28.0 on pci0 pci2: on pcib2 bge0: mem 0xb0200000-0xb020ffff irq 11 at device 0.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:15:58:09:1b:e7 bge0: [ITHREAD] pcib3: irq 11 at device 28.2 on pci0 pci3: on pcib3 uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 11 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xb0000000-0xb00003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci11: on pcib4 cbb0: mem 0xb4000000-0xb4000fff irq 11 at device 0.0 on pci11 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] pcm0: port 0x1c00-0x1cff,0x1880-0x18bf mem 0xb0000800-0xb00009ff,0xb0000400-0xb00004ff irq 11 at device 30.2 on pci0 pcm0: [ITHREAD] pcm0: pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x1000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd1800-0xd27ff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x278-0x27f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ugen0: on uhub2 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounter "TSC" frequency 1862138034 Hz quality 800 Timecounters tick every 1.000 msec The GEOM class JOURNAL is already loaded. ZFS filesystem version 6 ZFS storage pool version 6 ad0: 57231MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 GEOM_JOURNAL: Journal 273940673: ad0s1e contains data. GEOM_JOURNAL: Journal 273940673: ad0s1e contains journal. GEOM_JOURNAL: Journal ad0s1e clean. Trying to mount root from ufs:/dev/ad0s1a ath0: mem 0xb4010000-0xb401ffff irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:18:4d:8e:51:42 ath0: mac 7.9 phy 4.5 radio 5.6 WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. bridge0: Ethernet address: 96:e4:69:df:24:5b info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] -------------- next part -------------- dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1333 dev.cpu.0.freq_levels: 1866/27000 1632/23625 1600/23700 1400/20737 1333/20400 1166/17850 1066/17100 932/14962 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% -------------- next part -------------- hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 37.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 89.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 93.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 600 hw.acpi.battery.life: 69 hw.acpi.battery.time: 31 hw.acpi.battery.state: 1 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 0 hw.acpi.cpu.cx_lowest: C1 -------------- next part -------------- dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 3328 dev.acpi_ibm.0.lcd_brightness: 7 dev.acpi_ibm.0.volume: 8 dev.acpi_ibm.0.mute: 1 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 0 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 37 36 31 37 29 -1 25 -1 -------------- next part -------------- dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 1600/-1 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% 0.00% -------------- next part -------------- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r186194: Tue Dec 16 22:46:15 EST 2008 nslay@BOTTLE.LOCAL:/usr/obj/usr/src/sys/BOTTLE WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1600MHz (598.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf Features2=0x180 real memory = 804651008 (767 MB) avail memory = 774418432 (738 MB) kbd1 at kbdmux0 ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xe0000000-0xe7ffffff,0xc0100000-0xc010ffff irq 11 at device 0.0 on pci1 uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc0000000-0xc00003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [FILTER] em0: port 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: [FILTER] em0: Ethernet address: 00:09:6b:5f:3a:d0 pci2: at device 2.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c00-0xc0000dff,0xc0000800-0xc00008ff irq 11 at device 31.5 on pci0 pcm0: [ITHREAD] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x278-0x27f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 Timecounter "TSC" frequency 598063934 Hz quality 800 Timecounters tick every 1.000 msec ad0: 38154MB at ata0-master UDMA100 cardbus1: Expecting link target, got 0x0 cardbus1: Expecting link target, got 0x0 ral0: mem 0xc0218000-0xc021ffff irq 11 at device 0.0 on cardbus1 ral0: MAC/BBP RT2561C, RF RT2527 ral0: [ITHREAD] acd0: CDRW at ata1-master UDMA33 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s1a lock order reversal: 1st 0xc3c6f044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xc3dec7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c087b43a,c3b6f918,c05eaa75,4,c0876c93,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0876c93,c3c29728,c3c2ea70,c3b6f974,...) at kdb_backtrace+0x29 _witness_debugger(c087df1b,c3dec7ac,c0871dfd,c3c2ea70,c0884d51,...) at _witness_debugger+0x25 witness_checkorder(c3dec7ac,1,c0884d51,81f,0,...) at witness_checkorder+0x82b __lockmgr_args(c3dec7ac,200501,c3dec7c8,0,0,...) at __lockmgr_args+0x228 ffs_lock(c3b6fa80,c05ea81b,c08a09cb,200501,c3dec754,...) at ffs_lock+0x82 VOP_LOCK1_APV(c08f5740,c3b6fa80,c3c6ce24,c0905280,c3dec754,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c3dec754,200501,c0884d51,81f,4,...) at _vn_lock+0x5e vget(c3dec754,200501,c3c6cd80,4b4,0,...) at vget+0xcb vnode_pager_lock(c14442e8,0,c089dfa4,127,c3b6fc18,...) at vnode_pager_lock+0x1d9 vm_fault(c3c6f000,80db000,2,8,80db000,...) at vm_fault+0x1e9 trap_pfault(5,0,c08a93ff,2e7,c,...) at trap_pfault+0xf5 trap(c3b6fd38) at trap+0x26f calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- wlan0: Ethernet address: 00:11:50:dc:4c:ed ral0: need multicast update callback ral0: need multicast update callback From kamikaze at bsdforen.de Sun Dec 21 01:55:08 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Dec 21 01:55:16 2008 Subject: Kernel not mounting root In-Reply-To: References: Message-ID: <494E1258.9010500@bsdforen.de> Marius N?nnerich wrote: > Hi all, > > I did cvsup to 7-STABLE yesterday, build, installed and booted a new > kernel then buildworld. > Then I noticed that my PS/2 keyboard is not working at the loader menu > so I booted multiuser and did the make installworld part from there. > Then I tried to reboot but now it hangs after the line > Trying to mount root from ufs:/dev/ad4s1a > > It sits there for at least 10min. I tried so far: > - Installing 7.1-beta2 on another hd and booting it, it works. > - Copied that kernel to the old hd > - Moved kernel.old to kernel > - fsck everything > - mounted everything from the old hd under /mnt, chroot into that, installworld > > Anyone else seeing this or has an idea what to do next? > > Kind regards > Marius I encountered something similar with RC-1, yesterday. The installer entered the devices ad4s4a till ad4s4f instead of ad4s3a till ad4s3f into the fstab file. The annoying problem that you need to mount /usr to run /rescue/vi, because it needs a file from /usr/share is also still present. This makes /rescue/vi nearly useless in my opinion and honestly, ee is really awkward to use. Regards From nakal at web.de Sun Dec 21 03:04:39 2008 From: nakal at web.de (Martin) Date: Sun Dec 21 03:04:46 2008 Subject: Very serious cooling issues CURRENT/STABLE In-Reply-To: <494DDA1B.6050206@comcast.net> References: <494DDA1B.6050206@comcast.net> Message-ID: <20081221120427.2dfde4b1@zelda.local> Am Sun, 21 Dec 2008 00:54:35 -0500 schrieb Nathan Lay : > Hi list(s) > Early in the year I noticed CURRENT failed to cool my frankenstein > Thinkpad T40 (built from T40/40p parts) under load. The system would > shut down from critically high temperatures while building a port. I > did nothing special with ACPI. I thought nothing of it since, after > all, I rebuilt a broken T40 from T40p parts. Today, however, I > noticed that a very recent STABLE build failed to keep my T43 cool > while building ports. It reached temperatures of 97, 98, 99C. Hallo Nathan, I can confirm this on a T60p. My notebooks shuts down since I use 7.0 at 101?C. I have written a script that throttles the CPU if it gets above 75?C. I have to use it when I'm building world or ports. Btw, I have reported the problem here a some time ago [1]. I have received some feedback that IBM/Lenovo uses wrong cooling strategy placing the CPU and the VGA under one single cooled surface and using too much thermal grease. On the other hand I have also emphasized that the fan should be able to have about 800rpm more at the temperature of 80?C, but this has been ignored so far. This is why I have never had any problems running "the other common operating systems" and I have put them under heavy load. They don't exceed 85?C. > It > used to reach a max temperature of 80C while building a port (idling > temperature is ~ 45C). It behaved normally from 5.3 all the way > through 7.0. To remedy both issues, I had to underclock the > processor (via dev.cpu) and force the fan to its highest (I'm running > 533MHz shy of the processor's full potential, with a fan level of 7 > to keep the temperature at ~75C). I have one further hint for you. The VGA is running very hot on FreeBSD (~75?C when idle), because it is not able to throttle the GPU and its voltage. Maybe you've had a working setup for your GPU before and you even did not notice? Did you change your Xorg drivers? > I've always suspected FreeBSD's > ACPI didn't work properly on Thinkpad T series laptops (I have T40, > T41, T42 and T43) as it could never fully use the fan (Windows XP can > rev the fan far higher than acpi_ibm's level 7). Between STABLE and > CURRENT...something seems very wrong. These systems never had > cooling issues with FreeBSD before. The fan is running definitely too slow. On my system, too. Thanks, Martin References: [1] http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/042812.html From marius at nuenneri.ch Sun Dec 21 03:22:52 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Sun Dec 21 03:23:09 2008 Subject: Kernel not mounting root In-Reply-To: <494E1258.9010500@bsdforen.de> References: <494E1258.9010500@bsdforen.de> Message-ID: On Sun, Dec 21, 2008 at 10:54 AM, Dominic Fandrey wrote: > Marius N?nnerich wrote: >> Hi all, >> >> I did cvsup to 7-STABLE yesterday, build, installed and booted a new >> kernel then buildworld. >> Then I noticed that my PS/2 keyboard is not working at the loader menu >> so I booted multiuser and did the make installworld part from there. >> Then I tried to reboot but now it hangs after the line >> Trying to mount root from ufs:/dev/ad4s1a >> >> It sits there for at least 10min. I tried so far: >> - Installing 7.1-beta2 on another hd and booting it, it works. >> - Copied that kernel to the old hd >> - Moved kernel.old to kernel >> - fsck everything >> - mounted everything from the old hd under /mnt, chroot into that, installworld >> >> Anyone else seeing this or has an idea what to do next? >> >> Kind regards >> Marius > > I encountered something similar with RC-1, yesterday. The installer entered > the devices ad4s4a till ad4s4f instead of ad4s3a till ad4s3f into the fstab > file. That is different ad4s1a would be the right partition in my case. From onemda at gmail.com Sun Dec 21 05:14:27 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Dec 21 05:14:33 2008 Subject: Very serious cooling issues CURRENT/STABLE In-Reply-To: <494DDA1B.6050206@comcast.net> References: <494DDA1B.6050206@comcast.net> Message-ID: <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> On 12/21/08, Nathan Lay wrote: > acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 37.0C > hw.acpi.thermal.tz0.active: -1 Is this one ever changed? > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 89.5C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 93.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 This one means that coling will never be used, why: my output looks like this: hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: 5 > hw.acpi.thermal.tz0._TC2: 4 > hw.acpi.thermal.tz0._TSP: 600 You can play with all thermal values once you enable: hw.acpi.thermal.user_override But acpi may redo such values again after some time. You only real workaround is to use modified acpi ASL: it is explained in handbook. In my case I fixed in that way bogus kernel message "_CRT value is absurd, ignored". -- Paul From smithi at nimnet.asn.au Sun Dec 21 07:09:06 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Dec 21 07:09:14 2008 Subject: Very serious cooling issues CURRENT/STABLE In-Reply-To: <20081221120427.2dfde4b1@zelda.local> References: <494DDA1B.6050206@comcast.net> <20081221120427.2dfde4b1@zelda.local> Message-ID: <20081222004228.G29108@sola.nimnet.asn.au> On Sun, 21 Dec 2008, Martin wrote: > Am Sun, 21 Dec 2008 00:54:35 -0500 > schrieb Nathan Lay : > > > Hi list(s) > > Early in the year I noticed CURRENT failed to cool my frankenstein > > Thinkpad T40 (built from T40/40p parts) under load. The system would > > shut down from critically high temperatures while building a port. I > > did nothing special with ACPI. I thought nothing of it since, after > > all, I rebuilt a broken T40 from T40p parts. Today, however, I > > noticed that a very recent STABLE build failed to keep my T43 cool > > while building ports. It reached temperatures of 97, 98, 99C. Nathan, have you cleaned out airpaths, heatsinks, thermal paste etc recently? Just checking; people have reported drastic improvements. > Hallo Nathan, > > I can confirm this on a T60p. My notebooks shuts down since I use 7.0 > at 101?C. I have written a script that throttles the CPU if it gets > above 75?C. I have to use it when I'm building world or ports. > > Btw, I have reported the problem here a some time ago [1]. I have > received some feedback that IBM/Lenovo uses wrong cooling strategy > placing the CPU and the VGA under one single cooled surface and using > too much thermal grease. We keep hearing that, but that shouldn't affect the T40 or T43 .. so addressing the maximum fan speed issue below is more a 'last resort'; overriding and lowering the _PSV value for .tz0 might help via p4tcc? > On the other hand I have also emphasized that the fan should be able to > have about 800rpm more at the temperature of 80?C, but this has been > ignored so far. This is why I have never had any problems running "the > other common operating systems" and I have put them under heavy load. > They don't exceed 85?C. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpi_support/acpi_ibm.c?rev=1.17 Comments in acpi_ibm_sysctl_get, case ACPI_IBM_METHOD_FANLEVEL: say that setting bit 6 (IBM_EC_MASK_FANDISENGAGED) of IBM_EC_FANSTATUS overrides the fan speed limit, which linux allows, 'doze too apparently. acpi_ibm_sysctl_set currently rejects fan levels higher than 7, ie does not allow running the fan disengaged, but that's something you could fix at your own risk .. it's been suggested that this could wear the fan out more quickly, so I guess acpi_ibm is tending to be conservative here. It doesn't look hard to at least allow values with bit 6 set (ie 64-127) in acpi_ibm_sysctl_set, case ACPI_IBM_METHOD_FANLEVEL: and a bit more work to preserve that bit in the _get values. It looks like you might need to set the fan in manual mode too (dev.acpi_ibm.0.fan=0) but test! > > It > > used to reach a max temperature of 80C while building a port (idling > > temperature is ~ 45C). It behaved normally from 5.3 all the way > > through 7.0. To remedy both issues, I had to underclock the > > processor (via dev.cpu) and force the fan to its highest (I'm running > > 533MHz shy of the processor's full potential, with a fan level of 7 > > to keep the temperature at ~75C). > > I have one further hint for you. The VGA is running very hot on > FreeBSD (~75?C when idle), because it is not able to throttle the GPU > and its voltage. Maybe you've had a working setup for your GPU before > and you even did not notice? Did you change your Xorg drivers? > > > I've always suspected FreeBSD's > > ACPI didn't work properly on Thinkpad T series laptops (I have T40, > > T41, T42 and T43) as it could never fully use the fan (Windows XP can > > rev the fan far higher than acpi_ibm's level 7). Between STABLE and > > CURRENT...something seems very wrong. These systems never had > > cooling issues with FreeBSD before. > > The fan is running definitely too slow. On my system, too. I guess if I was having overheating issues with my T23 and was confident with C and its debugging, I'd have a go at this .. but I am neither .. > Thanks, > Martin > > > References: > [1] > http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/042812.html cheers, Ian From nakal at web.de Sun Dec 21 07:47:10 2008 From: nakal at web.de (Martin) Date: Sun Dec 21 07:47:18 2008 Subject: FreeBSD 7.1-RC1 Available... In-Reply-To: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> Message-ID: <20081221164707.4538402a@zelda.local> Am Tue, 09 Dec 2008 21:39:26 -0500 schrieb Ken Smith : > FreeBSD 7.1-RC1 is now available, the first of the Release Candidates. > There will be at least one more Release Candidate before the release > so the release itself is likely around 3 weeks from now IF no new > show-stoppers are uncovered during testing. Hi, I have just tried to use the RC1-livefs-CD (i386). It seems, I cannot boot it. I tried 3 different CD-R(W)s and three different drives (even one SCSI drive!). -- Martin From nslay at comcast.net Sun Dec 21 08:55:16 2008 From: nslay at comcast.net (Nathan Lay) Date: Sun Dec 21 08:55:24 2008 Subject: Very serious cooling issues CURRENT/STABLE In-Reply-To: <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> References: <494DDA1B.6050206@comcast.net> <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> Message-ID: <494E712B.802@comcast.net> Paul B. Mahol wrote: > On 12/21/08, Nathan Lay wrote: > >> acpi.thermal.min_runtime: 0 >> hw.acpi.thermal.polling_rate: 10 >> hw.acpi.thermal.user_override: 0 >> hw.acpi.thermal.tz0.temperature: 37.0C >> hw.acpi.thermal.tz0.active: -1 >> > Is this one ever changed? > > >> hw.acpi.thermal.tz0.passive_cooling: 1 >> hw.acpi.thermal.tz0.thermal_flags: 0 >> hw.acpi.thermal.tz0._PSV: 89.5C >> hw.acpi.thermal.tz0._HOT: -1 >> hw.acpi.thermal.tz0._CRT: 93.0C >> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 >> > > This one means that coling will never be used, why: > my output looks like this: > hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 > > >> hw.acpi.thermal.tz0._TC1: 5 >> hw.acpi.thermal.tz0._TC2: 4 >> hw.acpi.thermal.tz0._TSP: 600 >> > > You can play with all thermal values once you enable: > hw.acpi.thermal.user_override > > But acpi may redo such values again after some time. > You only real workaround is to use modified acpi ASL: > it is explained in handbook. > > In my case I fixed in that way bogus kernel > message "_CRT value is absurd, ignored". > > > hw.acpi never displayed thermal values for some reason. However, after loading acpi_ibm, I can query those values without a problem dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 I'm not sure the critical temperature (99C) is a problem, but what I have observed is you should never be near it. None of these thinkpads got over 80C under load with FreeBSD installed until recently. ACPI's ASL does not appear to be the problem as it has worked correctly in the past. Best Regards, Nathan Lay From onemda at gmail.com Sun Dec 21 09:19:34 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Dec 21 09:19:41 2008 Subject: Very serious cooling issues CURRENT/STABLE In-Reply-To: <494E712B.802@comcast.net> References: <494DDA1B.6050206@comcast.net> <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> <494E712B.802@comcast.net> Message-ID: <3a142e750812210919s3bd5876q8f45759f1228906b@mail.gmail.com> On 12/21/08, Nathan Lay wrote: > Paul B. Mahol wrote: >> On 12/21/08, Nathan Lay wrote: >> >>> acpi.thermal.min_runtime: 0 >>> hw.acpi.thermal.polling_rate: 10 >>> hw.acpi.thermal.user_override: 0 >>> hw.acpi.thermal.tz0.temperature: 37.0C >>> hw.acpi.thermal.tz0.active: -1 >>> >> Is this one ever changed? >> >> >>> hw.acpi.thermal.tz0.passive_cooling: 1 >>> hw.acpi.thermal.tz0.thermal_flags: 0 >>> hw.acpi.thermal.tz0._PSV: 89.5C >>> hw.acpi.thermal.tz0._HOT: -1 >>> hw.acpi.thermal.tz0._CRT: 93.0C >>> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 >>> >> >> This one means that coling will never be used, why: >> my output looks like this: >> hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 >> >> >>> hw.acpi.thermal.tz0._TC1: 5 >>> hw.acpi.thermal.tz0._TC2: 4 >>> hw.acpi.thermal.tz0._TSP: 600 >>> >> >> You can play with all thermal values once you enable: >> hw.acpi.thermal.user_override >> >> But acpi may redo such values again after some time. >> You only real workaround is to use modified acpi ASL: >> it is explained in handbook. >> >> In my case I fixed in that way bogus kernel >> message "_CRT value is absurd, ignored". >> >> >> > hw.acpi never displayed thermal values for some reason. However, after > loading acpi_ibm, I can query those values without a problem > dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 > > I'm not sure the critical temperature (99C) is a problem, but what I > have observed is you should never be near it. None of these thinkpads > got over 80C under load with FreeBSD installed until recently. ACPI's > ASL does not appear to be the problem as it has worked correctly in the > past. Until recenty when, can you point into svn revision? If the same overheat happens with acpi disabled that I dont see how freebsd acpi can help you. -- Paul From a134qaed at gmail.com Sun Dec 21 12:27:55 2008 From: a134qaed at gmail.com (Dylan Cochran) Date: Sun Dec 21 12:28:02 2008 Subject: Hard lock on 7.1-RC1 Message-ID: I'm hitting a strange lockup on 7.1-RC1, where some socket operations seem to stall, as well as basic file operations. The only reproducable way I have of triggering it is by doing multiple inserts into phpmyadmin on lighttpd+fastcgi php5 + mysql51-server, though this isn't the only thing which triggers it, just the only one which is semi reliable. I've also reproduced this on another machine, set up specifically to rule out any machine specific problems (as they have different drive controllers, one uses gjournal, etc). I inititially built a kernel with SW_WATCHDOG, and attempted to use watchdogd and DDB to get an output from show locks, but the watchdogd hasn't panicked the machine, so at least devfs is still unlocked; I'm not able to get physical access to the machine until monday. The bug was introduced as far as I can tell, between 7.1-BETA2 and 7.1-RC1. Any suggestions on what I can test for tommorow? From nslay at comcast.net Sun Dec 21 14:16:04 2008 From: nslay at comcast.net (Nathan Lay) Date: Sun Dec 21 14:16:16 2008 Subject: Very serious cooling issues CURRENT/STABLE In-Reply-To: <3a142e750812210919s3bd5876q8f45759f1228906b@mail.gmail.com> References: <494DDA1B.6050206@comcast.net> <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> <494E712B.802@comcast.net> <3a142e750812210919s3bd5876q8f45759f1228906b@mail.gmail.com> Message-ID: <494EA2E2.9050909@comcast.net> Paul B. Mahol wrote: > On 12/21/08, Nathan Lay wrote: > >> Paul B. Mahol wrote: >> >>> On 12/21/08, Nathan Lay wrote: >>> >>> >>>> acpi.thermal.min_runtime: 0 >>>> hw.acpi.thermal.polling_rate: 10 >>>> hw.acpi.thermal.user_override: 0 >>>> hw.acpi.thermal.tz0.temperature: 37.0C >>>> hw.acpi.thermal.tz0.active: -1 >>>> >>>> >>> Is this one ever changed? >>> >>> >>> >>>> hw.acpi.thermal.tz0.passive_cooling: 1 >>>> hw.acpi.thermal.tz0.thermal_flags: 0 >>>> hw.acpi.thermal.tz0._PSV: 89.5C >>>> hw.acpi.thermal.tz0._HOT: -1 >>>> hw.acpi.thermal.tz0._CRT: 93.0C >>>> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 >>>> >>>> >>> This one means that coling will never be used, why: >>> my output looks like this: >>> hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 >>> >>> >>> >>>> hw.acpi.thermal.tz0._TC1: 5 >>>> hw.acpi.thermal.tz0._TC2: 4 >>>> hw.acpi.thermal.tz0._TSP: 600 >>>> >>>> >>> You can play with all thermal values once you enable: >>> hw.acpi.thermal.user_override >>> >>> But acpi may redo such values again after some time. >>> You only real workaround is to use modified acpi ASL: >>> it is explained in handbook. >>> >>> In my case I fixed in that way bogus kernel >>> message "_CRT value is absurd, ignored". >>> >>> >>> >>> >> hw.acpi never displayed thermal values for some reason. However, after >> loading acpi_ibm, I can query those values without a problem >> dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 >> >> I'm not sure the critical temperature (99C) is a problem, but what I >> have observed is you should never be near it. None of these thinkpads >> got over 80C under load with FreeBSD installed until recently. ACPI's >> ASL does not appear to be the problem as it has worked correctly in the >> past. >> > > Until recenty when, can you point into svn revision? > > If the same overheat happens with acpi disabled that I dont see how > freebsd acpi can help you. > > > Ok, I ran portupgrade on both systems with ACPI disabled. I do not experience any overheating issues. The thinkpads also do not feel very hot while building large ports like jdk16 and gcc42 as they do when ACPI is enabled. As I said, the laptops only started recently overheating. The T40 started overheating when CURRENT was installed and the T43 started overheating on a more recent STABLE. I'll try to pinpoint exactly which STABLE build experienced this. Best Regards, Nathan Lay From smallpox at gmail.com Sun Dec 21 16:14:46 2008 From: smallpox at gmail.com (smallpox) Date: Sun Dec 21 16:14:53 2008 Subject: kernel panic on 7.0-p6 Message-ID: <494ED53F.1050603@gmail.com> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1002b fault code = supervisor read, page not present instruction pointer = 0x20:0xc0909ee7 stack pointer = 0x28:0xeb8cba9c frame pointer = 0x28:0xeb8cbaf4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1257 (httpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 1d22h29m29s Physical memory: 2025 MB Dumping 308 MB: 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06eef57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ef219 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc095730c in trap_fatal (frame=0xeb8cba5c, eva=65579) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0957590 in trap_pfault (frame=0xeb8cba5c, usermode=0, eva=65579) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0957f3c in trap (frame=0xeb8cba5c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc093debb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0909ee7 in vm_page_splay (pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:576 #8 0xc090a49d in vm_page_remove (m=0xc14faca0) at /usr/src/sys/vm/vm_page.c:718 #9 0xc090a6e1 in vm_page_free_toq (m=0xc14faca0) at /usr/src/sys/vm/vm_page.c:1291 #10 0xc090a8b6 in vm_page_free (m=0xc14faca0) at /usr/src/sys/vm/vm_page.c:498 #11 0xc0908ea5 in vm_object_terminate (object=0xcd8656c8) at /usr/src/sys/vm/vm_object.c:647 #12 0xc0909713 in vm_object_deallocate (object=0xcd8656c8) at /usr/src/sys/vm/vm_object.c:580 #13 0xc0901a38 in vm_map_delete (map=Variable "map" is not available. ) at /usr/src/sys/vm/vm_map.c:2315 #14 0xc0901ac1 in vm_map_remove (map=0xca0f02b8, start=0, end=3217031168) at /usr/src/sys/vm/vm_map.c:2423 #15 0xc09041bf in vmspace_exit (td=0xca672c60) at /usr/src/sys/vm/vm_map.c:324 #16 0xc06cda1a in exit1 (td=0xca672c60, rv=0) at /usr/src/sys/kern/kern_exit.c:294 #17 0xc06ced6d in sys_exit (td=Could not find the frame base for "sys_exit". ) at /usr/src/sys/kern/kern_exit.c:98 #18 0xc09578e5 in syscall (frame=0xeb8cbd38) at /usr/src/sys/i386/i386/trap.c:1035 #19 0xc093df20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- second crash 36 hours later. -- [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xfff77a88 fault code = supervisor write, page not present instruction pointer = 0x20:0xc090bee2 stack pointer = 0x28:0xe8df4bf4 frame pointer = 0x28:0xe8df4c24 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 43 (pagedaemon) trap number = 12 panic: page fault cpuid = 1 Uptime: 1d3h12m13s Physical memory: 2025 MB Dumping 321 MB: 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06eef57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ef219 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc095730c in trap_fatal (frame=0xe8df4bb4, eva=4294408840) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0957590 in trap_pfault (frame=0xe8df4bb4, usermode=0, eva=4294408840) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0957f3c in trap (frame=0xe8df4bb4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc093debb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc090bee2 in vm_page_cache (m=0xc1a6c860) at /usr/src/sys/vm/vm_page.c:1556 #8 0xc090df9a in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:862 #9 0xc06cef79 in fork_exit (callout=0xc090d450 , arg=0x0, frame=0xe8df4d38) at /usr/src/sys/kern/kern_fork.c:781 #10 0xc093df30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 -- crash a few hours later -- [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xac2248 fault code = supervisor read, page not present instruction pointer = 0x20:0xc075c0a6 stack pointer = 0x28:0xeb2468ac frame pointer = 0x28:0xeb2468d4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27668 (httpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 9h16m52s Physical memory: 2025 MB Dumping 297 MB: 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06eef57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ef219 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc095730c in trap_fatal (frame=0xeb24686c, eva=11280968) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0957590 in trap_pfault (frame=0xeb24686c, usermode=0, eva=11280968) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0957f3c in trap (frame=0xeb24686c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc093debb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc075c0a6 in vfs_hash_get (mp=0xc8abf29c, hash=17431063, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_hash.c:72 #8 0xc08dae99 in ffs_vget (mp=0xc8abf29c, ino=17431063, flags=2, vpp=0xeb2469bc) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1320 #9 0xc08e74ad in ufs_lookup (ap=0xeb246a00) at /usr/src/sys/ufs/ufs/ufs_lookup.c:573 #10 0xc096b8c2 in VOP_CACHEDLOOKUP_APV (vop=0xc0a74720, a=0xeb246a00) at vnode_if.c:153 #11 0xc0756bb0 in vfs_cache_lookup (ap=0xeb246a84) at vnode_if.h:83 #12 0xc096d506 in VOP_LOOKUP_APV (vop=0xc0a74c40, a=0xeb246a84) at vnode_if.c:99 #13 0xc075d3f1 in lookup (ndp=0xeb246ba8) at vnode_if.h:57 #14 0xc075e0ff in namei (ndp=0xeb246ba8) at /usr/src/sys/kern/vfs_lookup.c:219 #15 0xc076bbed in kern_stat (td=0xc9830a50, path=0x29b066d8
, pathseg=UIO_USERSPACE, sbp=0xeb246c18) at /usr/src/sys/kern/vfs_syscalls.c:2109 #16 0xc076bd9f in stat (td=0xc9830a50, uap=0xeb246cfc) at /usr/src/sys/kern/vfs_syscalls.c:2093 #17 0xc09578e5 in syscall (frame=0xeb246d38) at /usr/src/sys/i386/i386/trap.c:1035 #18 0xc093df20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit -- this is in about 3-4 days, it is a production server. /etc/sysctl.conf contains kern.ipc.nmbclusters=65536 kern.maxfiles=35000 net.inet.icmp.icmplim=500 /boot/loader.conf conTAINED vm.pmap.shpgperproc=1000 as i get these errors: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. -- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p6 #0: Mon Dec 15 21:39:02 PST 2008 root@dual2.box.com:/usr/obj/usr/src/sys/DUAL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2137522176 (2038 MB) avail memory = 2082156544 (1985 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] 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 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr a280a2806000a28 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr a280a2806000a28 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x30b0-0x30b7 mem 0xd0000000-0xd00fffff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 16 at device 28.4 on pci0 pci6: on pcib2 em0: port 0x4000-0x401f mem 0xd0100000-0xd011ffff irq 16 at device 0.0 on pci6 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:91:d0:48 em0: [FILTER] pcib3: irq 17 at device 28.5 on pci0 pci7: on pcib3 em1: port 0x5000-0x501f mem 0xd0200000-0xd021ffff irq 17 at device 0.0 on pci7 em1: Using MSI interrupt em1: Ethernet address: 00:30:48:91:d0:49 em1: [FILTER] uhci0: port 0x3000-0x301f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 17 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd0500000-0xd05003ff irq 16 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci8: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding disabled, default to accept, logging limited to 10000 packets/entry by default ad2: 238475MB at ata1-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad2s1a WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted - this system was migrated from another company, apache is configured for 4000 clients.. server worked well, now it only does 5-20mbit. i have another server doing 130mbit with same config, except for vm.pmap.shpgperproc=1000 on the bigger server is vm.pmap.shpgperproc=2000 and it's a QUAD processor, same amount of ram. i have since removed the loader.conf file and will test to see if that has anything to do with it. during the last crash, i had set kern.ipc.shm_use_phys=1 and it crashed a few hours later. now i'm not sure if any of this is linked.. for all i know, it could be a client doing something. any suggestions would be appreciated. thank you. From received at postcard.org Mon Dec 22 05:24:28 2008 From: received at postcard.org (received@postcard.org) Date: Mon Dec 22 05:24:34 2008 Subject: You have just received a virtual postcard from a friend ! Message-ID: <20081222123703.E202845042@techno01.bek.jp> You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://www.loaps.com/postcard.gif.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://www.loaps.com/postcard.gif.exe From patfbsd at davenulle.org Mon Dec 22 05:38:24 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Mon Dec 22 05:38:32 2008 Subject: FreeBSD 7.1-RC1 Available... In-Reply-To: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> Message-ID: <20081222143820.7f799014@baby-jane> Le Tue, 09 Dec 2008 21:39:26 -0500, Ken Smith a ?crit : Hello, > So... Two show-stoppers, one Security Advisory, and one "Gee. Did we > really implement that new interface that way? That needs a bit more > work." later... Can we know what were these two show-stoppers? In the past there were some informations about show stoppers on the FreeBSD's web site but i can't find them. I'm asking because i run 7.1 since the -PRERELEASE and it looks solid as a rock. Thank you all for this new release. Regards. From agh at coolrhaug.com Mon Dec 22 07:54:01 2008 From: agh at coolrhaug.com (Alastair Hogge) Date: Mon Dec 22 07:54:10 2008 Subject: Steelseries Ikari laser mouse. Message-ID: <200812230022.46822.agh@coolrhaug.com> Hey, I have an Ikari laser mouse, and the blasted thing does not work on my system. I've rebuilt a kernel with USB_DEBUG and umsdebug defined. The console will spew some text if I move the mouse or if I click the mouse buttons, however no pointer appears/or does anything, you can see the spew in my dmesg below. Look out for the lines "ums_intr..." uname: FreeBSD madcat 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Dec 23 01:44:32 WST 2008 agh@madcat:/usr/obj/usr/src/sys/MADCAT i38 dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #2: Tue Dec 23 01:44:32 WST 2008 agh@madcat:/usr/obj/usr/src/sys/MADCAT Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz (2999.97-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd> AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 4 real memory = 2146435072 (2047 MB) avail memory = 2088128512 (1991 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xc2000000-0xc2ffffff,0xa0000000-0xbfffffff,0xc0000000-0xc1ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: irq 16 at device 6.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.2 on pci2 pci4: on pcib4 hptrr0: port 0xd000-0xd0ff mem 0xc3100000-0xc31fffff irq 16 at device 4.0 on pci4 hptrr: adapter at PCI 4:4:0, IRQ 16 em0: port 0xf0e0-0xf0ff mem 0xc3400000-0xc341ffff,0xc3424000-0xc3424fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:c0:8c:09:75 uhci0: port 0xf0c0-0xf0df irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xf0a0-0xf0bf irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xf080-0xf09f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc3425400-0xc34257ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: waiting for BIOS to give up control usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) uhci3: port 0xf060-0xf07f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xf040-0xf05f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xf020-0xf03f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xc3425000-0xc34253ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: waiting for BIOS to give up control usb7: timed out waiting for BIOS usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 fwohci0: mem 0xc3300000-0xc3300fff irq 19 at device 0.0 on pci5 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:90:27:00:02:2b:34:b9 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:90:27:2b:34:b9 fwe0: Ethernet address: 02:90:27:2b:34:b9 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12d0000 fwip0: on firewire0 fwip0: Firewire address: 00:90:27:00:02:2b:34:b9 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf170-0xf17f,0xf160-0xf16f irq 19 at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xf150-0xf157,0xf140-0xf143,0xf130-0xf137,0xf120-0xf123,0xf110-0xf11f,0xf100-0xf10f irq 19 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] cpu0 on motherboard est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1 on motherboard est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2 on motherboard est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3 on motherboard est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est3 attach returned 6 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xccfff,0xcd000-0xd47ff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub8: on uhub0 uhub8: 4 ports with 4 removable, self powered ukbd0: on uhub0 kbd2 at ukbd0 ums0: on uhub0 ums_attach: bLength=7 bDescriptorType=5 bEndpointAddress=2-in bmAttributes=3 wMaxPacketSize=5 bInterval=10 ums0: mouse has no X report device_attach: ums0 attach returned 6 Timecounters tick every 1.000 msec hptrr: start channel [0,1] hptrr: start channel [0,2] hptrr: start channel [0,3] hptrr: start channel [0,4] hptrr: start channel [0,5] hptrr: channel [0,1] started successfully hptrr: channel [0,2] started successfully hptrr: channel [0,3] started successfully hptrr: channel [0,4] started successfully hptrr: channel [0,5] started successfully hptrr0: [GIANT-LOCKED] hptrr0: [ITHREAD] firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) da0 at hptrr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device acd0: DVDR at ata0-master SATA150 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 ad6: 114473MB at ata3-master SATA150 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/ad6s1a Loading configuration files. kernel dumps on /dev/da0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart . swapon: adding /dev/da0s1b as swap device Starting file system checks: /dev/ad6s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1a: clean, 219646 free (1422 frags, 27278 blocks, 0.3% fragmentation) /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 188978 free (1418 frags, 23445 blocks, 0.6% fragmentation) /dev/da0s1g: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1g: clean, 30775181 free (51725 frags, 3840432 blocks, 0.0% fragmentation) /dev/ad6s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1e: clean, 1982833 free (41 frags, 247849 blocks, 0.0% fragmentation) /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1f: clean, 5073397 free (1957 frags, 633930 blocks, 0.0% fragmentation) /dev/ad6s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1f: clean, 41156397 free (230869 frags, 5115691 blocks, 0.4% fragmentation) /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1d: clean, 5077072 free (40 frags, 634629 blocks, 0.0% fragmentation) /dev/ad6s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1d: clean, 310707 free (23579 frags, 35891 blocks, 2.4% fragmentation) /dev/da0s1h: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1h: clean, 108196201 free (147161 frags, 13506130 blocks, 0.1% fragmentation) /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1e: clean, 2487040 free (1992 frags, 310631 blocks, 0.1% fragmentation) Setting hostuuid: 00020003-0004-0005-0006-000700080009. Setting hostid: 0x81f4ec68. Mounting local file systems: . Setting hostname: madcat. net.inet6.ip6.auto_linklocal: 1 -> 0 vfs.usermount: 0 -> 1 kern.ipc.shmmax: 33554432 -> 67108864 kern.ipc.shmall: 8192 -> 32768 compat.linux.osrelease: 2.4.2 -> 2.6.16 kern.ipc.shm_allow_removed: 0 -> 1 em0: no link ... . . . got link DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.4 -- renewal in 43200 seconds. lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 metric 0 mtu 1500 options=1db ether 00:1c:c0:8c:09:75 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet 100baseTX status: active route: writing to routing socket : File exists add net default: gateway 192.168.1.1: route already in table Additional routing options: . Starting devd. Configuring keyboard: . Additional IP options: . Mounting NFS file systems: . ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib /usr/local/lib/compat /usr/local/lib/gcc/i386-portbld-freebsd7.0/3.4.6 /usr/local/lib/gnash /usr/local/lib/graphviz /usr/local/lib/kde3 /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/wine /usr/local/lib/zsh a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Clearing /tmp. Creating and/or trimming log files: . Starting syslogd. Checking for core dump on /dev/da0s1b... savecore: no dumps found Initial i386 initialization: . Additional ABI support: linux . Removing stale Samba tdb files: done Starting lighttpd. Starting dbus. Starting local daemons: . Updating motd . Mounting late file systems: . Starting bsdstats. Posting monthly OS statistics to rpt.bsdstats.org Configuring syscons: blanktime . Starting sshd. Starting cron. Local package initialization: rtc . /etc/rc.d/sysctl: WARNING: sysctl hw.snd.verbose does not exist. /etc/rc.d/sysctl: WARNING: sysctl hw.snd.maxautovchans does not exist. Starting inetd. Starting background file system checks in 60 seconds. Tue Dec 23 01:51:38 WST 2008 ums0: on uhub8 ums_attach: bLength=7 bDescriptorType=5 bEndpointAddress=1-in bmAttributes=3 wMaxPacketSize=8 bInterval=1 ums0: 7 buttons and Z dir. ums_attach: sc=0xc58c2800 ums_attach: X 64/16 ums_attach: Y 80/16 ums_attach: Z 96/8 ums_attach: B1 56/1 ums_attach: B2 57/1 ums_attach: B3 58/1 ums_attach: B4 59/1 ums_attach: B5 60/1 ums_attach: B6 61/1 ums_attach: B7 62/1 ums_attach: size=8, id=1 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 d0 ff 10 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 9b ff 30 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 cf ff 45 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 03 00 33 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 3b 00 17 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 4f 00 ed ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 29 00 e1 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 07 00 e3 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fc ff f3 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f6 ff f8 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f8 ff f8 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 06 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f2 ff fe ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 e9 ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 e2 ff fc ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ef ff fa ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 eb ff ed ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f5 ff e8 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fb ff ed ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 05 00 e2 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 07 00 f5 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 11 00 f3 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 18 00 f9 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 1e 00 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 21 00 0f 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 35 00 21 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 1a 00 15 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 08 00 18 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fa ff 18 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 eb ff 15 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ee ff 0f 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff fd ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 02 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 01 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 01 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 04 08 00 fe ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 04 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 04 04 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 02 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 03 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums0: at uhub8 port 2 (addr 4) disconnected ums_intr: sc=0xc58c2800 status=6 ums_intr: data = 02 00 ff ff 00 00 00 00 ums0: disconnected ums0: detached Dec 23 01:53:12 madcat moused: unable to open /dev/ums0: No such file or directory umass0: on uhub8 da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: 1918MB (3928064 512 byte sectors: 255H 63S/T 244C) GEOM_LABEL: Label for provider da1s1 is msdosfs/FAT32_FS. GEOM_LABEL: Label msdosfs/FAT32_FS removed. Thanks -Alastair From kensmith at cse.Buffalo.EDU Mon Dec 22 08:34:41 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Mon Dec 22 08:34:48 2008 Subject: FreeBSD 7.1-RC1 Available... In-Reply-To: <20081222143820.7f799014@baby-jane> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> <20081222143820.7f799014@baby-jane> Message-ID: <1229963671.29842.40.camel@bauer.cse.buffalo.edu> On Mon, 2008-12-22 at 14:38 +0100, Patrick Lamaizi?re wrote: > Le Tue, 09 Dec 2008 21:39:26 -0500, > Ken Smith a ?crit : > > Hello, > > > So... Two show-stoppers, one Security Advisory, and one "Gee. Did we > > really implement that new interface that way? That needs a bit more > > work." later... > > Can we know what were these two show-stoppers? In the past there were > some informations about show stoppers on the FreeBSD's web site but i > can't find them. > > I'm asking because i run 7.1 since the -PRERELEASE and it looks solid > as a rock. > The two show-stoppers, which were worked through quite a while ago (like I said before its been a couple other issues since then not necessarily directly related to stability) were: - routing table locking issues, which would under the "wrong" set of circumstances cause panics, most often it seemed during boot. It seemed to depend on how active things like the arp entries were, etc (as in didn't always cause a panic for any given machine as it booted, it was somewhat random). - huge performance drop on certain things that got traced to changes made to malloc after 7.0. Sorry about the lack of something on the Web site. We're working on ways to fix issues like that during the next release. The past couple of releases we've known I have communication issues that I meant to try and fix when things quieted down after the release. But then things were quiet and that sorta never happened. So we're starting to work out what needs to be done differently during 7.2-RELEASE now while the list of things not being done is freshly in everyones' mind instead of waiting to talk about it later... -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081222/94b4ab01/attachment.pgp From ericlin at tamama.org Mon Dec 22 08:44:55 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Mon Dec 22 08:45:02 2008 Subject: amd(8) cores dump when load high Message-ID: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> Dear listers, We currently found that amd frequently cores dump while loading is high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to 7.1-PRERELEASE. I have read -stable and svn log of 7-STABLE, but can not found a report or a solution. Did anyone have the same issue? Thank you very much. # uname -a FreeBSD bsd1 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8: Fri Dec 19 22:44:22 CST 2008 root@bsd1:/usr/obj/usr/src/sys/KERNEL amd64 # dmesg pid 51645 (amd), uid 0: exited on signal 11 (core dumped) pid 52077 (amd), uid 0: exited on signal 11 (core dumped) pid 52083 (amd), uid 0: exited on signal 11 (core dumped) pid 53876 (amd), uid 0: exited on signal 11 (core dumped) pid 56444 (amd), uid 0: exited on signal 11 (core dumped) # gdb `which amd` /amd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `amd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000080053ef8c in _rtld_thread_init () from /libexec/ld-elf.so.1 (gdb) bt #0 0x000000080053ef8c in _rtld_thread_init () from /libexec/ld-elf.so.1 #1 0x00000008005321c5 in _rtld_thread_init () from /libexec/ld-elf.so.1 #2 0x0000000800535bdc in _rtld_thread_init () from /libexec/ld-elf.so.1 #3 0x0000000800529a98 in _rtld_error () from /libexec/ld-elf.so.1 #4 0x000000080052be8e in dlsym () from /libexec/ld-elf.so.1 #5 0x000000080052c1a1 in dlclose () from /libexec/ld-elf.so.1 #6 0x000000080070fb34 in __cxa_finalize () from /lib/libc.so.7 #7 0x00000008006c5f8f in exit () from /lib/libc.so.7 #8 0x000000000041537c in ?? () #9 0x0000000000407a82 in ?? () #10 0x0000000000407be3 in ?? () #11 0x0000000000415282 in ?? () #12 0x000000000040af8f in ?? () #13 0x0000000000410ccc in ?? () #14 0x0000000000406919 in ?? () #15 0x000000000040460e in ?? () #16 0x000000080054b000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000008 in ?? () #20 0x00007fffffffee78 in ?? () #21 0x00007fffffffee86 in ?? () #22 0x00007fffffffee89 in ?? () #23 0x00007fffffffee8c in ?? () #24 0x00007fffffffee92 in ?? () #25 0x00007fffffffee95 in ?? () #26 0x00007fffffffee99 in ?? () #27 0x00007fffffffee9e in ?? () #28 0x0000000000000000 in ?? () #29 0x00007fffffffeea6 in ?? () #30 0x00007fffffffeeb1 in ?? () #31 0x00007fffffffeebb in ?? () #32 0x00007fffffffeecf in ?? () #33 0x00007fffffffeeda in ?? () #34 0x00007fffffffeee5 in ?? () #35 0x00007fffffffeef2 in ?? () #36 0x00007fffffffef00 in ?? () #37 0x00007fffffffef0c in ?? () #38 0x00007fffffffef63 in ?? () #39 0x00007fffffffef70 in ?? () #40 0x00007fffffffef93 in ?? () #41 0x00007fffffffefa2 in ?? () #42 0x00007fffffffefb1 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000003 in ?? () #45 0x0000000000400040 in ?? () #46 0x0000000000000004 in ?? () #47 0x0000000000000038 in ?? () #48 0x0000000000000005 in ?? () #49 0x0000000000000007 in ?? () #50 0x0000000000000006 in ?? () #51 0x0000000000001000 in ?? () #52 0x0000000000000008 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000009 in ?? () #55 0x0000000000404580 in ?? () #56 0x0000000000000007 in ?? () #57 0x0000000800525000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x6962732f7273752f in ?? () #75 0x702d00646d612f6e in ?? () #76 0x36646d61006b2d00 in ?? () #77 0x6c6c6100782d0034 in ?? () #78 0x6d610074656e2f00 in ?? () #79 0x55530070616d2e64 in ?? () #80 0x303d4449475f4f44 in ?? () #81 0x6f723d5245535500 in ?? () #82 0x3d4c49414d00746f in ?? () #83 0x69616d2f7261762f in ?? () #84 0x4800746f6f722f6c in ?? () #85 0x6f6f722f3d454d4f in ?? () #86 0x555f4f4455530074 in ?? () #87 0x474f4c00303d4449 in ?? () #88 0x6f6f723d454d414e in ?? () #89 0x414e524553550074 in ?? () #90 0x00746f6f723d454d in ?? () #91 0x6e6f633d4d524554 in ?? () #92 0x4854415000353273 in ?? () #93 0x2f3a6e6962732f3d in ?? () #94 0x7273752f3a6e6962 in ?? () #95 0x752f3a6e6962732f in ?? () #96 0x2f3a6e69622f7273 in ?? () #97 0x656d61672f727375 in ?? () #98 0x6c2f7273752f3a73 in ?? () #99 0x6962732f6c61636f in ?? () #100 0x6c2f7273752f3a6e in ?? () #101 0x6e69622f6c61636f in ?? () #102 0x622f746f6f722f3a in ?? () #103 0x49505f4352006e69 in ?? () #104 0x0031353539323d44 in ?? () #105 0x4d4f435f4f445553 in ?? () #106 0x74652f3d444e414d in ?? () #107 0x612f642e63722f63 in ?? () #108 0x617473657220646d in ?? () #109 0x4c4c454853007472 in ?? () #110 0x73632f6e69622f3d in ?? () #111 0x555f4f4455530068 in ?? () #112 0x746f6f723d524553 in ?? () #113 0x6f722f3d44575000 in ?? () #114 0x000000000000746f in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () #119 0x0000000000000000 in ?? () #120 0x0000000000000000 in ?? () #121 0x0000000000000000 in ?? () #122 0x0000000000000000 in ?? () #123 0x0000000000000000 in ?? () #124 0x0000000000000000 in ?? () #125 0x0000000000000000 in ?? () #126 0x0000000000000000 in ?? () #127 0x0000000000000000 in ?? () #128 0x0000000000000000 in ?? () #129 0x0000000000000000 in ?? () #130 0x0000000000000000 in ?? () ... (skip) #623 0x0000000000000000 in ?? () #624 0x0000000000000000 in ?? () #625 0x0000000000000000 in ?? () #626 0x0000000000000000 in ?? () #627 0x247c8d48002454ff in ?? () #628 0x01a1c0c748006a10 in ?? () #629 0x66fdebf4050f0000 in ?? () #630 0x9066669066669066 in ?? () #631 0x00007fffffffecc8 in ?? () #632 0x0000000000000008 in ?? () #633 0x00007fffffffed10 in ?? () #634 0x000000000000000e in ?? () From dindin at yandex-team.ru Mon Dec 22 08:53:36 2008 From: dindin at yandex-team.ru (Denis Barov) Date: Mon Dec 22 08:53:44 2008 Subject: is libc building is broken in RELENG_7 ? Message-ID: <20081222164232.GH76620@sepulca.yandex.ru> csup file: host=cvsup7.ru.FreeBSD.org *default base=/var/db *default prefix=/opt/usr/RELENG_7 *default release=cvs tag=RELENG_7 *default delete use-rel-suffix *default compress src-all empty /etc/make.conf, clean /usr/obj, /usr/src symlink to /opt/usr/RELENG_7/src operating system: FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Mar 6 21:26:17 UTC 2008 root@hostname:/pt/usr/obj/opt/usr/src/sys/W7_AMD64_ULE amd64 building world: make -C /usr/src/ -j 16 buildworld TARGET_ARCH=amd64 TARGET=amd64 Finished succesful, installing world into separate directory: make -C /usr/src/ installworld TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/mnt/crossinstall Finished successful. Then I try to mergemaster standart configuration files: mergemaster -a -i -m/usr/src/ -D/mnt/crossinstall -t/tmp/different_temproot I have an error in building libc: cc -O2 -fno-strict-aliasing -pipe -I/opt/usr/RELENG_7/src/lib/libc/include -I/opt/usr/RELENG_7/src/lib/libc/../../include -I/opt/usr/RELENG_7/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/opt/usr/RELENG_7/src/lib/libc/../../contrib/gdtoa -DINET6 -I/place/vartmp/temproot.1222.19.24.54/usr/obj/opt/usr/RELENG_7/src/lib/libc -I/opt/usr/RELENG_7/src/lib/libc/resolv -DPOSIX_MISTAKE -I/opt/usr/RELENG_7/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/opt/usr/RELENG_7/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c: In function '__fcntl_compat': /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:44: error: storage size of 'ofl' isn't known /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:69: error: 'F_OGETLK' undeclared (first use in this function) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:69: error: (Each undeclared identifier is reported only once /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:69: error: for each function it appears in.) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:76: error: 'struct flock' has no member named 'l_sysid' /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:81: error: 'F_OSETLK' undeclared (first use in this function) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:84: error: 'F_OSETLKW' undeclared (first use in this function) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:44: warning: unused variable 'ofl' *** Error code 1 Stop in /opt/usr/RELENG_7/src/lib/libc. *** Error code 1 Stop in /opt/usr/RELENG_7/src/lib. *** Error code 1 Stop in /opt/usr/RELENG_7/src. *** Error code 1 Stop in /opt/usr/RELENG_7/src. *** FATAL ERROR: Cannot 'cd' to /opt/usr/RELENG_7/src/ and install files to the temproot environment I tried to build libc manualy, (make -C /usr/src/lib/libc , clearing /usr/obj before ), I have same trouble. I'm wrong somwhere or libc compilation somehow broken? -- Cheers Denis Barov From admin at stardothosting.com Mon Dec 22 09:21:01 2008 From: admin at stardothosting.com (SDH Admin) Date: Mon Dec 22 09:21:08 2008 Subject: amd(8) cores dump when load high In-Reply-To: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> Message-ID: <003301c96455$bb4467f0$31cd37d0$@com> > #634 0x000000000000000e in ?? () What is running when the load is high? OR specifically what is the server doing that is generating the load? Kevin K. Systems Administrator www.stardothosting.com From ericlin at tamama.org Mon Dec 22 09:33:22 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Mon Dec 22 09:33:29 2008 Subject: amd(8) cores dump when load high In-Reply-To: <003301c96455$bb4467f0$31cd37d0$@com> References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <003301c96455$bb4467f0$31cd37d0$@com> Message-ID: <47713ee10812220933u4d20bbe8vef57b7c27570f4bb@mail.gmail.com> Hi, We are running some daily report (php scripts), get data from remote mysql database. And we are running daily backup script, to copy local data to remote NFS Server at the same time. On Tue, Dec 23, 2008 at 12:52 AM, SDH Admin wrote: > > >> #634 0x000000000000000e in ?? () > > > > What is running when the load is high? OR specifically what is the server > doing that is generating the load? > > > > > > Kevin K. > Systems Administrator > www.stardothosting.com > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From bballou at litchfieldsd.org Mon Dec 22 12:25:36 2008 From: bballou at litchfieldsd.org (Bruce H. Ballou) Date: Mon Dec 22 12:25:49 2008 Subject: ver 4.2 won't allow save because it can't see 2.2T disk drive Message-ID: Hello, I am green with FreeBSD, but I have a system (ver 4.2) which I can not update right now, but I am connected to a StoreVault data storage device which has a 2.2T disk, so it is showing up as to large to save data to. df -h shows the following Filesystem Size Used Avail Capacity Mounted on 10.9.1.15:/vol/exports/lsdist/1-storage 222G -715.7G 937G -323% /storage/1 I need to patch this until I can update the system, any pointers to where (if there is one) to get the patch for this, and installation instructions. Any help will be greatly apprecieated. Thanx, Bruce Ballou Technology Director SAU #27 ________________________________________________________________________ This Email has been scanned for all viruses by PAETEC Email Scanning Services, utilizing MessageLabs proprietary SkyScan infrastructure. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.paetec.com. ________________________________________________________________________ From admin at stardothosting.com Mon Dec 22 13:20:59 2008 From: admin at stardothosting.com (SDH Admin) Date: Mon Dec 22 13:21:07 2008 Subject: ver 4.2 won't allow save because it can't see 2.2T disk drive In-Reply-To: References: Message-ID: <006401c96477$3dd8e440$b98aacc0$@com> >I need to patch this until I can update the system, any pointers to >where (if there is one) to get the patch for this, and installation >instructions. What is the 2.2T disk formatted as? Can you give more details on your hardware (storage device and the 4.2 server), as well as posting your dmesg output. --- Kevin K. Systems Administrator www.stardothosting.com From brett at lariat.net Mon Dec 22 19:20:08 2008 From: brett at lariat.net (Brett Glass) Date: Mon Dec 22 19:20:28 2008 Subject: FreeBSD 7.1 - Actual schedule? Message-ID: <200812230307.UAA14987@lariat.net> The schedule for release of FreeBSD 7.1 at http://www.freebsd.org/releases/7.1R/schedule.html is so woefully out of date that we've given up waiting and built a bunch of systems with 7.0-RELEASE, even though clients were asking us to put 7.1-RELEASE on them. Where can one track the actual progress toward a release? There appears to be no "to do" list (as there was for previous releases), and therefore no way to easily keep abreast of progress, snags, etc. --Brett Glass From kensmith at cse.Buffalo.EDU Mon Dec 22 19:42:08 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Mon Dec 22 19:42:15 2008 Subject: FreeBSD 7.1 - Actual schedule? In-Reply-To: <200812230307.UAA14987@lariat.net> References: <200812230307.UAA14987@lariat.net> Message-ID: <1230002844.13438.25.camel@neo.cse.buffalo.edu> On Mon, 2008-12-22 at 20:07 -0700, Brett Glass wrote: > The schedule for release of FreeBSD 7.1 at > > http://www.freebsd.org/releases/7.1R/schedule.html > > is so woefully out of date that we've given up waiting and built > a bunch of systems with 7.0-RELEASE, even though clients were > asking us to put 7.1-RELEASE on them. Where can one track the > actual progress toward a release? There appears to be no > "to do" list (as there was for previous releases), and therefore > no way to easily keep abreast of progress, snags, etc. > Yeah, sorry. I've apologized a couple times here about the communication issues and indicated its actively being worked on for next time. This time is something of a lost cause at this point. I just sent out the request that the builds for 7.1-RC2 begin, which unless something *really* *really* catastrophic comes along will be the last of the public tests. If that's the way it goes 7.1-REL will happen about 1.5 to 2 weeks from now, maybe a bit less. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081223/b5b90e2c/attachment.pgp From yanefbsd at gmail.com Mon Dec 22 21:56:01 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Dec 22 21:56:09 2008 Subject: -m32 broken on bi-arch amd64 systems? Message-ID: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> Hi guys, I think I may have found an issue today with our bi-endian structure, and I wanted to make sure whether or not it was an already known issue (-m32 is broken for gcc with lib32/libgcc.a): [root@fbsd-7-test]# gcc -o boo boo.c # Compiles [root@fbsd-7-test]# gcc -m32 -o boo boo.c /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc [root@fbsd-7-test]# file /usr/lib32/libgcc_s.so.1 /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, stripped [root@fbsd-7-test]# uname -a FreeBSD fbsd-7-test.gateway.2wire.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sun Nov 23 16:19:09 UTC 2008 root@fbsd-7-test.gateway.2wire.net:/usr/obj/usr/src/sys/STARR amd64 I wish I had my amd64 CURRENT machine in front of me to confirm this, but I don't. Please keep me CC'ed as I am not subscribed to either amd64@ or stable@. Thanks! -Garrett From a134qaed at gmail.com Mon Dec 22 22:18:23 2008 From: a134qaed at gmail.com (Dylan Cochran) Date: Mon Dec 22 22:18:30 2008 Subject: Hard lock on 7.1-RC1 In-Reply-To: References: Message-ID: On Sun, Dec 21, 2008 at 3:05 PM, Dylan Cochran wrote: > I'm hitting a strange lockup on 7.1-RC1, where some socket operations > seem to stall, as well as basic file operations. The only reproducable > way I have of triggering it is by doing multiple inserts into > phpmyadmin on lighttpd+fastcgi php5 + mysql51-server, though this > isn't the only thing which triggers it, just the only one which is > semi reliable. I've also reproduced this on another machine, set up > specifically to rule out any machine specific problems (as they have > different drive controllers, one uses gjournal, etc). > > I inititially built a kernel with SW_WATCHDOG, and attempted to use > watchdogd and DDB to get an output from show locks, but the watchdogd > hasn't panicked the machine, so at least devfs is still unlocked; I'm > not able to get physical access to the machine until monday. > > The bug was introduced as far as I can tell, between 7.1-BETA2 and 7.1-RC1. > > Any suggestions on what I can test for tommorow? > I updated the kernel source to RELENG_7_1 as of a few hours ago, and built with DEBUG_VFS_LOCKS as well. Luckily the backtrace included the operating it was at before the watchdog, which seems to be kern_sendfile(). I'm no expert at kernel debugging, so any assistance on tracking this down further would be greatly appreciated. And, as promised, here is the output of script after the watchdog induced panic: Script started on Tue Dec 23 01:05:56 2008 # cu -l cua01 interrupt total irq4: sio0 623 irq6: fdc0 1 irq17: fwohci0 3 irq18: rl0 uhci2++ 60718 irq23: rl1 ehci0 206 cpu0: timer 514596 Total 576147 KDB: stack backtrace: db_trace_self_wrapper(c0b55b52,e66e0ae0,c07615e9,c0b50617,8ca93,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b50617,8ca93,0,c41a7690,2,...) at kdb_backtrace+0x29 hardclock(0,c07ff29d,0,0,4,...) at hardclock+0x1f9 lapic_handle_timer(e66e0b08) at lapic_handle_timer+0x9c Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc07ff29d, esp = 0xe66e0b48, ebp = 0xe66e0c34 --- kern_sendfile(c41a7690,e66e0cfc,0,0,0,...) at kern_sendfile+0x90d do_sendfile(e66e0d2c,c0aba265,c41a7690,e66e0cfc,20,...) at do_sendfile+0xb1 sendfile(c41a7690,e66e0cfc,20,16,e66e0d2c,...) at sendfile+0x13 syscall(e66e0d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x282cb0cb, esp = 0xbfbfc7cc, ebp = 0xbfbfe848 --- KDB: enter: watchdog timeout [thread pid 1288 tid 100060 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> show lock db> p show all proc pid ppid pgrp uid state wmesg wchan cmd 1600 902 902 0 R watchdogd 1470 1469 1470 0 S+ ttyin 0xc418fc10 csh 1469 1 1469 0 Ss+ wait 0xc46032b8 login 1468 1 1468 0 Ss+ ttyin 0xc41ac810 getty 1427 1 1427 0 Ss nanslp 0xc0c7dc44 cron 1420 1 1420 0 Ss select 0xc0c88eb8 sshd 1419 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1418 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1417 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1416 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1415 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1414 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1413 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1412 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1411 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1410 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1409 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1408 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1407 1289 1289 80 SJ accept 0xc445ab9a php-cgi --More-- 1406 1289 1289 80 SJ accept 0xc445ab9a php-cgi --More-- 1405 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1404 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1403 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1402 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1401 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1400 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1399 1300 1300 80 RJ php-cgi 1398 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1397 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1396 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1395 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1394 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1393 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1392 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1391 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1390 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1389 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1388 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1322 1 1322 25 SsJ pause 0xc4562b40 sendmail 1316 1 1316 0 RsJ sendmail --More-- 1306 1 1306 0 SsJ select 0xc0c88eb8 sshd 1300 1288 1300 80 SsJ wait 0xc43beae0 initial thread 1289 1288 1289 80 SsJ wait 0xc4564000 initial thread 1288 1 1287 80 RJ CPU 0 lighttpd 1286 1173 1170 88 R+J (threaded) mysqld 100114 S sigwait 0xe67a2be0 mysqld 100090 S ucond 0xc4359580 mysqld 100092 RunQ mysqld 100091 RunQ mysqld 100089 S ucond 0xc43598c0 mysqld 100088 S ucond 0xc4358c80 mysqld 100087 S ucond 0xc4094780 mysqld 100086 S ucond 0xc4359140 mysqld 100049 S select 0xc0c88eb8 initial thread 1173 1 1170 88 S+J wait 0xc43be2b8 sh 920 1 920 0 R+ (threaded) venti 100072 S ucond 0xc4358300 venti 100071 S accept 0xc445b03a venti 100070 S ucond 0xc4358200 venti 100069 S ucond 0xc4095980 venti --More-- 100068 S ucond 0xc41b1e00 venti 100067 S ucond 0xc4358100 venti 100066 S ucond 0xc4358280 venti 100065 S ucond 0xc41a45c0 venti 100064 S accept 0xc445a1da venti 100063 RunQ venti 100053 RunQ venti 902 1 902 0 Ss wait 0xc4343570 watchdogd 891 1 891 102 Rs gmond 770 1 770 0 Ss select 0xc0c88eb8 devd 338 1 338 65 Ss select 0xc0c88eb8 dhclient 322 1 49 0 S+ select 0xc0c88eb8 dhclient 48 0 0 0 SL sdflush 0xc0c95228 [softdepflush] 47 0 0 0 RL [syncer] 46 0 0 0 SL vlruwt 0xc4342000 [vnlru] 45 0 0 0 SL psleep 0xc0c89324 [bufdaemon] 44 0 0 0 SL pgzero 0xc0c95e00 [pagezero] 43 0 0 0 SL psleep 0xc0c95a18 [vmdaemon] 42 0 0 0 SL psleep 0xc0c959e0 [pagedaemon] 41 0 0 0 SL waiting_ 0xc0c8b0b4 [sctp_iterator] --More-- 40 0 0 0 WL [irq7: ppbus0 ppc0] 39 0 0 0 WL [irq1: atkbd0] 38 0 0 0 WL [irq15: ata1] 37 0 0 0 WL [irq14: ata0] 36 0 0 0 WL [swi0: sio] 35 0 0 0 SL - 0xc418d83c [fdc0] 34 0 0 0 SL - 0xc4097000 [fw0_probe] 33 0 0 0 SL - 0xc408c200 [fw0_taskq] 32 0 0 0 SL usbevt 0xc4013210 [usb4] 31 0 0 0 WL [irq23: rl1 ehci0] 30 0 0 0 SL usbevt 0xc407f210 [usb3] 29 0 0 0 SL usbevt 0xc406c210 [usb2] 28 0 0 0 WL [irq18: rl0 uhci2++] 27 0 0 0 SL usbevt 0xc405c210 [usb1] 26 0 0 0 WL [irq19: uhci1] 25 0 0 0 SL usbtsk 0xc0c7b234 [usbtask-dr] 24 0 0 0 SL usbtsk 0xc0c7b220 [usbtask-hc] 23 0 0 0 SL usbevt 0xc4024210 [usb0] 22 0 0 0 WL [irq16: uhci0 uhci3] 21 0 0 0 WL [irq9: acpi0] --More-- 20 0 0 0 WL [swi6: task queue] 19 0 0 0 WL [swi6: Giant taskq] 18 0 0 0 SL - 0xc3fe3700 [thread taskq] 17 0 0 0 WL [swi5: +] 9 0 0 0 SL - 0xc3fe3880 [acpi_task_2] 8 0 0 0 SL - 0xc3fe3880 [acpi_task_1] 7 0 0 0 SL - 0xc3fe3880 [acpi_task_0] 16 0 0 0 WL [swi2: cambio] 6 0 0 0 SL ccb_scan 0xc0c4b054 [xpt_thrd] 5 0 0 0 SL - 0xc3fe3a80 [kqueue taskq] 15 0 0 0 SL - 0xc0c7da74 [yarrow] 4 0 0 0 SL - 0xc0c7b62c [g_down] 3 0 0 0 SL - 0xc0c7b628 [g_up] 2 0 0 0 SL - 0xc0c7b620 [g_event] 14 0 0 0 WL [swi3: vm] 13 0 0 0 WL [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 1 0 1 0 SLs wait 0xc3f16ae0 [init] 10 0 0 0 SL audit_wo 0xc0c94c64 [audit] --More-- 0 0 0 0 SLs sched 0xc0c7b6e0 [swapper] db> Killed From bsdlist at cogeco.ca Tue Dec 23 04:41:43 2008 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Tue Dec 23 04:41:53 2008 Subject: 7.1-PRERELEASE: arcmsr write performance problem In-Reply-To: <494AED9E.9090900@cogeco.ca> References: <4949673B.2070701@elehost.com> <494AED9E.9090900@cogeco.ca> Message-ID: <494FABC2.1020804@cogeco.ca> > I actually find that running Wusage 8.0 a few times even with nice-19 > may be implicated in getting the system to spiral downwards. I hesitate > to mention this as it seems to be working fine on another 7.X server. I > believe that Wusage is tied to 6.X libraries and I wonder if somehow > this may initiate the problem. I also have another sio/com based program > running every few minutes which is also connected to the 6.X library > (scom thermal application for temperature monitoring) and turning both > of these off seems to help. I am going to try a 24 hour period without > either of these two running after a fresh reboot and we will see if this > is indeed one source to my abominable problem. > > Once the system spirals down into its locking then the io performance > never seems to recover unless I reboot it or somehow find the process > that is locked and kill it. > So after the testing period with the scom not running and wusage not running I still have the problem albeit less often. The stress on the system seems to bring it forward as notice by my other tests. It is easiest to see on httpd and a stop needs to be run try to free up the system. Dec 19 07:32:43 /usr/local/sbin/apachectl -k stop Dec 19 07:33:35 kernel: pid 31376 (httpd), uid 80: exited on signal 11 Dec 19 07:33:35 kernel: pid 31194 (httpd), uid 80: exited on signal 11 Dec 19 07:33:36 kernel: pid 31469 (httpd), uid 80: exited on signal 11 Dec 19 07:33:36 kernel: pid 31754 (httpd), uid 80: exited on signal 11 Dec 19 07:33:37 kernel: pid 31168 (httpd), uid 80: exited on signal 11 Dec 19 07:33:37 kernel: pid 31753 (httpd), uid 80: exited on signal 11 Dec 19 07:33:38 kernel: pid 31763 (httpd), uid 80: exited on signal 11 Dec 19 07:33:38 kernel: pid 31748 (httpd), uid 80: exited on signal 11 Its relatively easy to get this restarted but when it is something else in the system it is hard to locate and I have to do a reboot to release the blockage. When it is apache that has "locked" I have to kill it as a graceful will not work. The majority of the processes are in UFS state when it happens. If there was a quick way to determine which one has "locked" the system that would be so helpful as a temporary workaround. I am going to try to replace the motherboard next, This is one of the last hardware replacements to isolate this as a hardware problem. From mikej at rogers.com Tue Dec 23 08:34:59 2008 From: mikej at rogers.com (Mike Jakubik) Date: Tue Dec 23 08:35:06 2008 Subject: bce(4) and rx errors In-Reply-To: <4944D3A3.8040505@delphij.net> References: <20081210160325.GA72838@mr-happy.com> <4944D3A3.8040505@delphij.net> Message-ID: On Sun, December 14, 2008 4:36 am, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Gents, > > I have not yet talked this with David but it looks like this patch would > make it disappear. > > Cheers, I have been running my production systems for about a week now with this patch, interrupts are low and rx errors reports are gone, thanks Xin. P.S. I'm still having problems with my application, but at this point i'm not sure whether it has anything to do with the driver, for what its worth here is the error which causes it to stop accepting new connection. wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | Exception in thread "Thread-0" java.nio.channels.IllegalBlockingModeException wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at sun.nio.ch.ServerSocketAdaptor.accept(ServerSocketAdaptor.java:86) wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at com.precyse.chat.service.connector.ServerSocketChannelConnector.registerSelection(ServerSocketChannelConnector.java:404) wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at com.precyse.chat.service.connector.ServerSocketChannelConnector.run(ServerSocketChannelConnector.java:148) From customersolutions--ysm at cc.yahoo-inc.com Tue Dec 23 08:56:29 2008 From: customersolutions--ysm at cc.yahoo-inc.com (customersolutions--ysm@cc.yahoo-inc.com) Date: Tue Dec 23 08:56:45 2008 Subject: Alert Notification: Billing Pending Inactivation in Account Message-ID: <1-JAY-01mgsQQIqrfFz00001671@mail.jaygroupllc.com> Renew Your Account Now ! Dear Advertiser, This is your official notification from Yahoo! Inc. that the service(s) listed below will be deactivated and deleted if not renewed immediately. As the Primary Contact, you must renew the service(s) listed below or it will be deactivated and deleted. [1]Renew Now your Yahoo Sponsored Search services. SERVICE: Yahoo Sponsored Search EXPIRATION: December, 23 2008 Thank you for using Yahoo Inc service. We appreciate your business and the opportunity to serve you. Yahoo Inc. Sponsored Search Service *Note : Please do not reply to this Customer Service e-mail. Copyright ©2008 Yahoo! Inc. All rights reserved. References 1. http://www.yahoobusinessupdate.com/marketingsolutions/adui/renew/login/loadSignin.htm From maciej at suszko.eu Tue Dec 23 09:04:19 2008 From: maciej at suszko.eu (Maciej Suszko) Date: Tue Dec 23 09:04:26 2008 Subject: -m32 broken on bi-arch amd64 systems? In-Reply-To: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> Message-ID: <20081223173608.068fe9d8@suszko.eu> "Garrett Cooper" wrote: > Hi guys, > I think I may have found an issue today with our bi-endian > structure, and I wanted to make sure whether or not it was an already > known issue (-m32 is broken for gcc with lib32/libgcc.a): > > [root@fbsd-7-test]# gcc -o boo boo.c # Compiles > [root@fbsd-7-test]# gcc -m32 -o boo boo.c > /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching > for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when > searching for -lgcc /usr/bin/ld: cannot find -lgcc > [root@fbsd-7-test]# file /usr/lib32/libgcc_s.so.1 > /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, > version 1 (FreeBSD), dynamically linked, stripped > [root@fbsd-7-test]# uname -a > FreeBSD fbsd-7-test.gateway.2wire.net 7.1-PRERELEASE FreeBSD > 7.1-PRERELEASE #0: Sun Nov 23 16:19:09 UTC 2008 > root@fbsd-7-test.gateway.2wire.net:/usr/obj/usr/src/sys/STARR amd64 > > I wish I had my amd64 CURRENT machine in front of me to confirm > this, but I don't. > Please keep me CC'ed as I am not subscribed to either amd64@ or > stable@. Thanks! > -Garrett I also noticed that behavior, shouldn't compiler/linker look into /usr/lib32 without additional -B switch? -- regards, Maciej Suszko. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081223/d2044bbe/signature.pgp From ericlin at tamama.org Tue Dec 23 09:15:55 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Tue Dec 23 09:16:02 2008 Subject: Process stuck in STOP state Message-ID: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> Dear listers, Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve them with apache 2.2 (worker MPM + php fastcgi mode). At least one time a day the apache process is stuck in the STOP state and is unkillable. gdb won't attach to the process, either. Does anyone have any similar issue? I have found that may be because of libkse, but we use libthr now. Thank you all in advance. From ericlin at tamama.org Tue Dec 23 09:17:16 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Tue Dec 23 09:17:24 2008 Subject: Process stuck in STOP state In-Reply-To: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> References: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> Message-ID: <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> > Dear listers, > > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve > them with apache 2.2 (worker MPM + php fastcgi mode). Sorry. we use -STABLE now. event# uname -a FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 01:45:42 CST 2008 root@event:/usr/obj/usr/src/sys/KERNEL amd64 From delphij at delphij.net Tue Dec 23 09:19:19 2008 From: delphij at delphij.net (Xin LI) Date: Tue Dec 23 09:19:27 2008 Subject: bce(4) and rx errors In-Reply-To: References: <20081210160325.GA72838@mr-happy.com> <4944D3A3.8040505@delphij.net> Message-ID: <49511D8A.2000304@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Mike, Mike Jakubik wrote: > On Sun, December 14, 2008 4:36 am, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, Gents, >> >> I have not yet talked this with David but it looks like this patch would >> make it disappear. >> >> Cheers, > > I have been running my production systems for about a week now with this > patch, interrupts are low and rx errors reports are gone, thanks Xin. > > P.S. I'm still having problems with my application, but at this point i'm > not sure whether it has anything to do with the driver, for what its worth > here is the error which causes it to stop accepting new connection. > > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | Exception in > thread "Thread-0" java.nio.channels.IllegalBlockingModeException > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at > sun.nio.ch.ServerSocketAdaptor.accept(ServerSocketAdaptor.java:86) > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at > com.precyse.chat.service.connector.ServerSocketChannelConnector.registerSelection(ServerSocketChannelConnector.java:404) > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at > com.precyse.chat.service.connector.ServerSocketChannelConnector.run(ServerSocketChannelConnector.java:148) Thanks for the feedback. Could you check netstat -m and/or vmstat -z to see if there is any mbuf exhaustion issue? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklRHYoACgkQi+vbBBjt66AlTACeOz59K8geIlaJTIjzf6dB0xHR UwMAoLCy9bTTha8fu0Y6v1SzzMk5JuOH =wh5l -----END PGP SIGNATURE----- From kabaev at gmail.com Tue Dec 23 09:54:13 2008 From: kabaev at gmail.com (Alexander Kabaev) Date: Tue Dec 23 09:54:21 2008 Subject: -m32 broken on bi-arch amd64 systems? In-Reply-To: <20081223173608.068fe9d8@suszko.eu> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> Message-ID: <20081223122313.6254e173@kan.dnsalias.net> On Tue, 23 Dec 2008 17:36:08 +0100 Maciej Suszko wrote: > "Garrett Cooper" wrote: > > Hi guys, > > I think I may have found an issue today with our bi-endian > > structure, and I wanted to make sure whether or not it was an > > already known issue (-m32 is broken for gcc with lib32/libgcc.a): > > > > [root@fbsd-7-test]# gcc -o boo boo.c # Compiles > > [root@fbsd-7-test]# gcc -m32 -o boo boo.c > > /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching > > for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when > > searching for -lgcc /usr/bin/ld: cannot find -lgcc > > [root@fbsd-7-test]# file /usr/lib32/libgcc_s.so.1 > > /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, > > version 1 (FreeBSD), dynamically linked, stripped > > [root@fbsd-7-test]# uname -a > > FreeBSD fbsd-7-test.gateway.2wire.net 7.1-PRERELEASE FreeBSD > > 7.1-PRERELEASE #0: Sun Nov 23 16:19:09 UTC 2008 > > root@fbsd-7-test.gateway.2wire.net:/usr/obj/usr/src/sys/STARR amd64 > > > > I wish I had my amd64 CURRENT machine in front of me to confirm > > this, but I don't. > > Please keep me CC'ed as I am not subscribed to either amd64@ or > > stable@. Thanks! > > -Garrett > > I also noticed that behavior, shouldn't compiler/linker look > into /usr/lib32 without additional -B switch? > -- > regards, Maciej Suszko. Read email archives, this was discussed on several occasions before. Short summary: it never worked and will not work unless some non-trivial work is put into how GCC handles include and linker search paths. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081223/17c56970/signature.pgp From wieczyk at gmail.com Tue Dec 23 10:16:30 2008 From: wieczyk at gmail.com (=?ISO-8859-2?Q?Pawe=B3_Wieczorek?=) Date: Tue Dec 23 10:16:37 2008 Subject: -m32 broken on bi-arch amd64 systems? In-Reply-To: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> Message-ID: <1255bf0d0812230946nc90ee38u28b040c3d720868a@mail.gmail.com> I will extend topic to C++: [19:38] zubr:~/Code (1) $ g++ -m32 -B /usr/lib32 p.cpp In file included from /usr/include/c++/4.2/ext/new_allocator.h:37, from /usr/include/c++/4.2/bits/c++allocator.h:39, from /usr/include/c++/4.2/bits/allocator.h:53, from /usr/include/c++/4.2/memory:54, from /usr/include/c++/4.2/string:48, from /usr/include/c++/4.2/bits/locale_classes.h:47, from /usr/include/c++/4.2/bits/ios_base.h:47, from /usr/include/c++/4.2/ios:48, from /usr/include/c++/4.2/ostream:45, from /usr/include/c++/4.2/iostream:45, from p.cpp:1: /usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:96: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:99: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:100: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:105: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:106: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter [19:38] zubr:~/Code (1) $ cat p.cpp #include int main() { return 0; } [19:39] zubr:~/Code $ Problem with C++ is more connected to headers than binaries, any suggestions how to use G++ to produce 32bit code ? From josh.carroll at gmail.com Tue Dec 23 10:24:24 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue Dec 23 10:24:31 2008 Subject: -m32 broken on bi-arch amd64 systems? In-Reply-To: <20081223173608.068fe9d8@suszko.eu> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> Message-ID: <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> > I also noticed that behavior, shouldn't compiler/linker look > into /usr/lib32 without additional -B switch? > -- > regards, Maciej Suszko. > I don't know if it should or should not, but I can confirm that this behavior was around in 7.0-RELEASE, so it's been that way for quite a while, at least in the 7 branch. Josh From sgk at troutmask.apl.washington.edu Tue Dec 23 10:36:49 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Tue Dec 23 10:36:57 2008 Subject: -m32 broken on bi-arch amd64 systems? In-Reply-To: <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> Message-ID: <20081223183649.GA90840@troutmask.apl.washington.edu> On Tue, Dec 23, 2008 at 12:55:04PM -0500, Josh Carroll wrote: > > I also noticed that behavior, shouldn't compiler/linker look > > into /usr/lib32 without additional -B switch? > > -- > > regards, Maciej Suszko. > > > > I don't know if it should or should not, but I can confirm that this > behavior was around in 7.0-RELEASE, so it's been that way for quite a > while, at least in the 7 branch. > Sigh. Read the list archives. It's been this way since Peter Wemm first introduce the ability to run i386 binaries on amd64. -- Steve From jack at jarasoft.net Tue Dec 23 10:40:31 2008 From: jack at jarasoft.net (Jack Raats) Date: Tue Dec 23 10:40:39 2008 Subject: Problems installing FreeBSD 7.0 Message-ID: Hi, At this moment I have problems installing FreeBSD 6.4 and FreeBSD 7.0. After booting from CD the system I get the menu. I have tried all possible options. The system starts checking all hardware but freezes after finding the CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) (acd0) The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB Can anyone help me. I never had this problems before on other systems. Thanks Jack From admin at stardothosting.com Tue Dec 23 11:07:27 2008 From: admin at stardothosting.com (SDH Admin) Date: Tue Dec 23 11:07:33 2008 Subject: Problems installing FreeBSD 7.0 In-Reply-To: References: Message-ID: <00fb01c96531$a5fca290$f1f5e7b0$@com> > The system starts checking all hardware but freezes after finding the > CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) > (acd0) > > The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB Can you try to paste exactly what was on the screen before the "freeze" for both 6.4 and 7.0? Thanks. --- Kevin K. Systems Administrator www.stardothosting.com From minimarmot at gmail.com Tue Dec 23 11:09:17 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Tue Dec 23 11:09:48 2008 Subject: Problems installing FreeBSD 7.0 In-Reply-To: References: Message-ID: <47d0403c0812231045o49cf05fv5999f32d1061a8a9@mail.gmail.com> On Tue, Dec 23, 2008 at 1:30 PM, Jack Raats wrote: > Hi, > > At this moment I have problems installing FreeBSD 6.4 and FreeBSD 7.0. > After booting from CD the system I get the menu. I have tried all possible options. > The system starts checking all hardware but freezes after finding the CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) > (acd0) > > The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB > > Can anyone help me. I never had this problems before on other systems. > Have you tried booting in verbose mode? If so, does it give any further output after printing the GEOM_LABEL for the other drives? -Ben Kaduk From glen.j.barber at gmail.com Tue Dec 23 11:19:52 2008 From: glen.j.barb