Re: Disk schedulers

2008-02-15 Thread Zan Lynx

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

2008-02-06 Thread Zan Lynx

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

2008-02-06 Thread Zan Lynx
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
CONFIG_S

Re: 2.6.24-mm1 - build error, AMD MCE using Intel ifdef'd log function

2008-02-04 Thread Zan Lynx

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

2008-01-29 Thread Zan Lynx

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.

2008-01-28 Thread Zan Lynx

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

2008-01-28 Thread Zan Lynx

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

2008-01-25 Thread Zan Lynx

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

2008-01-24 Thread Zan Lynx

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

2008-01-23 Thread Zan Lynx
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


Re: Why is the kfree() argument const?

2008-01-18 Thread Zan Lynx

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

2008-01-18 Thread Zan Lynx

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.

2008-01-18 Thread Zan Lynx

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

2008-01-17 Thread Zan Lynx
NING 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_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

2008-01-17 Thread Zan Lynx

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: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)

2008-01-10 Thread Zan Lynx

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

2007-12-08 Thread Zan Lynx

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

2007-12-07 Thread Zan Lynx

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

2007-12-07 Thread Zan Lynx

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

2007-12-07 Thread Zan Lynx

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

2007-12-07 Thread Zan Lynx
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

2007-12-07 Thread Zan Lynx
: [sdf] Attached SCSI removable disk
sd 3:0:0:3: Attached scsi generic sg6 type 0
ReiserFS: sda1: replayed 120 transactions in 1 seconds
ReiserFS: sda1: Using r5 hash to sort names
Adding 2843496k swap on /dev/sda3.  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

2007-12-07 Thread Zan Lynx
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-rc2-mm1

2007-11-13 Thread Zan Lynx

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

2007-10-19 Thread Zan Lynx
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

2007-10-15 Thread Zan Lynx
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

2007-10-15 Thread Zan Lynx
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: [patch] reiser4: do not allocate struct file on stack

2007-10-05 Thread Zan Lynx
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

2007-09-27 Thread Zan Lynx
A_FS is not set
# 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


Re: 2.6.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes

2007-08-23 Thread Zan Lynx
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

2007-08-22 Thread Zan Lynx
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)

2007-08-13 Thread Zan Lynx
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)

2007-08-13 Thread Zan Lynx
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: why are some atomic_t's not volatile, while most are?

2007-08-07 Thread Zan Lynx
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?)

2007-08-01 Thread Zan Lynx
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?)

2007-07-31 Thread Zan Lynx
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?)

2007-07-31 Thread Zan Lynx
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

2007-07-31 Thread Zan Lynx
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


Re: -mm merge plans for 2.6.23

2007-07-25 Thread Zan Lynx
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

2007-07-25 Thread Zan Lynx
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: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

2007-07-17 Thread Zan Lynx
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

2007-07-17 Thread Zan Lynx
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: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer

2007-07-13 Thread Zan Lynx
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  |  

Re: 2.6.22-rc6-mm1 reiser4_tree_by_page NULL pointer

2007-07-12 Thread Zan Lynx

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

2007-07-11 Thread Zan Lynx

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

2007-07-10 Thread Zan Lynx
# 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

2007-06-28 Thread Zan Lynx
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

2007-06-02 Thread Zan Lynx
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

2007-05-23 Thread Zan Lynx
d USB device using ehci_hcd and address 11
usb 3-2.3: new device found, idVendor=0781, idProduct=b4b5
usb 3-2.3: new 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 -mm merge plans

2007-05-01 Thread Zan Lynx
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

2007-04-28 Thread Zan Lynx
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: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)

2007-04-27 Thread Zan Lynx
On Fri, 2007-04-27 at 11:31 -0700, Andrew Morton wrote:
[snip]
> ext3's problem here is that a single fsync() requires that ext3 sync the
> whole filesystem.  Because
> 
> - a journal commit can contain metadata from multiple files, and if we
>   want to journal one file's metadata via fsync(), we unavoidably journal
>   all the other file's metadata at the same time.
> 
> - ordered mode requires that we write a file's data blocks prior to
>   journalling the metadata which refers to those blocks.
> 
> net result: syncing anything syncs the whole world.
> 
> There are a few areas in which this could conceivably be tuned up: if a
> particular file doesn't currently have any metadata in the commit, we don't
> actually need to sync its data blocks: we could just transfer them into
> next commit.  Hard, unlikely to be of benefit.
[snip]

