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/
>  
>

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Petr Vandrovec]

On  9 Apr 03 at 15:55, Randy.Dunlap wrote:
> On Wed, 9 Apr 2003 23:52:51 +0200 "Petr Vandrovec" <VANDROVE@vc.cvut.cz> wrote:
> 
> | On  9 Apr 03 at 14:45, Randy.Dunlap wrote:
> | >  [<c029367a>] fbcon_set_display+0x33a/0x4c0
> | >  [<c01f8031>] set_inverse_transl+0x41/0xa0
> | 
> | Can you remove 'printk(KERN_DEBUG "%s: %ux%u, vt=%u, init=%u, ...'
> | from fbcon_set_display (drivers/video/console/fbcon.c)? On my system
> | printk(KERN_DEBUG) does not print nothing to the console even before
> | syslogd is started (one wonders why...), but on your system it apparently
> | triggers output to console before video mode was set.
> 
> Yes, I did that and can report that this one printk() kills it for me.
> I.e., it boots and runs fine with this line commented out, but when I
> put it back and rebuild, that kernel gets the same oops during boot.

Thanks. It looks like that I missed that there is still large window where
we use fbcon before mode is set on underlying fbdev, even after reorg.
I did at console level. For now it is easier to remove this printk...
                                                            Petr
                                                            

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Randy.Dunlap]

On Wed, 9 Apr 2003 23:52:51 +0200 "Petr Vandrovec" <VANDROVE@vc.cvut.cz> wrote:

| On  9 Apr 03 at 14:45, Randy.Dunlap wrote:
| >  [<c029367a>] fbcon_set_display+0x33a/0x4c0
| >  [<c01f8031>] set_inverse_transl+0x41/0xa0
| 
| Can you remove 'printk(KERN_DEBUG "%s: %ux%u, vt=%u, init=%u, ...'
| from fbcon_set_display (drivers/video/console/fbcon.c)? On my system
| printk(KERN_DEBUG) does not print nothing to the console even before
| syslogd is started (one wonders why...), but on your system it apparently
| triggers output to console before video mode was set.

Yes, I did that and can report that this one printk() kills it for me.
I.e., it boots and runs fine with this line commented out, but when I
put it back and rebuild, that kernel gets the same oops during boot.

--
~Randy

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Petr Vandrovec]

On  9 Apr 03 at 14:45, Randy.Dunlap wrote:
>  [<c029367a>] fbcon_set_display+0x33a/0x4c0
>  [<c01f8031>] set_inverse_transl+0x41/0xa0

Can you remove 'printk(KERN_DEBUG "%s: %ux%u, vt=%u, init=%u, ...'
from fbcon_set_display (drivers/video/console/fbcon.c)? On my system
printk(KERN_DEBUG) does not print nothing to the console even before
syslogd is started (one wonders why...), but on your system it apparently
triggers output to console before video mode was set.
                                            Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Randy.Dunlap]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

On Wed, 9 Apr 2003 22:58:45 +0200 "Petr Vandrovec" <VANDROVE@vc.cvut.cz> wrote:

| [As this one is matroxfb only, I removed others...]
| 
| > 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
| 
| It should not happen. Did not you get some rejects while patching?

No.

| > 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
| 
| If your kernel binary is simillar to mine, it looks like that 
| fbops->fb_imageblit was NULL. It should not happen, as matroxfb's 
| fb_imageblit should point either to no_imageblit (which currenlty does 
| nothing, but it should complain loudly) or to cfb_imageblit (which 
| paints character) or matroxfb_imageblit (which should paint character too).
| 
| But from call trace it looks like that some printk() error got
| triggered on your config. Can you try booting with serial console? 
| Do you see penguins on the screen, or not? 

No penguins on screen.
I don't see any problems logged.  I did boot with serial console.
It's attached.

