similar to: [PATCH 3/3] ALPHA: implement and use rdwr_bytes

This set of patches add some support for sector size >512. Currently it fixes extlinux, MBR for GPT and ext partitions. Other code is unaffected. This set of patches has been tested on a read Dell machine running a beta firmware.

From: Raphael S. Carvalho <raphael.scarv at gmail.com> It's already loading modules successfully, booting Linux, and both UFS version 1 and 2 seem to be working correctly. Signed-off-by: Raphael S. Carvalho <raphael.scarv at gmail.com> --- core/fs/ufs/bmap.c | 202 ++++++++++++++++++++++++++ core/fs/ufs/ufs.c | 404 ++++++++++++++++++++++++++++++++++++++++++++++++++++

It's already loading modules successfully, and both UFS version 1 and 2 seems to be working correctly. Special thanks to Paulo Alcantara and Matt Fleming for being always ready to help me and give feedback. Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com> --- core/fs/ufs/bmap.c | 202 ++++++++++++++++++++++++++ core/fs/ufs/ufs.c | 404

From: Raphael S. Carvalho <raphael.scarv at gmail.com> MULTIFS SYNTAX: (hd[disk number]:[partition number])/path/to/file The meaning of this_fs was changed to improve the flexibility of the support. Now, this_fs means the file system being currently used. root_fs was created to save the context of the main file system (where ldlinux.sys lives in). get_fs_info is a function pointer that

On Thu, 19 Jun, at 10:04:35PM, Gene Cumm wrote: > > I'm getting some similar results here with the precompiled binaries > and my binaries of 6.03-pre17 Gene, could you try out the attached patch? And see if you get any different results? Andrew, feel free to try it out too, or you could just wait for someone to cut another pre-release. Note that I don't think this will

Hi, C/H/S addressing and reading of first block seems to be ok in isohdpfd.bin. The main suspect for the failure of the attempt with isohdpfd.bin is the number or content of the blocks read after the first one. But i have no clue why isohdpfc.bin should do better than isohdpfd.bin. They differ just by one instruction (JC = 0x72 versus JMP = 0xEB) which both are performed before the reading and

liu asked me for some clarification on how intermode calls work on the core32 branch, so I decided that that was probably something that really should be published more widely. This is the *current state* of the core32 branch; all this stuff is subject to change as development progresses: *** Call from real mode (16-bit) to protected mode (32-bit): These calls are done with the pm_call macro:

From: Sylvain Gault <sylvain.gault at gmail.com> Some linker scripts were splitted into i386 and x86_64 versions in commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were left there. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- core/syslinux.ld | 414 ------------------------------------------------ core/x86_64/syslinux.ld | 389

This patch changes only strings, no program code. It is would be nice if it goes in the 6.04 release. Reported-by: Ady <ady-sf at hotmail.com> How this patch was prepared, how the editting for this patch was done Where is auxiliary written with double l? git grep -i auxilliary Which files are effect git grep -li auxilliary Changing the those files with the streaming editor sed

This pull request contains the XFS filesystem driver for Syslinux. Due to historical reasons (SGI IRIX's design of disk layouts), the first sector in the primary AG on XFS filesystems contains the superblock, which is a problem with BIOSes, since VBRs must be loaded up from the first sector of the active partition. Thus, we needed to handle this issue by putting the Syslinux bootsector

The disk number is set twice in diskio.c/edd_rdwr_sectors() this patch removes the redundant setting. diff --git a/core/fs/diskio.c b/core/fs/diskio.c index 481b59b..38d3da3 100644 --- a/core/fs/diskio.c +++ b/core/fs/diskio.c @@ -163,8 +163,6 @@ static int edd_rdwr_sectors(struct disk *disk, void *buf, memset(&reset, 0, sizeof reset); - ireg.edx.b[0] = disk->disk_number; -

I have been using iosoop script (see http://www.opensolaris.org/os/community/dtrace/scripts/) written by Brendan Gregg to look at the IO operations of my application. When I was running my test-program on a UFS filesystem I could see both read and write operations like: UID PID D BLOCK SIZE COMM PATHNAME 203803 4436 R 6016592 16384 diskio <none> 203803 4436 W 3448432

From: Raphael S. Carvalho <raphael.scarv at gmail.com> Most of file system drivers initialize the cache themselves. The problem is that the same cache could be again initialized later, then invalidating the previous one. This patch fixes this. Problem found while auditing the code. Signed-off-by: Raphael S. Carvalho <raphael.scarv at gmail.com> --- core/fs/cache.c | 2 ++

NTFS $MFT file may be fragmented by itself (and actually is in most cases). However, such a situation was not handled. This patch add support for fragmented $MFT file. Signed-off-by: Andy Alex <andy at r-tt.com> --- diff -uprN syslinux-6.02.orig/core/fs/ntfs/ntfs.c syslinux-6.02/core/fs/ntfs/ntfs.c --- syslinux-6.02.orig/core/fs/ntfs/ntfs.c 2013-10-13 21:59:03.000000000 +0400 +++

The ext2 filesystem supports volume UUID now. The FSUUID variable can be set to kernel command line. Patch is based on FSUUID for FAT patch. Signed-off-by: Serj Kalichev <serj.kalichev at gmail.com> --- core/fs/ext2/ext2.c | 40 +++++++++++++++++++++++++++++++++++++++- core/fs/ext2/ext2_fs.h | 1 + 2 files changed, 40 insertions(+), 1 deletion(-) diff --git a/core/fs/ext2/ext2.c

Besides supporting newer version of xfs file system, this patch also does some code refactoring and fix completely broken listing and searching on v2-3 node directories. Cc: Gene Cumm <gene.cumm at gmail.com> Cc: H. Peter Anvin <hpa at zytor.com> Cc: Raphael S. Carvalho <raphael.scarv at gmail.com> Cc: Ady <ady-sf at hotmail.com> Signed-off-by: Paulo Alcantara <pcacjr

Here is a partial patch that I'm using to illustrate a few questions that I have. Looking at the gpllib write_sectors (com32/gpllib/disk/write.c) it looks like the allocated size is wrong; size is in sectors so we should adjust the alloc/memcpy by size*SECTOR. Also, comparing core/diskio.c it looks like the registers aren't even setup right. In the patch below I put an #if 0 around the

Hello, We found that fsync and fdatasync syscalls sometimes don't sync data in an ext3 file system under the following conditions. 1. Kernel version is 2.6.6 or later (including 2.6.8.1 and 2.6.9-rc2). 2. Ext3's journalling mode is "data=journal". 3. Create a file (whose size is 1Mbytes) and execute umount/mount. 4. lseek to a random position within the file, write 8192 bytes

xfs_is_valid_magicnum is not actually a generic function that checks for magic numbers, instead it checks only for superblock's one. Signed-off-by: Paulo Alcantara <pcacjr at zytor.com> --- core/fs/xfs/xfs.c | 13 +++++-------- core/fs/xfs/xfs.h | 19 ++++++++++--------- 2 files changed, 15 insertions(+), 17 deletions(-) diff --git a/core/fs/xfs/xfs.c b/core/fs/xfs/xfs.c index

Hi, Geert Stappers wrote: > Contact David off-list, he did unsubscribe. Can you tell when he unsubscribed (i.e. which of the messages he got as last one) ? > Martin posted elsewhere in this thread "Thomas, you found the bug" > and provided a patch. Open question is whether the fix helps with David's BIOS. The newest answer from Martin indicates that a failure to read