Re: [patch] mousedev.c

[Igmar Palsenberg]

Hi,

Patch looks not necessary. The compiler executes the statements until it
encounters a break.

> -   case BTN_EXTRA:  if (list->mode > 1) 
>{ index = 4; break; }
> +   case BTN_EXTRA:  if (list->mode > 1) 
>index = 4; break;




Igmar

-
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: Using floating point in the kernel

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:
> On Wed, 20 Sep 2000, Timur Tabi wrote:

> Well the code does a fnsave. Somebody never looked at the damn book! it
> takes 143 clocks for this, plus at least 3 for fwait.  Then it sets a
> flag to let return code 'know' if the context has to be restored. This
> code `exists` sort of like moss. I don't think it is ever executed and
> if it is, you get to keep both broken pieces.

+--+-+
| non-MMX clear_page   | 2382 cycles | 
| MMX clear_page   |  874 cycles |
+--+-|
| non-MMX copy_page| 4569 cycles |
| MMX copy_page| 1748 cycles |
+--+-+

(On a AMD Duron 700Mhz with 2 133Mhz DIMMs)

The numbers above don't include the fnsave. But as you can see the 150
cycles you mention above are still worth it. 

Greetings,
   Arjan van de Ven


< The test program is available at http://www.fenrus.demon.nl/athlon.c >
-
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: [PATCH] ISAPNP using an invalid IO_APIC IRQ

[M.H.VanLeeuwen]

Linus Torvalds wrote:
> 
> On Thu, 21 Sep 2000, M.H.VanLeeuwen wrote:
> >
> > Is this patch acceptable?
> 
> Please explain.
> 
> The test seems to be that "if there are IO_APICs, a PnP irq _has_ to be an
> IO_APIC irq".
> 
> > +   if (!IO_APIC_IRQ(irq) && io_apic_irqs)
> > +   return 1;
> 
> Which makes no sense to me. Why would a legacy irq not be acceptable?

firstly, I have no understanding of IO_APIC vs. legacy IRQ handling in i386
hardware so what I say may be completely wrong.  I'll explain my circumstance
and we'll go from there.

Legacy would be just fine, but ISAPNP is attempting to assign an IRQ that is
unavailable on my system.  In otherwords, the BIOS has assigned it to some
other function and thus the IRQ doesn't appear to Linux as even existing.
In my case IRQ5 was assigned to "DISPLAY CONTROLLER" and IRQ5 isn't available
to the system, excerpts from dmesg:
...
Bus #2 is ISA
I/O APIC #2 Version 17 at 0xFEC0.
Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04  *** NO ISA IRQ 5 ***
Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
...
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22, 2-23 not connected.
 ^ no IRQ 5 ?
...
 IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 04 003 03  000   0   01149
 05 000 00  100   0   00000   *** IRQ 5 ??? ***
 06 003 03  000   0   01151

Yet ISAPNP decided to assign that IRQ5 to my NIC.  ne.c fails to operate
when there are plenty of other IRQs still available.

The difference is in this logic between _no_ IO-APIC and _yes_ IO_APIC
in isapnp.c

isapnp_for_each_dev(dev) {
if (dev->active) {
if (dev->irq_resource[0].start == irq ||
dev->irq_resource[1].start == irq)
return 1;

}
}  

since w/o IO_APIC no PIC->APIC IRQ transform is done and this returns 1
and IRQ 5 is not used.  With IO_APIC no match occurs and the system attempt
to use IRQ 5, thus a hung system.

Hence, my attempt to rule out APIC IRQs that were unavailable to the system,
also assuming the legacy IRQs would also not be available.  This may not be
globally true, but seems to be on my system.  Abit BP6, nu Bios.

This entire problem would not have bothered me too badly, had the system
come up and run, but w/o explicitly telling the BIOS to reserve an ISA
IRQ ISAPNP eventually decides to try IRQ 12.  IRQ sharing with PS/2 mouse
and ne.c fail miserably.  On 2.2.X I had been using IRQ9 for ne.c card.
With 2.4 IRQ 9 is listed after IRQ 12 in xtab[16] (isapnp.c) so the system
fails to boot.

> Especially as they seem to be acceptable if there are _no_ IO-APIC irq's.

Only if they work. ;)

More info on request or tell me to go away, _grin_ again.

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: [PATCH] Fix sg in 2.4.0-test9-pre5 when builtin

[Jeff Garzik]

Douglas Gilbert wrote:
> @@ -1298,18 +1302,20 @@
>  }
> 
>  #ifdef MODULE
> -
>  MODULE_PARM(def_reserved_size, "i");
>  MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
> +#endif /* MODULE */

MODULE_xxx typically doesn't need to be surrounded by ifdef MODULE.

Also note that proc_fs.h provides no-op inline replacements for the
!CONFIG_PROC_FS case.  If you want to be really space conscious, you
still need the ifdef's in the code for the most part, but the no-ops
sometimes eliminate ifdefs if you look carefully.

Jeff
-
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: cPCI development

[Dan Hollis]

On Thu, 21 Sep 2000, Alan Cox wrote:
> I'd disagree on the ISP thing too btw. Telcos care a lot about hotswap PCI,
> but ISP services you can take a down box with a failover of a machine -
> which in general is a lot easier and overall better coverage

Alan, you want an ISP to configure identical machines for linux routers
just so they can hotswap NICs? What have you been putting in your tea 
lately 8)

Clustering synchronous serial routers? Thatd be a neat trick. Yes cisco
has HSRP but its not quite the same thing and you cant have both ciscos
going to the same T1 RJ45 jack on the telco demarc.

Yes you can failover your mail server, but your core linux routers are
another story and thats where hotswap really counts. Customers can
tolerate short mailserver outages but they cant tolerate short router
outages.

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

[PATCH] Fix sg in 2.4.0-test9-pre5 when builtin

[Douglas Gilbert]

Linus,
This patch has been generated in response to the thread: 
"[2.4.0-test9-pre5] SCSI still broken, trident/mixer 
still broken" on lkml today. Simon Kirby reported that
the SCSI generic (sg) wasn't working in the latest
pre-release when the driver was built into the kernel.

Torben Mathiasen wrote:
> 
> On Thu, Sep 21 2000, Douglas Gilbert wrote:
> > Torben Mathiasen wrote:
> > >
> > > Ok, small patch cooked up. Not tested, not compiled. Give
> > > it a try, and if it works please send it off to Linus.
> > > I really need to get some work done on a project...
> >
> > Here is a very similar patch that has been tested
> > [with a USB zip drive using sg (builtin) to read it].
> > It worked and the /proc/scsi/sg directory was
> > properly populated.
> >
> 
> Looks good, but you should make the init functions static.

Done. Also added conditionals to make it compile cleanly
when procfs is not present. Tested as builtin and module,
with and without procfs.

Doug Gilbert

--- linux/include/scsi/sg.h Sun Jul 16 18:38:11 2000
+++ linux/include/scsi/sg.h3117 Thu Sep 21 20:00:08 2000
@@ -11,9 +11,13 @@
 Version 2 and 3 extensions to driver:
 *   Copyright (C) 1998 - 2000 Douglas Gilbert
 
-    Version: 3.1.16 (2716)
-This version is for 2.3/2.4 series kernels.
+Version: 3.1.17 (2921)
+This version is for 2.4 series kernels.
 
+Changes since 3.1.16 (2716)
+   - changes for new scsi subsystem initialization
+   - change Scsi_Cmnd usage to Scsi_Request
+   - cleanup for no procfs
 Changes since 3.1.15 (2528)
- further (scatter gather) buffer length changes
 Changes since 3.1.14 (2503)
--- linux/drivers/scsi/sg.c Wed Sep 20 22:06:26 2000
+++ linux/drivers/scsi/sg.c3117 Thu Sep 21 20:13:12 2000
@@ -17,8 +17,11 @@
  * any later version.
  *
  */
- static char * sg_version_str = "Version: 3.1.16 (2716)";
- static int sg_version_num = 30116; /* 2 digits for each component */
+#include 
+#ifdef CONFIG_PROC_FS
+ static char * sg_version_str = "Version: 3.1.17 (2921)";
+#endif
+ static int sg_version_num = 30117; /* 2 digits for each component */
 /*
  *  D. P. Gilbert ([EMAIL PROTECTED], [EMAIL PROTECTED]), notes:
  *  - scsi logging is available via SCSI_LOG_TIMEOUT macros. First
@@ -38,7 +41,6 @@
  *  # cat /proc/scsi/sg/debug
  *
  */
-#include 
 #include 
 
 #include 
@@ -235,10 +237,12 @@
 static int sg_ms_to_jif(unsigned int msecs);
 static unsigned sg_jif_to_ms(int jifs);
 static int sg_allow_access(unsigned char opcode, char dev_type);
-static int sg_last_dev(void);
 static int sg_build_dir(Sg_request * srp, Sg_fd * sfp, int dxfer_len);
 static void sg_unmap_and(Sg_scatter_hold * schp, int free_also);
 static Sg_device * sg_get_dev(int dev);
+#ifdef CONFIG_PROC_FS
+static int sg_last_dev(void);
+#endif
 
 static Sg_device ** sg_dev_arr = NULL;
 
@@ -1298,18 +1302,20 @@
 }
 
 #ifdef MODULE
-
 MODULE_PARM(def_reserved_size, "i");
 MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif /* MODULE */
 
-int init_module(void) {
+static int __init init_sg(void) {
+#ifdef MODULE
 if (def_reserved_size >= 0)
sg_big_buff = def_reserved_size;
+#endif /* MODULE */
 sg_template.module = THIS_MODULE;
 return scsi_register_module(MODULE_SCSI_DEV, _template);
 }
 
-void cleanup_module( void)
+static void __exit exit_sg( void)
 {
 #ifdef CONFIG_PROC_FS
 sg_proc_cleanup();
@@ -1324,7 +1330,6 @@
 }
 sg_template.dev_max = 0;
 }
-#endif /* MODULE */
 
 
 #if 0
@@ -1972,6 +1977,7 @@
 return resp;
 }
 
+#ifdef CONFIG_PROC_FS
 static Sg_request * sg_get_nth_request(Sg_fd * sfp, int nth)
 {
 Sg_request * resp;
@@ -1985,6 +1991,7 @@
 read_unlock_irqrestore(>rq_list_lock, iflags);
 return resp;
 }
+#endif
 
 /* always adds to end of list */
 static Sg_request * sg_add_request(Sg_fd * sfp)
@@ -2064,6 +2071,7 @@
 return res;
 }
 
+#ifdef CONFIG_PROC_FS
 static Sg_fd * sg_get_nth_sfp(Sg_device * sdp, int nth)
 {
 Sg_fd * resp;
@@ -2077,6 +2085,7 @@
 read_unlock_irqrestore(_dev_arr_lock, iflags);
 return resp;
 }
+#endif
 
 static Sg_fd * sg_add_sfp(Sg_device * sdp, int dev)
 {
@@ -2410,6 +2419,7 @@
 }
 
 
+#ifdef CONFIG_PROC_FS
 static int sg_last_dev()
 {
 int k;
@@ -2421,6 +2431,7 @@
 read_unlock_irqrestore(_dev_arr_lock, iflags);
 return k + 1;   /* origin 1 */
 }
+#endif
 
 static Sg_device * sg_get_dev(int dev)
 {
@@ -2782,3 +2793,7 @@
 return 1;
 }
 #endif  /* CONFIG_PROC_FS */
+
+
+module_init(init_sg);
+module_exit(exit_sg);

Re: Oops with K6-2 350, but not with other CPUs.

[Daniel Grimwood]

Thanks to those who responded.  I tried a K6-2 500 and it worked fine, so
my chip looks like it's buggy or has mysteriously died.  Will contact AMD
to see if they can replace it, don't like my chances seeing it's 18 months
old, never know though.

Thanks again,
Daniel. :)


On Tue, 19 Sep 2000, Daniel Grimwood wrote:
>   am having many random fatal oopses with my K6-2 350.  .

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

issuing SIDT _crashes_ the system?!

[Julien Oster]

Hello,

I tried getting the interrupt descriptor table register (IDTR) using
sidt but... the system crashed? it first told me about a null pointer
dereference (sorry, haven't got the oops any more) and then all processes
died away. on the console i repeatedly got the message "no vm86 information:
BAD"

What's up there? It's probably my mistake due to bad code, but I still
don't understand and I can't find a bug in the module (sorry, it's late :) ).

I passed SIDT a pointer to a structure which contains the 2 byte limit and
the 4 byte base. To ensure that it is actually modified, I put in the two
values 0xDEAD and 0xBABEFACE.

After issuing SIDT, limit and base were 0. It's clear that that isn't the
correct value for the IDTR...

here's my getidt function (NASM):

BITS 32

GLOBAL getidt

getidt: push ebp
mov ebp, esp
sidt [ebp - 4]
pop ebp
ret

and here's the C part of the module:

#define MODULE
#define __KERNEL__

#include 
#include 

struct idtr {
unsigned short limit;
unsigned char * base;
};

extern void getidt (struct idtr *);

int init_module (void) {
struct idtr aidtr = {
0xDEAD,
(void*)0xBABEFACE
};

printk ("1 limit: %hu, base: %p\n", aidtr.limit, aidtr.base);
getidt ();
printk ("2 limit: %hu, base: %p\n", aidtr.limit, aidtr.base);

return -1;
}

void cleanup_module (void) {
return;
}

any ideas?

Julien



-
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: [PATCH] Remove unneeded symbols from System.map

[Keith Owens]

On Thu, 21 Sep 2000 19:49:59 -0400, 
Brian Gerst <[EMAIL PROTECTED]> wrote:
>Currently, System.map contains a significant number of automatically
>generated symbols.  These symbols are unnecessary for debugging since
>they represent individual elements of the exported symbol and PCI device
>tables, yet represent about 60% of the symbols in System.map.  This
>patch adds a filter to remove these symbols.

Please do not apply.  The size of System.map is almost irrelevant.
Having the __kstrtab_ and __ksymtab_ symbols in the map helps when
debugging EXPORT_SYMBOL problems.  I expect that other people find the
__device entries to be useful.

-
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: [patch *] VM deadlock fix

[David S. Miller]

   Date: Fri, 22 Sep 2000 02:18:05 +0200
   From: Andrea Arcangeli <[EMAIL PROTECTED]>

   As far as sleep_time is ok to be set to zero its missing
   initialization is right.

Indeed.

Later,
David S. Miller
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] 2.4 version of my duplicate IP and MAC detection patch

[Marc MERLIN]

On Fri, Sep 22, 2000 at 01:31:06AM +0200, Andi Kleen wrote:
> You added a linear IP search to fast path ARP processing. The people running 
> thousands of IP aliases will surely love you. You could at least use the
> ip_route_input output instead that arp_rcv computes anyways and check
> for RTN_LOCAL. 
 
While you actually  don't get broadcast ARP request very  often (more than a
few per minute is rare), even on a busy net, making it faster doesn't hurt.
I'll write a new patch, thanks.
 
> BTW, the idea  of doing it in user  space is not to have  a daemon running
> but just to do DAD once when you configure the ip address, like most other
> OSes do  [as easily done  with arping and a  small script, see  ipcfg from
> iproute2].
 
I know  about this. It  only helps you  not to steal  someone else's  IP, it
doesn't help when someone else just stole your IP.
Take a Solaris box, an IRIX one, or  windows (these are the only ones I have
access to for testing) and they'll all  complain and notice if I steal their
IP.
I find it  useful that a server  syslogs the fact that its  IP was stolen. I
can use that info  to bring up a temporary DHCP IP, and  send a message to a
central  network  monitor which  will  trace  the  culprit MAC  address  and
optionally turn off the switched port it came from.
 
Marc
-- 
Microsoft is to software what McDonalds is to gourmet cooking
 
Home page: http://marc.merlins.org/ (friendly to non IE browsers)
Finger [EMAIL PROTECTED] for PGP key and other contact information
-
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/

Graphics Drivers for Intel 82815 Graphics Controller

[Craig Whitmore]

Does anyone know what Video Drivers will allow X to 
work with an Intel Graphics Controller 
(82815 Graphics Controller)
(on a Intel D815EEA) Motherboard? The VesaFB does 
not work properly with it properly.
 
 
00:02.0 VGA compatible controller: Intel 
Corporation: Unknown device 1132 (rev 02) (prog-if 00 [VGA]) Subsystem: 
Intel Corporation: Unknown device 4541 Control: I/O+ Mem+ BusMaster+ 
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: 
Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-  Latency: 0 set Interrupt: pin 
A routed to IRQ 11 Region 0: Memory at f800 (32-bit, prefetchable) 
[size=64M] Region 1: Memory at ffa8 (32-bit, non-prefetchable) 
[size=512K] Capabilities: [dc] Power Management version 
2  Flags: PMEClk- AuxPwr- DSI+ D1- D2- PME-  Status: 
D0 PME-Enable- DSel=0 DScale=0 PME-
 
Thanks
Craig Whitmore
 
 
 
 

Re: [patch *] VM deadlock fix

[Andrea Arcangeli]

On Thu, Sep 21, 2000 at 03:23:17PM -0700, David S. Miller wrote:
> 
> How did you get away with adding a new member to task_struct yet not
> updating the INIT_TASK() macro appropriately? :-)  Does it really
> compile?

As far as sleep_time is ok to be set to zero its missing initialization is
right.

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: linux-kernel-digest ?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Matti Aarnio <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Thu, Sep 21, 2000 at 07:38:15AM -0500, Joshua Jore wrote:
> > Huh?  *is* supposed to be equivalent to  according to RFC822. 
> 
>   *NOT* for Procmail's REGULAR EXPRESSIONS.
> 
>   They are, after all, just regular UNIX REs without special
>   knowledge about e.g. EMAIL.
> 

Actually, procmail does canonicalize the header somewhat.  This is one
of the things that it really should have canonicalized.

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

2.4.0test8 masquerading code problems : turning into a trafic generator

[Pierre Brua]

Hi,

There seem to be something weird in 2.4 compared to 2.2.
The masquerading in 2.4 can apparently transform a router into an
automatic trafic generator in some cases.

Here is the logical network configuration I have, a simple masqueraded
network :
IFE
I (bepc.paralline.i) : internal computer using masquerading (standard
linux 2.2.16)
F (external IP : maxwell.paralline.com, internal IP 192.168.2.1) :
firewall doing the masquerading (2.4.0test8, PII/350 128MB, uptime 30
days)
E : external network (cable modem)

For switching from 2.2 to 2.4, I compiled the ipchains module and used
the emulation method.
Here are the firewall masquerading rules this problem appeared with :
ipchains -P forward DENY
ipchains -A forward -s 192.168.2.0/24 -j MASQ
Exactly the same that what I used for 2.2 kernels...

And here is a crazy log from tcpdump executed on the external interface
of the firewall :
20:42:55.594209 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)
20:42:55.594877 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack
1 win 8760  (DF)
20:42:55.595405 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)
20:42:55.595879 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack
1 win 8760  (DF)
20:42:55.596212 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)
20:42:55.596729 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack
1 win 8760  (DF)
20:42:55.597403 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)
20:42:55.604912 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack
1 win 8760  (DF)
20:42:55.605259 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)
20:42:55.605495 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack
1 win 8760  (DF)
20:42:55.605806 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)
20:42:55.606113 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack
1 win 8760  (DF)
20:42:55.606654 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)
20:42:55.612966 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack
1 win 8760  (DF)
20:42:55.613309 maxwell.paralline.com.61642 > www.geologie.ens.fr.http:
. ack 1 win 31856  (DF)

Stopping the http browser didn't help.
If I disconnect the external network ethernet cable during a few seconds
and reconnect it, it stops generating trafic.
This problem happens with various web servers being browsed (i.e. :
different OS stacks). It did not appear before the 2.4 switch with the
same internal computer and kernel.

I checked the list archives and found nothing related to that kind of
problems. I don't know this area of the kernel enough to track down the
bug, but I will give all the help I can.
I can add test code to the firewall, patch/recompile a kernel and
provide new logs if needed.

Hope it helps,

Pierre BRUA
-- 
  PARALLINE  ///Parallelism & Linux
///
71,av. des Vosges Phone:+33 388 141 740 mailto:[EMAIL PROTECTED]
F-67000 STRASBOURG  Fax:+33 388 141 741  http://www.paralline.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: lvm in 2.4.0-test9pre5

[Andrea Arcangeli]

On Thu, Sep 21, 2000 at 06:38:39PM -0500, Peter Samuelson wrote:
> Right.  Functionally they overlap (lvm can do the equivalent of md
> linear) but structurally, the md drivers all operate under the md

lvm can do linear and raid0 (striping in two or more disks), and it supports
live snapshotting of the logical volume (but it's a not a persistent snapshot
at the moment so you lose its data when you reboot). It's still useful for
backups of a raw logical volume though. Checkpoint and block, snapshot, unblock
and then backup from the snapshot and then drop the snapshot when the backup
completes.

> Since it's just two source files I would leave it in drivers/block/.

Yep, that looks ok to me.

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/

[PATCH] Remove unneeded symbols from System.map

[Brian Gerst]

Currently, System.map contains a significant number of automatically
generated symbols.  These symbols are unnecessary for debugging since
they represent individual elements of the exported symbol and PCI device
tables, yet represent about 60% of the symbols in System.map.  This
patch adds a filter to remove these symbols.  In doing so, I split out
the filter patterns to a seperate file, avoiding more clutter in the
Makefile.

-rw-rw-r--   1 bgerst   bgerst 425382 Sep 20 13:30 System.map
-rw-rw-r--   1 bgerst   bgerst 196986 Sep 20 13:31 System.map

-- 

Brian Gerst

diff -urN linux-2.4.0t9p4/Makefile linux/Makefile
--- linux-2.4.0t9p4/MakefileTue Sep 19 09:48:26 2000
+++ linux/Makefile  Wed Sep 20 12:28:56 2000
@@ -208,7 +208,7 @@
$(LIBS) \
--end-group \
-o vmlinux
-   $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aU] 
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
+   $(NM) vmlinux | grep -v -f scripts/System.map-filter | sort > System.map
 
 symlinks:
rm -f include/asm
diff -urN linux-2.4.0t9p4/scripts/System.map-filter linux/scripts/System.map-filter
--- linux-2.4.0t9p4/scripts/System.map-filter   Wed Dec 31 19:00:00 1969
+++ linux/scripts/System.map-filter Wed Sep 20 11:47:50 2000
@@ -0,0 +1,10 @@
+compiled
+\.o$
+ [aU] 
+\.\.ng$
+LASH[RL]DI
+__kstrtab_
+__ksymtab_
+__vendorstr_
+__devicestr_
+__devices_

Re: [PATCH] Re: SCSI scanning

[Michael Elizabeth Chastain]

Eric Youngdale writes:

> .initcall.init : { *(.initcall.init1) }
> .initcall.init : { *(.initcall.init2) }
> .initcall.init : { *(.initcall.init) }

I like this idea.

I would add initcall.init8 and initcall.init9 in order to have some
levels after the normal initcalls.

> It isn't as ugly as jumping through millions of hoops to get the Makefiles
> to do it right.

It's about three lines in Rules.make to do link ordering in each
directory.

But the situation in scsi right now requires cross-directory ordering
and that is going to be some ugly hoop-jumping if done in Makefiles.

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

Problem remains - page_launder? (Was: Re: [patch *] VM deadlock fix)

[Roger Larsson]

Hi again,

Further hints.

More testing (printks in refill_inactive and page_launder)
reveals that refill_inactive works ok (16 pages) but 
page_launder never succeeds in my lockup state... (WHY)
alloc fails since there is no inactive_clean and free is
less than MIN. And then when page_launder fails...

/RogerL


Roger Larsson wrote:
> 
> Hi,
> 
> Tried your patch on 2.2.4-test9-pre4
> with the included debug patch applied.
> 
> Rebooted, started mmap002
> 
> After a while it starts outputting (magic did not work
> this time - usually does):
> 
> - - -
> "VM: try_to_free_pages (result: 1) try_again # 12345"
> "VM: try_to_free_pages (result: 1) try_again # 12346"
> - - -
> 
> My interpretation:
> 1) try_to_free_pages succeeds (or returns ok when it did not work)
> 2) __alloc_pages still can't alloc
> 
> Maybe it is different limits,
>   try_to_free_pages requires less to succeed than
>   __alloc_pages_limit requires.
> or a bug in
>   __alloc_pages_limit(zonelist, order, PAGES_MIN, direct_reclaim)
> 
> Note:
>   12345  is an example, it loops to over 3...
> 
> /RogerL
> 
> Rik van Riel wrote:
> >
> > Hi,
> >
> > I've found and fixed the deadlocks in the new VM. They turned out
> > to be single-cpu only bugs, which explains why they didn't crash my
> > SMP tesnt box ;)
> >
> > They have to do with the fact that processes schedule away while
> > holding IO locks after waking up kswapd. At that point kswapd
> > spends its time spinning on the IO locks and single-cpu systems
> > will die...
> >
> > Due to bad connectivity I'm not attaching this patch but have only
> > put it online on my home page:
> >
> > http://www.surriel.com/patches/2.4.0-t9p2-vmpatch
> >
> > (yes, I'm at a conference now ... the worst beating this patch
> > has had is a full night in 'make bzImage' with mem=8m)
> >
> > regards,
> >
> > Rik
> > --
> > "What you're running that piece of shit Gnome?!?!"
> >-- Miguel de Icaza, UKUUG 2000
> >
> > http://www.conectiva.com/   http://www.surriel.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/
> 
> --
> Home page:
>   http://www.norran.net/nra02596/
> 
>   
> Name: vmdebug.patch
>vmdebug.patchType: Plain Text (text/plain)
> Encoding: 7bit

--
Home page:
  http://www.norran.net/nra02596/
-
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: lvm in 2.4.0-test9pre5

[Peter Samuelson]

[Andrea]
> LVM and MD have nothing common. They're two completly orthogonal
> piece of code

Right.  Functionally they overlap (lvm can do the equivalent of md
linear) but structurally, the md drivers all operate under the md
framework and user-toolset while lvm has its own framework and toolset.

> LVM should live in drivers/lvm not drivers/md.

Since it's just two source files I would leave it in drivers/block/.
If someone starts merging in e.g. IBM lvm components it could make
sense to move it.

Peter
-
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: [patch] 2.4 version of my duplicate IP and MAC detection patch

[Andi Kleen]

On Thu, Sep 21, 2000 at 04:09:41PM -0700, Marc MERLIN wrote:
> I updated my duplicate IP detection patch to work with 2.4.
> 
> I announced  the 2.2 version  here last  year, and several  people expressed
> interest in it, but it never  made it into the kernel unfortunately. I asked
> a few times and  eventually gave up as I didn't want  to appear overly pushy
> and it got included in the kernels that I use (kernels from VA).
> 
> I didn't receive  any negative comments, except for Alexey  who believed the
> check should be done in user space.

You added a linear IP search to fast path ARP processing. The people running 
thousands of IP aliases will surely love you. You could at least use the
ip_route_input output instead that arp_rcv computes anyways and check
for RTN_LOCAL. 

BTW, the idea of doing it in user space is not to have a daemon running
but just to do DAD once when you configure the ip address, like most
other OSes do [as easily done with arping and a small script, see ipcfg
from iproute2]. 

Overall it looks like bloat.

-Andi
-
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] 2.4 version of my duplicate IP and MAC detection patch

[Marc MERLIN]

I updated my duplicate IP detection patch to work with 2.4.

I announced  the 2.2 version  here last  year, and several  people expr=
essed
interest in it, but it never  made it into the kernel unfortunately. I =
asked
a few times and  eventually gave up as I didn't want  to appear overly =
pushy
and it got included in the kernels that I use (kernels from VA).

I didn't receive  any negative comments, except for Alexey  who believe=
d the
check should be done in user space.

The patches (2.2/2.4) and discussion can be found here:
http://marc.merlins.org/linux/arppatch/

Here are two excerpts:
---=
-
What does the patch do?
It looks at all the broadcast ARP  requests and checks that the source =
IP of
the request is different from the  interface's IP. This will catch a ma=
chine
that is using your IP and is trying to talk to a machine on your net fo=
r the
first time or the first time in a while.
The big plus of this approach is that it's passive=20

It will get your system to output this:=20
Uh Oh, MAC address 00:A0:C9:EE:9C:8A claims to have our IP addresses
(192.168.205.9) (duplicate IP conflict likely)
or this:=20
Uh Oh, I received an ARP packet claiming to be from our MAC address
00:80:C8:47:37:72, but with an IP I don't own (192.168.205.1). Someone =
has
apparently stolen our MAC address
---=
-

---=
-
But then why not write the whole thing in user space?

Well, the line has  to be drawn somewhere... The whole IP  stack could =
be in
user space  if we  wanted... In this  case, the actual  added code  (I'=
m not
talking about the existing code which I  turned into a function) is abo=
ut 20
lines, it's trivial and it uses much  less resources on a slow machine =
(386)
than a  user space solution which  forces a context switches,  system c=
alls,
and memory for that user process.
Also, not  that others are always  right, but do  you know any OS  that=
 does
duplicate IP checking by inspecting ARP requests in user space?
---=
-

