Re: Git archive now available
Darren Williams wrote: Hi All Thanks to the team at [EMAIL PROTECTED] we now have a no so complete Git archive at http://www.gelato.unsw.edu.au/archives/git/ If somebody could send me a complete Git mbox I will update the archive with it. - dsw gmane.org is already archiving this list. - 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: Git archive now available
Darren Williams wrote: Hi All Thanks to the team at [EMAIL PROTECTED] we now have a no so complete Git archive at http://www.gelato.unsw.edu.au/archives/git/ If somebody could send me a complete Git mbox I will update the archive with it. - dsw gmane.org is already archiving this list. - 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: Use of C99 int types
On Sun, 2005-04-03 at 21:23 +0200, Renate Meijer wrote: > On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote: > > > Stephen Rothwell wrote: > > > >> On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> > >> wrote: > >> > >>> I've been working on a new DES implementation for Linux, and ran into > >>> the problem of how to get access to C99 types like uint_fast32_t for > >>> internal (not interface) use. In my tests, key setup on Athlon 64 > >>> slows > >>> down by 40% when using u32 instead of uint_fast32_t. > >>> > >> > >> If you look in stdint.h you may find that uint_fast32_t is actually > >> 64 bits on Athlon 64 ... so does it help if you use u64? > >> > >> > > > > Yes, but wouldn't it be much better to avoid code like the following, > > which may also be wrong (in terms of speed)? > > > > #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? > > #define fast_u32 u64 > > #else > > #define fast_u32 u32 > > #endif > > Isn't it better to use a general integer type, reflecting the cpu's > native register-size and let the compiler sort it out? Restrict all > uses of explicit width types to where it's *really* needed, that is, in But is this not exactly what Dag Arne Osvik was trying to do ?? uint_fast32_t means that we want at least 32 bits but it's OK with more if that happens to be faster on this particular architecture. The problem was that the C99 standard types are not defined anywhere in the kernel headers so they can not be used. Perhaps they should be added to asm/types.h ? signature.asc Description: This is a digitally signed message part
Re: Use of C99 int types
On Sun, 2005-04-03 at 21:23 +0200, Renate Meijer wrote: On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote: Stephen Rothwell wrote: On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik [EMAIL PROTECTED] wrote: I've been working on a new DES implementation for Linux, and ran into the problem of how to get access to C99 types like uint_fast32_t for internal (not interface) use. In my tests, key setup on Athlon 64 slows down by 40% when using u32 instead of uint_fast32_t. If you look in stdint.h you may find that uint_fast32_t is actually 64 bits on Athlon 64 ... so does it help if you use u64? Yes, but wouldn't it be much better to avoid code like the following, which may also be wrong (in terms of speed)? #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? #define fast_u32 u64 #else #define fast_u32 u32 #endif Isn't it better to use a general integer type, reflecting the cpu's native register-size and let the compiler sort it out? Restrict all uses of explicit width types to where it's *really* needed, that is, in But is this not exactly what Dag Arne Osvik was trying to do ?? uint_fast32_t means that we want at least 32 bits but it's OK with more if that happens to be faster on this particular architecture. The problem was that the C99 standard types are not defined anywhere in the kernel headers so they can not be used. Perhaps they should be added to asm/types.h ? signature.asc Description: This is a digitally signed message part
Re: EXT2 Filesystem permissions (bug)?
Interesting but I wonder how much this helps someone that not already know what it is. Should not the ls manual also contain something that explains the meaning instead of just the mapping from bits to symbol. Do linux even support the sticky bit (t) I can't see a reason to use it, why would I want the file to be stored in the swap ?? Also I think S (setuid but no execute bit) have something to do with file locking but I'am not shure exactly how it works. "H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:Shawn Starr <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Is this a bug or something thats undocumented somewhere? > > > > dT > > and > > drwSrwSrwT > > > > are these special bits? I'm not aware of +S and +T > > > > It's neither a bug nor undocumented. > > "info ls" would have told you the following: > > The permissions listed are similar to symbolic mode > specifications > (*note Symbolic Modes::.). But `ls' combines multiple bits into > the third character of each set of permissions as follows: > `s' > If the setuid or setgid bit and the corresponding executable > bit are both set. > > `S' > If the setuid or setgid bit is set but the corresponding > executable bit is not set. > > `t' > If the sticky bit and the other-executable bit are both set. > > `T' > If the sticky bit is set but the other-executable bit is not > set. > > `x' > If the executable bit is set and none of the above apply. > > `-' > Otherwise. > > -hpa - 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: EXT2 Filesystem permissions (bug)?
Interesting but I wonder how much this helps someone that not already know what it is. Should not the ls manual also contain something that explains the meaning instead of just the mapping from bits to symbol. Do linux even support the sticky bit (t) I can't see a reason to use it, why would I want the file to be stored in the swap ?? Also I think S (setuid but no execute bit) have something to do with file locking but I'am not shure exactly how it works. H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Shawn Starr [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Is this a bug or something thats undocumented somewhere? dT and drwSrwSrwT are these special bits? I'm not aware of +S and +T It's neither a bug nor undocumented. info ls would have told you the following: The permissions listed are similar to symbolic mode specifications (*note Symbolic Modes::.). But `ls' combines multiple bits into the third character of each set of permissions as follows: `s' If the setuid or setgid bit and the corresponding executable bit are both set. `S' If the setuid or setgid bit is set but the corresponding executable bit is not set. `t' If the sticky bit and the other-executable bit are both set. `T' If the sticky bit is set but the other-executable bit is not set. `x' If the executable bit is set and none of the above apply. `-' Otherwise. -hpa - 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: LANANA: To Pending Device Number Registrants
Chip Salzenberg wrote: > According to Alan Cox: > > Given a file handle 'X' how do I find out what ioctl groups I should > > apply to it. > > Wouldn't it be better just to *try* ioctls and see which ones work and > which ones don't? As ioctl's is just numbers that can be valid but mean totally different thing depending on device I don't see how this is going to work. It took me close to a month to figure out why my new 1rpm scsi disk constantly ended up with a read only filesystem. What I did not know at that time was that the /dev/sg[x] numbering was changed by adding something to the scsi chain and my backup software now sent the eject command to the disk instead of to the tape. This ioctl means spinn down when it is sent to the disk and that in turn produces a fatal error and a remount to ro for the mounted filesystem. This problem had not existed for me if things had been mapped more static this i why I'am not overly happy hearing that things is going to be even more volatile. But I guess that it's possible to solve most of this issues in userspace. One way of looking on the problem is to take it to it's logical extrem. This would be a kernel with no persistent storage for devices no major,minor and no name policy. The kernel would simply put any device it finds in /dev/devno/[x] where x is just a number that should be seen as something that changed for every reboot. Any userspace solution that can create device links that are stable out of this is one that would get my vote. This obviously needs some type if standard why to query the devices or else it's no way it can work. - 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: LANANA: To Pending Device Number Registrants
Chip Salzenberg wrote: According to Alan Cox: Given a file handle 'X' how do I find out what ioctl groups I should apply to it. Wouldn't it be better just to *try* ioctls and see which ones work and which ones don't? As ioctl's is just numbers that can be valid but mean totally different thing depending on device I don't see how this is going to work. It took me close to a month to figure out why my new 1rpm scsi disk constantly ended up with a read only filesystem. What I did not know at that time was that the /dev/sg[x] numbering was changed by adding something to the scsi chain and my backup software now sent the eject command to the disk instead of to the tape. This ioctl means spinn down when it is sent to the disk and that in turn produces a fatal error and a remount to ro for the mounted filesystem. This problem had not existed for me if things had been mapped more static this i why I'am not overly happy hearing that things is going to be even more volatile. But I guess that it's possible to solve most of this issues in userspace. One way of looking on the problem is to take it to it's logical extrem. This would be a kernel with no persistent storage for devices no major,minor and no name policy. The kernel would simply put any device it finds in /dev/devno/[x] where x is just a number that should be seen as something that changed for every reboot. Any userspace solution that can create device links that are stable out of this is one that would get my vote. This obviously needs some type if standard why to query the devices or else it's no way it can work. - 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 and 2GB swap partition limit
Jonathan Lundell wrote: > > (Does Linux swap out text, by the way, he asks ignorantly?) .text is just droped and read back from the actuall file it's not put into the swap - 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 and 2GB swap partition limit
Jonathan Lundell wrote: (Does Linux swap out text, by the way, he asks ignorantly?) .text is just droped and read back from the actuall file it's not put into the swap - 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: IP Acounting Idea for 2.5
Alan Cox wrote: > > > Fix your userspace applications to behave correctly. If _you_ > > > require your userspace applications to not clear counters, then fix > > > the application. > > > > You are confused. What would you say if a close() by another, > > No he isnt confused, you are trying to dictate policy. Well it's not actually possible to do a fix in userspace for a odometer type of counter that can be reset. I don't know what you mean about policy but this reset "feature" is a shure way to get bad values. I have not seen one good reason to have a reset other than it easier to read and that is something that can be fixed in userspace. - 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: IP Acounting Idea for 2.5
Alan Cox wrote: Fix your userspace applications to behave correctly. If _you_ require your userspace applications to not clear counters, then fix the application. You are confused. What would you say if a close() by another, No he isnt confused, you are trying to dictate policy. Well it's not actually possible to do a fix in userspace for a odometer type of counter that can be reset. I don't know what you mean about policy but this reset "feature" is a shure way to get bad values. I have not seen one good reason to have a reset other than it easier to read and that is something that can be fixed in userspace. - 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 and 2GB swap partition limit
[EMAIL PROTECTED] wrote: > Linus has spoken, and 2.4.x now requires swap = 2x RAM. > But, the 2GB per swap partition limit still exists, best as we can tell. > So, we sell machines with say 8GB RAM. We need 16GB swap, but really we > need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a > 2GB swap partition on each. That's ugly. > > Is the 2GB per swap partition going to go away any time soon? > > Thanks, > Matt > I know Rik have some plans but I don't know the time table. On the other hand do you really need swap partitions how about using swap files? That way you don't need to manage alot of partitons and you can test if you really do need to go all the way to 2xRAM. It dose look a bit silly to have 16GB swap. Are you really going to load the machine with work that needs more than 8GB?? if not you don't really need any swap. I have not created any swap partitons in years and mostly run without any swap whatsoever. It's easy to create one temporary if I know I'am going to use more memory than I have. Obviously on a server it's better to be safe than sorry. - 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 and 2GB swap partition limit
[EMAIL PROTECTED] wrote: Linus has spoken, and 2.4.x now requires swap = 2x RAM. But, the 2GB per swap partition limit still exists, best as we can tell. So, we sell machines with say 8GB RAM. We need 16GB swap, but really we need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a 2GB swap partition on each. That's ugly. Is the 2GB per swap partition going to go away any time soon? Thanks, Matt I know Rik have some plans but I don't know the time table. On the other hand do you really need swap partitions how about using swap files? That way you don't need to manage alot of partitons and you can test if you really do need to go all the way to 2xRAM. It dose look a bit silly to have 16GB swap. Are you really going to load the machine with work that needs more than 8GB?? if not you don't really need any swap. I have not created any swap partitons in years and mostly run without any swap whatsoever. It's easy to create one temporary if I know I'am going to use more memory than I have. Obviously on a server it's better to be safe than sorry. - 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: three kernel trees?
"Jeff V. Merkey" wrote: > Alan, > > Were Linux to go totally modular in 2.5, development cycles will be > reduced by 1/2 to 1/3. This is because you could always roll back to > known good modules to post a release. The way you guys are going, if > Linux stays monolithic, your cycles will get longer and longer. > Modularity will allow multiple people to proceed in parallel without > every patch and bug going through you and Linus all the time (which > would mean you could enjoy more free time). > I don't really see what class of problems this would solve. It could be that we mean different things with modular. Do you mean distribute the driver source separately from the kernel source or do you mean going none monolitic by creating a stable binary interface?? I think the second one is going to be hard to get pass Linus and the first one is going to result in alot of drivers not uptodate with kernel changes. The problem with a binary interface is that if it was easy to do one we did not need one in the first place as that would suggest that the source code interface also was stable. > > This does not solve the problem of integration testing, but eh solution > here is to create an integration test group whose sole charter is to > test modules in an integrated framework as they roll off the assembly > line. I am speaking from my commercial software development experienes Good luck finding anyone doing this job. It's hard to make people write documentation this is going to be impossible. This is a solution that works if you can pay people but I don't think it's going to work when volunteers is doing it. > > here. Linux is falling into the same rut NetWare did as it became > successful -- too much work for mere mortals without some new structures > put in place. > > Just a thought. > Yes but is anyone taking notes on what work really is taking up all the time? Is it really drivers that is the problem? To me it lookes more like a problem with deciding what really is the goal of every new version that make all sort of late changes creap into the kernel that increase the time to a stable version. Making the TODO list before instead of at the end would probably make people concentrate on the same thing. Just another thought. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: three kernel trees?
"Jeff V. Merkey" wrote: Alan, Were Linux to go totally modular in 2.5, development cycles will be reduced by 1/2 to 1/3. This is because you could always roll back to known good modules to post a release. The way you guys are going, if Linux stays monolithic, your cycles will get longer and longer. Modularity will allow multiple people to proceed in parallel without every patch and bug going through you and Linus all the time (which would mean you could enjoy more free time). I don't really see what class of problems this would solve. It could be that we mean different things with modular. Do you mean distribute the driver source separately from the kernel source or do you mean going none monolitic by creating a stable binary interface?? I think the second one is going to be hard to get pass Linus and the first one is going to result in alot of drivers not uptodate with kernel changes. The problem with a binary interface is that if it was easy to do one we did not need one in the first place as that would suggest that the source code interface also was stable. This does not solve the problem of integration testing, but eh solution here is to create an integration test group whose sole charter is to test modules in an integrated framework as they roll off the assembly line. I am speaking from my commercial software development experienes Good luck finding anyone doing this job. It's hard to make people write documentation this is going to be impossible. This is a solution that works if you can pay people but I don't think it's going to work when volunteers is doing it. here. Linux is falling into the same rut NetWare did as it became successful -- too much work for mere mortals without some new structures put in place. Just a thought. Yes but is anyone taking notes on what work really is taking up all the time? Is it really drivers that is the problem? To me it lookes more like a problem with deciding what really is the goal of every new version that make all sort of late changes creap into the kernel that increase the time to a stable version. Making the TODO list before instead of at the end would probably make people concentrate on the same thing. Just another thought. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre1 hang when loading scsi-ide cdrom
Frank van de Pol wrote: > Just experienced a (reproducable) hang of the system when loading the > drivers for my cdrom drives. (ide-cd and ide-scsi). System freezes > completely; interupts / alt-sysreq is still working. > ... > > It appears to me that something breaks during the init/registration of these > devices. Any hint/tips to pinpoint the problem? > If it worked for you in test8 the only thing that changed is that in sr.c the init_sr() function been maked with __init and the exit_sr() with __exit. You could test removing them (__init and __exit that is not the function) it should not matter but it's all I could find :( By the way it works for me and I compile sr as a module mybe you don't ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test8-pre6 file corruption and oops
"Juan J. Quintela" wrote: > >>>>> "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes: > > kenneth> Is there some way I can fix the old report I don't have a unprocessed >version of the oops as klogd "fixed" it automatically. > > I don't think so. It is a good idea to run klogd with the -x option, > to prevent him from doind the translation. I checked into this some more and debian have a patched version that actually gets it right and it did not take the symbols from the System.map link. It was easy to check as that mapfile don't even have the "__mon_yday" symbol so it must have got the symbols from another file and unless it's seriously broken it should have picked the right one. So it lookes like the call trace was wrong and not the map file. I have now put "-k /boot/System.map-$(uname -r)" as argument to klogd so it can't possibly choose the wrong file but is there some reason to turn off the lookup in klogd and use ksymoops ?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test8-pre6 file corruption and oops
"Juan J. Quintela" wrote: > >>>>> "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes: > > hi > > I only can guess that you are using a wrong System.map for > doing the ksymoops. __mon_yday is an array, not a function, > the backtrace don't make sense. > > Later, Juan "waiting for a nice backtrace" :))) You are right for some reason my last 5 upgrades have copied the correct System.map(with version numer in the name) into /boot but not updated the link. I have to investigate why this happens. I guess most tools use the right version anyway otherwise I would have seen this error before. Is there some way I can fix the old report I don't have a unprocessed version of the oops as klogd "fixed" it automatically. Sorry for the bogus report. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test8-pre6 file corruption and oops
"Juan J. Quintela" wrote: "kenneth" == Kenneth Johansson [EMAIL PROTECTED] writes: hi I only can guess that you are using a wrong System.map for doing the ksymoops. __mon_yday is an array, not a function, the backtrace don't make sense. Later, Juan "waiting for a nice backtrace" :))) You are right for some reason my last 5 upgrades have copied the correct System.map(with version numer in the name) into /boot but not updated the link. I have to investigate why this happens. I guess most tools use the right version anyway otherwise I would have seen this error before. Is there some way I can fix the old report I don't have a unprocessed version of the oops as klogd "fixed" it automatically. Sorry for the bogus report. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test8-pre6 file corruption and oops
I get this on only one of my machines but it's probably not that stange as they really don't have much in common other than being i386 compatible. Could old errors on the filesystem produce this error?? I have only run fsck under t8p6. The last one is incomplete but the kernel had inserted part of another file in the log so that was all I could get out. I have not noticed when this happens, If I find a pattern I post it later but It only functions as a nfs server and NAT box(ppp/netfiler/squid/...) so I don't think I could find much. Sep 7 17:39:50 ken1 kernel: invalid operand: Sep 7 17:39:50 ken1 kernel: CPU:0 Sep 7 17:39:50 ken1 kernel: EIP:0010:[__make_request+161/1444] Sep 7 17:39:50 ken1 kernel: EFLAGS: 00010286 Sep 7 17:39:50 ken1 kernel: eax: 001f ebx: c22ab380 ecx: edx: Sep 7 17:39:50 ken1 kernel: esi: c22ab380 edi: c0268380 ebp: 0001 esp: c1171f34 Sep 7 17:39:50 ken1 kernel: ds: 0018 es: 0018 ss: 0018 Sep 7 17:39:50 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000) Sep 7 17:39:50 ken1 kernel: Stack: c01e19da c01e1cc2 02c7 c22ab380 0001 000c 0001 Sep 7 17:39:50 ken1 kernel:c0268398 c0268390 0002 c015f592 00fe Sep 7 17:39:50 ken1 kernel:c0160151 c0268380 0001 c22ab380 c22ab380 0001 c1171fd0 Sep 7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] [__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] [ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] Sep 7 17:39:50 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 ca 25 c0 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: 0f b6 46 15 movzbl 0x15(%esi),%eax Code; 0009 Before first symbol 9: 0f b7 4e 14 movzwl 0x14(%esi),%ecx Code; 000d Before first symbol d: 8b 14 85 00 ca 25 c0 mov0xc025ca00(,%eax,4),%edx Sep 7 22:19:47 ken1 kernel: invalid operand: Sep 7 22:19:47 ken1 kernel: CPU:0 Sep 7 22:19:47 ken1 kernel: EIP:0010:[__make_request+161/1444] Sep 7 22:19:47 ken1 kernel: EFLAGS: 00010286 Sep 7 22:19:47 ken1 kernel: eax: 001f ebx: c1b15b00 ecx: edx: Sep 7 22:19:47 ken1 kernel: esi: c1b15b00 edi: c0268380 ebp: 0001 esp: c1171f34 Sep 7 22:19:47 ken1 kernel: ds: 0018 es: 0018 ss: 0018 Sep 7 22:19:47 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000) Sep 7 22:19:47 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c1b15b00 0001 000c 001e8480 Sep 7 22:19:47 ken1 kernel:c0268398 c0268390 0002 c015f592 00fe Sep 7 22:19:47 ken1 kernel:c0160151 c0268380 0001 c1b15b00 c1b15b00 0001 c1171fd0 Sep 7 22:19:47 ken1 kernel: Call Trace: [__mon_yday+6234/22368] [__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] [ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] Sep 7 22:19:47 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 ca 25 c0 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: 0f b6 46 15 movzbl 0x15(%esi),%eax Code; 0009 Before first symbol 9: 0f b7 4e 14 movzwl 0x14(%esi),%ecx Code; 000d Before first symbol d: 8b 14 85 00 ca 25 c0 mov0xc025ca00(,%eax,4),%edx Sep 7 22:26:06 ken1 kernel: invalid operand: Sep 7 22:26:06 ken1 kernel: CPU:0 Sep 7 22:26:06 ken1 kernel: EIP:0010:[__make_request+161/1444] Sep 7 22:26:06 ken1 kernel: EFLAGS: 00010282 Sep 7 22:26:06 ken1 kernel: eax: 001f ebx: c21f49c0 ecx: edx: Sep 7 22:26:06 ken1 kernel: esi: c21f49c0 edi: c0268380 ebp: 0001 esp: c1173f3c Sep 7 22:26:06 ken1 kernel: ds: 0018 es: 0018 ss: 0018 Sep 7 22:26:06 ken1 kernel: Process kflushd (pid: 3, stackpage=c1173000) Sep 7 22:26:06 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c21f49c0 0001 [EMAIL PROTECTED]> Status: RO 1 warning issued. Results may not be reliable.
test8-pre6 file corruption and oops
I get this on only one of my machines but it's probably not that stange as they really don't have much in common other than being i386 compatible. Could old errors on the filesystem produce this error?? I have only run fsck under t8p6. The last one is incomplete but the kernel had inserted part of another file in the log so that was all I could get out. I have not noticed when this happens, If I find a pattern I post it later but It only functions as a nfs server and NAT box(ppp/netfiler/squid/...) so I don't think I could find much. Sep 7 17:39:50 ken1 kernel: invalid operand: Sep 7 17:39:50 ken1 kernel: CPU:0 Sep 7 17:39:50 ken1 kernel: EIP:0010:[__make_request+161/1444] Sep 7 17:39:50 ken1 kernel: EFLAGS: 00010286 Sep 7 17:39:50 ken1 kernel: eax: 001f ebx: c22ab380 ecx: edx: Sep 7 17:39:50 ken1 kernel: esi: c22ab380 edi: c0268380 ebp: 0001 esp: c1171f34 Sep 7 17:39:50 ken1 kernel: ds: 0018 es: 0018 ss: 0018 Sep 7 17:39:50 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000) Sep 7 17:39:50 ken1 kernel: Stack: c01e19da c01e1cc2 02c7 c22ab380 0001 000c 0001 Sep 7 17:39:50 ken1 kernel:c0268398 c0268390 0002 c015f592 00fe Sep 7 17:39:50 ken1 kernel:c0160151 c0268380 0001 c22ab380 c22ab380 0001 c1171fd0 Sep 7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] [__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] [ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] Sep 7 17:39:50 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 ca 25 c0 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: 0f b6 46 15 movzbl 0x15(%esi),%eax Code; 0009 Before first symbol 9: 0f b7 4e 14 movzwl 0x14(%esi),%ecx Code; 000d Before first symbol d: 8b 14 85 00 ca 25 c0 mov0xc025ca00(,%eax,4),%edx Sep 7 22:19:47 ken1 kernel: invalid operand: Sep 7 22:19:47 ken1 kernel: CPU:0 Sep 7 22:19:47 ken1 kernel: EIP:0010:[__make_request+161/1444] Sep 7 22:19:47 ken1 kernel: EFLAGS: 00010286 Sep 7 22:19:47 ken1 kernel: eax: 001f ebx: c1b15b00 ecx: edx: Sep 7 22:19:47 ken1 kernel: esi: c1b15b00 edi: c0268380 ebp: 0001 esp: c1171f34 Sep 7 22:19:47 ken1 kernel: ds: 0018 es: 0018 ss: 0018 Sep 7 22:19:47 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000) Sep 7 22:19:47 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c1b15b00 0001 000c 001e8480 Sep 7 22:19:47 ken1 kernel:c0268398 c0268390 0002 c015f592 00fe Sep 7 22:19:47 ken1 kernel:c0160151 c0268380 0001 c1b15b00 c1b15b00 0001 c1171fd0 Sep 7 22:19:47 ken1 kernel: Call Trace: [__mon_yday+6234/22368] [__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] [ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] Sep 7 22:19:47 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 ca 25 c0 Code; Before first symbol _EIP: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: 0f b6 46 15 movzbl 0x15(%esi),%eax Code; 0009 Before first symbol 9: 0f b7 4e 14 movzwl 0x14(%esi),%ecx Code; 000d Before first symbol d: 8b 14 85 00 ca 25 c0 mov0xc025ca00(,%eax,4),%edx Sep 7 22:26:06 ken1 kernel: invalid operand: Sep 7 22:26:06 ken1 kernel: CPU:0 Sep 7 22:26:06 ken1 kernel: EIP:0010:[__make_request+161/1444] Sep 7 22:26:06 ken1 kernel: EFLAGS: 00010282 Sep 7 22:26:06 ken1 kernel: eax: 001f ebx: c21f49c0 ecx: edx: Sep 7 22:26:06 ken1 kernel: esi: c21f49c0 edi: c0268380 ebp: 0001 esp: c1173f3c Sep 7 22:26:06 ken1 kernel: ds: 0018 es: 0018 ss: 0018 Sep 7 22:26:06 ken1 kernel: Process kflushd (pid: 3, stackpage=c1173000) Sep 7 22:26:06 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c21f49c0 0001 [EMAIL PROTECTED] Status: RO 1 warning issued. Results may not be reliable.
