Re: Unable to remove kernel module showing permanent using lsmod
On Thu, Mar 24, 2011 at 12:08, sakthi selvam sakthi@gmail.com wrote: But in my case, cleanup module also available in memory, after loading the module. I used to check using the file in /proc/kallsyms for the availability of cleanup module in memory. AFAIK, such thing could happen due to certain data structure(s) from that module that are continously accessed or locked. So, to avoid race condition ( and missing pointer), keeping the module in memory is the right way to do. But of course, AFAIK too, you can try rmmod -f. But the risk is all yours. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regarding hugetlbfs
Hi All, I am having the following query regarding Huge pages and hugetlbfs. 1- How Hugetlbfs is dependent on hardware ? 2- Huge pages which is architecture dependent and ARM arm architecture supports Tiny, small and large pages will it support hugetlbfs if not then why ? can some one guide me thanks in advance Thanks John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Unable to remove kernel module showing permanent using lsmod
On Thu, Mar 24, 2011 at 02:47:15PM +0700, Kacrut wrote: On 03/24/2011 01:38 PM, Mulyadi Santosa wrote: On Thu, Mar 24, 2011 at 12:08, sakthi selvamsakthi@gmail.com wrote: But in my case, cleanup module also available in memory, after loading the module. I used to check using the file in /proc/kallsyms for the availability of cleanup module in memory. AFAIK, such thing could happen due to certain data structure(s) from that module that are continously accessed or locked. So, to avoid race condition ( and missing pointer), keeping the module in memory is the right way to do. But of course, AFAIK too, you can try rmmod -f. But the risk is all yours. I got same problem too. Doing rmmod -f doesnt solve it. Any other solution? Nope, your kernel is probably configured to not allow kernel modules to be unloaded. I would ask your vendor about this as they are the ones that can support your kernel the best, not the community. best of luck, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
maranello for staging ?
we have, at http://www.cs.umd.edu/projects/maranello/ Abstract In this project, we design, implement, and evaluate Maranello, a novel partial packet recovery mechanism for 802.11. In Maranello, the receiver computes checksums over blocks in corrupt packets and bundles these checksums into a negative acknowledgment sent when the sender expects to receive an acknowledgment. The sender then retransmits only those blocks for which the checksum is incorrect, and repeats this partial retransmission until it receives an acknowledgment. Successful transmissions are not burdened by additional bits and the receiver needs not infer which bits were corrupted. We implemented Maranello using OpenFWWF (open source firmware for Broadcom wireless cards) and deployed it in a small testbed. We compare Maranello to alternative recovery protocols using a trace-driven simulation and to 802.11 using a live implementation under various channel conditions. To our knowledge, Maranello is the first partial packet recovery design to be implemented in commonly-available firmware. This is cool stuff. Im probably jumping the gun a bit, but well, its cool, and I have a wrt54g router to eventually try it on. I dont however have both sides of a wifi connection, so I wont be able to actually test it. Ive taken the patches on the site, applied them to 2.6.29-rc2, and started working them a bit to make them suitable for inclusion. Naturally I have questions: I started with their patches verbatim, as this preserves their provenance, and limits my chances of screwing up and making an unmaintainable mess out of them. Does staging tree value the preservation of provenance ? Or does it want all patches in the set to be proper (at minimum passing checkpatch). If so, I should keep the style fixups separate, instead of folding them back in to make each patch (including the original maranello patches) pass the objective criteria. How do I balance these competing interests ? Also, I figure Im serving several different purposes (or audiences) here; - inclusion (2.6.4x ?) - maranello team (success would be them adopting this rework in progress) - OpenWRT development - serious pool of hackers and devices to test upon (10.03.1-rc4 is using 2.6.32.25 currently, I dont know future kernel plans) I have a github repo: https://github.com/jimc/linux-2.6 and have pushed the following to mx0a branch. jimc@chumly:~/projects/lx/linux-2.6$ git log --oneline 4bb61c8 maranello.h defines maranello_stats, use it. 856f571 add spaces after C keywords e1251f1 fixup C99 comments e663495 cleanfile drivers/net/wireless/b43/phy_common.h too 2c67a78 run cleanfile, fix whitespace problems added by original patches 07bc126 extract maranello common parts 1 04f010b patch -p0 maranello_released_kernelpatches/b43.patch 59f4336 patch -p0 maranello_released_kernelpatches/include.patch 6cc5022 patch -p0 maranello_released_kernelpatches/mac80211.patch 1de9e8e Linux 2.6.29-rc2 I merged this branch up with 2.6.32, and found I had to do ~6 merge fixups. I tried merge --squash, in effort to catch the changes to a separate commit; but that puts the commit on the 'wrong' branch - and it ISTM that it doesnt catch just the conflict resolution diffs, but rather the sum of all the diffs in the other branch. I was hoping to do a series of merge --squashes, and adapt the branch by slowly working up the various commits of master; effectively climbing the ladder. Is this a sane, straightforward strategy ? I figured Id select merge-points with this: 'git log --oneline drivers/net/wireless/b43' Im not quite sure how to proceed with this, Ive refrained from sending to net...@kernel.org, I guess Id like advice and feedback 1st. thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Debug kernel panic with gdb?
Hi,
I'm trying to debug a kernel panic (something like this):
Unable to handle kernel NULL pointer dereference at virtual address 0014
ptbr = 93959000 pgd = 93a0a000
Oops: Kernel access of bad area, sig: 11 [#1]
FRAME_POINTER chip: 0x01f:0x1e82 rev 2
Modules linked in: ftdi_sio usbserial
PC is at isp1760_irq+0xda/0x7f0
LR is at isp1760_irq+0x492/0x7f0
pc : [901408be]lr : [90140c76]Not tainted
sp : 93aa399c r12: fffe r11:
r10: r9 : fffe r8 :
r7 : 93aa3a08 r6 : 93406400 r5 : 00820004 r4 : 0003
r3 : 0008 r2 : 0002 r1 : fffd r0 : 93837000
Call trace:
[90134abc] usb_hcd_irq+0x50/0x54
[900383da] handle_IRQ_event+0x1e/0x40
[90039098] handle_level_irq+0x78/0x8c
...
This is on an AVR32 platform, and I'm building the kernel myself (cross
compiling). The image is then converted to a uImage before being loaded
to the target. Is there a way to get the following to work in this context?
$ gdb arch/avr32/boot/images/vmlinux.elf
...
Reading symbols from
/home/.../linux-2.6.37/arch/avr32/boot/images/vmlinux.elf...done.
(gdb) list *isp1760_irq+0xda
0x9017ac36 is in isp1760_irq (include/linux/spinlock.h:285).
280 raw_spin_lock_init((_lock)-rlock);\
281 } while (0)
282
283 static inline void spin_lock(spinlock_t *lock)
284 {
285 raw_spin_lock(lock-rlock);
286 }
287
288 static inline void spin_lock_bh(spinlock_t *lock)
289 {
The problem is that the line reported is totally wrong (this being very
unhelpful
and confusing indeed - it tool me awhile to realise this!). I've also tried to
use gdb from the avr32 toolchain with the same result.
Is there a way to get this to work?
Thanks,
Arvid Brodin
Enea Services Stockholm AB
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
