Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Gábor Lénárt]

On Mon, Feb 14, 2005 at 08:45:39PM -0500, Kyle Moffett wrote:
> >last thing that gets run.  There is just no reason for this.  We should
> >start X and initialize the display and get the login prompt up there
> >ASAP, and let the system acquire the DHCP lease and start sendmail and
> >apache and get the date from the NTP server *in the background while I
> >am logging in*.  It's not rocket science.
> 
> Such a system needs a drastically different bootup process than 
> currently
> exists, including the ability to specify init-script dependencies.  
> (Like

Ok, so see Gentoo. Exactly fits your needs, it seems ;-) Dependencies are
supported, even paralell execution of init scripts are supported by default
design (you need to change only one setting to do this, IMHO, in
/etc/conf.d/rc). So it is already solved if you talking about the paralell
execution with dependency info in init scripts ...

Also the smf ability of Solaris10 seems to be interesting, but I don't want
to talk about it, since I have no time to see it in action, I've only read
about it, so ...

- Gábor
-
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][RFC]: Clean up resource allocation in i8042 driver

[Vojtech Pavlik]

On Mon, Feb 14, 2005 at 11:32:30AM -0500, Prarit Bhargava wrote:

> I didn't see a final ACK on this patch -- just checking for one :)

The patch was redone - we now check for error from the 'flush' command
before sending CTL_TEST.

> P.
> 
> Prarit Bhargava wrote:
> 
> >I've taken into account Dmitry's comments (thanks Dmitry!) and 
> >generated a new patch.
> >
> >Thanks,
> >
> >P.
> >Jesse Barnes wrote:
> >
> >>On Friday, January 21, 2005 8:35 am, Vojtech Pavlik wrote:
> >> 
> >>
> >>>No. But vacant ports usually return 0xff. The problem here is that 0xff
> >>>is a valid value for the status register, too. Fortunately this patch
> >>>checks for 0xff only after the timeout failed.
> >>>  
> >>
> >>
> >>On PCs you'll get all 1s, but on some ia64 platforms and others, 
> >>you'll take a hard machine check exception if you try to access 
> >>non-existent memory (mmio, port space, or otherwise).
> >>
> >>Jesse
> >>-
> >>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/
> >>
> >> 
> >>
> >
> >
> >= i8042.c 1.71 vs edited =
> >--- 1.71/drivers/input/serio/i8042.c 2005-01-03 08:11:49 -05:00
> >+++ edited/i8042.c   2005-01-21 11:50:11 -05:00
> >@@ -696,7 +696,10 @@
> > unsigned char param;
> >
> > if (i8042_command(, I8042_CMD_CTL_TEST)) {
> >-printk(KERN_ERR "i8042.c: i8042 controller self test 
> >timeout.\n");
> >+if (i8042_read_status() != 0xFF)
> >+printk(KERN_ERR "i8042.c: i8042 controller 
> >self test timeout.\n");
> >+else
> >+printk(KERN_ERR "i8042.c: no i8042 
> >controller found.\n");
> > return -1;
> > }
> >
> >@@ -1016,16 +1019,22 @@
> > i8042_aux_values.irq = I8042_AUX_IRQ;
> > i8042_kbd_values.irq = I8042_KBD_IRQ;
> >
> >-if (i8042_controller_init())
> >+if (i8042_controller_init()) {
> >+i8042_platform_exit();
> > return -ENODEV;
> >+}
> >
> > err = driver_register(_driver);
> >-if (err)
> >+if (err) {
> >+i8042_platform_exit();
> > return err;
> >+}
> >
> > i8042_platform_device = platform_device_register_simple("i8042", -1, 
> > NULL, 0);
> > if (IS_ERR(i8042_platform_device)) {
> > driver_unregister(_driver);
> >+i8042_platform_exit();
> >+del_timer_sync(_timer);
> > return PTR_ERR(i8042_platform_device);
> > }
> >
> > 
> >
> 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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 Tue, Feb 15, 2005 at 06:39:37AM +0100, Harald Dunkel wrote:
> Greg KH wrote:
> >On Sat, Feb 12, 2005 at 09:30:54AM +0100, Harald Dunkel wrote:
> >
> >>
> >>If it is not possible to use klibc together with a non-Linux
> >>system (e.g. FreeBSD or Mach), then I would suggest to make
> >>klibc an optional kernel patch and drop it from udev and
> >>hotplug.
> >
> >
> >But it is not possible to use udev or hotplug-ng on a non-Linux system,
> >right?
> >
> 
> Thats not the point. The point is to remove the copy of the
> klibc sources from packages like udev and hotplug-ng and
> to use the existing klibc sources or binaries on the target
> system instead. Just to keep it modular.

Again, my point is I'll take klibc out of the udev and hotplug-ng trees
when it is actually on people's systems because it is in the kernel
source tree.  Until that happens I'll continue to keep it in the udev
and hotplug-ng trees, ok?

> >As far as "optional kernel patch"?  What do you mean?  People are
> >working on adding klibc to the main kernel tree, nothing optional about
> >that.
> >
> 
> I do not know the internals of klibc that much. Is it possible
> to use klibc on non-Linux systems, e.g. on Mach or FreeBSD?
> Maybe by adding some #ifdefs to klibc's kernel interface?

I don't know, and I really don't care :)

> If yes, then making klibc an integrated part of the Linux
> kernel source tree and dropping the independent development
> tree would be a restriction to the use of klibc.

Huh?  You are free to take klibc and do whatever you want to with it
based on the license it has.  No one is restricting you from doing that,
right?

> AFAIK the plan for initramfs is to move as much functionality
> as possible from kernel to user space.

Yes.

> Why not do the same
> thing for the sources? Everything that is supposed to be run
> in user space could be removed from the kernel source tree
> and managed seperately, either in a set of userspace modules
> like klibc, hotplug, udev, initramfs, etc., or in a monolithic
> "userspace-tools" source tree.

Because we still want to actually be able to boot a kernel, right?  :)

Let's just get the early boot stuff building and working properly, and
then we'll worry about ripping the stuff out of the kernel tree then.

> Surely klibc belongs to the user space.

Hm, like the other things in the kernel source tree that are also only
in userspace?  :)

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-bk: cpu hotplug + preempt = smp_processor_id warnings galore

[Ingo Molnar]

* Nathan Lynch <[EMAIL PROTECTED]> wrote:

> Works ok here.
> 
> It looks as if we need to explicitly bind worker threads to a newly
> onlined cpu.  This gets rid of the smp_processor_id warnings from
> cache_reap.  Adding a little more instrumentation to the debug
> smp_processor_id showed that new worker threads were actually running
> on the wrong cpu...
> 
> Does this look ok?

indeed - looks much better than the 'turn off the warning' solution.

Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Nigel Cunningham]

Hi.

On Tue, 2005-02-15 at 17:15, Jim Crilly wrote:
> Nigel Cunningham said the following:
> > You warmed my heart until...
> 
> Good to know someone reads my email =)
> 
> > Why not? :> I guess you mean to the problem of slow booting in the first
> > place - I would agree with you there, but is there are reason why we
> > should have booting being the norm instead of normally suspending and
> > resuming, and only rebooting for new kernels/hardware/etc.
> 
> Don't get me wrong, I would go nuts without swsusp2 on my notebook and I 
> don't 
> see why that shouldn't be a valid avenue to pursue; even for servers it 
> doesn't 
> seem like a terribly bad idea. But for me it only works on 1 out of my 4 
> machines. The 3 non-working machines have their root and swap on SCSI devices 
> and to top it off 2 of them are non-x86 architectures.

Okay. So it's a lack of hardware support then. I need to bug people to
get SCSI PM support working, and to lend me non-x86 and x86-64 some more
:>

> Another issue would be dual-booting, which a lot of people still do for some 
> strange reason. At least I had noticed that Windows tends to have problems 
> when 
> filesystems it had mounted before the hibernation are altered while it's not 
> running. I'm not sure if similar issues would apply to Linux, hell I'm not 
> even 
> sure if it still applies to Windows because that was so long ago that I had 
> noticed.

Suspend certainly doesn't like filesystems being mounted under it - it
writes the image without remounting ro or unmounting. I think I saw a
patch Tim had that remounted ro, but you still have to be careful as the
saved memory contains a picture of the state of superblocks and so on.

Regards,

Nigel

-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

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

asm-m32r/bug.h (was Re: )

[Hirokazu Takata]

Hi,

There is no special reason at this moment.
Please apply this patch.

Thank you.


From: Daniel Dickman <[EMAIL PROTECTED]>
Date: Sun, 13 Feb 2005 00:24:13 -0800 (PST)
> For the m32r architecture, is there a reason not to use the generic bug.h
> definition?
> 
> Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>
> 
> --- linux-2.6.11-rc4/include/asm-m32r/bug.h 2004-12-24 16:34:01.0
> -0500
> +++ linux/include/asm-m32r/bug.h2005-02-13 03:39:39.775236000 -0500
> @@ -1,22 +1,4 @@
>  #ifndef _M32R_BUG_H
>  #define _M32R_BUG_H
> -
> -#define BUG()  do { \
> -   printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
> -} while (0)
> -
> -#define PAGE_BUG(page) do { BUG(); } while (0)
> -
> -#define BUG_ON(condition) \
> -   do { if (unlikely((condition)!=0)) BUG(); } while(0)
> -
> -#define WARN_ON(condition) do { \
> -   if (unlikely((condition)!=0)) { \
> -   printk("Badness in %s at %s:%d\n", __FUNCTION__, \
> -   __FILE__, __LINE__); \
> -   dump_stack(); \
> -   } \
> -} while (0)
> -
> -#endif /* _M32R_BUG_H */
> -
> +#include 
> +#endif
> 
--
Hirokazu Takata <[EMAIL PROTECTED]>
Linux/M32R Project:  http://www.linux-m32r.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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Jim Crilly]

Nigel Cunningham said the following:
You warmed my heart until...
Good to know someone reads my email =)
Why not? :> I guess you mean to the problem of slow booting in the first
place - I would agree with you there, but is there are reason why we
should have booting being the norm instead of normally suspending and
resuming, and only rebooting for new kernels/hardware/etc.
Don't get me wrong, I would go nuts without swsusp2 on my notebook and I don't 
see why that shouldn't be a valid avenue to pursue; even for servers it doesn't 
seem like a terribly bad idea. But for me it only works on 1 out of my 4 
machines. The 3 non-working machines have their root and swap on SCSI devices 
and to top it off 2 of them are non-x86 architectures.

Another issue would be dual-booting, which a lot of people still do for some 
strange reason. At least I had noticed that Windows tends to have problems when 
filesystems it had mounted before the hibernation are altered while it's not 
running. I'm not sure if similar issues would apply to Linux, hell I'm not even 
sure if it still applies to Windows because that was so long ago that I had 
noticed.

Regards,
Nigel
Jim.
-
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: Radeon FB troubles with recent kernels

[Matt Mackall]

On Tue, Feb 15, 2005 at 12:07:34PM +1100, Benjamin Herrenschmidt wrote:
> 
> > Nope. No printk outputs from _set_par, _write_mode, or _engine_init.
> > 
> > Just to clarify: the gdm stop is done from tty1 while gdm is running
> > on tty7, so I don't think it's a matter of mode switch logic.
> 
> Ohhh, this is a known bug then. When you kill X while it's not on the
> front VT, it will crap on the engine. This has always been the case, I
> suppose that if you didn't notice it before, it 's because you are
> lucky :)

I think I noticed it in the course of testing recent fbdev and console
code changes..

> > Also, I'm still seeing the LCD blooming + hang on starting radeonfb.
> > It's something like 1 in 10 boots rather than every boot now though.
> 
> Does it actually hangs ? That's weird... looks like a chip crash. Can
> you check if that happens with radeonfb.default_dynclk=-1 on the kernel
> command line ?

Hard to say, it's rather a pain to reproduce. I can add that to my
default boot and if it shows up again, I'll let you know.

-- 
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: Call for help: list of machines with working S3

[Alistair John Strachan]

On Monday 14 Feb 2005 21:11, Pavel Machek wrote:
[snip]
>
> Table of known working systems:
>
> Model   hack (or "how to do it")
> ---
>--- IBM TP R32 / Type 2658-MMG  none (1)
> Athlon HP Omnibook XE3none (1)
> Compaq Armada E500 - P3-700 none (1) (S1 also works OK)
> IBM t41p  none (1)
> Athlon64 desktop prototypes3_bios (2)
> HP NC6000 s3_bios (2)

The above report is incorrect. On 2.6.11-rc4, even with the s3_bios option, 
the NC6000 (which I own) still does not wake up from S3 sleep. The wiki 
linked somewhere else in this thread also identifies these machines as not 
working.

> Toshiba Satellite 4080XCDT  s3_mode (3)
> Toshiba Satellite 4030CDT s3_mode (3)
> Dell D600, ATI RV250vga=normal (**)
> Asus L2400D s3_mode (3)(***) (S1 also works OK)
> Toshiba Satellite P10-554   s3_bios,s3_mode (4)()
> Acer TM 800   vga=normal, X patches, see webpage (5)
> Athlon64 Arima W730a  vbestate needed (6)
> eMachines athlon64 machines   vbestate needed (6) (someone please get me
> model #s)
>
> (**) Text console is "strange" after resume. Backlight is switched on again
>
>  by the X server. X server is:
>  | X Window System Version 6.8.1.904 (6.8.2 RC 4)
>  | Release Date: 2 February 2005
>  | X Protocol Version 11, Revision 0, Release 6.8.1.904
>  | Build Operating System: SuSE Linux [ELF] SuSE
>
>  as present in SUSE 9.3preview3.
>
> (***) To be tested with a newer kernel.
>
> () Not with SMP kernel, UP only.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:CS/CSim Undergraduate
contact:1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
-
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] New 2/5: LSM hooks rework

[Kurt Garloff]

Hi,

On Sun, Feb 13, 2005 at 04:11:09PM -0500, Kurt Garloff wrote:
> From: Kurt Garloff <[EMAIL PROTECTED]>
> Subject: Clean LSM stub file
[...]

So, for convenience, I merged Andreas' fix on top
of this patch into a new patch 2, which is attached.
So CONFIG_SECURITY_NETWORK disabled should work again.

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Clean LSM stub file
References: 40217, 39439

Rather than having every LSM hook twice, once for the case with
CONFIG_SECURITY enabled and once for the disabled case, put
everything in one inline function. This reduces the chance of
the two to go out of sync immensely.

This is patch 2/5 of the LSM overhaul.

 security.h | 1274 -
 1 files changed, 342 insertions(+), 932 deletions(-)

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

