Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Manfred Spraul]

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 that network throughput is halved causes the
> problem not to appear?

No. The problem is still there. But now lots of losts packets instead of
a total hang.

Due to the modification of mask_irq now disable_irq_nosync and
enable_irq act as if I would press SysRQ+q every millisecond, and thus
the io apic is immediatly reset when it got stuck.

Btw, my initial assumption about EOI to masked interrupt must be wrong:
2.2 always first masks the irq, then it sends the EOI, and 2.2 doesn't
hang.

--
Manfred
-
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/

Re: generic_file_write change in 2.4.0-ac8

[Alexander Viro]

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 vmtruncate() is deep inside the protected area.

It is taken out of the main path for obvious reasons, but as far as
control flow counts it sits inside the main loop. FWIW, it might
as well be written as

status = mapping->a_ops->prepare_write(.);
if (status) {
UnlockPage(page);
deactivate_page(page);
page_cache_release(page);
if (pos + bytes > inode->i_size)
vmtruncate(inode, inode->i_size);
break;
}
...
except that this variant would litter the main path. And the whole loop
is under the ->i_sem - check the beginning of the function.

-
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/

Re: [CONT PROBLEM] 2.4.1-pre3 - Undefined symbol `__buggy_fxsr_alignment'

[Shawn Starr]

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 `check_fpu':
> > init/main.o(.text.init+0x53): undefined reference to `__buggy_fxsr_alignment'
> > make: *** [vmlinux] Error 1
> >
> > same fatal error. Where is this function defined in the i386 asm header?
>
> It should not be present at all in the objects.
> The compiler optimizer should remove that call,
> which is just an example of similar kind of "if
> optimizer fails, here is cannon-fodder to alert
> users about it."
>
> > If so, I could fix this and submit a patch.
>
> > /* Enable FXSR and company _before_ testing for FP problems. */
> > /*
> >  * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
> >  */
> > if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
> > extern void __buggy_fxsr_alignment(void);
> > __buggy_fxsr_alignment();
> >
> > Where is this function? Where is it defined? When i grep the whole dir
> > i dont see this function anywhere?
>
> See the comment above the  offsetof()  call.
> Now think.   Figure out why things are at wrong offset.
> Has something been added into   task_struct  lately ?
> Or to  thread_struct,  which actually is processor context
> data where this 'thread.i386.fxsave' thing resides ?
>
> Oh yes,  if compilation DOES NOT happen with  -O  flag,
> this will also happen..
>
> > Shawn.
>
> /Matti Aarnio
> -
> 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/

-
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/

Re: ide.2.4.1-p3.01112001.patch

[Adrian Bunk]

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 for it during early 2.4.x).
>
> It hasnt gotten worse, its just its a very specific combination and its a
> well known problem (vendors dont enable auto dma for ide for this reason)
> 2.2.16 just covers the cases I know about (and slightly overdoes it for now)
>
> > We've already had one major fs corruption due to this, I want that fixed
> > _first_.
>
> I've got other reports too.
>...

At least some of the reported problems with VIA chipsets are fixed with
the VIA IDE driver v3.11 [1]. Are there any problems that still occur with
this driver?

cu,
Adrian

[1] http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-02/1291.html


-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi




-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

> 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:      4384IO-APIC-edge  keyboard
  2:  0  0  XT-PIC  cascade
  3: 79 59IO-APIC-edge  serial
  4:  12743  12850IO-APIC-edge  serial
 14:   7855   7885IO-APIC-edge  ide0
 15:   1990   1703IO-APIC-edge  ide1
 16:  0  0   IO-APIC-level  es1371, mga@PCI:1:0:0
 17: 24 28   IO-APIC-level  sym53c8xx
 18:  0  0   IO-APIC-level  bttv
 19: 460435 460402   IO-APIC-level  eth0, eth1, usb-uhci
NMI: 210303 210303 
LOC: 210285 210284 
ERR:  0

The interrupt which caused problems was 19 (with both network cards and USB on
it). It shows a high number of interrupts because I've been load-testing the
network. The mere fact that it shows this hig number of interrupts shows the
fix works...

As this is a BP6, I'm now supposed to go on about the dead chickens, dedicated
air conditioners, nuclear powersupplies and other magic you're supposed to buy
to get these boards running. Well, nothing of that sort, it is running on a
simple (but high quality) 235W PSU with heatgreased coolers on the CPUs and the
BX xhipset. Nothing is overclocked. CPU and chipset tmeperatures are 24.C and
32.C, respectively.

In short, nothing remarkable. All PCI slots are used, as you can see from my
first posting in this thread (which contains more info on the hardware).

//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: [DOS] emulation under linux

[Justin Zygmont]

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.
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 
> 
> ___
> Redhat-install-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/redhat-install-list
> 

-
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/

Re: [CONT PROBLEM] 2.4.1-pre3 - Undefined symbol `__buggy_fxsr_alignment'

[Matti Aarnio]

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 error. Where is this function defined in the i386 asm header?

It should not be present at all in the objects.
The compiler optimizer should remove that call,
which is just an example of similar kind of "if
optimizer fails, here is cannon-fodder to alert
users about it."

> If so, I could fix this and submit a patch.
 
> /* Enable FXSR and company _before_ testing for FP problems. */
> /*
>  * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
>  */
> if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
> extern void __buggy_fxsr_alignment(void);
> __buggy_fxsr_alignment();
> 
> Where is this function? Where is it defined? When i grep the whole dir
> i dont see this function anywhere?

See the comment above the  offsetof()  call.
Now think.   Figure out why things are at wrong offset.
Has something been added into   task_struct  lately ?
Or to  thread_struct,  which actually is processor context
data where this 'thread.i386.fxsave' thing resides ?

Oh yes,  if compilation DOES NOT happen with  -O  flag,
this will also happen..

> Shawn.

/Matti Aarnio
-
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/

Re: Subtle MM bug

[Russell King]

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 the page size,
you will always have alias issues.  These are ones where the cache lines
are indexed independent of virtual address (and therefore can have funny
cache line replacement algorithms).

And yes, you guessed which processor has it. ;)

(Sorry the CC list got trimmed, elm ate some of it.  I'm sure most of the
people who where on it were on lkml anyway)
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
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/

Fix for Adaptec Starfire resource handling

[Ion Badulescu]

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 your mouth shut and be thought a fool,
than to open it and remove all doubt.

--
--- linux-2.4.vanilla/drivers/net/starfire.cFri Aug 11 15:57:58 2000
+++ linux-2.4/drivers/net/starfire.cFri Jan 12 12:52:48 2001
@@ -390,7 +390,7 @@
static int card_idx = -1;
static int printed_version = 0;
long ioaddr;
-   int drv_flags, io_size = netdrv_tbl[chip_idx].io_size;
+   int drv_flags, io_size;

card_idx++;
option = card_idx < MAX_UNITS ? options[card_idx] : 0;
@@ -400,6 +400,7 @@
   version1, version2, version3);

ioaddr = pci_resource_start (pdev, 0);
+   io_size = pci_resource_len (pdev, 0);
if (!ioaddr || ((pci_resource_flags (pdev, 0) & IORESOURCE_MEM) == 0)) {
printk (KERN_ERR "starfire %d: no PCI MEM resources, aborting\n", 
card_idx);
return -ENODEV;
@@ -1359,6 +1360,9 @@

unregister_netdev(dev);
iounmap((char *)dev->base_addr);
+
+   release_mem_region(pci_resource_start (pdev, 0),
+  pci_resource_len (pdev, 0));

if (np->tx_done_q)
pci_free_consistent(np->pci_dev, PAGE_SIZE,

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

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 causes the
problem not to appear? Remember, it only appears under HEAVY network load. A
single nfs cp -rd  was not enough to hang my network, I needed to add
at least another cp -rd or some streaming audio or something else...

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

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 killing streaming audio and interactive network use, nothing hangs.
As soon as the ping flood is stopped, audio streams on and ssh sessions are
useable again. So, it seems to fix it...

Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Adaptec 29160N + Quantum Atlas 10K = Kernel 2.4 will _NOT_ boot.

[Andreas Henriksson]

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_
 > beating on the patches that _would_ be a big issue.  Things like 
security (_especially_
 > remote attacks), outright crashes, or just
 > totally unusable systems because it can't see the harddisk.

I get "Unknown device 24" when I try booting Kernel 2.4.0 (and it has been 
like this on all 2.4-test kernels too).

When I had my Plextor Plexwriter 8/2/20 CD-ROM attached it didn't even find 
my hard drive (Quantum Atlas 10K).

I have a Adaptec 29160N scsi card.

I've had some problems with 2.2.x too, sometimes it doesn't boot (time out 
and stuff like that on the scsi probing).

I have previously posted about this and none obviously cared, hope 
something will happen this time since I guess Adaptec 29160N + Quantum 
Atlas 10K would be a quite common combination. Anyone with the same 
hardware setup that would like to comment please mail me at 
[EMAIL PROTECTED] since I'm not on the linux-kernel mailing list. 
Comments would be appreciated.

Oh, by the way. Someone posted a patch for this that wasn't accepted. 
Reason: "It wasn't needed". (Although the patch didn't solve my second 
problem, the one with the cd-rom attached... still didn't find my hard 
drive). He/she had a Compaq something that also had problem booting. The 
patch was really just a 2.2.x rip off that added a few lines.

Ahh... still have it .. it's attached.
It probably won't apply cleanly but it's not that hard to do it manually. 
Better someone else fix it and resubmit it I'll probably just screw it up 
anyway. ;)

This patch was _not_ written by me, I don't really know what it does, and 
it doesn't solve the problem completely. (Booting 2.2.x isn't 100% reliable 
for me either, works most of the time though.)

I hope my english is understandable.

Best regards, Andreas Henriksson // [EMAIL PROTECTED]

 lin24scsi.patch

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Manfred Spraul]

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
deadlocks with level triggered ioapic irqs, do not use them" - I'm sure
ne2k-pci isn't the only driver that uses these function.

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.

I'll restart now from a fresh 2.4.0 tree:
Changes:

1) enable focus cpu.
2) apply the attached patch.

I'm not sure if it's a real fix or if it just hides the problem: my
sysrq patch has shown that clearing and setting the "level trigger" bit
in the io apic reanimates the IO APIC.

--
Manfred

--- build-2.4/arch/i386/kernel/io_apic.c.orig   Fri Jan 12 20:17:36 2001
+++ build-2.4/arch/i386/kernel/io_apic.cFri Jan 12 21:26:31 2001
@@ -134,6 +134,30 @@
spin_unlock_irqrestore(&ioapic_lock, flags);
 }
 
+DO_ACTION( __trigger_level,0, |= 0x8000, io_apic_sync(entry->apic))/* mask = 
+1 */
+DO_ACTION( __trigger_edge,  0, &= 0x7fff, )/* 
+mask = 0 */
+
+
+static void unmask_level_IO_APIC_irq (unsigned int irq)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&ioapic_lock, flags);
+   __trigger_level_IO_APIC_irq(irq);
+   __unmask_IO_APIC_irq(irq);
+   spin_unlock_irqrestore(&ioapic_lock, flags);
+}
+
+static void mask_level_IO_APIC_irq (unsigned int irq)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&ioapic_lock, flags);
+   __mask_IO_APIC_irq(irq);
+   __trigger_edge_IO_APIC_irq(irq);
+   spin_unlock_irqrestore(&ioapic_lock, flags);
+}
+
 static void unmask_IO_APIC_irq (unsigned int irq)
 {
unsigned long flags;
@@ -143,6 +167,7 @@
spin_unlock_irqrestore(&ioapic_lock, flags);
 }
 
+
 void clear_IO_APIC_pin(unsigned int apic, unsigned int pin)
 {
struct IO_APIC_route_entry entry;
@@ -1181,14 +1206,14 @@
  */
 static unsigned int startup_level_ioapic_irq (unsigned int irq)
 {
-   unmask_IO_APIC_irq(irq);
+   unmask_level_IO_APIC_irq(irq);
 
return 0; /* don't check for pending */
 }
 
-#define shutdown_level_ioapic_irq  mask_IO_APIC_irq
-#define enable_level_ioapic_irqunmask_IO_APIC_irq
-#define disable_level_ioapic_irq   mask_IO_APIC_irq
+#define shutdown_level_ioapic_irq  mask_level_IO_APIC_irq
+#define enable_level_ioapic_irqunmask_level_IO_APIC_irq
+#define disable_level_ioapic_irq   mask_level_IO_APIC_irq
 
 static void end_level_ioapic_irq (unsigned int i)
 {

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Ingo Molnar]

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 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.

Ingo

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[David Woodhouse]

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
interrupts die was usb-uhci, and that doesn't appear to use disable_irq.

But then again, I've only ever seen this happen once. It's not repeatable.

-- 
dwmw2


-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

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 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.

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

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 things.)

OK, maybe the Sun example was not the best to give for this code... But if
there are no hot-pluggable x86's around now (I think there are, but can not
recollect who made 'm...) and nobody is complaining, then it is fine with me...
I won't hot-unplug my BP6's CPU's anyway...

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Mark Hahn]

> 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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Ingo Molnar]

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 reverting back to a stock
> io_apic.c would cause instabilities (which would be weird, since I had
> no instabilities running only a patched 8390.c), I think the patch to
> 8390.c DOES remove the symptoms all by itself. No other patches seem
> necessary to get a stable box.

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

-
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/

Re: kernel.org signer broken?

[H. Peter Anvin]

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 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 to propagate
> > to the mirrors, unfortunately.
> 
> Ok, then rsync  won't find it either unless driven in
> file CRC verification mode (which is not usual...)
> 

Right; kernel.org does that once a day.

> You *must* change its time (e.g. with touch).
> 

Unfortunately, you can't -- because the signer relies on the timestamp to
know if the file it is mirroring has changed.

Probably the best solution is to touch the original file.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

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 driver (so that would be stock 8390,
> > patched apic.c, stock io_apic.c). Please let me know which you want...
> 
> WITH. patched 8390.c, patched apic.c, sock io_apic.c. My very strong
> feeling is that this will be a stable combination, and that this is what
> we want as a final solution.

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
reverting back to a stock io_apic.c would cause instabilities (which would be
weird, since I had no instabilities running only a patched 8390.c), I think the
patch to 8390.c DOES remove the symptoms all by itself. No other patches seem
necessary to get a stable box.

But I'll patch the mess again just fox kicks :-)

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Ingo Molnar]

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. 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 things.)

Ingo

-
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/

Re: kernel.org signer broken?

[Matti Aarnio]

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 size, it can take
> up to 24 hours for it to hit ftp.kernel.org, and even longer to propagate
> to the mirrors, unfortunately.

Ok, then rsync  won't find it either unless driven in
file CRC verification mode (which is not usual...)

You *must* change its time (e.g. with touch).

>   -hpa
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!

/Matti Aarnio
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Ingo Molnar]

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). Please let me know which you want...

WITH. patched 8390.c, patched apic.c, sock io_apic.c. My very strong
feeling is that this will be a stable combination, and that this is what
we want as a final solution.

Ingo

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

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 stuck-ne2k bug), but with
> TARGET_CPUS set to cpu_online_mask. (this later is needed for certain
> crappy BIOSes.)

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). Please let me know which you want...

Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

generic_file_write change in 2.4.0-ac8

[Chris Mason]

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
--- linux-2.4.0/mm/filemap.cWed Jan  3 02:59:45 2001
+++ linux.ac/mm/filemap.c   Thu Jan 11 17:26:55 2001
@@ -2578,6 +2625,13 @@
ClearPageUptodate(page);
kunmap(page);
goto unlock;
+sync_failure:
+   UnlockPage(page);
+   deactivate_page(page);
+   page_cache_release(page);
+   if (pos + bytes > inode->i_size)
+   vmtruncate(inode, inode->i_size);
+   goto done;
 }

 

-
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/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

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 on _every_
> board.

Of course. That's why I'm calling for bug reports.

> This is, in fact, why I will _NOT_ accept anything but a simple auto-dma
> disable for this problem for early 2.4.x. I hope that people will continue
> to work on and debug this problem, but it's just been around for too long,
> and it's obvious enough that it doesn't happen with all hardware that I
> doubt there is any other reasonable solution that doesn't require some
> _very_ extensive testing to verify.
> 
> I'd love to see people who see these problems and are willing to test out
> patches to fix it. But in parallel with that, I definitely want the 2.2.x
> "disable auto-DMA" thing for the big public. We can enable it later if
> some patch does seem to fix it for good.

Sure.

However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
That's because all VIA chipsets starting from vt82c586 to vt82c686b
(UDMA100), share the same PCI ID.

Would you prefer to filter just vt82c586 and vt82c586a as the comment in
Alan's code says or simply unconditionally kill autodma on all of VIA
chipsets, as Alan's code does?

-- 
Vojtech Pavlik
SuSE Labs
-
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/

Re: kernel.org signer broken?

[H. Peter Anvin]

[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 to propagate
to the mirrors, unfortunately.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Ingo Molnar]

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
TARGET_CPUS set to cpu_online_mask. (this later is needed for certain
crappy BIOSes.)

i believe the ne2k driver change is the key.

> > I have a first idea: we send an EOI to an interrupt that is masked on
> > the IO apic, perhaps that causes the problems.
>
> Sound plausible...

does not help. I've tried it (and many other combinations). I did not find
any direct workaround for this problem. (i tried very hard.)

Ingo

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

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 patched io_apic ((TARGET_CPUS 0xff)

> I have a first idea: we send an EOI to an interrupt that is masked on
> the IO apic, perhaps that causes the problems.

Sound plausible...

> I'm right now typing a patch.

I'll await yours instead of making my own patch this time... :-)

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Manfred Spraul]

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?
> 

Frank, please clarify:
you still run without disable_irq_nosync() in 8390.c?

I have a first idea: we send an EOI to an interrupt that is masked on
the IO apic, perhaps that causes the problems.

I'm right now typing a patch.

--
Manfred
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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 io-apic handling had some reason for
> them. Ingo, what was the focus-cpu thing?

Well, with 'this' (in 'could THIS be') I really meant the move from disable_irq
to the irq_safe spinlocks. I'm currently running with the patched 8390.c
driver, patched io_apic (TARGET_CPUS 0xff) and patched apic.c (focus cpu
enabled), and have had no problems yet... even though I'm running several
simulatnsous nfs cp -rd , streaming network audio, scanning with an
USB scanner, etc.

So far, it seems that the patch to 8390.c removed the symptoms. The changes to
apic.c and io_apic.c did not make the network hang come back. 

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Linus Torvalds]

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 heavy network
>load (which would have killed a non-patched driver within seconds). Network
>latency seems a bit higher, and there are some hiccups in the streaming audio
>(part of the network load, easy indicator of performance...), but no hangs.

Ok, so it's tentatively the IOAPIC disable/enable code.  But it could
obviously be something that just interacts with it, including just a
timing issue (ie the _real_ bug might just be bad behaviour when
changing IO-APIC state at the same time as an interrupt happens, and
disable/enable-irq just happen to be the only things that do it at a
high enough frequency that you can see the problem). 

Remind me: what polarity are your io-apic irq's? Level, edge, sideways?
Anything else that might be relevant?

Linus
-
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/

Re: Linux-2.4.0-ac7: Unresolved symbol "queued_sectors" in scsi_mod.o

[Jens Axboe]

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

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Ingo Molnar]

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 both cases
the hang happens. I spent a good deal of time trying to fix this problem,
but failed - so any fresh ideas are more than welcome.

Ingo

-
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/

