Re: Microsoft and Xenix.
On Sun, 24 Jun 2001, Rob Landley wrote: > I know the geos had nothing to do with digital, it started as a windowing GUI > for the commodore 64, if you can believe that... Not only can I belive it, but I was going to bring it up the first time GEOS was mentioned. Having only used Macs (in school) for file operations (I had loaded games off a TSR-80 datasette). I couldn't follow copying/deleting/renaming files by typing commands when my family finally got me a C64. So I relied heavily on GEOS. I even got one of those touch pads to move the cursor around the screen. When my dad finally got a PC in 1991 it had MS-DOS 5.0 and Windows 3.1 on it. I didn't like Windows too much, but still found DOS awkward (still using Macs in school). I started using dosshell a lot for file operations. But when I saw an ad for GEOS in a computer mag. I was so happy. I ended up using that for a while. But more and more programs required Windows, and that made me mad. There was one book that totally changed my life. I can't remember the correct title, but it was something to the effect of Secrets to the DOS Gurus. After reading that book, I fell in love with the command line interface. Everything started making sense. Somewhere along the line, I think 1994 I started working for the Maryland state government at a Healt Department. They were running Xenix (SCO, the 2 names were interchanged a lot) on a 386. A few of the "important" people had serial lines run to their Win 3.1 PCs where they'd use Telix to run the database programs on the Xenix box. As I watched people work on in Xenix I recognized a lot of the commands I had picked up using the Delphi online service. I had a neighbor that showed me some stuff I could do if I chose the Exit to Shell option. In 1995 still working for the Health Department I got to go to my first trade show, FOSE. I met and heavily impressed a lot of booth workers. One such booth was Microsoft. I was invited to participate in their beta program for the upcoming Windows 95 (I was one of the "lucky" people who didn't have to pay for their betas). I used the Win95 betas for a while. But something happened that year. I got a Linux Unleashed book from SAMS. It included a copy of Slackware. I installed that along side my Win95, and when I saw how fast Doom loaded I was in love. I vowed that on August 24, 1995 I would delete Windows from my machine and never use it again. Well I can't say that I have held complete faithful to that vow, but I have had Linux on my machine ever since then. Now my computer is Windows free and has been for a year and a half. Okay, I brushed on GEOS, Microsoft, Xenix, and even Linux. So I'm as on topic as the rest of this thread. I just have never told my story on l-k, and this seemed a good place to put a little of it in. :) -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Microsoft and Xenix.
On Sun, 24 Jun 2001, Rob Landley wrote: I know the geos had nothing to do with digital, it started as a windowing GUI for the commodore 64, if you can believe that... Not only can I belive it, but I was going to bring it up the first time GEOS was mentioned. Having only used Macs (in school) for file operations (I had loaded games off a TSR-80 datasette). I couldn't follow copying/deleting/renaming files by typing commands when my family finally got me a C64. So I relied heavily on GEOS. I even got one of those touch pads to move the cursor around the screen. When my dad finally got a PC in 1991 it had MS-DOS 5.0 and Windows 3.1 on it. I didn't like Windows too much, but still found DOS awkward (still using Macs in school). I started using dosshell a lot for file operations. But when I saw an ad for GEOS in a computer mag. I was so happy. I ended up using that for a while. But more and more programs required Windows, and that made me mad. There was one book that totally changed my life. I can't remember the correct title, but it was something to the effect of Secrets to the DOS Gurus. After reading that book, I fell in love with the command line interface. Everything started making sense. Somewhere along the line, I think 1994 I started working for the Maryland state government at a Healt Department. They were running Xenix (SCO, the 2 names were interchanged a lot) on a 386. A few of the important people had serial lines run to their Win 3.1 PCs where they'd use Telix to run the database programs on the Xenix box. As I watched people work on in Xenix I recognized a lot of the commands I had picked up using the Delphi online service. I had a neighbor that showed me some stuff I could do if I chose the Exit to Shell option. In 1995 still working for the Health Department I got to go to my first trade show, FOSE. I met and heavily impressed a lot of booth workers. One such booth was Microsoft. I was invited to participate in their beta program for the upcoming Windows 95 (I was one of the lucky people who didn't have to pay for their betas). I used the Win95 betas for a while. But something happened that year. I got a Linux Unleashed book from SAMS. It included a copy of Slackware. I installed that along side my Win95, and when I saw how fast Doom loaded I was in love. I vowed that on August 24, 1995 I would delete Windows from my machine and never use it again. Well I can't say that I have held complete faithful to that vow, but I have had Linux on my machine ever since then. Now my computer is Windows free and has been for a year and a half. Okay, I brushed on GEOS, Microsoft, Xenix, and even Linux. So I'm as on topic as the rest of this thread. I just have never told my story on l-k, and this seemed a good place to put a little of it in. :) -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, you look like you are wearing a tuxedo. The second penguin said, I might be... --David Lynch, Twin Peaks - 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: PROBLEM: compiling with gcc 3.0
On Tue, 19 Jun 2001, Simone Piunno wrote: > I was trying to compile 2.4.5 with gcc 3.0 but there is a problem > (conflicting type) between kernel/timer.c and include/linux/sched.h > Apparently the problem solves with this oneline workarond: > > --- linux/include/linux/sched.h Tue Jun 19 17:00:03 2001 > +++ linux/include/linux/sched.h.origTue Jun 19 17:00:13 2001 [short patch snipped] > don't know if this is the right approach but works for me. The approach was right, but your argument order to diff was backwards. Andrea posted this patch a little while ago: --- 2.4.6pre2aa1/include/linux/sched.h.~1~ Wed Jun 13 00:44:45 2001 +++ 2.4.6pre2aa1/include/linux/sched.h Wed Jun 13 00:47:23 2001 @@ -541,7 +541,7 @@ extern unsigned long volatile jiffies; extern unsigned long itimer_ticks; extern unsigned long itimer_next; -extern struct timeval xtime; +extern volatile struct timeval xtime; extern void do_timer(struct pt_regs *); extern unsigned int * prof_buffer; -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: PROBLEM: compiling with gcc 3.0
On Tue, 19 Jun 2001, Simone Piunno wrote: I was trying to compile 2.4.5 with gcc 3.0 but there is a problem (conflicting type) between kernel/timer.c and include/linux/sched.h Apparently the problem solves with this oneline workarond: --- linux/include/linux/sched.h Tue Jun 19 17:00:03 2001 +++ linux/include/linux/sched.h.origTue Jun 19 17:00:13 2001 [short patch snipped] don't know if this is the right approach but works for me. The approach was right, but your argument order to diff was backwards. Andrea posted this patch a little while ago: --- 2.4.6pre2aa1/include/linux/sched.h.~1~ Wed Jun 13 00:44:45 2001 +++ 2.4.6pre2aa1/include/linux/sched.h Wed Jun 13 00:47:23 2001 @@ -541,7 +541,7 @@ extern unsigned long volatile jiffies; extern unsigned long itimer_ticks; extern unsigned long itimer_next; -extern struct timeval xtime; +extern volatile struct timeval xtime; extern void do_timer(struct pt_regs *); extern unsigned int * prof_buffer; -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, you look like you are wearing a tuxedo. The second penguin said, I might be... --David Lynch, Twin Peaks - 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 - Locked keyboard
On Tue, 15 May 2001, Anuradha Ratnaweera wrote: > > On Thu, 10 May 2001, Jorge Boncompte [DTI2] wrote: > > > After the reboot, the keyboard was working 5 minutes and then it > > locked. The console was working. I rebooted the machine again and has > > been working for 2 days, that the keyboard gets locked again. > > Just to make sure... > > Did you check scoll lock? :) I was seeing the same problem in 2.4.0-2. Unplugging my keyboard for a few seconds and then plugging it back in would solve it when it happened, but it would happen again. 2.4.3 seemed to have the problem decrease, and I don't think I've seen it once with 2.4.4. So someone seemed to have known about it and was working to fix it. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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 - Locked keyboard
On Tue, 15 May 2001, Anuradha Ratnaweera wrote: On Thu, 10 May 2001, Jorge Boncompte [DTI2] wrote: After the reboot, the keyboard was working 5 minutes and then it locked. The console was working. I rebooted the machine again and has been working for 2 days, that the keyboard gets locked again. Just to make sure... Did you check scoll lock? :) I was seeing the same problem in 2.4.0-2. Unplugging my keyboard for a few seconds and then plugging it back in would solve it when it happened, but it would happen again. 2.4.3 seemed to have the problem decrease, and I don't think I've seen it once with 2.4.4. So someone seemed to have known about it and was working to fix it. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, you look like you are wearing a tuxedo. The second penguin said, I might be... --David Lynch, Twin Peaks - 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: Linux 2.4.3-ac7
On Mon, 16 Apr 2001, Alan Cox wrote: > VIA users should test this kernel carefully. It has what are supposed to be > the right fixes for the VIA hardware bugs. Obviously the right fixes are not > as tested as the deduced ones. I saw no mention of the ACPI idle problem I see on my Athlons. Is the acpi=no-idle work around the perminate fix? -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Linux 2.4.3-ac7
On Mon, 16 Apr 2001, Alan Cox wrote: VIA users should test this kernel carefully. It has what are supposed to be the right fixes for the VIA hardware bugs. Obviously the right fixes are not as tested as the deduced ones. I saw no mention of the ACPI idle problem I see on my Athlons. Is the acpi=no-idle work around the perminate fix? -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: [lkml]Re: [PATCH] matroxfb and mga XF4 driver coexistence...
On Thu, 12 Apr 2001, [EMAIL PROTECTED] wrote: > Of course, but if we can fix the problem by making the kernel smaller, > what possible motive could you have for opposing it other than 'but it > doesn't solve _my_ problems!' ? Agreed. The only thing I was thinking, was if the kernel is doing the right thing now, it shouldn't be forced to work around a bug in XFree. By not "fixing" the kernel, the XFree team would be forced to do the right thing. As for me, I'm going to see about getting the matroxfb working, so if the patch goes in I'll be able to use a nice 132 character wide terminal again. And I'm getting addicted to dual head in X, might be fun on the console too. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: [PATCH] matroxfb and mga XF4 driver coexistence...
On Thu, 12 Apr 2001, Rafael E. Herrera wrote: > > But only users using matroxfb complains to me and/or to linux-kernel ;-) > > You know, it worked last week, but it does not work anymore today. And > > only thing I changed was kernel. So it must be in kernel... I thought I had seen at least one other complaint on l-k about seeing the problem in text mode. > I think he's referrig to the matrox cards. I have mentioned this > happening to me in this list. I've a G450, if I use anything other than > 'normal', going in and out of X makes my text console go blank. I don't > use the frame buffer, by the way. Yes, sorry I didn't make this clear. I have a Matrox G400. > If the problem occurs whithout the frame buffer on, the problem seems to > be on the X server. Exactly. That is what I'm saying. I've seen the problem with the returning to VESA text modes from XFree 4.0 anytime I use the hallib, with 2.2 and 2.4 kernels. If I compile an X server without the hallib it's fine (G450 users don't have that option, and I like my dual head). If X changes the mode upon starting it should put it back when it is done. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: [PATCH] matroxfb and mga XF4 driver coexistence...
On Thu, 12 Apr 2001, Rafael E. Herrera wrote: But only users using matroxfb complains to me and/or to linux-kernel ;-) You know, it worked last week, but it does not work anymore today. And only thing I changed was kernel. So it must be in kernel... I thought I had seen at least one other complaint on l-k about seeing the problem in text mode. I think he's referrig to the matrox cards. I have mentioned this happening to me in this list. I've a G450, if I use anything other than 'normal', going in and out of X makes my text console go blank. I don't use the frame buffer, by the way. Yes, sorry I didn't make this clear. I have a Matrox G400. If the problem occurs whithout the frame buffer on, the problem seems to be on the X server. Exactly. That is what I'm saying. I've seen the problem with the returning to VESA text modes from XFree 4.0 anytime I use the hallib, with 2.2 and 2.4 kernels. If I compile an X server without the hallib it's fine (G450 users don't have that option, and I like my dual head). If X changes the mode upon starting it should put it back when it is done. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: [lkml]Re: [PATCH] matroxfb and mga XF4 driver coexistence...
On Thu, 12 Apr 2001, [EMAIL PROTECTED] wrote: Of course, but if we can fix the problem by making the kernel smaller, what possible motive could you have for opposing it other than 'but it doesn't solve _my_ problems!' ? Agreed. The only thing I was thinking, was if the kernel is doing the right thing now, it shouldn't be forced to work around a bug in XFree. By not "fixing" the kernel, the XFree team would be forced to do the right thing. As for me, I'm going to see about getting the matroxfb working, so if the patch goes in I'll be able to use a nice 132 character wide terminal again. And I'm getting addicted to dual head in X, might be fun on the console too. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: [PATCH] matroxfb and mga XF4 driver coexistence...
On Wed, 11 Apr 2001, Petr Vandrovec wrote: > Hi, >Alan, Linus, please apply this patch to matroxfb. It fixes complaints > from people that screen is black after they exit from X back to console. > Matrox driver does not know that it should return hardware state back to > initial state after switch, but matroxfb relies on that (XF3 did that...). > So now it reprograms hardware always from scratch... I would like to see this fixed as much as anyone (even complained to the XFree people from SuSE last ALS). But I don't think the fix should be in the kernel. XF4 needs to be fixed. The problem doesn't just effect the maxtroxfb, but also the vgacon video mode selection. If I put anything other than "normal" or "extended" in the "vga=" line of my lilo.conf the machine starts okay, but upon exiting X bad stuff happens. The screen doesn't just go black. Probally the majority of Matrox owners have multisync monitors, but I'm stuck with an old monosync, and it looses sync when trying to return to a VESA text mode. I don't use the matroxfb driver so this patch wouldn't help me, and is also why I say XFree 4.0 needs to be fixed. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: [PATCH] matroxfb and mga XF4 driver coexistence...
On Wed, 11 Apr 2001, Petr Vandrovec wrote: Hi, Alan, Linus, please apply this patch to matroxfb. It fixes complaints from people that screen is black after they exit from X back to console. Matrox driver does not know that it should return hardware state back to initial state after switch, but matroxfb relies on that (XF3 did that...). So now it reprograms hardware always from scratch... I would like to see this fixed as much as anyone (even complained to the XFree people from SuSE last ALS). But I don't think the fix should be in the kernel. XF4 needs to be fixed. The problem doesn't just effect the maxtroxfb, but also the vgacon video mode selection. If I put anything other than "normal" or "extended" in the "vga=" line of my lilo.conf the machine starts okay, but upon exiting X bad stuff happens. The screen doesn't just go black. Probally the majority of Matrox owners have multisync monitors, but I'm stuck with an old monosync, and it looses sync when trying to return to a VESA text mode. I don't use the matroxfb driver so this patch wouldn't help me, and is also why I say XFree 4.0 needs to be fixed. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: New directions for kernel development
On Sun, 1 Apr 2001, David Riley wrote: > Linus Torvalds wrote: > > Uhm, yeah... I don't know who wrote this, but it came from Washington > state and was written with MS Outlook... Something tells me that this > April Fool's joke wasn't Linus'. :-) Yeah, the quality of these jokes has really gone down hill. Last year we had forged headers and composed with Pine. This year we have someone with a dialup account using Outlook, with all it's ^Os and long lines of text. Bah. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: New directions for kernel development
On Sun, 1 Apr 2001, David Riley wrote: Linus Torvalds wrote: Uhm, yeah... I don't know who wrote this, but it came from Washington state and was written with MS Outlook... Something tells me that this April Fool's joke wasn't Linus'. :-) Yeah, the quality of these jokes has really gone down hill. Last year we had forged headers and composed with Pine. This year we have someone with a dialup account using Outlook, with all it's ^Os and long lines of text. Bah. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Hardware problem detection? Linux 2.4.3-pre4 lockups.
On Thu, 15 Mar 2001, Nathan Black wrote: > I am at a total loss, But I have found some interesting anomalies with my > hardware. That is about how I was feeling when I had similar problems. > My Current Setup: > Supermicro S370DE6 (Serverworks Chipset) > Dual PIII 866 > 2 x 256 MB PC133 ECC SDRAM > onboard AIC 7899 SCSI Controller. > 36G,73GB Seagate Cheetah Drive. > Voodoo4 4500 AGP video, > Fore PCA 200e ATM My setup was (is): Tyan Thunder 2500 (Serverworks) Dual PIII 667s 2 x 512 MB PC133 ECC SDRAM Onboard dual SYM53C896 controller 5 18.2 GB Seagate Cheetahs nVideo Vanta Onboard Intel 10/100 > Problem, I have a program the can read a file(large, or small) it will then > transmit the data over atm, ethernet, localhost,or write to a file. I could move a lot of network traffic as long as I wasn't hitting the disk too hard. > I have noticed that the machine will consistently crash(hard lockup) when I > do a read loop of the File. It never locks up at the same place, and I have > changed it so that it never actually does anything with the data after it > reads. Still, same result. Any time I pushed the disk subsystem hard I would get a lockup. Sometimes the kernel would oops, the program writing to the disk would segfault, but always the machine locked hard. > Things that have "fixed" the problem. Setting the FSB to 100(jumpered) will > allow me to run forever. > Also, Setting the L1 Cache to Write-through instead of write back will allow > me to run forever at 133, but the performance hit is worse than setting the > FSB to 100. If I forced things to run slower I could run longer, like changing the cache setting, never tried the FSB setting. But even with the machine slowed down I could eventually lock it up if I pushed the disks hard enough (12 bonnies at the same time would always do it). > Another note. When I have attempted to compile the kernel for Uni processor. > I started getting segmentation faults with gcc. > Now this tells me it might be the processor. But I have nothing overclocked, > so I would think that it might be some kind of timing issue in the kernel. I saw so much strange stuff I couldn't pin it down to one thing, except perhaps the processor. > I have two machines set up this way. One is much more stable. But I do > observe the occasional crash.(hard lockup) I too had two identical machines. I was doing all my work on one, and was planning on copying the finished product over to the second when I was done. After I started suspecting the hardware, I started up the other machine. It ran perfectly. I could push it as hard as I wanted with no trouble at all. > I have also seen fsck crash as well. when the system was not shut down > correctly. ( as a hard lockup happens very frequently.) > > Here are some things that I have tried, but Have not fixed it. > 1) SMP Kernel with "noapic" at lilo prompt ( and without the noapic) > 2) Uni Kernel w/ & w/out apic > > I am at a total loss. > Is there anything I can do(other than run at 100 FSB)? > > Nathan > > P.S. I have enclosed the dmesg output for my Uniprocessor kernel > <> In the end I started swapping processors between the two machines. I found the problem followed 1 of my processors. I called Intel and after 2 days of convincing they RMAed my old processor and sent me a replacement. Both machines have been running perfectly since then. If you have any more processors I'd try swapping them around. But since you are seeing problems with 2 similar machines, I wouldn't get my hopes up as to this being the solution. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Hardware problem detection? Linux 2.4.3-pre4 lockups.
On Thu, 15 Mar 2001, Nathan Black wrote: I am at a total loss, But I have found some interesting anomalies with my hardware. That is about how I was feeling when I had similar problems. My Current Setup: Supermicro S370DE6 (Serverworks Chipset) Dual PIII 866 2 x 256 MB PC133 ECC SDRAM onboard AIC 7899 SCSI Controller. 36G,73GB Seagate Cheetah Drive. Voodoo4 4500 AGP video, Fore PCA 200e ATM My setup was (is): Tyan Thunder 2500 (Serverworks) Dual PIII 667s 2 x 512 MB PC133 ECC SDRAM Onboard dual SYM53C896 controller 5 18.2 GB Seagate Cheetahs nVideo Vanta Onboard Intel 10/100 Problem, I have a program the can read a file(large, or small) it will then transmit the data over atm, ethernet, localhost,or write to a file. I could move a lot of network traffic as long as I wasn't hitting the disk too hard. I have noticed that the machine will consistently crash(hard lockup) when I do a read loop of the File. It never locks up at the same place, and I have changed it so that it never actually does anything with the data after it reads. Still, same result. Any time I pushed the disk subsystem hard I would get a lockup. Sometimes the kernel would oops, the program writing to the disk would segfault, but always the machine locked hard. Things that have "fixed" the problem. Setting the FSB to 100(jumpered) will allow me to run forever. Also, Setting the L1 Cache to Write-through instead of write back will allow me to run forever at 133, but the performance hit is worse than setting the FSB to 100. If I forced things to run slower I could run longer, like changing the cache setting, never tried the FSB setting. But even with the machine slowed down I could eventually lock it up if I pushed the disks hard enough (12 bonnies at the same time would always do it). Another note. When I have attempted to compile the kernel for Uni processor. I started getting segmentation faults with gcc. Now this tells me it might be the processor. But I have nothing overclocked, so I would think that it might be some kind of timing issue in the kernel. I saw so much strange stuff I couldn't pin it down to one thing, except perhaps the processor. I have two machines set up this way. One is much more stable. But I do observe the occasional crash.(hard lockup) I too had two identical machines. I was doing all my work on one, and was planning on copying the finished product over to the second when I was done. After I started suspecting the hardware, I started up the other machine. It ran perfectly. I could push it as hard as I wanted with no trouble at all. I have also seen fsck crash as well. when the system was not shut down correctly. ( as a hard lockup happens very frequently.) Here are some things that I have tried, but Have not fixed it. 1) SMP Kernel with "noapic" at lilo prompt ( and without the noapic) 2) Uni Kernel w/ w/out apic I am at a total loss. Is there anything I can do(other than run at 100 FSB)? Nathan P.S. I have enclosed the dmesg output for my Uniprocessor kernel dmesg.out.uni In the end I started swapping processors between the two machines. I found the problem followed 1 of my processors. I called Intel and after 2 days of convincing they RMAed my old processor and sent me a replacement. Both machines have been running perfectly since then. If you have any more processors I'd try swapping them around. But since you are seeing problems with 2 similar machines, I wouldn't get my hopes up as to this being the solution. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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/
Quotas not updating.
I'm running 2.4.1 (had been using 2.4.0 since it was released) with quota 2.00 on an ext2 filesystem mounted as /home. When a file is created or deleted from the file system the quota usage is not updated. If I run a "quotacheck -a" everything gets updated, but quickly after as mail is delivered or what ever the numbers get out of sync. If I run quotacheck and a user is updated to be over quota I can no longer create files as that user, so quotas are being inforced. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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/
Quotas not updating.
I'm running 2.4.1 (had been using 2.4.0 since it was released) with quota 2.00 on an ext2 filesystem mounted as /home. When a file is created or deleted from the file system the quota usage is not updated. If I run a "quotacheck -a" everything gets updated, but quickly after as mail is delivered or what ever the numbers get out of sync. If I run quotacheck and a user is updated to be over quota I can no longer create files as that user, so quotas are being inforced. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: hotmail not dealing with ECN
On Fri, 26 Jan 2001, Daniel Chemko wrote: > Microsoft are bad for dropping ICMP because of security.. .I mean try pinging > microsoft.com... It's down, ha ha, Microsoft is down! I'm joking of course. But you don't know how many times my techs have told me that. It's either that, or something is seeming a little strange on our network, and to trouble shoot, they ping microsoft.com and don't get a responce. Then they call me at home, to tell me that our T1s are down. I wonder how much bandwidth was used up by people pinging MS to trouble shoot when they still allowed ICMP packets through. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: hotmail not dealing with ECN
On Fri, 26 Jan 2001, Daniel Chemko wrote: Microsoft are bad for dropping ICMP because of security.. .I mean try pinging microsoft.com... It's down, ha ha, Microsoft is down! I'm joking of course. But you don't know how many times my techs have told me that. It's either that, or something is seeming a little strange on our network, and to trouble shoot, they ping microsoft.com and don't get a responce. Then they call me at home, to tell me that our T1s are down. I wonder how much bandwidth was used up by people pinging MS to trouble shoot when they still allowed ICMP packets through. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Delay in authentication.gy
On Mon, 8 Jan 2001, Alan Cox wrote: > And have identical bad problems with auth failures. Right now I've given up > trying to make 2.4 and YP mix because my RH setup assumes NIS auth will fail > fast during boot up scripts and it doesnt. > > Unfortunately for the quickfix folks, Dave is right about needing to sort it, > and that means someone has to sort glibc to use the new interfaces I just compiled glibc 2.2.1 against the 2.4.0 kernel headers today. I went to the local console to login. I was expecting to go get a coffee after typing my password, but was pleasantly surprised to see the prompt waiting for me in no time at all. So the newest glibc seems to have the problem fixed for me now. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Delay in authentication.gy
On Mon, 8 Jan 2001, Alan Cox wrote: And have identical bad problems with auth failures. Right now I've given up trying to make 2.4 and YP mix because my RH setup assumes NIS auth will fail fast during boot up scripts and it doesnt. Unfortunately for the quickfix folks, Dave is right about needing to sort it, and that means someone has to sort glibc to use the new interfaces I just compiled glibc 2.2.1 against the 2.4.0 kernel headers today. I went to the local console to login. I was expecting to go get a coffee after typing my password, but was pleasantly surprised to see the prompt waiting for me in no time at all. So the newest glibc seems to have the problem fixed for me now. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Delay in authentication.
On Mon, 8 Jan 2001, Scott Laird wrote:
>
> Is syslog running correctly? When syslog screws up, it very frequently
> results in this sort of problem.
>
I would guess that syslog is okay. I'm getting plenty of entries in my
various logs, along with a few boxes remote logging into this server.
Another interesting thing I have noticed about this delay. If I remove
the data in the password field from the shadow file ("username::...")
there is no pause during login.
-Chris
--
Two penguins were walking on an iceberg. The first penguin said to the
second, "you look like you are wearing a tuxedo." The second penguin
said, "I might be..." --David Lynch, Twin Peaks
-
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: Delay in authentication.
On Mon, 8 Jan 2001, Scott Laird wrote:
Is syslog running correctly? When syslog screws up, it very frequently
results in this sort of problem.
I would guess that syslog is okay. I'm getting plenty of entries in my
various logs, along with a few boxes remote logging into this server.
Another interesting thing I have noticed about this delay. If I remove
the data in the password field from the shadow file ("username::...")
there is no pause during login.
-Chris
--
Two penguins were walking on an iceberg. The first penguin said to the
second, "you look like you are wearing a tuxedo." The second penguin
said, "I might be..." --David Lynch, Twin Peaks
-
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: Delay in authentication.
On Mon, 8 Jan 2001, Igmar Palsenberg wrote: > check /etc/pam.d/login No pam. > Could be kerberos that is biting you, althrough that doesn't explain the > portmap story. So no kerberos. I just rebuilt the shadow suite (where my login comes from) to be on the safe side. But the problem is still there. ldd login shows: libshadow.so.0 => /lib/libshadow.so.0 (0x4001a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x4006) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) I'm running glibc-2.2, but this problem also existed in 2.1.x (which I had installed when I went to the 2.3 kernels that exposed this problem). -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Delay in authentication.
On Mon, 8 Jan 2001, David S. Miller wrote: > This definitely seems like the classic "/etc/nsswitch.conf is told to > look for YP servers and you are not using YP", so have a look and fix > nsswitch.conf if this is in fact the problem. What I have never gotten, is why on my machines (no specific distro, just everything built from source and installed by me) login takes a long time, unless I have portmap running. My /etc/nsswitch.conf would seem to be right: passwd: files group: files shadow: files hosts: files dns networks: files dns protocols: files services: files ethers: files rpc:files netgroup: files What else could effect that? -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Delay in authentication.
On Mon, 8 Jan 2001, David S. Miller wrote: This definitely seems like the classic "/etc/nsswitch.conf is told to look for YP servers and you are not using YP", so have a look and fix nsswitch.conf if this is in fact the problem. What I have never gotten, is why on my machines (no specific distro, just everything built from source and installed by me) login takes a long time, unless I have portmap running. My /etc/nsswitch.conf would seem to be right: passwd: files group: files shadow: files hosts: files dns networks: files dns protocols: files services: files ethers: files rpc:files netgroup: files What else could effect that? -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Delay in authentication.
On Mon, 8 Jan 2001, Igmar Palsenberg wrote: check /etc/pam.d/login No pam. Could be kerberos that is biting you, althrough that doesn't explain the portmap story. So no kerberos. I just rebuilt the shadow suite (where my login comes from) to be on the safe side. But the problem is still there. ldd login shows: libshadow.so.0 = /lib/libshadow.so.0 (0x4001a000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40033000) libc.so.6 = /lib/libc.so.6 (0x4006) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) I'm running glibc-2.2, but this problem also existed in 2.1.x (which I had installed when I went to the 2.3 kernels that exposed this problem). -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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/
Where to get quota.
Perhaps the help text for disk quotas needs to be updated, or at least the howto for quotas. The help text for disk quotas says to see the Quota mini-HOWTO. The howto says to get the quota source from: ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/subsystems/quota/all.tar.gz That doesn't exist anymore. I'm just looking for a quick pointer to the quota source, but also suggesting that maybe the help text should be updated. Or if someone points me in the right direction, I'll write to the author of the howto. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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/
Where to get quota.
Perhaps the help text for disk quotas needs to be updated, or at least the howto for quotas. The help text for disk quotas says to see the Quota mini-HOWTO. The howto says to get the quota source from: ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/subsystems/quota/all.tar.gz That doesn't exist anymore. I'm just looking for a quick pointer to the quota source, but also suggesting that maybe the help text should be updated. Or if someone points me in the right direction, I'll write to the author of the howto. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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/
feature flags set on rev 0 fs
I'm seeing a new warning with the 2.4.0-prerelease (could have been introduced in -pre11 or 12): EXT2-fs warning: feature flags set on rev 0 fs, running e2fsck is recommended Well I've run e2fsck (version 1.18) twice, and looked at the options for tune2fs. Is there an easy way to change the rev of the fs, without a format and restore? -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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/
feature flags set on rev 0 fs
I'm seeing a new warning with the 2.4.0-prerelease (could have been introduced in -pre11 or 12): EXT2-fs warning: feature flags set on rev 0 fs, running e2fsck is recommended Well I've run e2fsck (version 1.18) twice, and looked at the options for tune2fs. Is there an easy way to change the rev of the fs, without a format and restore? -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Trashing ext2 with hdparm
On 6 Dec 2000, H. Peter Anvin wrote: > > Please don't use the path /var/shm... it was a really bad precedent > set when someone suggested it. Use /dev/shm. > And I'll ask again... If this is now the recommend mount point, can we have devfs create this directory for us? -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: Trashing ext2 with hdparm
On 6 Dec 2000, H. Peter Anvin wrote: HARP Please don't use the path /var/shm... it was a really bad precedent set when someone suggested it. Use /dev/shm. /HARP And I'll ask again... If this is now the recommend mount point, can we have devfs create this directory for us? -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: Dual XEON - >>SLOW<< on SMP
On 2 Nov 2000, Ulrich Drepper wrote: > I'm seeing this as well, but only with PIII Xeon systems, not PII > Xeon. Every single timer interrupt on any CPU is accompanied by a NMI > and LOC increment on every CPU. > >CPU0 CPU1 > 0: 146727 153389IO-APIC-edge timer > [...] > NMI: 300035 300035 > LOC: 300028 300028 You mean that isn't supposed to happen? CPU0 CPU1 0:84801927786028IO-APIC-edge timer 1: 3 1IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 0IO-APIC-edge rtc 13: 0 0 XT-PIC fpu 23: 188915 191259 IO-APIC-level eth0 28: 16 14 IO-APIC-level sym53c8xx 29: 33655 33665 IO-APIC-level sym53c8xx 30: 0 0 IO-APIC-level es1371 NMI: 16266140 16266140 LOC: 16266123 16266122 ERR: 0 This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII chipset. I reported this on -test6 but got no replies. I'm now running -test10 and still seeing it. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: Dual XEON - SLOW on SMP
On 2 Nov 2000, Ulrich Drepper wrote: I'm seeing this as well, but only with PIII Xeon systems, not PII Xeon. Every single timer interrupt on any CPU is accompanied by a NMI and LOC increment on every CPU. CPU0 CPU1 0: 146727 153389IO-APIC-edge timer [...] NMI: 300035 300035 LOC: 300028 300028 You mean that isn't supposed to happen? CPU0 CPU1 0:84801927786028IO-APIC-edge timer 1: 3 1IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 0IO-APIC-edge rtc 13: 0 0 XT-PIC fpu 23: 188915 191259 IO-APIC-level eth0 28: 16 14 IO-APIC-level sym53c8xx 29: 33655 33665 IO-APIC-level sym53c8xx 30: 0 0 IO-APIC-level es1371 NMI: 16266140 16266140 LOC: 16266123 16266122 ERR: 0 This machine isn't even a Xeon, just a PIII CuMine on a ServerWorks HeIII chipset. I reported this on -test6 but got no replies. I'm now running -test10 and still seeing it. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: Question about signals
On Wed, 20 Sep 2000, Adam Watson wrote: > I am working to get Diald up and running and with both 2.2.16 and the 2.4.0 > series kernels I have been getting SIOCSIFMETRIC Operation not supported. > I've looked through the kernel docs and include files but couldn't find a > reference to that operation. > > Is there another name for that operation or does someone have the fix for > Diald-0.99.4? Sorry, no fix, but a question. Are you using diald to dial a PPP connection? If so, pppd has supported demand dialing for a while now. I found it much easier to set up. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: Question about signals
On Wed, 20 Sep 2000, Adam Watson wrote: I am working to get Diald up and running and with both 2.2.16 and the 2.4.0 series kernels I have been getting SIOCSIFMETRIC Operation not supported. I've looked through the kernel docs and include files but couldn't find a reference to that operation. Is there another name for that operation or does someone have the fix for Diald-0.99.4? Sorry, no fix, but a question. Are you using diald to dial a PPP connection? If so, pppd has supported demand dialing for a while now. I found it much easier to set up. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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/
2.4.0-test8 scsidrv.o can't link without modules
I just tried to build 2.4.0-test8 on a machine where I don't use modules at all, and thus have them disabled in the config. The kernel compile just about finishes, but scsidrv.o contains "scsi_register_module" and "scsi_unregister_module", so the link fails. -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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/
2.4.0-test8 scsidrv.o can't link without modules
I just tried to build 2.4.0-test8 on a machine where I don't use modules at all, and thus have them disabled in the config. The kernel compile just about finishes, but scsidrv.o contains "scsi_register_module" and "scsi_unregister_module", so the link fails. -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: [OT] Re: Availability of kdb
Now that is what I want on a t-shirt. ;) On Thu, 7 Sep 2000, Peter Samuelson wrote: > [Now, centuries-old theological arguments may well be of supreme > importance in some ways -- an undeniably subjective and personal > judgment -- but in terms of Linux kernel development they are usually > considered even more off-topic than the latest clever AC quote.] -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: [PATCH] devfs support for LVM
On Tue, 5 Sep 2000, Richard Gooch wrote: > > Yes. The userlevel tool can't handle other things without recompiling. > > Don't worry about that. I can add a rule to devfsd so it creates > appropriate compatibility entries. But the userlevel tool needs fixed too. Recompiling is fine, as long as it is easy to configure, a config file might be nice also. I know devfsd is nice and good, but I don't use it. At this point I have ALL my programs working without it. > > I can't use /dev/lvm, too because this is the name of the control file > > without lvm (and the lvm tools will barf if this is a dircetory. > > Well, how about another directory name? Can you think of something > else that would be appropriate? And no, "LVM" is not on! How about releasing a new version of the userlevel tools. Just list it as the required version in the Changes file. Have the new version check to see if /dev/lvm is a directory or file. It probally isn't the best idea to assume too much based on that fact, but it could be used as a basis for devfs vs. traditional /dev compatibility in one executable without needing a recompile. > But we really should stop namespace pollution in /dev, and doing it > before 2.4 is released is the best time. In fact, given that this > patch has only gone in recently, I'd be inclined to go with the names > I suggested and just break the userspace tools. People have to expect > that things may change before a production kernel is released. We just required a modutils upgrade. No one really complained. A few people (not many at all) cried about things breaking. But a quick pointer to the Changes file set them straight. So yes, do this now. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: [PATCH] devfs support for LVM
On Tue, 5 Sep 2000, Richard Gooch wrote: Yes. The userlevel tool can't handle other things without recompiling. Don't worry about that. I can add a rule to devfsd so it creates appropriate compatibility entries. But the userlevel tool needs fixed too. Recompiling is fine, as long as it is easy to configure, a config file might be nice also. I know devfsd is nice and good, but I don't use it. At this point I have ALL my programs working without it. I can't use /dev/lvm, too because this is the name of the control file without lvm (and the lvm tools will barf if this is a dircetory. Well, how about another directory name? Can you think of something else that would be appropriate? And no, "LVM" is not on! How about releasing a new version of the userlevel tools. Just list it as the required version in the Changes file. Have the new version check to see if /dev/lvm is a directory or file. It probally isn't the best idea to assume too much based on that fact, but it could be used as a basis for devfs vs. traditional /dev compatibility in one executable without needing a recompile. But we really should stop namespace pollution in /dev, and doing it before 2.4 is released is the best time. In fact, given that this patch has only gone in recently, I'd be inclined to go with the names I suggested and just break the userspace tools. People have to expect that things may change before a production kernel is released. We just required a modutils upgrade. No one really complained. A few people (not many at all) cried about things breaking. But a quick pointer to the Changes file set them straight. So yes, do this now. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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: [PATCH] 2.2: /proc/config.gz
What about those of us who don't have modules enabled. "make modules_install" complains. I'm still like the idea of /lib/kernel or /lib/linux. Keep /lib/modules for modules. Or on my machines I won't even have to create /lib/modules. On Thu, 31 Aug 2000, Robert Greimel wrote: > It would be nice if "make modules_install" would automatically copy System.map > to /lib/modules// . -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - 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/
