RE: [PATCH] large offset llseek breaks for device special files on ac series
>Here is the patch. Sorry, at least most of the patch was there. Here is the rest: diff -r -u -N -b linux-2.4.5.ac16/include/linux/fs.h linux-2.4.5.ac16.patched/include/linux/fs.h --- linux-2.4.5.ac16/include/linux/fs.h Tue Jun 19 15:12:50 2001 +++ linux-2.4.5.ac16.patched/include/linux/fs.h Tue Jun 19 18:28:47 2001 @@ -1336,6 +1336,7 @@ extern void do_generic_file_read(struct file *, loff_t *, read_descriptor_t *, read_actor_t); extern ssize_t generic_read_dir(struct file *, char *, size_t, loff_t *); +extern loff_t generic_file_llseek(struct file *, loff_t, int); extern int generic_file_open(struct inode *, struct file *); extern struct file_operations generic_ro_fops; diff -r -u -N -b linux-2.4.5.ac16/kernel/ksyms.c linux-2.4.5.ac16.patched/kernel/ksyms.c --- linux-2.4.5.ac16/kernel/ksyms.c Tue Jun 19 15:13:08 2001 +++ linux-2.4.5.ac16.patched/kernel/ksyms.c Wed Jun 20 01:41:21 2001 @@ -245,6 +245,7 @@ EXPORT_SYMBOL(vfs_unlink); EXPORT_SYMBOL(vfs_rename); EXPORT_SYMBOL(vfs_statfs); +EXPORT_SYMBOL(generic_file_llseek); EXPORT_SYMBOL(generic_read_dir); EXPORT_SYMBOL(__pollwait); EXPORT_SYMBOL(poll_freewait); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
In article <[EMAIL PROTECTED]>, Zack Weinberg <[EMAIL PROTECTED]> wrote: >On Tue, Jun 19, 2001 at 07:52:25PM -0700, David S. Miller wrote: >> >> Zack Weinberg writes: >> > It *has* been fixed in 2.4, though. Some sort of compatibility issue? >> >> No, some kind of "it doesn't matter" issue. > >I can demonstrate user code that behaves differently under 2.2 than >2.4. The example I have (appended) doesn't suffer data loss, but I >bet I could make one that did. Hey, I can demonstrate user code that behaves differently depending on what compiler options were used etc. Hint: "undefined behaviour". If somebody passes in a bad pointer to a system call, you've just invoced the rule of "the kernel _may_ be nice to you, but the kernel might just consider you a moron and tell you it worked". There is no "lost data" or anything else. You've screwed yourself, and you threw the data away. Don't blame the kernel. And before you say "it has to return EFAULT", check the standards, and think about the case of libraries vs system calls - and how do you tell them apart? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac16 -- "proc_get_inode" still unresolved in /net/wan/comx.o
depmod: *** Unresolved symbols in /lib/modules/2.4.5-ac16/kernel/drivers/net/wan/comx.o depmod: proc_get_inode - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - Linux 2.4.5; devfs support for /dev/raw
Hi,
I have written this patch so that /dev/raw now appears in a devfs
filesystem. I haven't tried to support the /dev/rawN devices because
I'm not sure that it would be worthwhile. (Seeing as you need to bind
them by hand manually anyway.)
Cheers,
Chris
--- linux-2.4.5/drivers/char/raw.c.orig Sat May 26 11:58:45 2001
+++ linux-2.4.5/drivers/char/raw.c Sat Jun 16 20:54:10 2001
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#define dprintk(x...)
@@ -28,6 +29,7 @@
} raw_device_data_t;
static raw_device_data_t raw_devices[256];
+static const char RAW_DEVICE_NAME[] = "raw";
static ssize_t rw_raw_dev(int rw, struct file *, char *, size_t, loff_t *);
@@ -53,7 +55,11 @@
static int __init raw_init(void)
{
int i;
- register_chrdev(RAW_MAJOR, "raw", _fops);
+ devfs_register_chrdev(RAW_MAJOR, RAW_DEVICE_NAME, _fops);
+ devfs_register(NULL, RAW_DEVICE_NAME, DEVFS_FL_DEFAULT,
+ RAW_MAJOR, 0,
+ S_IFCHR | S_IRUSR | S_IWUSR,
+ _fops, NULL);
for (i = 0; i < 256; i++)
init_MUTEX(_devices[i].mutex);
--AA136AFB19.993012573/zappa.oak.suse.com--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Early flush (was: spindown)
Daniel Phillips writes: > I never realized how much I didn't like the good old 5 second delay > between saving an edit and actually getting it written to disk until > it went away. Now the question is, did I lose any performance in > doing that. What I wrote in the previous email turned out to be > pretty accurate, so I'll just quote it Starting I/O immediately if there is no load sounds nice. However, what about the other case, when the disc is already spun down (and hence there's no I/O load either)? I want the system to avoid doing writes while the disc is spun down. I'm quite happy for the system to accumulate dirtied pages/buffers, reclaiming clean pages as needed, until it absolutely has to start writing out (or I call sync(2)). Right now I hack that by setting bdflush parameters to 5 minutes. But that's not ideal either. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
On Tue, Jun 19, 2001 at 07:52:25PM -0700, David S. Miller wrote:
>
> Zack Weinberg writes:
> > It *has* been fixed in 2.4, though. Some sort of compatibility issue?
>
> No, some kind of "it doesn't matter" issue.
I can demonstrate user code that behaves differently under 2.2 than
2.4. The example I have (appended) doesn't suffer data loss, but I
bet I could make one that did.
I don't think it's a security hole, if that's what you mean.
zw
/* Pointer validation hack. Expected output is
* |
* |
* |{null ptr}
* |{unmapped: 0xAFAFAFAF}
* |{unmapped: 0xA5A5A5A5}
* |{unmapped: 0xCDEFABCD}
* |{unaligned: 0xBB2B}
*
* Under Linux 2.2, will print a blank line instead of each
* {unmapped: 0x...}.
*/
#include
#include
#include
static const char *
validate_ptr(void *p, size_t align)
{
static int pipes[2];
static int setup = 0;
char dummy;
if(!setup)
{
if(pipe(pipes))
abort();
setup = 1;
}
if(p == NULL)
return "{null ptr}";
if((unsigned long)p & (align - 1))
return "{unaligned: 0x%lX}";
if(write(pipes[1], p, 1) != 1)
return "{unmapped: 0x%lX}";
/* clear out the byte we just wrote down the pipe */
read(pipes[0], , 1);
return 0;
}
int
main(void)
{
char blah = 'x';
char *a, *b, *c, *d, *e, *f;
const char *msg;
a =
b = malloc(1);
c = (char *) 0;
d = (char *) 0xafafafaf;
e = (char *) 0xa5a5a5a5;
f = (char *) 0xcdefabcd;
#define TEST(x, y) \
if((msg = validate_ptr(x, y))) printf(msg, (unsigned long)x); \
putchar('\n');
TEST(a, 1);
TEST(b, 4);
TEST(c, 1);
TEST(d, 1);
TEST(e, 1);
TEST(f, 1);
TEST(a, 2);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: softirq in pre3 and all linux ports
On Wed, Jun 20, 2001 at 01:33:19PM +1000, Paul Mackerras wrote: > Well, I object to the "without thinking" bit. [..] agreed, apologies. > BHs disabled is buggy - why would you want to do that? And if we do tasklet_schedule > want to allow that, shouldn't we put the check in raise_softirq or the > equivalent, to get the minimum latency? We should release the stack before running the softirq (some place uses softirqs to release the stack and avoid overflows). > Soft irqs should definitely not be much heavier than an irq handler, > if they are then we have implemented them wrongly somehow. ip + tcp are more intensive than just queueing a packet in a blacklog. That's why they're not done in irq context in first place. > ksoftirqd seems like the wrong solution to the problem to me, if we > really getting starved by softirqs then we need to look at whether > whatever is doing it should be a kernel thread itself rather than > doing it in softirqs. Do you have a concrete example of the > starvation/live lockup that you can describe to us? I don't have gigabit ethernet so I cannot flood my boxes to death. But I think it's real, and a softirq marking itself runnable again is another case to handle without live lockups or starvation. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: softirq in pre3 and all linux ports
Andrea Arcangeli writes: > With pre3 there are bugs introduced into mainline that are getting > extended to all architectures. > > First of all nucking the handle_softirq from entry.S is wrong. ppc > copied without thinking and we'll need to resurrect it too for example Well, I object to the "without thinking" bit. It seems to me that code that raises a softirq without having either hard interrupts or BHs disabled is buggy - why would you want to do that? And if we do want to allow that, shouldn't we put the check in raise_softirq or the equivalent, to get the minimum latency? > Fourth if the tasklet or softirq or bottom half hander is been marked > running again because of another even (like a nested irq) the kernel can > starve userspace too. (softirqs are much heavier than the irq handler so > it can also live lockup much more easily this way) Soft irqs should definitely not be much heavier than an irq handler, if they are then we have implemented them wrongly somehow. > So I recommend Linus merging this patch that fixes all the above > mentioned bugs (the anti starvation/live lockup logic is called > ksoftirqd): ksoftirqd seems like the wrong solution to the problem to me, if we really getting starved by softirqs then we need to look at whether whatever is doing it should be a kernel thread itself rather than doing it in softirqs. Do you have a concrete example of the starvation/live lockup that you can describe to us? Regards, Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 08:04:42PM -0700, Larry McVoy wrote: > On the other hand, the fact that it doesn't exist on other platforms sort > of means that it isn't going anywhere. In a sick sort of way, the most > likely way to make this happen is to get Microsoft to do it and then Linux > will do it as well and then the Solaris jocks will also fall in line. The > only problem with that is that Microsoft can't design an OS interface to save > their lives, so maybe Linux _should_ do it first. world domination has to start somewhere... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Tu amigo tiene un amigo, y el amigo de tu amigo tiene otro amigo; por consiguiente, sé discreto. -- Proverbio judío. PGP signature
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 10:57:38PM -0400, Michael Rothwell wrote: > On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote: > > > Linux inherits several unix properties which are not friendly to good state > > based programming - lack of good AIO for one. > > Oh, how I would love for select() and poll() to work on files... or for > any other working AIO mothods to be present. > > What would get broken if things were changed to let select() work for > filesystem fds? I asked Linus for this a long time ago and he pointed out that you couldn't make it work over NFS, at least not nicely. It does seem like that could be worked around by having a "poll daemon" which knew about all the things being waited on and checked them. Or something. I'd like it too. And I'd like a callback for iocompletion, a way to do preread(fd, len). On the other hand, the fact that it doesn't exist on other platforms sort of means that it isn't going anywhere. In a sick sort of way, the most likely way to make this happen is to get Microsoft to do it and then Linux will do it as well and then the Solaris jocks will also fall in line. The only problem with that is that Microsoft can't design an OS interface to save their lives, so maybe Linux _should_ do it first. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Repeatable hard locks on console switch. XFree 4.1.0
Dear All; I can fire up XFree4.1.0 on one or several virtual consoles, and switch between them, and text consoles to my hearts content. However, if the X server exits everything is still fine, _except_ any attempt to switch consoles at this point will lock up the machine completely. (eg. numlock doesnt work, nor does magic sysrq, unpingable, no logs) [ Trivially the problem manifests itself when one logs in via xdm, then logs out. You can log back on just fine, but if you try to switch virtual consoles after this it locks.] XFree3.3.6 works good for me. XFree4.1.0 manifests the problem on 2.4.5, and 2.2.18. I128 server. Any comments or suggestions welcome Thanks; Paul [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote: > Linux inherits several unix properties which are not friendly to good state > based programming - lack of good AIO for one. Oh, how I would love for select() and poll() to work on files... or for any other working AIO mothods to be present. What would get broken if things were changed to let select() work for filesystem fds? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 10:23:47PM -0400, John Weber wrote:
> On a related note... is System.map also necessary? Anyone care to explain
Debugging. ksymoops and klogd can both make use of it.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
Zack Weinberg writes: > It *has* been fixed in 2.4, though. Some sort of compatibility issue? No, some kind of "it doesn't matter" issue. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
On Tue, Jun 19, 2001 at 07:16:23PM -0700, David S. Miller wrote: > > Zack Weinberg writes: > > The anonymous pipe code in 2.2 does not check the return value of > > copy_*_user. This can lead to silent loss of data. > > I remember Andrew Tridgell (cc:'d) spotting this a long time > ago, and we didn't fix it, and I forget what the reason was. It *has* been fixed in 2.4, though. Some sort of compatibility issue? -- zw This APT has Super Cow Powers. -- apt-get 0.5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
Alan Cox wrote: >>I am trying to compile the 2.2.19 kernel one one machine for installation >>on another. I believe I need to do more than just copy over bzImage and >>modify lilo.conf, but I don't know what. Is there documentation somewhere >>on how to do this? Thanks. >> > > Other than making sure you configure it for the box it will eventually run > on - nope you have it all sorted. If you use modules you'll want to install > the modules on the target machine too On a related note... is System.map also necessary? Anyone care to explain what System.map does? I have noticed that my kernel works with or without that file, but just figured it was a good question to ask in this thread. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 06:30:54PM -0700, Ben Greear wrote:
> Yeah, and we are young and prolific too, so you better watch out! :)
Prolific != competent.
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.2 PATCH: check return from copy_*_user in fs/pipe.c
The anonymous pipe code in 2.2 does not check the return value of
copy_*_user. This can lead to silent loss of data.
The appended patch fixes the bug. It has been in continuous use on my
machine since May 13 (2.2.19) with no problems. It will apply to any
2.2 kernel from at least 2.2.18, there have been no changes to pipe.c
since then.
2.4 pipe.c has been completely rewritten and does not have the bug.
--
zw > Having been converted to bagels in the US, ...
Good Lord! You must have -really- offended a Jewish wizard.
-- Niall McAuley and Kip Williams in rec.arts.sf.fandom
--- pipe.c.zw Tue Jun 19 18:37:13 2001
+++ pipe.c Tue Jun 19 18:37:16 2001
@@ -31,10 +31,9 @@
size_t count, loff_t *ppos)
{
struct inode * inode = filp->f_dentry->d_inode;
- ssize_t chars = 0, size = 0, read = 0;
+ ssize_t chars = 0, size = 0, read = 0, nleft = 0;
char *pipebuf;
-
if (ppos != >f_pos)
return -ESPIPE;
@@ -59,19 +58,22 @@
interruptible_sleep_on(_WAIT(*inode));
}
PIPE_LOCK(*inode)++;
- while (count>0 && (size = PIPE_SIZE(*inode))) {
+ while (count>0 && (size = PIPE_SIZE(*inode)) && nleft == 0) {
chars = PIPE_MAX_RCHUNK(*inode);
if (chars > count)
chars = count;
if (chars > size)
chars = size;
- read += chars;
pipebuf = PIPE_BASE(*inode)+PIPE_START(*inode);
+
+ nleft = copy_to_user(buf, pipebuf, chars);
+ chars -= nleft;
+
+ read += chars;
PIPE_START(*inode) += chars;
PIPE_START(*inode) &= (PIPE_BUF-1);
PIPE_LEN(*inode) -= chars;
count -= chars;
- copy_to_user(buf, pipebuf, chars );
buf += chars;
}
PIPE_LOCK(*inode)--;
@@ -80,6 +82,8 @@
UPDATE_ATIME(inode);
return read;
}
+ if (nleft)
+ return -EFAULT;
if (PIPE_WRITERS(*inode))
return -EAGAIN;
return 0;
@@ -89,7 +93,7 @@
size_t count, loff_t *ppos)
{
struct inode * inode = filp->f_dentry->d_inode;
- ssize_t chars = 0, free = 0, written = 0, err=0;
+ ssize_t chars = 0, free = 0, written = 0, err = 0, nleft = 0;
char *pipebuf;
if (ppos != >f_pos)
@@ -127,29 +131,38 @@
interruptible_sleep_on(_WAIT(*inode));
}
PIPE_LOCK(*inode)++;
- while (count>0 && (free = PIPE_FREE(*inode))) {
+ while (count>0 && (free = PIPE_FREE(*inode)) && nleft == 0) {
chars = PIPE_MAX_WCHUNK(*inode);
if (chars > count)
chars = count;
if (chars > free)
chars = free;
pipebuf = PIPE_BASE(*inode)+PIPE_END(*inode);
+
+ nleft = copy_from_user(pipebuf, buf, chars);
+ chars -= nleft;
written += chars;
PIPE_LEN(*inode) += chars;
count -= chars;
- copy_from_user(pipebuf, buf, chars );
buf += chars;
}
PIPE_LOCK(*inode)--;
wake_up_interruptible(_WAIT(*inode));
free = 1;
+ if (nleft) {
+ err = -EFAULT;
+ goto errout;
+ }
}
- inode->i_ctime = inode->i_mtime = CURRENT_TIME;
- mark_inode_dirty(inode);
errout:
+ if (written) {
+ inode->i_ctime = inode->i_mtime = CURRENT_TIME;
+ mark_inode_dirty(inode);
+ err = written;
+ }
up(>i_atomic_write);
down(>i_sem);
- return written ? written : err;
+ return err;
}
static long long pipe_lseek(struct file * file, long long offset, int orig)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] Early flush (was: spindown)
I never realized how much I didn't like the good old 5 second delay between
saving an edit and actually getting it written to disk until it went away.
Now the question is, did I lose any performance in doing that. What I wrote
in the previous email turned out to be pretty accurate, so I'll just quote it
to keep it together with the patch:
> I'm now in the midst of hatching a patch. [1] The first thing I had to do
> is go explore the block driver code, yum yum. I found that it already
> computes the statistic I'm interested in, namely queued_sectors, which is
> used to pace the IO on block devices. It's a little crude - we really want
> this to be per-queue and have one queue per "spindle" - but even in its
> current form it's workable.
>
> The idea is that when queued_sectors drops below some threshold we have
> 'unused disk bandwidth' so it would be nice to do something useful with it:
>
> 1) Do an early 'sync_old_buffers'
> 2) Do some preemptive pageout
>
> The benefit of (1) is that it lets disks go idle a few seconds earlier, and
> (2) should improve the system's latency in response to load surges. There
> are drawbacks too, which have been pointed out to me privately, but they
> tend to be pretty minor, for example: on a flash disk you'd do a few extra
> writes and wear it out ever-so-slightly sooner. All the same, such special
> devices can be dealt easily once we progress a little further in improving
> the kernel's 'per spindle' intelligence.
>
> Now how to implement this. I considered putting a (newly minted)
> wakeup_kflush in blk_finished_io, conditional on a loaded-to-unloaded
> transition, and that's fine except it doesn't do the whole job: we also
> need to have the early flush for any write to a disk file while the disks
> are lightly loaded, i.e., there is no convenient loaded-to-unloaded
> transition to trigger it. The missing trigger could be inserted into
> __mark_dirty, but that would penalize the loaded state (a little, but
> that's still too much). Furthermore, it's probably desirable to maintain a
> small delay between the dirty and the flush. So what I'll try first is
> just running kflush's timer faster, and make its reschedule period vary
> with disk load, i.e., when there are fewer queued_sectors, kflush looks at
> the dirty buffer list more often.
>
> The rest of what has to happen in kflush is pretty straightforward. It
> just uses queued_sectors to determine how far to walk the dirty buffer
> list, which is maintained in time-since-dirtied order. If queued_sectors
> is below some threshold the entire list is flushed. Note that we want to
> change the sense of b_flushtime to b_timedirtied. It's more efficient to
> do it this way anyway.
>
> I haven't done anything about preemptive pageout yet, but similar ideas
> apply.
>
> [1] This is an experiment, do not worry, it will not show up in your tree
> any time soon. IOW, constructive criticism appreciated, flames copied to
> /dev/null.
I originally intended to implement a sliding flush delay based on disk load.
This turned out to be a lot of work for a hard-to-discern benefit. So the
current approach has just two delays: .1 second and whatever the bdflush
delay is set to. If there is any non-flush disk traffic the longer delay is
used. This is crude but effective... I think. I hope that somebody will run
this through some benchmarks to see if I lost any performance. According to
my calculations, I did not. I tested this mainly in UML, and also ran it
briefly on my laptop. The interactive feel of the change is immediately
obvious, and for me at least, a big improvement.
The patch is against 2.4.5. To apply:
cd /your/source/tree
patch b_flushtime = jiffies + bdf_prm.b_un.age_buffer;
+ bh->b_dirtytime = jiffies;
refile_buffer(bh);
}
@@ -2524,12 +2524,20 @@
as all dirty buffers lives _only_ in the DIRTY lru list.
As we never browse the LOCKED and CLEAN lru lists they are infact
completly useless. */
-static int flush_dirty_buffers(int check_flushtime)
+static int flush_dirty_buffers (int update)
{
struct buffer_head * bh, *next;
int flushed = 0, i;
+ unsigned queued = atomic_read (_sectors);
+ unsigned long youngest_to_update;
- restart:
+#ifdef DEBUG
+ if (update)
+ printk("kupdate %lu %i\n", jiffies, queued);
+#endif
+
+restart:
+ youngest_to_update = jiffies - (queued? bdf_prm.b_un.age_buffer: 0);
spin_lock(_list_lock);
bh = lru_list[BUF_DIRTY];
if (!bh)
@@ -2544,19 +2552,14 @@
if (buffer_locked(bh))
continue;
- if (check_flushtime) {
- /* The dirty lru list is chronologically ordered so
- if the current bh is not yet timed out,
- then also all the following bhs
- will be too young. */
- if
Re: Alan Cox quote? (was: Re: accounting for threads)
Larry McVoy wrote: > > Good question but I doubt we're going to get anywhere. Anyone who thinks > that 73MB of RAM is an OK thing to waste on window system is probably a > died-in-the-wool Java programmer and could care less about performance, > system design, or any elegance whatsoever. Bleh, don't go taking cheap shots at Java! Java is good at what it does, memory and performance be damned! > It pains me to believe that people like this exist but there they are. Yeah, and we are young and prolific too, so you better watch out! :) Ben -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bind oddity/trap
Hi, Al. Here's an oddity I just ran across with VFS bindings: # mkfifo /dev/modem (BTW: it would be nice not to have to make the node) # mount --bind /dev/tts/0 /dev/modem # kermit kermit> set line /dev/modem kermit> set speed 4800 ?Sorry, you must SET LINE first The reason this is happening is because Kermit will do a readdir(2), scanning /dev for a node with the same inum as it gets from fstat(2). In this case, fstat(2) is giving the inum of /dev/tts/0, which is of course the correct behaviour. However, the d_ino field from readdir(2) is giving the inum of the "mount point" (the FIFO I created). So there is an inconsistency, and kermit gets confused. Perhaps readdir(2) should return the same inum as fstat(2) does? I realise that could be quite nasty to implement. However, it is an inconsistency, and a potential trap. But there probably isn't a good solution to this one. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
the 'compile in one place and export the product via nfs' mentality really kicks in under *bsd, where you may have a server farm and want to upgrade all at once...the tarball idea works for one machine, but for multiples, its all about exporting it... just my 2 cents. --gabe ,[ On Tue, Jun 19, at 07:24PM, Kelledin Tane wrote: ]-- | Gabriel Rocha wrote: | | > you could always compile on one machine and nfs mount the /usr/src/linux | > and do a make modules_install from the nfs mounted directory... | | The way I've always managed this sort of thing is to tar up your kernel source, | transfer it to the "compile box" however you please, then do all the compile | steps except the "make modules_install" and the copying of the kernel image. | Then tar up the compiled source tree, transfer it over to the box you want to | install on, untar it, and do the rest of the steps (the "make modules_install" | and the copying of the kernel image). Just make sure that all the systems | involved have about the same system time, else you'll get the message, "Clock | skew detected. Your build may be incomplete." | | One day I managed to get egcs-2.91.66 to compile against glibc-2.2, and I never | had to do that stuff again. ;) | | Kelledin | | bash-2.05 $ kill -9 1 | init: Just what do you think you're doing, Dave? | | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to [EMAIL PROTECTED] | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ `[ End Quote ]--- -- Gabriel Rocha ([EMAIL PROTECTED]) - 1-877-4-1SECURE OneSecure, Inc. Sunnyvale Security Operations Center (GMT -0700) -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia mQCNAzrYQA8AAAEEAL/fjYD12U8QNO0PJX30zYd+0Wg1aZq+jPp34hTiMXrGg2bv VE2hwrcz4iILCaQ5KlncteycMx6VL7u0tnIkxnT0M8fAPuS4VpqB/tS/mr3RcHLa 52+TRZ45KnZt/6pp+pc9zJM8STJvGatfF+YPYKtzEM3mFL4OEnMJdtsEFkx1AAUT tCRHYWJyaWVsIFJvY2hhIDxncm9jaGFAb25lc2VjdXJlLmNvbT6JAJUDBRA62EAP cwl22wQWTHUBATrVA/9Z+/pUsd0nV6ZtOn014Q9hJ1TUzhzVcNVF1zUufTHTwLO1 gnKaomNj1Fb+pwGK3ZxNqomUTAnCXCU3HxQ0DkG8OIjzuOIr08Lv57pA9u/yjlTR IOV5REUNFWD0ogKLAlVG9wp3IsSgntjToB/rj75siVrBapqzbgR+Dcs3nb8Ijg== =HwqX -END PGP PUBLIC KEY BLOCK- PGP signature
[PATCH] setuid(2) buggy or bad docs
setuid(2) differs from the OpenBSD setuid(2) in that -EPERM is returned by the syscall even if the euid of the process matches the uid passed to it. Either I am non compos or the thing is very wrong. The docs (man-pages-1.35) say ERRORS EPERM The user is not the super-user, and uid does not match the effective or saved user ID of the calling process. The following untested patch changes the kernel to match the documentated behaviour. --- linux-2.4.4-orig/kernel/sys.c Tue May 1 14:34:43 2001 +++ linux-2.4.4/kernel/sys.c Wed Jun 20 01:32:46 2001 @@ -603,7 +603,9 @@ asmlinkage long sys_setuid(uid_t uid) if (uid != old_ruid && set_user(uid, old_euid != uid) < 0) return -EAGAIN; new_suid = uid; - } else if ((uid != current->uid) && (uid != new_suid)) + } else if ((uid != current->uid) + && (uid != new_suid) + && (uid != old_euid)) return -EPERM; if (old_euid != uid) -- Summer job urgently sought due to last minute visa trouble! Please see http://ape.n3.net/cv.html
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 05:19:45PM -0700, Mike Castle wrote: > On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote: > > But so what? That's $16 worth of DRAM (I just checked). Not so bad > > *if* threads are otherwise a great solution. I grant that one might > > have a pretty tough time making the case, but again, for the right > > application, say some app with a dedicated server, 73MB isn't the end > > of the world (though I suppose it was at the time...). > > How much would 73MB of cache cost? How much would it cost to get that much > on the CPU? Good question but I doubt we're going to get anywhere. Anyone who thinks that 73MB of RAM is an OK thing to waste on window system is probably a died-in-the-wool Java programmer and could care less about performance, system design, or any elegance whatsoever. It pains me to believe that people like this exist but there they are. What can you do? As Confucius says "If I hold up three corners of a square and the student does not hold up the fourth, I do not bother to go over the point again". -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should VLANs be devices or something else?
Hi, Ben Greear wrote: > > > > Should VLANs be devices or some other thing? > I found it to be the easiest way to implement things. It allowed > me to not have to touch any of layer 3, and I did not have to patch > any user-space program like ip or ifconfig. I faced the same issue when implementing RFC2684 (formerly 1483) Ethernet over ATM-AAL5. Since users want to do the same thing (ifconfig, tcpdump, rfc 2514 pppoe, dhcp, ipx) as with traditional eth0 using register_netdev was 'the right thing'. However having the possibility of many devices annoyed some people. (upto appr. 4095/ATM-VC in case of vlan over rfc2684 over atm ;-) My answer to the (old) 'long ifconfig listing' argument: Users do not have more interfaces in the ifconfig listing than those they create for themselves. That's ok, exactly what they want. Those who do not like many interfaces do not create many. The real thrill would be maintaining new (or patched) tools just because we want to avoid having the _possibility_ of long listings at any cost... I remember /proc/sys/net/ipv4/conf/ was broken for about >300 devices. I do not know how's it today. > Adding the hashed lookup for devices took the exponential curve out of > ip and ifconfig's performance, btw. n^2 for creating n devices (in the unfortunate increasing or random order), (not 2^n), I guess. Cell -- You'll never see all the places, or read all the books, but fortunately, they're not all recommended. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] swapfile.c
The following diff tries to improve on the efficiency of try_to_unuse(). It
removes the potential O(|swap_map|^2) business and makes it linear time.
I'm not sure what this means in terms of overall change, but Linus seemed
interested in the innefficiency in that code. Test with caution.
Nathan.
diff -uwrN linux/mm/swapfile.c.old linux/mm/swapfile.c
--- linux/mm/swapfile.c.old Tue Jun 19 17:15:07 2001
+++ linux/mm/swapfile.c Tue Jun 19 17:44:24 2001
@@ -328,6 +328,41 @@
return;
}
+static int unuse_entry (swp_entry_t entry) {
+ struct page *page;
+ struct task_struct *p;
+
+ /* Get a page for the entry, using the existing swap
+ cache page if there is one. Otherwise, get a clean
+ page and read the swap into it. */
+ page = read_swap_cache_async(entry);
+ if (!page) {
+ swap_free(entry);
+ return -ENOMEM;
+ }
+
+ lock_page (page);
+ if (PageSwapCache(page))
+ delete_from_swap_cache_nolock(page);
+ UnlockPage (page);
+
+ read_lock(_lock);
+ for_each_task(p)
+ unuse_process(p->mm, entry, page);
+ read_unlock(_lock);
+
+ shmem_unuse(entry, page);
+ /* Now get rid of the extra reference to the temporary
+ page we've been using. */
+ page_cache_release(page);
+ /*
+ * Check for and clear any overflowed swap map counts.
+ */
+ swap_free(entry);
+
+ return 0;
+}
+
/*
* We completely avoid races by reading each swap page in advance,
* and then search for the process using it. All the necessary
@@ -336,12 +371,10 @@
static int try_to_unuse(unsigned int type)
{
struct swap_info_struct * si = _info[type];
- struct task_struct *p;
- struct page *page;
swp_entry_t entry;
int i;
+ int err;
- while (1) {
/*
* Find a swap page in use and read it in.
*/
@@ -356,42 +389,19 @@
*/
if (si->swap_map[i] != SWAP_MAP_MAX)
si->swap_map[i]++;
+
swap_device_unlock(si);
-goto found_entry;
- }
- }
- swap_device_unlock(si);
- break;
- found_entry:
entry = SWP_ENTRY(type, i);
-
- /* Get a page for the entry, using the existing swap
- cache page if there is one. Otherwise, get a clean
- page and read the swap into it. */
- page = read_swap_cache_async(entry);
- if (!page) {
- swap_free(entry);
- return -ENOMEM;
+ err = unuse_entry (entry);
+ if (err < 0) {
+return err;
}
- lock_page(page);
- if (PageSwapCache(page))
- delete_from_swap_cache_nolock(page);
- UnlockPage(page);
- read_lock(_lock);
- for_each_task(p)
- unuse_process(p->mm, entry, page);
- read_unlock(_lock);
- shmem_unuse(entry, page);
- /* Now get rid of the extra reference to the temporary
- page we've been using. */
- page_cache_release(page);
- /*
- * Check for and clear any overflowed swap map counts.
- */
- swap_free(entry);
- swap_list_lock();
+
swap_device_lock(si);
+
+ swap_list_lock();
+ /* check this value again after unusing the entry */
if (si->swap_map[i] > 0) {
if (si->swap_map[i] != SWAP_MAP_MAX)
printk("VM: Undead swap entry %08lx\n",
@@ -399,9 +409,13 @@
nr_swap_pages++;
si->swap_map[i] = 0;
}
- swap_device_unlock(si);
swap_list_unlock();
+
+ /* Leave the device locked for loop */
+ }
}
+ swap_device_unlock (si);
+
return 0;
}
Re: How to compile on one machine and install on another?
Gabriel Rocha wrote: > you could always compile on one machine and nfs mount the /usr/src/linux > and do a make modules_install from the nfs mounted directory... The way I've always managed this sort of thing is to tar up your kernel source, transfer it to the "compile box" however you please, then do all the compile steps except the "make modules_install" and the copying of the kernel image. Then tar up the compiled source tree, transfer it over to the box you want to install on, untar it, and do the rest of the steps (the "make modules_install" and the copying of the kernel image). Just make sure that all the systems involved have about the same system time, else you'll get the message, "Clock skew detected. Your build may be incomplete." One day I managed to get egcs-2.91.66 to compile against glibc-2.2, and I never had to do that stuff again. ;) Kelledin bash-2.05 $ kill -9 1 init: Just what do you think you're doing, Dave? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote:
> But so what? That's $16 worth of DRAM (I just checked). Not so bad
> *if* threads are otherwise a great solution. I grant that one might
> have a pretty tough time making the case, but again, for the right
> application, say some app with a dedicated server, 73MB isn't the end
> of the world (though I suppose it was at the time...).
How much would 73MB of cache cost? How much would it cost to get that much
on the CPU?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, 19 Jun 2001, David S. Miller wrote: > > > Don't believe me that Solaris sucks here? Run this experiment under > Solaris-latest and Linux on a sparc64 system (using lmbench): > > Under Solaris: ./lat_proc fork > Under Linux: strace -f ./lat_proc fork > > I bet the Linux case does better than the Solaris run by some orders > of magnitude. That's how poor their fork/exit/switch code is. > > It's a very impressive difference: Script started on Tue Jun 19 17:49:30 2001 [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 563.7778 microseconds [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 565.5556 microseconds [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 568. microseconds [kaboom@thing2 linux]$ exit Script done on Tue Jun 19 17:49:46 2001 Script started on Tue 19 Jun 2001 05:51:38 PM MDT [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4249.5000 microseconds [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4212.5000 microseconds [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4241. microseconds [kaboom@thing1 solaris]$ exit script done on Tue 19 Jun 2001 05:52:19 PM MDT thing1 and thing2 are identical Sun Blade 100s. thing1 is running Solaris 8 (04/01 release), while thing2 is running 2.4.4 (Debian/unstable). later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
net.agent and ifconfig (RH 7.1)
I was running my VLAN test, which creates 4000 VLAN interfaces, sets their IP/mask, and then later tears them down... However, my box is seeing 300 processes running and a load of around 47.00. Most of these processes are 'ifconfig' and net.agent. I am not running ifconfig in my script, so I assume net.agent is. Needless to say, my test is running real slow... I am wondering if this is a RH only thing, or if it is found across all 2.4 distributions... Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
** Reply to message from Rob Landley <[EMAIL PROTECTED]> on Tue, 19 Jun 2001 14:18:03 -0400 > 2) Not only did Linux not have threads (at all), it didn't plan to have > threads, and anybody who brought up the idea of threads was dismissed. > Considering this was long before clone, and SMP hardware was starting to come > into the high and and looked like it might wind up on the desktop eventually > (who knew MS would keep DOS around another ten years, unable to understand > two processors, to displays, two mice, two keyboards, and barely able to cope > with two hard drives under a 26 letter limit...) Amen. This is one of the reasons why I also prefer OS/2 over Linux. > So I wound up work at IBM doing OS/2 development for a couple years. On a > project called Feature Install, which was based on a subclassed folder in the > workplace shell (object oriented desktop). [snip] > When they made up a test object hierarchy > for all the components of the entire OS, it created so many threads the > system ran out and got completely hosed. I had a command line window open, > but couldn't RUN anything, since anything it tried to spawn required a thread > to run. (Child of the shell.) Feature Installer is a bad example. That software is a piece of crap for lots of reasons, excessive threading being only one, and every OS/2 user knew it the day it was released. Why do you think WarpIN was created? > Sometimes they're an easy way to get asynchronous behavior, and to perform > work in the background without the GUI being locked up. But the difference > between "processes" and "threads" there is academic. Processes with shared > memory and some variant of semaphores to avoid killing each other in it. > Same thing. Not quite. What makes OS/2's threads superior is that the OS multitasks threads, not processes. So I can create a time-critical thread in my process, and it will have priority over ALL threads in ALL processes. A lot of OS/2 software is written with this feature in mind. I know of one programmer who absolutely hates Linux because it's just too difficult porting software to it, and the lack of decent thread support is part of the problem. > Bondage and discipline languages that enforce somebody's idea of good > programming practice usually just result in WORSE bad programs, and fewer > good programs written by people who know how to play with fire without > burning themselves. Saying you can't have threads because they can be > misused and "you shouldn't program that way" would be truly dumb. (Turned ME > off for a couple years, anyway.) Exactly. Saying that threads cause bad code is just as dumb as saying that a kernel debugger will cause bad code because programmers will start using the debugger instead of proper design. Oh wait, never mind . -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] large offset llseek breaks for device special files on ac series
Dear all, The ac-kernel series include a check in default_llseek() to not set the file position beyond the file systems maximum file size. This check should be done only for regular files, e.g. for a device special file the test does not make sense. Alan suggested that we remove the check from the default_llseek method and introduce a generic_file_llseek() method that checks the maximum file size. The generic_file_llseek() method needs to be put in all file systems in order to test for the maximum file size. I send the mail with the patch to all maintainers of file systems, please comment. Here is the patch. I put the generic_file_llseek into adfs, affs, bfs, coda, ext2, fat, free_vxfs, hfs, hpfs, jffs, jffs2, minix, ncpfs, nfs, ntfs, openpromfs, qnx4, ramfs, reiserfs, smbfs, sysv, and udf. hfs got two additional llseek methods for the metadata, same for openpromfs. The patch applies to 2.4.5 ac 16. The cmsfs directory produces an object file with the wrong name, the patch fixes the cmsfs/Makefile do produce the right object file. Especially the hfs and openpromfs modifications should be checked. I did not touch the other file systems, there is either no file read or write, or a fix is not straight forward. I did not modifiy the proc file system, the llseek problem should be fixed there in a more general way. Regards, Martin patch-fs.2.4.5.ac16.gz
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tuesday 19 June 2001 12:52, Larry McVoy wrote: > On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote: > > On Tue, 19 Jun 2001, Larry McVoy wrote: > > > ``Think of it this way: threads are like salt, not like pasta. You > > > like salt, I like salt, we all like salt. But we eat more pasta.'' > > > > This is oft-quoted but has, IMO, the property of not actually > > making any sense. > > Hmm. Makes sense to me. All it is saying is that you can't make a good > dinner out of a pile of salt. It was originally said to some GUI people > who wanted to use a thread per object, every button, scrollbar, canvas, > text widget, menu, etc., are all threads. What they didn't figure out is > that a thread needs a stack, the stack is the dominating space term, and > they were looking at a typical desktop with around 9,000 objects. Times, > at that point, an 8K stack. That was 73MB in stacks. Pretty darned stupid > when you look at it that way, huh? I've seen worse. Back around '93 or so I took a look at Linux and wound up putting OS/2 on my desktop instead of Linux for 2 reasons. 1) Diamond Stealth video card. It worked in OS/2, didn't work in Linux, and the reason was you guys couldn't get vendor support while IBM could. According to this list, it was entirely possible this sort of problem would NEVER be addressed. (We got around it with reverse engineering and critical mass, but at the time hardware was changing way faster than we could keep up with it.) 2) Not only did Linux not have threads (at all), it didn't plan to have threads, and anybody who brought up the idea of threads was dismissed. Considering this was long before clone, and SMP hardware was starting to come into the high and and looked like it might wind up on the desktop eventually (who knew MS would keep DOS around another ten years, unable to understand two processors, to displays, two mice, two keyboards, and barely able to cope with two hard drives under a 26 letter limit...) So I wound up work at IBM doing OS/2 development for a couple years. On a project called Feature Install, which was based on a subclassed folder in the workplace shell (object oriented desktop). The idea was you fill up a folder with files, drag and drop them from diskette to desktop, and they install themselves automatically. (Went out the window when a single install object had to span two disks, but oh well. By then, they were stuck with the design. I inherited it after a year or two of scar tissue had accumulated.) They created THREE threads for every single object, and they objects could nest arbitrarily deep. (Modular installs with sub-components.) The OS had a default of 1024 threads (expandable to 4096, I believe, before they hit a 64k limit somewhere in the coding). When they made up a test object hierarchy for all the components of the entire OS, it created so many threads the system ran out and got completely hosed. I had a command line window open, but couldn't RUN anything, since anything it tried to spawn required a thread to run. (Child of the shell.) One three finger salute later, the desktop comes back up automatically, with this nasty tangle of objects STILL there, and of course hoses itself AGAIN as the desktop instantiates all those objects in memory with their three threads apiece, and runs out again... Those were the days. If I remember correctly, I replace ALL those threads with a single thread doing all the work, a mutex protected linked list of work to do, and an event semaphore to tell it to do it. > Nobody is arguing that having more than one thread of execution in an > application is a bad idea. On an SMP machine, having the same number of > processes/threads as there are CPUs is a requirement to get the scaling > if that app is all you are running. That's fine. But on a uniprocessor, > threads are basically stupid. Sometimes they're an easy way to get asynchronous behavior, and to perform work in the background without the GUI being locked up. But the difference between "processes" and "threads" there is academic. Processes with shared memory and some variant of semaphores to avoid killing each other in it. Same thing. And I think the most I've ever REALLY used is about three for a whole program. (Unless you're talking about a server with a thread pool handling connections. And yeah that could be done with poll and non-blocking I/O, but not if you're shelling out to ssh and such...) > The only place that I know of where it is > necessary is for I/O which blocks. And even there you only need enough > to overlap the I/O such that it streams. And processes will, and do, > work fine for that. And nonblocking GUI elements, and breaking up work for multiple processors, and probably a few other things. But I think the MAIN difference between the two camps is that the people who despise threads consider them to be a lot different from processes, and
"clock timer configuration lost" on non-VIA m.b.
2.4.5-ac14 on an Asus A7A266 w/ Athlon: ... Jun 19 16:14:21 pollux kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a motherboard. Jun 19 16:14:21 pollux kernel: probable hardware bug: restoring chip configuration. ... According to the documentation, this is an ALi chipset: Northbridge: ALi M1647 Southbridge: ALi M1535D+ The message appears irregularly, with a period varying between 10 minutes and an hour. More system info available on request. Bobby Bryant Austin, Texas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Emu10k1-devel] Re: Buggy emu10k1 drivers.
Robert Love wrote: > > Can you give the CVS driver a try? Snapshots are available here: > > http://opensource.creative.com/snapshot.html > > > > The driver in the kernel is based on a CVS snapshot from last summer, the > > problem may be fixed in CVS. Also, the CVS driver is a common driver for > > 2.2 and 2.4 (with some #ifdef), so it may be useful to see if it works for > > you on 2.4.5 but not on 2.2.19. > > if the driver in the kernel is that old, could we try merging a newer > release? is there any reason why it has not been done yet? Tried 2.4.5 and 2.2.19 with the same snapshot code (emu10k1-20010617.tar.gz) 2.4.5 works, 2.2.19 doesn't. Maybe 2.2.19 has deeper problems with my hardware which aren't in the driver, then, as identical code works on one and not the other. -- www.kuro5hin.org -- technology and culture, from the trenches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] rio500 devfs support
The attached diff adds devfs support to the rio500 driver, so that
/dev/usb/rio500 gets created automagically. It was generated against
2.4.5, but probably applies fine against any recent kernel. Comments
are welcome (but be gentle, this is my first attempt at a kernel
patch :-).
Cheers!
diff -urN linux-2.4.5.orig/drivers/usb/rio500.c linux-2.4.5/drivers/usb/rio500.c
--- linux-2.4.5.orig/drivers/usb/rio500.c Mon Jun 18 17:10:39 2001
+++ linux-2.4.5/drivers/usb/rio500.cTue Jun 19 17:12:26 2001
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "rio500_usb.h"
@@ -70,6 +71,7 @@
};
static struct rio_usb_data rio_instance;
+static devfs_handle_t rio500_devfs_handle;
static int open_rio(struct inode *inode, struct file *file)
{
@@ -492,6 +494,12 @@
if (usb_register(_driver) < 0)
return -1;
+ rio500_devfs_handle = devfs_register(NULL, "usb/rio500",
+ DEVFS_FL_DEFAULT,
+ USB_MAJOR, RIO_MINOR,
+ S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP |
+S_IWGRP,
+ _rio_fops, NULL);
+
info(DRIVER_VERSION " " DRIVER_AUTHOR);
info(DRIVER_DESC);
@@ -506,6 +514,7 @@
rio->present = 0;
usb_deregister(_driver);
+ devfs_unregister(rio500_devfs_handle);
}
PGP signature
Re: Should VLANs be devices or something else?
On Tue, 19 Jun 2001, Ben Greear wrote: > I have had a good discussion with Dave Miller today, and there > is one outstanding issue to clear up before my 802.1Q VLAN patch may > be considered for acceptance into the kernel: > > Should VLANs be devices or some other thing? I would vote that VLANs be devices. Conceptually, VLANs as network devices is a no brainer. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 04:45:24PM -0500, Eli Carter wrote:
> Gabriel Rocha wrote:
> > you could always compile on one machine and nfs mount the /usr/src/linux
> > and do a make modules_install from the nfs mounted directory...
>
> Which would require exporting that filesystem with root permissions
> enabled...any security bells going off?
Why would you need to have nfs root access?
You're reading from the nfs mount, not writing to it.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
FYI: 2.4.5-ac16 panics on Asus A7A266
I tried 2.4.5-ac16 on my Asus A7A266 w/ Athlon because the fixnotes sounded like it might address the simplex vs. DMA problem that I reported a while back, but I get a kernel panic early in the boot sequence every time I try to boot. FYI, 2.4.5-ac14 boots and runs OK, except for the disabled DMA and frequent SMBus resets when I try to run lm_sensors. (The only difference in the .config between -ac14 and -ac16 is that for -ac16 I enabled the new ALI chipset fix.) Possibly relevant, notice that 2.4.5-ac14 reports the chipset as "ALI15X3" during the boot sequence, whereas the board's documentation says that it's actually an ALi M1535D+. It also gives this message at boot time, which I will send to the indicated address in a separate message: Jun 19 15:49:36 pollux kernel: PCI: Found IRQ 9 for device 00:0d.0 Jun 19 15:49:36 pollux kernel: Redundant entry in serial pci_table. Please send the output of Jun 19 15:49:36 pollux kernel: lspci -vv, this message (4793,4104,4793,215) Jun 19 15:49:36 pollux kernel: and the manufacturer and name of serial board or modem board Jun 19 15:49:36 pollux kernel: to [EMAIL PROTECTED] Jun 19 15:49:36 pollux kernel: ttyS04 at port 0x9800 (irq = 9) is a 16550A The lspci info is attached, in case anyone here wants it. Holler if you want more, and tell this cluebie how to collect it. Thanks, Bobby Bryant Austin, Texas 00:00.0 Host bridge: Acer Laboratories Inc. [ALi]: Unknown device 1647 (rev 04) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [a4] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5247 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- FastB2B- 00:04.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c4) (prog-if fa) Subsystem: Asustek Computer, Inc.: Unknown device 8053 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0b.0 Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] Capabilities: [58] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0d.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 01) (prog-if 02 [16550]) Subsystem: US Robotics/3Com: Unknown device 00d7 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR-
Re: Linux 2.2.20-pre4
Philip Blundell wrote: > I don't think -fno-builtin has any bearing on whether gcc will emit calls to > memcpy; Good point. The subject was about the compiler adding function calls to code, and I started talking about the compiler removing them... -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20-pre4
Alan Cox wrote: > > why not always -fno-builtin, > > and then call __builtin_foo when we really want the compiler's version.. > That may well be the right thing to do. Of course we rely on the compiler > providing some of them too true, it wouldn't be a completely transparent switchover, but it seems like the best way to produce expected results across a bunch of different compilers. > but -fno-builtin will still > give a kernel that dosnt link due to abs() and other problems.. 8) Any others come to mind? abs is definitely special in that the compiler [potentially] can do additional magic with the type information it has. Maybe -fno-builtin plus #undef abs #define abs __builtin_abs Thanks, Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20-pre4
>> It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
>> insert calls to 'memcpy'
>
>IMHO omitting -fno-builtin when compiling the kernel was always a risky
>proposition... Since we provide our own copies of many of the builtins
>[which are used in the kernel] anyway... why not always -fno-builtin,
>and then call __builtin_foo when we really want the compiler's version..
>
>gcc 3.0 without -fno-builtin is perfectly allowed to assume it can
>insert calls to memcpy..
I don't think -fno-builtin has any bearing on whether gcc will emit calls to
memcpy; instead it prevents gcc from open-coding them when it thinks it
understands what's going on.
Try this with gcc -O2 -S, and again with -fno-builtin:
struct s { int a[200]; };
f(struct s *a, struct s *b)
{
*b = *a;
}
g(int *a, int *b)
{
memcpy(b, a, 4);
}
p.
PGP signature
Re: Linux 2.2.20-pre4
> IMHO omitting -fno-builtin when compiling the kernel was always a risky > proposition... Since we provide our own copies of many of the builtins > [which are used in the kernel] anyway... why not always -fno-builtin, > and then call __builtin_foo when we really want the compiler's version.. That may well be the right thing to do. Of course we rely on the compiler providing some of them too > gcc 3.0 without -fno-builtin is perfectly allowed to assume it can > insert calls to memcpy.. I have no argument about its correctness there, but -fno-builtin will still give a kernel that dosnt link due to abs() and other problems.. 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
hey, how and where you export the filesystem is an exercise left for the reader, i have no problem exporting nfs filesystems in my internal network, what you do or dont, is up to you. and there is always cfs... ,[ On Tue, Jun 19, at 04:45PM, Eli Carter wrote: ]-- | Gabriel Rocha wrote: | > | > you could always compile on one machine and nfs mount the /usr/src/linux | > and do a make modules_install from the nfs mounted directory... | | Which would require exporting that filesystem with root permissions | enabled...any security bells going off? | | C-ya, | | Eli | ---. No wonder we didn't get this right first time | Eli Carter | through. It's not really all that horribly | eli.carter(at)inet.com `- complicated, but the _details_ kill you. Linus `[ End Quote ]--- -- Gabriel Rocha ([EMAIL PROTECTED]) - 1-877-4-1SECURE OneSecure, Inc. Sunnyvale Security Operations Center (GMT -0700) -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia mQCNAzrYQA8AAAEEAL/fjYD12U8QNO0PJX30zYd+0Wg1aZq+jPp34hTiMXrGg2bv VE2hwrcz4iILCaQ5KlncteycMx6VL7u0tnIkxnT0M8fAPuS4VpqB/tS/mr3RcHLa 52+TRZ45KnZt/6pp+pc9zJM8STJvGatfF+YPYKtzEM3mFL4OEnMJdtsEFkx1AAUT tCRHYWJyaWVsIFJvY2hhIDxncm9jaGFAb25lc2VjdXJlLmNvbT6JAJUDBRA62EAP cwl22wQWTHUBATrVA/9Z+/pUsd0nV6ZtOn014Q9hJ1TUzhzVcNVF1zUufTHTwLO1 gnKaomNj1Fb+pwGK3ZxNqomUTAnCXCU3HxQ0DkG8OIjzuOIr08Lv57pA9u/yjlTR IOV5REUNFWD0ogKLAlVG9wp3IsSgntjToB/rj75siVrBapqzbgR+Dcs3nb8Ijg== =HwqX -END PGP PUBLIC KEY BLOCK- PGP signature
intermittent hangs with threads (clone() bug?/linuxthreads bug?)
Hi, I am experiencing intermittent hangs running LinuxThreads programs from a shell script. This happens with any combination of stock RH 7.1 SMP kernel (2.4.2) or my own 2.4.5 kernel and stock RH 7.1 libc (2.2.2), redhat rawhide libc (2.2.3) and my own 2.2.3 libc. If I run, for example, linuxthreads/Examples/ex1 (one thread prints 'a', one prints 'b') it will run fine. If I run it from a shell script (bash or ksh) with exec ex1 it almost always hangs. When I do a "ps" I see the original "ex1" process plus another defunct "ex1" process with a higher pid. This defunct process was supposed to be the LinuxThreads manager thread but it seems that clone() is silently failing to create a valid thread. Attaching a debugger to the original "ex1" and putting print statements in libc/linuxthreads and the kernel (do_fork() and friends) all indicate things are proceeding normally. Yet the manager thread/process is never scheduled to run...it is immediately defunct. My hardware is an 8-way i686. I tried removing CPU's but the problem remains until I get down to a single CPU (or boot a uniprocessor kernel). When I got down to 2 CPU's I noticed that running my script from console almost always produced a hang while running from an xterm always worked. Obviously a timing issue. Also things run fine on other SMP hardware I have access to. If anyone has any idea what is going on, I would love to hear it. If you need more information please let me know, as well. Thanks Ed Connell Healthy traceback from original "ex1" process where it is waiting for the manager thread to take over. (gdb) where #0 0x40067ff5 in __sigsuspend (set=0xb2e8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #1 0x4002d25f in __pthread_wait_for_restart_signal (self=0x40036300) at pthread.c:958 #2 0x4002cbc4 in __pthread_create_2_1 (thread=0xb454, attr=0x0, start_routine=0x8048580 , arg=0x804871d) at restart.h:34 #3 0x080485e7 in main () at ex1.c:29 #4 0x400565e7 in __libc_start_main (main=0x80485cc , argc=1, ubp_av=0xb4c4, init=0x80483d0 <_init>, fini=0x80486e0 <_fini>, rtld_fini=0x4000e154 <_dl_fini>, stack_end=0xb4bc) at ../sysdeps/generic/libc-start.c:129 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac15
On Sun, 17 Jun 2001, Walter Hofmann wrote: > I had already two crashes with ac15. The system was still ping-able, but > login over the network didn't work anymore. > > The first crash happened after I started xosview and noticed that the > system almost used up the swap (for no apparent reason). The second > crash happened shortly after I started fsck on a crypto-loop device. > > This does not happen with ac14, even under heavy load. > > I noticed a second problem: Sometimes the system hangs completely for > approximately ten seconds, but continues just fine after that. I have > seen this with ac14 and ac15, but not with ac12. FWIW, here is the vmstat output for the second (short) hang. Taken with ac14, vmstat 1 was started (long) before the hang and interrupted about five seconds after it. The machine has 128MB RAM and 256MB swap. procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 1 0 77332 1584 15632 67740 44 0 448 0 496 932 84 15 1 1 2 0 77456 1848 15944 66960 0 0 372 724 625 2296 62 20 18 3 0 1 77456 1780 16208 67044 72 0 33680 584 1695 20 20 61 2 0 0 77404 1464 16672 66652 0 0 572 0 530 2649 26 19 55 3 1 0 77344 1464 17000 66480 124 0 656 0 419 879 12 16 72 0 3 0 77344 1468 17076 66388 184 0 1080 0 561 654 8 8 84 0 5 0 77892 1464 17184 66892 176 128 800 396 415 1050 14 11 74 0 5 0 77892 1600 17216 66868 16 068 1020 508 295 5 5 90 0 3 0 77892 1464 17316 66784 56 0 37268 464 1287 22 14 64 2 3 0 77892 1464 17524 66828 76 0 440 0 398 987 8 12 79 1 3 0 77892 1464 17780 66680 32 0 512 0 367 1061 10 10 79 1 1 0 77880 1464 18020 66392 224 0 756 0 394 1579 43 12 44 2 1 0 77784 2172 18324 64820 16 0 992 0 529 1745 37 19 44 0 4 0 77936 1848 18428 65180 124 0 252 920 570 451 23 9 69 0 2 0 77888 1680 18564 65656 84 0 744 0 532 721 21 12 67 3 0 0 77876 1464 18700 65564 4 0 1176 0 487 804 26 16 58 0 3 1 77496 1468 18712 65700 424 100 1296 384 401 532 70 10 20 2 0 0 77920 1508 18804 65504 72 248 968 260 525 709 40 9 51 2 2 0 77908 1728 18788 65388 0 120 1000 568 568 608 41 8 51 0 4 0 77908 1620 18828 65548 0 0 172 356 545 420 22 8 69 1 1 0 77904 1712 18472 65464 36 0 1600 0 485 621 52 15 33 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 1 0 78124 1528 18496 64940 116 20 884 288 545 604 54 16 30 4 0 0 78124 1468 18548 64260 4 0 468 0 449 663 49 6 46 3 0 0 77844 3416 18492 63932 100 0 304 0 431 1915 80 16 4 1 2 0 77844 2892 18536 64204 60 0 284 820 583 917 64 13 23 1 0 0 77844 2824 18544 64236 0 04068 591 550 36 6 58 3 0 0 77844 2604 18568 64372 0 0 120 0 455 474 64 13 23 1 0 0 77844 2472 18572 64440 0 056 0 399 617 35 9 56 1 0 0 77844 2456 18572 64460 0 0 0 0 515 721 8 6 87 0 0 0 77844 2448 18572 64468 0 0 4 0 469 655 8 8 83 1 0 0 77844 2384 18572 64528 0 0 0 428 538 641 7 10 83 0 0 0 77844 2388 18572 64528 0 0 0 0 492 733 3 9 89 0 0 0 77844 2368 18572 64548 0 0 0 0 520 804 11 7 82 0 0 0 77844 2336 18572 64580 0 0 0 0 473 680 6 6 89 1 0 0 77844 2276 18584 64608 0 012 0 490 966 30 13 56 2 0 0 77844 2228 18584 64648 0 0 0 344 539 589 47 7 47 3 0 0 77844 2228 18588 64692 0 0 4 0 381 455 29 11 60 2 0 1 77844 2180 18588 64700 0 0 0 0 453 781 33 9 58 1 0 0 77844 2160 18604 64708 0 016 0 390 852 18 5 77 2 0 1 77844 1940 18616 64912 124 0 212 0 318 756 40 8 52 3 0 0 77844 1680 18620 65180 240 0 244 576 492 1632 87 13 0 2 0 1 77844 1528 18540 65540 584 0 592 0 352 2466 90 10 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 0 0 77844 1800 18516 65588 40 040 0 357 675 89 11 0 3 5 2 77844 1464 18536 65916 1508 44 1660 264 435 852 37 16 47 1 0 0 77844 1484 18532 65968 864 0 936 0 386 667 89 7 5 1 0 1 77844 1464 18344 66220 1328 0 1416 280 416
Re: How to compile on one machine and install on another?
Quoting Tom Diehl <[EMAIL PROTECTED]> from ml.linux.kernel: :What is the best way to install the modules? Is there a directory _all_ of :the modules exist in b4 you do "make modules_install". I usually end up :setting EXTRAVERSION to something unique and doing a make modules_install. :That way it does not hose up the modules for the build machine. :Is there a better way? Yes, there is. I usually add the the following to the main Makefile: export INSTALL_PATH=/nfs/lyon/home/ram/root-install/boot export INSTALL_MOD_PATH=/nfs/lyon/home/ram/root-install I then proceed as usual, and the modules get copied over NFS to the target machine, in root-install/lib/modules, etc... If you don't have NFS mounts to the remote machine, you'll have to rcp the tree, that's all. Raphael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote?
Larry McVoy writes: > Great, then we are in violent agreement on the single abstraction. > On the second part, I stand by my previous statements that threads or > processes should be used sparingly. > > All I'm doing is trying to counter all the "threads are great" hype. > This is a pretty intelligent pile of people but there are also a fair > number of people who read this list looking for nuggets of information. > If they walk away going "(a) Linux has a cool threading model, and > (b) I should only use threads if I absolutely have to do so and even > then if there are more than there are CPUs I'm probably making a > mistake", if they get that message, that's a good thing, IMHO. New FAQ entry: http://www.tux.org/lkml/#s7-21 Yeah, it's probably a bit harsh :-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
Johannes Erdfelt wrote: > Could you load uhci with the debug=1 option? I did an 'insmod uhci.o debug=1' but the dmesg output did not alter. My easy steps to reproduce it is to 'delete selected images' in gphoto such that there will be no images in the camera left when the operation is done. At loast it doesn't lock up the camera like it used to :-/ I think this may be a problem in the dc2xx.o then, since uhci didn't reveal any new messages. -- www.kuro5hin.org -- technology and culture, from the trenches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 04:55:10PM -0400, Tom Diehl wrote: > What is the best way to install the modules? Is there a directory _all_ of > the modules exist in b4 you do "make modules_install". I usually end up > setting EXTRAVERSION to something unique and doing a make modules_install. > That way it does not hose up the modules for the build machine. > Is there a better way? Not anymore there isn't. You'll just have to run make modules_install as 'INSTALL_MOD_DIR="/path/to/module" make modules_install' -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to compile on one machine and install on another?
-Original Message- From: Tom Diehl [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 4:55 PM To: [EMAIL PROTECTED] Subject:Re: How to compile on one machine and install on another? On Tue, 19 Jun 2001, Alan Cox wrote: > Other than making sure you configure it for the box it will eventually run > on - nope you have it all sorted. If you use modules you'll want to install > the modules on the target machine too What is the best way to install the modules? Is there a directory _all_ of the modules exist in b4 you do "make modules_install". I usually end up setting EXTRAVERSION to something unique and doing a make modules_install. That way it does not hose up the modules for the build machine. Is there a better way? I found it puts the new ones in a unique directory under /lib/modules. I just copied that also. I didn't go into the issues, but I am getting an error message from the target box that "/dev/md0 must be a nonpersistent RAID0 or LINEAR array!" This is OK in 2.2.17, which is currently running on the machine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SMP] 2.4.5-ac13 memory corruption/deadlock?
Are you sure about bad memory? Single-bit errors will be corrected; double-bit errors will generate NMI. You can also find memory errors with an exerciser. Unfortunately, trusty memtest86 bombs on my ServerWorks machine. Instead I use http://www.qcc.sk.ca/~charlesc/software/memtester/ which runs in user-mode. I diagnosed thermal problems by running this utility. Within 3 minutes of cold start, it raised main memory temperature sufficiently to induce a hard error, which was detected simultaneously by it and the hardware (NMI taken by kernel). Can you recommend one of your (shorter) tests for me to try? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
On Tue, 19 Jun 2001, Alan Cox wrote: > Other than making sure you configure it for the box it will eventually run > on - nope you have it all sorted. If you use modules you'll want to install > the modules on the target machine too What is the best way to install the modules? Is there a directory _all_ of the modules exist in b4 you do "make modules_install". I usually end up setting EXTRAVERSION to something unique and doing a make modules_install. That way it does not hose up the modules for the build machine. Is there a better way? -- ..Tom INCOMPETIANCE: When You Earnestly Believe You Can [EMAIL PROTECTED] Compensate for a Lack of Skill by Doubling Your Efforts, There's No End to What You Can't Do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
threading question (more results)
Hello, (for all who are interested) I finally obtained access to a linux platform running 2.2.17 on a 2x500 Mhz alpha machine (Compaq's testdrive program). Below are my results: Linux 2.2.17 on 2x500 Mhz Celerons: parallel app = 1.48 times faster than sequential one. Linux 2.4 on a 2x1 Ghz PIIIs: parallel ap = 1.57 times faster than the sequential one. Linux 2.2.17 on a 2 500 Mhz Alpha CPUs: parallel app = 1.76 times faster than the sequential one. Interesting how hardware changed the numbers. Another interesting thing is that the same application when run on a dual Alpha running Tru64 does not obtain the speedup Linux provided on the Alpha hardware. In my limited example application SGI IRIX 2 CPU platform provided 2.25 times the speed of the sequential application and Sun Solaris 1.99 times the sequential application (also on a 2 CPU machine). All these numbers above are when the same code utilizing pthreads was compiled and run on these various platforms. On all of the tests I have used a pool of three threads waiting to get work to do. The testing was done on a set of various sequence files that I believe represent most of the types of data / sequences that might be used on this program. Best regards, Ognen -- Ognen Duzlevski Plant Biotechnology Institute National Research Council of Canada Bioinformatics team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
large offset llseek breaks for device special files on ac series
Hi,
the ac series include a check in default_llseek() to not set the
file position beyond the file systems maximum file size.
This check should be done only for regular files, e.g. for
a device special file the test does not make sense.
Either we change the check or we have to write a llseek
method for each device driver.
The patch below by-passes the check for non-file inodes.
The patch is against 2.4.5.ac16. The problem was introduced
earlier (at least on 2.4.3.ac14 the same check is there).
--- linux-2.4.5.ac16/fs/read_write.cTue Jun 19 15:11:58 2001
+++ linux-2.4.5.ac16.patched/fs/read_write.cTue Jun 19 15:28:37 2001
@@ -36,7 +36,7 @@
offset += file->f_pos;
}
retval = -EINVAL;
- if (offset>=0 && offset<=file->f_dentry->d_inode->i_sb->s_maxbytes) {
+ if (offset>=0 && (!S_ISREG(file->f_dentry->d_inode->i_mode) ||
+offset<=file->f_dentry->d_inode->i_sb->s_maxbytes)) {
if (offset != file->f_pos) {
file->f_pos = offset;
file->f_reada = 0;
Regards, Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
How to compile on one machine and install on another?
I am trying to compile the 2.2.19 kernel one one machine for installation on another. I believe I need to do more than just copy over bzImage and modify lilo.conf, but I don't know what. Is there documentation somewhere on how to do this? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac16 (linux_booted_ok: only on Intel implemented)
> linux_booted_ok(), called from init/main.c is not implemented on > other architectures than Intel. Yeah. I just need to drop null functions in. Im still not sure if that should in fact be invoked from user space - say on hitting run level 3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20-pre4
> On Tue, 19 Jun 2001, Alan Cox wrote: > [..] > > o Fix refclock build with newer gcc (Jari Ruusu) > > Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ? > If not what must be fixed/chenged to be ready ? It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can insert calls to 'memcpy' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 03:38:34PM -0400, Georg Nikodym wrote: > > "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes: > > > "MC" == Mike Castle <[EMAIL PROTECTED]> writes: > MC> What about the "UNIX is starting to smell bad" comment? :-> > > GN> I believe that it comes from a paper that Pike presented at a > GN> OSDI (or the Usenix general) last year on the theme of OS > GN> Research being dead. Links to it were also posted on /. around > GN> that time... > > Oops. I was wrong. I found the presentation I was referring to and > it doesn't have this quote. Ummm, the quote about "UNIX is starting to smell bad" is much, much older. I think I first heard in the 1989 Baltimore USENIX, when Pike was the featured speaker, and his talk was "Why workstations don't work", where he outlined Plan9. If it wasn't the Baltimore USENIX, it may have been Salt Lake city, Dallas, or the Boston one. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> But that foregoes the point that the code is far more complex and > harder to make 'obviously correct', a concept that *does* translate > well to userspace. Check the state threads library from SGI: http://oss.sgi.com/projects/state-threads/ It should provide the code clarity one is used from "real" threads and the efficiency of a state machine. Regards Joerg = -- Regards Joerg __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 08:18:59PM +0100, Alan Cox wrote: > > But that foregoes the point that the code is far more complex and harder to > > make 'obviously correct', a concept that *does* translate well to userspace. > > There I disagree. Threads introduce parallelism that the majority of user > space programmers have trouble getting right (not that C is helpful here). True. Balancing with what Larry said, threads require education. In good Unix tradition you can shoot yourself in the foot in many ways. > A threaded program has a set of extremely complex hard to repeat timing based > behaviour dependancies. An unthreaded app almost always does the same thing on > the same input. From a verification and coverage point of view that is > incredibly important. Reproducability is very important. But where threads may become inefficient if used unwisely (I handily do many megabits of DNS traffic with our threaded daemon by the way), statemachines have a way if becoming very intractable - leading to whole new problems. It's an 'enough rope' thing. Bad programmers will always write broken code - the saving grace of state machines are that they are hard to write, which means that *if* they are being used, it is often by a skilled programmer. Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes: > "MC" == Mike Castle <[EMAIL PROTECTED]> writes: MC> What about the "UNIX is starting to smell bad" comment? :-> GN> I believe that it comes from a paper that Pike presented at a GN> OSDI (or the Usenix general) last year on the theme of OS GN> Research being dead. Links to it were also posted on /. around GN> that time... Oops. I was wrong. I found the presentation I was referring to and it doesn't have this quote. Sorry, I'll get my pattern matching unit looked at pronto. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 corruption (again)
On Tue, 19 Jun 2001, Larry McVoy wrote: > OK, my corruption is back and this time I'm saving the data. Al, send some > email when you are around, we can talk about access to the data. I'm tarring Doing that. > up both good & bad right now. I've looked at a few files and they look > "shifted". > > extra junk > original file less sizeof(extra junk) bytes > > The machine has been up 6 days since the last corruption happened and the > process which detected the corruption ran successfully every night as well > as about 4 times by hand after my last corroption report. Lovely. Are these files longer than 4Kb, BTW? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> Which clearly marks you as a typical kernel-side developer :-) It never > ceases to amaze me how different a userland perspective can be from that of > people who live in kernel space. I've been writing multiuser games since 1987. I'm not just a kernel hacker > But that foregoes the point that the code is far more complex and harder to > make 'obviously correct', a concept that *does* translate well to userspace. There I disagree. Threads introduce parallelism that the majority of user space programmers have trouble getting right (not that C is helpful here). A threaded program has a set of extremely complex hard to repeat timing based behaviour dependancies. An unthreaded app almost always does the same thing on the same input. From a verification and coverage point of view that is incredibly important. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
softirq in pre3 and all linux ports
With pre3 there are bugs introduced into mainline that are getting extended to all architectures. First of all nucking the handle_softirq from entry.S is wrong. ppc copied without thinking and we'll need to resurrect it too for example so please arch maintainers don't kill that check (alpha in pre3 by luck didn't killed it I think). Without such check before returning to userspace any tasklet or softirq posted by kernel code will get a latency of 1/HZ. Secondly the pre3 softirq re-enables irqs before returning from do_softirq which is wrong as well because it can generate irq flood and stack overflow and do_softirq run not at the first not nested irq layer. Third if a softirq or a tasklet post itself running again the do_softirq can starve userspace in one or more cpus. Fourth if the tasklet or softirq or bottom half hander is been marked running again because of another even (like a nested irq) the kernel can starve userspace too. (softirqs are much heavier than the irq handler so it can also live lockup much more easily this way) This patch that I have in my tree since some day fixes all those issues. The assmembler changes needed in the entry.S files while returning to userspace can be described in C code this way, this is the 2.4.5 way: if (softirq_active(cpu) & softirq_mask(cpu)) do_softirq(); This is the 2.4.6pre3+belowfix way: if (softirq_pending(cpu)) do_softirq() pending doesn't need to be a 64bit integer (it can though) but it needs to be at least a 32bit integer. An `int' is fine for most archs, on alpha we use a long though and that's fine too. So I recommend Linus merging this patch that fixes all the above mentioned bugs (the anti starvation/live lockup logic is called ksoftirqd): ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1/00_ksoftirqd-6 Plus those SMP race fixes for archs where atomic operations aren't implicit memory barriers: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1/00_softirq-fixes-4 Plus this scheduler generic cpu binding fix to avoid ksoftirqd deadlocking at boot: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1/00_cpus_allowed-1 I verified the patches applies just fine to 2.4.6pre3 and they're not controversial. If you've any question on how to update a certain kernel port I will do my best to help in the update process! Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 data corruption
> Sometimes it takes either the kernel tree or our website some time to get > in 'sync' with the latest driver version. The latest driver version is > 1.02.00.007. > > There may be DAC960 like /proc support at some point for GUI haters. Publishing enough info to let people write a GPL non gui management tool would be a win in itself - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> How about "If you think you need threads, stop programming with closed > sourced libraries where the documentation doesn't give you a clue how > you might make things work within a state machine way" Linux inherits several unix properties which are not friendly to good state based programming - lack of good AIO for one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: b_dev vs. b_rdev confusion
> how do the inode->i_dev, i_rdev fit into this? These are what you see with stat(2). i_dev gives the device the file is on i_rdev is usually undefined, but for device special files it gives the real device. > Is there a set rule on when/where one should use a buffer head's > b_dev and when/where one should use b_rdev? b_dev gives the device the user was thinking about b_rdev is the actual underlying device Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
how to get DMA'able memory within 4GB on 64-bit machine
Hi List, Is there a way for a driver to ask kernel to give DMA'able memory within 4GB ? I read about pci_alloc_consistent(). But I could not find out whether that guarantees the DMA'able memory to be within 4GB or not. Is there any other kernel routine that I should call from Driver to get such a memory ? Regards, -hiren [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SMP] 2.4.5-ac13 memory corruption/deadlock?
> > I've got a strange situation, and I'm looking for a little direction. > > Quick summary: I get sporadic lockups running 2.4.5-ac13 on a > > ServerWorks HE-SL board (SuperMicro 370DE6), 2 800MHz Coppermine CPUs, > > 512M RAM, 512M+ swap. Machine has 8 active disks, two as RAID 1, > > 6 as RAID 5. Swap is on RAID 1. Machine also has a 100Mbit Netgear > > FA310TX and an Intel 82559-based 100Mbit card. SCSI controllers > > are AIC-7899 (2) and AIC-7895 (1). RAM is PC-133 ECC RAM; two > > identical machines display these problems. > > please adds nmi_watchdog=1 as kernel parameter ( append=... in lilo ) and try > again. Done, and I managed to get it to lock solid in under three hours. Two oopses in the syslog (follow). It looks like memory corruption: the BUG() that is called from spin_lock() and spin_unlock() test to see whether the spinlock at the given address has the proper magic; apparently it's gotten to the point where it doesn't. In this case the lock that has gotten mangled is dcache_lock. Unfortunately, I don't think that this particular lockup is repeatable, but I'm going to try again anyway to see if the same pattern of memory corruption occurs. -Bob kernel BUG at /usr/src/linux-2.4.5-ac13/include/asm/spinlock.h:113! invalid operand: CPU:0 EIP:0010:[d_alloc+413/504] EFLAGS: 00010286 eax: 0044 ebx: de9f811c ecx: c027c088 edx: 869b esi: c6e3fed1 edi: c190a14c ebp: c6e3fee8 esp: c6e3fe94 ds: 0018 es: 0018 ss: 0018 Process sshd (pid: 565, stackpage=c6e3f000) Stack: c0238840 0071 de38bd04 c7f5ee94 c6e3fed2 0004 c01dae97 c190a11c c6e3fee8 de38bd04 c7975f14 c6e3ff14 bca8 3532325b 35373138 c01d005d bca8 c6e3ff14 0010 de38bd04 c7975f14 c6e3fec8 0009 002274ff Call Trace: [sock_map_fd+211/532] [mark_rdev_faulty+17/60] [sys_accept+197/252] [__free_pages+27/28] [free_pages+33/36] [poll_freewait+58/68] [do_select+523/548] [select_bits_free+10/16] [sys_select+1135/1148] [sys_socketcall+180/512] [system_call+51/56] Code: 0f 0b 83 c4 08 8d b6 00 00 00 00 a0 c0 e2 27 c0 84 c0 7e 17 eip: c0152f37 (d_lookup) kernel BUG at /usr/src/linux-2.4.5-ac13/include/asm/spinlock.h:101! invalid operand: CPU:1 EIP:0010:[d_lookup+121/476] EFLAGS: 00010282 eax: 0044 ebx: dffe9f68 ecx: c027c088 edx: 8a07 esi: edi: c1933824 ebp: b818 esp: dffe9f04 ds: 0018 es: 0018 ss: 0018 Process init (pid: 1, stackpage=dffe9000) Stack: c0238840 0065 dffe9f68 c1933824 b818 dff40a20 d228d001 0023ee05 0003 c014850c c1932de4 dffe9f68 dffe9f68 c0148d09 c1932de4 dffe9f68 0004 d228d000 dffe9fa4 b818 c01480ca 0009 Call Trace: [cached_lookup+16/84] [path_walk+889/3104] [getname+90/152] [__user_walk+60/88] [sys_stat64+22/120] [system_call+51/56] eip: c021f2f4 (atomic_dec_and_lock) kernel BUG at /usr/src/linux-2.4.5-ac13/include/asm/spinlock.h:101! Code: 0f 0b 83 c4 08 f0 fe 0d c0 e2 27 c0 0f 88 22 17 0d 00 8b 54 invalid operand: Kernel panic: Attempted to kill init! > > I've seen three variations of symptoms: > > > > 1) Almost complete lockout - machine responds to interrupts (indeed, > > it can even complete a TCP connection) but no userspace code gets > > executed. Alt-SysRq-* still works, console scrollback does not; > > 2) Partial lockout - lock_kernel() seems to be getting called without > > a corresponding unlock_kernel(). This manifested as programs such > > as 'ps' and 'top' getting stuck in kernel space; > > 3) Unkillable programs - a test program that allocates 512M of memory > > and touches every page; running two copies of this simultaneously > > repeatedly results in at least one of the copies getting stuck > > in 'raid1_alloc_r1bh'. > > > > Symptom number 1 was present in 2.4.2-ac20 as well; symptoms 2 and 3 > > were observed under 2.4.5-ac13 only. I never get any PANICs, only > > these variety of deadlocks. A reboot is the only way to resolve the > > problem. > > > > There seem to be two ways to manifest the problem. As alluded to in > > (3), running two copies of the memory eater simultaneously along with > > calls to 'ps' and 'top' trigger the bug fairly quickly (within a minute > > or two). Another method to manifest the problem is to run multiple > > copies of this script (I run 10 simultaneous copies): > > > > #!/bin/sh > > > > while /bin/true; do > > ssh remote-machine 'sleep 1' > > done > > > > This script causes (1) in about a day or two. > > > > If anyone has any suggestions about how to proceed to figure out what > > the problem is (or if there is already a fix), please let me know. > > I would be more than willing to provide a wide range of cooperation on > > this problem. I don't have a feel for where to go from here, and I'm > > hoping that someone with more experience can give me some > > assistance.. > > > > -Bob > > - > > To unsubscribe from this list:
Re: Alan Cox quote?
On Tue, Jun 19, 2001 at 08:01:00PM +0200, Kai Henningsen wrote: > The funny thing here, Larry, is that to most people (who aren't OS gurus), > Linux' clone or Plan 9's rfork *are* threads. > > I certainly agree that you don't necessarily need two different kernel- > level kinds of things, but really, most of the time when people talk about > threads Great, then we are in violent agreement on the single abstraction. On the second part, I stand by my previous statements that threads or processes should be used sparingly. All I'm doing is trying to counter all the "threads are great" hype. This is a pretty intelligent pile of people but there are also a fair number of people who read this list looking for nuggets of information. If they walk away going "(a) Linux has a cool threading model, and (b) I should only use threads if I absolutely have to do so and even then if there are more than there are CPUs I'm probably making a mistake", if they get that message, that's a good thing, IMHO. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AMD756VIPER PCI IRQ Routing Patch (Need Additional Tests)
Hi,
I have been working on a small patch to add support for AMD756 PCI IRQ
Routing with linux-2.4.5
This has been tested with a Gigabyte 7IXE 7F board and several PCI cards,
including a SMC-Lucent PCI Cardbus Bridge which doesn't get an IRQ
assigned by the BIOS.
If anybody has a board based on this chipset I would appreciate further
testing and advise about the patch.
In this alpha version, I left two printk() lines to get information
about the IRQ settings.
You should get an output like the following:
[root@klingon ~]# dmesg | grep 756
PCI: Using IRQ router AMD756 VIPER [1022/740b] at 00:07.3
AMD756: dev 104c:ac1c, router pirq : 4 get irq : 0
AMD756: dev 104c:ac1c, router pirq : 4 get irq : 0
AMD756: dev 10ec:8029, router pirq : 3 get irq : 10
AMD756: dev 104c:ac1c, router pirq : 4 get irq : 0
AMD756: dev 104c:ac1c, router pirq : 4 SET irq : 5
AMD756: dev 104c:ac1c, router pirq : 4 get irq : 5
AMD756: dev 11fe:0005, router pirq : 1 get irq : 12
Thanks.
diff -u linux-2.4.5/arch/i386/kernel/pci-irq.c \
linux/arch/i386/kernel/pci-irq.c > linux-2.4.5_amd756-pci-routing-alpha1.patch
--
Jhon H. Caicedo O. <[EMAIL PROTECTED]>
Observatorio Sismológico del SurOccidente O.S.S.O
http://www.osso.org.co
Cali - Colombia
--- linux-2.4.5/arch/i386/kernel/pci-irq.c Wed May 16 12:25:39 2001
+++ linux/arch/i386/kernel/pci-irq.cTue Jun 19 13:20:47 2001
@@ -391,6 +391,56 @@
return 1;
}
+/*
+ * Jun/19/2001 Support for AMD756 PCI Router (Alpha Release)
+ * Jhon H. Caicedo <[EMAIL PROTECTED]>
+ * The AMD756 pirq rules are nibble-based
+ * offset 0x56 0-3 PIRQA 4-7 PIRQB
+ * offset 0x57 0-3 PIRQC 4-7 PIRQD
+ */
+static int pirq_amd756_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
+{
+ u8 irq_value;
+ u8 irq;
+
+ if (pirq < 5)
+ {
+ if (pirq < 3)
+ pci_read_config_byte(router, 0x56, _value);
+ else
+ pci_read_config_byte(router, 0x57, _value);
+ if (pirq & 1)
+ irq = irq_value & 15;
+ else
+ irq = irq_value >> 4;
+ printk(KERN_INFO "AMD756: dev %04x:%04x, router pirq : %d get irq :
+%2d\n",
+ dev->vendor, dev->device, pirq, irq);
+ return irq;
+ }
+return 0;
+}
+
+static int pirq_amd756_set(struct pci_dev *router, struct pci_dev *dev, int pirq, int
+irq)
+{
+ u8 irq_value;
+ u8 offset;
+
+ printk(KERN_INFO "AMD756: dev %04x:%04x, router pirq : %d SET irq : %2d\n",
+ dev->vendor, dev->device, pirq, irq);
+
+ if (pirq < 3)
+ offset = 0x56;
+ else
+ offset = 0x57;
+ pci_read_config_byte(router, offset, _value);
+ if (pirq & 1)
+ irq_value = (irq_value & 0xF0) | irq;
+ else
+ irq_value = (irq_value & 0x0F) | (irq << 4);
+ pci_write_config_byte(router, offset, irq_value);
+ return 1;
+}
+
#ifdef CONFIG_PCI_BIOS
static int pirq_bios_set(struct pci_dev *router, struct pci_dev *dev, int pirq, int
irq)
@@ -426,6 +476,8 @@
{ "VLSI 82C534", PCI_VENDOR_ID_VLSI, PCI_DEVICE_ID_VLSI_82C534, pirq_vlsi_get,
pirq_vlsi_set },
{ "ServerWorks", PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_OSB4,
pirq_serverworks_get, pirq_serverworks_set },
+ { "AMD756 VIPER", PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_VIPER_740B,
+ pirq_amd756_get, pirq_amd756_set },
{ "default", 0, 0, NULL, NULL }
};
Re: b_dev vs. b_rdev confusion
On Tue, 19 Jun 2001 [EMAIL PROTECTED] wrote: > All of the md code looks like it copies the buffer head, setting > b_dev=b_rdev="real device" in the new bh and leaving b_dev==b_rdev="logical > device" in the original bh. I'm assuming they do this for a reason, but > it would be nice from a performance standpoint to just touch b_rdev and > b_end_io and be done. Is there something I'm missing which necessitates the > copy? Oops...I take that back. In the md code for raid1, raid5 and multipath I see copies, but not in lvm or linear. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
b_dev vs. b_rdev confusion
These are probably dumb questions but I haven't been able to find definitive answers... Is there a set rule on when/where one should use a buffer head's b_dev and when/where one should use b_rdev? I'm been tracing through the kernel source quite a bit and it seems like above ll_rw_blk.c's submit_bh() b_dev is being used. Below there as the request heads off into whichever block device b_rdev is used. Is this true? Things read like the b_dev/b_rdev distinction was introduced to facilitate block drivers intercepting and redirecting requests (lvm, raid, multipathing, ) and I'm trying to figure out if there's a clean delineation of which is used where and if I can safely twiddle b_rdev and pass the buffer head on without copying it. (Are these what are somtimes called "stacking drivers" here?) All of the md code looks like it copies the buffer head, setting b_dev=b_rdev="real device" in the new bh and leaving b_dev==b_rdev="logical device" in the original bh. I'm assuming they do this for a reason, but it would be nice from a performance standpoint to just touch b_rdev and b_end_io and be done. Is there something I'm missing which necessitates the copy? And how do the inode->i_dev, i_rdev and i_bdev fit into this? When are those set and does anything get confused by i_rdev moving? Thanks in advance for any suggestions/info... Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> "MC" == Mike Castle <[EMAIL PROTECTED]> writes: MC> What about the "UNIX is starting to smell bad" comment? :-> I believe that it comes from a paper that Pike presented at a OSDI (or the Usenix general) last year on the theme of OS Research being dead. Links to it were also posted on /. around that time... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote?
[EMAIL PROTECTED] (Larry McVoy) wrote on 19.06.01 in <[EMAIL PROTECTED]>: > Another one that I can't believe I forgot is from Rob Pike: > > "If you think you need threads then your processes are too fat" > > And one from me: > > ``Think of it this way: threads are like salt, not like pasta. You > like salt, I like salt, we all like salt. But we eat more pasta.'' > > Threads are a really bad idea. All you need are processes and either the > ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good > old mmap(2). If you allow threads then all you are saying is that your > process model is so pathetic you had to invent another, supposedly lighter > weight, object to do the same thing. The funny thing here, Larry, is that to most people (who aren't OS gurus), Linux' clone or Plan 9's rfork *are* threads. I certainly agree that you don't necessarily need two different kernel- level kinds of things, but really, most of the time when people talk about threads, they don't care one whit how their libraries manage to produce threads, as long as those threads actually work. Threads are a kind of abstraction. And the argument that you don't need threads when you have state machines is exactly as valid as the one that says that you don't need loops when you have goto. Oh, you also don't need subroutines when you have state machines and goto. Fancy that! I've even been told you can do all these things with nothing more than a Turing machine ... MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gnu asm help...
On 19 Jun 01 at 13:21, Richard B. Johnson wrote: > On Tue, 19 Jun 2001, Timur Tabi wrote: > > Oh, I see the problem. You could do something like this: > > > > cli > > mov %0, %%eax > > inc %%eax > > mov %%eax, %0 > > sti > > > > and then return eax, but that won't work on SMP (whereas the "lock inc" does). > > Doing a global cli might work, though. Use spinlocks instead of global cli. Global cli can take milliseconds. > The Intel book(s) state that an interrupt is not acknowledged until > so many clocks (don't remember the number) after a stack operation. Reread it. It says 'after operation with ss' - that is after "mov ,%ss" or "pop %ss", as it is expected that next instruction will be "movl ,%esp". Before "lss " (it is lss in intel mnemonic...) was invented, you could not switch your stack safely without this feature, as NMI could arrive in the middle of your stack switch without blocking all interrupts after "mov ,%ss". BTW, if you chain "mov %eax,%ss" back to back, they are executed in pairs - irq can arrive after even mov, but cannot after odd (at least on PII and PIII). But it is a bit off topic for L-K (except that we can try other clones, maybe someone got it wrong?) Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: compiling with gcc 3.0
It was posted by Alan Cox where I now add my 0.02 EUR... > > I was trying to compile 2.4.5 with gcc 3.0 but there is a problem > > (conflicting type) between kernel/timer.c and include/linux/sched.h > > Apparently the problem solves with this oneline workarond: > > Yep. Its fixed in the pre-patches I believe now. There are also a pile of > warning fixes that need to be merging. I would still be very wary of relying > on a gcc 3.0.0 built kernel though Since the rwsem had been fixed my 2.4.3-ac7 (with Andrea's generic rwsem) has been rock solid, and it has been built with a binary snapshot of april 2001. We don't have any problems using it yet. I can send the .config if you want. -mirabilos -- C:\>debug -e100 EA F0 FF 00 F0 -g --->Enjoy! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
Larry McVoy wrote: > > On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote: > > On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote: > > > Another one that I can't believe I forgot is from Rob Pike: > > > > > > "If you think you need threads then your processes are too fat" > > > > Also, I could never actually find the "too fat" quote anywhere. > > I can personally vouch for the too fat comment, I've heard him say it in > person. How about "If you think you need threads, stop programming with closed sourced libraries where the documentation doesn't give you a clue how you might make things work within a state machine way" Regards, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 10:37:12AM -0700, Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> > Also, I could never actually find the "too fat" quote anywhere.
>
> I can personally vouch for the too fat comment, I've heard him say it in
> person.
What about the "UNIX is starting to smell bad" comment? :->
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 10:36:00AM -0700, Jonathan Lundell wrote: > At 9:09 AM -0700 2001-06-19, Larry McVoy wrote: > >Don't you think it is funny that Sun doesn't publish numbers comparing > >their thread performance to process performance? Sure, you can find > >context switch benchmarks where they have user level switching going on > >but those are a red herring. The real numbers you want are the kernel > >level context switches and those are just as expensive as the process > >context switch numbers. > > Sun (or at least SPARC) is a bit of a special case, though. SPARC's > register-window architecture makes thread-switching (not to mention > recursion) significantly more expensive than on most other > architectures. Yes, but that misses the point. The point is that you have to do the same work, almost, to switch a kernel thread as a process. You don't have to switch the VM context but that isn't the dominating term. So the fact that Sun has slow[er] context switching and slow[er] thread switching isn't the issue. The issue is that people perceive threads to be cheap but they are not cheap at all. It's the relative cheapness, or lack thereof, when comparing them to processes. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote: > On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote: > > Another one that I can't believe I forgot is from Rob Pike: > > > > "If you think you need threads then your processes are too fat" > > Also, I could never actually find the "too fat" quote anywhere. I can personally vouch for the too fat comment, I've heard him say it in person. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac15 -- Unresolved symbols "gameport_register_port"
On Wed, Jun 20, 2001 at 12:43:02AM +1000, Keith Owens wrote: > On Tue, 19 Jun 2001 16:35:20 +0200, > Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > >On Wed, Jun 20, 2001 at 12:30:05AM +1000, Keith Owens wrote: > >> Gameports and joysticks should not be available unless input core > >> support is selected first. Invalid configs were slipping through. > > > >Gameports are not input core dependent. > >Only joysticks are. > > drivers/char/Makefile says > subdir-$(CONFIG_INPUT) += joystick > > Gameports are in subdir joystick. Certainly looks dependent on > CONFIG_INPUT to me. Ouch. Forgot about this one. I guess it'd be better to fix this, because the gameport code really is independent on input. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
At 9:09 AM -0700 2001-06-19, Larry McVoy wrote: >Don't you think it is funny that Sun doesn't publish numbers comparing >their thread performance to process performance? Sure, you can find >context switch benchmarks where they have user level switching going on >but those are a red herring. The real numbers you want are the kernel >level context switches and those are just as expensive as the process >context switch numbers. Sun (or at least SPARC) is a bit of a special case, though. SPARC's register-window architecture makes thread-switching (not to mention recursion) significantly more expensive than on most other architectures. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac16
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.5-ac16 o Drop the shmem/removepage changes to see if they(me) are cuaisng the instabilities in ac15 o Fix bug in pci_init_module causing serial crash (me) | Figured out by Niels Jensen o Alpha build fixes for keyboard change (Jay Thorne) o Tidy up imsttfb driver (Paul Mundt) o Fix tdfxfb warning (Steven Walter) o Fix fat fs build on ARM (Russell King) o Fix catc help text (Brad Hards) o Fix missing unlock_kernel in fs/locks.c (Andrey Savochkin) o Minixfs alloc_branch fixes (Al Viro) o Support bootflag extension (me) | Experimental o Add EMC Symmetrix to the sparselun list (Alar Aun) o Update the ioc3 ethernet(Ralf Baechle) o Add ataraid to the known root names (Arjan van de Ven) o Further Sony Pi driver upgrades (Stelian Pop) o Add geometry queries to the ataraid driver (Arjan van de Ven) o Add ALi IRDA FIR support(Benjamin Kong) o Fix gameport compile failures (Keith Owens) o Fixes IrLMP states stuck in CONN_PEND state (Jean Tourrilhes) o Small cris config fixes (Andrzej Krzysztofowicz) o Fix some potential irlan bugs/stack abuse (Ted Unangst) o Fix OSS API bug in USB audio(Bruce Nesbitt) o Update the MIPS64 core (Ralf Baechle, Thiemo Seurer, and others) o Update the MIPS32 core (Ralf Baechle, Kevin Kissell, Carsten Langgaard, Justin Carlson, Jun Sun) o Add a driver for the AU1000 ethernet(P Popov) o Fix security problems with i810 and MGA drm (Jeff Hartmann) o Use a saner computation for maxthreads (Rik van Riel) o Update matroxfb, support G100 SGRAM (Petr Vandrovec) o Fix hang in scsi generic with cdrdao(Doug Gilbert) o Correct aha152x abort fix (Jüergen E. Fischer) 2.4.5-ac15 o Enable MMX extensions on Cyrix MII (me) o Make pid on core dump configurable (Ben LaHaise) o Random UML fixups, add fcntl64/getdents64 (Jeff Dike) o Add multicast support to UML(Harland Welte) o Ensure promise raid driver doesnt look at non (Arjan van de Ven) disk devices o Fix IDE chipsets that incorrectly think a 64K (Mark Lord) DMA is in fact zero size o Fix generic alpha build trident driver (Michal Jaegermann) o SHM accounting fixes(Christoph Rohland) o Update refill_inactive to match Linus tree (Rik van Riel) o Add Asustek L8400K to the dmi data (me) o Add kernel mode keyboard rate setup (Sergey Tursanov) o Alpha compile fix (Richard Henderson) o Add Ali1533 to the isa dma quirks (Angelo Di Filippo) o Fix a procfs oops (Al Viro) o Alpha symbol/warning fixes (Michal Jaegermann) o Some laptops take a long time for the cs4281(Rik van Riel) and codec bus to wake up o Fix potential flags corruption on error path(me) in comx-mixcom driver 2.4.5-ac14 o Fix oops on command abort on aha152x(me) | This so far is only a partial fix o Switch to unlazy swap cache free up (Marcelo Tosatti) o Page launder changes(Rik van Riel) o Remove dead irda irlap compression code (Dag Brattli) o Fix bug where init/main.c executes freed code (Hans-Peter Nilsson) o Fix ramfs accounting. truncate/freepage hook(Christoph Rohland) o Add MTWEOF ioctl to parallel tape (Russ Ingram) o Add driver for CATC based USB ethernet (Vojtech Pavlik) o Update cris architecture code (Bjorn Wesen) o Clean up reiserfs tail->full page convert (Chris Mason) o Clean up lp init, fix lp= option handling (Tim Waugh) o Don't panic on out of memory during ps/2 setup (Andrey Panin) o Initialise vc_cons objects in full (Richard Hirst) o Futher Configure.help resync(Eric Raymond) o Fix misdeclaration of xtime (Petr Vandrovec) o Add yet more sb variants
Re: gnu asm help...
On Tue, 19 Jun 2001, Timur Tabi wrote: > ** Reply to message from "Petr Vandrovec" <[EMAIL PROTECTED]> on Tue, 19 Jun > 2001 01:36:26 MET-1 > > > > No. Another CPU might increment value between LOCK INCL and > > fetching v->counter. On ia32 architecture you are almost out of > > luck. You can either try building atomic_inc around CMPXCHG, > > using it as conditional store (but CMPXCHG is not available > > on i386), or you can just guard your atomic variable with > > spinlock - but in that case there is no reason for using atomic_t > > at all. > > Oh, I see the problem. You could do something like this: > > cli > mov %0, %%eax > inc %%eax > mov %%eax, %0 > sti > > and then return eax, but that won't work on SMP (whereas the "lock inc" does). > Doing a global cli might work, though. The Intel book(s) state that an interrupt is not acknowledged until so many clocks (don't remember the number) after a stack operation. Given this, is an 'attack' by another CPU allowed within this time-frame? If not, you can do: pushl %ebx movlINPUT_VALUE(%esp), %eax # Get input value movlINPUT_PTR(%esp), %ebx # Get input pointer lock addl%eax,(%ebx) # Add value pushl (%ebx) # Put result on stack popl%eax# Return value in EAX popl%ebx It may be worth an experiment. In any event, you can always use a local lock to make these operations atomic. # Stack offsets VALUE = 0x08 POINTER = 0x0C .section .data __local_lock: .long 0 .section .text .global add_atom .type add_atom,@function add_atom: pushf cli incb(__local_lock) # Set the lock 1: cmpb$1,(__local_lock) jnz 1b pushl %ebx movlVALUE(%esp), %eax movlPOINTER(%esp), %ebx addl%eax, (%ebx) movl(%ebx), %eax popl%ebx decb(__local_lock) # Release the lock popf ret The lock can also be done as: incb(__local_lock) 1: cmpb$1,(__local_lock) jz 2f repz nop jmp 1b 2: (maybe) the CPU being locked loops in low-power mode. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> Another one that I can't believe I forgot is from Rob Pike:
>
> "If you think you need threads then your processes are too fat"
Pike also to have said, "Not only is UNIX dead, it's starting to smell bad."
Also, I could never actually find the "too fat" quote anywhere. Best I
could find was one of Pike's papers on the plan9 site. Best that I can
tell is that both of these quotes are Urban Legends.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Direct access to the RTC ...
Hi ! I have a program that need to have a precision better than 1ms. Is there any way to change the "tick" field of the "adjtimex" function to reduce it under 1000 (reprogramming the RTC) ? Friendly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
I can understand the opinnions expressed by these quotes. Having seen how horribly certain CORBA monsters work, I am sure that the basic idea of threads is lost somewhere along the way... On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote: > > > >-- > > > > "A Computer is a state machine. > > > > Threads are for people who can't program state machines." > > > > - Alan Cox > And one from me: > > ``Think of it this way: threads are like salt, not like pasta. You > like salt, I like salt, we all like salt. But we eat more pasta.'' > > Threads are a really bad idea. All you need are processes and either the > ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good > old mmap(2). If you allow threads then all you are saying is that your > process model is so pathetic you had to invent another, supposedly lighter > weight, object to do the same thing. That is usually true. In rare cases I *do* want to use threads, or things just alike them. Pre-requisite are for wanting to share very large amounts of the VM of the processes and/or IO descriptors, have multiple processors in the system capable to execute my code, and wanting to parallellize (with lack of AIO) certain IO activities (disk related, mainly) which normal non-blocking IO can't handle. Threads are like salt, best used in moderation. They are resources, and hogging them will very rapidly cause the harms to exceed the benefits. (...that CORBA beast...) ... creates a thread for each incoming request without any sort of limit at how much there can be threads running in parallel. > Don't you think it is funny that Sun doesn't publish numbers comparing > their thread performance to process performance? Sure, you can find > context switch benchmarks where they have user level switching going on > but those are a red herring. The real numbers you want are the kernel > level context switches and those are just as expensive as the process > context switch numbers. If they weren't, I would be most amazed.. > -- > Larry McVoylm at bitmover.com http://www.bitmover.com/lm /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFQ] aic7xxx driver panics under heavy swap.
>
>Justin,
>When free memory is low, I get a series of aic7xxx messages followed by
>panic. It appears to be a race condition in the code.
Its actually a logic error, not a race condition. You should never
enter ahc_linux_run_device_queue() while the device is still on the
run queue. The real issue is that ahc_linux_queue bypasses the
round-robin device scheduler by calling ahc_linux_run_device_queue()
directly. The code should look like this (the LIST macro calls
where switched to TAILQ calls a bit ago to ensure round-robin, but
that change came just after 6.1.13). I haven't tested this yet...
Thanks for the bug report. If you can verify that this works under
memeory pressure, the printf can go away.
--
Justin
//depot/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c#67 -
/usr/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c
--- /tmp/tmp.3288.0 Tue Jun 19 11:07:32 2001
+++ /usr/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c Tue Jun 19 11:02:54 2001
@@ -1514,7 +1514,11 @@
}
cmd->result = CAM_REQ_INPROG << 16;
TAILQ_INSERT_TAIL(>busyq, (struct ahc_cmd *)cmd, acmd_links.tqe);
- ahc_linux_run_device_queue(ahc, dev);
+ if ((dev->flags & AHC_DEV_ON_RUN_LIST) == 0) {
+ TAILQ_INSERT_TAIL(>platform_data->device_runq, dev, links);
+ dev->flags |= AHC_DEV_ON_RUN_LIST;
+ ahc_linux_run_device_queues(ahc);
+ }
ahc_unlock(ahc, );
return (0);
}
@@ -1530,6 +1534,9 @@
struct ahc_tmode_tstate *tstate;
uint16_t mask;
+ if ((dev->flags & AHC_DEV_ON_RUN_LIST) != 0)
+ panic("running device on run list");
+
while ((acmd = TAILQ_FIRST(>busyq)) != NULL
&& dev->openings > 0 && dev->qfrozen == 0) {
@@ -1538,8 +1545,6 @@
* running is because the whole controller Q is frozen.
*/
if (ahc->platform_data->qfrozen != 0) {
- if ((dev->flags & AHC_DEV_ON_RUN_LIST) != 0)
- return;
TAILQ_INSERT_TAIL(>platform_data->device_runq,
dev, links);
@@ -1550,8 +1555,6 @@
* Get an scb to use.
*/
if ((scb = ahc_get_scb(ahc)) == NULL) {
- if ((dev->flags & AHC_DEV_ON_RUN_LIST) != 0)
- panic("running device on run list");
TAILQ_INSERT_TAIL(>platform_data->device_runq,
dev, links);
dev->flags |= AHC_DEV_ON_RUN_LIST;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 05:26:09PM +0100, Matthew Kirkwood wrote: > On Tue, 19 Jun 2001, Larry McVoy wrote: > > > ``Think of it this way: threads are like salt, not like pasta. You > > like salt, I like salt, we all like salt. But we eat more pasta.'' > > This is oft-quoted but has, IMO, the property of not actually > making any sense. Hmm. Makes sense to me. All it is saying is that you can't make a good dinner out of a pile of salt. It was originally said to some GUI people who wanted to use a thread per object, every button, scrollbar, canvas, text widget, menu, etc., are all threads. What they didn't figure out is that a thread needs a stack, the stack is the dominating space term, and they were looking at a typical desktop with around 9,000 objects. Times, at that point, an 8K stack. That was 73MB in stacks. Pretty darned stupid when you look at it that way, huh? Nobody is arguing that having more than one thread of execution in an application is a bad idea. On an SMP machine, having the same number of processes/threads as there are CPUs is a requirement to get the scaling if that app is all you are running. That's fine. But on a uniprocessor, threads are basically stupid. The only place that I know of where it is necessary is for I/O which blocks. And even there you only need enough to overlap the I/O such that it streams. And processes will, and do, work fine for that. I think the general thrust of us ``anti-thread'' people is that a few are fine, a lot is stupid, and the model encourages a lot. It's just like perl5, C++, pick-your-favorite-feature-rich-language in that exceptional programmers will do a good job with the problem but average programmers will do a horrible job. Given that there are only a few exceptional programmers and a never ending wave of average programmers, the argument is that one should tailor the paradigm for the common case, not for the exceptional case. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to patch driver into kernel
[EMAIL PROTECTED] wrote: >hi: > I write a serial driver for linux , and have a personal test . I went >to patch this driver into kernel >but I don't know how to contact serial.c author .. >can any one help me ? > rich.liu > For future patches please read the Documentation/SubmittingPatches and Documentation/SubmittingDrivers files. Regards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.10-pre4, error while applying the patch
> patching file `drivers/scsi/sym53c8xx_defs.h' > The next patch would create the file `drivers/sound/ad1848.c', > which already exists! Assume -R? [n] My error - just skip the ad1848.c segment - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20-pre4
Hi again, On 19 Jun 2001, Jochen Striepe <[EMAIL PROTECTED]> wrote: > > Now it stops with OK, this resolved to nothing (my mistake). Now it works fine. Until it reaches ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ fs/filesystems.a \ net/network.a \ drivers/block/block.a drivers/char/char.o drivers/misc/misc.a drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/pci/pci.a drivers/pnp/pnp.a drivers/video/video.a \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom': aic7xxx.o(.text+0x12a76): undefined reference to `memcpy' make: *** [vmlinux] Error 1 HAND, Jochen. -- "Gosh that takes me back ... or forward. That's the trouble with time travel, you never can tell." -- Dr. Who - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Using cramfs as root filesystem on diskless machine
Le Tue, Jun 19, 2001 at 07:44:52PM +0400, Alexandr Andreev écrivait : > David L. Parsley wrote > > Possibly, some symlinks are broken, or some libraries are missed, on my > rootfs... > But it is very strange, that ext2fs ramdisk image works with the same > rootfs on it. > I'll try to investigate it by myself. I have almost the same problem, I am using a cramfs root filesystem, not a ramdisk cramfs. When I use the very same content on ext2 mounted read-only everything work as expected, but with cramfs some daemons don't start (mingetty for example)... I mount tmpfs in /tmp and files touched in /var are symlinks to files in /tmp... I don't have a clue of what goes wrong, hints a more than welcome ;) linux is 2.4.5-ac15+patch for cramfs by Daniel Quinlan+Mathias Killian (http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html) Regards, Sept -- Stéphane Casset LOGIDÉE sàrl Se faire plaisir d'apprendre 3, quai Kléber, Tour Sébastopol Tel : +33 388 23 69 77 [EMAIL PROTECTED] F-67080 STRASBOURG Cedex 3Fax : +33 388 23 70 00 http://logidee.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.10-pre4, error while applying the patch
Hi, While I apply the patch pre-patch-2.2.20-4 to a clean 2.2.19 tree, I get the following error : patching file `drivers/scsi/sd_ioctl.c' patching file `drivers/scsi/sym53c8xx.c' patching file `drivers/scsi/sym53c8xx_defs.h' The next patch would create the file `drivers/sound/ad1848.c', which already exists! Assume -R? [n] - Regards Jean-Luc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20-pre4
Hi, On 19 Jun 2001, Alan Cox <[EMAIL PROTECTED]> wrote: > > > sched.c:52: conflicting types for `xtime' > > /usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime' > > Stick a volatile in the declaration. Thats a real bug it found Um... I made it extern volatile struct timeval xtime; Now it stops with /usr/src/linux/include/linux/sched.h: At top level: /usr/src/linux/include/linux/sched.h:509: warning: useless keyword or type name in empty declaration In file included from /usr/src/linux/include/linux/blkdev.h:6, from ksyms.c:15: /usr/src/linux/include/linux/genhd.h: In function `ptype': /usr/src/linux/include/linux/genhd.h:83: warning: deprecated use of label at end of compound statement ksyms.c: At top level: ksyms.c:352: `xtime' undeclared here (not in a function) ksyms.c:352: initializer element is not constant ksyms.c:352: (near initialization for `__ksymtab_xtime.value') make[2]: *** [ksyms.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel' make: *** [_dir_kernel] Error 2 So long, Jochen. -- The number of UNIX installations has grown to 10, with more expected. - Dennis Ritchie and Ken Thompson, June 1972 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What happened to lookup_dentry?
** Reply to message from Alexander Viro <[EMAIL PROTECTED]> on Mon, 18 Jun 2001
19:45:11 -0400 (EDT)
> It depends on what kind of use 2.2 code had for it. There are several
> situations in which it used to be called and proper replacements depend
> on the context. Details, please... (alternatively, send an URL of patch
> and I'll see what to do with the thing)
Well, I didn't write the driver that I'm trying to port, so it's a little
difficult. The code in question is:
struct dentry * de = lookup_dentry(zfcdb[i].fullname, NULL, LOOKUP_FOLLOW);
if (IS_ERR(de))
continue;
if (de != zfcdb[i].dentry)
{
print("zfc: dentry changed for %s\n", zfcdb[i].fullname);
zfc_file_init([i], de);
}
So it appears it's just checking to see if the dentry for a particular file has
changed.
--
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
We'll yes it's true you can program everything like a state machine if the correct OS interfaces are there. I don't think they are though ATM. Also some things are more elegantly implemented using threads, whereas others are better as state machines. Padraig. David S. Miller wrote: >Dan Kegel writes: > > Alan, did you really say that, or are people taking your name in vain? > >He did say it, and I for one agree with him. :-) > >Later, >David S. Miller >[EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 08:58:20AM -0700, Dan Kegel wrote: > [EMAIL PROTECTED] wrote: > > > > On an unrelated note: > > > > I noticed the quote below in your message. Is this a true quote or just a > > joke going around? I have tried believing it is just a joke but I am > > scared it is not. > > > > >-- > > > "A Computer is a state machine. > > > Threads are for people who can't program state machines." > > > - Alan Cox > > Alan, did you really say that, or are people taking your name in vain? Yup Alan said and I liked it so much I put it on my quotes page, http://www.bitmover.com/lm/quotes.html Another one that I can't believe I forgot is from Rob Pike: "If you think you need threads then your processes are too fat" And one from me: ``Think of it this way: threads are like salt, not like pasta. You like salt, I like salt, we all like salt. But we eat more pasta.'' Threads are a really bad idea. All you need are processes and either the ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good old mmap(2). If you allow threads then all you are saying is that your process model is so pathetic you had to invent another, supposedly lighter weight, object to do the same thing. Don't you think it is funny that Sun doesn't publish numbers comparing their thread performance to process performance? Sure, you can find context switch benchmarks where they have user level switching going on but those are a red herring. The real numbers you want are the kernel level context switches and those are just as expensive as the process context switch numbers. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