| Or remove body from drivers/video/console/fbcon.c:check_vc() - it should
| is not triggered on Linus kernels, but maybe -mm1 moved something around.
| It looks like that it is time to download -mm1 :-(

Actually this is just 2.5.67 + mga-2.5.66-bk12 with and without my
earlier-keyboard-init.patch...

--
~Randy

[-- Attachment #2: mfb2-capture.txt --]
[-- Type: text/plain, Size: 9629 bytes --]

Synchronizing SCSI caches: sda 
Shutting down devices
Restarting system.
Linux version 2.5.67 (rddunlap@gargoyle.pdx.osdl.net) (gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)) #10 SMP Wed Apr 9 13:01:23 PDT 2003
Video mode to be used for restore is f06
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f52a0
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 262128
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:16
  HighMem zone: 32752 pages, LIFO batch:7
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 15:1 APIC version 17
Processor #1 15:0 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2
IBM machine detected. Enabling interrupts during APM calls.
IBM machine detected. Disabling SMBus accesses.
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=lin2567nkb root=304 hdd=ide-scsi devfs=nomount debug console=ttyS0,38400n8 console=tty1 profile=4
ide_setup: hdd=ide-scsi
kernel profiling enabled
Initializing CPU#0
PID hash table entries: 4096 (order 12: 32768 bytes)
Detected 1684.911 MHz processor.
Console: colour VGA+ 80x34
Calibrating delay loop... 3317.76 BogoMIPS
Memory: 1032604k/1048512k available (2396k kernel code, 14988k reserved, 991k data, 140k init, 131008k highmem)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 256K
CPU: Hyper-Threading is disabled
CPU:     After generic, caps: 3febfbff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU#0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel(R) Xeon(TM) CPU 1.70GHz stepping 02
per-CPU timeslice cutoff: 731.63 usecs.
task migration cache decay timeout: 1 msecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 3358.72 BogoMIPS
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 256K
CPU: Hyper-Threading is disabled
CPU:     After generic, caps: 3febfbff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU#1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU#1: Thermal monitoring enabled
CPU1: Intel(R) Xeon(TM) CPU 1700MHz stepping 0a
Total of 2 processors activated (6676.48 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-12, 2-18, 2-21, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 20.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00178020
.......     : max redirection entries: 0017
.......     : PRQ implemented: 1
.......     : IO APIC version: 0020
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 000 00  1    0    0   0   0    0    0    00
 06 001 01  0    0    0   0   0    1    1    51
 07 001 01  0    0    0   0   0    1    1    59
 08 001 01  0    0    0   0   0    1    1    61
 09 001 01  0    0    0   0   0    1    1    69
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 000 00  1    0    0   0   0    0    0    00
 0d 001 01  0    0    0   0   0    1    1    71
 0e 001 01  0    0    0   0   0    1    1    79
 0f 001 01  0    0    0   0   0    1    1    81
 10 001 01  1    1    0   1   0    1    1    89
 11 001 01  1    1    0   1   0    1    1    91
 12 000 00  1    0    0   0   0    0    0    00
 13 001 01  1    1    0   1   0    1    1    99
 14 001 01  1    1    0   1   0    1    1    A1
 15 000 00  1    0    0   0   0    0    0    00
 16 001 01  1    1    0   1   0    1    1    A9
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ22 -> 0:22
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1684.0925 MHz.
..... host bus clock speed is 99.0113 MHz.
checking TSC synchronization across 2 CPUs: passed.
Starting migration thread for cpu 0
Bringing up 1
CPU 1 IS NOW UP!
Starting migration thread for cpu 1
CPUS done 8
Initializing RT netlink socket
mtrr: v2.0 (20020519)
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
PCI: PCI BIOS revision 2.10 entry at 0xfb110, last bus=4
PCI: Using configuration type 1
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs: 256 entries (12 bytes)
biovec pool[1]:   4 bvecs: 256 entries (48 bytes)
biovec pool[2]:  16 bvecs: 256 entries (192 bytes)
biovec pool[3]:  64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
Linux Plug and Play Support v0.96 (c) Adam Belay
block request queues:
 128 requests per read queue
 128 requests per write queue
 8 requests per batch
 enter congestion at 15
 exit congestion at 17
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Br
PCI: Using IRQ router PIIX [8086/2440] at 00:1f.0
PCI->APIC IRQ transform: (B1,I0,P0) -> 22
PCI->APIC IRQ transform: (B3,I1,P0) -> 20
PCI->APIC IRQ transform: (B3,I1,P1) -> 20
PCI->APIC IRQ transform: (B4,I4,P0) -> 16
PCI->APIC IRQ transform: (B0,I31,P3) -> 19
PCI->APIC IRQ transform: (B0,I31,P1) -> 17
PCI->APIC IRQ transform: (B0,I31,P1) -> 17
Starting balanced_irq
Enabling SEP on CPU 1
Enabling SEP on CPU 0
highmem bounce pool size: 64 pages
Journalled Block Device driver loaded
udf: registering filesystem
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!
 

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Petr Vandrovec]

[As this one is matroxfb only, I removed others...]

> 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

It should not happen. Did not you get some rejects while patching?

> 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

If your kernel binary is simillar to mine, it looks like that 
fbops->fb_imageblit was NULL. It should not happen, as matroxfb's 
fb_imageblit should point either to no_imageblit (which currenlty does 
nothing, but it should complain loudly) or to cfb_imageblit (which 
paints character) or matroxfb_imageblit (which should paint character too).

But from call trace it looks like that some printk() error got
triggered on your config. Can you try booting with serial console? 
Do you see penguins on the screen, or not? 

Or remove body from drivers/video/console/fbcon.c:check_vc() - it should
is not triggered on Linus kernels, but maybe -mm1 moved something around.
It looks like that it is time to download -mm1 :-(
                                            Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Chuck Ebbert]

> Unfortunately, as proven by i2c, kobjects infrastructure does not like if
> you reference non-existing bus type before it is registered.


  AFAICT sysfs itself sort of has this problem in 2.5.66 -- it tries
to register itself as a filesystem before the set 'fs' is registered.
It retries later and succeeds but I could never figure out if that was
by design or accident. 8)

  This patch helps find some of these problems but I don't think it will