I'm attaching the 2.4  version which I'd really like to  see included i=
n the
main tree. While I don't see a good reason to disable this, if what it =
takes
is a  config option, experimental  or not, disabled  by default or  not=
 (I'd
rather  have it  non experimental  since  it's a  year old,  and enable=
d  by
default, but I'll settle), I'll do what it takes.

I'm attaching the 2.4  version and you can find the 2.2  version, as we=
ll as
more info on my page:
http://marc.merlins.org/linux/arppatch/

Thanks,
Marc

diff -urN linux-2.2.4-test5/net/ipv4/arp.c linux-2.2.4-test5-detectarpd=
upe/net/ipv4/arp.c
--- linux-2.2.4-test5/net/ipv4/arp.cFri Jul 21 21:54:29 2000
+++ linux-2.2.4-test5-detectarpdupe/net/ipv4/arp.c  Sun Sep 17 19:19:49 =
2000
@@ -65,6 +65,8 @@
  * clean up the APFDDI & gen. FDDI bits.
  * Alexey Kuznetsov:   new arp state machine;
  * now it is in net/core/neighbour.c.
+ * Marc Merlin :   Added duplicate IP and MAC address
+ * detection (2000/09/17)
  */
=20
 /* RFC1122 Status:
@@ -121,6 +123,8 @@
=20
 #include 
 #include 
+=20
+#undef IDONTRECEIVEMYOWNPACKETSBACK=20
=20
 #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
 static char *ax2asc2(ax25_address *a, char *buf);
@@ -135,6 +139,7 @@
 static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb);
 static void arp_error_report(struct neighbour *neigh, struct sk_buff *=
skb);
 static void parp_redo(struct sk_buff *skb);
+static char *mac2asc(unsigned char *sha, unsigned char addr_len);
=20
 static struct neigh_ops arp_generic_ops =3D
 {
@@ -716,6 +721,55 @@
goto out;
}
=20
+   if (!memcmp(sha,dev->dev_addr,dev->addr_len))
+   {
+   char ourip=3D0;
+   struct in_device *idev=3Ddev->ip_ptr;
+   struct in_ifaddr *adlist=3Didev->ifa_list;
+   =09
+   while (adlist !=3D NULL)
+   {
+   if (adlist->ifa_address =3D=3D sip) {
+   =09
+   ourip=3D1;
+   break;
+   }
+   adlist=3Dadlist->ifa_next;
+   }
+   =09
+   if (net_ratelimit()) {
+   if (ourip) {
+#ifdef IDONTRECEIVEMYOWNPACKETSBACK
+/* This is an attempt at detecting that someone stole your MAC and you=
r IP, but
+ * in some network configurations and with some switches, you will get=
 your
+ * own packets back, so this warning would be triggered by error for t=
oo many
+ * people.
+ * It's disabled by default but I have left it there in case it's usef=
ul to=20
+ * 

Re: [DOC] Debugging early kernel hangs

[Keith Owens]

On Thu, 21 Sep 2000 18:54:33 -0400 (EDT), 
Byron Stanoszek <[EMAIL PROTECTED]> wrote:
>On Fri, 22 Sep 2000, Keith Owens wrote:
>> The idea is to write characters direct to the video screen during
>> booting using a macro called VIDEO_CHAR.
>
>Why not just redirect printk() to output a string of characters one by one
>using VIDEO_CHAR until the console subsystem is initialized. You can use a
>statically defined int to keep track of what row & column you're on. There is
>no need to be so cryptic about the readout.

Overhead and difficulty to use from assembler.  VIDEO_CHAR() generates
a single mov instruction, calling printk and looping to do output does
a lot more code. You can do the equivalent of VIDEO_CHAR direct from
assembler without disturbing any registers, to call printk means saving
registers around the call and constructing text strings in the
assembler code.

And besides, debugging should be difficult, damn it.
-
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-kernel-digest ?

[Matti Aarnio]

On Thu, Sep 21, 2000 at 11:27:01PM +0100, Alan Cox wrote:
> >From: Alan Cox <[EMAIL PROTECTED]>
> > 
> >Having slowly switched every list I have to run or help run to
> >mailman I can recommend the pain of the switch over the pain of
> >running majordomo
> > 
> > I suggested this but Matti immediately told me that mailman has
> > several RFC compliancy "issues" which I am sure he can elaborate on.
> 
> I'd like to hear more. I think mailman is worth fixing even if so - the fact
> folks who change email address dont have to send you hate mail being one
> major reason 8)

  A year or two ago I had a peek after I got reports that it
  didn't work together with ZMailer -- turned out that some
  baseline PYTHON library for SMTP does something stupid in
  its protocol line construction..  The system experiencing
  problems was running ZMailer with ultra-strict RFC 821
  (plus amendaments) mode.

  Ergo, the MAILMAN might be ok, but underneath it there may
  be buggy language library..  (may STILL be, that is.)

  Another point, DaveM, was that MAILMAN is written in Python,
  and neither of us "speaks" that language...


> BTW tell Matti that zmailer is positively vicious - when I put my mail server
> back online on the cable modem after 3 days offline vger streamed mail at it
> at a steady 512Kbits/second and nearly killed it

  Oh dear me.  It is feeding those one message at a time with least
  possible resource usage...  Perhaps it can be made less "vicious"
  with e.g. sprinkling sleep(1) calls all over the code, but I would
  rather not do such a gross thing..

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

[PATCH] RAID autorun fix (fwd)

[Matthew Kirkwood]

Tsk, forgot the cc.


-- Forwarded message --
Date: Thu, 21 Sep 2000 23:59:09 +0100 (BST)
From: Matthew Kirkwood <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Subject: [PATCH] RAID autorun fix

Hi,

The attached diff makes RAID autorun work for me.

It transpired that the failed initialisation was not
an init order thing, but more related to that fact
that md.c wasn't using the new init scheme at all.

I'm not 100% sure that the last bit (which affects
initrds which I don't use) is correct, so you may
want to leave that as-is.

Cheers,
Matthew.

diff -ruN linux-2.4.0-test9pre5/drivers/block/ll_rw_blk.c 
linux/drivers/block/ll_rw_blk.c
--- linux-2.4.0-test9pre5/drivers/block/ll_rw_blk.c Thu Sep 21 23:47:12 2000
+++ linux/drivers/block/ll_rw_blk.c Thu Sep 21 22:00:31 2000
@@ -1130,9 +1130,6 @@
 #ifdef CONFIG_SJCD
sjcd_init();
 #endif CONFIG_SJCD
-#ifdef CONFIG_BLK_DEV_MD
-   md_init();
-#endif CONFIG_BLK_DEV_MD
 #ifdef CONFIG_APBLOCK
ap_init();
 #endif
diff -ruN linux-2.4.0-test9pre5/drivers/md/md.c linux/drivers/md/md.c
--- linux-2.4.0-test9pre5/drivers/md/md.c   Thu Sep 21 23:47:12 2000
+++ linux/drivers/md/md.c   Thu Sep 21 22:44:25 2000
@@ -34,6 +34,8 @@
 #include 
 #include 
 
+#include 
+
 #ifdef CONFIG_KMOD
 #include 
 #endif
@@ -3844,6 +3846,11 @@
free_device_names();
 
 }
+#endif
+
+__initcall(md_init);
+#ifdef CONFIG_AUTODETECT_RAID
+__initcall(md_run_setup);
 #endif
 
 MD_EXPORT_SYMBOL(md_size);
diff -ruN linux-2.4.0-test9pre5/fs/partitions/check.c linux/fs/partitions/check.c
--- linux-2.4.0-test9pre5/fs/partitions/check.c Sun Sep 10 12:36:06 2000
+++ linux/fs/partitions/check.c Thu Sep 21 22:42:22 2000
@@ -439,9 +439,6 @@
 #endif
rd_load();
 #endif
-#ifdef CONFIG_BLK_DEV_MD
-   md_run_setup();
-#endif
return 0;
 }
 
diff -ruN linux-2.4.0-test9pre5/init/main.c linux/init/main.c
--- linux-2.4.0-test9pre5/init/main.c   Sun Sep 10 12:36:06 2000
+++ linux/init/main.c   Thu Sep 21 22:42:02 2000
@@ -727,9 +727,6 @@
while (pid != wait());
if (MAJOR(real_root_dev) != RAMDISK_MAJOR
 || MINOR(real_root_dev) != 0) {
-#ifdef CONFIG_BLK_DEV_MD
-   md_run_setup();
-#endif
error = change_root(real_root_dev,"/initrd");
if (error)
printk(KERN_ERR "Change root to /initrd: "


-
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: [DOC] Debugging early kernel hangs

[Byron Stanoszek]

On Fri, 22 Sep 2000, Keith Owens wrote:

> If a kernel hangs early in the boot process (before the console has
> been initialized) then printk is no use because you never see the
> output.  There is a technique for using the video display to indicate
> boot progress so you can localize the problem.  Reporting "my kernel
> hangs during boot at line nnn in routine xyz" is a lot better than "my
> kernel hangs during boot".
> 
> The idea is to write characters direct to the video screen during
> booting using a macro called VIDEO_CHAR.  This macro takes a character
> position and a single character value to be displayed.  Use different
> positions on the screen for different levels of code and use different
> characters in one position to indicate which stage that level is up to.
> For example, with the patch below, the string EAC at hang indicates
> parse_options(), checksetup().

Why not just redirect printk() to output a string of characters one by one
using VIDEO_CHAR until the console subsystem is initialized. You can use a
statically defined int to keep track of what row & column you're on. There is
no need to be so cryptic about the readout.

Regards,
 Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [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: /dev/f1

[Michael Elizabeth Chastain]

Hi Daniel,

> tar -cvf /dev/f1 .

Take a look at the line before it:

tar:
tar -cvf /dev/f1 .

This goal has been in the net/*/Makefile files a very long time.  I see
it in linux-0.99.1.tar!

My guess is that the original author/user of this little goal liked to
back up their work to floppy disk every so often (think about it, they
didn't have mature networking in place, so a floppy backup makes a lot
of sense).  I'll also guess that the original author/user is no longer
backing up onto floppies, and no one would mind if someone removed this
historic relic.

But it's not a 2.4 critical bug so no action for a while.

Michael
-
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: Using floating point in the kernel

[Richard B. Johnson]

On Thu, 21 Sep 2000, Alan Cox wrote:

> > > > It is sufficient when you do tsk->flags |= PF_USEDFPU first.
> > > 
> > > Unless you sleep
> > 
> > Unless I'm missing something the lazy FPU state save in the 2.4 switch_to will
> > do the right thing at least on x86. Your kernel FPU state will overwrite the 
> > user FPU state in current, but that's ok because it is undefined anyways 
> > (and you restore the correct state when you wake up again) 
> 
> 2.4 maybe. Im not totally sure on that code. 2.2 wont
> 

If you fire off about 20 copies of this, then execute the X-SERVER,
they will eventually all fail. Takes about 20 minutes on my machine.
I tried to update, but they don't support my screen-card anymore. This
was, I think, their first attempt at MMX stuff.

This is an old X-Server:

XFree86 Version 3.3.3.1 / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: December 29 1998
If the server is older than 6-12 months, or if your card is newer
than the above date, look for a newer version before reporting
problems.  (see http://www.XFree86.Org/FAQ)


Here's the test code:


#include 
#include 
#include 
#include 

#define ARRAY_LEN 0x1

int main()
{
   double *d0, *d1;
   size_t i;
   if((d0 = malloc(ARRAY_LEN *sizeof(double))) == NULL)
   {
fprintf(stderr, "Memory allocation error\n");
exit(EXIT_FAILURE);
   }
   if((d1 = malloc(ARRAY_LEN *sizeof(double))) == NULL)
   {
fprintf(stderr, "Memory allocation error\n");
exit(EXIT_FAILURE);
   }
   for(;;)
   {
   for(i=0; i< ARRAY_LEN; i++)
  d0[i] = cos((double) (i % 60));
   for(i=0; i< ARRAY_LEN; i++)
  d1[i] = cos((double) (i % 60));
   if(memcmp((char*)d0, (char *)d1, ARRAY_LEN * sizeof(double)))
   {
for(i=0; i< ARRAY_LEN; i++)
if(d0[i] != d1[i]) break;
fprintf(stderr, "Floating point error at offset %u ", i);
fprintf(stderr, "d0[%u]=%f, d1[%u]=%f\n", i, d0[i], i, d1[i]);
exit(EXIT_FAILURE);
   }
   }
}

Somebody who has RAID or whatever with MMX may want to try this.



Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

ARP entry in /proc wrong?

[his dad]

Linux 2.4.0-test6 i386

I've just put a manual arp entry in for 192.168.56.1.

arp -n does not show it.

/proc/arp

has the following line


192.168.56.10x10xc 


where the ipaddress and the HWtype are jammed against each other.

dare i suggest this might be a bug?

Regards

hisdad

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

[DOC] Debugging early kernel hangs

[Keith Owens]

If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output.  There is a technique for using the video display to indicate
boot progress so you can localize the problem.  Reporting "my kernel
hangs during boot at line nnn in routine xyz" is a lot better than "my
kernel hangs during boot".

The idea is to write characters direct to the video screen during
booting using a macro called VIDEO_CHAR.  This macro takes a character
position and a single character value to be displayed.  Use different
positions on the screen for different levels of code and use different
characters in one position to indicate which stage that level is up to.
For example, with the patch below, the string EAC at hang indicates
parse_options(), checksetup().

The patch below is generic, except for the definition of VIDEO_CHAR
which is ix86 specific.  If this patch ever becomes part of the main
kernel then VIDEO_CHAR needs to be moved to an arch specific header.
If any arch other than ix86 uses this technique, please mail
[EMAIL PROTECTED] with your definition of VIDEO_CHAR.

You can plant VIDEO_CHAR calls anywhere you like, up to the call to
mem_init().  After mem_init has done its work and memory has been
remapped, VIDEO_CHAR cannot write to video memory, it will oops.
However by then the console has been initialized so you can use printk.

Demonstration patch against 2.4.0-test9-pre5.  This only uses screen
positions 0, 1, 2.  If you want to drill down into lower level
routines, just use screen positions 3 onwards.

Index: 0-test9-pre5.1/init/main.c
--- 0-test9-pre5.1/init/main.c Sun, 03 Sep 2000 20:40:52 +1100 kaos 
(linux-2.4/j/46_main.c 1.1.2.2.1.1.2.5.1.2.1.1 644)
+++ 0-test9-pre5.1(w)/init/main.c Fri, 22 Sep 2000 09:32:20 +1100 kaos 
+(linux-2.4/j/46_main.c 1.1.2.2.1.1.1.2.1.5.1.1 644)
@@ -77,6 +77,13 @@ extern void nubus_init(void);
 #error sorry, your GCC is too old. It builds incorrect kernels.
 #endif
 
+#ifdef DEBUG_VIDEO_CHAR
+/* ix86 specific */
+#define VIDEO_CHAR(c, v) (*((volatile char *)(0xb8000 + 2*(c))) = (v))
+#else
+#define VIDEO_CHAR(c, v)
+#endif
+
 extern char _stext, _etext;
 extern char *linux_banner;
 
@@ -415,12 +422,14 @@ static void __init parse_options(char *l
char *next,*quote;
int args, envs;
 
+   VIDEO_CHAR(1, 'A');
if (!*line)
return;
args = 0;
envs = 1;   /* TERM is set to 'linux' by default */
next = line;
while ((line = next) != NULL) {
+   VIDEO_CHAR(2, 'A');
 quote = strchr(line,'"');
 next = strchr(line, ' ');
 while (next != NULL && quote != NULL && quote < next) {
@@ -433,9 +442,11 @@ static void __init parse_options(char *l
 next = strchr(next+1, ' ');
 }
 }
+   VIDEO_CHAR(2, 'B');
 if (next != NULL)
 *next++ = 0;
if (!strncmp(line,"init=",5)) {
+   VIDEO_CHAR(3, 'A');
line += 5;
execute_command = line;
/* In case LILO is going to boot us with default command line,
@@ -446,8 +457,10 @@ static void __init parse_options(char *l
args = 0;
continue;
}
+   VIDEO_CHAR(2, 'C');
if (checksetup(line))
continue;
+   VIDEO_CHAR(2, 'D');

/*
 * Then check if it's an environment variable or
@@ -463,9 +476,12 @@ static void __init parse_options(char *l
if (*line)
argv_init[++args] = line;
}
+   VIDEO_CHAR(2, 'E');
}
+   VIDEO_CHAR(1, 'B');
argv_init[args+1] = NULL;
envp_init[envs+1] = NULL;
+   VIDEO_CHAR(1, 'C');
 }
 
 
@@ -509,16 +525,27 @@ asmlinkage void __init start_kernel(void
  * Interrupts are still disabled. Do necessary setups, then
  * enable them
  */
+   VIDEO_CHAR(0, 'A');
lock_kernel();
+   VIDEO_CHAR(0, 'B');
printk(linux_banner);
+   VIDEO_CHAR(0, 'C');
setup_arch(_line);
+   VIDEO_CHAR(0, 'D');
printk("Kernel command line: %s\n", saved_command_line);
+   VIDEO_CHAR(0, 'E');
parse_options(command_line);
+   VIDEO_CHAR(0, 'F');
trap_init();
+   VIDEO_CHAR(0, 'G');
init_IRQ();
+   VIDEO_CHAR(0, 'H');
sched_init();
+   VIDEO_CHAR(0, 'I');
time_init();
+   VIDEO_CHAR(0, 'J');
softirq_init();
+   VIDEO_CHAR(0, 'K');
 
/*
 * HACK ALERT! This is early. We're enabling the console before
@@ -526,8 +553,10 @@ asmlinkage void __init start_kernel(void
 * this. But we do want output early, in case something goes wrong.
   

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote:
> torben> core-hosts/i2o-upper.
> 
> Ok, I understand the problem.
> 
> Can you elaborate some more on exactly which files go in "core",
> "hosts", and "upper"?  My understanding is:
> 
> # drivers/scsi
> scsi-core-files  := scsi_mod.o scsi_syms.o
> scsi-hosts-files := ... everything not in core and upper ...
> scsi-upper-files := st.o sd_mod.o sr_mod.o sg.o
> 
> # i2o
> i2o-files:= %.o
>

Eaxctly. The core and upperlayers are ok now. You just need 
to get all hosts adapters into hosts.o. Everything is there
except those outside drivers/scsi. It would be great if
someone with an i2o adapter could verify any changes.
Please note I already sorted the hosts.o files in the drivers/scsi/Makefile. 

> I can do this in the top Makefile by declaring lists like the above
> using $(filter) and $(filter-out).  The hard part is going to be defining
> "scsi-hosts-files" to work properly.  I think I will need to add a few
> more lines to drivers/scsi/Makefile and make one more multi.  Or maybe
> three more multis.

Yeah I've been thinking of doing this, but was afraid to srew it up. Give
it a try, and lets see what Linus thinks. 

BTW, while you are at it, could you rename sg.o to sg_mod.o. It would
look better...

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
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: Given an image, how can show its config?

[Alan Cox]

> I would like to upgrade my kernel which is bundled with Red Hat. However,
> I don't want to lose modules/functions it has complied. How can I do
> it? Is there any command to check the current config and how can I check
> the modules it has as well?

The Red Hat bundled source rpm package contains the .config files, patches and
all pieces to build the kernels. 

This ought to go to a Red Hat list though.. 

-
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: [Oops] Unable to handle kernel NULL pointer dereference

[Igmar Palsenberg]

> >>EIP; c01527b9<= 
> Trace; c015357b  
> Trace; c01363d8  
> Trace; c012c1e7  
> Trace; c01371a9 <__user_walk+4d/58> 
> Trace; c012c23b  
> Trace; c011d630  
> Trace; c0108d83  
> Code;  c01527b9  
>  <_EIP>: 
> Code;  c01527b9<= 
>0:   f6 43 34 40   testb  $0x40,0x34(%ebx)   <= 
> Code;  c01527bd  
>4:   74 07 je d <_EIP+0xd> c01527c6 
>  
> Code;  c01527bf  
>6:   31 c0 xor%eax,%eax 
> Code;  c01527c1  
>8:   e9 f9 00 00 00jmp106 <_EIP+0x106> c01528bf 
>  
> Code;  c01527c6  
>d:   8b 53 48  mov0x48(%ebx),%edx 
> Code;  c01527c9  
>   10:   85 d2 test   %edx,%edx 
> Code;  c01527cb  
>   12:   74 43 je 57 <_EIP+0x57> c0152810 
>  

Smells like the famous quota bug. Didn't there get a patch posted a few
days ago ?



Igmar

-
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: [patch *] VM deadlock fix

[David S. Miller]

How did you get away with adding a new member to task_struct yet not
updating the INIT_TASK() macro appropriately? :-)  Does it really
compile?

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Strange virtual/physical address of global data

[Alan Cox]

> unsigned long test_data;
> 
> int init_module(void)
> {
> void *virt = _data;
> unsigned long phys = virt_to_phys(virt);
> 
> When I run this and check the valur of virt and phys, it appears that phys is
> outside the range of physical memory!  That is, if I have 512MB of RAM, then
> phys is equal to about 520M.  However, if I make test_data a local variable:

Module data isnt guaranteed to be in dmaable memory (nor btw is the stack but
you were lucky). If you want to use virt_to_bus() and friends for stuff like
DMA you must kmalloc the buffers

-
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: Using floating point in the kernel

[Alan Cox]

> Well the code does a fnsave. Somebody never looked at the damn book! it

Oh I did. And then I timed the performance for the copying cases

Alan

-
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: cPCI development

[Alan Cox]

> } On Wed, 20 Sep 2000, Adrian Cox wrote:
> } > cPCI is PCI + hotswap. Most people seem to ignore the hotswap, except at
> } > tradeshows.
> } 
> } ISPs certainly don't ignore hotswap. Unfortunately, Linux does. :) :(
> 
> PowerPC has hotswap for Motorola boards thanks to Johnnie Peters and Matt
> Porter.

I'd disagree on the ISP thing too btw. Telcos care a lot about hotswap PCI, but
ISP services you can take a down box with a failover of a machine - which in
general is a lot easier and overall better coverage

Alan


-
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: Using floating point in the kernel

[Andi Kleen]

On Thu, Sep 21, 2000 at 11:28:26PM +0100, Alan Cox wrote:
> > > > It is sufficient when you do tsk->flags |= PF_USEDFPU first.
> > > 
> > > Unless you sleep
> > 
> > Unless I'm missing something the lazy FPU state save in the 2.4 switch_to will
> > do the right thing at least on x86. Your kernel FPU state will overwrite the 
> > user FPU state in current, but that's ok because it is undefined anyways 
> > (and you restore the correct state when you wake up again) 
> 
> 2.4 maybe. Im not totally sure on that code. 2.2 wont

We were actually talking about a hypothetical fully interruptible 2.5 kernel.

-Andi

-
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: Using floating point in the kernel

[Alan Cox]

> > > It is sufficient when you do tsk->flags |= PF_USEDFPU first.
> > 
> > Unless you sleep
> 
> Unless I'm missing something the lazy FPU state save in the 2.4 switch_to will
> do the right thing at least on x86. Your kernel FPU state will overwrite the 
> user FPU state in current, but that's ok because it is undefined anyways 
> (and you restore the correct state when you wake up again) 

2.4 maybe. Im not totally sure on that code. 2.2 wont

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

[Steven Pritchard]

Alan Cox said:
> Having slowly switched every list I have to run or help run to mailman I can
> recommend the pain of the switch over the pain of running majordomo 

There is a Majordomo 2 in development.  I'm using it for all of my
lists now.  The upgrade from Majordomo 1 wasn't terribly painful.

Note that it's not really a new version, but rather a total rewrite.
MIME, archives, digests, and everything else you would expect to "just
work" does.  Of course, the catch is that there hasn't been an
official, stable release yet.

See

http://www.hpc.uh.edu/majordomo/#mj2

for more info.

Steve
-- 
[EMAIL PROTECTED]   | Linux Users of Central Illinois
(618)398-7320 | Meetings the 4th Tuesday of every month
Steven Pritchard  | http://www.luci.org/ for more info
-
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: Using floating point in the kernel

[Andi Kleen]

On Thu, Sep 21, 2000 at 11:08:36PM +0100, Alan Cox wrote:
> > On Thu, Sep 21, 2000 at 11:36:17AM +, John Alvord wrote:
> > > A 2.5-time problem is that portions of the kernel are planned to
> > > become interruptible... so saving and restoring around a certain usage
> > > would be insufficient.
> > 
> > It is sufficient when you do tsk->flags |= PF_USEDFPU first.
> 
> Unless you sleep

Unless I'm missing something the lazy FPU state save in the 2.4 switch_to will
do the right thing at least on x86. Your kernel FPU state will overwrite the 
user FPU state in current, but that's ok because it is undefined anyways 
(and you restore the correct state when you wake up again) 


-Andi

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

USB behavior screwy for uhci.o in test9-pre5

[Ari Pollak]

Sometime between test9-pre3 and test9-pre5, the alternative UHCI driver
(uhci.o) got screwed up - with my MS Natural Keyboard Pro in USB mode &
using the keybdev + hid + uhci driver, pressing one of caps/num/scroll
lock
turns the appropriate light on, but then when pressing the same
caps/num/scroll lock button again, the light stays on and I get the
following error message:

kernel: hid.c: usb_submit_urb(out) failed

Using the usb-uhci.o driver instead of uhci.o corrects the problem, but
I can't use usb-uhci.o properly on a regular basis because my ibm
usb webcam does not work properly with it.

-
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: strange BogoMIPS value

[Alan Cox]

> It seems as if linux 2.2.17 is calculating a strange value for my bogomips
> value.  I thought is was supposed to be somewhere near the processor
> speed.  Perhaps I am missing something?

bogo - see bogus ;)

Its just an internal magic number

-
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: [patch] mousedev.c

[Vojtech Pavlik]

On Fri, Sep 22, 2000 at 12:03:20AM +0900, Yoichi Imai wrote:

> I think it's a bug.

I think it's a feature.

> --- linux-2.4.0-test8/drivers/input/mousedev.c Wed Aug 23 01:06:31 2000
> +++ linux/drivers/input/mousedev.c  Thu Sep 21 22:20:22 2000
> @@ -121,12 +121,12 @@
> case BTN_TOUCH:
> case BTN_LEFT:   index = 0; break;
> case BTN_4:
> -   case BTN_EXTRA:  if (list->mode > 1) 
>{ index = 4; break; }
> +   case BTN_EXTRA:  if (list->mode > 1) 
>index = 4; break;
> case BTN_STYLUS:
> case BTN_1:
> case BTN_RIGHT:  index = 1; break;
> case BTN_3:
> -   case BTN_SIDE:   if (list->mode > 1) 
>{ index = 3; break; }
> +   case BTN_SIDE:   if (list->mode > 1) 
>index = 3; break;
> case BTN_2:
> case BTN_STYLUS2:
> case BTN_MIDDLE: index = 2; break;   
>   

-- 
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: [PATCH] Re: SCSI scanning

[Michael Elizabeth Chastain]

torben> core-hosts/i2o-upper.

Ok, I understand the problem.

Can you elaborate some more on exactly which files go in "core",
"hosts", and "upper"?  My understanding is:

# drivers/scsi
scsi-core-files  := scsi_mod.o scsi_syms.o
scsi-hosts-files := ... everything not in core and upper ...
scsi-upper-files := st.o sd_mod.o sr_mod.o sg.o

# i2o
i2o-files:= %.o

I can do this in the top Makefile by declaring lists like the above
using $(filter) and $(filter-out).  The hard part is going to be defining
"scsi-hosts-files" to work properly.  I think I will need to add a few
more lines to drivers/scsi/Makefile and make one more multi.  Or maybe
three more multis.

But I'm sure I can do it without moving any source files around.

torben> The perfect solution would be to remove the link order
torben> dependency. 

Yeah, I agree with Linus: minimizing link order dependencies is the
right thing.

For the link order dependencies which *do* exist at any point in time,
I'd like the Makefiles to have explicit link-ordering declarations with
comments on them about why they are needed.

Michael
-
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: [RFC] ioctl(2) return value

[Abramo Bagnara]

Linus Torvalds wrote:
> 
> On Thu, 21 Sep 2000, Abramo Bagnara wrote:
> >
> > In ALSA we use the return value from ioctl as a simple way to return a
> > positive number to user space (if the return value is less than 0 we got
> > error, of course)
> 
> Looks fine to me. It's how most UNIX system calls work, I don't see why
> ioctl() should be any different.
> 
> Linus

Cause my fault in sending to bad lkml address this answer has never
reached the list.

I'm sorry (now I've updated my address book).

-- 
Abramo Bagnara   mailto:[EMAIL PROTECTED]

Opera Unica
Via Emilia Interna, 140  Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy  Fax:   +39.0546.656023

ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com

It sounds good!
-
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-kernel-digest ?

[David S. Miller]

   Date:Thu, 21 Sep 2000 22:58:16 +0100 (BST)
   From: Alan Cox <[EMAIL PROTECTED]>

   Having slowly switched every list I have to run or help run to
   mailman I can recommend the pain of the switch over the pain of
   running majordomo

I suggested this but Matti immediately told me that mailman has
several RFC compliancy "issues" which I am sure he can elaborate on.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Question: Using floating point in the kernel

[Alan Cox]

> On Thu, Sep 21, 2000 at 11:36:17AM +, John Alvord wrote:
> > A 2.5-time problem is that portions of the kernel are planned to
> > become interruptible... so saving and restoring around a certain usage
> > would be insufficient.
> 
> It is sufficient when you do tsk->flags |= PF_USEDFPU first.

Unless you sleep

-
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: [RFC] ioctl(2) return value

[Alan Cox]

> I've looked Singe UNIX Specification, Version 2 and there this seems
> perfectly acceptable.
> 
> I'd like very much to have some feedback to do the RightThing (tm).
> 
> The alternative of course would be to add a result field inside struct
> passed by pointer to ioctl call.

Linux doesnt care. If you want ALSA to run on SYS5 or BSD derived kernels you
should avoid returning anything but 0/error-code from ioctls.  

-
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: Using floating point in the kernel

[Alan Cox]

> On Wed, 20 Sep 2000, Lyle Coder wrote:
> >You cannot use MMX registers in the kernel either, since the kernel doesen't 
> >save and restore FX state (fxsave, fxrstor) either (just like 
> >(fsave/frstor).
> 
> You might want to tell the software RAID maintainers that... RAID5 CRC
> calculations can be done with MMX. (I'm sure they save and restore the
> FPU state, however.  Yes, the save/restore cycle is _damned_ expensive.)

The raid5 folks include Ingo who knows precisely what he is doing to get
away with it. For 2.4 its a bit cleaner and there is infrastructure for it

-
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: Alpha/Linux FP denormal processing

[David S. Miller]

   Date: Thu, 21 Sep 2000 14:17:12 -0700
   From: Richard Henderson <[EMAIL PROTECTED]>

   Why would you need to cook up any sparc bits?  Jakub
   already has a proper implementaion of qrnnd for sparc...

Nevermind, brain fart.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-kernel-digest ?

[Alan Cox]

>   According to DaveM:  No.
>   (Sometimes he holds possibly bad opinnions as ferociously as Linus,
>but on the other hand, that Majordomo 1.x digester breaks structured
>MIME messages BADLY.  It should be trivial to fix, but I don't hack
>Md, I hack ZMailer -- and also sometimes the kernel.)

Having slowly switched every list I have to run or help run to mailman I can
recommend the pain of the switch over the pain of running majordomo 

-
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: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote:
> Torben Mathiasen wrote:
> 
> > I can't seem to find a clean way of getting the drivers outside
> > "drivers/scsi" to link _after_ the other low-level drivers.
> 
> Can you characterize the problem in more detail for me?  That is,
> exactly what link order constraints you are trying to obey.
> 
> I am thinking about this:
> 
> # Makefile
> link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o
> link-last :=
> 
> DRIVERS := \
>   $(filter $(link-first), $(DRIVERS)) \
>   $(filter-out $(link-first) $(link-last), $(DRIVERS)) \
>   $(filter $(link-last), $(DRIVERS))
>

Okay, in pre5 I got the scsi system to link

core-hosts-upperlayers.

We need to get the drivers outside drivers/scsi to link
as the _last_ ones in the host section:

core-hosts/i2o-upper.

Now this is difficult without moving things around, which is
bad. I'm not a makefile guru, so if you have any ideas go
for it. Alan problaly wants to verify the i2o stuff...

The perfect solution would be to remove the link order
dependency. 

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
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: [PATCH] Re: SCSI scanning

[Michael Elizabeth Chastain]

Torben Mathiasen wrote:

> I can't seem to find a clean way of getting the drivers outside
> "drivers/scsi" to link _after_ the other low-level drivers.

Can you characterize the problem in more detail for me?  That is,
exactly what link order constraints you are trying to obey.

I am thinking about this:

# Makefile
link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o
link-last :=

DRIVERS := \
$(filter $(link-first), $(DRIVERS)) \
$(filter-out $(link-first) $(link-last), $(DRIVERS)) \
$(filter $(link-last), $(DRIVERS))

This is just a preliminary thought.  I'd like to know more about the
problem.

Michael Elizabeth Chastain

"love without fear"
-
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.0test9-pre1, CD drive on hpt366 not detected correctlyand locking up when activated

[FORT David]

Andre Hedrick wrote:

> The ATAPI-DMA code for the use of all addon cards is not native.
> You are not allowed to do ATAPI-DMA on these, yet.
> I do not care what the OEM claims with their drivers, Linux chipset code
> is not completed or started to do this in 95 % of the cases.
>
> Cheers,
>
> On Wed, 20 Sep 2000, FORT David wrote:
>
> > The subject says everything, while detecting the drive
> >
> > i got the following strange thing:
> >
> > [from dmesg]
> >
> > >PIIX4: chipset revision 1
> ... bla bla bla

Yap, I've already tried with DMA disabled and the drive works perfectly. Is it to say
that
ide2 and ide3 don't have yet DMA support, even for Harddrives ?



--
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière 0240726275   %
% 44470 Thouare, France  [EMAIL PROTECTED] %
% ICU:54999224   AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
%  -datamining|   .~. %
%  -networking|   /V\L  I  N  U  X%
%  -opensource|  // \\ >Fear the Penguin< %
%  -GNOME/enlightenment/GIMP  | /(   )\   %
%   feel enlighted|  ^^-^^%
%-%



-
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: Alpha/Linux FP denormal processing

[Richard Henderson]

On Tue, Sep 19, 2000 at 08:58:06PM -0700, David S. Miller wrote:
> Is this a serious patch submission or just a call for testing?  If the
> former, I need to cook up the sparc bits once it gets in :-)

Huh?  A serious patch submission, since it fixes a bug.

Why would you need to cook up any sparc bits?  Jakub
already has a proper implementaion of qrnnd for sparc...



r~
-
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-test9-pre5] SCSI still broken, trident/mixer still broken

[Torben Mathiasen]

On Thu, Sep 21 2000, Douglas Gilbert wrote:
> Torben Mathiasen wrote:
> > 
> > Ok, small patch cooked up. Not tested, not compiled. Give
> > it a try, and if it works please send it off to Linus.
> > I really need to get some work done on a project...
> 
> Here is a very similar patch that has been tested
> [with a USB zip drive using sg (builtin) to read it].
> It worked and the /proc/scsi/sg directory was
> properly populated.
>

Looks good, but you should make the init functions static.


-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
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: PROBLEM: umount report "busy" on r/o remount of root filesystem

[Pavel Machek]

Hi!

> Umount report "busy" when i try r/o remount the root filesystem at end
> of
> halt script. My halt script ends with:
> 
> # Begin of halt
> kill -9 -1 
> umount -a
> mount -n -o remount,ro /

BTW is this right? Does kill -9 guarantee that all syscalls are dead by
the time it returns from kernel? Because if not, then race is pretty clear.

[And I'm pretty sure that kill -9 does *NOT* guarantee that.]

Try adding sleep 1 before umount -a

> halt
> # End of halt
> 
> Umount (and mount on next line too) report "/: device is busy" and the
> root filesystem
> stay not correctly unmounted. But when i press magic key "u" (emergency
> remount),
> the filesystem is correctly remounted. All other mounted filesystems are
> correctly unmounted by "umount -a". This bug is present only on my
> motherboard with SiS5513

I've seen this in past with various -testX and older. I doubt it is 
mainoard-specific.
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Cannot boot with 2.4.0-test9-pre5

[Carrer Yuri]

Cannot boot with 2.4.0-test9-pre5
gcc 2.7.3
compiled as PIII
the .config is the same of previous mails :)

Yuri

--
"I bambini nascono per essere felici"

Jose' Marti'

-
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: [patch *] VM deadlock fix

[Roger Larsson]

Hi,

Tried your patch on 2.2.4-test9-pre4
with the included debug patch applied.

Rebooted, started mmap002

After a while it starts outputting (magic did not work
this time - usually does):

- - -
"VM: try_to_free_pages (result: 1) try_again # 12345"
"VM: try_to_free_pages (result: 1) try_again # 12346"
- - -

My interpretation:
1) try_to_free_pages succeeds (or returns ok when it did not work)
2) __alloc_pages still can't alloc

Maybe it is different limits,
  try_to_free_pages requires less to succeed than
  __alloc_pages_limit requires.
or a bug in
  __alloc_pages_limit(zonelist, order, PAGES_MIN, direct_reclaim)

Note:
  12345  is an example, it loops to over 3...

/RogerL

Rik van Riel wrote:
> 
> Hi,
> 
> I've found and fixed the deadlocks in the new VM. They turned out
> to be single-cpu only bugs, which explains why they didn't crash my
> SMP tesnt box ;)
> 
> They have to do with the fact that processes schedule away while
> holding IO locks after waking up kswapd. At that point kswapd
> spends its time spinning on the IO locks and single-cpu systems
> will die...
> 
> Due to bad connectivity I'm not attaching this patch but have only
> put it online on my home page:
> 
> http://www.surriel.com/patches/2.4.0-t9p2-vmpatch
> 
> (yes, I'm at a conference now ... the worst beating this patch
> has had is a full night in 'make bzImage' with mem=8m)
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/   http://www.surriel.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/

--
Home page:
  http://www.norran.net/nra02596/

--- mm/page_alloc.c.origThu Sep 21 20:02:54 2000
+++ mm/page_alloc.c Thu Sep 21 20:49:35 2000
@@ -295,6 +295,7 @@
int direct_reclaim = 0;
unsigned int gfp_mask = zonelist->gfp_mask;
struct page * page = NULL;
+   int try_again_loops = 0;
 
/*
 * Allocations put pressure on the VM subsystem.
@@ -320,8 +321,10 @@
/*
 * Are we low on inactive pages?
 */
-   if (inactive_shortage() > inactive_target / 2 && free_shortage())
+   if (inactive_shortage() > inactive_target / 2 && free_shortage()) {
+ printk("VM: inactive shortage wake kswapd\n");
wakeup_kswapd(0);
+   }
 
 try_again:
/*
@@ -410,6 +413,7 @@
 * piece of free memory.
 */
if (order > 0 && (gfp_mask & __GFP_WAIT)) {
+ printk("VM: higher order");
zone = zonelist->zones;
/* First, clean some dirty pages. */
page_launder(gfp_mask, 1);
@@ -444,7 +448,9 @@
 * processes, etc).
 */
if (gfp_mask & __GFP_WAIT) {
-   try_to_free_pages(gfp_mask);
+   int success = try_to_free_pages(gfp_mask);
+ printk("VM: try_to_free_pages (result: %d) try_again # %d\n",
+success, ++try_again_loops);   
memory_pressure++;
goto try_again;
}

Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken

[Simon Kirby]

On Thu, Sep 21, 2000 at 09:39:07PM +0200, Torben Mathiasen wrote:

> Ok, small patch cooked up. Not tested, not compiled. Give
> it a try, and if it works please send it off to Linus.
> I really need to get some work done on a project...

This worked, thanks. :)

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[   [EMAIL PROTECTED]   ][   [EMAIL PROTECTED]]
[ Opinions expressed are not necessarily those of my employers. ]

> diff -ur --exclude-from=/root/torben /opt/kernel/kernels/linux/drivers/scsi/sg.c 
>linux/drivers/scsi/sg.c
> --- /opt/kernel/kernels/linux/drivers/scsi/sg.c   Thu Sep 21 21:29:44 2000
> +++ linux/drivers/scsi/sg.c   Thu Sep 21 21:35:46 2000
> @@ -1298,18 +1298,18 @@
>  }
>  
>  #ifdef MODULE
> -
>  MODULE_PARM(def_reserved_size, "i");
>  MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
> +#endif
>  
> -int init_module(void) {
> +static int __init init_sg(void) {
>  if (def_reserved_size >= 0)
>   sg_big_buff = def_reserved_size;
>  sg_template.module = THIS_MODULE;
>  return scsi_register_module(MODULE_SCSI_DEV, _template);
>  }
>  
> -void cleanup_module( void)
> +static void __exit exit_sg( void)
>  {
>  #ifdef CONFIG_PROC_FS
>  sg_proc_cleanup();
> @@ -1324,7 +1324,9 @@
>  }
>  sg_template.dev_max = 0;
>  }
> -#endif /* MODULE */
> +
> +module_init(init_sg);
> +module_exit(exit_sg);
>  
>  
>  #if 0

-
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: [PATCH] ISAPNP using an invalid IO_APIC IRQ

[Linus Torvalds]

On Thu, 21 Sep 2000, M.H.VanLeeuwen wrote:
> 
> Is this patch acceptable?

Please explain.

The test seems to be that "if there are IO_APICs, a PnP irq _has_ to be an
IO_APIC irq".

> +   if (!IO_APIC_IRQ(irq) && io_apic_irqs)
> +   return 1;

Which makes no sense to me. Why would a legacy irq not be acceptable?
Especially as they seem to be acceptable if there are _no_ IO-APIC irq's.

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: strange BogoMIPS value

[Marko Kreen]

On Thu, Sep 21, 2000 at 10:39:27AM -0500, Erik McKee wrote:
> It seems as if linux 2.2.17 is calculating a strange value for my bogomips
> value.  I thought is was supposed to be somewhere near the processor
> speed.  Perhaps I am missing something?

In 2.3.x they changed the BogoMIPS algorithm.  Seems like the change
is reached 2.2 series.  Something to do with variable clock speed...

Yes, new bogomips looks similar to twice the clock speed.

I guess the main reason for change was to make Linux run infinite
loops twice as fast...

-- 
marko

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

240-test[589] SMP lockups, confirming.

[Elmer Joandi]

Running here SMP  dual celeron, 440BX, 2HD( Maxtor 1G IBM 9G)
ISA 3c509, 128MB ram,
nfsroot server for 2 clients, X, workstation,

Once a day of serious usage computer locks up.
Most part sysrq works.

Now I had to work on text-console(test9 clean) for some days
and got 2 lockups:

1. nfs was in D state if I remember correctly (or R)(sysrq works)
  but userland is stuck.
2. httpd(not livin on nfs) stop caused then cpu1 to detect lockup
(and sysrq didnt work)
httpd stop is a weird operation, on some computers with e2compr
this caused a logmessage about async io.

logs show nothing.
It has been so for whole 2.4.0-test[5-9] time(I did not try earlier
much,
2.3.99-pre6 was latest, nfs activity seems to  be most guilty, however,
I can not see any way to debug it when
it happens under X.

Anyway,  the complaining about SMP instablity seems very justified,
because, I had to pump 1GB of logs into mysql and 2.2.18-pre9 did the
job,
so it is very probably not a hardware problem. 2.2.18-pre9 is up
and running for 35 hours now, incuding 10 hours mysql with loadavg 3.

nfsroot clients are 2.2 and 2.4.

If anyone wants me to do some setup-specific stresstests, u are welcome.



elmer.



-
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-test9-pre5] SCSI still broken, trident/mixer still broken

[Douglas Gilbert]

Torben Mathiasen wrote:
> 
> Ok, small patch cooked up. Not tested, not compiled. Give
> it a try, and if it works please send it off to Linus.
> I really need to get some work done on a project...

Here is a very similar patch that has been tested
[with a USB zip drive using sg (builtin) to read it].
It worked and the /proc/scsi/sg directory was
properly populated.

Doug Gilbert

--- linux/drivers/scsi/sg.c Thu Sep 21 15:05:28 2000
+++ linux/drivers/scsi/sg.c3117 Thu Sep 21 15:22:08 2000
@@ -17,8 +17,8 @@
  * any later version.
  *
  */
- static char * sg_version_str = "Version: 3.1.16 (2716)";
- static int sg_version_num = 30116; /* 2 digits for each component */
+ static char * sg_version_str = "Version: 3.1.17 (2921)";
+ static int sg_version_num = 30117; /* 2 digits for each component */
 /*
  *  D. P. Gilbert ([EMAIL PROTECTED], [EMAIL PROTECTED]), notes:
  *  - scsi logging is available via SCSI_LOG_TIMEOUT macros. First
@@ -1298,18 +1298,20 @@
 }
 
 #ifdef MODULE
-
 MODULE_PARM(def_reserved_size, "i");
 MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif /* MODULE */
 
-int init_module(void) {
+int __init init_sg(void) {
+#ifdef MODULE
 if (def_reserved_size >= 0)
sg_big_buff = def_reserved_size;
+#endif /* MODULE */
 sg_template.module = THIS_MODULE;
 return scsi_register_module(MODULE_SCSI_DEV, _template);
 }
 
-void cleanup_module( void)
+void __exit exit_sg( void)
 {
 #ifdef CONFIG_PROC_FS
 sg_proc_cleanup();
@@ -1324,7 +1326,6 @@
 }
 sg_template.dev_max = 0;
 }
-#endif /* MODULE */
 
 
 #if 0
@@ -2782,3 +2783,7 @@
 return 1;
 }
 #endif  /* CONFIG_PROC_FS */
+
+
+module_init(init_sg);
+module_exit(exit_sg);

Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken

[Torben Mathiasen]

Ok, small patch cooked up. Not tested, not compiled. Give
it a try, and if it works please send it off to Linus.
I really need to get some work done on a project...


-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk


diff -ur --exclude-from=/root/torben /opt/kernel/kernels/linux/drivers/scsi/sg.c 
linux/drivers/scsi/sg.c
--- /opt/kernel/kernels/linux/drivers/scsi/sg.c Thu Sep 21 21:29:44 2000
+++ linux/drivers/scsi/sg.c Thu Sep 21 21:35:46 2000
@@ -1298,18 +1298,18 @@
 }
 
 #ifdef MODULE
-
 MODULE_PARM(def_reserved_size, "i");
 MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif
 
-int init_module(void) {
+static int __init init_sg(void) {
 if (def_reserved_size >= 0)
sg_big_buff = def_reserved_size;
 sg_template.module = THIS_MODULE;
 return scsi_register_module(MODULE_SCSI_DEV, _template);
 }
 
-void cleanup_module( void)
+static void __exit exit_sg( void)
 {
 #ifdef CONFIG_PROC_FS
 sg_proc_cleanup();
@@ -1324,7 +1324,9 @@
 }
 sg_template.dev_max = 0;
 }
-#endif /* MODULE */
+
+module_init(init_sg);
+module_exit(exit_sg);
 
 
 #if 0

Re: [RFC] ioctl(2) return value

[Andries . Brouwer]

> Not only Sun does, Linux does too (e.g. in various networking ioctls).
> I would just fix the man page.

Ach - more ugliness in Linux.
New man page fragment:

...
RETURN VALUE
   Usually, on success zero is returned.  A  few  ioctls  use
   the  return value as an output parameter and return a non­
   negative value on success.  On error, -1 is returned,  and
   errno is set appropriately.
...

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: strange BogoMIPS value

[David Riley]

Erik McKee wrote:
> 
> Hello!
> 
> It seems as if linux 2.2.17 is calculating a strange value for my bogomips
> value.  I thought is was supposed to be somewhere near the processor
> speed.  Perhaps I am missing something?
> 
> Have a nice day ;)
> Erik
> 

