bug in scsi.c
hello, I have found a problem in scsi.c which in present in the 2.2 and 2.4 series. the scsi error handler thread is created with: kernel_thread((int (*)(void *)) scsi_error_handler, (void *) shpnt, 0); This will lead to problems, when you have to umount the filesystem on which the scsi-hostapter module is located. To solve to problem I would propose to change this to: kernel_thread((int (*)(void *)) scsi_error_handler, (void *) shpnt, CLONE_FILES); Bye, -- Andreas Klein [EMAIL PROTECTED] root / webmaster @cip.physik.uni-wuerzburg.de root / webmaster @www.physik.uni-wuerzburg.de _ | | | Long live our gracious AMIGA! | |___| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bug in scsi.c
On Thu, 7 Dec 2000, Tigran Aivazian wrote: > On Thu, 7 Dec 2000, Andreas Klein wrote: > > > hello, > > > > I have found a problem in scsi.c which in present in the 2.2 and 2.4 > > series. the scsi error handler thread is created with: > > > > kernel_thread((int (*)(void *)) scsi_error_handler, > > (void *) shpnt, 0); > > > > This will lead to problems, when you have to umount the filesystem on > > which the scsi-hostapter module is located. > > To solve to problem I would propose to change this to: > > > > kernel_thread((int (*)(void *)) scsi_error_handler, > > (void *) shpnt, CLONE_FILES); > > Hi Andreas, > > Unfortunately, CLONE_FILES is not enough because the module may be loaded > from the directory containing it, i.e. the thread's cwd may point to that > filesystem and that would keep it busy. Or-ing CLONE_FS into flags > wouldn't help either... Yes, you are right with that. > A proper way to release the references to resources is to call daemonize() > function from within the kernel thread function, which calls > exit_fs()/exit_files() internally. Nearly correct, the daemonize function does NOT call exit_files. This has to be done manually. Looking at the 2.4.0-test10 source I saw, that someone has already fixed the problem by calling exit_files and daemonize. In the 2.2 series someone tried cut-copy-paste programing from the daemonize function, but exit_files was forgotten. The following patch should fix the problem for 2.2.16, while leaving scsi.c untouched. --- linux/drivers/scsi/scsi_error.c.origThu Dec 7 23:56:47 2000 +++ linux/drivers/scsi/scsi_error.c Fri Dec 8 00:13:20 2000 @@ -1935,6 +1935,7 @@ * user space pages. We don't need them, and if we didn't close them * they would be locked into memory. */ + exit_files(current); exit_mm(current); current->session = 1; Bye, -- Andreas Klein [EMAIL PROTECTED] root / webmaster @cip.physik.uni-wuerzburg.de root / webmaster @www.physik.uni-wuerzburg.de _ | | | Long live our gracious AMIGA! | |___| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bug in scsi.c
On Thu, 7 Dec 2000, Alan Cox wrote: > Andreas is looking at a slightly older kernel, and was right for that. Every > caller to daemonize either then did the file stuff or needed to and forgot > so I fixed daemonize I think, there ist still a small bug. (This time I even checked 2.4.0-test12-pre8) In linux/arch/i386/kernel/process.c, function kernel_thread, line 453 the flag CLONE_VM is always used. In sched.c, function daemonize, line 1216 you call exit_mm. Since the memory is cloned, you will take away the mem from your user-space-application as well. So if insmod is already running at that time, it has to segvault. If I am not wrong at this point CLONE_VM simply has to be removed from kernel_thread. The kernel-thread will free his mem in daemonize (calling exit_mm) and the user-space-application will free the mem when exiting. Bye, -- Andreas Klein [EMAIL PROTECTED] root / webmaster @cip.physik.uni-wuerzburg.de root / webmaster @www.physik.uni-wuerzburg.de _ | | | Long live our gracious AMIGA! | |___| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reiserfs-oops; kernel 2.4.3-pre4
hello, I got the following oops: ksymoops 2.4.0 on i686 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map-2.4.3-pre4 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Mar 15 00:56:10 wptx99 kernel: Unable to handle kernel NULL pointer dereference at virtual address 0108 Mar 15 00:56:10 wptx99 kernel: c016f090 Mar 15 00:56:10 wptx99 kernel: *pde = Mar 15 00:56:10 wptx99 kernel: Oops: Mar 15 00:56:10 wptx99 kernel: CPU:1 Mar 15 00:56:10 wptx99 kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Mar 15 00:56:10 wptx99 kernel: EFLAGS: 00010286 Mar 15 00:56:10 wptx99 kernel: eax: 0108 ebx: 0108 ecx: de785ebc edx: ce09d488 Mar 15 00:56:10 wptx99 kernel: esi: 0001 edi: de785e58 ebp: d13c17c0 esp: de785e1c Mar 15 00:56:10 wptx99 kernel: ds: 0018 es: 0018 ss: 0018 Mar 15 00:56:10 wptx99 kernel: Process nfsd (pid: 712, stackpage=de785000) Mar 15 00:56:10 wptx99 kernel: Stack: de785ebc c0160046 0108 de785ebc 0001 0002 Mar 15 00:56:10 wptx99 kernel:c015c8a8 c18ec400 de785ebc fff4 de784000 d13c17c0 df6ee060 0001 Mar 15 00:56:10 wptx99 kernel: cf73dc60 cf73d6c0 Mar 15 00:56:10 wptx99 kernel: Call Trace: [] [] [] [] [] [] [] Mar 15 00:56:10 wptx99 kernel:[] [] [] [] [] [] [] [] Mar 15 00:56:10 wptx99 kernel: Code: 8b 13 8b 01 39 c2 73 08 b8 ff ff ff ff eb 1e 90 39 c2 76 0c >>EIP; c016f090<= Trace; c0160046 Trace; c015c8a8 Trace; c013e39d Trace; e0e039b1 <[nfsd].rodata.start+1771/3913> Trace; c013e43f Trace; e0df8f8b <[nfsd]nfsd_lookup+3cb/528> Trace; e0df6c8c <[nfsd]nfsd_proc_lookup+8c/a0> Trace; e0e05c80 <[nfsd]nfsd_procedures2+80/240> Trace; e0df6593 <[nfsd]nfsd_dispatch+cb/168> Trace; e0e05c80 <[nfsd]nfsd_procedures2+80/240> Trace; e0ddd52f <[sunrpc]svc_process+297/4d8> Trace; e0e05b68 <[nfsd]nfsd_version2+0/10> Trace; e0df63ad <[nfsd]nfsd+225/340> Trace; e0e05b60 <[nfsd]nfsd_list+0/0> Trace; c01074c4 Code; c016f090 <_EIP>: Code; c016f090<= 0: 8b 13 mov(%ebx),%edx <= Code; c016f092 2: 8b 01 mov(%ecx),%eax Code; c016f094 4: 39 c2 cmp%eax,%edx Code; c016f096 6: 73 08 jae10 <_EIP+0x10> c016f0a0 Code; c016f098 8: b8 ff ff ff ffmov$0x,%eax Code; c016f09d d: eb 1e jmp2d <_EIP+0x2d> c016f0bd Code; c016f09f f: 90nop Code; c016f0a0 10: 39 c2 cmp%eax,%edx Code; c016f0a2 12: 76 0c jbe20 <_EIP+0x20> c016f0b0 1 warning issued. Results may not be reliable. The machine is running linux-2.4.3-pre4 including the reiserfs-patches from Alexander Zarochentcev. The filesystem was created with mkreiserfs 3.x.0h Bye, -- Andreas Klein [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AVM A1 pcmcia, kernel 2.4.5-ac11 problem
Hello,
On Wed, 13 Jun 2001, Kai Germaschewski wrote:
> On Tue, 12 Jun 2001, Boenisch Joerg wrote:
>
> If you dig it up somewhere and get it working with 2.4.5, it would be nice
> if you let me know. We can then work together to integrate it into the
> kernel tree - I can't do it myself, because I don't have the card.
>
> --Kai
I am using the attached patch without problems with the 2.4.X series of
the linux-kernel (at the moment I am runnign 2.4.5-ac13). The patch is the
same, as the one Jochen Friedrich has sent a few day ago (including a
small fix).
Bye,
-- Andreas Klein
[EMAIL PROTECTED]
root / webmaster @cip.physik.uni-wuerzburg.de
root / webmaster @www.physik.uni-wuerzburg.de
_
| |
| Long live our gracious AMIGA! |
|___|
diff -u -r -N linux/drivers/isdn/Makefile linux-2.4.2/drivers/isdn/Makefile
--- linux/drivers/isdn/Makefile Fri Dec 29 23:40:54 2000
+++ linux-2.4.2/drivers/isdn/Makefile Sat Mar 10 15:55:59 2001
@@ -45,6 +45,15 @@
subdir-$(CONFIG_ISDN_DRV_EICON)+= eicon
subdir-$(CONFIG_HYSDN) += hysdn
+ifeq ($(CONFIG_PCMCIA),y)
+ subdir-y += pcmcia
+ subdir-m += pcmcia
+else
+ ifeq ($(CONFIG_PCMCIA),m)
+subdir-m += pcmcia
+ endif
+endif
+
obj-y += $(addsuffix /vmlinux-obj.o, $(subdir-y))
# The global Rules.make.
diff -u -r -N linux/drivers/isdn/pcmcia/Makefile
linux-2.4.2/drivers/isdn/pcmcia/Makefile
--- linux/drivers/isdn/pcmcia/Makefile Thu Jan 1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/MakefileSat Mar 10 15:55:30 2001
@@ -0,0 +1,20 @@
+#
+# Makefile for drivers/isdn/pcmcia
+#
+# Note! Dependencies are done automagically by 'make dep', which also
+# removes any old dependencies. DON'T put your own dependencies here
+# unless it's something special (ie not a .c file).
+#
+
+obj-y :=
+obj-n :=
+obj-m :=
+obj-:=
+
+ifeq ($(CONFIG_ISDN_DRV_HISAX),m)
+ ifeq ($(CONFIG_HISAX_AVM_A1_PCMCIA),y)
+obj-m += avma1_cs.o
+ endif
+endif
+
+include $(TOPDIR)/Rules.make
diff -u -r -N linux/drivers/isdn/pcmcia/avma1_cs.c
linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c
--- linux/drivers/isdn/pcmcia/avma1_cs.cThu Jan 1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c Sat Mar 10 15:55:30 2001
@@ -0,0 +1,541 @@
+/*==
+
+A PCMCIA client driver for AVM B1/M1/M2
+
+Written by Carsten Paeth, [EMAIL PROTECTED]
+
+==*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+int avm_a1_init_pcmcia(void *pcm_iob, int pcm_irq, int *busy_flag, int prot);
+void HiSax_closecard(int cardnr);
+
+
+/*
+ All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If
+ you do not define PCMCIA_DEBUG at all, all the debug code will be
+ left out. If you compile with PCMCIA_DEBUG=0, the debug code will
+ be present but disabled -- but it can then be enabled for specific
+ modules at load time with a 'pc_debug=#' option to insmod.
+*/
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+MODULE_PARM(pc_debug, "i");
+#define DEBUG(n, args...) if (pc_debug>(n)) printk(KERN_DEBUG args);
+static char *version =
+"avma1_cs.c 1.00 1998/01/23 10:00:00 (Carsten Paeth)";
+#else
+#define DEBUG(n, args...)
+#endif
+
+/**/
+
+/* Parameters that can be set with 'insmod' */
+
+static int default_irq_list[11] = { 15, 13, 12, 11, 10, 9, 7, 5, 4, 3, -1 };
+static int irq_list[11] = { -1 };
+static int isdnprot = 2;
+
+MODULE_PARM(irq_list, "1-11i");
+MODULE_PARM(isdnprot, "1-4i");
+
+/**/
+
+/*
+ The event() function is this driver's Card Services event handler.
+ It will be called by Card Services when an appropriate card status
+ event is received. The config() and release() entry points are
+ used to configure or release a socket, in response to card insertion
+ and ejection events. They are invoked from the skeleton event
+ handler.
+*/
+
+static void avma1cs_config(dev_link_t *link);
+static void avma1cs_release(u_long arg);
+static int avma1cs_event(event_t event, int priority,
+ event_callback_args_t *args);
+
+/*
+ The attach() and detach() entry points are used to create and destroy
+ "instances" of the driver, where each instance represents everything
+ needed to manage one actual PCMCIA card.
+*/
+
+static dev_link_t *avma1cs_a
