Thread: [Ndiswrapper-general] Re: BCM4306 64-bit notes -- 1.0 works and possible memory leak
Status: Beta
Brought to you by:
pgiri
From: Parag W. <ker...@co...> - 2005-02-17 01:14:57
|
Pkl0IGxvb2tzIGxpa2UgdGhlIHByb2JsZW0gaXMga2VybmVsLXZlcnNpb24gcmVsYXRlZCwgbm90 IG5kaXN3cmFwcGVyLiAKPm5kaXN3cmFwcGVyIGp1c3QgdXNlcyBzb21lIEFQSSB0aGF0IHN0YXJ0 cyB0aGUgbWVtb3J5IGxlYWsgYnV0IHRoZSAKPiBwcm9ibGVtIGlzIGluZGVlZCBpbiB0aGUga2Vy bmVsIGl0c2VsZi4gdmVyc2lvbnMgZnJvbSAyLjYuMTAgdXAgdG8gCj4uMTEtcmMzIGhhdmUgdGhp cyBwcm9ibGVtIGFmYWlrLiBoYXZlbiJ0IHRlc3RlZCByYzQgYnV0IG1heWJlIHRoaXMgb25lIAo+ IGRvZXNuInQgaGF2ZSB0aGUgcHJvYmxlbSBhbnltb3JlLCB3ZSB3aWxsIHNlZQoKSSB0ZXN0ZWQg c3RvY2sgLXJjNCB3aXRoIG5kaXN3cmFwcGVyIDEuMCBhbmQgNjRiaXQgQkNNIGFuZCB0aGUgbGVh ayBpcyBzdGlsbCAKcHJlc2VudC4gQmVpbmcgb24gWDg2XzY0LCBJIGhhdmVuJ3QgYmVlbiBhYmxl IHRvIG1ha2UgdXNlIG9mIHRoZSBiZWxvdyBwYXRjaCAKdG8gdHJhY2sgdGhlIGxlYWsgKEkgYWx3 YXlzIGdldCBqdW5rIF9fYnVpbHRpbl9yZXR1cm5fYWRkcmVzcykuIE5lZWRzIApDT05GSUdfREVC VUcgYW5kIENPTkZJR19ERUJVR19TTEFCLgoKRnJvbTogTWFuZnJlZCBTcHJhdWwgPG1hbmZyZWRA Y29sb3JmdWxsaWZlLmNvbT4KCldpdGggdGhlIHBhdGNoIGFwcGxpZWQsCgqgoKCgoKCgoGVjaG8g InNpemUtNDA5NiAwIDAgMCIgPiAvcHJvYy9zbGFiaW5mbwoKd2Fsa3MgdGhlIG9iamVjdHMgaW4g dGhlIHNpemUtNDA5NiBzbGFiLCBwcmludGluZyBvdXQgdGhlIGNhbGxpbmcgYWRkcmVzcwpvZiB3 aG9ldmVyIGFsbG9jYXRlZCB0aGF0IG9iamVjdC4KCkl0IGlzIGZvciBsZWFrIGRldGVjdGlvbi4K CgpkaWZmIC1wdU4gbW0vc2xhYi5jfnNsYWItbGVhay1kZXRlY3RvciBtbS9zbGFiLmMKLS0tIDI1 L21tL3NsYWIuY35zbGFiLWxlYWstZGV0ZWN0b3KgoKCgoDIwMDUtMDItMTUgMjE6MDY6NDQuMDAw MDAwMDAwIC0wODAwCisrKyAyNS1ha3BtL21tL3NsYWIuY6CgoDIwMDUtMDItMTUgMjE6MDY6NDQu MDAwMDAwMDAwIC0wODAwCkBAIC0yMTE2LDYgKzIxMTYsMTUgQEAgY2FjaGVfYWxsb2NfZGVidWdj aGVja19hZnRlcihrbWVtX2NhY2hlXwqgoKCgoKCgoKCgoKCgoKCgKmRiZ19yZWR6b25lMShjYWNo ZXAsIG9ianApID0gUkVEX0FDVElWRTsKoKCgoKCgoKCgoKCgoKCgoCpkYmdfcmVkem9uZTIoY2Fj aGVwLCBvYmpwKSA9IFJFRF9BQ1RJVkU7CqCgoKCgoKCgfQoroKCgoKCgoHsKK6CgoKCgoKCgoKCg oKCgoGludCBvYmpucjsKK6CgoKCgoKCgoKCgoKCgoHN0cnVjdCBzbGFiICpzbGFicDsKKworoKCg oKCgoKCgoKCgoKCgc2xhYnAgPSBHRVRfUEFHRV9TTEFCKHZpcnRfdG9fcGFnZShvYmpwKSk7CisK K6CgoKCgoKCgoKCgoKCgoG9iam5yID0gKG9ianAgLSBzbGFicC0+c19tZW0pIC8gY2FjaGVwLT5v YmpzaXplOworoKCgoKCgoKCgoKCgoKCgc2xhYl9idWZjdGwoc2xhYnApW29iam5yXSA9ICh1bnNp Z25lZCBsb25nKWNhbGxlcjsKK6CgoKCgoKB9CqCgoKCgoKCgb2JqcCArPSBvYmpfZGJnaGVhZChj YWNoZXApOwqgoKCgoKCgoGlmIChjYWNoZXAtPmN0b3IgJiYgY2FjaGVwLT5mbGFncyAmIFNMQUJf UE9JU09OKSB7CqCgoKCgoKCgoKCgoKCgoKB1bnNpZ25lZCBsb25noKCgY3Rvcl9mbGFncyA9IFNM QUJfQ1RPUl9DT05TVFJVQ1RPUjsKQEAgLTIxNzksMTIgKzIxODgsMTQgQEAgc3RhdGljIHZvaWQg ZnJlZV9ibG9jayhrbWVtX2NhY2hlX3QgKmNhYwqgoKCgoKCgoKCgoKCgoKCgb2JqbnIgPSAob2Jq cCAtIHNsYWJwLT5zX21lbSkgLyBjYWNoZXAtPm9ianNpemU7CqCgoKCgoKCgoKCgoKCgoKBjaGVj a19zbGFicChjYWNoZXAsIHNsYWJwKTsKoCNpZiBERUJVRworI2lmIDAKoKCgoKCgoKCgoKCgoKCg oGlmIChzbGFiX2J1ZmN0bChzbGFicClbb2JqbnJdICE9IEJVRkNUTF9GUkVFKSB7CqCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoHByaW50ayhLRVJOX0VSUiAic2xhYjogZG91YmxlIGZyZWUgZGV0ZWN0 ZWQgaW4gY2FjaGUgCiclcycsIG9ianAgJXAuXG4iLAqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBjYWNoZXAtPm5hbWUsIG9ianApOwqgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKBCVUcoKTsKoKCgoKCgoKCgoKCgoKCgoH0KoCNlbmRpZgorI2VuZGlmCqCgoKCg oKCgoKCgoKCgoKBzbGFiX2J1ZmN0bChzbGFicClbb2JqbnJdID0gc2xhYnAtPmZyZWU7CqCgoKCg oKCgoKCgoKCgoKBzbGFicC0+ZnJlZSA9IG9iam5yOwqgoKCgoKCgoKCgoKCgoKCgU1RBVFNfREVD X0FDVElWRShjYWNoZXApOwpAQCAtMjk5OCw2ICszMDA5LDI5IEBAIHN0cnVjdCBzZXFfb3BlcmF0 aW9ucyBzbGFiaW5mb19vcCA9IHsKoKCgoKCgoKAuc2hvd6CgoD0gc19zaG93LAqgfTsKoAorc3Rh dGljIHZvaWQgZG9fZHVtcF9zbGFicChrbWVtX2NhY2hlX3QgKmNhY2hlcCkKK3sKKyNpZiBERUJV RworoKCgoKCgoHN0cnVjdCBsaXN0X2hlYWQgKnE7CisKK6CgoKCgoKBjaGVja19pcnFfb24oKTsK K6CgoKCgoKBzcGluX2xvY2tfaXJxKCZjYWNoZXAtPnNwaW5sb2NrKTsKK6CgoKCgoKBsaXN0X2Zv cl9lYWNoKHEsJmNhY2hlcC0+bGlzdHMuc2xhYnNfZnVsbCkgeworoKCgoKCgoKCgoKCgoKCgc3Ry dWN0IHNsYWIgKnNsYWJwOworoKCgoKCgoKCgoKCgoKCgaW50IGk7CiugoKCgoKCgoKCgoKCgoKBz bGFicCA9IGxpc3RfZW50cnkocSwgc3RydWN0IHNsYWIsIGxpc3QpOworoKCgoKCgoKCgoKCgoKCg Zm9yIChpID0gMDsgaSA8IGNhY2hlcC0+bnVtOyBpKyspIHsKK6CgoKCgoKCgoKCgoKCgoKCgoKCg oKCgdW5zaWduZWQgbG9uZyBzeW0gPSBzbGFiX2J1ZmN0bChzbGFicClbaV07CisKK6CgoKCgoKCg oKCgoKCgoKCgoKCgoKCgcHJpbnRrKCJvYmogJXAvJWQ6ICVwIiwgc2xhYnAsIGksICh2b2lkICop c3ltKTsKK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgcHJpbnRfc3ltYm9sKCIgPCVzPiIsIHN5bSk7 CiugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHByaW50aygiXG4iKTsKK6CgoKCgoKCgoKCgoKCgoH0K K6CgoKCgoKB9CiugoKCgoKCgc3Bpbl91bmxvY2tfaXJxKCZjYWNoZXAtPnNwaW5sb2NrKTsKKyNl bmRpZgorfQorCqAjZGVmaW5lIE1BWF9TTEFCSU5GT19XUklURSAxMjgKoC8qKgqgICogc2xhYmlu Zm9fd3JpdGUgLSBUdW5pbmcgZm9yIHRoZSBzbGFiIGFsbG9jYXRvcgpAQCAtMzAzOCw5ICszMDcy LDExIEBAIHNzaXplX3Qgc2xhYmluZm9fd3JpdGUoc3RydWN0IGZpbGUgKmZpbGUKoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgIKAgoGJhdGNoY291bnQgPCAxIHx8CqCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoCCgIKBiYXRjaGNvdW50ID4gbGltaXQgfHwKoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIKAg oHNoYXJlZCA8IDApIHsKLaCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKByZXMgPSAtRUlO VkFMOworoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoGRvX2R1bXBfc2xhYnAoY2FjaGVw KTsKK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKByZXMgPSAwOwqgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKB9IGVsc2UgewotoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHJlcyA9 IGRvX3R1bmVfY3B1Y2FjaGUoY2FjaGVwLCBsaW1pdCwgCmJhdGNoY291bnQsIHNoYXJlZCk7Ciug oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgcmVzID0gZG9fdHVuZV9jcHVjYWNoZShjYWNo ZXAsIGxpbWl0LAoroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoGJhdGNoY291bnQsIHNoYXJlZCk7CqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoH0K oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgYnJlYWs7CqCgoKCgoKCgoKCgoKCgoKB9ClBhcmFnCg== |
From: Parag W. <ker...@co...> - 2005-02-21 00:28:02
|
Sorry for changing the subject - here is the background-- On Wednesday 16 February 2005 08:14 pm, Parag Warudkar wrote: > >It looks like the problem is kernel-version related, not ndiswrapper. > >ndiswrapper just uses some API that starts the memory leak but the > > problem is indeed in the kernel itself. versions from 2.6.10 up to > >.11-rc3 have this problem afaik. haven"t tested rc4 but maybe this one > > doesn"t have the problem anymore, we will see > > I tested stock -rc4 with ndiswrapper 1.0 and 64bit BCM and the leak is > still present. Being on X86_64, I haven't been able to make use of the > below patch to track the leak (I always get junk __builtin_return_address). > Needs CONFIG_DEBUG and CONFIG_DEBUG_SLAB. I have tracked it down to NdisAllocateBuffer (kmalloc) - Within minutes, it is called 39584 times without a corresponding call to NdisFreeBuffer (kfree). I can't imagine the kernel calling NdisAllocateBuffer directly so it is either ndiswrapper itself or the Broadcom driver forgets to call NdisFreeBuffer. What's the greater possibility out of two? Parag |
From: Giridhar P. <gi...@lm...> - 2005-02-21 01:22:19
|
NdisAllocateBuffer is called by the driver - ndiswrapper has to call kmalloc to complete this call, so it certainly is not ndiswrapper issue in this case. Whether it is Broadcom driver or not is any body's guess. I heard that sometime during 2.6.10 to 2.6.11-rc4 memory issues surfaced (I saw in lkml same problem reported without ndiswrapper), so it is possible something is triggering this behavior. Try older than 2.6.10 kernel or 2.6.11-rc4-bkX. -- Giri |
From: Parag W. <ker...@co...> - 2005-02-21 01:59:12
|
On Sunday 20 February 2005 08:22 pm, Giridhar Pemmasani wrote: > NdisAllocateBuffer is called by the driver - ndiswrapper has to call > kmalloc to complete this call, so it certainly is not ndiswrapper > issue in this case. Whether it is Broadcom driver or not is any body's > guess. I heard that sometime during 2.6.10 to 2.6.11-rc4 memory issues > surfaced (I saw in lkml same problem reported without ndiswrapper), so > it is possible something is triggering this behavior. Try older than > 2.6.10 kernel or 2.6.11-rc4-bkX. I tried all kernels till 2.6.8 - NdisWrapper leaks with all of them. I am a little short of concluding that it is an NdisWrapper bug - will update shortly. --Thanks |
From: Karl V. <kar...@te...> - 2005-02-23 00:02:29
|
Parag Warudkar <ker...@co...> writes: > I have tracked it down to NdisAllocateBuffer (kmalloc) - Within minutes, it is > called 39584 times without a corresponding call to NdisFreeBuffer (kfree). > > I can't imagine the kernel calling NdisAllocateBuffer directly so it is either > ndiswrapper itself or the Broadcom driver forgets to call NdisFreeBuffer. > > What's the greater possibility out of two? Apparently the second one... Testing showed that the broadcom driver is using NdisAllocateBuffer() and then using IoFreeMdl() to release it, which is rather odd. Giri has fixed the issue in 1.1rc2 I've tested the fix and it's looking good.. copied 7Gb from and 7Gb to my machine over ndiswrapper and the box is still in healthy condition. |
From: Parag W. <ker...@co...> - 2005-02-21 04:25:22
Attachments:
ndis.c.patch
|
On Sunday 20 February 2005 08:22 pm, Giridhar Pemmasani wrote: > NdisAllocateBuffer is called by the driver - ndiswrapper has to call > kmalloc to complete this call, so it certainly is not ndiswrapper > issue in this case. Whether it is Broadcom driver or not is any body's > guess. I heard that sometime during 2.6.10 to 2.6.11-rc4 memory issues > surfaced (I saw in lkml same problem reported without ndiswrapper), so > it is possible something is triggering this behavior. Try older than > 2.6.10 kernel or 2.6.11-rc4-bkX. Ok, here is the scoop - For the following reasons, the kernel is not at fault - 1) Kernel runs fine without ndiswrapper 2) I did track kmalloc usage and its callers - NdisAllocateBuffer is the culprit which is called a zillion times without a single corresponding NdisFreeBuffer which means a zillion kmallocs with no kfrees - leak. For the following reasons NdisWrapper is the culprit - 1) Driver starts calling NdisAllocateBuffer the moment it is loaded and keeps calling it for ever. 2) Driver calls NdisAllocateBuffer only handful of times for distinct Virtual Addresses (Parameter #4 - void* virt). IOW, 98% calls of NdisAllocateBuffer are for a previously asked Virt Addr. MSDN documentation is unclear but it would seem this is perfectly alright. 3) We do a kmalloc for every NdisAllocateBuffer. -- This is the problem. We should track if the VA was previously given a buffer. If so we should free that buffer and return a new mapping. Attached experimental patch works and doesn't leak. I have tested it by downloading the linux kernel @400KB/s and it seems fine. I don't suggest applying it to main tree yet - I am planning on a better solution avoiding those zillion kmallocs and kfrees. Any one having memory leak problem with the 64Bit Broadcom driver, please test keeping in mind that it is experimental. Cheers Parag |
From: Jonathan B. <be...@gm...> - 2005-02-21 05:59:02
|
On Sun, 20 Feb 2005 23:24:59 -0500, Parag Warudkar <ker...@co...> wrote: > On Sunday 20 February 2005 08:22 pm, Giridhar Pemmasani wrote: > > NdisAllocateBuffer is called by the driver - ndiswrapper has to call > > kmalloc to complete this call, so it certainly is not ndiswrapper > > issue in this case. Whether it is Broadcom driver or not is any body's > > guess. I heard that sometime during 2.6.10 to 2.6.11-rc4 memory issues > > surfaced (I saw in lkml same problem reported without ndiswrapper), so > > it is possible something is triggering this behavior. Try older than > > 2.6.10 kernel or 2.6.11-rc4-bkX. > > Ok, here is the scoop - > > For the following reasons, the kernel is not at fault - > 1) Kernel runs fine without ndiswrapper > 2) I did track kmalloc usage and its callers - NdisAllocateBuffer is the > culprit which is called a zillion times without a single corresponding > NdisFreeBuffer which means a zillion kmallocs with no kfrees - leak. > > For the following reasons NdisWrapper is the culprit - > 1) Driver starts calling NdisAllocateBuffer the moment it is loaded and keeps > calling it for ever. > 2) Driver calls NdisAllocateBuffer only handful of times for distinct Virtual > Addresses (Parameter #4 - void* virt). IOW, 98% calls of NdisAllocateBuffer > are for a previously asked Virt Addr. MSDN documentation is unclear but it > would seem this is perfectly alright. > 3) We do a kmalloc for every NdisAllocateBuffer. -- This is the problem. We > should track if the VA was previously given a buffer. If so we should free > that buffer and return a new mapping. > > Attached experimental patch works and doesn't leak. I have tested it by > downloading the linux kernel @400KB/s and it seems fine. I don't suggest > applying it to main tree yet - I am planning on a better solution avoiding > those zillion kmallocs and kfrees. > > Any one having memory leak problem with the 64Bit Broadcom driver, please test > keeping in mind that it is experimental. > > Cheers > Parag Thanks a ton Parag. Great work tracking down the leak. I guess I'll have to retract my bugzilla :). I'll try your patch as soon as I get a chance to. By the way, which version did you apply it to? That is, which version did you make the changes to? I have only been able to get version 1.0 to work for me, as I said before. Once this leak is fixed for good, I should be able to use my wireless. Jonathan PS: You sent a message after this that seems blank to me. Looking at the source, it seems to have binary content, though it's MIME type is plain text. It's a Fwd:, so perhaps did it attach the email? I can't figure it out. |
From: Parag W. <ker...@co...> - 2005-02-21 16:08:28
Attachments:
ndis.c.patch
|
> > Attached experimental patch works and doesn't leak. I have tested it by > > downloading the linux kernel @400KB/s and it seems fine. I don't suggest > > applying it to main tree yet - I am planning on a better solution > > avoiding those zillion kmallocs and kfrees. Actually the solution is simple. We do not need to do all those kmallocs and kfrees at all if we initialize the ndis_buffer before returning the same buffer for an existing VA. Try this new patch - it totally avoids the kmalloc/kfree for existing VA and so it should be significantly faster and safer. Giri - Pending testing from other people and your comments - please apply if there aren't any objections to this patch. Parag |
From: Giridhar P. <gi...@lm...> - 2005-02-21 21:22:36
Attachments:
pool
|
If driver is calling NdisAllocateBuffer for a memory region for which already a buffer has been allocated, then it is a bug in that driver IMO. NDIS is not clear about this, but driver shouldn't allocate buffers like that. The patch below is correct patch to handle this. I don't have amd64 so I can't test this. On x86 with couple of drivers, this works. If this works for amd64, I can prepare 1.1rc2. |
From: Parag W. <ker...@co...> - 2005-02-22 01:57:06
|
On Monday 21 February 2005 04:22 pm, Giridhar Pemmasani wrote: > If driver is calling NdisAllocateBuffer for a memory region for which > already a buffer has been allocated, then it is a bug in that driver IMO. > NDIS is not clear about this, but driver shouldn't allocate buffers like > that. It's valid for a driver to call NdisAllocateBuffer multiple times with same VA. That is because on Windows, NdisAllocateBuffer does not allocate memory - it just sets up mapping for the driver specified memory area. That's why it is valid for user to ask for mapping more than once. To verify I asked this on MSDN newsgroups and they seem to concur. > > The patch below is correct patch to handle this. I don't have amd64 so I > can't test this. On x86 with couple of drivers, this works. If this works > for amd64, I can prepare 1.1rc2. This patch being conceptually similar - for (i = 0; i < pool->num_buffers; i++) { + *buffer = &(pool->buffers[i]); + if ((*buffer)->startva == 0 || (*buffer)->startva == virt) { ^^^^^^^^^^^^^^^ - in that it finds the buffer corresponding to existing VirtAddr, I think it will fix the leak too. The patch doesn't apply, wrong version or corrupted possibly. Parag |
From: Giridhar P. <gi...@lm...> - 2005-02-22 02:27:30
|
I have committed the patch to CVS and generated latest nightly. Try the latest nightly and see if it fixes the memory issues. I wanted to acknowledge Parag for pointing out the problem in CVS log, but forgot to do so. Sorry about that. So here goes - thanks Parag for your work. -- Giri |
From: Jonathan B. <be...@gm...> - 2005-02-22 05:52:51
|
On Mon, 21 Feb 2005 21:27:22 -0500, Giridhar Pemmasani <gi...@lm...> wrote: > I have committed the patch to CVS and generated latest nightly. Try the latest > nightly and see if it fixes the memory issues. > > I wanted to acknowledge Parag for pointing out the problem in CVS log, but > forgot to do so. Sorry about that. So here goes - thanks Parag for your > work. > > -- > Giri Well, Parag's patch seems to work for me. I don't see size-64 growing like it was before. As far as Giri's patch, it would not apply cleanly to 1.0 and I still cannot get the latest nightly to work 050221. It modprobes just fine, but it seems to die when actually using the interface after "dhclient wlan0" just like the others. I'll try to setup an experiment with netconsole and DEBUG=3 within the next couple of days to see if I can actually get some useful information. Giri, what are the differences between your patch and the one Parag submitted? Is it just cleaned up a bit? Thanks to you both for working on this. Jonathan |
From: Giridhar P. <gi...@lm...> - 2005-02-22 10:20:41
|
I was told that CVS is broken for amd64 in the past couple of days. Someone with amd64 needs to figure out what it is and provide a patch or identify which commit breaks it. My patch is not cleaned up version, it is different and should be similar to what NDIS does. It is also more efficient. This patch shouldn't break for amd64; earlier ones are probably the culprits. -- Giri |
From: Jonathan B. <be...@gm...> - 2005-02-23 05:49:35
|
On Tue, 22 Feb 2005 05:20:52 -0500, Giridhar Pemmasani <gi...@lm...> wrote: > I was told that CVS is broken for amd64 in the past couple of > days. Someone with amd64 needs to figure out what it is and provide a > patch or identify which commit breaks it. It seems to have broken much earlier for me. I have tried the nightly for several dates since 050131 and none of those seems to work. I finally decided to try the 1.0 release and it has worked. I think you recently posted to someone to try checking out CVS for specific dates and find when it breaks. When I have some time, I'll try that. > My patch is not cleaned up version, it is different and should be > similar to what NDIS does. It is also more efficient. This patch > shouldn't break for amd64; earlier ones are probably the culprits. Okay. Yes, I have had problems before this patch, as stated above, so it is earlier patches that are the problem. Anyone have any tips for using netconsole? I'd really like to get that setup so that I can grab these Oopses. I think I have my laptop setup right, I just cannot figure out how to see stuff on the remote machine. I can't seem to find good documentation. > -- > Giri Thanks, Jonathan |