Messages in this thread | | | From | "Ammar T. Al-Sayegh" <> | Subject | Re: kernel BUG at mm/rmap.c:483! | Date | Thu, 24 Feb 2005 04:25:09 -0500 |
| |
>> really; it was supposed to do that already >> > >> >> i2c_dev 13249 0 >> >> i2c_core 24513 1 i2c_dev >> > >> > try for fun to not use i2c for a while >> > >> >> microcode 11489 0 >> > same for microcode... try removing that so that the microcode of your >> > system doesn't get updated at boot >> >> What do these two modules do in particular? and how can I disable >> them so that they don't get reloaded during boot time? do I need >> to disable both i2c_dev and i2c_core or just one of them? > > i2c is used to directly talk to motherboard hardware such as temperature > sensors. I've seen cases of certain chipset bugs leading to cacheline > corruption when stuff talked to the slow i2c bus and did other stuff in > parallel. > > microcode changes the microcode of the cpu (a part of your cpu is > actually written in "software" that can be updated); however updating > this behind the back of the bios might not always be a good idea. (but I > have no hard proof of any failures due to this) > > As for how to disable these.. you could just rename the respective .ko > files to .notko or something....
Done. Following is my new loaded module list:
[root ~]# lsmod Module Size Used by ip_conntrack_ftp 76145 0 md5 8001 1 ipv6 236769 38 autofs4 21829 0 sunrpc 135077 1 ipt_REJECT 10561 2 ipt_state 5825 79 ip_conntrack 45317 2 ip_conntrack_ftp,ipt_state iptable_filter 7489 1 ip_tables 20929 3 ipt_REJECT,ipt_state,iptable_filter dm_mod 57925 0 video 19653 0 button 10577 0 battery 13253 0 ac 8773 0 uhci_hcd 33497 0 ehci_hcd 33737 0 e1000 84629 0 floppy 56913 0 ext3 117961 6 jbd 57177 1 ext3 3w_xxxx 30561 0 ata_piix 12485 7 libata 44101 1 ata_piix sd_mod 20545 9 scsi_mod 116033 3 3w_xxxx,libata,sd_mod
Looks better now?
I guess I can no longer monitor the processor temperature and such after preventing i2c from loading, but what what's the penalty of preventing microcode from loading? a performance hit?
I will be testing memory as suggested by Hugh Dickins as well. Hopefully, your trick or Hugh's suggestion will help revealing the source of the problem, if not the kernel itself.
-ammar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |