Daniel Wagner <[EMAIL PROTECTED]> writes:
> Calling device_write with an invalid data_count, device_write will return
> an error (D_INVALID_SIZE). I didn't checked the return value, instead
> I tested for the bytes_written and of course there's only a bogus
> value.
This is a general rule for
> ds_device_write_error_reply call in ds_device_write. What is the actual
> failure mode now?
You were completetly right. There's no bug. Sorry, for bothering you.
Calling device_write with an invalid data_count, device_write will return
an error (D_INVALID_SIZE). I didn't checked the return v
> ds_net_write_inband makes first a sanity check for the given paramenters.
> If this fails it just returns without setting bytes_written to 0.
That is as it should be. I thought you were talking about a successful call.
The out parameters are not examined when the return value is nonzero,
so it
> That is pretty strange. There are two things here that are not right.
> That value from ops->write_inband (61) is bogus for that call. But,
> whatever is in *bytes_written at that point definitely ought to make it
> back to the user. To debug the latter case, please do "finish" from that
> fr
> In order to trigger the bug again, I setted data_count to 4. bytes_written
> return the value 18677512. But bytes_written does not match to size which
> the driver returns:
That is pretty strange. There are two things here that are not right.
That value from ops->write_inband (61) is bogus for
Sorry for being so unclear, I'm trying to be more specific.
I was referring to this (stolen from the mach docs):
kern_return_t device_write (device_t device,
dev_mode_t mode,
recnum_t recnum,
io_buf_ptr_t data
> Just one thing: The last argument should return the number of written
> bytes. When an error has occured, the return values does not match the
> bytes_written variable in ds_device_write.
Sorry, I am not following you at all. Please be more specific (show a patch).
It sounds like you are tal
> Please try the ds_routines.c change I just committed and tell me if it
> helps or harms.
Your patch helps.
Just one thing: The last argument should return the number of written
bytes. When an error has occured, the return values does not match the
bytes_written variable in ds_device_write.
Please try the ds_routines.c change I just committed and tell me if it
helps or harms.
Thanks,
Roland
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Hmm, I think I may have eyeballed the problem. When the server function
(ds_device_write) returns something other than KERN_SUCCESS (zero) or
MIG_NO_REPLY, then the message body will get destroyed by the kernel.
What's happening is that we call vm_map_copyout, which consumes the ool
stuff in the
I don't really have any ideas off hand what the problem might be. Can you
step through the return from ds_device_write in gdb and follow what happens
from there until the crash?
The only other idea that occurs to me for narrowing it down is to try you
test program with device_write_inband and se
The bug is triggered, when from an underlying layer (driver layer, I think)
an error via the return value is reported. I tried several values for the
size parameter. If it's reasonable large, for example 64 bytes, the system
stays stable. But count = 4 will trigger the bug. To be on sure side I t
12 matches
Mail list logo
