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 tried
hacked following into oskit-mach/oskit/ds_routines:
io_return_t
ds_device_write (device_t dev, ipc_port_t reply_port,
mach_msg_type_name_t reply_port_type, dev_mode_t mode,
recnum_t recnum, io_buf_ptr_t data, unsigned int count,
int *bytes_written)
{
[...]
vm_offset_t addr;
kern_return_t kr = vm_map_copyout (device_io_map, &addr,
(vm_map_copy_t) data);
if (kr == KERN_SUCCESS)
{
/* Note: we assume that write_inband can take a large count. */
kr = (*dev->ops->write_inband) (dev, reply_port,
reply_port_type, mode, recnum,
(char *) addr, count,
bytes_written);
(void) vm_deallocate (device_io_map, addr, count);
}
if (count == 66) /* XXX */
return 123;
return kr;
[...]
}
As you can see, if count is 66, the return value is just a silly value.
Without these lines, the kernel works fine. The question now is, why
an error code is not a good thing at this location?
wagi
--
Daniel Wagner "use quit to exit"
email: [EMAIL PROTECTED]
GnuPG: 1024D/DCDE890A (public key available on any keyserver)
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
