Re: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
Compile bombs out in bridging: br.c: In function `brg_probe': br.c:2458: `loops_per_sec' undeclared (first use in this function) br.c:2458: (Each undeclared identifier is reported only once br.c:2458: for each function it appears in.) br.c:2442: warning: `bogomips' might be used uninitialized in this function br.c: At top level: br.c:165: warning: `br_get_ifnames' declared `static' but never defined make[3]: *** [br.o] Error 1 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_bridge] Error 2 make: *** [_dir_net] Error 2 In the style of the other loops_per_sec->loops_per_jiffy changes this makes it compile (not booted, yet...) --- net/bridge/br.c~Sun Sep 10 11:38:46 2000 +++ net/bridge/br.c Sun Oct 1 00:26:26 2000 @@ -2455,7 +2455,7 @@ /* Set up MAC address based on BogoMIPs figure for first CPU and time */ - bogomips = (loops_per_sec+2500)/50 ; + bogomips = (loops_per_jiffy+2500)/(50/HZ); get_fast_time(); /* U YES! */ M - 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: We interrupt you regularly scheduled catfight for.. Linux2.2.18pre13
On Sat, 30 Sep 2000, Horst von Brand wrote: > Alexander Viro <[EMAIL PROTECTED]> said: > > [...] > > > Patches are welcome. But keep in mind that we _are_ dependent on a > > particular compiler. gcc, that is. I would be glad to get rid of it - the > > codebase is extremely messy. However, removing gcc-isms is a huge > > work. You are welcome to do it, indeed, but so far nobody had done that. > > Is there any _real_ gcc alternative in sight? pcc might become such, but I'm not subscribing to that job. - 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: Standard Linux (Was What is up with Redhat 7.0?)
There is no need for a law requiring a 'standard' kernel in any distro, and there is no chance people would follow any such rule. So long as people know their distro kernel is patched and, if they want to apply some 3rd party patch, we advise them they may want to obtain and install 'clean' sources from kernel.org. This is the approach I take in my kernel-config chapters for the Unleashed books, and it is also the advice given on the RedHat website (or at least it was last I looked) Anyone who knows they need and will apply a 3rd party patch likely knows how to obtain and compile a fresh kernel (or can follow my chapter ;) A case in point is the Trelos Win4Linux windows 'emulator'. This is shipped as a patch against what I call "the cannonical sources" and fails on some of the more exotic distros. Frankly, I don't think Trelos should bother shipping 'distro flavours' of their patch, and instead, distros should ship a diff-set which would incrementally migrate cannonical sources to match their distro package. That way, if I want Trelos' software, I get the kernel.org sources, patch them for Trelos, then selectively add what I want from RedHat or Mandrake or Debian or whatever. IMHO, this has a far greater chance of success across a wider range of scenarios. However it goes, though, it is not our problem, it is entirely up to the distros to sort this out among themselves and the ISVs. -- Gary Lawrence Murphy <[EMAIL PROTECTED]>: office voice/fax: 01 519 4222723 T(!c)Inc Business Innovation through Open Source http://www.teledyn.com M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net "You don't play what you know; you play what you hear." --- Miles Davis - 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/
implicit declaration of execve()
Hi, I am trying to call execve() from within fs/binfmt_elf.c. I am fairly certain I am giving it the right arguments (ie. path,argv and envp). As an example I am referring to the use of execve in kernel/kmod.c and init/main.c. On kernel compilation I always get the error "Warning: implicit declaration of execve()" and at the end of the compilation: fs/fs.o: undefined reference to execve. which (AFAIK) means that it cannot find a declaration of execve. I am including all the .h files that are included in kmod.c (ie unistd,uaccess,smp_lock?, sched, etc) and yet I still get this error. Can anyone shine a light on this for me? I am not on the list, so a reply to this address would be appreciated. Thanks in advance... dan. -= Daniel Walls - 4th Yr B. InfTech (Hon) UQ =- - 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.18pre13 and sun4c
> > Attached is my .config, not sure what else could be needed. > > Patience :) In Alan's announce, he said some changes were made to udelay() that would require non-x86 to do some mods. I'm sure by pre14 these will be merged in (or soon thereafter). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
Alexander Viro <[EMAIL PROTECTED]> said: [...] > Patches are welcome. But keep in mind that we _are_ dependent on a > particular compiler. gcc, that is. I would be glad to get rid of it - the > codebase is extremely messy. However, removing gcc-isms is a huge > work. You are welcome to do it, indeed, but so far nobody had done that. Is there any _real_ gcc alternative in sight? Just wondering... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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/
kernel BUG at ll_rw_blk.c:711
This is the first time in a long time I'm experiencing problems with the Linux kernel. A wonderful job. The backside is that it's also a very long time ago since the last time I read (parts of) the kernel. One of my users complained of netscape hanging frequently while reading news. I tried to find out what was happening and found netscape in the ``uninterruptible sleep' state. When checking dmesg I found this message: --- kernel BUG at ll_rw_blk.c:711! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00210282 eax: 001f ebx: c15853c0 ecx: c1377180 edx: esi: c15853c0 edi: c02b9760 ebp: 0001 esp: c39a3ea8 ds: 0018 es: 0018 ss: 0018 Process communicator-sm (pid: 1415, stackpage=c39a3000) Stack: c0207405 c02076a2 02c7 c15853c0 0001 000c c135fd54 c02b9778 c02b9770 0008 c0167f22 00fe c0168b81 c02b9760 0001 c15853c0 c15853c0 0001 c39a3f38 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 0f b6 46 15 0f b7 4e 14 8b 14 85 e0 dc 2a --- Well, if the kernel says it's a bug, it'll be a bug, right? But I really don't know what to do with this. I checked out that line and got the message that this is something for 2.5. The kernel is 2.4.0pre8 using APIC on a mono CPU, compiled with gcc 2.95.2, debian/woody box (Athlon CPU, Biostar motherboard, VIA chipset). I wonder if there is anything I can do in this situation beside switching off APIC and waiting for 2.5.0. The bad thing is, that after this has happened, sync, shutdown (and some other programs?) also fall asleep, forcing me to powercycle the computer. I can't really tell how to reproduce the problem, but as it is popping up quite frequently, a more knowledable writer on this list might be able to tell me how to prepare such an event to make it reproducible. In both cases, please CC to me, as I'm not on this list. TIA Christoph - 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: What is up with Redhat 7.0?
Bernhard Rosenkraenzer wrote: > > Which still makes it an broken, experimental, unreleased and unofficial > > compiler, with all the consequences I said. > > I agree about the "unreleased and unofficial" part, but it's not quite > that broken and experimental. Everything that is shipped with Red Hat > Linux (the distribution itself, Powertools, the extra CDs for Europe, > etc) compiles and works without problems. > Some programs needed patches, but that was much like updating from egcs > 1.1.2 to gcc 2.95 - stricter checks for clean code. Hah! Even the preprocessor is broken in 2.96. I have to use an older one. -- 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: kernel compilation question
> that the main kernel is compiled with gcc, and linked with standard ld, > and only the bootloader code is compiled using the bin86 (as86, > ld86) tools. Am I right in interpreting this to mean that the main kernel > is/can be 32-bit binary, and not strictly 16-bit? The main kernel is 32bit. The 16bit pieces of code are just used to boot into 32bit mode either on the first CPU when entering from the bootstrap or on the other processors (if SMP) from the processor startup messages - 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] Fix for I-Opener IDE problems
Andre Hedrick wrote: > > On Sat, 30 Sep 2000, Alex Stewart wrote: > > > The attached patch (against 2.4.0-test8) adjusts the code to only mark > > the slave not present if a flashdisk is master, not vice-versa. > > So are you saying that the master is flash and slave is ATA? No, that's not what I'm saying. The master is a traditional ATA disk and the _slave_ is a flash disk: hda: IBM-DMCA-21440, ATA DISK drive hdb: SunDisk SDTB-128, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 2822400 sectors (1445 MB) w/96KiB Cache, CHS=700/64/63 hdb: 31360 sectors (16 MB) w/1KiB Cache, CHS=490/2/32 Take a look at the patch (it only changes two lines). It's pretty clear what it fixes. -alex - 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/
kernel compilation question
I was perusing the makefiles, and I've pretty much come to the conclusion that the main kernel is compiled with gcc, and linked with standard ld, and only the bootloader code is compiled using the bin86 (as86, ld86) tools. Am I right in interpreting this to mean that the main kernel is/can be 32-bit binary, and not strictly 16-bit? Strictly for the sake of doing it, I'm considering recompiling the kernel using an alternate compiler, and if the kernel main is actually 16-bit, I need to know that information for setting up the other compiler. Thanks for the info. Dan Lange - 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: What is up with Redhat 7.0?
In article <[EMAIL PROTECTED]>, Marc Lehmann <[EMAIL PROTECTED]> wrote: >Taken on it's own, redhat never did anything which is not "politically >correct" or "was just a bug that has been fixed". However, that redhat >claims to maintain linux, gcc and other major projects (which is >absolutely untrue) is an open secret - just look at sources.redhat.com >where redhat openly announces _their_ projects (like source navigator, >binutils and gcc). I believe that any happy talk you find on the "sources.redhat.com" web page predates the Red Hat/Cygnus merger. The words probably came from the gdb developer who was instrumental in getting funding within Cygnus for setting up a T1 and a system to support the external free software community. I am fairly certain that there was little or no marketing intent. There was a 's/Cygnus/Red Hat/g' operation on the web page at some point, though, of course. What you are apparently reading as an announcement of ownership is the intermingling of things like news of the release of the Source Navigator sources with news of the binutils release. Personally, I think it is a stretch to construe that as Red Hat crowing about ownership of binutils but since you have interpreted it this way, it's likely that others have too. As a Red Hat employee and one of the sources.redhat.com site administrators, I'll look into changing the words to make things clearer and to better delineate what is an FSF project, what is a Red Hat project, and what is just a random "Joe Hacker" sponsored project. I don't recall any previous complaints about the wording of the sources.redhat.com site, but, really, all you have to do is mention it if you find something objectionable. We're happy to correct anything which gives a misperception. And, I personally apologize if the site which I help administer is giving people the wrong impression. I can just imagine the headlines when I change things, though: "Red Hat bows to external pressure from irate open source community." -- [EMAIL PROTECTED] Cygnus Solutions, a Red Hat company http://sources.redhat.com/ http://www.redhat.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/
SA_INTERRUPT
Don Becker has some text at: http://www.scyld.com/expert/irq-conflict.html which includes a section: > Why SA_INTERRUPT in the SCSI drivers is a Bad Thing > ... it could potentially have a very negative impact on all other interrupt-driven > kernel service. That includes just about everything ... > > I believe that very few complex devices can be correctly run by a device driver > that uses SA_INTERRUPT. So I grepped drivers/*/*.c in the nearest handy kernel source, which happened to be 2.2.16, and found 113 uses of SA_INTEERUPT, 64 in drivers/scsi/*.c and the rest spread around. Do we have a problem? Should it be fixed as part of the cleanup before 2.4.0? - 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: [RFC] Imminent death of /proc/locks predicted; film at 11
On Sat, Sep 30, 2000 at 08:23:37PM -0500, Peter Samuelson wrote: > > [Matthew Wilcox] > > if fcntl took a 4th argument specifying the length of the buffer, i'd > > recommend a F_GETLKS fcntl. a horrid work around for this would be > > that the first 4 bytes of the buffer pointed to by the third argument > > of the fcntl is the length of the buffer. > > E! You're right, it's horrid. Anyway, I think this one can be > solved in userspace -- as long as you don't need atomicity. Untested > code with no error checking: thanks for snipping the part of my email where i explain this won't work. examples: process 1 locks bytes 1 to 7 nonexclusively process 2 locks bytes 2 to 5 nonexclusively you now can't see the second lock. and there's no way of seeing the blocked lock. This needs kernel support some how. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
breada bug
On Tue, 29 Feb 2000 11:10:20, Mikulas Patocka wrote:
: This code in breada
:
:if (blocks < (read_ahead[MAJOR(dev)] >> index))
:blocks = read_ahead[MAJOR(dev)] >> index;
:
: will increase number of block that are read ahead. However the code
: doesn't check for end of device and so it can generate accesses beyond
: end of device.
In patch-2.3.99-pre1 he, or someone else, added
--
--- v2.3.51/linux/fs/hpfs/buffer.c Tue Jun 1 23:25:47 1999
+++ linux/fs/hpfs/buffer.c Mon Mar 13 12:27:51 2000
@@ -125,7 +125,8 @@
kdev_t dev = s->s_dev;
struct buffer_head *bh;
- if (!ahead || secno + ahead >= s->s_hpfs_fs_size)
+/* - workaround for the breada bug */
+ if (!ahead || secno + ahead + (read_ahead[MAJOR(dev)] >> 9)
+>= s->s_hpfs_fs_size)
*bhp = bh = bread(dev, secno, 512);
else *bhp = bh = breada(dev, secno, 512, 0, (ahead + 1) << 9);
--
Two remarks:
(i) This code in hpfs/buffer.c is bogus:
The last argument of breada is a bytecount, read_ahead[]
and ahead are sector counts, and "(read_ahead[MAJOR(dev)] >> 9)"
has the wrong unit. Probably it is zero, and hence harmless,
but still this patch fragment and a similar one farther down
in the same file should be reverted.
(ii) Concerning the original comment, I agree, but disagree
with the proposed patch (not quoted here). Instead, I think
that the above test in fs/buffer.c should just be deleted.
In other words:
--- buffer.c~ Sun Sep 24 20:53:57 2000
+++ buffer.cSun Oct 1 03:17:33 2000
@@ -1038,12 +1038,8 @@
blocks = (filesize - pos) >> (9+index);
- if (blocks < (read_ahead[MAJOR(dev)] >> index))
- blocks = read_ahead[MAJOR(dev)] >> index;
if (blocks > NBUF)
blocks = NBUF;
-
-/* if (blocks) printk("breada (new) %d blocks\n",blocks); */
bhlist[0] = bh;
j = 1;
[pasted from another window]
(Then the logic becomes:
read ahead until end-of-file, but no more than NBUF blocks.)
I think that breada is used only in isofs and hpfs.
Perhaps the entire routine can be deleted.
Andries
-
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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
[Christoph Hellwig] > If you are using a distribution that ships with a default C compiler > that is not able to compile linux kernel, use make CC=kgcc (redhat) > or CC=gcc272 (debian) instead. That works for >= 2.3.30 or so. For 2.2 it's more like make CC="kgcc -D__KERNEL__ -I`pwd`/include" which is really too much to tell people to do. Most people would probably rather just edit the makefile. Peter - 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: [RFC] Imminent death of /proc/locks predicted; film at 11
[Matthew Wilcox]
> if fcntl took a 4th argument specifying the length of the buffer, i'd
> recommend a F_GETLKS fcntl. a horrid work around for this would be
> that the first 4 bytes of the buffer pointed to by the third argument
> of the fcntl is the length of the buffer.
E! You're right, it's horrid. Anyway, I think this one can be
solved in userspace -- as long as you don't need atomicity. Untested
code with no error checking:
#include
#include
#include
void report_locks(int fd, void (*report)(int, struct flock *))
{
off_t start, end;
struct flock f;
struct stat st;
fstat(fd, );
start = 0; end = st.st_size;
while (start <= end) {
f.l_type = F_WRLCK;
f.l_whence = L_SET;
f.l_start = start;
f.l_len = end-start;
fcntl (fd, F_GETLK, );
if (f.l_type == F_UNLCK) /* region is free for the taking */
break;
report (fd, );
start = f.l_start + f.l_len + 1;
}
}
Alan, is this roughly what you want?
Peter
-
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: [RFC] Imminent death of /proc/locks predicted; film at 11
On Sun, Oct 01, 2000 at 12:55:30AM +0100, Alan Cox wrote: > > When debugging this kind of problem, you're not interested in the > > non-conflicting locks, only the ones which are blocked waiting for > > another lock, right? > > All I care about is what locks are currently in force in the system. So for > example I can do something like > > showlocks /var/spool/mail/alan there's already a F_GETLK fcntl. however, it's not entirely suitable for use as a debugging tool since it dosen't report the blocked locks and it might not find all the locks in force (or if it does,it could take 2^64 calls to fcntl to find them all). given an inode, it's trivial to find the locks in force on it (and the locks blocked on the locks in force upon it). the difficulty lies in reporting this data to userspace. if fcntl took a 4th argument specifying the length of the buffer, i'd recommend a F_GETLKS fcntl. a horrid work around for this would be that the first 4 bytes of the buffer pointed to by the third argument of the fcntl is the length of the buffer. i'd appreciate anyone coming up with a nicer interface. How do other unices provide this information? grovelling through /proc/kcore? -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: We interrupt you regularly scheduled catfight for.. Linux2.2.18pre13
On Sat, 30 Sep 2000, Mr. James W. Laferriere wrote: > Where does the idea that the kernel 'needs' a special compiler > come from ? I have been under the impression that that is just Mostly from the sad fact that it does. > what we were trying to get away from . I am reminded of other > os's that required their propritary compiler in order to create > a os image . Please let us not travel that road . Tia , JimL Patches are welcome. But keep in mind that we _are_ dependent on a particular compiler. gcc, that is. I would be glad to get rid of it - the codebase is extremely messy. However, removing gcc-isms is a huge work. You are welcome to do it, indeed, but so far nobody had done that. - 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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
> > Isn't this completely broken? I mean, it wont detect the others at all. It > > will leave CC="" if gcc272 or kgcc are there. > > Yes. Sorry I' too selfish today ;) Your version seems more accurate to me. I've dropped Miquel's version into my tree. He simply side steps the entire 'which which' issue and uses scripts/kwhich Alan - 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: We interrupt you regularly scheduled catfight for.. Linux
> come from ? I have been under the impression that that is just > what we were trying to get away from . I am reminded of other > os's that required their propritary compiler in order to create > a os image . Please let us not travel that road . Tia , JimL We've always had the kernel tied to specific ranges of kernels and binutils. Given the nature of kernel code it is very hard to avoid and it takes a lot of time to get a new compiler version supported and trusted. In terms of needing a specific compiler well you need gcc or some variant of it. Linux is written very much in GNU c Alan - 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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
Ben Collins <[EMAIL PROTECTED]> wrote: > Isn't this completely broken? I mean, it wont detect the others at all. It > will leave CC="" if gcc272 or kgcc are there. Yes. Sorry I' too selfish today ;) Your version seems more accurate to me. Christoph -- Always remember that you are unique. Just like everyone else. - 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: [RFC] Imminent death of /proc/locks predicted; film at 11
> When debugging this kind of problem, you're not interested in the > non-conflicting locks, only the ones which are blocked waiting for > another lock, right? All I care about is what locks are currently in force in the system. So for example I can do something like showlocks /var/spool/mail/alan - 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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
On Sat, Sep 30, 2000 at 07:30:42PM -0400, Alexander Viro wrote: > Forget distributions. There is a very, very good reason to have the choice > of cc used in kernel builds uncoupled from the userland one. IMO kgcc is a > misnomer (kcc would be better), but the idea is sound - you don't want to > deal with the miscompiled kernel while you are porting the userland to > another version of compiler. You also don't want it once you've are done > with the userland stuff - level of dependency on gcc details is much > higher in case of the kernel. I have no problem with that although I didn't think about it yet. What I disklike is having magic in the Makefile to find the right compiler. Probably we could just put CC=kcc in the Makefile and everyone would have to arrange it right. (This is also a good way to make the newbies the documentation ;)) Christoph -- Always remember that you are unique. Just like everyone else. - 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: We interrupt you regularly scheduled catfight for.. Linux2.2.18pre13
Hello Alexander , On Sat, 30 Sep 2000, Alexander Viro wrote: > On Sun, 1 Oct 2000, Christoph Hellwig wrote: > > I personally dislike the 'autmatically detect kgcc and gcc272' patches a lot, > > and I think we should put a sentence like > > If you are using a distribution that ships with a default C compiler that is > > not able to compile linux kernel, use make CC=kgcc (redhat) or CC=gcc272 > > (debian) instead. > > into README, instead of fiddling around with a command/program with lots of > > different and incompatible versions. > Forget distributions. There is a very, very good reason to have the choice > of cc used in kernel builds uncoupled from the userland one. IMO kgcc is a > misnomer (kcc would be better), but the idea is sound - you don't want to > deal with the miscompiled kernel while you are porting the userland to > another version of compiler. You also don't want it once you've are done > with the userland stuff - level of dependency on gcc details is much > higher in case of the kernel. Where does the idea that the kernel 'needs' a special compiler come from ? I have been under the impression that that is just what we were trying to get away from . I am reminded of other os's that required their propritary compiler in order to create a os image . Please let us not travel that road . Tia , JimL ++ | 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/
Re: [PATCH] Fix for I-Opener IDE problems
On Sat, 30 Sep 2000, Alex Stewart wrote: > The attached patch (against 2.4.0-test8) adjusts the code to only mark > the slave not present if a flashdisk is master, not vice-versa. So are you saying that the master is flash and slave is ATA? Did you read the ide.c about ()->ata_flash flags? All you have to do is tell it that the flash exists. hdx=flash will set the flag. If this does not work then I-Opener will be required to disclose a constant unique signature in the MTD IDENTIFY page to know to look for the second device. 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: [RFC] Imminent death of /proc/locks predicted; film at 11
On Sun, Oct 01, 2000 at 12:29:27AM +0100, Alan Cox wrote: > > Does anyone actually want /proc/locks to stay? The data structure > > I'd like a way to view the locks that exist - its useful for debugging > weird app stuff > > > out /proc/locks. If it could be deleted, a lot of code and data pointers > > could go away. I don't think any program depends on its existance and > > it's a pretty ugly file anyway (exposing kernel pointers to userspace? > > looks like pure debug code). > > > > Speak now, or it shall be gone. > > If it makes the code far cleaner then I have no objection. If we can do a > simple (different format even) /proc/locks to replace it that scores double > points ;) This was the sort of objection I was hoping to receive :-) When debugging this kind of problem, you're not interested in the non-conflicting locks, only the ones which are blocked waiting for another lock, right? If so, then we need that structure around anyway for doing the crappy POSIX deadlock detection. And I don't have a problem with exposing that to userspace. If you did want all locks, we could walk all inodes in core and print out all the locks held on them :-) That might even be more scalable than the current approach... -- Revolutions do not require corporate support. - 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: [RFC] Imminent death of /proc/locks predicted; film at 11
On Sun, 1 Oct 2000, Alan Cox wrote: > If it makes the code far cleaner then I have no objection. If we can do a > simple (different format even) /proc/locks to replace it that scores double > points ;) Additional bonus points for changing the name. /proc/fs/locks might be a good variant... - 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: We interrupt you regularly scheduled catfight for.. Linux2.2.18pre13
On Sun, 1 Oct 2000, Christoph Hellwig wrote: > I personally dislike the 'autmatically detect kgcc and gcc272' patches a lot, > and I think we should put a sentence like > > If you are using a distribution that ships with a default C compiler that is > not able to compile linux kernel, use make CC=kgcc (redhat) or CC=gcc272 > (debian) instead. > > into README, instead of fiddling around with a command/program with lots of > different and incompatible versions. Forget distributions. There is a very, very good reason to have the choice of cc used in kernel builds uncoupled from the userland one. IMO kgcc is a misnomer (kcc would be better), but the idea is sound - you don't want to deal with the miscompiled kernel while you are porting the userland to another version of compiler. You also don't want it once you've are done with the userland stuff - level of dependency on gcc details is much higher in case of the kernel. - 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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
> - snip - > > --- Makefile~ Sun Oct 1 00:46:27 2000 > +++ Makefile Sun Oct 1 00:49:27 2000 > @@ -23,7 +23,7 @@ > AS =$(CROSS_COMPILE)as > LD =$(CROSS_COMPILE)ld > CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)cc; else \ > - which gcc272 2>/dev/null || which kgcc 2>/dev/null || echo cc; fi) \ > + which gcc272 >/dev/null 2>/dev/null || which kgcc > /dev/null 2>/dev/null || >echo cc; fi) \ > -D__KERNEL__ -I$(HPATH) > #CC =$(CROSS_COMPILE)cc -D__KERNEL__ -I$(HPATH) > CPP =$(CC) -E > - snip - Isn't this completely broken? I mean, it wont detect the others at all. It will leave CC="" if gcc272 or kgcc are there. How about: CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)cc; else \ if which gcc272 > /dev/null 2> /dev/null; then \ which gcc272; \ else \ if which kgcc > /dev/null 2> /dev/null; then \ which kgcc; \ else \ echo cc; \ fi; \ fi) -D__KERNEL__ -I$(HPATH) (obscure as needed) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [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: [RFC] Imminent death of /proc/locks predicted; film at 11
> Does anyone actually want /proc/locks to stay? The data structure I'd like a way to view the locks that exist - its useful for debugging weird app stuff > out /proc/locks. If it could be deleted, a lot of code and data pointers > could go away. I don't think any program depends on its existance and > it's a pretty ugly file anyway (exposing kernel pointers to userspace? > looks like pure debug code). > > Speak now, or it shall be gone. If it makes the code far cleaner then I have no objection. If we can do a simple (different format even) /proc/locks to replace it that scores double points ;) - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
[RFC] Imminent death of /proc/locks predicted; film at 11
Does anyone actually want /proc/locks to stay? The data structure which allows it to be generated is now only used by the code to print out /proc/locks. If it could be deleted, a lot of code and data pointers could go away. I don't think any program depends on its existance and it's a pretty ugly file anyway (exposing kernel pointers to userspace? looks like pure debug code). Speak now, or it shall be gone. -- Revolutions do not require corporate support. - 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.18pre12 mouse detection problem
On Sat, 30 Sep 2000, Alan Cox wrote: > > use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2 > > mouse and do I want to install it, etc. If I tell it not to change > > anything, the system comes up. However, the real mouse then misbehaves > > badly, losing button-down events and being generally sluggish. > > > > Rebooting with 2.2.17, there are no problems. > > 2. can you see if an earlier one is broken > > In theory 2.2.18pre12 has the only actual change to mouse behaviour and > its not capable of breaking it. But theory is obviously out to lunch at the > moment Alan, No problem with 2.2.18pre11. - 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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
> I personally dislike the 'autmatically detect kgcc and gcc272' patches a lot, > and I think we should put a sentence like > > If you are using a distribution that ships with a default C compiler that is > not able to compile linux kernel, use make CC=kgcc (redhat) or CC=gcc272 > (debian) instead. kgcc is also conectiva but maybe You are under the delusion that people read the README file ? I'd like to get a solution to this. If I can get one that works everywhere then its README file time yes. Herbert Xu posted a fairly sane looking approach Alan - 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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
> o Fix the 'which' compiler stuff (Horst von Brand, >Peter Samuelson) > | Can someone verify for me this works on Slackware and > | on Caldera ? It breaks on Caldera. The errors are: -- snip - bin/sh: syntax error near unexpected token `(/' /bin/sh: -c: line 1: `if which: no gcc272 in (/bin:/usr/bin:/usr/sbin:/sbin:/home/lstguest/hch/bin) which: no kgcc in (/bin:/usr/bin:/usr/sbin:/sbin:/home/lstguest/hch/bin) cc -D__KERNEL__ -I/home.stand/lstguest/hch/linux/include -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi' (/bin:/usr/bin:/usr/sbin:/sbin:/home/lstguest/hch/bin) cc -D__KERNEL__ -I/home.stand/lstguest/hch/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -v 2>&1 -- snip - The problem is that the which output is not ignored. The following patch fixes it: - snip - --- Makefile~ Sun Oct 1 00:46:27 2000 +++ MakefileSun Oct 1 00:49:27 2000 @@ -23,7 +23,7 @@ AS =$(CROSS_COMPILE)as LD =$(CROSS_COMPILE)ld CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)cc; else \ - which gcc272 2>/dev/null || which kgcc 2>/dev/null || echo cc; fi) \ + which gcc272 >/dev/null 2>/dev/null || which kgcc > /dev/null 2>/dev/null || +echo cc; fi) \ -D__KERNEL__ -I$(HPATH) #CC=$(CROSS_COMPILE)cc -D__KERNEL__ -I$(HPATH) CPP=$(CC) -E - snip - I personally dislike the 'autmatically detect kgcc and gcc272' patches a lot, and I think we should put a sentence like If you are using a distribution that ships with a default C compiler that is not able to compile linux kernel, use make CC=kgcc (redhat) or CC=gcc272 (debian) instead. into README, instead of fiddling around with a command/program with lots of different and incompatible versions. Christoph -- Always remember that you are unique. Just like everyone else. - 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] Fix for I-Opener IDE problems
Attached is a patch which fixes the boot problems on I-Opener hardware.
The problem is not the IDE chipset, as some had assumed, but rather the
SanDisk flash disk. Since flashdisks typically don't have slaves, there
is code in the kernel to avoid checking for a slave disk if a flashdisk
is detected on an IDE interface. The problem is that the code as
originally written has the side effect that if a flashdisk is detected
as the slave disk on an interface (as it is on an I-Opener if another
disk is attached as master), it will mark the master as being not
present even though it is.
The attached patch (against 2.4.0-test8) adjusts the code to only mark
the slave not present if a flashdisk is master, not vice-versa.
-alex
--- drivers/ide/ide-probe.c.origSat Sep 30 13:38:36 2000
+++ drivers/ide/ide-probe.c Sat Sep 30 13:40:37 2000
@@ -161,8 +161,8 @@
* Prevent long system lockup probing later for non-existant
* slave drive if the hwif is actually a flash memory card of some variety:
*/
- if (drive_is_flashcard(drive)) {
- ide_drive_t *mate = (drive)->drives[1^drive->select.b.unit];
+ if (!drive->select.b.unit && drive_is_flashcard(drive)) {
+ ide_drive_t *mate = (drive)->drives[1];
if (!mate->ata_flash) {
mate->present = 0;
mate->noprobe = 1;
Re: Linux 2.2.18pre12
On Sat, 30 Sep 2000, Alan Cox wrote: > > does not compile with gcc272. > > > > It complains about the line > > > > static __attribute__((unused)) void unused(void) > > > > gcc 2.95.2 does compile it. > > I dont have 272 around at the moment does > > static void __attribute__((unused)) work ? Yes, it does. Greetings Wolfgang Walter - 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.18pre12 fix for some distros
On Sat, Sep 30, 2000 at 03:13:02PM +0100, Alan Cox wrote:
> > Please replace which with "command -v" which is required by SuS in /bin/sh.
>
> command -v breaks on some setups. One problem can be seen easily by doing this
>
> # command -v ls
> alias ls='ls --color=tty'
.bashrc is only read for interactive shells. Besides, if which is a bash
alias as well,
$ command -v which
alias which='type -path'
$
it will break too,
$ which which
$
I think what you can do is to ignore the value returned by command -v, and
just use it is an indication that this thing exists. After all, if you can
find it using command -v, just calling it will work too. Something like
if command -v gcc272 > /dev/null 2> /dev/null; then echo gcc272; else \
echo gcc; fi
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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.18pre12 mouse detection problem
On Sat, 30 Sep 2000, Alan Cox wrote: > > use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2 > > mouse and do I want to install it, etc. If I tell it not to change > > anything, the system comes up. However, the real mouse then misbehaves > > badly, losing button-down events and being generally sluggish. > > > > Rebooting with 2.2.17, there are no problems. > > Ugghh. Ok > 1. do you have any usb stuff compiled in or loaded as >modules No to both questions. > 2. can you see if an earlier one is broken I'll build 2.2.18pre11 and let you know. > In theory 2.2.18pre12 has the only actual change to mouse behaviour and > its not capable of breaking it. But theory is obviously out to lunch at the > moment Funny how that sometimes works! Steve - 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/
MANOS Mailing List
For anyone wanting to track the MANOS fork of Linux for the purposes of monitoring bugs that show up in the ports of Linux code and drivers to the Open Source NetWare, the MANOS mailing list is active, and you can sign up at [EMAIL PROTECTED] It's set up the same way the lists for linux-kernel are setup. I will post the announcement of exactly which individuals code has been identified to move over next week, when work will begin in earnest. We have moved most of the MANOS code over to gcc, and the next post of MANOS will include the LLINK linkers we wrote that link DLL's and W2K PE EXE's into a bootable OS, along with make scripts for gcc. Bugs received on this list for existing Linux code will be reposted to linux-kernel if they also affect Linux. :-) 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: Standard Linux (Was What is up with Redhat 7.0?)
On Sat, 30 Sep 2000, Michael Peddemors wrote: >On Sat, 30 Sep 2000, Marc Lehmann wrote: > >> However, I think attacking other free softwrae projects because of *bugs* >> is just childish at this point - after all, this discussion was about >> supporting distributions that - without technical reasons - make their >> products incompatible to what one would call "standard linux", and that I >> do not think that the kernel should support such doings. >> > > >That RedHat Thread was degrading into a name calling match... >But it does have one core element that maybe should be discussed, and that can be a >relevant and productive discussion for this list. > >'Standard Linux' >Should the core kernel define a standard Linux?? >And what does the community think of distros that veer from the standard? >Should the 'standard' be set in stone? > >ie should we say that ALL distros have to ship with, and be compatible with the >standard kernel? If a distro has a patch that they want in the kernel, and the >mainstream kernel doesn't feel it belongs, should it be labeled differently? >Do we go with a Debian Linux, Redhat Linux, etc.. accepting that they are all >different, but from a common heritage or should there be a 'seal of approval' so that >a distro can indicate it is 100% linux mainstream, as in >SomeDistro Linux, '100% Linux Standard Compliant' This has come up in the past. 1. Most of the "distribution" is actually code from a totally independant (from Linux) project - the FSF Hurd. 2. Linux only refers to the kernel. Not the distribution. Most of the utilities (when you get away from device/kernel setup/logging/initialization) is from that project. I believe R. Stallman would prefer that the distributions be referred to differently (Hurd/linux? That wasn't quite it... I don't remember what he said specificly). It had to do with the source of most of the things that make a system work - cp, ls, mkdir, gcc, libc,... These all come from a different location, they are not part of Linux, although the Linux kernel is useless without them. >Thoughts?? I know our Linux Distro is non-conformant because of our FreeS/WAN and >encryption patches.. Yes, we are still Linux, but I know we shouldn't get the '100% >...Compliant' label.. Of course, from a marketing standpoint, I would hate to carry >that stigma, but I think it is prudent that our customers have the right to know that >their experience with other Linux's may not be sufficient, or that down the road they >may be forced to use us for support, or get/buy 'LinuxMagic' software rather than >'100% Compliant' versions of the software if we choose to not be compliant. >That is the risk of using our product if we are not compliant, even if we perhaps >happen, or claim to be the best/greatest/fastest thing since sliced bread, and blow >away the '100% Compliant' version. At that point we aren't really Linux but a Linux >variant that is still opensource, uses the Linux metholdolgy, and albeit a close >dirivitive.. but still not really Linux.. No distribution is "Linux". That is the name of the kernel. Now it does happen that I would (personal preference here) have those utilities that are built to interface directly with the kernel (ifconfig, init, hdparm, ...) to be provided from the same location as the kernel. That way the dependancies between kernel and these applications would remain consistant. But.. they arn't. No big deal. Even these utilities (frequently I understand) come from BSD/netBSD/OpenBSD (whereever) distributions. Each distribution appears to be aimed at a specific user base, some larger than others. These distributions should not be penalized for providing additional support. After all, that is what they make their money from. Penalizing distributions for "compliancy" doesn't make sense - Would that also apply to a specialty hardware vendor that provides a driver? After all, it's not in the "standard"... The areas of non-compliancy are usually in specific bug patches, and drivers. Sometimes even in the compiler used. This IS up to the vendors. They have to support their customer base, and I have no problem with it. I do believe they should be documenting the uniqueness better. As far as I've seen, the distributions accept what are "best practices" from a variety of places, AT System V, BSD, Sun OS 4.x, Sun Solaris 2.x, whereever something worked, and worked well, it has been adopted. There were/are some "adjusting" to make it all be relatively seamless; and that is another place of "compliancy" as well as "if it works cleanly, and well then that is the direction to go". Linux runs in some systems that are NOT considered a "Unix" environment. It is still Linux even if it does have custom drivers, and applications. >Some companies are using 'open-source' monickers as a marketing ploy... As if >'open-source' means that it is some sort of industry standard.. And although the >freedom of open source in the
Patch: fix munmap on ARM
Linus, lkml,
The following patch is required so that munmap(0x8000, *) does not cause
ARM kernels to hang. The problem is that the machine vectors are at
virtual address 0. Unfortunately, when free_pgtables() is called, it
clears first level page tables starting at 0 in this case, and takes
out the machine vectors. This then results in an unrecoverable hang.
We already have FIRST_USER_PGD_NR to define the first entry in the pgd
which may be cleared, so we use this to clamp "start_index"
appropriately. The following patch does this. Tested on ARM.
There is only one concern that I can see with this patch - GCC may warn
about comparison always zero on architectures that define
FIRST_USER_PGD_NR to be zero.
--- orig/mm/mmap.c Tue Sep 5 22:22:12 2000
+++ linux/mm/mmap.c Sat Sep 30 14:24:23 2000
@@ -620,6 +620,8 @@
* old method of shifting the VA >> by PGDIR_SHIFT doesn't work.
*/
start_index = pgd_index(first);
+ if (start_index < FIRST_USER_PGD_NR)
+ start_index = FIRST_USER_PGD_NR;
end_index = pgd_index(last);
if (end_index > start_index) {
clear_page_tables(mm, start_index, end_index - start_index);
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
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/
We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
Bug squash number one. This should fix the 'it doesnt compile at all' bug. The other change here is that support for faster processors, that will catch out anyone using (abusing) udelay with extremely large values. If you get a link error or a module load error about bad_udelay let me know. Everything but x86 is probably in need of some small fixing by the port maintainers. Alan Stuff left to do for 2.2.18final - Support for >2GHz processors - Merge the S/390 stuff and make S/390 build again - Hunt bugs in the stuff so far. - Fix the megaraid (revert if need be) The S/390 stuff shouldnt touch the mainstream so from hereon in its simply a case of squashing bugs as they pop out until its ready to be 2.2.18. 2.2.18pre13 o Change udelay to use loops_per tick (Philipp Rumpf) | Otherwise we bomb out at 2GHz which isnt far enough | away with 1.4/1.6GHz stuff due out RSN o Fix drivers using big delays to use mdelay (me) o Fix drivers that used loops_per_sec (Philipp Rumpf, me) o Fix yamaha PCI sound SMP bug(Arjan van de Ven) o Change to preferred USB init fix(David Rees) o Fix rio fix (Arjan van de Ven) o Catch the VT but no mouse case in init/main.c (Arjan van de Ven) o Fix the 'which' compiler stuff (Horst von Brand, Peter Samuelson) | Can someone verify for me this works on Slackware and | on Caldera ? o Add devfs include. Devfs wont be going into 2.2 (Richard Gooch) but this again makes it easier to do 2.2/2.4 drivers. 2.2.18pre12 o Fix cyrix MTRR handling bug (IIZUKA Daisuke) o Fix ymfpci poll (me, Arjan) o Update radio-maestro, add Configure.help(Adam Tla/lka> o Fix rio/generic serial build bug(Marcelo Tossati) o USB build bug fix (Arjan van de Ven) o Fix missing ac97_codec.c return value (Arjan van de Ven) o Fix several warnings(Arjan van de Ven) o Made the PS/2 reconnect behaviour optional (me) | Its now 'psaux-reconnect' on the boot line o Allow for newer Hauppauge with 4 ports (Krischan Jodies) o Switch sound drivers from library to object (Arjan van de Ven) o Kill the not working ac97 lock on the 810 (me) o Automatically select older compilers for kernel builds on Debian and RH (Arjan van de Ven) o Start volumes higher on ac97, teach the driver (Rui Sousa) about 5bit and 6bit codec precision and use the mute bit. 2.2.18pre11 o Kill bogus codec_id assignment (Linus Torvalds) o Update codec init code to handle id right (me) o Fix dead/clashing define for NFS(Trond Myklebust) o Remove the find_vga crap from bttv (me) o Fix return on probe failure for cadet (Arjan van de Ven) o Add missing configure.help stuff from 2.4test (Alan Ford) o Fix inia100/megaraid define clash (Arjan van de Ven) o __xchg marked as taking volatiles (Arjan van de Ven) o Fix vwsnd warning in sound core (Arjan van de Ven) o wdt_pci driver should return -EIO on error (Arjan van de Ven) o Fix init_adfs_fs warning(Arjan van de Ven) o Fix the joystick driver option parsing (Arjan van de Ven) o Update mkdep to handle // commenting(Mike Klar) o Thunderlan driver typo fixes(Torben Mathiasen) o Add KX133/KT133 stuff to the AGP/DRM(Jeff Nguyen) o FIx multiple card bug in eepro driver (Aristeu Filho) o Initial YMF PCI native driver (Pete Zaitcev) | Based on Jaroslav's ALSA driver and I've tweaked it | a bit and maybe broken it 8) o Fix procfs unlink bugs (Willy Tarreau) o X.25 bugfix backport(Henner Eisen) o Fix incorrect free_dma on DMAless boxes (Boria) o Fix via audio driver merge (Nick Lamb) o Update plusb driver to 2.4 one (Greg Kroah-Hartman) o Put description info in wacom driver(Greg Kroah-Hartman) o Update both UHCI drivers to match 2.4test (Greg Kroah-Hartman) o Masquerade cleanup/warning fixes(Horst von Brand) 2.2.18pre10 o Add printk level to partition printk messages (me) o Fix bluesmoke address report/serialize (Andrea Arcangeli) o Add 2.4pre CPUID/MSR docs to 2.2.18pre (Adrian
Re: Standard Linux (Was What is up with Redhat 7.0?)
> 'Standard Linux' > Should the core kernel define a standard Linux?? To an extent. I will tell you the rules I try to follow for 2.2.x o Never add an ABI that is not standardised in 2.3.x by Linus o If drivers/ioctl interfaces are added to 2.2 first I try to be very fussy about them because an ABI is hardest to fix > And what does the community think of distros that veer from the standard? > Should the 'standard' be set in stone? I certainly don't want it set in stone. All of a sudden I then become some kind of multi-vendor approval service. That is wrong. > ie should we say that ALL distros have to ship with, and be compatible with the > standard kernel? If a distro has a patch that they want in the kernel, and the Compatible with yes, but without additional features - I think thats bad. The Linux Standard Base project is about defining a standard 'Linux' - which might btw equally be a fully compliant Linux emulation on FreeBSD for all it matters to application vendors. > (Side Note: had one of my sysadmins that needed to install a server with a DAC960 >Raid > controller.. The standard Linux kernel had no support for it so he had a choice. Im confused there. Leonard has been submitted DAC960 patches to the standard kernel first since 1.2. or so. - 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: What is up with Redhat 7.0?t
On Sat, Sep 30, 2000 at 10:57:57PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > > they were involved, but I have reason to doubt that they actually agreed. > > They did. O.k. let's disagree ;) > > This really is an affront on your side, twisting reality quite a bit - the > I noticed you carefully deleted the rest of that paragraph. Perhaps people I didn't carefully delete that paragraph - however, I also didn't want this thread to become a personal attacking flamewar either. I wasn't at all satisfied with your initial reaction and shoot back. I actually wanted this thread to dicsuss wether the kernel should care for specific unofficial versions of some software in some distros - I just think that no software project should work around bugs in software never release by the original authors just because it is used in a major distribution, where people have virtually no choice (if, like in debian, there were seperate gcc-2.95 and gcc-pre3 packages that could be used alternatively, this would be differemt, but AFAIK the redhat package management system is not able to provide for this). So let's die this thread, or at least the name-calling right now. I'll try as best as I can to keep the disucssion to the original, on-topic point only. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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: Standard Linux (Was What is up with Redhat 7.0?)
On Sat, 30 Sep 2000, Michael Peddemors wrote: > ie should we say that ALL distros have to ship with, and be compatible with the > standard kernel? If a distro has a patch that they want in the kernel, and the > mainstream kernel doesn't feel it belongs, should it be labeled differently? > Do we go with a Debian Linux, Redhat Linux, etc.. accepting that they are all > different, but from a common heritage Why not? Worked for BSD just fine. > or should there be a 'seal of approval' so that > a distro can indicate it is 100% linux mainstream, as in > SomeDistro Linux, '100% Linux Standard Compliant' Yeah... And then we'll have every marketdroid and his mom _really_ trying hard to get every patch into the main tree. Thanks, but no thanks. - 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.18pre12 mouse detection problem
> use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2 > mouse and do I want to install it, etc. If I tell it not to change > anything, the system comes up. However, the real mouse then misbehaves > badly, losing button-down events and being generally sluggish. > > Rebooting with 2.2.17, there are no problems. Ugghh. Ok 1. do you have any usb stuff compiled in or loaded as modules 2. can you see if an earlier one is broken In theory 2.2.18pre12 has the only actual change to mouse behaviour and its not capable of breaking it. But theory is obviously out to lunch at the moment - 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/
ramfs in 2.4.0-test6
I didn't try -test8 since it's LFS seems broken. But anyway, I was able to crash a machine using ramfs when I filled it up. I got "Kernel panic: attempted to kill init" on the console -- Lab tests show that use of micro$oft causes cancer in lab animals - 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.2.18pre12
> does not compile with gcc272. > > It complains about the line > > static __attribute__((unused)) void unused(void) > > gcc 2.95.2 does compile it. I dont have 272 around at the moment does static void __attribute__((unused)) work ? - 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: What is up with Redhat 7.0?t
> > Various people I associate with being senior in both glibc and gcc (people > > like Ulrich Drepper and Jeff Law) were involved in the compiler and glibc > > they were involved, but I have reason to doubt that they actually agreed. They did. > > to the temporary ABI in 2.95 first - whomever that was - I don't know, or > > on the gcc people who couldnt keep the ABI stable. > > This really is an affront on your side, twisting reality quite a bit - the I noticed you carefully deleted the rest of that paragraph. Perhaps people should look back in the archive and note why - 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: Standard Linux (Was What is up with Redhat 7.0?)
On Sat, Sep 30, 2000 at 02:39:00PM -0700, Michael Peddemors <[EMAIL PROTECTED]> wrote: > That RedHat Thread was degrading into a name calling match... And a pile of misunderstandings as well. > ie should we say that ALL distros have to ship with, and be compatible with the > standard kernel? Define compatible. Your FreeS/WAN does not make binaries compiled on your distro inherently incompatible with others. Of course, gnu/linux distributions are free to drop a lot of things (like the gnu prefix) and create something entirely non-standard. However, major distributions also have a responsibility. Also, what means "open" in this respect? Should redhat or suse be able to create a version of the linux kernel that runs ELF+ binaries and generates them by default under some circumstances? Requiring special redhat/suse packages to run them on other distros? This is what I feel RH is currently doing, and did in the past, although the past problems could have been simple bugs like in any other project. and the responsibility argument really only applies to the big players, not something like RTLinux. (I do agree with most of the unquoted parts of your mail, btw.) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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: Standard Linux (Was What is up with Redhat 7.0?)
On Sat, 30 Sep 2000, Marc Lehmann wrote: > However, I think attacking other free softwrae projects because of *bugs* > is just childish at this point - after all, this discussion was about > supporting distributions that - without technical reasons - make their > products incompatible to what one would call "standard linux", and that I > do not think that the kernel should support such doings. > That RedHat Thread was degrading into a name calling match... But it does have one core element that maybe should be discussed, and that can be a relevant and productive discussion for this list. 'Standard Linux' Should the core kernel define a standard Linux?? And what does the community think of distros that veer from the standard? Should the 'standard' be set in stone? ie should we say that ALL distros have to ship with, and be compatible with the standard kernel? If a distro has a patch that they want in the kernel, and the mainstream kernel doesn't feel it belongs, should it be labeled differently? Do we go with a Debian Linux, Redhat Linux, etc.. accepting that they are all different, but from a common heritage or should there be a 'seal of approval' so that a distro can indicate it is 100% linux mainstream, as in SomeDistro Linux, '100% Linux Standard Compliant' Thoughts?? I know our Linux Distro is non-conformant because of our FreeS/WAN and encryption patches.. Yes, we are still Linux, but I know we shouldn't get the '100% ...Compliant' label.. Of course, from a marketing standpoint, I would hate to carry that stigma, but I think it is prudent that our customers have the right to know that their experience with other Linux's may not be sufficient, or that down the road they may be forced to use us for support, or get/buy 'LinuxMagic' software rather than '100% Compliant' versions of the software if we choose to not be compliant. That is the risk of using our product if we are not compliant, even if we perhaps happen, or claim to be the best/greatest/fastest thing since sliced bread, and blow away the '100% Compliant' version. At that point we aren't really Linux but a Linux variant that is still opensource, uses the Linux metholdolgy, and albeit a close dirivitive.. but still not really Linux.. Some companies are using 'open-source' monickers as a marketing ploy... As if 'open-source' means that it is some sort of industry standard.. And although the freedom of open source in the development community means great things for all, the end consumer wants standards. Maybe it is time that standards, (And accepting patches or changes to the kernel while rejecting others IS a standard whether we call it such or not) are openly claimed to be such, even if those standards are dictated by Linus himself, the community at large by consensus, or a representing body. Either that or I see a very real possiblilty of fragmentation of the development of Linux products as the corporate needs start to dictate what 'Linux' is.. Oh, and don't get me wrong, fragmentation will happen as two people differ on what they think is best.. Otherwise we wouldn't have so many flavours of Unices out there too. Some guys at Berkely might still be dictating their thoughts of what is best.. and we would all be using it.. Linus?? I wouldn't mind hearing you thoughts on formally declaring a 'standard' on kernels..rather than an assumption that it is :> (Side Note: had one of my sysadmins that needed to install a server with a DAC960 Raid controller.. The standard Linux kernel had no support for it so he had a choice. Patch it, or use the RedHat version. Do we say that this controller is not supported by Linux, but is supported by RedHat Linux? Are we not then saying we have two different OS's??) Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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.17 --- extreme format string weirdness in /proc
On Sat, 30 Sep 2000, Nix wrote:
>Andries Brouwer <[EMAIL PROTECTED]> writes:
>
>> On Sat, Sep 30, 2000 at 03:09:10PM +0100, Nix wrote:
>>
>> > Yesterday, I noticed that netstat had stopped working on my 2.2.17 box
>> > The reason is fairly self-evident:
>> >
>> > : loki:/# cat /proc/net/dev
>> ...
>> > : lo:%lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu
>> > : eth0:%lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu
>>
>> This could be explained by a single-bit corruption of your kernel,
>> namely if the place where printk tests a format character against '%'
>> is broken. Maybe the '%' is bad, or maybe the comparison instruction.
>
>Agreed. /proc/{pid}/stat backs you up there too. %u is fine, only %lu is
>mangled by something.
>
>It's certainly an amusing failure; I'm surprised by how well everything
>runs with the system in this state; netstat and top fall over, uptime
>calculations go wrong, and ps and inndwatch complain. Everything else is
>happy as could be.
>
>
>Whatever it is it probably isn't memory error; I do lots of gcc
>compilations on this machine, and don't get nonrepeatable bootstrap
>comparison failures...
>
>I'll try pulling out some of the patches and modules (lm-sensors can go
>easily; reiserfs not so easily) and see what happens.
Check back a few weeks in the archives - I think this has to do with some
compiler issues where %lu isn't done because printk couldn't do the conversion.
I seem to remember that a patch was provided too...
--
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
-
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 Matti
Just FYI; I tried to reply to your mail (you know the topic) but your mailserver blocked me. I didn't ignore that mail. - 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: What is up with Redhat 7.0?
On Sat, Sep 30, 2000 at 01:20:58PM -0700, Ulrich Drepper <[EMAIL PROTECTED]> wrote: > > If you say so However, I am not sure that you (we?) can actually > > control it. > > You are excused this one and only time since I am fortunate enough to > never have met you but listen carefully now: And you are excused this once only to have only read what people have quoted instead of reading what I actually wrote: OTOH, [EMAIL PROTECTED] might get pressed into not doing incompatible changes, although I trust drepper to act truely honest. > > Well, I actually do think that this has happened with glibc-2.1. > > And this I take as personal insult. Who the f*ck do you think you are > to claim the right of making such a statement? Well, the glibc-2.1 on redhat disks acted differently than the glibc-2.1 in the cvs repository or on the ftp servers, but that does not mean that the actual glibc code is the culprit. Again, please read what I actually wrote, not only the parts that others have quoted. Thank you for doing that. > This is so completely insane that I really have not the slightest idea > how you can make Probably that's becausde I didn't write what you think I did write since you only read selected snippets of my mail. > whatsoever. If you cannot find anybody I demand a public apology from > you. VV. Really, there is no need to fight over misquoted mails. Please do calm down. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre12 mouse detection problem
Alan, I just jumped to 2.2.18pre12 from 2.2.17 final. Something's broken with mouse detection. My mouse is a Logitech Serial Mousman on ttyS0, and has been forever. A ps/2 port is present on the motherboard, but not in use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2 mouse and do I want to install it, etc. If I tell it not to change anything, the system comes up. However, the real mouse then misbehaves badly, losing button-down events and being generally sluggish. Rebooting with 2.2.17, there are no problems. Steve - 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: What is up with Redhat 7.0?
I really didn't want to make a comment on this stupid thread but now you are getting personal: > > > OTOH, [EMAIL PROTECTED] might get pressed into not doing incompatible > > > changes, > > > > We're doing no such thing. > > If you say so However, I am not sure that you (we?) can actually > control it. You are excused this one and only time since I am fortunate enough to never have met you but listen carefully now: I allow nobody to tell me what to do. Nobody from Red Hat ever tried to do this. If this would have been on the mind of somebody (which I doubt) this illusion would have been destroyed on the first day when I told them that this never would be an option. There are external entities (commercial and non-commercial) who try this, though, of course without success either. > > If we did this sort of thing, he would have been pressed into releasing > > glibc 2.2 in time. > > Well, I actually do think that this has happened with glibc-2.1. And this I take as personal insult. Who the f*ck do you think you are to claim the right of making such a statement? This is so completely insane that I really have not the slightest idea how you can make something like this up. Go and find somebody who is working on glibc to back up this "statement" and not some idiot like you who has no inside whatsoever. If you cannot find anybody I demand a public apology from you. -- ---. ,-. 1325 Chesapeake Terrace Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.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/
uhci bad, usb-uhci good in test9-pre7
In 2.4.0-test9-pre7, uhci module does not reliably. I have a Logitech N48 wheel mouse attached, it's the only USB device. I can use the mouse fine in X via /dev/input interface (except that input moule's reference count is still zero). But when I switch to text console (and maybe move the mouse) and switch back to X, the mouse is dead. Unplug+plug cures it until the next console switch. I have also a PS/2 mouse attached and I'm using it via gpm on text consoles (if this is of any importance). usb-uhci module seems to be OK. In 2.2.18pre12 backport, uhci seems to work also, it's only 2.4 that's broken at the first glance. USB controller is VIA KT133 onboard USB: 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) --- Meelis Roos ([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.2.18pre12
Hello, drivers/char/drm/r128_drv.c does not compile with gcc272. It complains about the line static __attribute__((unused)) void unused(void) gcc 2.95.2 does compile it. Greetings, Wolfgang Walter - 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.18pre12 usb module counts wrong?
> > recheck and found a strange thing: lsmod shows zero usage counts for usb > > modules while I'm actively using the mouse in X. > > Using the input device (dev/input/.. ) ? Yes, "mknod /dev/input/mice c 13 63" and X uses it happily. Just noticed that it's the same under 2.4.0-test9-pre7. > > input 3068 0 [mousedev usbmouse] > > This appears to be the problem, the others are all locked by being used by > another module --- Meelis Roos e-mail: [EMAIL PROTECTED] www:http://www.cs.ut.ee/~mroos/ - 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: What is up with Redhat 7.0?
On Sat, Sep 30, 2000 at 09:28:18PM +0200, Bernhard Rosenkraenzer <[EMAIL PROTECTED]> wrote: > > OTOH, [EMAIL PROTECTED] might get pressed into not doing incompatible > > changes, > > We're doing no such thing. If you say so However, I am not sure that you (we?) can actually control it. > If we did this sort of thing, he would have been pressed into releasing > glibc 2.2 in time. Well, I actually do think that this has happened with glibc-2.1. > > own people (e.g. from cygnus) who I really believe didn't support their > The opposite is the case. They didn't want to have to support a dead > branch (2.1/2.95). So they took a snapshot of gcc that is known to be broken, fixed it up a bit and released it as working code (from http://www.redhat.com/products/software/linux/rhl7_new_features.html): "GCC Compiler 2.96 GCC 2.96 allows for faster optimized code and more complete C++ support." This is neither true nor honest - there is no gcc compiler 2.96 (gcc is named gnu compiler colelction, btw!), and that their version is a seriously hacked non standard gcc snapshot, still, is alraedy causing quite a few bogus bug reports. It already forced the gcc maintainers to bump the internal version from 2.96 to 2.97. > > Redhat might just hack their libc to be redhat-7.0 compatible > That's what we'll do if any incompatible changes will be necessary - > fortunately glibc supports versioning. Yes. "Your product doesn't work? Our redhat libc works for your software - download it here. no, the compatitors are not gnu/linux compatible". Great future. Anyway, my pont *here* is that the kernel shouldn't explicitly support this marketing. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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.17 --- extreme format string weirdness in /proc
Andries Brouwer <[EMAIL PROTECTED]> writes:
> On Sat, Sep 30, 2000 at 03:09:10PM +0100, Nix wrote:
>
> > Yesterday, I noticed that netstat had stopped working on my 2.2.17 box
> > The reason is fairly self-evident:
> >
> > : loki:/# cat /proc/net/dev
> ...
> > : lo:%lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu
> > : eth0:%lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu
>
> This could be explained by a single-bit corruption of your kernel,
> namely if the place where printk tests a format character against '%'
> is broken. Maybe the '%' is bad, or maybe the comparison instruction.
Agreed. /proc/{pid}/stat backs you up there too. %u is fine, only %lu is
mangled by something.
It's certainly an amusing failure; I'm surprised by how well everything
runs with the system in this state; netstat and top fall over, uptime
calculations go wrong, and ps and inndwatch complain. Everything else is
happy as could be.
Whatever it is it probably isn't memory error; I do lots of gcc
compilations on this machine, and don't get nonrepeatable bootstrap
comparison failures...
I'll try pulling out some of the patches and modules (lm-sensors can go
easily; reiserfs not so easily) and see what happens.
--
`ERGOTISM is what you get if you overuse the word "therefore". Egotism
on the other hand is a form of "I" strain.' --- Paul 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: What is up with Redhat 7.0?t
On Sat, Sep 30, 2000 at 08:08:40PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > for Caldera, Transmeta, SuSE and others I expect. So I dont think you can > work on the basis they have any influence over me. The logic is not quite right, but tt's definitely another story indeed. > > the largest one, and they started the trend to monopolize the market at > > the cost of morality, ethics and free software. > > Which is why I think you are a nut, because your technical comments don't > match the above. Well, at least you acknowledge that I *also* made technical comments - you bluntly ignored them so far. > If I thought Red Hat was damaging free software I wouldnt be working for > them. I'd probably be working for another truely open source vendor of > which there are several. Sorry if you understood it that way - I certainly didn't want to attack you personally. What I was attacking is the technically (and in their consequences morally) unsound decisions redhat did as the first of the major gnu/linux distribs. Taken on it's own, redhat never did anything which is not "politically correct" or "was just a bug that has been fixed". However, that redhat claims to maintain linux, gcc and other major projects (which is absolutely untrue) is an open secret - just look at sources.redhat.com where redhat openly announces _their_ projects (like source navigator, binutils and gcc). > Various people I associate with being senior in both glibc and gcc (people > like Ulrich Drepper and Jeff Law) were involved in the compiler and glibc they were involved, but I have reason to doubt that they actually agreed. > to the temporary ABI in 2.95 first - whomever that was - I don't know, or > on the gcc people who couldnt keep the ABI stable. This really is an affront on your side, twisting reality quite a bit - the gcc releases certainly are backwards compatible (with regards to old gcc features), and, mind you, who broke the ABI? the gcc people Sorry, the only ones who actually broke anything major were redhat, this is a hard fact. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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: What is up with Redhat 7.0?
On Sat, 30 Sep 2000, Marc Lehmann wrote: > OTOH, [EMAIL PROTECTED] might get pressed into not doing incompatible > changes, We're doing no such thing. If we did this sort of thing, he would have been pressed into releasing glibc 2.2 in time. [EMAIL PROTECTED] did have some influence on choosing the glibc for 7.0 though, so we're confident no major changes will be necessary. > This might not > mean anything, however, since redhat was most probably ignoring their > own people (e.g. from cygnus) who I really believe didn't support their > decision. The opposite is the case. They didn't want to have to support a dead branch (2.1/2.95). > Redhat might just hack their libc to be redhat-7.0 compatible > later... That's what we'll do if any incompatible changes will be necessary - fortunately glibc supports versioning. LLaP bero - 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-2.2] Bonding Driver Enhancements + Security fix
Hello Thomas ! I've slightly enhanced the bonding code : - MII link checking with automatic slave enabling/disabling : Now the bond interface monitors all its MII-compliant slaves and disables the ones which have a dead link, and enables those which have a good one. The link check time defaults to 1 second but I've seen no overhead even at 30 ms. - slave release is now possible with a running bond - SMP-safe enslave/release/check/stats/xmit - fix a security bug which allowed anybody to enslave any active interface, thus making a local denial of service. - fix a potential infinite loop in bond_xmit() if no slave is useable. It now works very well for me, and the removal of a link becomes completely transparent now. On monday, I'll trunk it to an alteon switch. I've stressed the enslave/release code during "ping -f" and links up/down, but triggered absolutely no problem. I think it's stable enough to include it in 2.2.18 (Alan CC'ed for this). I'd like Constantine to test it on his servers because it should do exactly what he needed, and send us his feedback. The attached patch is against 2.2.17. Regards, Willy patch-bonding-2.2.17.gz
Re: What is up with Redhat 7.0?
On Fri, 29 Sep 2000, Alec Smith wrote: > Congratulations, you got further than I did. I couldn't even get that > disaster known as RH7.0 to even install. It died with some error about not > being able to detect free disk space after formatting the paritions... Please report this at http://bugzilla.redhat.com/bugzilla, along with details about your hardware - we didn't see this on any of our test machines, and neither did our beta testers. LLaP bero - 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: What is up with Redhat 7.0?
On Fri, 29 Sep 2000, David M. Rector wrote: > Has anyone tried Redhat 7.0 yet? Sure... > What a mess. Not quite... > 1) It would not compile stock kernels out of the box. (ends at > compress.S) with a fatal error. Either use the kernel compiler (kgcc) or patch the file to be compatible with newer gccs. > 2) Trying to compile the kernel source for 2.2.16 that comes with the > redhat disk (which is very different than the stock 2.2.16) causes my > system come to a screeching halt, no messages, no errors, crashed solid. I can't reproduce this... Do you get any helpful info from SysRq? Anything in syslog? LLaP bero - 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.18pre12 usb module counts wrong?
> recheck and found a strange thing: lsmod shows zero usage counts for usb > modules while I'm actively using the mouse in X. Using the input device (dev/input/.. ) ? > input 3068 0 [mousedev usbmouse] This appears to be the problem, the others are all locked by being used by another module > - 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] PCI detection in 2.2.x and 2.4.0
Hi.
I recently had a problem with linux 2.2.x and 2.4.0 oopsing early
in the boot process on a old pentium I had gotten hold of. printk
investigation showed the problem to be in the PCI detection code,
specifically the part where linux tries to go through the BIOS to
get the PCI settings. Picking 'Direct' (CONFIG_PCI_GODIRECT) make
the boot succeed where 'Any' had not.
This stumped me since the help text had led me to believe
otherwise: The help text states that if CONFIG_PCI_GOANY is set
linux will first try to detect the settings directly and go
through BIOS if this fails. The code first goes through BIOS to
get the settings, then gets them directly and then pick the
direct settings (if valid) otherwise the BIOS settings (if
valid).
The following patches fixes the code to follow the help text. I
am not sure if this is the correct fix, but I prefer it since it
makes my machine boot :)
Patches for both 2.4.0-test9-pre7 and 2.2.18pre10. Please comment.
2.4.0-test9-pre7:
--- linux-240test9-pre7-clean/arch/i386/kernel/pci-pc.c Mon Jul 31 21:03:10 2000
+++ linux/arch/i386/kernel/pci-pc.c Sat Sep 30 20:36:10 2000
@@ -962,15 +962,15 @@
struct pci_ops *bios = NULL;
struct pci_ops *dir = NULL;
+#ifdef CONFIG_PCI_DIRECT
+ if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
+ dir = pci_check_direct();
+#endif
#ifdef CONFIG_PCI_BIOS
- if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios( {
+ if ((pci_probe & PCI_PROBE_BIOS) && (!dir) && ((bios = pci_find_bios( {
pci_probe |= PCI_BIOS_SORT;
pci_bios_present = 1;
}
-#endif
-#ifdef CONFIG_PCI_DIRECT
- if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
- dir = pci_check_direct();
#endif
if (dir)
pci_root_ops = dir;
2.2.18-pre10:
--- linux-2.2.18pre10/arch/i386/kernel/bios32.c.org Mon Sep 25 16:37:03 2000
+++ linux-2.2.18pre10/arch/i386/kernel/bios32.c Mon Sep 25 16:39:28 2000
@@ -1267,15 +1267,15 @@
struct pci_access *bios = NULL;
struct pci_access *dir = NULL;
+#ifdef CONFIG_PCI_DIRECT
+ if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
+ dir = pci_check_direct();
+#endif
#ifdef CONFIG_PCI_BIOS
- if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios( {
+ if ((pci_probe & PCI_PROBE_BIOS) && (!dir) ((bios = pci_find_bios( {
pci_probe |= PCI_BIOS_SORT;
pci_bios_present = 1;
}
-#endif
-#ifdef CONFIG_PCI_DIRECT
- if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
- dir = pci_check_direct();
#endif
if (dir)
access_pci = dir;
--
Regards,
Rasmus([EMAIL PROTECTED])
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James
-
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: What is up with Redhat 7.0?t
> After all, even if you do work for redhat, the way redhat actively damages I work for Red Hat. I can pick up the phone any day of the week and work for Caldera, Transmeta, SuSE and others I expect. So I dont think you can work on the basis they have any influence over me. > same) and free softwrae projects JUST NOW should not leave you quietly > obeying (mind you, I am not the only one saying this). The big reasons I worked for Red Hat is that they don't do half proprietary things like some of the other folks and they have zero contractual control over what I choose to do. > Redhat certainly is not special compared to other distros. But redhat is > the largest one, and they started the trend to monopolize the market at > the cost of morality, ethics and free software. Which is why I think you are a nut, because your technical comments don't match the above. If I thought Red Hat was damaging free software I wouldnt be working for them. I'd probably be working for another truely open source vendor of which there are several. Various people I associate with being senior in both glibc and gcc (people like Ulrich Drepper and Jeff Law) were involved in the compiler and glibc choices, and being as close as possible to the standards (including the LSB draft) was an important guiding choice. That means shipping a compiler on advice of what will be compatible C++ wise with the future, and shipping a different compiler for the kernel. 2.95 is not compatible with egcs and you can take your wrath out on whoever moved to the temporary ABI in 2.95 first - whomever that was - I don't know, or on the gcc people who couldnt keep the ABI stable. The latter is pointless since they (probably rightfully) blame the C++ standardisation people for changing all the scoping rules. Alan - 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.18pre12 observations
> There are also many assembler warnings. Most talk about using %eax where > %ax was asked with l suffix. Also some indirect lcalls without *. Proably > not dangerous. These are intentional. Actually fixing them breaks building with older binutils 8( Alan - 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: Anyone working on multi-threaded core files for 2.4 ?
On Sat, 30 Sep 2000, James Cownie wrote: > I was expecting to take the Posix thread style viewpoint in which any > of the core dumping signals kill the _process_, so all of the threads > are necessarily dead thereafter since they have nowhere to live any > longer. Different model. Threads are _not_ parts of process, they are processes that happen to share a component (VM). - 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: What is up with Redhat 7.0?
On Sat, 30 Sep 2000, Marc Lehmann wrote: > Which still makes it an broken, experimental, unreleased and unofficial > compiler, with all the consequences I said. I agree about the "unreleased and unofficial" part, but it's not quite that broken and experimental. Everything that is shipped with Red Hat Linux (the distribution itself, Powertools, the extra CDs for Europe, etc) compiles and works without problems. Some programs needed patches, but that was much like updating from egcs 1.1.2 to gcc 2.95 - stricter checks for clean code. > > possible, but 2.95 isnt binary compatible with anything past or future and > > Not true, Why not? Its C++ part definitely isn't binary compatible with the previous (egcs 1.1.2) version and the future (gcc 2.96) version. The C part is, and so is the C part of the 2.96 compiler in Red Hat Linux 7. (We're still fully LSB compliant.) Also, it's GPL code, so anyone who wants to use it on other distributions can just take libstdc++; people providing binary-only software can include whatever version of libstdc++ they used with the binary and LD_PRELOAD it, or even link it statically. This is much like saying everyone who ships gcc 2.95.x is just trying to make everybody not use Red Hat Linux because we never shipped it, and therefore aren't shipping the libstdc++ used by 2.95.x. > but even if it were, 2.95 is compatible to all other distributions At the moment, yes. Once the next gcc is released, they'll start updating, and 2.95 would be incompatible. We don't break binary compatibility in minor releases (which is why even 6.2 still used egcs 1.1.2 even though gcc 2.95 was better), so we'll stick with a similar compiler throughout the 7.x series. Keeping 2.95 all the time wouldn't do much to increase binary compatibility when everyone else starts updating. > And the next gcc release will be worse, so where is the logic behind > choosing a compiler not compatibly to ANYTHING, except if trying to force > customers to stick to redhat? It was a purely technical decision, made by the compiler engineers at Cygnus and our development. We wanted ia64 support (using 2 different compilers for the 7.0 release, just on different architectures, wouldn't be nice), the new ia32 backend, as well as the more complete C++ implementation and ISO C99 compliance. We don't want to stick with 2.95 for the next year or two, so this was the only way to go. > gcc-2.96 (remember that this thing is not precisely defined as no such > release exists) produces worse code, So the new ia32 backend isn't better than the old one? Why? And if the old one was so much better, why was it replaced? > It would be better than a world where I cannot switch to another > distribution because vendors only support redhat and the binaries will not > run on the "competitors" linux' distros, forcing me to use redhat binutils, > redhat gcc, redhat libc and so on. Either link statically to libstdc++ (c++ is the only part of the compiler which is not fully ABI compatible), or just install the libstdc++-3-libc6.2-2-2.10.0.so file from Red Hat Linux, possibly even to a different directory with LD_PRELOAD or the likes set. This won't break anything. > Well, if redhat really tried to do this they failed miserably. OTOH, maybe > the redhat people doing that were drugged, because every child could > deduce that using an experimental snapshot that is has a non-fixed and > changing ABI will not help binary compatibility. When the decision was made (and I still think it was the right decision - especially because of ia64 compatibility), there was still some hope that gcc 2.96 would be ready by release time. If it's of any help, I can put up all potentially incompatible libraries as a plain tarfile somewhere, along with detailed instructions on how to use them for compatibility on other systems. Breaking compatibility has never been one of our intentions. LLaP bero - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre12 usb module counts wrong?
Just as I said that 2.2.18pre12 works well with my usb mouse, I did recheck and found a strange thing: lsmod shows zero usage counts for usb modules while I'm actively using the mouse in X. Module Size Used by ide-cd 23928 1 (autoclean) cdrom 27452 0 (autoclean) [ide-cd] parport_probe 3496 0 (autoclean) parport_pc 7596 1 (autoclean) lp 5484 0 (autoclean) parport 7700 1 (autoclean) [parport_probe parport_pc lp] lockd 37992 1 (autoclean) sunrpc 60772 1 (autoclean) [lockd] uhci 18836 0 (unused) mousedev3788 0 (unused) usbmouse1688 0 (unused) usbcore47208 0 [uhci usbmouse] input 3068 0 [mousedev usbmouse] via82cxxx_audio 9008 0 ac97_codec 7332 0 [via82cxxx_audio] es1371 24612 0 soundcore 2788 6 [via82cxxx_audio es1371] rtl813911908 1 --- Meelis Roos ([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: 2.2.17 --- extreme format string weirdness in /proc
On 30 Sep 2000 15:09:10 +0100, Nix <[EMAIL PROTECTED]> wrote: >: loki:/# cat /proc/net/dev >: Inter-| Receive| Transmit >: face |bytespackets errs drop fifo frame compressed multicast|bytespackets >errs drop fifo colls carrier compressed >: lo:%lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu >: eth0:%lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu %lu I have seen that symptom after kernel stack overflow. For some reason it starts printing the format strings instead of substituting them. It is one of my triggers for "oh, oh, what just went recursive?". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre12 observations
(no complaints about 2.2.18pre12 from real work - my usb mouse works well). * make xconfig gave 2 errors: ERROR - Attempting to write value for unconfigured variable (CONFIG_VIDEO_CPIA_USB). ERROR - Attempting to write value for unconfigured variable (CONFIG_USB_AUDIO). * there were many warning during compilation. The list of C warnings that are not about unused variables etc: floppy.c: In function `result': floppy.c:1168: warning: `status' might be used uninitialized in this function old_tulip.c: In function `tulip_probe': old_tulip.c:475: warning: suggest explicit braces to avoid ambiguous `else' old_tulip.c: In function `select_media': old_tulip.c:1542: warning: suggest explicit braces to avoid ambiguous `else' make[3]: Entering directory `/home/mroos/compile/22/linux/drivers/net/irda' /home/mroos/compile/22/linux/Rules.make:278: target `irport.o' given more than once in the same rule. make[2]: Entering directory `/home/mroos/compile/22/linux/fs/vfat' namei.c: In function `xlate_to_uni': namei.c:679: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type (there is a lot of unused variable and defined but not used things too but these are probably unimportant). There are also many assembler warnings. Most talk about using %eax where %ax was asked with l suffix. Also some indirect lcalls without *. Proably not dangerous. --- Meelis Roos ([EMAIL PROTECTED]) # # Automatically generated by make menuconfig: don't edit # # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set CONFIG_M586TSC=y # CONFIG_M686 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_1GB=y # CONFIG_2GB is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_OPTIMIZE=y CONFIG_PCI_OLD_PROC=y # CONFIG_MCA is not set # CONFIG_VISWS is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_BINFMT_JAVA is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_OTHER is not set CONFIG_APM=y CONFIG_APM_IGNORE_USER_SUSPEND=y CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y CONFIG_APM_DISPLAY_BLANK=y # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set CONFIG_APM_REAL_MODE_POWER_OFF=y # CONFIG_TOSHIBA is not set # # Plug and Play support # CONFIG_PNP=y CONFIG_PNP_PARPORT=m # # Block devices # CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_NS87415 is not set CONFIG_BLK_DEV_VIA82C586=y # CONFIG_BLK_DEV_CMD646 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_PARIDE_PARPORT=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_HD is not set # # Networking options # CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_FIREWALL=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_ROUTE_LARGE_TABLES is not set CONFIG_IP_ROUTE_NAT=y # CONFIG_IP_PNP is not set CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_NETLINK=y CONFIG_NETLINK_DEV=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_TRANSPARENT_PROXY=y CONFIG_IP_MASQUERADE=y CONFIG_IP_MASQUERADE_ICMP=y CONFIG_IP_MASQUERADE_MOD=y CONFIG_IP_MASQUERADE_IPAUTOFW=m CONFIG_IP_MASQUERADE_IPPORTFW=m CONFIG_IP_MASQUERADE_MFW=m CONFIG_IP_ROUTER=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_IP_ALIAS=y # CONFIG_ARPD is not
Re: What is up with Redhat 7.0?
On Sat, Sep 30, 2000 at 07:30:50PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > pgcc just didnt work. I got to the point where the kernel list stuff I had > actually had pgcc filtered. Because it was kernel crash pgcc this, kernel > wont compile pgcc that. Well, I grant that supporting pgcc is not an option for you, but most bugs with respect to pgcc have been fixed in the kernel since quite some time, mainly due to your work of fixing linux with respect to gcc-2.95 ;) However, I think attacking other free softwrae projects because of *bugs* is just childish at this point - after all, this discussion was about supporting distributions that - without technical reasons - make their products incompatible to what one would call "standard linux", and that I do not think that the kernel should support such doings. > Now we can't both be right so whats your point. He's entitled to have a > pathalogical hatred of Red Hat and I'm entitled to think he's a kook. I am talking about facts, while you keep ignoring facts and attack me on a very personal level. I've never been a "kook" on this list or elsewhere if you care to remember, and if you don't, a look into the list archives will show this (or use google to find more about me). If you disagree personally or technically with me you either say this in public or private or keep quiet. Attacking me over totally unrelated things is obviously some maneuver to distract people from the real, kernel-related question, and I have no idea why you are doing this... After all, even if you do work for redhat, the way redhat actively damages linux (the kernel), other distributions (who probably would like to do the same) and free softwrae projects JUST NOW should not leave you quietly obeying (mind you, I am not the only one saying this). Redhat certainly is not special compared to other distros. But redhat is the largest one, and they started the trend to monopolize the market at the cost of morality, ethics and free software. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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-test9 kernel header flaw
Jeff Garzik wrote: > > On 29 Sep 2000, H. Peter Anvin wrote: > > Followup to: <[EMAIL PROTECTED]> > > By author:Andries Brouwer <[EMAIL PROTECTED]> > > In newsgroup: linux.dev.kernel > > > > > > On Thu, Sep 28, 2000 at 03:41:41PM -0700, Jack Howarth wrote: > > > > > > > I find that the compile of gnome-utils fails as follows... > > > > > > > > In file included from /usr/include/linux/string.h:21, > > > > from /usr/include/linux/fs.h:23, > > > > from badblocks.c:43: > > > > > > Yes, a well-known phenomenon. > > > Kernel headers are to compile the kernel. > > > They are not for inclusion in user programs. > > > > > > > It really doesn't work in practice. There are enough things that > > really need it. > > > > We really need #ifdef __KERNEL__ (or is that #ifdef _LINUX now?) in > > the appropriate places. > > For specific driver ioctl interfaces and such, I agree... > > But gnome-utils? I don't think userspace needs to be looking at our > fs.h, string.h, etc. > It sounds like what's collapsing is badblocks, which probably uses ioctl interfaces. The main problem tends to be linux/fs.h, which is a huge file, some of which is indeed needed by userspace. It perpetually causes problems because someone included something non-userspace-safe in this file. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: What is up with Redhat 7.0?
> pgcc never was incompatible at binary level to gcc/egcs. pgcc just didnt work. I got to the point where the kernel list stuff I had actually had pgcc filtered. Because it was kernel crash pgcc this, kernel wont compile pgcc that. > That's simply a fact that you can't discuss away by attacking Lehmann > who is one of the main integration persons (gcc/egcs). And ? Im one of the main integrators of Linux 2.2 Now we can't both be right so whats your point. He's entitled to have a pathalogical hatred of Red Hat and I'm entitled to think he's a kook. Alan - 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 boots on Wildfire^WGS320!
On Sat, 30 Sep 2000, Andrea Arcangeli wrote: > On Sat, Sep 30, 2000 at 02:58:35PM -0300, Rik van Riel wrote: > > Both the current code and classzone will need some adjustments > > to work fine (as in: reasonably efficient) with NUMA. > > The exact thing I was talking about in my previous email is that > in classzone _all_ the cache lru are been intentionally designed > to be per node lists because NUMA memory balancing heuristics > needs that per-node info to be able to shrink from the "near" > node. Yeah, but this is a no-brainer change which can also be applied to the normal VM in 30 minutes. The real reason classzone could be interesting is that (combined with per-node memory_pressure info) it could be used to better balance memory pressure across nodes. Say that the local node got allocated a slightly too big job and the node next door has some spare capacity. In that case classzone could be used to make sure we'll: 1) use some memory from the other node instead of swapping 2) don't start swapping too much on the local node because it wouldn't be good Using information like memory_pressure difference and node distance, we can use classzone to use the NUMA beast a bit more efficiently. The only question here is, can we abstract this away in such a way that: 1) the code is clean and efficient 2) we don't do any of this complex stuff on "normal" machines Oh, and then there's of course the question of the pagecache_lock, but that's quite a separate issue from the memory allocation and balancing ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.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: What is up with Redhat 7.0?
On Sat, Sep 30, 2000 at 04:26:38PM +0100, Alan Cox wrote: > > > They released a supported ex-Cygnus people approved compiler. > > > > Which still makes it an broken, experimental, unreleased and unofficial > > compiler, with all the consequences I said. > > And didnt you write something called pgcc once. pgcc never was incompatible at binary level to gcc/egcs. > *PLONK* It's really absurd to attack Lehmann but I understand that's your job. RedHat workers should accept that they working for a company that works against the community. This does not mean that each individual worker works against the community but this fact is not really important. That's simply a fact that you can't discuss away by attacking Lehmann who is one of the main integration persons (gcc/egcs). Please read http://gcc.gnu.org/steering.html -- ciao - Stefan " A standard that defines "bc" but not "dc" is broken by design - SUS " Stefan TrabyLinux/ia32 fax: +43-3133-6107-9 Mitterlasznitzstr. 13 Linux/alphaphone: +43-3133-6107-2 8302 Nestelbach Linux/sparc http://www.hello-penguin.com Austriamailto:[EMAIL PROTECTED] Europe 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: Linux boots on Wildfire^WGS320!
On Sat, Sep 30, 2000 at 02:58:35PM -0300, Rik van Riel wrote: > Both the current code and classzone will need some adjustments > to work fine (as in: reasonably efficient) with NUMA. The exact thing I was talking about in my previous email is that in classzone _all_ the cache lru are been intentionally designed to be per node lists because NUMA memory balancing heuristics needs that per-node info to be able to shrink from the "near" node. Andrea - 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: AW: Linux kernel modules development in C++
Carsten Lang <[EMAIL PROTECTED]> writes: > Hi, > i don't want to start discussing the pros and cons of using C++ in kernel > development. > BUT: why do we blame people if they want to? several reasons 1) this thread keeps coming back on linux-kernel and various linux related usenet groups every couple of months or so. the people who ask are either slow learners or incapable of using dejanews. 2) someone always suggests putting in C++ but never wants to do the work to do it themselves. if they are so gung ho about the idea, they are free to fork off a variant kernel path. > It is possible to produce stable and good C++ modules (i have one for a > framegrabber device) it's also trivial to write very bad code in C++ since the compiler will try to do a lot of stuff behind the scenes. > and it is much easier to port already exsiting C++ > drivers from windows to linux. how many of these are out there? seriously, if you want to share driver code between windows and linux i see no reason not to write the whole thing in plain C in the first place. > So all i want to ask for is to give an easy way to people to > write their modules in C++. please, be my guest. no one is stopping you in this effort. > All we have to do is to change some few > lines in the kernel (the variable names "class", "public" and so on). > I'm VERY sure, that after this annoying problem is solved, we have > a C++ capsule which can be used by hardware manufacturers to > provide their Linux-drivers very fast by porting them from windows to > Linux by using a generic (C++) interface. > I don't need a very good and fast operating system, because of being > written in C, which is not supported by my hardware... > Somebody thought about that? > In my opinion we should not change the whole system to C++, > that would be very crazy (although i'm quite sure the quality of > Linux would increase), but I want to choose the language i'm > writing my device drivers in. > And if the changes are so ridiculous small, why don't we start doing > them no, why don't *you* start doing them. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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-scsi seems to inhibit mounting CD-ROMs
On Sat, 30 Sep 2000, Timothy Little wrote: > >> When using ide-scsi to access a CDRW writer, the recording process works > >> but I am not able to mount any CD-ROM media in that drive for reading. > > > >And here it's exactly the opposite :) > > > >If anyone has a Philips CDD-36xx drive and cdrecord works, a private email > >would be gladly welcome. > > I think I went through almost every combination before getting it > right. There are about 10 different ways to get it wrong that look > plausible. It is even possible to get it wrong *after* following the > documentation, so I did. My CD-RW is a Phillips CDD-3610. I'm not sure who the person wanting input from a Phillips user was so I hope that person is reading here. I got cdrecord working by NOT compiling in ATAPI CD ROM support, and by compiling ide-scsi emulation as built-in rather than modular. I have a "regular" atapi cdrom and the above Phillips drive, both on the secondary IDE interface. the cdrom ends up at /dev/scd0 and the cdrw ends up at /dev/scd1. - 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 boots on Wildfire^WGS320!
On Sat, 30 Sep 2000, Andrea Arcangeli wrote: > The allocator also mandatory needs part of classzone to be able > to make decent decisions. (putting the memory of different NUMA > nodes internally to a pgdat_t as different zones as it's been > proposed in linux-mm is a broken hack that can't work right) Um. Last I saw the idea was to simply have the fallback zonelist for allocations extend into other pgdats ... ;) > Infact saying that classzone have problems with NUMA looks silly > to me as it's the other way around as far I can see. Both the current code and classzone will need some adjustments to work fine (as in: reasonably efficient) with NUMA. If the classzone idea can be extended to NUMA with more readable (== maintainable) code than the standard zoned allocator, I'm all for having it integrated... (I'm not sure if classzone will have many benefits in "normal" setups, but with NUMA I can see the idea giving a lot more performance benefits) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.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: reading 1 hardsector size, not one block size
On Sat, Sep 30, 2000 at 12:14:56PM -0500, [EMAIL PROTECTED] wrote: > I do appreciate the many responses I've received to my initial query. I'm > glad that there *is* a solution that allows me read/write one hardsector, > and I'll be implementing such in my EFI partition code after the weekend. > > As for the issue of understanding a drive's true capacity and capabilities, > as opposed to what it "normally" returns, the two issues are orthogonal. > >From a hardware manufacturer's point of view, for diagnostics, support, and > other reasons, it would be nice to be able to access all capabilities that a > specific disk can provide. Accessing data beyond the reported last sector > for the purposes of partition table backup, diagnostic information, etc. > could be very valuable. > > Do I think that access to this "extra" disk space necessarily should be the > job of any file system layer? No. Should it be the job of the block layer, > to abstract the difference between SCSI and IDE, probably, so long as the > IDE and SCSI drivers can present the same interface for accessing the same > feature on both types of disks. In cases where IDE and SCSI disks differ, > then either a) the block layer supports one, and stub no-ops the other, or > b) it's left up to the IDE and SCSI drivers to present that feature. From > user-space, I'd prefer that a) be implemented, because I don't care if it's > a SCSI or IDE disk necessarily, but I'd want the same behavior from either. > > Clearly this part of the discussion needs to be held-over until 2.5. > > Again, thanks for everyone's comments. I'll be submitting a patch to enable > the EFI stuff in the near future. Ah, this sounds like you want a special feature (ioctl or whatever) that will allow accessing beyond the end of what Linux sees as the end of the device? I don't think this will ever happen - you can get Linux to see the whole space (even beyond what's reported by the drive), you can get Linux to see the extra space as a different device, but I don't believe it is reasonable to have an extra API for this kind of accesses. -- Vojtech Pavlik SuSE Labs - 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: reading 1 hardsector size, not one block size
I do appreciate the many responses I've received to my initial query. I'm glad that there *is* a solution that allows me read/write one hardsector, and I'll be implementing such in my EFI partition code after the weekend. As for the issue of understanding a drive's true capacity and capabilities, as opposed to what it "normally" returns, the two issues are orthogonal. >From a hardware manufacturer's point of view, for diagnostics, support, and other reasons, it would be nice to be able to access all capabilities that a specific disk can provide. Accessing data beyond the reported last sector for the purposes of partition table backup, diagnostic information, etc. could be very valuable. Do I think that access to this "extra" disk space necessarily should be the job of any file system layer? No. Should it be the job of the block layer, to abstract the difference between SCSI and IDE, probably, so long as the IDE and SCSI drivers can present the same interface for accessing the same feature on both types of disks. In cases where IDE and SCSI disks differ, then either a) the block layer supports one, and stub no-ops the other, or b) it's left up to the IDE and SCSI drivers to present that feature. From user-space, I'd prefer that a) be implemented, because I don't care if it's a SCSI or IDE disk necessarily, but I'd want the same behavior from either. Clearly this part of the discussion needs to be held-over until 2.5. Again, thanks for everyone's comments. I'll be submitting a patch to enable the EFI stuff in the near future. Thanks, Matt - 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: Bottom Handles/soft irqs/timer interrupts/SMP .....
> "anton" == Anton Blanchard <[EMAIL PROTECTED]> writes: >> > 2nd Question: Is there a sane way to queue an operation to be done in >> >each specific CPU? >> >> smp_call_function(). anton> The slab code was using smp_call_function until davem fixed it. anton> On sparc blocking interrupts does not block the reception of cpu cross anton> calls, so you cannot do anything like grab locks within a called function. Hi I have just dono a (2nd version of the patch). This version uses smp_call_function, but don't grab any lock inside. I sent the version to the list. It is also at: http://carpanta.dc.fi.udc.es/~quintela/kernel/2.4.0-test9-pre7/slab_02.patch Could you test if it is now safe in SMP Sparc also (/me has no SMP Sparc's around nor knoledge about them :( Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - 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: Bottom Handles/soft irqs/timer interrupts/SMP .....
On Fri, Sep 29, 2000 at 11:41:57PM +1100, Anton Blanchard wrote: > On sparc blocking interrupts does not block the reception of cpu cross > calls, so you cannot do anything like grab locks within a called function. So if you can't handle the IPI when you get it, set a flag and trap on the next sti. It certainly sounds like broken hardware to me and it can be worked around, can't it ? Maybe we should have a version of smp_call_function that uses softirqs (unless those are broken on sparc as well ;) ) and use the old version for the very performance-sensitive parts only ? Putting all tests for smp_call_function in the timer interrupt code doesn't make any sense at all to me. 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/
Re: reading 1 hardsector size, not one block size
On Sat, 30 Sep 2000, Vojtech Pavlik wrote: > That, again, is the IDE driver issue, not the FS layer's. If you want to Nope it is a SCSI issues also. If it was not Matt would not be asking the question. I have more of a heads up on what he was wanting because I spoke with him for about 45 min on the phone. > What has this to do with the rest? If you were going to try and jump the limits then you could only go so far. > Anyway, I believe that it'd be good to report the REAL geometry to the That wich we think is "REAL" is not, we can not always make it "REAL". > user, but also the faked one so that he sees what's happening. Possibly > allowing him to enable the full capacity say by using the kernel command > line. 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: 2.2.18pre12 fix for some distros
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >I'll play with the proposed which based fixes first, unless you have clever >ideas ? Include a script in scripts/kwhich that tells you the path to a certain binary. Below is a simple implementation. If you condense it you can even include it in the Makefile verbatim, though a seperate script seems cleaner to me. % ./kwhich unknowncc gcc272 gcc cc /usr/bin/gcc272 #! /bin/sh # kwhich 1.0 (C) 2000 Miquel van Smoorenburg # This program is GPLed if [ $# -lt 1 ] then echo "Usage: $0 cmd [cmd..]" >&2 exit 1 fi IFS=: for cmd in $* do for path in $PATH do if [ -x "$path/$cmd" ] then echo "$path/$cmd" exit 0 fi done done echo "$*: not found" >&2 exit 1 - 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: Bottom Handles/soft irqs/timer interrupts/SMP .....
Hello! > The slab code was using smp_call_function until davem fixed it. > > On sparc blocking interrupts does not block the reception of cpu cross > calls, so you cannot do anything like grab locks within a called function. Funny, are IPI really absolute nmi on sparc? I am honestly curious, for what purpose such IPIs were designed. Theay do not look useful. The fix is worth than problem was in any case. Waiting for timer under semaphore is not a good idea. Alexey - 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: What is up with Redhat 7.0?
On Sat, Sep 30, 2000 at 04:26:38PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > > Which still makes it an broken, experimental, unreleased and unofficial > > compiler, with all the consequences I said. > > And didnt you write something called pgcc once. Oh yes, of course while providing full binary compatibility. You can even mix & match objects from gcc and pgcc and agcc, no kidding. No distribution that used pgcc was ever binary incompatible to any other distribution, which is the point you keep ignoring. > *PLONK* No need to get personal ;) I had hoped you could keep to *technical* reasoning, though :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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: Anyone working on multi-threaded core files for 2.4 ?
On Sat, Sep 30, 2000 at 03:45:54PM +0100, James Cownie wrote: > Since the Villarreal patch exists and seems to do all that I wanted, I > don't propose to create a competing patch. > > Maybe you kernel gurus could point out any problems with the Villarreal > approach ? The patch assumes that all threads have the same pgrp (may be not true) When other threads do not actually coredump or have the same pgrp then the tcore structure will never be cleaned up as far as I can see, allowing a nice DoS attack of filling your memory completely. There was also another patch from Philip Gladstone for 2.2 BTW which did the same thing, but also had various problems. It worked around that particular trap by implementing the killing of other threads in kernel space (which is fine for Linux Threads, but limits other otherwise useful applications of clone threads). I think it had some other problems too. -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: What is up with Redhat 7.0?
> > They released a supported ex-Cygnus people approved compiler. > > Which still makes it an broken, experimental, unreleased and unofficial > compiler, with all the consequences I said. And didnt you write something called pgcc once. *PLONK* Alan - 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: What is up with Redhat 7.0?
On Sat, Sep 30, 2000 at 03:58:20PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > > a broken, experimental, unreleased compiler as if it were an official > > version. Worse, creating a maintainance nightmare for almost everybody by > > They released a supported ex-Cygnus people approved compiler. Which still makes it an broken, experimental, unreleased and unofficial compiler, with all the consequences I said. > possible, but 2.95 isnt binary compatible with anything past or future and Not true, but even if it were, 2.95 is compatible to all other distributions, a fine point easy to overlook. And the next gcc release will be worse, so where is the logic behind choosing a compiler not compatibly to ANYTHING, except if trying to orce customers to stick to redhat? > Want to complain about the USB code, flame the SuSE people who did the backport > work first, or perhaps you'd prefer to insult the volunteers who wrote most of > the USB code initially ? You somehow miss the relations, unfortunately. The usb code if self-contained and does not affect every program compiled with it. > Want to complain about the DRM/AGP code, then flame Xfree86 and > precision insight who did that work, many of them as volunteers .. Same here. > to flame SuSE, Conectiva, and especially Mandrake as well - all of them made > up of hardworking people trying to do what they think is best for Linux. I Indeed. So why does redhat so a remarkably *bad* job at the same? SuSE for example did *not* make their distribution incompatible to all others to try to tie customers to them. > *want* people to be prepared to ship new and innovative things. gcc-2.96 is not innovative, it simply does not exist, only in the unofficial redhat version. So the best thing one could say is that redhat forked their version of gcc. That's not innovative, that's a marketing trick: gcc-2.96 (remember that this thing is not precisely defined as no such release exists) produces worse code, has more bugs and is less compatible than 2.95, so where is the innovation? In copying marketing tricks from other companies? Very innovative for a gnu/linux company indeed. > you really want a world where you cannot buy a distribution with 2.2 that > has Reiserfs because Alan Cox refused to merge it with the mainstream ? It would be better than a world where I cannot switch to another distribution because vendors only support redhat and the binaries will not run on the "competitors" linux' distros, forcing me to use redhat binutils, redhat gcc, redhat libc and so on. This is *exactly* what is happening with redhat. Comparing this mess with an usb backport that does not at all cause these problems is missing the point completely. > > making redhat binary incompatibly to other linux distributions, therefore > > effectively forking gnu/linux in a way unseen before.(*) > > The fact this was done to help binary compatibility aside ? Well, if redhat really tried to do this they failed miserably. OTOH, maybe the redhat people doing that were drugged, because every child could deduce that using an experimental snapshot that is has a non-fixed and changing ABI will not help binary compatibility. > Let me metion the Nazi's. Now can the thread die ? Aren't you paid by redhat? ;-> -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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: What is up with Redhat 7.0?
> projects because they receive bogus bug reports because redhat shipped > a broken, experimental, unreleased compiler as if it were an official > version. Worse, creating a maintainance nightmare for almost everybody by They released a supported ex-Cygnus people approved compiler. Its not the compiler I would have chosen, since I prefer to use old compilers whenever possible, but 2.95 isnt binary compatible with anything past or future and egcs 1.1.2 isnt a good idea when you wish to build things like Mozilla or KDE2. I get a _lot_ of bug reports caused by people shipping broken kernels. The RH kernel patches are ones I went through and are mostly 2.2.17pre stuff needed for important fixes or stuff already tested Want to complain about the USB code, flame the SuSE people who did the backport work first, or perhaps you'd prefer to insult the volunteers who wrote most of the USB code initially ? Want to complain about the DRM/AGP code, then flame Xfree86 and precision insight who did that work, many of them as volunteers .. If you want to moan about shipping stuff like AGP/DRM, USB then remember to flame SuSE, Conectiva, and especially Mandrake as well - all of them made up of hardworking people trying to do what they think is best for Linux. I *want* people to be prepared to ship new and innovative things. If everyone complains about not shipping precise reference kernels then all of a sudden for 2.2 I become some annointed high power of approval for vendors - that is something I don't wish to be and which would be very very bad for Linux. Do you really want a world where you cannot buy a distribution with 2.2 that has Reiserfs because Alan Cox refused to merge it with the mainstream ? > making redhat binary incompatibly to other linux distributions, therefore > effectively forking gnu/linux in a way unseen before.(*) The fact this was done to help binary compatibility aside ? > (*) redhat is a major distribution and obviously now plays monopoly games. Its alt.conspiracy.kook time Let me metion the Nazi's. Now can the thread die ? - 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: Anyone working on multi-threaded core files for 2.4 ?
> Open question: whether or not to allow the remaining threads to > continue once the dump is completed, to abort them, or to signal > them. Probably should be run time configurable. I was expecting to take the Posix thread style viewpoint in which any of the core dumping signals kill the _process_, so all of the threads are necessarily dead thereafter since they have nowhere to live any longer. This approach is certainly what people migrating from other Unixen expect. (And, killing everyone is also what Linux threads implements). Andreas Dilger <[EMAIL PROTECTED]> was kind enough to point out that there have been a couple of recent postings (which I failed to find in my original search :-() which claim already to have implemented this, and provided patches :- Terje Malmedal <[EMAIL PROTECTED]>: http://marc.theaimsgroup.com/?l=linux-kernel=96355845607151=4 The Malmedal patch is not actually a patch to generate a multi-threaded core file, rather it generates a separate complete core file for each thread. I will not consider this further. Jason Villarreal <[EMAIL PROTECTED]>: http://marc.theaimsgroup.com/?l=linux-kernel=96931745912910=4 The Villarreal patch is exactly the kind of thing I was thinking of. It generates a standard multi-threaded ELF core file. I _think_, but would need to read it in more detail to be sure, that it assumes that all of the threads in the process are sent the signal which forced the dump. It then lets the last one out actually write the file including the thread specific data recorded by all of the previous threads to exit. Since the Villarreal patch exists and seems to do all that I wanted, I don't propose to create a competing patch. Maybe you kernel gurus could point out any problems with the Villarreal approach ? -- Jim James Cownie<[EMAIL PROTECTED]> Etnus, LLC. +44 117 9071438 http://www.etnus.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: Linux boots on Wildfire^WGS320!
On Wed, Sep 27, 2000 at 12:18:11PM +, Pavel Machek wrote: > Hi! > > > Well, I'm finally getting around to sending out this announcement. > > As can be seen on www.alphanews.net, we've managed to boot Linux on an > > AlphaServer GS320. The only caveats are that one of the CPUs was out of > > the system at the time (hence 31 CPUs, not 32), and that we haven't yet > > finished the DISCONTIGMEM support for Alpha (hence the 480GB of memory, > > instead of the real 256GB). Needless to say, things like kernel builds > > run _really_ fast. Heck, I could put all of my workstation (several > > I want that machine! Hmm, would it fit in my room? > > Do you know why different bogomips on cpu #2,3,4 were detected? Read calibrate_delay(). We only care about 8 bits and 1488.88 vs 1493.17 differ by about that. - 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: What is up with Redhat 7.0?
On Sat, Sep 30, 2000 at 03:07:49PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > > If you don't like this, I suggest you send mail complaining to RedHat. > > Customer complaints are going to be the only way that RH is going to be > > influenced not to play games like this > > Remind me next time I get to deal with crap from VA customers because VA > Talk about the pot calling the kettle black. I think you owe an apology Actually, it's redhat who owes an apology to the commnity at large for _already_ creating a maintainance hassle for gcc and other free software projects because they receive bogus bug reports because redhat shipped a broken, experimental, unreleased compiler as if it were an official version. Worse, creating a maintainance nightmare for almost everybody by making redhat binary incompatibly to other linux distributions, therefore effectively forking gnu/linux in a way unseen before.(*) However, I can understand that you have to support redhat and have probably lost your neutrality. (*) redhat is a major distribution and obviously now plays monopoly games. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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/
