the resulting patch can be applied with patch -p1.
This seems to be a common mistake.
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
--- linux-2.6.11/Documentation/SubmittingPatches.ori2005-03-05
21:29:26.0 +0100
+++ linux-2.6.11/Documentation/SubmittingPatches2005-03-05
21:38
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Would it not be simpler to just add "resume=03:02" to the boot command line?
Some devices have random device numbers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Andrew Morton [EMAIL PROTECTED] wrote:
Would it not be simpler to just add resume=03:02 to the boot command line?
Some devices have random device numbers.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Melkor Ainur <[EMAIL PROTECTED]> wrote:
> Is there a way for a user space app to get a signal or
> maybe woken up from select/read when there is a change
> on a particular input pin on the parallel port?
The easiest hack I can think of is: Change the db9-driver to be freely
configurable and make
Melkor Ainur [EMAIL PROTECTED] wrote:
Is there a way for a user space app to get a signal or
maybe woken up from select/read when there is a change
on a particular input pin on the parallel port?
The easiest hack I can think of is: Change the db9-driver to be freely
configurable and make
On Wed, 23 Feb 2005, linux-os wrote:
> On Wed, 23 Feb 2005, Bodo Eggert wrote:
> > linux-os <[EMAIL PROTECTED]> wrote:
> >> You don't seem to understand. A process that's stuck in 'D' state
> >> shows a SEVERE error, usually with a hardware driver.
>
On Wed, 23 Feb 2005, linux-os wrote:
On Wed, 23 Feb 2005, Bodo Eggert wrote:
linux-os [EMAIL PROTECTED] wrote:
You don't seem to understand. A process that's stuck in 'D' state
shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing
linux-os <[EMAIL PROTECTED]> wrote:
> You don't seem to understand. A process that's stuck in 'D' state
> shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing server or share.
> For instance,
> somebody may have coded something in a
linux-os [EMAIL PROTECTED] wrote:
You don't seem to understand. A process that's stuck in 'D' state
shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing server or share.
For instance,
somebody may have coded something in a critical
Der Herr Hofrat <[EMAIL PROTECTED]> wrote:
> cd /proc/8655
> kill -9 8655
> ls
> /usr/bin/ls: .: Stale NFS file handle
Seems to be fixed in 2.6.10-ac9 or earlier
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Der Herr Hofrat [EMAIL PROTECTED] wrote:
cd /proc/8655
kill -9 8655
ls
/usr/bin/ls: .: Stale NFS file handle
Seems to be fixed in 2.6.10-ac9 or earlier
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote:
>> Rene Scharfe <[EMAIL PROTECTED]> wrote:
>> > Add proc.umask kernel parameter. It can be used to restrict permissions
>> > on the numerical directories in the root of a proc filesystem,
Herbert Poetzl [EMAIL PROTECTED] wrote:
On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote:
Rene Scharfe [EMAIL PROTECTED] wrote:
Add proc.umask kernel parameter. It can be used to restrict permissions
on the numerical directories in the root of a proc filesystem, i.e. the
lifier control
*03.01.2003 0.32 open_mode fixes from Georg Acher <[EMAIL PROTECTED]>
+ *22.01.2004 0.33 fix output of joystick address
+ * by Bodo Eggert <[
control
*03.01.2003 0.32 open_mode fixes from Georg Acher [EMAIL PROTECTED]
+ *22.01.2004 0.33 fix output of joystick address
+ * by Bodo Eggert [EMAIL PROTECTED]
*/
/*/
@@ -2849,8
Kendall Bennett <[EMAIL PROTECTED]> wrote:
> Laptops are a little different as they will make calls from the Video
> BIOS into the system BIOS, so you need to make sure that the system BIOS
> is also available in the execution environment.
Any video BIOS (especially EGA) may call system BIOS
Kendall Bennett [EMAIL PROTECTED] wrote:
Laptops are a little different as they will make calls from the Video
BIOS into the system BIOS, so you need to make sure that the system BIOS
is also available in the execution environment.
Any video BIOS (especially EGA) may call system BIOS
This oops happened while watching TV and burning a CD. Other oopses (I
guess, didn't verify at that time) happened while copying many large
files and watching TV at the same time.
Note1: /proc/ksyms does not exist. What to do?
Note2: ksymoops prints this error message to /dev/stderr:
On Sun, 6 Feb 2005, Neil Conway wrote:
> Since writing the above, I've been searching for more info. I
> downloaded four different versions of grub (GNU Grub Legacy, GNU Grub2,
> gentoo and Fedora Core 3). NONE of these showed any evidence of GPT
> support (I was in a hurry, so I searched for
On Sun, 6 Feb 2005, Neil Conway wrote:
Since writing the above, I've been searching for more info. I
downloaded four different versions of grub (GNU Grub Legacy, GNU Grub2,
gentoo and Fedora Core 3). NONE of these showed any evidence of GPT
support (I was in a hurry, so I searched for
This oops happened while watching TV and burning a CD. Other oopses (I
guess, didn't verify at that time) happened while copying many large
files and watching TV at the same time.
Note1: /proc/ksyms does not exist. What to do?
Note2: ksymoops prints this error message to /dev/stderr:
Neil Conway <[EMAIL PROTECTED]> wrote:
> I thought sure I had read somewhere that typical x86 PC BIOSes just
> didn't understand the GPT ptbl, and thus couldn't boot from a GPT'ed
> disk.
No common x86 BIOS can understand any partition table. Booting is done by
loading the first sector of the
Neil Conway [EMAIL PROTECTED] wrote:
I thought sure I had read somewhere that typical x86 PC BIOSes just
didn't understand the GPT ptbl, and thus couldn't boot from a GPT'ed
disk.
No common x86 BIOS can understand any partition table. Booting is done by
loading the first sector of the boot
John Richard Moser <[EMAIL PROTECTED]> wrote:
> What systems exist for complex logging and security auditing in the kernel?
>
> For example, let's say I wanted to register my specific code (i.e. a
> security module) to log, and adjust to log level N. I also want another
> module to log at log
John Richard Moser [EMAIL PROTECTED] wrote:
What systems exist for complex logging and security auditing in the kernel?
For example, let's say I wanted to register my specific code (i.e. a
security module) to log, and adjust to log level N. I also want another
module to log at log level L,
: es1371 joystick at 0x218
Signed-off-by: Bodo Eggert <[EMAIL PROTECTED]>
--- sound/oss/es1371.c.ori 2005-01-22 17:38:10.180308592 +0100
+++ sound/oss/es1371.c 2005-01-22 18:11:25.919910056 +0100
@@ -105,6 +105,8 @@
* Fix SETTRIGGER non OSS API conformity
*14.0
: es1371 joystick at 0x218
Signed-off-by: Bodo Eggert [EMAIL PROTECTED]
--- sound/oss/es1371.c.ori 2005-01-22 17:38:10.180308592 +0100
+++ sound/oss/es1371.c 2005-01-22 18:11:25.919910056 +0100
@@ -105,6 +105,8 @@
* Fix SETTRIGGER non OSS API conformity
*14.07.2001
Mario Holbe <[EMAIL PROTECTED]> wrote:
> I understand the point that the device's blocksize affects the device's
> length... obviously a block device can only consist of full blocks,
> not half a block or something like that.
> However, if that's right, a block device's length should IMHO also be
Mario Holbe [EMAIL PROTECTED] wrote:
I understand the point that the device's blocksize affects the device's
length... obviously a block device can only consist of full blocks,
not half a block or something like that.
However, if that's right, a block device's length should IMHO also be
On Thu, 20 Jan 2005, Edjard Souza Mota wrote:
> > > > What about creating a linked list of (stackable) algorhithms which can
> > > > be
> > > > extended by loading modules and resorted using {proc,sys}fs? It will
> > > > avoid
> > > > the extra process, the extra CPU time (and task switches) to
Ed L Cashin <[EMAIL PROTECTED]> wrote:
> +if test -z "$conf"; then
> +conf="`find /etc -type f -name udev.conf 2> /dev/null`"
> +fi
> +if test -z "$conf" || test ! -r $conf; then
> +echo "$me Error: could not find readable udev.conf in /etc" 1>&2
> +exit 1
> +fi
This will
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> 1) Unconditionally execute make install assuming vmlinux is up-to-date.
>make modules_install run unconditionally, so this is already know
>practice
(o) Vote for this.
IMO, a make install should NEVER run the compiler.
The reason is: I'm
Sam Ravnborg [EMAIL PROTECTED] wrote:
1) Unconditionally execute make install assuming vmlinux is up-to-date.
make modules_install run unconditionally, so this is already know
practice
(o) Vote for this.
IMO, a make install should NEVER run the compiler.
The reason is: I'm deliberaely
Ed L Cashin [EMAIL PROTECTED] wrote:
+if test -z $conf; then
+conf=`find /etc -type f -name udev.conf 2 /dev/null`
+fi
+if test -z $conf || test ! -r $conf; then
+echo $me Error: could not find readable udev.conf in /etc 12
+exit 1
+fi
This will fail and print
---
On Thu, 20 Jan 2005, Edjard Souza Mota wrote:
What about creating a linked list of (stackable) algorhithms which can
be
extended by loading modules and resorted using {proc,sys}fs? It will
avoid
the extra process, the extra CPU time (and task switches) to frequently
On Tue, 18 Jan 2005, Edjard Souza Mota wrote:
> > If my system needs the OOM killer, it's usurally unresponsive to most
> > userspace applications. A normal daemon would be swapped out before the
> > runaway dhcpd grows larger than the web cache. It would have to be a mlocked
> > RT task started
On Tue, 18 Jan 2005, Edjard Souza Mota wrote:
If my system needs the OOM killer, it's usurally unresponsive to most
userspace applications. A normal daemon would be swapped out before the
runaway dhcpd grows larger than the web cache. It would have to be a mlocked
RT task started from
Edjard Souza Mota wrote:
> What do you think about the point we are trying to make, i.e., moving the
> ranking of PIDs to be killed to user space?
If my system needs the OOM killer, it's usurally unresponsive to most
userspace applications. A normal daemon would be swapped out before the
runaway
Edjard Souza Mota wrote:
What do you think about the point we are trying to make, i.e., moving the
ranking of PIDs to be killed to user space?
If my system needs the OOM killer, it's usurally unresponsive to most
userspace applications. A normal daemon would be swapped out before the
runaway
701 - 739 of 739 matches
Mail list logo
