linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* 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