Re: 2.4.0-test5 bug: invalid "shmid_kernel" passed to "shm_nopage_core"

[Kevin Buhr]

Christoph Rohland <[EMAIL PROTECTED]> writes:
> 
> This is the first report of such corruption. If it's real it is _not_
> fixed between test5 and test11. There is probably no way to reproduce
> it since you ask if it's fixed in test11, right?

I know no way to reproduce it.  I've been using "test5" reliably since
just after its release, and I've triggered this bug only the one time.

I was running Mozilla, one of the few programs I run that uses shared
memory to communicate with the X server.  If I recall correctly, the
machine had been idle for a few minutes when my ISP suddenly hung up
on me.  Then, I discovered the machine had locked: CPU1 running "pppd"
got stuck waiting for the kernel lock in "sock_ioctl".  I believe it
was the innocent victim.  CPU0 (running "XF86_SVGA") had grabbed the
kernel lock and gotten stuck spinning on the invalid swap device
spinlock, as mentioned in my previous message.

I use a SysReq patch to do an oops-style dump instead of the usual
"showPc" function, so I was able to copy a stack dump down.

>From the stack dump, I can be 100% positive that, in shm_nopage_core,
"shp" was 0xc218b240 on entry and "idx" was 0, but the line

pte = SHM_ENTRY(shp,idx);

calculated a value of 0xc218b268, the memory location of
"shp->shm_dir".  That is, I had shp->shm_dir == **shp->shm_dir, so I
*suspect* that that shp->shm_dir == *shp->shm_dir.

In any event, the "shp" was corrupt (hadn't been initialized or had
been freed and reused).

I'll fiddle around a bit more and see if I can find a way to reproduce
it reliably.

Thanks.

Kevin <[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: difference between kernel and bios report on drive status

[Andre Hedrick]

It is a standards bug that your drives are mixed in the rev.
Adjust the IVB option so that it does not care about these bits just the
presence of either set.

Cheers,


On Sun, 26 Nov 2000 [EMAIL PROTECTED] wrote:

> Hi there:  
> 
> I am using PROMISE ultra100 with 2 UDMA66 disks. The PROMIS
> bios reports that both disks are using UDMA 4. But during kernel boot On
> Fri, 24 Nov 2000, Szabolcs Szakacsits wrote: up, the master disk is using
> UDMA 2 only. The reason is that master disk's pci->dma_ultra value is only
> 0x40f. I hacked the kernel a bit, both hard disk using hardware configued
> udma_four though. So I am wondering why not use udma_four as mode
> indication? Anyone here knows or
>  I have to email Andre on this?
> 
> By the way, mode4 works much faster.(hdparm -tT):
> disk1: udma33, mode2, disk buffer read 14MB/s
> disk2: udma66, mode4, disk buffer read 24MB/s
> 
> both disks: buffer-cache read 88MB/s
> 
> The second disk is only 5400RPM, the first one is 7200RPM. Both comply > >
> HOW? to UDMA66. How come the 2nd one is UDMA66, but the first one is > > >
> No performance loss, RAM is always fully utilized (except if no swap),
> UDMA33? And how come the 2nd is faster than the first one. 
> 
> I hope this is not a kernel bug.
> 
> Fei
> 

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

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

Patch: 2.4.0-test11ac4 version of pci and isapnp device ID's patch

[Adam J. Richter]

For those of you playing with Alan Cox's linux-2.4.0-test11ac4
release, I have made a separate patch of the remaining device ID
changes which patches against that kernel and builds cleanly (the
primary difference is that it omits the files that have gained the
same ID tables in Alan's ac4 release).  The patch is FTPable from:

ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_tables-2.4.0-test11-ac4.patch4.gz
 

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
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/

difference between kernel and bios report on drive status

[afei]

Hi there:  

I am using PROMISE ultra100 with 2 UDMA66 disks. The PROMIS
bios reports that both disks are using UDMA 4. But during kernel boot On
Fri, 24 Nov 2000, Szabolcs Szakacsits wrote: up, the master disk is using
UDMA 2 only. The reason is that master disk's pci->dma_ultra value is only
0x40f. I hacked the kernel a bit, both hard disk using hardware configued
udma_four though. So I am wondering why not use udma_four as mode
indication? Anyone here knows or
 I have to email Andre on this?

By the way, mode4 works much faster.(hdparm -tT):
disk1: udma33, mode2, disk buffer read 14MB/s
disk2: udma66, mode4, disk buffer read 24MB/s

both disks: buffer-cache read 88MB/s

The second disk is only 5400RPM, the first one is 7200RPM. Both comply > >
HOW? to UDMA66. How come the 2nd one is UDMA66, but the first one is > > >
No performance loss, RAM is always fully utilized (except if no swap),
UDMA33? And how come the 2nd is faster than the first one. 

I hope this is not a kernel bug.

Fei

-
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: linux-2.4.0-test11ac4/drivers/net/tokenring/{tmspci,abyss}.c __devinit fixes

[Adam J. Richter]

Hooray!  I see that Alan has included a port of the
drivers/net/tokenring/{tmspci,abyss}.c to the new PCI interface,
presumably by Adam Fritzler.

This patch correct some minor errors where __devinit{,data}
should be used instead of __init{,data} so the driver does not
make illegal memory references in a hot plugging event.  Even if
there is currently no hot pluggable version of these cards, I believe
the scenario would occur if you were to plug a notebook into
a PCI docking station that supports hot docking and had one of these
cards plugged in.  So, the scenario can happen.  I also added
__devinit to the eeprom reading routines, which are only called
by another __devinit routine.

I hope this patch will be applied both to the development
version of the driver and, ideally, to Alan's tree, and really ideally,
propagated to Linus with the rest of Adam Fritzler's port.

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


diff -u -r linux-2.4.0-test11-ac4/drivers/net/tokenring/tmspci.c 
linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/tmspci.c
--- linux-2.4.0-test11-ac4/drivers/net/tokenring/tmspci.c   Sat Nov 25 21:15:17 
2000
+++ linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/tmspci.cSat Nov 25 
+21:51:49 2000
@@ -41,7 +41,7 @@
 #include 
 #include "tms380tr.h"
 
-static char version[] __initdata =
+static char version[] __devinitdata =
 "tmspci.c: v1.02 23/11/2000 by Adam Fritzler\n";
 
 #define TMS_PCI_IO_EXTENT 32
@@ -58,7 +58,7 @@
{ {0x03, 0x01}, "3Com Token Link Velocity"},
 };
 
-static struct pci_device_id tmspci_pci_tbl[] __initdata = {
+static struct pci_device_id tmspci_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TOKENRING, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0 },
{ PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_TR, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 1 },
{ PCI_VENDOR_ID_TCONRAD, PCI_DEVICE_ID_TCONRAD_TOKENRING, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 2 },
@@ -67,7 +67,7 @@
 };
 MODULE_DEVICE_TABLE(pci, tmspci_pci_tbl);
 
-static void tms_pci_read_eeprom(struct net_device *dev);
+static void __devinit tms_pci_read_eeprom(struct net_device *dev);
 static unsigned short tms_pci_setnselout_pins(struct net_device *dev);
 
 static unsigned short tms_pci_sifreadb(struct net_device *dev, unsigned short reg)
@@ -90,7 +90,7 @@
outw(val, dev->base_addr + reg);
 }
 
-static int __init tms_pci_attach(struct pci_dev *pdev, const struct pci_device_id 
*ent)
+static int __devinit tms_pci_attach(struct pci_dev *pdev, const struct pci_device_id 
+*ent)
 {  
static int versionprinted;
struct net_device *dev;
@@ -192,7 +192,7 @@
  * machine hard when this is called.  Luckily, its supported in a
  * seperate driver.  --ASF
  */
-static void tms_pci_read_eeprom(struct net_device *dev)
+static void __devinit tms_pci_read_eeprom(struct net_device *dev)
 {
int i;

@@ -219,7 +219,7 @@
return val;
 }
 
-static void __exit tms_pci_detach (struct pci_dev *pdev)
+static void __devexit tms_pci_detach (struct pci_dev *pdev)
 {
struct net_device *dev = pci_get_drvdata(pdev);
 
diff -u -r linux-2.4.0-test11-ac4/drivers/net/tokenring/abyss.c 
linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/abyss.c
--- linux-2.4.0-test11-ac4/drivers/net/tokenring/abyss.cSat Nov 25 21:15:17 
2000
+++ linux-2.4.0-test11-ac4.hacked/drivers/net/tokenring/abyss.c Sat Nov 25 21:52:49 
+2000
@@ -41,12 +41,12 @@
 #include "tms380tr.h"
 #include "abyss.h"/* Madge-specific constants */
 
-static char version[] __initdata =
+static char version[] __devinitdata =
 "abyss.c: v1.02 23/11/2000 by Adam Fritzler\n";
 
 #define ABYSS_IO_EXTENT 64
 
-static struct pci_device_id abyss_pci_tbl[] __initdata = {
+static struct pci_device_id abyss_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_MADGE, PCI_DEVICE_ID_MADGE_MK2,
  PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_NETWORK_TOKEN_RING << 8, 0x00ff, },
{ } /* Terminating entry */
@@ -91,7 +91,7 @@
outw(val, dev->base_addr + reg);
 }
 
-static int __init abyss_attach(struct pci_dev *pdev, const struct pci_device_id *ent)
+static int __devinit abyss_attach(struct pci_dev *pdev, const struct pci_device_id 
+*ent)
 {  
static int versionprinted;
struct net_device *dev;
@@ -390,7 +390,7 @@
  * Read configuration data from the AT24 SEEPROM on Madge cards.
  *
  */
-static void abyss_read_eeprom(struct net_device *dev)
+static void __devinit abyss_read_eeprom(struct net_device *dev)
 {
struct net_local *tp;
unsigned long ioaddr;
@@ -432,7 +432,7 @@
return 0;
 }
 
-static void __exit abyss_detach (struct pci_dev *pdev)
+static void __

Re: [PATCH] removal of "static foo = 0"

[Andre Hedrick]

On Sun, 26 Nov 2000, Keith Owens wrote:

> >Are you positive for modules too...
> 
> Yes.

I know this, I am being punchy.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

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

Re: [PATCH] removal of "static foo = 0"

[Keith Owens]

On Sat, 25 Nov 2000 21:10:19 -0800 (PST), 
Andre Hedrick <[EMAIL PROTECTED]> wrote:
>On Sun, 26 Nov 2000, John Alvord wrote:
>> It also says "I do not know much about the details of the kernel C
>> environment. In particular I do not know that all static variables are
>> initialized to 0 in the kernel startup. I have not read setup.S."
>
>Are you positive for modules too...

Yes.

-
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] removal of "static foo = 0"

[Werner Almesberger]

Andries Brouwer wrote:
> On Sat, Nov 25, 2000 at 10:27:15PM +, Tigran Aivazian wrote:

I think it's a bad sign if people like the two of you start flaming
each other ...

On the issue of  static int foo = 0;  vs.  static int foo;  I'd agree
with Andries' view. It's a common enough idiom that it is useful to
convey the intentions of the programmer.

On "optimizing" changes: there are plenty of very ugly things you can
do to a C program to make source or object code smaller (e.g. use only
one-character identifiers for smaller code; re-use variables as much
as possible, maybe with casts for smaller stack footprint, etc.). We
usually avoid these too, so a few extra initializations in the source
shouldn't hurt.

On the .data segment size: if all the energy that went into this
thread would have gone into implementing a gcc option to move all-zero
.data objects to .bss, the technical side of the problem would be
solved already ;-)

> Does the kernel contain a bug? Panic!  I don't think my alpha would
> have gotten an uptime of 1198 days under that paradigm.
> (I don't think you were serious, but still..)

Hmm, sometimes a panic _is_ the right answer, though. If a critical
subsystem just politely returns an error to user space and tries to
continue, it may take a while until somebody realizes that there's
something wrong at all ...

- Werner

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
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] removal of "static foo = 0"

[Andre Hedrick]

On Sun, 26 Nov 2000, John Alvord wrote:

> On Sun, 26 Nov 2000 04:25:05 + (GMT), Alan Cox
> <[EMAIL PROTECTED]> wrote:
> 
> >>  AB> of changes that yield a negligable advantage and reduce stability
> >>  AB> a tiny little bit. That is pushing Linux in the direction of this
> >>  AB> abyss. You notice that the view gets better, and I get nervous.
> >> 
> >> Can somebody stop this train load of bunk?
> >> 
> >> Uninitialized global variables always have a initial value of
> >> zero.  Static or otherwise.  Period.
> >
> >That isnt what Andries is arguing about. Read harder. Its semantic differences
> >rather than code differences.
> >
> > static int a=0;
> >
> >says 'I thought about this. I want it to start at zero. I've written it this
> >way to remind of the fact'
> >
> >Sure it generates the same code
> 
> It also says "I do not know much about the details of the kernel C
> environment. In particular I do not know that all static variables are
> initialized to 0 in the kernel startup. I have not read setup.S."

Are you positive for modules too...

Regardless of the fact you have displayed, some of us prefer to clobber it
to insure that it stays zero until access.  Last thing you want is an
unstatic static when we go to spin a disk for data.

Just how warm and fuzzy do you fell if your block drivers do not insure
this point?

Cheers,

Andre Hedrick
Linux ATA Development

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

Re: [PATCH] removal of "static foo = 0"

[John Alvord]

On Sun, 26 Nov 2000 04:25:05 + (GMT), Alan Cox
<[EMAIL PROTECTED]> wrote:

>>  AB> of changes that yield a negligable advantage and reduce stability
>>  AB> a tiny little bit. That is pushing Linux in the direction of this
>>  AB> abyss. You notice that the view gets better, and I get nervous.
>> 
>> Can somebody stop this train load of bunk?
>> 
>> Uninitialized global variables always have a initial value of
>> zero.  Static or otherwise.  Period.
>
>That isnt what Andries is arguing about. Read harder. Its semantic differences
>rather than code differences.
>
>   static int a=0;
>
>says 'I thought about this. I want it to start at zero. I've written it this
>way to remind of the fact'
>
>Sure it generates the same code

It also says "I do not know much about the details of the kernel C
environment. In particular I do not know that all static variables are
initialized to 0 in the kernel startup. I have not read setup.S."

john alvord
-
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] removal of "static foo = 0"

[Alan Cox]

>  AB> of changes that yield a negligable advantage and reduce stability
>  AB> a tiny little bit. That is pushing Linux in the direction of this
>  AB> abyss. You notice that the view gets better, and I get nervous.
> 
> Can somebody stop this train load of bunk?
> 
> Uninitialized global variables always have a initial value of
> zero.  Static or otherwise.  Period.

That isnt what Andries is arguing about. Read harder. Its semantic differences
rather than code differences.

static int a=0;

says 'I thought about this. I want it to start at zero. I've written it this
way to remind of the fact'

Sure it generates the same code

-
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] removal of "static foo = 0"

[James A Sutherland]

On Sat, 25 Nov 2000, Tim Waugh wrote:
> 
> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
> 
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
> 
> Why doesn't the compiler just leave out explicit zeros from the
> 'initial data' segment then?  Seems like it ought to be tought to..

Good idea; unfortunately, it's probably too kernel-specific, so gcc may not
want to include this change. Also, the kernel is gcc version-specific; even if
this feature were automated in gcc now, it could take some time before the
kernel could safely be built under that version. Better to optimise the source
code to avoid the problem, rather than change the compiler to kludge around it.


James.
-
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_card_id tables for all isapnp drivers in 2.4.0-test11

[Adam J. Richter]

>   == Kai Germaschewski
>>  == Keith Owens  
>>> == Adam Richter

>>> [...] I plan to go
>>>through all of the changes and bracket all of these new tables
>>>with #ifdef MODULE...#endif so they do not result in complaints
>>>about the table being defined static and never used in cases where
>>>the driver is compiled directly into the kernel.

(I have now done this and release the patch at
ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/.)


>> This is cleaner.  Append MODULE_ONLY after __initdata and remove the
>> ifdef.  It increases the size of initdata in the kernel, compared to
>> ifdef, but since initdata is promptly reused as scratch space it should
>> not be a problem.
[...]
>> +#define MODULE_ONLY __attribute__ ((unused))

>What about the making MODULE_DEVICE_TABLE reference this table? This has
>the same disadvantage (i.e. having a little unneeded __initdata in the
>kernel image), but it wouldn't need the rather ugly MODULE_ONLY macro.

>I'ld suggest something like this in module.h, #ifndef MODULE part:

