Re: HELP!!! SD and suspend damage i-node.
Hi! > Suspend damage filesystem each times on 4G SD. > I use bluetooth. But corruption doesn't depend on it. > I also test 2.6.21-rc4-git7 kernel. The same problem. > 512Mb SD works normal. Try using smaller filesystem on 4G SD, and be sure to CC SD/MMC maintainer next time. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
Hi! Suspend damage filesystem each times on 4G SD. I use bluetooth. But corruption doesn't depend on it. I also test 2.6.21-rc4-git7 kernel. The same problem. 512Mb SD works normal. Try using smaller filesystem on 4G SD, and be sure to CC SD/MMC maintainer next time. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
Suspend damage filesystem each times on 4G SD. I use bluetooth. But corruption doesn't depend on it. I also test 2.6.21-rc4-git7 kernel. The same problem. 512Mb SD works normal. Pavel Machek wrote: > Hi! > >> I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 >> (PXA255). >> After suspend/resume filesystem stay clean. But some i-nodes become broken. >> Some files looks like block device or pipe with strange permissions, owner >> etc. >> I'm sure that there is no bad blocks on SD. >> I'll send any additional information. Just say me what you need to help me. >> I had i lot of tries. Apply patches, remove its, change fstype etc. >> output of fsck -f > > How repeatable is the corruption? I have c3000 here, and it corrupts > memory during system, say during one in 5 suspends. Longer suspends > seem to lead to 'more' corruption. > > It did not damage my filesystem, yet. > > Do you use bluetooth? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
Suspend damage filesystem each times on 4G SD. I use bluetooth. But corruption doesn't depend on it. I also test 2.6.21-rc4-git7 kernel. The same problem. 512Mb SD works normal. Pavel Machek wrote: Hi! I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 (PXA255). After suspend/resume filesystem stay clean. But some i-nodes become broken. Some files looks like block device or pipe with strange permissions, owner etc. I'm sure that there is no bad blocks on SD. I'll send any additional information. Just say me what you need to help me. I had i lot of tries. Apply patches, remove its, change fstype etc. output of fsck -f How repeatable is the corruption? I have c3000 here, and it corrupts memory during system, say during one in 5 suspends. Longer suspends seem to lead to 'more' corruption. It did not damage my filesystem, yet. Do you use bluetooth? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
Hi! > I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 > (PXA255). > After suspend/resume filesystem stay clean. But some i-nodes become broken. > Some files looks like block device or pipe with strange permissions, owner > etc. > I'm sure that there is no bad blocks on SD. > I'll send any additional information. Just say me what you need to help me. > I had i lot of tries. Apply patches, remove its, change fstype etc. > output of fsck -f How repeatable is the corruption? I have c3000 here, and it corrupts memory during system, say during one in 5 suspends. Longer suspends seem to lead to 'more' corruption. It did not damage my filesystem, yet. Do you use bluetooth? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
Hi! I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 (PXA255). After suspend/resume filesystem stay clean. But some i-nodes become broken. Some files looks like block device or pipe with strange permissions, owner etc. I'm sure that there is no bad blocks on SD. I'll send any additional information. Just say me what you need to help me. I had i lot of tries. Apply patches, remove its, change fstype etc. output of fsck -f How repeatable is the corruption? I have c3000 here, and it corrupts memory during system, say during one in 5 suspends. Longer suspends seem to lead to 'more' corruption. It did not damage my filesystem, yet. Do you use bluetooth? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
On Friday, 23 March 2007 12:25, Sergey Smirnov wrote: > It's happen only with 4G SD. I made the same test in 512Mb SD. > After suspend/resume there is no errors on fs. > > If I resume PDA with 4G SD it go back to suspend after few seconds. Well, I believe the problem is related to the SD driver (maintainer added to the Cc list) or to the zaurus-specific code. Rafael > Rafael J. Wysocki wrote: > > On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote: > >> I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 > >> (PXA255). > >> After suspend/resume filesystem stay clean. But some i-nodes become broken. > >> Some files looks like block device or pipe with strange permissions, owner > >> etc. > >> I'm sure that there is no bad blocks on SD. > >> I'll send any additional information. Just say me what you need to help me. > >> I had i lot of tries. Apply patches, remove its, change fstype etc. > >> output of fsck -f > > > > I assume this is the suspend to RAM? > > > > Rafael > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
It's happen only with 4G SD. I made the same test in 512Mb SD. After suspend/resume there is no errors on fs. If I resume PDA with 4G SD it go back to suspend after few seconds. Rafael J. Wysocki wrote: > On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote: >> I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 >> (PXA255). >> After suspend/resume filesystem stay clean. But some i-nodes become broken. >> Some files looks like block device or pipe with strange permissions, owner >> etc. >> I'm sure that there is no bad blocks on SD. >> I'll send any additional information. Just say me what you need to help me. >> I had i lot of tries. Apply patches, remove its, change fstype etc. >> output of fsck -f > > I assume this is the suspend to RAM? > > Rafael > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
It's happen only with 4G SD. I made the same test in 512Mb SD. After suspend/resume there is no errors on fs. If I resume PDA with 4G SD it go back to suspend after few seconds. Rafael J. Wysocki wrote: On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote: I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 (PXA255). After suspend/resume filesystem stay clean. But some i-nodes become broken. Some files looks like block device or pipe with strange permissions, owner etc. I'm sure that there is no bad blocks on SD. I'll send any additional information. Just say me what you need to help me. I had i lot of tries. Apply patches, remove its, change fstype etc. output of fsck -f I assume this is the suspend to RAM? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
On Friday, 23 March 2007 12:25, Sergey Smirnov wrote: It's happen only with 4G SD. I made the same test in 512Mb SD. After suspend/resume there is no errors on fs. If I resume PDA with 4G SD it go back to suspend after few seconds. Well, I believe the problem is related to the SD driver (maintainer added to the Cc list) or to the zaurus-specific code. Rafael Rafael J. Wysocki wrote: On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote: I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 (PXA255). After suspend/resume filesystem stay clean. But some i-nodes become broken. Some files looks like block device or pipe with strange permissions, owner etc. I'm sure that there is no bad blocks on SD. I'll send any additional information. Just say me what you need to help me. I had i lot of tries. Apply patches, remove its, change fstype etc. output of fsck -f I assume this is the suspend to RAM? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP!!! SD and suspend damage i-node.
On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote: > I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 > (PXA255). > After suspend/resume filesystem stay clean. But some i-nodes become broken. > Some files looks like block device or pipe with strange permissions, owner > etc. > I'm sure that there is no bad blocks on SD. > I'll send any additional information. Just say me what you need to help me. > I had i lot of tries. Apply patches, remove its, change fstype etc. > output of fsck -f I assume this is the suspend to RAM? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HELP!!! SD and suspend damage i-node.
I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 (PXA255). After suspend/resume filesystem stay clean. But some i-nodes become broken. Some files looks like block device or pipe with strange permissions, owner etc. I'm sure that there is no bad blocks on SD. I'll send any additional information. Just say me what you need to help me. I had i lot of tries. Apply patches, remove its, change fstype etc. output of fsck -f e2fsck 1.40-WIP (14-Nov-2006) Pass 1: Checking inodes, blocks, and sizes Inode 328897 is in use, but has dtime set. Fix? yes Inode 328897 has imagic flag set. Clear? yes Deleted inode 328898 has zero dtime. Fix? yes Inode 328901 is in use, but has dtime set. Fix? yes Inode 328901 has imagic flag set. Clear? yes Inode 328902 is in use, but has dtime set. Fix? yes Inode 328902 has imagic flag set. Clear? yes Inode 328903 is in use, but has dtime set. Fix? yes Inode 328903 has imagic flag set. Clear? yes Inode 328904 is in use, but has dtime set. Fix? yes Inode 328904 has imagic flag set. Clear? yes Inode 328905 is in use, but has dtime set. Fix? yes Inode 328906 is in use, but has dtime set. Fix? yes Inode 328907 is in use, but has dtime set. Fix? yes Inode 328908 is in use, but has dtime set. Fix? yes Inode 328897 has illegal block(s). Clear? yes Illegal block #0 (4027835811) in inode 328897. CLEARED. Illegal block #1 (4293308792) in inode 328897. CLEARED. Illegal block #2 (55841555) in inode 328897. CLEARED. Illegal block #3 (2960401150) in inode 328897. CLEARED. Illegal block #4 (2197115429) in inode 328897. CLEARED. Illegal block #5 (4124718308) in inode 328897. CLEARED. Illegal block #6 (504504963) in inode 328897. CLEARED. Illegal block #7 (4028032370) in inode 328897. CLEARED. Illegal block #8 (4028097955) in inode 328897. CLEARED. Illegal block #9 (4001625378) in inode 328897. CLEARED. Illegal block #10 (1422192624) in inode 328897. CLEARED. Too many illegal blocks in inode 328897. Clear inode? yes Inode 328907 has illegal block(s). Clear? yes Illegal block #0 (880856325) in inode 328907. CLEARED. Illegal block #1 (3138519423) in inode 328907. CLEARED. Illegal block #2 (303682281) in inode 328907. CLEARED. Illegal block #3 (351229189) in inode 328907. CLEARED. Illegal block #4 (168967413) in inode 328907. CLEARED. Illegal block #5 (920785427) in inode 328907. CLEARED. Illegal block #6 (2733646821) in inode 328907. CLEARED. Illegal block #7 (607380579) in inode 328907. CLEARED. Illegal block #8 (3833787818) in inode 328907. CLEARED. Illegal block #9 (2213926708) in inode 328907. CLEARED. Illegal block #10 (2431648992) in inode 328907. CLEARED. Too many illegal blocks in inode 328907. Clear inode? yes Inode 328904 has compression flag set on filesystem without compression support. Clear? yes Inode 328904, i_size is 1298022311761903630, should be 0. Fix? yes Inode 328904, i_blocks is 17109592, should be 0. Fix? yes Inode 328903 has compression flag set on filesystem without compression support. Clear? yes Inode 328903 has INDEX_FL flag set but is not a directory. Clear HTree index? yes Inode 328903, i_size is 4634368754045078648, should be 0. Fix? yes Inode 328903, i_blocks is 33775633, should be 0. Fix? yes Inode 328902 has INDEX_FL flag set but is not a directory. Clear HTree index? yes Inode 328902, i_size is 17719074603564334822, should be 0. Fix? yes Inode 328902, i_blocks is 1342215186, should be 0. Fix? yes Inode 328908 has INDEX_FL flag set but is not a directory. Clear HTree index? yes Inode 328908, i_size is 266945914413200612, should be 0. Fix? yes Inode 328908, i_blocks is 3792889567, should be 0. Fix? yes Inode 328906, i_size is 17222592312736442656, should be 0. Fix? yes Inode 328906, i_blocks is 55615200, should be 0. Fix? yes Inode 328901 has compression flag set on filesystem without compression support. Clear? yes Inode 328901, i_size is 367595204451501376, should be 0. Fix? yes Inode 328901, i_blocks is 4293787104, should be 0. Fix? yes Inode 328905 has compression flag set on filesystem without compression support. Clear? yes Inode 328905 has INDEX_FL flag set but is not a directory. Clear HTree index? yes Inode 328905, i_size is 8427850164134760656, should be 0. Fix? yes Inode 328905, i_blocks is 58744799, should be 0. Fix? yes Inodes thInode 328905, i_blocks is 58744799, should be 0. Fix? yes Inodes that were part of a corrupted orphan linked list found. Fix? yes Inode 474215 was part of the orphaned inode list. FIXED. Inode 474216 was part of the orphaned inode list. FIXED. Inode 474217 was part of the orphaned inode list. FIXED. Inode 474218 was part of the orphaned inode list. FIXED. Restarting e2fsck from the beginning... Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure at were part of a corrupted orphan linked list found. Fix? yes Entry 'GMT+7' in /usr/share/zoneinfo/Etc (328890) has deleted/unused
HELP!!! SD and suspend damage i-node.
I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 (PXA255). After suspend/resume filesystem stay clean. But some i-nodes become broken. Some files looks like block device or pipe with strange permissions, owner etc. I'm sure that there is no bad blocks on SD. I'll send any additional information. Just say me what you need to help me. I had i lot of tries. Apply patches, remove its, change fstype etc. output of fsck -f e2fsck 1.40-WIP (14-Nov-2006) Pass 1: Checking inodes, blocks, and sizes Inode 328897 is in use, but has dtime set. Fixy? yes Inode 328897 has imagic flag set. Cleary? yes Deleted inode 328898 has zero dtime. Fixy? yes Inode 328901 is in use, but has dtime set. Fixy? yes Inode 328901 has imagic flag set. Cleary? yes Inode 328902 is in use, but has dtime set. Fixy? yes Inode 328902 has imagic flag set. Cleary? yes Inode 328903 is in use, but has dtime set. Fixy? yes Inode 328903 has imagic flag set. Cleary? yes Inode 328904 is in use, but has dtime set. Fixy? yes Inode 328904 has imagic flag set. Cleary? yes Inode 328905 is in use, but has dtime set. Fixy? yes Inode 328906 is in use, but has dtime set. Fixy? yes Inode 328907 is in use, but has dtime set. Fixy? yes Inode 328908 is in use, but has dtime set. Fixy? yes Inode 328897 has illegal block(s). Cleary? yes Illegal block #0 (4027835811) in inode 328897. CLEARED. Illegal block #1 (4293308792) in inode 328897. CLEARED. Illegal block #2 (55841555) in inode 328897. CLEARED. Illegal block #3 (2960401150) in inode 328897. CLEARED. Illegal block #4 (2197115429) in inode 328897. CLEARED. Illegal block #5 (4124718308) in inode 328897. CLEARED. Illegal block #6 (504504963) in inode 328897. CLEARED. Illegal block #7 (4028032370) in inode 328897. CLEARED. Illegal block #8 (4028097955) in inode 328897. CLEARED. Illegal block #9 (4001625378) in inode 328897. CLEARED. Illegal block #10 (1422192624) in inode 328897. CLEARED. Too many illegal blocks in inode 328897. Clear inodey? yes Inode 328907 has illegal block(s). Cleary? yes Illegal block #0 (880856325) in inode 328907. CLEARED. Illegal block #1 (3138519423) in inode 328907. CLEARED. Illegal block #2 (303682281) in inode 328907. CLEARED. Illegal block #3 (351229189) in inode 328907. CLEARED. Illegal block #4 (168967413) in inode 328907. CLEARED. Illegal block #5 (920785427) in inode 328907. CLEARED. Illegal block #6 (2733646821) in inode 328907. CLEARED. Illegal block #7 (607380579) in inode 328907. CLEARED. Illegal block #8 (3833787818) in inode 328907. CLEARED. Illegal block #9 (2213926708) in inode 328907. CLEARED. Illegal block #10 (2431648992) in inode 328907. CLEARED. Too many illegal blocks in inode 328907. Clear inodey? yes Inode 328904 has compression flag set on filesystem without compression support. Cleary? yes Inode 328904, i_size is 1298022311761903630, should be 0. Fixy? yes Inode 328904, i_blocks is 17109592, should be 0. Fixy? yes Inode 328903 has compression flag set on filesystem without compression support. Cleary? yes Inode 328903 has INDEX_FL flag set but is not a directory. Clear HTree indexy? yes Inode 328903, i_size is 4634368754045078648, should be 0. Fixy? yes Inode 328903, i_blocks is 33775633, should be 0. Fixy? yes Inode 328902 has INDEX_FL flag set but is not a directory. Clear HTree indexy? yes Inode 328902, i_size is 17719074603564334822, should be 0. Fixy? yes Inode 328902, i_blocks is 1342215186, should be 0. Fixy? yes Inode 328908 has INDEX_FL flag set but is not a directory. Clear HTree indexy? yes Inode 328908, i_size is 266945914413200612, should be 0. Fixy? yes Inode 328908, i_blocks is 3792889567, should be 0. Fixy? yes Inode 328906, i_size is 17222592312736442656, should be 0. Fixy? yes Inode 328906, i_blocks is 55615200, should be 0. Fixy? yes Inode 328901 has compression flag set on filesystem without compression support. Cleary? yes Inode 328901, i_size is 367595204451501376, should be 0. Fixy? yes Inode 328901, i_blocks is 4293787104, should be 0. Fixy? yes Inode 328905 has compression flag set on filesystem without compression support. Cleary? yes Inode 328905 has INDEX_FL flag set but is not a directory. Clear HTree indexy? yes Inode 328905, i_size is 8427850164134760656, should be 0. Fixy? yes Inode 328905, i_blocks is 58744799, should be 0. Fixy? yes Inodes thInode 328905, i_blocks is 58744799, should be 0. Fixy? yes Inodes that were part of a corrupted orphan linked list found. Fixy? yes Inode 474215 was part of the orphaned inode list. FIXED. Inode 474216 was part of the orphaned inode list. FIXED. Inode 474217 was part of the orphaned inode list. FIXED. Inode 474218 was part of the orphaned inode list. FIXED. Restarting e2fsck from the beginning... Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure at were part of a corrupted orphan linked list found. Fixy? yes Entry 'GMT+7' in
Re: HELP!!! SD and suspend damage i-node.
On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote: I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 (PXA255). After suspend/resume filesystem stay clean. But some i-nodes become broken. Some files looks like block device or pipe with strange permissions, owner etc. I'm sure that there is no bad blocks on SD. I'll send any additional information. Just say me what you need to help me. I had i lot of tries. Apply patches, remove its, change fstype etc. output of fsck -f I assume this is the suspend to RAM? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
