Messages in this thread | | | Date | Fri, 12 Sep 2008 17:13:02 -0700 | From | Andrew Morton <> | Subject | Re: Partition check considered as error is breaking mounting in 2.6.27 |
| |
On Fri, 12 Sep 2008 16:59:20 -0700 David Brownell <david-b@pacbell.net> wrote:
> > > > ________________________________________________________________disk->disk_name, p); > > > > -______________________________________________continue; > > > > ________________________________} > > > > wtf-your-email-client-is-insane. > > I have no idea where that came from. Wasn't in the original or > in my copy. >
Your email client added it. What I sent:
0008A0: 68 65 63 6B 2E 63 0A 40 40 20 2D 35 34 30 2C 37 >heck.c@@@ -540,7< 0008B0: 20 2B 35 34 30 2C 36 20 40 40 20 69 6E 74 20 72 > +540,6 @@ int r< 0008C0: 65 73 63 61 6E 5F 70 61 72 74 69 74 69 6F 6E 73 >escan_partitions< 0008D0: 28 73 74 72 75 63 74 20 67 65 6E 64 69 73 6B 20 >(struct gendisk < 0008E0: 2A 64 69 0A 20 09 09 69 66 20 28 66 72 6F 6D 20 >*di@ @@if (from < 0008F0: 2B 20 73 69 7A 65 20 3E 20 67 65 74 5F 63 61 70 >+ size > get_cap< 000900: 61 63 69 74 79 28 64 69 73 6B 29 29 20 7B 0A 20 >acity(disk)) {@ < 000910: 09 09 09 70 72 69 6E 74 6B 28 4B 45 52 4E 5F 45 >@@@printk(KERN_E< 000920: 52 52 20 22 20 25 73 3A 20 70 25 64 20 65 78 63 >RR " %s: p%d exc< 000930: 65 65 64 73 20 64 65 76 69 63 65 20 63 61 70 61 >eeds device capa< 000940: 63 69 74 79 5C 6E 22 2C 0A 20 09 09 09 09 64 69 >city\n",@ @@@@di< 000950: 73 6B 2D 3E 64 69 73 6B 5F 6E 61 6D 65 2C 20 70 >sk->disk_name, p< 000960: 29 3B 0A 2D 09 09 09 63 6F 6E 74 69 6E 75 65 3B >);@-@@@continue;< 000970: 0A 20 09 09 7D 0A 20 09 09 72 65 73 20 3D 20 61 >@ @@}@ @@res = a<
your reply:
000C50: A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 >@@@@@@@@@@@@@@@@< 000C60: A0 70 72 69 6E 74 6B 28 4B 45 52 4E 5F 45 52 52 >@printk(KERN_ERR< 000C70: 20 22 20 25 73 3A 20 70 25 64 20 65 78 63 65 65 > " %s: p%d excee< 000C80: 64 73 20 64 65 76 69 63 65 20 63 61 70 61 63 69 >ds device capaci< 000C90: 74 79 5C 6E 22 2C 0A 3E 20 A0 A0 A0 A0 A0 A0 A0 >ty\n",@> @@@@@@@< 000CA0: A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 >@@@@@@@@@@@@@@@@< 000CB0: A0 A0 A0 A0 A0 A0 A0 A0 A0 64 69 73 6B 2D 3E 64 >@@@@@@@@@disk->d< 000CC0: 69 73 6B 5F 6E 61 6D 65 2C 20 70 29 3B 0A 3E 20 >isk_name, p);@> < 000CD0: 2D A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 >-@@@@@@@@@@@@@@@< 000CE0: A0 A0 A0 A0 A0 A0 A0 A0 63 6F 6E 74 69 6E 75 65 >@@@@@@@@continue<
I've ceased to be amazed at the stupid tricks which MUAs inflict upon us in recent years.
> > > > So that now deserves to be KERN_WARN not KERN_ERR, yes? > > > > spose so. > > > > I'm fairly unenthused about the recent KERN_correctness fad since it > > went and broke sysrq-T output (you have to set the loglevel beforehand > > to avoid getting only partial output). > > On development systems I generally "echo 8 > /proc/sysrq*" > to make sure KERN_DEBUG isn't hidden.
Yeah, but it's another step we need to walk reporters through when diagnosing problems. Madly machine-gunning each others' feet.
> In this case it's just that I saw flamage a few minutes > earlier from someone trying to keep a distro boot from > spewing scarey messages for things that were NOT errors. > Like ... this message. :)
Lots of our messages should just be deleted. I think people put them in at development time and are then reluctant to clean them up.
Proposed algorithm:
- choose the message well so it can be googled for.
- time passes
- google for it
- if nobody's reporting it: kill.
| |