* Re: pmc551 status
@ 1999-10-21 7:52 David Woodhouse
1999-10-22 4:24 ` Mark Ferrell
0 siblings, 1 reply; 4+ messages in thread
From: David Woodhouse @ 1999-10-21 7:52 UTC (permalink / raw)
To: Mark Ferrell; +Cc: mtd
mferrell@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@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@ferret.lmh.ox.ac.uk for PGP key.
To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: pmc551 status
1999-10-21 7:52 pmc551 status David Woodhouse
@ 1999-10-22 4:24 ` Mark Ferrell
1999-10-25 21:15 ` Mark Ferrell
0 siblings, 1 reply; 4+ messages in thread
From: Mark Ferrell @ 1999-10-22 4:24 UTC (permalink / raw)
To: David Woodhouse; +Cc: mtd
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@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@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@ferret.lmh.ox.ac.uk for PGP key.
--
Mark Ferrell : mferrell@nortelnetworks.com
(972) 685-7868 : Desk
(972) 685-4210 : Lab
(972) 879-4326 : Pager
To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pmc551 status
1999-10-22 4:24 ` Mark Ferrell
@ 1999-10-25 21:15 ` Mark Ferrell
0 siblings, 0 replies; 4+ messages in thread
From: Mark Ferrell @ 1999-10-25 21:15 UTC (permalink / raw)
To: David Woodhouse, mtd
[-- Attachment #1: Type: text/plain, Size: 5996 bytes --]
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@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@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@ferret.lmh.ox.ac.uk for PGP key.
>
> --
> Mark Ferrell : mferrell@nortelnetworks.com
> (972) 685-7868 : Desk
> (972) 685-4210 : Lab
> (972) 879-4326 : Pager
--
Mark Ferrell : mferrell@nortelnetworks.com
(972) 685-7868 : Desk
(972) 685-4210 : Lab
(972) 879-4326 : Pager
[-- Attachment #2: Type: text/html, Size: 7125 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* pmc551 status
@ 1999-10-21 4:13 Mark Ferrell
0 siblings, 0 replies; 4+ messages in thread
From: Mark Ferrell @ 1999-10-21 4:13 UTC (permalink / raw)
To: mtd
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Anyway, I have what appears to be a very ruff around the edges driver
for the pmc551 cPCI Memory module by Ramix Inc.
The module detects the start address in memory and the onboard DRAM size
and all that crazy stuff and appears to work fairly well all in all.
Unfortunately I am having 'issues' w/ getting the mtdblock layer to work
on it. Is there something special I should do far handling that?
If I load the mtd.o then the pmc551.o then then mtdblock.o I get a
kernel panic
If I load the mtd.o then the mtdblock.o then the pmc551.o everything
appears to work, but /dev/mtd0 is unussable.
Apon cat'ing /dev/mtd0 I get the following kernel messages
mtdblock_open
ok
mtdblock_open
ok
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?
--
Mark Ferrell : mferrell@nortelnetworks.com
(972) 685-7868 : Desk
(972) 685-4210 : Lab
(972) 879-4326 : Pager
[-- Attachment #2: Type: text/html, Size: 1180 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-10-25 21:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-10-21 7:52 pmc551 status David Woodhouse
1999-10-22 4:24 ` Mark Ferrell
1999-10-25 21:15 ` Mark Ferrell
-- strict thread matches above, loose matches on Subject: below --
1999-10-21 4:13 Mark Ferrell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox