Pavel Roskin skrev: > On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote: >> Hello, >> >> First some background: >> I am currently running latest mainline from git. This kernel suffers >> from a scheduler? > > I think this question is more suited for LKML. > I'm sorry for being a bit vague. I'm just trying to describe the circumstances surrounding the issue. I and others have reported the scheduler oddity to LKML and it's being dealt with.
My question to this list could be condensed to: Is it normal that over 25000 interrupts are generated when loading b43, or is the driver or something else broken? I believe you guys are the best suited to answer this question. >> While trying to find what these hickups come from I ran watch --interval >> .1 "cat /proc/interrupts". I can see there that the b43 disappears, gets >> unloaded probably, and then reappears. > > You should probably show the exact contents of /proc/interrupts and > provide some details about the systems (architecture, CPU speed, > contents of /proc/sched_debug, lspci output, dmesg output). > >> When b43 reappears in the interrupt listing, that line generates some >> 25000 irq's within a fraction of a second. Is this a bug somewhere or by >> design? > > It's possible that the interrupt count is not shown when the driver > "disappears", but is not reset to 0. Once the interrupt has a handler, > the original count is shown. > This is on a HP DV2140eu laptop, 1GB ram, amd turion64 TL52 x2 (1600MHz), kubuntu 8.04 broadcom flavor: 4311 $ uname -a Linux laptop 2.6.25 #38 SMP Thu Apr 24 16:45:44 CEST 2008 x86_64 GNU/Linux I was trying to make a testcase, but can't find how to disable networkmanager, nor how to control if from a terminal. Just inactivating knetworkmanager and "rmmod b43" results in a segfault. Anyway networkmanager seems to reload the driver periodically for some reason. Probably because it's stupid and unaware that the radio is disabled by hardware button. b43 is loaded, not associated since wired networking is used. $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:12:50 CEST 2008 19: 813 210843 IO-APIC-fasteoi b43 a few moments later: $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:13:15 CEST 2008 19: 813 210843 IO-APIC-fasteoi b43 $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:13:16 CEST 2008 19: 813 210851 IO-APIC-fasteoi b43 $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:13:17 CEST 2008 19: 813 210854 IO-APIC-fasteoi <-- b43 reloaded by nm $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:13:18 CEST 2008 19: 856 232101 IO-APIC-fasteoi b43 $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:13:19 CEST 2008 19: 871 236961 IO-APIC-fasteoi $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:13:20 CEST 2008 19: 871 236969 IO-APIC-fasteoi b43 $ date && cat /proc/interrupts |grep "19:" fre apr 25 15:13:26 CEST 2008 19: 871 236969 IO-APIC-fasteoi b43 "within a fraction of a second" was a slight exaggregation by me, but most of the interrupts happens within a second. regards, Richard _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
