Re: CPU attachent and detachment in a running Linux system

2000-12-17 Thread Heiko . Carstens





Hi,

>> I still wonder what you and other people think about the idea of an
>> interface where the parts of the kernel with per-cpu dependencies should
>> register two functions...
>Why not compile kernel with structeres big enough for 32 processors,
>and then just add CPUs up to the limit without changing anything?

That's a good point and it would probably work for attachment of cpus, but
it won't work for detachment because there are some data structures that
need to be updated if a cpu gets detached. For example it would be nice
to flush the per-cpu cache of the detached cpu in the slabcache. Then one
has to think of pending tasklets for the detached cpu which should be
moved to another cpu and then there are a lot of per-cpu data structures
in the networking part of the kernel.. most of them seem to be for
statistics only but I think these structures should be updated in any
case.
So at least for detaching it would make sense to register functions which
will be called whenever a cpu gets detached.

Heiko


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



Problem with 3c59x and 3C905B

2000-12-17 Thread Michael Illgner

Hi folks,
I have some trouble using a 3COM NIC905B and the 3c59x driver with kernel
2.2.x
and 2.4.0.testx. First of all the card works fine with Windows or with linux
2.2.18
using the 3c90x driver supplied by 3COM. But with the 3c59x driver I get
transfer rates
below 10k/s or even lower. The card is connected to a 10/100 Hub (Netgear
DS104).

Here are some informations

Kernel version

2.2.18 SMP and 2.4.0.test12 SMP (latest kernel) but the problem seems
to be independent of the kernel version.


Banner message

Dec 17 19:44:48 ganerc kernel: 3c59x.c:LK1.1.11 13 Nov 2000  Donald Becker
and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
Dec 17 19:44:48 ganerc kernel: See Documentation/networking/vortex.txt
Dec 17 19:44:48 ganerc kernel: eth0: 3Com PCI 3c905B Cyclone 100baseTx at
0xdc00,  00:10:5a:d8:25:f1, IRQ 19
Dec 17 19:44:48 ganerc kernel: Full duplex capable
Dec 17 19:44:48 ganerc kernel:   8K byte-wide RAM 5:3 Rx:Tx split,
autoselect/Autonegotiate interface.
Dec 17 19:44:48 ganerc kernel:   MII transceiver found at address 24, status
786d.
Dec 17 19:44:48 ganerc kernel:   MII transceiver found at address 0, status
786d.
Dec 17 19:44:48 ganerc kernel:   Enabling bus-master transmits and
whole-frame receives.
Dec 17 19:44:48 ganerc kernel: eth0: using NWAY autonegotiation


lspci -vx

