UBI: why was UBI reboot notifier removed
Artem Bityutskiy
Artem.Bityutskiy at nokia.com
Fri Apr 1 09:34:53 EDT 2011
Hi,
On Wed, 2011-03-30 at 07:43 -0700, Jose Nimni wrote:
> I wanted to ask you a question regarding the change you made in UBI, when you
> removed the UBI reboot notifier. (commit "UBI: remove reboot notifier")
>
> I have omap3530 processor, working with numonyx NOR flashe PF2800AP33EF (intel
> command set).
> I am working with linux omap kernel 2.6.34, but patched it with the newest UBI
> directory (i needed the new patches for NOR PEBs).
>
> i have seen that if i write a lot data to the NOR flash, 2 things happen:
> 1. UBIFS thread are flushing the data to the flash for quite some time.
> 2. ubi_bgt0d is working after that, cleaning up some PEBs.
>
> if i reboot just after the write process returned, the flashed are unmounted
> (after waiting for ubifs to finish flushing).
> but when the sigkills are sent, a UBI error is occuring:
> UBI error: ubi_io_read: error -5 while reading 64 bytes from PEB x:y, read 0
> bytes.
> UBI error: nor_erase_prepare: cannot invalidate PEB X, write returned -5 read
> returned -5
> ....
> ubi_thread: ubi_bgt0d: work failed with error code -5.
OK, reboot notifiers again :-)
About the question why they were removed? I think the primary driver was
that they cause issues with suspend, see here:
http://thread.gmane.org/gmane.linux.drivers.mtd/29143/focus=29681
Kevin provided an excellent description in the corresponding NOR commit
message:
https://groups.google.com/group/fa.linux.kernel/browse_thread/thread/cbe1baeb0cc906f9?fwc=1&hl=en&pli=1
> after some research, i saw that you removed the UBI reboot notifier, that used
> to kill ubi_bgt thread.
> now, during shutdown, the cfi_cmdset_0001.c driver does not allow any
> communication with the flash - but the bgt thread is still alive, so it gets a
> read/write error (-EIO).
Well, in your case these messages are harmless, but I agree that this is
not nice. I think the best way to fix this would be to make the CFI code
return a special error code in this case, e.g., -EBUSY. Then UBI thread
could wait and re-try without printing warnings.
Could you do this?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
More information about the linux-mtd
mailing list