Re: Suggested patch: reset errno after isatty()

[Ketil Froyn <ketil@froyn.name>]

On Wed, Nov 24, 2010 at 8:50 AM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Thu, Nov 18, 2010 at 06:13, Ketil Froyn wrote:
>
> so you'll want to dive into the ioctls to see what isnt working right.
>  strace is your friend.

Thanks for the kick. I had tried that, but for some reason strace was
dying with the error "syscall: unknown syscall trap 0xe8bd8008". A
little more searching now led me to this patch, which fixed it for me:

http://www.fluff.org/ben/patches/strace/strace-fix-arm-bad-syscall.patch

Anyway, here's the full output:

execve("/system/nanddump", ["/system/nanddump", "-f", "/sdcard/dump",
"/dev/mtd/mtd5"], [/* 6 vars */]) = 0
uname({sys="Linux", node="localhost", ...}) = 0
brk(0)                                  = 0x94000
brk(0x94d00)                            = 0x94d00
syscall_983045(0x944c0, 0x917d0, 0xffffffe0, 0x10, 0x92048, 0x8, 0x10,
0xf0005, 0x9185c, 0x4, 0x28, 0x944c0, 0, 0xbeccad00, 0xe474, 0xe484,
0x40000010, 0x944c0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
brk(0xb5d00)                            = 0xb5d00
brk(0xb6000)                            = 0xb6000
open("/sys/class/mtd", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
pivot_root(0x3, "")                     = 384
close(3)                                = 0
open("/sys/class/mtd/mtd0/name", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open("/dev/mtd/mtd5", O_RDONLY|O_LARGEFILE) = 3
stat64("/dev/mtd/mtd5", {st_mode=S_IFCHR|0600, st_rdev=makedev(90,
10), ...}) = 0
open("/dev/mtd/mtd5", O_RDWR|O_LARGEFILE) = 4
ioctl(4, 0x80204d01, 0xbecca978)        = 0
ioctl(4, 0x40084d0b, 0xbecca998)        = 0
close(4)                                = 0
open("/proc/mtd", O_RDONLY|O_LARGEFILE) = 4
read(4, "dev:    size   erasesize  name\nmtd0: 00040000 00020000
\"misc\"\nmtd1: 00500000 00020000 \"recovery\"\nmtd2: 00280000
00020000 \"boot\"\nmtd3: 0aa00000 00020000 \"system\"\nmtd4: 08200000
00020000 \"cache\"\nmtd5: 0a5c0000 00020000 \"userdata\"\n", 4096) =
228
close(4)                                = 0
ioctl(3, 0x80104d12, 0xbeccacfc)        = 0
write(2, "ECC failed: 0\n", 14)         = 14
write(2, "ECC corrected: 0\n", 17)      = 17
write(2, "Number of bad blocks: 0\n", 24) = 24
write(2, "Number of bbt blocks: 0\n", 24) = 24
open("/sdcard/dump", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0644) = 4
ioctl(4, TCGETS or SNDCTL_TMR_TIMEBASE, 0xbecca9ec) = -1 ENOTTY (Not a
typewriter)
write(2, "Block size 131072, page size 2048, OOB size 0\n", 46) = 46
write(2, "Dumping data starting at 0x00000000 and ending at
0x0a5c0000...\n", 64) = 64
ioctl(3, 0x40084d0b, 0xbeccaa48)        = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
read(3, "[snip]"..., 2048) = 2048
ioctl(3, 0x80104d12, 0xbeccacec)        = 0
write(4, "[snip]"..., 2048) = 2048
ioctl(3, 0xc0184d16, 0xbecca9e8)        = -1 ENOTTY (Not a typewriter)
ioctl(3, 0xc00c4d04 <unfinished ...>
+++ killed by SIGSEGV +++

The old version of nanddump (with my patches) works fine on the same
system. It looks like this:

execve("/system/nanddump-old", ["/system/nanddump-old", "-f",
"/sdcard/old-dump", "/dev/mtd/mtd5"], [/* 6 vars */]) = 0
uname({sys="Linux", node="localhost", ...}) = 0
brk(0)                                  = 0x96000
brk(0x96d00)                            = 0x96d00
syscall_983045(0x964c0, 0x92010, 0xffffffe0, 0x10, 0x939a0, 0x8, 0x10,
0xf0005, 0x920c8, 0x4, 0x28, 0x964c0, 0, 0xbeeb6cf0, 0xb0b4, 0xb0c4,
0x40000010, 0x964c0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
brk(0xb7d00)                            = 0xb7d00
brk(0xb8000)                            = 0xb8000
open("/dev/mtd/mtd5", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, 0x80204d01, 0xbeeb6ca4)        = 0
ioctl(3, 0x80104d12, 0xbeeb6cd4)        = 0
write(2, "ECC failed: 0\n", 14)         = 14
write(2, "ECC corrected: 0\n", 17)      = 17
write(2, "Number of bad blocks: 0\n", 24) = 24
write(2, "Number of bbt blocks: 0\n", 24) = 24
open("/sdcard/old-dump", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0644) = 4
ioctl(4, TCGETS or SNDCTL_TMR_TIMEBASE, 0xbeeb6aec) = -1 ENOTTY (Not a
typewriter)
write(2, "Block size 131072, page size 2048, OOB size 56\n", 47) = 47
write(2, "Dumping data starting at 0x00000000 and ending at
0x0a5c0000...\n", 64) = 64
ioctl(3, 0x40084d0b, 0xbeeb6cf0)        = 0
read(3, "[snip]"..., 2048) = 2048
ioctl(3, 0x80104d12, 0xbeeb6cc4)        = 0
write(4, "[snip]"..., 2048) = 2048
ioctl(3, 0xc00c4d04, 0xbeeb6ce4)        = 0
write(4, "[snip]", 56) = 56
read(3, "[snip]"..., 2048) = 2048
ioctl(3, 0x80104d12, 0xbeeb6cc4)        = 0
write(4, "[snip]"..., 2048) = 2048
ioctl(3, 0xc00c4d04, 0xbeeb6ce4)        = 0
write(4, "[snip]", 56) = 56
etc...

>> This particular system appears to use MTD partitioning, maybe
>> redboot(?) or something like that. I haven't had the opportunity to
>> delve into how that works yet - could it be that the partitioning
>> takes 8 bytes of the OOB?
>
> no

Thanks for the clarification. I guess those are the actual physical
parameters, then.

Cheers, Ketil