[CONT PROBLEM] 2.4.1-pre3 - Undefined symbol `__buggy_fxsr_alignment'

[Shawn Starr]

 


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
fs/fs.o ipc/ipc.o \
 drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o  drivers/parport/driver.o
drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o
drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/input/inputdrv.o
\
 net/network.o \
 /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a
\
 --end-group \
 -o vmlinux
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 error. Where is this function defined in the i386 asm header?
If so, I could fix this and submit a patch.
[root@coredump linux]# grep -r "__buggy_fxsr_alignment" *
include/asm-i386/bugs.h:  extern void __buggy_fxsr_alignment(void);
include/asm-i386/bugs.h:  __buggy_fxsr_alignment();
include/asm/bugs.h:  extern void __buggy_fxsr_alignment(void);
include/asm/bugs.h:  __buggy_fxsr_alignment();
/* Enable FXSR and company _before_ testing for FP problems. */
    /*
 * Verify that the
FXSAVE/FXRSTOR data will be 16-byte aligned.
 */
    if (offsetof(struct task_struct,
thread.i387.fxsave) & 15) {
   
extern void __buggy_fxsr_alignment(void);
   
__buggy_fxsr_alignment();
Where is this function? Where is it defined? When i grep the
whole dir i dont see this function anywhere?
Shawn.
Shawn Starr wrote:
e i think it was just fixed in pre3 ;-)
+   if (offsetof(struct task_struct,
thread.i387.fxsave) & 15) {
+  
extern void __buggy_fxsr_alignment(void);
+  
__buggy_fxsr_alignment();
+   }
> GCC 2.95.2 -> PGCC 2.95.2(3?) patched. 2.4.0 compiles fine
>
> init/main.o: In function `check_fpu':
> init/main.o(.text.init+0x53): undefined reference to `__buggy_fxsr_alignment'
>
> make: *** [vmlinux] Error 1
>
> On compiling (and recompiling) i get this fatal error. This function
> does not exist anymore?
>
> Anyone else having this problem?
>
> Shawn Starr.
>

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Linus Torvalds]

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 = cpu_online_mask, was 0xFF.
> > 
> > Could you disable both bandaids? I disabled them, no problems so far.
> 
> I disabled both (I guess you meant the 'define TARGET_CPUS cpu_online' in
> io_apic.c?), and reverted my own patch, added your patch... Now running with
> the usual heavy network load, no problems so far... Also made USB produce
> interrupts (shares irq with network), no problems...
> 
> 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 io-apic handling had some reason for
them. Ingo, what was the focus-cpu thing?

Linus

-
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/

Linux-2.4.0-ac7: Unresolved symbol "queued_sectors" in scsi_mod.o

[Chris Rankin]

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 the .ver files in include/linux/modules contains
a reference to queued_sectors, nor does this symbol appear in
/proc/ksyms. However, it does appear in the System.map file as

c025335c B queued_sectors

I have worked around the problem by compiling scsi_mod.o into the
kernel instead.

Cheers,
Chris
-
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/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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, in fact, why I will _NOT_ accept anything but a simple auto-dma
disable for this problem for early 2.4.x. I hope that people will continue
to work on and debug this problem, but it's just been around for too long,
and it's obvious enough that it doesn't happen with all hardware that I
doubt there is any other reasonable solution that doesn't require some
_very_ extensive testing to verify.

I'd love to see people who see these problems and are willing to test out
patches to fix it. But in parallel with that, I definitely want the 2.2.x
"disable auto-DMA" thing for the big public. We can enable it later if
some patch does seem to fix it for good.

Linus

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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 disabled them, no problems so far.

I disabled both (I guess you meant the 'define TARGET_CPUS cpu_online' in
io_apic.c?), and reverted my own patch, added your patch... Now running with
the usual heavy network load, no problems so far... Also made USB produce
interrupts (shares irq with network), no problems...

Could this really be the solution?

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: 2.4 ate my filesystem on rw-mount

[Vojtech Pavlik]

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
> > trashes hard disks like that. The 2.2 one also did this sometimes but only
> > with specific chipset versions and if you have dma autotune on (thats why
> > currently 2.2 refuses to do tuning on VP3)
> >
> > -
> > 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 had exactly the same problem with my K6-350 and IDE VT82C586a
> on a kernet 2.2.16. i just made a hdparm to enable DMA and poo
> lost all data  reinstall necessary from scratch

Is this problem still present with 2.4.0? Well, you don't need to kill
your data to test this - make sure the kernel is mounting the
filesystems read only in the test. DMA will be probably enabled
automatically for your drives.

-- 
Vojtech Pavlik
SuSE Labs
-
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/

Re: 2.4 ate my filesystem on rw-mount

[Vojtech Pavlik]

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
> blam!  The RedHat init stripts got to the "remounting root read-write"
> point, and just froze solid.
> 
> Rebooting into RH7 failed, becauce inittab could not be found.  In fact
> the filesystem was completely messed up, with /dev empty, lots of device
> nodes in /etc, and files missing all over the place.  I had to reinstall
> RH7 from scratch.
> 
> I do not understand how this could happen during a remounting root rw.
> Is the filesystem really that unstable?
> 
> Am I right in suspecting DMA, which was enabled at the time?  Any other
> ideas?  Is it a known problem?
> 
> 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)
> 
> [I know this is not a very good trouble report, but it will have to do for
> the time beeing.  I hope to do more testing at a later time.]
> 
> /Tobias
> 
> PS. This is _not_ the same system that I reported IDE busy errors for.

Wow. Ok, I'm maintaining the 2.4.0 VIA driver, so I'd like to know more
about this:

1) What's the ISA bridge revision?
2) What's in /proc/ide/via?
3) What says hdparm -i on your devices?
4) If you mount your filesystem read-only, does it read garbage?

Thanks.

-- 
Vojtech Pavlik
SuSE Labs
-
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/

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

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
> >Intel 440*X Chipset groups.  Since it appears that their bug was copied
> >but other chipset makers..you see the picture clearly, right?
> 
> No.
> 
> That experimental patch is _experimental_, and has not been reported by
> anybody to fix anything at all.  Also, the DMA timeout on PIIX4 seems to
> have nothing at all to do with the very silent corruption on VIA. At
> least nobody has reported any error messages being produced on the VIA
> corruption cases.
> 
> In short, let's leave it out of a stable kernel for now, and add
> blacklisting of auto-DMA. Alan has a list. We can play around with
> trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport
> the thing once it has been sufficiently battletested that people believe
> it truly will work).

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.

Does anyone still have any vt82c586 or vt82c586a the 2.4 VIA driver is
corrupting data on?

I'd like to hear about such reports so that I can start debugging (and
perhaps get me one of those failing boards, they must be quite cheap
these days).

-- 
Vojtech Pavlik
SuSE Labs
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Manfred Spraul]

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 own patched version, which uses
> spin_lock_irq/spin_unlock_irq instead of
> spin_lock_irqsave/spin_unlock_irqrestore like you patch uses. Looking at
> spinlock.h, spin_lock_irq does a local irq disable, which seems to be closer to
> the original intent (disable_irq) than spin_lock_irqsave. Anyone want to
> comment on this?
> 
It's a bit dangerous: _if_ one of the function is called with disabled
local interrupts, then spin_unlock_irq would enable these interrupts.
That could cause other problems, but I haven't checked if these function
are actually called with disabled interrupts - e.g. the transmit
function is called with enabled interrupts.

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 disabled them, no problems so far.

Now back to the disable_irq_nosync().
--
Manfred
-
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/

Re: Linux booting from HD on Promise Ultra ATA 100

[Martin Josefsson]

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 itself as one at boottime)
> > 
> > boot = /dev/hde3
> > delay = 50
> > message = /boot/message
> > vga = extended
> > read-only
> > lba32
> > disk=/dev/hde
> >   bios=0x80
> 
> 
> The line "lba32" is for what? I have to ask this because I have never seen
> it in an example of a lilo.conf file before.

it is a BIOS extension that allows you to boot of a partition thats
located above cylinder 1024. I think it's called EDB or something like
that.

> Also you put "disk=/dev/hde and bios=0x80" to inform lilo that there was a
> disk there and its bios address is 0x80. Is this right?

yes.

> If I would follow your example then I would put:
> 
> lba32
> disk=/dev/hdf
>bios=0x82

I think that would be correct yes, and install LILO on hde (I think the
promise-card only tries to boot from primary master when you have selected
SCSI in BIOS. But I'm not sure.

/Martin

-
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/

RE: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Laramie Leavitt]

> 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 kernels did - the kernel would be confusing, but at least it
> > would be consistently confusing ;)
> 
> The earlier kernels were 98% consistent in providing the 
> "cpu_has" information
> via /proc/cpuinfo that is true information too.
> 
> What I am suggesting is to fix the few places to make the 
> /proc/cpuinfo 100%
> consistent reporting "cpu_has", and to provide the "can_I_use" 
> information in
> another place (for example with /proc/osinfo or a new "osflags" row in
> /proc/cpuinfo).
> 
> This way we are 100% consistent and we don't lose the "cpu_has" 
> information.
> 

Yes, but why?  If the features cannot be used by userspace, then 
2.2 should be fixed to use the current model.  If someone wants
the information about the cpu that is not provided by the 'cpu_allows'
(My view of 'can_I_use' ) can't they just do a 'cpuid' and get
it for themselves anyway?

Laramie
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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
spin_lock_irq/spin_unlock_irq instead of
spin_lock_irqsave/spin_unlock_irqrestore like you patch uses. Looking at
spinlock.h, spin_lock_irq does a local irq disable, which seems to be closer to
the original intent (disable_irq) than spin_lock_irqsave. Anyone want to
comment on this?

Anyway, still running under load, also got USB (which uses the same irq) to
produce some interrupts by scanning some stuff. No problems so far...

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: Where did vm_operations_struct->unmap in 2.4.0 go?

[Christian Zander]

> >> 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 gotten from IRC server irc.openprojects.net, channel
> >#nvidia. Or from http://ex.shafted.com.au/nvidia/
> 
> And what a pile of crud those patches are!!  Instead of using the clean
> replacement interface for get_module_symbol, nvidia/patch-2.4.0-PR hard
> codes the old get_module_symbol algorithm as inline code.
> 
> This patch violates the modules interface by accessing modules.c
> internal data.  It still suffers from all the problems that
> get_module_symbol had.  Because it is hard coded as inline code instead
> of a common function, will be much harder to fix when it breaks.
> 

The way I understand the inter_module mechanism, module A registers one
or several of its symbols using inter_module_register to make it or them 
available to other modules. Module B can then request any of the symbols
with inter_module_request and get a pointer. The inter_module mechanism 
guarantees that the symbol will be available until module B decides that 
the symbol is no longer needed and releases it by calling inter_module_put.

Saying that I should have made use of this mechanism for the specific
code in the Nvidia driver that we are talking about clearly shows that
you didn't look at it. The module used get_module_symbol to search its
own symbol table for parameters that may have been passed to it at load
time. Arguably, this is bad practise, but it is also the reason why using
your mechanism doesn't make any sense. Obviously, the module wouldn't
want to register private data to request it later on; the information
that would have to be passed to inter_module_register is the same that
the code in question intends to retrieve in the first place.

Contrary to what you're saying, the patch does not just inline the old
get_module_symbol algorithm nor does it access any of module.c's internal
data. What is does is to browse the list of the modules's _own_ symbols 
looking for a match. If it finds one, it returns the desired data.

> Whoever coded that patch should be taken out and shot, hung, drawn and
> quartered then forced to write COBOL for the rest of their natural
> life.

Excellent comment - it is just as appropriate as it is helpful.

--
--
 christian zander  we come to bury dos, not to praise it.
 [EMAIL PROTECTED]-- paul vojta
--

 PGP signature

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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 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?

Hm, I also sent in a (somewhat different) patch on my own... :-)]

Anyway, still running under heavy load...

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: 2.4.0 Keyboard and mouse lock

[Andrea Ferraris]

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 devices) was up and running.

Andrea
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Frank de Lange]

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 seconds). Network
latency seems a bit higher, and there are some hiccups in the streaming audio
(part of the network load, easy indicator of performance...), but no hangs.
Here's the patch:

--- linux/drivers/net/8390.c.orgFri Jan 12 19:52:38 2001
+++ linux/drivers/net/8390.cFri Jan 12 19:54:50 2001
@@ -242,15 +242,15 @@
 
/* Ugly but a reset can be slow, yet must be protected */

-   disable_irq_nosync(dev->irq);
-   spin_lock(&ei_local->page_lock);
+   /* disable_irq_nosync(dev->irq); */
+   spin_lock_irq(&ei_local->page_lock);

/* Try to restart the card.  Perhaps the user has fixed something. */
ei_reset_8390(dev);
NS8390_init(dev, 1);

-   spin_unlock(&ei_local->page_lock);
-   enable_irq(dev->irq);
+   spin_unlock_irq(&ei_local->page_lock);
+   /* enable_irq(dev->irq); */
netif_wake_queue(dev);
 }
 
@@ -285,9 +285,9 @@
 *  Slow phase with lock held.
 */
 
-   disable_irq_nosync(dev->irq);
+   /* disable_irq_nosync(dev->irq); */

-   spin_lock(&ei_local->page_lock);
+   spin_lock_irq(&ei_local->page_lock);

ei_local->irqlock = 1;
 
@@ -383,8 +383,8 @@
ei_local->irqlock = 0;
outb_p(ENISR_ALL, e8390_base + EN0_IMR);

-   spin_unlock(&ei_local->page_lock);
-   enable_irq(dev->irq);
+   spin_unlock_irq(&ei_local->page_lock);
+   /* enable_irq(dev->irq); */
 
dev_kfree_skb (skb);
ei_local->stat.tx_bytes += send_length;

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Manfred Spraul]

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 - the test is still running.

Frank, could you double check it?

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 0
//  EXTRAVERSION =
--- 2.4/drivers/net/8390.c  Thu Jan  4 22:00:55 2001
+++ build-2.4/drivers/net/8390.cFri Jan 12 19:53:47 2001
@@ -242,15 +242,15 @@
 
/* Ugly but a reset can be slow, yet must be protected */

-   disable_irq_nosync(dev->irq);
-   spin_lock(&ei_local->page_lock);
+/* disable_irq_nosync(dev->irq);*/
+   spin_lock_irqsave(&ei_local->page_lock, flags);

/* Try to restart the card.  Perhaps the user has fixed something. */
ei_reset_8390(dev);
NS8390_init(dev, 1);

-   spin_unlock(&ei_local->page_lock);
-   enable_irq(dev->irq);
+   spin_unlock_irqrestore(&ei_local->page_lock, flags);
+/* enable_irq(dev->irq); */
netif_wake_queue(dev);
 }
 
@@ -285,9 +285,9 @@
 *  Slow phase with lock held.
 */
 
-   disable_irq_nosync(dev->irq);
+/* disable_irq_nosync(dev->irq);*/

-   spin_lock(&ei_local->page_lock);
+   spin_lock_irqsave(&ei_local->page_lock, flags);

ei_local->irqlock = 1;
 
@@ -327,8 +327,8 @@
ei_local->irqlock = 0;
netif_stop_queue(dev);
outb_p(ENISR_ALL, e8390_base + EN0_IMR);
-   spin_unlock(&ei_local->page_lock);
-   enable_irq(dev->irq);
+   spin_unlock_irqrestore(&ei_local->page_lock, flags);
+/* enable_irq(dev->irq);*/
ei_local->stat.tx_errors++;
return 1;
}
@@ -383,8 +383,8 @@
ei_local->irqlock = 0;
outb_p(ENISR_ALL, e8390_base + EN0_IMR);

-   spin_unlock(&ei_local->page_lock);
-   enable_irq(dev->irq);
+   spin_unlock_irqrestore(&ei_local->page_lock, flags);
+/* enable_irq(dev->irq); */
 
dev_kfree_skb (skb);
ei_local->stat.tx_bytes += send_length;

Kernel oops in tcp_ipv4.c

[Patrick]

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 kernel oops. The syslog messages are:

Jan 11 21:10:06 ws2 kernel: tcp_v4_hash: bug, socket state is 1 
Jan 11 21:10:06 ws2 kernel: Unable to handle kernel NULL pointer
dereference at virtual address  
Jan 11 21:10:06 ws2 kernel: current->tss.cr3 = 0ca7c000, %cr3 = 0ca7c000 
Jan 11 21:10:06 ws2 kernel: *pde =  
Jan 11 21:10:06 ws2 kernel: Oops: 0002 
Jan 11 21:10:06 ws2 kernel: CPU:0 

The code that outputs the first message is in tcp_ipv4.c, and was added
in version 2.2.17. The code deliberately causes a kernel oops when it
encounters this bug, presumably because the IP stack is unusable at this
point.

If this code was deliberately added then presumably someone knows what
might cause the problem. Is there a patch somewhere that fixes this
problem?

regards,
Patrick

-- 
Patrick Mackinlay[EMAIL PROTECTED]
ICQ: 59277981tel: +44 7050699851
 fax: +44 7050699852
SpaceSurfer Limited  http://www.spacesurfer.com/
-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

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 kernels did - the kernel would be confusing, but at least it
> would be consistently confusing ;)

The earlier kernels were 98% consistent in providing the "cpu_has" information
via /proc/cpuinfo that is true information too.

What I am suggesting is to fix the few places to make the /proc/cpuinfo 100%
consistent reporting "cpu_has", and to provide the "can_I_use" information in
another place (for example with /proc/osinfo or a new "osflags" row in
/proc/cpuinfo).

This way we are 100% consistent and we don't lose the "cpu_has" information.

Andrea
-
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/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Dan Kegel]

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 do async file i/o on Linux? 

SGI has done lots of work on this, using kernel threads; 
they don't have a patch yet for 2.4.0, but they do support
2.2.17 and 2.4.0-test10.

TUX uses async I/O, I think, but it's inside the kernel.
I hear plans are afoot for giving userspace async I/O that
avoids creating threads; that should be more scalable than
SGI's approach, if it ever happens.

See http://www.kegel.com/c10k.html#aio for links and a few notes.
- Dan
-
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/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 other chipset makers..you see the picture clearly, right?

No.

That experimental patch is _experimental_, and has not been reported by
anybody to fix anything at all.  Also, the DMA timeout on PIIX4 seems to
have nothing at all to do with the very silent corruption on VIA. At
least nobody has reported any error messages being produced on the VIA
corruption cases.

In short, let's leave it out of a stable kernel for now, and add
blacklisting of auto-DMA. Alan has a list. We can play around with
trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport
the thing once it has been sufficiently battletested that people believe
it truly will work).

Linus
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Ingo Molnar]

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 timer IRQ happens only if
the APIC timer IRQ vector's priority level has more than 2 active vectors.
It's a very limited case, which does not happen in recent CPUs anyway
(such as the PIII).

> But that doesn't explain what happens with ne2k cards: neither 2.2 nor
> 2.4 have more than 2 interrupts in class for the hardware interrupt
> 16/19.

yep.

Ingo

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Manfred Spraul]

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 bug in hw_irq.h..
> 
I reread the 2.2 and 2.4 code:

2.2 spreads all vectors, even the internal interrupts (tlb flush,
reschedule, timer, call function) are spread.
Hmm. AFAICS there is one bug: 3 interrupts are in priority 5:

CALL_FUNCTION_VECTOR0x50
IRQ0_TRAP_VECTOR0x51
irq1: irq0+80x59

check arch/i386/kernel/irq.h and assign_irq_vector (io_apic.c)

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.

But that doesn't explain what happens with ne2k cards: neither 2.2 nor
2.4 have more than 2 interrupts in class for the hardware interrupt
16/19.
With 2.2 I don't have any problems, 2.4 hangs.

--
Manfred
-
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/

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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))
>{
>autodma_default = 0;
>break;
>}
>if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
>{
>autodma_default = 0;
>break;
>}
>
>
>PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_0
>PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_1

Can I get a patch, Andre?

Linus
-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

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 exactly what I meant by being messy and not having a good
control over capabilities, so I think it's a perfect example. 

The fact is, we've historically NOT had a good way of indicating which
features the kernel can try to take advantage of.  This is something
that 2.4.0 tries to fix - to have everything in one central place with
no way to get mixed up about whether the CPU has some feature or not. 
And then export that single source knowledge through /proc/cpuinfo. 

I happen to believe that it's a big advantage to have just a single
source of capability data, AND to have that capability data be available
to user mode - with no way for the user to be confused ("But
/proc/cpuinfo _said_ that the kernel had FXSR, why can't I use it?"). 

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 kernels did - the kernel would be confusing, but at least it
would be consistently confusing ;)

I don't buy that argument. I don't care that we got details like this
wrong before.

Linus
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Linus Torvalds]

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, we must reorder the vector numbers for our own interrupts
>(0xfb-0xff), but that doesn't explain our problems: we don't loose
>reschedule interrupts, we have problems with normal interrupts - and
>there we only use 2 irq at the same priority level.
>
>Btw, the kick patch I sent a few minutes ago revives my io apic.

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). 

"disable_irq()"/"enable_irq()" has always tended to be slightly
problematic.  It's not a set of semantics that maps well onto all
interrupt controllers (io-apic definitely included).  Drivers would
generally be better off if they disabled their own chip from sending
interrupts, rather than disabling the interrupt line the chip is on. 

(Of course, most drivers would be even _better_ off if they didn't play
games with irq disabling at all, but I think the 8390 driver does it
because otherwise it would suck too badly for words). 

If you are seeing this with a 8390 core, try to see if the problem goes
away if you remove the "disable_irq_nosync(dev->irq);" and
"enable_irq()" thing (which means that you need to change the
spinlocking at the same place to use irq-safe versions - this _will_
make for bad interrupt latency especially with ISA ne2000 cards, but it
would be interesting to hear if it makes the problem less likely to
happen). 

Linus
-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

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 the presence of asymetric MP.
> > 
> > Point taken, feel free to have a can_I_use per-cpu instead of global but don't
> > overwrite the cpu_has with it. 
> 
> Andrea, the whole POINT of "cpu_has_xxx" is for the kernel to test for
> features like this.

I'm only concerned about the semantics of fxsr and xmm in /proc/cpuinfo, _not_
about the kernel implementation and self contained #defines (that
I'd preferred if they really meant cpu_has and not can_I_use too, but
that's an our internal thing not visible from userspace).

fxsr and xmm in /proc/cpuinfo in 2.4.0, 2.4.1-pre[12], and 2.2.* means
"cpu_has" and _not_ "can_I_use".

So anybody using the fxsr and xmm in the "flags" row of /proc/cpuinfo as the
"can_I_use" will break in any kernel before 2.4.1-pre3.

Anybody reading fxsr and xmm as "cpu_has" will break in any kernel after
2.4.1-pre2.

This all I meant when I said that 2.4.1-pre3 broke /proc/cpuinfo.

I'd prefer if /proc/cpuinfo wasn't broken. That's all.

Andrea
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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 shows these entries:

Jan 12 19:22:57 behemoth kernel: SysRq: <0> NR Log Phy Mask Trig IRR Pol Stat Dest 
Deli Vect:
Jan 12 19:22:57 behemoth kernel: Before:
Jan 12 19:22:57 behemoth kernel:  00 003 03  011   1   11199
Jan 12 19:22:57 behemoth kernel: After switching to edge:
Jan 12 19:22:57 behemoth kernel:  00 003 03  001   1   11199
Jan 12 19:22:57 behemoth kernel: After switch back:
Jan 12 19:22:57 behemoth kernel:  00 003 03  011   1   11199

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

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 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).

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 other chipset makers..you see the picture clearly, right?

> We've already had one major fs corruption due to this, I want that fixed
> _first_.

Well since I do not have VIA boards and Vojtech Pavlik <[EMAIL PROTECTED]>
is doing that chipset, take that issue to him.  VIA has always been a HACK
fro mthe beginning because it was written off the whitepapers that stink.

The AMD and HPT366 code were to be in 2.4.0 release, but the early
surprize caused most to be off guard.

I will pull the TIMEOUT but this is one you have bitched me out before
about not fixing or attempting to fix.  You can not have it both ways.
This is why I made it a compile option and not default.  I have one report
that it does not helpthus I changed it to a compile option.  Yes one
report took it from mainstream to option.

Cheers,

Andre Hedrick
Linux ATA Development


-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Ingo Molnar]

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 priority.
> 
>
> Ok, we must reorder the vector numbers for our own interrupts
> (0xfb-0xff), but that doesn't explain our problems: we don't loose
> reschedule interrupts, we have problems with normal interrupts - and
> there we only use 2 irq at the same priority level.

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 bug in hw_irq.h..

the 'loss of interrupts' above does not include external interrupts, only
local interrupts (such as the APIC timer interrupt) can get lost in such a
situation.

(nevertheless there is something going on.)

Ingo

-
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/

Re: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> 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 worse, its just its a very specific combination and its a 
well known problem (vendors dont enable auto dma for ide for this reason)
2.2.16 just covers the cases I know about (and slightly overdoes it for now)

> We've already had one major fs corruption due to this, I want that fixed
> _first_.

I've got other reports too. 

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))
{
autodma_default = 0;
break;
}
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
{
autodma_default = 0;
break;
}


PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_0
PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_82C586_1



-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Manfred Spraul]

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 what they were, but some APIC versions do have errata
> and someting about 3 irqs at the same priority level rings a bell.

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 priority.


Ok, we must reorder the vector numbers for our own interrupts
(0xfb-0xff), but that doesn't explain our problems: we don't loose
reschedule interrupts, we have problems with normal interrupts - and
there we only use 2 irq at the same priority level.

Btw, the kick patch I sent a few minutes ago revives my io apic.

--
Manfred
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Manfred Spraul]

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 network hang (nmi_watchdog=0)
> ===
> 

It still hangs.

Frank, I've attached a proposed kick_IOAPIC pin. Could you try it?
I'm rebooting with that patch right now.
--
Manfred

1) add to the end of io_apic.c:

static void print_line(struct IO_APIC_route_entry* entry)
{
printk(KERN_EMERG " %02x %03X %02X  ",
0,
entry->dest.logical.logical_dest,
entry->dest.physical.physical_dest
);

printk("%1d%1d%1d   %1d   %1d%1d%1d%02X\n",
entry->mask,
entry->trigger,
entry->irr,
entry->polarity,
entry->delivery_status,
entry->dest_mode,
entry->delivery_mode,
entry->vector
);
}

void kick_IOAPIC_pin(int pin)
{
unsigned long flags;
struct IO_APIC_route_entry entry;

local_irq_save(flags);

*(((int *)&entry) + 1) = io_apic_read(0, 0x11 + 2 * pin);
*(((int *)&entry) + 0) = io_apic_read(0, 0x10 + 2 * pin);

printk(KERN_EMERG " NR Log Phy Mask Trig IRR Pol"
  " Stat Dest Deli Vect:   \n");
printk(KERN_EMERG "Before:\n");
print_line(&entry);

entry.trigger = 0;
io_apic_write(0, 0x11 + 2 * pin, *(((int *)&entry) + 1));
io_apic_write(0, 0x10 + 2 * pin, *(((int *)&entry) + 0));
udelay(10);
printk(KERN_EMERG "After switching to edge:\n");
print_line(&entry);

entry.trigger = 1;
io_apic_write(0, 0x11 + 2 * pin, *(((int *)&entry) + 1));
io_apic_write(0, 0x10 + 2 * pin, *(((int *)&entry) + 0));
udelay(10);
printk(KERN_EMERG "After switch back:\n");
print_line(&entry);

local_irq_restore(flags);
}

2) add to sysrq.c:
--- 2.4/drivers/char/sysrq.cMon Dec  4 02:48:19 2000
+++ build-2.4/drivers/char/sysrq.c  Fri Jan 12 18:37:57 2001
@@ -137,6 +137,9 @@
send_sig_all(SIGKILL, 1);
orig_log_level = 8;
break;
+   case 'q':
+   kick_IOAPIC_pin(19);
+
default:/* Unknown: help */
if (kbd)
printk("unRaw ");

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

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 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).

We've already had one major fs corruption due to this, I want that fixed
_first_.

Linus

-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Alan Cox]

> 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 message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Alan Cox]

> 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 versions do have errata
and someting about 3 irqs at the same priority level rings a bell.


-
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/

Re: 2.4 ate my filesystem on rw-mount

[Martin Laberge]

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 this sometimes but only
> with specific chipset versions and if you have dma autotune on (thats why
> currently 2.2 refuses to do tuning on VP3)
>
> -
> 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 had exactly the same problem with my K6-350 and IDE VT82C586a
on a kernet 2.2.16. i just made a hdparm to enable DMA and poo
lost all data  reinstall necessary from scratch

Martin Laberge
[EMAIL PROTECTED]


-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

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 per-cpu instead of global but don't
> overwrite the cpu_has with it. 

Andrea, the whole POINT of "cpu_has_xxx" is for the kernel to test for
features like this.

If you're not going to overwrite it when some feature is deemed disabled,
you're missing the whole _reason_ for having capabilities bitmaps in the
first place.

This is not negotiable. We used to have a damn mess in 2.2.x with all the
capabilities stuff, and 2.4.x finally cleans it up and gets it right
across different CPU's, exactly because we have a clean "this CPU can do
X" approach without any if's, but's and why's. 

The fact that 2.2.x has bad control over capabilities and is messy is NOT
an excuse to screw up forever. 

Linus

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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)

Jan 12 18:24:43 behemoth kernel: SysRq:
Jan 12 18:24:43 behemoth kernel: print_PIC()
Jan 12 18:24:43 behemoth kernel:
Jan 12 18:24:43 behemoth kernel: printing PIC contents
Jan 12 18:24:43 behemoth kernel: ... PIC  IMR: fffa
Jan 12 18:24:43 behemoth kernel: ... PIC  IRR: 
Jan 12 18:24:43 behemoth kernel: ... PIC  ISR: 
Jan 12 18:24:43 behemoth kernel: ... PIC ELCR: 1e00
Jan 12 18:24:43 behemoth kernel: print_IO_APIC()
Jan 12 18:24:43 behemoth kernel: number of MP IRQ sources: 23.
Jan 12 18:24:43 behemoth kernel: number of IO-APIC #2 registers: 24.
Jan 12 18:24:43 behemoth kernel: testing the IO APIC...
Jan 12 18:24:43 behemoth kernel:
Jan 12 18:24:43 behemoth kernel: IO APIC #2..
Jan 12 18:24:43 behemoth kernel:  register #00: 0200
Jan 12 18:24:43 behemoth kernel: ...: physical APIC id: 02
Jan 12 18:24:43 behemoth kernel:  register #01: 00170011
Jan 12 18:24:43 behemoth kernel: ... : max redirection entries: 0017
Jan 12 18:24:43 behemoth kernel: ... : IO APIC version: 0011
Jan 12 18:24:43 behemoth kernel:  register #02: 
Jan 12 18:24:43 behemoth kernel: ... : arbitration: 00
Jan 12 18:24:43 behemoth kernel:  IRQ redirection table:
Jan 12 18:24:43 behemoth kernel:  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
Jan 12 18:24:43 behemoth kernel:  00 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  01 003 03  000   0   01139
Jan 12 18:24:43 behemoth kernel:  02 003 03  000   0   01131
Jan 12 18:24:43 behemoth kernel:  03 003 03  000   0   01141
Jan 12 18:24:43 behemoth kernel:  04 003 03  000   0   01149
Jan 12 18:24:43 behemoth kernel:  05 003 03  000   0   01151
Jan 12 18:24:43 behemoth kernel:  06 003 03  000   0   01159
Jan 12 18:24:43 behemoth kernel:  07 003 03  000   0   01161
Jan 12 18:24:43 behemoth kernel:  08 003 03  000   0   01169
Jan 12 18:24:43 behemoth kernel:  09 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  0a 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  0b 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  0c 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  0d 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  0e 003 03  000   0   01171
Jan 12 18:24:43 behemoth kernel:  0f 003 03  000   0   01179
Jan 12 18:24:43 behemoth kernel:  10 003 03  010   1   01181
Jan 12 18:24:43 behemoth kernel:  11 003 03  010   1   01189
Jan 12 18:24:43 behemoth kernel:  12 003 03  010   1   01191
Jan 12 18:24:43 behemoth kernel:  13 003 03  010   1   01199
Jan 12 18:24:43 behemoth kernel:  14 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  15 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  16 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel:  17 000 00  100   0   00000
Jan 12 18:24:43 behemoth kernel: IRQ to pin mappings:
Jan 12 18:24:43 behemoth kernel: IRQ0 -> 2
Jan 12 18:24:43 behemoth kernel: IRQ1 -> 1
Jan 12 18:24:43 behemoth kernel: IRQ3 -> 3
Jan 12 18:24:43 behemoth kernel: IRQ4 -> 4
Jan 12 18:24:43 behemoth kernel: IRQ5 -> 5
Jan 12 18:24:43 behemoth kernel: IRQ6 -> 6
Jan 12 18:24:43 behemoth kernel: IRQ7 -> 7
Jan 12 18:24:43 behemoth kernel: IRQ8 -> 8
Jan 12 18:24:43 behemoth kernel: IRQ13 -> 13
Jan 12 18:24:43 behemoth kernel: IRQ14 -> 14
Jan 12 18:24:43 behemoth kernel: IRQ15 -> 15
Jan 12 18:24:43 behemoth kernel: IRQ16 -> 16
Jan 12 18:24:43 behemoth kernel: IRQ17 -> 17
Jan 12 18:24:43 behemoth kernel: IRQ18 -> 18
Jan 12 18:24:43 behemoth kernel: IRQ19 -> 19
Jan 12 18:24:43 behemoth kernel:  done.
Jan 12 18:24:43 behemoth kernel: print_all_local_APICs()
Jan 12 18:24:43 behemoth kernel:
Jan 12 18:24:43 behemoth kernel: printing local APIC contents on CPU#1/1:
Jan 12 18:24:43 behemoth kernel: ... APIC ID:  0100 (1)
Jan 12 18:24:43 behemoth kernel: ... APIC VERSION: 00040011
Jan 12 18:24:43 behemoth kernel: ... APIC TASKPRI:  (00)
Jan 12 18:24:43 behemoth kernel: ... APIC ARBPRI:  (00)
Jan 12 18:24:43 behemoth kernel: ... APIC PROCPRI: 
Jan 12 18:24:43 behemoth kernel: ... APIC EOI: 
Jan 12 18:24:43 behemoth kernel: ... APIC LDR: 0200
Jan 12 18:24:43 behemoth kernel: ..

Re: [DOS] emulation under linux

[Martin Laberge]

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 kernel 2.2.14-12. RH 6.2.
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> -
> 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/



-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Manfred Spraul]

> 
> [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 send an EOI by writing 0 to the EOI register of the local apic, and
then the local apic automagically checks it's ISR bitfield.
It takes the highest set bit and clears it. Then it checks that bit in
the TMR, and it if's also set in the TMR then it sends an EOI to the IO
apic.

The magic seems to be tamper proof: all bits are read only.

The bit on the IO apic is also read only.
Perhaps with brute force? Switch the interrupt to edge triggered on the
io apic, wait 1 usec, switch it back to level triggered. The IRR bit is
undefined for edge triggered interrupts, perhaps that clears the IRR
bit.

I would first concentrate on the differences between 2.2 and 2.4:

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.

--
Manfred
-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

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 entry to /proc (say "/proc/osinfo") to provide the "can_I_use"
> > informations instead (TSC included).  Breaking /proc/cpuinfo isn't the way to
> > go IMHO.
> 
> Sorry, but you're not taking the long view here,  "can_I_use" most
> definetly should be per-cpu...
> 
> 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 per-cpu instead of global but don't
overwrite the cpu_has with it. 

Andrea
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[David Woodhouse]

[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 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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Manfred Spraul]

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 only, so we can't set it to 0 to kick the io apic.

The Vector is 99, we must check that bit in the ISR, TMR and IRR of both
cpus.

cpu1:
> ISR: all bits 0
> TMR: only bit 0x99 is set
> IRR: all bits 0

cpu0:
> ISR: all bits 0
> TMR: only bit 0x89 is set
> IRR: bit 0xfc and bit 0xef are set.

ISR is the in-server register, 0 means that the cpu is not processing an
interrupt right now.

TMR is the trigger mode registers, 1 means that the local apic should
send an EOI to the io apic when the cpu signals the EOI to the local
apic.


IRR is the list of pending interrupts:
0xef is the local timer interrupt,
0xfc is the reschedule interrupt
(see include/asm-i386/hw_irq.h)

These bits are also read only.

If you search the IO APIC documentation: number 29056601 - just search
with google. The local APIC is documented in the main cpu handbook (PPro
or later), in the chapter about multiple processor management 

--
Manfred
-
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/

[PATCH] srcdocs for sysctl

[John Levon]

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 /home/S96/levonj5/disk/dontdiff linux/Documentation/DocBook/Makefile 
new/Documentation/DocBook/Makefile
--- linux/Documentation/DocBook/MakefileSun Dec 31 02:16:13 2000
+++ new/Documentation/DocBook/Makefile  Fri Jan 12 16:01:44 2001
@@ -9,12 +9,12 @@
 EPS-parportbook := $(patsubst %.fig, %.eps, $(IMG-parportbook))
 JPG-parportbook := $(patsubst %.fig, %.jpeg, $(IMG-parportbook))
 
+books: $(BOOKS)
+
 $(BOOKS): $(TOPDIR)/scripts/docproc
 
 .PHONY:books ps pdf html clean mrproper
 
-books: $(BOOKS)
-
 ps:$(PS)
 
 pdf:   $(PDF)
@@ -79,6 +79,7 @@
$(TOPDIR)/drivers/usb/usb.c \
$(TOPDIR)/fs/locks.c \
$(TOPDIR)/fs/devfs/base.c \
+   $(TOPDIR)/kernel/sysctl.c \
$(TOPDIR)/kernel/pm.c \
$(TOPDIR)/kernel/ksyms.c \
$(TOPDIR)/net/netsyms.c
diff -Naur -X /home/S96/levonj5/disk/dontdiff 
linux/Documentation/DocBook/kernel-api.tmpl new/Documentation/DocBook/kernel-api.tmpl
--- linux/Documentation/DocBook/kernel-api.tmpl Fri Jan 12 16:30:14 2001
+++ new/Documentation/DocBook/kernel-api.tmpl   Fri Jan 12 16:27:47 2001
@@ -60,6 +60,14 @@
   
   
 
+  
+ The proc filesystem
+ 
+ sysctl interface
+!Ekernel/sysctl.c
+ 
+  
+
   
  The Linux VFS
  The Directory Cache
diff -Naur -X /home/S96/levonj5/disk/dontdiff linux/fs/super.c new/fs/super.c
--- linux/fs/super.cFri Jan 12 16:30:33 2001
+++ new/fs/super.c  Fri Jan 12 16:28:21 2001
@@ -281,6 +281,8 @@
 
 static LIST_HEAD(vfsmntlist);
 
+static char nomem_name [] = "ENOMEM";
+
 /**
  * add_vfsmnt - add a new mount node
  * @nd: location of mountpoint or %NULL if we want a root node
@@ -303,9 +305,6 @@
  * will have to pass the visibility flag explicitly, so if we will add
  * support for such beasts we'll have to change prototype.
  */
-
-static char nomem_name [] = "ENOMEM";
-
 static struct vfsmount *add_vfsmnt(struct nameidata *nd,
struct dentry *root,
const char *dev_name)
diff -Naur -X /home/S96/levonj5/disk/dontdiff linux/kernel/sysctl.c new/kernel/sysctl.c
--- linux/kernel/sysctl.c   Fri Jan 12 16:30:38 2001
+++ new/kernel/sysctl.c Fri Jan 12 16:27:56 2001
@@ -483,13 +483,82 @@
return 0;
 }
 
+/**
+ * register_sysctl_table - register a sysctl heirarchy
+ * @table: the top-level table structure
+ * @insert_at_head: whether the entry should be inserted in front or at the end
+ *
+ * Register a sysctl table heirarchy. @table should be a filled in ctl_table
+ * array. An entry with a ctl_name of 0 terminates the table. 
+ *
+ * The members of the &ctl_table structure are used as follows:
+ *
+ * ctl_name - This is the numeric sysctl value used by sysctl(2). The number
+ *must be unique within that level of sysctl
+ *
+ * procname - the name of the sysctl file under /proc/sys. Set to %NULL to not
+ *enter a sysctl file
+ *
+ * data - a pointer to data for use by proc_handler
+ *
+ * maxlen - the maximum size in bytes of the data
+ *
+ * mode - the file permissions for the /proc/sys file, and for sysctl(2)
+ *
+ * child - a pointer to the child sysctl table if this entry is a directory, or
+ * %NULL.
+ *
+ * proc_handler - the text handler routine (described below)
+ *
+ * strategy - the strategy routine (described below)
+ *
+ * de - for internal use by the sysctl routines
+ *
+ * extra1, extra2 - extra pointers usable by the proc handler routines
+ *
+ * Leaf nodes in the sysctl tree will be represented by a single file
+ * under /proc; non-leaf nodes will be represented by directories.
+ *
+ * sysctl(2) can automatically manage read and write requests through
+ * the sysctl table.  The data and maxlen fields of the ctl_table
+ * struct enable minimal validation of the values being written to be
+ * performed, and the mode field allows minimal authentication.
+ *
+ * More sophisticated management can be enabled by the provision of a
+ * strategy routine with the table entry.  This will be called before
+ * any automatic read or write of the data is performed.
+ *
+ * The strategy routine may return
+ *
+ * < 0 - Error occurred (error is passed to user process)
+ *
+ * 0   - OK - proceed with automatic read or write.
+ *
+ * > 0 - OK - read or write has been done by the strategy routine, so
+ *   return immediately.
+ *
+ * There must be a proc_handler routine for any terminal nodes
+ * mirrored under /proc/sys (non-terminals are handled by a built-in
+ * directory handler).  Several default handlers are available to
+ * cover common cases -
+ *
+ * proc_dostring(), proc_dointvec(), proc_dointvec_jiffies(),
+ * proc_dointvec_min

Re: Linux 2.4.0-ac8

[J . A . Magallon]

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 2.4.1-pre series, would not be
better to start naming ac9 as pre3-ac1 ?

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.0-ac6 #1 SMP Thu Jan 11 11:56:52 CET 2001 i686

-
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/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Alexander V. Lukyanov]

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 descriptor, select() always returns 0.
>
> The definition of immediate is not 'instant'. Otherwise no I/O system would
> ever return anything but -EWOULDBLOCK. Its that it won't wait when there is
> no data pending. On a floppy there is always data pending

I have a long standing idea on modifying poll/read/write behavior on
regular files opened in O_NONBLOCK mode. How about the following scheme:

   * poll returns POLLIN/POLLOUT on regular files only if the data are
   in buffer cache/there is room for write().
   * read returns EAGAIN if the data are not in buffer cache.
   * write returns EAGAIN if there is no room (yet) to store the data.

All the operation should signal to IO subsystem that the data are
needed in cache/the room has to be freed.

--
   Alexander.
-
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/

Re: Subtle MM bug

[Eric W. Biederman]

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 thats undefined in the implementation ;))
> > 
> > Are there any other (not yet supported) platforms with similar (or other
> > unrelated, but hard to support because of the current architecture of
> > the kernel) problems?
> > 
> > (No, I have no secret trumps up my sleeve, I'm just curious.)
> 
> Having a reverse mappings is the least sucky way to handle virtual aliases
> of certain types of MIPS caches.

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.

You could also play some games with simply allocating pages only with the proper 
proper high bits.   These games might also be useful on architectures for L2 caches
who have significant physical bits than PAGE_SHIFT bits.

But how does a reverse mapping help to handle virtual aliases?  What are those
caches doing?  The only model in my head is having a virtually indexed cache
where you have more index bits than PAGE_SHIFT bits.

Eric

-
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/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

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 reason is that the way TSC gets disabled breaks /proc/cpuinfo.
> 
> No.
> 
> It FIXES /proc/cpuinfo.
> 
> Your alternative patch is the thing that breaks.

In 2.2.*, 2.4.0, 2.4.1-pre[12] and 2.4.0ac* `fxsr' and `xmm' in /proc/cpuinfo
means "cpu_has", you changed their meaning in 2.4.1-pre3 to "can_I_use". So now
unless you check the `uname -r` first you don't know anymore what fxsr and xmm
means (if either "cpu_has" or "can_I_use").

This means 2.4.1-pre3 broke /proc/cpuinfo IMHO (while pre2 plus my patch
didn't break anything).

> We _want_ /proc/cpuinfo to reflect the fact that the kernel considers
> FSXR/XMM to not exist. That is true information, and is in fact something
> that install scripts etc can find extremely useful.

The "cpu_has" is true information as well (certainly it's less interesting than
the "can_I_use" but that that's not a good reason for dropping the "cpu_has"
information while breaking the semantics of fxsr/xmm in /proc/cpuinfo).

> In particular, imagine an installation script that wants to install the
> proper optimized version of a library on a machine. How is it supposed to
> know whether it should use the mmx version, the xmm version, or the
> integer version?

Any userspace software that will use `fxsr' and `xmm' information in
/proc/cpuinfo as "can_I_use" will work correctly _only_ in 2.4.1-pre3 and later
kernels (unless it does checks on the kernel revision it's running on first)
and it will break in all 2.2.x, 2.4.0 and 2.4.1-pre[12] (if it's not
checking the kernel revision). This is also a proof of what I said above.

Nobody should ever consider fxsr and xmm as "can_I_use" for backwards
compatibilty reasons with 2.4.0 and 2.2.*.

> This is _exactly_ the kind of thing that /proc/cpuinfo was supposed to be
> able to deal with, and that means that if the kernel doesn't like to use

/proc/cpuinfo shows per-cpu infos, it's always been the "cpu_has" _per-cpu_
info (not the _global_ "can_I_use").

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 entry to /proc (say "/proc/osinfo") to provide the "can_I_use"
informations instead (TSC included).  Breaking /proc/cpuinfo isn't the way to
go IMHO.

> xmm for some reason (ie the user explicitly told it to), then it shouldn't
> show up in /proc/cpuinfo - because on that machine XMM simply does not
> exist as far as user-land is concerned.

So then why does bogomips and and f00f_bug and similar things show up in
/proc/cpuinfo if they aren't useful to user-land either?

/proc/cpuinfo is providing info that isn't just useful for user-land software
agreed, but it's useful for the user to see the details of his hw. That's
always been the case. In 2.2.x and 2.4.0 the user wasn't allowed to use xmm but
he _wanted_ to see "xmm" in the flags field to know the details of his
hardware. That's not an information for userland software but just for the
user.

> Similarly, when we disable TSC, it's also telling user-land that this
> machine does not appear to have a working TSC for some reason. User-land

And IMHO that's wrong too.

> After all, a user can always do a "cpuid" to get to know what the CPU
> itself reports. /proc/cpuinfo is supposed to be a higher-level interface,
> where the buggy bits have been removed or renamed (ie AMD extensions are
> properly renamed and can be easily recognized as such, without each
> user-mode application having to know about the magic meaning of bits in
> "cpuid" on different machines).

cpuid says the "cpu_has" not the "can_I_use" too.

Andrea
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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 the results from de debug log facility:

before network hang
===

Jan 12 16:18:30 behemoth kernel: SysRq:
Jan 12 16:18:30 behemoth kernel: print_PIC()
Jan 12 16:18:30 behemoth kernel:
Jan 12 16:18:30 behemoth kernel: printing PIC contents
Jan 12 16:18:30 behemoth kernel: ... PIC  IMR: fffa
Jan 12 16:18:30 behemoth kernel: ... PIC  IRR: 
Jan 12 16:18:30 behemoth kernel: ... PIC  ISR: 
Jan 12 16:18:30 behemoth kernel: ... PIC ELCR: 1e00
Jan 12 16:18:30 behemoth kernel: print_IO_APIC()
Jan 12 16:18:30 behemoth kernel: number of MP IRQ sources: 23.
Jan 12 16:18:30 behemoth kernel: number of IO-APIC #2 registers: 24.
Jan 12 16:18:30 behemoth kernel: testing the IO APIC...
Jan 12 16:18:30 behemoth kernel:
Jan 12 16:18:30 behemoth kernel: IO APIC #2..
Jan 12 16:18:30 behemoth kernel:  register #00: 0200
Jan 12 16:18:30 behemoth kernel: ...: physical APIC id: 02
Jan 12 16:18:30 behemoth kernel:  register #01: 00170011
Jan 12 16:18:30 behemoth kernel: ... : max redirection entries: 0017
Jan 12 16:18:30 behemoth kernel: ... : IO APIC version: 0011
Jan 12 16:18:30 behemoth kernel:  register #02: 0100
Jan 12 16:18:30 behemoth kernel: ... : arbitration: 01
Jan 12 16:18:30 behemoth kernel:  IRQ redirection table:
Jan 12 16:18:30 behemoth kernel:  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
Jan 12 16:18:30 behemoth kernel:  00 000 00  100   0   00000
Jan 12 16:18:30 behemoth kernel:  01 0FF 0F  000   0   01139
Jan 12 16:18:30 behemoth kernel:  02 0FF 0F  000   0   01131
Jan 12 16:18:30 behemoth kernel:  03 0FF 0F  000   0   01141
Jan 12 16:18:30 behemoth kernel:  04 0FF 0F  000   0   01149
Jan 12 16:18:30 behemoth kernel:  05 0FF 0F  000   0   01151
Jan 12 16:18:30 behemoth kernel:  06 0FF 0F  000   0   01159
Jan 12 16:18:30 behemoth kernel:  07 0FF 0F  000   0   01161
Jan 12 16:18:30 behemoth kernel:  08 0FF 0F  000   0   01169
Jan 12 16:18:30 behemoth kernel:  09 000 00  100   0   00000
Jan 12 16:18:30 behemoth kernel:  0a 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel:  0b 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel:  0c 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel:  0d 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel:  0e 0FF 0F  000   0   01171
Jan 12 16:18:31 behemoth kernel:  0f 0FF 0F  000   0   01179
Jan 12 16:18:31 behemoth kernel:  10 0FF 0F  010   1   01181
Jan 12 16:18:31 behemoth kernel:  11 0FF 0F  010   1   01189
Jan 12 16:18:31 behemoth kernel:  12 0FF 0F  010   1   01191
Jan 12 16:18:31 behemoth kernel:  13 0FF 0F  010   1   01199
Jan 12 16:18:31 behemoth kernel:  14 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel:  15 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel:  16 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel:  17 000 00  100   0   00000
Jan 12 16:18:31 behemoth kernel: IRQ to pin mappings:
Jan 12 16:18:31 behemoth kernel: IRQ0 -> 2
Jan 12 16:18:31 behemoth kernel: IRQ1 -> 1
Jan 12 16:18:31 behemoth kernel: IRQ3 -> 3
Jan 12 16:18:31 behemoth kernel: IRQ4 -> 4
Jan 12 16:18:31 behemoth kernel: IRQ5 -> 5
Jan 12 16:18:31 behemoth kernel: IRQ6 -> 6
Jan 12 16:18:31 behemoth kernel: IRQ7 -> 7
Jan 12 16:18:31 behemoth kernel: IRQ8 -> 8
Jan 12 16:18:31 behemoth kernel: IRQ13 -> 13
Jan 12 16:18:31 behemoth kernel: IRQ14 -> 14
Jan 12 16:18:31 behemoth kernel: IRQ15 -> 15
Jan 12 16:18:31 behemoth kernel: IRQ16 -> 16
Jan 12 16:18:31 behemoth kernel: IRQ17 -> 17
Jan 12 16:18:31 behemoth kernel: IRQ18 -> 18
Jan 12 16:18:31 behemoth kernel: IRQ19 -> 19
Jan 12 16:18:31 behemoth kernel:  done.
Jan 12 16:18:31 behemoth kernel: print_all_local_APICs()
Jan 12 16:18:31 behemoth kernel:
Jan 12 16:18:31 behemoth kernel: printing local APIC contents on CPU#0/0:
Jan 12 16:18:31 behemoth kernel: ... APIC ID:   (0)
Jan 12 16:18:31 behemoth kernel: ... APIC VERSION: 00040011
Jan 12 16:18:31 behemoth kernel: ... APIC TASKPRI:  (00)
Jan 12 16:18:31 behemoth kernel: ... APIC ARBPRI:  (00)
Jan 12 16:18:31 behemoth kernel: ... APIC PROCPRI: 
Jan 12 16:18:31 behemoth kernel: ... APIC EOI: 
Jan 12 16:18:31 behemoth ke

Re: Linux booting from HD on Promise Ultra ATA 100

[Stephen Torri]

-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
> message = /boot/message
> vga = extended
> read-only
> lba32
> disk=/dev/hde
>   bios=0x80


The line "lba32" is for what? I have to ask this because I have never seen
it in an example of a lilo.conf file before.

Also you put "disk=/dev/hde and bios=0x80" to inform lilo that there was a
disk there and its bios address is 0x80. Is this right?

If I would follow your example then I would put:

lba32
disk=/dev/hdf
   bios=0x82

Stephen

- -- 
Buyer's Guide for a Operating System:
Don't care to know: Mac
Don't mind knowing but not too much: Windows
Hit me! I can take it!: Linux
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Filter: gpg4pine 4.0 (http://azzie.robotics.net)

iD8DBQE6XyltI7ZT+dSlizsRAiM/AJ9SdDSNbYk1Pep2+guGakfYcYUYjQCgzLWR
BcrGeMP0DKwgZWo3m0KdEho=
=gGWn
-END PGP SIGNATURE-

-
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/

Re: Linux booting from HD on Promise Ultra ATA 100

[Martin Josefsson]

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 PIIX4). The setup was
> 
> /dev/hda - ST310232A, FwRev=3.09  (Seagate)
> /dev/hdb - 927308, FwRev=RA530JNO (Maxtor) * Linux installed here
> /dev/hdc - CD-532E-B (Teach CDROM)
> /dev/hdd - CD-RW4224A (Smart & Friendly CDRW).
> 
> Well I got an Promise Ultra ATA 100 controller card. Went over to
> linux-ide.org and get the patches for kernel-2.2.16. Took a pristine
> kernel-2.2.16 and patched it and then compiled it on a RedHat 6.2
> system. I then made a bootdisk with this new kernel.
> 
> So then I installed the drives in this order:
> 
> (Mainsboard controller)
> primary master - ST310232A (Seagate)
> primary slave - none
> secondary master - CDROM
> secondary slave - CDRW
> 
> (Promise controller)
> primary slave - IBM-DLTA-307045 (IBM)
> primary slave - 927308 (Maxtor) * Linux install here
> secondary master - none
> secondary slave - none
> 
> The system boots if I use the bootdisk and tell it "linux
> root=/dev/hdf3".  I edited the lilo.conf and the fstab for the new
> setup. I can log in and do my business with my the linux partition but
> when I tried to use lilo to setup the MBR on the first disk (mainsboard) I
> got this:
> 
> warning: BIOS Drive 0x82 may not be accessible.
> 
> Is there some settings that I need to give to the lilo to boot?

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
message = /boot/message
vga = extended
read-only
lba32
disk=/dev/hde
  bios=0x80

image=/boot/kernel/vmlinuz-2.4.1-pre2
  label = Linux
  root = /dev/hde5

image=/boot/kernel/vmlinuz-2.4.0-test10
  label = test10
  root = /dev/hde5




This works perfectly fine here

/Martin

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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...

Before network hang
===

print_PIC()
printing PIC contents
print_IO_APIC()
testing the IO APIC...

 done.
print_all_local_APICs()

... APIC ID:  0100 (1)
... APIC VERSION: 00040011










0100









0001


... APIC ID:   (0)
... APIC VERSION: 00040011










01000100









1000

NOTICE: results differ every time I hit ALT-SYSRQ-A.
The '1' bit at 'row 11, col. 26' stays '1'
no matter how many times I use the magic keys.
The other '1' bits jump around a bit, or
disappear alltogether. Also, the sequence
in which the APICs appear in the dump sometimes
differs (this example shows 1 first, then 0,
other times you'd see 0 first, then 1)

After network hang
==

print_PIC()
printing PIC contents
print_IO_APIC()
testing the IO APIC...

 done.
print_all_local_APICs()

... APIC ID:   (0)
... APIC VERSION: 00040011










0100









0001


... APIC ID:  0100 (1)
... APIC VERSION: 00040011










0100









0001

NOTICE: hmmm... see, now that '1' bit at row 11,
col. 26 for APIC 0 which was '1' before
has turned to '0'. It will stay '0' no
matter how many times I hit the magic keys...
It seems to have been replaced by the '1'
bit at row 11, col. 10, since that bit 
stays '1' no matter how many magic I
throw at it...

Hope this helps... If you need more, let me know...

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux

Linux 2.4.0-ac8

[Alan Cox]

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 my vm
diffs in favour of his
o   PC110 pad move to new driver style  (Hans Grobler)
o   Clean up/fix leaks in ncr885e   (Hans Grobler)
o   Move dsp56k to new style module stuff   (Hans Grobler)
o   check->request_region, resource leak fixes  (Hans Grobler)
for qlogicisp
o   Fix iounmap leak in iphase  (Hans Grobler)
o   Fix iounmap leaks in ymf_pci(Hans Grobler)
o   Fix s390mach.c for non SMP  (Ulrich Weigand)
o   Export queued_sectors   (Jens Axboe)
o   Fix raid5 build after Linus merge   (Andrea Arcangeli)
o   Documentation and chkconfig update  (Niels Jensen)
o   Fix iounmap leaks in oaknet (Arnaldo Carvalho de Melo)
o   Clean up mac89x0(Arnaldo Carvalho de Melo)
o   Fix leaks on error in myri_sbus (Arnaldo Carvalho de Melo)
o   Convert macsonic.c to new style (Arnaldo Carvalho de Melo)
o   RCPCI further fixes (Rasmus Andersen)

2.4.0-ac7
o   Export a KMALLOC_MAXSIZE for drivers to check   (Hans Grobler)
| this is needed to verify things like firmware
| sizes passed by users
o   Fix highmem compile issues  (Ingo Molnar)
o   Fix kmalloc check missing in hades-pci  (Hans Grobler)
o   Fix kmalloc fail crash in sdla_ppp  (Hans Grobler)
o   cfi locking fixes   (Hans Grobler)
o   Fix missing spin_unlock_irq in hd6457x.c(Hans Grobler)
o   Fix lmc_main missing skb_unlock on error case   (Hans Grobler)
o   Handle out of memory on lanstreamer (Hans Grobler)
o   Bring cs46xx.c into working state for non   (Hans Grobler)
module. Fix locking
o   Fix filesystem locking documentation(Al Viro)
o   Fusion driver updates   (Steve Ralston)
o   Correct netfilter url   (Rusty Russell)
o   rcpci45 fix the pci_table name (again)  (Hans Grobler)
o   Fix scsi option ordering bug noted by   (Michael Zieger)
o   Config.h include updates(Niels Jensen)
o   LFS handling cleanup, move some checks to   (Al Viro)
vmtruncate
o   Fix missing s->maxbytes setup for procfs(me)
o   Replace epic100 patches with alternatives   (Jeff Garzik)
o   eepro fixes for older cards (Aristeu Sergio
 Rozanski Filho)
o   Buz error handling fix  (Hans Grobler)
o   DGRS driver cleanups/kmalloc checks (Arnaldo Carvalho 
de Melo)
o   Fix ioremap leak in zr36120 (Hans Grobler)
o   FIx iounmap leaks in Stradis driver (Hans Grobler)
o   Further mtd fixes   (David Woodhouse)
o   Update yellowfin driver (Jeff Garzik, from
 Don Beckers drivers)
o   Fix iounmap bugs in vga16   (Hans Grobler)
o   TCP odd error fix   (Dave Miller)
o   ll_rw_blk enhancements  (Jens Axboe)
o   DMFE driver cleanup (Pavel Rabel)
o   iucv fix for S/390 build when non SMP   (Ulrich Weigand)
o   Merge linus -pre2
o   Fix ixj kmalloc checks  (Ingo Molnar)
o   Fix null pointer check in ibm partition code(Ingo Molnar)
o   Fix kmalloc check in pc_keyb(Ingo Molnar)
o   Fix kmalloc check in atari_pamsnet  (Ingo Molnar)
o   Fix kmalloc check in 3c515  (Ingo Molnar)
o   Tidy up defxx/fix module locks etc  (Jeff Garzik)
o   Fix kmalloc check in atari_bionet   (Ingo Molnar)
o   Fix kmalloc check in olympic driver (Ingo Molnar)
o   Fix kmalloc checks in avmb1 driver  (Ingo Molnar)
o   Tokenring needs to be an object file as its (Jeff Garzik)
using initcalls

2.4.0-ac6
o   Sunrpc locking fix  ()
o   Made agpgart smarter about i815 (Charles McLachlan)
o   Speed up truncate for shmem and clean up(Christoph Rohland)
o   Fix kmalloc test in udf (Ingo Molnar)
o   Fix ram

Linux booting from HD on Promise Ultra ATA 100

[Stephen Torri]

-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  (Seagate)
/dev/hdb - 927308, FwRev=RA530JNO (Maxtor) * Linux installed here
/dev/hdc - CD-532E-B (Teach CDROM)
/dev/hdd - CD-RW4224A (Smart & Friendly CDRW).

Well I got an Promise Ultra ATA 100 controller card. Went over to
linux-ide.org and get the patches for kernel-2.2.16. Took a pristine
kernel-2.2.16 and patched it and then compiled it on a RedHat 6.2
system. I then made a bootdisk with this new kernel.

So then I installed the drives in this order:

(Mainsboard controller)
primary master - ST310232A (Seagate)
primary slave - none
secondary master - CDROM
secondary slave - CDRW

(Promise controller)
primary slave - IBM-DLTA-307045 (IBM)
primary slave - 927308 (Maxtor) * Linux install here
secondary master - none
secondary slave - none

The system boots if I use the bootdisk and tell it "linux
root=/dev/hdf3".  I edited the lilo.conf and the fstab for the new
setup. I can log in and do my business with my the linux partition but
when I tried to use lilo to setup the MBR on the first disk (mainsboard) I
got this:

warning: BIOS Drive 0x82 may not be accessible.

Is there some settings that I need to give to the lilo to boot?

Stephen

- -- 
Buyer's Guide for a Operating System:
Don't care to know: Mac
Don't mind knowing but not too much: Windows
Hit me! I can take it!: Linux
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Filter: gpg4pine 4.0 (http://azzie.robotics.net)

iD8DBQE6XyOTI7ZT+dSlizsRAu3BAKCdtwlgiJ9+isy9NOlltIs+logHMgCfViiy
ofYOmWxhH6Qt8FDeoJNZvsg=
=+RwL
-END PGP SIGNATURE-

-
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/

Re: khttpd beaten by boa

[Ingo Oeser]

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 kernel.
> Regarding wether either khttpd or TuX should be in the kernel: I take it
> that it is your oppinion that neither should be in the kernel. I disagree
> with that and I think having a http-server-engine  (or even a more generic
> file-serving engine) in the kernel can make sense for high-end uses. The
> average desktop-user doesn't profit from it, sure. But that also holds for
> things like hardware-raid or even SCSI. We still want those in though.

This thingie is nice for embedded use, where you need a webserver
for some stuff, but don't wan't to include one, because you need
it only to represent some machine values of a process
computer[1].

But we need a more generic one, which has the functionality of a
read only entry of /proc.

That would be _very_ useful.

Regards

Ingo Oeser

[1] Don't know the right translation for "Prozessrechner", Sorry ;-(
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
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/

Re: Ingo's RAID patch for 2.2.18 final?

[Oliver Teuber]

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 finish it I will send the patch to mingo :)
> > 
> > try http://www.linuxraid.org/
> 
> If I see it there is no raid patch for 2.2.18 final, only
> 2.2.18pre13. This patch (raid-2.2.18-A2) rejects some diffs. I will apply
> it by hand :)
> 
> -- 
> Takika
> 
> -
> 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/
-
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/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Andries . Brouwer]

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 not block the calling process. 

the man pages are wrong

Don't you think cc'ing the man page maintainer [[EMAIL PROTECTED]]
would be a good idea whenever you think something is wrong
in the man pages? You never know, they might even improve.

In this particular case I don't think anything is actually
wrong, but I can well imagine that someone can invent clearer
wording. It would also be useful to more clearly separate
POSIX-mandated behaviour and actual Linux behaviour.
Suggestions and patches are welcome as always.

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/

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Tim Wright]

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()
> 
> into this:
> 
>   down(sem)
>   
>   up(sem)
> 
> had the effect of *decreasing* Apache's maximum connection rate
> on an 8-way from ~5,000 connections/sec to ~2,000 conn/sec.
> 
> That's downright scary.
> 
> Obviously,  was very quick, and the CPUs were passing through
> this section at a great rate.
> 
> How can we be sure that converting spinlocks to semaphores
> won't do the same thing?  Perhaps for workloads which we
> aren't testing?
> 
> So this needs to be done with caution.
> 

Hmmm...
if  is very quick, and is guaranteed not to sleep, then a semaphore
is the wrong way to protect it. A spinlock is the correct choice. If it's
always slow, and can sleep, then a semaphore makes more sense, although if
it's highly contented, you're going to serialize and throughput will die.
At that point, you need to redesign :-)
If it's mostly quick but occasionally needs to sleep, I don't know what the
correct idiom would be in Linux. DYNIX/ptx has the concept of atomically
releasing a spinlock and going to sleep on a semaphore, and that would be
the solution there e.g.

p_lock(lock);
retry:
...
if (condition where we need to sleep) {
p_sema_v_lock(sema, lock);
/* we got woken up */
p_lock(lock);
goto retry;
}
...

I'm stating the obvious here, and re-iterating what you said, and that is that
we need to carefully pick the correct primitive for the job. Unless there's
something very unusual in the Linux implementation that I've missed, a
spinlock is a "cheaper" method of protecting a short critical section, and
should be chosen.

I know the BKL is a semantically a little unusual (the automatic release on
sleep stuff), but even so, isn't

lock_kernel()
down(sem)

up(sem)
unlock_kernel()

actually equivalent to

lock_kernel()

unlock_kernel()

If so, it's no great surprise that performance dropped given that we replaced
a spinlock (albeit one guarding somewhat more than the critical section) with
a semaphore.

Tim

--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[Frank de Lange]

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 everything is good
> 2: Type ALT-SYSRQ-A when everything is bad
> 3: send the resulting logs.

WillCo...

Now rebuilding...


Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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/

Re: APIC ERRor on CPU0: 00(02) ...

[Mark Hahn]

> 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 an out-of-spec capacitor (if v1.1).
jeez, it's almost like a 12-step program for recovering from BP6ing ;)

>  This message doesn 't  appears in Kernel-2.2.17 only in Kernel-2.4

indeed: the error still happens in 2.2, but is simply not reported.
note also that this message is a *warning* - an inter-apic message 
was corrupted, and automatically retried.

regards, mark hahn.

-
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/

Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.

[Michael Rothwell]

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 slow environment) with
> > O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on
> > the file descriptor, select() always returns 0.
> 
> The definition of immediate is not 'instant'. Otherwise no I/O system would
> ever return anything but -EWOULDBLOCK. Its that it won't wait when there is
> no data pending. On a floppy there is always data pending


How about using fcntl(), O_ASYNC and SIGIO? Or maybe a broader question:
what's the preferred/working way to do async file i/o on Linux?

-M
-
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/

Re: kernel.org signer broken?

[Andries . Brouwer]

> 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/

APIC ERRor on CPU0: 00(02) ...

[V.P.]

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)
APIC error on CPU1: 04(02)


What wrongs ?

 This message doesn 't  appears in Kernel-2.2.17 only in Kernel-2.4

  Any Help is apreciated


  V.P. ***  Linux **  Porto *** Portugal

-
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/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware related?

[David Woodhouse]

[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
> problems on 2.2.x kernels. 

IRQ 19 on my BP6 stopped arriving a few days ago. 

 19:  90373  90473   IO-APIC-level  usb-uhci

Removing and reloading the usb-uhci driver didn't help. Loading the uhci 
driver just oopsed, which seems to be its normal behaviour on the occasions 
on which I try it.

Rebooting fixed it. I was half tempted to code a 'kick APIC because I think 
it broke' function, but then decided not to bother.

It might be nice in 2.5 to give drivers some way of kicking the APIC when 
they think they've missed an interrupt, much like the network code kicks 
the driver. And to deal more gracefully with IRQ storms.

Once a driver has a way of saying "Oi! Why isn't IRQ x working?" it would 
be feasible to just disable the damn thing if we receive a million of them 
in rapid succession.

--
dwmw2


-
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/