00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 30)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
Flags: bus master, medium devsel, latency 64, IRQ 19
I/O ports at dc00 [size=128]
Memory at e100 (32-bit, non-prefetchable) [size=128]
Expansion ROM at df00 [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
00: b7 10 55 90 07 00 10 02 30 00 00 02 08 40 00 00
10: 01 dc 00 00 00 00 00 e1 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90
30: 00 00 00 df dc 00 00 00 00 00 00 00 0a 01 0a 0a


Here are some messages from syslog

Dec 17 19:59:15 ganerc kernel: vortex_up(): writing 0x380 to
InternalConfig
Dec 17 19:59:15 ganerc kernel: eth0: MII #24 status 786d, link partner
capability 40a1, setting half-duplex.
Dec 17 19:59:15 ganerc kernel: eth0: MII #24 status 786d, link partner
capability 40a1, setting half-duplex.
Dec 17 19:59:15 ganerc kernel: eth0: vortex_up() InternalConfig 0380.
Dec 17 19:59:15 ganerc kernel: eth0: vortex_up() irq 19 media status 8080.
Dez 17 19:59:16 ganerc network: Bringing up interface eth0:  succeeded
Dec 17 19:59:18 ganerc kernel: eth0: Media selection timer tick happened,
Autonegotiate.
Dec 17 19:59:18 ganerc kernel: dev->watchdog_timeo=40
Dec 17 19:59:18 ganerc kernel: eth0: MII transceiver has status 7869.
Dec 17 19:59:18 ganerc kernel: eth0: Media selection timer finished,
Autonegotiate.
Dec 17 19:59:29 ganerc kernel: boomerang_start_xmit()
Dec 17 19:59:29 ganerc kernel: eth0: Trying to send a packet, Tx index 0.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe201
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e201, latency 8
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e201.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe401
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e401, latency 6
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e401.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt->boomerang_rx
Dec 17 19:59:29 ganerc kernel: boomerang_rx(): status e001
Dec 17 19:59:29 ganerc kernel: Receiving packet size 60 status 803c.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:29 ganerc kernel: boomerang_start_xmit()
Dec 17 19:59:29 ganerc kernel: eth0: Trying to send a packet, Tx index 1.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe201
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e201, latency 5
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e201.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt. status=0xe401
Dec 17 19:59:29 ganerc kernel: eth0: interrupt, status e401, latency 6
ticks.
Dec 17 19:59:29 ganerc kernel: eth0: In interrupt loop, status e401.
Dec 17 19:59:29 ganerc kernel: boomerang_interrupt->boomerang_rx
Dec 17 19:59:29 ganerc kernel: boomerang_rx(): status e001
Dec 17 19:59:29 ganerc kernel: Receiving packet size 98 status 20008062.
Dec 17 19:59:29 ganerc kernel: eth0: exiting interrupt, status e000.
Dec 17 19:59:30 ganerc kernel: boomerang_start_xmit()
Dec 17 19:59:30 ganerc kernel: eth0: Trying to send a packet, Tx index 2.
Dec 17 19:59:30 ganerc kernel: boomerang_interrupt. status=0xe201
Dec 17 19:59:30 ganerc kernel: eth0: interrupt, status e201, latency 5
ticks.
Dec 17 19:59:30 ganerc kernel: eth0: In interrupt loop, status e201.
Dec 17 19:59:30 ganerc kernel: eth0: exiting interrupt, status 

Re: [PATCH] link time error in drivers/mtd (240t13p2)

2000-12-17 Thread Peter Samuelson


[Horst von Brand]
> Would tsort(1) perhaps help?

I'm betting Linus would never go for using tsort to resolve such issues
-- unless tsort output is guaranteed to be stable (the docs for GNU
textutils don't say).  This would be for the same reason that he
rejected the partial ordering in the LINK_FIRST patch -- because it was
only partial ordering and he thinks total ordering is necessary.  For
me, BTW, that's still an article of faith -- I still do not see why
total ordering *is* necessary, but  thus saith the penguin.

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: kernel-doc minor fix

2000-12-17 Thread Simon Huggins

On Sat, Dec 16, 2000 at 04:41:44PM +0200, Jani Monoses wrote:
> --- /usr/src/linux/scripts/kernel-doc Tue Dec 12 11:25:59 2000
> +++ kernel-docSat Dec 16 15:53:17 2000
> @@ -664,10 +664,11 @@

>  ##
>  # takes a function prototype and spits out all the details
> -# stored in the global arrays/hsahes.
> +# stored in the global arrays/hashes.
>  sub dump_function {
>  my $prototype = shift @_;

> +$prototype =~ s/^const+ //;
>  $prototype =~ s/^static+ //;
>  $prototype =~ s/^extern+ //;
>  $prototype =~ s/^inline+ //;

Since when did C accept cons and static?
etc.

Should that be " +" not "+ " or is someone just trying to confuse me?
Or did someone try to mean s/foo//g by adding a +?


Yours confusedly,

Simon.

-- 
[ "Therapy is expensive. Popping bubble wrap is cheap. You choose."]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: APM/DPMS lockup on Dell 3800

2000-12-17 Thread David Feuer

Dagnabbit.  I forgot to give my kernel version, and now I'm booted into 
Windows, and can't remember it.  It's some 2.2 kernel: whatever comes with 
Mandrake 7.2.

At 07:14 AM 12/18/2000 +0100, you wrote:
>
>
>I have a Dell Inspiron 7000 with BIOS A15 and exactly the same
>problem.
>
>(I last observed this problem using linux-2.4.0-test12, though.
>Now I'm running test13-pre3 and it has not yet occurred.)
>-


--
This message has been brought to you by the letter alpha and the number pi.
Open Source: Think locally; act globally.
David Feuer
[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] 2.4.0-test13-pre3: Makefile problem in drivers/video

2000-12-17 Thread Peter Samuelson


[Norbert Breun]
> The problem is, there should be a directory "media" under
> /lib/modules/2.4.0-test12.old/kernel/drivers/ and this is missing in
> test13pre2 and test13pre3. The modules are not built.

Does this help?  I think it's right.

Peter

diff -urk.orig 2.4.0test13pre3/drivers/media/Makefile
--- 2.4.0test13pre3/drivers/media/Makefile.orig Sat Dec 16 06:18:16 2000
+++ 2.4.0test13pre3/drivers/media/Makefile  Mon Dec 18 01:32:34 2000
@@ -10,6 +10,7 @@
 #
 
 subdir-y := video radio
+subdir-m := video radio
 
 O_TARGET := media.o
 obj-y:= $(join $(subdir-y),$(subdir-y:%=/%.o))
-
To unsubscribe from this list: send the 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-test13-pre3: Makefile problem in drivers/video

2000-12-17 Thread Norbert Breun

Peter,

you may be right there is no module "video.o". The problem is, there should 
be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/ 
and this is missing in test13pre2 and test13pre3. The modules are not built.

kind regards
Norbert


On Monday 18 December 2000 07:11, Peter Samuelson wrote:
> [Mikael Djurfeldt]
>
> > When trying to build video.o as a module, video.o doesn't get copied
> > to /lib/modules/* during installation.
>
> There is no video.o module.  If video.o is built at all, it is linked
> into the vmlinux image directly.  The modules in that directory will be
> atyfb.o, tdfxfb.o and about 800 others.
>
> 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/
-
To unsubscribe from this list: send the 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-test13-pre2, unresolved symbols

2000-12-17 Thread Norbert Breun

Keith,

thanks for your hint. The problem seems that all modules (+ directory 
~/media) under /lib/modules/2.4.0-test13pre3/kernel/drivers/media/  are 
missing. Make modules_install does not build the directory ~/media and its 
contents. There were no modules built under /linux/drivers/media/video or 
~radio.
BTW: this time I used 2.4.0-test13pre3 + your minipatch ...

kind regards
Norbert


On Sunday 17 December 2000 09:32, Keith Owens wrote:
> On Sun, 17 Dec 2000 09:22:04 +0100,
>
> Norbert Breun <[EMAIL PROTECTED]> wrote:
> >having applied your patch below + modutils2.3.23-1 +
> > kernel2.4.0-test13pre2 all seems to run perfect.
> >But when starting kwintv  /dev/video is not found. /dev/video is a symling
> > on /dev/video0 and with kernel kernel2.4.0-test12 there is no problem at
> > all.
> >
> >>can't open /dev/video: Kein passendes Gerät gefunden
>
> "No suitable device found", -ENODEV.  The video driver has not been
> loaded or has not been initialised correctly.  Compare the dmesg output
>
> >from 2.4.0-test12 and 0-test13-pre2 to see what is different.  It might
>
> be a side effect of Linus's Makefile reordering.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: unresolved symbols pm_*register ad1848.o

2000-12-17 Thread Peter Samuelson


[Peter Samuelson]
> Looks like your symbol versions got out of sync, somehow.

Uh, never mind, I didn't notice that pm.c is not listed as exporting
symbols.  Someone else just posted a patch -- add pm.o to the
'export-objs' line in kernel/Makefile.

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: unresolved symbols pm_*register ad1848.o

2000-12-17 Thread Peter Samuelson


[khromy]
> 2.4.0-test13-pre3 unresolved symbols:
> 
> modprobe ad1848
> /lib/modules/2.4.0-test13-pre3/kernel/drivers/sound/ad1848.o: unresolved symbol 
>pm_unregister_Reccd1e64
> /lib/modules/2.4.0-test13-pre3/kernel/drivers/sound/ad1848.o: unresolved symbol 
>pm_register_R8dbab11c

Looks like your symbol versions got out of sync, somehow.
Unfortunately this is fairly easy to do, due to the fragile nature of
MODVERSIONS.

  cp .config ..
  make mrproper
  cp ../.config .
  make oldconfig
  make dep

and try again.

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: APM/DPMS lockup on Dell 3800

2000-12-17 Thread Mikael Djurfeldt

David Feuer <[EMAIL PROTECTED]> writes:

> I get this problem both in Linux and Windows, so I won't
> rule out hardware/bios bugs, but I find that often when my
> monitor (backlight) gets turned off automatically after a
> long period of non-use, the computer freezes up.  I think it
> only happens when I've left it that way for a long time,
> though.  If I move the mouse immediately after the screen is
> blacked, I have no trouble, but if I leave it for a long
> time, when I get back the monitor won't unblack,
> ctrl-alt-backspace does nothing, ctrl-alt-delete does
> nothing,  Fn-Suspend, Fn-A don't do anything, and the
> capslock and numlock keys don't do anything either.  I
> haven't tried reaching the machine from outside yet, but I
> will if someone wants.

I have a Dell Inspiron 7000 with BIOS A15 and exactly the same
problem.

(I last observed this problem using linux-2.4.0-test12, though.
Now I'm running test13-pre3 and it has not yet occurred.)
-
To unsubscribe from this list: send the 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-test13-pre3: Makefile problem in drivers/video

2000-12-17 Thread Peter Samuelson


[Mikael Djurfeldt]
> When trying to build video.o as a module, video.o doesn't get copied
> to /lib/modules/* during installation.

There is no video.o module.  If video.o is built at all, it is linked
into the vmlinux image directly.  The modules in that directory will be
atyfb.o, tdfxfb.o and about 800 others.

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: test13-pre3 woes

2000-12-17 Thread Niels Kristian Bech Jensen

On Mon, 18 Dec 2000, J Sloan wrote:

> Similar problem here - with CONFIG_DRM_TDFX=m
> I have not gotten a tdfx.o module complied since the
> start of the test13-pre series...
>
> So no quake 3 arena unless I want to play at < 1 fps...
>
Does this patch fix your problem?

--- test13-pre3/drivers/char/Makefile   Mon Dec 18 01:21:31 2000
+++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000
@@ -16,6 +16,8 @@

 O_TARGET := char.o

+mod-subdirs := drm
+
 obj-y   += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o

 # All of the (potential) objects that export symbols.

-- 
Niels Kristian Bech Jensen -- [EMAIL PROTECTED] -- http://www.image.dk/~nkbj/

--->>  Stop software piracy --- use free software!  <<---

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



Re: test13-pre3

2000-12-17 Thread Peter Samuelson


[Albert Cranford]
> With CONFIG_DRM_R128=m
> we fail to produce module linux/drivers/char/drm/r128.o

He's right.  Linus, please apply.

Peter

--- test13pre3/drivers/char/Makefile.orig   Wed Dec 13 23:56:01 2000
+++ test13pre3/drivers/char/MakefileSun Dec 17 23:55:00 2000
@@ -25,6 +25,7 @@
misc.o pty.o random.o selection.o serial.o \
tty_io.o
 
+mod-subdirs:=  joystick ftape drm pcmcia
 list-multi :=  
 
 KEYMAP   =defkeymap.o
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test13-pre3 woes

2000-12-17 Thread J Sloan

Similar problem here - with CONFIG_DRM_TDFX=m
I have not gotten a tdfx.o module complied since the
start of the test13-pre series...

So no quake 3 arena unless I want to play at < 1 fps...

:(

jjs

Albert Cranford wrote:

> With CONFIG_DRM_R128=m
> we fail to produce module linux/drivers/char/drm/r128.o

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



Re: Monitoring filesystems / blockdevice for errors

2000-12-17 Thread Peter Samuelson


  [Mark Hahn]
> > reinventing /proc/kmsg and klogd would be tre gross.

[Lars Marowsky-Bree]
> Well, only one process can read kmsg and get notified about new
> messages at any time, so that makes the monitoring depend on
> klogd/syslogd working, which given a write error by syslog might not
> be the case...

So rewrite klogd to do something much simpler for serious errors (yes
they will be tagged as such) before trying to pass them on to syslogd.
Or does it already do this?  It's a userspace problem.

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: APM/DPMS lockup on Dell 3800

2000-12-17 Thread David Feuer

>

By the way, I now checked the syslog, and I see that the last cron message
was logged about an hour before I reset the system.  So it looks like a total
lockup.


BTW, what does it mean when this gets logged?

Dec 17 19:01:09 localhost kernel: eth0: Resetting the Tx ring pointer.
Dec 17 19:01:09 localhost kernel: eth0: Tx Ring full, refusing to send
buffer.


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



APM/DPMS lockup on Dell 3800

2000-12-17 Thread David Feuer

I get this problem both in Linux and Windows, so I won't
rule out hardware/bios bugs, but I find that often when my
monitor (backlight) gets turned off automatically after a
long period of non-use, the computer freezes up.  I think it
only happens when I've left it that way for a long time,
though.  If I move the mouse immediately after the screen is
blacked, I have no trouble, but if I leave it for a long
time, when I get back the monitor won't unblack,
ctrl-alt-backspace does nothing, ctrl-alt-delete does
nothing,  Fn-Suspend, Fn-A don't do anything, and the
capslock and numlock keys don't do anything either.  I
haven't tried reaching the machine from outside yet, but I
will if someone wants.  Possibly useful note: when the
computer is in this state and I remove the (PCMCIA) network
card and re-insert it, it does not get reset.  This could
indicate a complete lockup.

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



Re: test13-pre3

2000-12-17 Thread Albert Cranford

With CONFIG_DRM_R128=m
we fail to produce module linux/drivers/char/drm/r128.o
Any thoughts.
Albert

Linus Torvalds wrote:
> 
> The most noticeable part of this is that the run_task_queue fix should
> cure the lockup that some people have seen.
> 
> The shmfs cleanup should be unnoticeable except to users who use SAP with
> huge shared memory segments, where Christoph Rohlands work not only
> makes the code much more readable, it should also make it dependable..
> 
> Linus
> 
> 
> 
>  - pre3:
>- Christian Jullien: smc9194: proper dev_kfree_skb_irq
>- Cort Dougan: new-style PowerPC Makefiles
>- Andrew Morton, Petr Vandrovec: fix run_task_queue
>- Christoph Rohland: shmfs for shared memory handling
> 

-- 
Albert Cranford Deerfield Beach FL USA
[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] 2.4.0test13-pre3 apm.o unresolved symbols

2000-12-17 Thread Barry K. Nathan

(Linus Torvalds added to the cc list because there's now a patch to fix
the problem.)

Alan Cox wrote:
> pm.o should be listed as a symbol exporting object in kernel/Makefile

Ok, here's a patch that does this. Tested for both the in-kernel and
module cases.

-Barry K. Nathan <[EMAIL PROTECTED]>

diff -ruN linux-2.4.0test13pre3/kernel/Makefile 
linux-2.4.0test13pre3bkn/kernel/Makefile
--- linux-2.4.0test13pre3/kernel/Makefile   Sun Dec 17 14:17:47 2000
+++ linux-2.4.0test13pre3bkn/kernel/MakefileSun Dec 17 17:55:11 2000
@@ -9,7 +9,7 @@
 
 O_TARGET := kernel.o
 
-export-objs = signal.o sys.o kmod.o context.o ksyms.o
+export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o
 
 obj-y = sched.o dma.o fork.o exec_domain.o panic.o printk.o \
module.o exit.o itimer.o info.o time.o softirq.o resource.o \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [OT] Re: Linus's include file strategy redux

2000-12-17 Thread Peter Samuelson


[[EMAIL PROTECTED]]
> One last question: WHY is the kernel's top-level Makefile handling
> this symlink?

Where do you think it should be handled?  'make modules_install' seems
like the most logical place, to me.

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: set_rtc_mmss: can't update from 0 to 59

2000-12-17 Thread Matthew Dharm

On Sun, Dec 17, 2000 at 09:54:18PM +0100, [EMAIL PROTECTED] wrote:
> What architecture?

i386

> What kernel version?

2.4.0-test13-pre2, but this has been happening for a while.

> Are you in fact running xntpd?

Yes.

> > According to the notes in the code, this should work if my RTC
> > is less than 15 minutes off... which I can guarantee it is.
> 
> Well, since you looked at the source:
> For some randomly chosen kernel version and architecture it does
> 
> if (abs(real_minutes - cmos_minutes) < 30) {
>   update_cmos()
>   } else {
>   printk("set_rtc_mmss: can't update from %d to %d\n",
>  cmos_minutes, real_minutes);
>   }
> 
> so if your cmos time is 0.001 sec ahead of your system time
> then around the hour you'll see
>   set_rtc_mmss: can't update from 0 to 59

Ahh... I think I see.  While the math says "if the diference between the
real time and the cmos time is less than 30 min", it doesn't recognize that
the time difference between 2:59 and 3:00 is only 1 min.

Hrm.. the logic to get this right is always the type of thing that gets
me... that's why I usually calculate things the UNIX way -- seconds since
an epoch.

> Of course, messing with the cmos clock at all was a rather bad idea,
> but that is a different discussion.

True enough...  but, the question is, how do we fix this?  Make the logic
more buff?  Or change the algorithm to use something like minutes since the
epoch?

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

We can customize our colonels.
-- Tux
User Friendly, 12/1/1998

 PGP signature


Re: test12 final, test13-pre3 freezing system

2000-12-17 Thread Mohammad A. Haque

known problem with netfilter. I think someone is working on it.

Robert Lynch wrote:
> 
> I find that running these kernels (because of a netfilter modules
> compile error, didn't try test13-pre1 or 2) in X my entire system
> freezes, requiring a hard reboot.  With test12 final, suddenly
> the screen streaked, then froze.
> 
> No oops, just the freeze.

-- 

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



unresolved symbols pm_*register ad1848.o

2000-12-17 Thread khromy

2.4.0-test13-pre3 unresolved symbols:

modprobe ad1848
/lib/modules/2.4.0-test13-pre3/kernel/drivers/sound/ad1848.o: unresolved symbol 
pm_unregister_Reccd1e64
/lib/modules/2.4.0-test13-pre3/kernel/drivers/sound/ad1848.o: unresolved symbol 
pm_register_R8dbab11c
/lib/modules/2.4.0-test13-pre3/kernel/drivers/sound/ad1848.o: insmod 
/lib/modules/2.4.0-test13-pre3/kernel/drivers/sound/ad1848.o failed
-- 
L1: khromy  ;khromy(at)lnuxlab.net
-
To unsubscribe from this list: send 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 final, test13-pre3 freezing system

2000-12-17 Thread Robert Lynch

I find that running these kernels (because of a netfilter modules
compile error, didn't try test13-pre1 or 2) in X my entire system
freezes, requiring a hard reboot.  With test12 final, suddenly
the screen streaked, then froze.

No oops, just the freeze.

Been a while (when I used to run Windoze) since I saw a frozen
screen complete with frozen mouse hour-glass. :)

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



Re: aic7xxx

2000-12-17 Thread Douglas Gilbert

Mohammad A. Haque wrote:
>
> Weird. The modules just give me unresolved symbol errors instead of the
> loop.
> 
> Mathias Wiklander wrote:
> > 
> > Sorry I've forgot that. It is 2.4.0-test12
> >

There was a SCSI Makefile bug in test12 that caused
those unresoved symbols. This patch from Bob Tracy
fixes it.

Doug Gilbert

--- linux/drivers/scsi/Makefile Tue Dec 12 10:49:32 2000
+++ linux/drivers/scsi/Makefile.t12bt   Tue Dec 12 22:46:27 2000
@@ -30,7 +30,7 @@
 CFLAGS_gdth.o= # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ -DGDTH_STATISTICS
 CFLAGS_seagate.o =   -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
 
-obj-$(CONFIG_SCSI) += scsi_mod.o
+obj-$(CONFIG_SCSI) += scsi_mod.o scsi_syms.o
 
 obj-$(CONFIG_A4000T_SCSI)  += amiga7xx.o   53c7xx.o
 obj-$(CONFIG_A4091_SCSI)   += amiga7xx.o   53c7xx.o
@@ -122,8 +122,7 @@
 scsi_mod-objs  := scsi.o hosts.o scsi_ioctl.o constants.o \
scsicam.o scsi_proc.o scsi_error.o \
scsi_obsolete.o scsi_queue.o scsi_lib.o \
-   scsi_merge.o scsi_dma.o scsi_scan.o \
-   scsi_syms.o
+   scsi_merge.o scsi_dma.o scsi_scan.o
 
 sr_mod-objs:= sr.o sr_ioctl.o sr_vendor.o
 initio-objs:= ini9100u.o i91uscsi.o

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



Re: random.c patch

2000-12-17 Thread Sandy Harris

Karel Kulhavy wrote:
> 
> There are several places where the rotation yields garbage according to ANSI
> C definition when called with 0 bit position argument.
> 
> diff -Pur linux_reference/drivers/char/random.c linux/drivers/char/random.c
> --- linux_reference/drivers/char/random.c   Wed Jul 19 00:58:13 2000
> +++ linux/drivers/char/random.c Sun Dec 17 22:42:59 2000
> @@ -411,7 +411,7 @@
>  #if (!defined (__i386__))
>  extern inline __u32 rotate_left(int i, __u32 word)
>  {
> -   return (word << i) | (word >> (32 - i));
> +   return (word << i) | (word >> ((-i)&31));
> 
If the calling code guarantees 0 < i < 32, then the patch is unnecessary.
In the kernel I have to hand (2.2.6), grepping gives:

r->input_rotate = j & 31 ;

and then both calls to the function use r->input_rotate as the first argument,
so the guarantee from higher level code seems to be 0 <= i < 32, in which case
your patch seems needed.

On the other hand, why not put the &= inside the function with something
like:

 extern inline __u32 rotate_left(int i, __u32 word)
{
switch( i &= 31 )   { /* cheap version of i %= 32 */
case 0 :
return word ;
default :
return (word << i) | (word >> (32 - i)) ;
}

or some faster alternative along the lines of:

{
i &= 31 ;
return( i ? ((word << i) | (word >> (32 - i))) : word ) ;

This works right for any i. Yours fails for i >= 32 unless you make it:

   return (word << (i&31)) | (word >> ((-i)&31));

Whichever way is fastest is fine, but I'd advocate doing the range
manipulation inside the function in any case. Why trust the caller?
If the code is maintained or modified, you're almost guaranteed to
be called with bad argumantes in some version.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [lkml]Re: VM problems still in 2.2.18

2000-12-17 Thread Mark Symonds



- Original Message - 
From: "Alan Cox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 2:38 PM
Subject: Re: [lkml]Re: VM problems still in 2.2.18


> 
> I think Andrea just earned his official God status ;)

Just wanted to quickly report that after applying
Andreas patch, the problem has been fixed here as
well.  I've got two machines here that were previously
unable to stay up more than a day, been pounding on 
them since Friday without any problems.  

Great!  :)

--
Mark

grep me no patterns and I'll tell you no lines.


-
To unsubscribe from this list: send 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-test13-pre3: Makefile problem in drivers/video

2000-12-17 Thread Mikael Djurfeldt

When trying to build video.o as a module, video.o doesn't get copied
to /lib/modules/* during installation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



linux-2.4.0-test13-pre3: Makefile problem in ipv4/netfilter

2000-12-17 Thread Mikael Djurfeldt

When trying to compile linux-2.4.0-test13-pre3 with the following
.config:


 kernel configuration


I got the following error message:

--
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext 
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o 
ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o 
drivers/net/net.o drivers/media/media.o  drivers/char/agp/agp.o drivers/char/drm/drm.o 
drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o 
drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o 
drivers/video/video.o drivers/usb/usbdrv.o \
net/network.o \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a 
/usr/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
net/network.o: In function `ftp_nat_expected':
net/network.o(.text+0x30763): undefined reference to `ip_nat_setup_info'
net/network.o: In function `delete_sack':
net/network.o(.text+0x30b40): undefined reference to `ip_nat_cheat_check'
net/network.o: In function `help':
net/network.o(.text+0x30e3f): undefined reference to `ip_nat_cheat_check'
net/network.o(.text+0x30e4f): undefined reference to `ip_nat_cheat_check'
net/network.o: In function `init':
net/network.o(.text.init+0x114f): undefined reference to `ip_nat_expect_register'
net/network.o(.text.init+0x1162): undefined reference to `ip_nat_helper_register'
net/network.o(.text.init+0x1175): undefined reference to `ip_nat_expect_unregister'
make: *** [vmlinux] Error 1
--

The reason seems to be a dependency problem in

  net/ipv4/netfilter/Makefile

The following patch happens to fix it, but I have no clue as to
whether the fix makes sense:

linnaeus:/usr/src/linux> diff -u net/ipv4/netfilter/Makefile{~,}
--- net/ipv4/netfilter/Makefile~Sun Dec 17 18:26:32 2000
+++ net/ipv4/netfilter/Makefile Sun Dec 17 19:37:32 2000
@@ -38,12 +38,12 @@
 obj-$(CONFIG_IP_NF_FTP) += ip_nat_ftp.o
 
 # generic IP tables 
-obj-$(CONFIG_IP_NF_IPTABLES) += ip_tables.o
+obj-$(CONFIG_IP_NF_IPTABLES) += ip_tables.o $(iptable_nat-objs)
 
 # the three instances of ip_tables
 obj-$(CONFIG_IP_NF_FILTER) += iptable_filter.o
 obj-$(CONFIG_IP_NF_MANGLE) += iptable_mangle.o
-obj-$(CONFIG_IP_NF_NAT) += iptable_nat.o
+obj-$(CONFIG_IP_NF_NAT) += iptable_nat.o $(ip_nf_nat-objs)
 
 # matches
 obj-$(CONFIG_IP_NF_MATCH_LIMIT) += ipt_limit.o



Re: PROBLEM : Networking stops working with kernel 2.4.0-test11

2000-12-17 Thread Jorge Nerin

Zanetti Arnaud wrote:
> 
> Summary
> After an undetermined amount of download, eth0 just stop
> receiving/transmitting bytes
> 
> Description:
> After working perfectly for an undetermined time /  volume of download,
> eth0 just stop working (i.e. : it won'n receive/transmit anymore bytes).
> I just can see the 'drop' field in /proc/net/dev increasing, all other
> fields just remaining the same.
> I tried to bring eth0 down and up again and it doesn't work.
> Ad it happens only during intensive download (>100Ko/s) I suspected a
> security mecanism could have seen it as an attack, but I couldn't figure
> out what mecanism it could have been. Comparing /proc/sys/net both in
> working and stopped situation with a
> more $(find net/ -type f) >~/sys.net.ok
> and a
> more $(find net/ -type f) >~/sys.net.stopped
> I found strictly no differences (i.e. the 'diff' command found no
> differences)
> 
> Keywords:
> networking
> 
> Kernel version:
> Linux version 2.4.0-test11-zatto ([EMAIL PROTECTED]) (gcc
> version egcs-2.91.66.1 19990314/Linux (egcs-1.1.2 release)) #3 SMP mer
> déc 6 15:40:04 CET 2000
> 
> -- Versions installed: (if some fields are empty or look
> -- unusual then possibly you have very old versions)
> Linux zatto.resI.insa-lyon.fr 2.4.0-test11-zatto #3 SMP mer déc 6
> 15:40:04 CET 2000 i686 unknown
> Kernel modules 2.3.18
> Gnu C  2.95.3
> Gnu Make   3.79.1
> Binutils   2.10.0.24
> Linux C Library2.1.3
> Dynamic linker ldd (GNU libc) 2.1.3
> Procps 2.0.7
> Mount  2.10o
> Net-tools  1.57
> Console-tools  0.2.3
> Sh-utils   2.0
> Modules Loaded ne2k-pci 8390 nls_iso8859-1 nls_cp437 loop tuner
> bttv videodev sr_mod cdrom
> 
> CPU:
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model  : 6
> model name : Celeron (Mendocino)
> stepping : 5
> cpu MHz  : 400.000918
> cache size : 128 KB
> fdiv_bug : no
> hlt_bug  : no
> f00f_bug : no
> coma_bug : no
> fpu  : yes
> fpu_exception : yes
> cpuid level : 2
> wp  : yes
> features : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 mmx fxsr
> bogomips : 799.54
> 
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model  : 6
> model name : Celeron (Mendocino)
> stepping : 5
> cpu MHz  : 400.000918
> cache size : 128 KB
> fdiv_bug : no
> hlt_bug  : no
> f00f_bug : no
> coma_bug : no
> fpu  : yes
> fpu_exception : yes
> cpuid level : 2
> wp  : yes
> features : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 mmx fxsr
> bogomips : 801.18
> 
> Modules loaded:
> ne2k-pci4896   1
> 83906784   0 [ne2k-pci]
> nls_iso8859-1   2848   1 (autoclean)
> nls_cp437   4368   1 (autoclean)
> loop7744   0 (unused)
> tuner   3264   1 (autoclean)
> bttv   57584   0 (unused)
> videodev4832   2 [bttv]
> sr_mod 12160   2
> cdrom  27648   0 [sr_mod]
> 
> /proc/ioports
> -001f : dma1
> 0020-003f : pic1
> 0040-005f : timer
> 0060-006f : keyboard
> 0080-008f : dma page reg
> 00a0-00bf : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0170-0177 : ide1
> 01f0-01f7 : ide0
> 02f8-02ff : serial(auto)
> 0376-0376 : ide1
> 03c0-03df : vga+
> 03f6-03f6 : ide0
> 03f8-03ff : serial(auto)
> 0cf8-0cff : PCI conf1
> 4000-403f : Intel Corporation 82371AB PIIX4 ACPI
>   4000-4003 : acpi
>   4004-4005 : acpi
>   4008-400b : acpi
>   400c-400f : acpi
> 5000-501f : Intel Corporation 82371AB PIIX4 ACPI
> c000-c01f : Intel Corporation 82371AB PIIX4 USB
> c400-c43f : Ensoniq 5880 AudioPCI
>   c400-c43f : es1371
> c800-c81f : Realtek Semiconductor Co., Ltd. RTL-8029(AS)
>   c800-c81f : ne2k-pci
> cc00-ccff : 3Dfx Interactive, Inc. Voodoo 3
> d000-d007 : Triones Technologies, Inc. HPT366
> d400-d403 : Triones Technologies, Inc. HPT366
> d800-d8ff : Triones Technologies, Inc. HPT366
>   d800-d807 : ide2
>   d810-d8ff : HPT366
> dc00-dc07 : Triones Technologies, Inc. HPT366 (#2)
> e000-e003 : Triones Technologies, Inc. HPT366 (#2)
> e400-e4ff : Triones Technologies, Inc. HPT366 (#2)
>   e400-e407 : ide3
>   e410-e4ff : HPT366
> f000-f00f : Intel Corporation 82371AB PIIX4 IDE
>   f000-f007 : ide0
>   f008-f00f : ide1
> 
> /proc/iomem
> 
> -0009efff : System RAM
> 000a-000b : Video RAM area
> 000c-000c7fff : Video ROM
> 000f-000f : System ROM
> 0010-13ff : System RAM
>   0010-0025ad97 : Kernel code
>   0025ad98-00270f9f : Kernel data
> d000-d3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
> d400-d5ff : 3Dfx Interactive, Inc. Voodoo 3
> d600-d7ff : 3Dfx Interactive, Inc. Voodoo 3
> d900-d9000fff : Brooktree Corporation Bt848 TV with DMA push
>   d900-d9000fff : bttv
> 
> lspci -vvv
> 
> 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
> (rev 03)
>  

Re: [BUG] 2.4.0test13-pre3 apm.o unresolved symbols

2000-12-17 Thread Alan Cox

> /lib/modules/2.4.0-test13-pre3/kernel/arch/i386/kernel/apm.o: unresolved
> symbol pm_active
> 
> This is my first time building APM as a module, so I don't know when the
> error was first introduced...

13pre in the Makefile redo

pm.o should be listed as a symbol exporting object in kernel/Makefile

-
To unsubscribe from this list: send the 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-test13-pre3 and ext2 as module

2000-12-17 Thread Martin Josefsson

Hi

Linus, will you please consider this patch by Jeff Raubitschek for the
next pre-patch? It fixes two unresolved symbols in ext2.o when building
ext2 as a module.

--- linux-2.4.0-test12/kernel/ksyms.c   Tue Dec 12 11:19:17 2000
+++ linux/kernel/ksyms.cTue Dec 12 11:18:57 2000
@@ -252,6 +252,8 @@
 EXPORT_SYMBOL(lock_may_read);
 EXPORT_SYMBOL(lock_may_write);
 EXPORT_SYMBOL(dcache_readdir);
+EXPORT_SYMBOL(buffer_insert_inode_queue);
+EXPORT_SYMBOL(fsync_inode_buffers);
 
 /* for stackable file systems (lofs, wrapfs, cryptfs, etc.) */
 EXPORT_SYMBOL(default_llseek);


/Martin

Linux hackers are funny people: They count the time in patchlevels.

On Mon, 18 Dec 2000, Martin Josefsson wrote:

> On Mon, 18 Dec 2000, Martin Josefsson wrote:
> 
> > On Mon, 18 Dec 2000, Alan Cox wrote:
> > 
> > > > I compiled test13-pre3 a few minutes ago and when running
> > > > make modules_install I got this:
> > > > 
> > > > depmod: *** Unresolved symbols in 
>/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
> > > > depmod: buffer_insert_inode_queue
> > > > depmod: fsync_inode_buffers
> > > 
> > > Jeff Raubitschek posted a patch for this on the 12th. 
> > 
> > Thanks for the quick response, testing the patch now.
> > If it works I'll ask Linux to include it in the next pre-patch
> 
> Gaah, why do I write Linux instead of Linus... maybe I should get some
> sleep..
> 
> /Martin
> 
> 

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



[BUG] 2.4.0test13-pre3 apm.o unresolved symbols

2000-12-17 Thread Barry K. Nathan

When I try "modprobe apm" I get these errors:

/lib/modules/2.4.0-test13-pre3/kernel/arch/i386/kernel/apm.o: unresolved
symbol pm_send_all
/lib/modules/2.4.0-test13-pre3/kernel/arch/i386/kernel/apm.o: unresolved
symbol pm_active

This is my first time building APM as a module, so I don't know when the
error was first introduced...

-Barry K. Nathan <[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-test13-pre3 and ext2 as module

2000-12-17 Thread Martin Josefsson

On Mon, 18 Dec 2000, Martin Josefsson wrote:

> On Mon, 18 Dec 2000, Alan Cox wrote:
> 
> > > I compiled test13-pre3 a few minutes ago and when running
> > > make modules_install I got this:
> > > 
> > > depmod: *** Unresolved symbols in 
>/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
> > > depmod: buffer_insert_inode_queue
> > > depmod: fsync_inode_buffers
> > 
> > Jeff Raubitschek posted a patch for this on the 12th. 
> 
> Thanks for the quick response, testing the patch now.
> If it works I'll ask Linux to include it in the next pre-patch

Gaah, why do I write Linux instead of Linus... maybe I should get some
sleep..

/Martin

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



RE: /dev/random: really secure?

2000-12-17 Thread David Schwartz


> I noticed peculiarities in the behaviour of the delta-delta-3 system for
> entropy estimation in the random.c code./ When I hold right alt
> or control, I
> get about 8 bits of entropy per repeat fro the /dev/random which is
> overestimated. I think the real entropy is 0 bits because it is absolutely
> deterministic when the interrupt comes. Am I right or is there any hidden
> magic source of entropy in this case?

There are hidden sources of entropy. One is clock skew between the keyboard
processor's clock, the keyboard controller's clock, and the CPU clock
generator's PLL. Another is data motion between the CPU cache and main
memory as various interupt service routines are executed interspersed with
other system activity.

> Right shift, left alt, ctrl and shift make 4 bits per repeat. Is greater
> randomness being expected from the keys that return 8 bits?

The code does its best to estimate how much actual entropy it is gathering.

> When I have a server where n blobk read, keyboard and mouse events occur
> (everything is cached within huge amount of semiconductor RAM),
> the /dev/random
> depends solely on the network packets. These can be manipulated and their
> leading edge precisely sniffed. I think here exists a severe risk of
> compromise. Am I right?

Nope. There is no way to sniff their leading edge accurate to a billionth
of a second. If you have a 1Ghz Pentium 3, that's the accuracy you'd need.
And you'd need to know that relative to the CPU clock, which comes from an
uncompensated quartz crystal oscillator fed into a noisy multiplier. Top
that off with variations in the oscillator frequency due to microscopic zone
temperature variations.

There is no known method to predict these numbers.

DS

-
To unsubscribe from this list: send the 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-test13-pre3 and ext2 as module

2000-12-17 Thread Martin Josefsson

On Mon, 18 Dec 2000, Alan Cox wrote:

> > I compiled test13-pre3 a few minutes ago and when running
> > make modules_install I got this:
> > 
> > depmod: *** Unresolved symbols in 
>/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
> > depmod: buffer_insert_inode_queue
> > depmod: fsync_inode_buffers
> 
> Jeff Raubitschek posted a patch for this on the 12th. 

Thanks for the quick response, testing the patch now.
If it works I'll ask Linux to include it in the next pre-patch

/Martin

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



Re: 2.4.0-test13-pre3 and ext2 as module

2000-12-17 Thread Alan Cox

> I compiled test13-pre3 a few minutes ago and when running
> make modules_install I got this:
> 
> depmod: *** Unresolved symbols in 
>/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
> depmod: buffer_insert_inode_queue
> depmod: fsync_inode_buffers

Jeff Raubitschek posted a patch for this on the 12th. 
-
To unsubscribe from this list: send 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-test13-pre3 and ext2 as module

2000-12-17 Thread Martin Josefsson

Hi

I compiled test13-pre3 a few minutes ago and when running
make modules_install I got this:

depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
depmod: buffer_insert_inode_queue
depmod: fsync_inode_buffers

As you may have noticed I have ext2 as a module, I have reiserfs as main
filesystem here on this system. This is not a critical error to me.

I havn't tried to compile ext2 into kernel.

.config is availiable if anyone wants it.

/Martin

Linux hackers are funny people: They count the time in patchlevels.

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



PROBLEM : Networking stops working with kernel 2.4.0-test11

2000-12-17 Thread Zanetti Arnaud

Summary
After an undetermined amount of download, eth0 just stop
receiving/transmitting bytes

Description:
After working perfectly for an undetermined time /  volume of download,
eth0 just stop working (i.e. : it won'n receive/transmit anymore bytes).
I just can see the 'drop' field in /proc/net/dev increasing, all other
fields just remaining the same.
I tried to bring eth0 down and up again and it doesn't work.
Ad it happens only during intensive download (>100Ko/s) I suspected a
security mecanism could have seen it as an attack, but I couldn't figure
out what mecanism it could have been. Comparing /proc/sys/net both in
working and stopped situation with a
more $(find net/ -type f) >~/sys.net.ok
and a
more $(find net/ -type f) >~/sys.net.stopped
I found strictly no differences (i.e. the 'diff' command found no
differences)

Keywords:
networking

Kernel version:
Linux version 2.4.0-test11-zatto ([EMAIL PROTECTED]) (gcc
version egcs-2.91.66.1 19990314/Linux (egcs-1.1.2 release)) #3 SMP mer
déc 6 15:40:04 CET 2000


-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux zatto.resI.insa-lyon.fr 2.4.0-test11-zatto #3 SMP mer déc 6
15:40:04 CET 2000 i686 unknown
Kernel modules 2.3.18
Gnu C  2.95.3
Gnu Make   3.79.1
Binutils   2.10.0.24
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.7
Mount  2.10o
Net-tools  1.57
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded ne2k-pci 8390 nls_iso8859-1 nls_cp437 loop tuner
bttv videodev sr_mod cdrom


CPU:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model  : 6
model name : Celeron (Mendocino)
stepping : 5
cpu MHz  : 400.000918
cache size : 128 KB
fdiv_bug : no
hlt_bug  : no
f00f_bug : no
coma_bug : no
fpu  : yes
fpu_exception : yes
cpuid level : 2
wp  : yes
features : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr
bogomips : 799.54

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model  : 6
model name : Celeron (Mendocino)
stepping : 5
cpu MHz  : 400.000918
cache size : 128 KB
fdiv_bug : no
hlt_bug  : no
f00f_bug : no
coma_bug : no
fpu  : yes
fpu_exception : yes
cpuid level : 2
wp  : yes
features : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr
bogomips : 801.18

Modules loaded:
ne2k-pci4896   1
83906784   0 [ne2k-pci]
nls_iso8859-1   2848   1 (autoclean)
nls_cp437   4368   1 (autoclean)
loop7744   0 (unused)
tuner   3264   1 (autoclean)
bttv   57584   0 (unused)
videodev4832   2 [bttv]
sr_mod 12160   2
cdrom  27648   0 [sr_mod]

/proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-403f : Intel Corporation 82371AB PIIX4 ACPI
  4000-4003 : acpi
  4004-4005 : acpi
  4008-400b : acpi
  400c-400f : acpi
5000-501f : Intel Corporation 82371AB PIIX4 ACPI
c000-c01f : Intel Corporation 82371AB PIIX4 USB
c400-c43f : Ensoniq 5880 AudioPCI
  c400-c43f : es1371
c800-c81f : Realtek Semiconductor Co., Ltd. RTL-8029(AS)
  c800-c81f : ne2k-pci
cc00-ccff : 3Dfx Interactive, Inc. Voodoo 3
d000-d007 : Triones Technologies, Inc. HPT366
d400-d403 : Triones Technologies, Inc. HPT366
d800-d8ff : Triones Technologies, Inc. HPT366
  d800-d807 : ide2
  d810-d8ff : HPT366
dc00-dc07 : Triones Technologies, Inc. HPT366 (#2)
e000-e003 : Triones Technologies, Inc. HPT366 (#2)
e400-e4ff : Triones Technologies, Inc. HPT366 (#2)
  e400-e407 : ide3
  e410-e4ff : HPT366
f000-f00f : Intel Corporation 82371AB PIIX4 IDE
  f000-f007 : ide0
  f008-f00f : ide1

/proc/iomem

-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-13ff : System RAM
  0010-0025ad97 : Kernel code
  0025ad98-00270f9f : Kernel data
d000-d3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
d400-d5ff : 3Dfx Interactive, Inc. Voodoo 3
d600-d7ff : 3Dfx Interactive, Inc. Voodoo 3
d900-d9000fff : Brooktree Corporation Bt848 TV with DMA push
  d900-d9000fff : bttv

lspci -vvv

00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
 Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge
(rev 03) (prog-if 00 [Normal decode])
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-

2.2.18 asm-alpha/system.h has a problem

2000-12-17 Thread Daiki Matsuda

Hi, all.

I encounterd the problem that 'cdrdao' is not compilable in 2.2.18 on
Alpha. And I researched a little.
So, then new code added in include/asm-alpha/system.h on 2.2.18 has a
problem in C++. The 'new' may be the reserved word in C++. And I send
its patch.

Regards
Daiki Matsuda


--- linux/include/asm-alpha/system.h.oldSun Dec 17 17:53:28 2000
+++ linux/include/asm-alpha/system.hSun Dec 17 17:54:51 2000
@@ -390,7 +390,7 @@
 #define __HAVE_ARCH_CMPXCHG 1
 
 extern __inline__ unsigned long
-__cmpxchg_u32(volatile int *m, int old, int new)
+__cmpxchg_u32(volatile int *m, int old_val, int new_val)
 {
unsigned long prev, cmp;
 
@@ -409,13 +409,13 @@
"3: br 1b\n"
".previous"
: "="(prev), "="(cmp), "=m"(*m)
-   : "r"((long) old), "r"(new), "m"(*m) : "memory");
+   : "r"((long) old_val), "r"(new_val), "m"(*m) : "memory");
 
return prev;
 }
 
 extern __inline__ unsigned long
-__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
+__cmpxchg_u64(volatile long *m, unsigned long old_val, unsigned long new_val)
 {
unsigned long prev, cmp;
 
@@ -434,7 +434,7 @@
"3: br 1b\n"
".previous"
: "="(prev), "="(cmp), "=m"(*m)
-   : "r"((long) old), "r"(new), "m"(*m) : "memory");
+   : "r"((long) old_val), "r"(new_val), "m"(*m) : "memory");
 
return prev;
 }
@@ -444,16 +444,16 @@
 extern void __cmpxchg_called_with_bad_pointer(void);
 
 static __inline__ unsigned long
-__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
+__cmpxchg(volatile void *ptr, unsigned long old_val, unsigned long new_val, int size)
 {
switch (size) {
case 4:
-   return __cmpxchg_u32(ptr, old, new);
+   return __cmpxchg_u32(ptr, old_val, new_val);
case 8:
-   return __cmpxchg_u64(ptr, old, new);
+   return __cmpxchg_u64(ptr, old_val, new_val);
}
__cmpxchg_called_with_bad_pointer();
-   return old;
+   return old_val;
 }
 
 #define cmpxchg(ptr,o,n)\



linux-2.4.0-test13-pre2 has problems on Alpha

2000-12-17 Thread Daiki Matsuda

Hi, all.

I tested test13-pre2 on Alpha, but it is not compilable. So, I send a
small patch, and in test13-pre3 its problem may not be repaired.

'CONFIG_ALPHA' is used in drivers/pci/Makefile, but it is not defined
in anywhere. So, I added it to arch/alpha/config.in.

I think the point in arch/alpha/math-emu/Makefile small.

Regards
Daiki Matsuda



--- linux/arch/alpha/math-emu/Makefile.old  Sun Dec 17 22:06:10 2000
+++ linux/arch/alpha/math-emu/Makefile  Sun Dec 17 22:04:58 2000
@@ -8,7 +8,7 @@
 # Note 2! The CFLAGS definition is now in the main makefile...
 
 O_TARGET := math-emu.o
-O_OBJS   := math.o qrnnd.o
+obj-y   := math.o qrnnd.o
 CFLAGS += -I. -I$(TOPDIR)/include/math-emu -w
 
 ifeq ($(CONFIG_MATHEMU),m)
--- linux/arch/alpha/config.in.old  Sun Dec 17 22:22:27 2000
+++ linux/arch/alpha/config.in  Sun Dec 17 22:23:38 2000
@@ -24,6 +24,8 @@
 mainmenu_option next_comment
 comment 'General setup'
 
+define_bool CONFIG_ALPHA y
+
 choice 'Alpha system type' \
"GenericCONFIG_ALPHA_GENERIC\
 Alcor/Alpha-XLTCONFIG_ALPHA_ALCOR  \



Signal 11 - revisited

2000-12-17 Thread Rainer Mager

I was wondering if anyone had any new info/suggestions for the Signal 11
problem.

I think I last reported that I had tried 2.4.0test12 w AGPGart and DRM
turned off. This seemed a bit more stable but I did have X crash with
Signall 11 after about 1.5 days.

I'd really appreciate any advice on how to diagnose this.


Thanks,

--Rainer

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



mount and 2.2.18

2000-12-17 Thread Igor Mozetic

After installing the latest 2.2.18 kernel on a Debian 2.2 
box the following keeps appearing in kern.log:

Dec 17 18:33:53 xxx kernel: nfs warning: mount version older than kernel

Is this harmless or do I need the latest mount?
Currently I don't use kNFSv3, user-space v2 is fine.

-Igor Mozetic
-
To unsubscribe from this list: send 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-test12 and pci

2000-12-17 Thread Hexxor

Hello all, I hope I'm posting to the right place for this

I noticed there was a patch to enable the 'pci=autoirq' option, but any
occurance I've found seems to be incomplete or something (it won't apply)
and I'm getting weird irq messages in my logs, searching for the errors
brings up posts from MJ (who wrote the patch, I think)

any help would be appreciated, as I don't know much about what this error
could mean

Dec 16 04:01:55 nanook kernel: Kernel command line: auto BOOT_IMAGE=Linux
ro root=301 BOOT_FILE=/boot/vmlinuz hdc=ide-scsi pci=autoirq
Dec 16 04:01:55 nanook kernel: PCI: Unknown option `autoirq'
Dec 16 04:01:55 nanook kernel: IRQ routing conflict in pirq table! Try 'pci=autoirq'


also, I get this one occasionally:

Dec 14 02:01:24 nanook kernel: spurious 8259A interrupt: IRQ7.

all this started happening after I upgraded to 2.4.0-test12, which was the
same day I put an AMD k6/2 450 cpu in this box, relevant?

TIA

-- 


-Hexxor / Charles D

"Do not take for granted, the powers out there."

GMUd-s:--a--C++ULPLEW++N+o+K-O-
w---M-V-PS+++PEY+PGPt---5--X-R!tvb+DID+Geh--ry+

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



Re: recursive exports && linux nfs

2000-12-17 Thread Pavel Machek

Hi!

> > > 2) using: I can do cd /nfs/fs, but the directoy is always empty, and when I
> > >try to step into a subdirectory I always get "No such file or directory".
> > > 
> > > Thanks a lot for any insights, even if this means "this is not supported"
> > > ;)
> > 
> > This can't be supported, afaict, because nfs handles have limited
> > size.
> 
> Ehrm, did you really read my mail? Most people told me something like
> "recursive exports are not supported" (actually, they are and they work),
> and it seems nobody really read what I wrote :(

They do not work too well. They break guarantee that handles are
persistent across reboots. Recursive exports are huge kludge. They
have to be.

[Sorry, I did not read your mail too carefully]

> My problem is that autofs doesn't work. Example:
> 
> / reiserfs
> /fs   autofs
> /fs/big   ext2
> 
> When I exportfs /, /fs AND /fs/big then I can mount /fs on another box,
> but it is always empty, even if something (e.g. /fs/big) is mounted and
> can be accessed fine the whole time. Automounting doesn't work, either, of
> course.
> 
> Another (less grave) problem is that exportfs (and/or rpc.nfsd) require
> network access and access to the volume, so they a) mount all automounted
> directories (VERY expensive) and require network access (making all
> clients NOT survive a reboot).
> 

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



test13-pre3

2000-12-17 Thread Linus Torvalds


The most noticeable part of this is that the run_task_queue fix should
cure the lockup that some people have seen.

The shmfs cleanup should be unnoticeable except to users who use SAP with
huge shared memory segments, where Christoph Rohlands work not only
makes the code much more readable, it should also make it dependable..

Linus



 - pre3:
   - Christian Jullien: smc9194: proper dev_kfree_skb_irq
   - Cort Dougan: new-style PowerPC Makefiles
   - Andrew Morton, Petr Vandrovec: fix run_task_queue
   - Christoph Rohland: shmfs for shared memory handling

 - pre2:
   - Kai Germaschewski: ISDN update (including Makefiles)
   - Jens Axboe: cdrom updates
   - Petr Vandrovec; Matrox G450 support
   - Bill Nottingham: fix FAT32 filesystems on 64-bit platforms
   - David Miller: sparc (and other) Makefile fixup
   - Andrea Arkangeli: alpha SMP TLB context fix (and cleanups)
   - Niels Kristian Bech Jensen: checkconfig, USB warnings
   - Andrew Grover: large ACPI update

 - pre1:
   - me: drop support for old-style Makefiles entirely. Big.
   - me: check b_end_io at the IO submission path
   - me: fix "ptep_mkdirty()" (so that swapoff() works correctly)
   - fix fault case in copy_from_user() with a constant size, where
 ((size & 3) == 3)


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



/dev/random: really secure?

2000-12-17 Thread Karel Kulhavy

I noticed peculiarities in the behaviour of the delta-delta-3 system for
entropy estimation in the random.c code./ When I hold right alt or control, I
get about 8 bits of entropy per repeat fro the /dev/random which is
overestimated. I think the real entropy is 0 bits because it is absolutely
deterministic when the interrupt comes. Am I right or is there any hidden
magic source of entropy in this case?

Right shift, left alt, ctrl and shift make 4 bits per repeat. Is greater
randomness being expected from the keys that return 8 bits?

When I have a server where n blobk read, keyboard and mouse events occur
(everything is cached within huge amount of semiconductor RAM), the /dev/random
depends solely on the network packets. These can be manipulated and their
leading edge precisely sniffed. I think here exists a severe risk of
compromise. Am I right?

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



random.c patch

2000-12-17 Thread Karel Kulhavy

There are several places where the rotation yields garbage according to ANSI
C definition when called with 0 bit position argument.

diff -Pur linux_reference/drivers/char/random.c linux/drivers/char/random.c
--- linux_reference/drivers/char/random.c   Wed Jul 19 00:58:13 2000
+++ linux/drivers/char/random.c Sun Dec 17 22:42:59 2000
@@ -411,7 +411,7 @@
 #if (!defined (__i386__))
 extern inline __u32 rotate_left(int i, __u32 word)
 {
-   return (word << i) | (word >> (32 - i));
+   return (word << i) | (word >> ((-i)&31));

 }
 #else
@@ -857,7 +857,7 @@
 #define K3  0x8F1BBCDCL/* Rounds 40-59: sqrt(5) * 2^30 */
 #define K4  0xCA62C1D6L/* Rounds 60-79: sqrt(10) * 2^30 */
 
-#define ROTL(n,X)  ( ( ( X ) << n ) | ( ( X ) >> ( 32 - n ) ) )
+#define ROTL(n,X)  ( ( ( X ) << n ) | ( ( X ) >> ( (- n)&31 ) ) )
 
 #define subRound(a, b, c, d, e, f, k, data) \
 ( e += ROTL( 5, a ) + f( b, c, d ) + k + data, b = ROTL( 30, b ) )
@@ -1087,7 +1087,7 @@
 
 /* This is the central step in the MD5 algorithm. */
 #define MD5STEP(f, w, x, y, z, data, s) \
-   ( w += f(x, y, z) + data,  w = w<>(32-s),  w += x )
+   ( w += f(x, y, z) + data,  w = w<>((-s)&31),  w += x )
 
 /*
  * The core of the MD5 algorithm, this alters an existing MD5 hash to
@@ -1883,7 +1883,7 @@
  * Rotation is separate from addition to prevent recomputation
  */
 #define ROUND(f, a, b, c, d, x, s) \
-   (a += f(b, c, d) + x, a = (a << s) | (a >> (32-s)))
+   (a += f(b, c, d) + x, a = (a << s) | (a >> ((-s)&31)))
 #define K1 0
 #define K2 013240474631UL
 #define K3 015666365641UL

 Clock

-
To unsubscribe from this list: send the 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: innd bug came back?

2000-12-17 Thread Henrik Størner

In <[EMAIL PROTECTED]> Alexander Viro 
<[EMAIL PROTECTED]> writes:

>On Sun, 17 Dec 2000, Jorg de Jong wrote:

>> > >On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote:
>> > >
>> > >> Just to add a "me too" on this. I didn't report when I saw it last week

>> I'd like to second that. ME TOO !
>> Since I switched to 2.4.0.test12 I again have the innd bug.
>> ( well at least the same symptoms !)

>Guys, what blocksize are you using?

I am using Reiserfs, and I hear it has some problems with the changes
introduced in pre12. So I will report back once the Reiserfs guys get 
this settled.
-- 
Henrik Storner  | "Crackers thrive on code secrecy. Cockcroaches breed 
<[EMAIL PROTECTED]> |  in the dark. It's time to let the sunlight in."
|  
|  Eric S. Raymond, re. the Frontpage backdoor
-
To unsubscribe from this list: send the 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: innd bug came back?

2000-12-17 Thread Alexander Viro



On Sun, 17 Dec 2000, Jorg de Jong wrote:

> > >On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote:
> > >
> > >> Just to add a "me too" on this. I didn't report when I saw it last week,
> 
> I'd like to second that. ME TOO !
> Since I switched to 2.4.0.test12 I again have the innd bug.
> ( well at least the same symptoms !)

Guys, what blocksize are you using? BTW, old testcase was
cat >foo.c <
main(argc,argv)
int argc;
char **argv;
{
int fd;
char c=0;
truncate(argv[1], 10);
fd = open(argv[1], 1);
lseek(fd, 16384, 0);
write(fd, , 1);
close(fd);
}
EOF
gcc foo.c
./a.out /tmp/something_old
od -c http://www.tux.org/lkml/



Re: aic7xxx

2000-12-17 Thread Mohammad A. Haque

Weird. The modules just give me unresolved symbol errors instead of the
loop.

Mathias Wiklander wrote:
> 
> Sorry I've forgot that. It is 2.4.0-test12
> 

-- 

=
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] shm cleanup

2000-12-17 Thread Christoph Rohland

Linus Torvalds <[EMAIL PROTECTED]> writes:
> The only comment I have is that as far as I can tell, your shm_writepage()
> has a small bug: if "__get_swap_page()" fails, we can't just drop the
> dirty page in question, so instead of returning -ENOMEM we should really
> return a "1" to tell the VM to keep the page dirty.

Right, here comes the (incremental) patch

Christoph

diff -uNr c/mm/shmem.c c1/mm/shmem.c
--- c/mm/shmem.cSun Dec 17 21:31:46 2000
+++ c1/mm/shmem.c   Sun Dec 17 21:35:08 2000
@@ -210,31 +210,33 @@
 {
int error;
struct shmem_inode_info *info;
-   swp_entry_t *entry;
+   swp_entry_t *entry, swap;
 
info = &((struct inode *)page->mapping->host)->u.shmem_i;
if (info->locked)
return 1;
+   swap = __get_swap_page(2);
+   if (!swap.val)
+   return 1;
+
spin_lock(>lock);
entry = shmem_swp_entry (info, page->index);
if (!entry) /* this had been allocted on page allocation */
BUG();
error = -EAGAIN;
-   if (entry->val)
-   goto out;
-
-   error = -ENOMEM;
-   *entry = __get_swap_page(2);
-   if (!entry->val)
+   if (entry->val) {
+__swap_free(swap, 2);
goto out;
+}
 
+*entry = swap;
error = 0;
/* Remove the from the page cache */
lru_cache_del(page);
remove_inode_page(page);
 
/* Add it to the swap cache */
-   add_to_swap_cache(page,*entry);
+   add_to_swap_cache(page, swap);
page_cache_release(page);
SetPageDirty(page);
info->swapped++;

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

2000-12-17 Thread Christoph Rohland

Hi Linus,

Here is my shm cleanup patch. It survived several days of stress
testing on my 8way.

It is somewhat conservative wrt to locking and the truncate logic
could be optimised for speed. But it is robust and passes all the SYSV
compatibilty tests I remembered.

I had to implement some semantic change to writepage in vmscan.c to be
able to implement SHM_LOCK handling. I actually do not understand how
we can ignore the return code from writepage... If writepage fails we
probably should not simply drop the page?

You do not see the SYSV shared memory segments any more in the mounted
instance and loose the ability to 'rm' them instead of using
ipcrm. Also /proc/sys/kernel/shm{all,mni} are back. Therefore you can
now mount several shm filesystem instances for POSIX shm and when we
implement read and write for the fs we will have a fullblown swapfs
like Solaris' tmpfs.

Greetings
Christoph

diff -uNr 4-13-2/Documentation/Changes c/Documentation/Changes
--- 4-13-2/Documentation/ChangesSun Dec 17 13:00:23 2000
+++ c/Documentation/Changes Sun Dec 17 15:48:40 2000
@@ -115,18 +115,18 @@
 the kernel source tree for all the gory details.
 
 System V shared memory is now implemented via a virtual filesystem.
-You do not have to mount it to use it as long as you can live with the
-default maxima for shared memory and segments.  If you wish to change
-these variables, you have to mount it with the options nr_blocks
-and / or nr_inodes.  POSIX shared memory is also now implemented via a
-virtual filesystem.  If you want to use it, you'll need to mount the
-filesystem.  The recommended mount location is /dev/shm, and adding the
-following line to /etc/fstab should take care of things:
+You do not have to mount it to use it. SYSV shared memory limits are
+set via /proc/sys/kernel/shm{max,all,mni}.  You should mount the
+filesystem under /dev/shm to be able to use POSIX shared
+memory. Adding the following line to /etc/fstab should take care of
+things:
 
 none   /dev/shmshm defaults0 0
 
 Remember to create the directory that you intend to mount shm on if
-necessary.
+necessary (The entry is automagically created if you use devfs). You
+can set limits for the number of blocks and inodes used by the
+filesystem with the mount options nr_blocks and nr_inodes.
 
 The Logical Volume Manager (LVM) is now in the kernel.  If you want to
 use this, you'll need to install the necessary LVM toolset.
diff -uNr 4-13-2/drivers/char/mem.c c/drivers/char/mem.c
--- 4-13-2/drivers/char/mem.c   Thu Nov 30 21:46:51 2000
+++ c/drivers/char/mem.cSun Dec 17 13:01:42 2000
@@ -438,7 +438,7 @@
 static int mmap_zero(struct file * file, struct vm_area_struct * vma)
 {
if (vma->vm_flags & VM_SHARED)
-   return map_zero_setup(vma);
+   return shmem_zero_setup(vma);
if (zeromap_page_range(vma->vm_start, vma->vm_end - vma->vm_start, 
vma->vm_page_prot))
return -EAGAIN;
return 0;
diff -uNr 4-13-2/include/linux/fs.h c/include/linux/fs.h
--- 4-13-2/include/linux/fs.h   Sun Dec 17 12:54:01 2000
+++ c/include/linux/fs.hSun Dec 17 16:04:13 2000
@@ -283,6 +283,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -441,6 +442,7 @@
struct ufs_inode_info   ufs_i;
struct efs_inode_info   efs_i;
struct romfs_inode_info romfs_i;
+   struct shmem_inode_info shmem_i;
struct coda_inode_info  coda_i;
struct smb_inode_info   smbfs_i;
struct hfs_inode_info   hfs_i;
@@ -685,6 +687,7 @@
struct affs_sb_info affs_sb;
struct ufs_sb_info  ufs_sb;
struct efs_sb_info  efs_sb;
+   struct shmem_sb_infoshmem_sb;
struct romfs_sb_inforomfs_sb;
struct smb_sb_info  smbfs_sb;
struct hfs_sb_info  hfs_sb;
diff -uNr 4-13-2/include/linux/mm.h c/include/linux/mm.h
--- 4-13-2/include/linux/mm.h   Sun Dec 17 12:54:01 2000
+++ c/include/linux/mm.hSun Dec 17 16:10:34 2000
@@ -129,15 +129,6 @@
 };
 
 /*
- * A swap entry has to fit into a "unsigned long", as
- * the entry is hidden in the "index" field of the
- * swapper address space.
- */
-typedef struct {
-   unsigned long val;
-} swp_entry_t;
-
-/*
  * Try to keep the most commonly accessed fields in single cache lines
  * here (16 bytes or greater).  This ordering should be particularly
  * beneficial on 32-bit processors.
@@ -390,7 +381,10 @@
 
 extern void clear_page_tables(struct mm_struct *, unsigned long, int);
 
-extern int map_zero_setup(struct vm_area_struct *);
+int shmem_swapout(struct page * page, struct file *file);
+struct page * shmem_nopage(struct vm_area_struct * vma, unsigned long address, int 
+no_share);
+struct file *shmem_file_setup(char * 

Re: set_rtc_mmss: can't update from 0 to 59

2000-12-17 Thread Andries . Brouwer

What architecture?
What kernel version?
Are you in fact running xntpd?

> According to the notes in the code, this should work if my RTC
> is less than 15 minutes off... which I can guarantee it is.

Well, since you looked at the source:
For some randomly chosen kernel version and architecture it does

if (abs(real_minutes - cmos_minutes) < 30) {
update_cmos()
} else {
printk("set_rtc_mmss: can't update from %d to %d\n",
   cmos_minutes, real_minutes);
}

so if your cmos time is 0.001 sec ahead of your system time
then around the hour you'll see
set_rtc_mmss: can't update from 0 to 59

Of course, messing with the cmos clock at all was a rather bad idea,
but that is a different discussion.

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/



set_rtc_mmss: can't update from 0 to 59

2000-12-17 Thread Matthew Dharm

I was trying to figure out why I periodically get the message 

set_rtc_mmss: can't update from 0 to 59

on my console.  It appears that the kernel is attempting to update my CMOS
clock for me, based on the more accurate data being provided by my xntpd.

According to the notes in the code, this should work if my RTC is less than
15 minutes off... which I can guarantee it is.  Accoring to hwclock, it's
less than a second off.

So, what's causing this message?

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

Okay, this isn't funny anymore! Let me down!  I'll tell Bill on you!!
-- Microsoft Salesman
User Friendly, 4/1/1998

 PGP signature


Re: 2.4.0-test13-pre1 lockup: run_task_queue or tty_io are wrong

2000-12-17 Thread Linus Torvalds

In article <[EMAIL PROTECTED]>,
Jeff V. Merkey <[EMAIL PROTECTED]> wrote:
>
>Try thinking about the work to do model (since task queues are so similiar)
>Having to "kick" these things should be automatic in the kernel.  I could
>do a lot of cool stuff with this in there, manos aside.

No, the "kicking" should _not_ be automatic.

Th ewhol epoint of a lot of the task queues is that they are manual. The
main use for them (apart from the tty layer, which could easily use
something else) is the disk starter - where we want to delay the
submission of requests to the disk until we've aggregated as many as
possible. Which means that the "tq_disk" queue must absolutely not be
kicked automatically.

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: [OT] Re: Linus's include file strategy redux

2000-12-17 Thread ferret



On Sun, 17 Dec 2000, Peter Samuelson wrote:

> 
> [[EMAIL PROTECTED] <[EMAIL PROTECTED]>]
> > I have not moved or deleted a tree. I do not HAVE a kernel tree in
> > the first place. Therefore, nothing for the symlink to point to when
> > I install the kernel.
> 
> If this is not the machine you compile your kernels on, why are you
> compiling your external modules on it?

One last question: WHY is the kernel's top-level Makefile handling this
symlink?

-
To unsubscribe from this list: send the 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-test13-pre1 lockup: run_task_queue or tty_io are wrong

2000-12-17 Thread Jeff V. Merkey

On Sun, Dec 17, 2000 at 12:02:31PM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 17 Dec 2000, Jamie Lokier wrote:
> > 
> > How about using a sentinel list entry representing the current position
> > in run_task_queue's loop?
> 
> Nope.
> 
> There may be multiple concurrent run_task_queue's executing, so for now
> I've applied Andrew Morton's patch that most closely gets the old
> behaviour of having a private list.
> 
> HOWEVER, this does need to be re-visited. The task-queue handling is
> potantially something that should be completely re-vamped in the future.
> 
>   Linus


Linus,

Try thinking about the work to do model (since task queues are so similiar)
Having to "kick" these things should be automatic in the kernel.  I could
do a lot of cool stuff with this in there, manos aside.

:-)

Jeff


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



Re: 2.4.0-test13-pre1 lockup: run_task_queue or tty_io are wrong

2000-12-17 Thread Linus Torvalds



On Sun, 17 Dec 2000, Jamie Lokier wrote:
> 
> How about using a sentinel list entry representing the current position
> in run_task_queue's loop?

Nope.

There may be multiple concurrent run_task_queue's executing, so for now
I've applied Andrew Morton's patch that most closely gets the old
behaviour of having a private list.

HOWEVER, this does need to be re-visited. The task-queue handling is
potantially something that should be completely re-vamped in the future.

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/



2.2.18 ide-scsi & scsi generic modules

2000-12-17 Thread Alex Buell

There was a post on linux-kernel earlier today stating that "hdx=scsi" did
not work correctly if both were compiled as modules for 2.4.10-testxx and
a patch was posted.

I can confirm that this is true for 2.2.x, with "hdx=ide-scsi". Once I
compiled both statically into the kernel, it works.

Perhaps somone can backport the fixes? It would be nice to change 2.2 so
it can accept "hdx=scsi" for compatiblity with 2.4.

Cheers,
Alex
-- 
The truth is out there.

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/



[PATCH] mdacon.c cleanup in 2.2.19

2000-12-17 Thread Pavel Rabel


Patch is removing few ifdefs.
Both MODULE_PARM and __initfunc are removed by preprocessor if compiled
as module.

Pavel Rabel

--- drivers/video/mdacon.c.old  Sun Dec 17 18:53:18 2000
+++ drivers/video/mdacon.c  Sun Dec 17 18:54:55 2000
@@ -75,14 +75,10 @@
 
 static struct vc_data  *mda_display_fg = NULL;
 
-#ifdef MODULE_PARM
 MODULE_PARM(mda_first_vc, "1-255i");
 MODULE_PARM(mda_last_vc,  "1-255i");
-#endif
-
 
-/* MDA register values
- */
+/* MDA register values */
 
 #define MDA_CURSOR_BLINKING0x00
 #define MDA_CURSOR_OFF 0x20
@@ -200,11 +196,7 @@
 }
 #endif
 
-#ifdef MODULE
-static int mda_detect(void)
-#else
 __initfunc(static int mda_detect(void))
-#endif
 {
int count=0;
u16 *p, p_save;
@@ -287,11 +279,7 @@
return 1;
 }
 
-#ifdef MODULE
-static void mda_initialize(void)
-#else
 __initfunc(static void mda_initialize(void))
-#endif
 {
write_mda_b(97, 0x00);  /* horizontal total */
write_mda_b(80, 0x01);  /* horizontal displayed */
@@ -316,11 +304,7 @@
outb_p(0x00, mda_gfx_port);
 }
 
-#ifdef MODULE
-static const char *mdacon_startup(void)
-#else
 __initfunc(static const char *mdacon_startup(void))
-#endif
 {
mda_num_columns = 80;
mda_num_lines   = 25;
@@ -606,11 +590,7 @@
mdacon_invert_region,   /* con_invert_region */
 };
 
-#ifdef MODULE
-void mda_console_init(void)
-#else
 __initfunc(void mda_console_init(void))
-#endif
 {
if (mda_first_vc > mda_last_vc)
return;

-
To unsubscribe from this list: send the 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 panic for nfsd access for test12

2000-12-17 Thread Mohammad A. Haque

Do you use netfilter? It's a known bug if you do.

Tommy Wu wrote:
> 
>   Does anyone use nfsd on kernel 2.4.0-test12 ?
> 
>   Usually, I backup my linux box via another machine use nfs to mount it, then run
>   afio to backup file to mo. It is work very fine through kernel 2.4.0-test7 to 
>test11.
> 
>   But this week, I change my linux box's kernel to 2.4.0-test12, I found when I use
>   another linux box (kernel 2.2.18pre21) to mount the directory in the linux server
>   running kernel 2.4.0-test12, it can be mounted, but if I do any file access, the
>   server will show kernel panic screen and there is no any log write down to 
>file.
>   All system will be halt, just can be power down. (SysRq don't work)
> 
>   I change the kernel back to 2.4.0-test11, everything is ok. So, I think it should 
>be
>   a bug in 2.4.0-test12. (I use the same .config to build both kernel, nfsd is make 
>as
>   a module)
> 
>   Because I can't see all of the kernel trace dump screen, so I can't give any 
>ksymoops
>   for that...

-- 

=
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: Monitoring filesystems / blockdevice for errors

2000-12-17 Thread Lars Marowsky-Bree

On 2000-12-17T13:23:52,
   Mark Hahn <[EMAIL PROTECTED]> said:

> > Short of parsing syslog messages, which isn't particularly great.
> what's wrong with it?

Because it means having to know about all potential messages the filesystems
might dump out.

> reinventing /proc/kmsg and klogd would be tre gross.

Well, only one process can read kmsg and get notified about new messages at
any time, so that makes the monitoring depend on klogd/syslogd working, which
given a write error by syslog might not be the case...

> > I don't have a real idea how this could be added, short of adding a field to
> > /proc/partitions (error count) or something similiar.
> for reporting errors, that might be OK, but it's not a particularly nice
> _notification_ mechanism...

Well, yes.

Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
To unsubscribe from this list: send 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] ppc fixes for drivers/char/serial.c

2000-12-17 Thread Andreas Tobler

Hi Alan,

can you may include the attached patch in one of the next pre19 patches?
It adds the possibility to work with pcmcia modem cards on PowerBooks,
this patch was in for a longer time in the ppc tree of Paul M. and Ben
Herrenschmidt. 
Ben told me to send it to you with his ack.

Thanks in advance,

Andreas
 serial2218.diff


Re: test12: innd bug came back?

2000-12-17 Thread Jorg de Jong

> >On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote:
> >
> >> Just to add a "me too" on this. I didn't report when I saw it last week,

I'd like to second that. ME TOO !
Since I switched to 2.4.0.test12 I again have the innd bug.
( well at least the same symptoms !)

No problems with test10 and test11. I have not used any pre kernels.

regards


-- 
Jorg de Jong
Work : mailto:[EMAIL PROTECTED] 
Play : 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/



[RFC] Semaphores used for daemon wakeup

2000-12-17 Thread Daniel Phillips

This patch illustrates an alternative approach to waking and waiting on
daemons using semaphores instead of direct operations on wait queues.
The idea of using semaphores to regulate the cycling of a daemon was
suggested to me by Arjan Vos.  The basic idea is simple: on each cycle
a daemon down's a semaphore, and is reactivated when some other task
up's the semaphore.

Sometimes an activating task wants to wait until the daemon completes
whatever it's supposed to do - flushing memory in this case.  I
generalized the above idea by adding another semaphore for wakers to
sleep on, and a count variable to let the daemon know how many
sleepers it needs to activate.  This patch updates bdflush and
wakeup_bdflush to use that mechanism.

The implementation uses two semaphores and a counter:

DECLARE_MUTEX_LOCKED(bdflush_request);
DECLARE_MUTEX_LOCKED(bdflush_waiter);
atomic_t bdflush_waiters /*= 0*/;

A task wanting to activate bdflush does:

up(_request);

A task wanting to activate bdflush and wait does:

atomic_inc(_waiters);
up(_request);
down(_waiter);

When bdflush has finished its work it does:

waiters = atomic_read(_waiters);
atomic_sub(waiters, _waiters);
while (waiters--)
up(_waiter);
down(_request);

Since I wasn't sure whether the side effect in the existing code of
setting the current task RUNNING was really wanted, I wrote this in
explicitly in the places where the side effect was noted, with the
obligatory comment.

I've done some fairly heavy stress-testing and this new scheme (but
not on non-x86 or SMP) and it does seem to work much the same as the
existing one.  I doubt that there is a measureable difference in
execution overhead, nor is there a difference in correctness as far as
I can see.  But for me at least, it's considerably easier to verify
that the semaphore approach is correct.

OK, there it is.  Is this better, worse, or lateral?

-- 
Daniel


--- ../2.4.0-test10.clean/fs/buffer.c	Thu Oct 12 23:19:32 2000
+++ ./fs/buffer.c	Mon Dec 18 03:03:01 2000
@@ -708,7 +708,8 @@
 static void refill_freelist(int size)
 {
 	if (!grow_buffers(size)) {
-		wakeup_bdflush(1);  /* Sets task->state to TASK_RUNNING */
+		wakeup_bdflush(1);
+		__set_current_state(TASK_RUNNING); /* needed?? */
 		current->policy |= SCHED_YIELD;
 		schedule();
 	}
@@ -2469,33 +2470,28 @@
  * response to dirty buffers.  Once this process is activated, we write back
  * a limited number of buffers to the disks and then go back to sleep again.
  */
-static DECLARE_WAIT_QUEUE_HEAD(bdflush_done);
+
+/* Semaphore wakeups, Daniel Phillips, [EMAIL PROTECTED], 2000/12 */
+
 struct task_struct *bdflush_tsk = 0;
+DECLARE_MUTEX_LOCKED(bdflush_request);
+DECLARE_MUTEX_LOCKED(bdflush_waiter);
+atomic_t bdflush_waiters /*= 0*/;
 
 void wakeup_bdflush(int block)
 {
-	DECLARE_WAITQUEUE(wait, current);
-
 	if (current == bdflush_tsk)
 		return;
 
-	if (!block) {
-		wake_up_process(bdflush_tsk);
+	if (!block)
+	{
+		up(_request);
 		return;
 	}
 
-	/* kflushd can wakeup us before we have a chance to
-	   go to sleep so we must be smart in handling
-	   this wakeup event from kflushd to avoid deadlocking in SMP
-	   (we are not holding any lock anymore in these two paths). */
-	__set_current_state(TASK_UNINTERRUPTIBLE);
-	add_wait_queue(_done, );
-
-	wake_up_process(bdflush_tsk);
-	schedule();
-
-	remove_wait_queue(_done, );
-	__set_current_state(TASK_RUNNING);
+	atomic_inc(_waiters);
+	up(_request);
+	down(_waiter);
 }
 
 /* This is the _only_ function that deals with flushing async writes
@@ -2640,7 +2636,7 @@
 int bdflush(void *sem)
 {
 	struct task_struct *tsk = current;
-	int flushed;
+	int flushed, waiters;
 	/*
 	 *	We have a bare-bones task_struct, and really should fill
 	 *	in a few more things so "top" and /proc/2/{exe,root,cwd}
@@ -2660,6 +2656,7 @@
 	spin_unlock_irq(>sigmask_lock);
 
 	up((struct semaphore *)sem);
+	printk("Testing semwake bdflush synchronization.\n");
 
 	for (;;) {
 		CHECK_EMERGENCY_SYNC
@@ -2668,28 +2665,16 @@
 		if (free_shortage())
 			flushed += page_launder(GFP_BUFFER, 0);
 
-		/* If wakeup_bdflush will wakeup us
-		   after our bdflush_done wakeup, then
-		   we must make sure to not sleep
-		   in schedule_timeout otherwise
-		   wakeup_bdflush may wait for our
-		   bdflush_done wakeup that would never arrive
-		   (as we would be sleeping) and so it would
-		   deadlock in SMP. */
-		__set_current_state(TASK_INTERRUPTIBLE);
-		wake_up_all(_done);
-		/*
-		 * If there are still a lot of dirty buffers around,
-		 * skip the sleep and flush some more. Otherwise, we
-		 * go to sleep waiting a wakeup.
-		 */
-		if (!flushed || balance_dirty_state(NODEV) < 0) {
+		waiters = atomic_read(_waiters);
+		atomic_sub(waiters, _waiters);
+		while (waiters--)
+			up(_waiter);
+
+		if (!flushed || balance_dirty_state(NODEV) < 0) 
+		{
 			run_task_queue(_disk);
-			schedule();
+			down(_request);
 		}
-		/* 

Re: 2.4.0-test13-pre1 lockup: run_task_queue or tty_io are wrong

2000-12-17 Thread Jamie Lokier

Linus Torvalds wrote:
> Ho humm. I'll have to check what the proper fix is. Right now the rule is
> that nobody can _ever_ remove himself from a task queue, although there is
> one bad user that does exactly that, and that means that it should be ok
> to just cache the "next" pointer in run_task_queue(), and make it look
> something like

How about using a sentinel list entry representing the current position
in run_task_queue's loop?

The sentinel's next pointer isn't invalidated by other operations on the
list, provided each operation is protected by tqueue_lock.  Each
iteration step is a matter or removing the sentinel, and inserting it in
the next position.  A task removing itself would then be perfectly ok.

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



Re: Monitoring filesystems / blockdevice for errors

2000-12-17 Thread Mark Hahn

> currently, there is no way for an external application to monitor whether a
> filesystem or underlaying block device has hit an error condition - internal
> inconsistency, read or write error, whatever.
> 
> Short of parsing syslog messages, which isn't particularly great.

what's wrong with it?  reinventing /proc/kmsg and klogd would be tre gross.

> I don't have a real idea how this could be added, short of adding a field to
> /proc/partitions (error count) or something similiar.

for reporting errors, that might be OK, but it's not a particularly nice
_notification_ mechanism...

regards, mark hahn.

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



[PATCH] sim710.c compiler warning

2000-12-17 Thread Pavel Rabel


Patch fixes compiler warning for 2.4.0-test12

sim710.c: In function `sim710_detect':
sim710.c:1452: warning: comparison between pointer and integer

Pavel Rabel

--- drivers/scsi/sim710.c.old   Tue Dec  5 15:34:00 2000
+++ drivers/scsi/sim710.c   Tue Dec  5 15:37:18 2000
@@ -1449,7 +1449,7 @@
 
 for(indx = 0; indx < no_of_boards; indx++) {
 unsigned long page = __get_free_pages(GFP_ATOMIC, order);
-if(page == NULL)
+if( !page )
 {
printk(KERN_WARNING "sim710: out of memory registering board %d.\n", 
indx);
break;


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



Kernel panic for nfsd access for test12

2000-12-17 Thread Tommy Wu


  Does anyone use nfsd on kernel 2.4.0-test12 ?

  Usually, I backup my linux box via another machine use nfs to mount it, then run
  afio to backup file to mo. It is work very fine through kernel 2.4.0-test7 to test11.

  But this week, I change my linux box's kernel to 2.4.0-test12, I found when I use
  another linux box (kernel 2.2.18pre21) to mount the directory in the linux server
  running kernel 2.4.0-test12, it can be mounted, but if I do any file access, the
  server will show kernel panic screen and there is no any log write down to file.
  All system will be halt, just can be power down. (SysRq don't work)

  I change the kernel back to 2.4.0-test11, everything is ok. So, I think it should be
  a bug in 2.4.0-test12. (I use the same .config to build both kernel, nfsd is make as
  a module)

  Because I can't see all of the kernel trace dump screen, so I can't give any ksymoops
  for that...

-- 

Tommy Wu
mailto:[EMAIL PROTECTED]
http://www.teatime.com.tw/~tommy
ICQ: 22766091
Mobile Phone: +886 936 909490
TeaTime BBS +886 2 3151964 24Hrs V.Everything

-
To unsubscribe from this list: send 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] making hdx=scsi work with modular SCSI support

2000-12-17 Thread Scott Murray

Andre,

While trying to get my CD-R drive working under test11, I discovered that
the hdx=scsi kernel parameter is disabled unless both IDE-SCSI support and
SCSI are compiled in statically.  That definitely wasn't the case in my
configuration and I think it unlikely to be common.  The attached patch
adds in the _MODULE definition checks and it should apply cleanly even in
test13-pre2.  It's not overly pretty, though, so maybe you can come up
with something better.

Scott


--- linux-2.4.0-test11/drivers/ide/ide.cMon Oct 16 15:58:51 2000
+++ linux-2.4.0-test11-dev/drivers/ide/ide.cWed Dec 13 23:59:37 2000
@@ -2973,13 +2973,13 @@
drive->remap_0_to_1 = 2;
goto done;
case -14: /* "scsi" */
-#if defined(CONFIG_BLK_DEV_IDESCSI) && defined(CONFIG_SCSI)
+#if (defined(CONFIG_BLK_DEV_IDESCSI) || defined(CONFIG_BLK_DEV_IDESCSI_MODULE)) && 
+(defined(CONFIG_SCSI) || defined(CONFIG_SCSI_MODULE))
drive->scsi = 1;
goto done;
 #else
drive->scsi = 0;
goto bad_option;
-#endif /* defined(CONFIG_BLK_DEV_IDESCSI) && defined(CONFIG_SCSI) */
+#endif /* (CONFIG_BLK_DEV_IDESCSI || CONFIG_BLK_DEV_IDESCSI_MODULE) && (CONFIG_SCSI 
+|| CONFIG_SCSI_MODULE) */
case 3: /* cyl,head,sect */
drive->media= ide_disk;
drive->cyl  = drive->bios_cyl  = vals[0];


-- 
=
Scott Murrayemail: [EMAIL PROTECTED]
http://www.interlog.com/~scottm   ICQ: 10602428
-
 "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"


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



test13-pre2, fpu_entry.c compile error

2000-12-17 Thread Frank Davis



Hello,
  I haven't seen this posted yet, so I have included it 
below.
Regards,
Frank
 
fpu_entry.c: In function 
`math_emulate':fpu_entry.c:194: structure has no member named 
`segments'make[2]: *** [fpu_entry.o] Error 1make[2]: Leaving directory 
`/usr/src/linux/arch/i386/math-emu'make[1]: *** [first_rule] Error 
2make[1]: Leaving directory `/usr/src/linux/arch/i386/math-emu'make: *** 
[_dir_arch/i386/math-emu] Error 2



Re: [PATCH] link time error in drivers/mtd (240t13p2)

2000-12-17 Thread Horst von Brand

Keith Owens <[EMAIL PROTECTED]> said:

[...]

> Messing about with conditional compilation because the link order is
> incorrect is the wrong fix.  The mtd/Makefile must link the objects in
> the correct order.
> 
> cfi_probe.o needs to come after cfi_cmdset_000?.o.
> doc_probe.o needs to come after doc200?.o.
> nora.o, octagon-5066.o, physmap.o, rpxlite.o, vmax301.o, pnc2000.o need
> to come after cfi_probe.o.
> octagon-5066.o, vmax301.o need to come after jedec.o.
> octagon-5066.o, vmax301.o need to come after map_ram.o.
> octagon-5066.o, vmax301.o need to come after map_rom.o.

Would tsort(1) perhaps help?
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the 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-test13-pre2: mark CONFIG_PARPORT_PC_FIFO experimental

2000-12-17 Thread Tim Waugh

On Sun, Dec 17, 2000 at 05:22:23PM +0100, Andrzej Krzysztofowicz wrote:

> Why it does not depend on CONFIG_EXPERIMENTAL if it really is experimental ?

Oh, missed that.  Thanks, fixed.

Tim.
*/

 PGP signature


Re: [patch] 2.4.0-test13-pre2: mark CONFIG_PARPORT_PC_FIFO experimental

2000-12-17 Thread Andrzej Krzysztofowicz

"Tim Waugh wrote:"
> Hi Linus,
> 
> Here is a patch that marks CONFIG_PARPORT_PC_FIFO experimental.

Why it does not depend on CONFIG_EXPERIMENTAL if it really is experimental ?
 
> --- linux-2.4.0-test13-pre1/drivers/parport/Config.in.fifoexp Thu Jun 29 10:20:36 
>2000
> +++ linux-2.4.0-test13-pre1/drivers/parport/Config.in Thu Dec 14 11:38:53 2000
> @@ -12,7 +12,7 @@
>  if [ "$CONFIG_PARPORT" != "n" ]; then
> dep_tristate '  PC-style hardware' CONFIG_PARPORT_PC $CONFIG_PARPORT
> if [ "$CONFIG_PARPORT_PC" != "n" ]; then
> -  bool 'Use FIFO/DMA if available' CONFIG_PARPORT_PC_FIFO
> +  bool 'Use FIFO/DMA if available (EXPERIMENTAL)' CONFIG_PARPORT_PC_FIFO
>if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
>   bool 'SuperIO chipset support (EXPERIMENTAL)' CONFIG_PARPORT_PC_SUPERIO
>fi
--
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: Linux 2.2.19pre2

2000-12-17 Thread Kurt Garloff

Hi,

On Sun, Dec 17, 2000 at 12:56:56PM +0200, Petri Kaukasoina wrote:
> I guess the new memory detect does not work correctly with my old work
> horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with
> a version number of 51-000-0001169_0011-101094-SIS550X-H.
> 
> 2.2.18 reports:
> Memory: 55536k/57344k available (624k kernel code, 412k reserved, 732k data, 40k 
>init)
> 
> 2.2.19pre2 reports:
> Memory: 53000k/54784k available (628k kernel code, 408k reserved, 708k data, 40k 
>init)
> 
> 57344k is 56 Megs which is correct.
> 54784k is only 53.5 Megs.

It's this patch that changes things for you:
o   E820 memory detect backport from 2.4(Michael Chen)

The E820 memory detection parses a list from the BIOS, which specifies
the amount of memory, holes, reserved regions, ...
Apparently, your BIOS does not do it completely correctly; otherwise you
should have had crashes before ...

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


using kernel headers from user space

2000-12-17 Thread Glen Shere


Keith Owens wrote:
> Linus has spoken, it is an error for user space applications to
> include kernel headers.  Even modutils does not include
> linux/module.h, instead it has a portable (2.0 through 2.4) local
> definition of struct module.

Oh my.  This isn't clear to the part-time kernel hacker; to install
[...]linux/include/linux in /usr/include/linux implies that those headers
can and should be used in user-space.  I've already done this several
times, in order to use kernel structures from user space.  Whoops :-)

Perhaps the header files that are intended to be used only within the
kernel tree could be moved to a seperate directory, and then not installed
in /usr/include.  Obviously 2.5 material, if Linus is so inclined.

I would rather a build break when what's defined in a kernel header file
gets changed (such as a critical structure, or the like) and further
maintenance of the user-space utilities is needed; a "heads-up" to the
maintainer if nothing else.  The recent episode with klogd is a fine
example of how well that would work.  If klogd had its own copies of
headers and built fine, we all would quite possibly still not know about
the inconsistency.

-Glen



-
To unsubscribe from this list: send the 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] link time error in drivers/mtd (240t13p2)

2000-12-17 Thread Alan Cox

> David Woodhouse <[EMAIL PROTECTED]> wrote:
> >The conditional compilation is far more obvious to people than subtle
> >issues with link order. So I prefer to avoid the latter at all costs.
> 
> The rest of the kernel already depends totally on these "subtle" issues
> with link order.  Why should mtd be different?

Why should mtd be broken just because the rest of the Makefiles are

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



Re: APM bug with Inspiron 5000e

2000-12-17 Thread Alan Cox

> I am seeing this bug with both test8 and test12 kernels. Help/suggestions
> for debugging are appreciated.

Ask Dell for a working BIOS. This 5000E is a known BIOS bug. 

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



Re: aic7xxx

2000-12-17 Thread stewart


 ditto.

On Sun, 17 Dec 2000, Mathias Wiklander wrote:

> Sorry I've forgot that. It is 2.4.0-test12
> 
> /Eastbay
> "Mohammad A. Haque" wrote:
> > 
> > Helps if we could get a kernel version.
> > 
> > Mathias Wiklander wrote:
> > >
> > > Hi!
> > >
> > > I have problem using my scsi card. It is an Adaptec 2940 (SCSI2). When
> > > ever I try to load it as a module or if I compile it in the kernel I get
> > > the folowing error messages. The last 4 messages repeats for ever. The
> > > problem is on 3 diffrent machines. Anyone who know what it can be and
> > > how to fix it.
> > 


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



Monitoring filesystems / blockdevice for errors

2000-12-17 Thread Lars Marowsky-Bree

Good morning,

currently, there is no way for an external application to monitor whether a
filesystem or underlaying block device has hit an error condition - internal
inconsistency, read or write error, whatever.

Short of parsing syslog messages, which isn't particularly great.

This is necessary for server monitoring in general.

I don't have a real idea how this could be added, short of adding a field to
/proc/partitions (error count) or something similiar.

Comments?

Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
To unsubscribe from this list: send the 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] docbook fix kmod.c

