* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Robert Love @ 2002-12-20 0:29 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, linux kernel mailing list
In-Reply-To: <200212201122.59691.conman@kolivas.net>
On Thu, 2002-12-19 at 19:22, Con Kolivas wrote:
> Is it just because the base timeslices are longer than the old scheduler?
Could be. The default timeslice was around 50ms in 2.4. The default in
2.5 with a min of 10 and a max of 300 is about 100ms.
It could be that without the priority boost, 100ms is too long and
capable of starving tasks (which, without the priority boost, are all at
the same level and thus scheduled round-robin).
Robert Love
^ permalink raw reply
* Re: ALSA update
From: Greg KH @ 2002-12-20 0:27 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Takashi Iwai, Ruslan U. Zakirov, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.33.0212191314460.521-100000@pnote.perex-int.cz>
On Thu, Dec 19, 2002 at 01:18:10PM +0100, Jaroslav Kysela wrote:
> On Thu, 19 Dec 2002, Takashi Iwai wrote:
>
> > At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
> > Ruslan U. Zakirov <cubic@miee.ru> wrote:
> > >
> > > Hello, Jaroslav and All.
> > > How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
> > > or changes with module & boot params (Rusty Russel)? There are now some
> > > changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
> > > compatible with other kernels. May be it's better split your tree in
> > > several trees for each version of kernels?
> >
> > if possible, we'll build up some wrapper for 2.4 on alsa-driver (not
> > the codebase for 2.5) tree. if not possible, yes, splitting to two
> > trees would be reasonable for such big changes...
> >
> > thanks for noticing this issue. i'll check them now.
>
> I just removed the complete callback redefinitions from the 2.5 tree,
> but we still have three small OLD_USB sections (mainly commenting 2.5
> code which 2.4 code requires to override). Hopefully, it's quite reasonable.
> What do you think, Greg?
In the end, whatever is easiest for you do to, as I'm not the one who
has to maintain the code :)
That being said, the smaller the number of #ifdefs, the better.
Personally I would just have two different trees, but that's just me...
thanks,
greg k-h
^ permalink raw reply
* Modules loading when hardcoded
From: Jason Lixfeld @ 2002-12-20 0:33 UTC (permalink / raw)
To: linux-kernel
I had 2.4.20 compiled with ext3 as a module. ran did the standard
compile including make modules ; make modules_install but when I
rebooted, the bootup failed telling me that the modules were compiled
for 2.4.18 and being run on 2.4.20. Stranger still, the path was
/lib/jbd.o and the modules aren't even there, they are in the standard
module path of /usr/lib/modules/2.4.20
I nuked the 2.4.20 modules and re-ran make modules ; make
modules_install for 2.4.20 in hopes that it would help but it didn't.
I re-compiled the kernel and hard coded ext3 and that allowed me to boot
properly but I still got the errors about version problems on ext3.o and
jbd.o. Why are they still trying to get referenced and why are they
still trying to get referenced with the old version?!
^ permalink raw reply
* Re: parport_serial link order bug, NetMos support
From: Zwane Mwaikambo @ 2002-12-20 0:40 UTC (permalink / raw)
To: Marek Michalkiewicz; +Cc: linux-kernel
In-Reply-To: <E18P8vO-0005Rs-00@alf.amelek.gda.pl>
On Thu, 19 Dec 2002, Marek Michalkiewicz wrote:
> > I have local patches which do the same and have been using them for about
> > a year too (also at 115k). Regarding the parallel port aspect of the card,
> > i have tested using shared IRQs by running an epat cdrom via said port and
> > generating a high amount of serial i/o
>
> Could you send me your local patches? (I use parport in polling mode.)
Currently i use the following patch since i only tested the epat to ensure
that shared parport/serial irq would work.
For serial in 2.4.20
http://function.linuxpower.ca/patches/patch-parport_serial-2.4
For shared IRQs (probably would need hand patching)
http://function.linuxpower.ca/patches/patch-parport-irq1
> Would be nice to know exactly what these issues are. My only issue with
> these cards so far is that I have to patch the kernel to use them...
Perhaps google, he did mention that he had netmos support in and then
backed it out again.
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* Re: module-init-tools 0.9.5
From: Rusty Russell @ 2002-12-20 0:37 UTC (permalink / raw)
To: Tomas Szepe; +Cc: lkml
In-Reply-To: <20021219152942.GD26389@louise.pinerecords.com>
In message <20021219152942.GD26389@louise.pinerecords.com> you write:
> $ uname -r
> 2.4.20
>
> [compile and install 2.5.52]
>
> still in 2.4.20:
> # depmod -V
> module-init-tools 0.9.5
> # depmod -ae -F /boot/System.map-2.5.52 2.5.52
> #
>
> [reboot into 2.5.52]
>
> # modprobe pcnet32
> FATAL: module pcnet32 not found.
> # depmod -ae
> # modprobe pcnet32
> #
>
> Hmm?
I can't reproduce that here (the two produce identical results with my
config). Can you send the contents of /lib/modules/2.5.52/modules.dep
produced after each run?
Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* raid5 multi-drive-failure and recovery?
From: Dan Merillat @ 2002-12-20 0:49 UTC (permalink / raw)
To: linux-kernel
I've got a problem. Two drives in my array developed bad sectors at
the same time. They're in completely different places, but I can't
read the disk because md simply fails out both of them, and marks the
array unusable.
Now, I can either buy new drives and dd the raw partition over, or I
can hack the kernel to make it a bit smarter about unrecoverable
reads.
Obviously, if I have raid5_error not mark the drive bad, it will hammer
away on it, failing over and over. My thought was to let the read
fail, catch it in raid5_end_read_request then tag the stripe_head
with the device that's failed. If one has already failed, return
EIO. This way further reads on the stripe_head will go to the parity
disk (until it's eventually freed. One IO error per stripe isn't too
harsh a price to pay for disaster recovery)
in 2.4.20, I'm at raid5.c:421 where we're about to call md_error.
What happens to the bh from that point? Obviously, it's not up-to-date,
so when 1 drive fails how does it get re-issued to be pulled from a parity
drive to reconstruct it?
Please CC me, I read via the archives.
Thanks,
--Dan
Obviously, this would ONLY be for recovery in the face of bad sectors.
As quickly as possible the bad drives need to be replaced
^ permalink raw reply
* Re: writing new BBRAM driver
From: Alex Pavloff @ 2002-12-20 1:14 UTC (permalink / raw)
To: 'linux-mtd@lists.infradead.org'
Sorry, repost with a proper header... grr...
> Date: Mon, 16 Dec 2002 13:54:14 +0100
> From: Geoffroy Stevenne <geof@hellea.com>
> To: linux-mtd@lists.infradead.org
> Subject: Re: writing new BBRAM driver
> Organization: Hellea SPRl
>
>
> Hi,
>
> On Mon, 16 Dec 2002 11:14:41 +0100 (MET)
> Tobias Otto-Adamczak <toa@indakom.de> wrote:
>
> > Alex Pavloff, 2002-12-13, 15:45h:
> >
> > > Hi there folks. I've written the struct mtd_info functions for a
> > > 128KB BBRAM driver for my companies new board. It's horribly
> > > simple, as most of it is actually done by a gate array on
> the board,
> > > so from kernel land its just poking ioports. Easy stuff.
>
> Great! If it works with the versalogic board it will be tested
> here with a 512KB BBRAM. Of course I'll provide maximum feedback
> (maybe patches if any required). Thanks!
Sadly, its an integrated piece of hardware that goes onto a
power/touchscreen/bbram mezzanine board that fits directly on top of a geode
"biscuit" SBC board and connects via PC104. I'll make the source available,
but I really don't think it'll be useful to anyone else as something other
than an example.
I'm still trying to figure out some stuff.
The BBRAM formats to 122KB, which is fine. I can copy files to & from it.
Since my device can be powered down at any second, I'm might want to use a
journalling filesystem, but, well, I don't need any sort of wear levelling,
so I think jffs/2 is overkill. Shall I just run minix and just fsck the
drive on powerup or us there some sort of small non-wear-levelling yet
journalling filesystem that I could use?
Secondly: erasesize. I have to define a "erase" function (like that of the
test RAM device) and define MTD_ERASEABLE and I've got the erasesize set to
0. Is this ok? Will this be called? Should I make erase size larger for
some reason?
And lastly, while I've got you here, does anyone have any info on why
certain CompactFlash pieces don't work properly in IDE mode without file
corruption?
A range of possible theories have been proposed
1) Slow write speed of flash falling out of IDE spec
2) Crappy controller chips with IDE code that isn't up to spec
3) Linux affinity for SanDisk only, require the =flash option boot
I don't have any flash that does this, but its out there. All thoughts
appreciated.
Thanks for the great subsystem.
Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Hanna Linder @ 2002-12-20 1:01 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Hanna Linder, linux-kernel, khoa, mbligh
In-Reply-To: <20021219192419.A11997@devserv.devel.redhat.com>
--On Thursday, December 19, 2002 07:24:19 PM -0500 Pete Zaitcev <zaitcev@redhat.com> wrote:
> I see the point. I would say, having an owner does not mean
> much. Owner is just a person who makes sure bugs do not get lost.
> You can work on my bugs if you'd like :)
Well thank you :) My argument is that there should be a
way USING THE TOOL to determine which bugs are available to be
worked on. Do you seriously want 2000 people emailing you privately
asking if you are working on your bugs? I suspect since this bugzilla
is so brand new that there should be something the database people
can do to facilitate this.
I agree there should be people making sure the bugs don't get
ignored, but do they have to be assigned as owners? Could there
be a hierarchical set up of subsystem maintainer contact and
then actual bug owner?
Hanna
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Daniel Jacobowitz @ 2002-12-20 0:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jamie Lokier, H. Peter Anvin, Terje Eggestad, Ulrich Drepper,
Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212181448100.1516-100000@penguin.transmeta.com>
On Wed, Dec 18, 2002 at 02:57:11PM -0800, Linus Torvalds wrote:
>
> Btw, I'm pushing what looks like the "final" version of sysenter/sysexit
> for now. There may be bugs left, but all the known issues are resolved:
>
> - single-stepping over the system call now works. It doesn't actually see
> all of the user-mode instructions, since the fast system call interface
> does not lend itself well to restoring "TF" in eflags on return, but
> the trampoline code saves and restores the flags, so you will be able
> to step over the important bits.
>
> (ptrace also doesn't actually allow you to look at the instruction
> contents in high memory, so gdb won't see the instructions in the
> user-mode fast system call trampoline even when it can single-step
> them, and I don't think I'll bother to fix it up).
This worries me. I'm no x86 guru, but I assume the trampoline's setting of
the TF bit will kick in right around the following 'ret'. So the
application will stop and GDB won't be able to read the instruction at
PC. I bet that makes it unhappy.
Shouldn't be that hard to fix this up in ptrace, though.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: [LARTC] HTB steals bandwidth
From: Mr. Adam ALLEN @ 2002-12-20 0:50 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104005823313721@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
On Thu, 2002-12-19 at 08:08, Robert Brueckmann wrote:
<SNIPPED>
> The ftp-data-port rule works for all active ftp-connections, and the packet
> dounter of the rule increases just as I expected.
>
> Any ideas, why the rate crashes down with these rules? May the
> processor-power be the problem? The router is a Pentium-200, 64mb ram.
>
I'm running HTB to split 512Kb DSL connection between two people, and it
seems to be working as expected... I can't remember any figures - but
never had reason for concern.
This is a P166 (no MMX), and 96Mb memory, and has NFS/HTTP/MYSQL
happening much of the time.
--
NAME : Adam Allen.
EMAIL : adam@dynamicinteraction.co.uk
COMMENT : ~~~~ insert your favourite signature comment here ~~~~
PGP : http://search.keyserver.net:11371/pks/lookup?op=vindex&search=adam%40dynamicinteraction.co.uk
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: raid5 multi-drive-failure and recovery?
From: Neil Brown @ 2002-12-20 0:59 UTC (permalink / raw)
To: Dan Merillat; +Cc: linux-kernel
In-Reply-To: <200212200049.gBK0n5NS016297@chaos.ao.net>
On Thursday December 19, harik@chaos.ao.net wrote:
>
> I've got a problem. Two drives in my array developed bad sectors at
> the same time. They're in completely different places, but I can't
> read the disk because md simply fails out both of them, and marks the
> array unusable.
>
> Now, I can either buy new drives and dd the raw partition over, or I
> can hack the kernel to make it a bit smarter about unrecoverable
> reads.
>
> Obviously, if I have raid5_error not mark the drive bad, it will hammer
> away on it, failing over and over. My thought was to let the read
> fail, catch it in raid5_end_read_request then tag the stripe_head
> with the device that's failed. If one has already failed, return
> EIO. This way further reads on the stripe_head will go to the parity
> disk (until it's eventually freed. One IO error per stripe isn't too
> harsh a price to pay for disaster recovery)
>
> in 2.4.20, I'm at raid5.c:421 where we're about to call md_error.
> What happens to the bh from that point? Obviously, it's not up-to-date,
> so when 1 drive fails how does it get re-issued to be pulled from a parity
> drive to reconstruct it?
Nothing much happens to the bh. It just has Uptodate cleared.
A little later (line 433) we call release_stripe. Once all the active
IO requests have finished the stripe will be completely released and
handle_stripe gets called (from raid5d) to handle the stripe.
It notices there is a block that is being read (bh_read) but that
isn't uptodate, and so tries to schedule a read. Line 949 notices
that the block it wants to read is on a failed drive, so it causes all
blocks to be read in. Once they are read in, handle_stripe gets
called again, and this time it gets to line 955 where it computes the
block that you want.
What you want to do is add a 'failed_drive' field to the stripe_head
which gets initialised to -1 in init_stripe, and set at line 421
instead of calling md_error. Then in handle_stripe, line 875 changes
from
if (!conf->disks[i].operational) {
to
if (!conf->disks[i].operational || sh->failed_drive == i) {
and it might just work for you.
Good luck
NeilBrown
^ permalink raw reply
* [PATCH] [2.4.21-pre2] scx200 build fix
From: Jörg Prante @ 2002-12-20 0:58 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 233 bytes --]
Hi,
this patch solves the problem reported by Eyal Lebedinsky.
It moves scx200.c from arch/i386/kernel to drivers/char directory and adjusts
the Makefile accordingly. Marcelo, can you please apply?
Best regards,
Jörg
[-- Attachment #2: 001_scx200-fix --]
[-- Type: text/x-diff, Size: 7202 bytes --]
--- linux/drivers/char/Makefile 2002-12-10 20:22:56.000000000 +0000
+++ linux/drivers/char/Makefile 2002-12-10 20:22:01.000000000 +0000
@@ -254,7 +254,7 @@
obj-$(CONFIG_DZ) += dz.o
obj-$(CONFIG_NWBUTTON) += nwbutton.o
obj-$(CONFIG_NWFLASH) += nwflash.o
-obj-$(CONFIG_SCx200_GPIO) += scx200_gpio.o
+obj-$(CONFIG_SCx200_GPIO) += scx200_gpio.o scx200.o
# Only one watchdog can succeed. We probe the hardware watchdog
# drivers first, then the softdog driver. This means if your hardware
--- linux/drivers/char/scx200.c 1970-01-01 00:00:00.000000000 +0000
+++ linux/drivers/char/scx200.c 2002-12-10 20:22:10.000000000 +0000
@@ -0,0 +1,128 @@
+/* linux/drivers/char/scx200.c
+
+ Copyright (c) 2001,2002 Christer Weinigel <wingel@nano-system.com>
+
+ National Semiconductor SCx200 support. */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+
+#include <linux/scx200.h>
+#include <linux/scx200.h>
+
+#define NAME "scx200"
+
+MODULE_AUTHOR("Christer Weinigel <wingel@nano-system.com>");
+MODULE_DESCRIPTION("NatSemi SCx200 Driver");
+MODULE_LICENSE("GPL");
+
+unsigned scx200_gpio_base = 0;
+long scx200_gpio_shadow[2];
+
+spinlock_t scx200_gpio_lock = SPIN_LOCK_UNLOCKED;
+static spinlock_t scx200_gpio_config_lock = SPIN_LOCK_UNLOCKED;
+
+u32 scx200_gpio_configure(int index, u32 mask, u32 bits)
+{
+ u32 config, new_config;
+ unsigned long flags;
+
+ spin_lock_irqsave(&scx200_gpio_config_lock, flags);
+
+ outl(index, scx200_gpio_base + 0x20);
+ config = inl(scx200_gpio_base + 0x24);
+
+ new_config = (config & mask) | bits;
+ outl(new_config, scx200_gpio_base + 0x24);
+
+ spin_unlock_irqrestore(&scx200_gpio_config_lock, flags);
+
+ return config;
+}
+
+void scx200_gpio_dump(unsigned index)
+{
+ u32 config = scx200_gpio_configure(index, ~0, 0);
+ printk(KERN_DEBUG "GPIO%02u: 0x%08lx", index, (unsigned long)config);
+
+ if (config & 1)
+ printk(" OE"); /* output enabled */
+ else
+ printk(" TS"); /* tristate */
+ if (config & 2)
+ printk(" PP"); /* push pull */
+ else
+ printk(" OD"); /* open drain */
+ if (config & 4)
+ printk(" PUE"); /* pull up enabled */
+ else
+ printk(" PUD"); /* pull up disabled */
+ if (config & 8)
+ printk(" LOCKED"); /* locked */
+ if (config & 16)
+ printk(" LEVEL"); /* level input */
+ else
+ printk(" EDGE"); /* edge input */
+ if (config & 32)
+ printk(" HI"); /* trigger on rising edge */
+ else
+ printk(" LO"); /* trigger on falling edge */
+ if (config & 64)
+ printk(" DEBOUNCE"); /* debounce */
+ printk("\n");
+}
+
+int __init scx200_init(void)
+{
+ struct pci_dev *bridge;
+ int bank;
+ unsigned base;
+
+ printk(KERN_INFO NAME ": NatSemi SCx200 Driver\n");
+
+ if ((bridge = pci_find_device(PCI_VENDOR_ID_NS,
+ PCI_DEVICE_ID_NS_SCx200_BRIDGE,
+ NULL)) == NULL)
+ return -ENODEV;
+
+ base = pci_resource_start(bridge, 0);
+ printk(KERN_INFO NAME ": GPIO base 0x%x\n", base);
+
+ if (request_region(base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO") == 0) {
+ printk(KERN_ERR NAME ": can't allocate I/O for GPIOs\n");
+ return -EBUSY;
+ }
+
+ scx200_gpio_base = base;
+
+ /* read the current values driven on the GPIO signals */
+ for (bank = 0; bank < 2; ++bank)
+ scx200_gpio_shadow[bank] = inl(scx200_gpio_base + 0x10 * bank);
+
+ return 0;
+}
+
+void __exit scx200_cleanup(void)
+{
+ release_region(scx200_gpio_base, SCx200_GPIO_SIZE);
+}
+
+module_init(scx200_init);
+module_exit(scx200_cleanup);
+
+EXPORT_SYMBOL(scx200_gpio_base);
+EXPORT_SYMBOL(scx200_gpio_shadow);
+EXPORT_SYMBOL(scx200_gpio_lock);
+EXPORT_SYMBOL(scx200_gpio_configure);
+EXPORT_SYMBOL(scx200_gpio_dump);
+
+/*
+ Local variables:
+ compile-command: "make -k -C ../../.. SUBDIRS=arch/i386/kernel modules"
+ c-basic-offset: 8
+ End:
+*/
--- linux/arch/i386/kernel/scx200.c 1970-01-01 00:00:00.000000000 +0000
+++ linux/arch/i386/kernel/scx200.c 2002-12-10 20:22:10.000000000 +0000
@@ -1,128 +0,0 @@
-/* linux/arch/i386/kernel/scx200.c
-
- Copyright (c) 2001,2002 Christer Weinigel <wingel@nano-system.com>
-
- National Semiconductor SCx200 support. */
-
-#include <linux/config.h>
-#include <linux/module.h>
-#include <linux/errno.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/pci.h>
-
-#include <linux/scx200.h>
-#include <linux/scx200.h>
-
-#define NAME "scx200"
-
-MODULE_AUTHOR("Christer Weinigel <wingel@nano-system.com>");
-MODULE_DESCRIPTION("NatSemi SCx200 Driver");
-MODULE_LICENSE("GPL");
-
-unsigned scx200_gpio_base = 0;
-long scx200_gpio_shadow[2];
-
-spinlock_t scx200_gpio_lock = SPIN_LOCK_UNLOCKED;
-static spinlock_t scx200_gpio_config_lock = SPIN_LOCK_UNLOCKED;
-
-u32 scx200_gpio_configure(int index, u32 mask, u32 bits)
-{
- u32 config, new_config;
- unsigned long flags;
-
- spin_lock_irqsave(&scx200_gpio_config_lock, flags);
-
- outl(index, scx200_gpio_base + 0x20);
- config = inl(scx200_gpio_base + 0x24);
-
- new_config = (config & mask) | bits;
- outl(new_config, scx200_gpio_base + 0x24);
-
- spin_unlock_irqrestore(&scx200_gpio_config_lock, flags);
-
- return config;
-}
-
-void scx200_gpio_dump(unsigned index)
-{
- u32 config = scx200_gpio_configure(index, ~0, 0);
- printk(KERN_DEBUG "GPIO%02u: 0x%08lx", index, (unsigned long)config);
-
- if (config & 1)
- printk(" OE"); /* output enabled */
- else
- printk(" TS"); /* tristate */
- if (config & 2)
- printk(" PP"); /* push pull */
- else
- printk(" OD"); /* open drain */
- if (config & 4)
- printk(" PUE"); /* pull up enabled */
- else
- printk(" PUD"); /* pull up disabled */
- if (config & 8)
- printk(" LOCKED"); /* locked */
- if (config & 16)
- printk(" LEVEL"); /* level input */
- else
- printk(" EDGE"); /* edge input */
- if (config & 32)
- printk(" HI"); /* trigger on rising edge */
- else
- printk(" LO"); /* trigger on falling edge */
- if (config & 64)
- printk(" DEBOUNCE"); /* debounce */
- printk("\n");
-}
-
-int __init scx200_init(void)
-{
- struct pci_dev *bridge;
- int bank;
- unsigned base;
-
- printk(KERN_INFO NAME ": NatSemi SCx200 Driver\n");
-
- if ((bridge = pci_find_device(PCI_VENDOR_ID_NS,
- PCI_DEVICE_ID_NS_SCx200_BRIDGE,
- NULL)) == NULL)
- return -ENODEV;
-
- base = pci_resource_start(bridge, 0);
- printk(KERN_INFO NAME ": GPIO base 0x%x\n", base);
-
- if (request_region(base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO") == 0) {
- printk(KERN_ERR NAME ": can't allocate I/O for GPIOs\n");
- return -EBUSY;
- }
-
- scx200_gpio_base = base;
-
- /* read the current values driven on the GPIO signals */
- for (bank = 0; bank < 2; ++bank)
- scx200_gpio_shadow[bank] = inl(scx200_gpio_base + 0x10 * bank);
-
- return 0;
-}
-
-void __exit scx200_cleanup(void)
-{
- release_region(scx200_gpio_base, SCx200_GPIO_SIZE);
-}
-
-module_init(scx200_init);
-module_exit(scx200_cleanup);
-
-EXPORT_SYMBOL(scx200_gpio_base);
-EXPORT_SYMBOL(scx200_gpio_shadow);
-EXPORT_SYMBOL(scx200_gpio_lock);
-EXPORT_SYMBOL(scx200_gpio_configure);
-EXPORT_SYMBOL(scx200_gpio_dump);
-
-/*
- Local variables:
- compile-command: "make -k -C ../../.. SUBDIRS=arch/i386/kernel modules"
- c-basic-offset: 8
- End:
-*/
^ permalink raw reply
* [Linux-ia64] Re: ia64 cache flushing?
From: Richard Henderson @ 2002-12-20 0:56 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805582@msgid-missing>
On Thu, Dec 19, 2002 at 03:15:49PM -0800, David Mosberger wrote:
> Rich> No it isn't. Find me the address of the stub.
>
> After you're done applying relocations, what stops you from going
> through all PLTs and patching them to use "brl"?
You're not listening. WHERE ARE THEY? You don't have their address.
You only have the address of the descriptor that they use.
r~
^ permalink raw reply
* linuxppc_2_4_devel patch: 8xx commproc extensions
From: Wolfgang Denk @ 2002-12-20 1:00 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
Hi,
this is a patch against linuxppc_2_4_devel BK Changeset 1.1197
(trini@kernel.crashing.org|ChangeSet|20021219180614|11718)
It adds support for SPI and RISC timers to the MPC8xx commproc.h file.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
The perversity of nature is nowhere better demonstrated by the fact
that, when exposed to the same atmosphere, bread becomes hard while
crackers become soft.
[-- Attachment #2: commproc.patch --]
[-- Type: application/x-patch , Size: 6694 bytes --]
^ permalink raw reply
* linuxppc_2_4_devel patch: 8xx FEC extensions
From: Wolfgang Denk @ 2002-12-20 1:05 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
Hi,
this is a patch against linuxppc_2_4_devel BK Changeset 1.1197
(trini@kernel.crashing.org|ChangeSet|20021219180614|11718)
It makes the following modifications to the MPC8xx FEC driver:
- change PHY configuration from #define to kernel config mechanism
- add support for AMD79C874 PHY
- add multicast support
- add PACKETHOOK support
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love; Love is
not music; Music is the best." - Frank Zappa
[-- Attachment #2: 8xx-fec.patch --]
[-- Type: application/x-patch , Size: 32680 bytes --]
^ permalink raw reply
* [Linux-ia64] CONFIG_SERIAL_ACPI missing??
From: Peter Chubb @ 2002-12-20 1:06 UTC (permalink / raw)
To: linux-ia64
Hi,
The options CONFIG_SERIAL_8250_ACPI and CONFIG_SERIAL_8250_HDCP appear
to have vanished in recent kernels.
Here's a patch against 2.5.45 to reinstate them.
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/drivers/serial/Kconfig linux-2.5-preempt/drivers/serial/Kconfig
--- linux-2.5-EXPORT/drivers/serial/Kconfig Fri Dec 20 11:47:23 2002
+++ linux-2.5-preempt/drivers/serial/Kconfig Thu Dec 12 11:52:33 2002
@@ -138,6 +138,23 @@
help
::: To be written :::
+config SERIAL_8250_ACPI
+ bool "Support for serial ports defined by the ACPI tables"
+ depends on SERIAL_8250 && IA64
+ help
+ Legacy free machines may not have serial ports at the legacy
+ COM1, COM2 etc addresses. Serial ports on such machines are
+ described by the ACPI tables SPCR (Serial Port Console
+ Redirection) table and DBGP (Debug Port) table. Say Y here if
+ you want to include support for these serial ports.
+
+config SERIAL_8250_HCDP
+ bool "Support for serial ports defined by the EFI HCDP"
+ depends on SERIAL_8250 && IA64
+ help
+ ::: No help yet :::
+
+
comment "Non-8250 serial port support"
config SERIAL_8250_ACORN
^ permalink raw reply
* [Linux-ia64] Re: ia64 cache flushing?
From: David Mosberger @ 2002-12-20 1:07 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805582@msgid-missing>
>>>>> On Thu, 19 Dec 2002 16:56:51 -0800, Richard Henderson <rth@twiddle.net> said:
Richard> On Thu, Dec 19, 2002 at 03:15:49PM -0800, David Mosberger
Richard> wrote:
Rich> No it isn't. Find me the address of the stub.
>> After you're done applying relocations, what stops you from
>> going through all PLTs and patching them to use "brl"?
Richard> You're not listening. WHERE ARE THEY? You don't have
Richard> their address. You only have the address of the descriptor
Richard> that they use.
They're in a section called .plt. When you load the module, you have
access to the section table, so I don't see the problem (yes, you need
to do some calculations on the section-size to figure out where the
PLTs to patch start, but that should be it).
--david
^ permalink raw reply
* Re: Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
From: darren @ 2002-12-20 1:08 UTC (permalink / raw)
To: green; +Cc: reiserfs-list
Hi!
Thanx for responding to my ques.
So, to make my reiserfs on my RedHat7.3 kernel the same one as the one in Kernel 2.4.20, all i have to do is to patch:
2.4.18-pre1.pending
2.4.18-pre2.pending
.
.
2.4.18-rc1.pending
2.4.18.pending
2.4.19
2.4.20
and so on??
-----Original Message-----
From: Oleg Drokin <green@namesys.com>
To: darren <teodarren@myrealbox.com>
Date: Thu, 19 Dec 2002 18:58:05 +0300
Subject: Re: reiserfs and TUX2 - 2.4.18 or 2.4.19?
Hello!
On Thu, Dec 19, 2002 at 11:53:49PM +0800, darren wrote:
> I want to run TUX2 to serve files off my ReiserFS partition.
> But I cannot seem to get TUX2 on kernel 2.4.19, which I would like to
> run my reiserfs partition on.
We cannot tell you anything about Tux2 because we do not know anything
about it ;)
> Should I just stick to 2.4.18 and somehow patch the reiserfs there??
If you plan to run not current 2.4 kernels, you might want to
get patches from ftp://ftp.namesys.com/pub/reiserfs-for-2.4/<version>.pending
Where <version> next kernel version. (repeat that until you reach latest
kernel).
But actually 2.4.18 is pretty stable and you may not want to patch it if you
want.
Bye,
Oleg
^ permalink raw reply
* [Linux-ia64] Another preemption supprt patch...
From: Peter Chubb @ 2002-12-20 1:14 UTC (permalink / raw)
To: linux-ia64
Hi,
In time for Christmas, here's the latest version of the
preemption-support-on-IA64 patch.
Tested on ZX2000 and I2000 UP, and simulator only.
There are some known bugs:
-- Perfmon interrupts are getting lost somewhere.
-- You need Matt Domsch's efivars.c patch posted to this list
recently.
-- There's still a problem (somewhere?) symptoms are a physical
address being used when virtual addressing is turned on (causing
an unhandleable page fault in kernel mode).
Patch against 2.5.45 plus DavidM's IA64 patch + some minor tweaks of
mine --- patch may apply with some offset hunks.
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/Kconfig linux-2.5-preempt/arch/ia64/Kconfig
--- linux-2.5-EXPORT/arch/ia64/Kconfig Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/Kconfig Fri Dec 20 10:49:34 2002
@@ -380,6 +380,18 @@
If you don't know what to do here, say N.
+config PREEMPT
+ bool "Preemptible Kernel"
+ help
+ This option reduces the latency of the kernel when reacting to
+ real-time or interactive events by allowing a low priority process to
+ be preempted even if it is in kernel mode executing a system call.
+ This allows applications to run more reliably even when the system is
+ under load.
+
+ Say Y here if you are building a kernel for a desktop, embedded
+ or real-time system. Say N if you are unsure.
+
config IA32_SUPPORT
bool "Support running of Linux/x86 binaries"
help
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/hp/sim/simserial.c linux-2.5-preempt/arch/ia64/hp/sim/simserial.c
--- linux-2.5-EXPORT/arch/ia64/hp/sim/simserial.c Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/hp/sim/simserial.c Fri Dec 20 10:49:35 2002
@@ -63,7 +63,6 @@
static char *serial_name = "SimSerial driver";
static char *serial_version = "0.6";
-static spinlock_t serial_lock = SPIN_LOCK_UNLOCKED;
/*
* This has been extracted from asm/serial.h. We need one eventually but
@@ -235,14 +234,14 @@
if (!tty || !info->xmit.buf) return;
- spin_lock_irqsave(&serial_lock, flags);
+ local_irq_save(flags);
if (CIRC_SPACE(info->xmit.head, info->xmit.tail, SERIAL_XMIT_SIZE) = 0) {
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
return;
}
info->xmit.buf[info->xmit.head] = ch;
info->xmit.head = (info->xmit.head + 1) & (SERIAL_XMIT_SIZE-1);
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
}
static _INLINE_ void transmit_chars(struct async_struct *info, int *intr_done)
@@ -250,7 +249,8 @@
int count;
unsigned long flags;
- spin_lock_irqsave(&serial_lock, flags);
+
+ local_irq_save(flags);
if (info->x_char) {
char c = info->x_char;
@@ -293,7 +293,7 @@
info->xmit.tail += count;
}
out:
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
}
static void rs_flush_chars(struct tty_struct *tty)
@@ -334,7 +334,7 @@
break;
}
- spin_lock_irqsave(&serial_lock, flags);
+ local_irq_save(flags);
{
c1 = CIRC_SPACE_TO_END(info->xmit.head, info->xmit.tail,
SERIAL_XMIT_SIZE);
@@ -344,7 +345,7 @@
info->xmit.head = ((info->xmit.head + c) &
(SERIAL_XMIT_SIZE-1));
}
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
buf += c;
count -= c;
@@ -352,7 +353,7 @@
}
up(&tmp_buf_sem);
} else {
- spin_lock_irqsave(&serial_lock, flags);
+ local_irq_save(flags);
while (1) {
c = CIRC_SPACE_TO_END(info->xmit.head, info->xmit.tail, SERIAL_XMIT_SIZE);
if (count < c)
@@ -367,7 +368,7 @@
count -= c;
ret += c;
}
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
}
/*
* Hey, we transmit directly from here in our case
@@ -398,9 +399,9 @@
struct async_struct *info = (struct async_struct *)tty->driver_data;
unsigned long flags;
- spin_lock_irqsave(&serial_lock, flags);
+ local_irq_save(flags);
info->xmit.head = info->xmit.tail = 0;
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
wake_up_interruptible(&tty->write_wait);
@@ -573,7 +574,7 @@
state->irq);
#endif
- spin_lock_irqsave(&serial_lock, flags);
+ local_irq_save(flags);
{
/*
* First unlink the serial port from the IRQ chain...
@@ -611,7 +612,7 @@
info->flags &= ~ASYNC_INITIALIZED;
}
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
}
/*
@@ -634,13 +635,13 @@
state = info->state;
- spin_lock_irqsave(&serial_lock, flags);
+ local_irq_save(flags);
if (tty_hung_up_p(filp)) {
#ifdef SIMSERIAL_DEBUG
printk("rs_close: hung_up\n");
#endif
MOD_DEC_USE_COUNT;
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
return;
}
#ifdef SIMSERIAL_DEBUG
@@ -665,11 +667,11 @@
}
if (state->count) {
MOD_DEC_USE_COUNT;
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
return;
}
info->flags |= ASYNC_CLOSING;
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
/*
* Now we wait for the transmit buffer to clear; and we notify
@@ -776,7 +778,7 @@
if (!page)
return -ENOMEM;
- spin_lock_irqsave(&serial_lock, flags);
+ local_irq_save(flags);
if (info->flags & ASYNC_INITIALIZED) {
free_page(page);
@@ -857,11 +859,11 @@
}
info->flags |= ASYNC_INITIALIZED;
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
return 0;
errout:
- spin_unlock_irqrestore(&serial_lock, flags);
+ local_irq_restore(flags);
return retval;
}
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/ia32/ia32_support.c linux-2.5-preempt/arch/ia64/ia32/ia32_support.c
--- linux-2.5-EXPORT/arch/ia64/ia32/ia32_support.c Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/ia32/ia32_support.c Fri Dec 20 10:49:35 2002
@@ -93,9 +93,8 @@
{
unsigned long eflag, fsr, fcr, fir, fdr, csd, ssd, tssd;
struct pt_regs *regs = ia64_task_regs(t);
- int nr = smp_processor_id(); /* LDT and TSS depend on CPU number: */
+ int nr = get_cpu(); /* LDT and TSS depend on CPU number: */
- nr = smp_processor_id();
eflag = t->thread.eflag;
fsr = t->thread.fsr;
@@ -121,6 +120,7 @@
regs->r17 = (_TSS(nr) << 48) | (_LDT(nr) << 32) | (__u32) regs->r17;
regs->r30 = load_desc(_LDT(nr)); /* LDTD */
+ put_cpu();
}
/*
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/kernel/entry.S linux-2.5-preempt/arch/ia64/kernel/entry.S
--- linux-2.5-EXPORT/arch/ia64/kernel/entry.S Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/kernel/entry.S Fri Dec 20 10:49:35 2002
@@ -570,11 +570,23 @@
GLOBAL_ENTRY(ia64_leave_kernel)
PT_REGS_UNWIND_INFO(0)
// work.need_resched etc. mustn't get changed by this CPU before it returns to userspace:
+.work_recheck:
(pUser) cmp.eq.unc p6,p0=r0,r0 // p6 <- pUser
+#ifdef CONFIG_PREEMPT
+ rsm psr.i // disable interrupts
+ adds r17=TI_FLAGS+IA64_TASK_SIZE,r13
+(pKern) adds r20=TI_PRE_COUNT+IA64_TASK_SIZE,r13
+ ;;
+(pKern) ld4 r21=[r20] // preempt_count ->r21
+ ;;
+(pKern) cmp4.eq p6,p0=r21,r0
+ ;;
+#else // CONFIG_PREEMPT
(pUser) rsm psr.i
;;
(pUser) adds r17=TI_FLAGS+IA64_TASK_SIZE,r13
;;
+#endif // CONFIG_PREEMPT
.work_processed:
(p6) ld4 r18=[r17] // load current_thread_info()->flags
adds r2=PT(R8)+16,r12
@@ -802,15 +814,27 @@
.work_pending:
tbit.z p6,p0=r18,TIF_NEED_RESCHED // current_thread_info()->need_resched=0?
(p6) br.cond.sptk.few .notify
+#ifdef CONFIG_PREEMPT
+(pKern) dep r21=-1,r0,PREEMPT_ACTIVE_BIT,1
+ ;;
+(pKern) st4 [r20]=r21
+(pKern) ssm psr.i // enable interrupts
+#endif
+
#if __GNUC__ < 3
br.call.spnt.many rp=invoke_schedule
#else
br.call.spnt.many rp=schedule
#endif
.ret9: cmp.eq p6,p0=r0,r0 // p6 <- 1
- rsm psr.i
+ rsm psr.i // disable interrupts
;;
adds r17=TI_FLAGS+IA64_TASK_SIZE,r13
+#if CONFIG_PREEMPT
+ adds r20=TI_PRE_COUNT+IA64_TASK_SIZE,r13
+ ;;
+ st4 [r20]=r0 // preempt_count() <- 0
+#endif
br.cond.sptk.many .work_processed // re-check
.notify:
@@ -844,7 +868,7 @@
br.cond.sptk ia64_leave_kernel
END(handle_syscall_error)
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
/*
* Invoke schedule_tail(task) while preserving in0-in7, which may be needed
* in case a system call gets restarted.
@@ -861,7 +885,7 @@
br.ret.sptk.many rp
END(ia64_invoke_schedule_tail)
-#endif /* CONFIG_SMP */
+#endif /* CONFIG_SMP || CONFIG_PREEMPT */
#if __GNUC__ < 3
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/kernel/irq.c linux-2.5-preempt/arch/ia64/kernel/irq.c
--- linux-2.5-EXPORT/arch/ia64/kernel/irq.c Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/kernel/irq.c Fri Dec 20 10:49:35 2002
@@ -340,12 +340,14 @@
* 0 return value means that this irq is already being
* handled by some other CPU. (or is disabled)
*/
- int cpu = smp_processor_id();
+ int cpu;
irq_desc_t *desc = irq_desc(irq);
struct irqaction * action;
unsigned int status;
irq_enter();
+ cpu = smp_processor_id();
+
kstat.irqs[cpu][irq]++;
if (desc->status & IRQ_PER_CPU) {
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/kernel/palinfo.c linux-2.5-preempt/arch/ia64/kernel/palinfo.c
--- linux-2.5-EXPORT/arch/ia64/kernel/palinfo.c Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/kernel/palinfo.c Fri Dec 20 10:49:35 2002
@@ -898,10 +898,12 @@
* in SMP mode, we may need to call another CPU to get correct
* information. PAL, by definition, is processor specific
*/
- if (f->req_cpu = smp_processor_id())
+ if (f->req_cpu = get_cpu())
len = (*palinfo_entries[f->func_id].proc_read)(page);
else
len = palinfo_handle_smp(f, page);
+
+ put_cpu();
if (len <= off+count) *eof = 1;
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/kernel/perfmon.c linux-2.5-preempt/arch/ia64/kernel/perfmon.c
--- linux-2.5-EXPORT/arch/ia64/kernel/perfmon.c Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/kernel/perfmon.c Fri Dec 20 10:49:35 2002
@@ -1529,6 +1529,7 @@
DBprintk(("ctx_last_cpu=%d for [%d]\n", atomic_read(&ctx->ctx_last_cpu), task->pid));
for (i = 0; i < count; i++, req++) {
+ int me;
if (__get_user(cnum, &req->reg_num)) return -EFAULT;
if (__get_user(reg_flags, &req->reg_flags)) return -EFAULT;
@@ -1549,7 +1550,8 @@
* PMU state is still in the local live register due to lazy ctxsw.
* If true, then we read directly from the registers.
*/
- if (atomic_read(&ctx->ctx_last_cpu) = smp_processor_id()){
+ me = get_cpu();
+ if (atomic_read(&ctx->ctx_last_cpu) = me){
ia64_srlz_d();
val = ia64_get_pmd(cnum);
DBprintk(("reading pmd[%u]=0x%lx from hw\n", cnum, val));
@@ -1575,6 +1577,9 @@
/* context has been saved */
val = th->pmd[cnum];
}
+
+ put_cpu();
+
if (PMD_IS_COUNTING(cnum)) {
/*
* XXX: need to check for overflow
@@ -2250,9 +2255,13 @@
pfm_enable(struct task_struct *task, pfm_context_t *ctx, void *arg, int count,
struct pt_regs *regs)
{
+ int me;
+
/* we don't quite support this right now */
if (task != current) return -EINVAL;
+ me = get_cpu(); /* make sure we're not migrated */
+
if (ctx->ctx_fl_system = 0 && PMU_OWNER() && PMU_OWNER() != current)
pfm_lazy_save_regs(PMU_OWNER());
@@ -2295,12 +2304,14 @@
SET_PMU_OWNER(task);
ctx->ctx_flags.state = PFM_CTX_ENABLED;
- atomic_set(&ctx->ctx_last_cpu, smp_processor_id());
+ atomic_set(&ctx->ctx_last_cpu, me);
/* simply unfreeze */
ia64_set_pmc(0, 0);
ia64_srlz_d();
+ put_cpu();
+
return 0;
}
@@ -2590,7 +2601,7 @@
* initialize entry header
*/
h->pid = current->pid;
- h->cpu = smp_processor_id();
+ h->cpu = get_cpu();
h->last_reset_value = ovfl_mask ? ctx->ctx_soft_pmds[ffz(~ovfl_mask)].lval : 0UL;
/*
* where did the fault happen
@@ -2625,7 +2636,7 @@
DBprintk_ovfl(("e=%p pmd%d =0x%lx\n", (void *)e, j, *e));
e++;
}
- pfm_stats[smp_processor_id()].pfm_recorded_samples_count++;
+ pfm_stats[h->cpu].pfm_recorded_samples_count++;
/*
* make the new entry visible to user, needs to be atomic
@@ -2642,9 +2653,11 @@
/*
* XXX: must reset buffer in blocking mode and lost notified
*/
- pfm_stats[smp_processor_id()].pfm_full_smpl_buffer_count++;
+ pfm_stats[h->cpu].pfm_full_smpl_buffer_count++;
+ put_cpu();
return 1;
}
+ put_cpu();
return 0;
}
@@ -2677,6 +2690,8 @@
* valid one, i.e. the one that caused the interrupt.
*/
+ preempt_disable();
+
t = &task->thread;
/*
@@ -2686,6 +2701,7 @@
if ((t->flags & IA64_THREAD_PM_VALID) = 0 && ctx->ctx_fl_system = 0) {
printk("perfmon: Spurious overflow interrupt: process %d not using perfmon\n",
task->pid);
+ preempt_enable();
return 0x1;
}
/*
@@ -2694,6 +2710,7 @@
if ((pmc0 & 0x1) = 0) {
printk("perfmon: pid %d pmc0=0x%lx assumption error for freeze bit\n",
task->pid, pmc0);
+ preempt_enable();
return 0x0;
}
@@ -2778,6 +2795,7 @@
if (ovfl_notify = 0UL) {
if (ovfl_pmds)
pfm_reset_regs(ctx, &ovfl_pmds, PFM_RELOAD_SHORT_RESET);
+ preempt_enable();
return 0x0;
}
@@ -2921,6 +2939,7 @@
DBprintk_ovfl(("return pmc0=0x%x must_block=%ld\n",
ctx->ctx_fl_frozen ? 0x1 : 0x0, t->pfm_ovfl_block_reset));
+ preempt_enable();
return ctx->ctx_fl_frozen ? 0x1 : 0x0;
}
@@ -2931,7 +2950,7 @@
struct task_struct *task;
pfm_context_t *ctx;
- pfm_stats[smp_processor_id()].pfm_ovfl_intr_count++;
+ pfm_stats[get_cpu()].pfm_ovfl_intr_count++;
/*
* srlz.d done before arriving here
@@ -2954,6 +2973,7 @@
if (!ctx) {
printk("perfmon: Spurious overflow interrupt: process %d has no PFM context\n",
task->pid);
+ put_cpu();
return;
}
#ifdef CONFIG_SMP
@@ -2991,6 +3011,7 @@
} else {
pfm_stats[smp_processor_id()].pfm_spurious_ovfl_intr_count++;
}
+ put_cpu();
}
/* for debug only */
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/kernel/smp.c linux-2.5-preempt/arch/ia64/kernel/smp.c
--- linux-2.5-EXPORT/arch/ia64/kernel/smp.c Fri Dec 20 11:46:35 2002
+++ linux-2.5-preempt/arch/ia64/kernel/smp.c Fri Dec 20 10:49:35 2002
@@ -90,7 +90,7 @@
void
handle_IPI (int irq, void *dev_id, struct pt_regs *regs)
{
- int this_cpu = smp_processor_id();
+ int this_cpu = get_cpu();
unsigned long *pending_ipis = &__get_cpu_var(ipi_operation);
unsigned long ops;
@@ -146,8 +146,12 @@
} while (ops);
mb(); /* Order data access and bit testing. */
}
+ put_cpu();
}
+/*
+ * Called with preeemption disabled
+ */
static inline void
send_IPI_single (int dest_cpu, int op)
{
@@ -155,6 +159,9 @@
platform_send_ipi(dest_cpu, IA64_IPI_VECTOR, IA64_IPI_DM_INT, 0);
}
+/*
+ * Called with preeemption disabled
+ */
static inline void
send_IPI_allbutself (int op)
{
@@ -166,6 +173,9 @@
}
}
+/*
+ * Called with preeemption disabled
+ */
static inline void
send_IPI_all (int op)
{
@@ -176,12 +186,18 @@
send_IPI_single(i, op);
}
+/*
+ * Called with preeemption disabled
+ */
static inline void
send_IPI_self (int op)
{
send_IPI_single(smp_processor_id(), op);
}
+/*
+ * Called with preeemption disabled
+ */
void
smp_send_reschedule (int cpu)
{
@@ -197,12 +213,15 @@
smp_send_reschedule_all (void)
{
int i;
+ int cpu = get_cpu(); /* disable preemption */
for (i = 0; i < NR_CPUS; i++)
- if (cpu_online(i) && i != smp_processor_id())
+ if (cpu_online(i) && i != cpu)
smp_send_reschedule(i);
+ put_cpu();
}
+
void
smp_flush_tlb_all (void)
{
@@ -228,9 +247,11 @@
{
struct call_data_struct data;
int cpus = 1;
+ int me = get_cpu(); /* prevent preemption and reschedule on another processor */
- if (cpuid = smp_processor_id()) {
+ if (cpuid = me) {
printk("%s: trying to call self\n", __FUNCTION__);
+ put_cpu();
return -EBUSY;
}
@@ -257,6 +278,7 @@
call_data = NULL;
spin_unlock_bh(&call_lock);
+ put_cpu();
return 0;
}
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/mm/fault.c linux-2.5-preempt/arch/ia64/mm/fault.c
--- linux-2.5-EXPORT/arch/ia64/mm/fault.c Fri Dec 20 11:46:36 2002
+++ linux-2.5-preempt/arch/ia64/mm/fault.c Wed Dec 18 15:26:23 2002
@@ -55,7 +55,7 @@
/*
* If we're in an interrupt or have no user context, we must not take the fault..
*/
- if (in_interrupt() || !mm)
+ if (in_atomic() || !mm)
goto no_context;
down_read(&mm->mmap_sem);
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/arch/ia64/mm/tlb.c linux-2.5-preempt/arch/ia64/mm/tlb.c
--- linux-2.5-EXPORT/arch/ia64/mm/tlb.c Fri Dec 20 11:46:36 2002
+++ linux-2.5-preempt/arch/ia64/mm/tlb.c Fri Dec 20 10:49:36 2002
@@ -81,9 +81,13 @@
}
read_unlock(&tasklist_lock);
/* can't call flush_tlb_all() here because of race condition with O(1) scheduler [EF] */
- for (i = 0; i < NR_CPUS; ++i)
- if (i != smp_processor_id())
- per_cpu(ia64_need_tlb_flush, i) = 1;
+ {
+ int cpu = get_cpu(); /* prevent preemption/migration */
+ for (i = 0; i < NR_CPUS; ++i)
+ if (i != cpu)
+ per_cpu(ia64_need_tlb_flush, i) = 1;
+ put_cpu();
+ }
__flush_tlb_all();
}
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/include/asm-ia64/hardirq.h linux-2.5-preempt/include/asm-ia64/hardirq.h
--- linux-2.5-EXPORT/include/asm-ia64/hardirq.h Fri Dec 20 11:47:33 2002
+++ linux-2.5-preempt/include/asm-ia64/hardirq.h Fri Dec 20 10:51:04 2002
@@ -83,13 +83,13 @@
#define hardirq_trylock() (!in_interrupt())
#define hardirq_endlock() do { } while (0)
-#define in_atomic() (preempt_count() != 0)
#define irq_enter() (preempt_count() += HARDIRQ_OFFSET)
#if CONFIG_PREEMPT
-# error CONFIG_PREEMT currently not supported.
+# define in_atomic() ((preempt_count() & ~PREEMPT_ACTIVE) != kernel_locked())
# define IRQ_EXIT_OFFSET (HARDIRQ_OFFSET-1)
#else
+# define in_atomic() (preempt_count() != 0)
# define IRQ_EXIT_OFFSET HARDIRQ_OFFSET
#endif
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/include/asm-ia64/system.h linux-2.5-preempt/include/asm-ia64/system.h
--- linux-2.5-EXPORT/include/asm-ia64/system.h Fri Dec 20 11:47:34 2002
+++ linux-2.5-preempt/include/asm-ia64/system.h Fri Dec 20 10:51:05 2002
@@ -380,7 +380,7 @@
#ifdef CONFIG_PERFMON
DECLARE_PER_CPU(int, pfm_syst_wide);
-# define PERFMON_IS_SYSWIDE() (get_cpu_var(pfm_syst_wide) != 0)
+# define PERFMON_IS_SYSWIDE() (__get_cpu_var(pfm_syst_wide) != 0)
#else
# define PERFMON_IS_SYSWIDE() (0)
#endif
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/include/asm-ia64/thread_info.h linux-2.5-preempt/include/asm-ia64/thread_info.h
--- linux-2.5-EXPORT/include/asm-ia64/thread_info.h Fri Dec 20 11:47:34 2002
+++ linux-2.5-preempt/include/asm-ia64/thread_info.h Fri Dec 20 10:48:37 2002
@@ -15,7 +15,8 @@
#define TI_ADDR_LIMIT 0x10
#define TI_PRE_COUNT 0x18
-#define PREEMPT_ACTIVE 0x4000000
+#define PREEMPT_ACTIVE_BIT 26
+#define PREEMPT_ACTIVE (1<<PREEMPT_ACTIVE_BIT)
#ifndef __ASSEMBLY__
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.5-EXPORT/kernel/sched.c linux-2.5-preempt/kernel/sched.c
--- linux-2.5-EXPORT/kernel/sched.c Fri Dec 20 11:47:43 2002
+++ linux-2.5-preempt/kernel/sched.c Fri Dec 20 10:45:53 2002
@@ -962,7 +962,7 @@
*/
if (likely(current->state != TASK_ZOMBIE)) {
if (unlikely(in_atomic())) {
- printk(KERN_ERR "bad: scheduling while atomic!\n");
+ printk(KERN_ERR "bad: scheduling while atomic! (preempt_count = %d)\n", preempt_count());
dump_stack();
}
}
@@ -2167,6 +2167,9 @@
prev_jiffy = jiffies;
printk(KERN_ERR "Debug: sleeping function called from illegal"
" context at %s:%d\n", file, line);
+ printk(KERN_ERR "Debug: lock_depth = %d, preempt_count=%d\n",
+ current->lock_depth,
+ preempt_count() & ~PREEMPT_ACTIVE);
dump_stack();
}
#endif
^ permalink raw reply
* [Linux-ia64] Re: ia64 cache flushing?
From: Richard Henderson @ 2002-12-20 1:18 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805582@msgid-missing>
On Thu, Dec 19, 2002 at 05:07:54PM -0800, David Mosberger wrote:
> They're in a section called .plt.
Oh, you're talking about modules. I was still talking about ld.so.
r~
^ permalink raw reply
* [Linux-ia64] Re: ia64 cache flushing?
From: David Mosberger @ 2002-12-20 1:20 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805582@msgid-missing>
>>>>> On Thu, 19 Dec 2002 17:18:07 -0800, Richard Henderson <rth@twiddle.net> said:
Rich> On Thu, Dec 19, 2002 at 05:07:54PM -0800, David Mosberger
Rich> wrote:
>> They're in a section called .plt.
Rich> Oh, you're talking about modules. I was still talking about
Rich> ld.so.
Yep. I agree it's a different issue in general, but for kernel
modules, it should be fine (and worthwhile).
--david
^ permalink raw reply
* need for benchmarking system?
From: grobe @ 2002-12-20 1:20 UTC (permalink / raw)
To: reiserfs-list
Hi List!
As we are going to get a quite big new server in january, and as I have
taken a lot of advantage from the reiserfs development, I wonder if I could
contribute a bit by making a "reiserfs-large-server-test-day"?
The system will be a redundant fibrechannel storage with two dual processor
systems, about 2 Terabytes raid5. I am going to install SuSE ES8 (I usually
install on LVM).
If the reiserfs-team thinks this could be useful, please tell me the
configuration you need (e.g. kernel 2.4.xx, 2.5.xx, reiserfs 3.xx or 4?) and how we
should do this (benchmark scripts etc), I will try to get the specs of the
system and see how to put this into the schedule.
If there's no need, it just has been a silly idea of mine ;-) In fact, it's
not so altruistic... I'm quite sure there will be running some reiser
filesystems on the machine in the near future ;-)))
CU Lars.
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
^ permalink raw reply
* Re: [drm:drm_init] *ERROR* Cannot initialize the agpgart module.
From: Matt Bernstein @ 2002-12-20 1:30 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Paul P Komkoff Jr, linux-kernel, Dave Jones, Rusty Russell
In-Reply-To: <20021217125013.29A57B63@oscar.casa.dyndns.org>
On Dec 17 Ed Tomlinson wrote:
>Not normally. If I modprobe via-agp modprobe segfaults (a Rusty's bug),
>but via_agp and agpgart get loaded (note that - changed to _ when the module
>is loaded - it has dash in file in the directory). Doing it this time gets
>an oops (52bk as of last night):
[snip]
I get a very similar oops, but with amd_k7_agp (2.5.52-mm2). I'm not
bk-savvy as yet, but if pointed at a diff, would be happy to verify it.
Matt
^ permalink raw reply
* Re: [drm:drm_init] *ERROR* Cannot initialize the agpgart module.
From: Randy.Dunlap @ 2002-12-20 1:43 UTC (permalink / raw)
To: Matt Bernstein
Cc: Ed Tomlinson, Paul P Komkoff Jr, linux-kernel, Dave Jones,
Rusty Russell
In-Reply-To: <Pine.LNX.4.51.0212200127001.877@jester.mews>
On Fri, 20 Dec 2002, Matt Bernstein wrote:
| On Dec 17 Ed Tomlinson wrote:
|
| >Not normally. If I modprobe via-agp modprobe segfaults (a Rusty's bug),
| >but via_agp and agpgart get loaded (note that - changed to _ when the module
| >is loaded - it has dash in file in the directory). Doing it this time gets
| >an oops (52bk as of last night):
| [snip]
|
| I get a very similar oops, but with amd_k7_agp (2.5.52-mm2). I'm not
| bk-savvy as yet, but if pointed at a diff, would be happy to verify it.
2.5.zz kernel diff snapshots (from bk) are available at
http://www.kernel.org/pub/linux/kernel/v2.5/snapshots/
e.g., latest is:
http://www.kernel.org/pub/linux/kernel/v2.5/snapshots/patch-2.5.52-bk4.bz2
--
~Randy
^ permalink raw reply
* Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
From: Nuno Silva @ 2002-12-20 1:47 UTC (permalink / raw)
To: Torben Frey; +Cc: linux kernel mailing list
In-Reply-To: <3E01D7D7.2070201@mailsammler.de>
Hello!
Torben Frey wrote:
[..snip..]
> watching "vmstat 1" in another window - and this is what surprised me:
> when I stopped the copy job, there were 22 more seconds when data was
> still written to the backup software raid. Is this a hint where the
> problem could be? I have the same "feature" when I write to my 3ware.
>
[..snip..]
AFAIK, this is because you have some GB of memory (RAM) that are beeing
used as disk-cache. It took 22 seconds for the cached writes-to-disk
being flushed to the device.
If 22 seconds is too much for the amount of cached disk-writes is
another story :)
Maybe 3ware controllers are slow with many disks? Try the same with only
3 disks to eliminate this variable.
Regards,
Nuno Silva
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.