search for: 2kib

On 11/21/2013 02:50 AM, Carl Duff wrote: > Hi All, > > It is impossible to boot Linux-based ISOs that use Syslinux 6.02 via > CD or DVD on older - non-UEFI - systems. Any attempt to do so will > result in the following error message: ISOLINUX 6.02 ETCDisolinux: > Disk error 01, AX = 4279, drive FE > Error 01 is unsupported operation, 42xx is read, so something is really

We are utilizing the xen hypervisor on nexenta with ISCSI as our method of communication with the guests (currently ubuntu but could be moving to centos). Obviously jumbo packet support would be nice to have. The last time I see that on the xen roadmap http://wiki.xensource.com/xenwiki/XenRoadMap . Is there a canonical place that spells out if jumbo frames are now supported or still on the

Hello What is the largest file size that can be created on Linux ? is there any limitation ? Thanks

bump? Any idea how to tackle this dark text and dark hud problem? I updated amd/ati catalyst to latest 12.1, and wine to 1.3.37, but won't fix the problem. Here is the image again. [Image: http://i44.tinypic.com/2946gbs.jpg ]

Hi, Ady wrote: > I wonder if isolinux.bin should be limited to max. 16 sectors (of > 2KiB each), as that's the default limit in mkisofs "-G > <generic_boot_image>" option. Option -G is not related to the El Torito boot image isolinux.bin. It inserts its data into the System Area of the ISO, which is indeed limited to 32 KiB. Use cases are MBR and other kinds of...

> Hi, > > Ady wrote: > > I wonder if isolinux.bin should be limited to max. 16 sectors (of > > 2KiB each), as that's the default limit in mkisofs "-G > > <generic_boot_image>" option. > > Option -G is not related to the El Torito boot image isolinux.bin. > It inserts its data into the System Area of the ISO, which is > indeed limited to 32 KiB. > Use cas...

...ly code that emits this message is *identical* between > Syslinux 4 and Syslinux 6. The biggest difference is the size of > isolinux.bin, so it is possible that that might be the source of the > problem. > > -hpa I wonder if isolinux.bin should be limited to max. 16 sectors (of 2KiB each), as that's the default limit in mkisofs "-G <generic_boot_image>" option. If that happens to be the case, perhaps there is some additional option so to reserve more sectors for the boot image? Is there any method to reduce the size of isolinux.bin? Regards, Ady.

Hi, I am not an engineer or linux expert but I have been using syslinux to boot live disk filesets (extracted from iso's) residing on fat32 and NTFS volumes. In FAT32 there has been no problem going with larger cluster sizes up to the nominal maximum of 64K however, with NTFS it has not been possible to exceed the cluster size of 4096. With NTFS formatted using clusters of 8192 or larger,

> I'm the developer of manjaroiso, the tool we use to build our install > medias for Manjaro Linux. > During our testings we found out, that syslinux6 won't work on older > hardware. I've a new Lenovo i7 notebook which booted up our images > just fine. Even with syslinux6. On my other PCs I got similar error > messages as Carl got. (snip) > > In

...*identical* between >> Syslinux 4 and Syslinux 6. The biggest difference is the size of >> isolinux.bin, so it is possible that that might be the source of the >> problem. >> >> -hpa > > I wonder if isolinux.bin should be limited to max. 16 sectors (of > 2KiB each), as that's the default limit in mkisofs "-G > <generic_boot_image>" option. > > If that happens to be the case, perhaps there is some additional > option so to reserve more sectors for the boot image? > > Is there any method to reduce the size of isolinux...

I have recently moved from Ubuntu 10.04 to Mint 11 Katya and installed Wine 1.2.2 using software manager. I have the original dayplan.exe files and dll files from the Norton Desktop program that was designed to run without an installer from Win 3.1 . For me this program has worked in all versions of Windows including XP and when running Wine in Ubuntu 10.04 it also worked. Now when I double

...isual tearing on > the > screen. In some unforgiving hardware, some of this programming has to both > start and end in the same vblank. This is apparently the case on the > majority > of Intel GPUs in the wild right now, most notably with gamma updates which > involve mashing over 2KiB of registers during the vblank. Other drivers have > very similar needs to this (nouveau in particular is why I'm here, we need > it > for CRC related stuff) so we figured it'd be a good idea to add a set of > helpers for performing realtime hardware programming that's synch...

...useful for NTFS as in FAT32, > > if not more so. > > > > I stand by prepared for immediate testing of win32 > syslinux versions as early as 4.06 which contain > > modifications to include this property > > -- > -Gene > > search terms: 0.5 kiB, 1kiB, 2kiB, 4kiB 8kiB; half k, 1k, > 2k, 4k, 8k; > 0.5kB, 1kB, 2kB, 4kB, 8kB

...fely changed without showing visual tearing on the screen. In some unforgiving hardware, some of this programming has to both start and end in the same vblank. This is apparently the case on the majority of Intel GPUs in the wild right now, most notably with gamma updates which involve mashing over 2KiB of registers during the vblank. Other drivers have very similar needs to this (nouveau in particular is why I'm here, we need it for CRC related stuff) so we figured it'd be a good idea to add a set of helpers for performing realtime hardware programming that's synchronized to vblank in...

...> > screen. In some unforgiving hardware, some of this programming has to both > > start and end in the same vblank. This is apparently the case on the > > majority > > of Intel GPUs in the wild right now, most notably with gamma updates which > > involve mashing over 2KiB of registers during the vblank. Other drivers > > have > > very similar needs to this (nouveau in particular is why I'm here, we need > > it > > for CRC related stuff) so we figured it'd be a good idea to add a set of > > helpers for performing realtime hardwar...

On Tue, Mar 17, 2020 at 08:40:58PM -0400, Lyude Paul wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > Add some kind of vblank workers. The interface is similar to regular > delayed works, and also allows for re-scheduling. > > Whatever hardware programming we do in the work must be fast > (must at least complete during the vblank, sometimes during