Re: 2.4.3, VMWare, 2 VMs
Petr Vandrovec wrote: > > On 9 Apr 01 at 12:03, Wade Hampton wrote: > > > Is anyone having problems with running more than > As I already answered on VMware newsgroups: Thanks. I didn't see the post on the VMware newsgroup > VMware's 2.0.3 vmmon module uses save_flags() + cli() > in poll() fops, and after this cli() it calls > spin_lock() :-( It is not safest thing to do. > But it should not cause reboot. You should get > > /dev/vmmon: 11 wait for global VM lock XX I had over 2000 of those in /var/log/messages (not counting the "repeated" lines in /var/log/messages). Yep, that's the problem > > and now dead machine with disabled interrupts... Yes, basically a dead machine with NO response to anything > > As all other callers of HostIF_GlobalVMLock() hold > big kernel lock, easiest thing to do is to add > lock_kernel()/unlock_kernel() around LinuxDriver_Poll() > body. > > Removing whole save_flags/cli is for sure much better, > but it is still in my queue (if you are looking into vmmon > driver, then whole poll mess is there to get wakeup on > next jiffy, and not on next + one...). No, I can wait for the a release that fixes this. If you have a patch or test version, send it to me and I'll test it on my development machine For now, I'll just not use 2 VMs until it is fixed. Cheers, -- W. Wade, Hampton <[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/
2.4.3, VMWare, 2 VMs
Greetings, Is anyone having problems with running more than 1 VM on 2.4.3. I have crashed my host O/S several times when I try to start two VMs. Currently, I don't have an oops or other info to report, but I did see a post on the vmware list about 2.4.3 SMP and VMWARE. Host: dual PIII/800, 256 M RAM, RedHat 6.2 with updates, 2.4.3 VM1: RedHat 7.0 with recent updates VM2: RedHat 7.0 with 2.4.3 and LIDS Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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/
OPPS with 2.4.3 and LIDS
See attached oops description. -- W. Wade, Hampton <[EMAIL PROTECTED]> BUG report for vmguest5 on Mon Apr 9 07:00:32 EDT 2001 [1.] One line summary of the problem: Kernel oops with 2.4.3+LIDS running under VMWare [2.] Full description of the problem/report: The machine that crashed is a RedHat 7.0 virtual host running under VMWare 2.0.3 on a RedHat 6.2 base host. The virtual host has 2.4.3 with LIDS 1.0.7. This report is on the virtual host that includes LIDS. Over the weekend, I had two VMs running on my Linux box (RH 6.2 with 2.4.3), but apparently there is an issue with vmware and 2.4.3 SMP. The box locked up (base O/S). Note, 2.4.3 seems much better than 2.4.1 for vmware lockups with 2 VMs, but still I don't recommend it, yet. This is a separate issue and I have yet to get an oops I can report. This will be a separate report This morning, I rebooted the base O/S, then once it was up and functioning properly, I started the test VM with LIDS. The test VM started booting, then came to the login prompt. It then started running slocate, etc. A few minutes after booting, I got the OOPS. [3.] Keywords (i.e., modules, networking, kernel): kernel 2.4.3, VMWare, LIDS [4.] Kernel version (from /proc/version): Linux version 2.4.3 (root@vmguest5) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #3 Fri Apr 6 10:40:10 EDT 2001 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) Trace; c012dc3b Trace; c01fccf5 Trace; c01fcbb0 Trace; c011a0c3 Trace; c01163fc Trace; c0116306 Trace; c011620b Trace; c01083af Trace; c0106fd0 Original OOPS: LIDS: slocate (3 5 inode 96962) pid 1220 ppid 1218 user (0/0) on NULL tty: voliated CAP_DAC_READ_SEARCH kernelb BUG at slab.c:1073! invalid operand: CPU:0 EIP:0010:[c012d99b>] EFLAGS: 0286 ... Process sendmail (pid: 1552, stackpage c397b000) Stack: c0219f9e c021a03e 0431 00030002 c159bbfc c1134050 c25b5005 0026c8ca 0003 0015 c1117570 0007 c1263d20 c012dc3b c1117570 0007 0282 0001 c111b260 1000 c22089e0 000c c01fccf5 Call Trace: [] [] [] [] [] [] [] [] [] Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing [6.] A small shell script or example program which triggers the problem (if possible) none [7.] Environment [7.1.] Software (add the output of the ver_linux script here) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Base O/S: - RedHat 6.2 (VA) with updates - Kernel 2.4.3 - VMWare 2.0.3 VMHost O/S (the one that crashed): - RedHat 7.0 with updates - Kernel 2.4.3 - part of pcnet32 patch removed to get it to work (previous kernel msgs) - LIDS 1.0.7 patch Linux vmguest5 2.4.3 #3 Fri Apr 6 10:40:10 EDT 2001 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.0.18 util-linux 2.10m modutils 2.3.21 e2fsprogs 1.18 pcmcia-cs 3.1.19 Linux C Library> libc.2.2 Dynamic linker (ldd) 2.2 Procps 2.0.7 Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded pcnet32 sb sb_lib uart401 sound soundcore [7.2.] Processor information (from /proc/cpuinfo): Base O/S: - Dual PIII/800 VMHost O/S (the one that crashed): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 931.349 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1228.80 [7.3.] Module information (from /proc/modules): pcnet3211600 1 (autoclean) sb 7520 0 (unused) sb_lib 34528 0 [sb] uart401 6416 0 [sb_lib] sound 58864 0 [sb_lib uart401] soundcore 4080 5 [sb_lib sound] [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0220-022f : soundblaster 02e8-02ef : serial(auto) 02f8-02ff : serial(auto) 0330-0333 : MPU-401 UART 0376-0376 : ide1 03c0-03df : vga+ 03e8-03ef : serial(auto) 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 1000-101f : Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] 1000-101f : PCnet/PCI II 79C970A 1020-103f : Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (#2)
oops script for /usr/src/linux/scripts
I made a simple bug_report.sh script to facilitate generating a bug report. It could be included in /usr/src/linux/scripts and could be referenced in /usr/src/linux/BUG-REPORTING. If anyone is interested, please see attached. Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> bug_report.sh
OPPS with 2.4.3 and LIDS
See attached oops description. -- W. Wade, Hampton [EMAIL PROTECTED] BUG report for vmguest5 on Mon Apr 9 07:00:32 EDT 2001 [1.] One line summary of the problem: Kernel oops with 2.4.3+LIDS running under VMWare [2.] Full description of the problem/report: The machine that crashed is a RedHat 7.0 virtual host running under VMWare 2.0.3 on a RedHat 6.2 base host. The virtual host has 2.4.3 with LIDS 1.0.7. This report is on the virtual host that includes LIDS. Over the weekend, I had two VMs running on my Linux box (RH 6.2 with 2.4.3), but apparently there is an issue with vmware and 2.4.3 SMP. The box locked up (base O/S). Note, 2.4.3 seems much better than 2.4.1 for vmware lockups with 2 VMs, but still I don't recommend it, yet. This is a separate issue and I have yet to get an oops I can report. This will be a separate report This morning, I rebooted the base O/S, then once it was up and functioning properly, I started the test VM with LIDS. The test VM started booting, then came to the login prompt. It then started running slocate, etc. A few minutes after booting, I got the OOPS. [3.] Keywords (i.e., modules, networking, kernel): kernel 2.4.3, VMWare, LIDS [4.] Kernel version (from /proc/version): Linux version 2.4.3 (root@vmguest5) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #3 Fri Apr 6 10:40:10 EDT 2001 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) Trace; c012dc3b kmalloc+6b/90 Trace; c01fccf5 lids_proceed_scan+145/2b0 Trace; c01fcbb0 lids_proceed_scan+0/2b0 Trace; c011a0c3 timer_bh+213/250 Trace; c01163fc bh_action+1c/60 Trace; c0116306 tasklet_hi_action+36/60 Trace; c011620b do_softirq+5b/80 Trace; c01083af do_IRQ+9f/b0 Trace; c0106fd0 ret_from_intr+0/20 Original OOPS: LIDS: slocate (3 5 inode 96962) pid 1220 ppid 1218 user (0/0) on NULL tty: voliated CAP_DAC_READ_SEARCH kernelb BUG at slab.c:1073! invalid operand: CPU:0 EIP:0010:[c012d99b] EFLAGS: 0286 ... Process sendmail (pid: 1552, stackpage c397b000) Stack: c0219f9e c021a03e 0431 00030002 c159bbfc c1134050 c25b5005 0026c8ca 0003 0015 c1117570 0007 c1263d20 c012dc3b c1117570 0007 0282 0001 c111b260 1000 c22089e0 000c c01fccf5 Call Trace: [c012dc3b] [c01fccf5] [c01fcbb0] [c011a0c3] [c01163fc] [c0116306] [c011620b] [c01083af] [c0106fd0] Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing [6.] A small shell script or example program which triggers the problem (if possible) none [7.] Environment [7.1.] Software (add the output of the ver_linux script here) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Base O/S: - RedHat 6.2 (VA) with updates - Kernel 2.4.3 - VMWare 2.0.3 VMHost O/S (the one that crashed): - RedHat 7.0 with updates - Kernel 2.4.3 - part of pcnet32 patch removed to get it to work (previous kernel msgs) - LIDS 1.0.7 patch Linux vmguest5 2.4.3 #3 Fri Apr 6 10:40:10 EDT 2001 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.0.18 util-linux 2.10m modutils 2.3.21 e2fsprogs 1.18 pcmcia-cs 3.1.19 Linux C Library libc.2.2 Dynamic linker (ldd) 2.2 Procps 2.0.7 Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded pcnet32 sb sb_lib uart401 sound soundcore [7.2.] Processor information (from /proc/cpuinfo): Base O/S: - Dual PIII/800 VMHost O/S (the one that crashed): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 931.349 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1228.80 [7.3.] Module information (from /proc/modules): pcnet3211600 1 (autoclean) sb 7520 0 (unused) sb_lib 34528 0 [sb] uart401 6416 0 [sb_lib] sound 58864 0 [sb_lib uart401] soundcore 4080 5 [sb_lib sound] [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0220-022f : soundblaster 02e8-02ef : serial(auto) 02f8-02ff : serial(auto) 0330-0333 : MPU-401 UART 0376-0376 : ide1 03c0-03df : vga+ 03e8-03ef : serial(auto) 03f6-03f6
oops script for /usr/src/linux/scripts
I made a simple bug_report.sh script to facilitate generating a bug report. It could be included in /usr/src/linux/scripts and could be referenced in /usr/src/linux/BUG-REPORTING. If anyone is interested, please see attached. Cheers, -- W. Wade, Hampton [EMAIL PROTECTED] bug_report.sh
2.4.3, VMWare, 2 VMs
Greetings, Is anyone having problems with running more than 1 VM on 2.4.3. I have crashed my host O/S several times when I try to start two VMs. Currently, I don't have an oops or other info to report, but I did see a post on the vmware list about 2.4.3 SMP and VMWARE. Host: dual PIII/800, 256 M RAM, RedHat 6.2 with updates, 2.4.3 VM1: RedHat 7.0 with recent updates VM2: RedHat 7.0 with 2.4.3 and LIDS Cheers, -- W. Wade, Hampton [EMAIL PROTECTED] If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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.3, VMWare, 2 VMs
Petr Vandrovec wrote: On 9 Apr 01 at 12:03, Wade Hampton wrote: Is anyone having problems with running more than As I already answered on VMware newsgroups: Thanks. I didn't see the post on the VMware newsgroup VMware's 2.0.3 vmmon module uses save_flags() + cli() in poll() fops, and after this cli() it calls spin_lock() :-( It is not safest thing to do. But it should not cause reboot. You should get /dev/vmmon: 11 wait for global VM lock XX I had over 2000 of those in /var/log/messages (not counting the "repeated" lines in /var/log/messages). Yep, that's the problem and now dead machine with disabled interrupts... Yes, basically a dead machine with NO response to anything As all other callers of HostIF_GlobalVMLock() hold big kernel lock, easiest thing to do is to add lock_kernel()/unlock_kernel() around LinuxDriver_Poll() body. Removing whole save_flags/cli is for sure much better, but it is still in my queue (if you are looking into vmmon driver, then whole poll mess is there to get wakeup on next jiffy, and not on next + one...). No, I can wait for the a release that fixes this. If you have a patch or test version, send it to me and I'll test it on my development machine For now, I'll just not use 2 VMs until it is fixed. Cheers, -- W. Wade, Hampton [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/
2.2.19 toshiba option broken
On my toshiba laptop, I am trying to use 2.2.19. However, building it with the Toshiba Laptop option set to Y or M results in errors. The errors from setting it to M are: toshiba.c:81: toshiba.h: No such file or directory toshiba.c:156: parse error before `*' ... The fix is to edit drivers/char/toshiba.c and change #include "toshiba.h" to #include"linux/toshiba.h" Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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: pcnet32 (maybe more) hosed in 2.4.3
Carsten Langgaard wrote: > > I'm not sure what the problem is, but the whole deal about checking whether the > controller runs in 16 bit or 32 bit mode, is a little bit tricky. >[snip] Without the changes listed in this thread, 2.4.3 crashed vmware 2.0.3 Linux. It did not OOPS the kernel, it caused vmware to go down in flames Changing the code per the previous mail fixed it and my VM now works fine. THANKS! Is this list non-causal? The answer was posted to the list as I was getting ready to build 2.4.3 on my VM, before I found the problem or even had to ask the question! Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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: pcnet32 (maybe more) hosed in 2.4.3
Carsten Langgaard wrote: I'm not sure what the problem is, but the whole deal about checking whether the controller runs in 16 bit or 32 bit mode, is a little bit tricky. [snip] Without the changes listed in this thread, 2.4.3 crashed vmware 2.0.3 Linux. It did not OOPS the kernel, it caused vmware to go down in flames Changing the code per the previous mail fixed it and my VM now works fine. THANKS! Is this list non-causal? The answer was posted to the list as I was getting ready to build 2.4.3 on my VM, before I found the problem or even had to ask the question! Cheers, -- W. Wade, Hampton [EMAIL PROTECTED] If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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.2.19 toshiba option broken
On my toshiba laptop, I am trying to use 2.2.19. However, building it with the Toshiba Laptop option set to Y or M results in errors. The errors from setting it to M are: toshiba.c:81: toshiba.h: No such file or directory toshiba.c:156: parse error before `*' ... The fix is to edit drivers/char/toshiba.c and change #include "toshiba.h" to #include"linux/toshiba.h" Cheers, -- W. Wade, Hampton [EMAIL PROTECTED] If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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.2 cs4232 is not SMP safe
Olaf Hering wrote: > > On Wed, Mar 28, Alan Cox wrote: > > > > But it still jumps into xmon. How can we make that driver SMP safe? > > > There is no maintainer address in the files. > > > > CS4232 has no maintainer. I've had no SMP x86 problems reported with it for > > a long time but that may be chance > > Well, the alsa driver loads but it can not play sound, all you get is a > strange noise. The same driver (alsa/kernel) works on a UP ppc machine > (a B50). I will try to get an UP kernel for that machine, it worked once > around 2.4.3-pre. I have been using a Dell SMB dual PII/300 box with cs4232 playing my MP3s in a loop 24x7 for nearly a year without any glitches. I have tried it with 2.2 kernels and 2.4.0. The only problem I have had with the box and sound driver was that I had to set the PCI quirks flag to 1 (thanks to Alan for pointing me to it) to keep it from crashing when playing sound and accessing the floppy (this got QUITE embarassing when I was doing some custom work for some high-level folks a while back). However, I have one beef with the driver. Each time it starts a cut, I get a loud pop from the speaker. This appears to be a startup transient and is not present on my other sound card in the box, a SoundBlaster Vibra 16. This pop happens on ANY play application, playing ANY file (esdplay, play[sox], vplay, xmms, etc.). Cheers, -- Wade Hampton - 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.2 cs4232 is not SMP safe
Olaf Hering wrote: On Wed, Mar 28, Alan Cox wrote: But it still jumps into xmon. How can we make that driver SMP safe? There is no maintainer address in the files. CS4232 has no maintainer. I've had no SMP x86 problems reported with it for a long time but that may be chance Well, the alsa driver loads but it can not play sound, all you get is a strange noise. The same driver (alsa/kernel) works on a UP ppc machine (a B50). I will try to get an UP kernel for that machine, it worked once around 2.4.3-pre. I have been using a Dell SMB dual PII/300 box with cs4232 playing my MP3s in a loop 24x7 for nearly a year without any glitches. I have tried it with 2.2 kernels and 2.4.0. The only problem I have had with the box and sound driver was that I had to set the PCI quirks flag to 1 (thanks to Alan for pointing me to it) to keep it from crashing when playing sound and accessing the floppy (this got QUITE embarassing when I was doing some custom work for some high-level folks a while back). However, I have one beef with the driver. Each time it starts a cut, I get a loud pop from the speaker. This appears to be a startup transient and is not present on my other sound card in the box, a SoundBlaster Vibra 16. This pop happens on ANY play application, playing ANY file (esdplay, play[sox], vplay, xmms, etc.). Cheers, -- Wade Hampton - 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: regression testing
[EMAIL PROTECTED] wrote: > > Hi. I was wondering if there has been any discussion of kernel > regression testing. Wouldn't it be great if we didn't have to depend > on human testers to verify every change didn't break something? IMHO, much of the strength of Linux is the very large, extremely diverse population of folks using it, testing it, beating on the latest release, etc. However, a lab dedicated to testing the linux kernel, properly funded, staffed, and containing the most common hardware and software would be a good idea. Does anyone have any idea how this could be accomplished? Who could do it? IBM? What would it cost to setup a reasonable lab? My guess would be dozens of machines of various architectures, a staff of at least 10, several thousand square feet of space, and a good budget Any takers? Much of the kernel COULD be tested such as file systems, network stack, SMP, compile options on various platforms, etc. More obscure hardware, some older hardware, etc., would be out of scope for such an effort. Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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: regression testing
[EMAIL PROTECTED] wrote: Hi. I was wondering if there has been any discussion of kernel regression testing. Wouldn't it be great if we didn't have to depend on human testers to verify every change didn't break something? IMHO, much of the strength of Linux is the very large, extremely diverse population of folks using it, testing it, beating on the latest release, etc. However, a lab dedicated to testing the linux kernel, properly funded, staffed, and containing the most common hardware and software would be a good idea. Does anyone have any idea how this could be accomplished? Who could do it? IBM? What would it cost to setup a reasonable lab? My guess would be dozens of machines of various architectures, a staff of at least 10, several thousand square feet of space, and a good budget Any takers? Much of the kernel COULD be tested such as file systems, network stack, SMP, compile options on various platforms, etc. More obscure hardware, some older hardware, etc., would be out of scope for such an effort. Cheers, -- W. Wade, Hampton [EMAIL PROTECTED] If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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: eject weirdness on NEC disc changer, kernel 2.4.2
Jim Breton wrote: > > Hi all, I've gotten a response from the "eject" author and he seems to > agree that this is something in the kernel causing this issue. Have you had it where the drive would not eject the disc? I seem to be having this on several ATAPI drives (CD-R, CD-ROM, DVD), all with ide-scsi running Note, this has forced me to reboot both 2.4.0, 2.4.1, and 2.4.2 (multiple boxes). Cheers, -- W. Wade, Hampton <[EMAIL PROTECTED]> If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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: eject weirdness on NEC disc changer, kernel 2.4.2
Jim Breton wrote: Hi all, I've gotten a response from the "eject" author and he seems to agree that this is something in the kernel causing this issue. Have you had it where the drive would not eject the disc? I seem to be having this on several ATAPI drives (CD-R, CD-ROM, DVD), all with ide-scsi running Note, this has forced me to reboot both 2.4.0, 2.4.1, and 2.4.2 (multiple boxes). Cheers, -- W. Wade, Hampton [EMAIL PROTECTED] If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Occasionally your car would just die for no reason, and you'd have to restart it, but you'd just accept this. - 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/
apparent file corruption on 2.4.2
Greetings, This is a CC of a post I sent last night to the redhat-list. I am forwarding it to the kernel list as I hear others have had file corruption and this might be of interest Also, if anyone has any ideas I got a couple of responses including: 1) Backup/restore the partition (in this case /) 2) Try shutdown -F now then do an FSCK again 3) There is something else you can do, but it's rather radical. Overwrite the entries directly in the directory table. You would have to write a program to do it, but it should solve the problem. Warren Melnick <[EMAIL PROTECTED]> 4) From Kernel Traffic #107 For 16 Feb, item #3 "I resorted to using debugfs to remove these entries, and re-running e2fsck".[I may try this tonight!] System information: Dell PIII 600 with 20G ATAPI, ATAPI DVD, ZIP, CD-R IDE-SCSI loaded for CD-R, DVD 3COM 3C905 100T NIC 3dfx AGP video RedHat 7.0 with updates 2.4.0 or 2.4.2 kernel, stock (no custom patches) Original post follows: I had some problems with shutting down my RH 7.0 box (2.4.0) and had to hit the reset button. I then tried booting to 2.4.2 which I had just installed. However, I got a lot of disk errors and the sizes on quite a few files were changed to 104. A second hard reboot and startup of 2.4.0, a single user fsck of all partitions and reboot seemed to make all well, however a couple of files are messed up, /bin/hostname and /dev/dsp. I can't move, delete, or do anything with these files. I tried chattr, touch, etc. and the only thing I can do is change the access date with touch. b--sr-s--t1 1769209956 1852796526 116, 101 May 29 2023 /binold/hostname prwxr-x--T1 2232483836 23128812830 Mar 1 22:41 /dev/dsp I recovered /bin by copying /bin/* to /binnew, moving /bin to /binold, then moving /binnew to /bin. I then recovered /bin/hostname from the RPM file, but now I can't do anything with /binold/hostname I tried chattr, chmod, chgrp, mv, cat, vi, touch, etc. Does anyone have any ideas. I can live with one messed up file in /binold, but I can't live with a messed up /dev/dsp. I really don't want the Microsoft solution (reload) Any help would be MOST appreciated! -- Wade Hampton - 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/
apparent file corruption on 2.4.2
Greetings, This is a CC of a post I sent last night to the redhat-list. I am forwarding it to the kernel list as I hear others have had file corruption and this might be of interest Also, if anyone has any ideas I got a couple of responses including: 1) Backup/restore the partition (in this case /) 2) Try shutdown -F now then do an FSCK again 3) There is something else you can do, but it's rather radical. Overwrite the entries directly in the directory table. You would have to write a program to do it, but it should solve the problem. Warren Melnick [EMAIL PROTECTED] 4) From Kernel Traffic #107 For 16 Feb, item #3 "I resorted to using debugfs to remove these entries, and re-running e2fsck".[I may try this tonight!] System information: Dell PIII 600 with 20G ATAPI, ATAPI DVD, ZIP, CD-R IDE-SCSI loaded for CD-R, DVD 3COM 3C905 100T NIC 3dfx AGP video RedHat 7.0 with updates 2.4.0 or 2.4.2 kernel, stock (no custom patches) Original post follows: I had some problems with shutting down my RH 7.0 box (2.4.0) and had to hit the reset button. I then tried booting to 2.4.2 which I had just installed. However, I got a lot of disk errors and the sizes on quite a few files were changed to 104. A second hard reboot and startup of 2.4.0, a single user fsck of all partitions and reboot seemed to make all well, however a couple of files are messed up, /bin/hostname and /dev/dsp. I can't move, delete, or do anything with these files. I tried chattr, touch, etc. and the only thing I can do is change the access date with touch. b--sr-s--t1 1769209956 1852796526 116, 101 May 29 2023 /binold/hostname prwxr-x--T1 2232483836 23128812830 Mar 1 22:41 /dev/dsp I recovered /bin by copying /bin/* to /binnew, moving /bin to /binold, then moving /binnew to /bin. I then recovered /bin/hostname from the RPM file, but now I can't do anything with /binold/hostname I tried chattr, chmod, chgrp, mv, cat, vi, touch, etc. Does anyone have any ideas. I can live with one messed up file in /binold, but I can't live with a messed up /dev/dsp. I really don't want the Microsoft solution (reload) Any help would be MOST appreciated! -- Wade Hampton - 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/
