lkml.org 
[lkml]   [1998]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectIRQ 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.049 / U:0.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site