I bet you compiled 2.1.102 with other compiler. I had the problem too,
and it turned out to be a timer problem. It only appeared when gcc (or
egcs) produced too good code, and could be solved by inserting little
delay on top of SMC93x_Init function.
Here is what Richard Henderson says:
% > handle_irq: irq 8 count 91837 cc 1612 @ fffffc0000328744
% > My system: pc164 433Mhz
%
% That is a timer going wild. A cc that small means it was
% interrupting at 268610 Hz -- about 200 times fast.
%
% This is semi-consistent with other systems in that RTC
% handling seems dreadfully broken at the moment, and I have
% no idea why.
As I said, inserting udelay(200) fixed that problem, but nobody knows
why. Disabling interrupts in SMC93x_Init fixes the problem too. Here
is what I currently use on PC164/433Mhz/egcs-1.1/linux-2.1.126:
--- smc37c93x.c.1 Thu Sep 24 17:12:04 1998
+++ smc37c93x.c Thu Sep 24 17:10:46 1998
@@ -242,6 +242,10 @@
int __init SMC93x_Init(void)
{
unsigned long SMCUltraBase;
+ unsigned long flags;
+ int ret;
+
+ __save_and_cli(flags);
if ((SMCUltraBase = SMCDetectUltraIO()) != 0UL) {
printk("SMC FDC37C93X Ultra I/O Controller found @ 0x%lx\n",
@@ -265,10 +269,12 @@
SMCReportDeviceStatus(SMCUltraBase);
#endif
SMCRunState(SMCUltraBase);
- return 1;
+ ret = 1;
}
else {
DBG_DEVS(("No SMC FDC37C93X Ultra I/O Controller found\n"));
- return 0;
+ ret = 0;
}
+ __restore_flags(flags);
+ return ret;
}
Alexander.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/