Re: CPU attachent and detachment in a running Linux system
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
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)
[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
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
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
[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
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
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
[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
[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
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
[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
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
[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
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
[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
> 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
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
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
(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
[[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
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
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
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
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
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
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
- 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
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
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
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
> /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
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
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
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?
> 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
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
> 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
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
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
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
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
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
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
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
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
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?
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
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
> >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
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
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
> 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
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
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
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
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)
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
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
"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
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
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)
> 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
> 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
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
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
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
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?
> 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
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
> - 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
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
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]
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
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
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
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.
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)
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)
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)
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)
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
[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
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/
