Re: Disk schedulers
On Fri, 2008-02-15 at 15:57 +0100, Prakash Punnoor wrote: > On the day of Friday 15 February 2008 Jan Engelhardt hast written: > > On Feb 14 2008 17:21, Lukas Hejtmanek wrote: > > >Hello, > > > > > >whom should I blame about disk schedulers? > > > > Also consider > > - DMA (e.g. only UDMA2 selected) > > - aging disk > > Nope, I also reported this problem _years_ ago, but till now much hasn't > changed. Large writes lead to read starvation. Yes, I see this often myself. It's like the disk IO queue (I set mine to 1024) fills up, and pdflush and friends can stuff write requests into it much more quickly than any other programs can provide read requests. CFQ and ionice work very well up until iostat shows average IO queuing above 1024 (where I set the queue number). -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Disk schedulers
On Fri, 2008-02-15 at 15:57 +0100, Prakash Punnoor wrote: On the day of Friday 15 February 2008 Jan Engelhardt hast written: On Feb 14 2008 17:21, Lukas Hejtmanek wrote: Hello, whom should I blame about disk schedulers? Also consider - DMA (e.g. only UDMA2 selected) - aging disk Nope, I also reported this problem _years_ ago, but till now much hasn't changed. Large writes lead to read starvation. Yes, I see this often myself. It's like the disk IO queue (I set mine to 1024) fills up, and pdflush and friends can stuff write requests into it much more quickly than any other programs can provide read requests. CFQ and ionice work very well up until iostat shows average IO queuing above 1024 (where I set the queue number). -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
On Wed, 2008-02-06 at 19:44 +, Alan Cox wrote: > On Wed, 06 Feb 2008 12:38:42 -0700 > Zan Lynx <[EMAIL PROTECTED]> wrote: > > > This doesn't happen often so it is rather hard to nail down, but I am > > fairly sure it didn't happen before I started running the 2.6.24 MM > > series kernels. > > Do you have the -mm1 hot fixes applied if its occuring in 2.6.24-mm1 ? All of them except stop-c_p_a-corrupting-the-pds.patch but I don't think that matters since the patch description says it affects x86_32 and this system is x86_64. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
This doesn't happen often so it is rather hard to nail down, but I am fairly sure it didn't happen before I started running the 2.6.24 MM series kernels. gnome-terminal gets stuck. It stops processing X events or anything else. It can be kicked out by strace'ing it or connecting with GDB, and the bug does not seem to ever happen while being traced. It just happened again and I did a sysrq-t to see where (sysrq output for gnome-terminal below). It gets stuck in tty_poll. Have there been changes to TTY stuff recently? I'd try to bisect but this only happens roughly twice a week. Feb 6 12:25:09 localhost kernel: [22779.484008] gnome-termina S 810001009ec0 0 7794 1 Feb 6 12:25:09 localhost kernel: [22779.484008] 81001649db08 0092 00020001 Feb 6 12:25:09 localhost kernel: [22779.484008] 8086dec0 8086dec0 8086dec0 8086dec0 Feb 6 12:25:09 localhost kernel: [22779.484008] 8086dec0 8086dec0 8086ad80 8086dec0 Feb 6 12:25:09 localhost kernel: [22779.484008] Call Trace: Feb 6 12:25:09 localhost kernel: [22779.484008] [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 Feb 6 12:25:09 localhost kernel: [22779.484008] [] schedule_timeout+0x95/0xd0 Feb 6 12:25:09 localhost kernel: [22779.484008] [tty_poll+145/160] tty_poll+0x91/0xa0 Feb 6 12:25:09 localhost kernel: [22779.484008] [] tty_poll+0x91/0xa0 Feb 6 12:25:09 localhost kernel: [22779.484008] [do_sys_poll+617/880] do_sys_poll+0x269/0x370 Feb 6 12:25:09 localhost kernel: [22779.484008] [] do_sys_poll+0x269/0x370 Feb 6 12:25:09 localhost kernel: [22779.484008] [__pollwait+0/304] __pollwait+0x0/0x130 Feb 6 12:25:09 localhost kernel: [22779.484008] [] __pollwait+0x0/0x130 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [thread_return+98/1306] thread_return+0x62/0x51a Feb 6 12:25:09 localhost kernel: [22779.484008] [] thread_return+0x62/0x51a Feb 6 12:25:09 localhost kernel: [22779.484008] [lockdep_sys_exit_thunk+53/103] lockdep_sys_exit_thunk+0x35/0x67 Feb 6 12:25:09 localhost kernel: [22779.484008] [] lockdep_sys_exit_thunk+0x35/0x67 Feb 6 12:25:09 localhost kernel: [22779.484008] [sys_poll+46/144] sys_poll+0x2e/0x90 Feb 6 12:25:09 localhost kernel: [22779.484008] [] sys_poll+0x2e/0x90 Feb 6 12:25:09 localhost kernel: [22779.484008] [system_call_after_swapgs+123/128] system_call_after_swapgs+0x7b/0x80 Feb 6 12:25:09 localhost kernel: [22779.484008] [] system_call_after_swapgs+0x7b/0x80 Kernel .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-mm1 # Mon Feb 4 15:04:58 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y
MM kernels 2.6.24-rc*-mm*, 2.6.24-mm1: gnome-terminal stuck in tty_poll
This doesn't happen often so it is rather hard to nail down, but I am fairly sure it didn't happen before I started running the 2.6.24 MM series kernels. gnome-terminal gets stuck. It stops processing X events or anything else. It can be kicked out by strace'ing it or connecting with GDB, and the bug does not seem to ever happen while being traced. It just happened again and I did a sysrq-t to see where (sysrq output for gnome-terminal below). It gets stuck in tty_poll. Have there been changes to TTY stuff recently? I'd try to bisect but this only happens roughly twice a week. Feb 6 12:25:09 localhost kernel: [22779.484008] gnome-termina S 810001009ec0 0 7794 1 Feb 6 12:25:09 localhost kernel: [22779.484008] 81001649db08 0092 00020001 Feb 6 12:25:09 localhost kernel: [22779.484008] 8086dec0 8086dec0 8086dec0 8086dec0 Feb 6 12:25:09 localhost kernel: [22779.484008] 8086dec0 8086dec0 8086ad80 8086dec0 Feb 6 12:25:09 localhost kernel: [22779.484008] Call Trace: Feb 6 12:25:09 localhost kernel: [22779.484008] [schedule_timeout+149/208] schedule_timeout+0x95/0xd0 Feb 6 12:25:09 localhost kernel: [22779.484008] [8057dde5] schedule_timeout+0x95/0xd0 Feb 6 12:25:09 localhost kernel: [22779.484008] [tty_poll+145/160] tty_poll+0x91/0xa0 Feb 6 12:25:09 localhost kernel: [22779.484008] [80430f11] tty_poll+0x91/0xa0 Feb 6 12:25:09 localhost kernel: [22779.484008] [do_sys_poll+617/880] do_sys_poll+0x269/0x370 Feb 6 12:25:09 localhost kernel: [22779.484008] [802bbe69] do_sys_poll+0x269/0x370 Feb 6 12:25:09 localhost kernel: [22779.484008] [__pollwait+0/304] __pollwait+0x0/0x130 Feb 6 12:25:09 localhost kernel: [22779.484008] [802bcb30] __pollwait+0x0/0x130 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [default_wake_function+0/16] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [80230ee0] default_wake_function+0x0/0x10 Feb 6 12:25:09 localhost kernel: [22779.484008] [thread_return+98/1306] thread_return+0x62/0x51a Feb 6 12:25:09 localhost kernel: [22779.484008] [8057d408] thread_return+0x62/0x51a Feb 6 12:25:09 localhost kernel: [22779.484008] [lockdep_sys_exit_thunk+53/103] lockdep_sys_exit_thunk+0x35/0x67 Feb 6 12:25:09 localhost kernel: [22779.484008] [8057f9bd] lockdep_sys_exit_thunk+0x35/0x67 Feb 6 12:25:09 localhost kernel: [22779.484008] [sys_poll+46/144] sys_poll+0x2e/0x90 Feb 6 12:25:09 localhost kernel: [22779.484008] [802bd14e] sys_poll+0x2e/0x90 Feb 6 12:25:09 localhost kernel: [22779.484008] [system_call_after_swapgs+123/128] system_call_after_swapgs+0x7b/0x80 Feb 6 12:25:09 localhost kernel: [22779.484008] [8020c30b] system_call_after_swapgs+0x7b/0x80 Kernel .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-mm1 # Mon Feb 4 15:04:58 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y
Re: 2.6.24-mm1 - build error, AMD MCE using Intel ifdef'd log function
On Sun, 2008-02-03 at 17:16 -0800, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/ > > arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': (.text+0xe7c4): undefined reference to `mce_log_therm_throt_event' make: *** [.tmp_vmlinux1] Error 1 I looked in MAINTAINERS for MCE, MACHINE and CHECK, but didn't spot any likely entries to CC. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.24-mm1 - build error, AMD MCE using Intel ifdef'd log function
On Sun, 2008-02-03 at 17:16 -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/ arch/x86/kernel/built-in.o: In function `amd_smp_thermal_interrupt': (.text+0xe7c4): undefined reference to `mce_log_therm_throt_event' make: *** [.tmp_vmlinux1] Error 1 I looked in MAINTAINERS for MCE, MACHINE and CHECK, but didn't spot any likely entries to CC. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: ndiswrapper and GPL-only symbols redux
Jon Masters wrote: I wouldn't quite say that. I wasn't going to comment, but...personally, I actually disagree with the assertions that ndiswrapper isn't causing proprietary code to link against GPL functions in the kernel (how is an NDIS implementation any different than a shim layer provided to load a graphics driver?), but I wasn't trying to make that point. Well, as long as *any* part of the kernel ever links to proprietary code, then GPL functions link to it in exactly the same way ndiswrapper enables. It's only a matter of how many steps of separation. A perfectly GPL USB network driver linked to GPL-only functions feeds data into the kernel where it swirls about and emerges from a proprietary network filesystem driver, for example. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ndiswrapper and GPL-only symbols redux
Jon Masters wrote: I wouldn't quite say that. I wasn't going to comment, but...personally, I actually disagree with the assertions that ndiswrapper isn't causing proprietary code to link against GPL functions in the kernel (how is an NDIS implementation any different than a shim layer provided to load a graphics driver?), but I wasn't trying to make that point. Well, as long as *any* part of the kernel ever links to proprietary code, then GPL functions link to it in exactly the same way ndiswrapper enables. It's only a matter of how many steps of separation. A perfectly GPL USB network driver linked to GPL-only functions feeds data into the kernel where it swirls about and emerges from a proprietary network filesystem driver, for example. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: show label for swap partition.
On Mon, 2008-01-28 at 14:58 -0500, Jason Price wrote:
> I apologize if this is the wrong forum. Please CC me on replies.
>
> A admin accidentally deleted the swap line from the fstab file. We
> mount the swap filesystem via labels. However, there seems to be no
> way to list the label on an existing swap partition, via the command
> line swap tools (mkswap, swapon/off, etc)
>
> Is this blindness on my part, or should there be an analog to e2label
> for swap partitions?
There's this cheesy way to get it:
# dd if=swapfile bs=4k count=1 | xxd -a
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 6.2589e-05 s, 65.4 MB/s
000:
*
400: 0100 f209 fce3
410: 7bc9 486d ac86 5d63 af25 3c99 466c 6173 {.Hm..]c.%<.Flas
420: 6853 7761 7000 hSwap...
430:
*
ff0: 5357 4150 5350 4143 4532 ..SWAPSPACE2
You can see it is marked as SWAPSPACE2. The label is FlashSwap. Looks
like it appears at offset 0x41c.
--
Zan Lynx <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: Problem with ata layer in 2.6.24
On Mon, 2008-01-28 at 11:50 -0500, Calvin Walton wrote: > On Mon, 2008-01-28 at 11:35 -0500, Gene Heskett wrote: > > On Monday 28 January 2008, Mikael Pettersson wrote: > > >Unfortunately we also see: > > > > [ 48.285456] nvidia: module license 'NVIDIA' taints kernel. > > > > [ 48.549725] ACPI: PCI Interrupt :02:00.0[A] -> Link [APC4] -> GSI > > > > 19 (level, high) -> IRQ 20 [ 48.550149] NVRM: loading NVIDIA UNIX x86 > > > > Kernel Module 169.07 Thu Dec 13 18:42:56 PST 2007 > > > > > >We have no way of debugging that module, so please try 2.6.24 without it. > > > > Sorry, I can't do this and have a working machine. The nv driver has > > suffered > > bit rot or something since the FC2 days when it COULD run a 19" crt at > > 1600x1200, and will not drive this 20" wide screen lcd 1680x1050 monitor at > > more than 800x600, which is absolutely butt ugly fuzzy, looking like a jpg > > compressed to 10%. The system is not usable on a day to basis without the > > nvidia driver. > > You should probably give the nouveau[1] driver a try, if only for > testing purposes; if you are running an NV4x (G6x or G7x) card in > particular, it works a lot better than the nv driver for 2d support. > > 1. http://nouveau.freedesktop.org/wiki/InstallNouveau But nouveau is much less stable than nv. For testing purposes, go with stable. I'm not sure why it won't run his screen though. I can use nv to run a 1920x1200 laptop LCD. It *is* dog slow (although nouveau was not any better with a NV17 / 440-Go -- render support for AA fonts seems to be missing), but it does work. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Fwd: show label for swap partition.
On Mon, 2008-01-28 at 14:58 -0500, Jason Price wrote:
I apologize if this is the wrong forum. Please CC me on replies.
A admin accidentally deleted the swap line from the fstab file. We
mount the swap filesystem via labels. However, there seems to be no
way to list the label on an existing swap partition, via the command
line swap tools (mkswap, swapon/off, etc)
Is this blindness on my part, or should there be an analog to e2label
for swap partitions?
There's this cheesy way to get it:
# dd if=swapfile bs=4k count=1 | xxd -a
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 6.2589e-05 s, 65.4 MB/s
000:
*
400: 0100 f209 fce3
410: 7bc9 486d ac86 5d63 af25 3c99 466c 6173 {.Hm..]c.%.Flas
420: 6853 7761 7000 hSwap...
430:
*
ff0: 5357 4150 5350 4143 4532 ..SWAPSPACE2
You can see it is marked as SWAPSPACE2. The label is FlashSwap. Looks
like it appears at offset 0x41c.
--
Zan Lynx [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Problem with ata layer in 2.6.24
On Mon, 2008-01-28 at 11:50 -0500, Calvin Walton wrote: On Mon, 2008-01-28 at 11:35 -0500, Gene Heskett wrote: On Monday 28 January 2008, Mikael Pettersson wrote: Unfortunately we also see: [ 48.285456] nvidia: module license 'NVIDIA' taints kernel. [ 48.549725] ACPI: PCI Interrupt :02:00.0[A] - Link [APC4] - GSI 19 (level, high) - IRQ 20 [ 48.550149] NVRM: loading NVIDIA UNIX x86 Kernel Module 169.07 Thu Dec 13 18:42:56 PST 2007 We have no way of debugging that module, so please try 2.6.24 without it. Sorry, I can't do this and have a working machine. The nv driver has suffered bit rot or something since the FC2 days when it COULD run a 19 crt at 1600x1200, and will not drive this 20 wide screen lcd 1680x1050 monitor at more than 800x600, which is absolutely butt ugly fuzzy, looking like a jpg compressed to 10%. The system is not usable on a day to basis without the nvidia driver. You should probably give the nouveau[1] driver a try, if only for testing purposes; if you are running an NV4x (G6x or G7x) card in particular, it works a lot better than the nv driver for 2d support. 1. http://nouveau.freedesktop.org/wiki/InstallNouveau But nouveau is much less stable than nv. For testing purposes, go with stable. I'm not sure why it won't run his screen though. I can use nv to run a 1920x1200 laptop LCD. It *is* dog slow (although nouveau was not any better with a NV17 / 440-Go -- render support for AA fonts seems to be missing), but it does work. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [RFC] Parallelize IO for e2fsck
On Fri, 2008-01-25 at 04:09 -0700, Andreas Dilger wrote:
> On Jan 24, 2008 17:25 -0700, Zan Lynx wrote:
> > Have y'all been following the /dev/mem_notify patches?
> > http://article.gmane.org/gmane.linux.kernel/628653
>
> Having the notification be via poll() is a very restrictive processing
> model. Having the notification be via a signal means that any kind of
> process (and not just those that are event loop driven) can register
> a callback at some arbitrary point in the code and be notified. I
> don't object to the poll() interface, but it would be good to have a
> signal mechanism also.
The commentary on the mem_notify threads claimed that the signal is
easily provided by setting up the file handle for SIGIO.
Yeah. Here it is...copied from email written by KOSAKI Motohiro:
implement FASYNC capability to /dev/mem_notify.
fd = open("/dev/mem_notify", O_RDONLY);
fcntl(fd, F_SETOWN, getpid());
flags = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL, flags|FASYNC); /* when low memory, receive SIGIO */
--
Zan Lynx <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: [RFC] Parallelize IO for e2fsck
On Thu, 2008-01-24 at 18:40 -0500, Theodore Tso wrote: > On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote: > > In practice, there is a small number of programs that are both the > > common memory hogs and should be able to reduce their memory consumption > > by 10% or 20% without big problems when requested (e.g. Java VMs, > > Firefox and databases come into my mind). > > I agree, it's only a few processes where this makes sense. But for > those that do, it would be useful if they could register with the > kernel that would like to know, (just before the system starts > ejecting cached data, just before swapping, etc.) and at what > frequency. And presumably, if the kernel notices that a process is > responding to such requests with memory actually getting released back > to the system, that process could get "rewarded" by having the OOM > killer less likely to target that particular thread. Have y'all been following the /dev/mem_notify patches? http://article.gmane.org/gmane.linux.kernel/628653 -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [RFC] Parallelize IO for e2fsck
On Thu, 2008-01-24 at 18:40 -0500, Theodore Tso wrote: On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote: In practice, there is a small number of programs that are both the common memory hogs and should be able to reduce their memory consumption by 10% or 20% without big problems when requested (e.g. Java VMs, Firefox and databases come into my mind). I agree, it's only a few processes where this makes sense. But for those that do, it would be useful if they could register with the kernel that would like to know, (just before the system starts ejecting cached data, just before swapping, etc.) and at what frequency. And presumably, if the kernel notices that a process is responding to such requests with memory actually getting released back to the system, that process could get rewarded by having the OOM killer less likely to target that particular thread. Have y'all been following the /dev/mem_notify patches? http://article.gmane.org/gmane.linux.kernel/628653 -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.24-rc8-mm1 NULL deref in reiser4_tree_by_page
Unable to handle kernel NULL pointer dereference at RIP: [] reiser4_tree_by_page+0x4/0x20 PGD 12d76067 PUD 12cc7067 PMD 0 Oops: [1] SMP last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq CPU 0 Modules linked in: isofs nls_iso8859_1 nls_cp437 vfat fat nls_base snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device netconsole configfs joydev usb_storage usbhid hid libusual psmouse serio_raw evdev nvidiafb fb fb_ddc i2c_algo_bit cfbcopyarea vgastate i2c_core cfbimgblt snd_intel8x0m ohci_hcd snd_intel8x0 ehci_hcd cfbfillrect snd_ac97_codec ac97_bus snd_pcm snd_timer usbcore snd snd_page_alloc sg Pid: 393133, comm: beagled-helper Not tainted 2.6.24-rc8-mm1 #3 RIP: 0010:[] [] reiser4_tree_by_page+0x4/0x20 RSP: 0018:8100185d5cd0 EFLAGS: 00010296 RAX: RBX: RCX: 000c RDX: RSI: RDI: e200014beda0 RBP: e200014beda0 R08: 0002 R09: R10: 80332a3c R11: 80366910 R12: e200014beda0 R13: 8100185d5de8 R14: 81000ff4b474 R15: 81000ff4b474 FS: 4319d950(0063) GS:80721000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 12da9000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 4ff0 DR7: 0400 Process beagled-helper (pid: 393133, threadinfo 8100185d4000, task 81001d25c000) Stack: 8033217a 8100185d5de8 e200014beda0 8100185d5e20 8100185d5de8 81000ff4b474 81000ff4b474 80359d5a 8102 e202 8102 Call Trace: [] ? jnode_of_page+0x2a/0x2a0 [] ? uf_readpages_filler+0x24a/0x300 [] ? uf_readpages_filler+0x0/0x300 [] ? read_cache_pages+0x96/0xc0 [] ? readpages_unix_file+0x56/0xc0 [] ? __do_page_cache_readahead+0x1c8/0x2b0 [] ? force_page_cache_readahead+0x61/0x90 [] ? sys_fadvise64_64+0x103/0x1e0 [] ? system_call_after_swapgs+0x7b/0x80 Code: 00 66 0f 1f 44 00 00 e8 cb 99 fe ff e9 e2 fe ff ff 48 8b 7d 00 bb fe ff ff ff e8 b8 99 fe ff e9 cf fe ff ff 90 90 90 48 8b 47 18 <48> 8b 00 48 8b 80 d0 01 00 00 48 8b 80 30 04 00 00 48 83 c0 48 RIP [] reiser4_tree_by_page+0x4/0x20 RSP CR2: ---[ end trace aaa0c2da658acfd6 ]--- $ /usr/src/linux/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux zephyr 2.6.24-rc8-mm1 #3 SMP Fri Jan 18 14:36:24 MST 2008 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Gnu C 4.2.2 Gnu make 3.81 binutils 2.18.50.0.1.20070908 util-linux 2.13.1 mount 2.13.1 module-init-tools 3.4 e2fsprogs 1.40.4 reiserfsprogs 3.6.19 reiser4progs 1.0.6 pcmciautils014 pcmcia-cs 3.2.9 PPP2.4.4 nfs-utils 1.0.7 Linux C LibraryDynamic linker (ldd) 2.7 Procps 3.2.7 Net-tools 1.60 Kbd1.13 oprofile 0.9.3 Sh-utils 6.9 udev 118 wireless-tools 29 Modules Loaded isofs nls_iso8859_1 nls_cp437 vfat fat nls_base snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device netconsole configfs usb_storage usbhid hid libusual joydev psmouse serio_raw evdev nvidiafb fb fb_ddc i2c_algo_bit cfbcopyarea vgastate i2c_core cfbimgblt cfbfillrect snd_intel8x0 snd_intel8x0m snd_ac97_codec ehci_hcd ohci_hcd ac97_bus snd_pcm usbcore snd_timer snd sg snd_page_alloc -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.24-rc8-mm1 NULL deref in reiser4_tree_by_page
Unable to handle kernel NULL pointer dereference at RIP: [803495d4] reiser4_tree_by_page+0x4/0x20 PGD 12d76067 PUD 12cc7067 PMD 0 Oops: [1] SMP last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq CPU 0 Modules linked in: isofs nls_iso8859_1 nls_cp437 vfat fat nls_base snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device netconsole configfs joydev usb_storage usbhid hid libusual psmouse serio_raw evdev nvidiafb fb fb_ddc i2c_algo_bit cfbcopyarea vgastate i2c_core cfbimgblt snd_intel8x0m ohci_hcd snd_intel8x0 ehci_hcd cfbfillrect snd_ac97_codec ac97_bus snd_pcm snd_timer usbcore snd snd_page_alloc sg Pid: 393133, comm: beagled-helper Not tainted 2.6.24-rc8-mm1 #3 RIP: 0010:[803495d4] [803495d4] reiser4_tree_by_page+0x4/0x20 RSP: 0018:8100185d5cd0 EFLAGS: 00010296 RAX: RBX: RCX: 000c RDX: RSI: RDI: e200014beda0 RBP: e200014beda0 R08: 0002 R09: R10: 80332a3c R11: 80366910 R12: e200014beda0 R13: 8100185d5de8 R14: 81000ff4b474 R15: 81000ff4b474 FS: 4319d950(0063) GS:80721000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 12da9000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 4ff0 DR7: 0400 Process beagled-helper (pid: 393133, threadinfo 8100185d4000, task 81001d25c000) Stack: 8033217a 8100185d5de8 e200014beda0 8100185d5e20 8100185d5de8 81000ff4b474 81000ff4b474 80359d5a 8102 e202 8102 Call Trace: [8033217a] ? jnode_of_page+0x2a/0x2a0 [80359d5a] ? uf_readpages_filler+0x24a/0x300 [80359b10] ? uf_readpages_filler+0x0/0x300 [80293086] ? read_cache_pages+0x96/0xc0 [80359e66] ? readpages_unix_file+0x56/0xc0 [80292e78] ? __do_page_cache_readahead+0x1c8/0x2b0 [80292fc1] ? force_page_cache_readahead+0x61/0x90 [8028e313] ? sys_fadvise64_64+0x103/0x1e0 [8020c37b] ? system_call_after_swapgs+0x7b/0x80 Code: 00 66 0f 1f 44 00 00 e8 cb 99 fe ff e9 e2 fe ff ff 48 8b 7d 00 bb fe ff ff ff e8 b8 99 fe ff e9 cf fe ff ff 90 90 90 48 8b 47 18 48 8b 00 48 8b 80 d0 01 00 00 48 8b 80 30 04 00 00 48 83 c0 48 RIP [803495d4] reiser4_tree_by_page+0x4/0x20 RSP 8100185d5cd0 CR2: ---[ end trace aaa0c2da658acfd6 ]--- $ /usr/src/linux/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux zephyr 2.6.24-rc8-mm1 #3 SMP Fri Jan 18 14:36:24 MST 2008 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Gnu C 4.2.2 Gnu make 3.81 binutils 2.18.50.0.1.20070908 util-linux 2.13.1 mount 2.13.1 module-init-tools 3.4 e2fsprogs 1.40.4 reiserfsprogs 3.6.19 reiser4progs 1.0.6 pcmciautils014 pcmcia-cs 3.2.9 PPP2.4.4 nfs-utils 1.0.7 Linux C LibraryDynamic linker (ldd) 2.7 Procps 3.2.7 Net-tools 1.60 Kbd1.13 oprofile 0.9.3 Sh-utils 6.9 udev 118 wireless-tools 29 Modules Loaded isofs nls_iso8859_1 nls_cp437 vfat fat nls_base snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device netconsole configfs usb_storage usbhid hid libusual joydev psmouse serio_raw evdev nvidiafb fb fb_ddc i2c_algo_bit cfbcopyarea vgastate i2c_core cfbimgblt cfbfillrect snd_intel8x0 snd_intel8x0m snd_ac97_codec ehci_hcd ohci_hcd ac97_bus snd_pcm usbcore snd_timer snd sg snd_page_alloc -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Why is the kfree() argument const?
On Fri, 2008-01-18 at 11:14 -0800, Vadim Lobanov wrote: [cut] > Second, even if const did have stronger semantics that forbade the value of x > from being modified during execution of foo, the compiler still could not > reorder the two function calls, before it cannot assume that the two > functions (in their internal implementations) do not touch some other, > unknown to this code, global variable. This is why GCC has the pure and const function attributes. These attributes are more powerful than the "const" keyword, and do allow optimizations with assumptions about global state. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [Announce] Development release 0.1 of the LatencyTOP tool
On Fri, 2008-01-18 at 09:36 -0800, Arjan van de Ven wrote: > The Intel Open Source Technology Center is pleased to announce the > release of version 0.1 of LatencyTOP, a tool for developers to visualize > system latencies. > > http://www.latencytop.org > > Slow servers, Skipping audio, Jerky video --everyone knows the symptoms > of latency. But to know what's really going on in the system, what's causing > the latency, and how to fix it... those are difficult questions without > good answers right now. [cut] Just curious... My biggest latency problems (as observed by me, the user) happen when a program needs memory, or launching a new program, and the kernel begins forces dirty memory to disk. This results in an unholy seek storm of mixed writes (flushing, maybe a little swap) and reads (new program loading). Streaming audio/video almost always starts freezing up during this as well. I don't suppose LatencyTop would help track anything down in that case, would it? -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [2.6.24-rc8-mm1] Locking API boot-time self-tests hangs.
On Thu, 2008-01-17 at 20:42 -0800, Andrew Morton wrote: > On Fri, 18 Jan 2008 12:19:56 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: > > > Hello. > > > > Andrew Morton wrote: > > > I'd be suspecting git-sched, so in lieu of a full bisection search it > > > would > > > be great if one of you could apply > > > http://userweb.kernel.org/~akpm/git-sched.patch to 2.6.24-rc8 and see if > > > it > > > fails in the same way. > > Too bad. It didn't fail. > > > > I used your exact .config with the current mm lineup (I don't thinlk > anything relevant has changed) and it booted OK on my old PIII machine. > > It could be compiler version dependent. I used gcc-4.1.0. Which version > were you and Zan using please? From my -rc6-mm1 boot. $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux zephyr 2.6.24-rc6-mm1 #1 SMP Tue Dec 25 17:53:03 MST 2007 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Gnu C 4.2.2 Gnu make 3.81 binutils 2.18.50.0.1.20070908 util-linux 2.13.1 mount 2.13.1 module-init-tools 3.4 e2fsprogs 1.40.4 reiserfsprogs 3.6.19 reiser4progs 1.0.6 pcmciautils014 pcmcia-cs 3.2.9 PPP2.4.4 nfs-utils 1.0.7 Linux C LibraryDynamic linker (ldd) 2.7 Procps 3.2.7 Net-tools 1.60 Kbd1.13 oprofile 0.9.3 Sh-utils 6.9 udev 118 wireless-tools 29 Modules Loaded nls_cp437 vfat fat nls_iso8859_1 isofs nls_base nouveau drm snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device rfcomm l2cap usbhid hid hci_usb bluetooth usb_storage libusual joydev nvidiafb fb fb_ddc i2c_algo_bit cfbcopyarea vgastate i2c_core cfbimgblt cfbfillrect snd_intel8x0m snd_intel8x0 snd_ac97_codec ehci_hcd psmouse ohci_hcd serio_raw ac97_bus snd_pcm snd_timer usbcore evdev snd sg snd_page_alloc -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [Announce] Development release 0.1 of the LatencyTOP tool
On Fri, 2008-01-18 at 09:36 -0800, Arjan van de Ven wrote: The Intel Open Source Technology Center is pleased to announce the release of version 0.1 of LatencyTOP, a tool for developers to visualize system latencies. http://www.latencytop.org Slow servers, Skipping audio, Jerky video --everyone knows the symptoms of latency. But to know what's really going on in the system, what's causing the latency, and how to fix it... those are difficult questions without good answers right now. [cut] Just curious... My biggest latency problems (as observed by me, the user) happen when a program needs memory, or launching a new program, and the kernel begins forces dirty memory to disk. This results in an unholy seek storm of mixed writes (flushing, maybe a little swap) and reads (new program loading). Streaming audio/video almost always starts freezing up during this as well. I don't suppose LatencyTop would help track anything down in that case, would it? -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Why is the kfree() argument const?
On Fri, 2008-01-18 at 11:14 -0800, Vadim Lobanov wrote: [cut] Second, even if const did have stronger semantics that forbade the value of x from being modified during execution of foo, the compiler still could not reorder the two function calls, before it cannot assume that the two functions (in their internal implementations) do not touch some other, unknown to this code, global variable. This is why GCC has the pure and const function attributes. These attributes are more powerful than the const keyword, and do allow optimizations with assumptions about global state. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [2.6.24-rc8-mm1] Locking API boot-time self-tests hangs.
On Thu, 2008-01-17 at 20:42 -0800, Andrew Morton wrote: On Fri, 18 Jan 2008 12:19:56 +0900 Tetsuo Handa [EMAIL PROTECTED] wrote: Hello. Andrew Morton wrote: I'd be suspecting git-sched, so in lieu of a full bisection search it would be great if one of you could apply http://userweb.kernel.org/~akpm/git-sched.patch to 2.6.24-rc8 and see if it fails in the same way. Too bad. It didn't fail. I used your exact .config with the current mm lineup (I don't thinlk anything relevant has changed) and it booted OK on my old PIII machine. It could be compiler version dependent. I used gcc-4.1.0. Which version were you and Zan using please? From my -rc6-mm1 boot. $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux zephyr 2.6.24-rc6-mm1 #1 SMP Tue Dec 25 17:53:03 MST 2007 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Gnu C 4.2.2 Gnu make 3.81 binutils 2.18.50.0.1.20070908 util-linux 2.13.1 mount 2.13.1 module-init-tools 3.4 e2fsprogs 1.40.4 reiserfsprogs 3.6.19 reiser4progs 1.0.6 pcmciautils014 pcmcia-cs 3.2.9 PPP2.4.4 nfs-utils 1.0.7 Linux C LibraryDynamic linker (ldd) 2.7 Procps 3.2.7 Net-tools 1.60 Kbd1.13 oprofile 0.9.3 Sh-utils 6.9 udev 118 wireless-tools 29 Modules Loaded nls_cp437 vfat fat nls_iso8859_1 isofs nls_base nouveau drm snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device rfcomm l2cap usbhid hid hci_usb bluetooth usb_storage libusual joydev nvidiafb fb fb_ddc i2c_algo_bit cfbcopyarea vgastate i2c_core cfbimgblt cfbfillrect snd_intel8x0m snd_intel8x0 snd_ac97_codec ehci_hcd psmouse ohci_hcd serio_raw ac97_bus snd_pcm snd_timer usbcore evdev snd sg snd_page_alloc -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.24-rc8-mm1 and boot lockup during locking self-test
CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_DEBUG_SYNCHRO_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_KPROBES_SANITY_TEST=y # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_LKDTM is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_UNWIND_INFO is not set # CONFIG_KGDB is not set # CONFIG_KGDB_ATTACH_WAIT is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_RODATA is not set CONFIG_X86_MPPARSE=y # CONFIG_IOMMU_DEBUG is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # CONFIG_DEBUG_BOOT_PARAMS is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y CONFIG_SECURITY=y # CONFIG_SECURITY_NETWORK is not set CONFIG_SECURITY_CAPABILITIES=y CONFIG_SECURITY_FILE_CAPABILITIES=y CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_CCM=m # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_LZO=m # CONFIG_CRYPTO_HW is not set # CONFIG_VIRTUALIZATION is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: echo mem > /sys/power/state
On Wed, 2008-01-16 at 22:24 -0800, Andrew Morton wrote: > So I take everyone's latest and greatest product and injudiciously type the > above command. The result five minutes later is at > http://userweb.kernel.org/~akpm/borkage.jpg. See if you can count all the > bugs. > > Sorry, but I've had it with this stuff and I'm tired of fixing everyone else's > stuff. I'm just going to ship it. Good luck. Heh. Laptop suspend to anything has been so broken for so long in the -mm series on my Compaq R3000 that I didn't even know it was ever supposed to work. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: echo mem /sys/power/state
On Wed, 2008-01-16 at 22:24 -0800, Andrew Morton wrote: So I take everyone's latest and greatest product and injudiciously type the above command. The result five minutes later is at http://userweb.kernel.org/~akpm/borkage.jpg. See if you can count all the bugs. Sorry, but I've had it with this stuff and I'm tired of fixing everyone else's stuff. I'm just going to ship it. Good luck. Heh. Laptop suspend to anything has been so broken for so long in the -mm series on my Compaq R3000 that I didn't even know it was ever supposed to work. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.24-rc8-mm1 and boot lockup during locking self-test
CONFIG_KPROBES_SANITY_TEST=y # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_LKDTM is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_UNWIND_INFO is not set # CONFIG_KGDB is not set # CONFIG_KGDB_ATTACH_WAIT is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_RODATA is not set CONFIG_X86_MPPARSE=y # CONFIG_IOMMU_DEBUG is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # CONFIG_DEBUG_BOOT_PARAMS is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y CONFIG_SECURITY=y # CONFIG_SECURITY_NETWORK is not set CONFIG_SECURITY_CAPABILITIES=y CONFIG_SECURITY_FILE_CAPABILITIES=y CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_CCM=m # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_LZO=m # CONFIG_CRYPTO_HW is not set # CONFIG_VIRTUALIZATION is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On Thu, 2008-01-10 at 13:43 +0100, Matthew wrote: > it's a little tricky to reproduce it: > I tried it with root-account: firefox-bin, thunderbird-bin wouldn't trigger > user-account (with used account-directory of both apps): > thunderbird-bin triggers it more reliably > probably it has to do with the x86 compatibility apps of gentoo ? > gentoo amd64-users with 32bit firefox & thunderbird - anyone able to > reproduce it ? I believe that I *have* seen this happen to me. I'm using a Compaq R3000 laptop with AMD-64 CPU and Gentoo with kernel 2.6.24-rc6-mm1. A few days ago I crashed it twice in a row by trying to load my Comics bookmarks as tabs (87 entries) in 32-bit Firefox. I only got 1 and 3/4ths lines output by netconsole and it mentioned a function with 32-something in the name. Later tonight I can try loading the tabs in Firefox again to see if it will reproduce for a 3rd time. I also have to say that the NMI watchdog, supposedly Non-Maskable, hardly *ever* works for me. I don't believe that whatever events reset the dog actually matter to the end user. Perhaps its still processing interrupts and running a timer loop but if nothing can read or write disk, net, netlink or other device IO, I don't believe the system can actually claim to be working. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On Thu, 2008-01-10 at 13:43 +0100, Matthew wrote: it's a little tricky to reproduce it: I tried it with root-account: firefox-bin, thunderbird-bin wouldn't trigger user-account (with used account-directory of both apps): thunderbird-bin triggers it more reliably probably it has to do with the x86 compatibility apps of gentoo ? gentoo amd64-users with 32bit firefox thunderbird - anyone able to reproduce it ? I believe that I *have* seen this happen to me. I'm using a Compaq R3000 laptop with AMD-64 CPU and Gentoo with kernel 2.6.24-rc6-mm1. A few days ago I crashed it twice in a row by trying to load my Comics bookmarks as tabs (87 entries) in 32-bit Firefox. I only got 1 and 3/4ths lines output by netconsole and it mentioned a function with 32-something in the name. Later tonight I can try loading the tabs in Firefox again to see if it will reproduce for a 3rd time. I also have to say that the NMI watchdog, supposedly Non-Maskable, hardly *ever* works for me. I don't believe that whatever events reset the dog actually matter to the end user. Perhaps its still processing interrupts and running a timer loop but if nothing can read or write disk, net, netlink or other device IO, I don't believe the system can actually claim to be working. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Sat, 2007-12-08 at 02:07 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 22:01:33 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:
> > > On Fri, 07 Dec 2007 23:09:43 +
> > > Zan Lynx <[EMAIL PROTECTED]> wrote:
> > [cut]
> > > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again,
> > > > > > but I
> > > > > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I
> > > > > > got
> > > > > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2
> > > > > > reader.
[cut]
> argh. OK. And Linus's current tree is OK, yes?
>
> In which case we should be OK for 2.6.24 and I guess we can hope like heck
> that the dud patch doesn't leak into mainline. Hopefully Alan will get
> some time to look into it before 2.6.25 opens.
Linus' tree is also broken.
I tried a Linus 2.6.24-rc4 and it acts the same way, with a very slow
transfer rate.
I also tried 2.6.24-rc4 with the older not-libata PATA drivers and it is
broken. dmesg had a line about the CF card detected as hda,
but /sys/block did not have hda and /dev/hda did not function.
I will try the patches you mentioned, but I think I may also have to
work backward through kernel versions until I find the last one where
the PCMCIA hd{a,b,c,d,e} drivers worked.
--
Zan Lynx <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Sat, 2007-12-08 at 02:07 -0800, Andrew Morton wrote:
On Fri, 07 Dec 2007 22:01:33 -0700 Zan Lynx [EMAIL PROTECTED] wrote:
On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:
On Fri, 07 Dec 2007 23:09:43 +
Zan Lynx [EMAIL PROTECTED] wrote:
[cut]
Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again,
but I
only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I
got
at least 16 MB/s. The card itself is capable of 30+ in the USB-2
reader.
[cut]
argh. OK. And Linus's current tree is OK, yes?
In which case we should be OK for 2.6.24 and I guess we can hope like heck
that the dud patch doesn't leak into mainline. Hopefully Alan will get
some time to look into it before 2.6.25 opens.
Linus' tree is also broken.
I tried a Linus 2.6.24-rc4 and it acts the same way, with a very slow
transfer rate.
I also tried 2.6.24-rc4 with the older not-libata PATA drivers and it is
broken. dmesg had a line about the CF card detected as hda,
but /sys/block did not have hda and /dev/hda did not function.
I will try the patches you mentioned, but I think I may also have to
work backward through kernel versions until I find the last one where
the PCMCIA hd{a,b,c,d,e} drivers worked.
--
Zan Lynx [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote: > On Fri, 07 Dec 2007 23:09:43 + > Zan Lynx <[EMAIL PROTECTED]> wrote: [cut] > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I > > > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got > > > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2 > > > > reader. [cut] > Maybe pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch? > > Could you try a `patch -R' of the below? > > > From: Alan Cox <[EMAIL PROTECTED]> > > Signed-off-by: Alan Cox <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- > > drivers/ata/pata_pcmcia.c | 31 +-- > 1 file changed, 17 insertions(+), 14 deletions(-) > > diff -puN > drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards > drivers/ata/pata_pcmcia.c [cut] Nope, that did not change anything. It still detects as PIO0 and still runs at 1.6 MB/s. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote: > On Fri, 07 Dec 2007 23:09:43 + > Zan Lynx <[EMAIL PROTECTED]> wrote: > > > > > On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote: > > > On Fri, 07 Dec 2007 20:38:24 + > > > Zan Lynx <[EMAIL PROTECTED]> wrote: > > > > > > > While I'm reporting problems I'll get this one out there. > > > > > > > > I normally use a USB-2 memory card reader but I also have a PCMCIA > > > > CompactFlash adapter that I use occasionally. During the MM series > > > > kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all. I > > > > don't know about vanilla since I don't run that. > > > > > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I > > > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got > > > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2 > > > > reader. > > > > > > [cut] > Oh, OK. Hopefully the ata guys can help out with this. > > I don't know if it actually strictly a regression? Did libata ever support > that device in any earlier kernels? That could be why it didn't work for a few kernel versions. I reconfigured for a libata-only system a while back. And, since I usually use the USB-2 flash reader I didn't care much about the PCMCIA. I will try reverting that patch later tonight, in a few hours. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote: > On Fri, 07 Dec 2007 20:38:24 + > Zan Lynx <[EMAIL PROTECTED]> wrote: > > > While I'm reporting problems I'll get this one out there. > > > > I normally use a USB-2 memory card reader but I also have a PCMCIA > > CompactFlash adapter that I use occasionally. During the MM series > > kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all. I > > don't know about vanilla since I don't run that. > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2 > > reader. > > > Are we talking about this? [cut] > > It might be that it auto-configures for PIO-0. I have no idea why it > > does that. > > > > Another interesting thing is that doing a dd to or from the card brings > > the rest of the system to a nearly complete halt. Interrupt problem? > > Where are you seeing the evidence that it autoconfigures for PIO-0? No, this: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x5000-0x57ff: excluding 0x5000-0x57ff cs: memory probe 0xe010-0xe17f: excluding 0xe010-0xe026 0xe03e-0xe082 0xe0b1-0xe10c pcmcia: registering new device pcmcia0.0 scsi2 : pata_pcmcia ata3: PATA max PIO0 cmd 0x3100 ctl 0x310e irq 19 ata3.00: CFA: LEXAR ATA FLASH, V2.00, max PIO6 ata3.00: 8018640 sectors, multi 0: LBA ata3.00: configured for PIO0 ata3.00: configured for PIO0 ata3: EH complete isa bounce pool size: 16 pages scsi 2:0:0:0: Direct-Access ATA LEXAR ATA FLASH V2.0 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk Specifically: ata3.00: configured for PIO0 ata3.00: configured for PIO0 -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.24-rc4-mm1 and excessive block IO errors
I am not sure if this problem has been addressed already. I read some about the fast-fail issues and this may be related? On nearly all my USB block devices, I have been getting zillions of I/O errors. But they aren't real, they don't appear with 2.6.23 kernels. I can often read and write data to the device, but these IO errors cause error aborts in user space applications in many cases, making it a chancy thing to run backup software, for example. Here is a bit of dmesg from plugging in a perfectly good USB-2 flash drive. hub 3-0:1.0: state 7 ports 6 chg evt 0004 ehci_hcd :00:02.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: new high speed USB device using ehci_hcd and address 9 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: default language 0x0409 usb 3-2: uevent usb 3-2: usb_probe_device usb 3-2: configuration #1 chosen from 1 choice usb 3-2: adding 3-2:1.0 (config #1, interface 0) usb 3-2:1.0: uevent libusual 3-2:1.0: usb_probe_interface libusual 3-2:1.0: usb_probe_interface - got id usb-storage 3-2:1.0: usb_probe_interface usb-storage 3-2:1.0: usb_probe_interface - got id scsi4 : SCSI emulation for USB Mass Storage devices drivers/usb/core/inode.c: creating file '009' usb 3-2: New USB device found, idVendor=05dc, idProduct=a400 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: JUMPDRIVE usb 3-2: Manufacturer: LEXAR MEDIA usb 3-2: SerialNumber: 0A4EEC05201219080904 usb-storage: device found at 9 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 4:0:0:0: Direct-Access LEXARJUMPDRIVE1000 PQ: 0 ANSI: 0 CCS sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sdg: sdg1 sd 4:0:0:0: [sdg] Attached SCSI removable disk sd 4:0:0:0: Attached scsi generic sg7 type 0 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 3984 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 162 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 290 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 418 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 546 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 674 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 802 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 930 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1058 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1186 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1314 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1442 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1570 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1698 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1826 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1954 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 528288 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 528672 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 546392 -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
Priority:100 extents:1 across:2843496k Bluetooth: L2CAP ver 2.9 Bluetooth: L2CAP socket layer initialized usb usb1: usb auto-resume ohci_hcd :00:02.0: resume root hub hub 1-0:1.0: hub_resume hub 1-0:1.0: state 7 ports 3 chg evt Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 ohci_hcd :00:02.0: auto-stop root hub hub 1-0:1.0: hub_suspend usb usb1: bus auto-suspend ohci_hcd :00:02.0: suspend root hub eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1 warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use) eth0: no IPv6 routers present [drm] Initialized drm 1.1.0 20060810 [drm] Detected an NV17 generation card (0x017900a5) [drm] Initialized nouveau 0.0.10 20060213 on minor 0 [drm] Used old pci detect: framebuffer loaded agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 4x mode agpgart: Putting AGP V2 device at :01:00.0 into 4x mode [drm] Allocating FIFO number 0 [drm] nouveau_fifo_alloc: initialised FIFO 0 [drm] Allocating FIFO number 1 [drm] nouveau_fifo_alloc: initialised FIFO 1 usb 3-1.4.3: link qh4-3804/81001e1808c0 start 3 [1/2 us] usb 3-1.4.3: unlink qh4-3804/81001e1808c0 start 3 [1/2 us] ehci_hcd :00:02.2: reused qh 81001e1808c0 schedule usb 3-1.4.3: link qh4-3804/81001e1808c0 start 3 [1/2 us] Hangcheck: hangcheck value past margin! -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.24-rc4-mm1 and /proc//status Name: field
Today I noticed pgrep doesn't work. It seems the reason is a missing Name: tag in the status file for a process in /proc. # cat /proc/1/status init State: S (sleeping) Tgid: 1 Pid:1 PPid: 0 TracerPid: 0 ...etc, etc... This is supposed to look like: # cat /proc/1/status Name: init State: S (sleeping) Tgid: 1 Pid:1 PPid: 0 TracerPid: 0 ... -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote: On Fri, 07 Dec 2007 20:38:24 + Zan Lynx [EMAIL PROTECTED] wrote: While I'm reporting problems I'll get this one out there. I normally use a USB-2 memory card reader but I also have a PCMCIA CompactFlash adapter that I use occasionally. During the MM series kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all. I don't know about vanilla since I don't run that. Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got at least 16 MB/s. The card itself is capable of 30+ in the USB-2 reader. Are we talking about this? [cut] It might be that it auto-configures for PIO-0. I have no idea why it does that. Another interesting thing is that doing a dd to or from the card brings the rest of the system to a nearly complete halt. Interrupt problem? Where are you seeing the evidence that it autoconfigures for PIO-0? No, this: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x5000-0x57ff: excluding 0x5000-0x57ff cs: memory probe 0xe010-0xe17f: excluding 0xe010-0xe026 0xe03e-0xe082 0xe0b1-0xe10c pcmcia: registering new device pcmcia0.0 scsi2 : pata_pcmcia ata3: PATA max PIO0 cmd 0x3100 ctl 0x310e irq 19 ata3.00: CFA: LEXAR ATA FLASH, V2.00, max PIO6 ata3.00: 8018640 sectors, multi 0: LBA ata3.00: configured for PIO0 ata3.00: configured for PIO0 ata3: EH complete isa bounce pool size: 16 pages scsi 2:0:0:0: Direct-Access ATA LEXAR ATA FLASH V2.0 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk Specifically: ata3.00: configured for PIO0 ata3.00: configured for PIO0 -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote: On Fri, 07 Dec 2007 23:09:43 + Zan Lynx [EMAIL PROTECTED] wrote: [cut] Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got at least 16 MB/s. The card itself is capable of 30+ in the USB-2 reader. [cut] Maybe pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch? Could you try a `patch -R' of the below? From: Alan Cox [EMAIL PROTECTED] Signed-off-by: Alan Cox [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/ata/pata_pcmcia.c | 31 +-- 1 file changed, 17 insertions(+), 14 deletions(-) diff -puN drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards drivers/ata/pata_pcmcia.c [cut] Nope, that did not change anything. It still detects as PIO0 and still runs at 1.6 MB/s. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote: On Fri, 07 Dec 2007 23:09:43 + Zan Lynx [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote: On Fri, 07 Dec 2007 20:38:24 + Zan Lynx [EMAIL PROTECTED] wrote: While I'm reporting problems I'll get this one out there. I normally use a USB-2 memory card reader but I also have a PCMCIA CompactFlash adapter that I use occasionally. During the MM series kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all. I don't know about vanilla since I don't run that. Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got at least 16 MB/s. The card itself is capable of 30+ in the USB-2 reader. [cut] Oh, OK. Hopefully the ata guys can help out with this. I don't know if it actually strictly a regression? Did libata ever support that device in any earlier kernels? That could be why it didn't work for a few kernel versions. I reconfigured for a libata-only system a while back. And, since I usually use the USB-2 flash reader I didn't care much about the PCMCIA. I will try reverting that patch later tonight, in a few hours. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.24-rc4-mm1 and excessive block IO errors
I am not sure if this problem has been addressed already. I read some about the fast-fail issues and this may be related? On nearly all my USB block devices, I have been getting zillions of I/O errors. But they aren't real, they don't appear with 2.6.23 kernels. I can often read and write data to the device, but these IO errors cause error aborts in user space applications in many cases, making it a chancy thing to run backup software, for example. Here is a bit of dmesg from plugging in a perfectly good USB-2 flash drive. hub 3-0:1.0: state 7 ports 6 chg evt 0004 ehci_hcd :00:02.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: new high speed USB device using ehci_hcd and address 9 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: default language 0x0409 usb 3-2: uevent usb 3-2: usb_probe_device usb 3-2: configuration #1 chosen from 1 choice usb 3-2: adding 3-2:1.0 (config #1, interface 0) usb 3-2:1.0: uevent libusual 3-2:1.0: usb_probe_interface libusual 3-2:1.0: usb_probe_interface - got id usb-storage 3-2:1.0: usb_probe_interface usb-storage 3-2:1.0: usb_probe_interface - got id scsi4 : SCSI emulation for USB Mass Storage devices drivers/usb/core/inode.c: creating file '009' usb 3-2: New USB device found, idVendor=05dc, idProduct=a400 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: JUMPDRIVE usb 3-2: Manufacturer: LEXAR MEDIA usb 3-2: SerialNumber: 0A4EEC05201219080904 usb-storage: device found at 9 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 4:0:0:0: Direct-Access LEXARJUMPDRIVE1000 PQ: 0 ANSI: 0 CCS sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sdg: sdg1 sd 4:0:0:0: [sdg] Attached SCSI removable disk sd 4:0:0:0: Attached scsi generic sg7 type 0 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 3984 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 162 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 290 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 418 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 546 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 674 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 802 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 930 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1058 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1186 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1314 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1442 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1570 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1698 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1826 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 1954 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 528288 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 528672 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 546392 -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.24-rc4-mm1 and /proc/pid/status Name: field
Today I noticed pgrep doesn't work. It seems the reason is a missing Name: tag in the status file for a process in /proc. # cat /proc/1/status init State: S (sleeping) Tgid: 1 Pid:1 PPid: 0 TracerPid: 0 ...etc, etc... This is supposed to look like: # cat /proc/1/status Name: init State: S (sleeping) Tgid: 1 Pid:1 PPid: 0 TracerPid: 0 ... -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
evt Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 ohci_hcd :00:02.0: auto-stop root hub hub 1-0:1.0: hub_suspend usb usb1: bus auto-suspend ohci_hcd :00:02.0: suspend root hub eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1 warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use) eth0: no IPv6 routers present [drm] Initialized drm 1.1.0 20060810 [drm] Detected an NV17 generation card (0x017900a5) [drm] Initialized nouveau 0.0.10 20060213 on minor 0 [drm] Used old pci detect: framebuffer loaded agpgart: Found an AGP 2.0 compliant device at :00:00.0. agpgart: Putting AGP V2 device at :00:00.0 into 4x mode agpgart: Putting AGP V2 device at :01:00.0 into 4x mode [drm] Allocating FIFO number 0 [drm] nouveau_fifo_alloc: initialised FIFO 0 [drm] Allocating FIFO number 1 [drm] nouveau_fifo_alloc: initialised FIFO 1 usb 3-1.4.3: link qh4-3804/81001e1808c0 start 3 [1/2 us] usb 3-1.4.3: unlink qh4-3804/81001e1808c0 start 3 [1/2 us] ehci_hcd :00:02.2: reused qh 81001e1808c0 schedule usb 3-1.4.3: link qh4-3804/81001e1808c0 start 3 [1/2 us] Hangcheck: hangcheck value past margin! -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.24-rc2-mm1
Andrew Morton wrote:
[cut]
hm, that was supposed to shut itself off after 100 messages:
if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {
static int __read_mostly count = 100;
if (count && printk_ratelimit()) {
char comm[TASK_COMM_LEN];
count--;
printk(KERN_INFO "fork(): process `%s' used deprecated "
"clone flags 0x%lx\n",
get_task_comm(comm, current),
clone_flags & (CLONE_DETACHED|CLONE_STOPPED));
}
}
I don't see how you got 151 instances. I guess I'm having another stupid
day.
It looks like a simple race, two threads do count-- before doing
if(count), resulting in an almost infinite loop. Probably.
atomic_test_and_dec might work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
Andrew Morton wrote:
[cut]
hm, that was supposed to shut itself off after 100 messages:
if (unlikely(clone_flags (CLONE_DETACHED|CLONE_STOPPED))) {
static int __read_mostly count = 100;
if (count printk_ratelimit()) {
char comm[TASK_COMM_LEN];
count--;
printk(KERN_INFO fork(): process `%s' used deprecated
clone flags 0x%lx\n,
get_task_comm(comm, current),
clone_flags (CLONE_DETACHED|CLONE_STOPPED));
}
}
I don't see how you got 151 instances. I guess I'm having another stupid
day.
It looks like a simple race, two threads do count-- before doing
if(count), resulting in an almost infinite loop. Probably.
atomic_test_and_dec might work.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm2 ACPI Battery Info in /sys but not /proc/acpi
On Fri, 2007-10-19 at 11:59 -0400, Chris Bandy wrote: > I had this same problem, but found that it was because I turned off the > newly deprecated CONFIG_ACPI_PROCFS. This was the problem. Thank you. What confused me was that *only* the battery information seemed to be missing. If all the ACPI info in /proc had been missing I would have suspected something like this right away. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.23-rc8-mm2 ACPI Battery Info in /sys but not /proc/acpi
On Fri, 2007-10-19 at 11:59 -0400, Chris Bandy wrote: I had this same problem, but found that it was because I turned off the newly deprecated CONFIG_ACPI_PROCFS. This was the problem. Thank you. What confused me was that *only* the battery information seemed to be missing. If all the ACPI info in /proc had been missing I would have suspected something like this right away. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: WANTED: kernel projects for CS students
On Sun, 2007-10-14 at 19:01 -0400, Rik van Riel wrote: > The kernel newbies community often gets inquiries from CS students who > need a project for their studies and would like to do something with > the Linux kernel, but would also like their code to be useful to the > community afterwards. > > In order to make it easier for them, I am trying to put together a > page with projects that: > - Are self contained enough that the students can implement the > project by themselves, since that is often a university requirement. > - Are self contained enough that Linux could merge the code (maybe > with additional changes) after the student has been working on it > for a few months. > - Are large enough to qualify as a student project, luckily there is > flexibility here since we get inquiries for anything from 6 week > projects to 6 month projects. > > If you have ideas on what projects would be useful, please add them > to this page (or email me): > > http://kernelnewbies.org/KernelProjects How about this in the Device Mapper raid-1/mirror code? /* FIXME: add read balancing */ That comment has been in there for many releases. I've wanted read balancing for several servers and had all sorts of ideas about it, like adding functions to the underlying device queues to return a "queuing cost" to determine which is the best queue to add the read request. I think that could work better for queues like CFQ than the MD closest-head. An implementation would also need to be benchmarked against the MD raid-1. Along with the time to submit it to LKML, get it reviewed and polish it up, it might make a good student project. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.23-mm1
On Fri, 2007-10-12 at 14:00 -0700, Andrew Morton wrote: > On Fri, 12 Oct 2007 22:38:25 +0200 > Laurent Riffard <[EMAIL PROTECTED]> wrote: > > > Le 12.10.2007 06:31, Andrew Morton a écrit : > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > Mounting reiser4 fs does hang with these messages in dmesg: > > > > Loading Reiser4. See www.namesys.com for a description of Reiser4. > > reiser4[swapper(0)]: end_bio_single_page_read > > (fs/reiser4/page_cache.c:331)[nikita-3332]: > > WARNING: Truncated single page read: 4096 > > > > Hitting SysRq-W produces this output: > > > > SysRq : Show Blocked State > > taskPC stack pid father > > mount D c20d6b70 1592 2509 2495 > > c229bbd8 0046 c239d684 c20d6b70 e0824b8d c229bc10 > > c229bc18 > > c229bbe0 c02ac14e c229bbe8 c0141b7b c229bc04 c02ac344 c0141b45 > > c1402654 > > c1045f60 c1045f60 c229bc10 c229bc30 c0141d6e 0002 c1045f60 > > > > Call Trace: > >[] io_schedule+0xe/0x16 > >[] sync_page+0x36/0x3a > >[] __wait_on_bit+0x36/0x5d > >[] wait_on_page_bit+0x55/0x5b > >[] jload_gfp+0x73/0x163 [reiser4] > >[] load_journal_control_block+0x4d/0x77 [reiser4] > >[] reiser4_init_journal_info+0x2b/0x54 [reiser4] > >[] init_format_format40+0x79/0x4ab [reiser4] > >[] fill_super+0xce/0x1ee [reiser4] > >[] get_sb_bdev+0xe0/0x11e > >[] reiser4_get_sb+0x13/0x15 [reiser4] > >[] vfs_kern_mount+0x3b/0x76 > >[] do_mount+0x68a/0x7a3 > >[] sys_mount+0x68/0xa4 > >[] sysenter_past_esp+0x5f/0x99 > >=== > > ho hum. Maybe reiser4 needs updating for the git-block changes. > > I don't recall having seen a useful description of what's going on > in git-block so some reverse-engineering might be needed. Hmm. I can add more data to this. My x86_64 mode laptop is running 2.6.23-mm1 with Reiser4 and does not experience problems. I am using 64-bit kernel, libata (I think, whatever the SCSI-like PATA is called), and Reiser4. Both libata and Reiser4 are built-in, not modules. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.23-mm1
On Fri, 2007-10-12 at 14:00 -0700, Andrew Morton wrote: On Fri, 12 Oct 2007 22:38:25 +0200 Laurent Riffard [EMAIL PROTECTED] wrote: Le 12.10.2007 06:31, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Mounting reiser4 fs does hang with these messages in dmesg: Loading Reiser4. See www.namesys.com for a description of Reiser4. reiser4[swapper(0)]: end_bio_single_page_read (fs/reiser4/page_cache.c:331)[nikita-3332]: WARNING: Truncated single page read: 4096 Hitting SysRq-W produces this output: SysRq : Show Blocked State taskPC stack pid father mount D c20d6b70 1592 2509 2495 c229bbd8 0046 c239d684 c20d6b70 e0824b8d c229bc10 c229bc18 c229bbe0 c02ac14e c229bbe8 c0141b7b c229bc04 c02ac344 c0141b45 c1402654 c1045f60 c1045f60 c229bc10 c229bc30 c0141d6e 0002 c1045f60 Call Trace: [c02ac14e] io_schedule+0xe/0x16 [c0141b7b] sync_page+0x36/0x3a [c02ac344] __wait_on_bit+0x36/0x5d [c0141d6e] wait_on_page_bit+0x55/0x5b [e1c0e1a6] jload_gfp+0x73/0x163 [reiser4] [e1c1c7f8] load_journal_control_block+0x4d/0x77 [reiser4] [e1c1c86e] reiser4_init_journal_info+0x2b/0x54 [reiser4] [e1c454e6] init_format_format40+0x79/0x4ab [reiser4] [e1c21cf8] fill_super+0xce/0x1ee [reiser4] [c015f731] get_sb_bdev+0xe0/0x11e [e1c21a8f] reiser4_get_sb+0x13/0x15 [reiser4] [c015f336] vfs_kern_mount+0x3b/0x76 [c0171621] do_mount+0x68a/0x7a3 [c01717a2] sys_mount+0x68/0xa4 [c0103dee] sysenter_past_esp+0x5f/0x99 === ho hum. Maybe reiser4 needs updating for the git-block changes. I don't recall having seen a useful description of what's going on in git-block so some reverse-engineering might be needed. Hmm. I can add more data to this. My x86_64 mode laptop is running 2.6.23-mm1 with Reiser4 and does not experience problems. I am using 64-bit kernel, libata (I think, whatever the SCSI-like PATA is called), and Reiser4. Both libata and Reiser4 are built-in, not modules. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: WANTED: kernel projects for CS students
On Sun, 2007-10-14 at 19:01 -0400, Rik van Riel wrote: The kernel newbies community often gets inquiries from CS students who need a project for their studies and would like to do something with the Linux kernel, but would also like their code to be useful to the community afterwards. In order to make it easier for them, I am trying to put together a page with projects that: - Are self contained enough that the students can implement the project by themselves, since that is often a university requirement. - Are self contained enough that Linux could merge the code (maybe with additional changes) after the student has been working on it for a few months. - Are large enough to qualify as a student project, luckily there is flexibility here since we get inquiries for anything from 6 week projects to 6 month projects. If you have ideas on what projects would be useful, please add them to this page (or email me): http://kernelnewbies.org/KernelProjects How about this in the Device Mapper raid-1/mirror code? /* FIXME: add read balancing */ That comment has been in there for many releases. I've wanted read balancing for several servers and had all sorts of ideas about it, like adding functions to the underlying device queues to return a queuing cost to determine which is the best queue to add the read request. I think that could work better for queues like CFQ than the MD closest-head. An implementation would also need to be benchmarked against the MD raid-1. Along with the time to submit it to LKML, get it reviewed and polish it up, it might make a good student project. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [patch] reiser4: do not allocate struct file on stack
On Fri, 2007-10-05 at 03:22 +0400, Edward Shishkin wrote: > Edward Shishkin wrote: > > > Dave Hansen wrote: > > > ... > > >> > >> I think that stack allocation is a pretty nasty trick for a structure > >> that's supposed to be pretty persistent and dynamically allocated, and > >> is certainly something that needs to get fixed up in a proper way. > >> > >> > > > > agreed. > > > >> This works around the problem for now, but this could potentially cause > >> more bugs any time we add some member to 'struct file' and depend on its > >> state being sane anywhere in the VFS. If there's a list anywhere of > >> merge-stopper reiser4 bugs around, this should probably go in there. > >> > >> > > > > will be fixed. > > > > The promised fixup is attached. > Andrew, please apply. > > Thanks, > Edward. There were several copies of this email, so I picked one. :) I had the crash with 2.6.23-rc8-mm2, so I applied this patch. Hunk #1 failed, the rest applied with fuzz. I manually applied hunk #1 and recompiled. I am now running with 2.6.23-rc8-mm2 + this patch and things seem good. (Except for some issues with ACPI battery info moving out of proc and confusing the heck out of HAL and the GNOME power management scripts). -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [patch] reiser4: do not allocate struct file on stack
On Fri, 2007-10-05 at 03:22 +0400, Edward Shishkin wrote: Edward Shishkin wrote: Dave Hansen wrote: ... I think that stack allocation is a pretty nasty trick for a structure that's supposed to be pretty persistent and dynamically allocated, and is certainly something that needs to get fixed up in a proper way. agreed. This works around the problem for now, but this could potentially cause more bugs any time we add some member to 'struct file' and depend on its state being sane anywhere in the VFS. If there's a list anywhere of merge-stopper reiser4 bugs around, this should probably go in there. will be fixed. The promised fixup is attached. Andrew, please apply. Thanks, Edward. There were several copies of this email, so I picked one. :) I had the crash with 2.6.23-rc8-mm2, so I applied this patch. Hunk #1 failed, the rest applied with fuzz. I manually applied hunk #1 and recompiled. I am now running with 2.6.23-rc8-mm2 + this patch and things seem good. (Except for some issues with ACPI battery info moving out of proc and confusing the heck out of HAL and the GNOME power management scripts). -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
et # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=m CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # CONFIG_DLM is not set # # Instrumentation Support # CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_KPROBES=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_PAGE_OWNER is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_SLUB_DEBUG_ON=y CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y # CONFIG_RT_MUTEX_TESTER is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_LOCKDEP is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_FRAME_POINTER is not set # CONFIG_UNWIND_INFO is not set # CONFIG_PROFILE_LIKELY is not set # CONFIG_FORCED_INLINING is not set # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_DEBUG_SYNCHRO_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_LKDTM is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_KGDB is not set # CONFIG_KGDB_ATTACH_WAIT is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_IOMMU_DEBUG is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_XTS=m # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set CONFIG_CRYPTO_AUTHENC=m # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.23-rc8-mm2 NULL dereference in __mnt_is_readonly in ftruncate
is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes
On Thu, 2007-08-23 at 11:28 +0200, Jiri Kosina wrote: > On Wed, 22 Aug 2007, Zan Lynx wrote: > > > After installing this new wonder kernel on my AMD-64 laptop, I > > discovered that Beagle wouldn't start. While enjoying how fast my > > system felt ( :) ) I also discovered that Evolution wouldn't start > > because it was built with mono integration. > [...] > > Mono claims to mmap with the MAP_32BIT option. > > In -rc3-mm1 strace shows mono's mmap like this: > > mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, > > MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0) = 0x7fa21f5cb000 > > Hi Zan, > > thanks for an excellent bugreport. Rather than throwing the whole > pie-randomization and flexmmap support away, could you please test the > patch below and let me know whether it fixes all your issues? Thanks. > > > From: Jiri Kosina <[EMAIL PROTECTED]> > > Handle MAP_32BIT flags properly in x86_64 flexmmap > > We need to handle MAP_32BIT flags of mmap() properly for 64bit > applications with filexible mmap layout. > > This patch introduces x86_64-specific version of > arch_get_unmapped_area_topdown() which differs from the generic one in > handling of the MAP_32BIT flag -- when this flag is passed to mmap(), we > stick back to the legacy layout for this particular mmap, which gives > proper 32bit range. > > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> [snip patch] This does fix the mono problem. Thank you. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes
On Thu, 2007-08-23 at 11:28 +0200, Jiri Kosina wrote: On Wed, 22 Aug 2007, Zan Lynx wrote: After installing this new wonder kernel on my AMD-64 laptop, I discovered that Beagle wouldn't start. While enjoying how fast my system felt ( :) ) I also discovered that Evolution wouldn't start because it was built with mono integration. [...] Mono claims to mmap with the MAP_32BIT option. In -rc3-mm1 strace shows mono's mmap like this: mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0) = 0x7fa21f5cb000 Hi Zan, thanks for an excellent bugreport. Rather than throwing the whole pie-randomization and flexmmap support away, could you please test the patch below and let me know whether it fixes all your issues? Thanks. From: Jiri Kosina [EMAIL PROTECTED] Handle MAP_32BIT flags properly in x86_64 flexmmap We need to handle MAP_32BIT flags of mmap() properly for 64bit applications with filexible mmap layout. This patch introduces x86_64-specific version of arch_get_unmapped_area_topdown() which differs from the generic one in handling of the MAP_32BIT flag -- when this flag is passed to mmap(), we stick back to the legacy layout for this particular mmap, which gives proper 32bit range. Signed-off-by: Jiri Kosina [EMAIL PROTECTED] [snip patch] This does fix the mono problem. Thank you. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes
On Wed, 2007-08-22 at 02:06 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ After installing this new wonder kernel on my AMD-64 laptop, I discovered that Beagle wouldn't start. While enjoying how fast my system felt ( :) ) I also discovered that Evolution wouldn't start because it was built with mono integration. Can't live without email, so I poked at it and discovered that if I run mono applications (including Evolution) with the legacy memory layout, they work. Like this: setarch x86_64 -L evolution This didn't happen on -rc2-mm2, so I think somebody changed something. Mono claims to mmap with the MAP_32BIT option. In -rc3-mm1 strace shows mono's mmap like this: mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0) = 0x7fa21f5cb000 It's got MAP_32BIT, but that's not a 32-bit address... -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes
On Wed, 2007-08-22 at 02:06 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ After installing this new wonder kernel on my AMD-64 laptop, I discovered that Beagle wouldn't start. While enjoying how fast my system felt ( :) ) I also discovered that Evolution wouldn't start because it was built with mono integration. Can't live without email, so I poked at it and discovered that if I run mono applications (including Evolution) with the legacy memory layout, they work. Like this: setarch x86_64 -L evolution This didn't happen on -rc2-mm2, so I think somebody changed something. Mono claims to mmap with the MAP_32BIT option. In -rc3-mm1 strace shows mono's mmap like this: mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0) = 0x7fa21f5cb000 It's got MAP_32BIT, but that's not a 32-bit address... -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: How to make -mm a more viable testbed (was: [PATCH] [1/12] x86: Work around mmio config space quirk on AMD)
On Mon, 2007-08-13 at 17:09 -0400, Dave Jones wrote: > On Mon, Aug 13, 2007 at 02:40:06PM -0600, Zan Lynx wrote: > > I thought most people running -mm were running klive, which shou > > ld tell kernel versions, uptime and other things. I run it, anyway. > > > > http://klive.cpushare.com/ > > If that's the case, there are 3 people running 2.6.23-rc2-mm2. > I suspect the actual number of users is considerably higher. > Somehow I doubt that 'most' people are running klive. I had thought Andrew asked people to do it at one point. Could have been someone else, I suppose. Ah, it was Andrea Arcangeli. At the time, it seemed more people were doing it. I guess not though. Or there really aren't many people running the latest -mm. It *is* quite a hassle. I only do it because I'm crazy. :) I think klive is a good idea for tracking kernel testing. Perhaps mentioning it here again will get more people running it. I suppose that someone could try to estimate usage by counting patch downloads off kernel.org. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: How to make -mm a more viable testbed (was: [PATCH] [1/12] x86: Work around mmio config space quirk on AMD)
On Mon, 2007-08-13 at 08:08 +0300, Al Boldi wrote: > Linus Torvalds wrote: > > On Sun, 12 Aug 2007, Dave Jones wrote: > > > > > > This does make me wonder, why these weren't caught in -mm ? > > > > I'm worried that -mm isn't getting a lot of exposure these days. People do > > run it, but I wonder how many.. > > Well, I'm not running it because it's got too much garbage in it, which makes > it a pretty unrealistic testbed. And to make matters worse, I also stay > away from rc's as a consequence. > > To make -mm more viable, it may be advisable to restructure -mm in such a way > as to be a Kconfig option to mainline. This would probably involve some > patch management functionality to apply experimental submissions on a > per-patch basis, as opposed to being a 'take it or leave it slam onto > mainline' patch. I thought most people running -mm were running klive, which shou ld tell kernel versions, uptime and other things. I run it, anyway. http://klive.cpushare.com/ -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: How to make -mm a more viable testbed (was: [PATCH] [1/12] x86: Work around mmio config space quirk on AMD)
On Mon, 2007-08-13 at 08:08 +0300, Al Boldi wrote: Linus Torvalds wrote: On Sun, 12 Aug 2007, Dave Jones wrote: This does make me wonder, why these weren't caught in -mm ? I'm worried that -mm isn't getting a lot of exposure these days. People do run it, but I wonder how many.. Well, I'm not running it because it's got too much garbage in it, which makes it a pretty unrealistic testbed. And to make matters worse, I also stay away from rc's as a consequence. To make -mm more viable, it may be advisable to restructure -mm in such a way as to be a Kconfig option to mainline. This would probably involve some patch management functionality to apply experimental submissions on a per-patch basis, as opposed to being a 'take it or leave it slam onto mainline' patch. I thought most people running -mm were running klive, which shou ld tell kernel versions, uptime and other things. I run it, anyway. http://klive.cpushare.com/ -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: How to make -mm a more viable testbed (was: [PATCH] [1/12] x86: Work around mmio config space quirk on AMD)
On Mon, 2007-08-13 at 17:09 -0400, Dave Jones wrote: On Mon, Aug 13, 2007 at 02:40:06PM -0600, Zan Lynx wrote: I thought most people running -mm were running klive, which shou ld tell kernel versions, uptime and other things. I run it, anyway. http://klive.cpushare.com/ If that's the case, there are 3 people running 2.6.23-rc2-mm2. I suspect the actual number of users is considerably higher. Somehow I doubt that 'most' people are running klive. I had thought Andrew asked people to do it at one point. Could have been someone else, I suppose. Ah, it was Andrea Arcangeli. At the time, it seemed more people were doing it. I guess not though. Or there really aren't many people running the latest -mm. It *is* quite a hassle. I only do it because I'm crazy. :) I think klive is a good idea for tracking kernel testing. Perhaps mentioning it here again will get more people running it. I suppose that someone could try to estimate usage by counting patch downloads off kernel.org. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: why are some atomic_t's not volatile, while most are?
On Tue, 2007-08-07 at 15:38 -0600, Chris Friesen wrote:
> Chris Snook wrote:
>
> > That's why we define atomic_read like so:
> >
> > #define atomic_read(v) ((v)->counter)
> >
> > This avoids the aliasing problem, because the compiler must de-reference
> > the pointer every time, which requires a memory fetch.
>
> Can you guarantee that the pointer dereference cannot be optimised away
> on any architecture? Without other restrictions, a suficiently
> intelligent optimiser could notice that the address of v doesn't change
> in the loop and the destination is never written within the loop, so the
> read could be hoisted out of the loop.
>
> Even now, powerpc (as an example) defines atomic_t as:
>
> typedef struct { volatile int counter; } atomic_t
>
>
> That volatile is there precisely to force the compiler to dereference it
> every single time.
I just tried this with GCC 4.2 on x86_64 because I was curious.
struct counter_t { volatile int counter; } test;
struct counter_t *tptr =
int main() {
int i;
tptr->counter = 0;
i = 0;
while(tptr->counter < 100) {
i++;
}
return 0;
}
$ gcc -O3 -S t.c
a snippet of t.s:
main:
.LFB2:
movqtptr(%rip), %rdx
movl$0, (%rdx)
.p2align 4,,7
.L2:
movl(%rdx), %eax
cmpl$99, %eax
jle .L2
Now with the volatile removed:
main:
.LFB2:
movqtptr(%rip), %rax
movl$0, (%rax)
.L2:
jmp .L2
If the compiler can see it clearly, it will optimize out the load
without the volatile.
--
Zan Lynx <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: why are some atomic_t's not volatile, while most are?
On Tue, 2007-08-07 at 15:38 -0600, Chris Friesen wrote:
Chris Snook wrote:
That's why we define atomic_read like so:
#define atomic_read(v) ((v)-counter)
This avoids the aliasing problem, because the compiler must de-reference
the pointer every time, which requires a memory fetch.
Can you guarantee that the pointer dereference cannot be optimised away
on any architecture? Without other restrictions, a suficiently
intelligent optimiser could notice that the address of v doesn't change
in the loop and the destination is never written within the loop, so the
read could be hoisted out of the loop.
Even now, powerpc (as an example) defines atomic_t as:
typedef struct { volatile int counter; } atomic_t
That volatile is there precisely to force the compiler to dereference it
every single time.
I just tried this with GCC 4.2 on x86_64 because I was curious.
struct counter_t { volatile int counter; } test;
struct counter_t *tptr = test;
int main() {
int i;
tptr-counter = 0;
i = 0;
while(tptr-counter 100) {
i++;
}
return 0;
}
$ gcc -O3 -S t.c
a snippet of t.s:
main:
.LFB2:
movqtptr(%rip), %rdx
movl$0, (%rdx)
.p2align 4,,7
.L2:
movl(%rdx), %eax
cmpl$99, %eax
jle .L2
Now with the volatile removed:
main:
.LFB2:
movqtptr(%rip), %rax
movl$0, (%rax)
.L2:
jmp .L2
If the compiler can see it clearly, it will optimize out the load
without the volatile.
--
Zan Lynx [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)
On Wed, 2007-08-01 at 08:52 -0700, Nish Aravamudan wrote: > On 7/31/07, Zan Lynx <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote: > > > On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote: > > > > > > > I was playing with huge pages and libhugetlbfs. Small programs like > > > > "ls" work fine. I tried running Evolution through libhugetlbfs and the > > > > system slowly stops running. One interesting thing is the "ps" command, > > > > it gets stuck like this: > > > > > > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1? > > > > D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut & paste to be > > sure: > > Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007 > > x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux > > Just to confirm, still happens with -mm2? No, it does not seem to. Evolution runs OK. ps, top, pmap all work fine. However, a couple of other things happened. Could be unrelated or only loosely related. Evolution launches spamd (spamassassin) to filter junk mail. spamd died and I have this in dmesg to show for it: VM: killing process spamd spamd would have inherited the libhugetlbfs.so environment variables. There are no other clues as to why it died though. Also, immediately after launching evolution with libhugetlbfs, I got that USB bug where the mouse starts creating keyboard input. I got some of these in dmesg: keyboard.c: can't emulate rawmode for keycode 240 That could be pure coincidence, although I had been using the system almost all day before that, and it hadn't happened. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)
On Wed, 2007-08-01 at 08:52 -0700, Nish Aravamudan wrote: On 7/31/07, Zan Lynx [EMAIL PROTECTED] wrote: On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote: On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote: I was playing with huge pages and libhugetlbfs. Small programs like ls work fine. I tried running Evolution through libhugetlbfs and the system slowly stops running. One interesting thing is the ps command, it gets stuck like this: Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1? D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut paste to be sure: Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Just to confirm, still happens with -mm2? No, it does not seem to. Evolution runs OK. ps, top, pmap all work fine. However, a couple of other things happened. Could be unrelated or only loosely related. Evolution launches spamd (spamassassin) to filter junk mail. spamd died and I have this in dmesg to show for it: VM: killing process spamd spamd would have inherited the libhugetlbfs.so environment variables. There are no other clues as to why it died though. Also, immediately after launching evolution with libhugetlbfs, I got that USB bug where the mouse starts creating keyboard input. I got some of these in dmesg: keyboard.c: can't emulate rawmode for keycode 240 That could be pure coincidence, although I had been using the system almost all day before that, and it hadn't happened. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)
On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote: > On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote: > > > I was playing with huge pages and libhugetlbfs. Small programs like > > "ls" work fine. I tried running Evolution through libhugetlbfs and the > > system slowly stops running. One interesting thing is the "ps" command, > > it gets stuck like this: > > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1? D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut & paste to be sure: Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.22-rc1-mm1 huge pages VM freeze (maybe?)
I was playing with huge pages and libhugetlbfs. Small programs like "ls" work fine. I tried running Evolution through libhugetlbfs and the system slowly stops running. One interesting thing is the "ps" command, it gets stuck like this: psD 81001e57ed40 0 103558 103483 81001f061dc8 0096 81003d8586e8 81001cbadc00 0006 80537009 0030 807ff700 807ff700 807ff700 807ff700 807ff700 Call Trace: [] _spin_unlock+0x29/0x50 [] __down_read+0x75/0xaf [] access_process_vm+0x49/0x190 [] proc_pid_cmdline+0xa3/0x130 [] proc_info_read+0xba/0x100 [] vfs_read+0xc5/0x180 [] sys_read+0x53/0x90 [] system_call+0x7e/0x83 and nothing will touch it after that. Here's my kernel command line: root=/dev/sda2 rootfstype=reiser4 rootflags=no_write_barrier ro i8042.nomux elevator=cfq resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug hugepages=32 Here's the "huge" script I was using to run programs: #!/bin/sh export LD_PRELOAD=libhugetlbfs.so export HUGETLB_MORECORE=yes export HUGETLB_PATH=/mnt/huge export HUGETLB_VERBOSE=1 exec "$@" I don't have any more info than that at the moment but I could reproduce it with whatever, on request. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.23-rc1-mm1 Reiser4 / SLUB padding overwritten error
call+0x7e/0x83 48 02 01 c0 66 48 31 c3 BUG: sleeping function called from invalid context at kernel/rwsem.c:20 [] down_read+0x15/0x40 [] check_bytes_and_report+0x4b/0x100 [] count_deleted_blocks_actor+0x0/0x20 [] blocknr_set_iterator+0xc9/0x130 [] vfs_statfs_native+0x2a/0x70 [] trace_hardirqs_on_thunk+0x35/0x37 BUG: scheduling while atomic: gnome-volume-ma/0x1003/7793 [] release_console_sem+0x4f/0x220 [] cond_resched+0x32/0x40 [] do_page_fault+0x613/0x8b0 [] count_deleted_blocks_actor+0x0/0x20 [] count_deleted_blocks_actor+0x5/0x20 [] vfs_statfs+0x67/0x80 [] vfs_read+0x173/0x180 INFO: lockdep is turned off. SysRq : Emergency Sync BUG: spinlock lockup on CPU#0, ktxnmgrd:sda2:r/539, 810003dcbc08 Call Trace: [] _raw_spin_lock+0x134/0x140 [] commit_some_atoms+0x34/0x150 [] commit_some_atoms+0x34/0x150 [] ktxnmgrd+0x0/0x1a0 [] ktxnmgrd+0x141/0x1a0 [] ktxnmgrd+0x0/0x1a0 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] restore_args+0x0/0x30 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 INFO: lockdep is turned off. NMI backtrace for cpu 0 Call Trace: [] nmi_watchdog_tick+0x159/0x1e0 [] default_do_nmi+0x76/0x1e0 [] do_nmi+0x3d/0x60 [] nmi+0x7f/0x80 [] release_console_sem+0x4f/0x220 [] __delay+0x8/0x20 <> [] __trigger_all_cpu_backtrace+0x1f/0x40 [] _raw_spin_lock+0x139/0x140 [] commit_some_atoms+0x34/0x150 [] commit_some_atoms+0x34/0x150 [] ktxnmgrd+0x0/0x1a0 [] ktxnmgrd+0x141/0x1a0 [] ktxnmgrd+0x0/0x1a0 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] restore_args+0x0/0x30 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 INFO: lockdep is turned off. Hangcheck: hangcheck value past margin! SysRq : Resetting -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.23-rc1-mm1 Reiser4 / SLUB padding overwritten error
: R10: 80335902 R11: 009a R12: 81000d1cce90 R13: 810003dcbc01 R14: 8100150b9d10 R15: 803356e0 FS: 2b66943fe730() GS:806bf000() knlGS:f63c69d0 CS: 0010 DS: ES: CR0: 8005003b CR2: 80f8 CR3: 08a8e000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process gnome-volume-ma (pid: 7793, threadinfo 8100150b8000, task 810009280fd0) Stack: 80342939 810003dcbc38 03dcb9f8 810020c27458 810020c27400 5a5a5a5a5a5a5a5a 810020c27400 810003dcbc38 810003dcb9f8 810003dcbc08 8100150b9d10 810008c82480 Call Trace: [80342939] blocknr_set_iterator+0xc9/0x130 [80335927] txnmgr_count_deleted_blocks+0xc7/0x100 [803438b6] reiser4_statfs+0x76/0x120 [802ae8f7] vfs_statfs+0x67/0x80 [802aeb2a] vfs_statfs_native+0x2a/0x70 [802aec95] sys_statfs+0x85/0xc0 [802afceb] do_readv_writev+0x16b/0x220 [802b0133] vfs_read+0x173/0x180 [8020c1de] system_call+0x7e/0x83 48 02 01 c0 66 48 31 c3 BUG: sleeping function called from invalid context at kernel/rwsem.c:20 [80257615] down_read+0x15/0x40 [802a999b] check_bytes_and_report+0x4b/0x100 [803356e0] count_deleted_blocks_actor+0x0/0x20 [80342939] blocknr_set_iterator+0xc9/0x130 [802aeb2a] vfs_statfs_native+0x2a/0x70 [8053657c] trace_hardirqs_on_thunk+0x35/0x37 BUG: scheduling while atomic: gnome-volume-ma/0x1003/7793 [8023d72f] release_console_sem+0x4f/0x220 [80533fb2] cond_resched+0x32/0x40 [80539bb3] do_page_fault+0x613/0x8b0 [803356e0] count_deleted_blocks_actor+0x0/0x20 [803356e5] count_deleted_blocks_actor+0x5/0x20 [802ae8f7] vfs_statfs+0x67/0x80 [802b0133] vfs_read+0x173/0x180 INFO: lockdep is turned off. SysRq : Emergency Sync BUG: spinlock lockup on CPU#0, ktxnmgrd:sda2:r/539, 810003dcbc08 Call Trace: [803db034] _raw_spin_lock+0x134/0x140 [80337e64] commit_some_atoms+0x34/0x150 [80337e64] commit_some_atoms+0x34/0x150 [80342510] ktxnmgrd+0x0/0x1a0 [80342651] ktxnmgrd+0x141/0x1a0 [80342510] ktxnmgrd+0x0/0x1a0 [80253cab] kthread+0x4b/0x80 [8020d098] child_rip+0xa/0x12 [8020c780] restore_args+0x0/0x30 [80253c60] kthread+0x0/0x80 [8020d08e] child_rip+0x0/0x12 INFO: lockdep is turned off. NMI backtrace for cpu 0 Call Trace: NMI [805388e9] nmi_watchdog_tick+0x159/0x1e0 [80537d86] default_do_nmi+0x76/0x1e0 [805389ad] do_nmi+0x3d/0x60 [80537a9f] nmi+0x7f/0x80 [8023d72f] release_console_sem+0x4f/0x220 [803cc378] __delay+0x8/0x20 EOE [8021edff] __trigger_all_cpu_backtrace+0x1f/0x40 [803db039] _raw_spin_lock+0x139/0x140 [80337e64] commit_some_atoms+0x34/0x150 [80337e64] commit_some_atoms+0x34/0x150 [80342510] ktxnmgrd+0x0/0x1a0 [80342651] ktxnmgrd+0x141/0x1a0 [80342510] ktxnmgrd+0x0/0x1a0 [80253cab] kthread+0x4b/0x80 [8020d098] child_rip+0xa/0x12 [8020c780] restore_args+0x0/0x30 [80253c60] kthread+0x0/0x80 [8020d08e] child_rip+0x0/0x12 INFO: lockdep is turned off. Hangcheck: hangcheck value past margin! SysRq : Resetting -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
2.6.22-rc1-mm1 huge pages VM freeze (maybe?)
I was playing with huge pages and libhugetlbfs. Small programs like ls work fine. I tried running Evolution through libhugetlbfs and the system slowly stops running. One interesting thing is the ps command, it gets stuck like this: psD 81001e57ed40 0 103558 103483 81001f061dc8 0096 81003d8586e8 81001cbadc00 0006 80537009 0030 807ff700 807ff700 807ff700 807ff700 807ff700 Call Trace: [80537009] _spin_unlock+0x29/0x50 [80536425] __down_read+0x75/0xaf [80295f49] access_process_vm+0x49/0x190 [802f3003] proc_pid_cmdline+0xa3/0x130 [802f4cea] proc_info_read+0xba/0x100 [802b0085] vfs_read+0xc5/0x180 [802b0583] sys_read+0x53/0x90 [8020c1de] system_call+0x7e/0x83 and nothing will touch it after that. Here's my kernel command line: root=/dev/sda2 rootfstype=reiser4 rootflags=no_write_barrier ro i8042.nomux elevator=cfq resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug hugepages=32 Here's the huge script I was using to run programs: #!/bin/sh export LD_PRELOAD=libhugetlbfs.so export HUGETLB_MORECORE=yes export HUGETLB_PATH=/mnt/huge export HUGETLB_VERBOSE=1 exec $@ I don't have any more info than that at the moment but I could reproduce it with whatever, on request. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)
On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote: On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote: I was playing with huge pages and libhugetlbfs. Small programs like ls work fine. I tried running Evolution through libhugetlbfs and the system slowly stops running. One interesting thing is the ps command, it gets stuck like this: Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1? D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut paste to be sure: Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: -mm merge plans for 2.6.23
On Wed, 2007-07-25 at 15:05 -0700, Paul Jackson wrote: [snip] > Question: > Could those who have found this prefetch helps them alot say how > many disks they have? In particular, is their swap on the same > disk spindle as their root and user files? > > Answer - for me: > On my system where updatedb is a big problem, I have one, slow, disk. > On my system where updatedb is a small problem, swap is on a separate > spindle. > On my system where updatedb is -no- problem, I have so much memory > I never use swap. > > I'd expect the laptop crowd to mostly have a single, slow, disk, and > hence to find updatedb more painful. A well done swap-to-flash would help here. I sometimes do it anyway to a 4GB CF card but I can tell it's hitting the read/update/write cycles on the flash blocks. The sad thing is that it is still a speed improvement over swapping to laptop disk. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: -mm merge plans for 2.6.23
On Wed, 2007-07-25 at 09:02 -0700, Ray Lee wrote: > I'd just like updatedb to amortize its work better. If we had some way > to track all filesystem events, updatedb could keep a live and > accurate index on the filesystem. And this isn't just updatedb that > wants that, beagle and tracker et al also want to know filesystem > events so that they can index the documents themselves as well as the > metadata. And if they do it live, that spreads the cost out, including > the VM pressure. That would be nice. It'd be great if there was a per-filesystem inotify mode. I can't help but think it'd be more efficient than recursing every directory and adding a watch. Or maybe a netlink thing that could buffer events since filesystem mount until a daemon could get around to starting, so none were lost. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: -mm merge plans for 2.6.23
On Wed, 2007-07-25 at 09:02 -0700, Ray Lee wrote: I'd just like updatedb to amortize its work better. If we had some way to track all filesystem events, updatedb could keep a live and accurate index on the filesystem. And this isn't just updatedb that wants that, beagle and tracker et al also want to know filesystem events so that they can index the documents themselves as well as the metadata. And if they do it live, that spreads the cost out, including the VM pressure. That would be nice. It'd be great if there was a per-filesystem inotify mode. I can't help but think it'd be more efficient than recursing every directory and adding a watch. Or maybe a netlink thing that could buffer events since filesystem mount until a daemon could get around to starting, so none were lost. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: -mm merge plans for 2.6.23
On Wed, 2007-07-25 at 15:05 -0700, Paul Jackson wrote: [snip] Question: Could those who have found this prefetch helps them alot say how many disks they have? In particular, is their swap on the same disk spindle as their root and user files? Answer - for me: On my system where updatedb is a big problem, I have one, slow, disk. On my system where updatedb is a small problem, swap is on a separate spindle. On my system where updatedb is -no- problem, I have so much memory I never use swap. I'd expect the laptop crowd to mostly have a single, slow, disk, and hence to find updatedb more painful. A well done swap-to-flash would help here. I sometimes do it anyway to a 4GB CF card but I can tell it's hitting the read/update/write cycles on the flash blocks. The sad thing is that it is still a speed improvement over swapping to laptop disk. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On Tue, 2007-07-17 at 18:52 +0200, Rene Herman wrote: > On 07/17/2007 06:14 PM, Shawn Bohrer wrote: > > > I can't speak for Fedora, but RHEL disables XFS in their kernel likely > > because it is known to cause problems with 4K stacks. > > Okay. So is it fair to say it's largely XFS that's the problem? No problems > with LVM/MD and say plain ext? There *are* crashes from LVM and ext3. I had to change kernels to avoid them. I had crashes with ext3 on LVM snapshot on DM mirror on SATA. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [patch 0/3] reiser4 fixups
On Mon, 2007-07-16 at 22:50 +0400, Edward Shishkin wrote: > Zan Lynx wrote: > ... > > >Unable to handle kernel NULL pointer dereference at > RIP: > > [] reiser4_tree_by_page+0x4/0x20 [snip] > This is bug in Zam's new file_read: unlocked page was reclaimed, > then reiser4_tree_by_page() looks at page->mapping->host. > The patch #3 fixes this problem. > > Andrew, please apply the following series. These three patches appear to have fixed my problem. I ran it all of last afternoon and last night, and it did not oops. Thank you, Edward. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Re: [patch 0/3] reiser4 fixups
On Mon, 2007-07-16 at 22:50 +0400, Edward Shishkin wrote: Zan Lynx wrote: ... Unable to handle kernel NULL pointer dereference at RIP: [8033d324] reiser4_tree_by_page+0x4/0x20 [snip] This is bug in Zam's new file_read: unlocked page was reclaimed, then reiser4_tree_by_page() looks at page-mapping-host. The patch #3 fixes this problem. Andrew, please apply the following series. These three patches appear to have fixed my problem. I ran it all of last afternoon and last night, and it did not oops. Thank you, Edward. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On Tue, 2007-07-17 at 18:52 +0200, Rene Herman wrote: On 07/17/2007 06:14 PM, Shawn Bohrer wrote: I can't speak for Fedora, but RHEL disables XFS in their kernel likely because it is known to cause problems with 4K stacks. Okay. So is it fair to say it's largely XFS that's the problem? No problems with LVM/MD and say plain ext? There *are* crashes from LVM and ext3. I had to change kernels to avoid them. I had crashes with ext3 on LVM snapshot on DM mirror on SATA. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
On Thu, 2007-07-12 at 14:31 -0600, Zan Lynx wrote: > Edward Shishkin wrote: > > > > I have found the bug, which kills data > > when booting after crash, power loss, etc. > > The patch is attached. > > Please, ping me, if it doesn't help.. > > It appears to be holding up well so far. About 5 hours of Gentoo > updating and compiling. Maybe it isn't fixed so well at that. I got one of these today, here is the dmesg (at the bottom): Linux version 2.6.22-rc6-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.0 (Gentoo 4.2.0)) #4 SMP PREEMPT Wed Jul 11 23:22:08 MDT 2007 Command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=anticipatory resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug kernelcore=384M BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7f000 (ACPI data) BIOS-e820: 3ff7f000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fff8 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 262000) 1 entries of 256 used end_pfn_map = 1048576 DMI present. ACPI: RSDP 000F7240, 0014 (r0 PTLTD ) ACPI: RSDT 3FF7A87E, 0034 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 3FF7EE13, 0074 (r1 NVIDIA CK8 604 PTL_F4240) ACPI: DSDT 3FF7A8B2, 4561 (r1 NVIDIA CK8 604 MSFT 10E) ACPI: FACS 3FF7FFC0, 0040 ACPI: APIC 3FF7EE87, 005A (r1 NVIDIA NV_APIC_ 604 LTP0) ACPI: BOOT 3FF7EEE1, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 3FF7EF09, 00F7 (r1 PTLTD POWERNOW 604 LTP1) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 262000) 1 entries of 256 used No mptable found. sizeof(struct page) = 88 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node Node 0: 99328 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 262000 On node 0 totalpages: 261903 Node 0 memmap at 0x81000100 size 23068672 first pfn 0x81000100 DMA zone: 88 pages used for memmap DMA zone: 2784 pages reserved DMA zone: 1127 pages, LIFO batch:0 DMA32 zone: 2046 pages used for memmap DMA32 zone: 93186 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 3494 pages used for memmap Movable zone: 159178 pages, LIFO batch:31 Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x8008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000d swsusp: Registered nosave memory region: 000d - 0010 Allocating PCI resources starting at 5000 (gap: 4000:bff8) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 33144 bytes of per cpu data Built 1 zonelists in Zone order, mobility grouping on. Total pages: 253491 Kernel command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=anticipatory resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug kernelcore=384M Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) TSC calibrated against PM_TIMER time.c: Detected 797.942 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1648 kB per task-struct memory footprint: 1680 bytes | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock: ok | ok | ok
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
On Thu, 2007-07-12 at 14:31 -0600, Zan Lynx wrote: Edward Shishkin wrote: I have found the bug, which kills data when booting after crash, power loss, etc. The patch is attached. Please, ping me, if it doesn't help.. It appears to be holding up well so far. About 5 hours of Gentoo updating and compiling. Maybe it isn't fixed so well at that. I got one of these today, here is the dmesg (at the bottom): Linux version 2.6.22-rc6-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.0 (Gentoo 4.2.0)) #4 SMP PREEMPT Wed Jul 11 23:22:08 MDT 2007 Command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=anticipatory resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug kernelcore=384M BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7f000 (ACPI data) BIOS-e820: 3ff7f000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fff8 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 262000) 1 entries of 256 used end_pfn_map = 1048576 DMI present. ACPI: RSDP 000F7240, 0014 (r0 PTLTD ) ACPI: RSDT 3FF7A87E, 0034 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 3FF7EE13, 0074 (r1 NVIDIA CK8 604 PTL_F4240) ACPI: DSDT 3FF7A8B2, 4561 (r1 NVIDIA CK8 604 MSFT 10E) ACPI: FACS 3FF7FFC0, 0040 ACPI: APIC 3FF7EE87, 005A (r1 NVIDIA NV_APIC_ 604 LTP0) ACPI: BOOT 3FF7EEE1, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 3FF7EF09, 00F7 (r1 PTLTD POWERNOW 604 LTP1) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 262000) 1 entries of 256 used No mptable found. sizeof(struct page) = 88 Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 Movable zone start PFN for each node Node 0: 99328 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 262000 On node 0 totalpages: 261903 Node 0 memmap at 0x81000100 size 23068672 first pfn 0x81000100 DMA zone: 88 pages used for memmap DMA zone: 2784 pages reserved DMA zone: 1127 pages, LIFO batch:0 DMA32 zone: 2046 pages used for memmap DMA32 zone: 93186 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 3494 pages used for memmap Movable zone: 159178 pages, LIFO batch:31 Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x8008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000d swsusp: Registered nosave memory region: 000d - 0010 Allocating PCI resources starting at 5000 (gap: 4000:bff8) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 33144 bytes of per cpu data Built 1 zonelists in Zone order, mobility grouping on. Total pages: 253491 Kernel command line: root=/dev/sda2 rootfstype=reiser4 ro i8042.nomux elevator=anticipatory resume=/dev/sda3 panic=5 nmi_watchdog=2,panic debug kernelcore=384M Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) TSC calibrated against PM_TIMER time.c: Detected 797.942 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1648 kB per task-struct memory footprint: 1680 bytes | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-A deadlock: ok | ok | ok
Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
Edward Shishkin wrote: I have found the bug, which kills data when booting after crash, power loss, etc. The patch is attached. Please, ping me, if it doesn't help.. It appears to be holding up well so far. About 5 hours of Gentoo updating and compiling. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc6-mm1 reiser4_tree_by_page NULL pointer
Edward Shishkin wrote: I have found the bug, which kills data when booting after crash, power loss, etc. The patch is attached. Please, ping me, if it doesn't help.. It appears to be holding up well so far. About 5 hours of Gentoo updating and compiling. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] 4K stacks default, not a debug thing any more...?
Jesper Juhl wrote: Hi, I'm wondering if it's time to make 4K stacks the default and to start considering removing the 8K stack option alltogether soon? One of the big problem spots was XFS, but that got some stack usage fixes recently, and the 4K stack option has been around for quite a while now, so people really should have gotten around to fixing any code that can't handle it. Are there still any big problem areas remaining? Has anyone fixed the infrequent crashes with 4K stacks and ext3 -> LVM snapshot -> LVM -> DM mirror -> libata? The latest (as of 150 days ago) Fedora 6 32-bit kernels crashed every week or two, the 64-bit kernel, which I believe uses 8K stacks, has been up 150 days. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] 4K stacks default, not a debug thing any more...?
Jesper Juhl wrote: Hi, I'm wondering if it's time to make 4K stacks the default and to start considering removing the 8K stack option alltogether soon? One of the big problem spots was XFS, but that got some stack usage fixes recently, and the 4K stack option has been around for quite a while now, so people really should have gotten around to fixing any code that can't handle it. Are there still any big problem areas remaining? Has anyone fixed the infrequent crashes with 4K stacks and ext3 - LVM snapshot - LVM - DM mirror - libata? The latest (as of 150 days ago) Fedora 6 32-bit kernels crashed every week or two, the 64-bit kernel, which I believe uses 8K stacks, has been up 150 days. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
# CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Distributed Lock Manager # # CONFIG_DLM is not set # # Instrumentation Support # CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_KPROBES=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_PAGE_OWNER is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_DETECT_SOFTLOCKUP=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_SLUB_DEBUG_ON=y CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y # CONFIG_RT_MUTEX_TESTER is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_LOCKDEP is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_FRAME_POINTER is not set CONFIG_UNWIND_INFO=y # CONFIG_STACK_UNWIND is not set # CONFIG_PROFILE_LIKELY is not set # CONFIG_FORCED_INLINING is not set # CONFIG_DEBUG_SYNCHRO_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_LKDTM is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_KGDB is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_IOMMU_DEBUG is not set CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer
# CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Distributed Lock Manager # # CONFIG_DLM is not set # # Instrumentation Support # CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_KPROBES=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_PAGE_OWNER is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_DETECT_SOFTLOCKUP=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_SLUB_DEBUG_ON=y CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y # CONFIG_RT_MUTEX_TESTER is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_LOCKDEP is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_FRAME_POINTER is not set CONFIG_UNWIND_INFO=y # CONFIG_STACK_UNWIND is not set # CONFIG_PROFILE_LIKELY is not set # CONFIG_FORCED_INLINING is not set # CONFIG_DEBUG_SYNCHRO_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_LKDTM is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_KGDB is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_IOMMU_DEBUG is not set CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Thu, 2007-06-28 at 03:43 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ > +intel-iommu-dmar-detection-and-parsing-logic.patch > +intel-iommu-pci-generic-helper-function.patch > +intel-iommu-pci-generic-helper-function-fix.patch > +intel-iommu-clflush_cache_range-now-takes-size-param.patch > +intel-iommu-iova-allocation-and-management-routines.patch > +intel-iommu-iova-allocation-and-management-routines-fix.patch > +intel-iommu-iova-allocation-and-management-routines-fix-2.patch > +intel-iommu-intel-iommu-driver.patch > +intel-iommu-intel-iommu-driver-fix.patch > +intel-iommu-intel-iommu-driver-fix-2.patch > +intel-iommu-avoid-memory-allocation-failures-in-dma-map-api-calls.patch > +intel-iommu-intel-iommu-cmdline-option-forcedac.patch > +intel-iommu-dmar-fault-handling-support.patch > +intel-iommu-iommu-gfx-workaround.patch > +intel-iommu-iommu-floppy-workaround.patch > +intel-iommu-iommu-floppy-workaround-fix.patch > +intel-iommu-iommu-floppy-workaround-fix-fix.patch > > Intel IOMMU support I believe the above patch set is causing the problem. On my first try with rc6-mm1 I said Yes to the CONFIG_DMAR options. (I'm nearly as good as random option selection :-) The system panicked during boot, I believe it was trying to detect an Intel IOMMU. Later when I have a camera, I will try to post a screenshot of the backtrace. (I can't seem to get netconsole to work on boot, only in a module). When I recompiled without DMAR set, things seem to be working great. I seem to be getting better disk read throughput than rc3-mm1, by the way. This laptop is an AMD Athlon64 on a NForce3 running a 64-bit Gentoo build. I'll provide more details on request, and when I get the chance. This is a heads-up on the BUG in case someone has an "ah ha!" moment. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
On Thu, 2007-06-28 at 03:43 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/ +intel-iommu-dmar-detection-and-parsing-logic.patch +intel-iommu-pci-generic-helper-function.patch +intel-iommu-pci-generic-helper-function-fix.patch +intel-iommu-clflush_cache_range-now-takes-size-param.patch +intel-iommu-iova-allocation-and-management-routines.patch +intel-iommu-iova-allocation-and-management-routines-fix.patch +intel-iommu-iova-allocation-and-management-routines-fix-2.patch +intel-iommu-intel-iommu-driver.patch +intel-iommu-intel-iommu-driver-fix.patch +intel-iommu-intel-iommu-driver-fix-2.patch +intel-iommu-avoid-memory-allocation-failures-in-dma-map-api-calls.patch +intel-iommu-intel-iommu-cmdline-option-forcedac.patch +intel-iommu-dmar-fault-handling-support.patch +intel-iommu-iommu-gfx-workaround.patch +intel-iommu-iommu-floppy-workaround.patch +intel-iommu-iommu-floppy-workaround-fix.patch +intel-iommu-iommu-floppy-workaround-fix-fix.patch Intel IOMMU support I believe the above patch set is causing the problem. On my first try with rc6-mm1 I said Yes to the CONFIG_DMAR options. (I'm nearly as good as random option selection :-) The system panicked during boot, I believe it was trying to detect an Intel IOMMU. Later when I have a camera, I will try to post a screenshot of the backtrace. (I can't seem to get netconsole to work on boot, only in a module). When I recompiled without DMAR set, things seem to be working great. I seem to be getting better disk read throughput than rc3-mm1, by the way. This laptop is an AMD Athlon64 on a NForce3 running a 64-bit Gentoo build. I'll provide more details on request, and when I get the chance. This is a heads-up on the BUG in case someone has an ah ha! moment. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc3-mm1 reiser4 bug
On Sat, 2007-06-02 at 13:11 -0600, Berck E. Nash wrote: > All appears to work fine, until I try to boot a kernel with a Reiser4 / > partition. Then I get endless errors of the sort: > > [ 206.349450] sd 1:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET > driverbyte=DRIVER_OK,SUGGEST_OK > > (See attached dmesg for more, I only sent the first 1,000 lines, it goes > on until a hard reboot.) > > The same partition and the same kernel work great as long as that > partition isn't the current system root. The same kernel and the same > hard drive works fine as long as the partition is formatted ReiserFS. It can't be a simple bug, because I am running 2.6.22-rc3-mm1 and Reiser4 on / right now, and it works well for me. I am using a busybox initramfs that does the actual mounting. I don't know if that makes a difference. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Re: 2.6.22-rc3-mm1 reiser4 bug
On Sat, 2007-06-02 at 13:11 -0600, Berck E. Nash wrote: All appears to work fine, until I try to boot a kernel with a Reiser4 / partition. Then I get endless errors of the sort: [ 206.349450] sd 1:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK (See attached dmesg for more, I only sent the first 1,000 lines, it goes on until a hard reboot.) The same partition and the same kernel work great as long as that partition isn't the current system root. The same kernel and the same hard drive works fine as long as the partition is formatted ReiserFS. It can't be a simple bug, because I am running 2.6.22-rc3-mm1 and Reiser4 on / right now, and it works well for me. I am using a busybox initramfs that does the actual mounting. I don't know if that makes a difference. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Re: 2.6.22-rc2-mm1
device strings: Mfr=3, Product=4, SerialNumber=5 usb 3-2.3: Product: ImageMate 14 in 1 Reader/Writer usb 3-2.3: Manufacturer: SanDisk usb 3-2.3: SerialNumber: 0304237855 PM: Adding info for usb:3-2.3 PM: Adding info for No Bus:usbdev3.11_ep00 usb 3-2.3: configuration #1 chosen from 1 choice PM: Adding info for usb:3-2.3:1.0 scsi3 : SCSI emulation for USB Mass Storage devices PM: Adding info for No Bus:host3 PM: Adding info for No Bus:usbdev3.11_ep81 PM: Adding info for No Bus:usbdev3.11_ep02 usb-storage: device found at 11 usb-storage: waiting for device to settle before scanning usb 3-2.2.1: new low speed USB device using ehci_hcd and address 12 usb 3-2.2.1: new device found, idVendor=046d, idProduct=c704 usb 3-2.2.1: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2.2.1: Product: USB Receiver usb 3-2.2.1: Manufacturer: Logitech usb 3-2.2.1: SerialNumber: 04E5EF PM: Adding info for usb:3-2.2.1 PM: Adding info for No Bus:usbdev3.12_ep00 usb 3-2.2.1: configuration #1 chosen from 1 choice PM: Adding info for usb:3-2.2.1:1.0 input: Logitech USB Receiver as /class/input/input10 PM: Adding info for No Bus:hidraw1 input,hidraw1: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-:00:02.2-2.2.1 PM: Adding info for No Bus:usbdev3.12_ep81 PM: Adding info for usb:3-2.2.1:1.1 input: Logitech USB Receiver as /class/input/input11 PM: Adding info for No Bus:hiddev0 PM: Adding info for No Bus:hidraw2 input,hiddev0,hidraw2: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:02.2-2.2.1 PM: Adding info for No Bus:usbdev3.12_ep82 PM: Adding info for No Bus:target3:0:0 scsi 3:0:0:0: Direct-Access Generic STORAGE DEVICE 9339 PQ: 0 ANSI: 0 PM: Adding info for scsi:3:0:0:0 sd 3:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB) sd 3:0:0:0: [sdb] Write Protect is off sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00 sd 3:0:0:0: [sdb] Assuming drive cache: write through sd 3:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB) sd 3:0:0:0: [sdb] Write Protect is off sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00 sd 3:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 3:0:0:0: [sdb] Attached SCSI removable disk sd 3:0:0:0: Attached scsi generic sg2 type 0 PM: Adding info for No Bus:target3:0:1 PM: Removing info for No Bus:target3:0:1 PM: Adding info for No Bus:target3:0:2 PM: Removing info for No Bus:target3:0:2 PM: Adding info for No Bus:target3:0:3 PM: Removing info for No Bus:target3:0:3 PM: Adding info for No Bus:target3:0:4 PM: Removing info for No Bus:target3:0:4 PM: Adding info for No Bus:target3:0:5 PM: Removing info for No Bus:target3:0:5 PM: Adding info for No Bus:target3:0:6 PM: Removing info for No Bus:target3:0:6 PM: Adding info for No Bus:target3:0:7 PM: Removing info for No Bus:target3:0:7 usb-storage: device scan complete -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.22-rc2-mm1
: Adding info for No Bus:target3:0:6 PM: Removing info for No Bus:target3:0:6 PM: Adding info for No Bus:target3:0:7 PM: Removing info for No Bus:target3:0:7 usb-storage: device scan complete -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: 2.6.22 -mm merge plans
On Mon, 2007-04-30 at 16:20 -0700, Andrew Morton wrote: [snip] > Mel's moveable-zone work. > > I don't believe that this has had sufficient review and I'm sure that it > hasn't had sufficient third-party testing. Most of the approbations thus far > have consisted of people liking the overall idea, based on the changelogs and > multi-year-old discussions. > > For such a large and core change I'd have expected more detailed reviewing > effort and more third-party testing. And I STILL haven't made time to review > the code in detail myself. [snip] I am a fan of this, but I hadn't really realized that it's in -mm, and that it has to be enabled with kernelcore= Now that I am, I'm running it on my laptop with kernelcore=256M (it wouldn't boot with 128M or less, weird initscript errors and OOMs). 1 GB single-core laptops are probably not the intended test audience :) But I'll see what happens. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: 2.6.22 -mm merge plans
On Mon, 2007-04-30 at 16:20 -0700, Andrew Morton wrote: [snip] Mel's moveable-zone work. I don't believe that this has had sufficient review and I'm sure that it hasn't had sufficient third-party testing. Most of the approbations thus far have consisted of people liking the overall idea, based on the changelogs and multi-year-old discussions. For such a large and core change I'd have expected more detailed reviewing effort and more third-party testing. And I STILL haven't made time to review the code in detail myself. [snip] I am a fan of this, but I hadn't really realized that it's in -mm, and that it has to be enabled with kernelcore= Now that I am, I'm running it on my laptop with kernelcore=256M (it wouldn't boot with 128M or less, weird initscript errors and OOMs). 1 GB single-core laptops are probably not the intended test audience :) But I'll see what happens. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [-mm patch] i386: enable 4k stacks by default
On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote: > 4k stacks have become a well-tested feature used fore a long time in > Fedora and even in RHEL 4. So has anyone fixed the bugs involving ext3 and LVM snapshots on top of DM mirror? Our 32-bit Fedora Core 5 dual Opteron server at work crashed once a week while running rdiff-backup off a snapshot. Installing a 64-bit kernel stopped the crashes, and I believe the 64-bit still uses the bigger stacks. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [-mm patch] i386: enable 4k stacks by default
On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote: 4k stacks have become a well-tested feature used fore a long time in Fedora and even in RHEL 4. So has anyone fixed the bugs involving ext3 and LVM snapshots on top of DM mirror? Our 32-bit Fedora Core 5 dual Opteron server at work crashed once a week while running rdiff-backup off a snapshot. Installing a 64-bit kernel stopped the crashes, and I believe the 64-bit still uses the bigger stacks. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
