Re: init patch
Make sense? Now it does. Thanks for clearing it up for me. However, here is probably a better version of your patch, since it uses crash_system(). Returning err, causes launch_something () to retry start_child as it needs to and crashes the system if nothing works. Does it report a usefull message when crashing? ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: init: cannot reboot
tty1"/libexec/getty 38400" hurdon secure trus= ted console Shouldn't "/libexec/getty 38400" be "/libexec/getty 9600"? Due to some bug; not that I remeber what bug. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: init patch
--- "Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote: > Make sense? > > Now it does. Thanks for clearing it up for me. > >However, here is probably a better version of your patch, since it >uses crash_system(). Returning err, causes launch_something () to >retry start_child as it needs to and crashes the system if nothing >works. > > Does it report a usefull message when crashing? I doubt it, I haven't got around to crashing my system by having no console. = James Morrison University of Waterloo Computer Science - Digital Hardware 2B co-op http://hurd.dyndns.org Anyone referring to this as 'Open Source' shall be eaten by a GNU __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: init: cannot reboot
Quoting "Alfred M. Szmidt" <[EMAIL PROTECTED]>: >tty1"/libexec/getty 38400" hurdon secure > trus= >ted console > > Shouldn't "/libexec/getty 38400" be "/libexec/getty 9600"? Due to > some bug; not that I remeber what bug. 38400 always worked for me. Maybe you are confused with the maximum speed for the serial console. IIRC the serial console has a maximum speed of 9600. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
gnumach2 & the serial port
Hi
I'm try to get the serial driver from OSKit working with gnumach2.
Basically I just changed the Makefile to include the freebsd driver
library and added the oskit_freebsd_init_sio call to
gnumach/oskit/ds_osenv.c. Of course things are not that simple and so
I see a panic as soon the ttyS1 device is accessed. BTW looks this
setup correct?
hurd:~# showtrans /dev/ttyS1
/hurd/term /dev/ttyS1 device @isa@0x02f8
After several unsuccessful days trying to get gdb working, I
stepped back and started to do a simple printf debugging and gathered
some results.
When the device is accessed for the first time dev_open_com
(gnumach/oskit/ds_routines.c) is called. After some bookeeping things
the device should be opened to decide which flavor it is
(oskit_device_query). But oskit_device_query doesn't find the serial
device. Actually the serial driver implements the oskti_stream_iid
interface, so it should be found if the driver would be initialized.
The question is why it's not. The serial driver object will be fully
initialized when the bus is probed. So before we can access the
serial driver object we need to probe the bus. The code is also there
in dev_open_com but obviously never called (I have checked it with
printf):
else if (oskit_device_query (com_device, &oskit_bus_iid,
(void **) &bus) == 0)
{
printf ("XXX %s: oskit_bus_iid\n", __FUNCTION__);
if (mode & D_WRITE)
{
device_lock (dev);
mode = dev->mode & D_NODELAY;
device_unlock (dev);
if (mode & D_NODELAY)
/* Someone was waiting for us to finish opening. */
thread_wakeup ((event_t)dev);
device_deallocate (dev);
return D_READ_ONLY;
}
ops = &bus_device_ops;
rc = populate_bus (dev, bus);
oskit_bus_release (bus);
}
I don't think this code is there just for fun, so the question is how
do I trigger gnumach2 to execute this part of the code?
thanks,
daniel
ps: If someone is interested how to debug gnumach under bochs let me
know. I'm quite experinced with that now :)
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: gnumach2 & the serial port
You cited the code for oskit_bus_t devices, which has nothing to do with the serial device in particular. The code you cited is used if you do e.g. "storecat -Tdevice @". From that you can see the bus structure and then use other names starting with @ for "bus-walk" syntax as described in the comment at the top of oskit/unsupported/bus_walk_lookup.c. You might have meant to cite the code that uses oskit_stream_t. As the comment there says, that is a special case for the console. In ds_routines.c, notice the #ifdef oskit_streamdev_open parts. Perhaps you meant to cite that. It's in #ifdef because the oskit doesn't actually have an oskit_streamdev_t interface. I added that when I wrote the i8042 driver. You'll need to build your own oskit with those changes (which I must have posted here sometime in the past, or can again), and recompile oskit-mach with the new oskit/dev/stream.h header installed. That is the baseline for stream-like devices, and sufficient for the i8042 where you can get away without having any control operations. You need a lot more glue work in oskit-mach to support a set of control interfaces sufficient for serial devices. Once that is done, it will take some more hoops to use the freebsd sio driver that's in the oskit. What the oskit has is oskit_ttydev_t, which is a cop out using POSIX.1-style interfaces rather than true driver-level interfaces exposing the hardware models directly. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
