MTD Partition problems

MTD Partition problems

[Malik, Vipin [FRCO/HOU]]

Hi Folks,

I'm just getting back into playing with this.

Is there something broken with the mtd partitioning code?

I defined 3 mtd partitions on one 8MB flash. The partitions look fine on the
debug log and a "cat /proc/mtd" shows three devices with the proper sizes
and names as defined in my "mtd_partition" map structure in my map file.

However, it seems that 6 mtd partitions have been added (even though just 3
show up in /proc/mtd)!

Each of mtd[0,1], mtd[2,3] and mtd[4,5] pairs point to partitions 1,2&3
respectively. Each of the pairs point to the same partitions (have the same
stuff in them).

However mtdblock0,1,2 point to the correct partitions!

And I've checked that my /dev/mtd0,1,2,3,4,5 devices are pointing to char
devices 30,1...5

Any clues?

Vipin
 

Re: MTD Partition problems

[Jörn Engel]

On Fri, 2 August 2002 16:59:07 -0500, Malik, Vipin [FRCO/HOU] wrote:
> I'm just getting back into playing with this.
> 
> Is there something broken with the mtd partitioning code?

Not really broken, but maybe useless.

> I defined 3 mtd partitions on one 8MB flash. The partitions look fine on the
> debug log and a "cat /proc/mtd" shows three devices with the proper sizes
> and names as defined in my "mtd_partition" map structure in my map file.
> 
> However, it seems that 6 mtd partitions have been added (even though just 3
> show up in /proc/mtd)!
> 
> Each of mtd[0,1], mtd[2,3] and mtd[4,5] pairs point to partitions 1,2&3
> respectively. Each of the pairs point to the same partitions (have the same
> stuff in them).

One device of each pair is read-only. This is by design and scheduled
to be ripped out sometime.

David, 2.4.19 is released, but I am right in my exam period. Does end
of August and/or beginning of September sound ok for the merge?

Jörn

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth

Re: MTD Partition problems

[Vipin Malik]

At 11:46 AM 8/3/2002 +0200, Jörn Engel wrote:
>On Fri, 2 August 2002 16:59:07 -0500, Malik, Vipin [FRCO/HOU] wrote:
> > I'm just getting back into playing with this.
> >
> > Is there something broken with the mtd partitioning code?
>
>Not really broken, but maybe useless.


Hmm, useless as in "that functionality has been depricated- a better way is 
available- use <state better way here>" or useless as in "it's good stuff 
but currently not working".

I am (almost) sure that it was working and allowed me to setup different 
read/write partitions on the same flash chip (about 9-12 months ago).



> > I defined 3 mtd partitions on one 8MB flash. The partitions look fine 
> on the
> > debug log and a "cat /proc/mtd" shows three devices with the proper sizes
> > and names as defined in my "mtd_partition" map structure in my map file.
> >
> > However, it seems that 6 mtd partitions have been added (even though just 3
> > show up in /proc/mtd)!
> >
> > Each of mtd[0,1], mtd[2,3] and mtd[4,5] pairs point to partitions 1,2&3
> > respectively. Each of the pairs point to the same partitions (have the same
> > stuff in them).
>
>One device of each pair is read-only. This is by design and scheduled
>to be ripped out sometime.


Sorry for the stupid question: If it's by design, why is it going to be 
ripped out sometime soon?


>David, 2.4.19 is released, but I am right in my exam period. Does end
>of August and/or beginning of September sound ok for the merge?


Should I be using the main CVS code or some branch. The above was with 
2.4.19-rc3.

Thanks

Vipin
P.S. I noticed that my original mail did show up, but not at work. Hmmm. 
Sorry for the duplicate post.



>Jörn
>
>--
>Beware of bugs in the above code; I have only proved it correct, but
>not tried it.
>-- Donald Knuth
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: MTD Partition problems

[Jörn Engel]

On Sat, 3 August 2002 07:47:11 -0500, Vipin Malik wrote:
> >> Is there something broken with the mtd partitioning code?
> >
> >Not really broken, but maybe useless.
> 
> Hmm, useless as in "that functionality has been depricated- a better way is 
> available- use <state better way here>" or useless as in "it's good stuff 
> but currently not working".

Useless as in useless, really. Functionality is added, that is
available anyway.

> >One device of each pair is read-only. This is by design and scheduled
> >to be ripped out sometime.
> 
> Sorry for the stupid question: If it's by design, why is it going to be 
> ripped out sometime soon?

It might have made sense, when it was designed. It might just have
been a relatively new developer making the usual mistakes. Whatever.

Fact is that it is useless, the superuser can create a read only
device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
those extra devices do, except for causing confusion and eating up
minor numbers.

People would get even more confused when suddenly the device nodes
have different behaviour, which will definitely happen as soon as the
ro-devices are gone. But I have some patches in my queue that will
create confusion anyway. You do the math.

> >David, 2.4.19 is released, but I am right in my exam period. Does end
> >of August and/or beginning of September sound ok for the merge?
> 
> Should I be using the main CVS code or some branch. The above was with 
> 2.4.19-rc3.

Currently, there is no branch that tackles this problem. There was
one, but David never took a look, was busy, and rescheduled to 'when
2.4.19 is out'. Now I am busy,...

Jörn

-- 
Public Domain  - Free as in Beer
General Public - Free as in Speech
BSD License    - Free as in Enterprise
Shared Source  - Free as in "Work will make you..."

Re: MTD Partition problems

[Vipin Malik]

> >
> > Sorry for the stupid question: If it's by design, why is it going to be
> > ripped out sometime soon?
>
>It might have made sense, when it was designed. It might just have
>been a relatively new developer making the usual mistakes. Whatever.
>
>Fact is that it is useless, the superuser can create a read only
>device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
>those extra devices do, except for causing confusion and eating up
>minor numbers.

So if I read you correctly, you are saying that the partitioning code 
really works but in a quirky way: the presence of duplicate read only 
paired devices, which really provide no useful functionality.

However, if one ignores the duplicated devices, one can still use 
partitioning and mount a JFFS2 fs on one of the partitions while having 
something completely different on another and device access locking will be 
taken care of by the mtd driver (which is essentially what partitioning 
provides vs. just calling add_mtd() NUM_PARTITION times in your map file on 
the same flash chip).

Additionally, (say) /dev/mtdblock2 will really provide a handle to 
/dev/mtd4 the writable third partition on the partitioned flash chip, thus 
mounting the JFFS2 fs on the partition originally intended (the third 
partition).

Unfortunately, my tests indicate that this is not happening. I know that 
/dev/mtdblock2 (the intended third partition) is formatted. However JFFS2 
finds data here and refuses to mount on it. I think it is really being 
passes a handle to and accesses /dev/mtd2, which is the wrong partition.

/dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and /dev/mtd4 
is the correct partition that I want!

Argh! I'll try your patches if you like.

Thanks for your answers.

Vipin




>People would get even more confused when suddenly the device nodes
>have different behaviour, which will definitely happen as soon as the
>ro-devices are gone. But I have some patches in my queue that will
>create confusion anyway. You do the math.
>
> > >David, 2.4.19 is released, but I am right in my exam period. Does end
> > >of August and/or beginning of September sound ok for the merge?
> >
> > Should I be using the main CVS code or some branch. The above was with
> > 2.4.19-rc3.
>
>Currently, there is no branch that tackles this problem. There was
>one, but David never took a look, was busy, and rescheduled to 'when
>2.4.19 is out'. Now I am busy,...
>
>Jörn
>
>--
>Public Domain  - Free as in Beer
>General Public - Free as in Speech
>BSD License    - Free as in Enterprise
>Shared Source  - Free as in "Work will make you..."
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: MTD Partition problems

[Jörn Engel]

On Sat, 3 August 2002 14:24:32 -0500, Vipin Malik wrote:
> >Fact is that it is useless, the superuser can create a read only
> >device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
> >those extra devices do, except for causing confusion and eating up
> >minor numbers.
> 
> So if I read you correctly, you are saying that the partitioning code 
> really works but in a quirky way: the presence of duplicate read only 
> paired devices, which really provide no useful functionality.

Yes.

> However, if one ignores the duplicated devices, one can still use 
> partitioning and mount a JFFS2 fs on one of the partitions while having 
> something completely different on another and device access locking will be 
> taken care of by the mtd driver (which is essentially what partitioning 
> provides vs. just calling add_mtd() NUM_PARTITION times in your map file on 
> the same flash chip).

Yes. The partitioning code basically checks the limits and hands the
work to the base device with adjusted offset.

> Additionally, (say) /dev/mtdblock2 will really provide a handle to 
> /dev/mtd4 the writable third partition on the partitioned flash chip, thus 
> mounting the JFFS2 fs on the partition originally intended (the third 
> partition).

Almost. /dev/mtd4 should be minor number 8. If you check
/usr/src/linux/Documentation/devices.txt, you will read the following:
                  0 = /dev/mtd0         First MTD (rw)
                  1 = /dev/mtdr0        First MTD (ro)
Thus mtd0 has minor 0, mtd1 has minor 2, ...

Also, the third partition is /dev/mtd3, as /dev/mtd0 is the real
device. Look at the minor numbers for /dev/hda*, just the same.

But what you *meant* is correct.

> Unfortunately, my tests indicate that this is not happening. I know that 
> /dev/mtdblock2 (the intended third partition) is formatted. However JFFS2 
> finds data here and refuses to mount on it. I think it is really being 
> passes a handle to and accesses /dev/mtd2, which is the wrong partition.

See above.

> /dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and /dev/mtd4 
> is the correct partition that I want!

See above.

> Argh! I'll try your patches if you like.

I would be happy if you did. But you don't need my patches, unless you
have more than one device that you want to partition. With the two
thinkos out of the way, you should be doing fine. :)

Jörn

-- 
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens

Re: MTD Partition problems

[Vipin Malik]

> > Additionally, (say) /dev/mtdblock2 will really provide a handle to
> > /dev/mtd4 the writable third partition on the partitioned flash chip, thus
> > mounting the JFFS2 fs on the partition originally intended (the third
> > partition).
>
>Almost. /dev/mtd4 should be minor number 8. If you check
>/usr/src/linux/Documentation/devices.txt, you will read the following:
>                   0 = /dev/mtd0         First MTD (rw)
>                   1 = /dev/mtdr0        First MTD (ro)
>Thus mtd0 has minor 0, mtd1 has minor 2, ...
>
>Also, the third partition is /dev/mtd3, as /dev/mtd0 is the real
>device. Look at the minor numbers for /dev/hda*, just the same.
>
>But what you *meant* is correct.
>
> > Unfortunately, my tests indicate that this is not happening. I know that
> > /dev/mtdblock2 (the intended third partition) is formatted. However JFFS2
> > finds data here and refuses to mount on it. I think it is really being
> > passes a handle to and accesses /dev/mtd2, which is the wrong partition.
>
>See above.


Well, I think there is still a problem somewhere. Regardless of which 
/dev/mtd<n> device is the actual physical partition (that was a good 
academic discussion), JFFS2 never gets passed the /dev/mtd<n> device by me- 
only the /dev/mtdblock<n> device.

I can do a 'less -f /dev/mtdblock2' and see that's the partition that I 
want to mount JFFS2 on (it's all formatted correctly). However, a 'mount -t 
jffs2 /dev/mtdblock2 /mnt/flash' fails as JFFS2 sees a bunch of data to 
whichever mtd device handle its been passed (by mtdblock2) and refuses to 
mount as it cannot find any valid JFFS2 nodes there.

Vipin



> > /dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and 
> /dev/mtd4
> > is the correct partition that I want!
>
>See above.
>
> > Argh! I'll try your patches if you like.
>
>I would be happy if you did. But you don't need my patches, unless you
>have more than one device that you want to partition. With the two
>thinkos out of the way, you should be doing fine. :)
>
>Jörn
>
>--
>Mundie uses a textbook tactic of manipulation: start with some
>reasonable talk, and lead the audience to an unreasonable conclusion.
>-- Bruce Perens
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: MTD Partition problems

[Jörn Engel]

On Mon, 5 August 2002 14:10:24 -0500, Vipin Malik wrote:
> Well, I think there is still a problem somewhere. Regardless of which 
> /dev/mtd<n> device is the actual physical partition (that was a good 
> academic discussion), JFFS2 never gets passed the /dev/mtd<n> device by me- 
> only the /dev/mtdblock<n> device.

I fail to see what was academic about that discussion. Is it academic,
if you pass /dev/hda1 (empty partition) or /dev/hda (whole disk with
root partition) to mke2fs? Try it and tell me again. :-)

> I can do a 'less -f /dev/mtdblock2' and see that's the partition that I 
> want to mount JFFS2 on (it's all formatted correctly). However, a 'mount -t 
> jffs2 /dev/mtdblock2 /mnt/flash' fails as JFFS2 sees a bunch of data to 
> whichever mtd device handle its been passed (by mtdblock2) and refuses to 
> mount as it cannot find any valid JFFS2 nodes there.

If it was formatted correctly, it should get mounted. But I have no
idea, what "it's all formatted correctly" or "JFFS2 sees a bunch of
data" means. Try doing a trivial format (eraseall /dev/mtd<n>) and
mount that. If that fails, show me that the partition has all 0xff and
the jffs2 messages and I will have a look. Until then, I consider this
to be pebkac.

Jörn

-- 
There's nothing better for promoting creativity in a medium than
making an audience feel "Hmm ­ I could do better than that!"
-- Douglas Adams in a slashdot interview

Re: MTD Partition problems

[Vipin Malik]

>
> > However, if one ignores the duplicated devices, one can still use
> > partitioning and mount a JFFS2 fs on one of the partitions while having
> > something completely different on another and device access locking 
> will be
> > taken care of by the mtd driver (which is essentially what partitioning
> > provides vs. just calling add_mtd() NUM_PARTITION times in your map 
> file on
> > the same flash chip).
>
>Yes. The partitioning code basically checks the limits and hands the
>work to the base device with adjusted offset.
>
> > Additionally, (say) /dev/mtdblock2 will really provide a handle to
> > /dev/mtd4 the writable third partition on the partitioned flash chip, thus
> > mounting the JFFS2 fs on the partition originally intended (the third
> > partition).
>
>Almost. /dev/mtd4 should be minor number 8. If you check
>/usr/src/linux/Documentation/devices.txt, you will read the following:
>                   0 = /dev/mtd0         First MTD (rw)
>                   1 = /dev/mtdr0        First MTD (ro)
>Thus mtd0 has minor 0, mtd1 has minor 2, ...
>
>Also, the third partition is /dev/mtd3, as /dev/mtd0 is the real
>device. Look at the minor numbers for /dev/hda*, just the same.


I got the JFFS2 to mount on /dev/mtdblock2 (most of the partition was 
erased. I must have passed the wrong size to the mtd_debug erase. There was 
some garbage at the end).

Anyway, thanks for the explanations.

Vipin


>But what you *meant* is correct.
>
> > Unfortunately, my tests indicate that this is not happening. I know that
> > /dev/mtdblock2 (the intended third partition) is formatted. However JFFS2
> > finds data here and refuses to mount on it. I think it is really being
> > passes a handle to and accesses /dev/mtd2, which is the wrong partition.
>
>See above.
>
> > /dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and 
> /dev/mtd4
> > is the correct partition that I want!
>
>See above.
>
> > Argh! I'll try your patches if you like.
>
>I would be happy if you did. But you don't need my patches, unless you
>have more than one device that you want to partition. With the two
>thinkos out of the way, you should be doing fine. :)
>
>Jörn
>
>--
>Mundie uses a textbook tactic of manipulation: start with some
>reasonable talk, and lead the audience to an unreasonable conclusion.
>-- Bruce Perens
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: MTD Partition problems

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
> > Sorry for the stupid question: If it's by design, why is it going to
> > be ripped out sometime soon?

> It might have made sense, when it was designed. It might just have
> been a relatively new developer making the usual mistakes. Whatever.

> Fact is that it is useless, the superuser can create a read only
> device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
> those extra devices do, except for causing confusion and eating up
> minor numbers. 

I inherited the major number from elsewhere, and it was already set up like 
that. I haven't changed it because people have only just started to read 
the bloody documentation and set it up right -- with the occasional 
exception :)

>  Currently, there is no branch that tackles this problem. There was
> one, but David never took a look, was busy, and rescheduled to 'when
> 2.4.19 is out'. Now I am busy,...

I want to get the remaining changes in the tree into 2.4.20-pre, then 
update the code for 2.5 and start doing new exciting stuff. 

--
dwmw2

Disk blocks for long periods

[Joakim Tjernlund]

Hi 

I have noticed that if i copy a "big" file(580K) it sometimes take up to 42 seconds before
it's finished. Normally it takes about 3-4 seconds. When this long copy happen, top reports
that kupdate and the copy(cp) process is in D state, the rest is sleeping.
The FS is a 45% usage. FS is about 63MB in size. Using the stable branch.

Why does it block for so long time?

Also, if I fill the FS up to 100% and later reboots, it kan take 10-15 minutes before
init starts to run. The root fs mount takes about 20 seconds and the system just
stops between the last message from the kernel and when init prints its version.

It is just the first reboot after I fill the FS, once I have gotten past the first reboot and
reboots again, things are back to normal.

Any ideas?

   Jocke

Re: Disk blocks for long periods

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I have noticed that if i copy a "big" file(580K) it sometimes take up
> to 42 seconds before it's finished. Normally it takes about 3-4
> seconds. When this long copy happen, top reports that kupdate and the
> copy(cp) process is in D state, the rest is sleeping. The FS is a 45%
> usage. FS is about 63MB in size. Using the stable branch.

> Why does it block for so long time?

Dunno. What's it doing? Where are cp and kupdate sleeping? (SysRq-T).

>  Also, if I fill the FS up to 100% and later reboots, it kan take
> 10-15 minutes before init starts to run. The root fs mount takes about
> 20 seconds and the system just stops between the last message from the
> kernel and when init prints its version.

> It is just the first reboot after I fill the FS, once I have gotten
> past the first reboot and reboots again, things are back to normal. 

More logs and SysRq-T required. Sounds like it's erasing blocks and for 
some reason not allowing anything else to happen while it's doing it.

--
dwmw2

RE: Disk blocks for long periods

[Joakim Tjernlund]

> joakim.tjernlund@lumentis.se said:
> >  I have noticed that if i copy a "big" file(580K) it sometimes take up
> > to 42 seconds before it's finished. Normally it takes about 3-4
> > seconds. When this long copy happen, top reports that kupdate and the
> > copy(cp) process is in D state, the rest is sleeping. The FS is a 45%
> > usage. FS is about 63MB in size. Using the stable branch.
> 
> > Why does it block for so long time?
> 
> Dunno. What's it doing? Where are cp and kupdate sleeping? (SysRq-T).

