If I remember well, Qemu usually has problems emulating SATA devices. Maybe
can be necessary to test It over real hardware
El mar, 24 nov 2020 a las 7:59, Samuel Thibault ()
escribió:
> Damien Zammit, le mar. 24 nov. 2020 11:15:15 +1100, a ecrit:
> > On 24/11/20 5:16 am, Samuel Thibault wrote:
>
Damien Zammit, le mar. 24 nov. 2020 11:15:15 +1100, a ecrit:
> On 24/11/20 5:16 am, Samuel Thibault wrote:
> > Had you tested support for cd-rom? With qemu I am getting a media sense
> > error with status 0x50.
>
> I think that was the reason for the qemu patch for syncing IDE cache iirc.
I thoug
On 24/11/20 5:16 am, Samuel Thibault wrote:
> Hello,
>
> Had you tested support for cd-rom? With qemu I am getting a media sense
> error with status 0x50.
I think that was the reason for the qemu patch for syncing IDE cache iirc.
Damien
Hello,
Had you tested support for cd-rom? With qemu I am getting a media sense
error with status 0x50.
Samuel
On 11/11/20 5:58 am, Samuel Thibault wrote:
> Damien Zammit, le mar. 10 nov. 2020 21:11:31 +1100, a ecrit:
>> I also printed inside rumpdisk to dump the offsets before calling
>> pread/pwrite,
>> these offsets are sometimes wider than 32 bits, sometimes not.
>
> Ok. Do pread/pwrite get called
Damien Zammit, le mar. 10 nov. 2020 21:11:31 +1100, a ecrit:
> I also printed inside rumpdisk to dump the offsets before calling
> pread/pwrite,
> these offsets are sometimes wider than 32 bits, sometimes not.
Ok. Do pread/pwrite get called concurrently, or is pread/pwrite always
finished before
Hi Samuel,
On 10/11/20 6:21 pm, Samuel Thibault wrote:
>> It seems to be compiled with -D_FILE_OFFSET_BITS=64 already by default:
>
> But is rumpkernel itself also built with it?
>
> Really, better actually *test* that offsets are getting properly
> propagated.
Test program output:
```
...
wd0:
Damien Zammit, le mar. 10 nov. 2020 13:17:52 +1100, a ecrit:
> On 10/11/20 10:39 am, Samuel Thibault wrote:
> >> sdd2 is / that boots with rumpdisk.static
> >> sdd3 is the second partition I am trying to mount with the injected
> >> translator
> >
> > That's far... Unless rumpdisk is built with _
Hi,
On 10/11/20 10:39 am, Samuel Thibault wrote:
>> sdd2 is / that boots with rumpdisk.static
>> sdd3 is the second partition I am trying to mount with the injected
>> translator
>
> That's far... Unless rumpdisk is built with _FILE_OFFSET_BITS 64, its
> off_t etc. will be 32bit, thus probably i
Damien Zammit, le mar. 10 nov. 2020 11:01:29 +1100, a ecrit:
> On 10/11/20 6:06 am, Samuel Thibault wrote:
> > Perhaps add prints in the rump code to determine what really returns
> > that error and why. Possibly it's really a constraint of wd0d, perhaps
> > it can only be opened once at a time.
>
Hi,
On 10/11/20 6:06 am, Samuel Thibault wrote:
> Perhaps add prints in the rump code to determine what really returns
> that error and why. Possibly it's really a constraint of wd0d, perhaps
> it can only be opened once at a time.
I am getting EBUSY when trying to reopen /dev/wd0d in rump_sys_op
Damien Zammit, le mar. 10 nov. 2020 10:33:39 +1100, a ecrit:
> Hi,
>
> On 10/11/20 6:12 am, Samuel Thibault wrote:
> > Btw, is your second partition within small bounds? (e.g. within 4GiB
> > that can be expressed with 32bit integers)
>
> Device Boot Start End Sectors Size Id Typ
Hi,
On 10/11/20 6:12 am, Samuel Thibault wrote:
> Btw, is your second partition within small bounds? (e.g. within 4GiB
> that can be expressed with 32bit integers)
Device Boot Start End Sectors Size Id Type
/dev/sdd12048 1953791 1951744 953M 82 Linux swap / Solar
Samuel Thibault, le lun. 09 nov. 2020 20:06:28 +0100, a ecrit:
> I'd say track the offset within the pread calls, to make sure that it is
> not getting lost along the path.
Also, I'd say put prints around the pread and pwrite calls. Actually now
realizing that rumpdisk is for now single-threaded,
Damien Zammit, le lun. 09 nov. 2020 19:43:05 +1100, a ecrit:
> On 9/11/20 4:50 am, Samuel Thibault wrote:
> > But you can as well replace these two calls with a single tall to
> > rump_sys_pread() that avoids such issue (ditto for write).
>
> http://git.zammit.org/hurd-sv.git/log/
>
> Even with t
Hi,
On 9/11/20 4:50 am, Samuel Thibault wrote:
> But you can as well replace these two calls with a single tall to
> rump_sys_pread() that avoids such issue (ditto for write).
http://git.zammit.org/hurd-sv.git/log/
Even with the new pread/pwrite calls, it still seems to mix up the reads/writes
b
Samuel Thibault, le dim. 08 nov. 2020 18:50:12 +0100, a ecrit:
> But you can as well replace these two calls with a single tall to
> rump_sys_pread() that avoids such issue (ditto for write).
(IIRC we had already discussed about it and left it in some TODO-list,
is that recorded somewhere?)
Samue
Damien Zammit, le dim. 08 nov. 2020 16:10:32 +1100, a ecrit:
> I am using the libparted access method via
> storeio `-T typed part:x` but using the same underlying device.
> Do I need to make opening a new partition on the same disk device
> open a new handle on the same disk?
Since your device_r
Hi Samuel,
When I access a different partition on the same disk,
I am using the libparted access method via
storeio `-T typed part:x` but using the same underlying device.
Do I need to make opening a new partition on the same disk device
open a new handle on the same disk? If so, how?
I think cu
Damien Zammit, le dim. 08 nov. 2020 10:41:47 +1100, a ecrit:
> On 8/11/20 2:35 am, Samuel Thibault wrote:
> > Perhaps, before mounting, try to run
>
> DISK
> > fdisk -l /dev/wd0
>
> root@zamhurd:~# showtrans /dev/wd0
> /hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0
> root@zamhurd:~# fdis
Hi,
On 8/11/20 2:35 am, Samuel Thibault wrote:
> Perhaps, before mounting, try to run
DISK
> fdisk -l /dev/wd0
root@zamhurd:~# showtrans /dev/wd0
/hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0
root@zamhurd:~# fdisk -l /dev/wd0
ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMO
Hello,
Damien Zammit, le sam. 07 nov. 2020 18:39:32 +1100, a ecrit:
> I think I managed to get the rumpdisk bootstrapped translator installed on a
> filesystem node,
Yay :)
> but when I try to mount a second partition on the same disk it crashes the /
> partition.
Perhaps, before mounting, t
Hi all,
I think I managed to get the rumpdisk bootstrapped translator installed on a
filesystem node,
but when I try to mount a second partition on the same disk it crashes the /
partition.
```
root@zamhurd:~# showtrans /dev/wd0s3
/hurd/storeio -T typed part:3:device:@/dev/rumpdisk:/dev/wd0
?2
23 matches
Mail list logo