Re: [microblaze-uclinux] Power-fail handling

["Jim Law" <jlaw@xxxxxxxxxxxxx>]

Hi John,

I had also found the CHECK_EMERGENCY_SYNC code fragment and it is also 
referenced in uClinux-2.4.x/fs/buffer.c in what looks to be the bdflush 
kernel thread that is supposed to be woken up when you need it to do the 
sync for you.

It looks like the lock_ and unlock_kernel are in the do_emergency_sync() 
function that gets called by the CHECK_EMERGENCY_SYNC code fragment out of 
the bdflush thread when it is woken up.  The only thing that has to run in 
the interrupt is then the wakeup_bdflush() call after the 
emergency_sync_scheduled flag is set.

I'll copy/massage some of the sysrq.c code into our driver that handles the 
core that has the power fail interrupt and see what I get.  In the adapter.c 
for the sysace driver, it seems like the MAJOR_NR is dynamically allocated - 
how do I find the actual major number at run time to include it in the 
is_local_disk() helper function?

Thanks,

Jim


----- Original Message ----- 
From: "John Williams" <jwilliams@xxxxxxxxxxxxxx>
To: <microblaze-uclinux@xxxxxxxxxxxxxx>
Sent: Monday, October 20, 2008 8:41 PM
Subject: Re: [microblaze-uclinux] Power-fail handling


> Hi Jim,
> Jim Law wrote:
>
> > Thanks for the place to look.  I'm in the 2.4 kernel, and it looks like 
> > emergency_sync() doesn't exist in linux/fs.h there.  But I followed your 
> > clue to look in drivers/char/sysrq.c and I see something that looks like 
> > a earlier attempt at a "do_emergency_sync()" in the driver itself.  I'll 
> > study this for a while to see if I can figure out how this function gets 
> > registered to be called back by the bdflush kernel thread.
>
> From a quick scan the mechanism looks like this:
>
> include/linux/sysrq.h defines CHECK_EMERGENCY_SYNC which is a small code 
> fragment to see if the mergency_sync is enabled, and if so vcalls it.
>
> sysrq.c defines the tested variable and the function, as well as some 
> helpers.
>
> The only place in the kernel I find the CHECK_EMERGENCY_SYNC macro 
> referenced is in kernel/panic.c, basically during a kernel panic it chekcs 
> and maybe does a sync.
>
> It seems this fairly generic functionality has been centralised in the 2.6 
> kernel, but you can lift much of the implementation from the sysrq 
> handler.  Note you'll need to tweak the is_local_disk() function to report 
> that SystemACE is indeed a block device worthy of syncing, in the kernel 
> it just does IDE and SCSI drives by the look of it.
>
>
>   Is this
> > likely to be interrupt-safe in your opinion?
>
> Honestly very hard to say.  do_emergency_sync does grab the kernel lock, 
> not sure what will happen if that occurs during interrupt context.
>
> Give it a try with non-critical stuff on the CF card, see what happens. If 
> it's not interrupt safe you'll probably get a BUG() or panic() to tell you 
> so.
>
> Might also be worth floating this past LKML, although not suer how much 
> help you'll get on a 2.4-era question.  uclinux-dev mailing list might 
> also be worth a try.
>
> Cheers,
>
> John
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : 
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/