2000-12-17 Thread Tim Waugh

On Sat, Dec 16, 2000 at 05:26:09PM +0200, Jani Monoses wrote:

>   kernel-api.tmpl references the exported functions of kmod.c but
> there are none.

There are: hotplug_path, exec_usermodehelper, call_usermodehelper,
request_module.

Try adding kmod.c to APISOURCES in the Makefile.

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/



Re: [patch] pci.c inline documentation

2000-12-17 Thread Tim Waugh

On Sat, Dec 16, 2000 at 05:37:51PM +0200, Jani Monoses wrote:

> + * Otherwise if @from is not %NULL, searches continue from that point.

Searches continue from the next one I think.

> + * pci_register_driver - register a new pci driver
[...]
> + * pci_unregister_driver - unregister a pci driver
[...]
> + * pci_insert_device - insert a hotplug device
> + * pci_remove_device - remove a hotplug device
> + * pci_dev_driver - get the pci_driver of a device
> + * pci_set_master - enables bus-mastering for device dev
> + * pci_setup_device - fill in class and map information of a device

These have no full-stop after the description, but the others do.

Tim.
*/

 PGP signature


Re: kapm-idled : is this a bug?

2000-12-17 Thread Igmar Palsenberg


> How about adding a flag to FLAGS, or a new letter in STATE in
> /proc/pid/stat, to mean "this is an idle task"?
> 
> ps & top could easily by taught to recognise the flag.

