pmc551 status

Mark Ferrell mferrell at nortelnetworks.com
Mon Oct 25 17:15:46 EDT 1999


Okay .. the kernel panic isn't from anything going wrong w/ the mtd layer .. or
'mostly' isn't going wrong.  I guess that part of the reason the problem exists is
because `mtdblock.o has to be loaded last.  The basic problem is the size of the
pmc551 device.  The PPC system has for BAT registers that as I understand have a max
mapping size of 256M .. only 2 of these registers are reserved for the kernels I/O
space .. so when I remap the PCI memory space it overruns the boundries or some
such.  Thusly .. apon trying to load the mtdblock.o the kernel tries to malloc the
module outside of it's own limits and causes the kernel panic.  Working on trying to
get around this problem on the systems at this time.

"Ferrell, Mark (EXCHANGE:RICH2:2K25)" wrote:

> Yah .. that's the interesting part .. I can write/read to/from the /dev/mtd0 just
> fine from what I can tell, but when I load the mtdblock0 it causes an ugly kernel
> panic.
>
> Anyway .. here is an output of what is going on, though I don't know what extent
> you want me to test /dev/mtd0 at.
>
> [root@(none) /mnt/src/mtd-19990820/kernel]# insmod mtd.o
> [root@(none) /mnt/src/mtd-19990820/kernel]# insmod pmc551.o
> pmc551: Found PCI V370PDC IRQ:11
> pmc551: 256M (0x10000000) of prefetchable memory at 0x90000000
> pmc551: DRAM_BLK3 Flags: RW,On
> pmc551: DRAM_BLK2 Flags: RW,On
> pmc551: DRAM_BLK1 Flags: RW,On
> pmc551: DRAM_BLK0 Flags: RW,On
> pmc551: Memory Access on
> pmc551: I/O Access off
> pmc551: Devsel Fast
> pmc551: Not Fast Back-to-Back
> Registered pmc551 device from 2359296Kb to 2621440Kb
> Mapped from 0xd4005008 to 0xe4005008
>
> [root@(none) /mnt/src/mtd-19990820/kernel]# cd /proc
> [root@(none) /proc]# cat devices
> Character devices:
>   1 mem
>   2 pty
>   3 ttyp
>   4 ttyS
>   5 cua
>  10 misc
>  90 mtd
> 128 ptm
> 136 pts
>
> Block devices:
>   1 ramdisk
>   7 loop
>
> [root@(none) /proc]# cat ksyms > /dev/mtd0
> pmc551: writing 0xc00 to 0xd4005008
> pmc551: writing 0xc00 to 0xd4005c08
> pmc551: writing 0xc00 to 0xd4006808
> pmc551: writing 0xc00 to 0xd4007408
> pmc551: writing 0xc00 to 0xd4008008
> pmc551: writing 0x3d5 to 0xd4008c08
>
> [root@(none) /proc]# /mnt/bin/head -50 /dev/mtd0
> d400304c pmc551_erase   [pmc551]
> d40030d4 pmc551_point   [pmc551]
> d40031d4 pmc551_init    [pmc551]
> d40030f0 pmc551_unpoint [pmc551]
> d4003c90 mymtd  [pmc551]
> d4003164 pmc551_write   [pmc551]
> d40030f4 pmc551_read    [pmc551]
> d4000b58 get_mtd_device [mtd]
> d4000b6c del_mtd_device [mtd]
> d4000c1c register_mtd_notifier  [mtd]
> d4000c68 unregister_mtd_notifier        [mtd]
> d4000aa4 add_mtd_device [mtd]
> d4001090 proc_mtd       [mtd]
> c0003e3c clear_page
> c0007b38 do_signal
> c0009b70 syscall_trace
> c0003000 transfer_to_handler
> c0003b44 int_return
> c0005edc do_IRQ
> c0005504 MachineCheckException
> c0005728 AlignmentException
> c00056a0 ProgramCheckException
> c00056f4 SingleStepException
> c0007548 sys_sigreturn
> c0108070 ppc_n_lost_interrupts
> c00086ac do_lost_interrupts
> c0005bd8 enable_irq
> c0005b8c disable_irq
> c0005b40 disable_irq_nosync
> c0108078 ppc_local_irq_count
> c0108068 ppc_local_bh_count
> c00e86c8 isa_io_base
> c00e86cc isa_mem_base
> c00e86d0 pci_dram_offset
> c010802c ISA_DMA_THRESHOLD
> c010805c DMA_MODE_READ
> c0108044 DMA_MODE_WRITE
> c01080a4 _prep_type
> c0108050 ucSystemType
> c0008778 atomic_add
> c00087a4 atomic_sub
> c00087b8 atomic_inc
> c00087cc atomic_inc_return
> c00087e4 atomic_dec
> c00087f8 atomic_dec_return
> c0008810 atomic_dec_and_test
> c0008d24 set_bit
> c0008d90 clear_bit
> c0008dfc change_bit
> c0008e68 test_and_set_bit
> [root@(none) /proc]# cd /mnt/src/mtd-19990820/kernel/
> [root@(none) /mnt/src/mtd-19990820/kernel]# insmod mtdblock.o
> NIP: C000EE54 XER: 00000000 LR: C0017A20 REGS: cf6b5da0 TRAP: 0300
> MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> TASK = cf6b4000[37] 'insmod' mm->pgd c11f3000 Last syscall: 127
> last math cf6b4000
> GPR00: C0017A08 CF6B5E50 CF6B4000 E4007000 00000000 00000048 E4006FFC 00008000
> GPR08: CF710000 C0110000 00007B49 C0110000 2222222C 01901170 00000000 00000000
> GPR16: 018D2C10 00000000 FFFFFFFF 00000000 00009032 0F6B5E80 00000000 C0003B44
> GPR24: C0003878 00000002 00000001 019002D8 0000080C 00000008 00000008 E4007000
> Call backtrace:
> C0017A08 C00038CC 00000002 0181DFF0 0181B2E0 01814308 0184CFFC
> 00000000
> Kernel panic: kernel access of bad area pc c000ee54 lr c0017a20 address
> E4007007
>
> David Woodhouse wrote:
>
> > mferrell at nortelnetworks.com said:
> > >  And that's it.  It opens the device for a short duration of time ..
> > > but nothing comes forth.  I tried all sortsa fun with noluck.  Any
> > > ideas, suggestions, large bat's to beat the system about the head
> > > with?
> >
> > Hmmm. To test your driver itself, use the character devices, which are what
> > /dev/mtd0 ought to be.
> >
> > When you're sure that's OK, you ought just to be able to load the mtdblock
> > device (after your driver) and use /dev/mtdblock0 too. There may be bugs in
> > the mtdblock code, however.
> >
> > Can you trace and send me the oops that you get if you load mtd, pmc551, then
> > mtdblock in that order?
> >
> > Also, it's worth checking that the mtdblock code actually sets the size of the
> > block device. The kernel might be refusing to pass on any read() requests
> > because we've left the device size set to zero.
> >
> > ----                                ----                                 ----
> > David Woodhouse       David.Woodhouse at mvhi.com      Office: (+44) 1223 810302
> >  Project Leader,    Process Information Systems     Mobile: (+44) 7976 658355
> >     Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
> >              finger dwmw2 at ferret.lmh.ox.ac.uk for PGP key.
>
> --
>  Mark Ferrell  : mferrell at nortelnetworks.com
> (972) 685-7868 : Desk
> (972) 685-4210 : Lab
> (972) 879-4326 : Pager

--
 Mark Ferrell  : mferrell at nortelnetworks.com
(972) 685-7868 : Desk
(972) 685-4210 : Lab
(972) 879-4326 : Pager


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infradead.org/pipermail/linux-mtd/attachments/19991025/9e2d70cf/attachment.html 


More information about the linux-mtd mailing list