Index: linux-2.6.10/include/linux/security.h
===
--- linux-2.6.10.orig/include/linux/security.h
+++ linux-2.6.10/include/linux/security.h
@@ -1242,1544 +1242,954 @@ struct security_operations {
 
 /* global variables */
 extern struct security_operations *security_ops;
 
+/* prototypes */
+extern int security_init   (void);
+extern int register_security   (struct security_operations *ops);
+extern int unregister_security (struct security_operations *ops);
+extern int mod_reg_security(const char *name, struct security_operations 
*ops);
+extern int mod_unreg_security  (const char *name, struct security_operations 
*ops);
+
+#define COND_SECURITY(seop, def) security_ops->seop
+
+#else /* CONFIG_SECURITY */
+static inline int security_init(void)
+{
+   return 0;
+}
+
+# define COND_SECURITY(seop, def) def
+#endif
+
+#ifdef CONFIG_SECURITY_NETWORK
+#define COND_SECU_NET(seop, def) COND_SECURITY(seop, def)
+#else
+#define COND_SECU_NET(seop, def) def
+#endif
+/* SELinux noop */
+#define SE_NOP ({})
+
 /* inline stuff */
 static inline int security_ptrace (struct task_struct * parent, struct 
task_struct * child)
 {
-   return security_ops->ptrace (parent, child);
+   return COND_SECURITY(ptrace (parent, child),
+cap_ptrace (parent, child));
 }
 
 static inline int security_capget (struct task_struct *target,
   kernel_cap_t *effective,
   kernel_cap_t *inheritable,
   kernel_cap_t *permitted)
 {
-   return security_ops->capget (target, effective, inheritable, permitted);
+   return COND_SECURITY(capget (target, effective, inheritable, permitted),
+cap_capget (target, effective, inheritable, 
permitted));
 }
 
 static inline int security_capset_check (struct task_struct *target,
 kernel_cap_t *effective,
 kernel_cap_t *inheritable,
 kernel_cap_t *permitted)
 {
-   return security_ops->capset_check (target, effective, inheritable, 
permitted);
+   return COND_SECURITY(capset_check (target, effective, inheritable, 
permitted),
+cap_capset_check (target, effective, inheritable, 
permitted));
 }
 
 static inline void security_capset_set (struct task_struct *target,
kernel_cap_t *effective,
kernel_cap_t *inheritable,
kernel_cap_t *permitted)
 {
-   security_ops->capset_set (target, effective, inheritable, permitted);
+   COND_SECURITY(capset_set (target, effective, inheritable, permitted),
+ cap_capset_set (target, effective, inheritable, permitted));
 }
 
 static inline int security_acct (struct file *file)
 {
-   return security_ops->acct (file);
+   return COND_SECURITY(acct (file),
+0);
 }
 
 static inline int security_sysctl(struct ctl_table *table, int op)
 {
-   return security_ops->sysctl(table, op);
+   return COND_SECURITY(sysctl(table, op),
+0);
 }
 
 static inline int security_quotactl (int cmds, int type, int id,
 struct super_block *sb)
 {
-   return security_ops->quotactl (cmds, type, id, sb);
+   return COND_SECURITY(quotactl (cmds, type, id, sb),
+0);
 }
 
 static inline int security_quota_on (struct dentry * dentry)
 {
-   return security_ops->quota_on (dentry);
+   return COND_SECURITY(quota_on (dentry),
+0);
 }
 
 static inline int security_syslog(int type)
 {
-   return security_ops->syslog(type);
+   return COND_SECURITY(syslog(type),
+cap_syslog(type));
 }
 
 static inline int security_settime(struct timespec *ts, struct timezone *tz)
 {
-   return security_ops->settime(ts, tz);
+   

Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Nigel Cunningham]

Ah Jim.

On Tue, 2005-02-15 at 14:38, Jim Crilly wrote:
> I agree boot up is too slow and that some things should be started in the 
> background, but not things that are required for the main purpose of the box 
> to 
> work properly, what should be started sync and what should be async is a hard 
> decision IMO. Right now I use swsusp2 to work around this, it takes less time 
> to resume my session + 500M of file cache than it does to boot manually and 

You warmed my heart until...

> start all of my apps back up, but obviously that's not a real solution.

Why not? :> I guess you mean to the problem of slow booting in the first
place - I would agree with you there, but is there are reason why we
should have booting being the norm instead of normally suspending and
resuming, and only rebooting for new kernels/hardware/etc.

Regards,

Nigel

-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

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

[RCF/RFT] Fix race timer race in gameport-based joystick drivers

[Dmitry Torokhov]

Hi,

There seems to be a race WRT to timer handling in all gameport-based
joystick drivers. open() and close() methods are used to start and
stop polling timers on demand but counter and the timer itself is not
protected in any way so if several clients will try to open/close
corresponding input device node they could up with timer not running
at all or running while nobody has the node open. Plus it is possible
that disconnect will run and free driver structure while timer is running
on other CPU.

I have moved timer and counter down into gameport structure (I think it
is ok because on the one hand joysticks are the only users of gameport
and on the other hand polling timer can be useful to other clients if
ever writen), and added helper functions to manipulate it:

- gameport_start_polling(gameport)
- gameport_stop_polling(gameport)
- gameport_set_poll_handler(gameoirt, handler)
- gameport_set_poll_interval(gameport, msecs)

gameport_{start|stop}_poll handler are using spinlock to guarantee that
timer updated properly. Also, gameport_close deletes (synchronously) timer
to make sure there is no surprises since gameport_stop_poling does del_timer
and thus may leave timer scheduled. Timer routine also checks the counter
and does not restart it if there are no users.

Please let me know what you think.
 
-- 
Dmitry

===

Input: fix race timer handling races in gameport-based joystick drivers
   by moving pollig timer down into gameport and using spinlock to
   protect it.

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


 drivers/input/gameport/gameport.c  |   42 -
 drivers/input/joystick/a3d.c   |   38 ++---
 drivers/input/joystick/adi.c   |   25 +-
 drivers/input/joystick/analog.c|   25 --
 drivers/input/joystick/cobra.c |   28 ++--
 drivers/input/joystick/gf2k.c  |   30 +++---
 drivers/input/joystick/grip.c  |   24 +++--
 drivers/input/joystick/grip_mp.c   |   30 ++
 drivers/input/joystick/guillemot.c |   23 +++-
 drivers/input/joystick/interact.c  |   24 +++--
 drivers/input/joystick/tmdc.c  |   25 --
 include/linux/gameport.h   |   19 
 12 files changed, 165 insertions(+), 168 deletions(-)


Index: dtor/drivers/input/joystick/guillemot.c
===
--- dtor.orig/drivers/input/joystick/guillemot.c
+++ dtor/drivers/input/joystick/guillemot.c
@@ -45,7 +45,6 @@ MODULE_LICENSE("GPL");
 #define GUILLEMOT_MAX_START600 /* 600 us */
 #define GUILLEMOT_MAX_STROBE   60  /* 60 us */
 #define GUILLEMOT_MAX_LENGTH   17  /* 17 bytes */
-#define GUILLEMOT_REFRESH_TIME HZ/50   /* 20 ms */
 
 static short guillemot_abs_pad[] =
{ ABS_X, ABS_Y, ABS_THROTTLE, ABS_RUDDER, -1 };
@@ -69,8 +68,6 @@ struct guillemot_type {
 struct guillemot {
struct gameport *gameport;
struct input_dev dev;
-   struct timer_list timer;
-   int used;
int bads;
int reads;
struct guillemot_type *type;
@@ -120,12 +117,12 @@ static int guillemot_read_packet(struct 
 }
 
 /*
- * guillemot_timer() reads and analyzes Guillemot joystick data.
+ * guillemot_poll() reads and analyzes Guillemot joystick data.
  */
 
-static void guillemot_timer(unsigned long private)
+static void guillemot_poll(struct gameport *gameport)
 {
-   struct guillemot *guillemot = (struct guillemot *) private;
+   struct guillemot *guillemot = gameport_get_drvdata(gameport);
struct input_dev *dev = >dev;
u8 data[GUILLEMOT_MAX_LENGTH];
int i;
@@ -150,8 +147,6 @@ static void guillemot_timer(unsigned lon
}
 
input_sync(dev);
-
-   mod_timer(>timer, jiffies + GUILLEMOT_REFRESH_TIME);
 }
 
 /*
@@ -162,8 +157,7 @@ static int guillemot_open(struct input_d
 {
struct guillemot *guillemot = dev->private;
 
-   if (!guillemot->used++)
-   mod_timer(>timer, jiffies + GUILLEMOT_REFRESH_TIME);
+   gameport_start_polling(guillemot->gameport);
return 0;
 }
 
@@ -175,8 +169,7 @@ static void guillemot_close(struct input
 {
struct guillemot *guillemot = dev->private;
 
-   if (!--guillemot->used)
-   del_timer(>timer);
+   gameport_stop_polling(guillemot->gameport);
 }
 
 /*
@@ -194,9 +187,6 @@ static int guillemot_connect(struct game
return -ENOMEM;
 
guillemot->gameport = gameport;
-   init_timer(>timer);
-   guillemot->timer.data = (long) guillemot;
-   guillemot->timer.function = guillemot_timer;
 
gameport_set_drvdata(gameport, guillemot);
 
@@ -222,6 +212,9 @@ static int guillemot_connect(struct game
goto 

Re: [ANNOUNCE] hotplug-ng 001 release

[Harald Dunkel]

Greg KH wrote:
On Sat, Feb 12, 2005 at 09:30:54AM +0100, Harald Dunkel wrote:
If it is not possible to use klibc together with a non-Linux
system (e.g. FreeBSD or Mach), then I would suggest to make
klibc an optional kernel patch and drop it from udev and
hotplug.

But it is not possible to use udev or hotplug-ng on a non-Linux system,
right?
Thats not the point. The point is to remove the copy of the
klibc sources from packages like udev and hotplug-ng and
to use the existing klibc sources or binaries on the target
system instead. Just to keep it modular.
As far as "optional kernel patch"?  What do you mean?  People are
working on adding klibc to the main kernel tree, nothing optional about
that.
I do not know the internals of klibc that much. Is it possible
to use klibc on non-Linux systems, e.g. on Mach or FreeBSD?
Maybe by adding some #ifdefs to klibc's kernel interface?
If yes, then making klibc an integrated part of the Linux
kernel source tree and dropping the independent development
tree would be a restriction to the use of klibc.
AFAIK the plan for initramfs is to move as much functionality
as possible from kernel to user space. Why not do the same
thing for the sources? Everything that is supposed to be run
in user space could be removed from the kernel source tree
and managed seperately, either in a set of userspace modules
like klibc, hotplug, udev, initramfs, etc., or in a monolithic
"userspace-tools" source tree.
Surely klibc belongs to the user space.
Regards
Harri


signature.asc
Description: OpenPGP digital signature

RE: [BK] upgrade will be needed

[Hua Zhong]

> Linus has never worked on Unix in any form, and most of the 
> other kernel hackers hasn't either. Ever.

Huh? I believe they have used Unix, as in the BitKeeper case. In neither
case they get access to the source code of the software they use, to make
the comparison equal.

Whether they used a *free* Unix (and thus whether they could have been asked
to not go write a clone) is another matter.

Hua
-
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: [BK] upgrade will be needed

[Scott Lockwood]

>
> On 2005-02-14, at 19:17, Matthew Jacob wrote:
> He is simply plain dishonest about his intentions. And since he is
> driving a
> company it's not difficult to deduce what his intentions really are:
> Making money.
> That's plain and simple what all companies are all about.
> Now you can start to guess how he wants to accomplish this.

Excuse me, does this tinfoil hat belong to you? You seem to have droped
it, getting off that short bus over there...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 0/5: LSM hooks rework

[Chris Wright]

* Kurt Garloff ([EMAIL PROTECTED]) wrote:
> this goes back to a discussion in August last year:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0408.1/0623.html

Thanks for follow up Kurt.  I'm travelling at the moment so bear with me
if my response time is slow.  In short, I don't mind switching over to
default capabilities and the consolidation of inline functions.  The
last optimization is pessimistic for case where module is in use, so let's
hold on that one at least as we work out any minor nits with the first
three patches.

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/

[PATCH] Consolidate the last compat sigvals

[Stephen Rothwell]

Hi all,

This patch just consolidates the last of the (what should have been)
compat_sigval_ts.  It worries me that S390 has a sigval_t in its struct
compat_siginfo, but I have left that for now.

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

P.S. this patch has not even been compiled as I don't have acces to any of
the platforms involved, but should be straight forward to fix if it breaks
anything.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/

diff -ruNp linus-waitid.1/arch/ia64/ia32/ia32priv.h 
linus-waitid.2/arch/ia64/ia32/ia32priv.h
--- linus-waitid.1/arch/ia64/ia32/ia32priv.h2005-01-05 17:06:07.0 
+1100
+++ linus-waitid.2/arch/ia64/ia32/ia32priv.h2005-02-15 15:26:42.0 
+1100
@@ -225,11 +225,6 @@ struct stat64 {
unsigned intst_ino_hi;
 };
 
-typedef union sigval32 {
-   int sival_int;
-   unsigned int sival_ptr;
-} sigval_t32;
-
 #define SIGEV_PAD_SIZE32 ((SIGEV_MAX_SIZE/sizeof(int)) - 3)
 
 typedef struct compat_siginfo {
@@ -251,7 +246,7 @@ typedef struct compat_siginfo {
timer_t _tid;   /* timer id */
int _overrun;   /* overrun count */
char _pad[sizeof(unsigned int) - sizeof(int)];
-   sigval_t32 _sigval; /* same as below */
+   compat_sigval_t _sigval;/* same as below */
int _sys_private;   /* not to be passed to user */
} _timer;
 
@@ -259,7 +254,7 @@ typedef struct compat_siginfo {
struct {
unsigned int _pid;  /* sender's pid */
unsigned int _uid;  /* sender's uid */
-   sigval_t32 _sigval;
+   compat_sigval_t _sigval;
} _rt;
 
/* SIGCHLD */
@@ -285,7 +280,7 @@ typedef struct compat_siginfo {
 } compat_siginfo_t;
 
 typedef struct sigevent32 {
-   sigval_t32 sigev_value;
+   compat_sigval_t sigev_value;
int sigev_signo;
int sigev_notify;
union {
diff -ruNp linus-waitid.1/arch/mips/kernel/signal32.c 
linus-waitid.2/arch/mips/kernel/signal32.c
--- linus-waitid.1/arch/mips/kernel/signal32.c  2005-02-04 04:10:36.0 
+1100
+++ linus-waitid.2/arch/mips/kernel/signal32.c  2005-02-15 15:27:37.0 
+1100
@@ -32,11 +32,6 @@
 
 #define SI_PAD_SIZE32   ((SI_MAX_SIZE/sizeof(int)) - 3)
 
-typedef union sigval32 {
-   int sival_int;
-   s32 sival_ptr;
-} sigval_t32;
-
 typedef struct compat_siginfo {
int si_signo;
int si_code;
@@ -89,7 +84,7 @@ typedef struct compat_siginfo {
struct {
compat_pid_t _pid;  /* sender's pid */
compat_uid_t _uid;  /* sender's uid */
-   sigval_t32 _sigval;
+   compat_sigval_t _sigval;
} _rt;
 
} _sifields;
diff -ruNp linus-waitid.1/arch/s390/kernel/compat_linux.h 
linus-waitid.2/arch/s390/kernel/compat_linux.h
--- linus-waitid.1/arch/s390/kernel/compat_linux.h  2005-02-04 
13:05:31.0 +1100
+++ linus-waitid.2/arch/s390/kernel/compat_linux.h  2005-02-15 
15:28:48.0 +1100
@@ -29,11 +29,6 @@ struct old_sigaction32 {
__u32   sa_restorer;/* Another 32 bit pointer */
 };
  
-typedef union sigval32 {
-int sival_int;
-__u32   sival_ptr;
-} sigval_t32;
- 
 typedef struct compat_siginfo {
int si_signo;
int si_errno;
@@ -60,7 +55,7 @@ typedef struct compat_siginfo {
struct {
pid_t   _pid;   /* sender's pid */
uid_t   _uid;   /* sender's uid */
-   sigval_t32  _sigval;
+   compat_sigval_t _sigval;
} _rt;
 
/* SIGCHLD */
diff -ruNp linus-waitid.1/arch/sparc64/kernel/signal32.c 
linus-waitid.2/arch/sparc64/kernel/signal32.c
--- linus-waitid.1/arch/sparc64/kernel/signal32.c   2005-02-04 
04:10:36.0 +1100
+++ linus-waitid.2/arch/sparc64/kernel/signal32.c   2005-02-15 
15:38:14.0 +1100
@@ -104,7 +104,7 @@ typedef struct compat_siginfo{
struct {
timer_t _tid;   /* timer id */
int _overrun;   /* overrun count */
-   sigval_t32 _sigval; /* same as below */
+   compat_sigval_t _sigval;/* same as 
below */
int _sys_private;   /* not to be passed to 
user */
} _timer;
 
@@ -112,7 +112,7 @@ typedef struct compat_siginfo{
struct {
compat_pid_t _pid;  /* sender's pid */

my bk-pci and bk-driver trees are back up

[Greg KH]

Could you put my bk-pci and bk-driver trees back into the next -mm
releases?  They are at:

bk://kernel.bkbits.net/gregkh/linux/pci-2.6
and
bk://kernel.bkbits.net/gregkh/linux/driver-2.6

Respectively.  I've pluled the 64bit resource stuff out of the pci tree,
that was causing a lot of problems.  It's in a separate bk tree for now
(at: bk://kernel.bkbits.net/gregkh/linux/resource-2.6 if anyone cares).

I've also pulled out the pm changes from my driver tree that were
causing the merge issues before, as I see Pavel has started to split
them up better.

For those who want to see patches of this stuff, big ones can be found
at:

PCI patch:

http://www.kernel.org/pub/linux/kernel/people/gregkh/pci/2.6/2.6.11-rc3/bk-pci-2.6.11-rc3-mm1.patch
PCI description:

http://www.kernel.org/pub/linux/kernel/people/gregkh/pci/2.6/2.6.11-rc3/bk-pci-2.6.11-rc3-mm1.patch.desc

64bit resource patch:

http://www.kernel.org/pub/linux/kernel/people/gregkh/pci/2.6/2.6.11-rc3/bk-resource-2.6.11-rc3-mm1.patch
64bit resource description:

http://www.kernel.org/pub/linux/kernel/people/gregkh/pci/2.6/2.6.11-rc3/bk-resource-2.6.11-rc3-mm1.patch.desc

driver patch:

http://www.kernel.org/pub/linux/kernel/people/gregkh/driver_core/2.6/2.6.11-rc4/bk-driver-2.6.11-rc4.patch
driver patch description:

http://www.kernel.org/pub/linux/kernel/people/gregkh/driver_core/2.6/2.6.11-rc4/bk-driver-2.6.11-rc4.patch.desc

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: [BK] upgrade will be needed

[Horst von Brand]

Marcin Dalecki <[EMAIL PROTECTED]> said:
> On 2005-02-14, at 19:56, Larry McVoy wrote:
> > All we are trying to do is
> >
> > 1.  Provide the open source community with a useful tool.
> > 2.  Prevent that from turning into the open source community
> > creating a clone of our tool.

> Now that's pathetic!

> You recognize that point 2. is precisely the reason Linux is all about
> in first place? Remind you: Linux - a free UNIX/POSIX system
> clone done by people who where previously working on UNIX in first place
> and just wanted a free version of it. By definition it is just that...

Linus has never worked on Unix in any form, and most of the other kernel
hackers hasn't either. Ever. It goes so far that at least at IBM people
working on AIX aren't allowed to even look at Linux code, and viceversa.

Please don't spread SCOX type FUD.

> And in this copy-cat community

That sounds dangerously close to diffamation...

>you intend to thrive as "Mother Theresa"
> of SCM?  You still wonder why you provoke disgruntling?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
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 mar, 2005-02-15 at 03:45 +0100, Esben Stien wrote: 
> Jeremy Nickurak <[EMAIL PROTECTED]> writes:
> 
> > 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.
> 
> I'm a little unclear as to what you mean here. Could you elaborate?

I use X.org with the following mouse configuration:

> Section "InputDevice"
> Identifier "Mouse0"
> Driver "mouse"
> Option "Protocol" "evdev"
> Option "Device" "/dev/input/event-mx1000"
> Option "Buttons" "12"
> Option "ZAxisMapping" "11 12"
> Option "Resolution" "800"
> EndSection

With an Xmodmap rule:

> pointer = 1 2 3 8 9 10 11 12 6 7 4 5

This is to make sure that the scroll wheel shows up as 4/5 as expected,
and that the horizontal scroll shows up as 6/7, which most software
interprets as the left/right scroll buttons.

Xev says that the horizontal scrollers produce:

Scroll Left:

> ButtonPress event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334935139, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES
> 
> ButtonPress event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x10, button 5, same_screen YES
> 
> ButtonRelease event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334935155, (88,104), root:(89,150),
> state 0x1010, button 5, same_screen YES
> 
> ButtonRelease event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334935267, (88,104), root:(89,150),
> state 0x10, button 6, same_screen YES

And right:

> ButtonPress event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334935915, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES
> 
> ButtonPress event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x10, button 4, same_screen YES
> 
> ButtonRelease event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334935931, (88,104), root:(89,150),
> state 0x810, button 4, same_screen YES
> 
> ButtonRelease event, serial 29, synthetic NO, window 0xe1,
> root 0x4a, subw 0x0, time 334936027, (88,104), root:(89,150),
> state 0x10, button 7, same_screen YES

I'm being very careful not accidentally press the horizontal scroller
buttons. If there's a different mouse configuration I'm supposed to be
using here, I'd love to hear it. I spent alot of time trying out various
configurations under the 2.6.10 to find one that made everything
(including the cruise control buttons, which still don't work quite
right... see: http://bugzilla.kernel.org/show_bug.cgi?id=1786 ) working.

Various software versions below.

> [EMAIL PROTECTED]:~$ xdpyinfo | grep 'X.Org version'
> X.Org version: 6.8.1.902
> [EMAIL PROTECTED]:~$ uname -a
> Linux agaeris 2.6.11-rc3 #1 Thu Feb 10 23:17:14 MST 2005 i686
> GNU/Linux

-- 
Jeremy Nickurak <[EMAIL PROTECTED]>


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

Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Randy.Dunlap]

Sergio Monteiro Basto wrote:
Hi, don't feel much better but thanks a lot!
in conclusion ? 
1- hdc=ide-scsi, now should be hdc=ide-cd for general cd-writer, because
cdrecorder don't need scsi emulation anymore.
At least partially correct:  don't use "hdc=ide-scsi".
However, I don't use "hdc=ide-cd" and I can burn CDs,
so that's not needed AFAIK.
2- as hdc already is ide-cd by default, therefore is not necessary to
write it and what should be made is erase the line hdc=ide-scsi.
Correct ?
Ah, yes, we seem to agree on that.
HTH.
~Randy
On Mon, 2005-02-14 at 18:25 -0800, Randy.Dunlap wrote:
Sergio Monteiro Basto wrote:
"Use ide-cd and give dev=/dev/hdX as device" 
cracks me up , Can someone translate this to English ?
I'll try.
It means:  don't use the ide-scsi driver.  Support for it is
lagging (not well-maintained) because it's really not needed for
burning CDs.  Just use the ide-cd driver (module) and
specify the CD burner device as /dev/hdX.
Example with cdrecord:
deprecated:
cdrecord -dev=1,0,0 -data backup.iso
modern :)
cdrecord -dev=/dev/hdc -data backup.iso
Do you know how to _not_ use ide-scsi?  Don't load the module
if you have it built as a module, or don't build it into the
kernel boot image.  Mostly don't try to open /dev/sdX, just use
/dev/hdX instead.
Hope you feel better soon.
-
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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Sergio Monteiro Basto]

Hi, don't feel much better but thanks a lot!

in conclusion ? 
1- hdc=ide-scsi, now should be hdc=ide-cd for general cd-writer, because
cdrecorder don't need scsi emulation anymore.

2- as hdc already is ide-cd by default, therefore is not necessary to
write it and what should be made is erase the line hdc=ide-scsi.

Correct ?
 

On Mon, 2005-02-14 at 18:25 -0800, Randy.Dunlap wrote:
> Sergio Monteiro Basto wrote:
> > "Use ide-cd and give dev=/dev/hdX as device" 
> > cracks me up , Can someone translate this to English ?
> 
> I'll try.
> It means:  don't use the ide-scsi driver.  Support for it is
> lagging (not well-maintained) because it's really not needed for
> burning CDs.  Just use the ide-cd driver (module) and
> specify the CD burner device as /dev/hdX.
> 
> Example with cdrecord:
> deprecated:
> cdrecord -dev=1,0,0 -data backup.iso
> modern :)
> cdrecord -dev=/dev/hdc -data backup.iso
> 
> Do you know how to _not_ use ide-scsi?  Don't load the module
> if you have it built as a module, or don't build it into the
> kernel boot image.  Mostly don't try to open /dev/sdX, just use
> /dev/hdX instead.
> 
> Hope you feel better soon.
> 

-- 
Sérgio M.B.

-
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: RTC Inappropriate ioctl for device

[Randy.Dunlap]

Aurélien GÉRÔME wrote:
Hi,
Having CONFIG_RTC=y, I tried on x86 the rtctest program found in
linux-2.6.10/Documentation/rtc.txt. However, it failed at:
ioctl(fd, RTC_UIE_ON, 0);
with:
ioctl: Inappropriate ioctl for device
Did I miss something? Maybe something else conflicts with CONFIG_RTC?
Cheers.
Do you have an HPET timer enabled?  That could cause a conflict.
Does /proc/interrupts report rtc interrupts increasing when you
run rtctest?
I.e., does the number of this line increase like this?
  8:131IO-APIC-edge  rtc
rtctest works for me (2.6.11-rc4).  Maybe send me the strace
output when you run rtctest and your .config file.
Oh, and your kernel boot log, maybe there are some rtc driver
messages in it.
--
~Randy
-
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: Radeon FB troubles with recent kernels

[Vincent C Jones]

In article <[EMAIL PROTECTED]> you write:
>On my Thinkpad T30 with a Radeon Mobility M7 LW, I get interesting
>console video corruption if I start GDM, switch back to text mode,
>then stop it again. X is Xfree86 from Debian/unstable or X.org 6.8.2.
>
>The corruption shows up whenever the console scrolls after X has been
>shut down and manifests as horizontal lines spaced about 4 pixel rows
>apart containing contents recognizable as the X display. Switch from
>vt1 to vt2 and back or visual bell clears things back to normal, but
>corruption will reappear on the next scroll.
>
>This has appeared in at least 2.6.11-rc3-mm2 and rc4.

On my Thinkpad X31 with a Radeon Mobility M6 LY I see a major
regression going from 2.6.11-rc3 to rc4. With rc-4, the frame
buffer console (using "video=radeonfb:[EMAIL PROTECTED]") comes up as
640x480 expanded to 1024x768. The inability of ACPI suspend to turn
off the backlight also returns. Using rc-3, frame buffer console
works fine and suspend/resume appears to work reliably without
needing radeontool to turn off the backlight (as long as I do it
from X.org X).

-- 
Dr. Vincent C. Jones, PE  Expert advice and a helping hand
Computer Network Consultant   for those who want to manage and
Networking Unlimited, Inc.control their networking destiny
Phone: +1 201 568-7810
14 Dogwood Lane, Tenafly, NJ 07670
[EMAIL PROTECTED] http://www.networkingunlimited.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: [BK] upgrade will be needed

[Steven Rostedt]

On Mon, 2005-02-14 at 19:01 -0800, Larry McVoy wrote:

> Would the tarball + patch server suffice for you?  We could make a
> ChangeSet file which had bk changes -v output in it and that would 
> give you a fairly useful set of version information.  For those who
> don't know, bk changes -v is output in time sorted order of changesets
> with the changeset comments then each file's comments like the output
> below.  
> 

This is perfect for me. The only time I've ever used BK was when someone
told me that I needed the lastest snapshot from the bk-tree.  What I do
with the kernel is to port it, write drivers or customize it for
customers. So I'm not in the development part of the kernel (although
I'll report bugs and fixes when I find them). I really believe that the
majority that download the kernel from BK are doing things like I am and
not part of the core development team. 

Currently, I'm working on a customization of Ingo's RT version, so
really at the moment I don't even need access to BK. But with my
previous job, I was downloading the bk version quite a lot. But just to
get the latest updates. So what you have suggested would have been all
that I needed.  As I've mentioned, earlier. I work from job to job and
my needs change with each one. I joined in this discussion because it
could have affected me quite a bit, since someday I might be hired to
work on a SCM tool, and I'm very careful about NDAs and the like.
 
-- Steve

PS - I'm packing up now to drive to Boston. See everyone at
LinuxWorld ;-)



-
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Jim Crilly]

Lee Revell said the following:
The reason I marked by response OT is that the time from power on to
userspace does not seem to be a big problem.  It's the amount of time
from user space to presenting a login prompt that's way too long.  My
distro (Debian) runs all the init scripts one at a time, and GDM is the
last thing that gets run.  There is just no reason for this.  We should
start X and initialize the display and get the login prompt up there
ASAP, and let the system acquire the DHCP lease and start sendmail and
apache and get the date from the NTP server *in the background while I
am logging in*.  It's not rocket science.
That is one of the "features" that I hate most about Windows. All you really do 
is move the delays around. For instance, my Windows machine at work is joined 
to a domain and has the Novell NetWare client installed for NDS auth (don't 
ask) so when the GINA comes up, I hit Ctrl+Alt+Del, enter my password and wait 
staring at an hourglass while the GINA waits for network connectivity to come 
up so that it can authenticate me. And even if authentication was local and I 
got logged in right away, chances are good that I have mapped drives or 
printers on the network that I will have to wait for during the login process 
anyway.

I agree boot up is too slow and that some things should be started in the 
background, but not things that are required for the main purpose of the box to 
work properly, what should be started sync and what should be async is a hard 
decision IMO. Right now I use swsusp2 to work around this, it takes less time 
to resume my session + 500M of file cache than it does to boot manually and 
start all of my apps back up, but obviously that's not a real solution.

Lee
Jim.
-
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/RFC] A method for clearing out page cache

[Paul Jackson]

Questions concerning this page cache patch that Martin submitted,
as a merge of something originally written by Ray Bryant.

The following patch is not really a patch.  It is a few questions, a
couple minor space tweaks, and a never compiled nor tested rewrite of
proc_do_toss_page_cache_nodes() to try to make it look a little
prettier.

Some of the issues are cosmetic, but some I suspect warrant competent
response by Martin or Ray, before this goes into *-mm, such as some
questions as to whether locking is adequate, or a kmalloc() size might
be forced huge by the user.  And my suggested rewrite changes the kernel
API in one error case, so better to decide that matter before it is
too widely used.

Specifically:

  1) A couple of kmalloc's are done using lengths that
 so far as I could tell, came straight from user land.
 Never let the user size a kernel malloc without limit,
 as it makes it way too easy to ask for something huge,
 and give the kernel indigestion.  If the lengths in
 question are actually limited, then nevermind (or comment
 in a terse one-liner, for worry warts such as myself).

  2) Beware that this patch depends on the cpuset patch:
new-bitmap-list-format-for-cpusets.patch
 which is still in *-mm only, for the routines
 bitmap_scnlistprintf/bitmap_parselist.

  3) Should the maxlen of a nodemask for the sysctl
 handler for proc_do_toss_page_cache_nodes be the byte
 length of the kernels internal binary nodemask, or
 a reasonable upper bound on the max length of the
 ascii representation thereof, which is about the value:
100 + 6 * MAX_NUMNODES
 when using the bitmap_scnlistprintf/bitmap_parselist
 format.

  4) A couple of existing blank lines were nuked by this
 patch - I restored them.  I though them to be nice blank lines ;).

  5) The requirement to read the string in one read(2) syscall
 seemed like it might be draconian.  If the available
 apparatus supports it, better to allocate the ascii buffer
 on the open for read, let the reads (and seeks) feast on
 that buffer, using f_pos as it should be used, and freeing
 the buffer on the close.  Mind you, I have no idea if the
 sysctl.c apparatus conveniently supports this.

  6) The kernel header bitops.h is no longer needed by sysctl.c,
 following my (uncompiled, untested) rewrite.

  7) Instead of two counters to track how many threads remained
 to be waited for, toss_done and nodes_to_toss, my rewrite
 just has one: num_toss_threads_active.  It bumps that value
 once each kthread it starts, decrements it as each thread
 finishes, and waits for it to get back to zero in the loop.

  8) Several changes in the rewrite of proc_do_toss_page_cache_nodes():
