Re: [ck] Re: RSDL v0.30 cpu scheduler for mainline kernels
On 3/13/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: On Tue, Mar 13, 2007 at 02:05:23PM +1100, Con Kolivas wrote: > On Tuesday 13 March 2007 10:46, David Miller wrote: > > From: Con Kolivas <[EMAIL PROTECTED]> > > Date: Mon, 12 Mar 2007 10:58:11 +1100 > > > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-sched-rsdl-0. > > >30.patch > > > > FWIW, this boots and seems to work well on sparc64. Tested > > on UP SunBlade1500 and 24cpu Niagara T1000. > > Very nice. Thanks for the feedback and I'm sorry you have to work with such > lousy hardware. BTW, I don't know if you say this as a joke, but those are not necessarily lousy hardware. Sun does lousy hardware when they put Sparcs in PCs (ultra5, ultra10, blade100). But their servers generally are nice with large memory busses and very scalable SMP architectures. I guess Con was kidding. A 24-CPU system can be anything but lousy hardware. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ck] Re: RSDL v0.30 cpu scheduler for mainline kernels
On 3/13/07, Willy Tarreau [EMAIL PROTECTED] wrote: On Tue, Mar 13, 2007 at 02:05:23PM +1100, Con Kolivas wrote: On Tuesday 13 March 2007 10:46, David Miller wrote: From: Con Kolivas [EMAIL PROTECTED] Date: Mon, 12 Mar 2007 10:58:11 +1100 http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-sched-rsdl-0. 30.patch FWIW, this boots and seems to work well on sparc64. Tested on UP SunBlade1500 and 24cpu Niagara T1000. Very nice. Thanks for the feedback and I'm sorry you have to work with such lousy hardware. BTW, I don't know if you say this as a joke, but those are not necessarily lousy hardware. Sun does lousy hardware when they put Sparcs in PCs (ultra5, ultra10, blade100). But their servers generally are nice with large memory busses and very scalable SMP architectures. I guess Con was kidding. A 24-CPU system can be anything but lousy hardware. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.13-rc4-mm1
> >Why was the KERNEL_VERSION(a,b,c) macro removed from > >include/linux/version.h? The removal breaks external drivers like > >NDISWRAPPER or nVidia propietary. > > > Hello Felipe, > > I could not regonize a breakage of NVidia (Version 1.0-7667) propietary > drivers. > They work just perfect. Indeed they do work perfectly, but I can't compile them (from the nVidia package) without adding back the KERNEL_VERSION macro in file include/linux/version.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.13-rc4-mm1
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc4-mm1
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.13-rc4-mm1
Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. Hello Felipe, I could not regonize a breakage of NVidia (Version 1.0-7667) propietary drivers. They work just perfect. Indeed they do work perfectly, but I can't compile them (from the nVidia package) without adding back the KERNEL_VERSION macro in file include/linux/version.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.13-rc2-mm2
> What's your device-mapper/lvm configuration and what 'lvm' command > did you run to trigger this? Nothing special... it happens while booting Fedora Core 4. > 'dmsetup info -c' > 'dmsetup table' > 'lvs --segments -o+devices -a' # cat /etc/fstab /dev/VolGroup00/Root/ ext3defaults1 1 /dev/VolGroup00/Home/home ext3nodev 1 2 /dev/VolGroup00/Swap none swapdefaults0 0 # dmsetup info -c Name Maj Min Stat Open Targ Event UUID VolGroup00-Home 253 2 L--w11 0 pooZ0kfkAXH04Jai0ih2M1YtE1FNgI2xdn8wPAEh3ROBTzYw6gG7qEnYMDn5hfeR VolGroup00-Swap 253 1 L--w11 0 pooZ0kfkAXH04Jai0ih2M1YtE1FNgI2x1ITYve4bdfV53jjNMWTa3w24BBFFLI3t VolGroup00-Root 253 0 L--w11 0 pooZ0kfkAXH04Jai0ih2M1YtE1FNgI2x7HHDn3Iw4wxcQNBHO0gEDMoe7Nta2xv0 # dmsetup table VolGroup00-Home: 0 190414848 linear 3:2 42008960 VolGroup00-Swap: 0 1048576 linear 3:2 40960384 VolGroup00-Root: 0 4096 linear 3:2 384 # lvs --segments -o+devices -a LV VG Attr #Str Type SSize Devices Home VolGroup00 -wi-ao1 linear 90.80G /dev/hda2(5128) Root VolGroup00 -wi-ao1 linear 19.53G /dev/hda2(0) Swap VolGroup00 -wi-ao1 linear 512.00M /dev/hda2(5000) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc2-mm2
What's your device-mapper/lvm configuration and what 'lvm' command did you run to trigger this? Nothing special... it happens while booting Fedora Core 4. 'dmsetup info -c' 'dmsetup table' 'lvs --segments -o+devices -a' # cat /etc/fstab /dev/VolGroup00/Root/ ext3defaults1 1 /dev/VolGroup00/Home/home ext3nodev 1 2 /dev/VolGroup00/Swap none swapdefaults0 0 # dmsetup info -c Name Maj Min Stat Open Targ Event UUID VolGroup00-Home 253 2 L--w11 0 pooZ0kfkAXH04Jai0ih2M1YtE1FNgI2xdn8wPAEh3ROBTzYw6gG7qEnYMDn5hfeR VolGroup00-Swap 253 1 L--w11 0 pooZ0kfkAXH04Jai0ih2M1YtE1FNgI2x1ITYve4bdfV53jjNMWTa3w24BBFFLI3t VolGroup00-Root 253 0 L--w11 0 pooZ0kfkAXH04Jai0ih2M1YtE1FNgI2x7HHDn3Iw4wxcQNBHO0gEDMoe7Nta2xv0 # dmsetup table VolGroup00-Home: 0 190414848 linear 3:2 42008960 VolGroup00-Swap: 0 1048576 linear 3:2 40960384 VolGroup00-Root: 0 4096 linear 3:2 384 # lvs --segments -o+devices -a LV VG Attr #Str Type SSize Devices Home VolGroup00 -wi-ao1 linear 90.80G /dev/hda2(5128) Root VolGroup00 -wi-ao1 linear 19.53G /dev/hda2(0) Swap VolGroup00 -wi-ao1 linear 512.00M /dev/hda2(5000) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.13-rc2-mm2
> Changes since 2.6.13-rc2-mm1:
I'm seeing this oops with 2.6.13-rc2-mm2:
*pde
Oops: [#1]
last sysfs file:
Modules linked in: dm_snapshot dm_mirror ext3 mbcache jbd dm_mod
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.13-rc2mm2)
EIP is at suspend_targets+0x6/0x47 [dm_mod]
eax: ebx: dfdee400 ecx: e0827108 edx:
esi: dfdee400 edi: c162 ebp: esp: c1621efc
ds: 007b es: 007b ss:0068
Process lvm (pid: 236, threadinfo=c162 task=dfee1a70)
Stack: dfdee400 dfdee400 c162 e081d15b dfee1a70
c0115680 dfded680 dfdee400 e0826bc0 e082c000 e08201f0
dfded680 c162 0006 e082023d e08211b8 0001
Call Trace:
[] dm_suspend+0x89/0x185 [dm_mod]
[] default_wake_function+0x0/0xc
[] do_resume+0x149/0x196 [dm_mod]
[] dev_suspend+0x0/0x10 [dm_mod]
[] ctl_ioctl+0xce/0x10a [dm_mod]
[] ctl_ioctl+0x0/0x10a [dm_mod]
[] do_ioctl+0x51/0x55
[] vfs_ioctl+0x50/0x1aa
[] sys_ioctl+0x5d/0x6b
[] syscall_call+0x7/0xb
Code: 00 00 8b 83 b0 00 00 00 89 86 4c 01 00 00 5b 5e c3 8b 80 88 00
00 00 c3 05 9c 00 00 00 c3 8b 80 98 00 00 00 c3 44 57 56 53 89 d5 <8b>
b8 88 00 00 00 8b 98 94 00 00 00 85 ff 74 1e 31 f6 85 ed 74
ERROR: /bin/lvm exited abnormally with value 0 ! (pid 236)
Doesn't happen with 2.6.13-rc2-mm1, however.
Any ideas?
config-2.6.13-rc2mm2
Description: Binary data
Re: 2.6.13-rc2-mm2
Changes since 2.6.13-rc2-mm1:
I'm seeing this oops with 2.6.13-rc2-mm2:
*pde
Oops: [#1]
last sysfs file:
Modules linked in: dm_snapshot dm_mirror ext3 mbcache jbd dm_mod
CPU:0
EIP:0060:[e081e681]Not tainted VLI
EFLAGS: 00010246 (2.6.13-rc2mm2)
EIP is at suspend_targets+0x6/0x47 [dm_mod]
eax: ebx: dfdee400 ecx: e0827108 edx:
esi: dfdee400 edi: c162 ebp: esp: c1621efc
ds: 007b es: 007b ss:0068
Process lvm (pid: 236, threadinfo=c162 task=dfee1a70)
Stack: dfdee400 dfdee400 c162 e081d15b dfee1a70
c0115680 dfded680 dfdee400 e0826bc0 e082c000 e08201f0
dfded680 c162 0006 e082023d e08211b8 0001
Call Trace:
[e081d15b] dm_suspend+0x89/0x185 [dm_mod]
[c0115680] default_wake_function+0x0/0xc
[e08201f0] do_resume+0x149/0x196 [dm_mod]
[e082023d] dev_suspend+0x0/0x10 [dm_mod]
[e08211b8] ctl_ioctl+0xce/0x10a [dm_mod]
[e08210ea] ctl_ioctl+0x0/0x10a [dm_mod]
[c015fdc1] do_ioctl+0x51/0x55
[c015feb7] vfs_ioctl+0x50/0x1aa
[c016006e] sys_ioctl+0x5d/0x6b
[c0102c85] syscall_call+0x7/0xb
Code: 00 00 8b 83 b0 00 00 00 89 86 4c 01 00 00 5b 5e c3 8b 80 88 00
00 00 c3 05 9c 00 00 00 c3 8b 80 98 00 00 00 c3 44 57 56 53 89 d5 8b
b8 88 00 00 00 8b 98 94 00 00 00 85 ff 74 1e 31 f6 85 ed 74
ERROR: /bin/lvm exited abnormally with value 0 ! (pid 236)
Doesn't happen with 2.6.13-rc2-mm1, however.
Any ideas?
config-2.6.13-rc2mm2
Description: Binary data
Re: Multi-core, Vanderpool support?
On 4/15/05, Linda Luu <[EMAIL PROTECTED]> wrote: > Hello, > > Does anyone happen to know how the upcoming multi-core CPU will be handled > by the kernel? Does it see each core as a physical or logical CPU or ? Can't answer this, but I guess each core will be seen as a physical CPU as they are real CPU cores, not just logical CPUs as with multithreading. > Vanderpool is a hardware support for OS virtualization (running multiple OS > "at the same time"), how does Linux kernel make use of this, particularly > which part of the kernel code? At least, Xen will make great use of Vanderpool (VT) for virtualization purpouses. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Multi-core, Vanderpool support?
On 4/15/05, Linda Luu [EMAIL PROTECTED] wrote: Hello, Does anyone happen to know how the upcoming multi-core CPU will be handled by the kernel? Does it see each core as a physical or logical CPU or ? Can't answer this, but I guess each core will be seen as a physical CPU as they are real CPU cores, not just logical CPUs as with multithreading. Vanderpool is a hardware support for OS virtualization (running multiple OS at the same time), how does Linux kernel make use of this, particularly which part of the kernel code? At least, Xen will make great use of Vanderpool (VT) for virtualization purpouses. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: crypting filesystems
On Apr 4, 2005 9:51 PM, Wiktor <[EMAIL PROTECTED]> wrote: > Hi, > > I'm using the following method and it seems to be working fine > (involving crypto-loop): > > i have normal ext3 /boot partition, where i store kernel image & initrd. > after lilo boots the kernel, initrd sets up /dev/loop0 to be > crypto-loop/blowfish for /dev/hda1 (losetup /dev/loop0 /dev/hda1 -e > blowfish). losetup asks for passphrase, and (if entered correctly), > /dev/loop0 is mounted as root filesystem (it can be done also by simple > mount call: mount /dev/hda1 /some-place -o rw,encryption=blowfish). for > encrypting more filesystems with one passphrase, you can read it in > shell script in non-echo-mode (if such exists, i'm not sure), and pass > it to mount or losetup. crypto-loop makes possible to switch encryption > type without modifying whole initrd. > > Regarding your questions: > > > 1. In order to put in the passphrase just once a time at booting, I > put the passphrase in a gpg-crypted file (cipher AES256 and 256Bit key > size), which is decrypted at boot-time to /tmp (-> tmpfs) and > immediately removed with shred, after activating the three partitions. > Is it possible to see the cleartext password after this action in tmpfs? > > Disk encryption usually protects from hardware-attacks (when hacker has > physical access to the hardware). if you keep passphrase > reversible-encrypted, attacker can read it and run brute-force attack > using some huge-computing-capacity. is this what you want? > > > 2. Is it possible to gain the passphrase from the active encrypted > partitions (because the passphrase is somewhere held in the RAM)? > > Only when attacker has root privileges. But i'm not sure if it is > possible to extract passphrase knowing both encrypted and not encrypted > data. What i mean is that usually each filesystem begins with > filesystem-specyfic-header, which is constant or similar to each other. > so, if attacker has encrypted form of this header and can estimate > unencryptes form, it can possibly gain the passphrase. (but therse are > only my ideas, i don't know how the encryptino-algorithm works). What´s kept in RAM is the AES key used to decrypt disk blocks. However, the passphrase from which the AES key is derived (usually by using a hash function) is not kept in memory. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: crypting filesystems
On Apr 4, 2005 9:51 PM, Wiktor [EMAIL PROTECTED] wrote: Hi, I'm using the following method and it seems to be working fine (involving crypto-loop): i have normal ext3 /boot partition, where i store kernel image initrd. after lilo boots the kernel, initrd sets up /dev/loop0 to be crypto-loop/blowfish for /dev/hda1 (losetup /dev/loop0 /dev/hda1 -e blowfish). losetup asks for passphrase, and (if entered correctly), /dev/loop0 is mounted as root filesystem (it can be done also by simple mount call: mount /dev/hda1 /some-place -o rw,encryption=blowfish). for encrypting more filesystems with one passphrase, you can read it in shell script in non-echo-mode (if such exists, i'm not sure), and pass it to mount or losetup. crypto-loop makes possible to switch encryption type without modifying whole initrd. Regarding your questions: 1. In order to put in the passphrase just once a time at booting, I put the passphrase in a gpg-crypted file (cipher AES256 and 256Bit key size), which is decrypted at boot-time to /tmp (- tmpfs) and immediately removed with shred, after activating the three partitions. Is it possible to see the cleartext password after this action in tmpfs? Disk encryption usually protects from hardware-attacks (when hacker has physical access to the hardware). if you keep passphrase reversible-encrypted, attacker can read it and run brute-force attack using some huge-computing-capacity. is this what you want? 2. Is it possible to gain the passphrase from the active encrypted partitions (because the passphrase is somewhere held in the RAM)? Only when attacker has root privileges. But i'm not sure if it is possible to extract passphrase knowing both encrypted and not encrypted data. What i mean is that usually each filesystem begins with filesystem-specyfic-header, which is constant or similar to each other. so, if attacker has encrypted form of this header and can estimate unencryptes form, it can possibly gain the passphrase. (but therse are only my ideas, i don't know how the encryptino-algorithm works). What´s kept in RAM is the AES key used to decrypt disk blocks. However, the passphrase from which the AES key is derived (usually by using a hash function) is not kept in memory. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forkbombing Linux distributions
On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet <[EMAIL PROTECTED]> wrote: > > The memory limits aren't good enough either: if you set them low > > enough that memory-forkbombs are unperilous for > > RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious > > applications. > > yes, if you want to run application like openoffice.org you need at > least 200Mo. If you want that your system is usable, you need at least 40 > process per user. So 40*200 = 8Go, and it don't think you have all this > memory... > > I think per user limit could be a solution. > > attached a small fork-memory bombing. Doesn't do anything on my machine: # ulimits -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 4095 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited it tops at 100 processes and eats a little CPU... although the system is under load, it's completely responsive. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forkbombing Linux distributions
On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet [EMAIL PROTECTED] wrote: The memory limits aren't good enough either: if you set them low enough that memory-forkbombs are unperilous for RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious applications. yes, if you want to run application like openoffice.org you need at least 200Mo. If you want that your system is usable, you need at least 40 process per user. So 40*200 = 8Go, and it don't think you have all this memory... I think per user limit could be a solution. attached a small fork-memory bombing. Doesn't do anything on my machine: # ulimits -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 4095 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited it tops at 100 processes and eats a little CPU... although the system is under load, it's completely responsive. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: binary drivers and development
On Thu, 10 Mar 2005 17:32:39 -0500, John Richard Moser <[EMAIL PROTECTED]> wrote: > CPL=3 scares me; context switches are expensive. can they have direct > hardware access? I'm sure a security model to isolate user mode drivers > could be in place. . . > > . . . huh. Xen seems to run Linux at CPL=3 and give direct hardware > access, so I guess user mode drivers are possible *shrug*. Linux isn't > a microkernel though. Xen hypervisor runs at Ring0, while the guest OSs it supports run at Ring1. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: binary drivers and development
On Thu, 10 Mar 2005 17:32:39 -0500, John Richard Moser [EMAIL PROTECTED] wrote: CPL=3 scares me; context switches are expensive. can they have direct hardware access? I'm sure a security model to isolate user mode drivers could be in place. . . . . . huh. Xen seems to run Linux at CPL=3 and give direct hardware access, so I guess user mode drivers are possible *shrug*. Linux isn't a microkernel though. Xen hypervisor runs at Ring0, while the guest OSs it supports run at Ring1. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] nicksched for 2.6.11
On Mon, 07 Mar 2005 17:02:43 +1100, Nick Piggin <[EMAIL PROTECTED]> wrote: > Yes it is. I have a hack in there that automatically renices any > binary starting with 'XF' to -10 for people who forget. So this > includes XFree86, though maybe it doesn't get the x.org server? X.org's X server binary is called "Xorg", though sometimes it's called "X" (a symbolic link to Xorg). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] nicksched for 2.6.11
On Mon, 07 Mar 2005 17:02:43 +1100, Nick Piggin [EMAIL PROTECTED] wrote: Yes it is. I have a hack in there that automatically renices any binary starting with 'XF' to -10 for people who forget. So this includes XFree86, though maybe it doesn't get the x.org server? X.org's X server binary is called Xorg, though sometimes it's called X (a symbolic link to Xorg). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device "301")
On Wed, 23 Feb 2005 16:25:39 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Could someone try this?
>
> Let's turn that into a real patch.
>
> --- 25/drivers/ide/ide-probe.c~ide_init_disk-fixWed Feb 23 16:24:44
> 2005
> +++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
> @@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
> void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
> {
> ide_hwif_t *hwif = drive->hwif;
> - unsigned int unit = drive->select.all & (1 << 4);
> + unsigned int unit = (drive->select.all >> 4) & 1;
>
> disk->major = hwif->major;
> disk->first_minor = unit << PARTN_BITS;
> _
>
> -
Works for me.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1 (VFS: Cannot open root device 301)
On Wed, 23 Feb 2005 16:25:39 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
Could someone try this?
Let's turn that into a real patch.
--- 25/drivers/ide/ide-probe.c~ide_init_disk-fixWed Feb 23 16:24:44
2005
+++ 25-akpm/drivers/ide/ide-probe.c Wed Feb 23 16:24:55 2005
@@ -1269,7 +1269,7 @@ EXPORT_SYMBOL_GPL(ide_unregister_region)
void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
{
ide_hwif_t *hwif = drive-hwif;
- unsigned int unit = drive-select.all (1 4);
+ unsigned int unit = (drive-select.all 4) 1;
disk-major = hwif-major;
disk-first_minor = unit PARTN_BITS;
_
-
Works for me.
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic on a 2.6.7
On 31 Jan 2005, at 02:51, Clemens Schwaighofer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a RedHat 9.0 box with a self compiled 2.6.7 kernel. Today I had this error and a total lockup on the box. Before that (~6h before I had another lockup, but no output to anywhere). Have you tried with a more recent kernel? 2.6.7 is a little bit ancient. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/6 randomize the stack pointer
On 27 Jan 2005, at 19:04, John Richard Moser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What the hell? So instead of bringing something in that works, you bring something in that does significantly less, and gives no savings on overhead or patch complexity why? So you can later come out and say "We're so great now we've increased the randomization by tweaking one variable aren't we cool!!!"? Red Hat is all smoke and mirrors anyway when it comes to security, just like Microsoft. This just reaffirms that. Please, keep politics out of this list and, instead, keep contributing with practical ideas and code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/6 randomize the stack pointer
On 27 Jan 2005, at 19:04, John Richard Moser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What the hell? So instead of bringing something in that works, you bring something in that does significantly less, and gives no savings on overhead or patch complexity why? So you can later come out and say We're so great now we've increased the randomization by tweaking one variable aren't we cool!!!? Red Hat is all smoke and mirrors anyway when it comes to security, just like Microsoft. This just reaffirms that. Please, keep politics out of this list and, instead, keep contributing with practical ideas and code. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: porting Linux to a virtual machine
On 26 Jan 2005, at 07:23, Robert W. Fuller wrote: Has anybody ported Linux to a virtual machine? http://xen.sf.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: porting Linux to a virtual machine
On 26 Jan 2005, at 07:23, Robert W. Fuller wrote: Has anybody ported Linux to a virtual machine? http://xen.sf.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
On 23 Jan 2005, at 03:39, Andi Kleen wrote: Felipe Alfaro Solana <[EMAIL PROTECTED]> writes: AFAIK, XOR is quite expensive on IA32 when compared to simple MOV operatings. Also, since the original patch uses 3 MOVs to perform the swapping, and your version uses 3 XOR operations, I don't see any gains. Both are one cycle latency for register<->register on all x86 cores I've looked at. What makes you think differently? I thought XOR was more expensie. Anyways, I still don't see any advantage in replacing 3 MOVs with 3 XORs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Bug 4081] New: OpenOffice crashes while starting due to a threading error
On 22 Jan 2005, at 18:33, Matthias-Christian Ott wrote: Hi! I'm suing Arch Linux and the Kernel 2.6.11-rc2 -- it works great. Try to recompile your ^ suing? My God! More legal trouble. Didn't you mean "using"? ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/13] Qsort
On 22 Jan 2005, at 22:00, vlobanov wrote:
Hi,
I was just reading over the patch, and had a quick question/comment
upon
the SWAP macro defined below. I think it's possible to do a tiny bit
better (better, of course, being subjective), as follows:
#define SWAP(a, b, size)\
do {\
register size_t __size = (size);\
register char * __a = (a), * __b = (b); \
do {\
*__a ^= *__b; \
*__b ^= *__a; \
*__a ^= *__b; \
__a++; \
__b++; \
} while ((--__size) > 0);\
} while (0)
What do you think? :)
AFAIK, XOR is quite expensive on IA32 when compared to simple MOV
operatings. Also, since the original patch uses 3 MOVs to perform the
swapping, and your version uses 3 XOR operations, I don't see any
gains.
Am I missing something?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 1/13] Qsort
On 22 Jan 2005, at 22:00, vlobanov wrote:
Hi,
I was just reading over the patch, and had a quick question/comment
upon
the SWAP macro defined below. I think it's possible to do a tiny bit
better (better, of course, being subjective), as follows:
#define SWAP(a, b, size)\
do {\
register size_t __size = (size);\
register char * __a = (a), * __b = (b); \
do {\
*__a ^= *__b; \
*__b ^= *__a; \
*__a ^= *__b; \
__a++; \
__b++; \
} while ((--__size) 0);\
} while (0)
What do you think? :)
AFAIK, XOR is quite expensive on IA32 when compared to simple MOV
operatings. Also, since the original patch uses 3 MOVs to perform the
swapping, and your version uses 3 XOR operations, I don't see any
gains.
Am I missing something?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Bug 4081] New: OpenOffice crashes while starting due to a threading error
On 22 Jan 2005, at 18:33, Matthias-Christian Ott wrote: Hi! I'm suing Arch Linux and the Kernel 2.6.11-rc2 -- it works great. Try to recompile your ^ suing? My God! More legal trouble. Didn't you mean using? ;-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 1/13] Qsort
On 23 Jan 2005, at 03:39, Andi Kleen wrote: Felipe Alfaro Solana [EMAIL PROTECTED] writes: AFAIK, XOR is quite expensive on IA32 when compared to simple MOV operatings. Also, since the original patch uses 3 MOVs to perform the swapping, and your version uses 3 XOR operations, I don't see any gains. Both are one cycle latency for register-register on all x86 cores I've looked at. What makes you think differently? I thought XOR was more expensie. Anyways, I still don't see any advantage in replacing 3 MOVs with 3 XORs. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
