Re: MFC of em/igb drivers
Jack Vogel wrote: I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! Jack Jack, I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... [EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=198VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX full-duplex (autoselect) status: no carrier ... Any idea how to solve this issue? thanks, Ganbold ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- Q: How many pre-med's does it take to change a lightbulb? A: Five: One to change the bulb and four to pull the ladder out from under him. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of em/igb drivers
On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: Jack Vogel wrote: I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... [EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=198VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX full-duplex (autoselect) status: no carrier ... Any idea how to solve this issue? Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0=... media 1000baseTX mediaopt full-duplex Cisco switches have a notorious history of not being friendly with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
Re: MFC of em/igb drivers
Jeremy Chadwick wrote: On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: Jack Vogel wrote: I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... [EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=198VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX full-duplex (autoselect) status: no carrier ... Any idea how to solve this issue? Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0=... media 1000baseTX mediaopt full-duplex I tried it and it doesn't work. Cisco switches have a notorious history of not being friendly with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. Tried too, doesn't work. Ganbold -- Life is too important to take seriously. -- Corky Siegel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Hi, On Thu, 05 Jun 2008 13:31:44 -0500 Paul Schmehl [EMAIL PROTECTED] wrote: --On Thursday, June 05, 2008 17:53:01 +0100 Tom Evans [EMAIL PROTECTED] wrote: I think that, especially with open source products, there is a large emphasis on testing in your own environments, and choosing the 'correct' version of a particular software package is important. For example, at $JOB, we had a lot of servers running 6.1 as it was an extended lifetime release, so no point jumping to 6.2, instead we waited for 6.3 to pass our integration testing. Not everyone has those kinds of resources. The domain I'm referring to is a hobby site, run by a husband and wife. They started with shared hosting and moved to a dedicated box when I volunteered to help with the backend work. For several years we ran one server hosting dns, imaps, smtps, mail lists and websites. Yes, it's not ideal, but when you have zero income you do what you can. Testing like you describe is out of the question. We now have the embarrassment of riches of two servers; one for web and the old one for the rest. The old box is still running 5.4 SECURITY. The new box is running 6.1. I'd *like* to upgrade both boxes, and the older box can go offline comfortably for several hours without anyone but me noticing. But if the web box goes down for 30 seconds, queries from the users start pouring in. What you are saying sounds like a contradiction to me. On one side it is just a hobby site and generates no income and on the other hand it is a critical server with millions of hits and the box can't even go down for a short time. What happens in case lets say your harddisk crashes? Something which is not an exactly rare case... If the users are not paying for the service they should be able to accept a downtime, may it be scheduled or even completely unexpected. Or pay / donate for a more reliable service (Redundant server as hot standby / testbed etc.). Manfred -- Manfred Usselmann [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant reboot with FreeBSD 6.3 and 2GB RAM
Hello, i can confirm that the bug fix submitted with PR 108215 solves the reboot problem when using mfsroot images in FreeBSD 6.3. I will test it also on FreeBSD 7.0, but i assume that it will fix it there too. Many users using FreeNAS reporting this reboot problem on their machines with RAM 2GB. Regards Volker Original-Nachricht Datum: Wed, 21 May 2008 21:08:25 +0200 Von: Volker [EMAIL PROTECTED] An: [EMAIL PROTECTED] CC: freebsd-stable@freebsd.org, [EMAIL PROTECTED] Betreff: Re: Instant reboot with FreeBSD 6.3 and 2GB RAM On 12/23/-58 20:59, [EMAIL PROTECTED] wrote: Hello, some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to = 2GB. We are using the following kernel configuration which is based on GENERIC: http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291view=markup I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. Is there any limitation? Could someone help me out of this problem? Regards Volker Hi Volker ;) I'm not quite sure about your 2nd problem and your report is not quite detailed but from your description it looks like loader is causing that. As there's no filesystem available at that time, the loader has to read itself through the filesystem structures. Knowing that, PR misc/108215 comes to mind. I've not been able to check if the issue and the patch to it is right but you may give it a try. Probably somebody with loader and filesystem (ufs) knowledge may answer that question quickly if the patch contained in the PR is right. The report is about 6.2-R but at least I've checked loader code and 7.x code is the same. I came across that report yesterday and was unable to check the calculation. If that is really the case, your problem may be related to that. http://www.freebsd.org/cgi/query-pr.cgi?pr=108215 Assuming the problem report is right, it's about reading huge files by loader reads in wrong sectors. HTH Volker -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of em/igb drivers
On Fri, Jun 06, 2008 at 05:29:46PM +0800, Ganbold wrote: Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0=... media 1000baseTX mediaopt full-duplex I tried it and it doesn't work. Cisco switches have a notorious history of not being friendly with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. Tried too, doesn't work. Good to know. Sounds like a driver problem; back to Jack for that one. :-) -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Paul Schmehl [EMAIL PROTECTED] writes: [...] I reacted in anger because I felt the OP was being savagely attacked rather than being responded to with professionalism. Later in the thread some folks got around to asking which PRs he was referring to, but that was after attacking him for having the temerity to suggest that perhaps 6.2 shouldn't be EOL. [...] I don't recall him ever refusing. I think after his initial post he's been forced to defend himself from attack from 360 degrees. [...] I came in late, and thus had the benefit of reading most of thread in context rather than piece by piece over time, and in my opinion, the above is a gross misrepresentation. I think you need to go back and re-read the thread from the beginning. Here, let me help you. Three people replied to Jo Rhett's initial email. Here's what they said, with Jo's own text elided: Doug Barton: It isn't that we want people to upgrade, it's that we are trying to be realistic regarding what we have the resources to support. [...] I admit to not having been following 6.x too closely, but are these things that have been reported, or problems you're having personally? [...] Having an upgrade path is something every operation needs. Set it and forget it isn't a viable strategy in the current culture where 0-day vulnerabilities are becoming increasingly common. Scott Long: Can you describe the bugs that are affecting you? [...] The expectation is always that newer versions of a stable branch will have few regressions, and thus upgrading is a low risk. John Baldwin: FWIW, at Y! 6.3 is more stable than 6.2 (I had a list of about 10 patches for known deadlocks and kernel panics that were errata candidates for 6.2 that never made it into RELENG_6_2 but all of them are in 6.3). We also have many machines with bge(4) and from our perspective 6.3 has less issues with bge0 devices than 6.2. Given the real world experience I have, your claims of instability w/o even testing 6.3 border on silly. Also, when it comes to bge(4), you need to be _very_ specific about what chipsets you are using and comparing those with the chipsets in the bug reports you read. The bge(4) driver in particular covers a vast range of different hardware variations and is a bit of a hodge-podge itself. If there is a problem with a 5705 card then it may be specific to just 5705 parts and not affect 575x, etc. parts. Again, with 3ware, there are two different drivers (twe(4) vs twa(4)) and again, you need to be more specific with which driver you are using and which model controllers you have. It takes a very active imagination to describe this as an attack from 360 degrees. The fun starts with the following exchange between Jo and Kris Kennaway (who responded to Doug): Kris Kennaway: Also, it's not like anyone should have been caught by surprise by the 6.2 EoL; the expiry date has been advertised since the 6.2 release itself. Jo Rhett: It has changed multiple times. I keep reviewing and finding 6.3 bugs outstanding, and then observe the EoL get pushed. I'm surprised that it failed to get pushed this time. This is competely untrue - but Kris doesn't swallow the bait, and relies patiently and politely: I'm sorry that the FreeBSD project failed to conform to your expectations. However, I invite you to actually try 6.3 for yourself instead of assuming that it will fail. This is the crux of the matter - Jo is complaining about software he hasn't even tried. There is absolutely no way anybody can help him until he actually tries 6.3 and reports any actual bugs and regressions he finds. This subthread quickly degrades after Chris Marlatt inists that we should support LTS releases for four years instead of two, and takes personal offense at the fact that we don't have the resources to do so. Let's jump back to Scott Long's subthread: Scott Long: Can you describe the bugs that are affecting you? Jo Rhett: gmirror failures, 3ware raid driver timeouts, bge0 problems. All three in production use on dozens of systems. That is also untrue. None of these are bugs that are affecting [Jo], since he hasn't tried running 6.3 at all. Scott Long: Give me specific details on the 3ware and bge problems. Jo Rhett: Familiar with searching the open bug reports? That's where I found them. Sorry, I'm knee-deep in a major project that I've been working 16+ hours a day on right now, and I just don't have the time for spurious queries. Query the open bug reports for 6.3 and then explain to me again why 6.2 is no longer supported. Scott asks him to describe the problems he's having, and he calls that spurious queries which he doesn't have time for. Is that Scott attacking and disrespecting Jo, or Jo attacking and disrespecting Scott? No wonder Scott gets annoyed: Really, if it's such a big issue that you have time to bitch an moan on the mailing lists, I don't understand why you don't
Re: gmirror patches
Patch is gzipped and can be easily gunziped after download. (and uuencoded in webpage view) Ah, yes, sorry about that - thought it would be obvious. I always submit changes that way as I find that whitespace has a habit of breaking otherwise. It is true that patch is better in plaintext diff. How would I set about doing that without the whitespace being messed up by email transit ? I have always found in the past that tabs end up as spaces and then patch gets upset hwne you try to apply it. -pete. PS: thanks for the emai address BTW! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror patches
Pete French wrote: [...] It is true that patch is better in plaintext diff. How would I set about doing that without the whitespace being messed up by email transit ? I have always found in the past that tabs end up as spaces and then patch gets upset hwne you try to apply it. I sent PR throught webform with plain text patch with txt extension (http://www.freebsd.org/cgi/query-pr.cgi?pr=124248), patch is shown on webpage with spaces instead of tabs, but if you download it, tabs are tabs. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 8:22 PM, Jo Rhett wrote: If you're asking why I don't turn a production environment over to being a freebsd-unstable-testbed, I can't really answer that question in a way you'd understand (if you were asking that question) If you don't have an identical setup to test new software, then you're pretty much not able to ever upgrade anything, IMO, and your production environment *is* a testbed for new software. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 9:03 PM, Adrian Chadd wrote: If this is so important to you - contribute to the project and/or hire a FreeBSD developer. I've got a strange problem with jails and I've been trying to hire a freebsd developer, but I can't seem to get anyone to a) call me back. I got one response on try doing xxx which involved kernel hacking and such, which is beyond what I am in a position to do. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Fri, Jun 06, 2008 at 12:08:54PM -0400, Vivek Khera wrote: On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: Speaking just for myself, I'd love to get a general response from people who have run servers on both as to whether 6.3 is on average more stable than 6.2. I really haven't gotten any clear impression as I'll throw in my +1 for running 6.3. I have it on many boxes, some of which run gmirror and some of which have bge devices (some with both). Never any problems. They operate things varying from Postgres servers to DNS servers to mail servers (postfix) under pretty consistent load pushing lots and lots of data both network and to disk. Thanks. That sounds like the kind of broad experience I need, particularly as the main group of servers are mail servers (spam filtering machines running Postfix, with some config files on NFS.) -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Fri, 2008-06-06 at 12:08 -0400, Vivek Khera wrote: On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: Speaking just for myself, I'd love to get a general response from people who have run servers on both as to whether 6.3 is on average more stable than 6.2. I really haven't gotten any clear impression as I'll throw in my +1 for running 6.3. I have it on many boxes, some of which run gmirror and some of which have bge devices (some with both). Never any problems. They operate things varying from Postgres servers to DNS servers to mail servers (postfix) under pretty consistent load pushing lots and lots of data both network and to disk. AOL! 6.3 with gmirror is rock solid here for web, mail, dns and db. No bge here, but still, I haven't seen 6.3 glitch once. /Mike -- Michael Gratton [EMAIL PROTECTED] Quuxo Software http://web.quuxo.com/ signature.asc Description: This is a digitally signed message part
Re: MFC of em/igb drivers
Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0=... media 1000baseTX mediaopt full-duplex Disagree with this piece of advice. Cisco switches have a notorious history of not being friendly with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. I might have said the same myself five years ago. But this is 2008, and we have autoneg as default on all ports (even at 100 Mbps). Our Cisco switch ports (and we have a *lot* of them) work just fine with autoneg. Note that GigE is different from FE here - autoneg is a compulsory part of the GigE standard, while it's not compulsory for FE. The only GigE ports that have needed anything else were some pre-standard GigE ports. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[nvidia | shared irq] umass disconnects [was: panic dd-ing from a USB disk ]
Mikhail Teterin [EMAIL PROTECTED] writes: Hello! I had some troubles mounting the filesystem from: da0 at umass-sim0 bus 0 target 0 lun 0 da0: MATSHITA DMC-FX12 0100 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 3886MB (7959552 512 byte sectors: 255H 63S/T 495C) and decided to just dd the entire da0 to a file, so that the camera can be disconnected: dd if=/dev/da0 of=/home/mi/da0.dd bs=16384 The dd-ing was proceeding slowly (600Kb/s) and I stopped watching it... The machine paniced about an hour later (at 0:52). The timestamp on /home/mi/da0.dd was 23:45, it was only about 500Mb in size. The stack is below. Would anybody like to look at the complete vmcore dump? The hardware is a quad Opteron with 8Gb RAM. Only 4Gb of these are used, because it runs 7.x/i386 from April 5th (without PAE) -- for the sake of NVidia's card. I can easily produce a similar panic on a dual Opteron 185 with 3G of RAM and running 7-stable-amd64 on a (cheap) nvidia-based MB. It runs gmirror on atapci1 and I attach a geli-encrypted disk via usb. Both share irq 23. Under heavy load (periodic security is enough ) it panics after having disconnected umass0 ( kgdb trace below ) : Unread portion of the kernel message buffer: umass0: at uhub1 port 1 (addr 2) disconnected (da1:umass-sim0:0:0:0): lost device (pass1:umass-sim0:0:0:0): lost device (pass1:umass-sim0:0:0:0): removing device entry I'd be happy to provide more info. Best, Arno Please, advise. Thanks! -mi [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. There is no member named pathname. Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /opt/modules/fuse.ko...done. Loaded symbols for /opt/modules/fuse.ko Unread portion of the kernel message buffer: umass0: at uhub0 port 6 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x0 fault code= supervisor write, page not present instruction pointer = 0x20:0xc0449702 stack pointer = 0x28:0xeb74b8bc frame pointer = 0x28:0xeb74b8dc code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13989 (dd) trap number = 12 panic: page fault cpuid = 3 Uptime: 12d10h52m16s (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x34, scsi status == 0xc8 Physical memory: 3054 MB Dumping 334 MB: (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:195 195 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) #0 doadump () at pcpu.h:195 #1 0xc0599f7b in boot (howto=260) at /ibm/src/sys/kern/kern_shutdown.c:418 #2 0xc059a449 in panic (fmt=0x104 Address 0x104 out of bounds) at /ibm/src/sys/kern/kern_shutdown.c:572 #3 0xc077f60d in trap_fatal (frame=0xeb74b87c, eva=40) at /ibm/src/sys/i386/i386/trap.c:899 #4 0xc077f9aa in trap_pfault (frame=0xeb74b87c, usermode=0, eva=0) at /ibm/src/sys/i386/i386/trap.c:812 #5 0xc078035c in trap (frame=0xeb74b87c) at /ibm/src/sys/i386/i386/trap.c:490 #6 0xc076637b in calltrap () at /ibm/src/sys/i386/i386/exception.s:139 #7 0xc0449702 in xpt_done (done_ccb=0xc690a000) at /ibm/src/sys/cam/cam_xpt.c:4856 #8 0xc044b15c in xpt_action (start_ccb=0xc690a000) at /ibm/src/sys/cam/cam_xpt.c:3057 #9 0xc04462b6 in cam_periph_runccb (ccb=0xc690a000, error_routine=0, camflags=CAM_FLAG_NONE, sense_flags=1, ds=0xc6aea690) at /ibm/src/sys/cam/cam_periph.c:878 #10 0xc0453aa1 in daclose (dp=0xcc862600) at /ibm/src/sys/cam/scsi/scsi_da.c:714 #11 0xc0549b2e in g_disk_access (pp=0xc7e12680, r=0, w=0, e=Variable e is not available.) at /ibm/src/sys/geom/geom_disk.c:152 #12 0xc054ec4d in g_access (cp=0xc8a90380, dcr=-1, dcw=0, dce=0) at /ibm/src/sys/geom/geom_subr.c:748 #13 0xc05490f3 in g_dev_close (dev=0xca1dad00, flags=Variable flags is not available.) at /ibm/src/sys/geom/geom_dev.c:217 #14 0xc0531f69 in devfs_close (ap=0xeb74ba94) at /ibm/src/sys/fs/devfs/devfs_vnops.c:372 #15 0xc0623e86 in
Java binaries for FreeBSD 7
Greetings, From http://www.freebsdfoundation.org/ We are working on providing Java 1.6 support for FreeBSD 6.3 and 7.0. The binaries for 7.0 will be available by June 1. Any news? :) Where I can read more? P.S. I understand that this is not the mailing list to ask, but I can't find better. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3)
On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: Speaking just for myself, I'd love to get a general response from people who have run servers on both as to whether 6.3 is on average more stable than 6.2. I really haven't gotten any clear impression as 6.3 has been stable for me. I've been running since April on DL380 G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel 815E boards. My bge(4) NICs are detected as Broadcom BCM5703 A2 and BCM5704 A2, with no issues. Running gmirror with no issues. Someone mentioned freebsd-update earlier in the thread. I'd like to take a moment to plug it, since making it easy to move to 6.3 seems topical. I got a little long-winded, so here's an executive summary: freebsd-update is good; business case for more hardware; updating in 'hybrid' mode with custom kernels and stock userland; using kernel config 'includes' to save additional effort. I prefer freebsd-update over the buildworld and then installworld-over-NFS routine, centralized rsyncs, or anything else. I used freebsd-update to uplift the systems above, and also just bumped sixteen more from 6.2. Worked like a charm. Its 'rollback' option is also very handy, for obvious reasons. Based on how much time I save with freebsd-update, I can make a business case for buying another box for a farm, rather than rolling my own kernels and eking out xx% of additional performance. Once ULE gets into 7.x-RELEASE, I probably won't even have to do that. For systems that require a custom kernel, we still patch everything else with freebsd-update. When freebsd-update detects the non-stock kernel, it warns you to install a kernel from the target release. If that scares you, you can swap in a stock kernel from the current release (saved off, or from the release media or FTP) and then upgrade. When finished, save off the new stock kernel for future upgrades, and then rebuild your custom kernel. (Anybody else doing anything like this, or something better?) I also recommend starting your kernel config with 'include SMP' (or GENERIC or PAE or whatever). If you use nocpu, nooptions, nomakeoptions, nodevice etc. to turn off what you don't need, your config is reduced to a 'diff' of sorts against the stock config. Our kernel configs are now ~17 lines, can be grokked at a glance, and should change little from release to release. Here's a stub of an example that uses most of the knobs: include SMP# Inherit SMP (which inherits GENERIC). nocpu I486_CPU # Disable old CPU support; see tuning(7). nocpu I586_CPU ident SMP-GENERIC_CUSTOM_FOO # Inherit ident, custom name. nomakeoptionDEBUG # Do not build with gdb(1) debug symbols. nooptions SCHED_4BSD # Do not use the 4BSD scheduler; options SCHED_ULE # use ULE schedule instead. # ALTQ support options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build # Devices for pf device pf # PF device pflog # pflog device pfsync # pfsync Use 'nodevice' to turn off devices worth leaving out, but only as many as are worth the effort. If you haven't already considered freebsd-update, either for the whole system or just userland, I highly recommend it. These days, the gain has to be pretty significant for me to want to go back to making world. For our PXE installs using custom install.cfg, we can go from bare metal to a fully patched vanilla system in four minutes on modern hardware! The novelty of that still hasn't worn off. :-) It's more efficient (and probably safer?) to use freebsd-update against a binary install rather than against local compilation. And if you're bumping major versions (6.x - 7.x), you still have to rebuild your ports. But try it in your lab or for your next deployment. You can easily convert a freebsd-updated system to a makeworld system, if necessary. And thanks again, Colin! Royce -- Royce D. Williams - http://royce.ws/ Inspiration exists, but it has to find us working. - Pablo Picasso ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3)
On Fri, Jun 06, 2008 at 11:34:01AM -0800, Royce Williams wrote: On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: Speaking just for myself, I'd love to get a general response from people who have run servers on both as to whether 6.3 is on average more stable than 6.2. I really haven't gotten any clear impression as 6.3 has been stable for me. I've been running since April on DL380 G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel 815E boards. My bge(4) NICs are detected as Broadcom BCM5703 A2 and BCM5704 A2, with no issues. Running gmirror with no issues. Someone mentioned freebsd-update earlier in the thread. I'd like to take a moment to plug it, since making it easy to move to 6.3 seems topical. I got a little long-winded, so here's an executive summary: freebsd-update is good; business case for more hardware; updating in 'hybrid' mode with custom kernels and stock userland; using kernel config 'includes' to save additional effort. I prefer freebsd-update over the buildworld and then installworld-over-NFS routine, centralized rsyncs, or anything else. I used freebsd-update to uplift the systems above, and also just bumped sixteen more from 6.2. Worked like a charm. Its 'rollback' option is also very handy, for obvious reasons. Based on how much time I save with freebsd-update, I can make a business case for buying another box for a farm, rather than rolling my own kernels and eking out xx% of additional performance. Once ULE gets into 7.x-RELEASE, I probably won't even have to do that. For systems that require a custom kernel, we still patch everything else with freebsd-update. When freebsd-update detects the non-stock kernel, it warns you to install a kernel from the target release. If that scares you, you can swap in a stock kernel from the current release (saved off, or from the release media or FTP) and then upgrade. When finished, save off the new stock kernel for future upgrades, and then rebuild your custom kernel. (Anybody else doing anything like this, or something better?) Alternativly, you can edit freebsd-update.conf and tell it to not update your kernel on those machines. You can also exclude particular files. We use this to keep from updating libc directly on some machines where we're using modified RPC timings to improve NIS performance in the face of occataionl packet loss. -- Brooks GENERIC or PAE or whatever). If you use nocpu, nooptions, nomakeoptions, nodevice etc. to turn off what you don't need, your config is reduced to a 'diff' of sorts against the stock config. Our kernel configs are now ~17 lines, can be grokked at a glance, and should change little from release to release. Here's a stub of an example that uses most of the knobs: include SMP# Inherit SMP (which inherits GENERIC). nocpu I486_CPU # Disable old CPU support; see tuning(7). nocpu I586_CPU ident SMP-GENERIC_CUSTOM_FOO # Inherit ident, custom name. nomakeoptionDEBUG # Do not build with gdb(1) debug symbols. nooptions SCHED_4BSD # Do not use the 4BSD scheduler; options SCHED_ULE # use ULE schedule instead. # ALTQ support options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build # Devices for pf device pf # PF device pflog # pflog device pfsync # pfsync Use 'nodevice' to turn off devices worth leaving out, but only as many as are worth the effort. If you haven't already considered freebsd-update, either for the whole system or just userland, I highly recommend it. These days, the gain has to be pretty significant for me to want to go back to making world. For our PXE installs using custom install.cfg, we can go from bare metal to a fully patched vanilla system in four minutes on modern hardware! The novelty of that still hasn't worn off. :-) It's more efficient (and probably safer?) to use freebsd-update against a binary install rather than against local compilation. And if you're bumping major versions (6.x - 7.x), you still have to rebuild your ports. But try it in your lab or for your next deployment. You can easily convert a freebsd-updated system to a makeworld system, if necessary. And thanks again, Colin! Royce -- Royce D. Williams - http://royce.ws/ Inspiration exists, but it has to find us working. - Pablo Picasso ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL
6.2-STABLE = 7.0-STABLE Upgrade root partition more full
I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 7766238935817%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 588466432 0%/tmp /dev/da0s1f 268217320 4866120 241893816 2%/usr /dev/da0s1d 4298926 162066 3792946 4%/var Now it shows: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 18483428218640%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 426466594 0%/tmp /dev/da0s1f 268217320 5514844 241245092 2%/usr /dev/da0s1d 4298926 187570 3767442 5%/var Notice the the increase in the root partition. Should I have made this partition bigger when I first installed? Is there any cleaning up I can do after version upgrades? I would've thought /usr would be the one that grew more, but then again my /usr partition is fairly sizeable. Does 7.0 just take up a lot more of the root partition than 6.2? - Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Java binaries for FreeBSD 7
On Friday 06 June 2008 19:39:59 Stefan Lambrev wrote: Greetings, From http://www.freebsdfoundation.org/ We are working on providing Java 1.6 support for FreeBSD 6.3 and 7.0. The binaries for 7.0 will be available by June 1. Any news? :) Where I can read more? P.S. I understand that this is not the mailing list to ask, but I can't find better. Perhaps here http://www.freebsd.org/java/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-STABLE = 7.0-STABLE Upgrade root partition more full
On Fri, Jun 06, 2008 at 11:37:51AM -0700, Gavin Spomer wrote: I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 7766238935817%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 588466432 0%/tmp /dev/da0s1f 268217320 4866120 241893816 2%/usr /dev/da0s1d 4298926 162066 3792946 4%/var Now it shows: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 18483428218640%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 426466594 0%/tmp /dev/da0s1f 268217320 5514844 241245092 2%/usr /dev/da0s1d 4298926 187570 3767442 5%/var Notice the the increase in the root partition. Should I have made this partition bigger when I first installed? Is there any cleaning up I can do after version upgrades? I would've thought /usr would be the one that grew more, but then again my /usr partition is fairly sizeable. Does 7.0 just take up a lot more of the root partition than 6.2? Yes, it just does. It should not keep expanding, though. IMHO, you should still be fine as long as you've got /tmp, /usr/, /var, and the home directories residing on other partitions. If you're using /home under / for home directories, you might want to move it to /usr/home and symlink /home to it. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-STABLE = 7.0-STABLE Upgrade root partition more full
Gavin Spomer wrote: I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 7766238935817%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 588466432 0%/tmp /dev/da0s1f 268217320 4866120 241893816 2%/usr /dev/da0s1d 4298926 162066 3792946 4%/var Now it shows: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 18483428218640%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 426466594 0%/tmp /dev/da0s1f 268217320 5514844 241245092 2%/usr /dev/da0s1d 4298926 187570 3767442 5%/var Notice the the increase in the root partition. Should I have made this partition bigger when I first installed? Is there any cleaning up I can do after version upgrades? I would've thought /usr would be the one that grew more, but then again my /usr partition is fairly sizeable. Does 7.0 just take up a lot more of the root partition than 6.2? 7.0 installs debugging symbols for the kernel and modules by default. You can avoid that by defining INSTALL_NODEBUG during installkernel. If already installed, you can delete the symbol files without causing problems as long as you don't need to debug the kernel. Also, when you install a new kernel, the old kernel is saved as kernel.old so you now have 2 kernels in /boot instead of one. If you're positive the new kernel works fine, the old kernel can be removed as that's only used to recover from a new kernel with problems. But, your space really isn't that close to the limit, IMO. You appear to have enough space to have an old and new kernel installed both with symbols, so I'd leave it as is in case you need to debug something or boot the old kernel. You can always take care of it later if you're about to run out of space. Why do today what you can put off 'til tomorrow? Also, consider reading UPDATING before every upgrade. The entry for 20060118 covers this issue. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
TMPFS: File System is Full
Hi, I found when we exhaust memory, tmpfs will not be able to write anything into it and cannot mount it. I use ZFS and TMPFS at the same time. Florence# cd /usr/src make buildworld /dev/null Florence# uname -a FreeBSD Florence.tamama.org 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #5: Mon May 5 00:36:32 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL amd64 Florence# mount -t tmpfs -o rw,size=1024000 tmpfs /tmp/tmpfs mount: tmpfs : No space left on device first 5 lines of top: last pid: 26893; load averages: 1.50, 1.58, 1.48 up 12+01:43:49 05:40:51 146 processes: 2 running, 144 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 406M Active, 574M Inact, 1775M Wired, 83M Cache, 214M Buf, 126M Free Swap: 1024M Total, 1024M Free I think there should be a lower bound size limit. Does TMPFS use kernel-space memory? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update 6.2-R - 6.3-B1 rollback failed
Colin Percival wrote: Jan Henrik Sylvester wrote: In short, as long as you don't build a custom kernel but call it GENERIC or SMP, FreeBSD Update should automatically DTRT. That is exactly my question. On 6.2-RELEASE, I sometimes used a modified ld-elf.so.1 or a single patched module without recompiling the kernel. What does using freebsd-update (accidentally or deliberately) do in that case? By accident, I discovered that it does not always fail. Does it skip the modified files, overwrite them with new versions, or overwrite them with an unpredictable bdiff merge that is likely garbage? Depending on the UpdateIfUnmodified option in freebsd-update.conf, it will either update files to clean new versions or print a warning message and not touch them. There's also an IgnorePaths directive which you can use to tell FreeBSD Update not to touch some files (even if they haven't been modified locally). FreeBSD Update will never produce mangled files as a result of applying a bsdiff patch to the wrong file -- it checks file hashes before and after applying patches and gracefully falls back to downloading complete files if it can't generate a file via patching. Is it possible to configure freebsd-update to not remove old kernel directory and just rename it to kernel.old or something else? Two times I end up with unbootable machine (upgraded from 6.3 to 7.0 - 7.x version kernel always hangs on this machine, even with CD boot) and then I must use bootable CD / flashdisk with old 6.x kernel to be able to run freebsd-update rollback. It will be useful if one can choose to leave old kernel in boot directory to be able to boot it if something goes wrong. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Java Status
Dear Stefan, I'm responding to your inquiry about the Java binaries. I just updated our website with the current status. We have completed the certification testing of Java 1.6 on FreeBSD 7. We are now waiting for approval from Sun. We anticipate it to take another two weeks. Please let me know if you have any other questions. Sincerely, Deb Goodkin Director of Operations The FreeBSD Foundation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: challenge: end of life for 6.2 is premature with buggy 6.3
--On June 6, 2008 11:53:49 AM +0200 Manfred Usselmann [EMAIL PROTECTED] wrote: What you are saying sounds like a contradiction to me. On one side it is just a hobby site and generates no income and on the other hand it is a critical server with millions of hits and the box can't even go down for a short time. What happens in case lets say your harddisk crashes? Something which is not an exactly rare case... Actually, that happened to us a couple of years ago, on the old server while it still the only server, and I was on vacation 1600 miles away. We ended up having to pay the hosting company to fix the hardware problem and reinstall FreeBSD (which they unfortunately did a lousy job of), and then I rebuilt the server and restored it to service over a dialup account while on vacation. Many of our users are retired old guys who can barely figure out how to use a computer. When the site goes down, some of them claim to go into withdrawal. The total downtime for that incident was about two days, and they suffered greatly. If the users are not paying for the service they should be able to accept a downtime, may it be scheduled or even completely unexpected. Or pay / donate for a more reliable service (Redundant server as hot standby / testbed etc.). Actually, it was the owners who had to be convinced to accept donations from the users, who were all too willing to help. The new server was purchased with those donations. Maybe some day we *will* be able to afford redundancy. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
Re: challenge: end of life for 6.2 is premature with buggy 6.3
--On June 6, 2008 3:08:25 PM +0200 Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Paul Schmehl [EMAIL PROTECTED] writes: [...] I reacted in anger because I felt the OP was being savagely attacked rather than being responded to with professionalism. Later in the thread some folks got around to asking which PRs he was referring to, but that was after attacking him for having the temerity to suggest that perhaps 6.2 shouldn't be EOL. [...] I don't recall him ever refusing. I think after his initial post he's been forced to defend himself from attack from 360 degrees. [...] I came in late, and thus had the benefit of reading most of thread in context rather than piece by piece over time, and in my opinion, the above is a gross misrepresentation. I think you need to go back and re-read the thread from the beginning. Here, let me help you. Thanks for the help. My point still stands. I think the behavior of the developers on the lists should be of as high a quality as the work they do on the OS (which, as I have stated, is first rate.) Descending to the levels that some have (some of which you quote here) reflects poorly on the OS and its developers. The fact that FreeBSD is open source does not negate the fact that its users are its customers and should be treated with respect, professionalism and yes, patience. And again, I am trying neither to excuse nor to defend Jo's behavior. That's his gauntlet. I am saying that the fact that developers possess a unique and valuable skill that is much appreciated by those of us who use the product of their labor does not excuse or justify some of the boorish behavior that was exhibited in this thread - regardless of how insulting one may have felt Jo's responses were. Since a lot of people seem to want to pontificate without doing much of anything helpful, allow me to bring this discussion back to Jo's point: http://www.freebsd.org/cgi/query-pr-summary.cgi?category=severity=priority=class=state=sort=nonetext=bgeresponsible=multitext=originator=release=%5EFreeBSD+6 That url lists 6 serious problems for bge and 3 non-critical problems, some dating to more than two years ago. Two were patched, one is suspended and 6 are still open; four of those critical. http://www.freebsd.org/cgi/query-pr-summary.cgi?category=severity=priority=class=state=sort=nonetext=gmirrorresponsible=multitext=originator=release=%5EFreeBSD+6 That url lists 1 serious problem and 3 non-critical problems with gmirror, all of which remain open. http://www.freebsd.org/cgi/query-pr-summary.cgi?category=severity=priority=class=state=sort=nonetext=tweresponsible=multitext=originator=release=%5EFreeBSD+6 That url refers to locking problems that cause kernel panics using the twe driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107608 That url refers to a hang that renders a system unusable when using the twa driver. Jo's concerns about updating to 6.3 rather than sticking with a system that's working for him don't seem unreasonable to me. Do they to you? Furthermore, it seems the reaction of developers, that he wasn't being specific enough are rendered moot by the urls above, which were easily accessed by me, someone with little knowledge at all of two of the three issues. So, rather than berating Jo for not producing PRs, wouldn't it have been more professional to list the relevant PRs (just as I have done, which took me less time than the multiple angry responses to Jo took the involved developers) and ask him which of them gave him the greatest concerns? What's the point of the constant demands to either produce specific relevant information of STFU? Are the developers trying to impress the list with their professionalism? Their patience? Their knowledge? If you're offended that I hold the developers to a higher standard than I do the users, then I plead guilty as charged and believe I am correct to do so. As to your specific points: I'm sorry that the FreeBSD project failed to conform to your expectations. However, I invite you to actually try 6.3 for yourself instead of assuming that it will fail. This is the crux of the matter - Jo is complaining about software he hasn't even tried. There is absolutely no way anybody can help him until he actually tries 6.3 and reports any actual bugs and regressions he finds. Not only is this wrong, but it completely misses the point. Why should Jo have to upgrade to find out if his servers will fail under the conditions already articulated in existing, unresolved PRs that affect hardware that he is presently using? That's a bit like saying, Buy this new car. Sure it has bugs that could easily directly affect you, but what's the chance you'll encounter them? in the off chance that they do, then you can help us resolve them. You reveal extreme naivette when you state this: That is also untrue. None of these are bugs that are affecting [Jo], since he hasn't tried
TMPFS: File System is Full
Hi, I found when we exhaust memory, tmpfs will not be able to write anything into it and cannot mount it. I use ZFS and TMPFS at the same time. Florence# cd /usr/src make buildworld /dev/null Florence# uname -a FreeBSD Florence.tamama.org 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #5: Mon May 5 00:36:32 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL amd64 Florence# mount -t tmpfs -o rw,size=1024000 tmpfs /tmp/tmpfs mount: tmpfs : No space left on device first 5 lines of top: last pid: 26893; load averages: 1.50, 1.58, 1.48 up 12+01:43:49 05:40:51 146 processes: 2 running, 144 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 406M Active, 574M Inact, 1775M Wired, 83M Cache, 214M Buf, 126M Free Swap: 1024M Total, 1024M Free I think there should be a lower bound size limit. Does TMPFS use kernel-space memory? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
