Re: panics in network stack in 12-current
Hamza Sheikh wrote: I may have encountered something similar on an EdgeRouter Lite running r317256. It's serving as network gateway at home. After some time the WAN connection goes dead. It starts working with either (a) reconnecting the network cable or (b) pinging any IP on the internet from that box. On rare occasions I had to reboot to get it to work. it doesn't sound much like my problem. i had no network issues until the system would suddenly panic and reboot. removing FLOWTABLE from my kernel might have fixed it, but it is too early to tell as I have yet to discover a reproducible way to trigger the bug. I'm still new to FreeBSD and don't know how to collect relevant information or whether to even determine if my issue is related to Andrey's. Any help is really appreciated. My setup is documented in detail in a blog post[0] if it helps. You probably don't want to hear this, but if you are new to FreeBSD, maybe you shouldn't be running current. I probably shouldn't running current and I have 35 years of BSD experience. I do it as a way of contributing to the project by alpha-testing new code when I have time. Brendan Gregg has some very good material on his site that might help you learn to collect useful info about what is going on inside your systems. http://www.brendangregg.com/Perf/freebsd_observability_tools.png http://www.brendangregg.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Andrey V. Elsukov wrote: On 27.04.2017 08:42, Tom Uffner wrote: Tom Uffner wrote: Andrey V. Elsukov wrote: I think the most of these panics should be fixed in r315956. thanks. I'll give it a try and report back as soon as I have a result. r315956 panicked about 22 min after boot. failed to dump a core. Why not update to the latest revision? Probably this is flowtable related, don't think it is usable. Anyway we need the trace to determine the cause. Also it seems you have VIMAGE enabled. This also have some known panics. attached is a text dump from this version core.txt.6.bz2 Description: Binary data ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Andrey V. Elsukov wrote: On 27.04.2017 08:42, Tom Uffner wrote: r315956 panicked about 22 min after boot. failed to dump a core. Why not update to the latest revision? I did several times a while ago, but didn't get a panic free system. I was hoping to bisect the point the point where the problem actually occurred and maybe send a patch instead of just begging for help. trouble was, I got down to a small number of revisions and none of them had any changes that looked even remotely related to my problem. I'll give today's HEAD a try. Probably this is flowtable related, don't think it is usable. Anyway we need the trace to determine the cause. Also it seems you have VIMAGE enabled. This also have some known panics. OK, I will also try disabling flowtable. Not sure about VIMAGE. I don't have it specifically enabled, but I don't have it specifically disabled either if it defaults to on. I don't know much about it. I have also tried using the GENERIC kernel instead of my custom one, but it was even less stable on my hardware and bricked the system instead of panicking and producing a core dump. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Tom Uffner wrote: Andrey V. Elsukov wrote: I think the most of these panics should be fixed in r315956. thanks. I'll give it a try and report back as soon as I have a result. r315956 panicked about 22 min after boot. failed to dump a core. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panics in network stack in 12-current
Andrey V. Elsukov wrote: On 26.04.2017 04:03, Tom Uffner wrote: I think the most of these panics should be fixed in r315956. thanks. I'll give it a try and report back as soon as I have a result. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panics in network stack in 12-current
Since updating my -current box to 12 several months ago, I have been trying to pin down several elusive and probably related panics. they always manifest a a trap out of rw_wlock_hard() i am fairly certain that r302409 was stable, revs up through r306792 may be stable, or perhaps I just didn't wait long enough for my system to panic. I don't know of anything that I can reproducably poke at to trigger this. r306807 is definitely bad, as is everything up through r309124. I haven't seen anything on the mailing lists or in the SVN logs that looks like it is related to my problem. my hardware is an Asus M4A77TD MB, AMD Phenom 2 X6 1100T CPU (for some of this time I had an Athlon 2 X2, but upgraded recently), and RealTek 8168 PCIe Gigabit NIC. FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #33 r306807M: Tue Apr 18 17:09:55 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 in revs between 306807-307125, the panics have been in flowcleaner, in more recent ones, they happen in arbitrary userspace processes that make heavy use of the network. I know I should try the latest rev to see if it went away. aside from that, any thoughts on how I should proceed? Mon Apr 17 02:52:10 EDT 2017 FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #32 r306821M: Fri Apr 7 02:11:44 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 panic: page fault Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8057820d stack pointer = 0x28:0xfe046a422650 frame pointer = 0x28:0xfe046a422690 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 = 697 (ntpd) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe046a4222b0 vpanic() at vpanic+0x186/frame 0xfe046a422330 panic() at panic+0x43/frame 0xfe046a422390 trap_fatal() at trap_fatal+0x331/frame 0xfe046a4223f0 trap_pfault() at trap_pfault+0x14f/frame 0xfe046a422430 trap() at trap+0x21e/frame 0xfe046a422580 calltrap() at calltrap+0x8/frame 0xfe046a422580 --- trap 0xc, rip = 0x8057820d, rsp = 0xfe046a422650, rbp = 0xfe046a422690 --- __rw_wlock_hard() at __rw_wlock_hard+0xad/frame 0xfe046a422690 ip_output() at ip_output+0x483/frame 0xfe046a4227c0 udp_send() at udp_send+0xb8f/frame 0xfe046a422890 sosend_dgram() at sosend_dgram+0x431/frame 0xfe046a422910 kern_sendit() at kern_sendit+0x178/frame 0xfe046a4229c0 sendit() at sendit+0x179/frame 0xfe046a422a10 sys_sendto() at sys_sendto+0x4d/frame 0xfe046a422a60 amd64_syscall() at amd64_syscall+0x391/frame 0xfe046a422bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe046a422bf0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x8013c9cba, rsp = 0x7fffdfffc7e8, rbp = 0x7fffdfffc830 --- Mon Apr 17 03:19:00 EDT 2017 FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #32 r306821M: Fri Apr 7 02:11:44 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 panic: page fault Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8057820d stack pointer = 0x28:0xfe0469a0eab0 frame pointer = 0x28:0xfe0469a0eaf0 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 = 21 (flowcleaner) trap number = 12 Timeout initializing vt_vga panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0469a0e710 vpanic() at vpanic+0x186/frame 0xfe0469a0e790 panic() at panic+0x43/frame 0xfe0469a0e7f0 trap_fatal() at trap_fatal+0x331/frame 0xfe0469a0e850 trap_pfault() at trap_pfault+0x14f/frame 0xfe0469a0e890 trap() at trap+0x21e/frame 0xfe0469a0e9e0 calltrap() at calltrap+0x8/frame 0xfe0469a0e9e0 --- trap 0xc, rip = 0x8057820d, rsp = 0xfe0469a0eab0, rbp = 0xfe0469a0eaf0 --- __rw_wlock_hard() at __rw_wlock_hard+0xad/frame 0xfe0469a0eaf0 flowtable_clean_vnet() at flowtable_clean_vnet+0x496/frame 0xfe0469a0eb80 flowtable_cleaner() at flowtable_cleaner+0x90/frame 0xfe0469a0ebb0 fork_exit() at fork_exit+0x75/frame 0xfe0469a0ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0469a0ebf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Mon Apr 17 02:25:20 EDT 2017 FreeBSD discord
Re: r289932 causes pf reversion - breaks rules with broadcast destination
Kristof Provost wrote:
Can you give this a quick test:
diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c
index 1dfc37d..762b82e 100644
--- a/sys/netpfil/pf/pf.c
+++ b/sys/netpfil/pf/pf.c
@@ -1973,9 +1973,9 @@ pf_addr_wrap_neq(struct pf_addr_wrap *aw1, struct
pf_addr_wrap *aw2)
switch (aw1->type) {
case PF_ADDR_ADDRMASK:
case PF_ADDR_RANGE:
- if (PF_ANEQ(&aw1->v.a.addr, &aw2->v.a.addr, 0))
+ if (PF_ANEQ(&aw1->v.a.addr, &aw2->v.a.addr, AF_INET6))
return (1);
- if (PF_ANEQ(&aw1->v.a.mask, &aw2->v.a.mask, 0))
+ if (PF_ANEQ(&aw1->v.a.mask, &aw2->v.a.mask, AF_INET6))
return (1);
return (0);
case PF_ADDR_DYNIFTL:
Your patch appears to solve the problem. Thanks!
Also thank you for your quick response.
Sorry I took so long to reply, but I was getting bizarre results from
the "quick" test, and needed to fall back to a full kernel rebuild w/
a consistent set of sources to do a fair apples to apples comparison.
tom
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r289932 causes pf reversion - breaks rules with broadcast destination
Tom Uffner wrote: Commit r289932 causes pf rules with broadcast destinations (and some but not all rules after them in pf.conf) to be silently ignored. This is bad. I do not understand the pf code well enough to see why this change caused the breakage, but I suspect that it might expose some deeper problem and should not simply be reverted. OK, so here is why I don't want to simply back this out and have a "working" firewall again: Apparently PF_ANEQ was prone to false positives when comparing IPv4 addrs. This is what r289932 and r289940 fixed. For IPv4 it does not matter where in bits 32-127 the address mismatch occurs or what order the garbage data is tested. That is all the paren fix in r289940 changes. It might be relevant for v6, but doesn't matter here. So, if my rule was "working" due to false positive in a comparison that has now been fixed, how many other address comparisons were affected by this error? There are 36 occurrences of PF_ANEQ in pf.c and 2 in if_pfsync.c About half of them appear to be testing IPv4 addresses. How many of them may have been influenced by uninitialized data returning a false positive result? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r289932 causes pf reversion - breaks rules with broadcast destination
Kristof Provost wrote: On 2015-11-04 20:31:35 (-0500), Tom Uffner wrote: Commit r289932 causes pf rules with broadcast destinations (and some but not all rules after them in pf.conf) to be silently ignored. This is bad. What version did you test exactly? There was an issue with r289932 that was fixed in r289940, so if you're in between those two can you test with something after r289940? thanks for your response. r289940 does not fix the problem that I am seeing. I first discovered it when I updated a -current system (from Jun 30, don't know the exact rev) to r290174 on Oct 30. After finding that many of my net services no longer worked, I isolated rules w/ broadcast addresses as the specific cause of the problem. Then I looked up every commit that touched sys/netpfil/pf from 6/30 to 10/30 and tested a kernel from before & after each one. when r290160 unexpectedly failed, I looked a little deeper and came up with sys/net/pfvars.h and r289932 As I said, I don't know why this change causes a problem (and don't really have time to figure it out at the moment). I just know that <=r289931 works, and that r289932 and greater do not. thanks, tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r289932 causes pf reversion - breaks rules with broadcast destination
Commit r289932 causes pf rules with broadcast destinations (and some but not
all rules after them in pf.conf) to be silently ignored. This is bad.
this broke access to my samba shares, and every "pass in ..." rule occurring
after the samba rule in my pf.conf.
for example, the host in question is a file server that allows SMB access on
my DMZ network. prior to r289932 the I could allow clients to browse shares
with pf rules such as:
pass in log on $dmz_if proto tcp from $ext_if:network to $dmz_if:0 \
port { 137 139 445 }
pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:0 port 137
pass in log on $dmz_if proto udp from $ext_if:network to $dmz_if:broadcast \
port { 137 138 }
after r289932 the 3rd of these was silently ignored -- pf parsed it w/o
complaint and listed it w/ "pfctl -s rules" but packets that should have
been allowed were instead matched by my default rule 0 ("block log all")
as were packets that should have matched later pass in rules.
it did not matter if the rule used an explicit address (... to 10.10.61.255)
or interface (... to re0:broadcast) or a macro (to $dmz_if:broadcast).
I do not understand the pf code well enough to see why this change caused
the breakage, but I suspect that it might expose some deeper problem and
should not simply be reverted.
tom
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: geom mirror now rebuilding on every reboot?
Alexander Motin wrote: I think the right answer would be to remove stale Promise format RAID metadata from the disk. You should be able to do it by booting from any source and doing `graid list -a` to see all RAID GEOMs (even broken) and then remove them with `graid remove Promise ad4`. thanks, that fixed it. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: geom mirror now rebuilding on every reboot?
not quite the same issue, but i tried to update a system with gmirror from FreeBSD eris.uffner.com 10.0-CURRENT FreeBSD 10.0-CURRENT #210: Thu Mar 15 16:41:18 EDT 2012 t...@eris.uffner.com:/usr/obj/usr/src/sys/ERIS i386 to -current from Aug 4th, and booting now fails into mountroot> with GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad4 (error=1) GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1) GEOM_MIRROR: Device gm0 destroyed GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad6 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad6 (error=1) GEOM_MIRROR: Cannot add disk ad6 to gm0 (error=1) GEOM_MIRROR: Device gm0 destroyed nor will it boot from the underlying partitions (ad4s1a, ad6s1a), even if i unplug one of the drives. the partitions & metadata are not corrupt and work just fine if i revert to the previous kernel. i haven't had time yet to track down the commit where this breaks. i was just wondering if anyone knew offhand what is going on & how to fix it. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB
according to kldstat -v, both "uhci/usbus" & "pci/uhci" were present in my kernel but one or both of them was silently failing. apparently something in my sources was corrupt because deleting all of the USB related code from my CVS root, re-csuping it, and building a fresh kernel solved the problem. thanks for the help. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB
John Baldwin wrote: On Friday, December 10, 2010 8:13:01 pm Tom Uffner wrote: no...@pci0:0:16:0: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB Ok, can you show the output of 'pciconf -rb pci0:0:16:0 0x9'? [xiombarg#:~:1] pciconf -rb pci0:0:16:0 0x9 00 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB 1.1 devs not working on ASUS K8VSE (x86) MB
John Baldwin wrote: pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 16.2 (no driver attached) pci0: at device 16.3 (no driver attached) Can you get pciconf -lv output for these four devices? no...@pci0:0:16:0: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB no...@pci0:0:16:1: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB no...@pci0:0:16:2: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB no...@pci0:0:16:3: class=0x0c0300 card=0x80ed1043 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
USB 1.1 devs not working on ASUS K8VSE (x86) MB
I have a fairly recent Current system running on an ASUS K8V SE Deluxe MB. It was a dual boot amd64/x86 system (until a few days ago when the drive w/ the amd64 partitions unexpectedly failed after only a week of use) When running it as x86, USB 1.1 devices are not recognized by FreeBSD. They worked fine on the amd64 kernel built from the same code. both ohci and uhci are in the kernel even though they don't show up in dmesg. the devices in question (currently a 1.1 hub and a mouse) are both seen and activated by the BIOS but turned off once FreeBSD takes over. I had the same problem with GENERIC kernels from the 9.0-current-201011 snapshot, so it is not my kernel config. the mouse also works fine on either x86 or amd64 when plugged into a USB 2.0 hub or a PS2 adapter. and both these devices worked w/ the x86 kernel on the previous incarnation of this system with an ASUS A7N8X MB (NVIDIA chipset) so i suspect that the problem may be in the initialization code for the Via chipset. thanks in advance for any help, tom FreeBSD xiombarg.uffner.com 9.0-CURRENT FreeBSD 9.0-CURRENT #292: Wed Dec 8 13:10:15 EST 2010 root@:/usr/obj/usr/src/sys/XIOMBARG i386 Copyright (c) 1992-2010 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 9.0-CURRENT #292: Wed Dec 8 13:10:15 EST 2010 root@:/usr/obj/usr/src/sys/XIOMBARG i386 CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.87-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0xfc0 Family = f Model = c Stepping = 0 Features=0x78bfbff AMD Features=0xe0500800 real memory = 2147483648 (2048 MB) avail memory = 2094309376 (1997 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7fef (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: 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 0xa000-0xa0ff mem 0xe000-0xefff,0xfce0-0xfce0 irq 16 at device 0.0 on pci1 vgapci1: mem 0xd000-0xdfff,0xfcc0-0xfcc0 at device 0.1 on pci1 atapci0: port 0xe800-0xe87f,0xe400-0xe4ff mem 0xfda0-0xfda00fff,0xfd90-0xfd91 irq 16 at device 9.0 on pci0 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 skc0: port 0xe000-0xe0ff mem 0xfdc0-0xfdc03fff irq 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:11:2f:38:7b:87 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto re0: port 0xd800-0xd8ff mem 0xfd70-0xfd7000ff irq 17 at device 12.0 on pci0 re0: Chip rev. 0x1000 re0: MAC rev. 0x miibus1: on re0 rgephy0: PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:14:d1:14:33:e6 pcm0: port 0xd400-0xd4ff irq 19 at device 14.0 on pci0 atapci1: port 0xd000-0xd007,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xb800-0xb80f,0xb400-0xb4ff irq 20 at device 15.0 on pci0 ata5: on atapci1 ata6: on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ata1: on atapci2 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 16.2 (no driver attached) pci0: at device 16.3 (no driver attached) ehci0: mem 0xfd50-0xfd5000ff irq 21 at device 16.4 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 acpi_button0: on acpi0 acpi_button1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc-0xccfff,0xcd000-0xd57ff pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual co
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Weongyo Jeong wrote: OK. The patch is ready to test. Could you please test it with attached patch? your patch got rid of the "bwn0: unsupported rate 0" messages on my Dell Inspiron 1150. But it still gives me repeated: bwn0: RX decryption attempted (old 0 keyidx 0x1) and a few of the following: bwn0: need multicast update callback ts_to_ct(1274664456.824638117) = [2010-05-24 01:27:36] please let me know if there is anything you want me to test. Copyright (c) 1992-2010 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-STABLE #0: Sun May 16 00:05:17 EDT 2010 t...@zoe.uffner.com:/usr/obj/usr/src/sys/ZOE i386 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ab6000. Preloaded elf module "/boot/kernel/if_bwn.ko" at 0xc0ab6174. Preloaded elf module "/boot/kernel/siba_bwn.ko" at 0xc0ab6220. Preloaded elf module "/boot/modules/bwn_v4_ucode.ko" at 0xc0ab62d0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2597803596 Hz CPU: Intel(R) Celeron(R) CPU 2.60GHz (2597.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebf9ff Features2=0x4400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 128 KB, 2-way set associative, sectored cache, 64 byte line size real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c26000 - 0x3ec82fff, 1040568320 bytes (254045 pages) avail memory = 1040355328 (992 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xcfae pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: x86bios: IVT 0x00-0x0004ff at 0xc000 x86bios: SSEG 0x01-0x01 at 0xc3b74000 x86bios: EBDA 0x09f000-0x09 at 0xc009f000 x86bios: ROM 0x0a-0x0e at 0xc00a ULE: setup cpu 0 wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32] c=0x03ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 firmware: 'bwn_v4_ucode' version 0: 0 bytes loaded at 0xc0a8b808 firmware: 'bwn_v4_ucode5' version 0: 22384 bytes loaded at 0xc0a8b808 firmware: 'bwn_v4_ucode11' version 0: 29864 bytes loaded at 0xc0a90f78 firmware: 'bwn_v4_ucode13' version 0: 32232 bytes loaded at 0xc0a98420 firmware: 'bwn_v4_ucode14' version 0: 31384 bytes loaded at 0xc0aa0208 firmware: 'bwn_v4_ucode15' version 0: 30488 bytes loaded at 0xc0aa7ca0 firmware: 'bwn_v4_pcm5' version 0: 1320 bytes loaded at 0xc0aaf3b8 firmware: 'bwn_v4_a0g1initvals5' version 0: 1840 bytes loaded at 0xc0aaf8e0 firmware: 'bwn_v4_a0g0initvals5' version 0: 1840 bytes loaded at 0xc0ab0010 firmware: 'bwn_v4_b0g0initvals5' version 0: 1840 bytes loaded at 0xc0ab0740 firmware: 'bwn_v4_b0g0initvals13' version 0: 2080 bytes loaded at 0xc0ab0e70 firmware: 'bwn_v4_a0g1bsinitvals5' version 0: 158 bytes loaded at 0xc0ab1690 firmware: 'bwn_v4_a0g0bsinitvals5' version 0: 158 bytes loaded at 0xc0ab172e firmware: 'bwn_v4_b0g0bsinitvals5' version 0: 158 bytes loaded at 0xc0ab17cc firmware: 'bwn_v4_lp0initvals13' version 0: 3618 bytes loaded at 0xc0ab186a firmware: 'bwn_v4_lp0initvals14' version 0: 2064 bytes loaded at 0xc0ab268c firmware: 'bwn_v4_lp0initvals15' version 0: 2052 bytes loaded at 0xc0ab2e9c firmware: 'bwn_v4_lp0bsinitvals13' version 0: 158 bytes loaded at 0xc0ab36a0 firmware: 'bwn_v4_lp0bsinitvals14' version 0: 158 bytes loaded at 0xc0ab373e firmware: 'bwn_v4_lp0bsinitvals15' version 0: 158 bytes loaded at 0xc0ab37dc firmware: 'bwn_v4_n0bsinitvals11' version 0: 158 bytes loaded at 0xc0ab387a kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device mem: Pentium Pro MTRR support enabled null: io: random: ACPI: RSDP 0xfdf00 00014 (v0 DELL ) ACPI: RSDT 0x3fef 00028 (v1 DELLCPi R 27D50605 ASL 0061) ACPI: FACP 0x3fef0400 00074 (v1 DELLCPi R 27D50605 ASL 0061) ACPI: DSDT 0x3fef0c00 02594 (v1 INT430 SYSFexxx 1001 MSFT 010E) ACPI: FACS 0x3feff800 00040 npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: wakeup code va 0xc3b73000 pa 0x1000 atpic: Programming IRQ9 as level/low pci_open(1):mode 1 addr port (0x0cf8) is 0x8050 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80]
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Attilio Rao wrote: I have another problem where the bwn is fully recognized and wlan0 is created but the interface doesn't scan at all: # netstat -nil Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll bwn0 2290 00:26:5e:64:be:750 0 0 0 0 0 # ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:26:5e:64:be:75 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 wme bintval 0 # kldstat Id Refs AddressSize Name 14 0x8010 90b9a8 kernel 21 0x80c22000 28a9abwn_v4_ucode.ko doing "ifconfig wlan0 list scan" ends up immediately without further output. The dmesg is here: http://www.freebsd.org/~attilio/dmesg-bwn0.diff I had a similar problem w/ a 4309. If you haven't solved this already, please check that the radio is actually enabled. some laptops have a button. some have a key sequence. many also have a BIOS setting. mine looked pretty much the same as yours to FreeBSD but just endlessly scanned the channels for a signal until i noticed that the radio was disabled in BIOS. tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Xin LI wrote:
On Wed, Mar 31, 2010 at 6:56 PM, Tom Uffner wrote:
Michael Butler wrote:
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of "off64_t".
it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 & everything that depends on it.
Just because they used to compile DOES NOT mean they were right. It's
NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see:
http://www.delorie.com/gnu/docs/glibc/libc_13.html
i realize this. i was just adding to the list of ports that no longer
build after this change. ghostscript is kind of important for print
support.
i doubt this is "right" either, but it is a quick & dirty way to
make mplayer compile again:
--- configure.orig 2010-04-01 15:49:37.0 -0400
+++ configure 2010-04-01 15:50:50.0 -0400
@@ -5337,7 +5337,7 @@
#include
int main(void) { return 0; }
EOF
-cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE \
+cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
-ldvdread $_ld_dl && _dvdread=yes && _res_comment="external"
fi
fi
@@ -7412,8 +7412,6 @@
if test "$_largefiles" = yes || freebsd ; then
CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
if test "$_dvdread" = yes || test "$_libdvdcss_internal" = yes ; then
-# dvdread support requires this (for off64_t)
-CFLAGS="$CFLAGS -D_LARGEFILE64_SOURCE"
cygwin && CFLAGS="$CFLAGS -DSYS_CYGWIN"
fi
fi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Michael Butler wrote: This breaks most (if not all) of the QT4-dependent ports for the lack of a definition of "off64_t". it also breaks multimedia/mplayer, graphics/ImageMagick, and print/ghostscript8 & everything that depends on it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 5.0-20010304-CURRENT panics during boot on Sony Vaio
John Baldwin wrote: > On 05-Mar-01 Tom Uffner wrote: > > John Baldwin wrote: > >> On 04-Mar-01 Tom Uffner wrote: > >> > all of the snapshots since the 24th have exhibited this same or > >> > very similar behavior. > >> Does it happen for snapshots before the 24th? > > no, it does not, at least not for the 5.0-20010210-CURRENT snap. > Can you try cvsupping the src/sys tree one day at a time to see what day > the kernel starts breaking for you? ok, now i'm really confused. i built GENERIC kernels for every day from the 2/10 to 2/25 and none of them panic. the snaps for the 24th and 25th both during boot (only on my Vaio, not my other test systems) could something outside the kernel have changed that made a difference? or could it from building with different options? my /etc/make.conf has "COPTFLAGS= -O -pipe -march=i686". i presume that the snaps were built without any optimization, could this make a difference? -- Tom Uffner [EMAIL PROTECTED] Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-20010304-CURRENT panics during boot on Sony Vaio
John Baldwin wrote: > > On 04-Mar-01 Tom Uffner wrote: > > all of the snapshots since the 24th have exhibited this same or > > very similar behavior. > > Does it happen for snapshots before the 24th? > no, it does not, at least not for the 5.0-20010210-CURRENT snap. it boots from the floppies and once installed, from the disk. oh well, so much for the idea that it would be easier to get past the libc change by installing a snapshot... Copyright (c) 1992-2001 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 5.0-20010210-CURRENT #0: Sat Feb 10 16:04:54 GMT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 496311413 Hz CPU: Pentium III/Pentium III Xeon/Celeron (496.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 134152192 (131008K bytes) avail memory = 125415424 (122476K bytes) Preloaded elf kernel "kernel" at 0xc0506000. Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 8 entries at 0xc00fdf40 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xfca0-0xfcbf irq 9 at dev ice 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at 7.3 (no driver attached) pci0: at 8.0 (no driver attached) pcm0: port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 0xfedf8000-0x fedf irq 9 at device 9.0 on pci0 pci0: at 10.0 (no driver attached) pcic-pci0: at device 12.0 on pci0 pcic-pci1: at device 12.1 on pci0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pcic0: at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 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 sio1: configured irq 3 not in bitmap of probed irqs 0 sn0: ioaddr is 0x300 sn0: test1 failed vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources pccard: card inserted, slot 0 ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed ad0: 17301MB [35152/16/63] at ata0-master UDMA33 acd0: DVD-ROM at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted lp0: IPv6 not supported ed1 at port 0x300-0x31f irq 3 slot 0 on pccard0 ed1: address 00:e0:98:70:10:ee, type Linksys (16 bit) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-20010304-CURRENT panics during boot on Sony Vaio
all of the snapshots since the 24th have exhibited this same or very similar behavior. when booting from the kern & mfsroot floppies i get: . . . unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources pccard: card inserted, slot 0 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while it kernel mode instruction pointer = 0x8:0xc02e3858 stack pointer = 0x10:0xc78c8f50 frame pointer = 0x10:0xc78c8f64 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 19 (irq9: uhci0) trap number = 9 panic: general protection fault i only get this on my vaio (PCG-XG9); several other pc's i tried these boot floppies on boot and run sysinstall just fine. none of my other test boxes have USB though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