How about mixing the ordered and data journal modes?  If the data blocks
would fit, have fsync write them into the journal as is done in
data=journal mode.  Then that file data is committed to disk as fsync
requires, but it shouldn't require flushing all the previous metadata to
get an ordered guarantee.

Or so it seems to me.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: coding style for long conditions

2007-04-06 Thread Zan Lynx
On Fri, 2007-04-06 at 14:38 -0700, Roland Dreier wrote:
[snip]
> If you have a git tree handy, you can do "git show 68380b58" and see
> that Linus himself wrote:
> 
>   if (get_wq_data(work) == cwq
>   && work_pending(work)
>   && !list_empty(&work->entry)) {
> 
> I have to admit that I would have put the &&s at the ends of the
> previous lines rather than where Linus put them, but... egads!  Linus
> put spaces before the &&s to line them up nicely!

My favorite form uses only tabs and would make that look like:
if(
get_wq_data(work) == cwq &&
work_pending(work) &&
!list_empty(&work->entry)
) {
...
...
}

Putting the && at the front would be OK with me too, it does make them
more obvious and easier to find.

I don't find too many people who like my style but that's OK.  I think
it makes everything a lot easier to read and everything lines up with
8-space tabs or 2 or 3 space tabs.  Plus, reformatting other people's
code gives me a good chance to read it as I go. :-)
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


2.6.21-rc5-mm4 initramfs Make Error

2007-04-05 Thread Zan Lynx
I built a version of 2.6.21-rc5-mm4 with an initramfs and it built OK
the first time.

Then I made changes (applied a Reiser4 patch) and rebuilt, and got the
following error:

zephyr linux # make
  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CALLscripts/checksyscalls.sh
:1356:2: warning: #warning syscall getcpu not implemented
:1360:2: warning: #warning syscall epoll_pwait not implemented
:1364:2: warning: #warning syscall lutimesat not implemented
:1380:2: warning: #warning syscall revokeat not implemented
:1384:2: warning: #warning syscall frevoke not implemented
  CHK include/linux/compile.h
/usr/src/linux-2.6.21-rc5-mm4/usr/Makefile:41: *** target pattern contains no 
`%'.  Stop.
make: *** [usr] Error 2

I have this in the config:
CONFIG_INITRAMFS_SOURCE="/initramfs"

/initramfs is the directory where I build my initramfs, which is just a
busybox setup, very simple.

# rm usr/.initramfs_data.*
seems to make it go again.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: 2.6.21-rc5-mm2 OOPS and spinlock lockup

2007-03-28 Thread Zan Lynx
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/
> 
> 
> - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU
>   scheduler has been added.

Here is the last bit of netconsole dump I had from my laptop when the
kernel died just now.

Note that the kernel is compiled with SMP but the laptop is one core
only. I have CONFIG_DEBUG_SPINLOCK=y and CONFIG_DEBUG_SPINLOCK_SLEEP=y

It's AMD-64.

[ 2597.436421] Hangcheck: hangcheck value past margin!
[ 2794.356033] Unable to handle kernel NULL pointer dereference at 
00c0 RIP: 
[ 2794.356058]  [] _raw_spin_lock+0x1f/0x140
[ 2794.356088] PGD 9f39067 PUD 9f38067 PMD 0 
[ 2794.356180] Oops:  [1] PREEMPT SMP 
[ 2794.356261] last sysfs file: devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 2794.356328] CPU 0 
[ 2794.356341] Modules linked in: netconsole nls_iso8859_1 nls_cp437 vfat fat 
nls_base zaurus cdc_ether usbnet snd_pcm_oss snd_mixer_oss rfcomm hidp hid 
l2cap ipv6 hci_usb bluetooth usb_storage snd_intel8x0 psmouse serio_raw 
snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc ehci_hcd ohci_hcd 
ssb usbcore evdev sg
[ 2794.357227] Pid: 8049, comm: khidpd_046db3e1 Not tainted 2.6.21-rc5-mm2 #1
[ 2794.357295] RIP: 0010:[]  [] 
_raw_spin_lock+0x1f/0x140
[ 2794.357318] RSP: :81000d865d10  EFLAGS: 00010282
[ 2794.357329] RAX: 81000d739040 RBX: 00b8 RCX: 
[ 2794.357396] RDX:  RSI:  RDI: 00b8
[ 2794.357408] RBP: 81000e23dd08 R08: 0002 R09: 
[ 2794.357422] R10: 80318019 R11:  R12: 81000e23dd10
[ 2794.357435] R13:  R14: 81000e16b928 R15: 81000b518720
 [] _raw_spin_lock+0x1f/0x140
[ 2794.359149]  RSP 
[ 2794.359214] CR2: 00c0
[ 2794.359268] note: khidpd_046db3e1[8049] exited with preempt_count 3
[ 2804.355026] BUG: soft lockup detected on CPU#0!
[ 2804.355037] 
[ 2804.355039] Call Trace:
[ 2804.355051][] softlockup_tick+0xf9/0x140
[ 2804.355140]  [] update_process_times+0x57/0x90
[ 2804.355157]  [] smp_local_timer_interrupt+0x34/0x60
[ 2804.355171]  [] smp_send_timer_broadcast_ipi+0x3a/0x60
[ 2804.355188]  [] timer_interrupt+0x23/0x30
[ 2804.355259]  [] handle_IRQ_event+0x1e/0x60
[ 2804.355275]  [] handle_edge_irq+0xfa/0x150
[ 2804.355291]  [] do_IRQ+0x110/0x190
[ 2804.355306]  [] ret_from_intr+0x0/0xf
[ 2804.355371][] shrink_dcache_parent+0x2c/0x120
[ 2804.355399]  [] _raw_spin_lock+0xac/0x140
[ 2804.355413]  [] _raw_spin_lock+0xb9/0x140
[ 2804.355484]  [] shrink_dcache_parent+0x2c/0x120
[ 2804.355499]  [] proc_flush_task+0x76/0x220
[ 2804.355518]  [] release_task+0x316/0x360
[ 2804.355532]  [] do_wait+0x80f/0xc10
[ 2804.355607]  [] default_wake_function+0x0/0x10
[ 2804.355624]  [] system_call+0x7e/0x83
[ 2804.355639] 
[ 2804.355646] INFO: lockdep is turned off.
[ 2821.783782] BUG: spinlock lockup on CPU#0, init/1, 806b0e00
[ 2821.783793] 
[ 2821.783794] Call Trace:
[ 2821.783830]  [] _raw_spin_lock+0xfa/0x140
[ 2821.783845]  [] shrink_dcache_parent+0x2c/0x120
[ 2821.783866]  [] proc_flush_task+0x76/0x220
[ 2821.783895]  [] release_task+0x316/0x360
[ 2821.783910]  [] do_wait+0x80f/0xc10
[ 2821.783939]  [] default_wake_function+0x0/0x10
[ 2821.783956]  [] system_call+0x7e/0x83
[ 2821.783983] 
[ 2821.783989] INFO: lockdep is turned off.

-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: [Bluez-devel] 2.6.21-rc4-mm1

2007-03-23 Thread Zan Lynx
On Wed, 2007-03-21 at 15:12 +0100, Marcel Holtmann wrote:
> Hi Andrew,
> 
> > >   * Freezes immediately if I allow Bluetooth to configure.
> > 
> > cc bluez-devel
> 
> is the -mm specific or does this also happens with 2.6.21-rc4?

Bluetooth works now, so it isn't entirely -mm's fault.  

I applied a posted patch for the Sonic Silicon Backplane.  I also set
all the older BCM43xx driver modules to N, and my freeze with wireless
went away.

On this laptop (a Compaq R3000) the Bluetooth and the wireless are
controlled by the same front panel button, so I wonder if they are
related in other ways as well.

If I get a chance to play with it this weekend I will see if I can
isolate the change that fixes/breaks it.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: 2.6.21-rc4-mm1

2007-03-23 Thread Zan Lynx
On Wed, 2007-03-21 at 11:13 -0500, Larry Finger wrote:
> Andrew Morton wrote:
> > On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote:
> >> First impressions:
> >> Several of the same bugs as rc3-mm*:
> >>   * Freezes immediately if I touch the wlan0 device after loading
> >> the new Broadcom wireless driver.
> 
> --snip--
> 
> >> 02:02.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless 
> >> LAN Controller (rev 02)
> 
> I'm a little confused. The bcm43xx-mac80211 driver does not handle 802.11b 
> devices, and the
> bcm43xx-softmac driver should not freeze. Which one was configured here?

It may have partly been a problem of having half of softmac and half
devicescape.  I'm not entirely sure what udev did.

I tried a patch for the Sonic Silicon that was posted and I turned off
all the configuration for the softmac driver.

It isn't crashing right now but 802.11 isn't working either.  I may get
a chance this weekend to try some things with it, and some different
firmware sets.

If the new bcm43xx drivers do not support 802.11b at all and never will,
I missed the documentation.  Someone should add that to Kconfig.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: Stolen and degraded time and schedulers

2007-03-14 Thread Zan Lynx
On Tue, 2007-03-13 at 23:52 -0700, Jeremy Fitzhardinge wrote:
> Yep.  But the tsc is just an example of a clocksource, and doesn't have
> any real bearing on what I'm saying.
[cut/snip/slash]
> Well, it doesn't need to be a constant clock if its modelling a changing
> rate.  And it doesn't need to be an exact model; it just needs to be
> better than the current situation.

It's 2 AM so I don't know if I'm making sense, but I had an idea for the
sort of clock I think you're looking for.

Couldn't one of the CPU performance counters do this?  I think you can
set one to count cycles and trigger every 100,000, or 10,000 or 1,000,
or whatever.  Then when you get that interrupt hit the context switch.

Then every time slice would be in cycles and not wall-clock, which is
what I think you wanted.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: 2.6.21-rc2-mm1

2007-03-05 Thread Zan Lynx
On Sun, 2007-03-04 at 10:07 +0100, Mariusz Kozlowski wrote:
> Hello,
> 
>   I'm experiencing weird system hangs with recent -mm. After a few hours 
> of uptime for no
> obvious reason system hangs and is (almost) unusable until reset.

This is similar to what I have been experiencing.  I have not been able
to get my laptop to run 2.6.21-rc2-mm1 for more than 5 minutes.  The
last kernel I had working was 2.6.20-rc6-mm3.

The problems may be multiple.  Whenever I load the new bcm43xx drivers
and do *anything* with iwconfig, it locks hard.  No keyboard LEDs, and
sysrq does not work.

While I had it in single-user mode, no bcm43xx drivers loaded, I was
using make menuconfig to try a different configuration, and it locked
hard for no apparent reason.  Again, no keyboard LEDs, no sysrq.

Laptop fans come on full speed after a bit, so something is still
happening in the BIOS.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


2.6.20-rc6-mm3 possible circular lock on mmap_sem

2007-02-01 Thread Zan Lynx
ae/0xd0
[  142.314219]  [] read_unix_file+0xdb/0x450
[  142.314225]  [] vma_merge+0x12b/0x1e0
[  142.314291]  [] vfs_read+0xba/0x180
[  142.314297]  [] sys_read+0x53/0x90
[  142.314360]  [] system_call+0x7e/0x83
[  142.314366] 

-- 
Zan Lynx <[EMAIL PROTECTED]>



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


Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption

2007-02-01 Thread Zan Lynx
On Thu, 2007-02-01 at 18:54 +0300, Edward Shishkin wrote:
[snip]
> Thanks for the dump.
> 
> >[ 3138.456588]  [] current_atom_finish_all_fq+0x12e/0x280
> >[ 3138.456661]  [] autoremove_wake_function+0x0/0x30
> >[ 3138.456674]  [] submit_wb_list+0x11c/0x130
> >[ 3138.456690]  [] reiser4_txn_end+0x349/0x530
> >[ 3138.456710]  [] reiser4_txn_restart+0x9/0x20
> >[ 3138.456781]  [] force_commit_atom+0x50/0x60
> >[ 3138.456793]  [] writepages_unix_file+0x671/0x780
> >[ 3138.456824]  [] do_writepages+0x43/0x80
> >[ 3138.456838]  [] __filemap_fdatawrite_range+0x58/0x70
> >[ 3138.456914]  [] do_fsync+0x3d/0xe0
> >[ 3138.456930]  [] sys_msync+0x143/0x1f0
> >[ 3138.456945]  [] system_call+0x7e/0x83
> >  
> >
> 
> This is waiting for IO completion, and no success because of new plugging
> policy introduced by block layer folks. The attached patch should help.
> Andrew, please apply.

OK, I have been using it with your patch for many hours and it has not
frozen up yet.  I believe that the patch did indeed fix it.

Thank you.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption

2007-01-19 Thread Zan Lynx
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes.  They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
full fsck.reiser4 --build-fs to recover the filesystem.

But I finally got some output in a console session.  I wasn't able to
get it all, I made some notes of what I think the problem is.  I may try
again later once I get netconsole working (netconsole fails as a
built-in, I'll try it as a module next).

1 lock held by pdflush/185:
#0: (&type->s_umount_key#15) ... writeback_inodes+0x89

3 locks held by realsync/12942:
#0: (&type->s_umount_key#15) at ... __sync_inodes+0x78
#1: (&mgr->commit_mutex) ... reiser4_txn_end+0x37a
#2: (&qp->mutex) ... synchronize_qrcu+0x19

So, I *think* the problem is two locks on s_umount_key#15.  Does that
sound likely?  I also noticed QRCU may be involved.

Perhaps someone will look at this and instantly know what the problem
is.

If not, I'll be following up with more details like .config and perhaps
a full sysrq-T dump as soon as that fsck finishes.


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


Disk Cache, Was: O_DIRECT question

2007-01-12 Thread Zan Lynx
On Sat, 2007-01-13 at 00:03 +0300, Michael Tokarev wrote:
[snip]
> And sure thing, withOUT O_DIRECT, the whole system is almost dead under this
> load - because everything is thrown away from the cache, even caches of /bin
> /usr/bin etc... ;)  (For that, fadvise() seems to help a bit, but not alot).

One thing that I've been using, and seems to work well, is a customized
version of the readahead program several distros use during boot up.

Mine starts off doing:
mlockall(MCL_CURRENT|MCL_FUTURE);
...yadda, yadda...

and for each file listed:
...open, stat stuff...
   if( NULL == mmap(
NULL, stat_buf.st_size, 
PROT_READ, MAP_SHARED|MAP_LOCKED|MAP_POPULATE,
fd, 0)
) {
fprintf(stderr, "'%s' ", file);
perror("mmap");
}
...more stuff...
and then ends with:
pause();
and it sits there forever.

As far as I can tell, this makes the program and library code stay in
RAM.  At least, after a drop_caches nautilus doesn't load 12 MB off
disk, it just starts.  It has to be reloaded after software updates and
after prelinking.  I find the 250 MB used to be worthwhile, even if its
kinda Windowsey.

Something like that could keep your system responsive no matter what the
disk cache is doing otherwise.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: A "new driver model" and EXPORT_SYMBOL_GPL question

2005-07-05 Thread Zan Lynx
On Sun, 2005-07-03 at 22:44 -0700, Greg KH wrote:
> On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote:
[snip]
> Then take it up with them.  Users of those symbols have had many months
> advance notice that this was going to happen.
> 
> > Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
> > what considerations dictated it, other then the patch author wrote
> > it that way, and what drivers in question are supposed to use when
> > this change will show up in the mainline?  It looks that 2.6.13
> > will do this.
> 
> Please see the archives for the answers to these questions.

The archives say:
Greg KH wrote:
> I have been recently advised that I should not change these symbols,
> and so I will not.
> 
> Sorry for the noise and wasted bandwidth, will not happen again.
> 
> greg k-h

Sourced from here:
http://hulllug.principalhosting.net/archive/index.php/t-52440.html

That was the way it was as of 2.6.10-mm1 and it stayed that way through
2.6.12.  When did that decision change?  If it was there in the
archives, I missed it in the search.

If this was a Greg-only decision, perhaps a patch reversing the change
addressed to Linus would get a solid yes/no decision from the top.

From what I gather in the archives, the last time this happened it was
just a leak from Greg's tree and not an official policy change.  It
isn't in the feature removal schedule, even though other _GPL changes
are listed there.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: intercepting syscalls

2005-04-15 Thread Zan Lynx
On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> Hello,
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
> Patching kernel to export sys_call_table is not an option. The fast
> and dirty way to do this would be by using System.map, but I would
> rather we find a cleaner approach.

These ideas are hardly a clean approach but might work although I
haven't tried:

Hook into an existing kernel function that is exported to modules that
can be called by a system call, like a /proc or /sys file.  On a
sys_read or sys_write to your /proc file, perform a stack trace back to
the system call, then search and adjust to find the system call table
pointer.

You might also be able to look at the int $80 vector and grub through
the machine code to find it.

Of course, anything like this will probably only work on x86 and need to
be rewritten for each architecture.  Very messy.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

2005-04-12 Thread Zan Lynx
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote:
[snip]
> > A did put a GPL notice on it. He can't change his mind later.
> Then he should give us the source.
[snip]
> The fact remains that those firmware blob have no licence, and thus defacto
> fall under the GPL.
> 
> > Moreover, the firmare in not in binary form, but is part of a C source
> > file.
> 
> It is in binary form. Disguised binary form maybe but still binary form.
[snip]
> And where did those hexstrings come from ? 

It seems to me, that to be consistent with the argument you seem to be
presenting concerning binary data in GPLd code, that you also need to be
demanding the "source" hardware design for binary register values.

Why not consider the binary firmware in the same category as binary
register programming information?  You poke these magic bytes into these
memory locations and it works.

Where do you draw the lines between "write this byte to set the input
gate here and the output gate to there" and "write this byte sequence to
send the input byte through this loop, into this buffer, add it to the
last byte entered, and output it over there"?
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: Can't use SYSFS for "Proprietry" driver modules !!!.

2005-03-28 Thread Zan Lynx
On Mon, 2005-03-28 at 19:33 -0800, Greg KH wrote:
> Also, the code has undergone a rewrite, fixing many issues, and changing
> the way things work to tie more closely into the main driver core code.
> As such, the class_simple code is now just gone, there is no such need
> for it.  And as such, the new code contains the _GPL markings, as I do
> not think that _anyone_ can try to claim that their code would not be a
> derived work of Linux who wants to use it (as no other OS has such a
> driver model interface.)

That does not really make sense, as the driver model code could be used
for ndiswrapper, for example.  That would not make the Windows net
drivers derived code of the Linux kernel.  ndiswrapper, yes it would be.
Binary driver blobs, no.

ndiswrapper is a perfect example, in fact.  It is GPL, and implements an
_interface_ to binary code that is not GPL.  

It seems to me that any author has the right to create a public
interface into the kernel.  

If that interface is well-defined and public, implementing it from the
other side in binary code does not create a derived work.  It is
especially obvious if there are multiple interface implementations.
Hard to argue that the same binary that links unchanged into Windows,
BSD and Linux is Linux-derived.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: dmesg verbosity [was Re: AGP bogosities]

2005-03-22 Thread Zan Lynx
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote:
> El Mon, 14 Mar 2005 14:07:53 -0500,
> Lee Revell <[EMAIL PROTECTED]> escribió:
> 
> > I'm really not trolling, but I suspect if we made the boot process less
> > verbose, people would start to wonder more about why Linux takes so much
> > longer than XP to boot.
> 
> By the way, Microsoft seems to be claiming that boot time will be reduced to 
> the half
> with Longhorn. While we already know how ms marketing team works, 50% looks
> like a lot. Is there a good place to discuss what could be done in the 
> linuxland to
> improve things? It doesn't looks like a couple of optimizations will be 
> enought...

Make software suspend work 100% of the time and rename "resume" to
"fastboot".
-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: Please open sysfs symbols to proprietary modules

2005-02-02 Thread Zan Lynx
On Wed, 2005-02-02 at 16:30 -0800, Greg KH wrote:
> On Wed, Feb 02, 2005 at 07:07:21PM -0500, Pavel Roskin wrote:
> > On Wed, 2 Feb 2005, Greg KH wrote:
> > >On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:
> > >>
> > >>What is wrong with creating a (GPL'd) abstraction layer that exports
> > >>symbols to the proprietary modules?
> > >
> > >Ick, no!
> > >
> > >Please consult with a lawyer before trying this.  I know a lot of them
> > >consider doing this just as forbidden as marking your module
> > >MODULE_LICENSE("GPL"); when it really isn't.
> > 
> > There will be a GPL'd layer, and it's likely that sysfs interaction will 
> > be on the GPL'd side anyway, for purely technical reasons.  But it does 
> > feel like circumvention of the limitations set in the kernel.
> 
> It is.  And as such, it is not allowed.
[snip]

So, what's the magic amount of redirection and abstraction that cleanses
the GPLness, hmm?  Who gets to wave the magic wand to say what
interfaces are GPL-to-non-GPL and which aren't?

For example, the IDE drivers use GPL symbols but the VFS does not.  So
anyone can write a proprietary filesystem which eventually gets around
to driving the IDE layer.  That is okay, but this isn't?

If the trend of making everything _GPL continues, I don't see any choice
for binary module vendors but to join together to develop a stable
driver API and build it as a GPL/BSD module.  Do the same API for BSD
systems to prove modules using it are not GPL derived.  Watch Greg foam.
It'd be fun.
--
Zan Lynx <[EMAIL PROTECTED]>


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


Re: [PATCH 2/8] lib/sort: Replace qsort in XFS

2005-02-01 Thread Zan Lynx
On Tue, 2005-02-01 at 14:22 -0800, Randy.Dunlap wrote:
> Chris Wedgwood wrote:
> > On Mon, Jan 31, 2005 at 01:34:59AM -0600, Matt Mackall wrote:
> > 
> > 
> >>+#define qsort xfs_sort
> >>+static inline void xfs_sort(void *a, size_t n, size_t s,
> >>+   int (*cmp)(const void *,const void *))
> >>+{
> >>+   sort(a, n, s, cmp, 0);
> >>+}
> >>+
> > 
> > 
> > why not just:
> > 
> > #define qsort(a, n, s, cmp) sort(a, n, s, cmp, NULL)
> > 
> > 
> > 
> > On Mon, Jan 31, 2005 at 01:35:00AM -0600, Matt Mackall wrote:
> > 
> > 
> >>Switch NFS ACLs to lib/sort
> > 
> > 
> >>+   sort(acl->a_entries, acl->a_count, sizeof(struct posix_acl_entry),
> >>+cmp_acl_entry, 0);
> > 
> > 
> > There was a thread about stlye and I though the concensurs for null
> > pointers weas to use NULL and not 0?
> 
> Yes, otherwise sparse complains... and maybe Linus  :)

And you get in the habit of using 0 instead of NULL and before you know
it you've used it in a variable argument list for a GTK library call on
an AMD64 system and corrupted the stack. :-)

(The compiler can't convert 0 to a pointer if it doesn't know that it's
supposed to be one.  Variable argument lists are evil that way.)

-- 
Zan Lynx <[EMAIL PROTECTED]>


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


Re: thoughts on kernel security issues

2005-01-27 Thread Zan Lynx
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
> On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
> > On Wed, 26 Jan 2005, Jesse Pollard wrote:
> > > On Tuesday 25 January 2005 15:05, linux-os wrote:
> > > > This isn't relevant at all. The Navy doesn't have any secure
> > > > systems connected to a network to which any hackers could connect.
> > > > The TDRS communications satellites provide secure channels
> > > > that are disassembled on-board. Some ATM-slot, after decryption
> > > > is fed to a LAN so the sailors can have an Internet connection
> > > > for their lap-tops. The data took the same paths, but it's
> > > > completely independent and can't get mixed up no matter how
> > > > hard a hacker tries.
> > >
> > > Obviously you didn't hear about the secure network being hit by the "I
> > > love you" virus.
> > >
> > > The Navy doesn't INTEND to have any secure systems connected to a network
> > > to which any hackers could connect.
> >
> > What's hard about that? Matter of physical network topology, absolutely no
> > physical connection, no machines with a 2nd NIC, no access to/from I'net.
> > Yes, it's a PITA, add logging to a physical printer which can't be erased
> > if you want to make your CSO happy (corporate security officer).
> 
> And you are ASSUMING the connection was authorized. I can assure you that 
> there are about 200 (more or less) connections from the secure net to the
> internet expressly for the purpose of transferring data from the internet
> to the secure net for analysis. And not ALL of these connections are 
> authorized. Some are done via sneakernet, others by running a cable ("I need
> the data NOW... I'll just disconnect afterward..."), and are not visible
> for very long. Other connections are by picking up a system and carrying it
> from one connection to another (a version of sneakernet, though here it
> sometimes needs a hand cart).
> 
> > > Unfortunately, there will ALWAYS be a path, either direct, or indirect
> > > between the secure net and the internet.
> >
> > Other than letting people use secure computers after they have seen the
> > Internet, a good setup has no indirect paths.
> 
> Ha. Hahaha...
> 
> Reality bites.

In the reality I'm familiar with, the defense contractor's secure
projects building had one entrance, guarded by security guards who were
not cheap $10/hr guys, with strict instructions.  No computers or
computer media were allowed to leave the building except with written
authorization of a corporate officer.  The building was shielded against
Tempest attacks and verified by the NSA.  Any computer hardware or media
brought into the building for the project was physically destroyed at
the end.

Secure nets _are_ possible.
-- 
Zan Lynx <[EMAIL PROTECTED]>


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