Re: Relayfs question

[Theodore Ts'o]

On Sat, Mar 19, 2005 at 10:08:13PM +0100, Jan Engelhardt wrote:
> 
> Well, what about things like urandom? It also moves "a lot" of data and does
> nothing else.
> 

If you're using urandom to move "a lot" of data, you're using it
wrong.  That's not what it is supposed to be for; I can't think of a
valid use of /dev/urandom that would use more than, say, 256 bytes
(2048 bits), and most sanely written users of /dev/urandom only need
16 bytes (i.e., 128 bits).  Anything more than that, and you should be
using a userpsace PRNG or CRNG, and **not** /dev/urandom.

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

Re: forkbombing Linux distributions

[Jan Engelhardt]

>>William> Sure enough, I created the following script and ran it as a
>>William> non-root user:
>>
>>William> #!/bin/bash $0 & $0 &
>>
>>There are two approaches to fixing this.
>>  1.  Rate limit fork()
>>  2.  Limit (per user) the number of processes allowed
>
>Had to try it out of curiosity, five ssh logins at the time, 
>but I hit Ctrl-S on the terminal running forkbomb, then other 
>terminals responsive and I could recover, do 'killall forkbomb'.

By the time you killed a handful of procs, the other half spawned new ones.

You can try stopping forkbombs by "killall -STOP nameofprog" and then 
"killall -9 nameofprog".

But you probably won't get to run killall in case of a thrasher running within 
the limits of `ulimit -m` and `ulimit -u`:
  perl -e 'fork,$_="x"x 10E6 while 1'


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

Re: [PATCH] NMI handler message passing / work deferral API

[Dave Peterson]

Ok, one more try... This time my email client is set to "no word-wrap".
Now the patch should apply cleanly.  Sorry about the mistake...

Dave


diff -urNp -X dontdiff linux-2.6.11.5/arch/i386/defconfig 
linux-2.6.11.5-nmi/arch/i386/defconfig
--- linux-2.6.11.5/arch/i386/defconfig  2005-03-18 22:35:00.0 -0800
+++ linux-2.6.11.5-nmi/arch/i386/defconfig  2005-03-20 09:37:36.0 
-0800
@@ -101,6 +101,7 @@ CONFIG_X86_TSC=y
 CONFIG_X86_MCE=y
 CONFIG_X86_MCE_NONFATAL=y
 CONFIG_X86_MCE_P4THERMAL=y
+# CONFIG_NMI_EXTENDED is not set
 # CONFIG_TOSHIBA is not set
 # CONFIG_I8K is not set
 # CONFIG_MICROCODE is not set
diff -urNp -X dontdiff linux-2.6.11.5/arch/i386/Kconfig 
linux-2.6.11.5-nmi/arch/i386/Kconfig
--- linux-2.6.11.5/arch/i386/Kconfig2005-03-18 22:34:52.0 -0800
+++ linux-2.6.11.5-nmi/arch/i386/Kconfig2005-03-20 09:37:36.0 
-0800
@@ -610,6 +610,13 @@ config X86_MCE_P4THERMAL
  Enabling this feature will cause a message to be printed when the P4
  enters thermal throttling.
 
+config NMI_EXTENDED
+   bool "Extended support for NMI handlers (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
+   help
+ This option provides a few things that facilitate writing kernel
+ modules that handle NMIs (nonmaskable interrupts).
+
 config TOSHIBA
tristate "Toshiba Laptop support"
---help---
diff -urNp -X dontdiff linux-2.6.11.5/arch/x86_64/defconfig 
linux-2.6.11.5-nmi/arch/x86_64/defconfig
--- linux-2.6.11.5/arch/x86_64/defconfig2005-03-18 22:35:00.0 
-0800
+++ linux-2.6.11.5-nmi/arch/x86_64/defconfig2005-03-20 09:37:36.0 
-0800
@@ -93,6 +93,7 @@ CONFIG_GART_IOMMU=y
 CONFIG_SWIOTLB=y
 CONFIG_X86_MCE=y
 CONFIG_X86_MCE_INTEL=y
+# CONFIG_NMI_EXTENDED is not set
 CONFIG_GENERIC_HARDIRQS=y
 CONFIG_GENERIC_IRQ_PROBE=y
 
diff -urNp -X dontdiff linux-2.6.11.5/arch/x86_64/Kconfig 
linux-2.6.11.5-nmi/arch/x86_64/Kconfig
--- linux-2.6.11.5/arch/x86_64/Kconfig  2005-03-18 22:35:01.0 -0800
+++ linux-2.6.11.5-nmi/arch/x86_64/Kconfig  2005-03-20 09:37:36.0 
-0800
@@ -350,6 +350,14 @@ config X86_MCE_INTEL
help
   Additional support for intel specific MCE features such as
   the thermal monitor.
+
+config NMI_EXTENDED
+   bool "Extended support for NMI handlers (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
+   help
+ This option provides a few things that facilitate writing kernel
+ modules that handle NMIs (nonmaskable interrupts).
+
 endmenu
 
 #
diff -urNp -X dontdiff linux-2.6.11.5/include/linux/nmi.h 
linux-2.6.11.5-nmi/include/linux/nmi.h
--- linux-2.6.11.5/include/linux/nmi.h  2005-03-18 22:34:49.0 -0800
+++ linux-2.6.11.5-nmi/include/linux/nmi.h  2005-03-20 19:45:58.420053288 
-0800
@@ -1,10 +1,20 @@
 /*
  *  linux/include/linux/nmi.h
+ *
+ *  NMI producer/consumer, message queue, and defer callback implementations:
+ *  Copyright (C) 2005  The Regents of the University of California.
+ *  Produced at the Lawrence Livermore National Laboratory.
+ *  Written by David S. Peterson <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>.
+ *  All rights reserved.
+ *  See preamble notice and terms and conditions in kernel/nmi.c.
  */
 #ifndef LINUX_NMI_H
 #define LINUX_NMI_H
 
+#include 
+#include 
 #include 
+#include 
 
 /**
  * touch_nmi_watchdog - restart NMI watchdog timeout.
@@ -19,4 +29,195 @@ extern void touch_nmi_watchdog(void);
 # define touch_nmi_watchdog() do { } while(0)
 #endif
 
+#ifdef CONFIG_NMI_EXTENDED
+
+/* NMI producer/consumer interface.  This is a bare-bones mechanism for
+ * passing information from NMI handlers to other parts of the kernel in a
+ * manner that is free from deadlocks and race conditions.  For most purposes
+ * you will probably want to use the NMI message queue interface rather than
+ * directly accessing the producer/consumer mechanism.
+ */
+
+/* NMI producer/consumer data structure.  For SMP safety, use one of these for
+ * each CPU and be sure preemption is disabled before accessing.
+ */
+typedef struct {
+   /* containers for info to be passed fromm NMI handler */
+   void *container[2];
+
+   /* boolean flags are set if containers are not empty */
+   volatile int has_items[2];
+
+   int active_container_nr;  /* container for NMI handler to use */
+} nmi_producer_consumer_t;
+
+/* Initialize an nmi_producer_consumer_t object.  container0 and container1
+ * point to a pair of containers for storing the information we wish to
+ * transfer from the NMI handler.
+ */
+static inline void nmi_producer_consumer_init
+   (nmi_producer_consumer_t *p, void *container0,
+void *container1)
+{
+   p->container[0] = container0;
+   p->container[1] = container1;
+   p->has_items[0] = 0;
+   p->has_items[1] = 0;
+   p->active_container_nr = 0;
+}
+
+/* The producer (NMI handler) calls this function to obtain a container to
+ 

Re: USB mouse hiccups (was RFD: Kernel release numbering)

[Andrew Morton]

viking <[EMAIL PROTECTED]> wrote:
>
> On Sun, Mar 20, 2005 at 04:41:29PM -0800, Andrew Morton wrote:
> > viking <[EMAIL PROTECTED]> wrote:
> > >
> > > I did note something strange. I'm running 2.6.11.2 at this moment, when I
> > >  tried 2.6.11.3, my USB Microsoft Wireless Optical Mouse stopped moving
> > >  from left to right, and would only move up and down if I physically moved
> > >  the mouse from left to right. I didn't see anything in the patches that
> > >  touched anything in the event handling, so frankly I'm puzzled.
> > >  Any clues as to where I need to look? I've seen this problem before, but
> > >  don't know what causes it, nor how I fixed it at the time.
> > >  Also, how do I get that patch that enables the tiltwheel (left-right
> > >  events)?
> > 
> > Could you please test 2.6.12-rc1?
> 
> Got it compiled this evening. How many days do you want me to run it for? A
> week?

Well it should take about seven seconds to work out if the mouse movement
is still broken?

> Can I test out the suspend-to-disk on this release too?

Please do.

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

Re: Kernel hiccups (was USB Mouse Hiccups)

[Jan Engelhardt]

>-meat-
>> I've also noted .10 is quicker off the blocks than 2.6.11 seems to be.
>
>Namely seems to happen around the times when I'm doing something like
>mounting devfs (takes nearly 30 secs), and when I'm accessing files from
>disc (bash$ less some-random-file.txt) - this can take about two seconds
>for Linux to actually notice I've done something. I've no idea where the
>error is here, either. i.e. is bash waiting around for me? is the
>filesystem code waiting for some reason? Is the kernel in a tailspin?
>[shrug]

Use sysrq+t and see where it "hangs".


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

Re: USB mouse hiccups (was RFD: Kernel release numbering)

[viking]

On Sun, Mar 20, 2005 at 04:41:29PM -0800, Andrew Morton wrote:
> viking <[EMAIL PROTECTED]> wrote:
> >
> > I did note something strange. I'm running 2.6.11.2 at this moment, when I
> >  tried 2.6.11.3, my USB Microsoft Wireless Optical Mouse stopped moving
> >  from left to right, and would only move up and down if I physically moved
> >  the mouse from left to right. I didn't see anything in the patches that
> >  touched anything in the event handling, so frankly I'm puzzled.
> >  Any clues as to where I need to look? I've seen this problem before, but
> >  don't know what causes it, nor how I fixed it at the time.
> >  Also, how do I get that patch that enables the tiltwheel (left-right
> >  events)?
> 
> Could you please test 2.6.12-rc1?

Got it compiled this evening. How many days do you want me to run it for? A
week? Can I test out the suspend-to-disk on this release too?

Thanks for your attention on this.

-- 
 /|   _,.:*^*:.,   |\  Cheers from the Viking family, including Pippin, our cat
| |_/'  viking@ `\_| |
|flying-brick| $FunnyMail   : What do you mean, I've lost the plot?
 \_.caverock.net.nz_/ 5.40  : I planted them carrots right here!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA Promise TX4 Crash

[Brad Campbell]

Neil Whelchel wrote:
Hello,
I have two Promise SATA TX4 cards connected to a total of 6 Maxtor 250 GB
drives (7Y250M0) configured into a RAID 5. All works well with small
disk load, but when a large number of requests are issued, it causes crash
similar to the attached, except that the errors before the crash are on a

EFLAGS: 00010046   (2.6.11.2)
EIP is at scsi_put_command+0xbb/0x100
Oooh Oooh Oooh, pick me Mr Kotter!
I have seen this repeatedly, fought it and "apparently" beat it by upgrading my 
PSU.
I could reliably reproduce it by running a raid resync and issuing SMART queries
to the drives, but after a PSU upgrade it has gone away.
I have tried hard to reproduce it recently but I just can't get it to crash 
anymore.
I have a similar setup 4x SATA-TX4 cards and 15x 7Y250M0 drives. I'm thought it 
was actually
a bug, but as I can't reproduce it anymore it's making it a bit hard to track 
down.
Not much help, sorry.
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fuse is cool and robust

[bert hubert]

On Sun, Mar 20, 2005 at 10:55:15PM +0100, Jan Engelhardt wrote:

> encfs being hard from kernel space? I've seen a whole cryptoloop in the 
> kernel. Can't be "hard". At least unpracticable.

encfs is not cryptoloop - please follow the URL.

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Major problem with PCMCIA/Yenta system

[Jonas Oreland]

Hi,
I recently had a similar problem, but with a netgear-wg511t
However, a kind gentleman called [EMAIL PROTECTED] supplied with me a patch that
solved the problem.
Not sure if it will work with your card, but you can always try.
You should find it on this list, 
 thread topic is "yenta_socket "nobody cared - Disabling IRQ #4""

/Jonas
Ron Gage wrote:
Greetings:
I have been trying to get a recently acquired Cardbus based USB 2.0 card 
working under 2.6 for the past weekend.  It's not going well.

Everytime I plug the card into the computer, the entire PCMCIA system just 
dies, taking my network connectivity with it.  I have to do a power off reset 
to recover.

The cardbus card is based on the ALI USB chipset.  This shows up as both an 
EHCI and an OHCI device under 2.6.11.5.  My laptop, an older HP Pavilion 
N5150 has a UHCI based chipset:

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 
03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 
03)
00:04.0 CardBus bridge: Texas Instruments PCI1420
00:04.1 CardBus bridge: Texas Instruments PCI1420
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:08.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12)
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
02:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)

My ethernet card is a generic cardbus device.
When I insert the new USB 2.0 card, the kernel reports that it's killing off 
IRQ 11.  Here is the actual dump from dmesg:

Mar 20 18:38:13 port2 kernel: irq 11: nobody cared!
Mar 20 18:38:13 port2 kernel:  [] __report_bad_irq+0x2a/0xa0
Mar 20 18:38:13 port2 kernel:  [] handle_IRQ_event+0x30/0x70
Mar 20 18:38:13 port2 kernel:  [] note_interrupt+0x70/0xb0
Mar 20 18:38:13 port2 kernel:  [] __do_IRQ+0xe1/0xf0
Mar 20 18:38:13 port2 kernel:  [] do_IRQ+0x19/0x30
Mar 20 18:38:13 port2 kernel:  [] common_interrupt+0x1a/0x20
Mar 20 18:38:13 port2 kernel:  [] __do_softirq+0x2e/0xa0
Mar 20 18:38:13 port2 kernel:  [] do_softirq+0x26/0x30
Mar 20 18:38:13 port2 kernel:  [] do_IRQ+0x1e/0x30
Mar 20 18:38:13 port2 kernel:  [] common_interrupt+0x1a/0x20
Mar 20 18:38:13 port2 kernel:  [] acpi_processor_idle+0x238/0x288
Mar 20 18:38:13 port2 kernel:  [] default_idle+0x0/0x30
Mar 20 18:38:13 port2 kernel:  [] cpu_idle+0x4c/0x60
Mar 20 18:38:13 port2 kernel:  [] start_kernel+0x13c/0x160
Mar 20 18:38:13 port2 kernel:  [] unknown_bootoption+0x0/0x200
Mar 20 18:38:13 port2 kernel: handlers:
Mar 20 18:38:13 port2 kernel: [] (yenta_interrupt+0x0/0x40 
[yenta_socket])
Mar 20 18:38:13 port2 kernel: [] (yenta_interrupt+0x0/0x40 
[yenta_socket])
Mar 20 18:38:13 port2 kernel: [] (tulip_interrupt+0x0/0x9c0)
Mar 20 18:38:13 port2 kernel: Disabling IRQ #11
Mar 20 18:38:14 port2 kernel: PCI: Enabling device :06:00.0 ( -> 0002)
Mar 20 18:38:14 port2 kernel: PCI: Enabling device :06:00.3 ( -> 0002)
Mar 20 18:38:16 port2 kernel: ohci_hcd :06:00.0: Unlink after no-IRQ?  
Controller is probably using the wrong IRQ.

Again, when the USB card in inserted, the entire PCMCIA system shuts down and 
remains unusuable until powered off.

Kernel is stock 2.6.11.5.  I also tried with 2.6.11, 2.6.10, 2.6.9 and 2.6.7 - 
same result.  Distribution is Slackware 9.1 - gcc is 3.2.3

HELP!!!


--
Jonas Oreland, Software Engineer
MySQL AB, www.mysql.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Suspend-to-disk woes

[Nigel Cunningham]

Hi.

On Mon, 2005-03-21 at 11:17, Matthew Garrett wrote:
> Nigel Cunningham <[EMAIL PROTECTED]> wrote:
> 
> > Yuck! Why panic when you know what is needed? A better solution is to
> > tell the user they've messed up and given them the option to (1) reboot
> > and try another kernel or (2) have swsusp restore the original swap
> > signature and continue booting. This is what suspend2 does (with a
> > timeout for the prompt). It's not that hard.
> 
> It's trivial to do this in userspace - just have an app in initramfs
> that checks for a swsusp signature, and then compare the kernel
> versions. If they mismatch, prompt for what to do. Putting it in the
> kernel is madness.

It's not that trivial.

- You need to know how to modify your initramfs to do it;
- You might have to (learn how to) set up an initramfs just for this;
- Your image might not be stored in a swap partition. For Suspend2, it
can potentially in a swap file or (soon) an ordinary file;
- Finding which partition to look in for the signature might be non
trivial (labels in fstab). You'd want to hard code it or (perferably)
copy a config file from the root (or other) partition;
- Having addressed the above issues, you still need to add code to read
the swap header, parse it to find the header, read the header from the
image, parse it and obtain the kernel version of the saved image.

If your image is not stored in a swap partition, you probably can't
mount the fs the image is stored on, because doing so will replay the
image and make resuming unsafe, so this approach is less trivial without
knowing exactly which disk blocks and device IDs to use (and using dd to
access them).

On top of these, we have two implementations, so you'll want to check
for the signatures of both.

That said, I am considering making something like what you're saying:
exposing methods of testing whether an image exists and an entry through
which you can get Suspend to erase an image via a proc (eventually
sysfs) entry. This will allow something like what you're saying to be
controlled from userspace.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net

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

[CHECKER] ext3 bug in ftruncate() with O_SYNC?

[Ben Pfaff]

Hi.  We're doing some checking on Linux file systems and found
what appears to be a bug in the Linux 2.6.11 implementation of
ext3: when ftruncate shrinks a file, using a file descriptor
opened with O_SYNC, the file size is not updated synchronously.
I've appended a test program that illustrates the problem.  After
this program runs, the file system shows a file with length 1031,
not 4 as would be expected if the ftruncate completed
synchronously.  (If I insert an fsync before closing the file,
the file length is correct.)

Does this look like a bug to you guys?

Thanks,

Ben.

--

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define CHECK(ret) if(ret < 0) {perror(0); assert(0);}

int systemf(const char *fmt, ...)
{
static char cmd[1024];

va_list ap;
va_start(ap, fmt);
vsprintf(cmd, fmt, ap);
va_end(ap);

fprintf(stderr, "running cmd \"%s\"\n", cmd);
return system(cmd);
}

main(int argc, char *argv[])
{
int ret, fd;
systemf("umount /dev/sbd0");
systemf("sbin/mkfs.ext3 -F -j -b 1024 /dev/sbd0 2048");
systemf("sbin/e2fsck.shared -y /dev/sbd0");
systemf("mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535");
systemf("umount /dev/sbd0");
systemf("mount -t ext3 /dev/sbd0 /mnt/sbd0 -o commit=65535");

fd = open("/mnt/sbd0/0001", O_CREAT | O_RDWR | O_SYNC, 0700);
CHECK(fd);
ret = write(fd, "foobar", 6);
CHECK(ret);
ret = ftruncate(fd, 1031);
CHECK(ret);
ret = pwrite(fd, "bazzle", 6, 1031 - 6);
CHECK(ret);
ret = ftruncate(fd, 4);
CHECK(ret);
ret = close(fd);
CHECK(ret);

#if 0
{
#include "../sbd/sbd.h"
int sbd_fd = open("/dev/sbd0", O_RDONLY);
ret = ioctl(sbd_fd, SBD_COPY_DISK, 1);
CHECK(ret);
close(sbd_fd);
}
#else
systemf("reboot -f -n");
#endif
return 0;
}



-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] I8K driver facelift

[Dmitry Torokhov]

Hi,

On Thursday 17 March 2005 04:46, Frank Sorenson wrote:
> Dmitry Torokhov wrote:
> | Hrm, can we be a little more explicit and not poke in the sysfs guts right
> | in the driver? What do you think about the patch below athat implements
> | "attribute arrays"? And I am attaching cumulative i8k patch using these
> | arrays so they can be tested.
> 
> Also, with power_status being a module parameter defaulting to 0/off, we
> can leave out the device_create_file for the i8k_power_status_attr.  No
> need to expose it in sysfs if it will always return -EIO.
>

Since root can toggle power_status through sysfs at runtime (see
/sys/modules/i8k/parameters/power_status) I think it is simplier to have
the file always created. 

I have implemented arrays of groups of attributes:

[EMAIL PROTECTED] ~]$ ls -R /sys/bus/platform/devices/i8k/fan/
/sys/bus/platform/devices/i8k/fan/:
0  1

/sys/bus/platform/devices/i8k/fan/0:
speed  state

/sys/bus/platform/devices/i8k/fan/1:
speed  state

Please give it a try when you have time. Thanks!

-- 
Dmitry
===

sysfs: add support for attribute arrays so it is possible to create
   a number of similar attributes all sharing the same show and
   store handlers:

  ..//0
  ..//1
   ...
  ..//

   Number of attributes can be specified at run-time.

Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 fs/sysfs/Makefile |2 
 fs/sysfs/array.c  |  162 ++
 include/linux/sysfs.h |   20 +-
 3 files changed, 182 insertions(+), 2 deletions(-)

Index: dtor/fs/sysfs/array.c
===
--- /dev/null
+++ dtor/fs/sysfs/array.c
@@ -0,0 +1,162 @@
+/*
+ * fs/sysfs/array.c - Operations for adding/removing arrays of attributes.
+ *
+ * Copyright (c) 2005 Dmitry Torokhov <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPL v2.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include "sysfs.h"
+
+struct attr_element {
+	struct attribute attr;
+	unsigned int idx;
+	char name[4];
+};
+#define to_attr_element(e)	container_of(e, struct attr_element, attr)
+
+struct attr_array {
+	const struct enumerated_attr *base_attr;
+	unsigned int n_elements;
+	struct kobject kobj;
+	struct attr_element elements[0];
+};
+#define to_attr_array(obj)	container_of(obj, struct attr_array, kobj)
+
+static ssize_t
+attr_array_show(struct kobject *kobj, struct attribute *attr, char *buf)
+{
+	struct attr_element *element = to_attr_element(attr);
+	struct attr_array *array = to_attr_array(kobj);
+	ssize_t ret = 0;
+
+	if (array->base_attr->show)
+		ret = array->base_attr->show(kobj->parent, element->idx, buf);
+
+	return ret;
+}
+
+static ssize_t
+attr_array_store(struct kobject *kobj, struct attribute *attr,
+		 const char *buf, size_t count)
+{
+	struct attr_element *element = to_attr_element(attr);
+	struct attr_array *array = to_attr_array(kobj);
+	ssize_t ret = 0;
+
+	if (array->base_attr->store)
+		ret = array->base_attr->store(kobj->parent, element->idx, buf, count);
+
+	return ret;
+}
+
+static struct sysfs_ops attr_array_sysfs_ops = {
+	.show	= attr_array_show,
+	.store	= attr_array_store,
+};
+
+static void attr_array_release(struct kobject *kobj)
+{
+	kfree(to_attr_array(kobj));
+}
+
+static struct kobj_type ktype_attr_array = {
+	.release	= attr_array_release,
+	.sysfs_ops	= _array_sysfs_ops,
+};
+
+
+static int create_array_element(struct attr_array *array,
+unsigned int idx)
+{
+	struct attr_element *element = >elements[idx];
+
+	snprintf(element->name, sizeof(element->name), "%d", idx);
+	element->idx = idx;
+	element->attr = array->base_attr->attr;
+	element->attr.name = element->name;
+
+	return sysfs_create_file(>kobj, >attr);
+}
+
+static inline void remove_array_element(struct attr_array *array,
+	unsigned int idx)
+{
+	sysfs_remove_file(>kobj, >elements[idx].attr);
+}
+
+int sysfs_create_array(struct kobject *kobj,
+		   const struct enumerated_attr *attr,
+		   unsigned int n_elements)
+{
+	struct attr_array *array;
+	size_t size;
+	unsigned int i;
+	int error;
+
+	BUG_ON(!kobj || !kobj->dentry);
+	BUG_ON(!attr_name(*attr));
+
+	if (n_elements > 999)
+		return -EINVAL;
+
+	size = sizeof(struct attr_array) +
+	   sizeof(struct attr_element) * n_elements;
+
+	array = kmalloc(size, GFP_KERNEL);
+	if (!array)
+		return -ENOMEM;
+
+	memset(array, 0, size);
+	array->base_attr = attr;
+	array->n_elements = n_elements;
+
+	array->kobj.ktype = _attr_array;
+	array->kobj.parent = kobj;
+	kobject_set_name(>kobj, attr_name(*attr));
+
+	error = kobject_register(>kobj);
+	if (error)
+		goto fail;
+
+	for (i = 0; i < n_elements; i++) {
+		error = create_array_element(array, i);
+		if (error) {
+			while (--i)
+remove_array_element(array, i);
+			goto fail;
+		}
+	}
+
+	return 0;
+
+ fail:
+	kfree(array);
+	return error;
+}
+
+void sysfs_remove_array(struct 

Re: forkbombing Linux distributions

[Grant Coady]

On Mon, 21 Mar 2005 14:27:55 +1100, Peter Chubb <[EMAIL PROTECTED]> wrote:

>> "William" == William Beebe <[EMAIL PROTECTED]> writes:
>
>William> Sure enough, I created the following script and ran it as a
>William> non-root user:
>
>William> #!/bin/bash $0 & $0 &
>
>There are two approaches to fixing this.
>  1.  Rate limit fork().  Unfortunately some legitimate usges do a lot
>  of forking, and you don't really want to slow them down.
>  2.  Limit (per user) the number of processes allowed. This is what's
>  currently done; and if you as administrator want to you can set
>  RLIMIT_NPROC in /etc/security/limits.conf
>
>On an almost-single-user system such as most desktops, there isn't much
>point in setting this.  On shared systems, it can be useful.

Had to try it out of curiosity, five ssh logins at the time, 
but I hit Ctrl-S on the terminal running forkbomb, then other 
terminals responsive and I could recover, do 'killall forkbomb'.

Even 'top' segfaulted.  Machine didn't die though.  

slackware-current running 2.4.29-hf5

Just checked logs, messages: --> kernel: VFS: file-max limit 52427 reached
nothing in syslog or debug

Cheers,
Grant.

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

[PATCH] NMI handler message passing / work deferral API

[Dave Peterson]

Below is an experimental 2.6.11.5 kernel patch that implements the
following:

 - A generic mechanism for safely passing information from NMI handlers
   to code that executes outside NMI context.
 - A message queue implementation that allows NMI handlers to queue
   messages for receipt by code that executes outside NMI context.
   This is built on top of the generic mechanism.  It includes a means
   of safely allocating and freeing message buffers for use by NMI
   handlers.
 - An API that allows NMI handlers to schedule callbacks that will
   execute outside NMI context.  This provides a means of deferring
   work from NMI handlers so that certain actions (grabbing spinlocks,
   etc.) may be performed without creating deadlocks or race
   conditions.  NMI handlers may perform the minimal amount of work
   that must be done immediately and defer everything else for
   execution outside NMI context.

My intent is to provide an API that may be used by chipset error handling
modules, kernel profiling code (i.e. oprofile), and perhaps other code that
may benefit from the ability to execute at NMI time.  By providing an API
that handles most or all of the common synchronization issues associated
with NMI handlers, I hope to make NMI handler code easier to develop and
more reliable (since most or all of the NMI-related synchronization code is
localized within a relatively small shared API).

One thing my patch lacks is a notifier mechanism for registering callbacks
that execute at NMI time.  The following patch posted by Corey Minyard
already provides this functionality:

http://lkml.org/lkml/2004/8/19/140

Also I have not dealt with the issue of where to check for pending
callbacks deferred by NMI handlers.  Here are a few possibilities:

1.  Modules that wish to register NMI handlers may periodically poll
for pending callbacks.  The advantage of this is that it requires
no changes to the core kernel code.  The disadvantage is that with
polling, there is a tradeoff between prompt execution of callbacks
and wasted CPU cycles due to excessive polling.
2.  Check for pending callbacks at the same time pending softirqs are
checked for.  The advantage of this is that the polling may be
done with relatively high frequency as compared to option #1
without the overhead of using timers to do the polling.  The
disadvantage is that implementing this requires minor changes to
the softirq implementation code.
3.  When an NMI handler schedules a callback, let the NMI handler raise
a normal (maskable) interrupt whose purpose is to execute the
callbacks soon after the NMI handler returns.  The advantage here
is that polling is eliminated and callbacks execute as soon as
possible.  A disadvantage is that this will probably require
architecture-specific changes to reserve an interrupt vector
specifically for this purpose (similar to how smp_call_function()
is implemented).  Also, hardware resources required for raising the
interrupt (i.e. the local APIC on x86 processors) must be protected
from concurrent access by NMI handler code and code that executes
outside NMI context.  However this problem is not difficult to
solve.

I welcome any feedback anyone may have.  When replying, please cc
[EMAIL PROTECTED] and [EMAIL PROTECTED]

Thanks,
Dave Peterson

Signed-off-by: Dave Peterson <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

diff -urNp -X dontdiff linux-2.6.11.5/arch/i386/defconfig 
linux-2.6.11.5-nmi/arch/i386/defconfig
--- linux-2.6.11.5/arch/i386/defconfig 2005-03-18 22:35:00.0 -0800
+++ linux-2.6.11.5-nmi/arch/i386/defconfig 2005-03-20 09:37:36.0 -0800
@@ -101,6 +101,7 @@ CONFIG_X86_TSC=y
 CONFIG_X86_MCE=y
 CONFIG_X86_MCE_NONFATAL=y
 CONFIG_X86_MCE_P4THERMAL=y
+# CONFIG_NMI_EXTENDED is not set
 # CONFIG_TOSHIBA is not set
 # CONFIG_I8K is not set
 # CONFIG_MICROCODE is not set
diff -urNp -X dontdiff linux-2.6.11.5/arch/i386/Kconfig 
linux-2.6.11.5-nmi/arch/i386/Kconfig
--- linux-2.6.11.5/arch/i386/Kconfig 2005-03-18 22:34:52.0 -0800
+++ linux-2.6.11.5-nmi/arch/i386/Kconfig 2005-03-20 09:37:36.0 -0800
@@ -610,6 +610,13 @@ config X86_MCE_P4THERMAL
Enabling this feature will cause a message to be printed when the P4
enters thermal throttling.
 
+config NMI_EXTENDED
+ bool "Extended support for NMI handlers (EXPERIMENTAL)"
+ depends on EXPERIMENTAL
+ help
+   This option provides a few things that facilitate writing kernel
+   modules that handle NMIs (nonmaskable interrupts).
+
 config TOSHIBA
  tristate "Toshiba Laptop support"
  ---help---
diff -urNp -X dontdiff linux-2.6.11.5/arch/x86_64/defconfig 
linux-2.6.11.5-nmi/arch/x86_64/defconfig
--- linux-2.6.11.5/arch/x86_64/defconfig 2005-03-18 22:35:00.0 -0800
+++ linux-2.6.11.5-nmi/arch/x86_64/defconfig 

Re: 2.6.11.3 build problem in arch/alpha/kernel/srcons.c with gcc-4.0

[Richard Henderson]

On Sun, Mar 20, 2005 at 07:03:52PM -0800, Andrew Morton wrote:
> Dan Kegel <[EMAIL PROTECTED]> wrote:
> >
> > Anyone with an alpha care to suggest a fix for this?
> > 
> > arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
> > arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used 
> > uninitialized in this function
> > make[1]: *** [arch/alpha/kernel/srmcons.o] Error 1
> > make: *** [arch/alpha/kernel] Error 2
> > 
> > I get this when building the 2.6.11.3 kernel with a recent gcc-4.0 snapshot.
> > 
> 
> It's beyond gcc's ability to figure out that the code is OK.  Options would
> be to disable -Werror, or to artificially initialise that variable.

Fixed thus.

Note that even with a _raw_read_trylock implementation, smp still
doesn't work.  Everything that init spawns dies immediately.  I
havn't had a chance to find out why yet...


r~



You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.

===


[EMAIL PROTECTED], 2005-03-20 12:29:41-08:00, [EMAIL PROTECTED]
  [ALPHA] Elimitate two warnings from gcc4.


 smp.c |   43 ---
 srmcons.c |   27 ++-
 2 files changed, 10 insertions(+), 60 deletions(-)


diff -Nru a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
--- a/arch/alpha/kernel/smp.c   2005-03-20 20:23:28 -08:00
+++ b/arch/alpha/kernel/smp.c   2005-03-20 20:23:28 -08:00
@@ -175,48 +175,6 @@
cpu_idle();
 }
 
-
-/*
- * Rough estimation for SMP scheduling, this is the number of cycles it
- * takes for a fully memory-limited process to flush the SMP-local cache.
- *
- * We are not told how much cache there is, so we have to guess.
- */
-static void __init
-smp_tune_scheduling (int cpuid)
-{
-   struct percpu_struct *cpu;
-   unsigned long on_chip_cache;/* kB */
-   unsigned long freq; /* Hz */
-   unsigned long bandwidth = 350;  /* MB/s */
-
-   cpu = (struct percpu_struct*)((char*)hwrpb + hwrpb->processor_offset
- + cpuid * hwrpb->processor_size);
-   switch (cpu->type)
-   {
-   case EV45_CPU:
-   on_chip_cache = 16 + 16;
-   break;
-
-   case EV5_CPU:
-   case EV56_CPU:
-   on_chip_cache = 8 + 8 + 96;
-   break;
-
-   case PCA56_CPU:
-   on_chip_cache = 16 + 8;
-   break;
-
-   case EV6_CPU:
-   case EV67_CPU:
-   default:
-   on_chip_cache = 64 + 64;
-   break;
-   }
-
-   freq = hwrpb->cycle_freq ? : est_cycle_freq;
-}
-
 /* Wait until hwrpb->txrdy is clear for cpu.  Return -1 on timeout.  */
 static int __init
 wait_for_txrdy (unsigned long cpumask)
@@ -517,7 +475,6 @@
current_thread_info()->cpu = boot_cpuid;
 
smp_store_cpu_info(boot_cpuid);
-   smp_tune_scheduling(boot_cpuid);
smp_setup_percpu_timer(boot_cpuid);
 
/* Nothing to do on a UP box, or when told not to.  */
diff -Nru a/arch/alpha/kernel/srmcons.c b/arch/alpha/kernel/srmcons.c
--- a/arch/alpha/kernel/srmcons.c   2005-03-20 20:23:28 -08:00
+++ b/arch/alpha/kernel/srmcons.c   2005-03-20 20:23:28 -08:00
@@ -164,29 +164,22 @@
unsigned long flags;
int retval = 0;
 
-   spin_lock_irqsave(_lock, flags);
-
-   do {
-   if (srmconsp != NULL) {
-   *ps = srmconsp;
-   break;
-   }
+   if (srmconsp == NULL) {
+   spin_lock_irqsave(_lock, flags);
 
srmconsp = kmalloc(sizeof(*srmconsp), GFP_KERNEL);
-   if (srmconsp == NULL) {
+   if (srmconsp == NULL)
retval = -ENOMEM;
-   break;
+   else {
+   srmconsp->tty = NULL;
+   spin_lock_init(>lock);
+   init_timer(>timer);
}
 
-   srmconsp->tty = NULL;
-   spin_lock_init(>lock);
-   init_timer(>timer);
-
-   *ps = srmconsp;
-   } while(0);
-
-   spin_unlock_irqrestore(_lock, flags);
+   spin_unlock_irqrestore(_lock, flags);
+   }
 
+   *ps = srmconsp;
return retval;
 }
 

===


This BitKeeper patch contains the following changesets:
1.2289
## Wrapped with gzip_uu ##


M'XL( $!,/D(  [56[V_;-A#]+/X5!Q38FFV628KZY4XSH8D1KK%-F#@>'J\]^[>[EMAIL PROTECTED]@LU\919H#?PL=%F
MXG$E?+,N\[P2OA3^:QL;'BZ868YLY?O=YS&_;$?4C9$\ON3:P:O]%YY3=J_D^4
M$ (\R^')V?
[EMAIL PROTECTED],8'2Y5Q6-7OA""'.,3AZA:?O>)3BWJA?I3?Z"*G>@#RND49R_0\O-^RN)C,R\
MNCVM2MD9UB_#4'" X8@&$8D?A5+
M7([EMAIL PROTECTED]:I<67/,M%%=9D!W;MTLN(&[EMAIL PROTECTED]:#>] (Z;Ohttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forkbombing Linux distributions

[William Beebe]

Thanks. That's what I thought. Sorry for the annoyance.


On Sun, 20 Mar 2005 22:22:21 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 20, 2005 at 10:06:57PM -0500, William Beebe wrote:
> 
>  > Is this really a kernel issue? Or is there a better way in userland to
>  > stop this kind of crap?
> 
> man ulimit
> 
> Dave
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forkbombing Linux distributions

[Peter Chubb]

> "William" == William Beebe <[EMAIL PROTECTED]> writes:

William> Sure enough, I created the following script and ran it as a
William> non-root user:

William> #!/bin/bash $0 & $0 &

There are two approaches to fixing this.
  1.  Rate limit fork().  Unfortunately some legitimate usges do a lot
  of forking, and you don't really want to slow them down.
  2.  Limit (per user) the number of processes allowed. This is what's
  currently done; and if you as administrator want to you can set
  RLIMIT_NPROC in /etc/security/limits.conf

On an almost-single-user system such as most desktops, there isn't much
point in setting this.  On shared systems, it can be useful.

-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

[Dmitry Torokhov]

On Sunday 20 March 2005 21:04, Patrick McFarland wrote:
> On Sunday 20 March 2005 07:39 pm, Andrew Morton wrote:
> > Patrick McFarland <[EMAIL PROTECTED]> wrote:
> > > It seems that the es1371 driver (which provides its own joystick port
> > > driver) is broken in at least 2.6.11-mm4. I don't know when it broke, but
> > > it used to work around in the 2.6.8/9 days (I haven't used the joystick
> > > in awhile). The hardware and joystick still both work (tested in
> > > Windows).
> >
> > Please define "broken".  I assume that audio still comes out, but that the
> > joystick doesn't work?
> 
> Yup, audio works fine, this is why I never noticed. Also, the external midi 
> interface also works fine. Digging around, /proc/asound/card0/audiopci says 
> "Joystick enable: off, Joystick port: 0x200". 
> 
> I've also been looking through alsa's cvs for alsa-kernel, and I can't see 
> any 
> changes that might have broken it.
> 

I could have broken it during my gameport sysfs integration... Although I can't
see anything that could cause the breakage. Can I please see your .config?

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

Re: forkbombing Linux distributions

[Dave Jones]

On Sun, Mar 20, 2005 at 10:06:57PM -0500, William Beebe wrote:

 > Is this really a kernel issue? Or is there a better way in userland to
 > stop this kind of crap?

man ulimit

Dave

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

Re: 2.6.11.3 build problem in arch/alpha/kernel/srcons.c with gcc-4.0

[Richard Henderson]

On Sun, Mar 20, 2005 at 07:03:52PM -0800, Andrew Morton wrote:
> Dan Kegel <[EMAIL PROTECTED]> wrote:
> >
> > Anyone with an alpha care to suggest a fix for this?
> > 
> > arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
> > arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used 
> > uninitialized in this function
> > make[1]: *** [arch/alpha/kernel/srmcons.o] Error 1
> > make: *** [arch/alpha/kernel] Error 2
> > 
> > I get this when building the 2.6.11.3 kernel with a recent gcc-4.0 snapshot.
> > 
> 
> It's beyond gcc's ability to figure out that the code is OK.  Options would
> be to disable -Werror, or to artificially initialise that variable.

I've a fix in my local tree.  I'll pass it along shortly.



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

Re: 2.6.11.3 build problem in arch/alpha/kernel/srcons.c with gcc-4.0

[Dan Kegel]

Andrew Morton wrote:
Dan Kegel <[EMAIL PROTECTED]> wrote:
Anyone with an alpha care to suggest a fix for this?
arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used uninitialized 
in this function
make[1]: *** [arch/alpha/kernel/srmcons.o] Error 1
make: *** [arch/alpha/kernel] Error 2
I get this when building the 2.6.11.3 kernel with a recent gcc-4.0 snapshot.

It's beyond gcc's ability to figure out that the code is OK.  Options would
be to disable -Werror, or to artificially initialise that variable.
I'll initialize it to something - guess it doesn't matter what.
Thanks,
Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

forkbombing Linux distributions

[William Beebe]

The following quote is from the article "Linux Kernel Security, Again"
(http://www.securityfocus.com/columnists/308):

"Don't get me wrong. Linux doesn't suck. But I do believe that the
Linux kernel team (and some of the Linux distributions that are still
vulnerable to fork bombing) need to take proactive security a little
more seriously. I'm griping for a reason here -- things need to be
change."

Sure enough, I created the following script and ran it as a non-root user:

#!/bin/bash
$0 & $0 &

and ran it on Fedora Core 3 with kernel 2.6.11.5 (the box is an Athlon
XP 2500+ Barton with 512M on an nForce2 board). The system locked up
tighter than a drum. However... After about two minutes the system
"unlocked" and responsiveness returned to normal. I can see where this
would be an issue on a production system, especially if you could kick
off a new fork bomb to continuously lock the system.

Is this really a kernel issue? Or is there a better way in userland to
stop this kind of crap?

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

Re: 2.6.11.3 build problem in arch/alpha/kernel/srcons.c with gcc-4.0

[Andrew Morton]

Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> Anyone with an alpha care to suggest a fix for this?
> 
> arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
> arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used 
> uninitialized in this function
> make[1]: *** [arch/alpha/kernel/srmcons.o] Error 1
> make: *** [arch/alpha/kernel] Error 2
> 
> I get this when building the 2.6.11.3 kernel with a recent gcc-4.0 snapshot.
> 

It's beyond gcc's ability to figure out that the code is OK.  Options would
be to disable -Werror, or to artificially initialise that variable.

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

Re: Futex queue_me/get_user ordering

[Jamie Lokier]

Ingo Molnar wrote:
> 
> * Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> 
> > The futex man pages that have been around for years (certainly since
> > mid 2002) certainly don't document FUTEX_WAIT as token passing
> > operation, but as atomic operation:
> > 
> > Say http://www.icewalkers.com/Linux/ManPages/futex-2.html
> 
> besides this documented-behavior argument, i dont think futexes should
> be degraded into waitqueues

I give in...

Depending on atomicity makes it impossible for an application, which
is linked with NPTL and Glibc, to write an NPTL-compatible "wait on
two locks" function.

I'm not saying that's a very clean thing to want, but it's a
conceptual loss and I'm disappointed I seem to be the only one
noticing it.

On the other hand, I was mistaken to think it makes it impossible to
write an emulation of synchronous futex() in terms of asynchronous
futex().* In fact it makes it impossible to do so using the existing
FUTEX_FD, but it would be possible if there were a FUTEX_FD2 added
somewhere down the line.

* - The reason you would do this is if you were writing userspace-threading
for any reason, and you had to include an emulation of synchronous
futex() in terms of async futex because there are some libraries
which might run on top of the userspace-threading which use futex
in an application-dependent way.

> - in fact, to solve some of the known
> performance problems the opposite will have to happen: e.g. i believe
> that in the future we'll need to enable the kernel-side futex code to
> actually modify the futex variable. I.e. atomicity of the read in
> FUTEX_WAIT is an absolute must, and is only the first step.

Some of those performance problems can be solved already by better use
of FUTEX_REQUEUE instead of FUTEX_WAKE.

> [ the double-context-switch problem in cond_signal() that Jamie
>   mentioned is precisely one such case: pthread semantics force us that
>   the wakeup of the wakee _must_ happen while still holding the internal
>   lock. So we cannot just delay the wakeup to outside the glibc critical
>   section. This double context-switch could be avoided if the 'release
>   internal lock and wake up wakee' operation could be done atomically
>   within the kernel. (A sane default 'userspace unlock' operation on a
>   machine word could be defined .. e.g. decrement-to-zero.) ]

Did you not see the solution I gave last November, using FUTEX_REQUEUE?

See:

http://lkml.org/lkml/2004/11/29/201

I spent a _lot_ of time figuring it out but everyone was too busy to
confirm that it worked.  It would improve performance in a number of cases.

I hope that it does not get ignored yet again.

There _may_ be cases where more complex futex operations are needed,
but we should try the better algorithms that use the existing futex
operations before adding new ones.

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

Re: Kernel hiccups (was USB Mouse Hiccups)

[Nick Piggin]

viking wrote:
Okay - so I see I'm not the only one to see significant slowdowns in 2.6.11.x
compared to 2.6.10 - guess I'll have to wait until the 4-level table thing
sorts itself out...
/me removes foot out of gob.
The 4-level page tables slowdowns don't explain the problems you
are seeing. 2.6.12-rc1 is very close to 2.6.10 speed. The slowdown
we are talking about is on the order of microseconds at process
exit time, and unmap.
So please continue to investigate your problems. I think there may
have been some small CPU scheduler changes between 2.6.10 and
2.6.11 from Con. Seems unlikely that they would be causing your
problems, but that's my suggestion for a starting point.
Thanks,
Nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.11.3 build problem in arch/alpha/kernel/srcons.c with gcc-4.0

[Dan Kegel]

Anyone with an alpha care to suggest a fix for this?
arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used uninitialized 
in this function
make[1]: *** [arch/alpha/kernel/srmcons.o] Error 1
make: *** [arch/alpha/kernel] Error 2
I get this when building the 2.6.11.3 kernel with a recent gcc-4.0 snapshot.
Thanks,
Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

[Patrick McFarland]

On Sunday 20 March 2005 07:39 pm, Andrew Morton wrote:
> Patrick McFarland <[EMAIL PROTECTED]> wrote:
> > It seems that the es1371 driver (which provides its own joystick port
> > driver) is broken in at least 2.6.11-mm4. I don't know when it broke, but
> > it used to work around in the 2.6.8/9 days (I haven't used the joystick
> > in awhile). The hardware and joystick still both work (tested in
> > Windows).
>
> Please define "broken".  I assume that audio still comes out, but that the
> joystick doesn't work?

Yup, audio works fine, this is why I never noticed. Also, the external midi 
interface also works fine. Digging around, /proc/asound/card0/audiopci says 
"Joystick enable: off, Joystick port: 0x200". 

I've also been looking through alsa's cvs for alsa-kernel, and I can't see any 
changes that might have broken it.

Also, I have a usb gamepad that currently works fine.

-- 
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989


pgpUleYD5GNdd.pgp
Description: PGP signature

Re: Kernel hiccups (was USB Mouse Hiccups)

[viking]

Okay - so I see I'm not the only one to see significant slowdowns in 2.6.11.x
compared to 2.6.10 - guess I'll have to wait until the 4-level table thing
sorts itself out...

/me removes foot out of gob.

-- 
 /|   _,.:*^*:.,   |\  Cheers from the Viking family, including Pippin, our cat
| |_/'  viking@ `\_| |
|flying-brick| $FunnyMail   : What do you mean, I've lost the plot?
 \_.caverock.net.nz_/ 5.40  : I planted them carrots right here!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB mouse hiccups

[viking]

On Sun, Mar 20, 2005 at 04:41:29PM -0800, Andrew Morton wrote:
> viking <[EMAIL PROTECTED]> wrote:
> >
> > I did note something strange. I'm running 2.6.11.2 at this moment, when I
> >  tried 2.6.11.3, my USB Microsoft Wireless Optical Mouse stopped moving
> >  from left to right, and would only move up and down if I physically moved
> >  the mouse from left to right. I didn't see anything in the patches that
> >  touched anything in the event handling, so frankly I'm puzzled.
> >  Any clues as to where I need to look? I've seen this problem before, but
> >  don't know what causes it, nor how I fixed it at the time.
> >  Also, how do I get that patch that enables the tiltwheel (left-right
> >  events)?
> 
> Could you please test 2.6.12-rc1?

Yeesh. You ARE keen, aren't you. I'll attempt to do so over the next day or
so. Thanks.

-- 
 /|   _,.:*^*:.,   |\  Cheers from the Viking family, including Pippin, our cat
| |_/'  viking@ `\_| |
|flying-brick| $FunnyMail   : What do you mean, I've lost the plot?
 \_.caverock.net.nz_/ 5.40  : I planted them carrots right here!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] del_timer_sync scalability patch

[Andrew Morton]

Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> On Sun, 20 Mar 2005, Andrew Morton wrote:
> 
> > > Hope Andrew is going to take the patch this time.
> >
> > Hope Kenneth is going to test the alternate del_timer_sync patches in next
> > -mm ;)
> 
> BTW Why are we going through this? Oleg has posted a much better solution
> to this issue yersteday AFAIK.

That is what I was referring to.

Those patches need to be reviewed, performance tested and stability tested.
It's appropriate that interested parties do that work, please.

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

Re: [patch] del_timer_sync scalability patch

[Andrew Morton]

Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> On Sun, 20 Mar 2005, Andrew Morton wrote:
> 
> > "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
> > >
> > > We did exactly the same thing about 10 months back.  Nice to
> > > see that independent people came up with exactly the same
> > > solution that we proposed 10 months back.
> >
> > Well the same question applies.  Christoph, which code is calling
> > del_timer_sync() so often that you noticed?
> 
> Ummm. I have to ask those who brought this to my attention. Are you
> looking for the application under which del_timer_sync showed up in
> profiling or the kernel subsystem?

I was wondering which part of the kernel was hammering del_timer_sync() so
hard.  I guess we could work that out from a description of the workload.

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

Re: Function stack size usage (was [PATCH][1/2] SquashFS)

[Andrew Morton]

Phillip Lougher <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Phillip Lougher <[EMAIL PROTECTED]> wrote:
> >>
> >>+static struct inode *squashfs_iget(struct super_block *s, squashfs_inode 
> >>inode)
> >>+{
> >>+   struct inode *i;
> >>+   squashfs_sb_info *msBlk = (squashfs_sb_info *)s->s_fs_info;
> >>+   squashfs_super_block *sBlk = >sBlk;
> >>+   unsigned int block = SQUASHFS_INODE_BLK(inode) +
> >>+   sBlk->inode_table_start;
> >>+   unsigned int offset = SQUASHFS_INODE_OFFSET(inode);
> >>+   unsigned int ino = SQUASHFS_MK_VFS_INODE(block
> >>+   - sBlk->inode_table_start, offset);
> >>+   unsigned int next_block, next_offset;
> >>+   squashfs_base_inode_header inodeb;
> > 
> > 
> > How much stack space is being used here?  Perhaps you should run
> > scripts/checkstack.pl across the whole thing.
> > 
> 
> A lot of the functions use a fair amount of stack (I never thought it 
> was excessive)...  This is the result of running checkstack.pl against 
> the code on Intel.
> 
> 0x3a3c get_dir_index_using_name:596
> 0x0d80 squashfs_iget:   488
> 0x44d8 squashfs_lookup: 380
> 0x3d00 squashfs_readdir:372
> 0x20fe squashfs_fill_super: 316
> 0x31b8 squashfs_readpage:   308
> 0x2f5c read_blocklist:  296
> 0x3634 squashfs_readpage4K: 284
> 
> A couple of these functions show a fair amount of stack use.  What is 
> the maximum acceptable usage,

There's no hard-and-fast rule.  The conditions running up to a stack
overrun are necessarily complex, and rare.  But you can see that for a
twenty or thirty function deep call stack, 500 bytes is a big bite out of
4k.

> i.e. do any of the above functions need 
> work to reduce their stack usage?

I'd say so, yes.  If at all possible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] del_timer_sync scalability patch

[Christoph Lameter]

On Sun, 20 Mar 2005, Andrew Morton wrote:

> > Hope Andrew is going to take the patch this time.
>
> Hope Kenneth is going to test the alternate del_timer_sync patches in next
> -mm ;)

BTW Why are we going through this? Oleg has posted a much better solution
to this issue yersteday AFAIK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Function stack size usage (was [PATCH][1/2] SquashFS)

[Phillip Lougher]

Andrew Morton wrote:
Phillip Lougher <[EMAIL PROTECTED]> wrote:
+static struct inode *squashfs_iget(struct super_block *s, squashfs_inode 
inode)
+{
+   struct inode *i;
+   squashfs_sb_info *msBlk = (squashfs_sb_info *)s->s_fs_info;
+   squashfs_super_block *sBlk = >sBlk;
+   unsigned int block = SQUASHFS_INODE_BLK(inode) +
+   sBlk->inode_table_start;
+   unsigned int offset = SQUASHFS_INODE_OFFSET(inode);
+   unsigned int ino = SQUASHFS_MK_VFS_INODE(block
+   - sBlk->inode_table_start, offset);
+   unsigned int next_block, next_offset;
+   squashfs_base_inode_header inodeb;

How much stack space is being used here?  Perhaps you should run
scripts/checkstack.pl across the whole thing.
A lot of the functions use a fair amount of stack (I never thought it 
was excessive)...  This is the result of running checkstack.pl against 
the code on Intel.

0x3a3c get_dir_index_using_name:596
0x0d80 squashfs_iget:   488
0x44d8 squashfs_lookup: 380
0x3d00 squashfs_readdir:372
0x20fe squashfs_fill_super: 316
0x31b8 squashfs_readpage:   308
0x2f5c read_blocklist:  296
0x3634 squashfs_readpage4K: 284
A couple of these functions show a fair amount of stack use.  What is 
the maximum acceptable usage, i.e. do any of the above functions need 
work to reduce their stack usage?

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

Re: [patch] del_timer_sync scalability patch

[Christoph Lameter]

On Sun, 20 Mar 2005, Andrew Morton wrote:

> "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
> >
> > We did exactly the same thing about 10 months back.  Nice to
> > see that independent people came up with exactly the same
> > solution that we proposed 10 months back.
>
> Well the same question applies.  Christoph, which code is calling
> del_timer_sync() so often that you noticed?

Ummm. I have to ask those who brought this to my attention. Are you
looking for the application under which del_timer_sync showed up in
profiling or the kernel subsystem?

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

Re: [2.6 patch] i386/x86_64 mpparse.c: kill maxcpus

[Adrian Bunk]

On Sun, Mar 20, 2005 at 07:01:49PM -0500, Dave Jones wrote:
> On Mon, Mar 21, 2005 at 12:59:46AM +0100, Adrian Bunk wrote:
>  > On Sun, Mar 20, 2005 at 06:32:03PM -0500, Dave Jones wrote:
>  > > On Mon, Mar 21, 2005 at 12:12:32AM +0100, Adrian Bunk wrote:
>  > >  > On Sun, Mar 20, 2005 at 05:42:34PM -0500, Dave Jones wrote:
>  > >  > > On Sun, Mar 20, 2005 at 08:25:49PM +0100, Adrian Bunk wrote:
>  > >  > >  > Do we really need a global variable that does only hold the 
> value of 
>  > >  > >  > NR_CPUS?
>  > >  > > 
>  > >  > > Yes.
>  > >  > >  
>  > >  > > NR_CPUS = compile time
>  > >  > > maxcpus = boot command line at runtime.
>  > >  > 
>  > >  > If this is how is was expected to work - it isn't exactly what is 
>  > >  > currently implemented.
>  > > 
>  > > It's ugly, as its setting the same thing in two different places, but
>  > > I don't see any obvious reason why it won't work.
>  > >...
>  > 
>  > I might be too dumb, but where are the mpparse.c maxcpus variables ever 
>  > set to any value different from NR_CPUS?
> 
> arch/x86_64/kernel/setup.c:parse_cmdline_early()
> 
>   ...
> else if (!memcmp(from, "maxcpus=", 8)) {
> extern unsigned int maxcpus;
> 
> maxcpus = simple_strtoul(from + 8, NULL, 0);
> }
>   ...

Ah, thanks.

I didn't see this extern declaration.
(and my test compiles were with SMP=n...)

>   Dave

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: USB mouse hiccups (was RFD: Kernel release numbering)

[Andrew Morton]

viking <[EMAIL PROTECTED]> wrote:
>
> I did note something strange. I'm running 2.6.11.2 at this moment, when I
>  tried 2.6.11.3, my USB Microsoft Wireless Optical Mouse stopped moving
>  from left to right, and would only move up and down if I physically moved
>  the mouse from left to right. I didn't see anything in the patches that
>  touched anything in the event handling, so frankly I'm puzzled.
>  Any clues as to where I need to look? I've seen this problem before, but
>  don't know what causes it, nor how I fixed it at the time.
>  Also, how do I get that patch that enables the tiltwheel (left-right
>  events)?

Could you please test 2.6.12-rc1?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

[Andrew Morton]

Patrick McFarland <[EMAIL PROTECTED]> wrote:
>
> It seems that the es1371 driver (which provides its own joystick port driver) 
> is broken in at least 2.6.11-mm4. I don't know when it broke, but it used to 
> work around in the 2.6.8/9 days (I haven't used the joystick in awhile). The 
> hardware and joystick still both work (tested in Windows).
> 

Please define "broken".  I assume that audio still comes out, but that the
joystick doesn't work?

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

SATA Promise TX4 Crash

[Neil Whelchel]

Hello,
I have two Promise SATA TX4 cards connected to a total of 6 Maxtor 250 GB
drives (7Y250M0) configured into a RAID 5. All works well with small
disk load, but when a large number of requests are issued, it causes crash
similar to the attached, except that the errors before the crash are on a
different drive nearly every time. I have tried several different
motherboards with both Nvidia and Via chipsets, with Athlon and K6
CPUs, and the crash remains the same. I have also seen the same crash
with both a preemptable and a non-preemptable kernel, with kernel
versions 2.6.9, 2.6.10, 2.6.11, and 2.6.11.2 (this one).
Any suggestions, or is this a bug?


ata3: status=0x51 { DriveReady SeekComplete Error }
ata3: error=0x40 { UncorrectableError }
ata3: status=0x51 { DriveReady SeekComplete Error }
ata3: error=0x40 { UncorrectableError }
ata3: status=0x51 { DriveReady SeekComplete Error }
ata3: error=0x40 { UncorrectableError }
ata3: status=0x51 { DriveReady SeekComplete Error }
ata3: error=0x40 { UncorrectableError }
ata3: status=0x51 { DriveReady SeekComplete Error }
ata3: error=0x40 { UncorrectableError }
ata3: command timeout
Assertion failed! qc->flags &
ATA_QCFLAG_ACTIVE,drivers/scsi/libata-core.c,ata_qc_complete,line=2807
ata3: status=0x51 { DriveReady SeekComplete Error }
ata3: called with no error (51)!
[ cut here ]
kernel BUG at drivers/scsi/scsi.c:299!
invalid operand:  [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046   (2.6.11.2)
EIP is at scsi_put_command+0xbb/0x100
eax: 0001   ebx: c2f5e390   ecx: 0001   edx: c2f5e390
esi: c2f5e380   edi: 0246   ebp: c7c4beb4   esp: c7c4be9c
ds: 007b   es: 007b   ss: 0068
Process scsi_eh_2 (pid: 821, threadinfo=c7c4a000 task=c7c315b0)
Stack: 0296 c7c3 c7c26400 c7c23030 c2f5e380 0246 c7c4bec4 c02ae9b3
   c2f5e380 c44a1740 c7c4bee0 c02aeabc c2f5e380 c7c23030 c2f5e380 0802
   c44a1740 c7c4bf28 c02aedd2 c2f5e380 0001   
Call Trace:
 [] show_stack+0x72/0xa0
 [] show_registers+0x104/0x180
 [] die+0xd3/0x180
 [] do_invalid_op+0x90/0xa0
 [] error_code+0x2b/0x30
 [] scsi_next_command+0x13/0x20
 [] scsi_end_request+0xbc/0xe0
 [] scsi_io_completion+0x132/0x3c0
 [] sd_rw_intr+0xb8/0x2c0
 [] ata_scsi_qc_complete+0x20/0x40
 [] ata_qc_complete+0x2c/0xa0
 [] pdc_eng_timeout+0x93/0x120
 [] ata_scsi_error+0x14/0x40
 [] scsi_error_handler+0x5b/0xc0
 [] kernel_thread_helper+0x5/0x14
Code: ec 8b 42 08 ff 30 e8 e5 cd e8 ff 59 5b 8b 45 f0 05 84 01 00 00 89 45
08 8d 65 f4 5b 5e 5f c9 e9 ac 41 fc ff e8 47 6c 13 00 eb ce <0f> 0b 2b 01
d6 e8 40 c0 e9 6c ff ff ff e8 33 6c 13 00 eb 8b 89
 <6>note: scsi_eh_2[821] exited with preempt_count 1


-Neil Whelchel-
First Light Internet Services
760 366-0145
- We don't do Window$, that's what the janitor is for -

Bubble Memory, n.:
A derogatory term, usually referring to a person's
intelligence.  See also "vacuum tube".

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

Re: Suspend-to-disk woes

[Matthew Garrett]

Nigel Cunningham <[EMAIL PROTECTED]> wrote:

> Yuck! Why panic when you know what is needed? A better solution is to
> tell the user they've messed up and given them the option to (1) reboot
> and try another kernel or (2) have swsusp restore the original swap
> signature and continue booting. This is what suspend2 does (with a
> timeout for the prompt). It's not that hard.

It's trivial to do this in userspace - just have an app in initramfs
that checks for a swsusp signature, and then compare the kernel
versions. If they mismatch, prompt for what to do. Putting it in the
kernel is madness.

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

Re: Suspend-to-disk woes

[Nigel Cunningham]

Hi.

On Sun, 2005-03-20 at 08:29, Pavel Machek wrote:
> On So 19-03-05 12:20:35, Russell Miller wrote:
> > On Saturday 19 March 2005 05:26, Pavel Machek wrote:
> > 
> > > Checking that would be hard, but you might want to provide patch to check
> > > last-mounted dates of filesystems and panic if they changed.
> > >   Pavel
> > 
> > Then how would you fix it?  There'd also have to be a way to reset it, 
> 
> boot with "noresume", then mkswap.

Yuck! Why panic when you know what is needed? A better solution is to
tell the user they've messed up and given them the option to (1) reboot
and try another kernel or (2) have swsusp restore the original swap
signature and continue booting. This is what suspend2 does (with a
timeout for the prompt). It's not that hard.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net

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

Re: [2.6 patch] i386/x86_64 mpparse.c: kill maxcpus

[Dave Jones]

On Mon, Mar 21, 2005 at 12:59:46AM +0100, Adrian Bunk wrote:
 > On Sun, Mar 20, 2005 at 06:32:03PM -0500, Dave Jones wrote:
 > > On Mon, Mar 21, 2005 at 12:12:32AM +0100, Adrian Bunk wrote:
 > >  > On Sun, Mar 20, 2005 at 05:42:34PM -0500, Dave Jones wrote:
 > >  > > On Sun, Mar 20, 2005 at 08:25:49PM +0100, Adrian Bunk wrote:
 > >  > >  > Do we really need a global variable that does only hold the value 
 > > of 
 > >  > >  > NR_CPUS?
 > >  > > 
 > >  > > Yes.
 > >  > >  
 > >  > > NR_CPUS = compile time
 > >  > > maxcpus = boot command line at runtime.
 > >  > 
 > >  > If this is how is was expected to work - it isn't exactly what is 
 > >  > currently implemented.
 > > 
 > > It's ugly, as its setting the same thing in two different places, but
 > > I don't see any obvious reason why it won't work.
 > >...
 > 
 > I might be too dumb, but where are the mpparse.c maxcpus variables ever 
 > set to any value different from NR_CPUS?

arch/x86_64/kernel/setup.c:parse_cmdline_early()

...
else if (!memcmp(from, "maxcpus=", 8)) {
extern unsigned int maxcpus;

maxcpus = simple_strtoul(from + 8, NULL, 0);
}
...


Dave

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

Re: [2.6 patch] i386/x86_64 mpparse.c: kill maxcpus

[Adrian Bunk]

On Sun, Mar 20, 2005 at 06:32:03PM -0500, Dave Jones wrote:
> On Mon, Mar 21, 2005 at 12:12:32AM +0100, Adrian Bunk wrote:
>  > On Sun, Mar 20, 2005 at 05:42:34PM -0500, Dave Jones wrote:
>  > > On Sun, Mar 20, 2005 at 08:25:49PM +0100, Adrian Bunk wrote:
>  > >  > Do we really need a global variable that does only hold the value of 
>  > >  > NR_CPUS?
>  > > 
>  > > Yes.
>  > >  
>  > > NR_CPUS = compile time
>  > > maxcpus = boot command line at runtime.
>  > 
>  > If this is how is was expected to work - it isn't exactly what is 
>  > currently implemented.
> 
> It's ugly, as its setting the same thing in two different places, but
> I don't see any obvious reason why it won't work.
>...

I might be too dumb, but where are the mpparse.c maxcpus variables ever 
set to any value different from NR_CPUS?

>   Dave

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Major problem with PCMCIA/Yenta system

[Ron Gage]

Greetings:

I have been trying to get a recently acquired Cardbus based USB 2.0 card 
working under 2.6 for the past weekend.  It's not going well.

Everytime I plug the card into the computer, the entire PCMCIA system just 
dies, taking my network connectivity with it.  I have to do a power off reset 
to recover.

The cardbus card is based on the ALI USB chipset.  This shows up as both an 
EHCI and an OHCI device under 2.6.11.5.  My laptop, an older HP Pavilion 
N5150 has a UHCI based chipset:

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 
03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 
03)
00:04.0 CardBus bridge: Texas Instruments PCI1420
00:04.1 CardBus bridge: Texas Instruments PCI1420
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:08.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12)
01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
02:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)


My ethernet card is a generic cardbus device.

When I insert the new USB 2.0 card, the kernel reports that it's killing off 
IRQ 11.  Here is the actual dump from dmesg:

Mar 20 18:38:13 port2 kernel: irq 11: nobody cared!
Mar 20 18:38:13 port2 kernel:  [] __report_bad_irq+0x2a/0xa0
Mar 20 18:38:13 port2 kernel:  [] handle_IRQ_event+0x30/0x70
Mar 20 18:38:13 port2 kernel:  [] note_interrupt+0x70/0xb0
Mar 20 18:38:13 port2 kernel:  [] __do_IRQ+0xe1/0xf0
Mar 20 18:38:13 port2 kernel:  [] do_IRQ+0x19/0x30
Mar 20 18:38:13 port2 kernel:  [] common_interrupt+0x1a/0x20
Mar 20 18:38:13 port2 kernel:  [] __do_softirq+0x2e/0xa0
Mar 20 18:38:13 port2 kernel:  [] do_softirq+0x26/0x30
Mar 20 18:38:13 port2 kernel:  [] do_IRQ+0x1e/0x30
Mar 20 18:38:13 port2 kernel:  [] common_interrupt+0x1a/0x20
Mar 20 18:38:13 port2 kernel:  [] acpi_processor_idle+0x238/0x288
Mar 20 18:38:13 port2 kernel:  [] default_idle+0x0/0x30
Mar 20 18:38:13 port2 kernel:  [] cpu_idle+0x4c/0x60
Mar 20 18:38:13 port2 kernel:  [] start_kernel+0x13c/0x160
Mar 20 18:38:13 port2 kernel:  [] unknown_bootoption+0x0/0x200
Mar 20 18:38:13 port2 kernel: handlers:
Mar 20 18:38:13 port2 kernel: [] (yenta_interrupt+0x0/0x40 
[yenta_socket])
Mar 20 18:38:13 port2 kernel: [] (yenta_interrupt+0x0/0x40 
[yenta_socket])
Mar 20 18:38:13 port2 kernel: [] (tulip_interrupt+0x0/0x9c0)
Mar 20 18:38:13 port2 kernel: Disabling IRQ #11
Mar 20 18:38:14 port2 kernel: PCI: Enabling device :06:00.0 ( -> 0002)
Mar 20 18:38:14 port2 kernel: PCI: Enabling device :06:00.3 ( -> 0002)
Mar 20 18:38:16 port2 kernel: ohci_hcd :06:00.0: Unlink after no-IRQ?  
Controller is probably using the wrong IRQ.

Again, when the USB card in inserted, the entire PCMCIA system shuts down and 
remains unusuable until powered off.

Kernel is stock 2.6.11.5.  I also tried with 2.6.11, 2.6.10, 2.6.9 and 2.6.7 - 
same result.  Distribution is Slackware 9.1 - gcc is 3.2.3

HELP!!!


-- 
Ron Gage - Pontiac, Michigan
(MCP, LPIC1, A+, Net+)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bitrotting serial drivers

[Pete Popov]

Russell King wrote:
On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote:
- __register_serial, register_serial, unregister_serial
(this driver doesn't support PCMCIA cards, all of which are based on
 8250-compatible devices.)
I tried a couple of times to cleanly add support to the 8250 for the Au1x 
serial. The uart is just different enough to make that hard, though I admit I 
never spent too much time on it. Sounds like it's time to revisit it again.

I would prefer to have a patch to remove (or ack to do so myself) the
above three mentioned functions so I can avoid breaking your driver,
rather than a large update to it.
Go for it. I'll test the driver afterwards and think about getting it into the 
8250 again.

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

Re: [patch] del_timer_sync scalability patch

[Andrew Morton]

"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>
> We did exactly the same thing about 10 months back.  Nice to
> see that independent people came up with exactly the same
> solution that we proposed 10 months back.

Well the same question applies.  Christoph, which code is calling
del_timer_sync() so often that you noticed?

>  In fact, this patch
> is line-by-line identical to the one we post.

I assume that's not a coincidence.

> Hope Andrew is going to take the patch this time.

Hope Kenneth is going to test the alternate del_timer_sync patches in next
-mm ;)

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

Re: Real-Time Preemption and RCU

[Esben Nielsen]

On Sun, 20 Mar 2005, Paul E. McKenney wrote:

> On Sun, Mar 20, 2005 at 02:29:17PM +0100, Esben Nielsen wrote:
> > On Fri, 18 Mar 2005, Ingo Molnar wrote:
> > 
> > > [...]
> > 
> > I think it can be deterministic (on the long timescale of memory 
> > management) 
> > anyway: Boost any non-RT task entering an RCU region to the lowest RT 
> > priority.
> > This way only all the RT tasks + one non-RT task can be within those
> > regions. The RT-tasks are supposed to have some kind of upper bound to
> > their CPU-usage. The non-RT task will also finish "soon" as it is
> > boosted. If the RCU batches are also at the lowest RT-priority they can be
> > run immediately after the non-RT task is done.
> 
> Hmmm...  Sort of a preemptive-first-strike priority boost.  Cute!  ;-)
> 
Well, I was actually thinking of an API like
 preempt_by_nonrt_disable()
 preempt_by_nonrt_enable()
working like the old preempt_disable()/preempt_enable() but still
allowing RT tasks (as well as priority inheriting non-RT tasks) to be
scheduled. That would kind of help "split" the kernel into two halfs: the
RT part and the non-RT part. The non-RT part would in many ways work as it
has always done.

> > > clearly the simplest solution is to go with the single-reader locks for
> > > now - a separate experiment could be done with a new type of rwlock that
> > > can only be used by the RCU code. (I'm not quite sure whether we could
> > > guarantee a minimum rate of RCU callback processing under such a scheme
> > > though. It's an eventual memory DoS otherwise.)
> > > 
> > 
> > Why are a lock needed at all? If it is doable without locking for an
> > non-preemptable SMP kernel it must be doable for an preemptable kernel as
> > well.I am convinced some kind of per-CPU rcu_read_count as I specified in
> > my previous mail can work some way or the other. call_rcu() might need to
> > do more complicated stuff and thus use CPU but call_rcu() is supposed to
> > be an relative rare event not worth optimizing for.  Such an
> > implementation will work for any preemptable kernel, not only PREEMPT_RT. 
> > For performance is considered it is important not to acquire any locks in
> > the rcu-read regions. 
> 
> You definitely don't need a lock -- you can just suppress preemption
> on the read side instead.  But that potentially makes for long scheduling
> latencies.

Well, in my patch I do not leave preemption off - only while doing the
simple ++/--. In effect, I let rcu_qsctr_inc know that some RCU reader
might be active, i.e. preempted, on the current CPU such that this isn't
and quiescent point after all.
(To others: Paul nicely unfolded my attachment below - I left it in
the mail such you can read it.)
The problem with this approach is ofcourse that user space programs might
preempt an RCU reader for a very long time such that RCU batches are never
really run. The boosting of non-RT tasks mentioned above would help a
lot.
A plus(?) in it: You can actually sleep while having the rcu_read_lock !!

> 
> The counter approach might work, and is also what the implementation #5
> does -- check out rcu_read_lock() in Ingo's most recent patch.
> 

Do you refer to your original mail with implementing it in 5 steps?
In #5 in that one (-V0.7.41-00, right?) you use a lock and as you say that
forces syncronization between the CPUs - bad for scaling. It does make the
RCU batches somewhat deterministic, as the RCU task can boost the readers
to the rcu-task's priority.
The problem about this approach is that everybody calling into RCU code
have a worst case behaviour of the systemwide worst case RCU reader 
section - which can be pretty large (in principle infinite if somebody.)
So if somebody uses a call to a function in the code containing a RCU read
area the worst case behavious would be the same as teh worst case latency
in the simple world where preempt_disable()/preempt_enable() was used.

>   Thanx, Paul
> 
> > I tried this approach. My UP labtop did boot on it, but I haven't testet
> > it further. I have included the very small patch as an attachment.
> > 
> > >   Ingo
> > 
> > I have not yet looked at -V0.7.41-00...
> > 
> > Esben
> > 
> 
> > diff -Naur --exclude-from diff_exclude 
> > linux-2.6.11-final-V0.7.40-00/include/linux/rcupdate.h 
> > linux-2.6.11-final-V0.7.40-00-RCU/include/linux/rcupdate.h
> > --- linux-2.6.11-final-V0.7.40-00/include/linux/rcupdate.h  2005-03-11 
> > 23:40:13.0 +0100
> > +++ linux-2.6.11-final-V0.7.40-00-RCU/include/linux/rcupdate.h  
> > 2005-03-19 12:47:09.0 +0100
> > @@ -85,6 +85,7 @@
> >   * curlist - current batch for which quiescent cycle started if any
> >   */
> >  struct rcu_data {
> > +   longactive_readers;
> > /* 1) quiescent state handling : */
> > longquiescbatch; /* Batch # for grace period */
> > int passed_quiesc;   /* User-mode/idle loop etc. */
> > @@ -115,12 +116,14 @@
> >  static inline void 

Re: [2.6 patch] i386/x86_64 mpparse.c: kill maxcpus

[Dave Jones]

On Mon, Mar 21, 2005 at 12:12:32AM +0100, Adrian Bunk wrote:
 > On Sun, Mar 20, 2005 at 05:42:34PM -0500, Dave Jones wrote:
 > > On Sun, Mar 20, 2005 at 08:25:49PM +0100, Adrian Bunk wrote:
 > >  > Do we really need a global variable that does only hold the value of 
 > >  > NR_CPUS?
 > > 
 > > Yes.
 > >  
 > > NR_CPUS = compile time
 > > maxcpus = boot command line at runtime.
 > 
 > If this is how is was expected to work - it isn't exactly what is 
 > currently implemented.

It's ugly, as its setting the same thing in two different places, but
I don't see any obvious reason why it won't work.

 > The function maxcpus in init/main.c sets a static variable max_cpus -
 > not the global variable maxcpus in the mpparse.c files.

Both variables are used differently. The arch specific var is only
used for HT descrimination. The init/main.c one is used for smp bringup.

 > How should it be?
 > 
 > Should max_cpus in init/main.c become global and replace the maxcpus 
 > from the mpparse.c files?

I'd just leave it as it is, as it seems to be working right now.

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

Re: Bitrotting serial drivers

[Russell King]

On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote:
> >>>- __register_serial, register_serial, unregister_serial
> >>>  (this driver doesn't support PCMCIA cards, all of which are based on
> >>>   8250-compatible devices.)
>
> I tried a couple of times to cleanly add support to the 8250 for the Au1x 
> serial. The uart is just different enough to make that hard, though I admit I 
> never spent too much time on it. Sounds like it's time to revisit it again.

I would prefer to have a patch to remove (or ack to do so myself) the
above three mentioned functions so I can avoid breaking your driver,
rather than a large update to it.

Thanks.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [patch] del_timer_sync scalability patch

[Chen, Kenneth W]

We did exactly the same thing about 10 months back.  Nice to
see that independent people came up with exactly the same
solution that we proposed 10 months back.  In fact, this patch
is line-by-line identical to the one we post.

Hope Andrew is going to take the patch this time.

See our original posting:
http://marc.theaimsgroup.com/?l=linux-kernel=108422767319822=2

- Ken


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

[SATA] non-PCI SATA devices and libata

[John Williams]

Hello,
I am looking into developing a driver for a custom, non-PCI SATA 
controller.  The target arch is Microblaze, an FPGA-based NOMMU target 
on a 2.4.29-uc0 kernel.

It seems that Jeff Garzik's libata is the way to go for SATA, however 
there seems to be some degree of coupling between libata and PCI support.

Some comments/observations, please correct me if I am wrong:
 - include/linux/libata.h appears to recognise that CONFIG_PCI may not 
be set, however libata-compat.h is entirely PCI-specific.  Indeed, it 
effectively maps generic bus/dma operations onto their pci-specific 
equivalents.  Also, libata.h unconditionally includes pci.h.

 - All of the drivers/scsi/sata_XXX drivers target PCI devices only.
It seems I have a few choices here.
Option 1 is to just hack together stubbed PCI support for my arch, 
making our on-chip bus pretend to be PCI for the purposes of libata (and 
indeed many other bus subsystems, like USB).  This is pretty unclean, 
particularly since it is entirely likely that someone will build a 
microblaze system with a true PCI bridge and bus, meaning that this 
temporary hack would certainly come back to haunt me[1].

Option 2 is to try to decouple libata from PCI support.  This may be as 
simple as a conditional inclusion of libata-compat.h from libata.h, 
however I am not yet familiar enough with libata to be sure.

For now this will be staying in the NOMMU 2.4 kernel (uClinux), but if I 
choose option (2) I would like to work with libata, not against it.  It 
may well be that non-PCI SATA support is a Good Thing in a broader 
sense, so perhaps this is a good discussion to have anyway.

All input, suggestions and comments welcome.
Thanks,
John
[1] There is a bigger picture here, that with FPGA-based CPUs like 
Microblaze, we can build systems with arbitrary CPU/memory/IO bus 
topologies.  Indeed, we do so on a daily basis.  In the back of my mind 
I am envisioning some kind of generic bus abstraction API, of which PCI, 
USB etc would be mere instances.
--
John Williams, Research Fellow,
Embedded Systems Group / Reconfigurable Computing
School of ITEE, The University of Queensland, Brisbane, Australia

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

Kernel hiccups (was USB Mouse Hiccups)

[viking]

On Sun, 20 Mar 2005 23:20:04 +0100, viking wrote:

-blather-
> at least I *think* they're Linus' patches - no Visual Basic in them yet.
Guess that means Linus hasn't flipped his lid. So we won't see Linux-4.0
for MSVC any time soon.

Heh he - the ultimate virus would be if a Linux kernel could install
itself onto a NTFS partition and take over from the Windows kernel code.
Then MS would have way less support issues, we'd be hailed saviours, and
achieve world domination through the back door.

-meat-
> I've also noted .10 is quicker off the blocks than 2.6.11 seems to be.

Namely seems to happen around the times when I'm doing something like
mounting devfs (takes nearly 30 secs), and when I'm accessing files from
disc (bash$ less some-random-file.txt) - this can take about two seconds
for Linux to actually notice I've done something. I've no idea where the
error is here, either. i.e. is bash waiting around for me? is the
filesystem code waiting for some reason? Is the kernel in a tailspin?
[shrug]

CC if you wish, but I ought to be watching the list again for this one.

-- 
 /|   _,.:*^*:.,   |\  Cheers from the Viking family, including Pippin, our cat
| |_/'  viking@ `\_| |
|flying-brick| $FunnyMail   : What do you mean, I've lost the plot?
 \_.caverock.net.nz_/ 5.40  : I planted them carrots right here!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] i386/x86_64 mpparse.c: kill maxcpus

[Adrian Bunk]

On Sun, Mar 20, 2005 at 05:42:34PM -0500, Dave Jones wrote:
> On Sun, Mar 20, 2005 at 08:25:49PM +0100, Adrian Bunk wrote:
>  > Do we really need a global variable that does only hold the value of 
>  > NR_CPUS?
> 
> Yes.
>  
> NR_CPUS = compile time
> maxcpus = boot command line at runtime.

If this is how is was expected to work - it isn't exactly what is 
currently implemented.

The function maxcpus in init/main.c sets a static variable max_cpus -
not the global variable maxcpus in the mpparse.c files.

How should it be?

Should max_cpus in init/main.c become global and replace the maxcpus 
from the mpparse.c files?

>   Dave

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: fuse is cool and robust

[Andrew Morton]

bert hubert <[EMAIL PROTECTED]> wrote:
>
> I'm wondering what the status of Fuse is wrt to 2.6.12 or 2.6.13

Christoph H.  has indicated that he was going to review the code and I've
been holding off pending that.

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

[PATCH 5/5] autoparam: various fixes

[Magnus Damm]

Some module parameter fixes, errors reported by section2text.rb. 

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>

diff -urN linux-2.6.12-rc1/drivers/net/8139cp.c 
linux-2.6.12-rc1-autoparam/drivers/net/8139cp.c
--- linux-2.6.12-rc1/drivers/net/8139cp.c   2005-03-20 18:09:14.0 
+0100
+++ linux-2.6.12-rc1-autoparam/drivers/net/8139cp.c 2005-03-20 
22:47:41.504538496 +0100
@@ -94,13 +94,13 @@
 MODULE_LICENSE("GPL");
 
 static int debug = -1;
-MODULE_PARM (debug, "i");
+module_param (debug, int, 0);
 MODULE_PARM_DESC (debug, "8139cp: bitmapped message enable number");
 
 /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
The RTL chips use a 64 element hash table based on the Ethernet CRC.  */
 static int multicast_filter_limit = 32;
-MODULE_PARM (multicast_filter_limit, "i");
+module_param (multicast_filter_limit, int, 0);
 MODULE_PARM_DESC (multicast_filter_limit, "8139cp: maximum number of filtered 
multicast addresses");
 
 #define PFXDRV_NAME ": "
diff -urN linux-2.6.12-rc1/drivers/net/eepro100.c 
linux-2.6.12-rc1-autoparam/drivers/net/eepro100.c
--- linux-2.6.12-rc1/drivers/net/eepro100.c 2005-03-20 18:20:16.0 
+0100
+++ linux-2.6.12-rc1-autoparam/drivers/net/eepro100.c   2005-03-20 
22:46:12.176118480 +0100
@@ -144,8 +144,8 @@
 MODULE_PARM_DESC(congenb, "Enable congestion control (1)");
 MODULE_PARM_DESC(txfifo, "Tx FIFO threshold in 4 byte units, (0-15)");
 MODULE_PARM_DESC(rxfifo, "Rx FIFO threshold in 4 byte units, (0-15)");
-MODULE_PARM_DESC(txdmaccount, "Tx DMA burst length; 128 - disable (0-128)");
-MODULE_PARM_DESC(rxdmaccount, "Rx DMA burst length; 128 - disable (0-128)");
+MODULE_PARM_DESC(txdmacount, "Tx DMA burst length; 128 - disable (0-128)");
+MODULE_PARM_DESC(rxdmacount, "Rx DMA burst length; 128 - disable (0-128)");
 MODULE_PARM_DESC(rx_copybreak, "copy breakpoint for copy-only-tiny-frames");
 MODULE_PARM_DESC(max_interrupt_work, "maximum events handled per interrupt");
 MODULE_PARM_DESC(multicast_filter_limit, "maximum number of filtered multicast 
addresses");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] autoparam: script

[Magnus Damm]

The quick ruby hack that generates text from the section data. The script
should probably be rewritten in some other languare to minimize dependencies.
Parameters without types are the result of MODULE_PARM_DESC typos or the use of
MODULE_PARM() instead of module_param() and are treated as errors.

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>

diff -urN linux-2.6.12-rc1/scripts/section2text.rb 
linux-2.6.12-rc1-autoparam/scripts/section2text.rb
--- linux-2.6.12-rc1/scripts/section2text.rb1970-01-01 01:00:00.0 
+0100
+++ linux-2.6.12-rc1-autoparam/scripts/section2text.rb  2005-03-20 
22:53:10.847470760 +0100
@@ -0,0 +1,72 @@
+#!/usr/bin/env ruby
+
+param = {}   # param[parametername] = [ type, description ]
+
+STDIN.read.split("\0").each do | x |
+  if x != ""
+d = x.split
+p = d.shift
+t = d.shift
+
+if d.length > 0
+  d = d.join(" ")
+else
+  d = ""
+end
+
+if param[p]
+  if param[p][0] == "()"
+param[p][0] = t
+  end
+  if param[p][1] == ""
+param[p][1] = d
+  end
+else
+  param[p] = [ t, d ]
+end
+  end
+end
+
+bad = []
+
+param.keys.sort.each do | p |
+  t, d = param[p]
+
+  if t == "()"
+bad << p
+  end
+end
+
+if bad != []
+  STDERR.puts "#{bad.length} error(s):"
+  bad.each do | p |
+STDERR.puts "MODULE_PARM_DESC() on non-existing parameter \"#{p}\""
+  end
+  exit 1
+end
+
+param.keys.sort.each do | p |
+  t, d = param[p]
+
+  if not t
+if p.index("=")
+  t = "(string)"
+else
+  t = "(bool)"
+end
+  end
+
+  if t == "()"
+bad << p
+  else
+puts "#{p} #{t}"
+if d == ""
+  puts "  Unknown"
+else
+  puts "  #{d}"
+end
+puts
+  end
+end
+
+exit 0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] autoparam: ide workarounds

[Magnus Damm]

This patch contains quick fixes that prevents KBUILD_MODNAME conflicts.

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>

diff -urN linux-2.6.12-rc1/drivers/ide/ide-disk.c 
linux-2.6.12-rc1-autoparam/drivers/ide/ide-disk.c
--- linux-2.6.12-rc1/drivers/ide/ide-disk.c 2005-03-20 18:20:16.0 
+0100
+++ linux-2.6.12-rc1-autoparam/drivers/ide/ide-disk.c   2005-03-20 
22:19:34.917938632 +0100
@@ -1179,6 +1179,8 @@
return ide_register_driver(_driver);
 }
 
+#undef ide_disk
+
 module_init(idedisk_init);
 module_exit(idedisk_exit);
 MODULE_LICENSE("GPL");
diff -urN linux-2.6.12-rc1/drivers/ide/ide-floppy.c 
linux-2.6.12-rc1-autoparam/drivers/ide/ide-floppy.c
--- linux-2.6.12-rc1/drivers/ide/ide-floppy.c   2005-03-20 18:20:16.0 
+0100
+++ linux-2.6.12-rc1-autoparam/drivers/ide/ide-floppy.c 2005-03-20 
22:19:34.920938176 +0100
@@ -2117,6 +2117,8 @@
return 0;
 }
 
+#undef ide_floppy
+
 module_init(idefloppy_init);
 module_exit(idefloppy_exit);
 MODULE_LICENSE("GPL");
diff -urN linux-2.6.12-rc1/drivers/ide/ide-tape.c 
linux-2.6.12-rc1-autoparam/drivers/ide/ide-tape.c
--- linux-2.6.12-rc1/drivers/ide/ide-tape.c 2005-03-20 18:20:16.0 
+0100
+++ linux-2.6.12-rc1-autoparam/drivers/ide/ide-tape.c   2005-03-20 
22:19:34.944934528 +0100
@@ -4818,6 +4818,8 @@
return 0;
 }
 
