Bug#292516: also in 2.6.9

[Aaron Denney <wnoise@ofb.net>]

--
FWIW, I had what appears to be the same problem with 2.6.9 kernel, and it worked fine on 
2.6.6.  So likely something changed either in 2.6.8 -> 2.6.9 or in
2.6.7 -> 2.6.8

Examining the 2.6.8 changelog finds this:

<hirofumi@mail.parknet.co.jp>
	[PATCH] FAT: don't use "utf8" charset and NLS_DEFAULT
	
	Recently, some distributors have set "utf8" to NLS_DEFAULT, therefore,
	FAT uses the "iocharset=utf8" as default.  But, since "iocharset=utf8"
	doesn't provide the function (lower <-> upper conversion) which FAT
	needs, so FAT can't provide suitable behavior.
	
	This patch does:
	
	     - doesn't recognize "utf8" as "iocharset"
	     - doesn't use NLS_DEFAULT as default "iocharset"
	     - instead of NLS_DEFAULT, adds FAT_DEFAULT_CODEPAGE and
	       FAT_DEFAULT_IOCHARSET
	   
	NOTE: the following looks like buggy, so it's not recommended
	
	    "codepage=437,iocharset=iso8859-1,utf8"
	
	however, some utf8 file name can handle. (in this case, it uses the
	table of iso8859-1 for lower <-> upper conversion)

Which while it covers an undefined behaviour, it does so with much
ugliness, and at the cost of usability, especially since it loked like
the problem was with codepage 437, even though it loaded successfully.

-- 
Aaron Denney
-><-