Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wed, 30 May 2001, Vincent Stemen wrote: > On Wednesday 30 May 2001 15:17, Mike Galbraith wrote: > > On Wed, 30 May 2001, Vincent Stemen wrote: > > > On Wednesday 30 May 2001 01:02, Mike Galbraith wrote: > > > > On Tue, 29 May 2001, Vincent Stemen wrote: > > > > > On Tuesday 29 May 2001 15:16, Alan Cox wrote: > > > > > > > a reasonably stable release until 2.2.12. I do not understand > > > > > > > why code with such serious reproducible problems is being > > > > > > > introduced into the even numbered kernels. What happened to > > > > > > > the plan to use only the > > > > > > > > > > > > Who said it was introduced ?? It was more 'lurking' than > > > > > > introduced. And unfortunately nobody really pinned it down in > > > > > > 2.4test. > > > > > > > > > > I fail to see the distinction. First of all, why was it ever > > > > > released as 2.4-test? That question should probably be directed at > > > > > Linus. If it is not fully tested, then it should be released it as > > > > > an odd number. If it already existed in the odd numbered > > > > > development kernel and was known, then it should have never been > > > > > released as a production kernel until it was resolved. Otherwise, > > > > > it completely defeats the purpose of having the even/odd numbering > > > > > system. > > > > > > > > > > I do not expect bugs to never slip through to production kernels, > > > > > but known bugs that are not trivial should not, and serious bugs > > > > > like these VM problems especially should not. > > > > > > > > And you can help prevent them from slipping through by signing up as > > > > a shake and bake tester. Indeed, you can make your expectations > > > > reality absolutely free of charge, and or compensation > > > > what a bargain! > > > > > > > > X ___ ;-) > > > > > > > > -Mike > > > > > > The problem is, that's not true. These problems are not slipping > > > through because of lack of testers. As Alan said, the VM problem has > > > > Sorry, that's a copout. You (we) had many chances to notice. Don't > > push the problems back onto developers.. it's our problem. > > > > How is that a copout? The problem was noticed. I am only suggesting > that we not be in such a hurry to put code in the production kernels > until we are pretty sure it works well enough, and that we release > major production versions more often so that they do not contain 2 or > 3 years worth of new code making it so hard to debug. We probably > should have had 2 or 3 code freezes and production releases since > 2.2.x. As I mentioned in a previous posting, this way we do not have > to run a 2 or 3 year old kernel in order to have reasonable stability. I don't think you or I can do a better job of release management than Linus and friends, so there's no point in us discussing it. If you want to tell Linus, Alan et al how to do it 'right', you go do that. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
First of all I would like to say thanks to everyone. I didn't expect so many answer in so few time ( I got most of them directly in my mailbox) Anyway I've ordered right now the D-Link DFE-570 that seems the one with the best price/quality ratio so I can test it on the "battle field". Best Regards Fabio -- Fabio Massimo Di Nitto Debian GNU/Linux Testing/Unstable Kernel 2.4.5 Office for the Complication of Otherwise Simple Affairs PROUD TO BE MICROSOFT FREE! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM
On Wed, 30 May 2001, Marcelo Tosatti wrote: > On Wed, 30 May 2001, Mike Galbraith wrote: > > > On Wed, 30 May 2001, Rik van Riel wrote: > > > > > On Wed, 30 May 2001, Marcelo Tosatti wrote: > > > > > > > The problem is that we allow _every_ task to age pages on the system > > > > at the same time --- this is one of the things which is fucking up. > > > > > > This should not have any effect on the ratio of cache > > > reclaiming vs. swapout use, though... > > > > It shouldn't.. but when many tasks are aging, it does. > > What Rik means is that they are independant problems. Ok. > > > Excluding these guys certainly seems to make a difference. > > Sure, those guys are going to "help" kswapd to unmap pte's and allocate > swap space. > > Now even if only kswapd does this job (meaning a sane amount of cache > reclaims/swapouts), you still have to deal with the reclaim/swapout > tradeoff. > > See? Yes. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
one link missing for a directory
Hi, Sorry to disturb you. I tried to create a file system similar to ramfs on 2.2.14 kernel. I was able to insert it as a module and mount it to ram disk at /dev/ram0 at a mount point called /mnt. It gets mounted . But after mounting it the link count of directory /mnt becomes 1 and size becomes 0 which was previously 4096. What might be the problem. In my file system I have implemented only directory lookup and readdir functions. Which function takes care of the link count and the size of the directory. It would be very helpful for me if you could answer this so that I can proceed with my implementation. Thanks in advance, Regards, sathish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ip_masq_vdolive.c typo fix
Hi.
I found typo at ip_masq_vdolive.c.
2.2.{19,20-pre2} typo fix
--- linux.orig/net/ipv4/ip_masq_vdolive.c Thu May 31 13:29:14 2001
+++ linux/net/ipv4/ip_masq_vdolive.cThu May 31 13:30:47 2001
@@ -242,7 +242,7 @@
ports[i]))) {
return j;
}
- IP_MASQ_DEBUG(1-debug, "RealAudio: loaded support on port[%d]
= %d\n", i, ports[i]);
+ IP_MASQ_DEBUG(1-debug, "VDOlive: loaded support on port[%d] =
+%d\n", i, ports[i]);
} else {
/* To be safe, force the incarnation table entry to NULL */
masq_incarnations[i] = NULL;
<|> YOSHIMURA 'ramsy' Keitaro / Japan Linux Association
<|> mailto:[EMAIL PROTECTED]
<|> http://jla.linux.or.jp/index.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cs46xx oops in 2.4.5-ac4
This problem is still present in 2.4.5-ac5. Here's the latest oops: ksymoops 2.4.1 on i686 2.4.5-ac5. Options used -v /usr/src/linux-2.4.5-ac5/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac5/ (default) -m /usr/src/linux/System.map (default) Unable to handle kernel NULL pointer dereference at virtual address *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: cfa78e84 ebx: ecx: 0286 edx: cc961f2c esi: cc961f24 edi: cfa78e80 ebp: cc961f24 esp: cc961f08 ds: 0018 es: 0018 ss: 0018 Process sox (pid: 195, stackpage=cc961000) Stack: cfa78e78 cc96 c0105938 ffea cc9ce560 1000 cfa78df0 0001 cc96 cfa78e84 c0105aa8 cfa78e78 cfa78dc0 cc9ce580 d0c676b4 ffea cc9ce560 1000 b830 cfa78df0 c0267c40 Call Trace: [] [] [] [] [] [] Code: 89 13 51 9d 5b 5e c3 90 9c 58 fa 8b 4a 0c 8b 52 08 89 4a 04 >>EIP; c0111f54<= Trace; c0105938 <__down+4c/a8> Trace; c0105aa8 <__down_failed+8/c> Trace; d0c676b4 <[cs46xx].text.end+74/1e0> Trace; c0119baa Trace; c012dd86 Trace; c0106b27 Code; c0111f54 <_EIP>: Code; c0111f54<= 0: 89 13 mov%edx,(%ebx) <= Code; c0111f56 2: 51push %ecx Code; c0111f57 3: 9dpopf Code; c0111f58 4: 5bpop%ebx Code; c0111f59 5: 5epop%esi Code; c0111f5a 6: c3ret Code; c0111f5b 7: 90nop Code; c0111f5c 8: 9cpushf Code; c0111f5d 9: 58pop%eax Code; c0111f5e a: facli Code; c0111f5f b: 8b 4a 0c mov0xc(%edx),%ecx Code; c0111f62 e: 8b 52 08 mov0x8(%edx),%edx Code; c0111f65 11: 89 4a 04 mov%ecx,0x4(%edx) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wednesday 30 May 2001 15:17, Mike Galbraith wrote: > On Wed, 30 May 2001, Vincent Stemen wrote: > > On Wednesday 30 May 2001 01:02, Mike Galbraith wrote: > > > On Tue, 29 May 2001, Vincent Stemen wrote: > > > > On Tuesday 29 May 2001 15:16, Alan Cox wrote: > > > > > > a reasonably stable release until 2.2.12. I do not understand > > > > > > why code with such serious reproducible problems is being > > > > > > introduced into the even numbered kernels. What happened to > > > > > > the plan to use only the > > > > > > > > > > Who said it was introduced ?? It was more 'lurking' than > > > > > introduced. And unfortunately nobody really pinned it down in > > > > > 2.4test. > > > > > > > > I fail to see the distinction. First of all, why was it ever > > > > released as 2.4-test? That question should probably be directed at > > > > Linus. If it is not fully tested, then it should be released it as > > > > an odd number. If it already existed in the odd numbered > > > > development kernel and was known, then it should have never been > > > > released as a production kernel until it was resolved. Otherwise, > > > > it completely defeats the purpose of having the even/odd numbering > > > > system. > > > > > > > > I do not expect bugs to never slip through to production kernels, > > > > but known bugs that are not trivial should not, and serious bugs > > > > like these VM problems especially should not. > > > > > > And you can help prevent them from slipping through by signing up as > > > a shake and bake tester. Indeed, you can make your expectations > > > reality absolutely free of charge, and or compensation > > > what a bargain! > > > > > > X ___ ;-) > > > > > > -Mike > > > > The problem is, that's not true. These problems are not slipping > > through because of lack of testers. As Alan said, the VM problem has > > Sorry, that's a copout. You (we) had many chances to notice. Don't > push the problems back onto developers.. it's our problem. > How is that a copout? The problem was noticed. I am only suggesting that we not be in such a hurry to put code in the production kernels until we are pretty sure it works well enough, and that we release major production versions more often so that they do not contain 2 or 3 years worth of new code making it so hard to debug. We probably should have had 2 or 3 code freezes and production releases since 2.2.x. As I mentioned in a previous posting, this way we do not have to run a 2 or 3 year old kernel in order to have reasonable stability. > > Here are some of the problems I see: > > > > There was far to long of a stretch with to much code dumped into both > > the 2.2 and 2.4 kernels before release. There needs to be a smaller > > number changes between major releases so that they can be more > > thoroughly tested and debugged. In the race to get it out there they > > are making the same mistakes as Microsoft, releasing production > > kernels with known serious bugs because it is taking to long and they > > want to move on forward. I enjoy criticizing Microsoft so much for > > the same thing that I do not want to have to stop in order to not > > sound hypocritical :-). The Linux community has built a lot of it's > > reputation on not making these mistakes. Please lets try not to > > destroy that. > > > > They are disregarding the even/odd versioning system. > > For example: > > There was a new 8139too driver added to the the 2.4.5 (I think) kernel > > which Alan Cox took back out and reverted to the old one in his > > 2.4.5-ac? versions because it is apparently causing lockups. > > Shouldn't this new driver have been released in a 2.5.x development > > kernel and proven there before replacing the one in the production > > kernel? I haven't even seen a 2.5.x kernel released yet. > > > > Based on Linus's original very good plan for even/odd numbers, there > > should not have been 2.4.0-test? kernels either. This was another > > example of the rush to increment to 2.4 long before it was ready. > > There was a long stretch of test kernels and and now we are all the > > way to 2.4.5 and it is still not stable. We are repeating the 2.2.x > > process all over again. It should have been 2.3.x until the > > production release was ready. If they needed to distinguish a code > > freeze for final testing, it could be done with a 4th version > > component (2.3.xx.xx), where the 4 component is incremented for final > > bug fixes. > > Sorry, I disagree with every last bit. Either you accept a situation > or you try to do something about it. > > -Mike I am spending a lot of time testing new kernels, reporting bugs and offering suggestions that I think may improve on the stability of production kernels. Is this not considered doing something about it? It is necessary to point out where one sees a problem in order to offer possible solutions for improvement. - Vincent - To unsubscribe from this list: send the line
Re: How to know HZ from userspace?
Harald Welte writes:
> Is there any way to read out the compile-time HZ value of the kernel?
>
> I had a brief look at /proc/* and didn't find anything.
Look again, this time with a sick mind. Got your barf bag?
Kubys made me do it.
//
/***\
* Copyright (C) 1992-1998 by Michael K. Johnson, [EMAIL PROTECTED] *
* *
* This file is placed under the conditions of the GNU Library *
* General Public License, version 2, or any later version.*
* See file COPYING for information on distribution conditions.*
\***/
/* ...but Albert Cahalan wrote the really evil parts.
MKJ is only guilty for the macro */
/* Sets Hertz equal to the kernel's HZ, as seen in /proc. */
#include
#include
#include
#include
#include
#include
#ifndef HZ
#include /* htons */
#endif
long smp_num_cpus; /* number of CPUs */
#define BAD_OPEN_MESSAGE\
"Error: /proc must be mounted\n"\
" To mount /proc at boot you need an /etc/fstab line like:\n" \
" /proc /proc procdefaults\n" \
" In the meantime, mount /proc /proc -t proc\n"
#define STAT_FILE"/proc/stat"
static int stat_fd = -1;
#define UPTIME_FILE "/proc/uptime"
static int uptime_fd = -1;
#define LOADAVG_FILE "/proc/loadavg"
static int loadavg_fd = -1;
#define MEMINFO_FILE "/proc/meminfo"
static int meminfo_fd = -1;
static char buf[1024];
/* This macro opens filename only if necessary and seeks to 0 so
* that successive calls to the functions are more efficient.
* It also reads the current contents of the file into the global buf.
*/
#define FILE_TO_BUF(filename, fd) do{ \
static int local_n; \
if (fd == -1 && (fd = open(filename, O_RDONLY)) == -1) {\
fprintf(stderr, BAD_OPEN_MESSAGE); \
fflush(NULL); \
_exit(102); \
} \
lseek(fd, 0L, SEEK_SET);\
if ((local_n = read(fd, buf, sizeof buf - 1)) < 0) {\
perror(filename); \
fflush(NULL); \
_exit(103); \
} \
buf[local_n] = '\0';\
}while(0)
unsigned long Hertz;
static void init_Hertz_value(void) __attribute__((constructor));
static void init_Hertz_value(void){
unsigned long user_j, nice_j, sys_j, other_j; /* jiffies (clock ticks) */
double up_1, up_2, seconds;
unsigned long jiffies, h;
smp_num_cpus = sysconf(_SC_NPROCESSORS_CONF);
if(smp_num_cpus==-1) smp_num_cpus=1;
do{
FILE_TO_BUF(UPTIME_FILE,uptime_fd); sscanf(buf, "%lf", _1);
/* uptime(_1, NULL); */
FILE_TO_BUF(STAT_FILE,stat_fd);
sscanf(buf, "cpu %lu %lu %lu %lu", _j, _j, _j, _j);
FILE_TO_BUF(UPTIME_FILE,uptime_fd); sscanf(buf, "%lf", _2);
/* uptime(_2, NULL); */
} while((long)( (up_2-up_1)*1000.0/up_1 )); /* want under 0.1% error */
jiffies = user_j + nice_j + sys_j + other_j;
seconds = (up_1 + up_2) / 2;
h = (unsigned long)( (double)jiffies/seconds/smp_num_cpus );
/* actual values used by 2.4 kernels: 32 64 100 128 1000 1024 1200 */
switch(h){
case 30 ... 34 : Hertz = 32; break; /* ia64 emulator */
case 48 ... 52 : Hertz = 50; break;
case 58 ... 62 : Hertz = 60; break;
case 63 ... 65 : Hertz = 64; break; /* StrongARM /Shark */
case 95 ... 105 : Hertz = 100; break; /* normal Linux */
case 124 ... 132 : Hertz = 128; break; /* MIPS, ARM */
case 195 ... 204 : Hertz = 200; break; /* normal << 1 */
case 253 ... 260 : Hertz = 256; break;
case 393 ... 408 : Hertz = 400; break; /* normal << 2 */
case 790 ... 808 : Hertz = 800; break; /* normal << 3 */
case 990 ... 1010 : Hertz = 1000; break; /* ARM */
case 1015 ... 1035 : Hertz = 1024; break; /* Alpha, ia64 */
case 1180 ... 1220 : Hertz = 1200; break; /* Alpha */
default:
#ifdef HZ
Hertz = (unsigned long)HZ;/* */
#else
/* If 32-bit or big-endian (not Alpha or ia64), assume HZ is 100. */
Hertz = (sizeof(long)==sizeof(int) || htons(999)==999) ? 100UL : 1024UL;
#endif
fprintf(stderr, "Unknown HZ value! (%ld) Assume %ld.\n", h, Hertz);
}
}
//
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: How to know HZ from userspace?
Jonathan Lundell writes: > At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote: >>> If you now want to set those values from a userspace program / script in >>> a portable manner, you need to be able to find out of HZ of the currently >>> running kernel. >> >> Yes, but that's because the interfaces are broken. The decision has >> been that these values should be exported using the default HZ for the >> architecture, and that it is the kernel's responsibility to scale them >> when HZ != USER_HZ. I don't know if any work has been done in this >> area. Nope. HZ-derived values are not scaled in the /proc code. The real value is not available to apps. (Linus said so) People often change the HZ value. Thus we have problems. Maybe I'll post my disgusting hack. You _can_ get HZ out of /proc if you know where to look. >:-) > FWIW (perhaps not much in this context), the POSIX way is > sysconf(_SC_CLK_TCK) POSIX sysconf is pretty useful for this > kind of thing (not just HZ, either). That does not report the real value. It reports the default. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wednesday 30 May 2001 15:30, Rik van Riel wrote: > On Wed, 30 May 2001, Vincent Stemen wrote: > > The problem is, that's not true. These problems are not slipping > > through because of lack of testers. As Alan said, the VM problem has > > been lurking, which means that it was known already. > > Fully agreed, it went through because of a lack of hours > per day and the fact that the priority of developers was > elsewhere. > > For me, for example, the priorities have mostly been with > bugs that bothered me or that bothered Conectiva's customers. > > If you _really_ feel this strongly about the bug, you could > either try to increase the number of hours a day for all of I sure wish I could :-). > us or you could talk to my boss about hiring me as a consultant > to fix the problem for you on an emergency basis :) > The other two alternatives would be either waiting until > somebody gets around to fixing the bug or sending in a patch > yourself. > > Trying to piss off developers has adverse effect on all four > of the methods above :) > Why should my comments piss anybody off? I am just trying to point out a problem, as I see it, an offer suggestions for improvement. Other developers will either agree with me or they wont. Contributions are not made only through writing code. I contribute through code, bug reports, ideas, and suggestions. I would love to dive in and try to help fix some of the kernel problems but my hands are just to full right now. My comments are not meant to rush anybody and I am not criticizing how long it is taking. I know everybody is doing everything they can just like I am, and they are doing a terrific job. I am just suggesting a modification to the way the kernels are distributed that is more like the early versions that I hoped would allow us to maintain a stable kernel for distributions and production machines. - Vincent Stemen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtdram.c
this seemed to be a straight forward null pointer bug. i just copied the
error handling code from about 5 lines below what i added in.
-john martin
--- drivers/mtd/mtdram.c.orig Fri Feb 9 11:30:23 2001
+++ drivers/mtd/mtdram.cSat May 26 20:52:56 2001
@@ -115,6 +115,11 @@
mtd_info->size = MTDRAM_TOTAL_SIZE;
mtd_info->erasesize = MTDRAM_ERASE_SIZE;
mtd_info->priv = vmalloc(MTDRAM_TOTAL_SIZE);
+ if (!mtd_info->priv) {
+ kfree(mtd_info);
+ mtd_info = NULL;
+ return -ENOMEM;
+ }
memset(mtd_info->priv, 0xff, MTDRAM_TOTAL_SIZE);
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
On Tue, 29 May 2001, John Chris Wren wrote: > Should the man pages be changed to reflect reality, or select() fixed to > act like BSD? > BSD should be destroyed :) Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
Joel Becker wrote: > > On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote: > > FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK) > > > > POSIX sysconf is pretty useful for this kind of thing (not just HZ, either). > > Well, how many hundred things on Linux are available from /proc > but not from sysconf or the like? :-) Those hundert things which you either don't need or which should go to syslog or shouldn't be sysconf and nothing else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
On Wed, May 30, 2001 at 05:44:39PM -0700, Jonathan Lundell wrote:
> Lots. Maybe we oughta have /proc/sysconf/... (there's no reason
> sysconf() can't be a library reading /proc).
You don't mount proc?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
At 1:38 AM +0100 2001-05-31, Joel Becker wrote: >On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote: >> FWIW (perhaps not much in this context), the POSIX way is >>sysconf(_SC_CLK_TCK) >> >> POSIX sysconf is pretty useful for this kind of thing (not just HZ, either). > > Well, how many hundred things on Linux are available from /proc >but not from sysconf or the like? :-) > >Joel Lots. Maybe we oughta have /proc/sysconf/... (there's no reason sysconf() can't be a library reading /proc). -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote: > FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK) > > POSIX sysconf is pretty useful for this kind of thing (not just HZ, either). Well, how many hundred things on Linux are available from /proc but not from sysconf or the like? :-) Joel -- "There is no sincerer love than the love of food." - George Bernard Shaw http://www.jlbec.org/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote: > > If you now want to set those values from a userspace program / script in >> a portable manner, you need to be able to find out of HZ of the currently >> running kernel. >> > >Yes, but that's because the interfaces are broken. The decision has >been that these values should be exported using the default HZ for the >architecture, and that it is the kernel's responsibility to scale them >when HZ != USER_HZ. I don't know if any work has been done in this >area. FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK) POSIX sysconf is pretty useful for this kind of thing (not just HZ, either). -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [OFF-TOPIC] 4 ports ETH cards
> I've been working with these boards for a couple months and thought they > were great. However, now it turns out that they won't fit into our > systems too well (a little too long). Does anyone have knowledge of > another brand that has a (slightly) smaller form factor? I did some > checking on Pricewatch but wasn't able to find anything that fit our > needs. > > TIA, > > -Jeff The Adaptec Quartet64 boards worked ok for me with 2.2 and the Starfire driver. Not sure if they are smaller (shorter) than the D-Link but they sure are a lot shorter than the old Tulip-based Adaptec quad boards. They are a bit pricey, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Harald Welte <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > Is there any way to read out the compile-time HZ value of the kernel? > > Yes, but that's because the interfaces are broken. The decision has > been that these values should be exported using the default HZ for the > architecture, and that it is the kernel's responsibility to scale them > when HZ != USER_HZ. I don't know if any work has been done in this > area. Pardon, but that still seems broken to me. USER_HZ shouldn't matter to the architecture either. I would think that if 'echo 10 > /proc/foo/icmp_foo' sets a timeout of 10ms on alpha, it should also do so on x86, sparc, and mips. Why should the userspace implementation *ever* have to know the 'architecture HZ', the 'real HZ' or anything of the kind? Joel -- "I'm drifting and drifting Just like a ship out on the sea. Cause I ain't got nobody, baby, In this world to care for me." http://www.jlbec.org/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
Followup to: <[EMAIL PROTECTED]> By author:Harald Welte <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Is there any way to read out the compile-time HZ value of the kernel? > > I had a brief look at /proc/* and didn't find anything. > > The background, why it is needed: > > There are certain settings, for example the icmp rate limiting values, > which can be set using sysctl. Those setting are basically derived from > HZ values (1*HZ, for example). > > If you now want to set those values from a userspace program / script in > a portable manner, you need to be able to find out of HZ of the currently > running kernel. > Yes, but that's because the interfaces are broken. The decision has been that these values should be exported using the default HZ for the architecture, and that it is the kernel's responsibility to scale them when HZ != USER_HZ. I don't know if any work has been done in this area. -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 Oops at boot
Chris Mason wrote: > > On Wednesday, May 30, 2001 03:03:32 PM -0600 "D. Stimits" > <[EMAIL PROTECTED]> wrote: > > [ snip ] > > > RAMDISK: Compressed image found at block 0 > > Freeing initrd memory: 249k freed > > VFS: Mounted root (ext2 filesystem). > > Red Hat nash version 3.0.10 starting > > VFS: Mounted root (ext2 filesystem) readonly. > > change_root: old root has d_count=2 > > Trying to unmount old root ... <1>Unable to handle kernel NULL pointer > > dereference at virtual address 0010 > > printing eip: > > Can't say for sure without the oops decoded through ksymoops, but this > looks like the oops in rd_ioctl fixed by 2.4.5-ac3 and higher. I think the > following patch (taken from ac3) will be sufficient: > > -chris > > --- linux.vanilla/fs/block_dev.cSat May 26 16:53:17 2001 > +++ linux.ac/fs/block_dev.c Mon May 28 16:10:59 2001 > @@ -603,6 +602,7 @@ > if (!bdev->bd_op->ioctl) > return -EINVAL; > inode_fake.i_rdev=rdev; > + inode_fake.i_bdev=bdev; > init_waitqueue_head(_fake.i_wait); > set_fs(KERNEL_DS); > res = bdev->bd_op->ioctl(_fake, NULL, cmd, arg); I'm just verifying that this one change was sufficient to allow booting from a hard disk install. I'm still trying to figure out why "make bzdisk" is failing, I will try the ac5 patch next. Thanks, D. Stimits, [EMAIL PROTECTED] PS: Is it possible to read a floppy image directly (for example, after dd to a file), and tell if it is overrunning its maximum size limit? For example, the partition records always end with 55 AA, is there something I can look for to determine if a floppy image has gone too far? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to know HZ from userspace?
Hi! Is there any way to read out the compile-time HZ value of the kernel? I had a brief look at /proc/* and didn't find anything. The background, why it is needed: There are certain settings, for example the icmp rate limiting values, which can be set using sysctl. Those setting are basically derived from HZ values (1*HZ, for example). If you now want to set those values from a userspace program / script in a portable manner, you need to be able to find out of HZ of the currently running kernel. -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Only 5 undocumented configuration symbols left
The current list of symbols with missing help is very short. Here it is: PPC port: CONFIG_BLK_DEV_MPC8xx_IDE CONFIG_IRQ_ALL_CPUS CONFIG_USE_MDIO CRIS port: CONFIG_ETRAX_FLASH_BUSWIDTH CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C Let's finish this off, people! -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke, "A Treatise Concerning Civil Government" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
> > drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn > > 'DoC_Probe' calling init fn 'doccheck' > > Strictly speaking, not actually a bug. DoC_Probe() itself is only ever > called from __init code. But it's probably not worth trying to make the > checker notice that situation - I've fixed it anyway by making DoC_Probe() > __init too, which saves a bit more memory. Thanks. It's a space/performance bug, though, right? From the original mail: 1. The best case: the caller should actually be an __init function as well. This is a performance bug since it won't be freed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
On Wed, 30 May 2001, Michael H. Warfield wrote: [snip] > Just got three of these suckers and I'm about to order a bunch > more (happy camper)... yes the Dlink DFE570-TX is a very nice card indeed. [snip] > Because the D-Link cards were less than half of the nearest > competitor [ < $180 vs > $360 for others and Compac was > $2400! ] I > ordered only three not knowing for sure if they would work. Turned on > the tulip driver and them suckers fired right up. Now I know they work, > stock, right out of the box, and I can order a bunch more for the lab > I'm working with. I use those cards in all routers here and they work extremely well. But I don't use the standard vanilla tulip driver that's in the official kernel. I use an optimized version that handled high traffic volumes much better, it decreases the interrupt-load quite a lot. (this driver is about to be merged with the standard tulip driver IIRC) I havn't had any problems with these cards so I can really recommend them. /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reclaim dirty dead swapcache pages
On Thu, 31 May 2001, J . A . Magallon wrote: > > On 05.30 Marcelo Tosatti wrote: > > > > > > Its at > > http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.5ac4/reapswap.patch > > > > Please test. > > > > Which kind of test, something like the gcc think I posted recently ? I don't remember that, sorry. What was it again? > Just stress vm, fill swap, and try to do it again ? For example. I would _prefer_ tests non artifical tests, though. (ie not the kind of workloads where tasks are trying to consume all available resources all the time) Still, any kind of report is welcome, of course. Thanks a lot! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
"Michael H. Warfield" wrote: > > On Wed, May 30, 2001 at 06:34:16PM -0300, Harald Welte wrote: > > On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: > > > Hi all, > > > sorry for the offtopic msg. > > > > > > Can someone point me to a 4 ports fast/eth card solution for linux? > > > D-Link DFE-570 has a reasonable pricing and is well supported by the > > tulip driver > > Just got three of these suckers and I'm about to order a bunch > more (happy camper)... > > > > I found some cards based on the DEC 21*4* chips but when > > > I asked for more details I got a strange answer from the reseller > > > like that this card is able to work only half-duplex and the chip has > > > only one mac-address for the 4 eth cards (really strange). > > > nah. And even if so, you can always change the mac-address using ifconfig. > > Each D-Link card has four MAC addresses (sequential). I doubt > other manufactures are any different. > > > What the guy most likely wanted to say, is that there is only one EEprom > > containing all mac adresses for the four tulip chips, which I have seen > > on multiple boards > > What the guy was doing was having a bad case of optical rectitus. > That would be typical of a "reseller" (AKA Salesman). Most would not > even have a CLUE that the cards were based on the tulip chipset / driver. > > Because the D-Link cards were less than half of the nearest > competitor [ < $180 vs > $360 for others and Compac was > $2400! ] I > ordered only three not knowing for sure if they would work. Turned on > the tulip driver and them suckers fired right up. Now I know they work, > stock, right out of the box, and I can order a bunch more for the lab > I'm working with. > I've been working with these boards for a couple months and thought they were great. However, now it turns out that they won't fit into our systems too well (a little too long). Does anyone have knowledge of another brand that has a (slightly) smaller form factor? I did some checking on Pricewatch but wasn't able to find anything that fit our needs. TIA, -Jeff -- Jeff Golds [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Remaining undocumented Configure.help symbols
Harald Welte <[EMAIL PROTECTED]>: > On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote: > > > CONFIG_NET_CLS_TCINDEX > > If you say Y here, you will be able to classify outgoing packets > according to the tc_index field of the skb. You will want this > feature if you want to implement Differentiates Services useing > sch_dsmark. If unsure, say Y. > > This code is also available as a module called cls_tcindex.o ( = code > which can be inserted in and removed from the running kernel > whenever you want). If you want to compile it as a module, say MM > here and read Documentation/modules.txt Looks good. > > CONFIG_NET_SCH_INGRESS > > If you say Y here, you will be able to police incoming bandwidth > and drop packets when this bandwidth exceeds your desired rate. > If unsure, say Y. > > This code is also available as a module called cls_tcindex.o ( = code > which can be inserted in and removed from the running kernel > whenever you want). If you want to compile it as a module, say MM > here and read Documentation/modules.txt I'm going to assume that the cls_tcindex.o in the second entry is a cut'n'paste error and should read sch_ingress.o. Should the CLS_POLICE entry, then, read like this? Traffic policing (needed for in/egress) CONFIG_NET_CLS_POLICE Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reclaim dirty dead swapcache pages
On 05.30 Marcelo Tosatti wrote: > > > Its at > http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.5ac4/reapswap.patch > > Please test. > Which kind of test, something like the gcc think I posted recently ? Just stress vm, fill swap, and try to do it again ? -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac4 #1 SMP Wed May 30 00:17:45 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac5
On 05.30 Alan Cox wrote: > > 2.4.5-ac5 > o Move the pagecache and pagemap_lru_lock to (Andrea Arcangeli) > different cache lines Nice bit. One other bit from aa I think perhaps is usefull for SMP (don't understand fully the difference, but if it makes cache usage better...) is 00_pagetable-fast-2. And one other thing (that has not appeared on the list again) is the patch for single-copy-pipes. I have been using it since it was out on ac kernels without problems (well, a small one in the beginning). Both attached (against 2.4.5-ac5). -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac4 #1 SMP Wed May 30 00:17:45 CEST 2001 i686 patch-sc-pipe.bz2 patch-pgtable-fast.bz2
Makefile patch for cscope and saner Ctags
The following patch generates saner Ctags and will build cscope output. It's against 2.4.5 --- Makefile.oldMon May 28 22:44:01 2001 +++ MakefileWed May 30 17:50:01 2001 @@ -334,11 +334,32 @@ # Exuberant ctags works better with -I tags: dummy - CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "-I __initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ + CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "--sort=no -I +__initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ ctags $$CTAGSF `find include/asm-$(ARCH) -name '*.h'` && \ - find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 2 -maxdepth 2 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 3 -maxdepth 3 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 4 -maxdepth 4 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 5 -maxdepth 5 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ find $(SUBDIRS) init -name '*.c' | xargs ctags $$CTAGSF -a + mv tags tags.unsorted + LC_ALL=C sort -k 1,1 -s tags.unsorted > tags + rm tags.unsorted +cscope: dummy + find include/asm-$(ARCH) -name '*.h' >cscope.files + find include $(SUBDIRS) init -type f -name '*.[ch]' \ + | grep -v include/asm- | grep -v include/config >> cscope.files + cscope -b -I include + + ifdef CONFIG_MODULES ifdef CONFIG_MODVERSIONS MODFLAGS += -DMODVERSIONS -include $(HPATH)/linux/modversions.h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
On Wed, May 30, 2001 at 10:49:18PM +0100, Alan Cox wrote:
> > The problem is only there if you specify a directory for the linked to
> > component.
> >
> > [marcus@wine /tmp]$ strace -f ln -s fupp/berk xxx
> > execve("/bin/ln", ["ln", "-s", "fupp/berk", "xxx"], [/* 39 vars */]) = 0
> > ... ld stuff ... locale stuff ...
>
> bash-2.04$ ln -s foo/frob eep
> bash-2.04$ ls -l eep
> lrwxrwxrwx1 alan users 8 May 30 22:19 eep -> foo/frob
*sigh*
I just rebooted and it is no longer reproducable.
Sorry for the confusion caused.
Ciao, Marcus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
On Wed, May 30, 2001 at 06:34:16PM -0300, Harald Welte wrote: > On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: > > Hi all, > > sorry for the offtopic msg. > > > > Can someone point me to a 4 ports fast/eth card solution for linux? > D-Link DFE-570 has a reasonable pricing and is well supported by the > tulip driver Just got three of these suckers and I'm about to order a bunch more (happy camper)... > > I found some cards based on the DEC 21*4* chips but when > > I asked for more details I got a strange answer from the reseller > > like that this card is able to work only half-duplex and the chip has > > only one mac-address for the 4 eth cards (really strange). > nah. And even if so, you can always change the mac-address using ifconfig. Each D-Link card has four MAC addresses (sequential). I doubt other manufactures are any different. > What the guy most likely wanted to say, is that there is only one EEprom > containing all mac adresses for the four tulip chips, which I have seen > on multiple boards What the guy was doing was having a bad case of optical rectitus. That would be typical of a "reseller" (AKA Salesman). Most would not even have a CLUE that the cards were based on the tulip chipset / driver. Because the D-Link cards were less than half of the nearest competitor [ < $180 vs > $360 for others and Compac was > $2400! ] I ordered only three not knowing for sure if they would work. Turned on the tulip driver and them suckers fired right up. Now I know they work, stock, right out of the box, and I can order a bunch more for the lab I'm working with. > > Thanks a lot > > Fabbione > > -- > Live long and prosper > - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
Ronald Bultje writes: > On 30 May 2001 14:58:57 -0500, Vincent Stemen wrote: > > There was a new 8139too driver added to the the 2.4.5 (I think) kernel > > which Alan Cox took back out and reverted to the old one in his > > 2.4.5-ac? versions because it is apparently causing lockups. > > Shouldn't this new driver have been released in a 2.5.x development > > kernel and proven there before replacing the one in the production > > kernel? I haven't even seen a 2.5.x kernel released yet. > > If every driver has to go thorugh the complete development cycle (of 2+ > years), I'm sure very little driver writers will be as motivated as they > are now - it takes ages before they see their efforts "rewarded" with a > place in the kernel. > The ideal case is that odd-numbered kernels are "for testing" and > even-numbered kernels are stable. However, this is only theory. In > practice, you can't rule out all bugs. And you can't test all things for > all cases and every test case, the linux community doesn't have the > manpower for that. And to prevent a complete driver development cycle > taking 2+ years, you have to compromise. > > If you would take 2+ years for a single driver development cycle, nobody > would be interested in linux since the new devices would only be > supported by a stable kernel two years after their release. See the > point? To prevent that, you need to compromise. and thus, sometimes, you > have some crashes. I agree with everything you say up till this point, but you are arguing against a point I never made. First of all, bugs like the 8139too lockup was found within the first day or two of release in the 2.4.3 kernel. Also, most show stopper bugs such as the VM problems are found fairly quickly. Even if it takes a long time to figure out how to fix them, I do not think they should be pushed on through into production kernels until they are until they are fixed. I already said that I do not expect minor bugs not to slip through. However, if they are minor, they can usually be fixed quickly once they are discovered and it is no big deal if they make it into a production kernel. > That's why there's still 2.2.x - that's purely stable > and won't crash as fast as 2.4.x, but misses the "newest > cutting-edge-technology device support" and "newest technology" (like > new SMP handling , ReiserFS, etc... But it *is* stable. > The reason I suggested more frequent major production releases is so that you don't have to go back to a 2 or 3 year old kernel and loose out on years worth of new features to have any stability. One show stopper bug like the VM problems would not be as much of a problem if there was a stable production kernel that we could run that was only 4 or 6 months old. > > Based on Linus's original very good plan for even/odd numbers, there > > should not have been 2.4.0-test? kernels either. This was another > > example of the rush to increment to 2.4 long before it was ready. > > There was a long stretch of test kernels and and now we are all the > > way to 2.4.5 and it is still not stable. We are repeating the 2.2.x > > process all over again. > > Wrong again. > 2.3.x is for development, adding new things, testing, adding, testing, > changing, testing, etc. Which is the same point I made. > 2.4-test is for testing only, it's some sort of feature freeze. Agreed. My only point here was that it suggests that there are only minor bugs left to be solved before the production release by setting the version to 2.4-test. That is one of the reasons I made the suggestion to keep it in the 2.3 range, since there were actually serious VM problems still upon the production 2.4 release. > 2.4.x is for final/stable 2.4. > It's a standard *nix development cycle. That's how everyone does it. My point exactly. > > Regards, > > Ronald Bultje - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
On Wed, 30 May 2001, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn > > 'DoC_Probe' calling init fn 'doccheck' > > Strictly speaking, not actually a bug. DoC_Probe() itself is only ever > called from __init code. But it's probably not worth trying to make the > checker notice that situation - I've fixed it anyway by making DoC_Probe() > __init too, which saves a bit more memory. Thanks. Anything that's only called or used by functions marked init is a candidate for being marked init. I suspect there's still quite a bit out there that meets this description. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Acpi] RE: [patch]: ide dma timeout retry in pio
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Diefenbaugh, Paul S > > Chris/All: > > I think your assumptions are correct. I'm guessing that IDE DMA > activity is > not being properly handled when the CPU is in C3, resulting in memory (and > therefore file system) corruption. We haven't seen corruption on our > development systems, but this is probably due to the fact that we don't > explicitly enable IDE DMA transfers (?). > > I'm concerned that the CPU is being put into C3 during what appears to be > times of high bus mastering activity. The default policy (prpolicy.c) is > configured to only use C3 when bus mastering (BM_STS) is silent for 4 or > more 'quantums'. You can see if this is working by causing disk activity > while cat'ing the file '/proc/acpi/processor/0/status': the C3 counter > should not be incrementing (or not by much, anyway). H I'll have to look at this a bit more but you can also keep from C3 *and* C2 states by not having an idle CPU. For instance "./setiathome -verbose -nice 19" Prevents the C3 state quite nicely! :-) > > The C3 handler should block bus master activity while the CPU is > in C3. DMA > activity (writes) during C3 would result in cache-incoherency > (since the CPU > is not snooping) and thus memory corruption. The idea is to block bus > mastering activity while in C3 (ARB_DIS), but allow the CPU to wakeup > whenever bus mastering is requested (BM_RLD). I'm betting that DMA is > happening during C3 resulting in fs corruption. *or* that the bus master request wakes up the cpu but for some reason the requestor is not granted the bus? So that you end up with DMA timeouts and the FS gets corrupt because no data is getting written? > > To verify if C3 is really the culprit we should try disabling its use on a > vulnerable system. I'd recommend mapping the C3 handler to use > C2 instead, > which could be done by modifying the switch statement in pr_power_idle() > within prpower.c (see below). Note that we'll still be setting BM_RLD for > C3's during pr_power_activate_state(), but this shouldn't be an issue. > [example code snipped] > > Could somebody give this a try and let me know? > I've already done something very similar to this. I set "processor->power.state[PR_C3].is_valid" to false near the end of pr_power_set_default_policy(). And did not have any hang/corruption problems. The test I was using was three "find / >/dev/null" instances running 10-15 seconds apart. Without C3 disabled it would hang/crash within the first few minutes. With this disabled it ran fine all the way thru. Would it help if I tried this as you suggested and still calling pr_power_activate_state()? -- Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
On Wed, May 30, 2001 at 11:30:05PM +0200, Marcus Meissner wrote:
> The problem is only there if you specify a directory for the linked to
> component.
>
> [marcus@wine /tmp]$ strace -f ln -s fupp/berk xxx
Is it only a directory, or the length?
ln -s fupp_berk xxx
for instance.
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
On Wed, 30 May 2001, Marcus Meissner wrote:
> On Wed, May 30, 2001 at 09:08:56PM +0100, Alan Cox wrote:
> > > > What file system. Its find on my 2.4.5-ac with ext2
> > >
> > > 100% reproducible on NFS and EXT2 here, with following:
> >
> >
> > > $ ls -la bar
> > > lrwxrwxrwx 1 marcus users 3 May 30 20:30 bar -> bar
> >
> > bash-2.04$ uname -a
> > Linux irongate.swansea.linux.org.uk 2.4.5-ac2 #163 Mon May 28
> 22:56:38 BST 2001 i686 unknown
> > bash-2.04$ ln -s frobnitz flop
> > bash-2.04$ ls -l f*
> > lrwxrwxrwx1 alan users 8 May 30 20:50 flop ->
> frobnitz
> >
> > bash-2.04$ gcc -v
> > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> > gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81
>
> The problem is only there if you specify a directory for the linked to
> component.
>
> [marcus@wine /tmp]$ strace -f ln -s fupp/berk xxx
> execve("/bin/ln", ["ln", "-s", "fupp/berk", "xxx"], [/* 39 vars */]) =
> 0
> ... ld stuff ... locale stuff ...
> lstat64("xxx", 0xb47c) = -1 ENOENT (No such file or
> directory)
> lstat64("xxx", 0xb47c) = -1 ENOENT (No such file or
> directory)
> symlink("fupp/berk", "xxx") = 0
> _exit(0)= ?
> [marcus@wine /tmp]$ ll xxx
> lrwxrwxrwx 1 marcus users 3 May 30 22:36 xxx -> xxx
> [marcus@wine /tmp]$ uname -a
> Linux wine.lst.de 2.4.5-ac4 #3 SMP Tue May 29 18:24:07 CEST 2001 i686
> unknown
> [marcus@wine /tmp]$
>
> It works just wonderful with previous kernels.
Works here:
=== Cut ===
[root@nomad tmp]# uname -a
Linux nomad.cyberbills.com 2.4.5ac4 #1 SMP Wed May 30 11:55:15 PDT 2001 i686
unknown
[root@nomad tmp]# touch 2/dummy
[root@nomad tmp]# ln -s 2/dummy very_dummy
[root@nomad tmp]# ls -l very_dummy
lrwxrwxrwx1 root root7 May 30 14:37 very_dummy -> 2/dummy
=== Cut ===
EXT2, loaded as module.
There are other problems (may be caused by R.Gooch's latest patch,
devfs-177) - no module autoloading complaining about "/dev//floppy/0" etc.
(there are 2 slashes after /dev, it's not a mistake). Recompiling ac5
without that patch, may be it'll help.
---
Sergey Kubushin Sr. Unix Administrator
CyberBills, Inc.Phone: 702-567-8857
874 American Pacific Dr,Fax:702-567-8808
Henderson, NV 89014
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: here comes the summer...
On Wed, 30 May 2001, J . A . Magallon wrote: > Anybody knows if sensors will get into kernel anytime in this century ? > Yes, it can generate patches automagically, but there is a big big lack > of sync with latest kernels. Patches generated are silly big because of > things like Any big reason why you don't use them as modules? -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Procfs Guide
On Wed, May 30, 2001 at 03:10:32PM -0600, [EMAIL PROTECTED] wrote: > So where can find the whole docbook ? I could not find under > linux/Documentation directory. That's correct, I only submitted it for inclusion into the kernel, so it's not yet there. Just patch your kernel source with my patch, run "make psdocs" and you'll have it in your kernel tree as well. However, because we got a similar procfs question on the kernelnewbies list, I already put the html and pdf versions online on the kernelnewbies documentation pages: http://www.kernelnewbies.org/documents/kdoc/procfs-guide/lkprocfsguide.html Erik PS: Was it really necessary to quote my complete message *including* the patch? Next time quote properly before you post. -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
On Wed, May 30, 2001 at 01:08:40PM -0700, Dawson Engler wrote: > Here are *uninspected* 2.4.5-ac4 results of a checker that warns when a > non-__init function calls an __init function (suggested by > [EMAIL PROTECTED]). There seem to be two cases: > > 1. The best case: the caller should actually be an __init function > as well. This is a performance bug since it won't be freed. > > 2. The worst case: some random post-initialization routine > calls an __init routine which can cause the kernel to go into > hyperspace if the __init routine's code has been deleted. > > The current messages do not differentiate between these two cases. If these > results are generally useful, I can fix up the checker, but as it now stands > there shouldn't be that many false positives. > > Dawson > MC linux bug database: http://hands.stanford.edu/linux > > >/u2/engler/mc/oses/linux/2.4.5-ac4/net/ipv4/netfilter/ip_nat_standalone.c:278:init_or_cleanup: > ERROR:INIT: non-init fn 'init_or_cleanup' calling init fn 'ip_nat_rule_init' This is not a bug. init_or_cleanup is only called from one place with an argument of 1: from the init() function. If the argument is 0, as called by the exit() function, the code for calling the ip_nat_rule_setup is never reached. So it is definitely not a bug. Anyway, one should maybe make this a little bit cleaner. Will look into that. -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: > Hi all, > sorry for the offtopic msg. > > Can someone point me to a 4 ports fast/eth card solution for linux? D-Link DFE-570 has a reasonable pricing and is well supported by the tulip driver > I found some cards based on the DEC 21*4* chips but when > I asked for more details I got a strange answer from the reseller > like that this card is able to work only half-duplex and the chip has > only one mac-address for the 4 eth cards (really strange). nah. And even if so, you can always change the mac-address using ifconfig. What the guy most likely wanted to say, is that there is only one EEprom containing all mac adresses for the four tulip chips, which I have seen on multiple boards > Thanks a lot > Fabbione -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
[EMAIL PROTECTED] said: > drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn > 'DoC_Probe' calling init fn 'doccheck' Strictly speaking, not actually a bug. DoC_Probe() itself is only ever called from __init code. But it's probably not worth trying to make the checker notice that situation - I've fixed it anyway by making DoC_Probe() __init too, which saves a bit more memory. Thanks. parse_mem_cmdline() in arch/i386/kernel/setup.c is a similar false (or at least questionable) positive. Note that it's an inline function, only used inside setup_arch(), which _is_ marked __init. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
here comes the summer...
...again (I think I asked just the same last summer) and lm_sensors is still out of the kernel (we have got 40ºC in Spain this week, and I would like to know how my PIIs suffer...) Anybody knows if sensors will get into kernel anytime in this century ? Yes, it can generate patches automagically, but there is a big big lack of sync with latest kernels. Patches generated are silly big because of things like #endif /* Whatever you like */ vs #endif X and init functions and so on... -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac4 #1 SMP Wed May 30 00:17:45 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ PATCH ]: disable pcspeaker kernel: 2.4.2 - 2.4.5
On Wednesday 30 May 2001 17:25, Ingo Molnar wrote: > On Wed, 30 May 2001, Nico Schottelius wrote: > > > the default value is 0, that is good enough. > > > > hmm.. I don't think so... value of 1 would be much better, because > > 0 normally disables the speaker. > > i confused the value. Yes, an initialization to 1 would be the > correct, ie.: > > +++ linux-2.4.5-nc/kernel/sysctl.c Wed May 9 23:44:30 2001 > @@ -48,6 +49,7 @@ > extern int nr_queued_signals, max_queued_signals; > extern int sysrq_enabled; > > +int pcspeaker_enabled = 1; I'd go and change the whole patch so that speaker_disabled = 0 is the default, but that's just me. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
udelay() on machines with speedstep [IBM ThinkPad T20 has real problems]
Hi!
It seems there's machine where changing CPU clocks actually does
something very bad [was it keyboard freeze?].
Can the unhappy thinkpad T20 owner please step up and test this patch?
Alan, is something like this candidate for -ac series?
Pavel
--- clean//arch/i386/kernel/time.c Mon Jan 8 22:49:35 2001
+++ linux/arch/i386/kernel/time.c Mon Jan 8 22:43:56 2001
@@ -63,7 +63,7 @@
*/
#include
-
+extern int x86_udelay_tsc;
unsigned long cpu_khz; /* Detected as we calibrate the TSC */
/* Number of usecs that the last interrupt was delayed */
@@ -152,7 +152,7 @@
* comp.protocols.time.ntp!
*/
-static unsigned long do_slow_gettimeoffset(void)
+static unsigned long do_read_hwtimer(void)
{
int count;
@@ -227,7 +227,7 @@
count -= 256;
#else
- printk("do_slow_gettimeoffset(): hardware timer
problem?\n");
+ printk("do_read_hwtimer(): hardware timer problem?\n");
#endif
}
}
@@ -235,6 +235,12 @@
jiffies_p = jiffies_t;
count_p = count;
+ return count;
+}
+
+unsigned long do_slow_gettimeoffset(void)
+{
+ unsigned long count = do_read_hwtimer();
count = ((LATCH-1) - count) * TICK_SIZE;
count = (count + LATCH/2) / LATCH;
@@ -449,7 +455,39 @@
#endif
}
-static int use_tsc;
+int use_tsc;
+
+void big_calibrate_tsc(void)
+{
+ if (cpu_has_tsc) {
+ unsigned long tsc_quotient = calibrate_tsc();
+ if (tsc_quotient) {
+ fast_gettimeoffset_quotient = tsc_quotient;
+ use_tsc = 1;
+ /*
+* We could be more selective here I suspect
+* and just enable this for the next intel chips ?
+*/
+ x86_udelay_tsc = 1;
+#ifndef do_gettimeoffset
+ do_gettimeoffset = do_fast_gettimeoffset;
+#endif
+ do_get_fast_time = do_gettimeofday;
+
+ /* report CPU clock rate in Hz.
+* The formula is (10^6 * 2^32) / (2^32 * 1 / (clocks/us)) =
+* clock/second. Our precision is about 100 ppm.
+*/
+ { unsigned long eax=0, edx=1000;
+ __asm__("divl %2"
+ :"=a" (cpu_khz), "=d" (edx)
+ :"r" (tsc_quotient),
+ "0" (eax), "1" (edx));
+ printk("Detected %lu.%03lu MHz processor.\n", cpu_khz
+/ 1000, cpu_khz % 1000);
+ }
+ } else { printk( "Failed to detect CPU Hz.\n" ); use_tsc = 0; }
+ } else use_tsc = 0;
+}
/*
* This is the same as the above, except we _also_ save the current
@@ -469,6 +507,28 @@
*/
write_lock(_lock);
+ if (use_tsc) {
+ long off = do_gettimeoffset();
+ /* Damn, kapmd plays hell with this. We'd need to busy loop in timer
+interrupt to calibrate reliably. */
+ static int faster = 0, slower = 0;
+ if (off > (110/HZ))
+ faster++;
+ else
+ faster = 0;
+
+ if (off < (90/HZ))
+ slower++;
+ else
+ slower = 0;
+
+ if ((faster > 10) || (slower > 10)) {
+ printk( KERN_ERR "TSC is %s than it should be! ", (faster >
+10) ? "faster" : "slower" );
+ big_calibrate_tsc();
+ faster = 0;
+ slower = 0;
+ }
+ }
+
if (use_tsc)
{
/*
@@ -558,7 +618,7 @@
#define CALIBRATE_LATCH(5 * LATCH)
#define CALIBRATE_TIME (5 * 120/HZ)
-static unsigned long __init calibrate_tsc(void)
+static unsigned long calibrate_tsc(void)
{
/* Set the Gate high, disable speaker */
outb((inb(0x61) & ~0x02) | 0x01, 0x61);
@@ -625,8 +685,6 @@
void __init time_init(void)
{
- extern int x86_udelay_tsc;
-
xtime.tv_sec = get_cmos_time();
xtime.tv_usec = 0;
@@ -657,34 +715,7 @@
dodgy_tsc();
- if (cpu_has_tsc) {
- unsigned long tsc_quotient = calibrate_tsc();
- if (tsc_quotient) {
- fast_gettimeoffset_quotient = tsc_quotient;
- use_tsc = 1;
- /*
-* We could be more selective here I suspect
-* and just enable this for the next intel chips ?
-*/
- x86_udelay_tsc = 1;
-#ifndef do_gettimeoffset
-
Re: 2.4.5 Oops at boot
On Wednesday, May 30, 2001 03:03:32 PM -0600 "D. Stimits" <[EMAIL PROTECTED]> wrote: [ snip ] > RAMDISK: Compressed image found at block 0 > Freeing initrd memory: 249k freed > VFS: Mounted root (ext2 filesystem). > Red Hat nash version 3.0.10 starting > VFS: Mounted root (ext2 filesystem) readonly. > change_root: old root has d_count=2 > Trying to unmount old root ... <1>Unable to handle kernel NULL pointer > dereference at virtual address 0010 > printing eip: Can't say for sure without the oops decoded through ksymoops, but this looks like the oops in rd_ioctl fixed by 2.4.5-ac3 and higher. I think the following patch (taken from ac3) will be sufficient: -chris --- linux.vanilla/fs/block_dev.cSat May 26 16:53:17 2001 +++ linux.ac/fs/block_dev.c Mon May 28 16:10:59 2001 @@ -603,6 +602,7 @@ if (!bdev->bd_op->ioctl) return -EINVAL; inode_fake.i_rdev=rdev; + inode_fake.i_bdev=bdev; init_waitqueue_head(_fake.i_wait); set_fs(KERNEL_DS); res = bdev->bd_op->ioctl(_fake, NULL, cmd, arg); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: determining size of cdrom
On Wed, May 30 2001, Jeff Meininger wrote:
>
> I'm not subscribed to the mailing list, so please Cc a copy of your
> replies straight to my email address: [EMAIL PROTECTED]
>
>
> I'm trying to determine the raw size of a cdrom disc, as in the size of
> the file you'd get by doing 'dd if=/dev/cdrom of=size_of_this.img'.
>
> I've tried the following things (with a disc in the drive) without
> success, and I'm hoping that someone will be able to point me in the right
> direction.
>
>
> struct stat s;
> stat("/dev/cdrom", );
> /* s.st_size is 0, s.st_blocks is 0. */
>
> int fd = open("/dev/cdrom", O_RDONLY);
>
> off_t bytes = lseek(fd, 0, SEEK_END);
> /* bytes is 0 */
>
> long sectors = 0;
> ioctl(fd, BLKGETSIZE, );
> /* sectors varies (never seems accurate) and is usually LONG_MAX */
At least this is the capacity as reported by the drive when we read the
table of contents.
> long ssz = 0;
> ioctl(fd, BLKSSZGET, );
> /* ssz varies, and is usually 1024. (shouldn't it be 2048?) */
Someone added a block size setting of 1024 to ide revalidate, and this
has screwed us for a awhile (ie atapi dvd-ram breaks). Recent ac has the
correct stuff to reset it.
> /* ioctl HDIO_GETGEO fails. */
>
> /* ioctl HDIO_GET_IDENTITY returns 0's for the c/h/s values I'm looking
> for. */
>
> I didn't find anything that looked obvious to me in linux/cdrom.h, except
> in the #ifdef __KERNEL__ section which I don't believe I can use from
> user space.
You can do it from user space with CDROMREADTOCHDR/CDROMREATOCENTRY if
you want, did you see those?
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Procfs Guide
So where can find the whole docbook ? I could not find under linux/Documentation directory. Regards, -hiren (408)970-3062 [EMAIL PROTECTED] > -Original Message- > From: Erik Mouw [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 30, 2001 1:36 PM > To: Tim Waugh > Cc: Linux kernel mailing list; Alan Cox > Subject: Re: [PATCH] Procfs Guide > > > On Wed, May 30, 2001 at 09:30:48AM +0100, Tim Waugh wrote: > > On Wed, May 30, 2001 at 01:29:17AM +0200, Erik Mouw wrote: > > > I'm still looking for a proper way to automatically > include the example > > > source into the SGML file, this patch with the same content in two > > > files is a bit of an ugly hack. > > > > Probably your best bet is to get the Makefile to pass a copy of the > > real example source through sed to ify the bits that would > > confuse SGML (<, >, etc), and into example.c.sed, make that into an > > entity, and include it. > > > > See http://people.redhat.com/twaugh/docbook/selfdocbook/> for > > instance, which does this with its own SGML source. > > Thanks, that was a really helpful example. > > So how about this version? > > > Erik > > -- > J.A.K. (Erik) Mouw, Information and Communication Theory > Group, Department > of Electrical Engineering, Faculty of Information Technology > and Systems, > Delft University of Technology, PO BOX 5031, 2600 GA Delft, > The Netherlands > Phone: +31-15-2783635 Fax: +31-15-2781843 Email: > [EMAIL PROTECTED] > WWW: http://www-ict.its.tudelft.nl/~erik/ > > > Index: Documentation/DocBook/Makefile > === > RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/Makefile,v > retrieving revision 1.1.1.30 > retrieving revision 1.1.1.25.2.2 > diff -u -r1.1.1.30 -r1.1.1.25.2.2 > --- Documentation/DocBook/Makefile2001/05/15 12:14:07 1.1.1.30 > +++ Documentation/DocBook/Makefile2001/05/30 20:31:18 > 1.1.1.25.2.2 > @@ -1,7 +1,7 @@ > BOOKS:= wanbook.sgml z8530book.sgml mcabook.sgml > videobook.sgml \ > kernel-api.sgml parportbook.sgml kernel-hacking.sgml \ > kernel-locking.sgml via-audio.sgml mousedrivers.sgml > sis900.sgml \ > -deviceiobook.sgml > +deviceiobook.sgml procfs-guide.sgml > > PS := $(patsubst %.sgml, %.ps, $(BOOKS)) > PDF := $(patsubst %.sgml, %.pdf, $(BOOKS)) > @@ -9,6 +9,7 @@ > IMG-parportbook := parport-share.fig parport-multi.fig > parport-structure.fig > EPS-parportbook := $(patsubst %.fig, %.eps, $(IMG-parportbook)) > JPG-parportbook := $(patsubst %.fig, %.jpeg, $(IMG-parportbook)) > +C-procfs-example = procfs_example.sgml > > books: $(BOOKS) > > @@ -67,6 +68,17 @@ > $(TOPDIR)/scripts/docgen > $(TOPDIR)/drivers/media/video/videodev.c \ > videobook.sgml > > +procfs_example.sgml: procfs_example.c > + echo "" > $@ > + expand --tabs=8 < $< | \ > + sed -e "s/&/\\/g" \ > + -e "s/ + -e "s/>/\\/g" >> $@ > + echo "" >> $@ > + > +procfs-guide.sgml: procfs-guide.tmpl procfs_example.sgml > + $(TOPDIR)/scripts/docgen < procfs-guide.tmpl >$@ > + > APISOURCES :=$(TOPDIR)/drivers/media/video/videodev.c \ > $(TOPDIR)/arch/i386/kernel/irq.c \ > $(TOPDIR)/arch/i386/kernel/mca.c \ > @@ -128,6 +140,7 @@ > -$(RM) $(BOOKS) > -$(RM) $(DVI) $(AUX) $(TEX) $(LOG) $(OUT) > -$(RM) $(JPG-parportbook) $(EPS-parportbook) > + -$(RM) $(C-procfs-example) > > mrproper: clean > -$(RM) $(PS) $(PDF) > Index: Documentation/DocBook/procfs-guide.tmpl > === > RCS file: procfs-guide.tmpl > diff -N procfs-guide.tmpl > --- /dev/null Thu Mar 22 14:04:47 2001 > +++ Documentation/DocBook/procfs-guide.tmpl Wed May 30 22:32:02 2001 > @@ -0,0 +1,603 @@ > + > + + > +]> > + > + > + > +Linux Kernel Procfs Guide > + > + > + > + > + Erik > + (J.A.K.) > + Mouw > + > + Delft University of Technology > + Faculty of Information Technology and Systems > + > +[EMAIL PROTECTED] > +PO BOX 5031 > +2600 GA > +Delft > +The Netherlands > + > + > + > + > + > + > + > + 2001 > + Erik Mouw > + > + > + > + > + > +This documentation is free software; you can redistribute it > +and/or modify it under the terms of the GNU General Public > +License as published by the Free Software Foundation; either > +version 2 of the License, or (at your option) any later > +version. > + > + > + > +This documentation is distributed in the hope that it will be > +useful, but WITHOUT ANY WARRANTY; without even the implied > +warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR > +PURPOSE. See the GNU General Public License for > more details. > + > +
RE: [patch]: ide dma timeout retry in pio
Chris/All: I think your assumptions are correct. I'm guessing that IDE DMA activity is not being properly handled when the CPU is in C3, resulting in memory (and therefore file system) corruption. We haven't seen corruption on our development systems, but this is probably due to the fact that we don't explicitly enable IDE DMA transfers (?). I'm concerned that the CPU is being put into C3 during what appears to be times of high bus mastering activity. The default policy (prpolicy.c) is configured to only use C3 when bus mastering (BM_STS) is silent for 4 or more 'quantums'. You can see if this is working by causing disk activity while cat'ing the file '/proc/acpi/processor/0/status': the C3 counter should not be incrementing (or not by much, anyway). The C3 handler should block bus master activity while the CPU is in C3. DMA activity (writes) during C3 would result in cache-incoherency (since the CPU is not snooping) and thus memory corruption. The idea is to block bus mastering activity while in C3 (ARB_DIS), but allow the CPU to wakeup whenever bus mastering is requested (BM_RLD). I'm betting that DMA is happening during C3 resulting in fs corruption. To verify if C3 is really the culprit we should try disabling its use on a vulnerable system. I'd recommend mapping the C3 handler to use C2 instead, which could be done by modifying the switch statement in pr_power_idle() within prpower.c (see below). Note that we'll still be setting BM_RLD for C3's during pr_power_activate_state(), but this shouldn't be an issue. case PR_C2: case PR_C3: /* Interrupts must be disabled during C2 transitions */ disable(); /* See how long we're asleep for */ acpi_get_timer(_ticks); /* Invoke C2 */ acpi_os_in8(processor->power.p_lvl2); /* Dummy op - must do something useless after P_LVL2 read */ acpi_hw_register_bit_access(ACPI_READ, ACPI_MTX_DO_NOT_LOCK, BM_STS); /* Compute time elapsed */ acpi_get_timer(_ticks); /* Re-enable interrupts */ enable(); break; Could somebody give this a try and let me know? Thanks, -- Paul Diefenbaugh Intel Corporation -Original Message- From: Christopher B. Liebman [mailto:[EMAIL PROTECTED]] Sent: Monday, May 28, 2001 1:13 PM To: Jens Axboe; Mark Hahn Cc: Acpi@Phobos. Fachschaften. Tu-Muenchen. De; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [patch]: ide dma timeout retry in pio I think that this may be an issue with ACPI processor power saving... I have documented issues with ide DMA timeouts when the processor is put into the C3 power state. One of the things that happens in this state is that buss master arbitration is *disabled*. bus master activity is *supposed* to transition the system back to a C0 power state. I'll bet there are some issues with the Linux IDE dma and disabling bus master arbitration.. ideas? thoughts? patches? ;-) -- Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Hahn > > I seem to recall Andre saying that the problem arises when the > ide DMA engine looses PCI arbitration during a burst. shorter > bursts would seem like the best workaround if this is the problem... > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
determining size of cdrom
I'm not subscribed to the mailing list, so please Cc a copy of your
replies straight to my email address: [EMAIL PROTECTED]
I'm trying to determine the raw size of a cdrom disc, as in the size of
the file you'd get by doing 'dd if=/dev/cdrom of=size_of_this.img'.
I've tried the following things (with a disc in the drive) without
success, and I'm hoping that someone will be able to point me in the right
direction.
struct stat s;
stat("/dev/cdrom", );
/* s.st_size is 0, s.st_blocks is 0. */
int fd = open("/dev/cdrom", O_RDONLY);
off_t bytes = lseek(fd, 0, SEEK_END);
/* bytes is 0 */
long sectors = 0;
ioctl(fd, BLKGETSIZE, );
/* sectors varies (never seems accurate) and is usually LONG_MAX */
long ssz = 0;
ioctl(fd, BLKSSZGET, );
/* ssz varies, and is usually 1024. (shouldn't it be 2048?) */
/* ioctl HDIO_GETGEO fails. */
/* ioctl HDIO_GET_IDENTITY returns 0's for the c/h/s values I'm looking
for. */
I didn't find anything that looked obvious to me in linux/cdrom.h, except
in the #ifdef __KERNEL__ section which I don't believe I can use from
user space.
I hope I didn't miss something really obvious, but I've been at this
problem for a few days now (mostly spent reading docs and headers) and I'm
at the point where I'll risk asking something stupid.
Thanks!!
BTW, once again, I'm not subscribed to the mailing list, so please Cc a
copy of your replies straight to my email address: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM
On Wed, 30 May 2001, Mike Galbraith wrote: > On Wed, 30 May 2001, Rik van Riel wrote: > > > On Wed, 30 May 2001, Marcelo Tosatti wrote: > > > > > The problem is that we allow _every_ task to age pages on the system > > > at the same time --- this is one of the things which is fucking up. > > > > This should not have any effect on the ratio of cache > > reclaiming vs. swapout use, though... > > It shouldn't.. but when many tasks are aging, it does. What Rik means is that they are independant problems. > Excluding these guys certainly seems to make a difference. Sure, those guys are going to "help" kswapd to unmap pte's and allocate swap space. Now even if only kswapd does this job (meaning a sane amount of cache reclaims/swapouts), you still have to deal with the reclaim/swapout tradeoff. See? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.4ac11 - 2.4.5 and 2.4.5ac5] problems with stat continue (ln -s broken ...?)
Hallo all!
I know that I'm repeating myself - but the problem is still the same. It's
impossible for me to use these kernels mentioned in the subject.
I think there is a parallelism to the mail "ln -s broken on 2.4.5" or am I
the problem? Who can help me?
Regards,
Andreas Hartmann
> Hallo all,
>
> I get the mentioned error as often as longer the system is running. E.g.:
> $ ls kviewshell/.libs/libkmultipage.so
>
> The following is what strace say's:
>
> []
> 3795 lstat("kviewshell/.libs/libkmultipage.so", 0xb718) = -1 EIO
> (Input/output error)
> [...]
>
> The file really exists and is correct!
>
> Another example is:
> umount /boot
>
> That's what strace is saying:
> [...]
>
> 3762 open("/etc/mtab~3762", O_WRONLY|O_CREAT, 0) = 4
> 3762 close(4) = 0
> 3762 link("/etc/mtab~3762", "/etc/mtab~") = -1 ENOENT (No such file or
> directory)
> 3762 unlink("/etc/mtab~3762") = 0
> []
>
> I've got no problems with 2.4.4ac9 and ac10. The Problems start with ac11
> and can be found until the actual ac17.
>
>
> Versions:
> Linux athlon 2.4.4-ac16 #1 Don Mai 24 22:47:31 CEST 2001 i686 unknown
>
> Gnu C 2.95.3
> Gnu make 3.76.1
> binutils 2.9.5.0.12
> util-linux 2.10s
> mount 2.10s
> modutils 2.4.5
> e2fsprogs 1.19
> PPP2.4.0b1
> Linux C Library2.1.3
> Dynamic linker (ldd) 2.1.3
> Procps 2.0.2
> Net-tools 1.56
> Kbd0.96
> Sh-utils 2.0g
> Modules Loaded ext2 nfs lockd sunrpc 8139too sis900 serial
> parport_pc lp parport unix
>
> I'm using reiserfs, 3.5.x disk format.
>
>
> $ lspci -v
>
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
> Flags: bus master, medium devsel, latency 0
> Memory at d600 (32-bit, prefetchable) [size=32M]
> Capabilities:
>
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge] (prog-if
> 00 [Normal decode])
> Flags: bus master, 66Mhz, medium devsel, latency 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: c000-cfff
> Memory behind bridge: d400-d5ff
> Prefetchable memory behind bridge: d000-d3ff
> Capabilities:
>
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
> Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
> Flags: bus master, stepping, medium devsel, latency 0
>
> 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
> 10) (prog-if 8a [Master SecP PriP])
> Flags: bus master, medium devsel, latency 32
> I/O ports at d000 [size=16]
> Capabilities:
>
> 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> (prog-if 00 [UHCI])
> Subsystem: Unknown device 0925:1234
> Flags: bus master, medium devsel, latency 32, IRQ 9
> I/O ports at d400 [size=32]
> Capabilities:
>
> 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
> (rev 30)
> Flags: medium devsel, IRQ 9
> Capabilities:
>
> 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
> [Apollo Super AC97/Audio] (rev 20)
> Subsystem: VIA Technologies, Inc.: Unknown device 4511
> Flags: medium devsel, IRQ 5
> I/O ports at dc00 [size=256]
> I/O ports at e000 [size=4]
> I/O ports at e400 [size=4]
> Capabilities:
>
> 00:08.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100
> Ethernet (rev 02)
> Subsystem: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet Adapter
> Flags: bus master, medium devsel, latency 32, IRQ 10
> I/O ports at e800 [size=256]
> Memory at d900 (32-bit, non-prefetchable) [size=4K]
> Expansion ROM at [disabled] [size=128K]
> Capabilities:
>
> 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev
> 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139
> Flags: bus master, medium devsel, latency 32, IRQ 11
> I/O ports at ec00 [size=256]
> Memory at d9001000 (32-bit, non-prefetchable) [size=256]
> Expansion ROM at [disabled] [size=64K]
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF
> (prog-if 00 [VGA])
> Subsystem: ATI Technologies Inc: Unknown device 0008
> Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 10
> Memory at d000 (32-bit, prefetchable) [size=64M]
> I/O ports at c000 [size=256]
> Memory at d500 (32-bit, non-prefetchable) [size=16K]
> Expansion ROM at [disabled] [size=128K]
> Capabilities:
>
>
>
> Regards,
> Andreas Hartmann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
2.4.5 Oops at boot
I have two systems, one running RH 7.1 as base, the other RH 7.1 beta. Both are x86 SMP. The following Oops is from the RH 7.1 machine (non-beta) for kernel 2.4.5 (compiled with kgcc, no patches). Please note that both machines will fail to create a bootable floppy with make bzdisk; I have tried half a dozen separate floppies from separate boxes. Both will boot from floppy made through mkbootdisk. Both have scsi compiled directly in, and are not modules. Both use aic7xxx. The machine with Oops being reported on is being booted "noapic", since it is the i840 chipset (the other machine is BX chipset). The following bootup message excerpt should be accurate, but I had to type this whole thing in by hand, since the system dies. I went through a lot of effort to make sure there were no typo's, but there is still a very minor possibility of such. It isn't possible to list lspci -vv for the failed kernel, which is requested in the boot message at one point, so I have to do this through the RH stock 2.4.2 SMP kernel of RH 7.1. Kernel config for this is attached. D. Stimits, [EMAIL PROTECTED] Bootup: ... ... ... Redundant entry in serial pci_table. Please send the output of lspci -vv, this message (4793,4104,4793,173) ... ... ... RAMDISK: Compressed image found at block 0 Freeing initrd memory: 249k freed VFS: Mounted root (ext2 filesystem). Red Hat nash version 3.0.10 starting VFS: Mounted root (ext2 filesystem) readonly. change_root: old root has d_count=2 Trying to unmount old root ... <1>Unable to handle kernel NULL pointer dereference at virtual address 0010 printing eip: c01c5bda *pde = Oops: CPU:1 EIP:0010:[] EFLAGS: 00010202 eax: ebx: ecx: 1261 edx: c1479d98 esi: edi: c1479e2c ebp: esp: c1479d68 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c1479000) Stack: c1478000 cfe97f60 c1479e2c c013b0fb c1479d98 1261 cfeac560 fffe cfe97f60 cff06ea4 cff06e10 c0346340 0001def6 cfef0001 c01ea7b2 cff06e00 0082 0202 c14e1cb8 cfef8200 cff07e60 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 10 83 f8 02 7e 0e b8 f0 ff ff ff eb 7e 8d b4 26 00 00 Kernel panic: Attempted to kill init! >From lspci -vv: ~# lspci -vv 00:00.0 Host bridge: Intel Corporation 82840 840 (Carmel) Chipset Host Bridge (Hub A) (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset AGP Bridge (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 00:02.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset PCI Bridge (Hub B) (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 03:00.0 PIC: Intel Corporation 82806AA PCI64 Hub Advanced Programmable Interrupt Controller (rev 01) (prog-if 20 [IO(X)-APIC]) Subsystem: Intel Corporation 82806AA PCI64 Hub Advanced Programmable Interrupt Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set #
Re: Kernel 2.4.x TODO
Em Wed, May 30, 2001 at 01:46:50PM -0700, Dunlap, Randy escreveu: > > From: Sasi Peter [mailto:[EMAIL PROTECTED]] > > > > > Check out the kernel janitor project at > > > http://bazar.conectiva.com.br/~acme/TODO (original) > > > > Is this information up2date? If it is, sad to see we have > > this many bugs... > > "Last updated in: Mon Feb 26 21:19:49 EST 2001" > > The other link that I sent (the kernel janitor project) replaced this list > and should be more up-to-date...although I can't really find a TODO list > there: > http://sourceforge.net/projects/kernel-janitor > > Jeff? its in CVS, you can see it here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kernel-janitor/kernel-janitor/TODO Being in CVS I, Dave Jones and Jeff Garzik can go on updating it more easily, but for now Dave is the only one doing commits, thanks Dave! And if somebody volunteers to make a nice web page for the project... 8) Ah, I'm updating the TODO in http://bazar.conectiva.com.br/~acme/TODO, including a pointer to the above URL. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel 2.4.x TODO
On Wed, 30 May 2001, Dunlap, Randy wrote: The memory management subsystem uses a Bugzilla as its TODO list: http://linux-mm.org/bugzilla.shtml regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel 2.4.x TODO
> From: Sasi Peter [mailto:[EMAIL PROTECTED]] > > > Check out the kernel janitor project at > > http://bazar.conectiva.com.br/~acme/TODO (original) > > Is this information up2date? If it is, sad to see we have > this many bugs... "Last updated in: Mon Feb 26 21:19:49 EST 2001" The other link that I sent (the kernel janitor project) replaced this list and should be more up-to-date...although I can't really find a TODO list there: http://sourceforge.net/projects/kernel-janitor Jeff? ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] new floating point bugs in 2.4.5-ac4
In article <[EMAIL PROTECTED]> you wrote: > Here are two new uses of floating point that popped up in the 2.4.5-ac4 > kernel. While the expressions that use FP are trivial, at least my > version of gcc does not calculate them at compile time. > [BUG] DMFE_TX_KICK is (HZ * 0.5) which gcc does as floating point. Fix is >trivial: just divide by 2 instead. Fixed in 2.4.5-ac5 already - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Segfault during network calls
Hello colleagues, We have a strange problem with our multi-threaded SMTP client: at very heavy load (e.g. 150 threads, each with a pool of 5 persistent connections) it sometimes receives SIGSEGV while making network kernel calls (mostly in "recvfrom" for both TCP and UDP, but also in "connect"). This happens for both 2.2.12 and 2.4.4 kernels on a Celeron 600 machine (no SMP) with glibc 2.1.3. The kernel logs do not show any problems, yet the application program gets killed. This happens MORE frequently if we increase the number of file descriptors available to the process (using "ulimit -n"), which suggests some resource utilisation problem in the kernel (?) E.g., is there a compiled-in upper bound on the total number of sockets which can be created by all processes? (I could not find SOCK_ARRAY_SIZE in 2.4.4). Any ideas would be very much appreciated. Thank you very much in advance, Dr. Leonid A. Timochouk Computing Laboratory University of Kent at Canterbury - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM
On Wed, 30 May 2001, Rik van Riel wrote: > On Wed, 30 May 2001, Marcelo Tosatti wrote: > > > The problem is that we allow _every_ task to age pages on the system > > at the same time --- this is one of the things which is fucking up. > > This should not have any effect on the ratio of cache > reclaiming vs. swapout use, though... It shouldn't.. but when many tasks are aging, it does. Excluding these guys certainly seems to make a difference. (could be seeing something else and interpreting it wrong...) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Procfs Guide
On Wed, May 30, 2001 at 09:30:48AM +0100, Tim Waugh wrote: > On Wed, May 30, 2001 at 01:29:17AM +0200, Erik Mouw wrote: > > I'm still looking for a proper way to automatically include the example > > source into the SGML file, this patch with the same content in two > > files is a bit of an ugly hack. > > Probably your best bet is to get the Makefile to pass a copy of the > real example source through sed to ify the bits that would > confuse SGML (<, >, etc), and into example.c.sed, make that into an > entity, and include it. > > See http://people.redhat.com/twaugh/docbook/selfdocbook/> for > instance, which does this with its own SGML source. Thanks, that was a really helpful example. So how about this version? Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ Index: Documentation/DocBook/Makefile === RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/Makefile,v retrieving revision 1.1.1.30 retrieving revision 1.1.1.25.2.2 diff -u -r1.1.1.30 -r1.1.1.25.2.2 --- Documentation/DocBook/Makefile 2001/05/15 12:14:07 1.1.1.30 +++ Documentation/DocBook/Makefile 2001/05/30 20:31:18 1.1.1.25.2.2 @@ -1,7 +1,7 @@ BOOKS := wanbook.sgml z8530book.sgml mcabook.sgml videobook.sgml \ kernel-api.sgml parportbook.sgml kernel-hacking.sgml \ kernel-locking.sgml via-audio.sgml mousedrivers.sgml sis900.sgml \ - deviceiobook.sgml + deviceiobook.sgml procfs-guide.sgml PS := $(patsubst %.sgml, %.ps, $(BOOKS)) PDF:= $(patsubst %.sgml, %.pdf, $(BOOKS)) @@ -9,6 +9,7 @@ IMG-parportbook := parport-share.fig parport-multi.fig parport-structure.fig EPS-parportbook := $(patsubst %.fig, %.eps, $(IMG-parportbook)) JPG-parportbook := $(patsubst %.fig, %.jpeg, $(IMG-parportbook)) +C-procfs-example = procfs_example.sgml books: $(BOOKS) @@ -67,6 +68,17 @@ $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/media/video/videodev.c \ videobook.sgml +procfs_example.sgml: procfs_example.c + echo "" > $@ + expand --tabs=8 < $< | \ + sed -e "s/&/\\/g" \ + -e "s//\\/g" >> $@ + echo "" >> $@ + +procfs-guide.sgml: procfs-guide.tmpl procfs_example.sgml + $(TOPDIR)/scripts/docgen < procfs-guide.tmpl >$@ + APISOURCES := $(TOPDIR)/drivers/media/video/videodev.c \ $(TOPDIR)/arch/i386/kernel/irq.c \ $(TOPDIR)/arch/i386/kernel/mca.c \ @@ -128,6 +140,7 @@ -$(RM) $(BOOKS) -$(RM) $(DVI) $(AUX) $(TEX) $(LOG) $(OUT) -$(RM) $(JPG-parportbook) $(EPS-parportbook) + -$(RM) $(C-procfs-example) mrproper: clean -$(RM) $(PS) $(PDF) Index: Documentation/DocBook/procfs-guide.tmpl === RCS file: procfs-guide.tmpl diff -N procfs-guide.tmpl --- /dev/null Thu Mar 22 14:04:47 2001 +++ Documentation/DocBook/procfs-guide.tmpl Wed May 30 22:32:02 2001 @@ -0,0 +1,603 @@ + + +]> + + + +Linux Kernel Procfs Guide + + + + + Erik + (J.A.K.) + Mouw + + Delft University of Technology + Faculty of Information Technology and Systems + +[EMAIL PROTECTED] +PO BOX 5031 +2600 GA +Delft +The Netherlands + + + + + + + + 2001 + Erik Mouw + + + + + +This documentation is free software; you can redistribute it +and/or modify it under the terms of the GNU General Public +License as published by the Free Software Foundation; either +version 2 of the License, or (at your option) any later +version. + + + +This documentation is distributed in the hope that it will be +useful, but WITHOUT ANY WARRANTY; without even the implied +warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR +PURPOSE. See the GNU General Public License for more details. + + + +You should have received a copy of the GNU General Public +License along with this program; if not, write to the Free +Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, +MA 02111-1307 USA + + + +For more details see the file COPYING in the source +distribution of Linux. + + + + + + + + + + + + + + +Preface + + + This guide describes the use of the procfs file system from + within the Linux kernel. The idea to write this guide came up on + the #kernelnewbies IRC channel (see
[CHECKER] new floating point bugs in 2.4.5-ac4
Here are two new uses of floating point that popped up in the 2.4.5-ac4
kernel. While the expressions that use FP are trivial, at least my
version of gcc does not calculate them at compile time.
As a bonus, two old, but still existing FP uses are also included.
Dawson
MC linux bug database: http://hands.stanford.edu/linux
# New errors.
#
-
[BUG] DMFE_TX_TIMEOUT is HZ * 1.5 which seems easy to fix.
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/dmfe.c:1112:dmfe_timer: ERROR:FLOAT:
cannot use fp in kernel
if ( db->tx_packet_cnt &&
((jiffies - dev->trans_start) > DMFE_TX_KICK) ) {
outl(0x1, dev->base_addr + DCR1); /* Tx polling again */
/* TX Timeout */
Error --->
if ( (jiffies - dev->trans_start) > DMFE_TX_TIMEOUT ) {
-
[BUG] DMFE_TX_KICK is (HZ * 0.5) which gcc does as floating point. Fix is
trivial: just divide by 2 instead.
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/dmfe.c:1108:dmfe_timer: ERROR:FLOAT:
cannot use fp in kernel
}
db->interval_rx_cnt = 0;
/* TX polling kick monitor */
if ( db->tx_packet_cnt &&
Error --->
((jiffies - dev->trans_start) > DMFE_TX_KICK) ) {
# Existing, unfixed errors
#
-
[BUG]
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/video/sgivwfb.c:731:sgivwfb_set_var:
ERROR:FLOAT: cannot use fp in kernel
var->green.msb_right = 0;
var->blue.msb_right = 0;
var->transp.msb_right = 0;
/* set video timing information */
Error --->
var->pixclock = (__u32)(1.0e+9/(float)timing->cfreq);
-
[BUG]
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/video/sgivwfb.c:664:sgivwfb_set_var:
ERROR:FLOAT: cannot use fp in kernel
return -EINVAL; /* Resolution to high */
/* XXX FIXME - should try to pick best refresh rate */
/* for now, pick closest dot-clock within 3MHz*/
#error "Floating point not allowed in kernel"
Error --->
req_dot = (int)((1.0e3/1.0e6) / (1.0e-12 * (float)var->pixclock));
# Old fixed
#
[FIXED] sis_main.c:crtc_to_var:FLOAT: cannot use fp in kerne
/u2/engler/mc/oses/linux/2.4.4/drivers/video/sis/sis_main.c:588:crtc_to_var:
ERROR:FLOAT: cannot use fp in kernel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: calculation of ac_mem (in BSD accounting) misleading?
On Wed, 30 May 2001, Doug Bagley wrote: > Does it make sense to others that ac_mem should be changed to reflect > the resident set size? It does, but doesn't have all that much priority at the moment. Feel free to send patches, though. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
calculation of ac_mem (in BSD accounting) misleading?
I'm interested in understanding better why the value of ac_mem in the BSD process accounting code (linux/kernel/acct.c) is calculated the way it is. My humble uninformed opinion is that it's current definition is possibly misleading at best and mostly useless at worst. As a little background: The comment in include/linux/acct.h says ac_mem is "Average Memory Usage". According to BSD sources, ac_mem in BSD looks like a time-averaged resident set size: acct.ac_mem = (r->ru_ixrss + r->ru_idrss + r->ru_isrss) / t; (http://minnie.tuhs.org/FreeBSD-srctree/newsrc/kern/kern_acct.c.html) But the code in linux/kernel/acct.c indicates that ac_mem is simply the vmsize (in KB) at the time acct_process() is called from do_exit(). It does not appear to be an average, and IMHO, vmsize is nearly useless, especially if one expects RSS. Does it make sense to others that ac_mem should be changed to reflect the resident set size? Cheers, Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac5
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac5 o Fix bug introduced in cs46xx/trident locking(me) o Fix reiserfs unload/exit locking race (Paul Mundt) o Miscellaneous small UML updates (Jeff Dike) o Further FAT cleanups(OGAWA Hirofumi) o Fix ext2fs oops following disk error(Andreas Dilger) o Optimise segment reloads, syscall path (Andi Kleen) o Clean up .byte abuse where asm is now known (Brian Gerst) by required tools o Fix eepro100 on 64bit machine bitops bug(Andrea Arcangeli) o Move the pagecache and pagemap_lru_lock to (Andrea Arcangeli) different cache lines o Clean up .byte abuse where asm is now known (Brian Gerst) by required tools o Fix user space dereference in bluetooth (me) | From Stanford tools o Fix user space dereference in sbc60wdt (me) | From Stanford tools o Fix user space dereference in mdc800(me) | From Stanford tools o Fix a rather wrong memset in nubus.c(Chris Peterson) o Remove fpu references from dmfe (Arjan van de Ven) o Fix spelling of Portuguese (Nerijus Baliunas) 2.4.5-ac4 o APIC parsing updates(Ingo Molnar) o Retry rather than losing I/O on an IDE DMA (Jens Axboe) timeout. o Add missing locking to cs46xx (Frank Davis) o Clean up sym53c416 and add PnP support (me) o Tidy up changelog in apm.c (Stephen Rothwell) o Update jffs2, remove abuse of kdev_t(David Woodhouse) o Fix oops on unplugging bluetooth(Greg Kroah-Hartmann) o Move stuff into bss on aironet4500 (Rasmus Andersen) o Fix up alpha oops output(George France) o Update SysKonnect PCI id list (Mirko Lindner) o Update SysKonnect GigE driver (Mirko Lindner) o Add ATM DS3/OC12 definitions to atmdev.h(Mitchell Blank) o Clean up atm drivers, fixed up user space (Mitchell Blank, access with irqs off, kmalloc and use after John Levon) free. o Update input device/joystick/gameport drivers (Vojtech Pavlik) o Update USB hid drivers (Vojtech Pavlik) o Fix out of memory oops in hysdn (Rasmus Andersen) o Belarussian should be Belarusian according to (Nerijus Baliunas) the standards o Support booting off old 720K floppies (Niels Jensen, Chris Noe) 2.4.5-ac3 o Ignore console writes from an IRQ handler (me) o Make SIGBUS/SIGILL visible to UML debugger (Jeff Dike) o Clean up UML syscalls add missing items (Jeff Dike) o Clean up non portable UML code (Jeff Dike) o Fix off by one and other oddments in hostfs (Henrik Nordstrom) o Update UML to use CONFIG_SMP not __SMP__(Jeff Dike) o Fix UML crash if console is typed at too early (Jeff Dike) o Clean up UML host transports(Lennert Buytenhek, Jim Leu) o Resynchronize UML/ppc (Chris Emerson) o Fix UML crash if it had an address space hole (Jeff Dike) between text and data o Fix rd_ioctl crash with initrd (Go Taniguchi) o Fix IRQ ack path on Alpha rawhide (Richard Henderson) o Drop back to older 8139too driver from 2.4.3 | Seems the new one causes lockups o Experimental promise fastrak raid driver(Arjan van de Ven) 2.4.5-ac2 o Restore lock_kernel on umount (Al Viro) | Should cure Reiserfs crash in 2.4.5 o Fix additional scsi_ioctl leak (John Martin) o Clean up scsi_ioctl error handling (me) o Configure.help typo fixes (Nerijus Baliunas) o Fix hgafb problems with logos (Ferenc Bakonyi) o Fix lock problems in the rio driver (Rasmus Andersen) o Make new cmpci SMP safe (Carlos E Gorges) o Fix missing restore flags in soundmodem (Rasmus Andersen) o Set max sectors in ps2esdi
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wed, 30 May 2001, Vincent Stemen wrote: > The problem is, that's not true. These problems are not slipping > through because of lack of testers. As Alan said, the VM problem has > been lurking, which means that it was known already. Fully agreed, it went through because of a lack of hours per day and the fact that the priority of developers was elsewhere. For me, for example, the priorities have mostly been with bugs that bothered me or that bothered Conectiva's customers. If you _really_ feel this strongly about the bug, you could either try to increase the number of hours a day for all of us or you could talk to my boss about hiring me as a consultant to fix the problem for you on an emergency basis :) The other two alternatives would be either waiting until somebody gets around to fixing the bug or sending in a patch yourself. Trying to piss off developers has adverse effect on all four of the methods above :) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops on 2.2.5
Hello There is two "Oops" from user's space (pine,epic) programs. On 2.2.x kernels, on this machine, it had never happened. (2.4.5 #1 SMP Pentium III (Coppermine), 800MHz, RH 7.1, gcc 2.96) ksymoops 2.4.0 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /usr/src/linux/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry May 24 22:46:17 oceanic kernel: Unable to handle kernel NULL pointer May 24 22:46:17 oceanic kernel: c0106c28 May 24 22:46:17 oceanic kernel: *pde = May 24 22:46:17 oceanic kernel: Oops: May 24 22:46:17 oceanic kernel: CPU:0 May 24 22:46:17 oceanic kernel: EFLAGS: 00010286 May 24 22:46:17 oceanic kernel: eax: ebx: ce702000 ecx: edx: ce702000 May 24 22:46:17 oceanic kernel: esi: 0016 edi: 0016 ebp: 6b19 esp: ce703f28 May 24 22:46:17 oceanic kernel: ds: 0018 es: 0018 ss: 0018 May 24 22:46:17 oceanic kernel: Process epic (pid: 27417, stackpage=ce703000) May 24 22:46:17 oceanic kernel: Stack: ce702640 ce703fc4 0016 0080 c01476dc May 24 22:46:17 oceanic kernel:e4bbc0c0 c02b0b18 dc7a91c0 dc7a91c0 db843000 bfffc484 db843000 5403 May 24 22:46:17 oceanic kernel:c018ad42 db843000 bfffc484 0002 bfffc484 c010876e 0001 c0301068 May 24 22:46:17 oceanic kernel: Call Trace: [] [] [] [] [] May 24 22:46:17 oceanic kernel: Code: f6 80 48 01 00 00 01 75 0a 6a 11 52 e8 c7 7a 01 00 5e 5f e8 Using defaults from ksymoops -t elf32-i386 -a i386 Trace; c01476dc Trace; c018ad42 Trace; c010876e Trace; c01434f9 Trace; c0106e5c Code; Before first symbol <_EIP>: Code; Before first symbol 0: f6 80 48 01 00 00 01 testb $0x1,0x148(%eax) Code; 0007 Before first symbol 7: 75 0a jne13 <_EIP+0x13> 0013 Before first symbol Code; 0009 Before first symbol 9: 6a 11 push $0x11 Code; 000b Before first symbol b: 52push %edx Code; 000c Before first symbol c: e8 c7 7a 01 00call 17ad8 <_EIP+0x17ad8> 00017ad8 Before first symbol Code; 0011 Before first symbol 11: 5epop%esi Code; 0012 Before first symbol 12: 5fpop%edi Code; 0013 Before first symbol 13: e8 00 00 00 00call 18 <_EIP+0x18> 0018 Before first symbol 1 warning issued. Results may not be reliable. ksymoops 2.4.0 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /usr/src/linux/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry May 30 17:47:59 oceanic kernel: Unable to handle kernel NULL pointer dereference at virtual address 0148 May 30 17:47:59 oceanic kernel: c0106c28 May 30 17:47:59 oceanic kernel: *pde = May 30 17:47:59 oceanic kernel: Oops: May 30 17:47:59 oceanic kernel: CPU:0 May 30 17:47:59 oceanic kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 May 30 17:47:59 oceanic kernel: EFLAGS: 00010286 May 30 17:47:59 oceanic kernel: eax: ebx: ddb4 ecx: edx: ddb4 May 30 17:47:59 oceanic kernel: esi: 0016 edi: 0016 ebp: 461f esp: ddb41f28 May 30 17:47:59 oceanic kernel: ds: 0018 es: 0018 ss: 0018 May 30 17:47:59 oceanic kernel: Process pine (pid: 17951, stackpage=ddb41000) May 30 17:47:59 oceanic kernel: Stack: ddb40640 ddb41fc4 0016 0080 ecdb84e0 May 30 17:47:59 oceanic kernel:ecdb8500 d45f3f60 4001e000 c018cf60 dbf26b60 0282 May 30 17:47:59 oceanic kernel:d967d000 f4ef78a0 ffea 003e f4ef78a0 fe00 May 30 17:47:59 oceanic kernel: Call Trace: [] [] [] May 30 17:47:59 oceanic kernel: Code: f6 80 48 01 00 00 01 75 0a 6a 11 52 e8 37 7a 01 00 5e 5f e8 >>EIP; c0106c28<= Trace; c018cf60 Trace; c0134132 Trace; c0106e5c Code; c0106c28 <_EIP>: Code; c0106c28<= 0: f6 80 48 01 00 00 01 testb $0x1,0x148(%eax) <= Code; c0106c2f 7: 75 0a jne13 <_EIP+0x13> c0106c3b Code; c0106c31 9: 6a 11 push $0x11 Code; c0106c33 b: 52push %edx Code; c0106c34 c: e8 37 7a 01 00call 17a48 <_EIP+0x17a48> c011e670 Code; c0106c39 11: 5epop%esi Code; c0106c3a 12: 5fpop%edi Code; c0106c3b 13: e8 00 00 00 00call 18 <_EIP+0x18> c0106c40 1 warning
[CHECKER] 2.4.5-ac4 non-init functions calling init functions
Here are *uninspected* 2.4.5-ac4 results of a checker that warns when a non-__init function calls an __init function (suggested by [EMAIL PROTECTED]). There seem to be two cases: 1. The best case: the caller should actually be an __init function as well. This is a performance bug since it won't be freed. 2. The worst case: some random post-initialization routine calls an __init routine which can cause the kernel to go into hyperspace if the __init routine's code has been deleted. The current messages do not differentiate between these two cases. If these results are generally useful, I can fix up the checker, but as it now stands there shouldn't be that many false positives. Dawson MC linux bug database: http://hands.stanford.edu/linux /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/sb_card.c:757:sb_init: ERROR:INIT: non-init fn 'sb_init' using init data 'sb_isapnp_list' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/es1371.c:2898:es1371_probe: ERROR:INIT: non-init fn 'es1371_probe' calling init fn 'src_init' /u2/engler/mc/oses/linux/2.4.5-ac4/arch/i386/kernel/apm.c:1475:apm: ERROR:INIT: non-init fn 'apm' calling init fn 'apm_driver_version' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/isdn/hisax/avm_pci.c:746:AVM_card_msg: ERROR:INIT: non-init fn 'AVM_card_msg' calling init fn 'inithdlc' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/scsi/advansys.c:17836:AdvSet3550EEPConfig: ERROR:INIT: non-init fn 'AdvSet3550EEPConfig' calling init fn 'AdvWaitEEPCmd' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/sb_card.c:722:sb_init: ERROR:INIT: non-init fn 'sb_init' using init data 'sb_isapnp_list' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/scsi/advansys.c:17942:AdvSet38C1600EEPConfig: ERROR:INIT: non-init fn 'AdvSet38C1600EEPConfig' calling init fn 'AdvWaitEEPCmd' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/tokenring/ibmtr.c:635:ibmtr_probe1: ERROR:INIT: non-init fn 'ibmtr_probe1' using init data 'ibmtr_mem_base' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/arlan.c:1276:arlan_open: ERROR:INIT: non-init fn 'arlan_open' calling init fn 'arlan_probe_everywhere' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/isdn/hisax/gazel.c:565:setup_gazelpci: ERROR:INIT: non-init fn 'setup_gazelpci' using init data 'dev_tel' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/sonicvibes.c:2491:sv_probe: ERROR:INIT: non-init fn 'sv_probe' using init data 'sv_ddma_name' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/char/pcwd.c:530:get_firmware: ERROR:INIT: non-init fn 'get_firmware' calling init fn 'send_command' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/char/istallion.c:4784:stli_initbrds: ERROR:INIT: non-init fn 'stli_initbrds' calling init fn 'stli_brdinit' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/sb_card.c:782:sb_init: ERROR:INIT: non-init fn 'sb_init' using init data 'sb_isapnp_list' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/scsi/advansys.c:17833:AdvSet3550EEPConfig: ERROR:INIT: non-init fn 'AdvSet3550EEPConfig' calling init fn 'AdvWaitEEPCmd' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/ide/hd.c:915:parse_hd_setup: ERROR:INIT: non-init fn 'parse_hd_setup' calling init fn 'hd_setup' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/char/stallion.c:2681:stl_initech: ERROR:INIT: non-init fn 'stl_initech' calling init fn 'stl_mapirq' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/acenic.c:542:acenic_probe: ERROR:INIT: non-init fn 'acenic_probe' using init data 'probed' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/cs4281/cs4281m.c:4421:cs4281_probe: ERROR:INIT: non-init fn 'cs4281_probe' using init data 'initvol' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/scsi/advansys.c:17904:AdvSet38C0800EEPConfig: ERROR:INIT: non-init fn 'AdvSet38C0800EEPConfig' calling init fn 'AdvWaitEEPCmd' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/sscape.c:1504:cleanup_sscape: ERROR:INIT: non-init fn 'cleanup_sscape' using init data 'mss' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/video/cyber2000fb.c:1548:cyberpro_probe: ERROR:INIT: non-init fn 'cyberpro_probe' calling init fn 'fb_find_mode' /u2/engler/mc/oses/linux/2.4.5-ac4/arch/i386/kernel/setup.c:744:parse_mem_cmdline: ERROR:INIT: non-init fn 'parse_mem_cmdline' calling init fn 'add_memory_region' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/mpu401.c:1772:cleanup_mpu401: ERROR:INIT: non-init fn 'cleanup_mpu401' using init data 'irq' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/scsi/BusLogic.c:2395:BusLogic_InitializeHostAdapter: ERROR:INIT: non-init fn 'BusLogic_InitializeHostAdapter' calling init fn 'BusLogic_Failure' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/scsi/advansys.c:17806:AdvSet3550EEPConfig: ERROR:INIT: non-init fn 'AdvSet3550EEPConfig' calling init fn 'AdvWaitEEPCmd' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/char/pcwd.c:529:get_firmware: ERROR:INIT: non-init fn 'get_firmware' calling init fn 'send_command' /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/pnp/quirks.c:139:isapnp_fixup_device: ERROR:INIT: non-init
Re: boundary condition bug in do_mmap()
On Wed, 30 May 2001, Tania Oka wrote: > if ((offset + PAGE_ALIGN(len)) < offset) Why are you mailing this the week after it was fixed ? :) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
> There was a new 8139too driver added to the the 2.4.5 (I think) kernel > which Alan Cox took back out and reverted to the old one in his > 2.4.5-ac? versions because it is apparently causing lockups. > Shouldn't this new driver have been released in a 2.5.x development > kernel and proven there before replacing the one in the production > kernel? I haven't even seen a 2.5.x kernel released yet. Nope. The 2.4.3 one is buggy too - but differently (and it turns out a little less) buggy. Welcome to software. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wednesday 30 May 2001 01:02, Mike Galbraith wrote: > On Tue, 29 May 2001, Vincent Stemen wrote: > > On Tuesday 29 May 2001 15:16, Alan Cox wrote: > > > > a reasonably stable release until 2.2.12. I do not understand why > > > > code with such serious reproducible problems is being introduced > > > > into the even numbered kernels. What happened to the plan to use > > > > only the > > > > > > Who said it was introduced ?? It was more 'lurking' than introduced. > > > And unfortunately nobody really pinned it down in 2.4test. > > > > I fail to see the distinction. First of all, why was it ever released > > as 2.4-test? That question should probably be directed at Linus. If > > it is not fully tested, then it should be released it as an odd > > number. If it already existed in the odd numbered development kernel > > and was known, then it should have never been released as a production > > kernel until it was resolved. Otherwise, it completely defeats the > > purpose of having the even/odd numbering system. > > > > I do not expect bugs to never slip through to production kernels, but > > known bugs that are not trivial should not, and serious bugs like > > these VM problems especially should not. > > And you can help prevent them from slipping through by signing up as a > shake and bake tester. Indeed, you can make your expectations reality > absolutely free of charge, and or compensation > what a bargain! > > X ___ ;-) > > -Mike The problem is, that's not true. These problems are not slipping through because of lack of testers. As Alan said, the VM problem has been lurking, which means that it was known already. We currently have no development/production kernel distinction and I have not been able to find even one stable 2.4.x version to run on our main machines. Reverting back to 2.2.x is a real pain because of all the surrounding changes which will affect our initscripts and other system configuration issues, such as Unix98 pty's, proc filesystem differences, device numbering, etc. I have the greatest respect and appreciation for Linus, Alan, and all of the other kernel developers. My comments are not meant to criticize, but rather to point out some the problems I see that are making it so difficult to stabilize the kernel and encourage them to steer back on track. Here are some of the problems I see: There was far to long of a stretch with to much code dumped into both the 2.2 and 2.4 kernels before release. There needs to be a smaller number changes between major releases so that they can be more thoroughly tested and debugged. In the race to get it out there they are making the same mistakes as Microsoft, releasing production kernels with known serious bugs because it is taking to long and they want to move on forward. I enjoy criticizing Microsoft so much for the same thing that I do not want to have to stop in order to not sound hypocritical :-). The Linux community has built a lot of it's reputation on not making these mistakes. Please lets try not to destroy that. They are disregarding the even/odd versioning system. For example: There was a new 8139too driver added to the the 2.4.5 (I think) kernel which Alan Cox took back out and reverted to the old one in his 2.4.5-ac? versions because it is apparently causing lockups. Shouldn't this new driver have been released in a 2.5.x development kernel and proven there before replacing the one in the production kernel? I haven't even seen a 2.5.x kernel released yet. Based on Linus's original very good plan for even/odd numbers, there should not have been 2.4.0-test? kernels either. This was another example of the rush to increment to 2.4 long before it was ready. There was a long stretch of test kernels and and now we are all the way to 2.4.5 and it is still not stable. We are repeating the 2.2.x process all over again. It should have been 2.3.x until the production release was ready. If they needed to distinguish a code freeze for final testing, it could be done with a 4th version component (2.3.xx.xx), where the 4 component is incremented for final bug fixes. - Vincent Stemen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
Marcus Meissner wrote: > $ ln -s fupp/bar bar > $ ls -la bar --- Is it peculiar to a specific architecture? What does strace show for args to the symlink cmd? -l -- The above thoughts and | They may have nothing to do with writings are my own. | the opinions of my employer. :-) L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.5 -ac series broken on Sparc64
Alan Cox responded to: > Leif Sawyer, who wrote: >> include/linux/irq.h:61: asm/hw_irq.h: No such file or directory >> *** [sched.o] Error 1 >> >> a find . -name 'hw_irq.h' shows appropriate versions >> in i386, ia64, mips, mips64, alpha, ppc, parisc, um, and sh >> > The sparc64 tree isnt very well integrated with -ac. What I > have I merge but where -ac varies from the Linus tree or the > Linus tree requires new files tends to break it. > > It can probably be an empty file This worked for me: sed 's/_SH_/_SPARC64_/g' include/asm-sh/hw_irq.h > include/asm-sparc64/hw_irq.h make mrproper cp ../.config . make oldconfig make dep && make In file included from /usr/src/linux-2.4.5-ac4/include/linux/sched.h:9 /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: which is probably not what you want. This warning is repeated for quite a good portion of the source files during the make process, however the kernel seems to build correctly. Haven't tried a reboot though.. :-\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
On Wed, May 30, 2001 at 07:24:30PM +0100, Alan Cox wrote: > > I downloaded the linux 2.4.5 sources and built and installed them on my > > system. Since then, I've noticed strange file system behavior: > > What file system. Its find on my 2.4.5-ac with ext2 Filesystem: ext2 Architecture: i386 CPU: AMD K6-II Christopher Cole mentioned that he saw this problem, but it went away after a reboot. I rebooted into 2.4.5 again and the problem seemed to have gone away. But now, I got something else something that looks like a kernel Ooops. I was running automake and got the following: kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 ... I'm gonna try 2.4.4 for now. But if anyone is interested in looking into this deeper, I can send the whole "oops" message and whatever other info needed to debug this. -- Edsel Adap [EMAIL PROTECTED] http://www.adap.org/~edsel/ LINUX - the choice of the GNU generation "Netscape is an application which grows to fill all available memory." - me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.x: update for PCI vendor id 0x12d4
[Updated patch is in the end of this mail] Thanks, Mark! > submit patches as text in your message, since people want > to read them, and not waste time saving to a file, etc. > also, explain patches: who is vid 0x12d4, how did you get > the information, what does it effect, etc. BTW I noticed a funny thing: the file devlist.h I tried to patch doesn't always exist - as it gets built from the file pci.ids in the same directory. Noone complained on that :) What I don't understand is why pci_ids.h doesn't get generated from pci.ids as well. So, here's the new patch, sent along also to the pci.ids maintainer, along with the required info. 12d4 was DGM Then DGM was aquired by Comverse, and later the corresponding activities (and the same PCI boards manufacturing) went to Comverse spinoff Ulticom. So, in fact, Ulticom is just DGM under a different name and controlled by Comverse. I guess the PCI vendor registry should get updated at some point, but I thought it could be a great thing if Linux knew it ahead. (Currently reported by the PCI driver "DGM" is obsolete - such entity doesn't exist any more). Naturally, I have got this info being a Comverse employee. This patch only has effect on kernel PCI driver reporting on the 12d4 vendor ID. There is no Linux kernel code which supports the corresponding SS7 signalling boards. Kind regards, Vassilii --- /usr/src/linux-2.4.5/include/linux/pci_ids.hWed May 16 13:25:39 2001 +++ pci_ids.h Wed May 30 14:55:01 2001 @@ -1199,6 +1199,8 @@ #define PCI_VENDOR_ID_NVIDIA_SGS 0x12d2 #define PCI_DEVICE_ID_NVIDIA_SGS_RIVA128 0x0018 +#define PCI_VENDOR_ID_ULTICOM 0x12d4 /* Formerly DGM */ + #define PCI_SUBVENDOR_ID_CHASE_PCIFAST 0x12E0 #define PCI_SUBDEVICE_ID_CHASE_PCIFAST40x0031 #define PCI_SUBDEVICE_ID_CHASE_PCIFAST80x0021 --- /usr/src/linux-2.4.5/drivers/pci/pci.idsSat May 19 20:49:14 2001 +++ pci.ids Wed May 30 14:54:50 2001 @@ -3204,7 +3204,7 @@ 002c VTNT2 00a0 ITNT2 12d3 Vingmed Sound A/S -12d4 DGM +12d4 Ulticom (Formerly DGM) 12d5 Equator Technologies 12d6 Analogic Corp 12d7 Biotronic SRL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 4GB I/O, cut three
On Wed, 30 May 2001, Andrea Arcangeli wrote: > On Wed, May 30, 2001 at 08:57:50PM +0200, Yoann Vandoorselaere wrote: > > I remember the 2.3.51 kernel as the most usable kernel I ever used > > talking about VM. > > I also don't remeber anything strange in that kernel about the VM (I > instead remeber well the VM breakage introduced in 2.3.99-pre). > > Regardless of what 2.3.51 was doing, the falling back into the lower > zones before starting the balancing is fine. The problem with 2.3.51 was that it started balancing the HIGHMEM zone before falling back. On a 1GB system this lead not only to the system starting to swap as soon as the 128MB highmem zone was filled up, it also resulted in the other 900MB being essentially unused. Having your 1GB system running as if it had 128MB definately can be classified as Not Fun. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
In article <[EMAIL PROTECTED]> you wrote: >> I downloaded the linux 2.4.5 sources and built and installed them on my >> system. Since then, I've noticed strange file system behavior: > What file system. Its find on my 2.4.5-ac with ext2 100% reproducible on NFS and EXT2 here, with following: $ ln -s fupp/bar bar $ ls -la bar lrwxrwxrwx 1 marcus users 3 May 30 20:30 bar -> bar $ Ciao, Marcus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM
On Wed, 30 May 2001, Mike Galbraith wrote: > I wouldn't go so far as to say totally broken (mostly because I've > tried like _hell_ to find a better way, and [despite minor successes] > I've not been able to come up with something which covers all cases > that even _I_ [hw tech] can think of well). The "easy way out" seems to be physical -> virtual page reverse mappings, these make it trivial to apply balanced pressure on all pages. The downside of this measure is that it costs additional overhead and can up to double the amount of memory we take in with page tables. Of course, this amount is only prohibitive if the amount of page table memory was also prohibitively large in the first place, but ... :) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 4GB I/O, cut three
On Wed, May 30, 2001 at 08:57:50PM +0200, Yoann Vandoorselaere wrote: > I remember the 2.3.51 kernel as the most usable kernel I ever used > talking about VM. I also don't remeber anything strange in that kernel about the VM (I instead remeber well the VM breakage introduced in 2.3.99-pre). Regardless of what 2.3.51 was doing, the falling back into the lower zones before starting the balancing is fine. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOpses in memory allocator with 2.4.5-ac2
Following is a series of oopses that kept my server not responding for a while this morning. Running lots of services amoung them a hub for the openproject IRC network: May 30 07:58:01 melchi kernel: invalid operand: May 30 07:58:01 melchi kernel: CPU:0 May 30 07:58:01 melchi kernel: EIP:0010:[rmqueue+552/592] May 30 07:58:01 melchi kernel: EFLAGS: 00010202 May 30 07:58:01 melchi kernel: eax: 0048 ebx: 0002 ecx: c01d9e54 edx: 4000 May 30 07:58:01 melchi kernel: esi: c10bca18 edi: c01d9e84 ebp: 0001 esp: c241fef8 May 30 07:58:01 melchi kernel: ds: 0018 es: 0018 ss: 0018 May 30 07:58:01 melchi kernel: Process cron (pid: 238, stackpage=c241f000) May 30 07:58:01 melchi kernel: Stack: c01d9e54 c01da04c 0002 0001 1c62 0282 c01d9e84 0001 May 30 07:58:01 melchi kernel:c01d9e54 c01231d1 0080 c01da054 0001 c241ffbc c012328f c01da048 May 30 07:58:01 melchi kernel:0001 0002 c241e000 c241e000 c241ffa8 c241ffbc 0007 May 30 07:58:01 melchi kernel: Call Trace: [__alloc_pages_limit+105/128] [__alloc_pages+167/556] [__get_free_pages+20/32] [do_fork+140/1632] [sys_fork+20/28] May 30 07:58:01 melchi kernel:[system_call+51/64] May 30 07:58:01 melchi kernel: May 30 07:58:01 melchi kernel: Code: 0f 0b 89 f0 eb 1a 47 83 44 24 18 0c 83 ff 09 0f 86 eb fd ff May 30 07:59:10 melchi kernel: invalid operand: May 30 07:59:10 melchi kernel: CPU:0 May 30 07:59:10 melchi kernel: EIP:0010:[rmqueue+552/592] May 30 07:59:10 melchi kernel: EFLAGS: 00010202 May 30 07:59:10 melchi kernel: eax: 0048 ebx: 0002 ecx: c01d9e54 edx: 4000 May 30 07:59:10 melchi kernel: esi: c10c3018 edi: c01d9e84 ebp: 0001 esp: c1e6bf1c May 30 07:59:10 melchi kernel: ds: 0018 es: 0018 ss: 0018 May 30 07:59:10 melchi kernel: Process apache (pid: 264, stackpage=c1e6b000) May 30 07:59:10 melchi kernel: Stack: 0060 c01da04c 0001 c1e6bfbc 1de2 0292 c01d9e84 0001 May 30 07:59:10 melchi kernel:c01d9e54 c0123241 c1e6a000 c1e6a000 c1e6bfa8 c1e6bfbc 0007 May 30 07:59:10 melchi kernel:c01da048 c0123428 c010f6e8 c1e6a000 0002 bc5c c1e6bfbc c1e6bf94 May 30 07:59:10 melchi kernel: Call Trace: [__alloc_pages+89/556] [__get_free_pages+20/32] [do_fork+140/1632] [sys_fork+20/28] [system_call+51/64] May 30 07:59:10 melchi kernel:[startup_32+43/165] May 30 07:59:10 melchi kernel: May 30 07:59:10 melchi kernel: Code: 0f 0b 89 f0 eb 1a 47 83 44 24 18 0c 83 ff 09 0f 86 eb fd ff May 30 07:59:17 melchi kernel: invalid operand: May 30 07:59:17 melchi kernel: CPU:0 May 30 07:59:17 melchi kernel: EIP:0010:[rmqueue+552/592] May 30 07:59:17 melchi kernel: EFLAGS: 00010202 May 30 07:59:17 melchi kernel: eax: 004c ebx: 0001 ecx: c01d9e54 edx: 4000 May 30 07:59:17 melchi kernel: esi: c10be310 edi: c01d9e78 ebp: esp: c0f9dd3c May 30 07:59:17 melchi kernel: ds: 0018 es: 0018 ss: 0018 May 30 07:59:17 melchi kernel: Process apache (pid: 6325, stackpage=c0f9d000) May 30 07:59:17 melchi kernel: Stack: 0060 c01d9ffc 00041704 1cc0 0292 c01d9e78 May 30 07:59:17 melchi kernel:c01d9e54 c0123241 1000 00041704 0003 0001 May 30 07:59:17 melchi kernel:c01d9ff8 c012b4ee 0006 1601 00041704 c01298f1 May 30 07:59:17 melchi kernel: Call Trace: [__alloc_pages+89/556] [grow_buffers+62/320] [refill_freelist+41/84] [getblk+242/264] [ext2_getblk+123/316] May 30 07:59:17 melchi kernel:[ext2_getblk+123/316] [cached_lookup+16/84] [path_walk+1569/1768] [ext2_find_entry+121/776] [cached_lookup+16/84] [ext2_lookup+48/128] May 30 07:59:17 melchi kernel:[real_lookup+83/196] [path_walk+1225/1768] [open_namei+120/1376] [filp_open+51/84] [sys_open+54/152] [system_call+51/64] May 30 07:59:17 melchi kernel:[startup_32+43/165] May 30 07:59:17 melchi kernel: May 30 07:59:17 melchi kernel: Code: 0f 0b 89 f0 eb 1a 47 83 44 24 18 0c 83 ff 09 0f 86 eb fd ff May 30 07:59:26 melchi kernel: invalid operand: May 30 07:59:26 melchi kernel: CPU:0 May 30 07:59:26 melchi kernel: EIP:0010:[rmqueue+552/592] May 30 07:59:26 melchi kernel: EFLAGS: 00010202 May 30 07:59:26 melchi kernel: eax: 004c ebx: 0001 ecx: c01d9e54 edx: 4000 May 30 07:59:26 melchi kernel: esi: c10d5a20 edi: c01d9e78 ebp: esp: c0f9fe88 May 30 07:59:26 melchi kernel: ds: 0018 es: 0018 ss: 0018 May 30 07:59:26 melchi kernel: Process apache (pid: 6324, stackpage=c0f9f000) May 30 07:59:26 melchi kernel: Stack: 0060 c01da024 0001 2244 0282 c01d9e84 May 30 07:59:26 melchi kernel:c01d9e54 c0123241 c1025e38 c110 0001 0005 0001 May 30 07:59:26 melchi kernel:c01da020 c011a0d6 080f301c c1d22540 0001 c011a7cb c1d22540 May 30
Re: [patch] 4GB I/O, cut three
On Wed, May 30, 2001 at 03:42:51PM -0300, Rik van Riel wrote: > On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: > > > btw, I think such heuristic is horribly broken ;), the highmem zone > > simply needs to be balanced if it is under the pages_low mark, just > > skipping it and falling back into the normal zone that happens to be > > above the low mark is the wrong thing to do. > > 2.3.51 did this, we all know the result. I've no idea about what 2.3.51 does, but I was obviously wrong about that. Forget such what I said above. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 4GB I/O, cut three
Rik van Riel <[EMAIL PROTECTED]> writes: > On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: > > > btw, I think such heuristic is horribly broken ;), the highmem zone > > simply needs to be balanced if it is under the pages_low mark, just > > skipping it and falling back into the normal zone that happens to be > > above the low mark is the wrong thing to do. > > 2.3.51 did this, we all know the result. Just a note, I remember the 2.3.51 kernel as the most usable kernel I ever used talking about VM. -- Yoann Vandoorselaere | C makes it easy to shoot yourself in the foot. C++ makes MandrakeSoft | it harder, but when you do, it blows away your whole | leg. - Bjarne Stroustrup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM
On Wed, 30 May 2001, Rik van Riel wrote: > On Wed, 30 May 2001, Marcelo Tosatti wrote: > > > The problem is that we allow _every_ task to age pages on the system > > at the same time --- this is one of the things which is fucking up. > > This should not have any effect on the ratio of cache > reclaiming vs. swapout use, though... Sure, who said that ? :) The current discussion between Mike/Jonathan and me is about the aging issue. > > > The another problem is that don't limit the writeout in the VM. > > This is a big problem too, but also unrelated to the > impossibility of balancing cache vs. swap in the current > scheme. ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 4GB I/O, cut three
On Wed, 30 May 2001, Jens Axboe wrote: > You are right, this is definitely something that needs checking. I > really want this to work though. Rik, Andrea? Will the balancing > handle the extra zone? In as far as it handles balancing the current zones, it'll also work with one more. In places where it's currently broken it will probably also break with one extra zone, though the fact that the DMA32 zone takes the pressure off the NORMAL zone might actually help. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 4GB I/O, cut three
On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: > btw, I think such heuristic is horribly broken ;), the highmem zone > simply needs to be balanced if it is under the pages_low mark, just > skipping it and falling back into the normal zone that happens to be > above the low mark is the wrong thing to do. 2.3.51 did this, we all know the result. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 245-ac4
> Hi all,
>
> This patch remove some NULL parameters tests in kfree-like functions and
> add this directly in function.
>
> - dev_kfree_skb_irq == dev_kfree_skb == kfree_skb
> - kfree already handle null parameters :
> void kfree (const void *objp)
> {
> kmem_cache_t *c;
> unsigned long flags;
>
> >> if (!objp)
> >> return;
>
>local_irq_save(flags);
> CHECK_PAGE(virt_to_page(objp));
> c = GET_PAGE_CACHE(virt_to_page(objp));
> __kmem_cache_free(c, (void*)objp);
> local_irq_restore(flags);
> }
This is bad. It will only slow thing down.
It will also hide allocation errors in the rest of the kernel. A bug that
causes crash is much better than the one that doesn't.
Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM
On Wed, 30 May 2001, Marcelo Tosatti wrote: > The problem is that we allow _every_ task to age pages on the system > at the same time --- this is one of the things which is fucking up. This should not have any effect on the ratio of cache reclaiming vs. swapout use, though... > The another problem is that don't limit the writeout in the VM. This is a big problem too, but also unrelated to the impossibility of balancing cache vs. swap in the current scheme. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cs46xx oops in 2.4.5-ac4
Since upgrading to 2.4.5-ac4 the Crystal Soundfusion card in my Thinkpad 600X has stopped working. Trying to play an audio file (with /usr/bin/play from sox 12.16) gives me an oops. Here is the init stuff from dmesg for the sound card: Crystal 4280/46xx + AC97 Audio, version 1.27.32, 13:05:58 May 29 2001 cs46xx: Card found at 0x5010 and 0x5000, IRQ 11 cs46xx: Thinkpad 600X/A20/T20 (1014:0153) at 0x5010/0x5000, IRQ 11 ac97_codec: AC97 Audio codec, id: 0x4352:0x5913 (Cirrus Logic CS4297A rev A) And here is the oops info from ksymoops (apologies if my email program wraps any lines; I intend to start using a decent mail program Real Soon Now): ksymoops 2.4.1 on i686 2.4.5-ac4. Options used -v /usr/src/linux-2.4.5-ac4/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac4/ (default) -m /usr/src/linux/System.map (default) Unable to handle kernel NULL pointer dereference at virtual address *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: ccf7d884 ebx: ecx: 0286 edx: cca43f2c esi: cca43f24 edi: ccf7d880 ebp: cca43f24 esp: cca43f08 ds: 0018 es: 0018 ss: 0018 Process sox (pid: 186, stackpage=cca43000) Stack: ccf7d878 cca42000 c0105938 ffea cdcf7a20 1000 ccf7d7f0 0001 cca42000 ccf7d884 c0105aa8 ccf7d878 ccf7d7c0 cdcf7a40 d0c75678 ffea cdcf7a20 1000 b870 ccf7d7f0 0001 0018 Call Trace: [] [] [] [] [] [] Code: 89 13 51 9d 5b 5e c3 90 9c 58 fa 8b 4a 0c 8b 52 08 89 4a 04 >>EIP; c0111f34<= Trace; c0105938 <__down+4c/a8> Trace; c0105aa8 <__down_failed+8/c> Trace; d0c75678 <[cs46xx].text.end+74/1dc> Trace; c01225cb Trace; c012dd66 Trace; c0106b27 Code; c0111f34 <_EIP>: Code; c0111f34<= 0: 89 13 mov%edx,(%ebx) <= Code; c0111f36 2: 51push %ecx Code; c0111f37 3: 9dpopf Code; c0111f38 4: 5bpop%ebx Code; c0111f39 5: 5epop%esi Code; c0111f3a 6: c3ret Code; c0111f3b 7: 90nop Code; c0111f3c 8: 9cpushf Code; c0111f3d 9: 58pop%eax Code; c0111f3e a: facli Code; c0111f3f b: 8b 4a 0c mov0xc(%edx),%ecx Code; c0111f42 e: 8b 52 08 mov0x8(%edx),%edx Code; c0111f45 11: 89 4a 04 mov%ecx,0x4(%edx) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
> I downloaded the linux 2.4.5 sources and built and installed them on my > system. Since then, I've noticed strange file system behavior: What file system. Its find on my 2.4.5-ac with ext2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 4 security holes in 2.4.4-ac8
On Tue, May 29, 2001 at 03:00:56PM -0700, Dawson Engler wrote:
> -
> [BUG] ./drivers/usb/bluetooth.c: dereference of 'buf' at the beginning of
> the switch, and then does a copyin.
This is a real bug, thanks.
The attached patch, against the latest -ac tree should fix it.
greg k-h
diff -Nru a/drivers/usb/bluetooth.c b/drivers/usb/bluetooth.c
--- a/drivers/usb/bluetooth.c Wed May 30 11:10:08 2001
+++ b/drivers/usb/bluetooth.c Wed May 30 11:10:08 2001
@@ -1,11 +1,20 @@
/*
- * bluetooth.c Version 0.9
+ * bluetooth.c Version 0.10
*
* Copyright (c) 2000, 2001 Greg Kroah-Hartman <[EMAIL PROTECTED]>
* Copyright (c) 2000 Mark Douglas Corner <[EMAIL PROTECTED]>
*
* USB Bluetooth driver, based on the Bluetooth Spec version 1.0B
*
+ * (2001/05/28) Version 0.10 gkh
+ * - Fixed problem with using data from userspace in the bluetooth_write
+ * function as found by the CHECKER project.
+ * - Added a buffer to the write_urb_pool which reduces the number of
+ * buffers being created and destroyed for ever write. Also cleans
+ * up the logic a bit.
+ * - Added a buffer to the control_urb_pool which fixes a memory leak
+ * when the device is removed from the system.
+ *
* (2001/05/28) Version 0.9 gkh
* Fixed problem with bluetooth==NULL for bluetooth_read_bulk_callback
* which was found by both the CHECKER project and Mikko Rahkonen.
@@ -101,7 +110,7 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v0.9"
+#define DRIVER_VERSION "v0.10"
#define DRIVER_AUTHOR "Greg Kroah-Hartman, Mark Douglas Corner"
#define DRIVER_DESC "USB Bluetooth driver"
@@ -264,7 +273,7 @@
}
-static int bluetooth_ctrl_msg (struct usb_bluetooth *bluetooth, int request, int
value, void *buf, int len)
+static int bluetooth_ctrl_msg (struct usb_bluetooth *bluetooth, int request, int
+value, const unsigned char *buf, int len)
{
struct urb *urb = NULL;
devrequest *dr = NULL;
@@ -286,11 +295,23 @@
return -ENOMEM;
}
- /* free up the last buffer that this urb used */
- if (urb->transfer_buffer != NULL) {
- kfree(urb->transfer_buffer);
- urb->transfer_buffer = NULL;
+ /* keep increasing the urb transfer buffer to fit the size of the message */
+ if (urb->transfer_buffer == NULL) {
+ urb->transfer_buffer = kmalloc (len, GFP_KERNEL);
+ if (urb->transfer_buffer == NULL) {
+ err (__FUNCTION__" - out of memory");
+ return -ENOMEM;
+ }
+ }
+ if (urb->transfer_buffer_length < len) {
+ kfree (urb->transfer_buffer);
+ urb->transfer_buffer = kmalloc (len, GFP_KERNEL);
+ if (urb->transfer_buffer == NULL) {
+ err (__FUNCTION__" - out of memory");
+ return -ENOMEM;
+ }
}
+ memcpy (urb->transfer_buffer, buf, len);
dr->requesttype = BLUETOOTH_CONTROL_REQUEST_TYPE;
dr->request = request;
@@ -299,14 +320,14 @@
dr->length = cpu_to_le16p();
FILL_CONTROL_URB (urb, bluetooth->dev, usb_sndctrlpipe(bluetooth->dev, 0),
- (unsigned char*)dr, buf, len, bluetooth_ctrl_callback,
bluetooth);
+ (unsigned char*)dr, urb->transfer_buffer, len,
+bluetooth_ctrl_callback, bluetooth);
/* send it down the pipe */
status = usb_submit_urb(urb);
if (status)
dbg(__FUNCTION__ " - usb_submit_urb(control) failed with status = %d",
status);
- return 0;
+ return status;
}
@@ -405,12 +426,13 @@
{
struct usb_bluetooth *bluetooth = get_usb_bluetooth ((struct usb_bluetooth
*)tty->driver_data, __FUNCTION__);
struct urb *urb = NULL;
- unsigned char *new_buffer;
+ unsigned char *temp_buffer = NULL;
+ const unsigned char *current_buffer;
const unsigned char *current_position;
- int status;
int bytes_sent;
int buffer_size;
int i;
+ int retval = 0;
if (!bluetooth) {
return -ENODEV;
@@ -440,38 +462,39 @@
printk ("\n");
#endif
- switch (*buf) {
+ if (from_user) {
+ temp_buffer = kmalloc (count, GFP_KERNEL);
+ if (temp_buffer == NULL) {
+ err (__FUNCTION__ "- out of memory.");
+ retval = -ENOMEM;
+ goto exit;
+ }
+ copy_from_user (temp_buffer, buf, count);
+ current_buffer = temp_buffer;
+ } else {
+ current_buffer = buf;
+ }
+
+ switch (*current_buffer) {
/* First byte indicates the type of packet */
case CMD_PKT:
/*
[PATCH] 245-ac4
Hi all,
This patch remove some NULL parameters tests in kfree-like functions and add this
directly in function.
- dev_kfree_skb_irq == dev_kfree_skb == kfree_skb
- kfree already handle null parameters :
void kfree (const void *objp)
{
kmem_cache_t *c;
unsigned long flags;
>> if (!objp)
>> return;
local_irq_save(flags);
CHECK_PAGE(virt_to_page(objp));
c = GET_PAGE_CACHE(virt_to_page(objp));
__kmem_cache_free(c, (void*)objp);
local_irq_restore(flags);
}
diff -ur --exclude=*~ --exclude=*.rej linux-245ac/arch/i386/kernel/mtrr.c
linux-245ac-carlos/arch/i386/kernel/mtrr.c
--- linux-245ac/arch/i386/kernel/mtrr.c Thu May 24 18:14:08 2001
+++ linux-245ac-carlos/arch/i386/kernel/mtrr.c Wed May 30 13:25:13 2001
@@ -966,7 +966,7 @@
/* Free resources associated with a struct mtrr_state */
static void __init finalize_mtrr_state(struct mtrr_state *state)
{
-if (state->var_ranges) kfree (state->var_ranges);
+kfree (state->var_ranges);
} /* End Function finalize_mtrr_state */
diff -ur --exclude=*~ --exclude=*.rej linux-245ac/arch/ia64/kernel/efivars.c
linux-245ac-carlos/arch/ia64/kernel/efivars.c
--- linux-245ac/arch/ia64/kernel/efivars.c Thu Apr 5 15:51:47 2001
+++ linux-245ac-carlos/arch/ia64/kernel/efivars.c Wed May 30 13:25:29 2001
@@ -163,8 +163,8 @@
efivar_entry_t *new_efivar = kmalloc(sizeof(efivar_entry_t),
GFP_KERNEL);
if (!short_name || !new_efivar) {
- if (short_name)kfree(short_name);
- if (new_efivar)kfree(new_efivar);
+ kfree(short_name);
+ kfree(new_efivar);
return 1;
}
memset(short_name, 0, short_name_size+1);
diff -ur --exclude=*~ --exclude=*.rej linux-245ac/arch/sparc64/kernel/ioctl32.c
linux-245ac-carlos/arch/sparc64/kernel/ioctl32.c
--- linux-245ac/arch/sparc64/kernel/ioctl32.c Wed May 30 14:03:46 2001
+++ linux-245ac-carlos/arch/sparc64/kernel/ioctl32.cWed May 30 13:27:53 2001
@@ -1024,10 +1024,10 @@
if (err)
err = -EFAULT;
-out: if (cmap.red) kfree(cmap.red);
- if (cmap.green) kfree(cmap.green);
- if (cmap.blue) kfree(cmap.blue);
- if (cmap.transp) kfree(cmap.transp);
+out: kfree(cmap.red);
+ kfree(cmap.green);
+ kfree(cmap.blue);
+ kfree(cmap.transp);
return err;
}
@@ -1356,7 +1356,7 @@
if (err)
err = -EFAULT;
-out: if (karg) kfree(karg);
+out: kfree(karg);
return err;
}
@@ -,6 +,7 @@
static void put_lv_t(lv_t *l)
{
+ if(!l) return;
if (l->lv_current_pe) vfree(l->lv_current_pe);
if (l->lv_block_exception) vfree(l->lv_block_exception);
kfree(l);
diff -ur --exclude=*~ --exclude=*.rej linux-245ac/arch/um/fs/hostfs/hostfs_kern.c
linux-245ac-carlos/arch/um/fs/hostfs/hostfs_kern.c
--- linux-245ac/arch/um/fs/hostfs/hostfs_kern.c Wed May 30 04:19:34 2001
+++ linux-245ac-carlos/arch/um/fs/hostfs/hostfs_kern.c Wed May 30 13:24:24 2001
@@ -110,7 +110,7 @@
void hostfs_delete_inode(struct inode *ino)
{
- if(ino->u.generic_ip) kfree(ino->u.generic_ip);
+ kfree(ino->u.generic_ip);
ino->u.generic_ip = NULL;
clear_inode(ino);
}
diff -ur --exclude=*~ --exclude=*.rej linux-245ac/arch/um/kernel/process_kern.c
linux-245ac-carlos/arch/um/kernel/process_kern.c
--- linux-245ac/arch/um/kernel/process_kern.c Wed May 30 04:19:34 2001
+++ linux-245ac-carlos/arch/um/kernel/process_kern.cWed May 30 13:24:49 2001
@@ -584,7 +584,7 @@
if(t == NULL) task = current;
else task = t;
- if(task->thread.altstack != NULL) kfree(task->thread.altstack);
+ kfree(task->thread.altstack);
n = PAGE_SIZE - (sp & ~PAGE_MASK);
stack = kmalloc(n, GFP_KERNEL);
if(stack == NULL) panic("save_altstack : kmalloc failed");
diff -ur --exclude=*~ --exclude=*.rej linux-245ac/drivers/atm/ambassador.c
linux-245ac-carlos/drivers/atm/ambassador.c
--- linux-245ac/drivers/atm/ambassador.cWed May 30 04:19:34 2001
+++ linux-245ac-carlos/drivers/atm/ambassador.c Wed May 30 13:36:53 2001
@@ -458,6 +458,7 @@
/** free an skb (as per ATM device driver documentation) **/
static inline void amb_kfree_skb (struct sk_buff * skb) {
+ if(!skb) return;
if (ATM_SKB(skb)->vcc->pop) {
ATM_SKB(skb)->vcc->pop (ATM_SKB(skb)->vcc, skb);
} else {
diff -ur --exclude=*~ --exclude=*.rej linux-245ac/drivers/atm/eni.c
linux-245ac-carlos/drivers/atm/eni.c
--- linux-245ac/drivers/atm/eni.c Wed May 16 13:22:50 2001
+++ linux-245ac-carlos/drivers/atm/eni.cWed May 30 13:58:15 2001
@@ -487,7 +487,7 @@
if (paddr)
pci_unmap_single(eni_dev->pci_dev,paddr,skb->len,
PCI_DMA_FROMDEVICE);
- if (skb) dev_kfree_skb_irq(skb);
+ dev_kfree_skb_irq(skb);
Athlon fast_copy_page revisited
Hi. A few weeks ago there was a discussion centering on the Athlon-optimized fast_copy_page routine and how the prefetch might be causing problems on Via motherboards. Unfortunately Alan's proposed fixes (to not prefetch the final 320 bytes) don't seem to help...at least on my iWill KT-133A system as recent as 2.4.5-ac1. Since Alan's code looks like it prevents the possibility of prefetching too much data, it seems something else must be the culprit. Arjan posted a link to a user-space program that benchmarks various *_clear_page and *_copy_page schemes. I spent yesterday evening playing with this. On a whim, I added some NOP statements to the even_faster copy_page routine. Imagine my surprise when I found that the NOP-modified routine showed the highest throughput of all the *_copy_page routines, consistently beating the other optimized routines by sometimes 10% or more (but generally between 2-5%). On my two Athlon machines (both socket-A thunderbirds), I found that I got the best scores if I grouped the MOVQ and MOVNTQ operations into sets of 4. It's interesting to note that I don't run into any problems running any of the *_copy_page schemes in user-space but if I try in kernel space, I get the notorious crash inside fast_copy_page. (If there was some sort of fundamental hardware problem associated with prefetch or streaming, wouldn't it also show up in user-space?) Note: I've yet to try the NOP-modified routines in kernel-space. I've tried this benchmark on 4 Athlon/Duron machines now (2 Socket-A Thunderbirds, 1 Socket-A Duron and 1 Slot-A Athlon). Each of the Socket-A machines showed improvement using the NOP-modified routines while the Slot-A machine performed better with the original 3DNow routine. Arjan's original code is at: http://www.fenrus.demon.nl/athlon.c My modifications are at: http://sackheads.org/~mayfield/jrm_athlon.c Example test runs: copy_page() tests copy_page function 'warm up run' took 21350 cycles per page copy_page function '2.4 non MMX' took 27706 cycles per page copy_page function '2.4 MMX fallback'took 28600 cycles per page copy_page function '2.4 MMX version' took 21370 cycles per page copy_page function 'faster_copy' took 13119 cycles per page copy_page function 'even_faster' took 14767 cycles per page copy_page function 'jrm_copy_page_8nop' took 12774 cycles per page copy_page function 'jrm_copy_page_10nop' took 12746 cycles per page copy_page function 'jrm_copy_page_12nop' took 12740 cycles per page copy_page() tests copy_page function 'warm up run' took 22499 cycles per page copy_page function '2.4 non MMX' took 27769 cycles per page copy_page function '2.4 MMX fallback'took 27696 cycles per page copy_page function '2.4 MMX version' took 22666 cycles per page copy_page function 'faster_copy' took 13058 cycles per page copy_page function 'even_faster' took 13169 cycles per page copy_page function 'jrm_copy_page_8nop' took 12691 cycles per page copy_page function 'jrm_copy_page_10nop' took 12750 cycles per page copy_page function 'jrm_copy_page_12nop' took 14786 cycles per page The values obviously fluctuate depending on system activity but the jrm_* routines were faster in 13 out of 15 trials. - Jimmie -- Jimmie Mayfield http://www.sackheads.org/mayfield email: [EMAIL PROTECTED] My mail provider does not welcome UCE -- http://www.sackheads.org/uce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: POSIX/1003.b/whatever docs free?
if you go to opengroup.org you can read the single-unix standard for free... you need to register though. (it's not quite the same as POSIX...) -dean On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: > Is there somewhere I can download the collection of POSIX standards docs > free of charge? > > ;-) > > Thankyou, > James > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: via-rhine DFE-530TX rev A1
On Wed, 30 May 2001, Rose, Daniel wrote: > It seems as though my card will not reset anymore after running windows 98, > even after a cold boot, and recompiling the kernel. Below is the output of > dmesg, lspci -n and ifconfig. Does anyone have any ideas? (please cc > replies) Have you tried cutting power to the machine? (ie physically unplugging it) Someone has claimed that the chip may not reset otherwise. As it is Wake-On-Lan capable, that sort of makes sense - it needs to be not entirely dead. > via-rhine.c:v1.08b-LK1.1.8 4/17/2000 Written by Donald Becker > http://www.scyld.com/network/via-rhine.html > PCI: Found IRQ 10 for device 00:11.0 > PCI: The same IRQ used for device 00:07.2 > eth0: VIA VT6102 Rhine-II at 0xd000, 00:00:00:00:00:00, IRQ 10. [snip] > 00:11.0 Class 0200: 1106:3065 (rev 42) Are you sure the card is marked rev-A1 and not rev-B1? I was hoping DFE-530TXs with vt6102 were all rev-B1. Can you check what's printed on the card and send me the markings on the main chips? (one is probably marked DL10030, DL10030A or possibly vt6102 with a big VIA logo) /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pte_page
On Wed, 30 May 2001, Pete Wyckoff wrote: > > __pa(page_address(pte_page(pte))) is the address you want. [or > > pte_val(*pte) & (PAGE_SIZE-1) on x86 but this is platform-dependent.] > > Does this work on x86 non-kmapped highmem user pages too? (i.e. is > page->virtual valid for every potential user page.) you are right, the highmem-compatible solution is to use page-mem_map as the physical page index. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Zerocopy NBD
On Wed, 30 May 2001, Steve Whitehouse wrote: > Hi, > > > > > On Wed, 30 May 2001, Steve Whitehouse wrote: > > > > [info about NBD patch deleted] > > > > > Cool. > > > > Are you seeing performance improvements with the patch ? > > > > Yes, but my testing is not in anyway complete yet. The only network device > I have which is supported by zerocopy is loopback and there appear to be > problems with deadlocks when using NBD over loopback. So what I did was to > modify the NBD server (the userland one from Pavel Machek's web site) > so that it didn't actually do any disk I/O. It still copied the data from > the network into a buffer on write and it returns zeroed buffers on read > (not that thats important as only the write patch is affected in the patch). > > I could then test using dd which is a bit artificial in that it creates > large requests giving probably much more data per NBD request than would > be usual under a filesystem load and hence also better with the zerocopy > patch. A timed dd with 10 blocks of 1k spent 1.2 secs of system time > to do the write with NBD in 2.4.5 and 0.8 secs with my patch. Copying bunchs of sequential data with 'dd' is OK for testing it --- you're trying to measure only device speed, not fs speed. > Also it may well be possible to adjust the network stack's memory management > to give better performance. I upped the values in tcp_[r|w]mem but I've > not checked what different vaules would do to those figures. > > I want to do some more testing though in case I've made an error somewhere > in the method. I'd be particularly interested to hear from someone who > has any results for real hardware. If I have time I'll look into whether > the eepro100 or SysKonnect GigE cards could be made to support zerocopy > as they are the ones I have here, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ln -s broken on 2.4.5
On Wed, 30 May 2001, Edsel Adap wrote: > I downloaded the linux 2.4.5 sources and built and installed them on my > system. Since then, I've noticed strange file system behavior: > marvin:/tmp> ln -s foo bar > lrwxrwxrwx1 adap users 3 May 30 12:09 bar -> bar > Notice that the symlink created is wrong. It seems that any symlink I > create is always linked to itself. I tried the same: moffe@grignard:/tmp/test# ls -la totalt 1 drwxr-xr-x2 moffeusers 48 ons maj 30 19:10:20 2001 . drwxrwxrwt 13 root root 496 ons maj 30 19:10:40 2001 .. moffe@grignard:/tmp/test# ln -s foo bar moffe@grignard:/tmp/test# ls -la totalt 1 drwxr-xr-x2 moffeusers 72 ons maj 30 19:10:58 2001 . drwxrwxrwt 13 root root 496 ons maj 30 19:10:40 2001 .. lrwxrwxrwx1 moffeusers 3 ons maj 30 19:10:58 2001 bar -> foo moffe@grignard:/tmp/test# cd /boot/test/ moffe@grignard:/boot/test# ls -la totalt 2 drwxr-xr-x2 moffeusers1024 ons maj 30 19:10:28 2001 . drwxr-xr-x4 root root 1024 ons maj 30 19:10:28 2001 .. moffe@grignard:/boot/test# ln -s foo bar moffe@grignard:/boot/test# ls -la totalt 2 drwxr-xr-x2 moffeusers1024 ons maj 30 19:11:09 2001 . drwxr-xr-x4 root root 1024 ons maj 30 19:10:28 2001 .. lrwxrwxrwx1 moffeusers 3 ons maj 30 19:11:09 2001 bar -> foo / is on reiserfs and /boot is on ext2 - as you see, I do not have the problem (also running 2.4.5). Could it be a fileutils problem? Rasmus -- -- [ Rasmus 'Møffe' Bøg Hansen ] -- Programming is a race between programmers, who try and make more and more idiot-proof software, and universe, which produces more and more remarkable idiots. Until now, universe leads the race. - R. Cooka [ moffe at amagerkollegiet dot dk ] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Zerocopy NBD
Hi, > > On Wed, 30 May 2001, Steve Whitehouse wrote: > > [info about NBD patch deleted] > > > Cool. > > Are you seeing performance improvements with the patch ? > Yes, but my testing is not in anyway complete yet. The only network device I have which is supported by zerocopy is loopback and there appear to be problems with deadlocks when using NBD over loopback. So what I did was to modify the NBD server (the userland one from Pavel Machek's web site) so that it didn't actually do any disk I/O. It still copied the data from the network into a buffer on write and it returns zeroed buffers on read (not that thats important as only the write patch is affected in the patch). I could then test using dd which is a bit artificial in that it creates large requests giving probably much more data per NBD request than would be usual under a filesystem load and hence also better with the zerocopy patch. A timed dd with 10 blocks of 1k spent 1.2 secs of system time to do the write with NBD in 2.4.5 and 0.8 secs with my patch. Also it may well be possible to adjust the network stack's memory management to give better performance. I upped the values in tcp_[r|w]mem but I've not checked what different vaules would do to those figures. I want to do some more testing though in case I've made an error somewhere in the method. I'd be particularly interested to hear from someone who has any results for real hardware. If I have time I'll look into whether the eepro100 or SysKonnect GigE cards could be made to support zerocopy as they are the ones I have here, Steve. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pte_page
[EMAIL PROTECTED] said: > On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: > > I use the 'pgt_offset', 'pmd_offset', 'pte_offset' and 'pte_page' > > inside a module to get the physical address of a user space virtual > > address. The physical address returned by 'pte_page' is not page > > aligned whereas the virtual address was page aligned. Can somebody > > tell me the reason? > > __pa(page_address(pte_page(pte))) is the address you want. [or > pte_val(*pte) & (PAGE_SIZE-1) on x86 but this is platform-dependent.] Does this work on x86 non-kmapped highmem user pages too? (i.e. is page->virtual valid for every potential user page.) -- Pete > > Also, can i use these functions to get the physical address of a > > kernel virtual address using init_mm? > > nope. Eg. on x86 these functions only walk normal 4K page pagetables, they > do not walk 4MB pages correctly. (which are set up on pentiums and better > CPUs, unless mem=nopentium is specified.) > > a kernel virtual address can be decoded by simply doing __pa(kaddr). If > the page is a highmem page [and you have the struct page pointer] then you > can do [(page-mem_map) << PAGE_SHIFT] to get the physical address, but > only on systems where mem_map[] starts at physical address 0. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: empeg-car serial-over-USB driver
On Tue, May 29, 2001 at 11:16:08PM +0100, Philip Blundell wrote: > Has anybody used this successfully in a recent kernel? With 2.4.5 it seems to > detect the device successfully: Are you _sure_ you are using usb-uhci and not uhci? :) Any oops message available from a serial console? > empeg.c: v1.0.0 Greg Kroah-Hartman <[EMAIL PROTECTED]>, Gary Brubaker ><[EMAIL PROTECTED]> Try emailing Gary, as he is current maintainer of the driver. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