+#undef ide_tape
+
 module_init(idetape_init);
 module_exit(idetape_exit);
 MODULE_ALIAS_CHARDEV_MAJOR(IDETAPE_MAJOR);
diff -urN linux-2.6.12-rc1/drivers/scsi/ide-scsi.c 
linux-2.6.12-rc1-autoparam/drivers/scsi/ide-scsi.c
--- linux-2.6.12-rc1/drivers/scsi/ide-scsi.c2005-03-20 18:20:17.0 
+0100
+++ linux-2.6.12-rc1-autoparam/drivers/scsi/ide-scsi.c  2005-03-20 
22:19:34.946934224 +0100
@@ -1097,6 +1097,8 @@
ide_unregister_driver(_driver);
 }
 
+#undef ide_scsi
+
 module_init(init_idescsi_module);
 module_exit(exit_idescsi_module);
 MODULE_LICENSE("GPL");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] autoparam: af_unix workaround

[Magnus Damm]

This is a quick fix that removes the "KBUILD_MODNAME -> unix -> 1" conflict.

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>

diff -urN linux-2.6.12-rc1/net/unix/af_unix.c 
linux-2.6.12-rc1-autoparam/net/unix/af_unix.c
--- linux-2.6.12-rc1/net/unix/af_unix.c 2005-03-20 18:20:18.0 +0100
+++ linux-2.6.12-rc1-autoparam/net/unix/af_unix.c   2005-03-20 
22:21:24.180328224 +0100
@@ -2080,6 +2080,8 @@
kmem_cache_destroy(unix_sk_cachep);
 }
 