- rename 'retval' to 'ret' (more common, shorter)
- nuke bitmap and use nodemask routines
- dont error if some nodes offline (general idea is to
either do something useful and claim success, or do
nothing at all, and complain of error, but dont both
do something useful and complain.)
- convert to a single return, at bottom of function
- XXX Comment: doesn't this code require locking node_online_map?
- Remove unused 'started'
- Remove no longer used 'i'
- Remove no longer used 'errors'
- Replace 3 line bitop for loop with one line for_each_node_mask
- Replace 15 lines of 'validity checking' with one line check
  for node being online

  9) Comment - dont we need to protect the kernel global variable
 toss_page_cache_nodes from simulaneous access by two tasks?

Index: 2.6.11-rc4/include/linux/sysctl.h
===
--- 2.6.11-rc4.orig/include/linux/sysctl.h  2005-02-14 18:26:28.0 
-0800
+++ 2.6.11-rc4/include/linux/sysctl.h   2005-02-14 18:27:31.0 -0800
@@ -803,6 +803,7 @@ extern int proc_doulongvec_ms_jiffies_mi
  struct file *, void __user *, size_t *, 
loff_t *);
 extern int proc_dobitmap_list(ctl_table *table, int, struct file *,
  void __user *, size_t *, loff_t *);
+
 extern int do_sysctl (int __user *name, int nlen,
  void __user *oldval, size_t __user *oldlenp,
  void __user *newval, size_t newlen);
Index: 2.6.11-rc4/kernel/sysctl.c
===
--- 2.6.11-rc4.orig/kernel/sysctl.c 2005-02-14 18:26:28.0 -0800
+++ 2.6.11-rc4/kernel/sysctl.c  2005-02-14 18:27:46.0 -0800
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -839,6 +838,8 @@ static ctl_table vm_table[] = {
.ctl_name   = VM_TOSS_PAGE_CACHE_NODES,
.procname   = "toss_page_cache_nodes",
.data   = _page_cache_nodes,
+/* XXX 

X86_64 kernel support MAX memory.

[YhLu]

Andi,

How much is max RAM 2.6.11 x86_64 support on AMD64?
64G or 128G?

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

[Andrew Morton]

Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> you're right something might be different now
>  that we don't follow a swapout virtual address space order anymore

There's a patch in -mm which attempts to do so, and afair, succeeds.

However the performance seems to be crappy.  Its main benefit at present
is in reducing worst-case scheduling latencies (scan_swap_map).

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/broken-out/swapspace-layout-improvements-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 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Paul Jackson]

Ray wrote:
> [Thus the disclaimer in
> the overview note that we have figured all the interaction with
> memory policy stuff yet.]

Does the same disclaimer apply to cpusets?

Unless it causes some undo pain, I would think that page migration
should _not_ violate a tasks cpuset.  I guess this means that a typical
batch manager would move a task to its new cpuset on the new nodes, or
move the cpuset containing some tasks to their new nodes, before asking
the page migrator to drag along the currently allocated pages from the
old location.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: [BK] upgrade will be needed

[Paul Jackson]

Another variation - allow _one_ flip, either way, into or out of BK.
But each flip sets a one year timer within which you can't reverse flip.

 ... just brainstorming ...

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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] Consolidate compat_sys_waitid

[Stephen Rothwell]

Hi all,

This patch does:
- consolidate the three implementations of compat_sys_waitid
  (some were called sys32_waitid).
- adds sys_waitid syscall to ppc
- adds sys_waitid and compat_sys_waitid syscalls to ppc64

Parisc seemed to assume th existance of compat_sys_waitid.  The MIPS
syscall tables have me confused and may need updating.  I have arbitrarily
chosen the next available syscall number on ppc and ppc64, I hope this is
correct.

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

Comments?

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/

diff -ruNp linus-bk/arch/ia64/ia32/ia32_entry.S 
linus-bk-waitid.1/arch/ia64/ia32/ia32_entry.S
--- linus-bk/arch/ia64/ia32/ia32_entry.S2005-01-16 07:07:51.0 
+1100
+++ linus-bk-waitid.1/arch/ia64/ia32/ia32_entry.S   2005-02-15 
12:12:21.0 +1100
@@ -494,7 +494,7 @@ ia32_syscall_table:
data8 compat_sys_mq_notify
data8 compat_sys_mq_getsetattr
data8 sys_ni_syscall/* reserved for kexec */
-   data8 sys32_waitid
+   data8 compat_sys_waitid
 
// guard against failures to increase IA32_NR_syscalls
.org ia32_syscall_table + 8*IA32_NR_syscalls
diff -ruNp linus-bk/arch/ia64/ia32/sys_ia32.c 
linus-bk-waitid.1/arch/ia64/ia32/sys_ia32.c
--- linus-bk/arch/ia64/ia32/sys_ia32.c  2005-02-11 13:05:29.0 +1100
+++ linus-bk-waitid.1/arch/ia64/ia32/sys_ia32.c 2005-02-15 12:16:35.0 
+1100
@@ -2633,32 +2633,6 @@ long sys32_fadvise64_64(int fd, __u32 of
   advice); 
 } 
 
-asmlinkage long sys32_waitid(int which, compat_pid_t pid,
-compat_siginfo_t __user *uinfo, int options,
-struct compat_rusage __user *uru)
-{
-   siginfo_t info;
-   struct rusage ru;
-   long ret;
-   mm_segment_t old_fs = get_fs();
-
-   info.si_signo = 0;
-   set_fs (KERNEL_DS);
-   ret = sys_waitid(which, pid, (siginfo_t __user *) , options,
-uru ? (struct rusage __user *)  : NULL);
-   set_fs (old_fs);
-
-   if (ret < 0 || info.si_signo == 0)
-   return ret;
-
-   if (uru && (ret = put_compat_rusage(, uru)))
-   return ret;
-
-   BUG_ON(info.si_code & __SI_MASK);
-   info.si_code |= __SI_CHLD;
-   return copy_siginfo_to_user32(uinfo, );
-}
-
 #ifdef NOTYET  /* UNTESTED FOR IA64 FROM HERE DOWN */
 
 asmlinkage long sys32_setreuid(compat_uid_t ruid, compat_uid_t euid)
diff -ruNp linus-bk/arch/ppc/kernel/misc.S 
linus-bk-waitid.1/arch/ppc/kernel/misc.S
--- linus-bk/arch/ppc/kernel/misc.S 2005-01-04 17:05:28.0 +1100
+++ linus-bk-waitid.1/arch/ppc/kernel/misc.S2005-02-15 13:12:01.0 
+1100
@@ -1450,3 +1450,4 @@ _GLOBAL(sys_call_table)
.long sys_add_key
.long sys_request_key   /* 270 */
.long sys_keyctl
+   .long sys_waitid
diff -ruNp linus-bk/arch/ppc64/kernel/misc.S 
linus-bk-waitid.1/arch/ppc64/kernel/misc.S
--- linus-bk/arch/ppc64/kernel/misc.S   2005-01-16 07:07:51.0 +1100
+++ linus-bk-waitid.1/arch/ppc64/kernel/misc.S  2005-02-15 13:13:51.0 
+1100
@@ -939,6 +939,7 @@ _GLOBAL(sys_call_table32)
.llong .sys32_add_key
.llong .sys32_request_key
.llong .compat_sys_keyctl
+   .llong .compat_sys_waitid
 
.balign 8
 _GLOBAL(sys_call_table)
@@ -1214,3 +1215,4 @@ _GLOBAL(sys_call_table)
.llong .sys_add_key
.llong .sys_request_key /* 270 */
.llong .sys_keyctl
+   .llong .sys_waitid
diff -ruNp linus-bk/arch/sparc64/kernel/sys_sparc32.c 
linus-bk-waitid.1/arch/sparc64/kernel/sys_sparc32.c
--- linus-bk/arch/sparc64/kernel/sys_sparc32.c  2005-02-11 13:05:29.0 
+1100
+++ linus-bk-waitid.1/arch/sparc64/kernel/sys_sparc32.c 2005-02-15 
12:01:55.0 +1100
@@ -1653,34 +1653,3 @@ sys32_timer_create(u32 clock, struct sig
 
return err;
 }
-
-asmlinkage long compat_sys_waitid(u32 which, u32 pid,
- struct compat_siginfo __user *uinfo,
- u32 options, struct compat_rusage __user *uru)
-{
-   siginfo_t info;
-   struct rusage ru;
-   long ret;
-   mm_segment_t old_fs = get_fs();
-
-   memset(, 0, sizeof(info));
-
-   set_fs (KERNEL_DS);
-   ret = sys_waitid(which, pid, (siginfo_t __user *) ,
-options,
-uru ? (struct rusage __user *)  : NULL);
-   set_fs (old_fs);
-
-   if (ret < 0 || info.si_signo == 0)
-   return ret;
-
-   if (uru) {
-   ret = put_compat_rusage(, uru);
-   if (ret)
-   return ret;
-   }
-
-   BUG_ON(info.si_code & __SI_MASK);
-   info.si_code |= __SI_CHLD;
-   return copy_siginfo_to_user32(uinfo, );
-}
diff -ruNp linus-bk/arch/x86_64/ia32/ia32entry.S 

Re: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 08:00:59PM -0500, Steven Rostedt wrote:
> I guess you are dealing with three groups of people.
> 
> 1) The ones paying you. The companies that spend money to get things
> done.  -- Needs full version of BK.

Agreed.

> 2) The Open Source developers, Linus and others that like BK and will
> work with it with whatever license you give it. -- Needs strong version
> of BK. Probably no more than 100 users (or less).

We could handle these guys by selling/donating commercial seats.
But while we started out with the goal of helping the Linux effort,
specifically Linus, other open source projects have gotten past
the license and found value in the product: mysql, xaraya, xen, etc.
Whatever we do we can't do anything which would disrupt their efforts,
that's not reasonable.

> 3) The Open Source users, tweakers, hackers that are not the core
> developers. -- Needs only to checkout the kernel. Probably over 1000
> users.  I fall in this category.

Would the tarball + patch server suffice for you?  We could make a
ChangeSet file which had bk changes -v output in it and that would 
give you a fairly useful set of version information.  For those who
don't know, bk changes -v is output in time sorted order of changesets
with the changeset comments then each file's comments like the output
below.  

This server wouldn't be much use for someone trying to track down the
source of a bug, you'd really need the BK2CVS tree for that or a BK
tree.  In some ways, the BK2CVS tree is far nicer because you can do
binary search on it, but as Roman/Pavel/et al have pointed out sometimes
the commits in the CVS tree are too coarse if the cset you want is a
merge of 20 changesets on a branch.  In that case you want the BK tree.

But for people trying to easily track the head the tarball server might
be just the ticket.  Erik (codepoet guy) would probably love it (right?).
If it would help people feel better about us and/or make their lives easier
we can set up that server for all the repos on bkbits.net.  I suspect
that it would help at least some people out there.

--lm

[EMAIL PROTECTED], 2005-02-14 18:09:02+00:00, [EMAIL PROTECTED]
+3 -0
  [ARM] Fix sparse warnings for Integrator builds.
  
  Add some missing __iomem annotations for Integrator machines.
  
  Signed-off-by: Russell King <[EMAIL PROTECTED]>

  arch/arm/mach-integrator/[EMAIL PROTECTED], 2005-02-14 18:03:31+00:00, [EMAIL 
PROTECTED] .linux.org.uk +1 -1
Add sparse __iomem annotations.

  arch/arm/mach-integrator/[EMAIL PROTECTED], 2005-02-14 18:03:31+00:00, [EMAIL 
PROTECTED]  linux.org.uk +4 -4
Add sparse __iomem annotations.
Use "dev" rather than "rtc_base" for the device id when requesting
the RTC interrupt.

  drivers/input/serio/[EMAIL PROTECTED], 2005-02-14 18:03:31+00:00, [EMAIL 
PROTECTED] inux.org.uk +1 -1
Add sparse __iomem annotations.


> This is why we have asked about three versions. Obviously, Linus and
> friends are the most important part for the Linux community, so even if
> it hurts 2000 other people that only want to download the lastest
> snapshots from BK, it really doesn't matter.  Let us complain, but
> unless Linus decides to go elsewhere, we are stuck.  So don't do the
> crippled version if it hurts Linus.
> 
> -- Steve
> 

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

[Esben Stien]

Jeremy Nickurak <[EMAIL PROTECTED]> writes:

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

I'm a little unclear as to what you mean here. Could you elaborate?

-- 
Esben Stien is [EMAIL PROTECTED]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[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: Please open sysfs symbols to proprietary modules

[Alan Cox]

> You shouldn't, although many people do.  It's a derived work and hence the
> GPL is applicable.  The only exception we make is for code which was
> written for other operating systems and was then ported to Linux. 

As one of the copyright holders I make no such exception. Its either a
derived work in law or its not. In the former case obey the license or
remove every line of code derived from anything I wrote.

If it's not a derived work then fine. If you aren't sure ask your
lawyer.

[Sorry I'm sort of obliged to reply to this comment to prove I'm
defending my
 copyrights and not accepting various positions Linus and others may
claim
 exist. I believe others like the FSF whose code is used in the kernel
have 
 similar views]

Alan

-
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: [BK] upgrade will be needed

[Tristan Wibberley]

On Mon, 14 Feb 2005 19:54:14 +0100, Juergen Stuber wrote:

> g BK, I can immediately start working on another SCM
> but I can't go back to BK immediately

IMHO, it should be the other way around, and more like two years, then you
can buy back time at something like 1/12th full BK license price per month
that you want less than the two years. Two years would be more appropriate
since you need to make sure that coders who've worked on the other SCM
before are well and truly out of touch with the code when they go back.
With that scheme, if you have a serious business case for writing a new
SCM *today* you just have to factor an extra cost into your plans (double
BK license), and if you want to work on an open source one, you just have
to wait while BitMover gets another two years on their head-start. Now
only people with determined plans can switch from using BK to working on
an SCM, and BitMover can get new users benefiting from their kindness and
lifting their market penetration as easily as possible.

-- 
Tristan Wibberley

-
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: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 09:13:14PM -0500, Ed Tomlinson wrote:
> > The way some people are reading the license the price is even higher,
> > they think it is a forever tainted license as it stands today.  I've had
> > specific requests to clarify this part of the license.
> > 
> > So how would you suggest that we resolve it?  The protection we need is
> > that people don't get to
> 
> How about just reversing it.  If you work on another scm you cannot use
> _free_ bk for 1 year after you stop. 

Hi Ed, thanks for the thought.  We've discussed this idea before with
some managers of open source developers and found that no matter which
one we pick some people don't like it.  People tend to cluster up based on
whether they value working on $SCM more or using BK more.  If they want to
preserve the ability to move people to working on competing products then
they would like the option you suggested.  If they are more interested
in using BK then they would prefer the other way.  The people we spoke
with were far more interested in the ability to move people onto BK when
they needed to.

But it's a good idea and we'd certainly be willing to flip to your way
on a case by case basis.
-- 
---
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: Logitech MX1000 Horizontal Scrolling

[Esben Stien]

Vojtech Pavlik <[EMAIL PROTECTED]> writes:

> Please try if 2.6.11-rc3 is any better.

Yes, nice, the error is gone and I've verified with blender that the
horizontal scroll works as it should;).

Firefox gives me something strange, but the kernel issue is resolved.

I'll explain what firefox gives me, in case you're interested, but
I'll take this issue over to the firefox mailinglist.

I'm using xbindkeys to set up what the mouse is supposed to do:

"xvkbd -xsendevent -text "\[Left]""
  b:11

"xvkbd -xsendevent -text "\[Right]""
  b:12

#11 = HORIZONTAL LEFT
#12 = HORIZONTAL RIGHT

With this config, it is supposed to scroll in the horizontal direction
when keys 11/12 are pressed/moved/tilted.

Now, in firefox, I tilt the wheel in the right direction. It moves one
cm to the right, but then proceeds to move up and it continues to do
so until it reaches the top of the page or I release the button. 

It is supposed to just move right, of course, as long as the tilt
wheel is not released and there is more data in the right direction. 

-- 
Esben Stien is [EMAIL PROTECTED]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Randy.Dunlap]

Sergio Monteiro Basto wrote:
for the google archives :
I work with Linux more than 10 years and this messages are a great
sheet ! I can't understand a thing of the fuck is going in the mind of
the author.
"Use ide-cd and give dev=/dev/hdX as device" 
cracks me up , Can someone translate this to English ?
I'll try.
It means:  don't use the ide-scsi driver.  Support for it is
lagging (not well-maintained) because it's really not needed for
burning CDs.  Just use the ide-cd driver (module) and
specify the CD burner device as /dev/hdX.
Example with cdrecord:
deprecated:
cdrecord -dev=1,0,0 -data backup.iso
modern :)
cdrecord -dev=/dev/hdc -data backup.iso
Do you know how to _not_ use ide-scsi?  Don't load the module
if you have it built as a module, or don't build it into the
kernel boot image.  Mostly don't try to open /dev/sdX, just use
/dev/hdX instead.
Hope you feel better soon.

reading man fstab-sync we get 

 --add=UDI
Add an entry to the /etc/fstab file by giving a HAL Unique Device
Identifier
no fucking example of the fuck is one UDI !
here is my /var/log/message after a reboot the cdwriter still no
working.
A fucking example could be a great help !
Feb 15 01:41:44 bastov su(pam_unix)[5370]: session opened for user root by 
sergio(uid=500)
Feb 15 01:55:51 bastov kernel: SCSI subsystem initialized
Feb 15 01:55:51 bastov kernel: ide-scsi is deprecated for cd burning! Use 
ide-cd and give dev=/dev/hdX as device
Feb 15 01:55:51 bastov kernel: scsi0 : SCSI host adapter emulation for IDE 
ATAPI devices
Feb 15 01:55:51 bastov kernel:   Vendor: HPModel: CD-Writer+ 8200   
Rev: 1.0f
Feb 15 01:55:51 bastov kernel:   Type:   CD-ROM 
ANSI SCSI revision: 02
Feb 15 01:55:51 bastov hald[4294]: Timed out waiting for hotplug event 701. 
Rebasing to 705
Feb 15 01:55:51 bastov scsi.agent[5621]: cdrom at 
/devices/pci:00/:00:1f.1/ide1/1.0/host0/target0:0:0/0:0:0:0
Feb 15 01:55:51 bastov kernel: ide-scsi: Warning this device driver is only 
intended for specialist devices.
Feb 15 01:55:51 bastov kernel: ide-scsi: Do not use for cd burning, use 
/dev/hdX directly instead.
Feb 15 01:55:51 bastov kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw 
xa/form2 cdda tray
Feb 15 01:55:51 bastov kernel: ide-scsi: unsup command: dev hdc: flags = 
REQ_CMD REQ_STARTED
Feb 15 01:55:51 bastov kernel: sector 0, nr/cnr 1/1
Feb 15 01:55:51 bastov kernel: bio c06558c0, biotail c06558c0, buffer c601f000, 
data , len 0
Feb 15 01:55:51 bastov kernel: end_request: I/O error, dev hdc, sector 0
Feb 15 01:55:51 bastov kernel: FAT: unable to read boot sector
Feb 15 01:55:51 bastov kernel: Unable to handle kernel NULL pointer dereference 
at virtual address 
Feb 15 01:55:51 bastov kernel:  printing eip:
Feb 15 01:55:51 bastov kernel: c01d5fac
Feb 15 01:55:51 bastov kernel: *pde = 
Feb 15 01:55:51 bastov kernel: Oops:  [#1]
Feb 15 01:55:51 bastov kernel: Modules linked in: sr_mod ide_scsi scsi_mod md5 
ipv6 parport_pc lp parport autofs4sunrpc pcmcia yenta_socket pcmcia_core 
microcode vfat fat dm_mod video button battery ac uhci_hcd hw_random i2c_i801 
i2c_core snd_ens1371 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss 
snd_mixer_oss snd_pcm snd_timer sndsoundcore snd_page_alloc gameport 3c59x 
floppy ext3 jbd
Feb 15 01:55:51 bastov kernel: CPU:0
Feb 15 01:55:51 bastov kernel: EIP:0060:[]Not tainted VLI
Feb 15 01:55:51 bastov kernel: EFLAGS: 00210286   (2.6.10-1.760_FC3)
Feb 15 01:55:51 bastov kernel: EIP is at get_kobj_path_length+0x10/0x25
Feb 15 01:55:51 bastov kernel: eax:    ebx: 0001   ecx:    
edx: d3dd5490
Feb 15 01:55:51 bastov kernel: esi:    edi:    ebp: d3dd5490   
esp: c0e74e44
Feb 15 01:55:51 bastov kernel: ds: 007b   es: 007b   ss: 0068
Feb 15 01:55:51 bastov kernel: Process mount (pid: 5559, threadinfo=c0e74000 
task=ca144e50)
Feb 15 01:55:51 bastov kernel: Stack: 00d0 0005 c01d6016 0005 
d2419400  0005 d499fec0
Feb 15 01:55:51 bastov kernel:c01d6716 fff4 d2419400 d2a7c2c0 
d499fec0 d499fec0 c01d67c1 00d0
Feb 15 01:55:51 bastov kernel:c01689ed d2419440 d2419400 c01670b5 
fffb fffb d2a7c2c0 c01689b0
Feb 15 01:55:51 bastov kernel: Call Trace:
Feb 15 01:55:51 bastov kernel:  [] kobject_get_path+0xe/0x4a
Feb 15 01:55:51 bastov kernel:  [] do_kobject_uevent+0x19/0xba
Feb 15 01:55:51 bastov kernel:  [] kobject_uevent+0xa/0xc
Feb 15 01:55:51 bastov kernel:  [] kill_block_super+0x16/0x30
Feb 15 01:55:51 bastov kernel:  [] deactivate_super+0xc8/0xdd
Feb 15 01:55:51 bastov kernel:  [] get_sb_bdev+0xf1/0x118
Feb 15 01:55:51 bastov kernel:  [] selinux_sb_copy_data+0x33/0x159
Feb 15 01:55:51 bastov kernel:  [] vfat_get_sb+0xe/0x11 [vfat]
Feb 15 01:55:51 bastov kernel:  [] vfat_fill_super+0x0/0x36 [vfat]
Feb 15 01:55:51 bastov kernel:  [] do_kern_mount+0x8a/0x13a
Feb 15 01:55:51 bastov kernel:  [] do_new_mount+0x61/0x90
Feb 15 01:55:51 bastov kernel:  [] 

Re: Repeatable hang with XFS under 2.6.11-rc4

[Nathan Scott]

Hi Peter,

On Tue, Feb 15, 2005 at 12:49:45PM +1100, Peter Chubb wrote:
> Running Reaim-7 on a 4G ram disk with 4 processors on
> Itanium... Every few runs, as the multiprocessing level increases, we
> see 22 processes hung in sync(), all except one waiting in
> sync_filesystems() and that one waiting in pagebuf_iowait().

That would indicate either XFS dropped the IO completion for a
metadata buffer, or the driver didn't pass it back to us.  Hard
to say which; is this with default mkfs options?  If so, try
using -ssize=4k at mkfs time, that'll get rid of some of the
more unusual IO patterns which XFS can send down.  Also try a
blocksize the same as the pagesize (16K there I would guess).
If the behaviour changes, these'll give us pointers and help
isolate where the problem is.

cheers.

-- 
Nathan
-
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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Sergio Monteiro Basto]

for the google archives :

I work with Linux more than 10 years and this messages are a great
sheet ! I can't understand a thing of the fuck is going in the mind of
the author.

"Use ide-cd and give dev=/dev/hdX as device" 
cracks me up , Can someone translate this to English ?

reading man fstab-sync we get 

 --add=UDI
Add an entry to the /etc/fstab file by giving a HAL Unique Device
Identifier

no fucking example of the fuck is one UDI !

here is my /var/log/message after a reboot the cdwriter still no
working.
A fucking example could be a great help !

Feb 15 01:41:44 bastov su(pam_unix)[5370]: session opened for user root by 
sergio(uid=500)
Feb 15 01:55:51 bastov kernel: SCSI subsystem initialized
Feb 15 01:55:51 bastov kernel: ide-scsi is deprecated for cd burning! Use 
ide-cd and give dev=/dev/hdX as device
Feb 15 01:55:51 bastov kernel: scsi0 : SCSI host adapter emulation for IDE 
ATAPI devices
Feb 15 01:55:51 bastov kernel:   Vendor: HPModel: CD-Writer+ 8200   
Rev: 1.0f
Feb 15 01:55:51 bastov kernel:   Type:   CD-ROM 
ANSI SCSI revision: 02
Feb 15 01:55:51 bastov hald[4294]: Timed out waiting for hotplug event 701. 
Rebasing to 705
Feb 15 01:55:51 bastov scsi.agent[5621]: cdrom at 
/devices/pci:00/:00:1f.1/ide1/1.0/host0/target0:0:0/0:0:0:0
Feb 15 01:55:51 bastov kernel: ide-scsi: Warning this device driver is only 
intended for specialist devices.
Feb 15 01:55:51 bastov kernel: ide-scsi: Do not use for cd burning, use 
/dev/hdX directly instead.
Feb 15 01:55:51 bastov kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw 
xa/form2 cdda tray
Feb 15 01:55:51 bastov kernel: ide-scsi: unsup command: dev hdc: flags = 
REQ_CMD REQ_STARTED
Feb 15 01:55:51 bastov kernel: sector 0, nr/cnr 1/1
Feb 15 01:55:51 bastov kernel: bio c06558c0, biotail c06558c0, buffer c601f000, 
data , len 0
Feb 15 01:55:51 bastov kernel: end_request: I/O error, dev hdc, sector 0
Feb 15 01:55:51 bastov kernel: FAT: unable to read boot sector
Feb 15 01:55:51 bastov kernel: Unable to handle kernel NULL pointer dereference 
at virtual address 
Feb 15 01:55:51 bastov kernel:  printing eip:
Feb 15 01:55:51 bastov kernel: c01d5fac
Feb 15 01:55:51 bastov kernel: *pde = 
Feb 15 01:55:51 bastov kernel: Oops:  [#1]
Feb 15 01:55:51 bastov kernel: Modules linked in: sr_mod ide_scsi scsi_mod md5 
ipv6 parport_pc lp parport autofs4sunrpc pcmcia yenta_socket pcmcia_core 
microcode vfat fat dm_mod video button battery ac uhci_hcd hw_random i2c_i801 
i2c_core snd_ens1371 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss 
snd_mixer_oss snd_pcm snd_timer sndsoundcore snd_page_alloc gameport 3c59x 
floppy ext3 jbd
Feb 15 01:55:51 bastov kernel: CPU:0
Feb 15 01:55:51 bastov kernel: EIP:0060:[]Not tainted VLI
Feb 15 01:55:51 bastov kernel: EFLAGS: 00210286   (2.6.10-1.760_FC3)
Feb 15 01:55:51 bastov kernel: EIP is at get_kobj_path_length+0x10/0x25
Feb 15 01:55:51 bastov kernel: eax:    ebx: 0001   ecx:    
edx: d3dd5490
Feb 15 01:55:51 bastov kernel: esi:    edi:    ebp: d3dd5490   
esp: c0e74e44
Feb 15 01:55:51 bastov kernel: ds: 007b   es: 007b   ss: 0068
Feb 15 01:55:51 bastov kernel: Process mount (pid: 5559, threadinfo=c0e74000 
task=ca144e50)
Feb 15 01:55:51 bastov kernel: Stack: 00d0 0005 c01d6016 0005 
d2419400  0005 d499fec0
Feb 15 01:55:51 bastov kernel:c01d6716 fff4 d2419400 d2a7c2c0 
d499fec0 d499fec0 c01d67c1 00d0
Feb 15 01:55:51 bastov kernel:c01689ed d2419440 d2419400 c01670b5 
fffb fffb d2a7c2c0 c01689b0
Feb 15 01:55:51 bastov kernel: Call Trace:
Feb 15 01:55:51 bastov kernel:  [] kobject_get_path+0xe/0x4a
Feb 15 01:55:51 bastov kernel:  [] do_kobject_uevent+0x19/0xba
Feb 15 01:55:51 bastov kernel:  [] kobject_uevent+0xa/0xc
Feb 15 01:55:51 bastov kernel:  [] kill_block_super+0x16/0x30
Feb 15 01:55:51 bastov kernel:  [] deactivate_super+0xc8/0xdd
Feb 15 01:55:51 bastov kernel:  [] get_sb_bdev+0xf1/0x118
Feb 15 01:55:51 bastov kernel:  [] selinux_sb_copy_data+0x33/0x159
Feb 15 01:55:51 bastov kernel:  [] vfat_get_sb+0xe/0x11 [vfat]
Feb 15 01:55:51 bastov kernel:  [] vfat_fill_super+0x0/0x36 [vfat]
Feb 15 01:55:51 bastov kernel:  [] do_kern_mount+0x8a/0x13a
Feb 15 01:55:51 bastov kernel:  [] do_new_mount+0x61/0x90
Feb 15 01:55:51 bastov kernel:  [] do_mount+0x178/0x190
Feb 15 01:55:51 bastov kernel:  [] __alloc_pages+0xac/0x28e
Feb 15 01:55:51 bastov kernel:  [] sys_mount+0x6a/0xbd
Feb 15 01:55:51 bastov kernel:  [] syscall_call+0x7/0xb
Feb 15 01:55:51 bastov kernel: Code: 75 14 89 d8 e8 9a ff ff ff 85 c0 89 c6 74 
07 89 d8 e8 4e c9 fc ff 5b 89 f0 5e c3 57 89 c2 53 bb 01 00 00 00 8b 3a 31 c0 
83 c9 ff  ae f7 d1 49 8b 52 24 8d 5c 0b 01 85 d2 75 e9 89 d8 5b 5fc3
Feb 15 01:55:56 bastov fstab-sync[5755]: added mount point /media/cdrecorder 
for /dev/scd0






On Tue, 2005-02-15 at 00:20 +, Sergio Monteiro Basto wrote:
> What this message means ?
> 
> instead 

Re: aacraid fails under kernel 2.6

[Alan Cox]

On Gwe, 2005-02-11 at 14:28, Jonathan Knight wrote:
> Fedora and the 2.6 kernel nothing has worked well.  The latest 2.6.10 build
> is the worst so far.  We've even gone and unpacked the rc3 for 2.6.11 and
> dug out the aacraid controller but that didn't perform any better.  We think
> 2.6.8 was the most usable of the 2.6's so far.

Fedora 2.6.10 or the base 2.6.10. The base 2.6.10 is missing at least
one aacraid fix.

-
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: [BK] upgrade will be needed

[Ed Tomlinson]

On Monday 14 February 2005 10:40, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 10:08:20AM -0500, Jeff Sipek wrote:
> > On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy <[EMAIL PROTECTED]> wrote:
> > > > is to clarify the non-compete stuff.  We've had some people who have
> > > > indicated that they believed that if they used BK they were agreeing
> > > > that they would never work on another SCM system.  We can see how it
> > > > is possible that people would interpret the license that way but that
> > > > wasn't our intent.  What we would like to do is change the language to
> > > > say that if you use BK you are agreeing that you won't work on another
> > > > SCM for 1 year after you stop using BK.  But after that you would be
> > > 
> > > I don't even plan working on some SCM system, but being
> > > tainted for 1 year for just *using* BK is not worth the price IMHO.
> > 
> > I agree, the price is just too high. No matter how much I like BK, I
> > would give it up.
> 
> The way some people are reading the license the price is even higher,
> they think it is a forever tainted license as it stands today.  I've had
> specific requests to clarify this part of the license.
> 
> So how would you suggest that we resolve it?  The protection we need is
> that people don't get to

How about just reversing it.  If you work on another scm you cannot use
_free_ bk for 1 year after you stop. 

Ed Tomlinson


> - use BK
> - stop using BK so they can go work on another system
> - start using BK again
> - stop using BK so they can go work on another system
> ...
> 
> We could say that if you stop using BK and work on another system then
> you can't ever use it again.  We're not going to do that, we've already
> had to calm the fears of people who found themselves in that situation
> for their job.  
> 
> So what do you want us to do?  This isn't a change to take stuff from
> you, it's a change that some of your peers asked us to do so they could
> use BK (and it would be nice if the people who wanted this are reading
> this thread and will speak up so it doesn't look like I'm making it up).
> 
> What we've been doing so far is telling people who were worried to act as
> if there were a year long gap and they have been happy with that answer
> but they are asking for us to put it in the license so they don't have
> to depend on some email based side agreement.
> 
> It would be nice if you could talk this over amongst yourselves and
> suggest an answer.  I can see why you think it is a bad change, I'm hoping
> that you can see why other people may want us to make this sort of change.
> Maybe if you think about it a bit you'll come up with a better solution.
> Or maybe we will.  Either way, I can't be very involved in the process,
> I'm taking off for a week long vacation starting Wednesday and I won't
> have email access.  Which will be a good way to make sure that if this 
> turns into a flame war I won't be prolonging 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: avoiding pci_disable_device()...

[Jeff Garzik]

Arjan van de Ven wrote:
No.  You also need to consider situations such as out-of-tree drivers 
for the same hardware (might not use PCI API), and situations where you 
have peer devices discovered and used (PCI API doesn't have "hey,  
device is associated with , too" capability)

there's not a lot you or anyone else can do about such broken (and often
proprietary) drivers if a device doesn't use the kernel API's its
end of game basically. Adding more new API's isn't going to help you ...

This specific instance isn't about adding a new API, but using an 
existing one correctly.

If pci_request_regions() fails, that implies another driver is using the 
kernel API to let you know the region is unavailable.  You should honor 
that, by not disabling the hardware in that case.

Jeff
-
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: Pty is losing bytes

[Alex Davis]

Problem does not exist on 2.6.8.1. Compiling your program and running

./a.out < README | diff README -

produces no output.

I tested various files ranging in size from 10 to 60k.

-Alex


=
I code, therefore I am



__ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
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/

Repeatable hang with XFS under 2.6.11-rc4

[Peter Chubb]

Running Reaim-7 on a 4G ram disk with 4 processors on
Itanium... Every few runs, as the multiprocessing level increases, we
see 22 processes hung in sync(), all except one waiting in
sync_filesystems() and that one waiting in pagebuf_iowait().

There's lots of free memory, the ram-disk is not full, ...
Load average is low; nothing in the logs or on the console.

[EMAIL PROTECTED]:/proc# vmstat 2 
procs ---memory-- ---swap-- -io --system-- cpu
 r  b   swpd   free   buff  cache   si   sobibo   incs us sy id wa
 0  0 0 23027552 1091472 218496  00 1 42107   12 6 1 21 78  0
 0  0 0 23027552 1091472 218496  00 0 0 411010 0  0 100 0
 0  0 0 23027552 1091472 218496  00 0 0 4109 8 0  0 100 0
 0  0 0 23027488 1091472 218496  00 032 411415 0  0 100 0
 0  0 0 23027488 1091472 218496  00 0 0 4110 9 0  0 100 0
 0  0 0 23027488 1091472 218496  00 0 0 4109 9 0  0 100 0
 
[EMAIL PROTECTED]:/proc/fs/xfs# df /mnt/ram-disk
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/ram1  1038336127800910536  13% /mnt/ram-disk


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

Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Kyle Moffett]

On Feb 14, 2005, at 20:17, Lee Revell wrote:
On Mon, 2005-02-14 at 16:16 -0800, Tim Bird wrote:
Lee Revell wrote:
But, I was referring more to things like GDM not being started until 
all
the other init scripts are done.  Why not start it first, and let the
network initialize while the user is logging in?
There are a number of techniques used by CE vendors to get fast bootup
time.  Some CE products boot Linux in under 1 second.  Sony's
best Linux boot time in the lab (from power on to user space)
was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).
The reason I marked by response OT is that the time from power on to
userspace does not seem to be a big problem.  It's the amount of time
from user space to presenting a login prompt that's way too long.  My
distro (Debian) runs all the init scripts one at a time, and GDM is the
last thing that gets run.  There is just no reason for this.  We should
start X and initialize the display and get the login prompt up there
ASAP, and let the system acquire the DHCP lease and start sendmail and
apache and get the date from the NTP server *in the background while I
am logging in*.  It's not rocket science.
Such a system needs a drastically different bootup process than 
currently
exists, including the ability to specify init-script dependencies.  
(Like
for example user login via GDM (and with our setup, GDM working at all)
requires that AFS is mounted and NIS is working, which both require the
network to be available, which requires...  You can see where this is
going.  I think eventually we need a better /sbin/init, one that can use
a traditional legacy /etc/inittab file in addition to a newfangled
simultaneous boot process with lots of ways to start various kinds of
services.  Unfortunately such a system will need a _LOT_ of work and
testing to make sure it doesn't break existing setups.  Oh well, I can
dream, can't I? :-D

Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

-
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: avoiding pci_disable_device()...

[Arjan van de Ven]

> No.  You also need to consider situations such as out-of-tree drivers 
> for the same hardware (might not use PCI API), and situations where you 
> have peer devices discovered and used (PCI API doesn't have "hey,  
> device is associated with , too" capability)


there's not a lot you or anyone else can do about such broken (and often
proprietary) drivers if a device doesn't use the kernel API's its
end of game basically. Adding more new API's isn't going to help you ...



-
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: [BK] upgrade will be needed

[David Lang]

On Mon, 14 Feb 2005 [EMAIL PROTECTED] wrote:
this does mean that there would be somehat of a commiter/non-commiter
split, with the difference between them being those who agree to the
non-compete license of #1 and those who don't and use #2 to have a local
read-only copy and have to use normal patches to submit changes up the
tree.
And how does the CVS gateway not provide this today?  We effectively
have exactly what you are describing.  And long ago I offered what I
called the tarball + patch server with an open source client for all
trees on bkbits.net - here it is:  http://lkml.org/lkml/2003/12/14/47
If people had stopped flaming long enough to look at that it would
be installed on bkbits today and any repo hosted there would have an
automatic real-time gateway with no license problems.  Heck, we could
even export the changeset comments into ChangeLog as Keith suggested
here: http://lkml.org/lkml/2003/12/14/92 .
the advantage over CVS would be the reduced network useage (both server 
side and client side), but that's not worth the development costs you are 
quoting.

since I don't have any problem with your license I had forgotten about 
that other option. I was just trying to clarify what looked like a 
misunderstanding of what was being asked and exploring options to reduce 
the flaming.

People didn't seem interested and I came with the conclusion, rightly or
wrongly, that the vast majority of the people who did real work didn't
care about the license and the noisy people just wanted to pick a fight.
If I was wrong and this is valuable I can look into putting it up on
bkbits.net.
unfortunantly, you are probably right :-(
David Lang
--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Lee Revell]

On Mon, 2005-02-14 at 16:16 -0800, Tim Bird wrote:
> Lee Revell wrote:
> > But, I was referring more to things like GDM not being started until all
> > the other init scripts are done.  Why not start it first, and let the
> > network initialize while the user is logging in?
> 
> There are a number of techniques used by CE vendors to get fast bootup
> time.  Some CE products boot Linux in under 1 second.  Sony's
> best Linux boot time in the lab (from power on to user space)
> was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).

