Re: 32GB limit per swap device?
Two additional pieces of information. The original limitation was more related to DEV_BSIZE calculations for the buf/bio, which is now 64-bits and thus not applicable, though you probably need some preemptive casts to ensure the multiplication is done in 64-bits. There was also another intermediate calculation overflow in the swap radix-tree code which had to be fixed to be able to use the full range... I think w/simple casts. I haven't looked it up but there should be a few commits in the DFly codebase that can be referenced. Second item: The main physical memory use is not the radix tree bitmap code for the swap code, but instead the auxillary data structure used to store the swapblk information which is associated with the vm_object structure. This structure contains a short array of swap block assignments (as a memory optimization to reduce header overhead) and it is these fields which you really want to keep 32-bits (unless you want the ~1MB per ~1GB of swap to become ~2MB per ~1GB of swap in physical memory overhead). The block number is in page-sized chunks so the practical limit is still ~4TB, with a further caveat below. The further caveat is that the actual limitation for the radix tree is 0x4000 blocks, which is 1/4 the full range or ~1TB, so the actual limitation for the (fixed) original radix tree code is ~1TB rather than ~4TB. This restricted range is due to some shift operators used in the radix tree code that I didn't want to make more complicated. So, my recommendation is to fix the intermediate calculations and keep the swapblk related blockno fields 32 bits. The preallocation for the vm_object's auxillary structure must be large enough to actually be able to fill up swap and assign all the swap blocks. This is what eats the physical memory (4 bytes per 4K = 1024x storage factor). The radix tree bitmap itself winds up eating only around 2 bits per swap block in total overhead. So the auxillary structure is the main culprit. You definitely want to keep those block number fields in the aux structure 32 bits. The practical limit of ~1TB of swap requires ~1GB of preallocated physical memory with a 32 bit block number field. That would become ~2GB of preallocated memory if 64 bit block numbers were used instead, for no gain other than wasting physical memory. Ok, nobody is likely to actually need that much swap but people might be surprised, there are a lot of modern-day uses for swap space that don't involve heavy paging of anonymous memory. -Matt ___ 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: 32GB limit per swap device?
On 08/22/2011 21:36, Matthew Dillon wrote: The limitation was ONLY due to a *minor* 32-bit integer overflow in one or two *intermediate* calculations in the radix tree code, which I long ago fixed in DragonFly. Just find the changes in the DFly codebase and determine if they need to be applied. The swap space radix code (which I wrote long ago) is in page-sized blocks, so you actually probably want to keep using a 32-bit integer for the block number there to keep the physical memory reservation required for the radix tree low. If you just pop the base block id up to 64 bits without adjusting the radix code to overlay a 64 bit bitmap on it you waste a lot of physical memory for the same amount of swap reservation. Unfortunately, in FreeBSD, when daddr_t was increased to 64 bits a few years ago, the bitmap size was not increased. So, we have been wasting about half the space used by the blist structure for some time now. I expect that we'll fix this after the current code freeze ends. However, as Alexander observed, the primary reason for the 32GB limit on the size of a swap partition was artificial. The limit was being implemented in the wrong place. It was being performed before the conversion from 512 byte blocks to 4KB pages. Since a blist is managing swap space at the granularity of pages and the limit is imposed by the blist code, the check should come after the conversion. Just by moving the check to its proper place, the effective limit can be increased from 32GB to 256GB. Kostik committed such a change earlier today. 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
-m32 on freeBSD 8.2r amd64
We are trying to compile i386 on a FreeBSD 8.2r amd64. we are getting an error stating that libstdc++.so.6, is missing. COMPACT6x and COMPACT7x have been installed. But this does not solve the problem. Is it possible to compile i386 on and amd64 system? -- View this message in context: http://freebsd.1045724.n5.nabble.com/bin-139146-still-not-right-in-FreeBSD-8-2-m32-on-amd64-tp3965590p4725801.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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
10G Inter adapter
Hi everyone, i have a 82599EB network card. the ixgbe driver on 8* supports 82598 cards, although it identified my card but i'm not sure it will work fine and won't make kernel panics, since its a production server i want to put a good driver that will work without problems. I just found this from the Intel website. Looks like they have added support for the 82598 and 82599 which isn't on the ixgbe driver on 8 stable/release. * http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=14688lang=eng * is it safe to dowload and put the files of this driver in /sys/dev/ixgbe and then install it? is it simply: *make make install make clean*? i guess i need to recompile the kernel also because ixgbe is on the GENERIC kernel. what do you advise me? -- Sami Halabi Information Systems Engineer NMS Projects Expert ___ 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: -m32 on freeBSD 8.2r amd64
On Tue, Aug 23, 2011 at 2:26 PM, noel beck nb...@hobsoft.com.mt wrote: We are trying to compile i386 on a FreeBSD 8.2r amd64. we are getting an error stating that libstdc++.so.6, is missing. COMPACT6x and COMPACT7x have been installed. But this does not solve the problem. Is it possible to compile i386 on and amd64 system? I believe compiler flags to /lib32 is required (-L/usr/lib32 or something) ___ 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: 10G Inter adapter
What OS release are you going to be using, 8.2 ? The driver in HEAD is the latest code, the internal tarball goes thru release machinery so it is lagging a bit (2.3.8 vs 2.3.11), you should be OK in either case, but I'd recommend the newer. Jack On Tue, Aug 23, 2011 at 12:39 AM, Sami Halabi sodyn...@gmail.com wrote: Hi everyone, i have a 82599EB network card. the ixgbe driver on 8* supports 82598 cards, although it identified my card but i'm not sure it will work fine and won't make kernel panics, since its a production server i want to put a good driver that will work without problems. I just found this from the Intel website. Looks like they have added support for the 82598 and 82599 which isn't on the ixgbe driver on 8 stable/release. * http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=14688lang=eng * is it safe to dowload and put the files of this driver in /sys/dev/ixgbe and then install it? is it simply: *make make install make clean*? i guess i need to recompile the kernel also because ixgbe is on the GENERIC kernel. what do you advise me? -- Sami Halabi Information Systems Engineer NMS Projects Expert ___ 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
reproducible panic on 8.2-RELEASE, but no core file
Hi, I'm experiencing a reproducible kernel panic that would be really nice to debug, but unfortunately no core file is getting generated. I don't have console access either. All I can get so far is this, from syslog: Aug 23 19:51:38 kern.crit estranged kernel: Aug 23 19:51:38 kern.crit estranged kernel: Fatal double fault: Aug 23 19:51:38 kern.crit estranged kernel: eip = 0xc0593b2e Aug 23 19:51:38 kern.crit estranged kernel: esp = 0xe5583fe4 Aug 23 19:51:38 kern.crit estranged kernel: ebp = 0xe5584010 Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0; apic id = 00 Aug 23 19:51:38 kern.crit estranged kernel: panic: double fault Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 Aug 23 19:51:38 kern.crit estranged kernel: panic: 0xc4263b40 must be migratable Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 Aug 23 19:51:38 kern.crit estranged kernel: panic: 0xc4263b40 must be migratable Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 [SNIP - above two lines repeated alot] Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0kernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: panic: Aug 23 19:51:38 kern.crit estranged kernel: 0xc4263b40 must be migratablekernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: kernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 Aug 23 19:51:38 kern.crit estranged kernel: kernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: panic: My dumpdev is set: $ ls -l /dev/dumpdev lrwxr-xr-x 1 root wheel 11 Aug 23 19:56 /dev/dumpdev@ - /dev/ad4s1b But savecore reports: Aug 23 19:56:34 console.info estranged kernel: No core dumps found. Any advice for getting a core file? :) Thanks, Aragon ___ 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: reproducible panic on 8.2-RELEASE, but no core file
on 23/08/2011 23:05 Aragon Gouveia said the following: Hi, I'm experiencing a reproducible kernel panic that would be really nice to debug, but unfortunately no core file is getting generated. I don't have console access either. All I can get so far is this, from syslog: Aug 23 19:51:38 kern.crit estranged kernel: Aug 23 19:51:38 kern.crit estranged kernel: Fatal double fault: Aug 23 19:51:38 kern.crit estranged kernel: eip = 0xc0593b2e Aug 23 19:51:38 kern.crit estranged kernel: esp = 0xe5583fe4 Aug 23 19:51:38 kern.crit estranged kernel: ebp = 0xe5584010 Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0; apic id = 00 Aug 23 19:51:38 kern.crit estranged kernel: panic: double fault Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 Aug 23 19:51:38 kern.crit estranged kernel: panic: 0xc4263b40 must be migratable Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 Aug 23 19:51:38 kern.crit estranged kernel: panic: 0xc4263b40 must be migratable Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 [SNIP - above two lines repeated alot] Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0kernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: panic: Aug 23 19:51:38 kern.crit estranged kernel: 0xc4263b40 must be migratablekernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: kernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: cpuid = 0 Aug 23 19:51:38 kern.crit estranged kernel: kernel trap 12 with interrupts disabled Aug 23 19:51:38 kern.crit estranged kernel: panic: My dumpdev is set: $ ls -l /dev/dumpdev lrwxr-xr-x 1 root wheel 11 Aug 23 19:56 /dev/dumpdev@ - /dev/ad4s1b But savecore reports: Aug 23 19:56:34 console.info estranged kernel: No core dumps found. Any advice for getting a core file? :) Not sure about the core file - I think that we do not attempt to do a dump when we get a doublefault which is what you have, but not sure about this. Also, those secondary panics might be coming from the sched_bind() call at the start of boot() function in sys/kern/kern_shutdown.c. For a start you can try adding DDB to your kernel config and capturing a stack trace of the panic from the ddb prompt. -- Andriy Gapon ___ 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
