* What would you like to see most in minix?
@ 1991-08-25 20:57 99% Linus Benedict Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Benedict Torvalds @ 1991-08-25 20:57 UTC (permalink / raw)
To: Linux Kernel Mailing List
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).
I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)
Linus (torvalds@kruuna.helsinki.fi)
PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.
^ permalink raw reply [relevance 99%]
* Re: Progress! was: Re: Yet more VM writable swap-cached pages
@ 1998-07-10 0:54 98% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1998-07-10 0:54 UTC (permalink / raw)
To: Stephen C. Tweedie
Cc: ganesh.sittampalam, Virtual Memory problem report list, mingo,
Bill Hawes, Alan Cox, David S. Miller
On Fri, 10 Jul 1998, Stephen C. Tweedie wrote:
> with no rwe currently enabled. Page flags are normal for a resident
> swap-cached anonymous page with no IO in flight. The page count, 2, is
> also normal for a cached anonymous page. The pte, 6a8042, is not normal
> at all. It is marked non-present (the lowest bit is clear) but
> _PAGE_PROTNONE. That changes everything.
Cool. This does indeed explain it.
The _PAGE_PROTNONE was a clever way to get the correct unreadability on an
x86, but I did indeed miss the fact that now a page can be marked
"present" as far as the Linux memory management is concerned, yet not be
writable by looking at _PAGE_RW.
Your suggestion not only should fix this, but is also the RightThing(tm)
to do.
It also explains why so few people saw this - PROT_NONE is not something
that is normally used.
> What are
> the implications for other architectures which organise their ptes
> differently?
Other architectures may have the same bug, but it's actually fairly
unlikely. Most other architectures tend to have a nicer way to do
PROT_NONE anyway, and the x86 thing is a hack (but a very nice hack,
because it leaves the mm layer completely unaware of the fact that the x86
page tables are fairly deficient in this area).
So it's not a conceptual problem, it might just be something that needs to
be looked at. Certainly the alpha does not have this problem.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
^ permalink raw reply [relevance 98%]
* Re: Progress! was: Re: Yet more VM writable swap-cached pages
[not found] <Pine.LNX.3.95.980710021356.10100A-100000@fishy>
@ 1998-07-10 1:26 93% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1998-07-10 1:26 UTC (permalink / raw)
To: ganesh.sittampalam
Cc: Stephen C. Tweedie, Virtual Memory problem report list, mingo,
Bill Hawes, Alan Cox, David S. Miller
On Fri, 10 Jul 1998, Ganesh Sittampalam wrote:
>
> Since this is now 100% reproducible on my system, I'd be happy to
> guinea-pig any fixes, however experimental.
Does this fix it dor you?
Linus
-----
diff -u --recursive --new-file v2.1.108/linux/include/asm-i386/pgtable.h linux/include/asm-i386/pgtable.h
--- v2.1.108/linux/include/asm-i386/pgtable.h Wed Jun 24 22:54:10 1998
+++ linux/include/asm-i386/pgtable.h Thu Jul 9 18:13:50 1998
@@ -225,6 +225,9 @@
#define _PAGE_4M 0x080 /* 4 MB page, Pentium+.. */
#define _PAGE_GLOBAL 0x100 /* Global TLB entry PPro+ */
+#define _PAGE_READABLE (_PAGE_PRESENT)
+#define _PAGE_WRITABLE (_PAGE_PRESENT | _PAGE_RW)
+
#define _PAGE_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED | _PAGE_DIRTY)
#define _KERNPG_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY)
@@ -330,21 +333,25 @@
* Undefined behaviour if not..
*/
extern inline int pte_read(pte_t pte) { return pte_val(pte) & _PAGE_USER; }
-extern inline int pte_write(pte_t pte) { return pte_val(pte) & _PAGE_RW; }
extern inline int pte_exec(pte_t pte) { return pte_val(pte) & _PAGE_USER; }
extern inline int pte_dirty(pte_t pte) { return pte_val(pte) & _PAGE_DIRTY; }
extern inline int pte_young(pte_t pte) { return pte_val(pte) & _PAGE_ACCESSED; }
-extern inline pte_t pte_wrprotect(pte_t pte) { pte_val(pte) &= ~_PAGE_RW; return pte; }
extern inline pte_t pte_rdprotect(pte_t pte) { pte_val(pte) &= ~_PAGE_USER; return pte; }
extern inline pte_t pte_exprotect(pte_t pte) { pte_val(pte) &= ~_PAGE_USER; return pte; }
extern inline pte_t pte_mkclean(pte_t pte) { pte_val(pte) &= ~_PAGE_DIRTY; return pte; }
extern inline pte_t pte_mkold(pte_t pte) { pte_val(pte) &= ~_PAGE_ACCESSED; return pte; }
-extern inline pte_t pte_mkwrite(pte_t pte) { pte_val(pte) |= _PAGE_RW; return pte; }
extern inline pte_t pte_mkread(pte_t pte) { pte_val(pte) |= _PAGE_USER; return pte; }
extern inline pte_t pte_mkexec(pte_t pte) { pte_val(pte) |= _PAGE_USER; return pte; }
extern inline pte_t pte_mkdirty(pte_t pte) { pte_val(pte) |= _PAGE_DIRTY; return pte; }
extern inline pte_t pte_mkyoung(pte_t pte) { pte_val(pte) |= _PAGE_ACCESSED; return pte; }
+
+/*
+ * These are harder, as writability is two bits, not one..
+ */
+extern inline int pte_write(pte_t pte) { return (pte_val(pte) & _PAGE_WRITABLE) == _PAGE_WRITABLE; }
+extern inline pte_t pte_wrprotect(pte_t pte) { pte_val(pte) &= ~((pte_val(pte) & _PAGE_PRESENT) << 1); return pte; }
+extern inline pte_t pte_mkwrite(pte_t pte) { pte_val(pte) |= _PAGE_RW; return pte; }
/*
* Conversion functions: convert a page and protection to a page entry,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
^ permalink raw reply [relevance 93%]
* Re: Progress! was: Re: Yet more VM writable swap-cached pages
@ 1998-07-10 2:18 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1998-07-10 2:18 UTC (permalink / raw)
To: Bill Hawes
Cc: ganesh.sittampalam, Stephen C. Tweedie,
Virtual Memory problem report list, mingo, Alan Cox,
David S. Miller
On Thu, 9 Jul 1998, Bill Hawes wrote:
>
> > +extern inline pte_t pte_mkwrite(pte_t pte) { pte_val(pte) |= _PAGE_RW; return pte; }
> ^^^^^^^^
> Did you mean to put in _PAGE_WRITABLE here, or can the pte_mkwrite macro always assume the
> PRESENT bit is already set?
I decided that it cannot matter. If somebody tries to make a PROT_NONE
page writable by using pte_mkwrite(), there is already a bug there, and
I'm happier keeping it PROT_NONE than I am to mark it present.
Note that this can not happen through a normal page fault, because a
normal page fault would have noticed that we don't actually have write
permission to the page at all. As such, the only way somebody can mark a
PROT_NONE page writable is if we're doing the nasty "bring in all the
pages because somebody did a mlock[all]() on us".
In which case the above does the right thing, by certainly bringing the
page in, but not actually allowing anybody to read/write to it (actually,
I don't think this can happen even in that case, because if we have
PROT_NONE then the make_pages_present() stuff will not try to bring it
into memory writably, so we won't even try to make it writable).
In short, the above really only makes sense if PRESENT is already set, and
if it was PROT_NONE from before it is a no-op which is fine.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
^ permalink raw reply [relevance 97%]
* Re: Progress! was: Re: Yet more VM writable swap-cached pages
@ 1998-07-20 17:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1998-07-20 17:01 UTC (permalink / raw)
To: Richard Henderson
Cc: Stephen C. Tweedie, ganesh.sittampalam,
Virtual Memory problem report list, mingo, Bill Hawes, Alan Cox,
David S. Miller
On Mon, 20 Jul 1998, Richard Henderson wrote:
> On Thu, Jul 09, 1998 at 05:54:21PM -0700, Linus Torvalds wrote:
> > It also explains why so few people saw this - PROT_NONE is not something
> > that is normally used.
>
> Actually, the glibc ld.so will create PROT_NONE regions if there is
> a hole between a shared library's text and data space. E.g.
>
> 20000110000-200001d6000 r-xp 00000000000 08:02 29407 /lib/libc-2.0.7.so
> 200001d6000-200002d0000 ---p 000000c6000 08:02 29407 /lib/libc-2.0.7.so
> 200002d0000-200002e6000 rwxp 000000c0000 08:02 29407 /lib/libc-2.0.7.so
Yes, but you won't have any actualy _pages_ mapped there.
The only way to get the pages there is to first map it with something else
than prot_none, touch some of the pages, and then do a mprotect() to make
them invisible again. I doubt glibc does that ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
^ permalink raw reply [relevance 99%]
* Re: PTRACE_POKEDATA on PROT_NONE hangs kernel
@ 1998-09-21 6:17 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1998-09-21 6:17 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: linux-kernel
On Sun, 20 Sep 1998, Michael Elizabeth Chastain wrote:
>
> First of all, if anyone else out there knows about the recent
> _PAGE_PROTNONE optimization, could you write to me please?
> I need to talk to you, if only for background information.
It's not an optimization. It's there to make things work. It essentially
has to be done that way due to the less than satisfactory intel page table
setup (there's no way to say "this page is present, but cannot be accessed
from user or kernel mode", we actuall yhave to turn off the present bit
and then use a separate bit (the _PAGE_PROTNONE bit) to keep track of the
fact that the page _is_ actually present.
> There are two pte tests in put_long:
>
> /* arch/i386/kernel/ptrace.c: put_long */
> pgtable = pte_offset(pgmiddle, addr);
> if (!pte_present(*pgtable)) {
> handle_mm_fault(tsk, vma, addr, 1);
> goto repeat;
> }
Right. The above pages it in if it isn't present. In this case, it does
nothing, because the page _is_ present (as far as the kernel is
concerned), it's just marked non-present as far as hardware is concerned
in order to get the right PROT_NONE permissions.
> page = pte_page(*pgtable);
> if (!pte_write(*pgtable)) {
> handle_mm_fault(tsk, vma, addr, 1);
> goto repeat;
> }
Ahhah. Ok, this is the buggy one. The problem is that we _should_ do a
"handle_mm_fault()" if it isn't writable, but we have no current knowledge
of that as is..
Ok, I have a simple fix, I think.
Fix for the above, take two:
- if (!pte_write(*pgtable)) {
+ if (!pte_dirty(*pgtable)) {
handle_mm_fault(tsk, vma, addr, 1);
goto repeat;
}
The above should correctly do the proper mm fault handling whenever the
page hasn't been written to before.
Does that finally fix it for you for all cases?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Re: entry.S mess with %ebx (¤t pointer)
@ 1998-11-19 18:01 97% ` Linus Torvalds
1998-11-19 18:08 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 1998-11-19 18:01 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: linux-kernel
On Thu, 19 Nov 1998, Andrea Arcangeli wrote:
>
> I am sure that the kernel run do_signal() from signal_return, even if
> sigpending is 0. This mean that %ebx got corrupted somewhere (and this
> explain very well also the need_resched flood I suspected some days ago).
> A patch for 2.1.128 that fix the UP hang fine here is this:
Good debugging, but the fix is incorrect (or at least unnecessarily slow).
I see where the problem is, and I also see why it _only_ happens on UP.
The problem is that the fork return point to the new process does not
initialize %ebx in the UP case.
It _does_ initialize it in the SMP case, and this is basically just an
oversight.
This patch should fix it properly, please tell me whether that is true..
Linus
-----
diff -u --recursive --new-file v2.1.129/linux/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S
--- v2.1.129/linux/arch/i386/kernel/entry.S Sun Nov 8 14:02:42 1998
+++ linux/arch/i386/kernel/entry.S Thu Nov 19 09:53:08 1998
@@ -150,14 +150,14 @@
jmp ret_from_sys_call
-#ifdef __SMP__
ALIGN
.globl ret_from_smpfork
-ret_from_smpfork:
+ret_from_fork:
GET_CURRENT(%ebx)
+#ifdef __SMP__
btrl $0, SYMBOL_NAME(scheduler_lock)
- jmp ret_from_sys_call
#endif /* __SMP__ */
+ jmp ret_from_sys_call
/*
* Return to user mode is not as complex as all this looks,
diff -u --recursive --new-file v2.1.129/linux/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
--- v2.1.129/linux/arch/i386/kernel/process.c Fri Oct 9 13:27:05 1998
+++ linux/arch/i386/kernel/process.c Thu Nov 19 09:53:35 1998
@@ -50,11 +50,7 @@
spinlock_t semaphore_wake_lock = SPIN_LOCK_UNLOCKED;
-#ifdef __SMP__
-asmlinkage void ret_from_fork(void) __asm__("ret_from_smpfork");
-#else
-asmlinkage void ret_from_fork(void) __asm__("ret_from_sys_call");
-#endif
+asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
#ifdef CONFIG_APM
extern int apm_do_idle(void);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Re: entry.S mess with %ebx (¤t pointer)
1998-11-19 18:01 97% ` Linus Torvalds
@ 1998-11-19 18:08 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1998-11-19 18:08 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: linux-kernel
On Thu, 19 Nov 1998, Linus Torvalds wrote:
>
> This patch should fix it properly, please tell me whether that is true..
Duh, the ".globl" declaration should also obviously be fixed to be
ret_from_fork rather than ret_from_smpfork in order for this to link..
Linus
-----
> diff -u --recursive --new-file v2.1.129/linux/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S
> --- v2.1.129/linux/arch/i386/kernel/entry.S Sun Nov 8 14:02:42 1998
> +++ linux/arch/i386/kernel/entry.S Thu Nov 19 09:53:08 1998
> @@ -150,14 +150,14 @@
> jmp ret_from_sys_call
>
>
> -#ifdef __SMP__
> ALIGN
> .globl ret_from_smpfork
^^^^^^^^^^^^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* pre-2.1.130-3
@ 1998-11-24 20:40 95% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1998-11-24 20:40 UTC (permalink / raw)
To: Kernel Mailing List
There's a new pre-patch for people who want to test these things out: I'll
probably make a real 2.1.130 soon just to make sure all the silly problems
in 2.1.129 are left behind (ie the UP flu in particular that people are
still discussing even though there's a known cure).
The pre-patch fixes a rather serious problem with wall-clock itimer
functions, that admittedly was very very hard to trigger in real life (the
only reason we found it was due to the diligent help from John Taves that
saw sporadic problems under some very specific circumstances - thanks
John).
It also fixes a very silly NFS path revalidation issue: when we
revalidated a cached NFS path component, we didn't update the revalidation
time, so we ended up doing a lookup over the wire every time after the
first time - essentially making the dcache useless for path component
caching of NFS. If you use NFS heavily, you _will_ notice this change (it
also fixes some rather ugly uses of dentries and inodes in the NFS code
where we didn't update the counter so the inode wasn't guaranteed to even
be there any more!).
Also, thanks to Richard Gooch &co, who found the rather nasty race
condition when a kernel thread was started from an init-region. The
trivial fix was to not have the kernel thread function be inlined, but
while fixing it was trivial, it wasn't trivial to notice in the first
place. Good debugging.
And the UP flu is obviously fixed here (as it was in earlier pre-patches
and in various other patches floating around).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: disk head scheduling
[not found] <Pine.LNX.3.95.990320224514.1123A-100000@localhost>
@ 1999-03-20 22:41 90% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-03-20 22:41 UTC (permalink / raw)
To: Gerard Roudier; +Cc: linux-kernel
On Sat, 20 Mar 1999, Gerard Roudier wrote:
>
> The kernel IO-request queue is one queue and a device TASK SET is also one
> queue, the SCSI sub-system passes requests between the kernel request
> queue and device queues.
The kernel IO-request queue is NOT one queue.
This is a common misunderstanding, and I'm really fed up with it.
The generic kernel low-level driver interface was designed to have
multiple requests queues, and the fact is that sadly the SCSI layer
doesn't understand this, so the SCSI layer uses just one queue.
The IDE driver is much better in this regard, for example. The IDE driver
uses one queue per controller, rather than one global queue. That means
that the generic code doesn't waste time trying to schedule requests for
different controllers, only schedule them on a per-controller basis.
There is indeed a global upper limit of total requests that the kernel
will queue up, but that's a separate issue or memory management, and is
actually just a single define.. It means that all IO requests are allocated
from the same pool of requests entries, but that does NOT MEAN, and has
NEVER MEANT that there is only one queue.
Sorry for shouting, but this is one of my major gripes with the SCSI
layer: it was just badly designed. And now that bad design means that
driver writers believe that the generic kernel is doing something stupid.
It isn't. It's the SCSI layer that is stupid, and it wouldn't have to be.
Just to give you an idea: right now the generic disk interface layer in
the kernel sees only one queue for all SCSI devices, which means that it
tries to sort all the requests according to that. That obviously fails: in
the presense of multiple disks, the sorting criteria just do not make all
that much sense.
So the generic layer spends time sorting the requests onto one queue,
doesn't do a good job because of that, and then the SCSI layer spends MORE
time unsorting the requests.
This means, for example, that while the kernel is making up a request for
one SCSI disk and has "plugged" the request queue in order to give just
one large requests to the disk, that "plug" will now plug all other SCSI
devices too - even though that wasn't the reason for doing the plugging.
With just one controller, this usually isn't a problem, but if you have
multiple controllers you can only blame the SCSI layer if it doesn't scale
up nicely.
This is one reason why people like Leonard decide to not use the SCSI
layer at all for their newer drivers.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 90%]
* Fake emails from "Linus"
@ 1999-07-19 7:31 99% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-07-19 7:31 UTC (permalink / raw)
To: Kernel Mailing List
Just a heads-up: somebody is sending out fake emails that claim to be from
me, and that have me endorsing the Java client for Seti@Home.
The reason I know somebody is faking emails is that I got a bounce from
one of them.
If somebody on the kernel list gets a message that claims to be from
"Linus Torvalds <torvalds@transmeta.com>" with a subject line of
"Seti@Home user interface", it is fake.
I'd like to see the full headers from such a message, to see if it shows
where it is really originating from: the bounced message does not contain
the original headers..
I assume it is a mass-posting trying to market Seti@Home or the particular
client in question, and I'm not all that amused.
Linus
PS. Although I have to admit that the first line brought a grin: "Being
the awesome Linux stud that I am.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: active_mm
[not found] <199907302050.NAA24558@napali.hpl.hp.com>
@ 1999-07-30 21:36 82% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-07-30 21:36 UTC (permalink / raw)
To: David Mosberger; +Cc: Kernel Mailing List
Cc'd to linux-kernel, because I don't write explanations all that often,
and when I do I feel better about more people reading them.
On Fri, 30 Jul 1999, David Mosberger wrote:
>
> Is there a brief description someplace on how "mm" vs. "active_mm" in
> the task_struct are supposed to be used? (My apologies if this was
> discussed on the mailing lists---I just returned from vacation and
> wasn't able to follow linux-kernel for a while).
Basically, the new setup is:
- we have "real address spaces" and "anonymous address spaces". The
difference is that an anonymous address space doesn't care about the
user-level page tables at all, so when we do a context switch into an
anonymous address space we just leave the previous address space
active.
The obvious use for a "anonymous address space" is any thread that
doesn't need any user mappings - all kernel threads basically fall into
this category, but even "real" threads can temporarily say that for
some amount of time they are not going to be interested in user space,
and that the scheduler might as well try to avoid wasting time on
switching the VM state around. Currently only the old-style bdflush
sync does that.
- "tsk->mm" points to the "real address space". For an anonymous process,
tsk->mm will be NULL, for the logical reason that an anonymous process
really doesn't _have_ a real address space at all.
- however, we obviously need to keep track of which address space we
"stole" for such an anonymous user. For that, we have "tsk->active_mm",
which shows what the currently active address space is.
The rule is that for a process with a real address space (ie tsk->mm is
non-NULL) the active_mm obviously always has to be the same as the real
one.
For a anonymous process, tsk->mm == NULL, and tsk->active_mm is the
"borrowed" mm while the anonymous process is running. When the
anonymous process gets scheduled away, the borrowed address space is
returned and cleared.
To support all that, the "struct mm_struct" now has two counters: a
"mm_users" counter that is how many "real address space users" there are,
and a "mm_count" counter that is the number of "lazy" users (ie anonymous
users) plus one if there are any real users.
Usually there is at least one real user, but it could be that the real
user exited on another CPU while a lazy user was still active, so you do
actually get cases where you have a address space that is _only_ used by
lazy users. That is often a short-lived state, because once that thread
gets scheduled away in favour of a real thread, the "zombie" mm gets
released because "mm_users" becomes zero.
Also, a new rule is that _nobody_ ever has "init_mm" as a real MM any
more. "init_mm" should be considered just a "lazy context when no other
context is available", and in fact it is mainly used just at bootup when
no real VM has yet been created. So code that used to check
if (current->mm == &init_mm)
should generally just do
if (!current->mm)
instead (which makes more sense anyway - the test is basically one of "do
we have a user context", and is generally done by the page fault handler
and things like that).
Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago,
because it slightly changes the interfaces to accomodate the alpha (who
would have thought it, but the alpha actually ends up having one of the
ugliest context switch codes - unlike the other architectures where the MM
and register state is separate, the alpha PALcode joins the two, and you
need to switch both together).
> Also, I saw reference to threads being "more soft". I'm not sure what
> this is referring to. Perhaps it's related to the changes on how
> segment registers are being managed on x86 now?
It's more a reaction to a (temporary and already removed) naming issue.
Ingo got rid of the 1:1 mapping of "hard" thread structures on the x86
side, so now we only have one TSS per CPU, and all the kernel thread
structures are completely independent of the CPU-imposed thread structure
on x86.
While Ingo was working on it, he called the kernel thread structure a
"soft_thread_struct", while the intel TSS structure was then called a
"hard_thread_struct". That was purely temporary and never saw the light of
day: the real names are "thread_struct" for the kernel thread structure,
and "tss_struct" for the intel TSS.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 82%]
* Re: More linker magic..
[not found] <19990804214327.A736@albireo.ucw.cz>
@ 1999-08-05 0:03 93% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-08-05 0:03 UTC (permalink / raw)
To: Martin Mares; +Cc: Andi Kleen, David Hinds, Pete Zaitcev, linux-kernel
Ok,
I was hoping that Martin would end up doing this, but as I'm forcing
myself to honour the feature freeze too, I decided I might as well forge
right ahead on the PCI resoruce issue because it will be needed for proper
PCMCIA integration.
pre-patch-2.3.13-5 does the proper resource allocation for all PCI cards;
instead of having the drivers do the resource building, the PCI layer
builds up the resource information automatically, and at least for the set
of drivers I was concerned about on my machine there wasn't even any need
to adjust the old compatibility stuff, but that will almost certainly be
needed for other sets of drivers (ie extending the resource flags with a
"BUSY" bit to mark resources as being exclusively used by some driver).
There are probably a number of broken PCI drivers, but they tend to be
fairly straightforward to fix, and often the fix cleans things up. For
example, there used to be a
pci_device->base_address[6]
array, where "base_address" wasn't really the base_address, it was really
the value in the PCI configuration space that is a mixture of base address
and flags. With the new scheme, there is
pci_device->resource[6]
where each resource has all the normal "start"/"end"/"flags" things, and
the fields actually do exactly what they say (so "flags" has the flags for
that region: IO vs Mem, 64-bit addressing etc, and "start" really is the
base address).
It also means that /proc/ioport and /proc/iomem actually show the full
population.
Broken non-updated drivers simply won't compile, but the fixes tend to be
rather straightforward. The less straightforward part is if some driver
tries to change the start offsets etc, which implies that he really has to
unregister the resource and re-register somewhere else. I don't know if
anybody actually does that, although I do know that there are drivers that
play some silly games with their resource list.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 93%]
* Re: irq.h changes in 2.3.14
@ 1999-08-19 17:45 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-08-19 17:45 UTC (permalink / raw)
To: Jes Sorensen; +Cc: x-linux-kernel
On Thu, 19 Aug 1999, Jes Sorensen wrote:
>
> I noticed the moving of arch/i386/kernel/irq.h to include/linux/irq.h in
> the 2.3.14 final patch.
>
> I really don't think it is a good idea to move this very i386 specific
> definitions in there since the interrupt subsystems on other
> architectures are very different from that of the i386.
The thing is, that the irq handling is _too_ different on different
architectures. A lot of the problems, especially the SMP issues, are
simply completely architecture-independent.
> Ie. on the m68k
> we do not use the same types or irq descriptors, the IRQ line statuses
> make no sense etc. and I am sure it is the same for some of the other
> non x86 architectures.
It is. And I _know_ that just about every architecture except for the x86
has bugs when it comes to SMP handling. Some, like the 68k, do not need to
care.
> I see that it expects asm/hw_irq.h to be the architecture dependant
> stuff, but even the things that made it into include/linux/irq.h are way
> to architecture specific.
There's absolutely nothing architecture-specific in <linux/irq.h>.
It may be _different_ than existing architectures, but I'll try to make
sure that future ports use the same correct irq handling, and I'll see if
I can port some of the existing stuff (notably alpha) to use the new
generic handling. It's actually very flexible - it pretty much has to be
in order to handle the different kinds of interrupt controllers that exist
on PC-like machines.
No architecture will be _forced_ to use the new stuff, so don't worry. But
I'll just warn you that you're likely to get the SMP stuff wrong if you
don't use it ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Linux-2.3.15..
[not found] <Pine.LNX.4.10.9908271831030.4003-100000@laser.random>
@ 1999-08-27 17:45 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-08-27 17:45 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Kernel Mailing List, David S. Miller, Richard Henderson
On Fri, 27 Aug 1999, Andrea Arcangeli wrote:
>
> I guess the problem is the pipe code since I understood the old semaphores
> completly and there weren't SMP races there.
Well, I certainly saw strange behaviour. The trylock code seemed to be the
prime culprit - it tried to decrement the "waking" count, but it could end
up doing it too late so that people had already seen a increment from a
concurrent "up()".
I'm not saying the new code is bug-free, but it works for me where the old
one did not - and your claim that it is obviously broken is also obviously
wrong, see later..
> Your new semaphores seems completly buggy to me and I am surprised your
> kernel works without crash or corruption with them.
Well, you're not counting right..
> task1 task2 task3 -> effect -> count sleepers
> ----- ----- ----- ----- --------
> 1 0
>
> ------- task 0 does a down() ------------------ 0 0
> ------- here task 1,2,3 try to get the lock ---
>
> down() -1 1
> (I avoided the details here)
> schedule()
> down() -2 1
> spin_lock()
> sleepers++ -2 2
> add_neg(1) -1??? 2
> sleepers = 1 -1 1
> schedule()
> down()
> spin_lock()
> sleepers++ -1 2
Wrong counting. The "down()" decremented count, so you have
-2 2
which is exactly right, and explains why there will _not_ be two users in
the critical region at the same time.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: architecture bootup changes..
@ 1999-10-21 3:35 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-10-21 3:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel
On Thu, 21 Oct 1999, Paul Mackerras wrote:
>
> There's a problem that doesn't show up on intel, and that is that
> flush_page_to_ram() is called with inconsistent arguments. Sometimes it's
> a struct page * (mm/filemap.c and mm/memory.c), in other cases it's a
> kernel virtual address (e.g. kernel/ptrace.c, include/linux/highmem.h).
>
> I'm inclined to think it should be a kernel virtual address. Comments?
Ho humm.. I would almost prefer the "struct page" because in theory you
might want to do it without mapping the page at all. But this is
definitely a case where most of the time it's only needed with virtual
caches, so at the same time a virtual address is not necessarily wrong
either.
So my preference would be a "struct page", but if you have a stronger
opinion you can override me with a little argumentation for show, ok?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: EISA i/o mem & ioremap vs isa_memcpy
[not found] <3821F95D.60EC8B0C@yahoo.com>
@ 1999-11-05 18:04 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1999-11-05 18:04 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-kernel list
On Thu, 4 Nov 1999, Paul Gortmaker wrote:
>
> My question is: Does adding the isa_ prefix to the memcpy (and readb &
> friends) make sense for these EISA cases or should I just do the ioremap()
> unconditionally and not use the isa_ prefix. I tend to prefer the latter.
Just do the ioremap() unconditionally.
Note that the isa_xxxx() functions are for old drivers that do NOT know
about ioremap(), and think that the ISA space is always mapped. Think of
it as a band-aid for stupid drivers, making it easier to bring them up to
working order. But the "ioremap()" approach is always the right one.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Linux 2000(tm)(r)
@ 2000-04-01 0:00 78% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-04-01 0:00 UTC (permalink / raw)
To: linux-kernel
Dear Linux Users,
I'm pleased to announce jointly with Microsoft(tm)(r) Corporation
release of Linux 2000 Professional Enterprise.
As you probably already know I'm busy with my family and I already
have full-time job with Transmeta. Thus, it has been necessary for me to
look for some responsible partner who would help me develop Linux.
After extensive search, I have decided upon Microsoft Corporation
which has been known on market for long time from their high quality
software.
Thus the upcoming Linux 2.4.0 will become Linux 2000(tm)(r).
Pricing will be determined at later time. However, I would like to
take opportunity now to remind people who have unlicensed version of Linux
to delete it from hard disk and then wait until official release of Linux
2000(tm)(r) will become available.
Effective April 1st 2000, midnight, all older versions of Linux
are illegal under Digital Millennium Copyright Act.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 78%]
* Re: error in arch/i386/kernel/ptrace.c (subtle)
@ 2000-09-02 19:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-09-02 19:01 UTC (permalink / raw)
To: linux-kernel
In article <20000902155021.51C9E4917@pornstar.not.very.secure.org>,
Silvio Cesare <silvio@big.net.au> wrote:
>
>My fix would be to change orig_eax to -1 if the eip register is modified.
>Thus the signal handling code wouldnt think it needed to restart any syscalls.
>This is untested code btw.
Looks like a good fix to me..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test10-pre1
@ 2000-10-09 22:28 98% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-09 22:28 UTC (permalink / raw)
To: Kernel Mailing List
Largely VM balancing and OOM things (get rid of the VM livelock that
existed in test9), and USB fixes.
And a number of random driver fixes (SMP locking on network drivers, what
not).
Linus
-----
- pre1:
- Roger Larsson: ">=" instead of ">" to make the VM not get stuck.
- Gideon Glass: brw_kiovec() failure case oops fix
- Rik van Riel: better memory balancing and OOM killer
- Ivan Kokshaysky: alpha compile fixes
- Vojtech Pavlik: forgotten ENOUGH macro in via82cxxx ide driver
- Arnaldo Carvalho de Melo: acpi resource leak fix
- Brian Gerst: use mov's instead of xchg in kernel trap entry
- Torben Mathiasen: tlan timer being added twice bug
- Andrzej Krzysztofowicz: config file fixes
- Jean Tourrilhes: Wavelan lockup on SMP fix
- Roman Zippel: initdata must be initialized (even if it is to zero:
gcc is strange)
- Jean Tourrilhes: hp100 driver lockup at startup on SMP
- Russell King: fix silly minixfs uninitialized error bug
- (various): fix uid hashing to use "uid_t" instead of "unsigned short"
- Jaroslav Kysela: isapnp timeout fix. NULL ptr dereference fix.
- Alain Knaff: fdformat should work again.
- Randy Dunlap: USB - fix bluetooth, acm, printer, serial to work
with urb->dev changes.
- Randy Dunlap: USB whiteheat serial driver firmware update.
- Randy Dunlap: USB hub memory corruption and pegasus driver update
- Andre Hedrick: IDE Makefile cleanup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 98%]
* Re: [PATCH] Clean up x86 write-protect test
[not found] <39E7AA78.B6E5D6D@didntduck.org>
@ 2000-10-14 1:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-14 1:47 UTC (permalink / raw)
To: Brian Gerst; +Cc: Linux kernel mailing list
On Fri, 13 Oct 2000, Brian Gerst wrote:
>
> Also, Could somebody who has a machine with a known buggy processor give
> this patch a try?
I like the patch. Would you mind re-writing the exception handling the
other way around, though:
Instead of doing it like this:
+ __asm__ __volatile__(
+ " movb %0,%1 \n"
+ "1: movb %1,%0 \n"
+ " jmp 3f \n"
+ "2: incl %2 \n"
+ "3: \n"
+ ".section __ex_table,\"a\"\n"
+ " .align 4 \n"
+ " .long 1b,2b \n"
+ ".previous \n"
+:"=m" (*(char *) vaddr),
+ "=q" (tmp_reg),
+ "=r" (flag)
+:"2" (flag)
+:"memory");
it would be nicer to simply to the other way around (if exception happens,
"flag" is untouched and jumped over, if not, flag is cleared):
+ __asm__ __volatile__(
+ " movb %0,%1 \n"
+ "1: movb %1,%0 \n"
+ " xor %2,%2 \n"
+ "2: \n"
+ ".section __ex_table,\"a\"\n"
+ " .align 4 \n"
+ " .long 1b,2b \n"
+ ".previous \n"
+:"=m" (*(char *) vaddr),
+ "=q" (tmp_reg),
+ "=r" (flag)
+:"2" (1)
+:"memory");
which basically means that if flag stays as "1", then the exception
happened, but if the exception didn't happen the code will fall through
the "xor" and clear "flag".
After that, and testing that it works on a broken machine, I'd love to
apply it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Linux's implementation of poll() not scalable?
@ 2000-10-26 16:44 94% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-26 16:44 UTC (permalink / raw)
To: Dan Kegel; +Cc: Eric W. Biederman, Helge Hafting, linux-kernel
On Thu, 26 Oct 2000, Dan Kegel wrote:
>
> With level-triggered interfaces like poll(), your chances
> of writing a correctly functioning program are higher because you
> can throw events away (on purpose or accidentally) with no consequences;
> the next time around the loop, poll() will happily tell you the current
> state of all the fd's.
Agreed.
However, we also need to remember what got us to this discussion in the
first place. One of the reasons why poll() is such a piggy interface is
exactly because it tries to be "nice" to the programmer.
I'd much rather have an event interface that is documented to be edge-
triggered and is really _lightweight_, than have another interface that
starts out with some piggy features.
I do understand that level to some degree is "nicer", but everybody pretty
much agrees that apart from requireing more care, edge-triggered certainly
does everything the level-triggered interfaces do.
For example, if you want to only partially handle an event (one of the
more valid arguments I've seen, although I do not agree with it actually
being all that common or important thing to do), the edge-triggered
interface _does_ allow for that. It's fairly easy, in fact: you just
re-bind the thing.
(My suggested "bind()" interface would be to just always add a newly bound
fd to the event queue, but I would not object to a "one-time test for
active" kind of "bind()" interface either - which would basically allow
for a poll() interface - and the existing Linux internal "poll()"
implementation actually already allows for exactly this so it wouldn't
even add any complexity).
> With edge-triggered interfaces, the programmer must be much more careful
> to avoid ever dropping a single event; if he does, he's screwed.
> This gives rise to complicated code in apps to remember the current
> state of fd's in those cases where the programmer has to drop events.
No, the "re-bind()" approach works very simply, and means that the
overhead of testing whether the event is still active is not a generic
thing that _always_ has to be done, but something where the application
can basically give the kernel the information that "this time we're
leaving the event possibly half-done, please re-test now".
Advantage: performance again. The common case doesn't take the performance
hit.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 94%]
* Re: PATCH: killing read_ahead[]
[not found] <Pine.GSO.4.21.0010251435100.12098-100000@weyl.math.psu.edu>
@ 2000-10-26 20:44 98% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-26 20:44 UTC (permalink / raw)
To: Alexander Viro; +Cc: Rik van Riel, Jeff Garzik, Martin Dalecki, linux-kernel
On Wed, 25 Oct 2000, Alexander Viro wrote:
>
> Linus, what do you think about that? I can do the remaining filesystems
> and give it initial testing today.
Ok, looks reasonable, if not really pretty. I'd probably prefer
last_page = size >> PAGE_CACHE_SIZE;
last_page_size = size & (PAGE_CACHE_SIZE-1);
and then the three cases would be
if (index < last_page) {
full page case - ok.
}
if (index > last_page || !last_page_size) {
bad case, past the end
}
partial_page.
I see why you did it the way you did, but while it makes it really cheap
to test for "index past the end", it makes for less obvious calculations
in other places, I feel.
The alternative is to have an entirely different approach, where the page
cache itself only knows about the maximum page (in which case your current
"last_page" calculation is right on), and then anybody who needs to know
about partial pages needs to get THAT information from the inode.
I'd almost prefer the alternative approach. Especially as right now the
only real problem we're fighting is to make sure we never return an
invalid page - the sub-page offset really doesn't matter for those things,
and everybody who cares about the sub-page-information already obviously
has it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 98%]
* Re: missing mxcsr initialization
@ 2000-10-27 5:35 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-27 5:35 UTC (permalink / raw)
To: Alan Cox
Cc: Andrea Arcangeli, Doug Ledford, Gabriel Paubert, mingo, gareth,
linux-kernel
On Fri, 27 Oct 2000, Alan Cox wrote:
> > bitmap is all about, and should be forced to go back to the bad old times
> > when you had to check the stepping levels etc to figure out what the CPU's
> > could do.
>
> You still do. In fact your example SEP specifically requires this due to
> Intel specification changes in the undocumented=->documented versions
NO.
Go back. Read ym email. Realize that you do this ONCE. At setup time.
You can even split SEP into SEPOLD and SEPNEW, and _always_ just test one
bit. You should not have to test stepping levels in normal use: that
invariably causes problems when there are more than one CPU that has some
feature.
It is insidious. It starts out as something simple like
if (stepping < 5) {
...
}
and everybody thinks it is cool. Until somebody notices that it should be
if (vendor == intel && stepping < 5) {
...
}
and it appears to work again, until it turns out that Cyrix has the same
issue, and then it ends up being the test from hell, where different
vendor tests all clash, and it gets increasingly difficult to add a new
thing later on sanely.
In contrast, having the test be
if (feature & SEPNEW) {
...
}
your test is simplified, easier to read and understand, AND it is much
easier to account for different vendors who have different stepping levels
etc. Especially as some vendors need setup code for the thing to work at
all, so it's not even stepping levels, it's stepping levels PLUS some
certain magic sequence that must have been done to initialize the thing.
No thank you. We'll just require fixed feature flags. Which can be turned
on as the features are enabled.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* test10-pre6
@ 2000-10-27 6:58 70% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-27 6:58 UTC (permalink / raw)
To: Kernel Mailing List
Thanks to everybody who has been testing.
pre6 has tons of small fixes, the most noticeable of which are
(a) the new compiler requirements (sorry, but it turned out that 2.7.2.3
really is too subtly broken with named structure initializers that
are very heavily used these days inside the kernel)
Suggested stable compiler: gcc-2.91.66, aka egcs-1.1.2, which is the
one most vendors have been shipping for a long time, and while sure
to be buggy too has not been found to be seriously so at least yet.
Other modern gcc versions may well work too.
(b) various PCI fixes that used to make 2.4.0 completely unboot/usable on
certain machines (ALI chipsets with certain PIRQ routing tables and
laptops with some docking bridges. Oh, and PIIX4 chipsets with USB
enabled and certain other magic things going on).
Let's hope that there aren't too many more of these. The ALI one in
particular was "interesting" to chase down. More interesting than I
personally need in my old age.
The rest of the changes should be mostly unnoticeable.
Still known: the same old "page->mapping = NULL" thing that has not seen
an acceptable fix yet. If it wasn't for that, I'd have called this test10
already and be done with it. Super-Al to the rescue (and no, that was not
a reference to the current sad state of US politics).
Linus
-----
- pre6:
- Jeremy Fitzhardinge: autofs4 expiry fix
- David Miller: sparc driver updates, networking updates
- Mathieu Chouquet-Stringer: buffer overflow in sg_proc_dressz_write
- Ingo Molnar: wakeup race fix (admittedly the window was basically
non-existent, but still..)
- Rasmus Andersen: notice that "this_slice" is no longer used for
scheduling - delete the code that calculates it.
- ALI pirq routing update. It's even uglier than we initially thought..
- Dimitrios Michailidis: fix ipip locking bugs
- Various: face it - gcc-2.7.2.3 miscompiles structure initializers.
- Paul Cassella: locking comments on dev_base
- Trond Myklebust: NFS locking atomicity. refresh inode properly.
- Andre Hedrick: Serverworks Chipset driver, IDE-tape fix
- Paul Gortmaker: kill unused code from 8390 support.
- Andrea Arcangeli: fix nfsv3d wrong truncates over 4G
- Maciej W. Rozycki: PIIX4 needs the same USB quirk handling as PIIX3.
- me: if we cannot figure out the PCI bridge windows, just "inherit"
the window from the parent. Better than not booting.
- Ching-Ling Lee: ALI 5451 Audio core support update
- pre5:
- Mikael Pettersson: more Pentium IV cleanup.
- David Miller: non-x86 platforms missed "pte_same()".
- Russell King: NFS invalidate_inode_pages() can do bad things!
- Randy Dunlap: usb-core.c is gone - module fix
- Ben LaHaise: swapcache fixups for the new atomic pte update code
- Oleg Drokin: fix nm256_audio memory region confusion
- Randy Dunlap: USB printer fixes
- David Miller: sparc updates
- David Miller: off-by-one error in /proc socket dumper
- David Miller: restore non-local bind() behaviour.
- David Miller: wakeups on socket shutdown()
- Jeff Garzik: DEPCA net drvr fixes and CodingStyle
- Jeff Garzik: netsemi net drvr fix
- Jeff Garzik & Andrea Arkangeli: keyboard cleanup
- Jeff Garzik: VIA audio update
- Andrea Arkangeli: mxcsr initialization cleanup and fix
- Gabriel Paubert: better twd_i387_to_fxsr() emulation
- Andries Brouwer: proper error return in ext2 mkdir()
- pre4:
- disable writing to /proc/xxx/mem. Sure, it works now, but it's still
a security risk.
- IDE driver update (Victroy66 SouthBridge support)
- i810 rng driver cleanup
- fix sbus Makefile
- named initializers in module..
- ppoe: remove explicit initializer - it's done with initcalls.
- x86 WP bit detection: do it cleanly with exception handling
- Arnaldo Carvalho de Melo: memory leaks in drivers/media/video
- Bartlomiej Zolnierkiewicz: video init functions get __init
- David Miller: get rid of net/protocols.c - they get to initialize themselves
- David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway.
- Geert Uytterhoeven: Zorro (Amiga) bus support update
- David Miller: work around gcc-2.7.2 bug
- Geert Uytterhoeven: mark struct consw's "const".
- Jeff Garzik: network driver cleanups, ns558 joystick driver oops fix
- Tigran Aivazian: clean up __alloc_pages(), kill_super() and
notify_change()
- Tigran Aivazian: move stuff from .data to .bss
- Jeff Garzik: divert.h typename cleanups
- James Simmons: mdacon using spinlocks
- Tigran Aivazian: fix BFS free block calculation
- David Miller: sparc32 works again
- Bernd Schmidt: fix undefined C code (set/use without a sequence point)
- Mikael Pettersson: nicer Pentium IV setup handling.
- Georg Acher: usb-uhci cpia oops fix
- Kanoj Sarcar: more node_data cleanups for [non]NUMA.
- Richard Henderson: alpha update to new vmalloc setup
- Ben LaHaise: atomic pte updates (don't lose dirty bit)
- David Brownell: ohci memory debugging (== use separate slabs for allocation)
- pre3:
- update email address of Joerg Reuter
- Andries Brouwer: spelling fixes, missing atari brelse(), breada() fix
- Geert Uytterhoeven: used named initializers for "struct console".
- Carsten Paeth: ISDN capifs - iput() only once.
- Petr Vandrovec: VFAT short name generation fix
- Jeff Garzik: i810_rng cleanup, and i815 chipset added.
- Bartlomiej Zolnierkiewicz: clean up some remaining old-style Makefiles
- Dave Jones: x86 setup fixes (recognize Pentium IV etc).
- x86: do the "fast A20" setup too in setup.S
- NIIBE Yutaka: update SuperH for the global page table (vmalloc) change.
- David Miller: sparc updates (vmalloc stuff still pending)
- David Miller: CodaFS warnings and 64-bit warnings in pci_size()
- David Miller: pcnet32 - correct NULL test
- David Miller: vmlist lock -> page_table_lock clarification
- Trond Myklebust: Ouch. rpcauth_lookup_credcache() memory corruption bug
- Matthew Wilcox: file locking cleanups
- David Woodhouse: USB audio spinlock fixes
- Torben Mathiasen: tlan driver cleanups
- Randy Dunlap: Yenta: CACHE_LINE_SIZE is in dwords, not bytes.
- Randy Dunlap: more USB updates
- Kanoj Sarcar: clean up the NUMA interfaces (pg_data instead of nodes)
- "save_fpu()" was broken. Need to clear pending errors: save_init_fpu().
- pre2:
- remember to change the kernel version ;)
- isapnp.txt bugfix
- ia64 update
- sparc update
- networking update (pppoe init, frame diverter, fix tcp_sendmsg,
fix udp_recvmsg).
- Compile for WinChip must _not_ use "-march=i686". It's a i586.
- Randy Dunlap: more USB updates
- clarify the Firewire AIC-5800 situation. It's not supported yet.
- PCI-space decode size fix. This is needed for some (broken?) hardware
- /proc/self/maps off-by-one error
- 3c501, 3c507, cs89x0 network drivers drop unnecessary check_region
- Asahi Kasei AK4540: new codec ID. Yamaha: new PCI ID's.
- ne2k-pci net driver documentation update
- Paul Gortmaker: delete paranoia check in rtc_exit
- scsi_merge: memset the right amount of memory.
- sun3fb: old __initfunc() not supported any more.
- synclink: remove unnecessary task state games
- xd.c: proper casting for 64-bit architectures
- vmalloc: page table update race condition.
- pre1:
- Roger Larsson: ">=" instead of ">" to make the VM not get stuck.
- Gideon Glass: brw_kiovec() failure case oops fix
- Rik van Riel: better memory balancing and OOM killer
- Ivan Kokshaysky: alpha compile fixes
- Vojtech Pavlik: forgotten ENOUGH macro in via82cxxx ide driver
- Arnaldo Carvalho de Melo: acpi resource leak fix
- Brian Gerst: use mov's instead of xchg in kernel trap entry
- Torben Mathiasen: tlan timer being added twice bug
- Andrzej Krzysztofowicz: config file fixes
- Jean Tourrilhes: Wavelan lockup on SMP fix
- Roman Zippel: initdata must be initialized (even if it is to zero:
gcc is strange)
- Jean Tourrilhes: hp100 driver lockup at startup on SMP
- Russell King: fix silly minixfs uninitialized error bug
- (various): fix uid hashing to use "uid_t" instead of "unsigned short"
- Jaroslav Kysela: isapnp timeout fix. NULL ptr dereference fix.
- Alain Knaff: fdformat should work again.
- Randy Dunlap: USB - fix bluetooth, acm, printer, serial to work
with urb->dev changes.
- Randy Dunlap: USB whiteheat serial driver firmware update.
- Randy Dunlap: USB hub memory corruption and pegasus driver update
- Andre Hedrick: IDE Makefile cleanup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 70%]
* Re: Full preemption issues
@ 2000-10-27 17:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-27 17:47 UTC (permalink / raw)
To: George Anzinger; +Cc: linux-kernel@vger.redhat.com, Nigel Gamble
On Fri, 27 Oct 2000, George Anzinger wrote:
>
> First, as you know, we have added code to the spinlock macros to count
> up and down a preemption lock counter. We would like to not do this if
> the macro also turns off local interrupts. The issue here is that in
> some places in the code, spin_lock_irq() or spin_lock_irqsave() is
> called but spin_unlock_irq() or spin_lock_irqrestore() is not. This, of
> course, confuses the preemption count. Attached is a patch that
> addresses this issue. At this time we are not asking you to apply this
> patch, but to indicate if we are moving in an acceptable direction.
Looks entirely sane to me.
> The second issue resolves around the naming conventions used in the
> kernel. We want to extend this work to include the SMP kernel, but to
> do this we need to have several levels of names for the spinlock
> macros. We note that the kernel uses "_" and "__" prefixes in some
> macros, but can not, by inspection, figure out when to uses these
> prefixes. Could you explain this convention or is this wisdom written
> somewhere?
The "wisdom" is not written down anywhere, and is more a convention than
anything else. The convention is that a prepended "__" means that "this is
an internal routine, and you can use it, but you should damn well know
what you're doing if you do". For example, the most common use is for
routines that need external locking - the version that does its own
locking and is thus "safe" to use in normal circumstances has the regular
name, and the version of the routine that does no locking and depends on
the caller to lock for it has the "__" version.
Your proto code does not break this convention in any way..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: page->mapping == 0
@ 2000-10-29 18:05 94% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-29 18:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel
On Sun, 29 Oct 2000, Paul Mackerras wrote:
>
> I have tracked down why I am getting the oops with page->mapping == 0
> in block_read_full_page. Well, at least if not the ultimate cause,
> then the penultimate cause. It's basically yet another truncate bug
> (tm). I have some fairly detailed traces which I can send you if you
> like, but the executive summary is that a page can get truncated out
> from under us while we are sleeping in lock_page. The scenario I
> observed is this:
Sorry, maybe our discussions with Al Viro weren't public, but yes, we did
come to the same conclusion a few days ago.
The only problem right now is deciding how to fix it - because as you
rightly point out, this actually happens in a number of places, and as
such it's not trivial to fix it cleanly. We may have to use a brute-force
approach for 2.4.x where we just re-test against the file size in multiple
places where this can happen - but it would be nicer to handle this more
cleanly.
There are a few details that still elude me, the main one being the big
question about why this started happening to so many people just recently.
The bug is not new, and yet it's become obvious only in the last few
weeks.
I _hope_ that the reason for this is that more people are testing out
2.4.x, and that we've fixed most of the other issues that kept people back
from using it. It may be as simple as that. But I wonder if there is
something else going on too, like the read-ahead being buggy, and that
causing the bug to just happen a lot more (if read-ahead is buggy and
tries to read ahead past the end of the file, a truncate() will be much
more likely to hit these pages past the end, for example. Because most
cases of "truncate" are actually about truncating _upwards_, not
downwards).
So the two worries I have now is (a) the details on how to fix this thing
(minor worry, mainly one of aesthetics) and (b) whether there is something
else going on that brings it out of the woodworks..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 94%]
* Re: page->mapping == 0
@ 2000-10-29 19:12 93% ` Linus Torvalds
2000-10-29 19:33 91% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2000-10-29 19:12 UTC (permalink / raw)
To: Alexander Viro; +Cc: Paul Mackerras, linux-kernel
On Sun, 29 Oct 2000, Alexander Viro wrote:
>
> One possible way is to access page->mapping _only_ under the page lock
> and in cases when we call ->i_mapping->a_ops->foo check the ->mapping
> before the method call.
I'm leaning towards this for a 2.4.x solution.
As far as I can tell, page->mapping is _already_ only accessed and
modified with the page lock held. It's just that we don't test it for
NULL, in case an earlier lock holder decided to clear it.
(No, I didn't look through all the users, but at least conceptually it
_should_ be true that we only look at "mapping" with the lock held: it's
mainly used for pagein, and pageout, buth with the lock held for other
reasons already. Certainly all the places where we have had bug-reports
have been of this type).
Making it policy that we have to re-test page->mapping after aquireing the
page lock might be the simplest fix for 2.4.x. It still means that we
might end up allowing people to have a "bad" page in the VM space due to
the "test->insert" race condition, but it woul dmake that event pretty
much a harmless bug (and thus move it to the "beauty wart - to be fixed
later" category).
And the places where we get the page lock and use page->mapping are not
that many, I think.
(And notice how we actually _have_ this approach already in
do_buffer_fdatasync(), for similar reasons - we use the "re-test the
page->buffers" thing there. Of course, there we do it because the clearing
of page->buffers is easier to see, and can happen as a result of memory
pressure, and not just truncate()).
So, for example, in __find_lock_page() we should re-test the mapping after
we aquired the page lock. Which is fairly easy, just add something like
/* Race: did the mapping go away before we got the page lock? */
if (page && page->mapping != mapping) {
page_cache_release(page);
goto repeat;
}
to the end of __find_lock_page(). Add similar logic to
do_generic_file_read(), filemap_nopage() and filemap_sync_pte() and
read_cache_page(), and you're pretty much done.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 93%]
* Re: page->mapping == 0
2000-10-29 19:12 93% ` Linus Torvalds
@ 2000-10-29 19:33 91% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-29 19:33 UTC (permalink / raw)
To: Alexander Viro; +Cc: Paul Mackerras, linux-kernel
On Sun, 29 Oct 2000, Linus Torvalds wrote:
>
> Making it policy that we have to re-test page->mapping after aquireing the
> page lock might be the simplest fix for 2.4.x. It still means that we
> might end up allowing people to have a "bad" page in the VM space due to
> the "test->insert" race condition, but it woul dmake that event pretty
> much a harmless bug (and thus move it to the "beauty wart - to be fixed
> later" category).
I'd like to just re-iterate this point: re-testing "page->mapping" fixes
the oops, but is not a full fix for the conceptual problem.
The problem with just re-testing "page->mapping" is that you still have a
nasty potential race where you insert a (bogus) page into the VM space of
a process instead of giving a SIGBUS/SIGSEGV.
Now, I don't think this is really a valid usage pattern, so it's most
likely to be a result of a buggy application, but I can imagine having
some strange kind of user-space VM memory management scheme that depends
on SIGBUS to maintain a file length. I've never heard of such a thing, but
I could imagine somebody doing some kind of persistent data object store
in user space this way.
Does anybody actually know of an application that does something like
this? Because I'm more and more inclined to just going with the half-fix
for now. It would at least guarantee internal kernel data consistency (and
no oopses, of course).
Don't get me wrong - we need to clean this part up, but as far as I can
tell we have never done this "right", so in that sense it's not a new
2.4.x bug and it can't break existing applications.
[ In fact, with the current ordering inside "vmtruncate()" of doing the
"truncate_inode_pages()" thing before doing the "vmtruncate_list()", I
have this suspicion that the race might even be impossible to trigger.
Even when the race "happens" in kernel space, we will end up unmapping
the page immediately afterwards, and the only effect as far as the user
is concerned is the disappearance of the SIGBUS.
And the "disappearing SIGBUS" is actually explainable with a
_user_level_ race: in order to get the kernel race at all, user level
itself must have been inherently racing on the truncate/access, and
depending on which one happened "first" you'd have lost the SIGBUS and
the data you wrote anyway.
So it may actually be that we can honestly claim that the half-fix is
actually a proper fix. I would have to look a lot closer at the issue to
be able to guarantee this, though. Comments? Anybody? ]
Al?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 91%]
* test10-pre7
@ 2000-10-30 19:32 71% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 19:32 UTC (permalink / raw)
To: Kernel Mailing List
Ok, this one contains at least a preliminary fix for the problem with
truncate together with a concurrent page access - the bug that causes
oopses in block_read_full_page() and filemap_nopage().
This is a fairly minimal fix, and I'll still have to verify that I caught
all the relevant places, but I wanted people who have seen this problem to
please test this out asap - I'll make a real test10 later once I've
integrated some further patches from Alan and Jeff, but this should fix
the major show-stopper bug.
Thanks,
Linus
----
- pre7:
- Niels Jensen: remove no-longer-needed workarounds for old gcc versions
- Ingo Molnar & Rik v Riel: VM inactive list maintenance correction
- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
memory leak fixes
- David Miller: networking updates
- David Mosberger: add AT_CLKTCK to elf information. And make AT_PAGESZ work
for static binaries too.
- oops. pcmcia broke by mistake
- Me: truncate vs page access race fix.
- pre6:
- Jeremy Fitzhardinge: autofs4 expiry fix
- David Miller: sparc driver updates, networking updates
- Mathieu Chouquet-Stringer: buffer overflow in sg_proc_dressz_write
- Ingo Molnar: wakeup race fix (admittedly the window was basically
non-existent, but still..)
- Rasmus Andersen: notice that "this_slice" is no longer used for
scheduling - delete the code that calculates it.
- ALI pirq routing update. It's even uglier than we initially thought..
- Dimitrios Michailidis: fix ipip locking bugs
- Various: face it - gcc-2.7.2.3 miscompiles structure initializers.
- Paul Cassella: locking comments on dev_base
- Trond Myklebust: NFS locking atomicity. refresh inode properly.
- Andre Hedrick: Serverworks Chipset driver, IDE-tape fix
- Paul Gortmaker: kill unused code from 8390 support.
- Andrea Arcangeli: fix nfsv3d wrong truncates over 4G
- Maciej W. Rozycki: PIIX4 needs the same USB quirk handling as PIIX3.
- me: if we cannot figure out the PCI bridge windows, just "inherit"
the window from the parent. Better than not booting.
- Ching-Ling Lee: ALI 5451 Audio core support update
- pre5:
- Mikael Pettersson: more Pentium IV cleanup.
- David Miller: non-x86 platforms missed "pte_same()".
- Russell King: NFS invalidate_inode_pages() can do bad things!
- Randy Dunlap: usb-core.c is gone - module fix
- Ben LaHaise: swapcache fixups for the new atomic pte update code
- Oleg Drokin: fix nm256_audio memory region confusion
- Randy Dunlap: USB printer fixes
- David Miller: sparc updates
- David Miller: off-by-one error in /proc socket dumper
- David Miller: restore non-local bind() behaviour.
- David Miller: wakeups on socket shutdown()
- Jeff Garzik: DEPCA net drvr fixes and CodingStyle
- Jeff Garzik: netsemi net drvr fix
- Jeff Garzik & Andrea Arkangeli: keyboard cleanup
- Jeff Garzik: VIA audio update
- Andrea Arkangeli: mxcsr initialization cleanup and fix
- Gabriel Paubert: better twd_i387_to_fxsr() emulation
- Andries Brouwer: proper error return in ext2 mkdir()
- pre4:
- disable writing to /proc/xxx/mem. Sure, it works now, but it's still
a security risk.
- IDE driver update (Victroy66 SouthBridge support)
- i810 rng driver cleanup
- fix sbus Makefile
- named initializers in module..
- ppoe: remove explicit initializer - it's done with initcalls.
- x86 WP bit detection: do it cleanly with exception handling
- Arnaldo Carvalho de Melo: memory leaks in drivers/media/video
- Bartlomiej Zolnierkiewicz: video init functions get __init
- David Miller: get rid of net/protocols.c - they get to initialize themselves
- David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway.
- Geert Uytterhoeven: Zorro (Amiga) bus support update
- David Miller: work around gcc-2.7.2 bug
- Geert Uytterhoeven: mark struct consw's "const".
- Jeff Garzik: network driver cleanups, ns558 joystick driver oops fix
- Tigran Aivazian: clean up __alloc_pages(), kill_super() and
notify_change()
- Tigran Aivazian: move stuff from .data to .bss
- Jeff Garzik: divert.h typename cleanups
- James Simmons: mdacon using spinlocks
- Tigran Aivazian: fix BFS free block calculation
- David Miller: sparc32 works again
- Bernd Schmidt: fix undefined C code (set/use without a sequence point)
- Mikael Pettersson: nicer Pentium IV setup handling.
- Georg Acher: usb-uhci cpia oops fix
- Kanoj Sarcar: more node_data cleanups for [non]NUMA.
- Richard Henderson: alpha update to new vmalloc setup
- Ben LaHaise: atomic pte updates (don't lose dirty bit)
- David Brownell: ohci memory debugging (== use separate slabs for allocation)
- pre3:
- update email address of Joerg Reuter
- Andries Brouwer: spelling fixes, missing atari brelse(), breada() fix
- Geert Uytterhoeven: used named initializers for "struct console".
- Carsten Paeth: ISDN capifs - iput() only once.
- Petr Vandrovec: VFAT short name generation fix
- Jeff Garzik: i810_rng cleanup, and i815 chipset added.
- Bartlomiej Zolnierkiewicz: clean up some remaining old-style Makefiles
- Dave Jones: x86 setup fixes (recognize Pentium IV etc).
- x86: do the "fast A20" setup too in setup.S
- NIIBE Yutaka: update SuperH for the global page table (vmalloc) change.
- David Miller: sparc updates (vmalloc stuff still pending)
- David Miller: CodaFS warnings and 64-bit warnings in pci_size()
- David Miller: pcnet32 - correct NULL test
- David Miller: vmlist lock -> page_table_lock clarification
- Trond Myklebust: Ouch. rpcauth_lookup_credcache() memory corruption bug
- Matthew Wilcox: file locking cleanups
- David Woodhouse: USB audio spinlock fixes
- Torben Mathiasen: tlan driver cleanups
- Randy Dunlap: Yenta: CACHE_LINE_SIZE is in dwords, not bytes.
- Randy Dunlap: more USB updates
- Kanoj Sarcar: clean up the NUMA interfaces (pg_data instead of nodes)
- "save_fpu()" was broken. Need to clear pending errors: save_init_fpu().
- pre2:
- remember to change the kernel version ;)
- isapnp.txt bugfix
- ia64 update
- sparc update
- networking update (pppoe init, frame diverter, fix tcp_sendmsg,
fix udp_recvmsg).
- Compile for WinChip must _not_ use "-march=i686". It's a i586.
- Randy Dunlap: more USB updates
- clarify the Firewire AIC-5800 situation. It's not supported yet.
- PCI-space decode size fix. This is needed for some (broken?) hardware
- /proc/self/maps off-by-one error
- 3c501, 3c507, cs89x0 network drivers drop unnecessary check_region
- Asahi Kasei AK4540: new codec ID. Yamaha: new PCI ID's.
- ne2k-pci net driver documentation update
- Paul Gortmaker: delete paranoia check in rtc_exit
- scsi_merge: memset the right amount of memory.
- sun3fb: old __initfunc() not supported any more.
- synclink: remove unnecessary task state games
- xd.c: proper casting for 64-bit architectures
- vmalloc: page table update race condition.
- pre1:
- Roger Larsson: ">=" instead of ">" to make the VM not get stuck.
- Gideon Glass: brw_kiovec() failure case oops fix
- Rik van Riel: better memory balancing and OOM killer
- Ivan Kokshaysky: alpha compile fixes
- Vojtech Pavlik: forgotten ENOUGH macro in via82cxxx ide driver
- Arnaldo Carvalho de Melo: acpi resource leak fix
- Brian Gerst: use mov's instead of xchg in kernel trap entry
- Torben Mathiasen: tlan timer being added twice bug
- Andrzej Krzysztofowicz: config file fixes
- Jean Tourrilhes: Wavelan lockup on SMP fix
- Roman Zippel: initdata must be initialized (even if it is to zero:
gcc is strange)
- Jean Tourrilhes: hp100 driver lockup at startup on SMP
- Russell King: fix silly minixfs uninitialized error bug
- (various): fix uid hashing to use "uid_t" instead of "unsigned short"
- Jaroslav Kysela: isapnp timeout fix. NULL ptr dereference fix.
- Alain Knaff: fdformat should work again.
- Randy Dunlap: USB - fix bluetooth, acm, printer, serial to work
with urb->dev changes.
- Randy Dunlap: USB whiteheat serial driver firmware update.
- Randy Dunlap: USB hub memory corruption and pegasus driver update
- Andre Hedrick: IDE Makefile cleanup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 71%]
* Re: [PATCH] Re: test10-pre7
@ 2000-10-30 21:02 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 21:02 UTC (permalink / raw)
To: Alexander Viro; +Cc: Kernel Mailing List
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> Unfortunately, it doesn't fix the thing. ->sync_page() is called when we
> do not own the page lock and nfs_sync_page() uses page->mapping. Yes, we
> check it before calling the bloody thing, but we don't own the lock.
Good catch.
> Problem only for NFS, but I'm not sure what to do about it - the whole
> point of ->sync_page() seems to be (if I understood Trond's intentions
> right) in forcing the ->readpage() in progress.
How about just changing ->sync_page() semantics to own the page lock? That
sound slike the right thing anyway, no?
> Another place you've missed is in read_cache_page(). That one is easy - we've
> just locked the page and we should just repeat the whole thing if it's out
> of cache.
I didn't actually miss it, I just looked at the users and decided that it
looks like they should never have this issue. But I might have missed
something. As far as I can tell, "read_cache_page()" is only used for
meta-data like things that cannot be truncated.
But you're right, we should do it for consistency.
> One more is in filemap_swapout() - dunno, I just shifted the check to
> filemap_write_page().
I'd really like to do these in the thing that locks the page, and make the
rule be that the page locker needs to do the work. That's why I'd prefer
to let the test be in the _caller_ of filemap_write_page(), as that's the
point where we got the lock.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: test10-pre7
@ 2000-10-30 22:21 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 22:21 UTC (permalink / raw)
To: Alexander Viro; +Cc: Kernel Mailing List
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> > I didn't actually miss it, I just looked at the users and decided that it
> > looks like they should never have this issue. But I might have missed
> > something. As far as I can tell, "read_cache_page()" is only used for
> > meta-data like things that cannot be truncated.
>
> invalidate_inode_pages().
Nope. It checks the page count these days, so it would never kill such a
page from under us (we increment the page count while holding the
pagecache lock).
But yes, I'm starting to agree with you more and more..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-30 22:24 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 22:24 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Keith Owens, Kernel Mailing List
On Mon, 30 Oct 2000, Jeff Garzik wrote:
>
> Ya know, sorting those lists causes this problem, too... usb.o is
> listed first in the various lists, as is usbcore.o. Is it possible to
> avoid sorting? Doing so will fix this, and also any other link order
> breakage like this that exists, too.
This is the right fix. We MUST NOT sort those things.
The only reason for sorting is apparently to remove the "multi-objs"
things, and replace them with the object files they are composed of.
To which I say "Why?"
It makes more sense to just leave the multi's there.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-30 22:51 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 22:51 UTC (permalink / raw)
To: Keith Owens; +Cc: Jeff Garzik, Kernel Mailing List
On Tue, 31 Oct 2000, Keith Owens wrote:
>
> obj-y is used together with export-objs to split objects into O_OBJS
> (no export symbol) and OX_OBJS (export symbol). If usbcore.o (multi)
> is not replaced by its components then usb.o (in export-objs) is not
> added to OX_OBJS so usb.c gets compiled with the wrong flags which
> causes incorrect module symbols. Multi's in obj-y have to replaced by
> their components before being split into O_OBS and OX_OBJS.
Your honour, I object.
What would be wrong with just splitting it the other way, ie make OX_OBJS
be the expanded (but not ordered) list?
That should take care of it, no?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: test10-pre7
@ 2000-10-30 23:05 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 23:05 UTC (permalink / raw)
To: Alexander Viro; +Cc: Kernel Mailing List
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> [ sync_page brokenness ]
>
> To elaborate: the thing is called if we get a contention on the page lock.
Ok, sync_page() looks like a broken design, but I suspect that for
expediency the simplest fix is to just make the NFS sync_page() (re-)check
for "mapping == NULL", and let it be at that. Avoid the NULL pointer
dereference (very small window already).
We should probably in the long run make "page->buffers" be a more generic
thing, and let NFS use it as a wb-info thing, and be done with it. That's
obviously not 2.4.x material, though.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-30 23:08 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 23:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Keith Owens, Kernel Mailing List
On Mon, 30 Oct 2000, Jeff Garzik wrote:
> >
> > What would be wrong with just splitting it the other way, ie make OX_OBJS
> > be the expanded (but not ordered) list?
> >
> > That should take care of it, no?
>
> As an aside: remember you mentioned we should try to go 100% OX_OBJS
> anyway, eliminating O_OBJS completely...
The only problem is that those unfortunate people without tons of
CPU-power would get really fed up with the extra "made depend" overhead.
So as a less drastic step we should just make it more of a hint, and less
of a design that impacts the link-order..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-30 23:15 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 23:15 UTC (permalink / raw)
To: Keith Owens; +Cc: Jeff Garzik, Kernel Mailing List
On Tue, 31 Oct 2000, Keith Owens wrote:
> >
> >What would be wrong with just splitting it the other way, ie make OX_OBJS
> >be the expanded (but not ordered) list?
> >
> >That should take care of it, no?
>
> usbcore.o is both multi part *and* order critical. This is a
> combination that the existing "link order relies on declaration order"
> kludge cannot cope with. It requires an explicit declaration of link
> order, which is exactly what LINK_FIRST implements.
I don't see your point.
I'm saying that EVERYTHING should be order-critical.
It is NEVER acceptable to change the order of object files.
If the Makefile said that the ordering should be
obj-y = usb.o usbcore.o third.o last.o
then the fact that usbcore.o is a multi-part object file SHOULD NOT
MATTER.
We should just link it in the order specified:
ld -r usbdrv.o $(obj-y)
No re-ordering. No expansion of multi-objs. No games. Do what the Makefile
author expected.
In short, we should _remove_ all traces of stuff like
O_OBJS = $(filter-out $(export-objs), $(obj-y))
It's wrong.
We should just have
O_OBJS = $(obj-y)
which is always right.
Then we change the meaning of OX_OBJS, and instead of saying
ALL_O = $(OX_OBJS) $(O_OBJS)
we just say
ALL_O = $(O_OBJS)
and the meaning of $OX_OBJS is the _subset_ of object file that have
SYMTAB objects.
This should all work pretty much as-is, with som every simple
modifications to existing old-style Makefiles, and with some even simpler
modifications to the new-style ones. In fact, it should remove pretty much
all the ugly games that new-style files do.
And it should make all this FIRST/LAST object file mockery a total
non-issue, because the whole concept turns out to be completely
unnecessary.
Is there anything that makes this more complex than what I've outlined
above?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: [PATCH] Re: test10-pre7
@ 2000-10-30 23:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 23:17 UTC (permalink / raw)
To: Alexander Viro; +Cc: Kernel Mailing List
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> Fine with me. Just let's remember that it should be revisited in 2.5.
> What about filemap_swapout()? If you agree with checking ->mapping
> there... looks like we are done with that crap for the time being.
Yup, I agree. I already applied your patch, and did the additional
"mapping" check in nfs_sync_page. We should be ok for now, the only wart
being the fact that sync_page() is ugly.
But better ugly than broken.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-30 23:40 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 23:40 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jeff Garzik, linux-kernel, Keith Owens
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
>
> It is simple - but a change in _every_ makefile is required.
> And it is not really needed for old-style makefiles.
Actually, you don't have to change every makefile, because you CAN do this
all with a simple backwards-compatibility layer, something like:
OXONLY = $(filter-out $(O_OBJS), $(OX_OBJS))
ALL_O = $(OXONLY) $(O_OBJS)
which is a no-op for a "proper" makefile that follows the new rules
(OXONLY will be empty, because all OX_OBJS files will be part of O_OBJS),
but it will make old-style stuff act the same..
I'd actually prefer to just change every Makefile, but hey, I think
something like the above (untested) would make them work unmodified too.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-30 23:47 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 23:47 UTC (permalink / raw)
To: Keith Owens; +Cc: Jeff Garzik, Kernel Mailing List
On Tue, 31 Oct 2000, Keith Owens wrote:
>
> >It is NEVER acceptable to change the order of object files.
>
> It is NEVER acceptable to change the order of object files, but only
> for those files where the developer has explicitly said what the order
> must be. In the case of USB, the developers say usb.o must be first,
> the rest can be in any order.
How much do you want to bet that this can and will change if people were
made aware of how easy ordering can be?
I think we have too many "subtle" rules already.
We should have some REALLY simple and to-the-point rules. Namely:
- object files get linked in the order specified
No ifs, buts, "except when the user doesn't care", or anything like that.
No extra new logic with fancy new names for FIRST and LAST objects. No,
that's the wrong thing.
> > ALL_O = $(O_OBJS)
> >
> >and the meaning of $OX_OBJS is the _subset_ of object file that have
> >SYMTAB objects.
>
> We do not have an automatic way of detecting SYMTAB objects, OX_OBJS is
> the only way that 2.4 kbuild can tell if an source has SYMTAB or not.
I _know_.
I'm saying that we should not care. OX_OBJS still exists, but it has
nothing to do with _linking_. It has everything to do with the build
rules.
OX_OBJS is just a list of files that have exports.
It won't affect linking. It will only affect the list of SYMTAB_OBJS,
_nothing_ more.
For example, the old-style kernel/Makefile, you'd have O_OBJS containing
signal.o and sys.o. As would OX_OBJS. They'd be in both places, because
O_OBJS would tell that yes, we want to link it into the kernel, and
OX_OBJS would tell that yes, we need to generate symtab informaiton for
the files in question.
The two things are entirely orthogonal, as far as I can see. Except
historically we've mixed them up (OX_OBJS + O_OBJS is the link-list,
O_OBJS is the symtab information). And this mixup is what the problems
come from.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: test10-pre7
@ 2000-10-30 23:51 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-30 23:51 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jeff Garzik, linux-kernel, Keith Owens
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
>
> But when we are changing makefiles everywhere - why not do the proper think
> and let the new-style makefiles share their code?
>
> (I have a patch ready - it just needs some forward-porting and testing)
I hate your patch.
I'd rather see "Rules.make" just base itself entirely off the new-style
Makefiles, and have it use "$(obj-y)" instead of O_OBJS etc.
Then, _old_style Makefiles could be fixed up by doing a
include Compat.make
or preferably by just fixing them. I don't want to have another
Rules.make. I want to fix the old users.
(Compat.make would then look like
obj-y = $(OX_OBJS) $(O_OBJS)
export-objs = $(OX_OBJS)
...
and make _old_ Makefiles look like new ones as far as Rules.make is
concerned.
See?
This is the same as with source code. I do NOT want to have backwards
compatibility in source code - if compatibility is needed, I'd much rather
have it be _forwards_ compatibility, where the old setup is made to look
like the new with wrapper functions etc.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-31 0:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 0:47 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jeff Garzik, linux-kernel, Keith Owens
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
>
> Old-style Makefiles are playing dirty tricks with defining
> L_TARGET and then using O_TARGET for linking some onjects into
> an intermediate object.
Actually, I think I have an even simpler solution, which is to change the
newstyle rule to something very simple:
# Translate to Rules.make lists.
O_OBJS := $(obj-y)
M_OBJS := $(obj-m)
MIX_OBJS := $(export-objs)
# The global Rules.make.
include $(TOPDIR)/Rules.make
And you're done..
Does anybody see anything wrong with this approach?
It's kin dof cheesy, but I think it should work. The magic is that by
avoiding OX_OBJS and MX_OBJS, we avoid all the sorting issues. We
basically lie, and say that we don't have anything like that.
Then, MIX_OBJS picks up the stragglers, and makes sure that we consider
the proper files to be SYMTAB_OBJS.
This works for me for USB (ie just remove all the stuff with "int-y" and
multi's etc). Does it work for anybody else?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-31 2:54 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 2:54 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jeff Garzik, linux-kernel, Keith Owens
On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> > newstyle rule to something very simple:
> >
> > # Translate to Rules.make lists.
> >
> > O_OBJS := $(obj-y)
> > M_OBJS := $(obj-m)
>
> This will destroy one nice feature of list-style makefiles:
> when you have and object both in obj-y and obj-m it will be removed
> from obj-m with the old boiler-plates, not with your proposal.
Ok. That's fine, the "obj-m" thing doesn't have any ordering constraints,
so we can do whatever we want to it. Including the $(filter-out ..) thing.
> > MIX_OBJS := $(export-objs)
>
> The MIX_OBJS change is wrong. It may not hurt the resulting
> kernel image but you will build all export-objs, not only the
> ones you actually have selected. But we might get around this
> with some $(filter ...) magic.
Yes. That's fine, again MIX_OBJS does not care about ordering, so
filtering etc is fine here.
The only thing I really care about is O_OBJS = $(obj-y), and with this
setup it seems to be a valid thing to do, with some slight hackery on the
other ones.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-31 2:58 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 2:58 UTC (permalink / raw)
To: Keith Owens; +Cc: Christoph Hellwig, Jeff Garzik, linux-kernel
On Tue, 31 Oct 2000, Keith Owens wrote:
>
> You will compile all export objects, whether they are configured or
> not. The "obvious" fix does not work.
>
> MIX_OBJS := $(filter $(export-objs),$(obj-y) $(obj-m))
>
> export_objs contains usb.o, obj-y contains usb_core.o, it does not
> contain usb.o. Multi lists in obj-y and obj-m need to be expanded
> while preserving the required link order (which is where we came in).
No. We can expand multi-lists at ANY OTHER POINT than O_OBJS. That's ok.
It's only O_OBJS that has any ordering issues.
And we just shouldn't use OX_OBJS at all, as that breaks ordering _and_
can be done equally well with MIX_OBJS instead.
> It still does not document the only real link order constraint in USB.
> The almost complete lack of documentation on which link orders are
> required and which are historical is extremely annoying and _must_ be
> fixed, instead we just propagate the problem.
We can add a comment to the Makefile. That's trivial.
What's not trivial, and what I WANT DONE is to make sure that _when_
somebody wants to maintain link ordering, he can do so in an easy and
obvious way. Not with Yet Another Hack.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-31 6:10 87% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 6:10 UTC (permalink / raw)
To: Rusty Russell; +Cc: Keith Owens, linux-kernel
On Tue, 31 Oct 2000, Rusty Russell wrote:
>
> Quiet suggestion:
If I understood the GNU make syntax correctly (which is possibly not the
case - GNU make is possibly the only example of "overkill" to rival GNU
emacs), this looks like a reasonable idea.
However, it also looks like much more of a change than to change the
fairly boiler-plate OX_OBJS etc stuff in new-style makefiles. And quite
frankly, I don't see how it would get the multi-part object file case
right, but that's probably because you left off some of the black magic
required to do that (and it's not as if the current Makefile magic doesn't
do black magic for that already).
Why do I really care? We actually have the same issue in the SCSI driver
directory, where the ordering restraints are much stricter than for USB.
Now that case has fewer export-objs, and that case isn't a part of a
multi-list, but I really want to have something that works for both these
cases with minimal (and reasonably straightforward) surgery.
In fact, I suspect the SCSI rules would work almost as-is. They break
ordering for the export-objs entry, but that looks fixable. This is how it
looks now:
# Extract lists of the multi-part drivers.
# The 'int-*' lists are the intermediate files used to build the multi's.
multi-y := $(filter $(list-multi), $(obj-y))
multi-m := $(filter $(list-multi), $(obj-m))
int-y := $(sort $(foreach m, $(multi-y), $($(basename $(m))-objs)))
int-m := $(sort $(foreach m, $(multi-m), $($(basename $(m))-objs)))
# Files that are both resident and modular: remove from modular.
obj-m := $(filter-out $(obj-y), $(obj-m))
int-m := $(filter-out $(int-y), $(int-m))
O_OBJS := $(filter-out $(export-objs), $(obj-y))
OX_OBJS := $(filter $(export-objs), $(obj-y))
M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m)))
MX_OBJS := $(sort $(filter $(export-objs), $(obj-m)))
MI_OBJS := $(sort $(filter-out $(export-objs), $(int-m)))
MIX_OBJS := $(sort $(filter $(export-objs), $(int-m)))
In the above, the only problem is OX_OBJS and the breaking of ordering of
"export-objs" (which SCSI doesn't care about, unlike USB, partly because
SCSI uses the old-fashioned "every export in a special file" approach).
And it looks like even THAT could be fixed by changing it to
O_OBJS := $(obj-y)
OX_OBJS :=
MIX_OBJS := $(sort $(filter $(export-objs), $(int-m) $(obj-y)))
(and the others are unchanged) which looks like it would handle it all
correctly. Basically, the changes would mean that the export-objs subset
of $(obj-y) would stay in O_OBJS instead of moving to OX_OBJS, but
additionally those objs would also be added to MIX_OBJS.
Would this satisfy everybody? It _is_ complex enough that I guess it
easily rates having it's own rule-file and be included by new-style
Makefiles instead of being copied over and over again..
Rusty's suggestion would mean having to actually change all the lists
themselves, which at this point sounds a bit dangerous.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 87%]
* Re: test10-pre7
@ 2000-10-31 17:29 93% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 17:29 UTC (permalink / raw)
To: Peter Samuelson; +Cc: Keith Owens, Christoph Hellwig, Jeff Garzik, linux-kernel
On Tue, 31 Oct 2000, Peter Samuelson wrote:
>
> The thing that Keith's patch does is flush these things out into the
> open. By using LINK_FIRST/LINK_LAST, we declare that "these are the
> known issues" -- and then the rest of the objects are reordered, and if
> something breaks, we track it down and add it to LINK_FIRST.
But it doesn't even WORK.
You need to have
LINK_FIRST1
LINK_FIRST2
LINK_FIRST3
...
etc to get the proper ordering.
USB is the _easy_ case. There happen sto be only one file that cares about
ordering.
In many other cases, like SCSI, we need almost _total_ ordering. For such
a case, theer is no "first" or "last" - there is a well-specific ORDER.
Do you see the problem now? LINK_FIRST/LINK_LAST is a complete and utter
hack, and it WON'T EVER WORK. The only way it would work is to make
LINK_FIRST maintain the order, but once you do that LINK_FIRST is
completely superfluous, as it ends up being exactly the same as $(obj-y).
See the fallacy? LINK_FIRST doesn't solve anything, because in the end it
has to do everything O_OBJS will have to do anyway: maintain the full
order.
So trust me, LINK_FIRST/LINK_LAST is not going to happen.
> A few months ago I actually tried to write a make function (yes, GNU
> make has these!) to remove duplicates while not sorting, but GNU make
> doesn't seem to support the necessary iteration/(tail-)recursion
> features. (Surprising, considering GNU's overall LISP-ish worldview.)
Ehh..
There are multiple solutions to this. One is to simply not do that then.
We've done that before, it's not all that painful at all. The classic
example is the current drivers/net/ Makefile, which is badly written
anyway (a mixture of old-style and new-style stuff), and has that 8390.o
and slhc.o multiple thing. It's not that hard to re-write by just adding a
special
obj-8390-$(CONFIG_xxx) = y
for every config that wants 8390.o (and same thing for slhc) and at the
very end do a final
obj-$(obj-8390-y) += 8390.o
Not as simple as what we have now, but not a disaster like the current
lack of ordering is.
And if you really want to remove duplicates, at worst we can even use an
external program for it - which would solve all these things once and for
all. The difference between
$(filter .. black magic lies here ..)
and
$(shell .. black magic lies here ..)
is not that big.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 93%]
* Re: test10-pre7
@ 2000-10-31 17:31 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 17:31 UTC (permalink / raw)
To: Keith Owens; +Cc: Russell King, Jeff Garzik, Kernel Mailing List
On Wed, 1 Nov 2000, Keith Owens wrote:
>
> LINK_FIRST is processed in the order it is specified, so a.o will be
> linked before z.o when both are present. See the patch.
So why don't you do the same thing for obj-y, then?
Why can't you do
LINK_FIRST=$(obj-y)
and be done with it?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-31 18:38 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 18:38 UTC (permalink / raw)
To: Vladislav Malyshkin; +Cc: Peter Samuelson, R.E.Wolff, linux-kernel
Ok, how about this approach? It only works for the case where we do not
have the kind of multiple stuff that drivers/net has, but hey, we don't
actually need to handle all the cases right now.
We can leave that for the future, as the configuration process is likely
to change anyway during 2.5.x, and the multiple object case may go away
entirely (ie the case of slhc and 8390 will become just a normal
configuration dependency: you'd have a "CONFIG_SLHC" entry that is
computed by the dependency graph at configuration time, rather than by the
Makefile at build time).
This is the simplest rule base that I could come up with that should work
for both SCSI and USB:
# Translate to Rules.make lists.
multi-used := $(filter $(list-multi), $(obj-y) $(obj-m))
multi-objs := $(foreach m, $(multi-used), $($(basename $(m))-objs))
active-objs := $(sort $(multi-objs) $(obj-y) $(obj-m))
O_OBJS := $(obj-y)
M_OBJS := $(obj-m)
MIX_OBJS := $(filter $(export-objs), $(active-objs))
Does anybody see any problems with it? Basically, we're sidestepping the
sorting, because neither SCSI nor USB need it. Making the problem simpler
is always good.
Now, the above won't work for drivers/net, but I think it will work for
just about anything else. So let's just leave drivers/net alone for now.
Simplicity is good.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Linux-2.4.0-test10
@ 2000-10-31 20:41 99% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 20:41 UTC (permalink / raw)
To: Kernel Mailing List
Ok, test10-final is out there now. This has no _known_ bugs that I
consider show-stoppers, for what it's worth.
And when I don't know of a bug, it doesn't exist. Let us rejoice. In
traditional kernel naming tradition, this kernel hereby gets anointed as
one of the "greased weasel" kernel series, one of the final steps in a
stable release.
We're still waiting for the Vatican to officially canonize this kernel,
but trust me, that's only a matter of time. It's a little known fact, but
the Pope likes penguins too.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Linux-2.4.0-test10
@ 2000-10-31 20:57 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 20:57 UTC (permalink / raw)
To: Rik van Riel; +Cc: Kernel Mailing List
On Tue, 31 Oct 2000, Rik van Riel wrote:
> On Tue, 31 Oct 2000, Linus Torvalds wrote:
> >
> > Ok, test10-final is out there now. This has no _known_ bugs that
> > I consider show-stoppers, for what it's worth.
> >
> > And when I don't know of a bug, it doesn't exist. Let us
> > rejoice. In traditional kernel naming tradition, this kernel
> > hereby gets anointed as one of the "greased weasel" kernel
> > series, one of the final steps in a stable release.
>
> Well, there's the thing with RAW IO being done into a
> process' address space and the data arriving only after
> the page gets unmapped from the process.
Yes. But that doesn't count like a "show-stopper" for me, simply because
it's one of those small details that are known, and never materialize
under normal load.
Yes, it will have to be fixed before anybody starts doing RAW IO in a
major way. And I bet it will be fixed. But it's not on my list of "I
cannot release a 2.4.0 before this is done" - even if I think it will
actually be fixed for the common case before that anyway.
(Note: I suspect that we may just have to accept the fact that due to NFS
etc issues, RAW IO into a shared mapping might not really supported at
all. I don't think any raw IO user uses it that way anyway, so I think the
big and worrisome case is actually only the swap-out case).
> > We're still waiting for the Vatican to officially canonize this
> > kernel, but trust me, that's only a matter of time. It's a
> > little known fact, but the Pope likes penguins too.
>
> Lets just hope he doesn't need RAW IO ;)
Naah, he mainly just does some browsing with netscape, and (don't tell a
soul) plays QuakeIII with the door locked.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test10-pre7
@ 2000-10-31 20:59 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-10-31 20:59 UTC (permalink / raw)
To: Russell King; +Cc: Keith Owens, Jeff Garzik, Kernel Mailing List
On Tue, 31 Oct 2000, Russell King wrote:
> Linus Torvalds writes:
> > On Wed, 1 Nov 2000, Keith Owens wrote:
> > > LINK_FIRST is processed in the order it is specified, so a.o will be
> > > linked before z.o when both are present. See the patch.
> >
> > So why don't you do the same thing for obj-y, then?
> >
> > Why can't you do
> >
> > LINK_FIRST=$(obj-y)
> >
> > and be done with it?
>
> Hmm, so why don't we just call it obj-y and be done with it? ;)
That was going to be my next question if somebody actually said "sure".
The question was rhetorical, since the way LINK_FIRST is implemented means
that it has all the same problems that $(obj-y) has, and is hard to get
right in the generic case (but you can get it trivially right for the
subset case, like for USB).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Linux-2.4.0-test10
@ 2000-11-01 5:43 70% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-01 5:43 UTC (permalink / raw)
To: Miles Lane; +Cc: Kernel Mailing List
On Tue, 31 Oct 2000, Miles Lane wrote:
>
> Were there no changes between test10-pre7 and test10?
> I notice you didn't send out a Changelist.
>
> The Changelists help me focus my testing.
Sorry. Here it is..
Linus
-----
- final:
- Jeff Garzik: ISA network driver cleanup, wrapper.h fixes, 8139too
update, etc
- Mike Coleman: fix TracerPid in /proc/<n>/status
- Thomas Molina: mark NAT packet drop message KERN_DEBUG
- Marcelo Tosatti: nbd should use GFP_BUFFER, not GFP_ATOMIC
- Steve Pratt: TLB flush order fix
- David Miller: network and sparc updates
- Alan Cox: various details (NULL ptr checks in SCSI etc)
- Daniel Roesen: pretty up microcode revision printouts
- Mike Coleman: fix ptrace ambiguity issues
- Paul Mackerras: make yenta work even in the absense of ISA irqs
- me: make USB Makefile do the right thing for export-objs.
- Randy Dunlap, USB: fix race conditions, usb enumeration etc.
- pre7:
- Niels Jensen: remove no-longer-needed workarounds for old gcc versions
- Ingo Molnar & Rik v Riel: VM inactive list maintenance correction
- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
memory leak fixes
- David Miller: networking updates
- David Mosberger: add AT_CLKTCK to elf information. And make AT_PAGESZ work
for static binaries too.
- oops. pcmcia broke by mistake
- Me: truncate vs page access race fix.
- pre6:
- Jeremy Fitzhardinge: autofs4 expiry fix
- David Miller: sparc driver updates, networking updates
- Mathieu Chouquet-Stringer: buffer overflow in sg_proc_dressz_write
- Ingo Molnar: wakeup race fix (admittedly the window was basically
non-existent, but still..)
- Rasmus Andersen: notice that "this_slice" is no longer used for
scheduling - delete the code that calculates it.
- ALI pirq routing update. It's even uglier than we initially thought..
- Dimitrios Michailidis: fix ipip locking bugs
- Various: face it - gcc-2.7.2.3 miscompiles structure initializers.
- Paul Cassella: locking comments on dev_base
- Trond Myklebust: NFS locking atomicity. refresh inode properly.
- Andre Hedrick: Serverworks Chipset driver, IDE-tape fix
- Paul Gortmaker: kill unused code from 8390 support.
- Andrea Arcangeli: fix nfsv3d wrong truncates over 4G
- Maciej W. Rozycki: PIIX4 needs the same USB quirk handling as PIIX3.
- me: if we cannot figure out the PCI bridge windows, just "inherit"
the window from the parent. Better than not booting.
- Ching-Ling Lee: ALI 5451 Audio core support update
- pre5:
- Mikael Pettersson: more Pentium IV cleanup.
- David Miller: non-x86 platforms missed "pte_same()".
- Russell King: NFS invalidate_inode_pages() can do bad things!
- Randy Dunlap: usb-core.c is gone - module fix
- Ben LaHaise: swapcache fixups for the new atomic pte update code
- Oleg Drokin: fix nm256_audio memory region confusion
- Randy Dunlap: USB printer fixes
- David Miller: sparc updates
- David Miller: off-by-one error in /proc socket dumper
- David Miller: restore non-local bind() behaviour.
- David Miller: wakeups on socket shutdown()
- Jeff Garzik: DEPCA net drvr fixes and CodingStyle
- Jeff Garzik: netsemi net drvr fix
- Jeff Garzik & Andrea Arkangeli: keyboard cleanup
- Jeff Garzik: VIA audio update
- Andrea Arkangeli: mxcsr initialization cleanup and fix
- Gabriel Paubert: better twd_i387_to_fxsr() emulation
- Andries Brouwer: proper error return in ext2 mkdir()
- pre4:
- disable writing to /proc/xxx/mem. Sure, it works now, but it's still
a security risk.
- IDE driver update (Victroy66 SouthBridge support)
- i810 rng driver cleanup
- fix sbus Makefile
- named initializers in module..
- ppoe: remove explicit initializer - it's done with initcalls.
- x86 WP bit detection: do it cleanly with exception handling
- Arnaldo Carvalho de Melo: memory leaks in drivers/media/video
- Bartlomiej Zolnierkiewicz: video init functions get __init
- David Miller: get rid of net/protocols.c - they get to initialize themselves
- David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway.
- Geert Uytterhoeven: Zorro (Amiga) bus support update
- David Miller: work around gcc-2.7.2 bug
- Geert Uytterhoeven: mark struct consw's "const".
- Jeff Garzik: network driver cleanups, ns558 joystick driver oops fix
- Tigran Aivazian: clean up __alloc_pages(), kill_super() and
notify_change()
- Tigran Aivazian: move stuff from .data to .bss
- Jeff Garzik: divert.h typename cleanups
- James Simmons: mdacon using spinlocks
- Tigran Aivazian: fix BFS free block calculation
- David Miller: sparc32 works again
- Bernd Schmidt: fix undefined C code (set/use without a sequence point)
- Mikael Pettersson: nicer Pentium IV setup handling.
- Georg Acher: usb-uhci cpia oops fix
- Kanoj Sarcar: more node_data cleanups for [non]NUMA.
- Richard Henderson: alpha update to new vmalloc setup
- Ben LaHaise: atomic pte updates (don't lose dirty bit)
- David Brownell: ohci memory debugging (== use separate slabs for allocation)
- pre3:
- update email address of Joerg Reuter
- Andries Brouwer: spelling fixes, missing atari brelse(), breada() fix
- Geert Uytterhoeven: used named initializers for "struct console".
- Carsten Paeth: ISDN capifs - iput() only once.
- Petr Vandrovec: VFAT short name generation fix
- Jeff Garzik: i810_rng cleanup, and i815 chipset added.
- Bartlomiej Zolnierkiewicz: clean up some remaining old-style Makefiles
- Dave Jones: x86 setup fixes (recognize Pentium IV etc).
- x86: do the "fast A20" setup too in setup.S
- NIIBE Yutaka: update SuperH for the global page table (vmalloc) change.
- David Miller: sparc updates (vmalloc stuff still pending)
- David Miller: CodaFS warnings and 64-bit warnings in pci_size()
- David Miller: pcnet32 - correct NULL test
- David Miller: vmlist lock -> page_table_lock clarification
- Trond Myklebust: Ouch. rpcauth_lookup_credcache() memory corruption bug
- Matthew Wilcox: file locking cleanups
- David Woodhouse: USB audio spinlock fixes
- Torben Mathiasen: tlan driver cleanups
- Randy Dunlap: Yenta: CACHE_LINE_SIZE is in dwords, not bytes.
- Randy Dunlap: more USB updates
- Kanoj Sarcar: clean up the NUMA interfaces (pg_data instead of nodes)
- "save_fpu()" was broken. Need to clear pending errors: save_init_fpu().
- pre2:
- remember to change the kernel version ;)
- isapnp.txt bugfix
- ia64 update
- sparc update
- networking update (pppoe init, frame diverter, fix tcp_sendmsg,
fix udp_recvmsg).
- Compile for WinChip must _not_ use "-march=i686". It's a i586.
- Randy Dunlap: more USB updates
- clarify the Firewire AIC-5800 situation. It's not supported yet.
- PCI-space decode size fix. This is needed for some (broken?) hardware
- /proc/self/maps off-by-one error
- 3c501, 3c507, cs89x0 network drivers drop unnecessary check_region
- Asahi Kasei AK4540: new codec ID. Yamaha: new PCI ID's.
- ne2k-pci net driver documentation update
- Paul Gortmaker: delete paranoia check in rtc_exit
- scsi_merge: memset the right amount of memory.
- sun3fb: old __initfunc() not supported any more.
- synclink: remove unnecessary task state games
- xd.c: proper casting for 64-bit architectures
- vmalloc: page table update race condition.
- pre1:
- Roger Larsson: ">=" instead of ">" to make the VM not get stuck.
- Gideon Glass: brw_kiovec() failure case oops fix
- Rik van Riel: better memory balancing and OOM killer
- Ivan Kokshaysky: alpha compile fixes
- Vojtech Pavlik: forgotten ENOUGH macro in via82cxxx ide driver
- Arnaldo Carvalho de Melo: acpi resource leak fix
- Brian Gerst: use mov's instead of xchg in kernel trap entry
- Torben Mathiasen: tlan timer being added twice bug
- Andrzej Krzysztofowicz: config file fixes
- Jean Tourrilhes: Wavelan lockup on SMP fix
- Roman Zippel: initdata must be initialized (even if it is to zero:
gcc is strange)
- Jean Tourrilhes: hp100 driver lockup at startup on SMP
- Russell King: fix silly minixfs uninitialized error bug
- (various): fix uid hashing to use "uid_t" instead of "unsigned short"
- Jaroslav Kysela: isapnp timeout fix. NULL ptr dereference fix.
- Alain Knaff: fdformat should work again.
- Randy Dunlap: USB - fix bluetooth, acm, printer, serial to work
with urb->dev changes.
- Randy Dunlap: USB whiteheat serial driver firmware update.
- Randy Dunlap: USB hub memory corruption and pegasus driver update
- Andre Hedrick: IDE Makefile cleanup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 70%]
* Re: Poll and OSS API
@ 2000-11-02 17:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-02 17:38 UTC (permalink / raw)
To: Thomas Sailer; +Cc: linux-kernel
On Thu, 2 Nov 2000, Thomas Sailer wrote:
>
> The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
> specifies that a select _with the sounddriver's filedescriptor
> set in the read mask_ should start the recording.
So fix the stupid API.
The above is just idiocy.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange performance behavior of 2.4.0-test9)
@ 2000-11-04 6:23 95% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-04 6:23 UTC (permalink / raw)
To: linux-kernel
In article <3A0399CD.8B080698@uow.edu.au>,
Andrew Morton <andrewm@uow.edu.au> wrote:
>
>neither flock() nor fcntl() serialisation are effective
>on linux 2.2 or linux 2.4. This is because the file
>locking code still wakes up _all_ waiters. In my testing
>with fcntl serialisation I have seen a single Apache
>instance get woken and put back to sleep 1,500 times
>before the poor thing actually got to service a request.
Indeed.
flock() is the absolute worst case, and always has been. I guess nobody
every actually bothered to benchmark it.
>For kernel 2.2 I recommend that Apache consider using
>sysv semaphores for serialisation. They use wake-one.
>
>For kernel 2.4 I recommend that Apache use unserialised
>accept.
No.
Please use unserialized accept() _always_, because we can fix that.
Even 2.2.x can be fixed to do the wake-one for accept(), if required.
It's not going to be any worse than the current apache config, and
basically the less games apache plays, the better the kernel can try to
accomodate what apache _really_ wants done. When playing games, you
hide what you really want done, and suddenly kernel profiles etc end up
being completely useless, because they no longer give the data we needed
to fix the problem.
Basically, the whole serialization crap is all about the Apache people
saying the equivalent of "the OS does a bad job on something we consider
to be incredibly important, so we do something else instead to hide it".
And regardless of _what_ workaround Apache does, whether it is the sucky
fcntl() thing or using SysV semaphores, it's going to hide the real
issue and mean that it never gets fixed properly.
And in the end it will result in really really bad performance.
Instead, if apache had just done the thing it wanted to do in the first
place, the wake-one accept() semantics would have happened a hell of a
lot earlier.
Now it's there in 2.4.x. Please use it. PLEASE PLEASE PLEASE don't play
games trying to outsmart the OS, it will just hurt Apache in the long run.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: Poll and OSS API
@ 2000-11-04 6:39 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-04 6:39 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Thomas Sailer, linux-kernel
On Sat, 4 Nov 2000, Jeff Garzik wrote:
> > So fix the stupid API.
> >
> > The above is just idiocy.
>
> We're pretty much stuck with the API, until we look at merging ALSA in
> 2.5.x. Broken API or not, OSS is a mature API, and there are
> spec-correct apps that depend on this behavior.
Considering that about 100% of the sound drivers do not follow that
particular API damage anyway (they can't, as has been pointed out: the
driver doesn't even receive enough information to be _able_ to follow the
documented API), I doubt that there are all that many programs that depend
on it.
Yes, some drivers apparently _try_ to follow the spec to some degree, but
we should just change the documentation asap.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: Negative scalability by removal of
@ 2000-11-04 17:22 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-04 17:22 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Sat, 4 Nov 2000, Alan Cox wrote:
>
> > Even 2.2.x can be fixed to do the wake-one for accept(), if required.
>
> Do we really want to retrofit wake_one to 2.2. I know Im not terribly keen to
> try and backport all the mechanism. I think for 2.2 using the semaphore is a
> good approach. Its a hack to fix an old OS kernel. For 2.4 its not needed
We don't need to backport of the full exclusive wait queues: we could do
the equivalent of the semaphore inside the kernel around just accept(). It
wouldn't be a generic thing, but it would fix the specific case of
accept().
Otherwise we're going to have old binaries of apache lying around forever
that do the wrong thing..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: Negative scalability by removal of
[not found] <3A06C007.99EE3746@uow.edu.au>
@ 2000-11-06 17:48 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-06 17:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: Alan Cox, linux-kernel
On Tue, 7 Nov 2000, Andrew Morton wrote:
> Alan Cox wrote:
> >
> > > Even 2.2.x can be fixed to do the wake-one for accept(), if required.
> >
> > Do we really want to retrofit wake_one to 2.2. I know Im not terribly keen to
> > try and backport all the mechanism. I think for 2.2 using the semaphore is a
> > good approach. Its a hack to fix an old OS kernel. For 2.4 its not needed
>
> It's a 16-liner! I'll cheerfully admit that this patch
> may be completely broken, but hey, it's free. I suggest
> that _something_ has to be done for 2.2 now, because
> Apache has switched to unserialised accept().
This is why I'd love to _not_ see silly work-arounds in apache: we
obviously _can_ fix the places where our performance sucks, but only if we
don't have other band-aids hiding the true issues.
For example, with a file-locking apache, we'd have to fix the (noticeably
harder) file locking thing to be wake-one instead, and even then we'd
never be able to do as well as something that gets the same wake-one thing
without the two extra system calls.
The patch looks superficially fine to me, although it does seem to add
another cache-line to the wakeup setup - it migth be worth-while to have
the exclusive state closer. But maybe I just didn't count right.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test11-pre1
@ 2000-11-07 21:06 99% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-07 21:06 UTC (permalink / raw)
To: Kernel Mailing List
Mostly driver updates.
With a few notable exceptions: two rather subtle MM race conditions that
happened with SMP and highmem respectively. And the FXCSR and file locking
that was already discussed on the list.
Linus
-----
- pre1:
- me: make PCMCIA work even in the absense of PCI irq's
- me: add irq mapping capabilities for Cyrix southbridges
- me: make IBMMCA compile right as a module
- me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed.
- Andrea Arkangeli: don't allow people to set security-conscious
bits in mxcsr through ptrace SETFPXREGS.
- Jürgen Fischer: aha152x update
- Andrew Morton, Trond Myklebust: file locking fixes
- me: TLB invalidate race with highmem
- Paul Fulghum: synclink/n_hdlc driver updates
- David Miller: export sysctl_jiffies, and have the proper no-sysctl
version handy
- Neil Brown: RAID driver deadlock and nsfd read access to
execute-only files fix
- Keith Owens: clean up module information passing, remove
"get_module_symbol()".
- Jeff Garzik: network (and other) driver fixes and cleanups
- Andrea Arkangeli: scheduler cleanup.
- Ching-Ling Li: fix ALi sound driver memory leak
- Anton Altaparmakov: upcase fix for NTFS
- Thomas Woller: CS4281 audio update
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] deadlock fix
@ 2000-11-08 4:39 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-08 4:39 UTC (permalink / raw)
To: Gary E. Miller; +Cc: Mike Galbraith, MOLNAR Ingo, linux-kernel
On Tue, 7 Nov 2000, Gary E. Miller wrote:
>
> I see this patch did not make it into test11-pre1. Without it
> raid1 and SMP do not work together. Please consider for test11-pre2.
You must have a different test11-pre1 than the one I have.
It's already there in -pre1, as far as I can see.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [RANT] Linux-IrDA status
@ 2000-11-08 5:23 92% ` Linus Torvalds
2000-11-08 7:26 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-08 5:23 UTC (permalink / raw)
To: Michael Rothwell; +Cc: jt, Kernel Mailing List, Alan Cox, Dag Brattli
On Wed, 8 Nov 2000, Michael Rothwell wrote:
> Linus Torvalds wrote:
> >
> > Also, I've never seen much in the form of explanation, and at least the
> > last patch I saw just the first screenful was so off-putting that I just
> > went "Ok, I have real bugs to fix, I don't need this crap".
>
> Like what? I'm not sure what you're saying here. It seems that the pople
> writing the IrDA code have gotten no feedback from you as to why their
> patch is never accepted -- could you clarify?
There's one _major_ reason why things never get accepted:
CVS trees
I'm not fed patches. I'm force-fed big changes every once in a while. I
don't like it.
I like it even less when the very first screen of a patch is basically a
stupid change that implies that somebody calls ioctl's from interrupts.
When I get a big patch like that, where the very first screen is
bletcherous, what the hell am I supposed to do? I'm not going to waste my
time on people who cannot send multiple small and well-defined patches,
and who send be big, ugly, "non-maintained" (as far as I'm concerned)
patches.
I'm surprised Alan rants about this. He knows VERY well how I work, and is
(along with Jeff Garzik and Randy Dunlap) one of the people who are very
good at sending me 25 separate patches with explanations of what they do.
Basically, if you send me a big patch with tons of changes, how the hell
DO you expect me to answer them? Does anybodt really expect me to go
through ten thousand lines of code that I do not know, and comment on it?
Obviously not, as anybody with an ounce of sense would see.
So what choice do I have? Apply them blindly?
Quite frankly, I'd rather have a few people hate me deeply than apply
stuff I don't like. If I just start blindly applying big patches, I can
avoid nasty discussions. But I'd rather have people flame me. Maybe some
day people will instead start sending me smaller commented patches.
I'm NOT going to do other peoples work for them. If people can't be
bothered to send me well-specified patches ESPECIALLY now that we're close
to 2.4.x, then I can't be bothered to apply them,
Live with it. Hat eme all you like. I do not care. Th ething I care about
is not letting too much crap through unchecked.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 92%]
* Re: [RANT] Linux-IrDA status
2000-11-08 5:23 92% ` Linus Torvalds
@ 2000-11-08 7:26 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-08 7:26 UTC (permalink / raw)
To: Michael Rothwell; +Cc: jt, Kernel Mailing List, Alan Cox, Dag Brattli
On Wed, 8 Nov 2000, Michael Rothwell wrote:
>
> Like what? I'm not sure what you're saying here. It seems that the pople
> writing the IrDA code have gotten no feedback from you as to why their
> patch is never accepted -- could you clarify?
Just to clarify.
The ONLY message from the IrDA people I've gotten during the last few
weeks has been a SINGLE email from Dag Brattli, with a 330kB patch.
The whole, full, unabridged explanation for those 330kB of patches:
>> Hello Linus,
>>
>> Here is the latest IrDA patch for Linux-2.4.0-test10.
>>
>> Short summary:
>>
>> o Fixes IrDA in 2.4
>> o Touches _no_ other files.
>>
>> Please apply!
>>
>> Best regards
>>
>> Dag Brattli
That's it.
ONE message during the last month. ONE huge patch. From people who should
have known about 2.4.x being pending for some time.
10,000+ lines of diff, with _no_ effort to split it up, or explain it with
anything but
"o Fixes IrDA in 2.4"
and these people expect me to reply, sending long explanations of why I
don't like them? After they did nothing of the sort for the code they
claim should have been applied? Nada.
Get a grip.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Pentium 4 and 2.4/2.5
@ 2000-11-08 17:26 93% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-08 17:26 UTC (permalink / raw)
To: linux-kernel
In article <E13t7dG-0007KT-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>Be careful with the intel patches. The ones I've seen so far tried to call the
>cpu 'if86' breaking several tools that do cpu model checking off uname. They
>didnt fix the 2GHz CPU limit, they use 'rep nop' in the locks which is
>explicitly 'undefined behaviour' for non intel processors and they use the
>TSC without checking it had one.
"rep nop" is definitely not undefined behaviour except in some older
Intel manuals.
Do you actually know of a CPU where it doesn't work? Every single
intel-compatible CPU I know of has the rep prefixes as no-ops if they
aren't used (lock -> ILL being a later, documented, addition), and the
way the prefixes work it almost has to be that way.
As prefixes they can't be part of the instruction, because you can
legally have other prefixes in between the rep and the real instruction,
which means that any sane implementation will just set a flag when it
sees the prefix, and an instruction that doesn't care will just ignore
the flag. So you'd almost have to do _extra_ work to make "rep nop"
fail, even if it used to be specified as "undefined".
Standard 2.4.x will definitely be using "rep nop" unless somebody can
show me a CPU where it doesn't work (and even then I probably won't care
unless that CPU is also SMP-capable). It's documented by intel these
days, and it works on all CPU's I've ever heard of, and it even makes
sense to me (*).
(*) Well.. More sense than _some_ instruction set extensions I've seen.
After all, "repeat no-op" for a longer delay sounds almost logical.
Certainly better than that IV == 15 thing, ugh ;)
Also, at least part of the reason Intel removed the TSC check was that
Linux actually seems to get the extended CPU capability flags wrong,
overwriting the _real_ capability flags which in turn caused the TSC
check on Linux to simply not work. Peter Anvin is working on fixing
this. I suspect that Linux-2.2 has the same problem.
There's a few other minor details that need to be fixed for Pentium 4
features (aka " not very well documented errata"), and I think I have
them all except for waiting for Peter to get the capabilities flag
handling right.
So I suspect that we'll have good support for Pentium IV soon enough..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 93%]
* Re: Pentium 4 and 2.4/2.5
@ 2000-11-08 17:31 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-08 17:31 UTC (permalink / raw)
To: linux-kernel
In article <E13tGbg-0007oC-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>rep;nop is a magic instruction on the PIV and possibly some PIII series CPUs
>[not sure]. As far as I can make out it naps momentarily or until bus
>activity thus saving power on spinlocks.
>From what I've heard, the reason Intel _really_ wants "rep nop" is that
without it the CPU will heat up quite efficiently (that's what you do
when you want to run at an eventual 2GHz with all cylinders firing all
the time), causing thermal meltdown on non-thermally protected CPU's and
CPU speed throttling on the ones that _are_ thermally protected (which
will obviously have to be all the shipping ones).
And the thermal throttling will severly cripple performance.
>The problem is 'rep nop' is not defined on other cpus so we can only really use
>it on the PIII/PIV kernel builds
Intel retroactively defined it for all their CPU's. And I very strongly
suspect that every single other x86 CPU vendor does the same. Why not?
They get a new instruction for free, but just documenting it. Maybe they
can sell the same old chip with a new name ("The Xxxxx Wonderchip. Now
with documetned 'rep nop' support! Get one today!").
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Pentium 4 and 2.4/2.5
@ 2000-11-08 18:10 95% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-08 18:10 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Wed, 8 Nov 2000, Alan Cox wrote:
> > unless that CPU is also SMP-capable). It's documented by intel these
> > days, and it works on all CPU's I've ever heard of, and it even makes
> > sense to me (*).
>
> Do the intel docs guarantee it works on i486 and higher, if so SMP athlon
> will be the only check needed for the SMP users. You work for an x86 chip
> cloning company so if you say it works I trust you 8)
Well, we don't make low-power SMP laptops, so as such Transmeta doesn't
much care. It will work, though. And yes, as far as I know Intel made it
an "architecture feature", meaning that they claim it work son all their
ia32 chips.
Now, I could imagine that Intel would select an instruction that didn't
work on Athlon on purpose, but I really don't think they did. I don't
have an athlon to test.
It's easy enough to generate a test-program. If the following works,
you're pretty much guaranteed that it's ok
int main()
{
printf("Testing 'rep nop' ... ");
asm volatile("rep ; nop");
printf("okey-dokey\n");
return 0;
}
(there's not much a "rep nop" _can_ do, after all - the most likely CPU
extension would be to raise an "Illegal Opcode" fault).
> > Also, at least part of the reason Intel removed the TSC check was that
> > Linux actually seems to get the extended CPU capability flags wrong,
> > overwriting the _real_ capability flags which in turn caused the TSC
> > check on Linux to simply not work. Peter Anvin is working on fixing
> > this. I suspect that Linux-2.2 has the same problem.
>
> I've not seen incorrect TSC detection in 2.2, do you know the precise
> circumstances this occurs and I'll check over them. I've also got no
> bug reports of this failing.
It won't fail on other CPU's. The bug is, as far as I can tell, in
get_model_name(),
cpuid(0x80000001, &dummy, &dummy, &dummy, &(c->x86_capability));
Notice how we overwrite the x86_capability state with whatever we read
from the extended register 0x80000001. So we overwrite the _real_
capabilities that we got the right way in head.S.
This is wrong. It just happens to work on other, non-Pentium IV,
processors. The extended capabilities are an _extention_, not replacement,
for the regular capabilities.
> check_config would also panic with the 'Kernel compiled for ..' message
> if it occurred.
Which is what it apparently does, if you compile for TSC. Even though very
obviously a Pentium IV _does_ have a TSC.
NOTE! I don't actually have access to a Pentium IV myself yet, although
I'm promised one soon enough. So I've only got second-hand reports on the
cpuid thing so far.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: PATCH: rd - deadlock removal
@ 2000-11-09 18:02 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-09 18:02 UTC (permalink / raw)
To: Jens Axboe; +Cc: Neil Brown, linux-kernel
On Thu, 9 Nov 2000, Jens Axboe wrote:
>
> > The second is more elegant in that it side steps the problem by
> > giving rd.c a make_request function instead of using the default
> > _make_request. This means that io_request_lock is simply never
> > claimed my rd.
>
> And this solution is much better, even given the freeze I think that
> is the way to go.
I agree, I already applied it. The second approach just makes the problem
go away, and also avoids needlessly merging the request etc. I suspect
that the lack of request-merging could also eventually be used to simplify
the driver a bit, as it now wouldn't need to worry about that issue any
more at all.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [BUG] /proc/<pid>/stat access stalls badly for swapping process, 2.4.0-test10
[not found] <Pine.Linu.4.10.10011091452270.747-100000@mikeg.weiden.de>
@ 2000-11-09 18:31 86% ` Linus Torvalds
0 siblings, 2 replies; 200+ results
From: Linus Torvalds @ 2000-11-09 18:31 UTC (permalink / raw)
To: Mike Galbraith
Cc: Jens Axboe, MOLNAR Ingo, Rik van Riel, Kernel Mailing List, Alan Cox
As to the real reason for stalls on /proc/<pid>/stat, I bet it has nothing
to do with IO except indirectly (the IO is necessary to trigger the
problem, but the _reason_ for the problem lies elsewhere).
And it has everything to do with the fact that the way Linux semaphores
are implemented, a non-blocking process has a HUGE advantage over a
blocking one. Linux kernel semaphores are extreme unfair in that way.
What happens is that some process is getting a lot of VM faults and gets
its VM semaphore. No contention yet. it holds the semaphore over the
IO, and now another process does a "ps".
The "ps" process goes to sleep on the semaphore. So far so good.
The original process releases the semaphore, which increments the count,
and wakes up the process waiting for it. Note that it _wakes_ it, it does
not give the semaphore to it. Big difference.
The process that got woken up will run eventually. Probably not all that
immediately, because the process that woke it (and held the semaphore)
just slept on a page fault too, so it's not likely to immediately
relinquish the CPU.
The original running process comes back faulting again, finds the
semaphore still unlocked (the "ps" process is awake but has not gotten to
run yet), gets the semaphore, and falls asleep on the IO for the next
page.
The "ps" process actually gets to run now, but it's a bit late. The
semaphore is locked again.
Repeat until luck breaks the bad circle.
(This schenario, btw, is much harder to trigger on SMP than on UP. And
it's completely separate from the issue of simple disk bandwidth issues
which can obviously cause no end of stalls on anything that needs the
disk, and which can also happen on SMP).
NOTE! If somebody wants to fix this, the fix should be reasonably simple
but needs to be quite exhaustively checked and double-checked. It's just
too easy to break the semaphores by mistake.
The way to make semaphores more fair is to NOT allow a new process to just
come in immediately and steal the semaphore in __down() if there are other
sleepers. This is most easily accomplished by something along the lines of
the following in __down() in arch/i386/kernel/semaphore.c
spin_lock_irq(&semaphore_lock);
sem->sleepers++;
+
+ /*
+ * Are there other people waiting for this?
+ * They get to go first.
+ */
+ if (sleepers > 1)
+ goto inside;
for (;;) {
int sleepers = sem->sleepers;
/*
* Add "everybody else" into it. They aren't
* playing, because we own the spinlock.
*/
if (!atomic_add_negative(sleepers - 1, &sem->count)) {
sem->sleepers = 0;
break;
}
sem->sleepers = 1; /* us - see -1 above */
+inside:
spin_unlock_irq(&semaphore_lock);
schedule();
tsk->state = TASK_UNINTERRUPTIBLE|TASK_EXCLUSIVE;
spin_lock_irq(&semaphore_lock);
}
spin_unlock_irq(&semaphore_lock);
But note that teh above is UNTESTED and also note that from a throughput
(as opposed to latency) standpoint being unfair tends to be nice.
Anybody want to try out something like the above? (And no, I'm not
applying it to my tree yet. It needs about a hundred pairs of eyes to
verify that there isn't some subtle "lost wakeup" race somewhere).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 86%]
* Re: [bug] usb-uhci locks up on boot half the time
@ 2000-11-09 22:54 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-09 22:54 UTC (permalink / raw)
To: linux-kernel
In article <3A0B27E3.7D10AB64@linux.com>, David Ford <david@linux.com> wrote:
>
>The oddity is that kdb shows the machine to lock up on the popf in
>pci_conf_write_word()+0x2c. I never did get around to digging up this
>routine and looking at the code, but I suspect this is a final return
>from the routine. I'm rather confused however, I have no idea why a
>flags pop would hang the hardware.
Educated guess: it enables interrupts, after it has done something to
the hardware that causes an infinite stream of them.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test11-pre2
@ 2000-11-10 1:52 91% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-10 1:52 UTC (permalink / raw)
To: Kernel Mailing List
Nothing stands out as affecting most people here. Security fix for /proc,
and various cleanups. Alpha and sparc fixes. If you use RAID or ramdisk,
upgrade.
Linus
-----
- pre2:
- Stephen Rothwell: directory notify could return with the lock held
- Richard Henderson: CLOCKS_PER_SEC on alpha.
- Jeff Garzik: ramfs and highmem: kmap() the page to clear it
- Asit Mallick: enable the APIC in the official order
- Neil Brown: avoid rd deadlock on io_request_lock by using a
private rd-request function. This also avoids unnecessary
request merging at this level.
- Ben LaHaise: vmalloc threadign and overflow fix
- Randy Dunlap: USB updates (plusb driver). PCI cacheline size.
- Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1
- Alan Cox: various (Athlon mmx copy, NULL ptr checks for
scsi_register etc).
- Al Viro: fix /proc permission check security hole.
- Can-Ru Yeou: SiS301 fbcon driver
- Andrew Morton: NMI oopser and kernel page fault punch through
both console_lock and timerlist_lock to make sure it prints out..
- Jeff Garzik: clean up "kmap()" return type (it returns a kernel
virtual address, ie a "void *").
- Jeff Garzik: network driver docs, various one-liners.
- David Miller: add generic "special" flag to page flags, to be
used by architectures as they see fit. Like keeping track of
cache coherency issues.
- David Miller: sparc64 updates, make sparc32 boot again
- Davdi Millner: spel "synchronous" correctly
- David Miller: networking - fix some bridge issues, and correct
IPv6 sysctl entries.
- Dan Aloni: make fork.c use proper macro rather than doing
get_exec_domain() by hand.
- pre1:
- me: make PCMCIA work even in the absense of PCI irq's
- me: add irq mapping capabilities for Cyrix southbridges
- me: make IBMMCA compile right as a module
- me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed.
- Andrea Arkangeli: don't allow people to set security-conscious
bits in mxcsr through ptrace SETFPXREGS.
- Jürgen Fischer: aha152x update
- Andrew Morton, Trond Myklebust: file locking fixes
- me: TLB invalidate race with highmem
- Paul Fulghum: synclink/n_hdlc driver updates
- David Miller: export sysctl_jiffies, and have the proper no-sysctl
version handy
- Neil Brown: RAID driver deadlock and nsfd read access to
execute-only files fix
- Keith Owens: clean up module information passing, remove
"get_module_symbol()".
- Jeff Garzik: network (and other) driver fixes and cleanups
- Andrea Arkangeli: scheduler cleanup.
- Ching-Ling Li: fix ALi sound driver memory leak
- Anton Altaparmakov: upcase fix for NTFS
- Thomas Woller: CS4281 audio update
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 91%]
* Re: [BUG] /proc/<pid>/stat access stalls badly for swapping process, 2.4.0-test10
@ 2000-11-10 17:07 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-10 17:07 UTC (permalink / raw)
To: linux-kernel
In article <Pine.Linu.4.10.10011100732250.601-100000@mikeg.weiden.de>,
Mike Galbraith <mikeg@wen-online.de> wrote:
>>
>> (This schenario, btw, is much harder to trigger on SMP than on UP. And
>> it's completely separate from the issue of simple disk bandwidth issues
>> which can obviously cause no end of stalls on anything that needs the
>> disk, and which can also happen on SMP).
>
>Unfortunately, it didn't help in the scenario I'm running.
>
>time make -j30 bzImage:
>
>real 14m19.987s (within stock variance)
>user 6m24.480s
>sys 1m12.970s
Note that the above kin of "throughput performance" should not have been
affected, and was not what I was worried about.
>procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
>31 2 1 12 1432 4440 12660 0 12 27 151 202 848 89 11 0
>34 4 1 1908 2584 536 5376 248 1904 602 763 785 4094 63 32 5
>13 19 1 64140 67728 604 33784 106500 84612 43625 21683 19080 52168 28 22 50
Looks like there was a big delay in vmstat there - that could easily be
due to simple disk throughput issues..
Does it feel any different under the original load that got the original
complaint? The patch may have just been buggy and ineffective, for all I
know.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: The IrDA patches !!! (was Re: [RANT] Linux-IrDA status)
[not found] <20001109192404.B25828@bougret.hpl.hp.com>
@ 2000-11-10 19:56 89% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-10 19:56 UTC (permalink / raw)
To: jt; +Cc: Michael Rothwell, Kernel Mailing List, Alan Cox, Dag Brattli
On Thu, 9 Nov 2000, Jean Tourrilhes wrote:
>
> I spent my full day going through my archives and splitting
> the big patch of Dag into lots of small patches (see attached). I'm
> glad I've got a big hard drive full of junk.
When I say multiple mails, I mean multiple mails. NOT "26 attachements in
one mail". In fact, not a single attachment at all, please. Send me
patches as a regular text body, with the explanation at the top, and the
patch just appended.
Why?
Attachements may look simple, but they are not. I end up having to open
each and every one of them individually, remembering which one I've
checked, save them off individually, remembering what the file name was,
and then apply them each individually.
See the picture? Attachements are evil.
In contrast, imagine that you (and everybody else) sends me plain-text
patches, with just an explanation on top. What do I do?
I see the explanation immediately when I open the mail (ie when I press
the "n" key for "next email").
I can save it off with a simple "s../doit", which saves it in _one_ "doit"
file appended to all the other pending stuff. Alternatively, I can skip
it, or leave it pending, and let the _mail_software_ remember whether I
answered that particular patch.
I can reply to it individually, and that patch (and nothing else) will be
automatically set up for the reply so that I can easily quote whatever
parts I want to point out.
I can apply all the patches that I have approved with a single
patch -p1 < ~/doit
without having to go through them individually.
None of the above works with attachments.
> > Basically, if you send me a big patch with tons of changes, how the hell
> > DO you expect me to answer them? Does anybodt really expect me to go
> > through ten thousand lines of code that I do not know, and comment on it?
> > Obviously not, as anybody with an ounce of sense would see.
>
> If somebody send you 1000 lines in one go or as 100 times 10
> lines, it doesn't matter, it is still 1000 lines of code to read
> through. Even small patches can be totally obscure for somebody not
> familiar with the code and what it is supposed to do.
You are WRONG.
10 emails with 1000-line patches are _much_ easier to handle. I can
clearly see the parts that belong together (nothing is mixed up with other
issues), and I can keep the explanation in mind. I do not have to remind
myself what that particular piece is doing.
It has other advantages too. With a single 10000-line patch, if I don't
like something, I have a hard time just removing THAT part. So I have to
reject the whole f*cking patch, and the person who sent it to me has to
fix up the whole thing (assuming I'd bother answering to it, poitning out
the parts that I don't like from the large patch, which I will not).
With 10 1000-line emails, I can decide to apply 8 of them outright, apply
one with comments, and discard one that does something particularly
nauseating. And I can much more easily explain to the submitter which one
I hate, without having to edit it down.
See?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 89%]
* Re: [BUG] /proc/<pid>/stat access stalls badly for swapping process,2.4.0-test10
@ 2000-11-11 6:20 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-11 6:20 UTC (permalink / raw)
To: linux-kernel
In article <3A0C6BD6.A8F73950@dm.ultramaster.com>,
David Mansfield <lkml@dm.ultramaster.com> wrote:
>Linus Torvalds wrote:
>...
>>
>> And it has everything to do with the fact that the way Linux semaphores
>> are implemented, a non-blocking process has a HUGE advantage over a
>> blocking one. Linux kernel semaphores are extreme unfair in that way.
>>
>...
>> The original running process comes back faulting again, finds the
>> semaphore still unlocked (the "ps" process is awake but has not gotten to
>> run yet), gets the semaphore, and falls asleep on the IO for the next
>> page.
>>
>> The "ps" process actually gets to run now, but it's a bit late. The
>> semaphore is locked again.
>>
>> Repeat until luck breaks the bad circle.
>>
>
>But doesn't __down have a fast path coded in assembly? In other words,
>it only hits your patched code if there is already contention, which
>there isn't in this case, and therefore the bug...?
The __down() case should be hit if there's a waiter, even if that waiter
has not yet been able to pick up the lock (the waiter _will_ have
decremented the count to negative in order to trigger the proper logic
at release time).
But as I mentioned, the pseudo-patch was certainly untested, so
somebody should probably walk through the cases to check that I didn't
miss something.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: sendfile(2) fails for devices?
@ 2000-11-12 0:57 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-12 0:57 UTC (permalink / raw)
To: linux-kernel
In article <3A0DE0C8.C700F33D@mandrakesoft.com>,
Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
>sendfile(2) fails with -EINVAL every time I try to read from a device
>file.
>
>This sounds like a bug... is it? (the man page doesn't mention such a
>restriction)
sendfile() on purpose only works on things that use the page cache.
EINVAL is basically sendfiles way of saying "I would fall back on doing
a read+write, so you might as well do it yourself in user space because
it might actually be more efficient that way".
>I am using kernel 2.4.0-test11-pre2. All other tests with sendfile(2)
>succeed: file->file, file->STDOUT, STDIN->file...
Yes, as long as STDIN is a file ;)
sendfile() wants the source to be in the page cache, because the whole
point of sendfile() was to avoid a copy.
The current device model does _not_ use the page cache. Now, arguably
that's a bug - it also means that you cannot mmap() a block device - but
as it could be easily documented (maybe it is, somewhere), I'll call it
a bad feature for now.
Now, if you want to add the code to do address spaces for block devices,
I wouldn't be all that unhappy. I've wanted to see it for a while. I'm
not likely to apply it for 2.4.x any more, but I'd love to have it early
for 2.5.x.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [patch] patch-2.4.0-test10-irda24 (resend)
[not found] <200011120115.BAA37679@tepid.osl.fast.no>
@ 2000-11-12 2:13 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-12 2:13 UTC (permalink / raw)
To: Dag Brattli; +Cc: linux-kernel
On Sun, 12 Nov 2000, Dag Brattli wrote:
>
> (resending in case it got lost, didn't show up on linux-kernel)
Didn't get lost, but I think the linux-kernel size filter killed it from
the kernel list.
Everything applied. Thanks,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [patch] wakeup_bdflush related fixes and nfsd optimizations for test10
@ 2000-11-12 2:30 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-12 2:30 UTC (permalink / raw)
To: Ying Chen/Almaden/IBM; +Cc: linux-kernel
On Sat, 11 Nov 2000, Ying Chen/Almaden/IBM wrote:
>
> This patch includes two sets of things against test10:
> First, there are several places where schedule() is called after
> wakeup_bdflush(1) is called. This is completely unnecessary
Fair enough.
> Second, (I have posted this to the kernel mailing list, but I forgot to cc
> to Linus.) I made some optimizations on racache in nfsd in test10.
..but this would need a lot more testing/feedback, especially from the nfs
client maintainers (I see that Neil Brown did some querying already, I
think more is in order).
Also, I'd _really_ like those lists to be real <linux/list.h> lists
instead of duplicating code.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: The IrDA patches !!! (was Re: [RANT] Linux-IrDA status)
@ 2000-11-12 2:43 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-12 2:43 UTC (permalink / raw)
To: jt; +Cc: Kernel Mailing List, Alan Cox
Ok, thanks to the work of Jean, everything seems to be applied now.
I'll make a test3 one of these days (probably tomorrow), please verify
that everything looks happy.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] show_task() and thread_saved_pc() fix for x86
@ 2000-11-12 2:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-12 2:47 UTC (permalink / raw)
To: Alexander Viro; +Cc: linux-kernel
On Fri, 10 Nov 2000, Alexander Viro wrote:
> diff -urN rc11-2/include/asm-i386/processor.h rc11-2-show_task/include/asm-i386/processor.h
> --- rc11-2/include/asm-i386/processor.h Fri Nov 10 09:14:04 2000
> +++ rc11-2-show_task/include/asm-i386/processor.h Fri Nov 10 16:08:15 2000
> @@ -412,7 +412,7 @@
> */
> extern inline unsigned long thread_saved_pc(struct thread_struct *t)
> {
> - return ((unsigned long *)t->esp)[3];
> + return ((unsigned long **)t->esp)[0][1];
> }
The above needs to get verified: it should be something like
unsigned long *ebp = *((unsigned long **)t->esp);
if ((void *) ebp < (void *) t)
return 0;
if ((void *) ebp >= (void *) t + 2*PAGE_SIZE)
return 0;
if (3 & (unsigned long)ebp)
return 0;
return *ebp;
because otherwise I guarantee that we'll eventually have a bug with a
invalid pointer reference in the debugging code and that would be bad.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* 2.4.0-test11-pre3
@ 2000-11-12 3:22 85% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-12 3:22 UTC (permalink / raw)
To: Kernel Mailing List
Drivers, drivers, drivers. IrDA and ISDN. PPC.
The most interesting part is probably the exclusive wait-queue patch.
David Miller noticed that exclusivity doesn't nest correctly the way we
used to do it: being on multiple wait-queues would potentially cause lost
wake-up events if a non-exclusive waiter got mistaken for an exclusive one
because the exclusive bit was a per-process thing.
Moving the exclusivity bit from the process into the wait-queue cleaned up
the interfaces and also made it nest properly.
No known uses were actually buggy, but at least one case was apparently ok
only by pure luck.
Linus
-----
- pre3:
- James Simmons: vgacon "printk()" deadlock with global irq lock.
- don't poke blanked console on console output
- Ching-Ling: get channels right on ALI audio driver
- Dag Brattli and Jean Tourrilhes: big IrDA update
- Paul Mackerras: PPC updates
- Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin
serial converter.
- Jeff Garzik: pcnet32 and lance net driver fix/cleanup
- Mikael Pettersson: clean up x86 ELF_PLATFORM
- Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and
cleanups
- Al Viro: Jeff missed some kmap()'s. sysctl cleanup
- Kai Germaschewski: ISDN updates
- Alan Cox: SCSI driver NULL ptr checks
- David Miller: networking updates, exclusive waitqueues nest properly,
SMP i_shared_lock/page_table_lock lock order fix.
- pre2:
- Stephen Rothwell: directory notify could return with the lock held
- Richard Henderson: CLOCKS_PER_SEC on alpha.
- Jeff Garzik: ramfs and highmem: kmap() the page to clear it
- Asit Mallick: enable the APIC in the official order
- Neil Brown: avoid rd deadlock on io_request_lock by using a
private rd-request function. This also avoids unnecessary
request merging at this level.
- Ben LaHaise: vmalloc threadign and overflow fix
- Randy Dunlap: USB updates (plusb driver). PCI cacheline size.
- Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1
- Alan Cox: various (Athlon mmx copy, NULL ptr checks for
scsi_register etc).
- Al Viro: fix /proc permission check security hole.
- Can-Ru Yeou: SiS301 fbcon driver
- Andrew Morton: NMI oopser and kernel page fault punch through
both console_lock and timerlist_lock to make sure it prints out..
- Jeff Garzik: clean up "kmap()" return type (it returns a kernel
virtual address, ie a "void *").
- Jeff Garzik: network driver docs, various one-liners.
- David Miller: add generic "special" flag to page flags, to be
used by architectures as they see fit. Like keeping track of
cache coherency issues.
- David Miller: sparc64 updates, make sparc32 boot again
- Davdi Millner: spel "synchronous" correctly
- David Miller: networking - fix some bridge issues, and correct
IPv6 sysctl entries.
- Dan Aloni: make fork.c use proper macro rather than doing
get_exec_domain() by hand.
- pre1:
- me: make PCMCIA work even in the absense of PCI irq's
- me: add irq mapping capabilities for Cyrix southbridges
- me: make IBMMCA compile right as a module
- me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed.
- Andrea Arkangeli: don't allow people to set security-conscious
bits in mxcsr through ptrace SETFPXREGS.
- Jürgen Fischer: aha152x update
- Andrew Morton, Trond Myklebust: file locking fixes
- me: TLB invalidate race with highmem
- Paul Fulghum: synclink/n_hdlc driver updates
- David Miller: export sysctl_jiffies, and have the proper no-sysctl
version handy
- Neil Brown: RAID driver deadlock and nsfd read access to
execute-only files fix
- Keith Owens: clean up module information passing, remove
"get_module_symbol()".
- Jeff Garzik: network (and other) driver fixes and cleanups
- Andrea Arkangeli: scheduler cleanup.
- Ching-Ling Li: fix ALi sound driver memory leak
- Anton Altaparmakov: upcase fix for NTFS
- Thomas Woller: CS4281 audio update
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 85%]
* test11-pre5
@ 2000-11-14 21:47 84% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-14 21:47 UTC (permalink / raw)
To: Kernel Mailing List
More drivers.
The x86 capabilities cleanup is here.
Linus
----
- pre5:
- Rasmus Andersen: add proper "<linux/init.h>" for sound drivers
- David Miller: sparc64 and networking updates
- David Trcka: MOXA numbering starts from 0, not 1.
- Jeff Garzik: sysctl.h standalone
- Dag Brattli: IrDA finishing touches
- Randy Dunlap: USB fixes
- Gerd Knorr: big bttv update
- Peter Anvin: x86 capabilities cleanup
- Stephen Rothwell: apm initcall fix - smp poweroff should work
- Andrew Morton: setscheduler() spinlock ordering fix
- Stephen Rothwell: directory notification documentation
- Petr Vandrovec: ncpfs capabilities check cleanup
- David Woodhouse: fix jffs to use generic isxxxx() library
- Chris Swiedler: oom_kill selection fix
- Jens Axboe: re-merge after sleeping in ll_rw_block.
- Randy Dunlap: USB updates (pegasus and ftdi_sio)
- Kai Germaschewski: ISDN ppp header compression fixed
- pre4:
- Andrea Arcangeli: SMP scheduler memory barrier fixup
- Richard Henderson: fix alpha semaphores and spinlock bugs.
- Richard Henderson: clean up the file from hell: "xor.c"
- pre3:
- James Simmons: vgacon "printk()" deadlock with global irq lock.
- don't poke blanked console on console output
- Ching-Ling: get channels right on ALI audio driver
- Dag Brattli and Jean Tourrilhes: big IrDA update
- Paul Mackerras: PPC updates
- Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin
serial converter.
- Jeff Garzik: pcnet32 and lance net driver fix/cleanup
- Mikael Pettersson: clean up x86 ELF_PLATFORM
- Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and
cleanups
- Al Viro: Jeff missed some kmap()'s. sysctl cleanup
- Kai Germaschewski: ISDN updates
- Alan Cox: SCSI driver NULL ptr checks
- David Miller: networking updates, exclusive waitqueues nest properly,
SMP i_shared_lock/page_table_lock lock order fix.
- pre2:
- Stephen Rothwell: directory notify could return with the lock held
- Richard Henderson: CLOCKS_PER_SEC on alpha.
- Jeff Garzik: ramfs and highmem: kmap() the page to clear it
- Asit Mallick: enable the APIC in the official order
- Neil Brown: avoid rd deadlock on io_request_lock by using a
private rd-request function. This also avoids unnecessary
request merging at this level.
- Ben LaHaise: vmalloc threadign and overflow fix
- Randy Dunlap: USB updates (plusb driver). PCI cacheline size.
- Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1
- Alan Cox: various (Athlon mmx copy, NULL ptr checks for
scsi_register etc).
- Al Viro: fix /proc permission check security hole.
- Can-Ru Yeou: SiS301 fbcon driver
- Andrew Morton: NMI oopser and kernel page fault punch through
both console_lock and timerlist_lock to make sure it prints out..
- Jeff Garzik: clean up "kmap()" return type (it returns a kernel
virtual address, ie a "void *").
- Jeff Garzik: network driver docs, various one-liners.
- David Miller: add generic "special" flag to page flags, to be
used by architectures as they see fit. Like keeping track of
cache coherency issues.
- David Miller: sparc64 updates, make sparc32 boot again
- Davdi Millner: spel "synchronous" correctly
- David Miller: networking - fix some bridge issues, and correct
IPv6 sysctl entries.
- Dan Aloni: make fork.c use proper macro rather than doing
get_exec_domain() by hand.
- pre1:
- me: make PCMCIA work even in the absense of PCI irq's
- me: add irq mapping capabilities for Cyrix southbridges
- me: make IBMMCA compile right as a module
- me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed.
- Andrea Arkangeli: don't allow people to set security-conscious
bits in mxcsr through ptrace SETFPXREGS.
- Jürgen Fischer: aha152x update
- Andrew Morton, Trond Myklebust: file locking fixes
- me: TLB invalidate race with highmem
- Paul Fulghum: synclink/n_hdlc driver updates
- David Miller: export sysctl_jiffies, and have the proper no-sysctl
version handy
- Neil Brown: RAID driver deadlock and nsfd read access to
execute-only files fix
- Keith Owens: clean up module information passing, remove
"get_module_symbol()".
- Jeff Garzik: network (and other) driver fixes and cleanups
- Andrea Arkangeli: scheduler cleanup.
- Ching-Ling Li: fix ALi sound driver memory leak
- Anton Altaparmakov: upcase fix for NTFS
- Thomas Woller: CS4281 audio update
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 84%]
* Re: [PATCH] Re: test11-pre5
@ 2000-11-14 23:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-14 23:47 UTC (permalink / raw)
To: Dan Aloni; +Cc: Kernel Mailing List
On Wed, 15 Nov 2000, Dan Aloni wrote:
>
> summery: dev_3c501.name shouldn't be NULL, or we get oops
Note that these days "name" is not a pointer at all, but an array, and as
such cannot be NULL any more. Not initializing it will just cause it to be
empty (ie is the same as initializing it to "").
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: test11-pre5
@ 2000-11-14 23:51 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-14 23:51 UTC (permalink / raw)
To: linux-kernel
In article <Pine.LNX.4.21.0011150104250.26856-100000@callisto.yi.org>,
Dan Aloni <karrde@callisto.yi.org> wrote:
>On Tue, 14 Nov 2000, Jeff Garzik wrote:
>
>> Dan Aloni wrote:
>> >
>> > reason: Correct me if I'm wrong, but 3c501.c:init_module() calls
>> > net_init.c:register_netdev(&dev_3c501), which calls strchr(),
>> > {and might also,which might} dereference dev_3c501.name.
>>
>> There is no dereferencing involved, and therefore no problem.
>
>Well, at least I was alertive. Almost a bug fix ;-)
>Is there a special reason why dev->name is not a pointer?
It used to be.
And we used to have an incredible number of bugs with initialization and
with creating these things dynamically. A lot of Space.c was due to
horrible hackery with getting the static allocation right for these
things. Turning it into a plain array got rid of all the hackery, and
saved memory anyway.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Memory management bug
@ 2000-11-15 16:45 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-15 16:45 UTC (permalink / raw)
To: linux-kernel
In article <C1256998.004585F4.00@d12mta07.de.ibm.com>,
> After some trickery with some special hardware feature (storage
>keys) I found out that empty_bad_pmd_table and empty_bad_pte_table have
>been put to the page table quicklists multiple(!) times.
This is definitely bad, and means that something else really bad is
going on.
In fact, I have this fairly strong suspicion that we should just get rid
of the "bad" page tables altogether, and make the stuff that now uses
them BUG() instead.
The whole concept of "bad" page tables comes from very early on in
Linux, when the way the page fault handler worked was that if it ran out
of memory or something else really bad happened, it would insert a dummy
page table entry that was guaranteed to let the CPU continue. That way
the page fault handler was always "successful" from a hardware
standpoint, even if it ended up trying to kill the process.
This used to be required simply because a page fault in kernel space
originally needed to let the process unwind sanely and cleanly.
These days, the requirement that page faults always "succeed" is long
long gone. The exception handling mechanism handles the cases where we
validly can take a page fault, and in other cases we will just kill the
process outright. As such, the bad page tables should no longer be
needed, and are apparently just hiding some nasty bugs.
What happens if you just replace all places that would use a bad page
table with a BUG()? (Ie do _not_ add the bug to the place where you
added the test: by that time it's too late. I'm talking about the
places where the bad page tables are used, like in the error cases of
"get_pte_kernel_slow()" etc.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: BUG: isofs broken (2.2 and 2.4)
@ 2000-11-16 0:52 99% ` Linus Torvalds
2000-11-16 1:16 88% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 0:52 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Harald Koenig, emoenke, eric, linux-kernel
On Thu, 16 Nov 2000, Andries Brouwer wrote:
>
> Has there been a kernel version that could read these?
> It looks like it proclaims blocksize 512 and uses blocksize 2048 or so.
The (de_len == 0) check in do_isofs_readdir() seems to imply that the
blocksize is always 2048. So at the very least something is inconsistent.
We use ISOFS_BUFFER_SIZE(inode) (512 in this case) for some sector sizes,
and then ISOFS_BLOCK_SIZE (2048) for others.
But the way isofs_bmap() works, we need to work with
ISOFS_BUFFER_SIZE(inode). And I don't know if directories are always
_aligned_ at 2048 bytes even if they should be blocked at 2k.
Looking at the isofs lookup() logic, it will actually handle split
entries, instead of complaining about them. And I suspect readdir() did
too at some point, and the code was just removed (probably due to
excessive confusion) when one of the many readdir() reorganizations was
done.
readdir() probably worked a long time ago.
Is the thing documented somewhere? It looks like we should just allow
entries that are split and not complain about them. We have the temporary
buffer for it already..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: BUG: isofs broken (2.2 and 2.4)
2000-11-16 0:52 99% ` Linus Torvalds
@ 2000-11-16 1:16 88% ` Linus Torvalds
2000-11-16 1:33 99% ` Linus Torvalds
1 sibling, 1 reply; 200+ results
From: Linus Torvalds @ 2000-11-16 1:16 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Harald Koenig, emoenke, eric, linux-kernel
Does this patch fix it for you?
Warning: TOTALLY UNTESTED!!! Please test carefully.
Also, I'd be interested to know whether somebody really knows if the zero
length handling is correct. Should we really round up to 2048, or should
we perhaps round up only to the next bufsize?
Linus
-----
--- v2.4.0-test10/linux/fs/isofs/dir.c Fri Aug 11 14:29:01 2000
+++ linux/fs/isofs/dir.c Wed Nov 15 17:14:26 2000
@@ -94,6 +94,14 @@
return retnamlen;
}
+static struct buffer_head *isofs_bread(struct inode *inode, unsigned int bufsize, unsigned int block)
+{
+ unsigned int blknr = isofs_bmap(inode, block);
+ if (!blknr)
+ return NULL;
+ return bread(inode->i_dev, blknr, bufsize);
+}
+
/*
* This should _really_ be cleaned up some day..
*/
@@ -105,7 +113,7 @@
unsigned char bufbits = ISOFS_BUFFER_BITS(inode);
unsigned int block, offset;
int inode_number = 0; /* Quiet GCC */
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int len;
int map;
int high_sierra;
@@ -117,46 +125,25 @@
return 0;
offset = filp->f_pos & (bufsize - 1);
- block = isofs_bmap(inode, filp->f_pos >> bufbits);
+ block = filp->f_pos >> bufbits;
high_sierra = inode->i_sb->u.isofs_sb.s_high_sierra;
- if (!block)
- return 0;
-
- if (!(bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size)))
- return 0;
-
while (filp->f_pos < inode->i_size) {
int de_len;
-#ifdef DEBUG
- printk("Block, offset, f_pos: %x %x %x\n",
- block, offset, filp->f_pos);
- printk("inode->i_size = %x\n",inode->i_size);
-#endif
- /* Next directory_record on next CDROM sector */
- if (offset >= bufsize) {
-#ifdef DEBUG
- printk("offset >= bufsize\n");
-#endif
- brelse(bh);
- offset = 0;
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size);
+
+ if (!bh) {
+ bh = isofs_bread(inode, bufsize, block);
if (!bh)
return 0;
- continue;
}
de = (struct iso_directory_record *) (bh->b_data + offset);
- if(first_de) inode_number = (block << bufbits) + (offset & (bufsize - 1));
+ if (first_de) inode_number = (block << bufbits) + (offset & (bufsize - 1));
de_len = *(unsigned char *) de;
#ifdef DEBUG
printk("de_len = %d\n", de_len);
-#endif
-
+#endif
/* If the length byte is zero, we should move on to the next
CDROM sector. If we are at the end of the directory, we
@@ -164,36 +151,36 @@
if (de_len == 0) {
brelse(bh);
- filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
+ bh = NULL;
+ filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1)) + ISOFS_BLOCK_SIZE);
+ block = filp->f_pos >> bufbits;
offset = 0;
-
- if (filp->f_pos >= inode->i_size)
- return 0;
-
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size);
- if (!bh)
- return 0;
continue;
}
- offset += de_len;
+ offset += de_len;
+ if (offset == bufsize) {
+ offset = 0;
+ block++;
+ brelse(bh);
+ bh = NULL;
+ }
+
+ /* Make sure we have a full directory entry */
if (offset > bufsize) {
- /*
- * This would only normally happen if we had
- * a buggy cdrom image. All directory
- * entries should terminate with a null size
- * or end exactly at the end of the sector.
- */
- printk("next_offset (%x) > bufsize (%lx)\n",
- offset,bufsize);
- break;
+ int slop = bufsize - offset + de_len;
+ memcpy(tmpde, de, slop);
+ offset &= bufsize - 1;
+ block++;
+ brelse(bh);
+ bh = isofs_bread(inode, bufsize, block);
+ if (!bh)
+ return 0;
+ memcpy((void *) tmpde + slop, bh->b_data, de_len - slop);
+ de = tmpde;
}
- if(de->flags[-high_sierra] & 0x80) {
+ if (de->flags[-high_sierra] & 0x80) {
first_de = 0;
filp->f_pos += de_len;
continue;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 88%]
* Re: BUG: isofs broken (2.2 and 2.4)
2000-11-16 1:16 88% ` Linus Torvalds
@ 2000-11-16 1:33 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 1:33 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Harald Koenig, emoenke, eric, linux-kernel
On Wed, 15 Nov 2000, Linus Torvalds wrote:
>
> Does this patch fix it for you?
>
> Warning: TOTALLY UNTESTED!!! Please test carefully.
Ok, I tested it with the broken image.
It looks like "readdir()" is ok now (but not really knowing what the right
output should be I cannot guarantee that). HOWEVER, doing an "ls -l" on
some of the files gets ENOENT, implying that "lookup()" still has some
problems with the image.
I suspect the code to handle split entries in isofs_find_entry() has some
simple bug, but I'm too lazy to check it out right now. Anybody else
willing to finish this one off?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: BUG: isofs broken (2.2 and 2.4)
@ 2000-11-16 2:31 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 2:31 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: aeb, emoenke, eric, koenig, linux-kernel
On Thu, 16 Nov 2000 Andries.Brouwer@cwi.nl wrote:
>
> If noone else does, I suppose I can.
Thanks.
>
> (> .. gets ENOENT ..
> and that is not because it only is a partial image?)
I don't think so, but I obviously have no way of actually confirming my
suspicion.
If the stat information was wrong due to the partial image, the lookup
should still have succeeded (the directory entries certainly were there -
otherwise they'd not have shown up in readdir), and we would just have
gotten garbage inode information etc. I think.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [BUG] Inconsistent behaviour of rmdir
@ 2000-11-16 15:49 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 15:49 UTC (permalink / raw)
To: Jean-Marc Saffroy; +Cc: viro, linux-kernel, Eric Paire
On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:
>
> As you see, it looks like the rmdir fails simply because the dir name ends
> with a dot !! This is confirmed by sys_rmdir in fs/namei.c, around line
> 1384 :
>
> switch(nd.last_type) {
> case LAST_DOTDOT:
> error = -ENOTEMPTY;
> goto exit1;
> case LAST_ROOT: case LAST_DOT:
> error = -EBUSY;
> goto exit1;
> }
>
> Should we rip off the offending "case LAST_DOT" ? Or do we need a smarter
> patch ? Is it really a problem that a process has its current directory
> deleted ? How about the root ?
The cwd is not the problem. The '.' is.
The reason for that check is that allowing "rmdir(".")" confuses a lot of
UNIX programs, because it wasn't traditionally allowed.
> The man page for rmdir(2) should be updated as well, the current one
> states :
> EBUSY pathname is the current working directory or root
> directory of some process.
That's definitely wrong. You can do
rmdir `pwd`
and that's fine (not all filesystems will let you do that, but that's a
low-level filesystem issue). It's really only the special names "." and
".." that cannot be removed.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Memory management bug
@ 2000-11-16 17:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 17:01 UTC (permalink / raw)
To: schwidefsky; +Cc: mingo, linux-kernel
On Thu, 16 Nov 2000 schwidefsky@de.ibm.com wrote:
>
> Ok, the BUG() hit in get_pmd_slow:
>
> pmd_t *
> get_pmd_slow(pgd_t *pgd, unsigned long offset)
> {
> pmd_t *pmd;
> int i;
>
> pmd = (pmd_t *) __get_free_pages(GFP_KERNEL,2);
You really need 4 pages?
There's no way to reliably get 4 consecutive pages when you're even close
to being low on memory. I would suggest just failing with a NULL return
here.
What is the architecture setup for this machine? I have no clue about
S/390 memory management. Maybe you can modify the pmd layout?
One potential fix for this is to just make the page size bigger. Make
"Linux pages" be _two_ hardware pages, and make a Linux pte contain two
"hardware pte's". That way the pmd would be an order-1 allocation instead
of an order-2 one. Which is statistically _much_ more likely to be around
(exponential distribution).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Memory management bug
@ 2000-11-16 18:07 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 18:07 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: schwidefsky, mingo, linux-kernel
On Thu, 16 Nov 2000, Andrea Arcangeli wrote:
>
> If they absolutely needs 4 pages for pmd pagetables due hardware constraints
> I'd recommend to use _four_ hardware pages for each softpage, not two.
Yes.
However, it definitely is an issue of making trade-offs. Most 64-bit MMU
models tend to have some flexibility in how you set up the page tables,
and it may be possible to just move bits around too (ie making both the
pmd and the pgd twice as large, and getting the expansion of 4 by doing
two expand-by-two's, for example, if the hardware has support for doing
things like that).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: PATCH: 8139too kernel thread
@ 2000-11-16 18:10 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 18:10 UTC (permalink / raw)
To: Alexander Viro; +Cc: Alan Cox, Jeff Garzik, linux-kernel, netdev
On Thu, 16 Nov 2000, Alexander Viro wrote:
>
> On Thu, 16 Nov 2000, Alan Cox wrote:
>
> > > The only disadvantage to this scheme is the added cost of a kernel
> > > thread over a kernel timer. I think this is an ok cost, because this
> > > is a low-impact thread that sleeps a lot..
> >
> > 8K of memory, two tlb flushes, cache misses on the scheduler. The price is
> ^^^^^^^^^^^^^^^
> > actually extremely high.
>
> <confused>
> Does it really need non-lazy TLB?
If Alan wants to back-port it into 2.2.x, the lazy tlb won't work.
But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by
far is probably the locking needed for the scheduler etc, and there the
best rule of thumb is probably to see whether the driver really ends up
being noticeably simpler.
The event stuff that we are discussing for pcmcia may make all of this
moot, maybe media selection is the perfect example of how to do the very
same thing. I'll forward Jeff the emails on that.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH (2.4)] atomic use count for proc_dir_entry
@ 2000-11-16 21:14 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-16 21:14 UTC (permalink / raw)
To: Dan Aloni; +Cc: linux-kernel
On Thu, 16 Nov 2000, Dan Aloni wrote:
>
> Makes procfs use an atomic use count for dir entries, to avoid using
> the Big kernel lock. Axboe says it looks ok.
There's a race there. Look at what happens if de_put() races with
remove_proc_entry(): we'd do free_proc_entry() twice. Not good.
Leave the kernel lock for now.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test11-pre6
@ 2000-11-17 2:33 80% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 2:33 UTC (permalink / raw)
To: Kernel Mailing List
The log-file says it all..
Linus
-----
- pre6:
- Intel: start to add Pentium IV specific stuff (128-byte cacheline
etc)
- David Miller: search-and-destroy places that forget to mark us
running after removing us from a wait-queue.
- me: NFS client write-back ref-counting SMP instability.
- me: fix up non-exclusive waiters
- Trond Myklebust: Be more careful about SMP in NFS and RPC code
- Trond Myklebust: inode attribute update race fix
- Charles White: don't do unaligned accesses in cpqarray driver.
- Jeff Garzik: continued driver cleanup and fixes
- Peter Anvin: integrate more of the Intel patches.
- Robert Love: add i815 signature to the intel AGP support
- Rik Faith: DRM update to make it easier to sync up 2.2.x
- David Woodhouse: make old 16-bit pcmcia controllers work
again (ie i82365 and TCIC)
- pre5:
- Rasmus Andersen: add proper "<linux/init.h>" for sound drivers
- David Miller: sparc64 and networking updates
- David Trcka: MOXA numbering starts from 0, not 1.
- Jeff Garzik: sysctl.h standalone
- Dag Brattli: IrDA finishing touches
- Randy Dunlap: USB fixes
- Gerd Knorr: big bttv update
- Peter Anvin: x86 capabilities cleanup
- Stephen Rothwell: apm initcall fix - smp poweroff should work
- Andrew Morton: setscheduler() spinlock ordering fix
- Stephen Rothwell: directory notification documentation
- Petr Vandrovec: ncpfs capabilities check cleanup
- David Woodhouse: fix jffs to use generic isxxxx() library
- Chris Swiedler: oom_kill selection fix
- Jens Axboe: re-merge after sleeping in ll_rw_block.
- Randy Dunlap: USB updates (pegasus and ftdi_sio)
- Kai Germaschewski: ISDN ppp header compression fixed
- pre4:
- Andrea Arcangeli: SMP scheduler memory barrier fixup
- Richard Henderson: fix alpha semaphores and spinlock bugs.
- Richard Henderson: clean up the file from hell: "xor.c"
- pre3:
- James Simmons: vgacon "printk()" deadlock with global irq lock.
- don't poke blanked console on console output
- Ching-Ling: get channels right on ALI audio driver
- Dag Brattli and Jean Tourrilhes: big IrDA update
- Paul Mackerras: PPC updates
- Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin
serial converter.
- Jeff Garzik: pcnet32 and lance net driver fix/cleanup
- Mikael Pettersson: clean up x86 ELF_PLATFORM
- Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and
cleanups
- Al Viro: Jeff missed some kmap()'s. sysctl cleanup
- Kai Germaschewski: ISDN updates
- Alan Cox: SCSI driver NULL ptr checks
- David Miller: networking updates, exclusive waitqueues nest properly,
SMP i_shared_lock/page_table_lock lock order fix.
- pre2:
- Stephen Rothwell: directory notify could return with the lock held
- Richard Henderson: CLOCKS_PER_SEC on alpha.
- Jeff Garzik: ramfs and highmem: kmap() the page to clear it
- Asit Mallick: enable the APIC in the official order
- Neil Brown: avoid rd deadlock on io_request_lock by using a
private rd-request function. This also avoids unnecessary
request merging at this level.
- Ben LaHaise: vmalloc threadign and overflow fix
- Randy Dunlap: USB updates (plusb driver). PCI cacheline size.
- Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1
- Alan Cox: various (Athlon mmx copy, NULL ptr checks for
scsi_register etc).
- Al Viro: fix /proc permission check security hole.
- Can-Ru Yeou: SiS301 fbcon driver
- Andrew Morton: NMI oopser and kernel page fault punch through
both console_lock and timerlist_lock to make sure it prints out..
- Jeff Garzik: clean up "kmap()" return type (it returns a kernel
virtual address, ie a "void *").
- Jeff Garzik: network driver docs, various one-liners.
- David Miller: add generic "special" flag to page flags, to be
used by architectures as they see fit. Like keeping track of
cache coherency issues.
- David Miller: sparc64 updates, make sparc32 boot again
- Davdi Millner: spel "synchronous" correctly
- David Miller: networking - fix some bridge issues, and correct
IPv6 sysctl entries.
- Dan Aloni: make fork.c use proper macro rather than doing
get_exec_domain() by hand.
- pre1:
- me: make PCMCIA work even in the absense of PCI irq's
- me: add irq mapping capabilities for Cyrix southbridges
- me: make IBMMCA compile right as a module
- me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed.
- Andrea Arkangeli: don't allow people to set security-conscious
bits in mxcsr through ptrace SETFPXREGS.
- Jürgen Fischer: aha152x update
- Andrew Morton, Trond Myklebust: file locking fixes
- me: TLB invalidate race with highmem
- Paul Fulghum: synclink/n_hdlc driver updates
- David Miller: export sysctl_jiffies, and have the proper no-sysctl
version handy
- Neil Brown: RAID driver deadlock and nsfd read access to
execute-only files fix
- Keith Owens: clean up module information passing, remove
"get_module_symbol()".
- Jeff Garzik: network (and other) driver fixes and cleanups
- Andrea Arkangeli: scheduler cleanup.
- Ching-Ling Li: fix ALi sound driver memory leak
- Anton Altaparmakov: upcase fix for NTFS
- Thomas Woller: CS4281 audio update
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 80%]
* Re: [PATCH] pcmcia event thread. (fwd)
@ 2000-11-17 16:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 16:17 UTC (permalink / raw)
To: Russell King
Cc: Alan Cox, Jeff Garzik, David Woodhouse, David Hinds, tytso, linux-kernel
On Fri, 17 Nov 2000, Russell King wrote:
> Alan Cox writes:
> > >From a practical point of view that currently means 'delete Linus tree pcmcia
> > regardless of what you are doing' since the modules from David Hinds and Linus
> > pcmcia are not 100% binary compatible for all cases.
>
> However, deleting that code would render a significant number of ARM platforms
> without PCMCIA support, which would be real bad.
Right now, I suspect that the in-kernel pcmcia code is actually at the
point where it _is_ possible to use it. David Hinds has been keeping the
cs layer in synch with the external versions, and tons of people have
helped make the low-level drivers stable again.
If somebody still has a problem with the in-kernel stuff, speak up.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] pcmcia event thread. (fwd)
@ 2000-11-17 16:21 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 16:21 UTC (permalink / raw)
To: Alan Cox
Cc: Russell King, Jeff Garzik, David Woodhouse, David Hinds, tytso,
linux-kernel
On Fri, 17 Nov 2000, Alan Cox wrote:
> > > regardless of what you are doing' since the modules from David Hinds and Linus
> > > pcmcia are not 100% binary compatible for all cases.
> >
> > However, deleting that code would render a significant number of ARM platforms
> > without PCMCIA support, which would be real bad.
>
> It would actually have made no difference as said code didnt actually work
> anyway. Dwmw2 seems to have solved that
Alan, Russell is talking about CardBus controllers (it's also PCMCIA, in
fact, these days it's the _only_ pcmcia in any machine made less than five
years ago).
The patches to get i82365 and TCIC up and running again are interesting
mainly for laptops with i486 CPUs and for desktops with pcmcia add-in
cards (which are basically always ISA i82365-clones). They aren't
interesting to ARM, I suspect.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] pcmcia event thread. (fwd)
@ 2000-11-17 16:35 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 16:35 UTC (permalink / raw)
To: Alan Cox
Cc: Russell King, Jeff Garzik, David Woodhouse, David Hinds, tytso,
linux-kernel
On Fri, 17 Nov 2000, Alan Cox wrote:
> > Alan, Russell is talking about CardBus controllers (it's also PCMCIA, in
> > fact, these days it's the _only_ pcmcia in any machine made less than five
> > years ago).
>
> I have at least two machines here that are < 2 years old but disagree
> with you. Once is only months old.
Who makes those pieces of crap? And who _buys_ them? I can understand it
in embedded stuff simply because the chips are simpler and smaller, but in
a laptop you should definitely try to avoid it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Memory management bug
@ 2000-11-17 16:42 98% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 16:42 UTC (permalink / raw)
To: schwidefsky; +Cc: Andrea Arcangeli, mingo, linux-kernel
On Fri, 17 Nov 2000 schwidefsky@de.ibm.com wrote:
>
> >> Whats the reasoning behind these ifs ?
> >
> >To catch memory corruption or things running out of control in the kernel.
> I was refering to the "if (!order) goto try_again" ifs in alloc_pages, not
> the "if (something) BUG()" ifs.
Basically, if you try to wait for orders > 0, you may have to wait for a
LOONG time.
It actually works reasonably well on machines with big memories, because a
buddy allocator _will_ try to coalesce memory allocations as much as
possible. But it has nasty cases where you can be really unlucky. Feel
free to run simulations to see, but basically if you have reasonably
random allocation and free patterns and you want to get an order-X
contiguous allocation, you may have to free up a noticeable portion of
your memory before it succeeds.
Sure, you could do "directed freeing", where you actually try to look at
which pages would be worth freeing to find a large free area, but the
complexity is not insignificant, and quite frankly the proper approach has
always been "don't do that then". Don't rely on big contiguous chunks of
memory. Having an mm that can guarantee contiguous chunks of physical
memory would be cool, but I suspect strongly that it would have some
serious downsides.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 98%]
* Re: [PATCH] pcmcia event thread. (fwd)
@ 2000-11-17 16:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 16:47 UTC (permalink / raw)
To: Jeff Garzik
Cc: David Woodhouse, Russell King, Alan Cox, David Hinds, tytso,
linux-kernel
On Fri, 17 Nov 2000, Jeff Garzik wrote:
> >
> > 2. Even when I specify cs_irq=27, it resorts to polling:
> >
> > Intel PCIC probe:
> > Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets
> > host opts [0]: none
> > host opts [1]: none
> > ISA irqs (default) = none! polling interval = 1000 ms
> > Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x80, 2 sockets
> > host opts [2]: none
> > host opts [3]: none
> > ISA irqs (default) = none! polling interval = 1000 ms
>
> For these two, it sounds to me like you need to be doing a PCI probe,
> and getting the irq and I/O port info from pci_dev. And calling
> pci_enable_device, which may or may not be a showstopper here...
The i82365 stuff actually used to do much of this, but it was so
intimately intertwined with the cardbus handling that I pruned it out for
my sanity.
It should be possible to do the same thing with a nice simple concentrated
PCI probe, instead of having stuff quite as spread out as it used to be.
As to why it doesn't show any ISA interrupts, who knows... Some of the PCI
PCMCIA bridges need to be initialized.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: BUG: isofs broken (2.2 and 2.4)
@ 2000-11-17 22:29 66% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 22:29 UTC (permalink / raw)
To: Harald Koenig; +Cc: Andries.Brouwer, aeb, emoenke, eric, kobras, linux-kernel
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> this seems to make things much worse: starting with ~90M free memory
> "du" again started leaking (or maybe just using memory?) down to ~80M free
> memory when the system suddently locked up completely, no console switch
> was possible anymore (but Sysrq-B did reboot).
How about this version (full patch against test10 - it includes a
slightly corrected version of my earlier dir.c patch)?
It's entirely untested, but it looks good and compiles. Ship it!
Linus
-----
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/dir.c linux/fs/isofs/dir.c
--- v2.4.0-test10/linux/fs/isofs/dir.c Fri Aug 11 14:29:01 2000
+++ linux/fs/isofs/dir.c Fri Nov 17 13:38:01 2000
@@ -94,6 +94,14 @@
return retnamlen;
}
+static struct buffer_head *isofs_bread(struct inode *inode, unsigned int bufsize, unsigned int block)
+{
+ unsigned int blknr = isofs_bmap(inode, block);
+ if (!blknr)
+ return NULL;
+ return bread(inode->i_dev, blknr, bufsize);
+}
+
/*
* This should _really_ be cleaned up some day..
*/
@@ -105,7 +113,7 @@
unsigned char bufbits = ISOFS_BUFFER_BITS(inode);
unsigned int block, offset;
int inode_number = 0; /* Quiet GCC */
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int len;
int map;
int high_sierra;
@@ -117,46 +125,25 @@
return 0;
offset = filp->f_pos & (bufsize - 1);
- block = isofs_bmap(inode, filp->f_pos >> bufbits);
+ block = filp->f_pos >> bufbits;
high_sierra = inode->i_sb->u.isofs_sb.s_high_sierra;
- if (!block)
- return 0;
-
- if (!(bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size)))
- return 0;
-
while (filp->f_pos < inode->i_size) {
int de_len;
-#ifdef DEBUG
- printk("Block, offset, f_pos: %x %x %x\n",
- block, offset, filp->f_pos);
- printk("inode->i_size = %x\n",inode->i_size);
-#endif
- /* Next directory_record on next CDROM sector */
- if (offset >= bufsize) {
-#ifdef DEBUG
- printk("offset >= bufsize\n");
-#endif
- brelse(bh);
- offset = 0;
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size);
+
+ if (!bh) {
+ bh = isofs_bread(inode, bufsize, block);
if (!bh)
return 0;
- continue;
}
de = (struct iso_directory_record *) (bh->b_data + offset);
- if(first_de) inode_number = (block << bufbits) + (offset & (bufsize - 1));
+ if (first_de) inode_number = (bh->b_blocknr << bufbits) + offset;
de_len = *(unsigned char *) de;
#ifdef DEBUG
printk("de_len = %d\n", de_len);
-#endif
-
+#endif
/* If the length byte is zero, we should move on to the next
CDROM sector. If we are at the end of the directory, we
@@ -164,36 +151,33 @@
if (de_len == 0) {
brelse(bh);
- filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
+ bh = NULL;
+ filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1)) + ISOFS_BLOCK_SIZE);
+ block = filp->f_pos >> bufbits;
offset = 0;
-
- if (filp->f_pos >= inode->i_size)
- return 0;
-
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size);
- if (!bh)
- return 0;
continue;
}
- offset += de_len;
- if (offset > bufsize) {
- /*
- * This would only normally happen if we had
- * a buggy cdrom image. All directory
- * entries should terminate with a null size
- * or end exactly at the end of the sector.
- */
- printk("next_offset (%x) > bufsize (%lx)\n",
- offset,bufsize);
- break;
+ offset += de_len;
+
+ /* Make sure we have a full directory entry */
+ if (offset >= bufsize) {
+ int slop = bufsize - offset + de_len;
+ memcpy(tmpde, de, slop);
+ offset &= bufsize - 1;
+ block++;
+ brelse(bh);
+ bh = NULL;
+ if (offset == bufsize) {
+ bh = isofs_bread(inode, bufsize, block);
+ if (!bh)
+ return 0;
+ memcpy((void *) tmpde + slop, bh->b_data, de_len - slop);
+ }
+ de = tmpde;
}
- if(de->flags[-high_sierra] & 0x80) {
+ if (de->flags[-high_sierra] & 0x80) {
first_de = 0;
filp->f_pos += de_len;
continue;
@@ -265,7 +249,7 @@
continue;
}
- brelse(bh);
+ if (bh) brelse(bh);
return 0;
}
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/namei.c linux/fs/isofs/namei.c
--- v2.4.0-test10/linux/fs/isofs/namei.c Mon May 10 14:14:28 1999
+++ linux/fs/isofs/namei.c Fri Nov 17 14:22:33 2000
@@ -49,6 +49,15 @@
return dentry->d_op->d_compare(dentry, &dentry->d_name, &qstr);
}
+static struct buffer_head *isofs_bread(struct inode *inode, unsigned int bufsize, unsigned int block)
+{
+ unsigned int blknr = isofs_bmap(inode, block);
+ if (!blknr)
+ return NULL;
+ return bread(inode->i_dev, blknr, bufsize);
+}
+
+
/*
* isofs_find_entry()
*
@@ -57,129 +66,82 @@
* itself (as an inode number). It does NOT read the inode of the
* entry - you'll have to do that yourself if you want to.
*/
-static struct buffer_head *
-isofs_find_entry(struct inode *dir, struct dentry *dentry, unsigned long *ino)
+static unsigned long
+isofs_find_entry(struct inode *dir, struct dentry *dentry,
+ char * tmpname, struct iso_directory_record * tmpde)
{
+ unsigned long inode_number;
unsigned long bufsize = ISOFS_BUFFER_SIZE(dir);
unsigned char bufbits = ISOFS_BUFFER_BITS(dir);
- unsigned int block, i, f_pos, offset,
- inode_number = 0; /* shut gcc up */
- struct buffer_head * bh , * retval = NULL;
- unsigned int old_offset;
- int dlen, match;
- char * dpnt;
- unsigned char *page = NULL;
- struct iso_directory_record * de = NULL; /* shut gcc up */
- char de_not_in_buf = 0; /* true if de is in kmalloc'd memory */
- char c;
-
- *ino = 0;
-
- if (!(block = dir->u.isofs_i.i_first_extent)) return NULL;
+ unsigned int block, f_pos, offset;
+ struct buffer_head * bh = NULL;
+
+ if (!dir->u.isofs_i.i_first_extent)
+ return 0;
f_pos = 0;
+ offset = 0;
+ block = 0;
- offset = f_pos & (bufsize - 1);
- block = isofs_bmap(dir,f_pos >> bufbits);
+ while (f_pos < dir->i_size) {
+ struct iso_directory_record * de;
+ int de_len, match, i, dlen;
+ char *dpnt, c;
- if (!block || !(bh = bread(dir->i_dev,block,bufsize))) return NULL;
+ if (!bh) {
+ bh = isofs_bread(dir, bufsize, block);
+ if (!bh)
+ return 0;
+ }
- while (f_pos < dir->i_size) {
+ de = (struct iso_directory_record *) (bh->b_data + offset);
+ inode_number = (bh->b_blocknr << bufbits) + offset;
- /* if de is in kmalloc'd memory, do not point to the
- next de, instead we will move to the next sector */
- if(!de_not_in_buf) {
- de = (struct iso_directory_record *)
- (bh->b_data + offset);
- }
- inode_number = (block << bufbits) + (offset & (bufsize - 1));
-
- /* If byte is zero, or we had to fetch this de past
- the end of the buffer, this is the end of file, or
- time to move to the next sector. Usually 2048 byte
- boundaries. */
-
- if (*((unsigned char *) de) == 0 || de_not_in_buf) {
- if(de_not_in_buf) {
- /* james@bpgc.com: Since we slopped
- past the end of the last buffer, we
- must start some way into the new
- one */
- de_not_in_buf = 0;
- kfree(de);
- f_pos += offset;
- }
- else {
- offset = 0;
- f_pos = ((f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
- }
+ de_len = *(unsigned char *) de;
+ if (!de_len) {
brelse(bh);
bh = NULL;
-
- if (f_pos >= dir->i_size)
- break;
-
- block = isofs_bmap(dir,f_pos>>bufbits);
- if (!block || !(bh = bread(dir->i_dev,block,bufsize)))
- break;
-
- continue; /* Will kick out if past end of directory */
+ f_pos = (f_pos + ISOFS_BLOCK_SIZE) & ~(ISOFS_BLOCK_SIZE - 1);
+ block = f_pos >> bufbits;
+ offset = 0;
+ continue;
}
- old_offset = offset;
- offset += *((unsigned char *) de);
- f_pos += *((unsigned char *) de);
+ offset += de_len;
+ f_pos += de_len;
- /* james@bpgc.com: new code to handle case where the
- directory entry spans two blocks. Usually 1024
- byte boundaries */
+ /* Make sure we have a full directory entry */
if (offset >= bufsize) {
- struct buffer_head *bh_next;
-
- /* james@bpgc.com: read the next block, and
- copy the split de into a newly kmalloc'd
- buffer */
- block = isofs_bmap(dir,f_pos>>bufbits);
- if (!block ||
- !(bh_next = bread(dir->i_dev,block,bufsize)))
- break;
-
- de = (struct iso_directory_record *)
- kmalloc(offset - old_offset, GFP_KERNEL);
- memcpy((char *)de, bh->b_data + old_offset,
- bufsize - old_offset);
- memcpy((char *)de + bufsize - old_offset,
- bh_next->b_data, offset - bufsize);
- brelse(bh_next);
- de_not_in_buf = 1;
- offset -= bufsize;
+ int slop = bufsize - offset + de_len;
+ memcpy(tmpde, de, slop);
+ offset &= bufsize - 1;
+ block++;
+ brelse(bh);
+ bh = NULL;
+ if (offset == bufsize) {
+ bh = isofs_bread(dir, bufsize, block);
+ if (!bh)
+ return 0;
+ memcpy((void *) tmpde + slop, bh->b_data, de_len - slop);
+ }
+ de = tmpde;
}
+
dlen = de->name_len[0];
dpnt = de->name;
- if (dir->i_sb->u.isofs_sb.s_rock ||
- dir->i_sb->u.isofs_sb.s_joliet_level ||
- dir->i_sb->u.isofs_sb.s_mapping == 'n' ||
- dir->i_sb->u.isofs_sb.s_mapping == 'a') {
- if (! page) {
- page = (unsigned char *)
- __get_free_page(GFP_KERNEL);
- if (!page) break;
- }
- }
if (dir->i_sb->u.isofs_sb.s_rock &&
- ((i = get_rock_ridge_filename(de, page, dir)))) {
+ ((i = get_rock_ridge_filename(de, tmpname, dir)))) {
dlen = i;
- dpnt = page;
+ dpnt = tmpname;
#ifdef CONFIG_JOLIET
} else if (dir->i_sb->u.isofs_sb.s_joliet_level) {
- dlen = get_joliet_filename(de, dir, page);
- dpnt = page;
+ dlen = get_joliet_filename(de, dir, tmpname);
+ dpnt = tmpname;
#endif
} else if (dir->i_sb->u.isofs_sb.s_mapping == 'a') {
- dlen = get_acorn_filename(de, page, dir);
- dpnt = page;
+ dlen = get_acorn_filename(de, tmpname, dir);
+ dpnt = tmpname;
} else if (dir->i_sb->u.isofs_sb.s_mapping == 'n') {
for (i = 0; i < dlen; i++) {
c = dpnt[i];
@@ -190,13 +152,13 @@
break;
}
if (c == ';') c = '.';
- page[i] = c;
+ tmpname[i] = c;
}
/* This allows us to match with and without
* a trailing period. */
- if(page[dlen-1] == '.' && dentry->d_name.len == dlen-1)
+ if(tmpname[dlen-1] == '.' && dentry->d_name.len == dlen-1)
dlen--;
- dpnt = page;
+ dpnt = tmpname;
}
/*
* Skip hidden or associated files unless unhide is set
@@ -208,43 +170,32 @@
match = (isofs_cmp(dentry,dpnt,dlen) == 0);
}
if (match) {
- if(inode_number == -1) {
- /* Should only happen for the '..' entry */
- inode_number =
- isofs_lookup_grandparent(dir,
- find_rock_ridge_relocation(de,dir));
- }
- *ino = inode_number;
- retval = bh;
- bh = NULL;
- break;
+ if (bh) brelse(bh);
+ return inode_number;
}
}
- if (page) free_page((unsigned long) page);
if (bh) brelse(bh);
- if(de_not_in_buf)
- kfree(de);
- return retval;
+ return 0;
}
struct dentry *isofs_lookup(struct inode * dir, struct dentry * dentry)
{
unsigned long ino;
- struct buffer_head * bh;
struct inode *inode;
+ struct page *page;
#ifdef DEBUG
printk("lookup: %x %s\n",dir->i_ino, dentry->d_name.name);
#endif
dentry->d_op = dir->i_sb->s_root->d_op;
- bh = isofs_find_entry(dir, dentry, &ino);
+ page = alloc_page(GFP_USER);
+ ino = isofs_find_entry(dir, dentry, page_address(page), 1024 + page_address(page));
+ __free_page(page);
inode = NULL;
- if (bh) {
- brelse(bh);
-
- inode = iget(dir->i_sb,ino);
+ if (ino) {
+ inode = iget(dir->i_sb, ino);
if (!inode)
return ERR_PTR(-EACCES);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 66%]
* Re: BUG: isofs broken (2.2 and 2.4)
@ 2000-11-17 23:46 60% ` Linus Torvalds
2000-11-17 23:53 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 23:46 UTC (permalink / raw)
To: Harald Koenig; +Cc: Andries.Brouwer, aeb, emoenke, eric, kobras, linux-kernel
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> Linus: 0.380u 76.850s 1:19.12 97.6% 0+0k 0+0io 113pf+0w
> Andries: 0.470u 97.220s 1:40.29 97.4% 0+0k 0+0io 112pf+0w
The biggest difference is just the system times and the fact that it's
more efficient coding.
> BUT: there are some obvious bugs in the output of "du" and "find".
> some samples (all file names (should) match the format "xe%03d/xe%03d.%c%c"
> with both %03d being the _same_ number and both %c are in [a-z0-9]).
Yes. There's a silly bug there, now that I've tested it a bit. Basically
the test for stuff that traversed a boundary was wrong.
The whole name conversion code is pretty horrible. It's been written over
the years, and it was doing the same thing with small modifications in
both readdir() and lookup(). I've got a cleaned up version that also
should have the above bug fixed.
Still ready to test? This time I went over the files rather carefully, and
while I've not tested the fixed version I'm getting pretty happy with it.
I'll merge some more of the name translation logic, but before I do that
here's the newest patch..
Linus
-----
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/dir.c linux/fs/isofs/dir.c
--- v2.4.0-test10/linux/fs/isofs/dir.c Fri Aug 11 14:29:01 2000
+++ linux/fs/isofs/dir.c Fri Nov 17 15:43:36 2000
@@ -40,14 +40,17 @@
lookup: isofs_lookup,
};
-static int isofs_name_translate(char * old, int len, char * new)
+int isofs_name_translate(struct iso_directory_record *de, char *new, struct inode *inode)
{
- int i, c;
+ char * old = de->name;
+ int len = de->name_len[0];
+ int i;
for (i = 0; i < len; i++) {
- c = old[i];
+ unsigned char c = old[i];
if (!c)
break;
+
if (c >= 'A' && c <= 'Z')
c |= 0x20; /* lower case */
@@ -74,8 +77,7 @@
{
int std;
unsigned char * chr;
- int retnamlen = isofs_name_translate(de->name,
- de->name_len[0], retname);
+ int retnamlen = isofs_name_translate(de, retname, inode);
if (retnamlen == 0) return 0;
std = sizeof(struct iso_directory_record) + de->name_len[0];
if (std & 1) std++;
@@ -105,7 +107,7 @@
unsigned char bufbits = ISOFS_BUFFER_BITS(inode);
unsigned int block, offset;
int inode_number = 0; /* Quiet GCC */
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int len;
int map;
int high_sierra;
@@ -117,46 +119,22 @@
return 0;
offset = filp->f_pos & (bufsize - 1);
- block = isofs_bmap(inode, filp->f_pos >> bufbits);
+ block = filp->f_pos >> bufbits;
high_sierra = inode->i_sb->u.isofs_sb.s_high_sierra;
- if (!block)
- return 0;
-
- if (!(bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size)))
- return 0;
-
while (filp->f_pos < inode->i_size) {
int de_len;
-#ifdef DEBUG
- printk("Block, offset, f_pos: %x %x %x\n",
- block, offset, filp->f_pos);
- printk("inode->i_size = %x\n",inode->i_size);
-#endif
- /* Next directory_record on next CDROM sector */
- if (offset >= bufsize) {
-#ifdef DEBUG
- printk("offset >= bufsize\n");
-#endif
- brelse(bh);
- offset = 0;
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size);
+
+ if (!bh) {
+ bh = isofs_bread(inode, bufsize, block);
if (!bh)
return 0;
- continue;
}
de = (struct iso_directory_record *) (bh->b_data + offset);
- if(first_de) inode_number = (block << bufbits) + (offset & (bufsize - 1));
+ if (first_de) inode_number = (bh->b_blocknr << bufbits) + offset;
de_len = *(unsigned char *) de;
-#ifdef DEBUG
- printk("de_len = %d\n", de_len);
-#endif
-
/* If the length byte is zero, we should move on to the next
CDROM sector. If we are at the end of the directory, we
@@ -164,36 +142,33 @@
if (de_len == 0) {
brelse(bh);
- filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
+ bh = NULL;
+ filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1)) + ISOFS_BLOCK_SIZE);
+ block = filp->f_pos >> bufbits;
offset = 0;
-
- if (filp->f_pos >= inode->i_size)
- return 0;
-
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size);
- if (!bh)
- return 0;
continue;
}
- offset += de_len;
- if (offset > bufsize) {
- /*
- * This would only normally happen if we had
- * a buggy cdrom image. All directory
- * entries should terminate with a null size
- * or end exactly at the end of the sector.
- */
- printk("next_offset (%x) > bufsize (%lx)\n",
- offset,bufsize);
- break;
+ offset += de_len;
+
+ /* Make sure we have a full directory entry */
+ if (offset >= bufsize) {
+ int slop = bufsize - offset + de_len;
+ memcpy(tmpde, de, slop);
+ offset &= bufsize - 1;
+ block++;
+ brelse(bh);
+ bh = NULL;
+ if (offset) {
+ bh = isofs_bread(inode, bufsize, block);
+ if (!bh)
+ return 0;
+ memcpy((void *) tmpde + slop, bh->b_data, de_len - slop);
+ }
+ de = tmpde;
}
- if(de->flags[-high_sierra] & 0x80) {
+ if (de->flags[-high_sierra] & 0x80) {
first_de = 0;
filp->f_pos += de_len;
continue;
@@ -240,7 +215,7 @@
if (map) {
#ifdef CONFIG_JOLIET
if (inode->i_sb->u.isofs_sb.s_joliet_level) {
- len = get_joliet_filename(de, inode, tmpname);
+ len = get_joliet_filename(de, tmpname, inode);
p = tmpname;
} else
#endif
@@ -249,8 +224,7 @@
p = tmpname;
} else
if (inode->i_sb->u.isofs_sb.s_mapping == 'n') {
- len = isofs_name_translate(de->name,
- de->name_len[0], tmpname);
+ len = isofs_name_translate(de, tmpname, inode);
p = tmpname;
} else {
p = de->name;
@@ -265,7 +239,7 @@
continue;
}
- brelse(bh);
+ if (bh) brelse(bh);
return 0;
}
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/inode.c linux/fs/isofs/inode.c
--- v2.4.0-test10/linux/fs/isofs/inode.c Tue Jul 18 21:40:47 2000
+++ linux/fs/isofs/inode.c Fri Nov 17 15:15:07 2000
@@ -972,14 +972,24 @@
return 0;
}
+struct buffer_head *isofs_bread(struct inode *inode, unsigned int bufsize, unsigned int block)
+{
+ unsigned int blknr = isofs_bmap(inode, block);
+ if (!blknr)
+ return NULL;
+ return bread(inode->i_dev, blknr, bufsize);
+}
+
static int isofs_readpage(struct file *file, struct page *page)
{
return block_read_full_page(page,isofs_get_block);
}
+
static int _isofs_bmap(struct address_space *mapping, long block)
{
return generic_block_bmap(mapping,block,isofs_get_block);
}
+
static struct address_space_operations isofs_aops = {
readpage: isofs_readpage,
sync_page: block_sync_page,
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/joliet.c linux/fs/isofs/joliet.c
--- v2.4.0-test10/linux/fs/isofs/joliet.c Tue Jul 18 22:48:32 2000
+++ linux/fs/isofs/joliet.c Fri Nov 17 15:29:55 2000
@@ -70,8 +70,7 @@
}
int
-get_joliet_filename(struct iso_directory_record * de, struct inode * inode,
- unsigned char *outname)
+get_joliet_filename(struct iso_directory_record * de, unsigned char *outname, struct inode * inode)
{
unsigned char utf8;
struct nls_table *nls;
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/namei.c linux/fs/isofs/namei.c
--- v2.4.0-test10/linux/fs/isofs/namei.c Mon May 10 14:14:28 1999
+++ linux/fs/isofs/namei.c Fri Nov 17 15:43:19 2000
@@ -57,147 +57,87 @@
* itself (as an inode number). It does NOT read the inode of the
* entry - you'll have to do that yourself if you want to.
*/
-static struct buffer_head *
-isofs_find_entry(struct inode *dir, struct dentry *dentry, unsigned long *ino)
+static unsigned long
+isofs_find_entry(struct inode *dir, struct dentry *dentry,
+ char * tmpname, struct iso_directory_record * tmpde)
{
+ unsigned long inode_number;
unsigned long bufsize = ISOFS_BUFFER_SIZE(dir);
unsigned char bufbits = ISOFS_BUFFER_BITS(dir);
- unsigned int block, i, f_pos, offset,
- inode_number = 0; /* shut gcc up */
- struct buffer_head * bh , * retval = NULL;
- unsigned int old_offset;
- int dlen, match;
- char * dpnt;
- unsigned char *page = NULL;
- struct iso_directory_record * de = NULL; /* shut gcc up */
- char de_not_in_buf = 0; /* true if de is in kmalloc'd memory */
- char c;
-
- *ino = 0;
-
- if (!(block = dir->u.isofs_i.i_first_extent)) return NULL;
+ unsigned int block, f_pos, offset;
+ struct buffer_head * bh = NULL;
+
+ if (!dir->u.isofs_i.i_first_extent)
+ return 0;
f_pos = 0;
+ offset = 0;
+ block = 0;
- offset = f_pos & (bufsize - 1);
- block = isofs_bmap(dir,f_pos >> bufbits);
+ while (f_pos < dir->i_size) {
+ struct iso_directory_record * de;
+ int de_len, match, i, dlen;
+ char *dpnt;
- if (!block || !(bh = bread(dir->i_dev,block,bufsize))) return NULL;
+ if (!bh) {
+ bh = isofs_bread(dir, bufsize, block);
+ if (!bh)
+ return 0;
+ }
- while (f_pos < dir->i_size) {
+ de = (struct iso_directory_record *) (bh->b_data + offset);
+ inode_number = (bh->b_blocknr << bufbits) + offset;
- /* if de is in kmalloc'd memory, do not point to the
- next de, instead we will move to the next sector */
- if(!de_not_in_buf) {
- de = (struct iso_directory_record *)
- (bh->b_data + offset);
- }
- inode_number = (block << bufbits) + (offset & (bufsize - 1));
-
- /* If byte is zero, or we had to fetch this de past
- the end of the buffer, this is the end of file, or
- time to move to the next sector. Usually 2048 byte
- boundaries. */
-
- if (*((unsigned char *) de) == 0 || de_not_in_buf) {
- if(de_not_in_buf) {
- /* james@bpgc.com: Since we slopped
- past the end of the last buffer, we
- must start some way into the new
- one */
- de_not_in_buf = 0;
- kfree(de);
- f_pos += offset;
- }
- else {
- offset = 0;
- f_pos = ((f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
- }
+ de_len = *(unsigned char *) de;
+ if (!de_len) {
brelse(bh);
bh = NULL;
-
- if (f_pos >= dir->i_size)
- break;
-
- block = isofs_bmap(dir,f_pos>>bufbits);
- if (!block || !(bh = bread(dir->i_dev,block,bufsize)))
- break;
-
- continue; /* Will kick out if past end of directory */
+ f_pos = (f_pos + ISOFS_BLOCK_SIZE) & ~(ISOFS_BLOCK_SIZE - 1);
+ block = f_pos >> bufbits;
+ offset = 0;
+ continue;
}
- old_offset = offset;
- offset += *((unsigned char *) de);
- f_pos += *((unsigned char *) de);
+ offset += de_len;
+ f_pos += de_len;
- /* james@bpgc.com: new code to handle case where the
- directory entry spans two blocks. Usually 1024
- byte boundaries */
+ /* Make sure we have a full directory entry */
if (offset >= bufsize) {
- struct buffer_head *bh_next;
-
- /* james@bpgc.com: read the next block, and
- copy the split de into a newly kmalloc'd
- buffer */
- block = isofs_bmap(dir,f_pos>>bufbits);
- if (!block ||
- !(bh_next = bread(dir->i_dev,block,bufsize)))
- break;
-
- de = (struct iso_directory_record *)
- kmalloc(offset - old_offset, GFP_KERNEL);
- memcpy((char *)de, bh->b_data + old_offset,
- bufsize - old_offset);
- memcpy((char *)de + bufsize - old_offset,
- bh_next->b_data, offset - bufsize);
- brelse(bh_next);
- de_not_in_buf = 1;
- offset -= bufsize;
+ int slop = bufsize - offset + de_len;
+ memcpy(tmpde, de, slop);
+ offset &= bufsize - 1;
+ block++;
+ brelse(bh);
+ bh = NULL;
+ if (offset) {
+ bh = isofs_bread(dir, bufsize, block);
+ if (!bh)
+ return 0;
+ memcpy((void *) tmpde + slop, bh->b_data, de_len - slop);
+ }
+ de = tmpde;
}
+
dlen = de->name_len[0];
dpnt = de->name;
- if (dir->i_sb->u.isofs_sb.s_rock ||
- dir->i_sb->u.isofs_sb.s_joliet_level ||
- dir->i_sb->u.isofs_sb.s_mapping == 'n' ||
- dir->i_sb->u.isofs_sb.s_mapping == 'a') {
- if (! page) {
- page = (unsigned char *)
- __get_free_page(GFP_KERNEL);
- if (!page) break;
- }
- }
if (dir->i_sb->u.isofs_sb.s_rock &&
- ((i = get_rock_ridge_filename(de, page, dir)))) {
+ ((i = get_rock_ridge_filename(de, tmpname, dir)))) {
dlen = i;
- dpnt = page;
+ dpnt = tmpname;
#ifdef CONFIG_JOLIET
} else if (dir->i_sb->u.isofs_sb.s_joliet_level) {
- dlen = get_joliet_filename(de, dir, page);
- dpnt = page;
+ dlen = get_joliet_filename(de, dir, tmpname);
+ dpnt = tmpname;
#endif
} else if (dir->i_sb->u.isofs_sb.s_mapping == 'a') {
- dlen = get_acorn_filename(de, page, dir);
- dpnt = page;
+ dlen = get_acorn_filename(de, tmpname, dir);
+ dpnt = tmpname;
} else if (dir->i_sb->u.isofs_sb.s_mapping == 'n') {
- for (i = 0; i < dlen; i++) {
- c = dpnt[i];
- /* lower case */
- if (c >= 'A' && c <= 'Z') c |= 0x20;
- if (c == ';' && i == dlen-2 && dpnt[i+1] == '1') {
- dlen -= 2;
- break;
- }
- if (c == ';') c = '.';
- page[i] = c;
- }
- /* This allows us to match with and without
- * a trailing period. */
- if(page[dlen-1] == '.' && dentry->d_name.len == dlen-1)
- dlen--;
- dpnt = page;
+ dlen = isofs_name_translate(de, tmpname, dir);
+ dpnt = tmpname;
}
+
/*
* Skip hidden or associated files unless unhide is set
*/
@@ -208,43 +148,32 @@
match = (isofs_cmp(dentry,dpnt,dlen) == 0);
}
if (match) {
- if(inode_number == -1) {
- /* Should only happen for the '..' entry */
- inode_number =
- isofs_lookup_grandparent(dir,
- find_rock_ridge_relocation(de,dir));
- }
- *ino = inode_number;
- retval = bh;
- bh = NULL;
- break;
+ if (bh) brelse(bh);
+ return inode_number;
}
}
- if (page) free_page((unsigned long) page);
if (bh) brelse(bh);
- if(de_not_in_buf)
- kfree(de);
- return retval;
+ return 0;
}
struct dentry *isofs_lookup(struct inode * dir, struct dentry * dentry)
{
unsigned long ino;
- struct buffer_head * bh;
struct inode *inode;
+ struct page *page;
#ifdef DEBUG
printk("lookup: %x %s\n",dir->i_ino, dentry->d_name.name);
#endif
dentry->d_op = dir->i_sb->s_root->d_op;
- bh = isofs_find_entry(dir, dentry, &ino);
+ page = alloc_page(GFP_USER);
+ ino = isofs_find_entry(dir, dentry, page_address(page), 1024 + page_address(page));
+ __free_page(page);
inode = NULL;
- if (bh) {
- brelse(bh);
-
- inode = iget(dir->i_sb,ino);
+ if (ino) {
+ inode = iget(dir->i_sb, ino);
if (!inode)
return ERR_PTR(-EACCES);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 60%]
* Re: BUG: isofs broken (2.2 and 2.4)
@ 2000-11-17 23:51 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 23:51 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: koenig, aeb, emoenke, eric, kobras, linux-kernel
On Sat, 18 Nov 2000 Andries.Brouwer@cwi.nl wrote:
>
> But now that you did two-thirds of the job I take it you'll
> also do the third part? It is again precisely the same stuff.
Are you talking about isofs_lookup_grandparent()?
The code is now dead, and has been for a long time actually (as the VFS
layer keeps track of ".." for us these days). Removed.
I'll look at the isofs_read_level3_size() thing. At least that one doesn't
have the name translation crap in it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: BUG: isofs broken (2.2 and 2.4)
2000-11-17 23:46 60% ` Linus Torvalds
@ 2000-11-17 23:53 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-17 23:53 UTC (permalink / raw)
To: Harald Koenig; +Cc: Andries.Brouwer, aeb, emoenke, eric, kobras, linux-kernel
Oh, and sorry - the last patch doesn't contain the (obvious) fixes to the
header files to take some of the calling convention changes into account.
Linus
---
--- v2.4.0-test10/linux/include/linux/iso_fs.h Fri Sep 8 12:52:56 2000
+++ linux/include/linux/iso_fs.h Fri Nov 17 15:52:03 2000
@@ -177,16 +177,17 @@
extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode *);
extern int get_rock_ridge_filename(struct iso_directory_record *, char *, struct inode *);
+extern int isofs_name_translate(struct iso_directory_record *, char *, struct inode *);
extern int find_rock_ridge_relocation(struct iso_directory_record *, struct inode *);
-int get_joliet_filename(struct iso_directory_record *, struct inode *, unsigned char *);
+int get_joliet_filename(struct iso_directory_record *, unsigned char *, struct inode *);
int get_acorn_filename(struct iso_directory_record *, char *, struct inode *);
extern struct dentry *isofs_lookup(struct inode *, struct dentry *);
extern int isofs_get_block(struct inode *, long, struct buffer_head *, int);
extern int isofs_bmap(struct inode *, int);
-extern int isofs_lookup_grandparent(struct inode *, int);
+extern struct buffer_head *isofs_bread(struct inode *, unsigned int, unsigned int);
extern struct inode_operations isofs_dir_inode_operations;
extern struct file_operations isofs_dir_operations;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: BUG: isofs broken (2.2 and 2.4)
@ 2000-11-18 1:21 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2000-11-18 1:21 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: aeb, emoenke, eric, kobras, koenig, linux-kernel
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling it test11 outright.
It's almost guaranteed to be better than what we had before, but anyway..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test11-pre7 compile failure
@ 2000-11-18 3:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 3:38 UTC (permalink / raw)
To: linux-kernel
In article <3A15DDCB.42B0F208@toyota.com>, J Sloan <jjs@toyota.com> wrote:
>
>looks like the md fixes broke something -
>
>In file included from /usr/src/linux/include/linux/pagemap.h:17,
> from /usr/src/linux/include/linux/locks.h:9,
> from /usr/src/linux/include/linux/raid/md.h:37,
> from init/main.c:25:
>/usr/src/linux/include/linux/highmem.h: In function `bh_kmap':
>/usr/src/linux/include/linux/highmem.h:23: structure has no member named
>`p_page'
The "p_page" should be a "b_page". Duh.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Freeze on FPU exception with Athlon
@ 2000-11-18 3:48 99% ` Linus Torvalds
2000-11-18 4:10 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 3:48 UTC (permalink / raw)
To: linux-kernel
In article <20001118014019.18006.qmail@web3404.mail.yahoo.com>,
=?iso-8859-1?q?Markus=20Schoder?= <markus_schoder@yahoo.de> wrote:
>The following small program (linked against glibc 2.1.3) reliably
>freezes my system (Athlon Thunderbird CPU) with at least kernels
>2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
>after the freeze.
Are you sure sysrq doesn't work? Many distributions will disable the
kernel printing to the console, or move it to console 7 or similar.
It would be really good to get the EIP trace of RightAlt+ScrollLock
pressed a few times if you can try to see if you can use klogd to enable
proper printk's.
>Older kernels (e.g. 2.3.40) seem to work. Any Ideas?
The FP exception handling has certainly changed, but the changes should
all have affected mainly just PIII kernels with XMM support enabled. An
Athlon system should have been pretty unaffected. But I'll take a look
if I see something obvious.
One thing to try: if interrupts really don't work for you (and if SysRq
doesn't work, that may be the case), please test out a kernel that
simply ignores irq13 by just commenting out the line
setup_irq(13, &irq13);
in arch/i386/kernel/i8259.c. Does that make any difference? (irq13
shouldn't be used any more, it's horrible legacy crap, but we do want to
support even horrible legacy systems).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Freeze on FPU exception with Athlon
2000-11-18 3:48 99% ` Linus Torvalds
@ 2000-11-18 4:10 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 4:10 UTC (permalink / raw)
To: linux-kernel
In article <20001118014019.18006.qmail@web3404.mail.yahoo.com>,
=?iso-8859-1?q?Markus=20Schoder?= <markus_schoder@yahoo.de> wrote:
>The following small program (linked against glibc 2.1.3) reliably
>freezes my system (Athlon Thunderbird CPU) with at least kernels
>2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
>after the freeze.
>
>Older kernels (e.g. 2.3.40) seem to work. Any Ideas?
It certainly doesn't happen for me on any of the machines I work with,
but it wouldn't compile as-is for me, so I exchanged the FPU setting
with a simpler
asm("fldcw %0": :"m" (0));
which should do the equivalent (ie unmask divide by zero errors). Does
that make a difference for you?
Can you try to figure out where it started happening? Ie try test9 and
back too, to figure out what might be bringing it on...
I sure as hell hope this isn't an Athlon issue. Can other people try
the test-program and see if we have a pattern (ie "it happens only on
Athlons", or "Linus is on drugs and it happens for everybody else").
Thanks,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: BUG: isofs broken (2.2 and 2.4)
@ 2000-11-18 4:50 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 4:50 UTC (permalink / raw)
To: Keith Owens
Cc: Andries.Brouwer, aeb, emoenke, eric, kobras, koenig, linux-kernel
On Sat, 18 Nov 2000, Keith Owens wrote:
> On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
> Linus Torvalds <torvalds@transmeta.com> wrote:
> >There's a test11-pre7 there now, and I'd really ask people to check out
> >the isofs changes because slight worry about those is what held me up from
> >just calling it test11 outright.
> >
> >It's almost guaranteed to be better than what we had before, but anyway..
> >
> > Linus
>
> namei.c: In function `isofs_find_entry':
> namei.c:130: warning: passing arg 2 of `get_joliet_filename' from incompatible pointer type
> namei.c:130: warning: passing arg 3 of `get_joliet_filename' from incompatible pointer type
Thanks. The second and third arguments were switched around to match all
the other filename conversion stuff, and because I don't have joliet
enabled I didn't notice this. Just switch them around where the warning
occurs, and you should be golden.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [patch] potential death in disassociate_ctty()
@ 2000-11-18 5:34 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 5:34 UTC (permalink / raw)
To: linux-kernel
In article <3A15FF3F.9692D272@uow.edu.au>,
Andrew Morton <andrewm@uow.edu.au> wrote:
>
>Also, somewhere on the path from kernel 2.2 to 2.4 the call to
>do_notify_parent() was moved inside the tasklist lock. Why was this?
Ehh.. Because that is also what protects our "parent" pointer.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Please send Changelog info and patch notices for the test and -pre releases.
@ 2000-11-18 15:48 78% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 15:48 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel
On Fri, 17 Nov 2000, Miles Lane wrote:
>
> I haven't seen any announcements of recent test and test-pre releases.
> Can you begin sending those again, please?
You can actually get them off kernel.org these days: Peter Anvin set up a
system whereby when I upload a changelog it automatically gets added to
the web-site (main page, bottom).
Linus
-----
- pre7:
- Kai Germaschewski: more ISDN cleanups and small fixes.
- Al Viro: fix ntfs_new_inode() that he broke. Cleanups.
- various: handle !CONFIG_HOTPLUG properly
- David Miller: sparc and networking
- me: more iso9660 fixes.
- Neil Brown: fix rd and RAID on highmem machines
- Vojtech Pavlik: input driver fixes
- David Woodhouse: module unload races - up_and_exit()
- pre6:
- Intel: start to add Pentium IV specific stuff (128-byte cacheline
etc)
- David Miller: search-and-destroy places that forget to mark us
running after removing us from a wait-queue.
- me: NFS client write-back ref-counting SMP instability.
- me: fix up non-exclusive waiters
- Trond Myklebust: Be more careful about SMP in NFS and RPC code
- Trond Myklebust: inode attribute update race fix
- Charles White: don't do unaligned accesses in cpqarray driver.
- Jeff Garzik: continued driver cleanup and fixes
- Peter Anvin: integrate more of the Intel patches.
- Robert Love: add i815 signature to the intel AGP support
- Rik Faith: DRM update to make it easier to sync up 2.2.x
- David Woodhouse: make old 16-bit pcmcia controllers work
again (ie i82365 and TCIC)
- pre5:
- Rasmus Andersen: add proper "<linux/init.h>" for sound drivers
- David Miller: sparc64 and networking updates
- David Trcka: MOXA numbering starts from 0, not 1.
- Jeff Garzik: sysctl.h standalone
- Dag Brattli: IrDA finishing touches
- Randy Dunlap: USB fixes
- Gerd Knorr: big bttv update
- Peter Anvin: x86 capabilities cleanup
- Stephen Rothwell: apm initcall fix - smp poweroff should work
- Andrew Morton: setscheduler() spinlock ordering fix
- Stephen Rothwell: directory notification documentation
- Petr Vandrovec: ncpfs capabilities check cleanup
- David Woodhouse: fix jffs to use generic isxxxx() library
- Chris Swiedler: oom_kill selection fix
- Jens Axboe: re-merge after sleeping in ll_rw_block.
- Randy Dunlap: USB updates (pegasus and ftdi_sio)
- Kai Germaschewski: ISDN ppp header compression fixed
- pre4:
- Andrea Arcangeli: SMP scheduler memory barrier fixup
- Richard Henderson: fix alpha semaphores and spinlock bugs.
- Richard Henderson: clean up the file from hell: "xor.c"
- pre3:
- James Simmons: vgacon "printk()" deadlock with global irq lock.
- don't poke blanked console on console output
- Ching-Ling: get channels right on ALI audio driver
- Dag Brattli and Jean Tourrilhes: big IrDA update
- Paul Mackerras: PPC updates
- Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin
serial converter.
- Jeff Garzik: pcnet32 and lance net driver fix/cleanup
- Mikael Pettersson: clean up x86 ELF_PLATFORM
- Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and
cleanups
- Al Viro: Jeff missed some kmap()'s. sysctl cleanup
- Kai Germaschewski: ISDN updates
- Alan Cox: SCSI driver NULL ptr checks
- David Miller: networking updates, exclusive waitqueues nest properly,
SMP i_shared_lock/page_table_lock lock order fix.
- pre2:
- Stephen Rothwell: directory notify could return with the lock held
- Richard Henderson: CLOCKS_PER_SEC on alpha.
- Jeff Garzik: ramfs and highmem: kmap() the page to clear it
- Asit Mallick: enable the APIC in the official order
- Neil Brown: avoid rd deadlock on io_request_lock by using a
private rd-request function. This also avoids unnecessary
request merging at this level.
- Ben LaHaise: vmalloc threadign and overflow fix
- Randy Dunlap: USB updates (plusb driver). PCI cacheline size.
- Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1
- Alan Cox: various (Athlon mmx copy, NULL ptr checks for
scsi_register etc).
- Al Viro: fix /proc permission check security hole.
- Can-Ru Yeou: SiS301 fbcon driver
- Andrew Morton: NMI oopser and kernel page fault punch through
both console_lock and timerlist_lock to make sure it prints out..
- Jeff Garzik: clean up "kmap()" return type (it returns a kernel
virtual address, ie a "void *").
- Jeff Garzik: network driver docs, various one-liners.
- David Miller: add generic "special" flag to page flags, to be
used by architectures as they see fit. Like keeping track of
cache coherency issues.
- David Miller: sparc64 updates, make sparc32 boot again
- Davdi Millner: spel "synchronous" correctly
- David Miller: networking - fix some bridge issues, and correct
IPv6 sysctl entries.
- Dan Aloni: make fork.c use proper macro rather than doing
get_exec_domain() by hand.
- pre1:
- me: make PCMCIA work even in the absense of PCI irq's
- me: add irq mapping capabilities for Cyrix southbridges
- me: make IBMMCA compile right as a module
- me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed.
- Andrea Arkangeli: don't allow people to set security-conscious
bits in mxcsr through ptrace SETFPXREGS.
- Jürgen Fischer: aha152x update
- Andrew Morton, Trond Myklebust: file locking fixes
- me: TLB invalidate race with highmem
- Paul Fulghum: synclink/n_hdlc driver updates
- David Miller: export sysctl_jiffies, and have the proper no-sysctl
version handy
- Neil Brown: RAID driver deadlock and nsfd read access to
execute-only files fix
- Keith Owens: clean up module information passing, remove
"get_module_symbol()".
- Jeff Garzik: network (and other) driver fixes and cleanups
- Andrea Arkangeli: scheduler cleanup.
- Ching-Ling Li: fix ALi sound driver memory leak
- Anton Altaparmakov: upcase fix for NTFS
- Thomas Woller: CS4281 audio update
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 78%]
* Re: [PATCH] pcmcia event thread. (fwd)
@ 2000-11-18 16:03 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 16:03 UTC (permalink / raw)
To: David Ford; +Cc: Jeff Garzik, David Hinds, linux-kernel
On Sat, 18 Nov 2000, David Ford wrote:
> Linus Torvalds wrote:
> [...]
>
> > If somebody still has a problem with the in-kernel stuff, speak up.
>
> The kernel's irq detection for the card sockets doesn't work for me. It's the NEC
> Versa LX story. The DH code also reports no IRQ found but still figures out a
> working IRQ (normally 3) and assigns it for the tulip card. I use the i82365 module
> w/ the DH code. The below is the output of the kernel pcmcia code.
> PCI: No IRQ known for interrupt pin B of device 00:03.1. Please try using
> pci=biosirq.
> PCI: No IRQ known for interrupt pin A of device 00:03.0. Please try using
> pci=biosirq.
Strange. Your interrupt router is a bog-standard PIIX4, we know how to
route the thing, AND your device shows up:
> # dump_pirq
> Interrupt routing table found at address 0xf5a80:
> Version 1.0, size 0x0080
> Interrupt router is device 00:07.0
> PCI exclusive interrupt mask: 0x0000
> Compatible router: vendor 0x8086 device 0x1234
>
> Device 00:03.0 (slot 0):
> INTA: link 0x60, irq mask 0x0420
> INTB: link 0x61, irq mask 0x0420
>
> Interrupt router: Intel 82371AB PIIX4/PIIX4E PCI-to-ISA bridge
> PIRQ1 (link 0x60): irq 10
> PIRQ2 (link 0x61): irq 5
> PIRQ3 (link 0x62): unrouted
> PIRQ4 (link 0x63): irq 9
> Serial IRQ: [enabled] [continuous] [frame=21] [pulse=4]
Can you (you've probably done this before, but anyway) enable DEBUG in
arch/i386/kernel/pci-i386.h? I wonder if the kernel for some strange
reason doesn't find your router, even though "dump_pirq" obviously does..
If there's something wrong with the checksumming for example..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Freeze on FPU exception with Athlon
@ 2000-11-18 16:26 94% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 16:26 UTC (permalink / raw)
To: Brian Gerst; +Cc: linux-kernel, Markus Schoder
On Sat, 18 Nov 2000, Brian Gerst wrote:
>
> I get Floating Point Exception (core dumped), but I needed to use the
> modified program below to keep GCC from optimizing the division away as
> a constant. This is on test11-pre5.
I'm starting to suspect that it's really a combination of three things:
- 3dnow optimization (ie you have to compile the kernel with Athlon
support)
- pending, but not yet noticed, FPU exceptions.
- a bug/feature in the kernel, where a process exit does not bother to
clear the FPU, only marks it as "unused".
If I'm right, the proper test-program should be something like
int main(int argc, char **argv)
{
asm("fldcw %0": :"m" (0));
asm("fldz ; fld1 ; fdiv");
sleep(1);
return 0;
}
where it's important that we do not wait for the result of the fdiv, we
just exit after having caused a pending exception (and you cannot do this
reliably from C code - depending on compiler version and optimizations
gcc may try to write the bad value back to memory etc).
Now, with the pending exception, do a 3dnow MMX memcpy() - which will
clear the TS bit (because it decides that the FP state can be thrown
away and doesn't need to do a full save/restore) and start using the FPU.
Boom. Instant FP exception. With the exception handler deciding that
nobody owns the FP state, and thus doing nothing sane.
If I'm right (and I'm _always_ right), the following patch would make a
difference.
Markus?
Linus
----
--- v2.4.0-test10/linux/arch/i386/kernel/traps.c Tue Oct 31 12:42:26 2000
+++ linux/arch/i386/kernel/traps.c Fri Nov 17 21:52:55 2000
@@ -643,6 +640,12 @@
asmlinkage void do_coprocessor_error(struct pt_regs * regs, long error_code)
{
ignore_irq13 = 1;
+
+ /* Due to lazy error handling, we might have false pending errors! */
+ if (!current->used_math) {
+ init_fpu();
+ return;
+ }
math_error((void *)regs->eip);
}
@@ -700,6 +703,12 @@
if (cpu_has_xmm) {
/* Handle SIMD FPU exceptions on PIII+ processors. */
ignore_irq13 = 1;
+
+ /* Due to lazy error handling, we might have false pending errors! */
+ if (!current->used_math) {
+ init_fpu();
+ return;
+ }
simd_math_error((void *)regs->eip);
} else {
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 94%]
* Re: Freeze on FPU exception with Athlon
@ 2000-11-18 18:03 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 18:03 UTC (permalink / raw)
To: Alan Cox; +Cc: Udo A. Steinberg, Linux Kernel
On Sat, 18 Nov 2000, Alan Cox wrote:
> > Linus Torvalds wrote:
> > >
> > > I sure as hell hope this isn't an Athlon issue. Can other people try
> > > the test-program and see if we have a pattern (ie "it happens only on
> > > Athlons", or "Linus is on drugs and it happens for everybody else").
> >
> > I've tried both variants (fesetenv and inline-asm) with glibc-2.1.3,
> > 2.4.0-test11pre7 and an AMD Thunderbird. Neither does freeze, but
> > both yield:
> >
> > Floating point exception (core dumped)
>
> Compiler specific ?
There's almost certainly more than that. I'd love to have a report on my
asm-only version, but even so I suspect it also requires the 3dnow stuff,
because I'm not able to trigger anything like this on any machines I have
access to (none of them are AMD, though)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test11-pre6 still very broken
@ 2000-11-18 18:17 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 18:17 UTC (permalink / raw)
To: linux-kernel
In article <20001117235624.B26341@wirex.com>, Greg KH <greg@wirex.com> wrote:
>On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote:
>> Here is lspci output from the laptop in question. Is this not UHCI?
>
>Yes it is. Just a bit funny if you think about it, but with Intel and
>Via putting the UHCI core into their chipsets I guess it makes sense.
>
>One note for the archives, if you are presented a choice between a OHCI
>or a UHCI controller, go for the OHCI. It has a "cleaner" interface,
>handles more of the logic in the silicon, and due to this provides
>faster transfers.
I'd disagree. UHCI has tons of advantages, not the least of which is
[Cthat it was there first and is widely available. If OHCI hadn't been
done we'd have _one_ nice good USB controller implementation instead of
fighting stupid and unnecessary battles that shouldn't have existed in
the first place.
For example, the UHCI root hub can be controlled without DMA, which
makes it a lot cheaper on the system. When a UHCI system is unconnected
and idle, it doesn't waste cycles on extra memory traffic the way OHCI
does.
UHCI also requires fewer transistors, and is the more common by far
simply because Intel is good at getting their chipsets out.
Basically, the advantages of OHCI are not worth the differentiation, and
are not always advantages at all. Many people think that it is "good"
that the root hub looks more like a regular hub, but that's just wrong.
Especially with faster speeds, the memory pressure of the USB controller
is going to be noticeable, and it would be much preferable if the root
directory of the USB tree would be separated out (and cached in the
controller) by the root hub. The UHCI approach of making the root a bit
special should be taken _further_, and not seen as a mistake.
I hope EHCI makes it all moot. Some way or another.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Re: Freeze on FPU exception with Athlon
@ 2000-11-18 18:38 93% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 18:38 UTC (permalink / raw)
To: Markus Schoder; +Cc: Brian Gerst, linux-kernel, Udo A. Steinberg, Alan Cox
On Sat, 18 Nov 2000, Markus Schoder wrote:
>
> Your test program is indeed sufficient to trigger the
> freeze. Unfortunately the patch does not make a
> difference :(
Ok.
This may in fact be an Athlon CPU bug. But before we contact anybody from
AMD, I'd really need to know what the result from the irq13 disabling and
the non-3dnow thing is.
Considering that Udo reports no lockup at all with the same test-program
even with an Athlon and 3dnow, it looks like it's either irq13 (and a
motherboard routing issue: sane modern motherboards shouldn't even route
the external FERR at _all_ any more), or something stepping-specific on
your Athlon. It doesn't sound kernel-related per se.
Let's hope it's irq13. If so, it will be easy to fix (tentative fix: any
CPU that reports a built-in FPU just doesn't get irq13 enabled at all).
Current workign theory:
- Athlons do FERR wrong. They drive FERR externally when the
unmasked exception happens, rather than when the next FP instruction
actually detects the exception. This means that the external FERR irq13
actually happens _before_ the internal exception 16, which is wrong.
- Linux has seen exception 16 working, so it ignores irq13 and assumes
that it's some real external device (which does happen - sometimes
SCI is wired to irq13).
- irq13 is not only wired on the motherboard (which was right in 1989,
but is not right in 2000), but is marked level-triggered (which
probably wasn't right even in 1989). So when the irq13 happens, it
_keeps_ on happening, and we never get an exception 16 at all.
The reason 2.2.x works on your machine might be that the early bootup test
for FP exceptions will have done something to mask the fpu exception just
by luck. I forget the exact details of the test - it got removed in later
kernels because it made it really nasty to handle XMM faults correctly.
Does anybody have any better ideas?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 93%]
* Re: Freeze on FPU exception with Athlon
@ 2000-11-18 18:43 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-18 18:43 UTC (permalink / raw)
To: adrian; +Cc: Alan Cox, Udo A. Steinberg, Linux Kernel, Markus Schoder
On Sat, 18 Nov 2000, adrian wrote:
>
>
> On Sat, 18 Nov 2000, Linus Torvalds wrote:
>
> > There's almost certainly more than that. I'd love to have a report on my
> > asm-only version, but even so I suspect it also requires the 3dnow stuff,
>
> I tried all three versions, and no freezes. I forgot to mention the tests
> were run on a model 2 Athlon (original slot K7, .18 micron). The kernel
> is compiled with 3dnow support.
Apparently it isn't the stepping, as we have Athlon model 4's both showing
it and not showing it. The motherboard seems to be the only real
difference here, which is why I like the irq13 explanation more and more.
I've been wanting to get rid of irq13 anyway (some boards wire up USB
and/or ACPI to irq13 and the fact that the FPU has claimed it makes those
machines unhappy), so if the solution is to only check for irq13 on old
i386 and i486sx machines and just leave it alone for newer CPU's, I won't
complain.
Markus, can you make the irq13 test the first thing - don't worry about
3dnow as that seems to not be a deciding factor..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] semaphore fairness patch against test11-pre6
@ 2000-11-19 1:47 92% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-19 1:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Rohland, David Mansfield, lkml
On Sun, 19 Nov 2000, Andrew Morton wrote:
>
> Has anyone tried it on SMP? I get fairly repeatable instances of immortal
> `D'-state processes with this patch.
Too bad. I really thought it should be safe to do.
> The patch isn't right - it allows `sleepers' to increase without bound.
> But it's a boolean!
It's not a boolean. It's really a "bias count". It happens to get only the
values 0 and 1 simply becase the logic is that we always account for all
the other people when any process goes to sleep, so "sleepers" only ever
counts the one process that went to sleep last.
But the algorithm itself should allow for other values. In fact, I think
that you'll find that it works fine if you switch to non-exclusive
wait-queues, and the only reason you see the repeatable D states is
exactly the case where we didn't "take" the semaphore even though we were
awake, and that basically makes us an exclusive process that didn't react
to an exclusive wakeup.
(Think of it this way: with the "inside" patch, the process does
tsk->state = TASK_INTERRUPTIBLE;
twice, even though there was only one semaphore that woke it up: we
basically "lost" a wakeup event, not because "sleepers" cannot be 2, but
because we didn't pick up the wakeup that we might have gotten.
Instead of the "goto inside", how about just doing it without the "double
sleep", and doing something like
tsk->state = TASK_INTERRUPTIBLE;
add_wait_queue_exclusive(&sem->wait, &wait);
spin_lock_irq(&semaphore_lock);
sem->sleepers ++;
+ if (sem->sleepers > 1) {
+ spin_unlock_irq(&semaphore_lock);
+ schedule();
+ spin_lock_irq(&semaphore_lock);
+ }
for (;;) {
The only difference between the above and the "goto inside" variant is
really that the above sets "tsk->state = TASK_INTERRUPTIBLE;" just once
per loop, not twice as the "inside" case did. So if we happened to get an
exclusive wakeup at just the right point, we won't go to sleep again and
miss it.
But these things are very subtle. The current semaphore algorithm was
basically perfected over a week of some serious thinking. The fairness
change should similarly get a _lot_ of attention. It's way too easy to
miss things.
Does the above work for you even in SMP?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 92%]
* Re: [PATCH] pcmcia event thread. (fwd)
@ 2000-11-19 5:36 91% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-19 5:36 UTC (permalink / raw)
To: David Ford; +Cc: Jeff Garzik, David Hinds, linux-kernel
On Sat, 18 Nov 2000, David Ford wrote:
> Linus Torvalds wrote:
>
> > Can you (you've probably done this before, but anyway) enable DEBUG in
> > arch/i386/kernel/pci-i386.h? I wonder if the kernel for some strange
> > reason doesn't find your router, even though "dump_pirq" obviously does..
> > If there's something wrong with the checksumming for example..
>
> ..building now.
Actually, try this patch first. It adds the PCI_DEVICE_ID_INTEL_82371MX
router type, and also makes the PCI router search fall back more
gracefully on the device it actually found if there is not an exact match
on the "compatible router" entry...
It should make Linux find and accept the chip you have. Knock wood.
Linus
--- v2.4.0-test10/linux/arch/i386/kernel/pci-irq.c Tue Oct 31 12:42:26 2000
+++ linux/arch/i386/kernel/pci-irq.c Sat Nov 18 21:11:19 2000
@@ -283,12 +297,19 @@
{ "PIIX", PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371FB_0, pirq_piix_get, pirq_piix_set },
{ "PIIX", PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0, pirq_piix_get, pirq_piix_set },
{ "PIIX", PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_0, pirq_piix_get, pirq_piix_set },
+ { "PIIX", PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371MX, pirq_piix_get, pirq_piix_set },
{ "PIIX", PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443MX_0, pirq_piix_get, pirq_piix_set },
+
{ "ALI", PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M1533, pirq_ali_get, pirq_ali_set },
+
{ "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, pirq_via_get, pirq_via_set },
{ "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C596, pirq_via_get, pirq_via_set },
{ "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, pirq_via_get, pirq_via_set },
+
{ "OPTI", PCI_VENDOR_ID_OPTI, PCI_DEVICE_ID_OPTI_82C700, pirq_opti_get, pirq_opti_set },
+
+ { "NatSemi", PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5520, pirq_cyrix_get, pirq_cyrix_set },
+
{ "default", 0, 0, NULL, NULL }
};
@@ -298,7 +319,6 @@
static void __init pirq_find_router(void)
{
struct irq_routing_table *rt = pirq_table;
- u16 rvendor, rdevice;
struct irq_router *r;
#ifdef CONFIG_PCI_BIOS
@@ -308,32 +328,31 @@
return;
}
#endif
- if (!(pirq_router_dev = pci_find_slot(rt->rtr_bus, rt->rtr_devfn))) {
+ /* fall back to default router if nothing else found */
+ pirq_router = pirq_routers + sizeof(pirq_routers) / sizeof(pirq_routers[0]) - 1;
+
+ pirq_router_dev = pci_find_slot(rt->rtr_bus, rt->rtr_devfn);
+ if (!pirq_router_dev) {
DBG("PCI: Interrupt router not found at %02x:%02x\n", rt->rtr_bus, rt->rtr_devfn);
- /* fall back to default router */
- pirq_router = pirq_routers + sizeof(pirq_routers) / sizeof(pirq_routers[0]) - 1;
return;
}
- if (rt->rtr_vendor) {
- rvendor = rt->rtr_vendor;
- rdevice = rt->rtr_device;
- } else {
- /*
- * Several BIOSes forget to set the router type. In such cases, we
- * use chip vendor/device. This doesn't guarantee us semantics of
- * PIRQ values, but was found to work in practice and it's still
- * better than not trying.
- */
- DBG("PCI: Guessed interrupt router ID from %s\n", pirq_router_dev->slot_name);
- rvendor = pirq_router_dev->vendor;
- rdevice = pirq_router_dev->device;
- }
- for(r=pirq_routers; r->vendor; r++)
- if (r->vendor == rvendor && r->device == rdevice)
+
+ for(r=pirq_routers; r->vendor; r++) {
+ /* Exact match against router table entry? Use it! */
+ if (r->vendor == rt->rtr_vendor && r->device == rt->rtr_device) {
+ pirq_router = r;
break;
- pirq_router = r;
- printk("PCI: Using IRQ router %s [%04x/%04x] at %s\n", r->name,
- rvendor, rdevice, pirq_router_dev->slot_name);
+ }
+ /* Match against router device entry? Use it as a fallback */
+ if (r->vendor == pirq_router_dev->vendor && r->device == pirq_router_dev->device) {
+ pirq_router = r;
+ }
+ }
+ printk("PCI: Using IRQ router %s [%04x/%04x] at %s\n",
+ pirq_router->name,
+ pirq_router_dev->vendor,
+ pirq_router_dev->device,
+ pirq_router_dev->slot_name);
}
static struct irq_info *pirq_get_info(struct pci_dev *dev, int pin)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 91%]
* Re: [PATCH] semaphore fairness patch against test11-pre6
@ 2000-11-19 18:46 95% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-19 18:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Rohland, David Mansfield, lkml
On Sun, 19 Nov 2000, Andrew Morton wrote:
>
> I don't see a path where David's patch can cause a lost wakeup in the
> way you describe.
Basically, if there are two up() calls, they might end up waking up only
one process, because the same process goes to sleep twice. That's wrong.
It should wake up two processes.
However, thinking about it more, that's obviously possible only for
semaphores that are used for more than just mutual exclusion, and
basically nobody does that anyway.
> Next step is to move the waitqueue and wakeup operations so they're
> inside the spinlock. Nope. That doesn't work either.
>
> Next step is to throw away the semaphore_lock and use the sem->wait
> lock instead. That _does_ work. This is probably just a
> fluke - it synchronises the waker with the sleepers and we get lucky.
Yes, especially on a two-cpu machine that kind of synchronization can
basically end up hiding real bugs.
I'll think about this some more. One thing I noticed is that the
"wake_up(&sem->wait);" at the end of __down() is kind of bogus: we don't
actually want to wake anybody up at that point at all, it's just that if
we don't wake anybody up we'll end up having "sem = 0, sleeper = 0", and
when we unlock the semaphore the "__up()" logic won't trigger, and we
won't ever wake anybody up. That's just incredibly bogus.
Instead of the "wake_up()" at the end of __down(), we should have
something like this at the end of __down() instead:
... for-loop ...
}
tsk->state = TASK_RUNNING;
remove_wait_queue(&sem->wait, &wait);
/* If there are others, mark the semaphore active */
if (wait_queue_active(&sem_wait)) {
atomic_dec(&sem->count);
sem->sleepers = 1;
}
spin_unlock_irq(&semaphore_lock);
}
which would avoid an unnecessary reschedule, and cause the wakeup to
happen at the proper point, namely "__up()" when we release the
semaphore.
I suspect this may be part of the trouble with the "sleepers" count
playing: we had these magic rules that I know I thought about when the
code was written, but that aren't really part of the "real" rules.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Linux 2.4.0-test11
@ 2000-11-20 2:19 76% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-20 2:19 UTC (permalink / raw)
To: Kernel Mailing List
Ok, test11 is out there. The most noticeable fixes since pre7 are the
Athlon lockup fix, the PCI routing handling, and getting the Joliet stuff
right for iso9660.
Linus
----
- final:
- Patrick Mochel: export the ACPI facs table in /proc too
- Brian Gerst: Video4Linux cleanup (named initializers)
- me: only use irq13 for FP errors for external FPU's. This
fixes the Atlon FP exception lockups.
- me: add a new intel signature to the PIRQ table matching logic.
Make the matching match both reported and actual device ID (with a
preference for the reported). Fixes PCMCIA on NEC Versa laptops.
- iso9660: fix Joliet filename argument order bug introduced in pre7
- Highmem: p_page -> b_page typo.
- me: don't allow pending FPU exceptions without an FPU context..
- pre7:
- Kai Germaschewski: more ISDN cleanups and small fixes.
- Al Viro: fix ntfs_new_inode() that he broke. Cleanups.
- various: handle !CONFIG_HOTPLUG properly
- David Miller: sparc and networking
- me: more iso9660 fixes.
- Neil Brown: fix rd and RAID on highmem machines
- Vojtech Pavlik: input driver fixes
- David Woodhouse: module unload races - up_and_exit()
- pre6:
- Intel: start to add Pentium IV specific stuff (128-byte cacheline
etc)
- David Miller: search-and-destroy places that forget to mark us
running after removing us from a wait-queue.
- me: NFS client write-back ref-counting SMP instability.
- me: fix up non-exclusive waiters
- Trond Myklebust: Be more careful about SMP in NFS and RPC code
- Trond Myklebust: inode attribute update race fix
- Charles White: don't do unaligned accesses in cpqarray driver.
- Jeff Garzik: continued driver cleanup and fixes
- Peter Anvin: integrate more of the Intel patches.
- Robert Love: add i815 signature to the intel AGP support
- Rik Faith: DRM update to make it easier to sync up 2.2.x
- David Woodhouse: make old 16-bit pcmcia controllers work
again (ie i82365 and TCIC)
- pre5:
- Rasmus Andersen: add proper "<linux/init.h>" for sound drivers
- David Miller: sparc64 and networking updates
- David Trcka: MOXA numbering starts from 0, not 1.
- Jeff Garzik: sysctl.h standalone
- Dag Brattli: IrDA finishing touches
- Randy Dunlap: USB fixes
- Gerd Knorr: big bttv update
- Peter Anvin: x86 capabilities cleanup
- Stephen Rothwell: apm initcall fix - smp poweroff should work
- Andrew Morton: setscheduler() spinlock ordering fix
- Stephen Rothwell: directory notification documentation
- Petr Vandrovec: ncpfs capabilities check cleanup
- David Woodhouse: fix jffs to use generic isxxxx() library
- Chris Swiedler: oom_kill selection fix
- Jens Axboe: re-merge after sleeping in ll_rw_block.
- Randy Dunlap: USB updates (pegasus and ftdi_sio)
- Kai Germaschewski: ISDN ppp header compression fixed
- pre4:
- Andrea Arcangeli: SMP scheduler memory barrier fixup
- Richard Henderson: fix alpha semaphores and spinlock bugs.
- Richard Henderson: clean up the file from hell: "xor.c"
- pre3:
- James Simmons: vgacon "printk()" deadlock with global irq lock.
- don't poke blanked console on console output
- Ching-Ling: get channels right on ALI audio driver
- Dag Brattli and Jean Tourrilhes: big IrDA update
- Paul Mackerras: PPC updates
- Randy Dunlap: USB ID table support, LEDs with usbkbd, belkin
serial converter.
- Jeff Garzik: pcnet32 and lance net driver fix/cleanup
- Mikael Pettersson: clean up x86 ELF_PLATFORM
- Bartlomiej Zolnierkiewicz: sound and drm driver init fixes and
cleanups
- Al Viro: Jeff missed some kmap()'s. sysctl cleanup
- Kai Germaschewski: ISDN updates
- Alan Cox: SCSI driver NULL ptr checks
- David Miller: networking updates, exclusive waitqueues nest properly,
SMP i_shared_lock/page_table_lock lock order fix.
- pre2:
- Stephen Rothwell: directory notify could return with the lock held
- Richard Henderson: CLOCKS_PER_SEC on alpha.
- Jeff Garzik: ramfs and highmem: kmap() the page to clear it
- Asit Mallick: enable the APIC in the official order
- Neil Brown: avoid rd deadlock on io_request_lock by using a
private rd-request function. This also avoids unnecessary
request merging at this level.
- Ben LaHaise: vmalloc threadign and overflow fix
- Randy Dunlap: USB updates (plusb driver). PCI cacheline size.
- Neil Brown: fix a raid1 on top of lvm bug that crept in in pre1
- Alan Cox: various (Athlon mmx copy, NULL ptr checks for
scsi_register etc).
- Al Viro: fix /proc permission check security hole.
- Can-Ru Yeou: SiS301 fbcon driver
- Andrew Morton: NMI oopser and kernel page fault punch through
both console_lock and timerlist_lock to make sure it prints out..
- Jeff Garzik: clean up "kmap()" return type (it returns a kernel
virtual address, ie a "void *").
- Jeff Garzik: network driver docs, various one-liners.
- David Miller: add generic "special" flag to page flags, to be
used by architectures as they see fit. Like keeping track of
cache coherency issues.
- David Miller: sparc64 updates, make sparc32 boot again
- Davdi Millner: spel "synchronous" correctly
- David Miller: networking - fix some bridge issues, and correct
IPv6 sysctl entries.
- Dan Aloni: make fork.c use proper macro rather than doing
get_exec_domain() by hand.
- pre1:
- me: make PCMCIA work even in the absense of PCI irq's
- me: add irq mapping capabilities for Cyrix southbridges
- me: make IBMMCA compile right as a module
- me: uhhuh. Major atomic-PTE SMP race boo-boo. Fixed.
- Andrea Arkangeli: don't allow people to set security-conscious
bits in mxcsr through ptrace SETFPXREGS.
- Jürgen Fischer: aha152x update
- Andrew Morton, Trond Myklebust: file locking fixes
- me: TLB invalidate race with highmem
- Paul Fulghum: synclink/n_hdlc driver updates
- David Miller: export sysctl_jiffies, and have the proper no-sysctl
version handy
- Neil Brown: RAID driver deadlock and nsfd read access to
execute-only files fix
- Keith Owens: clean up module information passing, remove
"get_module_symbol()".
- Jeff Garzik: network (and other) driver fixes and cleanups
- Andrea Arkangeli: scheduler cleanup.
- Ching-Ling Li: fix ALi sound driver memory leak
- Anton Altaparmakov: upcase fix for NTFS
- Thomas Woller: CS4281 audio update
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 76%]
* Re: Linux 2.4.0-test11
@ 2000-11-20 2:42 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-20 2:42 UTC (permalink / raw)
To: richbaum; +Cc: linux-kernel
On Sun, 19 Nov 2000, Rich Baum wrote:
>
> The patch is in the v2.3 directory. You may want to move it to the
> v2.4 directory so people can find it easier.
Oops. Thanks. Done.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: 3c59x: Using bad IRQ 0
@ 2000-11-22 1:26 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-22 1:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Tobias Ringstrom, Kernel Mailing List, andrewm, Alan Cox
On Tue, 21 Nov 2000, Jeff Garzik wrote:
>
> A caveat to this whole scheme is that usb-uhci -already- calls
> pci_enable_device before checking dev->irq, and yet cannot get around
> the "assign IRQ to USB: no" setting in BIOS. I hope that is an
> exception rather than the rule.
Do we have a recent report of this with full PCI debug output? It might
just be another unlisted intel irq router..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: {PATCH} isofs stuff
@ 2000-11-23 15:37 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-23 15:37 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: alan, linux-kernel
On Thu, 23 Nov 2000 Andries.Brouwer@cwi.nl wrote:
>
> I never read assembler, but looking at the code produced
> by gcc (2.95.2) it seemed peculiar, maybe an attempt to
> optimize something combining the
> if (filp->f_pos >= inode->i_size)
> with the
> while (filp->f_pos < inode->i_size)
> slightly later.
Can you send me the code in question? I don't have gcc-2.95.2, and I don't
want to install it. If this is truly a compiler bug, I'd like to see it
and verify it and get it reported to the gcc lists asap, as these kinds of
things are so damn nasty to find.
> I have seen that there were discussions on the right compiler to use.
> Is 2.95.2 wrong? Have other things to do tomorrow, so it will be
> 24 hours before I can look at this again.
2.95.2 should have been reasonably ok, but egcs-2.91.66 is probably
considered the most stable compiler right now.
Note that gcc has always had problems with "long long" variables. Very few
people use them as they aren't standard, and the code generation can be
much trickier, so bugs are much more likely. This (along with performance
issues) was why I refused the original LFS patches - they put "long long"
code all over the place.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: 3c59x: Using bad IRQ 0
@ 2000-11-23 17:06 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-23 17:06 UTC (permalink / raw)
To: Tobias Ringstrom; +Cc: Jeff Garzik, Kernel Mailing List, andrewm, Alan Cox
On Tue, 21 Nov 2000, Tobias Ringstrom wrote:
> >
> > Tobias, can you confirm that calling pci_enable_device before reading
> > dev->irq fixes the 3c59x.c problem for you?
>
> Nope. The interrupts do not seem to get through. Packets are transmitted,
> but that's it. I've copied the interesting parts from dmesg:
>
> 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
> See Documentation/networking/vortex.txt
> PCI: Enabling device 00:0a.0 (0014 -> 0017)
> PCI: Assigned IRQ 9 for device 00:0a.0
> eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9
Ok, the VIA stuff is happy, and enables the irq routing. The fact that the
irq's don't actually seem to ever actually appear means that the enable
sequence is probably slightly buggy.
Can you do two things?
- enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code
print out what the pirq table entries are etc.
- add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before
the "return 1;"
Jeff, you had complete VIA docs, right? Can you check that whatever
Tobias' ends up having output from the debug stuff looks sane?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: {PATCH} isofs stuff
@ 2000-11-23 17:20 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-23 17:20 UTC (permalink / raw)
To: Ragnar Hojland Espinosa; +Cc: Andries.Brouwer, alan, linux-kernel
On Thu, 23 Nov 2000, Ragnar Hojland Espinosa wrote:
>
> Yup, indeed it solves the dir/namei problem.
Can you check whether the single patch of _just_ removing the extra "f_pos
>= i_size" test in do_isofs_readdir() fixes it? The other changes of
Andries patch look like they should not affect code generation at all, but
I'd still like to verify that it's only that part. If so, it definitely
looks like a gcc-2.95.2 code generation bug - that single if() statement
does not actually matter for the end result, it's just a (misguided)
early-out optimization.
[ Btw, looking at the generated assembly is quite painful. Ugh. It reminds
me again why "long long" is to be avoided with gcc. Getting rid of the
extra test actually improves and speeds up that function probably
simply because the 64-bit arithmetic just cofuses gcc so badly. ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Cardbus bridge problems
@ 2000-11-23 18:06 91% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-23 18:06 UTC (permalink / raw)
To: Tobias Ringstrom; +Cc: David Hinds, Martin Mares, Kernel Mailing List
[ Tobias: thanks for an excellent report, btw ]
On Wed, 22 Nov 2000, Tobias Ringstrom wrote:
> On Wed, 22 Nov 2000, Tobias Ringstrom wrote:
>
> > Not that I like it, but I need to boot Win98, and then warm boot into
> > Linux, or the Cardbus is not working. This is using Linux-2.4.0-test11 on
> > a Mitac 7233 laptop.
> >
> > Using lspci, I can see that the secondary and subordinate busses of the
> > Cardbus bridges are unconfigured/incorrect. I have attached dmesg and
> > lspci -vvvxxx output from the two cases (ok=Win98+warm-boot and
> > fail=cold-boot). I have enabled all PCI debug things I could find. Bw, it
> > would be really nice to have ONE place to enable the PCI debug info.
You have a really sick system, the following is absolute garbage:
00:08.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
Subsystem: Mitac: Unknown device 7233
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=00, subordinate=00, sec-latency=176
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
I/O window 0: 00001800-000018ff
I/O window 1: 00001c00-00001cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
That bus setup is horribly wrong, and says that the CardBus bridge no bus
numbers, which is obviously not correct. It somehow got through the bridge
scanning without being fixed up..
Now, the reason for why it seems to be so unhappy is apparently
Scanning behind PCI bridge 00:08.0, config 000040, pass 1
Scanning behind PCI bridge 00:08.1, config 000040, pass 1
Note the "config 000040". It basically seems to imply that the cardbus
bridge has been set up as bus 0x40, ie 64. With no secondary bus behind
it. Which looks completely and utterly bogus.
I bet the thing works for you if you change the magic constant 0xffffff in
pci_scan_bridge() to the new magic constant 0xffff00. Basically, we don't
much care what it reports for the primary bus number: but we _do_ care
that a PCI bridge should have a secondary bus number.
Martin, What say you? I think 0xffff00 makes more sense here anyway. And I
bet(*) it will also fix the problem Tobias is seeing.
Tobias? Does changing that if-statement that make your bus happier?
Oh, btw, Martin: I suspect the "cardbus bridge already set up" case in
pci_scan_bridge() should also have the logic
unsigned int cmax = child->subordinate;
if (cmax > max) max = cmax;
in addition to setting up the resources. Comments? As it stands now, it
looks like a pre-configured cardbus bridge doesn't count towards "max" at
all..
Linus
(*) But I won't be betting huge amounts of money on it. There may be other
things that aren't initialized correctly.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 91%]
* Re: 3c59x: Using bad IRQ 0
@ 2000-11-23 18:32 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-23 18:32 UTC (permalink / raw)
To: Tobias Ringstrom; +Cc: Jeff Garzik, Kernel Mailing List, andrewm, Alan Cox
On Thu, 23 Nov 2000, Tobias Ringstrom wrote:
> >
> > - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code
> > print out what the pirq table entries are etc.
>
> Done. When adding the call to eisa_set_level_irq, the line
>
> IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl 0000 -> newirq=9 -> assigning IRQ 9 ... OK
>
> was changed into
>
> IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl 0000 -> newirq=9 -> assigning IRQ 9 -> edge ... OK
Ok.
The thing was marked as edge-triggered, which is basically always wrong
for a PCI interrupt. The above printout just means that it now noticed
that it was edge, and fixed it up in the ELCR.
> > - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before
> > the "return 1;"
>
> You certainly know your kernel very well... :-)
That's why they pay me the big bucks. Good.
I'll make it do the eisa_set_level_irq() in the generic code: it should
always be right (we don't do it now in the PIIX4 case, for example, but
the PIIX documentation actually says that we _should_), and there is no
need to do it separately for each interrupt router.
One down.
Now just tell me if the problem with the machine that needs warm-booting
from Windows is fixed by the other PCI change, and I'll be a happy camper.
(Or rather, I'd be a happy camper if I knew what the cause of the disk
corruption reports is. That one bugs me).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: {PATCH} isofs stuff
@ 2000-11-23 20:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-23 20:38 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andries.Brouwer, alan, linux-kernel
On Thu, 23 Nov 2000, Andi Kleen wrote:
>
> I am actually not sure if the normal kernel contains even a variable
> width long long shift.
Sure it does. The isofs code contains exctly that:
block = filp->f_pos >> bufbits;
In fact, almost all filesystems do this at some point. ext2 does it for
directories too, for some very similar reasons that isofs does. See
fs/ext2/dir.c:
blk = (filp->f_pos) >> EXT2_BLOCK_SIZE_BITS(sb);
(and don't ask me about the extraneous parenthesis. I bet some LISP
programmer felt alone and decided to make it a bit more homey).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1
@ 2000-11-23 23:53 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-23 23:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Michael Elkins, Rui Sousa, usb, linux-kernel, Alan Cox
On Thu, 23 Nov 2000, Jeff Garzik wrote:
> >
> > It hangs in start_uhci():
> >
> > /* disable legacy emulation */
> > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
Try changing the thing around a bit: make the above place say
/* disable legacy emulation */
pci_write_config_word (dev, USBLEGSUP, 0);
and then AFTER we have successfully done a request_irq() call, we
can enable PCI interrupts with
/* Enable PIRQ */
pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
Does that make it happier?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1
@ 2000-11-24 16:30 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-24 16:30 UTC (permalink / raw)
To: Michael Elkins
Cc: Jeff Garzik, Rui Sousa, usb, jerdfelt, linux-kernel, Alan Cox
On Thu, 23 Nov 2000, Michael Elkins wrote:
>
> On Thu, Nov 23, 2000 at 03:53:27PM -0800, Linus Torvalds wrote:
> > Try changing the thing around a bit: make the above place say
> >
> > /* disable legacy emulation */
> > pci_write_config_word (dev, USBLEGSUP, 0);
> >
> > and then AFTER we have successfully done a request_irq() call, we
> > can enable PCI interrupts with
> >
> > /* Enable PIRQ */
> > pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT);
> >
> > Does that make it happier?
>
> Yep! That seems to have fixed it. Added the pci_write_config_word() after
> the request_irq() in alloc_uhci().
Johannes, can you get in touch with the right people and make sure this
gets fixed in both uhci drivers? They both look like they have the same
bug, and I'd prefer not to do it by hand as I don't have that much in the
form of USB..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: ext2 filesystem corruptions back from dead? 2.4.0-test11
@ 2000-11-24 17:41 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-24 17:41 UTC (permalink / raw)
To: linux-kernel
In article <20001124143557.A5614@win.tue.nl>,
Guest section DW <dwguest@win.tue.nl> wrote:
>
>(But I described the situation where the data on disk was correct
>and the date in core was not - almost certainly this is not an IDE problem.)
Ehh.. It only means that it would have been a read failure instead of a
write failure.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test12-pre2
@ 2000-11-28 2:45 96% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-28 2:45 UTC (permalink / raw)
To: Kernel Mailing List
Oh, well. Some people saw the (unannounced, and not for public
consumption) pre1, so here's pre2. pre1 was just meant to be an interim
patch to sync up with the ISDN patches.
Due to the birth of my third daughter last week (yes, I got /.'ed), if you
sent me patches that aren't in pre2, you can pretty much consider them
lost.
Linus
---
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: test12-pre2
@ 2000-11-28 4:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-28 4:38 UTC (permalink / raw)
To: Neil Brown; +Cc: Kernel Mailing List
On Tue, 28 Nov 2000, Neil Brown wrote:
>
> What happens about the stuff that went in to 2.4.0test11-ac{1,2,3,4}?
> Are you going to "sync-up" with Alan, or should we send bits directly
> to you?
Either, or both.
Alan feeds me his patches in small chunks anyway, and does a good job of
keeping stuff separate. Re-sending directly to me means that Alan would
just drop that part of the patch - or that I'd get the patch twice. Both
of which work ok, as long as it's the _same_ patch.
If you've made modifications since sending the stuff to Alan, you should
synchronize with Alan too - just to make sure that I don't en dup applying
the old stuff through Alan.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: corruption
@ 2000-11-29 5:09 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-29 5:09 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: linux-kernel
On Wed, 29 Nov 2000 Andries.Brouwer@cwi.nl wrote:
>
> I did again a large test comparing two identical trees.
> Found again corruption, and, upon inspection, the disk
> files did not differ - this is in-core corruption only.
Ok. It definitely looks like the 1kB thing has become broken somehow.
The fact that it is in-core only doesn't mean that much - it could still
easily be just problems at read-time, and if you have an IDE disk I would
strongly suggest you try out the patch that Jens Axboe posted,
re-initializing the "head" pointer when doing a re-merge.
That said, the VM/ext2 angle should definitely be looked at too. Nothing
has really changed there in some time - can you give a rough estimate on
when you suspect you started seeing it? Ie is it new to one of the test11
pre-kernels, or does it happen so occasionally that you can't tell whether
it happened much earlier too?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test12-pre3
@ 2000-11-29 6:57 95% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-29 6:57 UTC (permalink / raw)
To: Kernel Mailing List; +Cc: Alan Cox
The bulk of this is architecture updates (most lately mips64). The most
interesting (but fairly small) part is the VM cleanups. Any day now
kiobuf's can just use PageDirty on everything, and we won't have any nasty
races any more.
Linus
----
- pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: corruption
@ 2000-11-29 17:47 98% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-29 17:47 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: linux-kernel
On Wed, 29 Nov 2000 Andries.Brouwer@cwi.nl wrote:
>
> > can you give a rough estimate on when you suspect you started seeing it?
>
> I reported both cases. That is, I started seeing it a few days ago.
I wasn't trying to imply that you hadn't reported them well.
It's just that I was born with a highly developed case of Altzheimers, and
I have trouble keeping details around in my head for more than about five
minutes.
I'm half serious, btw. It's not that I don't have a good memory, but I
tend to remember patterns and how things work, and I'm _really_ bad at
keeping track of details. This is why I absolutely depend on people like
Alan Cox etc who maintain lists of problems, and who are good at gathering
reports on what kinds of machines see it etc. I just suck at it. I really
do.
Anyway, it tentatively sounds like it might have been request corruption
by the new re-merge code. It fits the details, you having IDE and all. I
see that you can't at least easily reproduce it in pre3 any more, but if
it turns out later that you still can, please holler. Loudly.
That still leaves the SCSI corruption, which could not have been due to
the request issue. What's the pattern there for people?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 98%]
* Re: plug problem in linux-2.4.0-test11
@ 2000-11-29 17:52 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-29 17:52 UTC (permalink / raw)
To: Jens Axboe; +Cc: schwidefsky, linux-kernel
On Wed, 29 Nov 2000, Jens Axboe wrote:
>
> I agree with your reasoning, even if the s390 behaviour is a bit
> "non-standard" wrt block devices. Linus, could you apply?
>
> --- drivers/block/ll_rw_blk.c~ Wed Nov 29 15:17:33 2000
> +++ drivers/block/ll_rw_blk.c Wed Nov 29 15:18:43 2000
> @@ -347,10 +347,9 @@
> */
> static inline void __generic_unplug_device(request_queue_t *q)
> {
> - if (!list_empty(&q->queue_head)) {
> - q->plugged = 0;
> + q->plugged = 0;
> + if (!list_empty(&q->queue_head))
> q->request_fn(q);
> - }
> }
I would much rather actually go back to the original setup, which did
nothing at all if the queue wasn't plugged in the first place.
I think that we should strive for a setup that calls "request_fn" only to
start new IO, and that expects the low-level driver to be able to do the
whole request queue until it is empty. Then we re-start it the next time
around.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: corruption
@ 2000-11-29 18:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-29 18:38 UTC (permalink / raw)
To: Tigran Aivazian; +Cc: Andries.Brouwer, linux-kernel
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
> On Wed, 29 Nov 2000, Tigran Aivazian wrote:
>
> > On Wed, 29 Nov 2000, Linus Torvalds wrote:
> > > That still leaves the SCSI corruption, which could not have been due to
> > > the request issue. What's the pattern there for people?
>
> one more thing I remember when this happened:
>
> a) lots of ld processes from kernel compilation were failing with ENOSPC
> although df(1) was showing plenty of memory and I could manually "touch
> ok" in the same filesystem just fine.
>
> b) immediately restarting "make -j4 bzImage" would go on for quite a bit
> and then hit the same set of .c files and "run out of space" again.
Ehh, this is a stupid question, but I've had that happen too, and it
turned out my /tmp filesystem was full, and it runs out of space only with
certain large link cases (never anything else, because all the other
stages of compilation are done with -pipe and do not use /tmp files).
I'm embarrassed to even mention this, but I'v ebeen confused myself.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: corruption
@ 2000-11-29 19:25 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-11-29 19:25 UTC (permalink / raw)
To: Alexander Viro; +Cc: Andries.Brouwer, Tigran Aivazian, linux-kernel
On Wed, 29 Nov 2000, Alexander Viro wrote:
>
> Problem fixed by Jens' patch had been there since March, so if it's a
> mix of __make_request() screwing up and something else... Urgh.
No, the bug really got introduced in test11 due to the request merging
stuff.
The patch may _look_ like it fixed a generic problem that has been there
forever, but we didn't actually need the spinlock for initializing "head"
at all. It's initialized to a constant offset within the unchaning request
queue, so we can happily do it outside the spinlock.
The reason the initialization was moved inside the spinlock was really
just that it had to be re-initialized for the case where we re-did the
merge, so it had to be moved down to inside the loop - and it just happens
to happen inside the spinlock now.
So the spinlock protection was never relevant to the bug - forgetting to
re-initialize a variable when a straight-line code was turned into a loop
was the bug.
> I'ld really like to see details on the box with ext2 corruption on SCSI.
> Tigran, IIRC you had it on SCSI boxen, right? Could you send me relevant
> part of logs?
I suspect that Tigran may have seen other instability (of which we had
lots back when he saw it), and that the current rash is for the IDE
problem only.
Which is not to say that there might not be SCSI issues or other issues
too, but I'm also not convinced that the SCSI thing might not just be a
red herring at this point.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Re: Transmeta and Linux-2.4.0-test12-pre3
@ 2000-12-02 5:09 85% ` Linus Torvalds
2000-12-02 7:27 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2000-12-02 5:09 UTC (permalink / raw)
To: linux-kernel
In article <200012020409.UAA04058@adam.yggdrasil.com>,
Adam J. Richter <adam@yggdrasil.com> wrote:
>
> Well, alas, it appears that linux-2.4.0-test12-pre3 freezes hard
>while reading the base address registers of the first PCI device
>(the "host bridge"). Actually, I think the problem is some kind of
>system management interrupt occuring at about this time, since the
>exact point where the printk's stop gets earlier as I add more
>printk's.
This is due to a Linux bug, where we disable the northbridge while we do
the PCI window probes.
[ I actually suspected for a while that we'd messed up at Transmeta, but
after talking with and double-checking the PCI specs, it turns out
that Linux really was at fault. Oh, well. Whichever way I turn, I'm
always to blame ;) ]
What happens is that the Sony notebook has Legacy USB support on in the
BIOS, which causes USB DMA events several thousand times a second. When
Linux does PCI probing, Linux will turn off the MEM and IO bits in the
PCI command register of the device it probes. It so happens that
according to the PCI spec, turning off the MEM bit of the host bridge
(aka "northbridge") disconnects the host from the PCI bus.
A few microseconds later a USB legacy DMA event comes in, but now the
host bridge no longer forwards the DMA between the PCI bus and memory,
and the machine hangs. Oops.
The simplest (working) solution is to remove the jiggering with the PCI
command register IO and MEM bits in drivers/pci/pci.c: pci_read_bases().
The proper fix (which we discussed with Martin Mares and Richard
Henderson) is actually to do the full bus enumeration first, _without_
doing any window probes (and thus without having to muck with the IO and
MEM bits in the command register), and when we find the offending USB
controller that the BIOS has left active, we kill it off first (we
already have this in the PCI quirks section, it's just that the PCI
quirks get executed too late to fix this problem as it is now).
> One sin that I am committing in these builds is that I am bulding
>them under gcc-2.95.2, although I do not think this is the sort of
>behavior that an optimizer bug is likely to produce.
Nope, this is completely unrelated.
> If anyone out there is using Linux 2.4.0-test on a Sony
>PictureBook PCG-C1VN (the Transmeta version), I would be interested in
>at least trying to build from your .config file.
>
> Memo to Transmeta management: buy Linus a PictureBook. :-)
Actually, I have one, and have had one for about two weeks, but because
of the newest (human) addition to the Torvalds family I didn't have any
time to debug this until the day before yesterday.
NOTE! Getting the 2.4.x kernel up and running is the easy part. The
machine also has a very recent ATI Rage Mobility chip in it, and you
need the newest XFree86 CVS snapshot to make it work (along with a
one-liner patch from me, unless that has already made it into the CVS
tree by now).
Even then XFree86 does something bad with DPMS, and will lock up the
graphics chipset when it tries to shut down the flat panel display.
Solution: don't enable DPMS is XF86Config. That's an XFree86 problem,
but happily easily worked around.
Oh, and there's a UHCI driver bug that will bite you (again because the
machine has legacy USB enabled by default - and unlike almost every
other laptop out there, Sony didn't allow USB legacy code to be turned
off in the BIOS setup), so unless you've applied the USB patches from
the USB mailing list you'll just hang there instead.
Anyway, I do have this machine working now, although not everything is
to my liking. Unlike older picture-books, for example, this one has a
WinModem. Ugh. And the sound chip is supported, but only by the ALSA
driver (the OSS version is too broken to be used).
But the camera is cool, and works beautifully (once you get XFree86
happy) thanks to Andrew Tridgell. (If I could just coax the X server
into giving my a YUV overlay I could play DVD's with this thing).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 85%]
* Re: Transmeta and Linux-2.4.0-test12-pre3
2000-12-02 5:09 85% ` Linus Torvalds
@ 2000-12-02 7:27 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-02 7:27 UTC (permalink / raw)
To: linux-kernel
In article <90a065$5ai$1@penguin.transmeta.com>,
Linus Torvalds <torvalds@transmeta.com> wrote:
>
>Anyway, I do have this machine working now, although not everything is
>to my liking. Unlike older picture-books, for example, this one has a
>WinModem. Ugh. And the sound chip is supported, but only by the ALSA
>driver (the OSS version is too broken to be used).
Oh - another detail: do _not_ get the latest ALSA driver: 0.5.9d is
apparently broken, while 0.5.8a works fine once you fix the MAP_NR()
issue (ie use "struct page *page = virt_to_page(addr)" instead of using
"int nr = MAP_NR(addr)", and do the arithmetic on "struct page" pointers
instead of ints.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Transmeta and Linux-2.4.0-test12-pre3 [slightly off-topic]
@ 2000-12-03 3:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-03 3:01 UTC (permalink / raw)
To: Ion Badulescu; +Cc: linux-kernel
On Sat, 2 Dec 2000, Ion Badulescu wrote:
>
> If it's the same bug that locks up the ATI chipset on my Dell laptop,
> then you can safely enable DPMS if only enable the standby mode,
> not the others (suspend and off). The panel gets turned off anyway,
> even in standby.
Yup, same bug, and yes, "dpms standby" works, only suspend and off are
broken.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Transmeta and Linux-2.4.0-test12-pre3
@ 2000-12-03 8:23 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-03 8:23 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Sat, 2 Dec 2000, Alan Cox wrote:
>
> > But the camera is cool, and works beautifully (once you get XFree86
> > happy) thanks to Andrew Tridgell. (If I could just coax the X server
> > into giving my a YUV overlay I could play DVD's with this thing).
>
> Start at http://www.core.binghamton.edu/~insomnia/gatos/
Heh.
I integrated "ati_video.c" from ati_xv into the current XFree86 CVS
sources, and yup, sure as h*ll, I can play movies fine. Quite smooth (at
least the 24 fps stuff - I bet it drops frames like mad for any 30fps
movies). It's quite cute.
There's some redraw bug in the overlay code, and it doesn't understand
virtual desktops larger than the physical desktop. Details, details.
Thanks for the pointer,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test12-pre4
@ 2000-12-04 2:29 93% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-04 2:29 UTC (permalink / raw)
To: Kernel Mailing List
Synching up with Alan and various other stuff. The most important one
being the fix to the inode dirty block list.
Linus
----
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
- Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work.
- Stephen Tweedie: fix inode dirty block handling
- Bill Hartner: reschedule_idle - prefer right cpu
- Johannes Erdfelt: USB updates
- Alan Cox: synchronize
- Richard Henderson: alpha updates and optimizations
- Geert Uytterhoeven: fbdev could be fooled into crashing fix
- Trond Myklebust: NFS filehandles in inode rather than dentry
- pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 93%]
* Re: [PATCH] inode dirty blocks
@ 2000-12-05 2:41 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 2:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: Alexander Viro, Kernel Mailing List
On Tue, 5 Dec 2000, Andrew Morton wrote:
>
> - test12-pre4
> - aviro bforget patch
Is the bforget patch really needed?
If clear_inode() gets rid of dirty buffers, I don't see how new dirty
buffers can magically appear. I may have missed part of the discussion on
all this.
I think that the second patch from Al (the inode dirty meta-data) is the
_real_ fix, and I don't see why the bforget changes should matter.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test12-pre5
@ 2000-12-05 3:20 80% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 3:20 UTC (permalink / raw)
To: Kernel Mailing List
Cc: Alexander Viro, Andrew Morton, Stephen C. Tweedie, Alan Cox,
Christoph Rohland, Rik van Riel, MOLNAR Ingo
Ok, this contains one of the fixes for the dirty inode buffer list (the
other fix is pending, simply because I still want to understand why it
would be needed at all). Al?
Also, it has the final installment of the PageDirty handling, and now
officially direct IO can work by just marking the physical page dirty and
be done with it. NFS along with all filesystems have been converted, the
one hold-out still being smbfs.
Who works on smbfs these days? I see two ways of fixing smbfs now that
"writepage()" only gets an anonymous page and no "struct file" information
any more (this also fixes the double page unlock that Andrew saw).
- disable shared mmap over smbfs (very easily done by just setting
writepage to NULL)
- fetch the dentry that writepage needs by just looking at the
inode->i_dentry list and/or just make the smbfs page cache host be the
dentry instead of the inode like other filesystems. The first approach
assumes that all paths are equal for writeout, the second one assumes
that there are no hard linking going on in smbfs.
Somebody more knowledgeable than I will have to make the decision
(otherwise I'll just end up disabling shared mmap - I doubt anybody really
uses it anyway, but it would be more polite to just support it).
NOTE! There's another change to "writepage()" semantics than just dropping
the "struct file": the new writepage() is supposed to mirror the logic of
readpage(), and unlock the page when it is done with it. This allows the
VM system more visibility into what IO is pending (which the VM doesn't
take advantage of yet, but now it can _truly_ use the same logic for both
swapout and for dirty file writeback).
The other change is that I forward-ported the ymfpci driver from 2.2.18,
as it works better than the ALSA one on my now-to-be-main-laptop ;)
[ Alan - I ahve your patches in my incoming queue still, I wanted to get
an interim version out to check with Al on the block list and the VM
stuff with Rik and people. ]
Linus
----
- pre5:
- Jaroslav Kysela: ymfpci driver
- me: get rid of bogus MS_INVALIDATE semantics
- me: final part of the PageDirty() saga
- Rusty Russell: 4-way SMP iptables fix
- Al Viro: oops - bad ext2 inode dirty block bug
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
- Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work.
- Stephen Tweedie: fix inode dirty block handling
- Bill Hartner: reschedule_idle - prefer right cpu
- Johannes Erdfelt: USB updates
- Alan Cox: synchronize
- Richard Henderson: alpha updates and optimizations
- Geert Uytterhoeven: fbdev could be fooled into crashing fix
- Trond Myklebust: NFS filehandles in inode rather than dentry
- pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 80%]
* Re: [PATCH] inode dirty blocks
@ 2000-12-05 3:52 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 3:52 UTC (permalink / raw)
To: Alexander Viro; +Cc: Andrew Morton, Kernel Mailing List
On Mon, 4 Dec 2000, Alexander Viro wrote:
>
> Well, to start with you don't want random bh's floating around on the
> inode's list. With the current code truncate()+fsync() can send a lot
> of already freed stuff to disk. Even though we can survive that (making
> clear_inode() to get rid of the list will save you from corruption)...
> it doesn't look like a good idea.
Now, I'll agree with that, certainly.
I just wanted to be clear on the purpose of the patches. The bforget() one
looks like "taking care of the details", but not like a bug-fix. Agreed?
(Which is not to say I won't apply it - I just want to make sure we have
the issues under control).
> BTW, in the current form clear_inode() doesn't get rid of the dirty
> buffers. It misses the pages that became anonymous and it misses the
> metadata that became freed. We can do that, but I'ld rather avoid
> leaving these buffer_heads on the inode's list - stuff that got freed
> has no business to be accessible from in-core inode.
Again, I agree with you, but it looks like that is a cleanup issue rather
than a bug.
> > I think that the second patch from Al (the inode dirty meta-data) is the
> > _real_ fix, and I don't see why the bforget changes should matter.
>
> We can survive without them (modulo patch to clear_inode()), but...
The "patch to clean-inode" is the one I already did from sct? Or are we
talking about another issue?
> BTW, there is another reason why we want to have separate function
> for freeing the stuff: we may want to mark them clean. If they are
> already under IO it will do nothing, but if they are merely dirty...
Yes. Make it so. In the meantime, does everybody agree that pre5 fixes the
bugs, even though it still has these discussion items left?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test12-pre5
@ 2000-12-05 4:00 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 4:00 UTC (permalink / raw)
To: Alexander Viro
Cc: Kernel Mailing List, Alexander Viro, Andrew Morton,
Stephen C. Tweedie, Alan Cox, Christoph Rohland, Rik van Riel,
MOLNAR Ingo
On Mon, 4 Dec 2000, Alexander Viro wrote:
>
> On Mon, 4 Dec 2000, Linus Torvalds wrote:
> >
> > Ok, this contains one of the fixes for the dirty inode buffer list (the
> > other fix is pending, simply because I still want to understand why it
> > would be needed at all). Al?
>
> See previous posting. BTW, -pre5 doesn't do the right thing in clear_inode().
>
> Scenario: bh of indirect block is busy (whatever reason, flush_dirty_buffers(),
> anything that can bump ->b_count for a while). ext2_truncate() frees the
> thing and does bforget(). bh is left on the inode's list. Woops...
So? Why wouldn't clear_inode() get rid of it?
> The minimal fix would be to make clear_inode() empty the list. IMO it's
> worse than preventing the freed stuff from being on that list...
This _is_ what clear_inode() does in pre5 (and in pre4, for that matter):
void clear_inode(struct inode *inode)
{
if (!list_empty(&inode->i_dirty_buffers))
invalidate_inode_buffers(inode);
...
which I find perfectly readable. And should mean that no dirty buffers
should be associated with the inode any more. ext2 calls clear_inode()
from ext2_free_inode(), and as far as I can tell the only thing that can
happen after that is that the inode is still scheduled for write-out
(which explains how the bug you fixed would cause a dirty block to be
attached to the inode _after_ we did a clear_inode() on it).
Or are you thinking of something else?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test12-pre5
@ 2000-12-05 17:48 90% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 17:48 UTC (permalink / raw)
To: Stephen C. Tweedie
Cc: Alexander Viro, Kernel Mailing List, Alexander Viro,
Andrew Morton, Alan Cox, Christoph Rohland, Rik van Riel,
MOLNAR Ingo
On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
>
> On Mon, Dec 04, 2000 at 08:00:03PM -0800, Linus Torvalds wrote:
> >
> > On Mon, 4 Dec 2000, Alexander Viro wrote:
> > >
> > This _is_ what clear_inode() does in pre5 (and in pre4, for that matter):
> >
> > void clear_inode(struct inode *inode)
> > {
> > if (!list_empty(&inode->i_dirty_buffers))
> > invalidate_inode_buffers(inode);
>
> That is still buggy. We MUST NOT invalidate the inode buffers unless
> i_nlink == 0, because otherwise a subsequent open() and fsync() will
> have forgotten what buffers are dirty, and hence will fail to
> synchronise properly with the disk.
Are you all on drugs?
Look at where clear_inode() is called. It's called by
ext2_delete_inode(). It's not called by close(). Never has, never will.
clear_inode() _destroys_ the inode. WE HAVE TO GET RID OF BUFFERS at that
point. Because there won't be anything left to index to. We're going to
free the memory in RAM held by the inode. Blathering on about
"i_nlink" etc is a complete and utter waste of time, because even if nlink
is a million, there's no way we could leave the buffers indexed on the
inode. We _will_ call destroy_inode() soon afterwards.
The thing that protects the inode while it is still truly in use, is the
CAN_UNUSE() macro, which explicitly tests that the inode is not used by
anybody and has no dirty pages. If that macro doesn't work, then we have a
damn more serious problem than nlink to worry about.
Get your acts together, guys. Stop blathering and frothing at the mouth.
The only time clear_inode() should be called is (a) when we prune the
inode cache - and we CLEARLY cannot prune an inode if it still has dirty
blocks associated with it and CAN_UNUSE() already enforces this or (b)
when we're getting rid of the very last occurrence of the inode. In one
case the dirty list is already empty. In the other, invalidating it is
clearly the right thing and the _required_ thing to do.
So I repeat: are there known bugs in this area left in pre5? And with
"bugs", I don't mean fever-induced rants like the above (*).
I don't see any. Andrew cannot re-create any. But I won't rest easy until
people agree that the code is ok as-is. After that I can consider applying
optimizations, because right now my personal conviction is that the
patches from Al are cleanups and optimizations, but _not_ bug-fixes. And
they will absolutely not get applied before there is some consensus on
these issues.
Linus
(*) And yes, you can smack me on the head for that outburst if it turns
out that I just didn't see anything. I'll apologize. But right now I'm
irritated.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 90%]
* Re: test12-pre5
@ 2000-12-05 18:33 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 18:33 UTC (permalink / raw)
To: Alexander Viro
Cc: Stephen C. Tweedie, Kernel Mailing List, Alexander Viro,
Andrew Morton, Alan Cox, Christoph Rohland, Rik van Riel,
MOLNAR Ingo
On Tue, 5 Dec 2000, Alexander Viro wrote:
>
> Sigh. OK, let me put it that way:
>
> * we _can_ have dirty blocks on the list when inode gets freed.
Agreed.
> * no, CAN_UNUSE will not see them.
CAN_UNUSE() is not used at all for the final forcible removal of an inode
that has no users.
> * no, we do not give a damn about forgetting them.
Indeed. We'd be better off marking them clean, to make sure they never hit
the disk.
> So Stephen is right wrt fsync() (it will not get that stuff on disk).
> However, it's not a bug - if that crap will not end up on disk we
> will only win.
Stephen is _wrong_ wrt fsync().
Why?
Think about it for a second. How the hell could you even _call_ fsync() on
a file that no longer exists, and has no file handles open to it?
By the time we call clear_inode(), fsync() had better not be an issue any
more. The only reason fscyn() could be an issue is if somebody starts
calling clear_inode() left and right, but hey, if that happens your
filesystem would be so FUBAR'ed that you really wouldn't care any more.
Data integrity of "fsync()" is the least of your worries.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test12-pre5
@ 2000-12-05 19:48 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 19:48 UTC (permalink / raw)
To: Alexander Viro
Cc: Stephen C. Tweedie, Kernel Mailing List, Alexander Viro,
Andrew Morton, Alan Cox, Christoph Rohland, Rik van Riel,
MOLNAR Ingo
On Tue, 5 Dec 2000, Alexander Viro wrote:
> >
> > Stephen is _wrong_ wrt fsync().
> >
> > Why?
> >
> > Think about it for a second. How the hell could you even _call_ fsync() on
> > a file that no longer exists, and has no file handles open to it?
> ^^^^^^^^^^^^^^
> clear_inode() <- dispose_list() <- prune_icache().
No. prune_icache() will absolutely _refuse_ to prune an inode that is
still in use. Where "in use" is defined to be an aggregate of many things,
including the fact that the inode is dirty (even if there are no actual
references to it any more) _or_ the fact that the inode has cached data
associated with it.
Page cache counts as cached data.
As does dirty buffers.
So clean_inode() is basically always called only for "dead" objects.
And this is not just a "it happens to be like this" kind of thing. It
_has_ to be like this, because every time we call clear_inode() we are
going to physically free the memory associated with the inode very soon
afterwards. Which means that _any_ use of the inode had better be long
gone. Dirty buffers included.
So it's definitely ok to say that "once we get to clean_inode(), there is
no way in h*ll that dirty buffers can be valid any more". Because either
we have checked that by hand (prune_icache), or we're killing the inode
outright (no more users and the inode has been removed).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Re: test12-pre5
[not found] <00120522275601.09076@gimli>
@ 2000-12-05 21:58 92% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 21:58 UTC (permalink / raw)
To: Daniel Phillips; +Cc: Kernel Mailing List
On Tue, 5 Dec 2000, Daniel Phillips wrote:
>
> OK, I see - this isn't easy at all. You start the io if necessary, and
> some time later it completes.
Right. You don't know when. Once completed, it will unlock the page and
wake up waiters. It will also set PG_Uptodate if the read was successful
(and obviously it might not have been).
If you only care about the contents of the page, you can just test the
Uptodate flag - if the page is up-to-date you may not care whether IO is
outstanding on the page, or whether somebody is modifying page state
(removing page buffers etc). So it's entirely legal to look up a page in
the page cache and only look at uptodate.
(Of course, if it _isn't_ uptodate, you will still have to get the page
lock and re-test and possibly start the IO if it still isn't up-to-date
after you got the page lock. This is what all the generic_file_read()
stuff does for you).
> The locking state is therefore
> indeterminate after ->readpage or ->writepage; all we know is that
> after some finite amount of time the lock bit will go down.
Yes. It might have completed immediately (ramdisks or what not), or be
fast enough that by the time you get back it's already done. But the
likely case is that the page will be locked, and you'd be better off going
away and doing something else in the meantime (this is certainly important
for the VM layer - it needs to continue doing swap-outs so that it
doesn't just dribble the pages out one by one).
The main reason for the page locking changes for the writepage() case were
really:
- the swapping code serializes accesses by using the page lock, and
doesn't have any other underlying serializing primitives. So we needed
to let the brw_page() code leave the lock set until the write has
physically completed.
- the VM code really wants to have a notion of "I have this many pages in
flight", so that it can sanely make a decision on when to start waiting
on page writeout completion, instead of just writing as much as it can.
The block device layer does some of this, of course, but the VM layer
can do more by just using the "nr_async_pages" thing. However, before
the unlock changes, this could not work for shared file mappings.
I hope that explains the change,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 92%]
* PCI irq routing..
[not found] <Pine.LNX.4.30.0012052110590.968-100000@localhost.localdomain>
@ 2000-12-05 23:04 85% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 23:04 UTC (permalink / raw)
To: Kai Germaschewski, Adam J. Richter, Martin Mares; +Cc: Kernel Mailing List
Ok, I now have two confirmations from independent people (Adam Richter
and Kai Germaschewski) who have completely different hardware, but have
the same problem: irq routing seems to not work for them.
In both cases it is because the PCI device config space already has an
entry for the interrupt, but the interrupt is apparently not actually
routed on the irq router.
WHY this happens is unclear, but it could be several reasons:
- undocumented "Plug'n'Play OS true behaviour"
- BIOS bugs. 'nuff said.
- warm-booting from an OS that _does_ set the interrupt routing,
and also sets the PCI config space thing
The problem can be fairly easily fixed by just removing the test for
whether "pci->dev" has already got set. This, btw, is important for
another reason too - there is nothing that says that a sleep event
wouldn't turn off the irq routing, so we _have_ to have some way of
forcing the interrupt routing to take effect even if we already think we
have the correct irq.
However, Martin is certainly also right in claiming that there might be
bugs the "other" way, and just completely dismissing the irq we already
are claimed to have would be bad.
This is my current suggested patch for the problem.
Adam, Kai, can you verify that it fixes the issues on your systems?
Anybody else who has had problems with PCI interrupt routing (tends to be
"new" devices like CardBus, ACPI, USB etc), can you verify that this
either fixes things or at least doesn't break a setup that had started
working earlier..
Martin, what do you think? We definitely need something like this, but
maybe we could add a few more sanity-tests?
Linus
----
--- v2.4.0-test11/linux/arch/i386/kernel/pci-irq.c Sun Nov 19 18:44:03 2000
+++ linux/arch/i386/kernel/pci-irq.c Tue Dec 5 14:38:13 2000
@@ -405,9 +424,12 @@
DBG(" -> PIRQ %02x, mask %04x, excl %04x", pirq, mask, pirq_table->exclusive_irqs);
mask &= pcibios_irq_mask;
- /* Find the best IRQ to assign */
- newirq = 0;
- if (assign) {
+ /*
+ * Find the best IRQ to assign: use the one
+ * reported by the device if possible.
+ */
+ newirq = dev->irq;
+ if (!newirq && assign) {
for (i = 0; i < 16; i++) {
if (!(mask & (1 << i)))
continue;
@@ -417,16 +439,22 @@
newirq = i;
}
}
- DBG(" -> newirq=%d", newirq);
}
+ DBG(" -> newirq=%d", newirq);
/* Try to get current IRQ */
if (r->get && (irq = r->get(pirq_router_dev, d, pirq))) {
DBG(" -> got IRQ %d\n", irq);
msg = "Found";
+ /* We refuse to override the dev->irq information. Give a warning! */
+ if (dev->irq && dev->irq != irq) {
+ printk("IRQ routing conflict in pirq table! Try 'pci=autoirq'\n");
+ return 0;
+ }
} else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
DBG(" -> assigning IRQ %d", newirq);
if (r->set(pirq_router_dev, d, pirq, newirq)) {
+ eisa_set_level_irq(newirq);
DBG(" ... OK\n");
msg = "Assigned";
irq = newirq;
@@ -556,19 +584,17 @@
void pcibios_enable_irq(struct pci_dev *dev)
{
- if (!dev->irq) {
- u8 pin;
- pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
- if (pin && !pcibios_lookup_irq(dev, 1)) {
- char *msg;
- if (io_apic_assign_pci_irqs)
- msg = " Probably buggy MP table.";
- else if (pci_probe & PCI_BIOS_IRQ_SCAN)
- msg = "";
- else
- msg = " Please try using pci=biosirq.";
- printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of device %s.%s\n",
- 'A' + pin - 1, dev->slot_name, msg);
- }
+ u8 pin;
+ pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+ if (pin && !pcibios_lookup_irq(dev, 1) && !dev->irq) {
+ char *msg;
+ if (io_apic_assign_pci_irqs)
+ msg = " Probably buggy MP table.";
+ else if (pci_probe & PCI_BIOS_IRQ_SCAN)
+ msg = "";
+ else
+ msg = " Please try using pci=biosirq.";
+ printk(KERN_WARNING "PCI: No IRQ known for interrupt pin %c of device %s.%s\n",
+ 'A' + pin - 1, dev->slot_name, msg);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 85%]
* Re: smbfs writepage & struct file
@ 2000-12-05 23:57 87% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-05 23:57 UTC (permalink / raw)
To: Urban Widmark, Alexander Viro, Trond Myklebust; +Cc: Kernel Mailing List
On Wed, 6 Dec 2000, Urban Widmark wrote:
>
> Hardlinks are not supported by smbfs, but they may be supported on the
> server side (ntfs). Haven't looked if smb has anything on this. Not sure
> if there are any implications on caching and such for smbfs. (If hardlinks
> need to be handled, smbfs is probably broken anyway wrt those).
Without hardlinks there will be a 1:1 relation between inodes and
dentries, which means that the dentry could be used as a mapping host.
Then you could just do
struct dentry *dentry = (struct dentry *)mapping->host;
and get the inode from "dentry->d_inode". The problem with going the other
ways is that you can have an inode where the dentry has been reaped by
shrink_dcache() due to memory pressure, so the inode->i_dentry list could
in theory be empty. The reverse can never be true (if the dentry exists,
the inode will exist too).
HOWEVER, the problem with just making the dentry be the mapping host is
that I don't think it has ever been done before, so there is no good
source of examples on how to do this. You would just initialize it in
"smb_iget()", but then you'd have to pass the dentry down to that routine
in order to know what to initialize the mapping host to, of course.
Even after you'd do that, there are other problems: the inode shrinking
code knows about having pages attached to the inode. The same is not true
of the dentry shrinking code - so we could shrink a dentry that is still
busy in that it has pages in its mapping.
In comparison to these dentry host problems, your patch looks fine. But I
suspect that you _can_ trigger the BUG() with an empty dentry list due to
dentry shrinking. So what I did is basically to (a) apply your patch and
(b) set writepage to NULL in the address space operations, so that shared
mappings will be disabled for the time being.
I also cc'd Al, because he's likely to just come up with a clever scheme
that solves this, and call me an idiot.
Hmm.. The smb filesystem code in general seems to assume that if we have
an inode, we'd always have a dentry and vice versa. Because otherwise we'd
have potentially multiple inodes for the same dentry. Every time we do a
successful dentry lookup(), we do a "new_inode()", so if we drop the
dentry and re-lookup, we'd have aliased inodes (and thus various page
cache aliases too, etc).
Having aliased inodes is not wrong per se: it's just that it doesn't mix
well with having the page cache associated with the inode. So it probably
works fine as-is, it just has the potential to not cache things as well as
it could (because dropping the dentry will basically mean dropping the
full page cache).
Al? Any ideas?
> I was "borrowing" stuff from the nfs code and this looked strange:
>
> nfs_writepage_sync:
> struct dentry *dentry = file->f_dentry;
> struct rpc_cred *cred = nfs_file_cred(file);
>
> yet it is called like this from nfs_writepage:
> err = nfs_writepage_sync(NULL, inode, page, 0, offset);
>
> where file is the 1st argument. Oh, it calls nfs_writepage_async most of
> the time. All of the time?
That's bogus. But Trond probably overlooked it in testing, because yes, it
always calls the async version unless there has been errors doing async
writes (which should be rather uncommon).
Trond? Can you massage the sync version to do the same as the async one?
Thanks for noticing.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 87%]
* Re: That horrible hack from hell called A20
@ 2000-12-06 0:13 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 0:13 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linux Kernel Mailing List, kai, Alan Cox
On Tue, 5 Dec 2000, H. Peter Anvin wrote:
>
> Okay, here is my latest attempt to find a way to toggle A20M# that
> genuinely works on all machines -- including Olivettis, IBM Aptivas,
> bizarre notebooks, yadda yadda.
I really think that the 0x92 accesses are still unsafe.
I will bet that the same way some manufacturers use the A20 output as a
GPIO, they might also use the keyboard _reset_ output as a GPIO. This
would explain why we have problems on getting back from resume.
So the "orb $2,%al ; andb $0xfe,%al" will potentially change both of
these. And I'd feel a hell of a lot more safe, if we avoided using 0x92
except when we find that we absolutely _have_ to.
How about making the keyboard controller timeouts shorter, and moving all
the 0x92 games to after the keyboard controller games. That, I feel, would
be the safest approach: try the really old approach first (that people are
the least likely to use as GPIO - it's just too damn painful to go through
the keyboard controller, and the keyboard controller A20 logic is just too
well documented, so nobody would use it for anything else).
If the keyboard controller times out, or if A20 still doesn't seem to be
enabled, only _then_ would we do the 0x92 testing.
Btw, do we actually know of any machine that really needs the "and $0xfe"?
That register really makes me nervous.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Re: That horrible hack from hell called A20
@ 2000-12-06 0:48 99% ` Linus Torvalds
2000-12-06 1:07 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 0:48 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: H. Peter Anvin, Linux Kernel Mailing List
On Wed, 6 Dec 2000, Kai Germaschewski wrote:
>
> On Tue, 5 Dec 2000, H. Peter Anvin wrote:
>
> > If you have had A20M# problems with any kernel -- recent or not --
> > *please* try this patch, against 2.4.0-test12-pre5:
>
> Just a datapoint: This patch doesn't fix the problem here (Sony
> PCG-Z600NE). Still the spontaneous reboot exactly the moment I expect to
> get my console back from resumeing.
Can you test whether it's the "and 0xfe" or the "or $2" that does it for
you?
Right now we know that the Olivetti M4 has problems with the "or $2". I'd
like to know if this is the same bit #1, or whether it's #0.
[ And I agree with Peter - if somebody knows BIOS programming and how to
use "int 15" to enter protected mode, then that migth well be the
easiest solution. The only real reason the linux setup code does it by
hand is that the original code was written that way - and it was written
that way because I had never used the BIOS in my life before, _and_ I
wanted to learn the i386. Both of which were valid reasons back in 1991.
Neither of which is probably a very good reason ten years later ;]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: That horrible hack from hell called A20
2000-12-06 0:48 99% ` Linus Torvalds
@ 2000-12-06 1:07 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 1:07 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: H. Peter Anvin, Alan Cox, Linux Kernel Mailing List
On Wed, 6 Dec 2000, Kai Germaschewski wrote:
>
> On Tue, 5 Dec 2000, H. Peter Anvin wrote:
>
> > If you have had A20M# problems with any kernel -- recent or not --
> > *please* try this patch, against 2.4.0-test12-pre5:
>
> Just a datapoint: This patch doesn't fix the problem here (Sony
> PCG-Z600NE). Still the spontaneous reboot exactly the moment I expect to
> get my console back from resumeing.
Actually, I bet I know what's up.
Want to bet $5 USD that suspend/resume saves the keyboard A20 state, but
does NOT save the fast-A20 gate information?
So anything that enables A20 with only the fast A20 gate will find that
A20 is disabled again on resume.
Which would make Linux _really_ unhappy, needless to say. Instant death in
the form of a triple fault (all of the Linux kernel code is in the 1-2MB
area, which would be invisible), resulting in an instant reboot.
Peter, we definitely need to do the keyboard A20, even if fast-A20 works
fine.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: That horrible hack from hell called A20
@ 2000-12-06 1:37 95% ` Linus Torvalds
2000-12-06 1:41 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2000-12-06 1:37 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kai Germaschewski, Alan Cox, Linux Kernel Mailing List
On Tue, 5 Dec 2000, H. Peter Anvin wrote:
>
> I might hack on using INT 15h to do the jump to protected mode, as ugly
> as it is, but I won't have time before my trip. It would require quite a
> bit of restructuring in setup.S, and would probably break LOADLIN.
Right now this is my interim patch (to clean test11). The thing to note is
that I decreased the keyboard controller timeout by a factor of about 167,
while making the "delay" a bit longer.
Now, if you don't have a keyboard controller, the bootup delay should be
on the order of 1.2 seconds or so (calling empty_8042 three times, each
around 0.4 seconds to time out). Which is acceptable. Especially as the
non-keyboard-controller machines that don't even emulate one are quite
rare. And it's still long enough that if the keyboard controller hasn't
emptied in 0.4 seconds, something else is badly wrong.
The non-keyboard-controller timeout used to be around three minutes
before. Which _definitely_ is excessive. Most people would assume that the
machine had hung.
Linus
----
--- v2.4.0-test11/linux/arch/i386/boot/setup.S Tue Oct 31 12:42:26 2000
+++ linux/arch/i386/boot/setup.S Tue Dec 5 17:31:53 2000
@@ -825,10 +825,18 @@
#
# Some machines have delusions that the keyboard buffer is always full
# with no keyboard attached...
+#
+# If there is no keyboard controller, we will usually get 0xff
+# to all the reads. With each IO taking a microsecond and
+# a timeout of 100,000 iterations, this can take about half a
+# second ("delay" == outb to port 0x80). That should be ok,
+# and should also be plenty of time for a real keyboard controller
+# to empty.
+#
empty_8042:
pushl %ecx
- movl $0x00FFFFFF, %ecx
+ movl $100000, %ecx
empty_8042_loop:
decl %ecx
@@ -867,7 +875,7 @@
# Delay is needed after doing I/O
delay:
- jmp .+2 # jmp $+2
+ outb %al,$0x80
ret
# Descriptor tables
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: That horrible hack from hell called A20
2000-12-06 1:37 95% ` Linus Torvalds
@ 2000-12-06 1:41 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 1:41 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kai Germaschewski, Alan Cox, Linux Kernel Mailing List
On Tue, 5 Dec 2000, Linus Torvalds wrote:
>
> Right now this is my interim patch (to clean test11). The thing to note is
> that I decreased the keyboard controller timeout by a factor of about 167,
> while making the "delay" a bit longer.
Oh, btw, I forgot to ask people to give this a whirl. I assume it fixes
the APM problems for Kai.
It definitely won't fix the silly Olivetti M4 issue (we still touch bit #2
in 0x92). We'll need to fix that by testing A20 before bothering with the
0x92 stuff. Alan, that should get fixed in 2.2.x too - clearly those
Olivetti machines can be considered buggy, but even so..
Who else had trouble with the keyboard controller?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test12-pre6
@ 2000-12-06 7:25 84% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 7:25 UTC (permalink / raw)
To: Kernel Mailing List
Ok, I almost called this the final test12, but I wanted to get some more
feedback on the keyboard controller stuff and PCI irq routing.
The biggest part of this is the budding parisc stuff, but it's unlikely
that we'll see full parisc support in 2.4.0 - the remaining pieces that
actually touch generic code aren't going to be as brainless to integrate.
Of this, the "exec_usermodehelper()" changes should fix a few problems for
people who rely heavily on automatic module loading, and the PCI irq
routing changes should hopefully fix a number of laptops.
Concering the PCI irq routing fixes in particular, I'd ask people with
laptops to start testing their kernels with PnP OS set to "yes" in the
BIOS setup. We shoul dbe at a stage where it should basically work all the
time, and it would be interesting to hear about cases that we don't handle
right.
(Anybody who has had problems with USB interrupts seemingly not being
delivered and similar is also encouraged to test this new kernel).
The APIC setup order should get older SMP machines working again (which
broke when we fixed some newer machines - let's hope that this time we fix
one machine without breaking another one).
Linus
----
- pre6:
- Alan Cox: synch. PA-RISC arch and bitops cleanups
- Maciej Rozycki: even more proper apic setup order.
- Andrew Morton: exec_usermodehelper fixes
- Adam Richter, Kai Germaschewski, me: PCI irq routing.
- revert A20 code changes. We really need to use the keyboard
controller if one exists. But decrease timeouts.
- Johannes Erdfelt: USB updates
- Ralf Baechle: MIPS memmove() fix.
- pre5:
- Jaroslav Kysela: ymfpci driver
- me: get rid of bogus MS_INVALIDATE semantics
- me: final part of the PageDirty() saga
- Rusty Russell: 4-way SMP iptables fix
- Al Viro: oops - bad ext2 inode dirty block bug
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
- Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work.
- Stephen Tweedie: fix inode dirty block handling
- Bill Hartner: reschedule_idle - prefer right cpu
- Johannes Erdfelt: USB updates
- Alan Cox: synchronize
- Richard Henderson: alpha updates and optimizations
- Geert Uytterhoeven: fbdev could be fooled into crashing fix
- Trond Myklebust: NFS filehandles in inode rather than dentry
- pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 84%]
* Re: PCI irq routing..
@ 2000-12-06 17:49 95% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 17:49 UTC (permalink / raw)
To: Martin Diehl
Cc: Kai Germaschewski, Adam J. Richter, Martin Mares, Kernel Mailing List
On Wed, 6 Dec 2000, Martin Diehl wrote:
>
> problems with recent 2.4.0-test1* on my HP OmniBook 800 are probably
> combined PCMCIA(CB) / PCI / APM issues. The point is my 16bit cards
> (modem+ne2k) are working perfectly fine with yenta sockets until the first
> suspend/resume. Afterwards the PCI config space of the Cardbus
> bridge(s) is completely messed up forcing me to reboot.
Ok. I actually knew of this issue, and it should be trivial to fix: we
should save and restore the 256-byte config space over suspends. CardBus
isn't the only controller that would need it.
Can you remind me in a day or two if I haven't gotten back to you? I don't
have any machines that need this, but I've seen ones that do, and if
you're willing to test..
> result: issue remains unchanged but nothing seems to be broken so far.
> The only difference I've noticed is the following two lines appearing when
> modprobing the pcmcia_core/yenta stuff:
>
> IRQ for 00:04.0(0) via 00:04.0 -> PIRQ 01, mask 8eb8, \
> excl 0000 -> newirq=9 ... failed
> IRQ for 00:04.1(1) via 00:04.1 -> PIRQ 04, mask 8eb8, \
> excl 0000 -> newirq=7 ... failed
Yes, this is expected for routers that we don't know about: we will still
use the irq that the device claims it has, but we will obviously fail to
try to route it (but it still works if the BIOS had already routed it -
which is how the old code always worked anyway).
Anyway, for the suspend-resume thing, if you want to go ahead on your own
without a real patch from me, the fix is along the lines of
- add a "u32 config_state[64]" array to pci_socket_t
- add two functions:
static void yenta_save_config(pci_socket_t *socket)
{
struct pci_dev *dev = socket->dev;
int i;
for (i = 0; i < 64; i++)
pci_read_config_dword(dev, i*4, socket->config_state+i);
}
static void yenta_restore_config(pci_socket_t *socket)
{
struct pci_dev *dev = socket->dev;
int i;
for (i = 0; i < 64; i++)
pci_write_config_dword(dev, i*4, socket->config_state[i]);
}
- do a "yenta_save_config()" in "yenta_suspend()" and a
"yenta_restore_config()" at the top of "yenta_resume()"
- test. Also test with the "pci_set_power_state(3)" in suspend enabled,
because it may/should actually work with that enabled too.
Any change in suspend/resume from the above?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: test12-pre6
@ 2000-12-06 18:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 18:38 UTC (permalink / raw)
To: Erik Mouw; +Cc: Kernel Mailing List
On Wed, 6 Dec 2000, Erik Mouw wrote:
>
> So at first the PCI code can't allocate an IRQ for devices 00:00.1
> (audio), 00:07.2 (USB), and 00:09.0 (winmodem), but after the audio and
> USB modules get inserted, IRQ 5 and 11 get allocated.
No, the irq stuff is a two-stage process: at first it only _reads_ the irq
config stuff for every device - whether they have a driver or not - and at
this stage it will not ever actually allocate and set up a new route. It
will just see if a route has already been set up by the BIOS.
Then, when a driver actually does a pci_enable_device(), it will do the
second stage of PCI irq routing, which is to actually set up a route if
none originally existed. So this is why you first se "failed" messages
(the generic "test if there is a route" code) and then later when loading
the module you see "allocated irq XX" messages.
So your dmesg output looks fine, and everything is ok at that level. The
fact that something still doesn't work for you indicates that we still
have problems, of course.
Can you tell me what device it is that doesn't work for you?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: test12-pre6
@ 2000-12-06 19:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 19:38 UTC (permalink / raw)
To: Erik Mouw; +Cc: Kernel Mailing List, jerdfelt, usb
On Wed, 6 Dec 2000, Erik Mouw wrote:
> >
> > Can you tell me what device it is that doesn't work for you?
>
> The USB controller. That's device 00:07.2:
>
> 00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller (prog-if 00 [UHCI])
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin D routed to IRQ 11
> Region 4: I/O ports at fcc0 [size=32]
Now, this is with a bog-standard PIIX irq router, so we definitely know
that we have the pirq table parsing right. I even have unofficial
confirmation from intel engineers on this.
But I see something obviously wrong there: you have busmaster disabled.
Looking into the UHCI controller code, I notice that neither UHCI driver
actually does the (required)
pci_set_master(dev);
Please add that to just after a successful "pci_enable_device(dev)", and I
just bet your USB will start working.
Johannes, Georg, the above is a fairly embarrassing bug, and is likely to
explain a _lot_ of USB failures (the OHCI driver does do this, btw).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
@ 2000-12-06 19:46 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 19:46 UTC (permalink / raw)
To: Tigran Aivazian; +Cc: Alexander Viro, linux-kernel
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
>
> This patch combines your previous patch with 2 changes I have just
> suggested. Both changes are obvious (and correct).
Why remove the EROFS test?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: The horrible hack from hell called A20
@ 2000-12-06 20:05 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-06 20:05 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel
On Wed, 6 Dec 2000, Miles Lane wrote:
>
> If I insert both my 3c575 and Belkin BusPort Mobile USB host-controller
> and then enable both of them, "modprobe usb-ohci" hangs. If I then
> attempt "modprobe -r 3c59x", that process hangs, too. lsmod shows:
>
> usb-ohci 15072 1 (initializing)
> 3c59x 0 0 (deleted)
> usbcore 50384 1 (autoclean) [usb-ohci]
The only thing in common between the two will be the fact that they do
share the same irq, and I'm not at all sure that those two drivers are
always happy about irq sharing.
Your dmesg output looks sane and happy, though. Both the USB and the 3c59x
driver find their hardware, and claim to have successfully initialized
them. The USB driver even finds the stuff on the USB bus (microsoft
intellimouse), so it obviously works to a large degree. Similarly, the
ethernet driver happily finds everything etc.
In fact, everything looks so happy that I bet that the reason the module
is stuck initializing is some setup problem, possibly because kusbd ends
up waiting on /sbin/hotplug or similar. It does not look like the drivers
themselves would have trouble, it looks much more like a modprobe-related
issue (maybe deadlocking on some semaphore or other lock).
I'd suggest two things:
- try not using modules. Does it "just work" for you then? (Both the OHCI
and the 3c59x driver should happily work with hotplug compiled right
into the kernel).
- try "strace"ing the whole modprobe thing, to see where it hangs, in
order to figure out what it is waiting for. I wonder if it's the
keventd changes.
Basically, I think this is a completely different problem, and not really
driver-related any more.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* 2.4.0-test12-pre7
[not found] <Pine.LNX.4.10.10012061618300.2415-100000@penguin.transmeta.com>
@ 2000-12-07 1:29 88% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-07 1:29 UTC (permalink / raw)
To: Kernel Mailing List; +Cc: Nils Faerber, Christoph Hellwig
The only reason for this pre7 is to resolve some warring patches in the
cs46xx driver.
Linus
---
- test7:
- Kai Germaschewski: ymfpci cleanups and resource leak fixes
- me: UHCI drivers really need to enable bus mastering.
- Trond Myklebust: fix up nfs_writepage_sync() to not require "filp".
- Andrew Morton: "tq_scheduler" is no more. We have keventd.
- Nils Faerber: cs46xx sounddriver update
- pre6:
- Alan Cox: synch. PA-RISC arch and bitops cleanups
- Maciej Rozycki: even more proper apic setup order.
- Andrew Morton: exec_usermodehelper fixes
- Adam Richter, Kai Germaschewski, me: PCI irq routing.
- revert A20 code changes. We really need to use the keyboard
controller if one exists.
- Johannes Erdfelt: USB updates
- Ralf Baechle: MIPS memmove() fix.
- pre5:
- Jaroslav Kysela: ymfpci driver
- me: get rid of bogus MS_INVALIDATE semantics
- me: final part of the PageDirty() saga
- Rusty Russell: 4-way SMP iptables fix
- Al Viro: oops - bad ext2 inode dirty block bug
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
- Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work.
- Stephen Tweedie: fix inode dirty block handling
- Bill Hartner: reschedule_idle - prefer right cpu
- Johannes Erdfelt: USB updates
- Alan Cox: synchronize
- Richard Henderson: alpha updates and optimizations
- Geert Uytterhoeven: fbdev could be fooled into crashing fix
- Trond Myklebust: NFS filehandles in inode rather than dentry
- pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 88%]
* Re: The horrible hack from hell called A20
@ 2000-12-07 2:27 98% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-07 2:27 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel
On Wed, 6 Dec 2000, Miles Lane wrote:
>
> Here is what goes wrong:
>
> Dec 6 04:21:32 agate kernel: eth0: Host error, FIFO diagnostic register 0000.
But it continues to work, right?
I bet that your ethernet card is just unhappy that it couldn't get DMA in
time, because the bus was so busy. Many of the busmastering ethernet
devices will start the packet send early, happy in the knowledge that
they'll usually have plenty of time to DMA the data by the time they need
it.
This works fine most of the time, but if you have a busy PCI bus and
you're doing things over a (potentially slow) PCI bridge like the Cardbus
bridge, you're taking chances. And sometimes those chances do not work out
ok.. Especially if you have slow memory, which most laptops have.
I suspect that the worst result of this is just a noisy driver: both on
the network (runt packets) and on the console. And it obviously will cause
performance to suffer too, due to retransmitting packets that failed,
and/or losing packets.
There may be some rule for the threshold for sending packets or something
else to make this happen less, so this is probably tweakable. But it
doesn't sound deadly (unless the driver causes this to result in a dead
network - does it?)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 98%]
* Re: The horrible hack from hell called A20
@ 2000-12-07 7:10 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-07 7:10 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel
On Wed, 6 Dec 2000, Miles Lane wrote:
>
> I have also just tried a test pass with 3c59x built in and
> USB built as modules. I booted with only the 3c575 inserted.
> I got eth0 running and then loaded usb-ohci (with the enable
> bus mastering change added). This resulted in modprobe hanging
> again.
I bet you're hanging on the rtnl_semaphore due to having a /sbin/hotplug
policy.
Miles, mind trying out a really simple change in the
____call_usermodehelper() function in kernel/kmod.c?
Change: #if 0 out the whole block that says "if (retval >= 0)" and does
the waiting for the child. We shouldn't wait for the user mode helper:
that's just going to cause nasty deadlocks. Deadlocks like the one you
seem to be seeing, in fact.
Does your ifconfig problem go away with that fix?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: 2.4.0-test12-pre7
@ 2000-12-07 17:34 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-07 17:34 UTC (permalink / raw)
To: Russell King; +Cc: Kernel Mailing List
On Thu, 7 Dec 2000, Russell King wrote:
>
> Is it intentional that pci_assign_unassigned_resources should:
> 1. enable all devices?
> 2. enable bus master on all devices?
Probably intentional, but probably for all the wrong reasons.
The device enabling is still required for all drivers that aren't PCI
aware of PCI PnP issues. And remember - that used to be pretty much every
single Linux driver out there. So a traditional Linux system pretty much
required that all the devices came up fully enabled, because most drivers
wouldn't know to enable them (as shown by the UHCI bug).
These days, we should probably remove all the logic to enable everything
in pci_assign_unassigned_resources(), because these days pretty much all
PCI drivers are supposed to know about enabling the device (otherwise they
wouldn't work in a PC PnP environment anyway).
The only special case to this rule is "legacy devices" - things like
serial ports in legacy regions, VGA consoles etc, where a driver can use
them without even being aware of the fact that the hardware may be PCI.
Those devices tend to need setup even just for booting, though, so they
tend to be enabled rather early for other reasons anyway.
So I would probably vote for getting rid of the device enables in
pci_assign_unassigned_resources() (for all the reasons already mentioned
by others - scribbling over memory due to not being quiescent etc). But
it's not worth breaking now. 2.5.x material. Most PCI drivers may already
do the right thing, but I bet that the USB driver wasn't the only one who
forgot..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: PCI irq routing..
@ 2000-12-07 18:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-07 18:38 UTC (permalink / raw)
To: Martin Diehl
Cc: Kai Germaschewski, Adam J. Richter, Martin Mares, Kernel Mailing List
On Thu, 7 Dec 2000, Martin Diehl wrote:
>
> btw, I'm thinking I could guess the routing from the VLSI config space,
> but I don't have any doc's. Would it be worth to try to add some specific
> get/set methods for this device? What about testers (or people who have
> access to the docs)?
Please do. You might leave them commented out right now, but this is
actually how most of the pirq router entries have been created: by looking
at various pirq tables and matching them up with other (non-pirq)
documentation and testing. Th epirq "link" value is basically completely
NDA'd, and is per-chipset-specific. Nobody documents it except in their
bios writers guide, if even there.
> yenta_resume() does not exist.
> yenta_*() replaced by cardbus_*() as explained.
Yes.
> The reason for this is in drivers/pci.c where bridges are touched
> twice: once as a device on a bus and once via ->self from the bus behind.
> I'm not sure whether this is the intended behavior - but it definitely
> calls cardbus_suspend/resume() twice which breaks when forwarding to
> pcmcia_suspend/resume_socket().
Not intended behaviour. The self case should be removed.
> So I've tentatively worked around using a "once" flag added to
> pci_socket_t. This solves the problems during suspend/resume and the
> cardbus' config space appears to be restored as intended - good.
>
> The bad news however is, the sockets are still broken after
> resume. Unfortunately there are several candidates I've spotted:
>
> - calling yenta_init() stuff at resume - is this sufficient?
> Probably we have to forward the pm-triggered resume from pm along
> pci -> cardbus -> pcmcia -> yenta (last link currently missed,
> because the pcmcia layer switches from incoming resume notification
> to init path)
>
> - some content of the mem/io regions might need to be preserved
>
> - some TI1131 oddity wrt to CSC-INT's - requested IRQ's show up correctly
> in /proc/interrupts and are properly triggered and handled at card
> insert/eject. But after pm suspend/resume the box freezed when inserting
> or ejecting the cards (no response to SysRq anymore).
Ok, definitely needs some more work. Thanks for testing - I have no
hardware where this is needed.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: kernel BUG at buffer.c:827! and scsi modules no load at boot w/ initrd - test12pre7
@ 2000-12-07 22:19 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-07 22:19 UTC (permalink / raw)
To: linux-kernel
In article <3A2FF076.946076FC@haque.net>,
Mohammad A. Haque <mhaque@haque.net> wrote:
>
>I'm getting a BUG at boot in buffer.c:827. Oops/ksymoops at teh end of
>this message. I also noticed that the driver for my scsi card isn't
>loading at boot if compiled as a module using initrd. This is what I get
>during the boot process.
This is a new BUG-check, where "UnlockPage()" actually verifies that the
page was locked before it unlocks it.
Trying to unlock a page that isn't locked is a nasty bug - if it happens
it probably also means that with some bad luck that unlock could have
unlocked the page that somebody _else_ had locked, and expected to stay
locked until it was unlocked properly.
(It may also be that the BUG() is due to exactly that - somebody else
who didn't have the lock unlocked the page from under you, and the
_proper_ unlocker will in that case be the one that oopses).
Do you have something special that triggers this? Can you test if it
only happens with initrd, for example?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-08 0:22 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 0:22 UTC (permalink / raw)
To: linux-kernel
In article <3A30125D.5F71110D@cheek.com>,
Joseph Cheek <joseph@cheek.com> wrote:
>copying files off a loopback-mounted vfat filesystem exposes this bug.
>test11 worked fine.
It's not a new bug - it's an old bug that apparently is uncovered by a
new stricter test.
Apparently loopback unlocks an already unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the BUG().
Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so
it's impossible to debug, but it's already interesting information to
see that it seems to be either loopback of vfat.
Can you test some more? In particular, I'd love to hear if this happens
with vfat even without loopback, or with loopback even without vfat
(make an ext2 filesystem or similar instead). That woul dnarrow down the
bug further.
Thanks,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Linux 2.2.18pre25
@ 2000-12-08 1:27 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 1:27 UTC (permalink / raw)
To: linux-kernel
In article <E144Bhf-0003GN-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>Excellent. I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting
>muddled together and hard to debug. Running with page aging convinces me that
>2.2.19 we need to sort some of the vm issues out badly, and make it faster than
>2.4test 8)
Ahh.. The challenge is out!
You and me. Mano a mano.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH,preliminary] cleanup shm handling
@ 2000-12-08 18:26 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 18:26 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-kernel, ch.rohland
On 8 Dec 2000, Christoph Rohland wrote:
>
> here is my first shot for cleaning up the shm handling. It did survive
> some basic testing but is not ready for inclusion.
The only comment I have right now is that you probably should not mark the
page dirty in "nopage" - theoretically somebody might have a sparse
mapping and depend on zero pages for the ones that aren't touched. It's
better to delay the dirty marking until swapout() (and write(), when that
is implemented), so that we don't needlessly create swap entries for zero
pages.
(No, probably nobody does this for traditional shared memory, but I could
well imagine mmap() on /dev/zero with most of the pages being read-only).
Other than that the approach at least looks reasonable. And cleaner than
what we currently have.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-08 18:48 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 18:48 UTC (permalink / raw)
To: Alexander Viro; +Cc: David Woodhouse, linux-kernel
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Fix: postpone changing ->b_end_io until the call of ll_rw_block(); if by
> the time of ll_rw_block() some fragments will still have IO in progress -
> wait on them.
>
> Comments?
Yes.
On the other hand, I have this suspicion that there is an even simpler
solution: stop using the end_buffer_io_sync version for writes
altogether.
It's really only __block_prepare_write() that can mark the buffers for
sync writes, and even that case is fairly bogus: it really only wants to
mark the non-upto-date buffers that it wants to _read_ for sync IO, it
just "knows" that it is ok to change every buffer it sees. It isn't.
Moving the
bh->b_end_io = end_buffer_io_sync;
into the read-path should be sufficient (hell, we should move the
"ll_rw_block(READ, 1, &bh)" away, and make it one single read with
ll_rw_block(READ, wait_bh-wait, wait);
at the end of the loop.
If we do it that way, there is no way the two can clash, because a
non-up-to-date buffer head won't ever be touched by the write path, so we
can't get this kind of confusion.
Al? I'd really prefer this alternative instead. Do you see any problems
with it?
(New rule that makes 100% sense: NOBODY sets "bh->b_end_io" on any buffer
that he isn't actually going to do IO on. And if there is pending IO on
the buffer, it had better only be of the same type as the one you're going
to do).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-08 19:39 95% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 19:39 UTC (permalink / raw)
To: Alexander Viro; +Cc: David Woodhouse, linux-kernel
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> but that will make for somewhat bigger patch. Hey, _you_ are in position
> to change the locking rules, freeze or not, so if it's OK with you...
No.
Read the code a bit more.
commit_write() doesn't start any IO at all. It only marks the buffer
dirty.
The dirty flush-out works the way it has always worked.
(You're right in that the dirty flusher should make sure to change
b_end_io when they do their write-outs - that code used to just depend on
the buffer always having b_end_io magically set)
> Hrm. Why not move setting ->b_end_io to ll_rw_block() while we are at it?
> Or into ll_rw_block() wrapper...
That's too big a change right now, but yes, in theory. That would make
sure that nobody could ever forget to set the "completion" handler.
In the meantime, let's just enforce it for ll_rw_block: make sure that
there is a 1:1 mapping between setting b_end_io and doing a ll_rw_block
(and let's make sure that there are no more of these non-local rules any
more).
Btw, I also think that the dirty buffer flushing should get the page lock.
Right now it touches the buffer list without holding the lock on the page
that the buffer is on, which means that there is really nothign that
prevents it from racing with the page-based writeout. I don't like that:
it does hold the LRU list lock, so the list state itself is ok, but it
does actually touch part of the buffer state that is not really protected
by the lock.
I think it ends up being ok because ll_rw_block will ignore buffers that
get output twice, and the rest of the state is handled with atomic
operations (b_count and b_flags), but it's not really proper. If
flush_dirty_buffers() got the page lock, everything would be protected
properly. Thoughts?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-08 21:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 21:17 UTC (permalink / raw)
To: Daniel Phillips; +Cc: Alexander Viro, David Woodhouse, linux-kernel
On Fri, 8 Dec 2000, Daniel Phillips wrote:
>
> [ flush-buffers taking the page lock ]
>
> This is great when you have buffersize==pagesize. When there are
> multiple buffers per page it means that some of the buffers might have
> to wait for flushing just because bdflush started IO on some other
> buffer on the same page. Oh well. The common case improves in terms
> being proveably correct and the uncommon case gets worse a tiny bit.
> It sounds like a win.
Also, I think that we should strive for a setup where most of the dirty
buffer flushing is done through "page_launder()" instead of using
sync_buffers all that much at all.
I'm convinced that the page LRU list is as least as good as, if not better
than, the dirty buffer timestamp stuff. And as we need to have the page
LRU for other reasons anyway, I'd like the long-range plan to be to get
rid of the buffer LRU completely. It wastes memory and increases
complexity for very little gain, I think.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Serial cardbus code.... for testing, please.....
@ 2000-12-08 21:27 97% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 21:27 UTC (permalink / raw)
To: tytso; +Cc: rgooch, jgarzik, dhinds, linux-kernel
I didn't have time to do more than just quickly apply the patch and leave
in a hurry, but my Vaio certainly recognized the serial port on the combo
cardbus card I have with this patch. Everything looked fine - I got a
message saying it found a 16450 on ttyS4 when I plugged the card in.
Ted, I have the in-kernel pcmcia on both Toves VAIO 505VE, and on both the
VAIO picturebooks I have (Pentium/MMX 266 and crusoe-600), and I saw the
serial chip on the first try with your patch. I'm surprised you seem to
have so many problems. All the thin-and-light VAIO's have very similar
electronics (the big power-VAIO's are different, but you said you had a
505VX, right?).
Why are you using "epic_cb"? That's almost certainly not going to work
with the in-kernel cardbus driver. Use the standard epic100 PCI driver, it
should work directly. No need to mess with any modules, or anything like
that. You don't even need cardmgr - the device just shows up. Same thing
with the serial card - remove all traces of serial_cb.
(Of course, I use tulip instead of epic100, so maybe there's an epic
driver bug, but it's definitely hotplug-aware).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 97%]
* Re: [PATCH,preliminary] cleanup shm handling
@ 2000-12-08 22:36 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 22:36 UTC (permalink / raw)
To: Christoph Rohland; +Cc: linux-kernel, ch.rohland
On 8 Dec 2000, Christoph Rohland wrote:
>
> Linus Torvalds <torvalds@transmeta.com> writes:
> > On 8 Dec 2000, Christoph Rohland wrote:
> > >
> > > here is my first shot for cleaning up the shm handling. It did
> > > survive some basic testing but is not ready for inclusion.
> >
> > The only comment I have right now is that you probably should not
> > mark the page dirty in "nopage" - theoretically somebody might have
> > a sparse mapping and depend on zero pages for the ones that aren't
> > touched. It's better to delay the dirty marking until swapout() (and
> > write(), when that is implemented), so that we don't needlessly
> > create swap entries for zero pages.
>
> OK. I simply copied that from shm.c without thinking. Actually I do
> not yet understand the implications of it. (I never thought that I
> would get so deeply involved into these issues and still struggle
> often with the details)
Basically, a clean page will just get dropped by the VM, because it knows
it can always re-create the contents.
So let's assume that you do a large mmap(MAP_SHARED) (or IPC shmem
mapping), and you populate your VM space with pages by just reading from
it. This is not common, but it does happen - things like sparse files
where just the fact that nothing has been written to a certain location is
information in itself.
Now, assume you run out of memory. With your current patch, we'd start
moving these zero-filled pages to the inode cache and write them out:
first we'd drop the entries from the page tables, then we'd call
"writepage()" to write the page to disk.
If, instead, you don't mark the page dirty immediately, but you wait until
somebody does a write, or until the VM layer informs you through the
"swapout()" function that somebody had a dirty page table entry, what
would happen is that (because nobody actually wrote to the page yet) it
would just get dropped from the VM space, and writepage() would never be
called.
> > Other than that the approach at least looks reasonable. And cleaner
> > than what we currently have.
>
> Only reasonable? :-(
I did not have time to give it a good check, and "reasonable" is the
highest praise I'll give without having checked that there aren't any real
gotchas.
I certainly think that this is the right way to do things. I haven't had
time to check whether it's perfect.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-08 22:42 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-08 22:42 UTC (permalink / raw)
To: Alexander Viro; +Cc: David Woodhouse, linux-kernel
On Fri, 8 Dec 2000, Alexander Viro wrote:
>
> I'm quite aware of that fact ;-) However, you said
>
> On the other hand, I have this suspicion that there is an even simpler
> solution: stop using the end_buffer_io_sync version for writes
> altogether.
>
> If that happens (i.e. if write requests resulting from prepare_write()/
> commit_write()/bdflush sequence become async) we must stop unlocking pages
> after commit_write(). Essentially it would become unlocker of the same
> kind as readpage() and writepage() - callers must assume that page submitted
> to commit_write() will eventually be unlocked.
You're right, we can't do that for anonymous buffers right now. Mea culpa.
Looking more at this issue, I suspect that the easiest pretty solution
that everybody can probably agree is reasonable is to either pass down the
end-of-io callback to ll_rw_block as you suggested, or, preferably by just
forcing the _caller_ to do the buffer locking, and just do the b_end_io
stuff inside the buffer lock and get rid of all the races that way
instead (and make ll_rw_block() verify that the buffers it is passed are
always locked).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Serial cardbus code.... for testing, please.....
@ 2000-12-09 7:41 95% ` Linus Torvalds
2000-12-09 7:48 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-09 7:41 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: rgooch, jgarzik, dhinds, linux-kernel
On Sat, 9 Dec 2000, Theodore Y. Ts'o wrote:
>
> I didn't have time to do more than just quickly apply the patch and leave
> in a hurry, but my Vaio certainly recognized the serial port on the combo
> cardbus card I have with this patch. Everything looked fine - I got a
> message saying it found a 16450 on ttyS4 when I plugged the card in.
>
> When you have a chance, can you check and make sure that you actually
> can talk to the modem? That will make me feel much better.....
Done.
It works perfectly fine for me, with the following caveat:
It crashes hard if I remove the card while the modem is in use, though (ie
insert card, point minicom at it, sit at the minicom window while removing
the card).
This is a problem that many drivers have: when the card is removed, the
driver sees an interrupt (which happens to be the CardBus card removal
interrupt, but the serial driver doesn't know that, and the way cardbus
interrupts work it's always shared with the driver).
So the serial driver reads the modem status byte, which is all ones, and
decides that there is a ton of work to do. It then loops forever, because
the status byte bits will obviously continue to be all ones.
Note how the "rs_interrupt()" routine _tries_ to avoid this by having a
pass counter value, but that logic never triggers because we will loop
forever in receive_chars(), so the rs_interrupt() counter never even gets
to increment.
> Once I fixed the /etc/pcmcia/config file, was able to start up the
> epic100 driver with cardmgr. I was also able to (with cardmgr not
> running) load the epic100 module, and lo and behold it worked.
You should also just test having it compiled in - I know some people love
modules, but there is nothing quite as liberating as just having a kernel
that finds the devices it needs and doesn't need anything else.
> But then I ran into the second problem, which seems to afflict all
> PCMCIA/CARDBUS serial devices which I've tried. That problem is the one
> which I alluded to in an eariler messages; it looks like some or all of
> the I/O port window for the serial device isn't getting set up properly.
I'm sitting here with a minicom session, talking to the modem. Maybe you
have a device that is not a standard UART?
> This makes me suspicious that the I/O windows for the serial drivers
> aren't getting set correctly. And whatever the problem, it's affecting
> both PCMCIA devices (which still use serial_cs), as well as cardbus
> drivers, which is just using serial.o. And this is why I asked you
> whether or not you can actually talk to the modem.
I have the serial.c driver compiled into the kernel, and apart from the
glitch I can _definitely_ talk to the modem just fine.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 95%]
* Re: Serial cardbus code.... for testing, please.....
2000-12-09 7:41 95% ` Linus Torvalds
@ 2000-12-09 7:48 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-09 7:48 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: rgooch, jgarzik, dhinds, linux-kernel
Oh, I forgot to mention: I use a slight modification to your patch: you
left some functions as "__init/__initdata" functions/data even though they
are should definitely be __devinit/__devinitdata for all the hotplug
stuff. So the thing that works for me has had a global search-and-replace
to replace all "__init" with "__devinit".
If you're testing with just modules, you shouldn't see this effect,
though (otherwise you might get strange oopsen and/or corrupted initdata,
of course).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-09 8:45 66% ` Linus Torvalds
2000-12-09 8:56 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2000-12-09 8:45 UTC (permalink / raw)
To: Alexander Viro; +Cc: David Woodhouse, Kernel Mailing List
On Fri, 8 Dec 2000, Alexander Viro wrote:
> On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
> > Looking more at this issue, I suspect that the easiest pretty solution
> > that everybody can probably agree is reasonable is to either pass down the
> > end-of-io callback to ll_rw_block as you suggested, or, preferably by just
> > forcing the _caller_ to do the buffer locking, and just do the b_end_io
> > stuff inside the buffer lock and get rid of all the races that way
> > instead (and make ll_rw_block() verify that the buffers it is passed are
> > always locked).
>
> Hmm... I've looked through the ll_rw_block() callers and yes, it seems
> to be doable.
Looking at this, there's a _lot_ of them.
I've taken a test-approach that is fairly simple:
- get rid of the old "ll_rw_block()", because it was inherently racey wrt
bh->b_end_io, I think we all agree that changing bh->b_end_io without
holding any locks at all is fairly dangerous.
- instead, a simple "submit_bh()" thing, that takes only one locked
buffer head at a time, and queues it for IO. The usage would basically
be
lock_buffer(bh);
bh->b_end_io = completion_callback;
submit_bh(READ|WRITE, bh);
which is a pretty clean and simple interface that has no obvious
races - submit_bh() will set bh->b_end_io to the completion callback.
- BUT BUT BUT: Because of tons of old users of ll_rw_block(), we
introduce a totally new ll_rw_block() that has the same old interface,
but basically does
void ll_rw_block(int op, int nr, struct buffer_head **array)
{
int i;
for (i = 0; i < nr; i++) {
struct buffer_head * bh = array[i];
lock_buffer(bh);
bh->b_end_io = end_buffer_io_sync;
submit_bh(op, bh);
}
}
Again, the above avoids the race (we never touch b_end_io except with
the buffer lock held), and allows all old uses of "ll_rw_block()"
_except_ the ones that wanted to do the fancy async callbacks.
The advantage? All the regular old code that isn't fancy (ie the low-level
filesystems, bread(), breada() etc) will get a working ll_rw_block() with
the semantics they want, and we can pretty much prove that they can never
get an async handler even by mistake.
And the (few) clever routines in fs/buffer.c that currently use
ll_rw_block() with async handlers can just be converted to use the
submit_bh() interface.
This is a preliminary patch that I have not compiled and probably breaks,
but you get the idea. I'm going to sleep, to survive another night with
three small kids.
If somebody wants to run with this, please try it out, but realize that
it's a work-in-progress. And realize that bugs in this area tend to
corrupt filesystems very quickly indeed. I would strongly advice against
trying this patch out without really grokking what it does and feeling
confident that it actually works.
NOTE NOTE NOTE! I've tried to keep the patch small and simple. I've tried
to make all the changes truly straightforward and obvious. I want this bug
squashed, and I don't want to see it again. But I _still_ think this is a
dangerous patch until somebody like Al has given it a green light. Caveat
Emptor.
Linus
-----
diff -u --recursive t12p7/linux/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c
--- t12p7/linux/drivers/block/ll_rw_blk.c Thu Dec 7 15:56:25 2000
+++ linux/drivers/block/ll_rw_blk.c Sat Dec 9 00:40:35 2000
@@ -885,6 +885,36 @@
while (q->make_request_fn(q, rw, bh));
}
+
+/*
+ * Submit a buffer head for IO.
+ */
+void submit_bh(int rw, struct buffer_head * bh)
+{
+ if (!test_bit(BH_Lock, &bh->b_state))
+ BUG();
+
+ set_bit(BH_Req, &bh->b_state);
+
+ /*
+ * First step, 'identity mapping' - RAID or LVM might
+ * further remap this.
+ */
+ bh->b_rdev = bh->b_dev;
+ bh->b_rsector = bh->b_blocknr * (bh->b_size>>9);
+
+ generic_make_request(rw, bh);
+}
+
+/*
+ * Default IO end handler, used by "ll_rw_block()".
+ */
+static void end_buffer_io_sync(struct buffer_head *bh, int uptodate)
+{
+ mark_buffer_uptodate(bh, uptodate);
+ unlock_buffer(bh);
+}
+
/* This function can be used to request a number of buffers from a block
device. Currently the only restriction is that all buffers must belong to
the same device */
@@ -931,7 +961,8 @@
if (test_and_set_bit(BH_Lock, &bh->b_state))
continue;
- set_bit(BH_Req, &bh->b_state);
+ /* We have the buffer lock */
+ bh->b_end_io = end_buffer_io_sync;
switch(rw) {
case WRITE:
@@ -954,17 +985,9 @@
end_io:
bh->b_end_io(bh, test_bit(BH_Uptodate, &bh->b_state));
continue;
-
}
- /*
- * First step, 'identity mapping' - RAID or LVM might
- * further remap this.
- */
- bh->b_rdev = bh->b_dev;
- bh->b_rsector = bh->b_blocknr * (bh->b_size>>9);
-
- generic_make_request(rw, bh);
+ submit_bh(rw, bh);
}
return;
@@ -972,7 +995,6 @@
for (i = 0; i < nr; i++)
buffer_IO_error(bhs[i]);
}
-
#ifdef CONFIG_STRAM_SWAP
extern int stram_device_init (void);
diff -u --recursive t12p7/linux/fs/buffer.c linux/fs/buffer.c
--- t12p7/linux/fs/buffer.c Thu Dec 7 15:56:26 2000
+++ linux/fs/buffer.c Sat Dec 9 00:38:20 2000
@@ -758,12 +758,6 @@
bh->b_private = private;
}
-static void end_buffer_io_sync(struct buffer_head *bh, int uptodate)
-{
- mark_buffer_uptodate(bh, uptodate);
- unlock_buffer(bh);
-}
-
static void end_buffer_io_bad(struct buffer_head *bh, int uptodate)
{
mark_buffer_uptodate(bh, uptodate);
@@ -1001,7 +995,7 @@
* and it is clean.
*/
if (bh) {
- init_buffer(bh, end_buffer_io_sync, NULL);
+ init_buffer(bh, end_buffer_io_bad, NULL);
bh->b_dev = dev;
bh->b_blocknr = block;
bh->b_state = 1 << BH_Mapped;
@@ -1210,7 +1204,6 @@
if (buffer_uptodate(bh))
return(bh);
- else ll_rw_block(READ, 1, &bh);
blocks = (filesize - pos) >> (9+index);
@@ -1225,12 +1218,11 @@
brelse(bh);
break;
}
- else bhlist[j++] = bh;
+ bhlist[j++] = bh;
}
/* Request the read for these buffers, and then release them. */
- if (j>1)
- ll_rw_block(READA, (j-1), bhlist+1);
+ ll_rw_block(READ, j, bhlist);
for(i=1; i<j; i++)
brelse(bhlist[i]);
@@ -1439,7 +1431,7 @@
block = *(b++);
tail = bh;
- init_buffer(bh, end_buffer_io_async, NULL);
+ init_buffer(bh, end_buffer_io_bad, NULL);
bh->b_dev = dev;
bh->b_blocknr = block;
@@ -1586,8 +1578,6 @@
int err, i;
unsigned long block;
struct buffer_head *bh, *head;
- struct buffer_head *arr[MAX_BUF_PER_PAGE];
- int nr = 0;
if (!PageLocked(page))
BUG();
@@ -1600,6 +1590,8 @@
bh = head;
i = 0;
+
+ /* Stage 1: make sure we have all the buffers mapped! */
do {
/*
* If the buffer isn't up-to-date, we can't be sure
@@ -1616,28 +1608,32 @@
if (buffer_new(bh))
unmap_underlying_metadata(bh);
}
- set_bit(BH_Uptodate, &bh->b_state);
- set_bit(BH_Dirty, &bh->b_state);
+ bh = bh->b_this_page;
+ block++;
+ } while (bh != head);
+
+ /* Stage 2: lock the buffers, mark them dirty */
+ do {
+ lock_buffer(bh);
bh->b_end_io = end_buffer_io_async;
atomic_inc(&bh->b_count);
- arr[nr++] = bh;
+ set_bit(BH_Uptodate, &bh->b_state);
+ set_bit(BH_Dirty, &bh->b_state);
bh = bh->b_this_page;
- block++;
} while (bh != head);
- if (nr) {
- ll_rw_block(WRITE, nr, arr);
- } else {
- UnlockPage(page);
- }
+ /* Stage 3: submit the IO */
+ do {
+ submit_bh(WRITE, bh);
+ bh = bh->b_this_page;
+ } while (bh != head);
+
+ /* Done - end_buffer_io_async will unlock */
SetPageUptodate(page);
return 0;
+
out:
- if (nr) {
- ll_rw_block(WRITE, nr, arr);
- } else {
- UnlockPage(page);
- }
+ UnlockPage(page);
ClearPageUptodate(page);
return err;
}
@@ -1669,7 +1665,6 @@
continue;
if (block_start >= to)
break;
- bh->b_end_io = end_buffer_io_sync;
if (!buffer_mapped(bh)) {
err = get_block(inode, block, bh, 1);
if (err)
@@ -1766,7 +1761,6 @@
unsigned long iblock, lblock;
struct buffer_head *bh, *head, *arr[MAX_BUF_PER_PAGE];
unsigned int blocksize, blocks;
- char *kaddr = NULL;
int nr, i;
if (!PageLocked(page))
@@ -1793,35 +1787,40 @@
continue;
}
if (!buffer_mapped(bh)) {
- if (!kaddr)
- kaddr = kmap(page);
- memset(kaddr + i*blocksize, 0, blocksize);
+ memset(kmap(page) + i*blocksize, 0, blocksize);
flush_dcache_page(page);
+ kunmap(page);
set_bit(BH_Uptodate, &bh->b_state);
continue;
}
}
- init_buffer(bh, end_buffer_io_async, NULL);
- atomic_inc(&bh->b_count);
arr[nr] = bh;
nr++;
} while (i++, iblock++, (bh = bh->b_this_page) != head);
- if (nr) {
- if (Page_Uptodate(page))
- BUG();
- ll_rw_block(READ, nr, arr);
- } else {
+ if (!nr) {
/*
* all buffers are uptodate - we can set the page
* uptodate as well.
*/
SetPageUptodate(page);
UnlockPage(page);
+ return 0;
}
- if (kaddr)
- kunmap(page);
+
+ /* Stage two: lock the buffers */
+ for (i = 0; i < nr; i++) {
+ struct buffer_head * bh = arr[i];
+ lock_buffer(bh);
+ bh->b_end_io = end_buffer_io_async;
+ atomic_inc(&bh->b_count);
+ }
+
+ /* Stage 3: start the IO */
+ for (i = 0; i < nr; i++)
+ submit_bh(READ, arr[i]);
+
return 0;
}
@@ -1989,7 +1988,6 @@
if (Page_Uptodate(page))
set_bit(BH_Uptodate, &bh->b_state);
- bh->b_end_io = end_buffer_io_sync;
if (!buffer_uptodate(bh)) {
err = -EIO;
ll_rw_block(READ, 1, &bh);
@@ -2263,67 +2261,31 @@
*/
int brw_page(int rw, struct page *page, kdev_t dev, int b[], int size)
{
- struct buffer_head *head, *bh, *arr[MAX_BUF_PER_PAGE];
- int nr, fresh /* temporary debugging flag */, block;
+ struct buffer_head *head, *bh;
if (!PageLocked(page))
panic("brw_page: page not locked for I/O");
-// ClearPageError(page);
- /*
- * We pretty much rely on the page lock for this, because
- * create_page_buffers() might sleep.
- */
- fresh = 0;
- if (!page->buffers) {
- create_page_buffers(rw, page, dev, b, size);
- fresh = 1;
- }
+
if (!page->buffers)
+ create_page_buffers(rw, page, dev, b, size);
+
+ head = bh = page->buffers;
+ if (!head)
BUG();
- head = page->buffers;
- bh = head;
- nr = 0;
+ /* Stage 1: lock all the buffers */
do {
- block = *(b++);
+ lock_buffer(bh);
+ bh->b_end_io = end_buffer_io_async;
+ atomic_inc(&bh->b_count);
+ bh = bh->b_this_page;
+ } while (bh != head);
- if (fresh && (atomic_read(&bh->b_count) != 0))
- BUG();
- if (rw == READ) {
- if (!fresh)
- BUG();
- if (!buffer_uptodate(bh)) {
- arr[nr++] = bh;
- atomic_inc(&bh->b_count);
- }
- } else { /* WRITE */
- if (!bh->b_blocknr) {
- if (!block)
- BUG();
- bh->b_blocknr = block;
- } else {
- if (!block)
- BUG();
- }
- set_bit(BH_Uptodate, &bh->b_state);
- set_bit(BH_Dirty, &bh->b_state);
- arr[nr++] = bh;
- atomic_inc(&bh->b_count);
- }
+ /* Stage 2: start the IO */
+ do {
+ submit_bh(rw, bh);
bh = bh->b_this_page;
} while (bh != head);
- if ((rw == READ) && nr) {
- if (Page_Uptodate(page))
- BUG();
- ll_rw_block(rw, nr, arr);
- } else {
- if (!nr && rw == READ) {
- SetPageUptodate(page);
- UnlockPage(page);
- }
- if (nr && (rw == WRITE))
- ll_rw_block(rw, nr, arr);
- }
return 0;
}
diff -u --recursive t12p7/linux/include/linux/fs.h linux/include/linux/fs.h
--- t12p7/linux/include/linux/fs.h Thu Dec 7 15:56:26 2000
+++ linux/include/linux/fs.h Sat Dec 9 00:27:41 2000
@@ -1193,6 +1193,7 @@
extern struct buffer_head * get_hash_table(kdev_t, int, int);
extern struct buffer_head * getblk(kdev_t, int, int);
extern void ll_rw_block(int, int, struct buffer_head * bh[]);
+extern void submit_bh(int, struct buffer_head *);
extern int is_read_only(kdev_t);
extern void __brelse(struct buffer_head *);
static inline void brelse(struct buffer_head *buf)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 66%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
2000-12-09 8:45 66% ` Linus Torvalds
@ 2000-12-09 8:56 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-09 8:56 UTC (permalink / raw)
To: Alexander Viro; +Cc: David Woodhouse, Kernel Mailing List
On Sat, 9 Dec 2000, Linus Torvalds wrote:
>
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
Call me stupid [ Chorus: "You're stupid, Linus" ], but I actually compiled
and booted this remotely. And it came up. Which is a pretty good sign that
it doesn't have anything really broken in it.
Still, it would be good to have a few other sharp eyes looking it over.
Look sclean and obviously correct to me, but then _everything_ I write
always looks obviously correct yo me.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-09 17:28 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-09 17:28 UTC (permalink / raw)
To: Alexander Viro
Cc: David Woodhouse, Ingo Molnar, Mikulas Patocka, Kernel Mailing List
On Sat, 9 Dec 2000, Alexander Viro wrote:
> Fine
> > - atomic_inc(&bh->b_count);
>
> Why? It's cleaner the old way - why bother postponing that until we
> lock the thing?
I had a rule: we always do the "lock_buffer()" and "b_count increment"
together with setting "b_end_io = end_buffer_io_async". Why? Because that
way we pair up the actions, and I could easily verify that every single
user of "end_buffer_io_async" will increment the count (that is
decremented in "end_buffer_io_async").
We never used to have any rules in this area, and it was sometimes hard to
match up the actions with each other.
> > int brw_page(int rw, struct page *page, kdev_t dev, int b[], int size)
>
> > if (!page->buffers)
> > + create_page_buffers(rw, page, dev, b, size);
>
> create_empty_buffers(page, dev, size);
Agreed.
> Modulo the comments above - fine with me. However, there is stuff in
> drivers/md that I don't understand. Ingo, could you comment on the use of
> ->b_end_io there?
I already sent him mail about it for the same reason.
> Another bad thing is in mm/filemap.c::writeout_one_page() - it doesn't
> even check for buffers being mapped, let alone attempt to map them.
> Fortunately, ext2 doesn't use it these days, but the rest of block
> filesystems... <doubletake> WTF? fsync() merrily ignores mmap()'ed stuff?
fsync() has _always_ ignored mmap'ed stuff.
If you want to get your mappings synchronized, you absolutely positively
have to call "msync()".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Serial cardbus code.... for testing, please.....
@ 2000-12-09 18:13 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-09 18:13 UTC (permalink / raw)
To: Jens Taprogge; +Cc: Theodore Y. Ts'o, rgooch, jgarzik, dhinds, linux-kernel
On Sat, 9 Dec 2000, Jens Taprogge wrote:
>
> I have a Megaherz card as well. It has been working fine ever since
> Linus fixed some issues with the ToPIC97 Cardbus controller. It reports
> a 16550A on my machine.
I checked my VAIO's, and they all have a Ricoh cardbus bridge.
Ted claimed he had a TI1311 or something, I think. So his VAIO is
definitely different from the ones I have. That may be enough of a
difference.
(But I know I've tried TI bridges too, and have had multiple success
reports with them. They are not uncommon. They _do_ tend to need more
initialization than some of the other bridges, and maybe that's the
difference. Ted, can you send me the lspci -vvxxx output with the full
config space setup?)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7
@ 2000-12-10 1:11 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-10 1:11 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Alexander Viro, Andries Brouwer, David Woodhouse, Ingo Molnar,
Kernel Mailing List
On Sat, 9 Dec 2000, Mikulas Patocka wrote:
>
> I did a test. I disabled readahead except for reading all 4 buffers in
> map_4sectors.
>
> I observed 14% slowdown on walking directories with find and 4% slowdown
> on grepping one my working directory (10M, 281 files).
>
> If you can't make it otherwise you can rip readahead out. If there is a
> possibility to keep it, it would be better.
The absolutely best thing would be to keep the directories in the page
cache. At which point the whole issue becomes pretty moot and we could use
the page-cache readahead code. Which gets the end right, and can handle
stuff that isn't physically contiguous on disk.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Serial cardbus code.... for testing, please.....
@ 2000-12-10 16:19 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-10 16:19 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: rgooch, jgarzik, dhinds, linux-kernel
On Sun, 10 Dec 2000, Theodore Y. Ts'o wrote:
>
> You should also just test having it compiled in - I know some people love
> modules, but there is nothing quite as liberating as just having a kernel
> that finds the devices it needs and doesn't need anything else.
>
> Interesting. Yup, the serial driver works with it compiled in.
Ho humm.. Why wouldn't it work as a module? Strange.
Are you sure cardmgr inserts the right module? If cardmgr tries to insert
serial_cb, and you have warring drivers, you'll break.
Oh, serial_cb shouldn't work anyway, I think.
> However, the epic driver fails after I eject and remove the card, and
> then re-insert it (it hangs on the re-insertion). It looks like a
> deadlock; after it hangs, "ifconfig" also hangs, presumably waiting on
> the same lock (ps alx reports it's waiting on "down").
This is almost certainly the silly hotplug issue that we have - there's a
problem with execin'g /sbin/hotplug and the semaphore that protects the
device state. That will be fixed in the next patch..
> In any case, I think I know how to fix the serial driver to not loop in
> receive_chars(). If I get this working, do you want to take a serial
> driver update now or post 2.4.0?
Pls do it now, this is only going to clean it up (I bet we'll also be able
to remove some of the serial.c PCI device lists, because many of them
probably work with the general "is this a serial device?" test and do not
need to be explicitly listed).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [patch] hotplug fixes
@ 2000-12-10 16:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-10 16:47 UTC (permalink / raw)
To: David Woodhouse; +Cc: Andrew Morton, lkml, linux-usb-devel
On Sun, 10 Dec 2000, David Woodhouse wrote:
>
> That's sick. Do we have to? The PCMCIA coded obviously wants an async
> call_usermodehelper() or it wouldn't have been using schedule_task()
> for it in the first place, would it? Can't we pass an 'int async' arg to
> call_usermodehelper() instead of doing it this way?
All user-mode-helpers are async as of this patch.
The reason for the serialization is that we need to wait until the exec()
has taken place - so that the arguments that the caller set up haven't
disappeared from the caller stack. The actual execution is asynchronous
anyway.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* test12-pre8
@ 2000-12-10 18:18 85% Linus Torvalds
2000-12-10 18:31 99% ` test12-pre8 Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2000-12-10 18:18 UTC (permalink / raw)
To: Kernel Mailing List
The biggest part of the pre8 changes are the USB updates, with support for
a new serial dongle.
The most discussed part of this is the fs/buffer.c handling, and hotplug
changes. Which were fairly small, but interesting (the fs/buffer.c stuff
should fix the double unlock oops, where the new test got added in pre5 as
part of the PageDirty sanity checking).
Can anybody who saw the oops please verify that it is indeed fixed for
them?
Linus
----
- pre8:
- Stephen Rothwell: APM updates
- Johannes Erdfelt: USB updates
- me: call_usermodehelper(/sbin/hotplug) cleanup and deadlock fix
- Leonard Zubkoff: DAC960 Driver Update
- Martin Diehl: fix PCI PM callback ordering
- Andrew Morton: call_usermodehelper() fixes
- Urban Widmark: clean up and enable shared mmap on smbfs.
- Trond Myklebust: fix NFS path revalidation.
- me: proper locking around buffer b_end_io
- pre7:
- Kai Germaschewski: ymfpci cleanups and resource leak fixes
- me: UHCI drivers really need to enable bus mastering.
- Trond Myklebust: fix up nfs_writepage_sync() to not require "filp".
- Andrew Morton: "tq_scheduler" is no more. We have keventd.
- Nils Faerber: cs46xx sounddriver update
- pre6:
- Alan Cox: synch. PA-RISC arch and bitops cleanups
- Maciej Rozycki: even more proper apic setup order.
- Andrew Morton: exec_usermodehelper fixes
- Adam Richter, Kai Germaschewski, me: PCI irq routing.
- revert A20 code changes. We really need to use the keyboard
controller if one exists.
- Johannes Erdfelt: USB updates
- Ralf Baechle: MIPS memmove() fix.
- pre5:
- Jaroslav Kysela: ymfpci driver
- me: get rid of bogus MS_INVALIDATE semantics
- me: final part of the PageDirty() saga
- Rusty Russell: 4-way SMP iptables fix
- Al Viro: oops - bad ext2 inode dirty block bug
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
- Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work.
- Stephen Tweedie: fix inode dirty block handling
- Bill Hartner: reschedule_idle - prefer right cpu
- Johannes Erdfelt: USB updates
- Alan Cox: synchronize
- Richard Henderson: alpha updates and optimizations
- Geert Uytterhoeven: fbdev could be fooled into crashing fix
- Trond Myklebust: NFS filehandles in inode rather than dentry
- pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 85%]
* Re: test12-pre8
2000-12-10 18:18 85% test12-pre8 Linus Torvalds
@ 2000-12-10 18:31 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-10 18:31 UTC (permalink / raw)
To: Kernel Mailing List
Follow-up: I uploaded the wrong patch by mistake, so if anybody got
test12-pre8 within the first five minutes, you'll get a kernel that has
some trouble compiling. Oops. Fixed.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: cardbus pirq conflict
@ 2000-12-11 20:30 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-11 20:30 UTC (permalink / raw)
To: Matthew Galgoci; +Cc: Andrew Morton, linux-kernel, Martin Mares
On Mon, 11 Dec 2000, Matthew Galgoci wrote:
>
> I do however still recieve a nasty message about a pirq table
> conflict, but it does not seem to affect the operation of the
> card.
It doesn't.
> The pirq conflict message seems a little harsh though, and perhaps
> unnecessary.
It is a bit harsh, and while not unnecessary I'll have to do something
about it.
What is going on is that a lot of laptops appear to have a pirq routing
table for PCI bus #1 (and sometimes #2), even though that bus does not
actually exist in hardware at all. My suspicion is that the BIOS writers
just re-use the same pirq table over and over again, and that it's just a
remnant of the fact that some laptops have either a docking station bus or
an AGP bus as bus #1.
When Linux assigns bus #1 to the CardBus bridge, those bogus entries in
the pirq routing table will show up as conflicts. They'll be ignored, but
it's still a nasty message.
The problem is that the message probably _should_ be printed for the real
case of a misconfigured BIOS, if for no other reason than to try to track
down what the h*ll is going on.
My tentative fix for this would be to make Linux never assign bus #1 or #2
to a cardbus bridge, and start cardbus bridges at bus #8 or something like
that. That way we'd still catch any strangeness in the pirq table, but we
wouldn't get the message for this case which seems to be very common.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: PCI irq routing..
[not found] <20001130093428.A6326@atrey.karlin.mff.cuni.cz>
@ 2000-12-12 1:15 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-12 1:15 UTC (permalink / raw)
To: Martin Mares; +Cc: Kernel Mailing List
Martin,
I finally got access to a machine that truly has multiple PCI buses and
bridges in between them, and at least for that machine the x86 IRQ lookup
does not work at all.
The problem seems to be the "pci_get_interrupt_pin()" call. We should not
do that. The pirq table has the unmodified device information - and when
we try to swizzle the pins and find the bridge that the device is behind,
we're trying to be way too clever.
Instead of doing
pin = pci_get_interrupt_pin(dev, &d);
if (pin < 0) {
DBG(" -> no interrupt pin\n");
return 0;
}
I think we should be doing:
u8 pin;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
if (!pin) {
DBG(" -> no interrupt pin\n");
return 0;
}
pin--;
d = dev;
and be done with it. No swizzling, no nothing.
On the machine I just saw, this would have given the right end result.
On machines with just one bus, we'd never see the difference.
Comments?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Linux-2.4.0-test12
@ 2000-12-12 2:52 84% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-12 2:52 UTC (permalink / raw)
To: Kernel Mailing List
Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
compile fixes and (b) the NetApp snapshot thing.
Dave's merge_segments thing could in theory be a deadlock on SMP.
Linus
----
- final:
- David Miller: sparc and net updates. Fix merge_segments.
- Dan Aloni: ISA PnP name parsing cleanup
- Mohammad Haque and others: hunt down tq initializations.
- Petr Vandrovec: ncpfs config changes
- Neil Brown: raid and md cleanups
- Pete Zaitcev: ymfpci update
- Alan Cox: sync (network driver MODULE_OWNER and cleanups)
- Martin Diehl: pirq router for VLSI 82C534 (HP OmniBook and others)
- Tigran Aivazian: ia32 microcode driver update
- Tim Waugh: parport fixes (ECP write, documentation)
- Richard Henderson: alpha update
- David Woodhouse: MTD update
- Trond Myklebust: index the NFS inode cache using the file handle.
This makes NetApp snapshot directories do the right thing.
- test8:
- Stephen Rothwell: APM updates
- Johannes Erdfelt: USB updates
- me: call_usermodehelper(/sbin/hotplug) cleanup and deadlock fix
- Leonard Zubkoff: DAC960 Driver Update
- Martin Diehl: fix PCI PM callback ordering
- Andrew Morton: call_usermodehelper() fixes
- Urban Widmark: clean up and enable shared mmap on smbfs.
- Trond Myklebust: fix NFS path revalidation.
- test7:
- Kai Germaschewski: ymfpci cleanups and resource leak fixes
- me: UHCI drivers really need to enable bus mastering.
- Trond Myklebust: fix up nfs_writepage_sync() to not require "filp".
- Andrew Morton: "tq_scheduler" is no more. We have keventd.
- Nils Faerber: cs46xx sounddriver update
- pre6:
- Alan Cox: synch. PA-RISC arch and bitops cleanups
- Maciej Rozycki: even more proper apic setup order.
- Andrew Morton: exec_usermodehelper fixes
- Adam Richter, Kai Germaschewski, me: PCI irq routing.
- revert A20 code changes. We really need to use the keyboard
controller if one exists.
- Johannes Erdfelt: USB updates
- Ralf Baechle: MIPS memmove() fix.
- pre5:
- Jaroslav Kysela: ymfpci driver
- me: get rid of bogus MS_INVALIDATE semantics
- me: final part of the PageDirty() saga
- Rusty Russell: 4-way SMP iptables fix
- Al Viro: oops - bad ext2 inode dirty block bug
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
- Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work.
- Stephen Tweedie: fix inode dirty block handling
- Bill Hartner: reschedule_idle - prefer right cpu
- Johannes Erdfelt: USB updates
- Alan Cox: synchronize
- Richard Henderson: alpha updates and optimizations
- Geert Uytterhoeven: fbdev could be fooled into crashing fix
- Trond Myklebust: NFS filehandles in inode rather than dentry
- pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()
- pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update
- pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
/proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 84%]
* Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
@ 2000-12-12 18:40 98% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-12 18:40 UTC (permalink / raw)
To: Steven Cole; +Cc: Alan Cox, linux-kernel
On Tue, 12 Dec 2000, Steven Cole wrote:
>
> Executive summary: SMP 2.4.0 is 2% faster than SMP 2.2.18.
Note that kernel compilation really isn't a very relevant benchmark,
because percentage differences in this range can be basically just noise:
things like driver version differences that show up, but impact different
machines different ways (maybe one driver is better for certain machines,
and worse on others. Things like that).
The setup you descibe is just too CPU-intensive, with little potential for
truly interesting differences.
> I ran X and KDE 2.0 during the tests to provide a greater though
> reproducable load on the tested kernel.
You might want to do the same in 32-64MB of RAM. And actually move your
mouse around a bit to keep KDE/X from just being paged out, at which point
it turns un-interesting again. I don't know how to do that repeatably,
though, but one thing I occasionally do is to read my email (which is not
very CPU-intensive, but it does keep the desktop active and also gives me
a feel for interactive behaviour).
At that point the numbers are probably going to show more difference (and
the variation is probably going to be much bigger).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 98%]
* Re: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
@ 2000-12-12 19:06 98% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-12 19:06 UTC (permalink / raw)
To: Jasper Spaans; +Cc: Neil Brown, linux-kernel
On Tue, 12 Dec 2000, Jasper Spaans wrote:
> On Mon, Dec 11, 2000 at 06:52:55PM -0800, Linus Torvalds wrote:
> >
> > Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
> > compile fixes and (b) the NetApp snapshot thing.
>
> > - final:
> > - Neil Brown: raid and md cleanups
>
> Hmm, while doing some not-so-heavy things with a mysql-db on a raid5-device
> this kernel Oopsed on me; ksymoops output [which went through klogd,
> shouldn't matter that much, klogd was using the right System.map]:
>
> Dec 12 14:04:50 spaans kernel: invalid operand: 0000
> Dec 12 14:04:50 spaans kernel: CPU: 1
> Dec 12 14:04:50 spaans kernel: EIP: 0010:[end_buffer_io_bad+85/92]
>
> Dec 12 14:04:50 spaans kernel: Call Trace:
> [raid5_end_buffer_io+68/128]
> [complete_stripe+151/272]
> [handle_stripe+331/1092]
> [raid5d+173/260]
> [md_thread+299/508]
Looks like somebody didn't initialize the "b_end_io" pointer - the code
defaults to it being "end_buffer_io_bad" (which oopses unconditionally on
purpose exactly to find places where it wasn't initialized).
And it obviously looks like it's the raid5 code that does it.
It _looks_ like the raid5 code does a "generic_make_request()" without
setting b_end_io anywhere, but I don't know the raid5 code well enough.
To get better debug output, could you please do something for me?
In fs/buffer.c, get rid of "end_buffer_io_bad" completely, and replace all
users of it with NULL.
Then, in drivers/block/ll_rw_block.c: generic_make_request(), add a test
like
if (!bh->b_end_io) BUG();
to the top of that function.
You'll still get a oops, but the difference is that you'll get the oops
when the request is queued, rather than when the requst is finished, which
will make it easier to figure out what the thing is that leads up to this.
In the meantime I'm sure Neil can figure out where in the raid5 code we
don't initialize the buffer head properly even without that, but it's
worth doing the above anyway.
Thanks,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 98%]
* Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
@ 2000-12-12 20:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-12 20:38 UTC (permalink / raw)
To: Steven Cole; +Cc: Alan Cox, linux-kernel
On Tue, 12 Dec 2000, Steven Cole wrote:
>
> Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
Actually, do it with
make -j3 'MAKE=make -j3' bzImage
A single "-j3" won't do much. It will only build three directories at a
time, and you'll never see much load. But doing it recursively means that
you'll build three at a time all the way out to the leaf directories, and
you should see loads up to 20+, and much more memory pressure too.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
@ 2000-12-12 23:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-12 23:47 UTC (permalink / raw)
To: Neil Brown; +Cc: Jasper Spaans, linux-kernel
On Wed, 13 Dec 2000, Neil Brown wrote:
>
> Could you add this test to the top of md_make_request as well, because
> requests to raid5 don't go through generic_make_request.
Sure they do. Everything that calls ll_rw_block() or submit_bh() will go
through generic_make_request.
Neil, you're probably thinking about __make_request(), which only triggers
for "normal" devices.
The fact that the buffer doesn't go through generic_make_request() implies
that it is some buffer that is completely internal to the raid5
processing. I don't see anything like that, though.
Jasper, sorry about even asking this, but where did you add the check for
b_end_io? Maybe you put it in __make_request() by mistake?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
@ 2000-12-13 3:08 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-13 3:08 UTC (permalink / raw)
To: Neil Brown; +Cc: Jasper Spaans, linux-kernel
On Wed, 13 Dec 2000, Neil Brown wrote:
>
> Yes... you are right. Alright, I can't escape it any other way so I
> guess I must admit that it is a raid5 bug.
>
> But how can raid5 be calling b_end_io on a buffer_head that was never
> passed to generic_make_request?
> Answer, it snoops on the buffer cache to try to do complete stripe
> writes.
Ahh, yes. It seems to just do a "get_hash_table()", and put that bh into
the queues. Bad.
> The following patch disabled that code.
If this fix makes the oops go away, then the proper fix for the problem is
not the #if 0, but do add something like
bh->b_end_io = buffer_end_io_sync;
to just before the "add_stripe_bh(sh, bh, i, WRITE);"
We've already locked the thing, so that should be ok.
I wonder about that "md_test_and_set_bit(BH_Lock ...);" thing there,
though. If the buffer we find was dirty but already locked, we won't be
using that buffer at all (because the md_test_and_set_bit() will fail),
which probably means that the RAID5 checksum won't be right. Hmm..
Why is there an dirty aliased buffer head anyway? That sounds like a
recipe for disaster - maybe we should have synched all the stripe devices
before we set up the raid? Is that a raid5 rebuild issue? What's going on
here?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Signal 11 - the continuing saga
@ 2000-12-13 3:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-13 3:17 UTC (permalink / raw)
To: linux-kernel
In article <20001212191719.A12420@vger.timpanogas.org>,
Jeff V. Merkey <jmerkey@vger.timpanogas.org> wrote:
>On Wed, Dec 13, 2000 at 09:22:55AM +0900, Rainer Mager wrote:
>> I have a tiny bash script that launches a Java swing app. If I run my
>> script from an xterm (or gnome-terminal or whatever) then it starts up fine.
>> If, however, I try to launch it from my gnome taskbar's menu then it dies
>> with signal 11 (the Java log is available upon request). This seems to be
>> 100% consistent, since I noticed it yesterday, even across reboots.
>> Interestingly, the same behavior occurs if I try to run the program from
>> withis JBuilder 4.
>> So, is this related to the larger signal 11 problems?
>
>There's a corruption bug in the page cache somewhere, and it's 100%
>reproducable. Finding it will be tough....
Unlikely. If the actual program data was corrupted, it would SIGSEGV
regardless of how it's executed.
I'd guess that the program has a bug, and depending on the arguments and
environment (especially the latter will be different), it shows up or
not. Things like not having a LOCALE set in either case or similar.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Signal 11 - the continuing saga
[not found] <Pine.LNX.4.10.10012130805190.19301-100000@penguin.transmeta.com>
@ 2000-12-13 17:23 96% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-13 17:23 UTC (permalink / raw)
To: Mike Galbraith; +Cc: Kernel Mailing List
On Wed, 13 Dec 2000, Linus Torvalds wrote:
>
> Lookin gat "swapoff()", it could easily be something like
>
> - swapoff walks theough the processes, marking the pages dirty
> (correctly)
> - swapoff goes on to the next swap entry, and because it needs memory for
> this, the VM layer will swap out old entries by marking them dirty in
> the "struct page".
> - final stages of swapoff() removes the swap cache entry, never minding
> the fact that it is marked dirty again in "struct page", and clean in
> various VM page tables.
>
> Ho humm.. I don't think that is it exactly, but something along those
> lines.
Actually, having thought about it for five more minutes, I actually think
that that _is_ it.
If so, the fix looks like it could be really simple. The whole problem
arises from the fact that we remove the page from the swap cache only
_after_ we've walked the page-tables to look at it. It looks like the
fairly trivial fix is simply to remove it from the swap cache before,
getting rid of all such races in swapoff().
Mind trying out this patch?
NOTE! It's untested. It might not work. It might trigger some sanity-test
somewhere else. But it looks like it should do the right thing (the page
might be moved to _another_ swap device early, if there are multiple swap
areas, but even that should be fine - the unuse_process() stuff doesn't
care about what swapcache this actually is any more.
Does this patch make a difference (I moved the delete seven lines upwards,
and removed the test - the test looks extraneous).
Linus
----
--- v2.4.0-test12/linux/mm/swapfile.c Tue Oct 31 12:42:27 2000
+++ linux/mm/swapfile.c Wed Dec 13 09:17:51 2000
@@ -370,6 +370,7 @@
swap_free(entry);
return -ENOMEM;
}
+ delete_from_swap_cache(page);
read_lock(&tasklist_lock);
for_each_task(p)
unuse_process(p->mm, entry, page);
@@ -377,8 +378,6 @@
shm_unuse(entry, page);
/* Now get rid of the extra reference to the temporary
page we've been using. */
- if (PageSwapCache(page))
- delete_from_swap_cache(page);
page_cache_release(page);
/*
* Check for and clear any overflowed swap map counts.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 96%]
* Re: Signal 11 - the continuing saga
@ 2000-12-13 19:27 99% ` Linus Torvalds
2000-12-13 19:35 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-13 19:27 UTC (permalink / raw)
To: Mike Galbraith; +Cc: Kernel Mailing List
On Wed, 13 Dec 2000, Mike Galbraith wrote:
>
> Not in my test tree. Same fault, and same trace leading up to it. no
Ok.
It definitely looks like a swapoff() problem.
Have you ever seen the behaviour without running swapoff?
Also, can you re-create it without running swapon() (if it's something
like a lost dirty bit, it should be possible to trigger even without the
swapon, and I'd like to hear if that can happen - if it only happens with
swapon() and you can't trigger it with just a swapoff() it might be a
question of re-using some swap file stuff and delaying the writeout or
whatever).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
* Re: Signal 11 - the continuing saga
2000-12-13 19:27 99% ` Linus Torvalds
@ 2000-12-13 19:35 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2000-12-13 19:35 UTC (permalink / raw)
To: Mike Galbraith; +Cc: Kernel Mailing List
Ehh, I think I found it.
Hint: "ptep_mkdirty()".
Oops.
I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that
this explains it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 99%]
Results 1-200 of ~40000 next (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1991-08-25 20:57 99% What would you like to see most in minix? Linus Benedict Torvalds
1998-07-10 0:42 Progress! was: Re: Yet more VM writable swap-cached pages Stephen C. Tweedie
1998-07-10 0:54 98% ` Linus Torvalds
[not found] <Pine.LNX.3.95.980710021356.10100A-100000@fishy>
1998-07-10 1:26 93% ` Linus Torvalds
1998-07-10 2:18 Bill Hawes
1998-07-10 2:18 97% ` Linus Torvalds
1998-07-20 11:16 Richard Henderson
1998-07-20 17:01 99% ` Linus Torvalds
1998-09-21 1:52 PTRACE_POKEDATA on PROT_NONE hangs kernel Michael Elizabeth Chastain
1998-09-21 6:17 97% ` Linus Torvalds
1998-11-19 10:45 entry.S mess with %ebx (¤t pointer) Andrea Arcangeli
1998-11-19 18:01 97% ` Linus Torvalds
1998-11-19 18:08 99% ` Linus Torvalds
1998-11-24 20:40 95% pre-2.1.130-3 Linus Torvalds
[not found] <Pine.LNX.3.95.990320224514.1123A-100000@localhost>
1999-03-20 22:41 90% ` disk head scheduling Linus Torvalds
1999-07-19 7:31 99% Fake emails from "Linus" Linus Torvalds
[not found] <199907302050.NAA24558@napali.hpl.hp.com>
1999-07-30 21:36 82% ` active_mm Linus Torvalds
[not found] <19990804214327.A736@albireo.ucw.cz>
1999-08-05 0:03 93% ` More linker magic Linus Torvalds
1999-08-19 9:14 irq.h changes in 2.3.14 Jes Sorensen
1999-08-19 17:45 99% ` Linus Torvalds
[not found] <Pine.LNX.4.10.9908271831030.4003-100000@laser.random>
1999-08-27 17:45 99% ` Linux-2.3.15 Linus Torvalds
1999-10-21 2:33 architecture bootup changes Paul Mackerras
1999-10-21 3:35 99% ` Linus Torvalds
[not found] <3821F95D.60EC8B0C@yahoo.com>
1999-11-05 18:04 99% ` EISA i/o mem & ioremap vs isa_memcpy Linus Torvalds
2000-04-01 0:00 78% Linux 2000(tm)(r) Linus Torvalds
2000-09-02 15:50 error in arch/i386/kernel/ptrace.c (subtle) Silvio Cesare
2000-09-02 19:01 99% ` Linus Torvalds
2000-10-09 22:28 98% test10-pre1 Linus Torvalds
[not found] <39E7AA78.B6E5D6D@didntduck.org>
2000-10-14 1:47 99% ` [PATCH] Clean up x86 write-protect test Linus Torvalds
2000-10-26 16:20 Linux's implementation of poll() not scalable? Dan Kegel
2000-10-26 16:44 94% ` Linus Torvalds
[not found] <Pine.GSO.4.21.0010251435100.12098-100000@weyl.math.psu.edu>
2000-10-26 20:44 98% ` PATCH: killing read_ahead[] Linus Torvalds
2000-10-27 0:39 missing mxcsr initialization Alan Cox
2000-10-27 5:35 96% ` Linus Torvalds
2000-10-27 6:58 70% test10-pre6 Linus Torvalds
2000-10-27 17:41 Full preemption issues George Anzinger
2000-10-27 17:47 99% ` Linus Torvalds
2000-10-29 9:38 page->mapping == 0 Paul Mackerras
2000-10-29 18:05 94% ` Linus Torvalds
2000-10-29 18:32 Alexander Viro
2000-10-29 19:12 93% ` Linus Torvalds
2000-10-29 19:33 91% ` Linus Torvalds
2000-10-30 15:00 [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9) Andrew Morton
2000-10-30 23:24 ` dean gaudet
2000-11-04 5:08 ` [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange " Andrew Morton
2000-11-04 6:23 95% ` Linus Torvalds
2000-10-30 19:32 71% test10-pre7 Linus Torvalds
2000-10-30 20:34 [PATCH] test10-pre7 Alexander Viro
2000-10-30 21:02 99% ` Linus Torvalds
2000-10-30 21:23 Alexander Viro
2000-10-30 22:21 99% ` Linus Torvalds
2000-10-30 22:01 test10-pre7 Jeff Garzik
2000-10-30 22:24 99% ` test10-pre7 Linus Torvalds
2000-10-30 22:01 [PATCH] test10-pre7 Alexander Viro
2000-10-30 23:05 99% ` Linus Torvalds
2000-10-30 22:41 test10-pre7 Keith Owens
2000-10-30 22:51 99% ` test10-pre7 Linus Torvalds
2000-10-30 23:02 test10-pre7 Jeff Garzik
2000-10-30 23:08 99% ` test10-pre7 Linus Torvalds
2000-10-30 23:03 test10-pre7 Keith Owens
2000-10-30 23:15 96% ` test10-pre7 Linus Torvalds
2000-10-30 23:14 [PATCH] test10-pre7 Alexander Viro
2000-10-30 23:17 99% ` Linus Torvalds
2000-10-30 23:32 test10-pre7 Christoph Hellwig
2000-10-30 23:40 99% ` test10-pre7 Linus Torvalds
2000-10-30 23:38 test10-pre7 Keith Owens
2000-10-30 23:47 96% ` test10-pre7 Linus Torvalds
2000-10-30 23:45 test10-pre7 Christoph Hellwig
2000-10-30 23:51 99% ` test10-pre7 Linus Torvalds
2000-10-30 23:57 test10-pre7 Christoph Hellwig
2000-10-31 0:47 99% ` test10-pre7 Linus Torvalds
2000-10-31 1:01 test10-pre7 Christoph Hellwig
2000-10-31 2:54 99% ` test10-pre7 Linus Torvalds
2000-10-31 1:49 test10-pre7 Keith Owens
2000-10-31 2:58 99% ` test10-pre7 Linus Torvalds
2000-10-31 4:57 test10-pre7 Rusty Russell
2000-10-31 6:10 87% ` test10-pre7 Linus Torvalds
2000-10-31 13:55 test10-pre7 Peter Samuelson
2000-10-31 17:29 93% ` test10-pre7 Linus Torvalds
2000-10-31 14:02 test10-pre7 Keith Owens
2000-10-31 17:31 99% ` test10-pre7 Linus Torvalds
2000-10-31 18:07 test10-pre7 Vladislav Malyshkin
2000-10-31 18:38 97% ` test10-pre7 Linus Torvalds
2000-10-31 19:28 test10-pre7 Russell King
2000-10-31 20:59 99% ` test10-pre7 Linus Torvalds
2000-10-31 20:41 99% Linux-2.4.0-test10 Linus Torvalds
2000-10-31 20:48 Linux-2.4.0-test10 Rik van Riel
2000-10-31 20:57 99% ` Linux-2.4.0-test10 Linus Torvalds
2000-11-01 5:46 Linux-2.4.0-test10 Miles Lane
2000-11-01 5:43 70% ` Linux-2.4.0-test10 Linus Torvalds
2000-11-02 14:03 Poll and OSS API Thomas Sailer
2000-11-02 17:38 99% ` Linus Torvalds
2000-11-04 6:18 Jeff Garzik
2000-11-04 6:39 99% ` Linus Torvalds
2000-11-04 10:54 [PATCH] Re: Negative scalability by removal of Alan Cox
2000-11-04 17:22 99% ` Linus Torvalds
[not found] <3A06C007.99EE3746@uow.edu.au>
2000-11-06 17:48 99% ` Linus Torvalds
2000-11-07 3:41 Pentium 4 and 2.4/2.5 Andre Hedrick
2000-11-07 12:13 ` Alan Cox
2000-11-08 17:26 93% ` Linus Torvalds
2000-11-07 21:06 Lyle Coder
2000-11-07 21:48 ` Alan Cox
2000-11-08 17:31 99% ` Linus Torvalds
2000-11-07 21:06 99% test11-pre1 Linus Torvalds
2000-11-08 0:45 [PATCH] deadlock fix Gary E. Miller
2000-11-08 4:39 99% ` Linus Torvalds
2000-11-08 5:08 [RANT] Linux-IrDA status Michael Rothwell
2000-11-08 5:23 92% ` Linus Torvalds
2000-11-08 7:26 99% ` Linus Torvalds
2000-11-08 17:50 Pentium 4 and 2.4/2.5 Alan Cox
2000-11-08 18:10 95% ` Linus Torvalds
2000-11-09 9:35 PATCH: rd - deadlock removal Jens Axboe
2000-11-09 18:02 99% ` Linus Torvalds
2000-11-09 17:06 [bug] usb-uhci locks up on boot half the time Dunlap, Randy
2000-11-09 22:40 ` David Ford
2000-11-09 22:54 99% ` Linus Torvalds
[not found] <Pine.Linu.4.10.10011091452270.747-100000@mikeg.weiden.de>
2000-11-09 18:31 86% ` [BUG] /proc/<pid>/stat access stalls badly for swapping process, 2.4.0-test10 Linus Torvalds
2000-11-10 7:34 ` Mike Galbraith
2000-11-10 17:07 99% ` Linus Torvalds
2000-11-10 21:42 ` [BUG] /proc/<pid>/stat access stalls badly for swapping process,2.4.0-test10 David Mansfield
2000-11-11 6:20 99% ` Linus Torvalds
2000-11-10 1:52 91% test11-pre2 Linus Torvalds
[not found] <20001109192404.B25828@bougret.hpl.hp.com>
2000-11-10 19:56 89% ` The IrDA patches !!! (was Re: [RANT] Linux-IrDA status) Linus Torvalds
2000-11-10 21:25 Jean Tourrilhes
2000-11-12 2:43 99% ` Linus Torvalds
2000-11-10 21:26 [PATCH] show_task() and thread_saved_pc() fix for x86 Alexander Viro
2000-11-12 2:47 99% ` Linus Torvalds
2000-11-11 17:53 [patch] wakeup_bdflush related fixes and nfsd optimizations for test10 Ying Chen/Almaden/IBM
2000-11-12 2:30 99% ` Linus Torvalds
2000-11-12 0:14 sendfile(2) fails for devices? Jeff Garzik
2000-11-12 0:57 99% ` Linus Torvalds
[not found] <200011120115.BAA37679@tepid.osl.fast.no>
2000-11-12 2:13 99% ` [patch] patch-2.4.0-test10-irda24 (resend) Linus Torvalds
2000-11-12 3:22 85% 2.4.0-test11-pre3 Linus Torvalds
2000-11-14 21:47 84% test11-pre5 Linus Torvalds
2000-11-14 22:45 [PATCH] test11-pre5 Dan Aloni
2000-11-14 23:47 99% ` Linus Torvalds
2000-11-14 22:50 Jeff Garzik
2000-11-14 23:10 ` Dan Aloni
2000-11-14 23:51 99% ` Linus Torvalds
2000-11-15 12:39 Memory management bug schwidefsky
2000-11-15 16:45 96% ` Linus Torvalds
2000-11-16 0:11 BUG: isofs broken (2.2 and 2.4) Andries Brouwer
2000-11-16 0:52 99% ` Linus Torvalds
2000-11-16 1:16 88% ` Linus Torvalds
2000-11-16 1:33 99% ` Linus Torvalds
2000-11-16 1:53 Andries.Brouwer
2000-11-16 2:31 99% ` Linus Torvalds
2000-11-16 13:47 [BUG] Inconsistent behaviour of rmdir Jean-Marc Saffroy
2000-11-16 15:49 99% ` Linus Torvalds
2000-11-16 16:12 Memory management bug schwidefsky
2000-11-16 17:01 99% ` Linus Torvalds
2000-11-16 17:45 Andrea Arcangeli
2000-11-16 18:07 99% ` Linus Torvalds
2000-11-16 18:05 PATCH: 8139too kernel thread Alexander Viro
2000-11-16 18:10 99% ` Linus Torvalds
2000-11-16 21:00 [PATCH (2.4)] atomic use count for proc_dir_entry Dan Aloni
2000-11-16 21:14 99% ` Linus Torvalds
2000-11-17 0:51 [PATCH] pcmcia event thread. (fwd) Russell King
2000-11-17 16:17 99% ` Linus Torvalds
2000-11-17 2:33 80% test11-pre6 Linus Torvalds
2000-11-17 10:54 [PATCH] pcmcia event thread. (fwd) Alan Cox
2000-11-17 16:21 99% ` Linus Torvalds
2000-11-17 16:29 Alan Cox
2000-11-17 16:35 99% ` Linus Torvalds
2000-11-17 16:35 Memory management bug schwidefsky
2000-11-17 16:42 98% ` Linus Torvalds
2000-11-17 16:40 [PATCH] pcmcia event thread. (fwd) Jeff Garzik
2000-11-17 16:47 99% ` Linus Torvalds
2000-11-17 20:00 test11-pre6 still very broken Tigran Aivazian
2000-11-18 6:31 ` Greg KH
2000-11-18 7:25 ` Ben Ford
2000-11-18 7:56 ` Greg KH
2000-11-18 18:17 97% ` Linus Torvalds
2000-11-17 21:20 BUG: isofs broken (2.2 and 2.4) Harald Koenig
2000-11-17 22:29 66% ` Linus Torvalds
2000-11-17 22:55 Harald Koenig
2000-11-17 23:46 60% ` Linus Torvalds
2000-11-17 23:53 99% ` Linus Torvalds
2000-11-17 23:33 Andries.Brouwer
2000-11-17 23:51 99% ` Linus Torvalds
2000-11-18 0:17 Andries.Brouwer
2000-11-18 1:21 99% ` Linus Torvalds
2000-11-18 1:39 ` test11-pre7 compile failure J Sloan
2000-11-18 3:38 99% ` Linus Torvalds
2000-11-18 1:40 Freeze on FPU exception with Athlon Markus Schoder
2000-11-18 3:48 99% ` Linus Torvalds
2000-11-18 4:10 99% ` Linus Torvalds
2000-11-18 4:02 [patch] potential death in disassociate_ctty() Andrew Morton
2000-11-18 5:34 99% ` Linus Torvalds
2000-11-18 4:33 BUG: isofs broken (2.2 and 2.4) Keith Owens
2000-11-18 4:50 99% ` Linus Torvalds
2000-11-18 6:35 Please send Changelog info and patch notices for the test and -pre releases Miles Lane
2000-11-18 15:48 78% ` Linus Torvalds
2000-11-18 9:55 [PATCH] pcmcia event thread. (fwd) David Ford
2000-11-18 16:03 99% ` Linus Torvalds
2000-11-18 14:15 Freeze on FPU exception with Athlon Brian Gerst
2000-11-18 16:26 94% ` Linus Torvalds
2000-11-18 17:17 Alan Cox
2000-11-18 18:03 99% ` Linus Torvalds
2000-11-18 18:22 Markus Schoder
2000-11-18 18:38 93% ` Linus Torvalds
2000-11-18 18:34 adrian
2000-11-18 18:43 99% ` Linus Torvalds
2000-11-19 1:12 [PATCH] semaphore fairness patch against test11-pre6 Andrew Morton
2000-11-19 1:47 92% ` Linus Torvalds
2000-11-19 5:32 [PATCH] pcmcia event thread. (fwd) David Ford
2000-11-19 5:36 91% ` Linus Torvalds
2000-11-19 12:51 [PATCH] semaphore fairness patch against test11-pre6 Andrew Morton
2000-11-19 18:46 95% ` Linus Torvalds
2000-11-20 2:19 76% Linux 2.4.0-test11 Linus Torvalds
2000-11-20 2:39 Rich Baum
2000-11-20 2:42 99% ` Linus Torvalds
2000-11-21 19:28 3c59x: Using bad IRQ 0 Jeff Garzik
2000-11-22 1:26 99% ` Linus Torvalds
2000-11-21 22:18 Tobias Ringstrom
2000-11-23 17:06 99% ` Linus Torvalds
2000-11-22 13:33 Cardbus bridge problems Tobias Ringstrom
2000-11-23 18:06 91% ` Linus Torvalds
2000-11-23 3:50 {PATCH} isofs stuff Andries.Brouwer
2000-11-23 15:37 99% ` Linus Torvalds
2000-11-23 16:58 Ragnar Hojland Espinosa
2000-11-23 17:20 99% ` Linus Torvalds
2000-11-23 18:21 3c59x: Using bad IRQ 0 Tobias Ringstrom
2000-11-23 18:32 99% ` Linus Torvalds
2000-11-23 19:57 {PATCH} isofs stuff Andi Kleen
2000-11-23 20:38 99% ` Linus Torvalds
2000-11-23 23:06 [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1 Jeff Garzik
2000-11-23 23:53 99% ` Linus Torvalds
2000-11-24 5:34 ext2 filesystem corruptions back from dead? 2.4.0-test11 Mohammad A. Haque
2000-11-24 8:51 ` Ion Badulescu
2000-11-24 13:35 ` Guest section DW
2000-11-24 17:41 99% ` Linus Torvalds
2000-11-24 7:06 [PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1 Michael Elkins
2000-11-24 16:30 99% ` Linus Torvalds
2000-11-28 2:45 96% test12-pre2 Linus Torvalds
2000-11-28 3:46 test12-pre2 Neil Brown
2000-11-28 4:38 99% ` test12-pre2 Linus Torvalds
2000-11-29 4:08 corruption Andries.Brouwer
2000-11-29 5:09 99% ` corruption Linus Torvalds
2000-11-29 6:57 95% test12-pre3 Linus Torvalds
2000-11-29 9:08 corruption Alexander Viro
2000-11-29 19:25 97% ` corruption Linus Torvalds
2000-11-29 11:16 corruption Andries.Brouwer
2000-11-29 17:47 98% ` corruption Linus Torvalds
2000-11-29 14:23 plug problem in linux-2.4.0-test11 Jens Axboe
2000-11-29 17:52 99% ` Linus Torvalds
2000-11-29 18:08 corruption Tigran Aivazian
2000-11-29 18:38 99% ` corruption Linus Torvalds
2000-12-02 4:09 Transmeta and Linux-2.4.0-test12-pre3 Adam J. Richter
2000-12-02 5:09 85% ` Linus Torvalds
2000-12-02 7:27 99% ` Linus Torvalds
2000-12-02 9:55 Transmeta and Linux-2.4.0-test12-pre3 [slightly off-topic] Ion Badulescu
2000-12-03 3:01 99% ` Linus Torvalds
2000-12-02 13:04 Transmeta and Linux-2.4.0-test12-pre3 Alan Cox
2000-12-03 8:23 99% ` Linus Torvalds
2000-12-04 2:29 93% test12-pre4 Linus Torvalds
2000-12-05 1:47 [PATCH] inode dirty blocks Andrew Morton
2000-12-05 2:41 99% ` Linus Torvalds
2000-12-05 3:20 80% test12-pre5 Linus Torvalds
2000-12-05 3:31 [PATCH] inode dirty blocks Alexander Viro
2000-12-05 3:52 99% ` Linus Torvalds
2000-12-05 3:42 test12-pre5 Alexander Viro
2000-12-05 4:00 99% ` test12-pre5 Linus Torvalds
2000-12-05 17:09 test12-pre5 Stephen C. Tweedie
2000-12-05 17:48 90% ` test12-pre5 Linus Torvalds
2000-12-05 18:14 test12-pre5 Alexander Viro
2000-12-05 18:33 99% ` test12-pre5 Linus Torvalds
2000-12-05 18:59 test12-pre5 Alexander Viro
2000-12-05 19:48 97% ` test12-pre5 Linus Torvalds
[not found] <00120522275601.09076@gimli>
2000-12-05 21:58 92% ` test12-pre5 Linus Torvalds
[not found] <Pine.LNX.4.30.0012052110590.968-100000@localhost.localdomain>
2000-12-05 23:04 85% ` PCI irq routing Linus Torvalds
2000-12-05 23:25 smbfs writepage & struct file Urban Widmark
2000-12-05 23:57 87% ` Linus Torvalds
2000-12-05 23:30 That horrible hack from hell called A20 H. Peter Anvin
2000-12-06 0:13 97% ` Linus Torvalds
2000-12-06 0:21 Kai Germaschewski
2000-12-06 0:48 99% ` Linus Torvalds
2000-12-06 1:07 99% ` Linus Torvalds
2000-12-06 1:10 H. Peter Anvin
2000-12-06 1:37 95% ` Linus Torvalds
2000-12-06 1:41 99% ` Linus Torvalds
2000-12-06 7:25 84% test12-pre6 Linus Torvalds
2000-12-06 9:11 [patch-2.4.0-test12-pre6] truncate(2) permissions Tigran Aivazian
2000-12-06 19:46 99% ` Linus Torvalds
2000-12-06 9:29 PCI irq routing Martin Diehl
2000-12-06 17:49 95% ` Linus Torvalds
2000-12-06 12:09 The horrible hack from hell called A20 Miles Lane
2000-12-06 20:05 96% ` Linus Torvalds
2000-12-06 18:08 test12-pre6 Erik Mouw
2000-12-06 18:38 99% ` test12-pre6 Linus Torvalds
2000-12-06 19:08 test12-pre6 Erik Mouw
2000-12-06 19:38 99% ` test12-pre6 Linus Torvalds
2000-12-06 22:35 The horrible hack from hell called A20 Miles Lane
2000-12-07 2:27 98% ` Linus Torvalds
[not found] <Pine.LNX.4.10.10012061618300.2415-100000@penguin.transmeta.com>
2000-12-07 1:29 88% ` 2.4.0-test12-pre7 Linus Torvalds
2000-12-07 6:43 The horrible hack from hell called A20 Miles Lane
2000-12-07 7:10 99% ` Linus Torvalds
2000-12-07 14:11 2.4.0-test12-pre7 Russell King
2000-12-07 17:34 96% ` 2.4.0-test12-pre7 Linus Torvalds
2000-12-07 18:30 PCI irq routing Martin Diehl
2000-12-07 18:38 99% ` Linus Torvalds
2000-12-07 20:17 kernel BUG at buffer.c:827! and scsi modules no load at boot w/ initrd - test12pre7 Mohammad A. Haque
2000-12-07 22:19 99% ` Linus Torvalds
2000-12-07 22:42 kernel BUG at buffer.c:827 in test12-pre6 and 7 Joseph Cheek
2000-12-08 0:22 99% ` Linus Torvalds
2000-12-08 0:41 Linux 2.2.18pre25 Andrea Arcangeli
2000-12-08 0:47 ` Alan Cox
2000-12-08 1:27 99% ` Linus Torvalds
2000-12-08 13:23 [PATCH,preliminary] cleanup shm handling Christoph Rohland
2000-12-08 18:26 99% ` Linus Torvalds
2000-12-08 18:05 Serial cardbus code.... for testing, please tytso
2000-12-08 21:27 97% ` Linus Torvalds
2000-12-08 18:11 [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7 Alexander Viro
2000-12-08 18:48 96% ` Linus Torvalds
2000-12-08 19:13 Alexander Viro
2000-12-08 19:39 95% ` Linus Torvalds
2000-12-08 19:50 Daniel Phillips
2000-12-08 21:17 99% ` Linus Torvalds
2000-12-08 22:21 [PATCH,preliminary] cleanup shm handling Christoph Rohland
2000-12-08 22:36 96% ` Linus Torvalds
2000-12-08 22:30 [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7 Alexander Viro
2000-12-08 22:42 99% ` Linus Torvalds
2000-12-09 4:59 Alexander Viro
2000-12-09 8:45 66% ` Linus Torvalds
2000-12-09 8:56 99% ` Linus Torvalds
2000-12-09 5:41 Serial cardbus code.... for testing, please Theodore Y. Ts'o
2000-12-09 7:41 95% ` Linus Torvalds
2000-12-09 7:48 99% ` Linus Torvalds
2000-12-09 10:40 [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7 Alexander Viro
2000-12-09 17:28 99% ` Linus Torvalds
2000-12-09 13:54 Serial cardbus code.... for testing, please Jens Taprogge
2000-12-09 18:13 99% ` Linus Torvalds
2000-12-09 21:25 [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7 Mikulas Patocka
2000-12-10 1:11 99% ` Linus Torvalds
2000-12-10 7:07 Serial cardbus code.... for testing, please Theodore Y. Ts'o
2000-12-10 16:19 99% ` Linus Torvalds
2000-12-10 12:44 [patch] hotplug fixes David Woodhouse
2000-12-10 16:47 99% ` Linus Torvalds
2000-12-10 18:18 85% test12-pre8 Linus Torvalds
2000-12-10 18:31 99% ` test12-pre8 Linus Torvalds
2000-12-11 20:03 cardbus pirq conflict Matthew Galgoci
2000-12-11 20:30 96% ` Linus Torvalds
2000-12-11 23:24 Signal 11 Rainer Mager
2000-12-13 0:22 ` Signal 11 - the continuing saga Rainer Mager
2000-12-13 2:17 ` Jeff V. Merkey
2000-12-13 3:17 99% ` Linus Torvalds
[not found] <20001130093428.A6326@atrey.karlin.mff.cuni.cz>
2000-12-12 1:15 99% ` PCI irq routing Linus Torvalds
2000-12-12 2:52 84% Linux-2.4.0-test12 Linus Torvalds
2000-12-12 15:06 [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12] Jasper Spaans
2000-12-12 19:06 98% ` Linus Torvalds
2000-12-12 18:18 UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12 Steven Cole
2000-12-12 18:40 98% ` Linus Torvalds
2000-12-12 20:19 Steven Cole
2000-12-12 20:38 99% ` Linus Torvalds
2000-12-12 23:21 [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12] Neil Brown
2000-12-12 23:47 99% ` Linus Torvalds
2000-12-13 0:17 Neil Brown
2000-12-13 3:08 99% ` Linus Torvalds
[not found] <Pine.LNX.4.10.10012130805190.19301-100000@penguin.transmeta.com>
2000-12-13 17:23 96% ` Signal 11 - the continuing saga Linus Torvalds
2000-12-13 18:02 Mike Galbraith
2000-12-13 19:27 99% ` Linus Torvalds
2000-12-13 19:35 99% ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).