Bug 52781 - MTD CFI (Intel StrataFlash) flash access creates I/O errors
Summary: MTD CFI (Intel StrataFlash) flash access creates I/O errors
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: David Woodhouse
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-29 01:13 UTC by Just E
Modified: 2007-04-18 16:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-04-09 09:39:48 UTC
Embargoed:


Attachments (Terms of Use)

Description Just E 2001-08-29 01:13:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.9 i686)

Description of problem:
Using the standard kernel.org kernel and MTD subsystem, I am able to access
the onboard flash module (Intel StrataFlash 28F128J3A) via a custom mapping
driver.
Using the RedHat Roswell 2.4.7 kernel,  access causes I/O errors under
certain conditions.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. modprobe mtdcore, mtdpart, mtdblock, mtdchar, cfi_probe
2. insmod <my_driver_that_works_under_kernel.org_kernel_just_fine>
3. eraseall /dev/mtd/2 (or whatever partition is ~5MB or so)
4. If that does not hang, simply dd any arbitrary data of ~5MB into the
flash partition:
    dd if=/tmp/some_5MB_file.dat of=/dev/mtdblock/2 bs=131072

	

Actual Results:  Towards the end of the block writes, it should fail (not
always, but mostly) with I/O errors.  These errors are returned from
cfi_cmdset_0001.c in do_write_buffer().

Almost always, the userspace program (dd in this case) will hang as well
with status as "Disk Wait" in /proc/pid/status.  It never returns.  Strace
will hang instead of  attaching to this pid.  The system will not sync (I
believe it is pending on block activity).  Halt will not halt, etc, etc.




Expected Results:  There should be no I/O errors, no userland processes
hanging, etc.
Basically, it should work as it does with a kernel.org kernel.



Additional info:

I understand that this issue is complicated by the fact that I am using a
custom mapping driver for our flash access, but I believe it is indicative
of other problems in the kernel.

The severity is listed above normal, as the system does not really recover
from this state-- i.e. cannot reboot, sync, umount, etc, after this error.

Comment 1 Arjan van de Ven 2001-08-29 08:32:06 UTC
every -EIO return value prints something to syslog/dmesg. Can you check which
one it prints ? That might help pinning it down

Comment 2 Just E 2001-08-31 02:06:23 UTC
Kernel and modules built on stock RedHat 7.1 toolchain.

GCC version is:
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)

Annotated output below from userspace hang of dd' command to flash partition:

[ Console output ]
...
mtdblock: write on "module A: Temp" at 0x19f000, size 0x1000
mtdblock: write on "module A: Temp" at 0x1a0000, size 0x1000
mtdblock: writing cached data for "module A: Temp" at 0x180000, size 0x20000
end_request: I/O error, dev 1f:02 (mtdblock), sector 3328

[ stdout output ]
[root@mozart6 rft]# dd if=/mnt/flashdisk.bin of=/dev/mtdblock/2 bs=131072
51+1 records in
51+1 records out
<hangs here>

[ PS Listing w/WCHAN entry ]
805 root       9   0   580  580   504 c01475f6 D     0.0  0.1   0:00 dd

[ /proc/ksyms entry related to WCHAN above]
c0147040 init_private_file_Rsmp_094d10c7
c01470b0 fput_Rsmp_b03d026c
c01471f0 fget_Rsmp_ee274bab
c0147260 put_filp_Rsmp_eb4d9151
c01473d0 file_moveto_Rsmp_345af75b
c0147580 __wait_on_buffer_Rsmp_a44e575e      <--- hung here (?)
c0147a20 fsync_no_super_Rsmp_57520644



Comment 3 David Woodhouse 2004-04-09 09:39:48 UTC
Closing because 2.4.7 is far too ancient to be concerned about. The
Intel flash chip driver has basically been rewritten since then.

If you can still reproduce this in 2.4.2x or 2.6 kernels, please do so
with the /dev/mtd2 character device -- by writing to it and/or using
ioctl(MEMERASE) on it. Report the error messages you see and the
return code from the write() or ioctl() system calls. 


Note You need to log in before you can comment on or make changes to this bug.