> Detected 99547 kHz processor.
...
> Calibrating delay loop... 198.25 BogoMIPS

This actually seems about right.

Keep in mind that just about any modern processor since the 486 has had
parallel instruction units.  Theoretically, for example, a processor
with three integer units (like a PowerPC 750 or an Athlon) could execute
3 short integer instructions per CPU cycle (not quite that simple). 
MIPS is for the number of instructions that can be executed per second,
which means that if you have a slower processor that takes several
cycles to do even simple computations (say 2 cycles for an add) you
might get less than your CPU speed.  What you have seems to be twice
your CPU speed.  I'm not quite sure what the algorithm is (I never
really peeked) but on my Pentium 100 I get about 200 BogoMIPS (though
older kernels used to give me 40).  What you have is twice your
processor speed.
-
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: [Oops] Unable to handle kernel NULL pointer dereference

[J Brook]

Thank you Martin! Upgrading to test9-pre5 and applying your patch
works a treat. I've tried running through the steps that lead to the
crash with the old kernel and there's now no trace of an oops! Thanks
also to Igmar Palsenberg who pointed me in the right direction.

 John

[EMAIL PROTECTED]

Martin Diehl wrote:

> On Wed, 20 Sep 2000, J Brook wrote:
> 
> > >>EIP; c01527b9<= 
> > Trace; c015357b  
> 
> this is the quota issue for which I've posted a fix some days ago.
> It's (as of 2.4.0-t9p5) waiting on the TODO list to be merged.
> I'd consider it "critical" (wrt what Linus accepts for 2.4.0) as
> processes calling sys_chown() may be trapped in D-state forever so
> you end up fscking.
> 
> 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.0-test9-pre5] SCSI still broken, trident/mixer still broken

[Torben Mathiasen]

On Thu, Sep 21 2000, Douglas Gilbert wrote:

[delete]

> > At one point before I followed some of the debug/logging commands listed
> > at the top of sg.c and got an Oops as well...
> 
> Seems as though I've got a lot of retesting to do.
>

Please note that the changes to the scsi midlayer requires all
upper layers to use the module_init/exit functions. We do 
_not_ explicitly call the layers init funtions anymore.
Adding the module stuff will probaly fix most problems
(asuming module and builtin do not differ). The link
order should make sure everything gets called in order.


-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
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-test9-pre5] SCSI still broken, trident/mixer still broken

[Simon Kirby]

On Thu, Sep 21, 2000 at 02:34:01PM -0400, Douglas Gilbert wrote:

> I do nearly all of my testing with sg as a module.
> So this looks like (another recent) breakage.
> 
> It is beginning to look like the sg driver is not
> (properly) initialized when it is built into the
> kernel. Perhaps you could put a printk in
> sg_init() and sg_attach() to see if they are called.

Actually, I also had a printk in sg_init() and it never got
printed.  I didn't have one in sg_attach, but I can try that.

> > At one point before I followed some of the debug/logging commands listed
> > at the top of sg.c and got an Oops as well...
> 
> Seems as though I've got a lot of retesting to do.

The oops may have been the result of it not being properly initialized or
something...

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[   [EMAIL PROTECTED]   ][   [EMAIL PROTECTED]]
[ Opinions expressed are not necessarily those of my employers. ]
-
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: [PATCH] 2.4.0 i386 watchpoint problems

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Actually, even simpler approach:
> 
>  - always clear db7 after sending signal - don't test for pending or for
>kernel mode at all at that point.
>  - re-load %db7 at the top of the for(;;) loop in do_signal().
> 
> That should mean that you will actually get a debug signal for ALL
> triggers of the debug registers, except you'll only get one for kernel
> mode.
> 
> (For extra credit, make the patch use "eip=-1" in the siginfo structure if
> the trap happened in kernel mode, so that we don't leak kernel addresses
> to user space. Not that it would be much of a security issue, but it's a
> beauty wart that could easily be cleared up).
> 

It could be (and so would even giving the signals in kernel
mode)... remember that silly case of passwords crossing page
boundaries?

-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: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken

[Douglas Gilbert]

Simon Kirby wrote:
> 
> On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote:
> 
> > Interesting. 'cat /proc/scsi/scsi' should show the same
> > devices as 'cat /proc/scsi/sg/device_strs' [and
> > 'cat /proc/scsi/sg/devices']. If not, then the SCSI
> > mid-level is not calling sg_detect() [in sg.c] for
> > all new scsi devices detected by the mid-level.
> >
> > The sg_detect() routine is silent for all devices that
> > are "owned" by other upper level drivers (i.e. disks,
> > cdroms and tapes) but outputs a line for any other
> > scsi type (e.g. scanners which are scsi type 6).
> 
> I didn't fiddle with it too much, but I added a printk to sg_detect and
> verified it was not getting called at all.  I notice now, however, that I
> don't even have a /proc/scsi/sg.  Does that mean it's not getting
> initialized at all?  CONFIG_CHR_DEV_SG=y, assuming that's what needs to
> be set (config didn't change between kernel versions).

I do nearly all of my testing with sg as a module.
So this looks like (another recent) breakage.

It is beginning to look like the sg driver is not
(properly) initialized when it is built into the
kernel. Perhaps you could put a printk in
sg_init() and sg_attach() to see if they are called.

> At one point before I followed some of the debug/logging commands listed
> at the top of sg.c and got an Oops as well...

Seems as though I've got a lot of retesting to do.

Doug Gilbert
-
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-test9-pre5] SCSI still broken, trident/mixer still broken

[Douglas Gilbert]

Torben Mathiasen wrote:
> 
> On Thu, Sep 21 2000, Douglas Gilbert wrote:
> 
> [deleted]
> 
> > It is not clear to me what "hacking" sg requires as
> > Torben Mathiasen suggested in his response. This seems
> > like a mid level problem. I'll check with my scsi
> > scanner this evening.
> >
> 
> Well first of all the sg driver needs to be updated the
> same way sd and sr was.

Well looking at sr in test9-pre5 the only changes are the 
addition of 'static' before the sr_template definition 
and various functions. Sg already has the corresponding
functions declared static and the sg_template definition
has been changed to 'static'.

So as far as I can see the mid level has failed to call
sg_detect() when it should have. Simon has now confirmed
with a printk that sg_detect() was not called for the
scanner which the mid level obviously knows about.

Doug Gilbert
-
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-test9-pre4: __alloc_pages(...) try_again:

[Roger Larsson]

Rik van Riel wrote:
> 
> On Wed, 20 Sep 2000, Roger Larsson wrote:
> 
> > I added a counter for try_again loops.
> >
> > ... __alloc_pages(...)
> >
> > int direct_reclaim = 0;
> > unsigned int gfp_mask = zonelist->gfp_mask;
> > struct page * page = NULL;
> > +   int try_again_loops = 0;
> >
> > - - -
> >
> > + printk("VM: sync kswapd (direct_reclaim: %d) try_again #
> > %d\n",
> > +direct_reclaim, ++try_again_loops);
> > wakeup_kswapd(1);
> > goto try_again;
> >
> >
> > Result was surprising:
> >   direct_reclaim was 1.
> >   try_again_loops did never stop increasing (note: it is not static,
> >   and should restart from zero after each success)
> >
> > Why does this happen?
> > a) kswapd did not succeed in freeing a suitable page?
> > b) __alloc_pages did not succeed in grabbing the page?
> 
> No.
> 
> It's a locking issue. In __alloc_pages we may be
> holding some IO locks (gfp_mask & __GFP_IO == 0),
> then we wait on kswapd and schedule out. The result is that
> kswapd will be spinning on a lock it can never get.

Hmm... If it did how could the __alloc_pages
wakeup_kswapd(1) return, it should be synchronous...
(counter is incremented past 1, a lot past...)

In addition to this I have seen that kswapd really loops with
a printk in the loop. (first in do_try_to_free_pages to be
exact)

> 
> The fix for this was included in the patch I sent to Linus
> for 2.4.0-tes9-pre2, but unfortunately not included.
> Ia'll send it agani soon.
>

Ok, I will try the patch.
But I really think that the problem is something different...
 
> There is anathor, more subtle, case like this in
> buffer.c, which I have also fixed in my local tree here.
> 
> The patch for this will be online on my home paeg
> soon. (connectivity isn't that great as you can see from mytyping)
> 
> cheers,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/   http://www.surriel.com/

--
Home page:
  http://www.norran.net/nra02596/
-
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-test9-pre5] SCSI still broken, trident/mixer still broken

[Simon Kirby]

On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote:

> Interesting. 'cat /proc/scsi/scsi' should show the same
> devices as 'cat /proc/scsi/sg/device_strs' [and 
> 'cat /proc/scsi/sg/devices']. If not, then the SCSI
> mid-level is not calling sg_detect() [in sg.c] for
> all new scsi devices detected by the mid-level.
> 
> The sg_detect() routine is silent for all devices that
> are "owned" by other upper level drivers (i.e. disks,
> cdroms and tapes) but outputs a line for any other
> scsi type (e.g. scanners which are scsi type 6).

I didn't fiddle with it too much, but I added a printk to sg_detect and
verified it was not getting called at all.  I notice now, however, that I
don't even have a /proc/scsi/sg.  Does that mean it's not getting
initialized at all?  CONFIG_CHR_DEV_SG=y, assuming that's what needs to
be set (config didn't change between kernel versions).

At one point before I followed some of the debug/logging commands listed
at the top of sg.c and got an Oops as well...

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[   [EMAIL PROTECTED]   ][   [EMAIL PROTECTED]]
[ Opinions expressed are not necessarily those of my employers. ]
-
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: [PATCH] 2.4.0 i386 watchpoint problems

[Linus Torvalds]

On Thu, 21 Sep 2000, Linus Torvalds wrote:
> 
> I would suggest an alternate patch, which would be something like
> 
>   if (SIGTRAP is pending in tsk)
>   goto clear_dr7;

Actually, even simpler approach:

 - always clear db7 after sending signal - don't test for pending or for
   kernel mode at all at that point.
 - re-load %db7 at the top of the for(;;) loop in do_signal().

That should mean that you will actually get a debug signal for ALL
triggers of the debug registers, except you'll only get one for kernel
mode.

(For extra credit, make the patch use "eip=-1" in the siginfo structure if
the trap happened in kernel mode, so that we don't leak kernel addresses
to user space. Not that it would be much of a security issue, but it's a
beauty wart that could easily be cleared up).

Send me that patch, tested, and I'll happily apply it.

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.0-test9-pre5] SCSI still broken, trident/mixer still broken

[Torben Mathiasen]

On Thu, Sep 21 2000, Douglas Gilbert wrote:

[deleted]

> It is not clear to me what "hacking" sg requires as
> Torben Mathiasen suggested in his response. This seems
> like a mid level problem. I'll check with my scsi
> scanner this evening.
>

Well first of all the sg driver needs to be updated the
same way sd and sr was.

> 
> Other random scsi notes:
>   - scsi modules were completely broken in 2.4.0-test9-pre4
> but worked again in pre5 [Makefile hacks?]
[snip]

Yes, check the scsi scanning thread, and the patch I sent 
yesterday.


-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
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/

scsi-ide lockup is fixed in test9-pre5

[Frank van de Pol]

Just tested it with a plain 2.4.0-test9-pre5 kernel and the problem is now
fixed.

Thanks to all involved,
Frank.

-- 
+ --- -- -  -   -- 
|Frank van de Pol  -o)
| [EMAIL PROTECTED]   /\\
| _\_v
|Linux - Why use Windows, since there is a door?
-
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: [PATCH] 2.4.0 i386 watchpoint problems

[Linus Torvalds]

On Thu, 21 Sep 2000, James Cownie wrote:
>
> The problem
> http://www.geocrawler.com/archives/3/343/2000/8/0/4140605/
> which is on Alan's list to be looked at for 2.2 remains in 
> 2.4.0.
> 
> Here is a patch for 2.4.0

I'm very nervous that this patch couldlead to horrible performance issues
due to somebody setting debug state to catch some nasty common condition
in kernel code - causing tons of traps while we're not even schedulable.

I would suggest an alternate patch, which would be something like

if (SIGTRAP is pending in tsk)
goto clear_dr7;

which basically says that we'll send the signal once, regardless of
whether the trap happened in user or kernel mode, and we can't get into
the nasty "tons of traps" situation because we'll at most get one trap
until the signal has been delivered..

Does that work for you?

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.0-test9-pre5] SCSI still broken, trident/mixer still broken

[Douglas Gilbert]

Simon Kirby wrote:

> Around 2.4.0-test9-pre2 (or so, definitely in pre3) both my SCSI scanner
> and trident sound card stopped being happy.  They are still both broken
> in pre5.  On test8, both work perfectly.
> 
> On test8:
> 
> (scsi0:6:0) Synchronous Data Transfer Request was rejected
>   Vendor:   Model: Scanner   Rev: 1.70
>   Type:   ScannerANSI SCSI revision: 04
> Detected scsi generic sg0 at scsi0, channel 0, id 6, lun 0, type 6
> (scsi1:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31.
>   Vendor: YAMAHAModel: CRW4416S  Rev: 1.0e
>   Type:   CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0
> scsi : detected 1 SCSI cdrom total.
> sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray
> 
> ... on test9pre5 and test9pre3:
> 
> (scsi0:6:0) Synchronous Data Transfer Request was rejected
>   Vendor:   Model: Scanner   Rev: 1.70
>   Type:   ScannerANSI SCSI revision: 04
> (scsi0:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31.
>   Vendor: YAMAHAModel: CRW4416S  Rev: 1.0e
>   Type:   CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
> sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray
> 
> ("Detected scsi generic..." line missing.)

[snipped trident problem report]

Interesting. 'cat /proc/scsi/scsi' should show the same
devices as 'cat /proc/scsi/sg/device_strs' [and 
'cat /proc/scsi/sg/devices']. If not, then the SCSI
mid-level is not calling sg_detect() [in sg.c] for
all new scsi devices detected by the mid-level.

The sg_detect() routine is silent for all devices that
are "owned" by other upper level drivers (i.e. disks,
cdroms and tapes) but outputs a line for any other
scsi type (e.g. scanners which are scsi type 6).

It is not clear to me what "hacking" sg requires as
Torben Mathiasen suggested in his response. This seems
like a mid level problem. I'll check with my scsi
scanner this evening.


Other random scsi notes:
  - scsi modules were completely broken in 2.4.0-test9-pre4
but worked again in pre5 [Makefile hacks?]
  - the sd module's name has now reverted to its historic name
of "sd_mod.o"
  - the imm module (scsi over parallel port for ZIP drives)
works on a UP machine but locks up a SMP machine (until
the NMI notices)
  - the sg "stall" problem (plugged queues) has not been
addressed yet

Doug Gilbert
-
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: [User-mode-linux-user] Ptrace broken since 2.4.0-test8pre4?...

[William Stearns]

On Tue, 19 Sep 2000, Jeff Dike wrote:

> [EMAIL PROTECTED] said:
> > I tested vanilla test7 with  ptrace() patch. It breaks uml exactly
> > like I see with any kernel > test7. 
> 
> > exec_user.c:29 ptrace(PTRACE_SYSCALL, 4901, 0, 0) = 0
> > And voila, we got SIGSEGV instead of happy running child:
> > Child 4901 exited with signal 11 
> 
> Yuri, I apologize for doubting you.  That's about the best evidence possible 
> that the test8 ptrace fix is what's breaking UML and not the thread group 
> stuff.
> 
> If anyone has any idea why that fix breaks PTRACE_SYSCALL, I'd love to know.  
> I'm kind of short on time at the moment, so I'm not in a great position to 
> delve into this at the moment.
> 
> Until this is fixed, UML doesn't work on any host kernels beyond test7.

As a further verification that this change is causing problems for
UML, test9-pre5 allows uml to run if the ptrace.c change is
reverted.  I do understand that this is not the correct fix for the
problem, but for those who would like to independently verify this, the
(incorrect) patch is attached.

Cheers,
- Bill

---
Things you Do Not Want To See On IRC: your husband commenting on the
S390 port and in the next comment, announcing that he expects a new toy.
He tells me the two are unrelated. I do hope so. 
- Telsa Gwynn, Alan Cox' wife
--
William Stearns ([EMAIL PROTECTED]).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--



diff -u --recursive --new-file linux/arch/i386/kernel/ptrace.c.orig 
linux/arch/i386/kernel/ptrace.c
--- linux/arch/i386/kernel/ptrace.c.origThu Sep 21 00:34:03 2000
+++ linux/arch/i386/kernel/ptrace.c Thu Sep 21 11:44:36 2000
@@ -100,10 +100,10 @@
value &= FLAG_MASK;
value |= get_stack_long(child, EFL_OFFSET) & ~FLAG_MASK;
break;
-   case EIP:
-   /* Mark us as not being in a system call, so that no restart 
issues happen */ 
-   put_stack_long(child, 4*ORIG_EAX - sizeof(struct pt_regs), 
-1);
-   break;
+// case EIP:
+// /* Mark us as not being in a system call, so that no restart 
+issues happen */ 
+// put_stack_long(child, 4*ORIG_EAX - sizeof(struct pt_regs), 
+-1);
+// break;
}
if (regno > GS*4)
regno -= 2*4;

[patch *] VM deadlock fix

[Rik van Riel]

Hi,

I've found and fixed the deadlocks in the new VM. They turned out 
to be single-cpu only bugs, which explains why they didn't crash my
SMP tesnt box ;)

They have to do with the fact that processes schedule away while
holding IO locks after waking up kswapd. At that point kswapd
spends its time spinning on the IO locks and single-cpu systems
will die...

Due to bad connectivity I'm not attaching this patch but have only
put it online on my home page:

http://www.surriel.com/patches/2.4.0-t9p2-vmpatch

(yes, I'm at a conference now ... the worst beating this patch
has had is a full night in 'make bzImage' with mem=8m)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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: BPF in the kernel

[Marc Lehmann]

On Mon, Sep 18, 2000 at 10:55:20PM -0700, Philippe Troin <[EMAIL PROTECTED]> wrote:
> Ideally, libpcap should be extended to support the LPFisms. A LSF

Indeed, and I sent a patch to do so about 4 weeks after LSF was in the
kernel, but nothing happened so far. ("Hey, the -s option suddenly works ;")

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
-
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: Tailmerging for Ext2 - release 0.0

[Marc Lehmann]

On Sat, Sep 16, 2000 at 10:59:54PM +0200, Daniel Phillips 
<[EMAIL PROTECTED]> wrote:
> Here we are, finally: code.  I do not make any claim that this code is
> elegant, correct, complete, esthetically pleasing or that it will
> refrain from eating your hard disk.
> 
> What this code will do is let you verify for yourself whether my
> proposed approach to tailmerging for Ext2 is worth the effort.  After

Well, if ext2 gets some decent directory speed up soon + some journaling
(soon as well ;) then this could be a very viable alternative to reiserfs!


-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
-
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-test9-pre4: __alloc_pages(...) try_again:

[Rik van Riel]

On Wed, 20 Sep 2000, Roger Larsson wrote:

> I added a counter for try_again loops.
> 
> ... __alloc_pages(...)
> 
> int direct_reclaim = 0;
> unsigned int gfp_mask = zonelist->gfp_mask;
> struct page * page = NULL;
> +   int try_again_loops = 0;
> 
> - - -
> 
> + printk("VM: sync kswapd (direct_reclaim: %d) try_again #
> %d\n",
> +direct_reclaim, ++try_again_loops);
> wakeup_kswapd(1);
> goto try_again;
> 
> 
> Result was surprising:
>   direct_reclaim was 1.
>   try_again_loops did never stop increasing (note: it is not static,
>   and should restart from zero after each success)
> 
> Why does this happen?
> a) kswapd did not succeed in freeing a suitable page?
> b) __alloc_pages did not succeed in grabbing the page?

No.

It's a locking issue. In __alloc_pages we may be
holding some IO locks (gfp_mask & __GFP_IO == 0),
then we wait on kswapd and schedule out. The result is that
kswapd will be spinning on a lock it can never get.

The fix for this was included in the patch I sent to Linus
for 2.4.0-tes9-pre2, but unfortunately not included.
Ia'll send it agani soon.

There is anathor, more subtle, case like this in
buffer.c, which I have also fixed in my local tree here.

The patch for this will be online on my home paeg
soon. (connectivity isn't that great as you can see from mytyping)

cheers,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.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/

Datapoint re: "umount: device busy"

[Matthew Kirkwood]

Hi,

It seems that it's fairly easy to get a ramfs stuck:

# mkdir bar
# mount -t ramfs bar bar
# umount bar
# mount -t ramfs bar bar
# chown nobody bar
# umount bar
umount: /root/bar: device is busy
#

This doesn't appear to affect ext2 filesystems, though.

Matthew

--
$ grep -c ramfs /proc/mounts
12

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

can't login to X

[Paavo Nikula]

I can't figure out why i can't login to X as user with the latest kernels 
(test9-pre[2-4]). Maybe someone here can help?

Tiesitkö, että Sunpoint.netin käyttäjät voivat lukea sähköpostinsa myös 
WAP-puhelimella.
  
http://www.sunpoint.net/SunAds/click.htm?mode=footer==http%3A%2F%2Fwww.sunpoint.net%2Fwap%2F
-
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: lvm in 2.4.0-test9pre5

[Jan Niehusmann]

On Thu, Sep 21, 2000 at 05:47:36PM +0200, Andrea Arcangeli wrote:
> On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
> > Yes, lvm.c and lvm-snap.c are missing from drivers/md/. 
> 
> LVM and MD have nothing common.

Yes, I know. I'm not arguing about the right location for lvm. But lvm has
been moved from drivers/block/Makefile to drivers/md/Makefile, so lvm.c
has to follow. (Or Makefile has to be changed again)

If lvm is in drivers/md or in drivers/lvm is a matter of taste. drivers/lvm
is more logical, but having another directory for only two source files? 

Putting it in the same directory as md is not too bad, because both do similar
things: They take existing block devices and somehow combine them to a bigger 
one. 

Put it wherever you want. I just don't care. But make it work. ;-)

Jan

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

strange BogoMIPS value

[Erik McKee]

Hello!

It seems as if linux 2.2.17 is calculating a strange value for my bogomips
value.  I thought is was supposed to be somewhere near the processor
speed.  Perhaps I am missing something?

Have a nice day ;)
Erik

p.s. dmesg output attatched...


cc version 2.95.1 19990816 (release)) #8 Thu Sep 14 14:14:56 CDT 2000
Detected 99547 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 198.25 BogoMIPS
Memory: 30628k/32768k available (1068k kernel code, 412k reserved, 600k data, 60k 
init)
Dentry hash table entries: 4096 (order 3, 32k)
Buffer cache hash table entries: 32768 (order 5, 128k)
Page cache hash table entries: 8192 (order 3, 32k)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: Intel Pentium 75 - 200 stepping 06
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfc7f5
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 32768 bhash 32768)
IPv4 over IPv4 tunneling driver
early initialization of device tunl0 is deferred
GRE over IPv4 tunneling driver
early initialization of device gre0 is deferred
NET4: Linux IPX 0.38 for NET4.0
IPX Portions Copyright (c) 1995 Caldera, Inc.
NET4: AppleTalk 0.18 for Linux NET4.0
Initializing RT netlink socket
Starting kswapd v 1.5 
vga16fb: initializing
vga16fb: mapped to 0xc00a
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device
Detected PS/2 Mouse Port.
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
pty: 512 Unix98 ptys configured
Software Watchdog Timer: 0.05, timer margin: 60 sec
Real Time Clock Driver v1.09
loop: registered device at major 7
CMD640: ignored by ide_scan_pci_device() (uses own driver)
ide0: buggy cmd640b interface on PCI (type1), config=0x7e
ide1: serialized, secondary interface okay
cmd640: drive0 timings/prefetch(on) preserved, clocks=2/3/3
cmd640: drive1 timings/prefetch(on) preserved, clocks=2/3/3
cmd640: drive2 timings/prefetch(on) preserved, clocks=2/3/3
cmd640: drive3 timings/prefetch(on) preserved, clocks=2/3/3
hda: Conner Peripherals 1080MB - CFS1081A, ATA DISK drive
hdb: Conner Peripherals 420MB - CFS420A, ATA DISK drive
hdc: Conner Peripherals 1275MB - CFS1275A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15 (serialized with ide0)
hda: Conner Peripherals 1080MB - CFS1081A, 1032MB w/0kB Cache, CHS=524/64/63
hdb: Conner Peripherals 420MB - CFS420A, 406MB w/64kB Cache, CHS=826/16/63
hdc: Conner Peripherals 1275MB - CFS1275A, 1219MB w/64kB Cache, CHS=2477/16/63
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
PPP: version 2.3.7 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
PPP BSD Compression module registered
PPP Deflate Compression module registered
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
SLIP linefill/keepalive option.
ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker 
http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html
ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xfce0, IRQ 9.
eth0: RealTek RTL-8029 found at 0xfce0, IRQ 9, 00:C0:F0:5B:62:4B.
Partition check:
 hda: hda1 hda2
 hdb: hdb1 hdb2
 hdc: [PTBL] [619/64/63] hdc1
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 60k freed
PPP BSD Compression module registered
3c507.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED])
eth1: 3c507 at 0x300, 00 60 8c 5c e4 7a, IRQ 3, external xcvr, memory 0xd-0xd.
3c507.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED])
Adding Swap: 16124k swap-space (priority -1)
Adding Swap: 15620k swap-space (priority -2)

Re: cpu reset on laptops and microcode update.

[Timur Tabi]

** Reply to message from [EMAIL PROTECTED] on Thu, 21 Sep 2000 06:01:08 -0700


> I was curious about this when with OS/2, the Win-OS2 media player would not
> stop when I gave it the three-finger-salute while it was still playing a
> CD-ROM, that is, until it began to re-boot.  When it re-boots, the microcode
> should get replaced during the bootstrap process.

That's got nothing to do with CPU microcode.  It has to do with the fact that
the sound card and the CPU do no work when playing audio from a CD-ROM.  The
CD-ROM drive does all the work - it extracts the audio data from the CD,
converts it to analog, and pipes out a cable which plugs into your sound card.
All your sound card does is pipe out to your speakers.  In order to stop a CD,
you need to 1) stop the CD-ROM drive (reset the drive) or 2) mute the CD input
(reset the sound card).



-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
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: lvm in 2.4.0-test9pre5

[Andrea Arcangeli]

On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
> Yes, lvm.c and lvm-snap.c are missing from drivers/md/. 

LVM and MD have nothing common. They're two completly orthogonal piece of code
(you can put LVM on top of MD but that's just because of the nice reentrance of
the blkdev API as you can run loop on top of ext2 on top of ramdisk).  I don't
think it's good idea to mix LVM and MD in the same directory. LVM should live
in drivers/lvm not drivers/md.

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/

AW: kernel: nfs: task X can't get a request slot

[Schulz, Michael (Presales)]

Hi Vincent,

I have the same Problem on a Proliant 2500 and my Workstation
with a 3Com 3c509. Different Settings on the Network-Cards could
be the Problem (i.e. Half vs. Full-Duplex).

bye
  michael


> COMPAQ Computer GmbH
Michael Schulz
Competence Center Enterprise Computing
Robert Bosch Str.5
63303 Dreieich
Tel:49 6103 383 339
Mail:   [EMAIL PROTECTED]

PGP-Key on Request or on www.keyserver.de



> -Ursprungliche Nachricht-
> Von: Vincent Schultz [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 21. September 2000 14:22
> An: [EMAIL PROTECTED]
> Betreff: kernel: nfs: task X can't get a request slot
> 
> 
> Hello gentlemen,
> 
> We experience some troubles from time to time between our web 
> servers and a NetApp 700 series. Sometimes, at hight loads 
> (it seems), all servers crash at the same time. 
> Here is a sample of /var/log/messages before they crash :
> 
> Sep 20 02:42:03 web kernel: nfs: server web-filer1 not 
> responding, still trying
> Sep 20 02:42:04 web kernel: nfs: task 61640 can't get a request slot
> Sep 20 02:42:04 web kernel: nfs: task 61661 can't get a request slot
> and so long ...
> 
> As far as I know this message show that there is a congestion 
> on the RPC socket.
 
-
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: cpu reset on laptops and microcode update.

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Tigran Aivazian <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> A long time ago I noticed a curious feature on my Dell Latitude CPx 
> H-450GT laptop - rebooting it via "shutdown -r now" (and therefore going
> through BIOS) does not discard the microcode applied to the CPU. But I
> would expect it to be discarded as prescribed by Intel manuals, on #RESET.
> 
> Does it mean that rebooting a laptop does not actually ever reset the
> CPU? (this would imply that the BIOS is also a protected mode software?)
> 

Most CPU's aren't... instead the system assert INIT.

-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: [RFC] Wine speedup through kernel module

[David Howells]

"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
> In spite of that, it should be considered. It allows this:
> 
> $ ls -log /proc/self/fd
> total 0
> lrwx--1 acahalan   64 Sep 21 09:12 0 -> /dev/pts/4
> lrwx--1 acahalan   64 Sep 21 09:12 1 -> /dev/pts/4
> lrwx--1 acahalan   64 Sep 21 09:12 2 -> /dev/pts/4
> lrwx--1 acahalan   64 Sep 21 09:12 3 -> mutex:[720429]
> lrwx--1 acahalan   64 Sep 21 09:12 4 -> event:[592]
> lr-x--1 acahalan   64 Sep 21 09:12 5 -> /proc/14527/fd

Looks nice, I know, but it may mean file handles are indirect, in that you
have:

  struct file->struct dentry->struct inode->struct winefile->struct file->...

if you can't store all the extra wine attributes on the struct file. It also
means that the inode or the dentry has to maintain a list of attached file's,
which I don't think it does at the moment.

> >> Any information not in kernel structure is Wine specific anyway, so
> >> should be separate
> 
> It goes into the kernel structure, so that it won't be Wine-specific.
> SGI has already done this so that Samba would interact properly with
> regular UNIX software and the NFS server.
> 
> (one might support SGI's API for this)

Hmmm... worth investigating. I take it that this was only done for IRIX, not
Linux.

> Yep, share bits definitely belong in the kernel. How else could
> you properly protect against regular (clueless) Linux software?

Probably do...

> We already have 3 ways to do file locking, so this is only 33% more.

66%... Don't forget LockFile/UnlockFile. These work very similarly to fcntl,
I think, but demand mandatory locking.

> Now THAT would be a disaster. Linux software ought to be able to rely
> on having these features available.

I agree, but does Linus?

> Modules are very bad for this.

Probably, but unless the code goes into the kernel proper, patch maintainance
can be a real nightmare. The greater the amount of kernel actually changed by
a patch, the worse it is.

> Named? That means you use the VFS.

Not necessarily. For file handles, you probably should (unless you want
drive-letter mappings to occur in the kernel - yuk), but the other things are
effectively in separate namespaces.

>> Don't use it then... it'll not be mandatory. Wine has also to support OS's
>> that can't or won't add Win32 support in the kernel.

You misunderstand me... _Using_ this API will not be mandatory, whether or not
it exists in the kernel proper.

> See a pattern here? System calls are not supposed to be modular.

knfsd? But I agree, really. But what is the likelyhood?

> We shouldn't have calls that appear and disappear on a whim.

True... that smacks of MS policy:-)

> Binary compatibility requires that system calls be available on
> all Linux systems.

Also true. You should be able to compile the module I currently have on all
Linux systems. Unfortunately, I can't test this at the moment.

David Howells
-
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] mousedev.c

[Yoichi Imai]

Hello.

I think it's a bug.

--- linux-2.4.0-test8/drivers/input/mousedev.c Wed Aug 23 01:06:31 2000
+++ linux/drivers/input/mousedev.c  Thu Sep 21 22:20:22 2000
@@ -121,12 +121,12 @@
case BTN_TOUCH:
case BTN_LEFT:   index = 0; break;
case BTN_4:
-   case BTN_EXTRA:  if (list->mode > 1) { 
index = 4; break; }
+   case BTN_EXTRA:  if (list->mode > 1) 
+index = 4; break;
case BTN_STYLUS:
case BTN_1:
case BTN_RIGHT:  index = 1; break;
case BTN_3:
-   case BTN_SIDE:   if (list->mode > 1) { 
index = 3; break; }
+   case BTN_SIDE:   if (list->mode > 1) 
+index = 3; break;
case BTN_2:
case BTN_STYLUS2:
case BTN_MIDDLE: index = 2; break; 
 


Regards.
-- 
Yoichi Imai <[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: [RFC] Wine speedup through kernel module

[Albert D. Cahalan]

David Howells writes:
> Waldek Hebisch <[EMAIL PROTECTED]> wrote:

> I think we have a misunderstanding here... I meant that using the VFS
> structures for Win32 objects like mutexes, semaphores and events is
> massive overkill, and uses a great deal of unnecessary memory.

In spite of that, it should be considered. It allows this:

$ ls -log /proc/self/fd
total 0
lrwx--1 acahalan   64 Sep 21 09:12 0 -> /dev/pts/4
lrwx--1 acahalan   64 Sep 21 09:12 1 -> /dev/pts/4
lrwx--1 acahalan   64 Sep 21 09:12 2 -> /dev/pts/4
lrwx--1 acahalan   64 Sep 21 09:12 3 -> mutex:[720429]
lrwx--1 acahalan   64 Sep 21 09:12 4 -> event:[592]
lr-x--1 acahalan   64 Sep 21 09:12 5 -> /proc/14527/fd

Alternately, it allows this:

$ ls -log /proc/self/fd
total 0
lrwx--1 acahalan   64 Sep 21 09:12 0 -> /dev/pts/4
lrwx--1 acahalan   64 Sep 21 09:12 1 -> /dev/pts/4
lrwx--1 acahalan   64 Sep 21 09:12 2 -> /dev/pts/4
lrwx--1 acahalan   64 Sep 21 09:12 3 -> /mutex/720429
lrwx--1 acahalan   64 Sep 21 09:12 4 -> /event/592
lr-x--1 acahalan   64 Sep 21 09:12 5 -> /proc/14527/fd
$ ls -log /mutex
total 0
mrw--w1 acahalan0 Sep 21 09:33 720429
mrw--w1 acahalan0 Sep 18 19:33 2852
mrw---1 acahalan0 Sep 21 09:33 53245325
mrw--w1 acahalan0 Sep 21 09:33 88234
$ ls -log /event
total 0
erw---1 acahalan0 Sep 21 09:33 592

>>>  (3) Linux file structures do not hold enough information to support
>>>  CreateFile (access & sharing interactions).
>>
>> Any information not in kernel structure is Wine specific anyway, so
>> should be separate

It goes into the kernel structure, so that it won't be Wine-specific.
SGI has already done this so that Samba would interact properly with
regular UNIX software and the NFS server.

(one might support SGI's API for this)

> What I meant on the CreateFile() front is that this function takes
> an access bitmask and a share bitmask which interact with other
> CreateFile()'s and some other functions. For instance, if two
> separate CreateFile()'s are issued on a file then the second is
> rejected if it's share mask excludes the first's access mask or
> if the first's share mask excludes the second's access mask.

Yep, share bits definitely belong in the kernel. How else could
you properly protect against regular (clueless) Linux software?

>> However, Unix has quite a lot of mechanisms for interprocess
>> comunication: signals, shared memory, SYSV IPC semaphores and messages,
>> sockets, pipes. A lot of kernel structers and code is just to make
>> this work efficiently and relaiably. Putting in the kernel subsystem
>> which to large degree has the same functionality (but with incompatible
>> interface) seems like a recipe for disaster (small is the project
>> dies, big is it makes its way to the kernel).

We already have 3 ways to do file locking, so this is only 33% more.

> Why should it be a disaster? It can just be kept as a module
> that is loaded to accelerate Wine.

Now THAT would be a disaster. Linux software ought to be able to rely
on having these features available. Modules are very bad for this.

Look, we don't have flock() in a module.

>> However, I would rather belive that they already exists. As long
>> as I understand the main problem is Wine I/O performance. The other
>> problem is to have efficient mutexes. I expect SYSV stuff to be
>> reasonably efficient, and very fast mutexes may be implemented
>> (almost) in user space using ix86 assembly. With shared memory and
>> fast mutexes it should be possible to move I/O to client side even
>> in multithreading programs.
>
> That entails all sorts of other problems... On Win32, a lot of
> these objects are named... That means you have to have some sort
> of atomic-access name table in shared memory.

Named? That means you use the VFS.

>> I understand that Wine has good reasons to use W32 interfaces internally,
>> but pushing them to Linux kernel seems bad for me.
>
> Don't use it then... it'll not be mandatory. Wine has also to support OS's
> that can't or won't add Win32 support in the kernel.

The sendfile() call is mandatory.
The real-time schedular and signals are mandatory.
The clone() call is mandatory.
The prctl() call is mandatory.

See a pattern here? System calls are not supposed to be modular.
We shouldn't have calls that appear and disappear on a whim.
Binary compatibility requires that system calls be available on
all Linux systems.

-
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: sbpcd bug in 2.4.0...

[Jens Axboe]

On Thu, Sep 21 2000, ismael ripoll wrote:
> The problem seems to be originatied by the new block devices
> interface..  

Right

> The bug Is that in the function sbpcd_end_request
> the value of "req->q" is NULL.. and then:
> 
> list_add(>queue, >q->queue_head);  << FAILS >>

And I don't see why it should do this. It would make more sense
to just leave the current request in the queue, and let end_request
deal with dequeueing when it is done.

Could you try this patch? Completely untested and note even compiled :)

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs


--- /opt/kernel/linux-2.4.0-test9-pre5/drivers/cdrom/sbpcd.cMon Sep 11 02:49:27 
2000
+++ drivers/cdrom/sbpcd.c   Thu Sep 21 16:27:09 2000
@@ -4864,10 +4864,6 @@
  *
  */
 #undef DEBUG_GTL
-static inline void sbpcd_end_request(struct request *req, int uptodate) {
-   list_add(>queue, >q->queue_head);
-   end_request(uptodate);
-}
 /*==*/
 /*
  *  I/O request routine, called from Linux kernel.
@@ -4902,12 +4898,11 @@
 #endif
INIT_REQUEST;
req=CURRENT;/* take out our request so no other */
-   blkdev_dequeue_request(req);/* task can fuck it up GTL  */

if (req->rq_status == RQ_INACTIVE)
-   sbpcd_end_request(req, 0);
+   end_request(req, 0);
if (req -> sector == -1)
-   sbpcd_end_request(req, 0);
+   end_request(req, 0);
spin_unlock_irq(_request_lock);
 
down(_read_sem);
@@ -4949,7 +4944,7 @@
 #endif
up(_read_sem);
spin_lock_irq(_request_lock);
-   sbpcd_end_request(req, 1);
+   end_request(req, 1);
goto request_loop;
}
 
@@ -4990,7 +4985,7 @@
 #endif
up(_read_sem);
spin_lock_irq(_request_lock);
-   sbpcd_end_request(req, 1);
+   end_request(req, 1);
goto request_loop;
}
}
@@ -5006,7 +5001,7 @@
up(_read_sem);
sbp_sleep(0);/* wait a bit, try again */
spin_lock_irq(_request_lock);
-   sbpcd_end_request(req, 0);
+   end_request(req, 0);
goto request_loop;
 }
 /*==*/
@@ -5815,7 +5810,6 @@
 #endif MODULE
}
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
-   blk_queue_headactive(BLK_DEFAULT_QUEUE(MAJOR_NR), 0);
read_ahead[MAJOR_NR] = buffers * (CD_FRAMESIZE / 512);

request_region(CDo_command,4,major_name);

Re: lvm in 2.4.0-test9pre5

[Jan Niehusmann]

On Wed, Sep 20, 2000 at 08:54:55PM -0400, Mohammad A. Haque wrote:
> I think lvm and lvm-snap didn't get moved into the md dir. Or maybe the
> Makefile in md needs to be fixed.

Yes, lvm.c and lvm-snap.c are missing from drivers/md/. 
Additionally, drivers/Makefile needs to be modified: If you use lvm as a 
module, and do not use md, the md directory is not included in MOD_SUB_DIRS.
I just added 

ifeq ($(CONFIG_BLK_DEV_LVM),y)
SUB_DIRS += md
MOD_SUB_DIRS += md
else
  ifeq ($(CONFIG_BLK_DEV_LVM),m)
  MOD_SUB_DIRS += md
  endif
endif

and now lvm works again. I don't know if this is correct if both md and lvm
are used, as then MOD_SUB_DIRS will contain 'md' twice. 

Jan

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

sbpcd bug in 2.4.0...

[ismael ripoll]

Hi!
I have an old PC Pentium 100 with a CDROM x2 
The CD driver used to work with: 

modprobe sbpcd sbpcd=0x340,0

It works fine with all version of Linux but 2.3.?? and
above. Version 2.4.0-test5 also fails.

I've tried to solve the bug... but no way.

The module gets loaded smoothly, and detects the real hardware.
The problem arises the firt (or the second) time the function 
sbpcd_end_request is called.
This occurs whe I try to "mount".

The problem seems to be originatied by the new block devices
interface..  

The bug Is that in the function sbpcd_end_request
the value of "req->q" is NULL.. and then:

list_add(>queue, >q->queue_head);  << FAILS >>


I have managed to mount the unit by changing "req->q"
by the value of of "q" received by función:
static void DO_SBPCD_REQUEST(request_queue_t * q)


Here is that I did:

static inline void sbpcd_end_request(struct request *req,
request_queue_t * q, int uptodate) {
list_add(>queue, >queue_head);
end_request(uptodate);
}  

And the call to this function is 
>>> Code from funcion DO_SBPCD_REQUEST 
 .
if (req->rq_status == RQ_INACTIVE)
sbpcd_end_request(req, q, 0);
if (req -> sector == -1)
sbpcd_end_request(req, q, 0);
spin_unlock_irq(_request_lock);  
..


The problem now is that after a while the system gets 
unstable and the kernel tries to "free unallocated pages"
or something like that. I don't remember the message.


Another test I did was to return inmediately from the 
DO_SBPCD_REQUEST function... And even in this prety simple
code, the system hanged ¿May be the cdrom.c code is broken ?


Please answer this mail. It is the second time I mail it to you.

Regards.



-- 
Ismael Ripoll: Universitat Politecnica de Valencia;46071 Valencia,Spain
Tel: +34 96 3879 577  Fax: +34 96 3877 579
mailto:[EMAIL PROTECTED] http://bernia.disca.upv.es/~iripoll
---
In an open world without walls and fences who needs Windows and Gates? 
-
-
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/