I am on PPC and SysRq-T does not display anything useful :-(
Perhaps readprofile?

> 
> >  Also, if I fill the FS up to 100% and later reboots, it kan take
> > 10-15 minutes before init starts to run. The root fs mount takes about
> > 20 seconds and the system just stops between the last message from the
> > kernel and when init prints its version.
> 
> > It is just the first reboot after I fill the FS, once I have gotten
> > past the first reboot and reboots again, things are back to normal. 
> 
> More logs and SysRq-T required. Sounds like it's erasing blocks and for 
> some reason not allowing anything else to happen while it's doing it.

Perhaps kupdate is holding some VFS specific block? I am on a MV 2.4.2 kernel 

> 
> --
> dwmw2
> 
> 
> 

Re: Disk blocks for long periods

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I am on PPC and SysRq-T does not display anything useful :-( Perhaps
> readprofile?

SysRq-T should work on PPC. It's mostly generic code. What's wrong with it?

The profile _may_ help but it's most likely to tell us that the CPU spend
most time sleeping, without actually telling us _where_ each process was
sleeping.

>  Perhaps kupdate is holding some VFS specific block? I am on a MV
> 2.4.2 kernel 

I'd care more if you could reproduce it with something a little more 
recent. I'm assuming you're using v1.100 of cfi_cmdset_0001.c, since you 
committed that change.


--
dwmw2

RE: Disk blocks for long periods

[Joakim Tjernlund]

> 
> joakim.tjernlund@lumentis.se said:
> >  I am on PPC and SysRq-T does not display anything useful :-( Perhaps
> > readprofile?
> 
> SysRq-T should work on PPC. It's mostly generic code. What's wrong with it?
Maybe I spoke too soon, but I can not make sense of it:
SysRq: Show State                                                               
                                                                                
                         free                        sibling                    
  task             PC    stack   pid father child younger older                 
init      S 0FF86418     0     1      0   159  (NOTLB)                          
keventd   S 00000000     0     2      1        (L-TLB)       3                  
kswapd    S 00000000     0     3      1        (L-TLB)       4     2            
kreclaimd  S 00000000     0     4      1        (L-TLB)       5     3           
bdflush   S 00000000     0     5      1        (L-TLB)       6     4            
kupdate   D 00000000     0     6      1        (L-TLB)       7     5            
mtdblockd  S 00000000     0     7      1        (L-TLB)       8     6           
jffs2_gcd_mtd4  S 00000000     0     8      1        (L-TLB)      51     7      
syslogd   S 0FF86418    28    51      1        (NOTLB)      53     8            
klogd     R 0FF7EB04   144    53      1        (NOTLB)      58    51            
inetd     S 0FF86418     0    58      1   163  (NOTLB)      72    53            
te_server  S 0FF42A84     0    72      1        (NOTLB)      75    58           
te_log    S 0FF3C418    28    75      1        (NOTLB)      77    72            
te        S 0FF3C418     0    77      1        (NOTLB)      79    75            
ntpd      S 0FDE4418     0    79      1        (NOTLB)      81    77
alib_psupd  S 0FED6418     0    81      1        (NOTLB)      83    79          
icn_server  S 0FF18418     0    83      1        (NOTLB)      85    81          
cp_cm     S 0FED6418     0    85      1        (NOTLB)      87    83            
cp_cop    S 0FED6418     0    87      1        (NOTLB)      89    85            
cp_pbh    S 0FED6418     0    89      1        (NOTLB)      91    87            
alib_swusd  S 0FED6418     0    91      1        (NOTLB)      93    89          
mgmt_named  S 0FEAC418     0    93      1        (NOTLB)      95    91          
mgmt_invd  S 0FD6A418  3520    95      1        (NOTLB)      97    93           
eq_rh     S 0FD6A418     0    97      1        (NOTLB)      99    95            
mgmt_pmd  S 0FC45418     0    99      1        (NOTLB)     101    97            
eq_bh_superviso  S 0FE3E418  3520   101      1        (NOTLB)     103    99     
eq_bh     S 0FE3E418     0   103      1        (NOTLB)     105   101            
mgmt_backupd  S 0FC45418  3520   105      1        (NOTLB)     107   103        
mgmt_alarmd  S 0FD6A418   124   107      1        (NOTLB)     109   105         
tosv_server  S 0FED6418     0   109      1        (NOTLB)     111   107         
tosv_supervisor  S 0FED6418     0   111      1        (NOTLB)     113   109     
snmpd     S 0FB4B418     8   113      1   161  (NOTLB)     115   111            
sys_sysconfd  S 0FD6A418  3168   115      1        (NOTLB)     117   113        
sys_ipconfd  S 0FD6A418     0   117      1        (NOTLB)     120   115         
umi_sim   S 0FED6418    76   120      1        (NOTLB)     122   117            
uxi_sim   S 0FED6418     0   122      1        (NOTLB)     124   120            
upi_sim   S 0FED6418     0   124      1        (NOTLB)     126   122            
cp_sim    S 0FED6418   260   126      1        (NOTLB)     128   124            
eq_tm_mgr  S 0FD6A418     0   128      1        (NOTLB)     130   126
eq_mxm_mgr  S 0FD6A418     0   130      1        (NOTLB)     132   128          
eq_gbem_mgr  S 0FD6A418    24   132      1        (NOTLB)     134   130         
eq_xm_mgr  S 0FD6A418     0   134      1        (NOTLB)     136   132           
eq_cpm_mgr  S 0FD6A418     4   136      1   160  (NOTLB)     138   134          
eq_pbm_mgr  S 0FD6A418     4   138      1        (NOTLB)     140   136          
eq_bm_mgr  S 0FD6A418     0   140      1        (NOTLB)     142   138           
eq_topm_mgr  S 0FD6A418     0   142      1        (NOTLB)     144   140         
eq_spfm_mgr  S 0FD6A418  3136   144      1        (NOTLB)     146   142         
eq_pm_mgr  S 0FD6A418     0   146      1        (NOTLB)     148   144           
ne_swumd  S 0FED6418     0   148      1        (NOTLB)     150   146            
ne_rc     S 0FED6418   428   150      1        (NOTLB)     152   148            
ne_rc_superviso  S 0FF3C418     0   152      1        (NOTLB)     154   150     
pppd      S 0FF86418   152   154      1        (NOTLB)     156   152            
zebra     S 0FD29418   128   156      1        (NOTLB)     158   154            
ospfd     S 0FD97418  3520   158      1        (NOTLB)     159   156            
bash      S 0FEC35AC   416   159      1   181  (NOTLB)           158            
eq_cpm_child  S 0FD6A418    68   160    136        (NOTLB)                      
snmpd     S 0FB51B84     0   161    113   162  (NOTLB)                          
snmpd     S 0FAB3370     0   162    161        (NOTLB)                          
in.telnetd  S 0FF64418     0   163     58   164  (NOTLB)                        
bash      S 0FEE0B04     0   164    163        (NOTLB)                          
bash      S 0FEC35AC  3156   180    159   182  (NOTLB)     181                  
cp        D 0FF7EB14  2868   181    159        (NOTLB)           180            
cp        D 0FF7EB14  1996   182    180        (NOTLB)



> 
> The profile _may_ help but it's most likely to tell us that the CPU spend
> most time sleeping, without actually telling us _where_ each process was
> sleeping.
> 
> >  Perhaps kupdate is holding some VFS specific block? I am on a MV
> > 2.4.2 kernel 
> 
> I'd care more if you could reproduce it with something a little more 
> recent. I'm assuming you're using v1.100 of cfi_cmdset_0001.c, since you 
> committed that change.
> 

Sorry, but It's a major job to upgrade our kernel, so that will have to wait.
No, I am not running the v1.100 of cfi_cmdset_0001.c but I have made sure that
the relevant fixes are in.

When I last looked(many months ago) there was no 2.4 branch of the MTD layer and there
was much NAND activity so I kept the one I had. Is the latest CVS of drivers/mtd the stable one?
Is it in 2.4.19?

   Jocke 

Re: Disk blocks for long periods

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> > SysRq-T should work on PPC. It's mostly generic code. What's wrong
> > with it? 

> Maybe I spoke too soon, but I can not make sense of it:

That's because you're using 2.4.2. A newer kernel would print the relevant 
call trace from the kernel stack too, and we'd be able to see what kernel 
function(s) it's sleeping in.

--
dwmw2

Re: Disk blocks for long periods

[Jasmine Strong]

On Monday, August 5, 2002, at 03:42 PM, David Woodhouse wrote:

>
> joakim.tjernlund@lumentis.se said:
>>> SysRq-T should work on PPC. It's mostly generic code. What's wrong
>>> with it?
>
>> Maybe I spoke too soon, but I can not make sense of it:
>
> That's because you're using 2.4.2.

...2.4.2 was the last-but-one Redwood PPC kernel release from Montavista;
they have a 2.4.17 out now which is much more stable and faster.

On the 2.4.2 kernel we had lots of odd little problems with stuff like
this that Just Went Away with 2.4.17.

(in ppc405gp land) Jas.