What's the problem with using PID 0 as the idle task ? That's 'standard'
with OS'ses that display the idle task.

It's also the 'right' thing to do, and should directly work with top / ps


Igmar




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



Kernel Panic with 2.4.0-test12 when using iso9660 over nfs

2000-12-17 Thread Dieter Schuster

If I mount a cdrom over NFS with 2.4.0-test12 on the NFS-Server, the server
crashs. In the log-files are no Information. On the screen comes the following:

Code: 89 42 04 89 10 b8 01 00 00 c7 43 04 00 00 00 c 03 00
Aieee, killing interupt handler
Unable to handle kernel Null pointer deveference at virtural address 029e.

It crashs only with 2.4.0-test12 with 2.4.0-test10 it doesn't (with 
2.4.0-test11 I cannot use cdroms at all). 

I have an Alladin V chipset and a IDE-CDROM.

My System:
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux Poseidon 2.4.0-test12 #2 Wed Nov 29 19:54:45 MET 2000 i586 unknown
Kernel modules found
Gnu C  2.95.2
Binutils   2.9.5.0.37
Linux C Library2.2
Procps 2.0.6
Mount  2.10f
Net-tools  (1999-04-20)
Kbd[option...]
Sh-utils   2.0
Sh-utils   Parker.
Sh-utils   Inc.
Sh-utils   NO
Sh-utils   PURPOSE.

Dieter

Registered Linux User #186360
-- 
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.

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



Re: Sound (emu10k1) broken in 2.2.18

2000-12-17 Thread Simon Lodal

> - Do you have emu10k1 compiled in, or as a module?
> - Does your SBLive appear to have been detected?  (Check 'dmesg')
> - If emu10k1 is a module, is the module loaded?  Does it seem to detect
>   your SBLive when loaded?  (Again check 'dmesg')

On my machine emu10k1 works as a module, but not at all when compiled
in. When I had it compiled in I didn't notice if the card was detected.
It surely worked as compiled in with 2.2.17, but not with 2.2.18.

Too, the bass and treble controls seem to have vanished in 2.2.18, they
do not show up in any mixer apps anymore.

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



[patch] 2.4.0-test13-pre2: better parport_pc commentary

2000-12-17 Thread Tim Waugh

Hi Linus,

Here is a patch to make the parport_pc comments better.  No code
change.

Tim.
*/

2000-12-17  Tim Waugh  <[EMAIL PROTECTED]>

* drivers/parport/parport_pc.c: Better commentary.  Patch from
R Horn.
* drivers/parport/ChangeLog: Updated.

--- linux-2.4.0-test12/drivers/parport/parport_pc.c.commentary  Tue Dec 12 13:03:24 
2000
+++ linux-2.4.0-test12/drivers/parport/parport_pc.c Wed Dec 13 14:11:11 2000
@@ -938,13 +938,11 @@
/* Can't yield the port. */
schedule ();
 
