search for: n_sector

...ou looked at how other drivers (like the Xen pv blkfront) handle this? > My driver will create a virtio-blk request with two elements in the sg list, one > for the first 4096 byes and the other for the remaining 904. > > From stepping through with gdb, virtio_blk_handle_write will sets n_sectors to 9 > (5000 / 512). Later on the code, n_sectors is used the calculate the size of the > buffer required but 9 * 512 is too small and so when the request is process it > ends up writing past the end of the buffer and I guest this triggers the glibc > error. We need to validate that (...

...ou looked at how other drivers (like the Xen pv blkfront) handle this? > My driver will create a virtio-blk request with two elements in the sg list, one > for the first 4096 byes and the other for the remaining 904. > > From stepping through with gdb, virtio_blk_handle_write will sets n_sectors to 9 > (5000 / 512). Later on the code, n_sectors is used the calculate the size of the > buffer required but 9 * 512 is too small and so when the request is process it > ends up writing past the end of the buffer and I guest this triggers the glibc > error. We need to validate that (...

Hi Apologies for referring back to an old thread, but in this conversation https://www.syslinux.org/archives/2018-October/026198.html Thomas and Ady seemed to suggest that booting 32-bit linux from 64-bit EFI was possible with the patched 6.04-pre version of syslinux that Debian are using. When I try this, all I get is Loading ../../bzImage...ok Loading ../../imgpt4.gz...ok and then nothing.

...lo; return lo->lo_number; diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c index 48c67f6..81f289a 100644 --- a/drivers/block/mg_disk.c +++ b/drivers/block/mg_disk.c @@ -1006,6 +1006,7 @@ static int mg_probe(struct platform_device *plat_dev) set_capacity(host->gd, host->n_sectors); + /* FIXME: handle error. */ device_add_disk(NULL, host->gd, NULL); return err; diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c index 504c549..83dc3dc 100644 --- a/drivers/block/mtip32xx/mtip32xx.c +++ b/drivers/block/mtip32xx/mtip32xx.c @@ -4028,6 +...

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk