Booting after make installworld takes ages [Was Re: Can't boot after make installworld]
On Sunday, 21 of March 2010 20:15:29 Krzysztof Dajka wrote: Hi, I'm having problem with upgrading my FreeBSD to RELENG_8. Building world and kernel went smoothly I can boot with new kernel, but after 'make installworld' I could boot my system. My system prints only: BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS drive E: is disk2 BIOS drive F: is disk3 | And freezes... I had a problem in march with booting after 'makeinstall' as stated above. It seems that I was impatient prejudged facts. For few months I was running newer kernel than world. After all I decided to upgrade whole system yesterday. After 'make installkernel', booting to new kernel went as usual. After 'make installworld' and rebooting it hangs at: BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS drive E: is disk2 BIOS drive F: is disk3 | After waiting 50 seconds it started booting. During this time my usb flash drive, which contains only bootcode blinked as crazy. I remembered that Dan Naumov told me The ZFS bootloader has been changed in 8-STABLE compared to 8.0-RELEASE. Reinstall your boot blocks. So this time I did: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 But this didn't help, booting is still painfully slow. -- Niniejsza wiadomość pochodzi z domeny @agora.pl, należącej do Grupy Kapitałowej Agory. Główne spółki wchodzące w skład Grupy Kapitałowej Agory to: Agora SA, ul. Czerska 8/10, 00-732 Warszawa; Numer identyfikacji podatkowej: PL 526-030-56-44; Miejsce zarejestrowania: Sąd Rejonowy dla m. st. Warszawy: Numer rejestru KRS: 59944; Kapitał zakładowy: 50.937.386 zł, wpłacony w całości. Agora - Poligrafia Sp. z o.o., ul. Towarowa 4, 43-110 Tychy; Numer identyfikacji podatkowej: PL 646-20-72-095; Miejsce zarejestrowania: Sąd Rejonowy w Katowicach Numer rejestru KRS: 72481; Kapitał zakładowy: 1.000.000,00 zł. Grupa Radiowa Agory Sp. z o.o., ul. Czerska 8/10, 00-732 Warszawa; Numer identyfikacji podatkowej: PL 521-289-70-03; Miejsce zarejestrowania: Sąd Rejonowy dla m. st. Warszawy Numer rejestru KRS: 126767; Kapitał zakładowy: 25.019.500,00 zł. Więcej informacji o spółkach na stronie: www.agora.pl Wiadomość jest przeznaczona wyłącznie dla zamierzonego adresata i może zawierać informacje o charakterze poufnym. W razie stwierdzenia, że odbiorcą miała być inna osoba prosimy poinformować nadawcę oraz niezwłocznie usunąć wiadomość. Wiadomość może nie stanowić oficjalnego stanowiska spółki Agora SA i nie być związana z jej działalnością. This message was sent from domain @agora.pl belonging to Agora Group. Principal companies in the Agora Group structure are: Agora SA, ul. Czerska 8/10, 00-732 Warszawa; Polish VAT and tax ID no.: PL 526-030-56-44; Place of registration: Regional Court for the Capital City of Warsaw; Registration no.: 59944; Share capital: PLN 50.937.386, fully paid-up. Agora - Poligrafia Sp. z o.o., ul. Towarowa 4, 43-110 Tychy; Polish VAT and tax ID no.: PL 646-20-72-095; Place of registration: Regional Court in Katowice; Registration no.: 72481; Share capital: PLN 1.000.000,00. Grupa Radiowa Agory Sp. z o.o., ul. Czerska 8/10, 00-732 Warszawa; Polish VAT and tax ID no.: PL 521-289-70-03; Place of registration: Regional Court for the Capital City of Warsaw; Registration no.: 126767; Share capital: PLN 25.019.500,00. For more information about our companies see site: www.agora.pl This message is for the intended recipient only and it may contain confidential information. If you receive this message in error, please immediately delete it and notify the sender. This message may not represent the official views of Agora SA and may not be related to its business. ___ 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: Locking a file backed mdconfig into memory
John Baldwin j...@freebsd.org writes: On Wednesday 02 June 2010 6:37:59 pm Dave Hayes wrote: John Baldwin j...@freebsd.org writes: Ok, if you are using a stock mfsroot from a release build, that should work fine. If you have built a custom mfsroot that is larger, then you may need to increase NKPT on i386. In very recent 7 and later you can do this by setting it to a new value in your kernel config. In older versions you can do this by manually adding a #define to set a new value of NKPT in opt_global.h or hacking on the source directly. Is this also true for amd64 (which is my particular target)? It might be. What is the panic you are seeing? I can't see the panic as it repeatedly scrolls across the console screen faster than I can read it. In this case the mfsroot is around 275MB. I have noticed that sometimes I can build an mfsroot that does not crash of this size. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org The opinions expressed above are entirely my own People usually oppose things because they are ignorant of them. ___ 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
atapicam issue
Hi, FreeBSD-stable clandestinely dropped support for my p-ata DVD drive some two or three weeks ago. The relevant devcontrol list-entry is still in its place, yet atapicam fails to create /dev/cd0. # camcontrol devlist HL-DT-ST DVD-RAM GH22NP20 1.02 at scbus0 target 0 lun 0 (pass0) dmesg reports: (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) --- Thanks in advance for your help! Hans ___ 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: Locking a file backed mdconfig into memory
On Friday 04 June 2010 5:37:14 am Dave Hayes wrote: John Baldwin j...@freebsd.org writes: On Wednesday 02 June 2010 6:37:59 pm Dave Hayes wrote: John Baldwin j...@freebsd.org writes: Ok, if you are using a stock mfsroot from a release build, that should work fine. If you have built a custom mfsroot that is larger, then you may need to increase NKPT on i386. In very recent 7 and later you can do this by setting it to a new value in your kernel config. In older versions you can do this by manually adding a #define to set a new value of NKPT in opt_global.h or hacking on the source directly. Is this also true for amd64 (which is my particular target)? It might be. What is the panic you are seeing? I can't see the panic as it repeatedly scrolls across the console screen faster than I can read it. In this case the mfsroot is around 275MB. I have noticed that sometimes I can build an mfsroot that does not crash of this size. Hmmm, I would just try increasing NKPT then. You might have to poke around in sys/amd64 to see what the default size is and how to tune it. -- John Baldwin ___ 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: SUJ Patches for 8.X ???
On 2010-06-04 01:24, David Rhodus wrote: Anyone have a SUJ patch set for 8.x ? http://www.andric.com/freebsd/suj/suj-stable8-r208287-1.diff.bz2 This backports SUJ from head to stable/8 (at r208799), by cherry-picking the following revisions: r207141 | jeff | 2010-04-24 09:05:35 +0200 (Sat, 24 Apr 2010) | 7 lines r207142 | pjd | 2010-04-24 09:36:33 +0200 (Sat, 24 Apr 2010) | 2 lines r207143 | pjd | 2010-04-24 09:54:49 +0200 (Sat, 24 Apr 2010) | 2 lines r207144 | pjd | 2010-04-24 09:58:59 +0200 (Sat, 24 Apr 2010) | 3 lines r207145 | jeff | 2010-04-24 09:59:45 +0200 (Sat, 24 Apr 2010) | 4 lines r207309 | jeff | 2010-04-28 09:26:41 +0200 (Wed, 28 Apr 2010) | 2 lines r207310 | jeff | 2010-04-28 09:57:37 +0200 (Wed, 28 Apr 2010) | 5 lines r207421 | jeff | 2010-04-30 06:21:22 +0200 (Fri, 30 Apr 2010) | 7 lines r207462 | edwin | 2010-05-01 11:05:06 +0200 (Sat, 01 May 2010) | 7 lines r207476 | emaste | 2010-05-01 20:56:45 +0200 (Sat, 01 May 2010) | 4 lines r207741 | jeff | 2010-05-07 10:20:56 +0200 (Fri, 07 May 2010) | 8 lines r207742 | jeff | 2010-05-07 10:45:21 +0200 (Fri, 07 May 2010) | 7 lines r208241 | jeff | 2010-05-18 03:45:28 +0200 (Tue, 18 May 2010) | 11 lines r208287 | jeff | 2010-05-19 08:18:01 +0200 (Wed, 19 May 2010) | 11 lines I have tested: - Applying this diff to stable/8 at r208799 (any other rev is NOT guaranteed to work, but there is a good chance, if not too far off) - Doing a full buildworld, buildkernel, installkernel, reboot, installworld and mergemaster. - Enabling SUJ on a big filesystem with tunefs -j enable. - Randomly resetting the box during a large copy operation on that filesystem, seeing the journal is replayed at boot time, and the filesystem recovered. That said, there is NO WARRANTY that this patch works properly. It could hose all your filesystems, and/or cause irreversible damage to your system. Most likely, even. You have been warned. :) Also, please do NOT bother Jeff Roberson about this, as he is probably busy enough supporting SUJ in head. :) Instead, direct any problem reports to me first, or to the freebsd-stable mailing list, if you prefer. ___ 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: Locking a file backed mdconfig into memory
On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: Hmmm, I would just try increasing NKPT then. You might have to poke around in sys/amd64 to see what the default size is and how to tune it. When Isilon did the stable/7 merge and amd64 default NKPT changed from 240 to 32 amd64 started having weird pmap issues during boot. At panic time the stack wasn't very useful, and I didn't finish debugging the issue since eventually I just had to get something working. We just reverted NKPT to 240 and it worked for us. I didn't see an anything in optsions.amd64 so I hard-coded it in amd64/include/pmap.h. Supposedly amd64 can deal with a small NKPT and grow dynamically, but it didn't seem to work for us. :-( Perhaps when we do the next merge project I'll have a few days to devote to debugging the root cause. Thanks, matthew ___ 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: atapicam issue
hans.da...@eml.cc wrote: FreeBSD-stable clandestinely dropped support for my p-ata DVD drive some two or three weeks ago. The relevant devcontrol list-entry is still in its place, yet atapicam fails to create /dev/cd0. # camcontrol devlist HL-DT-ST DVD-RAM GH22NP20 1.02 at scbus0 target 0 lun 0 (pass0) dmesg reports: (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) --- This is not fatal errors. It is normal. Could you boot with verbose messages and show full log? -- Alexander Motin ___ 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: SUJ Patches for 8.X ???
On Fri, Jun 04, 2010 at 05:00:25PM +0200, Dimitry Andric thus spake: On 2010-06-04 01:24, David Rhodus wrote: Anyone have a SUJ patch set for 8.x ? http://www.andric.com/freebsd/suj/suj-stable8-r208287-1.diff.bz2 This backports SUJ from head to stable/8 (at r208799), by cherry-picking the following revisions: r207141 | jeff | 2010-04-24 09:05:35 +0200 (Sat, 24 Apr 2010) | 7 lines r207142 | pjd | 2010-04-24 09:36:33 +0200 (Sat, 24 Apr 2010) | 2 lines r207143 | pjd | 2010-04-24 09:54:49 +0200 (Sat, 24 Apr 2010) | 2 lines r207144 | pjd | 2010-04-24 09:58:59 +0200 (Sat, 24 Apr 2010) | 3 lines r207145 | jeff | 2010-04-24 09:59:45 +0200 (Sat, 24 Apr 2010) | 4 lines r207309 | jeff | 2010-04-28 09:26:41 +0200 (Wed, 28 Apr 2010) | 2 lines r207310 | jeff | 2010-04-28 09:57:37 +0200 (Wed, 28 Apr 2010) | 5 lines r207421 | jeff | 2010-04-30 06:21:22 +0200 (Fri, 30 Apr 2010) | 7 lines r207462 | edwin | 2010-05-01 11:05:06 +0200 (Sat, 01 May 2010) | 7 lines r207476 | emaste | 2010-05-01 20:56:45 +0200 (Sat, 01 May 2010) | 4 lines r207741 | jeff | 2010-05-07 10:20:56 +0200 (Fri, 07 May 2010) | 8 lines r207742 | jeff | 2010-05-07 10:45:21 +0200 (Fri, 07 May 2010) | 7 lines r208241 | jeff | 2010-05-18 03:45:28 +0200 (Tue, 18 May 2010) | 11 lines r208287 | jeff | 2010-05-19 08:18:01 +0200 (Wed, 19 May 2010) | 11 lines I have tested: - Applying this diff to stable/8 at r208799 (any other rev is NOT guaranteed to work, but there is a good chance, if not too far off) - Doing a full buildworld, buildkernel, installkernel, reboot, installworld and mergemaster. - Enabling SUJ on a big filesystem with tunefs -j enable. - Randomly resetting the box during a large copy operation on that filesystem, seeing the journal is replayed at boot time, and the filesystem recovered. That said, there is NO WARRANTY that this patch works properly. It could hose all your filesystems, and/or cause irreversible damage to your system. Most likely, even. You have been warned. :) Also, please do NOT bother Jeff Roberson about this, as he is probably busy enough supporting SUJ in head. :) Instead, direct any problem reports to me first, or to the freebsd-stable mailing list, if you prefer. ___ 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 I wasn't sure what SUJ was, so I looked it up and it sounds like a great feature to come to FreeBSD. I also found this email from Jeff that may be a good resource as well. http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014811.html -j ___ 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: if_sge related panics
On Fri, Jun 04, 2010 at 07:52:19AM +0300, Nikolay Denev wrote:
On Jun 4, 2010, at 3:35 AM, Pyun YongHyeon wrote:
On Thu, Jun 03, 2010 at 09:29:20AM +0300, Nikolay Denev wrote:
On May 24, 2010, at 8:12 PM, Pyun YongHyeon wrote:
On Mon, May 24, 2010 at 09:48:33AM -0400, John Baldwin wrote:
On Monday 24 May 2010 6:35:01 am Nikolay Denev wrote:
On May 24, 2010, at 8:57 AM, Nikolay Denev wrote:
Hi,
Recently I started to experience a if_sge(4) related panic.
It happens almost every time I try to download a torrent file for
example.
Copying of large files over NFS seem not to trigger it, but I haven't
tested extensively.
Here is the panic message :
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x8
fault code = supervisor write data, page
not present
instruction pointer= 0x20:0x80230413
stack pointer = 0x28:0xff80001e9280
frame pointer = 0x28:0xff80001e9510
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= 12 (irq19: sge0)
trap number= 12
panic: page fault
cpuid = 0
Uptime: 1d20h56m20s
Cannot dump. Device not defined or unavailable
Automatic reboot in 15 seconds - press a key on the console to abort
Sleeping thread (tid 100039, pid 12) owns a non-sleepable lock
My swap is on a zvol, so I don't have dump. I'll try to attach a disk
on the eSATA port and dump there if needed.
Here is some info from the crashdump :
(kgdb) #0 doadump () at pcpu.h:223
#1 0x802fb149 in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:416
#2 0x802fb57c in panic (fmt=0x8055d564 %s)
at /usr/src/sys/kern/kern_shutdown.c:590
#3 0x805055b8 in trap_fatal (frame=0xff000288a3e0,
eva=Variable eva is not available.
)
at /usr/src/sys/amd64/amd64/trap.c:777
#4 0x805059dc in trap_pfault (frame=0xff80001e91d0,
usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:693
#5 0x805061c5 in trap (frame=0xff80001e91d0)
at /usr/src/sys/amd64/amd64/trap.c:451
#6 0x804eb977 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:223
#7 0x80230413 in sge_start_locked (ifp=0xff000270d800)
at /usr/src/sys/dev/sge/if_sge.c:1591
Try this. sge_encap() can sometimes return an error with m_head set to
NULL:
Thanks John. Committed in r208512.
Index: if_sge.c
===
--- if_sge.c (revision 208375)
+++ if_sge.c (working copy)
@@ -1588,7 +1588,8 @@
if (m_head == NULL)
break;
if (sge_encap(sc, m_head)) {
-IFQ_DRV_PREPEND(ifp-if_snd, m_head);
+if (m_head != NULL)
+IFQ_DRV_PREPEND(ifp-if_snd, m_head);
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
break;
}
--
John Baldwin
After the patch I experienced several network outages (ping reporting no
buffer space available)
that were resolved by ifconfig down/up of the sge(4) interface.
Because I don't have access to sge(4) controllers I never had chance
to run it. Does ping(8) generates no buffer space available when
the system is in idle state? Could you show me more information on
how you checked network outages?
It happened 4-5 times recently. I didn't do extensive investigation, but yes,
ping
returned no buffer space avail when I tried pinging from the machine itself.
It was unreachable from other hosts on the network.
I'm not sure what you bean by idle state but there was a torrent client
running
on the machine, which printed errors about inability to reach peers.
If system is under heavy TX load(e.g. 64bytes UDP test), ping(8)
may show that message.
I can see that most of the other drivers that handle XXX_encap() returning
m_head pointing NULL, break when this condition
Yes, most drivers written/touched by me behaves like that.
is hit: i.e. :
Index: if_sge.c
===
--- if_sge.c (revision 208375)
+++ if_sge.c (working copy)
@@ -1588,7 +1588,8 @@
if (m_head == NULL)
break;
if (sge_encap(sc, m_head)) {
- IFQ_DRV_PREPEND(ifp-if_snd, m_head);
+ if (m_head == NULL)
+ break;
IFQ_DRV_PREPEND(ifp-if_snd, m_head);
ifp-if_drv_flags |=
Re: Locking a file backed mdconfig into memory
Matthew D Fleming wrote: On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: Hmmm, I would just try increasing NKPT then. You might have to poke around in sys/amd64 to see what the default size is and how to tune it. When Isilon did the stable/7 merge and amd64 default NKPT changed from 240 to 32 amd64 started having weird pmap issues during boot. At panic time the stack wasn't very useful, and I didn't finish debugging the issue since eventually I just had to get something working. We just reverted NKPT to 240 and it worked for us. I didn't see an anything in optsions.amd64 so I hard-coded it in amd64/include/pmap.h. Supposedly amd64 can deal with a small NKPT and grow dynamically, but it didn't seem to work for us. :-( Perhaps when we do the next merge project I'll have a few days to devote to debugging the root cause. NKPT controls the number of page table pages that are initially allocated at the bottom of the top 2GB of the kernel address space. However, the vast majority of the kernel address space, 510GB in FreeBSD =7.3, is below these page table pages. The page table pages for this region are dynamically allocated as needed. If you're booting a kernel and modules greater than 64GB in size, then I can certainly see why you would need to increase NKPT. John, is there some way to know at boot time how big the kernel and modules were? Then, we could probably eliminate NKPT. Alan ___ 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: Locking a file backed mdconfig into memory
On Friday 04 June 2010 1:58:13 pm Alan Cox wrote: Matthew D Fleming wrote: On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: Hmmm, I would just try increasing NKPT then. You might have to poke around in sys/amd64 to see what the default size is and how to tune it. When Isilon did the stable/7 merge and amd64 default NKPT changed from 240 to 32 amd64 started having weird pmap issues during boot. At panic time the stack wasn't very useful, and I didn't finish debugging the issue since eventually I just had to get something working. We just reverted NKPT to 240 and it worked for us. I didn't see an anything in optsions.amd64 so I hard-coded it in amd64/include/pmap.h. Supposedly amd64 can deal with a small NKPT and grow dynamically, but it didn't seem to work for us. :-( Perhaps when we do the next merge project I'll have a few days to devote to debugging the root cause. NKPT controls the number of page table pages that are initially allocated at the bottom of the top 2GB of the kernel address space. However, the vast majority of the kernel address space, 510GB in FreeBSD =7.3, is below these page table pages. The page table pages for this region are dynamically allocated as needed. If you're booting a kernel and modules greater than 64GB in size, then I can certainly see why you would need to increase NKPT. 64GB seems like a lot of address space, I would not expect that to be completely used by kernel and modules. I think earlier in the thread someone said they had problems with a mere 295MB mfsroot. John, is there some way to know at boot time how big the kernel and modules were? Then, we could probably eliminate NKPT. I think the loader knows, so it could pass that info to the kernel. -- John Baldwin ___ 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: Locking a file backed mdconfig into memory
On 6/4/2010 1:53 PM, John Baldwin wrote: On Friday 04 June 2010 1:58:13 pm Alan Cox wrote: Matthew D Fleming wrote: On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote: Hmmm, I would just try increasing NKPT then. You might have to poke around in sys/amd64 to see what the default size is and how to tune it. When Isilon did the stable/7 merge and amd64 default NKPT changed from 240 to 32 amd64 started having weird pmap issues during boot. At panic time the stack wasn't very useful, and I didn't finish debugging the issue since eventually I just had to get something working. We just reverted NKPT to 240 and it worked for us. I didn't see an anything in optsions.amd64 so I hard-coded it in amd64/include/pmap.h. Supposedly amd64 can deal with a small NKPT and grow dynamically, but it didn't seem to work for us. :-( Perhaps when we do the next merge project I'll have a few days to devote to debugging the root cause. NKPT controls the number of page table pages that are initially allocated at the bottom of the top 2GB of the kernel address space. However, the vast majority of the kernel address space, 510GB in FreeBSD =7.3, is below these page table pages. The page table pages for this region are dynamically allocated as needed. If you're booting a kernel and modules greater than 64GB in size, then I can certainly see why you would need to increase NKPT. 64GB seems like a lot of address space, I would not expect that to be completely used by kernel and modules. I think earlier in the thread someone said they had problems with a mere 295MB mfsroot. Oops. I meant to say 64MB. :-) John, is there some way to know at boot time how big the kernel and modules were? Then, we could probably eliminate NKPT. I think the loader knows, so it could pass that info to the kernel. ___ 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
