Re: problems booting 8.x kernel
On 14/03/11 18:48, Olivier Cochard-Labbé wrote:
On Mon, Mar 14, 2011 at 11:06 AM, Mike Scott wrote:
Basically, I'm finding that the 8.1 and 8.2 kernels hang on certain machines
during bootup, specifically during device discover and module load. I've
tried 8.2 off the current release CD, and also 8.1 off the Debian kfreebsd
6.0.0 distribution - both have the same issue.
I've got the same problem with one motherboard (Asus K8N7-E deluxe):
Since FreeBSD 8.0, there is an ACPI bug (pr 142263) in the FreeBSD
kernel that detect wrong address for all devices.
As example, here is an extract of the dmesg on FreeBSD 7.2:
nfe0: port
0xb000-0xb007 mem 0xd300-0xd3000fff irq 21 at device 10.0 on pci0
nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd300
But, since FreeBSD 8.0, the dmesg report this (note the reserved mem diff):
nfe0: irq 21 at device
10.0 on pci0
nfe0: Lazy allocation of 0x100 bytes rid 0x10 type 3 at 0x8100
nfe0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x8100!
Try to boot by disabling ACPI into the FreeBSD boot screen… This solve
the problem on my motherboard.
Thanks for the note.
I've tried disabling everything - floppy, usb and acpi - in the BIOS.
Still no joy; it just hangs. I don't get the 'lazy allocation' message
you do; nfe0 looks reasonable here.
I'm using boot -v. Depending on whether I use -p (single step) as well,
the hang point changes from just after "flowtable cleaner started" or
the message about a firewire bus reset I quoted earlier.
I've found the occasional similar comment on the web, such as
http://forums.freebsd.org/showthread.php?p=117767
hanging on amd64 smp hardware after 'ata pseudoraid loaded' (which is a
message I sometimes see just before the 'flowtable' message); maybe
related, maybe not. But no answers :-{
I think I'll have to give up because I'm out of ideas, settle for a
linux kernel on this particular target h/w, and just hope this issue
doesn't affect another machine I have which is due for imminent upgrade
from 6.2 to 8.x.
--
Mike Scott
Harlow, Essex, England
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems booting 8.x kernel
On 15/03/11 09:54, Mike Scott wrote:
Sorry, a line or two 'got away from' that last message, so part won't
make sense. Should be
I've found the occasional similar comment on the web, such as
http://forums.freebsd.org/showthread.php?p=117767
That refers to a hang after 'flowtable cleaner' while I've also seen
comments about:
hanging on amd64 smp hardware after 'ata pseudoraid loaded' (which is a
message I sometimes see just before the 'flowtable' message); maybe
related, maybe not. But no answers :-{
--
Mike Scott
Harlow, Essex, England
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems booting 8.x kernel
On Tue, 15 Mar 2011, Mike Scott wrote: > I think I'll have to give up because I'm out of ideas, settle for a linux > kernel on this particular target h/w, and just hope this issue doesn't > affect another machine I have which is due for imminent upgrade from 6.2 to > 8.x. Does it boot ok on 7.4? Might that be suitable for this box's purpose? cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems booting 8.x kernel
On 15/03/11 10:17, Ian Smith wrote: On Tue, 15 Mar 2011, Mike Scott wrote: > I think I'll have to give up because I'm out of ideas, settle for a linux > kernel on this particular target h/w, and just hope this issue doesn't > affect another machine I have which is due for imminent upgrade from 6.2 to > 8.x. Does it boot ok on 7.4? Might that be suitable for this box's purpose? Don't know about booting. I'm looking at multiple installations, which confuses me as much as anyone :-) The small server currently running 6.2 I need^W want to get up to 8.x for the userland camera support. The desktop I've mostly been referring to previously is a testbed before I consider buying new hardware - I want to get a system installed, write some software and get it all running before committing to significant (at least for me!) expense. The problem being that I see some advantage in trying debian kfreebsd (I need alsaplayer, and assume this would be available) - which uses an 8.1 kernel and is where all this started because it wouldn't boot! If pushed, I'd probably drop back to straight debian/linux, but I'd rather stick with something I know a little about; besides I happen to like freebsd :-) Does that make some sort of sense?? -- Mike Scott Harlow, Essex, England ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Dell 850 Panic on boot
On 15/03/2011 02:06, Mark Felder wrote: Well I'm not sure what to say. I just remembered I promised an update and so I went to try to boot the server off an 8.2 disc and see it panic again and nothing. No panic. I have no explanation for this except maybe a failing power supply that was being naughty on Friday but is OK today. I will have to reinstall this server soon so we'll see what happens. If I can reproduce it again I'll revive this thread. Thank you for the update. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
MAC address / per-proto ARP caching in 8.1-RELEASE
Is anyone aware of some sort of facility in either FreeBSD 8.1-RELEASE or the em(4) driver which would cause it to cache MAC addresses / ARP entries for hosts on a per-protocol basis? We've been doing some testing with new routers, and almost every time we switch them in or out our FreeBSD machines get stuck sending UDP DNS requests to the MAC address of the old default gateway in complete disregard for the current contents of the ARP table. New TCP connections do not seem to be affected: [spolyack@web01 ~]$ uname -a FreeBSD web01 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #3: Mon Dec 6 08:58:21 EST 2010 root@web01:/usr/obj/usr/src/sys/WEB-AMD64 amd64 Current ARP table after the router replacement, the default gateway is 10.0.1.254, which it has the correct new MAC address for already: [spolyack@web01 ~]$ arp -an ? (10.0.1.17) at 00:0c:29:47:74:3a on em2 permanent [ethernet] ? (10.0.1.130) at 00:0c:29:47:74:26 on em0 permanent [ethernet] ? (10.0.1.254) at 00:a0:c9:00:01:01 on em0 expires in 915 seconds [ethernet] ? (10.0.0.17) at 00:0c:29:47:74:30 on em1 permanent [ethernet] ? (10.0.0.15) at 00:0c:29:47:74:30 on em1 permanent [ethernet] ? (10.0.0.11) at 00:0c:29:47:74:30 on em1 permanent [ethernet] ? (10.0.0.2) at 00:1f:a0:10:28:70 on em1 expires in 1162 seconds [ethernet] ? (10.0.0.1) at 00:1f:a0:10:28:70 on em1 expires in 943 seconds [ethernet] tcpdump shows the DNS requests heading to the *old* router's MAC address despite the contents of the ARP table: [spolyack@web01 ~]$ sudo tcpdump -i em0 -s 256 -vvv -e -n -ttt 'port 53' tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 256 bytes 00:00:00.00 00:0c:29:47:74:26 > 54:75:d0:a3:7c:8c, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 64, id 55590, offset 0, flags [none], proto UDP (17), length 72) 10.0.1.130.52419 > 10.0.2.80.53: [bad udp cksum fdc5!] 52051+ A? db-testing-lab. (44) [spolyack@web01 ~]$ arp -an | grep 54:75:d0 [spolyack@web01 ~]$ Using telnet to form a TCP connection to port 53 on the same DNS server which the above UDP requests are headed to works just fine: [spolyack@web01 ~]$ telnet 10.0.2.80 53 Trying 10.0.2.80... Connected to 10.0.2.80. Escape character is '^]'. 00:03:43.272134 00:0c:29:47:74:26 > 00:a0:c9:00:01:01, ethertype IPv4 (0x0800), length 74: (tos 0x10, ttl 64, id 24383, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.130.20130 > 10.0.2.80.53: Flags [S], cksum 0x0353 (incorrect -> 0xf74d), seq 2674341615, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 60433610 ecr 0], length ... Even after the above, standard UDP DNS requests are still headed to the old default gateway MAC address. tcpdumping and looking at ARP requests/responses doesn't show any traces of the old MAC address either. The switch which connects the server and router doesn't have any entries referencing the old router's MAC address anywhere either. I'm assuming this isn't related to the new flowtable features included in 8.x, since they appear to function on a 4-tuple of src addr, src port, dst addr, and dst port, which isn't going to match for new DNS requests. If anyone has any ideas or suggestions on what additional data I can grab, I'd be happy to investigate further, but I've run out of ideas here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Fwd: ipfw pipe show (freebsd 8.1)
Hi fellows. On freebsd release 7, the 'ipfw pipe show' command shows something like that: fw# ipfw pipe show 10 00010: 1.024 Mbit/s0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 icmp 10.105.71.246/0 10.107.255.246/0 996777 242031672 00 0 The same command on FreeBSD release 8.1 shows: fw# ipfw pipe show 10 00010: 1.024 Mbit/s0 ms burst 0 q131082 50 sl. 0 flows (1 buckets) sched 65546 weight 0 lmax 0 pri 0 droptail sched 65546 type FIFO flags 0x0 0 buckets 0 active Someone knows how to get the same result ( or similar ) on FreeBSD 8 ? Thanks. -- Att, Leonardo Reginin === PROCERGS - Cia. Processamento de Dados do Estado do RS DPR/SSR - Divisão de Produção/Setor de Suporte e Projeto Redes Fone: 55(xx51)3210-3138 'A candle loses nothing by lighting another candle' Erin Majors === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MAC address / per-proto ARP caching in 8.1-RELEASE
On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote: > Is anyone aware of some sort of facility in either FreeBSD > 8.1-RELEASE or the em(4) driver which would cause it to cache MAC > addresses / ARP entries for hosts on a per-protocol basis? > > [snipping remaining details; readers can read it here instead:] > [http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/061908.html] The only thing I can think of would be flowtable, but I'm not sure if it's enabled by default on 8.1-RELEASE-p2. You can try the following sysctl to disable it (I would recommend setting this in sysctl.conf and rebooting; I don't know what happens in the case you set it on a live system that's already experiencing the MAC issue you describe). net.inet.flowtable.enable=0 Details: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MAC address / per-proto ARP caching in 8.1-RELEASE
On 03/15/11 14:26, Jeremy Chadwick wrote: On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote: Is anyone aware of some sort of facility in either FreeBSD 8.1-RELEASE or the em(4) driver which would cause it to cache MAC addresses / ARP entries for hosts on a per-protocol basis? [snipping remaining details; readers can read it here instead:] [http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/061908.html] The only thing I can think of would be flowtable, but I'm not sure if it's enabled by default on 8.1-RELEASE-p2. You can try the following sysctl to disable it (I would recommend setting this in sysctl.conf and rebooting; I don't know what happens in the case you set it on a live system that's already experiencing the MAC issue you describe). net.inet.flowtable.enable=0 Details: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf It looks like it is enabled by default on 8.1-RELEASE. Here's the net.inet.flowtable tree from the box in question: [spolyack@web00 ~]$ sysctl net.inet.flowtable net.inet.flowtable.stats: table name: ipv4 collisions: 1 allocated: 0 misses: 20013 max_depth: 0 free_checks: 377953 frees: 19993 hits: 69519580 lookups: 69539593 net.inet.flowtable.nmbflows: 50176 net.inet.flowtable.tcp_expire: 86400 net.inet.flowtable.fin_wait_expire: 600 net.inet.flowtable.udp_expire: 300 net.inet.flowtable.syn_expire: 300 net.inet.flowtable.enable: 1 net.inet.flowtable.debug: 0 I'm planning on setting net.inet.flowtable.debug=1 next time we see this behavior, but from looking at the code, it looks like we might have to rebuild with -DFLOWTABLE_DEBUG to get really useful information. It's too bad that there is not yet a method to dump the contents of the flowtable. Thanks for the suggestion. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps(4) driver (LSI 6Gb SAS) commited to stable/8
On Sun, Feb 27, 2011 at 09:17:46 -0800, Hubert Tournier wrote: > > Yes, thank you Ken (and everybody involved) for this driver! > > Ken, i think you left out the mps.4 man page from CURRENT in the 8-STABLE > backporting. Whoops, you're right. I just merged it to stable/8. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: statd/lockd startup failure
> On 03/13/2011 08:23, Daniel Braniss wrote: > >> On 03/12/2011 02:21, Daniel Braniss wrote: > >>> The problem with trying to get the same port for all > >>> tcp/udp/inet/inet6 > >>> though might succeed most of the time, will fail sometimes, then > >>> what? > >> > >> Can you please describe the scenario when it's completely > >> impossible to > >> find a port that's open on all 4 families? > > i did not say impossible, concidering that Rick asked how many times > > he > > should try, unless N is forever, it could fail. > > And what I'm asking is that you describe the circumstances which might > lead to that failure. > > >>> I saw Doug's commnent, and also the:), it's not as simple as > >>> tracking port > >>> 80 or 25, needs some efford, but it's deterministic/programable, > >>> and worst case > >>> you can still use the -p option (which again will fail > >>> sometimes:-). > >> > >> Given that Rick has already written the patch, I don't think it's > >> at all > >> unreasonable to put it in as the first choice, perhaps with a > >> fallback > >> to picking any available port if there isn't one available for all > >> 4 > >> families. > >> > > as Rick mentioned, the patch is not trivial, and to quote him: > > "My only concern with the "same port# patch" is that it is more > > complex > >and, therefore, somewhat riskier w.r.t. my having gotten it > >wrong." > > Yeah, I saw that, did you see my response? I'm very much in favor of > keeping things simple, but only as simple as they can be made. > [some good stuff snipped for brevity] Ok, well I believe that the patches I currently have aren't broken. How about I change the patches so that after N attempts fail, it does a final attempt allowing different port#s for the 4 cases. (If that fails, I don't think there is anything that can be done, since it means that no port# is available for at least one of the four cases?) Does that sound reasonable? rick ps: I was thinking N should be somewhere in the 10<->100 range. Anyone want to suggest a value for N? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
