Frank de Lange wrote:
>
> On Fri, Jan 12, 2001 at 09:54:31PM +0100, Manfred Spraul wrote:
> > I have found one combination that doesn't hang with the unpatched
> > 8390.c, but network throughput is down to 1/2. I hope that's due to the
> > debugging changes.
>
> Hm, could it be that the fact
On Fri, 12 Jan 2001, Chris Mason wrote:
>
> Hi guys,
>
> This code for generic_file_write calls vmtruncate without i_sem held. Is
> that intentional? It should cause problems for reiserfs at least...
Erm... generic_file_write() grabs i_sem upon entry and drops it on exit.
This call of
Well, when i Make bzImage it uses -O2 for optimization. Is there any fix? change
the optimization to -O0 ?
Matti Aarnio wrote:
> On Fri, Jan 12, 2001 at 03:02:15PM -0500, Shawn Starr wrote:
> > Nope, its not ;/
> >
> > Im on a Intel Pentium 200Mhz PC, 64MB RAM,
> >
> > init/main.o: In function
On Fri, 12 Jan 2001, Alan Cox wrote:
> > I want to see the code to handle the apparent VIA DMA bug. At this point,
> > preferably by just disabling DMA on VIA chipsets or something like that
> > (if it has only gotten worse since 2.2.x, I'm not interested in seeing any
> > experimental patches
> Remind me: what polarity are your io-apic irq's? Level, edge, sideways?
> Anything else that might be relevant?
Well, sideways ofcourse! :-)
here's a cat /proc/interrupts from the (BP6) box:
CPU0 CPU1
0: 104936 105433IO-APIC-edge timer
1:
www.dosemu.org
On Fri, 12 Jan 2001, Jim M. wrote:
> Hi,
> There is a compiler package that runs on DOS but not on Linux.
> I was wondered how can i emulate DOS under linux so that i run the compile
> package?. I have kernel 2.2.14-12. RH 6.2.
>
On Fri, Jan 12, 2001 at 03:02:15PM -0500, Shawn Starr wrote:
> Nope, its not ;/
>
> Im on a Intel Pentium 200Mhz PC, 64MB RAM,
>
> init/main.o: In function `check_fpu':
> init/main.o(.text.init+0x53): undefined reference to `__buggy_fxsr_alignment'
> make: *** [vmlinux] Error 1
>
> same fatal
Eric W. Biederman writes:
> Hmm. I would think that increasing the logical page size in the kernel
> would be the trivial way to handle virtual aliases. (i.e.) with a large
> enough page size you can't actually have a virtual alias.
There are types of caches out there that no matter how large
Hi,
The starfire driver in 2.4.0 (and 2.4.0-ac8) forgets to release its MMIO
region when the module is unloaded, which makes it impossible to load it a
second time. The attached patch fixed this problem; I tested it here on a
2-port card.
Please apply.
Thanks,
Ion
--
It is better to keep
On Fri, Jan 12, 2001 at 09:54:31PM +0100, Manfred Spraul wrote:
> I have found one combination that doesn't hang with the unpatched
> 8390.c, but network throughput is down to 1/2. I hope that's due to the
> debugging changes.
Hm, could it be that the fact that network throughput is halved
On Fri, Jan 12, 2001 at 09:51:36PM +0100, Ingo Molnar wrote:
> great. Back when i had the same problem, flood pinging another host (on
> the local network) was the quickest way to reproduce the hang:
>
> ping -f -s 10 otherhost
>
> this produced an IOAPIC-hang within seconds.
Apart from
from "Linux-2.4.x patch submission policy":
> Another way of putting it: if you have a patch, ask yourself what
> would happen if it got left off the next
> RedHat/SuSE/Debian/Turbo/whatever distribution CD. Would it really
> be a big problem? If not, then I'd rather spend the time _really_
Ingo Molnar wrote:
>
>
> okay - i just wanted to hear a definitive word from you that this fixes
> your problem, because this is what we'll have to do as a final solution.
> (barring any other solution.)
>
Ingo, is that possible?
The current fix is "disable_irq_nosync() and enable_irq() cause
On Fri, 12 Jan 2001, Frank de Lange wrote:
> PATCHED 8390.c (using irq_safe spinlocks instead of disable_irq)
> PATCHED apic.c (focus cpu ENABLED)
> STOCK io_apic.c
>
> No problems under heavy network load.
>
> Gentleman, this (the patch to 8390.c) seems to fix the problem.
great. Back when i
On Fri, 12 Jan 2001, Ingo Molnar wrote:
> okay - i just wanted to hear a definitive word from you that this fixes
> your problem, because this is what we'll have to do as a final solution.
> (barring any other solution.)
Patching 8390.c won't fix this for me. The only thing on IRQ19 when I saw
On Fri, Jan 12, 2001 at 09:37:24PM +0100, Ingo Molnar wrote:
> okay - i just wanted to hear a definitive word from you that this fixes
> your problem, because this is what we'll have to do as a final solution.
> (barring any other solution.)
Now running with this config:
PATCHED 8390.c (using
On Fri, Jan 12, 2001 at 09:34:03PM +0100, Ingo Molnar wrote:
> ? this is x86-only code. There is no hot-pluggable CPU support for Linux
> AFAIK. (But in any case, the code is basically ready for hot-pluggable
> CPUs, just take a few precautions and change cpu_online_mask and a couple
> of other
> This way we are 100% consistent and we don't lose the "cpu_has" information.
but /dev/cpu/*/{msr|cpuid} are "cpu has".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Fri, 12 Jan 2001, Frank de Lange wrote:
> It is. As I already mentioned in other messages, I already tested with
> JUST the patched 8390.c driver, no other patches. It was stable. I
> then patched apic.c AND io_apic.c, which did not introduce new
> instabilities. Unless you think that
Matti Aarnio wrote:
>
> On Fri, Jan 12, 2001 at 12:23:48PM -0800, H. Peter Anvin wrote:
> > [EMAIL PROTECTED] wrote:
> > > > The signature on man-pages-1.34.tar.gz is bad:
> > >
> > > Hmm, thought I had corrected that already.
> > > Is it correct now?
> > >
> > > Andries
> >
> > Because an
On Fri, Jan 12, 2001 at 09:31:15PM +0100, Ingo Molnar wrote:
>
> On Fri, 12 Jan 2001, Frank de Lange wrote:
>
> > WITH or WITHOUT the changed 8390 driver? I can already give you the
> > results for running WITH the changed driver: it works. I have not yet
> > tried it WITHOUT the changed 8390
On Fri, 12 Jan 2001, Frank de Lange wrote:
> BTW, does this (TARGET_CPUS cpu_online_mask) not wreak havoc with
> systems with hot-pluggable CPUs (many Suns, etc...)? Wouldn;t it be
> better to make this a config option (like the optional PCI fixes for
> crappy BIOSs)?
? this is x86-only code.
On Fri, Jan 12, 2001 at 12:23:48PM -0800, H. Peter Anvin wrote:
> [EMAIL PROTECTED] wrote:
> > > The signature on man-pages-1.34.tar.gz is bad:
> >
> > Hmm, thought I had corrected that already.
> > Is it correct now?
> >
> > Andries
>
> Because an updated signature has the same timestamp and
On Fri, 12 Jan 2001, Frank de Lange wrote:
> WITH or WITHOUT the changed 8390 driver? I can already give you the
> results for running WITH the changed driver: it works. I have not yet
> tried it WITHOUT the changed 8390 driver (so that would be stock 8390,
> patched apic.c, stock io_apic.c).
On Fri, Jan 12, 2001 at 09:19:53PM +0100, Ingo Molnar wrote:
> > In addition, I patched apic.c (focus cpu enabled)
> > In addition, I patched io_apic ((TARGET_CPUS 0xff)
>
> please try it with the focus CPU enabling change (we want to enable that
> feature, i only disabled it due to the
Hi guys,
This code for generic_file_write calls vmtruncate without i_sem held. Is
that intentional? It should cause problems for reiserfs at least...
-chris
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux-2.4.0/mm/filemap.c linux.ac/mm/filemap.c
---
On Fri, Jan 12, 2001 at 11:57:37AM -0800, Linus Torvalds wrote:
> > I've got a vt82c586 here (bought it just for testing of this problem),
> > and I wasn't able to create any corruption using that board and the 2.4
> > drivers.
>
> The fact that it works on one board doesn't mean that it works
[EMAIL PROTECTED] wrote:
>
> > The signature on man-pages-1.34.tar.gz is bad:
>
> Hmm, thought I had corrected that already.
> Is it correct now?
>
> Andries
Because an updated signature has the same timestamp and size, it can take
up to 24 hours for it to hit ftp.kernel.org, and even longer
On Fri, 12 Jan 2001, Frank de Lange wrote:
> In addition, I patched apic.c (focus cpu enabled)
> In addition, I patched io_apic ((TARGET_CPUS 0xff)
please try it with the focus CPU enabling change (we want to enable that
feature, i only disabled it due to the stuck-ne2k bug), but with
On Fri, Jan 12, 2001 at 09:11:29PM +0100, Manfred Spraul wrote:
> Frank, please clarify:
> you still run without disable_irq_nosync() in 8390.c?
I am running with your patched version of 8390.c (so WITHOUT
disable_irq_nosync()).
In addition, I patched apic.c (focus cpu enabled)
In addition, I
Linus Torvalds wrote:
>
>
> I'd like to know _which_ of the two makes a difference (or does it only
> trigger with both of them enabled)? And even then I'm not sure that it is
> "the" solution - both changes to io-apic handling had some reason for
> them. Ingo, what was the focus-cpu thing?
>
On Fri, Jan 12, 2001 at 11:59:25AM -0800, Linus Torvalds wrote:
> > Could this really be the solution?
>
> I'd like to know _which_ of the two makes a difference (or does it only
> trigger with both of them enabled)? And even then I'm not sure that it is
> "the" solution - both changes to
In article <[EMAIL PROTECTED]>,
Frank de Lange <[EMAIL PROTECTED]> wrote:
>As per Linus' suggestion, I removed the disable_irq/enable_irq statements from
>the 8390 core driver, and replace the spinlocks with irq-safe versions. This
>seems to solve the network hangs, as I am currently running a
On Fri, Jan 12 2001, Chris Rankin wrote:
> Hi,
>
> I have just compiled 2.4.0-ac7, and this kernel boots up OK (no more
> processes missing from the output of "ps -ef", either). However, I am
> now getting an unresolved symbol "queued_sectors" in scsi_mod.o when I
> run depmod.
Fixed in -ac8
On Fri, 12 Jan 2001, Linus Torvalds wrote:
> [...] Ingo, what was the focus-cpu thing?
well, some time ago i had an ne2k card in an SMP system as well, and found
this very problem. Disabling/enabling focus-cpu appeared to make a
difference, but later on i made experiments that show that in
Nope, its not ;/
Im on a Intel Pentium 200Mhz PC, 64MB RAM,
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o
arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o
On Fri, 12 Jan 2001, Frank de Lange wrote:
> On Fri, Jan 12, 2001 at 08:33:15PM +0100, Manfred Spraul wrote:
> > Frank, the 2.4.0 contains 2 band aids that were added for ne2k smp:
> >
> > * From Ingo: focus cpu disabled, in arch/i386/kernel/apic.c
> > * From myself: TARGET_CPU =
Hi,
I have just compiled 2.4.0-ac7, and this kernel boots up OK (no more
processes missing from the output of "ps -ef", either). However, I am
now getting an unresolved symbol "queued_sectors" in scsi_mod.o when I
run depmod.
I've done a "make mproper; ; make oldconfig;
make dep" and none of
On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
>
> I've got a vt82c586 here (bought it just for testing of this problem),
> and I wasn't able to create any corruption using that board and the 2.4
> drivers.
The fact that it works on one board doesn't mean that it works on _every_
board.
This is,
On Fri, Jan 12, 2001 at 08:33:15PM +0100, Manfred Spraul wrote:
> Frank, the 2.4.0 contains 2 band aids that were added for ne2k smp:
>
> * From Ingo: focus cpu disabled, in arch/i386/kernel/apic.c
> * From myself: TARGET_CPU = cpu_online_mask, was 0xFF.
>
> Could you disable both bandaids? I
On Fri, Jan 12, 2001 at 12:23:21PM -0500, Martin Laberge wrote:
> > > This is on a 450 MHz AMD-K6 with the following IDE controller:
> > > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> >
> > There are several people who have reported that the 2.4.0 VIA IDE driver
On Fri, Jan 12, 2001 at 10:15:45AM +0100, Tobias Ringstrom wrote:
> I've never seen anything like it before, which I'm happy for. The system
> had been running a standard RedHat 7 kernel for days without any problems,
> but who wants to run a 2.2 kernel? I compiled 2.4.0 for it, rebooted, and
>
On Fri, Jan 12, 2001 at 10:55:22AM -0800, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Andre Hedrick <[EMAIL PROTECTED]> wrote:
> >
> >Well that "experimental patch" is designed to get out of the dreaded
> >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
>
Frank de Lange wrote:
>
> On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
> > I removed the disable_irq lines from 8390.c, and that fixed the problem:
> > no hang within 2 minutes - the test is still running.
> >
> > Frank, could you double check it?
>
> I'm currently running my
On Fri, 12 Jan 2001, Stephen Torri wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 12 Jan 2001, Martin Josefsson wrote:
>
> > My setup looks like this, I boot from hde
> > I configured my BIOS to boot from SCSI (I have no scsi-adapter but the
> > promise card reports
> On Fri, Jan 12, 2001 at 10:35:24AM -0800, Linus Torvalds wrote:
> > Andreas argument was that earlier kernels weren't consistent, and as
> > such we shouldn't even bother to try to make newer kernels consistent.
> > We would be better off reporting our internal inconsistencies the way
> >
On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
> I removed the disable_irq lines from 8390.c, and that fixed the problem:
> no hang within 2 minutes - the test is still running.
>
> Frank, could you double check it?
I'm currently running my own patched version, which uses
> >> I ran into this while hacking the Nvidia kernel driver to work with
> >> 2.4.0. I got the driver working but it's not 100%
> >>
> >> Also where did get_module_symbol() and put_module_symbol() go?
> >
> >Patches for the NVIDIA binary X drivers following all these kernel
> >changes can be
On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
> Linus wrote:
> > Does this seem to happen mainly with drivers that use "disable_irq()"
> > and "enable_irq()"? I know the ne drivers do (through the 8390 module),
> > and some others do too (3c59x).
>
> I removed the
Sorry for the noise, it has happened again, but this time I had
sysreq active and it worked. CTRL+ALT+BACKSPACE or
ALT+FX didn't work. With sysreq I synced, umounted and
rebooted without trouble.
I think that could be a mouse and/or X and/or Netscape problem,
since the system (apart input
As per Linus' suggestion, I removed the disable_irq/enable_irq statements from
the 8390 core driver, and replace the spinlocks with irq-safe versions. This
seems to solve the network hangs, as I am currently running a heavy network
load (which would have killed a non-patched driver within
Linus wrote:
> Does this seem to happen mainly with drivers that use "disable_irq()"
> and "enable_irq()"? I know the ne drivers do (through the 8390 module),
> and some others do too (3c59x).
I removed the disable_irq lines from 8390.c, and that fixed the problem:
no hang within 2 minutes -
I am running a medium-high traffic web server on an SMP machine. I have
always had problems with linux hanging (No syslog messages and no
console response). I have tried kernel versions 2.2.12, 2.2.14 and
2.2.16
Recently I tried 2.2.17, this kernel was up for about a month, before
there was a
On Fri, Jan 12, 2001 at 10:35:24AM -0800, Linus Torvalds wrote:
> Andreas argument was that earlier kernels weren't consistent, and as
> such we shouldn't even bother to try to make newer kernels consistent.
> We would be better off reporting our internal inconsistencies the way
> earlier
Michael Rothwell ([EMAIL PROTECTED]) wrote:
> How about using fcntl(), O_ASYNC and SIGIO?
Don't think that's supported for disk files yet, at least by the
kernel. glibc does aio emulation with threads, which isn't great.
> Or maybe a broader question:
> what's the preferred/working way to
In article <[EMAIL PROTECTED]>,
Andre Hedrick <[EMAIL PROTECTED]> wrote:
>
>Well that "experimental patch" is designed to get out of the dreaded
>"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
>Intel 440*X Chipset groups. Since it appears that their bug was copied
>but
On Fri, 12 Jan 2001, Manfred Spraul wrote:
> 2.4 spreads the vectors for the external (hardware, from io apic)
> interrupts, but 5 ipi vectors have the same priority: reschedule, call
> function, tlb invalidate, apic error, spurious interrupt.
my reading of the errata is that the lost APIC
Ingo Molnar wrote:
>
> we *already* reorder vector numbers and spread them out as much as
> possible. We do this in 2.2 as well. We did this almost from day 1 of
> IO-APIC support. If any manually allocated IRQ vector creates a '3 vectors
> in the same 16-vector region' situation then thats a
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>
>The PCI ids I kill autodma on for 2.2 to cover this are:
>
>/*
> * Don't try and tune a VIA 82C586 or 586A
> */
>if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>> The fact that 2.2.x has bad control over capabilities and is messy is NOT
>> an excuse to screw up forever.
>
>2.2 has a mix of 'can I use' and 'does the cpu have' so using 2.2 as an
>example doesnt work
The above was
In article <[EMAIL PROTECTED]>,
Manfred Spraul <[EMAIL PROTECTED]> wrote:
>The processor's local APIC includes an in-service entry and a holding
>entry for each priority level. To avoid losing interrupts, software
>should allocate no more than 2 interrupt vectors per priority.
>
>
>Ok,
On Fri, Jan 12, 2001 at 09:35:14AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
>
> > On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
> > >
> > > Its fine either way on current x86 and many other platforms, but falls
> > > on its face in
On Fri, Jan 12, 2001 at 06:51:36PM +0100, Manfred Spraul wrote:
> Frank, I've attached a proposed kick_IOAPIC pin. Could you try it?
> I'm rebooting with that patch right now.
I added the patch, and tried it out. When the network hangs, I am able to revive it
with ALT-SYSRQ-Q. The debug log
On Fri, 12 Jan 2001, Linus Torvalds wrote:
>
>
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> >
> > Scratch that patch it has 2 typos that are in amd74xx.c
> >
> > will do it again..
>
> I will scratch your new patch too.
>
> I want to see the code to handle the apparent VIA DMA
On Fri, 12 Jan 2001, Manfred Spraul wrote:
> The PPro local apic documentation says:
> <<<
> The processor's local APIC includes an in-service entry and a holding
> entry for each priority level. To avoid losing interrupts, software
> should allocate no more than 2 interrupt vectors per
> I want to see the code to handle the apparent VIA DMA bug. At this point,
> preferably by just disabling DMA on VIA chipsets or something like that
> (if it has only gotten worse since 2.2.x, I'm not interested in seeing any
> experimental patches for it during early 2.4.x).
It hasnt gotten
Alan Cox wrote:
>
> > Frank, could you try what happens with the NMI oopser disabled?
> >
> > The second major difference I'm immediately aware of is the number of
> > the reschedule/tlb flush/etc interrupt: 2.2 uses the lowest priority,
> > 2.4 the highest priority.
>
> Im trying to remember
Frank de Lange wrote:
>
> On Fri, Jan 12, 2001 at 06:16:36PM +0100, Manfred Spraul wrote:
> > I would first concentrate on the differences between 2.2 and 2.4:
> >
> > Frank, could you try what happens with the NMI oopser disabled?
>
> Here's the results with nmi_watchdog=0
>
>
> After
On Fri, 12 Jan 2001, Andre Hedrick wrote:
>
> Scratch that patch it has 2 typos that are in amd74xx.c
>
> will do it again..
I will scratch your new patch too.
I want to see the code to handle the apparent VIA DMA bug. At this point,
preferably by just disabling DMA on VIA chipsets
> The fact that 2.2.x has bad control over capabilities and is messy is NOT
> an excuse to screw up forever.
2.2 has a mix of 'can I use' and 'does the cpu have' so using 2.2 as an
example doesnt work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
> Frank, could you try what happens with the NMI oopser disabled?
>
> The second major difference I'm immediately aware of is the number of
> the reschedule/tlb flush/etc interrupt: 2.2 uses the lowest priority,
> 2.4 the highest priority.
Im trying to remember what they were, but some APIC
Alan Cox wrote:
> > This is on a 450 MHz AMD-K6 with the following IDE controller:
> > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
>
> There are several people who have reported that the 2.4.0 VIA IDE driver
> trashes hard disks like that. The 2.2 one also did
On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
> On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
> >
> > Its fine either way on current x86 and many other platforms, but falls
> > on its face in the presence of asymetric MP.
>
> Point taken, feel free to have a can_I_use
On Fri, Jan 12, 2001 at 06:16:36PM +0100, Manfred Spraul wrote:
> I would first concentrate on the differences between 2.2 and 2.4:
>
> Frank, could you try what happens with the NMI oopser disabled?
Here's the results with nmi_watchdog=0
Before network hang (nmi_watchdog=0)
Try "dosemu" package
the dosemu home page will tell you all about it
Martin Laberge
[EMAIL PROTECTED]
"Jim M." wrote:
> Hi,
> There is a compiler package that runs on DOS but not on Linux.
> I was wondered how can i emulate DOS under linux so that i run the compile
> package?. I have
>
> [EMAIL PROTECTED] said:
> > IRR for interrupt 19 is set, that means the IO APIC has sent the
> > interrupt to a cpu but not yet received the corresponding EOI.
>
> OK, but couldn't we reset it by sending an extra EOI when the drivers
> decide that they've missed interrupts?
How?
You
On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
> On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
>
> > It doesn't make much sense to me to put the "can_I_use" global information in
> > the per-cpu slots, that's obviously the wrong place for it. We simply need to
> > add a new
[EMAIL PROTECTED] said:
> IRR for interrupt 19 is set, that means the IO APIC has sent the
> interrupt to a cpu but not yet received the corresponding EOI.
OK, but couldn't we reset it by sending an extra EOI when the drivers
decide that they've missed interrupts?
--
dwmw2
-
To unsubscribe
Let's decode it:
> IO APIC #2..
> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
> 12 0FF 0F 0 1 0 1 0 1 1 91
> 13 0FF 0F 0 1 1 1 0 1 1 99
IRR for interrupt 19 is set, that means the IO APIC has sent the
interrupt to a cpu but not yet received the corresponding EOI.
That bit is read
This patch is some documentation for sysctl API. It also fixed a warning
with fs/super.c, and makes the default target for the DocBook makefile a
little saner (though everyone should be using make htmldocs of course)
It's against 2.4.0ac8
thanks
john
diff -Naur -X
On 2001.01.12 Alan Cox wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
> 2.4.0-ac8
I was not sure to ask this, because one of your answers to one other mail
suggested that you will take a parallel way to linux updates.
But as you seem to be tracking close the
On Fri, Jan 12, 2001 at 09:40:55AM +, Alan Cox wrote:
> > be true; but perhaps I am doing something wrong. If I open() a file (on
> > 2.2.18) from a floppy or NFS mount (to test in a slow environment) with
> > O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on
> > the file
Ralf Baechle <[EMAIL PROTECTED]> writes:
> On Thu, Jan 11, 2001 at 12:56:57AM +0100, David Weinehall wrote:
>
> > > The MMU on these systems is a CAM, and the mmu table is thus backwards to
> > > convention. (It also means you can notionally map two physical addresses to
> > > one virtual but
On Thu, Jan 11, 2001 at 08:26:04PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
> >
> > Note that there was a precise reason for not implementing it as the TSC disable
> > (infact at first in 2.2.x I was clearing the bigflag in x86_capabilities too).
> > The
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
> Here is a debugging patch. Could you please apply this,
> rebuild and:
>
> 1: Type ALT-SYSRQ-A when everything is good
> 2: Type ALT-SYSRQ-A when everything is bad
> 3: send the resulting logs.
And, for completeness' sake, here's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 12 Jan 2001, Martin Josefsson wrote:
> My setup looks like this, I boot from hde
> I configured my BIOS to boot from SCSI (I have no scsi-adapter but the
> promise card reports itself as one at boottime)
>
> boot = /dev/hde3
> delay = 50
>
On Fri, 12 Jan 2001, Stephen Torri wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm having difficulty booting from the Promise controller. Here is the
> story:
>
> I originally had my system setup with all drives working off the
> mainsboard IDE controller (Intel 82371AB
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
> Here is a debugging patch. Could you please apply this,
> rebuild and:
>
> 1: Type ALT-SYSRQ-A when everything is good
> 2: Type ALT-SYSRQ-A when everything is bad
> 3: send the resulting logs.
OK, here's the results I get...
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
2.4.0-ac8
o Fix PS/2 mouse ack/echo handling behaviour (Julian Bradfield)
| Let me know if you see 'odd' ps/2 stuff (Chris Hanson)
| in 2.4.0ac8 not in ac7
o Merge Linus 1pre3. Drop out some of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm having difficulty booting from the Promise controller. Here is the
story:
I originally had my system setup with all drives working off the
mainsboard IDE controller (Intel 82371AB PIIX4). The setup was
/dev/hda - ST310232A, FwRev=3.09
On Fri, Jan 12, 2001 at 02:36:41PM +0100, Arjan van de Ven wrote:
> > This just goes on to show that khttpd is unnecessary kernel bloat and can be
> > "just as well" handled by a userspace application, minus some rather very
> > special cases which do not justify its inclusion into the main
hi
use the 2.2.18aa2 patch from andrea ... raid 0.9 is included!
cu, oli
ftp://ftp.de.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18aa2.bz2
On Thu, Jan 11, 2001 at 11:42:33PM +0100, Takacs Sandor wrote:
> On Thu, 11 Jan 2001, Alan Cox wrote:
>
> > > I tried to apply it. If I
From: Chris Wedgwood <[EMAIL PROTECTED]>
On Thu, Jan 11, 2001 at 09:34:08PM -0500, Michael Rothwell wrote:
The man pages for open, read and write say that if a file is opened
using the O_NONBLOCK flag, then read() and write() will always return
immediately and
On Sat, Jan 13, 2001 at 12:30:46AM +1100, Andrew Morton wrote:
> what worries me about this is the Apache-flock-serialisation saga.
>
> Back in -test8, kumon@fujitsu demonstrated that changing this:
>
> lock_kernel()
> down(sem)
>
> up(sem)
> unlock_kernel()
>
>
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
> Frank de Lange wrote:
> >
> > Quick and dirty conclusion: as soon as the apic comes in to play, things get
> > messy...
> Here is a debugging patch. Could you please apply this,
> rebuild and:
>
> 1: Type ALT-SYSRQ-A when
> I have a Motherboard BP6 with two Celeron 500 (Not overclocked) and
...
> APIC error on CPU1: 00(08)
...
> What wrongs ?
Abit designed the board wrong. there are things you can do to reduce
the incidence of this error: upgrading the bios, better cooling, more
powerful power supply, replacing
Alan Cox wrote:
>
> > using the O_NONBLOCK flag, then read() and write() will always return
> > immediately and not block the calling process. This does not appear to
> > be true; but perhaps I am doing something wrong. If I open() a file (on
> > 2.2.18) from a floppy or NFS mount (to test in a
> The signature on man-pages-1.34.tar.gz is bad:
Hmm, thought I had corrected that already.
Is it correct now?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
I have a Motherboard BP6 with two Celeron 500 (Not overclocked) and
Linux Kernel-2.4
and I have de message
APIC error on CPU0: 00(02)
APIC error on CPU1: 00(08)
APIC error on CPU1: 08(04)
APIC error on CPU0: 02(08)
APIC error on CPU0: 08(08)
APIC error on CPU1: 04(04)
APIC error on CPU0: 08(02)
[EMAIL PROTECTED] said:
> No, I'm judging based on the fact that I found reports from people
> using NE2K-PCI with several cards as well as tulip-based cards
> (different driver) on abit BP6 as well as Gigabyte motherboards,
> mostly on 2.3.x/2.4.x kernels. I found some postings with these
>
101 - 200 of 495 matches
Mail list logo