The reason I marked by response OT is that the time from power on to
userspace does not seem to be a big problem.  It's the amount of time
from user space to presenting a login prompt that's way too long.  My
distro (Debian) runs all the init scripts one at a time, and GDM is the
last thing that gets run.  There is just no reason for this.  We should
start X and initialize the display and get the login prompt up there
ASAP, and let the system acquire the DHCP lease and start sendmail and
apache and get the date from the NTP server *in the background while I
am logging in*.  It's not rocket science.

Lee

-
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 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Steve Longerbeam]

Andi Kleen wrote:
For our use, the batch scheduler will give an intermediary program a
list of processes and a series of from-to node pairs.  That process would
then ensure all the processes are stopped, scan their VMAs to determine
what regions are mapped by more than one process, which are mapped
by additional processes not in the job, and make this system call for
each of the unique ranges in the job to migrate their pages from one
node to the next.  I believe Ray is working on a library and a standalone
program to do this from a command line.
   

Sounds quite ugly. 

Do you have evidence that this is a common use case? (jobs having stuff
mapped from programs not in the job). If not I think it's better
to go with a simple interface, not one that is unusable without
a complex user space library.
If you mean glibc etc. only then the best solution for that would be probably
to use the (currently unmerged) arbitary file mempolicy code for this and set
a suitable attribute that prevents moving.
 

Hi Andi, Ray, et.al.,
Just want to let you know that I'm still planning to push
my patches to NUMA mempolicy for filemap support and
page migration. I've been swamped with another task at work,
but later this week I will post the latest patches for review.
I haven't been following Ray's manual page migration thread
but will get up-to-speed also, and see how it impacts my patchset
to mempolicy.
Steve
-
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: Address lots of pending pm_message_t changes

[Bernard Blackham]

[Trimmed Cc]

On Tue, Feb 15, 2005 at 11:15:56AM +1100, Nigel Cunningham wrote:
> > Well, yes, if you switch pm_message_t into struct. But we are not yet
> > ready to do that... it is going to be typedefed to u32 for 2.6.11...
> 
> Ah. So I haven't realised that Bernard took your patches wholesale,
> which is why we're fixing the compile errors too :>
> 
> Okay then, I guess the whole thing isn't urgent then?

I was taking the whole shebang in order to differentiate between
PMSG_FREEZE and PMSG_SUSPEND - they're currently typedef'd to the
same thing (3), so drivers such as ide-disk can't decide whether or
not they need to spin down for the atomic copy or for powering off.
(Otherwise you'll find the HDD spinning down and up mid-suspend).

I believe vanilla swsusp passed "3" as the power state hence the HDD
spun down and up anyway, so there were no regressions there, just
bugs. Software Suspend 2 passed "4" as the power state which
ide-disk.c treated as "flush caches, but don't spin down". This is
what broke when the new typedefs went in, but would be fixed when
they're complete (whole shebang).

Bernard.

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

Fix u32 vs. pm_message_t confusion in AGP

[Pavel Machek]

Hi!

This should fix u32 vs. pm_message_t confusion in AGP. Last patch for
tonight, please apply,
Pavel

--- clean-mm/drivers/char/agp/via-agp.c 2005-02-15 00:46:40.0 +0100
+++ linux-mm/drivers/char/agp/via-agp.c 2005-02-15 01:04:09.0 +0100
@@ -440,10 +440,10 @@
 
 #ifdef CONFIG_PM
 
-static int agp_via_suspend(struct pci_dev *pdev, u32 state)
+static int agp_via_suspend(struct pci_dev *pdev, pm_message_t state)
 {
pci_save_state (pdev);
-   pci_set_power_state (pdev, 3);
+   pci_set_power_state (pdev, PCI_D3hot);
 
return 0;
 }
@@ -452,7 +452,7 @@
 {
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
 
-   pci_set_power_state (pdev, 0);
+   pci_set_power_state (pdev, PCI_D0);
pci_restore_state(pdev);
 
if (bridge->driver == _agp3_driver)


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

Re: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments

[Nishanth Aravamudan]

On Sat, Feb 12, 2005 at 09:00:52PM -0800, Nish Aravamudan wrote:
> On Sun, 13 Feb 2005 03:41:01 +0100, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> > On Sünnavend 12 Februar 2005 14:28, Sergey Vlasov wrote:
> > > On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:
> > > > #define __wait_event_lock(wq, condition, lock, flags)  \
> > > > do {   \
> > > >DEFINE_WAIT(__wait);\
> > > >\
> > > >for (;;) {  \
> > > >prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
> > > >spin_lock_irqsave(lock, flags); \
> > > >if (condition)  \
> > > >break;  \
> > > >spin_unlock_irqrestore(lock, flags);\
> > > >schedule(); \
> > > >}   \
> > > >spin_unlock_irqrestore(lock, flags);\
> > > >finish_wait(, &__wait);  \
> > > > } while (0)
> > >
> > > But in this case the result of testing the condition becomes useless
> > > after spin_unlock_irqrestore - someone might grab the lock and change
> > > things.   Therefore the calling code would need to add a loop around
> > > wait_event_lock - and the wait_event_* macros were added precisely to
> > > encapsulate such a loop and avoid the need to code it manually.
> > 
> > Ok, i understand now what the patch really wants to achieve. However,
> > I'm not convinced it's a good idea. In the usb/gadget/serial.c driver,
> > this appears to work only because an unconventional locking scheme is
> > used, i.e. there is an extra flag (port->port_in_use) that is set to
> > tell other functions about the state of the lock in case the lock holder
> > wants to sleep.
> > 
> > Is there any place in the kernel that would benefit of the
> > wait_event_lock() macro family while using locks without such
> > special magic?
> 
> Sorry for replying from a different account, but it's the best I can
> do right now. I know while I was scanning the whole kernel for other
> wait_event*() replacements, I thought at least a handful of times,
> "ugh, I could replace this whole block of code, except for that lock!"
> I will try to get you a more concrete example on Monday. Thanks for
> the feedback & patience!

Here's at least one example:

drivers/ieee1394/video1394.c:__video1394_ioctl()

I'm having trouble finding more (maybe I already fixed some of them via
the existing macros in different ways -- or maybe my memory is just
acting up...).

I think this patch/macro can be useful for wait-queues where the same
lock is used to protect the sleeper and the sleeper's data?

Any further feedback would be appreciated, or any recommendations for
better ways of doing things. I really would just like to have one
consistent interface for all wait-queue usage :) The fact that was is
nearly (but not quite) done by wait_event*() has to be defined somewhere
else just to get that functionality, when it costs little to add it to a
common header, makes this a pretty small change to me.

But, Arnd, I understand your concern. It would not be good if we had a
bunch of lock-holding sleepers pop up now! I will try to think of a
better solution.

Thanks,
Nish
-
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: Radeon FB troubles with recent kernels

[Benjamin Herrenschmidt]

> Nope. No printk outputs from _set_par, _write_mode, or _engine_init.
> 
> Just to clarify: the gdm stop is done from tty1 while gdm is running
> on tty7, so I don't think it's a matter of mode switch logic.

Ohhh, this is a known bug then. When you kill X while it's not on the
front VT, it will crap on the engine. This has always been the case, I
suppose that if you didn't notice it before, it 's because you are
lucky :)

> If I do "sleep 5; /etc/init.d/gdm stop" and then switch to tty7 and
> wait for it to stop, all is fine.

Yes.
> 
> Also, I'm still seeing the LCD blooming + hang on starting radeonfb.
> It's something like 1 in 10 boots rather than every boot now though.

Does it actually hangs ? That's weird... looks like a chip crash. Can
you check if that happens with radeonfb.default_dynclk=-1 on the kernel
command line ?

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/

Fix u32 vs. pm_message_t confusion in bttv

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t confusion in bttv. Please apply,

Pavel
--- clean-mm/drivers/media/video/bttv-driver.c  2005-02-15 00:34:38.0 
+0100
+++ linux-mm/drivers/media/video/bttv-driver.c  2005-02-15 01:04:10.0 
+0100
@@ -3921,7 +3921,7 @@
 return;
 }
 
-static int bttv_suspend(struct pci_dev *pci_dev, u32 state)
+static int bttv_suspend(struct pci_dev *pci_dev, pm_message_t state)
 {
 struct bttv *btv = pci_get_drvdata(pci_dev);
struct bttv_buffer_set idle;


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

Re: [BK] upgrade will be needed

[Steven Rostedt]

On Mon, 2005-02-14 at 16:35 -0800, Larry McVoy wrote:
> On Mon, Feb 14, 2005 at 07:14:11PM -0500, Steven Rostedt wrote:
> > On Mon, 2005-02-14 at 16:00 -0800, Larry McVoy wrote:
> > > How about this?
> > > 
> > > http://lkml.org/lkml/2003/12/14/47
> > 
> > I don't know about others, but it solves my issues.  I'm one of the many
> > that use BK not for the changes, but just for the snapshots. This seems
> > to do it.  Warning, you will still not please a lot of the complainers
> > on the list, but myself (and others) would be satisfied.
> 
> Well it would sure help if you said that in public.  Unless people ask
> for this we aren't going to go build it and support it on bkbits.net.
> It needs to solve problems for a pile of people or we can't afford to do
> it.
> 

I wasn't very active on the list back then, but post something like this
again and I'll second it publicly. You may have already done so, but I
might have missed it. I'll cc the LKML to make this public anyway.

> > As someone mentioned. Still do what you were going to do (keep BK free
> > for Open Source albeit the restriction). But have this for those of us
> > that can't go with the restriction, but still like the latest snapshots
> > of the kernel. In essence, two free versions, where one is "more free"
> > but also "crippled".
> 
> There are HUGE costs with maintaining multiple versions, I'd like to
> avoid that.  We've specced out what it would cost us to maintain 
> old/new versions that talked to each other and it's more or less twice
> as much engineering because you have to backport each new feature needed
> for compat, you have to figure out which bugs have to be backported,
> etc., etc.  It is very very expensive and takes up the resources of our
> most important people.

I don't know the architecture of the tool, but I've worked on some
pretty big projects, that could disable most of the tool with just a
simple config option. Heck, the Linux kernel does this.  But if the
design of the tool is such that you can't disable features without
destroying others (like removing IE from Windows),  then I guess this is
not an option. 

I guess you are dealing with three groups of people.

1) The ones paying you. The companies that spend money to get things
done.  -- Needs full version of BK.

2) The Open Source developers, Linus and others that like BK and will
work with it with whatever license you give it. -- Needs strong version
of BK. Probably no more than 100 users (or less).

3) The Open Source users, tweakers, hackers that are not the core
developers. -- Needs only to checkout the kernel. Probably over 1000
users.  I fall in this category.

This is why we have asked about three versions. Obviously, Linus and
friends are the most important part for the Linux community, so even if
it hurts 2000 other people that only want to download the lastest
snapshots from BK, it really doesn't matter.  Let us complain, but
unless Linus decides to go elsewhere, we are stuck.  So don't do the
crippled version if it hurts Linus.

-- Steve


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

Fix u32 vs. pm_message_t confusion in serials

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t confusion in serials. Please apply,

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

--- clean-mm/drivers/serial/8250.c  2005-02-15 00:46:41.0 +0100
+++ linux-mm/drivers/serial/8250.c  2005-02-15 01:04:10.0 +0100
@@ -2316,7 +2316,7 @@
return 0;
 }
 
-static int serial8250_suspend(struct device *dev, u32 state, u32 level)
+static int serial8250_suspend(struct device *dev, pm_message_t state, u32 
level)
 {
int i;
 
--- clean-mm/drivers/serial/8250_pci.c  2004-12-25 13:35:01.0 +0100
+++ linux-mm/drivers/serial/8250_pci.c  2005-02-15 01:04:10.0 +0100
@@ -1759,7 +1759,7 @@
}
 }
 
-static int pciserial_suspend_one(struct pci_dev *dev, u32 state)
+static int pciserial_suspend_one(struct pci_dev *dev, pm_message_t state)
 {
struct serial_private *priv = pci_get_drvdata(dev);
 

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

Fix u32 vs. pm_message_t in macintosh

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t confusion in macintosh. Please apply,

Pavel

--- clean-mm/drivers/macintosh/via-pmu.c2005-02-15 00:46:40.0 
+0100
+++ linux-mm/drivers/macintosh/via-pmu.c2005-02-15 01:04:10.0 
+0100
@@ -2339,7 +2339,7 @@
}
 
/* Send suspend call to devices, hold the device core's dpm_sem */
-   ret = device_suspend(PM_SUSPEND_MEM);
+   ret = device_suspend(PMSG_SUSPEND);
if (ret) {
broadcast_wake();
printk(KERN_ERR "Driver sleep failed\n");

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

Fix u32 vs. pm_message_t confusion in MMC

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t confusion in MMC layer. Please apply,

Pavel

--- clean-mm/drivers/mmc/mmc_block.c2005-02-15 00:34:38.0 +0100
+++ linux-mm/drivers/mmc/mmc_block.c2005-02-15 01:04:10.0 +0100
@@ -437,7 +437,7 @@
 }
 
 #ifdef CONFIG_PM
-static int mmc_blk_suspend(struct mmc_card *card, u32 state)
+static int mmc_blk_suspend(struct mmc_card *card, pm_message_t state)
 {
struct mmc_blk_data *md = mmc_get_drvdata(card);
 
--- clean-mm/drivers/mmc/mmc_sysfs.c2004-10-01 00:30:15.0 +0200
+++ linux-mm/drivers/mmc/mmc_sysfs.c2005-02-15 01:04:10.0 +0100
@@ -74,7 +74,7 @@
return 0;
 }
 
-static int mmc_bus_suspend(struct device *dev, u32 state)
+static int mmc_bus_suspend(struct device *dev, pm_message_t state)
 {
struct mmc_driver *drv = to_mmc_driver(dev->driver);
struct mmc_card *card = dev_to_mmc_card(dev);
--- clean-mm/include/linux/mmc/card.h   2004-10-01 00:30:30.0 +0200
+++ linux-mm/include/linux/mmc/card.h   2005-02-15 01:04:11.0 +0100
@@ -75,7 +75,7 @@
struct device_driver drv;
int (*probe)(struct mmc_card *);
void (*remove)(struct mmc_card *);
-   int (*suspend)(struct mmc_card *, u32);
+   int (*suspend)(struct mmc_card *, pm_message_t);
int (*resume)(struct mmc_card *);
 };
 


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

Fix u32 vs. pm_message_t in i8042.c

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t in i8042.c. Please apply,
Pavel

--- clean-mm/drivers/input/serio/i8042.c2005-02-15 00:46:40.0 
+0100
+++ linux-mm/drivers/input/serio/i8042.c2005-02-15 01:04:10.0 
+0100
@@ -900,7 +900,7 @@
  * Here we try to restore the original BIOS settings
  */
 
-static int i8042_suspend(struct device *dev, u32 state, u32 level)
+static int i8042_suspend(struct device *dev, pm_message_t state, u32 level)
 {
if (level == SUSPEND_DISABLE) {
del_timer_sync(_timer);

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

Pty is losing bytes

[Andreas Schwab]

Recent kernel are losing bytes on a pty.  Try running this program (needs
to be linked against -lutil) with a moderately large input (10K - 20K).
The output should match its input, but instead there is always one byte
missing at the end of the first 4K chunk read by the child.

#include 
#include 
#include 
#include 
#include 

char buf[4096];

int main (void)
{
int master;
int stdout = dup (1);
int pid = forkpty (, 0, 0, 0);
int bytes_read;
int bytes_written;

if (pid < 0) exit (1);
if (pid > 0) {
while ((bytes_read = read (0, buf, sizeof (buf))) > 0) {
char *p = buf;
while (bytes_read > 0 &&
   (bytes_written = write (master, p, bytes_read)) > 0)
  bytes_read -= bytes_written, p += bytes_written;
}
write (master, "EOF\n", 4);
waitpid (pid, 0, 0);
exit (0);
}

while ((bytes_read = read (0, buf, sizeof (buf))) > 0) {
char *p = buf;
if (strncmp (buf, "EOF\n", 4) == 0) break;
while (bytes_read > 0 &&
   (bytes_written = write (stdout, p, bytes_read)) > 0)
  bytes_read -= bytes_written, p += bytes_written;
}
exit (0);
}

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
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/

Fix u32 vs. pm_message_t confusion in framebuffers

[Pavel Machek]

Hi!

This should fix u32 vs pm_message_t confusion in framebuffers, and do
no code changes. Please apply,

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

--- clean-mm/drivers/video/aty/aty128fb.c   2005-02-15 00:46:41.0 
+0100
+++ linux-mm/drivers/video/aty/aty128fb.c   2005-02-15 01:04:11.0 
+0100
@@ -166,7 +166,7 @@
 static int aty128_probe(struct pci_dev *pdev,
const struct pci_device_id *ent);
 static void aty128_remove(struct pci_dev *pdev);
-static int aty128_pci_suspend(struct pci_dev *pdev, u32 state);
+static int aty128_pci_suspend(struct pci_dev *pdev, pm_message_t state);
 static int aty128_pci_resume(struct pci_dev *pdev);
 static int aty128_do_resume(struct pci_dev *pdev);
 
@@ -2330,7 +2330,7 @@
}
 }
 
-static int aty128_pci_suspend(struct pci_dev *pdev, u32 state)
+static int aty128_pci_suspend(struct pci_dev *pdev, pm_message_t state)
 {
struct fb_info *info = pci_get_drvdata(pdev);
struct aty128fb_par *par = info->par;
@@ -2413,7 +2413,7 @@
par->lock_blank = 0;
aty128fb_blank(0, info);
 
-   pdev->dev.power.power_state = 0;
+   pdev->dev.power.power_state = PMSG_ON;
 
printk(KERN_DEBUG "aty128fb: resumed !\n");
 
--- clean-mm/drivers/video/aty/atyfb_base.c 2005-02-15 00:34:40.0 
+0100
+++ linux-mm/drivers/video/aty/atyfb_base.c 2005-02-15 01:04:11.0 
+0100
@@ -2016,7 +2016,7 @@
return timeout ? 0 : -EIO;
 }
 
-static int atyfb_pci_suspend(struct pci_dev *pdev, u32 state)
+static int atyfb_pci_suspend(struct pci_dev *pdev, pm_message_t state)
 {
struct fb_info *info = pci_get_drvdata(pdev);
struct atyfb_par *par = (struct atyfb_par *) info->par;
@@ -2091,7 +2091,7 @@
 
release_console_sem();
 
-   pdev->dev.power.power_state = 0;
+   pdev->dev.power.power_state = PMSG_ON;
 
return 0;
 }
--- clean-mm/drivers/video/aty/radeon_pm.c  2005-02-15 00:46:41.0 
+0100
+++ linux-mm/drivers/video/aty/radeon_pm.c  2005-02-15 01:04:11.0 
+0100
@@ -2663,7 +2663,7 @@
else if (rinfo->dynclk == 0)
radeon_pm_disable_dynamic_mode(rinfo);
 
-   pdev->dev.power.power_state = 0;
+   pdev->dev.power.power_state = PMSG_ON;
 
  bail:
release_console_sem();
--- clean-mm/drivers/video/aty/radeonfb.h   2005-02-15 00:46:41.0 
+0100
+++ linux-mm/drivers/video/aty/radeonfb.h   2005-02-15 01:04:11.0 
+0100
@@ -624,7 +624,7 @@
 extern int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn, 
u8 **out_edid);
 
 /* PM Functions */
-extern int radeonfb_pci_suspend(struct pci_dev *pdev, u32 state);
+extern int radeonfb_pci_suspend(struct pci_dev *pdev, pm_message_t state);
 extern int radeonfb_pci_resume(struct pci_dev *pdev);
 extern void radeonfb_pm_init(struct radeonfb_info *rinfo, int dynclk);
 extern void radeonfb_pm_exit(struct radeonfb_info *rinfo);
--- clean-mm/drivers/video/cyber2000fb.c2005-02-15 00:34:40.0 
+0100
+++ linux-mm/drivers/video/cyber2000fb.c2005-02-15 01:04:11.0 
+0100
@@ -1665,7 +1665,7 @@
}
 }
 
-static int cyberpro_pci_suspend(struct pci_dev *dev, u32 state)
+static int cyberpro_pci_suspend(struct pci_dev *dev, pm_message_t state)
 {
return 0;
 }
--- clean-mm/drivers/video/i810/i810_main.c 2005-02-15 00:46:41.0 
+0100
+++ linux-mm/drivers/video/i810/i810_main.c 2005-02-15 01:04:11.0 
+0100
@@ -1524,7 +1524,7 @@
pci_disable_device(dev);
}
pci_save_state(dev);
-   pci_set_power_state(dev, state);
+   pci_set_power_state(dev, pci_choose_state(dev, state));
 
return 0;
 }
--- clean-mm/drivers/video/i810/i810_main.h 2004-04-05 10:45:24.0 
+0200
+++ linux-mm/drivers/video/i810/i810_main.h 2005-02-15 01:04:11.0 
+0100
@@ -18,7 +18,7 @@
   const struct pci_device_id *entry);
 static void __exit i810fb_remove_pci(struct pci_dev *dev);
 static int i810fb_resume(struct pci_dev *dev);
-static int i810fb_suspend(struct pci_dev *dev, u32 state);
+static int i810fb_suspend(struct pci_dev *dev, pm_message_t state);
 
 /*
  * voffset - framebuffer offset in MiB from aperture start address.  In order 
for

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

Fix u32 vs. pm_message_t in network device drivers

[Pavel Machek]

Hi!

This should fix confusion in network device drivers. No code
changes. Please apply,
Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

--- clean-mm/drivers/net/3c59x.c2005-02-15 00:34:38.0 +0100
+++ linux-mm/drivers/net/3c59x.c2005-02-15 01:04:10.0 +0100
@@ -964,7 +964,7 @@
 
 #ifdef CONFIG_PM
 
-static int vortex_suspend (struct pci_dev *pdev, u32 state)
+static int vortex_suspend (struct pci_dev *pdev, pm_message_t state)
 {
struct net_device *dev = pci_get_drvdata(pdev);
 
--- clean-mm/drivers/net/8139too.c  2005-02-15 00:46:41.0 +0100
+++ linux-mm/drivers/net/8139too.c  2005-02-15 01:04:10.0 +0100
@@ -2558,7 +2558,7 @@
 
 #ifdef CONFIG_PM
 
-static int rtl8139_suspend (struct pci_dev *pdev, u32 state)
+static int rtl8139_suspend (struct pci_dev *pdev, pm_message_t state)
 {
struct net_device *dev = pci_get_drvdata (pdev);
struct rtl8139_private *tp = netdev_priv(dev);
--- clean-mm/drivers/net/amd8111e.c 2005-02-15 00:34:38.0 +0100
+++ linux-mm/drivers/net/amd8111e.c 2005-02-15 01:04:10.0 +0100
@@ -1797,7 +1797,7 @@
if(!err)
netif_wake_queue(dev);
 }
-static int amd8111e_suspend(struct pci_dev *pci_dev, u32 state)
+static int amd8111e_suspend(struct pci_dev *pci_dev, pm_message_t state)
 {  
struct net_device *dev = pci_get_drvdata(pci_dev);
struct amd8111e_priv *lp = netdev_priv(dev);
--- clean-mm/drivers/net/b44.c  2005-02-15 00:46:41.0 +0100
+++ linux-mm/drivers/net/b44.c  2005-02-15 01:04:10.0 +0100
@@ -1910,7 +1910,7 @@
}
 }
 
-static int b44_suspend(struct pci_dev *pdev, u32 state)
+static int b44_suspend(struct pci_dev *pdev, pm_message_t state)
 {
struct net_device *dev = pci_get_drvdata(pdev);
struct b44 *bp = netdev_priv(dev);
--- clean-mm/drivers/net/e100.c 2005-02-15 00:34:38.0 +0100
+++ linux-mm/drivers/net/e100.c 2005-02-15 01:04:10.0 +0100
@@ -2310,7 +2310,7 @@
 }
 
 #ifdef CONFIG_PM
-static int e100_suspend(struct pci_dev *pdev, u32 state)
+static int e100_suspend(struct pci_dev *pdev, pm_message_t state)
 {
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
@@ -2321,7 +2321,7 @@
netif_device_detach(netdev);
 
pci_save_state(pdev);
-   pci_enable_wake(pdev, state, nic->flags & (wol_magic | e100_asf(nic)));
+   pci_enable_wake(pdev, pci_choose_state(pdev, state), nic->flags & 
(wol_magic | e100_asf(nic)));
pci_disable_device(pdev);
pci_set_power_state(pdev, pci_choose_state(pdev, state));
 
--- clean-mm/drivers/net/eepro100.c 2005-02-15 00:46:41.0 +0100
+++ linux-mm/drivers/net/eepro100.c 2005-02-15 01:04:10.0 +0100
@@ -2271,7 +2271,7 @@
 }
 
 #ifdef CONFIG_PM
-static int eepro100_suspend(struct pci_dev *pdev, u32 state)
+static int eepro100_suspend(struct pci_dev *pdev, pm_message_t state)
 {
struct net_device *dev = pci_get_drvdata (pdev);
struct speedo_private *sp = netdev_priv(dev);
@@ -2289,7 +2289,7 @@

/* XXX call pci_set_power_state ()? */
pci_disable_device(pdev);
-   pci_set_power_state (pdev, 3);
+   pci_set_power_state (pdev, PCI_D3hot);
return 0;
 }
 
@@ -2299,7 +2299,7 @@
struct speedo_private *sp = netdev_priv(dev);
void __iomem *ioaddr = sp->regs;
 
-   pci_set_power_state(pdev, 0);
+   pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
pci_enable_device(pdev);
pci_set_master(pdev);
--- clean-mm/drivers/net/epic100.c  2005-02-15 00:34:38.0 +0100
+++ linux-mm/drivers/net/epic100.c  2005-02-15 01:04:10.0 +0100
@@ -1624,7 +1624,7 @@
 
 #ifdef CONFIG_PM
 
-static int epic_suspend (struct pci_dev *pdev, u32 state)
+static int epic_suspend (struct pci_dev *pdev, pm_message_t state)
 {
struct net_device *dev = pci_get_drvdata(pdev);
long ioaddr = dev->base_addr;
--- clean-mm/drivers/net/irda/donauboe.c2005-02-15 00:34:38.0 
+0100
+++ linux-mm/drivers/net/irda/donauboe.c2005-02-15 01:04:10.0 
+0100
@@ -1712,7 +1712,7 @@
 }
 
 static int
-toshoboe_gotosleep (struct pci_dev *pci_dev, u32 crap)
+toshoboe_gotosleep (struct pci_dev *pci_dev, pm_message_t crap)
 {
   struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev);
   unsigned long flags;
--- clean-mm/drivers/net/natsemi.c  2005-02-15 00:34:39.0 +0100
+++ linux-mm/drivers/net/natsemi.c  2005-02-15 01:04:10.0 +0100
@@ -3160,7 +3160,7 @@
  * Interrupts must be disabled, otherwise hands_off can cause irq storms.
  */
 
-static int natsemi_suspend (struct pci_dev *pdev, u32 state)
+static int natsemi_suspend (struct pci_dev *pdev, pm_message_t state)
 {
struct net_device *dev = pci_get_drvdata (pdev);

FIx u32 vs. pm_message_t confusion in firewire

[Pavel Machek]

Hi!

This should fix u32 vs. pm_message_t confusion in firewire. No code
changes. Please apply,
Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

--- clean-mm/drivers/ieee1394/nodemgr.c 2005-02-15 00:46:40.0 +0100
+++ linux-mm/drivers/ieee1394/nodemgr.c 2005-02-15 01:04:10.0 +0100
@@ -1284,7 +1284,7 @@
 
if (ud->device.driver &&
(!ud->device.driver->suspend ||
- ud->device.driver->suspend(>device, 0, 0)))
+ ud->device.driver->suspend(>device, PMSG_SUSPEND, 0)))
device_release_driver(>device);
}
up_write(>device.bus->subsys.rwsem);
--- clean-mm/drivers/ieee1394/ohci1394.c2005-02-15 00:46:40.0 
+0100
+++ linux-mm/drivers/ieee1394/ohci1394.c2005-02-15 01:04:10.0 
+0100
@@ -3546,7 +3546,7 @@
 }
 
 
-static int ohci1394_pci_suspend (struct pci_dev *pdev, u32 state)
+static int ohci1394_pci_suspend (struct pci_dev *pdev, pm_message_t state)
 {
 #ifdef CONFIG_PMAC_PBOOK
{


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

Fix u32 vs. pm_message_t confusion in PCMCIA

[Pavel Machek]

Hi!

This should fix part of u32 vs. pm_message_t confusion in
pcmcia. PCMCIA is listed as unmaintained, that's why it goes
directly...

Pavel

--- clean-mm/drivers/pcmcia/cs.c2005-02-15 00:34:39.0 +0100
+++ linux-mm/drivers/pcmcia/cs.c2005-02-15 01:04:10.0 +0100
@@ -140,7 +140,7 @@
 static int socket_resume(struct pcmcia_socket *skt);
 static int socket_suspend(struct pcmcia_socket *skt);
 
-int pcmcia_socket_dev_suspend(struct device *dev, u32 state)
+int pcmcia_socket_dev_suspend(struct device *dev, pm_message_t state)
 {
struct pcmcia_socket *socket;
 
--- clean-mm/drivers/pcmcia/i82092.c2005-02-15 00:34:39.0 +0100
+++ linux-mm/drivers/pcmcia/i82092.c2005-02-15 01:04:10.0 +0100
@@ -42,7 +42,7 @@
 };
 MODULE_DEVICE_TABLE(pci, i82092aa_pci_ids);
 
-static int i82092aa_socket_suspend (struct pci_dev *dev, u32 state)
+static int i82092aa_socket_suspend (struct pci_dev *dev, pm_message_t state)
 {
return pcmcia_socket_dev_suspend(>dev, state);
 }
--- clean-mm/drivers/pcmcia/i82365.c2005-02-15 00:46:41.0 +0100
+++ linux-mm/drivers/pcmcia/i82365.c2005-02-15 01:04:10.0 +0100
@@ -1339,7 +1339,7 @@
 
 /**/
 
-static int i82365_suspend(struct device *dev, u32 state, u32 level)
+static int i82365_suspend(struct device *dev, pm_message_t state, u32 level)
 {
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-mm/drivers/pcmcia/pd6729.c2005-02-15 00:34:39.0 +0100
+++ linux-mm/drivers/pcmcia/pd6729.c2005-02-15 01:04:10.0 +0100
@@ -833,7 +833,7 @@
kfree(socket);
 }
 
-static int pd6729_socket_suspend(struct pci_dev *dev, u32 state)
+static int pd6729_socket_suspend(struct pci_dev *dev, pm_message_t state)
 {
return pcmcia_socket_dev_suspend(>dev, state);
 }
--- clean-mm/drivers/pcmcia/tcic.c  2005-02-15 00:34:39.0 +0100
+++ linux-mm/drivers/pcmcia/tcic.c  2005-02-15 01:04:10.0 +0100
@@ -373,7 +373,7 @@
 
 /**/
 
-static int tcic_drv_suspend(struct device *dev, u32 state, u32 level)
+static int tcic_drv_suspend(struct device *dev, pm_message_t state, u32 level)
 {
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
--- clean-mm/drivers/pcmcia/yenta_socket.c  2005-02-15 00:46:41.0 
+0100
+++ linux-mm/drivers/pcmcia/yenta_socket.c  2005-02-15 01:04:10.0 
+0100
@@ -1019,7 +1019,7 @@
 }
 
 
-static int yenta_dev_suspend (struct pci_dev *dev, u32 state)
+static int yenta_dev_suspend (struct pci_dev *dev, pm_message_t state)
 {
struct yenta_socket *socket = pci_get_drvdata(dev);
int ret;
--- clean-mm/include/pcmcia/ss.h2005-02-15 00:34:41.0 +0100
+++ linux-mm/include/pcmcia/ss.h2005-02-15 01:04:11.0 +0100
@@ -248,7 +248,7 @@
 extern struct class pcmcia_socket_class;
 
 /* socket drivers are expected to use these callbacks in their .drv struct */
-extern int pcmcia_socket_dev_suspend(struct device *dev, u32 state);
+extern int pcmcia_socket_dev_suspend(struct device *dev, pm_message_t state);
 extern int pcmcia_socket_dev_resume(struct device *dev);
 
 #endif /* _LINUX_SS_H */
 

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

Re: Fix pm_message_t in generic code [was Re: PATCH: Address lots of pending pm_message_t changes]

[Nigel Cunningham]

Hi Pavel.

Thanks!

Nigel
 
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

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

Fix u32 vs. pm_message_t confusion in OSS

[Pavel Machek]

Hi!

This fixes (part of) u32 vs. pm_message_t confusion in OSS. I found no
maintainer for OSS in MAINTAINERS, that's why it goes to you... It
should cause no code changes. Please apply,

Pavel


--- clean-mm/sound/oss/ali5455.c2005-02-15 00:34:42.0 +0100
+++ linux-mm/sound/oss/ali5455.c2005-02-15 01:04:11.0 +0100
@@ -3528,7 +3528,7 @@
 }
 
 #ifdef CONFIG_PM
-static int ali_pm_suspend(struct pci_dev *dev, u32 pm_state)
+static int ali_pm_suspend(struct pci_dev *dev, pm_message_t pm_state)
 {
struct ali_card *card = pci_get_drvdata(dev);
struct ali_state *state;
--- clean-mm/sound/oss/cs4281/cs4281_wrapper-24.c   2005-02-15 
00:34:42.0 +0100
+++ linux-mm/sound/oss/cs4281/cs4281_wrapper-24.c   2005-02-15 
01:04:11.0 +0100
@@ -27,7 +27,7 @@
 #include 
 
 static int cs4281_resume_null(struct pci_dev *pcidev) { return 0; }
-static int cs4281_suspend_null(struct pci_dev *pcidev, u32 state) { return 0; }
+static int cs4281_suspend_null(struct pci_dev *pcidev, pm_message_t state) { 
return 0; }
 
 #define free_dmabuf(state, dmabuf) \
pci_free_consistent(state->pcidev, \
--- clean-mm/sound/oss/cs46xx.c 2005-02-15 00:34:42.0 +0100
+++ linux-mm/sound/oss/cs46xx.c 2005-02-15 01:04:11.0 +0100
@@ -388,7 +388,7 @@
 static int cs46xx_powerup(struct cs_card *card, unsigned int type);
 static int cs461x_powerdown(struct cs_card *card, unsigned int type, int 
suspendflag);
 static void cs461x_clear_serial_FIFOs(struct cs_card *card, int type);
-static int cs46xx_suspend_tbl(struct pci_dev *pcidev, u32 state);
+static int cs46xx_suspend_tbl(struct pci_dev *pcidev, pm_message_t state);
 static int cs46xx_resume_tbl(struct pci_dev *pcidev);
 
 #ifndef CS46XX_ACPI_SUPPORT
@@ -5774,7 +5774,7 @@
 #endif
 
 #if CS46XX_ACPI_SUPPORT
-static int cs46xx_suspend_tbl(struct pci_dev *pcidev, u32 state)
+static int cs46xx_suspend_tbl(struct pci_dev *pcidev, pm_message_t state)
 {
struct cs_card *s = PCI_GET_DRIVER_DATA(pcidev);
CS_DBGOUT(CS_PM | CS_FUNCTION, 2, 
--- clean-mm/sound/oss/cs46xxpm-24.h2005-02-15 00:34:42.0 +0100
+++ linux-mm/sound/oss/cs46xxpm-24.h2005-02-15 01:04:11.0 +0100
@@ -36,7 +36,7 @@
 * for now (12/22/00) only enable the pm_register PM support.
 * allow these table entries to be null.
 */
-static int cs46xx_suspend_tbl(struct pci_dev *pcidev, u32 state);
+static int cs46xx_suspend_tbl(struct pci_dev *pcidev, pm_message_t state);
 static int cs46xx_resume_tbl(struct pci_dev *pcidev);
 #define cs_pm_register(a, b, c)  NULL
 #define cs_pm_unregister_all(a) 
--- clean-mm/sound/oss/esssolo1.c   2004-12-25 13:35:04.0 +0100
+++ linux-mm/sound/oss/esssolo1.c   2005-02-15 01:04:11.0 +0100
@@ -2257,7 +2257,7 @@
 }
 
 static int
-solo1_suspend(struct pci_dev *pci_dev, u32 state) {
+solo1_suspend(struct pci_dev *pci_dev, pm_message_t state) {
struct solo1_state *s = (struct solo1_state*)pci_get_drvdata(pci_dev);
if (!s)
return 1;
--- clean-mm/sound/oss/i810_audio.c 2005-02-15 00:34:42.0 +0100
+++ linux-mm/sound/oss/i810_audio.c 2005-02-15 01:04:11.0 +0100
@@ -3470,7 +3470,7 @@
 }
 
 #ifdef CONFIG_PM
-static int i810_pm_suspend(struct pci_dev *dev, u32 pm_state)
+static int i810_pm_suspend(struct pci_dev *dev, pm_message_t pm_state)
 {
 struct i810_card *card = pci_get_drvdata(dev);
 struct i810_state *state;
--- clean-mm/sound/oss/maestro3.c   2005-02-15 00:34:42.0 +0100
+++ linux-mm/sound/oss/maestro3.c   2005-02-15 01:04:11.0 +0100
@@ -375,7 +375,7 @@
  * I'm not very good at laying out functions in a file :)
  */
 static int m3_notifier(struct notifier_block *nb, unsigned long event, void 
*buf);
-static int m3_suspend(struct pci_dev *pci_dev, u32 state);
+static int m3_suspend(struct pci_dev *pci_dev, pm_message_t state);
 static void check_suspend(struct m3_card *card);
 
 static struct notifier_block m3_reboot_nb = {
@@ -2777,12 +2777,12 @@
 
 for(card = devs; card != NULL; card = card->next) {
 if(!card->in_suspend)
-m3_suspend(card->pcidev, 3); /* XXX legal? */
+m3_suspend(card->pcidev, PMSG_SUSPEND); /* XXX legal? */
 }
 return 0;
 }
 
-static int m3_suspend(struct pci_dev *pci_dev, u32 state)
+static int m3_suspend(struct pci_dev *pci_dev, pm_message_t state)
 {
 unsigned long flags;
 int i;
--- clean-mm/sound/oss/trident.c2005-02-15 00:34:42.0 +0100
+++ linux-mm/sound/oss/trident.c2005-02-15 01:04:11.0 +0100
@@ -487,7 +487,7 @@
 static struct trident_channel *ali_alloc_pcm_channel(struct trident_card 
*card);
 static void ali_restore_regs(struct trident_card *card);
 static void ali_save_regs(struct trident_card *card);
-static int trident_suspend(struct pci_dev *dev, u32 unused);
+static int trident_suspend(struct 

Fix u32 vs. pm_message_t in USB [was Re: PATCH: Address lots of pending pm_message_t changes]

[Pavel Machek]

Hi!

This fixes (part of) u32 vs. pm_message_t confusion in USB. It should
cause no code changes. Please apply,

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


--- clean-mm/drivers/usb/core/hcd-pci.c 2005-02-15 00:34:40.0 +0100
+++ linux-mm/drivers/usb/core/hcd-pci.c 2005-02-15 01:04:10.0 +0100
@@ -396,7 +396,7 @@
 
if (has_pci_pm)
pci_set_power_state (dev, 0);
-   dev->dev.power.power_state = 0;
+   dev->dev.power.power_state = PMSG_ON;
retval = request_irq (dev->irq, usb_hcd_irq, SA_SHIRQ,
hcd->driver->description, hcd);
if (retval < 0) {
--- clean-mm/drivers/usb/core/hcd.h 2005-02-15 00:46:41.0 +0100
+++ linux-mm/drivers/usb/core/hcd.h 2005-02-15 01:04:10.0 +0100
@@ -223,7 +223,7 @@
 extern void usb_hcd_pci_remove (struct pci_dev *dev);
 
 #ifdef CONFIG_PM
-extern int usb_hcd_pci_suspend (struct pci_dev *dev, u32 state);
+extern int usb_hcd_pci_suspend (struct pci_dev *dev, pm_message_t state);
 extern int usb_hcd_pci_resume (struct pci_dev *dev);
 #endif /* CONFIG_PM */
 
--- clean-mm/drivers/usb/core/hub.c 2005-02-15 00:46:41.0 +0100
+++ linux-mm/drivers/usb/core/hub.c 2005-02-15 01:06:01.0 +0100
@@ -1635,7 +1635,7 @@
  *
  * Returns 0 on success, else negative errno.
  */
-int usb_suspend_device(struct usb_device *udev, u32 state)
+int usb_suspend_device(struct usb_device *udev, pm_message_t state)
 {
int port1, status;
 
@@ -1950,7 +1950,7 @@
 
 #else  /* !CONFIG_USB_SUSPEND */
 
-int usb_suspend_device(struct usb_device *udev, u32 state)
+int usb_suspend_device(struct usb_device *udev, pm_message_t state)
 {
return 0;
 }
--- clean-mm/drivers/usb/core/usb.c 2005-02-15 00:34:40.0 +0100
+++ linux-mm/drivers/usb/core/usb.c 2005-02-15 01:04:11.0 +0100
@@ -1348,7 +1348,7 @@
usb_pipein (pipe) ? DMA_FROM_DEVICE : DMA_TO_DEVICE);
 }
 
-static int usb_generic_suspend(struct device *dev, u32 state)
+static int usb_generic_suspend(struct device *dev, pm_message_t state)
 {
struct usb_interface *intf;
struct usb_driver *driver;
--- clean-mm/drivers/usb/host/ehci-hcd.c2005-02-15 00:34:40.0 
+0100
+++ linux-mm/drivers/usb/host/ehci-hcd.c2005-02-15 01:04:11.0 
+0100
@@ -677,7 +677,7 @@
  * the right sort of wakeup.  
  */
 
-static int ehci_suspend (struct usb_hcd *hcd, u32 state)
+static int ehci_suspend (struct usb_hcd *hcd, pci_power_t state)
 {
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
 
--- clean-mm/drivers/usb/host/ohci-pci.c2005-02-15 00:34:40.0 
+0100
+++ linux-mm/drivers/usb/host/ohci-pci.c2005-02-15 01:04:11.0 
+0100
@@ -102,7 +102,7 @@
 
 #ifdef CONFIG_PM
 
-static int ohci_pci_suspend (struct usb_hcd *hcd, u32 state)
+static int ohci_pci_suspend (struct usb_hcd *hcd, pci_power_t state)
 {
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
 
--- clean-mm/drivers/usb/host/sl811-hcd.c   2005-02-15 00:34:40.0 
+0100
+++ linux-mm/drivers/usb/host/sl811-hcd.c   2005-02-15 01:04:11.0 
+0100
@@ -103,12 +103,12 @@
 
sl811->port1 = (1 << USB_PORT_FEAT_POWER);
sl811->irq_enable = SL11H_INTMASK_INSRMV;
-   hcd->self.controller->power.power_state = PM_SUSPEND_ON;
+   hcd->self.controller->power.power_state = PMSG_ON;
} else {
sl811->port1 = 0;
sl811->irq_enable = 0;
hcd->state = USB_STATE_HALT;
-   hcd->self.controller->power.power_state = PM_SUSPEND_DISK;
+   hcd->self.controller->power.power_state = PMSG_SUSPEND;
}
sl811->ctrl1 = 0;
sl811_write(sl811, SL11H_IRQ_ENABLE, 0);
@@ -1799,7 +1799,7 @@
  */
 
 static int
-sl811h_suspend(struct device *dev, u32 state, u32 phase)
+sl811h_suspend(struct device *dev, pm_message_t state, u32 phase)
 {
struct sl811*sl811 = dev_get_drvdata(dev);
int retval = 0;
--- clean-mm/drivers/usb/host/uhci-hcd.c2005-02-15 00:46:41.0 
+0100
+++ linux-mm/drivers/usb/host/uhci-hcd.c2005-02-15 01:04:11.0 
+0100
@@ -758,7 +758,7 @@
 }
 
 #ifdef CONFIG_PM
-static int uhci_suspend(struct usb_hcd *hcd, u32 state)
+static int uhci_suspend(struct usb_hcd *hcd, pci_power_t state)
 {
struct uhci_hcd *uhci = hcd_to_uhci(hcd);
 
--- clean-mm/drivers/usb/input/hid-core.c   2005-02-15 00:46:41.0 
+0100
+++ linux-mm/drivers/usb/input/hid-core.c   2005-02-15 01:04:11.0 
+0100
@@ -1854,7 +1854,7 @@
return 0;
 }
 
-static int hid_suspend(struct usb_interface *intf, u32 state)
+static int hid_suspend(struct usb_interface *intf, pm_message_t state)
 {
struct hid_device *hid = usb_get_intfdata (intf);
 
@@ -1869,7 +1869,7 @@

Fix pm_message_t in generic code [was Re: PATCH: Address lots of pending pm_message_t changes]

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t in generic code. No code
changes. Please apply,
Pavel


--- clean-mm/Documentation/power/devices.txt2005-02-15 00:34:36.0 
+0100
+++ linux-mm/Documentation/power/devices.txt2005-02-15 01:04:09.0 
+0100
@@ -15,7 +15,7 @@
 
 struct bus_type {
...
-   int (*suspend)(struct device * dev, u32 state);
+   int (*suspend)(struct device * dev, pm_message_t state);
int (*resume)(struct device * dev);
 };
 

--- clean-mm/include/linux/device.h 2005-02-15 00:34:41.0 +0100
+++ linux-mm/include/linux/device.h 2005-02-15 01:04:11.0 +0100
@@ -111,7 +111,7 @@
int (*probe)(struct device * dev);
int (*remove)   (struct device * dev);
void(*shutdown) (struct device * dev);
-   int (*suspend)  (struct device * dev, u32 state, u32 level);
+   int (*suspend)  (struct device * dev, pm_message_t state, u32 
level);
int (*resume)   (struct device * dev, u32 level);
 };
 
 
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Ray Bryant]

Andi Kleen wrote:
Ray Bryant <[EMAIL PROTECTED]> writes:
set of pages associated with a particular process need to be moved.
The kernel interface that we are proposing is the following:
page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);

[Only commenting on the interface, haven't read your patches at all]
This is basically mbind() with MPOL_F_STRICT, except that it has a pid 
argument. I assume that's for the benefit of your batch scheduler.

But it's not clear to me how and why the batch scheduler should know about
virtual addresses of different processes anyways. Walking
/proc/pid/maps? That's all inherently racy when the process is doing
mmap in parallel. The only way I can think of to do this would be to
check for changes in maps after a full move and loop, but then you risk
livelock.
And you cannot also just specify va_start=0, va_end=~0UL because that
would make the node arrays grow infinitely.
Also is there a good use case why the batch scheduler should only
move individual areas in a process around, not the full process?
The batch scheduler interface will be to move entire jobs (groups of
processes) around from one set of nodes to another.  But that interface
doesn't work at the kernel level.  The problem is that one just can't
ask the kernel to move the entire address space of a process for a number
of reasons:
(1)  You really don't want to migrate the code pages of shared libraries
 that are mapped into the process address space.  This causes a
 useless shuffling of pages which really doesn't help system
 performance.  On the other hand, if a shared library is some
 private thing that is only used by the processes being migrated,
 then you should move that.
(2)  You really only want to migrate pages once.  If a file is mapped
 into several of the pid's that are being migrated, then you want
 to figure this out and issue one call to have it moved wrt one of
 the pid's.
 (The page migration code from the memory hotplug patch will handle
 updating the pte's of the other processs (thank goodness for
 rmap...))
(3)  In the case where a particular file is mapped into different
 processes at different file offsets (and we are migrating both
 of the processes), one has to examine the file offsets to figure
 out if the mappings overlap or not. If they overlap, then you've
 got to issue two calls, each of which describes a non-overlapping
 region; both calls taken together would cover the entire range
 of pages mapped to the file.  Similarly if the ranges do not
 overlap.
Figuring all of this out seems to me to be way too complicated to
want to stick into the kernel.  Hence we proposed the kernel interface
as discussed in the overview note.  This interface would be used by
a user space library, whose batch scheduler interface would look
something like this:
migrate_processes(pid_count, pid_list, node_count, old_nodes, new_nodes);
which is what you are asking for, I think.  The library's job
(in addition to suspending all of the processes in the list for
the duration of the migration operation, plus do some other things
that are specific to sn2 hardware) would be to examine the
/proc/pid/maps entries for each pid that we are
migrating, and figure out from that what portions of which pid's
address spaces need to migrated so that we satisfy the constraints
given above.  I admit that this may be viewed as ugly, but I really
can't figure out a better solution than this without shuffling a
ton of ugly code into the kernel.
One issue that hasn't been addressed is the following:  given a
particular entry in /proc/pid/maps, how does one figure out whether
that entry is mapped into some other process in the system, one
that is not in the set of processes to be migrated?   One could
scan ALL of the /proc/pid/maps entries, I suppose, but that is
pretty expensive task on a 512 processor NUMA box.  The approach
I would like to follow would be to add a reference count to
/proc/pid/maps.  The reference could would tell how many VMAs
point at this particular /proc/pid/map entry.  Using this, if
all of the processes in the set to be migrated account for all
of the references, then this map entry represents an address
range that should be migrated.  If there are other references
then you shouldn't migrate the address range.
Note also that the data so reported represents a performance
optimization, not a correctness issue.  If some of the /proc/pid/map
info changes after we have read it and made our decision as
to what address ranges in which PIDs to migrate, the result
may be suboptimal performance.  But in most cases that we have
been able to think of where this could happen, it is not that
big of a deal.  (The typical example is library private.so
is used by an instance of batch job J1.  We decide to migrate
J1.  We look at the /proc/pid/maps info and find out that
only processes in J1 references private.so.  So we decide to migrate

ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Sergio Monteiro Basto]

What this message means ?

instead 
hdc=ide-scsi 
what should I put in options of boot kernel ?


please cc me with a quick reply.
for google the archives 

thanks,
-- 
Sérgio M.B.

-
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: Radeon FB troubles with recent kernels

[Matt Mackall]

On Tue, Feb 15, 2005 at 10:08:11AM +1100, Benjamin Herrenschmidt wrote:
> 
> > Appeared ? hah... that's strange. X is known to fuck up the chip when
> > quit, but I wouldn't have expected any change due to the new version of
> > radeonfb. From what you describe, it looks like an offset register is
> > changed by X, or the surface control.
> > 
> > My patch did not change any of radeonfb accel code though...
> > 
> > I'll catch up with you on IRC ...
> 
> Ok, from our discussions, it's not related to the power management code,
> and an engine reset triggered by fbset fixes it. So at this point, I can
> see no change in the driver explaining it...
> 
> We did some changes to the VT layer to force a mode setting (and thus an
> engine reset) when going away from X, so I can't see why that wouldn't
> work, while using fbset later on works ... this goes through the same
> code path in the driver... unless we are facing a timing issue...
> 
> X is known to play funny tricks, like touching the engine when it's in
> the background (not frontmost VT) and quit, or possibly other bad things
> on console switch. Maybe I changed enough delays (speeded up) the mode
> switch so that we fall into a case where X has not finished mucking up
> with us...
> 
> Can you try adding some msleep(200) or so at the beginning at
> radeonfb_set_par() or radeon_write_mode() to see if that makes any
> difference ?

Nope. No printk outputs from _set_par, _write_mode, or _engine_init.

Just to clarify: the gdm stop is done from tty1 while gdm is running
on tty7, so I don't think it's a matter of mode switch logic.

If I do "sleep 5; /etc/init.d/gdm stop" and then switch to tty7 and
wait for it to stop, all is fine.


Also, I'm still seeing the LCD blooming + hang on starting radeonfb.
It's something like 1 in 10 boots rather than every boot now though.

-- 
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: PATCH: Address lots of pending pm_message_t changes

[Nigel Cunningham]

Hi.

On Tue, 2005-02-15 at 11:15, Pavel Machek wrote:
> Hi!
> 
> > > > I guess I'm wrong then - I thought the other changes avoided compilation
> > > > errors.
> > > 
> > > Well, yes, if you switch pm_message_t into struct. But we are not yet
> > > ready to do that... it is going to be typedefed to u32 for 2.6.11...
> > 
> > Ah. So I haven't realised that Bernard took your patches wholesale,
> > which is why we're fixing the compile errors too :>
> > 
> > Okay then, I guess the whole thing isn't urgent then?
> 
> Well, it would be nice to be able to switch to struct pm_message_t
> very soon in 2.6.12 cycle, so that it actually works in 2.6.12...

Okay.. but it can wait until post 2.6.11, right?

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

-
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Tim Bird]

Lee Revell wrote:
> But, I was referring more to things like GDM not being started until all
> the other init scripts are done.  Why not start it first, and let the
> network initialize while the user is logging in?

There are a number of techniques used by CE vendors to get fast bootup
time.  Some CE products boot Linux in under 1 second.  Sony's
best Linux boot time in the lab (from power on to user space)
was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).

Every product I know of that boots in under 1 second does it
by completely eliminating RC scripts, and using a custom init
program.

For anyone interested, CELF has some resources on this topic at:
http://tree.celinuxforum.org/CelfPubWiki/BootupTimeResources

=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=
-
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: Address lots of pending pm_message_t changes

[Pavel Machek]

Hi!

> > > I guess I'm wrong then - I thought the other changes avoided compilation
> > > errors.
> > 
> > Well, yes, if you switch pm_message_t into struct. But we are not yet
> > ready to do that... it is going to be typedefed to u32 for 2.6.11...
> 
> Ah. So I haven't realised that Bernard took your patches wholesale,
> which is why we're fixing the compile errors too :>
> 
> Okay then, I guess the whole thing isn't urgent then?

Well, it would be nice to be able to switch to struct pm_message_t
very soon in 2.6.12 cycle, so that it actually works in 2.6.12...

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

Re: PATCH: Address lots of pending pm_message_t changes

[Nigel Cunningham]

Hi.

On Tue, 2005-02-15 at 10:41, Pavel Machek wrote:
> > I guess I'm wrong then - I thought the other changes avoided compilation
> > errors.
> 
> Well, yes, if you switch pm_message_t into struct. But we are not yet
> ready to do that... it is going to be typedefed to u32 for 2.6.11...

Ah. So I haven't realised that Bernard took your patches wholesale,
which is why we're fixing the compile errors too :>

Okay then, I guess the whole thing isn't urgent then?

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

-
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: [BK] upgrade will be needed

[Larry McVoy]

On Mon, Feb 14, 2005 at 03:23:47PM -0800, David Lang wrote:
> Larry, I don't think he's talking about making the free bk be a striped 
> down version, I think he's talking about having two different free 
> versions.

Leaving aside the $600K/year or so it would cost us to do that...

> this does mean that there would be somehat of a commiter/non-commiter 
> split, with the difference between them being those who agree to the 
> non-compete license of #1 and those who don't and use #2 to have a local 
> read-only copy and have to use normal patches to submit changes up the 
> tree.

And how does the CVS gateway not provide this today?  We effectively
have exactly what you are describing.  And long ago I offered what I
called the tarball + patch server with an open source client for all
trees on bkbits.net - here it is:  http://lkml.org/lkml/2003/12/14/47
If people had stopped flaming long enough to look at that it would 
be installed on bkbits today and any repo hosted there would have an
automatic real-time gateway with no license problems.  Heck, we could
even export the changeset comments into ChangeLog as Keith suggested
here: http://lkml.org/lkml/2003/12/14/92 .  

People didn't seem interested and I came with the conclusion, rightly or
wrongly, that the vast majority of the people who did real work didn't
care about the license and the noisy people just wanted to pick a fight.
If I was wrong and this is valuable I can look into putting it up on
bkbits.net.
-- 
---
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: Radeon FB troubles with recent kernels

[Antonino A. Daplas]

On Tuesday 15 February 2005 07:08, Benjamin Herrenschmidt wrote:
> > Appeared ? hah... that's strange. X is known to fuck up the chip when
> > quit, but I wouldn't have expected any change due to the new version of
> > radeonfb. From what you describe, it looks like an offset register is
> > changed by X, or the surface control.
> >
> > My patch did not change any of radeonfb accel code though...
> >
> > I'll catch up with you on IRC ...
>
> Ok, from our discussions, it's not related to the power management code,
> and an engine reset triggered by fbset fixes it. So at this point, I can
> see no change in the driver explaining it...
>
> We did some changes to the VT layer to force a mode setting (and thus an
> engine reset) when going away from X, so I can't see why that wouldn't
> work, while using fbset later on works ... this goes through the same
> code path in the driver... unless we are facing a timing issue...

You can also try inserting something like this before register_framebuffer()

info->flags |= FBINFO_MISC_MODESWITCHLATE;

to delay the call to set_par as late as possible.  It's the same hack used
in rivafb, but there were reports before that it does not work with a few 
radeon setups.

Tony

>
> X is known to play funny tricks, like touching the engine when it's in
> the background (not frontmost VT) and quit, or possibly other bad things
> on console switch. Maybe I changed enough delays (speeded up) the mode
> switch so that we fall into a case where X has not finished mucking up
> with us...
>
> Can you try adding some msleep(200) or so at the beginning at
> radeonfb_set_par() or radeon_write_mode() to see if that makes any
> difference ?
>
> Some printk's in there would help to... I expect calls to
> radeon_engine_init() to fix it and such a call is present in the mode
> restore unless accel is disabled...
>
> Can you check what's happening ?
>
> 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/

udev and cdsymlinks

[J.A. Magallon]

Hi all...

There are some problems with current udev. I wil try to propose an acceptable
solution (ie, patch ;) ).

My problems are with cdsymlinks (the C version, mandrake cooker uses that;
all I say is applicable also to the bash version).

Problems with udev-053:cdymlinks.c:

- Does not obey the NUMBERED_LINKS flag. Just a problem with string lengths.
  Fixed below.
- The nunbered links sould always be present (ie, kill NUMBERED_LINKS).
  Why ?
- In a box with several optical units, you obviously need numbered links.
  You also need a 'default' unit for each class (cdrom, dvd, cdrw...)
- In a box with only one unit, you also need the numbered links for
  compatibility (a program can try to open cdrom{i}, i in 0.., ) until
  it fails...)
- In a box with just one DVDRW it fails, typo in the strtok.

Is this patch acceptable ?

TIA

--- cdsymlinks.c.orig   2005-02-14 23:18:16.0 +0100
+++ cdsymlinks.c2005-02-15 00:30:16.0 +0100
@@ -55,7 +55,6 @@
 
 /* Configuration variables */
 static struct list_t allowed_output = {0};
-static int numbered_links = 1;
 
 /* Available devices */
 static struct list_t Devices = {0};
@@ -218,7 +217,7 @@
 list_assign_split (struct list_t *list, char *text)
 {
   char *token = strchr (text, ':');
-  token = strtok (token ? token + 1 : text, " \t");
+  token = strtok (token ? token + 1 : text, " \t\n");
   while (token)
   {
 list_prepend (list, token);
@@ -267,8 +266,6 @@
 list_delete (_output);
 list_assign_split (_output, p.we_wordv[0] + 7);
   }
-  else if (!strncmp (p.we_wordv[0], "NUMBERED_LINKS=", 14))
-numbered_links = atoi (p.we_wordv[0] + 14);
   break;
}
/* fall through */
@@ -325,9 +322,9 @@
   list_assign_split (_CDRW, text);
 else if (!strncasecmp (text, "Can write CD-R", 14))
   list_assign_split (_CDR, text);
-else if (!strncasecmp (text, "Can read MRW", 14))
+else if (!strncasecmp (text, "Can read MRW", 12))
   list_assign_split (_CDMRW, text);
-else if (!strncasecmp (text, "Can write MRW", 14))
+else if (!strncasecmp (text, "Can write MRW", 13))
   list_assign_split (_CDWMRW, text);
   }
   if (!feof (info))
@@ -408,24 +405,30 @@
*/
   present = 1;
   if (isdev)
-printf (" %s", list_nth (, li)->data);
+printf ("%s ", list_nth (, li)->data);
 }
 
 /* If we found no existing symlinks for the target device... */
 if (!present)
 {
   char buf[256];
-  snprintf (buf, sizeof (buf), count ? "%s%d" : "%s", link, count);
-  /* Find the next available (not present) symlink name.
-   * We always need to do this for reasons of output consistency: if a
-   * symlink is created by udev as a result of use of this program, we
-   * DON'T want different output!
-   */
-  while (list_search (, buf))
-snprintf (buf, sizeof (buf), "%s%d", link, ++count);
-  /* If ISDEV, output it. */
-  if (isdev && (numbered_links || count == 0))
-printf (" %s", buf);
+  if (!count) 
+ {
+snprintf (buf, sizeof (buf), "%s", link);
+if (isdev && !list_search (, buf))
+  printf ("%s ", buf);
+ }
+ /* Find the next available (not present) symlink name.
+  * We always need to do this for reasons of output consistency: if a
+  * symlink is created by udev as a result of use of this program, we
+  * DON'T want different output!
+  */
+ snprintf (buf, sizeof (buf), "%s%d", link, count);
+ while (list_search (, buf))
+   snprintf (buf, sizeof (buf), "%s%d", link, ++count);
+ /* If ISDEV, output it. */
+ if (isdev)
+   printf ("%s ", buf);
   /* If the link isn't in our "existing links" list, add it and increment
* our counter.
*/

--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-jam9 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1



pgpW8LKVVeuzI.pgp
Description: PGP signature

Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Ray Bryant]

Andi Kleen wrote:
But how do you use mbind() to change the memory placement for an anonymous
private mapping used by a vendor provided executable with mbind()?

For that you use set_mempolicy.
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [EMAIL PROTECTED]  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"[EMAIL PROTECTED]"> [EMAIL PROTECTED] 
Andi,
If all processes are guarenteed to use the NUMA api for memory placement,
then AFAIK one could, in principle, imbed the migration of pages into
the NUMA api as you propose.  The problem is that AFAIK most programs
that we run are not using the NUMA api.  Instead, they are using first-touch
with the knowledge that such pages will be allocated on the node where they
are first referenced.
Since we have to build a migration facility that will migrate jobs that
use both the NUMA API and the first-touch approach, it seems to me the
only plausible soluion is to move the pages via a migration facility
and then if there are NUMA API control structures found associated with
the moved pages to update them to represent the new reality.  Whether
this happens as an automatic side effect of the migration call or it
happens by a issuing a new set_mempolicy() is not clear to me.  I would
prefer to just issue a new set_mempolicy(), but somehow the migration
code will have to figure out where this call needs to be executed (i. e.
which pages have an associated NUMA policy).  [Thus the disclaimer in
the overview note that we have figured all the interaction with
memory policy stuff yet.]
--
---
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[EMAIL PROTECTED] [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
 so I installed Linux.
---
-
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: IEEE-1394 and disks

[Jody McIntyre]

On Thu, Jan 20, 2005 at 01:23:47PM -0700, Trever L. Adams wrote:
> By bridge chips I mean IEEE-1394 to IDE. Also, is it possible to set
> spin down time for these IDE disks through 1394? i.e. if they are
> inactive for 1 hour, I would like them to spin down. Is this possible?

Not currently.  I'm not sure if this is a hardware limitation or just
something that isn't implemented yet.

Jody

> 
> Trever
-
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] Call for help: list of machines with working S3

[Matthew Garrett]

On Mon, 2005-02-14 at 23:23 +, Matthew Garrett wrote:
> On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote:
> > Hi!
> > 
> > Stefan provided me initial list of machines where S3 works (including
> > video). If you have machine that is not on the list, please send me a
> > diff. If you have eMachines... I'd like you to try playing with
> > vbetool (it worked for me), and if it works for you supplying right
> > model numbers.
> 
> http://www.ubuntulinux.org/wiki/HoaryPMTesting has a list of several
> working machines. HP seem to be the worst supported at the moment.

Sorry - that should be http://www.ubuntulinux.org/wiki/HoaryPMResults

-- 
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: Address lots of pending pm_message_t changes

[Pavel Machek]

Hi!

> > > > > Andrew, if you get one big patch doing only type-safety (u32 ->
> > > > >  pm_message_t, no code changes), would you still take it this late? I
> > > > >  promise it is not going to break anything... It would help merge 
> > > > > after
> > > > >  2.6.11 quite a lot...
> > > > 
> > > > Problem is, such a megapatch causes grief for all those people who 
> > > > maintain
> > > > their own trees.  It would be best, please, to split it into 10-20 bits 
> > > > and
> > > > send the USB parts to Greg and the SCSI bits to James, etc.
> > > 
> > > Okay; I can do that if everyone is happy with the thing as a whole.
> > > Andrew, can I get your answer on Pavel's question - shall I just include
> > > the u32->pm_message_t part?
> > 
> > Yes, I believe it is too late to do anything than u32->pm_message_t
> > conversion that changes no code...
> 
> I guess I'm wrong then - I thought the other changes avoided compilation
> errors.

Well, yes, if you switch pm_message_t into struct. But we are not yet
ready to do that... it is going to be typedefed to u32 for 2.6.11...

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

[OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Lee Revell]

On Mon, 2005-02-14 at 15:21 -0800, Roland Dreier wrote:
> Lee> I don't see why so much effort goes into improving boot time
> Lee> on the kernel side when the most obvious user space problem
> Lee> is ignored.
> 
> How much of a win is it to run init scripts in parallel?  I seem to
> recall seeing tests that show that it doesn't make much difference and
> may even slow things down by causing more disk seeks as various things
> start up at the same time and cause reads of different files to get
> interleaved.
> 

This is why Windows XP reserves sapce at the beginning of the disk for
the files read during the boot process and caches copies of them there.

But, I was referring more to things like GDM not being started until all
the other init scripts are done.  Why not start it first, and let the
network initialize while the user is logging in?

> On the other hand, hotplug is an area that real profiling of real
> systems booting has identified as something that can be improved, and
> Greg's hotplug-ng seems to be a step towards a measurable improvement.

Agreed.

Lee

-
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

[Diego Calleja]

El Mon, 14 Feb 2005 18:04:00 -0500,
Lee Revell <[EMAIL PROTECTED]> escribió:

> Last I heard Gentoo does not even do it by default.
> 
> I don't see why so much effort goes into improving boot time on the
> kernel side when the most obvious user space problem is ignored.


There's stuff that it could be done in the kernel to help improving those 
numbers,
IMHO.

xp logs all the io done the first two minutes after booting. The next time it 
boots
it tries to read all those files at once so the programs will find stuff in 
memory
instead of having to do lots of small seeks. Some people in the linux field have
got a list of the files used at startup and they've thrown it at a "readhead" 
script,
which seems to help but IMHO it's somewhat "hacky" compared with the 
xp's trick. xp also does that when you start a program, it saves a log of all 
the
io done and it preloads it efficiently at startup - it improves "cold-cache" 
loading
times a _lot_. I haven't seen any alternative for that in the linux world, and
being able to keep track of al the io done by a given process would fix that 
(some
people has put used printk's for that, but i think it can be done better)

Also, it analyzes all those io "logs" and defragments (in background every 3 
days,
and with low load without the user noticing it) the disk according to the _use_ 
of the
systems. Linux kernel can keep a file unfragmented, but currently there's no way
linux can do decisions like "this system starts openoffice, so I'm going to 
move the
binaries to another place of the disk where they'll load faster" or "when X 
program
uses /lib/libfoo.so it also uses /lib/libbar.so, so I'm going to put those two 
together
in the disk because that will avoid seeks". Kernel only can keep a single file
unfragmented, but it doesn't know about how several files must be (un)fragmented
between them. Being able to defragment things seems to be the one fix that (even
mac os x does it)

Userspace is where the problem is, but it's not going to be fixed. Ever. If
something, it's going to be worse - it's how software works. And even if you 
make
openoffice "fast", you still could _improve_ things with the tricks described
above. Disks are too slow, and things like demand-loading executables generate
too many small seeks, and programs can't control demand-loading so I don't
think userspace is the only with work to do.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] add timing information to printk messages

[Tim Bird]

Here's a little patch which is useful for showing timing information for
kernel bootup activities.

This patch adds a new Kconfig option under "Kernel Hacking" and a new
option for the kernel command line.  It also provides a script for
showing delta information.

Note that the timing data may not be correct on some platforms until
after time_init() is called.

Recently (as of about 2.6.10) I found that the message log produced by
dmesg is truncated when I use this feature.  That is, the first few printk
messages of the boot sequence are not in the dmesg output, although
they are printed to console during startup.  This is a new behavior -
dmesg output was fine as of 2.6.9.  Increasing CONFIG_LOG_BUF_SHIFT
had no effect on the truncation.

Has something changed with printk recently?

For more information on this patch, see:
http://tree.celinuxforum.org/CelfPubWiki/InstrumentedPrintk

Here's some sample output:
...
[4294667.296000] Kernel command line: ro root=/dev/nfs ip=dhcp hdc=ide-scsi 
console=vga console=ttyS0,115200
[4294667.296000] ide_setup: hdc=ide-scsi
[4294667.296000] Initializing CPU#0
[4294667.296000] PID hash table entries: 512 (order: 9, 8192 bytes)
[0.00] Detected 1995.620 MHz processor.
[   21.397369] Using tsc for high-res timesource
[   21.399820] Console: colour VGA+ 80x25
[   21.537244] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[   21.544547] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[   21.555066] Memory: 125076k/130240k available (2002k kernel code, 4556k 
reserved, 1006k data, 140k init, 0k highmem)
[   21.565775] Checking if this processor honours the WP bit even in supervisor 
mode... Ok.
[   21.574089] Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176)
[   21.596511] Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
[   21.603263] CPU: After generic identify, caps: bfebfbff   
 4400  
[   21.603276] CPU: After vendor identify, caps: bfebfbff   
 4400  
[   21.603287] CPU: Trace cache: 12K uops, L1 D cache: 8K
[   21.608884] CPU: L2 cache: 128K
...


Output from diffinfo:
 Documentation/kernel-parameters.txt |2+ 0- (1 hunk)
 kernel/printk.c |   54+ 4- (2 hunks)
 lib/Kconfig.debug   |9+ 0- (1 hunk)
 scripts/show_delta  N  129+ 0- (1 hunk)
 4 files changed, 194 insertions(+), 4 deletions(-), 5 hunks

And now the patch...

Signed-off-by: Tim Bird 


diff -pruN linux-2.6.11-rc4.orig/Documentation/kernel-parameters.txt 
linux-2.6.11-rc4/Documentation/kernel-parameters.txt
--- linux-2.6.11-rc4.orig/Documentation/kernel-parameters.txt   2005-02-14 
11:46:47.0 -0800
+++ linux-2.6.11-rc4/Documentation/kernel-parameters.txt2005-02-14 
13:14:13.0 -0800
@@ -1356,6 +1356,8 @@ running once the system is up.
thash_entries=  [KNL,NET]
Set number of hash buckets for TCP connection

+   timeShow timing data prefixed to each printk message line
+
tipar.timeout=  [HW,PPT]
Set communications timeout in tenths of a second
(default 15).
diff -pruN linux-2.6.11-rc4.orig/kernel/printk.c 
linux-2.6.11-rc4/kernel/printk.c
--- linux-2.6.11-rc4.orig/kernel/printk.c   2005-02-14 11:46:50.0 
-0800
+++ linux-2.6.11-rc4/kernel/printk.c2005-02-14 13:12:50.0 -0800
@@ -499,6 +499,22 @@ static void zap_locks(void)
init_MUTEX(_sem);
 }

+#if defined(CONFIG_PRINTK_TIME)
+static int printk_time = 1;
+#else
+static int printk_time = 0;
+#endif
+
+static int __init printk_time_setup(char *str)
+{
+   if (*str)
+   return 0;
+   printk_time = 1;
+   return 1;
+}
+
+__setup("time", printk_time_setup);
+
 /*
  * This is printk.  It can be called from any context.  We want it to work.
  *
@@ -547,10 +563,44 @@ asmlinkage int vprintk(const char *fmt,
 */
for (p = printk_buf; *p; p++) {
if (log_level_unknown) {
-   if (p[0] != '<' || p[1] < '0' || p[1] > '7' || p[2] != 
'>') {
-   emit_log_char('<');
-   emit_log_char(default_message_loglevel + '0');
-   emit_log_char('>');
+/* log_level_unknown signals the start of a new line */
+   if (printk_time) {
+   int loglev_char;
+   char tbuf[50], *tp;
+   unsigned tlen;
+   unsigned long long t;
+   unsigned long nanosec_rem;
+   
+   /*
+* force the log level token to be
+* before the time output.
+   

Re: [PATCH] 4/5: LSM hooks rework

[Rik van Riel]

On Tue, 15 Feb 2005, Kurt Garloff wrote:
I sent out the full patch set, which moves the code from
vanilla to the code we've been shipping since 7 months.
Heh, it sounds like such a step back when it's said like that ;)
If we can't find consensus for patches 4 and 5, I'd still
think applying 1 -- 3 is useful.
I'll take a look at the other patches.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
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

[Lee Revell]

On Mon, 2005-02-14 at 15:16 -0800, Greg KH wrote:
> > I don't see why so much effort goes into improving boot time on the
> > kernel side when the most obvious user space problem is ignored.
> 
> What user space problem is that?

That init scripts with no interdependencies are run sequentially rather
than in parallel.

There was an article from IBM a while back with a neat hack that used a
parallel make to fire off groups of init scripts in parallel.  I would
expect more interest in this from the distros.

Lee

-
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: [BK] upgrade will be needed

[Gerold Jury]

>if they really need the more powerful features.  Or we could donate
>some on a case by case basis.
>
>If the hackers who are using BK can reach agreement that it would be
>better if the BK they had didn't move forward unless they got commercial
>seats then we could start moving towards a license on the free product
>that was less restrictive.  What that would mean is that the BK you have

I want to pay the fee for Linus and Alan.

Regards
Gerold
-
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: [BK] upgrade will be needed

[Marcin Dalecki]

On 2005-02-14, at 19:56, Larry McVoy wrote:
All we are trying to do is
1.  Provide the open source community with a useful tool.
2.  Prevent that from turning into the open source community
creating a clone of our tool.
Now that's pathetic!
You recognize that point 2. is precisely the reason Linux is all about
in first place? Remind you: Linux - a free UNIX/POSIX system
clone done by people who where previously working on UNIX in first place
and just wanted a free version of it. By definition it is just that...
And in this copy-cat community you intend to thrive as "Mother Theresa" 
of SCM?
You still wonder why you provoke disgruntling?

-
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] 4/5: LSM hooks rework

[Kurt Garloff]

Hi Rik,

On Mon, Feb 14, 2005 at 11:54:07AM -0500, Rik van Riel wrote:
> On Sun, 13 Feb 2005, Kurt Garloff wrote:
> 
> >The case that security_ops points to the default capability_
> >security_ops is the fast path and arguably the more likely one
> >on most systems.
> 
> Quite a few distributions ship with other security modules
> enabled by default, so I'm not sure we should add a "likely"
> here - let the CPU's branch prediction sort things out.

Fine with me. I had the fast path in mind, but with some
luck, CPU branch prediction will work for us.

I sent out the full patch set, which moves the code from
vanilla to the code we've been shipping since 7 months.
And I made the changes in the order to make the ones that I
expect the least controversial come first.

If we can't find consensus for patches 4 and 5, I'd still
think applying 1 -- 3 is useful.

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.


pgpivii4RdFWn.pgp
Description: PGP signature

Re: [BK] upgrade will be needed

[David Lang]

Larry, I don't think he's talking about making the free bk be a striped 
down version, I think he's talking about having two different free 
versions.

version 1
what you have today with the license you need to protect yourself
version 2
a version with no check-in capability at all, all it can do is passivly 
mirror a repository to a local system and check-out a tree to a local 
system. since this version won't have any of your 'secret sauce merging 
stuff' in it it may be possible for you to use a license that doesn't need 
to include the non-compete clause.

anyone doing development would need version1, but there are a number of 
people who have bitkeeper installed but only use it to check out versions 
and really don't care about the differences between bk and cvs for this 
(and for this purpose the differences are mainly network efficiancies)

Assuming that this is techincaly posible (my memory is warning me that the 
pull from a remote repository may be a 'check-in' as things are currently 
written) I think the risk to you would that the new license would let some 
of the people who want to reverse-engineer things use this 'fetch-only' 
version and see some of the meta-data, I don't know if you can leave out 
enough of the stuff you care about to be willing to loose the rest.

As you acknowledged in your presentation this last weekend, the people at 
the bottom of the tree don't get much benifit from bitkeeper, this applies 
even more so to the people who are read-only to the system.

this does mean that there would be somehat of a commiter/non-commiter 
split, with the difference between them being those who agree to the 
non-compete license of #1 and those who don't and use #2 to have a local 
read-only copy and have to use normal patches to submit changes up the 
tree.

David Lang
 On Mon, 14 Feb 2005 [EMAIL PROTECTED] wrote:
Date: Mon, 14 Feb 2005 14:57:04 -0800
From: [EMAIL PROTECTED]
To: Gerold Jury <[EMAIL PROTECTED]>
Cc: Linux Kernel Mailing List ,
Jeff Sipek <[EMAIL PROTECTED]>,
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 11:24:43PM +0100, Gerold Jury wrote:
Hi Larry
Hi Everyone
Do you think it is possible to make a split licence that will distinguish
between active changes and passive watching/tracking ?
A lot of people have told us to create two products, the free product
and the commercial product, and license the free product with standard
licensing terms.  The expectation is that we would somehow make the free
product less desirable so that people bought the commercial product.
That's an excellent suggestion if our only goal is to make money, that
makes the free product sort of a teaser and the commercial product the
real deal.  However, the goal really is to help the open source
community, Linux in particular.  If we give away crippled software then
all the people who say we are just a money grubbing corporation are
more or less correct.  At that point we aren't giving away the good
stuff and it was always the goal that you got the latest and greatest
because that's what can do you the most good.
However, it sure sounds like the noisy people would be a lot happier
with a stripped down BK that didn't have as many of the restrictions.
And a possible out for even the open source users is that they buy seats
if they really need the more powerful features.  Or we could donate
some on a case by case basis.
If the hackers who are using BK can reach agreement that it would be
better if the BK they had didn't move forward unless they got commercial
seats then we could start moving towards a license on the free product
that was less restrictive.  What that would mean is that the BK you have
is basically it, we'd not advance it other than keeping it up to date
with the protocol and/or file formats of the commercial version.  If you
think BK is good enough, fast enough, done enough that you don't want
what we have coming down the pike we can go that route.
I suspect that the heavy lifters really would like a faster BK with more
features that help them get their job done but the rank and file could
care less, they just want checkin/checkout.
--
---
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/
--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
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] Call for help: list of machines with working S3

[Matthew Garrett]

On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote:
> Hi!
> 
> Stefan provided me initial list of machines where S3 works (including
> video). If you have machine that is not on the list, please send me a
> diff. If you have eMachines... I'd like you to try playing with
> vbetool (it worked for me), and if it works for you supplying right
> model numbers.

http://www.ubuntulinux.org/wiki/HoaryPMTesting has a list of several
working machines. HP seem to be the worst supported at the moment.

-- 
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] 5/5: LSM hooks rework

[Kurt Garloff]

Hi James,

On Mon, Feb 14, 2005 at 11:50:01AM -0500, James Morris wrote:
> On Sun, 13 Feb 2005, Kurt Garloff wrote:
> 
> >  /* Condition for invocation of non-default security_op */
> >  #define COND_SECURITY(seop, def)   \
> > -   (likely(security_ops == _security_ops))? def: 
> > security_ops->seop
> > +   (unlikely(security_enabled))? security_ops->seop: def
> 
> So this will cause a false unlikely() for every single SELinux hook,
> again.

A correct unlikely() in my book.

Yes, that was one of the reasons that I split up the patches.

There are people who believe that we should optimize for the 
slow path (SELinux) or at least not penalize it.
Fine with me, feel free to ignore patches 4, 5 then.

> This was rejected last year. 

It wasn't. The discussion did not come to a conclusion.

Best regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.


pgpAydeVcylqn.pgp
Description: PGP signature

Re: [ANNOUNCE] hotplug-ng 001 release

[Roland Dreier]

Lee> I don't see why so much effort goes into improving boot time
Lee> on the kernel side when the most obvious user space problem
Lee> is ignored.

How much of a win is it to run init scripts in parallel?  I seem to
recall seeing tests that show that it doesn't make much difference and
may even slow things down by causing more disk seeks as various things
start up at the same time and cause reads of different files to get
interleaved.

On the other hand, hotplug is an area that real profiling of real
systems booting has identified as something that can be improved, and
Greg's hotplug-ng seems to be a step towards a measurable improvement.

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

Re: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Mon, Feb 14, 2005 at 06:04:00PM -0500, Lee Revell wrote:
> On Mon, 2005-02-14 at 09:51 +0100, Prakash Punnoor wrote:
> > Paolo Ciarrocchi schrieb:
> > > On Sun, 13 Feb 2005 23:06:51 -0500, Lee Revell <[EMAIL PROTECTED]> wrote:
> > >
> > >>On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
> > >>
> > >>>All distros are trying to reduce boot time.
> > >>
> > >>They certainly aren't all trying very hard.  Debian and Fedora (last
> > >>time I checked) do not even run the init scripts in parallel.
> > >
> > >
> > > Is there any distro that is running the init scripts in parallel ?
> > 
> > Gentoo.
> > 
> 
> Last I heard Gentoo does not even do it by default.

Gentoo doesn't do much "by default" :)  But it is an option.

> I don't see why so much effort goes into improving boot time on the
> kernel side when the most obvious user space problem is ignored.

What user space problem is that?

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: fix iounmap and a pageattr memleak (x86 and x86-64)

[Andrea Arcangeli]

Hello,

the fix for this bug in 2.6.11-rc3 for this bug is wrong, I thought I
posted the right one (that I already applied to all SUSE branches except
the HEAD branch that probably is in sync with the inferior fix in
mainline). Right fix is the below one. And then of course drop those
useless -PAGE_SIZE in change_page_attr p->size parameter in the arch
code. Exposing vmalloc.c internal knowledge of the guard-page-size into
the arch code is an unnecssary breakage of the vmalloc abstraction and
I've been very careful to avoid that and I thought I posted it too. It
has been even quicker to fix it right for me in a single place than to
hand edit the (not single) change_page_attr callers. I'd like the right
fix to obsolete the hand editing of arch code in multiple places that
breaks the layering. Thanks.

From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: reject zero page vm-area request, align size properly
 and hide the guard page from the callers like ioremap - this avoids
 a kernel crash due one more page being passed to change_page_attr

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

--- sl9.2/mm/vmalloc.c.~1~  2004-12-04 01:44:23.352416128 +0100
+++ sl9.2/mm/vmalloc.c  2004-12-04 03:02:37.299827656 +0100
@@ -199,20 +199,22 @@ struct vm_struct *__get_vm_area(unsigned
align = 1ul << bit;
}
addr = ALIGN(start, align);
+   size = PAGE_ALIGN(size);
 
area = kmalloc(sizeof(*area), GFP_KERNEL);
if (unlikely(!area))
return NULL;
 
-   /*
-* We always allocate a guard page.
-*/
-   size += PAGE_SIZE;
if (unlikely(!size)) {
kfree (area);
return NULL;
}
 
+   /*
+* We always allocate a guard page.
+*/
+   size += PAGE_SIZE;
+
write_lock(_lock);
for (p =  (tmp = *p) != NULL ;p = >next) {
if ((unsigned long)tmp->addr < addr) {
@@ -290,6 +292,11 @@ found:
unmap_vm_area(tmp);
*p = tmp->next;
write_unlock(_lock);
+
+   /*
+* Remove the guard page.
+*/
+   tmp->size -= PAGE_SIZE;
return tmp;
 }
 



-
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: Radeon FB troubles with recent kernels

[Benjamin Herrenschmidt]

> Appeared ? hah... that's strange. X is known to fuck up the chip when
> quit, but I wouldn't have expected any change due to the new version of
> radeonfb. From what you describe, it looks like an offset register is
> changed by X, or the surface control.
> 
> My patch did not change any of radeonfb accel code though...
> 
> I'll catch up with you on IRC ...

Ok, from our discussions, it's not related to the power management code,
and an engine reset triggered by fbset fixes it. So at this point, I can
see no change in the driver explaining it...

We did some changes to the VT layer to force a mode setting (and thus an
engine reset) when going away from X, so I can't see why that wouldn't
work, while using fbset later on works ... this goes through the same
code path in the driver... unless we are facing a timing issue...

X is known to play funny tricks, like touching the engine when it's in
the background (not frontmost VT) and quit, or possibly other bad things
on console switch. Maybe I changed enough delays (speeded up) the mode
switch so that we fall into a case where X has not finished mucking up
with us...

Can you try adding some msleep(200) or so at the beginning at
radeonfb_set_par() or radeon_write_mode() to see if that makes any
difference ?

Some printk's in there would help to... I expect calls to
radeon_engine_init() to fix it and such a call is present in the mode
restore unless accel is disabled...

Can you check what's happening ?

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

[Lee Revell]

On Mon, 2005-02-14 at 09:51 +0100, Prakash Punnoor wrote:
> Paolo Ciarrocchi schrieb:
> > On Sun, 13 Feb 2005 23:06:51 -0500, Lee Revell <[EMAIL PROTECTED]> wrote:
> >
> >>On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
> >>
> >>>All distros are trying to reduce boot time.
> >>
> >>They certainly aren't all trying very hard.  Debian and Fedora (last
> >>time I checked) do not even run the init scripts in parallel.
> >
> >
> > Is there any distro that is running the init scripts in parallel ?
> 
> Gentoo.
> 

Last I heard Gentoo does not even do it by default.

I don't see why so much effort goes into improving boot time on the
kernel side when the most obvious user space problem is ignored.

Lee

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