>#define MODULE_DEVICE_TABLE(type,name) \
>static struct type##_device_id *__dummy_##name \
>   __attribute__ ((unused, __section__(".text.exit"))) \
>   = name;

I did not realize that this thread had been posted to
linux-kernel.  Here is a response that I emailed to Keith Owens
and Kai Germaschewski that explains my reasons for sticking with
#ifndef MODULE...#endif rather than creating a new kernel facility
for something that, by the way, should become completely unused in
the next couple of months after 2.4.0 is released and the device
drivers are converted to the new PCI and isapnp interfaces:

|From: "Adam J. Richter" <[EMAIL PROTECTED]>
|To: [EMAIL PROTECTED]
|
|Thanks for the patch, but I think I'll stick with the ifdefs
|for now, for the following reasons.
|
|1. I think ifdef MODULE is more understandable to the casual observer.
|2. There is often some other condition that I need to combine
|   with (CONFIG_PCI, CONFIG_ISAPNP, CONFIG_ISAPNP_MODULE).
|3. There is often an existing ifdef in the right place that I
|   can just tuck the code into.
|4. I would prefer that this change not have even a file size cost
|   to people who want to build minimal monolithic kernels
|   for applicance applications.
|5. My feeling is that just the few kilobytes of file size cost
|   associated with #4 and knowing that absolutely nothing is
|   added for non-module usage will psychologically make
|   maintainers feel better about it and have even fewer misgivings
|   about integrating it.
|6. We can expect the lines bracketing these table declarations
|   to be changed in the near future as the drivers are changed
|   to use the new PCI and isapnp interfaces or to use the ID
|   tables just to eliminate the old custom data structures that
|   hold the same information.
|
|Thanks for the patch anyhow, though.  It's a clever idea that
|may be useful in other situations.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
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/

test11-ac4, APM & Dell 5000e

[ttsig]

Hi all,

Thanks for the workaround on the Dell 5000e APM problems.

However, there does seem to be a small typo in the patch.  The
comments state that the A04 BIOS dates 08/24/2000 is known defective,
but the code itself is looking for 08/04/2000.

With this small fix it actually "Works for Me" (well, minus the power
status stuff of course) but at least I get real working suspend/resume.

Later,
Tom

-
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] promise controller and QUANTUM FIREBALLlct10 30

[Friedrich Lobenstock]

Hi Andre!

I had to apply this patch to be able to get my system starting up
because the PDC driver would look the system without it.

If I remember correctly the system would hang after the last line shown.
hda: QUANTUM FIREBALLlct10 10, ATA DISK drive
hdc: QUANTUM FIREBALLlct10 10, ATA DISK drive
hde: QUANTUM FIREBALLlct10 30, ATA DISK drive   (on PDC 20262 !)
hdg: QUANTUM FIREBALLlct10 30, ATA DISK drive(on PDC 20262 !)
[..]
hda: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63, UDMA(33)
hdc: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63, UDMA(33)
hde: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(66)
hdg: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(66)


--- linux/drivers/ide/pdc202xx.c~   Fri Jul 28 21:08:30 2000
+++ linux/drivers/ide/pdc202xx.cSat Nov 25 20:18:51 2000
@@ -222,6 +222,7 @@

 const char *pdc_quirk_drives[] = {
"QUANTUM FIREBALLlct08 08",
+   "QUANTUM FIREBALLlct10 30",
"QUANTUM FIREBALLP KA6.4",
"QUANTUM FIREBALLP LM20.4",
"QUANTUM FIREBALLP LM20.5",

PS: Please CC me because I'm not on linux-kernel.
 
MfG / Regards
Friedrich Lobenstock
-
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/

[BUG] 2.4.0-test11-ac3 breaks raid autodetect (was Re: [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup))

[Friedrich Lobenstock]

Neil Brown wrote:
>
> The following patch changes the link order in the Makefile so that xor
> is initiailised before md tries to autostart anything.
> It also takes the theme a bit further and uses module_init/module_exit
> to init and shutdown the raid personalities.  This allows us to remove
> the explicit calls to raidXX_init from md.c, which is nice.
> 
> I have tested this patch both
>1/ monolithic kernel and autodetecting an array
>2/ md and all personalities modules
> 
> and it works fine.

Sorry to tell you that I just tried linux-2.4.0-test11-ac3 (which has this
patch) and I couldn't boot because the kernel detects the raid1 devices
but kicks the shortly after. I had to back out this code.

Here how the messages look like:

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xa400-0xa407,0xa002 on irq 9
hda: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63, UDMA(33)
hdc: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63, UDMA(33)
hde: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(66)
Partition check:
 hda: hda1 hda2
 hdc: hdc1 hdc2 hdc3
 hde: hde1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
LVM version 0.8final  by Heinz Mauelshagen  (15/02/2000)
lvm -- Driver successfully initialized
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 640k freed
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
md.c: sizeof(mdp_super_t) = 4096
autodetecting RAID arrays
(read) hda1's sb offset: 51264 [events: 0056]
(read) hda2's sb offset: 9970560 [events: 0051]
(read) hde1's sb offset: 29316544 [events: 0080]
autorun ...
considering hde1 ...
  adding hde1 ...
created md2
bind
running: 
now!
hde1's event counter: 0080
md: device name has changed from [dev 22:01] to hde1 since last import!
md2: former device hde1 is unavailable, removing from array!
request_module[md-personality-3]: Root fs not mounted
do_md_run() returned -22
md2 stopped.
unbind
export_rdev(hde1)
considering hda2 ...
  adding hda2 ...
created md1
bind
running: 
now!
hda2's event counter: 0051
md1: former device hdc2 is unavailable, removing from array!
request_module[md-personality-3]: Root fs not mounted
do_md_run() returned -22
md1 stopped.
unbind
export_rdev(hda2)
considering hda1 ...
  adding hda1 ...
created md0
bind
running: 
now!
hda1's event counter: 0056
md0: former device hdc1 is unavailable, removing from array!
request_module[md-personality-3]: Root fs not mounted
do_md_run() returned -22
md0 stopped.
unbind
export_rdev(hda1)
... autorun DONE.
raid1 personality registered
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem).
VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=3


MfG / Regards
Friedrich Lobenstock
-
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] removal of "static foo = 0"

[Georg Nikodym]

> "AB" == Andries Brouwer <[EMAIL PROTECTED]> writes:

 AB> No insult intended.  It is just that if there is an abyss
 AB> somewhere, I like to stay at least a meter away from it. Someone
 AB> else may think that one inch suffices.  I see you propose a lot
 AB> of changes that yield a negligable advantage and reduce stability
 AB> a tiny little bit. That is pushing Linux in the direction of this
 AB> abyss. You notice that the view gets better, and I get nervous.

Can somebody stop this train load of bunk?

Uninitialized global variables always have a initial value of
zero.  Static or otherwise.  Period.

Anybody with more than a week's experience programming knows this.
It's idiomatic.  Just as in English one says, "Go away!" knowing that
"You", the implied subject of the imperative sentence, will be
understood.

Andries, please devote your impressive energy to fixing _real_ bugs.
This kind of argument is best left until we're _really_ low on other
things to do.
-
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] removal of "static foo = 0"

[Andries Brouwer]

On Sat, Nov 25, 2000 at 06:02:51PM -0500, Jeff Garzik wrote:
> Andries Brouwer wrote:
> > In a program source there is information for the compiler
> > and information for the future me. Removing the " = 0"
> > is like removing comments. For the compiler the information
> > remains the same. For the programmer something is lost.
> 
> This is pretty much personal opinion :)
> 
> The C language is full of implicit as well as explicit features.  You
> are arguing that using an implicit feature robs the programmer of
> information.  For you maybe...  For others, no information is lost AND
> the code is more clean AND the kernel is smaller.  It's just a matter of
> knowing and internalizing "the rules" in your head.

Oh Jeff,

All these really good people, unable to capture a simple idea.
Let me try one more time.
There is information. The information is:
"this variable needs initialization"
Now you tell me to know simple rules. OK, I know them.
But what do they tell me about my variables a and b, where
a requires initialization and b does not require it?

One can write a comment, like

int a;  /* this variable needs initialization, fortunately
   it is already initialized at startup */
int b;  /* no initialization required */

But that is overdoing it, it uglifies the code.
One can leave the comment out, like

int a, b;

But then next month, when you decide to move this into
some function

int foo() {
int a, b;
...

there is no indication that you need an additional

a = 0;

You see?
There is real information here. Useful as a reminder.
Not necessary. The perfect programmer would see
immediately that the assignment is required, also
without the reminder. But not everybody is perfect
all of the time, and sometimes the code involved is
quite complicated. The tiny convention
"write an explicit initialization when initialization is needed"
is helpful. It is a form of program documentation.

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: [PATCH] removal of "static foo = 0"

[Andries Brouwer]

On Sat, Nov 25, 2000 at 10:27:15PM +, Tigran Aivazian wrote:
: Hello Andries,

Hi Tigran,

: ... I am quite free to _rely_ on this fact and will possibly do so.

Yes, you are. But some programmers have learned that it is a good
idea to code in a way that is informative to the programmer.

: > Tigran, you like to destabilize Linux.
: 
: Oh, Andries, that is insulting. Surely you do not really mean that.

No insult intended.
It is just that if there is an abyss somewhere, I like to stay at least
a meter away from it. Someone else may think that one inch suffices.
I see you propose a lot of changes that yield a negligable advantage
and reduce stability a tiny little bit. That is pushing Linux in the
direction of this abyss. You notice that the view gets better, and I
get nervous.

You seem to have these strange ideas. I quoted you

: It is better for code to be smaller than to be slightly more fool-proof.

Here is a different one:

: I think that the check for inode->i_op == NULL in various vfs_XXX()
: functions is bogus, i.e. if it is NULL then it must be a bug in
: some filesystem's ->read_inode() method and therefore, instead of
: returning error to userspace we should immediately panic, since
: it is a kernel bug.

Does the kernel contain a bug? Panic!  I don't think my alpha would
have gotten an uptime of 1198 days under that paradigm.
(I don't think you were serious, but still..)

  [I am not so sure why i_op == NULL necessarily is a bug.
  Sometimes a routine invents a dummy inode just because it is needed
  in some calling convention, while nothing of this inode is used
  except for example i_rdev. Maybe it does not occur today, in the
  filesystems in the 2.4 kernel tree. But such checks: test i_op,
  then test i_op->function, then call i_op->function() ensure
  a local correctness. That is what I like.
  Reading all filesystems in the kernel tree is what I don't like.
  And there are many filesystems not in the kernel tree.]

This is not to debate this particular case - it is Al's business.
This is just an example where you want to sacrifice local correctness
and be satisfied with global correctness.

: "sense of measure"

Yes, well formulated!

But this was a communication to linux-kernel, not an attack.
It was meant to say two things, namely
(i) Source code is a communication to programmers and to the compiler.
It is a bad idea to optimize the communication towards the compiler
when that is detrimental to the communication towards programmers.
And (ii) locally correct code is more stable than code that is only
globally correct.

For me these are truisms, but when Rusty complained about loss of
information lots of people did not seem to understand what could be meant.
I took you as my victim because you always seem to take the point
of view that the code must be perfect, never mind the programmers,
and that it is a good idea to save a few instructions, never mind
local correctness. (And also because your old remark quoted above
still required a reaction.)

No offense intended.

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/

2.4.0-test11 af_packet/tcpdump/routing bug?

[Frank van Maarseveen]

The tcpdump program (tcpdump -p -i ppp1 -s 1500 not port login) will
not report any packets after adding a default route to eth0 in the setup
below. The packet generating command is ping 192.168.2.42

It has been verified at the ppp1 peer that packets really arrive there via
ppp. Tcpdumping eth0 locally also confirms that packets don't go via eth0.

After adding/deleting the default route tcpdump needs to be restarted
to notice the difference. It uses the af_packet kernel module and maybe
its usage count must drop to zero temporarily to make a difference (I
don't know).

iapetus ~# route 
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
192.168.2.42*   255.255.255.255 UH0  00 ppp1
192.168.0.39*   255.255.255.255 UH0  00 eth0
192.168.2.0 *   255.255.255.0   U 0  00 eth0
localnet*   255.255.255.0   U 0  00 eth0
loopback*   255.0.0.0   U 0  00 lo
iapetus ~# ifconfig
eth0  Link encap:Ethernet  HWaddr 00:50:04:21:99:04  
  inet addr:192.168.0.39  Bcast:192.168.0.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:34216 errors:0 dropped:0 overruns:0 frame:0
  TX packets:52668 errors:0 dropped:0 overruns:0 carrier:5
  collisions:117 txqueuelen:100 
  Interrupt:10 Base address:0x300 

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16144  Metric:1
  RX packets:16037 errors:0 dropped:0 overruns:0 frame:0
  TX packets:16037 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 

ppp1  Link encap:Point-to-Point Protocol  
  inet addr:192.168.2.201  P-t-P:192.168.2.42  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:331 errors:0 dropped:0 overruns:0 frame:0
  TX packets:330 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:3 

Adding a default route:
iapetus ~# route add default dev eth0
iapetus ~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
192.168.2.42*   255.255.255.255 UH0  00 ppp1
192.168.0.39*   255.255.255.255 UH0  00 eth0
192.168.2.0 *   255.255.255.0   U 0  00 eth0
localnet*   255.255.255.0   U 0  00 eth0
loopback*   255.0.0.0   U 0  00 lo
default *   0.0.0.0 U 0  00 eth0

-- 
Frank
-
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.0-test11: Trying to free nonexistent resource <000003e0-000003e1>

[Frank van Maarseveen]

While shutting down, /var/log/messages said:
Nov 25 23:15:12 mimas cardmgr[342]: exiting
Nov 25 23:15:14 mimas kernel: Trying to free nonexistent resource <03e0-03e1> 
Nov 25 23:15:14 mimas kernel: unloading PCMCIA Card Services 

mimas /proc# cat ioports 
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0300-030f : 3c589_cs
03c0-03df : vga+
03e0-03e1 : i82365
03e8-03ef : serial(auto)
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1

mimas /proc# cat modules 
af_packet   9232   0 (autoclean)
ppp_deflate41056   2 (autoclean)
bsd_comp4224   0 (autoclean)
ppp_async   6800   1 (autoclean)
ppp_generic15328   3 (autoclean) [ppp_deflate bsd_comp ppp_async]
3c589_cs8112   1
ds  6864   2 [3c589_cs]
i82365 12672   2
pcmcia_core40256   0 [3c589_cs ds i82365]

Think it's not relevant but just in case: the RH6.1 cardmgr is
being used though linux/Documentation/Changes says it should be
upgraded for this kernel. kernel is SMP but there's only 1 CPU.

-- 
Frank
-
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] removal of "static foo = 0" from drivers/ide (test11)

[Bartlomiej Zolnierkiewicz]

On Thu, 23 Nov 2000, Rusty Russell wrote:

> In message <[EMAIL PROTECTED]> you write:
> > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > > > 
> > > > Quick removal of unnecessary initialization to 0.
> > 
> > Quite the contrary. The patch seems correct and useful to me. What do you
> > think is wrong with it? (Linus accepted megabytes worth of the above in
> > the past...)
>
> What irritates about these monkey-see-monkey-do patches is that if I
> initialize a variable to NULL, it's because my code actually relies on
> it; I don't want that information eliminated.
 
What irritates about these monkey-do-not-read-monkey-write e-mails
is that I know what I am doing :) My patch removed *REALLY* unnecessary
initialization, no code depended on beginning value so don't quote
my words...

--
Bartlomiej Zolnierkiewicz
<[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] removal of "static foo = 0"

[Tim Waugh]

On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:

> Which is silly. The variable is explicitly defined to be zero
> anyway, whether you put this in your code or not.

Why doesn't the compiler just leave out explicit zeros from the
'initial data' segment then?  Seems like it ought to be tought to..

Tim.
*/

 PGP signature

Re: [PATCH] G450 support for matroxfb

[Petr Vandrovec]

On Sat, Nov 25, 2000 at 04:36:50PM +0100, Willy Tarreau wrote:
> > BTW, XF4.0.1e is also very unhappy on this hardware.
> > Best regards,
> > Petr Vandrovec
> > [EMAIL PROTECTED]
> 
> does the Matrox driver work with it ? My G400 works very well with the one I
> found on this site, and the G450 is also referenced :
> 
> http://www.matrox.com/mga/support/drivers/latest/home.htm

If you are talking about Matrox's few source + large BLOB driver, I have
no idea. I do not use binary-only drivers if I do not have to...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]

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

Re: PROBLEM: crashing kernels

[Andrew Morton]

Nice report.  Wish they were all like that.

Look:

"Mr. Big" wrote:
> 
> I thought that the khttpd is guilty, I won't use it anymore. Next morning
> it crashed again, now without khttpd, without high load, without high
> memory usage, just the 3Com driver said:
> kernel: eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
^^

This is caused by the APIC(s) forgetting how to deliver interrupts
for a particular IRQ.  Normally, reloading the driver doesn't help.
But in your case it did.  This is odd.

It looks like the same thing is happening with the eepro NIC as
well.  But the eepro diagnostics aren't as informative when this
happens.

This can normally be prevented by booting with the `noapic' option
on the LILO command line.

So I suggest you stick with the 3c905C and boot with `noapic'.  Try
the eepro as well - it may well work fine with the APIC disabled.

You may also get some benefit from running:

# echo "512 1024 1536" > /proc/sys/vm/freepages

after booting.  The default values are a little too low for
applications which are very network intensive.
-
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: Questions about Kernel 2.4.0.?

[Keith Owens]

On Sat, 25 Nov 2000 14:20:39 -0800, 
"Android" <[EMAIL PROTECTED]> wrote:
>There is a link in /lib/modules/2.4.0.11: build->/usr/src/linux
>created by the Makefile (make modules_install).
>What for? depmod doesn't like this link. It gets confused.

grep modutils Documentation/Changes

-
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] removal of "static foo = 0"

[Herbert Xu]

On Sat, Nov 25, 2000 at 11:46:24PM +0100, Andries Brouwer wrote:
> 
> But if the program
> 
>   static int a = 0;
> 
>   int main() {
> /* do something */
>   }
> 
> is used as part of a larger program, it has to become
> 
>   static int a;
> 
>   int do_something() {
> a = 0;
> ...
>   }

Only if the person doing the change follows this convention, if that happens
to be you, not a problem.  But in a project like Linux, it's not very likely
to happen.

It's much better to put a comment above the definition.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.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: [PATCH] removal of "static foo = 0"

[Jeff Garzik]

Andries Brouwer wrote:
> In a program source there is information for the compiler
> and information for the future me. Removing the " = 0"
> is like removing comments. For the compiler the information
> remains the same. For the programmer something is lost.

This is pretty much personal opinion :)

The C language is full of implicit as well as explicit features.  You
are arguing that using an implicit feature robs the programmer of
information.  For you maybe...  For others, no information is lost AND
the code is more clean AND the kernel is smaller.  It's just a matter of
knowing and internalizing "the rules" in your head.

Jeff


-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
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] removal of "static foo = 0"

[James A Sutherland]

On Sat, 25 Nov 2000, Andries Brouwer wrote:
> On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:
> 
> > No information is lost.
> 
> Do I explain things so badly? Let me try again.
> The difference between
> 
>   static int a;
> 
> and
> 
>   static int a = 0;
> 
> is the " = 0". The compiler may well generate the same code,

It does not. That's the whole point: the (functionally redundant) =0 wastes
another sizeof(int) bytes in the kernel image.

> but I am not talking about the compiler. I am talking about
> the programmer. This " = 0" means (to me, the programmer)
> that the correctness of my program depends on this initialization.

If you want to document your code like this, put it in a comment. That's what
they are there for. Or, if coding a function which explicitly relies on a
variable being 0, have that function set the variable to zero.

> Its absense means (to me) that it does not matter what initial
> value the variable has.

Which is silly. The variable is explicitly defined to be zero anyway, whether
you put this in your code or not.

> This is a useful distinction. It means that if the program
> 
>   static int a;
> 
>   int main() {
> /* do something */
>   }
> 
> is used as part of a larger program, I can just rename main
> and get
> 
>   static int a;
> 
>   int do_something() {
> ...
>   }
> 
> But if the program
> 
>   static int a = 0;
> 
>   int main() {
> /* do something */
>   }
> 
> is used as part of a larger program, it has to become
> 
>   static int a;
> 
>   int do_something() {
> a = 0;
> ...
>   }

Just put:

static int a; /* must be set to zero in foobar() */

> You see that I, in my own code, follow a certain convention
> where presence or absence of assignments means something
> about the code.

Unfortunately, this handy documentation shortcut of yours bloats the kernel
unnecessarily.

> If now you change "static int a = 0;"
> into "static int a;" and justify that by saying that it
> generates the same code,

It does NOT generate the same code - that's the point. It generates smaller but
functionally equivalent code. The first version zeroes a TWICE, in effect; this
is completely unnecessary, and just bloats the kernel.

> then I am unhappy, because now
> if I turn main() into do_something() I either get a buggy
> program, or otherwise I have to read the source of main()
> again to see which variables need initialisation.

Oh no! You mean you might actually have to look at the code you're changing?!
This is hardly a valid reason for bloating the kernel! If you put the "this
variable must be zero when foo() is called" in a comment, rather than as a C
statement, it is equally clear to you - but avoids bloating the kernel.

> In a program source there is information for the compiler
> and information for the future me. Removing the " = 0"
> is like removing comments. For the compiler the information
> remains the same. For the programmer something is lost.

So put that comment in a real comment, rather than a redundant statement!


James.
-
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] removal of "static foo = 0"

[Andries Brouwer]

On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:

> No information is lost.

Do I explain things so badly? Let me try again.
The difference between

  static int a;

and

  static int a = 0;

is the " = 0". The compiler may well generate the same code,
but I am not talking about the compiler. I am talking about
the programmer. This " = 0" means (to me, the programmer)
that the correctness of my program depends on this initialization.
Its absense means (to me) that it does not matter what initial
value the variable has.

This is a useful distinction. It means that if the program

  static int a;

  int main() {
  /* do something */
  }

is used as part of a larger program, I can just rename main
and get

  static int a;

  int do_something() {
  ...
  }

But if the program

  static int a = 0;

  int main() {
  /* do something */
  }

is used as part of a larger program, it has to become

  static int a;

  int do_something() {
  a = 0;
  ...
  }


You see that I, in my own code, follow a certain convention
where presence or absence of assignments means something
about the code. If now you change "static int a = 0;"
into "static int a;" and justify that by saying that it
generates the same code, then I am unhappy, because now
if I turn main() into do_something() I either get a buggy
program, or otherwise I have to read the source of main()
again to see which variables need initialisation.

In a program source there is information for the compiler
and information for the future me. Removing the " = 0"
is like removing comments. For the compiler the information
remains the same. For the programmer something is lost.

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: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Rick Bunke]

I read up on this thread in the archives (the last message in thread was
posted on the 24th) so I'm sorry if this has already been said.

I'm having the same problem with 2.4.0-test10, but I don't have the
problem with 2.4.0-test9.  So i think the bug might have been introduced
in 10.

When I try to compile xfree86 (the DRI version) under test10 my system 
locks up and then has to clean up a bunch of errors in the filesystem on
reboot.  I went back, removed my build tree, recreated it, recompiled
again and it would lock up again.  I did this a few times under kernel
2.4.0-test10 and it would consistantly lock up, then I went to the kernel
archive and found this thread which says the problem is in test11.  I then
decided I better try out test9 and see if it was just me.  I rebooted into
kernel 2.4.0-test9, removed my build tree, recreated it, then recompiled
again and it worked just fine without locking up.  That is what leads me
to believe the problem was introduced in test10 and probably carried over
to test11.  Hope this helps. 

If you want more info just let me know 
my email address is [EMAIL PROTECTED]

Have Fun
Rick

Information is the currency of democracy.
   - Thomas Jefferson

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

reproducible 2.2.1x nethangs

[Clayton Weaver]

kernel versions 2.2.17 and 2.2.18-pre23 (same behavior)
monolithic kernel
i21143 tulip card (may or may not be significant, stock kernel driver)
egcs-1.1.2, glibc-2.1.3, binutils-2.9.1.0.25

I can reliably hang either 2.2.17 or 2.2.18-pre23 (same way, same
circumstances) with httpd over eth0. It is not a particularly exotic
kernel config (ethernet, tulip, dummy, ppp, aha154x, scsi hd/cd/tape,
pio ide, i486, generic pci driving an sis496 pci 2.0 bus, no pci bridge 
optimization, firewall enabled, no masq, no proxy, no adv routing). All of
this hardware and the network are stable on 2.0.38 (ie the tcp/ip over
ethernet hang never happens there). It happens without any ipchains
rules installed (the support is there, but it's not configured).

It doesn't seem to do it on ftp (although that may simply be not having
pushed it hard enough). It can handle 100s of mbs in a single ftp session
without falling over, but a rapid sequence of httpd requests will knock
it over every time.

Minor points of evidence:

* on one test, "strace -ff ..." showed the second argument to accept()
  scribbled over (6-7 lines of "^@^@..." in the child) about three forks
  before it deadlocked. I saw the same thing at the bottom of the
  httpd server's log after an earlier hang.

* It doesn't simply stop, it suddenly gets really slow on the connect
  where it is going to hang. The last html page downloaded on one test
  ended up with a partial document, so it sometimes starts the data
  transfer, it simply can't complete it (the kernel/network_stack is
  already on it's way to the twilight zone when the download starts, it
  simply manages to squeeze out a few packets before it gets there).

* When it happens, it takes the keyboard with it, and you can't ping it.

* It's not the hd filesystems. I can html browse the same files that it
  hangs on over eth0 via lynx on the same host where the httpd server is
  running for hours without reproducing the kernel hang. I can move gbs
  of data around on those filesystems without errors and without
  filesystem corruption.

Since the error can be reproduced so reliably, it should be possible to
debug it, if I know where/how to enable verbose logging.

Suggestions?

Regards,

Clayton Weaver

(Seattle)

"Everybody's ignorant, just in different subjects."  Will Rogers



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

Re: Linux 2.4.0test11ac4

[John Cavan]

Alan Cox wrote:
> o   Fix ppa and imm hangs on io_request_lock(Tim Waugh)

Just so I understand the differences, for learning purposes... Tim did
this a little different than I did and I'd just like to understand the
"whys" of it. 

Can't learn if I don't understand. :o)

Thanks,
John
-
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] removal of "static foo = 0"

[Tigran Aivazian]

Hello Andries,

On Sat, 25 Nov 2000, Andries Brouwer wrote:
> What a strange reaction. If I write
> 
>  static int foo;
> 
> this means that foo is a variable, local to the present compilation unit,
> whose initial value is irrelevant because it will be assigned to before use.
> If I write
> 
>  static int foo = 0;
> 
> this means that the code depends on the initialization.
> Indeed, it is customary to write
> 
>  int foo = 0;  /* just for gcc */
> 
> when the initialization in fact is not necessary.

What I am suggesting (in fact, not me but common sense) is that if you
write:

static int foo;

then you really mean "a variable is foo and since it is required to be
initialized to zero, I am quite free to _rely_ on this fact and will
possibly do so". It is true that information about whether you actually
rely on it or not is lost but surely such "loss" is worth being able to
run Linux rather than non-Linux (i.e. in the cases where it is a matter of
a "few bytes" that decides whether you _can_ run Linux or not at all, i.e.
presumably some small devices where you have to squeeze Linux with a given
set of drivers into finite room).

> Saving a byte in the binary image is not very interesting. Preserving
> information about the program is important.

Saving a single byte may not be. Some studies have shown that the total is
in the range of a megabyte, that is first. The second is -- developing the
optimal set of mind (namely that described above around "static int foo;"
) is very interesting as it ensures that Linux remains optimal even as it
and the number of people working on it grows astronomically. You must have
seen the source code of various commercial flavours of UNIX and therefore
understand why they are such a failure -- there is no one like Linus
Torvalds behind them which has so much patience that he gratefully accepts
all improvements, however small they may seem. I hope that Linux will
remain the cleanest system wrt attention to detail. Yes, I understand that
it requires absolutely _impossible_ amount of patience on the part of
Linus Torvalds, but that is indeed what he does -- the impossible and may
God bless him and keep him.

> 
> I see that this message is cc'ed to Tigran, so let me address him as well.
> Tigran, you like to destabilize Linux. I like to stabilize Linux.
> 

Oh, Andries, that is insulting. Surely you do not really mean that. So, I
_will_ read the rest of your message. :)

> If it is your intention to destabilize then you need not read the following.
> But let us assume that you try to make a perfect system.
> 
> There is the issue of local and global correctness.
> A piece of code is locally correct when its correctness can be seen
> by just looking at those lines, or that function, or that source file.
> A piece of code is globally correct when you need to read the entire kernel
> source to convince yourself that all is well.
> 
> Often local correctness is obtained by local tests. After reading the entire
> kernel source you conclude that these tests are superfluous because they
> are satisfied in all cases. And you think it is an improvement to remove
> the test. It almost never is. On a fast path, where every cycle counts, yes.
> But it is not a good idea to sacrifice local correctness and save five
> kernel image bytes, or speed up the mount system call by 0.001%.
> Why not? Because you read the entire kernel source of today.
> But not that of next week. Somewhere someone changes some code.
> The test is gone and the kernel crashes instead of returning an error.

your theory is very good, in theory, but is not so in practice. Namely, if
you cared to look in depth at the specific instances of the optimizations
I suggested which required what you call "global correctness checks" (I
like that terminology!) then you would either have found out that either:

a) I have done enough investigations to show that such tests can not only
be removed now but nothing in the future should ever require them to be
added.

or

b) I have made a mistake, in which case, I would be happy to see you
correcting me. Failure to do so indicates that I was right.

in both cases, I did not intentionally sacrifice "local correctness" as
you are trying to present. I think I value local correctness as much as
you do.

> You even like to destabilize when there is no gain in size or speed at all.
> It is bad coding practice to use casts. They tell the compiler not to check.
> With functions returning (void *) the opposite is true. The compiler cannot
> check now, but given a cast, it can. Thus, I wrote a few months ago
> 
> > If one just writes
> >   foo = kmalloc(n * sizeof(some_type), GFP_x);
> > then neither the compiler nor the human eye can check
> > easily that things are right, i.e. that foo really is
> > a (some_type *). Therefore it is better to write
> >   foo = (some_type *) kmalloc(n * sizeof(some_type), GFP_x);
> 
> To my surprise you answered
> 
> : It is a small thing, Andries, but I

Re: PIIX4 BX Errata for DMA errors.

[Tuomas Heino]

On Fri, 24 Nov 2000, Andre Hedrick wrote:

> Anyone having DMA errors that are dmaproc: error 14, there is not a clean
> workaround yet.  Also the Intel erratas state that only a bus reset will
> clear the hang, but the details are loose.

We talking about errors like the following one? :

Nov 18 10:08:46 bx3 kernel: hdb: timeout waiting for DMA
Nov 18 10:08:46 bx3 kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 
14
Nov 18 10:08:46 bx3 kernel: hdb: irq timeout: status=0xd0 { Busy }
Nov 18 10:08:46 bx3 kernel: hda: DMA disabled
Nov 18 10:08:46 bx3 kernel: hdb: DMA disabled
Nov 18 10:08:48 bx3 kernel: ide0: reset: success

If so, anyone happen to be able to help me figure out why that keeps
happening on hdb & hdd while it never happens on hda?

/dev/hda:

 Model=IBM-DJNA-352500, FwRev=J51OA30K, SerialNo=GW0GWF37316
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=49981680
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4

/dev/hdb:

 Model=IBM-DTTA-371440, FwRev=T71OA73A, SerialNo=WK0WKG29267
 BuffType=DualPortCache, BuffSize=462kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=28229040
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 *udma1 udma2

/dev/hdd:

 Model=IBM-DTTA-371440, FwRev=T71OA73A, SerialNo=WK0WKA28245
 BuffType=DualPortCache, BuffSize=462kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=28229040
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2

Also is there a way to actually use /proc/ide/hd?/smart_* ?

# diff -u --recursive 19990822 20001125 | diffstat
 hda/smart_values |   14 +++---
 hdb/smart_values |   12 ++--
 hdd/smart_values |   10 +-

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

Questions about Kernel 2.4.0.?

[Android]

There is a link in /lib/modules/2.4.0.11: 
build->/usr/src/linux
created by the Makefile (make 
modules_install).What for? depmod doesn't like this link. It gets 
confused.
 
Lines missing from 
/usr/src/linux/include/asm/uaccess.h:   #define 
put_user_ret(x,ptr,ret) ({ if (put_user(x,ptr)) return ret; })   
#define get_user_ret(x,ptr,ret) ({ if (get_user(x,ptr)) return ret; 
})   #define __put_user_ret(x,ptr,ret) ({ if (__put_user(x,ptr)) 
return ret; })   #define __get_user_ret(x,ptr,ret) ({ if 
(__get_user(x,ptr)) return ret; })
Some modules will not compile without these lines 
included.
 
Where are the drivers for bt878 (Video For 
Linux)?
 
Some of the device special files are missing when 
using devfs.
devfsd is running (loaded at the beginning of rc.S 
by init).
There was no /dev/lp0 on my system, even though 
module lp was loaded.
After creating this file explicitly with mknod, the 
printer worked.
 
This problem is probably the fault of X11 - it 
doesn't repaint the screen properly
after coming out of console mode. I have to switch 
back and forth several times
before I get a proper repaint. May be related to 
using framebuffer with X.
X crashes and locks completely when using sound. 
Anyone know why?
 
 
-- Ted
 

Re: [PATCH] removal of "static foo = 0"

[Herbert Xu]

Andries Brouwer <[EMAIL PROTECTED]> wrote:
>
>  int foo = 0;  /* just for gcc */

> when the initialization in fact is not necessary.

Only for non-static foo.

> It is a bad programming habit to depend on this zero initialization.
> Indeed, very often, when you have a program that does something
> you need to change it so that it does that thing a number of times.
> Well, put a for- or while-loop around it. But wait! The second time
> through the loop certain variables need to be reinitialized. Which ones?
> The ones that were initialized explicitly in your first program.
> Make the program into a function in a larger one. Same story.

Again, this only applies to non-static variables.  For static ones, they're
initialised once only even when they go out of scope.

> Saving a byte in the binary image is not very interesting.
> Preserving information about the program is important.

No information is lost.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.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/

Linux 2.4.0test11ac4

[Alan Cox]

Changes in 2.4.0test11ac4

o   Add clocking option to maestro (broken laptop   (me)
stuff again)
o   Put back the module locking in soundcore(David Schleef)
that someone disabled
o   Abyss driver cleanup(Jeff Garzik)
o   Alpha PCI fixes (update resource not __init,(Ivan Kokshaysky)
off by one on check)
o   DOC1000 driver fixes(David Woodhouse)
o   Switch tvaudio and msp3400 to use up_and_exit   (David Woodhouse)
o   Fix ppa and imm hangs on io_request_lock(Tim Waugh)
o   Fix pport reverse/forward logic error   (Tim Waugh)
o   usb-uhci was using constants not flags for  (Jeff Garzik)
pci interface
o   Small fix for kdoc  (Tim Waugh)
o   FPU emulator source set for m68k(Geert Uytterhoeven)
o   Fix m68k build with rmw disabled(Geert Uytterhoeven)
o   Fix nubus build (Geert Uytterhoeven)
o   atari/sun3lance update  (Geert Uytterhoeven)
o   Amiga gayle pcmcia fixups   (Geert Uytterhoeven)
o   Fixes for amiga scsi drivers(Geert Uytterhoeven)
o   Simplify amiga irq handling code(Geert Uytterhoeven)
o   Amiga sound/fb driver update(Geert Uytterhoeven)
o   Amiga/Mac/Atari keyboard driver changes (Geert Uytterhoeven)
o   Integrate atari stram with bootmem  (Geert Uytterhoeven)
o   Restore atafb_fix that someone deleted  (Geert Uytterhoeven)
o   m68k include updates for 64bit structs  (Geert Uytterhoeven)
o   Add driver for MVME147 onboard scsi (Geert Uytterhoeven)
o   Enable Q40 ide interface(Geert Uytterhoeven)
o   Replace init with initdata in places on m68k(Geert Uytterhoeven)
o   MMU code changes for m68k   (Geert Uytterhoeven)
o   dma_addr_t and other minor updates for m68k (Geert Uytterhoeven)
o   m68k ptrace update  (Geert Uytterhoeven)
o   Fix pmc551 when used without bugfix enabled (David Woodhouse)
o   Fix endianness on ftl layer (David Woodhouse)
o   Update 8139too driver   (Jeff Garzik)
o   Fix readdir returns on procfs   (Matt Kraai)
o   Fix atm build   (Markus Kossmann)

Changes in 2.4.0test11ac3

o   Features is back to flags for compatibility (me)
o   Cleanup ramdisk namespace   (Jeff Garzik)
o   ACPI updates(Andrew Grover)
o   Make SET_MODULE_OWNER macro safer   (Jeff Garzik)
o   Hisax needed __init (Jeff Garzik)
o   Tidy riscom8 and sx namespace   (Jeff Garzik)
o   Tidy network drivers module locking (Jeff Garzik)
o   APM updates, fix the Dell 5000e check for APM=m (Stephen Rothwell)
o   Fix module initialization oops  (Keith Owens)
o   Clean up Abyss driver   (Jeff Garzik)
o   Fix raid linking order  (Neil Brown)
o   Clean up rcpci driver (new style pci etc)   (Jeff Garzik)
o   Fix SCSI / PCI dependancies (Jeff Garzik)
o   Better trap for MP board with no MP cpu (Maciej W. Rozycki)
o   Tidy up mad16 driver(Pavel Rabel)
o   Update EATA driver and Ultrastor driver (Dario Ballabio)
o   Clean up printk formatting in a few drivers (me)
o   Disable PMC511 driver - its obviously broken(me)

Changes in 2.4.0test11ac2

o   Fix pcnet32 printk problems (Vojtech Pavlik)
o   Fix kd_mksound declaration  (Geert Uytterhoeven)
o   m68k config fixes   (Geert Uytterhoeven)
o   Make uid16 macros safer (Andreas Schwab)
o   Fix dquot overflow/recovery (Jan Kara)
o   Rename block_til_ready in generic_serial  (Patrick van de Lageweg)
o   Fix missing Config doc and sound doc error  (Thierry Vignaud)
o   Fix Ruffian Alpha boot  (Ivan Kokshaysky)
o   Bridge handling patches needed for Alpha(Ivan Kokshaysky /
Richard Henderson)
o   APM update  (Stephen Rothwell)
o   Fix SMP build on x86(Steven Cole)
o   Remove unneeded inits to 0 in ide code(Bartlomiej Zolnierkiewicz)
o   IDE documentation fixes   (Bartlomiej Zolnierkiewicz)
o   Maestro ioctl locking fix   (Zach Brown)
o   

Re: [PATCH] removal of "static foo = 0"

[Andries Brouwer]

On Sat, Nov 25, 2000 at 09:07:08PM +, Russell King wrote:
> Andries Brouwer writes:
> > What a strange reaction. If I write
> > 
> >  static int foo;
> > 
> > this means that foo is a variable, local to the present compilation unit,
> > whose initial value is irrelevant 
> 
> Wrong.  The initial value is well-defined.

Oh, please - something is wrong with your reading comprehension.
Don't you understand the word "irrelevant"? It means that the
initial value does not matter. It does not mean undefined.
Please reread my letter and comment when you understand my point.
-
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: *_trylock return on success?

[Roger Larsson]

On Saturday 25 November 2000 20:22, Philipp Rumpf wrote:
> On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
> > > _trylock functions return 0 for success.
> >
> > Not   spin_trylock
>
> Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean
> unlocked.  You're correct, and obviously this should be fixed.
> -
> 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/

If this are to change in 2.4 I would suggest
to renaming it to mutex_lock (as in Nigels preemptive kernel patch)

Why?

A) the name spin_lock describes how the function is implemented and not
the intended purpose.
B) with a preemptive kernel we will have more than four intended purposes:
1) SMP - spin_lock, prevent two processors to run currently
2) UP- not used, code can only be executed by one thread.
3) PREEMTIVE - lock a region for preemption to avoid concurrent execution.
4) debug - addition of debug checks.

With Nigels patch most are changed, with some additional stuff...

My suggestion, change the name to mutex_lock and negate let mutex_trylock
follow the example of other _trylocks (returning 0 for success).

Ok?

If it is ok, I can prepare a patch (earliest monday)

/RogerL
-- 
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: PROBLEM: crashing kernels

[Mr. Big]

> Alan Cox <[EMAIL PROTECTED]> writes:
> 
> > > benn compiled into the kernel, and not as a module) always gave the
> > > errors:
> > > 
> > > eth0: Transmit timed out: status 0050  0090 at 134704418/134704432 
> > > eth0: Trying to restart the transmitter...
> > 
> > Known problem. This one might be fixed in current 2.2.18pre. SOme people
> > see it some dont
> 
> I have another data point on this problem.
> I have seen it most with 2.4.0-test9.  But I'll look at 2.2.18pre.
> I can trigger this bug fairly reliably by warm booting, several times
> in a row.  With my linux warm booting directly into linux code triggers this
> one fairly reliably :)  Also putting another nick in seems to help
> trigger it as well.

Ok. I won't use that card anymore, and wont compile this part of code
neither. But I still doesn't know why does my 2.4.0-test11 crash to black:
no console, not keyboard, no logs, nothing... like a cut on the
electricity. 
Just some mins ago I got another interesting thing: (with the eepro100
driver)
I've been logged in trough ssh. Like 5-10 mins before the crash the packet
loss jumped up to around 30% (the network was ok, the other hosts on the
same network came with 0% loss) Then after a while no answare to the ping,
but my ssh worked still, and even I could log in. So it seems so, that
something in the network driver died, and it didn't answare anymore to the
ICMP requests. 
On the console was nothing again. When the guy pressed the ctrl-alt-del,
the normal reboot message came to the ssh terminals, but nothing happened
on the console, or on the computer (no hard drive activity, no leds on the
keyboard)

For the confusion of the services maybe the libc6 could be blamed. But I
yet doesn't understan why the packet loss rise, and why wasn't the console
working.

And a note for Alan: it isn't so simple to hack the Mylex driver from the
2.2.17 into the 2.2.14... I'm currently trying it...


++
| Nagy Attila|
|   mailto:[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] removal of "static foo = 0"

[Russell King]

Andries Brouwer writes:
> What a strange reaction. If I write
> 
>  static int foo;
> 
> this means that foo is a variable, local to the present compilation unit,
> whose initial value is irrelevant because it will be assigned to before use.

Wrong.  The initial value is well-defined.  Go and read any C standard you
choose.  Any C standard you care.  You will find out something really
interesting.  I can guarantee that you will find out that it will be
initialised to zero.  Unconditionally.  No question.  Absolutely.

> It is a bad programming habit to depend on this zero initialization.

Why?  Again, it is WELL defined, and is WELL defined in any C standard.

> Indeed, very often, when you have a program that does something
> you need to change it so that it does that thing a number of times.
> Well, put a for- or while-loop around it. But wait! The second time
> through the loop certain variables need to be reinitialized. Which ones?
> The ones that were initialized explicitly in your first program.
> Make the program into a function in a larger one. Same story.

Your point here is as clear as mud.

> If it is your intention to destabilize then you need not read the following.
> But let us assume that you try to make a perfect system.

There is absolutely NO destabilisation going on here.  Get a grip, read the
C standards, read the C startup code.  Then come back with something more
relevent.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test11: "_isofs_bmap: block < 0"

[Andries Brouwer]

On Sat, Nov 25, 2000 at 06:20:56PM +0100, Arjan Filius wrote:

> Nov 25 18:16:05 sjoerd kernel: _isofs_bmap: block < 0

Understood and solved. For the whole story read linux-kernel.
To fix just this, remove the two lines

if (filp->f_pos >= inode->i_size)
return 0;

from linux/fs/isofs/dir.c around line 119.

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: "Hyper-Mount" option possible???

[Timur Tabi]

** Reply to message from Robert L Martin <[EMAIL PROTECTED]> on Thu,
23 Nov 2000 10:55:38 -0500


> Soo  Given that Super-Mount is already taken, How about (in
> 2.5??)  hashing out a Hypermount option.

How about calling it "multi-mount"?  I think it's more accurate.


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

When replying to a mailing-list message, please direct the reply to the mailing list 
only.  Don't send another copy to me.
-
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: crashing kernels

[Eric W. Biederman]

Alan Cox <[EMAIL PROTECTED]> writes:

> > benn compiled into the kernel, and not as a module) always gave the
> > errors:
> > 
> > eth0: Transmit timed out: status 0050  0090 at 134704418/134704432 
> > eth0: Trying to restart the transmitter...
> 
> Known problem. This one might be fixed in current 2.2.18pre. SOme people
> see it some dont

I have another data point on this problem.
I have seen it most with 2.4.0-test9.  But I'll look at 2.2.18pre.
I can trigger this bug fairly reliably by warm booting, several times
in a row.  With my linux warm booting directly into linux code triggers this
one fairly reliably :)  Also putting another nick in seems to help
trigger it as well.

The 2.4.0-testxxx watchdog seems eventually to handle this case 
but it takes 1/2 hour or so to actually kick in and reset the card.

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

Re: [PATCH] removal of "static foo = 0"

[Andries Brouwer]

On Sat, Nov 25, 2000 at 11:50:20AM +, Russell King wrote:
> Rusty Russell writes:
> > What irritates about these monkey-see-monkey-do patches is that if I
> > initialize a variable to NULL, it's because my code actually relies on
> > it; I don't want that information eliminated.
> 
> What information is lost?  Unless you're working on a really strange
> machine which does not zero bss, the following means the same from the
> codes point of view:
> 
> static int foo = 0;
> static int foo;
> 
> Both are initialised to zero by the time the code sees them for the
> first time.  Therefore there is no difference to the code in its reliance
> on whether foo is zero.  foo will be zero in both cases.
> 
> Also, any good programmer worth their skin should know this, and should
> realise it.  Therefore, there is no information loss

What a strange reaction. If I write

 static int foo;

this means that foo is a variable, local to the present compilation unit,
whose initial value is irrelevant because it will be assigned to before use.
If I write

 static int foo = 0;

this means that the code depends on the initialization.
Indeed, it is customary to write

 int foo = 0;  /* just for gcc */

when the initialization in fact is not necessary.


It is a bad programming habit to depend on this zero initialization.
Indeed, very often, when you have a program that does something
you need to change it so that it does that thing a number of times.
Well, put a for- or while-loop around it. But wait! The second time
through the loop certain variables need to be reinitialized. Which ones?
The ones that were initialized explicitly in your first program.
Make the program into a function in a larger one. Same story.


Saving a byte in the binary image is not very interesting.
Preserving information about the program is important.

I see that this message is cc'ed to Tigran, so let me address him as well.
Tigran, you like to destabilize Linux. I like to stabilize Linux.

If it is your intention to destabilize then you need not read the following.
But let us assume that you try to make a perfect system.

There is the issue of local and global correctness.
A piece of code is locally correct when its correctness can be seen
by just looking at those lines, or that function, or that source file.
A piece of code is globally correct when you need to read the entire kernel
source to convince yourself that all is well.

Often local correctness is obtained by local tests. After reading the entire
kernel source you conclude that these tests are superfluous because they
are satisfied in all cases. And you think it is an improvement to remove
the test. It almost never is. On a fast path, where every cycle counts, yes.
But it is not a good idea to sacrifice local correctness and save five
kernel image bytes, or speed up the mount system call by 0.001%.
Why not? Because you read the entire kernel source of today.
But not that of next week. Somewhere someone changes some code.
The test is gone and the kernel crashes instead of returning an error.

You even like to destabilize when there is no gain in size or speed at all.
It is bad coding practice to use casts. They tell the compiler not to check.
With functions returning (void *) the opposite is true. The compiler cannot
check now, but given a cast, it can. Thus, I wrote a few months ago

> If one just writes
>   foo = kmalloc(n * sizeof(some_type), GFP_x);
> then neither the compiler nor the human eye can check
> easily that things are right, i.e. that foo really is
> a (some_type *). Therefore it is better to write
>   foo = (some_type *) kmalloc(n * sizeof(some_type), GFP_x);

To my surprise you answered

: It is a small thing, Andries, but I still think otherwise than you.
: It is better for code to be smaller than to be slightly more fool-proof.

Please change your mind.

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: gcc-2.95.2-51 is buggy

[Rik van Riel]

On Sat, 25 Nov 2000, Andries Brouwer wrote:
> On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:
> 
> > The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
> 
> Yes. Probably you have seen it by now, but the difference between
> good and bad versions of gcc-2.95.2 did not lie in the applied patches,
> but was the difference between compilation for 686 or 386.
> It is not your (SuSE's, Debian's) fault. A fix already exists.

Indeed, this should be fixed soon.

I'm sure a simple 'apt-get upgrade' will install a new
gcc RPM on my workstation soon ;)

cheers,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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: gcc-2.95.2-51 is buggy

[Andries Brouwer]

On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:

> The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.

Yes. Probably you have seen it by now, but the difference between
good and bad versions of gcc-2.95.2 did not lie in the applied patches,
but was the difference between compilation for 686 or 386.
It is not your (SuSE's, Debian's) fault. A fix already exists.

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: *_trylock return on success?

[Philipp Rumpf]

On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
> > _trylock functions return 0 for success.
> 
> Not   spin_trylock

Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean
unlocked.  You're correct, and obviously this should be fixed.
-
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: *_trylock return on success?

[Roger Larsson]

On Saturday 25 November 2000 19:30, Philipp Rumpf wrote:
> On Sat, Nov 25, 2000 at 03:49:25PM -0200, Rik van Riel wrote:
> > On Sat, 25 Nov 2000, Roger Larsson wrote:
> > > Questions:
> > >   What are _trylocks supposed to return?
> >
> > It depends on the type of _trylock  ;(
> >
> > >   Does spin_trylock and down_trylock behave differently?
> > >   Why isn't the expected return value documented?
> >
> > The whole trylock stuff is, IMHO, a big mess. When you
> > change from one type of trylock to another, you may be
> > forced to invert the logic of your code since the return
> > code from the different locks is different.
> >
> > For bitflags, for example, the trylock returns the state
> > the bit had before the lock (ie. 1 if the thing was already
> > locked).
>
> I assume you're talking about test_and_{set,clear}_bit here.  Their return
> value isn't consistent with the other _trylock functions since they're not
> _trylock functions.
>
> I think the real problem is that people use test_and_set_bit for locks,
> which is almost never[1] a good idea.  The overhead for a semaphore
> shouldn't be too much in most cases, and that way it is obvious what you
> want to do - and, hopefully, even more obvious if you end up with a
> semaphore that can be turned into a spinlock without further changes.
>
> > For spinlocks, it'll probably return something else ;/
>
> _trylock functions return 0 for success.

Not   spin_trylock

Simple example code from
code from include/asm-mips/spinlock.h:65
#define spin_trylock(lock) (!test_and_set_bit(0,(lock)))

/RogerL

> -
> 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/
-
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: *_trylock return on success?

[Roger Larsson]

On Saturday 25 November 2000 18:49, Rik van Riel wrote:
> On Sat, 25 Nov 2000, Roger Larsson wrote:
> > Questions:
> >   What are _trylocks supposed to return?
>
> It depends on the type of _trylock  ;(
>
> >   Does spin_trylock and down_trylock behave differently?
> >   Why isn't the expected return value documented?
>
> The whole trylock stuff is, IMHO, a big mess. When you
> change from one type of trylock to another, you may be
> forced to invert the logic of your code since the return
> code from the different locks is different.
>
> For bitflags, for example, the trylock returns the state
> the bit had before the lock (ie. 1 if the thing was already
> locked).
>

This holds for down_trylocks too.
It looks like it is the spinlocks that are wrong... :-(

As most return values tend to be error returns that also
matches other code in functionallity.

>
> For spinlocks, it'll probably return something else ;/
It does...

I guess fixing this is too much too late?


It looks like ppc mixes the ways... from arch/ppc/lib/locks.c:46

int spin_trylock(spinlock_t *lock)
{
if (__spin_trylock(&lock->lock))  /* one on failure */
return 0; /* zero on failure */ 
lock->owner_cpu = smp_processor_id(); 
lock->owner_pc = (unsigned long)__builtin_return_address(0);
return 1;
}


BUT anyway...
 The thing I hit is not a bug in the kernel proper - it is in the preemptive 
stuff.

/RogerL

-- 
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: PROBLEM: crashing kernels

[Alan Cox]

> Ok, I'll try. Since I'm not a kernel developer, I have the fool question,
> wether it is enough to overwrite the .c and .h files in the 2.2.14 source
> tree, or do I need to apply other changes too?

I believe that is all you need to do for that driver

-
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: crashing kernels

[Mr. Big]

> > benn compiled into the kernel, and not as a module) always gave the
> > errors:
> > 
> > eth0: Transmit timed out: status 0050  0090 at 134704418/134704432 
> > eth0: Trying to restart the transmitter...
> 
> Known problem. This one might be fixed in current 2.2.18pre. SOme people
> see it some dont
Ok, we're on the way to try to avoid the use of that ethernet card anyway

> 
> > mistake... But we couldn't go back to oldier kernels (because of the Mylex
> > card) so the only possibility is to go forward: we compiled the
> > 2.4.0-test11 kernel. It could be usefull also because of the khttpd, at
> > least we could free up some memory used by the apache.
> 
> You can copy the 2.2.17 updated mylex driver into 2.2.14 and rebuild a kernel
> that way. In fact that would be a good test

Ok, I'll try. Since I'm not a kernel developer, I have the fool question,
wether it is enough to overwrite the .c and .h files in the 2.2.14 source
tree, or do I need to apply other changes too?


++
| Nagy Attila|
|   mailto:[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: *_trylock return on success?

[Philipp Rumpf]

On Sat, Nov 25, 2000 at 03:49:25PM -0200, Rik van Riel wrote:
> On Sat, 25 Nov 2000, Roger Larsson wrote:
> 
> > Questions:
> >   What are _trylocks supposed to return?
> 
> It depends on the type of _trylock  ;(
> 
> >   Does spin_trylock and down_trylock behave differently?
> >   Why isn't the expected return value documented?
> 
> The whole trylock stuff is, IMHO, a big mess. When you
> change from one type of trylock to another, you may be
> forced to invert the logic of your code since the return
> code from the different locks is different.
> 
> For bitflags, for example, the trylock returns the state
> the bit had before the lock (ie. 1 if the thing was already
> locked).

I assume you're talking about test_and_{set,clear}_bit here.  Their return
value isn't consistent with the other _trylock functions since they're not
_trylock functions.

I think the real problem is that people use test_and_set_bit for locks,
which is almost never[1] a good idea.  The overhead for a semaphore shouldn't
be too much in most cases, and that way it is obvious what you want to do -
and, hopefully, even more obvious if you end up with a semaphore that can
be turned into a spinlock without further changes.

> For spinlocks, it'll probably return something else ;/

_trylock functions return 0 for success.
-
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: crashing kernels

[Alan Cox]

> benn compiled into the kernel, and not as a module) always gave the
> errors:
> 
> eth0: Transmit timed out: status 0050  0090 at 134704418/134704432 
> eth0: Trying to restart the transmitter...

Known problem. This one might be fixed in current 2.2.18pre. SOme people
see it some dont

> mistake... But we couldn't go back to oldier kernels (because of the Mylex
> card) so the only possibility is to go forward: we compiled the
> 2.4.0-test11 kernel. It could be usefull also because of the khttpd, at
> least we could free up some memory used by the apache.

You can copy the 2.2.17 updated mylex driver into 2.2.14 and rebuild a kernel
that way. In fact that would be a good test

I'd also be interested to know if 2.2.17 + Rik's vm patch (or + Andrea's
vm patch) is stable. (Rik and Andrea have differing views how to fix it but
both claim they have 8))

-
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: gcc-2.95.2-51 is buggy

[Jeff V. Merkey]

On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:

Rik,

We refuse to use it here at present.  Builds from it have a lot
of problems, for some reason.  Andre is looking into it more 
deeply than I, but I agree with your assessment.

Jeff


> On Fri, 24 Nov 2000, Neil Brown wrote:
> > On Friday November 24, [EMAIL PROTECTED] wrote:
> > > >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
> > > 
> > > > Now, if you can isolate the relevant part of the diff between
> > > > 2.95.2 and RH 2.96...
> > > 
> > > Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
> 
>   [image from FTP site not buggy]
> 
> > > This is from a SuSE distribution, I forget which, not very recent.
> > > Revised summary: gcc-2.95.2-51 from SuSE is buggy.
> > 
> > Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the
> > same bug. Debian applies a total of 49 patches to gcc and the
> > libraries.
> 
> The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
> 
> (and the ISO images haven't even been available for
> one week yet ... *sigh*)
> 
> regards,
> 
> Rik
> --
> Hollywood goes for world dumbination,
>   Trailer at 11.
> 
> 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/
-
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: silly [< >]

[Guest section DW]

On Sat, Nov 25, 2000 at 10:07:44PM +1100, Keith Owens wrote:

> If anybody really worries about the ix86 call trace going past column
> 80, just patch your kernel to print 5 fields per line instead of 8.  Do
> not change the format.  But hand copying an oops from an 80x24 screen
> is not going to work in the long term, see above.  Fiddling with the
> output format is a waste of time, instead work out how to capture the
> oops without relying on hand copying or a limited screen size.  Fix the
> problem, not the symptom.

Maybe you do not understand. This is a step towards capturing an oops.
People do different things - invent schemes to write an oops to swap space,
or to a floppy, or put it in memory in a place that might survive a reboot,
or log it over the ethernet, or attach a serial line to some terminal or
logging computer, they even use a high speed camera to capture an oops
as it is flying by.

These are all useful. Not every computer has a floppy drive, not every
computer has a hard disk, not every computer has a monitor screen,
not every computer can feasibly be connected to something else,
so more than a single scheme is needed. The scheme: write info to the screen
is very simple and is useful in a large number of cases. 
This screen has a very finite capacity (known to the kernel) so it is
important not to waste this capacity.

At present we waste a lot of space inserting meaningless parentheses.
The place of these parentheses is syntactically predictable, so
ksymoops can insert them just as well as the kernel can.
(I am talking about i386 here, have not looked at other architectures.)

And what is reality? I work under X and the system crashes. Boom. Dead.
No reaction to anything, no log, zero information. Ach.
Six weeks later, I work under X and the system crashes. Boom. Dead.
Nothing to do, zero information.
Four weeks later, I am on the console and the system crashes. A panic!
The message scrolls over the screen but the call trace is too long
and wastes 50% of the space so that only the end is visible - but that
is the part with the most worthless information. I do not want EIP to scroll
off-screen, I want the first few items of the Call Trace, not the last few.
Again the system is dead, and no useful information was obtained.

So, each time I miss important information because of these stupid
parentheses, I patch that kernel. And it regularly happens that I am
rewarded with a complete message that would otherwise have missed
the most important part. I think this change is useful for everybody,
not just for me.

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/

PROBLEM: crashing kernels

[Mr. Big]

[1.]
Kernels 2.2.14, 2.2.17, 2.4.0-test11 crash with various errors
(I know this is too simple, but this is what I could say in one line)

[2.]
We're running a quite bussy site, and updateing our servers hardware quite
often. Since a while ago we're expecting many troubles, that usually end
with crash (that means, we need to press the hw-reset to reboot).

We've run the kernel 2.2.14 for a long while, but after replacing the
mainboard, and the ethernet cards the module eepro100 (wich actually
benn compiled into the kernel, and not as a module) always gave the
errors:

eth0: Transmit timed out: status 0050  0090 at 134704418/134704432 
eth0: Trying to restart the transmitter...

In these cases we couldn't do anything than restarting the system
(yeah, I know is a quite window$ solution, but ifconfig eth0 down/up
didn't help neither) by pressing ctrl-alt-del. This problem occoured
almost every day once.

Ok, we thought maybe the driver isn't correct yet, and whenever we were a
little out-of-date with the kernel 2.2.14, so we decided to try a newer
one, first the 2.2.16. This kernel didn't last long, because it also
crashed with error like:
Oct  1 23:09:17 luna kernel: eth0: can't fill rx buffer (force 1)!
Oct  1 23:09:17 luna kernel: eth0: Tx ring dump,  Tx queue 6270428 /
6270428:
Oct  1 23:09:17 luna kernel: eth0: 0 200ca000.
Oct  1 23:09:17 luna kernel: eth0: 1 000ca000.
Oct  1 23:09:17 luna kernel: eth0: 2 000ca000.
Oct  1 23:09:17 luna kernel: eth0: 3 000ca000.
Oct  1 23:09:17 luna kernel: eth0: 4 000ca000.
Oct  1 23:09:17 luna kernel: eth0: 5 000ca000.
Oct  1 23:09:17 luna kernel: eth0: 6 000ca000.
Oct  1 23:09:17 luna kernel: eth0: 7 000ca000.
Oct  1 23:09:17 luna kernel: eth0: 8 200ca000.
Oct  1 23:09:17 luna kernel: eth0: 9 000ca000.
Oct  1 23:09:17 luna kernel: eth0:10 000ca000.
Oct  1 23:09:17 luna kernel: eth0: Printing Rx ring (next to receive into
427603
9, dirty index 4

 but in these cases there wasn't any possibility for a clean reboot. We
don't like much the fsck, so let's try the 2.2.17. Also the same troubles,
like above. We also tried to increase the TX_RING_SIZE, and RX_RING_SIZE
values, but this dind't help neither.

We got the informations, that these Intel Ether Express Pro cards have
some bugs, so we got another driver from the Intel, called e100, and
decided to go back to the good old 2.2.14 Kernel, and tried this module.
Wow, new type of error messages:

kernel: e100 - Intel(R) 82559 Fast Ethernet LAN on Motherboard 
kernel: eth0:  Mem:0xf4102000  IRQ:21  Speed:100 Mbps Dx:Full
kernel: Hardware receive checksums enabled
...
kernel: eth0: rx_srv: no buffers left!!!

Ok, the modul supported to change the buffer sizes, we tried to increase
them, but didn't help.

After some askabout we decided to throw out the EtherExpress Pro's, and to
change to something, that other people use. We couldn't do that totally,
because on of these cards is integrated to the mainboard, so we couldn't
get rid of that.

We also needed to do some changes (change the Mylex card to a Mylex
AcceleRAID 352) so we changed one of the EtherExpresses to a 3Com Tornado
at the same time. Like the kernel sais, it's a:
kernel: eth0: 3Com 3c905C Tornado at 0x2800, 00:01:02:b7:94:4b, IRQ 18
kernel:   8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
kernel:   MII transceiver found at address 24, status 782d.
kernel:   Enabling bus-master transmits and whole-frame receives.

We needed to change to the kernel 2.2.17 again, because this is the
onlyone that supports the Mylex 352.

This was the point where everything went down. We have 1Gb ram in the
computer, but sometimes we run out to the swap. This usually lead to a
server crash: you had a ping, but none of the ports answared. On the
console, and in the kern.log we got these kind of errors:
Nov 20 01:06:47 luna kernel: VM: do_try_to_free_pages failed for apache...
You could change the console, but nothing gave a reply. Such things
happened before with other kernels, but there we simply pulled down the
ethernet, the apache processes exited after some mins, and I could log in
to the console. But with the 2.2.17 it doesn't help anymore, only thing
could do: reset :( Then of course 2-3 hours of fsck... nice...
We tried to increase the amount of swap. (originally we had just 256MB, we
increased this to 1.7GB) Same shit happened again, and usually really
fast: often while I've been working on the computer once my ssh stoped,
and by then was too late...
I've checked the kernel source, and saw that the vmscan.c was changed
since the 2.2.14 until the 2.2.17. Ok, maybe the author made some
mistake... But we couldn't go back to oldier kernels (because of the Mylex
card) so the only possibility is to go forward: we compiled the
2.4.0-test11 kernel. It could be usefull also because of the khttpd, at
least we could free up some memory used by the apache.

The kernel compiled and the system booted up. The first three-four

Re: setting up pppd dial-in on linux

[Jeff V. Merkey]

On Sat, Nov 25, 2000 at 11:04:48AM -0600, William Scott Lockwood III wrote:
> Jeff,
>   I am also VERY interested in this, particularly on getting modems to work
> with Linux at all.  I'm not reading the list right now, but I'd appreciate
> any feedback you can throw my way on this.   Esp. if you DO get it setup and
> working.  It sure would be nice to see Linux FINALLY support more modems out
> there.  Hell, my Internal USR ISA modem is not even supported, but FreeBSD
> had had support for it for a long time now.  :-(  Please let me know what
> you find out, and I'm VERY interested in your RPM - hope there will be a
> straight tarball for us Slackware Dinosaurs too.  :-)

I'll post ot at vger.timpanogas.org with the Ute-NWFS distribution.  It 
will be freely downloadable.  Having plug and play NT dial-in support 
would be very nice.  SuSe has a pretty nice setup, but we have as many,
if not more problems with their's vs. RedHat and ours.

Jeff

> 
> Scott
> 
> - Original Message -
> From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, November 25, 2000 1:36 AM
> Subject: setting up pppd dial-in on linux
> 
> 
> >
> >
> > Anyone out there a whiz at setting up a pppd dialin server?  I am
> > trying to put together an RPM for pppd dialin configurations
> > that will support default Windows NT and Linux dial in clients
> > without requiring the poor user to learn bash scripting, chat
> > scripting, mgetty and inittab configuration, etc.  The steps
> > in setting this up are about as easy as going on a U.N. relief
> > mission to equatorial Africa, and most customers who are
> > "mere mortals" would give up about an hour into it.
> >
> > I am seeing massive problems with pppd dial-in and IP/IPX
> > routing with problems that range from constant Oops, to
> > the bug infested pppd daemon failing valid MD5 chap
> > authentication.  The HOW-TO's and man pages provide
> > wonderful commentary on all the things about pppd
> > that don't work, but it's not too helpful on getting
> > it to work reliably.  An NT dial-in server takes about
> > 5 minutes to configure on W2K.  Linux takes about 2 days, and
> > won't stay up reliably.
> >
> > Who out there is an expert on Linux pppd that would like
> > to help put together some easy configs for standard
> > dial-in scenarios?
> >
> > Thanks
> >
> > 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/
> >
-
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 on 2.2.18-23 as pppd dial in server

[Jeff V. Merkey]

On Sat, Nov 25, 2000 at 06:22:57PM +0100, Chmouel Boudjnah wrote:
> "Jeff V. Merkey" <[EMAIL PROTECTED]> writes:
> 
> > Was able to reproduce this Oops, but it took several days.   Oops occurs
> > against 2.2.18-23.  I had to copy this info from the console -- the
> > system was hard hung after the oops and even ksymoops was locked solid.
> 
> what type of mounted filesystem you have (dos/ext2) ?

ext2/nwfs.  I made the mitake of rebuilding the kernel so I have
to recompile again to get the System.map file to ksymoops the 
crash.   I will try to have it completed today and posted.

Jeff

> 
> -- 
> MandrakeSoft Inc http://www.chmouel.org
>   --Chmouel
-
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: setting up pppd dial-in on linux

[Jeff V. Merkey]

On Sat, Nov 25, 2000 at 02:28:56PM +0100, Pedro M. Rodrigues wrote:
> 
>You are not alone. And the problem gets even worse when you 
> have to deal with ISDN devices. In my company´s data room we 
> have all Linux servers running 365 days a year (minus upgrade 
> time) and in one corner a lonely Windows NT Server 3.0 with 5 
> Client Access Licenses working as a RAS server for 2 Diva Server 
> BRI cards (4 analog/digital channels) plus one analog modem. 
> Time to set it up? Half an hour counting NT installation. Time i lost 
> investigating and trying different configurations, dealing with 
> contradictory documentation, chat scripts, different ipppd versions, 
> and authentication failures? 2 days. At Ieast i cant complain about 
> pppd oops, as you do, the pppd in RH6.2 seemed solid. The 
> document of reference that seemed more interesting to me at the 
> time was http://www.swcp.com/~jgentry/pers.html  , have a look 
> please.

Thanks.  We need to get the Linux stuff to the same point.  From 
our analysis, it's the only weak feature left -- Linux either 
matches or surpasses NT in every other area now except this one.

Jeff

> 
> 
> Regards,
> Pedro
> 
> On 25 Nov 2000, at 0:36, Jeff V. Merkey wrote:
> 
> > 
> > 
> > Anyone out there a whiz at setting up a pppd dialin server?  I am 
> > trying to put together an RPM for pppd dialin configurations
> > that will support default Windows NT and Linux dial in clients
> > without requiring the poor user to learn bash scripting, chat 
> > scripting, mgetty and inittab configuration, etc.  The steps
> > in setting this up are about as easy as going on a U.N. relief
> > mission to equatorial Africa, and most customers who are 
> > "mere mortals" would give up about an hour into it.
> > 
> > I am seeing massive problems with pppd dial-in and IP/IPX 
> > routing with problems that range from constant Oops, to 
> > the bug infested pppd daemon failing valid MD5 chap 
> > authentication.  The HOW-TO's and man pages provide 
> > wonderful commentary on all the things about pppd 
> > that don't work, but it's not too helpful on getting
> > it to work reliably.  An NT dial-in server takes about
> > 5 minutes to configure on W2K.  Linux takes about 2 days, and 
> > won't stay up reliably.  
> > 
> > Who out there is an expert on Linux pppd that would like
> > to help put together some easy configs for standard 
> > dial-in scenarios?
> > 
> > Thanks
> > 
> > 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/
> > 
> 
-
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: setting up pppd dial-in on linux

[Jeff V. Merkey]

On Fri, Nov 24, 2000 at 11:48:06PM -0800, J Sloan wrote:
> "Jeff V. Merkey" wrote:
> 
> > Anyone out there a whiz at setting up a pppd dialin server?  I am
> > trying to put together an RPM for pppd dialin configurations
> > that will support default Windows NT and Linux dial in clients
> > without requiring the poor user to learn bash scripting, chat
> > scripting, mgetty and inittab configuration, etc.  The steps
> > in setting this up are about as easy as going on a U.N. relief
> > mission to equatorial Africa, and most customers who are
> > "mere mortals" would give up about an hour into it.
> 
> Red Hat's ppp client setup is about a 90 second job

I am using theirs as a base.   Setup's not the issue.  It's the 
chap MD5 authentication for NT clients and the constant 
crashing that's troublesome.  I have it working, just not
with NT clients.

> 
> > I am seeing massive problems with pppd dial-in and IP/IPX
> > routing with problems that range from constant Oops, to
> > the bug infested pppd daemon failing valid MD5 chap
> > authentication.  The HOW-TO's and man pages provide
> > wonderful commentary on all the things about pppd
> > that don't work, but it's not too helpful on getting
> > it to work reliably.  An NT dial-in server takes about
> > 5 minutes to configure on W2K.  Linux takes about 2 days, and
> > won't stay up reliably.
> 
> hmm, an awful lot of ISPs use Linux dialup servers...
> 
> I set up a linux ppp server back in 1996 - things might have
> changed, but it seemed fairly straightforward at the time -
> 
> can't imagine it's gotten worse since then...
> 
> > Who out there is an expert on Linux pppd that would like
> > to help put together some easy configs for standard
> > dial-in scenarios?
> 
> Crunch time for me right now, finals coming right up...

Thank's anyway.  I'll keep working on the bugs.

:-)

Jeff

> 
> I'll bet there's quite a few ISP-savvy admins who could
> lend a hand though -
> 
> jjs
> 
-
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: *_trylock return on success?

[Rik van Riel]

On Sat, 25 Nov 2000, Roger Larsson wrote:

> Questions:
>   What are _trylocks supposed to return?

It depends on the type of _trylock  ;(

>   Does spin_trylock and down_trylock behave differently?
>   Why isn't the expected return value documented?

The whole trylock stuff is, IMHO, a big mess. When you
change from one type of trylock to another, you may be
forced to invert the logic of your code since the return
code from the different locks is different.

For bitflags, for example, the trylock returns the state
the bit had before the lock (ie. 1 if the thing was already
locked).

For spinlocks, it'll probably return something else ;/

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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/

CLONE_NAMESPACE, links for dirs and mount(2) for normal users questions

[Remi Turk]

Hi,

Long long ago, (March 2000) Alexander Viro replied to Pavel Machek:
>> Am I right that from now on each process can have completely different
>> view of filesystem like in plan9?
>
>Almost there ;-) And yes, the only thing we lack for proper namespaces is
>the union-directories (clone() bit is trivial).
Are there any patches already?
If not, where should I start to implement them?

Probably related to the first question, what about allowing mount(2)
(as a CONFIG-option) for normal user processes when they
have a) rw access to the device and b) are the owner/have rw-access
to the mountpoint. (There would be at least one security problem:
A normal user could mount a loopback ext2 filesystem with
panic-on-error (man tune2fs) and then corrupt it)

In April, Al Viro wrote:
> 1.  We should never have more than one dentry for a writable directory.
> 
> Print it and hang it on the wall. It's a fundamental requirement. There is
> no way to work around it in our VFS. I tried to invent a scheme that would
> allow that for more than a year. And I've done most of namespace-related code
> in our VFS since the moment when Bill Hawes stopped working on it, so I suspect
> that right now I have the best working knowledge of that stuff. There is no
> fscking way to survive multiple dentries for writable directory without major
> lossage. Period.
Do I understand correctly that this means hardlinks to directories
(except . and ..) are fundamentally impossible in Linux?
(I'm thinking about trying to write a garbage collected
filesystem with hardlinks to directories.)

-- 
Linux 2.4.0-test11 #1 Mon Nov 20 17:19:26 CET 2000
-
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/

[oops] Yenta on 2.4.0-test11 laptop (worked with test9)

[Pascal Brisset]

Is anyone using Yenta on a sony vaio laptop (PII-400) with 2.4.0-test11 ?

I can't even follow my own printk()s through the call to exca_writew()
in the trace below, so the system might be getting corrupted earlier
(possibly not in the cardbus code).

The same .config works on this machine with test9.


Unable to handle kernel NULL pointer dereference at virtual address 0008
c4828050
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 0008   ebx:    ecx: 0040   edx: 003c
esi:    edi: c482a3a0   ebp: c113bf24   esp: c113bee4
ds: 0018   es: 0018   ss: 0018
Process eventd (pid: 3, stackpage=c113b000)
Stack: c48288b3 c482a3a0 0008   c113bf24 c482a3a0 c482a300 
   c482a340 b22f c482911b c482a3a0 c113bf24 c482a3a0  c3ae5000 
    0001   0fff  c48292ad c482a3a0 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] 
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 c4 8b 5c 

>>EIP; c4828050 <[yenta_socket]exca_writew+0/4c>   <=
Trace; c48288b3 <[yenta_socket]yenta_set_io_map+8f/148>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482a300 <[yenta_socket]pci_socket_operations+0/30>
Trace; c482a340 <[yenta_socket]cardbus_table+10/38>
Trace; c482911b <[yenta_socket]yenta_clear_maps+6b/9c>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c48292ad <[yenta_socket]yenta_init+11/18>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c4829727 <[yenta_socket]ricoh_init+b/68>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482989a <[yenta_socket]pci_init_socket+2a/38>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c481fef8 <[pcmcia_core]init_socket+28/2c>
Trace; c481ffc0 <[pcmcia_core]pcmcia_register_socket+c4/128>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c4829bc6 <[yenta_socket]cardbus_register+22/2c>
Trace; c482a300 <[yenta_socket]pci_socket_operations+0/30>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c482909b <[yenta_socket]yenta_open_bh+93/a8>
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c4829e40 <[yenta_socket].rodata.start+180/310>
Trace; c01168cd 
Trace; c482a3a0 <[yenta_socket]__kstrtab_yenta_operations+0/0>
Trace; c0105000 
Trace; c01089ff 
Code;  c4828050 <[yenta_socket]exca_writew+0/4c>   <=
 <_EIP>:   <=
Code;  c4828060 <[yenta_socket]exca_writew+10/4c>
  10:   82(bad)  
Code;  c4828061 <[yenta_socket]exca_writew+11/4c>
  11:   c4 8b 5c 00 00 00 les0x5c(%ebx),%ecx


1 warning issued.  Results may not be reliable.



Linux version 2.4.0-test11 (root@pcg) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #1 Sat Nov 25 11:34:01 MET 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009f800 @  (usable)
 BIOS-e820: 0800 @ 0009f800 (reserved)
 BIOS-e820: 00017800 @ 000e8800 (reserved)
 BIOS-e820: 03ef @ 0010 (usable)
 BIOS-e820: f800 @ 03ff (ACPI data)
 BIOS-e820: 0800 @ 03fff800 (ACPI NVS)
 BIOS-e820: 0008 @ fff8 (reserved)
On node 0 totalpages: 16368
zone(0): 4096 pages.
zone(1): 12272 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux-2.4.0 ro root=302 1 ro
Initializing CPU#0
Detected 397.002 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 792.99 BogoMIPS
Memory: 62696k/65472k available (882k kernel code, 2388k reserved, 53k data, 172k 
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 0183f9ff  , vendor = 0
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183f9ff   
CPU: After generic, caps: 0183f9ff   
CPU: Common caps: 0183f9ff   
CPU: Intel Mobile Pentium II stepping 0d
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd99e, last bus=1
PCI: 

Re: 2.4.0-test11: "_isofs_bmap: block < 0"

[Arjan Filius]

Hello,

Same here with CD 1 from SuSE 7.0-DE :
Nov 25 18:16:03 sjoerd kernel: VFS: Disk change detected on device ide1(22,64)
Nov 25 18:16:05 sjoerd kernel: ISO 9660 Extensions: RRIP_1991A
Nov 25 18:16:05 sjoerd kernel: _isofs_bmap: block < 0

Using test11 and everything is a module.


On 21 Nov 2000, Eugene Crosser wrote:

> I have a cdrom with iso9660+RR filesystem, with a few hundred files in
> ten directories.  With all previous kernels (checked up to test11-pre3),
> I had no problems with it.  With test11 final, "ls" command shows
> zero entries on the mounted CD, and each "ls" attempt causes this
> kernel message:
> 
> _isofs_bmap: block < 0
> 
> If I open a file directly, it opens and is read fine, so it's only
> readdir() that is not working.  Tell me if I need to provide more info.
> 
> Eugene
> -
> 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/
> 

-- 
Arjan Filius
mailto:[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: gcc-2.95.2-51 is buggy

[Rik van Riel]

On Fri, 24 Nov 2000, Neil Brown wrote:
> On Friday November 24, [EMAIL PROTECTED] wrote:
> > >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
> > 
> > > Now, if you can isolate the relevant part of the diff between
> > > 2.95.2 and RH 2.96...
> > 
> > Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".

[image from FTP site not buggy]

> > This is from a SuSE distribution, I forget which, not very recent.
> > Revised summary: gcc-2.95.2-51 from SuSE is buggy.
> 
> Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the
> same bug. Debian applies a total of 49 patches to gcc and the
> libraries.

The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.

(and the ISO images haven't even been available for
one week yet ... *sigh*)

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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: Fasttrak100 questions...

[Andre Hedrick]

Oh remember, I DEFINED the terms that the module could be created!
Go and examine the wrapper and it is portions of the pdc202xx.c code that
is mine.  With that in mind, in order to use that GPL code, the
restrictions and terms imposed were module exclusive.

Regards,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

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

Re: Oops on 2.2.18-23 as pppd dial in server

[Chmouel Boudjnah]

"Jeff V. Merkey" <[EMAIL PROTECTED]> writes:

> Was able to reproduce this Oops, but it took several days.   Oops occurs
> against 2.2.18-23.  I had to copy this info from the console -- the
> system was hard hung after the oops and even ksymoops was locked solid.

what type of mounted filesystem you have (dos/ext2) ?

-- 
MandrakeSoft Inc http://www.chmouel.org
  --Chmouel
-
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: Fasttrak100 questions...

[Andre Hedrick]

On Sat, 25 Nov 2000, Henning P. Schmiedehausen wrote:

> No, it does not. Distributing does. You will never get this right. You
> can compile into your kernel anything you like as long as you don't
> give it away.

And you will never boot it because the resources conflict with out the
module, go try it.  I promise you that it will never boot if you build it
in the kernel.  Also the terms of acceptance of the module also means you
can not built it inter the kernel.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

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

Re: [PATCH] blindingly stupid 2.2 VM bug

[Rik van Riel]

On Sat, 25 Nov 2000, Andrea Arcangeli wrote:

> VM-global-*-7 has no known bugs AFIK.

Sure, I don't use 2.2 anyway ;)

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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: setting up pppd dial-in on linux

[William Scott Lockwood III]

Jeff,
  I am also VERY interested in this, particularly on getting modems to work
with Linux at all.  I'm not reading the list right now, but I'd appreciate
any feedback you can throw my way on this.   Esp. if you DO get it setup and
working.  It sure would be nice to see Linux FINALLY support more modems out
there.  Hell, my Internal USR ISA modem is not even supported, but FreeBSD
had had support for it for a long time now.  :-(  Please let me know what
you find out, and I'm VERY interested in your RPM - hope there will be a
straight tarball for us Slackware Dinosaurs too.  :-)

Scott

- Original Message -
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 25, 2000 1:36 AM
Subject: setting up pppd dial-in on linux


>
>
> Anyone out there a whiz at setting up a pppd dialin server?  I am
> trying to put together an RPM for pppd dialin configurations
> that will support default Windows NT and Linux dial in clients
> without requiring the poor user to learn bash scripting, chat
> scripting, mgetty and inittab configuration, etc.  The steps
> in setting this up are about as easy as going on a U.N. relief
> mission to equatorial Africa, and most customers who are
> "mere mortals" would give up about an hour into it.
>
> I am seeing massive problems with pppd dial-in and IP/IPX
> routing with problems that range from constant Oops, to
> the bug infested pppd daemon failing valid MD5 chap
> authentication.  The HOW-TO's and man pages provide
> wonderful commentary on all the things about pppd
> that don't work, but it's not too helpful on getting
> it to work reliably.  An NT dial-in server takes about
> 5 minutes to configure on W2K.  Linux takes about 2 days, and
> won't stay up reliably.
>
> Who out there is an expert on Linux pppd that would like
> to help put together some easy configs for standard
> dial-in scenarios?
>
> Thanks
>
> 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/
>
-
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-test11 (pre1, final) OOPS during boot/modprobe

[Keith Owens]

On Sat, 25 Nov 2000 11:21:16 -0500, 
"Steven S. Dick" <[EMAIL PROTECTED]> wrote:
>On Sat, Nov 25, 2000 at 12:27:24PM +, Russell King wrote:
>> Keith Owens writes:
>> Steven probably wants to apply this patch to test11:
>
>How about we apply both that patch and this one?

Both already sent to Linus and Alan Cox.

-
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-test11 (pre1, final) OOPS during boot/modprobe

[Steven S. Dick]

On Sat, Nov 25, 2000 at 12:27:24PM +, Russell King wrote:
> Keith Owens writes:
> Steven probably wants to apply this patch to test11:

How about we apply both that patch and this one?

diff -u linux/Documentation/Changes.old linux/Documentation/Changes
--- linux/Documentation/Changes.old Sat Nov 25 11:18:00 2000
+++ linux/Documentation/Changes Sat Nov 25 11:18:28 2000
@@ -52,7 +52,7 @@
 o  Gnu make   3.77# make --version
 o  binutils   2.9.1.0.25  # ld -v
 o  util-linux 2.10o   # kbdrate -v
-o  modutils   2.3.18  # insmod -V
+o  modutils   2.3.21  # insmod -V
 o  e2fsprogs  1.19# tune2fs --version
 o  pcmcia-cs  3.1.21  # cardmgr -V
 o  PPP2.4.0   # pppd --version
-
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/

Announce: DProbes/LTT interoperability and custom event logging

[Karim Yaghmour]

As you've probably seen from Richard's announcement, it is now
possible to use the LTT/DProbes pair to dynamically insert trace
points anywhere in the system.

That said, the added functionnality to LTT also enables kernel/
module programmers to dynamically add trace types and log the
corresponding events in the trace.

The following functions have been added to provide this capability:
int  trace_create_event
   (char*/* String describing event type */,
char*/* String to format event description */,
event_data_desc* /* Table containing data formatting details */);
void trace_destroy_event
   (int   /* The event ID given by trace_create_event() */);
void trace_reregister_custom_events
   (void);
int  trace_formatted_event
   (int   /* The event ID given by trace_create_event() */,
...   /* The parameters to be printed out in the event string */);
int  trace_raw_event
   (int   /* The event ID given by trace_create_event() */,
int   /* The size of the raw data */,
void* /* Pointer to the raw event data */);


The following is an example module that uses this functionnality to
log custom events in the trace:

#define MODULE

#define CONFIG_TRACE

#include 
#include 
#include 
#include 

struct delta_event
{
  int   an_int;
  char  a_char;
};

static int alpha_id, omega_id, theta_id, delta_id, rho_id;

int init_module(void)
{
  uint8_t a_byte;
  char a_char;
  int an_int;
  int a_hex;
  char* a_string = "We are initializing the module";
  struct delta_event a_delta_event;

  /* Create events */
  alpha_id = trace_create_event("Alpha",
"Number %d, String %s, Hex %08X",
NULL);
  omega_id = trace_create_event("Omega",
"Number %d, Char %c",
NULL);
  theta_id = trace_create_event("Theta",
"Plain string",
NULL);
  delta_id = trace_create_event("Delta",
NULL,
NULL);
  rho_id = trace_create_event("Rho",
  NULL,
  NULL);

  /* Trace events */
  an_int = 1;
  a_hex = 0x;
  trace_formatted_event(alpha_id, an_int, a_string, a_hex);
  an_int = 25;
  a_char = 'c';
  trace_formatted_event(omega_id, an_int, a_char);
  trace_formatted_event(theta_id);
  memset(&a_delta_event, 0, sizeof(a_delta_event));
  trace_raw_event(delta_id, sizeof(a_delta_event), &a_delta_event);
  a_byte = 0x12;
  trace_raw_event(rho_id, sizeof(a_byte), &a_byte);

  return 0;
}

void cleanup_module(void)
{
  uint8_t a_byte;
  char a_char;
  int an_int;
  int a_hex;
  char* a_string = "We are initializing the module";
  struct delta_event a_delta_event;

  /* Trace events */
  an_int = 324;
  a_hex = 0xABCDEF10;
  trace_formatted_event(alpha_id, an_int, a_string, a_hex);
  an_int = 789;
  a_char = 's';
  trace_formatted_event(omega_id, an_int, a_char);
  trace_formatted_event(theta_id);
  memset(&a_delta_event, 0xFF, sizeof(a_delta_event));
  trace_raw_event(delta_id, sizeof(a_delta_event), &a_delta_event);
  a_byte = 0xA4;
  trace_raw_event(rho_id, sizeof(a_byte), &a_byte);

  /* Destroy the events created */
  trace_destroy_event(alpha_id);
  trace_destroy_event(omega_id);
  trace_destroy_event(theta_id);
  trace_destroy_event(delta_id);
  trace_destroy_event(rho_id);
}


This is the resulting output in the trace dump:
Memory  975,040,616,826,952 494 14  PAGE ALLOC ORDER : 0
Memory  975,040,616,826,957 494 14  PAGE FREE ORDER : 0
Memory  975,040,616,826,958 494 14  PAGE FREE ORDER : 0
Event creation  975,040,616,826,964 494 146 NEW EVENT TYPE : Alpha
Event creation  975,040,616,826,967 494 146 NEW EVENT TYPE : Omega
Event creation  975,040,616,826,970 494 146 NEW EVENT TYPE : Theta
Event creation  975,040,616,826,972 494 146 NEW EVENT TYPE : Delta
Event creation  975,040,616,826,974 494 146 NEW EVENT TYPE : Rho
Alpha   975,040,616,826,988 494 80  Number 1, String We 
are initializing the module, Hex 
Omega   975,040,616,826,991 494 36  Number 25, Char c
Theta   975,040,616,826,993 494 31  Plain string
Delta   975,040,616,826,994 494 26  00 00 00 00 00 00 00 
00 
Rho 975,040,616,826,995 494 19  12 
Syscall exit975,040,616,826,996 494 6   
Syscall entry   975,040,616,827,028 494

Re: [PATCH] G450 support for matroxfb

[Vojtech Pavlik]

On Sat, Nov 25, 2000 at 04:36:50PM +0100, Willy Tarreau wrote:
> > BTW, XF4.0.1e is also very unhappy on this hardware.
> > Best regards,
> > Petr Vandrovec
> > [EMAIL PROTECTED]
> 
> does the Matrox driver work with it ? My G400 works very well with the one I
> found on this site, and the G450 is also referenced :
> 
> http://www.matrox.com/mga/support/drivers/latest/home.htm

Well, XF4.0.1e should work with it if compiled with mgaHALlib.a ...
The Matrox driver referenced above uses this lib.

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

2.4.0-test{8..11} CONFIG_NETLINK*=y => unresolved symbol errors in several modules

[Karl M. Hegbloom]

 Sorry if this is already reported; I'm not subscribed since it's way
 over my head still and there's too much else to do...  so, please CC
 me if you need more input.

 I'm goofing around trying to get the right options set so I can run
 `dhcpd' and `vtun'...  I accidently turned on the "netlink" in
 "networking options", and found that `depmod -a' mentions several
 unresolved symbol errors.  One module in particular is `ipchains.o'
 that does this.  Upon reboot and attempted `modprobe ipchains', I see
 "netlink" mentioned, IIRC.  There is conditionalization in the
 "ipchains_core.c" on whether netlink is configured in, so I think
 this is correct information.

 Hope you can find it and fix it in only a few minutes.  It will take
 me another few years to do so, I believe.
-
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] G450 support for matroxfb

[Willy Tarreau]

> BTW, XF4.0.1e is also very unhappy on this hardware.
>   Best regards,
>   Petr Vandrovec
>   [EMAIL PROTECTED]

does the Matrox driver work with it ? My G400 works very well with the one I
found on this site, and the G450 is also referenced :

http://www.matrox.com/mga/support/drivers/latest/home.htm

Cheers,
Willy
-
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_card_id tables for all isapnp drivers in2.4.0-test11

[Kai Germaschewski]

On Sat, 25 Nov 2000, Keith Owens wrote:

> On Fri, 24 Nov 2000 15:37:33 -0800,
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> > Note that this is not a "final" version.  I plan to go
> >through all of the changes and bracket all of these new tables
> >with #ifdef MODULE...#endif so they do not result in complaints
> >about the table being defined static and never used in cases where
> >the driver is compiled directly into the kernel.
>
> This is cleaner.  Append MODULE_ONLY after __initdata and remove the
> ifdef.  It increases the size of initdata in the kernel, compared to
> ifdef, but since initdata is promptly reused as scratch space it should
> not be a problem.
>
> Index: 0-test11.1/include/linux/module.h
> --- 0-test11.1/include/linux/module.h Sun, 12 Nov 2000 14:59:01 +1100 kaos 
>(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3 644)
> +++ 0-test11.1(w)/include/linux/module.h Sat, 25 Nov 2000 12:40:10 +1100 kaos 
>(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3 644)
> @@ -261,6 +261,7 @@ extern struct module __this_module;
>  #define MOD_INC_USE_COUNT__MOD_INC_USE_COUNT(THIS_MODULE)
>  #define MOD_DEC_USE_COUNT__MOD_DEC_USE_COUNT(THIS_MODULE)
>  #define MOD_IN_USE   __MOD_IN_USE(THIS_MODULE)
> +#define MODULE_ONLY  __attribute__ ((unused))

What about the making MODULE_DEVICE_TABLE reference this table? This has
the same disadvantage (i.e. having a little unneeded __initdata in the
kernel image), but it wouldn't need the rather ugly MODULE_ONLY macro.

I'ld suggest something like this in module.h, #ifndef MODULE part:

#define MODULE_DEVICE_TABLE(type,name) \
static struct type##_device_id *__dummy_##name \
   __attribute__ ((unused, __section__(".text.exit"))) \
   = name;

This references the table (the variable holding the reference is in
text.exit and thus discarded at link time), maybe there's an easier way to
accomplish this. This of course smells like a hack, but at least it's
hidden away from the drivers ;-)

--Kai


-
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: LKCD from SGI

[64738]

Hello,

in the last time I got several e-mails from you, but that must be a mistake 
because I do not know you and I don´t know why you send me these e-mails. 
Please check whether you have the address [EMAIL PROTECTED] in your 
address-book. Please delete this address!! In past you have put this address in 
the field: copy and blind-copy.

Thank you very much!

Jan Woschinski
Schwung (University of Mannheim)
-
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/

*_trylock return on success?

[Roger Larsson]

Hi,

Background information:
 compiled and tested a test11 with the Montavista preemptive patch.
 After pressing Magic-SysRq-M all processes that tried to do IO hung in 'D'
 Last message "Buffer memory ..."
 Pressing Magic-SysRq-M again, all hung processes continued...

Checking the patch it looks like this

printk("Buffer memory:   %6dkB\n",
atomic_read(&buffermem_pages) << (PAGE_SHIFT-10));

-#ifdef CONFIG_SMP /* trylock does nothing on UP and so we could deadlock */
-   if (!spin_trylock(&lru_list_lock))
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
+   if (!mutex_trylock(&lru_list_mtx))
return;
for(nlist = 0; nlist < NR_LIST; nlist++) {

Ok, so I run some more code now than before (UP system with PREEMPT).
mutex_trylock is defined as:

+#define mutex_trylock(x) down_trylock(x)

Noticed that if the spin_trylock returns 0 on success, I will get the 
behavior I see.
  Not printing buffer info first time.
  Holding the lock - stopping other fs processes.
  Failing the mutex_trylock next attempt, interprete as success
  - continuing and printing the buffer info.
  - finally release the mutex

I removed the not (!) and now it works as expected.

Questions:
  What are _trylocks supposed to return?
  Does spin_trylock and down_trylock behave differently?
  Why isn't the expected return value documented?
  
/RogerL

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

anounce: Universal dynamic trace for Linux

[richardj_moore]

You can now use IBM's DProbes with Opersys' Linux Trace Toolkit to provide
a universal (dynamic) tracing capability for Linux.

It is universal because it provides a common tracing mechanism for all
executables whether in user or kernel space. It is dynamic because
tracepoints are defined and applied dynamically to object modules as
probepoints using DProbes - no source code modification is required.

To use dyamic trace you will require version 1.2 of DProbes, or later from
http://oss.software.ibm.com/
and LTT version 0.9.4pre4 or later from http://www.opersys.com/

The DProbes kernel patch will need to be compiled with correct
configuration options to enable it to work with LTT. See the respective
installation instructions in each package for more details.


Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).

http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


-
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: [BUG?] test11 - oops on loading some modules

[Keith Owens]

On Sat, 25 Nov 2000 15:59:30 +0200, 
Oren Held <[EMAIL PROTECTED]> wrote:
>I patched my test10 directly to test11 (I didn't use the PREs, so I
>can't

Upgrade to modutils 2.3.21.

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

[BUG?] test11 - oops on loading some modules

[Oren Held]

Hello !

I patched my test10 directly to test11 (I didn't use the PREs, so I
can't
say which exact version caused my problem, though if it's
important I can check that). Anyway, after I saw the problem, I
downloaded the whole kernel tree to see if it's not just some patching
problem, but it still happens:

Some of the modules I load (bttv.o , eepro.o , ide-scsi.o), return a
kernel oops, and since then I see them in lsmod stuck in that position:
bttv   55460   1  (initializing)

It seems to me like a problem with modules loading (some of these
modules weren't changed since test10)..
Here's an example of the oops that bttv.o returns:


bttv0: model: BT848A(Fly Video II) [insmod option]
Unable to handle kernel paging request at virtual address 0001
printing eip:
c8852050
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010202
eax: 0001   ebx: c8868748   ecx: fffb   edx: c886b110
esi: c88683bc   edi: c8868660   ebp: c8868748   esp: c7455e88
ds: 0018   es: 0018   ss: 0018
Process insmod (pid: 403, stackpage=c7455000)
Stack: c8858169 c8868660 c8868748 c88683bc c8868666 c8868660 c885c2b7
c8868660
   c8868500 0001 c8868500 0001 c8868665 c88648e5 
0282
   c8868500 c887d000 d8a4 c8861e5b c8868500  c8868500
c12ed400
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[]
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 ff 09 0f



Bye,
Oren.

-
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] blindingly stupid 2.2 VM bug

[Andrea Arcangeli]

+   /* Only lower priority if we didn't make progress. */
+   if (count == loopcount)
+   --priority;
+   loopcount = count;

If the while loops around the page-recycling-methods were missing we would
have just noticed as soon as we needed to recycle some byte of cache.

+   /* Return success if we have enough free memory or we freed a page. */
+   if (nr_free_pages > freepages.low)
+   return 1;

This anti-kill-flood check is just handled by the GFP layer (you don't
need to replicate it here in the memory balancing layer). It's currently
done against freepages.high to stay conservative (it's meant to catch
a task killed while we were blocked; a task killed will certainly
raise nr_free_pages over freepages.high).

+   return count < SWAP_CLUSTER_MAX;

This will make oom handling less graceful and if memory balancing
fails wrongly when the machine isn't truly oom this will only hide the problem
(and if there's a real problem like we had with MAP_SHARED and
always-async-kpiod [fixed by VM-global] it won't even be enough to hide it).


VM-global-*-7 has no known bugs AFIK.

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: LKCD from SGI

[J . A . Magallon]

On Sat, 25 Nov 2000 14:23:57 Keith Owens wrote:
> On Sat, 25 Nov 2000 14:18:30 +0100, 
> "J . A . Magallon" <[EMAIL PROTECTED]> wrote:
> >Could the default target install names int the std kernel be changed to 
> >System.map -> System.map-$(KERNELRELEASE)
> >vmlinuz-> vmlinuz-$(KERNELRELEASE)
> >and then symlink to that ?
> 
> We could do a lot of things in the install targets.  But none of them
> are going to be done before kernel 2.5.  We are in code freeze (is this
> freeze number 4 or 5?).  Changing the install method just before a new
> kernel branch is released will not be popular with the distributors.

Yes, I know. I thought you were talking about '2.5 kernel build wish list'.

-- 
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

Linux 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET 2000 i686 unknown

-
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: LKCD from SGI

[Matthew Kirkwood]

On Sat, 25 Nov 2000, J . A . Magallon wrote:

> Could the default target install names int the std kernel be changed to 
> System.map -> System.map-$(KERNELRELEASE)
> vmlinuz-> vmlinuz-$(KERNELRELEASE)
> and then symlink to that ?
>
> I think everyone that has a stable2.2, a devel 2.2 and a test24 is
> using that method, so as many distros...

The /sbin/installkernel hooks allow you to do this (and
other stuff) very easily:

# make install

does it all for you on Red Hat.  I've attached their
/sbin/installkernel in case you want to see how its
done.

Matthew.


#! /bin/sh

#
# /sbin/installkernel  - written by [EMAIL PROTECTED]
#

INSTALL_PATH=/boot

KERNEL_VERSION=$1
BOOTIMAGE=$2
MAPFILE=$3

if [ -f $INSTALL_PATH/vmlinuz-$KERNEL_VERSION ]; then 
  mv $INSTALL_PATH/vmlinuz-$KERNEL_VERSION \
  $INSTALL_PATH/vmlinuz.old;
fi

if [ -f $INSTALL_PATH/System.map-$KERNEL_VERSION ]; then 
  mv $INSTALL_PATH/System.map-$KERNEL_VERSION \
  $INSTALL_PATH/System.map.old; 
fi

cat $BOOTIMAGE > $INSTALL_PATH/vmlinuz-$KERNEL_VERSION
cp $MAPFILE $INSTALL_PATH/System.map-$KERNEL_VERSION

ln -fs vmlinuz-$KERNEL_VERSION $INSTALL_PATH/vmlinuz
ln -fs System.map-$KERNEL_VERSION $INSTALL_PATH/System.map

if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi

Re: setting up pppd dial-in on linux

[Pedro M. Rodrigues]

   You are not alone. And the problem gets even worse when you 
have to deal with ISDN devices. In my company´s data room we 
have all Linux servers running 365 days a year (minus upgrade 
time) and in one corner a lonely Windows NT Server 3.0 with 5 
Client Access Licenses working as a RAS server for 2 Diva Server 
BRI cards (4 analog/digital channels) plus one analog modem. 
Time to set it up? Half an hour counting NT installation. Time i lost 
investigating and trying different configurations, dealing with 
contradictory documentation, chat scripts, different ipppd versions, 
and authentication failures? 2 days. At Ieast i cant complain about 
pppd oops, as you do, the pppd in RH6.2 seemed solid. The 
document of reference that seemed more interesting to me at the 
time was http://www.swcp.com/~jgentry/pers.html  , have a look 
please.


Regards,
Pedro

On 25 Nov 2000, at 0:36, Jeff V. Merkey wrote:

> 
> 
> Anyone out there a whiz at setting up a pppd dialin server?  I am 
> trying to put together an RPM for pppd dialin configurations
> that will support default Windows NT and Linux dial in clients
> without requiring the poor user to learn bash scripting, chat 
> scripting, mgetty and inittab configuration, etc.  The steps
> in setting this up are about as easy as going on a U.N. relief
> mission to equatorial Africa, and most customers who are 
> "mere mortals" would give up about an hour into it.
> 
> I am seeing massive problems with pppd dial-in and IP/IPX 
> routing with problems that range from constant Oops, to 
> the bug infested pppd daemon failing valid MD5 chap 
> authentication.  The HOW-TO's and man pages provide 
> wonderful commentary on all the things about pppd 
> that don't work, but it's not too helpful on getting
> it to work reliably.  An NT dial-in server takes about
> 5 minutes to configure on W2K.  Linux takes about 2 days, and 
> won't stay up reliably.  
> 
> Who out there is an expert on Linux pppd that would like
> to help put together some easy configs for standard 
> dial-in scenarios?
> 
> Thanks
> 
> 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/
> 


-
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: LKCD from SGI

[Keith Owens]

On Sat, 25 Nov 2000 14:18:30 +0100, 
"J . A . Magallon" <[EMAIL PROTECTED]> wrote:
>On Sat, 25 Nov 2000 02:58:37 Keith Owens wrote:
>> 2.5 kernel build wish list[1] has a couple of entries for standardising
>> the install targets.  My thinking (and I know that some people disagree
>> with this) is that the standard targets of a linux compile are only
>> 
>> * vmlinux
>> * System.map
>> * modules in the kernel tree (not installed yet)
>> * any other bits and pieces that are required to compile external
>>   modules against this config.
>
>Could the default target install names int the std kernel be changed to 
>System.map -> System.map-$(KERNELRELEASE)
>vmlinuz-> vmlinuz-$(KERNELRELEASE)
>and then symlink to that ?

We could do a lot of things in the install targets.  But none of them
are going to be done before kernel 2.5.  We are in code freeze (is this
freeze number 4 or 5?).  Changing the install method just before a new
kernel branch is released will not be popular with the distributors.

-
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: LKCD from SGI

[J . A . Magallon]

On Sat, 25 Nov 2000 02:58:37 Keith Owens wrote:
> 
> 2.5 kernel build wish list[1] has a couple of entries for standardising
> the install targets.  My thinking (and I know that some people disagree
> with this) is that the standard targets of a linux compile are only
> 
> * vmlinux
> * System.map
> * modules in the kernel tree (not installed yet)
> * any other bits and pieces that are required to compile external
>   modules against this config.
> 

Could the default target install names int the std kernel be changed to 
System.map -> System.map-$(KERNELRELEASE)
vmlinuz-> vmlinuz-$(KERNELRELEASE)
and then symlink to that ?

I think everyone that has a stable2.2, a devel 2.2 and a test24 is using that
method, so as many distros...

-- 
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

Linux 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET 2000 i686 unknown

-
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 with NM256 and APM

[Paul Warren]

I have a problem with APM interfering with sound playback through a
NeoMagic 256.  

If I have sound playing, and do a "cat /proc/apm" I get a noticeable
glitch in sound playback.  The glitch sounds like playback skips
backwards by a fraction of a second.

The machine is a Dell Latitude CS, and I have seen this problem on
2.2.17 and 2.4.0test11.

The anonymous author of the NM256 driver claims to have not seen this
problem before.

dmesg says:

apm: BIOS version 1.2 Flags 0x03 (Driver version 1.13)
...
NeoMagic 256AV/256ZX audio driver, version 1.1
NM256: Found card signature in video RAM: 0x3fec00
NM256: Mapping port 1 from 0x3e6c00 - 0x3fec00
Initialized NeoMagic 256ZX audio in PCI native mode
Initialized AC97 mixer
Done installing NM256 audio driver.

Any clues as to what might be behind this?

cheers,

Paul
-
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-test11 (pre1, final) OOPS during boot/modprobe

[Keith Owens]

On Sat, 25 Nov 2000 12:27:24 + (GMT), 
Russell King <[EMAIL PROTECTED]> wrote:
>Keith Owens writes:
>> On Sat, 25 Nov 2000 06:10:54 -0500 (EST), 
>> [EMAIL PROTECTED] (Steven S. Dick) wrote:
>> >2.4.0-test11-pre1 seems to have broken something.
>> >I have no problems with test10, but test11-pre1 gives three oops
>> >messages during boot.  test11-final gives the exact same OOPS messages...
>> 
>> Which modutils?  And if it is not 2.3.21, upgrade.
>
>Steven probably wants to apply this patch to test11:

Upgrading to modutils 2.3.21 is easier and everybody should do that
anyway to fix the local root exploits.

-
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-test11 (pre1, final) OOPS during boot/modprobe

[Russell King]

Keith Owens writes:
> On Sat, 25 Nov 2000 06:10:54 -0500 (EST), 
> [EMAIL PROTECTED] (Steven S. Dick) wrote:
> >2.4.0-test11-pre1 seems to have broken something.
> >I have no problems with test10, but test11-pre1 gives three oops
> >messages during boot.  test11-final gives the exact same OOPS messages...
> 
> Which modutils?  And if it is not 2.3.21, upgrade.

Steven probably wants to apply this patch to test11:

--- orig/kernel/module.cWed Nov 22 14:08:23 2000
+++ linux/kernel/module.c   Sat Nov 25 10:40:26 2000
@@ -480,7 +480,9 @@
 
/* Ok, that's about all the sanity we can stomach; copy the rest.  */
 
-   if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {
+   if (copy_from_user((char *)mod+mod_user_size,
+  (char *)mod_user+mod_user_size,
+  mod->size-mod_user_size)) {
error = -EFAULT;
goto err3;
}

   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Fasttrak100 questions...

[Henning P. Schmiedehausen]

[EMAIL PROTECTED] (Andre Hedrick) writes:

>NO!

>Doing so VIOLATES the terms and agreement that you obtained the BINARY
>Soft-Raid Engine and the GPL terms of the kernel.

>On Fri, 24 Nov 2000, James Lamanna wrote:
[...]
>> The question is, is there a way to compile this module into the kernel
>> so that it will automatically detect the card? A simple linking of the
>> module into the scsi library by editing the Makefile doesn't seem to do
>> it. It doesn't detect the drives if I boot off of a floppy with this
>> kernel on it.
[...]

No, it does not. Distributing does. You will never get this right. You
can compile into your kernel anything you like as long as you don't
give it away.

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen   -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20   
-
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: silly [< >] and other excess

[Russell King]

Albert D. Cahalan writes:
> Yes. Don't you look at the raw data anyway?

I look at the raw stack data from time to time, but mostly I want
the backtrace, PC and LR converted into something more meaningful,
and I don't want the extra clutter of that particular raw data.

> In theory yes, but in practice no. Your kernel isn't a significant
> portion of your address space, so the chance of random data being
> looked up successfully is very low. Maybe a 1% chance on 32-bit
> hardware, and far less on 64-bit hardware.

Not so.  This is my point; on the ARM, when you get stuff like stack
and registers dumped, a lot of the hex numbers can look very much like
addresses in kernel space; most of them are data object symbols and
the like.  There can be a lot of these, and suddenly you'd end up with
most of the System.map being output because something in the dump
somewhere looks like its a symbol.

> Somebody else posted a reasonable hack for the [<>] problem.
> His proposal involved letting multiple values share the same
> markers, something like this:

Yep, now that is one idea I like!
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: silly [< >] and other excess

[Albert D. Cahalan]

Keith Owens writes:
> "Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:

>> Somebody else posted a reasonable hack for the [<>] problem.
>> His proposal involved letting multiple values share the same
>> markers, something like this:
>>
>> []
>
> What happens if the line is wrapped before being fed to ksymoops?  That
> happens quite often.

You code handles far worse already, plus getting rid of all the
extra junk will make word wrapping far less common.

Robust tools don't fail just because the data isn't in one of 42
different hard-coded formats, and don't fail because of word-wrap.

> What happens with the IKD patch which adds values
> between the addresses from stack?

So use a different marker... those users with IKD are quite a bit
more likely to have a serial console anyway, so it matters little.
The current over-size format would be fine.

> Why am I even bothering to reply to
> these messages?

You are guilty of causing data loss via scrolling, and you know it.
It is not good that your choice of regular expressions should dictate
that we get stuck with oopses that don't fit on the standard screen.

> Trying to shrink the oops log to fit on a screen is an exercise in
> futility.  How do you propose to make this IA64 oops fit on 80x24?

I didn't have much trouble, even while keeping it somewhat readable.
The actual data is worth much more than register names that are
exactly the same for every oops, so it is obvious what to chop out.

> Or this one from arm?  Even without markers it is 82x47.

If the standard ARM console can hold 82x47 then that is OK.
If nearly all ARM systems are embedded devices with a serial
console, then again there is no problem. If VGA is common,
then this is a bug.

> Or this one from sparc, 106x26?  No, you cannot merge the callers
> onto multiple lines, on some traces the caller address is followed
> by the parameters to the function.

Oh yes I can merge them, using a '/' as a separator. There are plenty
of other options... but isn't the SPARC console usually 128-wide anyway?

> But hand copying an oops from an 80x24 screen
> is not going to work in the long term, see above.  Fiddling with the
> output format is a waste of time, instead work out how to capture the
> oops without relying on hand copying or a limited screen size.  Fix the
> problem, not the symptom.

The 80x25 screen really must work. Normal users don't have serial
consoles, JTAG connections, ROM-based debuggers, or anything else
reliable that can be used to capture a crash 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: 2.4.0-test11 (pre1, final) OOPS during boot/modprobe

[Keith Owens]

On Sat, 25 Nov 2000 06:10:54 -0500 (EST), 
[EMAIL PROTECTED] (Steven S. Dick) wrote:
>2.4.0-test11-pre1 seems to have broken something.
>I have no problems with test10, but test11-pre1 gives three oops
>messages during boot.  test11-final gives the exact same OOPS messages...

Which modutils?  And if it is not 2.3.21, upgrade.

-
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] removal of "static foo = 0" from drivers/ide (test11)

[Russell King]

Rusty Russell writes:
> What irritates about these monkey-see-monkey-do patches is that if I
> initialize a variable to NULL, it's because my code actually relies on
> it; I don't want that information eliminated.

What information is lost?  Unless you're working on a really strange
machine which does not zero bss, the following means the same from the
codes point of view:

static int foo = 0;
static int foo;

Both are initialised to zero by the time the code sees them for the
first time.  Therefore there is no difference to the code in its reliance
on whether foo is zero.  foo will be zero in both cases.

Also, any good programmer worth their skin should know this, and should
realise it.  Therefore, there is no information loss about what value
that variable is expected to hold at initialisation time.

The only difference is the size on disk; if we go around setting every
bss variable to zero, the kernel/module data size will unnecessarily
huge.

We already argue about the extra couple of bytes that xx change to the
kernel/a module would cost.  With these change, we save kilo-bytes in
disk space (which is important on some systems).
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)

[Russell King]

J . A . Magallon writes:
> ANSI rules for C say that uninitialized vars get a 0, but you can't trust
> on the ANSI behaviour of a compiler.

It has nothing to do with the compiler, but everything to do with the
C startup code.  In the Linux kernel, we have complete control over the
C startup code - it is in arch/*/kernel/head.S.

The only way a compiler can break this is if it creates a new section
.bss_im_not_going_to_allow_anyone_to_initialise_this and places all
the variables in there.  Hardly likely, don't you think?

The initialisation of .bss is a run-time issue, NOT a compiler issue.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test11 (pre1, final) OOPS during boot/modprobe

[Steven S. Dick]

2.4.0-test11-pre1 seems to have broken something.
I have no problems with test10, but test11-pre1 gives three oops
messages during boot.  test11-final gives the exact same OOPS messages...

Of the three, only the first one decodes to anything useful:

Unable to handle kernel paging request at virtual address c86bd1e0 
 printing eip: 
c4890060 
*pde =  
Oops:  
CPU:0 
EIP:
0010:[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-12192/80] 
EFLAGS: 00010a82 
eax: c4890050   ebx: c3fcb400   ecx: c489101c   edx:  
esi: c4891160   edi: c4891160   ebp: c48912d4   esp: c36fbee8 
ds: 0018   es: 0018   ss: 0018 
Process modprobe (pid: 201, stackpage=c36fb000) 
Stack: c01b74fc c3fcb400 c489101c c3fcb400  c01b7554 c4891160 c3fcb400  
   c489 c489098c 0001 c4890996 c4891160 c0117d2d c36fa000 08065490  
   08061760 bfffe164 0001 c488d000 c488d000 c36fbf60 004c c48912c0  
Call Trace: [pci_announce_device+44/64] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-8164/80] 
[pci_register_driver+68/92] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-7840/80] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-12288/80] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-9844/80] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-9834/80]  
   [nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-7840/80] 
[sys_init_module+1409/1568] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-24576/80] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-24576/80] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-7488/80] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-24576/80] 
[nfsd:__insmod_nfsd_O/lib/modules/2.4.0-test11/kernel/fs/nfsd/nfs+-12192/80] 
[system_call+51/64]  
Code: 12 89 c4 c1 e2 03 89 44 24 18 89 54 24 1c 40 8b 8a c8 0f 89  

The addresses are different, but the stack trace is identical,
between test-11(pre1) and test11(final).

I think the oops's each correspond to a modprobe.

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

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