Re: 2.6.11-rc3-mm2

[Ingo Molnar]

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> Eh? Chris Wright's original rlimits patch was very straightforward
> [...]

the problem is that it didnt solve the problem (unprivileged user can
lock up the system) in any way. So after it became visible that all the
existing 'dont allow users to lock up' solutions are too invasive, we
went to recommend the solution that introduces the least architectural
problems: RT-LSM.

Ingo
-
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: [RFC PATCH] add wait_event_*_lock() functions

[Al Borchers]

On Thursday 10 February 2005 9:39 am, Nishanth Aravamudan wrote:
>> It came up on IRC that the wait_cond*() functions from
>> usb/serial/gadget.c could be useful in other parts of the kernel. Does
>> the following patch make sense towards this?

Sure, if people want to use these.

I did not push them because they seemed a bit "heavy weight",
but the construct is useful and general.

The docs should explain that the purpose is to wait atomically on
a complex condition, and that the usage pattern is to hold the
lock when using the wait_event_* functions or when changing any
variable that might affect the condition and waking up the waiting
processes.

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

[UTILITY] lksp - Help sending patches to lkml from quilt repository

[Tejun Heo]

 Hello,

 As I've been making quite a few mistakes posting patches to lkml.  I
wrote a perl script which automates sending multiple patches to lkml
from a quilt repository.

 lksp can...

 1. generate template index message.
 2. use only specified range of patches from the quilt repository.
 3. use the edited index message to generate individual patch mail
messages combined with patches acquired from quilt.
 4. keep all patch descriptions you wrote and reuse them.
 5. let you blame the script if something goes wrong and you end up
polluting other people's inbox.

 More information on lksp can be found at
 http://home-tj.org/lksp

 And the script can be downloaded from
 http://home-tj.org/lksp/files/lksp-0.1

 If you've found bugs or have any ideas, please let me know.

 Hope it helps. :-)

-- 
tejun

-
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: [RFC] Changing COW detection to be memory hotplug friendly

[Hugh Dickins]

On Thu, 10 Feb 2005, Andrea Arcangeli wrote:
> On Thu, Feb 10, 2005 at 08:19:47PM +, Hugh Dickins wrote:
> > 
> > get_user_pages broke COW in advance of the I/O.  The reason for
> > subsequent COW if the page gets unmapped is precisely because
> > can_share_swap_page used page_count to judge exclusivity, and
> > get_user_pages has bumped that up, so the page appears (in danger
> > of being) non-exclusive when actually it is exclusive.  By changing
> > can_share_swap_page to use page_mapcount, that frustration vanishes.
> 
> What if a second thread does a fork() while the rawio is in progress?
> The page will be again no shareable, and if you unmap it the rawio will
> be currupt if the thread that executed the fork while the I/O is in
> progress writes to a part of the page again after it has been unmapped
> (obviously the part of the page that isn't under read-rawio, rawio works
> with the hardblocksize, not on the whole page). 

I think there's no difference here between the two techniques.

With the new can_share_swap_page, yes, "page_swapcount" goes up with
the fork, the page will be judged non-exclusive, a user write to
another part of the page will replace it by a copy page, and it's
undefined how much of the I/O will be captured in the copy.

But even with the old can_share_swap_page, and try_to_unmap_one
refusing to unmap the page, copy_page_range's COW checking would
still remove write permission from the pte of an anonymous
page, so a user write to another part of the page would find
raised page_count and replace it by a copy page: same behaviour.

And it's fine for the behaviour to be somewhat undefined in this
peculiar case: the important thing is just that the page must not
be freed and reused while I/O occurs, hence get_user_page raising
the page_count - which I'm _not_ proposing to change!

Hugh
-
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: Logitech MX1000 Horizontal Scrolling

[Jeremy Nickurak]

On ven, 2005-02-04 at 20:54 +0100, Vojtech Pavlik wrote:
> On Thu, Feb 03, 2005 at 03:42:16PM +0100, Esben Stien wrote:
> > Esben Stien <[EMAIL PROTECTED]> writes:
> > 
> > > I got a 12 button logitech MX1000 mouse. 
> > 
> > I have still not resolved this issue. Anyone who can point me in any
> > direction?
>  
> Please try if 2.6.11-rc3 is any better.

Oddly, my horizontal scroll worked fine as extra buttons under 2.6.10.
2.6.11-rc3 causes the scroll wheel to appear under X.org 6.8.1 with the
evdev driver as two seperate mouse buttons being pressed simultaneously.

(Please CC me in replies).



signature.asc
Description: This is a digitally signed message part

[PATCH 10/10] Gameport: replace ->private with gameport_get/set_drvdata

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:23:40-05:00, [EMAIL PROTECTED]
  Input: remove gameport->private in favor of using driver-specific data
 in device structure, add gameport_get/set_drvdata to access it.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 drivers/input/joystick/a3d.c|   10 ++
 drivers/input/joystick/adi.c|7 ---
 drivers/input/joystick/analog.c |7 +--
 drivers/input/joystick/cobra.c  |   10 ++
 drivers/input/joystick/gf2k.c   |   10 ++
 drivers/input/joystick/grip.c   |   10 ++
 drivers/input/joystick/grip_mp.c|9 ++---
 drivers/input/joystick/guillemot.c  |9 +
 drivers/input/joystick/interact.c   |   10 ++
 drivers/input/joystick/sidewinder.c |   10 ++
 drivers/input/joystick/tmdc.c   |   10 ++
 include/linux/gameport.h|   15 ++-
 12 files changed, 76 insertions(+), 41 deletions(-)


===



diff -Nru a/drivers/input/joystick/a3d.c b/drivers/input/joystick/a3d.c
--- a/drivers/input/joystick/a3d.c  2005-02-11 01:41:08 -05:00
+++ b/drivers/input/joystick/a3d.c  2005-02-11 01:41:08 -05:00
@@ -277,13 +277,13 @@
if (!(a3d = kcalloc(1, sizeof(struct a3d), GFP_KERNEL)))
return -ENOMEM;
 
-   gameport->private = a3d;
-
a3d->gameport = gameport;
init_timer(>timer);
a3d->timer.data = (long) a3d;
a3d->timer.function = a3d_timer;
 
+   gameport_set_drvdata(gameport, a3d);
+
err = gameport_open(gameport, drv, GAMEPORT_MODE_RAW);
if (err)
goto fail1;
@@ -379,13 +379,14 @@
return 0;
 
 fail2: gameport_close(gameport);
-fail1:  kfree(a3d);
+fail1:  gameport_set_drvdata(gameport, NULL);
+   kfree(a3d);
return err;
 }
 
 static void a3d_disconnect(struct gameport *gameport)
 {
-   struct a3d *a3d = gameport->private;
+   struct a3d *a3d = gameport_get_drvdata(gameport);
 
input_unregister_device(>dev);
if (a3d->adc) {
@@ -393,6 +394,7 @@
a3d->adc = NULL;
}
gameport_close(gameport);
+   gameport_set_drvdata(gameport, NULL);
kfree(a3d);
 }
 
diff -Nru a/drivers/input/joystick/adi.c b/drivers/input/joystick/adi.c
--- a/drivers/input/joystick/adi.c  2005-02-11 01:41:08 -05:00
+++ b/drivers/input/joystick/adi.c  2005-02-11 01:41:08 -05:00
@@ -474,13 +474,13 @@
if (!(port = kcalloc(1, sizeof(struct adi_port), GFP_KERNEL)))
return -ENOMEM;
 
-   gameport->private = port;
-
port->gameport = gameport;
init_timer(>timer);
port->timer.data = (long) port;
port->timer.function = adi_timer;
 
+   gameport_set_drvdata(gameport, port);
+
err = gameport_open(gameport, drv, GAMEPORT_MODE_RAW);
if (err) {
kfree(port);
@@ -524,12 +524,13 @@
 static void adi_disconnect(struct gameport *gameport)
 {
int i;
-   struct adi_port *port = gameport->private;
+   struct adi_port *port = gameport_get_drvdata(gameport);
 
for (i = 0; i < 2; i++)
if (port->adi[i].length > 0)
input_unregister_device(>adi[i].dev);
gameport_close(gameport);
+   gameport_set_drvdata(gameport, NULL);
kfree(port);
 }
 
diff -Nru a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
--- a/drivers/input/joystick/analog.c   2005-02-11 01:41:08 -05:00
+++ b/drivers/input/joystick/analog.c   2005-02-11 01:41:08 -05:00
@@ -593,12 +593,13 @@
 {
int i, t, u, v;
 
-   gameport->private = port;
port->gameport = gameport;
init_timer(>timer);
port->timer.data = (long) port;
port->timer.function = analog_timer;
 
+   gameport_set_drvdata(gameport, port);
+
if (!gameport_open(gameport, drv, GAMEPORT_MODE_RAW)) {
 
analog_calibrate_timer(port);
@@ -672,6 +673,7 @@
err = analog_init_masks(port);
if (err) {
gameport_close(gameport);
+   gameport_set_drvdata(gameport, NULL);
kfree(port);
return err;
}
@@ -686,12 +688,13 @@
 static void analog_disconnect(struct gameport *gameport)
 {
int i;
-   struct analog_port *port = gameport->private;
+   struct analog_port *port = gameport_get_drvdata(gameport);
 
for (i = 0; i < 2; i++)
if (port->analog[i].mask)
input_unregister_device(>analog[i].dev);
gameport_close(gameport);
+   gameport_set_drvdata(gameport, NULL);
printk(KERN_INFO "analog.c: %d out of %d reads (%d%%) on %s failed\n",
port->bads, port->reads, port->reads ? (port->bads * 100 / 
port->reads) : 0,
port->gameport->phys);

[PATCH 9/10] Gameport: complete sysfs integration

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:21:32-05:00, [EMAIL PROTECTED]
  Input: complete gameport sysfs integration, ports are now
 devices in driver model. Implemented similarly to serio.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 drivers/input/gameport/gameport.c |  586 ++
 include/linux/gameport.h  |   64 ++--
 2 files changed, 579 insertions(+), 71 deletions(-)


===



diff -Nru a/drivers/input/gameport/gameport.c 
b/drivers/input/gameport/gameport.c
--- a/drivers/input/gameport/gameport.c 2005-02-11 01:40:19 -05:00
+++ b/drivers/input/gameport/gameport.c 2005-02-11 01:40:19 -05:00
@@ -2,6 +2,7 @@
  * Generic gameport layer
  *
  * Copyright (c) 1999-2002 Vojtech Pavlik
+ * Copyright (c) 2005 Dmitry Torokhov
  */
 
 /*
@@ -10,22 +11,27 @@
  * the Free Software Foundation.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
 #include 
 
+/*#include */
+
 MODULE_AUTHOR("Vojtech Pavlik <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Generic gameport layer");
 MODULE_LICENSE("GPL");
 
-EXPORT_SYMBOL(gameport_register_port);
+EXPORT_SYMBOL(__gameport_register_port);
 EXPORT_SYMBOL(gameport_unregister_port);
-EXPORT_SYMBOL(gameport_register_driver);
+EXPORT_SYMBOL(__gameport_register_driver);
 EXPORT_SYMBOL(gameport_unregister_driver);
 EXPORT_SYMBOL(gameport_open);
 EXPORT_SYMBOL(gameport_close);
@@ -34,13 +40,23 @@
 EXPORT_SYMBOL(gameport_set_name);
 EXPORT_SYMBOL(gameport_set_phys);
 
+/*
+ * gameport_sem protects entire gameport subsystem and is taken
+ * every time gameport port or driver registrered or unregistered.
+ */
+static DECLARE_MUTEX(gameport_sem);
+
 static LIST_HEAD(gameport_list);
-static LIST_HEAD(gameport_driver_list);
 
 static struct bus_type gameport_bus = {
.name = "gameport",
 };
 
+static void gameport_add_port(struct gameport *gameport);
+static void gameport_destroy_port(struct gameport *gameport);
+static void gameport_reconnect_port(struct gameport *gameport);
+static void gameport_disconnect_port(struct gameport *gameport);
+
 #ifdef __i386__
 
 #define DELTA(x,y)  ((y)-(x)+((y)<(x)?1193182/HZ:0))
@@ -106,21 +122,325 @@
 #endif
 }
 
+
+/*
+ * Basic gameport -> driver core mappings
+ */
+
+static void gameport_bind_driver(struct gameport *gameport, struct 
gameport_driver *drv)
+{
+   down_write(_bus.subsys.rwsem);
+
+   gameport->dev.driver = >driver;
+   if (drv->connect(gameport, drv)) {
+   gameport->dev.driver = NULL;
+   goto out;
+   }
+   device_bind_driver(>dev);
+out:
+   up_write(_bus.subsys.rwsem);
+}
+
+static void gameport_release_driver(struct gameport *gameport)
+{
+   down_write(_bus.subsys.rwsem);
+   device_release_driver(>dev);
+   up_write(_bus.subsys.rwsem);
+}
+
 static void gameport_find_driver(struct gameport *gameport)
 {
-struct gameport_driver *drv;
+   down_write(_bus.subsys.rwsem);
+   device_attach(>dev);
+   up_write(_bus.subsys.rwsem);
+}
+
+
+/*
+ * Gameport event processing.
+ */
+
+enum gameport_event_type {
+   GAMEPORT_RESCAN,
+   GAMEPORT_RECONNECT,
+   GAMEPORT_REGISTER_PORT,
+   GAMEPORT_REGISTER_DRIVER,
+};
+
+struct gameport_event {
+   enum gameport_event_type type;
+   void *object;
+   struct module *owner;
+   struct list_head node;
+};
+
+static DEFINE_SPINLOCK(gameport_event_lock);   /* protects gameport_event_list 
*/
+static LIST_HEAD(gameport_event_list);
+static DECLARE_WAIT_QUEUE_HEAD(gameport_wait);
+static DECLARE_COMPLETION(gameport_exited);
+static int gameport_pid;
+
+static void gameport_queue_event(void *object, struct module *owner,
+ enum gameport_event_type event_type)
+{
+   unsigned long flags;
+   struct gameport_event *event;
+
+   spin_lock_irqsave(_event_lock, flags);
 
-list_for_each_entry(drv, _driver_list, node) {
-   if (gameport->drv)
+   /*
+* Scan event list for the other events for the same gameport port,
+* starting with the most recent one. If event is the same we
+* do not need add new one. If event is of different type we
+* need to add this event and should not look further because
+* we need to preseve sequence of distinct events.
+*/
+   list_for_each_entry_reverse(event, _event_list, node) {
+   if (event->object == object) {
+   if (event->type == event_type)
+   goto out;
break;
-   drv->connect(gameport, drv);
-}
+   }
+   }
+
+   if ((event = kmalloc(sizeof(struct gameport_event), GFP_ATOMIC))) {
+   if (!try_module_get(owner)) {
+

[PATCH 8/10] Gameport: add "gameport" sysfs bus, add drivers

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:21:02-05:00, [EMAIL PROTECTED]
  Input: integrate gameport drivers info dribver model/sysfs,
 create "gameport" bus. drivers' connect() routines
 now return error code instead of void.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 drivers/Makefile|2 
 drivers/input/gameport/gameport.c   |   39 ++
 drivers/input/joystick/a3d.c|   44 ++---
 drivers/input/joystick/adi.c|   63 ++
 drivers/input/joystick/analog.c |   52 +++-
 drivers/input/joystick/cobra.c  |   42 
 drivers/input/joystick/gf2k.c   |   42 +---
 drivers/input/joystick/grip.c   |   61 +
 drivers/input/joystick/grip_mp.c|   56 +-
 drivers/input/joystick/guillemot.c  |   53 ++---
 drivers/input/joystick/interact.c   |   32 +++
 drivers/input/joystick/joydump.c|   20 ++---
 drivers/input/joystick/sidewinder.c |   75 +---
 drivers/input/joystick/tmdc.c   |   53 +
 include/linux/gameport.h|6 +-
 15 files changed, 407 insertions(+), 233 deletions(-)


===



diff -Nru a/drivers/Makefile b/drivers/Makefile
--- a/drivers/Makefile  2005-02-11 01:40:01 -05:00
+++ b/drivers/Makefile  2005-02-11 01:40:01 -05:00
@@ -47,8 +47,8 @@
 obj-$(CONFIG_TC)   += tc/
 obj-$(CONFIG_USB)  += usb/
 obj-$(CONFIG_USB_GADGET)   += usb/gadget/
-obj-$(CONFIG_INPUT)+= input/
 obj-$(CONFIG_GAMEPORT) += input/gameport/
+obj-$(CONFIG_INPUT)+= input/
 obj-$(CONFIG_I2O)  += message/
 obj-$(CONFIG_I2C)  += i2c/
 obj-$(CONFIG_W1)   += w1/
diff -Nru a/drivers/input/gameport/gameport.c 
b/drivers/input/gameport/gameport.c
--- a/drivers/input/gameport/gameport.c 2005-02-11 01:40:01 -05:00
+++ b/drivers/input/gameport/gameport.c 2005-02-11 01:40:01 -05:00
@@ -37,6 +37,10 @@
 static LIST_HEAD(gameport_list);
 static LIST_HEAD(gameport_driver_list);
 
+static struct bus_type gameport_bus = {
+   .name = "gameport",
+};
+
 #ifdef __i386__
 
 #define DELTA(x,y)  ((y)-(x)+((y)<(x)?1193182/HZ:0))
@@ -146,6 +150,21 @@
gameport_find_driver(gameport);
 }
 
+/*
+ * Gameport driver operations
+ */
+
+static ssize_t gameport_driver_show_description(struct device_driver *drv, 
char *buf)
+{
+   struct gameport_driver *driver = to_gameport_driver(drv);
+   return sprintf(buf, "%s\n", driver->description ? driver->description : 
"(none)");
+}
+
+static struct driver_attribute gameport_driver_attrs[] = {
+   __ATTR(description, S_IRUGO, gameport_driver_show_description, NULL),
+   __ATTR_NULL
+};
+
 void gameport_unregister_port(struct gameport *gameport)
 {
list_del_init(>node);
@@ -159,6 +178,9 @@
 {
struct gameport *gameport;
 
+   drv->driver.bus = _bus;
+   driver_register(>driver);
+
list_add_tail(>node, _driver_list);
list_for_each_entry(gameport, _list, node)
if (!gameport->drv)
@@ -175,6 +197,7 @@
drv->disconnect(gameport);
gameport_find_driver(gameport);
}
+   driver_unregister(>driver);
 }
 
 int gameport_open(struct gameport *gameport, struct gameport_driver *drv, int 
mode)
@@ -201,3 +224,19 @@
if (gameport->close)
gameport->close(gameport);
 }
+
+static int __init gameport_init(void)
+{
+   gameport_bus.drv_attrs = gameport_driver_attrs;
+   bus_register(_bus);
+
+   return 0;
+}
+
+static void __exit gameport_exit(void)
+{
+   bus_unregister(_bus);
+}
+
+module_init(gameport_init);
+module_exit(gameport_exit);
diff -Nru a/drivers/input/joystick/a3d.c b/drivers/input/joystick/a3d.c
--- a/drivers/input/joystick/a3d.c  2005-02-11 01:40:01 -05:00
+++ b/drivers/input/joystick/a3d.c  2005-02-11 01:40:01 -05:00
@@ -35,8 +35,10 @@
 #include 
 #include 
 
+#define DRIVER_DESC"FP-Gaming Assasin 3D joystick driver"
+
 MODULE_AUTHOR("Vojtech Pavlik <[EMAIL PROTECTED]>");
-MODULE_DESCRIPTION("FP-Gaming Assasin 3D joystick driver");
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
 
 #define A3D_MAX_START  400 /* 400 us */
@@ -108,7 +110,9 @@
 static int a3d_csum(char *data, int count)
 {
int i, csum = 0;
-   for (i = 0; i < count - 2; i++) csum += data[i];
+
+   for (i = 0; i < count - 2; i++)
+   csum += data[i];
return (csum & 0x3f) != ((data[count - 2] << 3) | data[count - 1]);
 }
 
@@ -138,7 +142,7 @@
 
a3d->buttons = ((data[3] << 3) | data[4]) & 0xf;
 
-   return;
+  

[PATCH 7/10] Gameport: convert sound/alsa to dynamic allocation

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:20:30-05:00, [EMAIL PROTECTED]
  Input: convert sound/pci to dynamic gameport allocation.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 include/sound/cs46xx.h   |4 -
 include/sound/trident.h  |4 -
 include/sound/ymfpci.h   |   14 +--
 sound/pci/als4000.c  |  111 +++--
 sound/pci/au88x0/au88x0.c|7 -
 sound/pci/au88x0/au88x0.h|2 
 sound/pci/au88x0/au88x0_game.c   |   49 ++--
 sound/pci/azt3328.c  |  111 +
 sound/pci/cmipci.c   |  104 ++-
 sound/pci/cs4281.c   |   91 ---
 sound/pci/cs46xx/cs46xx_lib.c|   81 ++---
 sound/pci/ens1370.c  |  122 +--
 sound/pci/es1938.c   |   52 ++---
 sound/pci/es1968.c   |   76 ++-
 sound/pci/sonicvibes.c   |   55 +++---
 sound/pci/trident/trident.c  |2 
 sound/pci/trident/trident_main.c |   87 ++
 sound/pci/via82xx.c  |   89 +--
 sound/pci/ymfpci/ymfpci.c|  149 ---
 sound/pci/ymfpci/ymfpci_main.c   |9 --
 20 files changed, 761 insertions(+), 458 deletions(-)


===



diff -Nru a/include/sound/cs46xx.h b/include/sound/cs46xx.h
--- a/include/sound/cs46xx.h2005-02-11 01:39:33 -05:00
+++ b/include/sound/cs46xx.h2005-02-11 01:39:33 -05:00
@@ -1720,7 +1720,7 @@
snd_kcontrol_t *eapd_switch; /* for amplifier hack */
int accept_valid;   /* accept mmap valid (for OSS) */
 
-   struct snd_cs46xx_gameport *gameport;
+   struct gameport *gameport;
 
 #ifdef CONFIG_SND_CS46XX_DEBUG_GPIO
int current_gpio;
@@ -1751,6 +1751,6 @@
 int snd_cs46xx_mixer(cs46xx_t *chip);
 int snd_cs46xx_midi(cs46xx_t *chip, int device, snd_rawmidi_t **rmidi);
 int snd_cs46xx_start_dsp(cs46xx_t *chip);
-void snd_cs46xx_gameport(cs46xx_t *chip);
+int snd_cs46xx_gameport(cs46xx_t *chip);
 
 #endif /* __SOUND_CS46XX_H */
diff -Nru a/include/sound/trident.h b/include/sound/trident.h
--- a/include/sound/trident.h   2005-02-11 01:39:33 -05:00
+++ b/include/sound/trident.h   2005-02-11 01:39:33 -05:00
@@ -448,7 +448,7 @@
 
spinlock_t reg_lock;
 
-   struct snd_trident_gameport *gameport;
+   struct gameport *gameport;
 };
 
 int snd_trident_create(snd_card_t * card,
@@ -457,7 +457,7 @@
   int pcm_spdif_device,
   int max_wavetable_size,
   trident_t ** rtrident);
-void snd_trident_gameport(trident_t *trident);
+int snd_trident_create_gameport(trident_t *trident);
 
 int snd_trident_pcm(trident_t * trident, int device, snd_pcm_t **rpcm);
 int snd_trident_foldback_pcm(trident_t * trident, int device, snd_pcm_t 
**rpcm);
diff -Nru a/include/sound/ymfpci.h b/include/sound/ymfpci.h
--- a/include/sound/ymfpci.h2005-02-11 01:39:33 -05:00
+++ b/include/sound/ymfpci.h2005-02-11 01:39:33 -05:00
@@ -198,6 +198,10 @@
 #define YMFPCI_LEGACY2_IMOD(1 << 15)   /* legacy IRQ mode */
 /* SIEN:IMOD 0:0 = legacy irq, 0:1 = INTA, 1:0 = serialized IRQ */
 
+#if defined(CONFIG_GAMEPORT) || (defined(MODULE) && 
defined(CONFIG_GAMEPORT_MODULE))
+#define SUPPORT_JOYSTICK
+#endif
+
 /*
  *
  */
@@ -311,9 +315,8 @@
struct resource *mpu_res;
 
unsigned short old_legacy_ctrl;
-#if defined(CONFIG_GAMEPORT) || defined(CONFIG_GAMEPORT_MODULE)
-   struct resource *joystick_res;
-   struct gameport gameport;
+#ifdef SUPPORT_JOYSTICK
+   struct gameport *gameport;
 #endif
 
struct snd_dma_buffer work_ptr;
@@ -381,6 +384,7 @@
  struct pci_dev *pci,
  unsigned short old_legacy_ctrl,
  ymfpci_t ** rcodec);
+void snd_ymfpci_free_gameport(ymfpci_t *chip);
 
 int snd_ymfpci_pcm(ymfpci_t *chip, int device, snd_pcm_t **rpcm);
 int snd_ymfpci_pcm2(ymfpci_t *chip, int device, snd_pcm_t **rpcm);
@@ -388,9 +392,5 @@
 int snd_ymfpci_pcm_4ch(ymfpci_t *chip, int device, snd_pcm_t **rpcm);
 int snd_ymfpci_mixer(ymfpci_t *chip, int rear_switch);
 int snd_ymfpci_timer(ymfpci_t *chip, int device);
-
-#if defined(CONFIG_GAMEPORT) || (defined(MODULE) && 
defined(CONFIG_GAMEPORT_MODULE))
-#define SUPPORT_JOYSTICK
-#endif
 
 #endif /* __SOUND_YMFPCI_H */
diff -Nru a/sound/pci/als4000.c b/sound/pci/als4000.c
--- a/sound/pci/als4000.c   2005-02-11 01:39:34 -05:00
+++ b/sound/pci/als4000.c   2005-02-11 01:39:34 -05:00
@@ -104,8 +104,7 @@
struct pci_dev *pci;
unsigned long gcr;
 #ifdef SUPPORT_JOYSTICK
-   struct gameport gameport;
-   struct resource *res_joystick;
+   struct gameport *gameport;
 #endif
 } 

[PATCH 6/10] Gameport: convert sound/oss to dynamic allocation

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:20:08-05:00, [EMAIL PROTECTED]
  Input: convert sound/oss to dynamic gameport allocation.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 cmpci.c  |  100 ++-
 es1370.c |   34 
 es1371.c |   52 ++
 esssolo1.c   |   47 ---
 mad16.c  |   47 ++-
 sonicvibes.c |   49 +---
 trident.c|   39 +--
 7 files changed, 249 insertions(+), 119 deletions(-)


===



diff -Nru a/sound/oss/cmpci.c b/sound/oss/cmpci.c
--- a/sound/oss/cmpci.c 2005-02-11 01:38:28 -05:00
+++ b/sound/oss/cmpci.c 2005-02-11 01:38:28 -05:00
@@ -426,7 +426,7 @@
struct address_info mpu_data;
 #endif
 #ifdef CONFIG_SOUND_CMPCI_JOYSTICK
-   struct gameport gameport;
+   struct gameport *gameport;
 #endif
 
int chip_version;
@@ -468,17 +468,17 @@
 
 static LIST_HEAD(devs);
 
-static int mpuio = 0;
-static int fmio = 0;
-static int joystick = 0;
-static int spdif_inverse = 0;
-static int spdif_loop = 0;
-static int spdif_out = 0;
-static int use_line_as_rear = 0;
-static int use_line_as_bass = 0;
-static int use_mic_as_bass = 0;
-static int mic_boost = 0;
-static int hw_copy = 0;
+static int mpuio;
+static int fmio;
+static int joystick;
+static int spdif_inverse;
+static int spdif_loop;
+static int spdif_out;
+static int use_line_as_rear;
+static int use_line_as_bass;
+static int use_mic_as_bass;
+static int mic_boost;
+static int hw_copy;
 module_param(mpuio, int, 0);
 module_param(fmio, int, 0);
 module_param(joystick, bool, 0);
@@ -2984,6 +2984,51 @@
return ChipVersion;
 }
 
