* 2.6.0-test8-mm1
@ 2003-10-20 9:05 Andrew Morton
2003-10-20 11:18 ` 2.6.0-test8-mm1 Thomas Schlichter
` (3 more replies)
0 siblings, 4 replies; 26+ messages in thread
From: Andrew Morton @ 2003-10-20 9:05 UTC (permalink / raw)
To: linux-kernel, linux-mm
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test8/2.6.0-test8-mm1
. Included a much updated fbdev patch. Anyone who is using framebuffers,
please test this.
. Quite a large number of stability fixes.
Changes since 2.6.0-test7-mm1:
-RD0-initrd-B6.patch
-sjcd-usercopy-checks.patch
-might_sleep-vs-jiffies-wrap.patch
-selinux-add-policyvers.patch
-mandocs-case-fix.patch
-swapon-handle-no-readpage.patch
-reiserfs-url-fixes.patch
-numaq-mpc-warning-fix.patch
-invalidate_inodes-speedup.patch
-invalidate_inodes-speedup-fixes.patch
-ide-piix-fallback-fix.patch
-ext3-i_disksize-locking-fix.patch
-applicom-fixes.patch
-acl-signedness-fix.patch
-saa7134-build-fix.patch
-ide-write-barrier-support.patch
-jbd-barrier-selection.patch
Merged
-vma-split-truncate-race-fix.patch
-vma-split-truncate-race-fix-tweaks.patch
+vma-split-truncate-race-fix-2.patch
Fix a race between vma_split() and truncation (rebased to Linus's tree)
+devfs-initrd-fix.patch
Fix initrd when devfs is in use
-ppc64-semaphore-reimplementation.patch
Dropped; it didn't solve the starvation problems anyway.
-ppc64-sym2-fix.patch
No longer needed.
-cursor-flashing-fix.patch
-radeonfb-line_length-fix.patch
Fixed in fbdev.patch
+fbdev-restore-pci-ids.patch
Fix AGP compilation.
+limit_regions-syncup.patch
Backport 2.4's ia32 "mem=" fix.
+ia32-efi-asm-warning-fix.patch
+ia32-efi-support-mem-equals-fix.patch
+efi-constant-sizing-fix.patch
More fixes for the EFI patch.
+fix-sqrt.patch
Fix int_sqrt().
scale-min_free_kbytes.patch
Fixed version.
+cdrom-allocation-try-harder.patch
Avoid order-4 memory allocations failures when opening CDROM devices.
+atp870u-oops-fix.patch
Fix an init-time oops in this driver.
+tmpfs-01-ENAMETOOLONG.patch
+tmpfs-02-gid-fix.patch
+tmpfs-03-swapoff-truncate-race.patch
+tmpfs-04-getpage-truncate-race.patch
+tmpfs-05-writepage-truncate-race.patch
+tmpfs-06-i_size_write.patch
+tmpfs-07-write-mark_page_accessed.patch
tmpfs fixes.
+quota-locking-fix.patch
Quota deadlock fix.
+export-system_running.patch
+might_sleep-early-bogons.patch
Stomp all the early might_sleep() warnings.
+constant_test_bit-doesnt-like-zwanes-gcc.patch
Workaround a gcc bug.
+slab-leak-detector.patch
+slab-leak-detector-tweaks.patch
A slab debugging tool for finding memory leaks: do
echo "slab-name 0 0 0" > /proc/slabinfo
and the kernel will inspect each live object in that cache and will print
out the code address from which the allocation was performed.
+digi_accelport-oops-fix.patch
Fix an oops in this driver.
+microcode-build-fix.patch
Microcode compile fix
+early-serial-registration-fix.patch
Fix crashes with early printk console registration.
+mtd-warning-fixes.patch
Fix a couple of warnings.
+early_serial_setup-range-check.patch
Another early printk fix.
+elf-verify-interpreter-arch.patch
Additional checks when loading ELF interpreters.
+journal_write_metadata_buffer-kfree-fix.patch
Fix kfree of an incorrect address.
+jbd-leak-fix.patch
Fix ext3 memory leak.
+kmem_freepages-BUG-fix.patch
Fix a BUG which can strike in slab.
+register_cpu-fix.patch
Dunno what this does really. Someone want to send me a decent changelog
for once?
+elv-select.patch
Runtime selectable I/O schedulers.
+elv-init-cleanup.patch
Elevator initialisation cleanups.
+bluetooth-no-procfs-fix.patch
Fix bluetooth compile with CONFIG_PROCFS=n
+gcc-Os.patch
Compile with -Os
+printk-handle-bad-pointers.patch
Make printk kinder when passed nearly-NULL pointers.
+kcapi-build-fix.patch
ISDN compile fix
+drm-module_init-retval-fix.patch
Fix an error code.
+parport_pc-resource-release-fix.patch
Fix an oopsable resource leak in parport_pc.
+3c527-smp-update.patch
Update this driver, make it work on SMP.
+3c527-module-license.patch
It is GPLed.
+no-mca-oops-fix.patch
+mca_find_unused_adapter-oops-fix.patch
Fix a couple of oopses when running CONFIG_MCA kernels on non-MCA hardware.
+register_netdevice-retval-fix.patch
Fix error code propagation.
+ext3-latency-fix.patch
Improved scheduling latency in ext3.
+ipc-msg-race-fix.patch
Fix oopsable race in SVSV IPC message tx/rx.
+iosched-oops-fixes.patch
Fix use-uninitialised in the deadline and AS I/O schedulers.
+pcm_native-deadlock-fix.patch
Fix a deadlock in the sound drivers.
+4g4g-wp-test-fix.patch
Fix a crash when doing the early WP detect with the 4g/4g split enabled.
+O_DIRECT-race-fixes-rework-XFS-fix-fix.patch
EXPORT_SYMBOL() fix.
All 178 patches:
mm.patch
add -mmN to EXTRAVERSION
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning fix
kgdb-buff-too-big.patch
kgdb buffer overflow fix
kgdb-warning-fix.patch
kgdbL warning fix
kgdb-build-fix.patch
kgdb-spinlock-fix.patch
kgdb-fix-debug-info.patch
kgdb: CONFIG_DEBUG_INFO fix
kgdb-cpumask_t.patch
kgdb-x86_64-fixes.patch
x86_64 fixes
kgdb-over-ethernet.patch
kgdb-over-ethernet patch
kgdb-over-ethernet-fixes.patch
kgdb-over-ethernet fixlets
kgdb-CONFIG_NET_POLL_CONTROLLER.patch
kgdb: replace CONFIG_KGDB with CONFIG_NET_RX_POLL in net drivers
kgdb-handle-stopped-NICs.patch
kgdb: handle netif_stopped NICs
eepro100-poll-controller.patch
tlan-poll_controller.patch
tulip-poll_controller.patch
tg3-poll_controller.patch
kgdb: tg3 poll_controller
8139too-poll_controller.patch
8139too poll controller
kgdb-eth-smp-fix.patch
kgdb-over-ethernet: fix SMP
kgdb-eth-reattach.patch
kgdb-skb_reserve-fix.patch
kgdb-over-ethernet: skb_reserve() fix
must-fix.patch
should-fix.patch
vma-split-truncate-race-fix-2.patch
fix split_vma vs. invalidate_mmap_range_list race
devfs-initrd-fix.patch
Fix initrd with devfs enabled
RD1-cdrom_ioctl-B6.patch
RD2-ioctl-B6.patch
RD2-ioctl-B6-fix.patch
RD2-ioctl-B6 fixes
RD3-cdrom_open-B6.patch
RD4-open-B6.patch
RD5-cdrom_release-B6.patch
RD6-release-B6.patch
RD7-presto_journal_close-B6.patch
RD8-f_mapping-B6.patch
RD9-f_mapping2-B6.patch
RD10-i_sem-B6.patch
RD11-f_mapping3-B6.patch
RD12-generic_osync_inode-B6.patch
RD13-bd_acquire-B6.patch
RD14-generic_write_checks-B6.patch
RD15-I_BDEV-B6.patch
RD16-rest-B6.patch
serio-01-renaming.patch
serio: rename serio_[un]register_slave_port to __serio_[un]register_port
serio-02-race-fix.patch
serio: possible race between port removal and kseriod
serio-03-blacklist.patch
Add black list to handler<->device matching
serio-04-synaptics-cleanup.patch
Synaptics: code cleanup
serio-05-reconnect-facility.patch
serio: reconnect facility
serio-06-synaptics-use-reconnect.patch
Synaptics: use serio_reconnect
acpi_off-fix.patch
fix acpi=off
cfq-4.patch
CFQ io scheduler
CFQ fixes
config_spinline.patch
uninline spinlocks for profiling accuracy.
ppc64-bar-0-fix.patch
Allow PCI BARs that start at 0
ppc64-reloc_hide.patch
sym-do-160.patch
make the SYM driver do 160 MB/sec
input-use-after-free-checks.patch
input layer debug checks
fbdev.patch
framebbuffer driver update
fbdev-restore-pci-ids.patch
aic7xxx-parallel-build-fix.patch
fix parallel builds for aic7xxx
ramdisk-cleanup.patch
intel8x0-cleanup.patch
intel8x0 cleanups
uml-update.patch
Update UML to 2.6.0-test5
pdflush-diag.patch
kobject-oops-fixes.patch
fix oopses is kobject parent is removed before child
futex-uninlinings.patch
futex uninlining
zap_page_range-debug.patch
zap_page_range() debug
acpi-thinkpad-fix.patch
APCI fix for thinkpads
scsi-handle-zero-length-requests.patch
scsi: handle zero-length requests
call_usermodehelper-retval-fix-3.patch
Make call_usermodehelper report exit status
asus-L5-fix.patch
Asus L5 framebuffer fix
jffs-use-daemonize.patch
tulip-NAPI-support.patch
tulip NAPI support
tulip-napi-disable.patch
tulip NAPI: disable poll in close
get_user_pages-handle-VM_IO.patch
limit_regions-syncup.patch
ia32 limit_regions update
dynamic-irq_vector-allocation.patch
dynamic irq_vector allocation for ia32
ia32-MSI-support.patch
Updated ia32 MSI Patches
ia32-MSI-support-tweaks.patch
ia32-efi-support.patch
EFI support for ia32
ia32-efi-asm-warning-fix.patch
efi warning fix
ia32-efi-support-mem-equals-fix.patch
CONFIG_ACPI_EFI-defaults-off.patch
ia32-efi-support-warning-fixes.patch
ia32-efi-support-tidy.patch
ia32-efi-other-arch-fix.patch
fix EFI for ppc64, ia64
efi-constant-sizing-fix.patch
efi: warning fixes
support-zillions-of-scsi-disks.patch
support many SCSI disks
SGI-IOC4-IDE-chipset-support.patch
Add support for SGI's IOC4 chipset
sparc32-sched_clock.patch
unmap_vmas-warning-fix.patch
Fix unmap_vmas() compile warning
pcibios_test_irq-fix.patch
Fix pcibios test IRQ handler return
fixmap-in-proc-pid-maps.patch
report user-readable fixmap area in /proc/PID/maps
ajdtimex-vs-gettimeofday.patch
Time precision, adjtime(x) vs. gettimeofday
i82365-sysfs-ordering-fix.patch
Fix init_i82365 sysfs ordering oops
pci_set_power_state-might-sleep.patch
compat_ioctl-cleanup.patch
cleanup of compat_ioctl functions
fix-sqrt.patch
sqrt() fixes
scale-min_free_kbytes.patch
scale the initial value of min_free_kbytes
cdrom-allocation-try-harder.patch
Use __GFP_REPEAT for cdrom buffer
atp870u-oops-fix.patch
atp870u oops fix
sym-2.1.18f.patch
CONFIG_STANDALONE-default-to-n.patch
Make CONFIG_STANDALONE default to N
nosysfs.patch
tmpfs-01-ENAMETOOLONG.patch
tmpfs 1/7 LTP ENAMETOOLONG
tmpfs-02-gid-fix.patch
tmpfs 2/7 LTP S_ISGID dir
tmpfs-03-swapoff-truncate-race.patch
tmpfs 3/7 swapoff/truncate race
tmpfs-04-getpage-truncate-race.patch
tmpfs 4/7 getpage/truncate race
tmpfs-05-writepage-truncate-race.patch
tmpfs 5/7 writepage/truncate race
tmpfs-06-i_size_write.patch
tmpfs 6/7 write i_size_write
tmpfs-07-write-mark_page_accessed.patch
tmpfs 7/7 write mark_page_accessed
quota-locking-fix.patch
Quota locking fix
export-system_running.patch
export system_running to other files
might_sleep-early-bogons.patch
Kill early might_sleep warnings
constant_test_bit-doesnt-like-zwanes-gcc.patch
gcc bug workaround for constant_test_bit()
slab-leak-detector.patch
slab leak detector
slab-leak-detector-tweaks.patch
digi_accelport-oops-fix.patch
digi_acceleport.c has bogus "address of" operator
microcode-build-fix.patch
fix microcode.c for older gcc's
early-serial-registration-fix.patch
serial console registration bugfix
mtd-warning-fixes.patch
Fix mtd printk warnings
early_serial_setup-range-check.patch
early_serial_setup array bounds check
elf-verify-interpreter-arch.patch
fs/binfmt_elf.c:load_elf_binary() doesn't verify interpreter arch
journal_write_metadata_buffer-kfree-fix.patch
JBD kfree() fix
jbd-leak-fix.patch
Fix JBD memory leak
kmem_freepages-BUG-fix.patch
fix low-memory BUG in slab
register_cpu-fix.patch
Subject: [PATCH] fix for register_cpu()
elv-select.patch
disk scheduler selection
elv-init-cleanup.patch
elv_init cleanup
bluetooth-no-procfs-fix.patch
fix bluetooh broken compilation when PROC_FS=n.
gcc-Os.patch
Use -Os for compilation
printk-handle-bad-pointers.patch
make printk more robust with "null" pointers
kcapi-build-fix.patch
kcapi.c CONFIG_MODULES=n build fix
drm-module_init-retval-fix.patch
DRM modprobe retval fix
parport_pc-resource-release-fix.patch
parport_pc not releasing all ioports
3c527-smp-update.patch
SMP support on 3c527 net driver
3c527-module-license.patch
Add 3c527 module license.
no-mca-oops-fix.patch
Fix oops with CONFIG_MCA=y
mca_find_unused_adapter-oops-fix.patch
Fix another CONFIG_MCA=y oops
register_netdevice-retval-fix.patch
register_netdevice return val fix
ext3-latency-fix.patch
ext3 scheduling latency fix
ipc-msg-race-fix.patch
ipc msg race fix
iosched-oops-fixes.patch
io scheduler oops fixes
pcm_native-deadlock-fix.patch
pcm_native locking fix
keyboard-repeat-rate-setting-fix.patch
keyboard repeat rate setting fix
list_del-debug.patch
list_del debug check
print-build-options-on-oops.patch
print a few config options on oops
show_task-free-stack-fix.patch
show_task() fix and cleanup
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
printk-oops-mangle-fix.patch
disentangle printk's whilst oopsing on SMP
4g-2.6.0-test2-mm2-A5.patch
4G/4G split patch
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g/4g usercopy atomicity fix
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g/4g usercopy atomicity fix
4G/4G preempt on vstack
4G/4G: even number of kmap types
4g4g: fix __get_user in slab
4g4g: Remove extra .data.idt section definition
4g/4g linker error (overlapping sections)
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g4g: show_registers() fix
4g/4g usercopy atomicity fix
4g4g: debug flags fix
4g4g: Fix wrong asm-offsets entry
cyclone time fixmap fix
4G/4G preempt on vstack
4G/4G: even number of kmap types
4g4g: fix __get_user in slab
4g4g: Remove extra .data.idt section definition
4g/4g linker error (overlapping sections)
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g4g: show_registers() fix
4g/4g usercopy atomicity fix
4g4g: debug flags fix
4g4g: Fix wrong asm-offsets entry
cyclone time fixmap fix
use direct_copy_{to,from}_user for kernel access in mm/usercopy.c
4G/4G might_sleep warning fix
4g/4g pagetable accounting fix
4g4g-athlon-prefetch-handling-fix.patch
4g4g-wp-test-fix.patch
Fix 4G/4G and WP test lockup
ppc-fixes.patch
make mm4 compile on ppc
aic7xxx_old-oops-fix.patch
O_DIRECT-race-fixes-rollup.patch
DIO fixes forward port and AIO-DIO fix
O_DIRECT race fixes comments
O_DRIECT race fixes fix fix fix
DIO locking rework
O_DIRECT-race-fixes-rework-XFS-fix.patch
O_DIRECT XFS fix
O_DIRECT-race-fixes-rework-XFS-fix-fix.patch
aio-01-retry.patch
AIO: Core retry infrastructure
Fix aio process hang on EINVAL
AIO: flush workqueues before destroying ioctx'es
AIO: hold the context lock across unuse_mm
task task_lock in use_mm()
4g4g-aio-hang-fix.patch
Fix AIO and 4G-4G hang
aio-refcounting-fix.patch
aio ref count in io_submit_one
aio-retry-elevated-refcount.patch
aio: extra ref count during retry
aio-splice-runlist.patch
Splice AIO runlist for fairer handling of multiple io contexts
aio-02-lockpage_wq.patch
AIO: Async page wait
aio-03-fs_read.patch
AIO: Filesystem aio read
aio-04-buffer_wq.patch
AIO: Async buffer wait
lock_buffer_wq fix
aio-05-fs_write.patch
AIO: Filesystem aio write
aio-06-bread_wq.patch
AIO: Async block read
aio-07-ext2getblk_wq.patch
AIO: Async get block for ext2
O_SYNC-speedup-2.patch
speed up O_SYNC writes
O_SYNC-speedup-2-f_mapping-fixes.patch
aio-09-o_sync.patch
aio O_SYNC
AIO: fix a BUG
Unify o_sync changes for aio and regular writes
aio-O_SYNC-fix bits got lost
aio: writev nr_segs fix
More AIO O_SYNC related fixes
aio-09-o_sync-f_mapping-fixes.patch
gang_lookup_next.patch
Change the page gang lookup API
aio-gang_lookup-fix.patch
AIO gang lookup fixes
aio-O_SYNC-short-write-fix.patch
Fix for O_SYNC short writes
aio-12-readahead.patch
AIO: readahead fixes
aio O_DIRECT no readahead
Unified page range readahead for aio and regular reads
aio-12-readahead-f_mapping-fix.patch
aio-readahead-speedup.patch
Readahead issues and AIO read speedup
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 9:05 2.6.0-test8-mm1 Andrew Morton
@ 2003-10-20 11:18 ` Thomas Schlichter
2003-10-20 15:32 ` 2.6.0-test8-mm1 John Cherry
` (2 subsequent siblings)
3 siblings, 0 replies; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-20 11:18 UTC (permalink / raw)
To: linux-kernel, linux-mm; +Cc: Andrew Morton
[-- Attachment #1.1: Type: text/plain, Size: 421 bytes --]
On Monday 20 October 2003 11:05, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test8/2
>.6.0-test8-mm1
~~ snip ~~
> +fix-sqrt.patch
>
> Fix int_sqrt().
I really like this one... ;-)
The problem ist that oom_kill.c assumes that int_sqrt() never returns 0. So we
could get a division by zero there :-(
The attached patch fixes that...
Regards
Thomas
[-- Attachment #1.2: fix-oom_kill.diff --]
[-- Type: text/x-diff, Size: 538 bytes --]
--- linux-2.6.0-test8-mm1/mm/oom_kill.c.orig Mon Oct 20 12:49:58 2003
+++ linux-2.6.0-test8-mm1/mm/oom_kill.c Mon Oct 20 12:52:55 2003
@@ -63,8 +63,8 @@
cpu_time = (p->utime + p->stime) >> (SHIFT_HZ + 3);
run_time = (get_jiffies_64() - p->start_time) >> (SHIFT_HZ + 10);
- points /= int_sqrt(cpu_time);
- points /= int_sqrt(int_sqrt(run_time));
+ points /= cpu_time ? int_sqrt(cpu_time) : 1;
+ points /= run_time ? int_sqrt(int_sqrt(run_time)) : 1;
/*
* Niced processes are most likely less important, so double
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 9:05 2.6.0-test8-mm1 Andrew Morton
2003-10-20 11:18 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-20 15:32 ` John Cherry
2003-10-20 16:11 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 19:21 ` [BUG] 2.6.0-test8-mm1 Ramón Rey Vicente
3 siblings, 0 replies; 26+ messages in thread
From: John Cherry @ 2003-10-20 15:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Full compile stats for mm builds at...
http://developer.osdl.org/cherry/compile/
Kernel version: 2.6.0-test8-mm1
Kernel build:
Making bzImage (defconfig): 0 warnings, 0 errors
Making modules (defconfig): 0 warnings, 0 errors
Making bzImage (allnoconfig): 0 warnings, 0 errors
Making bzImage (allyesconfig): 183 warnings, 0 errors
Making modules (allyesconfig): 13 warnings, 0 errors
Making bzImage (allmodconfig): 3 warnings, 0 errors
Making modules (allmodconfig): 223 warnings, 0 errors
John
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 9:05 2.6.0-test8-mm1 Andrew Morton
2003-10-20 11:18 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 15:32 ` 2.6.0-test8-mm1 John Cherry
@ 2003-10-20 16:11 ` Thomas Schlichter
2003-10-20 21:48 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 19:21 ` [BUG] 2.6.0-test8-mm1 Ramón Rey Vicente
3 siblings, 1 reply; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-20 16:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 3088 bytes --]
On Monday 20 October 2003 11:05, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test8/2
>.6.0-test8-mm1
>
>
> . Included a much updated fbdev patch. Anyone who is using framebuffers,
> please test this.
>
> . Quite a large number of stability fixes.
I've got a problem with NFS!
If the kernel NFS server (nfs-utils 1.0.6) is started I get following Oops:
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0163c36
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU: 0
EIP: 0060:[invalidate_list+37/211] Not tainted VLI
EFLAGS: 00010203
EIP is at invalidate_list+0x25/0xd3
eax: cded1e00 ebx: c13a80c0 ecx: c02e83a0 edx: cf35c000
esi: 00000000 edi: cf35df38 ebp: 00000000 esp: cf35df10
ds: 007b es: 007b ss: 0068
Process exportfs (pid: 1029, threadinfo=cf35c000 task=cefac0c0)
Stack: 00000000 00000000 cded1e00 cf35c000 cf35df38 cffe7c88 c0163d22 c02e8390
cded1e00 cf35df38 cf35df38 cf35df38 cd584980 cded1e00 c02e8640 cffe7c88
c01542f9 cded1e00 0000000e cf35c000 d1a2fde0 c0154bca cded1e00 cded1e00
Call Trace:
[invalidate_inodes+62/162] invalidate_inodes+0x3e/0xa2
[generic_shutdown_super+109/375] generic_shutdown_super+0x6d/0x177
[kill_anon_super+14/56] kill_anon_super+0xe/0x38
[deactivate_super+82/144] deactivate_super+0x52/0x90
[__fput+228/235] __fput+0xe4/0xeb
[sys_nfsservctl+257/267] sys_nfsservctl+0x101/0x10b
[syscall_call+7/11] syscall_call+0x7/0xb
Code: fb ff 5b 5e 5f c3 55 31 ed 57 56 53 50 50 8b 44 24 1c 8b 7c 24 24 c7 04
24
<6>note: exportfs[1029] exited with preempt_count 2
bad: scheduling while atomic!
Call Trace:
[schedule+60/1207] schedule+0x3c/0x4b7
[unmap_vmas+336/471] unmap_vmas+0x150/0x1d7
[exit_mmap+104/339] exit_mmap+0x68/0x153
[mmput+123/184] mmput+0x7b/0xb8
[do_exit+345/836] do_exit+0x159/0x344
[do_divide_error+0/167] do_divide_error+0x0/0xa7
[do_page_fault+784/1105] do_page_fault+0x310/0x451
[update_process_times+41/47] update_process_times+0x29/0x2f
[update_wall_time+11/51] update_wall_time+0xb/0x33
[do_timer+76/193] do_timer+0x4c/0xc1
[do_timer_interrupt+55/224] do_timer_interrupt+0x37/0xe0
[timer_interrupt+40/71] timer_interrupt+0x28/0x47
[rcu_process_callbacks+203/220] rcu_process_callbacks+0xcb/0xdc
[tasklet_action+58/89] tasklet_action+0x3a/0x59
[profile_hook+28/49] profile_hook+0x1c/0x31
[do_page_fault+0/1105] do_page_fault+0x0/0x451
[error_code+47/56] error_code+0x2f/0x38
[invalidate_list+37/211] invalidate_list+0x25/0xd3
[invalidate_inodes+62/162] invalidate_inodes+0x3e/0xa2
[generic_shutdown_super+109/375] generic_shutdown_super+0x6d/0x177
[kill_anon_super+14/56] kill_anon_super+0xe/0x38
[deactivate_super+82/144] deactivate_super+0x52/0x90
[__fput+228/235] __fput+0xe4/0xeb
[sys_nfsservctl+257/267] sys_nfsservctl+0x101/0x10b
[syscall_call+7/11] syscall_call+0x7/0xb
It just worked smoothly with 2.6.0-test7-mm1!
Regards
Thomas
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* [BUG] Re: 2.6.0-test8-mm1
2003-10-20 9:05 2.6.0-test8-mm1 Andrew Morton
` (2 preceding siblings ...)
2003-10-20 16:11 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-20 19:21 ` Ramón Rey Vicente
2003-10-20 20:10 ` Andrew Morton
3 siblings, 1 reply; 26+ messages in thread
From: Ramón Rey Vicente @ 2003-10-20 19:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
Hi.
The same problem with other kernel versions. I get it trying to delete
my local 2.6 svn repository:
EXT3-fs error (device hdb1): ext3_free_blocks: Freeing blocks in system
zones - Block = 512, count = 1
Aborting journal on device hdb1.
ext3_free_blocks: aborting transaction: Journal has aborted in
__ext3_journal_get_undo_access<2>EXT3-fs error (device hdb1) in
ext3_free_blocks: Journal has aborted
ext3_reserve_inode_write: aborting transaction: Journal has aborted in
__ext3_journal_get_write_access<2>EXT3-fs error (device hdb1) in
ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device hdb1) in ext3_truncate: Journal has aborted
ext3_reserve_inode_write: aborting transaction: Journal has aborted in
__ext3_journal_get_write_access<2>EXT3-fs error (device hdb1) in
ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device hdb1) in ext3_orphan_del: Journal has aborted
ext3_reserve_inode_write: aborting transaction: Journal has aborted in
__ext3_journal_get_write_access<2>EXT3-fs error (device hdb1) in
ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device hdb1) in ext3_delete_inode: Journal has aborted
ext3_abort called.
EXT3-fs abort (device hdb1): ext3_journal_start: Detected aborted
journal
Remounting filesystem read-only
--
Ramón Rey Vicente <ramon dot rey at hispalinux dot es>
jabber ID <rreylinux at jabber dot org>
GPG public key ID 0xBEBD71D5 -> http://pgp.escomposlinux.org/
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BUG] Re: 2.6.0-test8-mm1
2003-10-20 19:21 ` [BUG] 2.6.0-test8-mm1 Ramón Rey Vicente
@ 2003-10-20 20:10 ` Andrew Morton
2003-10-20 21:53 ` Ramón Rey Vicente
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Morton @ 2003-10-20 20:10 UTC (permalink / raw)
To: ramon.rey; +Cc: rrey, linux-kernel, linux-mm
Ramon Rey Vicente <rrey@ranty.pantax.net> wrote:
>
> The same problem with other kernel versions. I get it trying to delete
> my local 2.6 svn repository:
>
> EXT3-fs error (device hdb1): ext3_free_blocks: Freeing blocks in system
> zones - Block = 512, count = 1
This is consistent with a corrupted filesystem. Have you forced a fsck
against that partition?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 16:11 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-20 21:48 ` Andrew Morton
2003-10-20 22:01 ` 2.6.0-test8-mm1 Thomas Schlichter
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Morton @ 2003-10-20 21:48 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: linux-kernel, linux-mm
Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>
> On Monday 20 October 2003 11:05, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test8/2
> >.6.0-test8-mm1
> >
> >
> > . Included a much updated fbdev patch. Anyone who is using framebuffers,
> > please test this.
> >
> > . Quite a large number of stability fixes.
>
> I've got a problem with NFS!
> If the kernel NFS server (nfs-utils 1.0.6) is started I get following Oops:
>
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> printing eip:
> c0163c36
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> CPU: 0
> EIP: 0060:[invalidate_list+37/211] Not tainted VLI
A colleague here has discovered that this crash is repeatable, but goes
away when the radeon driver is disabled.
Are you using that driver?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BUG] Re: 2.6.0-test8-mm1
2003-10-20 20:10 ` Andrew Morton
@ 2003-10-20 21:53 ` Ramón Rey Vicente
0 siblings, 0 replies; 26+ messages in thread
From: Ramón Rey Vicente @ 2003-10-20 21:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
El lun, 20-10-2003 a las 22:10, Andrew Morton escribió:
> Ramón Rey Vicente <rrey@ranty.pantax.net> wrote:
> >
> > The same problem with other kernel versions. I get it trying to delete
> > my local 2.6 svn repository:
> >
> > EXT3-fs error (device hdb1): ext3_free_blocks: Freeing blocks in system
> > zones - Block = 512, count = 1
>
> This is consistent with a corrupted filesystem. Have you forced a fsck
> against that partition?
Ups, yes, it seems the filesystem was corrupted/inconsistent but with a
fsck now all is OK. Sorry for this. :-X
--
Ramón Rey Vicente <ramon dot rey at hispalinux dot es>
jabber ID <rreylinux at jabber dot org>
GPG public key ID 0xBEBD71D5 -> http://pgp.escomposlinux.org/
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 21:48 ` 2.6.0-test8-mm1 Andrew Morton
@ 2003-10-20 22:01 ` Thomas Schlichter
2003-10-20 22:17 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21 0:14 ` 2.6.0-test8-mm1 Valdis.Kletnieks
0 siblings, 2 replies; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-20 22:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1.1: Type: text/plain, Size: 589 bytes --]
On Monday 20 October 2003 23:48, Andrew Morton wrote:
> A colleague here has discovered that this crash is repeatable, but goes
> away when the radeon driver is disabled.
>
> Are you using that driver?
No, I'm not... I use the vesafb driver. Do you think disabling this could cure
the Oops?
Btw. a similar Oops at the same place occours when the uhci-hcd module is
unloaded...
The attached patch prevents the kernel from Oopsing, so it seems some inode
lists are corrupted (NULL terminated!). Don't know how the FB driver could be
the reason...
Regards
Thomas
[-- Attachment #1.2: hack-invalidate_list.diff --]
[-- Type: text/x-diff, Size: 670 bytes --]
--- linux-2.6.0-test8-mm1/fs/inode.c.orig Mon Oct 20 20:52:26 2003
+++ linux-2.6.0-test8-mm1/fs/inode.c Mon Oct 20 22:43:52 2003
@@ -292,14 +292,16 @@
int busy = 0, count = 0;
next = head->next;
- for (;;) {
- struct list_head * tmp = next;
+ while (next != head) {
struct inode * inode;
-
- next = next->next;
- if (tmp == head)
+#if 1
+ if (!next) {
+ printk(KERN_ERR "Badness in invalidate_list() !\n");
break;
- inode = list_entry(tmp, struct inode, i_list);
+ }
+#endif
+ inode = list_entry(next, struct inode, i_list);
+ next = next->next;
if (inode->i_sb != sb)
continue;
invalidate_inode_buffers(inode);
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 22:01 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-20 22:17 ` Andrew Morton
2003-10-20 22:30 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 0:14 ` 2.6.0-test8-mm1 Valdis.Kletnieks
1 sibling, 1 reply; 26+ messages in thread
From: Andrew Morton @ 2003-10-20 22:17 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: linux-kernel, linux-mm
Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
>
> On Monday 20 October 2003 23:48, Andrew Morton wrote:
> > A colleague here has discovered that this crash is repeatable, but goes
> > away when the radeon driver is disabled.
> >
> > Are you using that driver?
>
> No, I'm not... I use the vesafb driver. Do you think disabling this could cure
> the Oops?
It might. Could you test it please?
There's nothing in -mm which touches the inode list management code, so a
random scribble or misbehaving driver is likely.
> Btw. a similar Oops at the same place occours when the uhci-hcd module is
> unloaded...
How similar?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 22:17 ` 2.6.0-test8-mm1 Andrew Morton
@ 2003-10-20 22:30 ` Thomas Schlichter
2003-10-21 0:43 ` 2.6.0-test8-mm1 Thomas Schlichter
0 siblings, 1 reply; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-20 22:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
On Tuesday 21 October 2003 00:17, Andrew Mortonwrote:
> Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
> > On Monday 20 October 2003 23:48, Andrew Morton wrote:
> > > A colleague here has discovered that this crash is repeatable, but goes
> > > away when the radeon driver is disabled.
> > >
> > > Are you using that driver?
> >
> > No, I'm not... I use the vesafb driver. Do you think disabling this could
> > cure the Oops?
>
> It might. Could you test it please?
I will, but currently I compile 2.6.0-test8. I want to try if this works...
I also want to try test8-mm1 without the -Os patch, you never know... ;-)
> There's nothing in -mm which touches the inode list management code, so a
> random scribble or misbehaving driver is likely.
Yes, or some part of the kernel compiled false...
(After some problems with erlier gcc's I don't trust my curent 3.3.1 that
much...)
> > Btw. a similar Oops at the same place occours when the uhci-hcd module is
> > unloaded...
>
> How similar?
Very similar (I think it came from deactivate_super(), too), but it seems not
to be logged...
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 22:01 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 22:17 ` 2.6.0-test8-mm1 Andrew Morton
@ 2003-10-21 0:14 ` Valdis.Kletnieks
2003-10-21 0:27 ` 2.6.0-test8-mm1 Andrew Morton
1 sibling, 1 reply; 26+ messages in thread
From: Valdis.Kletnieks @ 2003-10-21 0:14 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: Andrew Morton, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 6389 bytes --]
On Tue, 21 Oct 2003 00:01:01 +0200, Thomas Schlichter said:
> No, I'm not... I use the vesafb driver. Do you think disabling this could cure
> the Oops?
>
> Btw. a similar Oops at the same place occours when the uhci-hcd module is
> unloaded...
>
> The attached patch prevents the kernel from Oopsing, so it seems some inode
> lists are corrupted (NULL terminated!). Don't know how the FB driver could be
> the reason...
I was seeing similar issues where the system would fail to find /sbin/init because
things were dying while still on the initrd, and put Thomas' patch on (although I added a
WARN_ON(1) so we'd get a stack trace in addition to the printk). And then things
got *really* bizarre...
While at work, in its docking station, it would complain while running things
from /linuxrc off the initrd (it complained while firing up SELinux):
SELinux: initialized (dev , type rootfs), uses genfs_contexts
SELinux: initialized (dev , type sysfs), uses genfs_contexts
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c015ec37
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU: 0
EIP: 0060:[<c015ec37>] Not tainted VLI
EFLAGS: 00010246
EIP is at __iget+0x25/0x6e
eax: 00000000 ebx: 00000000 ecx: cfddc088 edx: cfddc080
esi: cfddc080 edi: c1303308 ebp: cff95dbc esp: cff95db8
ds: 007b es: 007b ss: 0068
Process load_policy (pid: 16, threadinfo=cff94000 task=cff97940)
Stack: cfddc080 cff95dcc c015f5a7 cfddc080 cff94000 cff95df0 c01d7377 cfddc080
c1303300 00000000 cffd2bc0 cffd0c40 cffd0c00 cff94000 cff95e10 c01db157
cffd0c00 cffd2bc0 cffd2bc8 cff95e20 c0386170 c04c7ca0 cff95f54 c01e026d
Call Trace:
[<c015f5a7>] igrab+0x20/0x42
[<c01d7377>] superblock_doinit+0x227/0x28b
[<c01db157>] selinux_complete_init+0x96/0xe5
[<c01e026d>] security_load_policy+0xaf/0x25c
[<c013e88e>] handle_mm_fault+0x6d/0x10c
[<c0118a15>] do_page_fault+0x153/0x4a1
[<c01358a2>] __rmqueue+0xc3/0x123
[<c0135935>] rmqueue_bulk+0x33/0x78
[<c0145128>] map_area_pmd+0x50/0x7b
[<c01188c2>] do_page_fault+0x0/0x4a1
[<c0367b93>] error_code+0x2f/0x38
[<c01e915a>] __copy_from_user_ll+0x3c/0x5a
[<c01db6a7>] sel_write_load+0xd0/0xec
[<c0149d2d>] vfs_write+0xae/0xdc
[<c0149dce>] sys_write+0x2c/0x47
[<c0367187>] syscall_call+0x7/0xb
Code: b6 fe ff ff 5d c3 55 89 e5 53 8b 55 08 8b 42 1c 85 c0 74 05 ff 42 1c eb 58
ff 42 1c f6 82 34 01 00 00 0f 75 46 8d 4a 08 8b 59 04 <39> 0b 74 08 0f 0b 94 00
13 5f 38 c0 8b 42 08 39 48 04 74 08 0f
<6>note: load_policy[16] exited with preempt_count 1
bad: scheduling while atomic!
Call Trace:
[<c011a0df>] schedule+0x3c/0x4b7
[<c013d302>] unmap_vmas+0x13c/0x1be
[<c0140832>] exit_mmap+0x60/0x14b
[<c011bcb2>] mmput+0x7d/0xbd
[<c011f33b>] do_exit+0x163/0x351
[<c010c68a>] do_divide_error+0x0/0xad
[<c0118c10>] do_page_fault+0x34e/0x4a1
[<c01240a2>] update_wall_time+0xd/0x37
[<c01243c0>] do_timer+0x4e/0xc6
[<c0110f0f>] timer_interrupt+0x5a/0x118
[<c01208f6>] do_softirq+0x4a/0x91
[<c010d6de>] do_IRQ+0x121/0x138
[<c01188c2>] do_page_fault+0x0/0x4a1
[<c0367b93>] error_code+0x2f/0x38
[<c01d007b>] udf_UTF8toCS0+0xf2/0x178
[<c015ec37>] __iget+0x25/0x6e
[<c015f5a7>] igrab+0x20/0x42
[<c01d7377>] superblock_doinit+0x227/0x28b
[<c01db157>] selinux_complete_init+0x96/0xe5
[<c01e026d>] security_load_policy+0xaf/0x25c
[<c013e88e>] handle_mm_fault+0x6d/0x10c
[<c0118a15>] do_page_fault+0x153/0x4a1
[<c01358a2>] __rmqueue+0xc3/0x123
[<c0135935>] rmqueue_bulk+0x33/0x78
[<c0145128>] map_area_pmd+0x50/0x7b
[<c01188c2>] do_page_fault+0x0/0x4a1
[<c0367b93>] error_code+0x2f/0x38
[<c01e915a>] __copy_from_user_ll+0x3c/0x5a
[<c01db6a7>] sel_write_load+0xd0/0xec
[<c0149d2d>] vfs_write+0xae/0xdc
[<c0149dce>] sys_write+0x2c/0x47
[<c0367187>] syscall_call+0x7/0xb
Badness in invalidate_list() !
Badness in invalidate_list at fs/inode.c:299
Call Trace:
[<c015ee28>] invalidate_list+0x54/0x104
[<c015ef24>] invalidate_inodes+0x4c/0xb9
[<c014ed0c>] generic_shutdown_super+0x7f/0x18d
[<c014f6c2>] kill_anon_super+0x10/0x40
[<c014eb6b>] deactivate_super+0x6f/0xb7
[<c0161c77>] sys_umount+0x5f/0x67
[<c0149d4f>] vfs_write+0xd0/0xdc
[<c0149dce>] sys_write+0x2c/0x47
[<c0161c8c>] sys_oldumount+0xd/0xf
[<c0367187>] syscall_call+0x7/0xb
Badness in invalidate_list() !
Badness in invalidate_list at fs/inode.c:299
Call Trace:
[<c015ee28>] invalidate_list+0x54/0x104
[<c015ef24>] invalidate_inodes+0x4c/0xb9
[<c014ed2f>] generic_shutdown_super+0xa2/0x18d
[<c014f6c2>] kill_anon_super+0x10/0x40
[<c014eb6b>] deactivate_super+0x6f/0xb7
[<c0161c77>] sys_umount+0x5f/0x67
[<c0149d4f>] vfs_write+0xd0/0xdc
[<c0149dce>] sys_write+0x2c/0x47
[<c0161c8c>] sys_oldumount+0xd/0xf
[<c0367187>] syscall_call+0x7/0xb
If trying to boot to 'single' or initlevel 3 or 5, it would then wedge up trying to mount
the local filesystems. I got the above by using init=/bin/bash and doing a dmesg onto
a writeable filesystem I hand-mounted. So obviously things were very ill, and the patch
merely let the system live long enough for me to get a dmesg to run.
Now for the *really* weird part - at the office, the early dmesg has:
Console: switching to colour frame buffer device 160x64
pty: 256 Unix98 ptys configured
I came home, and rebooted the laptop - same kernel, same everything except it
wasn't docked, and it crashed... *partial* oops follows, my pen was dying so
I got what seemed most important:
Console: switching to colour frame buffer device 160x64
Unable to handle kernel NULL pointer dereference at virtual address 00000068
...
EIP is at create_dir+0x1f/0x8f
....
sysfs_create_dir+0x5a/0x70
create_dir+0x15/0x39
kobject_add+0xb2/0x107
cdev_add+0xe/0x4c
tty_register_driver+0x112/0x213
pty_init+0x2db/0x40b
do_initcalls_0x35/0x87
init+0x32/0x10e
init+0x0/0x10e
kernel_thread_helper+0x5/0xb
Never got as far as saying 256 ptys.
(reproducible, from a power-off it did it same way 3 times in a row). So
whatever was giving it indigestion was (a) *very* early on and (b) different
when my laptop was docked and undocked. I'm guessing something ACPI-related,
because when undocked I'm shy an Ethernet controller that's in the dock.
However, the only new patches in -mm1 that seem to go near acpi are the EFI and
MSI patches - and I checked, neither is config'ed into the kernel.
This ring any bells? What you want tested? etc etc....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 0:14 ` 2.6.0-test8-mm1 Valdis.Kletnieks
@ 2003-10-21 0:27 ` Andrew Morton
2003-10-21 0:46 ` 2.6.0-test8-mm1 Valdis.Kletnieks
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Morton @ 2003-10-21 0:27 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: schlicht, linux-kernel, linux-mm
Valdis.Kletnieks@vt.edu wrote:
>
> This ring any bells? What you want tested? etc etc....
Can you try disabling all fbdev stuff in config?
----- End forwarded message -----
--
"The software industry today survives only through an unstated agreement
not to stir things up too much. We must hope this lawsuit [by SCO] isn't
the big stirring spoon." -- Ian Lance Taylor, Linux Journal, June 2003
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-20 22:30 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-21 0:43 ` Thomas Schlichter
0 siblings, 0 replies; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-21 0:43 UTC (permalink / raw)
To: Andrew Morton, Valdis.Kletnieks; +Cc: linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]
On Tuesday 21 October 2003 00:30, I wrote:
> On Tuesday 21 October 2003 00:17, Andrew Mortonwrote:
> > Thomas Schlichter <schlicht@uni-mannheim.de> wrote:
> > > On Monday 20 October 2003 23:48, Andrew Morton wrote:
> > > > A colleague here has discovered that this crash is repeatable, but
> > > > goes away when the radeon driver is disabled.
> > > >
> > > > Are you using that driver?
> > >
> > > No, I'm not... I use the vesafb driver. Do you think disabling this
> > > could cure the Oops?
> >
> > It might. Could you test it please?
>
> I will, but currently I compile 2.6.0-test8. I want to try if this works...
> I also want to try test8-mm1 without the -Os patch, you never know... ;-)
OK, 2.6.0-test8 worked, 2.6.0-test8-mm1 without any FB support, too!!
So I didn't test reverting the -Os patch...
> > There's nothing in -mm which touches the inode list management code, so a
> > random scribble or misbehaving driver is likely.
>
> Yes, or some part of the kernel compiled false...
> (After some problems with erlier gcc's I don't trust my curent 3.3.1 that
> much...)
It seems my gcc 3.3.1 works the way it should... ;-)
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 0:27 ` 2.6.0-test8-mm1 Andrew Morton
@ 2003-10-21 0:46 ` Valdis.Kletnieks
2003-10-21 1:56 ` 2.6.0-test8-mm1 Andrew Morton
0 siblings, 1 reply; 26+ messages in thread
From: Valdis.Kletnieks @ 2003-10-21 0:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: schlicht, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
On Mon, 20 Oct 2003 17:27:32 PDT, Andrew Morton said:
> Valdis.Kletnieks@vt.edu wrote:
> >
> > This ring any bells? What you want tested? etc etc....
>
> Can you try disabling all fbdev stuff in config?
OK.. That booted just fine, didn't hang in pty_init, didn't hit the
WARN_ON added to fs_inoce.c.
So we have:
works:
# CONFIG_FB is not set
Doesn't work:
CONFIG_FB=y
CONFIG_FB_VESA=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
I've not had a chance to play binary search on those options yet.. Graphics
card is an NVidia GeForce 440Go, and was previous working just fine with
framebuffer over on vc1-6 and NVidia's driver on an XFree86 on vc7. (OK, I
admit I didn't stress test the framebuffer side much past "penguins and
scroiled text"...)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 0:46 ` 2.6.0-test8-mm1 Valdis.Kletnieks
@ 2003-10-21 1:56 ` Andrew Morton
2003-10-21 2:54 ` 2.6.0-test8-mm1 Valdis.Kletnieks
` (3 more replies)
0 siblings, 4 replies; 26+ messages in thread
From: Andrew Morton @ 2003-10-21 1:56 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: schlicht, linux-kernel, linux-mm, James Simmons
Valdis.Kletnieks@vt.edu wrote:
>
> On Mon, 20 Oct 2003 17:27:32 PDT, Andrew Morton said:
> > Valdis.Kletnieks@vt.edu wrote:
> > >
> > > This ring any bells? What you want tested? etc etc....
> >
> > Can you try disabling all fbdev stuff in config?
>
> OK.. That booted just fine, didn't hang in pty_init, didn't hit the
> WARN_ON added to fs_inoce.c.
>
> So we have:
>
> works:
> # CONFIG_FB is not set
>
> Doesn't work:
> CONFIG_FB=y
> CONFIG_FB_VESA=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_PCI_CONSOLE=y
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
> CONFIG_LOGO=y
> CONFIG_LOGO_LINUX_MONO=y
> CONFIG_LOGO_LINUX_VGA16=y
> CONFIG_LOGO_LINUX_CLUT224=y
>
> I've not had a chance to play binary search on those options yet.. Graphics
> card is an NVidia GeForce 440Go, and was previous working just fine with
> framebuffer over on vc1-6 and NVidia's driver on an XFree86 on vc7. (OK, I
> admit I didn't stress test the framebuffer side much past "penguins and
> scroiled text"...)
>
Thanks. You're now the third person (schlicht@uni-mannheim.de,
jeremy@goop.org) who reports that the weird oopses (usually in
invalidate_list()) go away when the fbdev code is disabled.
You're using vesafb on nvidia, Jeremy is using vesafb on either radeon or
nvidia, not sure about Thomas.
Has anyone tried CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC, see if that
turns anything up?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 1:56 ` 2.6.0-test8-mm1 Andrew Morton
@ 2003-10-21 2:54 ` Valdis.Kletnieks
2003-10-21 3:49 ` 2.6.0-test8-mm1 Jeremy Fitzhardinge
` (2 subsequent siblings)
3 siblings, 0 replies; 26+ messages in thread
From: Valdis.Kletnieks @ 2003-10-21 2:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: schlicht, linux-kernel, linux-mm, James Simmons
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
On Mon, 20 Oct 2003 18:56:13 PDT, Andrew Morton said:
> Has anyone tried CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC, see if that
> turns anything up?
Well, I built two test kernels, which hopefully tell us something.. ;)
1) I did a 'patch -R' and backed out the two fbdev patches - and a -test8-mm1
with them removed boots and runs fine with a framebuffer console.
2) Kernel *with* fbdev patch, but no 'vga=794' parm at boot works OK as well. So
it can be in the kernel and not used, and works OK.
3) With fbdev patch and DEBUG_SLAB and DEBUG_PAGEALLOC, it got weird.
It booted semi-OK (sort of - some funkyness mounting filesystems) but suffered some
truly horrid bit-droppings as stuff scrolled. Basically, most character cells that were
"blank" had light grey in the top 2 pixes of the cell, and many non-blanks that didn't
have ascenders had them as well. Not all the pixels were the same grey, either..
Looks like the debugging changed the layout in memory enough for things to almost
work (so less stuff was getting overlaid and we lived longer?), but didn't catch any
memory corruption (or at least neither console nor 'dmesg' saw any messages).
I'm wondering if it's stomping on some memory because the vga=794
parameter tells it to use 1280x1024x16, when the underlying card is really 1600x1200x32?
(Yes, I know this means the vesa is using a small corner of the card's memory)...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 1:56 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21 2:54 ` 2.6.0-test8-mm1 Valdis.Kletnieks
@ 2003-10-21 3:49 ` Jeremy Fitzhardinge
2003-10-21 8:39 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 17:47 ` 2.6.0-test8-mm1 James Simmons
3 siblings, 0 replies; 26+ messages in thread
From: Jeremy Fitzhardinge @ 2003-10-21 3:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Valdis.Kletnieks, schlicht, Linux Kernel List, linux-mm, James Simmons
On Mon, 2003-10-20 at 18:56, Andrew Morton wrote:
> You're using vesafb on nvidia, Jeremy is using vesafb on either radeon or
I get it with radeon and vesafb - I haven't tried on my nvidia system.
J
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 1:56 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21 2:54 ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21 3:49 ` 2.6.0-test8-mm1 Jeremy Fitzhardinge
@ 2003-10-21 8:39 ` Thomas Schlichter
2003-10-21 17:47 ` 2.6.0-test8-mm1 James Simmons
3 siblings, 0 replies; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-21 8:39 UTC (permalink / raw)
To: Andrew Morton, Valdis.Kletnieks; +Cc: linux-kernel, linux-mm, James Simmons
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
On Tuesday 21 October 2003 03:56, Andrew Morton wrote:
> Valdis.Kletnieks@vt.edu wrote:
> > I've not had a chance to play binary search on those options yet..
> > Graphics card is an NVidia GeForce 440Go, and was previous working just
> > fine with framebuffer over on vc1-6 and NVidia's driver on an XFree86 on
> > vc7. (OK, I admit I didn't stress test the framebuffer side much past
> > "penguins and scroiled text"...)
>
> Thanks. You're now the third person (schlicht@uni-mannheim.de,
> jeremy@goop.org) who reports that the weird oopses (usually in
> invalidate_list()) go away when the fbdev code is disabled.
>
> You're using vesafb on nvidia, Jeremy is using vesafb on either radeon or
> nvidia, not sure about Thomas.
Sorry for not mentioning it!
I use(d) vesafb on a Nvidia GeForce 2 MX 440.
> Has anyone tried CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC, see if that
> turns anything up?
I didn't yet, but I'll try now...
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 1:56 ` 2.6.0-test8-mm1 Andrew Morton
` (2 preceding siblings ...)
2003-10-21 8:39 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-21 17:47 ` James Simmons
2003-10-21 20:23 ` 2.6.0-test8-mm1 Helge Hafting
3 siblings, 1 reply; 26+ messages in thread
From: James Simmons @ 2003-10-21 17:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: Valdis.Kletnieks, schlicht, linux-kernel, linux-mm
Okay I see people are having alot of problems in the -mm tree. I don't
have any problems but I'm working against Linus tree. Could people try the
patch against 2.6.0-test8 and tell me if they still have the same results.
I have a new patch here:
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 17:47 ` 2.6.0-test8-mm1 James Simmons
@ 2003-10-21 20:23 ` Helge Hafting
2003-10-21 20:36 ` 2.6.0-test8-mm1 Thomas Schlichter
0 siblings, 1 reply; 26+ messages in thread
From: Helge Hafting @ 2003-10-21 20:23 UTC (permalink / raw)
To: James Simmons
Cc: Andrew Morton, Valdis.Kletnieks, schlicht, linux-kernel, linux-mm
On Tue, Oct 21, 2003 at 06:47:41PM +0100, James Simmons wrote:
>
> Okay I see people are having alot of problems in the -mm tree. I don't
> have any problems but I'm working against Linus tree. Could people try the
> patch against 2.6.0-test8 and tell me if they still have the same results.
This patch was fine. 2.6.0-test8 with this patch booted and
looked no different from plain 2.6.0-test8. I am using it for
writing this. The problems must be in mm1 somehow.
Helge Hafting
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 20:23 ` 2.6.0-test8-mm1 Helge Hafting
@ 2003-10-21 20:36 ` Thomas Schlichter
2003-10-21 20:42 ` 2.6.0-test8-mm1 James Simmons
0 siblings, 1 reply; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-21 20:36 UTC (permalink / raw)
To: Helge Hafting, James Simmons
Cc: Andrew Morton, Valdis.Kletnieks, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On Tuesday 21 October 2003 22:23, Helge Hafting wrote:
> On Tue, Oct 21, 2003 at 06:47:41PM +0100, James Simmons wrote:
> > Okay I see people are having alot of problems in the -mm tree. I don't
> > have any problems but I'm working against Linus tree. Could people try
> > the patch against 2.6.0-test8 and tell me if they still have the same
> > results.
>
> This patch was fine. 2.6.0-test8 with this patch booted and
> looked no different from plain 2.6.0-test8. I am using it for
> writing this. The problems must be in mm1 somehow.
>
> Helge Hafting
Well here I've got same problems for -test8 + fbdev-patch as with -test8-mm1.
I've compiled the kernel with most DEBUG_* options enabled (all but
DEBUG_INFO and KGDB) and see the same cursor and image corruption as with
-mm1 and the same options enabled.
Should I try compiling this kernel without the DEBUG_* options and watch if I
get the invalidate_list Oops again?
I use vesafb on a Nvidia GeForce 2 MX 440 with 64MB Video-RAM.
Regards
Thomas
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 20:36 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-21 20:42 ` James Simmons
2003-10-21 22:53 ` 2.6.0-test8-mm1 Thomas Schlichter
0 siblings, 1 reply; 26+ messages in thread
From: James Simmons @ 2003-10-21 20:42 UTC (permalink / raw)
To: Thomas Schlichter
Cc: Helge Hafting, Andrew Morton, Valdis.Kletnieks, linux-kernel, linux-mm
> > This patch was fine. 2.6.0-test8 with this patch booted and
> > looked no different from plain 2.6.0-test8. I am using it for
> > writing this. The problems must be in mm1 somehow.
> >
> > Helge Hafting
Yeah!!!
> Well here I've got same problems for -test8 + fbdev-patch as with -test8-mm1.
> I've compiled the kernel with most DEBUG_* options enabled (all but
> DEBUG_INFO and KGDB) and see the same cursor and image corruption as with
> -mm1 and the same options enabled.
>
> Should I try compiling this kernel without the DEBUG_* options and watch if I
> get the invalidate_list Oops again?
Yes. I'm using vesafb and I have no problems. I liek to see what the
problem really is.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 20:42 ` 2.6.0-test8-mm1 James Simmons
@ 2003-10-21 22:53 ` Thomas Schlichter
2003-10-21 23:27 ` 2.6.0-test8-mm1 Robert Love
0 siblings, 1 reply; 26+ messages in thread
From: Thomas Schlichter @ 2003-10-21 22:53 UTC (permalink / raw)
To: James Simmons
Cc: Helge Hafting, Andrew Morton, Valdis.Kletnieks, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On Tuesday 21 October 2003 22:42, James Simmons wrote:
> > > This patch was fine. 2.6.0-test8 with this patch booted and
> > > looked no different from plain 2.6.0-test8. I am using it for
> > > writing this. The problems must be in mm1 somehow.
> > >
> > > Helge Hafting
>
> Yeah!!!
>
> > Well here I've got same problems for -test8 + fbdev-patch as with
> > -test8-mm1. I've compiled the kernel with most DEBUG_* options enabled
> > (all but DEBUG_INFO and KGDB) and see the same cursor and image
> > corruption as with -mm1 and the same options enabled.
> >
> > Should I try compiling this kernel without the DEBUG_* options and watch
> > if I get the invalidate_list Oops again?
>
> Yes. I'm using vesafb and I have no problems. I liek to see what the
> problem really is.
OK, without any of the DEBUG_* options enabled the kernel SEEMS to work with
no problems. But I don't know how I can assure there actually is no memory
corruption...
For me the big question stays why enabling the DEBUG_* options results in a
corrupt cursor and the false dots on the top of each row... (with both
kernels)
And, of course, why enabling vesafb in -mm1 leads to memory corruption. (as
Vladis already mentioned, the same binary works if vesafb is not enabled via
the 'vga=xxx' boot option).
Regards
Thomas
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 22:53 ` 2.6.0-test8-mm1 Thomas Schlichter
@ 2003-10-21 23:27 ` Robert Love
2003-10-22 2:46 ` 2.6.0-test8-mm1 Valdis.Kletnieks
0 siblings, 1 reply; 26+ messages in thread
From: Robert Love @ 2003-10-21 23:27 UTC (permalink / raw)
To: Thomas Schlichter
Cc: James Simmons, Helge Hafting, Andrew Morton, Valdis.Kletnieks,
linux-kernel, linux-mm
On Tue, 2003-10-21 at 18:53, Thomas Schlichter wrote:
> For me the big question stays why enabling the DEBUG_* options results in a
> corrupt cursor and the false dots on the top of each row... (with both
> kernels)
Almost certainly due to CONFIG_DEBUG_SLAB or CONFIG_DEBUG_PAGEALLOC,
which debug memory allocations and frees.
Code that commits the usual memory bugs (use-after-free, etc.) will
quickly die with these set, whereas without them the bug might never
manifest.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: 2.6.0-test8-mm1
2003-10-21 23:27 ` 2.6.0-test8-mm1 Robert Love
@ 2003-10-22 2:46 ` Valdis.Kletnieks
0 siblings, 0 replies; 26+ messages in thread
From: Valdis.Kletnieks @ 2003-10-22 2:46 UTC (permalink / raw)
To: Robert Love
Cc: Thomas Schlichter, James Simmons, Helge Hafting, Andrew Morton,
linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]
On Tue, 21 Oct 2003 19:27:25 EDT, Robert Love said:
> On Tue, 2003-10-21 at 18:53, Thomas Schlichter wrote:
>
> > For me the big question stays why enabling the DEBUG_* options results in a
> > corrupt cursor and the false dots on the top of each row... (with both
> > kernels)
>
> Almost certainly due to CONFIG_DEBUG_SLAB or CONFIG_DEBUG_PAGEALLOC,
> which debug memory allocations and frees.
>
> Code that commits the usual memory bugs (use-after-free, etc.) will
> quickly die with these set, whereas without them the bug might never
> manifest.
Right. DEBUG_SLAB and DEBUG_PAGEALLOC will change where things end up in
memory. The part that *I* was surprised at was that turning them on did *NOT*
make the code quickly die as expected - but it *did* corrupt the on-screen
image. That's telling me that the DEBUG stuff is setting canaries that end up
in memory locations that the fbdev code thinks are destined for the display
pixels. (And conversely, that when you build without those two debug options,
that the fbdev code is parking those now not visibly corrupted pixels on top of
somebody's pointer chains and that's where the memory corruption is coming
from.
Or I could just be full of it as usual.. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2003-10-22 2:46 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-20 9:05 2.6.0-test8-mm1 Andrew Morton
2003-10-20 11:18 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 15:32 ` 2.6.0-test8-mm1 John Cherry
2003-10-20 16:11 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 21:48 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 22:01 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 22:17 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 22:30 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 0:43 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 0:14 ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21 0:27 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21 0:46 ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21 1:56 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21 2:54 ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21 3:49 ` 2.6.0-test8-mm1 Jeremy Fitzhardinge
2003-10-21 8:39 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 17:47 ` 2.6.0-test8-mm1 James Simmons
2003-10-21 20:23 ` 2.6.0-test8-mm1 Helge Hafting
2003-10-21 20:36 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 20:42 ` 2.6.0-test8-mm1 James Simmons
2003-10-21 22:53 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 23:27 ` 2.6.0-test8-mm1 Robert Love
2003-10-22 2:46 ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-20 19:21 ` [BUG] 2.6.0-test8-mm1 Ramón Rey Vicente
2003-10-20 20:10 ` Andrew Morton
2003-10-20 21:53 ` Ramón Rey Vicente
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox