Messages in this thread | | | Date | Sat, 8 Jul 2000 03:27:57 -0700 (MST) | From | Craig Kulesa <> | Subject | waitqueue bug flagged at /usr/include/asm/semaphore.h:111 |
| |
Looks like I have a waitqueue problem. On kernel 2.4.0-test3-pre6, when sending simple ioctl's to a National Instruments LPM-16 data acquisition card, I get errors like the following:
Jul 8 00:30:50 aspc72 kernel: bad magic c1c41edc (should be c1dba160), wq bug, forcing oops. Jul 8 00:30:50 aspc72 kernel: kernel BUG at /usr/include/asm/semaphore.h:111! Jul 8 00:30:50 aspc72 kernel: invalid operand: 0000 Jul 8 00:30:50 aspc72 kernel: CPU: 0
One example of such an ioctl call is:
if (ioctl(fd, ADC_SET_INTERVAL, 30) < 0) { perror(filename); exit(2); }
where fd = open("/dev/lpm16/adc", O_RDWR) and filename is a char *, and ADC_SET_INTERVAL is defined.
At this point, the "usage" count of the lpm16 module is incremented and therefore it can't be rmmod'ed. A reboot is necessary (or is there a trick to get modules to drop dead and broken dependents?) to unload the module and try again.
The code that fails is CHECK_MAGIC, below:
extern inline void down(struct semaphore * sem) { #if WAITQUEUE_DEBUG CHECK_MAGIC(sem->__magic); #endif
Indeed, up(adc->sem) and down(adc->sem) are invoked with the ioctl's.
The same driver code, modulo the 2.4 waitqueue changes, works without incident in 2.2.14. I've done the basics in the conversion, like:
- static struct semaphore mutex = MUTEX; /* mutex change */ + DECLARE_MUTEX(mutex);
and
- struct wait_queue *wait; /* Wait queue for read() */ + wait_queue_head_t wait;
and
- adc->wait = NULL; /* while initializing the card */ + init_waitqueue_head(&adc->wait);
And I call wakeup and sleep functions as before, like:
interruptible_sleep_on(&adc->wait); /* to block and wait for more data */
Any ideas? I can't disentangle whether I'm doing the Wrong Thing, creating a race, or if the problem resides outside this driver.
I'll keep plugging away at the driver, hoping that I'll trip across something illuminating ... but I'd appreciate any enlightenment about these sorts of errors!
Thanks muchly... :)
Craig Kulesa Steward Observatory
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |