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

[Tigran Aivazian]

On Tue, 28 Nov 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > First, they are not trivially equivalent. In fact, they are not
> > equivalent at all.  Any good C book should tell you that one places
> > data in "data segment" and another in "bss segment" (with a footnote
> > explaining historical meaning of "block started by symbol")
> 
> Do you have an ISO C standard to refer to?  I don't, but my guess is
> that the standard does not even *mention* discreet data sections.  It
> *does* say that globals and statics are implicitly initialized to 0 --
> the rest is a mere implementation issue.
> 
> So yes, the two statements *are* trivially equivalent, unless I'm wrong
> and the standard *does* talk about data sections.

no, I was not talking about ISO C standards but about the normal expected
C environment under any UNIX. I guess, we just mean different things by
"trivially equivalent" since neither of us said anything about what that
actually meant. What I meant by that was "not only imply the same logic
for the program but correspond to the same physical locations (if any) on
the resulting object file". In this sense, obviously, they are not
"trivially equivalent" since in one case  there is no physical location at
all -- that is the whole point of having bss at all.

> 
> > For example a programmer could expect the variable to be in .data for
> > binary patching the object
> 
> Binary patching?  If you are binary patching something you need to get
> the exact location, one way or another.  Whatever tool you use to
> extract the location of a symbol in an object file, that same tool
> should tell you which section it is in.  If the tool only looks in
> '.data', it is flawed.

Keith already pointed out why you are wrong there.

> 
>   [David Hinds]
> > > Did the savings really work out to be measured in kb's of space?  I
> > > would have expected compression to eliminate most of the savings.
> 
> Some boot targets are not compressed.  And the variables are scattered
> through the .data section rather than all in one place, so the 0s may
> not compress as well as you'd think.
> 
> Anyway, by some estimates 'vmlinux' has gone down by several kilobytes
> due to these patches.  Obviously the exact savings depend on .config .

"several" kilobytes? _My_ patches alone (accepted by Linus ages
ago) reduced it by >280K.

Regards,
Tigran

-
To unsubscribe from this list: send 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

[Mohammad A. Haque]

Whoops, my bad. Yes, 4k blocks.

Block size:   4096


Ion Badulescu wrote:
> 
> No, you misunderstood me. df is always going to say 1k-blocks, but that
> doesn't mean that the filesystem's allocation unit is actually 1k.
> 
> Try doing a tune2fs -l on the device holding the filesystem and grep for
> "Block size". Although... looking at the numbers above, it's almost
> certainly 4k.
> 
> That's what I thought... thanks.
> 

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Ion Badulescu]

On Wed, 29 Nov 2000, Mohammad A. Haque wrote:

> [mhaque@viper mhaque]$ df
> Filesystem   1k-blocks  Used Available Use% Mounted on
> /dev/hda3 12737128   9988400   2101712  83% /
> /dev/hda246668 15106 29153  35% /boot
> /dev/hdd1 44327416  26319188  15756484  63% /home2
> none   8388608 11944   8376664   1% /dev/shm

No, you misunderstood me. df is always going to say 1k-blocks, but that
doesn't mean that the filesystem's allocation unit is actually 1k.

Try doing a tune2fs -l on the device holding the filesystem and grep for
"Block size". Although... looking at the numbers above, it's almost
certainly 4k.

> Yes, exactly 4096 nulls.

That's what I thought... thanks.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
To unsubscribe from this list: send 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 in exec_usermodehelper

[Andrew Morton]

Petr Vandrovec wrote:
> 
> On 29 Nov 00 at 1:53, Andrew Morton wrote:
> 
> > hmm..  Quite a few things fixed here.
> >
> > Could you please test this patch?  It's against 2.4.0-test12-pre2,
> > should be OK against test11.
> 
> I upgraded to 12-pre2 already ;-) It looks like that it works.

Yup.  It works.

> > - keventd is now capable of reaping dead children.  I will be all ears
> >   if someone can tell me how to get a kernel thread to accept signals
> >   without having to install a handler with
> >
> > sa.sa_handler = (__sighandler_t)100;
> 
> Is there any reason why not set sa.sa_handler to SIG_IGN?

Nope.  SIG_IGN works well for SIGCHLD, which is special-cased
for the reasons which you identify.  Thanks.

> According
> to arch/i386/kernel/signal.c:do_signal(), signal manpage and my memory,
> kernel does automatic child reaping in such configuration. So you
> could even remove waitpid() loop from keventd. I did not tried it yet,
> but it looks like obvious solution...

Unfortunately this doesn't work for kernel threads.

do_signal()
{
...
/*
 * We want the common case to go fast, which
 * is why we may in certain cases get here from
 * kernel mode. Just return without doing anything
 * if so.
 */
if ((regs->xcs & 3) != 3)
return 1;
...


I suspect all the fancy signal frame assembly would blow up if it
tried to build a frame on a kernel stack.  Not sure...

do_signal() could be altered to do the reaping even for kernel
threads, but that means touching every arch and it's not The Right Way.

Similarly, the kernel thread could be reparented to init via
REMOVE_LINKS/SET_LINKS but again, I didn't want to commit a
layering violation just because proper signal and task management
for kernel threads is tricky.

> BTW, are you sure that kernel does not try to deliver SIGSEGV to
> keventd() when signal arrives. It looks like that it should, but it
> probably fails somewhere during way due to non-existent userspace for
> this process.

Well, the fault handler exception table walker will see we're running
a kernel thread and will force an oops.  Plus SIGSEGV is blocked...

> > +   sa.sa.sa_handler = (__sighandler_t)100; /* Surely there's a better way? */
> > +   sa.sa.sa_flags = 0;
> 
> SA_RESTART?

That's handled during signal delivery.  Kernel threads don't get that
far.

> SA_NOCLDSTOP ?

Kernel threads can block SIGSTOP :)


BTW, quite a lot of the modprobe-specific stuff can probably now
be thrown away - it can use this version of call_usermodehelper().
But that's not a bug.   Next time..
-
To unsubscribe from this list: send 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

[Mohammad A. Haque]

[mhaque@viper mhaque]$ df
Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/hda3 12737128   9988400   2101712  83% /
/dev/hda246668 15106 29153  35% /boot
/dev/hdd1 44327416  26319188  15756484  63% /home2
none   8388608 11944   8376664   1% /dev/shm

Yes, exactly 4096 nulls.

Ion Badulescu wrote:
> 1k- or 4k-block filesystem? Also, can you count the nulls to see if
> they are exactly 4096 of them?

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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/

test12-pre3

[Linus Torvalds]

The bulk of this is architecture updates (most lately mips64). The most
interesting (but fairly small) part is the VM cleanups. Any day now
kiobuf's can just use PageDirty on everything, and we won't have any nasty
races any more.

Linus



 - pre3:
- me: more PageDirty / swapcache handling
- Neil Brown: raid and md init fixes
- David Brownell: pci hotplug sanitization.
- Kanoj Sarcar: mips64 update
- Kai Germaschewski: ISDN sync
- Andreas Bombe: ieee1394 cleanups and fixes
- Johannes Erdfelt: USB update
- David Miller: Sparc and net update
- Trond Myklebust: RPC layer SMP fixes
- Thomas Sailer: mixed sound driver fixes
- Tigran Aivazian: use atomic_dec_and_lock() for free_uid()

 - pre2:
- Peter Anvin: more P4 configuration parsing
- Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
  do the right thing.
- Keith Owens: make mdule loading use the right struct module size
- Boszormenyi Zoltan: get MTRR's right for the >32-bit case
- Alan Cox: various random documentation etc
- Dario Ballabio: EATA and u14-34f update
- Ivan Kokshaysky: unbreak alpha ruffian
- Richard Henderson: PCI bridge initialization on alpha
- Zach Brown: correct locking in Maestro driver
- Geert Uytterhoeven: more m68k updates
- Andrey Savochkin: eepro100 update
- Dag Brattli: irda update
- Johannes Erdfelt: USB update

 - pre1: (for ISDN synchronization _ONLY_! Not complete!)
- Byron Stanoszek: correct decimal precision for CPU MHz in
  /proc/cpuinfo
- Ollie Lho: SiS pirq routing.
- Andries Brouwer: isofs cleanups
- Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
- me: be stricter about what we accept as a PCI bridge setup.
- me: always set PCI interrupts to be level-triggered when we enable them.
- me: updated PageDirty and swap cache handling
- Peter Anvin: update A20 code to work without keyboard controller
- Kai Germaschewski: ISDN updates
- Russell King: ARM updates
- Geert Uytterhoeven: m68k updates

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Ion Badulescu]

On Tue, 28 Nov 2000 23:37:49 -0500, Mohammad A. Haque <[EMAIL PROTECTED]> wrote:
> Ok, I just found a file with about the first 4k of it filled with nulls
> (^@^@). No telling if this was a result of what originally started this
> thread or not. I hadn't accessed that file since Nov 9th.

1k- or 4k-block filesystem? Also, can you count the nulls to see if
they are exactly 4096 of them?

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send 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

[Mohammad A. Haque]

Ok, I just found a file with about the first 4k of it filled with nulls
(^@^@). No telling if this was a result of what originally started this
thread or not. I hadn't accessed that file since Nov 9th.


-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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: corruption

[Linus Torvalds]

On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote:
>
> I did again a large test comparing two identical trees.
> Found again corruption, and, upon inspection, the disk
> files did not differ - this is in-core corruption only.

Ok. It definitely looks like the 1kB thing has become broken somehow. 

The fact that it is in-core only doesn't mean that much - it could still
easily be just problems at read-time, and if you have an IDE disk I would
strongly suggest you try out the patch that Jens Axboe posted,
re-initializing the "head" pointer when doing a re-merge.

That said, the VM/ext2 angle should definitely be looked at too. Nothing
has really changed there in some time - can you give a rough estimate on
when you suspect you started seeing it? Ie is it new to one of the test11
pre-kernels, or does it happen so occasionally that you can't tell whether
it happened much earlier too?

Linus

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

Re: 2.4.0-test: rmmod -a without effect

[Keith Owens]

On Wed, 29 Nov 2000 01:37:22 +0100,
Kurt Garloff <[EMAIL PROTECTED]> wrote:
>this is a 2.4.0-test11 system;
>rmmod -a (modutils-2.3.21) fails to unload unused autocleanable modules:

Designed behaviour.  sys_delete_module only removes autoclean modules
that have been used at least once, either they have been used or some
other module has a reference to them.  Otherwise you get nasty races
like this

  cpu 0   cpu 1
  request_module(foo)
modprobe -k foo
  insmod -k foo
foo is loaded, unused
  kernel sees foo has loaded
  rmmod -a
  kernel uses foo

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

corruption

[Andries . Brouwer]

I did again a large test comparing two identical trees.
Found again corruption, and, upon inspection, the disk
files did not differ - this is in-core corruption only.

A few days ago:

diff -r /c2/linux/linux-2.4.0-test10/linux/include/asm-sparc/ecc.h /g1/linux/li\
nux-2.4.0-test10/linux/include/asm-sparc/ecc.h
80,83c80,95
< #define ECC_FADDR0_CACHE 0x0800
< #define ECC_FADDR0_SIZE  0x0700
< #define ECC_FADDR0_TYPE  0x00f0
< #define ECC_FADDR0_PADDR 0x000f
---
> #define ECC_FADDR0_Ccount << RATIO_SCALE_LOG;
>   if (db->bytes_out != 0)
> {
>   new_ratio /= db->bytes_out;
> }
>
>   if (new_ratio < db->ratio || new_ratio < 1 * RATIO_SCALE)
> {
>   bsd_clear (db);
>   return 1;
> }
>   db->ratio = new_ratio;
> }
>   }
> return 0;
> }

Here the corruption starts precisely 3072 bytes into the file
(which lives on a filesystem with 1024-byte blocks).

But the tail is a fragment of drivers/isdn/isdn_bsdcomp.c
starting at an offset of 7168 bytes.

The former lives on blocks 6373895 6373896 6373897 6373898 6373899,
the other on blocks 2475568...2475579,2475616...2475628.

Today:

diff -r /g1/linux/linux-2.4.0-test11vanilla/linux/net/sched/sch_cbq.c /c2/linux\
/linux-2.4.0-test11vanilla/linux/net/sched/sch_cbq.c
2000c2000,2115
<   cbq_destr\201XM^@\202XM^@^@^@^@^@^@^@^@^@^@^@...

(lots of nulls)

with corruption starting at an offset of 47104=46*1024 bytes.
Don't know where the corruption part is from.

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/

PF_PACKET and Token Ring

[Gerard Paul Java]

Hi,

I'm trying to capture IP packets over a Token Ring network through a
(PF_PACKET, SOCK_RAW) socket, but for some
reason the sll_protocol field in the sockaddr_ll structure doesn't
contain ETH_P_IP for IP packets but rather contains 0x100 (of course, in
network byte order).

Is this a bug, or is it expected behavior?


Gerard Paul R. Java
System Administrator, Mosaic Communications Cebu
primary: [EMAIL PROTECTED]
secondary: [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" from drivers/ide (test11)

[Peter Samuelson]

[Keith Owens]
> Binary patches against bss on disk cannot work, there is nothing to
> patch.

OK, me dumkopf.

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

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

[Keith Owens]

On Tue, 28 Nov 2000 17:53:48 -0600, 
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>Binary patching?  If you are binary patching something you need to get
>the exact location, one way or another.  Whatever tool you use to
>extract the location of a symbol in an object file, that same tool
>should tell you which section it is in.  If the tool only looks in
>'.data', it is flawed.

The whole point of bss is that it does not have any space allocated in
the object on disk.  bss is just a section entry saying "this size, at
this location", the area is allocated and zeroed at load time.  Binary
patches against bss on disk cannot work, there is nothing to patch.

-
To unsubscribe from this list: send 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"

[Peter Samuelson]

[Albert D. Cahalan]
> Choosing an initializer that tends to catch unintended reliance on
> zeroed data would be good. Too bad it is too late to fix.

Why would that be good?  Why is it bad to accidentally rely on zeroed
data, if the data is in fact guaranteed to be zeroed?  It's not like
this is going to change out from under us in a year.  You said it
yourself: we can do whatever we want here.  And I don't see why we
would ever want to do anything other than zero it.

> Go back and read the rest of this thread. Examples have been provided
> (not by me) of such code leading to latter mistakes.

Oh please, how hard can it be to type

  static int foo; // = 0

as opposed to

  static int foo = 0;

If the two produced the same object code, the second would be better,
but they don't, so it isn't.  Patch gcc, if you care enough (and feel
you can convince the gcc steering committee to care enough).

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

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

[Peter Samuelson]

[Remi Turk]
> Do I understand correctly that this means hardlinks to directories
> (except . and ..) are fundamentally impossible in Linux?

Why do you want to be able to do that?  Use symlinks or loopback mounts
and stay out of trouble.

> (I'm thinking about trying to write a garbage collected filesystem
> with hardlinks to directories.)

Sounds like a lot of extra complexity.  Is this academic or do you have
a practical use for it?

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

Re: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Kiril Vidimce]

On Wed, 29 Nov 2000, Alan Cox wrote:
> > I've never seen such thing as code without bugs. In my experience,
> > the NVIDIA drivers are by far the most complete and solid 3D drivers 
> > under Linux.
> 
> You are welcome to your opinion. I've got this great bridge to sell you too

BTW, in case this is not clear, I am not saying that there are no problems
with the drivers. In fact, I have some issues with them but have reasonable
workarounds for the moment. However, if there are bugs, that doesn't mean 
that the drivers are completely broken.

KV
--
  ___
  Studio Tools[EMAIL PROTECTED]
  Pixar Animation Studioshttp://www.pixar.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/

Mobile IBM disk drive power settings?

[Stefan Hoffmeister]

Is there any support for the mobile IBM disk drive Advanced Battery Life
Extender power settings in Linux?

  http://www.alphaworks.ibm.com/tech/powerbooster


Power Booster allows any computer running Windows 95/98 and an IBM ATAPI 4
mobile disk drive to directly control advanced power management features
of the drive. 
...
PowerBooster uses a VXD to write ATA commands to the disk drive-


TIA,
Stefan
-
To unsubscribe from this list: send 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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Kiril Vidimce]

On Wed, 29 Nov 2000, Alan Cox wrote:
> > I've never seen such thing as code without bugs. In my experience,
> > the NVIDIA drivers are by far the most complete and solid 3D drivers 
> > under Linux.
> 
> You are welcome to your opinion. I've got this great bridge to sell you too

I don't see the need for sarcasm. If you feel that you can demonstrate
that the above is untrue, by all means do so. I am sure there is more
than one person that would want to know what's currently the best 3D 
Linux configuration out there.

KV
--
  ___
  Studio Tools[EMAIL PROTECTED]
  Pixar Animation Studioshttp://www.pixar.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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Alan Cox]

> I've never seen such thing as code without bugs. In my experience,
> the NVIDIA drivers are by far the most complete and solid 3D drivers 
> under Linux.

You are welcome to your opinion. I've got this great bridge to sell you too


-
To unsubscribe from this list: send 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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Kiril Vidimce]

On Wed, 29 Nov 2000, Alan Cox wrote:
> > On Tue, 28 Nov 2000, Dan Hollis wrote:
> > > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > > filesystems broken.
> > 
> > Not true. It works for us with no problems on a number of SMP boxes 
> > running 2.2.{14,16}. I don't know about 2.4.x.
> 
> Dan is not the only one to report it totally trashing a machine and file systems
> SMP. So I suspect there is something there , but I don't know what (or care).
> I've seen other demos of bugs in the nv driver, long standing ones and
> reading the mangled code you can see bugs even in their mangled code
> without looking too hard.

I've never seen such thing as code without bugs. In my experience,
the NVIDIA drivers are by far the most complete and solid 3D drivers 
under Linux.

KV
--
  ___
  Studio Tools[EMAIL PROTECTED]
  Pixar Animation Studioshttp://www.pixar.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: test12-pre2

[Wakko Warner]

>  - pre2:
> - Richard Henderson: PCI bridge initialization on alpha

Doesn't boot on noritake alpha.

It gets to POSIX conformance testing by UNIFIX
and hard locks.  the halt switch doesn't even work.


-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send 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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Alan Cox]

> On Tue, 28 Nov 2000, Dan Hollis wrote:
> > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > filesystems broken.
> 
> Not true. It works for us with no problems on a number of SMP boxes 
> running 2.2.{14,16}. I don't know about 2.4.x.

Dan is not the only one to report it totally trashing a machine and file systems
SMP. So I suspect there is something there , but I don't know what (or care).
I've seen other demos of bugs in the nv driver, long standing ones and
reading the mangled code you can see bugs even in their mangled code
without looking too hard.

-
To unsubscribe from this list: send 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.2.18pre24

[Alan Cox]

2.2.18pre24
o   Expose put_unused_fd for modules(Andi Kleen)
o   Fix the ps/2 mouse probe I hope (me)
o   Fix crash in cosa driver(Jan Kasprzak)
o   Fix procfs negative seek offset error reporting (HJ Lu)
o   Fix ext2 file limit constraints (Andrea Arcangeli)
o   Fix lockf corner cases  (Andi Kleen, me)
o   Fix NCPfs date limits   (Igor Zhbanov)
o   Update DRM  (Chip Salzenberg)
o   Fix missing Alpha includes  (Matt Wilson)
o   Fix missing symbols on alpha(Matt Wilson)
 
2.2.18pre23
o   Fix alpha compile problem   (Herbert Xu)
o   Scan DMI bios data to find broken laptops   (me)
o   Fix megaraid module symbols (Michael Marxmeier)
o   Fix visor/OHCI problem  (Gerg Kroah-Hartman)
o   Fix sysctl_jiffies compile bug  (Tomasz K³oczko)
o   Init mic input low to avoid feedback(Pete Zaitcev)
o   Fix typo in acenic headers  (Val Henson)
o   David Woodhouse has moved   (David Woodhouse)
o   Compaq raid driver update   (Charles White)
o   Fix aha1542 scribbles on errors (Phil Stracchino)
o   Update Advansys driver to v3.3D (Bob Frey)
o   Fix maestro ioctl locking   (Zach Brown)
o   Formatting cleanup for setup.c  (Dave Jones)
o   Fix FAT32 bugs on Alpha (Bill Nottingham)

2.2.18pre22
o   Fix HZ assumption in USB hub driver (Oleg Drokin)
o   Fix ndisc range check on ipv6   (Dave Miller)
o   Clear other fields in qcam VIDIOCGWIN return(Damion de Soto)
o   Fix sparc64 includes for socket.h   (Solar Designer)
o   ELF platform was misset for Pentium IV  (Mikael Pettersson)
o   ADMTek 985 ident was wrong  (Lee Bradshaw)
o   Fix filemark status test on scsi tape   (Robin Miller)
o   Fix file/block when spacing to tape beginning   (Kai Maiksara)
o   Small ISDN documentation fixes  (Kai Germaschewski)
o   Resync icn driver with core isdn tree   (Kai Germaschewski)
o   Fix isdn loopback driver(Kai Germaschewski)
o   Fix small leaks in lockd(Trond Myklebust)
o   Add Pentium IV rep nop, ident etc   (Various folks,
 notably HPA and
 Linda Wang)
o   Update sparc default config (Dave Miller)
o   Hopefully properly fix the megaraid problem (Willy Tarreau, AMI
 and others)
o   Resync tcp bits with Dave   (Dave Miller)
o   Make cpqarray provide randomness(Nigel Metheringham)
o   Fix wavefront symbols bug   (Carlos E. Gorges)
o   Fix acenic jumbo handling when flushing ring(Val Henson)
o   Fix ace_set_mac_addr for littleendian hosts (Stephen Hack)
o   Fix assorted typos in the kernel(Andries Brouwer)
o   EEPro100 fixes  (Dragan Stancevic)
o   Fix hisax _setup crash case (David Woodhouse)
o   Fix small cdrom driver bugs (Jens Axboe)
o   Fix remaining vmalloc corner cases  (Ben LaHaise)
o   Update USB maintainers  (Greg Kroah-Hartman)
o   Fix matroxfb doc bug(Pavel Rabel)
o   Fix setscheduler lock inversion (Andrew Morton)
o   Fix scsi unload/sg ioctl oops   (Paul Clements)

2.2.18pre21
o   Environment controller update for sparc (Eric Brower)
o   No italian translation for config.help  (Andrea Ferraris)
o   Fix type error in buz driver(Pete Zaitcev)
o   Resnchronize Apple PowerMac codebase(Paul Mackerras & co)
o   Merge powermac tree fixes into usb
o   Powermac input device handling changes
o   Fix console switch fonts
o   S/390 merge (IBM S/390 folks)
(Merge grunt work done by Kurt Roeckx)
o   Make knfsd TCP an option(me)
o   Drop cisco info packets (0x2000)(Ivan Passos)
o   Add belkin USB serial cable (William Greathouse)

2.2.18pre20
o   Fix ide-probe SMP build error   (Ian Morgan)
o   Fix appletalk physical layer ioctl handling (Andi Kleen)
o  

Re: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Kiril Vidimce]

On Tue, 28 Nov 2000, Dan Hollis wrote:
> Dont forget the nvidia driver is completely SMP broken. As in, trash your
> filesystems broken.

Not true. It works for us with no problems on a number of SMP boxes 
running 2.2.{14,16}. I don't know about 2.4.x.

KV
--
  ___
  Studio Tools[EMAIL PROTECTED]
  Pixar Animation Studioshttp://www.pixar.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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[J . A . Magallon]

On Wed, 29 Nov 2000 02:29:04 Dan Hollis wrote:
> On Wed, 29 Nov 2000, J . A . Magallon wrote:
> > On Wed, 29 Nov 2000 01:39:56 Dan Hollis wrote:
> > > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > > filesystems broken.
> > Not so broken. I use it under SMP 2.2.18-pre23 and works fine.
> 
> Try unreal tournament. Locks up hard during the intro animation. It's been
> listed for months in the nvidia FAQ as a known bug (#6.5.7) with no fix.
> 

Not exactly UT, but I have tried quake3, heretic2, and descent3. And in
the serious group, OpenGL Performer and recently Inventor. I have not
tried to leave q3a in demo mode for two days, but everything else works
fine. And Performer now (v2.4) is SMP'ing.

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

[Albert D. Cahalan]

Russell King writes:
> Albert D. Cahalan writes:

>> It is too late to fix things now. It would have been good to
>> have the compiler put explicitly zeroed data in a segment that
>> isn't shared with non-zero or uninitialized data, so that the
>> uninitialized data could be set to 0xfff00fff to catch bugs.
>> It would take much effort over many years to make that work.
>
> Oh dear, here's that misconception again.
>
> static int a;
>
> isn't a bug.

Alone, it is not.

> It is not "uninitialised data".  It is defined to be
> zero.  Setting the BSS of any C program to contain non-zero data will
> break it.  Fact.  The only bug you'll find is the fact that you're
> breaking the C standard.

Oh, bullshit. We break the C standard left and right already.
This is the kernel, and the kernel can initialize BSS any damn
way it feels like initializing it. The kernel isn't ever going
to be standard C.

Choosing an initializer that tends to catch unintended reliance
on zeroed data would be good. Too bad it is too late to fix.

> All variables declared at top-level are initialised.  No questions
> asked.  And its not a bug to rely on such a fact.

Go back and read the rest of this thread. Examples have been
provided (not by me) of such code leading to latter mistakes.
-
To unsubscribe from this list: send 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 ext2 fs corruption

[Andre Hedrick]

On Wed, 29 Nov 2000, Jens Axboe wrote:

> On Wed, Nov 29 2000, Andrea Arcangeli wrote:
> > Side note: that could generate mem/io corruption only on headactive devices
> > (like IDE).
> 
> Yep, that's why I told Linus it was a long shot and couldn't possibly
> account for all the corruption cases reported. And one would expect
> fs corruption to go with that as well. So it's of course a long shot,
> but still worth trying for Petr.

Okay, I have spent part of the afternoon kicking my FW around and have not
followed all of the thread.  However we are talking FSC and ATA so what
are the details?  And where are we poking into the driver.

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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Dan Hollis]

On Wed, 29 Nov 2000, J . A . Magallon wrote:
> On Wed, 29 Nov 2000 01:39:56 Dan Hollis wrote:
> > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > filesystems broken.
> Not so broken. I use it under SMP 2.2.18-pre23 and works fine.

Try unreal tournament. Locks up hard during the intro animation. It's been
listed for months in the nvidia FAQ as a known bug (#6.5.7) with no fix.

http://x54.deja.com/getdoc.xp?AN=687585074=975461056.438435863=2
http://x54.deja.com/getdoc.xp?AN=690445861=975461056.438435863=3

-Dan

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

Re: 2.4.0-test11 ext2 fs corruption

[Jens Axboe]

On Wed, Nov 29 2000, Andrea Arcangeli wrote:
> Side note: that could generate mem/io corruption only on headactive devices
> (like IDE).

Yep, that's why I told Linus it was a long shot and couldn't possibly
account for all the corruption cases reported. And one would expect
fs corruption to go with that as well. So it's of course a long shot,
but still worth trying for Petr.

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

Re: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[J . A . Magallon]

On Wed, 29 Nov 2000 01:39:56 Dan Hollis wrote:
> 
> Dont forget the nvidia driver is completely SMP broken. As in, trash your
> filesystems broken.
> 

Not so broken. I use it under SMP 2.2.18-pre23 and works fine. But under 2.4
hangs. So I think it is something that changed between 2.2 and 2.4 (locking
granularity???). And just hangs your box, does not corrupt anything.

It is a pitty that any piece of copylefted code prevents nVivia of giving all
of the drivers in source form.

-- 
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: 2.4.0-test11 ext2 fs corruption

[Andrea Arcangeli]

Side note: that could generate mem/io corruption only on headactive devices
(like IDE).

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: modutils-2.3.21: modprobe looping

[Kurt Garloff]

On Tue, Nov 28, 2000 at 10:24:48PM +0100, Kurt Garloff wrote:
> This is a pity, because I think the current behaviour is not acceptable,
> as it can kill the machine by just being invoked by kmod.
> I will try to make sense out of the code and make sure that modprobe
> will not go crazy, by either detecting loops (if I can do that in a way
> wihtout breaking things) or by limiting the recursion depth. I'll send
> you a patch.

Find it attached. As the dependency generation looked indeed rather
cumbersome to me, I didn't really touch it. I just did implement the
recursion limit to prevent the modprobe process grabbing all the memory of
the system ...
root@cantaloupe:~ > modprobe -k pppoe
modprobe: Too deep recursion in module dependencies!
modprobe: Circular dependency? pppox pppoe
Aborted

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security


diff -uNr modutils-2.3.21/insmod/modprobe.c modutils-2.3.21.SuSE/insmod/modprobe.c
--- modutils-2.3.21/insmod/modprobe.c   Tue Nov 21 10:10:54 2000
+++ modutils-2.3.21.SuSE/insmod/modprobe.c  Wed Nov 29 00:39:54 2000
@@ -363,6 +363,9 @@
return desc;
 }
 
+/* KG, 2000-11-29: Limit recursion in build_stack() */
+#define BSTACKRECMAX 128
+static int bstackrecurs = 0;
 /*
  * Create a linked list of the stack of modules needed in the kernel
  * in order to satisfy a request for "name"
@@ -395,6 +398,15 @@
if (rev && strcmp(rev->kname, desc->kname) == 0)
return 0;
 
+   if (++bstackrecurs > BSTACKRECMAX) {
+   fprintf (stderr, "modprobe: Too deep recursion in module 
+dependencies!\n");
+   fprintf (stderr, "modprobe: Circular dependency?");
+   for (lp = *stack; lp; lp = lp->next)
+   fprintf (stderr, " %s", lp->item.d->kname);
+   fprintf (stderr, "\n");
+   abort ();
+   }
+
/*
 * Get the modules that this one should pull in
 * according to modules.conf ("above")
@@ -414,7 +426,7 @@
rev ? rev : desc,
MODE_ABOVE, 1);
if (r < 0)
-   return r;
+   { bstackrecurs--; return r; }
}
}
}
@@ -424,7 +436,7 @@
if (strcmp(desc->kname, lp->item.d->kname) == 0) {
/* Avoid infinite loops ("above") */
if (rev && rev == lp->item.d)
-   return 0;
+   { bstackrecurs--; return 0; }
/* else */
/* Remove the entry, it is in the wrong place */
if (prev)
@@ -452,7 +464,7 @@
dir,
rev,
MODE_BELOW, 1)) < 0)
-   return r;
+   { bstackrecurs--; return r; }
}
}
}
@@ -465,10 +477,10 @@
for (nod = desc->nod->dep; nod; nod = nod->next) {
if ((r = build_stack(stack, nod->key, nod->str, dir, rev,
MODE_NORMAL, 0)) < 0)
-   return r;
+   { bstackrecurs--; return r; }
}
 
-   return 0;
+   bstackrecurs--; return 0;
 }
 
 /* For debugging */

 PGP signature

Re: 2.4.0-test11 ext2 fs corruption

[Jens Axboe]

On Tue, Nov 28 2000, Petr Vandrovec wrote:
> On 28 Nov 00 at 12:04, David S. Miller wrote:
> > 
> >Yes, it is identical copy. But I do not think that hdd can write same
> >data into two places with one command...
> > 
> > Petr, did the af_inet.c assertions get triggered on this
> > same machine?
> 
> No, ext2fs is at home, and af_inet is at work... At work I'm using
> vmware, at home I do not use it... But kernel sources are same
> (g450 patch for matroxfb, ncpfs supporting device nodes, threaded ipx;
> but neither ncpfs nor ipx is compiled at home).
>Petr Vandrovec
>[EMAIL PROTECTED]

Petr,

Could you try and reproduce with attached patch? If this would trigger
I would assume fs corruption as well (which doesn't seem to be the
case for you), but it's worth a shot.

--- drivers/block/ll_rw_blk.c~  Wed Nov 29 01:30:22 2000
+++ drivers/block/ll_rw_blk.c   Wed Nov 29 01:33:00 2000
@@ -684,7 +684,7 @@
int max_segments = MAX_SEGMENTS;
struct request * req = NULL, *freereq = NULL;
int rw_ahead, max_sectors, el_ret;
-   struct list_head *head = >queue_head;
+   struct list_head *head;
int latency;
elevator_t *elevator = >elevator;
 
@@ -734,6 +734,7 @@
 */
 again:
spin_lock_irq(_request_lock);
+   head = >queue_head;
 
/*
 * skip first entry, for devices with active queue head

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

Re: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Dan Hollis]

On Wed, 29 Nov 2000, Alan Cox wrote:
> > Thanks to some nice people in #NVIDIA I found what seems to be a
> > solution; compile with processor type as "K6". No segfaults, lost
> > terminfo or disabled consoles.
> > So are there issues with the K7 processor code? Bleh, never mind, I have
> > no idea what I am talking about.
> The K7 optimisations are not used for I/O space accessess. Or shouldnt be,
> but the nvidia code is unreadable so they may have done so

Dont forget the nvidia driver is completely SMP broken. As in, trash your
filesystems broken.

-Dan

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

2.4.0-test: rmmod -a without effect

[Kurt Garloff]

Hi,

this is a 2.4.0-test11 system;
rmmod -a (modutils-2.3.21) fails to unload unused autocleanable modules:
modprobe -r behaves the same, BTW

root@cantaloupe:~ > lsmod
Module  Size  Used by
ppp_deflate44736   0  (autoclean) (unused)
ppp_generic25728   0  (autoclean) [ppp_deflate]
root@cantaloupe:~ > rmmod -a
root@cantaloupe:~ > lsmod
Module  Size  Used by
ppp_deflate44736   0  (autoclean) (unused)
ppp_generic25728   0  (autoclean) [ppp_deflate]

As the binary does just a syscall delete_module(0), I guess it's the
kernel's fault. Same behaviour with 2.4.0-test9 and -test11-ac2.

Is this known and to be expected?

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security
-
To unsubscribe from this list: send 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.2.18pre19 oops in try_to_free_pages

[Andrea Arcangeli]

On Tue, Nov 28, 2000 at 01:44:18PM +0200, Ville Herva wrote:
> try Andrea's vm-global-7 now. It seems to include the bits Rik posted, or

It doesn't include the bits Rik posted because they were unnecessary.

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

[John Kennedy]

On Wed, Nov 29, 2000 at 01:04:16AM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 28, 2000 at 03:36:15PM -0800, John Kennedy wrote:
> >   No, it is all ext3fs stuff that is touching the same areas your
> 
> Ok this now makes sense. I ported VM-global-7 on top of ext3 right now
> but it's untested:

  Not for long.  (:

>  
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre18/VM-global-2.2.18pre18-7-against-ext3-0.0.3b-1.bz2

  Is ext3-0.0.3b the most current/stable?  On the FTP site (well,
ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs at least) it looks like
ext3-0.0.2f is current (which is what I've been using), but under the
test directory I see ext3-0.0.3b as well as ext3-0.0.5b.  I haven't
heard anything new about ext3fs in a long, long time.
-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Jan Rekorajski]

On Tue, 28 Nov 2000, Alan Cox wrote:

> > Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel j=
> > ob to
> > prevent admin from shooting him/her self in the foot.
> > 
> > root should be able to do fork() regardless of any limits,
> > and IMHO the following patch is the right thing.
> 
> This patch is bogus. root can always raise their limit. But having root
> tasks by default not take out the box is good

OK, I just fix applications that assume root = no limits ;)

Jan
-- 
Jan Rkorajski|  ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC |   -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send 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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Petter Sundlöf]

Alan Cox wrote:
> The K7 optimisations are not used for I/O space accessess. Or shouldnt be,
> but the nvidia code is unreadable so they may have done so

OK. I believe at least one of the NVIDIA developers read this list, so
hopefully they can look at what can be done on their side.
But seeing as how they've made no release for circa three months, and
considering the closed nature of their drivers, I doubt it'll be fixed
any time soon.

Oh well.
-
To unsubscribe from this list: send 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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Alan Cox]

> Thanks to some nice people in #NVIDIA I found what seems to be a
> solution; compile with processor type as "K6". No segfaults, lost
> terminfo or disabled consoles.
> 
> So are there issues with the K7 processor code? Bleh, never mind, I have
> no idea what I am talking about.

The K7 optimisations are not used for I/O space accessess. Or shouldnt be,
but the nvidia code is unreadable so they may have done so

-
To unsubscribe from this list: send 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]

On Tue, Nov 28, 2000 at 03:36:15PM -0800, John Kennedy wrote:
>   No, it is all ext3fs stuff that is touching the same areas your

Ok this now makes sense. I ported VM-global-7 on top of ext3 right now
but it's untested:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre18/VM-global-2.2.18pre18-7-against-ext3-0.0.3b-1.bz2

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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]

[Petter Sundlöf]

Thanks to some nice people in #NVIDIA I found what seems to be a
solution; compile with processor type as "K6". No segfaults, lost
terminfo or disabled consoles.

So are there issues with the K7 processor code? Bleh, never mind, I have
no idea what I am talking about.

Original bug report: http://findus.dhs.org/~odd/nvidia.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: Loading initrd from flash

[Erik Mouw]

On Tue, Nov 28, 2000 at 04:17:12PM -0700, Ian S. Nelson wrote:
> Is there a standardized way of doing this yet?  I'm not using any MTD
> stuff, yet, and it doesn't look like something that the code currently
> does.

The standard way of doing it on ARM linux systems is that the boot
loader copies the contents of the (compressed) ramdisk from flash to a
place in ram where the kernel expects it to be. Another possibility is
to point the kernel to the flash memory and have it decompressed from
there.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send 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)

[Peter Samuelson]

[Tigran Aivazian]
> First, they are not trivially equivalent. In fact, they are not
> equivalent at all.  Any good C book should tell you that one places
> data in "data segment" and another in "bss segment" (with a footnote
> explaining historical meaning of "block started by symbol")

Do you have an ISO C standard to refer to?  I don't, but my guess is
that the standard does not even *mention* discreet data sections.  It
*does* say that globals and statics are implicitly initialized to 0 --
the rest is a mere implementation issue.

So yes, the two statements *are* trivially equivalent, unless I'm wrong
and the standard *does* talk about data sections.

> For example a programmer could expect the variable to be in .data for
> binary patching the object

Binary patching?  If you are binary patching something you need to get
the exact location, one way or another.  Whatever tool you use to
extract the location of a symbol in an object file, that same tool
should tell you which section it is in.  If the tool only looks in
'.data', it is flawed.

  [David Hinds]
> > Did the savings really work out to be measured in kb's of space?  I
> > would have expected compression to eliminate most of the savings.

Some boot targets are not compressed.  And the variables are scattered
through the .data section rather than all in one place, so the 0s may
not compress as well as you'd think.

Anyway, by some estimates 'vmlinux' has gone down by several kilobytes
due to these patches.  Obviously the exact savings depend on .config .

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

Re: [PATCH] blindingly stupid 2.2 VM bug

[John Kennedy]

On Wed, Nov 29, 2000 at 12:20:09AM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 28, 2000 at 03:02:35PM -0800, John Kennedy wrote:
> > On Sat, Nov 25, 2000 at 02:57:01PM +0100, Andrea Arcangeli wrote:
> > > ... VM-global-*-7 has no known bugs AFIK.
> > 
> >   Is there anything more recent than VM-global-2.2.18pre18-7?  It isn't
> > patching very cleanly against my pre-patch-2.2.18-23 tree. 
> 
> It patches cleanly for me. (ignore the offset warnings from patch, just make
> sure there are no rejects)

  No, it is all ext3fs stuff that is touching the same areas your
patch is.  Sorry.  I was assuming that Rik van Riel's comments implied
that they should get patch a lot more cleanly and that I might have
missed a version, but there is no way these two could patch without
rejects along as-is.
-
To unsubscribe from this list: send 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: access() says EROFS even for device files if /dev is mounted RO

[Alexander Viro]

On Tue, 28 Nov 2000, Peter Cordes wrote:

>  I'm of the opinion that Linux should work in the way that is most useful,
> as long as that doesn't stop us from running stuff written for other unices.
> Unix is mostly good, but parts of it suck.  There's no reason to keep the
> parts that suck, except when needed for compatibility.  Changing the
> behaviour of access here would not introduce security holes in anything, so
> I think it should be changed to the more sensible way.
> 
> (That last paragraph is purely my opinion.  I'm pretty sure not everyone
> shares it!)

The funny thing being, access() _was_ consistent with open(). Relevant code
(I doubt that AT will care):

/*
 * open system call
 */
open()
{
register struct inode *ip;
register struct a {
char*fname;
int rwmode;
} *uap;

uap = (struct a *)u.u_ap;
ip = namei(uchar, 0);
if(ip == NULL)
return;
open1(ip, ++uap->rwmode, 0);
}

open1(ip, mode, trf)
register struct inode *ip;
register mode;
{
register struct file *fp;
int i;

if(trf != 2) {
if(mode)
access(ip, IREAD);
if(mode) {
access(ip, IWRITE);
if((ip->i_mode) == IFDIR)
u.u_error = EISDIR;
}
}
if(u.u_error)
goto out;

out:
iput(ip);
}

access(ip, mode)
register struct inode *ip;
{
register m;

m = mode;
if(m == IWRITE) {
if(getfs(ip->i_dev)->s_ronly != 0) {
u.u_error = EROFS;
return(1);
}

}

See what happens? open() calls open1(ip, mode, 0), we check that rtf is
not 2 and call access(ip, mode). Which sets u.u_error to EROFS and we
return from open1() (and open()). Failing. So behaviour of access()
was pretty and consistent with open().

When opening devices for write became allowed even for r/o filesystems
access() also had to be changed. And changed it was, back in mid-80s.
It's way older than Linux. Changing one of them and leaving another
as-is means introducing a bug. If standard admits one but not another -
standard is buggy. Again, when 4.*BSD (and 2.*BSD) allowed opening devices
for write even for nodes on r/o filesystems they did change access().

If standard in question doesn't allow such use of open() - too fscking bad.
For standard. Because I'll take the ability to boot from r/o media and
install the system (kinda requires ability to run mkfs) over POSIX/SuS
compliance any day.

 Oh, lovely...
   [EROFS]
  The named file resides on a read-only file system and either
  O_WRONLY, O_RDWR, O_CREAT (if file does not exist) or O_TRUNC
  is set in the oflag argument.

Wonderful. Andries, care to try pushing _that_ kind of standard-compliance?
It _is_ consistent, all right. And utterly wrong.

-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Frank v Waveren  <[EMAIL PROTECTED]> wrote:
>On Tue, Nov 28, 2000 at 09:58:14PM +, Alan Cox wrote:
>> > Because you want to be able to `kill `?
>> > And if you are over-limits you can't?
>> Wrong. limit is a shell built in
>
>I assume you mean kill is a shell builtin. Depending on your shell. :-).

No. Think about it.

Mike.
-
To unsubscribe from this list: send 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]

On Tue, Nov 28, 2000 at 03:02:35PM -0800, John Kennedy wrote:
> On Sat, Nov 25, 2000 at 02:57:01PM +0100, Andrea Arcangeli wrote:
> > ... VM-global-*-7 has no known bugs AFIK.
> 
>   Is there anything more recent than VM-global-2.2.18pre18-7?  It isn't
> patching very cleanly against my pre-patch-2.2.18-23 tree. 

It patches cleanly for me. (ignore the offset warnings from patch, just make
sure there are no rejects)

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: /proc/fb

[Jorge Nerin]

Geert Uytterhoeven wrote:
> 
> Hi Jorge,
> 
> In linux-2.4.0-test12-pre2/Documentation/filesystems/proc.txt, you wrote:
> 
> | fb Frame Buffer devices   (2.4)
> 
> This entry existed in 2.2 as well.
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 

Thanks, I put it 2.4 because in the original doc it didn't say anything
about it, and I don't use a 2.2 kernel since a long time.

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

[John Kennedy]

On Sat, Nov 25, 2000 at 02:57:01PM +0100, Andrea Arcangeli wrote:
> ... VM-global-*-7 has no known bugs AFIK.

  Is there anything more recent than VM-global-2.2.18pre18-7?  It isn't
patching very cleanly against my pre-patch-2.2.18-23 tree. 

  (I don't see anything under your pre19 thru pre23 dirs, but I
   may not be looking at a fully populated server or something.)

  Reiserfs on top of 2.2.18-23 blatantly runs me out of memory, and ext3fs
may be doing it too, although the laptop fan makes it sounds like it is
busy-looping somewhere.
-
To unsubscribe from this list: send 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] ide config order

[Pavel Rabel]

2.4.0test12-pre2
Please reorder config to group DMA options together.

Pavel Rabel


--- drivers/ide/Config.in.old   Tue Nov 28 22:22:49 2000
+++ drivers/ide/Config.in   Tue Nov 28 22:24:19 2000
@@ -42,8 +42,8 @@
 bool '  Generic PCI IDE chipset support' CONFIG_BLK_DEV_IDEPCI
 if [ "$CONFIG_BLK_DEV_IDEPCI" = "y" ]; then
bool 'Sharing PCI IDE interrupts support' CONFIG_IDEPCI_SHARE_IRQ
-   bool 'Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA_PCI
bool 'Boot off-board chipsets first support' CONFIG_BLK_DEV_OFFBOARD
+   bool 'Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA_PCI
dep_bool '  Use PCI DMA by default when available' 
CONFIG_IDEDMA_PCI_AUTO $CONFIG_BLK_DEV_IDEDMA_PCI
define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_PCI
dep_bool '  ATA Work(s) In Progress (EXPERIMENTAL)' 
CONFIG_IDEDMA_PCI_WIP $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_EXPERIMENTAL

-
To unsubscribe from this list: send 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: access() says EROFS even for device files if /dev is mounted RO

[Peter Cordes]

On Mon, Nov 27, 2000 at 01:42:51PM +0100, Andries Brouwer wrote:
> On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
> 
> >  While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
> > that open(1) doesn't work when / is mounted read only.
> 
> Already long ago open(1) was renamed to openvt(1), so it may be that
> have a very old version. See a recent kbd or console-tools.

 In the Debian package, on my Woody system, open is a symlink to openvt.
I've got console-tools 0.2.3.  The source uses access here:

  /* Maybe we are suid root, and the -c option was given.
 Check that the real user can access this VT.
 We assume getty has made any in use VT non accessable */
  if (access(vtname, R_OK | W_OK) < 0)
  {
 fprintf(stderr, _("Cannot open %s read/write (%s)\n"), vtname,
 strerror(errno));
 return (5);
  }

  That code could be "fixed" to work with the current kernel behaviour by
checking that errno != EROFS.  I thought access was supposed to tell you
whether open will work, except for directories, where you do different
things to write to them.  (I've seen your messages up to Tue, 28 Nov 2000
22:37:21 +0100, but I'm replying to this one, so you don't have to repeat
your arguments for me :)


> > access("/dev/tty2", R_OK|W_OK)  = -1 EROFS (Read-only file system)
> 
> >  However, this is wrong.  You _can_ write to device files on read-only
> > filesystems.  (open shouldn't bother calling access(), but the kernel should
> > definitely give the right answer!)
> 
> You misunderstand the function of access(). The standard says
> 
> [EROFS] write access shall fail if write access is requested
> for a file on a read-only file system
> 
> It does not look at whether you ask write access to a directory
> or a special device file (and whether the filesystem was mounted nodev or not).

 In the case of a directory, "writing" to it is creating or deleting files
in it: the list of filename:inode changes.  If the dir is on a read-only FS,
you can't write, so access() should fail.  Writing to a device file doesn't
change anything stored with the file, so it works even if the file is on a
read-only FS.

> So, probably you found a flaw in openvt: the use of access is almost always
> a bug - it doesnt tell you what you want to know. You may send me a patch
> if you want to.

 What do you think access is for then?  Is it defined by the standard in
such a way that it isn't useful for anything?

 I'm of the opinion that Linux should work in the way that is most useful,
as long as that doesn't stop us from running stuff written for other unices.
Unix is mostly good, but parts of it suck.  There's no reason to keep the
parts that suck, except when needed for compatibility.  Changing the
behaviour of access here would not introduce security holes in anything, so
I think it should be changed to the more sensible way.

(That last paragraph is purely my opinion.  I'm pretty sure not everyone
shares it!)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X([EMAIL PROTECTED] , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE
-
To unsubscribe from this list: send 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

[Mohammad A. Haque]

Ok, I'm not sure what else to try. I've even tried throwing around 1.6
GB of data, and copying and deleting at the same time. Nothing. Again,
this is _without_ the patches sent by Alexander.

I think I'm just gonna go on to test12-pre2.

Neil Brown wrote:
> 
> Turns out my data is a false alarm.  It was a bug in my raid5 code -
> and not a recent bug either - that was causing my filesystem
> corruption.
> 
> So if your earlier patches work for everybody else then they look like
> a good way to go.  I have fixed my fatal flaw and I cannot reproduce
> the problems any more.  Patch has gone to Alan.

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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] no RLIMIT_NPROC for root, please

[Frank v Waveren]

On Tue, Nov 28, 2000 at 09:58:14PM +, Alan Cox wrote:
> > Because you want to be able to `kill `?
> > And if you are over-limits you can't?
> Wrong. limit is a shell built in

I assume you mean kill is a shell builtin. Depending on your shell. :-).
It's still a real pain when you want to get the pid of the offending
proces(ses). You could of course do something like
for a in /proc/*; do echo -en "$a "; cat $a/cmdline; echo; done (it'll
barf a lot, but give a reasonable picture)...

Anyways, this is all not relevant, imho the whole point is moot.
"I don't like root having rlimits."
"So don't setrlimit root."

No reason to ditch functionality.

-- 

Frank v Waveren
fvw@[var.cx|stack.nl|chello.nl|dse.nl]
ICQ# 10074100
-
To unsubscribe from this list: send 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-t11: IDE probe failed

[Ragnar Hojland Espinosa]

I still get those at random (and no, I'm not hot-rebooting from ms windows)
Normally the cookie is 0xfff8 or similar.
-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."   hkp://keys.pgp.com

Handle via comment channels only.
-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Alan Cox]

> > AFAICS, _all_ resource limits are equally applied to root processes. =
>  Why
> > should NPROC be different?
> 
> Because you want to be able to `kill `?
> And if you are over-limits you can't?

Wrong. limit is a shell built in

-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Alan Cox]

> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel j=
> ob to
> prevent admin from shooting him/her self in the foot.
> 
> root should be able to do fork() regardless of any limits,
> and IMHO the following patch is the right thing.

This patch is bogus. root can always raise their limit. But having root
tasks by default not take out the box is good

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

Re: access() says EROFS even for device files if /dev is mounted RO

[Andries Brouwer]

On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:

> Ok, so if you read the standard carefully you get a bogus result. 

Why bogus? Things could have been otherwise, but the important
part is that all Unices do things the same way.

> Question: Was it meant this way, or did someone just make a mistake
> (which happened to slip through and get approved into the standard)? 
> 
> I happen to think the second. 
> 
> - Is it desirable to have a write-open of a device on a read-only 
> fail? I don't think so. You can't open the initial console etc etc.

Nevertheless the standard requires this.

> - Is it desirable to have access (W_OK) and "open-for-write" return
> different results? I don't think so. 

Nevertheless there have never been systems where access and open
behaved identically. An easy example is given by directories
that have write access when a w bit is set, but return EISDIR
upon open-for-write.

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: modutils-2.3.21: modprobe looping

[Kurt Garloff]

On Wed, Nov 29, 2000 at 07:33:53AM +1100, Keith Owens wrote:
> On Tue, 28 Nov 2000 20:22:59 +0100, 
> Kurt Garloff <[EMAIL PROTECTED]> wrote:
> >Find attached the modules.dep that caused this: There is a circular
> >dependency of pppoe on pppox on pppoe on 
> 
> The kernel code is broken.  Circular dependencies make no sense, the
> pppoe maintainer agrees and I thought that bug was fixed.

No question that circular dependencies are a bug in the kernel/modules. 
I just thought, that it would be nice if modprobe would not run crazy and
end up in an endless loop, possible risking the machine to run out of mem
with all the nice side effects this has on Linux. This is especially bad,
because modprobe is called invisibly by kmod.
Here's what happened on the test machine (2.4.0-test9 on Dual Power3):
Swapping like crazy; getting unresponsive; ...
Here's the last output top was able to produce:
 10:12pm  up  5:56,  3 users,  load average: 1.57, 0.41, 0.16
65 processes: 63 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 36.9% user, 19.0% system,  0.0% nice, 44.0% idle
Mem:   509320K av,  508272K used,1048K free,   28172K shrd,  76K buff
Swap:  131064K av,  107388K used,   23676K free7048K cached

  PID USER PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
23543 root  15   0  574M 472M   328 R   0 85.8 95.0   0:55 modprobe
2 root  11   0 00 0 DW  0 26.3  0.0   0:06 kswapd
23544 root  14   0   568  428   328 R   0  2.1  0.0   0:01 top
[...]
(10 mins later)
I'm afraid I can't wait until the machine recovers, if it ever will.
[2.2 with AA VM would have started to kill processes (which is bad) 
 till it would have finally killed modprobe (which is good);
 but I'm afraid that 2.4 will just not survive at all :-(   ]

> Circular dependencies are not supported, nor are they correrctly
> detected.  The existing code to walk the inter module relationships,
> including dependencies, alias, probe, probeall, before and after
> statements is a mess.  It just grew over the years with special cases
> being added and is not robust.

This is a pity, because I think the current behaviour is not acceptable,
as it can kill the machine by just being invoked by kmod.
I will try to make sense out of the code and make sure that modprobe
will not go crazy, by either detecting loops (if I can do that in a way
wihtout breaking things) or by limiting the recursion depth. I'll send
you a patch.

> In modutils 2.5 the entire code will be discarded and replaced with a
> standard graph walking algorithm with loop detection and back tracking
> instead of special case code.  That might change some modutils
> behaviour in rare cases and I do not want to change its behaviour just
> before kernel 2.4 is released.  I have a list of changes that might
> break backwards compatibility waiting for modutils 2.5, this is just
> one of them.

Looking forward to it.

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

Re: [PATCH] no RLIMIT_NPROC for root, please

[Jan Rekorajski]

On Tue, 28 Nov 2000, Andreas Schwab wrote:

> Jan Rekorajski <[EMAIL PROTECTED]> writes:
> 
> |> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
> |> prevent admin from shooting him/her self in the foot.
> |> 
> |> root should be able to do fork() regardless of any limits,
> |> and IMHO the following patch is the right thing.
> 
> AFAICS, _all_ resource limits are equally applied to root processes.  Why
> should NPROC be different?

Because you want to be able to `kill `?
And if you are over-limits you can't?

Jan
-- 
Jan Rkorajski|  ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC |   -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send 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: out of swap

[Jakob Østergaard]

On Tue, Nov 28, 2000 at 01:08:44PM -0800, Ben Ford wrote:
> Jakob Østergaard wrote:
> 
> 
> 
> > comments, Riel or Andrea ?).  I don't know of any good solution to this problem
> > other than just having enough swap space - after all, seriously, with today's
> > disks, who can't spare an extra few hundred megs (which would usually be more
> > than enough).
> 
> An embedded system for one . . . .

If you need to browse heavily illustrated web pages on an embedded system (one
small enough to not have a disk), then use a decent browser...

/me runs...  ;)

Usually ulimits can help and tons of swap is uncalled for - but this case where
Netscape makes X consume memory on Netscape's behalf is so rare (I guess), that
I don't think this is a problem worthy of the embedded-systems-VM-discussion.

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Andreas Schwab]

Jan Rekorajski <[EMAIL PROTECTED]> writes:

|> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
|> prevent admin from shooting him/her self in the foot.
|> 
|> root should be able to do fork() regardless of any limits,
|> and IMHO the following patch is the right thing.

AFAICS, _all_ resource limits are equally applied to root processes.  Why
should NPROC be different?

Andreas.

-- 
Andreas Schwab  "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Jan Rekorajski]

On Tue, 28 Nov 2000, Tigran Aivazian wrote:

> On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > --- linux/kernel/fork.c~Tue Sep  5 23:48:59 2000
> > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > @@ -560,7 +560,8 @@
> > *p = *current;
> >  
> > retval = -EAGAIN;
> > -   if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
> > +   if (p->user->uid &&
> > +  (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur))
> 
> Jan,
> 
> Hardcoding things signifying special treatment of uid=0 is almost always a
> bad idea. If you _really_ think that superuser (whatever entity that might
> be) should be exempt from RLIMIT_NPROC and can prove that (SuSv2 seems to
> be silent so you may be right), then you should use capable() to do proper
> capability test and not that horrible explicit uid test as in your patch
> above.

Ok, how about setting limits on login? When this looks like:

--- uid = 0 here
setrlimit(RLIMIT_NPROC, n)
fork()  <- this will fail if root has >n processes
setuid(user)

and it is hard to change this sequence, all PAM enabled apps depend on it :(

The other scenario may be when root has already n processes,
call them system stuff, and cannot login or even kill anything
because of limits.

Is this patch better? I put CAP_SYS_RESOURCE, but maybe it should be
CAP_SYS_ADMIN.

--- linux/kernel/fork.c~Fri Nov 17 15:09:26 2000
+++ linux/kernel/fork.c Tue Nov 28 22:02:17 2000
@@ -562,7 +562,8 @@
*p = *current;
 
retval = -EAGAIN;
-   if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
+   if ((atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) &&
+   !capable(CAP_SYS_RESOURCE))
goto bad_fork_free;
atomic_inc(>user->__count);
atomic_inc(>user->processes);

Jan
-- 
Jan Rkorajski|  ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC |   -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Andreas Dilger]

Jan R_korajski writes:
> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
> prevent admin from shooting him/her self in the foot.

> - if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)

By default, root has no real process limits anyways, so this test should
always succeed.  However, it would be nice to be _able_ to set process
limits on root for one reason or another.  Also, as we move towards more
secure systems, it is bad (IMHO) to special case root (uid=0) cases.
It just makes more to fix to get a system where root != god.

> root should be able to do fork() regardless of any limits,
> and IMHO the following patch is the right thing.

Then set the rlim_cur to unlimited, and blow your system up as you like.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send 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)

[Tigran Aivazian]

On Tue, 28 Nov 2000, David Hinds wrote:
> I would contend that it is a compiler bug in gcc if it treats the two
> statements differently, since they are trivially equivalent.  I guess
> that it has been decided that linux kernel coding style dictates no
> zero initializers, so that's that.  Personally, I prefer symmetry: if
> I have a list of static variables initialized to various things, I
> don't have to use a different form for ones that are zero initialized.

I would contend that you are wrong -- it is not a compiler bug.

First, they are not trivially equivalent. In fact, they are not equivalent
at all. Any good C book should tell you that one places data in "data
segment" and another in "bss segment" (with a footnote explaining
historical meaning of "block started by symbol")

Second, If compiler did the ".data -> .bss" move on the fly then it would
violate the principle of least surprize. For example a programmer could
expect the variable to be in .data for binary patching the object (this
reason is not applicable to the Linux kernel because section information
is lost when converting vmlinux to raw binary and then onto bzImage).

> 
> Did the savings really work out to be measured in kb's of space?  I
> would have expected compression to eliminate most of the savings.
> 

if one doesn't count compression then -- hundreds of Kbs (K=1024 and b =
byte, not bit!). Even Mbs if you count multiple architectures.

Use Keith Owens' famous perl script to do the counting.

Regards,
Tigran

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

Re: Patch: 2.4.0-test11ac4 version of pci and isapnp device ID'spatch

[Andre Hedrick]

On Sat, 25 Nov 2000, Adam J. Richter wrote:

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

Hey Alan, are we now sorting sub-id's?

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" from drivers/ide (test11)

[David Hinds]

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

I think the argument is that "static int foo;" implies you don't
actually care how "foo" is initialized, but adding the "= 0" is
revealing that the code actually relies on the default value.  The
code is obviously equivalent.  It is a readability issue, not an issue
of what the code does.

I would contend that it is a compiler bug in gcc if it treats the two
statements differently, since they are trivially equivalent.  I guess
that it has been decided that linux kernel coding style dictates no
zero initializers, so that's that.  Personally, I prefer symmetry: if
I have a list of static variables initialized to various things, I
don't have to use a different form for ones that are zero initialized.

Did the savings really work out to be measured in kb's of space?  I
would have expected compression to eliminate most of the savings.

-- Dave
-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Tigran Aivazian]

> On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > --- linux/kernel/fork.c~Tue Sep  5 23:48:59 2000
> > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > @@ -560,7 +560,8 @@
> > *p = *current;
> >  
> > retval = -EAGAIN;
> > -   if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
> > +   if (p->user->uid &&
> > +  (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur))
> 

On a totally unrelated to the resourcesnote, for your benefit, Jan:

the ->user->uid is maintained for a reason completely different from your
usage above (see kernel/user.c to learn why -- it is to easily find out
given user_struct which real uid it belongs to in uid_hash_find()). If you
wanted this process' uid you should have used p->uid. If you wanted this
process' effective uid (more likely) then you should have used p->euid.

Regards,
Tigran

-
To unsubscribe from this list: send 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] no RLIMIT_NPROC for root, please

[Tigran Aivazian]

On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> --- linux/kernel/fork.c~  Tue Sep  5 23:48:59 2000
> +++ linux/kernel/fork.c   Sun Nov 26 20:22:20 2000
> @@ -560,7 +560,8 @@
>   *p = *current;
>  
>   retval = -EAGAIN;
> - if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
> + if (p->user->uid &&
> +(atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur))

Jan,

Hardcoding things signifying special treatment of uid=0 is almost always a
bad idea. If you _really_ think that superuser (whatever entity that might
be) should be exempt from RLIMIT_NPROC and can prove that (SuSv2 seems to
be silent so you may be right), then you should use capable() to do proper
capability test and not that horrible explicit uid test as in your patch
above.

Regards,
Tigran

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

Re: [PATCH]: 2.4.0-testx: USB Audio

[Pavel Machek]

HI!

> This patch adds a workaround for the Dallas chip; the chip tags
> its 8bit formats with PCM8 but expects signed data.

> @@ -2895,6 +2897,9 @@
>   continue;
>   }
>   format = (fmt[5] == 2) ? (AFMT_U16_LE | AFMT_U8) : 
>(AFMT_S16_LE | AFMT_S8);
> + /* Dallas DS4201 workaround */
> + if (dev->descriptor.idVendor == 0x04fa && 
>dev->descriptor.idProduct == 0x4201)
> + format = (AFMT_S16_LE | AFMT_S8);

Should not you printk() in case of buggy hardware?
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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/

[PATCH] mad16 old OSS config

[Pavel Rabel]

Following patch is removing old config stuff which probably survived from
OSS.

Pavel Rabel

--- linux/drivers/sound/mad16.c.old Tue Nov 28 20:34:52 2000
+++ linux/drivers/sound/mad16.c Tue Nov 28 20:47:05 2000
@@ -20,38 +20,6 @@
  * issues of the card, using the OTI-605 chip, have an MPU-401 compatable Midi
  * port. This port is configured differently to that of the OPTi audio chips.
  *
- * NOTE! If you want to set CD-ROM address and/or joystick enable, define
- *   MAD16_CONF in local.h as combination of the following bits:
- *
- *  0x01- joystick disabled
- *
- *  CD-ROM type selection (select just one):
- *  0x00- none
- *  0x02- Sony 31A
- *  0x04- Mitsumi
- *  0x06- Panasonic (type "LaserMate", not "Sound Blaster")
- *  0x08- Secondary IDE (address 0x170)
- *  0x0a- Primary IDE (address 0x1F0)
- *  
- *  For example Mitsumi with joystick disabled = 0x04|0x01 = 0x05
- *  For example LaserMate (for use with sbpcd) plus joystick = 0x06
- *  
- *MAD16_CDSEL:
- *  This defaults to CD I/O 0x340, no IRQ and DMA3 
- *  (DMA5 with Mitsumi or IDE). If you like to change these, define
- *  MAD16_CDSEL with the following bits:
- *
- *  CD-ROM port: 0x00=340, 0x40=330, 0x80=360 or 0xc0=320
- *  OPL4 select: 0x20=OPL4, 0x00=OPL3
- *  CD-ROM irq: 0x00=disabled, 0x04=IRQ5, 0x08=IRQ7, 0x0c=IRQ3, 0x10=IRQ9,
- *  0x14=IRQ10 and 0x18=IRQ11.
- *
- *  CD-ROM DMA (Sony or Panasonic): 0x00=DMA3, 0x01=DMA2, 0x02=DMA1 or 
0x03=disabled
- *   or
- *  CD-ROM DMA (Mitsumi or IDE):0x00=DMA5, 0x01=DMA6, 0x02=DMA7 or 
0x03=disabled
- *
- *  For use with sbpcd, address 0x340, set MAD16_CDSEL to 0x03 or 0x23.
- *
  * Changes
  * 
  * Alan CoxClean up, added module selections.
@@ -67,6 +35,8 @@
  * 25-Nov-1999
  * Christoph Hellwig   Adapted to module_init/module_exit.
  * Arnaldo C. de Melo  got rid of attach_uart401   21-Sep-2000
+ *
+ * Pavel Rabel Clean up   Nov-2000
  */
 
 #include 
@@ -395,10 +365,6 @@
 {
unsigned char cfg = 0;
 
-#ifdef MAD16_CONF
-   cfg |= (0x0f & MAD16_CONF);
-#endif
-
if(c931_detected)
{
/* Bit 0 has reversd meaning. Bits 1 and 2 sese
@@ -435,14 +401,9 @@
/* bit 2 of MC4 reverses it's meaning between the C930
   and the C931. */
cfg = c931_detected ? 0x04 : 0x00;
-#ifdef MAD16_CDSEL
-   if(MAD16_CDSEL & 0x20)
-   mad_write(MC4_PORT, 0x62|cfg);  /* opl4 */
-   else
-   mad_write(MC4_PORT, 0x52|cfg);  /* opl3 */
-#else
+
mad_write(MC4_PORT, 0x52|cfg);
-#endif
+
mad_write(MC5_PORT, 0x3C);  /* Init it into mode2 */
mad_write(MC6_PORT, 0x02);  /* Enable WSS, Disable MPU and SB */
mad_write(MC7_PORT, 0xCB);
@@ -590,20 +551,9 @@
 */
 
tmp &= ~0x0f;
-#if defined(MAD16_CONF)
-   tmp |= ((MAD16_CONF) & 0x0f);   /* CD-ROM and joystick bits */
-#endif
mad_write(MC1_PORT, tmp);
 
-#if defined(MAD16_CONF) && defined(MAD16_CDSEL)
-   tmp = MAD16_CDSEL;
-#else
tmp = mad_read(MC2_PORT);
-#endif
-
-#ifdef MAD16_OPL4
-   tmp |= 0x20;/* Enable OPL4 access */
-#endif
 
mad_write(MC2_PORT, tmp);
mad_write(MC3_PORT, 0xf0);  /* Disable SB */

-
To unsubscribe from this list: send 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 ext2 fs corruption

[Petr Vandrovec]

On 28 Nov 00 at 12:04, David S. Miller wrote:
> 
>Yes, it is identical copy. But I do not think that hdd can write same
>data into two places with one command...
> 
> Petr, did the af_inet.c assertions get triggered on this
> same machine?

No, ext2fs is at home, and af_inet is at work... At work I'm using
vmware, at home I do not use it... But kernel sources are same
(g450 patch for matroxfb, ncpfs supporting device nodes, threaded ipx;
but neither ncpfs nor ipx is compiled at home).
   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/

[PATCH] no RLIMIT_NPROC for root, please

[Jan Rekorajski]

Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
prevent admin from shooting him/her self in the foot.

root should be able to do fork() regardless of any limits,
and IMHO the following patch is the right thing.


--- linux/kernel/fork.c~Tue Sep  5 23:48:59 2000
+++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
@@ -560,7 +560,8 @@
*p = *current;
 
retval = -EAGAIN;
-   if (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
+   if (p->user->uid &&
+  (atomic_read(>user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur))
goto bad_fork_free;
atomic_inc(>user->__count);
atomic_inc(>user->processes);

Jan
-- 
Jan Rkorajski|  ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC |   -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send 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 ext2 fs corruption

[Alexander Viro]

On Tue, 28 Nov 2000, Petr Vandrovec wrote:

> > two ranges? Then it looks like something way below the fs level... Weird.
> > Could you verify it with dd?
> 
> Yes, it is identical copy. But I do not think that hdd can write same
> data into two places with one command...
> 
> vana:/# dd if=/dev/hdd1 bs=4096 count=27 skip=722433 | md5sum
> 27+0 records in
> 27+0 records out
> 613de4a7ea664ce34b2a9ec8203de0f4
> vana:/# dd if=/dev/hdd1 bs=4096 count=27 skip=558899 | md5sum
> 27+0 records in
> 27+0 records out
> 613de4a7ea664ce34b2a9ec8203de0f4
> vana:/#

Bloody hell... OK, let's see. Both ranges are covered by multiple files
and are way larger than one page. I.e. anything on pagecache level is
extremely unlikely - pages are not searched by physical location on
disk. And I really doubt that it's ext2_get_block() - we would have
to get a systematic error (constant offset), then read the data in
for no good reason, then forget the page->buffers, then get the right
values fro ext2_get_block(), leave the data unmodified _and_ write it.

It almost looks like a request in queue got fscked up retaining the
->bh from one of the previous (also coalesced) requests and having
correct ->sector. Weird.

Linus, Andrea - any ideas? Situation looks so: after massive file creation
a range of disk with the data from new files (many new files) got
duplicated over another range - one with the data from older files
(also many of them). 27 blocks, block size == 4Kb. No intersection
between inodes, fsck is happy with fs, just a data ending up in two
places on disk. No warnings from IDE or ext2 drivers.

Kernel: test11 built with 2.95.2, so gcc bug may very well be there.
However, I really wonder what could trigger it in ll_rw_blk.c - 5:1
that shit had hit the fan there.

-
To unsubscribe from this list: send 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] lance.c - dev_kfree_skb() then reference skb->len

[Donald Becker]

On Tue, 28 Nov 2000, Eli Carter wrote:

> Patch is against 2.2.17, drivers/net/lance.c.
> I believe this to be "obviously correct," but please correct me if I'm
> wrong.
> This moves a reference to skb->len to before the possible
> dev_kfree_skb(skb) call.  Though it appears to work as is, I suspect it
> is incorrect.

This patch looks reasonable.

Perhaps it would be better to have the driver retain the skbuff until the
transmit succeeds, and only then add the length to the stats.  But this
specific bug is related the ISA bounce buffer code.  Any ISA card is in
the "legacy" category, so it's better to make minimal change needed to
correct the obvious potential problem.



Donald Becker   [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210   Second Generation Beowulf Clusters
Annapolis MD 21403  410-990-9993

-
To unsubscribe from this list: send 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.2.16-22 (RedHat 7.0) fs problem

[Alan Cox]

> when doing mount/umount of a MSDOS floppy on 2.2.16-22
> I often get
> 
> /var/log/messages.1:Nov 25 21:02:18 localhost kernel: set_blocksize: dev
> 02:00 buffer_dirty 19 size 512
> /var/log/messages.2:Nov 16 18:19:05 localhost kernel: set_blocksize: dev
> 02:00 buffer_dirty 19 size 512

It implies there were buffers still around that didnt get flushed. Its sort
of 'harmless but shouldnt happen'

> 

-
To unsubscribe from this list: send 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.2.18-23 w/Frame Buffer (LEVEL IV)

[Alex Buell]

On Mon, 27 Nov 2000, Jeff V. Merkey wrote:

> A level IV issue in 2.2.18-23.  With frame buffer enabled, upon boot,
> the OS is displaying four penguin images instead of one penguin in the
> upper left corner of the screen.  Looks rather tacky.  Also puts the
> VGA text mode default into mode 274.  Is this what's supposed to
> happen?

Have you ever used a box with more than one processor? Looks like you have
four processors on that box.

Cheers,
Alex
-- 
Tie me up, tie me down!

http://www.tahallah.clara.co.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: modutils-2.3.21: modprobe looping

[Rod Stewart]

On Wed, 29 Nov 2000, Keith Owens wrote:
> On Tue, 28 Nov 2000 20:22:59 +0100, 
> Kurt Garloff <[EMAIL PROTECTED]> wrote:
> >Find attached the modules.dep that caused this: There is a circular
> >dependency of pppoe on pppox on pppoe on 
> 
> The kernel code is broken.  Circular dependencies make no sense, the
> pppoe maintainer agrees and I thought that bug was fixed.

It is fixed in test10/11.

-Rms

-
To unsubscribe from this list: send 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: modutils-2.3.21: modprobe looping

[Keith Owens]

On Tue, 28 Nov 2000 20:22:59 +0100, 
Kurt Garloff <[EMAIL PROTECTED]> wrote:
>Find attached the modules.dep that caused this: There is a circular
>dependency of pppoe on pppox on pppoe on 

The kernel code is broken.  Circular dependencies make no sense, the
pppoe maintainer agrees and I thought that bug was fixed.

>modprobe has code to detect this in build_stack(), but it seems to not work.
>The old dep is thrown away and the new one is taken. And checked for
>dependencies again :-(
>Of course, one could also think of depmod making sure that such circular
>dependencies do not occur, but I guess, it's more robust if depmod has a
>working test in any case.

Circular dependencies are not supported, nor are they correrctly
detected.  The existing code to walk the inter module relationships,
including dependencies, alias, probe, probeall, before and after
statements is a mess.  It just grew over the years with special cases
being added and is not robust.

In modutils 2.5 the entire code will be discarded and replaced with a
standard graph walking algorithm with loop detection and back tracking
instead of special case code.  That might change some modutils
behaviour in rare cases and I do not want to change its behaviour just
before kernel 2.4 is released.  I have a list of changes that might
break backwards compatibility waiting for modutils 2.5, this is just
one of them.

-
To unsubscribe from this list: send 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.2.16-22 (RedHat 7.0) fs problem

[Vladislav Malyshkin]

when doing mount/umount of a MSDOS floppy on 2.2.16-22
I often get

/var/log/messages.1:Nov 25 21:02:18 localhost kernel: set_blocksize: dev
02:00 buffer_dirty 19 size 512
/var/log/messages.2:Nov 16 18:19:05 localhost kernel: set_blocksize: dev
02:00 buffer_dirty 19 size 512

Is this harmless or sume bug in the filesystem?

Vladislav

The system is:
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model  : 2
model name : Pentium 75 - 200
stepping : 5
cpu MHz  : 90.001
fdiv_bug : no
hlt_bug  : no
sep_bug  : no
f00f_bug : yes
coma_bug : no
fpu  : yes
fpu_exception : yes
cpuid level : 1
wp  : yes
flags  : fpu vme de pse tsc msr mce cx8
bogomips : 179.40



-
To unsubscribe from this list: send 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 ext2 fs corruption

[David S. Miller]

   From: "Petr Vandrovec" <[EMAIL PROTECTED]>
   Date:  Tue, 28 Nov 2000 21:10:36 MET-1

   Yes, it is identical copy. But I do not think that hdd can write same
   data into two places with one command...

Petr, did the af_inet.c assertions get triggered on this
same machine?

If yes, you seem to have some crazy kernel data corruptions
going on, and whatever it is would seem to be the cause of
both these problems you are reporting.

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

Re: 2.4.0-test11 ext2 fs corruption

[Petr Vandrovec]

On 28 Nov 00 at 15:02, Alexander Viro wrote:
> On Tue, 28 Nov 2000, Petr Vandrovec wrote:
> 
> > Hi Al,
> >   during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
> > with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
> > It failed to compile lbxproxy/di/main.c. After some investigation I found
> > that they were overwritten by some source font data. fsck did not reveal
> > any croslinked clusters, nothing. Filesystem itself uses 4KB clusters.
> > 
> >   Today I found some spare time and investigated it further. There is
> > same data contents in:
> > 
> > programs/lbxproxy/di/init.c 0-8720  fonts/bdf/75dpi/lubR24.bdf  0x5000-0x7210
> >  lbxfuncs.c 0x-0x0EC0   lubR24.bdf  0x8000-0x8EC0
> > 0x0EC1-0x0FFF  zero
> > 0x1000-0x5ABC   lutBS08.bdf 0x-0x4ABC
> > 0x5ABD-0x5FFF  zero
> > 0x6000-0x92C1   lutBS10.bdf 0x-0x32C1
> >  lbxutil.c  0x-0x1E27   lutBS10.bdf 0x4000-0x5E27
> > 0x1E28-0x1FFF  zero
> > 0x2000-0x3452   lutBS12.bdf 0x-0x1452   
> >  main.c 0-4614  lutBS12.bdf 0x2000-0x3206
> >  options.c  0x-0x222E   lutBS12.bdf 0x4000-0x622E
> > 0x222F-0x2FFF  zero
> > 0x3000-0x4E30   lutBS14.bdf 0x-0x1E30
> >  pm.c   0-11706 lutBS14.bdf 0x2000-0x4DA8
> >  (blocks 722433-722459)(blocks 558899-~558927)
> >  
> > Other files are intouch. As you can see, somewhat disk blocks
> > ended somewhere else than they should in addition to correct place.
> > I also found that data after end of file in di/*.c files are not
> > cleared, so maybe that ide driver did a mistake? But I was not able
> > to find how to convert either block address, or LBA adress, or CHS
> > address (drive uses 839/240/63, but I hope that it runs in LBA) to
> > get 558899 from 722433 or vice versa.
> 
> Erm... Do you mean that you've got a 1-1 correspondence in data between these
> two ranges? Then it looks like something way below the fs level... Weird.
> Could you verify it with dd?

Yes, it is identical copy. But I do not think that hdd can write same
data into two places with one command...

vana:/# dd if=/dev/hdd1 bs=4096 count=27 skip=722433 | md5sum
27+0 records in
27+0 records out
613de4a7ea664ce34b2a9ec8203de0f4
vana:/# dd if=/dev/hdd1 bs=4096 count=27 skip=558899 | md5sum
27+0 records in
27+0 records out
613de4a7ea664ce34b2a9ec8203de0f4
vana:/#

I found match by searching of contents of init.c in other files.

It is just these 27 blocks; blocks before and after range differs.
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: 2.4.0-test11 ext2 fs corruption

[Alexander Viro]

On Tue, 28 Nov 2000, Petr Vandrovec wrote:

> Hi Al,
>   during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
> with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
> It failed to compile lbxproxy/di/main.c. After some investigation I found
> that they were overwritten by some source font data. fsck did not reveal
> any croslinked clusters, nothing. Filesystem itself uses 4KB clusters.
> 
>   Today I found some spare time and investigated it further. There is
> same data contents in:
> 
> programs/lbxproxy/di/init.c 0-8720  fonts/bdf/75dpi/lubR24.bdf  0x5000-0x7210
>  lbxfuncs.c 0x-0x0EC0   lubR24.bdf  0x8000-0x8EC0
> 0x0EC1-0x0FFF  zero
> 0x1000-0x5ABC   lutBS08.bdf 0x-0x4ABC
> 0x5ABD-0x5FFF  zero
> 0x6000-0x92C1   lutBS10.bdf 0x-0x32C1
>  lbxutil.c  0x-0x1E27   lutBS10.bdf 0x4000-0x5E27
> 0x1E28-0x1FFF  zero
> 0x2000-0x3452   lutBS12.bdf 0x-0x1452   
>  main.c 0-4614  lutBS12.bdf 0x2000-0x3206
>  options.c  0x-0x222E   lutBS12.bdf 0x4000-0x622E
> 0x222F-0x2FFF  zero
> 0x3000-0x4E30   lutBS14.bdf 0x-0x1E30
>  pm.c   0-11706 lutBS14.bdf 0x2000-0x4DA8
>  (blocks 722433-722459)(blocks 558899-~558927)
>  
> Other files are intouch. As you can see, somewhat disk blocks
> ended somewhere else than they should in addition to correct place.
> I also found that data after end of file in di/*.c files are not
> cleared, so maybe that ide driver did a mistake? But I was not able
> to find how to convert either block address, or LBA adress, or CHS
> address (drive uses 839/240/63, but I hope that it runs in LBA) to
> get 558899 from 722433 or vice versa.

Erm... Do you mean that you've got a 1-1 correspondence in data between these
two ranges? Then it looks like something way below the fs level... Weird.
Could you verify it with dd?

-
To unsubscribe from this list: send 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-test12-pre2 -- Broken build. Many definitions redefined

[TimO]

Miles Lane wrote:
> 
> /usr/src/linux/include/linux/kernel_stat.h:48: for each function it
> appears in.)make[2]: *** [ksyms.o] Error 1
> make[2]: Leaving directory `/usr/src/linux/kernel'
> make[1]: *** [first_rule] Error 2
> make[1]: Leaving directory `/usr/src/linux/kernel'
> make: *** [_dir_kernel] Error 2
> 

Oddly enough, I had to run 'make mrproper' on a clean tree (patched
from -test1 -> test12p2) in order to make it compile.

-- 
===
-- Tim
-
To unsubscribe from this list: send 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 ext2 fs corruption

[Petr Vandrovec]

Hi Al,
  during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
It failed to compile lbxproxy/di/main.c. After some investigation I found
that they were overwritten by some source font data. fsck did not reveal
any croslinked clusters, nothing. Filesystem itself uses 4KB clusters.

  Today I found some spare time and investigated it further. There is
same data contents in:

programs/lbxproxy/di/init.c 0-8720  fonts/bdf/75dpi/lubR24.bdf  0x5000-0x7210
 lbxfuncs.c 0x-0x0EC0   lubR24.bdf  0x8000-0x8EC0
0x0EC1-0x0FFF  zero
0x1000-0x5ABC   lutBS08.bdf 0x-0x4ABC
0x5ABD-0x5FFF  zero
0x6000-0x92C1   lutBS10.bdf 0x-0x32C1
 lbxutil.c  0x-0x1E27   lutBS10.bdf 0x4000-0x5E27
0x1E28-0x1FFF  zero
0x2000-0x3452   lutBS12.bdf 0x-0x1452   
 main.c 0-4614  lutBS12.bdf 0x2000-0x3206
 options.c  0x-0x222E   lutBS12.bdf 0x4000-0x622E
0x222F-0x2FFF  zero
0x3000-0x4E30   lutBS14.bdf 0x-0x1E30
 pm.c   0-11706 lutBS14.bdf 0x2000-0x4DA8
 (blocks 722433-722459)(blocks 558899-~558927)
 
Other files are intouch. As you can see, somewhat disk blocks
ended somewhere else than they should in addition to correct place.
I also found that data after end of file in di/*.c files are not
cleared, so maybe that ide driver did a mistake? But I was not able
to find how to convert either block address, or LBA adress, or CHS
address (drive uses 839/240/63, but I hope that it runs in LBA) to
get 558899 from 722433 or vice versa.

Motherboard is i440BX, HDD was IDE TOSHIBA MK6409MAV on secondary IDE,
running UDMA2.

Nobody complained - neither IDE nor kernel nor ext2, just data were
damaged. Machine does not have any other problems, so I have no idea
what caused this incident. Maybe I stressed MM system too much with
some gnome app during untar?

And last note, according to debian/scripts/source.unpack, programs/lbxproxy
was created first, and fonts/bdf/... was created after that (i.e.
X401src-1 was decompressed first, X401src-2_debian was decompressed
second). This also agrees with zeroed bytes in these datablocks.
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]

P.S.: Ted, why field 'Blocks: XXX' in debugfs (1.19) is 'Sectors: '
in reality (it reports blocks * 8, so I assume (as I have 4KB clusters)
that it converts it to sector count)?
-
To unsubscribe from this list: send 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"

[Andrea Arcangeli]

On Tue, Nov 28, 2000 at 05:09:48PM +0100, Andreas Schwab wrote:
> including the Linux kernel. :-)

As it's a worthless extension it's always trivial to fixup after its removal :).

The fixup also shown that the sis_300 and sis_301 driver would break if used at
the same time (probably unlikely to happen as they're FB drivers though).

This patch compiles 2.4.0-test12-pre2 with -fno-common and it fixups some minor
compilation problem around the kernel. Karsten note the lc_start_delay_check
change I did to make it to compile, it's not implemented yet, it only compiles
right now.

Patch is verified to compile with almost everything linked into the kernel, and
it boots with my normal configuration.

--- 2.4.0-test12-pre2-fno-common/drivers/char/applicom.c.~1~Thu Jul 13 06:58:42 
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/char/applicom.cTue Nov 28 19:07:05 
+2000
@@ -63,8 +63,8 @@
 #define PCI_DEVICE_ID_APPLICOM_PCIGENERIC 0x0001
 #define PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN 0x0002
 #define PCI_DEVICE_ID_APPLICOM_PCI2000PFB 0x0003
-#define MAX_PCI_DEVICE_NUM 3
 #endif
+#define MAX_PCI_DEVICE_NUM 3
 
 static char *applicom_pci_devnames[] = {
"PCI board",
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.c.~1~Tue Nov 28 
18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.cTue Nov 28 19:46:08 
+2000
@@ -522,6 +522,11 @@
l3ml3p(st, DL_RELEASE | CONFIRM);
 }
 
+static void
+lc_start_delay_check(struct FsmInst *fi, int event, void *arg)
+{
+   /* FIXME */
+}
 
 /* *INDENT-OFF* */
 static struct FsmNode L3FnList[] __initdata =
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c.~1~  Tue Nov 28 18:40:29 
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c  Tue Nov 28 19:47:21 
+2000
@@ -75,7 +75,7 @@
(cs->hw.njet.last_is0 & NETJET_IRQM0_READ))
/* we have a read dma int */
read_tiger(cs);
-   if (cs->hw.njet.irqstat0 & NETJET_IRQM0_WRITE) !=
+   if ((cs->hw.njet.irqstat0 & NETJET_IRQM0_WRITE) !=
(cs->hw.njet.last_is0 & NETJET_IRQM0_WRITE))
/* we have a write dma int */
write_tiger(cs);
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c.~1~  Tue Nov 28 18:40:29 
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c  Tue Nov 28 19:48:52 
+2000
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "netjet.h"
 
 const char *NETjet_U_revision = "$Revision: 2.8 $";
@@ -131,7 +132,7 @@
return(0);
 }
 
-static struct pci_dev *dev_netjet __initdata;
+static struct pci_dev *dev_netjet __initdata = 0;
 
 int __init
 setup_netjet_u(struct IsdnCard *card)
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.c.~1~Tue Nov 28 
18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.cTue Nov 28 20:04:59 
+2000
@@ -376,7 +376,7 @@
 #endif /* IO0_IO1 */
 #endif /* MODULE */
 
-static int nrcards;
+int nrcards;
 
 extern char *l1_revision;
 extern char *l2_revision;
--- 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h.~1~ Tue Nov 28 18:50:21 
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h Tue Nov 28 18:51:19 
+2000
@@ -179,9 +179,9 @@
 
 /* i2c */
 #define I2C_CLIENTS_MAX 8
-struct i2c_algo_bit_data bttv_i2c_algo_template;
-struct i2c_adapter bttv_i2c_adap_template;
-struct i2c_client bttv_i2c_client_template;
+extern struct i2c_algo_bit_data bttv_i2c_algo_template;
+extern struct i2c_adapter bttv_i2c_adap_template;
+extern struct i2c_client bttv_i2c_client_template;
 void bttv_bit_setscl(void *data, int state);
 void bttv_bit_setsda(void *data, int state);
 void bttv_call_i2c_clients(struct bttv *btv, unsigned int cmd, void *arg);
--- 2.4.0-test12-pre2-fno-common/drivers/net/arlan.h.~1~Tue Nov 28 19:10:06 
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/net/arlan.hTue Nov 28 19:11:44 2000
@@ -321,7 +321,7 @@
   int tx_queue_len;
 };
 
-struct arlan_conf_stru arlan_conf[MAX_ARLANS];
+extern struct arlan_conf_stru arlan_conf[MAX_ARLANS];
 
 struct TxParam
 {
--- 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h.~1~  Tue Nov 28 19:25:37 
2000
+++ 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h  Tue Nov 28 19:40:11 
+2000
@@ -187,7 +187,7 @@
 extern struct semaphore us_list_semaphore;
 
 /* The structure which defines our driver */
-struct usb_driver usb_storage_driver;
+extern struct usb_driver usb_storage_driver;
 
 /* Function to fill an inquiry response. See usb.c for details */
 extern void fill_inquiry_response(struct us_data *us,
--- 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.h.~1~Tue Nov 28 
18:40:01 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.hTue Nov 28 19:28:42 
+2000
@@ -95,15 +95,6 @@
 
 #endif
 
-USHORT  P3c4,P3d4,P3c0,P3ce,P3c2,P3ca,P3c6,P3c7,P3c8,P3c9,P3da;
-USHORT  

modutils-2.3.21: modprobe looping

[Kurt Garloff]

Hi Keith,

thanks for your modutils-2.3.21!

During testing I found a problem:
modprobe pppoe was recursing endlessly in build_stack().

Find attached the modules.dep that caused this: There is a circular
dependency of pppoe on pppox on pppoe on 

modprobe has code to detect this in build_stack(), but it seems to not work.
The old dep is thrown away and the new one is taken. And checked for
dependencies again :-(
Of course, one could also think of depmod making sure that such circular
dependencies do not occur, but I guess, it's more robust if depmod has a
working test in any case.

Test system was a PPC machine running 2.4.0-test9.

Do you have a fix for this?

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security


/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_async.o:
/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_generic.o

/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_deflate.o:  
/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_generic.o

/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_generic.o:

/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_synctty.o:  
/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_generic.o

/lib/modules/2.4.0-test9/kernel/drivers/net/pppoe.o:
/lib/modules/2.4.0-test9/kernel/drivers/net/pppox.o \
/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_generic.o

/lib/modules/2.4.0-test9/kernel/drivers/net/pppox.o:
/lib/modules/2.4.0-test9/kernel/drivers/net/pppoe.o \
/lib/modules/2.4.0-test9/kernel/drivers/net/ppp_generic.o

/lib/modules/2.4.0-test9/kernel/drivers/net/skfp/skfp.o:

/lib/modules/2.4.0-test9/kernel/drivers/net/slip.o:


 PGP signature

Re: reproducible 2.2.1x nethangs

[Clayton Weaver]

I retract the comment about "accept() 2nd argument scribbled over
in the child". That was a misinterpretation of the strace log.
strace shows the struct sockaddr * scribble in the parent after a restart
of the accept() call. Also, the firewalling code is eliminated from
consideration. I compiled it and ppp out, and the only difference was that
the hang happened sooner, in about a dozen http connects instead of
around 30.

What happens, according to strace, is that accept() gets interrupted when
the SIGCHLD signal is delivered after the child that handled the previous
connect exits, and accept() sets ERESTARTSYS.

For the first N connects, this is not problematic. accept() is called
again, it returns normally, the fork() happens, everything is
copascetic. But eventually the restarted accept() call shows nul bytes in
the struct sockaddr *addr arg value in the strace output after
restarting accept, and a few connects later the kernel hangs.

If the socket itself is truly ozoned when strace says the accept() struct
sockaddr * argument has changed in between interrupt and restart, the
subsequent forked child shouldn't be able to send at all, but that is not
what happens. That html document gets there.

Yet the kernel always hangs within a few connects of seeing that, so I'd
be suspicious of the internal kernel data associated with that socket
when it comes time to deallocate it. The accept() code in the context of
interrupts that cause it to be stopped and restarted is at least worth a
look for possible races.

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

[Mr. Big]

> > The output of lspci -v:
> [...]
> > 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
> > Subsystem: Intel Corporation 82559 Fast Ethernet LAN on Motherboard
> > Flags: bus master, medium devsel, latency 64, IRQ 5
> 
>  Hmm, this is the device you reported you have a problem initially, isn't
> it?  If it is, then...
> 
> > 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 
>[UHCI])
> > Flags: bus master, medium devsel, latency 64, IRQ 5
> 
>  ... it shares its IRQ with an USB host adapter as I suspected.  And you
> don't have an USB driver installed.  Does the following patch help?  (Hmm,
> since you tested 2.4.0-test* as well -- it might not as it's just a
> backport...  Then again -- you might hit a different problem with
> 2.4.0-test*.) 

Yes You are right. This Ether Express is integrated on the motherboard, so
we couldn't get it out totally :( But there isn't any cable connected to
it, we also doesn't have the driver in the kernel. This is the same with
the USB too. Do You mind, that they could have some kind of conflict just
on they own, without being really used?

Currently after changing the processors to Katmais, and disabling the
apic, and some of the other unused peripheries, it seems, that the system
is more stable. If the errors come again, I'll try to compile the USB
driver also.


>  It's not impossible for an I/O APIC to lose an EOI message if there are
> severe errors during the transmission -- since you already tried
> 2.4.0-test*: have you seen any APIC errors in the syslog? 

Nope, specially we didn't get errors from the APIC himself. But both
network cards (except the EtherExpress) were saying errors considering to
interrupts.
3Com:
kernel: eth0: Interrupt posted but not delivered -- IRQ blocked by another
device?
kernel:   Flags; bus-master 1, full 0; dirty 112(0) current 112(0).
kernel:   Transmit list  vs. f20ac200.
kernel:   0: @f20ac200  length 8036 status
...
kernel:   15: @f20ac2f0  length 8042 status
kernel: eth0: Resetting the Tx ring pointer.


DLink:
Kernel Panic: skput:over: a00f8d9b: 1526 put: 66 dev: eth1
In interrupt handler - not syncing

after SysRQ+ALT+u:
Aiee, killing interrupt handler
Unable to handle kernel NULL pointer dereference

Thanx for the USB patch, I'll try it also.


++
| 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: Bug in date converting functions DOS<=>UNIX in FAT, NCPFS andSMBFS drivers

[Urban Widmark]

On Fri, 24 Nov 2000, Igor Yu. Zhbanov wrote:

> Hello!

Hello, sorry for the slow response.

> I have found a bug in drivers of file systems which use a DOS-like format
> of date (16 bit: years since 1980 - 7 bits, month - 4 bits, day - 5 bits).

[snip]

> 2) VFAT for example have three kinds of dates: creation date, modification date
>and access date. Sometimes one of these dates is set to zero (which indicates
>that this date is not set). Zero is not a valid date (e.g. months are
>numbered from one, not from zero) and can't be properly converted to
>UNIX-like format of date (it was converted to date before 1980).

Days are also numbered from one (at least smbfs) and this change doesn't
do anything about that. An all zero date gives 315446400 (or else my
testprogram is broken) and you wanted it to give 315532800 (?). So that
should be fixed too, I think.

It would be nice if someone would rewrite these shift-and-mask orgies into
something with a bit more structure (bitfields? hmm, endianess problems?
undefined compiler behaviour? I don't know ... macros?).

I'm having trouble following these, but maybe that's just me.

/Urban

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

Re: KERNEL BUG: console not working in linux

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Gianluca Anzolin <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> |No, the problem is the utterly braindamaged way the motherboard chose to
> |enable/disable it (*especially* if it's PCI... sheech, port 92h isn't
> |exactly something new in that timeframe.)
> |
> |What PC/motherboard is this, anyway?
> 
> It's an olivetti, but maybe they bought the mainboard elsewhere I don't
> know. Anyway you can find the lspci -xvv in
> http://www.gest.unipd.it/~iig0573/lspci.txt
> 

It's not "an Olivetti", it has a model number and God Knows What.
>From the looks of it they are using a 440FX chipset, which definitely
does not have this problem inherently (and almost certainly handles
port 92h correctly), so whomever wired up this motherboard was even
more of an idiot that I first thought.

If I were you I would take it back and demand a refund.  It isn't a PC
you have there.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] lance.c - dev_kfree_skb() then reference skb->len

[Eli Carter]

Greetings all,

Patch is against 2.2.17, drivers/net/lance.c.
I believe this to be "obviously correct," but please correct me if I'm
wrong.
This moves a reference to skb->len to before the possible
dev_kfree_skb(skb) call.  Though it appears to work as is, I suspect it
is incorrect.

Please apply or let me know why.

Eli

ps.  It's an attachment rather than inline because I can't seem to get
Netscape (4.71) to do that without replacing tabs with spaces.  Grr.

. "To the systems programmer, users and applications
Eli Carter  | serve only to provide a test load."
[EMAIL PROTECTED] `-- (random fortune)

--- lance.c.2.2.17  Mon Nov 13 12:13:11 2000
+++ lance.c Tue Nov 28 11:46:16 2000
@@ -926,6 +926,8 @@
 
lp->tx_ring[entry].misc = 0x;
 
+   lp->stats.tx_bytes += skb->len;
+
/* If any part of this buffer is >16M we must copy it to a low-memory
   buffer. */
if ((u32)virt_to_bus(skb->data) + skb->len > 0x0100) {
@@ -941,7 +943,6 @@
lp->tx_ring[entry].base = ((u32)virt_to_bus(skb->data) & 0xff) | 
0x8300;
}
lp->cur_tx++;
-   lp->stats.tx_bytes += skb->len;
 
/* Trigger an immediate send poll. */
outw(0x, ioaddr+LANCE_ADDR);

Re: bug in count_open_files() or a strange granularity?

[Tigran Aivazian]

On Tue, 28 Nov 2000, Alexander Viro wrote:
> You know, in such cases usual course of actions is to remove the bloody
> thing. It's not used, it's not set to anything useful, semantics is
> fundamentally non-obvious, so Occam's Razor applies. Until somebody
> comes up with a reasonable use _and_ clear semantics... Trying to invent
> one simply because the field is there looks, erm, odd.

Yes, I agree and, like I said, there are other things to do still. It just
looked like "the field was added recently but no support for it so it may
be a 'must-have' item for 2.4.0" which is why I rushed to try and give it
some meaning.

At least one useful thing came out of this exercise -- I understand the fd
allocation (fs/file.c) routines now.

Regards,
Tigran

-
To unsubscribe from this list: send 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 in exec_usermodehelper

[Petr Vandrovec]

On 29 Nov 00 at 1:53, Andrew Morton wrote:

> hmm..  Quite a few things fixed here.
> 
> Could you please test this patch?  It's against 2.4.0-test12-pre2,
> should be OK against test11.

I upgraded to 12-pre2 already ;-) It looks like that it works.
 
> - keventd is now capable of reaping dead children.  I will be all ears
>   if someone can tell me how to get a kernel thread to accept signals
>   without having to install a handler with
> 
> sa.sa_handler = (__sighandler_t)100;

Is there any reason why not set sa.sa_handler to SIG_IGN? According
to arch/i386/kernel/signal.c:do_signal(), signal manpage and my memory,
kernel does automatic child reaping in such configuration. So you
could even remove waitpid() loop from keventd. I did not tried it yet,
but it looks like obvious solution... 

BTW, are you sure that kernel does not try to deliver SIGSEGV to 
keventd() when signal arrives. It looks like that it should, but it
probably fails somewhere during way due to non-existent userspace for
this process.
 
> +   sa.sa.sa_handler = (__sighandler_t)100; /* Surely there's a better way? */
> +   sa.sa.sa_flags = 0;

SA_RESTART? SA_NOCLDSTOP ?

> +   do_sigaction(SIGCHLD, , (struct k_sigaction *)0);
>  
> for (;;) {
> -   current->state = TASK_INTERRUPTIBLE;
> +   __set_task_state(curtask, TASK_INTERRUPTIBLE);
> add_wait_queue(_task_wq, );
>  
> /*
> @@ -46,15 +59,19 @@
> schedule();
>  
> remove_wait_queue(_task_wq, );
> -   current->state = TASK_RUNNING;
> +   __set_task_state(curtask, TASK_RUNNING);
> run_task_queue(_context);
> +   if (signal_pending(curtask)) {
> +   while (waitpid(-1, (unsigned int *)0, __WALL|WNOHANG) > 0)
> +   ;
> +   flush_signals(curtask);
> +   recalc_sigpending(curtask);
> +   }

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: bug in count_open_files() or a strange granularity?

[Alexander Viro]

On Tue, 28 Nov 2000, Tigran Aivazian wrote:

> it is not basic at all. The problems you point out are extremely complex
> (at least the fd in transit issue, definitely is). 
> 
> So, yes it requires a bit more thought. I will come back when the issues
> you pointed out are dealt with. Someone has added the 'files' field to the
> 'struct user_struct' so someone must have meant to put support for this
> field to be something other than the meaningless 0 it currently is.

You know, in such cases usual course of actions is to remove the bloody
thing. It's not used, it's not set to anything useful, semantics is
fundamentally non-obvious, so Occam's Razor applies. Until somebody
comes up with a reasonable use _and_ clear semantics... Trying to invent
one simply because the field is there looks, erm, odd.

-- 
POSIX should be renamed to FPOSIX - it is U*IX-like, all right, but POS is
too mild to describe its quality.

-
To unsubscribe from this list: send 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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes

[Petter Sundlöf]

I bought this card on the promise that there'd be open drivers.

Sigh.

I shall forward the bug report to NVIDIA.

Alan Cox wrote:
> 
> > My graphics card is a NVIDIA GeForce DDR, using the 0.9-5 release. For
> > -test11 I had to patch 0.9-5 (but this was only a very trivial patch, I
> > am told).
> 
> If you are using the nvidia kernel module you should tell nvidia. Nobody
> else can help you since they obfuscated the 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: lmbench on linux-2.4.0-test[4-11]

[David S. Miller]

   Date:   Tue, 28 Nov 2000 18:23:52 +0100
   From: Lorenzo Allegrucci <[EMAIL PROTECTED]>

   BTW, all local services (smtp, telnet etc) work well.  Any ideas?

No ideas, and since the indicated programs from lmbench work
perfectly fine here on my machines, you're going to have to do some
detective work so we can figure out whats wrong.

You need to do some strace'ing of the affected programs and try
to figure out exactly how they get stuck and for what reason.

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

Re: lmbench on linux-2.4.0-test[4-11]

[Lorenzo Allegrucci]

At 01.57 28/11/00 -0800, you wrote:
>   Date:   Tue, 28 Nov 2000 11:08:17 +0100
>   From: Lorenzo Allegrucci <[EMAIL PROTECTED]>
>
>   Does anyone confirm this problem?
>
>Increase the space between the two numbers configured in
>/proc/sys/net/ipv4/ip_local_port_range, try a configuration
>such as:
>
>echo "32768 61000" >/proc/sys/net/ipv4/ip_local_port_range
>
>I bet the problem goes away then.

ip_local_port_range already comes with such configuration.
Anyhow, now even test1 shows the problem :-(
I can run lmbench on 2.2.x kernels only.
BTW, all local services (smtp, telnet etc) work well.
Any ideas?

--
Lorenzo
-
To unsubscribe from this list: send 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: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes

[Alan Cox]

> My graphics card is a NVIDIA GeForce DDR, using the 0.9-5 release. For
> -test11 I had to patch 0.9-5 (but this was only a very trivial patch, I
> am told).

If you are using the nvidia kernel module you should tell nvidia. Nobody
else can help you since they obfuscated the 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/