Re: Stacking lots of IP's on a single box - any 'gotchas'?
--On 31 July 2013 23:47 +0400 Sergey Kandaurov pluk...@gmail.com wrote: But is there any hard limit we're likely to encounter putting so many IP's on a single machine? - Are there any limits that would likely need tuning to support that many IP's? Unlikely, besides those unrelated things like ntpd+select() et.al. As far as I know they already split the software handling the IP's between multiple instances (some kind of VPN end points outward facing) - so as long as we say, avoid anything that's going to try and 'select' on all of them - and keep an eye on other things (like mbufs/clusters/fd's etc.) this should work... Thanks for the replies... -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Stacking lots of IP's on a single box - any 'gotchas'?
Hi, We've got a number of boxes we'd like to consolidate - this could mean upward of 1,500 IP's on a single box (9.1 amd64). Last time we did anything like this we hit at issue at around 900 (ntpd 'binds' by default to all available IP's - I think we had a workaround for that). But is there any hard limit we're likely to encounter putting so many IP's on a single machine? - Are there any limits that would likely need tuning to support that many IP's? Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
kldload ipfw, with IPFIREWALL_DEFAULT_TO_ACCEPT
Hi, I've got a number of 9.1 boxes, where we need to enable ipfw (by kldload'ing it). I'm sure I saw a while ago a sysctl that would change the default ipfw config from 'deny all' to 'allow all' - even for a kldload? But I can't find it now. The boxes have a number of CARP interfaces on them - and I don't want them getting blocked during the firewall load - as there's a chance they'll flip to MASTER etc. [as well as cutting everyone on, and going through the box off - even if only momentarily]. So if there's a sysctl for changing the default ipfw behaviour on loading, or someway of getting the ethernet interfaces to 'opt out' of ipfw (until I've added the 'allow all from any to any' rule) - that'd be great, Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kldload ipfw, with IPFIREWALL_DEFAULT_TO_ACCEPT
--On 29 July 2013 13:02 +0200 Stefan Esser s...@freebsd.org wrote: I guess you were looking for: net.inet.ip.fw.default_to_accept=1 which is a tunable to be set in /boot/loader.conf ... Very probably - but that's at boot time :( - Is there nothing I can do at kldload time to have the initial kldload give me a 'allow ip from any to any' rule as it loads? (thus not affecting traffic on the machine, or more importantly the CARP interfaces)? -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kldload ipfw, with IPFIREWALL_DEFAULT_TO_ACCEPT
--On 29 July 2013 12:30 +0100 Simon Dick sim...@irrelevant.org wrote: My normal way is to run the kldload in screen and manually run an allow all right afterwards e.g. kldload ipfw ipfw blah... :) Yeah, that would probably work - I'm more concerned what impact it would have on the CARP interfaces on the box - i.e. if they get 'cut off' even for a fractional period, they may decide they are the new master (or worse, other boxes may decide they need to become the new master). If there's no way of getting a 'default allow' on kldload (other than the workaround kind of way) it looks like I'll just have to plan for a cut off of things like CARP, and design around it :( Cheers, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kldload ipfw, with IPFIREWALL_DEFAULT_TO_ACCEPT
--On 29 July 2013 17:04 +0300 Konstantin Belousov kostik...@gmail.com wrote: kenv net.inet.ip.fw.default_to_accept=1 should have the same effect after the usermode is booted. Kenv must be set before the module is loaded. Great - thanks! - I'll give that a go in the test environment, Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Two Intel E31220L 9.0-Stable systems, 'kern.random' missing on one?
Hi, I have two SuperMicro E31220L based systems - both had identical /etc/sysctl.conf - I then shifted them from 9.0-R to 9.0-Stable (as of 2012/12/03). Now I've noticed of them complains at boot time that a bunch of OID's are missing - and sure enough: sysctl kern.random sysctl: unknown oid 'kern.random' But the other system returns these fine. One system ID's as 'Intel E31220L @ 2.20Ghz' - the other ID's as 'Intel E31220L V2 @ 2.30Ghz' the V2 system is apparently 'missing' the kern.random stuff. The only reason I can think for the OID's not being present is if one system is using hardware RNG? - Though 'man 4 random' states: The only hardware implementation currently is for the VIA C3 Nehemiah (stepping 3 or greater) CPU. More will be added in the future. Is there any other reason why they would have 'disappeared' on the non V2 system? (in fact, looking at the Feature2 line I can see 'RDRAND' on the V2 system, hmm so I'm guessing that's it?!) Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
--On 30 October 2012 19:51 +0200 Konstantin Belousov kostik...@gmail.com wrote: I suggest to take a look at where the actual memory goes. Start with procstat -v. Ok, running that for the milter PID I get seem to be able to see smallish chunks used for things like 'libmilter.so', and 'libthr.so' / 'libc.so' - e.g. 2010 0x40 0x413000 r-x 190 1 0 CN-- vn /usr/local/sbin/milter 2010 0x613000 0x80 rw- 150 1 0 df 20100x8006130000x80062b000 r-x 240 97 0 CN-- vn /libexec/ld-elf.so.1 20100x80062b0000x800634000 rw-90 1 0 df 20100x8006340000x80065f000 rw- 330 1 0 df 20100x80082b0000x80082d000 rw-20 1 0 df 20100x80082d0000x800839000 r-x 12 12 2 1 CN-- vn /usr/lib/libmilter.so.5 20100x8008390000x800a38000 ---00 1 0 df 20100x800a380000x800a39000 rw-10 1 0 C--- vn /usr/lib/libmilter.so.5 20100x800a390000x800a3c000 rw-00 0 0 -- Then there's a bunch of 'large' blocks e.g.. PID STARTEND PRT RES PRES REF SHD FL TP PATH 20100x801c00x80280 rw- 28690 4 0 df 20100x802800x80340 rw- 18800 1 0 df 20100x803400x80380 rw- 9200 1 0 df 20100x803800x80400 rw- 8650 1 0 df 20100x804000x80440 rw- 10240 4 0 df 20100x804400x804c0 rw- 6270 1 0 df 20100x804c00x80500 rw- 10210 4 0 df Then lots of 'little' blocks, 2010 0x70161000 0x70181000 rw- 160 1 0 ---D df 2010 0x70362000 0x70382000 rw- 160 1 0 ---D df 2010 0x70563000 0x70583000 rw- 160 1 0 ---D df 2010 0x70764000 0x70784000 rw- 160 1 0 ---D df 2010 0x70965000 0x70985000 rw- 160 1 0 ---D df 2010 0x70b66000 0x70b86000 rw- 160 1 0 ---D df 2010 0x70d67000 0x70d87000 rw- 160 1 0 ---D df 2010 0x70f68000 0x70f88000 rw- 160 1 0 ---D df 2010 0x71169000 0x71189000 rw- 160 1 0 ---D df The memory usage figures seem to have 'stabilized' now - SIZE/RES seem to track around 9 times the size of the 6.4 system, for a comparative load. We can probably live with this (as they have come back down overnight as load fell off) - i.e. they don't appear to be continuously growing (the binaries were heavily profiled under 6.x and found to have no internal leaks). -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
--On 31 October 2012 16:06 +0200 Konstantin Belousov kostik...@gmail.com wrote: Since you neglected to provide the verbatim output of procstat, nothing conclusive can be said. Obviously, you can make an investigation on your own. Sorry - when I ran it this morning the output was several hundred lines - I didn't want to post all of that to the list 99% of the lines are very similar. I can email it you off-list if having the whole lot will help? Then there's a bunch of 'large' blocks e.g.. PID STARTEND PRT RES PRES REF SHD FL TP PATH 20100x801c00x80280 rw- 28690 4 0 df 20100x802800x80340 rw- 18800 1 0 Most likely, these are malloc arenas. Ok, that's the heaviest usage. Then lots of 'little' blocks, 2010 0x70161000 0x70181000 rw- 160 1 0 ---D df And those are thread stacks. Ok, lots of those (lots of threads going on) - but they're all pretty small. My code only has a single call to malloc, which allocates around 20k per thread. Obviously there's other libraries and stuff running with the code - so would I be correct in guessing that they are more than likely for most of these large blocks? -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
Hi All, Can anyone think of any quick pointers as to why some code originally written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes up a *lot* more memory when running? The code involved is a sendmail Milter, and a TCP server type program (that runs up a large number of threads [~700] at startup). Both were previously compiled with: -O2 -pthread -lc_r They're now compiled under 9.0-S with just: -O2 -pthread As an example, under 6.4 the size/res for one reported by top is 81Mb/48Mb - and for the other is 44Mb/9Mb [this is after it's been running for weeks]. Under 9.0-stable the initial memory used by the processes just after starting rises to 625Mb/128Mb and 519Mb/65Mb respectively. Is that something I need to worry about? They've not been running longing enough yet to see if anything is 'leaking' (i.e. if size/res continues to go up). Just thought I'd ask if there's a simple/possible explanation for this - and if it's something I need to worry about... Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
--On 30 October 2012 11:21 + Steven Hartland kill...@multiplay.co.uk wrote: They've not been running longing enough yet to see if anything is 'leaking' (i.e. if size/res continues to go up). Just thought I'd ask if there's a simple/possible explanation for this - and if it's something I need to worry about... amd64 vs i386? Nice try :) - But as I said in my original email (he says, checking again - yup it's in there ;) both the 6.4 and 9.0 systems are amd64... I'd expect the memory usage to 'go up' between the versions for the programs, I'm just concerned by the size increase... -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
--On 30 October 2012 18:27 +0700 Erich Dollansky erichfreebsdl...@ovitrap.com wrote: is it still the same compiler? Depends how you mean 'the same' - on the 6.4 system it shows: cc (GCC) 3.4.6 [FreeBSD] 20060305 And, on the 9.0-S it shows: cc (GCC) 4.2.1 20070831 patched [FreeBSD] So 'same' - but different versions. I assume that it is a plain FreeBSD program without X. Yes. They are 'plain' programs - no X or anything. Now they've been running for an hour or so - they've gotten a little larger 552M/154M and 703M/75M. If it's not harmful I can live with it - it was just a bit of a surprise. -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
--On 30 October 2012 22:59 +1100 Jan Mikkelsen j...@transactionware.com wrote: -O2 -pthread -lc_r They're now compiled under 9.0-S with just: -O2 -pthread libc_r is a user mode implementation of pthreads, so there is one actual kernel thread with a stack. You now have ~700 kernel threads on startup. Per-thread stack allocation will be different, and you could quite easily explain differences that way. That seems the most fitting explanation so far - aside from seeing if I can cut back on the number of threads, I presume there's no issue with having that many kicking around - the RES size is still quite 'small' (still waiting to see if anything is 'leaking') - and if ~700 threads happily ran under user mode pthreads - it should still perform at least 'similarly' with kernel threading? -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
--On 30 October 2012 19:43 +0700 Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Depends how you mean 'the same' - on the 6.4 system it shows: cc (GCC) 3.4.6 [FreeBSD] 20060305 And, on the 9.0-S it shows: cc (GCC) 4.2.1 20070831 patched [FreeBSD] So 'same' - but different versions. did you check the default data sizes? How do you mean? Now they've been running for an hour or so - they've gotten a little larger 552M/154M and 703M/75M. If it's not harmful I can live with it - it was just a bit of a surprise. And a reason to spend more money on memory. Knowing the real reason would be better. I can understand your surprise. Hehe, more 'concern' than surprise I guess now... The sendmail milter has grown to a SIZE/RES of 1045M / 454M under 9.0. The original 6.4 machine under heaver load (more connections) shows a SIZE/RES of 85M/52M. The TCP listener code is now showing a SIZE/REZ of 815M/80M under 9.0 with the original 6.4 box showing 44M/9.5M The 9.0 box says it has 185M active, 472M inactive, 693M wired, 543M buf, and 4554M free. At this stage I'm just a bit concerned that at least the milter code is going to grow, and grow - and die. I would think it would last over night so I'll see what the figures are in the morning. Thanks for the replies... -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FreeBSD 9.0-R em0 issues?
Hi, I've got a SuperMicro X8DTL-IF based server (with Intel L5630), 6Gb of RAM and two onboard Intel NIC's. afaik this is running the stock FreeBSD 9.0-R GENERIC kernel. em0: Intel(R) PRO/1000 Network Connection 7.2.3 port 0xdc00-0xdc1f mem 0xfbce-0xfbcf,0xfbcdc000-0xfbcd irq 16 at device 0.0 on pci6 em0: Using MSIX interrupts with 3 vectors em0: Ethernet address: 00:25:90:31:82:46 em0: link state changed to UP em1: Intel(R) PRO/1000 Network Connection 7.2.3 port 0xec00-0xec1f mem 0xfbde-0xfbdf,0xfbddc000-0xfbdd irq 17 at device 0.0 on pci7 em1: Using MSIX interrupts with 3 vectors em1: Ethernet address: 00:25:90:31:82:47 em0 is the only one in use, and it 'freezes' every now and again. Symptoms are no traffic in, or out - but pretty 'insane' figures from 'netstat -i' e.g. NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll em01500 Link#5 00:25:90:31:82:46 610815304 22999549864725 0 518403896 6571299961350 3285649980675 The machines ARP cache expires at the time, and tcpdump shows no data at all on that interface. The switch port this is connected to disagrees with the errors (it has non logged currently for that port). The machine is a lightly loaded MySQL host. Considering the above was taken 'seconds' after the NIC stopped - I can't really see it had logged billions of legitimate errors in that small time frame? Doing an 'ifconfig em0 down' and 'ifconfig em0 up' makes no difference when it's hung. Rebooting the machine fixes the problem 'for a while'. Once rebooted no Oerrs, Coll errors or anything are shown by netstat -i Any suggestions what this could be? - Or what I can do to diagnose further? Nothing is logged on the console, or /var/log/messages When it failed last time, I did 'sysctl dev.em.0.debug=1' which netted: Interface is RUNNING and INACTIVE em0: hw tdh = -1, hw tdt = -1 em0: hw rdh = -1, hw rdt = -1 em0: Tx Queue Status = 1 em0: Tx descriptors avail = 986 em0: Tx Descriptors avail failure = 0 em0: RX discarded packets = 0 em0: RX Next to Check = 844 em0: RX Next to Refresh = 843 Should I be concerned about the '-1's? Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD 9.0-R em0 issues? - update...
The last time it hung, 'netstat -n -i' showed: NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll em01500 Link#5 00:25:90:31:82:46 355482 10612864185945 0 291109 3032246910270 1516123455135 That's from about 30 seconds after the interface 'stopped' - that number of ierrs/oerrs etc. - is just impossible for the traffic the machine handles, it looks like it's corrupt? Having dug around some more - I've now set: hw.em.enable_msix=0 After rebooting - the hang hasn't happened since - I'll leave it running like that for a while. If anyone can suggest anything to run when / if this happens again to track things down further - or any reason why it's doing it, that'd be great.. -Karl ps. Should have said before but the machine is running an amd64 kernel. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperMicro IPMI keyboard - fails for 'mountroot' prompt under FreeBSD 9-R...
--On 01 March 2012 07:59 -0800 Garrett Cooper yaneg...@gmail.com wrote: Do you mean (looking at the man page) just setting: hint.kbdmux.0.disabled=1 In device.hints? That didn't make any difference - nor, (just in case) did setting it to '0'. Are you sure it's compiled into the kernel? It's in GENERIC, but I'm not sure what you're running... -Garrett Sorry, yes - it's running GENERIC (i.e. stock 9.0-R GENERIC). -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperMicro IPMI keyboard - fails for 'mountroot' prompt under FreeBSD 9-R...
--On 29 February 2012 07:50 -0800 Garrett Cooper yaneg...@gmail.com wrote: The BIOS has an option for port 60/64 emulation - I've tried enabling it (didn't seem to make any difference with nothing changed on the FreeBSD side) - is there any way to coax the system to prefer / use what would appear to be a PS/2 keyboard at that stage? Have you tried kbdmux(4) yet? Do you mean (looking at the man page) just setting: hint.kbdmux.0.disabled=1 In device.hints? That didn't make any difference - nor, (just in case) did setting it to '0'. -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperMicro IPMI keyboard - fails for 'mountroot' prompt under FreeBSD 9-R...
--On 28 February 2012 10:47 -0800 Sean Bruno sean...@yahoo-inc.com wrote: Can you dump the full dmesg on boot? I've noted that shared ethernet devices and IPMI seem to conflict. Expecially if the kernel is explicity turning off the ethernet device becuase its not configured. Sean Sure - rather than clutter the list with wrapped / unwrapped lines, you can find it here: http://www.tdx.com/x8dtl-if.txt If you need me to try anything / further info, let me know. This machine is in our staging area at the moment - it's not in production yet. The RAID shows as degraded during boot as it'd only just been setup (and the machine hadn't been idle for long enough when booted yet to finish rebuilding - think it finished at the bottom of the dmesg output, just incase you were wondering :) Regards, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperMicro IPMI keyboard - fails for 'mountroot' prompt under FreeBSD 9-R...
--On 29 February 2012 12:44 +0200 Andriy Gapon a...@freebsd.org wrote: on 29/02/2012 11:47 Karl Pielorz said the following: http://www.tdx.com/x8dtl-if.txt So the cause is that ukbd driver tries to attach after the mountroot stage. The symptom is obvious, a fix is not. The BIOS has an option for port 60/64 emulation - I've tried enabling it (didn't seem to make any difference with nothing changed on the FreeBSD side) - is there any way to coax the system to prefer / use what would appear to be a PS/2 keyboard at that stage? -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperMicro IPMI keyboard - fails for 'mountroot' prompt under FreeBSD 9-R...
--On 27 February 2012 12:04 + Karl Pielorz kpielorz_...@tdx.co.uk wrote: Once the kernel is loading you see: Sorry - that should be, once the O/S is booting, not kernel loading - you see: ... ugen1.2: Winbond Electronics Corp at usbus1 ums0: Winbond Electronics Corp Hermon hidmouse Device, class 0/0, rev 1.10/0.01, addr 2 on usbus1 ums0: 3 buttons and [Z] coordinates ID=0 ukbd0: Winbond Electronics Corp Hermon USB hidmouse Device, class 0/0, rev 1.10/0.01, addr 2? on usbus1 kbd2 at ukbd0 -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
SuperMicro IPMI keyboard - fails for 'mountroot' prompt under FreeBSD 9-R...
Hi, We have a number of SuperMicro based systems (e.g. an X8DTL-IF) - this is running the latest BIOS (2.1a) - and the latest (supplied by SuperMicro) IPMI firmware - 2.44. We're using FreeBSD 9.0-R amd64. When using the LAN KVM keyboard (IPMI) - it works for the BIOS (as you'd expect) - it works for the Beastie boot menu prompt, and it works for when the O/S is booted. However, it doesn't work if the boot fails, e.g. if you get stuck at: mountroot I've tried changing a few things in the BIOS (such as EHCI handoff, legacy port 60/64 support, legacy USB support) - but nothing I change in there makes any difference. Once the kernel is loading you see: ugen1.2: Winbond Electronics Corp at usbus1 ums0: Winbond Electronics Corp Hermon hidmouse Device, class 0/0, rev 1.10/0.01, addr 2 on usbus1 ums0: 3 buttons and [Z] coordinates ID=0 ukbd0: Winbond Electronics Corp Hermon USB hidmouse Device, class 0/0, rev 1.10/0.01, addr 2? on usbus1 kbd2 at ukbd0 I've tried with a PS2 keyboard attached, and removed from the physical server - but it doesn't change anything. We have notes here for FreeBSD 8 to recompile the kernel with: nodevice ums To fix a previous KVM issue with SuperMicro - but this doesn't fix the above issue. Any clues on how I can fix / troubleshoot this further? The keyboard does work at the Beastie boot menu, and again once the O/S is loaded - but obviously having it work when the kernel has failed to load, would be handy :) Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Using underlying adX devices as well as ar0?
Hi, I posted this question in -Questions about a week ago, and didn't get any replies :( I'm just trying to check - we have a number of 8.2-STABLE amd64 systems where the onboard RAID shows up as '/dev/ar0' (which we use for filesystems, i.e. /dev/ar0s1d et'al), and the underlying devices for that RAID1 array show up as '/dev/ad12', '/dev/ad14'. Is it OK to run smartmontools / smartd / smartctl against the underlying adX devices, whilst ar0 is in use? I can't see anywhere that seems to indicate it's bad - and I can't seem to find anywhere that seems to say it's Ok... Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Using underlying adX devices as well as ar0?
--On 01 September 2011 07:45 -0500 Mark Felder f...@feld.me wrote: Is it OK to run smartmontools / smartd / smartctl against the underlying adX devices, whilst ar0 is in use? Yes. :-) Thanks :-) I'll look for other reasons why one of the machines mysteriously locked up with everything hung in 'ufs' [you can see why I asked now! :)] -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
8.1-R - Marvell 88SX6081 SATA controller via mvs = lots of errors
Hi, I just switched my 8.1-R/amd64 (dual Opteron) system from ATA over to the new mvs driver, and started seeing a whole bunch of errors (which appear to have hosed one of my zfs volumes during a scrub) - anyone know what the following errors actually mean? The machine has 2 * 88SX6081's in it: Sep 28 19:58:49 kernel: mvs0: Marvell 88SX6081 SATA controller port 0x3000-0x30ff mem 0xd010-0xd01f,0xd040-0xd07f irq 24 at device 4.0 on pci17 Sep 28 19:58:49 kernel: mvs0: Gen-II, 8 3Gbps ports, Port Multiplier ... Sep 28 19:58:49 kernel: mvs1: Marvell 88SX6081 SATA controller port 0x4000-0x40ff mem 0xd0c0-0xd0cf,0xd080-0xd0bf irq 28 at device 4.0 on pci18 Sep 28 19:58:49 kernel: mvs1: Gen-II, 8 3Gbps ports, Port Multiplier supported Under 7.2 they ran fine, with the ATA driver. I use ZFS on this machine - and both pools were scrubbed before the upgrade (and backed up fortunately!). With the mvs driver, during a scrub of the main volume, I see: Sep 29 08:56:13 kernel: mvsch12: EMPTY CRPB 6 (-14) 1 4000 Sep 29 08:56:13 kernel: mvsch12: EMPTY CRPB 7 (-14) 0 4000 Sep 29 08:56:13 kernel: mvsch12: EMPTY CRPB 8 (-14) 2 4000 [repeated a lot - interspersed with zfs reporting problems with files, on all the devices in the pool] I then also get a whole bunch of: Sep 29 08:56:56 kernel: mvsch0: Timeout on slot 1 Sep 29 08:56:56 kernel: mvsch0: iec 0200 sstat 0123 serr edma_s 1020 dma_c dma_s rs 0006 statu s 40 Sep 29 08:56:56 kernel: mvsch0: ... waiting for slots 0004 Sep 29 08:56:56 kernel: mvsch12: Timeout on slot 5 Sep 29 08:56:56 kernel: mvsch12: iec 0200 sstat 0123 serr edma_s 1121 dma_c dma_s rs 0028 stat us 40 The system has 2 pools (one is 12 disks of mirrored pairs - each side of the mirror is on alternate Marvell's), the other is 1 RAIDZ of 4 disks, 2 are on alternate Marvell's - the other 2 drives are on the motherboards nForce CK804 ports). I scrubbed the second pool yesterday without incident, so this only seemed to happen using drives exclusively on the 88SX6081's (or the I/O system is stressed, running the I/O for all 12 drives through the Marvells, as opposed to just the I/O for 2 drives [1 each] through the Marvells when the other pool is scrubbed). -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
7.3-STABLE 'zfs attach' results in geom guid mismatch?
Hi All, This is related to a post I made the other day in freebsd-fs, which didn't get any replies (I'm a bit desperate as I need to replace a failing drive on the system - hence need to attach a spare - so apologies for the kind of cross-post)... I'm running 7.3-STABLE on an amd64, w/10Gb of RAM, and 2 * dual core Opteron 285's. When I do a 'zfs attach' the system hangs with no I/O - everything that touches zfs hangs. Doing some digging around (turning on ZFS debug) I see: host# zfs attach vol ad34 ad40 vdev_geom_attach:112[1]: Attaching to ad40. vdev_geom_attach:153[1]: Created consumer for ad40. vdev_geom_read_guid:334[1]: guid for ad40 is 13247785578180267154 vdev_geom_detach:173[1]: Closing access to ad40. vdev_geom_detach:177[1]: Destroyed consumer to ad40. vdev_geom_open_by_path:472[1]: guid mismatch for provider /dev/ad40: 835553262974889329 != 13247785578180267154. vdev_geom_open_by_guid:430[1]: Searching by guid [835553262974889329]. Should I be worried about that first mismatch for provider? It then seems to iterate through all the disk devices on the system (including some ZFS 'volumes') before appearing to hang on one of those (i.e. with GEOM debug turned on) the end of output is: ... Jul 5 19:42:50 host kernel: g_access(0xff0035015380(zvol/vol2/zfs_backups/scanned), 1, 0, 0) Jul 5 19:42:50 host kernel: open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xff000e1fd000(zvol/vol2/zfs_backups/scanned) Jul 5 19:42:50 host kernel: g_access(0xff0035015380(zvol/vol2/zfs_backups/scanned), -1, 0, 0) Jul 5 19:42:50 host kernel: open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xff000e1fd000(zvol/vol2/zfs_backups/scanned) Jul 5 19:42:50 host kernel: g_detach(0xff0035015380) Jul 5 19:42:50 host kernel: g_access(0xff0035015380(zvol/vol/scan...@1237495449), 1, 0, 0) Jul 5 19:42:50 host kernel: open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xff000e60b300(zvol/vol/scan...@1237495449) [hangs here] ps axl at that point shows: 0 2250 2004 0 -8 0 14460 2044 g_wait D+p00:00.01 zpool attach vol ad34 ad40 So it appears to be hung in 'g_wait'. Any suggestions? -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
ZFS'inodes' (as reported by 'df -i') running out?
Hi All, I originally posted this in freebsd-fs - but didn't get a reply... I have a number of systems (mostly 7.2-S/amd64) running ZFS. Some of these handle millions of files. I've noticed recently, according to df -i I'm starting to run out of inodes on some of them (96% used). e.g. Filesystem iusedifree %iused Mounted on vol/imap 1726396 69976 96% /vol/imap I know ZFS doesn't have inodes (think they're znodes), and is capable of handling more files than you can probably sensibly think about on a filesystem - but is df -i just getting confused, or do I need to be concerned? Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS'inodes' (as reported by 'df -i') running out?
--On 18 February 2010 12:41 +0100 Ivan Voras ivo...@freebsd.org wrote: I know ZFS doesn't have inodes (think they're znodes), and is capable of handling more files than you can probably sensibly think about on a filesystem - but is df -i just getting confused, or do I need to be concerned? AFAIK ZFS allocates inodes when needed so df -i reports the previously allocated value. The number of available inodes should automatically grow as you add more files. Fantastic! Thanks for the clarification - I though it'd be something like that, but thought I'd better check before running out, Regards, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
ata 'Flush Cache' errors, on non-failing disk?
Hi, I've recently updated my amd64 system from 6.4 to 7.2-Stable - this works fine, but I've started picking up errors on the console: ad36: TIMEOUT - FLUSHCACHE retrying (1 retry left) The drive (an WD5000AAKS) appears healthy - SMART reports no errors, or problems - and the timeouts only appear when that drive is 'being hammered' by write requests (e.g. during ZFS re-silvering to it) The Western-Digi drive doctor CD/ISO runs a full test, and reports no problems (in that machine, with that drive). I did find a number of posts, such as: http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005939.html Which point to the default timeout for the ATA flushcache command being 5 seconds, when perhaps it should be 30... But the code in 7.2-STABLE bears no resemblance to the code that the patch is for - so I'm guessing things have moved on since then... Is there anywhere I might apply a similar patch to up the timeout to see if that cures the problem? The only mentions of ATA_FLUSHCACHE appears to be calls to ata_controlcmd( , ATA_FLUSHCACHE, 0, 0, 0); - ata_controlcmd in turn seems to set a request timeout of '1' - but I can't tell if that's a timeout of 1 second, 1 tick, or 1 what - or if it's a timeout for adding the command to the queue, or actually a timeout for executing that command... Is upping that request timeout conditionally for cache flushes likely to have the effect I'm looking for? -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Tyan S2895 7.1 amd64 8Gb RAM support? - resolved
Hi, I finally resolved this... (posted to the list for completeness / incase someone else hits this issue). Brief Solution: Reduce dram timing in the bios from DDR400 to DDR333. Gory details: Having taken quite a trip through mptables, bioses, pulling / pushing DIMM's etc. - all the DIMM's in the machine are DDR400 rated - all do test OK. Also remember this machine was used for years under WinXP64/Vista (including using things like a 6Gb RAM drive for video production) - if it had been corrupting data as much as under FreeBSD it would have been noticed :( Anyway, it transpires earlier Opterons were either incapable of running DDR400, or had a 'caveat' that when running lots of memory modules they recommended dropping the timing from DDR400 downwards. This was 'apparently' fixed in later Opterons (my system has 2 * E Stepping 285's). To counter this the BIOS would detect which CPU was in use, and drop the maximum memory speed accordingly vs. installed DIMM slots. This restriction was apparently lifted for Opteron 285's (at least for the stepping I'm using) as their onboard memory controller should be capable of driving all memory banks, at DDR400 speeds - the BIOS reflects this by defaulting to DDR400 timing for my system. Obviously, this works on this system under Windows memory usage patterns / loading / stress - but not for FreeBSD's memory usage / loading. With the RAM backed down to DDR333 - the system once again runs flawlessly. RAM tests didn't catch this - as I could only effectively test 4Gb of RAM 'at a time' - I also doubt that the memory usage patterns software such as memtest86 use would 'load' the memory system enough to cause the timing problem. Max Laier did say he'd had to make memory timing adjustments on his S2895 system, but I presumed that with DDR400 rated memory, and the BIOS using the SPD details on the chips (all branded RAM) that it wouldn't be that (and the fact windows gave years of service with the current settings). -Kp [Who now knows far more than I ever wanted to about mptables, APIC, ASL and hopefully a whole bunch of other stuff I can forget now ;)] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Tyan S2895 7.1 amd64 8Gb RAM support?
--On 13 February 2009 20:08 +0100 Max Laier m...@love2party.net wrote: Can you maybe try to take the nVidia RAID out of the equation? I figure the professional version of the chip is not that common so maybe the corruption stems from the disk controller. Hi, I've tested with both Marvell (PCI-X), and Promise (PCI 32 Bit) SATA controllers now - it makes no difference. I upgraded the BIOS on the machine, and did a CMOS reset, then load factory defaults. I also then slowly upped the hw.physmem setting to see what would happen. I can now get this running at 8Gb [I've changed the email subject accordingly]. Any attempt to go over that (or remove the line from loader.conf completely) and it ends in the previous random crashes, compiler errors (e.g. warnings of internal bugs in gcc) - and occasional sig11's... e.g. From compiling the kernel one time I got: mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/src/sys/amd64/compile/GENERIC /usr/src/sys/modules/uslcom/../../dev/usb/uslcom.c === utopia (depend) @ - /usr/src/sys /libexec/ld-elf.so.1: /lib/libc.so.7: Unsupported relocation type 88 in non-PLT relocations I could probably live with only 8Gb in the machine, but it's going to be running some large ZFS pools (and a number of other tasks) - I'd like to have all 10Gb usable (especially if I move to 8.x eventually - and obviously, as it's physically in there, it'd be good to 'use it') Can anyone think of anything that is likely to break if you go 8Gb? [up from 4Gb since the BIOS was reflashed/reset factory defaulted]. -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Tyan S2895 7.1 amd64 4Gb RAM support?
Hi, I've a Tyan S2895 (bios 1.04), w/10Gb of ECC RAM onboard using 2 * Opteron 285's. The machine used to run WinXP x64, and Vista x64 (mostly doing video production, ray tracing etc.) I recently switched this machine to FreeBSD 7.1 amd64 - to run ZFS on it, but I've been having horrific problems with it. Basically, with more than ~3Gb of RAM usable in the system - it shows signs of chronic RAM problems (everything from sig11's through to failing to compile the kernel with 'weird' errors - as well as kernel panics, and spontaneous reboots). I've tested all the RAM (ECC is enabled on the BIOS) - it all tests fine (even if I jumble it up between different simms in different sockets etc.) By setting: hw.physmem=3G In loader.conf - I get a stable system. I've not setup any ZFS pools or anything yet, until I get the system stable. I've also tried changing the BIOS settings for the Memory Hole, IOMMU, MTRR etc. - all to no avail (nor does a BIOS 'use safe defaults' make any difference). It boots off the onboard nVidia RAID controller (a pair of 36Gb drives configured as RAID1), this shows up as: atapci0: nVidia nForce CK804 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] atapci1: nVidia nForce CK804 SATA300 controller port 0x1440-0x1447,0x1434-0x1437,0x1438-0x143f,0x1430-0x1433,0x1410-0x141f mem 0xc0002000-0xc0002fff irq 22 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: ATA channel 0 on atapci1 ata2: [ITHREAD] ata3: ATA channel 1 on atapci1 ata3: [ITHREAD] atapci2: nVidia nForce CK804 SATA300 controller port 0x1458-0x145f,0x144c-0x144f,0x1450-0x1457,0x1448-0x144b,0x1420-0x142f mem 0xc0003000-0xc0003fff irq 23 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: ATA channel 0 on atapci2 ata4: [ITHREAD] ata5: ATA channel 1 on atapci2 ata5: [ITHREAD] ... ad8: 35304MB WDC WD360GD-00FNA0 35.06K35 at ata4-master SATA150 ad10: 35304MB WDC WD360GD-00FNA0 35.06K35 at ata5-master SATA150 ... ar0: 35304MB nVidia MediaShield RAID1 status: READY ar0: disk0 READY (master) using ad10 at ata5-master ar0: disk1 READY (mirror) using ad8 at ata4-master Trying to mount root from ufs:/dev/ar0s1a Anyone got any ideas? - At this time, I can't prove 100% whether it's the disk controller messing up and corrupting data as it's loaded into RAM, or data getting corrupt once in RAM that's causing the crashes - all I know is with ~3Gb RAM - either by physically pulling SIMMs or using the hw.physmem option - it works fine. I tried booting 8.0-CURRENT-200812-amd64-disc1.iso - to see if anything was different with this hardware in 8.0 - but unfortunately that doesn't boot past the BTX loader on this machine, regardless of how much RAM is / isn't in it :( -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
ZFS w/failing drives - any equivalent of Solaris FMA?
Hi, Recently, a ZFS pool on my FreeBSD box started showing lots of errors on one drive in a mirrored pair. The pool consists of around 14 drives (as 7 mirrored pairs), hung off of a couple of SuperMicro 8 port SATA controllers (1 drive of each pair is on each controller). One of the drives started picking up a lot of errors (by the end of things it was returning errors pretty much for any reads/writes issued) - and taking ages to complete the I/O's. However, ZFS kept trying to use the drive - e.g. as I attached another drive to the remaining 'good' drive in the mirrored pair, ZFS was still trying to read data off the failed drive (and remaining good one) in order to complete it's re-silver to the newly attached drive. Having posted on the Open Solaris ZFS list - it appears, under Solaris there's an 'FMA Engine' which communicates drive failures and the like to ZFS - advising ZFS when a drive should be marked as 'failed'. Is there anything similar to this on FreeBSD yet? - i.e. Does/can anything on the system tell ZFS This drives experiencing failures rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears to be the case). In the end, the failing drive was timing out literally every I/O - I did recover the situation by detaching it from the pool (which hung the machine - probably caused by ZFS having to update the meta-data on all drives, including the failed one). A reboot bought the pool back, minus the 'failed' drive, so enough of the 'detach' must have completed. The newly attached drive completed the re-silver in half an hour (as opposed to an estimated 755 hours and climbing with the other drive still in the pool, limping along). -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS w/failing drives - any equivalent of Solaris FMA?
--On 12 September 2008 06:21 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: As far as I know, there is no such standard mechanism in FreeBSD. If the drive falls off the bus entirely (e.g. detached), I would hope ZFS would notice that. I can imagine it (might) also depend on if the disk subsystem you're using is utilising CAM or not (e.g. disks should be daX not adX); Scott Long might know if something like this is implemented in CAM. I'm fairly certain nothing like this is implemented in ata(4). For ATA, at the moment - I don't think it'll notice even if a drive detaches. I think like my system the other day, it'll just keep issuing I/O commands to the drive, even if it's disappeared (it might get much 'quicker failures' if the device has 'gone' to the point of FreeBSD just quickly returning 'fail' for every request). Ideally, it would be the job of the controller and controller driver to announce to underlying I/O operations fail/success. Do you agree? I hope this FMA Engine on Solaris only *tells* underlying pieces of I/O errors, rather than acting on them (e.g. automatically yanking the disk off the bus for you). I'm in no way shunning Solaris, I'm simply saying such a mechanism could be as risky/deadly as it could be useful. Yeah, I guess so - I think the way it's meant to happen (and this is only AFAIK) is that FMA 'detects' a failing drive by applying some configurable policy to it. That policy would also include notifying ZFS, so that ZFS could then decide to stop issuing I/O commands to that device. None of this seems to be in place, at least for ATA under FreeBSD - when a drive goes bad, you can just end up with 'hours' worth of I/O timeouts, until someone intervenes. I did enquire on the Open Solaris list about setting limits for 'errors' in ZFS, which netted me a reply that it's FMA (at least in Solaris) that's responsible for this - it just then informs ZFS of the condition. We don't appear (again at least for ATA) to have anything similar for FreeBSD yet :( -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'?
--On 20 October 2006 13:47 +0100 Robert Watson [EMAIL PROTECTED] wrote: I'm just a little hesitant to put it all in, and end up with a machine that's 80% slower :( Depends a lot on your workload. WITNESS used to really, really slow things down for kernel lock intensive workloads (VFS especially); now it just really slows things down. INVARIANTS overhead is generally measurable, but for most workloads it is likely 20%. The place INVARIANTS hits you is when the kernel is allocating and freeing lots of memory, during which INVARIANTS will be scrubbing and checking for use after free, etc. It's worth running with WITNESS when debugging deadlocks if possible, because it is, essentially, a deadlock debugging tool. A moderate number of people run with INVARIANTS in production, but you generally don't want to do that with WITNESS. Well this is happening on an almost daily basis for me, so I threw everything in. I'd rather have lousy performance for a couple of days - and get all the info needed to fix the problem, than fsck a terrabyte, and mop up after a hung machine daily ;) Thanks for the replies, crossing fingers now :) -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1-STABLE hangs, ddb shows 'acpi_timer_read'?
Hi All, We've got an HP DL380 server, stacked out with drives running Sendmail. The machine is quite busy (LA rarely below 4 - and it's three 'spindle' sets of RAID drives are always busy). It's probably constantly running 200-300 copies of sendmail, plus an assortment of other processes (mostly admin scripts that kind of thing). It's got a Xeon 3.2Ghz CPU (HT disabled), w/2Gb of RAM running a generic kernel, w/out IPv6 support (and with DDB/KDB included obviously) This machine just 'hangs' every couple of days. I have DDB/KDB compiled in - and if I throw it into DDB I get the following: [first couple of lines missed courtesy of screen-dump] db bt Tracing pid 38 tid 100027 td 0xc6495180 acpi_timer_read(c0aba3c0,c09035c0,e6a05bbc,c0662ef3,c0aba3c0) at acpi_timer_read+0x13 acpi_timer_get_timecout_safe(c0aba3c0) at acpi_timer_get_timecount_safe+0xa binuptime(e6a05be8) at binuptime+0x43 mi_switch(6,c6395900,c639a54,c639500,e6a05c34) at mi_swtich+0x33 maybe_preempt(c6395900) at maybe_preempt+0xc4 sched_add(c639500,4,c6495180,c6395900,c637f280) at sched_add+0x27 setrunqueue(c6395900,4) at setrunqueue+0x63 intr_even_schedule_thread(c637f280) at intr_event_schedule_thread+0xb5 intr_exectue_handlers(c638d6e0,e6a05cac,13,46a05cf4,c08189f3) at intr_execute_handlers+0x118 ... I have a crash dump from it - which I've saved (I'm moderately familiar with working with dumps, but this one is split into two?) If anyone has any pointers, or can do some hand holding to get more info from the dump, or what to do next time it happens? Cheers, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'?
--On 20 October 2006 14:01 +0300 Kostik Belousov [EMAIL PROTECTED] wrote: On Fri, Oct 20, 2006 at 11:56:33AM +0100, Karl Pielorz wrote: I have a crash dump from it - which I've saved (I'm moderately familiar with working with dumps, but this one is split into two?) If anyone has any pointers, or can do some hand holding to get more info from the dump, or what to do next time it happens? See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern eldebug-deadlocks.html Thanks for the link! Anyone know much is all that lot (such as INVARIANTS/WITNESS) etc. likely to slow the machine down? - A few percent? More? I'm just a little hesitant to put it all in, and end up with a machine that's 80% slower :( -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Keyboard 'fails' in ddb on HP Proliant DL380 under 6.1-RC1
Hi All, We've recently started using HP Proliant DL360's / 380's - and we're also moving our new machines to FreeBSD 6.1 I've found a problem with ddb - no matter what I do, I can't get the keyboard on the server to work, when it's dropped into ddb. I've tried HP's iLO management (virtual console / keyboard) - and, thinking maybe that was messing up - plugging in a real keyboard and monitor into the server, and avoiding iLO. No matter how you end up in ddb (through a console command, a real 'panic', NMI, 'break' or Ctrl-Alt-Esc) - once you're there - the keyboard is dead. I've checked the manpage for 'atkbd' - but can't see anything obvious. These machines running 5.3/4 work fine - it's just under 6.x the problem appears. You can find a verbose boot output at: http://www.tdx.com/verbose_6.1rc1.txt Anyone got any suggestions? - We've also found a potential problem with the ciss driver, but I can't even start to look at that until ddb is useable :( Cheers, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard 'fails' in ddb on HP Proliant DL380 under 6.1-RC1
--On 27 April 2006 16:34 +0400 Andrey V. Elsukov [EMAIL PROTECTED] wrote: Karl Pielorz wrote: I've found a problem with ddb - no matter what I do, I can't get the keyboard on the server to work, when it's dropped into ddb. Try to boot in safe mode: http://docs.freebsd.org/cgi/mid.cgi?4437E1AD.7000303 Yup, pfft - no idea how I managed to miss finding that post :( - It wasn't for want of looking... Oh well, one problem kind of down, one to go :) Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 Beta #3 - IDE Problems? (Intel / ICH6 based laptop)
--On 05 September 2005 21:52 +0400 Stanislav Sedov [EMAIL PROTECTED] wrote: How does your SATA controller operate? Try to use LEGACY mode. Do you mean in the BIOS? - If so, there's no adjustments for this that I can see in the BIOS :( Infact, in keeping with most modern laptops - the 'fiddle-ability' level in the BIOS is pretty minimal :( -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.0 Beta #3 - IDE Problems? (Intel / ICH6 based laptop)
Hi All, I recently tried to boot the FreeBSD 6.0 Beta #3 on my laptop, and ran into a problem. The hard drive controller probes as: atapci0: Intel ICH6 SATA150 contoller port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 17 at device 31.2 on pci0 ... ad0: 57231MB HTS726060M9AT100/MH40A6EA [116280/16/63] at ata0-master UDMA100 But I then get the following spewed out: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721023 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=0 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721022 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=1 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721023 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=0 ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=4ABORTED LBA=11721017 Sysinstall cautions me that the Geometry for the drive is unlikely, and that it's using a more sensible one (it displays 7296/255/63, with 117210240 blocks). The drive itself is partitioned already (with a WinXP partition, and a FreeBSD slice, from an older 5.x install) - however, sysinstall claims it can't see any of that and the drive is all unused. The laptop itself is a Dell XPS Gen 2. Any suggestions? Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 Beta #3 - IDE Problems? (Intel / ICH6 based laptop)
--On 05 September 2005 19:31 +0400 Stanislav Sedov [EMAIL PROTECTED] wrote: Try to disable ACPI - it can helps. There may be some problems with ACPI on your laptop - BIOS update sometime helps. But first try to disable ACPI during FreeBSD boot. Latest BIOS on the machine already (apparently published sometime in August, '05) - No difference at all with ACPI disabled, apart from one PNP warning [which is understandable] and appeared to be something to do with the onboard sound. -Karl ps. When I said 'slice' in my earlier post, I meant partition - the hard drive has a WinXP partition, and a FreeBSD partition with the various slices on it, which Sysinstall doesn't see at all at installation time (in case anyone was rolling eyes g)... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Critical (or equivalent) section in Userland?
Warner Losh wrote: Kill sendmail's root process. That's the best you can do. It won't impact anything, it will prevent the reading of the queue files (and the config files) and the children will just run with the old copies. then you wait for all the children to die (with a reasonable timeout). Then you do your change, then restart sendmail. That's the best you can hope for. Unforuntately this doesn't work, as sendmails numerous children live for too long (the machine is a busy MX, and people increasingly mail 5Mb+ files around) Also adding to the children's lives is the fact that sendmail uses cached connections to delivery multiple messages to the same destination MX, which leads to even longer 'death' times, and can also result in Sendmail's kids looking up domains etc. in the config files :( [At least, that's what appears to be happening after a lot of observation]... However, 'killall -SIGSTOP sendmail' - appears to work very nicely... With a 'killall -SIGCONT sendmail' putting things back to normal. I'm also doing the stop twice for good measure incase anything was forking at the time. I guess only time will tell, but the signal idea seems the best so far, considering the other restrictions :) Regards, Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Critical (or equivalent) section in Userland?
Thomas Valentino Crimi wrote: Take a look at rtprio(2), giving yourself a realtime priority will guarantee you the CPU until you explicitly release it (or another higher priority realtime process comes along). I'm not sure if the same deadlock potential that exists with giving a process an idle priority exists due to locking in the kernel, although I see no mention of it in the man pages. It's definitely something I'd be wary of, though. Thanks, I'll look at that... Presumably, even though my process is making syscalls, when they're completed - the scheduler _should_ look to run me first, due to the very high priority? If this doesn't work - I think I'm going to have to look to fixing the problem (and removing the need to 'put the world on hold' while the program tinkers with a few files)... -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Critical (or equivalent) section in Userland?
Warner Losh wrote: If advisory locks won't work (and they almost always will for things like this), then you could walk the process tree. For all processes that aren't suspended or yourself, send a SIGSTOP, keep a list. I don't think advisory locks will work - the other process is sendmail... I have to keep it from opening any of it's config files, whilst I 'rename' out of place the old ones (keeping any fd's to them intact) and rename in the new ones... Killing / stopping the root sendmail doesn't work (as children making multiple deliveries still apparently open these files at will) - and killing all of them isn't really an option either (as too many emails will be dropped, this means junking say, a 90% of the way through 3mb email delivery - only to have to resend/process it again from scratch). going through the tree while you keep finding processes. SIGSTOP can't be caught or blocked, so you know you've stopped them). Do your operation, then send SIGCONT to all the processes that you sent a SIGSTOP to. I like the sound of this... The only race I could see would be if one of the sendmail's had issued the open() to open the file, but on the other hand, it will either get 'stopped' before this syscall (in which case it will open() the 'new' file when it gets continued), or it will get stopped after the open() in which case the FD it has will still be valid, as the old file still exists and has only been renamed... It can't get stopped in the middle of the open() call - can it? [Now I am being paranoid! - I'm sure it can't... Yet in FreeBSD...] Of course, this will likely be much harder than doing advisory locking, but might be a way that you might be able to exactly what you want. Presumably for advisory locking, I'm right in thinking I'd have to tinker with the sendmail source, so it also uses advisory locking etc? Well, you may need an exception list of processes if your files aren't on a local disk, but if they aren't on a local disk, this whole excersize is pointless, right? All the files are local... They're re-built from a database, on an all-to-often basis... (Hence the need to HUP sendmail, without killing all it's kids etc.) P.S. Can you tell I'm partial to advisory locks? Yes... :) - They would be a better way of doing it! - But I'd rather not mess with Sendmail :) Also, A big "Thanks" to all that replied... I've posted two questions to -hackers recently, and netted two very good replies... -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: LD_PRELOAD odities / Documentation?
Bjoern Fischer wrote: To wrap libc functions you have to use dlsym() with the special handle RTLD_NEXT to get the next incarnation of your function. E.g. you want to wrap fchmod(), so write your own fchmod() and after you `corrected' the params you may have to call the `real' fchmod(). You will get this with dlsym(RTLD_NEXT, "fchmod"). Thanks! - That fixed it... Linux doesn't have such a handle (and seems to work fine without it)... I hadn't strayed enough through the man page for dlsym to notice the difference... Regards, Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
LD_PRELOAD odities / Documentation?
Hi All, I'm working on some code that runs fine on Linux, but not under FreeBSD... Trying to port the code is proving to be a pain... The code is a 'wrapper' / 'shim' that's meant to be LD_PRELOAD'ed before an executable... I've gotten everything to compile, and the LD_PRELOAD works, but a lot of syscall's from the wrapper library fail either with bizare messages such as "malloc(): recursive call", or just die horibly (segmentation faults, and all sorts). Are there any problems from making syscalls / library calls from within an LD_PRELOAD'ed library? - Is anything like this documented anywhere? Most things seem to work, but calling even simply library routines such as 'strcat', 'sprintf' etc. die in flames... The wrapper I'm porting wraps a number of functions from libc (e.g. 'open', 'opendir' etc.) Any pointers would be greatefuly received, unfortunately this all works under Linux (I'm not bashing anyone on the head with that, I'm far more interested in getting it working under FreeBSD)... Thanks, -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: LD_PRELOAD odities / Documentation?
Daniel O'Connor wrote: On 03-Aug-00 Karl Pielorz wrote: Any pointers would be greatefuly received, unfortunately this all works under Linux (I'm not bashing anyone on the head with that, I'm far more interested in getting it working under FreeBSD)... I think the problem is that your calls are being resolved to your own library first, so that is the routine being called. AFAIK you have to build a set of pointers to the original (ie libc) routines. I know esound work with its esddsp program, so you could look there for some tips. Thanks for the reply! Sorry, I should have posted more details - I'll have a look at the reference you mentioned... re. Calling library Routines: One of the ways I've tried implementing syscalls is to dlopen() the correct library, and fetch the routines address from there (using dlsym) - and calling the routine that way... This doesn't seem to help though :( -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Drivers, templates and beyond 2.2.X
Hi All, It's now getting to the point where I _have_ to port my old, 2.2.X custom driver to run under 3.X/4.X. I'm a reasnably competant programmer, and creating the driver under 2.2.X wasn't too hard, thanks to help from friends, a ~10 year old book - and the files in /usr/share/examples/drivers A lot has changed since 2.2.X (i.e. probes, handlers, the way ISA drivers are attached etc. - and God knows what else). My questions are: 1. Has anyone got any updated 'skeleton drivers' for ISA devices under 3.X/4.X? (i.e. more up to date files than those in /usr/share/examples/drivers?) 2. Failing #1, which driver is the best driver to print out, and pull apart as an example of "How writing a simple port-mapped ISA card driver" should be done?. I've looked at things like the joystick driver, and some of the sound code etc. - there seems to be a lot of difference in the way the drivers are set out etc. (At least, that seems to be the case to me!). This leaves me a little confused, if I'm going to model my driver on one of the existing ones - which is best? Thanks in advance for any info, Regards, Karl Pielorz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations
Darren Reed wrote: It is evil connection. Good applications do read data from their sockets, and evil ones do not. And ever if it is good, but silly or busy application, good clients do not send so much data that application can not process it. Am I wrong, there are any examples? So what if someone manages to crash a program due to a DOS attack ? An easy one that comes to mind is syslogd. It's often stuck in disk-wait and can easily be targetted with a large number of packets. Isn't syslog UDP? - i.e. no ACK? - you could argue (to a point) that this might even be by design? :) (with regard to if syslog is in diskwait, and over burdened with traffic, data gets dropped). This, could be construed as a DoS (in fact it probably is)... If you look to real life, not many systems are DoS proof - Most real life scenarios work by detection and subsequent action, e.g. if you start calling the firemen out all over town (DoS'ing the fire service) - you will hopefully be detected, and removed :) You could try to prevent this, by having say limits on buffers per process, or through something like Inetd (i.e. throttling). You could even take Inetd a stage further and say "if excessive from same IP, stop responding to that IP for 'x' time), but even then people who are determined will only (and easily with the current Internet) start launching multi-homed attack's DoS's etc. How long before servers only accept connections from hosts presenting a valid 'certificate'? - How long until the certificates themselves are forged? At the end of the day, you have 1 box with limited resources - trying to handle the situation. Even if it's well behaved (doesn't crash) - something has to give, i.e. the service may shutdown for a while. The sad fact is, this is exactly what a DoS is trying to achieve, and will achieve until some intervening action is taken, you can only slow detect it - you can't readily stop it - there is no 'easy' fix for this... [You could argue, SysAdmin's are a fix? No?] Just my $0.02+1's worth -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations
Darren Reed wrote: It is evil connection. Good applications do read data from their sockets, and evil ones do not. And ever if it is good, but silly or busy application, good clients do not send so much data that application can not process it. Am I wrong, there are any examples? So what if someone manages to crash a program due to a DOS attack ? An easy one that comes to mind is syslogd. It's often stuck in disk-wait and can easily be targetted with a large number of packets. Isn't syslog UDP? - i.e. no ACK? - you could argue (to a point) that this might even be by design? :) (with regard to if syslog is in diskwait, and over burdened with traffic, data gets dropped). This, could be construed as a DoS (in fact it probably is)... If you look to real life, not many systems are DoS proof - Most real life scenarios work by detection and subsequent action, e.g. if you start calling the firemen out all over town (DoS'ing the fire service) - you will hopefully be detected, and removed :) You could try to prevent this, by having say limits on buffers per process, or through something like Inetd (i.e. throttling). You could even take Inetd a stage further and say if excessive from same IP, stop responding to that IP for 'x' time), but even then people who are determined will only (and easily with the current Internet) start launching multi-homed attack's DoS's etc. How long before servers only accept connections from hosts presenting a valid 'certificate'? - How long until the certificates themselves are forged? At the end of the day, you have 1 box with limited resources - trying to handle the situation. Even if it's well behaved (doesn't crash) - something has to give, i.e. the service may shutdown for a while. The sad fact is, this is exactly what a DoS is trying to achieve, and will achieve until some intervening action is taken, you can only slow detect it - you can't readily stop it - there is no 'easy' fix for this... [You could argue, SysAdmin's are a fix? No?] Just my $0.02+1's worth -Karl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: CFD: bogomips CPU performance metric
Chris Costello wrote: No, since it would just be useless bloat in the source tree. If we must have it, how about a port? - I'm definitely for the this isn't a good idea crowd, When I was using Linux, I thought it was 'cute'... I've grown up a bit since then... -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Well, the manual doesn't guarantee security either The only thing the switch seems to do is give dedicated bandwidth to each port but no one knows if it's a true switch since someone did mention a CableTron switch being nothing but a bundled of hub ports inside grouped together. Also, the management feature isn't suppose to affect data from being seen on all the ports. Can this be moved off -hackers?, onto perhaps FreeBSD-Hubs? g Or even, back to ye'olde -chat? :-) -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vinum is cool. anyone bitten recently?
Craig Johnston wrote: Well, I'm looking into doing striping and mirroring on a new webserver I am bringing up (3.2-stable) and I have to say, vinum looks very cool. It took me like half an hour to get it going from first contact. Nice job Greg -- very straightforward. Now, the official status of vinum is still alpha, right? But then again I know that that was (is?) the official status of softupdates for quite some time and I have been using it with no problems. Hi, We've been running vinum for quite a while on a number of systems... It's not 'bitten' us for a while, but it is _extremly_ intolerant of bad drives/termination/hardware etc. In fact, I would go as far as saying, nothing stresses the system more than building the world with a high -j factor on Vinum drives :-) We have 2 x 4.0-Current boxes running Vinum, and 1 x 3.2-Release box running vinum - all are healthy so far (Though two of the systems did have a couple of problems from the outset, which have recently been cured through 'better' setups (i.e. SCSI bus configuration etc.)... Having said that - it is 'alpha' / new - and you should take appropriate precautions... i.e. Don't bet your life on it, and as _always_ have nice regular backups... :) -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Note also that FreeBSD can easily saturate 100 Mbps Ethernet. It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). So far, transfers from FreeBSD to WinNT are _always_ slower than transfers from WinNT to FreeBSD - which considering the hardware and write-overhead etc. - you would have though the opposite should be true... I guess NT ain't a great operating system after all... no kidding? :) -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Testing after the dust has settled and while it is in use is different since conditions do change. The testers only tests for continuity, not the impedance or any other electrical properties of the cable. The decent testers (such as a professional cable installing friend of mine uses) do a full range of tests, at both 10Mbs and 100Mbs speed, including cross talk, attenuation + a host of other things. The customers gets a certificate _per_ connection, listing all the details... The decent testers use proper TDR techniques to do a full range of testing, more than just "The wires conduct, and their in the right order at both ends" :-) Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). Hmmm, how large of a file do you have to transfer to see the max speed? Typically around 2Gb's... I do a lot of DVR work, so I always have large files kicking around :-) What about from FreeBSD to FreeBSD? =) Don't have two boxes to test from... I've toyed with replacing my current NT install with FreeBSD, I guess I just love Delphi too much :-) [hence need Win32 :)] + The company database runs only under Win32 so far... This is getting off-topic for -hackers - if you want to chat we should either move it somewhere more appropriate - or personal replies only :-) -Kp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum is cool. anyone bitten recently?
Craig Johnston wrote: Well, I'm looking into doing striping and mirroring on a new webserver I am bringing up (3.2-stable) and I have to say, vinum looks very cool. It took me like half an hour to get it going from first contact. Nice job Greg -- very straightforward. Now, the official status of vinum is still alpha, right? But then again I know that that was (is?) the official status of softupdates for quite some time and I have been using it with no problems. Hi, We've been running vinum for quite a while on a number of systems... It's not 'bitten' us for a while, but it is _extremly_ intolerant of bad drives/termination/hardware etc. In fact, I would go as far as saying, nothing stresses the system more than building the world with a high -j factor on Vinum drives :-) We have 2 x 4.0-Current boxes running Vinum, and 1 x 3.2-Release box running vinum - all are healthy so far (Though two of the systems did have a couple of problems from the outset, which have recently been cured through 'better' setups (i.e. SCSI bus configuration etc.)... Having said that - it is 'alpha' / new - and you should take appropriate precautions... i.e. Don't bet your life on it, and as _always_ have nice regular backups... :) -Karl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Note also that FreeBSD can easily saturate 100 Mbps Ethernet. It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). So far, transfers from FreeBSD to WinNT are _always_ slower than transfers from WinNT to FreeBSD - which considering the hardware and write-overhead etc. - you would have though the opposite should be true... I guess NT ain't a great operating system after all... no kidding? :) -Karl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Vincent Poy wrote: Testing after the dust has settled and while it is in use is different since conditions do change. The testers only tests for continuity, not the impedance or any other electrical properties of the cable. The decent testers (such as a professional cable installing friend of mine uses) do a full range of tests, at both 10Mbs and 100Mbs speed, including cross talk, attenuation + a host of other things. The customers gets a certificate _per_ connection, listing all the details... The decent testers use proper TDR techniques to do a full range of testing, more than just The wires conduct, and their in the right order at both ends :-) Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). Hmmm, how large of a file do you have to transfer to see the max speed? Typically around 2Gb's... I do a lot of DVR work, so I always have large files kicking around :-) What about from FreeBSD to FreeBSD? =) Don't have two boxes to test from... I've toyed with replacing my current NT install with FreeBSD, I guess I just love Delphi too much :-) [hence need Win32 :)] + The company database runs only under Win32 so far... This is getting off-topic for -hackers - if you want to chat we should either move it somewhere more appropriate - or personal replies only :-) -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: (forw)
Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? -Kp crypt0genic wrote: Have you all seen this? From: Anonymous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw)
Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? -Kp crypt0genic wrote: Have you all seen this? From: Anonymous nob...@replay.com To: bugt...@securityfocus.com Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: (forw)
Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. I was actually leaning towards that... My boss had kittens here (we have 12 FreeBSD boxes running the show now), until I'd explained it to him... If syscall's need to be replaced, they need to be replaced - and if they are replaceable ... (I'll stop there) :) The article (from what I can remember) didn't actually go out of it's way to say you have to have be root to load the modules in the first place :) - Maybe it's warrants some kind of response page putting up somewhere? - this is also getting off topic for -hackers :(... -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
Greg Lehey wrote: I've come to understanding that lack of documentation is probably one of the factors that keep the system healthy, because it keeps the unskilled people away. I don't know whether it's true but I read in books that reading code is one of the methods to learn programming. Since FreeBSD does ship with source code, docs are not necessary. NT ships with poorly written docs instead, and, that is what kills it all the time, despite of its perfect design that I really like. People write NT drivers without full understanding what is going on, so they destabilize the system. I can't agree with this theory. Lack of documentation just moves the degree of skill needed to, for example, write device drivers. Document less well and your average device driver writer will write a worse driver, with or without source code access. Source code access helps too, of course. Coming from someone who's struggled to write a device driver, and then had to move the driver from 2.X, through to 3.X to 4.X (it's currently languishing somewhere along the line of 3.X) - I would wholely agree with Greg. Documentation is _very important_ even more so in a rapidly moving system... Having access to the source code is one thing, but 'c' was not designed for documentation, it was designed to program in... Looking at the current array of drivers in -current you get the idea everyones done it 'slightly differently', and no one comments their code enough to make it 'self documenting', nor has anyone singled out any of the vast array of drivers and said "this is a good example if your writing ISA drivers", or "this is a good one to go from if your writing PCI". Just my annoyed $0.02's worth! :) -Kp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)))
Greg Lehey wrote: I've come to understanding that lack of documentation is probably one of the factors that keep the system healthy, because it keeps the unskilled people away. I don't know whether it's true but I read in books that reading code is one of the methods to learn programming. Since FreeBSD does ship with source code, docs are not necessary. NT ships with poorly written docs instead, and, that is what kills it all the time, despite of its perfect design that I really like. People write NT drivers without full understanding what is going on, so they destabilize the system. I can't agree with this theory. Lack of documentation just moves the degree of skill needed to, for example, write device drivers. Document less well and your average device driver writer will write a worse driver, with or without source code access. Source code access helps too, of course. Coming from someone who's struggled to write a device driver, and then had to move the driver from 2.X, through to 3.X to 4.X (it's currently languishing somewhere along the line of 3.X) - I would wholely agree with Greg. Documentation is _very important_ even more so in a rapidly moving system... Having access to the source code is one thing, but 'c' was not designed for documentation, it was designed to program in... Looking at the current array of drivers in -current you get the idea everyones done it 'slightly differently', and no one comments their code enough to make it 'self documenting', nor has anyone singled out any of the vast array of drivers and said this is a good example if your writing ISA drivers, or this is a good one to go from if your writing PCI. Just my annoyed $0.02's worth! :) -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: do softupdates work on SMP -stable and -current now?
Roger Hardiman wrote: Hi, I remember reading in the mailing lists how softupdates were unreliable on SMP 3.x and -current machines about 6-8 months ago. Is this all fixed now for SMP machines? I've been using softupdates on a uni-processor 3.2-stable machine and it works well. I wanted to try it on my two SMP machines (one has 3.2-stable, one has -current) We have a couple of large(ish) systems (both dual P2/Pro's) running Vinum and softupdates, and I've not seen any problems... One was up until recently 3.1, there both 4.0-current now... -Karl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ZFS w/failing drives - any equivalent of Solaris FMA?
-> Re: ZFS w/failing drives - any equivalent of Solaris FMA? freebsd-hackers -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: ZFS w/failing drives - any equivalent of Solaris FMA? Karl Pielorz Re: ZFS w/failing drives - any equivalent of Solaris FMA? Nathanael Hoyle Re: ZFS w/failing drives - any equivalent of Solaris FMA? Zaphod Beeblebrox Re: ZFS w/failing drives - any equivalent of Solaris FMA? Oliver Fromme Re: ZFS w/failing drives - any equivalent of Solaris FMA? Zaphod Beeblebrox Re: ZFS w/failing drives - any equivalent of Solaris FMA? Jeremy Chadwick Re: ZFS w/failing drives - any equivalent of Solaris FMA? Zaphod Beeblebrox Re: ZFS w/failing drives - any equivalent of Solaris FMA? Freddie Cash Re: ZFS w/failing drives - any equivalent of Solaris FMA? Jeremy Chadwick Re: ZFS w/failing drives - any equivalent of Solaris FMA? Wilkinson, Alex Re: ZFS w/failing drives - any equivalent of Solaris FMA? Jeremy Chadwick Re: ZFS w/failing drives - any equivalent of Solaris FMA? Wilkinson, Alex Re: ZFS w/failing drives - any equivalent of Solaris FMA? Jeremy Chadwick Re: ZFS w/failing drives - any equivalent of Solaris FMA? Fabian Keil Re: ZFS w/failing drives - any equivalent of Solaris FMA? Jeremy Chadwick Re: ZFS w/failing drives - any equivalent of Solaris FMA? Freddie Cash Reply via email to