help in this case:


diff -ur --exclude-from=/home/me/exclude linux-2.5.66-ref/lib/kobject.c linux-2.5.66-uni/lib/kobject.c
--- linux-2.5.66-ref/lib/kobject.c	Tue Mar  4 22:29:36 2003
+++ linux-2.5.66-uni/lib/kobject.c	Sat Mar 29 20:43:26 2003
@ -57,10 +57,15 @
 				sysfs_remove_dir(kobj);
 		}
 	}
+	if (error) {
+		printk("Badness name:%s, err:%d, set:%s\n",
+		       kobj->name, error,
+		       kobj->kset ? kobj->kset->kobj.name : "<NULL>");
+		WARN_ON(1);
+	}
 	return error;
 }
 
-
 static inline struct kobject * to_kobj(struct list_head * entry)
 {
 	return container_of(entry,struct kobject,entry);
@ -149,7 +154,6 @
 	if (kobj) {
 		kobject_init(kobj);
 		error = kobject_add(kobj);
-		WARN_ON(error);
 	} else
 		error = -EINVAL;
 	return error;

--
 Chuck

Re: 2.5.67-mm1 cause framebuffer crash at bootup

[Petr Vandrovec]

On  9 Apr 03 at 11:42, Helge Hafting wrote:
> 
> 2.5.67-mm1 works if I drop framebuffer support completely.

Now when you sent full backtrace - it looks to me like that fbdev
drivers are initialized before pci subsystem in -mm1. Unfortunately,
as proven by i2c, kobjects infrastructure does not like if you reference
non-existing bus type before it is registered. 

Can you try reverting _initcall changes? Although I see no reason
why it should matter, it is clear that pci subsystem is a bit unhappy.
Maybe it is caused by driver or device which is probed before fbdev?
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz

P.S.: And what about change in drivers/pci/probe.c, which does

-  if (base && base <= limit) {
+  if (base <= limit) {


> 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!