Re: [PATCH] APMD on Linux 2.2.18 and include/linux/mc146818rtc.h
Marc Esipovich wrote: > > I've noticed this when attempting to build APMD, mc146818rtc.h has > a reference to a spinlock_t while asm/spinlock.h is not included. > > Patch follows: User space does not need to ever see any kernel spinlocks - you will find such a fix for this is in 2.2.19pre already though, so you can make use of that. Thanks for the report anyway, Paul. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - 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/
No Subject
- 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/
"i810_audio: DMA overrun on send" countless times in logs
This message pops up in my logs countless times, often accompanied by temporarily freezes of the system, and pops in the sound. It seems to occur more often when under load, i.e. playing a DVD. In fact, they degrade the performance so badly as to make DVDs unwatchable. I would chock this up to crappy hardware, accept that these errors don't occur with the ALSA drivers, even under the same situations. Not just the absense of the messages, but the absense of the symptoms. Thanks -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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: [OT] Re: Money stifles innovation
On Sun, 18 Feb 2001, Gregory Maxwell wrote: > On Sun, Feb 18, 2001 at 05:47:10PM -0800, Dan Hollis wrote: > > Actually the problem is lack of morals and bad people who are really evil > > at the core (you wouldnt want them for your neighbor). > Actually, it's because we've made it illegal to corporations to behave > ethically when it conflicts with short-term shareholder profits. > http://www.ratical.com/corporations/ > It would be nice if it were so simple as to declare the involved parties as > evil. I know both good and bad people at corporations. The bad people were mean and nasty before they joined the corporation, the corporation became a vehicle for them to abuse others and directly translated to the misbehaviour of that corporation. Doing bad things comes naturally to them. The good people went out of their way to prevent the corporation from doing evil things, or left the corporation so they would not be party to the unethical behaviour. -Dan - 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/
ip_conntrack error under 2.4.1-ac18
I'm getting multiple messages like: Feb 18 23:05:50 rhino kernel: ip_conntrack: maximum limit of 8184 entries exceeded Feb 18 23:05:52 rhino last message repeated 2 times while running nessus, with 100 simultaneous connections set, against a company machine. This is the first time I've observed this error. Billy - 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 executation from ROM
Dear Sirs, Thanks for your help, I see . The biggest negative point of running kernel from ROM is that ROM speed is slow :( Any how , thanks for your help, Best Regards, Jaswinder. -- These are my opinions not 3Di. - Original Message - From: "Peter Waltenberg" <[EMAIL PROTECTED]> To: "Jaswinder Singh" <[EMAIL PROTECTED]> Sent: Sunday, February 18, 2001 6:49 PM Subject: RE: Kernel executation from ROM > > You can laod the kernel from ROM, but it'll need RAM to execute. If you get to > be very good with the linker and loader, you can probably make a large part of > the kernel ROM resident, but it will still need significant amounts of RAM to > be usable. > It's probably easier not to bother and do what everyone else does and copy from > ROM->RAM at startup. > > Peter > > On 19-Feb-2001 Jaswinder Singh wrote: > > Dear Kernel mailing list , > > > > what changes i have to made in kernel so that i can > > run kernel from ROM, means i keep my kernel in ROM > > and i execute my kernel from ROM . > > > > Thanks , > > > > Happy Hacking, > > > > Jaswinder. > > -- > > These are my opinions not 3Di. > - - Original Message - From: "Albert D. Cahalan" <[EMAIL PROTECTED]> To: "Jaswinder Singh" <[EMAIL PROTECTED]> Sent: Sunday, February 18, 2001 6:57 PM Subject: Re: Kernel executation from ROM > > what changes i have to made in kernel so that i can > > run kernel from ROM, means i keep my kernel in ROM > > and i execute my kernel from ROM . > > 1. write boot code to copy initialized variables into RAM > 2. adjust the linker script to know about the above > 3. adjust the linker script for other sections too > > For better performance, assuming ROM is slow and costly: > > 1. compress the "__init" code and data; use it in RAM > 2. profile your kernel; put the critical parts in RAM > > If you want the details, take Red Hat's embedded systems > development class. If you have a dozen people, get the class > done at your location and have it modified to fit your needs. > I just took the class; it was pretty good. It is "RHD248". > - 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 timers and jiffie wrap-around
Jamie wrote: > > Hi ! > > I've been trying to determine the reliability of kernel timers when a box has been >up for a while. Now as everyone is aware (for HZ=100 (default)), when the uptime of >the kernel reaches (approx.) 1.3 years the clock tick count (jiffies) wraps-around. >Now if a kernel timer is added just before the wrap-around then from the source I get >the impression the kernel timer will be run immediately instead of after the >specified delay. Here's my reasoning: > > When adding a timer the internal_add_timer() function is (eventually) called. Given >that the current jiffies is close to maximum for an unsigned long value then the >following index value is computed: > > // jiffies = ULONG_MAX - 10, say. > // so timer_jiffies is close to jiffies. > // timer.expires = jiffies + TIMEOUT_VALUE, where TIMEOUT_VALUE=200, say. > > index = expires - timer_jiffies; > > Thus index is a large negative number resulting in the timer being added to >tv1.vec[tv1.index] which means that the timer is run on the next execution of >run_timer_list(). Now just how did you arrive at this? What value _is_ ULONG_MAX+190? It rolls over to 190. But you should think of timer_jiffies as 0-10 (in your case) so index=190+10 or the desired 200. No need to tweak the kernel, just try some simple C code. It all works until the requested time out is greater than ULONG_MAX/2 (about .68 years). George snip~ > > Surely I've misunderstood something in the timer code ? Now you have a good interview question for that next potential new hire :) snip~ - 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: problems with reiserfs + nfs using 2.4.2-pre4
On Sunday February 18, [EMAIL PROTECTED] wrote: > > OK, I grabbed these patches and applied them against 2.4.2-pre4 and > recompiled, rebooted. I am now able to use reiserfs with NFS, > basic operations appear to work as expected but I haven't done large amounts > of file IO or lots of concurrent requests. > > What is the plan with regards to these patches, or ones like it, making it into > the distribution? The changes to knfsd are fairly big and mean that every filesystem type that is to be exported needs to explicitly provide support for knfsd. I have almost completed doing this for ext2fs reiserfs isofs ufs efs which were the only ones that were mentioned when I asked "what filesystem types do you want to export" on the nfs list. The isofs stuff needs more work to be *right*, but it should be at least as good as the current code provides. (i.e. it works as long as things don't get flushed out of the dentry cache). The reiserfs bit needs work to get generation number checking done. This is being worked on by Danilov Nikita. I hope to put out a patch set for testing in a day or so and possibly suggest it to Alan for his -ac series. I don't see it going into 2.4.2, but 2.4.3 might be possible if Linus agrees. NeilBrown - 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/
[OT] Re: Money stifles innovation
On Sun, Feb 18, 2001 at 05:47:10PM -0800, Dan Hollis wrote: > On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > > On Sun, Feb 18, 2001 at 12:57:14AM -0800, Dan Hollis wrote: > > > The XOR patent and the fraudulent enforcement of it is the purest > > > embodiment of everything that is wrong with the patent system and IP law. > > As a person with a some decades of experience with patents and > > trademarks, and playing among the various sides, I can state > > quite unequivocally that the problem is money. > > Actually the problem is lack of morals and bad people who are really evil > at the core (you wouldnt want them for your neighbor). Actually, it's because we've made it illegal to corporations to behave ethically when it conflicts with short-term shareholder profits. http://www.ratical.com/corporations/ It would be nice if it were so simple as to declare the involved parties as evil. - 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: problems with reiserfs + nfs using 2.4.2-pre4
Neil Brown writes: >On Sunday February 18, [EMAIL PROTECTED] wrote: >> >> Hi, >> >> I migrated some exported disks over to reiserfs and had no luck when I >> mounted the disk via NFS on another machine. I've noticed many messages >> about reiser and NFS in the archives, but my understanding was that >> it had been cleared up. In particular, the Configure.help in 2.4.2-pre4 >> says "reiserfs can be used for anything that ext2 can be used for". > > >If you go to > > http://www.cse.unsw.edu.au/~neilb/patches/linux/2.4.2-pre3/ > >and pick up patch-B-nfsdops and patch-C-reisernfs >you should get reasonable nfs service for reiserfs. >Note that this is not final code though. The format of the filehandle >will probably change shortly as it doesn't currently contain a >generation number. >A similar patch is available somewhere under www.namesys.com I >believe. OK, I grabbed these patches and applied them against 2.4.2-pre4 and recompiled, rebooted. I am now able to use reiserfs with NFS, basic operations appear to work as expected but I haven't done large amounts of file IO or lots of concurrent requests. What is the plan with regards to these patches, or ones like it, making it into the distribution? I noticedAlan Cox just posted the following: >The configure.help is wrong on that and one other thing. NFS doesnt work >without extra patches and big endian boxes dont work with reiserfs currently >Chris - would it be worth sending me a patch that notes the NFS thing in >Configure.help and includes the patch url ? which suggests that the Configure.help mis-statement is going to be corrected but doesn't imply the fix is going in any time soon. I think NFS over Reiser is going to be interesting to people who are running big fileservers, so if this patch really does fix it (without breaking anything else) then itwould make sense for it to go in. Dave - 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: /proc/stat missing disk_io info
Not to be pushy or anything but since I received zero responses to this I was wondering what else I can do. I'd be happy to patch the problem myself but I have no idea what the correct value for DK_MAX_MAJOR should be. Anywho, if anyone has any thoughts I'd appreciate them. --Rainer > -Original Message- > I was wondering why some of my disks don't show up in > /proc/stat's disk_io > line. Specifically, my line says: > > disk_io: (2,0):(144,144,288,0,0) (3,0):(35,35,140,0,0) > > This equates to my floppy and first cdrom. I also have a second cdrom (RW) > and 2 hard disks. Looking at the code (kstat_read_proc in > fs/proc/proc_misc.c) it is looping only up to DK_MAX_MAJOR which > is defined > as 16 in kernel_stat.h. The problem is that my 2 HDs have a major > number of > 22. > > I don't know enough to produce a patch, that is, what should > DK_MAX_MAJOR be > set to, but I believe the above 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/
Kernel executation from ROM
Dear Kernel mailing list , what changes i have to made in kernel so that i can run kernel from ROM, means i keep my kernel in ROM and i execute my kernel from ROM . Thanks , Happy Hacking, Jaswinder. -- These are my opinions not 3Di. - 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/
anyone can tell me 2.4.2 is stable or not?
is it stable for use? - 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: Money stifles innovation [was: Linux stifles innovation.]
On Sunday February 18, [EMAIL PROTECTED] wrote: > > > On Sun, Feb 18, 2001 at 12:57:14AM -0800, Dan Hollis wrote: > > > > The XOR patent and the fraudulent enforcement of it is the purest > > > > embodiment of everything that is wrong with the patent system and IP law. > > > On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > > > As a person with a some decades of experience with patents and > > > trademarks, and playing among the various sides, I can state > > > quite unequivocally that the problem is money. > > On Sun, Feb 18, 2001 at 05:47:10PM -0800, Dan Hollis wrote: > > Actually the problem is lack of morals and bad people who are really evil > > at the core (you wouldnt want them for your neighbor). > > Many have heard the saying 'money is the root of all evil'. > > The quote is in fact 'the pursuit of money is the root of all evil'. > > Thanks go to Dan Hollis for reminding me of this. A better translation is: the love of money is a root of all kinds of evil. which is from the New International Version. Certainly it is easy to point to individual instances of evil that are not money related. Follow the URL: http://bible.gospelcom.net/cgi-bin/bible?passage=1+tim+6%3A10&NIV_version=yes&NASB_version=yes&KJV_version=yes&NKJV_version=yes&NIV-IBS_version=yes&RSV_version=yes&DARBY_version=yes&YLT_version=yes&WE_version=yes&showfn=yes&language=english for a comparison of translations. And seeing that we are way off topic already I would have said that the "core" is probably the one place where these people aren't evil. They just have lots of layers of evil hiding that core. NeilBrown > > -- > Brian Litzinger <[EMAIL PROTECTED]> > > Copyright (c) 2000 By Brian Litzinger, All Rights Reserved > - > 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: Money stifles innovation [was: Linux stifles innovation.]
> > On Sun, Feb 18, 2001 at 12:57:14AM -0800, Dan Hollis wrote: > > > The XOR patent and the fraudulent enforcement of it is the purest > > > embodiment of everything that is wrong with the patent system and IP law. > On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > > As a person with a some decades of experience with patents and > > trademarks, and playing among the various sides, I can state > > quite unequivocally that the problem is money. On Sun, Feb 18, 2001 at 05:47:10PM -0800, Dan Hollis wrote: > Actually the problem is lack of morals and bad people who are really evil > at the core (you wouldnt want them for your neighbor). Many have heard the saying 'money is the root of all evil'. The quote is in fact 'the pursuit of money is the root of all evil'. Thanks go to Dan Hollis for reminding me of this. -- Brian Litzinger <[EMAIL PROTECTED]> Copyright (c) 2000 By Brian Litzinger, All Rights Reserved - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
> > But it has to go somewhere, and 2.4 right now is unusable on two of my boxes > > with M/O drives. > > Reads can be pretty easily padded, but writes are a bit harder. Maybe > push it to some helper before the device queue sees it? For 2.4 the > best sd solution is probably to just make it able to handle these > requests. For M/O drives you can do it in the scsi layer. Doing it right in the block layer is not easy. Doing it cleanly and right I cant currently visualise a setu for. But I agree it belongs in the queueing layers - 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: problems with reiserfs + nfs using 2.4.2-pre4
> it had been cleared up. In particular, the Configure.help in 2.4.2-pre4 > says "reiserfs can be used for anything that ext2 can be used for". The configure.help is wrong on that and one other thing. NFS doesnt work without extra patches and big endian boxes dont work with reiserfs currently Chris - would it be worth sending me a patch that notes the NFS thing in Configure.help and includes the patch url ? - 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: Proliant hangs with 2.4 but works with 2.2.
> The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately > after they exit (with exit status 0). I cannot pinpoint why the kernel hangs > and would appreciate any help. The only thing I suspect it may be is that it The three of them all touch the mouse. Does dd if=/dev/psaux of=/dev/null count=256 also hang the box ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Mon, Feb 19 2001, Alan Cox wrote: > > So put 0 and sure anyone can submit I/O on the size that they want. > > Now the driver has to support padding reads, or gathering data to do > > a complete block write. This is silly. Sr should support 512b transfers > > just fine, but only because I added the necessary _hacks_ to support > > it. sd doesn't right now for instance. > > It is silly to be in the block layer, it is silly to be in each file system. > Perhaps it belongs in the block queueing/handling code or the caches > > But it has to go somewhere, and 2.4 right now is unusable on two of my boxes > with M/O drives. Reads can be pretty easily padded, but writes are a bit harder. Maybe push it to some helper before the device queue sees it? For 2.4 the best sd solution is probably to just make it able to handle these requests. -- 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: Money stifles innovation [was: Linux stifles innovation.]
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > On Sun, Feb 18, 2001 at 12:57:14AM -0800, Dan Hollis wrote: > > The XOR patent and the fraudulent enforcement of it is the purest > > embodiment of everything that is wrong with the patent system and IP law. > As a person with a some decades of experience with patents and > trademarks, and playing among the various sides, I can state > quite unequivocally that the problem is money. Actually the problem is lack of morals and bad people who are really evil at the core (you wouldnt want them for your neighbor). -Dan - 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 OS boilerplate
> I've been poring over the x86 boot code for a while now and I've been > considering writing a FAQ on the boot process (mostly for my own use, > but maybe others will be interested). This would include all relevant > information on setting up the x86 hardware for a boot (timers, PIC, A20, > protected mode, GDT, initial page tables, initial TSS, etc). It would certainly be a valuable piece for the kernel Documentation dir. Paticularly as people with embedded x86 grow keener and keener to boot biosless to save money and flash. - 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: MTU and 2.4.x kernel
> Fragmentation does _not_ work on poor internet more. At all. We are implementing an IP stack. Fragmentation works very well thank you, pointing at a few broken sites as an excuse to not do things right isnt very good. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote: > > Strange. The twelve or so CD readers I have here are all > > able to read 512-byte sectors. I am quite willing to believe > > I think most Plextor and Yamaha do, but it's not guaranteed to > be supported. And it definitely won't for ATAPI with ide-scsi. > > Strange. I just used ATAPI with ide-scsi as test. It works. Yeah it works because sr does read padding on drives that can't dish out 512b sectors... This is my point. > Setting hardsect_size to 2048 means: this hardware is unable > to use smaller blocks, give an error to whoever asks for > something smaller. Which is the case for some drives. The error now occurs when ext2 forcibly tries to set the block size. > Not setting hardsect_size at all means: I have no idea what this > hardware can do. Now it is up to the user. If the user tries > something the hardware cannot do, she will get EIO. > Limiting the user in advance is a bad idea. Ok agreed, just forcing 2048 is a bit harsh but it was nicer than letting sr bomb on 512b requests at the time. -- 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/
sendfile() breakage was Re: SO_SNDTIMEO: 2.4 kernel bugs
On Mon, 19 Feb 2001, Chris Evans wrote: > > BTW, if you have enough fast network, you probably can observe > > that sendfile() is even not interrupted by signals. 8) But this > > is possible to fix at least. BTW the same fix will repair SO_*TIMEO > > partially, i.e. it will timeout after n*timeo, where n is an arbitrary > > number not exceeding size/sndbuf. > > Hi Alexey, > > You are right - our sendfile() implementation is broken. I have fixed it > (patch at end of mail). Actually the whole mess stems from our broken internal ->write() and ->read() APIs. The _single_ return value is trying to convery _two_ pieces of information - always a bad move. They are: 1) Success/failure (and error code if it's a failure) 2) Amount of bytes read or written This bogon does not allow for the following information to be returned (assume I asked for 8192 bytes to be written): "4096 bytes were written, and the operation was aborted due to EINTR" Cheers 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: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
> So put 0 and sure anyone can submit I/O on the size that they want. > Now the driver has to support padding reads, or gathering data to do > a complete block write. This is silly. Sr should support 512b transfers > just fine, but only because I added the necessary _hacks_ to support > it. sd doesn't right now for instance. It is silly to be in the block layer, it is silly to be in each file system. Perhaps it belongs in the block queueing/handling code or the caches But it has to go somewhere, and 2.4 right now is unusable on two of my boxes with M/O drives. - 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 stifles innovation...
On Sun, 18 Feb 2001, Michael H. Warfield wrote: > On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote: > > > I remember being at a computer show in Minneapolis where a small company > > was showing off this mouse that worked on a variety of surfaces without a > > ball. I'm trying to remember if the mouse was optical or used yet another > > method of functioning -- I think it was optical, though I could be > > mistaken. This was in 1992/1993. > > I think you are correct here. I seem to recall mention of some > of those earlier devices at the time of the Microsoft announcement. I > seem to also recall some of the reliability problem they had. I believe > they were extremely fussy about the surface they were on. In the demo I saw, they had about 6 sample surfaces ranging from a mirror to blue jeans. I also got to play with the mouse on the demo system and it worked very well. At the time, mice were about $25 to $35 dollars, and theirs were like $79 or $99. I remember thinking it was a cool toy, but the price difference was going to keep it from mass market potential. - 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] smbfs does not support LFS (2.4.1-ac18)
> Is it ok to at mount time set it to non-LFS and then later change it to be > something larger? smbfs doesn't actually know what the server and smbmount > negotiates until later, but no smbfs operation can take place before that > anyway. You can change it per superblock later at the moment. Its probably best to set it as soon as possible. NFS sets it at mount time conditional on NFSv2 versus v3 for example Alan - 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: SO_SNDTIMEO: 2.4 kernel bugs
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote:
> Hello!
>
> > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():
>
> None of the options apply to sendfile(). It is not socket level
> operation. You have to use alarm for it.
>
> BTW, if you have enough fast network, you probably can observe
> that sendfile() is even not interrupted by signals. 8) But this
> is possible to fix at least. BTW the same fix will repair SO_*TIMEO
> partially, i.e. it will timeout after n*timeo, where n is an arbitrary
> number not exceeding size/sndbuf.
Hi Alexey,
You are right - our sendfile() implementation is broken. I have fixed it
(patch at end of mail).
However, I believe something is still wrong in the networking layer, even
with my fix applied.
Before I go into details, I want to step back and describe things from a
_users_ perspective. That is most important after all.
Take two different operations: write() to a socket and sendfile() down a
socket. In both cases, the socket has a send timeout of 10 seconds. From a
users' point of view, these are two socket write operations. The source of
data is different (a buffer or a file descriptor), but that is irrelevant.
The user has the right to expect a timeout after 10 seconds of no
progress, on both operations.
I have tried this on FreeBSD, and this is what happens: both sendfile()
and write() timeout in the same way.
On Linux, this is not the case => bug. I fixed a small sendfile() issue,
which did not recognise partial writes as an interruption, but as I said
above, the bug still remains.
Investigation shows that the Linux network layer is behaving oddly. It
seems that we are writing 4096 bytes to a socket. This proceeds in 4096
byte chunks until the send buffer on the socket is full, and a 4096 byte
write blocks. This blocking write is eventually interrupted by the
timeout, and the write call returns.. wait for it.. 4096! This suggests
there was socket space after all, and the call should not have blocked.
I wonder what is going on? I'd like to get this fixed. I think the FreeBSD
behaviour is definitely correct and we want it on Linux.
Cheers
Chris
--- filemap.c.old Sun Feb 18 23:35:06 2001
+++ filemap.c Mon Feb 19 00:13:38 2001
@@ -1062,7 +1062,7 @@
for (;;) {
struct page *page, **hash;
- unsigned long end_index, nr;
+ unsigned long end_index, nr, actor_ret;
end_index = inode->i_size >> PAGE_CACHE_SHIFT;
if (index > end_index)
@@ -1110,13 +1110,13 @@
* "pos" here (the actor routine has to update the user
buffer
* pointers and the remaining count).
*/
- nr = actor(desc, page, offset, nr);
- offset += nr;
+ actor_ret = actor(desc, page, offset, nr);
+ offset += actor_ret;
index += offset >> PAGE_CACHE_SHIFT;
offset &= ~PAGE_CACHE_MASK;
page_cache_release(page);
- if (nr && desc->count)
+ if (actor_ret == nr && desc->count)
continue;
break;
-
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: Proliant hangs with 2.4 but works with 2.2.
On Sun, 18 Feb 2001 23:09:17, "lafanga lafanga" <[EMAIL PROTECTED]> wrote: > I have a Compaq Proliant 1600 server which can be hung on demand with all > the 2.4 series kernels I have tried (2.4, 2.4.1 & 2.4.2-pre3). Kernel 2.2.16 > runs perfectly (from a default RH7.0). > > I have ensured that the server meets the necessary requirements for the 2.4 > kernels (modutils etc) and I have tried kgcc and various gcc versions. When > compiling I have tried default configs and also minimalist configs (with > only cpqarray and tlan). I have also ensured that I have the latest current > SmartStart CD (4.9) and have setup the firmware for installing Linux. If you cat /proc/ioports does cpqarray show any registered ioports? I think it has a bug that means it doesn't request_region() for the ioports it uses and this means that any other driver that tries to auto-detect hardware by probing ports can stomp on its toes. This is certainly the case for EISA cpqarray controllers which is where I found this. I sent a report into [EMAIL PROTECTED] or whatever the address listed in the maintainers file is but haven't heard anything. This bug _may_ only exist for EISA controllers - I couldn't test the PCI version since the only machine I have with one in is running that other o/s. -- Trevor Hemsley, Brighton, UK. [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: problems with reiserfs + nfs using 2.4.2-pre4
On Sunday February 18, [EMAIL PROTECTED] wrote: > > Hi, > > I migrated some exported disks over to reiserfs and had no luck when I > mounted the disk via NFS on another machine. I've noticed many messages > about reiser and NFS in the archives, but my understanding was that > it had been cleared up. In particular, the Configure.help in 2.4.2-pre4 > says "reiserfs can be used for anything that ext2 can be used for". pure marketing! Last I checked, it didn't have quotas either (well, it is available as an extra patch, but they might make incompatable changes later I gather). If you go to http://www.cse.unsw.edu.au/~neilb/patches/linux/2.4.2-pre3/ and pick up patch-B-nfsdops and patch-C-reisernfs you should get reasonable nfs service for reiserfs. Note that this is not final code though. The format of the filehandle will probably change shortly as it doesn't currently contain a generation number. A similar patch is available somewhere under www.namesys.com I believe. NeilBrown - 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/
[UPDATE] Zerocopy BETA 1, against 2.4.2-pre4
I'm calling this "BETA 1" because I currently feel that all performance and other issues have been addressed and that the patch is up for serious consideration for inclusion into a future 2.4.x release: ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2p4-1.diff.gz Besides merging to 2.4.2-pre4 the main change in this release is a totally revamped paged-SKB sendmsg implementation by Alexey. I truly believe now that bandwidth/latency is back to where we were before the zerocopy patches, and preliminary testing done by Andrew Morton supports this. (actually, in my own testing, latency over loopback seems to have improved) Some verbose TCP debugging is enabled in this release, most of the messages are harmless %99 of the time. If these messages bother you just set "FASTRETRANS_DEBUG" back to "1" in include/net/tcp.h Thanks. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
problems with reiserfs + nfs using 2.4.2-pre4
Hi, I migrated some exported disks over to reiserfs and had no luck when I mounted the disk via NFS on another machine. I've noticed many messages about reiser and NFS in the archives, but my understanding was that it had been cleared up. In particular, the Configure.help in 2.4.2-pre4 says "reiserfs can be used for anything that ext2 can be used for". Here's my setup: server box running RH71beta, kernel 2.4.2-pre4 compiled with gcc-2.95.2. client box running RH71beta, kernel 2.4.2-pre4 compiled with gcc-2.95.2. On the server, I built a standard kernel with NFS server, LVM, and reiser. On the client, I built a standard kernel with NFS client. On the server, the filesystem was created over an LVM logical volume. When I mounted the server-exported filesystem on the client node, there are no visible files or directories. Reverting to ext2 fixed the problem. I'd like to hear from people who have tried recent 2.4 kernels with RH7.1, NFS, and reiser, to see if anybody has had luck. Dave - 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: Proliant hangs with 2.4 but works with 2.2.
There is indeed a PS/2 mouse and it is plugged in. As far as I know its an Intel 440BX chipset since its a 100Mhz bus. >From: Johannes Erdfelt <[EMAIL PROTECTED]> >To: lafanga lafanga <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: Proliant hangs with 2.4 but works with 2.2. >Date: Sun, 18 Feb 2001 18:57:48 -0500 > >On Sun, Feb 18, 2001, lafanga lafanga <[EMAIL PROTECTED]> wrote: > > The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately > > after they exit (with exit status 0). I cannot pinpoint why the kernel >hangs > > and would appreciate any help. The only thing I suspect it may be is >that it > > is a dual processor mobo with only one processor but I don't know how >this > > detection has changed in the 2.4 kernels. > >I bet you it has to do with the PS/2 port. Do you have a mouse plugged >in? > >Does the 1600 use a Serverworks chipset? > >JE > _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - 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: Proliant hangs with 2.4 but works with 2.2.
On Sun, Feb 18, 2001, lafanga lafanga <[EMAIL PROTECTED]> wrote: > The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately > after they exit (with exit status 0). I cannot pinpoint why the kernel hangs > and would appreciate any help. The only thing I suspect it may be is that it > is a dual processor mobo with only one processor but I don't know how this > detection has changed in the 2.4 kernels. I bet you it has to do with the PS/2 port. Do you have a mouse plugged in? Does the 1600 use a Serverworks chipset? JE - 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 stifles innovation...
>> > On the other hand, they make excellent mice. The mouse wheel and >> > the new optical mice are truly innovative and Microsoft should be >> > commended for them. >> > >> The wheel was a nifty idea, but I've seen workstations 15 years old with >> optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross >grid mouse pad common on Sun workstations over the years. The Microsoft >optical mouse uses variations in the surface characteristics of whatever >it's on to perform it's function. The old optical mice just used two >different colors of LED's (red and IR) and a special pad. This would >actually have to scan and track the surface below it. Don't know that >I've seen anyone do that before. I doubt Micro$oft actually did the innovation there. After all, Apple now sell an optical mouse with similar capabilities, but with an innovative overall design (almost the entire upper surface forms the button!). Optical mouse technology has been developed continuously (with a fairly low profile) since the early models found on those Sun workstations, and both Micro$oft and Apple simply put said technology into their latest products. Maybe I'm biased, but I think Apple did a better job of it. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 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+ -END GEEK CODE BLOCK- - 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: Beware - kernel Newbie!
Thanks to all, I've just found http://www.linuxnewbie.org to be a good start point Pedro On Sunday 18 February 2001 23:57, Jeff Garzik wrote: > On Sun, 18 Feb 2001, Pedro Diaz Jimenez wrote: > > This is an typical mail from an experienced user-land programmer who > > wants to help in kernel development ;D. > > > > I've been lurking for a while in this list and I'm wondering if this is > > the right list for asking stupid newbie questions. Is it?. If not, do you > > know one?. Where I can find documentation? > > We are always welcome to answer newbie -kernel hacking- questions... > just ask specific ones. For example, ask "how does struct netdevice's > last_rx member get used?", not "what do I need to do to write a network > driver?" > > The documentation is in linux/Documentation/* > he he > > (yeah, yeah, read the code. But > > things are always better with an 'vi Doc.txt' in the processes tree :) > > Really. The code is the best documentation. Hone your code reading > skills. Use the source, Luke. > > Jeff > > > > > - > 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/
Proliant hangs with 2.4 but works with 2.2.
I have a Compaq Proliant 1600 server which can be hung on demand with all the 2.4 series kernels I have tried (2.4, 2.4.1 & 2.4.2-pre3). Kernel 2.2.16 runs perfectly (from a default RH7.0). I have ensured that the server meets the necessary requirements for the 2.4 kernels (modutils etc) and I have tried kgcc and various gcc versions. When compiling I have tried default configs and also minimalist configs (with only cpqarray and tlan). I have also ensured that I have the latest current SmartStart CD (4.9) and have setup the firmware for installing Linux. The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately after they exit (with exit status 0). I cannot pinpoint why the kernel hangs and would appreciate any help. The only thing I suspect it may be is that it is a dual processor mobo with only one processor but I don't know how this detection has changed in the 2.4 kernels. Thanks. Ayub. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - 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: Beware - kernel Newbie!
On Sun, 18 Feb 2001, Pedro Diaz Jimenez wrote: > This is an typical mail from an experienced user-land programmer who wants to > help in kernel development ;D. > > I've been lurking for a while in this list and I'm wondering if this is the > right list for asking stupid newbie questions. Is it?. If not, do you know > one?. Where I can find documentation? We are always welcome to answer newbie -kernel hacking- questions... just ask specific ones. For example, ask "how does struct netdevice's last_rx member get used?", not "what do I need to do to write a network driver?" The documentation is in linux/Documentation/* > (yeah, yeah, read the code. But > things are always better with an 'vi Doc.txt' in the processes tree :) Really. The code is the best documentation. Hone your code reading skills. Use the source, Luke. Jeff - 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_thread() & thread starting
Kenn Humborg writes:
> When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> make sure that the threads have run before continuing. Shouldn't
> start_context_thread() do something similar?
I think this would be a good idea. Here is a patch to try. Please report
back if it works so that it can be forwarded to Linus. Thanks.
--- orig/kernel/context.c Tue Jan 30 13:31:11 2001
+++ linux/kernel/context.c Sun Feb 18 22:51:56 2001
@@ -63,7 +63,7 @@
return ret;
}
-static int context_thread(void *dummy)
+static int context_thread(void *sem)
{
struct task_struct *curtask = current;
DECLARE_WAITQUEUE(wait, curtask);
@@ -79,6 +79,8 @@
recalc_sigpending(curtask);
spin_unlock_irq(&curtask->sigmask_lock);
+ up((struct semaphore *)sem);
+
/* Install a handler so SIGCLD is delivered */
sa.sa.sa_handler = SIG_IGN;
sa.sa.sa_flags = 0;
@@ -148,7 +150,9 @@
int start_context_thread(void)
{
- kernel_thread(context_thread, NULL, CLONE_FS | CLONE_FILES);
+ DECLARE_MUTEX_LOCKED(sem);
+ kernel_thread(context_thread, &sem, CLONE_FS | CLONE_FILES);
+ down(&sem);
return 0;
}
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.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/
Beware - kernel Newbie!
Hi all, This is an typical mail from an experienced user-land programmer who wants to help in kernel development ;D. I've been lurking for a while in this list and I'm wondering if this is the right list for asking stupid newbie questions. Is it?. If not, do you know one?. Where I can find documentation? (yeah, yeah, read the code. But things are always better with an 'vi Doc.txt' in the processes tree :) Thanks! Pedro - 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 stifles innovation...
On Sun, 18 Feb 2001, Steve VanDevender wrote: > Andre Hedrick writes: > > Those are not threats they are terms to enforce the License you agreed > > upon the very act of editing the source code that you are using in the > > kernel. > > Get it right, Andre. The mere act of editing a file that is part of a > GPL-licensed source distribution doesn't bind anyone to anything. > Anyone can download GPLed source and edit it all they want without > restriction, and they can also produce binaries for private use from > those edited sources without restriction. However, if they want to > distribute binaries derived from that source, edited or not, then the > GPL requires that they also distribute the source. > Steve, You are correct in the expanded definition and stand corrected; however, I assumed that we were already beyond the personal use issue. Because we were describing the situation of commerial issues. If this is all about personal use of the source and not redistribition for commerial purpose then why has it even used this much time of mailing list? Regards, Andre Hedrick Linux ATA Development - 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 stifles innovation...
Andre Hedrick writes: > Those are not threats they are terms to enforce the License you agreed > upon the very act of editing the source code that you are using in the > kernel. Get it right, Andre. The mere act of editing a file that is part of a GPL-licensed source distribution doesn't bind anyone to anything. Anyone can download GPLed source and edit it all they want without restriction, and they can also produce binaries for private use from those edited sources without restriction. However, if they want to distribute binaries derived from that source, edited or not, then the GPL requires that they also distribute the source. - 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/
kernel_thread() & thread starting
In init/main.c, do_basic_setup() we have: start_context_thread(); do_initcalls(); start_context_thread() calls kernel_thread() to start the keventd thread. Then do_initcalls() calls all the init functions and finishes by calling flush_scheduled_tasks(). This function ends up calling schedule_task() which checks if keventd is running. With a very stripped down kernel, it seems possible that do_initcalls() can complete without context_thread() having had a chance to run (and set the flag that keventd is running). Right now, in the Linux/VAX project, I'm working with a very stripped down kernel and I'm seeing this behaviour. Depending on what I enable in the .config, I can get schedule_task() to fail with: schedule_task(): keventd has not started When starting bdflush and kupdated, bdflush_init() uses a semaphore to make sure that the threads have run before continuing. Shouldn't start_context_thread() do something similar? Or am I missing something? Thanks, Kenn - 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 stifles innovation...
On Sun, 18 Feb 2001, Henning P . Schmiedehausen wrote: > Bla, bla, bla. The usual Andre Hedrick rant about how superior you're > to all other, threats and the cited hostility of "open source advocats" > about everyone not their opinion. > > You may be a really talented software developer with a deep under- > standing of the ATA subsystem. That does not give you the right to > insult all other people that are not your opinion. Mr. Schmiedehausen, I have not insulted you, just stated the facts. Those are not threats they are terms to enforce the License you agreed upon the very act of editing the source code that you are using in the kernel. It is you that would be violating the rules, and that makes me "hostile"? What about the issue you doing the initial terms and actions to harm me by willfully disregarding the the terms and usage? Please note that "you" refers to a generalixed individual. It is not intended to imply, state, charge, or any other means of accusing. > > When you begin to learn that OpenSource is the way and that some of us > > will work with companies on an as needed bases. At this point if you came > > Andre, I do this since quite a few years. I can live quote good from > it in my small vertical market and I love using free software for the > flexibility that I get. But this does not mean, that I will never ever > touch again a program where I have no source. I do this all the time > without and ideological prejudice. We agree that user-space programs that are value add are binaries. I also use programs that I have not source code for; however, you are now parsing the difference between user-space and kernel-space. I do not have a strong point of view on user-space open-source, however, if I got the source, hey no big deal. > > Once Linux decides to adopt and support AV Streams, it will be in the best > > interrest of TiVO to work with me so that they do not have to work against > > me. > > I see the fine point of you using the word "me". Not "the Linux community". Well, I would find very few that would not define "me" as part of "the Linux community". In fact these that have been charge with the task or have voluteered to the task of maintaining a supporting a subsystem are generally viewed as the contact point for that sub-system. ./drivers/net/ Don Becker ./drivers/scsi/ Justin Gibbs ./drivers/char(serial) Ted Ts'o ./drivers/usb/ The USB gang of Matt, Johannas, etc.. ./arch/arm/ Russel King ./arch/ia64/Walt Drummond ./arch/sparc(64)David Miller ./arch/ppc Paul Mac. ./arc/m68k Geert U. The point being, there are people designated as point or leaders. If you have an issue with me, you are free to submit it to Linus, Alan, or the List. Regards, Andre Hedrick Linux ATA Development - 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: Money stifles innovation [was: Linux stifles innovation.]
> On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > > About a year later I was talking with a group of business owners who had > > also received a similar demand letter. Some paid, some didn't. Those > > who didn't pay were not pursued other than the occasional copy of the > > demand letter. On Sun, Feb 18, 2001 at 12:57:14AM -0800, Dan Hollis wrote: > The XOR patent and the fraudulent enforcement of it is the purest > embodiment of everything that is wrong with the patent system and IP law. As a person with a some decades of experience with patents and trademarks, and playing among the various sides, I can state quite unequivocally that the problem is money. Courts, or rights, can simply be bought with enough money. And not necessarily in the way you would think. Here is a recent and true example: I owned the domain DemandTV.com, and had applied for a trademark. DirecTV, or DirectV, the satellite people, and subsidiary of Hughes Aerospace, contested my trademark application calling it 'confusingly similar'. Of course its not confusing similar as trademarks go. They started by subpoena'ing anyone that could find related to the trademark. Hours and hours of questions over multiple days. My own lawyers, a well respected big name law firm, said they really had no standing whatsoever and for a measly 1/2 million dollars we'd get the trademark through the PTO process. However, that is not the end. Even though the PTO would have blessed our trademark of DemandTV, it would still be up to District Courts as to decide whether we were infringing. And that is individual district courts all over the country. Hughes/DirectV could file basically as much as they want and we would be required to respond. We could try to sue for injunctive relief, but we would never "win" because we couldn't sustain the hemorrhage'ing of money. So they problem is that they have money and you don't so they win. Hughes was able to obtain the outcome they wanted simply because they had more money. Isn't that the golden rule? "He who has the gold makes the rules." -- Brian Litzinger <[EMAIL PROTECTED]> Copyright (c) 2000 By Brian Litzinger, All Rights Reserved - 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: AIC7xxx oops with justin gibbs patch on 2.4.1 alpha noritake
>Here's the dmesg when it happened (I took this via serial console which I was >logged in to) >[root@kakarot:/lvm/misc] cp /dev/zero . >(scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x33. Someone is sending a request that your drive believes specifies a data transfer to the drive such that either use_sg is 0 and request_buflen is 0 or use_sg is non-zero, but pci_map_sg returns 0. From looking at the alpha implementation of pci_map_sg, you should see a kernel message if it fails, so that should not be the problem. Some things to try... 1) In aic7xxx_linux.c:ahc_run_device_queue() around line 1612, you can add code to panic should we ever get to that point with scb-sg_count == 0 and cmd->sc_data_direction != SCSI_DATA_NONE. If that hits, printout cmd->use_sg and cmd->request_buflen. 2) In aic7xxx.c:ahc_handle_seqint() around line 743, you might want to print out scb->io_ctx->cmnd which is the cdb that was sent. It may also be good to print out cmd->use_sg and cmd->request_buflen. >From the looks of it, it logged me out. the 2nd oops I caused with the >sysrq-s. As you can see, I copied /dev/zero to a disk. That disk is >reiserfs ontop of LVM striping across 3 disks. 2.4.1 using the builtin >qlogic controller appears to be solid (had a 10 day uptime or so when I >shut it down. before with the reiserfs patch it would crash every 3-4 days >w/o usage). what's strange is the fact that once the disk is full it then >crashes. Last time I tried this, after the system came back up I noticed >that there were 0 bytes left on the drive (well 1995kb, but I couldn't write >anything, I think that's a reiserfs bug, not sure) Perhaps in the case of a full disk, the kernel queues a 0 length transaction that is not caught before reaching the SCSI driver. The driver doesn't spend a lot of its time trying to catch bogus transactions queued to it, so it doesn't surprise me that it falls over in this case. Hopefully the information gleaned from the above printks/panics will help track down the source of the bogus transaction. -- Justin - 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 OS boilerplate
On Sun, 18 Feb 2001, Scott Long wrote: > Does there exist an outline (detailed or not) of the boot process from > the point of BIOS bootsector load to when the kernel proper begins > execution? If not would anyone be willing to help me understand > bootsect.S and setup.S enough so that I might write such an outline? It might be a little fundamental but there is *a* boot loading process documented here: http://www.eecs.wsu.edu/~cs460/ Look over all the lecture notes and lab assignments up to the booter lab. I'd offer up my own explanation, but I'm just starting to learn this stuff. -karl - 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 stifles innovation...
In message <96o9uf$j4h$[EMAIL PROTECTED]>, "Henning P. Schmiedehausen" write s: > [EMAIL PROTECTED] (Gregory Maxwell) writes: > > >when you said commercial above) drivers for Linux, including the steaming > >pile of garbage your company ships. > > "hostile behaviour of the open source community towards people that > don't agree to their ideas". As I am a member of this community and have not exhibited such behavior to you, please include me *out* of such general condemnation. BTW, your conclusion is *false* -- +---+ | Bob Taylor Email: [EMAIL PROTECTED]| |---| | Like the ad says, at 300 dpi you can tell she's wearing a | | swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you | | can tell it's painted on. I suppose at 2400 dpi you can tell | | if the paint is giving her a rash. (So says Joshua R. Poulson)| +---+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
> You are defeating the entire purpose of having a hardware sector > size independently from the software block size. And 2kB is a > valid guess, apart from the drives that do 512 byte transfers too > 2kB is really the smallest transfer we can do. > > : And 2kB is a valid guess > > Strange. The twelve or so CD readers I have here are all > able to read 512-byte sectors. I am quite willing to believe I think most Plextor and Yamaha do, but it's not guaranteed to be supported. And it definitely won't for ATAPI with ide-scsi. Strange. I just used ATAPI with ide-scsi as test. It works. Did you verify that changing block size works? Just curious. Maybe you misunderstand. In reality no blocksize is changed. Setting hardsect_size to 2048 means: this hardware is unable to use smaller blocks, give an error to whoever asks for something smaller. Not setting hardsect_size at all means: I have no idea what this hardware can do. Now it is up to the user. If the user tries something the hardware cannot do, she will get EIO. Limiting the user in advance is a bad idea. But yes, I found an old CDROM with a blocksize of 1024, which was rejected by 2.4.1 and accepted by 2.4.1 after removing al mention of sr_hardsizes from sr.c. > is a good idea today. No padding reads involved. > If you disagree, please go slowly and state very explicitly > why you think I should be unable to mount ext2 filesystems with > a block size smaller than 2048 on my SCSI CD drive. I don't think you should be unable to, of course we would want to support 1kB ext2 and other file systems that want to change the block size. We are just disagreeing on how to do it. I don't think counting on being able to change the block size of a device at will always be reliable. It is not clear to me what you mean by "changing the block size". What problems do you see? Don't forget that 2.2 does not have sr_hardsizes, so all problems you see should be present in 2.2. Andries - 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 OS boilerplate
Have you seen Janet_Reno? ftp://linux01.gwdg.de/pub/cLIeNUX/interim/Janet_Reno.tgz IIRC. Janet is an x86 bootsector that gets into protected mode and can use the AT BIOS in pmode interrupts. It's written with a bunch of m4 macros I call asmacs that I'm currently basing an assembler in Bash on. That's shasm in the same directory as Janet. Rick Hohensee www.cLIeNUX.com - 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/
PROBLEM: pci bridge fails to wake up from suspend/resume( Inspiron 8000 )
Hello , i have some problems with my inspiron 8000 running kernler 2.4.1-ac16 and hope someone on this list can help me. the built in network card do not function after a suspend/resume , the only messages i receive is "eepro100: wait_for_cmd_done timeout!" , i belive the problem is in the pci bridge that the internal network card and modem is on(look tree.txt ) , i took a lspci -vx before suspend and one after and it seems as the io ports gets disabled for both the network card and modem ( look at before.txt /after.txt ) when i resume the machine again. I have included the following files which i hope can help in diagnose this problem: before.txt = lspci -vx before suspend after.txt = lspci -vx after resume tree.txt = lspci -tv dmesg.txt = dmesg if you need more info just give me a howler ? best regards Morten Stenseth [EMAIL PROTECTED] Linux version 2.4.1-ac16 (root@super-babar) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Sat Feb 17 00:58:02 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0feec000 @ 0010 (usable) BIOS-e820: 4000 @ 0ffec000 (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux2.4ac16 ro root=305 BOOT_FILE=/boot/vmlinuz-2.4.1-ac16 Initializing CPU#0 Detected 848.157 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1690.82 BogoMIPS Memory: 255504k/262064k available (1016k kernel code, 6172k reserved, 388k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0383f9ff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383f9ff CPU: After generic, caps: 0383f9ff CPU: Common caps: 0383f9ff CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfc06e, last bus=8 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 2: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router PIIX [8086/244c] at 00:1f.0 got res[f200:f2000fff] for resource 0 of Texas Instruments PCI4451 PC card Cardbus Controller got res[f2001000:f2001fff] for resource 0 of Texas Instruments PCI4451 PC card Cardbus Controller (#2) isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 169770kB/56590kB, 512 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=244a PCI_IDE: chipset revision 2 PCI_IDE: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:pio, hdd:pio hda: IBM-DJSA-232, ATA DISK drive hdb: TOSHIBA DVD-ROM SD-C2402, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 62506080 sectors (32003 MB) w/1874KiB Cache, CHS=3890/255/63 hdb: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others eth0: OEM i82557/i82558 10/100 Ethernet, 00:20:E0:64:49:64, IRQ 11. Receiver lock-up bug exists -- enabling work-around. Board assembly 727095-002, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed.
Re: Changes to ide-cd for 2.4.1 are broken?
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> > + /*
> > +* If not using Mt Fuji extended media tray reports,
> > +* just return TRAY_OPEN since ATAPI doesn't provide
> > +* any other way to detect this...
> > +*/
> > if (sense.sense_key == NOT_READY) {
> > - /* ATAPI doesn't have anything that can help
> > - us decide whether the drive is really
> > - emtpy or the tray is just open. irk. */
> > - return CDS_TRAY_OPEN;
> > + if (sense.asc == 0x3a && (!sense.ascq||sense.ascq ==
>1))
> > + return CDS_NO_DISC;
> > + else
> > + return CDS_TRAY_OPEN;
> > }
> >
> > My tray is open as I type, and it is misreported as CDS_NO_DISC. In
> > 2.4.0 it worked fine.
>
> Your drive is broken, the only other valid combination is 0x3a/0x02
> which means no media and tray open. You could try and dump the asc
> and ascq to see what your drive reports for the different states.
>
> Ha Jens - must we disagree twice on one evening?
:-)
> You know all about this stuff, so probably I am mistaken.
> However, my copy of SFF8020-r2.6 everywhere has
> "Sense 02 ASC 3A: Medium not present" without giving
> subcodes to distinguish Tray Open from No Disc.
> So, it seems to me that drives built to this spec will not have
> nonzero ASCQ.
Right, old ATAPI has 3a/02 as the only possible condition, so we
can't really tell between no disc and tray open. I guess the safest
is to just keep the old behaviour for !ascq and report open.
--
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/
AIC7xxx oops with justin gibbs patch on 2.4.1 alpha noritake
> There is one bug that might affect the Alpha in there. Once you have > patched your kernel, you should change the typedef of bus_addr_t in > drivers/scsi/aic7xxx/aic7xxx_osm.h from uint32_t to dma_addr_t: > > typedef uint32_t bus_addr_t > > becomes > > typedef dma_addr_t bus_addr_t > > I just noticed this today while testing an IA64 system (Compaq still > hasn't shipped us our Alpha) and it will be fixed in 6.1.2. 6.1.2 > will probably release on Friday. > > Please let me know how this works for you. Justin, subject says it all. here's the oops I get (only does it with the adaptec card, nothing else) See details at very bottom Decoded Oops: ksymoops 2.3.4 on alpha 2.4.1. Options used -v /241-aic7xxx (specified) -K (specified) -L (specified) -o /lib/modules/2.4.1-aic7xxx (specified) -m /boot/System.map-2.4.1-aic7xxx (specified) No modules in ksyms, skipping objects Unable to handle kernel paging request at virtual address 003ffc156000 pc = [] ra = [] ps = 0007 Using defaults from ksymoops -t elf64-alpha -a alpha v0 = 0001 t0 = 003ffc156000 t1 = 003ffc156000 t2 = 4000 t3 = 00c5efff t4 = 00c5afff t5 = fc156000 t6 = 0007 t7 = fc000837c000 s0 = 0001 s1 = 2000 s2 = fc000827d0c0 s3 = fc156080 s4 = 00c5efff s5 = 00c49000 s6 = fc000827d280 a0 = fc156080 a1 = 0007fc00 a2 = 0002 a3 = a4 = a5 = 00ff t8 = t9 = fc4b69a8 t10= fc4b6480 t11= 3fff pv = fc31c280 at = fc4b77f0 gp = fc4b5508 sp = fc000837faa8 Code: 42220642 e428 47e20401 2fe0 47ff041f 2fe0 42403532 >>PC; fc31b880<= Code; fc31b868 <_PC>: Code; fc31b868 0: 42 06 22 42 s8addq a1,t1,t1 Code; fc31b86c 4: 08 00 20 e4 beq t0,28 <_PC+0x28> fc31b890 Code; fc31b870 8: 01 04 e2 47 mov t1,t0 Code; fc31b874 c: 00 00 e0 2f unop Code; fc31b878 10: 1f 04 ff 47 nop Code; fc31b87c 14: 00 00 e0 2f unop Code; fc31b880<= 18: 00 00 e1 b7 stq zero,0(t0) <= Code; fc31b884 1c: 32 35 40 42 subq a2,0x1,a2 Here's the dmesg when it happened (I took this via serial console which I was logged in to) [root@kakarot:/lvm/misc] cp /dev/zero . (scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x33. (scsi1:A:2:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:0:0): data overrun detected in Data-out phase. Tag == 0x35. (scsi1:A:0:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:1:0): data overrun detected in Data-out phase. Tag == 0x34. (scsi1:A:1:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:1:0): data overrun detected in Data-out phase. Tag == 0x30. (scsi1:A:1:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x32. (scsi1:A:2:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:0:0): data overrun detected in Data-out phase. Tag == 0x31. (scsi1:A:0:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x3e. (scsi1:A:2:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:1:0): data overrun detected in Data-out phase. Tag == 0x3f. (scsi1:A:1:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x3a. (scsi1:A:2:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:1:0): data overrun detected in Data-out phase. Tag == 0x3b. (scsi1:A:1:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:0:0): data overrun detected in Data-out phase. Tag == 0x3d. (scsi1:A:0:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x39. (scsi1:A:2:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:1:0): data overrun detected in Data-out phase. Tag == 0x47. (scsi1:A:1:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x45. (scsi1:A:2:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:0:0): data overrun detected in Data-out phase. Tag == 0x3c. (scsi1:A:0:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:1:0): data overrun detected in Data-out phase. Tag == 0x46. (scsi1:A:1:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:0:0): data overrun detected in Data-out phase. Tag == 0x38. (scsi1:A:0:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x41. (scsi1:A:2:0): Have seen Data Phase. Length = 0. NumSGs = 0. (scsi1:A:1:0):
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote: > > A value of hardsect_size[] means: this is the smallest size > > the hardware can work with. It is therefore a serious mistake > > just to come with "a good guess". This value is used only > > You are defeating the entire purpose of having a hardware sector > size independently from the software block size. And 2kB is a > valid guess, apart from the drives that do 512 byte transfers too > 2kB is really the smallest transfer we can do. > > : And 2kB is a valid guess > > Strange. The twelve or so CD readers I have here are all > able to read 512-byte sectors. I am quite willing to believe I think most Plextor and Yamaha do, but it's not guaranteed to be supported. And it definitely won't for ATAPI with ide-scsi. Did you verify that changing block size works? Just curious. > that hardware exists that is unable to, but it is a bad idea > to refuse to mount filesystems just because of some "good guess" > that was not so good at all. By far most media used will be 2kB based, so it is a good guess. Of course we change it if we switch the block size. > So put 0 and sure anyone can submit I/O on the size that they want. > Now the driver has to support padding reads, or gathering data to do > a complete block write. This is silly. Sr should support 512b transfers > just fine, but only because I added the necessary _hacks_ to support > it. sd doesn't right now for instance. > > Please calm down. Removing this sr_hardsizes nonsense I'm perfectly calm. > is a good idea today. No padding reads involved. > If you disagree, please go slowly and state very explicitly > why you think I should be unable to mount ext2 filesystems with > a block size smaller than 2048 on my SCSI CD drive. I don't think you should be unable to, of course we would want to support 1kB ext2 and other file systems that want to change the block size. We are just disagreeing on how to do it. I don't think counting on being able to change the block size of a device at will always be reliable. -- 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: Linux OS boilerplate
Scott Long wrote: > Does there exist an outline (detailed or not) of the boot process from > the point of BIOS bootsector load to when the kernel proper begins > execution? If not would anyone be willing to help me understand > bootsect.S and setup.S enough so that I might write such an outline? I have been over it, and would be willing to help. You should first read all of the LILO documentation, and check out some of the LinuxBIOS project at www.linuxbios.org. - 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: MTU and 2.4.x kernel
Hello! > Please cite an exact RFC reference. Imagine, I found this reference yet. This is rfc1191, of course. 8) in the MSS option. The MSS option should be 40 octets less than the size of the largest datagram the host is able to reassemble (MMS_R, as defined in [1]); in many cases, this will be the architectural limit of 65495 (65535 - 40) octets. Alexey PS: But: A host MAY send an MSS value derived from the MTU of its connected network (the maximum MTU over its connected networks, for a multi-homed host); this should not cause problems for PMTU Discovery, and may dissuade a broken peer from sending enormous datagrams. Note: At the moment, we see no reason to send an MSS greater than the maximum MTU of the connected networks, and we recommend that hosts do not use 65495. It is quite possible that some IP implementations have sign-bit bugs that would be tickled by unnecessary use of such a large MSS. - 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: Changes to ide-cd for 2.4.1 are broken?
From: Jens Axboe <[EMAIL PROTECTED]>
On Sat, Feb 17 2001, John Fremlin wrote:
> Specifically, this part:
>
> @@ -2324,11 +2309,17 @@
> sense.ascq == 0x04)
> return CDS_DISC_OK;
>
> +
> + /*
> +* If not using Mt Fuji extended media tray reports,
> +* just return TRAY_OPEN since ATAPI doesn't provide
> +* any other way to detect this...
> +*/
> if (sense.sense_key == NOT_READY) {
> - /* ATAPI doesn't have anything that can help
> - us decide whether the drive is really
> - emtpy or the tray is just open. irk. */
> - return CDS_TRAY_OPEN;
> + if (sense.asc == 0x3a && (!sense.ascq||sense.ascq == 1))
> + return CDS_NO_DISC;
> + else
> + return CDS_TRAY_OPEN;
> }
>
> My tray is open as I type, and it is misreported as CDS_NO_DISC. In
> 2.4.0 it worked fine.
Your drive is broken, the only other valid combination is 0x3a/0x02
which means no media and tray open. You could try and dump the asc
and ascq to see what your drive reports for the different states.
Ha Jens - must we disagree twice on one evening?
You know all about this stuff, so probably I am mistaken.
However, my copy of SFF8020-r2.6 everywhere has
"Sense 02 ASC 3A: Medium not present" without giving
subcodes to distinguish Tray Open from No Disc.
So, it seems to me that drives built to this spec will not have
nonzero ASCQ.
Andries
-
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 OS boilerplate
I've been poring over the x86 boot code for a while now and I've been considering writing a FAQ on the boot process (mostly for my own use, but maybe others will be interested). This would include all relevant information on setting up the x86 hardware for a boot (timers, PIC, A20, protected mode, GDT, initial page tables, initial TSS, etc). The motivation behind this is that I would like to use the Linux boot system as a boilerplate booter for some experimental code. It's probably much cleaner and more robust than any boot loader I might come up with. Does there exist an outline (detailed or not) of the boot process from the point of BIOS bootsector load to when the kernel proper begins execution? If not would anyone be willing to help me understand bootsect.S and setup.S enough so that I might write such an outline? If no one can help me, would you consider it appropriate for me to send email to the people listed in bootsect.S and setup.S asking for assistance? Thanks, Scott - 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: question regarding routing/ethertap
Hi, I am sorry the might be of the list's normal content. My colleague will be on leave in may this year in states and wish to attend any I.T related conference during that period. Can you please send any info. if you are aware of any for that period. Thanks, Jones Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com - 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: MTU and 2.4.x kernel
Hello! > This smells bad. Datagram protocol send sizes are only limited by > socket buffer size, nothing more. Fragmentation makes it work. The thread was started from the observation that fragmented frames do _not_ pass through router. See? 8) Path mtu discovery exists exactly to help to solve this problem. In this case mtu is too low to be accepted by pmtu discovery, so that we simply disable it and start to fragment, exaclty like pmtu discovery was disabled completely. With all the consequences. So that workaround is not to _disable_ path mtu discovery, but to _enforce_ it, changing thresholds. The argument is subjectless. min_adv_mss must be changed to 256 in production version, no doubts. min_pmtu must stay at its current value of 576. That's all. Alexey - 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] nfsd + scalability
Hi Neil, all,
The nfs daemons run holding the global kernel lock. They still hold
this lock over calls to file_op's read and write.
The file system kernel interface (FSKI) doesn't require the kernel lock
to be held over these read/write calls. The nfs daemons do not require
that the reads or writes do not block (would be v silly if they did), so
they have no guarantee the lock isn't dropped and retaken during
blocking. ie. they aren't using it as a guard across the calls.
Dropping the kernel lock around read and write in fs/nfsd/vfs.c is a
_big_ SMP scalability win!
Attached patch is against 2.4.1-ac18, but should apply to most recent
kernel versions.
Mark
--- vanilla-2.4.1-ac18/fs/nfsd/vfs.cSun Feb 18 15:06:27 2001
+++ markhe-2.4.1-ac18/fs/nfsd/vfs.c Sun Feb 18 19:32:18 2001
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#define __NO_VERSION__
#include
@@ -602,12 +603,28 @@
file.f_ralen = ra->p_ralen;
file.f_rawin = ra->p_rawin;
}
+
+ /*
+* The nfs daemons run holding the global kernel lock, but
+* f_op->read() doesn't need the lock to be held.
+* Drop it here to help scalability.
+*
+* The "kernel_locked()" test isn't perfect (someone else could be
+* holding the lock when we're not), but it will eventually catch
+* any cases of entering here without the lock held.
+*/
+ if (!kernel_locked())
+ BUG();
+ unlock_kernel();
+
file.f_pos = offset;
oldfs = get_fs(); set_fs(KERNEL_DS);
err = file.f_op->read(&file, buf, *count, &file.f_pos);
set_fs(oldfs);
+ lock_kernel();
+
/* Write back readahead params */
if (ra != NULL) {
dprintk("nfsd: raparms %ld %ld %ld %ld %ld\n",
@@ -664,6 +681,22 @@
goto out_close;
#endif
+ /*
+* The nfs daemons run holding the global kernel lock, but
+* f_op->write() doesn't need the lock to be held.
+* Also, as the struct file is private, the export is read-locked,
+* and the inode attached to the dentry cannot change under us, the
+* lock can be dropped ahead of the call to write() for even better
+* scalability.
+*
+* The "kernel_locked()" test isn't perfect (someone else could be
+* holding the lock when we're not), but it will eventually catch
+* any cases of entering here without the lock held.
+*/
+ if (!kernel_locked())
+ BUG();
+ unlock_kernel();
+
dentry = file.f_dentry;
inode = dentry->d_inode;
exp = fhp->fh_export;
@@ -692,9 +725,12 @@
/* Write the data. */
oldfs = get_fs(); set_fs(KERNEL_DS);
err = file.f_op->write(&file, buf, cnt, &file.f_pos);
+ set_fs(oldfs);
+
+ lock_kernel();
+
if (err >= 0)
nfsdstats.io_write += cnt;
- set_fs(oldfs);
/* clear setuid/setgid flag after write */
if (err >= 0 && (inode->i_mode & (S_ISUID | S_ISGID))) {
Re: XOR [ was: Linux stifles innovation.]
| Since that time, about 1986, I learned that there is a whole cottage | industry of going through old, but not too old, patents and seeing how | they can be misconstrued to apply to current technology, buying the | patent for cheap, and then threatening "infringers". More or less | an extortion racket. Generally the license fee demanded is low enough | that is more cost effective, in the short term, to pay. And with | shareholder lawsuits the way they are, short term thinking | is the only thinking shareholders accept, and the extortionists | know it. Those of them that didn't end up in jail went on to form RAMBUS in the 90s. - 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: XOR [ was: Linux stifles innovation.]
| Since that time, about 1986, I learned that there is a whole cottage | industry of going through old, but not too old, patents and seeing how | they can be misconstrued to apply to current technology, buying the | patent for cheap, and then threatening "infringers". More or less | an extortion racket. Generally the license fee demanded is low enough | that is more cost effective, in the short term, to pay. And with | shareholder lawsuits the way they are, short term thinking | is the only thinking shareholders accept, and the extortionists | know it. Those of them that didn't end up in jail went on to form RAMBUS in the 90s. - 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: MTU and 2.4.x kernel
Hello! > Wouldn't it be simpler to just fix the bugs There are no bugs. There is phylosophical discussion about current state of internet communications. Alexey - 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: MTU and 2.4.x kernel
Hello! > Message size != MTU. Alan, you misunderstand _sense_ of the problem. Fragmentation does _not_ work on poor internet more. At all. Look at original report. It failed _only_ because his intemediate node failed to forward fragmented packets. Alexey - 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: SO_SNDTIMEO: 2.4 kernel bugs
Hello! > .. unless that page was partially written, in which case a short write > count is returned (rather than a timeout error), and the loop goes around > again. sendfile() does not return on partial write and tries to push more until error. On fast link it most likely succeeds, so that it is unkillable even with SIGKILL. > Which is good, because SO_SNDTIMEO is an inactivity monitor. Then why did you blame? 8)8) I do not think so. It is rather scheduling breaker. If connection is idle 99% of time, but wakes each sndtimeo-1usec, it must yuild, otherwise thread is lost for production. Alexey - 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: SO_SNDTIMEO: 2.4 kernel bugs
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > Hello! > > > So the actual timeout would be 2 * SO_SNDTIMEO. > > It will timeout if write of some page blocks for SO_SNDTIMEO. .. unless that page was partially written, in which case a short write count is returned (rather than a timeout error), and the loop goes around again. > If transmission of any page never takes more than SO_SNDTIMEO it never > times out. Which is good, because SO_SNDTIMEO is an inactivity monitor. Cheers 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: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
> A value of hardsect_size[] means: this is the smallest size > the hardware can work with. It is therefore a serious mistake > just to come with "a good guess". This value is used only You are defeating the entire purpose of having a hardware sector size independently from the software block size. And 2kB is a valid guess, apart from the drives that do 512 byte transfers too 2kB is really the smallest transfer we can do. : And 2kB is a valid guess Strange. The twelve or so CD readers I have here are all able to read 512-byte sectors. I am quite willing to believe that hardware exists that is unable to, but it is a bad idea to refuse to mount filesystems just because of some "good guess" that was not so good at all. > to reject impossible sizes, and everywhere the kernel accepts 0 > meaning "don't know". [Minor correction to my previous note: hardsect_size[MAJOR_NR] = NULL; is fine, putting 512 is fine as well, but putting 0 does not work because of the get_hardsect_size() that doesnt check for 0.] So put 0 and sure anyone can submit I/O on the size that they want. Now the driver has to support padding reads, or gathering data to do a complete block write. This is silly. Sr should support 512b transfers just fine, but only because I added the necessary _hacks_ to support it. sd doesn't right now for instance. Please calm down. Removing this sr_hardsizes nonsense is a good idea today. No padding reads involved. If you disagree, please go slowly and state very explicitly why you think I should be unable to mount ext2 filesystems with a block size smaller than 2048 on my SCSI CD drive. Andries - 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: SO_SNDTIMEO: 2.4 kernel bugs
Hello!
> So the actual timeout would be 2 * SO_SNDTIMEO.
It will timeout if write of some page blocks for SO_SNDTIMEO.
If transmission of any page never takes more than SO_SNDTIMEO it never
times out.
You can think about sendfile() as subroutine doing:
for (;;) {
read(4K from fdin);
write(4K to fdout);
}
All the options apply to each read()/write() separetely, so that... alas.
Alexey
-
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] HIGHMEM+buffers
Hi,
On a 4GB SMP box, configured with HIGHMEM support, making a 670G
(obviously using a volume manager) ext2 file system takes 12minutes (over
10minutes of sys time).
One problem is buffer allocations do not use HIGHMEM, but the
nr_free_buffer_pages() doesn't take this into account causing
balance_dirty_state() to return the wrong state.
The attached patch fixes the worse part of nr_free_buffer_pages() - with
HIGHMEM it now only counts free+inactive pages in the NORMAL and DMA
zone. It doesn't fix the inactive_dirty calculation.
Also, in buffer.c:flush_dirty_buffers(), it is worthwhile to kick the
disk queues if it decides to reschedule.
With the patch, that 670G filesystem can be created in 5m36secs (under
half the time).
Patch is against 2.4.1-ac18.
Mark
diff -urN -X dontdiff vanilla-2.4.1-ac18/fs/buffer.c markhe-2.4.1-ac18/fs/buffer.c
--- vanilla-2.4.1-ac18/fs/buffer.c Sun Feb 18 15:06:26 2001
+++ markhe-2.4.1-ac18/fs/buffer.c Sun Feb 18 19:03:19 2001
@@ -2638,8 +2638,11 @@
ll_rw_block(WRITE, 1, &bh);
atomic_dec(&bh->b_count);
- if (current->need_resched)
+ if (current->need_resched) {
+ /* kick what we've already pushed down */
+ run_task_queue(&tq_disk);
schedule();
+ }
goto restart;
}
out_unlock:
diff -urN -X dontdiff vanilla-2.4.1-ac18/include/linux/swap.h
markhe-2.4.1-ac18/include/linux/swap.h
--- vanilla-2.4.1-ac18/include/linux/swap.h Sun Feb 18 15:06:29 2001
+++ markhe-2.4.1-ac18/include/linux/swap.h Sun Feb 18 18:11:03 2001
@@ -65,7 +65,9 @@
extern int nr_swap_pages;
FASTCALL(unsigned int nr_free_pages(void));
+FASTCALL(unsigned int nr_free_pages_zone(int));
FASTCALL(unsigned int nr_inactive_clean_pages(void));
+FASTCALL(unsigned int nr_inactive_clean_pages_zone(int));
FASTCALL(unsigned int nr_free_buffer_pages(void));
extern int nr_active_pages;
extern int nr_inactive_dirty_pages;
diff -urN -X dontdiff vanilla-2.4.1-ac18/mm/page_alloc.c
markhe-2.4.1-ac18/mm/page_alloc.c
--- vanilla-2.4.1-ac18/mm/page_alloc.c Sun Feb 18 15:06:29 2001
+++ markhe-2.4.1-ac18/mm/page_alloc.c Sun Feb 18 19:04:36 2001
@@ -547,6 +547,23 @@
}
/*
+ * Total amount of free (allocatable) RAM in a given zone.
+ */
+unsigned int nr_free_pages_zone (int zone_type)
+{
+ pg_data_t *pgdat;
+ unsigned int sum;
+
+ sum = 0;
+ pgdat = pgdat_list;
+ while (pgdat) {
+ sum += (pgdat->node_zones+zone_type)->free_pages;
+ pgdat = pgdat->node_next;
+ }
+ return sum;
+}
+
+/*
* Total amount of inactive_clean (allocatable) RAM:
*/
unsigned int nr_inactive_clean_pages (void)
@@ -565,14 +582,43 @@
}
/*
+ * Total amount of inactive_clean (allocatable) RAM in a given zone.
+ */
+unsigned int nr_inactive_clean_pages_zone (int zone_type)
+{
+ pg_data_t *pgdat;
+ unsigned int sum;
+
+ sum = 0;
+ pgdat = pgdat_list;
+ while (pgdat) {
+ sum += (pgdat->node_zones+zone_type)->inactive_clean_pages;
+ pgdat = pgdat->node_next;
+ }
+ return sum;
+}
+
+
+/*
* Amount of free RAM allocatable as buffer memory:
+ *
+ * For HIGHMEM systems don't count HIGHMEM pages.
+ * This is function is still far from perfect for HIGHMEM systems, but
+ * it is close enough for the time being.
*/
unsigned int nr_free_buffer_pages (void)
{
unsigned int sum;
- sum = nr_free_pages();
- sum += nr_inactive_clean_pages();
+#ifCONFIG_HIGHMEM
+ sum = nr_free_pages_zone(ZONE_NORMAL) +
+ nr_free_pages_zone(ZONE_DMA) +
+ nr_inactive_clean_pages_zone(ZONE_NORMAL) +
+ nr_inactive_clean_pages_zone(ZONE_DMA);
+#else
+ sum = nr_free_pages() +
+ nr_inactive_clean_pages();
+#endif
sum += nr_inactive_dirty_pages;
/*
Re: SO_SNDTIMEO: 2.4 kernel bugs
On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > Hello! > > > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile(): > > None of the options apply to sendfile(). It is not socket level > operation. You have to use alarm for it. Hi Alexey, Actually sendfile() _does_ timeout using SO_SNDTIMEO. It just takes longer to timeout because the kernel sendfile() page loop will (usually) need to timeout a short write, and then timeout a 0 byte write. So the actual timeout would be 2 * SO_SNDTIMEO. Unfortunately, I'm seeing timeout at (I think) 3 * SO_SNDTIMEO, which I can't account for. Cheers 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: Changes to ide-cd for 2.4.1 are broken?
On Sat, Feb 17 2001, John Fremlin wrote:
> Specifically, this part:
>
> @@ -2324,11 +2309,17 @@
> sense.ascq == 0x04)
> return CDS_DISC_OK;
>
> +
> + /*
> +* If not using Mt Fuji extended media tray reports,
> +* just return TRAY_OPEN since ATAPI doesn't provide
> +* any other way to detect this...
> +*/
> if (sense.sense_key == NOT_READY) {
> - /* ATAPI doesn't have anything that can help
> - us decide whether the drive is really
> - emtpy or the tray is just open. irk. */
> - return CDS_TRAY_OPEN;
> + if (sense.asc == 0x3a && (!sense.ascq||sense.ascq == 1))
> + return CDS_NO_DISC;
> + else
> + return CDS_TRAY_OPEN;
> }
>
> My tray is open as I type, and it is misreported as CDS_NO_DISC. In
> 2.4.0 it worked fine.
Your drive is broken, the only other valid combination is 0x3a/0x02 which means
no media and tray open. You could try and dump the asc and ascq to see what
your drive reports for the different states.
--
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: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> Someone has added
> /*
> * These are good guesses for the time being.
> */
> for (i = 0; i < sr_template.dev_max; i++) {
> sr_blocksizes[i] = 2048;
> sr_hardsizes[i] = 2048;
> }
> blksize_size[MAJOR_NR] = sr_blocksizes;
> hardsect_size[MAJOR_NR] = sr_hardsizes;
> setting of hardsect_size to drivers/scsi/sr.c.
>
> A value of hardsect_size[] means: this is the smallest size
> the hardware can work with. It is therefore a serious mistake
> just to come with "a good guess". This value is used only
You are defeating the entire purpose of having a hardware sector
size independently from the software block size. And 2kB is a
valid guess, apart from the drives that do 512 byte transfers too
2kB is really the smallest transfer we can do.
> to reject impossible sizes, and everywhere the kernel accepts 0
> meaning "don't know".
So put 0 and sure anyone can submit I/O on the size that they want.
Now the driver has to support padding reads, or gathering data to do
a complete block write. This is silly. Sr should support 512b transfers
just fine, but only because I added the necessary _hacks_ to support
it. sd doesn't right now for instance.
In my oppinion we are always going to have hacks like this unless we
add some generic support for < hardware submission of I/O. Simply
ignoring this issue only makes it worse.
--
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: Linux stifles innovation...
On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote: > On Sun, 18 Feb 2001, Michael H. Warfield wrote: > > On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > > > > > On the other hand, they make excellent mice. The mouse wheel and > > > > the new optical mice are truly innovative and Microsoft should be > > > > commended for them. > > > > > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > > > optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross > > grid mouse pad common on Sun workstations over the years. The Microsoft > > optical mouse uses variations in the surface characteristics of whatever > > it's on to perform it's function. The old optical mice just used two > > different colors of LED's (red and IR) and a special pad. This would > > actually have to scan and track the surface below it. Don't know that > > I've seen anyone do that before. > I remember being at a computer show in Minneapolis where a small company > was showing off this mouse that worked on a variety of surfaces without a > ball. I'm trying to remember if the mouse was optical or used yet another > method of functioning -- I think it was optical, though I could be > mistaken. This was in 1992/1993. I think you are correct here. I seem to recall mention of some of those earlier devices at the time of the Microsoft announcement. I seem to also recall some of the reliability problem they had. I believe they were extremely fussy about the surface they were on. > The point is, I really do not believe Microsoft made the "leap" to provide > opitcal mice without the need of the mousepad grid. Their "innovation" was > in marketing it on a wide scale though. I would agree there. They did something to improve the reliability on a wider variety of surface textures, though. Is that innovation or merely getting a good idea, that's been around, to finally work? Don't know. I didn't find the idea itself particularly innovative. The fact that they did get it to work reliable is something to be said. The marketing is a given, of course. Particularly in the face of the preception in some camps that this style of optical mouse was unreliable. > I could be mistaken - if so then let's give them their credit - but I have > a hard time believing it was their idea without some serious proof. Agreed. 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: PROBLEM: page_alloc 2.4.1 kernel BUG running java 1.3.0
Rob Leathley wrote:
>
> [X] I have been suffering a lot of memory paging related Oops' on the
> above PC since upgrading to the 2.2.16 kernel. Most of these problems
> are fixed in 2.4.1 appart from the above. These problems don't appear
> on a faster machine (e.g. P3 733MHz) so could be related to race
> conditions? I appreciate that there is probably a bug in java 1.3.0 but
> it would be nice if it didn't kill the whole machine!
>
It's not a bug in java 1.3.0, that certain.
It's either a kernel bug or bad memory. Usually I'd say bad memory, but
your report is the third or forth one with __free_pages_ok(), so I
suspect a kernel bug.
Could you apply the attached patch to your kernel and run it until it
crashes again?
--
Manfred
--- linux.old/mm/page_alloc.c Sun Feb 18 20:06:11 2001
+++ linux/mm/page_alloc.c Sun Feb 18 20:05:59 2001
@@ -70,8 +70,15 @@
if (page->buffers)
BUG();
- if (page->mapping)
+ if (page->mapping) {
+ printk(KERN_EMERG "found bad mapping %lxh.\n",
+ (unsigned long)page->mapping);
+ printk(KERN_EMERG "page->mapping->nrpages: %d.\n",
+ (int)page->mapping->nrpages);
+ printk(KERN_EMERG "page->mapping->a_ops: [<%lxh>]\n",
+ (unsigned long)page->mapping->a_ops);
BUG();
+ }
if (!VALID_PAGE(page))
BUG();
if (PageSwapCache(page))
Re: too long mac address for --mac-source netfilter option
On Fri, Feb 16, 2001 at 05:40:04PM -0800, Jack Bowling wrote: > I am trying to use the --mac-source option in the netfilter code to better > refine access to my linux box. However, I have run up against something. The > router through which my private subnet work box passes sends a 14-group > "invalid" mac address, presumably as an attempt to conceal the real hextile > mac address. However, the code for the --mac-source netfilter option is > looking for a valid hextile mac address and complains loudly as such > (numerals converted to x's): > > iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx' > > to the respective iptable line: > > $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source > xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT > > The idea here is to allow VNC access to my home box with the access filtered > by both IP and mac address. This is not a bug. It is by intention. The LOG target (as well as the ULOG target from netfilter CVS) prints the whole layer two header. 6 bytes mac-source, 6 bytes mac-destination and 2 bytes (08:00) indicating it is IP. == 14 bytes :) On the other hand, the --mac-source match (emphasized mac-SOURCE) allows you to match on the source part of this mac header (i.e. the first 6 bytes) > Jack Bowling > mailto: [EMAIL PROTECTED] -- 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: Linux stifles innovation...
On Sun, 18 Feb 2001, Gregory S. Youngblood wrote: > I remember being at a computer show in Minneapolis where a small company > was showing off this mouse that worked on a variety of surfaces without a > ball. I'm trying to remember if the mouse was optical or used yet another > method of functioning -- I think it was optical, though I could be > mistaken. This was in 1992/1993. > > The point is, I really do not believe Microsoft made the "leap" to provide > opitcal mice without the need of the mousepad grid. Their "innovation" was > in marketing it on a wide scale though. I believe I read about an optical mouse that worked on any surface by tracking surface constrast movement in an old issue of Byte. I think it was an Xerox invention, but my memory may be off. Peter -- Peter Svensson ! Pgp key available by finger, fingerprint: <[EMAIL PROTECTED]>! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF <[EMAIL PROTECTED]> ! Remember, Luke, your source will be with you... always... - 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.2.x: TCP lockups with tcp_timestamps
Hello! > Yes. The 5.6.7.8 machine is connected to the Internet via a Linksys > "router" that is also performing masquerade. > > I will be very angry if this turns out to be the culprit. I am afraid it is. It corrupts packets preserving their checksum. Look: > Trace taken from 1.2.3.4 machine ... > 20:29:35.179648 1.2.3.4.379 > 5.6.7.8.1053: P 16468:16528(60) ack 65211 win 31856 > (DF) and > Trace taken from 5.6.7.8 (aka 192.168.1.102) machine ... > 19:18:26.808820 < 1.2.3.4.379 > 192.168.1.102.1053: P 16468:16528(60) ack 65211 win >31856 (DF) 5.6.7.8 received packet with garbage in timestamp area: <3643345 3395672641> instead of <3397515 1679644> And checksum is "corrupted" so that it remains right, which is impossible to make occasionally. Alexey - 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/
PROBLEM: page_alloc 2.4.1 kernel BUG running java 1.3.0
Here is a bug report in the format requested by linux/REPORTING-BUGS: [1] page_alloc 2.4.1 kernel BUG running java 1.3.0 [2] Running java 1.3.0 e.g. 'java -jar SwingSet2.jar' etc. causes system crashes and on other occasions, problems running other programs (e.g. umount) subsequently. This does not happen every time but is likely after ~30 minutes of runnning a java application. [3] kernel page_alloc free_pages memory [4] Linux version 2.4.1 (gcc version egcs-2.91.66) [5] Feb 15 22:38:02 susy kernel: kernel BUG at page_alloc.c:75! Feb 15 22:38:02 susy kernel: invalid operand: Feb 15 22:38:02 susy kernel: CPU:0 Feb 15 22:38:02 susy kernel: EIP:0010:[__free_pages_ok+62/840] Feb 15 22:38:02 susy kernel: EFLAGS: 00210296 Feb 15 22:38:02 susy kernel: eax: 001f ebx: c10b6fc8 ecx: edx Feb 15 22:38:02 susy kernel: esi: c10b6fc8 edi: ebp: 000b esp Feb 15 22:38:02 susy kernel: ds: 0018 es: 0018 ss: 0018 Feb 15 22:38:02 susy kernel: Process bdflush (pid: 6, stackpage=c5ff1000) Feb 15 22:38:02 susy kernel: Stack: c01d3d51 c01d3eff 004b c10b6ff0 c10b6fc8 Feb 15 22:38:02 susy kernel:0018 0018 ff0e c0128748 c0129dde Feb 15 22:38:02 susy kernel: 0008e000 0004 Feb 15 22:38:02 susy kernel: Call Trace: [page_launder+1220/2072] [__free_pages+ Feb 15 22:38:02 susy kernel: Feb 15 22:38:02 susy kernel: Code: 0f 0b 83 c4 0c 89 da 2b 15 b8 b9 25 c0 89 d0 Feb 15 22:38:02 susy kernel: kernel BUG at exit.c:457! Feb 15 22:38:02 susy kernel: invalid operand: Feb 15 22:38:02 susy kernel: CPU:0 Feb 15 22:38:02 susy kernel: EIP:0010:[do_exit+523/536] Feb 15 22:38:02 susy kernel: EFLAGS: 00013282 Feb 15 22:38:02 susy kernel: eax: 001a ebx: c0205cc0 ecx: edx Feb 15 22:38:02 susy kernel: esi: c5ff edi: 000b ebp: 000b esp Feb 15 22:38:02 susy kernel: ds: 0018 es: 0018 ss: 0018 Feb 15 22:38:02 susy kernel: Process bdflush (pid: 6, stackpage=c5ff1000) Feb 15 22:38:02 susy kernel: Stack: c01d0831 c01d0968 01c9 c5ff1f44 Feb 15 22:38:02 susy kernel:c01095a3 c01ca95a c5ff1f44 c5ff Feb 15 22:38:02 susy kernel:00030002 c012943e c5ff1f04 01c0 000e Feb 15 22:38:02 susy kernel: Call Trace: [do_invalid_op+0/136] [die+66/68] [do_i Feb 15 22:38:02 susy kernel:[ret_from_intr+0/32] [do_invalid_op+0/136] [ Feb 15 22:38:02 susy kernel:[bdflush+134/208] [kernel_thread+35/48] Feb 15 22:38:02 susy kernel: Feb 15 22:38:02 susy kernel: Code: 0f 0b 83 c4 0c e9 45 fe ff ff 8d 76 00 8b 4c Feb 15 22:38:02 susy kernel: kernel BUG at exit.c:457! ... Feb 17 18:41:18 susy kernel: kernel BUG at page_alloc.c:73! Feb 17 18:41:19 susy kernel: invalid operand: Feb 17 18:41:19 susy kernel: CPU:0 Feb 17 18:41:19 susy kernel: EIP:0010:[__free_pages_ok+34/840] Feb 17 18:41:19 susy kernel: EFLAGS: 00210282 Feb 17 18:41:19 susy kernel: eax: 001f ebx: c10ceba0 ecx: edx Feb 17 18:41:19 susy kernel: esi: 030a4067 edi: ebp: 0004d000 esp Feb 17 18:41:19 susy kernel: ds: 0018 es: 0018 ss: 0018 Feb 17 18:41:19 susy kernel: Process java (pid: 3043, stackpage=c0fa7000) Feb 17 18:41:19 susy kernel: Stack: c01d3d51 c01d3eff 0049 c10ceba0 030a4067 Feb 17 18:41:19 susy kernel:c1044010 c0208f60 00200213 1052 c0129dde Feb 17 18:41:19 susy kernel:c011ed60 c10ceba0 c4c1f7a0 c40b1640 0804d000 Feb 17 18:41:19 susy kernel: Call Trace: [__free_pages+26/28] [free_page_and_swa Feb 17 18:41:19 susy kernel:[system_call+51/64] Feb 17 18:41:19 susy kernel: Feb 17 18:41:19 susy kernel: Code: 0f 0b 83 c4 0c 83 7b 08 00 74 16 6a 4b 68 ff [6] see[2] [7.1] sh scripts/ver_linux -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux susy 2.4.1 #1 Sat Feb 3 16:46:27 GMT 2001 i586 unknown Kernel modules 2.4.1 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.9.5.0.24 Linux C Libraryx 1 root root 4070406 Aug 5 2000 /lib/libc.so.6 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10m Net-tools 1.56 Kbd0.99 Sh-utils 2.0 Modules Loaded usbcore serial isa-pnp C libs: /usr/i386-glibc21-linux /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so [7.2] processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping: 12 cpu MHz : 132.956 fdiv_bug: no hlt_bug : no f00f_bug: yes coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 bogomips: 265.42 [7.3] usbcore28688 0 (autoclean) (unused) serial 42736 0 (autoclean) isa-pnp2
Re: Linux stifles innovation...
On Sun, Feb 18, 2001 at 09:50:17AM -0800, Andre Hedrick wrote: [...] > If you do not like that rule, LEAVE! [...] > if I catch you abusing the privildge of use of my work, I will > pursue you in terms defined as actionable. [...] > And you do not have the knowledge or authority to comment on this subject > where "I do". [...] Bla, bla, bla. The usual Andre Hedrick rant about how superior you're to all other, threats and the cited hostility of "open source advocats" about everyone not their opinion. You may be a really talented software developer with a deep under- standing of the ATA subsystem. That does not give you the right to insult all other people that are not your opinion. > When you begin to learn that OpenSource is the way and that some of us > will work with companies on an as needed bases. At this point if you came Andre, I do this since quite a few years. I can live quote good from it in my small vertical market and I love using free software for the flexibility that I get. But this does not mean, that I will never ever touch again a program where I have no source. I do this all the time without and ideological prejudice. > Once Linux decides to adopt and support AV Streams, it will be in the best > interrest of TiVO to work with me so that they do not have to work against > me. I see the fine point of you using the word "me". Not "the Linux community". Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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 stifles innovation...
On Sun, 18 Feb 2001, Michael H. Warfield wrote: > On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > > > On the other hand, they make excellent mice. The mouse wheel and > > > the new optical mice are truly innovative and Microsoft should be > > > commended for them. > > > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > > optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross > grid mouse pad common on Sun workstations over the years. The Microsoft > optical mouse uses variations in the surface characteristics of whatever > it's on to perform it's function. The old optical mice just used two > different colors of LED's (red and IR) and a special pad. This would > actually have to scan and track the surface below it. Don't know that > I've seen anyone do that before. I remember being at a computer show in Minneapolis where a small company was showing off this mouse that worked on a variety of surfaces without a ball. I'm trying to remember if the mouse was optical or used yet another method of functioning -- I think it was optical, though I could be mistaken. This was in 1992/1993. The point is, I really do not believe Microsoft made the "leap" to provide opitcal mice without the need of the mousepad grid. Their "innovation" was in marketing it on a wide scale though. I could be mistaken - if so then let's give them their credit - but I have a hard time believing it was their idea without some serious proof. - 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 stifles innovation...
On Sun, 18 Feb 2001, Henning P. Schmiedehausen wrote: > >- Innovative new hardware devices are more likely to be based on > >Linux than any Microsoft OS. For example, the TiVO, the coolest > >improvement to television since the VCR. Henning, When you begin to learn that OpenSource is the way and that some of us will work with companies on an as needed bases. At this point if you came to me I would put you through the same grinder that I do every other use of the ATA/ATAPI subsystem for commerial purpose. I have the duty and right to protect that which was entrusted to me and that which I create. If you do not like that rule, LEAVE! Henning, if I catch you abusing the privildge of use of my work, I will pursue you in terms defined as actionable. It is not a game. > Because it is cheaper to use. Linux has no license fee. That's what > the TiVO vendor cares about. Henning, And you do not have the knowledge or authority to comment on this subject where "I do". Maybe it you would bother the take you shoe out of your mouth one more time than you put it in you could not sound more like a fool, today. TiVO came to Linux and Linux went back to TiVO in a working relationship. ** Date: Mon, 22 May 2000 14:10:42 -0700 From: Mike Klar <[EMAIL PROTECTED]> To: Andre Hedrick <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> Subject: Re: non-PCI IDE DMA in Linux IDE driver The 2.3-based tree is not in a releaseable state at his point, and doesn't have the AV stuff in it yet, anyway. The 2.1-based code (which is what our shipping units currently use) is available, I can inquire into the release mechanism for that if you're interested. Mike Klar TiVo Inc. Andre Hedrick wrote: > > Greetings Mike, > > Can I see the source tree under the rules of GPL? > I know that you are doing AV streams and that is the hot topic at t13. > > Cheers, > > Andre Hedrick > The Linux ATA/IDE guy ** Once Linux decides to adopt and support AV Streams, it will be in the best interrest of TiVO to work with me so that they do not have to work against me. This is how you work with industry. You load share the work. Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
From: Jon Forsberg <[EMAIL PROTECTED]>
I have two ext2 CD-ROMs. One of them I can mount the normal way,
the other I can't. Both are ok according to debugfs and e2fsck
and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom'
instead, both work.
The one that doesn't work have a blocksize of 1024 according to debugfs:
Block size = 1024, fragment size = 1024
And the other:
Block size = 4096, fragment size = 4096
What happens:
# mount -t ext2 /dev/cdrom /cdrom
mount: block device /dev/cdrom is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/cdrom,
or too many mounted file systems
kern.log:
Feb 18 14:54:34 pc1 kernel: VFS: Unsupported blocksize on dev sr(11,0).
I'm pretty sure both worked with 2.2.17.
You are being bitten by two bugs. By some coincidence I sent a
patch for the first one to Linus and Alan yesterday.
(That was fs/ext2/super.c - the same bug occurs in both 2.2 and 2.4.)
However, the second one will then still prevent you from mounting,
and it occurs only in 2.4.
Someone has added
/*
* These are good guesses for the time being.
*/
for (i = 0; i < sr_template.dev_max; i++) {
sr_blocksizes[i] = 2048;
sr_hardsizes[i] = 2048;
}
blksize_size[MAJOR_NR] = sr_blocksizes;
hardsect_size[MAJOR_NR] = sr_hardsizes;
setting of hardsect_size to drivers/scsi/sr.c.
A value of hardsect_size[] means: this is the smallest size
the hardware can work with. It is therefore a serious mistake
just to come with "a good guess". This value is used only
to reject impossible sizes, and everywhere the kernel accepts 0
meaning "don't know".
So, probably all will work fine if you change the second
2048 here to say 512 or 0. Or, if you, more drastically,
remove all references to sr_hardsizes[] from sr.c.
Andries
-
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: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile
> Minor nit, but I'd rather clear it up now. Which distribution you run
> doesn't matter for debugging. What does matter is that we've got known
> problems with a given compiler, and that compiler goes by a few different
> flavors with the same version number. Since there are known problems, if
> you don't provide the compiler version, I'll ask. If your bug is *really*
> odd, I might ask a few different ways, just to make sure you give the same
> answer every time ;-)
Well, a nit to a nit... In my experience it surely matters which distribution
somebody runs, since that tells a lot about the basic system (libc, probable
compiler, binutils, etc). RH7 is broken in many respects. Since it uses
glibc-2.2 as well, I usually add the notice that I do NOT run RH7 to messages
like these where I mention I use glibc-2.2.x, if only to ward off the usual
'are you running RH7 if yes please upgrade so and so' cycle. Bits and electrons
are much to precious to waste on
useless banter like that...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
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: SO_SNDTIMEO: 2.4 kernel bugs
Hello! > Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile(): None of the options apply to sendfile(). It is not socket level operation. You have to use alarm for it. BTW, if you have enough fast network, you probably can observe that sendfile() is even not interrupted by signals. 8) But this is possible to fix at least. BTW the same fix will repair SO_*TIMEO partially, i.e. it will timeout after n*timeo, where n is an arbitrary number not exceeding size/sndbuf. Alexey - 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: aic7xxx (and sym53c8xx) plans
>Have you any idea the breadth of cards and chips that aic7xxx supports? >Sure, Justin's driver does great with your shiny new 7899, but can you >verify that it also drives the 8-year-old EISA AHA-2740 I still have >sitting around (actually retired to the parts pile, but that's beside >the point, I'm sure some still exist in the wild)? How about the VLB >card I have in my 486 at home? I use a Dual Pentium-90 with PCI/EISA slots to test a 2742T and a 2740W. I haven't tested a 284X card for some time just for lack of a VLB machine (I have a card), but since it uses the aic7770 just like the 274X does, I'd be very surprised if it didn't just work. Version 6.1.2 of the driver has been tested on a G3 PowerMac, a Compaq Blazer IA64 machine, and about 14 different PC motherboards. We have an AS1200 on the way from Compaq too so we can test EISA and PCI support on the Alpha. I've verified the driver's functionality on 25 different cards thus far covering the full range of chips from aic7770->aic7899. Lots of people here at Adaptec look at me funny when I pull a PC from the scrap-heap, or pull an old, discontinued card from an unused marketing display for use in my lab, but I'm well aware of how these cards get used in 386sx routers/firewalls etc, and those configurations will be supported. -- Justin - 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: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaksmozilla compile
On Sunday, February 18, 2001 03:07:27 AM +0100 Frank de Lange <[EMAIL PROTECTED]> wrote: > > And no, I'm not running RedHat 7.x for those who might think so (and > automatically blame everything on it). > Minor nit, but I'd rather clear it up now. Which distribution you run doesn't matter for debugging. What does matter is that we've got known problems with a given compiler, and that compiler goes by a few different flavors with the same version number. Since there are known problems, if you don't provide the compiler version, I'll ask. If your bug is *really* odd, I might ask a few different ways, just to make sure you give the same answer every time ;-) -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: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaksmozilla compile
On Sunday, February 18, 2001 02:10:50 AM +0100 Frank de Lange <[EMAIL PROTECTED]> wrote: >> At least the patch didn't make it worse. Would anyone care to comment on >> how the elf-dynstr-gc option changes the file access patterns for the >> compile? > > It does not change the file access patterns, it adds an extra step. A > separate binary (dist/bin/elf-dynstr-gc, a convoluted version of strip) > is run over the final (linked) library/executable to remove some symbol > info. The elf-dynstr-gc program is compiled as part of the mozilla build. > There's nothing wrong with elf-dynstr-gc on the reiserfs filesystem, it > is identical to the one on the ext2 partition. Running the 'reiserfs' > version on the ext2 tree works as it should, running the ext2 version on > the reiserfs tree crashes (seems the program is not very robust, as it > does not detect garbled input files). As said, running objdump on the > corrupted (reiserfs compiled) library also produces errors. Great, that will help narrow things down. Please run the elf-dynstr-gc program under strace, on top of both the ext2 and reiserfs trees, and send the results (privately, they'll probably be large) to me. -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: Linux stifles innovation...
On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > On the other hand, they make excellent mice. The mouse wheel and > > the new optical mice are truly innovative and Microsoft should be > > commended for them. > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > optical mice. It wasn't MS's idea. I think their "innovation" was not requiring the optical cross grid mouse pad common on Sun workstations over the years. The Microsoft optical mouse uses variations in the surface characteristics of whatever it's on to perform it's function. The old optical mice just used two different colors of LED's (red and IR) and a special pad. This would actually have to scan and track the surface below it. Don't know that I've seen anyone do that before. > -b 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/
Free libre internet search engine.
Hi.. well this is off-topic sorry.. somebody is going to kill me but.. somebody has to make sure about this, Being aware about the new Microsoft "world domination" attempt with its .NET platform and after years watching how the Internet is getting more and more commercial (well this maybe is not that bad while freedom be respected).. I would like to propose the following: (and maybe it exist already if so tell me please and sorry!). We need a free, libre, Internet Search Engine.. we should coordinate this from all the international LUG's.. this Internet search engine should be not for profit but to ensure in the future that all of us will have a site of reference to query for all pages/information/documentation in the Internet without economical or other kind of interests interfering. We also should made sure that in the future every document in the Internet could have a chance to be indexed in order to be founded from every place around the world. Maybe this is not for tomorrow.. but a libre search engine is something needed.. Sorry very much, for my english that I am trying to improve and for my off-topic.. but I think is necessary to mention the possibility of a project like this. Sorry and thank you very much indeed. If you believe in this idea please write the FSF so they could coordinate all the effort. God bless you all!! Regards Roberto Roberto Diaz <[EMAIL PROTECTED]> http://vivaldi.dtts.net Powered by ddt dynamic DNS Powered by GNU running on a Linux kernel. Powered by Debian (The real wonder) Concerto Grosso Op. 3/8 A minor Antonio Vivaldi (so... do you need beautiful words?) - 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 stifles innovation... [way O.T.]
"Henning P. Schmiedehausen" wrote: > > [EMAIL PROTECTED] (Michael H. Warfield) writes: > > > Excuse me? A 1 billion dolar investment in Linux is not > >supporting it? > > On their own hardware. Which is really the point and they won't be the only ones. If IBM wants to attract and keep customers on their hardware, they will ensure that the software and Linux drivers for it run very well, if Linux is going to be their main play to sell hardware. The same will hold true for other hardware manufacturers, including those the make video cards, modems, etc, as Linux grows in the marketplace. Linux will not displace the software industry, it will eventually displace the commodity portions of it. This is what has Microsoft afraid, since commodity software is their real play, games and specialty software isn't. The fact is, the majority of software is written in-house and through contracted professional services work, not off the shelf. Linux will make that side of the industry even more valuable, it will empower the developers and the businesses that hire them to do even more than they can today. It will empower them to do it right. As for games and similar specialties, they aren't going anywhere. It costs far too much money to produce a high-end game and the open source world either can't afford it or can't produce it fast enough to support the market. So Allchin's flag waving is simple posturing. Microsoft may become irrelevant, but the software industry won't. John - 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 stifles innovation...
Hi. Thought I'd toss my 0.02sek into the discussion. > > > objective, arent we? > >Nope. Are you claiming to be? > > > > > For example, if there were six different companies that marketed ethernet > > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > >... Rant deleted > > > >I had a problem with eepro100. > >It was fixed same night cause I had the source. > >Don't even try to compare with MickyS**t. > > good commercial drivers dont need fixing. another point. You are arguing > that having source is required to fix crappy code, which i agree with. Ok, tell that to my SBLive that absolutely loves jumping and jittering on my SMP box under Win2k. Creative have been notified. Ever since they released their first driver for it... So if they would've had their driver out in the open I'm sure SOMEONE, if not me, would've squashed the bug already. So you're right, good commercial drivers don't need fixing. Also, good open-source drivers don't need fixing. Good drivers don't need fixing! Of course they don't! But crap coding is crap coding no matter what license/distribution form you put it under, be it open source, closed source or whatnot. // Stefan - 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.2-pre3: parport_pc init_module bug
On Wed, 14 Feb 2001, Grant Grundler wrote: > Philipp Rumpf wrote: > > Jeff Garzik wrote: > > > Looks ok, but I wonder if we should include this list in the docs. > > > These is stuff defined by the PCI spec, and this list could potentially > > > get longer... (opinions either way wanted...) > > Having people look things up in the spec isn't very user friendly. > Finding a copy of the PCI 2.1 or 2.2 spec I could pass on to others > (outside of HP) was a problem last year. The best I could do then > (legally) was point them to "PCI Systems Architecture" published > by MindShare. _PCI Systems Architecture_ is an awesome book, definitely. AFAIK there are two avenues to go, when getting the PCI specs. Become a PCI SIG member (much $$$), or buy a CD-ROM. For US$50, a non-member can purchase a CD-ROM from the PCI SIG which includes the latest versions of all the PCI specifications, in PDF format, as well as a hardcopy of the PCI 2.2 spec itself. Great deal, I recommend it for anybody intersted in hacking PCI. Jeff - 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] a more efficient BUG() macro
Keith Owens <[EMAIL PROTECTED]> writes: > > Would people prefer the C/ASM filename in BUG() messages instead of the > include header? If so I will add it to my todo list for the makefile > rewrite. Of course you can still use __FILE__ and __LINE_ if you > really want to report the error against the include file. I think include file name makes more sense, otherwise you'll have a hard time to find the actual BUG check. If someone wants more they can decode the oops. -Andi - 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/
[PROBLEM] 2.4.1 can't mount ext2 CD-ROM
I have two ext2 CD-ROMs. One of them I can mount the normal way, the other I can't. Both are ok according to debugfs and e2fsck and if I do 'mount -t ext2 -o loop /dev/cdrom /cdrom' instead, both works. The one that doesn't work have a blocksize of 1024 according to debugfs: Block size = 1024, fragment size = 1024 And the other: Block size = 4096, fragment size = 4096 What happens: # mount -t ext2 /dev/cdrom /cdrom mount: block device /dev/cdrom is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/cdrom, or too many mounted file systems kern.log: Feb 18 14:54:34 pc1 kernel: VFS: Unsupported blocksize on dev sr(11,0). I'm pretty sure both worked with 2.2.17. Please CC me. --zzed Feb 17 15:01:13 pc1 syslogd 1.3-3#33.1: restart. Feb 17 15:01:14 pc1 kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started. Feb 17 15:01:14 pc1 kernel: Inspecting /boot/System.map-2.4.1 Feb 17 15:01:14 pc1 kernel: Loaded 16115 symbols from /boot/System.map-2.4.1. Feb 17 15:01:14 pc1 kernel: Symbols match kernel version 2.4.1. Feb 17 15:01:14 pc1 kernel: No module symbols loaded. Feb 17 15:01:14 pc1 kernel: Linux version 2.4.1 (zzed@pc1) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 ons feb 14 12:35:41 CET 2001 Feb 17 15:01:14 pc1 kernel: BIOS-provided physical RAM map: Feb 17 15:01:14 pc1 kernel: BIOS-e820: 000a @ (usable) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ 000f (reserved) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 07deb000 @ 0010 (usable) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 4000 @ 07eeb000 (ACPI data) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ 07eef000 (reserved) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 1000 @ 07eff000 (ACPI NVS) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ (reserved) Feb 17 15:01:14 pc1 kernel: On node 0 totalpages: 32491 Feb 17 15:01:14 pc1 kernel: zone(0): 4096 pages. Feb 17 15:01:14 pc1 kernel: zone(1): 28395 pages. Feb 17 15:01:14 pc1 kernel: zone(2): 0 pages. Feb 17 15:01:14 pc1 kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=302 BOOT_FILE=/boot/vmlinuz hda=13410,15,63 hdc=scsi bttv.radio=1 hisax=36,2 Feb 17 15:01:14 pc1 kernel: ide_setup: hda=13410,15,63 Feb 17 15:01:14 pc1 kernel: ide_setup: hdc=scsi Feb 17 15:01:14 pc1 kernel: Initializing CPU#0 Feb 17 15:01:14 pc1 kernel: Detected 668.194 MHz processor. Feb 17 15:01:14 pc1 kernel: Console: colour VGA+ 80x25 Feb 17 15:01:14 pc1 kernel: Calibrating delay loop... 1333.65 BogoMIPS Feb 17 15:01:14 pc1 kernel: Memory: 125032k/129964k available (1364k kernel code, 4548k reserved, 604k data, 180k init, 0k highmem) Feb 17 15:01:14 pc1 kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Feb 17 15:01:14 pc1 kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Feb 17 15:01:14 pc1 kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Feb 17 15:01:14 pc1 kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Feb 17 15:01:14 pc1 kernel: CPU: Before vendor init, caps: 0383f9ff , vendor = 0 Feb 17 15:01:14 pc1 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Feb 17 15:01:14 pc1 kernel: CPU: L2 cache: 128K Feb 17 15:01:14 pc1 kernel: Intel machine check architecture supported. Feb 17 15:01:14 pc1 kernel: Intel machine check reporting enabled on CPU#0. Feb 17 15:01:14 pc1 kernel: CPU: After vendor init, caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: After generic, caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: Common caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: Intel Celeron (Coppermine) stepping 03 Feb 17 15:01:14 pc1 kernel: Enabling fast FPU save and restore... done. Feb 17 15:01:14 pc1 kernel: Enabling unmasked SIMD FPU exception support... done. Feb 17 15:01:14 pc1 kernel: Checking 'hlt' instruction... OK. Feb 17 15:01:14 pc1 kernel: POSIX conformance testing by UNIFIX Feb 17 15:01:14 pc1 kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Feb 17 15:01:14 pc1 kernel: mtrr: detected mtrr type: Intel Feb 17 15:01:14 pc1 kernel: PCI: PCI BIOS revision 2.10 entry at 0xf0960, last bus=1 Feb 17 15:01:14 pc1 kernel: PCI: Using configuration type 1 Feb 17 15:01:14 pc1 kernel: PCI: Probing PCI hardware Feb 17 15:01:14 pc1 kernel: PCI: Discovered primary peer bus fe [IRQ] Feb 17 15:01:14 pc1 kernel: PCI: Using IRQ router PIIX [8086/2440] at 00:1f.0 Feb 17 15:01:14 pc1 kernel: Linux NET4.0 for Linux 2.4 Feb 17 15:01:14 pc1 kernel: Based upon Swansea University Computer Society NET3.039 Feb 17 15:01:14 pc1 kernel: DMI 2.3 present. Feb 17 15:01:14 pc1 kernel: 45 structures occupying 1293 bytes. Feb 17 15:01:14 pc1 kernel: DMI table at 0x000F24C0. Feb 17 15:01:14 pc1 kernel: BIOS Vendor: Award Software, Inc. Feb 17 15:01:14 pc1 k
[patch] smbfs does not support LFS (2.4.1-ac18)
Hello Unless I misunderstand s_maxbytes it says how large a file can be on the fs. I assume it is enough for a fs to set that and then it knows the vfs will not ask it to go beyond that limit? Is it ok to at mount time set it to non-LFS and then later change it to be something larger? smbfs doesn't actually know what the server and smbmount negotiates until later, but no smbfs operation can take place before that anyway. For smbfs the limit is currently 2G, it does unsigned -> signed internally and it lacks support from smbmount. The later makes the server (tested vs NT4sp6) return errors beyond 2G. Quick patch below to keep it within limits. For people needing LFS in smbfs I have a *very* experimental pair of patches here: http://www.hojdpunkten.ac.se/054/samba/index.html (It worked last night, it may still work today. You need to patch both the kernel and samba ./configure) /Urban diff -ur -X exclude linux-2.4.1-ac18-orig/fs/smbfs/inode.c linux-2.4.1-ac18-smbfs/fs/smbfs/inode.c --- linux-2.4.1-ac18-orig/fs/smbfs/inode.c Sun Feb 18 01:20:31 2001 +++ linux-2.4.1-ac18-smbfs/fs/smbfs/inode.c Sun Feb 18 14:06:15 2001 @@ -399,7 +399,7 @@ sb->s_magic = SMB_SUPER_MAGIC; sb->s_flags = 0; sb->s_op = &smb_sops; - sb->s_maxbytes = ~0;/* Server limited not client */ + sb->s_maxbytes = MAX_NON_LFS; /* client support missing */ sb->u.smbfs_sb.mnt = NULL; sb->u.smbfs_sb.sock_file = NULL; - 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: [LONG RANT] Re: Linux stifles innovation...
Henning P. Schmiedehausen writes: > The matter with me is: "Vendors AAA ships its hardware product with a > driver for i386/Linux". The driver may be closed source, but at least > there _is_ a driver. Russell now says: "This is bad, because I can't use > the driver for my ARM box. So the vendor should ship no driver at > all. This is better than a i386-only driver". I thank you again to NOT put words in my mouth that I didn't say. > If the hardware is "NOT SUPPORTED BESIDES LINUX/i386" and you have an > ARM, the solution is simple: DON'T BUY IT. VOTE WITH YOUR MONEY. If > Linux/ARM starts becoming a sigificant part of the market share, > vendor AAA will either lose to vendor BBB or release a driver for ARM. When there is no vendor BBB to supply such a driver? This is my point. > And Russell can buy a vendor supported driver for Linux/ARM. Not possible. There are none at the present time, and have been none over the past 8 years for ARM Linux. Only recently, because of the hard work put into ARM Linux by the ARM community as a whole have the ARM vendors started to take Linux seriously. There are now around 50 or so different ARM machines that can run Linux, but most of them are not of a PC form factor. All of them are committed to open source. None of them write printer drivers. In fact, for a vast majority of them a printer driver would not make sense. > And I actively _DON'T_ want _YOU_ to decide what _I_ want. I don't want to tell you want you want either. Neither do I want you putting words into my mouth that I did not say. IMHO if you carry on in this light, and you have been shouted down for doing so, I am in full support of those who shouted you down, whether they be in the open source, closed source or whatever arena you care to think of. As a mark of good nature, I will dismiss all of your mistakes thus far. However, if you carry on mis-representing and mis-quoting me in this way, then I shall have to demand a full public appology, and demand that you decist in doing so. > I WANT THE CHOICE. If I have no choice, I buy the product on another > platform. That is your right. No one is taking that away from you. However, I want the choice to develop what I want, how I want, and allow other people to contribute to this development. If you would like to carry this discussion on in private, then I'm quite willing to accept. However, it is off-topic for the Linux-Kernel mailing list. If you wish to keep this public, then as before, please don't reply directly to me or CC: me. Thanks. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: 2.4.1 crashing every other day
> Looks like you were bitten by either the RAID 1 bugs or the elevator bugs. > Try a 2.4.2-pre4 or an 2.4.1-ac18 kernel. Should solve it. Just installed 2.4.2pre4, seems to be stable for now (testing it ATM, running dnetc, several kernel compiles etc.). On 2.4.1 even su segfault'd if the server were loaded. But, the problems have never appeared before after one or two days uptime, so we'll just have to see what happens later on. As the BIOS settings are the same on both servers, and the CPU temperature peaked at +43.5C on the crashing server, I might just think it's a software bug. Well, time will tell :-) Thanks for the input -- Regards, Andre Tomt - 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.1-ac7
On Tue, 13 Feb 2001, Rik van Riel wrote: > On Tue, 13 Feb 2001, Mike Galbraith wrote: > > On Mon, 12 Feb 2001, Marcelo Tosatti wrote: > > > > > Could you please try the attached patch on top of latest Rik's patch? > > > > Sure thing.. (few minutes later) no change. > > That's because your problem requires a change to the > balancing between swap_out() and refill_inactive_scan() > in refill_inactive()... > > The big problem here is that no matter which magic > proportion between the two functions we use, it'll always > be wrong for a large proportion of the people out there. > > This means we need to have a good way to auto-tune this > thing. I'm thinking of letting swap_out() start out way > less active than refill_inactive_scan() with extra calls > to swapout being made from refill_inactive_scan when we > think it's needed... > > (... I'm writing a patch right now ...) We're using nr_async_pages to calculate the number of pages which should be flushed, but nr_async_pages counts on flight swap _readaheads_ (each swapin increases nr_async_pages by (1 << page_cluster)) and writes, not only writes. That makes the "pageout free shortage and sleep" kswapd behaviour you wanted a bit messy. - 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/
Error reading last audio track under ide-scsi emulation.
My system has a IDE ATAPI CD-RW (Matshita CW 7586) and has a serious problem reading the last audio track of an audio CD. Reading the rest of the tracks is Ok, but when trying to rip the last one I get the following error: [With cdda2wav, versions 1.9 and 1.10a13] CDB: 47 00 00 3D 0D 3C 3D 0D 3D 00 Sense Bytes: F0 00 03 00 04 34 4F 0A 00 00 00 00 02 00 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x02 Qual 0x00 (no seek complete) Fru 0x0 Sense flags: Blk 275535 (valid) cmd finished after 0.418s timeout 300s recording 135.07599 seconds stereo with 16 bits @ 44100.0 Hz ->'track-19'... cdda2wav: Input/output error. ReadCD MMC 12: scsi sendcmd: retryable error CDB: BE 04 00 04 0E 44 00 00 4B 10 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 03 00 04 0E 8B 0A 00 00 00 00 02 00 00 00 Sense Key: 0x3 Medium Error, Segment 0 Sense Code: 0x02 Qual 0x00 (no seek complete) Fru 0x0 Sense flags: Blk 265867 (valid) cmd finished after 0.379s timeout 300s ... and it keeps on like that. [With cdparanoia III rel. 9.7] Ripping from sector 265204 (track 19 [0:00.00]) to sector 275385 (track 19 [2:15.56]) outputting to cdda.wav scsi_read error: sector=265204 length=3 retry=0 Sense key: 3 ASC: 2 ASCQ: 0 Transport error: Medium reading data from medium System error: Input/output error scsi_read error: sector=265207 length=13 retry=0 Sense key: 3 ASC: 2 ASCQ: 0 Transport error: Medium reading data from medium System error: Input/output error scsi_read error: sector=265207 length=6 retry=1 Sense key: 3 ASC: 2 ASCQ: 0 Transport error: Medium reading data from medium System error: Input/output error ... and so on. Both kernel versions 2.4.1 and 2.2.18 have this problem and, of course, (I think) this is not a hardware problem since ripping only with IDE CDROM support is perfect and clean. My /proc/scsi/scsi says: Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: MATSHITA Model: CD-RW CW-7586 Rev: 1.01 Type: CD-ROM ANSI SCSI revision: 02 Thanks in advance, Manuel Cepedello Boiso E-mail: [EMAIL PROTECTED] P.D. BTW, I've got full of 'kernel: VFS: Disk change detected on device sr(11,0)' on my syslog. Is it normal? - 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/
