On Sat, Mar 17, 2007 at 02:44:49AM -0400, Michael Wu wrote: > On Saturday 17 March 2007 02:15, Paul TBBle Hampson wrote: >> Is it worth dumping the purported eeprom to see if it's actually a valid >> eeprom in a format unexpected by the code? (The card is very old now...) > Actually, the code doesn't check (but it does report) if parsing fails so a > corrupted eeprom can't be the reason for probe failure. I'll get that fixed > next week.. > So anyway, your card isn't even returning the eeprom data. Only thing I can > think of is fiddling with the mdelay in that (p54p_read_eeprom) function > (there's only one). Try making it bigger. That mdelay solved problems with > eeprom reading on module reload but it's very close to the minimum delay > needed there. mdelay of 500 and 5000 didn't seem to help. Would the result of any of the P54P_READs help? Or do they not produce anything useful at this stage? -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@xxxxxxxxx Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Attachment:
pgphRtZnE8lQw.pgp
Description: PGP signature