+#undef unix
+
 module_init(af_unix_init);
 module_exit(af_unix_exit);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] autoparam

[Magnus Damm]

Here are a set of patches that makes it possible to autogenerate kernel command
line documentation from the source code. The approach is rather straightforward
- the parameter name, the type and the description are stored in a section 
called __param_strings. After vmlinux is built this section is extracted using
objcopy and a script is used to generate a primitive - but up to date - 
document.

Right now the section is left in the kernel binary. The document is currently
not generated from the Makefile, so the curious user should perform:

$ objcopy -j __param_strings vmlinux -O binary foo
$ chmod a+x scripts/section2text.rb
$ cat foo | ./scripts/section2text.rb

And yeah, you need to install ruby to run the script.

The ruby script section2text.rb does some checks to see if MODULE_PARM_DESC()
is used without module_param(). You will find interesting typos.

Future work that extends this idea could include replacing __setup(name) with 
__setup(name, descr). And storing the documentation somewhere to make it easy
for the end user to look up the generated parameter list from the boot loader.

/ magnus

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

[PATCH 1/5] autoparam: includes

[Magnus Damm]

The code of autoparam - modified include files. Stores parameter name, type 
and description in a section called __param_strings.  

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>

diff -urN linux-2.6.12-rc1/include/linux/init.h 
linux-2.6.12-rc1-autoparam/include/linux/init.h
--- linux-2.6.12-rc1/include/linux/init.h   2005-03-20 18:09:16.0 
+0100
+++ linux-2.6.12-rc1-autoparam/include/linux/init.h 2005-03-20 
22:24:14.393451896 +0100
@@ -125,7 +125,11 @@
__attribute_used__  \
__attribute__((__section__(".init.setup"))) \
__attribute__((aligned((sizeof(long)\
-   = { __setup_str_##unique_id, fn, early }
+   = { __setup_str_##unique_id, fn, early };   \
+   static const char __setup_doc_##unique_id[] \
+   __attribute_used__  \
+   __attribute__((section("__param_strings"))) \
+   = str
 
 #define __setup_null_param(str, unique_id) \
__setup_param(str, unique_id, NULL, 0)
diff -urN linux-2.6.12-rc1/include/linux/module.h 
linux-2.6.12-rc1-autoparam/include/linux/module.h
--- linux-2.6.12-rc1/include/linux/module.h 2005-03-20 18:20:18.0 
+0100
+++ linux-2.6.12-rc1-autoparam/include/linux/module.h   2005-03-20 
22:26:33.666279208 +0100
@@ -128,10 +128,18 @@
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 
+#ifdef MODULE
 /* One for each parameter, describing how to use it.  Some files do
multiple of these per line, so can't just use MODULE_INFO. */
 #define MODULE_PARM_DESC(_parm, desc) \
__MODULE_INFO(parm, _parm, #_parm ":" desc)
+#else
+#define MODULE_PARM_DESC(_parm, desc)  \
+   static const char __param_doc_desc_##_parm[]\
+   __attribute_used__  \
+   __attribute__((section("__param_strings"))) \
+   = __stringify(KBUILD_MODNAME) "." #_parm " () " desc
+#endif
 
 #define MODULE_DEVICE_TABLE(type,name) \
   MODULE_GENERIC_TABLE(type##_device,name)
diff -urN linux-2.6.12-rc1/include/linux/moduleparam.h 
linux-2.6.12-rc1-autoparam/include/linux/moduleparam.h
--- linux-2.6.12-rc1/include/linux/moduleparam.h2005-03-20 
18:20:18.0 +0100
+++ linux-2.6.12-rc1-autoparam/include/linux/moduleparam.h  2005-03-20 
22:29:09.438598216 +0100
@@ -69,6 +69,12 @@
 __attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void * \
= { __param_str_##name, perm, set, get, arg }
 
+#define module_param_doc(prefix, name, type)   \
+   static const char __param_doc_##name[]  \
+   __attribute_used__  \
+   __attribute__((section("__param_strings"))) \
+   = prefix #name " (" #type ")"
+
 #define module_param_call(name, set, get, arg, perm) \
__module_param_call(MODULE_PARAM_PREFIX, name, set, get, arg, perm)
 
@@ -78,7 +84,8 @@
 #define module_param_named(name, value, type, perm)   \
param_check_##type(name, &(value));\
module_param_call(name, param_set_##type, param_get_##type, , 
perm); \
-   __MODULE_PARM_TYPE(name, #type)
+   __MODULE_PARM_TYPE(name, #type);   \
+   module_param_doc(MODULE_PARAM_PREFIX, name, type)
 
 #define module_param(name, type, perm) \
module_param_named(name, name, type, perm)
@@ -89,7 +96,8 @@
= { len, string };  \
module_param_call(name, param_set_copystring, param_get_string, \
   &__param_string_##name, perm);   \
-   __MODULE_PARM_TYPE(name, "string")
+   __MODULE_PARM_TYPE(name, "string"); \
+   module_param_doc(MODULE_PARAM_PREFIX, name, type)
 
 /* Called on module insert or kernel boot */
 extern int parse_args(const char *name,
@@ -151,7 +159,8 @@
sizeof(array[0]), array };  \
module_param_call(name, param_array_set, param_array_get,   \
  &__param_arr_##name, perm);   \
-   __MODULE_PARM_TYPE(name, "array of " #type)
+   __MODULE_PARM_TYPE(name, "array of " #type);\
+   module_param_doc(MODULE_PARAM_PREFIX, name, type)
 
 #define module_param_array(name, type, nump, perm) \
module_param_array_named(name, name, type, nump, perm)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

Re: [new patch] Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/w100fb.c and add if()+comment back in drivers/video/console/bitblit.c

[Antonino A. Daplas]

On Monday 21 March 2005 06:45, Jesper Juhl wrote:
> On Sun, 20 Mar 2005, Jesper Juhl wrote:
> > On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > > On Monday 21 March 2005 06:02, Jesper Juhl wrote:
> > > > On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > > > > On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > > > > > Checking a pointer for NULL before calling kfree() on it is
> > > > > > redundant, kfree() deals with NULL pointers just fine.
> > > > > > This patch removes such checks from files in drivers/video/
> > > > >
> > > > > [snip]
> > > > >
> > > > > > ---
> > > > > > linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c   
> > > > > > 2005-03-16
> > > > > > 15:45:26.0 +0100 +++
> > > > > > linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-19
> > > > > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void
> > > > > > bit_putcs(struct vc_data *vc
> > > > > > count -= cnt;
> > > > > > }
> > > > > >
> > > > > > -   if (buf)
> > > > > > -   kfree(buf);
> > > > > > +   kfree(buf);
> > > > > >  }
> > > > >
> > > > > This is performance critical, so I would like the check to remain.
> > > > > A comment may be added in this section.
> > > >
> > > > Ok, I believe Andrew already merged the patch into -mm, if you really
> > > > want that check back then I'll send him a patch to put it back and
> > > > add a comment once he puts out the next -mm.
> > > > But, at the risk of exposing my ignorance, I have to ask if it
> > > > wouldn't actually perform better /without/ the if(buf) bit?  The
> > > > reason I say that is that the generated code shrinks quite a bit when
> > > > it's removed, and also kfree() itself does the same NULL check as the
> > > > very first thing, so it comes down to the bennefit of shorter
> > > > generated code, one less branch, against the overhead of a function
> > > > call - and how often will 'buf' be NULL? if buff is != NULL the
> > > > majority of the time, then it should be a gain to remove the if().
> > >
> > > You said it, buf is almost always NULL, except when the driver is in
> > > monochrome mode.  So a kfree is rarely done.
> >
> > I see, then my change in this exact spot woul probably be a loss in the
> > general case. Thank you for explaining.
> >
> > > Anyway, if the patch is already in the tree, let's leave it at that.  I
> > > would surmise that the performance loss is negligible.
> >
> > Well, I just spotted two cases I missed in drivers/video/ , so when I
> > send that patch I might as well include a hunk that puts this one check
> > back including a comment as to why it should stay.
>
> One case turned out not to be one when I took a closer look, so I actually
> only missed one. Here's a patch to fix that last one and also put the
> check in bitblit.c back.
> (Andrew: this should apply on top of what you already merged)
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
>
> --- linux-2.6.11-mm4/drivers/video/console/bitblit.c~ 2005-03-20
> 23:40:58.0 +0100 +++
> linux-2.6.11-mm4/drivers/video/console/bitblit.c  2005-03-20
> 23:40:58.0 +0100 @@ -199,7 +199,11 @@ static void bit_putcs(struct
> vc_data *vc
>   count -= cnt;
>   }
>
> - kfree(buf);
> + /* buf is always NULL except when in monochrome mode, so in this case
> +it's a gain to check buf against NULL even though kfree() handles
> +NULL pointers just fine */
> + if (buf)
> + kfree(buf);
>  }
>

As Joe Perch suggested, an if (unlikely(buf)) is better.

Tony

--- linux-2.6.11-mm4/drivers/video/console/bitblit.c~   2005-03-20 
23:40:58.0 +0100
+++ linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-20 
23:40:58.0 +0100
@@ -199,7 +199,11 @@ static void bit_putcs(struct vc_data *vc
count -= cnt;
}
 
-   kfree(buf);
+   /* buf is always NULL except when in monochrome mode, so in this case
+  it's a gain to check buf against NULL even though kfree() handles
+  NULL pointers just fine */
+   if (unlikely(buf))
+   kfree(buf);
 }
 


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

Re: Bitrotting serial drivers

[Pete Popov]

Ralf Baechle wrote:
On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote:

au1x00_uart
---
Maintainer: unknown (akpm - any ideas?)
Ralf.

Actually Pete Popov ([EMAIL PROTECTED]) who I put on the cc.
Thanks :)
This is a complete clone of 8250.c, which includes all the 8250-specific
structure names.
Specifically, I'd like to see the following addressed:
- Please clean this up to use au1x00-specific names.
- this driver is lagging behind with fixes that the other drivers are
 getting.  Is au1x00_uart actually maintained?

Sort of; much of the Alchemy development effort is still going into 2.4.
It works and no one has complained about any bugs. But you're right, fixes going 
into other drivers have not made it into this one.

- the usage of UPIO_HUB6
 (this driver doesn't support hub6 cards)
- __register_serial, register_serial, unregister_serial
 (this driver doesn't support PCMCIA cards, all of which are based on
  8250-compatible devices.)
- early_serial_setup
 (should we really have the function name duplicated across different
  hardware drivers?)

No argument here.  Pete says the AMD Alchemy UART is just different enough
to be hard to handle in the 8250 and so the driver is just an ugly
chainsawed version of the 8250.c

The main reason is I wish to kill off uart_register_port and
uart_unregister_port, but these drivers are using it.
I tried a couple of times to cleanly add support to the 8250 for the Au1x 
serial. The uart is just different enough to make that hard, though I admit I 
never spent too much time on it. Sounds like it's time to revisit it again.

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

[new patch] Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/w100fb.c and add if()+comment back in drivers/video/console/bitblit.c

[Jesper Juhl]

On Sun, 20 Mar 2005, Jesper Juhl wrote:

> 
> On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > On Monday 21 March 2005 06:02, Jesper Juhl wrote:
> > > On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > > > On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > > > > Checking a pointer for NULL before calling kfree() on it is redundant,
> > > > > kfree() deals with NULL pointers just fine.
> > > > > This patch removes such checks from files in drivers/video/
> > > > >
> > > > [snip]
> > > >
> > > > > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 
> > > > > 2005-03-16
> > > > > 15:45:26.0 +0100 +++
> > > > > linux-2.6.11-mm4/drivers/video/console/bitblit.c  2005-03-19
> > > > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void
> > > > > bit_putcs(struct vc_data *vc
> > > > >   count -= cnt;
> > > > >   }
> > > > >
> > > > > - if (buf)
> > > > > - kfree(buf);
> > > > > + kfree(buf);
> > > > >  }
> > > >
> > > > This is performance critical, so I would like the check to remain. A
> > > > comment may be added in this section.
> > >
> > > Ok, I believe Andrew already merged the patch into -mm, if you really want
> > > that check back then I'll send him a patch to put it back and add a
> > > comment once he puts out the next -mm.
> > > But, at the risk of exposing my ignorance, I have to ask if it wouldn't
> > > actually perform better /without/ the if(buf) bit?  The reason I say that
> > > is that the generated code shrinks quite a bit when it's removed, and also
> > > kfree() itself does the same NULL check as the very first thing, so it
> > > comes down to the bennefit of shorter generated code, one less branch,
> > > against the overhead of a function call - and how often will 'buf' be
> > > NULL? if buff is != NULL the majority of the time, then it should be a
> > > gain to remove the if().
> > 
> > You said it, buf is almost always NULL, except when the driver is in
> > monochrome mode.  So a kfree is rarely done.
> > 
> I see, then my change in this exact spot woul probably be a loss in the 
> general case. Thank you for explaining.
> 
> > Anyway, if the patch is already in the tree, let's leave it at that.  I 
> > would
> > surmise that the performance loss is negligible.
> > 
> Well, I just spotted two cases I missed in drivers/video/ , so when I send 
> that patch I might as well include a hunk that puts this one check back 
> including a comment as to why it should stay.
> 
One case turned out not to be one when I took a closer look, so I actually 
only missed one. Here's a patch to fix that last one and also put the 
check in bitblit.c back.
(Andrew: this should apply on top of what you already merged)


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.11-mm4/drivers/video/console/bitblit.c~   2005-03-20 
23:40:58.0 +0100
+++ linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-20 
23:40:58.0 +0100
@@ -199,7 +199,11 @@ static void bit_putcs(struct vc_data *vc
count -= cnt;
}
 
-   kfree(buf);
+   /* buf is always NULL except when in monochrome mode, so in this case
+  it's a gain to check buf against NULL even though kfree() handles
+  NULL pointers just fine */
+   if (buf)
+   kfree(buf);
 }
 
 static void bit_clear_margins(struct vc_data *vc, struct fb_info *info,
--- linux-2.6.11-mm4-orig/drivers/video/w100fb.c2005-03-16 
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/w100fb.c 2005-03-20 23:33:58.0 
+0100
@@ -537,10 +537,8 @@ static void w100fb_clear_buffer(void)
 {
int i;
for (i = 0; i < W100_BUF_NUM; i++) {
-   if (gSaveImagePtr[i] != NULL) {
-   kfree(gSaveImagePtr[i]);
-   gSaveImagePtr[i] = NULL;
-   }
+   kfree(gSaveImagePtr[i]);
+   gSaveImagePtr[i] = NULL;
}
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] i386/x86_64 mpparse.c: kill maxcpus

[Dave Jones]

On Sun, Mar 20, 2005 at 08:25:49PM +0100, Adrian Bunk wrote:
 > Do we really need a global variable that does only hold the value of 
 > NR_CPUS?

Yes.
 
NR_CPUS = compile time
maxcpus = boot command line at runtime.

Dave

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

Re: Bitrotting serial drivers

[Ralf Baechle]

On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote:

> > au1x00_uart
> > ---
> > 
> > Maintainer: unknown (akpm - any ideas?)
> 
> Ralf.

Actually Pete Popov ([EMAIL PROTECTED]) who I put on the cc.

> > This is a complete clone of 8250.c, which includes all the 8250-specific
> > structure names.
> > 
> > Specifically, I'd like to see the following addressed:
> > 
> > - Please clean this up to use au1x00-specific names.
> > - this driver is lagging behind with fixes that the other drivers are
> >   getting.  Is au1x00_uart actually maintained?

Sort of; much of the Alchemy development effort is still going into 2.4.

> > - the usage of UPIO_HUB6
> >   (this driver doesn't support hub6 cards)
> > - __register_serial, register_serial, unregister_serial
> >   (this driver doesn't support PCMCIA cards, all of which are based on
> >8250-compatible devices.)
> > - early_serial_setup
> >   (should we really have the function name duplicated across different
> >hardware drivers?)

No argument here.  Pete says the AMD Alchemy UART is just different enough
to be hard to handle in the 8250 and so the driver is just an ugly
chainsawed version of the 8250.c

> > The main reason is I wish to kill off uart_register_port and
> > uart_unregister_port, but these drivers are using it.

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

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[Paul E. McKenney]

On Sat, Mar 19, 2005 at 11:32:59PM -0500, Lee Revell wrote:
> On Sat, 2005-03-19 at 19:50 -0600, K.R. Foley wrote:
> > Lee Revell wrote:
> > > On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
> > > 
> > >>the biggest change in this patch is the merge of Paul E. McKenney's
> > >>preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it
> > >>is still quite experimental at this stage, it allowed the removal of
> > >>locking cruft (mainly in the networking code), so it could solve some of
> > >>the longstanding netfilter/networking deadlocks/crashes reported by a
> > >>number of people. Be careful nevertheless.
> > > 
> > > 
> > > With PREEMPT_RT my machine deadlocked within 20 minutes of boot.
> > > "apt-get dist-upgrade" seemed to trigger the crash.  I did not see any
> > > Oops unfortunately.
> > > 
> > > Lee
> > > 
> > 
> > Lee,
> > 
> > Just curious. Is this with UP or SMP? I currently have my UP box running 
> >   PREEMPT_RT, with no problems thus far. However, my SMP box dies while 
> > booting (with an oops). I am working on trying to get setup to capture 
> > the oops, although it might be tomorrow before I get that done.
> > 
> 
> UP.  It's 100% reproducible, this machine locks up over and over.  Seems
> to be associated with network activity by multiple processes.

OK, guess I need to go inspect the uses of synchronize_net() in addition
to synchronize_kernel...

If you do manage to get any additional info, please let me know...

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

Re: Real-Time Preemption and RCU

[Paul E. McKenney]

On Sun, Mar 20, 2005 at 02:29:17PM +0100, Esben Nielsen wrote:
> On Fri, 18 Mar 2005, Ingo Molnar wrote:
> 
> > 
> > * Esben Nielsen <[EMAIL PROTECTED]> wrote:
> > 
> > > Why can should there only be one RCU-reader per CPU at each given
> > > instance? Even on a real-time UP system it would be very helpfull to
> > > have RCU areas to be enterable by several tasks as once. It would
> > > perform better, both wrt. latencies and throughput: With the above
> > > implementation an high priority task entering an RCU area will have to
> > > boost the current RCU reader, make a task switch until that one
> > > finishes and makes yet another task switch. to get back to the high
> > > priority task. With an RCU implementation which can take n RCU readers
> > > per CPU there is no such problem.
> > 
> > correct, for RCU we could allow multiple readers per lock, because the
> > 'blocking' side of RCU (callback processing) is never (supposed to be)
> > in any latency path.
> > 
> > except if someone wants to make RCU callback processing deterministic at
> > some point. (e.g. for memory management reasons.)
> 
> I think it can be deterministic (on the long timescale of memory management) 
> anyway: Boost any non-RT task entering an RCU region to the lowest RT 
> priority.
> This way only all the RT tasks + one non-RT task can be within those
> regions. The RT-tasks are supposed to have some kind of upper bound to
> their CPU-usage. The non-RT task will also finish "soon" as it is
> boosted. If the RCU batches are also at the lowest RT-priority they can be
> run immediately after the non-RT task is done.

Hmmm...  Sort of a preemptive-first-strike priority boost.  Cute!  ;-)

> > clearly the simplest solution is to go with the single-reader locks for
> > now - a separate experiment could be done with a new type of rwlock that
> > can only be used by the RCU code. (I'm not quite sure whether we could
> > guarantee a minimum rate of RCU callback processing under such a scheme
> > though. It's an eventual memory DoS otherwise.)
> > 
> 
> Why are a lock needed at all? If it is doable without locking for an
> non-preemptable SMP kernel it must be doable for an preemptable kernel as
> well.I am convinced some kind of per-CPU rcu_read_count as I specified in
> my previous mail can work some way or the other. call_rcu() might need to
> do more complicated stuff and thus use CPU but call_rcu() is supposed to
> be an relative rare event not worth optimizing for.  Such an
> implementation will work for any preemptable kernel, not only PREEMPT_RT. 
> For performance is considered it is important not to acquire any locks in
> the rcu-read regions. 

You definitely don't need a lock -- you can just suppress preemption
on the read side instead.  But that potentially makes for long scheduling
latencies.

The counter approach might work, and is also what the implementation #5
does -- check out rcu_read_lock() in Ingo's most recent patch.

Thanx, Paul

> I tried this approach. My UP labtop did boot on it, but I haven't testet
> it further. I have included the very small patch as an attachment.
> 
> > Ingo
> 
> I have not yet looked at -V0.7.41-00...
> 
> Esben
> 

> diff -Naur --exclude-from diff_exclude 
> linux-2.6.11-final-V0.7.40-00/include/linux/rcupdate.h 
> linux-2.6.11-final-V0.7.40-00-RCU/include/linux/rcupdate.h
> --- linux-2.6.11-final-V0.7.40-00/include/linux/rcupdate.h2005-03-11 
> 23:40:13.0 +0100
> +++ linux-2.6.11-final-V0.7.40-00-RCU/include/linux/rcupdate.h
> 2005-03-19 12:47:09.0 +0100
> @@ -85,6 +85,7 @@
>   * curlist - current batch for which quiescent cycle started if any
>   */
>  struct rcu_data {
> + longactive_readers;
>   /* 1) quiescent state handling : */
>   longquiescbatch; /* Batch # for grace period */
>   int passed_quiesc;   /* User-mode/idle loop etc. */
> @@ -115,12 +116,14 @@
>  static inline void rcu_qsctr_inc(int cpu)
>  {
>   struct rcu_data *rdp = _cpu(rcu_data, cpu);
> - rdp->passed_quiesc = 1;
> + if(rdp->active_readers==0)
> + rdp->passed_quiesc = 1;
>  }
>  static inline void rcu_bh_qsctr_inc(int cpu)
>  {
>   struct rcu_data *rdp = _cpu(rcu_bh_data, cpu);
> - rdp->passed_quiesc = 1;
> + if(rdp->active_readers==0)
> + rdp->passed_quiesc = 1;
>  }
>  
>  static inline int __rcu_pending(struct rcu_ctrlblk *rcp,
> @@ -183,29 +186,27 @@
>   *
>   * It is illegal to block while in an RCU read-side critical section.
>   */
> -#define rcu_read_lock()  preempt_disable()
> +static inline void rcu_read_lock(void)
> +{
> + preempt_disable(); 
> + __get_cpu_var(rcu_data).active_readers++;
> + preempt_enable();
> +}
>  
>  /**
>   * rcu_read_unlock - marks the end of an RCU read-side critical section.
>   *
>   * See rcu_read_lock() for more information.
>   */
> -#define rcu_read_unlock()

RE: [patch] arch hook for notifying changes in PTE protections bits

[Seth, Rohit]

David S. Miller  wrote on Saturday, March
19, 2005 4:27 PM:

> On Sat, 19 Mar 2005 12:30:05 -0800
> David Mosberger <[EMAIL PROTECTED]> wrote:
> 
>> I agree about your concern about cost.  Accessing the page_map is
>> expensive (integer division + memory access) and we have to do that
>> in order to find out if the page is i-cache clean.
> 
> First, it's a multiply by reciprocol.  At least on sparc64 I get
> this emitted by the compiler.
> 
> Secondly, if you're willing to sacrifice 8 bytes per page struct
> simply define WANT_PAGE_VIRTUAL and page struct will be exactly
> 64 bytes and thus the divide a will turn into a simple shift.

As said earlier, set_pte_at is getting called from different places.
Not all of these times, we are actually installing valid page entries in
page tables.  Validating the incoming entry for all of these scenarois
(or changing page struct) is an extra overhead that should be
avoided...besides being less palatable as compared to new API.

The recent changes in interfaces, because of set_pte_at, does provide an
opportunity though to handle mprotect issue little differently.  We
could call update_mmu_cache after setting the new protections in
change_pte_range function.similar to the way update_mmu_cache gets
called at fault and any other times..though for this solution, we
need to extend change_pte_range interface to have vma parameter as well.



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

Re: [patch][resend] convert a remaining verify_area to access_ok (was: Re: [PATCH 2.6.11-mm1] mips: more convert verify_area to access_ok) (fwd)

[Ralf Baechle]

On Fri, Mar 18, 2005 at 01:17:47AM +0100, Jesper Juhl wrote:

> I hope I did a descent job and that you didn't waste too much time 
> duplicating effort...

Didn't look too hard at it since my patch of something like 2,500 lines
should be a superset of yours.

> > The last instance of verify_area() in the MIPS code is now the definition
> > itself.
> > 
> The plan is to wait for a few months (or a few kernel releases - whichever 
> comes first) and then I'll send Andrew patches to remove it completely.
> There are still a few related nits left, like the FPU_verify_area function 
> arch/i386/math-emu/reg_ld_str.c and the rw_verify_area function in 
> fs/read_write.c that I want to get out of the way first (think I'll 
> probably end up attempting to rename those s/verify_area/access_ok/ and 
> see if people scream).

Access_ok was introduced in 2.1.4.  Easy for people to write code that's
portable and so verify_area should die a peaceful death.

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

Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Jesper Juhl]

On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> On Monday 21 March 2005 06:02, Jesper Juhl wrote:
> > On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > > On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > > > Checking a pointer for NULL before calling kfree() on it is redundant,
> > > > kfree() deals with NULL pointers just fine.
> > > > This patch removes such checks from files in drivers/video/
> > > >
> > > [snip]
> > >
> > > > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c   
> > > > 2005-03-16
> > > > 15:45:26.0 +0100 +++
> > > > linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-19
> > > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void
> > > > bit_putcs(struct vc_data *vc
> > > > count -= cnt;
> > > > }
> > > >
> > > > -   if (buf)
> > > > -   kfree(buf);
> > > > +   kfree(buf);
> > > >  }
> > >
> > > This is performance critical, so I would like the check to remain. A
> > > comment may be added in this section.
> >
> > Ok, I believe Andrew already merged the patch into -mm, if you really want
> > that check back then I'll send him a patch to put it back and add a
> > comment once he puts out the next -mm.
> > But, at the risk of exposing my ignorance, I have to ask if it wouldn't
> > actually perform better /without/ the if(buf) bit?  The reason I say that
> > is that the generated code shrinks quite a bit when it's removed, and also
> > kfree() itself does the same NULL check as the very first thing, so it
> > comes down to the bennefit of shorter generated code, one less branch,
> > against the overhead of a function call - and how often will 'buf' be
> > NULL? if buff is != NULL the majority of the time, then it should be a
> > gain to remove the if().
> 
> You said it, buf is almost always NULL, except when the driver is in
> monochrome mode.  So a kfree is rarely done.
> 
I see, then my change in this exact spot woul probably be a loss in the 
general case. Thank you for explaining.

> Anyway, if the patch is already in the tree, let's leave it at that.  I would
> surmise that the performance loss is negligible.
> 
Well, I just spotted two cases I missed in drivers/video/ , so when I send 
that patch I might as well include a hunk that puts this one check back 
including a comment as to why it should stay.


-- 
Jesper 

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

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[Paul E. McKenney]

On Sat, Mar 19, 2005 at 08:16:58PM +0100, Ingo Molnar wrote:
> 
> i have released the -V0.7.41-00 Real-Time Preemption patch (merged to
> 2.6.12-rc1), which can be downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> the biggest change in this patch is the merge of Paul E. McKenney's
> preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it
> is still quite experimental at this stage, it allowed the removal of
> locking cruft (mainly in the networking code), so it could solve some of
> the longstanding netfilter/networking deadlocks/crashes reported by a
> number of people. Be careful nevertheless.
> 
> there are a couple of minor changes relative to Paul's latest
> preemptable-RCU code drop:
> 
>  - made the two variants two #ifdef blocks - this is sufficient for now
>and we'll see what the best way is in the longer run.
> 
>  - moved rcu_check_callbacks() from the timer IRQ to ksoftirqd. (the
>timer IRQ still runs in hardirq context on PREEMPT_RT.)
> 
>  - changed the irq-flags method to a preempt_disable()-based method, and
>moved the lock taking outside of the critical sections. (due to locks
>potentially sleeping on PREEMPT_RT).
> 
> to create a -V0.7.41-00 tree from scratch, the patching order is:
> 
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz2
>   
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc1-V0.7.41-00

Some proposed fixes from a quick scan (untested, probably does not even
compile).  These proposed fixes fall into the following categories:

o   Some functions that should be static.

o   Introduced a synchronize_kernel_barrier() for a number of
uses of synchronize_kernel() that are broken by the new
implementation.  Note that synchronize_kernel_barrier() is
the same as synchronize_kernel() in non-CONFIG_PREEMPT_RT
kernels.  Not clear that synchronize_kernel_barrier()
is strong enough for some uses, may need another API
(synchronize_kernel_barrier_voluntary()???) that waits for all
tasks to -voluntary- context switch or be executing in user
space (these are marked with FIXME in the attached patch).
Dipankar and/or Rusty put out a patch that did this some time
back -- this was when we were trying to make an RCU that worked
in CONFIG_PREEMPT kernels, but did not want preempt_disable()
on the read side.

That said, some of the synchronize_kernel_barrier()s marked
with FIXME may be fixable more simply by inserting
rcu_read_lock()/rcu_read_unlock() pairs in appropriate
places.

o   Merged the two identical implementations each of
rcu_dereference() and rcu_assign_pointer().

o   Added an rcu_read_lock() or two.  Clearly need to be searching
for patches containing "synchronize_kernel" in addition to
patches containing "rcu"...

Thoughts?

Thanx, Paul

Signed-off-by: <[EMAIL PROTECTED]>

diff -urpN -X dontdiff linux-2.6.11/arch/i386/oprofile/nmi_timer_int.c 
linux-2.6.11.fixes/arch/i386/oprofile/nmi_timer_int.c
--- linux-2.6.11/arch/i386/oprofile/nmi_timer_int.c Tue Mar  1 23:37:52 2005
+++ linux-2.6.11.fixes/arch/i386/oprofile/nmi_timer_int.c   Sun Mar 20 
08:40:31 2005
@@ -36,7 +36,7 @@ static void timer_stop(void)
 {
enable_timer_nmi_watchdog();
unset_nmi_callback();
-   synchronize_kernel();
+   synchronize_kernel_barrier();
 }
 
 
diff -urpN -X dontdiff linux-2.6.11/arch/ppc64/kernel/ItLpQueue.c 
linux-2.6.11.fixes/arch/ppc64/kernel/ItLpQueue.c
--- linux-2.6.11/arch/ppc64/kernel/ItLpQueue.c  Tue Mar  1 23:37:48 2005
+++ linux-2.6.11.fixes/arch/ppc64/kernel/ItLpQueue.cSun Mar 20 08:48:29 2005
@@ -142,7 +142,9 @@ unsigned ItLpQueue_process( struct ItLpQ

lpQueue->xLpIntCountByType[nextLpEvent->xType]++;
if ( nextLpEvent->xType < HvLpEvent_Type_NumTypes &&
 lpEventHandler[nextLpEvent->xType] ) 
+   rcu_read_lock();
lpEventHandler[nextLpEvent->xType](nextLpEvent, 
regs);
+   rcu_read_unlock();
else
printk(KERN_INFO "Unexpected Lp Event 
type=%d\n", nextLpEvent->xType );

diff -urpN -X dontdiff linux-2.6.11/arch/x86_64/kernel/mce.c 
linux-2.6.11.fixes/arch/x86_64/kernel/mce.c
--- linux-2.6.11/arch/x86_64/kernel/mce.c   Tue Mar  1 23:37:52 2005
+++ linux-2.6.11.fixes/arch/x86_64/kernel/mce.c Sun Mar 20 08:49:45 2005
@@ -392,7 +392,7 @@ static ssize_t mce_read(struct file *fil
memset(mcelog.entry, 0, next * sizeof(struct mce));
mcelog.next = 0;
 
-   synchronize_kernel();   
+   

Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Antonino A. Daplas]

On Monday 21 March 2005 05:49, Geert Uytterhoeven wrote:
> On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > > Checking a pointer for NULL before calling kfree() on it is redundant,
> > > kfree() deals with NULL pointers just fine.
> > > This patch removes such checks from files in drivers/video/
> > >
> > > Since this is a fairly trivial change (and the same change made
> > > everywhere) I've just made a single patch for all the files and CC all
> > > authors/maintainers of those files I could find for comments. If
> > > spliting this into one patch pr file is prefered, then I can easily do
> > > that as well.
> >
> > [snip]
> >
> > > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 2005-03-16
> > > 15:45:26.0 +0100 +++
> > > linux-2.6.11-mm4/drivers/video/console/bitblit.c  2005-03-19
> > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void
> > > bit_putcs(struct vc_data *vc
> > >   count -= cnt;
> > >   }
> > >
> > > - if (buf)
> > > - kfree(buf);
> > > + kfree(buf);
> > >  }
> >
> > This is performance critical, so I would like the check to remain. A
> > comment may be added in this section.
>
> The first thing kfree() does is check for the NULL pointer. And since
> kfree() is used a lot, it's probably already in the cache.

It's not the kfree that matters, but the fact that buf is almost always NULL.

Tony


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

Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Antonino A. Daplas]

On Monday 21 March 2005 06:02, Jesper Juhl wrote:
> On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > > Checking a pointer for NULL before calling kfree() on it is redundant,
> > > kfree() deals with NULL pointers just fine.
> > > This patch removes such checks from files in drivers/video/
> > >
> > > Since this is a fairly trivial change (and the same change made
> > > everywhere) I've just made a single patch for all the files and CC all
> > > authors/maintainers of those files I could find for comments. If
> > > spliting this into one patch pr file is prefered, then I can easily do
> > > that as well.
> >
> > [snip]
> >
> > > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 2005-03-16
> > > 15:45:26.0 +0100 +++
> > > linux-2.6.11-mm4/drivers/video/console/bitblit.c  2005-03-19
> > > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void
> > > bit_putcs(struct vc_data *vc
> > >   count -= cnt;
> > >   }
> > >
> > > - if (buf)
> > > - kfree(buf);
> > > + kfree(buf);
> > >  }
> >
> > This is performance critical, so I would like the check to remain. A
> > comment may be added in this section.
>
> Ok, I believe Andrew already merged the patch into -mm, if you really want
> that check back then I'll send him a patch to put it back and add a
> comment once he puts out the next -mm.
> But, at the risk of exposing my ignorance, I have to ask if it wouldn't
> actually perform better /without/ the if(buf) bit?  The reason I say that
> is that the generated code shrinks quite a bit when it's removed, and also
> kfree() itself does the same NULL check as the very first thing, so it
> comes down to the bennefit of shorter generated code, one less branch,
> against the overhead of a function call - and how often will 'buf' be
> NULL? if buff is != NULL the majority of the time, then it should be a
> gain to remove the if().

You said it, buf is almost always NULL, except when the driver is in
monochrome mode.  So a kfree is rarely done.

Anyway, if the patch is already in the tree, let's leave it at that.  I would
surmise that the performance loss is negligible.

Tony


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

USB mouse hiccups (was RFD: Kernel release numbering)

[viking]

-blather-
It took a few days before I actually saw this posting. I also agree that
2.6.10 seems to be more stable than 2.6.11 - mind you, that could be
because I'm using 2.6.10-linus (i.e. the tarball from the linux.org site)
and the 2.6.11 is a Mandrake-ised kernel + Linus patches - at least I
*think* they're Linus' patches - no Visual Basic in them yet.
I've also noted .10 is quicker off the blocks than 2.6.11 seems to be.

-meat-
I did note something strange. I'm running 2.6.11.2 at this moment, when I
tried 2.6.11.3, my USB Microsoft Wireless Optical Mouse stopped moving
from left to right, and would only move up and down if I physically moved
the mouse from left to right. I didn't see anything in the patches that
touched anything in the event handling, so frankly I'm puzzled.
Any clues as to where I need to look? I've seen this problem before, but
don't know what causes it, nor how I fixed it at the time.
Also, how do I get that patch that enables the tiltwheel (left-right
events)?

-blather-
I'll try out .5 once I fetch the patch and spend another three hours on my
cluster, compiling. Again. The reason I haven't dipped into real testing
of kernels was precisely for this reason, that I didn't want to have to
spend absolutely ages waiting for a compile. However, I've finally decided
to dip my toes back in the water, with the 2.6.11 series...

Love the Suspend-to-disk... only wish I could load a saved image into a
later kernel, though I understand why this can't be done. That would be my
current "killer app".

'Nuff mumbling.

CC if you wish, but I ought to be watching the list again for this one.

-- 
 /|   _,.:*^*:.,   |\  Cheers from the Viking family, including Pippin, our cat
| |_/'  viking@ `\_| |
|flying-brick| $FunnyMail   : What do you mean, I've lost the plot?
 \_.caverock.net.nz_/ 5.40  : I planted them carrots right here!!

-- 
 /|   _,.:*^*:.,   |\  Cheers from the Viking family, including Pippin, our cat
| |_/'  viking@ `\_| |
|flying-brick| $FunnyMail   : What do you mean, I've lost the plot?
 \_.caverock.net.nz_/ 5.40  : I planted them carrots right here!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Jan Engelhardt]

>>...
>
>This is performance critical, so I would like the check to remain. A comment
>may be added in this section.

Hm, if we used Yoshifuji's inline kfree(), you'd get both. A check and a clean 
code. (Though I would not move kfree to __kfree, but make the inline variant 
explicitly different named.)



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

Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Jesper Juhl]

On Mon, 21 Mar 2005, Antonino A. Daplas wrote:

> On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > Checking a pointer for NULL before calling kfree() on it is redundant,
> > kfree() deals with NULL pointers just fine.
> > This patch removes such checks from files in drivers/video/
> >
> > Since this is a fairly trivial change (and the same change made
> > everywhere) I've just made a single patch for all the files and CC all
> > authors/maintainers of those files I could find for comments. If spliting
> > this into one patch pr file is prefered, then I can easily do that as
> > well.
> >
> 
> [snip]
> 
> > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c   2005-03-16
> > 15:45:26.0 +0100 +++
> > linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-19
> > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void bit_putcs(struct
> > vc_data *vc
> > count -= cnt;
> > }
> >
> > -   if (buf)
> > -   kfree(buf);
> > +   kfree(buf);
> >  }
> >
> 
> This is performance critical, so I would like the check to remain. A comment
> may be added in this section.
> 
Ok, I believe Andrew already merged the patch into -mm, if you really want 
that check back then I'll send him a patch to put it back and add a 
comment once he puts out the next -mm.
But, at the risk of exposing my ignorance, I have to ask if it wouldn't 
actually perform better /without/ the if(buf) bit?  The reason I say that 
is that the generated code shrinks quite a bit when it's removed, and also 
kfree() itself does the same NULL check as the very first thing, so it 
comes down to the bennefit of shorter generated code, one less branch, 
against the overhead of a function call - and how often will 'buf' be 
NULL? if buff is != NULL the majority of the time, then it should be a 
gain to remove the if().


> >  static void bit_clear_margins(struct vc_data *vc, struct fb_info *info,
> > @@ -273,8 +272,7 @@ static void bit_cursor(struct vc_data *v
> > dst = kmalloc(w * vc->vc_font.height, GFP_ATOMIC);
> > if (!dst)
> > return;
> > -   if (ops->cursor_data)
> > -   kfree(ops->cursor_data);
> > +   kfree(ops->cursor_data);
> > ops->cursor_data = dst;
> > update_attr(dst, src, attribute, vc);
> > src = dst;
> > @@ -321,8 +319,7 @@ static void bit_cursor(struct vc_data *v
> > if (!mask)
> > return;
> >
> > -   if (ops->cursor_state.mask)
> > -   kfree(ops->cursor_state.mask);
> > +   kfree(ops->cursor_state.mask);
> > ops->cursor_state.mask = mask;
> 
> Although these are also performance critical, I will agree that the checks
> can go.  Very rarely will ops->cursor_state.mask and ops->cursor_data be
> NULL.
> 
> As for the rest, they are acceptable, as long as the maintainers agree.
> 
Ok, thank you for commenting.


-- 
Jesper Juhl

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

Re: Real-Time Preemption and RCU

[hui]

On Sun, Mar 20, 2005 at 01:38:24PM -0800, Bill Huey wrote:
> On Sun, Mar 20, 2005 at 05:57:23PM +0100, Manfred Spraul wrote:
> > That was just one random example.
> > Another one would be :
> > 
> > drivers/chat/tty_io.c, __do_SAK() contains
> >read_lock(_lock);
> >task_lock(p);
> > 
> > kernel/sys.c, sys_setrlimit contains
> >task_lock(current->group_leader);
> >read_lock(_lock);
> > 
> > task_lock is a shorthand for spin_lock(>alloc_lock). If read_lock is 
> > a normal spinlock, then this is an A/B B/A deadlock.
> 
> That code was already dubious in the first place just because it
> contained that circularity. If you had a rwlock that block on an
> upper read count maximum[,] a deadlock situation would trigger anyways,
> say, upon a flood of threads trying to do that sequence of aquires.

The RT patch uses the lock ordering "in place" and whatevery nasty
situation was going on previously will be effectively under high load,
which increases the chance of it being triggered. Removal of the read
side semantic just increases load more so that those cases can trigger.

I disagree with this approach and I have an alternate implementation
here that restores it. It's only half tested and fairly meaningless
until an extreme contention case is revealed with the current rt lock
implementation. Numbers need to be gather to prove or disprove this
conjecture.

> I'd probably experiment with using the {spin,read,write}-trylock
> logic and release the all locks contains in a sequence like that
> on the failure to aquire any of the locks in the chain as an
> initial fix. A longer term fix might be to break things up a bit
> so that whatever ordering being done would have that circularity.

Excuse me, ...would *not* have that circularity.

bill

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

Re: fuse is cool and robust

[Jan Engelhardt]

>I do understand that a filesystem is a particularly poor API for many
>things, and I'm not in favour of 'sqlfs' or 'ftpfs', but fuse IS a great
>enabler. 'encfs' would be hard to do from kernel space (or at least, a lot
>harder). http://arg0.net/users/vgough/encfs.html

encfs being hard from kernel space? I've seen a whole cryptoloop in the 
kernel. Can't be "hard". At least unpracticable.


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

Re: af_unix.c, KBUILD_MODNAME and unix

[Jan Engelhardt]

>> Why is not KBUILD_MODNAME=af_unix ?
>
>The exact solution does not matter that much to me, and I'm afraid I
>do not know how changing KBUILD_MODNAME affects the rest of the
>codebase. So basically - someone else should decide... but who?

KBUILD_MODNAME is "not used", which means you can use it for anything that 
like. You can undef it, redefine, thwap it all over and whatnot.
It's a generosity from /usr/bin/make generally providing the module with its 
own name.




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

Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Geert Uytterhoeven]

On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > Checking a pointer for NULL before calling kfree() on it is redundant,
> > kfree() deals with NULL pointers just fine.
> > This patch removes such checks from files in drivers/video/
> >
> > Since this is a fairly trivial change (and the same change made
> > everywhere) I've just made a single patch for all the files and CC all
> > authors/maintainers of those files I could find for comments. If spliting
> > this into one patch pr file is prefered, then I can easily do that as
> > well.
> >
> 
> [snip]
> 
> > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c   2005-03-16
> > 15:45:26.0 +0100 +++
> > linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-19
> > 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void bit_putcs(struct
> > vc_data *vc
> > count -= cnt;
> > }
> >
> > -   if (buf)
> > -   kfree(buf);
> > +   kfree(buf);
> >  }
> >
> 
> This is performance critical, so I would like the check to remain. A comment
> may be added in this section.

The first thing kfree() does is check for the NULL pointer. And since kfree()
is used a lot, it's probably already in the cache.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] spinlock_t & rwlock_t break_lock member initialization (patch seeking comments included)

[Jesper Juhl]

I'm often building the tree with gcc -W to look for potential trouble 
spots, and of course I see a lot of warning messages. I'm well aware that 
most of these don't indicate actual problems and should just be ignored, 
but the less warnings there are the easier it is to zoom in on the ones 
that might actually matter, so I try to also locate those that can be 
silenced safely even when they don't indicate a real problem - just to cut 
down on the number of warnings I have to sift through.
One class of warnings that belong in the "not really a problem but I 
believe I can silence it without doing any harm" category are these : 

include/linux/wait.h:82: warning: missing initializer
include/linux/wait.h:82: warning: (near initialization for 
`(anonymous).break_lock')

include/asm/rwsem.h:88: warning: missing initializer
include/asm/rwsem.h:88: warning: (near initialization for 
`(anonymous).break_lock')

These stem from the fact that when you enable CONFIG_PREEMPT spinlock_t 
and rwlock_t each gain an extra member "break_lock", but the lock 
initialization code neglects to initialize this extra member in that case.

If you enable CONFIG_PREEMPT and build with gcc -W you'll see a *lot* of 
those, since spinlocks and rwlocks are used all over the place.

I've come up with a patch to that silence those warnings by making sure 
the "break_lock" member will be initialized when CONFIG_PREEMPT is 
enabled.

I would like to know if a patch like this is welcome or just considered 
clutter for no real gain. I would also like to know if I've overlooked 
some implications of doing this - it seems to me that this should be 
completely safe to do and without significant overhead, but I'm also well 
aware that my knowledge of this code is quite shallow, so I need comments 
(especially since lock performance is quite performance critical, so I 
don't want to screw up here).

Here's the patch I came up with - comments are very welcome.


(no Signed-off-by since this is not intended to be merged just yet)

--- linux-2.6.11-mm4-orig/include/asm-i386/spinlock.h   2005-03-02 
08:37:50.0 +0100
+++ linux-2.6.11-mm4/include/asm-i386/spinlock.h2005-03-20 
22:40:46.0 +0100
@@ -32,7 +32,13 @@
 #define SPINLOCK_MAGIC_INIT/* */
 #endif
 
-#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 SPINLOCK_MAGIC_INIT }
+#ifdef CONFIG_PREEMPT
+#define SPINLOCK_BREAK_INIT, 0
+#else
+#define SPINLOCK_BREAK_INIT/* */
+#endif
+
+#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 SPINLOCK_MAGIC_INIT 
SPINLOCK_BREAK_INIT }
 
 #define spin_lock_init(x)  do { *(x) = SPIN_LOCK_UNLOCKED; } while(0)
 
@@ -182,7 +188,13 @@
 #define RWLOCK_MAGIC_INIT  /* */
 #endif
 
-#define RW_LOCK_UNLOCKED (rwlock_t) { RW_LOCK_BIAS RWLOCK_MAGIC_INIT }
+#ifdef CONFIG_PREEMPT
+#define RWLOCK_BREAK_INIT  , 0
+#else
+#define RWLOCK_BREAK_INIT  /* */
+#endif
+
+#define RW_LOCK_UNLOCKED (rwlock_t) { RW_LOCK_BIAS RWLOCK_MAGIC_INIT 
RWLOCK_BREAK_INIT }
 
 #define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
 

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

[PATCH 2.6.11.2][SECURITY] printk with anti-cluttering-feature

[Bodo Eggert]

Security fix against a log spamming DoS in tuner.c, compile-tested

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

--- linux-2.6.11/drivers/media/video/tuner.c2005-03-20 20:54:54.0 
+0100
+++ hotfix/drivers/media/video/tuner.c  2005-03-20 21:10:33.0 +0100
@@ -1048,8 +1048,9 @@ static void set_tv_freq(struct i2c_clien
   right now we don't have that in the config
   struct and this way is still better than no
   check at all */
-   printk("tuner: TV freq (%d.%02d) out of range (%d-%d)\n",
-  freq/16,freq%16*100/16,tv_range[0],tv_range[1]);
+   if(printk_ratelimit())
+   printk("tuner: TV freq (%d.%02d) out of range 
(%d-%d)\n",
+  freq/16,freq%16*100/16,tv_range[0],tv_range[1]);
return;
}
t->tv_freq(c,freq);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.11.2][2/2] printk with anti-cluttering-feature

[Bodo Eggert]

Update some functions to use printk_nospam

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

diff -purNXdontdiff linux-2.6.11/drivers/block/scsi_ioctl.c 
linux-2.6.11.new/drivers/block/scsi_ioctl.c
--- linux-2.6.11/drivers/block/scsi_ioctl.c 2005-03-03 15:41:28.0 
+0100
+++ linux-2.6.11.new/drivers/block/scsi_ioctl.c 2005-03-20 14:56:55.0 
+0100
@@ -547,7 +547,7 @@ int scsi_cmd_ioctl(struct file *file, st
 * old junk scsi send command ioctl
 */
case SCSI_IOCTL_SEND_COMMAND:
-   printk(KERN_WARNING "program %s is using a deprecated 
SCSI ioctl, please convert it to SG_IO\n", current->comm);
+   printk_nospam(2296159591, KERN_WARNING "program %s is 
using a deprecated SCSI ioctl, please convert it to SG_IO\n", current->comm);
err = -EINVAL;
if (!arg)
break;
diff -purNXdontdiff linux-2.6.11/drivers/input/keyboard/atkbd.c 
linux-2.6.11.new/drivers/input/keyboard/atkbd.c
--- linux-2.6.11/drivers/input/keyboard/atkbd.c 2005-03-03 15:41:33.0 
+0100
+++ linux-2.6.11.new/drivers/input/keyboard/atkbd.c 2005-03-20 
14:56:55.0 +0100
@@ -320,7 +320,7 @@ static irqreturn_t atkbd_interrupt(struc
atkbd_report_key(>dev, regs, KEY_HANJA, 3);
goto out;
case ATKBD_RET_ERR:
-   printk(KERN_DEBUG "atkbd.c: Keyboard on %s reports too 
many keys pressed.\n", serio->phys);
+   printk_nospam(2260620158, KERN_DEBUG "atkbd.c: Keyboard 
on %s reports too many keys pressed.\n", serio->phys);
goto out;
}
 
diff -purNXdontdiff linux-2.6.11/drivers/media/video/tuner.c 
linux-2.6.11.new/drivers/media/video/tuner.c
--- linux-2.6.11/drivers/media/video/tuner.c2005-03-20 20:54:54.0 
+0100
+++ linux-2.6.11.new/drivers/media/video/tuner.c2005-03-20 
14:56:55.0 +0100
@@ -1048,7 +1048,7 @@ static void set_tv_freq(struct i2c_clien
   right now we don't have that in the config
   struct and this way is still better than no
   check at all */
-   printk("tuner: TV freq (%d.%02d) out of range (%d-%d)\n",
+   printk_nospam(1801459135, "tuner: TV freq (%d.%02d) out of 
range (%d-%d)\n",
   freq/16,freq%16*100/16,tv_range[0],tv_range[1]);
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Real-Time Preemption and RCU

[hui]

On Sun, Mar 20, 2005 at 05:57:23PM +0100, Manfred Spraul wrote:
> That was just one random example.
> Another one would be :
> 
> drivers/chat/tty_io.c, __do_SAK() contains
>read_lock(_lock);
>task_lock(p);
> 
> kernel/sys.c, sys_setrlimit contains
>task_lock(current->group_leader);
>read_lock(_lock);
> 
> task_lock is a shorthand for spin_lock(>alloc_lock). If read_lock is 
> a normal spinlock, then this is an A/B B/A deadlock.

That code was already dubious in the first place just because it
contained that circularity. If you had a rwlock that block on an
upper read count maximum a deadlock situation would trigger anyways,
say, upon a flood of threads trying to do that sequence of aquires.

I'd probably experiment with using the {spin,read,write}-trylock
logic and release the all locks contains in a sequence like that
on the failure to aquire any of the locks in the chain as an
initial fix. A longer term fix might be to break things up a bit
so that whatever ordering being done would have that circularity.

BTW, the runtime lock cricularity detector was designed to trigger
on that situtation anyways.

That's my thoughts on the matter.

bill

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

[PATCH 2.6.11.2][1/2] printk with anti-cluttering-feature

[Bodo Eggert]

Introduce printk_nospam, which will prevent duplicate and excessive 
printing.

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

diff -purNXdontdiff linux-2.6.11/include/linux/kernel.h 
linux-2.6.11.new/include/linux/kernel.h
--- linux-2.6.11/include/linux/kernel.h 2005-03-03 15:42:13.0 +0100
+++ linux-2.6.11.new/include/linux/kernel.h 2005-03-20 21:15:23.0 
+0100
@@ -104,6 +104,12 @@ extern int session_of_pgrp(int pgrp);
 asmlinkage int vprintk(const char *fmt, va_list args);
 asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
+asmlinkage int printk_nospam(unsigned int magic, const char * fmt, ...)
+   __attribute__ ((format (printf, 2, 3)));
+/* Don't print the previously printed message had the same magic or the rate
+   limit would be exceeded.
+   Hint: Use a unique random value for the magic, e.g. the first value from
+   cksum on the file you're editing */
 
 unsigned long int_sqrt(unsigned long);
 
diff -purNXdontdiff linux-2.6.11/kernel/printk.c 
linux-2.6.11.new/kernel/printk.c
--- linux-2.6.11/kernel/printk.c2005-03-18 21:54:35.0 +0100
+++ linux-2.6.11.new/kernel/printk.c2005-03-20 21:15:14.0 +0100
@@ -115,6 +115,8 @@ static int preferred_console = -1;
 /* Flag: console code may call schedule() */
 static int console_may_schedule;
 
+static int antispam_magic;
+
 /*
  * Setup a list of consoles. Called from init/main.c
  */
@@ -517,6 +519,26 @@ asmlinkage int printk(const char *fmt, .
va_list args;
int r;
 
+   antispam_magic = 0;
+
+   va_start(args, fmt);
+   r = vprintk(fmt, args);
+   va_end(args);
+
+   return r;
+}
+
+asmlinkage int printk_nospam(unsigned int magic, const char *fmt, ...)
+{
+   va_list args;
+   int r;
+   
+   if (magic == antispam_magic)
+   return 0;
+   if (!printk_ratelimit())
+   return 0;
+   antispam_magic = magic;
+
va_start(args, fmt);
r = vprintk(fmt, args);
va_end(args);
@@ -591,6 +613,7 @@ out:
return printed_len;
 }
 EXPORT_SYMBOL(printk);
+EXPORT_SYMBOL(printk_nospam);
 EXPORT_SYMBOL(vprintk);
 
 /**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.11.2][0/2] printk with anti-cluttering-feature

[Bodo Eggert]

These patches address the issue of dmesg being slowly spammed with 
repeated warnings.

Some parts of the kernel want to notify the user about deprecated or 
invalid calls or parameters. These messages will slowly fill dmesg and 
hinder you from seing the boot messages.

Examples are:
atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
 (I'm using a keyboard switch and a IBM PS/2 keyboard)

program smartd is using a deprecated SCSI ioctl, please convert it to SG_IO
 (I'll use the latest version as soon as I need to)

tuner: TV freq (0.00) out of range (44-958)
 (I'll update zapping later)

This is prevented by introducing printk_nospam(), which takes an
additional magic value to identify the last one who printk-ed something.
If the current magic matches the one of the last successfull caller,
nothing will be printed. The normal printk will reset the magic to 0,
which ensures that if a messages indicating a current problem won't be
hidden just because it occured before.

Additionally, all these messages will be rate-limited, since they are
usurally triggered by userspace and thereby a way to DoS the machine.
Without the rate-limit, the user could repeatedly call two functions that
cause a printk in order to spam the log.

(The rate limit alone is not sufficient to prevent repeated warnings, 
since they would be allowed by the burst limit or by being slow.)

This patch uses an uint, which can be read and written atomically by most
architectures. On architectures not supporting atomic reads to ints, the
message may be dropped or printed twice. I think it's OK, since dropping
for being racy is unlikely (especially compared to hitting the rate
limit), and a double line won't hurt.



The first patch will introduce the printk_nospam function.
The second patch will update the three printks causing my examples.

Since the TV freq message can be triggered by UID != 0, I'll send a hotfix
patch for the 2.6.11.x line, too. This patch is only compile-tested.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PKT_SCHED]: Extended Matches API

[Thomas Graf]

* Geert Uytterhoeven <[EMAIL PROTECTED]> 2005-03-20 21:58
> On Tue, 15 Feb 2005, Linux Kernel Mailing List wrote:
> > ChangeSet 1.1982.66.2, 2005/02/15 12:13:15-08:00, [EMAIL PROTECTED]
> > 
> > [PKT_SCHED]: Extended Matches API
> 
> 
> > --- a/net/sched/Kconfig 2005-03-06 18:14:44 -08:00
> > +++ b/net/sched/Kconfig 2005-03-06 18:14:44 -08:00
> 
> > +config NET_EMATCH_STACK
> > +   int "Stack size"
> > +   depends on NET_EMATCH
> > +   default "32"
> > +   ---help---
> > + Size of the local stack variable used while evaluating the tree of
> > + ematches. Limits the depth of the tree, i.e. the number of
> > + encapsulated precedences. Every level requires 4 bytes of addtional
> ^
>   additional
> > + stack space.
> > +
> 
> Gr{oetje,eeting}s,

Fixed it in the ematch tree submit it in the next patchset. Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PKT_SCHED]: Extended Matches API

[Geert Uytterhoeven]

On Tue, 15 Feb 2005, Linux Kernel Mailing List wrote:
> ChangeSet 1.1982.66.2, 2005/02/15 12:13:15-08:00, [EMAIL PROTECTED]
> 
>   [PKT_SCHED]: Extended Matches API


> --- a/net/sched/Kconfig   2005-03-06 18:14:44 -08:00
> +++ b/net/sched/Kconfig   2005-03-06 18:14:44 -08:00

> +config NET_EMATCH_STACK
> + int "Stack size"
> + depends on NET_EMATCH
> + default "32"
> + ---help---
> +   Size of the local stack variable used while evaluating the tree of
> +   ematches. Limits the depth of the tree, i.e. the number of
> +   encapsulated precedences. Every level requires 4 bytes of addtional
^
additional
> +   stack space.
> +

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

alsa es1371's joystick functionality broken in 2.6.11-mm4

[Patrick McFarland]

It seems that the es1371 driver (which provides its own joystick port driver) 
is broken in at least 2.6.11-mm4. I don't know when it broke, but it used to 
work around in the 2.6.8/9 days (I haven't used the joystick in awhile). The 
hardware and joystick still both work (tested in Windows).

Where do I go from here?

-- 
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989


pgpfolDb0rtz0.pgp
Description: PGP signature

Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Antonino A. Daplas]

On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> Checking a pointer for NULL before calling kfree() on it is redundant,
> kfree() deals with NULL pointers just fine.
> This patch removes such checks from files in drivers/video/
>
> Since this is a fairly trivial change (and the same change made
> everywhere) I've just made a single patch for all the files and CC all
> authors/maintainers of those files I could find for comments. If spliting
> this into one patch pr file is prefered, then I can easily do that as
> well.
>

[snip]

> --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 2005-03-16
> 15:45:26.0 +0100 +++
> linux-2.6.11-mm4/drivers/video/console/bitblit.c  2005-03-19
> 22:27:39.0 +0100 @@ -199,8 +199,7 @@ static void bit_putcs(struct
> vc_data *vc
>   count -= cnt;
>   }
>
> - if (buf)
> - kfree(buf);
> + kfree(buf);
>  }
>

This is performance critical, so I would like the check to remain. A comment
may be added in this section.

>  static void bit_clear_margins(struct vc_data *vc, struct fb_info *info,
> @@ -273,8 +272,7 @@ static void bit_cursor(struct vc_data *v
>   dst = kmalloc(w * vc->vc_font.height, GFP_ATOMIC);
>   if (!dst)
>   return;
> - if (ops->cursor_data)
> - kfree(ops->cursor_data);
> + kfree(ops->cursor_data);
>   ops->cursor_data = dst;
>   update_attr(dst, src, attribute, vc);
>   src = dst;
> @@ -321,8 +319,7 @@ static void bit_cursor(struct vc_data *v
>   if (!mask)
>   return;
>
> - if (ops->cursor_state.mask)
> - kfree(ops->cursor_state.mask);
> + kfree(ops->cursor_state.mask);
>   ops->cursor_state.mask = mask;

Although these are also performance critical, I will agree that the checks
can go.  Very rarely will ops->cursor_state.mask and ops->cursor_data be
NULL.

As for the rest, they are acceptable, as long as the maintainers agree.

Tony


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

Re: [-mm patch] kill include/video/edid.h

[Antonino A. Daplas]

On Monday 21 March 2005 03:29, Adrian Bunk wrote:
> This patch removes some completely unused code.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
>  arch/i386/boot/compressed/misc.c |1 -
>  arch/i386/kernel/setup.c |4 
>  arch/x86_64/kernel/setup.c   |3 ---
>  drivers/video/fbmon.c|1 -
>  drivers/video/vesafb.c   |3 ---
>  include/asm-i386/setup.h |1 -
>  include/asm-x86_64/bootsetup.h   |1 -
>  include/video/edid.h |   27 ---
>  8 files changed, 41 deletions(-)
>
> --- linux-2.6.11-mm4-full/arch/i386/kernel/setup.c.old2005-03-20
> 20:06:06.0 +0100 +++
> linux-2.6.11-mm4-full/arch/i386/kernel/setup.c2005-03-20
> 20:06:45.0 +0100 @@ -43,8 +43,6 @@
>  #include 
>  #include 
>
> -#include 
> -
>  #include 
>  #include 
>  #include 
> @@ -118,7 +116,6 @@
>   unsigned short length;
>   unsigned char table[0];
>  };
> -struct edid_info edid_info;
>  struct ist_info ist_info;
>  struct e820map e820;
>
> @@ -1468,7 +1465,6 @@
>   ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
>   drive_info = DRIVE_INFO;
>   screen_info = SCREEN_INFO;
> - edid_info = EDID_INFO;
>   apm_info.bios = APM_BIOS_INFO;
>   ist_info = IST_INFO;
>   saved_videomode = VIDEO_MODE;
> --- linux-2.6.11-mm4-full/arch/x86_64/kernel/setup.c.old  2005-03-20
> 20:04:42.0 +0100 +++
> linux-2.6.11-mm4-full/arch/x86_64/kernel/setup.c  2005-03-20
> 20:07:11.0 +0100 @@ -48,7 +48,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -100,7 +99,6 @@
>   unsigned char table[0];
>  };
>
> -struct edid_info edid_info;
>  struct e820map e820;
>
>  extern int root_mountflags;
> @@ -523,7 +521,6 @@
>   ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
>   drive_info = DRIVE_INFO;
>   screen_info = SCREEN_INFO;
> - edid_info = EDID_INFO;
>   saved_video_mode = SAVED_VIDEO_MODE;
>   bootloader_type = LOADER_TYPE;
>
> --- linux-2.6.11-mm4-full/drivers/video/fbmon.c.old   2005-03-20
> 20:03:56.0 +0100 +++
> linux-2.6.11-mm4-full/drivers/video/fbmon.c   2005-03-20 20:04:27.0
> +0100 @@ -34,7 +34,6 @@
>  #include 
>  #include 
>  #endif
> -#include 
>  #include "edid.h"
>
>  /*
> --- linux-2.6.11-mm4-full/drivers/video/vesafb.c.old  2005-03-20
> 20:04:12.0 +0100 +++
> linux-2.6.11-mm4-full/drivers/video/vesafb.c  2005-03-20 20:04:18.0
> +0100 @@ -19,9 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#ifdef __i386__
> -#include 
> -#endif
>  #include 
>  #include 
>
> --- linux-2.6.11-mm4-full/arch/i386/boot/compressed/misc.c.old
> 2005-03-20
> 20:05:55.0 +0100 +++
> linux-2.6.11-mm4-full/arch/i386/boot/compressed/misc.c2005-03-20
> 20:05:58.0 +0100 @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>
> --- linux-2.6.11-mm4-full/include/asm-x86_64/bootsetup.h.old  2005-03-20
> 20:07:33.0 +0100 +++
> linux-2.6.11-mm4-full/include/asm-x86_64/bootsetup.h  2005-03-20
> 20:07:44.0 +0100 @@ -25,7 +25,6 @@
>  #define KERNEL_START (*(unsigned int *) (PARAM+0x214))
>  #define INITRD_START (*(unsigned int *) (PARAM+0x218))
>  #define INITRD_SIZE (*(unsigned int *) (PARAM+0x21c))
> -#define EDID_INFO (*(struct edid_info *) (PARAM+0x140))
>  #define EDD_NR (*(unsigned char *) (PARAM+EDDNR))
>  #define EDD_MBR_SIG_NR (*(unsigned char *) (PARAM+EDD_MBR_SIG_NR_BUF))
>  #define EDD_MBR_SIGNATURE ((unsigned int *) (PARAM+EDD_MBR_SIG_BUF))
> --- linux-2.6.11-mm4-full/include/asm-i386/setup.h.old2005-03-20
> 20:07:52.0 +0100 +++
> linux-2.6.11-mm4-full/include/asm-i386/setup.h2005-03-20
> 20:07:55.0 +0100 @@ -55,7 +55,6 @@
>  #define KERNEL_START (*(unsigned long *) (PARAM+0x214))
>  #define INITRD_START (*(unsigned long *) (PARAM+0x218))
>  #define INITRD_SIZE (*(unsigned long *) (PARAM+0x21c))
> -#define EDID_INFO   (*(struct edid_info *) (PARAM+0x140))
>  #define EDD_NR (*(unsigned char *) (PARAM+EDDNR))
>  #define EDD_MBR_SIG_NR (*(unsigned char *) (PARAM+EDD_MBR_SIG_NR_BUF))
>  #define EDD_MBR_SIGNATURE ((unsigned int *) (PARAM+EDD_MBR_SIG_BUF))

Not this one.  Code that grabs the EDID block using the video BIOS is in 
video.S.
Currently, there's no driver that uses this but it's an acceptable backup for 
drivers
that want the EDID block but has no i2c, or i2c probing fails.

Tony


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

[no subject]

[buakaw]

the system become very laggy.
i use kernel 2.6.10/2.6.11.3 on p4 2.8, msi915p, 3 x 3com905 boomerang.
and the cpu usage normally be about 12% and after something happens it
boost to 100% and it is used mostly by ksoftirqd/0, and a little bit by 
migration/0 and event/0. and in syslog i found thies lines

Mar 20 22:21:09 buakaw kernel: printk: 5543 messages suppressed.
Mar 20 22:21:09 buakaw kernel: dst cache overflow

what can cause this?


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

Re: af_unix.c, KBUILD_MODNAME and unix

[Bodo Eggert]

Magnus Damm <[EMAIL PROTECTED]> wrote:

> Solution? #undef unix?

#define unix unix?

provided nobody uses unix numerically.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

swsusp 1/1: kill swsusp_restore

[Pavel Machek]

Hi!

This kills swsusp_resume; it should be arch-neutral but some i386 code
sneaked in. And arch-specific code is better done in assembly
anyway. Plus it fixes memory leaks in error paths.

Please apply,
Pavel

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

--- clean-mm/arch/i386/power/swsusp.S   2005-03-19 00:31:06.0 +0100
+++ linux-mm/arch/i386/power/swsusp.S   2005-03-20 20:32:04.0 +0100
@@ -51,6 +51,15 @@
.p2align 4,,7
 
 done:
+   /* Flush TLB, including "global" things (vmalloc) */
+   movlmmu_cr4_features, %eax
+   movl%eax, %edx
+   andl$~(1<<7), %edx;  # PGE
+   movl%edx, %cr4;  # turn off PGE
+   movl%cr3, %ecx;  # flush TLB
+   movl%ecx, %cr3
+   movl%eax, %cr4;  # turn PGE back on
+
movl saved_context_esp, %esp
movl saved_context_ebp, %ebp
movl saved_context_ebx, %ebx
@@ -58,5 +67,7 @@
movl saved_context_edi, %edi
 
pushl saved_context_eflags ; popfl
-   call swsusp_restore
+
+   xorl%eax, %eax
+
ret
--- clean-mm/arch/x86_64/kernel/suspend_asm.S   2005-03-19 00:31:17.0 
+0100
+++ linux-mm/arch/x86_64/kernel/suspend_asm.S   2005-03-20 20:32:04.0 
+0100
@@ -69,12 +69,21 @@
movqpbe_next(%rdx), %rdx
jmp loop
 done:
+   /* Flush TLB, including "global" things (vmalloc) */
+   movqmmu_cr4_features(%rip), %rax
+   movq%rax, %rdx
+   andq$~(1<<7), %rdx;  # PGE
+   movq%rdx, %cr4;  # turn off PGE
+   movq%cr3, %rcx;  # flush TLB
+   movq%rcx, %cr3
+   movq%rax, %cr4;  # turn PGE back on
+
movl$24, %eax
movl%eax, %ds
 
movq saved_context_esp(%rip), %rsp
movq saved_context_ebp(%rip), %rbp
-   movq saved_context_eax(%rip), %rax
+   /* Don't restore %rax, it must be 0 anyway */
movq saved_context_ebx(%rip), %rbx
movq saved_context_ecx(%rip), %rcx
movq saved_context_edx(%rip), %rdx
@@ -89,5 +98,7 @@
movq saved_context_r14(%rip), %r14
movq saved_context_r15(%rip), %r15
pushq saved_context_eflags(%rip) ; popfq
-   callswsusp_restore
+
+   xorq%rax, %rax
+
ret
--- clean-mm/kernel/power/swsusp.c  2005-03-20 20:35:16.0 +0100
+++ linux-mm/kernel/power/swsusp.c  2005-03-20 20:43:25.0 +0100
@@ -892,29 +892,23 @@
 * at resume time, and evil weirdness ensues.
 */
if ((error = device_power_down(PMSG_FREEZE))) {
+   printk(KERN_ERR "Some devices failed to power down, aborting 
suspend\n");
local_irq_enable();
+   swsusp_free();
return error;
}
save_processor_state();
-   error = swsusp_arch_suspend();
+   if ((error = swsusp_arch_suspend()))
+   swsusp_free();
/* Restore control flow magically appears here */
restore_processor_state();
+   BUG_ON (nr_copy_pages_check != nr_copy_pages);
restore_highmem();
device_power_up();
local_irq_enable();
return error;
 }
 
-
-asmlinkage int swsusp_restore(void)
-{
-   BUG_ON (nr_copy_pages_check != nr_copy_pages);
-   
-   /* Even mappings of "global" things (vmalloc) need to be fixed */
-   __flush_tlb_global();
-   return 0;
-}
-
 int swsusp_resume(void)
 {
int error;


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Error with Sil3112A SATA controller and Maxtor 300GB HDD

[Manuel Lauss]

Howdy,
Guido Villa wrote:
I happen to have a SiI 3112A controller and a Maxtor 6B300S0 attached to
it, formatted with ext2. Never had any problems. I just copied
200GB of data to it, worked flawlessly. (Vanilla 2.6.11)
Maybe its the Motherboard?

I was checking my kernel configuration, and some doubts arised in my mind. 
Would you please check if my parameters are the same as yours? 

set:
CONFIG_IDE_GENERIC
CONFIG_BLK_DEV_IDEPCI
CONFIG_SCSI
CONFIG_BLK_DEV_SD
CONFIG_SCSI_SATA
CONFIG_SCSI_SATA_SIL 

unset:
CONFIG_BLK_DEV_GENERIC
CONFIG_BLK_DEV_SIIMAGE (I'm unsure on this) 
Heres a snippet from the box's .config:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDE_TASK_IOCTL=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_SIL=y
This is for Piix4 + promise20268 IDE
and the Sil sata ctrl, only harddisks.
--
 Manuel Lauss
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PCI: remove pci_find_device usage from pci sysfs code.

[Rolf Eike Beer]

Greg KH wrote:
> ChangeSet 1.1998.11.23, 2005/02/25 08:26:11-08:00, [EMAIL PROTECTED]
>
> PCI: remove pci_find_device usage from pci sysfs code.

> diff -Nru a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> --- a/drivers/pci/pci-sysfs.c 2005-03-04 12:41:33 -08:00
> +++ b/drivers/pci/pci-sysfs.c 2005-03-04 12:41:33 -08:00
> @@ -481,7 +481,7 @@
>   struct pci_dev *pdev = NULL;
>
>   sysfs_initialized = 1;
> - while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL)
> + while ((pdev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL)
>   pci_create_sysfs_dev_files(pdev);
>
>   return 0;

Any reasons why you are not using "for_each_pci_dev(pdev)" here?

Eike


pgpshfz4lTB8Z.pgp
Description: PGP signature

[2.6 patch] drivers/video/intelfb/intelfbdrv.h

[Adrian Bunk]

Ingo Oeser noticed that all that intelfbdrv.h contains are prototypes 
for static functions - and such prototypes don't belong into header 
files.

This patch therefore removes drivers/video/intelfb/intelfbdrv.h and 
moves the prototypes to intelfbdrv.c .

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/video/intelfb/intelfbdrv.c |   40 -
 drivers/video/intelfb/intelfbdrv.h |   68 -
 2 files changed, 39 insertions(+), 69 deletions(-)

--- linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.c.old
2005-03-20 03:39:30.0 +0100
+++ linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.c2005-03-20 
03:44:03.0 +0100
@@ -135,9 +135,47 @@
 #endif
 
 #include "intelfb.h"
-#include "intelfbdrv.h"
 #include "intelfbhw.h"
 
+
+static void __devinit get_initial_mode(struct intelfb_info *dinfo);
+static void update_dinfo(struct intelfb_info *dinfo,
+struct fb_var_screeninfo *var);
+static int intelfb_get_fix(struct fb_fix_screeninfo *fix,
+  struct fb_info *info);
+
+static int intelfb_check_var(struct fb_var_screeninfo *var,
+struct fb_info *info);
+static int intelfb_set_par(struct fb_info *info);
+static int intelfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+unsigned blue, unsigned transp,
+struct fb_info *info);
+
+static int intelfb_blank(int blank, struct fb_info *info);
+static int intelfb_pan_display(struct fb_var_screeninfo *var,
+  struct fb_info *info);
+
+static void intelfb_fillrect(struct fb_info *info,
+const struct fb_fillrect *rect);
+static void intelfb_copyarea(struct fb_info *info,
+const struct fb_copyarea *region);
+static void intelfb_imageblit(struct fb_info *info,
+ const struct fb_image *image);
+static int intelfb_cursor(struct fb_info *info,
+  struct fb_cursor *cursor);
+
+static int intelfb_sync(struct fb_info *info);
+
+static int intelfb_ioctl(struct inode *inode, struct file *file,
+unsigned int cmd, unsigned long arg,
+struct fb_info *info);
+
+static int __devinit intelfb_pci_register(struct pci_dev *pdev,
+ const struct pci_device_id *ent);
+static void __devexit intelfb_pci_unregister(struct pci_dev *pdev);
+static int __devinit intelfb_set_fbinfo(struct intelfb_info *dinfo);
+
+
 /*
  * Limiting the class to PCI_CLASS_DISPLAY_VGA prevents function 1 of the
  * mobile chipsets from being registered.
--- linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.h2005-03-16 
18:55:25.0 +0100
+++ /dev/null   2005-03-19 22:42:59.0 +0100
@@ -1,68 +0,0 @@
-#ifndef _INTELFBDRV_H
-#define _INTELFBDRV_H
-
-/*
- **
- * intelfb
- *
- * Linux framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G
- * integrated graphics chips.
- *
- * Copyright © 2004 Sylvain Meyer
- *
- * Author: Sylvain Meyer
- *
- **
- *This program is free software; you can redistribute it and/or modify
- *it under the terms of the GNU General Public License as published by
- *the Free Software Foundation; either version 2 of the License, or
- *(at your option) any later version.
- *
- *This program is distributed in the hope that it will be useful,
- *but WITHOUT ANY WARRANTY; without even the implied warranty of
- *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *GNU General Public License for more details.
- *
- *You should have received a copy of the GNU General Public License
- *along with this program; if not, write to the Free Software
- *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-static void __devinit get_initial_mode(struct intelfb_info *dinfo);
-static void update_dinfo(struct intelfb_info *dinfo,
-struct fb_var_screeninfo *var);
-static int intelfb_get_fix(struct fb_fix_screeninfo *fix,
-  struct fb_info *info);
-
-static int intelfb_check_var(struct fb_var_screeninfo *var,
-struct fb_info *info);
-static int intelfb_set_par(struct fb_info *info);
-static int intelfb_setcolreg(unsigned regno, unsigned red, unsigned green,
-unsigned blue, unsigned transp,
-struct fb_info *info);
-
-static int intelfb_blank(int blank, struct fb_info *info);
-static int intelfb_pan_display(struct fb_var_screeninfo *var,
-  struct fb_info *info);
-
-static void intelfb_fillrect(struct fb_info *info,
-const struct fb_fillrect *rect);
-static 

Re: swsusp: Remove arch-specific references from generic code

[Pavel Machek]

Hi!

> > Do you think you could just send me diff between 2.6.12-rc1 and your
> > tree? I'll merge it here.
> 
> Sure, no problem, the diff follows. :-)  It contains the following changes:
> 
> - remove swsusp_restore() (with the fix to return 0 from swsusp_arch_resume() 
> on x86*)
> - drop SUSPEND_PD_PAGES and pagedir_order
> - fix possible memory leaks in swsusp_suspend()
> 
> The original patches are also attached in case you need them (they all apply 
> to
> 2.6.12-rc1).
> 
> Please let me know if that's ok.

Thanks, applied to my tree. (Actually I applied 3 attachments, but
that should be okay).
Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][trivial] matroxfb_maven remove pointless semicolons after label

[Jesper Juhl]

On Sun, 20 Mar 2005, Petr Vandrovec wrote:

> On Sun, Mar 20, 2005 at 05:41:01PM +0100, Jesper Juhl wrote:
> > 
> > Having a semicolon at the end as in  labelname:;  is pointless, remove.
> 
> As long as I'm maintainer of this code, I prefer to leave them here.
>   Petr Vandrovec
> 
No problem. As you say, you're the maintainer. I just spotted them and 
made the patch, it's ofcourse entirely up to you if you want to apply it 
or not :-)

-- 
Jesper Juhl


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

[-mm patch] kill include/video/edid.h

[Adrian Bunk]

This patch removes some completely unused code.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/i386/boot/compressed/misc.c |1 -
 arch/i386/kernel/setup.c |4 
 arch/x86_64/kernel/setup.c   |3 ---
 drivers/video/fbmon.c|1 -
 drivers/video/vesafb.c   |3 ---
 include/asm-i386/setup.h |1 -
 include/asm-x86_64/bootsetup.h   |1 -
 include/video/edid.h |   27 ---
 8 files changed, 41 deletions(-)

--- linux-2.6.11-mm4-full/arch/i386/kernel/setup.c.old  2005-03-20 
20:06:06.0 +0100
+++ linux-2.6.11-mm4-full/arch/i386/kernel/setup.c  2005-03-20 
20:06:45.0 +0100
@@ -43,8 +43,6 @@
 #include 
 #include 
 
-#include 
-
 #include 
 #include 
 #include 
@@ -118,7 +116,6 @@
unsigned short length;
unsigned char table[0];
 };
-struct edid_info edid_info;
 struct ist_info ist_info;
 struct e820map e820;
 
@@ -1468,7 +1465,6 @@
ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
drive_info = DRIVE_INFO;
screen_info = SCREEN_INFO;
-   edid_info = EDID_INFO;
apm_info.bios = APM_BIOS_INFO;
ist_info = IST_INFO;
saved_videomode = VIDEO_MODE;
--- linux-2.6.11-mm4-full/arch/x86_64/kernel/setup.c.old2005-03-20 
20:04:42.0 +0100
+++ linux-2.6.11-mm4-full/arch/x86_64/kernel/setup.c2005-03-20 
20:07:11.0 +0100
@@ -48,7 +48,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -100,7 +99,6 @@
unsigned char table[0];
 };
 
-struct edid_info edid_info;
 struct e820map e820;
 
 extern int root_mountflags;
@@ -523,7 +521,6 @@
ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
drive_info = DRIVE_INFO;
screen_info = SCREEN_INFO;
-   edid_info = EDID_INFO;
saved_video_mode = SAVED_VIDEO_MODE;
bootloader_type = LOADER_TYPE;
 
--- linux-2.6.11-mm4-full/drivers/video/fbmon.c.old 2005-03-20 
20:03:56.0 +0100
+++ linux-2.6.11-mm4-full/drivers/video/fbmon.c 2005-03-20 20:04:27.0 
+0100
@@ -34,7 +34,6 @@
 #include 
 #include 
 #endif
-#include 
 #include "edid.h"
 
 /* 
--- linux-2.6.11-mm4-full/drivers/video/vesafb.c.old2005-03-20 
20:04:12.0 +0100
+++ linux-2.6.11-mm4-full/drivers/video/vesafb.c2005-03-20 
20:04:18.0 +0100
@@ -19,9 +19,6 @@
 #include 
 #include 
 #include 
-#ifdef __i386__
-#include 
-#endif
 #include 
 #include 
 
--- linux-2.6.11-mm4-full/arch/i386/boot/compressed/misc.c.old  2005-03-20 
20:05:55.0 +0100
+++ linux-2.6.11-mm4-full/arch/i386/boot/compressed/misc.c  2005-03-20 
20:05:58.0 +0100
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
--- linux-2.6.11-mm4-full/include/asm-x86_64/bootsetup.h.old2005-03-20 
20:07:33.0 +0100
+++ linux-2.6.11-mm4-full/include/asm-x86_64/bootsetup.h2005-03-20 
20:07:44.0 +0100
@@ -25,7 +25,6 @@
 #define KERNEL_START (*(unsigned int *) (PARAM+0x214))
 #define INITRD_START (*(unsigned int *) (PARAM+0x218))
 #define INITRD_SIZE (*(unsigned int *) (PARAM+0x21c))
-#define EDID_INFO (*(struct edid_info *) (PARAM+0x140))
 #define EDD_NR (*(unsigned char *) (PARAM+EDDNR))
 #define EDD_MBR_SIG_NR (*(unsigned char *) (PARAM+EDD_MBR_SIG_NR_BUF))
 #define EDD_MBR_SIGNATURE ((unsigned int *) (PARAM+EDD_MBR_SIG_BUF))
--- linux-2.6.11-mm4-full/include/asm-i386/setup.h.old  2005-03-20 
20:07:52.0 +0100
+++ linux-2.6.11-mm4-full/include/asm-i386/setup.h  2005-03-20 
20:07:55.0 +0100
@@ -55,7 +55,6 @@
 #define KERNEL_START (*(unsigned long *) (PARAM+0x214))
 #define INITRD_START (*(unsigned long *) (PARAM+0x218))
 #define INITRD_SIZE (*(unsigned long *) (PARAM+0x21c))
-#define EDID_INFO   (*(struct edid_info *) (PARAM+0x140))
 #define EDD_NR (*(unsigned char *) (PARAM+EDDNR))
 #define EDD_MBR_SIG_NR (*(unsigned char *) (PARAM+EDD_MBR_SIG_NR_BUF))
 #define EDD_MBR_SIGNATURE ((unsigned int *) (PARAM+EDD_MBR_SIG_BUF))
--- linux-2.6.11-mm4-full/include/video/edid.h  2005-03-02 08:37:50.0 
+0100
+++ /dev/null   2005-03-19 22:42:59.0 +0100
@@ -1,27 +0,0 @@
-#ifndef __linux_video_edid_h__
-#define __linux_video_edid_h__
-
-#ifdef __KERNEL__
-
-#include 
-#ifdef CONFIG_PPC_OF
-#include 
-#endif
-
-#ifdef CONFIG_X86
-struct edid_info {
-   unsigned char dummy[128];
-};
-
-extern struct edid_info edid_info;
-extern char *get_EDID_from_BIOS(void *);
-
-#endif /* CONFIG_X86 */
-
-#ifdef CONFIG_PPC_OF
-extern char *get_EDID_from_OF(struct pci_dev *pdev);
-#endif
-
-#endif /* __KERNEL__ */
-
-#endif /* __linux_video_edid_h__ */

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