[PATCH] [Bug 3736] Bug in tty_io.c after changes between 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2
Tried to fix a bug http://bugzilla.kernel.org/show_bug.cgi?id=3736 which appeared between kernels 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2. Suceeded to localize it to part of changes in drivers/char/tty_io.c. I guess changes were according changelog: --- [EMAIL PROTECTED], 2004-08-24 12:29:18-07:00, [EMAIL PROTECTED] [PATCH] /dev/ptmx open() fixes If tty_open() fails for a normal serial device, we end up doing cleanups that should only happen for failed open of /dev/ptmx. The results are not pretty - devpts et.al. end up very confused. That's what gave problems with ptmx. This splits ptmx file_operations from the normal case and cleans up both tty_open() and (new) ptmx_open(). Survived serious beating. --- Finally located that a problem seems to be a simple typo ( --- linux-2.6.10/drivers/char/tty_io.c~1 2004-12-24 23:34:58.0 +0200 +++ linux-2.6.10/drivers/char/tty_io.c 2005-01-22 10:54:32.0 +0200 @@ -1148,7 +1148,7 @@ static inline void pty_line_name(struct int i = index + driver->name_base; /* ->name is initialized to "ttyp", but "tty" is expected */ sprintf(p, "%s%c%x", - driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name, + driver->subtype == PTY_TYPE_SLAVE ? "pty" : driver->name, ptychar[i >> 4 & 0xf], i & 0xf); } At least as I tested, it fixes the problem on one of systems on which I tested. Andris - 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/
[PATCH] [Bug 3736] Bug in tty_io.c after changes between 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2
Tried to fix a bug http://bugzilla.kernel.org/show_bug.cgi?id=3736 which appeared between kernels 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2. Suceeded to localize it to part of changes in drivers/char/tty_io.c. I guess changes were according changelog: --- [EMAIL PROTECTED], 2004-08-24 12:29:18-07:00, [EMAIL PROTECTED] [PATCH] /dev/ptmx open() fixes If tty_open() fails for a normal serial device, we end up doing cleanups that should only happen for failed open of /dev/ptmx. The results are not pretty - devpts et.al. end up very confused. That's what gave problems with ptmx. This splits ptmx file_operations from the normal case and cleans up both tty_open() and (new) ptmx_open(). Survived serious beating. --- Finally located that a problem seems to be a simple typo ( --- linux-2.6.10/drivers/char/tty_io.c~1 2004-12-24 23:34:58.0 +0200 +++ linux-2.6.10/drivers/char/tty_io.c 2005-01-22 10:54:32.0 +0200 @@ -1148,7 +1148,7 @@ static inline void pty_line_name(struct int i = index + driver-name_base; /* -name is initialized to ttyp, but tty is expected */ sprintf(p, %s%c%x, - driver-subtype == PTY_TYPE_SLAVE ? tty : driver-name, + driver-subtype == PTY_TYPE_SLAVE ? pty : driver-name, ptychar[i 4 0xf], i 0xf); } At least as I tested, it fixes the problem on one of systems on which I tested. Andris - 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: 2.4.4-ac[356]: network (8139too) related crashes
On Mon, 28 May 2001, Martin Josefsson wrote: > On Mon, 28 May 2001, Andris Pavenis wrote: > > > On Sunday 27 May 2001 02:34, Alan Cox wrote: > [snip] > > > Can you try 2.4.5 with the 8139too.c file from the 2.4.3-ac3 that works for > > > you and report on that > > > > Done. > > > > Seems that taking 8139too.o from 2.4.3-ac3 fixes the problem. > > > > Tortured it much more as it was required to get 2.4.4-ac[356] and 2.4.5. to > > freeze (FTP uploads and downloads totally more than 100Mb with speed about > > 600Kb/s, for bad version of 8138too.c about 10Mb was usually more than enough > > for freezing) > > I've also been having problems with 2.4.4 (and 2.4.4-ac10). > But my problems havn't been very easy to trigger as sometimes it happens > after a few hours and sometimes after 4 days. > > I have a 8139A card. > > The machine ran 2.4.2-ac6 for a long time without any problems, and then I > switched to 2.4.4 and it hung after 1 day. It was a silent deadlock, it > didn't print anything on the screen and it didn't respond to anything. I had similar deadlocks > Then I switched to the 8139too driver from 2.4.2-ac6 to see if it's > stable. It has 2 days of uptime now so I'll have to wait some more until > I can say if it's stable or not. I was able to trigger this bug rather easy (tested with 2.4.4-ac3, ac5, ac6 and with 2.4.5) or not at all (2.4.3-ac3, perhaps also with 2.4.5 with 8139too.c from 2.4.3-ac3): trying to upload 5-10 Mb (transfer speed was about 500Kb/s) almost surely frozed system. When I tried 2.4.5 with drivers/net/8139too.c from 2.4.3-ac3 I uploaded some tenths of Mb and downloaded more than 100Mb without deadlocks Andris - 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: 2.4.4-ac[356]: network (8139too) related crashes
On Mon, 28 May 2001, Martin Josefsson wrote: On Mon, 28 May 2001, Andris Pavenis wrote: On Sunday 27 May 2001 02:34, Alan Cox wrote: [snip] Can you try 2.4.5 with the 8139too.c file from the 2.4.3-ac3 that works for you and report on that Done. Seems that taking 8139too.o from 2.4.3-ac3 fixes the problem. Tortured it much more as it was required to get 2.4.4-ac[356] and 2.4.5. to freeze (FTP uploads and downloads totally more than 100Mb with speed about 600Kb/s, for bad version of 8138too.c about 10Mb was usually more than enough for freezing) I've also been having problems with 2.4.4 (and 2.4.4-ac10). But my problems havn't been very easy to trigger as sometimes it happens after a few hours and sometimes after 4 days. I have a 8139A card. The machine ran 2.4.2-ac6 for a long time without any problems, and then I switched to 2.4.4 and it hung after 1 day. It was a silent deadlock, it didn't print anything on the screen and it didn't respond to anything. I had similar deadlocks Then I switched to the 8139too driver from 2.4.2-ac6 to see if it's stable. It has 2 days of uptime now so I'll have to wait some more until I can say if it's stable or not. I was able to trigger this bug rather easy (tested with 2.4.4-ac3, ac5, ac6 and with 2.4.5) or not at all (2.4.3-ac3, perhaps also with 2.4.5 with 8139too.c from 2.4.3-ac3): trying to upload 5-10 Mb (transfer speed was about 500Kb/s) almost surely frozed system. When I tried 2.4.5 with drivers/net/8139too.c from 2.4.3-ac3 I uploaded some tenths of Mb and downloaded more than 100Mb without deadlocks Andris - 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: 2.4.4-ac[356]: network (8139too) related crashes
On Wednesday 09 May 2001 22:25, Danny ter Haar wrote: > Andris Pavenis <[EMAIL PROTECTED]> wrote: > >With kernels 2.4.4-ac[356] I'm getting system freezing on FTP transfer > > after some time. I'm trying to upload about 6.5Mb file using MC (transfer > > speed about 300-1000Kb/s). With these kernel versions I'm getting random > > total freezing system (no any kernel error messages, no reaction to > > keyboard, no response to ping from other machine). The same seems to > > happen also when transfer speed is slower (I left wget downloading many > > files 2 nights and both times system was hanged in morning) > > I have similar problems on my sony vaio laptop (pcmcia ethernet > card that works with the 8139too driver) > I send detailed info to Jeff & Alan weeks ago. > > >Kernel 2.4.3-ac3 seems to be Ok. > > Problems started with the change in 2.4.3-ac7. > So up to 2.4.3-ac6 it's fine. > Tried 2.4.5 and got the same problem again. Parhaps I'll sty with 2.4.3-ac3 for now. At least it doesn't freeze ... Andris - 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: 2.4.4-ac[356]: network (8139too) related crashes
On Wednesday 09 May 2001 22:25, Danny ter Haar wrote: Andris Pavenis [EMAIL PROTECTED] wrote: With kernels 2.4.4-ac[356] I'm getting system freezing on FTP transfer after some time. I'm trying to upload about 6.5Mb file using MC (transfer speed about 300-1000Kb/s). With these kernel versions I'm getting random total freezing system (no any kernel error messages, no reaction to keyboard, no response to ping from other machine). The same seems to happen also when transfer speed is slower (I left wget downloading many files 2 nights and both times system was hanged in morning) I have similar problems on my sony vaio laptop (pcmcia ethernet card that works with the 8139too driver) I send detailed info to Jeff Alan weeks ago. Kernel 2.4.3-ac3 seems to be Ok. Problems started with the change in 2.4.3-ac7. So up to 2.4.3-ac6 it's fine. Tried 2.4.5 and got the same problem again. Parhaps I'll sty with 2.4.3-ac3 for now. At least it doesn't freeze ... Andris - 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/
2.4.4-ac[356]: network (8139too) related crashes
With kernels 2.4.4-ac[356] I'm getting system freezing on FTP transfer after some time. I'm trying to upload about 6.5Mb file using MC (transfer speed about 300-1000Kb/s). With these kernel versions I'm getting random total freezing system (no any kernel error messages, no reaction to keyboard, no response to ping from other machine). The same seems to happen also when transfer speed is slower (I left wget downloading many files 2 nights and both times system was hanged in morning) It doesn't seem to happen on other activity (I bootstrapped and run tested current CVS version of GCC-3.0 without problems) I have tested 2.4.4-ac3, ac5 and ac6 and for all all was able to freeze all these versions by uploading such file to different machine (I don't want to make more experiments) Kernel 2.4.3-ac3 seems to be Ok. System: PIII 700, 128Mb, I810 chipset, RTL8139 network card Bus 1, device 10, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 5. Master Capable. Latency=64. Min Gnt=32.Max Lat=64. I/O at 0xd800 [0xd8ff]. Non-prefetchable 32 bit memory at 0xe300 [0xe3ff]. Kernel configuration I used for 2.4.4-ac6 is included below Andris PS. I'm not subscribed to kernel mailing list # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUSMGR=y CONFIG_ACPI_SYS=y CONFIG_ACPI_CPU=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_AC=y CONFIG_ACPI_EC=y CONFIG_ACPI_CMBATT=y CONFIG_ACPI_THERMAL=y # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set CONFIG_PARIDE=y CONFIG_PARIDE_PARPORT=y # CONFIG_PARIDE_PD is not set CONFIG_PARIDE_PCD=y # CONFIG_PARIDE_PF is not set # CONFIG_PARIDE_PT is not set # CONFIG_PARIDE_PG is not set # CONFIG_PARIDE_ATEN is not set # CONFIG_PARIDE_BPCK is not set # CONFIG_PARIDE_BPCK6 is not set # CONFIG_PARIDE_COMM is not set # CONFIG_PARIDE_DSTR is not set # CONFIG_PARIDE_FIT2 is not set # CONFIG_PARIDE_FIT3 is not set CONFIG_PARIDE_EPAT=y # CONFIG_PARIDE_EPIA is not set # CONFIG_PARIDE_FRIQ is not set # CONFIG_PARIDE_FRPW is not set # CONFIG_PARIDE_KBIC is not set # CONFIG_PARIDE_KTTI is not set # CONFIG_PARIDE_ON20 is not set # CONFIG_PARIDE_ON26 is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set #
2.4.4-ac[356]: network (8139too) related crashes
With kernels 2.4.4-ac[356] I'm getting system freezing on FTP transfer after some time. I'm trying to upload about 6.5Mb file using MC (transfer speed about 300-1000Kb/s). With these kernel versions I'm getting random total freezing system (no any kernel error messages, no reaction to keyboard, no response to ping from other machine). The same seems to happen also when transfer speed is slower (I left wget downloading many files 2 nights and both times system was hanged in morning) It doesn't seem to happen on other activity (I bootstrapped and run tested current CVS version of GCC-3.0 without problems) I have tested 2.4.4-ac3, ac5 and ac6 and for all all was able to freeze all these versions by uploading such file to different machine (I don't want to make more experiments) Kernel 2.4.3-ac3 seems to be Ok. System: PIII 700, 128Mb, I810 chipset, RTL8139 network card Bus 1, device 10, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 5. Master Capable. Latency=64. Min Gnt=32.Max Lat=64. I/O at 0xd800 [0xd8ff]. Non-prefetchable 32 bit memory at 0xe300 [0xe3ff]. Kernel configuration I used for 2.4.4-ac6 is included below Andris PS. I'm not subscribed to kernel mailing list # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUSMGR=y CONFIG_ACPI_SYS=y CONFIG_ACPI_CPU=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_AC=y CONFIG_ACPI_EC=y CONFIG_ACPI_CMBATT=y CONFIG_ACPI_THERMAL=y # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set CONFIG_PARIDE=y CONFIG_PARIDE_PARPORT=y # CONFIG_PARIDE_PD is not set CONFIG_PARIDE_PCD=y # CONFIG_PARIDE_PF is not set # CONFIG_PARIDE_PT is not set # CONFIG_PARIDE_PG is not set # CONFIG_PARIDE_ATEN is not set # CONFIG_PARIDE_BPCK is not set # CONFIG_PARIDE_BPCK6 is not set # CONFIG_PARIDE_COMM is not set # CONFIG_PARIDE_DSTR is not set # CONFIG_PARIDE_FIT2 is not set # CONFIG_PARIDE_FIT3 is not set CONFIG_PARIDE_EPAT=y # CONFIG_PARIDE_EPIA is not set # CONFIG_PARIDE_FRIQ is not set # CONFIG_PARIDE_FRPW is not set # CONFIG_PARIDE_KBIC is not set # CONFIG_PARIDE_KTTI is not set # CONFIG_PARIDE_ON20 is not set # CONFIG_PARIDE_ON26 is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set #
Problems with devfs [WAS: Re: devfs breakage in 2.4.0 release]
On Tuesday 23 January 2001 10:25, Andris Pavenis wrote: > On Friday 12 January 2001 13:35, Andris Pavenis wrote: > > On Saturday 06 January 2001 15:28, Andris Pavenis wrote: > > > Noticed following devfs related problems with kernel version 2.4.0 on > > > one Pentium 200MMX box (the same problem with 2.4.0-ac2, but earlier > > > 2.4.0-test10 doesn't have this problem) > > > > > > I was able to reproduce it reliably by following steps: > > > - booted machine in runlevel 3 > > > - logged in as user and started MC (on first console) > > > - logged out > > > - logged in as different user (in this case root) and tried to > > > start MC again > > > > > > This time it hangs. The source of problem appears to be devfs related > > > as devfsd exited with error message that it cannot state vcc/1 as there > > > is no such file or directory. Related parts of log files (boot > > > parameter devfs=dall) and other related information (I hope...) is in > > > attachment. Of course MC is not behaving nicely, but the primary source > > > of problem seems to be devfs > > > > As I tested devfsd dies after I'm logging out (very often on P200MMX, > > much more seldom on P3 700). I suspect some devfs related race > > > > > On this machine kernel was compiled for Pentium CPUs. I tried to > > > reproduce the same on a different machine with Pentium III 700 using > > > kernel 2.4.0. It took more relogging as on Pentium 200, but I got the > > > same problem once (on slower machine I was able to reproduce it more > > > reliably). > > > > I tries 2.4.1-pre3 and got the same. Modifying devfsd.c to retry stating > > some times before giving up workarounds the problem (As far as I tested > > I'm getting only one retry ...) > > > > Perhaps it's kernel's bug anyway, but I think it's doesn't harm to make > > devfsd slightly more errorproof. I'm including patch for devfsd (I had > > also to define __USE_GNU to get devfsd compile with glibc-2.2 at all ...) > > > > Of course best solution would be to fix the race itself (it appeared > > sometimes between 2.4.0-test10 and 2.4.0-test12, first one is OK) > > I spent some time building various kernels on P200MMX box I have this > problem to happen more often. It looks that problem appears in > 2.4.0-test12-pre8 but is not present in 2.4.0-test12-pre7 > Forgot to mention: I have line REGISTERvcc/a* PERMISSIONS root.vcsa rw-rw REGISTERvcc/[0-9] PERMISSIONS root.ttyrw-rw in /etc/devfsd.conf (to change permissions for vcc/* as I don't want to make some applications suid root) So perhaps after logout current of vcc/[0-9] is reregistered, but sometimes devfsd suceeds to try to change permissions before the new node is created and stat() fails (ENOENT) in action_permissions(), as result unpached devfsd-1.3.11 exits with error message. Adding code to retry stat() after some small delay (usleep(1000)) workarounds problem. I'm including full /etc.devfsd in attachment. Andris # Sample /etc/devfsd.conf configuration file. # Richard Gooch <[EMAIL PROTECTED]> 3-FEB-2000 # # Enable full compatibility mode for old device names. You may comment these # out if you don't use the old device names. Make sure you know what you're # doing! REGISTER.* MKOLDCOMPAT UNREGISTER .* RMOLDCOMPAT # You may comment out the above and uncomment the following if you've # configured your system to use the original "new" devfs names or the really # new names #REGISTERvc/.* MKOLDCOMPAT #UNREGISTER vc/.* RMOLDCOMPAT #REGISTERpty/.* MKOLDCOMPAT #UNREGISTER pty/.* RMOLDCOMPAT #REGISTERmiscMKOLDCOMPAT #UNREGISTER miscRMOLDCOMPAT # Enable module autoloading. You may comment this out if you don't use # autoloading LOOKUP .* MODLOAD # You may comment these out if you don't use the original "new" names REGISTER.* MKNEWCOMPAT UNREGISTER .* RMNEWCOMPAT # # REGISTERfloppy/*PERMISSIONS root.floppy rw-rw REGISTERsound/audio PERMISSIONS root.sound rw-rw REGISTERsound/dsp PERMISSIONS root.sound rw-rw REGISTERsound/dspW PERMISSIONS root.sound rw-rw REGISTERsound/mixer PERMISSIONS root.sound rw-rw REGISTERmisc/psaux EXECUTE /bin/ln -s /dev/misc/psaux /dev/mouse REGISTERvcc/a* PERMISSIONS root.vcsa rw-rw REGISTERvcc/[0-9] PERMISSIONS root.ttyrw-rw REGISTERide/host0/bus1/target0/lun0/cd EXECUTE /bin/ln -s /dev/ide/host0/bus1/target0/lun0/cd /dev/cdrom
Re: problem with devfsd compilation
>> I am trying to compile devfsd on my system running RedHat linux 7.0
>> (kernel 2.2.16-22). I get the error "RTLD_NEXT" undefined. I am not
>> sure where this symbol is defined. Is there anything that I am missing
>> on my system.
>
>
>Sounds like a missing include in the devfsd code. That comes from
>dlfcn.h.
Following small patch fixes this and workarounds devfs related problem
which appeared in 2.4.0-test12-pre8:
when I'm logging out, devfsd tries to state /dev/vcc/[1-6] but sometimes
fails perhaps due to some race in kernel. As result devfsd quits with
error message. Retrying to state node suceeds on next attempt.
I don't know why it happens, but I guess it's related to
change in drivers/char/tty_io.c between test12-pre7 and pre8
(change to use flush_scheduled_tasks())
Hint: it seems to be easier to reproduce on slower machine (it happens seldom
on PIII-700, but very often on P200MMX)
Andris
--- devfsd/devfsd.c~1 Mon Jul 3 22:43:07 2000
+++ devfsd/devfsd.c Fri Jan 12 13:19:33 2001
@@ -189,6 +189,7 @@
#include
#include
#include
+#define __USE_GNU
#include
#include
#include
@@ -918,15 +919,29 @@
[RETURNS] Nothing.
*/
{
+int tries=0;
mode_t new_mode;
struct stat statbuf;
+Retry:
if (lstat (info->devname, ) != 0)
{
- SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
- info->devname, ERRSTRING);
- SYSLOG (LOG_ERR, "exiting\n");
- exit (1);
+ if (tries<10)
+ {
+ tries++;
+ SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
+ info->devname, ERRSTRING);
+ SYSLOG (LOG_ERR, "retrying (attempt %d) ...\n",tries);
+ usleep (1000); /* Let's sleep a bit */
+ goto Retry;
+ }
+ else
+ {
+ SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
+ info->devname, ERRSTRING);
+ SYSLOG (LOG_ERR, "exiting\n");
+ exit (1);
+ }
}
new_mode = (statbuf.st_mode & S_IFMT) |
(entry->u.permissions.mode & ~S_IFMT);
-
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: devfs breakage in 2.4.0 release
On Friday 12 January 2001 13:35, Andris Pavenis wrote: > On Saturday 06 January 2001 15:28, Andris Pavenis wrote: > > Noticed following devfs related problems with kernel version 2.4.0 on one > > Pentium 200MMX box (the same problem with 2.4.0-ac2, but earlier > > 2.4.0-test10 doesn't have this problem) > > > > I was able to reproduce it reliably by following steps: > > - booted machine in runlevel 3 > > - logged in as user and started MC (on first console) > > - logged out > > - logged in as different user (in this case root) and tried to > > start MC again > > > > This time it hangs. The source of problem appears to be devfs related as > > devfsd exited with error message that it cannot state vcc/1 as there is > > no such file or directory. Related parts of log files (boot parameter > > devfs=dall) and other related information (I hope...) is in attachment. > > Of course MC is not behaving nicely, but the primary source of problem > > seems to be devfs > > As I tested devfsd dies after I'm logging out (very often on P200MMX, > much more seldom on P3 700). I suspect some devfs related race > > > On this machine kernel was compiled for Pentium CPUs. I tried to > > reproduce the same on a different machine with Pentium III 700 using > > kernel 2.4.0. It took more relogging as on Pentium 200, but I got the > > same problem once (on slower machine I was able to reproduce it more > > reliably). > > I tries 2.4.1-pre3 and got the same. Modifying devfsd.c to retry stating > some times before giving up workarounds the problem (As far as I tested > I'm getting only one retry ...) > > Perhaps it's kernel's bug anyway, but I think it's doesn't harm to make > devfsd slightly more errorproof. I'm including patch for devfsd (I had also > to define __USE_GNU to get devfsd compile with glibc-2.2 at all ...) > > Of course best solution would be to fix the race itself (it appeared > sometimes between 2.4.0-test10 and 2.4.0-test12, first one is OK) > I spent some time building various kernels on P200MMX box I have this problem to happen more often. It looks that problem appears in 2.4.0-test12-pre8 but is not present in 2.4.0-test12-pre7 Andris - 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: devfs breakage in 2.4.0 release
On Friday 12 January 2001 13:35, Andris Pavenis wrote: On Saturday 06 January 2001 15:28, Andris Pavenis wrote: Noticed following devfs related problems with kernel version 2.4.0 on one Pentium 200MMX box (the same problem with 2.4.0-ac2, but earlier 2.4.0-test10 doesn't have this problem) I was able to reproduce it reliably by following steps: - booted machine in runlevel 3 - logged in as user and started MC (on first console) - logged out - logged in as different user (in this case root) and tried to start MC again This time it hangs. The source of problem appears to be devfs related as devfsd exited with error message that it cannot state vcc/1 as there is no such file or directory. Related parts of log files (boot parameter devfs=dall) and other related information (I hope...) is in attachment. Of course MC is not behaving nicely, but the primary source of problem seems to be devfs As I tested devfsd dies after I'm logging out (very often on P200MMX, much more seldom on P3 700). I suspect some devfs related race On this machine kernel was compiled for Pentium CPUs. I tried to reproduce the same on a different machine with Pentium III 700 using kernel 2.4.0. It took more relogging as on Pentium 200, but I got the same problem once (on slower machine I was able to reproduce it more reliably). I tries 2.4.1-pre3 and got the same. Modifying devfsd.c to retry stating some times before giving up workarounds the problem (As far as I tested I'm getting only one retry ...) Perhaps it's kernel's bug anyway, but I think it's doesn't harm to make devfsd slightly more errorproof. I'm including patch for devfsd (I had also to define __USE_GNU to get devfsd compile with glibc-2.2 at all ...) Of course best solution would be to fix the race itself (it appeared sometimes between 2.4.0-test10 and 2.4.0-test12, first one is OK) I spent some time building various kernels on P200MMX box I have this problem to happen more often. It looks that problem appears in 2.4.0-test12-pre8 but is not present in 2.4.0-test12-pre7 Andris - 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: devfs breakage in 2.4.0 release
On Saturday 06 January 2001 15:28, Andris Pavenis wrote:
> Noticed following devfs related problems with kernel version 2.4.0 on one
> Pentium 200MMX box (the same problem with 2.4.0-ac2, but earlier
> 2.4.0-test10 doesn't have this problem)
>
> I was able to reproduce it reliably by following steps:
> - booted machine in runlevel 3
> - logged in as user and started MC (on first console)
> - logged out
> - logged in as different user (in this case root) and tried to
> start MC again
>
> This time it hangs. The source of problem appears to be devfs related as
> devfsd exited with error message that it cannot state vcc/1 as there is no
> such file or directory. Related parts of log files (boot parameter
> devfs=dall) and other related information (I hope...) is in attachment. Of
> course MC is not behaving nicely, but the primary source of problem seems
> to be devfs
As I tested devfsd dies after I'm logging out (very often on P200MMX,
much more seldom on P3 700). I suspect some devfs related race
> On this machine kernel was compiled for Pentium CPUs. I tried to reproduce
> the same on a different machine with Pentium III 700 using kernel 2.4.0.
> It took more relogging as on Pentium 200, but I got the same problem once
> (on slower machine I was able to reproduce it more reliably).
>
I tries 2.4.1-pre3 and got the same. Modifying devfsd.c to retry stating
some times before giving up workarounds the problem (As far as I tested
I'm getting only one retry ...)
Perhaps it's kernel's bug anyway, but I think it's doesn't harm to make
devfsd slightly more errorproof. I'm including patch for devfsd (I had also
to define __USE_GNU to get devfsd compile with glibc-2.2 at all ...)
Of course best solution would be to fix the race itself (it appeared sometimes
between 2.4.0-test10 and 2.4.0-test12, first one is OK)
Andris
--- devfsd/devfsd.c~1 Mon Jul 3 22:43:07 2000
+++ devfsd/devfsd.c Fri Jan 12 13:19:33 2001
@@ -189,6 +189,7 @@
#include
#include
#include
+#define __USE_GNU
#include
#include
#include
@@ -918,15 +919,29 @@
[RETURNS] Nothing.
*/
{
+int tries=0;
mode_t new_mode;
struct stat statbuf;
+Retry:
if (lstat (info->devname, ) != 0)
{
- SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
- info->devname, ERRSTRING);
- SYSLOG (LOG_ERR, "exiting\n");
- exit (1);
+ if (tries<10)
+ {
+ tries++;
+ SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
+ info->devname, ERRSTRING);
+ SYSLOG (LOG_ERR, "retrying (attempt %d) ...\n",tries);
+ usleep (1000); /* Let's sleep a bit */
+ goto Retry;
+ }
+ else
+ {
+ SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
+ info->devname, ERRSTRING);
+ SYSLOG (LOG_ERR, "exiting\n");
+ exit (1);
+ }
}
new_mode = (statbuf.st_mode & S_IFMT) |
(entry->u.permissions.mode & ~S_IFMT);
-
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: devfs breakage in 2.4.0 release
On Saturday 06 January 2001 15:28, Andris Pavenis wrote:
Noticed following devfs related problems with kernel version 2.4.0 on one
Pentium 200MMX box (the same problem with 2.4.0-ac2, but earlier
2.4.0-test10 doesn't have this problem)
I was able to reproduce it reliably by following steps:
- booted machine in runlevel 3
- logged in as user and started MC (on first console)
- logged out
- logged in as different user (in this case root) and tried to
start MC again
This time it hangs. The source of problem appears to be devfs related as
devfsd exited with error message that it cannot state vcc/1 as there is no
such file or directory. Related parts of log files (boot parameter
devfs=dall) and other related information (I hope...) is in attachment. Of
course MC is not behaving nicely, but the primary source of problem seems
to be devfs
As I tested devfsd dies after I'm logging out (very often on P200MMX,
much more seldom on P3 700). I suspect some devfs related race
On this machine kernel was compiled for Pentium CPUs. I tried to reproduce
the same on a different machine with Pentium III 700 using kernel 2.4.0.
It took more relogging as on Pentium 200, but I got the same problem once
(on slower machine I was able to reproduce it more reliably).
I tries 2.4.1-pre3 and got the same. Modifying devfsd.c to retry stating
some times before giving up workarounds the problem (As far as I tested
I'm getting only one retry ...)
Perhaps it's kernel's bug anyway, but I think it's doesn't harm to make
devfsd slightly more errorproof. I'm including patch for devfsd (I had also
to define __USE_GNU to get devfsd compile with glibc-2.2 at all ...)
Of course best solution would be to fix the race itself (it appeared sometimes
between 2.4.0-test10 and 2.4.0-test12, first one is OK)
Andris
--- devfsd/devfsd.c~1 Mon Jul 3 22:43:07 2000
+++ devfsd/devfsd.c Fri Jan 12 13:19:33 2001
@@ -189,6 +189,7 @@
#include signal.h
#include regex.h
#include errno.h
+#define __USE_GNU
#include dlfcn.h
#include rpcsvc/ypclnt.h
#include rpcsvc/yp_prot.h
@@ -918,15 +919,29 @@
[RETURNS] Nothing.
*/
{
+int tries=0;
mode_t new_mode;
struct stat statbuf;
+Retry:
if (lstat (info-devname, statbuf) != 0)
{
- SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
- info-devname, ERRSTRING);
- SYSLOG (LOG_ERR, "exiting\n");
- exit (1);
+ if (tries10)
+ {
+ tries++;
+ SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
+ info-devname, ERRSTRING);
+ SYSLOG (LOG_ERR, "retrying (attempt %d) ...\n",tries);
+ usleep (1000); /* Let's sleep a bit */
+ goto Retry;
+ }
+ else
+ {
+ SYSLOG (LOG_ERR, "error stat(2)ing: \"%s\"\t%s\n",
+ info-devname, ERRSTRING);
+ SYSLOG (LOG_ERR, "exiting\n");
+ exit (1);
+ }
}
new_mode = (statbuf.st_mode S_IFMT) |
(entry-u.permissions.mode ~S_IFMT);
-
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: devfs breakage in 2.4.0 release
On Sat, 6 Jan 2001, Adam J. Richter wrote: > On my Sony PictureBook PCG-C1VN, 2.4.0 hangs in the boot > process while 2.4.0-prerelease boots just fine. At first I thought > the problem was devfs-related, but skipping devfsd just caused the > hang to occur a little later, this time in ifconfig. The kernel > call trace looked something like this: > > neigh_ifdown > sys_ioctl > sock_ioctl > [some addresses in modules] > stext_lock > __down_failed > __down > > What surprised me more was that attempting to remount the > root filesystem for writing just before this (to record the module > kernel symbols) caused a kenel BUG() in slab.c:1542 becuase kmalloc > was being called with a huge negative number. > > I know I could run ksymoops to get this trace, but I now > think the cause of the problem probably happens much earlier than > the symptoms. So, I trying backing out different 2.4.0 changes. > So far, I can tell you that reverting the linux/mm subdirectory to > its 2.4.0-prerelease contents had no effect. I will let you know > if I diagnose or fix the problem, as I think you may be experiencing > the same problem. I think it's a different problem. I reproduced the same with 2.4.0-test12 but not 2.4.0-test10. There are changes (not very large) in fs/devfs/base.c between these versions. I tried to take 2.4.0 and change back these updates and saw that it doesn't fix the problem. Trying all prerelaeses between 2.4.0-test10 and 2.4.0-test12 perhaps would take too much time ... There is no hanging (or crashes) at all for me. All these versions boots Ok for me, but what I have is devfsd quitting with error message that it cannot state /dev/vcc/[1-6] after some relooging from the same terminal. Andris - 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: devfs breakage in 2.4.0 release
On Sat, 6 Jan 2001, Adam J. Richter wrote: On my Sony PictureBook PCG-C1VN, 2.4.0 hangs in the boot process while 2.4.0-prerelease boots just fine. At first I thought the problem was devfs-related, but skipping devfsd just caused the hang to occur a little later, this time in ifconfig. The kernel call trace looked something like this: neigh_ifdown sys_ioctl sock_ioctl [some addresses in modules] stext_lock __down_failed __down What surprised me more was that attempting to remount the root filesystem for writing just before this (to record the module kernel symbols) caused a kenel BUG() in slab.c:1542 becuase kmalloc was being called with a huge negative number. I know I could run ksymoops to get this trace, but I now think the cause of the problem probably happens much earlier than the symptoms. So, I trying backing out different 2.4.0 changes. So far, I can tell you that reverting the linux/mm subdirectory to its 2.4.0-prerelease contents had no effect. I will let you know if I diagnose or fix the problem, as I think you may be experiencing the same problem. I think it's a different problem. I reproduced the same with 2.4.0-test12 but not 2.4.0-test10. There are changes (not very large) in fs/devfs/base.c between these versions. I tried to take 2.4.0 and change back these updates and saw that it doesn't fix the problem. Trying all prerelaeses between 2.4.0-test10 and 2.4.0-test12 perhaps would take too much time ... There is no hanging (or crashes) at all for me. All these versions boots Ok for me, but what I have is devfsd quitting with error message that it cannot state /dev/vcc/[1-6] after some relooging from the same terminal. Andris - 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/
devfs breakage in 2.4.0 release
Noticed following devfs related problems with kernel version 2.4.0 on one Pentium 200MMX box (the same problem with 2.4.0-ac2, but earlier 2.4.0-test10 doesn't have this problem) I was able to reproduce it reliably by following steps: - booted machine in runlevel 3 - logged in as user and started MC (on first console) - logged out - logged in as different user (in this case root) and tried to start MC again This time it hangs. The source of problem appears to be devfs related as devfsd exited with error message that it cannot state vcc/1 as there is no such file or directory. Related parts of log files (boot parameter devfs=dall) and other related information (I hope...) is in attachment. Of course MC is not behaving nicely, but the primary source of problem seems to be devfs On this machine kernel was compiled for Pentium CPUs. I tried to reproduce the same on a different machine with Pentium III 700 using kernel 2.4.0. It took more relogging as on Pentium 200, but I got the same problem once (on slower machine I was able to reproduce it more reliably). Andris devfs.err.gz
devfs breakage in 2.4.0 release
Noticed following devfs related problems with kernel version 2.4.0 on one Pentium 200MMX box (the same problem with 2.4.0-ac2, but earlier 2.4.0-test10 doesn't have this problem) I was able to reproduce it reliably by following steps: - booted machine in runlevel 3 - logged in as user and started MC (on first console) - logged out - logged in as different user (in this case root) and tried to start MC again This time it hangs. The source of problem appears to be devfs related as devfsd exited with error message that it cannot state vcc/1 as there is no such file or directory. Related parts of log files (boot parameter devfs=dall) and other related information (I hope...) is in attachment. Of course MC is not behaving nicely, but the primary source of problem seems to be devfs On this machine kernel was compiled for Pentium CPUs. I tried to reproduce the same on a different machine with Pentium III 700 using kernel 2.4.0. It took more relogging as on Pentium 200, but I got the same problem once (on slower machine I was able to reproduce it more reliably). Andris devfs.err.gz
Re: vfat problems in 2.4.0-test10-pre2
On Friday 13 October 2000 19:55, Petr Vandrovec wrote: > I missed original problem, but what about this one? Fixes extension > in MSDOS namespace when filename is longer than 12 chars... Someone > familiar with VFAT should look whether VFAT multibyte code cannot be > cleaned up a bit... When I was fixing 'break out of now nested loop' > for pre7, I missed this one. Sorry. > > If it works for you, either forward it to Linus, or tell me and I'll > send it - but I do not send patches during weekend ;-) . I do not use > VFAT to much personally, so more eyes... Thanks. I verified that the problem is present in 2.4.0-test9, after tested that patch fixes the problem (I wrote the same files in the same directory on VFAT32 partition). Now testing disk didn't show any problems (earlier it reported LFN problems) Andris PS. I haven't sent patch to Linus - 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: vfat problems in 2.4.0-test10-pre2
I have the same problem. As far as I remeber it appeared most likely beginning with 2.4.0-test7 (or maybe test6) Andris - 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: vfat problems in 2.4.0-test10-pre2
I have the same problem. As far as I remeber it appeared most likely beginning with 2.4.0-test7 (or maybe test6) Andris - 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: vfat problems in 2.4.0-test10-pre2
On Friday 13 October 2000 19:55, Petr Vandrovec wrote: I missed original problem, but what about this one? Fixes extension in MSDOS namespace when filename is longer than 12 chars... Someone familiar with VFAT should look whether VFAT multibyte code cannot be cleaned up a bit... When I was fixing 'break out of now nested loop' for pre7, I missed this one. Sorry. If it works for you, either forward it to Linus, or tell me and I'll send it - but I do not send patches during weekend ;-) . I do not use VFAT to much personally, so more eyes... Thanks. I verified that the problem is present in 2.4.0-test9, after tested that patch fixes the problem (I wrote the same files in the same directory on VFAT32 partition). Now testing disk didn't show any problems (earlier it reported LFN problems) Andris PS. I haven't sent patch to Linus - 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/
