Re: machine won't start
Been down that path, and almost lost my sanity. The code that probes for disks via the BIOS (in openbsd's boot loader) is just as sensitive, causing hangs, etc. Writing that was... interesting. The partition table entries are just about as sensitive (as you've found out), and the joy is all the different ways that BIOS will interpret values (and hang on values). Even better, I've seen BIOSen that would change the geometry information returned on (a USB stick was common) based on the partition table information that they may or may not have read from the first 512 bytes of a disk. Yuck. -Toby. On Wed, Jul 4, 2012 at 12:35 PM, Matthew Dillon dil...@apollo.backplane.com wrote: : I consider it almost a lost cause. : : :Don't get it: trying to fix this is a lost cause? Yah, because if we fix it for one BIOS we break it for another. Hence, a lost cause. There is no single fix which covers all BIOSs. -Matt
Re: btrfs and atime - is that similar with Hammer?
One solution I didn't see, is to pull atime out of the filesystem metadata, and make it a database within it's own file on the filesystem. This does have a number of benefits. For one, the atimes for all files are collected within a simple file, which will get snapshot'ed with other files. And for two, the updates to this invisible file would be cached, and not having to deal with a full sync-round-trip (as in the old ffs filesystems, yes, some have solved this issue). The extra space within the inode could be used for create-time, which can be useful at times. -Toby. On Wed, Jun 20, 2012 at 3:44 AM, Tomas Bodzar tomas.bod...@gmail.com wrote: See https://lwn.net/Articles/499293/
Hang right after BIOS CD is cd0 on booting dfly-i386-3.0.2_REL.iso
Hello all, I'm trying to boot up the 3.0.2 CD ISO (to fix a boot issue with the /boot partition) on my VM, and for some reason, I can't seem to make the ISO get past the line: BIOS CD is cd0 If I add a floppy to the mix, the machine does not get past the line: BIOS CD is cd0 BIOS drive A: is disk0 It almost seems as if some sort of BIOS style probing for disks is hanging early in the boot process. Is there a way for me to get around this? My first guess would be static int bd_int13probe(struct bdinfo *bd) in sys/boot/pc32/libi386/biosdisk.c. Back when I did the int 0x13 probing of disks in OpenBSD, I found a number BIOS that would simply hang when probing non-existant disks. Any chance someone could put some debug printf's() in there before and after the bios calls, and point me at an ISO I can try to boot? -Toby. PS: I've gotta get me a release/boot environment setup...
Re: Merry X-Mas and 3.0 release after the holidays - date not yet decided
Not that my voice has any weight, but I applaud and welcome a 3.0 release. :) -Toby. On Sun, Dec 25, 2011 at 4:01 PM, Matthew Dillon dil...@apollo.backplane.com wrote: Hello everyone! First, I apologize for the aborted 2.12 release. We got as far as rolling it but I decided to make a real push to try to fix the occassional random seg-fault bug that we were still seeing on 64-bit at the time. The seg-fault issue has now been resolved, I posted an exhaustive synopsis to the kernel@ list just a moment ago. Basically it appears to be an AMD cpu bug and not a DragonFly bug. We don't have final confirmation that it isn't a DragonFly bug because it is so sensitive to %rip and %rsp values that reproducing the environment to test it on other OSs (even FreeBSD) is difficult, but I'm 99% certain it's an AMD bug. Add a single NOP instruction to the end of one routine in the gcc-4.4 codebase appears to work around the bug. So moving on to rolling an official release... (1) Through past experience we will NOT do a release during the holidays! So everyone please enjoy Christmas and New Years! (2) I would like to call the release 3.0. Why? Because while spending the last ~1-2 months tracking down the cpu bug a whole lot of other work has gone into the kernel including major network protocol stack work and major SMP work. My contribution to the SMP work was to completely rewrite the 64-bit pmap, VM object handling code, and VM fault handling code, as well as some other stuff. This has resulted in a phenominal improvement in concurrency and in particular concurrent compilations or anything that takes a lot of page faults. SMP contention was completely removed from the page fault path and for most VM related operations, and almost completely removed from the exec*() path. Other related work has continued to improve mysql and postgresql numbers as well. (3) Release date is as-yet undecided. It will probably be mid-February to end-February in order to synchronize with the pkgsrc 2011-Q4 release and give things time to settle. The release meisters will be discussing it on IRC. I will say that there are NO serious showstoppers this time. I'd like us to take our time and make this the best release we've ever done! -Matt
