2.5.67-mm1

2.5.67-mm1

[Andrew Morton]

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.67-mm1.gz

  Will appear sometime at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.67/2.5.67-mm1/


. sparc64 is now using gcc-3.x, so there is a patch here to make gcc-2.95
  the minimum required version.

. A few rmap-speedup patches reduce the rmap CPU tax by 25-30% on a P4

. Various other cleaups, speedups and fixups.




Changes since 2.5.66-mm3:


 linus.patch

 Latest from Linus

-monotonic-clock-hangcheck.patch
-warning-fixes-1.patch
-bio_kmap-fix.patch
-file-limit-checking-cleanup.patch
-tmpfs-1-use-generic_write_checks.patch
-tmpfs-2-remove-shmem_readpage.patch
-tmpfs-3-user-generic_file_llseek.patch
-tmpfs-4-use-mark_page_accessed.patch
-tmpfs-4-use-cond_resched.patch
-tmpfs-6-percentile-sizing.patch
-stat_t-larger-dev_t.patch
-misc.patch
-smp_call_function-barrier.patch
-adaptec-del_timer_sync.patch
-3c59x-980-support.patch
-fadvise-flush-data.patch
-console-scrollback.patch
-devfs-rescan_partitions-fix.patch
-umsdos-fixes.patch
-exp_parent-locking-fix.patch
-real_lookup-race-fix.patch
-remove-dparent_lock.patch
-jbd_expect.patch
-jbd-assert-io-failure-fix.patch
-ext3_mark_inode_dirty-speedup.patch
-ext3_mark_inode_dirty-less-calls.patch
-ext3-handle-cache.patch
-jbd-handle-journal-io-errors.patch

 Merged

+kgdb-ga-up-warning-fix.patch

 Fix a kgb warning

+gcc-295-required.patch

 Require gcc-2.95 or higher.

+dmfe-kfree_skb-fix.patch

 Fix a goes-BUG bug in dmfe.c.

+ppc64-update.patch

 Stuff from Anton.

+remove-nr_reverse_maps.patch

 Remove /proc/meminfo:ReverseMaps.   It is measurably expensive.

+rmap-search-speedup.patch

 Warm up the rmap code.

+rmap-tweaks.patch

 Ditto

+page-lock-is-spin_lock.patch

 Make mapping->page_lock a spinlock.  It is faster than an rwlock.

+file_lock-spinlock.patch

 Ditto file->file_lock

+paride-remove-blk_queue_empty.patch

 Leftovers from the blk_queue_empty() removal

+as-use-queue_empty.patch

 Anticipatory scheduler rework

-fremap-all-mappings.patch

 Accidentally dropped

-objrmap-2.5.62-5.patch
-hugh-04-page_convert_anon-ENOMEM.patch
-hugh-05-page_convert_anon-unlocking.patch
-hugh-06-wrap-below-vm_start.patch
-hugh-07-objrmap-page_table_lock.patch
-hugh-08-rmap-comments.patch
-hugh-11-fix-unuse_pmd-fixme.patch
-tmpfs-blk_congestion_wait-fix.patch
-page_convert_anon-locking-fix.patch
-objrmap-sort-vma-list.patch
-stale-inode-fix.patch

 All rolled together, into objrmap.patch

+objrmap.patch

 Partial objrmap.

+32bit-dev_t-nfs-export-fix.patch

 Make NFS work better with 32-bit dev_t

+jbd-warning-fix.patch

 Fox a compile warning

+earlier-keyboard-init.patch

 Init the keyboard earlier, so sysrq is available

+epoll-cross-thread-deletion-fix.patch

 epoll fix

+mbcache-missing-brelse.patch

 Extended attribute leak fix

+nfs-read-corruption-fix.patch

 NFS read fix from Trond

+MS_ASYNC-more-async.patch

 Make msync(MS_ASYNC) just dirty the pages, and not start any I/O

+tasklist_lock-docco-fix.patch

 Commentary corrections

+dynamic-hd_struct-allocation.patch
+dynamic-hd_struct-allocation-fixes.patch

 Dynamically allocate struct hd_struct, to save RAM with 4000 disks.

+remove-flush_page_to_ram.patch

 Remove flush_page_to_ram()

+nfs-resource-management.patch

 Make NFS play more nicely with the VM/VFS memory balancing.

+compound-page-fix.patch

 Fix futex-in-hugepage, perhaps.

+xfs-dev_t-warning-fix.patch

 Compile warning fix for 32-bit dev-t

+fadvise-file-leak.patch

 fadvise() can leak a file ref



All 97 patches:

linus.patch

mm.patch
  add -mmN to EXTRAVERSION

kgdb-ga.patch
  kgdb stub for ia32 (George Anzinger's one)

kgdb-ga-warning-fix.patch
  -mm traps.c warning

kgdb-ga-up-warning-fix.patch

wait_on_buffer-debug-fix.patch
  fix wait_on_buffer() debug code

tty-shutdown-race-fix.patch
  fix tty shutdown race

ppa-null-pointer-fix.patch

gcc-295-required.patch
  Enforce gcc-2.95 as the minimum compiler requirement

dmfe-kfree_skb-fix.patch
  dmfe: don't free skb with local interrupts disabled

config_spinline.patch
  uninline spinlocks for profiling accuracy.

ppc64-reloc_hide.patch

ppc64-pci-patch.patch
  Subject: pci patch

ppc64-aio-32bit-emulation.patch
  32/64bit emulation for aio

ppc64-scruffiness.patch
  Fix some PPC64 compile warnings

ppc64-update.patch
  ppc64 update

sym-do-160.patch
  make the SYM driver do 160 MB/sec

config-PAGE_OFFSET.patch
  Configurable kenrel/user memory split

ptrace-flush.patch
  cache flushing in the ptrace code

buffer-debug.patch
  buffer.c debugging

warn-null-wakeup.patch

ext3-truncate-ordered-pages.patch
  ext3: explicitly free truncated pages

reiserfs_file_write-5.patch

rcu-stats.patch
  RCU statistics reporting

ext3-journalled-data-assertion-fix.patch
  Remove incorrect assertion from ext3

nfs-speedup.patch

nfs-oom-fix.patch
  nfs oom fix

sk-allocation.patch
  Subject: Re: nfs oom

nfs-more-oom-fix.patch

rpciod-atomic-allocations.patch
  Make rcpiod use atomic allocations

linux-isp.patch

isp-update-1.patch

remove-nr_reverse_maps.patch
  remove nr_reverse_maps VM accounting

rmap-search-speedup.patch
  speed up rmap searching

rmap-tweaks.patch
  misc rmap speedups

page-lock-is-spin_lock.patch
  Replace the radix-tree rwlock with a spinlock

file_lock-spinlock.patch
  convert file_lock to a spinlock

kblockd.patch
  Create `kblockd' workqueue

paride-remove-blk_queue_empty.patch
  fix up the paride driver for blk_queue_empty() removal

as-iosched.patch
  anticipatory I/O scheduler

as-np-reads-1.patch
  AS: read-vs-read fixes

as-np-reads-2.patch
  AS: more read-vs-read fixes

as-predict-data-direction.patch
  as: predict direction of next IO

as-remove-frontmerge.patch
  AS: remove frontmerge tunable

as-misc-cleanups.patch
  AS: misc cleanups

as-minor-tweaks.patch
  AS: tuning and tweaks

as-remove-stats.patch
  AS: remove statistics

as-locking-fix.patch
  AS: Fix minor race

as-disable-thinktime.patch

as-use-queue_empty.patch
  AS: Use the queue_empty API

cfq-2.patch
  CFQ scheduler, #2

unplug-use-kblockd.patch
  Use kblockd for running request queues

objrmap.patch
  object-based rmap

32bit-dev_t-nfs-export-fix.patch
  Fix nfsd exports with big dev_t

sched-2.5.64-D3.patch
  sched-2.5.64-D3, more interactivity changes

scheduler-tunables.patch
  scheduler tunables

show_task-free-stack-fix.patch
  show_task() fix and cleanup

jbd-warning-fix.patch
  JBD pasting warning fix

yellowfin-set_bit-fix.patch
  yellowfin driver set_bit fix

htree-nfs-fix.patch
  Fix ext3 htree / NFS compatibility problems

task_prio-fix.patch
  simple task_prio() fix

earlier-keyboard-init.patch
  earlier keyboard init

panic-on-oops.patch
  Allow panics and reboots at oops time.

epoll-cross-thread-deletion-fix.patch
  epoll cross-thread deletion fix

mbcache-missing-brelse.patch
  Missing brelse() in ext2/ext3 extended attribute code

nfs-read-corruption-fix.patch
  NFS read corruption fix

MS_ASYNC-more-async.patch
  Make msync(MS_ASYNC) no longer start the I/O

tasklist_lock-docco-fix.patch
  task_lock commentary fixes

posix-timer-hang-fix.patch
  posix_timer hang fix

dynamic-hd_struct-allocation.patch
  Allocate hd_structs dynamically

dynamic-hd_struct-allocation-fixes.patch
  dynamic allocation of hd_structs

remove-flush_page_to_ram.patch
  Remove flush_page_to_ram()

slab_store_user-large-objects.patch
  slab debug: perform redzoning against larger objects

nfs-resource-management.patch
  Subject: Resource management for NFS...

compound-page-fix.patch

htree-nfs-fix-2.patch
  htree nfs fix

put_task_struct-debug.patch

percpu_counter.patch
  percpu_counters: approximate but scalabel counters

blockgroup_lock.patch
  blockgroup_lock: hashed spinlocks for ext2 and ext3 blockgroup locking

ext2-no-lock_super-ng.patch

ext2-ialloc-no-lock_super-ng.patch

dev_t-32-bit.patch
  [for playing only] change type of dev_t

dev_t-remove-B_FREE.patch
  dev_t: eliminate B_FREE

sg-dev_t-fix.patch
  32-bit dev_t fix for sg

xfs-dev_t-warning-fix.patch
  xfs dev_t printk warning fix

init-sections-in-kallsyms.patch
  Put all functions in kallsyms

aggregated-disk-stats.patch
  Aggregated disk statistics

fadvise-file-leak.patch
  fix file leak in fadvise()

oops-dump-preceding-code.patch
  i386 oops output: dump preceding code

usb-disconnect-crash-fix.patch
  Subject: Re: [linux-usb-devel] timer hang with current 2.5 BK

conntrack-use-after-free-fix.patch
  fix use-after-free in ip_conntrack

ext3-no-bkl.patch

journal_dirty_metadata-speedup.patch

journal_get_write_access-speedup.patch

ext3-concurrent-block-inode-allocation.patch
  Subject: [PATCH] concurrent block/inode allocation for EXT3

ext3-concurrent-block-allocation-fix-1.patch

ext3-concurrent-block-allocation-hashed.patch
  Subject: Re: [PATCH] concurrent block/inode allocation for EXT3

Re: 2.5.67-mm1

[William Lee Irwin III]

On Tue, Apr 08, 2003 at 04:22:39AM -0700, Andrew Morton wrote:
> +remove-nr_reverse_maps.patch
>  Remove /proc/meminfo:ReverseMaps.   It is measurably expensive.

This is fine. The changelog comment doesn't look right though. It says
it's inferrable from slabinfo; it's meant to measure the number of
reverse mappings performed, or aggregate faulted-in virtualspace on the
system, or the number of PTE's pointing at userspace data.

The internal fragmentation within slabs is a separate notion.
pte_chains carry more than a single pointer, so the net utilization and
internal fragmentation of the things allocated can be computed from
nr_reverse_maps/(#pte_chains * NR_PTE), and is very different from the
internal fragmentation of slabs (there is no relationship whatsoever).

This stuff has been disturbed on several occasions, and effectively
lost whatever meaning it had left after PG_direct anyway, regardless
of who changed it to mean what, as the accounting was never adjusted to
remove PG_direct reverse mappings (the actions, not any kind of space)
from the count due to not being able to identify the notion that would
be measured by it. nr_shared_reverse_maps? It's dead, kill it.

-- wli

Re: 2.5.67-mm1

[Ed Tomlinson]

Hi,

This does not boot here.  I loop with the following message. 

i8042.c: Can't get irq 12 for AUX, unregistering the port.

irq 12 is used (correctly) by my 20267 ide card.  My mouse is
usb and AUX is not used.

Ideas?

Ed Tomlinson

Re: 2.5.67-mm1

[William Lee Irwin III]

On Tue, Apr 08, 2003 at 04:22:39AM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.67-mm1.gz
>   Will appear sometime at
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.67/2.5.67-mm1/
> . sparc64 is now using gcc-3.x, so there is a patch here to make gcc-2.95
>   the minimum required version.
> . A few rmap-speedup patches reduce the rmap CPU tax by 25-30% on a P4
> . Various other cleaups, speedups and fixups.

task_vsize() mysteriously appeared on my profiles. This should remove
it from them by using the already in-use elsewhere for rlimit checks
mm->total_vm for the benefit of O(1) cachelines touched.


--- virgin-2.5.67/fs/proc/task_mmu.c	Wed Jan 15 08:46:04 2003
+++ wli-2.5.67-1/fs/proc/task_mmu.c	Tue Apr  8 06:57:27 2003
@@ -45,13 +45,7 @@
 
 unsigned long task_vsize(struct mm_struct *mm)
 {
-	struct vm_area_struct *vma;
-	unsigned long vsize = 0;
-
-	for (vma = mm->mmap; vma; vma = vma->vm_next)
-		vsize += vma->vm_end - vma->vm_start;
-
-	return vsize;
+	return PAGE_SIZE * mm->total_vm;
 }
 
 int task_statm(struct mm_struct *mm, int *shared, int *text,

Re: 2.5.67-mm1

[Randy.Dunlap]

On Tue, 8 Apr 2003 09:17:15 -0400 Ed Tomlinson <tomlins@cam.org> wrote:

| Hi,
| 
| This does not boot here.  I loop with the following message. 
| 
| i8042.c: Can't get irq 12 for AUX, unregistering the port.
| 
| irq 12 is used (correctly) by my 20267 ide card.  My mouse is
| usb and AUX is not used.
| 
| Ideas?

I guess that's due to my early kbd init patch.
So why do you have i8042 configured into your kernel?

The loop doesn't terminate?  Do you get the same message (above)
over and over again?

--
~Randy

Re: 2.5.67-mm1

[Ed Tomlinson]

On April 8, 2003 11:31 am, Randy.Dunlap wrote:
> On Tue, 8 Apr 2003 09:17:15 -0400 Ed Tomlinson <tomlins@cam.org> wrote:
> | Hi,
> |
> | This does not boot here.  I loop with the following message.
> |
> | i8042.c: Can't get irq 12 for AUX, unregistering the port.
> |
> | irq 12 is used (correctly) by my 20267 ide card.  My mouse is
> | usb and AUX is not used.
> |
> | Ideas?
>
> I guess that's due to my early kbd init patch.
> So why do you have i8042 configured into your kernel?

One, What exactly configures it?  Two my keyboard is not usb, just
my mouse.

> The loop doesn't terminate?  Do you get the same message (above)
> over and over again?

Yes, until I trigger a reboot (SysReq+B).

Ed

Re: 2.5.67-mm1

[Andrew Morton]

Ed Tomlinson <tomlins@cam.org> wrote:
>
> Hi,
> 
> This does not boot here.  I loop with the following message. 
> 
> i8042.c: Can't get irq 12 for AUX, unregistering the port.
> 
> irq 12 is used (correctly) by my 20267 ide card.  My mouse is
> usb and AUX is not used.
> 

Does the below patch help?  Probably not...

And does reverting
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.67/2.5.67-mm1/broken-out/earlier-keyboard-init.patch
fix it?

Thanks.

diff -puN drivers/input/serio/i8042.c~i8042-share-irqs drivers/input/serio/i8042.c
--- 25/drivers/input/serio/i8042.c~i8042-share-irqs	2003-04-08 09:05:16.000000000 -0700
+++ 25-akpm/drivers/input/serio/i8042.c	2003-04-08 09:05:59.000000000 -0700
@@ -235,7 +235,8 @@ static int i8042_open(struct serio *port
 		if (i8042_mux_open++)
 			return 0;
 
-	if (request_irq(values->irq, i8042_interrupt, 0, "i8042", NULL)) {
+	if (request_irq(values->irq, i8042_interrupt,
+			SA_SHIRQ, "i8042", NULL)) {
 		printk(KERN_ERR "i8042.c: Can't get irq %d for %s, unregistering the port.\n", values->irq, values->name);
 		values->exists = 0;
 		serio_unregister_port(port);
@@ -570,7 +571,7 @@ static int __init i8042_check_mux(struct
  * Check if AUX irq is available.
  */
 
-	if (request_irq(values->irq, i8042_interrupt, 0, "i8042", NULL))
+	if (request_irq(values->irq, i8042_interrupt, SA_SHIRQ, "i8042", NULL))
                 return -1;
 	free_irq(values->irq, NULL);
 
@@ -641,7 +642,7 @@ static int __init i8042_check_aux(struct
  * in trying to detect AUX presence.
  */
 
-	if (request_irq(values->irq, i8042_interrupt, 0, "i8042", NULL))
+	if (request_irq(values->irq, i8042_interrupt, SA_SHIRQ, "i8042", NULL))
                 return -1;
 	free_irq(values->irq, NULL);
 

_

Re: 2.5.67-mm1

[Randy.Dunlap]

On Tue, 8 Apr 2003 11:39:58 -0400 Ed Tomlinson <tomlins@cam.org> wrote:

| On April 8, 2003 11:31 am, Randy.Dunlap wrote:
| > On Tue, 8 Apr 2003 09:17:15 -0400 Ed Tomlinson <tomlins@cam.org> wrote:
| > | Hi,
| > |
| > | This does not boot here.  I loop with the following message.
| > |
| > | i8042.c: Can't get irq 12 for AUX, unregistering the port.
| > |
| > | irq 12 is used (correctly) by my 20267 ide card.  My mouse is
| > | usb and AUX is not used.
| > |
| > | Ideas?
| >
| > I guess that's due to my early kbd init patch.
| > So why do you have i8042 configured into your kernel?
| 
| One, What exactly configures it?  Two my keyboard is not usb, just
| my mouse.

CONFIG_SERIO=y
CONFIG_SERIO_I8042=y

Is your keyboard PS/2 or PC-AT-like, or something else?

| > The loop doesn't terminate?  Do you get the same message (above)
| > over and over again?
| 
| Yes, until I trigger a reboot (SysReq+B).

Interesting.  If I force that register IRQ 12 to fail, I just get this
one time:

i8042.c: Can't get irq 12 for AUX, unregistering the port.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1


Just saw Andrew's email...

--
~Randy

Re: 2.5.67-mm1

[Ed Tomlinson]

On April 8, 2003 11:31 am, Randy.Dunlap wrote:
> | This does not boot here.  I loop with the following message.
> |
> | i8042.c: Can't get irq 12 for AUX, unregistering the port.
> |
> | irq 12 is used (correctly) by my 20267 ide card.  My mouse is
> | usb and AUX is not used.
> |
> | Ideas?
>
> I guess that's due to my early kbd init patch.

Just to confirm, removing the above patch lets me 
boot just fine.

Thanks
Ed

Re: 2.5.67-mm1

[Helge Hafting]

Devfs fails to find all partitions with 2.5.67-mm1, plain 2.5.67 is fine

I have 2 scsi disks, and 2.5.67-mm1 find only some of the partitions
when I boot.  Below is ls -l listings for /dev/discs/disc0 and
/dev/discs/disc1.  Note the missing stuff - linux wasn't at all 
happy when the device for /usr couldn't be found at boot time.
Running cfdisk showed that the partitions were there though.

Helge Hafting

2.5.67-mm1: ls -l /dev/discs/disc0/ 
total 0
brw-rw----    1 root     disk       8,   0 Jan  1  1970 disc
crw-------    1 root     root      21,   0 Jan  1  1970 generic
brw-rw----    1 root     disk       8,   1 Jan  1  1970 part1
brw-rw----    1 root     disk       8,   8 Jan  1  1970 part8

2.5.67:  ls -l /dev/discs/disc0/
totalt 0
brw-rw----    1 root     disk       8,   0 1970-01-01 01:00 disc
crw-------    1 root     root      21,   0 1970-01-01 01:00 generic
brw-rw----    1 root     disk       8,   1 1970-01-01 01:00 part1
brw-rw----    1 root     disk       8,   2 1970-01-01 01:00 part2
brw-rw----    1 root     disk       8,   3 1970-01-01 01:00 part3
brw-rw----    1 root     disk       8,   5 1970-01-01 01:00 part5
brw-rw----    1 root     disk       8,   6 1970-01-01 01:00 part6
brw-rw----    1 root     disk       8,   7 1970-01-01 01:00 part7
brw-rw----    1 root     disk       8,   8 1970-01-01 01:00 part8

And the second disk:
2.5.67-mm1: ls -l /dev/discs/disc1/
total 0
brw-rw----    1 root     disk       8,  16 Jan  1  1970 disc
crw-------    1 root     root      21,   1 Jan  1  1970 generic
brw-rw----    1 root     disk       8,  17 Jan  1  1970 part1
brw-rw----    1 root     disk       8,  18 Jan  1  1970 part2
brw-rw----    1 root     disk       8,  22 Jan  1  1970 part6
brw-rw----    1 root     disk       8,  23 Jan  1  1970 part7
brw-rw----    1 root     disk       8,  24 Jan  1  1970 part8

2.5.67:  ls -l /dev/discs/disc1/
totalt 0
brw-rw----    1 root     disk       8,  16 1970-01-01 01:00 disc
crw-------    1 root     root      21,   1 1970-01-01 01:00 generic
brw-rw----    1 root     disk       8,  17 1970-01-01 01:00 part1
brw-rw----    1 root     disk       8,  18 1970-01-01 01:00 part2
brw-rw----    1 root     disk       8,  21 1970-01-01 01:00 part5
brw-rw----    1 root     disk       8,  22 1970-01-01 01:00 part6
brw-rw----    1 root     disk       8,  23 1970-01-01 01:00 part7
brw-rw----    1 root     disk       8,  24 1970-01-01 01:00 part8

Re: 2.5.67-mm1

[Ed Tomlinson]

On April 8, 2003 12:10 pm, Andrew Morton wrote:
> Does the below patch help?

Yes.  With it 67-mm1 boots.  I do find the following in dmesg though: 

CPU: AMD-K6(tm) 3D+ Processor stepping 01
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Initializing RT netlink socket
mtrr: v2.0 (20020519)
pty: 256 Unix98 ptys configured
Bad boy: i8042 (at 0xc0320738) called us without a dev_id!
Bad boy: i8042 (at 0xc0320852) called us without a dev_id!
Bad boy: i8042 (at 0xc020a9e8) called us without a dev_id!
serio: i8042 AUX port at 0x60,0x64 irq 12
Bad boy: i8042 (at 0xc020a9e8) called us without a dev_id!
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
PCI: PCI BIOS revision 2.10 entry at 0xfb520, last bus=1
PCI: Using configuration type 1
BIO: pool of 256 setup, 14Kb (56 bytes/bio)

Box seems to work fine.  There is nothing plugged onto AUX
as my mouse is USB.  The keyboard is plugged into the other
PS2 port...

Ed

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Helge Hafting]

2.5.67 works with framebuffer console, 2.5.67-mm1 dies before activating
graphichs mode on two different machines:

smp with matroxfb, also using a patch that makes matroxfb work in 2.5
up with radeonfb, also using patches that fixes the broken devfs in mm1.

I use devfs and preempt in both cases, and monolithic kernels without module
support.

2.5.67-mm1 works if I drop framebuffer support completely.

Here is the printed backtrace for the radeon case, the matrox case was 
similiar:

<a few lines scrolled off screen>
pcibios_enable_device
pci_enable_device_bars
pci_enable_device
radeonfb_pci_register
sysfs_new_inode
pci_device_probe
bus_match
device_attach
bus_add_device
kobject_add
device_add
pci_bus_add_devices
pci_bus_add_devices
pci_scan_bus_parented
pcibios_scan_root
pci_legacy_init
do_initcalls
init_workqueues
init+0x36
init+0x00
kernel_thread_helper
code: Bad EIP value <0>Kernel panic:attempt to kill init!

sysrq worked and let me reboot.  No filesystems were
mounted at this point.

Helge Hafting

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Randy.Dunlap]

On Wed, 9 Apr 2003 03:18:45 -0700 Andrew Morton <akpm@digeo.com> wrote:

| 
| Helge Hafting <helgehaf@aitel.hist.no> wrote:
| >
| > 2.5.67 works with framebuffer console, 2.5.67-mm1 dies before activating
| > graphichs mode on two different machines:
| > 
| > smp with matroxfb, also using a patch that makes matroxfb work in 2.5
| > up with radeonfb, also using patches that fixes the broken devfs in mm1.
| > 
| > I use devfs and preempt in both cases, and monolithic kernels without module
| > support.
| > 
| > 2.5.67-mm1 works if I drop framebuffer support completely.
| >
| > Here is the printed backtrace for the radeon case, the matrox case was 
| > similiar:
| 
| Well I tried to reproduce this with an
| 
| 	nVidia Corporation NV17 [GeForce4 MX440] (rev a3)
| 
| and the screen came up in a strange mixture of penguins and obviously uninitialised
| video RAM overlayed on top of text.  I can't read a thing.
| 
| But there is no oops.
| 
| The Cirrus drivers still do not compile, so scrub that test box.
| 
| We have some compilation scruffies:
| drivers/video/aty/mach64_gx.c:194: warning: initialization from incompatible pointer type
....
| 
| Another machine here uses
| 
| 	ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02)
| 
| and..... it oopses!   Backing out 
| 
| ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.67/2.5.67-mm1/broken-out/earlier-keyboard-init.patch
| 
| prevents it oopsing.  Can you please try that?
| 
| 
| Despite the lack of oopses, framebuffer support is sick on this machine also.
| The LCD alternates between blackness and a strange smeary set of flickering
| lines.

Argh.  This is ridiculous.... OK, I'm over it.  I'll look into this more.
I'd settle for Vojtech making an appearance.  :)

I can reproduce the problem with the earlier-keyboard-init.patch, but if
I reverse it, I get this [using Petr's 2.5.66-bk12 mga patch].  Is that the
right one to use?  do I need to use any kernel command line options with it?
Matrox G400 dual-head capable, but only using one of them.


matroxfb: Matrox G450 detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x26208)
matroxfb: framebuffer at 0xEC000000, mapped to 0xf8805000, size 16777216
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<00000000>]    Not tainted
EFLAGS: 00010246
EIP is at 0x0
eax: c04b77c8   ebx: f7f9fccc   ecx: c1ada17f   edx: c04b6f40
esi: ffffffff   edi: 00000030   ebp: 00000030   esp: f7f9fc78
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 1, threadinfo=f7f9e000 task=f7f9c080)
Stack: c0292c1e c04b6f40 f7f9fccc ffffffff ffffffff 00000000 00000000 00000400 
       00000008 00000001 000000ff 0000000c c04b6f40 00000030 c1a41480 c0292e65 
       c1a41480 c04b6f40 f7f9fccc 00000030 c00bb1c0 00000000 00000108 00000180 
Call Trace:
 [<c0292c1e>] putcs_aligned+0x16e/0x1b0
 [<c0292e65>] accel_putcs+0xc5/0xf0
 [<c02939ce>] fbcon_putcs+0x7e/0x90
 [<c01feb73>] vt_console_print+0x103/0x2b0
 [<c011f616>] __call_console_drivers+0x46/0x60
 [<c011f762>] call_console_drivers+0xc2/0xf0
 [<c011fb23>] release_console_sem+0xa3/0x140
 [<c011f9d8>] printk+0x1d8/0x230
 [<c029367a>] fbcon_set_display+0x33a/0x4c0
 [<c01f8031>] set_inverse_transl+0x41/0xa0
 [<c013ecad>] kmalloc+0xdd/0x190
 [<c010b592>] do_IRQ+0x112/0x1f0
 [<c02930cd>] fbcon_init+0xdd/0xf0
 [<c01fba0f>] visual_init+0x9f/0x100
 [<c01ff3bd>] take_over_console+0xad/0x180
 [<c02981f5>] register_framebuffer+0x175/0x1a0
 [<c029be10>] initMatrox2+0x8e0/0x990
 [<c02d07ad>] pcibios_enable_device+0x1d/0x20
 [<c029c3c2>] matroxfb_probe+0x2c2/0x2f0
 [<c01e320f>] pci_device_probe+0x3f/0x60
 [<c021d4c4>] bus_match+0x34/0x60
 [<c021d594>] driver_attach+0x34/0x60
 [<c021d847>] bus_add_driver+0x97/0xd0
 [<c01e3326>] pci_register_driver+0x46/0x60
 [<c01050fb>] init+0x7b/0x220
 [<c0105080>] init+0x0/0x220
 [<c0107165>] kernel_thread_helper+0x5/0x10

Code:  Bad EIP value.
 <0>Kernel panic: Attempted to kill init!


--
~Randy

Re: 2.5.67-mm1 bootcrash, possibly IDE or RAID

[William Lee Irwin III]

On Wed, May 28, 2003 at 01:14:28PM +0200, Helge Hafting wrote:
> 2.5.69-mm8 is fine, 2.5.67-mm1 dies before mounting anything read-write.
> The early kernel boot is fine, the penguin appear,
> a bunch of the usual messages scroll by too fast to read,
> and then it hangs.
> The kernel is UP, with preempt & devfs.  All filesystems
> are ext2. This kernel has no module support.
> Root is on raid-1, there are two
> ide disks connected to this controller on separate cables:
> 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]

Well, bugs were fixed since 2.5.67-mm1. Just upgrade to the most recent
kernel (2.5.70-mm1).


-- wli

Re: 2.5.67-mm1 bootcrash, possibly IDE or RAID

[Helge Hafting]

2.5.69-mm8 is fine, 2.5.67-mm1 dies before mounting anything read-write.

The early kernel boot is fine, the penguin appear,
a bunch of the usual messages scroll by too fast to read,
and then it hangs.

The kernel is UP, with preempt & devfs.  All filesystems
are ext2. This kernel has no module support.

Root is on raid-1, there are two
ide disks connected to this controller on separate cables:
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]

Here's the decoded crash, written down by hand:
<stuff scrolled off screen>
bio_endio
_end_that_request_first
ide_end_request
ide_dma_intr
ide_intr
ide_dma_intr
handle_IRQ_event
do_IRQ
default_idle
default_idle
common_interrupt
default_idle
default_idle
default_idle
cpu_idle
rest_init
start_kernel
unknown_bootoption
<0>Kwrnel Panic fatal exception in interrupt
in interrupt - not syncing

Re: 2.5.70-mm1 bootcrash, possibly IDE or RAID

[Helge Hafting]

William Lee Irwin III wrote:
> On Wed, May 28, 2003 at 01:14:28PM +0200, Helge Hafting wrote:
> 
>>2.5.69-mm8 is fine, 2.5.67-mm1 dies before mounting anything read-write.
Argh.  I meant 2.5.70-mm1.  Followup to the wrong message. :-(

The early kernel boot is fine, the penguin appear,
a bunch of the usual messages scroll by too fast to read,
and then it hangs.
The kernel is UP, with preempt & devfs.  All filesystems
are ext2. This kernel has no module support.

Root is on raid-1, there are two
ide disks connected to this controller on separate cables:
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]

Here's the decoded crash, written down by hand:
<stuff scrolled off screen>
bio_endio
_end_that_request_first
ide_end_request
ide_dma_intr
ide_intr
ide_dma_intr
handle_IRQ_event
do_IRQ
default_idle
default_idle
common_interrupt
default_idle
default_idle
default_idle
cpu_idle
rest_init
start_kernel
unknown_bootoption
<0>Kwrnel Panic fatal exception in interrupt
in interrupt - not syncing

Re: 2.5.70-mm1 bootcrash, possibly IDE or RAID

[William Lee Irwin III]

On Wed, May 28, 2003 at 01:34:16PM +0200, Helge Hafting wrote:
> Here's the decoded crash, written down by hand:
> <stuff scrolled off screen>
> bio_endio
> _end_that_request_first
> ide_end_request
> ide_dma_intr
> ide_intr
> ide_dma_intr
> handle_IRQ_event
> do_IRQ
> default_idle
> default_idle
> common_interrupt

This is unusual; I'm having trouble very close to this area. There is
a remote chance it could be the same problem.

Could you log this to serial and get the rest of the oops/BUG? If it's
where I think it is, I've been looking at end_page_writeback() and so
might have an idea or two.


-- wli

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Helge Hafting]

On Wed, May 28, 2003 at 04:35:44AM -0700, William Lee Irwin III wrote:
> 
> This is unusual; I'm having trouble very close to this area. There is
> a remote chance it could be the same problem.
> 
> Could you log this to serial and get the rest of the oops/BUG? If it's
> where I think it is, I've been looking at end_page_writeback() and so
> might have an idea or two.

I tried 2.5.70-mm1 on the dual celeron at home.  This one has
scsi instead of ide, so I guess it is a RAID-1 problem.
This machine has root on raid-1 too.  I believe there where
several oopses in a row, I captured all of the last one
thanks to a framebuffer with a small font. Here it is:

Unable to handle kernel paging request at virtual address 8a8a8ab6
*pde=0 OOPS 0000 [#1]
EIP at put_all_bios+0x47/0x80
(edx was the register containing 8a8a8a8a)
Process swapper pid=0 threadinfo c1352000 task=c13f52d0
Call trace:
raid_end_bio_io
raid1_end_request
scsi_request_fn
bio_endio
_end_that_request_first
scsi_end_request
__wake_up
scsi_io_completion
scsi_delete_timer
sd_rw_intr
sym_wakeup_done
scsi_finish_command
scsi_softirq
timer_interrupt
do_softirq
do_IRQ
default_idle
default_idle
common_interrupt
default_idle
default_idle
default_idle
cpu_idle
printk
<0> Kernel panic:fatal exception in interrupt
in interrupt - not syncing
reboot in 300 seconds

This looks very similiar to the partial trace
from the ide machine,
it had everything from _end_that_request_first
down to the three default_idles, but with ide
instead of scsi functions.

Helge Hafting

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Andrew Morton]

Helge Hafting <helgehaf@aitel.hist.no> wrote:
>
> On Wed, May 28, 2003 at 04:35:44AM -0700, William Lee Irwin III wrote:
> > 
> > This is unusual; I'm having trouble very close to this area. There is
> > a remote chance it could be the same problem.
> > 
> > Could you log this to serial and get the rest of the oops/BUG? If it's
> > where I think it is, I've been looking at end_page_writeback() and so
> > might have an idea or two.
> 
> I tried 2.5.70-mm1 on the dual celeron at home.  This one has
> scsi instead of ide, so I guess it is a RAID-1 problem.
> This machine has root on raid-1 too.  I believe there where
> several oopses in a row, I captured all of the last one
> thanks to a framebuffer with a small font. Here it is:
> 
> Unable to handle kernel paging request at virtual address 8a8a8ab6
> *pde=0 OOPS 0000 [#1]
> EIP at put_all_bios+0x47/0x80
> (edx was the register containing 8a8a8a8a)
> Process swapper pid=0 threadinfo c1352000 task=c13f52d0
> Call trace:
> raid_end_bio_io
> raid1_end_request

That's POISON_BEFORE: "use of uninitialised memory", not "use of freed
memory".

I fiddled with the slab poisoning values, and shall undo that.

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Paul E. Erkkila]

I'm having a similar problem here with 2.5.70. I can't
seem to get the entire stack trace though, but with a
stripped down kernel config it seems to be when during
the time MD starts working.

Machine is an asus p4c8000, intel ich5, using the IDE
part not sata. I'm also using /dev/md0 as my root
partition.

Hope that helps, i'm trying to find a null modem to
get a real capture ;).

-pee

Helge Hafting wrote:

>On Wed, May 28, 2003 at 04:35:44AM -0700, William Lee Irwin III wrote:
>  
>
>>This is unusual; I'm having trouble very close to this area. There is
>>a remote chance it could be the same problem.
>>
>>Could you log this to serial and get the rest of the oops/BUG? If it's
>>where I think it is, I've been looking at end_page_writeback() and so
>>might have an idea or two.
>>    
>>
>
>I tried 2.5.70-mm1 on the dual celeron at home.  This one has
>scsi instead of ide, so I guess it is a RAID-1 problem.
>This machine has root on raid-1 too.  I believe there where
>several oopses in a row, I captured all of the last one
>thanks to a framebuffer with a small font. Here it is:
>
>Unable to handle kernel paging request at virtual address 8a8a8ab6
>*pde=0 OOPS 0000 [#1]
>EIP at put_all_bios+0x47/0x80
>(edx was the register containing 8a8a8a8a)
>Process swapper pid=0 threadinfo c1352000 task=c13f52d0
>Call trace:
>raid_end_bio_io
>raid1_end_request
>scsi_request_fn
>bio_endio
>_end_that_request_first
>scsi_end_request
>__wake_up
>scsi_io_completion
>scsi_delete_timer
>sd_rw_intr
>sym_wakeup_done
>scsi_finish_command
>scsi_softirq
>timer_interrupt
>do_softirq
>do_IRQ
>default_idle
>default_idle
>common_interrupt
>default_idle
>default_idle
>default_idle
>cpu_idle
>printk
><0> Kernel panic:fatal exception in interrupt
>in interrupt - not syncing
>reboot in 300 seconds
>
>This looks very similiar to the partial trace
>from the ide machine,
>it had everything from _end_that_request_first
>down to the three default_idles, but with ide
>instead of scsi functions.
>
>Helge Hafting
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Neil Brown]

Greetings all.

I think this might fix the bug, but I haven't looked very closely
yet.  I will expore it more deeply when I get time.

NeilBrown



 ----------- Diffstat output ------------
 ./drivers/md/raid1.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff ./drivers/md/raid1.c~current~ ./drivers/md/raid1.c
--- ./drivers/md/raid1.c~current~	2003-05-29 11:05:03.000000000 +1000
+++ ./drivers/md/raid1.c	2003-05-29 11:05:08.000000000 +1000
@@ -137,7 +137,7 @@ static void put_all_bios(conf_t *conf, r
 			BUG();
 		bio_put(r1_bio->read_bio);
 		r1_bio->read_bio = NULL;
-	}
+	} else
 	for (i = 0; i < conf->raid_disks; i++) {
 		struct bio **bio = r1_bio->write_bios + i;
 		if (*bio) {

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Zwane Mwaikambo]

On Thu, 29 May 2003, Neil Brown wrote:

> I think this might fix the bug, but I haven't looked very closely
> yet.  I will expore it more deeply when I get time.
> 
> NeilBrown

No go;

raid0:   comparing sdd1(4193152) with sdd1(4193152)
raid0:   END
raid0:   ==> UNIQUE
raid0: 1 zones
raid0: looking at sdc1
raid0:   comparing sdc1(4193152) with sdd1(4193152)
raid0:   EQUAL
raid0: FINAL 1 zones
raid0: multiple devices for 1 - aborting!
slab error in cache_free_debugcheck(): cache `size-32': double free, or memory before object was overwritten
Call Trace:
 [<c0148da3>] kfree+0xf3/0x2e0
 [<c0366a64>] raid0_run+0x234/0x250
 [<c0366a64>] raid0_run+0x234/0x250
 [<c012529a>] printk+0x1ca/0x280
 [<c0371fa4>] do_md_run+0x2f4/0x560
 [<c0371fbb>] do_md_run+0x30b/0x560
 [<c012529a>] printk+0x1ca/0x280
 [<c03724f2>] autorun_array+0x82/0xa0
 [<c012529a>] printk+0x1ca/0x280
 [<c03726ff>] autorun_devices+0x1ef/0x230
 [<c0375569>] autostart_arrays+0x29/0xba
 [<c036f8f6>] mddev_put+0x16/0xb0
 [<c0250728>] capable+0x18/0x40
 [<c03737de>] md_ioctl+0x56e/0x5a0
 [<c0169759>] blkdev_open+0x29/0x30
 [<c015f0dc>] dentry_open+0x14c/0x230
 [<c0148c2a>] kmem_cache_free+0x1ca/0x250
 [<c02a2f0b>] blkdev_ioctl+0x8b/0x3b1
 [<c01747d6>] sys_ioctl+0x156/0x310
 [<c056f6b7>] md_run_setup+0x57/0x80
 [<c056ef28>] prepare_namespace+0x8/0xa0
 [<c01050fb>] init+0x5b/0x210
 [<c01050a0>] init+0x0/0x210
 [<c01070e5>] kernel_thread_helper+0x5/0x10


-- 
function.linuxpower.ca

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Zwane Mwaikambo]

How does the following patch look for the double free.

On Thu, 29 May 2003, Zwane Mwaikambo wrote:

> slab error in cache_free_debugcheck(): cache `size-32': double free, or memory before object was overwritten
> Call Trace:
>  [<c0148da3>] kfree+0xf3/0x2e0
>  [<c0366a64>] raid0_run+0x234/0x250
>  [<c0366a64>] raid0_run+0x234/0x250
>  [<c012529a>] printk+0x1ca/0x280
>  [<c0371fa4>] do_md_run+0x2f4/0x560
>  [<c0371fbb>] do_md_run+0x30b/0x560
>  [<c012529a>] printk+0x1ca/0x280
>  [<c03724f2>] autorun_array+0x82/0xa0
>  [<c012529a>] printk+0x1ca/0x280
>  [<c03726ff>] autorun_devices+0x1ef/0x230
>  [<c0375569>] autostart_arrays+0x29/0xba
>  [<c036f8f6>] mddev_put+0x16/0xb0
>  [<c0250728>] capable+0x18/0x40
>  [<c03737de>] md_ioctl+0x56e/0x5a0
>  [<c0169759>] blkdev_open+0x29/0x30
>  [<c015f0dc>] dentry_open+0x14c/0x230
>  [<c0148c2a>] kmem_cache_free+0x1ca/0x250
>  [<c02a2f0b>] blkdev_ioctl+0x8b/0x3b1
>  [<c01747d6>] sys_ioctl+0x156/0x310
>  [<c056f6b7>] md_run_setup+0x57/0x80
>  [<c056ef28>] prepare_namespace+0x8/0xa0
>  [<c01050fb>] init+0x5b/0x210
>  [<c01050a0>] init+0x0/0x210
>  [<c01070e5>] kernel_thread_helper+0x5/0x10

Index: linux-2.5/drivers/md/raid0.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/md/raid0.c,v
retrieving revision 1.31
diff -u -p -B -r1.31 raid0.c
--- linux-2.5/drivers/md/raid0.c	27 May 2003 04:06:15 -0000	1.31
+++ linux-2.5/drivers/md/raid0.c	29 May 2003 06:35:17 -0000
@@ -85,10 +85,8 @@ static int create_strip_zones (mddev_t *
 	conf->devlist = kmalloc(sizeof(mdk_rdev_t*)*
 				conf->nr_strip_zones*mddev->raid_disks,
 				GFP_KERNEL);
-	if (!conf->devlist) {
-		kfree(conf);
+	if (!conf->devlist)
 		return 1;
-	}
 
 	memset(conf->strip_zone, 0,sizeof(struct strip_zone)*
 				   conf->nr_strip_zones);
@@ -194,7 +192,6 @@ static int create_strip_zones (mddev_t *
 	return 0;
  abort:
 	kfree(conf->devlist);
-	kfree(conf->strip_zone);
 	return 1;
 }
 
-- 
function.linuxpower.ca

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[John Stoffel]

Helge> On Wed, May 28, 2003 at 04:35:44AM -0700, William Lee Irwin III wrote:
>> 
>> Could you log this to serial and get the rest of the oops/BUG? If it's
>> where I think it is, I've been looking at end_page_writeback() and so
>> might have an idea or two.

Helge> I tried 2.5.70-mm1 on the dual celeron at home.  This one has
Helge> scsi instead of ide, so I guess it is a RAID-1 problem.
Helge> This machine has root on raid-1 too.  I believe there where
Helge> several oopses in a row, I captured all of the last one
Helge> thanks to a framebuffer with a small font. Here it is:

I've finally gotten 2.5.70-mm1 compiled and bootable on my system, but
with my /home being RAID1, I was getting crashes that looked alot like
this as well.  This was a Dual PIII Xeon 550, with a mix of IDE and
SCSI drives.  /home was on a pair of 18gb SCSI disks, RAID1.  

I also had problems with the new AIC7xxx driver and had to drop back
to the old one to get a boot.  I think.  Lots and lots of confusion
here.

John

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Neil Brown]

On Thursday May 29, zwane@linuxpower.ca wrote:
> How does the following patch look for the double free.
> 

Thanks. It is a good start, but there are other problems with freeing
things on error paths.   This patch should fix it all.

NeilBrown

--------------------------------------------
Fix up freeing of kmalloc structures

Some paths free things twice, others free un-initialised values :-(
Not any more.


 ----------- Diffstat output ------------
 ./drivers/md/raid0.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff ./drivers/md/raid0.c~current~ ./drivers/md/raid0.c
--- ./drivers/md/raid0.c~current~	2003-05-30 11:40:06.000000000 +1000
+++ ./drivers/md/raid0.c	2003-05-30 11:47:03.000000000 +1000
@@ -85,10 +85,8 @@ static int create_strip_zones (mddev_t *
 	conf->devlist = kmalloc(sizeof(mdk_rdev_t*)*
 				conf->nr_strip_zones*mddev->raid_disks,
 				GFP_KERNEL);
-	if (!conf->devlist) {
-		kfree(conf);
+	if (!conf->devlist)
 		return 1;
-	}
 
 	memset(conf->strip_zone, 0,sizeof(struct strip_zone)*
 				   conf->nr_strip_zones);
@@ -235,6 +233,8 @@ static int raid0_run (mddev_t *mddev)
 		goto out;
 	mddev->private = (void *)conf;
  
+	mddev->strip_zone = NULL;
+	mddev->devlist = NULL;
 	if (create_strip_zones (mddev)) 
 		goto out_free_conf;
 
@@ -273,7 +273,7 @@ static int raid0_run (mddev_t *mddev)
 				nb_zone*sizeof(struct strip_zone*));
 	conf->hash_table = kmalloc (sizeof (struct strip_zone *)*nb_zone, GFP_KERNEL);
 	if (!conf->hash_table)
-		goto out_free_zone_conf;
+		goto out_free_conf;
 	size = conf->strip_zone[cur].size;
 
 	for (i=0; i< nb_zone; i++) {
@@ -296,12 +296,11 @@ static int raid0_run (mddev_t *mddev)
 	blk_queue_merge_bvec(&mddev->queue, raid0_mergeable_bvec);
 	return 0;
 
-out_free_zone_conf:
-	kfree(conf->strip_zone);
-	conf->strip_zone = NULL;
-
 out_free_conf:
-	kfree (conf->devlist);
+	if (conf->strip_zone)
+		kfree(conf->strip_zone);
+	if (conf->devlist)
+		kfree (conf->devlist);
 	kfree(conf);
 	mddev->private = NULL;
 out:

Re: 2.5.70-mm1 bootcrash, possibly RAID-1

[Paul E. Erkkila]

With patch applied to lastest BK I get this on bootup.
(manual copy)

blk_queue_segment_boundary: set to minimum fff
raid1: raid set md0 active with 2 out of 2 mirrors
md: ... autorun DONE.
---------------[ cut here ] -------------
kernbel BUG at drivers/md/raid1.c:145!
invalid operand: 000 [#1]
CPU:   0
EIP:   0060:[<c025d7df>]   Not tainted
EFLAGS: 00010097
EIP is at put_all_bios+0x59/0x85
eax: 00000000 ebx: 00000001 exc: 00000010 edx: f7ffb800
esi: f7d5ddb4 edi: 00000003 ebp: c036bdf8 esp: c036bde8
ds: 007 es: 007b ss:0068
Process swapper (pid: 0, threadinfo=c036a000 task=c02f3000)
Stack: f7fcf900 f7d80480 00000046 f7d5dd80 c036be18 c025d8fc f7d80480 
f7d4dd80
       00000000 f7d5dd80 00000001 0000000c c036be18 c025da43 f7d5dd80 
f7f9f880
       00000003 00000000 00000001 00000004 00000000 c18f5ch4 f7d6fce0 
0000000c

Call Trace:
[<c025d8fc>] raid_end_bio_io+0x55/0x92
[<c025da43>] raid1_end_request+0x10a/0x196
[<c013042c>] mempool_free+0x32/0x65
[<c014a420>] bio_endio+0x55/0x7a
[<c01ef559>] __end_that_request_first+0x1f1/0x20d
[<c023c0a4>] ide_end_request+0x58/0x118
[<c024f3cb>] ide_dma_intr+0x9d/0xba
[<c023d43f>] ide_intr+0xb9/0x12e
[<c024f34e>] ide_dma_intr+0x0/0xba
[<c010c279>] handle_IRQ_event+0x3c/0xfd
[<c010c48f>] do_IRQ+0x80/0xd6
[<c0108be9>] default_idle+0x0/0x2c
[<c0108be9>] default_idle+0x0/0x2c
[<c010acd4>] common_interrupt+0x18/0x20
[<c0108be9>] default_idle+0x0/0x2c
[<c0108be9>] default_idle+0x0/0x2c
[<c0108c10>] default_idle+0x27/0x2c
[<c0108c81>] cpu_idle+0x31/0x3a
[<c0105000>] _stext+0x0/0x2a
[<c036c678>] start_kernel+0x152/0x177
[<c036c401>] unknown_bootoption+0x0/0xfa

Code: 0f 0b 91 00 85 96 2d c0 89 14 24 e8 7e c2 ee ff c7 06 00 00
 <0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing




















Neil Brown wrote:

>On Thursday May 29, zwane@linuxpower.ca wrote:
>  
>
>>How does the following patch look for the double free.
>>
>>    
>>
>
>Thanks. It is a good start, but there are other problems with freeing
>things on error paths.   This patch should fix it all.
>
>NeilBrown
>
>--------------------------------------------
>Fix up freeing of kmalloc structures
>
>Some paths free things twice, others free un-initialised values :-(
>Not any more.
>
>
> ----------- Diffstat output ------------
> ./drivers/md/raid0.c |   17 ++++++++---------
> 1 files changed, 8 insertions(+), 9 deletions(-)
>
>diff ./drivers/md/raid0.c~current~ ./drivers/md/raid0.c
>--- ./drivers/md/raid0.c~current~	2003-05-30 11:40:06.000000000 +1000
>+++ ./drivers/md/raid0.c	2003-05-30 11:47:03.000000000 +1000
>@@ -85,10 +85,8 @@ static int create_strip_zones (mddev_t *
> 	conf->devlist = kmalloc(sizeof(mdk_rdev_t*)*
> 				conf->nr_strip_zones*mddev->raid_disks,
> 				GFP_KERNEL);
>-	if (!conf->devlist) {
>-		kfree(conf);
>+	if (!conf->devlist)
> 		return 1;
>-	}
> 
> 	memset(conf->strip_zone, 0,sizeof(struct strip_zone)*
> 				   conf->nr_strip_zones);
>@@ -235,6 +233,8 @@ static int raid0_run (mddev_t *mddev)
> 		goto out;
> 	mddev->private = (void *)conf;
>  
>+	mddev->strip_zone = NULL;
>+	mddev->devlist = NULL;
> 	if (create_strip_zones (mddev)) 
> 		goto out_free_conf;
> 
>@@ -273,7 +273,7 @@ static int raid0_run (mddev_t *mddev)
> 				nb_zone*sizeof(struct strip_zone*));
> 	conf->hash_table = kmalloc (sizeof (struct strip_zone *)*nb_zone, GFP_KERNEL);
> 	if (!conf->hash_table)
>-		goto out_free_zone_conf;
>+		goto out_free_conf;
> 	size = conf->strip_zone[cur].size;
> 
> 	for (i=0; i< nb_zone; i++) {
>@@ -296,12 +296,11 @@ static int raid0_run (mddev_t *mddev)
> 	blk_queue_merge_bvec(&mddev->queue, raid0_mergeable_bvec);
> 	return 0;
> 
>-out_free_zone_conf:
>-	kfree(conf->strip_zone);
>-	conf->strip_zone = NULL;
>-
> out_free_conf:
>-	kfree (conf->devlist);
>+	if (conf->strip_zone)
>+		kfree(conf->strip_zone);
>+	if (conf->devlist)
>+		kfree (conf->devlist);
> 	kfree(conf);
> 	mddev->private = NULL;
> out:
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>