search for: 64x32

...n the partition. Not overly unhealthy, i'd say, because the ISO filesystem still fits into the partition. Nevertheless not totally clean. Does fdisk -lu complain ? An alternative would be to request a cylinder size which is divisible by 2048. E.g. isohybrid -h 252 -s 63 The cylinder sizes 64x32 and 255x63 emerged as best candidates when we compared our collections of questionable experience and rumors. More substance is not to see behind them. (Actually Cylinder/Head/Sector addressing is so brain damaged that only ill firmware can insist in it having a particular form. All sane firmware...

...teps. They share no prime factors except > > the block size.) Ady: > It doesn't matter. My test.img for Ronald had Nx255x63 geometry, and > STARTing LBA of 2048. Yeah. It has end CHS 89,69,35. But it lacks the other ingredient of the mess: a CHS driven filesystem. The hope with 64x32 and 255x63 is to make CHS addressing more likely to happen correctly. > So, IMHO, I don't see a Windows-user looking for mkdiskimage, but I > could be wrong. If the MS-Windows tools guide the user properly, then there will be no need for mkdiskimage. But a DOS line with mkdiskimage i...

> > Both sticks show very unusual factors for heads and sectors > > which are hardly intentional. If BIOS gets confused like fdisk, > > then the failure to find files is quite plausible. > > > > ------------------------------------------------------------- > > > > Could you please exercise what is described for Linux in > >

Hi, Ronald F. Guilmette wrote: > what exactly did we determine that GA-M55Plus-S3G is failing > to support? It appears to be related to the choice of CHS addressing with the FAT filesystem. This opens the door for misperceived factors of heads per cylinder and sectors per heads. My current suspicion is that the partition end did not expose the effective factors in its end CHS address, so

...essage means it's ok. Otherwise it spews a lot of errors. You have to manually set the TILE_HEIGHT, TILE_WIDTH and TILING_PARAM. TILE_WIDTH == TILE_PITCH in this case because it's 8bpp data. Use this list (TILING_PARAM) TILE_WIDTHxTILE_HEIGHT: (0x00) 32x4 (0x10) 64x8 (0x20) 64x16 (0x30) 64x32 (0x40) 64x64 I'm curious to know if anyone has different layouts. You may need to sudo run it. Maarten. -------------- next part -------------- A non-text attachment was scrubbed... Name: nv50_test.tar.bz2 Type: application/x-bzip2 Size: 1981 bytes Desc: not available Url : http://lists.free...

...lly have to attempt to find the rect in > the frontend at all. The generic interface I''d opt for would be to round up the framebuffer''s size in each direction to the next power of 2, then divide the region into 32 tiles by 32 i.e. for a 1280x1024 the size of each tile would be 64x32. Just using page-level protection to find the updated area in the frontend we''ll be setting runs of bits, but for e.g. a smart Xserver the 2D nature of the bitmap should enable us to do better. Ian _______________________________________________ Xen-devel mailing list Xen-devel@list...

...> the block size.) > > Ady: > > It doesn't matter. My test.img for Ronald had Nx255x63 geometry, and > > STARTing LBA of 2048. > > Yeah. It has end CHS 89,69,35. > But it lacks the other ingredient of the mess: a CHS driven filesystem. > > The hope with 64x32 and 255x63 is to make CHS addressing > more likely to happen correctly. Once the partition table matches the actual partition location, and the values in the VBR match them too (we are getting to that point when we finish with the "simple correction" procedure I already described)...

> An alternative would be to request a cylinder size which > is divisible by 2048. E.g. > > isohybrid -h 252 -s 63 > > The cylinder sizes 64x32 and 255x63 emerged as best > candidates when we compared our collections of questionable > experience and rumors. More substance is not to see behind > them. > (Actually Cylinder/Head/Sector addressing is so brain > damaged that only ill firmware can insist in it having > a part...

...assumption that each partition ends at a cylinder end. > Additionally, what do you mean with "non-traditional sizes"? Or, in > other words, what would constitute a traditional size for the resulting > isohybrid image? I mean non-traditional cylinder sizes. Advised by hpa are 64x32 and 255x63, but i assume that he was not aware of the problem of virtual DVD-ROMs not being aligned to 2048-byte blocks. So in the light of this thread it would be nice if the advise for 255x63 could be changed to 252x63. Question is whether this could cause any regressions with boot firmware. (Pa...

> Hi, > > at [Tails] we're in the process of shipping hybrid ISO images by > default again. We're using `isohybrid -h 255 -s 63' to do that (thanks > to the advice we got on this mailing-list a few months ago!). > > And then, we've discovered that sometimes, isohybrid produces ISO > images whose size is not a multiple of 2048 bytes. > > Who cares?

Hi, at [Tails] we're in the process of shipping hybrid ISO images by default again. We're using `isohybrid -h 255 -s 63' to do that (thanks to the advice we got on this mailing-list a few months ago!). And then, we've discovered that sometimes, isohybrid produces ISO images whose size is not a multiple of 2048 bytes. Who cares? ... may you ask. Well, apparently, VirtualBox does:

> Hi, > > Ady wrote: > > I fear we would get slightly off-topic. > > Yep. Since the TAILS ISO is supposed to not grow over 2 GiB > for now, it seems best to just use -h 128 -s 32 in order to > stay near to traditions. > > > ----------------------------------------------------------- > Summary: > > The alignment to cylinder size is a core feature of

On 02/24/16 20:45, Shao Miller via Syslinux wrote: > On 2/24/2016 22:55, Shao Miller wrote: >> Suppose...: >> - For non-releases: "git" + We take the first 6 chars of git commit >> - For releases: "ver" + major + "." + minor >> - For tar-balls: Something clever, maybe involving the date >> >> ...that we embed such a version in

...al cylinders. > > > > Additionally, what do you mean with "non-traditional sizes"? Or, in > > other words, what would constitute a traditional size for the resulting > > isohybrid image? > > I mean non-traditional cylinder sizes. > Advised by hpa are 64x32 and 255x63, but i assume that he > was not aware of the problem of virtual DVD-ROMs not being > aligned to 2048-byte blocks. My suggestion considers whichever pair of H*S (Cylinder _size_) values (which are command-line parameters), so there is no contradiction between my suggestion and r...

Hi, Ady wrote: > I fear we would get slightly off-topic. Yep. Since the TAILS ISO is supposed to not grow over 2 GiB for now, it seems best to just use -h 128 -s 32 in order to stay near to traditions. ----------------------------------------------------------- Summary: The alignment to cylinder size is a core feature of isohybrid. If -h multiplied by -s is not divisible by 4, then ISO

Hi, Ady wrote: > I personally don't like this "hiding" [of CHS], but I understand > their reasons to do so. > > I think that the "USB-Geometry" section in the wiki should try to > point to the same kind of users. But it is in wiki page Hardware_Compatibility. Check out the neighborhood. If there is a place to - for once - state how a "normal"