Messages in this thread | | | From | "Etienne Lorrain" <> | Date | Mon, 27 Apr 1998 17:29:32 +0001 | Subject | IRQ SMP and a question on FS |
| |
Hi,
1) Just for the people interrested in IRQ, there is a strange report for SMP bi P II 300 : When you produce an IRQ (the line directly goes active by hardware), it can be delayed quite a lot:
After udelay(1), the IRQ is still not treated. After udelay(10), the IRQ is treated (count is incremented).
The delay does not exists on 386 (few instructions before IRQ treatment) and is not seen on a UP PII 300 here.
manolow@step.es wrote: > The 'udelay(1) -> udelay(10)' change solved it!!! :-)
2) I also have a question related to FS: I am trying to debug the output of: cat /proc/tty/serial/drivers which put strange characters at the end when a lot of ports are present (SERIAL_MANY_PORTS).
I solved the "strange char" but I noticed that just "cat /proc/tty/serial/drivers" make two low-level reads, because the first read request 0 bytes to read, i.e. nbytes=0 in this call:
static ssize_t proc_file_read(struct file * file, char * buf, size_t nbytes, loff_t *ppos)
That seems to come from the "generic" FS layers, where I do not know anything. Does nbytes=0 means something special ? Is that normal behaviour ? (reading too many times the hardware is not nice in this case)
Thanks, Etienne. ----------- etienne.lorrain@ibm.net -- hdc: irq timeout: status=0xd0 { Busy } -- ide1: reset: success ----------> I like Linux !
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |