search for: 16mib

...rn their brains about the reasons. Users should not blame the distro (without even reporting the problem). We are talking about an average padding of less than 2% for realistic cases, and that's just for the minimal size (around 1GiB). If users are required to download images of 3GB, adding 16MiB (on average) is less than 1%. Additionally, we are talking about an average of 16MiB of padding for "un-padded" images. Current (as of 6.03) isohybrid images are already padded (with a different algorithm), so the additional (differential) "waste" produced by this patch is...

Hi, > Now, I have a question: what about the "offset" parameter? How it > modifies our assumptions and calculations if the "offset" parameter is > not zero? The offset influences only the start address of the partition. The alignment goal is about the end address. So these concepts are nearly independent. Of course, partition start must be smaller than partition

Hi, On Tue, Nov 12, 2013 at 01:41:29PM -0800, H. Peter Anvin wrote: > On 11/12/2013 01:22 PM, Andrew J. Schorr wrote: > > I am using 4.05 because that's what's packaged in the latest Fedora > > release (Fedora 19 in my case). I wonder why they are using such an > > old version. I will take a look at how difficult it would be to build > > the latest version on

...what I did :-) Didn't though about any other alternative... >> but that's sub-optimal since I need to have them in two places. > > Especially since the size of an El Torito boot image > is restricted to 32 MiB (65536 x 512 bytes). That's no problem here, it's under 16MiB. > In any case there is no other boot path specified than > to look up /efi/boot/bootx64.efi in the FAT filesystem > and to execute it. Should I rename syslinux.efi to that one? -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes,...

...things. > > That's an interesting idea. I may give that a try. Just to be clear, > are you talking here about the kernel "mem=" boot parameter, as documented > in kernel-parameters.txt? Yes. If the system has about 8192MiB RAM, I'd start by shaving it off in about 16MiB increments or perhaps take a binary search tree pattern approach. > I wonder if that has negative implications for subsequent system performance... Judicious use of that parameter should have minimal impact. You are right to think that it will make said RAM unavailable later but it also affec...

...'s an interesting idea. I may give that a try. Just to be clear, >> are you talking here about the kernel "mem=" boot parameter, as documented >> in kernel-parameters.txt? > > Yes. If the system has about 8192MiB RAM, I'd start by shaving it off > in about 16MiB increments or perhaps take a binary search tree pattern > approach. > Actually, start by dropping it down to mem=2G, and move downward from there. >> I wonder if that has negative implications for subsequent system performance... It will, but it would be useful as a diagnostic tool....

...DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. [ 0.156843] DMAR-IR: Enabled IRQ remapping in x2apic mode [ 2.112369] DMAR: No RMRR found [ 2.112505] DMAR: dmar0: Using Queued invalidation [ 2.112669] DMAR: Setting RMRR: [ 2.112671] DMAR: Prepare 0-16MiB unity mapping for LPC [ 2.112820] DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff] [ 2.211577] DMAR: Intel(R) Virtualization Technology for Directed I/O ===> This is expected # dmesg | grep -i iommu |grep device [ 2.212267] iommu: Adding device 0000:00:00.0 to grou...

Just a small correction: Thomas Schmitt via Syslinux <syslinux at zytor.com> wrote: > > > I expect the average waste to be a bit less than 16 MB. > > Yes, but slightly misleading. For example, the "16MB average" is > > relevant for 255/63. > > We advise two geometries: -h 63 -s 32 and -h 255 -s 63. > isohybrid behavior with the first one will not

Hi, > What about '-h 255 -s 63 , ISO size 1085736960' ? -h 255 -s 63 , ISO size 1085736960 : align_factor= 4 , padding= 0 , image size= 132.000000 cylinders ----------------------------------------------------------------- Code of isohybrid_test_mockup.c : ----------------------------------------------------------------- #include <stdlib.h> #include <stdio.h> int

Hi, i wrote: > > Would it be desirable to explain how Fedora et.al. > > created their FAT boot images by help of old or new > > GRUB ? > > (If developers of EFI bootable ISOs are reading this, > > please give a short sketch of the procedure.) piranna at gmail.com wrote: > I did it by including the Linux kernel and the initramfs None of the ISOs i know has this

...640 664 720 800 480 483 487 500 -hsync +vsync (29.7 kHz) (**) NOUVEAU(0): Display dimensions: (330, 210) mm (**) NOUVEAU(0): DPI set to (129, 127) (II) NOUVEAU(0): Opened GPU channel 2 (II) NOUVEAU(0): [DRI2] Setup complete (II) NOUVEAU(0): GART: 512MiB available (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer (**) NOUVEAU(0): Option "BackingStore" "true" (**) NOUVEAU(0): Backing store enabled (==) NOUVEAU(0): Silken mouse enabled (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video. (II) NOUVEAU(0): [XvMC] Extension initialized. (II) NOUVEAU(...

...on = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (--) Depth 24 pixmap format is 32 bpp (II) NOUVEAU(0): Opened GPU channel 2 (II) NOUVEAU(0): [DRI2] Setup complete (II) NOUVEAU(0): [DRI2] DRI driver: nouveau (II) NOUVEAU(0): GART: 512MiB available (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer (II) EXA(0): Driver allocated offscreen pixmaps (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen (==) NOUVEAU(0): Bac...

...Depth 24 pixmap format is 32 bpp [ 4325.503] (II) NOUVEAU(0): Opened GPU channel 1 [ 4325.503] (II) NOUVEAU(0): [DRI2] Setup complete [ 4325.503] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau_vieux [ 4325.503] (II) NOUVEAU(0): GART: 64MiB available [ 4325.506] (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer [ 4325.506] (**) NOUVEAU(0): Option "MigrationHeuristic" "always" [ 4325.506] (**) NOUVEAU(0): Option "EXANoComposite" "false" [ 4325.506] (**) NOUVEAU(0): Option "EXAOptimizeMigration" "true" [ 4325.507] (II) EXA(0...

...00000000 - 0x00000000 (0x1) IX[B] [22] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [23] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) NOUVEAU(0): Allocated 128MiB VRAM for framebuffer + offscreen pixmaps, at offset 0x20000000 (II) NOUVEAU(0): AGPGART: 32MiB available (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer (II) NOUVEAU(0): [drm] Using the DRM lock SAREA also for drawables. (II) NOUVEAU(0): [drm] framebuffer handle = 0xb0000000 (II) NOUVEAU(0): [drm] added 1 reserved context for kernel (II) NOUVEAU(0): X context handle = 0x1 (II) NOUVEAU(0): [drm] installed DRM signal handler (II)...

Hi Pierre, thanks for your reply. I am using kernel 3.10.0-123.8.1.el7.x86_64. The kernel modul used after nodedev-detach is vfio-pci This is the output of lspci -vv after I did a virsh nodedev-detatch pci_0000_02_00_0 02:00.0 Ethernet controller: PLX Technology, Inc. Device 235e Subsystem: PLX Technology, Inc. Device 235e Control: I/O- Mem- BusMaster- SpecCycle- MemWINV-

...(--) Depth 24 pixmap format is 32 bpp [ 23.564] (II) NOUVEAU(0): Opened GPU channel 1 [ 23.565] (II) NOUVEAU(0): [DRI2] Setup complete [ 23.565] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau [ 23.565] (II) NOUVEAU(0): GART: 256MiB available [ 23.573] (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer [ 23.607] (II) EXA(0): Driver allocated offscreen pixmaps [ 23.607] (II) EXA(0): Driver registered support for the following operations: [ 23.607] (II) Solid [ 23.607] (II) Copy [ 23.607] (II) Composite (RENDER acceleration) [ 23.607] (I...

...EAU(0): Opened GPU channel 2 [ 22.226] (II) NOUVEAU(0): [DRI2] Setup complete [ 22.226] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau [ 22.226] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau [ 22.232] (II) NOUVEAU(0): GART: 512MiB available [ 22.246] (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer [ 22.246] (II) EXA(0): Driver allocated offscreen pixmaps [ 22.246] (II) EXA(0): Driver registered support for the following operations: [ 22.246] (II) Solid [ 22.246] (II) Copy [ 22.246] (II) Composite (RENDER acceleration) [ 22.246] (I...

Hi, Following is a simple patch that is needed in nouveau to get accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is almost the mainline merge), was substituted into the kernel-tree. All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) used of the same day. Patch: diff -Naur

Hi, Following is a simple patch that is needed in nouveau to get accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is almost the mainline merge), was substituted into the kernel-tree. All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) used of the same day. Patch: diff -Naur