Bug 7295
| Summary: | kernel oops when using cisco vpnclient | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Ritesh Raj Sarraf (linux-kernel-bugs) |
| Component: | IEEE1394 | Assignee: | drivers_ieee1394 |
| Status: | CLOSED INVALID | ||
| Severity: | normal | CC: | bunk |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.18 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
|
Description
Ritesh Raj Sarraf
2006-10-09 22:53:26 UTC
Bugs with binary-only modules loaded (you are using at least two of them) are not debuggable. Please ask the vendors of these modules for support. If this didn't happen in 2.6.17, it would be helpful if you could check for possible culprits among the ieee1394 driver updates from 2.6.17 to 2.6.18: http://me.in-berlin.de/~s5r6/linux1394/merged/in_2.6.18/ I could bring this patch collection into proper order so that you can biject them (e.g. with quilt). Should I prepare this on top of plain 2.6.17 or on any 2.6.17.x? There were also ieee1394 patches in 2.6.17.2, .8, .11. Bijecting on top of plain 2.6.17 would check these -stable patches too. We could also stack the reverse of the patches on top of 2.6.18, or at least almost all of them. There was only a single patch to eth1394 which you could test first. In reply to comment #1: If a binary only module is not acceptable and you won't fix it, why don't you simply deny load of such modules. If you want to stop binary-only modules, don't have any such framework for it. First you show the path, and then you mandate to walk your way. Why not first teach them to work your way and then give them access to the path. The module support was not made for binary-only modules. Whether binary-only modules are legal at all is a disputed question only lawyers can decide. But the point why bugs with binary-only modules loaded are innvalid here is that a module can do ANYTHING, and we've already had too many seemingly unrelated bugs that turned out to be caused by binary-only modules, and that were undebuggable since we don't have the source for the binary-only modules. Adrian said they are _not debuggable_ rather than _not acceptable_. You can load them, and you can try to debug them on your own or with the help of the authors of this module. Before you do so you could check for a potential regression of eth1394 like I suggested. Please say so if you like to get the 2.6.17-to-2.6.18 FireWire patch series rearranged for this purpose. But you could also use git to do so, using a clone of Linus' tree and bijecting between the known good and bad snapshots. If you find the point were it broke, we can try to get a clue if the issue is with Linux or with the VPN client. But the findings could also turn out inconclusive, which would shift the burden to Cisco. PS: I absolutely agree to keep this bug 'REJECTED INVALID', unless rrs is able to dig out an actual kernel bug. Hi, I was just looking into the installer package of the cisco vpnclient. You mentioned in comment #1 seeing 2 binary-only modules loaded. One is nvidia. Can you tell the other one please. I hope that my understanding that ipw3945 is not a binary-only module is correct. If yes, then the cisco_ipsec module shouldn't also qualify as a binary only module. The source code to build the kernel module is provided in the tar.gz file. It, same as ipw3945, copies its binary daemon (cvpnd), libraries and init scripts. The files that build the cisco_ipsec module are provided with the package. Would be great if you could have a look to see if it really is a candidate for a binary-only module. Unless module authors play tricks, 'dmesg | grep taint' should show which modules tainted the kernel, AFAIK. BTW the term 'binary only' is a bit misleading: nVidia's driver for example come in several parts; two of them run in the kernel's address space: A thin open source interface layer and the actual kernel driver which is closed source. AFAIK cisco_ipsec, i.e. the component that is loaded into the kernel's address space, is partly closed source too. Or did they release it as open source now? One binary-only module (nvidia) makes it undebuggable. At least three external modules are loaded, and even one of them alone might will make it off-topic here. Even further, you seem to simply ignore Stefan's request to check whether any of the ieee1394 updates in 2.6.18 caused your breakage. There are rules what's offtopic here and what is ontopic. It's simply required to set limits since the (often spare) time people are spending on debugging kernel bugs here is not unlimited. There are people offering technical consultancy that might spend as much time as you want to pay them for on helping you debugging your problems. On request, I could have reproduced the bug without the nvidia module. Yes, I've been avoiding Stefan's request because: a) I'm not a Kernel Developer b) Nor a Q.A. c) I'm an end-user using Linux on my laptop busy with my own deadlines I filed the bug because I found it. And I keep the tendency to report such bugs so that people remain aware. The argument of whether it is a valid bug or not, whether binary-only modules should be allowed or not, is not my domain. Hence, closing it. |