-   /* At this point, the FIFO may already be full.
-* Ideally, we'd be able to tell the port to hold on
-* for a second while we empty the FIFO, and we'd be
-* able to ensure that no data is lost.  I'm not sure
-* that's the case. :-(  It might be that you can play
-* games with STB, as in the forward case; someone should
-* look at a datasheet. */
+   /* At this point, the FIFO may already be full. In
+ * that case ECP is already holding back the
+ * peripheral (assuming proper design) with a delayed
+ * handshake.  Work fast to avoid a peripheral
+ * timeout.  */
 
if (ecrval & 0x01) {
/* FIFO is empty. Wait for interrupt. */
@@ -976,6 +974,10 @@
goto false_alarm;
}
 
+   /* Depending on how the FIFO threshold was
+ * set, how long interrupt service took, and
+ * how fast the peripheral is, we might be
+ * lucky and have a just filled FIFO. */
continue;
}
 
@@ -987,6 +989,9 @@
continue;
}
 
+   /* FIFO not filled.  We will cycle this loop for a while
+ * and either the peripheral will fill it faster,
+ * tripping a fast empty with insb, or we empty it. */
*bufp++ = inb (fifo);
left--;
}
--- linux-2.4.0-test12/drivers/parport/ChangeLog.commentary Wed Dec 13 14:17:10 
2000
+++ linux-2.4.0-test12/drivers/parport/ChangeLogWed Dec 13 14:17:26 2000
@@ -0,0 +1,4 @@
+2000-12-17  R Horn  <[EMAIL PROTECTED]>
+
+   * parport_pc.c: Some commentary changes.
+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



[patch] 2.4.0-test13-pre2: macro documentation

2000-12-17 Thread Tim Waugh

Hi Linus,

This patch adds inline documentation to a couple of macros, with
improvements suggested by Andi Kleen.

Tim.
*/

2000-12-13  Tim Waugh  <[EMAIL PROTECTED]>

* include/linux/init.h, include/linux/module.h: Inline
documentation for some macros.  Patch from Armin Kuster.

--- linux-2.4.0-test12/include/linux/init.h.macrodocWed Nov  1 15:06:38 2000
+++ linux-2.4.0-test12/include/linux/init.h Wed Dec 13 23:26:04 2000
@@ -86,7 +86,27 @@
 #define __FINIT.previous
 #define __INITDATA .section".data.init","aw"
 
+/**
+ * module_init() - driver initialization entry point
+ * @x: function to be run at kernel boot time or module insertion
+ * 
+ * module_init() will add the driver initialization routine in
+ * the "__initcall.int" code segment if the driver is checked as
+ * "y" or static, or else it will wrap the driver initialization
+ * routine with init_module() which is used by insmod and
+ * modprobe when the driver is used as a module.
+ */
 #define module_init(x) __initcall(x);
+
+/**
+ * module_exit() - driver exit entry point
+ * @x: function to be run when driver is removed
+ * 
+ * module_exit() will wrap the driver clean-up code
+ * with cleanup_module() when used with rmmod when
+ * the driver is a module.  If the driver is statically
+ * compiled into the kernel, module_exit() has no effect.
+ */
 #define module_exit(x) __exitcall(x);
 
 #else
--- linux-2.4.0-test12/include/asm-i386/atomic.h.macrodoc   Tue Oct 10 14:34:08 
2000
+++ linux-2.4.0-test12/include/asm-i386/atomic.hWed Dec 13 23:26:13 2000
@@ -23,9 +23,33 @@
 
 #define ATOMIC_INIT(i) { (i) }
 
+/**
+ * atomic_read - read atomic variable
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically reads the value of @v.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */ 
 #define atomic_read(v) ((v)->counter)
+
+/**
+ * atomic_set - set atomic variable
+ * @v: pointer of type atomic_t
+ * @i: required value
+ * 
+ * Atomically sets the value of @v to @i.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */ 
 #define atomic_set(v,i)(((v)->counter) = (i))
 
+/**
+ * atomic_add - add integer to atomic variable
+ * @i: integer value to add
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically adds @i to @v.  Note that the guaranteed useful range
+ * of an atomic_t is only 24 bits.
+ */
 static __inline__ void atomic_add(int i, atomic_t *v)
 {
__asm__ __volatile__(
@@ -34,6 +58,14 @@
:"ir" (i), "m" (v->counter));
 }
 
+/**
+ * atomic_sub - subtract the atomic variable
+ * @i: integer value to subtract
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically subtracts @i from @v.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */
 static __inline__ void atomic_sub(int i, atomic_t *v)
 {
__asm__ __volatile__(
@@ -42,6 +74,16 @@
:"ir" (i), "m" (v->counter));
 }
 
+/**
+ * atomic_sub_and_test - test variable then subtract 
+ * @i: integer value to subtract
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically subtracts @i from @v and returns
+ * true if the result is zero, or false for all
+ * other cases.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */
 static __inline__ int atomic_sub_and_test(int i, atomic_t *v)
 {
unsigned char c;
@@ -53,6 +95,13 @@
return c;
 }
 
+/**
+ * atomic_inc - increment atomic variable
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically increments @v by 1.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */ 
 static __inline__ void atomic_inc(atomic_t *v)
 {
__asm__ __volatile__(
@@ -61,6 +110,13 @@
:"m" (v->counter));
 }
 
+/**
+ * atomic_dec - decrement the atomic variable
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically decrements @v by 1.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */ 
 static __inline__ void atomic_dec(atomic_t *v)
 {
__asm__ __volatile__(
@@ -69,6 +125,15 @@
:"m" (v->counter));
 }
 
+/**
+ * atomic_dec_and_test - decrement by 1 and test
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically decrements @v by 1 and
+ * returns true if the result is 0, or false for all other
+ * cases.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */ 
 static __inline__ int atomic_dec_and_test(atomic_t *v)
 {
unsigned char c;
@@ -80,6 +145,15 @@
return c != 0;
 }
 
+/**
+ * atomic_inc_and_test - increment by 1 and test 
+ * @v: pointer of type atomic_t
+ * 
+ * Atomically increments @v by 1
+ * and returns true if the result is zero, or false for all
+ * other cases.  Note that the guaranteed
+ * useful range of an atomic_t is only 24 bits.
+ */ 
 static __inline__ int atomic_inc_and_test(atomic_t *v)
 {
unsigned char c;
@@ -91,6 +165,16 @@
return c != 0;
 }
 
+/**
+ * 

[Fwd: [patch] call_usermodehelper]

2000-12-17 Thread Andrew Morton

I missed a certain mailing list on this one...

 Original Message 
Subject: [patch] call_usermodehelper
Date: Sun, 17 Dec 2000 23:01:14 +1100
From: Andrew Morton <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
CC: David Brownell <[EMAIL PROTECTED]>,Thomas Sailer <[EMAIL PROTECTED]>,Keith 
Owens <[EMAIL PROTECTED]>,"[EMAIL PROTECTED]" 
<[EMAIL PROTECTED]>

Final installment...

This function has three modes:

* Synchronous.  The caller is blocked until error or termination of the
  subprocess.  Needed by baycomm_epp.c and, in the future, by
  request_module().

* Asynchronous with completion.  The completion is called when an error
  occurs or when the subprocess exits.  To be used by USB.

* Asynchronous with no completion (the "fingers crossed" mode).  Used
  by netdevices.

I've been very careful to ensure that the caller always knows whether
or not the subprocess ran, and whether or not it succeeded (exit code).
See the inline kernel-docs for details.

- baycom_epp.c has been changed to use call_usermodehelper() (Thomas
  has tested this - thanks!) and exec_usermodehelper() has been
  removed from the kernel API. It still exists, statically, for
  request_module().  I'll kill it completely post-2.4

- In the three places where call_usermodehelper() is called, the
  initialisation of the PATH and HOME environment variables
  has been removed.  It is the responsibility of the usermode
  process to initialise these.  This change was not made in
  baycom_epp.c - that might break an existing application.

  If someone wants to set up a system which has world-writable
  /usr/sbin, the kernel shouldn't prevent this by offering users
  subtle rootsploits.  I think.

  Keith, I think we should do this to modprobe post-2.4 as well:
  it won't have a $PATH or $HOME when it is launched.

- Asynchronous usage of call_usermodehelper() from interrupt
  context is permitted.

- Asynchronous mode is now fully async wrt vfork(), which
  fixes the lingering concerns over vfork() doing something
  which requires hotplugging and causing keventd deadlock.

- Synchronous use of call_usermodehelper() from within keventd
  deadlocks keventd.  Not recommended.  Use a completion or
  a standalone thread.

- When there is a completion outstanding we manage the caller's
  module refcount for them.  But the caller must still do things
  like not shut the hardware down or free resources if a completion
  is outstanding.  If call_usermodehelper() returned non-negative,
  the completion _will_ be called.  Promise.

- Created lib/misc.c as a placeholder for reusable boilerplate.

- ObBloatStatement - grows the image by 1.1k.  Sorry.

TODO:

- Infinite recursion protection in synchronous mode.  I think this
  can wait until request_module() is using call_usermodehelper().



--- linux-2.4.0-test13-pre2/include/linux/string.h  Sat Dec 16 23:59:50 2000
+++ linux-akpm/include/linux/string.h   Sun Dec 17 22:51:29 2000
@@ -13,7 +13,10 @@
 extern char * strtok(char *,const char *);
 extern char * strsep(char **,const char *);
 extern __kernel_size_t strspn(const char *,const char *);
-
+extern void *kmallocz(size_t size, int gfp_flags);
+extern char *kstrdup(const char *orig, int gfp_flags);
+extern char **kstrdup_vec(char **orig, int gfp_flags);
+extern void kstrfree_vec(char **vec);
 
 /*
  * Include machine specific inline routines
--- linux-2.4.0-test13-pre2/include/linux/kmod.hSat Dec 16 23:59:50 2000
+++ linux-akpm/include/linux/kmod.h Sun Dec 17 22:51:29 2000
@@ -22,14 +22,31 @@
 #include 
 #include 
 
+struct module;
 #ifdef CONFIG_KMOD
 extern int request_module(const char * name);
 #else
 static inline int request_module(const char * name) { return -ENOSYS; }
 #endif
 
-extern int exec_usermodehelper(char *program_path, char *argv[], char *envp[]);
-extern int call_usermodehelper(char *path, char *argv[], char *envp[]);
+struct umh_control {
+   int synchronous;/* Flag: make 
+call_usermodehelper() block */
+   void (*completion)(void *completion_arg, int exit_code);/* Called when 
+subprocess exits if non-NULL */
+   void *completion_arg;   /* Private to caller */
+   struct module *owner;
+};
+
+#define INIT_UMH_CONTROL(_synchronous, _completion, _completion_arg) { \
+   synchronous:(_synchronous), \
+   completion: (_completion),  \
+   completion_arg: (_completion_arg),  \
+   owner:  THIS_MODULE,\
+   }
+
+#define DEFINE_UMH_CONTROL(name, synchronous, completion, completion_arg)  \
+   struct umh_control name = INIT_UMH_CONTROL(synchronous, completion, 
+completion_arg)
+
+extern int call_usermodehelper(char *path, char *argv[], char *envp[], struct 
+umh_control *umh_c);
 
 #ifdef CONFIG_HOTPLUG
 extern char hotplug_path [];
--- 

[patch] 2.4.0-test13-pre2: ppa 2.07

2000-12-17 Thread Tim Waugh

Hi Linus,

This patch fixes some timing issues with ppa.

Tim.
*/

2000-12-13  Tim Waugh  <[EMAIL PROTECTED]>

* drivers/scsi/ppa.c, drivers/scsi/ppa.h: Timing fixes.  New
parameter "recon_tmo=".  This is 2.07-for-2.4.x.

--- linux-2.4.0-test12/drivers/scsi/ppa.c.ppa207Tue Dec 12 13:03:27 2000
+++ linux-2.4.0-test12/drivers/scsi/ppa.c   Thu Dec 14 17:18:53 2000
@@ -31,6 +31,7 @@
 Scsi_Cmnd *cur_cmd;/* Current queued command   */
 struct tq_struct ppa_tq;   /* Polling interupt stuff   */
 unsigned long jstart;  /* Jiffies at start */
+unsigned long recon_tmo;/* How many usecs to wait for reconnection (6th bit) 
+*/
 unsigned int failed:1; /* Failure flag */
 unsigned int p_busy:1; /* Parport sharing busy flag*/
 } ppa_struct;
@@ -43,6 +44,7 @@
cur_cmd:NULL,   \
ppa_tq: { routine: ppa_interrupt }, \
jstart: 0,  \
+   recon_tmo:  PPA_RECON_TMO,  \
failed: 0,  \
p_busy: 0   \
 }
@@ -248,6 +250,12 @@
ppa_hosts[hostno].mode = x;
return length;
 }
+if ((length > 10) && (strncmp(buffer, "recon_tmo=", 10) == 0)) {
+   x = simple_strtoul(buffer + 10, NULL, 0);
+   ppa_hosts[hostno].recon_tmo = x;
+printk("ppa: recon_tmo set to %ld\n", x);
+   return length;
+}
 printk("ppa /proc: invalid variable\n");
 return (-EINVAL);
 }
@@ -268,6 +276,9 @@
 len += sprintf(buffer + len, "Version : %s\n", PPA_VERSION);
 len += sprintf(buffer + len, "Parport : %s\n", ppa_hosts[i].dev->port->name);
 len += sprintf(buffer + len, "Mode: %s\n", 
PPA_MODE_STRING[ppa_hosts[i].mode]);
+#if PPA_DEBUG > 0
+len += sprintf(buffer + len, "recon_tmo : %lu\n", ppa_hosts[i].recon_tmo);
+#endif
 
 /* Request for beyond end of buffer */
 if (offset > length)
@@ -556,6 +567,7 @@
 k = PPA_SELECT_TMO;
 do {
k--;
+   udelay(1);
 } while ((r_str(ppb) & 0x40) && (k));
 if (!k)
return 0;
@@ -569,6 +581,7 @@
 k = PPA_SELECT_TMO;
 do {
k--;
+   udelay(1);
 }
 while (!(r_str(ppb) & 0x40) && (k));
 if (!k)
@@ -652,6 +665,7 @@
  *  1 Finished data transfer
  */
 int host_no = cmd->host->unique_id;
+unsigned short ppb = PPA_BASE(host_no);
 unsigned long start_jiffies = jiffies;
 
 unsigned char r, v;
@@ -663,7 +677,11 @@
(v == WRITE_6) ||
(v == WRITE_10));
 
-r = ppa_wait(host_no); /* Need a ppa_wait() - PJC */
+/*
+ * We only get here if the drive is ready to comunicate,
+ * hence no need for a full ppa_wait.
+ */
+r = (r_str(ppb) & 0xf0);
 
 while (r != (unsigned char) 0xf0) {
/*
@@ -673,12 +691,36 @@
if (time_after(jiffies, start_jiffies + 1))
return 0;
 
-   if (((r & 0xc0) != 0xc0) || (cmd->SCp.this_residual <= 0)) {
+   if ((cmd->SCp.this_residual <= 0)) {
ppa_fail(host_no, DID_ERROR);
return -1;  /* ERROR_RETURN */
}
-   /* determine if we should use burst I/O */ fast = (bulk && 
(cmd->SCp.this_residual >= PPA_BURST_SIZE))
-   ? PPA_BURST_SIZE : 1;
+
+   /* On some hardware we have SCSI disconnected (6th bit low)
+* for about 100usecs. It is too expensive to wait a 
+* tick on every loop so we busy wait for no more than
+* 500usecs to give the drive a chance first. We do not 
+* change things for "normal" hardware since generally 
+* the 6th bit is always high.
+* This makes the CPU load higher on some hardware 
+* but otherwise we can not get more then 50K/secs 
+* on this problem hardware.
+*/
+   if ((r & 0xc0) != 0xc0) {
+  /* Wait for reconnection should be no more than 
+   * jiffy/2 = 5ms = 5000 loops
+   */
+  unsigned long k = ppa_hosts[host_no].recon_tmo; 
+  for (; k && ((r = (r_str(ppb) & 0xf0)) & 0xc0) != 0xc0; k--)
+udelay(1);
+
+  if(!k) 
+return 0;
+   }  
+
+   /* determine if we should use burst I/O */ 
+   fast = (bulk && (cmd->SCp.this_residual >= PPA_BURST_SIZE)) 
+? PPA_BURST_SIZE : 1;
 
if (r == (unsigned char) 0xc0)
status = ppa_out(host_no, cmd->SCp.ptr, fast);
@@ -701,7 +743,7 @@
}
}
/* Now check to see if the drive is ready to comunicate */
-   r = ppa_wait(host_no); /* need ppa_wait() - PJC */
+   r = (r_str(ppb) & 0xf0);
/* If not, drop back down to the scheduler and wait a timer tick */
if (!(r & 0x80))
return 0;
--- linux-2.4.0-test12/drivers/scsi/ppa.h.ppa207Tue Dec 12 13:03:27 2000
+++ linux-2.4.0-test12/drivers/scsi/ppa.h   Thu Dec 14 17:19:16 2000
@@ -10,7 +10,7 @@
 #ifndef 

[patch] 2.4.0-test13-pre2: mark CONFIG_PARPORT_PC_FIFO experimental

2000-12-17 Thread Tim Waugh

Hi Linus,

Here is a patch that marks CONFIG_PARPORT_PC_FIFO experimental.

Tim.
*/

2000-12-14  Tim Waugh  <[EMAIL PROTECTED]>

* drivers/parport/Config.in: Mark CONFIG_PARPORT_PC_FIFO
experimental.
* drivers/parport/ChangeLog: Updated.

--- linux-2.4.0-test13-pre1/drivers/parport/Config.in.fifoexp   Thu Jun 29 10:20:36 
2000
+++ linux-2.4.0-test13-pre1/drivers/parport/Config.in   Thu Dec 14 11:38:53 2000
@@ -12,7 +12,7 @@
 if [ "$CONFIG_PARPORT" != "n" ]; then
dep_tristate '  PC-style hardware' CONFIG_PARPORT_PC $CONFIG_PARPORT
if [ "$CONFIG_PARPORT_PC" != "n" ]; then
-  bool 'Use FIFO/DMA if available' CONFIG_PARPORT_PC_FIFO
+  bool 'Use FIFO/DMA if available (EXPERIMENTAL)' CONFIG_PARPORT_PC_FIFO
   if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
  bool 'SuperIO chipset support (EXPERIMENTAL)' CONFIG_PARPORT_PC_SUPERIO
   fi
--- linux-2.4.0-test13-pre1+/drivers/parport/ChangeLog.fifoexp  Fri Dec 15 11:33:52 
2000
+++ linux-2.4.0-test13-pre1+/drivers/parport/ChangeLog  Fri Dec 15 11:34:03 2000
@@ -0,0 +1,4 @@
+2000-12-14  Tim Waugh  <[EMAIL PROTECTED]>
+
+   * Config.in: Mark CONFIG_PARPORT_PC_FIFO 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/



[patch] 2.4.0-test13-pre2: ChangeLog sync

2000-12-17 Thread Tim Waugh

Hi Linus,

Here is a small patch that syncs up the parport ChangeLog to the
current source tree.

Tim.
*/

2000-12-13  Tim Waugh  <[EMAIL PROTECTED]>

* drivers/parport/ChangeLog: Resync.

--- linux-2.4.0-test12/drivers/parport/ChangeLog.sync   Wed Dec 13 12:37:45 2000
+++ linux-2.4.0-test12/drivers/parport/ChangeLogWed Dec 13 12:38:41 2000
@@ -9,6 +9,11 @@
* parport_pc.c (sio_via_686a_probe): Handle case
where hardware returns 255 for IRQ or DMA.
 
+2000-08-08  Cesar Eduardo Barros  <[EMAIL PROTECTED]>
+
+   * parport_pc.c (parport_pc_probe_port): Fix annoying printk to
+   console bug.
+
 2000-07-20  Eddie C. Dost  <[EMAIL PROTECTED]>
 
* share.c (attach_driver_chain): attach[i](port) needs to be
-
To unsubscribe from this list: send the 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 ll_rw_block error.

2000-12-17 Thread Chris Mason



On Sat, 16 Dec 2000, Russell Cattelan wrote:
> >
> I'm curious about this.
> Does the mean reiserFS is doing all of it's own buffer management?
> 
> This would seem a little redundant with what is already in the kernel?
> 
For metadata only reiserfs does its own write management.  The buffers
come from getblk. We just don't mark the buffers dirty for flushing by
flush_dirty_buffers()

This has the advantage of avoiding races against bdflush and friends, and
makes it easier to keep track of which buffers have actually made their
way to disk.  It has all of the obvious disadvantages with respect to
memory pressure.

-chris

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



Re: [PATCH] link time error in drivers/mtd (240t13p2)

2000-12-17 Thread David Woodhouse

On Sun, 17 Dec 2000, Keith Owens wrote:

> Your choice.  Just bear in mind that if CONFIG_MODULES=y but mtd
> objects are built into the kernel then mtd _must_ have a correct link
> order.  Consider a config with CONFIG_MODULES=y but every mtd option is
> set to 'y', link order is critical.

Yep, I'd just noticed that one. The patch was actually put in by someone
to fix 2.0 compilation - and I noticed that it made the link order
problem go away for certain configs.

> Of course you could invent and maintain your own unique method for
> controlling mtd initialisation order ...

I'll try to find a clean way to make the MTD code work in all
configurations without having to do that. If it really comes to doing the
above, I'll probably just give up and let it stay 'broken' (IMO) along
with the rest of the kernel code which as you say already has link order
dependencies.

-- 
dwmw2


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



Re: [PATCH] link time error in drivers/mtd (240t13p2)

2000-12-17 Thread Keith Owens

On Sun, 17 Dec 2000 11:39:50 + (GMT), 
David Woodhouse <[EMAIL PROTECTED]> wrote:
>On Sun, 17 Dec 2000, Keith Owens wrote:
>
>> The rest of the kernel already depends totally on these "subtle" issues
>> with link order.  Why should mtd be different?
>
>Because I maintain the MTD code and I want it to be. I think the link
>order dependencies are ugly, unnecessary and far more likely to be
>problematic then the alternatives. I'll code an alternative which is
>cleaner than the current code, and Linus can either accept it or not, as
>he sees fit.

Your choice.  Just bear in mind that if CONFIG_MODULES=y but mtd
objects are built into the kernel then mtd _must_ have a correct link
order.  Consider a config with CONFIG_MODULES=y but every mtd option is
set to 'y', link order is critical.  The moment you have two or more
mtd modules built in then you are stuck with link order issues, no
matter what you do.  Of course you could invent and maintain your own
unique method for controlling mtd initialisation order ...

-
To unsubscribe from this list: send the 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] link time error in drivers/mtd (240t13p2)

2000-12-17 Thread David Woodhouse

On Sun, 17 Dec 2000, Keith Owens wrote:

> The rest of the kernel already depends totally on these "subtle" issues
> with link order.  Why should mtd be different?

Because I maintain the MTD code and I want it to be. I think the link
order dependencies are ugly, unnecessary and far more likely to be
problematic then the alternatives. I'll code an alternative which is
cleaner than the current code, and Linus can either accept it or not, as
he sees fit.

-- 
dwmw2


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



for Alan Cox [patch-2.2.19-pre2] more fixes to microcode driver(fwd)

2000-12-17 Thread Tigran Aivazian

Alan, please ignore this one _if_ you have already received it today.

-- Forwarded message --
Date: Sun, 17 Dec 2000 10:53:49 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: Alan Cox <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: [patch-2.2.19-pre2] more fixes to microcode driver

Hi Alan,

I backported two bugfixes from 2.4 and also fixed an existing bug in
microcode_init. Tested both as module and static on 2.2.19-pre2.

Regards,
Tigran

diff -urN -X dontdiff linux/arch/i386/kernel/microcode.c 
ucode-2.2/arch/i386/kernel/microcode.c
--- linux/arch/i386/kernel/microcode.c  Sun Dec 17 09:18:32 2000
+++ ucode-2.2/arch/i386/kernel/microcode.c  Sun Dec 17 09:27:36 2000
@@ -33,6 +33,8 @@
  * Messages for error cases (non intel & no suitable microcode).
  * 1.0607 Dec 2000, Tigran Aivazian <[EMAIL PROTECTED]>
  * Pentium 4 support + backported fixes from 2.4
+ * 1.0713 Dec 2000, Tigran Aivazian <[EMAIL PROTECTED]>
+ * More bugfixes backported from 2.4
  */
 
 #include 
@@ -47,7 +49,7 @@
 #include 
 #include 
 
-#define MICROCODE_VERSION  "1.06"
+#define MICROCODE_VERSION  "1.07"
 
 MODULE_DESCRIPTION("Intel CPU (IA-32) microcode update driver");
 MODULE_AUTHOR("Tigran Aivazian <[EMAIL PROTECTED]>");
@@ -87,13 +89,10 @@
 
 int __init microcode_init(void)
 {
-   int error = 0;
-
if (misc_register(_dev) < 0) {
-   printk(KERN_WARNING 
-   "microcode: can't misc_register on minor=%d\n",
+   printk(KERN_ERR "microcode: can't misc_register on minor=%d\n",
MICROCODE_MINOR);
-   error = 1;
+   return -EINVAL;
}
printk(KERN_INFO "IA-32 Microcode Update Driver: v%s <[EMAIL PROTECTED]>\n", 
MICROCODE_VERSION);
@@ -234,18 +233,21 @@
 
 static ssize_t microcode_read(struct file *file, char *buf, size_t len, loff_t *ppos)
 {
-   if (*ppos >= mc_fsize)
-   return 0;
+   ssize_t err = 0;
+
down(_sem);
+   if (*ppos >= mc_fsize)
+   goto out;
if (*ppos + len > mc_fsize)
len = mc_fsize - *ppos;
-   if (copy_to_user(buf, mc_applied + *ppos, len)) {
-   up(_sem);
-   return -EFAULT;
-   }
+   err = -EFAULT;
+   if (copy_to_user(buf, mc_applied + *ppos, len))
+   goto out;
*ppos += len;
+   err = len;
+out:
up(_sem);
-   return len;
+   return err;
 }
 
 static ssize_t microcode_write(struct file *file, const char *buf, size_t len, loff_t 
*ppos)
@@ -300,11 +302,12 @@
case MICROCODE_IOCFREE:
down(_sem);
if (mc_applied) {
+   int bytes = smp_num_cpus * sizeof(struct microcode);
+
memset(mc_applied, 0, mc_fsize);
kfree(mc_applied);
mc_applied = NULL;
-   printk(KERN_WARNING 
-   "microcode: freed %d bytes\n", mc_fsize);
+   printk(KERN_WARNING "microcode: freed %d bytes\n", 
+bytes);
mc_fsize = 0;
up(_sem);
return 0;


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



Re: 2.2.18 vs Inspiron

2000-12-17 Thread Peter Samuelson


[James Simmons]
> Ah the infamous Rage Mobility chipset. Three versions of the same
> chipset but each is very different.

I knew it was bad when ATI refuses to publish Windows drivers -- they
basically say "get drivers from your laptop vendor, there is *no*
generic driver that works for everyone".

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: Linux 2.2.19pre2

2000-12-17 Thread Petri Kaukasoina

I guess the new memory detect does not work correctly with my old work
horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with
a version number of 51-000-0001169_0011-101094-SIS550X-H.

2.2.18 reports:
Memory: 55536k/57344k available (624k kernel code, 412k reserved, 732k data, 40k init)

2.2.19pre2 reports:
Memory: 53000k/54784k available (628k kernel code, 408k reserved, 708k data, 40k init)

57344k is 56 Megs which is correct.
54784k is only 53.5 Megs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



  1   2   3   >