uart device numbering
Hello, I have an embedded system which is equipped with uart hardware controlled by the puc driver. There are no standard uarts at 0x3f8/0x2f8. When I boot FreeBSD 8.2 I see my uarts as devices 0..3. FreeBSD 9 shows them as 2..5. The kernel configurations are more or less identical and disabling uarts 0 1 through /boot/device.hints seems not to change anything. Is this behaviour expected/wanted? Thank you, Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
bus device/ivars
Hello, I have written a bus device driver which itself is a pci driver. Child devices may allocate resources from my bus device. My bus device does the usual management of resources through the children's ivars. My question is this: The bus device mallocs the children's ivars in bus_add_child and frees the ivars in either bus_detach or bus_child_detached. The children are added in identify methods through BUS_ADD_CHILD. As I understand the code the bus device's bus_child_detached method is called in device_delete_child only if the child device is already attached. So, there seems to be a memory leak if I delete the child device in either identify or probe. My current solution (not tested yet) is to explicitly call BUS_CHILD_DETACHED in the child device's code before calling device_delete_child. Is this the correct way or is there a more elegant/cleaner solution? I expected to find something like a BUS_DELETE_CHILD method. Thank you for any advice, Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bus device driver
No. First of all, the PCI bus driver will only allocate resources for direct children. It simply passes requests up the tree for grandchildren (this is how ISA devices behind a PCI-ISA bridge request resources). In this case, you will want to allocate resources for your BAR and your interrupt using bus_alloc_resource() during your attach routine. You can then either share the resources directly with your children by returning your resource values in your own bus_alloc_resource() method (see ppc(4) for an example of this) or subdivide your resource to make new resources (the easiest way to do this is probably to create a rman from your resource and then use rman_reserve_resource() to sub-allocate chunks of that to your children). For the interrupt resource you can just return your own resource pointer directly in your bus_alloc_resource() routine. Ok, that makes things a bit clearer. Thank you for your help! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bus device driver
John Baldwin schrieb: On Monday 13 July 2009 10:05:15 am Norbert Koch wrote: Hello. I just started to write a device driver for a multi-function pci card. This card replaces a number of independant isa hardware devices. This pci card contains memory, i/o and interrupt sources. I want my device driver to serve as a bus driver between the pci driver and the specific device drivers. Do I need more than the following (see below)? Do I have to do any bookkeeping for allocated resources? How do the child devices receive resources? Do they suballocate regions from BARs in the PCI device or is your device a subtractive bridge that will forward requests for ISA ranges and your devices all use ISA ranges? I am not quite sure that I understand what you mean. What is the difference? My old device drivers were isa based. We had all our resources in the 15-16M isa hole. So I want to change them to just allocate resources from the pci bus through the bus device driver. I thought it would be sufficient to just forward *_alloc_resource calls directly to the pci driver. Clearly, my drivers will have to know that they are just forwarded through to pci and have to know what sub-resources to allocate. -- Dipl.-Ing. Norbert Koch Entwicklung Prozessregler * *demig Prozessautomatisierung GmbH * * * * Anschrift: Haardtstrasse 40 * * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * * Geschaeftsfuehrer: Joachim Herbst, * *Winfried Held * * Telefon: +49 271 772020 * * Telefax: +49 271 74704 * * E-Mail:i...@demig.de * * http://www.demig.de * * ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bus device driver
From a hardware perspective, how do your devices know which addresses to decode? Do they consume subranges of BARs or are they assigned fixed addresses somehow? Do they have programmable decoders of some sort themselves? If you wish to have the PCI bus assign you resources then that implies that your PCI device has a BAR and that you want to request resources for that BAR and then hand out subranges of that to your children. If that is the case, then you will need to allocate the resources for the BAR for the PCI device from the PCI bus. Then your bus driver for the PCI device will need to suballoc from that BAR to your children devices. My device decodes one ram address range (16MB) and gives me one interrupt line. As my sub-devices operate on partial address areas my idea was to let them all call bus_alloc_resource() with the same rid parameter (= BAR selector) and different offsets. So the bookkeeping should be done by the pci driver, right? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
bus device driver
Hello.
I just started to write a device
driver for a multi-function pci card.
This card replaces a number of
independant isa hardware devices.
This pci card contains memory, i/o
and interrupt sources.
I want my device driver to
serve as a bus driver between
the pci driver and the specific
device drivers.
Do I need more than the following (see below)?
Do I have to do any bookkeeping for allocated resources?
/*/
int mypci_probe (device_t dev)
{
if (pci_get_vendor (dev) == MYVENDOR
pci_get_devid (dev) == MYDEVID) {
device_set_desc (dev, MYPCI bus);
return 0;
};
return ENXIO;
}
static devclass_t mypci_devclass;
/* stolen from ISA/PCI brigde */
static device_method_t mypci_methods[] =
{
/* device */
DEVMETHOD (device_probe, mypci_probe),
DEVMETHOD (device_attach, bus_generic_attach),
DEVMETHOD (device_detach, bus_generic_detach),
/* bus */
DEVMETHOD (bus_print_child, bus_generic_print_child),
DEVMETHOD (bus_alloc_resource, bus_generic_alloc_resource),
DEVMETHOD (bus_release_resource, bus_generic_release_resource),
DEVMETHOD (bus_activate_resource, bus_generic_activate_resource),
DEVMETHOD (bus_deactivate_resource, bus_generic_deactivate_resource),
DEVMETHOD (bus_setup_intr, bus_generic_setup_intr),
DEVMETHOD (bus_teardown_intr, bus_generic_teardown_intr),
{0, 0}
};
static driver_t mypci_driver = {
mypci,
mypci_methods,
0
};
/*/
Thank you for any help.
Norbert Koch
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
'libc_r: enter/leave_cancellation_point()
Hello,
I was just inspecting libc_r for trying to understand
some things and found this:
-
--- src/lib/libc_r/uthread/uthread_cond.c 2002/05/24 04:32:28 1.33
+++ src/lib/libc_r/uthread/uthread_cond.c 2002/11/13 18:13:26 1.34
...
int
-_pthread_cond_signal(pthread_cond_t * cond)
+__pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
+ const struct timespec *abstime)
+{
+ int ret;
+
+ _thread_enter_cancellation_point();
+ ret = _pthread_cond_timedwait(cond, mutex, abstime);
+ _thread_enter_cancellation_point();
+ return (ret);
+}
Shouldn't that be _thread_leave_cancellation_point() after
calling _pthread_cond_timedwait() ?
What effect should I see if this is wrong?
Best regards,
Norbert Koch
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
gdb macros xp and xxp
Hello, for learning about gdb macros I looked through gdbinit-1.i386. ( or is there some secret gdb manual that *explains* macros? :-) The macros xp and xxp calculate the number of possible arguments as: ((*(int*)$ebp)-(int)$ebp)/4-4 Let's see (assuming char* ebp): *ebp : saved ebp from previous frame *(ebp+4) : saved eip *(ebp+8): first parameter (if any) *((*ebp)-4): saved register or local variable from previous frame Right? What I do not understand is the subtraction of 4 (I expected 2). When disassembling through different portions of the kernel code and userland programs, I found pushing of none up to three extra register (ebx, esi, ebp). But that depends heavyly on compiler options, doesn't it? So, is it just a guess that there are two register variables or am I missing something? Any comments? Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
usb keyboard attach crashes process usb0 (under FreeBSD4.11)
Hello.
First of all, I understand that there is no interest here in solving
FreeBSD 4.11 problems. I only post this because there
may be a chance that this could be a problem in CURRENT too.
(If no, may be someone likes to dive into ancient software bugs ;-)
I am running an embedded system under FreeBSD 4.11.
Sometimes after booting FreBSD the USB keyboard is not found
and so not automatically attached by usbd.
If I then unplug the keyboard and plug it in again the
kernel crashes with page fault in process 3 (usb0).
I currently have no debug kernel and cannot get a
kernel crash dump as I only have some limited flash memory.
But, so far I found that the crash address is in
usbdi.c, usbd_ar_pipe() at this line:
pipe-repeat=0.
The function seems to be only called from usbd_abort_pipe().
My guess is that usbd_abort_pipe() is called from ukbd_enable_intr()
in ukbd.c with a null pointer as usbd_pipe_handle.
The parts of the source I inspected seem to be unchanged in
CURRENT, so may be someone with more understanding of the
usb code has an idea about that.
So, first of all I will add a null pointer check in my
kernel source and see if it helps.
Further information: I am seeing this with and without kbdmux
(I modified an earlier and perhaps buggy kbdmux to work under 4.11).
Without kbdmux my usbd.conf contains these lines:
device USB keyboard
devname ukbd0
attach /usr/sbin/kbdcontrol -k /dev/kdb1 /dev/console
detach /usr/sbin/kbdcontrol -k /dev/kdb0 /dev/console
I also have the following modification in ukbd.c which has been suggested
earlier on this list by Hans Petter Selasky. It reports a specific
ukbd detach event to be catched by usbd. Without that patch the detach line
in usbd.conf won't work:
--- /usr/local/jail/usr/src/sys//dev/usb/ukbd.c Mon Mar 1 21:56:02 2004
+++ ./dev/usb/ukbd.cThu Feb 23 09:57:59 2006
@@ -195,6 +195,22 @@
USB_ATTACH_SUCCESS_RETURN;
}
+
+static void
+usbd_add_device_detach_event(device_t self)
+{
+struct usb_event ue;
+
+bzero(ue, sizeof(ue));
+
+strncpy(ue.u.ue_device.udi_devnames[0],
+device_get_nameunit(self), USB_MAX_DEVNAMELEN);
+ue.u.ue_device.udi_devnames[0][USB_MAX_DEVNAMELEN - 1] = '\0';
+
+usb_add_event(USB_EVENT_DEVICE_DETACH, ue);
+}
+
+
int
ukbd_detach(device_t self)
{
@@ -219,6 +235,8 @@
return error;
DPRINTF((%s: disconnected\n, USBDEVNAME(self)));
+
+usbd_add_device_detach_event(self);
return (0);
}
Thank you for any help or comment,
Norbert Koch
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb keyboard attach crashes process usb0 (under FreeBSD4.11)
Eugene Grosbein schrieb: On Tue, Apr 03, 2007 at 09:31:05AM +, Norbert Koch wrote: First of all, I understand that there is no interest here in solving FreeBSD 4.11 problems. I only post this because there may be a chance that this could be a problem in CURRENT too. (If no, may be someone likes to dive into ancient software bugs ;-) I am running an embedded system under FreeBSD 4.11. Sometimes after booting FreBSD the USB keyboard is not found and so not automatically attached by usbd. If I then unplug the keyboard and plug it in again the kernel crashes with page fault in process 3 (usb0). You didn't mention are you running 4.11-RELEASE or 4.11-STABLE. If you are using RELEASE then you definitely should try latest 4.11-STABLE, because there were lots of anti-panic fixes to RELENG_4 for USB subsystem aftere 4.11-RELEASE. Eugene Grosbein The entry in my sup-file is RELENG_4_11, not RELENG_4_11_0_RELEASE. So I think this is 4.11-STABLE, isn't it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb keyboard attach crashes process usb0 (under FreeBSD4.11)
Eugene Grosbein schrieb: On Tue, Apr 03, 2007 at 11:37:31AM +, Norbert Koch wrote: You didn't mention are you running 4.11-RELEASE or 4.11-STABLE. If you are using RELEASE then you definitely should try latest 4.11-STABLE, because there were lots of anti-panic fixes to RELENG_4 for USB subsystem aftere 4.11-RELEASE. Eugene Grosbein The entry in my sup-file is RELENG_4_11, not RELENG_4_11_0_RELEASE. So I think this is 4.11-STABLE, isn't it? No, this is so-called '4.11-SECURITY' (unofficial name since some moment). You need RELENG_4 in sup-file to obtain 4.11-STABLE, not RELENG_4_11. I believe RELENG_4_11 has not mentioned fixes. Eugene Ok, I'll try RELENG_4. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is the proper use of mlock(2)/munlock(2)?
Daniel Rudy schrieb: Hello FreeBSD Hackers, I've been reading the man page on mlock(2) and a number of questions have arisen about it's use. I have looked at malloc and mmap, and I have not been able to figure this one out. There doesn't seem to be any compiler or library options dealing with this either. 1) How do you make sure that an allocated address range has been aligned on a multiple of the page size given FreeBSD's virtual address map? Memory allocated by calling mmap(2) is always page aligned. And its size is always rounded up to a multiple of getpagesize(3). From mmap(2): The mmap() function causes the **pages** starting at addr and continuing for at most len bytes to be mapped from the object described by fd, starting at byte offset offset. If len is not a multiple of the pagesize, the mapped region **may extend past** the specified range. Any such extension beyond the end of the mapped object will be zero-filled. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [PATCH] does ukbd delay break scan codes?
Hello Maksim, yes I too looked at ukbd code and found the same. I already put a patch on the bug list yesterday. In the mean time I compared the ukbd code to that of NetBSD and OpenBSD. Their code is quite different. I expect that the DragenFlyBSD guys may have the same problem, but did not find their cvs web site so far. Norbert Maksim Yevmenkin wrote: [...] I still do not know where it comes from, but what I found so far is, that the usb keyboard (or ukbd driver) seems to delay the break codes for keys with prefix E0 (which may or may not have anything to do with my problem). E.g., I press Keypad-Enter and see E0 1C E0 ^prefix ^make code ^prefix and nothing else. As soon as I press e.g. Enter (any key works) I see 9C 1C 9C ^break code ^make code ^delayed break code. Does anyone have an idea where that may come from? i see this to on week old -current. if ukbd(4) delays break code then this might explain state synchronization problem with kbdmux(4). i guess we should start digging into ukbd(4), starting with ukbd_interrupt() to see why this happening. just by looking at the code, i think, that ukbd_check_char() should also return true if ks_buffered_char[0] != 0, i.e. try the following untested patch i have tested the attached patch. it works for me. with this patch usb keyboard return Feb 23 17:30:54 beetle kernel: e0 1c Feb 23 17:30:54 beetle kernel: e0 9c when i press gray enter key and ps/2 keyboard return Feb 23 17:31:41 beetle kernel: e0 Feb 23 17:31:41 beetle kernel: 1c Feb 23 17:31:41 beetle kernel: e0 Feb 23 17:31:41 beetle kernel: 9c also i tried to freeze my keyboards by pressing ctrl+f1 but i can not reproduce it here. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
does ukbd delay break scan codes?
Hello, while testing an older release of kbdmux under FreeBSD4 I am seeing some strange things: I have attached a primary ps/2 and a secondary usb keyboard. I run under X (which means that kbdmux is switched to return raw key codes only) and inspect kbdmux using some printfs and xconsole. From time to time I 'freeze' the keyboard input of my X application by pressing e.g. Ctrl+Fn1 on the primary keyboard. I still see kbdmux returning scan codes. Unfreezing can be done by simply switching virtual consoles, which seems to somehow re-initialize the keyboard state. I still do not know where it comes from, but what I found so far is, that the usb keyboard (or ukbd driver) seems to delay the break codes for keys with prefix E0 (which may or may not have anything to do with my problem). E.g., I press Keypad-Enter and see E0 1C E0 ^prefix ^make code ^prefix and nothing else. As soon as I press e.g. Enter (any key works) I see 9C 1C 9C ^break code ^make code ^delayed break code. Does anyone have an idea where that may come from? Could it be a possible bug in ukbd's conversion code? (BTW: I compared ukbd.c of RELENG-4 against RELENG-6. There are no significant differences) My usb keyboard is a Cherry RS6000. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
device probe re-tried for failed isa device
Hello.
I wrote two isa device drivers A and B for FreeBSD4.11.
Both are kld-loaded and have identify() entries.
Here is the pseudo code for the identify() routines:
A_identify() /* 2 units */
{
for (i = 0; i =1; ++ i)
{
dev = BUS_ADD_CHILD(parent, ISA-ORDER_SPECULATIVE, a, 0);
If (bus_set_resource (dev, ...) != 0)
{
device_delete_child (parent, dev);
continue;
};
init (device_get_softc (dev, i));
}
}
B_identify() /* 1 unit */
{
dev = BUS_ADD_CHILD(parent, ISA-ORDER_SPECULATIVE, a, 0);
If (bus_set_resource (dev, ...) != 0)
{
device_delete_child (parent, dev);
}
}
When I kldload the two drivers I see these function calls:
1. A_identify
2. A_probe(unit 0)
3. A_attach(unit 0)
4. A_probe(unit 1)
-- fails with ENXIO because hardware is not present
5. B_identify
6. A_probe(unit 1)
-- probed again!?
7. B_probe(unit 0)
8. B_attach(unit 0)
Is it correct, that the isa bus re-tries
to probe failed devices?
The results from calling device_get_softc()
differ for the two probe() calls 4 and 6.
Is this correct?
Is it correct to initialize softc in identify()?
Should I call device_delete_child() in
probe() when the hardware fails?
Thank you,
Norbert Koch
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PXE Boot FreeBSD with Etherboot
It seems there are some problems with using pxeboot in combination with the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar to the following photo I found: http://photos.night-shade.org.uk/photo.php?photo=6364 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to get a crash dump to play with. With vmware, it seems like I should be able to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? Just my experience. I never handled to successfully pxeboot FreeBSD. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PXE Boot FreeBSD with Etherboot
It seems there are some problems with using pxeboot in combination with the network boot code from the etherboot project. I have tried many combinations of options with no success. The result is very similar to the following photo I found: http://photos.night-shade.org.uk/photo.php?photo=6364 I have tried it both on my local machine and in vmware with the same result. It seems that somehow etherboot is not setting up the environment the way pxeboot expects it too. Now the native pxe boot code in vmware does load pxeboot correctly and I have successfully booted freebsd in vmware, however I can't get the pxe boot code on my network card to load at all, hence my need for etherboot. Also, both pxeboot from FreeBSD 4.11 and 6.0-BETA2 crash the same way. I'm assuming this is really a bug in etherboot, but I'm not sure how to get a crash dump to play with. With vmware, it seems like I should be able to save a memory image to examine, but I'm not sure how to do that. Any ideas on a fix for this? Just my experience. I never handled to successfully pxeboot FreeBSD. pxeboot works fine! i have some 50 hosts pxeboot'ing that say so. it's etherboot loading pxeboot that does not work. I did not try etherboot. I tried a pc104 board with bios's internal pxe function for the integrated intel 82551/9er chip. And it is reported that e.g. linux boots successfully on these boards. I manage to boot from disk with etherboot (5.2.4), but not using pxe. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: (no subject)
#define DEVICE2SOFTC(device) ((struct dev_softc
*)device_get_softc(device))
static void dev_intr(void *arg);
struct dev_softc {
...
int rid_irq;
struct resource* res_irq;
void*intr_cookie;
...
};
static int
dev_attach(device_t device)
{
...
dev_sc-rid_irq = 0;
dev_sc-res_irq = bus_alloc_resource_any(device, SYS_RES_IRQ,
(dev_sc-rid_irq),
RF_SHAREABLE|RF_ACTIVE);
if (dev_sc-res_irq == NULL)
{
uprintf(!!! Could not map interrupt !!!\n);
goto fail;
}
if (bus_setup_intr(device, dev_sc-res_irq, INTR_TYPE_TTY,
dev_intr, dev_sc, dev_sc-intr_cookie))
{
uprintf(!!! Could not setup irq !!!\n);
goto fail;
}
...
fail:
return ENXIO;
}
static int
dev_detach(device_t device)
{
struct dev_softc *dev_sc = DEVICE2SOFTC(device);
destroy_dev(dev_sc-device);
if (bus_teardown_intr(device, dev_sc-res_irq,
dev_sc-intr_cookie) != 0);
Do you see that semicolon?
Norbert
printf(bus_teardown_intr ERROR !!!\n);
bus_release_resource(device, SYS_RES_IRQ, dev_sc-rid_irq,
dev_sc-res_irq);
...
return 0;
}
static void
dev_intr(void *arg)
{
struct dev_softc *dev_sc = (struct dev_softc *)arg;
...
}
When the driver is loaded the following message is shown:
dev0 port 0x9800-0x980f,0x9400-0x947f irq 16 at device 10.0 on pci1
i.e., as I understand, resourses are allocated normally.
But when the driver is being unloaded the following message appear:
bus_teardown_intr ERROR !!!
What have I done wrong? Hint me please how to use bus_teardown_intr()
function correctly?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: await asleep
The functions await() and asleep() in kern_synch.c
are marked as EXPERIMENTAL/UNTESTED.
Is this comment still valid? Does anyone have used
those functions successfully? Should I better not
use them in my device driver code for RELENG_4?
How do I correctly cancel a request (as I should do
according to the man page): asleep (NULL, 0, NULL, 0)?
The await family was removed in 5.x and beyond, so trying to
use them in 4.x will make your driver very unportable. There
are better ways than await to handle delayed events.
Ok, my [classical] situation is this:
1. an interrupt handler writes into a queue
2. a read function reading from the queue
pseudo code using asleep()/await() (no error handling):
read()
{
forever {
while ! empty_queue() {
uiomove(uio, ...);
if (uio-uio_resid == 0) {
return 0;
}
}
asleep( read_queue, ...);
if (empty_queue ()) {
error = await (...);
} else {
asleep (NULL, ...);
}
}
}
If I want to do that with plain tsleep() I
have to use spl??() to lock the empty_queue() call
and not lose a wakeup() from the interrupt handler.
But if I add error checks the code becomes very ugly
compared to the solution above.
I never wrote a driver under 5.X. As I understand
I would use a mutex to access the queue and call msleep()
to sleep with the mutex unlocked. (That seems to simulate
pthread_cond_timedwait(), doesn't it?)
pseudo code:
read()
{
forever {
while ! empty_queue() {
uiomove(uio, ...);
if (uio-uio_resid == 0) {
return 0;
}
}
mtx_lock (mutex);
if (empty_queue ()) {
error = msleep (queue, mutex, ...);
};
mtx_unlock (mutex);
}
}
How would you suggest to do that under 4.X
in an _elegant_ way w/o asleep/await?
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problem with pic16l_setled
You see, in C, I call the function like this (for example): void pic16l_setled(unsigned int val); pic16l_setled (0x1234); And it gets assembled to: pushl $0x1234 callpic16l_setled But it should be assembled to: pushl $0x1234 callpic16l_setled add $4,%esp /* ditch the parameter */ Usually gcc collects stack cleanups. See -fno-defer-pop. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
await asleep
Hello. The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? Any help appreciated. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: how to use the function copyout()
#define IOCTL_GET_B_IOWR(F, 127, 0x4)
I think the third parameter to _IOWR should directly specify a type,
e.g. _IOWR(F, 127, int) or _IOWR(F, 127, struct MyStruct).
driver
struct my_softc {
...
short unsigned int B;
};
...
static int
my_ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag,
struct thread *td)
{
struct my_softc *my_sc;
int unit, error;
unit = minor(dev);
my_sc = (struct my_softc *)devclass_get_softc(my_devclass, unit);
if (my_sc == NULL)
return (ENXIO);
switch(cmd)
{
...
case IOCTL_GET_B:
error = copyout(my_sc-B, data, sizeof(my_sc-B));
switch (error)
{
case 0:
printf( IOCTL_GET_B: %d\n, my_sc-B);
break;
case EFAULT:
printf(EFAULT\n);
break;
case EIO:
printf(EIO\n);
break;
case ENOMEM:
printf(ENOMEM\n);
break;
case ENOSPC:
printf(ENOSPC\n);
break;
}
break;
default:
break;
}
return 0;
}
---user program --
...
short unsigned int Data[32768];
int
main(int argc, char *argv[])
{ ...
if (ioctl(fd0, IOCTL_GET_B, Data) == -1)
err(1, IOCTL_GET_B);
...
}
---
Here I get EFAULT.
What have I done wrong? How can I do it correctly?
The caddr_t data in your ioctl is already mapped into kernel
memory. Look into the source of other device drivers. You'll
find a lot of *(int *) data = ...
So your copyout() has to fail because it tries to address
memory which is not a part of your application's
memory.
From errno(2): EFAULT: Bad address...
I have no idea if it is possible for ioctls to have mapped more
than a few 100 bytes for data exchange.
You should use read and uiomove() instead.
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: how to use the function copyout()
So if I get it right, it's impossible in FreeBSD to gain access to
64KB of user's program memory with ioctl?
My situation is this - I have a device driver for Linux. My task is
port it as it is (1:1) into FreeBSD.
In the Linux driver Ioctl is realized with the macroses _put_user
_get_user all over it. As I understand in FreeBSD their analogues are
functions described in store(9), copy(9) and fetch(9).
So the problem is that in my user program an array short unsigned int
Data[32768] is defined. I need to gain access to the array(to each
element of it) from device driver with Ioctl handler.
Is it possible to do? If yes, then how it can be done?
A better alternative that doesn't involve copying huge amounts of data
from userlevel to kernel space and vice versa is probably to pass just
the address of the area with an ioctl() and then map the appropriate
pages from the address space of the user process to an area where the
kernel can access the data directly?
I think that could work (only an idea, not tested):
struct Region
{
void * p;
size_t s;
};
#define IOBIG _IOWR ('b', 123, struct Region)
userland:
char data[1000];
struct Region r;
r.p = data;
r.s = sizeof data;
int error = ioctl (fd, IOBIG, r);
kernel:
int my_ioctl(..., caddr_t data, ...)
{
...
char data[1000];
...
return copyout(data, ((struct Region *) data)-p, ((struct Region *)
data)-s);
}
Have a try and tell us if it works.
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Posix threads: CLOCK_REALTIME/CLOCK_MONOTONIC
Hello.
I am working on a multi-threaded application which
may call settimeofday() and therefore may have
serious problems with timing calculations.
In my applications I calclulate time differences
using clock_gettime(CLOCK_MONOTONIC) under FreeBSD-5.
Under FreeBSD-4 it is a trivial kernel patch in kern_time.c
to have CLOCK_MONOTONIC, as there already is a kernel function
nanouptime().
int
clock_gettime(p, uap)
struct proc *p;
struct clock_gettime_args *uap;
{
struct timespec ats;
switch (SCARG(uap, clock_id)) {
case CLOCK_REALTIME:
nanotime(ats);
break;
case CLOCK_MONOTONIC:
nanouptime(ats);
break;
default:
return (EINVAL);
};
return (copyout(ats, SCARG(uap, tp), sizeof(ats)));
}
Looking through the sources of the various threading libraries
I found that either gettimeofday() or clock_gettime(CLOCK_REALTIME)
is used for all calculations.
I am not sure, what posix currently says about this
but found a chapter 'Condition variable wait clock' in [Butenhof] (p.359).
As I understand it, Posix.1j expects an implementation to
- at least for pthread_cond_timedwait() - use CLOCK_MONOTONIC by default.
They introduce a new function pair pthread_condattr_(get|set)clock()
to change pthread_cond_timedwait() to use either CLOCK_MONOTONIC or
CLOCK_REALTIME.
From my understanding of the threading libraries' internals, it
should be trivial to modify them to using CLOCK_MONOTONIC only, but not
quite as trivial to implement pthread_condattr_(get|set)clock().
For FreeBSD-4 I already have a modified libc_r, where I call
clock_gettime(CLOCK_MONOTONIC) once in _thread_init() and set
a global variable _sched_clkid to either CLOCK_MONOTONIC or CLOCK_REALTIME
for further calls to clock_gettime().
Any comments/ideas/opinions?
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
pxe boot failure
Hello,
I'm trying to get pxeboot running without any success so far.
I get 'BTX halted' after a register dump showing an int 6.
I read almost anything, I could find about that problem.
I tried with/without LOADER_TFTP_SUPPORT, I uncommented
those delay() lines in pxe.c and enlarged the delays.
I even doubled some of the internal buffers.
The crash is always at different locations. The last
message usually is pxe_open: gateway ip: 10.47.11.1.
Tcpdump shows no problems.
So am I just having a buggy boot prom?
My board has an intel 82559er chip and I was told
by the board's manufacturer, that linux pxeboot
does work fine, which not really helps. They have no
newer bios update and know nothing about pxe problems.
My environment is FreeBSD 4.11 with latest ISC dhcpd.
Here are my settings:
/usr/local/dhcpd.conf:
default-lease-time 600;
max-lease-time 7200;
ddns-update-style ad-hoc;
log-facility local7;
subnet 10.47.11.0 netmask 255.255.255.0 {
range dynamic-bootp 10.47.11.10 10.47.11.99;
option routers 10.47.11.1;
filename pxeboot;
next-server 10.47.11.1;
option root-path 10.47.11.1:/usr/local/diskless_root;
}
/etc/inetd.conf (for LOADER_TFTP_SUPPORT=yes):
tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s
/usr/local/diskless_root
/etc/exports:
/usr -ro -maproot=0 -alldirs -network 10.47.11.00 -mask 255.255.255.0
BTW, booting via etherboot disk works. I just have to replace pxeboot with
kernel
in dhcpd.conf.
Any hints?
Thank you,
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
uplcom callin/callout device?
Hello. I'm trying to get a sub-to-rs232 adaptor running with FreeBSD-5. The vendor of this adaptor is some chinese company named High-Edge Tech, but as usbdevs shows, it identifies as USB_VENDOR_PROLIFIC(0x067b) and USB_PRODUCT_PROLIFIC_PL2303(0x2303). For testing, I connect the adaptor with the same computer's cuaa0 and do an 'stty speed 9600 clocal' on /dev/ucom0 and /dev/cuaia0. Now, if I do 'cat /dev/ucom0' and 'cat /dev/cuaa0', I see typed characters coming in. If I try the opposite direction, nothing happens. Is that something, I should've expected, and if so, why? Does it have something to do with the difference of callin and callout devices? Can I use /dev/ucom0 only as callin device like /dev/ttyd0? Thanks, Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: using vkbd device
Hello, I did some more testing with kbdmux. 1. I wait for the screen saver becoming active. 2. I press the control key. 3. All keys, I press after that, come as control keys, e.g. I press 'j' or 'J' and see a linefeed, I press 'I' and see a tab. 4. I wait a second time for the screen saver. 5. I press control. 6. The keys are ok now. Does syscons eat up the key but sets the state in kbdmux? Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Nagios and threads
[snip] at least some assumptions that the child won't be doing much before execing or exiting. (But Im sure one of the The child process should be able to call any system calls it likes -without assuming that pthreads from the parent process have been copied over to the child process. I spose most implementations support that. regards -kamal From Programming with POSIX Threads [David R. Butenhof]: p.197-198: ... Avoid using fork in a threaded program (if you can) unless you intend to exec a new program immediately ... Pthreads does not terminate the other threads in a forked process. ... They simple cease to exist. ... The state of mutexes is not affected by a fork. If it was locked in the parent it is locked in the child! Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel panic in usb0; was: RE: using vkbd device
In gdb bt only shows two entries. The function where the panic occurred and 0x0! that is normal you don't want to jump into gdb that soon. there is hardly anything set up. use the sysctl to enter gdb later. BTW, after boot -gd, when gdb attaches I have a kernel panic too. But I can just enter continue and the kernel continues booting. Is that ok? what do you mean panic? I never use -gd, just -g then hitting ^ALT-ESC or using th esysctl makes me enter the debugger when I need to. Ok, may be, I am doing something stupidly wrong. 1. Added DIAGNOSTIC, USB_DEBUG, INVARIANT_SUPPORT, INVARIANTS to my configuration and installed a new debug kernel. 2. Booted the target to the loader prompt. unload kernel load kerneld boot -gd 3. gdb -k kernel.debug target remote /dev/cuaa0 on my workstation. 4. Arrived in Debugger() and pressed c. 5. The kernel booted. I saw the usual boot messages. After seeing IP filtering initialized..., I saw: panic: usb_cold_explore: busses to explore when !cold. 6. Found, that cold is indeed 0. 7. Booted again up to 4. and set a breakpoint at usb_cold_explore(). Pressed c and got (from gdb): Continuing. Cannot insert breakpoint 1: Cannot access memory at address 0xc01e5a37. At the same time the target console showed twice: Fatal trap 12: page fault... ... supervisor read, page not present ... So, do I have something very wrong in my kernel configuration? (See attached file) What about HZ=400 and NO_SWAPPING? Any known problems? Can't I set a breakpoint at that early stage of booting? Thanks for any help, Norbert MOPSD Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel panic in usb0; was: RE: using vkbd device
When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? sounds like he means repeatedly. yes booting with -gd drops you into the (gdb) debugger immediatly.. I presume you have a gdb looking at the serial port and have a serial debug port defined then? Yes. That's what I did: boot -gd gdb -k kernel.debug target remote /dev/cuaa0 In gdb bt only shows two entries. The function where the panic occurred and 0x0! BTW, after boot -gd, when gdb attaches I have a kernel panic too. But I can just enter continue and the kernel continues booting. Is that ok? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel panic in usb0; was: RE: using vkbd device
When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? I mean plug in / plug out, repeat for ever. can you tell what value pipe handle has? i suspect its NULL yes can you tell what value iface handle has? i suspect its NULL yes thats ok. splusb is defined as splbio oh, ok. what is your usb controller? uhci/ohci? what chip? ohci AcerLabs M5237 (Aladdin-V) please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to adjust various debug knobs with sysctl(8) to get debug traces. at this point it looks like a race condition of some sort (to me). ok, I'll try this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: using vkbd device
seems to work, although I still have some stability issues with dynamically attaching/detaching a usb keyboard. For your reference I would you share with us what sort of issues you are having? feel free to move this into private email if you are not comfortable discussing it on public mailing list. Hello Max, I'm not yet finished with that issue, but it is _not_ related to kbdmux. Here is my scenario: An embedded device with a builtin at type keyboard and a usb connector. From usbd I call attach/detach scripts for ukbd. pseudo-code Attach: kbdcontrol -K kbdmuxctl -m /dev/kbd2 -ak 0 # at kbdmuxctl -m /dev/kbd2 -ak 1 # usb kbdcontrol -k /dev/kbd2 kbdcontrol -l specificlayout Detach: kbdcontrol -K kbdmuxctl -m /dev/kbd2 -rk 0 # at kbdmuxctl -m /dev/kbd2 -rk 1 # usb kbdcontrol -k /dev/kbd0 kbdcontrol -l defaultlayout /pseudo-code The ukbd-specific detaching only works, because I implemented something in ukbd.c, that Hans Petter Selasky [EMAIL PROTECTED] suggested in thread usbd.conf: detach ukbd. (See the patch files, I posted there) When the kernel panics, it does this in usb0 kernel thread. I figured out that this is only related to connecting/disconnecting the usb keyboard. It panics without kbdmux loaded and it panics with unmodified ukbd.c. So I'll have to try to remote debug it, as my embedded device has no swap space at all and so no core dump device (256MB flash/256 MD dram). no problem. in one of your previous emails you have been concerned about possible keyboard interrupt miss (in vkbd(4)). kbdmux(4) have the same issue. is that something you just did not fix yet, or it is not a problem anymore? in my local tree a added an extra callout that goes 10 times a second and queues interrupt if needed. also i'm curious why do you use splhigh() instead of spltty()? is this an issue with usb? (not sure which spl level usb runs on in 4.x) I didn't see any missed keys. I just think it could happen in theory. There is no special reason for using splhigh(). Usb has - as far as I know - its own splusb(). I'm not a kernel expert, so I'm not sure, if spltty() would be ok here. The thing I not yet understand is, in what context will taskqueue_swi be executed? Is it some process context? Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel panic in usb0; was: RE: using vkbd device
The ukbd-specific detaching only works, because I implemented something in ukbd.c, that Hans Petter Selasky [EMAIL PROTECTED] suggested in thread usbd.conf: detach ukbd. (See the patch files, I posted there) When the kernel panics, it does this in usb0 kernel thread. I figured out that this is only related to connecting/disconnecting the usb keyboard. It panics without kbdmux loaded and it panics with unmodified ukbd.c. So I'll have to try to remote debug it, as my embedded device has no swap space at all and so no core dump device (256MB flash/256 MD dram). Hello, I am observing spurious crashes in usb0 under FreeBSD 4.11. Kernel configuration/hardware: HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz When quickly connecting/disconnecting a usb keyboard, after some time I have a panic in process 3 (usb0), either at usbd_ar_pipe+0x7 (when detaching) or at usbd_get_interface_descriptor+0x6 (when attaching). Stack traces are: (a) usbd_ar_pipe+0x7 usbd_ar_pipe(0,...) usbd_abort_pipe(0,...) ukbd_enable_intr() ukbd_term() ukbd_detach() DEVICE_DETACH() device_detach() device_delete_child() usb_discommect_port() uhub_explore() usb_discover() usb_event_thread() (b) usbd_get_interface_descriptor+0x6 usbd_get_interface_descriptor(0) ukbd_attach(c0bf3b80) DEVICE_ATTACH() device_probe_and_attach() usbd_probe_and_attach() usbd_new_device() uhub_explore() usb_discover() usb_event_thread() In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling usbd_abort_pipe(). In situation (b), ipl is at none, USB_ATTACH_START() in USB_ATTACK(ukbd) in ukbd.c seems to make problems. The above stack traces are from ddb. Booting the kernel with -gd and using gdb -k didn't give more information. I almost always get an unusable empty stack trace and different crash addresses. It seems like 'usbd_setup_pipe: failed to start endpoint, IOERROR' always comes before the crash and ipl is mostly at bio, never at usb. When I'm doing these tests, I have an ssh console connected through fxp0 where I run usbd -dv. Any idea? Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Slowing down an old program to run on a fast CPU?
You could try installing vmware and running however many copies of windows it takes to make the game playable... (i would say some other form of *BSD, but it probobly wouldn't hog as much cpu :P) ~NVX Or try qemu. I yesterday booted installed NetBSD in a qemu box running under FreeBSD5.4 ;-) Try to run it with/without 'kldload kqemu'. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: usbd.conf: detach ukbd
Else if devd is not available on 4.11 you will have to change
some code and
compile a new kernel, from what I can see.
To the file /sys/dev/usb/ukbd.c add this:
static void
usbd_add_device_detach_event(device_t self)
{
struct usb_event ue;
bzero(ue, sizeof(ue));
strlcpy(ue.u.ue_device.udi_devnames[0],
device_get_nameunit(self), USB_MAX_DEVNAMELEN) ;
usb_add_event(USB_EVENT_DEVICE_DETACH, ue);
return;
}
ukbd_detach()
{
...
usbd_add_device_detach_event(self);
return (0);
}
This will make the suggestion from Maksim work.
Ok, that seems to work with a minor change [no strlcpy]
and two additional patches in usb.h usb.c.
Usbd gets a detach event ukbd0 and another event from its fallthrough
device.
Thank you once again.
If someone is interested in the patch files against 4.11 see the attachment.
Norbert
ukbd.c.patch
Description: Binary data
usb.c.patch
Description: Binary data
usb.h.patch
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: using vkbd device
you also might want to look at experimental keyboard mux drivers. it is based on vkbd(4) and uses the idea of one super-keyboard that consumes scancodes from other keyboards. there are still a few issues i need to fix, but, in general, it works. http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz thanks, max Hello Max, I back-ported kbdmux to FreeBSD 4.11 (and stopped work on vkbd). It seems to work, although I still have some stability issues with dynamically attaching/detaching a usb keyboard. For your reference I have enclosed a patch file. Sorry for some diffs due to slightly different coding and debugging style. Thank you for any comments, Norbert kbdmux.c.patch Description: Binary data dev_debug.h Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h)
So how can I fix this in assembly. I am not an expert with inlined assembly, so maybe someone can correct me if I am wrong, but something like this needs to be added: or %ecx, %ecx jz 2 2: This is wrong beacause the result is stored in ecx. Better using JECXZ instruction before the loop. Greeting, rookie No, it's a correct method to set/reset the zero flag: (X | X) == X just as (X X) == X So, he could also write: and %ecx, %ecx. I may be wrong, but in the old 386/486 days the jecxz was even less efficient, wasn't it? history Twenty years ago, my z80 programs had a lot of lines like and a ret z Weren't there discussions, if an nmos cpu consumed more electric power with either and a or or a? ;-) /history Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: usbd.conf: detach ukbd
-Original Message- From: Maksim Yevmenkin [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 5:50 PM To: Norbert Koch Cc: [EMAIL PROTECTED] Org Subject: Re: usbd.conf: detach ukbd Norbert, when running usbd (under FreeBSD 4.11) with -dv switches I can see that a usb keyboard correctly attaches as ukbd0, but detaches as fall-through USB device. can you please tell what is in your /etc/usbd.conf? Do I just have to live with that fact or can I change that anyhow? Is that a device/device-class specific problem? does something like device USB keyboard devname ukbd[0-9]+ attach foo detach bar work? note: please replace foo and bar with actual commands you want to be executed. No it does not, which is exactly my problem. Actually, I don't have the wildcard in my devname, just ukbd0, but that doesn't make the difference, I think. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: usbd.conf: detach ukbd
I'm not sure if detach is supported like that, because the ukbd
device name
will not be passed to usbd during detach. Then one needs to
match against
the class/subclass of the USB-keyboard:
device USB keyboard
class 3
subclass 1
detach ukbd0
But from what I see, when running usbd, the class and
subclass keys of the cherry keyboard, I am testing with,
are both zero at attach and detach. So, one idea would be
to rewrite usbd.conf in the attach script. Usbd
- as it is now - does only setenv (DEVNAME), but it
would be trivial to add e.g. setenv (VENDOR) and
setenv (PRODUCTID).
Else if devd is not available on 4.11 you will have to change
some code and
compile a new kernel, from what I can see.
To the file /sys/dev/usb/ukbd.c add this:
static void
usbd_add_device_detach_event(device_t self)
{
struct usb_event ue;
bzero(ue, sizeof(ue));
strlcpy(ue.u.ue_device.udi_devnames[0],
device_get_nameunit(self), USB_MAX_DEVNAMELEN) ;
usb_add_event(USB_EVENT_DEVICE_DETACH, ue);
return;
}
ukbd_detach()
{
...
usbd_add_device_detach_event(self);
return (0);
}
This will make the suggestion from Maksim work.
A generic solution would be to call
usbd_add_device_detach_event() from the
bus_child_detached method of uhub, which must be added.
Also one can change usb_disconnect_port() to generate the event
before the
sub-devices are detached, but that might not work in all cases.
--HPS
Hmm, may be I'll try this.
Thank you very much.
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
usbd.conf: detach ukbd
Hello, when running usbd (under FreeBSD 4.11) with -dv switches I can see that a usb keyboard correctly attaches as ukbd0, but detaches as fall-through USB device. Do I just have to live with that fact or can I change that anyhow? Is that a device/device-class specific problem? Thank you, Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: usbd.conf: detach ukbd
-Original Message- From: Hans Petter Selasky [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 4:31 PM To: Norbert Koch; Freebsd-Hackers@Freebsd.Org Subject: Re: usbd.conf: detach ukbd On Thursday 09 June 2005 15:41, Norbert Koch wrote: Hello, when running usbd (under FreeBSD 4.11) with -dv switches I can see that a usb keyboard correctly attaches as ukbd0, but detaches as fall-through USB device. usbd is going to be replaced by devd. devd will catch when the keyboard device detaches. --HPS I know, but I need to solve that problem for FreeBSD 4.X. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: synchronization question about /sys/dev/vkbd/vkbd.c
My question is: Is it not possible, that vkbd_dev_intr() could be interrupted at any position before the VKBD_LOCK() and then vkbd_dev_write() called? in theory it is possible. If yes, how should vkbd_dev_write() know, that it should call task_enqueue(), as TASK is still set? well, i guess it is possible to miss interrupt in this case. also, the scancodes are not lost, they will be processed on next write. I agree, that it is hardly possible to miss an interrupt, as keys come in so slowly. But that also means if it happens, you will notice it, because you have to press an additional key. i suspect that the vkbd_dev_intr() should be interrupted exactly in between (*kbdsw[kbd-kb_index]-intr)(kbd, NULL); and VKBD_LOCK(state); Yes, precisely. yes, that could be done. it is also possible to have a callout going few times a second to check if there is a scancodes in the queue and schedule vkbd_dev_intr(). funny that atkbd(4) and ukbd(4) have just this. Thank you for your comments, Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
using vkbd device
Hello, I am trying to use vkbd to multiplex an at keyboard and an usb keyboard into syscons. Vkbd's control device's write routine expects ints to queue to the slave device. As I understand, those ints map 1:1 to the chars I read from a keyboard device, right? So I open, for example, /dev/kbd0, set it to K_RAW, read chars from it and write them as ints to vkbd's control device, right? Thank you for any help, Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
O_NONBLOCK vs IO_NDELAY: what to use where?
Hello. In releng-4 the device driver's read/write functions check for non-blocking i/o using (flag IO_NDELAY) Is that changed in current to O_NONBLOCK? As I understand: #include vnode.h IO_NDELAY for releng-4 and #include fcntl.h O_NONBLOCK for current. Correct? If yes, what exact version should I test for? Thank you, Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
synchronization question about /sys/dev/vkbd/vkbd.c
Hello. When looking at /sys/dev/vkbd/vkbd.c I found one thing, that I do not understand. There are three places, where a flag TASK is used: 1. in vkbd_dev_close(): while(state-ks_flag TASK) VKBD_SLEEP (...); 2. in vkbd_dev_write() VKBD_LOCK (); ... if (!(state-ks_flags TASK) task_enqueue(...)) state-ks_flags |= TASK; ... VKBD_UNLOCK (); 3. in vkbd_dev_intr() ... /* call intr */ ... VKBD_LOCK(); state-ks_flags = ~TASK; wakeup(...); VKBD_UNLOCK(); As I understand: vkbd_dev_write() writes data into its queue and wants vkbd_dev_intr() to process the queue. My question is: Is it not possible, that vkbd_dev_intr() could be interrupted at any position before the VKBD_LOCK() and then vkbd_dev_write() called? If yes, how should vkbd_dev_write() know, that it should call task_enqueue(), as TASK is still set? Why not always call task_enqueue() unconditionally here and leave TASK only to synchronize the close call? Thank you for any help, Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: mutual exclusion in vkbd
Thank you all. I'll try it. Norbert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Maksim Yevmenkin Sent: Tuesday, May 31, 2005 10:59 PM To: Alexander Kabaev Cc: Norbert Koch; freebsd-hackers@freebsd.org Subject: Re: mutual exclusion in vkbd Alexander Kabaev wrote: On Tue, May 31, 2005 at 09:41:18AM -0700, Maksim Yevmenkin wrote: Norbert, I am currently trying to backport vkbd to FreeBSD 4. ok Maksim Yevmenkin uses mtx_lock()/mtx_unlock() for protecting access to data structures under FreeBSD 5/6 between the device functions and the kernel thread. How should I best do this under FreeBSD 4? Would something like splhigh() work in that context? Or should I use lockmgr with LK_EXCLUSIVE/LK_RELEASE? Is there any (pseudo)process context inside a kernel task? spltty() is what you probably need to use. you could just adjust the following defines like #define VKBD_LOCK_DECL int #define VKBD_LOCK_INIT(s) /* noop */ #define VKBD_LOCK_DESTROY(s)/* noop */ #define VKBD_LOCK(s)(s)-ks_lock = spltty() #define VKBD_UNLOCK(s) splx((s)-ks_lock) #define VKBD_LOCK_ASSERT(s, w) #define VKBD_SLEEP(s, f, d, t) \ tsleep((s)-f, PCATCH | (PZERO + 1), d, t) The code above will probably crash the kernel in many spectacular and unpredictable ways. You will need to save interrupt flags locally to each VKBD_LOCK caller or they will end up restoring each other's flags. yes, you are correct. my bad :( thanks for catching this max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
mutual exclusion in vkbd
Hello. I am currently trying to backport vkbd to FreeBSD 4. Maksim Yevmenkin uses mtx_lock()/mtx_unlock() for protecting access to data structures under FreeBSD 5/6 between the device functions and the kernel thread. How should I best do this under FreeBSD 4? Would something like splhigh() work in that context? Or should I use lockmgr with LK_EXCLUSIVE/LK_RELEASE? Is there any (pseudo)process context inside a kernel task? Thank you for any help, Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in device driver strategy function: bp-b_dev==NULL
Hello,
I have written a small device driver for a static ram
based disk. The code is - more or less - derived from
Poul Henning Kamp's md device.
It is written for FreeBSD 4.X.
This device is kld-loaded and runs without any problems
with my 'standard' kernel configuration.
As soon as I boot a kernel with some debug settings the
driver crashes due to a failed assertion in my strategy
routine.
Here are the diffs between my standard(-) and debug(+) kernel configuration:
+optionsDDB
+optionsDEBUG_LOCKS
+optionsKBDIO_DEBUG
+optionsSC_DEBUG_LEVEL=5
-optionsPANIC_REBOOT_WAIT_TIME=5
+optionsPANIC_REBOOT_WAIT_TIME=60
-optionsSC_DISABLE_DDBKEY
+optionsSC_HISTORY_SIZE=1000
-device sio0at isa? port IO_COM1 flags 0x10 irq 4
+device sio0at isa? port IO_COM1 flags 0x90 irq 4
Some of the common options are
HZ=400, DEVICE_POLLING, KTRACE, NO_SWAPPING, SOFTUPDATES, UFS_DIRHASH
Here is my debugging output:
(kgdb) bt
#1 0xc0153318 in panic (fmt=0xc0cabc80 \sram.c\, 362: sram_strategy:
bp-b_dev==NULL)
at ../../kern/kern_shutdown.c:593
#2 0xc0cab2e8 in sram_strategy (bp=0xc349bdc0) at sram.c:362
#3 0xc015ccad in diskstrategy (bp=0xc349bdc0) at ../../kern/subr_disk.c:251
#4 0xc0224952 in dsinit (dev=0xc0ca3e80, lp=0xc0c240d0, sspp=0xc0c240cc) at
../../kern/subr_diskmbr.c:191
#5 0xc015dbfa in dsopen (dev=0xc0ca3e80, mode=8192, flags=0,
sspp=0xc0c240cc, lp=0xc0c240d0)
at ../../kern/subr_diskslice.c:696
#6 0xc015cb36 in diskopen (dev=0xc0ca3e80, oflags=1, devtype=8192,
p=0xc7bb5260) at ../../kern/subr_disk.c:196
#7 0xc018d72d in spec_open (ap=0xc8908dfc) at
../../miscfs/specfs/spec_vnops.c:193
#8 0xc018d62d in spec_vnoperate (ap=0xc8908dfc) at
../../miscfs/specfs/spec_vnops.c:119
#9 0xc01ccfb5 in ufs_vnoperatespec (ap=0xc8908dfc) at
../../ufs/ufs/ufs_vnops.c:2394
#10 0xc0189641 in vn_open (ndp=0xc8908ec8, fmode=1, cmode=385) at
vnode_if.h:189
#11 0xc01854ec in open (p=0xc7bb5260, uap=0xc8908f80) at
../../kern/vfs_syscalls.c:1035
#12 0xc02193f9 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134543916,
tf_esi = -1077936648, tf_ebp = -1077936736, tf_isp = -930050092,
tf_ebx = 0, tf_edx = 134543904,
tf_ecx = -13, tf_eax = 5, tf_trapno = 0, tf_err = 2, tf_eip =
671988064, tf_cs = 31, tf_eflags = 582,
tf_esp = -1077937068, tf_ss = 47}) at ../../i386/i386/trap.c:1255
#13 0xc020c685 in Xint0x80_syscall ()
(kgdb) frame 2
(kgdb) p *bp
$2 = {b_hash = {le_next = 0xc3504000, le_prev = 0xc0286c0c}, b_vnbufs =
{tqe_next = 0x0, tqe_prev = 0x0},
b_freelist = {tqe_next = 0xc349bf18, tqe_prev = 0xc026e9e8}, b_act =
{tqe_next = 0x0, tqe_prev = 0x0},
b_flags = 1122304, b_qindex = 0, b_xflags = 0 '\000', b_lock =
{lk_interlock = {lock_data = 0},
lk_flags = 1024, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount
= 1, lk_prio = 20,
lk_wmesg = 0xc0239afc bufwait, lk_timo = 0, lk_lockholder = 134},
b_error = -1071408864,
b_bufsize = -1071408848, b_runningbufspace = 286, b_bcount = 0, b_resid =
512, b_dev = 0x0,
b_data = 0x200 Address 0x200 out of bounds, b_kvabase = 0x0, b_kvasize
= -1060487424,
b_lblkno = -1060470784, b_blkno = -1014542336, b_offset = 16384, b_iodone
= 0, b_iodone_chain = 0x,
b_vp = 0x, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred
= 0x0, b_pblkno = 0,
b_saveaddr = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_caller1 = 0x0,
b_caller2 = 0x0, b_pager = {
pg_spc = 0x0, pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first =
0x0, tqh_last = 0x0},
cluster_entry = {tqe_next = 0x0, tqe_prev = 0x0}}, b_pages = {0x0
repeats 32 times}, b_npages = 0,
b_dep = {lh_first = 0x0}, b_chain = {parent = 0x0, count = 0}}
And here is the source of the beginning of my strategy routine:
static void
sram_strategy (struct buf * bp)
{
intrmask_t s;
struct sram_softc * sc;
ASSERT (bp != NULL, sram_strategy: bp==NULL);/* #1 */
ASSERT (bp-b_dev != NULL, sram_strategy: bp-b_dev==NULL);/* #2 */
sc = bp-b_dev-si_drv1;
ASSERT (sc != NULL, sram_strategy: bp-b_dev-si_drv1==NULL);/* #3 */
DPRINTF (9, sram_strategy: (%p) %s %lx, %d, %ld, %p)\n,
bp,
devtoname (bp-b_dev),
bp-b_flags,
bp-b_blkno,
bp-b_bcount / DEV_BSIZE,
bp-b_data);
s = splbio ();
...
ASSERT #2 fails. Any idea?
Thank you for any help,
Norbert Koch
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: panic in device driver strategy function: bp-b_dev==NULL
Hello, I have written a small device driver for a static ram based disk. The code is - more or less - derived from Poul Henning Kamp's md device. It is written for FreeBSD 4.X. This device is kld-loaded and runs without any problems with my 'standard' kernel configuration. As soon as I boot a kernel with some debug settings the driver crashes due to a failed assertion in my strategy routine. Hello again, I played around with configuration switches and found, that without option DEBUG_LOCKS all is ok. Any idea? Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
parameters for tsleep(9)
Hello.
I am just writing a device driver for the i82527 (can-bus) chip.
For testing I need the driver to poll the chip instead of running
in interrupt mode.
My dev_t read function basically looks like this:
for (;;)
{
while (chip_has_data(...))
{
read_chip_data(...);
error = do_uiomove(...);
if (error || enough_read(...))
{
return error;
}
};
if (do_not_block_on_read(...))
{
return EWOULDBLOCK;
}
error = tsleep (XXX, PCATCH|PWAIT, canrd, hz / 10);
if (error != EWOULDBLOCK)
{
return error;
}
}
XXX should be 'something' which could be used
as parameter to wakeup(9), I read in tsleep(9).
In the kernel source tree I found one
place where tsleep _only_ sleeps: in sys/isa/ppc.c
(which already seems to be in the attic [?] but
still is in my computer's source tree).
Here, the first parameter was set to NULL.
Doing this I found, that tsleep immediately
returns 0 (which means: wakueup was called)
_without_ waiting. I even crashed or
froze the kernel by calling tsleep (NULL, ...)
for a random number of times. After changing
this to the address of the read-function itself,
all worked fine. No more crashes.
Just for my understanding: Is this a bug?
Does the first parameter have to point to
something useful?
Is it allowed to point it to a code position?
Or should I use some kind of dummy data in
the softc structure instead?
What about the second parameter: Is PWAIT
ok here or should I use PZERO or whatever?
(And btw, why has ppc.c been removed?)
Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
A program to automatically switch keyboards for syscons
Hello. For an embedded system I need FreeBSD to accept input from two keyboards at the same time. As syscons cannot do that and it is obviously not trivial to change that, I wrote the enclosed program. After switching syscons to the first keyboard available, it calls select for the other keyboard(s). If there is any input available the active keyboard for syscons is changed. This works, more or less. (I am using FreeBSD 4.10) The problem is that after switching, the first key pressed on the new keyboard is lost. Does anyone have an idea about that? Am I doing something wrong? Any other - possibly better - idea to have more than one keyboard at the same time? You may notice, that I flush the old keyboard after detaching and before re-attaching the new one. I do that because I saw an endless switching (kbd1-kbd0-kbd1-kbd0-...) when not doing that. I do not understand, why select should return anything from a keyboard where I do not press any key. May be, I am missing something. Any help appreciated. Thanks, Norbert P.S.: If there is any interest, I could make a port out of that program. kbautosw.c Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: A program to automatically switch keyboards for syscons
May be, I should do an ioctl KDSKBMODE to K_RAW to not miss any kind of keyboard event? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
using two keyboards at the same time
Hello.
I know, the syscons driver does not allow to have
two keyboards attached at the same time.
So my idea was to have a userland application
which polls the keyboard(s) currently _not_
attached to syscons using select(2) or poll(2)
and then switching to an active keyboard.
From reading the source code under /sys/dev/kbd
I thought this should work.
I made this simple test: I attached syscons to
/dev/kbd1 and ran cat /dev/kbd0.
As expected I saw characters
coming from both keyboards.
Then I wrote a program to do the selecting and switching.
Well, it does not work (under FreeBSD 4.10).
Select never returns. As I understand
it a device driver should return immediately
if it does not support poll.
Does anyone have an idea?
May be I just made some stupid mistake.
Thank you.
#include fcntl.h
#include sys/types.h
#include sys/stat.h
#include sys/time.h
#include machine/console.h
#include unistd.h
#include stdio.h
#include stdlib.h
#include string.h
#include errno.h
#define MAX_DEVICES 5
#define TEST
#define STR(x) #x
#define XSTR(x) STR (x)
static void usage (void)
{
fprintf (stderr,
usage: autosw [ -D ] [ -d ] [ [ -f device] ... ]\n
-D : do not detach\n
-d : enable debug output\n
-f : specify keyboard device (up to XSTR (MAX_DEVICES) )\n
if no keyboard devices specified\n
/dev/kbd0 and /dev/kbd1 are polled\n);
exit (1);
}
/*
* borrowed from /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c
*/
static int set_keyboard_fd (int fd)
{
keyboard_info_t info;
if (ioctl (fd, KDGKBINFO, info) == -1)
{
close (fd);
return -1;
};
ioctl (fd, CONS_RELKBD, 0);
close (fd);
if (ioctl (0, CONS_SETKBD, info.kb_index) == -1)
{
return -1;
};
return 0;
}
static int set_keyboard (char * device)
{
int fd;
fd = open (device, O_RDONLY);
if (fd 0)
{
return -1;
};
return set_keyboard_fd (fd);
}
int main (int argc, char ** argv)
{
char * devices[MAX_DEVICES];
fd_set ifds, ofds;
int ch, i, fd, maxfd, no_devices = 0, debug = 0, detach = 1, detached = 0;
struct stat sb;
while ((ch = getopt (argc, argv, Ddf:h)) != -1)
{
switch (ch)
{
case 'D':
detach = 0;
break;
case 'd':
++ debug;
break;
case 'f':
if (no_devices = MAX_DEVICES)
{
fprintf (stderr, too many devices\n);
exit (1);
};
if (stat (optarg, sb) 0)
{
fprintf (stderr, cannot stat %s: %s\n, optarg, strerror
(errno));
exit (1);
};
if ((sb.st_mode S_IFCHR) == 0)
{
fprintf (stderr, not a character device: %s\n, optarg);
exit (1);
};
devices[no_devices ++] = strdup (optarg);
continue;
case 'h':
case '?':
default:
usage ();
}
};
/*
* no devices specified, use default
*/
if (no_devices == 0)
{
devices[0] = /dev/kbd0;
devices[1] = /dev/kbd1;
no_devices = 2;
if (debug)
{
fprintf (stderr, using default devices\n);
};
};
/*
* switch syscons to first keyboard
*/
#ifndef TEST
for (i = -1; ++ i no_devices;)
#else
for (i = 1; i == 1; ++ i)
#endif
{
if (set_keyboard (devices[i]) == 0)
{
if (debug)
{
fprintf (stderr, selecting keyboard %s\n, devices[i]);
};
break;
}
};
for (;;)
{
/*
* try to open all devices for select
*/
FD_ZERO ( ifds);
maxfd = -1;
#ifndef TEST
for (i = -1; ++ i no_devices;)
#else
for (i = 0; i == 0; ++ i)
#endif
{
fd = open (devices[i], O_RDONLY|O_NONBLOCK);
if (fd = 0)
{
if (debug)
{
fprintf (stderr, polling %s, devices[i]);
};
if (debug = 2)
{
fprintf (stderr, fd=%u, fd);
};
if (debug)
{
fprintf (stderr, \n);
};
FD_SET (fd, ifds);
if (fd maxfd)
{
maxfd = fd;
}
}
};
if (maxfd 0)
{
fprintf (stderr, could not open any device\n);
exit (1);
};
if (detach ! detached ! debug)
{
daemon (0, 0);
detached = 1;
};
ofds = ifds;
if (debug = 2)
{
fprintf (stderr, polling maxfd=%u\n, maxfd);
};
/*
* !!! never returns !!!
*/
if (select (maxfd, ofds, NULL, NULL, NULL) == -1)
{
/*
* got signal
*/
exit (0);
};
if (debug)
{
fprintf (stderr, polled successfully\n);
};
/*
* find first keyboard where select returned some activity
*/
for (fd = -1; ++ fd maxfd; ++ fd)
{
if (FD_ISSET (fd, ofds))
{
if (debug)
{
fprintf (stderr, switching keyboard\n);
};
if (debug = 2)
{
fprintf (stderr,
