Re: r268621: panic: shadowed tmpfs v_object [with dump]
Bezüglich Sergey V. Dyatko's Nachricht vom 25.07.2014 07:36 (localtime): On Wed, 23 Jul 2014 22:56:46 +0200 Mattia Rossi mattia.rossi.m...@gmail.com wrote: Got the same panic, is this fix getting committed? Or has it already been committed? r269053 Great. But it's not MFCd yet. 10.1 needs this :-) -Harry signature.asc Description: OpenPGP digital signature
zfs ARC behaviour, Bug 187594
Hello, according to several reports, Karl Denningers (reworked) patch improoves the ARC memory-release behaviour a lot. It's discussed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594#c10 I guess many useres were happy if this patch would make it into 10.1. But it isn't in -current yet. Are there still any objections? Thanks, -Harry signature.asc Description: OpenPGP digital signature
r269471 makes unusable VT console
Hi, After r269471 was committed, a bunch of underscores make unusable VT console. As a workaround, I've added in /boot/loader.conf hw.vga.textmode=1 Someone know if this issue have been solved on a recent revision? Regards, -- Carlos Jacobo Puga Medina c...@fbsd.es ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Child suspend/resume
Hi Alexandr, Thanks. I got another confirmation that it didn't work, and may have found the cause. I have another patch that you can find at https://phabric.freebsd.org/D590 which fixes a typo that I had made. Could you try that? (Added current@ so everyone else sees this as well). Thanks! - Justin On Tue, 12 Aug 2014 11:18:29 +0300 Alexandr Krivulya shur...@shurik.kiev.ua wrote: Hi, Justin After applying your patch my thinkpad e530 (FreeBSD 11.0-CURRENT, amd64) doesn't resume any more - screen remains black. 11.08.2014 08:30, Justin Hibbits (by way of Justin Hibbits chmeeed...@gmail.com) пишет: Hi all, The attached patch is completely untested, due to lack of existing suspendable hardware (no x86 machines). It does compile cleanly against head, though. I don't think it should change any behavior, I tried to keep the essence of the code path the same. It was suggested that I break up my multipass suspend/resume code into incremental parts, so this is part one. It adds a BUS_SUSPEND_CHILD/BUS_RESUME_CHILD, as well as helper functions, bus_generic_suspend_child()/bus_generic_resume_child(), and modifies the PCI driver to use this new facility. I'd like some feedback, and testing of this, to make sure I didn't break anything. Thanks, Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Link for FreeBSD mirrors in snapshots messages
Dears All , Is it possible to include the link for FreeBSD mirrors list http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html into New FreeBSD snapshots available : ... messages ? This link will prevent a search of this list and will encourage use of mirrors by making it available easily . Thank you very much .. Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 makes unusable VT console
On 08/12/14 05:41, Carlos Jacobo Puga Medina wrote: Hi, After r269471 was committed, a bunch of underscores make unusable VT console. As a workaround, I've added in /boot/loader.conf hw.vga.textmode=1 Someone know if this issue have been solved on a recent revision? Regards, I believe it's still broken. There's a related PR at http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would you mind reverting this reversion? It seems to have created a lot of problems. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Booting a SuperMicro Superserver
A continuing issue (with 9.1 previously and now 10) is that FreeBSD occasionally (or always) seems to boot from the 2nd installed drive rather than the first. I'd be happy to debug this, but I have no idea if it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys are hard to work with and fairly arrogant if you don't specifically isolate something. The scenario occurs when ada0 is upgraded and has an incompatible kernel with other code on drive ada1. (note that ada1 is a backup of the pre-upgrade ada0, so it's fstab points to ada0 for mount points). The system will boot and then modules will fail to load. It loads the kernel from ada1 and then mounts partitions from ada0; old kernel and newer modules. The problem is resolved by popping the 2nd drive. So there is nothing wrong with ada0 to cause it to bounce to ada1. My question: What would cause the system to boot from ada1 instead of ada0? Bios or Bootcode? Thanks. BC ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booting a SuperMicro Superserver
The bios only gives you one choice for HDD. You can't select one of the 4 drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3. BC On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net wrote: On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote: A continuing issue (with 9.1 previously and now 10) is that FreeBSD occasionally (or always) seems to boot from the 2nd installed drive rather than the first. I'd be happy to debug this, but I have no idea if it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys are hard to work with and fairly arrogant if you don't specifically isolate something. The scenario occurs when ada0 is upgraded and has an incompatible kernel with other code on drive ada1. (note that ada1 is a backup of the pre-upgrade ada0, so it's fstab points to ada0 for mount points). The system will boot and then modules will fail to load. It loads the kernel from ada1 and then mounts partitions from ada0; old kernel and newer modules. The problem is resolved by popping the 2nd drive. So there is nothing wrong with ada0 to cause it to bounce to ada1. My question: What would cause the system to boot from ada1 instead of ada0? Bios or Bootcode? BIOS, most likely. If the disk controller in question is onboard you should be able to specify which disk(s) and what order they will be booted from. If not, you'll need to just say disk controller in the BIOS boot order then go to the controllers BIOS to say which disk(s) to boot from and in what order. I have recent experience with a SuperMicro box and an LSI controller; the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. :) JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booting a SuperMicro Superserver
On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote: A continuing issue (with 9.1 previously and now 10) is that FreeBSD occasionally (or always) seems to boot from the 2nd installed drive rather than the first. I'd be happy to debug this, but I have no idea if it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys are hard to work with and fairly arrogant if you don't specifically isolate something. The scenario occurs when ada0 is upgraded and has an incompatible kernel with other code on drive ada1. (note that ada1 is a backup of the pre-upgrade ada0, so it's fstab points to ada0 for mount points). The system will boot and then modules will fail to load. It loads the kernel from ada1 and then mounts partitions from ada0; old kernel and newer modules. The problem is resolved by popping the 2nd drive. So there is nothing wrong with ada0 to cause it to bounce to ada1. My question: What would cause the system to boot from ada1 instead of ada0? Bios or Bootcode? BIOS, most likely. If the disk controller in question is onboard you should be able to specify which disk(s) and what order they will be booted from. If not, you'll need to just say disk controller in the BIOS boot order then go to the controllers BIOS to say which disk(s) to boot from and in what order. I have recent experience with a SuperMicro box and an LSI controller; the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. :) JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booting a SuperMicro Superserver
On Aug 12, 2014, at 12:09 PM, Barney Cordoba barney_cord...@yahoo.com wrote: On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net wrote: On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote: A continuing issue (with 9.1 previously and now 10) is that FreeBSD occasionally (or always) seems to boot from the 2nd installed drive rather than the first. I'd be happy to debug this, but I have no idea if it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys are hard to work with and fairly arrogant if you don't specifically isolate something. The scenario occurs when ada0 is upgraded and has an incompatible kernel with other code on drive ada1. (note that ada1 is a backup of the pre-upgrade ada0, so it's fstab points to ada0 for mount points). The system will boot and then modules will fail to load. It loads the kernel from ada1 and then mounts partitions from ada0; old kernel and newer modules. The problem is resolved by popping the 2nd drive. So there is nothing wrong with ada0 to cause it to bounce to ada1. My question: What would cause the system to boot from ada1 instead of ada0? Bios or Bootcode? BIOS, most likely. If the disk controller in question is onboard you should be able to specify which disk(s) and what order they will be booted from. If not, you'll need to just say disk controller in the BIOS boot order then go to the controllers BIOS to say which disk(s) to boot from and in what order. I have recent experience with a SuperMicro box and an LSI controller; the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. :) The bios only gives you one choice for HDD. You can't select one of the 4 drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3. There may be a separate option controlling hard drive boot order, and/or there may be a completely separate BIOS program for your drive controller with its own hotkey. JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booting a SuperMicro Superserver
On 2014-08-12 14:09, Barney Cordoba wrote: The bios only gives you one choice for HDD. You can't select one of the 4 drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3. BC On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net wrote: On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote: A continuing issue (with 9.1 previously and now 10) is that FreeBSD occasionally (or always) seems to boot from the 2nd installed drive rather than the first. I'd be happy to debug this, but I have no idea if it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys are hard to work with and fairly arrogant if you don't specifically isolate something. The scenario occurs when ada0 is upgraded and has an incompatible kernel with other code on drive ada1. (note that ada1 is a backup of the pre-upgrade ada0, so it's fstab points to ada0 for mount points). The system will boot and then modules will fail to load. It loads the kernel from ada1 and then mounts partitions from ada0; old kernel and newer modules. The problem is resolved by popping the 2nd drive. So there is nothing wrong with ada0 to cause it to bounce to ada1. My question: What would cause the system to boot from ada1 instead of ada0? Bios or Bootcode? BIOS, most likely. If the disk controller in question is onboard you should be able to specify which disk(s) and what order they will be booted from. If not, you'll need to just say disk controller in the BIOS boot order then go to the controllers BIOS to say which disk(s) to boot from and in what order. I have recent experience with a SuperMicro box and an LSI controller; the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. :) JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org There is usually a second menu after you select 'HDD' in the boot order menu, something like 'HDD Boot Priority' that lets you select the correct disk to boot from http://s1121.photobucket.com/user/SleeperPro/media/BIOSBoot.jpg.html So after you select 'HDD in the 'boot device priority' menu, go to the 'hard disk drives' menu and set the order of the drives. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: PostgreSQL performance on FreeBSD
On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote: Hi! On 16 July 2014 06:29, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote: Hi, I did some measurements and hacks to see about the performance and scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD Foundation. The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf. The uncommitted patches, referenced in the article, are available as https://kib.kiev.ua/kib/pig1.patch.txt https://kib.kiev.ua/kib/patch-2 A followup to the original paper. Most importantly, I identified the cause for the drop on the graph after the 30 clients, which appeared to be the debugging version of malloc(3) in libc. Also there are some updates on the patches. New version of the paper is available at https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf The changes are marked as 'update for version 2.0'. Would you mind trying a default (non-PRODUCTION) build, but with junk filling turned off? adrian@adrian-hackbox:~ % ls -l /etc/malloc.conf lrwxr-xr-x 1 root wheel 10 Jun 24 04:37 /etc/malloc.conf - junk:false That fixes almost all of the malloc debug performance issues that I see without having to recompile. I'd like to know if you see any after that. OTOH, I have actually seen junk profiling _improve_ performance in certain cases as it forces promotion of allocated pages to superpages since all pages are dirtied. (I have a local hack that adds a new malloc option to explicitly memset() new pages allocated via mmap() that gives the same benefit without the junking overheadon each malloc() / free(), but it does increase physical RAM usage.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsd.sys.mk [-Wno-uninitialized]
On Tuesday, July 15, 2014 5:25:50 am Hans Petter Selasky wrote: On 07/05/14 15:10, David Chisnall wrote: On 5 Jul 2014, at 14:07, Dimitry Andric d...@freebsd.org wrote: Interestingly, -Wno-uninitialized has been in bsd.sys.mk since r76861, and the accompanying comment (XXX Delete -Wuninitialized by default for now -- the compiler doesn't always get it right) has never been changed. :-) It is probably time to re-enable that warning after 13 years, at least. It probably only wants enabling for clang. GCC (at least, GCC 4.2.1) performs this analysis based on analyses run by the optimisers and so the warnings are dependent on optimisation level. David Hi, Is someone working on this? If not, at least add a PR so it is harder to drop? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
I believe it's still broken. There's a related PR at http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would you mind reverting this reversion? It seems to have created a lot of problems. -Nathan Yes, I think that ray@ is around here somewhere to fix this :P Regards, -- Carlos Jacobo Puga Medina c...@fbsd.es ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PostgreSQL performance on FreeBSD
On 12 August 2014 11:09, John Baldwin j...@freebsd.org wrote: On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote: Hi! On 16 July 2014 06:29, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote: Hi, I did some measurements and hacks to see about the performance and scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD Foundation. The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf. The uncommitted patches, referenced in the article, are available as https://kib.kiev.ua/kib/pig1.patch.txt https://kib.kiev.ua/kib/patch-2 A followup to the original paper. Most importantly, I identified the cause for the drop on the graph after the 30 clients, which appeared to be the debugging version of malloc(3) in libc. Also there are some updates on the patches. New version of the paper is available at https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf The changes are marked as 'update for version 2.0'. Would you mind trying a default (non-PRODUCTION) build, but with junk filling turned off? adrian@adrian-hackbox:~ % ls -l /etc/malloc.conf lrwxr-xr-x 1 root wheel 10 Jun 24 04:37 /etc/malloc.conf - junk:false That fixes almost all of the malloc debug performance issues that I see without having to recompile. I'd like to know if you see any after that. OTOH, I have actually seen junk profiling _improve_ performance in certain cases as it forces promotion of allocated pages to superpages since all pages are dirtied. (I have a local hack that adds a new malloc option to explicitly memset() new pages allocated via mmap() that gives the same benefit without the junking overheadon each malloc() / free(), but it does increase physical RAM usage.) Hm. this isn't a jemalloc config option? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libthr and main thread stack size
On 08 Aug 2014, at 13:22, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Aug 08, 2014 at 12:32:56PM +0400, Ivan A. Kosarev wrote: On 08/08/2014 09:28 AM, Konstantin Belousov wrote: On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: Hello, According to libthr's thr_init.c (the 9.2 version) init_main_thread() allocates s.c. red zone below the main stack in order to protect other stacks. The size of the main stack is determined by the _thr_stack_initial variable that is declared extern though it doesn't seem it can be changed. The value of the variable is set to 4M on 64-bit platforms which is obviously not sufficient for the most of real programs. Can anyone please confirm that there is no way to increase the stack size for the main thread and thus any program linked against libthr has only a few megabytes of stack memory for its main thread--whatever the system stack size (ulimit -s) is set to? Yes, there is no way to change the main thread stack clamping. Could you provide a reasonable use case for the 4MB stack ? Traversing trees with recursive functions or on-stack grammar parsers? I just ran into a similar issue while running one of clang 3.5's test cases (see http://llvm.org/PR20635 ). On i386, it used up approximately 2MB of stack, then ran into the guard page, and segfaulted. I was quite amazed to find out that ulimit -s didn't help at all, until I remembered this thread. :-) Anyway, I somewhat sympathize to the idea to stop clamping the main thread stack, and to not reuse it for other threads stack carving. This also means that non-main threads stack allocator should stop tracking the explicit location for the stacks and rely on vm mmap(2) base selection instead. Yes, that would solve the problem. I do not know the motivations why the current scheme of stacks allocation was chosen. The changes do not look too involved. In fact, I can resonably explain the current behaviour. The motivation seems to come from desire to interpret the RLIMIT_STACK as the global limit to the stack usage by all threads. From this PoV, it becomes clean why the other thread stacks are carved from the main stack. Linux seems to interpret it as the default stack size for *each* new thread (so I guess that also includes the main thread, if Linux has such a concept): ''On Linux/x86-32, the default stack size for a new thread is 2 megabytes. Under the NPTL threading implementation, if the RLIMIT_STACK soft resource limit at the time the program started has any value other than unlimited, then it determines the default stack size of new threads.'' Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the main thread stack left as is, and other threads allocate stack below the area of RLIMIT_STACK. Try it. I do not want to set this behaviour as default. It works for my case, thanks. I'm not sure if we should use Linux's behavior of using RLIMIT_STACK for *all* threads, but I would definitely expect that value for the main thread by default... -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Booting a SuperMicro Superserver
On Tue, Aug 12, 2014 at 02:25:29PM -0400, Allan Jude wrote: On 2014-08-12 14:09, Barney Cordoba wrote: The bios only gives you one choice for HDD. You can't select one of the 4 drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3. BC On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net wrote: On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote: A continuing issue (with 9.1 previously and now 10) is that FreeBSD occasionally (or always) seems to boot from the 2nd installed drive rather than the first. I'd be happy to debug this, but I have no idea if it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys are hard to work with and fairly arrogant if you don't specifically isolate something. The scenario occurs when ada0 is upgraded and has an incompatible kernel with other code on drive ada1. (note that ada1 is a backup of the pre-upgrade ada0, so it's fstab points to ada0 for mount points). The system will boot and then modules will fail to load. It loads the kernel from ada1 and then mounts partitions from ada0; old kernel and newer modules. The problem is resolved by popping the 2nd drive. So there is nothing wrong with ada0 to cause it to bounce to ada1. My question: What would cause the system to boot from ada1 instead of ada0? Bios or Bootcode? BIOS, most likely. If the disk controller in question is onboard you should be able to specify which disk(s) and what order they will be booted from. If not, you'll need to just say disk controller in the BIOS boot order then go to the controllers BIOS to say which disk(s) to boot from and in what order. I have recent experience with a SuperMicro box and an LSI controller; the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. :) There is usually a second menu after you select 'HDD' in the boot order menu, something like 'HDD Boot Priority' that lets you select the correct disk to boot from http://s1121.photobucket.com/user/SleeperPro/media/BIOSBoot.jpg.html So after you select 'HDD in the 'boot device priority' menu, go to the 'hard disk drives' menu and set the order of the drives. I've also seen BIOS to scan complete boot order HDD for GPT and then MBR. Noticed this when seting up a gmirror server in the old way: Do lazy install on disk0 and boot. setup disk1 as gmirror/dedicated disk with it's fake MBR. Shutdown and physically swap disks, then gmirror the lazy installation disk. But after swapping disks the BIOS then bootet from disk1 with GPT, although the new gmirror/MBR disk0 was first in boot order. After gmirror sync disk1 the BIOS booted from disk0, so it really was the GPT why it prefered booting from second disk in bootorder. Think it was a Intel board, but can't say for sure. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booting a SuperMicro Superserver
So there is. But I still don't see how this can happen. The default is P0 first and P1 second and it certainly wasn't changed, but it still seems to boot from the second drive when both are present. It's almost like there's some logic that says drive P1 has the same kernel booted the last time, so lets use that instead of the new one in P0. It's happened more than once in remote locations that is a PIA to pop the 2nd drive. I'll have to try a few things. Easy enough to build a new kernel and see which it boots On Tuesday, August 12, 2014 2:24 PM, John Nielsen li...@jnielsen.net wrote: On Aug 12, 2014, at 12:09 PM, Barney Cordoba barney_cord...@yahoo.com wrote: On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net wrote: On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote: A continuing issue (with 9.1 previously and now 10) is that FreeBSD occasionally (or always) seems to boot from the 2nd installed drive rather than the first. I'd be happy to debug this, but I have no idea if it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys are hard to work with and fairly arrogant if you don't specifically isolate something. The scenario occurs when ada0 is upgraded and has an incompatible kernel with other code on drive ada1. (note that ada1 is a backup of the pre-upgrade ada0, so it's fstab points to ada0 for mount points). The system will boot and then modules will fail to load. It loads the kernel from ada1 and then mounts partitions from ada0; old kernel and newer modules. The problem is resolved by popping the 2nd drive. So there is nothing wrong with ada0 to cause it to bounce to ada1. My question: What would cause the system to boot from ada1 instead of ada0? Bios or Bootcode? BIOS, most likely. If the disk controller in question is onboard you should be able to specify which disk(s) and what order they will be booted from. If not, you'll need to just say disk controller in the BIOS boot order then go to the controllers BIOS to say which disk(s) to boot from and in what order. I have recent experience with a SuperMicro box and an LSI controller; the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. :) The bios only gives you one choice for HDD. You can't select one of the 4 drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3. There may be a separate option controlling hard drive boot order, and/or there may be a completely separate BIOS program for your drive controller with its own hotkey. JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
