cardbus0: Resource not specified in CIS: id=14, size=400?????
I have a Netgear FA511 Cardbus NIC that I am trying to use in a Dell Inspiron 8600 laptop running 6.1-STABLE, but with limited success. When I insert it, I get the message cardbus0: Resource not specified in CIS: id=14, size=400 appear as part of the cardbus probe. The card superficially works, but very unreliably (e.g., quite a few dc0: watchdog timeout messages and no network traffic at times). What does cardbus0: Resource not specified in CIS: id=14, size=400 mean? Is this a hardware or a firmware or a driver issue? When I insert the NIC into the Dell Inspiron 8600 laptop, the MAC address that gets assigned to the interface is 00-00-00-00-00-00. This happens both under FreeBSD and Windows XP. However, when I tried the NIC in a friend's Acer laptop, the MAC address was correctly reported by Windows XP (couldn't try FreeBSD), and corresponds with the one printed on the underside of the NIC. So, it seems that the Cardbus NIC itself is okay, just not in the Dell laptop. :-( Is this something that is fixable, e.g., with a suitable device.hints or sysctl setting? Here's what is output on the Dell Inspiron 8600 when I insert the Netgear FA511 NIC (extra cardbus debugging enabled): cbb0: card inserted: event=0x, state=3920 cbb0: cbb_power: 3V TUPLE: LINKTARGET [3]: 43 49 53 Product version: 5.0 Product name: NETGEAR, Inc. | FA511 | CardBus Mobile Adapter | 1.00 | Manufacturer ID: 2d021a51 Functions: Network Adaptor, Multi-Functioned Function Extension: 0102 Function Extension: 0280969800 Function Extension: 0200e1f505 Function Extension: 0301 cardbus0: Opening BAR: type=IO, bar=10, len=0100 TUPLE: Unknown(0x04) [7]: 03 01 00 00 00 00 ff TUPLE: Unknown(0x05) [5]: 41 80 fb 00 ff CIS reading done cardbus0: Resource not specified in CIS: id=14, size=400 cardbus0: Non-prefetchable memory at f6001000-f60013ff cardbus0: IO port at d000-d0ff dc0: Netgear FA511 10/100BaseTX port 0xd000-0xd0ff mem 0xf6001000-0xf60013ff irq 11 at device 0.0 on cardbus0 miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: link state changed to DOWN dc0: link state changed to UP Here is how the Cardbus adapter is probed during boot: pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci_link1: BIOS IRQ 11 for 2.3.INTA is invalid pci2: ACPI PCI bus on pcib2 cbb0: TI4510 PCI-CardBus Bridge at device 1.0 on pci2 cbb0: Found memory at f600 cbb0: Secondary bus is 0 cbb0: Setting primary bus to 2 cbb0: Secondary bus set to 3 subbus 4 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 Finally, here is the output of pciconf -vl for the laptop (the PCI4510SDFSDFSD PC Card Controller SDFSDAFSADFSDAFSDAF description for the Cardbus bridge looks highly suspicious to me): [EMAIL PROTECTED]:0:0:class=0x06 card=0x016a1028 chip=0x33408086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82855PM Host-Hub Interface Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x33418086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82855PM AGP Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x016a1028 chip=0x24c28086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x016a1028 chip=0x24c48086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:29:2:class=0x0c0300 card=0x016a1028 chip=0x24c78086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x016a1028 chip=0x24cd8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB 2.0 EHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x24488086 rev=0x81 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DBM (ICH4-M) LPC Interface Bridge' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:31:1: class=0x01018a card=0x016a1028 chip=0x24ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DBM (ICH4-M) UltraATA/100 EIDE Controller' class= mass storage subclass = ATA [EMAIL
Re: bge watchdog timeouts still happening
On Fri, 2006-09-15 at 12:33 -0700, Kent Stewart wrote: On Friday 15 September 2006 09:28, Herve Boulouis wrote: Le 15/09/2006 18:05, Gleb Smirnoff a écrit: H bge0: Broadcom BCM5700 B2, ASIC rev. 0x7102 mem 0xfeb0-0xfeb0 irq 17 at device 8.0 on pci1 H miibus0: MII bus on bge0 H brgphy0: BCM5401 10/100/1000baseTX PHY on miibus0 H brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto H bge0: Ethernet address: 00:06:5b:1a:7f:4a Is it integrated or not? I've got exactly the same NIC and I can try to reproduce the problem if you describe the workload. Yes, it's the onboard bge. Workload is 10-25 Mbit/s of web hosting. It seems to be at the top of the tree somewhere because people are also seeing the watchdog timeouts on em and I get them on the gigabit re's. I got them downloading the kde-3.5.4 distfiles on a 768kb DSL line. I had setiathome running, which keeps the cpu useage close to 100%. FWIW, I get repeated watchdog timeout errors on 6-STABLE with a dc-based Cardus NIC (Netgear FA511). The worst behaviour I observed was under heavy NFS load, with the link being unavailable for extended periods of time. Mostly, though, the problem manifests itself when the card is inserted and the interface is trying to be brought up via DHCP using dhclient, as if the NIC is not being initialised properly, perhaps. I don't know if this is the same problem, but I thought I'd mention it. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Here is what I get when I run diskinfo on one of the (somewhat elderly) disks I use in my desktop system (this is a drive I use for data, and it is idle): zappa# diskinfo -tv /dev/ad4 /dev/ad4 512 # sectorsize 25590620160 # mediasize in bytes (24G) 49981680# mediasize in sectors 49585 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 5.159189 sec = 20.637 msec Half stroke: 250 iter in 4.206125 sec = 16.825 msec Quarter stroke: 500 iter in 7.151951 sec = 14.304 msec Short forward:400 iter in 2.794380 sec =6.986 msec Short backward: 400 iter in 4.135579 sec = 10.339 msec Seq outer: 2048 iter in 0.332711 sec =0.162 msec Seq inner: 2048 iter in 0.363152 sec =0.177 msec Transfer rates: outside: 102400 kbytes in 7.677977 sec =13337 kbytes/sec middle:102400 kbytes in 9.151475 sec =11189 kbytes/sec inside:102400 kbytes in 14.345492 sec = 7138 kbytes/sec Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 11:38:44 -0400: Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. Which is not the case according to the OP... (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? ... rendering this completely irrelevant. ...especially when you've cut out the context of my reply. :-) My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. If I had been responding to a specific aspect of the OP's benchmark (or indeed anything the OP has said), I'm sure I would have quoted that to make the context clear. I have seen people come to a freebsd list with completely flawed comparisons or benchmarks: OSs installed on different partitions side by side, not taking VM cache into account, whatever, and be told that their numbers are flawed. I have also seen people test a specific subsystem (dd), and be told that their numbers don't reflect real world. And I have seen people test real world performance (install FreeBSD, install MySQL, run a stress test, reformat, install Linux, install MySQL, run a stress test) and get responses that try to make up reasons why the bad results are the testers fault). Heck, if installing an operating system, a database, and running it isn't a real world test, I don't know what is. Even if the bug is FreeBSD puts /var/db/mysql in the wrong part of the disk (then it's still a problem in FreeBSD, not in the messenger). I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. As it says in the BUGS section of the diskinfo man page: There are in order of increasing severity: lies, damn lies, statistics, and computer benchmarks. ;-) Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 19:17 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400: What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. Say I install FreeBSD (using default partitions), install MySQL from a package on the CD, run a stress test, collect numbers, then repeat the process with a Linux installed over the previous FreeBSD installation, and find out that FreeBSD allows the MySQL server process 1/3 queries less, what (if anything) will be wrong in my claim that MySQL/FreeBSD is slower than MySQL/Linux? To make the specific claim above, it would be okay, at least in my book. To make a more general claim, pedantically speaking, you should, e.g., replicate your benchmark using various different hardware combinations, to rule out the possibility of a pathological case affecting one or other OS (e.g., where one OS has much better driver support for some specific hardware aspect than the other). Also, you would need to be careful how you stated your claim. For example, it would be better to say something like untuned MySQL/Particular-FreeBSD-Version on a default install is slower than untuned MySQL/Particular-Linux-Distribution on a default install. If you test many Linux distributions and find they beat out all the FreeBSDs, then a more general MySQL/FreeBSD and MySQL/Linux might be appropriate. Similarly, if no amount of tuning lets FreeBSD MySQL compete with Linux, I'd say your original statement would be defensible. However, if some combinations of MySQL and FreeBSD tuning perform better than some well-tuned MySQL/Linux distributions, then it's not so straightforward to claim MySQL/FreeBSD is slower than MySQL/Linux. (It may be that default tunings favour one or the other. I'm sure the Linux people would gripe that you're using filesystem X instead of filesystem Y, which would give better performance.:) If you just want to make a benchmark statement about untuned installs on default distributions, that's fine, but I'm not sure how illuminating that is for the real world given that production systems are normally tuned for performance. Although this might seem like splitting hairs to the extreme, I guess the point I'm making is that benchmarks can be highly subjective. Unless you learn the context and point of view in which it was performed, you can't really tell if the results apply to you. In fact, even a very good benchmark may not yield the expected performance in the real world when run in an environment containing other systems (e.g., Apache, Squid, Postfix, etc.) that interact and contend for resources and affect performance in a way not measured when the systems are benchmarked in isolation. I guess the preferred colour for the consumers of benchmarks is black and white, when in reality what you get are subtle shades of grey. :-) Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Sat, 2005-07-16 at 16:16 +0200, Matthias Buelow wrote: David Taylor wrote: No. I'm just asking if you know of ANY ata drives that will wait for the cache to be flushed before claiming the disable cache command has succeeded. I don't, but I haven't looked. I don't know either. I assume that they do. Does it matter? I mean, I'm not suggesting a frivolous new theory that is highly speculative and warrants a lengthy debate on its purported merits. What I described is common practice on Windows, Linux and probably a few other systems and I would think that they're not doing this for nothing. And, frankly, I'm a bit astonished that the FreeBSD (community) seems to be so ignorant of well-known measures for improving data safety on consumer-grade desktop hardware. Does that mean that FreeBSD is deemed generally unsuited for desktop and laptop use and should be reserved for servers with the appropriate (expensive) hardware? I hope not. I recall reading on freebsd-current that Scott Long is working on adding journalling support to FFS. Perhaps you'd like to direct your input to him instead of rehashing it repeatedly on here, which is the wrong outlet for such discussion anyway: by definition, CURRENT, not STABLE will get a new feature like journalling, and so discussing the ins and outs of it on freebsd-current would seem more apropos. (Plus, I'd hate to see him implement something only for you to declare it to be the wrong way to do things. Better to get your 2p in now.:) Reagrding your question of does that mean that FreeBSD is deemed generally unsuited for desktop and laptop use, I can speak only from experience. I run 6-CURRENT on an ATA system using softupdates on my desktop, and have been doing so for quite some time. I've seen through quite a few periods of extreme growing pains for CURRENT, with seemingly random panics and mystery crashes at times. (Who can forget the dark days of the ULE + PREEMPTION instability?) Add to the mix that my neighbourhood has pretty flaky power, with a tendency for short interruptions at the first whiff of bad weather. This all adds up to a good smattering of reboots at inopportune times (like when doing buildworlds or large portupgrade sessions:). Despite that, I have never EVER had a problem with data consistency on my file systems. (The only problem I have had is when I added an ATA controller card one time and forgot to disable its RAID BIOS, which promptly spammed over my geom_mirror metadata.:) If softupdates were as unsafe as you often hint, I'm surprised that I haven't lost a file system by now. (I would also expect to hear from the field a lot more clamour about how unsafe it is, and that, in fact, the sky was indeed falling.) I guess I must be amazingly lucky and should start playing the lottery right now. :-) The main inconvenience I have with panics or outages is the fsck times on reboot. (Actually, what I find to be more inconvenient is the resynchronisation time needed for my geom_mirror, which takes a lot longer than a fsck.) I understand that fsck delays for large file systems is the major impetus behind the journalling work, not as a fix for a perceived data consistency problem. Cheers, Paul. PS: I also use softupdates on my NetBSD systems, again without problems. I've also used LFS on NetBSD at times, but have always ended up abandoning it due to performance and severe data reliability problems. (To be clear, though, I'm not sure LFS was deemed to be for production use, at least not the times I tried it.) -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Mon, 2005-07-18 at 16:35 +0200, Matthias Buelow wrote: Oliver Fromme [EMAIL PROTECTED] writes: buffers to disk. While it is doing that, it displays the number of remaining buffers, with increasing time intervals between them. If there are still buffers left after a certain number of intervals without change, the kernel gives up. Why is it doing this? Can't it just enumerate the buffers and write them, one by one? Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. You can enumerate the buffers and *try* to write them, but that doesn't guarantee they will be written successfully any more than observing the relative number left outstanding. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Mon, 2005-07-18 at 17:14 +0200, Matthias Buelow wrote: Paul Mather [EMAIL PROTECTED] writes: Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. So the kernel is relying on guesswork whether the buffers are flushed or not... I don't know if you are just deliberately trying to be contentious, but that is a serious misrepresentation of what is happening. Quite obviously the kernel knows whether a buffer has successfully been flushed, otherwise a count of outstanding buffers would be meaningless. (Surely you're not saying the kernel simply guesses if a buffer has been flushed in maintaining its count of outstanding buffers? What would be the point of that?) If you calm down and think about it for a little, you'll realise what you suggest to do and what is actually done amount to the same thing in practical terms. It's all very easy to say to write each buffer synchronously (and wait for the disk's response), but what do you do when the buffer *does* get stuck and won't complete (e.g., because someone removed the floppy or USB disk, or your remote ggate server disappeared, or your hard disk is going bad, etc.)? Do you just bail immediately at that point? Or do you keep retrying in the hope it will complete? In the end, it comes down to waiting a certain amount of time for drivers to do their best and then giving up. The only real question is how long you wait, and maybe whether syncer is not waiting long enough (and hence how to extend the amount of time it is willing to wait until it gives up on buffers being unflushable). I'm not sure why that is fundamentally madness. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: READ_DMA, WRITE_DMA errors
On Wed, 2005-07-20 at 23:54 -0500, Steve wrote: I've found tons of emails, news messages, listserv messages, and even some bug reports of this seemingly common error. So, I had been running 5.2 on a server, and, updated to 5.3. Got the READ_DMA and WRITE_DMA error and retries. So, figuring it might be a bad update, took a new drive. put it in, loaded 5.4 for grins, and, same issue, lots of these errors, eventually destroying the FS. Played around with various settings, no avail. So, took it back, got different box, everything new. Same problem, new install of 5.4 So, took it back, got another with another MB (different model), but, same maker (ASUS). Didn't have endless time to spend on production machine. Sure enough, same problem. It's an ASUS A7V880. Controller is SATA VT8237. Played around with tons of settings, eventually, after reading various messages out there, discovered one that resolved the problem. Had to set hw.ata.ata_dma=0. Of course, there is the obvious downside to that! Speed! But it stinks to have decent hardware, yet, have to cripple the machine. The place I got the equipment at runs ASUS only and has thousands of them running under other OSes. Wished I had stayed with the old FreeBSD version and old hardware now. I have not seen anyone that has ever said the problem was being (or had been) solved though. I see the bug reports, I take it no one has actually pinpointed the problem though. BUT, I do hope it is understood that this is fairly widespread, for me, the likelihood of 3 pcs, 2 different MB models, and, *complete* new hardware for each of the 3 pcs kind of rules out hardware being broken, might be badly designed, but, certainly not defective hardware. I do hope someone can eventually figure this out, seems to be extremely common, and, definitely a problem for a stable release named 5.4. I was one of the people who suffered from and reported this seemingly common error. On the systems that encountered problems, none had particularly obscure or cutting-edge hardware (e.g., Intel PIIX4 ATA controller on the motherboard). One common thread in my case is that all ran some kind of software RAID (gvinum or gmirror), though not all of my software RAIDed machines exhibited the DMA problems leading me to think perhaps it was a hardware/load/disk combination problem. Quite obviously, not all PIIX4 controller users were having this happen, and so the it doesn't happen to me factor might have contributed to the general notion that this was probably operator error or something like that, and dismissed. Anyway, as well as 5-STABLE, I also run a 6-CURRENT system that suffered the problem. Happily, after the ATA Mk.III merge, the situation improved a LOT. I occasionally still get the error reported, but it is not fatal, unlike before (where the drive would be detached, breaking my geom_mirror, necessitating a lengthy background rebuild). So, I consider the ATA Mk. III rewrite to have fixed the problem I had. It may be, then, that those upgrading to the upcoming 6.0-RELEASE (when it appears) might also find their ATA DMA problems solved, too. As for 5.x, I track -STABLE, and have noticed slight improvements regarding the DMA TIMEOUT problem. If you only run -RELEASE, you might miss these ongoing improvements that crop up from time to time. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quality of FreeBSD
On Thu, 2005-07-21 at 14:26 -0500, Karl Denninger wrote: Ok, Robert, but then here's the question How come the ATA code which was very stable in 4.x was screwed with in a production release, breaking it, with no path backwards to the working code? Not to mention that this happened during the 5.x release cycle. It's one thing to have a regression creep in when moving from one major release to another (e.g., oh, that's the fallout from introducing Big Feature XYZ or a big architectural revamp may have broken some things), but it's another thing entirely to have it happen between minor releases, which are supposed to be evolution, not revolution. (Although the whole Early Adopter status for early 5.x releases might mean all that is muddied when it comes to the 5.x series.) My main disappointment with the ATA DMA TIMEOUT bug is not that it crept in (these things happen), but that it did not seem to be taken seriously when it had done so. (Though, as Robert said, if the developers can't reproduce the problem, it's hard for them to work on and fix it.) Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Create 2.5TB file system on 5.4S?
On Tue, 2005-08-16 at 16:21 -0700, Brandon Fosdick wrote: David Magda wrote: There's the Bonnie and Bonnie++ file system testing programs. I believe one or both are in the Ports. Thanks. I'll take a look. There's also raidtest in benchmarks/raidtest in the ports tree that can be used to generate synthetic I/O load and measure performance. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Tue, 2005-08-30 at 03:11 +0200, Matthias Buelow wrote: BTW., when have you last seen a broken NTFS? While I don't do Windows much, I have had quite a few crashes on Windows (2000, XP) over the years on various machines, and I always asked myself how it could be that the system is up almost immediately (probably due to log replay) with no discernible filesystem damage. Windows (NT) has been doing the write barrier flush tricks (disabling-/ reenabling the cache for flushing it) for longer than Linux and I would think that this contributes to the fault resilience of NTFS. Not that I would imply that NTFS can't be corrupted, of course. Funny you should mention it, but the last time I saw a broken NTFS was back in July. It was a friend's Windows 2000 system. The net effect was that the system would not boot fully; was not responsive to the repair option; and wouldn't allow the recovery console to start. In the end, a wipe and reinstall was necessary. Oddly enough, trying to mount the NTFS file system via a Knoppix CD before resorting to that yielded complaints about the journal being corrupted. I guess I must be lucky because I've never yet had a corrupted file system with softupdates enabled due to power loss or panic under FreeBSD (though I've experienced plenty of power losses due to the flaky power here and panics due to tracking CURRENT on my desktop system:). By reading your regular dire warnings on the subject, my experience must differ greatly from yours. ;-) BTW, if you consider softupdates fundamentally broken wrt data integrity, why don't you post your concerns to -current or -hackers, say? Surely the developers to address the problem are more likely to be found reading there? Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tx underrun ? (add entry into xl manpage)
On Wed, 2005-11-30 at 04:37 -0800, Rob wrote: Vincent Blondel wrote: Hello all, When having a look at log files on my web servers, I regulary see next output on the 3COM ethernet interfaces : xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 180 bytes xl1: promiscuous mode enabled xl1: promiscuous mode disabled Can somebody explain me what it is and if this situation is normal ? Rumours are that these messages are harmless, but if someone can explain these messages properly, it would be nice to add an entry to the DIAGNOSTICS section of the xl manpage (hence, this mail also goes to doc mailinglist) I see these messages too on my router/gateway: xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 240 bytes This is from the dc(4) man page: dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. The driver will dynamically increase the trans- mit start threshold so that more data must be DMAed into the FIFO before the NIC will start transmitting it onto the wire. I'm assuming the explanation also holds true for other drivers (xl, etc.) that issue this warning. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_5, snapshots and disk lock time
On Mon, 2005-03-07 at 15:21 +0300, Dmitry Morozovsky wrote: Dear colleagues, dumping the snapshot of 140G ufs2 fyle system under contemporary RELENG_5 I found that during mksnap_ffs file system is unresponsible even for reading for more than 3 minutes (it's on modern SATA disk with 50+ MBps linear transfer). Is it normal? Oddly enough, this happened to me last night on a RELENG_5 system. In my case, things were so bad that mksnap_ffs appeared to wedge everything, meaning I'll have to make a trek in to where the machine is located and press the ol' reset button to get things going again. :-( The machine in question makes and mounts snapshots of all its filesystems for backup each night via Tivoli TSM. This has worked flawlessly for many months. Last night, I had many BitTorrent sessions active on the filesystem that wedged. I guess the activity broke the snapshot mechanism. :-( The odd thing is that it survived the night before, when there were also BitTorrent sessions active. I wonder how much activity mksnap_ffs can take? Cheers, Paul. PS: The problematic file system was not low on space, which could be an issue for snapshot creation. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem with current 5.4-PRERELEASE
On Wed, 2005-03-30 at 23:30 -0600, Karl Denninger wrote: BTW its NOT your hardware at fault here - the same hardware that returns these complaints for me on 5.x works perfectly with 4.11. There have been changes made to the ATA code that apparently interact VERY badly with some controllers - particularly some very common SATA (SII chipset, used on Adaptec and Bustek boards, among others) ones. It's not just a SATA problem. I get the problem (though more infrequently than it seems you do) on an Intel PIIX4 UDMA33 controller. The problem occurs on two different systems (one Gateway, one Dell), and only started happening some way through the 5.x life cycle, indicating to me that a serious regression was introduced (in 5.2, I believe). The problem does not afflict 4.x. I don't know if GEOM/GMIRROR is truly involved here although that's the easiest way for me to provoke it - I suspect not - its just that GEOM/GMIRROR produces an I/O load pattern that is conducive to the breakage showing up. Specifically, a DD from one or more disks does NOT fail - a mix of reads and writes and fairly significant load appears necessary to cause trouble. Of course installation produces a very nice load of that type On both systems that experience the problem, I am using some kind of software mirroring. On one I'm using geom_mirror, and on the other I'm using geom_vinum. Both suffer from the WRITE_DMA disconnect problem. The Dell, using geom_mirror, is now running HEAD. The Gateway running RELENG_5 is annoying because when a drive becomes disconnected, the only way right now to rebuild the plexes on the geom_vinum drive that is down is to reboot the system. (I've used setstate to flag the drive as up, but then gvinum start of any down plex causes an immediate panic/reboot.) Ian Dowse posted a patch to the freebsd-current mailing list for the WRITE_DMA issue (http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-February/046773.html). According to Dowse, the patch attempts to clean up the handling of timeouts in the ATA code by using the new callout_init_mtx() function. It was successful for me. I still got the WRITE_DMA timeouts, but not the disconnects. I don't know if RELENG_5 has the new callout_init_mtx() function. If it does, this patch might help there, too. I opened a PR on this quite some time ago - IMHO this sort of breakage should be considered a critical fault sufficient to stop a release until its completely resolved. A workaround that stops the system from blowing up but leaves the pauses and errors isn't really a fix - I doubt anyone will consider that acceptable as a means of truly addressing the problem (at least I hope not!) I agree that it wouldn't be ideal, but having something that fixed just the disconnects in the tree would be better than nothing at all. It's a pain to have to track third-party patches. I got surprised by this (in a bad way) and have been fighting workarounds since 5.3 was deemed production quality. Going back to 4.x is possible for me, but highly undesireable for a number of reasons, not the least of which is the official FreeBSD posture on where work is and will be done on the OS down the road. It's disappointing the way this problem appears to have been silently ignored (except by those whom it afflicts), because it is a regression that occurred during the 5.x lifecycle. It's one thing to know that your hardware won't work properly going from 4.x to 5.x, but another thing to have it stop working going from one 5.x release to another. (Or maybe it isn't, given the strange Early Adopter status of the start of the 5.x release cycle.) Anyway, I'm glad you are trying to keep this problem in the spotlight, because an unreliable ATA subsystem is a miserable thing to have to suffer. :-( Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum or gvinum on FreeBSD 5.4
On Thu, 2005-04-21 at 10:39 +0200, Claus Guttesen wrote: Hi. I may implement (g)vinum to stripe two 2 TB raid 5 volumes into a single 4 TB vinum-volume. The volumes reside on a atabeast doing the raid 5. The server is a 5.4 RC2 doing nfs on i386. According to some threads gvinum may not be completely stable (in 5.3, http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-11/0537.html) when doing raid 5 but works fine when striping. Should I go vinum or gvinum? Will newfs have problems with a 4 TB volume? Are there any performance-degradation doing striping? In addition to vinum and gvinum, have you considered geom_stripe? See gstripe(8) for details. I've been using it for a while on 5-STABLE to join two 65 GB slices on two different drives into a single 130 GB device (/dev/stripe/data in my case). I have had no stability problems, which is why I mention this as a possible solution for you if you're worried about the stability of vinum or gvinum in 5.x. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum or gvinum on FreeBSD 5.4
On Thu, 2005-04-21 at 10:39 +0200, Claus Guttesen wrote: Hi. I may implement (g)vinum to stripe two 2 TB raid 5 volumes into a single 4 TB vinum-volume. The volumes reside on a atabeast doing the raid 5. The server is a 5.4 RC2 doing nfs on i386. According to some threads gvinum may not be completely stable (in 5.3, http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-11/0537.html) when doing raid 5 but works fine when striping. Should I go vinum or gvinum? Will newfs have problems with a 4 TB volume? Are there any performance-degradation doing striping? I forgot to mention, but you should consult http://www.freebsd.org/projects/bigdisk/ to get an idea of the current state of play and issues regarding large disk handling in FreeBSD. According to the table of userland tools, it should be okay to newfs a file system 2 TB, but you might not be able to fsck or dump/restore it. :-( Also, I think that page holds for -CURRENT, and may not apply to 5.x. But, Pawel Jakub Dawidek has worked on large disk support, and so there's a good chance that his geom_stripe feature is able to handle 2 TB sizes. You could test it via gstripe on large swap-backed md providers. I also dimly recall you may run into problems running out of RAM trying to fsck very large filesystems. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum or gvinum on FreeBSD 5.4
On Fri, 2005-04-22 at 04:48 +0200, Vladimir Botka wrote: Hi, vinum is not stable under 5.4. After some research I found gmirror (RAID1) is ok. There are some notes on: http://www.freebsd.org/releases/5.3R/errata.html Cheers, Vladimir. On Thu, 21 Apr 2005, Paul Mather wrote: On Thu, 2005-04-21 at 10:39 +0200, Claus Guttesen wrote: Hi. I may implement (g)vinum to stripe two 2 TB raid 5 volumes into a single 4 TB vinum-volume. But geom_mirror (gmirror) would not do what the OP wants (i.e., stripe, not mirror). Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror
On Sat, 2005-05-14 at 11:30 +0100, Dominic Marks wrote: The seek times are way down, which is great, and makes sense using a round-robin strategy on the mirror, but my peak transfer rate has been almost halved too. I don't mind this too much as in my application low seek times are worth more than high transfer rates, but it is still puzzling to me to see such a remarkable drop in throughput. For large sequential reads on a round-robin mirror, you might be forcing each drive to do a lot more small seeks than if you just accessed the data from a single drive, and those small seeks may be slowing down the overall transfer significantly. I would have thought that large, whole-track caches prevalent on modern hard disks would ameliorate that problem in an otherwise quiescent environment, but, dependent upon the drive's caching policy, you never know... Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror
On Sat, 2005-05-14 at 18:00 +0400, Vladimir Dzhivsanoff wrote: three parallel tasks of dd is not good model for random reads ? Probably not, especially if you start the parallel tasks going at the same time. That way, the second and third tasks are almost certainly hitting data in the hard drive's cache, rather than the actual disk platters, and so are more likely to be testing the interface transfer speed than the hard drive's sustained performance. For a better model (of parallel large sequential transfers), you should at the very least stagger the start times of each task, to minimise cache effects. The better question to ask yourself is this: are large sequential transfers a good model of my workload. That is what you are testing with your dd's. Seek times are the dominant cost of a disk transfer. Large sequential transfers are a best-case scenario for I/O measurements because they involve minimal seek overheads. However, best-case and real-world are not usually the same thing. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol raid1 vs. gmirror
On Sat, 2005-06-11 at 14:42 -0400, Mike Jakubik wrote: Can someone explain tome the difference between a RAID1 setup done via atacontrol and gmirror? I have a VIA 6420 SATA150 controller, which also has raid, but is not supported by -stable. Here are the main differences, as I see them: atacontrol RAID: - Only for ATA; - Compatible with quite a few ATA RAID card BIOS metadata formats, hence you can create the RAID using the RAID controller's BIOS menu; - Supports only two-way mirroring (IIRC); - Supports spares. gmirror: - Works with any GEOM provider (ATA, SCSI, ggate, etc.); - Uses the last sector of each RAID component to store its own metadata; - Supports N-way mirroring; - Does not support spares (though gmirror activate/deactivate can be used to associate a component with a mirror somewhat akin to having a spare). I found array rebuilding to be troublesome on atacontrol RAID---so much so I abandoned it and used vinum and then gmirror instead for my RAID 1. (I have a bootable geom_mirror setup, now.) Mind you, that was in the pre-ATA mk.III days, and I hear the RAID support underwent a big revamp in the mk.III rewrite. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol Raid, cannot re-add member to array
On Sun, 2004-07-04 at 18:10, Simon L. Nielsen wrote: On 2004.07.04 23:33:28 +0200, Harald Schmalzbauer wrote: I've never tried ataraid with non-raid controllers but I doubt that detach/attach would work. It does work, you just have to hotswap the disk [1]. I tried it some time ago, and I successfully did a rebuild, though I did kill one of the disks shortly after since I tried to plug in the power cable the wrong way during another test (yes that's stupid, I know :-) ). So does this mean ATA RAID doesn't work on non-raid controllers that have non-hot swappable drives attached? (E.g., a drive get hard errors, is marked as failed and the RAID as DEGRADED, and you have to shut down the machine to remove and replace it---but ATA RAID won't recognise it/rebuild onto it when you reboot with the replacement drive.) If that is the case, the man page really should note that serious limitation. I have tried the detach/attach on a non-raid controller to simulate failure and have *never* managed to get rebuild to work. I've also tried the shutdown/remove/replace/reboot method but, again, *never* managed to get rebuild to work on a non-raid controller. :-( I've never had any hotswap-capable drives to test the hot-swap replacement/rebuild method. :-( Well, I'm using it just fine on my main mailserver (running 5.2.1) but that's a RAID1 with standard a ATA controller. I wish it would work for me. :-) I have a non-raid controller 5.2.1 system that I tried it on (with non-hot swap drives) that I eventually had to bail and use Vinum on. Alas, Vinum seems to be rotting at a fast pace in CURRENT, so I'm worried about the prospect of being able to upgrade that system when 5.3 rolls around... :-( Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vinum problems in 5.3-BETA7?
On Fri, 2004-10-08 at 07:52, Patrick M. Hausen wrote: We have a production system that runs on a vinum system drive configured like this: [[Configuration omitted.]] It's currently running fine with FreeBSD 5.2.1-RELEASE-p10. After upgrading to 5.3-BETA7, buildworld, buildkernel, installkernel and reboot the system stops: vinum: loaded vinum: no drives found That's it. Of course it complains that it can't mount /dev/vinum/root. The list of detected GEOM devices at the mountroot prompt includes ad0s1h, ad1s1h, ad0s1, ad1s1, ad0, ad1 and some more partitions. Where do I go from here? Is this expected behaviour due to the ongoing GEOM changes or should I go read Greg's how to debug vinum problems document? I will do that, no problem. Just want to know if it makes sense at all, because now everyone might tell me vinum is known broken in 5.3 or similar. Vinum is known broken in 5.3. :-) You should be using geom_vinum instead. It will largely be a drop-in replacement for your above Vinum configuration. (I am using it on a similar root-on-vinum setup.) The main changes are these: 1) Load geom_vinum in /boot/loader.conf, e.g., add 'geom_vinum_load=YES' to /boot/loader.conf. This will auto-detect your Vinum on-disk configuration during boot. You don't need any rc.conf glue with geom_vinum. 2) Change vinum to gvinum in /etc/fstab. E.g., use /dev/gvinum/root instead of /dev/vinum/root 3) The userland utility is gvinum instead of vinum. I am using geom_vinum on a root-on-vinum configuration under 6-CURRENT since before RELENG_5 was branched, and I believe the same holds true for RELENG_5 and HEAD as far as the above three points are concerned. I don't know if there are plans to replace vinum entirely with gvinum (and drop the g prefix) for 5.3-RELEASE. Lukas Ertl would know. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum again?
On Mon, 2004-11-15 at 00:36 -0500, Zaphod Beeblebrox wrote: I'm looking at gstat while fsck'ing a gvinum partition. The trouble I'm seeing is that I don't see activity on the second disk. Now... I'm using fsck -n ... just checking things ... so there's no writes, but does gvinum not (yet) load balance on reads? Your observation is correct: it doesn't (yet) load balance across plexes of mirrored volumes; geom_mirror (gmirror) does, though (and offers various load-balancing options). Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum again?
On Mon, 2004-11-15 at 02:31 -0500, Zaphod Beeblebrox wrote: On Mon, 15 Nov 2004 01:26:54 -0500, Paul Mather [EMAIL PROTECTED] wrote: Your observation is correct: it doesn't (yet) load balance across plexes of mirrored volumes; geom_mirror (gmirror) does, though (and offers various load-balancing options). Is this something planned for the near future? I'm migrating legacy units here, so I don't really have a choice. I don't know about the *near* future, but I believe it is on Lukas' ([EMAIL PROTECTED]) list of things to do. You'd probably have to ask him how high it is on the list, though. ... also ... I suspect, whatever form it eventually takes, that volume management and geom and/or vinum is essential. I my case I had a legacy root-on-vinum all-mirrored setup, and so was interested in mirroring more than LVM. (Like many, I'd used vinum just as a way of accomplishing a software RAID 1 across two drives to provide extra tolerance to drive failures.) So, migrating from geom_vinum to geom_mirror was not such a burden (or a hurdle). I don't know if growfs is 100% robust enough yet to provide the other important ingredient to a true LVM storage management system a la the logical volume manager on AIX or AdvFS on Tru64, say. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum again?
On Mon, 2004-11-15 at 19:33 +0100, Matthias Schuendehuette wrote: Hi, Am Montag, 15. November 2004 18:25 schrieb Paul Mather: [...] I don't know if growfs is 100% robust enough yet to provide the other important ingredient to a true LVM storage management system a la the logical volume manager on AIX or AdvFS on Tru64, say. Yes, it is. I use (g)vinum primarily as a LVM with concat plexes on ProLiant Servers with SmartRAID-Controllers, so mirroring and/or RAID5 is done in hardware. The extension of filesystems on concat plexes works (simply) as advertised... :-) At least *I* had no problems so far. That's encouraging to hear! Can you shrink volumes and filesystems like you can on, say, AdvFS under Tru64? That would be really nice. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat regression (RELENG_4 - RELENG_5)
On Wed, 2004-11-17 at 09:51 +0200, Dmitry Pryanishnikov wrote:
Hello!
While playing with fresh installation of 5.3-RELEASE (GENERIC kernel) I've
noticed that I can only see my HDD in the left lower corner of the systat's
vmstat screen. I also have working floppy and CD-RW drives, both are detected
and work, but I can't see data transfer stats for them. In 4.10-RELEASE, I see
ad0,acd0,fd0 here, but in 5.3-RELEASE I see only ad0.
After reading manual page systat(8) I see the root reason of this
behaviour:
kernel devstat(9) subsystem only sees my ad0. Under 4.10-RELEASE, sysctl
kern.devstat.numdevs gives 3, but under 5.3-RELEASE only 1. How can I enable
disk statistics gathering for disks other than HDD in 5.3-RELEASE?
The gstat(8) command will display statistics for all GEOM disks,
including floppy and CD-{ROM,R,RW}.
Cheers,
Paul.
--
e-mail: [EMAIL PROTECTED]
Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid.
--- Frank Vincent Zappa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Mount pending error?
Last night, this appeared in my logs (and on my console): Nov 23 03:05:36 zappa kernel: /data: mount pending error: blocks -1696 files 0 What is a mount pending error? I have heard this in conjunction with unclean shutdowns and fsck, but my system was not shut down recently, nor has /data (on a geom_stripe) been unmounted (cleanly or otherwise). The only thing I have done that could be related is to make a snapshot (later removed), but it was not of the filesystem being complained about. (Also, I create and mount snapshots of all my filesystems as part of my nightly TSM backup.) I guess I should shutdown and fsck just to make certain everything is okay. I am puzzled why this happened, though. (I've been running the backups for a while, and have not had any complaints.) BTW, I'm running RELENG_5, last rebuilt Nov. 19th 2004. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: graid3 - requirements or manpage wrong?
Brian Szymanski wrote: As for the swap: why would you want to do that? It was my understanding that the kernel load balanced swap requests across drives? You'd want to do it not for load-balancing but for fault tolerance. With a RAID 1/3/5 setup you could have a drive fail and still have swapping (and hence the system) continue to work. That's not the same as (or true of) having multiple swap partitions with the system balancing load over all of them. Cheers, Paul. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bios disk numbers and device names
On Mon, 2004-11-29 at 15:06 +0100, Andrea Campi wrote: The manpage explains it all, and that's all I know as well. glabel specifies a transient label, i.e. it's not saved on the disk, so you loose it on reboot or if the disk goes away. Glabel can create both transient and permanent labels: glabel create label provider is transient; glabel label label provider is permanent. In the latter case, the label metadata is stored in the last sector of provider. If geom_label is built into the kernel, or loaded as a kernel module at boot (e.g., via /boot/loader.conf) then labelled providers will be automagically discovered and /dev/label/... entries created during boot. In this way, devices can be given logical labels that will stick with them when they move around. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On Mon, 2004-12-13 at 10:28 -0800, Doug White wrote: On Sun, 12 Dec 2004, Joe Rhett wrote: On Sun, Dec 12, 2004 at 09:59:16PM -0800, Doug White wrote: Thats a nice shotgun you have there. Yessir. And that's what testing is designed to uncover. The question is why this works, and how do we prevent it? I'm sure Soren appreciates you donating your feet to the cause :) Why it works: the system assumes the administrator is competent enough to not yank a disk that is being rebuilt to. That's not quite fair. He was obviously testing to see how resilient ATA RAID is to drive failures during rebuilding, as part of a series of tests. (Obviously, it is not.) If you look at his original message, he did not even yank the disk. He detached it in a somewhat orderly fashion using atacontrol detach. (One can argue that physically yanking it might have been a more accurate, if more severe failure test.) This makes the ensuing panic even more sad. (Would the same panic result if the disk being rebuilt fell victim to one of those TIMEOUT - WRITE_DMA errors that are in vogue nowadays and was detached by the system? I get those errors occasionally [never used to under 5.1 on the exact same hardware] but my geom_mirror has coped with it so far, thankfully.) It's reasonable to conduct simulated failure testing of ATA RAID (or others such as geom_mirror and geom_vinum) prior to adopting it on your system. I know I did in the case of ATA RAID and abandoned it precisely because it turned out for me to be too flaky when it came to error recovery. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Sat, 2004-12-18 at 20:52 +0100, Nikolaj Hansen wrote: While some uncommon configurations, such as multiple vinum drives on a disk, are not supported, it is generally backward compatible. Note that for the geom(4)-aware vinum, its new userland control program, gvinum, should be used, and it is not yet feature-complete. I think I have to disagree calling muliple drives on a disk uncommon. In fact, I think I remember that being the way it was demonstrated in an old version of the handbook. Here is my current setup after rolling back to FreeBSD 5.2.1: I think you are misunderstanding things a little, here. It's not that multiple vinum volumes per disk can't be handled, but instead it's multiple vinum configurations per disk that are problematic. In other words, I believe it's not supported to have, say, a /dev/da0s1g vinum partition (containing vinum volumes, plexes, and subdisks) and also, say, a /dev/da0s1h vinum partition (again, containing vinum volumes, plexes, and subdisks). Such a setup was okay under the old vinum, but is not okay under geom_vinum (AFAIK). As far as I can tell, the new 5.3 release makes this disk configuration invalid? The vinum configuration you listed appears fine for geom_vinum. I transitioned by old root-on-vinum all-mirrored setup over to geom_vinum without any problems. (Yours looks the same, except that you also have a third drive with a single concat plex volume on it.) If not I have a major problem here :-( The biggest problem you'll have is if your system suffers the ATA TIMEOUT - WRITE_DMA woe that bedevils some of us under 5.3. When that happens, your mirror will be knocked into a degraded state (half of your mirrored plexes will be marked down) even though the drive is okay. Unfortunately, without setstate being implemented in gvinum to mark the drive as up, thereby allowing you to issue gvinum starts for the downed plexes, there's little more you can do to get the failed drive recognised as being in the up state other than to reboot. (You might be able to use atacontrol to stop/start or otherwise reset the drive; in my particular system I can't use atacontrol detach/attach because they're both on the same channel.) At any rate, every so often, when this happens, you'll have to resynchronise the failed plexes, which *really* sucks the I/O life out of the system because there's no way to throttle back reconstruction, unlike with geom_mirror (which has two sysctls to govern the load imposed by resynchronisation). But, it looks like you're lucky, because your mirrored drives are SCSI. I don't know about your ATA concat plex volume, though... Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Sun, 2004-12-19 at 00:15 +0100, Matthias Schuendehuette wrote: Am Samstag, 18. Dezember 2004 23:35 schrieb Paul Mather: The biggest problem you'll have is if your system suffers the ATA TIMEOUT - WRITE_DMA woe that bedevils some of us under 5.3. When that happens, your mirror will be knocked into a degraded state (half of your mirrored plexes will be marked down) even though the drive is okay. Unfortunately, without setstate being implemented in gvinum to mark the drive as up, thereby allowing you to issue gvinum starts for the downed plexes, there's little more you can do to get the failed drive recognised as being in the up state other than to reboot. [...] 'gvinum setstate' was MFCed from -current together with 'gvinum checkpatity' and 'gvinum rebuildparity' a week ago or so... So that should make it easier to handle these ATA-Problems... That's great to hear! (I'd been hoping for an MFC5.) It's handy, too, as I just recently got another one of those TIMEOUT - WRITE DMA induced failures, which was getting to be a real drag. :-( I'll update my 5.3-STABLE system right away... Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Tue, 2004-12-21 at 19:00 +0100, Nikolaj Hansen wrote: I also do not think it belongs in the stable branch just yet :-D Any hope of you fixing the old vinum in the 5.3 branch or is it a wait for the 5.4? AFAIK, the old vinum will *never* be fixed in the 5.3 branch or any subsequent branch, so don't hold your breath for 5.4. The fact that it wasn't being fully GEOM-ified (and hence was dying from neglect in 5.x) was the whole reason for Lukas to embark on geom_vinum. Geom_vinum *is* vinum for all intents and purposes, from this point on. The alternative to not having geom_vinum in the stable branch would be not to have vinum support at all. Cheers, Paul. PS: If you're unhappy with geom_vinum stability and performance, and you're using it mainly to do software RAID 1 (as opposed to using it for its LVM features), you might consider using geom_mirror instead. I converted one of my root-on-geom_vinum mirrored systems over to a bootable geom_mirror. (I did it in-place, too.) Right now, geom_mirror will load-balance reads across disks, whereas geom_vinum does not, which is something in geom_mirror's favour. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to remote update 4.10 - 5.3?
Palle Girgensohn wrote: I've tried the UPDATING instructions, both locally and remotely (the latter failed ;-). But really, everything has to be reinstalled, ports and the lot, so a new install is probably the best way... That's not so bad. A reinstall means you can newfs your partitions as UFS2 filesystems, which wouldn't be the case if you upgraded 4.10 in-place. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to remote update 4.10 - 5.3?
Igor Pokrovsky wrote: Are there any other advantages of UFS2 over UFS except maximum disk size? There's FFS snapshots capability in UFS2, for starters... Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
On Thu, 2005-01-20 at 19:17 +, Chris wrote: what does -fno-strict-alias do? I cannot find it in man gcc It is a truncation of -fno-strict-aliasing. The flag does not appear to be described in the gcc man page, but is documented in the gcc info page (search for -fstrict-aliasing). To quote the info page, -fstrict-aliasing allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. ... Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
On Thu, 2005-01-20 at 16:44 -0500, Mike Jakubik wrote: Paul Mather said: On Thu, 2005-01-20 at 19:17 +, Chris wrote: what does -fno-strict-alias do? I cannot find it in man gcc It is a truncation of -fno-strict-aliasing. The flag does not appear to be described in the gcc man page, but is documented in the gcc info page (search for -fstrict-aliasing). To quote the info page, -fstrict-aliasing allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. ... Wouldn't we want strict aliasing then? Yes, but unfortunately some ports circumvent the strict aliasing rules, which is why those ports break when building with -O2 (which causes -fstrict-aliasing to be enabled). Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Starting gvinum/vinum with RAID 5 and Compaq 39160 - 5.3-STABLE
On Mon, 2005-01-24 at 14:29 -0500, Michael L. Squires wrote: I've been playing with vinum and gvinum with a RAID-1 boot setup (now abandoned, hardware RAID was $29 - SM P4DC6+ with Adaptec 2005S) and with a RAID5 array using a Compaq version of the Adaptec 39160 card. I've found that only geom_vinum_load=YES works in order to get the RAID 5 array mounted at boot time; vinum_load with or without vinum.autostart doesn't work. (Doesn't work means that the boot fails when /dev/vinum/raid can't be mounted as per /etc/fstab, and I have to execute vinum before I can mount it while running single user after the crash). I've seen one other message that vinum_load didn't work for one other 5.3-R user, but I don't know if we both made the same mistake or if something else is wrong. For 5.3-STABLE you should be using geom_vinum. That means having 'geom_vinum_load=YES' in /boot/loader.conf; /dev/gvinum/raid... in /etc/fstab (in your case); and using gvinum for userland control, not vinum. The vinum /etc/rc.conf knobs are not applicable to geom_vinum. Mixing vinum and gvinum is not recommended. If you just want a RAID-1 boot setup, you might consider geom_mirror instead. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: opinion on which software RAID to use
On Thu, 2006-03-02 at 14:11 -0500, Vivek Khera wrote: Anyhow, I see at least three ways to set up a mirror of these drives and/or partitions: gvinum gmirror atacontrol Any opinions on which has both qualities: easy to configure/manage (ie, recover after failure) and performance? The handbook RAID page doesn't even mention gmirror. The atacontrol seems very simple to use, at least. Let me know what you think. Thanks! For basic mirroring, I'd say go for gmirror. I've been using it successfully for a long time. I migrated to it from vinum/gvinum because it offered more flexible read load-balancing (you can choose between various policies) and easier recovery. It can even do N-way mirroring. I tried atacontrol in the past, but could never get it to reconstruct after a simulated failure. With gmirror, you have the option of automatic or manual reconstruction for failed/stale providers. You might want to consider gvinum if you think you might want to use RAID 5 or LVM-type aggregations in the future, but if you are just planning on mirroring I'd strongly suggest going with gmirror. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap mirror servers
On Fri, 2006-04-21 at 14:40 +0200, Benjamin Lutz wrote: On Wednesday 19 April 2006 00:44, Colin Percival wrote: I have a list of people who have offered mirrors, but so far I haven't seen any need for additional mirrors -- the two which already exist are showing no signs of slowing down. Hm, but I see a quite noticeable speed difference between portsnap1 and portsnap2. The second one is quite a bit faster. I notice that on 4.x portsnap never finds any mirrors because the grep of the output returned by host -t srv ... is not appropriate for 4.x's version of /usr/bin/host, which produces output different to that of 5.x onwards (a BIND8 vs BIND9 issue, I guess). So, maybe because of this, all of the portsnaps running on 4.x machines are hitting the same server each time instead of randomly choosing a mirror, thereby causing that mirror to be a bit more loaded? Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumping large partition to USB drive fails
On 28 Jun 2007, at 9:06 PM, Roland Smith wrote: On Thu, Jun 28, 2007 at 12:24:15PM -0700, Jeremy Chadwick wrote: On Thu, Jun 28, 2007 at 08:55:46PM +0200, Roland Smith wrote: A tip from Paul Mather pointed to problems with USB/firewire chipset, the PL-3507, which was what I found in my enclosure. Most likely this is the culprit. I'm going to buy a new enclosure. Can you provide these details (forward what Paul sent you, etc.)? It would be nice to have this info somewhere in the archives in case someone mails about similar... Here it is; I don't have your original posting, so I don't know what model of chipset you have, though I do dimly recall it being a Prolific, which is why I thought I'd e-mail you. Given that the PL3507 had an early history of problems when writing to it using large transfers (and that GELI uses large transfers, IIRC), and you say that enclosure is old, you might want to see if chipset bugs are the source of your problem. Here is a link I had bookmarked when I was looking for firmware updates for the Prolific PL3507: http://missig.org/julian/blog/2004/06/10/prolific-pl3507-firewire- device/ Here is a link to the corruption issue that plagued various chipsets, including the Prolific PL3507: http://www.bustrace.com/delayedwrite/index.htm My apologies for not doing a reply all when responding to Roland initially. As a bit of extra context to the above, a while ago I bought a cheap external FireWire/USB DVD writer for my iBook G4. I was disappointed to discover upon using it that its read performance when using the FireWire interface was much poorer than when using its USB connector. (It annoyed me especially because I had bought something that supported FireWire because I wanted to daisy-chain it with my Western Digital MyBook external hard drive to avoid using up one of the two USB ports on my iBook.) Because the FireWire and USB performance of my MyBook external hard drive is good, I doubted the problem lay with the iBook, and suspected the enclosure chipset instead. When I began searching the Web for information about the Prolific PL3507 chipset, used in the enclosure, I quickly began discovering horror stories (see above links for a taste). I realised that, if I had my time over and had known this DVD writer's enclosure used that chipset, I would not have bought it and would have looked for something whose enclosure used a different one (e.g., Oxford). I also realised that not all enclosures are created equal, and it's definitely worthwhile to know what chipset it uses beforehand and make sure you avoid the bad ones (like the Prolific). :-) Somewhat fortunately, revisions B and C of the Prolific PL3507 can have their firmware upgraded via USB. (Unfortunately, Prolific only appear to make a Windows flash writer application available.) It seems that the latest firmware at least appears to correct the worst excesses of the chipset, though people do still seem to harbour mistrust over the hardware and complain of performance problems. Although I have no plans to buy another enclosure for this DVD writer (because it works well enough for the task in hand), I think I would were it housing a hard drive, if nothing else because of the poor performance relative to the WD MyBook. Cheers, Paul. e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ZFS pool upgrade to v14 broke ZFS booting
I have a FreeBSD guest running under VirtualBox 3.1.2 on Mac OS X. It's running a recent 8-STABLE and is a ZFS-only install booting via gptzfsboot. I use this VirtualBox guest as a test install. A day or so ago I noticed zpool status report that my pool could be upgraded from v13 to v14. I did this, via zfs upgrade -a. Today, when attempting to fire up this FreeBSD guest in VirtualBox I get this on the console: = ZFS: unsupported ZFS version 14 (should be 13) No ZFS pools located, can't boot _ = and the boot halts at that point. I don't see the boot menu I normally see that lists the opportunity to boot single-user; disable ACPI; and so on. Has anyone else experienced this? Is this a mismatch between gptzfsboot and my current pool version? (Gptzfsboot includes the message I'm seeing.) Am I supposed to rebuild and replace gptzfsboot every time the pool version is updated? (There was no advisory in /usr/src/UPDATING concerning this, nor do I remember seeing it elsewhere.) Now I have to figure out how to dig out from this. Well, I guess that's what test installations are for... :-) Cheers, Paul.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: make world fails in usr.sbin/config?
On May 24, 2010, at 8:29 AM, Jeremy Chadwick wrote: For added posterity, it looks like usr.sbin/config has been mostly untouched for quite some time, sans mkoptions.c and mkmakefile.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/config/ Having said that, there is this entry in /usr/src/UPDATING dating from early May: 20100502: The config(8) command has been updated to maintain compatibility with config files from 8.0-RELEASE. You will need a new version of config to build kernels (this version can be used from 8.0-RELEASE forward). The buildworld target will generate it, so following the instructions in this file for updating will work glitch-free. Merely doing a make buildkernel without first doing a make buildworld (or kernel-toolchain), or attempting to build a kernel using traidtional methods will generate a config version warning, indicating you should update. Stefan's kernel looks to have last been built on 20th February 2010. It isn't explicit in the first posting of this thread how Stefan is doing his build, so there is a possibility that he's being affected by the above UPDATING entry. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: make world fails in usr.sbin/config?
On May 24, 2010, at 9:27 AM, Stefan Bethke wrote: I've just moved from a root on UFS plus data on ZFS setup, to root on ZFS; that's the only real difference I can think of. Although I don't see how that would affect building world, especially since I've had src and obj on ZFS before. FWIW, I successfully completed buildworld + buildkernel for 8-STABLE on a root-on-ZFS system yesterday. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Make ZFS auto-destroy snapshots when the out of space?
On May 30, 2010, at 10:35 PM, David Magda wrote: An event framework would certainly be helpful in a general sense (Linux has event(3) AFAIK), and that could certainly be useful for purging snapshots during resource constrained situations. But even if we don't have it, I doubt a fork(2) from cron(8) and a statfs(2) would be onerous on a system. :) Devd already receives several ZFS-based events (failed vdev, I/O error, checksum mismatch, etc.), so perhaps it would be useful to add another, e.g., space which is set to be triggered when a pool attains a certain percentage full. This could default to 100%, but be capable of being set lower by an associated kernel sysctl. You could then have any auto-pruning/snapshot management script triggered from devd. (You'd probably also have to figure out some kind of throttling mechanism for this devd event, too.) Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Problems with ATA_CAM support in RELENG_8
I am running FreeBSD/amd64 RELENG_8 on a Dell Optiplex 745. The hard drive in the system is SATA and I have Normal, not Legacy SATA support enabled in the BIOS. (BIOS is V2.6.4.) I am assuming this will enable native AHCI mode for the drive. I built a kernel with ATA_CAM support, but for some reason the SATA drive is probing at slow, UDMA2, speeds: ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ST3160812AS 3.ADJ ATA-7 SATA 2.x device ada0: 33.300MB/s transfers (UDMA2, PIO 8192bytes) ada0: 152587MB (31250 512 byte sectors: 16H 63S/T 16383C) When I run camcontrol identify on the drive, it states the drive is capable of UDMA6 speeds: backup# camcontrol identify ada0 pass0: ST3160812AS 3.ADJ ATA-7 SATA 2.x device pass0: 33.300MB/s transfers (UDMA2, PIO 8192bytes) protocol ATA/ATAPI-7 SATA 2.x device model ST3160812AS firmware revision 3.ADJ serial number 5LS8PPDD cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 31250 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Feature Support EnableValue Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 65278/0xFEFE automatic acoustic management yes yes 254/0xFE208/0xD0 media status notification no no power-up in Standbyno no write-read-verify no no 0/0x0 unload no no free-fall no no data set management (TRIM) no So, why the slower speed? Also, camcontrol identify states the drive supports NCQ with up to 32 tags supported, yet camcontrol tags ada0 reports only 1 device opening, not 32 as I would expect: backup# camcontrol tags ada0 (pass0:ata2:0:0:0): device openings: 1 To enable ATA_CAM AHCI support, I included this in my kernel config file: # ATA and ATAPI devices options ATA_CAM device ahci device atacore device atapci options ATA_STATIC_ID # Static device numbering Is this the correct way to enable ATA_CAM AHCI support? I tried initially including just options ATA_CAM and device ahci but the resultant kernel would not probe my disk drive as ada0. Does my problem lie with my kernel config or is the Dell Optiplex 745 BIOS brain dead when it comes to AHCI native support? The only option it appears to have in the BIOS is Normal and Legacy when it comes to the SATA controller mode. I've attached my full kernel config and dmesg at the end of this e-mail. Cheers, Paul. Kernel config: # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.13 2010/05/02 06:24:17 imp Exp $ cpu HAMMER ident VPN # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env GENERIC.env #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL #
Re: Problems with ATA_CAM support in RELENG_8
On Jun 30, 2010, at 1:38 PM, Alexander Motin wrote: To enable ATA_CAM AHCI support, I included this in my kernel config file: # ATA and ATAPI devices options ATA_CAM device ahci device atacore device atapci options ATA_STATIC_ID # Static device numbering Is this the correct way to enable ATA_CAM AHCI support? I tried initially including just options ATA_CAM and device ahci but the resultant kernel would not probe my disk drive as ada0. Your controller seems to not report AHCI support. In such case legacy mode driver attaches to it. But as soon as you have no `device ataintel` line, only generic driver was there, limited by UDMA2 mode. PS: ATA_STATIC_ID is useless when ATA_CAM option enabled. Thank you (and Jeremy Chadwick) for the help and information. The kernel configuration options I used above were taken from a VirtualBox FreeBSD/amd64 install I have that I converted over to ATA_CAM when the code first went into RELENG_8 and it wasn't exactly clear at the time what options were absolutely required. (I'm not even sure that options ATA_CAM is needed any more, given device ahci implies it.) Does my problem lie with my kernel config or is the Dell Optiplex 745 BIOS brain dead when it comes to AHCI native support? The only option it appears to have in the BIOS is Normal and Legacy when it comes to the SATA controller mode. Your controller is not identified as AHCI: atapci0: Intel ATA controller port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfecf,0xecc0-0xeccf irq 20 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] atapci1: Intel ATA controller port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecd0-0xecdf irq 20 at device 31.5 on pci0 atapci1: [ITHREAD] ata4: ATA channel 0 on atapci1 ata4: [ITHREAD] ata5: ATA channel 1 on atapci1 ata5: [ITHREAD] You may check `pciconf -lvcb` output. For ICH8 with AHCI you should see there something like: ah...@pci0:0:31:2: class=0x010601 card=0xa00c14ff chip=0x28298086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile SATA AHCI Controller' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xe880, size 8, enabled bar [14] = type I/O Port, range 32, base 0xe800, size 4, enabled bar [18] = type I/O Port, range 32, base 0xe480, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xe400, size 4, enabled bar [20] = type I/O Port, range 32, base 0xe080, size 32, enabled bar [24] = type Memory, range 32, base 0xfeaff800, size 2048, enabled cap 05[80] = MSI supports 4 messages enabled with 4 messages cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair Pay attention to subclass = SATA. Then that's where my problem lies: atap...@pci0:0:31:2:class=0x01018f card=0x01da1028 chip=0x28208086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'SATA IDE Controller:4 port (82801HB/HR/HH/HO)' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xfe00, size 8, enabled bar [14] = type I/O Port, range 32, base 0xfe10, size 4, enabled bar [18] = type I/O Port, range 32, base 0xfe20, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xfe30, size 4, enabled bar [20] = type I/O Port, range 32, base 0xfec0, size 16, enabled bar [24] = type I/O Port, range 32, base 0xecc0, size 16, enabled cap 01[70] = powerspec 3 supports D0 D3 current D0 atap...@pci0:0:31:5:class=0x010185 card=0x01da1028 chip=0x28258086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) 2 port SATA Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xfe40, size 8, enabled bar [14] = type I/O Port, range 32, base 0xfe50, size 4, enabled bar [18] = type I/O Port, range 32, base 0xfe60, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xfe70, size 4, enabled bar [20] = type I/O Port, range 32, base 0xfed0, size 16, enabled bar [24] = type I/O Port, range 32, base 0xecd0, size 16, enabled cap 01[70] = powerspec 3 supports D0 D3 current D0 I thought ICH8 supported AHCI, but maybe it's only ICH8R that does? I'm assuming that subclass = ATA means the controller can't operate in AHCI mode. The BIOS setting is also confusing. It has two options, Normal and Legacy. Normal mode says, The hard drive controller is configured for native mode. This mode provides the highest drive performance and most flexibility. I guess I misinterpreted native mode to be AHCI mode. Thanks again for the help and for clearing things up. Cheers,
Re: Problems with ATA_CAM support in RELENG_8
On Jun 30, 2010, at 5:18 PM, Alexander Motin wrote: Paul Mather wrote: PS: ATA_STATIC_ID is useless when ATA_CAM option enabled. Thank you (and Jeremy Chadwick) for the help and information. The kernel configuration options I used above were taken from a VirtualBox FreeBSD/amd64 install I have that I converted over to ATA_CAM when the code first went into RELENG_8 and it wasn't exactly clear at the time what options were absolutely required. (I'm not even sure that options ATA_CAM is needed any more, given device ahci implies it.) `options ATA_CAM` enables CAM wrapper for legacy drivers, which gave you adaX devices instead of adX. It doesn't give major benefits, just unifies behavior. So, does that mean if you omit options ATA_CAM and have device ahci you will get adX devices, not adaX devices? In other words, if you have device ahci (or device siis or device mvs) will you will always get adaX devices, whether or not you have options ATA_CAM in your kernel config file? Does options ATA_CAM work with device ata or the modular ATA subsystem? Is that the intended use of options ATA_CAM: to provide adaX devices and a CAM interface for accessing ATA devices? Cheers, Paul.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.x grudges
On Jul 7, 2010, at 5:39 PM, Garrett Cooper wrote:
On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
07.07.2010 14:59, Jeremy Chadwick ???(??):
FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
thus not an option) -- the kernel-config files, that worked with
7.x, break without this option in them (in addition to all the
nuisance, that's documented in UPDATING -- which, somehow, makes
the breakage acceptable). config(8) would not warn about this, but
kernel build fails.
We don't use this option (meaning it's removed from our kernels). It's
definitely not required. All it does is ensure your kernel can
comprehend executables/binaries built on 7.x.
Attached is the kernel config-file (i386), that worked fine under 7.x. The
kernel-compile will break (some *freebsd7* structs undefined), without the
COMPAT_FREEBSD7 option. Try it for yourself...
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
Those require COMPAT_FREEBSD7.
I have an FreeBSD/amd64 8.1-PRERELEASE system with all COMPAT_FREEBSDx options
except COMPAT_FREEBSD32 commented out in my kernel config file and it builds
fine. So, unless I am misunderstanding you, I don't think options
SYSV{SHM,MSG,SEM} requires COMPAT_FREEBSD7.
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Using GTP and glabel for ZFS arrays
On Jul 21, 2010, at 11:05 PM, Dan Langille wrote: I hope my terminology is correct I have a ZFS array which uses raw devices. I'd rather it use glabel and supply the GEOM devices to ZFS instead. In addition, I'll also partition the HDD to avoid using the entire HDD: leave a little bit of space at the start and end. Why use glabel? * So ZFS can find and use the correct HDD should the HDD device ever get renumbered for whatever reason. e.g. /dev/da0 becomes /dev/da6 when you move it to another controller. I have created ZFS pools using this strategy. However, about a year ago I still fell foul of the drive shuffling problem, when GEOM labels appeared not to be detected properly: http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003654.html This was using RELENG_7, and the problem was provoked by external USB drives. The same issue might not occur with FreeBSD 8.x, but I thought I'd point out my experience as a possible warning about using glabel. Nowadays, I use GPT labels (gpart ... -l somelabel, referenced via /dev/gpt/somelabel). Why use partitions? * Primarily: two HDD of a given size, say 2TB, do not always provide the same amount of available space. If you use a slightly smaller partition instead of the entire physical HDD, you're much more likely to have a happier experience when it comes time to replace an HDD. * There seems to be a consensus amongst some that leaving the start and and of your HDD empty. Give the rest to ZFS. You should also try and accommodate 4K sector size drives these days. Apparently, the performance boosts from hitting 4K-aligned sectors can be very good. Cheers, Paul.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote: I have fixed the missing bits in r212688. Thanks for the notice. Dňa 15. 9. 2010 21:12, Xin LI wrote / napísal(a): On 2010/09/15 11:30, Mike Tancsa wrote: At 02:07 PM 9/15/2010, Pascal Stumpf wrote: First of all, a great thanks to mm@ and pjd@ for the excellent work on ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago. [...] here too. RELENG_8 AMD64. The tinderboxes havent hit that branch yet (http://tinderbox.freebsd.org/http://tinderbox.freebsd.org/), so it will be a few hrs before they get to test RELENG_8 [...] -lsbuf -lm -lnvpair -luutil -lutil /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent' *** Error code 1 Sorry for that, it seems to be caused by a partial merge (cddl/compat/opensolaris/misc/mnttab.c). mm@ is going to fix that ASAP. Cheers, I am getting a build failure on 8.1-STABLE: = [[...]] cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/p1003_1b.c cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/posix4_mib.c cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/sched_ule.c cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function 'sched_switch': /usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 'sched_pickcpu' /usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 'sched_pickcpu' *** Error code 1 Stop in /usr/obj/usr/src/sys/BACKUP. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. = Unfortunately (for me, I guess), GENERIC will build successfully on this system. It's only my custom kernel config file that is failing make buildkernel. The custom kernel config is GENERIC with various inapplicable drivers removed, plus some non-GENERIC things added in (such as ALTQ support options). I am building via the standard make buildworld followed by make buildkernel method. Can anyone spot anything obviously awry? I've included my config file at the end. Cheers, Paul. # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.19 2009/07/15 08:32:19 ed Exp $ cpu I586_CPU cpu I686_CPU ident BACKUP # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols #optionsSCHED_4BSD # 4BSD scheduler options SCHED_ULE # ULE scheduler options
Re: MFC of ZFSv15
On Sep 17, 2010, at 8:37 AM, Paul Mather wrote: On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote: I have fixed the missing bits in r212688. Thanks for the notice. Dňa 15. 9. 2010 21:12, Xin LI wrote / napísal(a): On 2010/09/15 11:30, Mike Tancsa wrote: At 02:07 PM 9/15/2010, Pascal Stumpf wrote: First of all, a great thanks to mm@ and pjd@ for the excellent work on ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago. [...] here too. RELENG_8 AMD64. The tinderboxes havent hit that branch yet (http://tinderbox.freebsd.org/http://tinderbox.freebsd.org/), so it will be a few hrs before they get to test RELENG_8 [...] -lsbuf -lm -lnvpair -luutil -lutil /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent' *** Error code 1 Sorry for that, it seems to be caused by a partial merge (cddl/compat/opensolaris/misc/mnttab.c). mm@ is going to fix that ASAP. Cheers, I am getting a build failure on 8.1-STABLE: = [[...]] cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/p1003_1b.c cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/posix4_mib.c cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/sched_ule.c cc1: warnings being treated as errors /usr/src/sys/kern/sched_ule.c: In function 'sched_switch': /usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 'sched_pickcpu' /usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 'sched_pickcpu' *** Error code 1 Stop in /usr/obj/usr/src/sys/BACKUP. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. = Unfortunately (for me, I guess), GENERIC will build successfully on this system. It's only my custom kernel config file that is failing make buildkernel. The custom kernel config is GENERIC with various inapplicable drivers removed, plus some non-GENERIC things added in (such as ALTQ support options). I am building via the standard make buildworld followed by make buildkernel method. Can anyone spot anything obviously awry? I've included my config file at the end. Just to follow up myself, here: I added options SMP to my custom kernel config file and that allowed me successfully to finish make buildkernel ... without error. So, is options SMP mandatory now on FreeBSD/i386 (even on uniprocessor systems), and, if so, shouldn't it be included in DEFAULTS? Cheers, Paul.
Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
On Sep 30, 2010, at 3:56 AM, Jeremy Chadwick wrote:
The diff is pretty obvious/simple (2 line change), so the other
databases/mysqlXX-server ports can be upgraded in the same manner.
--- files/mysql-server.sh.in.orig 2010-03-27 03:24:53.0 -0700
+++ files/mysql-server.sh.in 2010-09-30 00:45:38.0 -0700
@@ -35,8 +35,8 @@
mysql_user=mysql
mysql_limits_args=-e -U ${mysql_user}
pidfile=${mysql_dbdir}/`/bin/hostname`.pid
-command=%%PREFIX%%/bin/mysqld_safe
-command_args=--defaults-extra-file=${mysql_dbdir}/my.cnf
--user=${mysql_user} --datadir=${mysql_dbdir} --pid-file=${pidfile}
${mysql_args} /dev/null 21
+command=/usr/sbin/daemon
+command_args=-c -f /usr/local/bin/mysqld_safe
--defaults-extra-file=${mysql_dbdir}/my.cnf --user=${mysql_user}
--datadir=${mysql_dbdir} --pid-file=${pidfile} ${mysql_args}
Shouldn't this be -c -f %%PREFIX%%/bin/mysqld_safe ... rather than
hard-coding /usr/local?
procname=%%PREFIX%%/libexec/mysqld
start_precmd=${name}_prestart
start_postcmd=${name}_poststart
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Cheers,
Paul.___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Support for Areca ARC-1300-4X on 8-STABLE?
Does anyone know whether the Areca ARC-1300-4X external SAS HBA is currently supported under FreeBSD/amd64 8-STABLE? I just fired up a system that has one of these cards that is running 8.0-RELEASE and the HBA is not being detected properly by FreeBSD. (It is being misidentified by the arcmsr driver.) I'm hoping that once I upgrade from 8.0-RELEASE to a contemporary 8-STABLE that it'll be supported. I found a posting on the Web that indicated a driver would be available in the first quarter of 2010 (http://lists.freebsd.org/pipermail/freebsd-hardware/2009-December/006115.html). I'm really hoping I can use this card, though I'm somewhat discouraged by the fact that the Areca Web site lists only drivers for Windows, Linux, and Mac OS X for this particular model. :-( Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for Areca ARC-1300-4X on 8-STABLE?
On Nov 24, 2010, at 12:32 AM, Jeremy Chadwick wrote: On Tue, Nov 23, 2010 at 09:41:43PM -0500, Paul Mather wrote: Does anyone know whether the Areca ARC-1300-4X external SAS HBA is currently supported under FreeBSD/amd64 8-STABLE? I just fired up a system that has one of these cards that is running 8.0-RELEASE and the HBA is not being detected properly by FreeBSD. (It is being misidentified by the arcmsr driver.) I'm hoping that once I upgrade from 8.0-RELEASE to a contemporary 8-STABLE that it'll be supported. I found a posting on the Web that indicated a driver would be available in the first quarter of 2010 (http://lists.freebsd.org/pipermail/freebsd-hardware/2009-December/006115.html). I'm really hoping I can use this card, though I'm somewhat discouraged by the fact that the Areca Web site lists only drivers for Windows, Linux, and Mac OS X for this particular model. :-( Have you contacted Areca about this? Their Technical Support folks would be able to tell you why this is, and if there is work being done to provide a driver for FreeBSD. A hardware vendor that is known to support FreeBSD is more authoritative about their drivers than the FreeBSD Project. :-) I'll concede the latter point, but I'd also hope that such a vendor would be contributing its drivers directly into the source tree rather than having a separate set of patches or downloads for end-users to fiddle about with. I prefer my updates to come via csup. :-) The only Areca port I can see is the one for the CLI for their RAID cards (sysutils/areca-cli). I have contacted their support e-mail address asking what the situation is, from the horse's mouth, so to speak. I hope the news is good. Also, please see this thread (which is very recent): http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/059985.html Thanks for the link! I'm not sure whether Fixed arcmsr driver prevent arcsas support for Areca SAS HBA ARC13x0 in the Bug fixes list is good news or bad news for me. It suggests that the arcmsr driver has been fixed to prevent it attaching to the ARC-13X0 cards, implying that it is not supported. This entry about OS support on the Areca official page for the ARC-1300 product (http://www.areca.us/products/sasnoneraid.htm) is also not inspiring: BSD/FreeBSD (will be available with 6Gb/s Host Adapter). Does this mean only their 6 Gb/s cards will be supported under FreeBSD, or that support for the 3 Gb/s cards will appear alongside the 6 Gb/s cards, whenever they are released? I have to say all this has left a sour taste in my mouth. I chose Areca because of their solid FreeBSD support. :-( Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for Areca ARC-1300-4X on 8-STABLE?
On Nov 24, 2010, at 7:06 PM, Xin LI wrote: On Wed, Nov 24, 2010 at 7:01 AM, Paul Mather p...@gromit.dlib.vt.edu wrote: Thanks for the link! I'm not sure whether Fixed arcmsr driver prevent arcsas support for Areca SAS HBA ARC13x0 in the Bug fixes list is good news or bad news for me. It suggests that the arcmsr driver has been fixed to prevent it attaching to the ARC-13X0 cards, implying that it is not supported. This entry about OS support on the Areca official page for the ARC-1300 product (http://www.areca.us/products/sasnoneraid.htm) is also not inspiring: BSD/FreeBSD (will be available with 6Gb/s Host Adapter). Does this mean only their 6 Gb/s cards will be supported under FreeBSD, or that support for the 3 Gb/s cards will appear alongside the 6 Gb/s cards, whenever they are released? The 6Gb/s cards are not released yet. The updated driver resolved a conflict with the newer ARC13x0 cards, without it one will have to update arcmsr(4) before installing the SAS card driver. So, to clarify, does this mean the 3 Gb/s ARC-1300 cards are not currently supported under 8-STABLE? Or, are they supported by a different driver to arcmsr (if so, which one?), but arcmsr must be updated so it doesn't probe and claim the card instead? Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-10:10.openssl
On Dec 2, 2010, at 4:54 AM, Gareth de Vaux wrote: On Thu 2010-12-02 (00:05), jhell wrote: Try that with a ( make includes ) in that same directory and if it works then the advisory will have to be revised. Ah awesome, that works thanx. (I don't see why though, since it was only half complaining about a missing definition, even when I manually included dtls1.h. Also, I tried on a different system and the advisory instructions worked as is). The advisory instructions worked as-is for me on a 7.3-RELEASE-p3 system but failed on my 8.1-STABLE systems. However, a make buildworld followed by a make install in the appropriate directory work successfully on the 8.1-STABLE machines. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Supported SAS controllers (single port)
On Dec 7, 2010, at 8:36 PM, Daniel O'Connor wrote: On 08/12/2010, at 3:51, Mike Andrews wrote: On 12/7/2010 8:00 AM, Daniel O'Connor wrote: Does anyone have a recommendation for one? I am looking to connect a LTO tape drive to a FreeBSD 7 or 8 box and I've only ever used Adaptec 19160 and similar cards and LVDS SCSI. Our supplier has an LSI SAS3081E-R which is not outrageously expensive, has anyone used one? Yes, I've got one, it works fine :) Ahh, good news, thanks :) Have you used it with a tape drive? You may want to flash the non-raid firmware from LSI onto it. OK thanks. I just realised it doesn't have any external connectors so I'll have to find another candidate. However I do see the LSI spec sheet for it lists the chip which is listed in mpt(4) so I should be able to find something. I have a LSI SAS3801E (note lack of -R suffix) in a FreeBSD 8 box that is hooked up to a Quantum SuperLoader LTO-4 tape drive. It's not in production yet, and I haven't done extensive testing, but so far it probes the tape drive and autochanger correctly. The LSI SAS3801E itself attaches as a mpt device. It has two external connectors but no internal ones. I had intended to use an Areca ARC-1300-4X external SAS controller to drive this tape unit but, alas, I discovered that there is as yet no FreeBSD driver for that card. :-( Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: umass: AutoSense failed
On Dec 9, 2010, at 5:11 PM, Jeremy Chadwick wrote: On Thu, Dec 09, 2010 at 10:35:56PM +0100, Harald Weis wrote: What could be the reason for the following failure? ugen2.2: Sony at usbus2 umass0: Sony Sony DSC, class 0/0, rev 1.10/4.50, addr 2 on usbus2 umass0: RBC over CBI; quirks = 0x umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): AutoSense failed This occurs on 4 different boxes, all on 8.1-RELEASE. Never happened on previous releases. The camera works on an Ubuntu system. Please try a 8.1-STABLE or 8.2-PRERELEASE snapshot (you can boot the livefs CD or USB memstick image to test) and see if things are different (improved) there. ftp://ftp4.freebsd.org/pub/FreeBSD/snapshots/201011/ 8.x uses a newer/different USB stack than 7.x. I get something similar to this happening on 8.2-PRERELEASE. In my case, it's not during boot probing or device attachment. Instead, it happens occasionally after boot. The devices concerned are Maxtor OneTouch external USB hard drives. Every now and then, I will get something akin to the following crop up in the console log: (da1:umass-sim1:1:0:0): AutoSense failed I have three of these Maxtor OneTouch drives attached to the system as part of a ZFS pool. When I get an AutoSense failed message, it is usually accompanied by the ZFS pool being marked as faulted. The Maxtor OneTouch drives are wont to spin down and go into a deep sleep after a period of inactivity and appear very slow to wake up again when I/O occurs. I have always assumed that the AutoSense failed is associated with this---that there is some kind of timeout in the FreeBSD stack that this device is exceeding. In fact, sometimes the devices fail to probe properly during boot when they are asleep. This is what the OneTouch normally probes as: da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Maxtor OneTouch 0121 Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: OS X Lion time machine = (afpd|iSCSI) = ZFS question
On Jul 25, 2011, at 2:51 PM, Bakul Shah wrote: On Mon, 25 Jul 2011 14:15:06 EDT Gary Palmer gpal...@freebsd.org wrote: On Thu, Jul 21, 2011 at 02:56:17PM -0700, Bakul Shah wrote: I am in no hurry to upgrade my MBP to OS X Lion but given Lion time machine and netatalk issues, I got wondering if iSCSI on FreeBSD is stable enough for time machine use. How much duct tape and baling wire are needed to make it work?! Just a word of caution - I read somewhere that using iSCSI for Time Machine means that you cannot use TM during an OS reinstall to restore your files from the Time Machine archive as iSCSI isn't available at that point. It seems you have to use a locally attached disk or AFP for the support to be there during reinstall. Not sure if thats still the case in Lion or not, I would tend to suspect they still don't consider iSCSI a top tier transport. I read you can create a boot dvd from one of the files in the upgrade. The problem is that the Boot DVD or Recovery Partition does not have an iSCSI initiator. In fact, the Mac does not ship with an iSCSI initiator, and the common solution to obtaining one is to install the free globalSAN iSCSI Initiator for OS X. Without an installed iSCSI initiator, you won't be able to mount the LUNs upon which is located the Time Machine volume from which you are trying to restore files. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: usbus is seen as network interface - Fwd: sjakie.klop.ws daily run output
On Sep 20, 2011, at 6:11 AM, Ronald Klop wrote: Hello, Why is usbus seen as a network interface since some time? I'm running 9-CURRENT on amd64. I've been wondering this, too. It also started happening sometime in the lifetime of 8-STABLE some months ago, with netstat -i showing usbus network interfaces despite no ethernet NIC being attached. It appears that ifconfig is smart enough to omit these in output, as was netstat in former times on RELENG_8 (and still is on RELENG_7), so why include them now? Just wondering... Cheers, Paul.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fsck_ufs out of swapspace
On Dec 17, 2011, at 3:36 PM, Michiel Boland wrote: FreeBSD 9.0-PRERELEASE locked up while into some heavy I/O and failed to shut down properly, so I had to power-cycle. After it came back up it said Starting file system checks: ** SU+J Recovering /dev/ada0a ** Reading 33554432 byte journal from inode 4. swap_pager: out of swap space swap_pager_getswapspace(16): failed pid 67 (fsck_ufs), uid 0, was killed: out of swap space fsck: /dev/ada0a: Killed: 9 Script /etc/rc.d/fsck running Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! The only way to continue was to do a full fsck (with no journal) This is a Sun Blade 100 (sparc64) with 768M of RAM. So the fsck is taking up all of this? That can't be right. What can I do to troubleshoot this further? FWIW, I had this happen to me several weeks ago on FreeBSD/powerpc64 9-CURRENT. I had to get the machine up and running so I simply abandoned use of SU+J and went back to using just UFS+SU. (Not very helpful, I know, but there you go.) I figure it is likely to be some kind of endianness problem in the SU+J code, given the lack of complaints on FreeBSD/i386 and FreeBSD/amd64. Cheers, Paul. PS: The system I was using is an Apple Xserve G5 with 4 GB of RAM and 5 GB of swap space. As you say, surely fsck can't be using that much memory...___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ZFS + nullfs + Linuxulator = panic?
I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last built 2012-02-08). It will panic during the daily periodic scripts that run at 3am. Here is the most recent panic message: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x8069d266 stack pointer = 0x28:0xff8094b90390 frame pointer = 0x28:0xff8094b903a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 72566 (ps) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: #0 0x8062cf8e at kdb_backtrace+0x5e #1 0x805facd3 at panic+0x183 #2 0x808e6c20 at trap_fatal+0x290 #3 0x808e715a at trap+0x10a #4 0x808cec64 at calltrap+0x8 #5 0x805ee034 at fill_kinfo_thread+0x54 #6 0x805eee76 at fill_kinfo_proc+0x586 #7 0x805f22b8 at sysctl_out_proc+0x48 #8 0x805f26c8 at sysctl_kern_proc+0x278 #9 0x8060473f at sysctl_root+0x14f #10 0x80604a2a at userland_sysctl+0x14a #11 0x80604f1a at __sysctl+0xaa #12 0x808e62d4 at amd64_syscall+0x1f4 #13 0x808cef5c at Xfast_syscall+0xfc Uptime: 3d19h6m0s Dumping 1308 out of 2028 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... The reason for the subject line is that I have another RELENG_8 system that uses ZFS + nullfs but doesn't panic, leading me to believe that ZFS + nullfs is not the problem. I am wondering if it is the combination of the three that is deadly, here. Both RELENG_8 systems are root-on-ZFS installs. Each night there is a separate backup script that runs and completes before the regular periodic daily run. This script takes a recursive snapshot of the ZFS pool and then mounts these snapshots via mount_nullfs to provide a coherent view of the filesystem under /backup. The only difference between the two RELENG_8 systems is that one uses rsync to back up /backup to another machine and the other uses the Linux Tivoli TSM client to back up /backup to a TSM server. After the backup is completed, a script runs that unmounts the nullfs file systems and then destroys the ZFS snapshot. The first (rsync backup) RELENG_8 system does not panic. It has been running the ZFS + nullfs rsync backup job without incident for weeks now. The second (Tivoli TSM) RELENG_8 will reliably panic when the subsequent periodic daily job runs. (It is using the 32-bit TSM 6.2.4 Linux client running dsmc schedule via the linux_base-f10-10_4 package.) The actual ZFS + nullfs Tivoli TSM backup job appears to run successfully, making me wonder if perhaps it has some memory leak or other subtle corruption that sets up the ensuing panic when the periodic daily job later gives the system a workout. If I can provide more information about the panic, please let me know. Despite the message about dumping in the panic output above, when the system reboots I get a No core dumps found message during boot. (I have dumpdev=AUTO set in /etc/rc.conf.) My swap device is on separate partitions but is mirrored using geom_mirror as /dev/mirror/swap. Do crash dumps to gmirror devices work on RELENG_8? Does anyone have any idea what is to blame for the panic, or how I can fix or work around it? Cheers, Paul. PS: The uptime of three days in the panic message is because I disabled the Tivoli TSM backup job on Friday so it would not run over the weekend. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS + nullfs + Linuxulator = panic?
On Feb 14, 2012, at 7:23 PM, Jeremy Chadwick wrote: On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last built 2012-02-08). It will panic during the daily periodic scripts that run at 3am. Here is the most recent panic message: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x8069d266 stack pointer = 0x28:0xff8094b90390 frame pointer = 0x28:0xff8094b903a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 72566 (ps) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: #0 0x8062cf8e at kdb_backtrace+0x5e #1 0x805facd3 at panic+0x183 #2 0x808e6c20 at trap_fatal+0x290 #3 0x808e715a at trap+0x10a #4 0x808cec64 at calltrap+0x8 #5 0x805ee034 at fill_kinfo_thread+0x54 #6 0x805eee76 at fill_kinfo_proc+0x586 #7 0x805f22b8 at sysctl_out_proc+0x48 #8 0x805f26c8 at sysctl_kern_proc+0x278 #9 0x8060473f at sysctl_root+0x14f #10 0x80604a2a at userland_sysctl+0x14a #11 0x80604f1a at __sysctl+0xaa #12 0x808e62d4 at amd64_syscall+0x1f4 #13 0x808cef5c at Xfast_syscall+0xfc Uptime: 3d19h6m0s Dumping 1308 out of 2028 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... The reason for the subject line is that I have another RELENG_8 system that uses ZFS + nullfs but doesn't panic, leading me to believe that ZFS + nullfs is not the problem. I am wondering if it is the combination of the three that is deadly, here. Both RELENG_8 systems are root-on-ZFS installs. Each night there is a separate backup script that runs and completes before the regular periodic daily run. This script takes a recursive snapshot of the ZFS pool and then mounts these snapshots via mount_nullfs to provide a coherent view of the filesystem under /backup. The only difference between the two RELENG_8 systems is that one uses rsync to back up /backup to another machine and the other uses the Linux Tivoli TSM client to back up /backup to a TSM server. After the backup is completed, a script runs that unmounts the nullfs file systems and then destroys the ZFS snapshot. The first (rsync backup) RELENG_8 system does not panic. It has been running the ZFS + nullfs rsync backup job without incident for weeks now. The second (Tivoli TSM) RELENG_8 will reliably panic when the subsequent periodic daily job runs. (It is using the 32-bit TSM 6.2.4 Linux client running dsmc schedule via the linux_base-f10-10_4 package.) The actual ZFS + nullfs Tivoli TSM backup job appears to run successfully, making me wonder if perhaps it has some memory leak or other subtle corruption that sets up the ensuing panic when the periodic daily job later gives the system a workout. If I can provide more information about the panic, please let me know. Despite the message about dumping in the panic output above, when the system reboots I get a No core dumps found message during boot. (I have dumpdev=AUTO set in /etc/rc.conf.) My swap device is on separate partitions but is mirrored using geom_mirror as /dev/mirror/swap. Do crash dumps to gmirror devices work on RELENG_8? See gmirror(8) man page, section NOTES. Read the full thing. Thanks! I've changed the balance algorithm to prefer, so hopefully I'll get saved crash dumps to examine from now on. Does anyone have any idea what is to blame for the panic, or how I can fix or work around it? Does the panic always happen when ps is run? That's what's shown in the above panic message. Quoting: current process = 72566 (ps) And I'm inclined to think it does, based on the backtrace: #5 0x805ee034 at fill_kinfo_thread+0x54 #6 0x805eee76 at fill_kinfo_proc+0x586 #7 0x805f22b8 at sysctl_out_proc+0x48 #8 0x805f26c8 at sysctl_kern_proc+0x278 But if you can go through the previous panics and confirm that, it would be helpful to developers in tracking down the problem. Just going by memory, at least one other time it did a panic during df. But, most of the time I remember the panic occurring during ps. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS + nullfs + Linuxulator = panic?
On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote: On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last built 2012-02-08). It will panic during the daily periodic scripts that run at 3am. Here is the most recent panic message: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x8069d266 stack pointer = 0x28:0xff8094b90390 frame pointer = 0x28:0xff8094b903a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 72566 (ps) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: #0 0x8062cf8e at kdb_backtrace+0x5e #1 0x805facd3 at panic+0x183 #2 0x808e6c20 at trap_fatal+0x290 #3 0x808e715a at trap+0x10a #4 0x808cec64 at calltrap+0x8 #5 0x805ee034 at fill_kinfo_thread+0x54 #6 0x805eee76 at fill_kinfo_proc+0x586 #7 0x805f22b8 at sysctl_out_proc+0x48 #8 0x805f26c8 at sysctl_kern_proc+0x278 #9 0x8060473f at sysctl_root+0x14f #10 0x80604a2a at userland_sysctl+0x14a #11 0x80604f1a at __sysctl+0xaa #12 0x808e62d4 at amd64_syscall+0x1f4 #13 0x808cef5c at Xfast_syscall+0xfc Please look up the line number for the fill_kinfo_thread+0x54. Is there a way for me to do this from the above information? As I said in the original message, I failed to get a crash dump after reboot (because, it turns out, I hadn't set up my gmirror swap device properly). Alas, with the latest panic, it appears to have hung[1] during the Dumping phase, so it looks like I won't get a saved crash dump this time, either. :-( Speaking of the latest panic, here it is: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x308 fault code = supervisor read data, page not present instruction pointer = 0x20:0x806026ef stack pointer = 0x28:0xff8094acd2d0 frame pointer = 0x28:0xff8094acd350 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 20992 (df) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x8062cf8e at kdb_backtrace+0x5e #1 0x805facd3 at panic+0x183 #2 0x808e6c20 at trap_fatal+0x290 #3 0x808e6f71 at trap_pfault+0x201 #4 0x808e742f at trap+0x3df #5 0x808cec64 at calltrap+0x8 #6 0x80602e1e at _sx_xlock+0x4e #7 0x80f9ca35 at rrw_enter+0xa5 #8 0x80f9ce86 at zfs_statfs+0x46 #9 0x80681258 at __vfs_statfs+0x28 #10 0x81476521 at nullfs_statfs+0x51 #11 0x80681258 at __vfs_statfs+0x28 #12 0x80690b22 at kern_statfs+0x1b2 #13 0x80690c77 at statfs+0x37 #14 0x808e62d4 at amd64_syscall+0x1f4 #15 0x808cef5c at Xfast_syscall+0xfc Cheers, Paul. [1] Not quite hung solid: when I press the power button I get this appearing on the console: acpi0: suspend request ignored (not ready yet) acpi0: request to enter state S5 failed (err 6) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS + nullfs + Linuxulator = panic?
On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel,
last built 2012-02-08). It will panic during the daily periodic scripts
that run at 3am. Here is the most recent panic message:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8069d266
stack pointer = 0x28:0xff8094b90390
frame pointer = 0x28:0xff8094b903a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 72566 (ps)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e715a at trap+0x10a
#4 0x808cec64 at calltrap+0x8
#5 0x805ee034 at fill_kinfo_thread+0x54
#6 0x805eee76 at fill_kinfo_proc+0x586
#7 0x805f22b8 at sysctl_out_proc+0x48
#8 0x805f26c8 at sysctl_kern_proc+0x278
#9 0x8060473f at sysctl_root+0x14f
#10 0x80604a2a at userland_sysctl+0x14a
#11 0x80604f1a at __sysctl+0xaa
#12 0x808e62d4 at amd64_syscall+0x1f4
#13 0x808cef5c at Xfast_syscall+0xfc
Please look up the line number for the fill_kinfo_thread+0x54.
Is there a way for me to do this from the above information? As
I said in the original message, I failed to get a crash dump after
reboot (because, it turns out, I hadn't set up my gmirror swap device
properly). Alas, with the latest panic, it appears to have hung[1]
during the Dumping phase, so it looks like I won't get a saved crash
dump this time, either. :-(
Load the kernel.debug into kgdb, and from there do
list *fill_kinfo_thread+0x54.
gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(kgdb) list *fill_kinfo_thread+0x54
0x805ee034 is in fill_kinfo_thread (/usr/src/sys/kern/kern_proc.c:854).
849 thread_lock(td);
850 if (td-td_wmesg != NULL)
851 strlcpy(kp-ki_wmesg, td-td_wmesg,
sizeof(kp-ki_wmesg));
852 else
853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
855 if (TD_ON_LOCK(td)) {
856 kp-ki_kiflag |= KI_LOCKBLOCK;
857 strlcpy(kp-ki_lockname, td-td_lockname,
858 sizeof(kp-ki_lockname));
(kgdb)
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS + nullfs + Linuxulator = panic?
On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote:
On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel,
last built 2012-02-08). It will panic during the daily periodic scripts
that run at 3am. Here is the most recent panic message:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8069d266
stack pointer = 0x28:0xff8094b90390
frame pointer = 0x28:0xff8094b903a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 72566 (ps)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e715a at trap+0x10a
#4 0x808cec64 at calltrap+0x8
#5 0x805ee034 at fill_kinfo_thread+0x54
#6 0x805eee76 at fill_kinfo_proc+0x586
#7 0x805f22b8 at sysctl_out_proc+0x48
#8 0x805f26c8 at sysctl_kern_proc+0x278
#9 0x8060473f at sysctl_root+0x14f
#10 0x80604a2a at userland_sysctl+0x14a
#11 0x80604f1a at __sysctl+0xaa
#12 0x808e62d4 at amd64_syscall+0x1f4
#13 0x808cef5c at Xfast_syscall+0xfc
Please look up the line number for the fill_kinfo_thread+0x54.
Is there a way for me to do this from the above information? As
I said in the original message, I failed to get a crash dump after
reboot (because, it turns out, I hadn't set up my gmirror swap device
properly). Alas, with the latest panic, it appears to have hung[1]
during the Dumping phase, so it looks like I won't get a saved crash
dump this time, either. :-(
Load the kernel.debug into kgdb, and from there do
list *fill_kinfo_thread+0x54.
gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(kgdb) list *fill_kinfo_thread+0x54
0x805ee034 is in fill_kinfo_thread
(/usr/src/sys/kern/kern_proc.c:854).
849 thread_lock(td);
850 if (td-td_wmesg != NULL)
851 strlcpy(kp-ki_wmesg, td-td_wmesg,
sizeof(kp-ki_wmesg));
852 else
853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
855 if (TD_ON_LOCK(td)) {
856 kp-ki_kiflag |= KI_LOCKBLOCK;
857 strlcpy(kp-ki_lockname, td-td_lockname,
858 sizeof(kp-ki_lockname));
(kgdb)
This is indeed strange. It can only occur if td pointer is damaged.
Please, try to get a core and at least print the content of *td in this case.
Hopefully, I will be able to get a crash dump tonight. I disabled the Tivoli
dsmc schedule job over the weekend, because I don't have ready physical
access to the machine and prefer it not to be down for very extended periods of
time. (As I reported previously, for some reason the system seems to get stuck
saving the crash dump. If this persists, maybe it might be better to get the
system to drop into the debugger on panic instead of hoping forlornly for a
successful crash dump.)
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS + nullfs + Linuxulator = panic?
On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote:
On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel,
last built 2012-02-08). It will panic during the daily periodic scripts
that run at 3am. Here is the most recent panic message:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8069d266
stack pointer = 0x28:0xff8094b90390
frame pointer = 0x28:0xff8094b903a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 72566 (ps)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e715a at trap+0x10a
#4 0x808cec64 at calltrap+0x8
#5 0x805ee034 at fill_kinfo_thread+0x54
#6 0x805eee76 at fill_kinfo_proc+0x586
#7 0x805f22b8 at sysctl_out_proc+0x48
#8 0x805f26c8 at sysctl_kern_proc+0x278
#9 0x8060473f at sysctl_root+0x14f
#10 0x80604a2a at userland_sysctl+0x14a
#11 0x80604f1a at __sysctl+0xaa
#12 0x808e62d4 at amd64_syscall+0x1f4
#13 0x808cef5c at Xfast_syscall+0xfc
Please look up the line number for the fill_kinfo_thread+0x54.
Is there a way for me to do this from the above information? As
I said in the original message, I failed to get a crash dump after
reboot (because, it turns out, I hadn't set up my gmirror swap device
properly). Alas, with the latest panic, it appears to have hung[1]
during the Dumping phase, so it looks like I won't get a saved crash
dump this time, either. :-(
Load the kernel.debug into kgdb, and from there do
list *fill_kinfo_thread+0x54.
gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(kgdb) list *fill_kinfo_thread+0x54
0x805ee034 is in fill_kinfo_thread
(/usr/src/sys/kern/kern_proc.c:854).
849 thread_lock(td);
850 if (td-td_wmesg != NULL)
851 strlcpy(kp-ki_wmesg, td-td_wmesg,
sizeof(kp-ki_wmesg));
852 else
853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
855 if (TD_ON_LOCK(td)) {
856 kp-ki_kiflag |= KI_LOCKBLOCK;
857 strlcpy(kp-ki_lockname, td-td_lockname,
858 sizeof(kp-ki_lockname));
(kgdb)
This is indeed strange. It can only occur if td pointer is damaged.
Please, try to get a core and at least print the content of *td in this case.
Alas, I was unable to obtain a crash dump (or even a panic) last night, but I
have learned more about the circumstances that lead to this panic.
In attempting to find a workaround for this panic (because having nightly
backups instead of panics is a good thing:) I discovered two successful
approaches. In the original situation that causes a reliable panic I have a
daemonised Tivoli dsmc schedule job running. This communicates with the
Tivoli TSM server to determine when it should run its scheduled backup. When
the backup is run, there is defined in a Tivoli client config file (in
/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys) a preschedulecmd and a
postschedulecmd, which are /usr/local/bin/make_zfs_backup_snapshot and
/usr/local/bin/remove_zfs_backup_snapshot respectively. The preschedulecmd
script (run prior to the actual backup) basically makes ZFS snapshots of all
filesets and nullfs-mounts them under /backup. It then creates
/compat/linux/etc/mtab to list these nullfs filesystems as ext2 file systems,
so that the Tivoli backup client can know about them to back them up. The
postschedulecmd (run after the actual backup) unmounts all the nullfs-mounted
filesystems corresponding to the ZFS backup snapshots and then destroys all the
backup snapshots.
The first workaround that doesn't lead to a panic is this: Do not run dsmc
schedule. Instead, via cron, run this simple script:
#!/bin/sh
/usr/local/bin
Re: ZFS + nullfs + Linuxulator = panic?
On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote:
On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel,
last built 2012-02-08). It will panic during the daily periodic scripts
that run at 3am. Here is the most recent panic message:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8069d266
stack pointer = 0x28:0xff8094b90390
frame pointer = 0x28:0xff8094b903a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 72566 (ps)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e715a at trap+0x10a
#4 0x808cec64 at calltrap+0x8
#5 0x805ee034 at fill_kinfo_thread+0x54
#6 0x805eee76 at fill_kinfo_proc+0x586
#7 0x805f22b8 at sysctl_out_proc+0x48
#8 0x805f26c8 at sysctl_kern_proc+0x278
#9 0x8060473f at sysctl_root+0x14f
#10 0x80604a2a at userland_sysctl+0x14a
#11 0x80604f1a at __sysctl+0xaa
#12 0x808e62d4 at amd64_syscall+0x1f4
#13 0x808cef5c at Xfast_syscall+0xfc
Please look up the line number for the fill_kinfo_thread+0x54.
Is there a way for me to do this from the above information? As
I said in the original message, I failed to get a crash dump after
reboot (because, it turns out, I hadn't set up my gmirror swap device
properly). Alas, with the latest panic, it appears to have hung[1]
during the Dumping phase, so it looks like I won't get a saved crash
dump this time, either. :-(
Load the kernel.debug into kgdb, and from there do
list *fill_kinfo_thread+0x54.
gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(kgdb) list *fill_kinfo_thread+0x54
0x805ee034 is in fill_kinfo_thread
(/usr/src/sys/kern/kern_proc.c:854).
849 thread_lock(td);
850 if (td-td_wmesg != NULL)
851 strlcpy(kp-ki_wmesg, td-td_wmesg,
sizeof(kp-ki_wmesg));
852 else
853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
855 if (TD_ON_LOCK(td)) {
856 kp-ki_kiflag |= KI_LOCKBLOCK;
857 strlcpy(kp-ki_lockname, td-td_lockname,
858 sizeof(kp-ki_lockname));
(kgdb)
This is indeed strange. It can only occur if td pointer is damaged.
Please, try to get a core and at least print the content of *td in this case.
Another panic last night, after reverting dsmc schedule scripts to use
/bin/sh (actually /compat/linux/bin/sh):
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x308
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x806026ef
stack pointer = 0x28:0xff8094af02d0
frame pointer = 0x28:0xff8094af0350
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 90872 (df)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e6f71 at trap_pfault+0x201
#4 0x808e742f at trap+0x3df
#5 0x808cec64 at calltrap+0x8
#6 0x80602e1e at _sx_xlock+0x4e
#7 0x80f9ca35 at rrw_enter+0xa5
#8 0x80f9ce86 at zfs_statfs+0x46
#9 0x80681258 at __vfs_statfs+0x28
#10 0x81476521 at nullfs_statfs+0x51
#11 0x80681258 at __vfs_statfs+0x28
#12 0x80690b22 at kern_statfs+0x1b2
#13 0x80690c77 at statfs+0x37
#14 0x808e62d4 at amd64_syscall+0x1f4
#15 0x808cef5c at Xfast_syscall+0xfc
Alas, the system became hung here: there is no further
Re: zfs, 1 gig of RAM and periodic weekly
On Feb 27, 2012, at 11:10 PM, Eugene M. Zheganin wrote: Hi. On 28.02.2012 01:02, Nenhum_de_Nos wrote: regardless of the pool size ? I was planning on making an atom board a file server for my home, and I have two options: soekris net6501 2GB RAM and intel board powered by the 330 atom (says 2GB limited as well). My plans are to use from 4 up to 8 disks, and they should be 2TB at least. As its for home use, some p2p software and mostly music listening and sometimes movie streaming. should 2GB be that bad, that I should drop it and use UFS instead ? I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1. In the same time I have a couple of hosts successfully running zfs on 768 Megs and on 1 Gig of RAM. Both i386. And they aren't affected by the periodic weekly for some reason. And they are used only as fileservers. Basically the same story here: I am using a FreeBSD/i386 system with 768 MB of RAM running RELENG_8 with 4 x 1 TB drives arranged as a RAIDZ1 vdev. It is used as a Bacula server, backing up to the ZFS pool (with ZFS compression enabled). It has been rock solid, and I've had no problems with any of the periodic jobs. Here are the ZFS-related tunings I have in /boot/loader.conf: vm.kmem_size=640M vm.kmem_size_max=640M vfs.zfs.arc_max=512M vfs.zfs.txg.timeout=5 If you are planning on using P2P a lot, I had heard that large files fetched via Bittorrent can become very fragmented under ZFS (due to the COW nature of ZFS and the way Bittorrent fetches files), especially if the pool is very full, and so ZFS might not be the best thing to use if you are also planning on streaming these files, especially on modest hardware. UFS might be preferable in these circumstances. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
On Jun 2, 2012, at 1:31 PM, Chris Rees wrote: On Jun 2, 2012 3:19 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On 06/02/12 14:47, Daniel Kalchev wrote: On 02.06.12 15:32, Erich wrote: I know that the ports tree is a moving target. But it stops moving during the release period. This could be used to give a fall back solution. Or do I see this really too simple? The ports tree is a moving target during release periods still, although there are efforts to make movements smaller. This is why, after a release it suddenly moves more :) Daniel Even IF the ports tree IS a moving target, updating of UPDATING, for instance, follows most times AFTER the critical ports has been changed/updated and folks started updating their ports without realizing that they have shot themselfs into the foot! Not reading UPDATING until there are problems is not the fault of the ports tree; it should be checked every time you update. Of course, many of us forget, but that still doesn't make it anyone else's problem when we do! The point he made was actually not a matter of people not reading UPDATING but that UPDATING is oftentimes not updated until after the disruptive/potentially dangerous change has already hit the ports tree. So, even though people check UPDATING, it won't help them because there will be nothing apropos there until maybe days later when someone has decided an UPDATING entry was merited in retrospect. I'm not sure what the solution is for the end user. I know I get somewhat leery of updating my ports if I see a large number of changes coming via portsnap (like the 4000+ that accompanied the recent libpng upgrade) and there is nothing new in UPDATING (which, happily wasn't the case with the libpng upgrade). Usually, I wait a while for the dust to clear and an UPDATING entry potentially to appear. Maybe the solution is to track the freebsd-ports mailing list get get advanced warning of large changes, but that would mean following another high-volume list. :-( Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD?
On Jun 2, 2012, at 2:56 PM, Chris Nehren wrote: On Sat, Jun 02, 2012 at 14:11:06 -0400 , Paul Mather wrote: I'm not sure what the solution is for the end user. I know I get somewhat leery of updating my ports if I see a large number of changes coming via portsnap (like the 4000+ that accompanied the recent libpng upgrade) and there is nothing new in UPDATING (which, happily wasn't the case with the libpng upgrade). Usually, I wait a while for the dust to clear and an UPDATING entry potentially to appear. If you're concerned about things breaking, don't follow the bleeding edge. This seems to be common sense. Unfortunately, unlike the base operating system, which has -CURRENT, -STABLE, and -RELEASE, there is no well-defined bleeding edge in the case of ports. (Although there is a strong case to be made that it is analogous to -CURRENT.) So, as I said above, you have to fall back on heuristics to determine when it is best to update (with the caveat that waiting too long to update can also be as troublesome as updating too quickly). Certainly, it's far from a case of read UPDATING and you'll be okay, as someone in this thread was seeming to imply. NetBSD's pkgsrc has a nice feature: the quarterly package branches. These follow a quarterly release cycle and receive only security updates. It makes pkgsrc more akin to -CURRENT and -STABLE (or -RELEASE) instead of just -CURRENT. Maybe the solution is to track the freebsd-ports mailing list get get advanced warning of large changes, but that would mean following another high-volume list. :-( And any decent mailer setup can filter those messages for you, leaving only the messages relevant to ports you're interested in. There are also systems like gmane which provide an NNTP feed for mailing lists. Combined with a newsreader with good killfile / scoring features, it shouldn't be hard to keep up. Probably not, but then again you're still relying on it breaking for someone else (and thereby being reported) to avoid it breaking for you. :-) I'm not saying these are insurmountable problems, and, in my experience, most of the time ports updates go smoothly. But, it can present more of a challenge for those that are running an individual FreeBSD system (as their desktop/laptop system, say), and especially if they are using non-default port options in the ports they install, as these don't get the benefit of widespread testing. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PF to Preventing SMTP Brute Force Attacks
On Jun 15, 2012, at 12:55 PM, Shiv. Nath wrote: # START table bruteforce persist block in log quick from bruteforce pass in on $ext_if proto tcp \ from any to $ext_if port $trusted_tcp_ports \ flags S/SA keep state \ (max-src-conn-rate 3/300, overload bruteforce flush global) # END AND CRON: */12 * * * * /sbin/pfctl -t ssh-bruteforce -T expire 604800 /dev/null 21 What is the function expire 604800 are they entries in the table? should it be -t bruteforce or -t ssh-bruteforce It refers to entries in the table specified by the -t option and instructs pf to expire (remove from the table) all entries older than the specified time (in seconds). Basically, the value 604800 will expire entries older than 1 week. For the above pf rules, the cron entry should be -t bruteforce (although in the pf rules you should be using bruteforce). Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
uhci0 excessive interrupts---how can I disable or reset specific USB port?
I am running FreeBSD/amd64 9-STABLE (built Mon Jul 23 10:45:51 EDT 2012) on a Dell Optiplex 760 and, today, noticed I had almost 30% system CPU load in top even when the system was idle. A perusal of vmstat revealed the cause to be excessive interrupts on uhci0, even though nothing was plugged into that USB port: # vmstat -i interrupt total rate irq4: uart0 22 0 irq16: uhci0617002282738 310969 irq23: uhci3 ehci183 0 irq256: hpet0:t0 135818421 68 irq257: hpet0:t1 659301 1120 irq264: em0 29529304 14 irq265: ahci0 11132506 5 Total 619401422375 312178 Because I am only using the front USB ports on that hardware, I thought I would disable the other (rear) USB ports in the BIOS. I rebooted and duly disabled them. However, when FreeBSD booted, it appeared to ignore the BIOS setting: all the USB ports were probed as usual. (The high interrupts had vanished, though that might have been due to FreeBSD correctly shutting down the controllers at shutdown, or just the act of rebooting itself.) I added hint.uhci.0.disabled=1 to /boot/loader.conf (hoping it would disable uhci0), but, again all the USB ports appeared in the boot probes. (However, it *appears* as if uhci0 has been disabled because the irq16: uhci0 line no longer appears in vmstat -i. However, all the same ugen devices appear in /dev.) Is there a way of disabling a specific USB controller that you don't want to use? If so, how? I looked at usbconfig, but that appears to me to be more about controlling devices plugged in to a USB port rather than the port itself. The reset command of usbconfig appears to be about resetting USB devices, not ports. If I can't disable a specific USB port, is there a way to reset it without rebooting? If I ever get another crazy interrupt storm like I noticed today it would be nice to be able to stop it without having to do a reboot. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: virtio for 9.1-R
On Nov 27, 2012, at 3:49 PM, Joe Holden li...@rewt.org.uk wrote: On 27/11/2012 19:25, Sergey Kandaurov wrote: On 27 November 2012 22:12, Joe Holden li...@rewt.org.uk wrote: Hi guys, I can't see virtio in releng/9.1, is there any particular reason why it isn't going to be included given that it works reasonable well (and is optional anyway, so not likely to be detrimental)? virtio appeared in stable/9 a bit after 9.1 cut off, and it is too late now regardless of virtio shape. Anyway you can installed it from ports. Ah I see, doesn't really help all the people who can't install it in KVM and such though unfortunately, seems silly making them wait even longer and having to use Linux :) FWIW, I installed FreeBSD 9-STABLE (pre-virtio in src) in KVM, initially using the emulated devices and then, post-install, installed the emulators/virtio-kmod port and switched over to vtbd/vtnet devices without problem. When virtio appeared in src, I ditched the virtio-kmod port, again, without issues. I found making the transition to virtio devices no harder than the ad - ada device transition. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Upgrade of RELENG_8 ZFS boot pool leads to unbootable system
Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a champ
for ages. After a successful install{kernel,world} and reboot, I noticed the
20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via zfs upgrade
-a. I also upgraded my boot blocks as requested, and as per the ZFS notes
section of /usr/src/UPDATING.
Unfortunately rebooting with the upgraded pool failed. The windmill boot
spinner spins for a tiny amount of time and then stops dead. :-( I don't get
to the boot loader menu at all.
I downloaded a very recent RELENG_8 snapshot
(FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from
pub.allbsd.org and was able to boot successfully from USB using that. I
entered Fixit Mode and tried to write the boot blocks on the memstick image
onto my hard drives but the resultant system still wouldn't boot. The commands
I used (from Fixit Mode) are these:
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
(ad4 and ad6 are my two hard drives.)
If I load zfs before booting the USB memstick then I can see my old pool
listed when I do zfs import. I haven't tried importing the pool because I'm
not sure if that would make the problem worse.
Does anyone have any advice in restoring this system to bootability? I
followed the standard root on ZFS recipe using a two drive mirror when
installing the system initially. Each drive uses GPT with three partitions:
freebsd-boot, freebsd-swap, and freebsd-zfs in that order. Like I said at the
start, all this worked for a long time until just now when I upgraded the pool
to enable feature flags support. :-(
Any help is appreciated.
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system
On Jan 2, 2013, at 2:10 PM, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 02/01/2013 17:49, Paul Mather wrote:
Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a
champ for ages. After a successful install{kernel,world} and reboot, I
noticed the 20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via
zfs upgrade -a. I also upgraded my boot blocks as requested, and as per
the ZFS notes section of /usr/src/UPDATING.
Unfortunately rebooting with the upgraded pool failed. The windmill boot
spinner spins for a tiny amount of time and then stops dead. :-( I don't
get to the boot loader menu at all.
I downloaded a very recent RELENG_8 snapshot
(FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from
pub.allbsd.org and was able to boot successfully from USB using that. I
entered Fixit Mode and tried to write the boot blocks on the memstick image
onto my hard drives but the resultant system still wouldn't boot. The
commands I used (from Fixit Mode) are these:
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
(ad4 and ad6 are my two hard drives.)
If I load zfs before booting the USB memstick then I can see my old pool
listed when I do zfs import. I haven't tried importing the pool because
I'm not sure if that would make the problem worse.
Does anyone have any advice in restoring this system to bootability? I
followed the standard root on ZFS recipe using a two drive mirror when
installing the system initially. Each drive uses GPT with three partitions:
freebsd-boot, freebsd-swap, and freebsd-zfs in that order. Like I said at
the start, all this worked for a long time until just now when I upgraded
the pool to enable feature flags support. :-(
Any help is appreciated.
I think you may be running into problems with zpool.cache. This has
been fixed in current, which now has the ability to find the root zpool
without a valid zpool.cache, but that I suspect is faint comfort for you.
To recover from a toasted zpool.cache, you need to boot from alternate
media and then import your root zpool. It's easiest to do that to a
temporary directory. The important bit is to copy the zpool.cache onto
your actual zroot device:
-- Boot from install media to 'Live CD' and log in as root (no password)
Given the above, does this need to be a -CURRENT Live CD? I've been using the
RELENG_8 snapshot memstick.img mentioned in my original message above.
# kldload zfs -- should load opensolaris.ko automatically
# cd /tmp -- this should be a writable MFS; you'll
need to arrange something similar if
not.
# zpool import -o cachefile=/tmp/zpool.cache -R /tmp/zroot zroot
-- this should create a zpool.cache file
I tried this and it complained about the pool being in use by another
system---the original system that won't boot any more. I expected this, and
added -f to force an import.
# cp zpool.cache /tmp/zroot/boot/zfs/
This part also failed for me. My zroot fileset has a mountpoint property set
to legacy. I had to mount this manually, via mount -t zfs zroot /tmp/zroot
to make the /tmp/zroot/boot/zfs directory accessible.
# zfs umount -a
# shutdown -r
Eject the install media, and the system should boot up from your root spool.
Unfortunately, it didn't boot from the root pool. I get the same thing
happening: the windmill spins for a very short time and then stops dead. I
don't even make it to the BTX Loader output, let alone the boot loader menu
options. :-(
Thank you for the suggestions.
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Solved?: Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system
On Jan 2, 2013, at 2:10 PM, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 02/01/2013 17:49, Paul Mather wrote:
Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a
champ for ages. After a successful install{kernel,world} and reboot, I
noticed the 20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via
zfs upgrade -a. I also upgraded my boot blocks as requested, and as per
the ZFS notes section of /usr/src/UPDATING.
Unfortunately rebooting with the upgraded pool failed. The windmill boot
spinner spins for a tiny amount of time and then stops dead. :-( I don't
get to the boot loader menu at all.
I downloaded a very recent RELENG_8 snapshot
(FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from
pub.allbsd.org and was able to boot successfully from USB using that. I
entered Fixit Mode and tried to write the boot blocks on the memstick image
onto my hard drives but the resultant system still wouldn't boot. The
commands I used (from Fixit Mode) are these:
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
(ad4 and ad6 are my two hard drives.)
If I load zfs before booting the USB memstick then I can see my old pool
listed when I do zfs import. I haven't tried importing the pool because
I'm not sure if that would make the problem worse.
Does anyone have any advice in restoring this system to bootability? I
followed the standard root on ZFS recipe using a two drive mirror when
installing the system initially. Each drive uses GPT with three partitions:
freebsd-boot, freebsd-swap, and freebsd-zfs in that order. Like I said at
the start, all this worked for a long time until just now when I upgraded
the pool to enable feature flags support. :-(
Any help is appreciated.
I think you may be running into problems with zpool.cache. This has
been fixed in current, which now has the ability to find the root zpool
without a valid zpool.cache, but that I suspect is faint comfort for you.
It turns out it was my /boot.config that was preventing booting. The system is
usually always headless, so I have -S115200 -Dh as the sole line in
/boot.config to enable a 115200 baud serial console. This has been working
fine for me up until I did a {build,install} {kernel,world} on 1st January
2013. I was pretty sure my woes began after I did the zpool upgrade -a and
subsequently rebooted again, but now I can't be sure whether I successfully
rebooted at all after the make installworld and mergemaster step.
Does anyone know a sure-fire way of getting a dual console setup (high-speed
serial + VGA). The recipe I had been using had worked well for a long time. I
had -S115200 -Dh in /boot.config and the following entries in
/boot/loader.conf:
boot_multicons=YES
comconsole_speed=115200
console=comconsole,vidconsole
Now, though, if I have -S115200 -Dh then the system locks up at boot.
Removing /boot.config gets me dual console, but only at 9600 baud. :-(
Cheers,
Paul.
PS: Is the BOOT_COMCONSOLE_SPEED entry in /etc/make.conf needed? I was under
the impression it has been obsolete for a while and took it out of my
/etc/make.conf file.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Solved?: Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system
On Jan 4, 2013, at 5:39 AM, Vincent Hoffman vi...@unsane.co.uk wrote:
On 03/01/2013 21:18, Paul Mather wrote:
It turns out it was my /boot.config that was preventing booting. The system
is usually always headless, so I have -S115200 -Dh as the sole line in
/boot.config to enable a 115200 baud serial console. This has been working
fine for me up until I did a {build,install} {kernel,world} on 1st January
2013. I was pretty sure my woes began after I did the zpool upgrade -a
and subsequently rebooted again, but now I can't be sure whether I
successfully rebooted at all after the make installworld and mergemaster
step.
Does anyone know a sure-fire way of getting a dual console setup (high-speed
serial + VGA). The recipe I had been using had worked well for a long time.
I had -S115200 -Dh in /boot.config and the following entries in
/boot/loader.conf:
boot_multicons=YES
comconsole_speed=115200
console=comconsole,vidconsole
Now, though, if I have -S115200 -Dh then the system locks up at boot.
Removing /boot.config gets me dual console, but only at 9600 baud. :-(
I have
root@copia:/root # more /boot.config
-Dh
and
root@copia:/root # grep 'cons' /boot/loader.conf
console=comconsole,vidconsole
comconsole_speed=19200
boot_multicons=yes
Which works fine for ipmi based serial over lan console in a generic
9.1-RELEASE.
Not sure thats that helpful but 19200 is better than 9600 ;)
That's weird. I have the same basic /boot/loader.conf entries (except for a
speed of 115200) and even just putting -Dh into /boot.config leads to the
same unbootable system behaviour. :-(
Maybe something broke recently in the RELENG_8 boot loader? Like I said
originally, that /boot.config entry had been working for me without problems
for a long time.
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pkgng and updated packages
On Jan 28, 2013, at 1:59 PM, Rainer Duffner rai...@ultra-secure.de wrote: Am 28.01.2013 um 18:31 schrieb Glen Barber g...@freebsd.org: On Mon, Jan 28, 2013 at 06:28:02PM +0100, Rainer Duffner wrote: I go from PERL 5.10 to PERL 5.16, for example and it complains that perl5.16 conflicts with perl5.10... This I needed, too: pkg set -o long/perl5.10:lang/perl5.16 pkg remove perl pkg set -o devel/pkg-config:devel/pkgconf pkg remove -f pkg-config Hmm, you should not have needed to remove perl or pkg-config. They should have been upgraded as any other package. I tried it without and it said it conflicted. It wanted to install perl5.16, without doing anything to 5.10. The lang/perl5.10 and lang/perl5.16 ports are separate ports that are marked in their respective Makefiles as conflicting (because they install files into common places). Perl 5.16 is not an upgrade of Perl 5.10 in the standard ports sense. That is why both the Makefile and pkgng will complain if you try and install both (e.g., installing Perl 5.16 when Perl 5.10 is still installed). If you want to switch to lang/perl5.16 from lang/perl5.10 you could follow a procedure like that outlined in the 20120630 entry of /usr/ports/UPDATING. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run I think case 4 (no definition) is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present. In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service. (If it doesn't, that is a bug, IMHO.) For ports, the case is not so clear. There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to NO. But it is not a universal rule that no definition = default to NO. The net/avahi-app port, for example, doesn't default to NO if xxx_enable is not set: it defaults to whatever the gnome_enable setting is defined to be. For the base OS, I agree with your case 4; for the land of ports, I don't think the answer is so cut and dried. That is why I think the warning is useful: it reminds admins to look at the service in question and make a firm decision of their own as to whether it should explicitly be turned on or off. It
Re: ask about stable
On Feb 20, 2013, at 4:29 AM, Fleuriot Damien m...@my.gd wrote: Here, I think this is what you're looking for: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html You should be able to move from 9.1-RELEASE to 9-STABLE with freebsd-update :) Except that the freebsd-update(8) man page includes the following: DESCRIPTION The freebsd-update tool is used to fetch, install, and rollback binary updates to the FreeBSD base system. Note that updates are only available if they are being built for the FreeBSD release and architecture being used; in particular, the FreeBSD Security Team only builds updates for releases shipped in binary form by the FreeBSD Release Engineering Team, e.g., FreeBSD 7.3-RELEASE and FreeBSD 8.0-RELEASE, but not FreeBSD 6.3-STABLE or FreeBSD 9.0-CURRENT. In other words, you can't use it to track -STABLE or -CURRENT. Cheers, Paul. On Feb 20, 2013, at 9:57 AM, Nurhermansyah eka ekanoti...@gmail.com wrote: hi, oh ya .. true .. I'm running 9.1-RELEASE and I want to update to 9-STABLE it's how to update to 9-STABLE? thank you sorry if my english is bad, i from indonesia.. 2013/2/20 Damien Fleuriot m...@my.gd On 20 Feb 2013, at 06:03, Nurhermansyah eka ekanoti...@gmail.com wrote: hi all.. if I could make a stable version for freebsd 9.1-release ?? thanks Hi, Did you mean I'm running 9.1-RELEASE and I want to update it to 9-STABLE ? If not, kindly clarify... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPMI serial console
On Feb 21, 2013, at 11:29 PM, Jeremy Chadwick j...@koitsu.org wrote: On Fri, Feb 22, 2013 at 02:22:52PM +1030, Daniel O'Connor wrote: On 22/02/2013, at 12:02, Jeremy Chadwick j...@koitsu.org wrote: Hmm I tried putting '-S 115200' in /boot.config and it broke - the boot process didn't run the loader (or kernel). I'll talk a bit about this -- again, sorry for the verbosity. I'll explain what I've historically used/done, then speculate a bit about your IPMI stuff: For me, on systems without IPMI, all I had to do was this (and nothing else): * Put the following in /boot.config: -S115200 -Dh This breaks the boot for me, boot.config has to contain more than just flags it seems. In any case I believe setting boot_multicons and boot_serial is the same as -Dh. Not sure about the baud rate though. Then someone broke something (parser or something else). This has always, *always* worked (just flags). The last time I verified it was with the release of 9.0-RELEASE. I do have a system I could test this on, but I'd need to find a null modem cable first. I have seen some MFCs that touch those bits in the bootloader, but from my memory it didn't touch anything other than supporting /boot/config as an alternate location to the classic /boot.config file. I would be very surprised if this broke it. I can assure you that those were the only flags that were needed, and in exactly that syntax. Even the Handbook has this in it, as well as boot(8). I believe your explanation of boot_multicons and boot_serial are correct and do correlate with -D and -h. I could look at the bootstrap code to verify. The options are described in loader(8) but not loader.conf(5). I think something did break back at the start of the year that caused /boot.config contents to render the system completely unbootable. At least that is what happened to me on RELENG_8: http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071579.html Bruce A. Mah reports later in the same thread that his happened to him on 8.3-RELEASE. I don't know if this was fixed. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPMI serial console
On Feb 21, 2013, at 7:14 PM, Daniel O'Connor docon...@gsoft.com.au wrote: On 22/02/2013, at 10:40, Jeremy Chadwick j...@koitsu.org wrote: X9SIL-F BIOS version 1.1 (05/27/10) IPMI firmware is 2.01. I can't find this motherboard listed on Supermicro's site. kenv | grep smbios output please? Sorry, brainfart, it's an X8SIL-F http://www.supermicro.com/xeon_3400/Motherboard/X8SIL.cfm?IPMI=Y I am also using that motherboard and currently IPMI is working for me under 9.1-STABLE (r246366). My system has BIOS version 1.2 and IPMI firmware version 2.66. I have both the VGA KVM console and SOL console working (though the VGA console seems sensitive to the version of Java you have installed). I am using sysutils/ipmitool to access the system via IPMI SOL console. Here is what my IPMI SOL setup looks like in the BIOS setup screen: Advanced * Advanced - Remote Access Configuration * Select Remote Access * * *** * type. * * Remote Access [Enabled]** * ** * Serial Port Number [COM3 *] ** * Base Address, IRQ [3E8h, 5]** * Serial Port Mode [115200 8,n,1] ** * Flow Control [None] ** * Redirection After BIOS POST[Always] ** * Terminal Type [ANSI] ** * VT-UTF8 Combo Key Support [Enabled]** * Sredir Memory Display Delay[No Delay] ** * * :Move* * * Enter:Select * * * +/-/:Value * * * F10:Save * * * ESC:Exit * * * F1:General Help * * * F8:Fail-Safe Defaults* * * F9:Optimized Defaults* Here is what I have in /boot/loader.conf regarding a serial console: = # Enable IPMI serial console #console=comconsole # Give preference to VGA console console=vidconsole,comconsole # Uncomment below and comment above to give serial console preference #console=comconsole,vidconsole comconsole_speed=115200 boot_multicons=YES hint.uart.0.flags=0x0 hint.uart.2.at=isa hint.uart.2.port=0x3E8 #hint.uart.2.disabled=0 hint.uart.2.flags=0x30 = I don't know whether all of that is needed, but, as you can see from the various commented-out lines, it was a configuration I arrived at that works. :-) I don't have a /boot.config on this system. Usually, I have the VGA console take precedence. In that case, I get messages on both the VGA console and the IPMI SOL console during the BIOS screen, loader, and kernel boot messages but then only messages on the VGA console during the rc.d boot phase. I have a serial console enabled in /etc/ttys, so I get output (e.g., getty login) on the IPMI SOL when that is eventually spawned. If I want to have the serial console take precedence, I usually escape to the loader prompt (via ESC at the loader menu) and issue a set console=comconsole,vidconsole command. Then, the rc.d boot output goes to the serial console and not the VGA console. (It would be nice to have rc.d init scripts output go to both consoles, but I don't know whether that is possible.) Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Virtio and GEOM labels
I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM virtualisation. I have networking and storage in the FreeBSD guest using the Virtio drivers (with the virtual disk set to Virtio in the definition on the host). Everything is working nicely: I have a vtnet network adapter and see vtbd devices for my virtual disks in FreeBSD. Performance is much better compared with an emulated IDE device. The odd thing is that I don't see GEOM labels reflected in /dev. For example, I have GPT labels defined in the guest, but I don't see them show up under /dev/gpt. Similarly, my UFS labels don't show up under /dev/ufs. I *do* see a /dev/gptid. That appears to be the only label that shows up. Is there something special I need to do to get GPT and UFS labels to appear when using Virtio? It seems to me that Virtio block devices appear to be somewhat unusual. Unlike regular ATA and SCSI devices, my vtbd devices don't appear in the boot dmesg (although a vtblk device does), and camcontrol devlist does not list them. It's not clear to me how I am supposed to interact with them other than via basic device I/O through /dev/vtbdX. I thought that the virtio_scsi module might make them appear as da devices and able to interacted with via camcontrol, but this doesn't seem to be the case. I've included my system dmesg at the end of this message. Cheers, Paul. = Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #0 r248465: Mon Mar 18 11:19:23 EDT 2013 pmat...@freebsd9.virtual.lib.vt.edu:/usr/obj/usr/src/sys/KVMTEST amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: QEMU Virtual CPU version (cpu64-rhel6) (2100.15-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x6d3 Family = 0x6 Model = 0xd Stepping = 3 Features=0x783f3ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2 Features2=0x80002001SSE3,CX16,HV AMD Features=0x22500800SYSCALL,NX,MMX+,FFXSR,LM AMD Features2=0x73LAHF,CMP,CR8,ABM,SSE4A real memory = 8589934592 (8192 MB) avail memory = 8255410176 (7872 MB) Event timer LAPIC quality 400 ACPI APIC Table: BOCHS BXPCAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: BOCHS BXPCRSDT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci_link4: Unable to route IRQs: AE_NOT_FOUND isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 uhci0: Intel 82371SB (PIIX3) USB controller port 0xc020-0xc03f irq 11 at device 1.2 on pci0 usbus0: controller did not stop usbus0 on uhci0 pci0: bridge at device 1.3 (no driver attached) vgapci0: VGA-compatible display mem 0xf000-0xf1ff,0xf200-0xf2000fff at device 2.0 on pci0 virtio_pci0: VirtIO PCI Network adapter port 0xc040-0xc05f mem 0xf202-0xf2020fff irq 11 at device 3.0 on pci0 vtnet0: VirtIO Networking Adapter on virtio_pci0 virtio_pci0: host features: 0x711fffe3 EventIdx,RingIndirect,NotifyOnEmpty,RxModeExtra,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxUFO,TxTSOECN,TxTSOv6,TxTSOv4,RxUFO,RxECN,RxTSOv6,RxTSOv4,TxAllGSO,MacAddress,RxChecksum,TxChecksum virtio_pci0: negotiated features: 0x110fbba3 RingIndirect,NotifyOnEmpty,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxTSOECN,TxTSOv6,TxTSOv4,RxECN,RxTSOv6,RxTSOv4,MacAddress,RxChecksum,TxChecksum vtnet0: Ethernet address: 52:54:00:3e:48:94 virtio_pci1: VirtIO PCI Balloon adapter port 0xc060-0xc07f irq 10 at device 5.0 on pci0 vtballoon0: VirtIO Balloon Adapter on virtio_pci1 virtio_pci1: host features: 0x7102 EventIdx,RingIndirect,NotifyOnEmpty,StatsVq virtio_pci1: negotiated features: 0x0 virtio_pci2: VirtIO PCI Block adapter port 0xc080-0xc0bf mem 0xf204-0xf2040fff irq 10 at device 6.0 on pci0 vtblk0: VirtIO Block Adapter on virtio_pci2 virtio_pci2: host features: 0x71000654 EventIdx,RingIndirect,NotifyOnEmpty,Topology,FlushCmd,BlockSize,DiskGeometry,MaxNumSegs virtio_pci2: negotiated features: 0x1254 RingIndirect,FlushCmd,BlockSize,DiskGeometry,MaxNumSegs vtblk0: 8192MB (16777216 512 byte sectors) atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on
Re: Virtio and GEOM labels
On Mar 25, 2013, at 1:46 PM, John Nielsen li...@jnielsen.net wrote: On Mar 22, 2013, at 8:14 AM, Paul Mather p...@gromit.dlib.vt.edu wrote: I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM virtualisation. I have networking and storage in the FreeBSD guest using the Virtio drivers (with the virtual disk set to Virtio in the definition on the host). Everything is working nicely: I have a vtnet network adapter and see vtbd devices for my virtual disks in FreeBSD. Performance is much better compared with an emulated IDE device. I've had the same experience. The odd thing is that I don't see GEOM labels reflected in /dev. For example, I have GPT labels defined in the guest, but I don't see them show up under /dev/gpt. Similarly, my UFS labels don't show up under /dev/ufs. I *do* see a /dev/gptid. That appears to be the only label that shows up. I have not encountered this issue. I use virtio block devices and GPT labels exclusively in multiple FreeBSD 9.1 guests and all mount/function without issue. How are you referring to your filesystems in /etc/fstab? IIRC GEOM makes not-in-use labels disappear when a device is in use (e.g. mounted). If you take a new device, put a labeled GPT partition on it and a labeled UFS partition on that but don't mount anything, what happens? Thanks for the reply. My apologies: this is a case of pilot error on my part. I was mounting the devices as /dev/vtbd... I hadn't realised that the present-but-unused labels were being suppressed when the device was mounted. Has this always been the case? For some reason I had a distinct recollection stuck in my mind that all labels showed up in /dev. Anyway, many thanks for pointing the way to the solution. I now have GPT- and UFS-labelled devices mounted in my FreeBSD guest system. Is there something special I need to do to get GPT and UFS labels to appear when using Virtio? It seems to me that Virtio block devices appear to be somewhat unusual. Unlike regular ATA and SCSI devices, my vtbd devices don't appear in the boot dmesg (although a vtblk device does), and camcontrol devlist does not list them. It's not clear to me how I am supposed to interact with them other than via basic device I/O through /dev/vtbdX. I thought that the virtio_scsi module might make them appear as da devices and able to interacted with via camcontrol, but this doesn't seem to be the case. Virtio block devices and virtio SCSI devices are not the same. If you want to use the virtio_scsi module in FreeBSD you should expose a virtio SCSI device from the host. Thank you for the explanation. I've been using virt-manager up to now for setting up KVM guests and it seems that virtio-scsi isn't exposed through that interface---only through the command line. I'll have to investigate... Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS Panic after freebsd-update
On Jul 1, 2013, at 11:49 AM, Jeremy Chadwick j...@koitsu.org wrote: On Mon, Jul 01, 2013 at 11:35:30AM -0400, Scott Sipe wrote: *** Sorry for partial first message! (gmail sent after multiple returns apparently?) *** Hello, I have not had much time to research this problem yet, so please let me know what further information I might be able to provide. [[...]] Any thoughts? Thoughts: [[..]] Of course when I see lines like this: Trying to mount root from zfs:zroot ...this greatly diminishes any chances of live debugging on the system. It amazes me how often I see this come up on the lists -- people who have ZFS problems but use ZFS for their root/var/tmp/usr. I wish that behaviour would stop, as it makes debugging ZFS a serious PITA. This comes up on the list almost constantly, sad panda. I'm not sure why it amazes you that people are making widespread use of ZFS. You could make the same argument that people shouldn't use UFS2 journaling on their file systems because bugs in the implementation might make debugging journaled UFS2 file systems a serious PITA. The point is that there are VERY compelling reasons why people might want to use ZFS for root/var/tmp/usr/etc. (pooled storage; easy snapshots; etc.) and there should come a time when a given file system is generally regarded as safe. I'd say the time for ZFS came when they removed the big disclaimer from the boot messages. If ZFS is dangerous, they should reinstate the not ready for production warning. Until they do, I think it's unfair to castigate people for using ZFS universally. Isn't it a recurring theme on freebsd-current and freebsd-stable that more people need to use features so they can be debugged in realistic environments? If you're telling them, don't use that because it makes debugging harder, how are they supposed to get debugged and hence improved? :-) Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Enabling pf in 9-STABLE guest on KVM triggers abrt crash report
I have been using 9-STABLE as a guest under KVM on RHEL 6 for several months
now without incident. I am using the virtio drivers and using bridged
networking on the host to attach my guests.
Recently, I enabled pf in one of my 9-STABLE (r253579) guests and subsequently
started to receive intermittent crash reports from abrt on the KVM host. Has
anyone else encountered problems using pf under KVM virtualisation?
A typical crash report from the host goes like this:
=
abrt_version: 2.0.8
cmdline:ro root=/dev/mapper/chumby-root rd_LVM_LV=chumby/root
rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=chumby/swap SYSFONT=latarcyrheb-sun16
crashkernel=137M@0M rd_MD_UUID=b7338ac5:b08fdc1b:34d0fcf1:cf28da17
KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet console=tty0
console=ttyS1,115200
kernel: 2.6.32-358.14.1.el6.x86_64
not-reportable: A kernel problem occurred, but your kernel has been tainted
(flags:GW ). Kernel maintainers are unable to diagnose tainted reports.
time: Wed 07 Aug 2013 11:41:22 AM EDT
sosreport.tar.xz: Binary file, 2114408 bytes
backtrace:
:WARNING: at net/core/dev.c:1759 skb_gso_segment+0x1df/0x2b0() (Tainted: G
W --- )
:Hardware name: AX1204-819-R700UB
:igb: caps=(0x12114bb3, 0x0) len=2084 data_len=0 ip_summed=0
:Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
iptable_filter ip_tables ebtable_nat ebtables xt_CHECKSUM cpufreq_ondemand
powernow_k8 freq_table mperf bridge stp llc ipt_REJECT ip6t_REJECT
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
ip6_tables ipv6 ext2 vhost_net macvtap macvlan tun kvm_amd kvm igb dca ptp
pps_core microcode sg serio_raw fam15h_power k10temp amd64_edac_mod edac_core
edac_mce_amd i2c_piix4 i2c_core shpchp ext4 mbcache jbd2 raid1 sr_mod cdrom
sd_mod crc_t10dif pata_acpi ata_generic pata_atiixp ahci dm_mirror
dm_region_hash dm_log dm_mod [last unloaded: nf_defrag_ipv4]
:Pid: 3262, comm: vhost-3242 Tainted: GW ---
2.6.32-358.14.1.el6.x86_64 #1
:Call Trace:
:IRQ [8106e307] ? warn_slowpath_common+0x87/0xc0
:[8106e3f6] ? warn_slowpath_fmt+0x46/0x50
:[a01b7d62] ? igb_get_drvinfo+0x82/0xe0 [igb]
:[81448c2f] ? skb_gso_segment+0x1df/0x2b0
:[81449010] ? dev_hard_start_xmit+0x1b0/0x530
:[814674ea] ? sch_direct_xmit+0x15a/0x1c0
:[8144ce70] ? dev_queue_xmit+0x3b0/0x550
:[a02fd64c] ? br_dev_queue_push_xmit+0x6c/0xa0 [bridge]
:[a02fd6d8] ? br_forward_finish+0x58/0x60 [bridge]
:[a02fd78a] ? __br_forward+0xaa/0xd0 [bridge]
:[81474ce4] ? nf_hook_slow+0x74/0x110
:[a02fd80d] ? br_forward+0x5d/0x70 [bridge]
:[a02fe5e9] ? br_handle_frame_finish+0x179/0x2a0 [bridge]
:[81063536] ? rebalance_domains+0x1a6/0x5a0
:[a02fe8ba] ? br_handle_frame+0x1aa/0x250 [bridge]
:[814486d9] ? __netif_receive_skb+0x529/0x750
:[8144899a] ? process_backlog+0x9a/0x100
:[8144d203] ? net_rx_action+0x103/0x2f0
:[81076fd1] ? __do_softirq+0xc1/0x1e0
:[8100c1cc] ? call_softirq+0x1c/0x30
:[8100c1cc] ? call_softirq+0x1c/0x30
:EOI [8100de05] ? do_softirq+0x65/0xa0
:[8144d688] ? netif_rx_ni+0x28/0x30
:[a0079739] ? tun_sendmsg+0x229/0x4ec [tun]
:[a024acf5] ? handle_tx+0x275/0x5e0 [vhost_net]
:[a024b095] ? handle_tx_kick+0x15/0x20 [vhost_net]
:[a024855c] ? vhost_worker+0xbc/0x140 [vhost_net]
:[a02484a0] ? vhost_worker+0x0/0x140 [vhost_net]
:[81096956] ? kthread+0x96/0xa0
:[8100c0ca] ? child_rip+0xa/0x20
:[810968c0] ? kthread+0x0/0xa0
:[8100c0c0] ? child_rip+0x0/0x20
=
I get these crash reports even with a simple firewall rule set like this:
=
# $FreeBSD: stable/9/share/examples/pf/pf.conf 218854 2011-02-19
14:57:00Z brucec $
# $OpenBSD: pf.conf,v 1.34 2007/02/24 19:30:59 millert Exp $
#
# See pf.conf(5) and /usr/share/examples/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.
ext_if=vtnet0
set skip on lo
scrub in
block in
pass out
pass in on $ext_if proto tcp to ($ext_if) port ssh
pass in on $ext_if inet proto icmp from any to ($ext_if) icmp-type { unreach,
redir, timex }
=
Does anyone know of any problems using pf with the virtio vtnet driver, or
indeed in using pf at all under KVM virtualisation? For now, I've turned off
pf, but I would like to be able to enable it in future to do firewalling on the
virtual guest. I have no problems using iptables for firewalling on my Linux
KVM guests.
Cheers,
Paul.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: protecting some processes from out-of-swap killer
On Apr 28, 2015, at 5:51 AM, Ronald Klop ronald-li...@klop.ws wrote: On Sat, 25 Apr 2015 13:15:32 +0200, Dmitry Morozovsky ma...@rinet.ru wrote: On Sat, 25 Apr 2015, Baptiste Daroussin wrote: However, sometimes postgres processes got killed by 'out of swap space'. I suppose the source of problem could be that VSZ size of postgres processes (8-9 G) is bigger than swap congigured (4G). Is there any way to prevent this, besides reallocating space for swap? protect(1) ? Of course. I really do not understand how google hides the man page from me. Thanks, and sorry fot the noise. The OS trying to kill a process is probably not what you want. So when you protect(1) postgres the OS will kill another process, which I hope is not running without reason. My advice would be to - or increase your swap space - or tune postgresql to use less memory - or limit tmpfs (tmpfs uses swap if RAM is short) - or tune zfs to use less memory That is good advice, although I do think protect has its place for preventing unforeseen accidents as mentioned above. I believe it's good to be able to designate certain processes as more valuable than others if you know that to be the case. A case in point: We have an Omeka instance on a fairly low-resource system. Omeka uses ImageMagick to generate thumbnails for items added to collections. In one case, we had a very large TIFF file added, who, when having a thumbnail generated, caused its thumbnail-generating process to consume large amounts of memory and swap. When swap was exhausted, the OS decided it needed to kill off something and settled upon Apache (under which Omeka runs), causing Omeka to stop running. In other times, the out-of-swap killer has chosen to kill the SSH daemon, making it harder subsequently to access the box and fix problems. Being able to protect httpd---or even just sshd---served as a handy safety belt after that happened. :-) I guess the proper way to address this would be to set limits on Apache or the thumbnail generation so it doesn't go hog wild in the future... Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs, cam sticking on failed disk
On May 7, 2015, at 8:00 AM, Steven Hartland kill...@multiplay.co.uk wrote: On 07/05/2015 11:46, Slawa Olhovchenkov wrote: On Thu, May 07, 2015 at 11:38:46AM +0100, Steven Hartland wrote: How I can cancel this 24 requst? Why this requests don't timeout (3 hours already)? How I can forced detach this disk? (I am lready try `camcontrol reset`, `camconrol rescan`). Why ZFS (or geom) don't timeout on request and don't rerouted to da18? If they are in mirrors, in theory you can just pull the disk, isci will report to cam and cam will report to ZFS which should all recover. Yes, zmirror with da18. I am surprise that ZFS don't use da18. All zpool fully stuck. A single low level request can only be handled by one device, if that device returns an error then ZFS will use the other device, but not until. Why next requests don't routed to da18? Current request stuck on da19 (unlikely, but understund), but why stuck all pool? Its still waiting for the request from the failed device to complete. As far as ZFS currently knows there is nothing wrong with the device as its had no failures. Maybe related to this, but if the drive stalls indefinitely, is it what leads to the panic: I/O to pool 'poolname' appears to be hung on vdev guid GUID-ID at '/dev/somedevice'.? I have a 6-disk RAIDZ2 pool that is used for nightly rsync backups from various systems. I believe one of the drives is a bit temperamental. Very occasionally, I discover the backup has failed and the machine actually paniced because of this drive, with a panic message like the above. The panic backtrace includes references to vdev_deadman, which sounds like some sort of dead man's switch/watchdog. It's a bit counter-intuitive that a single drive wandering off into la-la land can not only cause an entire ZFS pool to wedge, but, worse still, panic the whole machine. If I'm understanding this thread correctly, part of the problem is that an I/O never completing is not the same as a failure to ZFS, and hence ZFS can't call upon various resources in the pool and mechanisms at its disposal to correct for that. Is that accurate? I would think that never-ending I/O requests would be a type of failure that ZFS could sustain. It seems from the hung on vdev panic that it does detect this situation, though the resolution (panic) is not ideal. :-) Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2
On Aug 3, 2015, at 11:09 AM, Alban Hertroys haram...@gmail.com wrote: On 3 August 2015 at 15:01, Paul Mather freebsd-li...@gromit.dlib.vt.edu wrote: On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu wrote: On 08/02/2015 21:22, Paul Mather wrote: I have a 4TB external USB drive (Western Digital My Book 1230) that I am trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul 29 20:59:39 EDT 2015). This system has a MSI 760GMA-P34 (FX) motherboard. The drive probes unreliably when plugged in to a USB 3 port. It reliably probes when plugged into a USB 2 port. However, it works in neither cases. Attempting to dd from the drive results in a dd: /dev/da0: Invalid argument. FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X (Mavericks). The drive was being used for Time Machine backups, but it would at irregular intervals it would just 'disconnect' itself. My guess is that there's a firmware problem in the USB3 chip in those drives. After trying to get the issue fixed for almost half a year I returned it and replaced it by a Seagate, which has been working flawlessly ever since. I'm just saying, perhaps the problem isn't with FreeBSD but with the drive. I'd love just to get to the randomly disconnects stage under FreeBSD at this point. :-) Up to now, I have been unable to read ANY data off the drive under FreeBSD, either via USB 2 or USB 3. :-( However, you have given me something to think about: does anyone know of a 4 TB USB 2 or 3 drive that will work reliably under FreeBSD 10-STABLE right now? Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pkg clean question
On Aug 3, 2015, at 11:39 AM, Zoran Kolic zko...@sbb.rs wrote: Amd64, 9.3. Updated few times, packages also. At first I found on laptop that /var directory was at 102%. Using pkg clean i removed about 400mb of cache packages from /var/cache/pkg. Tried to clean desktop cache and the out- put of the command was nothing to do. I see about 400 mb of files in the cache directory. Is it safe to remove them by the hand? Use pkg clean -ay to delete all cached packages, not just the ones that are no longer current or provided by the upstream repository. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2
On Aug 3, 2015, at 12:17 PM, Jack Vogel jfvo...@gmail.com wrote: Have you tried it on HEAD, and have you tried it on the same system with some recent flavor of Linux? No, and no. It's a good idea, though. I can try it this weekend, if I can run each OS via a USB memstick. With this being such a commonplace drive, I'd hoped someone might pipe up and say something along the lines of, oh, you have to add USB quirk XYZ to get that model working under FreeBSD. No such luck, it seems. Cheers, Paul. Jack On Mon, Aug 3, 2015 at 8:35 AM, Paul Mather freebsd-li...@gromit.dlib.vt.edu mailto:freebsd-li...@gromit.dlib.vt.edu wrote: On Aug 3, 2015, at 11:09 AM, Alban Hertroys haram...@gmail.com mailto:haram...@gmail.com wrote: On 3 August 2015 at 15:01, Paul Mather freebsd-li...@gromit.dlib.vt.edu mailto:freebsd-li...@gromit.dlib.vt.edu wrote: On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu mailto:mcdou...@egr.msu.edu wrote: On 08/02/2015 21:22, Paul Mather wrote: I have a 4TB external USB drive (Western Digital My Book 1230) that I am trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul 29 20:59:39 EDT 2015). This system has a MSI 760GMA-P34 (FX) motherboard. The drive probes unreliably when plugged in to a USB 3 port. It reliably probes when plugged into a USB 2 port. However, it works in neither cases. Attempting to dd from the drive results in a dd: /dev/da0: Invalid argument. FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X (Mavericks). The drive was being used for Time Machine backups, but it would at irregular intervals it would just 'disconnect' itself. My guess is that there's a firmware problem in the USB3 chip in those drives. After trying to get the issue fixed for almost half a year I returned it and replaced it by a Seagate, which has been working flawlessly ever since. I'm just saying, perhaps the problem isn't with FreeBSD but with the drive. I'd love just to get to the randomly disconnects stage under FreeBSD at this point. :-) Up to now, I have been unable to read ANY data off the drive under FreeBSD, either via USB 2 or USB 3. :-( However, you have given me something to think about: does anyone know of a 4 TB USB 2 or 3 drive that will work reliably under FreeBSD 10-STABLE right now? Cheers, Paul. ___ freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org mailto:freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2
On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu wrote: On 08/02/2015 21:22, Paul Mather wrote: I have a 4TB external USB drive (Western Digital My Book 1230) that I am trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul 29 20:59:39 EDT 2015). This system has a MSI 760GMA-P34 (FX) motherboard. The drive probes unreliably when plugged in to a USB 3 port. It reliably probes when plugged into a USB 2 port. However, it works in neither cases. Attempting to dd from the drive results in a dd: /dev/da0: Invalid argument. When plugged in to a USB 2 port, this is how the drive is probed: ugen6.2: Western Digital at usbus6 umass0: Western Digital My Book 1230, class 0/0, rev 2.10/10.65, addr 2 on usbus6 umass0: SCSI over Bulk-Only; quirks = 0xc001 umass0:9:0:-1: Attached to scbus9 da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: WD My Book 1230 1065 Fixed Direct Access SPC-4 SCSI device da0: Serial Number 57434334453056594A4C4A4A da0: 40.000MB/s transfers da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C) da0: quirks=0x2NO_6_BYTE ses0 at umass-sim0 bus 0 scbus9 target 0 lun 1 ses0: WD SES Device 1065 Fixed Enclosure Services SPC-4 SCSI device ses0: Serial Number 57434334453056594A4C4A4A ses0: 40.000MB/s transfers ses0: SCSI-3 ENC Device When booting with it connected to a USB 3 port, this is what is output: xhci0: XHCI (generic) USB 3.0 controller mem 0xfeafe000-0xfeaf irq 18 at device 0.0 on pci3 xhci0: 64 bytes context size, 64-bit DMA usbus0 on xhci0 [[...]] ohci0: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fe000-0xfe7fefff irq 16 at device 18.0 on pci0 usbus1 on ohci0 ohci1: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fd000-0xfe7fdfff irq 16 at device 18.1 on pci0 usbus2 on ohci1 ehci0: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff800-0xfe7ff8ff irq 17 at device 18.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 ohci2: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.0 on pci0 usbus4 on ohci2 ohci3: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f7000-0xfe7f7fff irq 18 at device 19.1 on pci0 usbus5 on ohci3 ehci1: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff400-0xfe7ff4ff irq 19 at device 19.2 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci1 [[...]] ohci4: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f6000-0xfe7f6fff irq 18 at device 20.5 on pci0 usbus7 on ohci4 [[...]] usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 usbus7: 12Mbps Full Speed USB v1.0 ugen7.1: ATI at usbus7 uhub0: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus7 ugen6.1: ATI at usbus6 uhub1: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus6 ugen5.1: ATI at usbus5 uhub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus5 ugen4.1: ATI at usbus4 uhub3: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus4 ugen3.1: ATI at usbus3 uhub4: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus3 ugen2.1: ATI at usbus2 uhub5: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 ugen1.1: ATI at usbus1 uhub6: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen0.1: 0x1912 at usbus0 uhub7: 0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1 on usbus0 uhub0: 2 ports with 2 removable, self powered uhub2: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub5: 3 ports with 3 removable, self powered uhub6: 3 ports with 3 removable, self powered uhub7: 8 ports with 8 removable, self powered [[...]] Root mount waiting for: usbus6 usbus3 usbus0 Root mount waiting for: usbus6 usbus3 usbus0 uhub1: 6 ports with 6 removable, self powered uhub4: 6 ports with 6 removable, self powered ugen0.2: vendor 0x1058 at usbus0 umass0: vendor 0x1058 product 0x1230, class 0/0, rev 3.00/10.65, addr 1 on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8000 Root mount waiting for: usbus0 [[...]] Root mount waiting for: usbus0 Root mount waiting for: usbus0 umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) umass0:9:0:-1: Attached to scbus9 [[...]] da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0:Fixed Direct Access SCSI device da0: Serial Number WCC4E0VYJLJJ da0: 400.000MB/s transfers da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C) da0: quirks=0x2NO_6_BYTE This external USB drive works fine under OSX Yosemite and also when plugged in to my Raspberry Pi 2 running OSMC. Is there anyone using this model of USB drive under FreeBSD/amd64 10.2? Is it a matter of finding the correct quirk to get it working? Cheers, Paul. The trouble detecting is probably related to https://bugs.freebsd.org
4TB Western Digital My Book 1230 USB hard drive not working on 10.2
I have a 4TB external USB drive (Western Digital My Book 1230) that I am trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul 29 20:59:39 EDT 2015). This system has a MSI 760GMA-P34 (FX) motherboard. The drive probes unreliably when plugged in to a USB 3 port. It reliably probes when plugged into a USB 2 port. However, it works in neither cases. Attempting to dd from the drive results in a dd: /dev/da0: Invalid argument. When plugged in to a USB 2 port, this is how the drive is probed: ugen6.2: Western Digital at usbus6 umass0: Western Digital My Book 1230, class 0/0, rev 2.10/10.65, addr 2 on usbus6 umass0: SCSI over Bulk-Only; quirks = 0xc001 umass0:9:0:-1: Attached to scbus9 da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: WD My Book 1230 1065 Fixed Direct Access SPC-4 SCSI device da0: Serial Number 57434334453056594A4C4A4A da0: 40.000MB/s transfers da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C) da0: quirks=0x2NO_6_BYTE ses0 at umass-sim0 bus 0 scbus9 target 0 lun 1 ses0: WD SES Device 1065 Fixed Enclosure Services SPC-4 SCSI device ses0: Serial Number 57434334453056594A4C4A4A ses0: 40.000MB/s transfers ses0: SCSI-3 ENC Device When booting with it connected to a USB 3 port, this is what is output: xhci0: XHCI (generic) USB 3.0 controller mem 0xfeafe000-0xfeaf irq 18 at device 0.0 on pci3 xhci0: 64 bytes context size, 64-bit DMA usbus0 on xhci0 [[...]] ohci0: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fe000-0xfe7fefff irq 16 at device 18.0 on pci0 usbus1 on ohci0 ohci1: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fd000-0xfe7fdfff irq 16 at device 18.1 on pci0 usbus2 on ohci1 ehci0: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff800-0xfe7ff8ff irq 17 at device 18.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 ohci2: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.0 on pci0 usbus4 on ohci2 ohci3: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f7000-0xfe7f7fff irq 18 at device 19.1 on pci0 usbus5 on ohci3 ehci1: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff400-0xfe7ff4ff irq 19 at device 19.2 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci1 [[...]] ohci4: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f6000-0xfe7f6fff irq 18 at device 20.5 on pci0 usbus7 on ohci4 [[...]] usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 usbus7: 12Mbps Full Speed USB v1.0 ugen7.1: ATI at usbus7 uhub0: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus7 ugen6.1: ATI at usbus6 uhub1: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus6 ugen5.1: ATI at usbus5 uhub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus5 ugen4.1: ATI at usbus4 uhub3: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus4 ugen3.1: ATI at usbus3 uhub4: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus3 ugen2.1: ATI at usbus2 uhub5: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 ugen1.1: ATI at usbus1 uhub6: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen0.1: 0x1912 at usbus0 uhub7: 0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1 on usbus0 uhub0: 2 ports with 2 removable, self powered uhub2: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub5: 3 ports with 3 removable, self powered uhub6: 3 ports with 3 removable, self powered uhub7: 8 ports with 8 removable, self powered [[...]] Root mount waiting for: usbus6 usbus3 usbus0 Root mount waiting for: usbus6 usbus3 usbus0 uhub1: 6 ports with 6 removable, self powered uhub4: 6 ports with 6 removable, self powered ugen0.2: vendor 0x1058 at usbus0 umass0: vendor 0x1058 product 0x1230, class 0/0, rev 3.00/10.65, addr 1 on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8000 Root mount waiting for: usbus0 [[...]] Root mount waiting for: usbus0 Root mount waiting for: usbus0 umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) umass0:9:0:-1: Attached to scbus9 [[...]] da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0:Fixed Direct Access SCSI device da0: Serial Number WCC4E0VYJLJJ da0: 400.000MB/s transfers da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C) da0: quirks=0x2NO_6_BYTE This external USB drive works fine under OSX Yosemite and also when plugged in to my Raspberry Pi 2 running OSMC. Is there anyone using this model of USB drive under FreeBSD/amd64 10.2? Is it a matter of finding the correct quirk to get it working? Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2
On Aug 3, 2015, at 2:15 PM, Paul Mather freebsd-li...@gromit.dlib.vt.edu wrote: On Aug 3, 2015, at 12:17 PM, Jack Vogel jfvo...@gmail.com wrote: Have you tried it on HEAD, and have you tried it on the same system with some recent flavor of Linux? No, and no. It's a good idea, though. I can try it this weekend, if I can run each OS via a USB memstick. Just to follow up on myself, I tried this external USB drive on a 20150804-r286285 snapshot of FreeBSD/amd64 11-CURRENT on the same system, as well as under Ubuntu 15.04. The 4 TB Western Digital My Book 1230 works under both those operating systems. The drive is detected and works reliably when plugged in to a USB 2 port on either 11-CURRENT or Ubuntu 15.04. It also works reliably when plugged in to a USB 3 port on either OS, however, it isn't always detected reliably under FreeBSD 11-CURRENT when unplugged and plugged in again (2 times out of 3 attempts), but was detected every time without fail under Ubuntu 15.04. So, it appears the hardware is okay; it seems the problem may lie with FreeBSD 10.2. Cheers, Paul. With this being such a commonplace drive, I'd hoped someone might pipe up and say something along the lines of, oh, you have to add USB quirk XYZ to get that model working under FreeBSD. No such luck, it seems. Cheers, Paul. Jack On Mon, Aug 3, 2015 at 8:35 AM, Paul Mather freebsd-li...@gromit.dlib.vt.edu mailto:freebsd-li...@gromit.dlib.vt.edu wrote: On Aug 3, 2015, at 11:09 AM, Alban Hertroys haram...@gmail.com mailto:haram...@gmail.com wrote: On 3 August 2015 at 15:01, Paul Mather freebsd-li...@gromit.dlib.vt.edu mailto:freebsd-li...@gromit.dlib.vt.edu wrote: On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu mailto:mcdou...@egr.msu.edu wrote: On 08/02/2015 21:22, Paul Mather wrote: I have a 4TB external USB drive (Western Digital My Book 1230) that I am trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul 29 20:59:39 EDT 2015). This system has a MSI 760GMA-P34 (FX) motherboard. The drive probes unreliably when plugged in to a USB 3 port. It reliably probes when plugged into a USB 2 port. However, it works in neither cases. Attempting to dd from the drive results in a dd: /dev/da0: Invalid argument. FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X (Mavericks). The drive was being used for Time Machine backups, but it would at irregular intervals it would just 'disconnect' itself. My guess is that there's a firmware problem in the USB3 chip in those drives. After trying to get the issue fixed for almost half a year I returned it and replaced it by a Seagate, which has been working flawlessly ever since. I'm just saying, perhaps the problem isn't with FreeBSD but with the drive. I'd love just to get to the randomly disconnects stage under FreeBSD at this point. :-) Up to now, I have been unable to read ANY data off the drive under FreeBSD, either via USB 2 or USB 3. :-( However, you have given me something to think about: does anyone know of a 4 TB USB 2 or 3 drive that will work reliably under FreeBSD 10-STABLE right now? Cheers, Paul. ___ freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org mailto:freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
10.2-RC1/STABLE VIMAGE memory leak progress?
I'm running 10-STABLE (which currently identifies itself as 10.2-PRERELEASE) and lately I've started experimenting with using iocage for Jail management. (I really like it so far.) In particular, I've been trying out iocage's support for VNET networking that relies on VIMAGE and uses bridge and epair for the network. I find that when I stop a VNET Jail using iocage that I get something akin to the following in my console logs: = Jul 27 10:59:47 chumby kernel: vnet0:1: link state changed to DOWN Jul 27 10:59:47 chumby kernel: vnet0: link state changed to DOWN Jul 27 10:59:47 chumby kernel: re0: link state changed to DOWN Jul 27 10:59:47 chumby kernel: bridge0: link state changed to DOWN Jul 27 10:59:47 chumby kernel: vnet1:1: link state changed to DOWN Jul 27 10:59:47 chumby kernel: vnet1: link state changed to DOWN Jul 27 10:59:47 chumby kernel: bridge1: link state changed to DOWN Jul 27 10:59:47 chumby kernel: ifa_del_loopback_route: deletion failed: 48 Jul 27 10:59:47 chumby kernel: Freed UMA keg (udp_inpcb) was not empty (120 items). Lost 12 pages of memory. Jul 27 10:59:47 chumby kernel: Freed UMA keg (udpcb) was not empty (1169 items). Lost 7 pages of memory. Jul 27 10:59:47 chumby kernel: hhook_vnet_uninit: hhook_head type=1, id=1 cleanup required Jul 27 10:59:47 chumby kernel: hhook_vnet_uninit: hhook_head type=1, id=0 cleanup required = I found a PR (kern/164763) dating back to 2012-02-04 describing the problem. The last update on that PR was on 2014-10-17, which made reference to some unmerged fixes that would be good to merge into HEAD. Does anyone know whether this was done? One of the entries in that PR states, Our current rule of thumb is 'if you need to shutdown one vimage jail then you need to reboot the host.' It then goes on to observe, Of course this is far from optimal. Is it safe to say, then, that dynamic VNET Jails are not recommended still under FreeBSD? Judging by that PR, this is not likely to be fixed for 10.2-RELEASE? Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Circular dependency between local_unbound and ntpd?
On Jul 14, 2015, at 10:33 AM, krad kra...@gmail.com wrote: As $ grep REQUIRE /etc/rc.d/ntpd # REQUIRE: DAEMON ntpdate FILESYSTEMS devfs You could set something similar to the following in the rc.conf ntpdate_hosts=a.b.c.d w.x.y.z ntpdate_enable=yes Thanks for that suggestion. I assume the a.b.c.d w.x.y.z are IP addresses, not hostnames, otherwise we'd have the same problem. The /etc/rc.d/ntpdate startup script has a REQUIRE: NETWORKING ... and /etc/rc.d/local_unbound has a BEFORE: NETWORKING in it, meaning it will be running before ntpdate runs. That means DNS resolution will require an accurate clock and, I assume, mean that ntpdate will require IP addresses, too? So, it still comes down to this: do I need to know the IP address of an NTP server to be able to use local_unbound safely with NTP? Cheers, Paul. On 14 July 2015 at 14:43, Paul Mather p...@gromit.dlib.vt.edu mailto:p...@gromit.dlib.vt.edu wrote: I believe I ran afoul of a circular dependency between local_unbound and ntpd on my 10.2-PRERELEASE system. I use a stock /etc/ntp.conf and use ntpd_sync_on_start=YES. Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch for the first time. No problem, I thought: NTP will correct it at boot. Wrong! When my system booted, the time was not corrected. Also, DNS resolution was not working. I figured out it was because local_unbound relies on an accurately set clock, but the clock could not be set accurately because my stock ntp.conf requires working DNS resolution to reach the NTP servers. That sounds like a potential circular dependency to me. My workaround at the time was to look up 0.freebsd.pool.ntp.org http://0.freebsd.pool.ntp.org/ on another system; stop ntpd; then do a ntpdate using the IP addresses to set the clock. Once the clock was set accurately, things were all hunky dory. Does anyone have any suggestion for an automatic way around this? I guess one way would be to put the IP address of an NTP server into my ntp.conf file, so at least one would be reachable without needing a working DNS? My main concern is for those systems like my Raspberry Pi and Beaglebone Black that don't have a battery-backed clock. I currently don't use local_unbound on those, but it seems like I'd encounter this problem routinely if I did. Cheers, Paul. ___ freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org mailto:freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Circular dependency between local_unbound and ntpd?
I believe I ran afoul of a circular dependency between local_unbound and ntpd on my 10.2-PRERELEASE system. I use a stock /etc/ntp.conf and use ntpd_sync_on_start=YES. Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch for the first time. No problem, I thought: NTP will correct it at boot. Wrong! When my system booted, the time was not corrected. Also, DNS resolution was not working. I figured out it was because local_unbound relies on an accurately set clock, but the clock could not be set accurately because my stock ntp.conf requires working DNS resolution to reach the NTP servers. That sounds like a potential circular dependency to me. My workaround at the time was to look up 0.freebsd.pool.ntp.org on another system; stop ntpd; then do a ntpdate using the IP addresses to set the clock. Once the clock was set accurately, things were all hunky dory. Does anyone have any suggestion for an automatic way around this? I guess one way would be to put the IP address of an NTP server into my ntp.conf file, so at least one would be reachable without needing a working DNS? My main concern is for those systems like my Raspberry Pi and Beaglebone Black that don't have a battery-backed clock. I currently don't use local_unbound on those, but it seems like I'd encounter this problem routinely if I did. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
