Re: 7.0-STABLE amd64 kernel trap during boot-time device probe
On Sat, Mar 01, 2008 at 11:31:30PM -0500, Jeff Blank wrote: _mtx_lock_sleep() at 0x8047d77e = _mtx_lock_sleep+0x4e ata_interrupt() at 0x80234184 = ata_interrupt+0x164 ata_generic_intr() at 0x80234e5f = ata_generic_intr+0x2f ithread_loop() at 0x8046ccf0 = ithread_loop+0x180 It looks like there's an unexpected ATA interrupt. I can't think of any reason why either sound or netgraph would cause this - neither should be touching the hardware directly. Unless someone else has seen this before, tracking it down could be time-consuming. I think you'll need a serial console to continue. -- 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. pgpk8sZBj4PaO.pgp Description: PGP signature
Re: FreeBSD 7.0-RELEASE Available
Quoting Ken Smith [EMAIL PROTECTED]: On Fri, 2008-02-29 at 19:18 -0600, Paul Schmehl wrote: Another approach might be to make one cd the desktop install cd, including all of the apps commonly used to install the desktop (xorg, kde, gnome, etc.) This is already in place, as best I can. X.org is on disc1 (on purpose since it's something you can select in the Distributions section before even getting to the Do you want to browse packages? menu), while Gnome and KDE are both on disc2. If you select All in the distributions section it will install X.org during the initial install phase. If you then install only KDE and/or Gnome it will only ask for disc2 once you get past the package selection. The combination of KDE and Gnome basically fill even the newer 700Mb target media sizes so for it to get any better sysinstall needs to be made smarter. It does seem to me that some work in this area would pay dividends. I am definitely not arguing that point, lots can be done here. If you ask me, kernel developer | server install should be on disc1, and desktop^*$ should go on disc99. FreeBSD ...the power to serve. ^ --Chris H -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade, recommended by 7 release notes, breaks perl
Steven Hartland wrote: Would fix this particular package but again: how many others do this? Maybe this is something that BSDPAN could / should override? It might be possible, you should talk to the BSDPAN maintainer. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Reliably trigger-able ZFS panic
Hi, The following iozone test case on ZFS would reliably trigger panic: /usr/local/bin/iozone -M -e -+u -T -t 128 -S 4096 -L 64 -R -r 4k -s 30g -i 0 -i 1 -i 2 -i 8 -+p 70 -C Unfortunately the kgdb can not reveal useful backtrace. I have tried KDB_TRACE, but have not yet be able to further investigate it. fs12# kgdb /boot/kernel/kernel.symbols vmcore.0 [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 amd64-marcel-freebsd. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x8:0x80763d16 stack pointer = 0x10:0xd94798f0 frame pointer = 0x10:0xd9479920 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 340 (txg_thread_enter) trap number = 12 panic: page fault cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a trap_fatal() at trap_fatal+0x29f trap_pfault() at trap_pfault+0x294 trap() at trap+0x2ea calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x80763d16, rsp = 0xd94798f0, rbp = 0xd9479920 --- dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x26 dmu_objset_sync() at dmu_objset_sync+0x12d dsl_pool_sync() at dsl_pool_sync+0x72 spa_sync() at spa_sync+0x390 txg_sync_thread() at txg_sync_thread+0x12f fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xd9479d30, rbp = 0 --- Uptime: 25m7s Physical memory: 4081 MB Dumping 1139 MB: 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 948 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) add-symbol-file /boot/kernel/zfs.ko.symbols add symbol table from file /boot/kernel/zfs.ko.symbols at (y or n) y Reading symbols from /boot/kernel/zfs.ko.symbols...done. (kgdb) where #0 doadump () at pcpu.h:194 #1 0x80277aa8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x80277f07 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0x80465a1f in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:724 #4 0x80465e04 in trap_pfault (frame=0xd9479840, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #5 0x8046677a in trap (frame=0xd9479840) at /usr/src/sys/amd64/amd64/trap.c:410 #6 0x8044babe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #7 0x80763d16 in ?? () #8 0x0004 in adjust_ace_pair () #9 0x0004 in adjust_ace_pair () #10 0xd94799e0 in ?? () #11 0x80763e7d in ?? () #12 0xff0004275a80 in ?? () #13 0xff00045a1190 in ?? () #14 0x807639b0 in ?? () #15 0x80763f20 in ?? () #16 0xff00042dc800 in ?? () #17 0x0004 in adjust_ace_pair () #18 0xd9479990 in ?? () #19 0xb55d in z_deflateInit2_ (strm=0xff00042dc8e0, level=70109184, method=68351768, windowBits=68351600, memLevel=76231808, strategy=76231808, version=Cannot access memory at address 0x00040010 ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/zmod/deflate.c:318 Previous frame inner to this frame (corrupt stack?) -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
This is just a 'me too'. I've experienced the following on 2 seperate and very different i386 systems: ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=1520671 ad4: TIMEOUT - READ_DMA retrying (0 retries left) LBA=1520671 ad4: FAILURE - READ_DMA timed out LBA=1520671 That was on an Intel i815 based board running a Celeron 1.3 but with a Highpoint HPT370 IDE RAID controller. The above disk is a Seagate Barracuda 7200.10 80GB, and one of a pair (both have the same problem). The error occurs just after disk detection at the end of the boot where normally it would mount / and start running rc The second system is a Dual P3 Serverworks system with an IBM 60GXP Deskstar 40GB disk connected to the onboard UDMA33 controller. Disabling DMA in loader.conf does the trick and allows both machines to boot. I have tried different drive combinations and controllers but to no avail. Neither of the systems are required for use just at the moment, so I'm quite happy to test patches once they're available, or provide further details as required. Regards, Richard Tector smime.p7s Description: S/MIME Cryptographic Signature
firewire related hang.
I just installed FreeBSD-7 on an amd64 box. The new motherboard has firewire builtin. I wanted to disable dma via firewire, but as soon as I add hw.firewire.phydma_enable=0 to /boot/loader.conf (which is what the man page suggests) The box hangs on boot. It detects the firewire controller, after that the sata disk and then hangs. Is this a known problem? Is there anything I can do to help debug this? Lastly, if this is not easily fixable, would removing the firewire driver from my kernel disable the DMA attack? CU, Sec -- Whatever the virtues of balance, it's just a pleasant form of insanity. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Quoting Richard Tector [EMAIL PROTECTED]: This is just a 'me too'. I've experienced the following on 2 seperate and very different i386 systems: An upgrade to RELENG_7 solved this problem. Whether there has actually been a change in the code that has done it, or perhaps I had a faulty install CD (it only dawned on me that I'd used the same CD for both systems). Regards, Richard Tector ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Jeremy Chadwick wrote: On Wed, Feb 27, 2008 at 01:20:50PM -0700, Scott Long wrote: I'd like to attack these driver problems. What I need is to spend a couple of days with an affected system that can reliably reproduce the problem, instrumenting and testing the driver. I have a number of theories about what might be going wrong, but nothing that I'm definitely sure about. If you are willing to set up your system with remote power and remote serial, and if we knew a reliable way to reproduce the problem, I could probably have the problem identified and fixed pretty quickly. Scott, I just wanted to take a moment to publicly thank you for stepping up to the plate on this one. I have a feeling that most of these reports will have to be dealt with on a case-by-case basis, but despite that, I really do apprecaite you offering to take this one. Thank you very, very much. In regards to my experience with said problem, I haven't been able to reproduce the errors I saw on January 25th: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/040013.html I do need to get the box in question into our datacenter and set up our remaining dev/test box to do nothing but hard I/O between ZFS and UFS for hours (or days) on end to see if I can reproduce it. There's an entry in the FreeBSD ZFS wiki about this problem, but there's a possibility the issue I saw is different than what another user reported (his result was a panic, my result was a machine that locked up hard after letting FreeBSD report DMA errors for some time). That user's post is here: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/040047.html I have 2 laptops running 7 http://www.berklix.com/~jhs/hardware/digital/dmesg/ http://www.berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st/ http://www.berklix.com/~jhs/hardware/laptops/#loader.conf that wont boot without /boot/loader.conf hw.ata.ata_dma=0 If you are willing to set up your system with remote power and remote serial Sorry, I can't offer that easily ( Would need to remove laptop battery, move laptop UPS to another site, set up serial of UPS to a net server prob v. little to no chance of BIOS serial console) I could easily test any patches though, made against 7.0-stable (sorry no current partition on there currently - small disc.) Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail just Ascii plain text. HTML Base64 is spam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
IP header checksum missing with Realtek 8168, jumbo frames and offloading.
I encountered connectivity issues with an integrated Realtek 8168 on my MSI motherboard after enabling jumbo frames on my other box. Investigating the issue, I found that the packets with an ethernet frame of length 2048 get an IP header of 0x. ping -s 3000 192.168.0.11 == fail (ethereal on the other box show the 0x checksum on IP header) ping -s 2008 192.168.0.11 == fail ping -s 2006 192.168.0.11 == succeed re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 19 at device 0.0 on pci2 re0: Using 2 MSI messages miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto The interface re0 is configured with : ifconfig inet 192.168.0.1/24 media auto mtu 7422 polling ifconfig re0 -txcsum solves the issue. I tried to reproduce the issue with a Realtek 8169 (using re(4) too). I couln't : checksum offloading works ok on this card. Is this a known issue (or maybe a bug in the 8168) ? I can provide some network capture if needed. In the meantime I swapped the two cards as I don't need jumbo on one of them. Thanks Arnaud ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IP header checksum missing with Realtek 8168, jumbo frames and offloading.
On Sun, Mar 02, 2008 at 11:44:03PM +0100, Arnaud Houdelette wrote: I encountered connectivity issues with an integrated Realtek 8168 on my MSI motherboard after enabling jumbo frames on my other box. Investigating the issue, I found that the packets with an ethernet frame of length 2048 get an IP header of 0x. ping -s 3000 192.168.0.11 == fail (ethereal on the other box show the 0x checksum on IP header) ping -s 2008 192.168.0.11 == fail ping -s 2006 192.168.0.11 == succeed re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 19 at device 0.0 on pci2 re0: Using 2 MSI messages miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto The interface re0 is configured with : ifconfig inet 192.168.0.1/24 media auto mtu 7422 polling ifconfig re0 -txcsum solves the issue. I tried to reproduce the issue with a Realtek 8169 (using re(4) too). I couln't : checksum offloading works ok on this card. Is this a known issue (or maybe a bug in the 8168) ? There had been several re(4) instability issues on PCIe based controllers. Would you try the following patch and let me know the result? http://people.freebsd.org/~yongari/re/6.3R/re.busdma.patch If you use 7.0-RELEASE use the following one. http://people.freebsd.org/~yongari/re/7.0R/if_re.c http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h I can provide some network capture if needed. In the meantime I swapped the two cards as I don't need jumbo on one of them. Thanks Arnaud -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAUSE support for Ethernet interfaces ?
On Fri, Feb 29, 2008 at 11:41:07AM +0100, Kurt Jaeger wrote: Hi! I'm researching the topic of PAUSE counters (receiving side) for FreeBSD systems. That's a sort of flow control with ethernet, see e.g.: http://www.techfest.com/networking/lan/ethernet3.htm#3.2.1 Cisco switches seem to receive and count them, which helps to find short-term (seconds) overloaded links. FreeBSD has no such framework in mii layer yet so it's completely up to driver. em(4) handles flow-control in driver so it can handle flow-control. Can FreeBSD 6.x or 7.x handle PAUSE frames, at least receiving them ? Receiving pause frames have no problem on any driver but most drivers does not respond with the pause frames. AFAIK marius@ has a flow-control patch so I guess FreeBSD will have generic flow-control capability which will make it available on all ethernet drivers with minor modification. Thanks for any pointer! -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I tried to install 7.0 today and had problems.
On Fri, Feb 29, 2008 at 12:06:28AM -0700, geek wrote: I tried to install 7.0 on a computer with an ABIT AV8 motherboard. This board has an integrated NIC and the installer didn't find it. This same machine works just fine with 6.2. Any suggestions would be appreciated. That's odd. I guess sysinstall may have showed you vge(4) was detected on your system. I had some trouble to make vge(4) work on my box but it's different issue. Since GENERIC kernel has vge(4) I don't think loading vge(4) kernel module helps here. Would you show me the output of pciconf -lcv? Thanks to all. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-RELEASE Available
Quoting Chris H. [EMAIL PROTECTED]: If you ask me, kernel developer | server install should be on disc1, and desktop^*$ should go on disc99. FreeBSD ...the power to serve. ^ eh ? ??? So what do you propose to use as workstations with your FreeBSD servers ? (Not that I see much difference in philosophy, nowadays: servers used to be those machines with high throughput all along the night, and now they tend to be those over-reactive transactional n-tier service-providers. What's so different with serving desktop-user requests... Sigh.) Anyway: are you deliberately proposing to concentrate on server, period. And to hell with other users (if one can use FreeBSD to be desktop-productive so much the better, but we shouldn't put too much effort in that) ? gregory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-RELEASE Available
On Mon, Mar 03, 2008 at 08:01:56AM +0100, [EMAIL PROTECTED] wrote: So what do you propose to use as workstations with your FreeBSD servers ? (Not that I see much difference in philosophy, nowadays: servers used to be those machines with high throughput all along the night, and now they tend to be those over-reactive transactional n-tier service-providers. What's so different with serving desktop-user requests... Sigh.) Anyway: are you deliberately proposing to concentrate on server, period. And to hell with other users (if one can use FreeBSD to be desktop-productive so much the better, but we shouldn't put too much effort in that) ? Do we really need another MacOS X? :-) Just kidding. Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd fails to synchronize on FreeBSD 6.3-STABLE
Clifton Royston wrote: You're not getting responses back from __any__ of those NTP servers. If you have a firewall *in front* of your BSD box (meaning a separate box, not ipfw/ipfilter/pf on the same BSD box!), then this is likely the cause of the problem. I really agree with you. I have upgraded to FreeBSD 7.0-RELEASE last weekend. The problem still persists. There must be some firewall in front of my BSD box. I will check my router/gateway. I'm sure that it's not an ntpd or BSD issue. Thanks, Pongthep ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