+#ifdef CONFIG_SOUND_CMPCI_JOYSTICK
+static int __devinit cm_create_gameport(struct cm_state *s, int io_port)
+{
+   struct gameport *gp;
+
+   if (!request_region(io_port, CM_EXTENT_GAME, "cmpci GAME")) {
+   printk(KERN_ERR "cmpci: gameport io ports 0x%#x in use\n", 
io_port);
+   return -EBUSY;
+   }
+
+   if (!(s->gameport = gp = gameport_allocate_port())) {
+   printk(KERN_ERR "cmpci: can not allocate memory for 
gameport\n");
+   release_region(io_port, CM_EXTENT_GAME);
+   return -ENOMEM;
+   }
+
+   gameport_set_name(gp, "C-Media GP");
+   gameport_set_phys(gp, "pci%s/gameport0", pci_name(s->dev));
+   gp->dev.parent = >dev->dev;
+   gp->io = io_port;
+
+   /* enable joystick */
+   maskb(s->iobase + CODEC_CMI_FUNCTRL1, ~0, 0x02);
+
+   gameport_register_port(gp);
+
+   return 0;
+}
+
+static void __devexit cm_free_gameport(struct cm_state *s)
+{
+   if (s->gameport) {
+   int gpio = s->gameport->io;
+
+   gameport_unregister_port(s->gameport);
+   s->gameport = NULL;
+   maskb(s->iobase + CODEC_CMI_FUNCTRL1, ~0x02, 0);
+   release_region(gpio, CM_EXTENT_GAME);
+   }
+}
+#else
+static inline int cm_create_gameport(struct cm_state *s, int io_port) { return 
-ENOSYS; }
+static inline void cm_free_gameport(struct cm_state *s) { }
+#endif
+
 #defineecho_option(x)\
 if (x) strcat(options, "" #x " ")
 
@@ -3229,22 +3274,11 @@
}
 skip_mpu:
 #endif
-#ifdef CONFIG_SOUND_CMPCI_JOYSTICK
-   /* enable joystick */
-   if (joystick) {
-   s->gameport.io = 0x200;
-   if (!request_region(s->gameport.io, CM_EXTENT_GAME, "cmpci 
GAME")) {
-   printk(KERN_ERR "cmpci: gameport io ports in use\n");
-   s->gameport.io = 0;
-   } else {
-   maskb(s->iobase + CODEC_CMI_FUNCTRL1, ~0, 0x02);
-   gameport_register_port(>gameport);
-   }
-   } else {
-   maskb(s->iobase + CODEC_CMI_FUNCTRL1, ~0x02, 0);
-   s->gameport.io = 0;
-   }
-#endif
+   /* disable joystick port */
+   maskb(s->iobase + CODEC_CMI_FUNCTRL1, ~0x02, 0);
+   if (joystick)
+   cm_create_gameport(s, 0x200);
+
/* store it in the driver field */
pci_set_drvdata(pcidev, s);
/* put it into driver list */
@@ -3278,13 +3312,9 @@
 
if (!s)
return;
-#ifdef CONFIG_SOUND_CMPCI_JOYSTICK
-   if (s->gameport.io) {
-   gameport_unregister_port(>gameport);
-   release_region(s->gameport.io, CM_EXTENT_GAME);
-   maskb(s->iobase + CODEC_CMI_FUNCTRL1, ~0x02, 0);
-   }
-#endif
+
+   cm_free_gameport(s);
+
 #ifdef CONFIG_SOUND_CMPCI_FM
if (s->iosynth) {
/* disable FM */
diff -Nru a/sound/oss/es1370.c b/sound/oss/es1370.c
--- 

[PATCH 4/10] Gameport: prepare to dynamic allocation

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:18:48-05:00, [EMAIL PROTECTED]
  Input: prepare for dynamic gameport allocation:
 - provide functions to allocate and free gameports;
 - provide functions to properly set name and phys;
 - dynamically allocated gameports are automatically
   announced in kernel logs and freed when unregistered.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 drivers/input/gameport/gameport.c |   24 
 include/linux/gameport.h  |   38 +++---
 2 files changed, 55 insertions(+), 7 deletions(-)


===



diff -Nru a/drivers/input/gameport/gameport.c 
b/drivers/input/gameport/gameport.c
--- a/drivers/input/gameport/gameport.c 2005-02-11 01:36:13 -05:00
+++ b/drivers/input/gameport/gameport.c 2005-02-11 01:36:13 -05:00
@@ -31,6 +31,8 @@
 EXPORT_SYMBOL(gameport_close);
 EXPORT_SYMBOL(gameport_rescan);
 EXPORT_SYMBOL(gameport_cooked_read);
+EXPORT_SYMBOL(gameport_set_name);
+EXPORT_SYMBOL(gameport_set_phys);
 
 static LIST_HEAD(gameport_list);
 static LIST_HEAD(gameport_driver_list);
@@ -117,10 +119,30 @@
gameport_find_driver(gameport);
 }
 
+void gameport_set_phys(struct gameport *gameport, const char *fmt, ...)
+{
+   va_list args;
+
+   va_start(args, fmt);
+   gameport->phys = gameport->phys_buf;
+   vsnprintf(gameport->phys_buf, sizeof(gameport->phys_buf), fmt, args);
+   va_end(args);
+}
+
 void gameport_register_port(struct gameport *gameport)
 {
list_add_tail(>node, _list);
gameport->speed = gameport_measure_speed(gameport);
+
+   if (gameport->dyn_alloc) {
+   if (gameport->io)
+   printk(KERN_INFO "gameport: %s is %s, io %#x, speed %d 
kHz\n",
+   gameport->name, gameport->phys, gameport->io, 
gameport->speed);
+   else
+   printk(KERN_INFO "gameport: %s is %s, speed %d kHz\n",
+   gameport->name, gameport->phys, 
gameport->speed);
+   }
+
gameport_find_driver(gameport);
 }
 
@@ -129,6 +151,8 @@
list_del_init(>node);
if (gameport->drv)
gameport->drv->disconnect(gameport);
+   if (gameport->dyn_alloc)
+   kfree(gameport);
 }
 
 void gameport_register_driver(struct gameport_driver *drv)
diff -Nru a/include/linux/gameport.h b/include/linux/gameport.h
--- a/include/linux/gameport.h  2005-02-11 01:36:13 -05:00
+++ b/include/linux/gameport.h  2005-02-11 01:36:13 -05:00
@@ -12,15 +12,16 @@
 #include 
 #include 
 #include 
-
-struct gameport;
+#include 
 
 struct gameport {
 
void *private;  /* Private pointer for joystick drivers */
void *port_data;/* Private pointer for gameport drivers */
char *name;
+   char name_buf[32];
char *phys;
+   char phys_buf[32];
 
struct input_id id;
 
@@ -36,8 +37,12 @@
void (*close)(struct gameport *);
 
struct gameport_driver *drv;
+   struct device dev;
 
struct list_head node;
+
+   /* temporary, till sysfs transition is complete */
+   int dyn_alloc;
 };
 
 struct gameport_driver {
@@ -55,13 +60,32 @@
 void gameport_close(struct gameport *gameport);
 void gameport_rescan(struct gameport *gameport);
 
-#if defined(CONFIG_GAMEPORT) || defined(CONFIG_GAMEPORT_MODULE)
+static inline struct gameport *gameport_allocate_port(void)
+{
+   struct gameport *gameport = kcalloc(1, sizeof(struct gameport), 
GFP_KERNEL);
+
+   if (gameport)
+   gameport->dyn_alloc = 1;
+
+   return gameport;
+}
+
+static inline void gameport_free_port(struct gameport *gameport)
+{
+   kfree(gameport);
+}
+
+static inline void gameport_set_name(struct gameport *gameport, const char 
*name)
+{
+   gameport->name = gameport->name_buf;
+   strlcpy(gameport->name, name, sizeof(gameport->name_buf));
+}
+
+void gameport_set_phys(struct gameport *gameport, const char *fmt, ...)
+   __attribute__ ((format (printf, 2, 3)));
+
 void gameport_register_port(struct gameport *gameport);
 void gameport_unregister_port(struct gameport *gameport);
-#else
-static inline void gameport_register_port(struct gameport *gameport) { return; 
}
-static inline void gameport_unregister_port(struct gameport *gameport) { 
return; }
-#endif
 
 void gameport_register_driver(struct gameport_driver *drv);
 void gameport_unregister_driver(struct gameport_driver *drv);
-
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/10] Gameport: convert input/gameport to dynamic allocation

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:19:36-05:00, [EMAIL PROTECTED]
  Input: convert input/gameport to dynamic gameport allocation.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 drivers/input/gameport/cs461x.c |   29 +
 drivers/input/gameport/emu10k1-gp.c |   40 
 drivers/input/gameport/fm801-gp.c   |   57 +--
 drivers/input/gameport/lightning.c  |  176 ++--
 drivers/input/gameport/ns558.c  |  120 +++-
 drivers/input/gameport/vortex.c |   68 ++---
 drivers/input/joystick/a3d.c|   59 +---
 include/linux/gameport.h|3 
 8 files changed, 286 insertions(+), 266 deletions(-)


===



diff -Nru a/drivers/input/gameport/cs461x.c b/drivers/input/gameport/cs461x.c
--- a/drivers/input/gameport/cs461x.c   2005-02-11 01:38:07 -05:00
+++ b/drivers/input/gameport/cs461x.c   2005-02-11 01:38:07 -05:00
@@ -120,9 +120,6 @@
 static unsigned long ba0_addr;
 static unsigned int __iomem *ba0;
 
-static char phys[32];
-static char name[] = "CS416x Gameport";
-
 #ifdef CS461X_FULL_MAP
 static unsigned long ba1_addr;
 static union ba1_t {
@@ -160,10 +157,10 @@
 static int cs461x_free(struct pci_dev *pdev)
 {
struct gameport *port = pci_get_drvdata(pdev);
-   if(port){
+
+   if (port)
gameport_unregister_port(port);
-   kfree(port);
-   }
+
if (ba0) iounmap(ba0);
 #ifdef CS461X_FULL_MAP
if (ba1.name.data0) iounmap(ba1.name.data0);
@@ -267,18 +264,17 @@
 return -ENOMEM;
 }
 #else
-   if (ba0 == NULL){
+   if (ba0 == NULL) {
cs461x_free(pdev);
return -ENOMEM;
}
 #endif
 
-   if (!(port = kmalloc(sizeof(struct gameport), GFP_KERNEL))) {
-   printk(KERN_ERR "Memory allocation failed.\n");
+   if (!(port = gameport_allocate_port())) {
+   printk(KERN_ERR "cs461x: Memory allocation failed\n");
cs461x_free(pdev);
return -ENOMEM;
}
-   memset(port, 0, sizeof(struct gameport));
 
pci_set_drvdata(pdev, port);
 
@@ -287,21 +283,14 @@
port->read = cs461x_gameport_read;
port->cooked_read = cs461x_gameport_cooked_read;
 
-   sprintf(phys, "pci%s/gameport0", pci_name(pdev));
-
-   port->name = name;
-   port->phys = phys;
-   port->id.bustype = BUS_PCI;
-   port->id.vendor = pdev->vendor;
-   port->id.product = pdev->device;
+   gameport_set_name(port, "CS416x");
+   gameport_set_phys(port, "pci%s/gameport0", pci_name(pdev));
+   port->dev.parent = >dev;
 
cs461x_pokeBA0(BA0_JSIO, 0xFF); // ?
cs461x_pokeBA0(BA0_JSCTL, JSCTL_SP_MEDIUM_SLOW);
 
gameport_register_port(port);
-
-   printk(KERN_INFO "gameport: %s on pci%s speed %d kHz\n",
-   name, pci_name(pdev), port->speed);
 
return 0;
 }
diff -Nru a/drivers/input/gameport/emu10k1-gp.c 
b/drivers/input/gameport/emu10k1-gp.c
--- a/drivers/input/gameport/emu10k1-gp.c   2005-02-11 01:38:07 -05:00
+++ b/drivers/input/gameport/emu10k1-gp.c   2005-02-11 01:38:07 -05:00
@@ -44,13 +44,13 @@
 
 struct emu {
struct pci_dev *dev;
-   struct gameport gameport;
+   struct gameport *gameport;
+   int io;
int size;
-   char phys[32];
 };
 
 static struct pci_device_id emu_tbl[] = {
- 
+
{ 0x1102, 0x7002, PCI_ANY_ID, PCI_ANY_ID }, /* SB Live gameport */
{ 0x1102, 0x7003, PCI_ANY_ID, PCI_ANY_ID }, /* Audigy gameport */
{ 0x1102, 0x7004, PCI_ANY_ID, PCI_ANY_ID }, /* Dell SB Live */
@@ -64,6 +64,7 @@
 {
int ioport, iolen;
struct emu *emu;
+   struct gameport *port;
 
if (pci_enable_device(pdev))
return -EBUSY;
@@ -74,31 +75,29 @@
if (!request_region(ioport, iolen, "emu10k1-gp"))
return -EBUSY;
 
-   if (!(emu = kmalloc(sizeof(struct emu), GFP_KERNEL))) {
-   printk(KERN_ERR "emu10k1-gp: Memory allocation failed.\n");
+   emu = kcalloc(1, sizeof(struct emu), GFP_KERNEL);
+   port = gameport_allocate_port();
+   if (!emu || !port) {
+   printk(KERN_ERR "emu10k1-gp: Memory allocation failed\n");
release_region(ioport, iolen);
+   kfree(emu);
+   gameport_free_port(port);
return -ENOMEM;
}
-   memset(emu, 0, sizeof(struct emu));
-
-   sprintf(emu->phys, "pci%s/gameport0", pci_name(pdev));
 
+   emu->io = ioport;
emu->size = iolen;
emu->dev = pdev;
+   emu->gameport = port;
 
-   emu->gameport.io = ioport;
-   emu->gameport.name = pci_name(pdev);
-   emu->gameport.phys = emu->phys;
-   emu->gameport.id.bustype = BUS_PCI;
-   emu->gameport.id.vendor = pdev->vendor;
-

[PATCH 2/10] Gameport: rename gameport_dev to gameport_driver

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:09:59-05:00, [EMAIL PROTECTED]
  Input: more renames in gameport in preparations to sysfs integration
 - gameport_dev -> gameport_driver
 - gameport_[un]register_device -> gameport_[un]register_driver
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 drivers/input/gameport/gameport.c   |   52 ++--
 drivers/input/joystick/a3d.c|   10 +++---
 drivers/input/joystick/adi.c|   10 +++---
 drivers/input/joystick/analog.c |   18 ++--
 drivers/input/joystick/cobra.c  |   10 +++---
 drivers/input/joystick/gf2k.c   |   10 +++---
 drivers/input/joystick/grip.c   |   10 +++---
 drivers/input/joystick/grip_mp.c|   10 +++---
 drivers/input/joystick/guillemot.c  |   10 +++---
 drivers/input/joystick/interact.c   |   10 +++---
 drivers/input/joystick/joydump.c|   12 
 drivers/input/joystick/sidewinder.c |   10 +++---
 drivers/input/joystick/tmdc.c   |   10 +++---
 include/linux/gameport.h|   12 
 14 files changed, 97 insertions(+), 97 deletions(-)


===



diff -Nru a/drivers/input/gameport/gameport.c 
b/drivers/input/gameport/gameport.c
--- a/drivers/input/gameport/gameport.c 2005-02-11 01:34:53 -05:00
+++ b/drivers/input/gameport/gameport.c 2005-02-11 01:34:53 -05:00
@@ -25,15 +25,15 @@
 
 EXPORT_SYMBOL(gameport_register_port);
 EXPORT_SYMBOL(gameport_unregister_port);
-EXPORT_SYMBOL(gameport_register_device);
-EXPORT_SYMBOL(gameport_unregister_device);
+EXPORT_SYMBOL(gameport_register_driver);
+EXPORT_SYMBOL(gameport_unregister_driver);
 EXPORT_SYMBOL(gameport_open);
 EXPORT_SYMBOL(gameport_close);
 EXPORT_SYMBOL(gameport_rescan);
 EXPORT_SYMBOL(gameport_cooked_read);
 
 static LIST_HEAD(gameport_list);
-static LIST_HEAD(gameport_dev_list);
+static LIST_HEAD(gameport_driver_list);
 
 #ifdef __i386__
 
@@ -100,61 +100,61 @@
 #endif
 }
 
-static void gameport_find_dev(struct gameport *gameport)
+static void gameport_find_driver(struct gameport *gameport)
 {
-struct gameport_dev *dev;
+struct gameport_driver *drv;
 
-list_for_each_entry(dev, _dev_list, node) {
-   if (gameport->dev)
+list_for_each_entry(drv, _driver_list, node) {
+   if (gameport->drv)
break;
-   if (dev->connect)
-   dev->connect(gameport, dev);
+   if (drv->connect)
+   drv->connect(gameport, drv);
 }
 }
 
 void gameport_rescan(struct gameport *gameport)
 {
gameport_close(gameport);
-   gameport_find_dev(gameport);
+   gameport_find_driver(gameport);
 }
 
 void gameport_register_port(struct gameport *gameport)
 {
list_add_tail(>node, _list);
gameport->speed = gameport_measure_speed(gameport);
-   gameport_find_dev(gameport);
+   gameport_find_driver(gameport);
 }
 
 void gameport_unregister_port(struct gameport *gameport)
 {
list_del_init(>node);
-   if (gameport->dev && gameport->dev->disconnect)
-   gameport->dev->disconnect(gameport);
+   if (gameport->drv && gameport->drv->disconnect)
+   gameport->drv->disconnect(gameport);
 }
 
-void gameport_register_device(struct gameport_dev *dev)
+void gameport_register_driver(struct gameport_driver *drv)
 {
struct gameport *gameport;
 
-   list_add_tail(>node, _dev_list);
+   list_add_tail(>node, _driver_list);
list_for_each_entry(gameport, _list, node)
-   if (!gameport->dev && dev->connect)
-   dev->connect(gameport, dev);
+   if (!gameport->drv && drv->connect)
+   drv->connect(gameport, drv);
 }
 
-void gameport_unregister_device(struct gameport_dev *dev)
+void gameport_unregister_driver(struct gameport_driver *drv)
 {
struct gameport *gameport;
 
-   list_del_init(>node);
+   list_del_init(>node);
list_for_each_entry(gameport, _list, node) {
-   if (gameport->dev == dev && dev->disconnect)
-   dev->disconnect(gameport);
-   gameport_find_dev(gameport);
+   if (gameport->drv == drv && drv->disconnect)
+   drv->disconnect(gameport);
+   gameport_find_driver(gameport);
}
 }
 
-int gameport_open(struct gameport *gameport, struct gameport_dev *dev, int 
mode)
+int gameport_open(struct gameport *gameport, struct gameport_driver *drv, int 
mode)
 {
if (gameport->open) {
if (gameport->open(gameport, mode))
@@ -164,17 +164,17 @@
return -1;
}
 
-   if (gameport->dev)
+   if (gameport->drv)
return -1;
 
-   gameport->dev = dev;
+   gameport->drv = drv;
 
return 0;
 }
 
 void 

[PATCH 3/10] Gameport: connect() is mandatory

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:18:29-05:00, [EMAIL PROTECTED]
  Input: make connect and disconnect methods mandatory for gameport
 drivers since that's where gameport_{open|close} are called
 from to actually bind driver to a port.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 gameport.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)


===



diff -Nru a/drivers/input/gameport/gameport.c 
b/drivers/input/gameport/gameport.c
--- a/drivers/input/gameport/gameport.c 2005-02-11 01:35:40 -05:00
+++ b/drivers/input/gameport/gameport.c 2005-02-11 01:35:40 -05:00
@@ -107,8 +107,7 @@
 list_for_each_entry(drv, _driver_list, node) {
if (gameport->drv)
break;
-   if (drv->connect)
-   drv->connect(gameport, drv);
+   drv->connect(gameport, drv);
 }
 }
 
@@ -128,7 +127,7 @@
 void gameport_unregister_port(struct gameport *gameport)
 {
list_del_init(>node);
-   if (gameport->drv && gameport->drv->disconnect)
+   if (gameport->drv)
gameport->drv->disconnect(gameport);
 }
 
@@ -138,7 +137,7 @@
 
list_add_tail(>node, _driver_list);
list_for_each_entry(gameport, _list, node)
-   if (!gameport->drv && drv->connect)
+   if (!gameport->drv)
drv->connect(gameport, drv);
 }
 
@@ -148,7 +147,7 @@
 
list_del_init(>node);
list_for_each_entry(gameport, _list, node) {
-   if (gameport->drv == drv && drv->disconnect)
+   if (gameport->drv == drv)
drv->disconnect(gameport);
gameport_find_driver(gameport);
}
-
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/10] Gameport: rename driver to port_data

[Dmitry Torokhov]

===


[EMAIL PROTECTED], 2005-02-11 01:09:43-05:00, [EMAIL PROTECTED]
  Input: rename gameport->driver to gameport->port_data in preparation
 to sysfs integration.

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


 drivers/input/gameport/lightning.c |8 
 drivers/input/gameport/vortex.c|   10 +-
 drivers/input/joystick/a3d.c   |8 
 include/linux/gameport.h   |4 ++--
 sound/oss/trident.c|   10 +-
 sound/pci/au88x0/au88x0_game.c |   15 +++
 6 files changed, 27 insertions(+), 28 deletions(-)


===



diff -Nru a/drivers/input/gameport/lightning.c 
b/drivers/input/gameport/lightning.c
--- a/drivers/input/gameport/lightning.c2005-02-11 01:34:39 -05:00
+++ b/drivers/input/gameport/lightning.c2005-02-11 01:34:39 -05:00
@@ -79,7 +79,7 @@
 
 static int l4_cooked_read(struct gameport *gameport, int *axes, int *buttons)
 {
-   struct l4 *l4 = gameport->driver;
+   struct l4 *l4 = gameport->port_data;
unsigned char status;
int i, result = -1;
 
@@ -112,7 +112,7 @@
 
 static int l4_open(struct gameport *gameport, int mode)
 {
-   struct l4 *l4 = gameport->driver;
+   struct l4 *l4 = gameport->port_data;
 if (l4->port != 0 && mode != GAMEPORT_MODE_COOKED)
return -1;
outb(L4_SELECT_ANALOG, L4_PORT);
@@ -190,7 +190,7 @@
 {
int i, t;
int cal[4];
-   struct l4 *l4 = gameport->driver;
+   struct l4 *l4 = gameport->port_data;
 
if (l4_getcal(l4->port, cal))
return -1;
@@ -252,7 +252,7 @@
sprintf(l4->phys, "isa%04x/gameport%d", L4_PORT, 4 * i 
+ j);
 
gameport = >gameport;
-   gameport->driver = l4;
+   gameport->port_data = l4;
gameport->open = l4_open;
gameport->cooked_read = l4_cooked_read;
gameport->calibrate = l4_calibrate;
diff -Nru a/drivers/input/gameport/vortex.c b/drivers/input/gameport/vortex.c
--- a/drivers/input/gameport/vortex.c   2005-02-11 01:34:39 -05:00
+++ b/drivers/input/gameport/vortex.c   2005-02-11 01:34:39 -05:00
@@ -62,19 +62,19 @@
 
 static unsigned char vortex_read(struct gameport *gameport)
 {
-   struct vortex *vortex = gameport->driver;
+   struct vortex *vortex = gameport->port_data;
return readb(vortex->io + VORTEX_LEG);
 }
 
 static void vortex_trigger(struct gameport *gameport)
 {
-   struct vortex *vortex = gameport->driver;
+   struct vortex *vortex = gameport->port_data;
writeb(0xff, vortex->io + VORTEX_LEG);
 }
 
 static int vortex_cooked_read(struct gameport *gameport, int *axes, int 
*buttons)
 {
-   struct vortex *vortex = gameport->driver;
+   struct vortex *vortex = gameport->port_data;
int i;
 
*buttons = (~readb(vortex->base + VORTEX_LEG) >> 4) & 0xf;
@@ -89,7 +89,7 @@
 
 static int vortex_open(struct gameport *gameport, int mode)
 {
-   struct vortex *vortex = gameport->driver;
+   struct vortex *vortex = gameport->port_data;
 
switch (mode) {
case GAMEPORT_MODE_COOKED:
@@ -120,7 +120,7 @@
 
pci_set_drvdata(dev, vortex);
 
-   vortex->gameport.driver = vortex;
+   vortex->gameport.port_data = vortex;
vortex->gameport.fuzz = 64;
 
vortex->gameport.read = vortex_read;
diff -Nru a/drivers/input/joystick/a3d.c b/drivers/input/joystick/a3d.c
--- a/drivers/input/joystick/a3d.c  2005-02-11 01:34:39 -05:00
+++ b/drivers/input/joystick/a3d.c  2005-02-11 01:34:39 -05:00
@@ -197,7 +197,7 @@
 
 static int a3d_adc_cooked_read(struct gameport *gameport, int *axes, int 
*buttons)
 {
-   struct a3d *a3d = gameport->driver;
+   struct a3d *a3d = gameport->port_data;
int i;
for (i = 0; i < 4; i++)
axes[i] = (a3d->axes[i] < 254) ? a3d->axes[i] : -1;
@@ -212,7 +212,7 @@
 
 static int a3d_adc_open(struct gameport *gameport, int mode)
 {
-   struct a3d *a3d = gameport->driver;
+   struct a3d *a3d = gameport->port_data;
if (mode != GAMEPORT_MODE_COOKED)
return -1;
if (!a3d->used++)
@@ -226,7 +226,7 @@
 
 static void a3d_adc_close(struct gameport *gameport)
 {
-   struct a3d *a3d = gameport->driver;
+   struct a3d *a3d = gameport->port_data;
if (!--a3d->used)
del_timer(>timer);
 }
@@ -336,7 +336,7 @@
a3d->dev.relbit[0] |= BIT(REL_X) | BIT(REL_Y);
a3d->dev.keybit[LONG(BTN_MOUSE)] |= BIT(BTN_RIGHT) | 
BIT(BTN_LEFT) | BIT(BTN_MIDDLE);
 
-   a3d->adc.driver = a3d;
+   a3d->adc.port_data = a3d;
a3d->adc.open = a3d_adc_open;
a3d->adc.close = a3d_adc_close;

[PATCH 0/10] Convert gameport to driver model/sysfs

[Dmitry Torokhov]

Hi,

This series of patches adds a new "gameport" bus to the driver model.
It is implemented very similarly to "serio" bus and also allows
individual drivers to be manually bound/disconnected from a port
by manipulating port's "drvctl" attribute.

01-gameport-renames1.patch
- rename gameport->driver to gameport->port_data in preparation
  to sysfs integration to avoid confusion with real drivers.

02-gameport-renames2.patch
- more renames in gameport in preparations to sysfs integration,
  gameport_dev renamed to gameport_driver, gameport_[un]register_device
  renamed to gameport_[un]register_driver

03-gameport-connect-mandatory.patch
- make connect and disconnect mandatory as these call gameport_open
  and gameport_close which actually bind driver and port together.

04-gameport-dynalloc-prepare.patch
- sysfs/kobjects requires objects be allocated synamically. Prepare
  to dynamic gameport allocation, create gameport_allocate_port and
  gameport_free_port; dynamically allocated ports are freed by core
  upon release. Also add gameport_set_name and gameport_set_phys
  to ease transition.

05-gameport-dynalloc-input.patch
- convert drivers in input/gameport to dynamic gameport allocation.

06-gameport-dynalloc-sound-oss.patch
- convert drivers in sound/oss to dynamic gameport allocation.

07-gameport-dynalloc-sound-alsa.patch
- convert drivers in sound/pci to dynamic gameport allocation.

08-gameport-drivers-sysfs.patch
- add "gameport" bus and have joystick gameport drivers register
  themselves on this bus.

09-gameport-devices-sysfs.patch
- complete gameport sysfs integration. Gameports are registered on
  the "gameport" bus.
 
10-gameport-drvdata.patch
- Get rid of gameport->private, use driver-specific data in device
  structure, access through gameport_get/set_drvdata helpers.

The changes can also be pulled from my tree (which has Vojtech's
input tree as a parent):

bk pull bk://dtor.bkbits.net/input 

I am CC-ing ALSA list as the changes touch quite a few sound drivers.

Comments/testing is appreciated.

-- 
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: 2.6.11-rc3-mm2

[Matt Mackall]

On Thu, Feb 10, 2005 at 10:41:28PM -0500, Paul Davis wrote:
>   [ the best solution is  ]
> 
>   [ my preferred solution is ... ]
> 
>   [ it would be better if ... ]
> 
>   [ this is a kludge and it should be done instead like ... ]
> 
> did nobody read what andrew wrote and what JOQ pointed out?
> 
> after weeks of debating this, no other conceptual solution emerged
> that did not have at least as many problems as the RT LSM module, and
> all other proposed solutions were also more invasive of other aspects
> of kernel design and operations than RT LSM is.

Eh? Chris Wright's original rlimits patch was very straightforward
(unlike some of the other rlimit-like patches that followed).
I haven't heard the downsides of it yet.

simple rlimits:
 logical extension of standard, flexible interface
 fine-grained per-process access to nice levels and priorities
 managed with standard tools
 fairly broad possible applications
 clean enough to be added unconditionally
 already doing mlock this way!

RT LSM:
 new, narrow magic group interface (module parameters!)
 boolean granularity of access to all RT levels and maybe mlock
 potential interesting interaction with other LSMs
 not orthogonal to mlock
 not appropriate for every box out there
 requires lsm and (sysfs or modprobe)

-- 
Mathematics is the supreme nostalgia of our time.
-
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: (fwd) Re: Bug#289770: kernel-image-2.6.10-1-686: 2.6.10 fails to set up DMA on my IBM thinkpad

[Marcin Kuk]

On Thu, Feb 10, 2005 at 08:02:01PM +, Philip Armstrong wrote:
> On Wed, Jan 12, 2005 at 01:52:33PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 12 January 2005 13:02, Philip Armstrong wrote:
> > > On Tue, Jan 11, 2005 at 08:53:45PM +0100, maximilian attems wrote:
> > > > dma on a thinkpad  600E worked for 2.6.8, but didn't since 2.6.9
> > > > also non working 2.6.10.
> > > > 
> > > > -hda: 12594960 sectors (6448 MB) w/460KiB Cache, CHS=13328/15/63, 
> > > > UDMA(33)
> > > > +hda: 12594960 sectors (6448 MB) w/460KiB Cache, CHS=13328/15/63
> > > > 
> > > > could you please look at the following ide dma bug report for piix in
> > > > debian -> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289770
> > > > full dmesg of both 2.6.8 and 2.6.10 are posted there.
> > 
> > "something" steals resource needed for IDE driver so no DMA
> 
> Further investigation reveals that turning off CONFIG_PNPBIOS solves
> the problem.
> 
> With PNPBIOS set, the kernel seems to think that the io range is in
> use regardless of whether quickboot is set in the BIOS or not.

I have Toshiba Satellite 320CDT.
I compiled 2.6.10 vanilla kernel with CONFIG_PNPBIOS disabled.
All IDE drivers was compiled into the kernel.
I can't still enable DMA for my harrddisk.
This is my earlier crying:

http://marc.theaimsgroup.com/?t=11078916604=1=2

What can I do?

Best regards

-- 
Marcin Kuk
-
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] Update panic() comment

[Heiko Carstens]

[PATCH] Update panic() comment

panic() doesn't flush the filesystem cache anymore. The comment above the
function still claims it does.

Thanks,
Heiko

diff -urN a/kernel/panic.c b/kernel/panic.c
--- a/kernel/panic.cFri Feb 11 07:41:57 2005
+++ b/kernel/panic.cFri Feb 11 07:42:08 2005
@@ -49,8 +49,7 @@
  * panic - halt the system
  * @fmt: The text string to print
  *
- * Display a message, then perform cleanups. Functions in the panic
- * notifier list are called after the filesystem cache is flushed (when 
possible).
+ * Display a message, then perform cleanups.
  *
  * This function never returns.
  */
-
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Thu, 2005-02-10 at 22:18 -0500, Bill Nottingham wrote:
> Greg KH ([EMAIL PROTECTED]) said: 
> > I'd like to announce, yet-another-hotplug based userspace project:
> > linux-ng.  This collection of code replaces the existing linux-hotplug
> > package with very tiny, compiled executable programs, instead of the
> > existing bash scripts.
> > 
> > It currently provides the following:
> > - a /sbin/hotplug multiplexer.  Works identical to the existing
> >   bash /sbin/hotplug.
> 
> How does this interact with current usage of udevsend as the hotplug
> multiplexer?

First off, not everyone wants to use udev (I know, horrible thought...)
This provides those people a solution to a "I want a tiny /sbin/hotplug"
problem.

Also, udevstart working as /sbin/hotplug is great for keeping things in
order, which is important during normal operation.  But during the boot
sequence, the odds of getting out-of-order events, or even remove
events, is somewhat limited.  So, this /sbin/hotplug replacement can
work in an initrd/initramfs image when udevstart would be overkill.

And finally, even if you do use udevstart to manager /sbin/hotplug
events, you still need a module autoloader program.  This package
provides executables for that problem, if you don't want to (or you
can't) use the existing linux-hotplug scripts.  udev will never do the
module loading logic, so there's no duplication in this case.

Hope this helps.  I do realize the whole hotplug process is getting a
bit complicated.  I hope to write up some good documentation on what all
is involved to help clear up some of the confusion that the combination
of udev, udevsend, udevd, hal, /etc/hotplug.d/, /etc/dev.d/,
and /sbin/hotplug have caused lately.

thanks,

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

Re: 2.6.11-rc3-mm2

[Nick Piggin]

On Fri, 2005-02-11 at 17:34 +1100, Peter Williams wrote:
> Nick Piggin wrote:

> > I can't say much about it because I'm not putting my hand up to
> > do anything. Just mentioning that rlimit would be better if not
> > for the userspace side of the equation. I think most were already
> > agreed on that point anyway though.
> 
> I think that the rlimits are a good idea in themselves but not as a 
> solution to this problem.  I.e. having a RT CPU rate rlimit should not 
> be a sufficient (or necessary for that matter) condition to change 
> policy to SCHED_OTHER or SCHED_RR but could still be used to limit the 
> possibility of lock out.

Ah well that may be a good way to do it indeed. As I said, I
don't know much about privileges etc.

But I just want to be clear that I'm not trying to stop RT-LSM
going in (if only because I don't care one way or the other
about it).

>   (But I guess even that is a violation of RT 
> semantics?)
> 

I'd have to re-read the standard, but it may not be. For example,
a compliant system advertises the minimum and maximum priority
levels available - you may be able to adjust these based on what
the rlimit is set to. On the other hand, yes it may violate the
stanards.

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/

Re: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote:
> hey greg
> 
> i remember for some months back, you posted something similar.. is this
> a version thats ready for use? if it is! im gonna use it! :D

Yes, this is that version, cleaned up and given a proper build system,
and even tested on my machines here :)

thanks,

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

Re: 2.6.11-rc3-mm2

[Peter Williams]

Nick Piggin wrote:
On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
 [ the best solution is  ]
 [ my preferred solution is ... ]
 [ it would be better if ... ]
 [ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.

Sure, it is quick and easy. Suits some. At least I do prefer
this to altering the semantics of realtime scheduling.
I can't say much about it because I'm not putting my hand up to
do anything. Just mentioning that rlimit would be better if not
for the userspace side of the equation. I think most were already
agreed on that point anyway though.
I think that the rlimits are a good idea in themselves but not as a 
solution to this problem.  I.e. having a RT CPU rate rlimit should not 
be a sufficient (or necessary for that matter) condition to change 
policy to SCHED_OTHER or SCHED_RR but could still be used to limit the 
possibility of lock out.  (But I guess even that is a violation of RT 
semantics?)

Peter
PS Zaphod's per task hard/soft CPU rate caps (which are the equivalent 
of an rlimit on CPU usage rate) are only enforced for SCHED_NORMAL tasks 
and should not (therefore) effect RT semantics.
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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: How to disable slow agpgart in kernel config?

[Dave Jones]

On Fri, Feb 11, 2005 at 07:07:22AM +0100, Marcus Hartig wrote:

 > the agpgart backend is now always compiled in and selected with 2.6.11-rc3 
 > x86_64. I can delete or disable it in the config, it is always back written.

probably you have selected IOMMU, which is dependant on it.

 > Is this the default future behaviour?

This is how it's always been.

 > The eg Nforce3 AGP is on a normal desktop so slow on 2D and also in 3D mode
 > a lot slower and all nvidia kernel driver users can not more use the really
 > faster nv_agp.

This surprises me, especially considering the in-kernel nvidia-agp driver
was actually written by NVidia. Are there any agp error messages in
your dmesg / X log ?

How big a speed difference do you notice with the two gart drivers?

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-rc3-mm2 (compile stats)

[John Cherry]

Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1)

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/

KernelbzImage   bzImage  bzImage  modules  bzImage  modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--- --     
2.6.11-rc3-mm2   14w/0e 0w/0e   192w/0e6w/0e  19w/0e172w/0e
2.6.11-rc3-mm1   13w/10e0w/7e   196w/12e   6w/0e  18w/12e   177w/0e
2.6.11-rc2-mm2   15w/0e 0w/0e   201w/0e6w/0e  18w/0e182w/0e
2.6.11-rc2-mm1   15w/0e 0w/0e   306w/14e   6w/0e  18w/0e294w/0e
2.6.11-rc1-mm2   21w/0e 0w/0e   316w/9e6w/0e  22w/0e294w/0e
2.6.11-rc1-mm1   21w/0e 0w/0e   319w/0e6w/0e  23w/0e298w/0e
2.6.10-mm3   21w/0e 0w/0e   320w/0e6w/0e  23w/0e299w/0e
2.6.10-mm2   21w/0e 0w/0e   440w/0e6w/0e  23w/0e420w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-rc1-mm1   16w/1e 1w/1e   592w/1e4w/0e  13w/1e857w/0e
2.6.9-mm1 6w/1e 1w/1e  1761w/15e  65w/0e   9w/0e   2086w/0e
2.6.9-rc4-mm1 5w/0e 0w/0e  1766w/11e  43w/0e   6w/0e   1798w/0e
2.6.9-rc3-mm3 5w/0e 0w/0e  1756w/11e  43w/0e   4w/0e   1786w/0e
2.6.9-rc3-mm210w/0e 4w/9e  1754w/14e  43w/0e   4w/0e   1782w/1e
2.6.9-rc3-mm110w/0e 4w/10e 1768w/0e   43w/0e   4w/0e   1796w/0e
2.6.9-rc2-mm410w/0e 5w/0e  2573w/0e   41w/0e   4w/0e   2600w/0e
2.6.9-rc2-mm310w/0e 5w/0e  2400w/0e   41w/0e   4w/0e   2435w/0e
2.6.9-rc2-mm210w/0e 5w/0e  2919w/0e   41w/0e   4w/0e   2954w/0e
2.6.9-rc2-mm1 0w/0e 2w/0e  3541w/9e   41w/0e   3w/9e   3567w/0e
2.6.9-rc1-mm4 0w/0e 1w/0e55w/0e3w/0e   2w/0e 48w/0e
2.6.9-rc1-mm3 0w/0e 0w/0e55w/13e   3w/0e   1w/0e 49w/1e
2.6.9-rc1-mm2 0w/0e 0w/0e53w/11e   3w/0e   1w/0e 47w/0e
2.6.9-rc1-mm1 0w/0e 0w/0e80w/0e4w/0e   1w/0e 74w/0e
2.6.8.1-mm4   0w/0e 0w/0e78w/0e4w/0e   1w/0e 73w/0e
2.6.8.1-mm3   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm2   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm1   0w/0e 0w/0e78w/0e4w/0e   1w/0e 74w/0e
2.6.8-rc4-mm1 0w/0e 0w/5e81w/0e4w/0e   1w/0e 75w/0e
2.6.8-rc3-mm2 1w/7e 0w/5e82w/8e4w/0e   2w/8e 75w/0e
2.6.8-rc3-mm1 0w/0e 1w/5e81w/9e4w/0e   1w/0e 75w/0e
2.6.8-rc2-mm2 0w/0e 4w/5e87w/9e4w/0e   1w/0e 80w/0e
2.6.8-rc2-mm1 0w/0e 0w/0e83w/9e3w/0e   1w/0e 81w/0e
2.6.8-rc1-mm1 0w/0e 0w/0e88w/9e5w/0e   1w/0e 87w/0e
2.6.7-mm7 0w/0e 0w/0e89w/9e5w/0e   1w/0e 84w/0e
2.6.7-mm6 0w/0e 0w/0e85w/9e5w/0e   1w/0e 80w/0e
2.6.7-mm5 0w/0e 0w/0e92w/0e5w/0e   1w/0e 87w/0e
2.6.7-mm4 0w/0e 0w/0e94w/0e5w/0e   1w/0e 89w/0e
2.6.7-mm3 0w/0e 0w/0e90w/6e5w/0e   1w/0e 86w/0e
2.6.7-mm2 0w/0e 0w/0e   109w/0e7w/0e   1w/0e106w/0e
2.6.7-mm1 0w/0e 5w/0e   108w/0e5w/0e   1w/0e104w/0e
2.6.7-rc3-mm2 0w/0e 5w/0e   105w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc3-mm1 0w/0e 5w/0e   104w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc2-mm2 0w/0e 5w/0e   109w/10e   5w/0e   2w/0e105w/2e
2.6.7-rc2-mm1 0w/0e12w/0e   158w/13e   5w/0e   3w/0e153w/4e
2.6.7-rc1-mm1 0w/0e 6w/0e   108w/0e

How to disable slow agpgart in kernel config?

[Marcus Hartig]

Hello,
the agpgart backend is now always compiled in and selected with 2.6.11-rc3 
x86_64. I can delete or disable it in the config, it is always back written.

Is this the default future behaviour? The eg Nforce3 AGP is on a normal 
desktop so slow on 2D and also in 3D mode a lot slower and all nvidia 
kernel driver users can not more use the really faster nv_agp.

Greetings,
Marcus
-
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.11-rc3-V0.7.38-01

[George Anzinger]

Sven Dietrich wrote:
Hi George,
you may want to use this for reference.
This patch adds a config option to allow you to select whether timer IRQ runs 
in thread or not.
I'm not totally happy with the #ifdefs, but it may make witching back and forth easier.
Thanks, but...
You are addressing a different problem than I.  I want to code the VST patch to 
work in a system with or without the RT patch (it is easy to work with the RT 
option on or off).  The problem is setting up the spin locks it needs.  My 
solution assumes that RAW_SPIN_LOCK_UNLOCKED will not be defined unless the RT 
patch is applied.

As to your patch, in most archs the timer interrupt does accounting which 
requires input on just who was interrupted on the interrupt.  This is lost when 
threading the timer IRQ.  I think it was problems of this sort that caused Ingo 
to back away...

George
PS
By the way, your mailer (Microsoft Outlook) set up your attachment in such a 
way that my mailer would not inline it.  You might want to look into this.
Sven

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
George Anzinger
Sent: Thursday, February 10, 2005 12:21 PM
To: Ingo Molnar
Cc: William Weston; linux-kernel@vger.kernel.org
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

If I want to write a patch that will work with or without the 
RT patch applied 
is the following enough?

#ifndef RAW_SPIN_LOCK_UNLOCKED
typedef raw_spinlock_t spinlock_t
#define RAW_SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED
#endif
--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
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/

--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
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-rc3-mm2

[Peter Williams]

Paul Davis wrote:
  [ the best solution is  ]
  [ my preferred solution is ... ]
  [ it would be better if ... ]
  [ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.
As I see it, what I said was in support of RT LSM (or at least the 
approach that RT LSM is taking) so why are you attacking me.  I'm on 
your side :-)

Peter
PS I'm withdrawing the "unprivileged real time" feature from the 
spa_no_frills and zaphod schedulers in the PlugSched patch as a result 
of the discussions on SCHED_ISO and RT rlimits because the discussion 
convinced me that it's the wrong way to go.
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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-rc3-mm2

[Nick Piggin]

On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
>   [ the best solution is  ]
> 
>   [ my preferred solution is ... ]
> 
>   [ it would be better if ... ]
> 
>   [ this is a kludge and it should be done instead like ... ]
> 
> did nobody read what andrew wrote and what JOQ pointed out?
> 
> after weeks of debating this, no other conceptual solution emerged
> that did not have at least as many problems as the RT LSM module, and
> all other proposed solutions were also more invasive of other aspects
> of kernel design and operations than RT LSM is.
> 

Sure, it is quick and easy. Suits some. At least I do prefer
this to altering the semantics of realtime scheduling.

I can't say much about it because I'm not putting my hand up to
do anything. Just mentioning that rlimit would be better if not
for the userspace side of the equation. I think most were already
agreed on that point anyway though.

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/

Re: [PATCH] arp_queue: serializing unlink + kfree_skb

[Dmitry Torokhov]

On Thursday 10 February 2005 22:50, David S. Miller wrote:
> > > Unlike the above routines, it is required that explicit memory
> > > barriers are performed before and after the operation.  It must
> > > be done such that all memory operations before and after the
> > > atomic operation calls are strongly ordered with respect to the
> > > atomic operation itself.
> > 
> > Hmm, given that this description will not only be read by implementers
> > of atomic functions, but also by users, the "explicit memory barriers"
> > may be confusing.
> 
> Absolutely, I agree.  My fingers even itched as I typed those lines
> in.  I didn't change the wording because I couldn't come up with
> anything better.

What about the following:

Unlike the routines above, these functions should always perform memory
barriers before and after the operation in question so that all memory
accesses before and after the atomic operation are strongly ordered with
respect to the atomic operation itself.

-- 
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: [PATCH] arp_queue: serializing unlink + kfree_skb

[Werner Almesberger]

David S. Miller wrote:
> Absolutely, I agree.  My fingers even itched as I typed those lines
> in.  I didn't change the wording because I couldn't come up with
> anything better.

How about something like:

  Unlike the above routines, atomic_???_return are required to perform
  memory barriers [...]

I think "implicit" and "explicit" here are just confusing, because
you don't define them, and there's no intuitively correct meaning
either.

Perhaps a little warning could also be useful for the reader who
wasn't paying close attention to whose role is described:

  Note: this means that a caller of atomic_add, etc., who needs a
  memory barrier before or after that call has to code the memory
  barrier explicitly, whereas a caller of atomic_???_return can rely
  on said functions to provide the barrier without further ado. For
  the implementor of the atomic functions, the roles are reversed.

> You still get the memory barrier, whether you read the return
> value or not.

That might be something worth mentioning. Not that a construct
is used that gcc can optimize away when nobody cares about the
return value.

- Werner

-- 
  _
 / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.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: [PATCH] arp_queue: serializing unlink + kfree_skb

[David S. Miller]

On Thu, 10 Feb 2005 01:23:04 -0300
Werner Almesberger <[EMAIL PROTECTED]> wrote:

> David S. Miller wrote:
> > Unlike the above routines, it is required that explicit memory
> > barriers are performed before and after the operation.  It must
> > be done such that all memory operations before and after the
> > atomic operation calls are strongly ordered with respect to the
> > atomic operation itself.
> 
> Hmm, given that this description will not only be read by implementers
> of atomic functions, but also by users, the "explicit memory barriers"
> may be confusing.

Absolutely, I agree.  My fingers even itched as I typed those lines
in.  I didn't change the wording because I couldn't come up with
anything better.

> In fact, I would call them "implicit", because they're hidden in the
> atomic_foo functions :-)

That's confusing to the implementer :-)

> s/smb_/smp/ :-)

Good catch, fixed in my local copy.

> Do they also work for atomic_add and atomic_sub, or do we have to
> fall back to smb_mb or atomic_add_return (see below) there ?

Macros for the other routines don't exist simply because nobody
ever had a use for them.

In practice they will just work.

> What happens if the operation could return a value, but the user
> ignores it ? E.g. if I don't like smp_mb__*, could I just use
> 
>   atomic_inc_and_test(foo);

You still get the memory barrier, whether you read the return
value or not.

> > These routines, like the atomic_t counter operations returning
> > values, require explicit memory barrier semantics around their
> > execution.
> 
> Very confusing: the barriers aren't around the routines (that
> is something the user would be doing), but around whatever does
> the atomic stuff inside them.

Yeah, it's the whole implicit/explicit wording issue discussed
above.
-
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] arp_queue: serializing unlink + kfree_skb

[David S. Miller]

On Thu, 10 Feb 2005 15:56:47 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:

> > ? If yes, is this a good idea ?
> 
> Dave mentioned that on sparc64, atomic_inc_and_test is much more
> expensive than the second variant.

Actually, besides the memory barriers themselves, all variants
are equally expensive.

On old i386 chips, the test variants are indeed more expensive.
Linus told me this and there is a note about this in the
atomic_ops.txt file if you look at the current copy :-)

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

[Paul Davis]

  [ the best solution is  ]

  [ my preferred solution is ... ]

  [ it would be better if ... ]

  [ this is a kludge and it should be done instead like ... ]

did nobody read what andrew wrote and what JOQ pointed out?

after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.

--p

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

[Bill Brandel]

Hi,

I'm running Linux 2.6.10 from Fedora Core 2  and I have enabled
rejected packet logging so
log-watch is able to alert me on possible attacks.   This however goes
in "dmesg" making it unusable to check for serious condition.  Is
there any way to only redirect such messages to the file
without having them in Dmesg ? 

Thanks.

-- 
Bill Brandel, http://www.generalcatalog.info - Start your Internet Search 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.11-rc3-mm2

[Peter Williams]

Nick Piggin wrote:
On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
* Matt Mackall ([EMAIL PROTECTED]) wrote:
What happened to the RT rlimit code from Chris?
I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
patch is wholly self-contained.
I think it's important to recognize that we're trying to address an
issue that has a much wider potential audience than pro audio users,
and not very far off - what is high end audio performance today will be
expected desktop performance next year.
So I think it's critical that we find solution that's appropriate for
_every single box_, because realistically vendors are going to ship
with this "wholly self-contained" feature turned on by default next
year, at which point the "containment" will be nil and whatever warts
it has will be with us forever.
The rlimit stuff is not perfect, but it's a much better fit for the
UNIX model generally, which is a fairly big win. Having it in the
system unconditionally doesn't trigger the gag reflex in quite the
same way as the LSM approach.

Without considering the userspace aspect, RT rlimits is the best
implementation I have seen. All others either break RT scheduling
semantics, or don't allow any way for root to maintain control of
the system after giving out RT privileges.
Personally, I think that the best approach to solving this problem is 
from the privileges aspect.  The ability to grant privileges to only set 
RT policy is just an example of a general need for granting limited 
privileges to a program and/or a user.  So a solution that involved a 
mechanism for granting a specified subset of root privileges to 
specified users when running specified programs would have wider 
application.

My limited understanding of SELinux (which may be mistaken) is that it 
provides a basic framework for this level of privilege control and 
perhaps the solution lies there.

Peter
--
Peter Williams   [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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: Reading Bad DVD Under 2.6.10 freezes the box.

[Jan Knutar]

On Monday 07 February 2005 16:46, linux-os wrote:

> Basically, when you start getting the kernel error messages on
> linux-2.4.22, you can ^C out and everything will quiet down.

Not in my experience.

> With Linux-2.6.10, nothing entered from the keyboard will
> do anything. Since the Caps-Lock key still functions, interrupts
> are still active. However, it is likely the kernel-lock that
> prevents signals (like ^C or ^/) from being executed.

Speculations aside, I have found only one sure way of breaking
the eternal kernel-hang if you make the mistake of inserting a bad
CD into your drive; Needlehole eject.

Sure, the kernel will spit loads of error messages at you, but atleast
it wont be hung anymore, you can save work and reboot.

For eternal hangs when burning CDs though, I've found the only
reliable way of unhanging the system is to unplug power to the 
CD burner and replug it. This seems to cause some amount of
disk corruption to the master device on the same IDE channel
though, so I guess if you have two harddrives, like me, it is a
hard choice between risking corruption on both, and risking
corruption on one.

HTH
-
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: [ANNOUNCE] hotplug-ng 001 release

[Bill Nottingham]

Greg KH ([EMAIL PROTECTED]) said: 
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.  This collection of code replaces the existing linux-hotplug
> package with very tiny, compiled executable programs, instead of the
> existing bash scripts.
> 
> It currently provides the following:
>   - a /sbin/hotplug multiplexer.  Works identical to the existing
> bash /sbin/hotplug.

How does this interact with current usage of udevsend as the hotplug
multiplexer?

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: EDD failures since edd=off patch

[Carl-Daniel Hailfinger]

Matt Domsch schrieb:
> On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
> 
>>Hi Matt,
>>
>>it seems the edd=off patch has caused some problems with
>>some machines I have access to. They simply don't boot
>>anymore unless I specify edd=foo. foo can be {off,skip,bar}
>>so it seems the hang on boot is related to the parser
>>not finding the parameter it is looking for.
>>I looked through the code some days ago and it seemed to
>>me that the register used to iterate through the command
>>line buffer only got its lower 16 bit reset before calling
>>into the BIOS. I don't have the code handy right now,
>>but I can look later if the hints I gave are insufficient.
> 
> 
> Yes, please.  I'm reading the code, and %ecx gets set to
> (COMMAND_LINE_SIZE-7) which is 256-7=249.  So the upper 24 bits of
> %ecx are going to always be zero, and if "edd=" isn't seen, then %ecx
> will be zero when dropping into edd_mbr_sig_start.  The only other
> register touched is %esi, but it's pushed at the beginning, and pop'd
> on all exit cases, so that should be unchanged.
> 
> ZF is the only other bit I can picture.  On the "no edd= option" path,
> ZF=0 on exit.  With "edd=of" or "edd=sk", ZF=1.  But with "edd=bar",
> ZF=0, which you say works too.  So that's not it...
> 
> CF is taken care of around the int13 calls already, so that's not
> it...

It all boils down to the question: When do the flags set by INCL
differ from those set by CMPW? We have already ruled out CF and ZF,
so only OF, SF, AF, PF can be the culprit.

Looking again, I think it will hang with edd=zz, but I have to verify
that.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.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: [ckrm-tech] Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Chandra Seetharaman]

On Wed, Feb 09, 2005 at 09:59:28AM -0800, Chandra Seetharaman wrote:
> On Tue, Feb 08, 2005 at 12:42:34PM -0800, Paul Jackson wrote:
--stuff deleted---
> memset_controller would be similar to this, before pitching it I will talk
> with Matt about why he thought that there is a problem.

Talked to Matt Dobson and explained him the CKRM architecture and how
cpuset/memset can be implemented as a ckrm controller. He is now convinced
that there is no problem in making memset also a ckrm controller.

As explained in the earlier mail, memset also can be implemented in the
same way as cpuset.

> 
> If I missed some feature of cpuset that shows a bigger problem, please
> let me know.
> > 
> > In sum -- I see a potential for useful integration of cpusets and
> > scheduler domains, I'll have to leave it up to those with expertise in
> > the scheduler to evaluate and perhaps accomplish this.  I do not see any
> > useful integration of cpusets and CKRM.
> > 
> > I continue to be befuddled as to why, Matthew, you confound potential
> > cpuset-scheddomain integration with potential cpuset-CKRM integration.
> > Scheduler domains and CKRM are distinct beasts, in my book, and the
> > contemplations of cpuset integration with these two beasts are also
> > distinct efforts.
> > 
> > And cpusets and CKRM are distinct beasts.
> > 
> > But I repeat myself ...
> > 
> > -- 
> >   I won't rest till it's the best ...
> >   Programmer, Linux Scalability
> >   Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
> > 1.925.600.0401
> > 
> > 
> > ---
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595_id=14396=click
> > ___
> > ckrm-tech mailing list
> > https://lists.sourceforge.net/lists/listinfo/ckrm-tech
> 
> -- 
> 
> --
> Chandra Seetharaman   | Be careful what you choose
>   - [EMAIL PROTECTED]   |  ...you may get it.
> --
> 
> 
> ---
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595_id=14396=click
> ___
> ckrm-tech mailing list
> https://lists.sourceforge.net/lists/listinfo/ckrm-tech

-- 

--
Chandra Seetharaman   | Be careful what you choose
  - [EMAIL PROTECTED]   |  ...you may get it.
--
-
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-rc3-mm2

[Nick Piggin]

On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
> On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
> > * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > > What happened to the RT rlimit code from Chris?
> > 
> > I still have it, but I had the impression Ingo didn't like it as a long
> > term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
> > patch is wholly self-contained.
> 
> I think it's important to recognize that we're trying to address an
> issue that has a much wider potential audience than pro audio users,
> and not very far off - what is high end audio performance today will be
> expected desktop performance next year.
> 
> So I think it's critical that we find solution that's appropriate for
> _every single box_, because realistically vendors are going to ship
> with this "wholly self-contained" feature turned on by default next
> year, at which point the "containment" will be nil and whatever warts
> it has will be with us forever.
> 
> The rlimit stuff is not perfect, but it's a much better fit for the
> UNIX model generally, which is a fairly big win. Having it in the
> system unconditionally doesn't trigger the gag reflex in quite the
> same way as the LSM approach.
> 

Without considering the userspace aspect, RT rlimits is the best
implementation I have seen. All others either break RT scheduling
semantics, or don't allow any way for root to maintain control of
the system after giving out RT privileges.


http://mobile.yahoo.com.au - Yahoo! Mobile

- Check & compose your email via SMS on your Telstra or Vodafone mobile.

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

[Matt Mackall]

On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
> * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > What happened to the RT rlimit code from Chris?
> 
> I still have it, but I had the impression Ingo didn't like it as a long
> term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
> patch is wholly self-contained.

I think it's important to recognize that we're trying to address an
issue that has a much wider potential audience than pro audio users,
and not very far off - what is high end audio performance today will be
expected desktop performance next year.

So I think it's critical that we find solution that's appropriate for
_every single box_, because realistically vendors are going to ship
with this "wholly self-contained" feature turned on by default next
year, at which point the "containment" will be nil and whatever warts
it has will be with us forever.

The rlimit stuff is not perfect, but it's a much better fit for the
UNIX model generally, which is a fairly big win. Having it in the
system unconditionally doesn't trigger the gag reflex in quite the
same way as the LSM approach.

-- 
Mathematics is the supreme nostalgia of our time.
-
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.4.x kernel BUG at filemap.c:81

[Marcelo Tosatti]

On Wed, Feb 09, 2005 at 11:23:42PM -0500, Todd Shetter wrote:
> Marcelo Tosatti wrote:
> 
> >On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote:
> > 
> >>Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28, 
> >>2.4.29 with highmem 4GB, and highmem i/o support enabled, I get a 
> >>system lockup. This happens in both X and console. Happens with and 
> >>without my Nvidia drivers loaded. I cannot determine what makes this 
> >>bug present it self besides highmem and high i/o support enabled. Im 
> >>guessing the system is fine until highmem is actually used to some 
> >>point and then it borks, but I really have no idea and so im just 
> >>making a random guess. I ran memtest86 for a few hours a while ago 
> >>thinking that it may be bad memory, but that did not seem to be the 
> >>problem.
> >>
> >>If you need anymore information, or have questions, or wish me to 
> >>test anything, PLEASE feel free to contact me, I would really like to 
> >>see this bug resolved. =)
> >>
> >>Todd Shetter
> >>
> >>Feb  8 19:49:31 quark kernel: kernel BUG at filemap.c:81!
> >>Feb  8 19:49:31 quark kernel: invalid operand: 
> >>Feb  8 19:49:31 quark kernel: CPU:0
> >>Feb  8 19:49:31 quark kernel: EIP:0010:[]Tainted: P
> >>   
> >Hi Todd, 
> >
> >Why is your kernel tainted ?
> >
> I had the nvidia 1.0-6629 driver loaded when I got that error. I 
> compiled the kernel using the slackware 10.1 config, enabled highmem 
> 4GB support, highmem i/o, and then some kernel hacking options 
> including debugging for highmen related things.
> 
> I booted, loaded X with KDE, opened firefox a few times, and then 
> started running hdparm because some newer 2.4.x kernels dont play nice 
> with my SATA, ICH5, and DMA. hdparm segfaulted while running the drive 
> read access portion of its tests, and things locked up from there in 
> about 30secs.
> 
> I've gotten the same error with the nvidia driver not loaded, so I dont 
> think that is part of the problem.
> 
> As I said, if you want me to test or try anything feel free to ask.  =)
> 
> >>>Todd,
> >>>
> >>>Would be interesting to have the oops output without the kernel nvidia 
> >>>module. 
> >>>Do you have that saved?
> >>>
> >>Sorry, it took me FOREVER to get this bug to appear again, and this time 
> >>its a little different.
> >>   
> >>
> >
> >Hum, both BUGs are due to a page with alive ->buffers mapping.
> >
> >Did it crashed right after hdparm now too? 
> >
> >Can you boot your box without SATA drivers, configuring the interface to 
> >IDE mode ?
> >
> >Which problems are you facing with newer v2.4.x kernels and SATA? 
> > 
> >
> 
> Im waiting for the system to crash, so I figured I might as well get on 
> with the SATA problems
> 
> Running 2.4.29 neither the CONFIG_BLK_DEV_IDE_SATA nor the 
> CONFIG_SCSI_SATA are set currently and DMA is not enabled on either of 
> my drives,  hda: ST380013AS,  hdb: WDC WD2500SD-01KCB0,  hdc: Maxtor 
> 94610U6. Setting DMA manually on the hard drives yields a HDIO_SET_DMA 
> failed: Operation not permitted error.
>
> Using 2.4.26, DMA worked fine on the drives. Under 2.4.27, 2.4.28, and 
> 2.4.29 using CONFIG_SCSI_SATA does not allow setting of DMA on the 
> drives, yielding a HDIO_SET_DMA failed: Operation not permitted error, 
> and the transfer speeds reported by hdparm are at about 3MB/s.

