Re: Linux stifles innovation...
On Fri, 16 Feb 2001, Matt D. Robinson wrote: >The day the Linux kernel splinters into multiple, distinct efforts is the >day I'll believe the kernel is fully into progress over "preference". Right >now, Alan accepts what he thinks should go into stable kernels, and Linus >accepts what he thinks should go into future kernels. I'm not saying they >aren't doing the right things, or that the system doesn't work, but it's >hardly what I would call a progressive movement. It's simply long, >drawn-out evolution at best. > >I'm surprised the major vendors haven't created their own consortium >by now to create a Linux kernel they think is best suited for their own >hardware. But then again, they probably still spend all their time worrying >about whether their efforts will be "accepted" into the mainstream Linux >kernel. Now _that's_ what I consider to be stifling innovation and >progression. > >Kind of off-topic, but whatever ... Basically it boils down to this.. By continuing this thread here, I'm preaching to the choir, and I'd rather not waste my time on those with no clue of the open source movement. The other alterative is to stick up for open source, and debate you until I'm blue in the face - and you wont change your mind anyways, and considering you're the minority here.. who cares? Thread == dead. -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- Red Hat Linux: http://www.redhat.com Download for free: ftp://ftp.redhat.com/pub/redhat/redhat-6.2/ - 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 Fri, 16 Feb 2001, Dennis wrote: > objective, arent we? Pot. Kettle. Black. > There is much truth to the concept, although Microsoft should not be ones > to comment on it as such. What truth? I have seen more "innovation" in the Open Source movement than I ever have in my 18+ years of being a professional programmer. I don't see how having the source open removes "intelectual property", except by showing that huge portions of the concept are flawed. > 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 > with different "features" that were of value to you. Instead, you have > crappy GPL code that locks up under load, and its not worth spending > corporate dollars to fix it because you have to give away your work for > free under GPL. And since there is a "free" driver that most people can > use, its not worth building a better mousetrap either because the market is > too small. So, the handful of users with problems get to "fit it > themselves", most of whom cant of course. Strange. I have not heard of any problems with that driver, except for issues where the original hardware vendor kept implimentation details from the open source community. (Citeing "IP issues".) > Theres also the propensity for mediocre stuff to get into the kernel > because some half-baked programmer was willing to contribute some code. The > 50% of the kernel that remains "experimental" ad infinitum is evidence of that. You must be looking at a different kernel. I have seen little in the kernel that was "half baked". There have been some things put in to test if they were good ideas. That is far different than half-baked. Most of the bad ideas never get to the kernel. Linus or Alan kick them out before they ever get that far. > The biggest thing that the linux community does to stifle innovation is to > bash commercial vendors trying to make a profit by whining endlessly about > "sourceless" distributions and recommending "open-source" solutions even > when they are wholly inferior. You're only hurting yourselves in the long > run. In that respect MS is correct, because those with the dollars to > innovate will stay away. You claim that "open source solutions are wholely inferior to closed source solutions". H... Then why does everyone run with Apache instead of IIS? Could it be that IIS is a piece of crap? Feature for feature I would rather use PHP 4 over ColdFusion any day. Sendmail is MUCH more stable than Exchange. (Even if it has config files that look like they were designed by Carlos Castanada on a bad day.) If not Sendmail, there are a couple of other Open Source mail programs that are much superior in quality than the closed source counterparts. As for the Linux kernel being "shoddy"... Since when? I can leave my Linux box running over night and actually have it do things! I cannot say the same for Windows. I leave that running (same hardware, different OS) and it is usually dead by dawn. But your argument is even more bogus than that. It seems that you argument boils down to a couple of thing... "Closed source is better because you pay money for it." "Closed source is superior because we have a company name and you don't." Sorry, but most of the people who develop Open Source are profesional programmers. They just have a different motivation. Open Source is motivated by pride in what you can do and a desire to help others by sharing that. They don't hide behind a wall of lawyers to keep people from finding out what they did wrong. I found out a long time ago that most "Trade Secret" claims were bogus. It was either a common technique that had been adapted to a particular purpose or it was being used as an excuse to hide how bad the code really was. But my experiences with Open Source, as well as the others I know who use it are quite telling. If I have a problem with an Open Source program I can look at the code and fix it. Or I can report the bug and it will get fixed soon after. The programmers involved put the effort into it because their name is attached. My experiences with closed source companies are not as good. In many cases, I was ignored because I did not represent a fortune 500 company. If the problem got fixed at all, it would be months before I saw it and usually in a later release that I would have to pay for. (Usually having features added that I neither wanted or would ever use.) In some cases (like Microsoft security bugs) it would be treated like a public relations problem instead of a software and quality issue. I have also seen cases where problems were buried in development because "no one will find out and if they do, we will just blame Microsoft". I understand your desire to make money off what you do for a living. I do object to you taring what I do as somehow damaging to the software industry as a whole. (Especially since
Re: Linux stifles innovation...
I did some research on the patent database and found nothing regarding such a patent. There's patent on word processors (not the concept but related to) and uses tab on the description...and that patent is from 1980. - Original Message - From: "James Sutherland" <[EMAIL PROTECTED]> To: "David D.W. Downey" <[EMAIL PROTECTED]> Cc: "Rik van Riel" <[EMAIL PROTECTED]>; "Alan Olsen" <[EMAIL PROTECTED]>; "Mark Haney" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 16, 2001 15:18 Subject: RE: Linux stifles innovation... > On Fri, 16 Feb 2001, David D.W. Downey wrote: > > > Would someone tell me where you get all this lovely information on > > patents held by M$? I can't find anything. > > Sorry, it's *IBM* who are said to hold a patent on the tab key. > > Legend has it Microsoft once found a patent of theirs which IBM appeared > to have infringed, and were very excited at the possibility of something > to hold over IBM, so their lawyers met IBM's lawyers. The MS lawyers > beamed "look at our patent you've infringed!" IBM's lawyers replied "look > at this pile of our patents YOU'VE infringed... let's start with this > one. A Tab key." MS suddenly realised they were outlawyered... > > No idea how accurate it is, but just the thought of MS's lawyers getting a > nasty shock like that has a certain appeal :-) > > > James. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 TCP(?) timeouts
Hello, Today we put 2.4.1 on our mail server after having see it perform well on some other boxes. It seems now we are receiving a few calls every hour from customers reporting that the server tends to hang and eventually time out on them when downloading mail. All customers that have reported this problem so far are on a didalup connection. Apparently the server will stop transmitting data (or the client seems to think so), and then their mail client will time out. I noticed that the 2.4.1 on my desktop seems to time out SSH connections to servers that have become unreachable in about 10 seconds or so, which is many times faster than 2.2 which used to sit for hours before it timed out (if it all). I'm not sure if this is related. I would expect the client to attempt to retransmit some ACKs and eventually get some RSTs back if this were the case. Has anybody seen similar problems? The box was previously running 2.2.19pre8 and no customers reported such problems. We're using cucipop w/ldap on a dual PIII 800 MHz box with 1.5 GB of RAM. Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - 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...
Dennis wrote: ... > 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. > The biggest thing that the linux community does to stifle innovation is to > bash commercial vendors trying to make a profit by whining endlessly about > "sourceless" distributions and recommending "open-source" solutions even > when they are wholly inferior. You're only hurting yourselves in the long > run. In that respect MS is correct, because those with the dollars to > innovate will stay away. When companys with less than a dozen people think it's worth while paying someone like me to develop code exclusivly for Linux we've got to have a chance. Source to binary ratio is probably 70/30 mainly because of code tied up in previous companys but they are trying. The project they're funding now is more like 90% GPL. Of course I could be producing crap code. 20 years kernel hacking and a cybernetics degree can't mean as much as being an MSCE. ps. This is definately a message from home and a bottom of a glass of whisky. -- Bob Dunlop [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: Linux stifles innovation...
"Mike A. Harris" wrote: > On Fri, 16 Feb 2001, Matt D. Robinson wrote: > > >The day the Linux kernel splinters into multiple, distinct efforts is the > >day I'll believe the kernel is fully into progress over "preference". Right > >now, Alan accepts what he thinks should go into stable kernels, and Linus > >accepts what he thinks should go into future kernels. I'm not saying they > >aren't doing the right things, or that the system doesn't work, but it's > >hardly what I would call a progressive movement. It's simply long, > >drawn-out evolution at best. > > > >I'm surprised the major vendors haven't created their own consortium > >by now to create a Linux kernel they think is best suited for their own > >hardware. But then again, they probably still spend all their time worrying > >about whether their efforts will be "accepted" into the mainstream Linux > >kernel. Now _that's_ what I consider to be stifling innovation and > >progression. > > > >Kind of off-topic, but whatever ... > > Basically it boils down to this.. By continuing this thread here, > I'm preaching to the choir, and I'd rather not waste my time on > those with no clue of the open source movement. The other > alterative is to stick up for open source, and debate you until > I'm blue in the face - and you wont change your mind anyways, > and considering you're the minority here.. who cares? > > Thread == dead. Mike, next time, read someone's post before responding, okay? If you think I don't care about open source, perhaps you weren't paying enough attention. I'd like to see open source evolve even faster than it does now. If you somehow missed that, then go back and read what I wrote again. And I'm sure you can find much more positive ways to defend open source than responding in the way you just did -- your tone projects the kind of animosity that causes these closed vs. open source debates in the first place. My feeling is we should splinter the kernel development for different purposes (enterprise, UP, security, etc.). I'm sure it isn't a popular view, but I feel it would allow faster progression of kernel functionality and features in the long run. And that's simply a different view than you have. It's certainly not one that is against the open source movement (as you've implied). --Matt (http://oss.sgi.com/projects/lkcd) - 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/
Multiport NICs and ether channel?
Greetings, Just a general question or two.. Please point me to a URL or tell me where to RTFM, or answer back ;-). What is the status/condition of using muliport NICs and bonding them together to form a larger pipe (i.e. a quad channel ethernet card for an Intel box, bonding all four interfaces together to get a theoretical 400Mbps pipe)? Are there any highly recommended cards of this type? Will the bonding work when connected to a Cisco catalyst switch with ether channel? Again, thanks in advance. If you need any further info, or if I need to describe something in greater detail please let me know. Cheers, Will Sarka -- - Those, who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. -Ben Franklin Historical Review of Constitution and Government of Pennsylvania - - 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: CONFIG_MODVERSIONS and same named files
On Fri, 16 Feb 2001 08:19:28 -0700, Tom Rini <[EMAIL PROTECTED]> wrote: >Hey all. The modversions code has a slight problem with files of the same >name, but in different directories. eg: drivers/a/foo.c exports FOO, and >drivers/b/foo.c exports BAR, include/linux/modules/foo.ver will only have the >information about drivers/b/foo.c. Anyone got an idea on how to fix this? Files that export symbols must have unique names. Which is why we have abominations like this. fs/msdos/msdosfs_syms.c fs/proc/procfs_syms.c fs/fat/fatfs_syms.c fs/vfat/vfatfs_syms.c fs/lockd/lockd_syms.c kernel/ksyms.c net/netsyms.c net/sunrpc/sunrpc_syms.c net/irda/irsyms.c Module symbol versions is being completely redesigned for 2.5 and will not have this problem. In the meantime create a unique filename for anything that exports symbols. - 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-ac14 won't boot
>
> 2.4.1-ac8 worked great, 2.4.1-ac13 and ac14 oops
> in IDE initialisation. All 3 have ide.2.4.1-p8.all.01172001.patch
> applied too. I'll try it without the ide patch today.
>
>
> -Thomas
>
> ---kernel messages---
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> AMD7409: IDE controller on PCI bus 00 dev 39
>: chipset revision 3
>: not 100% native mode: will probe irqs later
> AMD7409: disabling single-word DMA support (revision < C4)
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
> hda: IBM-DTTA-351010, ATA DISK drive
> hdb: IBM-DTTA-351010, ATA DISK drive
> hdc: WDC AC24300L, ATA DISK drive
> hdd: ATAPI CDROM, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: status error: status=0x50 { DriveReady SeekComplete }
> hda: no DRQ after issuing WRITE
> hda:19807200 sectors (10141 MB) w/466KiB Cache, CHS=19650/16/63,
> UDMA(33)
> hda:ide_intr: hwgroup->busy was 0 ??
> Inable to handle kernel NULL pointer dereference at virtual address
> 0040
> printing eip:
> c0192e86
> *pde =
> Oops:
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010046
> eax: ebx: c02cf820 ecx: c1461098 edx: 01f7
> esi: c02cf820 edi: 0282 ebp: c02cf7e0 esp: c145fe28
> ds: 0018 es: 0018 ss: 0018
> Process swaper (pid:1, stackpage=c145f000)
> stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
> 000e
>c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
> c029fc80
>c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
> c029fc80
> Call Trace: [] [] [] []
> [] [] []
>[] [] [] [] []
> [] [] []
>[] []
>
> Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6
> Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing
> spurious 8259A interrupt: IRQ7.
I have had a similar oops on my MSI-694D, but not always. I think that mine
happens in the Promise FastTrack Lite driver (pdc...). But since I have a
dual processor, the oops is interlaced with the other processor's boot
messages. About the only thing that I can get from it is the following.
(painstakingly copied by hand. I know, not run through ksymoops...)
E Flags 00010246
esp: c123ffb0
Call Trace: [][][]
I think that the change that caused mine is changing the Promise
driver to do a mdelay where it was doing that odd stuff.
But it boots more often than not, so I have ignored it.
Laramie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.1ac17
Seems everyone has been busy innovating again, so here is ac17. This merges 2.4.2pre4 which includes more elevator changes so please treat ac17 with caution. ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.1-ac17 o Fix pegasus for bigendian (Roman Weissgaerber) o Further smbfs fixes (Urban Widmark) o Update ISDN version tags(Kai Germaschewski) o Finish ISDN move to new style module_init (Kai Germaschewski) o Small Eicon driver updates/fix license bug (Armin Schindler) o Fix reiserfs tail packing problem (Alexander Zarochentcev Chris Mason) o Export aci symbols from drivers/sound/aci.c (Alexandr Kanevskiy) o Merge Linus 2.4.2pre4 o Starfire update (Ionu Badulescu) o Fix 3270 merge (Richard Hitt) 2.4.1-ac16 o Fix the exception table/unload race (me) o Further tulip fixup (Manfred Spraul) o Fix USB oops on traverse/delete race(Randy Dunlap) o Set max_sectors to 255 for hd/xd drivers(Paul Gortmaker) | This should make them work again o Fix typo in USB makefile(Arjan van de Ven) o Fix accidental change to scsi_scan (Steve Ralston) o Hid rollover/endian fixes (Paul Mackerras) o Drop via pci fixup (me) o Further hp5300 fixups (Arjan van de Ven) o PCnet 32 init changes for non SEPROM cards (Eli Carter) o Fix acpi idle reporting on SMP (Philipp Hahn) o Add non PCI pci device list walk macro (me) | pointed out by Mikael Pettersson o IBM S/390 3270 drivers (Richard Hitt) 2.4.1-ac15 o Fix the non booting winchip/cyrix problem (me) | Nasty interaction with the vmalloc fix | wants a cleaner solution. This one is a hack | to get people up and running again o Fix typo in vfat changes(OGAWA Hirofumi) o Update scsi blacklist table (Karsten Hopp) o dscc4 wan driver update (Francois Romieu) o Fix clgenfb warning (Bryan Headley) 2.4.1-ac14 o Fix tulip problems introduced by in ac13(Manfred Spraul) o S/390x build fixes (Ulrich Weigand) o Fix off by one error in octagon driver (David Woodhouse) o Fix dasd driver for new queues (Holger Smolinksi) o Networking standards compliance fixes o Fix binary layout assumptions in sym53c416 (Arjan van de Ven) o tmpfs timestamps(Christoph Rohland) o Further mkdep changes (Keith Owens) o Fix 16bit vfat handling (OGAWA Hirofumi) o JIS nls fixes (OGAWA Hirofumi) o Handle more than 8 luns (Eric Youngdale, Doug Gilbert) o Minor scsi clean ups(Eric Youngdale) 2.4.1-ac13 o Fix pnic tulip problems (Manfred Spraul) o Fix USB printer read and poll problems (Johannes Erdfelt) o Fix parport pci list corrupt bug(Tim Waugh) o Fix sbpcd driver crashes(Paul Gortmaker) o Clarify the locking doc (Rusty Russell) o i810 audio doesnt need OSS (Jeff Garzik) o Fix vmalloc fault race (Mark Hemment) o Makedep fixes (Keith Owens) o Fix missing unlock_kernel on usb hub(Paul Mundt) o Fix smbfs+bigmem, buffer and listing bugs (Urban Widmark) o Merge tms380 isa token ring support (Jochen Friedrich) o Sigmatel change didnt help, removed (Jeff Garzik) 2.4.1-ac12 o Make tmpfs use link counts of 2 on directories (Christoph Rohland) o Update Documentation/sound/Introductions(Wade Hampton) o Fix bug in new tlb shootdown code (Ben LaHaise) o Add isa_* api to the Alpha (Richard Henderson) o Export down_trylock on Alpha(Richard Henderson) o Fix maestro3 build on ia64 (Bill Nottingham) 2.4.1-ac11 o Hack the setup code to do the right thing for (me) Cyrix processors. Cpuid on cyrix should now work o Change sigmatel codec inits (Jeff
Re: Multiport NICs and ether channel?
On Sat, 17 Feb 2001, Willis L. Sarka wrote: > Greetings, > > Just a general question or two.. Please point me to a URL or tell me where > to RTFM, or answer back ;-). > > What is the status/condition of using muliport NICs and bonding > them together to form a larger pipe (i.e. a quad channel ethernet card for > an Intel box, bonding all four interfaces together to get a theoretical > 400Mbps pipe)? Are there any highly recommended cards of this type? Will > the bonding work when connected to a Cisco catalyst switch with ether > channel? Linux bonding is compat with Sun EtherTrunking and Cisco EtherChannel/FastEtherChannel. On the Cisco side you follow their setup examples, *except* you *must* trun keepalives off on the cisco. These are a Cisco extension. If you fail to do this the Cisco will toggle the onterfaces *off* every 10 - 30 seconds. --- The roaches seem to have survived, but they are not routing packets correctly. --About the Internet and nuclear war. - 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...
Matt D. Robinson wrote: > My feeling is we should splinter the kernel development for > different purposes (enterprise, UP, security, etc.). I'm sure > it isn't a popular view, but I feel it would allow faster progression > of kernel functionality and features in the long run. "enterprise" XOR security ? I think you understand the problem with your approach well ;-) Linux scales well from PDAs to large clusters. This is quite an achievement. Other operating systems are not able to match this. So why do you think that Linux should try to mimic their flaws ? Out of pity ? BTW, parallel development does happen all the time. The point of convergence in a single "mainstream" kernel is that you benefit from all the work that's been going on while you did the stuff you care most about. - Werner (having pity with the hungry looking trolls) -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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: "make dep" problem
On Fri, 16 Feb 2001 17:44:27 +0100 (CET), Andrzej Krzysztofowicz <[EMAIL PROTECTED]> wrote: > While trying to compile 2.4.1-ac1[34] I noticed that the following error >message appears sometimes: > >make[3]: *** No rule to make target >/home29/ankry/kernel/2.4/linux/drivers/pci/devlist.h', needed by `names.o'. The mkdep patch in -ac12 was incorrect, fixed in -ac14. You probably need to do make mrproper to get rid of the incorrect file generated by -ac12. - 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 Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote: > I did some research on the patent database and found nothing regarding such > a patent. There's patent on word processors (not the concept but related to) > and uses tab on the description...and that patent is from 1980. You know XOR is patented (yes, the logical bit operation XOR). -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 stifles innovation...
On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote: > On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote: > > I did some research on the patent database and found nothing regarding such > > a patent. There's patent on word processors (not the concept but related to) > > and uses tab on the description...and that patent is from 1980. > You know XOR is patented (yes, the logical bit operation XOR). But wasn't that Xerox that had that? Yeah, the same ones that screwed us over with the compression patent that shot .gif images out of the sky. There was inovation for you. > -Dan 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: Linux stifles innovation...
Werner Almesberger wrote: > > Matt D. Robinson wrote: > > My feeling is we should splinter the kernel development for > > different purposes (enterprise, UP, security, etc.). I'm sure > > it isn't a popular view, but I feel it would allow faster progression > > of kernel functionality and features in the long run. > > "enterprise" XOR security ? I think you understand the problem with > your approach well ;-) Actually I do. Perhaps I should define enterprise as "big iron". In that way, enterprise kernels would be far more innovative than a secure kernel (which cares less about performance gains and large features and more about just being "secure"). Unless you meant something else and I'm misinterpreting what you've stated. :) > Linux scales well from PDAs to large clusters. This is quite an > achievement. Other operating systems are not able to match this. > So why do you think that Linux should try to mimic their flaws ? > Out of pity ? I always considered SGI's kernels, from the low-end system up to the large server configurations, to scale well. Certainly it didn't work on PDAs. :) If you consider it a flaw for vendors to be able to create their own Linux kernels based on optimizations for their hardware and their customers, then that's a horrible perspective on overall open source progression. In fact, I think if some of these vendors created their own kernel trees, it would inevitably lead to inclusion of the best features into the primary kernel tree. Where's the harm in that? > BTW, parallel development does happen all the time. The point of > convergence in a single "mainstream" kernel is that you benefit > from all the work that's been going on while you did the stuff > you care most about. Agreed. It's great to have a "primary" kernel. I'd like to see more splintered kernels (not smaller project efforts), that's all. And I don't think that convergence happens quickly or efficiently enough, despite all the great work Linus and Alan do. > - Werner (having pity with the hungry looking trolls) --Matt - 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 2.4.0/1/1-ac15 and ncr53c810a
Hello, I have problems using my scanner (HP C6270A connected to ncr53c810a) with xsane. I always get the error message: error during read: Error during device I/O Feb 15 23:57:27 localhost kernel: Attached scsi generic sg2 at scsi0, channel 0, id 4, lun 0, type 3 Feb 15 23:57:27 localhost kernel: ncr53c810a-0-<4,*>: target did not report SYNC. Feb 15 23:58:01 localhost kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 4, lun 0 Read (6) 00 00 7b 66 00 Feb 15 23:58:01 localhost kernel: ncr53c8xx_abort: pid=0 serial_number=1099 serial_number_at_timeout=1099 Feb 15 23:58:04 localhost kernel: SCSI host 0 abort (pid 0) timed out - resetting Feb 15 23:58:04 localhost kernel: SCSI bus is being reset for host 0 channel 0. Feb 15 23:58:04 localhost kernel: ncr53c8xx_reset: pid=0 reset_flags=2 serial_number=1099 serial_number_at_timeout=1099 Feb 15 23:58:04 localhost kernel: ncr53c810a-0: restart (scsi reset). With kernel 2.2.x I have no problems accessing the scanner with xsane. Any idea? - 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/
IBM-DTLA-307045 very slow under 2.2.x
I have a SOYO "SY-5EMA+ Super 7" motherboard, with a K6-2 processor.
The 45 Gig IBM drive hangs the BIOS if I let it autodetect it, so I
turn off autodetection for IDE2 primary where it sits. This is probably
not relevant.
My problem is that "hdparm -tT dev/hdc" gives atrocious
performance:-
/dev/hdc:
Timing buffered disk reads: 64 MB in 22.81 seconds = 2.81 MB/sec
with approximately 25% CPU usage. By contrast, for /dev/hda it
gives:-
/dev/hda:
Timing buffered disk reads: 64 MB in 11.49 seconds = 5.57 MB/sec
with 100% CPU, which is still poor, but somewhat better. The relevant
part of my dmesg is
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALL CR13.0A, ATA DISK drive
hdb: CD-ROM 40X/AKU, ATAPI CDROM drive
hdc: IBM-DTLA-307045, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: QUANTUM FIREBALL CR13.0A, 12416MB w/418kB Cache, CHS=1582/255/63
hdc: IBM-DTLA-307045, 43979MB w/1916kB Cache, CHS=5606/255/63
hdb: ATAPI 40X CD-ROM drive, 128kB Cache
hdparm -i /dev/hdc gives:-
Model=IBM-DTLA-307045, FwRev=TX6OA50C, SerialNo=YM0YML23878
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=90069840
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2 udma0 udma1 udma2 udma3 udma4 udma5
Trying to set the DMA mode with -X34 and -d1 seems to have no effect.
Is this normal, or am I doing something wrong?
Thanks,
Neil.
-
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...
"David D.W. Downey" wrote: > > Seriously though folks, look at who's doing this! > > They've already tried once to sue 'Linux', were told they couldn't because > Linux is a non-entity (or at least one that they can not effectively sue > due to the classification Linux holds), ... --- Not having a long memory on these things, do you have an article or reference on this -- I'd love to read about that one. Sue Linux? For what? Competing? Perhaps by saying Open Source is a threat to the "American Way", they mean they can't effectively 'sue', buy up or destroy it? -l -- L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.4.0/1/1-ac15 and ncr53c810a
On 02.17 Wolfgang Teichmann wrote: > Hello, > > I have problems using my scanner (HP C6270A connected to ncr53c810a) > with xsane. > > I always get the error message: > > error during read: Error during device I/O > > > Feb 15 23:57:27 localhost kernel: Attached scsi generic sg2 at scsi0, > channel 0, id 4, lun 0, type 3 Try disabling 'Initiate sync negotitation' in the card BIOS for the ID of the scanner. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac14 #1 SMP Thu Feb 15 16:05:52 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
gcc-2.96 and kernel
Hi, (I suppose people track this info, but a remark never hurts...) Just updated Mandrake gcc to gcc-2.96-0.37mdk. Interesting point: * Thu Feb 15 2001 David BAUDENS <[EMAIL PROTECTED]> 2.96-0.37mdk - Fix build on PPC :) * Thu Feb 15 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.96-0.36mdk - Break build on PPC ;). - Red Hat patches, Jakub Jelinek (rel74) 5 new patches : - fix last cpp patch so that no whitespace is inserted at start of line if last macro expansion resulted in no tokens (Neil Booth) - fix ICE during printing warning about overloading decisions (#23584) - honor no implicit extern "C" on linux in cpp - fix layout of __attribute((packed)) enums in bitfields (showing up in Linux DAC960 driver) ^^^ .. The last thing remaining to recommend 2.96 ? Who knows... -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac14 #1 SMP Thu Feb 15 16:05:52 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
too long mac address for --mac-source netfilter option
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. Is there a resolution to this other than a rewrite and recompile of the relevant sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as experimental still so I would assume that the code is open for feedback ;) The question could be rephrased as: is there any chance of allowing "invalid" mac addresses to be recognized by the --mac-source option of the netfilter code? Running Redhat v7/kernel 2.4.1-ac15. Jack Bowling mailto: [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: kernel 2.4.0/1/1-ac15 and ncr53c810a
Hello Wolfgang & J.A. , On Sat, 17 Feb 2001, J . A . Magallon wrote: > On 02.17 Wolfgang Teichmann wrote: > > Hello, > > I have problems using my scanner (HP C6270A connected to ncr53c810a) > > with xsane. > > I always get the error message: > > error during read: Error during device I/O > > Feb 15 23:57:27 localhost kernel: Attached scsi generic sg2 at scsi0, > > channel 0, id 4, lun 0, type 3 > Try disabling 'Initiate sync negotitation' in the card BIOS for the ID of > the scanner. There is no Bios on an 810/810a . There is a way to tell the driver not to 'initiate Sync' & I'd prolly recommend disabling 'disconnect' as well . UNLESSS you have -any- other device on the 810's scsi bus . Please see : linux/drivers/scsi/EADME.ncr53c8xx Hth , JimL ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 Fri, 16 Feb 2001, Michael H. Warfield wrote: > > You know XOR is patented (yes, the logical bit operation XOR). > But wasn't that Xerox that had that? US Patent #4,197,590 held by NuGraphics, Inc. > Yeah, the same ones that screwed us over with the compression patent > that shot .gif images out of the sky. There was inovation for you. That wasn't Xerox. That was Unisys (due to LZW). -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 stifles innovation...
Matt D. Robinson wrote: > Actually I do. Perhaps I should define enterprise as "big iron". In > that way, enterprise kernels would be far more innovative than a > secure kernel (which cares less about performance gains and large > features and more about just being "secure"). Hmm, and if you want a secure "big iron" ? Do you then start another branch merging from both lines, or try to merge all the "enterprise" enhancements into the "secure" system or vice versa ? If the latter is easy, why was the split needed in the first place ? If it isn't easy, will you succeed ? After all, you're facing the integration of a large portion of code, and you only have a probably small "special interest" group of people for it. > In fact, I think > if some of these vendors created their own kernel trees, it would > inevitably lead to inclusion of the best features into the primary > kernel tree. Where's the harm in that? Temporary splits or "private" add-ons are not a problem. In fact, this happens all the time. If there are more fundamental and permanent splits, I would expect it to become increasingly difficult to maintain compatibility for components. This should affect drivers first, then deeper regions of the kernel (e.g. networking, then MM). Actually, there is a live experiment of this nature going on: with BSD, you have several specialized lines. I'm not following their development, but maybe somebody who does could comment on how they compare in terms of compatibility among themselves, and in terms of features/drivers with Linux. Also, code that is supposed to run on multiple platforms easily degenerates into a wild collection of #ifdefs, or requires the addition of further abstraction layers. (*) Again, the quality of BSD drivers (both in readability and efficiency) should be indicative for whether my assumption is true. (* Further abstraction layers can sometimes be very efficient, e.g. the UP/SMP support in Linux. The hard part is to put them at the right place. If your kernels are sufficiently different, you may end up with translation modules at fairly deep layers, e.g. instead of, say, VFS in all kernels providing the same set of functions, you'd translate between VFS variants in your file system driver, which is probably less efficient, and much more likely to result in bugs.) In my personal experience, it's already painful enough to maintain a piece of software that should run in 2.2 and 2.3 kernels, despite rather good compatibility support. > And I don't think that convergence happens quickly or efficiently > enough, despite all the great work Linus and Alan do. One of the largest obstacles to covergence that I've seen so far is that some groups isolate their work too much. Rapid convergence is only possible if all relevant parties understand what's going on, at least at the point of what happens at interfaces. This means that large projects should be done openly, with occasional announcements on linux-kernel. Building that killer subsystem in-house until perfection is reached, and then submitting a multi-megabyte patch isn't going to make anybody happy. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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/
"PCI quirks" in kernel for ppc in 2.2
Does this help for ppc? The help talks about BIOS which I know is only on x86. Does this code include anything that helps a non x86 comp? Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Fri, Feb 16, 2001 at 05:27:31PM -0500, Dennis wrote: > 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 > with different "features" that were of value to you. Instead, you have > crappy GPL code that locks up under load, and its not worth spending 1- GPL code is the opposite of crap 2- in that case, it's not the software, but the hardware which was locking up under load In addition, it would have been impossible to fix the problem if the code was not GPL. -- Augustin Vidovic http://www.vidovic.org/augustin/ "Nous sommes tous quelque chose de naissance, musicien ou assassin, mais il faut apprendre le maniement de la harpe ou du couteau." - 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: too long mac address for --mac-source netfilter option
Hello Jack & All , Might this be an atm interface ? If it is not then am I to assume that an atm interface with its erroneous mac-address is going to have the same difficulties . That is of course as soon as the atm interface actually put a valid ESI/mac-address into the interface table . Tia , JimL On Fri, 16 Feb 2001, 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. >> Is there a resolution to this other than a rewrite and recompile of the >relevant sections of the iptable code? Or am I stuck? I know this option >is tagged by Rusty as experimental still so I would assume that the code >is open for feedback ;) The question could be rephrased as: is there any >chance of allowing "invalid" mac addresses to be recognized by the >--mac-source option of the netfilter code? Running Redhat v7/kernel >2.4.1-ac15. ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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... ]
At 08:52 PM 2/16/01, you wrote: > On Fri, 16 Feb 2001, Michael H. Warfield wrote: > > > You know XOR is patented (yes, the logical bit operation XOR). > >But wasn't that Xerox that had that? > > US Patent #4,197,590 held by NuGraphics, Inc. The patent was for using the technique of using XOR for dragging/moving parts of a graphics image without erasing other parts. Also, since the patent was granted in 1980, the inventors have had their 17 years of patent protection, and we're all free to use the technique - legally! David P.S. Given that XOR is a basic boolean operation, I don't think the USPTO would ever be so dumb as to grant a patent on it. But, then the PTO has shown a creative ability to grant patents to questionable ideas, so who can say what they would/could/will do? - 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... ]
On Fri, 16 Feb 2001, David Relson wrote: > At 08:52 PM 2/16/01, you wrote: > > On Fri, 16 Feb 2001, Michael H. Warfield wrote: > > > > You know XOR is patented (yes, the logical bit operation XOR). > > > But wasn't that Xerox that had that? > > US Patent #4,197,590 held by NuGraphics, Inc. > The patent was for using the technique of using XOR for dragging/moving > parts of a graphics image without erasing other parts. Also, since the > patent was granted in 1980, the inventors have had their 17 years of patent > protection, and we're all free to use the technique - legally! So you approve of 4,197,590 and think it was an innovative and non obvious invention in 1980? -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: 2.4 TCP(?) timeouts
On Fri, Feb 16, 2001 at 07:08:05PM -0500, Simon Kirby wrote: > Hello, > > Today we put 2.4.1 on our mail server after having see it perform well on > some other boxes. It seems now we are receiving a few calls every hour > from customers reporting that the server tends to hang and eventually > time out on them when downloading mail. All customers that have reported > this problem so far are on a didalup connection. Apparently the server > will stop transmitting data (or the client seems to think so), and then > their mail client will time out. We recorded a trace on the mail server end to one of the customers having the problem. At first they closed the connection because their mail client was set to a timeout of 1 minute, but then when they changed it to 5 seconds, it seemed to limp along further. It seems to me just like there's a huge amount of packet loss, but pinging the machine just after this shows 0% loss (just occasional jumps in response time). During this trace, when long periods of nothing went by, "netstat -tan |grep ip" showed nothing abnormal: a 0 byte receive queue and some data in the send queue equal to what would be retransmitted and eventually go through two minutes later. nmap: Remote operating system guess: Windows 2000 Professional, Build 2128 16:26:14.738836 < client.1104 > mail.pop3: S 1263956200:1263956200(0) win 8760 (DF) 16:26:14.73 > mail.pop3 > client.1104: S 26894293:26894293(0) ack 1263956201 win 5840 (DF) 16:26:15.014145 < client.1104 > mail.pop3: . 1:1(0) ack 1 win 9112 (DF) 16:26:15.014866 > mail.pop3 > client.1104: P 1:92(91) ack 1 win 5840 (DF) 16:26:15.291998 < client.1104 > mail.pop3: P 1:16(15) ack 92 win 9021 (DF) 16:26:15.292199 > mail.pop3 > client.1104: . 92:92(0) ack 16 win 5840 (DF) 16:26:15.292305 > mail.pop3 > client.1104: P 92:115(23) ack 16 win 5840 (DF) 16:26:16.686295 > mail.pop3 > client.1104: P 92:115(23) ack 16 win 5840 (DF) 16:26:16.954563 < client.1104 > mail.pop3: P 16:30(14) ack 115 win 8998 (DF) 16:26:16.976908 > mail.pop3 > client.1104: P 115:137(22) ack 30 win 5840 (DF) 16:26:19.776322 > mail.pop3 > client.1104: P 115:137(22) ack 30 win 5840 (DF) 16:26:20.033951 < client.1104 > mail.pop3: P 30:36(6) ack 137 win 8976 (DF) 16:26:20.034063 > mail.pop3 > client.1104: P 137:149(12) ack 36 win 5840 (DF) 16:26:25.626301 > mail.pop3 > client.1104: P 137:149(12) ack 36 win 5840 (DF) 16:26:25.922151 < client.1104 > mail.pop3: P 36:42(6) ack 149 win 8964 (DF) 16:26:25.922254 > mail.pop3 > client.1104: P 149:219(70) ack 42 win 5840 (DF) 16:26:36.949499 < client.1104 > mail.pop3: P 36:42(6) ack 149 win 8964 (DF) 16:26:36.949533 > mail.pop3 > client.1104: . 219:219(0) ack 42 win 5840 (DF) 16:26:37.116302 > mail.pop3 > client.1104: P 149:219(70) ack 42 win 5840 (DF) 16:26:37.380554 < client.1104 > mail.pop3: P 42:50(8) ack 219 win 8894 (DF) 16:26:37.380645 > mail.pop3 > client.1104: . 219:219(0) ack 50 win 5840 (DF) 16:26:37.380709 > mail.pop3 > client.1104: P 219:231(12) ack 50 win 5840 (DF) 16:26:59.567440 < client.1104 > mail.pop3: P 42:50(8) ack 219 win 8894 (DF) 16:26:59.567476 > mail.pop3 > client.1104: . 231:231(0) ack 50 win 5840 (DF) 16:26:59.776301 > mail.pop3 > client.1104: P 219:231(12) ack 50 win 5840 (DF) 16:27:00.043125 < client.1104 > mail.pop3: P 50:59(9) ack 231 win 8882 (DF) 16:27:00.043186 > mail.pop3 > client.1104: . 231:231(0) ack 59 win 5840 (DF) 16:27:00.043475 > mail.pop3 > client.1104: . 231:767(536) ack 59 win 5840 (DF) 16:27:00.043491 > mail.pop3 > client.1104: P 767:1220(453) ack 59 win 5840 (DF) 16:27:44.399831 < client.1104 > mail.pop3: P 50:59(9) ack 231 win 8882 (DF) 16:27:44.399869 > mail.pop3 > client.1104: . 1220:1220(0) ack 59 win 5840 (DF) 16:27:44.836304 > mail.pop3 > client.1104: . 231:767(536) ack 59 win 5840 (DF) 16:27:45.295946 < client.1104 > mail.pop3: . 59:59(0) ack 767 win 9112 (DF) 16:27:45.296003 > mail.pop3 > client.1104: P 767:1220(453) ack 59 win 5840 (DF) 16:29:14.886322 > mail.pop3 > client.1104: P 767:1220(453) ack 59 win 5840 (DF) 16:29:15.264417 < client.1104 > mail.pop3: P 59:67(8) ack 1220 win 8659 (DF) 16:29:15.264479 > mail.pop3 > client.1104: . 1220:1220(0) ack 67 win 5840 (DF) 16:29:15.265127 > mail.pop3 > client.1104: . 1220:1756(536) ack 67 win 5840 (DF) 16:29:15.265145 > mail.pop3 > client.1104: . 1756:2292(536) ack 67 win 5840 (DF) 16:30:45.187652 < client.1104 > mail.pop3: P 59:67(8) ack 1220 win 8659 (DF) 16:30:45.187727 > mail.pop3 > client.1104: . 2292:2292(0) ack 67 win 5840 (DF) 16:31:16.326378 > mail.pop3 > client.1104: . 1220:1756(536) ack 67 win 5840 (DF) 16:31:17.513053 < client.1104 > mail.pop3: . 67:67(0) ack 1756 win 9112 (DF) 16:31:17.513129 > mail.pop3 > client.1104: . 1756:2292(536) ack 67 win 5840 (DF) 16:31:17.513143 > mail.pop3 > client.1104: . 2292:2828(536) ack 67 win 5840 (DF) 16:33:17.506376 > mail.pop3 > client.1104: . 1756:2292(536) ack 67 win 5840 (DF) 16:33:17.919146 < client.1104 > mail.pop3: . 67:67(0) ack 2292 win 9112 (DF) 16:33:17.919198 >
SO_SNDTIMEO: 2.4 kernel bugs
Hi, I was glad to see Linux gain SO_SNDTIMEO in kernel 2.4. It is a very use feature which can avoid complexity and pain in userspace programs. Unfortunately, it seems to be very buggy. Here are two buggy scenarios. 1) Create a socketpair(), PF_UNIX, SOCK_STREAM. Set a 5 second SO_SNDTIMEO on the socket. write() 100k down the socket in one write(), i.e. enough to cause the write to have to block. --> BUG!!! The call blocks indefinitely instead of returning after 5 seconds (Note that the same test but with SO_RCVTIMEO and a read() works as expected - I get EAGAIN after 5 seconds). 2) Create a localhost listening socket - AF_INET, SOCK_STREAM. Connect to the listening port Set a 5 second SO_SNDTIMEO on the socket. write() 1Mb down the socket in one write(), i.e. enough to cause it to have to block -> The write() will return after 5 seconds with a partial write count. GOOD! Repeat the write() - send another 1Mb. --> BUG!! The call blocks indefinitely instead of returning with EAGAIN after 5s. I hope this is detailled enough. I'm trying to gain access to a FreeBSD box to compare results.. 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: Linux stifles innovation...
Hahahaha. Dennis, the only linux network drivers that I have had serious problems with were yours. They caused kernel panic on 2.0.30+ every 6 hours. Of course I did not have the source to fix them. In comparision eepro100 works rock solid on all of my machines that use it. Will I use some binary only drivers again? No thanks! On Fri, 16 Feb 2001, Dennis wrote: > At 02:48 PM 02/16/2001, Jesse Pollard wrote: > >On Fri, 16 Feb 2001, Andrew Scott wrote: > > >On 15 Feb 2001, at 9:49, fsnchzjr wrote: > > > > > >> Watch Microsoft's Jim Allchin go Linux-bashing!!! > > >> Nice little article on how we're all going to die of herpes from our > > >> repeated exposition to Linux... > > >> > > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta > > >> g=ltnc > > > > > >That's about as self-serving a statement as I've ever seen. If this > > >'Jim Alchin' actually believes what he's saying, he's got to be one > > >of the worlds biggest fools, and if he doesn't believe what he's > > >saying, well there aren't too many words that would accurately > > >describe what he is. > > > > > >It's pretty funny in some ways, e.g. "We can build a better product > > >than Linux...", which begs the question, "Well, why don't you?". > > >Perhaps it costs too much? > > objective, arent we? > > There is much truth to the concept, although Microsoft should not be ones > to comment on it as such. > > 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 > with different "features" that were of value to you. Instead, you have > crappy GPL code that locks up under load, and its not worth spending > corporate dollars to fix it because you have to give away your work for > free under GPL. And since there is a "free" driver that most people can > use, its not worth building a better mousetrap either because the market is > too small. So, the handful of users with problems get to "fit it > themselves", most of whom cant of course. > > Theres also the propensity for mediocre stuff to get into the kernel > because some half-baked programmer was willing to contribute some code. The > 50% of the kernel that remains "experimental" ad infinitum is evidence of that. > > The biggest thing that the linux community does to stifle innovation is to > bash commercial vendors trying to make a profit by whining endlessly about > "sourceless" distributions and recommending "open-source" solutions even > when they are wholly inferior. You're only hurting yourselves in the long > run. In that respect MS is correct, because those with the dollars to > innovate will stay away. > > DB > > - > 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/
2.4.1-ac16 - Loopback device seems broken
I don't know if this is broken in 2.4.1-ac17 and 2.4.2-pre4, but, what happens when mounting a filesystem using the loopback device is that the process 'dies' in some way and there's no way I can kill it. This is what I did: mount /test-ext2-image.img /mnt/testimage -o loop,rw -t ext2 And after that there's no way I can get the process killed... Please CC replies to this email-address: [EMAIL PROTECTED] As I'm not currently subscribed to the linux kernel mailing-list. :-) Ole AndréFå deg en gratis webmail fra Hesbynett! http://diamondhead.hesbynett.no
[PROBLEM]: grep hanging with ReiserFS
grep -r "216.234.235.46" * ...waiting... ./debugps | more USER PID COMMAND WCHAN root 1 init do_select root 7 [kreiserfsd] - . root 28438 grep -r 216.234. pipe_wait Im using grep in /etc and its just waiting it should have finished. Shawn. - 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]: grep hanging with ReiserFS - More info
Linux coredump 2.4.2-pre3 #1 Fri Feb 9 20:57:39 EST 2001 i586 unknown Kernel modules 2.3.21 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.10.1 Linux C Library2.2.1 Dynamic linker ldd (GNU libc) 2.2.1 Procps 2.0.7 Mount 2.10r Net-tools 1.58 Console-tools 0.2.3 Sh-utils 2.0j Modules Loaded nls_cp437 vfat fat Shawn Starr wrote: > grep -r "216.234.235.46" * > > ...waiting... > > ./debugps | more > USER PID COMMAND WCHAN > root 1 init do_select > > root 7 [kreiserfsd] - > . > > root 28438 grep -r 216.234. pipe_wait > > Im using grep in /etc and its just waiting > it should have finished. > > Shawn. > > - > 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: Linux stifles innovation...
> > 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 > with different "features" that were of value to you. Instead, you have > crappy GPL code that locks up under load, and its not worth spending > corporate dollars to fix it because you have to give away your work for > free under GPL. And since there is a "free" driver that most people can > use, its not worth building a better mousetrap either because the market is > too small. So, the handful of users with problems get to "fit it > themselves", most of whom cant of course. > Assuming I am a corporate entity and I need to spend a few bucks to fix a GPL driver, just because I fix it and deploy my fix on my corporation's internal network machines -- and quite possibly benefit the hell out of myself and my company -- that does not mean that I have to release my work for free under the GPL. Of course, the *nice* thing to do would be to release it under the GPL even if I was only using the fix internally -- but I am under no obligation to do that, if, say, I just wanted to keep ahead of my competitors. Maybe I was planning to wait awhile so I could get ahead in my market. Maybe I'm just an IP freak and I want to keep my code to myself. Whatever. My understanding is that the only restrictions I have is that I can't sell or distribute the darned thing. If, say for example I needed to fix that driver so that it would work on my new WhizBang 2001 Corporate Server that is about to hit the market, then I would be making money on the hardware, and as an added bonus my company looks good because it has an "open" driver for its server. (no matter that it "had" to under the GPL) Mike Pontillo - 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]: grep hanging with ReiserFS
On Sat, 17 Feb 2001 02:12:40 -0500, Shawn Starr <[EMAIL PROTECTED]> wrote: > grep -r "216.234.235.46" * >Im using grep in /etc and its just waiting grep -r follows symlinks and tries to open named pipes. If you have qmail installed then /etc/qmail is a symlink to /var/qmail and named pipe /var/qmail/queue/lock/trigger lives down there. grep hangs trying to open the pipe. Not a reiserfs problem, just a badly designed application. - 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: block ioctl to read/write last sector
On Wed, 14 Feb 2001, David Balazic wrote: > Did you try scsi-emulation on IDE disks ? Don't be silly. That emulation is from scsi-packet to atapi-packet. Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.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: Whats the rvmalloc() story?
> I note that at least 5 device drivers have similar implementations > of rvmalloc()/rvfree() et al: > > ieee1394/video1394.c > usb/ibmcam.c > usb/ov511.c > media/video/bttv-driver.c > media/video/cpia.c > > rvmalloc()/rvfree() are functions that are used to allocate large > amounts of physically non-contiguous kernel virtual memory that will > then be mmap()'ed into a user process. I had to rewrite rvmalloc and friends in the bttv driver to support the new pci dynamic mapping interface. This sounds like a good time to clean up all these multiple definitions. Anton - 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/
