OOPS after upgrading CPU's ... (fwd)
my apologies for the cross-posting ... but since that matter is urgent for me and noone on the smp mailinglist have answered so far, i hope that i will find somebody on this list who can give me advice :) thanks! -- Forwarded Message -- Date: 10/05/00 00:19:53 +0200 From: Matthias Weidle <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: OOPS after upgrading CPU's ... hi there! there is some strange stuff going on here and after checking all sources of information (without success) i hope that one of you may have the answer ... :) ok, here is the problem: i'm running a smp server machine (mostly doing file server stuff) which was running pretty stable with 2 celeron-400 cpu's. i got about 60 days uptime without problems - even under heavy load! a few weeks ago i decided to upgrade the celeron cpu's to some older p3's (those with 512kb cache, no coppermine) and did not expect any complications with that upgrade. but since then i can't get the machine up for more than a couple of days (depending on the load). sooner or later it locks with the following kernel oops message: ksymoops 2.3.4 on i686 2.2.15pre19ext3. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.15pre19ext3/ (default) -m /usr/src/linux/System.map (default) Warning (compare_ksyms_lsmod): module i2c-isa is in lsmod but not in ksyms, probably no symbols exported Warning (compare_ksyms_lsmod): module i2c-piix4 is in lsmod but not in ksyms, probably no symbols exported Warning (compare_ksyms_lsmod): module nfsd is in lsmod but not in ksyms, probably no symbols exported Warning (compare_ksyms_lsmod): module w83781d is in lsmod but not in ksyms, probably no symbols exported Unable to handle kernel NULL pointer dereference at virtual address 0013 current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = Oops: 0002 CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010006 eax: 0013 ebx: 0260 ecx: cc100480 edx: cbffa000 esi: cbffa000 edi: 0013 ebp: cbffbf74 esp: cbffbf4c ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, process nr: 1, stackpage=cbffb000) Stack: 0013 c01104c1 0013 cbffbf7c cbffa000 c0226020 c010b850 0013 cbffbf7c cbffa000 c010a328 cbffa000 cbffa000 cbffa000 cbffa000 c0226020 0080 0018 cbff0018 ff13 c0107b15 0010 Call Trace: [] [] [] [] [] [] Code: e0 28 21 c0 8b 04 85 e4 28 21 c0 83 f8 ff 74 53 bf 00 e0 ff >>EIP; c01100c5<= Trace; c01104c1 Trace; c010b850 Trace; c010a328 Trace; c0107b15 Trace; c019c875 Trace; c01166b7 Code; c01100c5 <_EIP>: Code; c01100c5<= 0: e0 28 loopne 2a <_EIP+0x2a> c01100ef <= Code; c01100c7 2: 21 c0 andl %eax,%eax Code; c01100c9 4: 8b 04 85 e4 28 21 c0 movl 0xc02128e4(,%eax,4),%eax Code; c01100d0 b: 83 f8 ff cmpl $0x,%eax Code; c01100d3 e: 74 53 je 63 <_EIP+0x63> c0110128 Code; c01100d5 10: bf 00 e0 ff 00movl $0xffe000,%edi Kernel panic: Attempted to kill the idle task! 4 warnings issued. Results may not be reliable. there have been 4-5 lockups since the upgrade and it was always the same oops message. for the record some additional data about the server box: soltek sl-68a dual slot1 motherboard (with latest h4 bios) 2 p3-550 with 512kb cache promise udma66 controler intel etherexpress nic 64 + 128 mb ram (pc100) 6 hdd's (maxtor and ibm drives) kernel: 2.2.15pre20 (thats pretty much 2.2.16 i guess) + ide patch + ext3 patch + ppdd patch if you need any additional data please don't hesitate to contact me for that! is it really possible to break the stability of a box by simply upgrading to a better cpu? my first idea was bad ram ... because it is running at 100 mhz now (66 with the celerons). but then i realized that this would be pretty unlikely considering the same oops message all the time. is there somebody out there who can help me? best regards, matt. -- End Forwarded Message -- - 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: Tux 2 patents
Daniel Phillips wrote: > > "Jeff V. Merkey" wrote: > > > > > "Jeff V. Merkey" wrote: > > > > > > > > The patent attorneys at Malinkrodt received the materials Daniel sent > > > > yesterday on the Tux 2 patents via courier and are working on the > > > > analysis. They said they would have something for us to post on LKML > > > > next week. > > > > > > I'll calm down and work on my magicpoint slides for now. > > > > I think you are ok based on our preliminary review, but the patent lawyers > > will go down each claim granted by the USPTO in related patents, and > > analyze them relative to your proposed methods. > > And if my method is OK, then is there a reason why we should not apply > for a "white hat" patent with a GPL-compatible licence? And if my > method is not only OK, but superior in every way, then aren't we > winning? Once you use the technique and it's documented as clear by a patent lawyer, it will be safe for you to use forever, particularly if it's in the public domain. This is winning Jeff > > -- > Daniel > - > 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/ - 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: good book on kernel
O'Reilly have just released "Understanding the Linux Kernel" http://www.ora.com/catalog/linuxkernel/ Cheers Michael - Original Message - From: RAJESH BALAN <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 05, 2000 7:29 PM Subject: good book on kernel > Hi, > Iam interested in learning linux kernel. Can anyone > suggest a really good book for kernel internals (im > not bothered abt the price). i 've a book named > "linux kernel internals". i want something more to > follow the code completely. > tx, > rajesh balan > > > > __ > Do You Yahoo!? > Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! > http://photos.yahoo.com/ > - > 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/ > - 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: failure to burn CDs under 2.4.0-test9
On Thu, Oct 05, 2000 at 11:15:51PM -0700, Andre Hedrick wrote: > On Thu, 5 Oct 2000, Jeff V. Merkey wrote: > > > I am seeing this as well. I got around it by setting speed=2. If you > > are using one of the newer R/W CD/DVD drives (which are slower than > > crap, BTW on Linux), you should set the speed manually and try > > progressively slower settings until you find one that works. > > > cdrecord -v speed=2 dev=1,0,0 file.iso > > Sorry Jeff, I have to call you on that one. > > HP's are the know to burn at 4x and 8x clean. > I just got my 8x CD-RW HP 9100 series and will verify the issues. > Also will try to verify on my Panasonic DVD-RAM ATAPI. I am using a Panasonic RW/DVD. We went through 5 CD's today on 2.4.0-9 and it kept getting errors until we used the speed=2 setting (Larry Angus's idea). :-) Jeff > Linux DVD-RAM is looking like it will be showcased at Comdex in the > DVD-RAM Pavilion. > > Cheers, > > Andre Hedrick > The Linux ATA/IDE guy > - 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: failure to burn CDs under 2.4.0-test9
In <[EMAIL PROTECTED]> "Jeff V. Merkey" <[EMAIL PROTECTED]> writes: >On Fri, Oct 06, 2000 at 07:55:22AM +0200, Henrik Størner wrote: >> In <[EMAIL PROTECTED]> Christoph Lameter ><[EMAIL PROTECTED]> writes: >> >> >Comparing CD contents with the original after burning showed mismatches 4 >> >times in a row. Booted into linux 2.2.18 and everything is fine. >> >> I had quite a few problems burning the Red Hat 7 ISO images while >> running 2.4.0-test9-pre6. Symptoms were SCSI errors when trying >> to fixate the session. This happened on two very different systems >> (one pure SCSI system, the other pure IDE), both running Red Hat 6.2. >> >I am seeing this as well. I got around it by setting speed=2. If you >are using one of the newer R/W CD/DVD drives (which are slower than >crap, BTW on Linux), you should set the speed manually and try >progressively slower settings until you find one that works. Heh - the first drive I saw this on was an old HP IDE drive only capable of burning at double-speed. The second - a Yamaha SCSI drive - does support CDRW, but I rarely use it. The Yamaha does quad-speed, which is what I used when the burn faild. Haven't had any problems prior to this with these drives running at their max speed, though. And the same drive burns the same image just fine while running 2.2.17. No DVD support on either of the two. -- Henrik Storner | "Crackers thrive on code secrecy. Cockcroaches breed <[EMAIL PROTECTED]> | in the dark. It's time to let the sunlight in." | | Eric S. Raymond, re. the Frontpage backdoor - 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: failure to burn CDs under 2.4.0-test9
From: "Andre Hedrick" <[EMAIL PROTECTED]>
> On Thu, 5 Oct 2000, Jeff V. Merkey wrote:
>
> > I am seeing this as well. I got around it by setting speed=2. If you
> > are using one of the newer R/W CD/DVD drives (which are slower than
> > crap, BTW on Linux), you should set the speed manually and try
> > progressively slower settings until you find one that works.
>
> > cdrecord -v speed=2 dev=1,0,0 file.iso
>
> Sorry Jeff, I have to call you on that one.
>
> HP's are the know to burn at 4x and 8x clean.
> I just got my 8x CD-RW HP 9100 series and will verify the issues.
> Also will try to verify on my Panasonic DVD-RAM ATAPI.
> Linux DVD-RAM is looking like it will be showcased at Comdex in the
> DVD-RAM Pavilion.
For that matter Andre a 4 speed HP can certainly burn at 4 speed except
that cdrecord and the OS conspire to prevent this through a mathematical
error. It's rather a tad frustrating.
{^_^}
-
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/
Hot swap IDE
Lots of great info on the list thank you all!!! after reading i think most of the software raid howto's and hardware one's also.. I've Built a box with 3 drives and a hot spare.. p iii 500 256meg ram aus mother board (i think via chip set) two promise ata66 cards and 5 30 gig maxtor drives in promise ata66 hot swap drive bays. windows nt... just kidding... linux2.4.0-test9 and it's working great... worked in test8 test6 was not good I have not had to rebuild the array from scratch since moving to test8 (the hotremove did not work) if i compile the promise drivers then when i power off a drive for testing a failure the system freezes(i might not have done the sysrq correctly) i have to power off the system if i don't compile the promise drivers i can enable DMA (and am very happy very FAST). there does not seem to be a command to reset the IDE buss(this is mentioned in the raid howto's) can i compile the IDE drivers as a module and remove/install then while the system is running on the raid(i think not)... I'm booting from a 20 meg none raid drive (to be raid 1 in final production) i can replace the drive but it must be with the same type of drive... but the system's not really happy about the drive change and complains if the drive was partioned .. ide software raid seems soo close to ready for production... I have turned the system OFF several times and just turned off one drive... then the system while it's rebuilding the array... even booted with a failed drive... I tried some of this stuff with 2.2.16 redhat it was ugly.. as in complete reinstall and the system could not boot if a drive was failed (i accepect that this could be me) Thank you for your time... and a GREAT OS Mitchell Hicks - 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: Tux 2 patents
"Jeff V. Merkey" wrote: > > > "Jeff V. Merkey" wrote: > > > > > > The patent attorneys at Malinkrodt received the materials Daniel sent > > > yesterday on the Tux 2 patents via courier and are working on the > > > analysis. They said they would have something for us to post on LKML > > > next week. > > > > I'll calm down and work on my magicpoint slides for now. > > I think you are ok based on our preliminary review, but the patent lawyers > will go down each claim granted by the USPTO in related patents, and > analyze them relative to your proposed methods. And if my method is OK, then is there a reason why we should not apply for a "white hat" patent with a GPL-compatible licence? And if my method is not only OK, but superior in every way, then aren't we winning? -- Daniel - 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: failure to burn CDs under 2.4.0-test9
On Thu, 5 Oct 2000, Jeff V. Merkey wrote: > I am seeing this as well. I got around it by setting speed=2. If you > are using one of the newer R/W CD/DVD drives (which are slower than > crap, BTW on Linux), you should set the speed manually and try > progressively slower settings until you find one that works. > cdrecord -v speed=2 dev=1,0,0 file.iso Sorry Jeff, I have to call you on that one. HP's are the know to burn at 4x and 8x clean. I just got my 8x CD-RW HP 9100 series and will verify the issues. Also will try to verify on my Panasonic DVD-RAM ATAPI. Linux DVD-RAM is looking like it will be showcased at Comdex in the DVD-RAM Pavilion. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Intel 820 Chipset
John Wendel wrote: > > Hi, > > Does anyone have an agpgart patch for the Intel 820 chipset? > > If not, I'll be happy to help if there is some dumbass work. > I'm sorry I'm not smart enough to do this one myself. modprobe agpgart agp_try_unsupported=1 -- LarsG - 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: failure to burn CDs under 2.4.0-test9
On Fri, Oct 06, 2000 at 07:55:22AM +0200, Henrik Størner wrote: > In <[EMAIL PROTECTED]> Christoph Lameter ><[EMAIL PROTECTED]> writes: > > >Comparing CD contents with the original after burning showed mismatches 4 > >times in a row. Booted into linux 2.2.18 and everything is fine. > > I had quite a few problems burning the Red Hat 7 ISO images while > running 2.4.0-test9-pre6. Symptoms were SCSI errors when trying > to fixate the session. This happened on two very different systems > (one pure SCSI system, the other pure IDE), both running Red Hat 6.2. > I am seeing this as well. I got around it by setting speed=2. If you are using one of the newer R/W CD/DVD drives (which are slower than crap, BTW on Linux), you should set the speed manually and try progressively slower settings until you find one that works. i.e. cdrecord -v speed=2 dev=1,0,0 file.iso Jeff > -- > Henrik Storner | "Crackers thrive on code secrecy. Cockcroaches breed > <[EMAIL PROTECTED]> | in the dark. It's time to let the sunlight in." > | > | Eric S. Raymond, re. the Frontpage backdoor > - > 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/ - 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: failure to burn CDs under 2.4.0-test9
In <[EMAIL PROTECTED]> Christoph Lameter <[EMAIL PROTECTED]> writes: >Comparing CD contents with the original after burning showed mismatches 4 >times in a row. Booted into linux 2.2.18 and everything is fine. I had quite a few problems burning the Red Hat 7 ISO images while running 2.4.0-test9-pre6. Symptoms were SCSI errors when trying to fixate the session. This happened on two very different systems (one pure SCSI system, the other pure IDE), both running Red Hat 6.2. -- Henrik Storner | "Crackers thrive on code secrecy. Cockcroaches breed <[EMAIL PROTECTED]> | in the dark. It's time to let the sunlight in." | | Eric S. Raymond, re. the Frontpage backdoor - 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: Tux2 - evil patents sighted
Marty Fouts wrote: > Factoid: 90% of all patents are never challenged, while 80% of those that > are are overturned. In otherwords, 2% of patents are successfully defended, just enough to keep the serfs in line. >"Going into court is throwing the dice." If I am going to throw dice I'd much prefer to do it with 4/1 odds in my favor. -- Daniel - 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: Tux 2 patents
On Fri, Oct 06, 2000 at 07:14:44AM +0200, Daniel Phillips wrote: > "Jeff V. Merkey" wrote: > > > > The patent attorneys at Malinkrodt received the materials Daniel sent > > yesterday on the Tux 2 patents via courier and are working on the > > analysis. They said they would have something for us to post on LKML > > next week. > > I'll calm down and work on my magicpoint slides for now. > I think you are ok based on our preliminary review, but the patent lawyers will go down each claim granted by the USPTO in related patents, and analyze them relative to your proposed methods. Patents are granted for specific "methods" or ways of implementing stuff, and to infringe, you have to copy the methods described in the claims of the patent and be using them in the same basic combinations. The patent process in the US is a lot like filing a lawsuit. The patent application contains a series of "claims" for the invention, just as a petition for relief in a lawsuit contains "claims" of issues of fact. The patent lawyers have this fancy software (that costs a lot of $$$) that can cross reference your invention with thousands of patents quickly, and look for similiar "methods". The three you identified was very light -- there's probably going to be a larger number identified by these guys since patent attorneys have access to patents pending and provisional patent applications, which are not available to the general public. There's no telling how many provisional patents might be around with something like this. I would be unconcerned. 95% of getting around patents is just having patent lawyers to handle the politics at the USPTO. Most of the patent process in the US is very much a political process as much as a legal one. Think of a patent lawyer as someone in Congress lobbying for your interests, and you will have kind of the right picture of the "patent racket" in the US. Most patent infringment lawsuits end up in mediation with the USPTO with one side or the other having specific patent claims revoked because one side or the other gets their patent lawyers sending letters to the USPTO challenging prior art claims. Novell in their lawsuit with Roger Billings over the Network Operating System patents in 1993 convinced the patent office to invalidate his patents by shear force in numbers of legions of patent lawyers and a mountain of research and prior art claims -- they could not have gotten out of the infringement suit otherwise :-) Jeff > > -- > Daniel > - - 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: Tux 2 patents
"Jeff V. Merkey" wrote: > > The patent attorneys at Malinkrodt received the materials Daniel sent > yesterday on the Tux 2 patents via courier and are working on the > analysis. They said they would have something for us to post on LKML > next week. I'll calm down and work on my magicpoint slides for now. > Alain Williams wrote: > > > > I remember when at the University of Cambridge (in England) about 25 years ago > > seeing some work then about the Jackdaw (or was is Jackard) database system > > that had the great feature of being immune to OS crashes, it used a phased > > update mechanism where new blocks were written to disk and the last block > > written was the one that contained the switched pointer, until this last block > > had been written the changes had not been made. Since the write of a disk block > > was atomic the database would never be corrupt. > > > > If someone wants I think that I still have a (paper) copy of the report describing > > this. I can send/fax a copy if wanted. > > > > I don't subscribe to this list, so please reply direct if someone wants it. > > > > (Please don't request a copy just out of curiosity since I don't want to have > > to post/fax copies that won't help resolve this case by showing prior art.) Of course IANAL but it seems to me, the more similar things we find the better. I think you have to find essentially all the key ideas pre-existing in one piece of work to have a good piece of prior art, it's my understanding. Now of course that sucks, and the whole patent system sucks, but that's how the game is played. Of course, we have other options in this case. Naturally, I intend to show exactly what my prior work was, but I'm waiting to hear words from the lawyer first. I'm also waiting to hear from NetApp management, publicly or privately. I know they're aware of this, and have been for some time. We've already heard from one right-thinking NetApp employee as I'm sure you're aware. I don't think I should contact NetApp privately, not before I've had legal advice. -- Daniel - 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: linux-2.4.0-test9
Date: Thu, 5 Oct 2000 22:05:08 -0700 From: Richard Henderson <[EMAIL PROTECTED]> Compile with -fno-common and you'll get .bss, but not COMMON, variables. It's the COMMON bits that are screwing your games. This might be useful to catch people using extern properly as well. Later, David S. Miller [EMAIL PROTECTED] - 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: linux-2.4.0-test9
On Wed, Oct 04, 2000 at 05:25:44PM -0700, David S. Miller wrote: > These items are specifically placed into the data section, not the > BSS, because these alignment games are not possible in the BSS. Compile with -fno-common and you'll get .bss, but not COMMON, variables. It's the COMMON bits that are screwing your games. r~ - 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: is there a limit on bss size?
On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
> Hi,
>
> I put a simple construct in kernel/sched.c like this:
>
> struct runq_log_s {
> char comm[16];
> int pid;
> } runq_log[1024*1024];
>
> and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
Look at the code in arch/i386/kernel/entry.S that initializes our temporary
page tables:
/*
* Initialize page tables
*/
movl $pg0-__PAGE_OFFSET,%edi /* initialize page tables */
movl $007,%eax /* "007" doesn't mean with right to kill, but
PRESENT+RW+USER */
2: stosl
add $0x1000,%eax
cmp $empty_zero_page-__PAGE_OFFSET,%edi
jne 2b
/*
* The page tables are initialized to only 8MB here - the final page
* tables are set up later depending on memory size.
*/
.org 0x2000
ENTRY(pg0)
.org 0x3000
ENTRY(pg1)
My guess is we're trying to access higher addresses, and getting another
fault for those. Could you try modifying head.S in the obvious way to
map more than 8MB during the boot process ?
> I will try with a smaller value and see what is the limit but am curious
> as to the reason. The last thing I see is Uncompressing linux... Maybe the
> code in arch/i386/kernel/head.S which clears BSS is broken at "large
> values"?
That code would indeed be what causes the page faults we cannot handle,
if my theory is correct.
Philipp Rumpf
-
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/
tun/tap devices on 2.4.0-testX
need help getting tapX devices operational on 2.4 for 2.4 using the new tun.o module I cannot create a tap0 interface. on 2.2 it is the ethertap.o module. changing modules.conf allows the module to load but the interface does not come up: ifconfig tap0 192.168.0.10 up SIOCSIFADDR: No such device tap0: unknown interface: No such device tap0: unknown interface: No such device has anyone successfully gotten this to work, if so how? using devfs, which has created /dev/netlink/tapX devices... symlinking /dev/netlink/tap0 /dev/tap0 doesn't help. #define TUN_DEBUG 1, in tun.c doesn't help, fails to compile. TIA Martin - 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: Phase tree algorithm defined
Andi Kleen wrote: > As far as I can see (from reading fs/hpfs/*) HPFS uses a btree (or perhaps > b*tree) on disk. For what: Directory? Data Index? Allocation Map? All of the above? -- Daniel - 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: Final ] WAS (Re: [PATCH/RFC] (long) network interface changes
Date: Mon, 25 Sep 2000 22:20:36 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> Final patch with feedback from Henner to change the naming convention of the return codes. Clean it up, polish it, junk it etc. Jamal, I have no problems with these changes I think. Could you resend me a clean complete diff against test9 final? Thank you. Later, David S. Miller [EMAIL PROTECTED] - 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: evil patents
Martin Pool wrote: > > I worked on something similar to tuxfs a while ago: > > http://linuxcare.com.au/projects/snapfs/ > > This does clash with the patent claims and it was done only a couple > of years ago, so it's no direct use as prior art. I do agree about > software patents: once one starts thinking about the requirements the > method is fairly obvious. > > In fact I'd be surprised if BSD's write ordering doesn't come close to > clashing with the method of moving from one consistent state to > another. I'll read the full text on the weekend. BSD's write ordering doesn't quite cut it because it doesn't preserve a complete filesystem state. But the following do: Auragen (ask Victor Yodaiken) Nirvana db (my previous work) > I didn't hear anything from NetApp, though I did talk for a little > while with somebody from Veritas. I think they were trawling through > the l-k archives looking for work on filesystems. It's nice to know we're doing other people's work for them. Oh, wait, that's what we're supposed to do! Just so long as they remember to put some cookies back in the jar after they've munched on the ones they like. > As it happens I too just had a brush with an evil proprietary company: > > http://gnukeyring.sourceforge.net/safekeys/ > > I don't think NetApp would behave this badly. Soon, all of us will be having these brushes. Patents are a fence around Linux, trying to hold us in, keep us from using techniques newer than 17 years old. Of course, we can't accept that - it would be death for us. Um, I seem to recall Microsoft's Halloween II memo made special note of exactly that point. > On a more positive note I'm interested in getting back into this kind > of development. Are you looking for help? Yes, absolutely I am: http://innominate.org/~phillips/tux2/ Tux2 coding is temporarily suspended until after I come back from Atlanta (ALS) and Miami (Storage conference). After that I'm raring to go. There are plenty of design notes to read in the tux2-dev mailing list archives: http://innominate.org/mailman/listinfo/tux2-dev We *will* get through this NetApp thing in a satisfactory way, one way or another. In the meantime I'm really looking forward to fixing up Tux2 for 2.4.0. I have in mind a really great way to map the metadata into the page cache - and even into linear memory - using Al Viro's address_mapping machinery. This will actually make the 2.4.0 code cleaner than the 2.2.13 version and way more efficient. -- Daniel - 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: poll(2) semantics changed in 2.4.0-? vs. 2.2.16?
On Fri, Oct 06, 2000 at 02:13:45AM +0200, Martin Diehl wrote: > So, for me the 2.4.0-test9 behavior does not only differ from 2.2 and what > manpages say - I'm just wondering how to detect the unreachable peer port? > poll()-timeout means no response at all, which is sth different and forces > blocking for some time. Nonblocking recvfrom() without poll() wouldn't > help, since the pending error isn't passed to it either. Alexey Kuznetsov ([EMAIL PROTECTED]) changed it. Ask him why he did it, I agree with you that it would make more sense to keep the old behaviour (even though it is differing from most other BSD sockets implementations) To answer your question: you'll only get the error reported now when the UDP socket is either connect(2)ed or when you enabled asynchronous error reporting using IP_RECVERR. -Andi - 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: one-line umount patch needed for am-utils
On Tue, 3 Oct 2000, Alexander Viro wrote: > Nope. Doesn't have to be a symlink - it can be a directory. Overmounted by > bind-mount - you can mount over a mountpoint. And do a mount onto it while the kernel is waiting for revalidation? I'm sorry, but that makes it even more dependent on the kernel internals than the symlink hack. What if the kernel has already done the mountpoint crossing at the time it decides to do the revalidation? What if some other kernel in the future decides to do just that? There is one other downside: if you overlay it, you can't unmount it unless you also unmount the filesystem mounted over. Or, one of the key features of amd is that you can kill it, umount its own mount points and restart it, without having to unmount the real NFS filesystems mounted by amd. In most cases you couldn't do that anyway, unless you killed all the users on the system that were using them. [the autofs-enabled amd is the exception to the above rule, but that's a deficiency in the Linux autofs, not in amd. Linux autofs doesn't allow its mount points to be restarted (taken over by another automount process)] No, not acceptable. The future has AUTOFS written in capitals, but for now we'll have to live with what we have.. > > Can't do that. As I said, there are real people using this feature out > > there, it cannot be removed. I know what you're thinking, emulate direct > > mounts using indirect mounts (and/or autofs). It's possible, but not > > without system administrator support, because amd then needs a third > > directory in the namespace to support the indirect mounts, whose name has > > not been provided and which cannot simply appear out of the blue. > > Indeed it doesn't. Replace symlinks with directories and make > e.g. revalidation to trigger mount --bind. See the above. Can't do that, sorry. > Oh, that I agree with - we probably shouldn't allow such mounts in the > first place (non-directories and directories shouldn't turn into each > other). But they don't. You are overlaying a directory with some other object -- a symlink in this case. It's a different object in a different filesystem, so no problem there, and indeed all unix kernels out there (linux included) handle it just fine. Linux however won't allow you to unmount it. > Not much - I'ld check do_follow_mount() and neighbors, though (watch for > assumptions re directory vs. non-directory in the lookup_dentry() and > other places using ->d_covers/->d_mounts). I checked. super.c doesn't make any assumptions about the root of the filesystem being mounted/umounted. Neither does follow_mount in namei.c, it simply replaces the covered dentry with the root dentry of the covering filesystem. lookup_dentry calls follow_mount and _then_ it calls do_follow_link, and only after that it checks to see if the dentry is a directory, so we're safe there. I couldn't find anything in dcache.c, either. These three (namei, dcache and super.c) are the only that deal with mountpoints, so I think we're pretty safe. Alan, what's your opinion on this? > Again, the right thing for 2.4 is to do bind-mount instead of playing with > symlinks. As for the autofs plans - ask HPA... Unless something really dramatic happens in 2.4 (which I doubt at this point), autofs is not going to be significantly different for what we had in 2.2, at least from amd's point of view. The only additional feature of autofs v4 is that it allow us to do host mounts. Perhaps at some point in the near future I'll write the ioctl support for both autofs v3 and v4, to allow the take-over of a catatonic autofs mountpoint. If nobody beats me to it, that is. Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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: linux-2.4.0-test9
On Fri, 6 Oct 2000 01:19:16 +0200,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>David S. Miller wrote:
>>> These items are specifically placed into the data section, not the
>>> BSS, because these alignment games are not possible in the BSS.
>>
>>That would mean the BSS needs support alignment games.
>>
>> The problem is it doesn't work, please go try it.
>> So until it does work, I am going to revert this change.
>
>Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
>and it should do what you want.
>
>Heck, section ".bss" might give you the alignment without the allocation
>but I'm not as confident about that.
Call me mad but you could actually try this instead of guessing.
# cat x.c
int __attribute__ ((section (".data"))) int1;
int __attribute__ ((section (".bss"))) int2;
int __attribute__ ((section (".data.init"))) int3;
int __attribute__ ((section (".data.init"))) int4 = 0;
# gcc -c -o x.o x.c
# nm x.o
t gcc2_compiled.
B int1
0004 B int2
0008 B int3
D int4
# objdump -h x.o
x.o: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0034 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 0034 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 000c 0034 2**2
ALLOC
3 .note 0014 0034 2**0
CONTENTS, READONLY
4 .data.init0004 0048 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .comment 003d 004c 2**0
CONTENTS, READONLY
int[123] all end up in .bss, no matter what attributes you assign. If
you want special alignment then you must initialize the variable, even
if that means a zero initializer.
-
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: linux-2.4.0-test9
Date:Fri, 6 Oct 2000 01:19:16 +0200
From: Jamie Lokier <[EMAIL PROTECTED]>
Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
and it should do what you want.
Heck, section ".bss" might give you the alignment without the allocation
but I'm not as confident about that.
Well part of the issue is that the surrounding data items were moved
into the .bss section. That in and of itself I have no problems with.
How, if I put the cacheline_pad into .data will it help the placement
or surrounding .bss segment variables? Your suggestion really doesn't
solve the problem while retaining the intention of these recent test9
changes.
Later,
David S. Miller
[EMAIL PROTECTED]
-
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: Tux 2 patents
Forward the document to [EMAIL PROTECTED] Regarding patents, for prior art to be valid it has to have been "reduced to practice" (the legal term). That means it has to have been implemented and the theory demonstrated. There's no real requirement under US Patent Law that it be shipped, turned into code, etc., but in order to qualify as "prior art" is has to have been shown to have been "reduced to practice" in some meaningful way, and isn't hot air. If your document meets these requirements, it will count towards this issue ... Jeff "Jeff V. Merkey" wrote: > > The patent attorneys at Malinkrodt received the materials Daniel sent > yesterday on the Tux 2 patents via courier and are working on the > analysis. They said they would have something for us to post on LKML > next week. > > Jeff > > Alain Williams wrote: > > > > Hi, > > > > I remember when at the University of Cambridge (in England) about 25 years ago > > seeing some work then about the Jackdaw (or was is Jackard) database system > > that had the great feature of being immune to OS crashes, it used a phased > > update mechanism where new blocks were written to disk and the last block > > written was the one that contained the switched pointer, until this last block > > had been written the changes had not been made. Since the write of a disk block > > was atomic the database would never be corrupt. > > > > If someone wants I think that I still have a (paper) copy of the report describing > > this. I can send/fax a copy if wanted. > > > > I don't subscribe to this list, so please reply direct if someone wants it. > > > > (Please don't request a copy just out of curiosity since I don't want to have > > to post/fax copies that won't help resolve this case by showing prior art.) > > > > Cheers > > > > -- > > Alain Williams > > - > > 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/ - 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: Tux 2 patents
The patent attorneys at Malinkrodt received the materials Daniel sent yesterday on the Tux 2 patents via courier and are working on the analysis. They said they would have something for us to post on LKML next week. Jeff Alain Williams wrote: > > Hi, > > I remember when at the University of Cambridge (in England) about 25 years ago > seeing some work then about the Jackdaw (or was is Jackard) database system > that had the great feature of being immune to OS crashes, it used a phased > update mechanism where new blocks were written to disk and the last block > written was the one that contained the switched pointer, until this last block > had been written the changes had not been made. Since the write of a disk block > was atomic the database would never be corrupt. > > If someone wants I think that I still have a (paper) copy of the report describing > this. I can send/fax a copy if wanted. > > I don't subscribe to this list, so please reply direct if someone wants it. > > (Please don't request a copy just out of curiosity since I don't want to have > to post/fax copies that won't help resolve this case by showing prior art.) > > Cheers > > -- > Alain Williams > - > 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/ - 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: ack number in a connection-refused RST
From: "Alan Curry" <[EMAIL PROTECTED]> Date:Thu, 5 Oct 2000 18:03:55 -0500 (EST) 3. Does anybody know where to file a bug report on the Sega Dreamcast TCP? Eventually it should reach Microsoft, since if I remember correctly the dreamcast uses their networking stack. Linux should not honor the incorrect sequence number. If the sequence number is incorrect, the RST could legitimately be for another connection. It is pretty clear in the tcp RFCs what is supposed to happen here. Later, David S. Miller [EMAIL PROTECTED] - 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: svc: unknown program 100227 (me 100003)
Thus spake Harald Dunkel ([EMAIL PROTECTED]): > Maybe a stupid question, but it would be nice to know what this > message means: > > fright kernel: svc: unknown program 100227 (me 13) > > 'fright' is the name of the machine in question (2.4.0-test6, x86). > I get this about 40 times per day. That's a client requesting ACL information from nfsd on fright. SunOS does this every mount request. Since linux doesn't have ACLs, nfsd is simply saying "hey, i don't know what this is". It's nothing to worry about... -- oneiros ([EMAIL PROTECTED]) 1024D/62C2F77D 941432434515 url: http://www.darkspire.net/ EBB8 AF14 8C43 2F12 7623 126593210518 irc: EFnet / tietNET / opn C0AA C0AE 56D4 62C2 F77D 723904868285 - 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: Majordomo is sick
It's not majodomo. It's somone who is subscribed to the list bouncing things back. Could be a broken mail to news gateway or some other mis scripted feature. Read the mail headers and you can see fairly quickly who is responsable. Gerhard On Thu, 5 Oct 2000, Jeff V. Merkey wrote: > > > [EMAIL PROTECTED] is sick and is sending messages in a circle. > Better check the /etc/aliases file and make sure a record isn't pointing > somewhere it should not. > > Jeff > > [Fwd: Returned mail: Too many hops 29 (25 max): from > <[EMAIL PROTECTED]> via vger.kernel.org, to > <[EMAIL PROTECTED]>] -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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] APIC, NMI watchdog support on UP systems
On Wed, 4 Oct 2000, Ingo Molnar wrote:
>the latest UP-APIC patch against 2.4.0-test9 (upapic-2.4.0-test9-F5), can
>be downloaded from:
>
> http://www.kernel.org/pub/linux/kernel/people/mingo/apic-patches/
>
>this one should work on all systems - let me know how it behaves, reports,
>suggestions welcome. If any change didnt make it into this patch then
>please resubmit, there were major changes.
>...
> - reworked the APIC-enabling code and boot order along the suggestion of
> Mikael Pettersson, APICs should now be enabled early enough on all
> systems. This should also fix the boot problems seen by Prasanna
> Narayana. (me)
Sorry, but this still doesn't work. I tested -F5 and -F8 and they both
hang at "Calibrating delay loop". Same problem as before: the local APIC's
LVT0 and LVT1 entries hadn't yet been reprogrammed to ExtINT and NMI,
respectively, so no interrupts could be delivered to the CPU core.
I did the following to make -F8 work on my UP Pentium III machine:
* Moved the low-level APIC enabling code out of APIC_init_uniprocessor
to a separate function APIC_enable_uniprocessor (just a wrapper
around setup_local_APIC).
* In init_apic_mappings() I call APIC_enable_uniprocessor immediately
after it has been mapped; without this call, the kernel won't get any
interrupts.
* Moved setup_apic_nmi_watchdog from setup_local_APIC to
APIC_init_uniprocessor; this is because setup_apic_nmi_watchdog needs
cpu_khz, but cpu_khz hasn't been computed yet when my patch calls
setup_local_APIC. I don't know how this will affect SMP systems.
(side note: why not just make setup_apic_nmi_watchdog an __initcall?)
/Mikael
--- linux-2.4.0-test9-upapic-F8/arch/i386/kernel/apic.c.~1~ Thu Oct 5 17:12:13
2000
+++ linux-2.4.0-test9-upapic-F8/arch/i386/kernel/apic.c Thu Oct 5 20:45:12 2000
@@ -32,6 +32,8 @@
int prof_old_multiplier[NR_CPUS] = { 1, };
int prof_counter[NR_CPUS] = { 1, };
+static void APIC_enable_uniprocessor(void);
+
int get_maxlvt(void)
{
unsigned int v, ver, maxlvt;
@@ -315,9 +317,6 @@
* Must be "all ones" explicitly for 82489DX.
*/
apic_write_around(APIC_DFR, 0x);
-
- if (nmi_watchdog == NMI_LOCAL_APIC)
- setup_apic_nmi_watchdog();
}
/*
@@ -398,6 +397,8 @@
set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
Dprintk("mapped APIC to %08lx (%08lx)\n", APIC_BASE, apic_phys);
+ APIC_enable_uniprocessor();
+
/*
* Fetch the APIC ID of the BSP in case we have a
* default configuration (or the MP table is broken).
@@ -826,10 +827,10 @@
}
/*
- * This initializes the IO-APIC and APIC hardware if this is
- * a UP kernel.
+ * Enable the BSP's local APIC.
+ * Note: interrupts are not yet enabled and cpu_khz is not yet known.
*/
-void __init APIC_init_uniprocessor (void)
+static void __init APIC_enable_uniprocessor (void)
{
if (!cpu_has_apic)
return;
@@ -840,9 +841,21 @@
apic_write_around(APIC_ID, 0);
setup_local_APIC();
+}
- if (nmi_watchdog == NMI_LOCAL_APIC)
+/*
+ * This initializes the IO-APIC and APIC hardware if this is
+ * a UP kernel.
+ */
+void __init APIC_init_uniprocessor (void)
+{
+ if (!cpu_has_apic)
+ return;
+
+ if (nmi_watchdog == NMI_LOCAL_APIC) {
+ setup_apic_nmi_watchdog();
check_nmi_watchdog();
+ }
#ifdef CONFIG_X86_IO_APIC
if (smp_found_config)
setup_IO_APIC();
-
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/
Status Update for Linux 2.4 Status/TODO
Ted, .. .. 4. Boot Time Failures .. Boot hangs on a range of Dell docking stations (Latitude) Almost certainly related: PCI code doesn't see devices behind DECchip 21150 PCI bridges (used in Dell Latitude). Reported by Simon Trimmer . (Patch from Martin Mares exists but it disables cardbus devices, according to Tigran.) Derek Fawcus at Cisco reports similar problems with Toshiba Tecra 8000 attached to the DeskStation V+ docking station. (once again, caused by bridge returning 0 when reading the I/O base/limit and Memory base/limit registers which confuses the new PCI resource code). == I am the one who reported the "Boot hangs on a range of Dell docking stations (Latitude)". test9 has fixed this problem. Thanks to whoever saved me the time to poke into this. I do have a feeling this fixes other reported problems above; maybe people can test. This seems more related to second order PCI busses rather than DECchip 21150 PCI bridges. some details for my case: -- 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) ## 00.01:0 is a bridge from 00 to 01-01 00:03.0 CardBus bridge: Texas Instruments PCI1225 (rev 01) ## 00.03:0 is a bridge from 00 to 03-06 00:03.1 CardBus bridge: Texas Instruments PCI1225 (rev 01) ## 00.03:1 is a bridge from 00 to 07-0a 00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) ## 00.11:0 is a bridge from 00 to 02-02 01:00.0 VGA compatible controller: Neomagic Corporation NM2360 [MagicMedia 256ZX] 01:00.1 Multimedia audio controller: Neomagic Corporation NM2360 [MagicMedia 256ZX Audio] 02:01.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] 02:05.0 IDE interface: CMD Technology Inc PCI0646 (rev 03) 02:07.0 SCSI storage controller: Adaptec AIC-7860 (rev 03) 02:08.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] Having said all that, another problem still needs to be resolved, but i think that deserves another posting. Summary is: test9 boots fine. cheers, jamal - 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/
test9 PCI resource collisions
I have attached a few details of what appears to be a PCI resource alloc problem (IO ports from the look of it). Note: This is on a dell lattitude machine that never booted before with a docked setup. Enjoy! cheers, jamal pci.list.gz
Tux 2 patents
Hi, I remember when at the University of Cambridge (in England) about 25 years ago seeing some work then about the Jackdaw (or was is Jackard) database system that had the great feature of being immune to OS crashes, it used a phased update mechanism where new blocks were written to disk and the last block written was the one that contained the switched pointer, until this last block had been written the changes had not been made. Since the write of a disk block was atomic the database would never be corrupt. If someone wants I think that I still have a (paper) copy of the report describing this. I can send/fax a copy if wanted. I don't subscribe to this list, so please reply direct if someone wants it. (Please don't request a copy just out of curiosity since I don't want to have to post/fax copies that won't help resolve this case by showing prior art.) Cheers -- Alain Williams - 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: Integrating Andre IDE patch into 2.2.18/19 kernel
On Wed, 4 Oct 2000, Jeff Nguyen wrote: >Hi Alan. > >I hope you will consider to integrate Andre IDE patche into the 2.2.18 or >2.2.19 kernel. Be advised that the big IDE patch for 2.2 (at least as of a month ago) contains a backport of the 2.4 ide-tape driver. That driver is BROKEN -- if the last data written doesn't make up a full block, then the driver won't be able to read back ANY part of the last block. The current 2.2.17 ide-tape driver gets this right (you get the data padded with zeroes to a full block). I reported this to LKML and the ide-tape maintainer a month ago, but he hasn't replied so I can only assume he's off-line or doesn't care. /Mikael - 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: usb-audio, does it work at all?
On Thu, Oct 05, 2000 at 11:46:13AM -0700, Dunlap, Randy wrote: > usb audio will be made to work again, but it's > currently broken 2 ways: usb-uhci was just broken > in 2.4.0-test9. Oh? It works perfectly well with my Wacom Graphire. > Besides that, the audio driver > has been broken since 2.4.0-test7 or so. > It worked in 2.4.0-test5 but not in -test7. > I've been searching for the problem but haven't > found it yet. Hmm, yes, that's a difficult one. I just made a diff between test5 and test9, and there are no obvious changes in the audio driver. Except the changes in copy_from_user_ret() and mem_map_reserve(). Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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: hdparm settings: Can they be permanent?
On Thu, 5 Oct 2000, Harald Welte wrote: >> It was suggested to me that the way to make hdparm settings permanent was >> to create a script to change the settings on startup. Is this the best >> choice? > >Yes, indeed. It is the same for all kernel configurable parameters. Look >at /proc/sys/net/ipv4/ip_forward, etc. Not really. Red Hat ships with "sysctl" which runs at boot time and has a config file in /etc which stores settings for /proc/sys/whatever. So you don't have to write a script if you use the sysctl package. >Some distributions already have the hdparm initscript. I'm not sure about that one for RH.. I use my own script, but there might be one now.. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Need general help or technical support with Red Hat Linux 6.2? Join the user support mailing list by sending a message to "[EMAIL PROTECTED]" with the word "subscribe" on the subject line. - 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: usb-audio, does it work at all?
> From: Erik Mouw [mailto:[EMAIL PROTECTED]] > > On Thu, Oct 05, 2000 at 11:46:13AM -0700, Dunlap, Randy wrote: > > usb audio will be made to work again, but it's > > currently broken 2 ways: usb-uhci was just broken > > in 2.4.0-test9. > > Oh? It works perfectly well with my Wacom Graphire. So you are one of the lucky ones. :) > > Besides that, the audio driver > > has been broken since 2.4.0-test7 or so. > > It worked in 2.4.0-test5 but not in -test7. > > I've been searching for the problem but haven't > > found it yet. > > Hmm, yes, that's a difficult one. I just made a diff between test5 and > test9, and there are no obvious changes in the audio driver. Except > the changes in copy_from_user_ret() and mem_map_reserve(). Could have been some changes outside of audio.c that kill it. In any case, it just hangs the system in 2.4.0-test7 or later. ~Randy - 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: 2.2.x NFS service causing routing/networking failures?
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Okay, twice this evening I've seen my 2.2.16-kernel based i586 (K6-2) > > machine become ignorant of the utility of eth0. Both times I'd been > > playing mp3 audio on another linux box from an NFS volume served by > > the machine that went nuts. > > Let me guess - eth0 is a tulip card? Try a different driver. There are > three in the kernel sources - de4x5, tulip and old_tulip. > > You're probably using 'tulip'. Switch to 'old_tulip'. Hello, I'm using a realtek 8029 (ne2k-pci) that sometimes hungs, it stops working, nothing in the logs, no more interrupts, no respond to either ip or arp. ifdown & ifup don't solve it, neither rmmod insmod (ne2k-pci, 8390), and BTW a 3c503 in the same machine continues to work ok (8390 based also). So, a silent drop off the net and no other solution than a reboot. > > -- > dwmw2 -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Intel 820 Chipset
Hi, Does anyone have an agpgart patch for the Intel 820 chipset? If not, I'll be happy to help if there is some dumbass work. I'm sorry I'm not smart enough to do this one myself. Thanks, John - 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] APIC, NMI watchdog support on UP systems
Ingo Molnar wrote: > the latest UP-APIC patch against 2.4.0-test9 (upapic-2.4.0-test9-F5), can > be downloaded from: > > http://www.kernel.org/pub/linux/kernel/people/mingo/apic-patches/ > > this one should work on all systems - let me know how it behaves, reports, > suggestions welcome. If any change didnt make it into this patch then > please resubmit, there were major changes. This patch still gives me a kernel that will not boot at all on my Athlon machine. After selecting the boot image from LILO I get nothing but a black screen. Miles - 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: VGER
David, [EMAIL PROTECTED] is not answering the "lists" test with a reply. The server shows to be up at 199.183.24.194, and nslookup reports: [root@vger /]# [root@vger /]# nslookup -querytype=mx vger.kernel.org Server: slkcpop1.slkc.uswest.net Address: 206.81.128.1 Non-authoritative answer: vger.kernel.org preference = 200, mail exchanger = zeus.kernel.org vger.kernel.org preference = 10, mail exchanger = vger.kernel.org Authoritative answers can be found from: kernel.org nameserver = ns1.kernel.org kernel.org nameserver = ns2.kernel.org kernel.org nameserver = ns1.transmeta.com kernel.org nameserver = ns2.transmeta.com zeus.kernel.org internet address = 209.10.41.242 vger.kernel.org internet address = 199.183.24.194 ns1.kernel.org internet address = 209.10.217.83 ns2.kernel.org internet address = 209.10.41.242 ns1.transmeta.com internet address = 209.10.41.227 ns2.transmeta.com internet address = 209.10.217.68 [root@vger /]# but majordomo appears to be hosed or something. I'll forward this to the list. It's not on this end -- I can send email everywhere else and the law firm downstairs just got in and sent tons of legal briefs all over the place (San Francisco, London, etc.). You might want to go check and see if majordomo is hung or something on an address without a valid reverse DNS or something. Thanks David, Jeff P.S. We got anaconda running now and figured out thanks to the guy you referred us to. Thanks. :-) Jeff "David S. Miller" wrote: > >Date: Thu, 05 Oct 2000 17:31:05 -0600 >From: "Jeff V. Merkey" <[EMAIL PROTECTED]> > >Is vger down right now? > > Nope. > > Later, > David S. Miller > [EMAIL PROTECTED] - 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: linux-2.4.0-test9
David S. Miller wrote:
>> These items are specifically placed into the data section, not the
>> BSS, because these alignment games are not possible in the BSS.
>
>That would mean the BSS needs support alignment games.
>
> The problem is it doesn't work, please go try it.
> So until it does work, I am going to revert this change.
Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
and it should do what you want.
Heck, section ".bss" might give you the alignment without the allocation
but I'm not as confident about that.
-- Jamie
-
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] Bonding Driver Enhancements - final
willy tarreau wrote: > > Hello Thomas ! > > ok, all the suggestions, help and doc included. I've > extended bonding.txt to explain how to proceed with > HA. > The modified ifenslave prog is also included in the > Documentation directory since many people have > difficulties getting the original and I don't receive > replies from Donald Becker about this. > Donald's email server has been down for few days, my machine was not able to send him e-mail. > It works for me on two alteon switches. I think it > can safely be included in 2.2.18 (since it also fixes > some bugs anyway). > > I attach the complete patch against 2.2.1[78] with > help, doc and ifenslave.c. > Regarding your last patch -- it does not include the documentation update (ifenslave.c compile problem is solved). I have run the tests on both UP and SMP machines for two versions of your patch: the early version patch-bonding-2.2.17.gz (defaults to MII link monitoring and does not include optimized transmit path) and the latest version I got during the time we were doing the tests -- patch-bonding-20001005.gz. TEST RESULTS. Hardware: Machine 1: IBM Tninkpad 600X with 3Com 3CCFE575BT Cyclone CardBus and 3Com Megahertz 574B PCMCIA, 128MB RAM, PIII 500MHZx256K CPU (UP kernel tested). Machine 2: Compaq Proliant 3600xx (1U rackmount version) with 2x800MHZx256K CPU, 256MB RAM and 2 on-board Intel EtherExpress PRO/100 adapters (SMP and UP kernels tested). Machine 3: IBM Thinkpad laptop with one NIC. Switches: BayStack Switches, 2 trunks were defined (trunks were defined between ports that belonged to different modules). Software: 2.2.18-pre15 + updated bonding driver + E820 memory detection + software raid + nfs v3 server + IP Virtual Server. (Software raid, nfs and IP virtual server were modularized and were not used at testing time. Thus, they are not expected to have influenced the test results). BAD RESULTS. It did not work with SMP kernel on Compaq (worked fine with UP kernel though). With the old patch, if both links were active at boot, there would be no network. If only one link was active at boot, the network was functioning until the second link was brought up. There were no error kernel messages with the old patch (the link detection worked fine and was reported even when the network was dead). With the new patch, if both links were up, the network would be functioning well for just a few seconds. As soon as packets were queued to be sent via the second NIC, the network would effectively die. The driver could never sent the packets via the second interface (ifconfig showed zero packet statistics at all times). In this case, however, I saw a lot of messages like "eth1: transmit timeout, status..." and could do some pinging with variable success. However, after bringing up and down links one-two times, such messages would stop, no pinging could be done and no change of packet stats would be observed for both NICs. With both the old and the new patch, trying to bring the second ethernet down (either manually with ifconfig or at reboot) would freeze the machine. It was not a lock-up; machine would respond to keyboard, but all commands would get stuck. Alt+CTRL+DEL would not reboot, Sysrq would not sync or unmount but could reboot. This could be a case of a Compaq that is not properly configured for Linux (I did not have access for the config CD and the machine could not be configured from the keyboard AFAIK). For what it is worth, I did run some kernel compiles with "-j8" and some massive rpm builds on the machine and it would not lock up. If not a config problem, it seems that a lock is taken somewhere which is never released. I realize I forgot to test the backup mode with the SMP kernel. No test results for that, sorry. GOOD RESULTS. Both the old and the optimized patch work fine on UP machines (Compaq and Laptop). I have really tried to stress the network (nfs, interactive ssh sessions, and several ftp transfers of ~500MB files at the same time) and check for different link loss/recovery scenarios. Link loss was always properly detected and transparent for all applications. The traffic was distributed fairly between the two bonded interfaces. I have also tested the new backup mode with the latest patch. It worked fine without exhibiting any problems. The new patch does indeed optimize the load. One of my laptop cards (PCMCIA Megahertz 574B) is a lousy performer or has a lousy driver. Normally I can't achieve more than 4-5MB/sec and the driver really stresses the CPU (the cardbus card does not have that problem). With the old bonding patch, I would see 100% CPU usage with 1 high-speed FTP session. With the new patch, I see 100% CPU usage only with 2 high-speed FTP sessions. The high usage with the latest bonding patch on this specific card is not the bonding driver problem. I have never seen high CPU usage on Compaq with
Re: poll(2) semantics changed in 2.4.0-? vs. 2.2.16?
On Thu, 5 Oct 2000, David S. Miller wrote: > Fix your /etc/nsswitch.conf to not try to use NIS/NIS+ if you > do not have these services available. Yes, of course you are right - incorrect nsswitch.conf will reveal this problem too - but: No, the issue I've tried to demonstrate with my polltest.c program is completely independent. The point is: udp-sendmsg() to an unbound port on reachable peer (localhost:12345 e.g. - will try eth0 too) results in returning icmp: port unreachable. Ok so far. The following poll() on the sending fd should IMHO immediately return POLLERR due to pending ECONNREFUSED instead of blocking until timeout - right? At least, that is the behavior described in man udp(4)/RFC1122 and realized in 2.2.16 (at least since 2.0.x I think and probably up to 2.2.18pre?, as long as there is no corresponding 2.4 backport there, I believe - not tested). It's still working this way if I add a sleep(5) or so between sendto() and poll() in 2.2. Setting or unsetting SO_BSDCOMPAT doesn't change anything either. For 2.4.0-test9 however the poll() ignores the returned (still pending) icmp error and blocks until timeout (or forever), no matter if SO_BSDCOMPAT is set or not. So, for me the 2.4.0-test9 behavior does not only differ from 2.2 and what manpages say - I'm just wondering how to detect the unreachable peer port? poll()-timeout means no response at all, which is sth different and forces blocking for some time. Nonblocking recvfrom() without poll() wouldn't help, since the pending error isn't passed to it either. Sorry if my first post wasn't clear enough wrt that what I meant - a general poll() semantics question - which indeed might be hit pretty hard by incorrect /etc/nsswitch configuration for example. Regards, Martin - 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] enabling APIC and NMI watchdog on UP systems
Philip J. Mucci wrote: > Basically, reading the counters is a 2 step process: read the mmapped > virtual counters and add that to the contents of rdpmc(). This means > that (at least for the x86 series) the kernel interface only needs to > 'guard' access to the MSR to make sure the user doesn't set up anything > pathological. This same kind of interface is also possible for the > UltraSparc. For other systems where a lower IPL is required, the > interface needs to be a fast-path syscall interface. That sounds similar to the vsyscall interface Ingo's been working on. Why not use the read-only kernel page used for fast gettimeofday() calibration with MSR offsets? It's slightly more overhead than inlining the code, but it is still only a small overhead (no kernel entry, just a function call to code in a user-readable page). People doing advanced dynamic compilation techniques can always trace the vsyscall code and inline equivalent code directly into their hot paths ;-) -- Jamie - 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/
ack number in a connection-refused RST
Usually, when I try to connect to a port with nothing listening on it, it looks like this: 17:11:20.809712 eth0 > MYHOST.2514 > OTHERHOST.auth: S 2807001202:2807001202(0) win 32120 (DF) 17:11:20.819712 eth0 < OTHERHOST.auth > MYHOST.2514: R 0:0(0) ack 2807001203 win 0 MYHOST is my Linux box. The OTHERHOST can be almost anything. The ECONNREFUSED error comes immediately on receipt of the RST packet. Just as it should be. But I've found one host, BADHOST, which times out instead of giving ECONNREFUSED. And at first I couldn't figure out why, since it too sends a RST packet: 17:11:23.599564 eth0 > MYHOST.2515 > BADHOST.auth: S 2805193937:2805193937(0) win 32120 (DF) 17:11:23.719558 eth0 < BADHOST.auth > MYHOST.2515: R 0:0(0) ack 2805193937 win 0 Then I looked at the sequence numbers. In OTHERHOST's RST packet, the ack number was 1 higher than the sequence number in the SYN packet. in BADHOST's RST packet, the ack number is the *same* as the sequence number in the SYN packet. Questions: 1. Could/should the Linux kernel be patched to recognize the one-off sequence number and return ECONNREFUSED? 2. If the BADHOST behavior is incorrect, can a TCP expert please explain exactly why, so a bug report can be filed... 3. Does anybody know where to file a bug report on the Sega Dreamcast TCP? - 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: The case for a standard kernel debugger
[EMAIL PROTECTED] wrote: > One big argument against RAS of any sort is that it bloats the kernel and > not every one wants it (until they have a problem). A further argument with > Linux is that you may have to do quite a bit of hard work to get the subset > of RAS you need to co-exist, if it exists at all. Something we're working > on which may help resolve this, and will be made available with the next > drop of Dynamic Probes is Generalised Kernel Hooks Interface (GKHI). The > idea here is to make all our RAS function the option of being dynamically > loadable kernel modules. In most cases we don't need to modify kernel > function, just get control at the right time. So we place hooks in kernel > source, which remain dormant until activated by the GKHI when a RAS module > asks it to. Maybe this will provide a way out of the difficulty. Sorry for catching this a bit late, but I would like to point out that there already is a generalized kernel hooks interface, that does exactly what is described above, as part of the Linux Trace Toolkit. The hooks inserted in the kernel source don't modify the kernel's behavior, though they can trigger callback functions. To hook onto an event, the following function is used: int trace_register_callback(tracer_call pmTraceFunction, uint8_t pmEventID) Once this is called, the occurrence of the given event will generate a call to the given callback function. Hence the inserted hooks are dormant until used. On top of this callback interface, I am currently in the process of completing a state machine engine that would enable it's user to specify event driven state machines. What does this mean? Well, as Alan had suggested, this could be used to test a driver's actual behavior with the state-machine that models it's theoretical behavior. Furthermore, and I think this is a field open with a lot of very interesting opportunities, state machines could be developed that model intrusions and attacks. Hence, the state machine engine could be used as the basis of a very powerful intrusion detection system. The basic example of this is stack overflows. A lot of very cleaver schemes have been developed in order to detect these types of hacks. Yet, with a state-machine that models the types of attacks being conducted, it wouldn't matter which stack overflowed or who did what since the state machine would catch any unauthorized event sequence and, possibly, kill the culprit process, suspend it or warn the sysadmin. That said, I do think that dynamically inserted probes are useful. As Richard has pointed out, there are situations where this makes a big difference. In a sense, Dprobes could use the architecture already put forward by LTT to log custom events in a system trace and could use the trace hooking mechanism already available to implement whatever RAS function comes on top. For a full discussion on the performance and architecture issues regarding LTT, I invite the interested reader to take a look at the paper I presented last June at the annual Usenix technical conference: http://www.opersys.com/LTT/ltt-usenix.ps.gz And LTT can be found at: http://www.opersys.com/LTT/ Cheers === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === - 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: Why does everyone hate gcc 2.95?
Alexander Viro wrote: > ITYM "cute". As in "cute dancing paperclip". As colourized ls. Hey, colour ls is _useful_! > Or --ignore-fail-on-non-empty as rmdir option. Or "let's replace config > files with directories full of one-liners since packagers can't be arsed > to learn sed(1)" religion. Sigh... No, that's because (a) if 99% of packagers use sed in the right way and one makes a mistake, all the packages are broken; (b) no package manager I know of lets you mark a file as belonging to a package (e.g. inetd.conf to inetd) while doing a sed-like update of the skeleton part of the file, but keeping the changes from other packages. Now for an example which does it nicely, see GNU Info, `install-info' :-) -- Jamie - 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/
locking user memory
Hi, My driver needs to do a large DMA in the user address. Is there a way i can ensure the user buffer is not swapped out, while i am doing the IO. Please CC your mail to [EMAIL PROTECTED] TIA - 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: Compiling and linking with -gdwarf enable
Ralph Blach wrote:
>
> I am working with the monta-vista port of linux to the 405gp.
>
> arch/ppc/mm/4xx_tlb.o: In function `findPTE':
> /u/rcblach/405/2.4.0-test2/arch/ppc/mm/4xx_tlb.c:507: undefined
> reference to `pgd_none'
> /u/rcblach/405/2.4.0-test2/arch/ppc/mm/4xx_tlb.c:507: relocation
> truncated to fit: R_PPC_REL24 pgd_none
> Can the linux kernel be compiled with debug information in any of its
> modules? Is there a way to do this?
> Or is the kernel just fundementally designed not to be compiled with
> debug info in it.
Ralph;
In general enabling debugging in the kernel source is not a problem.
The specific problem is with the 405 code. What was the date you got
the kernel from MontaVista? i.e /ppc-405gp/files_{date}/
the latest was posted Sept 9th and you can get is @
ftp.mvista.com/pub/Area51/ppc-405gp/files_00.09.09/
Armin
-
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: v2.4.0test9 NFSv3 server woes Linux-->Solaris
On Thu, Oct 05, 2000 at 09:27:56PM +0200, Trond Myklebust wrote: > > " " == David Weinehall <[EMAIL PROTECTED]> writes: > > > Oh, by the way, is there ANY sane reason whatsoever behind the > > decision that the Linux NFSv3 client in the v2.2.18pre15 kernel > > defaults to wsize = rsize = 1kB and the NFSv3 client in > > v2.4.0test9 defaults to wsize = rsize = 4kB?! Every (?) other > > implementation of NFSv3 defaults to 32kB... At least when > > mounting Solaris NFSv3 server --> Linux NFSv3 client, 32kB > > rsize & wsize works perfectly fine (at least for v2.2.18pre15, > > but I hope that v2.4.0test9 isn't worse in this regard.) > > 2.4.0-pre9 should default to rsize/wsize == whatever Solaris asks for > (32k in practice). It does on my setup... I'm talking about the client, not the server. Thus, it's the Linux machine that makes the request, not the Solaris machine. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: Status of ReiserFS + Journalling
On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote: > A power failure might leave you with a corrupt disk block. That is > detectable (read failure) and you may then reconstruct it using the > rest of the stripe. This will get you data from either before > or after the update was supposed to happen. How would you be able to tell which disk contains the bad stripe? RAID reconstruction relies on knowing which disk to reconstruct because it's obviously bad - there's out of band information in the form of I/O errors. If you only have an incompletely updated stripe on a disk, you don't know which data to reconstruct from parity. I think the only way of doing this properly is to either have battery-backed cache, or by having journalling at the RAID level. J PGP signature
Re: Majordomo Problems?
On Thu, 5 Oct 2000, Matti Aarnio wrote: > The list has been experiencing loop via somebody. > The likely suspect is now deleted from the list, and > it remains to be seen if that helped. from a looping message: > X-Mailing-List: [EMAIL PROTECTED] > X-Mailing-List: [EMAIL PROTECTED] > X-Mailing-List: [EMAIL PROTECTED] > X-Mailing-List: [EMAIL PROTECTED] > Sender: [EMAIL PROTECTED] > Precedence: bulk > X-Mailing-List: [EMAIL PROTECTED] Apparently Majordomo does not have loop detection, or it's defective. Eric - 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: NGROUPS_MAX
On Wed, Oct 04, 2000 at 09:39:11AM +1300, Craig Whitmore wrote: > I need to set up a server with a user that is in more than 32 groups at a time > and as far as I know NGROUPS_MAX in limits.h changes this maximum. > If I increase (say to 256) this will this break anything or will linux work perfectly > well? It's almost time for a FAQ. For RH 6.1 which uses glibc-2.1.2 you need to take the following steps: 1) modify the kernel headers glibc uses (separately installed on RH6.1) linux/include/linux/limits.h: change NGROUPS_MAX linux/include/asm-i386/param.h: change NGROUPS accordingly 2) recompile glibc 3) install/upgrade it. When you have users in >16 groups working on an NFS client this will break: the RPC protocol passes only the first 16 groups to the server. I've various NFS client side patches to eliminate this problem (2.2.x, 2.4.0-test*, see also http://www.inter.nl.net/users/fvm/nfs-ngroups) I've set NGROUPS_MAX to 256, no problems. -- Frank - 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: Majordomo Problems?
++ 05/10/00 21:17 +0200 - Torben Mathiasen: > I have the same problems, thought it was because my resubscription went > wrong. Sorry, I caused this problem. The repeated messages were send out by a mail processing script I've actually been using for quite some time, but demonstrated to contain some 'hidden features' when confronted with LK-mail. Sorry for the inconvenience, everybody. It won't happen again. I promise! :) Frank van Viegen [EMAIL PROTECTED] - 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: poll(2) semantics changed in 2.4.0-? vs. 2.2.16?
Fix your /etc/nsswitch.conf to not try to use NIS/NIS+ if you do not have these services available. Later, David S. Miller [EMAIL PROTECTED] - 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/
failure to burn CDs under 2.4.0-test9
Comparing CD contents with the original after burning showed mismatches 4 times in a row. Booted into linux 2.2.18 and everything is fine. Together with the events of freezing in pine I would suggest that there is something in the kernel scribbling memory. I am back to 2.2 for good for now. - 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: 2.2.x NFS service causing routing/networking failures?
The card is a DLink DFE 530TX: via-rhine.c:v1.01 2/27/99 Written by Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html eth0: VIA VT3043 Rhine at 0xe000, 00:50:ba:a5:5f:e6, IRQ 5. eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link 40a1. PCI latency timer (CFLT) is unreasonably low at 32. Setting to 64 clocks. I see there is a newer version (1.08) although the 2.2.16 source RPM includes the version above. Is the newer one worth trying? I had no difficulties copying 6-7GB of data ON to the machine via NFS but "playing" the data from another machine with xmms seemingly caused me problems both times. I've never seen this behavior before or anything like it on this machine (which has always been very docile and stable). -joseph On 5 Oct, David Woodhouse wrote: > > [EMAIL PROTECTED] said: >> Okay, twice this evening I've seen my 2.2.16-kernel based i586 (K6-2) >> machine become ignorant of the utility of eth0. Both times I'd been >> playing mp3 audio on another linux box from an NFS volume served by >> the machine that went nuts. > > Let me guess - eth0 is a tulip card? Try a different driver. There are > three in the kernel sources - de4x5, tulip and old_tulip. > > You're probably using 'tulip'. Switch to 'old_tulip'. > - 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/
No Subject
I'm still trying to read physical sectors, and have made progress. Thanks
for the pointers on set_blocksize(), that seems to do the trick.
However, now I've got another problem. When I read blocks "too quickly", I
guess the elevator algorithm in ll_rw_block() kicks in and re-organizes my
buffer_head structures?
ReadLBA(2) - OK
ReadLBA(3) - OK
ReadLBA(4) - fails, kernel dereferences NULL,
All calls to getblk() succeed, and none of my buffer heads are NULL. I pass
this array to ll_rw_block(), which rewrites my array, leaving most of my
buffer_head pointers as NULL. So, I thought, that for each buffer head that
isn't NULL, maybe my next buffer head is in b_reqnext, but nope. It's NULL
too.
oops and my function are below. FWIW, this is the second version of my
function. Originally, I just looped, calling bread(dev, lba++, blocksize),
which oops in the same way. Both IA-32 and IA-64, kernel 2.4.0-test9.
TIA for your help.
-Matt
Unable to handle kernel NULL pointer dereference at virtual address
*pde = 37b11001
Oops:
CPU:0
EIP:0010:[<>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: c211dba0 ecx: edx: c029bfa8
esi: edi: 0001 ebp: 001f esp: c029bf60
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c029b000)
Stack: c010d4c0 001f c029bfa8 c029bfa8 c02d8be0 001f
c211dba0
c010d6c1 001f c029bfa8 c211dba0 c029a000 c0109bf0
c029a000
e000 c010bbf8 c029a000 c029a000 c0109bf0 c029a000
e000
Call Trace: [] [] [] [] []
[] []
[] [] []
Code: Bad EIP value.
>>EIP; Before first symbol
Trace; c010d4c0
Trace; c010d6c1
Trace; c0109bf0
Trace; c010bbf8
Trace; c0109bf0
Trace; c0100018
Trace; c0109c1e
Trace; c0109ca2
Trace; c0105000
Trace; c01001d0
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
struct buffer_head ** my_bread(kdev_t dev, u64 lba, u64 blockstoread)
{
struct buffer_head **bh, *thisbh;
unsigned int blocksize = get_hardblocksize(dev);
unsigned int i;
if (!blocksize) blocksize = 512;
printk(KERN_INFO "about to getblk %d blocks\n", blockstoread);
bh = kmalloc(GFP_KERNEL, blockstoread * sizeof(struct buffer_head *));
if (!bh) return NULL;
for (i=0; ib_reqnext ==
NULL */
/* Walk the chain */
for (i=0; ib_reqnext;
if (thisbh) printk(KERN_INFO "my_bread walking the chain...\n");
} while (thisbh);
}
return bh;
}
-
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: Majordomo is sick
>From the header, looks like several folks are responsible. Jeff Gerhard Mack wrote: > > It's not majodomo. It's somone who is subscribed to the list bouncing > things back. Could be a broken mail to news gateway or some other mis > scripted feature. Read the mail headers and you can see fairly quickly who > is responsable. > > Gerhard > > On Thu, 5 Oct 2000, Jeff V. Merkey wrote: > > > > > > > [EMAIL PROTECTED] is sick and is sending messages in a circle. > > Better check the /etc/aliases file and make sure a record isn't pointing > > somewhere it should not. > > > > Jeff > > > > [Fwd: Returned mail: Too many hops 29 (25 max): from > > <[EMAIL PROTECTED]> via vger.kernel.org, to > > <[EMAIL PROTECTED]>] > > -- > Gerhard Mack > > [EMAIL PROTECTED] > > <>< As a computer I find your faith in technology amusing. - 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/
Majordomo is sick
[EMAIL PROTECTED] is sick and is sending messages in a circle. Better check the /etc/aliases file and make sure a record isn't pointing somewhere it should not. Jeff [Fwd: Returned mail: Too many hops 29 (25 max): from <[EMAIL PROTECTED]> via vger.kernel.org, to <[EMAIL PROTECTED]>] The original message was received at Thu, 5 Oct 2000 12:33:57 -0600 from vger.kernel.org [199.183.24.194] - The following addresses had permanent fatal errors - <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - Transcript of session follows - 554 Too many hops 29 (25 max): from <[EMAIL PROTECTED]> via vger.kernel.org, to <[EMAIL PROTECTED]> Reporting-MTA: dns; vger.timpanogas.org Received-From-MTA: DNS; vger.kernel.org Arrival-Date: Thu, 5 Oct 2000 12:33:57 -0600 Original-Recipient: rfc822;[EMAIL PROTECTED] Final-Recipient: RFC822; <[EMAIL PROTECTED]> Action: failed Status: 5.4.6 Last-Attempt-Date: Thu, 5 Oct 2000 12:33:58 -0600 Original-Recipient: rfc822;[EMAIL PROTECTED] Final-Recipient: RFC822; <[EMAIL PROTECTED]> Action: failed Status: 5.0.0 Last-Attempt-Date: Thu, 5 Oct 2000 12:33:58 -0600 Return-Path: <[EMAIL PROTECTED]> Received: from vger.kernel.org (vger.kernel.org [199.183.24.194]) by vger.timpanogas.org (8.9.3/8.9.3) with ESMTP id MAA06225; Thu, 5 Oct 2000 12:33:57 -0600 Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand id ; Thu, 5 Oct 2000 14:49:03 -0400 Received: ([EMAIL PROTECTED]) by vger.kernel.org id ; Thu, 5 Oct 2000 14:48:54 -0400 Received: from cam035106.student.utwente.nl ([130.89.226.36]:60430 "EHLO jaqr.student.utwente.nl") by vger.kernel.org with ESMTP id ; Thu, 5 Oct 2000 14:48:43 -0400 Received: (from daemon@localhost) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) id e95IXf714047; Thu, 5 Oct 2000 20:33:41 +0200 Received: from freewww1.domainvalet.com (freewww1.domainvalet.com [216.122.66.78]) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id e95IXem14044 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 20:33:40 +0200 Received: from vger.kernel.org (vger.kernel.org [199.183.24.194]) by freewww1.domainvalet.com (8.9.3/8.9.3) with ESMTP id KAA08234 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 10:40:45 -0700 Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand id ; Thu, 5 Oct 2000 14:46:13 -0400 Received: ([EMAIL PROTECTED]) by vger.kernel.org id ; Thu, 5 Oct 2000 14:46:03 -0400 Received: from cam035106.student.utwente.nl ([130.89.226.36]:58638 "EHLO jaqr.student.utwente.nl") by vger.kernel.org with ESMTP id ; Thu, 5 Oct 2000 14:45:52 -0400 Received: (from daemon@localhost) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) id e95IUoc13944; Thu, 5 Oct 2000 20:30:50 +0200 Received: from freewww1.domainvalet.com (freewww1.domainvalet.com [216.122.66.78]) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id e95IUnm13940 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 20:30:49 +0200 Received: from vger.kernel.org (vger.kernel.org [199.183.24.194]) by freewww1.domainvalet.com (8.9.3/8.9.3) with ESMTP id KAA08063 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 10:37:53 -0700 Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand id ; Thu, 5 Oct 2000 14:44:12 -0400 Received: ([EMAIL PROTECTED]) by vger.kernel.org id ; Thu, 5 Oct 2000 14:44:02 -0400 Received: from cam035106.student.utwente.nl ([130.89.226.36]:53774 "EHLO jaqr.student.utwente.nl") by vger.kernel.org with ESMTP id ; Thu, 5 Oct 2000 14:43:45 -0400 Received: (from daemon@localhost) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) id e95ISiS13901; Thu, 5 Oct 2000 20:28:44 +0200 Received: from freewww1.domainvalet.com (freewww1.domainvalet.com [216.122.66.78]) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id e95IShm13898 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 20:28:43 +0200 Received: from vger.kernel.org (vger.kernel.org [199.183.24.194]) by freewww1.domainvalet.com (8.9.3/8.9.3) with ESMTP id KAA07943 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 10:35:47 -0700 Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand id ; Thu, 5 Oct 2000 14:41:52 -0400 Received: ([EMAIL PROTECTED]) by vger.kernel.org id ; Thu, 5 Oct 2000 14:41:42 -0400 Received: from cam035106.student.utwente.nl ([130.89.226.36]:51982 "EHLO jaqr.student.utwente.nl") by vger.kernel.org with ESMTP id ; Thu, 5 Oct 2000 14:41:31 -0400 Received: (from daemon@localhost) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) id e95IQT913829; Thu, 5 Oct 2000 20:26:29 +0200 Received: from freewww1.domainvalet.com (freewww1.domainvalet.com [216.122.66.78]) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id e95IQSm13825 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 20:26:28 +0200 Received: from vger.kernel.org (vger.kernel.org [199.183.24.194]) by freewww1.domainvalet.com (8.9.3/8.9.3) with ESMTP id KAA07854 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 10:33:32 -0700 Received: ([EMAIL PROTECTED]) by
svc: unknown program 100227 (me 100003)
Hi folks, Maybe a stupid question, but it would be nice to know what this message means: fright kernel: svc: unknown program 100227 (me 13) 'fright' is the name of the machine in question (2.4.0-test6, x86). I get this about 40 times per day. Many thanx Harri - 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: Majordomo Problems?
On Thu, Oct 05, 2000 at 09:17:14PM +0200, Torben Mathiasen wrote: > On Thu, Oct 05 2000, Post, Mark K wrote: > > I don't know if anyone else is seeing this, but I'm getting multiple copies > > of a lot of the emails to this list. For some, it's two copies, for others > > it is up to four copies. Am I the only one seeing this? > > I have the same problems, thought it was because my resubscription went > wrong. The list has been experiencing loop via somebody. The likely suspect is now deleted from the list, and it remains to be seen if that helped. > -- > Torben Mathiasen <[EMAIL PROTECTED]> /Matti Aarnio - 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: 2.0/2.2 Bug: SIGTRAP lost
Victor Zandy <[EMAIL PROTECTED]> writes: > If a process executes an int3 (breakpoint) instruction while > another process is attaching to it, the SIGTRAP can be lost. This bug > is present in 2.4.0-test8 and 2.2.14. Uh, this turns out to be my stupid programming error, not a bug in any of the fine versions of the Linux kernel. My apologies to anyone who invested time looking at this. Vic Zandy - 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: GET_USE_COUNT(THIS_MODULE) and i810_rng driver.
On Thu, 5 Oct 2000, Tigran Aivazian wrote:
> I tried to compile Jeff's i810_rng driver statically and I can't because
> of a construct like this:
>
> if (GET_USE_COUNT(THIS_MODULE) > 0)
> MOD_DEC_USE_COUNT;
> if (GET_USE_COUNT(THIS_MODULE) == 0)
> rng_hw_enabled = 0;
>
> A similar thing is used by other drivers but always inside #ifdef
> MODULE. The problem here is that if MODULE is not defined then THIS_MODULE
> is just NULL and GET_USE_COUNT(NULL) is not a very wise thing to be used
> in expressions :)
>
> Any ideas what should one do? To enclose the driver's code inside #ifdef
> MODULE (and check all other drivers) or to provide a magic version of
> GET_USE_COUNT() that will be suitable for static case? E.g. 1? Is 1 good
> enough?
FWIW, i810_rng -used- to use an internal variable for 'use_count', and
maintained MOD_{INC,DEC}_USE_COUNT off of that. I decided to get clever
and do the above, thinking that module.h was completely ok for the
non-modular case.
GET_USE_COUNT breaks the build on Alpha (hence the #ifdef). Further,
for this driver at least, it depends on a -working- module count for
all cases, returning 1 would not be sufficient.
prumpf has since sent me a fix patch which goes back to manually
maintaining the use_count for the static case, and that is the solution
I'm going with...
Jeff
-
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: kmem_grow
Hello, > Pardon my ignorance, but: > > Can anyone point me to a quick explaination of what > kmem_grow: Called nonatomically from int - size-64 > means or what to look for when you see something like this? > > I'm guessing size-64 is from the slab allocator... so kmalloc() or > something is being called incorrectly somewhere > > I'll read the fine manual or the appropriate source if someone will > point it out to me... > Yup, somebody's allocating very small bits of memory from an interrupt. You're probably using a buggy driver or kernel module.. The size is small enough it probably wouldn't trip up and cause a panic blocking waiting for more memory, but that's because you've been lucky so far.. -- Eric Lowe FibreChannel Software Engineer, Systran Corporation [EMAIL PROTECTED] - 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/
GET_USE_COUNT(THIS_MODULE) and i810_rng driver.
Hi Keith, I tried to compile Jeff's i810_rng driver statically and I can't because of a construct like this: if (GET_USE_COUNT(THIS_MODULE) > 0) MOD_DEC_USE_COUNT; if (GET_USE_COUNT(THIS_MODULE) == 0) rng_hw_enabled = 0; A similar thing is used by other drivers but always inside #ifdef MODULE. The problem here is that if MODULE is not defined then THIS_MODULE is just NULL and GET_USE_COUNT(NULL) is not a very wise thing to be used in expressions :) Any ideas what should one do? To enclose the driver's code inside #ifdef MODULE (and check all other drivers) or to provide a magic version of GET_USE_COUNT() that will be suitable for static case? E.g. 1? Is 1 good enough? Regards, Tigran - 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: v2.4.0test9 NFSv3 server woes Linux-->Solaris
> " " == David Weinehall <[EMAIL PROTECTED]> writes: > Oh, by the way, is there ANY sane reason whatsoever behind the > decision that the Linux NFSv3 client in the v2.2.18pre15 kernel > defaults to wsize = rsize = 1kB and the NFSv3 client in > v2.4.0test9 defaults to wsize = rsize = 4kB?! Every (?) other > implementation of NFSv3 defaults to 32kB... At least when > mounting Solaris NFSv3 server --> Linux NFSv3 client, 32kB > rsize & wsize works perfectly fine (at least for v2.2.18pre15, > but I hope that v2.4.0test9 isn't worse in this regard.) 2.4.0-pre9 should default to rsize/wsize == whatever Solaris asks for (32k in practice). It does on my setup... Cheers, Trond - 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] initdata and bss
On Thu, 5 Oct 2000, Roman Zippel wrote: > Hi, > > A few bss changes (to remove zero initialization) in test9 were not > completly correct. Init data must be initialized if you want that it gets > into the init section (it's also mentioned in the gcc documentation). > The following patch fixes what I was able to find with grep and also adds > a note about in init.h. Linus, I checked -- none of these are from my patch. I do actually check by compiling and gcc emits a warning when sees uninitialised __initdata items. Why do I say this? Because I am now in the process of compiling a "yes | make config" kernel in order to run Keith's data->bss perl script and get rid of all the remaining ones... :) Regards, Tigran - 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: Majordomo Problems?
On Thu, Oct 05 2000, Post, Mark K wrote: > I don't know if anyone else is seeing this, but I'm getting multiple copies > of > a lot of the emails to this list. For some, it's two copies, for others it > is up > to four copies. Am I the only one seeing this? > I have the same problems, thought it was because my resubscription went wrong. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - 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/
[PATCH] initdata and bss
Hi,
A few bss changes (to remove zero initialization) in test9 were not
completly correct. Init data must be initialized if you want that it gets
into the init section (it's also mentioned in the gcc documentation).
The following patch fixes what I was able to find with grep and also adds
a note about in init.h.
bye, Roman
diff -ur linux-2.4.org/arch/arm/mm/init.c linux-2.4-initdata/arch/arm/mm/init.c
--- linux-2.4.org/arch/arm/mm/init.cThu Oct 5 19:35:19 2000
+++ linux-2.4-initdata/arch/arm/mm/init.c Thu Oct 5 20:22:00 2000
@@ -56,7 +56,7 @@
* The sole use of this is to pass memory configuration
* data from paging_init to mem_init.
*/
-static struct meminfo __initdata meminfo;
+static struct meminfo meminfo __initdata = { 0, };
/*
* empty_bad_page is the page that is used for page faults when
diff -ur linux-2.4.org/arch/ia64/kernel/smp.c linux-2.4-initdata/arch/ia64/kernel/smp.c
--- linux-2.4.org/arch/ia64/kernel/smp.cThu Aug 24 19:30:52 2000
+++ linux-2.4-initdata/arch/ia64/kernel/smp.c Thu Oct 5 20:23:31 2000
@@ -49,8 +49,8 @@
spinlock_t kernel_flag = SPIN_LOCK_UNLOCKED;
-struct smp_boot_data __initdata smp;
-char __initdata no_int_routing = 0;
+struct smp_boot_data smp __initdata = { 0, };
+char no_int_routing __initdata = 0;
unsigned char smp_int_redirect;/* are INT and IPI
redirectable by the chipset? */
volatile int __cpu_number_map[NR_CPUS] = { -1, };/* SAPIC ID -> Logical ID */
diff -ur linux-2.4.org/arch/m68k/kernel/setup.c
linux-2.4-initdata/arch/m68k/kernel/setup.c
--- linux-2.4.org/arch/m68k/kernel/setup.c Wed Jul 5 01:04:12 2000
+++ linux-2.4-initdata/arch/m68k/kernel/setup.c Thu Oct 5 20:20:01 2000
@@ -68,13 +68,13 @@
char m68k_debug_device[6] = "";
-void (*mach_sched_init) (void (*handler)(int, void *, struct pt_regs *)) __initdata;
+void (*mach_sched_init) (void (*handler)(int, void *, struct pt_regs *)) __initdata =
+NULL;
/* machine dependent keyboard functions */
-int (*mach_keyb_init) (void) __initdata;
+int (*mach_keyb_init) (void) __initdata = NULL;
int (*mach_kbdrate) (struct kbd_repeat *) = NULL;
void (*mach_kbd_leds) (unsigned int) = NULL;
/* machine dependent irq functions */
-void (*mach_init_IRQ) (void) __initdata;
+void (*mach_init_IRQ) (void) __initdata = NULL;
void (*(*mach_default_handler)[]) (int, void *, struct pt_regs *) = NULL;
void (*mach_get_model) (char *model) = NULL;
int (*mach_get_hardware_list) (char *buffer) = NULL;
diff -ur linux-2.4.org/arch/ppc/kernel/apus_setup.c
linux-2.4-initdata/arch/ppc/kernel/apus_setup.c
--- linux-2.4.org/arch/ppc/kernel/apus_setup.c Thu Oct 5 19:35:21 2000
+++ linux-2.4-initdata/arch/ppc/kernel/apus_setup.c Thu Oct 5 20:19:41 2000
@@ -82,13 +82,13 @@
extern void amiga_init_IRQ(void);
-void (*mach_sched_init) (void (*handler)(int, void *, struct pt_regs *)) __initdata;
+void (*mach_sched_init) (void (*handler)(int, void *, struct pt_regs *)) __initdata =
+NULL;
/* machine dependent keyboard functions */
-int (*mach_keyb_init) (void) __initdata;
+int (*mach_keyb_init) (void) __initdata = NULL;
int (*mach_kbdrate) (struct kbd_repeat *) __apusdata = NULL;
void (*mach_kbd_leds) (unsigned int) __apusdata = NULL;
/* machine dependent irq functions */
-void (*mach_init_IRQ) (void) __initdata;
+void (*mach_init_IRQ) (void) __initdata = NULL;
void (*(*mach_default_handler)[]) (int, void *, struct pt_regs *) __apusdata = NULL;
void (*mach_get_model) (char *model) __apusdata = NULL;
int (*mach_get_hardware_list) (char *buffer) __apusdata = NULL;
diff -ur linux-2.4.org/arch/ppc/kernel/prep_setup.c
linux-2.4-initdata/arch/ppc/kernel/prep_setup.c
--- linux-2.4.org/arch/ppc/kernel/prep_setup.c Thu Oct 5 19:35:22 2000
+++ linux-2.4-initdata/arch/ppc/kernel/prep_setup.c Thu Oct 5 20:18:55 2000
@@ -384,8 +384,8 @@
* 2 following ones measure the interval. The precision of the method
* is still doubtful due to the short interval sampled.
*/
-static __initdata volatile int calibrate_steps = 3;
-static __initdata unsigned tbstamp;
+static volatile int calibrate_steps __initdata = 3;
+static unsigned tbstamp __initdata = 0;
void __init
prep_calibrate_decr_handler(intirq,
diff -ur linux-2.4.org/drivers/block/xd.c linux-2.4-initdata/drivers/block/xd.c
--- linux-2.4.org/drivers/block/xd.cThu Oct 5 19:35:27 2000
+++ linux-2.4-initdata/drivers/block/xd.c Thu Oct 5 20:14:58 2000
@@ -142,9 +142,9 @@
static DECLARE_WAIT_QUEUE_HEAD(xd_wait_open);
static u_char xd_valid[XD_MAXDRIVES] = { 0,0 };
static u_char xd_drives, xd_irq = 5, xd_dma = 3, xd_maxsectors;
-static u_char xd_override __initdata, xd_type __initdata;
+static u_char xd_override __initdata = 0, xd_type __initdata = 0;
static u_short xd_iobase = 0x320;
-static int xd_geo[XD_MAXDRIVES*3] __initdata;
+static int xd_geo[XD_MAXDRIVES*3] __initdata = { 0, };
static volatile int xdc_busy;
static DECLARE_WAIT_QUEUE_HEAD(xdc_wait);
diff -ur linux-2.
Re: 2.4.0-test9-pre8, usb, unresolved symbols
On Tue, Oct 03, 2000 at 09:54:25AM -0700, Greg KH wrote: > > Very strange, I'll beat on this some more today and try to see what's > up. I tried this .config on test9 final last night and didn't have any problems. Could you see if this is still a problem with test9? thanks, greg k-h -- greg@(kroah|wirex).com - 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: Majordomo Problems?
Hello, > I don't know if anyone else is seeing this, but I'm getting multiple copies > of > a lot of the emails to this list. For some, it's two copies, for others it > is up > to four copies. Am I the only one seeing this? No, I've got the same problem... -- Sven Krohlas, | __o | + - The definite solution! Germany |_ \<,_ | http://www.asbest-online.de [PGP key avaible] | (_)/ (_) | Russisches Sprichwort: Dem Vogel ist ein einfacher Zweig lieber als ein goldener Käfig. [EOF] - 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: 2.4.0-pre9: mga drm still not working
On Thu, 5 Oct 2000, Michael Meding wrote: > Hi there, > > just a side note. It is recommended that you use the mga.o from dri tree > anyway... > not the one from the kernel tree. That won't help much about the > underlying problem with the loading order but since there is no way to > compile the mga.o in from the dri tree the problem itself vanishes ;-) I downloaded the DRI CVS tree this morning and tried to build it, but unfortunately it failed in numerous ways. Starting here: as -o 3dnow_xform_masked4.o 3dnow_xform_masked4.i Assembler messages: Error: Can't open 3dnow_xform_masked4.i for reading. 3dnow_xform_masked4.i: No such file or directory make[6]: *** [3dnow_xform_masked4.o] Error 1 Maybe I'll try building without the 3DNow business. Do you think that will help? -jwb - 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: usb-audio, does it work at all?
Eric, usb audio will be made to work again, but it's currently broken 2 ways: usb-uhci was just broken in 2.4.0-test9. Besides that, the audio driver has been broken since 2.4.0-test7 or so. It worked in 2.4.0-test5 but not in -test7. I've been searching for the problem but haven't found it yet. ~Randy > -Original Message- > From: Erik Mouw [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 05, 2000 11:40 AM > To: [EMAIL PROTECTED] > Subject: usb-audio, does it work at all? > > > Hi all, > > I just got a "Target USB speaker converter", which is basically a > USB sound card. I opened the case and found a Philips UDA1321PS > chip, which seems to be the same chip as used in the Philips > DSS 330 USB speakers, according to the linux-usb pages[1]. > However, if I connect it to my laptop, nothing happens. Yes, the > USB layer sees a new device, but nothing happens, even if I have > the audio module loaded. Does it work with the Philips USB > speakers, or is the driver just broken? > > I'm using linux-2.4.0-test9 on an Asus P6300 notebook (PII 233, 80MB > memory, Intel BX/ZX chipset) running SuSE 6.4. USB controller is > an Intel 82371AB PIIX4 USB and both UHCI drivers fail to do > something useful with the sound card. > > > Erik > > [1] http://linux-usb.sourceforge.net/usb.ids , look for Philips > > -- > J.A.K. (Erik) Mouw, Information and Communication Theory > Group, Department > of Electrical Engineering, Faculty of Information Technology > and Systems, > Delft University of Technology, PO BOX 5031, 2600 GA Delft, > The Netherlands > Phone: +31-15-2783635 Fax: +31-15-2781843 Email: > [EMAIL PROTECTED] > WWW: http://www-ict.its.tudelft.nl/~erik/ > - > 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/ > - 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: Majordomo Problems?
On Thu, Oct 05, 2000 at 02:40:01PM -0400, Post, Mark K wrote: > I don't know if anyone else is seeing this, but I'm getting multiple copies > of > a lot of the emails to this list. For some, it's two copies, for others it > is up > to four copies. Am I the only one seeing this? No, somebody thinks it's funny to make a mail loop: Received: ([EMAIL PROTECTED]) by vger.kernel.org id ; Thu, 5 Oct 2000 14:46:04 -0400 Received: from cam035106.student.utwente.nl ([130.89.226.36]:58126 "EHLO jaqr.student.utwente.nl") by vger.kernel.org with ESMTP id ; Thu, 5 Oct 2000 14:45:51 -0400 Received: (from daemon@localhost) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) id e95IUpm13949; Thu, 5 Oct 2000 20:30:51 +0200 Received: from freewww1.domainvalet.com (freewww1.domainvalet.com [216.122.66.78]) by jaqr.student.utwente.nl (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id e95IUom13942 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 20:30:50 +0200 Received: from vger.kernel.org (vger.kernel.org [199.183.24.194]) by freewww1.domainvalet.com (8.9.3/8.9.3) with ESMTP id KAA08066 for <[EMAIL PROTECTED]>; Thu, 5 Oct 2000 10:37:54 -0700 Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand id ; Thu, 5 Oct 2000 14:44:52 -0400 Received: ([EMAIL PROTECTED]) by vger.kernel.org I think it goes wrong at cam035106.student.utwente.nl. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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: Majordomo Problems?
Hello Mark , I can confirm the (Very) recent start of some duplicates showing up . 4 for one message , 2 for another . Hth , JimL On Thu, 5 Oct 2000, Post, Mark K wrote: > I don't know if anyone else is seeing this, but I'm getting multiple copies > of > a lot of the emails to this list. For some, it's two copies, for others it > is up > to four copies. Am I the only one seeing this? > Mark Post ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - 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/
Majordomo Problems?
I don't know if anyone else is seeing this, but I'm getting multiple copies of a lot of the emails to this list. For some, it's two copies, for others it is up to four copies. Am I the only one seeing this? Mark Post - 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/
usb-audio, does it work at all?
Hi all, I just got a "Target USB speaker converter", which is basically a USB sound card. I opened the case and found a Philips UDA1321PS chip, which seems to be the same chip as used in the Philips DSS 330 USB speakers, according to the linux-usb pages[1]. However, if I connect it to my laptop, nothing happens. Yes, the USB layer sees a new device, but nothing happens, even if I have the audio module loaded. Does it work with the Philips USB speakers, or is the driver just broken? I'm using linux-2.4.0-test9 on an Asus P6300 notebook (PII 233, 80MB memory, Intel BX/ZX chipset) running SuSE 6.4. USB controller is an Intel 82371AB PIIX4 USB and both UHCI drivers fail to do something useful with the sound card. Erik [1] http://linux-usb.sourceforge.net/usb.ids , look for Philips -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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: test9-pre? lockups using pine
Hello Same problem wit test9-pre kernels (duno when this started, but test8 seems to be fine, and pre9-final is compiling now) For me it locked up in pine, just after sending an Email, but not always. (and sure i had to retype my emails serveral times) And yes my mailfolders are large (may be relevant) Global configuration: AMDK6-2/256MB/scsi/ide Almost anything as module,using raid* on LVM (ide/scsi), 3com 1Gbit ethernet, netfilter,ipv6,ax.25,ppp, several different (network) filesystems etc. Distribution SuSE7.0, PINE 4.21. and running MTA is qmail 1.03. On Tue, 3 Oct 2000, Christoph Lameter wrote: > I frequently experience lockups since test9-pre7. It usually happens when > leaving pine. Pine asks if the deleted messages should be purged. Say yes > and everything freezes up. > > Kernel configuration (Debian woody + pine 4.21) Arjan Filius mailto:[EMAIL PROTECTED] - 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: procfs docs...
Great start. To complete it we need some info on the read/write
interface. Is it the same as for other drivers? I have heard that read
is called once after returning an EOF. Is this so? I suppose there are
other interfaces also, e.g. ioctl, etc.
George
Jeff Garzik wrote:
>
> On Thu, 5 Oct 2000, George Anzinger wrote:
> > Where is the internal interface to procfs documented?
>
> There is no documentation for the -exported- procfs interface as far as
> I know. As for internal interfaces, who knows what you are asking...
>
> Here's a rough outline: (maybe somebody should clean this up and stick
> it into Documentation/*)
>
> * Drivers without MAJOR /proc interfaces should stick their procfs
> files/directories into /proc/driver/*
>
> * Use proc_mkdir to create directories. For symlinks, proc_symlink, for
> device nodes, proc_mknod. Note that only proc_mknod takes a permission
> (mode_t) argument. If you need special permissions on directories, use
> create_proc_entry with S_IFDIR in mode_t arg. Otherwise directories
> will be mode 0755.
>
> * Use create_proc_read_entry for your procfs "files." For anything more
> complex than simply reading, use create_proc_entry. If you pass '0' for
> mode_t, it will have mode 0644 (ie. normal file permissions).
>
> * Use remove_proc_entry for removing entries.
>
> * Pass NULL for the parent dir, if you are based off of /proc root.
>
> * You don't need to keep around pointers to your procfs directories and
> files. Just call remove_proc_entry with the correct (full) path,
> relative, to procfs root, and the right thing will happen.
>
> Cheesy init example:
>
> if (!proc_mkdir("driver/my_driver", NULL))
> /* error */
> if (!create_proc_read_entry("driver/my_driver/foo", 0, NULL,
> foo_read_proc, NULL))
> /* error */
> if (!create_proc_read_entry("driver/my_driver/bar", 0, NULL,
> bar_read_proc, NULL))
> /* error */
>
> Cheesy remove example:
>
> remove_proc_entry ("driver/my_driver/bar", NULL);
> remove_proc_entry ("driver/my_driver/foo", NULL);
> remove_proc_entry ("driver/my_driver", NULL);
>
> In the above examples, I'm pretty sure that the proc_mkdir call,
> and final remove_proc_entry, can be skipped, too
>
> Jeff
-
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: 2.4.0-pre9: mga drm still not working
Hi there, just a side note. It is recommended that you use the mga.o from dri tree anyway... not the one from the kernel tree. That won't help much about the underlying problem with the loading order but since there is no way to compile the mga.o in from the dri tree the problem itself vanishes ;-) Greetings Michael - 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/
procfs docs...
On Thu, 5 Oct 2000, George Anzinger wrote:
> Where is the internal interface to procfs documented?
There is no documentation for the -exported- procfs interface as far as
I know. As for internal interfaces, who knows what you are asking...
Here's a rough outline: (maybe somebody should clean this up and stick
it into Documentation/*)
* Drivers without MAJOR /proc interfaces should stick their procfs
files/directories into /proc/driver/*
* Use proc_mkdir to create directories. For symlinks, proc_symlink, for
device nodes, proc_mknod. Note that only proc_mknod takes a permission
(mode_t) argument. If you need special permissions on directories, use
create_proc_entry with S_IFDIR in mode_t arg. Otherwise directories
will be mode 0755.
* Use create_proc_read_entry for your procfs "files." For anything more
complex than simply reading, use create_proc_entry. If you pass '0' for
mode_t, it will have mode 0644 (ie. normal file permissions).
* Use remove_proc_entry for removing entries.
* Pass NULL for the parent dir, if you are based off of /proc root.
* You don't need to keep around pointers to your procfs directories and
files. Just call remove_proc_entry with the correct (full) path,
relative, to procfs root, and the right thing will happen.
Cheesy init example:
if (!proc_mkdir("driver/my_driver", NULL))
/* error */
if (!create_proc_read_entry("driver/my_driver/foo", 0, NULL,
foo_read_proc, NULL))
/* error */
if (!create_proc_read_entry("driver/my_driver/bar", 0, NULL,
bar_read_proc, NULL))
/* error */
Cheesy remove example:
remove_proc_entry ("driver/my_driver/bar", NULL);
remove_proc_entry ("driver/my_driver/foo", NULL);
remove_proc_entry ("driver/my_driver", NULL);
In the above examples, I'm pretty sure that the proc_mkdir call,
and final remove_proc_entry, can be skipped, too
Jeff
-
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/
kmem_grow
Pardon my ignorance, but: Can anyone point me to a quick explaination of what kmem_grow: Called nonatomically from int - size-64 means or what to look for when you see something like this? I'm guessing size-64 is from the slab allocator... so kmalloc() or something is being called incorrectly somewhere I'll read the fine manual or the appropriate source if someone will point it out to me... TIA, Eli . "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." [EMAIL PROTECTED] `-- (random fortune) - 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/
procfs info
Where is the internal interface to procfs documented? George - 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: good book on kernel
On Thu, 5 Oct 2000, RAJESH BALAN wrote: > Hi, > Iam interested in learning linux kernel. Can anyone > suggest a really good book for kernel internals (im > not bothered abt the price). i 've a book named > "linux kernel internals". i want something more to > follow the code completely. > tx, well, I could do a shameless plug and recommend my own :) http://www.moses.uklinux.net/patches/lki.sgml (it is a part of LDP on www.linuxdoc.org but LDP copy is out of date, I will send them an update later...) also, read the file Documentation/kernel-docs.txt in the kernel sources -- it lists lots of things (including the above). Regards, Tigran - 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: good book on kernel
On Thu, 5 Oct 2000, RAJESH BALAN wrote: > Hi, > Iam interested in learning linux kernel. Can anyone > suggest a really good book for kernel internals (im > not bothered abt the price). i 've a book named > "linux kernel internals". i want something more to > follow the code completely. > tx, > rajesh balan If there was such a book, it would be an e-book. Because development is faster than a printing press. Andre Hedrick The Linux ATA/IDE guy - 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: good book on kernel
On Thu, 5 Oct 2000, RAJESH BALAN wrote: > Hi, > Iam interested in learning linux kernel. Can anyone > suggest a really good book for kernel internals (im > not bothered abt the price). i 've a book named > "linux kernel internals". i want something more to > follow the code completely. > tx, > rajesh balan > There is a list of books at http://kernelnewbies.org john -- "Words ought to be a little wild, for they are the assault of thoughts on the unthinking." - John Maynard Keynes - 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/
[PATCH] xconfig, Menuconfig fixes (2.4test9)
Hi Linus,
Two patches for 2.4.0test9 configuration follow.
1. I found two bugs in configuration utilities:
- Menuconfig doesn't ignore commented out "endmenu" commands (while
commented out "mainmenu_option" it does). I don't think it is
intentional... Especially as it breaks s390 architecture configuration
(commented "endmenu" -> missing uncommented one -> xconfig has problems;
this is fixead in the second patch, but requires this one)
- Both Menuconfig and xconfig has problem with shortened default values for
choice lists, eg.:
choice 'Processor family' \
[...]
PPro/6x86MXCONFIG_M686" PPro
^^^
In effect, if one hits this value usage case it not properly recognized.
And no choice variable is set (all are unset) unless he entered the choice
menu and rechoose. In fact, the default value is rarely used.
2. Fixed some obvious bugs in configuration scripts:
- fixed CONFIG_PCI setting in ppc/arm by introducing
separate variables for "bool" statements (help entries
cloned; somebody may want to fix them), [arch/ppc,arch/arm]
- removed bogus initial values for "bool",[arch/ppc,arch/sparc64]
- missing "endmenu" (effect of Menuconfig bug), [drivers/s390]
- bool/int outside menu (in the main menu), [arch/s390]
- "include" instead of "source" (previously sent fix for
sparc/sparc64 not included).[drivers/s390]
Regards
Andrzej
PATCH 1 *
diff -uNr linux-test9/scripts/Menuconfig linux/scripts/Menuconfig
--- linux-test9/scripts/Menuconfig Mon Aug 21 17:57:36 2000
+++ linux/scripts/MenuconfigThu Oct 5 19:05:38 2000
@@ -634,6 +634,7 @@
title="$1"
choices="$2"
current="$3"
+chosen=
#
# Scan current value of choices and set radiolist switches.
@@ -644,7 +645,12 @@
while [ -n "$2" ]
do
case "$1" in
- "$current") list="$list $2 $1 ON " ;;
+ "$current"*)if [ -z "$chosen" ]; then
+ list="$list $2 $1 ON "
+ chosen=1
+ else
+ list="$list $2 $1 OFF "
+ fi ;;
*) list="$list $2 $1 OFF " ;;
esac
@@ -722,13 +728,13 @@
parser(ifile, newmenu)
}
+ else if ($0 ~ /^#|\$MAKE|mainmenu_name/) {
+ printf("") >>menu
+ }
else if ($1 ~ "endmenu") {
printf("}\n") >>menu
return
}
- else if ($0 ~ /^#|\$MAKE|mainmenu_name/) {
- printf("") >>menu
- }
else if ($1 == "source") {
parser($2,menu)
}
@@ -751,12 +757,12 @@
function parser(ifile,menu) {
while (getline >menu
- }
- else if ($0 ~ /^#|$MAKE|mainmenu_name/) {
+ if ($0 ~ /^#|$MAKE|mainmenu_name/) {
printf("") >>menu
}
+ else if ($1 ~ /mainmenu_option|endmenu/) {
+ printf("") >>menu
+ }
else if ($1 == "source") {
parser($2,menu)
}
@@ -1192,6 +1198,7 @@
choices="$2"
default="$3"
current=
+ chosen=
set -- $choices
while [ -n "$2" ]
@@ -1215,12 +1222,15 @@
set -- $choices
while [ -n "$2" ]
do
- if eval [ "$1" = "$current" ]
- then
- define_bool "$2" "y"
- else
- define_bool "$2" "n"
- fi
+ case "$1" in
+ "$current"*)if [ -z "$chosen" ]; then
+ define_bool "$2" "y"
+ chosen=1
+ else
+ define_bool "$2" "n"
+ fi ;;
+ *) define_bool "$2" "n" ;;
+ esac
shift ; shift
done
}
diff -uNr linux-test9/scripts/tkparse.c linux/scripts/tkparse.c
--- linux-test9/scripts/tkparse.c Mon Jun 19 22:45:52 2000
+++ linux/scripts/tkparse.c Thu Oct 5 13:52:51 2000
@@ -326,6 +326,7 @@
static const char * tokenize_choices( struct kconfig * cfg_choose,
const char * pnt )
{
+int default_checked = 0
Re: [PATCH] tlan timer fix on tytso's list.
On Thu, Oct 05 2000, Jeff Garzik wrote: > * return value from pci_module_init and TLan_EisaProbe is never checked. > If you don't care about the return value, just remove 'rc' var. > I was going to have some code here, but haven't had the time. I'll remove it. > * does TLan_EisaProbe work? It looks like request_region may be called > twice for the same I/O region, once in TLan_EisaProbe, and once in > TLan_Init (via TLan_probe1). Yes it works. Check the code again: if (!priv->is_eisa) Jeff I'll make the other changes you suggested. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - 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/
good book on kernel
Hi, Iam interested in learning linux kernel. Can anyone suggest a really good book for kernel internals (im not bothered abt the price). i 've a book named "linux kernel internals". i want something more to follow the code completely. tx, rajesh balan __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ - 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: IDE problems 2.4.0-t9p8 and later
On Thu, 5 Oct 2000, Eric Lowe wrote: > Agreed. I ran into the same problem myself, but I figured you probably > didn't break it. Would be nice to see it fixed though, I'm trying > to help debug the new VM on that machine that just so happens to use > that chipset, and it's hard to do that when it doesn't boot at all. :) Okay, it is partly my fault because I missed the patch pre-release to Linus. I had several events that to major priority over Linux. Jeff and I agree now that there was a problem in communication and timing. It will be backed out and a better solution for the possible exception that he needs with be worked out. Some time later today I will publish a patch and post it on kerne.org Also I will get in touch with LT about me placing the patch in testing. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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/
[PATCH] xconfig, Menuconfig fixes (2.2.18pre15)
Hi Alan,
Two patches for 2.2.18pre15 configuration follow.
1. I found two bugs in configuration utilities:
- Menuconfig doesn't ignore commented out "endmenu" commands (while
commented out "mainmenu_option" it does). I don't think it is
intentional... Especially as it breaks s390 architecture configuration
(commented "endmenu" -> missing uncommented one -> xconfig has problems;
this is fixead in the second patch, but requires this one)
- Both Menuconfig and xconfig has problem with shortened default values for
choice lists, eg.:
choice 'Processor family' \
[...]
PPro/6x86MXCONFIG_M686" PPro
^^^
In effect, if one hits this value usage case it not properly recognized.
And no choice variable is set (all are unset) unless he entered the choice
menu and rechoose. In fact, the default value is rarely used.
2. Fixed some obvious bugs in configuration scripts:
- missing "endmenu" (effect of Menuconfig bug), [drivers/s390]
- double "==" instead a single one "=", [arch/m68k]
- bool/int outside menu (in the main menu), [arch/s390]
- duplicated condition in IDE section. [drivers/block]
Regards
Andrzej
PATCH 1 *
diff -uNr linux-2.2.18pre15/scripts/Menuconfig linux/scripts/Menuconfig
--- linux-2.2.18pre15/scripts/MenuconfigThu Oct 5 19:16:19 2000
+++ linux/scripts/MenuconfigThu Oct 5 19:17:01 2000
@@ -634,6 +634,7 @@
title="$1"
choices="$2"
current="$3"
+chosen=
#
# Scan current value of choices and set radiolist switches.
@@ -644,7 +645,12 @@
while [ -n "$2" ]
do
case "$1" in
- "$current") list="$list $2 $1 ON " ;;
+ "$current"*)if [ -z "$chosen" ]; then
+ list="$list $2 $1 ON "
+ chosen=1
+ else
+ list="$list $2 $1 OFF "
+ fi ;;
*) list="$list $2 $1 OFF " ;;
esac
@@ -721,13 +727,13 @@
parser(ifile, "MCmenu"menu_no)
}
+ else if ($0 ~ /^#|\$MAKE|mainmenu_name/) {
+ printf("") >>menu
+ }
else if ($1 ~ "endmenu") {
printf("}\n") >>menu
return
}
- else if ($0 ~ /^#|\$MAKE|mainmenu_name/) {
- printf("") >>menu
- }
else if ($1 == "source") {
parser($2,menu)
}
@@ -750,12 +756,12 @@
function parser(ifile,menu) {
while (getline >menu
- }
- else if ($0 ~ /^#|$MAKE|mainmenu_name/) {
+ if ($0 ~ /^#|$MAKE|mainmenu_name/) {
printf("") >>menu
}
+ else if ($1 ~ /mainmenu_option|endmenu/) {
+ printf("") >>menu
+ }
else if ($1 == "source") {
parser($2,menu)
}
@@ -1192,6 +1198,7 @@
choices="$2"
default="$3"
current=
+ chosen=
set -- $choices
while [ -n "$2" ]
@@ -1215,12 +1222,15 @@
set -- $choices
while [ -n "$2" ]
do
- if eval [ "$1" = "$current" ]
- then
- define_bool "$2" "y"
- else
- define_bool "$2" "n"
- fi
+ case "$1" in
+ "$current"*)if [ -z "$chosen" ]; then
+ define_bool "$2" "y"
+ chosen=1
+ else
+ define_bool "$2" "n"
+ fi ;;
+ *) define_bool "$2" "n" ;;
+ esac
shift ; shift
done
}
diff -uNr linux-2.2.18pre15/scripts/tkparse.c linux/scripts/tkparse.c
--- linux-2.2.18pre15/scripts/tkparse.c Thu Oct 5 19:16:19 2000
+++ linux/scripts/tkparse.c Thu Oct 5 19:17:01 2000
@@ -326,6 +326,7 @@
static const char * tokenize_choices( struct kconfig * cfg_choose,
const char * pnt )
{
+int default_checked = 0;
for ( ; ; )
{
struct kconfig * cfg;
@@ -349,12 +350,20 @@
cfg->token = token_choice_item;
cfg->cfg_parent = cfg_choose;
pnt = get_string( pnt, &cfg->label );
+ if ( ! default_checked &&
+
Re: IDE problems 2.4.0-t9p8 and later
Hello, > I did not change it and I have yet to get a good reason from the person > who did. I have explained why it was wrong to change, but I guess things > will have to start crashing again when Linus accepts changes that I never > looked at or discussed. > > Take it up with ManDrake Linux folks, it was there person that submitted > the change directly. I have VETOed the change, that only works in an > environment that respects boundaries and specialities. > Agreed. I ran into the same problem myself, but I figured you probably didn't break it. Would be nice to see it fixed though, I'm trying to help debug the new VM on that machine that just so happens to use that chipset, and it's hard to do that when it doesn't boot at all. :) -- Eric Lowe FibreChannel Software Engineer, Systran Corporation [EMAIL PROTECTED] - 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] Link order of drivers outside drivers/scsi
On Thu, Oct 05 2000, Jeff Garzik wrote: > Please include your patches inline so we can easily quote them via the > standard e-mail reply feature. > > i2o_block.c: you don't need EXPORT_NO_SYMBOLS (yes, I know it was there > before) I' remove it. > sg.c: ug. the worst part of the patch. you revert some of doug > gilbert's correct changes, which went in after test9-pre9. This is > way wrong, so maybe it's a version/diff problem? > My fault. It seems I've had and old sg.c in my tree. Sorry should have double checked. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - 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] Link order of drivers outside drivers/scsi
Please include your patches inline so we can easily quote them via the standard e-mail reply feature. i2o_block.c: you don't need EXPORT_NO_SYMBOLS (yes, I know it was there before) sd.c: why do you add two blank lines, but change nothing else? sg.c: ug. the worst part of the patch. you revert some of doug gilbert's correct changes, which went in after test9-pre9. This is way wrong, so maybe it's a version/diff problem? Jeff - 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] tlan timer fix on tytso's list.
On Thu, Oct 05 2000, Tigran Aivazian wrote: > Hi Torben, > > Just a tiny comment - maybe you noticed the recent "trend" in moving > zero-initialised data out of data into where it belongs, i.e. bss. Your > patch does a little bit to the contrary, namely bits like: > > +static struct net_device *TLan_Eisa_Devices = NULL; > > > > +static int tlan_have_pci = 0; > +static int tlan_have_eisa = 0; > True. I'll submit a new patch ASAP. Thanks for noticing Tigran. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - 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/
[PATCH] Link order of drivers outside drivers/scsi
Linus,
This patch is a resend of my other link fix patch that didn't get
in test9-pre9. I assume this is because of some other changes
to upper layer scsi drivers.
This patch is a lot smaller because the "moving files around" part
has been omittet.
So please apply this patch and do the following:
copy sd.c sg.c sr.c sr_ioctl.c sr_vendor st.c to
drivers/scsi/upper
I really hope you don't mind this way of applying a patch, so if
you do please let me know. The patch still includes the I2O
fixes (verified by Alan).
BTW. To fix other drivers outside drivers/scsi to link corretly
they need the same changes as I2O:
convert to initcalls
move them in top makefile.
I just need to identify which drivers needs this.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -urN linux-test9/Makefile linux/Makefile
--- linux-test9/MakefileTue Oct 3 23:39:53 2000
+++ linux/Makefile Tue Oct 3 23:38:41 2000
@@ -144,7 +144,13 @@
DRIVERS-$(CONFIG_ARCNET) += drivers/net/arcnet/arcnet.a
DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o
DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o
+
+# Init ordering constraint:
+# scsidrv.o < !drivers/scsi < scsi_upper.o
DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o
+DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
+DRIVERS-$(CONFIG_SCSI) += drivers/scsi/upper/scsi_upper.o
+
DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a
ifneq
($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),)
@@ -171,7 +177,6 @@
DRIVERS-$(CONFIG_TC) += drivers/tc/tc.a
DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o
DRIVERS-$(CONFIG_INPUT) += drivers/input/inputdrv.o
-DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
DRIVERS-$(CONFIG_IRDA) += drivers/net/irda/irda.o
DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.o
diff -urN linux-test9/drivers/block/genhd.c linux/drivers/block/genhd.c
--- linux-test9/drivers/block/genhd.c Tue Oct 3 23:39:58 2000
+++ linux/drivers/block/genhd.c Tue Oct 3 23:38:41 2000
@@ -27,7 +27,6 @@
extern void console_map_init(void);
extern int soc_probe(void);
extern int atmdev_init(void);
-extern int i2o_init(void);
extern int cpqarray_init(void);
extern void ieee1394_init(void);
@@ -39,9 +38,6 @@
chr_dev_init();
blk_dev_init();
sti();
-#ifdef CONFIG_I2O
- i2o_init();
-#endif
#ifdef CONFIG_BLK_DEV_DAC960
DAC960_Initialize();
#endif
diff -urN linux-test9/drivers/i2o/i2o_block.c linux/drivers/i2o/i2o_block.c
--- linux-test9/drivers/i2o/i2o_block.c Tue Oct 3 23:40:13 2000
+++ linux/drivers/i2o/i2o_block.c Tue Oct 3 23:38:41 2000
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -108,6 +109,7 @@
#define I2O_BSA_DSC_VOLUME_CHANGED 0x000D
#define I2O_BSA_DSC_TIMEOUT 0x000E
+
/*
* Some of these can be made smaller later
*/
@@ -1591,11 +1593,7 @@
* (Just smiley confuses emacs :-)
*/
-#ifdef MODULE
-#define i2o_block_init init_module
-#endif
-
-int i2o_block_init(void)
+static int __init i2o_block_init(void)
{
int i;
@@ -1611,9 +1609,8 @@
MAJOR_NR);
return -EIO;
}
-#ifdef MODULE
+
printk(KERN_INFO "i2o_block: registered device at major %d\n", MAJOR_NR);
-#endif
/*
* Now fill in the boiler plate
@@ -1694,13 +1691,7 @@
return 0;
}
-#ifdef MODULE
-
-EXPORT_NO_SYMBOLS;
-MODULE_AUTHOR("Red Hat Software");
-MODULE_DESCRIPTION("I2O Block Device OSM");
-
-void cleanup_module(void)
+static void __exit i2o_block_exit(void)
{
struct gendisk **gdp;
int i;
@@ -1760,4 +1751,11 @@
break;
}
-#endif
+
+EXPORT_NO_SYMBOLS;
+MODULE_AUTHOR("Red Hat Software");
+MODULE_DESCRIPTION("I2O Block Device OSM");
+
+module_init(i2o_block_init);
+module_exit(i2o_block_exit);
+
diff -urN linux-test9/drivers/i2o/i2o_config.c linux/drivers/i2o/i2o_config.c
--- linux-test9/drivers/i2o/i2o_config.cTue Oct 3 23:40:13 2000
+++ linux/drivers/i2o/i2o_config.c Tue Oct 3 23:38:41 2000
@@ -910,11 +910,7 @@
&config_fops
};
-#ifdef MODULE
-int init_module(void)
-#else
-int __init i2o_config_init(void)
-#endif
+static int __init i2o_config_init(void)
{
printk(KERN_INFO "I2O configuration manager v 0.04.\n");
printk(KERN_INFO " (C) Copyright 1999 Red Hat Software\n");
@@ -948,9 +944,7 @@
return 0;
}
-#ifdef MODULE
-
-void cleanup_module(void)
+void __exit i2o_config_exit(void)
{
misc_deregister(&i2o_miscdev);
@@ -961,9 +955,11 @@
if(i2o_buffer)
kfree(i2o_buffer);
}
+
+module_init(i2o_config_init);
+module_exit(i2o_config_exit);
EXPORT_NO_SYMBOLS;
MODULE_AUTHOR("Red Hat Software");
MODULE_DESCRIPTION("I2O Configuration");
-#endif
diff -urN linux-test9/drive