I think thats expected. Jeff?

> Under 2.4.29 using CONFIG_BLK_DEV_IDE_SATA the DMA is set fine upon 
> boot, and I get good transfers, hdparm reports 58MB/s on my Western 
> Digital drive. I have not tested using CONFIG_BLK_DEV_IDE_SATA on any 
> previous kernel versions.
> 
> Well, still no crash yetAgain, anything else you want me to try or 
> do just let me know.

Lets wait - this nature of bug can be triggered by flaky hardware. 

If you can't get it to crash without SATA, re-enable it, and get another
couple of oopses 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: [ACPI] Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Li-Ta Lo schrieb:
> On Mon, 2005-02-07 at 09:01, Pavel Machek wrote:
> 
3 - it's always there and can be executed at *any* time: booting,
returning from suspend, etc. Also it would allow the VESA framebuffer
driver to change graphics mode at any time (for instance).
>>>
>>>OK, and what would force you to do the above in the kernel? If the code
>>>lives in initramfs, it can be called very early, too.
>>
>>It will be easier to debug in kernel than in initramfs, for
>>one. Kernel code is bad enough, but initramfs running while kernel is
>>not even initialized is going to be even more "fun".
> 
> One good thing about the emulator is it is very portable. There is
> virtually no stdlib dependency. We can freely move it between user
> and kernel space. When integrating the emulator into LinuxBIOS,
> we first tried to use it as an user space program and then "port" it
> into "kernel" space. The porting was done in a few days and the most
> of the time was spent fixing LinuxBIOS itself than doing any "porting".
> Actually, the same emulator source were used in both user and kernel
> space as a kind of regression test.

Do you have a kernel patch against a recent kernel? I'd like to try
the in-kernel emulator. A userspace variant would also be fine, provided
it solves the "VGA BIOS calls normal BIOS" type of problem I'm seeing
on my machine (Samsung P35 laptop with ATI Radeon Mobility 9700).


Regards,
Carl-Daniel
-- 
http://www.hailfinger.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: [ACPI] Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Jon Smirl schrieb:
> On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> 
>>On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
>>
>>
>>>So perhaps this problem is something similar?
> 
> 
> What type of computer has the problem? Who makes it's video chips?

Samsung P35 notebook with ATI Mobility Radeon 9700.
IIRC I saw the c000: jump on my machine.

Give me code to test and I'll mail you the results in a few minutes.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.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: [ANNOUNCE] hotplug-ng 001 release

[Kasper Sandberg]

hey greg

i remember for some months back, you posted something similar.. is this
a version thats ready for use? if it is! im gonna use it! :D

On Thu, 2005-02-10 at 16:52 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> > I'd like to announce, yet-another-hotplug based userspace project:
> > linux-ng.
> 
> Bah.  The name is hotplug-ng.  Sorry about that...
> 
> greg k-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/
> 

-
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Thu, Feb 10, 2005 at 08:07:23PM -0500, Patrick McFarland wrote:
> 
> Please, continue this project and encourage distros to switch to it (when 
> it exceeds hotplug in functionality and stability). Ubuntu currently is 
> trying to reduce boot time, and I bet something like this would factor in 
> (even a few seconds helps).

Thanks for the kind words.

All distros are trying to reduce boot time.  I don't think that the
module autoload time has been fingered as taking any serious ammount of
boot time due to it happening in the background of everything else.  But
yes, this should help it out (as long as we aren't trading I/O time for
CPU time, like it can happen if you don't have a populated modules.alias
file...)

And yes, I've been in contact with the Ubuntu developer already about
using this code, instead of dietHotplug.

thanks,

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

Re: DVB at76c651.c driver seems to be dead code

[Mws]

On Friday 11 February 2005 00:56, Adrian Bunk wrote:
> I didn't find any way how the drivers/media/dvb/frontends/at76c651.c 
> driver would do anything inside kernel 2.6.11-rc3-mm2. All it does is to 
> EXPORT_SYMBOL a function at76c651_attach that isn't used anywhere.
> 
> Is a patch to remove this driver OK or did I miss anything?
> 
> cu
> Adrian
> 
FYI

The atmel at76c651 frontend driver is used for the 
Sagem DBox2 Digital Cable Receiver. 

As all other parts of the dbox2 drivers are atm not hosted at kernel cvs but at
cvs.tuxbox.org you won't find any components in mainline kernel tree using this.

thus we are a hobby project - but even well known - there are not so many 
developer
available to make every kernel driver and other parts of it 
"kernel-style-alike". 
maybe there is more progress and kernel driver patching into mainline in the 
future.
we are having 2.6.9 running on dbox2 - higher versions are atm broken for 
support of
the mpc 823 architecture :/

removing this driver is not wanted.

regards
Marcel Siegert
[EMAIL PROTECTED]





pgpkLhF3AFyg8.pgp
Description: PGP signature

Re: [ANNOUNCE] hotplug-ng 001 release

[Patrick McFarland]

Greg KH wrote:
I'd like to announce, yet-another-hotplug based userspace project:
linux-ng.  This collection of code replaces the existing linux-hotplug
package with very tiny, compiled executable programs, instead of the
existing bash scripts.
It currently provides the following:
- a /sbin/hotplug multiplexer.  Works identical to the existing
  bash /sbin/hotplug.
- autoload programs for usb, scsi, and pci modules.  These
  programs determine what module needs to be loaded when the
  kernel emits a hotplug event for these types of devices.  This
  works just like the existing linux-hotplug scripts, with a few
  exceptions.
But why redo this all in .c code?  What's wrong with shell scripts?
Nothing is wrong with shell scripts, unless you don't want to have an
interpreter in your initramfs/initrd and you want to provide
/sbin/hotplug and autoload module functionality.  Or if you have a huge
box that spawns a zillion hotplug events all at once, and you need to be
able to handle all of that with the minimum amount of processing time
and memory.
Wow, thats pretty awesome. Just the other day I said, "Why is hotplug written 
in sh? Isn't that horribly inefficient way of handling something that needs to 
be done quickly using the least amount of resources possible?" It seems you 
were reading my mind.

Please, continue this project and encourage distros to switch to it (when it 
exceeds hotplug in functionality and stability). Ubuntu currently is trying to 
reduce boot time, and I bet something like this would factor in (even a few 
seconds helps).

--
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
-
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.

Bah.  The name is hotplug-ng.  Sorry about that...

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

Re: 2.6.11-rc3-mm2

[Chris Wright]

* Matt Mackall ([EMAIL PROTECTED]) wrote:
> What happened to the RT rlimit code from Chris?

I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
patch is wholly self-contained.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.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/

[ANNOUNCE] hotplug-ng 001 release

[Greg KH]

I'd like to announce, yet-another-hotplug based userspace project:
linux-ng.  This collection of code replaces the existing linux-hotplug
package with very tiny, compiled executable programs, instead of the
existing bash scripts.

It currently provides the following:
- a /sbin/hotplug multiplexer.  Works identical to the existing
  bash /sbin/hotplug.
- autoload programs for usb, scsi, and pci modules.  These
  programs determine what module needs to be loaded when the
  kernel emits a hotplug event for these types of devices.  This
  works just like the existing linux-hotplug scripts, with a few
  exceptions.

But why redo this all in .c code?  What's wrong with shell scripts?
Nothing is wrong with shell scripts, unless you don't want to have an
interpreter in your initramfs/initrd and you want to provide
/sbin/hotplug and autoload module functionality.  Or if you have a huge
box that spawns a zillion hotplug events all at once, and you need to be
able to handle all of that with the minimum amount of processing time
and memory.

So, how small are these programs?  Take a look:
   textdata bss dec hex filename
   4669  32 124482512d9 hotplug
   5077   8 34854331539 module_pci
   4925   8 412534514e1 module_scsi
   5349   8 34857051649 module_usb

Those are all static binaries, linked with klibc (which is included in
the hotplug-ng package, just like udev.)

This compares to the following bash scripts:
-rwxr-xr-x  1 root root  4412 Feb 10 15:28 /sbin/hotplug
-rw-r--r--  1 root root   702 Sep 24 08:04 /etc/hotplug/blacklist
-rw-r--r--  1 root root  5293 Sep 24 08:04 /etc/hotplug/hotplug.functions
-rwxr-xr-x  1 root root  3739 Sep 24 08:04 /etc/hotplug/pci.agent
-rwxr-xr-x  1 root root  1459 Sep 24 08:04 /etc/hotplug/scsi.agent
-rwxr-xr-x  1 root root 13466 Sep 24 08:04 /etc/hotplug/usb.agent
-rw-r--r--  1 root root 39306 Sep 24 08:04 /etc/hotplug/usb.distmap
-rw-r--r--  1 root root  4364 Sep 24 08:04 /etc/hotplug/usb.handmap
-rw-r--r--  1 root root   189 Sep 24 08:04 /etc/hotplug/usb.usermap

All of which are loaded into memory for each hotplug event (for specific
hotplug events, only that bus type of file is loaded.)

But what about speed?  With a completely unscientific measurement on my
old, slow laptop, it takes about 2 seconds from the time I plug a usb
device into the machine, for the proper module to be loaded.  With the
hotplug-ng program, it takes less than a second.

And for those of you who might remember the old dietHotplug program that
also did the same thing in a tiny amount of space, this project
obsoletes that one.  dietHotplug had to be rebuilt for every kernel that
was used on the system, hotplug-ng uses the ability for modprobe to
determine the module that needs to be loaded based on the module
aliases[1].

The code can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-ng-001.tar.gz
for those who wish to poke around in it.

I still have a few more programs to write to get it up to the same
functionality as the existing hotplug scripts (firmware, ieee1392, etc.)
but those will be done soon.  I'd like to get people's comments on the
idea, and welcome suggestions and even patches :)

hotplug-ng development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/hotplug-ng

If anyone ever wants a tarball of the current bk tree, just email me.

thanks,

greg k-h

[1] modprobe as it currently works stops loading modules when it finds
an alias that matches.  This does not work for drivers that claim to
support "all devices" and then later on fail on devices that they really
don't support.  For that, all matching drivers need to be loaded for the
system to work properly.  The linux-hotplug scripts handle this
correctly, so if you rely on this functionality, please stick with that
package for now.  I'll be modifying modprobe to add this feature in the
near future.

-
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: [ANNOUNCE] "iswraid" (ICHxR ataraid sub-driver) for 2.4.29

[Marcelo Tosatti]

Hi Bart,

On Fri, Feb 11, 2005 at 12:28:04AM +0100, Bartlomiej Zolnierkiewicz wrote:

> > > [ This mail is just to explain why I don't like iswraid,
> > >   I don't care if it gets merged that much... ]
> > >
> > > another BTW: this driver adds another incompatibility between
> > > 2.4.x and 2.6.x.
> > 
> > What do you mean "adds another incompatibility" ?
> > 
> > That users will have to switch to dmraid when upgrading to v2.6.x ?
> 
> It is worse than that - AFAIR iswraid provides some features which
> are NOT available in 2.6.x kernels. 

Oh really?

> > > Also most 2.4.x users will want (or have to) migrate
> > > to 2.6.x one day and they will have to switch to using device mapper
> > > and dmraid anyway.  From my POV merging/supporting iswraid
> > > in any way is a lost of time for EVERYBODY in the long-term.
> > > Martins, I appreciate all hard work that went into iswraid driver but
> > > please face the simple fact, this driver was already obsoleted in
> > > the moment it was created (from Linux development process POV).
> > >
> > > I previously (October?) asked about merging device-mapper
> > > instead as it provides easier way to migrate to 2.6.x (not only for
> > > Intel "RAID component" users but for ALL "RAID components" users)
> > > as they would be able to use the same method for accessing their
> > > data in both kernels.  I was said that it is too late for such changes
> > > (I consider device-mapper a new driver, changes to existing code
> > > are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
> > > 2.6.x to device-mapper which was just silly argument IMHO (why we
> > > don't stick to IDE drivers for SATA in 2.4.x?).
> > 
> > SATA is not the same case as sw-RAID in my POV Bart, it allows many
> > users to be _able_ use SATA controllers/drives.
> 
> Fully agreed but what is your point?  Mine was that we can different
> subsystems/drivers for the same device/functionality - like we have
> both IDE+siimage and libata+sata_sil drivers in 2.4.x.

My point is that the SATA subsystem is a very different case from 
device-mapper.

The SATA subsystem provides _hardware_ knowledge, it provides the ability 
for certain very popular devices to work, and improved functionality
for devices which could be driven by the IDE subsystem.

Now the device mapper can be thought of as a high-level abstraction in which 
LVM, RAID, and other functionality can be built on top of. We already have 
those in v2.4. 

They are quite different.

> Maybe Martins was forced to develop for ataraid in 2.4.x
> because lack of device-mapper.  In such case the current
> situations is our fault and we can learn something from it.

True. 

> > > I finally gave up because I didn't want to waste more my time on this and
> > > didn't want to go into
> > > politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)
> > 
> > Good to hear your opinion.  


-
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 2.4.30: fix modem_run

[Pete Zaitcev]

I entered a patch which adds "exclusive_access" lock into 2.4.29, to fix
devices which cannot handle simultaneous accesses. This caused a regression
with European ADSL modems. An ioctl USBDEVFS_REAPURB allows a process to enter
the kernel and wait for USB I/O to finish. Naturally, this should not take
exclusive_access, or nothing will ever finish.

This patch is essentially the patch by Sergey Vlasov with my additions
a) to allow ENOTTY returned without taking a lock and b) to filter ENOIOCTLCMD,
which is improper to leak to userspace.

diff -urpN -X dontdiff linux-2.4.30-pre1/drivers/usb/devio.c 
linux-2.4.30-pre1-usb/drivers/usb/devio.c
--- linux-2.4.30-pre1/drivers/usb/devio.c   2004-11-22 23:04:18.0 
-0800
+++ linux-2.4.30-pre1-usb/drivers/usb/devio.c   2005-02-10 11:18:08.0 
-0800
@@ -1132,6 +1132,8 @@ static int proc_ioctl (struct dev_state 
/* ifno might usefully be passed ... */
retval = driver->ioctl (ps->dev, ctrl.ioctl_code, buf);
/* size = min_t(int, size, retval)? */
+   if (retval == -ENOIOCTLCMD)
+   retval = -ENOTTY;
}
}
 
@@ -1146,24 +1148,10 @@ static int proc_ioctl (struct dev_state 
return retval;
 }
 
-static int usbdev_ioctl(struct inode *inode, struct file *file, unsigned int 
cmd, unsigned long arg)
+static int usbdev_ioctl_exclusive(struct dev_state *ps, struct inode *inode,
+ unsigned int cmd, unsigned long arg)
 {
-   struct dev_state *ps = (struct dev_state *)file->private_data;
-   int ret = -ENOIOCTLCMD;
-
-   if (!(file->f_mode & FMODE_WRITE))
-   return -EPERM;
-   down_read(>devsem);
-   if (!ps->dev) {
-   up_read(>devsem);
-   return -ENODEV;
-   }
-
-   /*
-* grab device's exclusive_access mutex to prevent its driver from
-* using this device while it is being accessed by us.
-*/
-   down(>dev->exclusive_access);
+   int ret;
 
switch (cmd) {
case USBDEVFS_CONTROL:
@@ -1194,14 +1182,6 @@ static int usbdev_ioctl(struct inode *in
inode->i_mtime = CURRENT_TIME;
break;
 
-   case USBDEVFS_GETDRIVER:
-   ret = proc_getdriver(ps, (void *)arg);
-   break;
-
-   case USBDEVFS_CONNECTINFO:
-   ret = proc_connectinfo(ps, (void *)arg);
-   break;
-
case USBDEVFS_SETINTERFACE:
ret = proc_setintf(ps, (void *)arg);
break;
@@ -1220,6 +1200,53 @@ static int usbdev_ioctl(struct inode *in
ret = proc_unlinkurb(ps, (void *)arg);
break;
 
+   case USBDEVFS_CLAIMINTERFACE:
+   ret = proc_claiminterface(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_RELEASEINTERFACE:
+   ret = proc_releaseinterface(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_IOCTL:
+   ret = proc_ioctl(ps, (void *) arg);
+   break;
+
+   default:
+   ret = -ENOTTY;
+   }
+   return ret;
+}
+
+static int usbdev_ioctl(struct inode *inode, struct file *file,
+   unsigned int cmd, unsigned long arg)
+{
+   struct dev_state *ps = file->private_data;
+   int ret;
+
+   if (!(file->f_mode & FMODE_WRITE))
+   return -EPERM;
+   down_read(>devsem);
+   if (!ps->dev) {
+   up_read(>devsem);
+   return -ENODEV;
+   }
+
+   /*
+* Some ioctls don't touch the device and can be called without
+* grabbing its exclusive_access mutex; they are handled in this
+* switch.  Other ioctls which need exclusive_access are handled in
+* usbdev_ioctl_exclusive().
+*/
+   switch (cmd) {
+   case USBDEVFS_GETDRIVER:
+   ret = proc_getdriver(ps, (void *)arg);
+   break;
+
+   case USBDEVFS_CONNECTINFO:
+   ret = proc_connectinfo(ps, (void *)arg);
+   break;
+
case USBDEVFS_REAPURB:
ret = proc_reapurb(ps, (void *)arg);
break;
@@ -1232,19 +1259,28 @@ static int usbdev_ioctl(struct inode *in
ret = proc_disconnectsignal(ps, (void *)arg);
break;
 
+   case USBDEVFS_CONTROL:
+   case USBDEVFS_BULK:
+   case USBDEVFS_RESETEP:
+   case USBDEVFS_RESET:
+   case USBDEVFS_CLEAR_HALT:
+   case USBDEVFS_SETINTERFACE:
+   case USBDEVFS_SETCONFIGURATION:
+   case USBDEVFS_SUBMITURB:
+   case USBDEVFS_DISCARDURB:
case USBDEVFS_CLAIMINTERFACE:
-   ret = proc_claiminterface(ps, (void *)arg);
-   break;
-
case USBDEVFS_RELEASEINTERFACE:
-   ret = proc_releaseinterface(ps, (void *)arg);
-   break;
-
case USBDEVFS_IOCTL:
-  

RE: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[Sven Dietrich]

Hi George,

you may want to use this for reference.

This patch adds a config option to allow you to select whether timer IRQ runs 
in thread or not.

I'm not totally happy with the #ifdefs, but it may make witching back and forth 
easier.

Sven


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> George Anzinger
> Sent: Thursday, February 10, 2005 12:21 PM
> To: Ingo Molnar
> Cc: William Weston; linux-kernel@vger.kernel.org
> Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
> 
> 
> If I want to write a patch that will work with or without the 
> RT patch applied 
> is the following enough?
> 
> #ifndef RAW_SPIN_LOCK_UNLOCKED
> typedef raw_spinlock_t spinlock_t
> #define RAW_SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED
> #endif
> 
> 
> -- 
> George Anzinger   george@mvista.com
> High-res-timers:  http://sourceforge.net/projects/high-res-timers/
> 
> -
> 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/
> 


common_timer_irqthread.patch
Description: Binary data

Re: 2.6.11-rc3-mm2

[Matt Mackall]

On Thu, Feb 10, 2005 at 02:51:44PM -0600, Jack O'Quin wrote:
> [direct reply bounced, resending via gmail]
> 
> Andrew Morton <[EMAIL PROTECTED]> writes:
> 
> > Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > >
> > > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > > > 
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > > > 
> > > > 
> > > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio 
> > > > guys.
> > > >   It seems that nothing else is going to come along and this is 
> > > > completely
> > > >   encapsulated.
> > > 
> > > Even if we accept a module that grants capabilities to groups this
> > > isn't fine yet because it only supports two specific capabilities
> > > (and even those two in different ways!) instead of adding generic
> > > support to bind capabilities to groups.
> > 
> > I'm sure that got discussed somewhere in the 1000 emails which flew past
> > last time.  Jack?
> 
> [adding cc: for the main discussion participants]
> 
> Most people felt that a more general capabilities module would be nice
> to have.  But, no one offered any code, or volunteered to work on it.

What happened to the RT rlimit code from Chris?

-- 
Mathematics is the supreme nostalgia of our time.
-
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 2.4.30: hid for ia64

[Pete Zaitcev]

Apparently, the HP rx5670 fails to reboot if a USB keyboard if attached
without this patch (and the OHCI fix we accepted for 2.4.29).

This bug is better known for its effect on Altix, but SGI ships a magic
kernel anyhow, so I don't want to use that as justification.

The original patch comes from Jes Sorensen, but then I corrupted his
idea with my simplifications and a partial backport from 2.6, so if this
fails do not e-mail him.

diff -urpN -X dontdiff linux-2.4.30-pre1/drivers/usb/hid-core.c 
linux-2.4.30-pre1-usb/drivers/usb/hid-core.c
--- linux-2.4.30-pre1/drivers/usb/hid-core.c2004-11-22 23:04:18.0 
-0800
+++ linux-2.4.30-pre1-usb/drivers/usb/hid-core.c2005-02-10 
11:18:08.0 -0800
@@ -1064,18 +1064,31 @@ static int hid_submit_out(struct hid_dev
 static void hid_ctrl(struct urb *urb)
 {
struct hid_device *hid = urb->context;
+   unsigned long flags;
 
if (urb->status)
warn("ctrl urb status %d received", urb->status);
 
+   spin_lock_irqsave(>outlock, flags);
+
hid->outtail = (hid->outtail + 1) & (HID_CONTROL_FIFO_SIZE - 1);
 
-   if (hid->outhead != hid->outtail)
-   hid_submit_out(hid);
+   if (hid->outhead != hid->outtail) {
+   if (hid_submit_out(hid)) {
+   clear_bit(HID_OUT_RUNNING, >iofl);
+   }
+   spin_unlock_irqrestore(>outlock, flags);
+   return;
+   }
+
+   clear_bit(HID_OUT_RUNNING, >iofl);
+   spin_unlock_irqrestore(>outlock, flags);
 }
 
 void hid_write_report(struct hid_device *hid, struct hid_report *report)
 {
+   unsigned long flags;
+
if (hid->report_enum[report->type].numbered) {
hid->out[hid->outhead].buffer[0] = report->id;
hid_output_report(report, hid->out[hid->outhead].buffer + 1);
@@ -1087,13 +1100,18 @@ void hid_write_report(struct hid_device 
 
hid->out[hid->outhead].dr.wValue = cpu_to_le16(((report->type + 1) << 
8) | report->id);
 
+   spin_lock_irqsave(>outlock, flags);
+
hid->outhead = (hid->outhead + 1) & (HID_CONTROL_FIFO_SIZE - 1);
 
if (hid->outhead == hid->outtail)
hid->outtail = (hid->outtail + 1) & (HID_CONTROL_FIFO_SIZE - 1);
 
-   if (hid->urbout.status != -EINPROGRESS)
-   hid_submit_out(hid);
+   if (!test_and_set_bit(HID_OUT_RUNNING, >iofl))
+   if (hid_submit_out(hid))
+   clear_bit(HID_OUT_RUNNING, >iofl);
+
+   spin_unlock_irqrestore(>outlock, flags);
 }
 
 int hid_open(struct hid_device *hid)
@@ -1333,6 +1351,8 @@ static struct hid_device *usb_hid_config
return NULL;
}
 
+   spin_lock_init(>outlock);
+
hid->version = hdesc->bcdHID;
hid->country = hdesc->bCountryCode;
hid->dev = dev;
diff -urpN -X dontdiff linux-2.4.30-pre1/drivers/usb/hid.h 
linux-2.4.30-pre1-usb/drivers/usb/hid.h
--- linux-2.4.30-pre1/drivers/usb/hid.h 2005-01-26 13:04:23.0 -0800
+++ linux-2.4.30-pre1-usb/drivers/usb/hid.h 2005-02-10 11:26:43.0 
-0800
@@ -302,6 +302,8 @@ struct hid_control_fifo {
 #define HID_CLAIMED_INPUT  1
 #define HID_CLAIMED_HIDDEV 2
 
+#define HID_OUT_RUNNING2
+
 struct hid_input {
struct list_head list;
struct hid_report *report;
@@ -322,12 +324,15 @@ struct hid_device {   
/* device repo
struct usb_device *dev; /* USB 
device */
int ifnum;  /* USB 
interface number */
 
+   unsigned long iofl; /* I/O 
flags (CTRL_RUNNING, OUT_RUNNING) */
+
struct urb urb; /* USB 
URB structure */
char buffer[HID_BUFFER_SIZE];   /* Rx 
buffer */
 
struct urb urbout;  /* 
Output URB */
struct hid_control_fifo out[HID_CONTROL_FIFO_SIZE]; /* 
Transmit buffer */
unsigned char outhead, outtail; /* Tx 
buffer head & tail */
+   spinlock_t outlock; /* 
Output fifo spinlock */
 
unsigned claimed;   /* 
Claimed by hidinput, hiddev? */  
unsigned quirks;/* 
Various quirks the device can pull on us */
-
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/

DVB at76c651.c driver seems to be dead code

[Adrian Bunk]

I didn't find any way how the drivers/media/dvb/frontends/at76c651.c 
driver would do anything inside kernel 2.6.11-rc3-mm2. All it does is to 
EXPORT_SYMBOL a function at76c651_attach that isn't used anywhere.

Is a patch to remove this driver OK or did I miss anything?

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/

USB 2.4.30: ftdi_sio

[Pete Zaitcev]

Granted, this is a cleanup, and we don't like cleanups in 2.4. But I really
dislike how the comment managed to detach from the function it described.
The idiotic error message is quite annoying, too.

diff -urpN -X dontdiff linux-2.4.30-pre1/drivers/usb/serial/ftdi_sio.c 
linux-2.4.30-pre1-usb/drivers/usb/serial/ftdi_sio.c
--- linux-2.4.30-pre1/drivers/usb/serial/ftdi_sio.c 2005-01-25 
11:17:25.0 -0800
+++ linux-2.4.30-pre1-usb/drivers/usb/serial/ftdi_sio.c 2005-02-10 
11:18:12.0 -0800
@@ -737,8 +737,6 @@ static struct usb_serial_device_type ftd
 };
 
 
-
-
 static struct usb_serial_device_type ftdi_userdev_device = {
.owner =THIS_MODULE,
.name = "FTDI SIO compatible",
@@ -1240,15 +1238,6 @@ static int ftdi_HE_TIRA1_startup (struct
 } /* ftdi_HE_TIRA1_startup */
 
 
-/* ftdi_shutdown is called from usbserial:usb_serial_disconnect 
- *   it is called when the usb device is disconnected
- *
- *   usbserial:usb_serial_disconnect
- *  calls __serial_close for each open of the port
- *  shutdown is called then (ie ftdi_shutdown)
- */
-
-
 /* Startup for the 8U232AM chip */
 static int ftdi_userdev_startup (struct usb_serial *serial)
 {
@@ -1273,6 +1262,14 @@ static int ftdi_userdev_startup (struct 
 }
 
 
+/* ftdi_shutdown is called from usbserial:usb_serial_disconnect 
+ *   it is called when the usb device is disconnected
+ *
+ *   usbserial:usb_serial_disconnect
+ *  calls __serial_close for each open of the port
+ *  shutdown is called then (ie ftdi_shutdown)
+ */
+
 static void ftdi_shutdown (struct usb_serial *serial)
 { /* ftdi_shutdown */

@@ -1382,6 +1379,7 @@ static void ftdi_close (struct usb_seria
struct usb_serial *serial;
unsigned int c_cflag = port->tty->termios->c_cflag;
char buf[1];
+   int err;
 
dbg("%s", __FUNCTION__);
 
@@ -1412,8 +1410,9 @@ static void ftdi_close (struct usb_seria
 
/* shutdown our bulk read */
if (port->read_urb) {
-   if(usb_unlink_urb (port->read_urb)<0)
-   err("Error unlinking urb");
+   err = usb_unlink_urb (port->read_urb);
+   if (err < 0 && err != -ENODEV)
+   err("Error unlinking urb (%d)", err);
}
/* unlink the running write urbs */
 
-
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-rc3-mm2

[Benjamin Herrenschmidt]

> > Without the aty128fb and radeonfb updates, current 2.6.11 is a
> > regression on pmac as it breaks sleep support on previously working
> > laptops.
> 
> Is that worse than the risk of the large patch?

Well, it used to work upstream fine for some time now... The large patch
isn't risky imho, at least in the latest version I sent you. The bulk of
the changes are just code to re-initialize new chip that isn't executed
at all on earlier models. The main radeonfb code changes very little. I
haven't had a failure report with the latest patch yet.

> > If you don't intend to get at least
> > try_to_acquire_console_sem() and aty128fb fix in, in which case i can
> > send you a minimal radeonfb patch, then I'll have to make another patch
> > for 2.6.11 that reverts some of the arch changes to re-enable sleep on
> > those machines.
> 
> Ho hum.  PM and fbdev are regularly broken anyway.  Please always identify
> the patches by name - it helps avoid mistakes.

Ahem ... not that badly broken on releases, I've been careful enough
that at least, powerbook sleep worked fine for some time now.
 
> These?
> 
> add-try_acquire_console_sem.patch
> update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch

Those 2 first at least yes

> radeonfb-update.patch
> radeonfb-build-fix.patch

And either the above, or I can do a minimal patch on radeonfb just
restoring sleep on earlier models (adding the pmac_feature call to
notify the arch code that we can wakeup the chip) if you don't want to
merge the bigger update.

Ben.


-
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: [ANNOUNCE] "iswraid" (ICHxR ataraid sub-driver) for 2.4.29

[Bartlomiej Zolnierkiewicz]

On Thu, 10 Feb 2005 16:39:34 -0200, Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
> On Thu, Feb 10, 2005 at 11:04:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Thu, 10 Feb 2005 21:05:13 +0100, Bartlomiej Zolnierkiewicz
> > <[EMAIL PROTECTED]> wrote:
> > > On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[EMAIL PROTECTED]> 
> > > wrote:
> > > > Bartlomiej Zolnierkiewicz wrote:
> > > > > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[EMAIL PROTECTED]> 
> > > > > wrote:
> > > > >
> > > > >>Arjan van de Ven wrote:
> > > > >>
> > > > I consider it not a new feature, but a missing feature, since 
> > > > otherwise
> > > > user data cannot be accessed in the RAID setups.
> > > > >>>
> > > > >>>
> > > > >>>the same is true for all new hardware drivers and hardware support
> > > > >>>patches. And for new DRM (since new X may need it) and new .. and
> > > > >>>new ... where is the line?
> > > > >>>
> > > > >>>for me a deep maintenance mode is about keeping existing stuff 
> > > > >>>working;
> > > > >>>all new hw support and derivative hardware support (such as this) 
> > > > >>>can be
> > > > >>>pointed at the new stable series... which has been out for quite some
> > > > >>>time now..
> > > > >>
> > > > >>Red herring.
> > > > >>
> > > > >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> > > > >>
> > > > >>We are talking about hardware that is ALREADY supported by 2.4.x 
> > > > >>kernel,
> > > > >>not new hardware.
> > > > >>
> > > > >>We are also talking about inability to access data on hardware 
> > > > >>supported
> > > > >>by 2.4.x, not something that can easily be ignored or papered over 
> > > > >>with
> > > > >>a compatibility mode.
> > > > >
> > > > >
> > > > > the same arguments can be used for crypto support etc.,
> > > > > answer is - use 2.6.x or add extra patches to get 2.4.x working
> > > >
> > > > It's fix in a sense. The hardware is supported now, just not very well.
> > > > If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> > > > it would be a fix, in this case thehardware is supported partially, the
> > > > RAID conponent isn't working, and this is the fix.
> > >
> > > The so called "RAID component" is 100% *software* solution.
> > >
> > > BTW What is UDA?
> >
> > [ This mail is just to explain why I don't like iswraid,
> >   I don't care if it gets merged that much... ]
> >
> > another BTW: this driver adds another incompatibility between
> > 2.4.x and 2.6.x.
> 
> What do you mean "adds another incompatibility" ?
> 
> That users will have to switch to dmraid when upgrading to v2.6.x ?

It is worse than that - AFAIR iswraid provides some features which
are NOT available in 2.6.x kernels.

> > Also most 2.4.x users will want (or have to) migrate
> > to 2.6.x one day and they will have to switch to using device mapper
> > and dmraid anyway.  From my POV merging/supporting iswraid
> > in any way is a lost of time for EVERYBODY in the long-term.
> > Martins, I appreciate all hard work that went into iswraid driver but
> > please face the simple fact, this driver was already obsoleted in
> > the moment it was created (from Linux development process POV).
> >
> > I previously (October?) asked about merging device-mapper
> > instead as it provides easier way to migrate to 2.6.x (not only for
> > Intel "RAID component" users but for ALL "RAID components" users)
> > as they would be able to use the same method for accessing their
> > data in both kernels.  I was said that it is too late for such changes
> > (I consider device-mapper a new driver, changes to existing code
> > are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
> > 2.6.x to device-mapper which was just silly argument IMHO (why we
> > don't stick to IDE drivers for SATA in 2.4.x?).
> 
> SATA is not the same case as sw-RAID in my POV Bart, it allows many
> users to be _able_ use SATA controllers/drives.

Fully agreed but what is your point?  Mine was that we can different
subsystems/drivers for the same device/functionality - like we have
both IDE+siimage and libata+sata_sil drivers in 2.4.x.

Maybe Martins was forced to develop for ataraid in 2.4.x
because lack of device-mapper.  In such case the current
situations is our fault and we can learn something from it.

> > I finally gave up because I didn't want to waste more my time on this and
> > didn't want to go into
> > politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)
> 
> Good to hear your opinion.
-
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: [TRIVIAL 2.6] Update panic() comment.

[Adrian Bunk]

On Wed, Feb 02, 2005 at 01:19:12PM +0100, Heiko Carstens wrote:
> [TRIVIAL 2.6] Update panic() comment.
> 
> panic() doesn't flush the filesystem cache anymore. The comment above the
> function still claims it does.
> 
> Thanks,
> Heiko
> 
> = panic.c 1.22 vs edited =
> --- 1.22/kernel/panic.c   2004-11-08 03:16:06 +01:00
> +++ edited/panic.c2005-02-02 12:25:21 +01:00
>...

Please send patches that apply with -p1.

In this case even more, since the kernel sources contain two panic.c 
files.

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: 2.6.11-rc3-mm2

[Adrian Bunk]

On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
>...
> - Various other stuff.  If anyone has a patch in here which they think
>   should be in 2.6.11, please let me know.  I'm intending to merge the
>   following into 2.6.11:
> 
>   alpha-add-missing-dma_mapping_error.patch
>   fix-compat-shmget-overflow.patch
>   fix-shmget-for-ppc64-s390-64-sparc64.patch
>   binfmt_elf-clearing-bss-may-fail.patch
>   qlogic-warning-fixes.patch
>   oprofile-exittext-referenced-in-inittext.patch
>   force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
>   oprofile-arm-xscale1-pmu-support-fix.patch
>...

As described in the patch description, I'd like to see 
mark-the-mcd-cdrom-driver-as-broken.patch in 2.6.11 .

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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

[Matan Ziv-Av]

On Thu, 10 Feb 2005, Bill Davidsen wrote:
Some systems (intel notably) appear to expect you to use the bios
save/restore video state not re-POST.
Isn't that what it's there for? In any context other than save/restore I 
wouldn't think using the BIOS was a good approach. But this is a special 
case, and if there's a BIOS function which does the right thing, it would 
seem to be easier to assume that the BIOS works than that the driver can do 
every operation for a clean restart.
Maybe with new cards it is different but a few years ago, most cards 
that I tested had problems with those functions.

--
Matan Ziv-Av. [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: 2.6.11-rc3-mm2

[Andrew Morton]

Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > 
> > 
> > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
> >   It seems that nothing else is going to come along and this is completely
> >   encapsulated.
> > 
> > - Various other stuff.  If anyone has a patch in here which they think
> >   should be in 2.6.11, please let me know.  I'm intending to merge the
> >   following into 2.6.11:
> > 
> > alpha-add-missing-dma_mapping_error.patch
> > fix-compat-shmget-overflow.patch
> > fix-shmget-for-ppc64-s390-64-sparc64.patch
> > binfmt_elf-clearing-bss-may-fail.patch
> > qlogic-warning-fixes.patch
> > oprofile-exittext-referenced-in-inittext.patch
> > force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
> > oprofile-arm-xscale1-pmu-support-fix.patch
> 
> Without the aty128fb and radeonfb updates, current 2.6.11 is a
> regression on pmac as it breaks sleep support on previously working
> laptops.

Is that worse than the risk of the large patch?

> If you don't intend to get at least
> try_to_acquire_console_sem() and aty128fb fix in, in which case i can
> send you a minimal radeonfb patch, then I'll have to make another patch
> for 2.6.11 that reverts some of the arch changes to re-enable sleep on
> those machines.

Ho hum.  PM and fbdev are regularly broken anyway.  Please always identify
the patches by name - it helps avoid mistakes.

These?

add-try_acquire_console_sem.patch
update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch
radeonfb-update.patch
radeonfb-build-fix.patch

-
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: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Thu, 2005-02-10 at 16:28 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
> > 
> > > So perhaps this problem is something similar?
> 
> What type of computer has the problem? Who makes it's video chips?

This one is an ECS G320 laptop, with an AMI BIOS and a VIA graphics
chipset. I've had similar reports from people with a variety of
different types of laptop hardware. 

-- 
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: 2.6.11-rc3-mm2

[Benjamin Herrenschmidt]

On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> 
> 
> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
>   It seems that nothing else is going to come along and this is completely
>   encapsulated.
> 
> - Various other stuff.  If anyone has a patch in here which they think
>   should be in 2.6.11, please let me know.  I'm intending to merge the
>   following into 2.6.11:
> 
>   alpha-add-missing-dma_mapping_error.patch
>   fix-compat-shmget-overflow.patch
>   fix-shmget-for-ppc64-s390-64-sparc64.patch
>   binfmt_elf-clearing-bss-may-fail.patch
>   qlogic-warning-fixes.patch
>   oprofile-exittext-referenced-in-inittext.patch
>   force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
>   oprofile-arm-xscale1-pmu-support-fix.patch

Without the aty128fb and radeonfb updates, current 2.6.11 is a
regression on pmac as it breaks sleep support on previously working
laptops. If you don't intend to get at least
try_to_acquire_console_sem() and aty128fb fix in, in which case i can
send you a minimal radeonfb patch, then I'll have to make another patch
for 2.6.11 that reverts some of the arch changes to re-enable sleep on
those machines.

Ben.


-
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: [ANNOUNCE] "iswraid" (ICHxR ataraid sub-driver) for 2.4.29

[Marcelo Tosatti]

On Thu, Feb 10, 2005 at 11:04:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thu, 10 Feb 2005 21:05:13 +0100, Bartlomiej Zolnierkiewicz
> <[EMAIL PROTECTED]> wrote:
> > On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > > Bartlomiej Zolnierkiewicz wrote:
> > > > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[EMAIL PROTECTED]> 
> > > > wrote:
> > > >
> > > >>Arjan van de Ven wrote:
> > > >>
> > > I consider it not a new feature, but a missing feature, since 
> > > otherwise
> > > user data cannot be accessed in the RAID setups.
> > > >>>
> > > >>>
> > > >>>the same is true for all new hardware drivers and hardware support
> > > >>>patches. And for new DRM (since new X may need it) and new .. and
> > > >>>new ... where is the line?
> > > >>>
> > > >>>for me a deep maintenance mode is about keeping existing stuff working;
> > > >>>all new hw support and derivative hardware support (such as this) can 
> > > >>>be
> > > >>>pointed at the new stable series... which has been out for quite some
> > > >>>time now..
> > > >>
> > > >>Red herring.
> > > >>
> > > >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> > > >>
> > > >>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> > > >>not new hardware.
> > > >>
> > > >>We are also talking about inability to access data on hardware supported
> > > >>by 2.4.x, not something that can easily be ignored or papered over with
> > > >>a compatibility mode.
> > > >
> > > >
> > > > the same arguments can be used for crypto support etc.,
> > > > answer is - use 2.6.x or add extra patches to get 2.4.x working
> > >
> > > It's fix in a sense. The hardware is supported now, just not very well.
> > > If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> > > it would be a fix, in this case thehardware is supported partially, the
> > > RAID conponent isn't working, and this is the fix.
> > 
> > The so called "RAID component" is 100% *software* solution.
> > 
> > BTW What is UDA?
> 
> [ This mail is just to explain why I don't like iswraid,
>   I don't care if it gets merged that much... ]
> 
> another BTW: this driver adds another incompatibility between
> 2.4.x and 2.6.x.  

What do you mean "adds another incompatibility" ? 

That users will have to switch to dmraid when upgrading to v2.6.x ? 

> Also most 2.4.x users will want (or have to) migrate
> to 2.6.x one day and they will have to switch to using device mapper
> and dmraid anyway.  From my POV merging/supporting iswraid
> in any way is a lost of time for EVERYBODY in the long-term.
> Martins, I appreciate all hard work that went into iswraid driver but
> please face the simple fact, this driver was already obsoleted in
> the moment it was created (from Linux development process POV).
> 
> I previously (October?) asked about merging device-mapper
> instead as it provides easier way to migrate to 2.6.x (not only for
> Intel "RAID component" users but for ALL "RAID components" users)
> as they would be able to use the same method for accessing their
> data in both kernels.  I was said that it is too late for such changes
> (I consider device-mapper a new driver, changes to existing code
> are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
> 2.6.x to device-mapper which was just silly argument IMHO (why we
> don't stick to IDE drivers for SATA in 2.4.x?).

SATA is not the same case as sw-RAID in my POV Bart, it allows many 
users to be _able_ use SATA controllers/drives. 

> I finally gave up because I didn't want to waste more my time on this and 
> didn't want to go into
> politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)

Good to hear your opinion.
-
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: NFS (ext3/VFS?) bug in 2.6.8/10

[Neil Conway]

--- Neil Conway <[EMAIL PROTECTED]> wrote:
> works even on machines with 256MB of RAM.  The odd thing I haven't
> figured out yet is that the fuslwr machine mentioned above has 2GB of
> RAM, and ALL of it is HIGHMEM.  Must be a kernel CONFIG option I
> guess.
>  (Rant: what replaces Configure.help???)

D'oh!!  Brain fade.  I mean to type, "2GB of RAM, and ALL of it is
LOWMEM".  Sigh...

Neil



__ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
-
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-rc3-mm2

[Corey Minyard]

Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
- Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
 It seems that nothing else is going to come along and this is completely
 encapsulated.
- Various other stuff.  If anyone has a patch in here which they think
 should be in 2.6.11, please let me know.  I'm intending to merge the
 following into 2.6.11:
alpha-add-missing-dma_mapping_error.patch
fix-compat-shmget-overflow.patch
fix-shmget-for-ppc64-s390-64-sparc64.patch
binfmt_elf-clearing-bss-may-fail.patch
qlogic-warning-fixes.patch
oprofile-exittext-referenced-in-inittext.patch
force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
oprofile-arm-xscale1-pmu-support-fix.patch
 

The following one should probably go in:
+update-to-ipmi-driver-to-support-old-dmi-spec.patch
 

Systems with old data will not work correctly without it.  There seems 
to be a few of them out there.

-Corey
-
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: [ANNOUNCE] "iswraid" (ICHxR ataraid sub-driver) for 2.4.29

[Bartlomiej Zolnierkiewicz]

On Thu, 10 Feb 2005 21:05:13 +0100, Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]> wrote:
> On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > Bartlomiej Zolnierkiewicz wrote:
> > > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > >
> > >>Arjan van de Ven wrote:
> > >>
> > I consider it not a new feature, but a missing feature, since otherwise
> > user data cannot be accessed in the RAID setups.
> > >>>
> > >>>
> > >>>the same is true for all new hardware drivers and hardware support
> > >>>patches. And for new DRM (since new X may need it) and new .. and
> > >>>new ... where is the line?
> > >>>
> > >>>for me a deep maintenance mode is about keeping existing stuff working;
> > >>>all new hw support and derivative hardware support (such as this) can be
> > >>>pointed at the new stable series... which has been out for quite some
> > >>>time now..
> > >>
> > >>Red herring.
> > >>
> > >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> > >>
> > >>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> > >>not new hardware.
> > >>
> > >>We are also talking about inability to access data on hardware supported
> > >>by 2.4.x, not something that can easily be ignored or papered over with
> > >>a compatibility mode.
> > >
> > >
> > > the same arguments can be used for crypto support etc.,
> > > answer is - use 2.6.x or add extra patches to get 2.4.x working
> >
> > It's fix in a sense. The hardware is supported now, just not very well.
> > If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> > it would be a fix, in this case thehardware is supported partially, the
> > RAID conponent isn't working, and this is the fix.
> 
> The so called "RAID component" is 100% *software* solution.
> 
> BTW What is UDA?

[ This mail is just to explain why I don't like iswraid,
  I don't care if it gets merged that much... ]

another BTW: this driver adds another incompatibility between
2.4.x and 2.6.x.  Also most 2.4.x users will want (or have to) migrate
to 2.6.x one day and they will have to switch to using device mapper
and dmraid anyway.  From my POV merging/supporting iswraid
in any way is a lost of time for EVERYBODY in the long-term.
Martins, I appreciate all hard work that went into iswraid driver but
please face the simple fact, this driver was already obsoleted in
the moment it was created (from Linux development process POV).

I previously (October?) asked about merging device-mapper
instead as it provides easier way to migrate to 2.6.x (not only for
Intel "RAID component" users but for ALL "RAID components" users)
as they would be able to use the same method for accessing their
data in both kernels.  I was said that it is too late for such changes
(I consider device-mapper a new driver, changes to existing code
are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while
2.6.x to device-mapper which was just silly argument IMHO (why we
don't stick to IDE drivers for SATA in 2.4.x?).  I finally gave up because
I didn't want to waste more my time on this and didn't want to go into
politics etc... but damn iswraid wasn't merged so I feel stupid now. :-)

Regards,
Bartlomiej
-
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] BSD Secure Levels: printk overhaul, 2.6.11-rc2-mm1 (1/8)

[Matt Mackall]

On Mon, Feb 07, 2005 at 01:21:08PM -0600, Michael Halcrow wrote:
> This is the first in a series of eight patches to the BSD Secure
> Levels LSM.  It overhauls the printk mechanism in order to reduce the
> unnecessary usage of the .text area.  Thanks to Brad Spengler for the
> suggestion.
> 
> Signed off by: Michael Halcrow <[EMAIL PROTECTED]>

> Index: linux-2.6.11-rc2-mm1-modules/security/seclvl.c
> ===
> --- linux-2.6.11-rc2-mm1-modules.orig/security/seclvl.c   2005-02-03 
> 14:55:44.799527472 -0600
> +++ linux-2.6.11-rc2-mm1-modules/security/seclvl.c2005-02-03 
> 14:56:18.527400056 -0600
> @@ -101,22 +101,20 @@
>  
>  #define MY_NAME "seclvl"
>  
> -/**
> - * This time-limits log writes to one per second.
> - */
> -#define seclvl_printk(verb, type, fmt, arg...)   \
> - do {\
> - if (verbosity >= verb) {\
> - static unsigned long _prior;\
> - unsigned long _now = jiffies;   \
> - if ((_now - _prior) > HZ) { \
> - printk(type "%s: %s: " fmt, \
> - MY_NAME, __FUNCTION__ , \
> - ## arg);\
> - _prior = _now;  \
> - }   \
> - }   \
> - } while (0)
> +static void seclvl_printk( int verb, const char * fmt, ... )
> +{
> + va_list args;
> + va_start( args, fmt );
> + if (verbosity >= verb) {
> + static unsigned long _prior;
> + unsigned long _now = jiffies;
> + if ((_now - _prior) > HZ) {
> + vprintk( fmt, args );
> + }
> + _prior = _now;
> + }
> + va_end( args );
> +}

This could be done with a seclvl_printk macro wrapping a
__seclvl_printk function that provides __FUNCTION__, leaving the
callers the same.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: Detecting kernel shutdown in a kernel driver

[Stephen Hemminger]

On Thu, 10 Feb 2005 15:05:37 -0500
"Simon White" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I've been writing a device driver for a piece of hardware that we recently 
> found the pci bridge has an issue on software reset (kernel 2.6.8.1, hardware 
> reset is fine).  The bridge appears to corrupt the subvendor/device ids on 
> next boot.  We have found a software work around in that I can write to the 
> bridge on module exit and it will always detect correctly next boot (through 
> module_exit when rmmod'd).
> 
> However on shutting down a machine with the module loaded it never works next 
> time, so is module_exit actually called?

(Line wrap your mail please)

> Secondly I searched through some code and on google to determine if I could 
> detect a shutdown notification in the kernel.  I thougt I'd found something 
> using:
> 
> static struct pci_driver hsid_driver =
> {
> .name = HSID_NAME,
> .id_table = id_table,
> .probe= hsid_probe,
> .driver   =
> {
> .shutdown = hsid_shutdown,
> },
> };
> 
> However that also appears not to work.  I wondered what the correct solution 
> was for detecting system shutdown in the kernel even if the application using 
> the device has locked up on un-interruptible sleep, so I may try to clean the 
> hardware up a little.
> 
> Thankyou for any assistance,
> Simon

How about the following, you probably still need pci_hook to handle PCI hot 
plug,
but you hardware probably doesn't do bus hot plug anyway.



static int hsid_notify(struct notifier_block *this, unsigned long code, void 
*unused)
{
if (code==SYS_DOWN || code==SYS_HALT) {
bang_the_bridge();
}

return NOTIFY_DONE;
}


static struct notifier_block hsid_notifier = {
.notifier_call  = hsid_notify,
};


hsid_module_init()
...
register_reboot_notifier(_notifier);


hsid_module_exit()
...
unregister_reboot_notifier(_notifier);
-
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: [RFC][PATCH] add driver matching priorities

[Adam Belay]

On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > I think the issue that Al raises about drivers grabbing devices, and
> > > then trying to unbind them might be a real problem.
> > 
> > I agree.  Do you think registering every in-kernel driver before probing
> > hardware would solve this problem?
> 
> In which case, consider whether we should be tainting the kernel if
> someone loads a device driver, it binds to a device, and then they
> unload that driver.
> 
> It's precisely the same situation, and precisely the same mechanics
> as what I've suggested should be going on here.  If one scenario is
> inherently buggy, so is the other.
> 

I think it would depend on whether the user makes the device busy before
the driver is unloaded.  Different device classes may have different
requirements for when and how a device can be removed.  Are there other
issues as well?  Maybe there are ways to improve driver start and stop
mechanics.

Thanks,
Adam


-
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: [RFC][PATCH] add driver matching priorities

[Adam Belay]

On Thu, 2005-02-10 at 13:46 -0500, Dmitry Torokhov wrote:
> On Thu, 10 Feb 2005 10:33:38 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > >
> > > The second "*match" function in "struct device_driver" gives the driver
> > > a chance to evaluate it's ability of controlling the device and solves a
> > > few problems with the current implementation.  (ex. it's not possible to
> > > detect ISA Modems with only a list of PnP IDs, and some PCI devices
> > > support a pool of IDs that is too large to put in an ID table).
> > 
> > What deficiancy in the current id tables do you see?  What driver has a
> > id table that is "too big"?  Is there some way we can change it to make
> > it work better?
> > 
> 
> Stepping a bit farther away - sometimes generinc matching is not
> enough to determine if driver suits for a device - actual probing is
> needed (consider atkbd and psmouse - they can both attach to the same
> port but we can't determine if it is a keyboard or mouse until we
> started probing)

Also, another example I remember seeing a while back...  Some pcmcia
devices have identical IDs but different chipsets.  The only way to find
the correct driver is to poke around.

Thanks,
Adam


-
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: [RFC][PATCH] add driver matching priorities

[Adam Belay]

On Thu, 2005-02-10 at 10:12 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote:
> > > On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote:
> > > > Hi,
> > > > 
> > > > This patch adds initial support for driver matching priorities to the
> > > > driver model.  It is needed for my work on converting the pci bridge
> > > > driver to use "struct device_driver".  It may also be helpful for driver
> > > > with more complex (or long id lists as I've seen in many cases) matching
> > > > criteria. 
> > > > 
> > > > "match" has been added to "struct device_driver".  There are now two
> > > > steps in the matching process.  The first step is a bus specific filter
> > > > that determines possible driver candidates.  The second step is a driver
> > > > specific match function that verifies if the driver will work with the
> > > > hardware, and returns a priority code (how well it is able to handle the
> > > > device).  The bus layer could override the driver's match function if
> > > > necessary (similar to how it passes *probe through it's layer and then
> > > > on to the actual driver).
> > > > 
> > > > The current priorities are as follows:
> > > > 
> > > > enum {
> > > > MATCH_PRIORITY_FAILURE = 0,
> > > > MATCH_PRIORITY_GENERIC,
> > > > MATCH_PRIORITY_NORMAL,
> > > > MATCH_PRIORITY_VENDOR,
> > > > };
> > > > 
> > > > let me know if any of this would need to be changed.  For example, the
> > > > "struct bus_type" match function could return a priority code.
> > > > 
> > > > Of course this patch is not going to be effective alone.  We also need
> > > > to change the init order.  If a driver is registered early but isn't the
> > > > best available, it will be bound to the device prematurely.  This would
> > > > be a problem for carbus (yenta) bridges.
> > > > 
> > > > I think we may have to load all in kernel drivers first, and then begin
> > > > matching them to hardware.  Do you agree?  If so, I'd be happy to make a
> > > > patch for that too.
> > > 
> > > I think the issue that Al raises about drivers grabbing devices, and
> > > then trying to unbind them might be a real problem.
> > 
> > I agree.  Do you think registering every in-kernel driver before probing
> > hardware would solve this problem?
> 
> This doesn't work for any vendor kernel as they build all drivers as
> modules :(

True, but if we allowed userspace to control specifically which drivers
are bound to which devices, then we will be able to ensure the best
driver is bound.  The only problem is that modules then shouldn't
automatically bind to devices.

For non-modules, as many core drivers currently are (ex. pci bus) we can
often do the right thing using the above suggestion.

I think we can't avoid this inherent flaw in modules if we don't have a
user-space mechanism to control driver binding.  Our current approach
doesn't work because it's indirect.  Adding a device ID doesn't
specifically ensure the device in question will be bound to the correct
driver.

Thanks,
Adam


-
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: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
> 
> > So perhaps this problem is something similar?

What type of computer has the problem? Who makes it's video chips?

-- 
Jon Smirl
[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: [RFC] Reliable video POSTing on resume

[Kendall Bennett]

Matthew Garrett said the following on 2/10/2005 1:06 PM:
On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:

So perhaps this problem is something similar?

I don't think so - if I dd out of ROM, I get something that looks like a
video BIOS (and, indeed, I can make VBE calls to and from it). The
problem is jumping to c000:0003 and executing - this has the effect of
turning off the backlight and giving an illegal instruction error
(I /think/ - I may be getting the machine I have here confused with one
a tester has...)
Laptops are a little different as they will make calls from the Video 
BIOS into the system BIOS, so you need to make sure that the system BIOS 
is also available in the execution environment. So if you are using an 
x86 emulator, you need to make sure the system BIOS is mapped into the 
emulator image and that any necessary resources it might need are available.

Regards,
--
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
-
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: [RFC] Linux Kernel Subversion Howto

[Larry McVoy]

Hi Alexandre,

It seems like you've made up your mind that we are operating out of pure
self interest and have no desire to help you or anyone else unless we
get something out of it.  In other words, we're making our decisions
based on the net positive/negative effect on our business.

Is that a fair assessment of your position?  

It's clear that the path we took has generated illwill amongst some of
you, the web is full of BK license is awful pages, etc.  It's a matter
of the public record that we had at least some idea that this was going
to happen, we didn't expect that you'd all be happy with this arrangement.

So if we knew that doing this would hurt our business, which according
you is the only thing we care about, then why would we do it?  The usual
response is the marketing value we get out of it.  Yes, we certainly do
get some positive marketing out of this.  We also get a ton of negative
marketing, you are aware of that, right?

Is it your opinion that the postive marketing we get outweighs the
negative?  That's possible, I don't think it's true, but lets suppose it
is.  That's only part of the picture.  The other part is that we are
taking a huge risk by giving away the product to very group that is most
motivated to copy it, and if a good enough copy existed it is unlikely
our business would success.

If you are willing to believe that we have good good enough management
here that we were aware of this, and we added up the illwill and the IP
risk and did it anyway.  Why?  Why would any business do something that
was obviously a poor business decision?  Please don't take the cheap
shot and say we are idiots, the founder of your company has advised us
from day one as have others.  We knew what we were doing.  

Can you offer any plausible explanation other than a good faith desire
to help the open source community, albeit in a non-traditional way?


This is perhaps a hard concept to grasp but we are basically saying we're
willing to help everyone except the people who want to take our business
away.  I would guess that over 99.999% of the open source in the world
has nothing to do with SCM.  That's a lot of source that we can help.
You are saying we are an evil money grubbing corporation because we
don't want to give our technology to our competitors.  Fair enough,
that's true, we don't.  What you aren't admitting is that we have done
a lot of good for your community, we continue to provide the tools,
the support, the infrastructure, and we do it in spite of it not being
a very good business decision.  If we get no credit in your mind for
all of that then I don't think we have any basis for further discussion.
-- 
---
Larry McVoylm at bitmover.com   http://www.bitkeeper.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: [PATCH] Altix : ioc4 serial driver support

[Patrick Gefre]

I updated again with more __iomem tags.
ftp://oss.sgi.com/projects/sn2/sn2-update/033-ioc4-support
Signed-off-by: Patrick Gefre <[EMAIL PROTECTED]>

Christoph Hellwig wrote:
On Thu, Feb 10, 2005 at 11:09:43AM -0800, Jesse Barnes wrote:
On Tuesday, February 8, 2005 8:52 am, Patrick Gefre wrote:
I've update the patch with changes from the comments below.
ftp://oss.sgi.com/projects/sn2/sn2-update/033-ioc4-support
Christoph Hellwig wrote:
On Mon, Feb 07, 2005 at 09:58:33AM -0600, Patrick Gefre wrote:
Latest version with review mods:
ftp://oss.sgi.com/projects/sn2/sn2-update/033-ioc4-support
- still not __iomem annotations.
I *think* I have this right ??
Here's the output from 'make C=1' with your driver patched in (you if you 
want
to run it yourself, just copy tomahawk.engr:~jbarnes/bin/sparse to somewhere
in your path and run 'make C=1').  I think most of these warning would be
fixed up if the structure fields referring to registers were declared as
__iomem, but I haven't looked carefully.

Actually the pointers to the struct need to be declared __iomem.  
-
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: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:

> So perhaps this problem is something similar?

I don't think so - if I dd out of ROM, I get something that looks like a
video BIOS (and, indeed, I can make VBE calls to and from it). The
problem is jumping to c000:0003 and executing - this has the effect of
turning off the backlight and giving an illegal instruction error
(I /think/ - I may be getting the machine I have here confused with one
a tester has...)

-- 
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: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[George Anzinger]

I am seeing:
kernel/built-in.o(.text+0x4974): In function `copy_mm':
/usr/src/cvs/mvl-kernel-26/makena/linux-2.6.10/kernel/fork.c:493: undefined 
reference to `__spin_is_locked'
kernel/built-in.o(.text+0x9f5a): In function `next_thread':
/usr/src/cvs/mvl-kernel-26/makena/linux-2.6.10/kernel/exit.c:877: undefined 
reference to `__raw_rwlock_is_locked'
net/built-in.o(.text+0x1258): In function `__sock_create':
/usr/src/cvs/mvl-kernel-26/makena/linux-2.6.10/net/socket.c:175: undefined 
reference to `__spin_is_locked'
net/built-in.o(.text+0x16b54): In function `dev_deactivate':
/usr/src/cvs/mvl-kernel-26/makena/linux-2.6.10/net/sched/sch_generic.c:594: 
undefined reference to `__spin_is_locked'
make[1]: *** [vmlinux] Error 1
make: *** [bzImage] Error 2

Possibly from:
define __raw_spin_is_locked(x)  (*(volatile signed char *)(&(x)->lock) <= 0)
#define __raw_spin_unlock_wait(x) \
do { barrier(); } while(__spin_is_locked(x))
in asm/spinlock.h
should that be __raw_spin_is_locked(x) instead?
--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
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-rc3-mm2

[Jack O'Quin]

[direct reply bounced, resending via gmail]

Andrew Morton <[EMAIL PROTECTED]> writes:

> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > > 
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > > 
> > > 
> > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio 
> > > guys.
> > >   It seems that nothing else is going to come along and this is completely
> > >   encapsulated.
> > 
> > Even if we accept a module that grants capabilities to groups this
> > isn't fine yet because it only supports two specific capabilities
> > (and even those two in different ways!) instead of adding generic
> > support to bind capabilities to groups.
> 
> I'm sure that got discussed somewhere in the 1000 emails which flew past
> last time.  Jack?

[adding cc: for the main discussion participants]

Most people felt that a more general capabilities module would be nice
to have.  But, no one offered any code, or volunteered to work on it.

I have no objection to that approach, but am not willing or able to do
it myself.  My opinion is that expanding the scope of the LSM would
significantly increase its security risk.  That job needs to be done
very carefully, by someone with a deep understanding of the kernel's
internal use of capabilities.

Perhaps, Christoph's suggestion could become part of a more general
module, which might replace the RT-LSM in the 2.8 timeframe.  Our LSM
is a modest solution aimed at solving the immediate needs of audio
developers and users with minimal impact on kernel security or
correctness.
-
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: [RFC] Reliable video POSTing on resume

[Kendall Bennett]

Hi Guys,
I have missed all the original emails in this thread. I was trying to 
re-subscribe to the lkml a few days ago (I just switched over to 
Thunderbird) but I haven't been getting any traffic. So I will try again.

The one thing I can say is that having worked extensively with ATI 
cards, there are some registers that have an effect on whether the BIOS 
image shows up on at the ROM BAR address or not. To get all the ATI 
cards we have working, we have had to massage some of those registers 
because after the POST has been run, they will cause the BIOS image to 
disappear (not intentionally on ATI's part, but a side effect I think).

Note that the cards that require this work just fine if they are in a 
cold boot state when you run the POST - they only have issues after the 
POST code has been run (which actually affects X drivers trying to read 
the BIOS PLL information too).

So perhaps this problem is something similar?
Regards,
Jon Smirl said the following on 2/10/2005 12:34 PM:
I added Kendall from Scitech to the CC list. He is the expert on
getting VBIOS's to post. Maybe he can help.
On Thu, 10 Feb 2005 20:29:47 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
It also explicitly states that Windows 2000 and XP don't support this,
which leads me to suspect that vendors no longer expect POSTing to be
possible after initial system boot.
No, it means that some of my ATI cards don't function as secondary
adapters on 2K and XP.
And nor will any other card that requires POSTing (assuming that it
isn't just ATI being less than honest about driver shortcomings). And
we've certainly seen in the past that removing support for functionality
in Windows tends to result in hardware no longer supporting that
functionality.
I have real, shipping hardware here that fails if you simply try to
execute the video BIOS POST code. If you think this is due to a
shortcoming in existing BIOS emulations, I'm more than happy to dump the
video and system BIOS regions and send them to you.
--
Matthew Garrett | [EMAIL PROTECTED]



--
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
-
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 2.4.30: mct_u232

[Pete Zaitcev]

Now that 2.6 has my changes, we can apply them to 2.4. This includes the
removal of dead code under #ifdef FIX_WRITE_RETURN_CODE_PROBLEM.

This patch fixes the endless loops on disconnect when resubmitting failed
URBs monopolizes CPU and prevents the disconnect thread from cleaning up.

Note though that because of the error code confusion, the actual technique
used in 2.4 is different from 2.6. The 2.4 version simply counts errors.
If too many are received in a row, we stop resubmitting. I consider this
relatively safe, because closing the line clears the condition, and so
in the unlikely event of a regression, users are not made to reboot.

diff -urpN -X dontdiff linux-2.4.30-pre1/drivers/usb/serial/mct_u232.c 
linux-2.4.30-pre1-usb/drivers/usb/serial/mct_u232.c
--- linux-2.4.30-pre1/drivers/usb/serial/mct_u232.c 2005-01-25 
11:17:25.0 -0800
+++ linux-2.4.30-pre1-usb/drivers/usb/serial/mct_u232.c 2005-02-10 
11:18:13.0 -0800
@@ -86,26 +86,14 @@
 #include "usb-serial.h"
 #include "mct_u232.h"
 
-
 /*
  * Version Information
  */
-#define DRIVER_VERSION "v1.2"
+#define DRIVER_VERSION "z2.0"  /* Linux in-kernel version */
 #define DRIVER_AUTHOR "Wolfgang Grandegger <[EMAIL PROTECTED]>"
 #define DRIVER_DESC "Magic Control Technology USB-RS232 converter driver"
 
 /*
- * Some not properly written applications do not handle the return code of
- * write() correctly. This can result in character losses. A work-a-round
- * can be compiled in with the following definition. This work-a-round
- * should _NOT_ be part of an 'official' kernel release, of course!
- */
-#undef FIX_WRITE_RETURN_CODE_PROBLEM
-#ifdef FIX_WRITE_RETURN_CODE_PROBLEM
-static int write_blocking; /* disabled by default */
-#endif
-
-/*
  * Function prototypes
  */
 static int  mct_u232_startup(struct usb_serial *serial);
@@ -114,13 +102,6 @@ static int  mct_u232_open   (stru
  struct file *filp);
 static void mct_u232_close  (struct usb_serial_port *port,
  struct file *filp);
-#ifdef FIX_WRITE_RETURN_CODE_PROBLEM
-static int  mct_u232_write  (struct usb_serial_port *port,
- int from_user,
- const unsigned char *buf,
- int count);
-static void mct_u232_write_bulk_callback (struct urb *urb);
-#endif
 static void mct_u232_read_int_callback   (struct urb *urb);
 static void mct_u232_set_termios (struct usb_serial_port *port,
  struct termios * old);
@@ -147,7 +128,7 @@ MODULE_DEVICE_TABLE (usb, id_table_combi
 
 static struct usb_serial_device_type mct_u232_device = {
.owner = THIS_MODULE,
-   .name =  "Magic Control Technology USB-RS232",
+   .name =  "MCT U232",
.id_table =  id_table_combined,
.num_interrupt_in =  2,
.num_bulk_in =   0,
@@ -155,10 +136,6 @@ static struct usb_serial_device_type mct
.num_ports = 1,
.open =  mct_u232_open,
.close = mct_u232_close,
-#ifdef FIX_WRITE_RETURN_CODE_PROBLEM
-   .write = mct_u232_write,
-   .write_bulk_callback = mct_u232_write_bulk_callback,
-#endif
.read_int_callback = mct_u232_read_int_callback,
.ioctl = mct_u232_ioctl,
.set_termios =   mct_u232_set_termios,
@@ -167,9 +144,14 @@ static struct usb_serial_device_type mct
.shutdown =  mct_u232_shutdown,
 };
 
+struct mct_u232_interval_kludge {
+   int ecnt;   /* Error counter */
+   int ibase;  /* Initial interval value */
+};
 
 struct mct_u232_private {
spinlock_t lock;
+   struct mct_u232_interval_kludge ik[2];
unsigned int control_state; /* Modem Line Setting (TIOCM) */
unsigned charlast_lcr;  /* Line Control Register */
unsigned charlast_lsr;  /* Line Status Register */
@@ -359,17 +341,13 @@ static int mct_u232_startup (struct usb_
struct mct_u232_private *priv;
struct usb_serial_port *port, *rport;
 
-   /* allocate the private data structure */
priv = kmalloc(sizeof(struct mct_u232_private), GFP_KERNEL);
if (!priv)
return -ENOMEM;
-   /* set initial values for control structures */
+   memset(priv, 0, sizeof(struct mct_u232_private));
spin_lock_init(>lock);
-   priv->control_state = 0;
-   priv->last_lsr = 0;
-   priv->last_msr = 0;
serial->port->private = priv;
- 
+
init_waitqueue_head(>port->write_wait);
 
/* Puh, that's dirty */
@@ -383,20 +361,27 @@ static int mct_u232_startup (struct usb_
rport->interrupt_in_urb = NULL;
port->read_urb->context = port;
 
+   priv->ik[0].ibase = 

Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[Ingo Molnar]

* George Anzinger  wrote:

> If I want to write a patch that will work with or without the RT patch 
> applied is the following enough?
> 
> #ifndef RAW_SPIN_LOCK_UNLOCKED
> typedef raw_spinlock_t spinlock_t
> #define RAW_SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED
> #endif

yeah. (but you should rather use DEFINE_SPINLOCK/DEFINE_RAW_SPINLOCK)

Ingo
-
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: [RFC] Changing COW detection to be memory hotplug friendly

[Andrea Arcangeli]

On Thu, Feb 10, 2005 at 08:19:47PM +, Hugh Dickins wrote:
> On Thu, 10 Feb 2005, Andrea Arcangeli wrote:
> > 
> > The reason pinned pages cannot be unmapped is that if they're being
> > unmapped while a rawio read is in progress, a cow on some shared
> > swapcache under I/O could happen.
> > 
> > If a try_to_unmap + COW over a shared swapcache happens during a rawio
> > read, then the rawio reads will get lost generating data corruption.
> 
> Yes, but...
> 
> get_user_pages broke COW in advance of the I/O.  The reason for
> subsequent COW if the page gets unmapped is precisely because
> can_share_swap_page used page_count to judge exclusivity, and
> get_user_pages has bumped that up, so the page appears (in danger
> of being) non-exclusive when actually it is exclusive.  By changing
> can_share_swap_page to use page_mapcount, that frustration vanishes.

What if a second thread does a fork() while the rawio is in progress?
The page will be again no shareable, and if you unmap it the rawio will
be currupt if the thread that executed the fork while the I/O is in
progress writes to a part of the page again after it has been unmapped
(obviously the part of the page that isn't under read-rawio, rawio works
with the hardblocksize, not on the whole page). 
-
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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

[Jon Smirl]

I added Kendall from Scitech to the CC list. He is the expert on
getting VBIOS's to post. Maybe he can help.

On Thu, 10 Feb 2005 20:29:47 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
> > On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> 
> > wrote:
> > > It also explicitly states that Windows 2000 and XP don't support this,
> > > which leads me to suspect that vendors no longer expect POSTing to be
> > > possible after initial system boot.
> >
> > No, it means that some of my ATI cards don't function as secondary
> > adapters on 2K and XP.
> 
> And nor will any other card that requires POSTing (assuming that it
> isn't just ATI being less than honest about driver shortcomings). And
> we've certainly seen in the past that removing support for functionality
> in Windows tends to result in hardware no longer supporting that
> functionality.
> 
> I have real, shipping hardware here that fails if you simply try to
> execute the video BIOS POST code. If you think this is due to a
> shortcoming in existing BIOS emulations, I'm more than happy to dump the
> video and system BIOS regions and send them to you.
> 
> --
> Matthew Garrett | [EMAIL PROTECTED]
> 
> 


-- 
Jon Smirl
[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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

[Ville Syrjälä]

On Thu, Feb 10, 2005 at 03:17:47PM -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > It also explicitly states that Windows 2000 and XP don't support this,
> > which leads me to suspect that vendors no longer expect POSTing to be
> > possible after initial system boot.
> 
> No, it means that some of my ATI cards don't function as secondary
> adapters on 2K and XP.

So you can suspend with one of these and the card gets resumed properly? 
If so I wonder why they don't allow POSTing of secondary cards.

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
-
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 01/04] Adding cipher mode context information to crypto_tfm

[David S. Miller]

On Thu, 10 Feb 2005 02:33:44 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:

> > Is there an easy way to bring pages to lowmem? The cryptoapi is called
> > from the backlog of the networking stack, which is assigned in irq
> > context first and processed softirq context.
> 
> Are networking frames ever allocated from highmem?  Don't think so.

It is absolutely possible, especially over loopback.

It can happen on the send side for any device which indicates
the NETIF_F_HIGHDMA capability, and because loopback indicates
this feature this means we'll see such highmem pages in packets
on receive too.

There is thus also nothing preventing a real hardware device
from feeding highmem packets into the networking stack.
-
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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

[Matthew Garrett]

On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > It also explicitly states that Windows 2000 and XP don't support this,
> > which leads me to suspect that vendors no longer expect POSTing to be
> > possible after initial system boot.
> 
> No, it means that some of my ATI cards don't function as secondary
> adapters on 2K and XP.

And nor will any other card that requires POSTing (assuming that it
isn't just ATI being less than honest about driver shortcomings). And
we've certainly seen in the past that removing support for functionality
in Windows tends to result in hardware no longer supporting that
functionality.

I have real, shipping hardware here that fails if you simply try to
execute the video BIOS POST code. If you think this is due to a
shortcoming in existing BIOS emulations, I'm more than happy to dump the
video and system BIOS regions and send them to you.

-- 
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: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[George Anzinger]

If I want to write a patch that will work with or without the RT patch applied 
is the following enough?

#ifndef RAW_SPIN_LOCK_UNLOCKED
typedef raw_spinlock_t spinlock_t
#define RAW_SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED
#endif
--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
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: [RFC] Changing COW detection to be memory hotplug friendly

[Hugh Dickins]

On Thu, 10 Feb 2005, Andrea Arcangeli wrote:
> 
> The reason pinned pages cannot be unmapped is that if they're being
> unmapped while a rawio read is in progress, a cow on some shared
> swapcache under I/O could happen.
> 
> If a try_to_unmap + COW over a shared swapcache happens during a rawio
> read, then the rawio reads will get lost generating data corruption.

Yes, but...

get_user_pages broke COW in advance of the I/O.  The reason for
subsequent COW if the page gets unmapped is precisely because
can_share_swap_page used page_count to judge exclusivity, and
get_user_pages has bumped that up, so the page appears (in danger
of being) non-exclusive when actually it is exclusive.  By changing
can_share_swap_page to use page_mapcount, that frustration vanishes.

(Of course, if the process forks while async I/O is in progress,
these I/O pages could still get COWed, and either parent or child
lose some of the data being read - but behaviour in that case is
anyway undefined, isn't it?  Just so long as kernel doesn't crash.)

> I had not much time to check the patch yet, but it's quite complex and
> could you explain again how do you prevent a cow to happen while the
> rawio is in flight if you don't pin the pte? The PG_locked bitflag
> cannot matter at all because the rawio read won't lock the page. What
> you have to prevent is the pte to be zeroed out, it must be kept
> writeable during the whole I/O. I don't see how you can allow unmapping
> without running into COWs later on.

The page_mapcount+page_swapcount test for exclusivity is simply a
better test for exclusivity than the page_count test.  Since it says
exclusive when the page is exclusive, no COW occurs (and I've just
remembered that we're actually talking of the odd case where the
process itself writes into another portion of the page under I/O,
to get that write fault: but that still works).

page_count does still play a vital role, in ensuring that the page
stays held in the swapcache, cannot actually be reused for something
else while it's unmapped.

> This is the only thing I care to understand really, since it's the only
> case that the pte pinning was fixing.
> 
> Overall I see nothing wrong in preventing memory removal while rawio is
> in flight. rawio cannot be in flight forever (ptrace and core dump as
> well should complete eventually). Why can't you simply drop pages from
> the freelist one by one until all of them are removed from the freelist?

I did ask Toshihiro about that earlier in the thread.  Best look up his
actual reply, but as I understand it, his test is sufficiently thorough
that it's actually doing direct I/Os in parallel, so there's never a
moment when the page is free.  He believes that an unprivileged process
should not be allowed to hold pages indefinitely unmigratable.

I have little appreciation of the hotplug/memmigration issues here.
But whatever the merits of that, I do think the new can_share_swap_page
is an improvement over the old (written in the days before page_mapcount
existed), and that it's preferable to remove the page_count heuristic
from try_to_unmap_one.

Hugh
-
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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

[Jon Smirl]

On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> It also explicitly states that Windows 2000 and XP don't support this,
> which leads me to suspect that vendors no longer expect POSTing to be
> possible after initial system boot.

No, it means that some of my ATI cards don't function as secondary
adapters on 2K and XP.

-- 
Jon Smirl
[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/

Detecting kernel shutdown in a kernel driver

[Simon White]

Hi,

I've been writing a device driver for a piece of hardware that we recently 
found the pci bridge has an issue on software reset (kernel 2.6.8.1, hardware 
reset is fine).  The bridge appears to corrupt the subvendor/device ids on next 
boot.  We have found a software work around in that I can write to the bridge 
on module exit and it will always detect correctly next boot (through 
module_exit when rmmod'd).

However on shutting down a machine with the module loaded it never works next 
time, so is module_exit actually called?

Secondly I searched through some code and on google to determine if I could 
detect a shutdown notification in the kernel.  I thougt I'd found something 
using:

static struct pci_driver hsid_driver =
{
.name = HSID_NAME,
.id_table = id_table,
.probe= hsid_probe,
.driver   =
{
.shutdown = hsid_shutdown,
},
};

However that also appears not to work.  I wondered what the correct solution 
was for detecting system shutdown in the kernel even if the application using 
the device has locked up on un-interruptible sleep, so I may try to clean the 
hardware up a little.

Thankyou for any assistance,
Simon

Please CC me.

-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

-
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] Panasonic ACPI driver

[Timo Hoenig]

Hi,

this is another ACPI driver for several Panasonic notebooks. The driver
provides support for hotkeys and enables access to other hardware like
reading/setting the LCD brightness.

Like the Sony ACPI driver--recently sent by Stelian Pop--it would be
good to to see this one to be integrated into the -mm tree, too.

The attached patch is against 2.6.11-rc3.

Thanks,

   -- Timo

..
Timo Hönig 
..:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066
diff -urN linux-2.6.11-rc3_a/drivers/acpi/Kconfig linux-2.6.11-rc3_b/drivers/acpi/Kconfig
--- linux-2.6.11-rc3_a/drivers/acpi/Kconfig	2005-02-03 02:57:04 +0100
+++ linux-2.6.11-rc3_b/drivers/acpi/Kconfig	2005-02-10 20:16:22 +0100
@@ -242,6 +242,22 @@
 	  If you have a legacy free Toshiba laptop (such as the Libretto L1
 	  series), say Y.
 
+config ACPI_PCC
+tristate "Panasonic Laptop Extras"
+depends on X86
+depends on ACPI_INTERPRETER
+default m
+   ---help---
+   This driver implements hotkey functionality and access to
+	   various hardware (e.g. LCD brightness) for the
+   Panasonic R1 (N variant), R2, R3, T2, W2, and Y2 laptops.
+
+   Further details and user space tools are available at
+   .
+
+	   If you have one of the above listed Panasonic laptops
+	   say Y or M here.
+
 config ACPI_CUSTOM_DSDT
 	bool "Include Custom DSDT"
 	depends on ACPI_INTERPRETER && !STANDALONE
diff -urN linux-2.6.11-rc3_a/drivers/acpi/Makefile linux-2.6.11-rc3_b/drivers/acpi/Makefile
--- linux-2.6.11-rc3_a/drivers/acpi/Makefile	2005-02-03 02:56:53 +0100
+++ linux-2.6.11-rc3_b/drivers/acpi/Makefile	2005-02-10 20:15:22 +0100
@@ -54,4 +54,5 @@
 obj-$(CONFIG_ACPI_ASUS)		+= asus_acpi.o
 obj-$(CONFIG_ACPI_IBM)		+= ibm_acpi.o
 obj-$(CONFIG_ACPI_TOSHIBA)	+= toshiba_acpi.o
+obj-$(CONFIG_ACPI_PCC)		+= pcc_acpi.o
 obj-$(CONFIG_ACPI_BUS)		+= scan.o motherboard.o
diff -urN linux-2.6.11-rc3_a/drivers/acpi/pcc_acpi.c linux-2.6.11-rc3_b/drivers/acpi/pcc_acpi.c
--- linux-2.6.11-rc3_a/drivers/acpi/pcc_acpi.c	1970-01-01 01:00:00 +0100
+++ linux-2.6.11-rc3_b/drivers/acpi/pcc_acpi.c	2005-02-10 14:50:59 +0100
@@ -0,0 +1,937 @@
+/*
+ *  Panasonic HotKey and lcd brightness control Extra driver
+ *  (C) 2004 Hiroshi Miura <[EMAIL PROTECTED]>
+ *  (C) 2004 NTT DATA Intellilink Co. http://www.intellilink.co.jp/
+ *  (C) 2005 Timo Hoenig <[EMAIL PROTECTED]>
+ *
+ *  derived from toshiba_acpi.c, Copyright (C) 2002-2004 John Belmonte
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as 
+ *  publicshed by the Free Software Foundation.
+ *
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#define ACPI_PCC_VERSION	"0.8.3"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+MODULE_AUTHOR("Hiroshi Miura");
+MODULE_DESCRIPTION("ACPI driver for Panasonic Lets Note laptops");
+MODULE_LICENSE("GPL");
+
+/* Defines */
+#define ACPI_HOTKEY_COMPONENT	0x1000
+#define _COMPONENT		ACPI_HOTKEY_COMPONENT
+#define HKEY_NOTIFY		0x80
+#define PROC_PCC		"panasonic"
+
+#define PCC_LOG"pcc_acpi: "
+#define PCC_ERRKERN_ERRPCC_LOG 
+#define PCC_INFO   KERN_INFO   PCC_LOG
+
+/* This is transitional definition */
+#ifndef KEY_BATT
+# define KEY_BATT 227
+#endif
+
+#define PROC_STR_MAX_LEN  8
+
+/* LCD_TYPEs: 0 = Normal, 1 = Semi-transparent
+ * ENV_STATEs: Normal temp=0x01, High temp=0x81, N/A=0x00
+ * 
+ */
+enum SINF_BITS { SINF_NUM_BATTERIES = 0,
+ SINF_LCD_TYPE, SINF_AC_MAX_BRIGHT,
+		 SINF_AC_MIN_BRIGHT, SINF_AC_CUR_BRIGHT, SINF_DC_MAX_BRIGHT,
+		 SINF_DC_MIN_BRIGHT, SINF_DC_CUR_BRIGHT, SINF_MUTE,
+		 SINF_RESERVED,  SINF_ENV_STATE,
+		 SINF_STICKY_KEY = 0x80,
+};
+
+
+static int __devinit acpi_pcc_hotkey_add (struct acpi_device *device);
+static int __devexit acpi_pcc_hotkey_remove (struct acpi_device *device,
+		int type);
+static int acpi_pcc_hotkey_resume(struct acpi_device *device, int state);
+
+static struct acpi_driver acpi_pcc_driver = {
+	.name =		"Panasonic PCC extra driver",
+	.class =	"pcc",
+	.ids =		"MAT0012,MAT0013,MAT0018,MAT0019",
+	.ops =		{
+.add =acpi_pcc_hotkey_add,
+.remove = __devexit_p(acpi_pcc_hotkey_remove),
+.resume = acpi_pcc_hotkey_resume,
+			},
+};
+
+struct acpi_hotkey {
+	acpi_handle		handle;
+	struct 

Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

[Matthew Garrett]

On Thu, 2005-02-10 at 21:25 +0200, Ville SyrjÃlà wrote:
> BTW it seems that old ATI cards use the BIOS to initialize secondary 
> adapters even under Windows.
> See http://www.ati.com/support/infobase/3663.html.

It also explicitly states that Windows 2000 and XP don't support this,
which leads me to suspect that vendors no longer expect POSTing to be
possible after initial system boot.

-- 
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: [ANNOUNCE] "iswraid" (ICHxR ataraid sub-driver) for 2.4.29

[Bartlomiej Zolnierkiewicz]

On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >>Arjan van de Ven wrote:
> >>
> I consider it not a new feature, but a missing feature, since otherwise
> user data cannot be accessed in the RAID setups.
> >>>
> >>>
> >>>the same is true for all new hardware drivers and hardware support
> >>>patches. And for new DRM (since new X may need it) and new .. and
> >>>new ... where is the line?
> >>>
> >>>for me a deep maintenance mode is about keeping existing stuff working;
> >>>all new hw support and derivative hardware support (such as this) can be
> >>>pointed at the new stable series... which has been out for quite some
> >>>time now..
> >>
> >>Red herring.
> >>
> >>2.4.x has ICH5/6 support -- but is missing the RAID support component.
> >>
> >>We are talking about hardware that is ALREADY supported by 2.4.x kernel,
> >>not new hardware.
> >>
> >>We are also talking about inability to access data on hardware supported
> >>by 2.4.x, not something that can easily be ignored or papered over with
> >>a compatibility mode.
> >
> >
> > the same arguments can be used for crypto support etc.,
> > answer is - use 2.6.x or add extra patches to get 2.4.x working
> 
> It's fix in a sense. The hardware is supported now, just not very well.
> If an IDE chipset was capable of UDA4 and the driver only allowed UDA2
> it would be a fix, in this case thehardware is supported partially, the
> RAID conponent isn't working, and this is the fix.

The so called "RAID component" is 100% *software* solution.

BTW What is UDA?
-
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: the "Turing Attack" (was: Sabotaged PaXtest)

[David Weinehall]

On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote:
> 
> * Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote:
> > > 
> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > 
> > > > the bigger problem is however that you're once again fixing the
> > > > symptoms, instead of the underlying problem - not the correct
> > > > approach/mindset.
> > > 
> > > i'll change my approach/mindset when it is proven that "the underlying
> > > problem" can be solved. (in a deterministic fashion)
> > 
> > I know neither exec-shield nor PaX and therefore have no bias or
> > preference - I thought I should chirp in on your comment here Ingo...
> > 
> > ...
> > > PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield
> > > is in the 6th month, but that does not change the fundamental
> > > end-result: a child will be born ;-)
> > 
> > Yes and no.  I would think that the chances of a child being born are
> > greater if the pregnancy has lasted successfully up until the 6th month,
> > compared to a first week pregnancy.
> > 
> > I assume you get my point  :)
> 
> the important point is: neither PaX nor exec-shield can claim _for sure_
> that no child will be born, and neither can claim virginity ;-)
> 
> [ but i guess there's a point where a bad analogy must stop ;) ]

Yeah, sex is *usually* a much more pleasant experience than having your
machine broken into, even if it results in a pregnancy. =)


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/
-
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-rc3-mm2

[Andrew Morton]

Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > 
> > 
> > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
> >   It seems that nothing else is going to come along and this is completely
> >   encapsulated.
> 
> Even if we accept a module that grants capabilities to groups this isn't fine
> yet because it only supports two specific capabilities (and even those two in
> different ways!) instead of adding generic support to bind capabilities to
> groups.

I'm sure that got discussed somewhere in the 1000 emails which flew past
last time.  Jack?

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