Re: "GPL weasels and the atheros stink"
> Question #1: Is it _ethical_ (legality aside) to take someone else's > actively maintained work (for example an OpenBSD driver) and make > changes which can not be shared/used by the original developer/maintainer? > > Answer #1: Considering that the whole reason I personally choose the GPL > for some projects is to prevent this sort of one way street behavior > _away_ from the original OSS developers/contributors _my_ answer must > be; No it is not ethical. I beg to differ. If you want to put things out there for others to use but want to avoid having the situation as you describe it, simply license the work as such (which would be neither BSD nor GPL)- requiring any changes to come back to the original maintainer. *Snort*. I seem to recall Unix commercial distributions that made claims that bug fixes that you made belonged to them. - 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: Fwd: That whole "Linux stealing our code" thing
This has been pretty interesting for me to watch as I distribute my isp driver under a dual license (at least the portions of it which are common with the *BSD and Solaris ports) that is almost identical to Sam's verbiage. I'll admit that I hadn't thought about whether redistribution included the ability to modify the header (and thus the text of the licensing as I had written) or not. On balance I'd say I believe that the arguments for, on redistribution, picking one or the other license makes sense and honored my general intent. This allows people who modify the code (and presumably improve it) a "chef's choice" based on where they're serving the meal. IANAL, but I believe that none of this keeps me from continuing to put a dual license on stuff I leave up for distribution, or changing that to restricting the code to Martian Triathalon winners or what have you. - 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: Fwd: That whole Linux stealing our code thing
This has been pretty interesting for me to watch as I distribute my isp driver under a dual license (at least the portions of it which are common with the *BSD and Solaris ports) that is almost identical to Sam's verbiage. I'll admit that I hadn't thought about whether redistribution included the ability to modify the header (and thus the text of the licensing as I had written) or not. On balance I'd say I believe that the arguments for, on redistribution, picking one or the other license makes sense and honored my general intent. This allows people who modify the code (and presumably improve it) a chef's choice based on where they're serving the meal. IANAL, but I believe that none of this keeps me from continuing to put a dual license on stuff I leave up for distribution, or changing that to restricting the code to Martian Triathalon winners or what have you. - 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: GPL weasels and the atheros stink
Question #1: Is it _ethical_ (legality aside) to take someone else's actively maintained work (for example an OpenBSD driver) and make changes which can not be shared/used by the original developer/maintainer? Answer #1: Considering that the whole reason I personally choose the GPL for some projects is to prevent this sort of one way street behavior _away_ from the original OSS developers/contributors _my_ answer must be; No it is not ethical. I beg to differ. If you want to put things out there for others to use but want to avoid having the situation as you describe it, simply license the work as such (which would be neither BSD nor GPL)- requiring any changes to come back to the original maintainer. *Snort*. I seem to recall Unix commercial distributions that made claims that bug fixes that you made belonged to them. - 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: FC - NPIV in 2.6.23-rc2
> > some sought of documentation for this, please let me know. > NPIV is a feature to provide multiple path available on one physical port and > it has implemented based on the multiport ID (MID) capability on the switch. > So, you have to have the switch with MID capable on the configuration to > support NPIV, besides the controller. > No, if the switch doesn't suport NP-IV, the 24XX f/w will come up in Public Loop mode (FL). - 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: FC - NPIV in 2.6.23-rc2
some sought of documentation for this, please let me know. NPIV is a feature to provide multiple path available on one physical port and it has implemented based on the multiport ID (MID) capability on the switch. So, you have to have the switch with MID capable on the configuration to support NPIV, besides the controller. No, if the switch doesn't suport NP-IV, the 24XX f/w will come up in Public Loop mode (FL). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
> hmm, wasn't loadable kernel modules first implemented in SunOS 4.x [...] Yes, but that was pretty cumbersome. You had to resolve the symbols in user space, using a hopefully matching /vmunix. Linux was first to feature an in-kernel linker and symbol table, IIRC. Err, uh, no- I believe that Solaris development for this at the very least predates even 0.59 linux- I think it was Joe Provino at Sun ECD near Boston who gave us a working prototype in early 1989. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
hmm, wasn't loadable kernel modules first implemented in SunOS 4.x [...] Yes, but that was pretty cumbersome. You had to resolve the symbols in user space, using a hopefully matching /vmunix. Linux was first to feature an in-kernel linker and symbol table, IIRC. Err, uh, no- I believe that Solaris development for this at the very least predates even 0.59 linux- I think it was Joe Provino at Sun ECD near Boston who gave us a working prototype in early 1989. - 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: DMA mapping API for non-system memory pools
Yes- this would be interesting to know wrt to doing things like PCI<>PCI xfers (e.g., for things like the Micromemory NVRAM card). On 2/9/07, Kumar Gala <[EMAIL PROTECTED]> wrote: We've been having a discussion on the linuxppc-dev list about how to handle IO memory that exists on some PPC SoC devices. These IO memories behave like system memory but are faster to the processor or device needed accessing for things like buffer descriptors. - 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: DMA mapping API for non-system memory pools
Yes- this would be interesting to know wrt to doing things like PCIPCI xfers (e.g., for things like the Micromemory NVRAM card). On 2/9/07, Kumar Gala [EMAIL PROTECTED] wrote: We've been having a discussion on the linuxppc-dev list about how to handle IO memory that exists on some PPC SoC devices. These IO memories behave like system memory but are faster to the processor or device needed accessing for things like buffer descriptors. - 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: [BK] upgrade will be needed
Umm- can't say I agree. I've known Larry since, oh, 1988, and up to about 18 months ago I lived about 3 blocks away from him and his family. Larry is pretty honest. He certainly isn't as evil as many on this list make him out to be. > > He is simply plain dishonest about his intentions. And since he is > driving a > company it's not difficult to deduce what his intentions really are: > Making money. > That's plain and simple what all companies are all about. > Now you can start to guess how he wants to accomplish this. > > - 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: [BK] upgrade will be needed
> So how would you suggest that we resolve it? The protection we need is > that people don't get to > >- use BK >- stop using BK so they can go work on another system >- start using BK again >- stop using BK so they can go work on another system >... > I guess I don't see the advantage that accrues to BitMover Inc from this or what you're trying to do here. I'm not trying to add kerosene to a flame fest here, but I'm definitely scratching my head on this one. Is your concern that you don't want to provide a free tool to people who then turn around to compete with you? That is, you don't want BK to enable people to do things to harm BK and its ongoing development? I mean- you're certainly free to impose whatever license you want, and others are free to be happy or unhappy with that. I'm just trying to figure out what you're actually trying to accomplish here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
So how would you suggest that we resolve it? The protection we need is that people don't get to - use BK - stop using BK so they can go work on another system - start using BK again - stop using BK so they can go work on another system ... I guess I don't see the advantage that accrues to BitMover Inc from this or what you're trying to do here. I'm not trying to add kerosene to a flame fest here, but I'm definitely scratching my head on this one. Is your concern that you don't want to provide a free tool to people who then turn around to compete with you? That is, you don't want BK to enable people to do things to harm BK and its ongoing development? I mean- you're certainly free to impose whatever license you want, and others are free to be happy or unhappy with that. I'm just trying to figure out what you're actually trying to accomplish here. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Umm- can't say I agree. I've known Larry since, oh, 1988, and up to about 18 months ago I lived about 3 blocks away from him and his family. Larry is pretty honest. He certainly isn't as evil as many on this list make him out to be. He is simply plain dishonest about his intentions. And since he is driving a company it's not difficult to deduce what his intentions really are: Making money. That's plain and simple what all companies are all about. Now you can start to guess how he wants to accomplish this. - 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: [BK] upgrade will be needed
I'm curious why you'd have a non-compete for 1 year for just using BK. That would make BK more or less unique amongst packages, no? - 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: Busy inodes after umount
I reported this a couple of months back. It's reassuring to know that it's a consistent problem. On Fri, 20 Jul 2001, [iso-8859-1] Ragnar Kjørstad wrote: > On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote: > > I found the same thing happening. Tracked it down in our case to using fdisk to >re-read disk size before mounting. Replaced it with "blockdev --readpt" and the >problem seems to have gone away. YMMV. > > I've now been able to reproduce: > > * make a filesystem > * mount it > * export it (nfs) > * mount on remote machine > * lock file (fcntl) > * unexport > * unmount > > Then you get the VFS message about self-destruct. Tested with both ext2 > and xfs. > > The lock is still present in /proc/locks after the umount. > > With ext2 I can remount the filesystem successfully, but with XFS I get > the message about duplicate UUIDs and the mount failes. I believe this is a totally > different problem from the one you were experiencing. (and blockdev doesn't help for >me) > > I suppose this is a generic kernel bug? > > > - 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: Busy inodes after umount
I reported this a couple of months back. It's reassuring to know that it's a consistent problem. On Fri, 20 Jul 2001, [iso-8859-1] Ragnar Kjørstad wrote: On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote: I found the same thing happening. Tracked it down in our case to using fdisk to re-read disk size before mounting. Replaced it with blockdev --readpt and the problem seems to have gone away. YMMV. I've now been able to reproduce: * make a filesystem * mount it * export it (nfs) * mount on remote machine * lock file (fcntl) * unexport * unmount Then you get the VFS message about self-destruct. Tested with both ext2 and xfs. The lock is still present in /proc/locks after the umount. With ext2 I can remount the filesystem successfully, but with XFS I get the message about duplicate UUIDs and the mount failes. I believe this is a totally different problem from the one you were experiencing. (and blockdev doesn't help for me) I suppose this is a generic kernel bug? - 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/
RESEND: [ PATCH ] externalize (new) scsi timer function
I sent this back in January and previously. I still think they're important. FWIW, Doug Gilbert thought they were okay. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - 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: Qlogic Fiber Channel
You know, this is probably slightly OTm, but I've been getting closer and closer to what I consider 'happy' for my QLogic megadriver under Linux- I have just a tad more to deal with in local loop failures (I spent far too much time working on fabric only)- but I've been happier with it and need to close it up and move on. I *do* plan to finish IP support eventually. I certainly would like to get more feedback about it. Feel free to pick up- bk://blade.feral.com:9002 ftp://ftp.feral.com/pub/isp/isp_dist.tgz It's certainly got the latest f/w in it which you can try and use with qlogicfc. -matt On Fri, 29 Jun 2001, [ISO-8859-1] christophe barbé wrote: > > Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit : > > > From my point of view, this driver is sadly broken. The fun part is > that > > > the qlogic driver is certainly based on this one too (look at the code, > > > the drivers differs not so much). > > > > And if the other one is stable someone should spend the time merging the > > two. > > That what I would like to try but It seems impossible without an > IP-enhanced firmware. I could try with the old firmware but I believe that > the new code from QLogic use some features that are only in recent > firmware. > > > > > > IMHO the qlogicfc driver should be removed from the kernel tree and > > > perhaps replaced by the last qlogic one. We then lost the IP support > > > but this is a broken support. > > > > For 2.5 that may wellk make sense. Personally I'd prefer someone worked > > out > > why the qlogicfc driver behaves as it does. It sounds like two small bugs > > nothing more > > > > 1. That the FC event code wasnt updated from 2.2 so now runs > > with IRQ's off when it didnt expect it > > > > 2. That someone has a slight glitch in the queue handling. > > This driver is already buggy under kernel 2.2. This driver is a well known > source of problems in the GFS mailing lists. > > I believe that the better thing to do is to use the qlogic driver. If we > manage to get a recent IP-enhanced firmware we could rewrite the missing IP > code. Half of the job is already done in the source of this driver. > > I didn't manage to reach the good person from qlogic. Perhaps someone would > have better results. > > Christophe > > -- > Christophe Barbé > Software Engineer - [EMAIL PROTECTED] > Lineo France - Lineo High Availability Group > 42-46, rue Médéric - 92110 Clichy - France > phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 > http://www.lineo.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/ > - 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: Qlogic Fiber Channel
You know, this is probably slightly OTm, but I've been getting closer and closer to what I consider 'happy' for my QLogic megadriver under Linux- I have just a tad more to deal with in local loop failures (I spent far too much time working on fabric only)- but I've been happier with it and need to close it up and move on. I *do* plan to finish IP support eventually. I certainly would like to get more feedback about it. Feel free to pick up- bk://blade.feral.com:9002 ftp://ftp.feral.com/pub/isp/isp_dist.tgz It's certainly got the latest f/w in it which you can try and use with qlogicfc. -matt On Fri, 29 Jun 2001, [ISO-8859-1] christophe barbé wrote: Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit : From my point of view, this driver is sadly broken. The fun part is that the qlogic driver is certainly based on this one too (look at the code, the drivers differs not so much). And if the other one is stable someone should spend the time merging the two. That what I would like to try but It seems impossible without an IP-enhanced firmware. I could try with the old firmware but I believe that the new code from QLogic use some features that are only in recent firmware. IMHO the qlogicfc driver should be removed from the kernel tree and perhaps replaced by the last qlogic one. We then lost the IP support but this is a broken support. For 2.5 that may wellk make sense. Personally I'd prefer someone worked out why the qlogicfc driver behaves as it does. It sounds like two small bugs nothing more 1. That the FC event code wasnt updated from 2.2 so now runs with IRQ's off when it didnt expect it 2. That someone has a slight glitch in the queue handling. This driver is already buggy under kernel 2.2. This driver is a well known source of problems in the GFS mailing lists. I believe that the better thing to do is to use the qlogic driver. If we manage to get a recent IP-enhanced firmware we could rewrite the missing IP code. Half of the job is already done in the source of this driver. I didn't manage to reach the good person from qlogic. Perhaps someone would have better results. Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.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/ - 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/
RESEND: [ PATCH ] externalize (new) scsi timer function
I sent this back in January and previously. I still think they're important. FWIW, Doug Gilbert thought they were okay. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Sure- that's not BSD. You were speaking about all kinds of firmware, at least
I thought you were. Must be too short on sleep.
On Thu, 24 May 2001, Aaron Lehmann wrote:
> On Thu, May 24, 2001 at 10:00:15PM -0700, Matthew Jacob wrote:
> >
> > It is my opinion, such as it is, that a BSD copyright inside of a GPL package
> > does not, per se, weaken the GPL. The BSD copyright is, in fact, the more
> > permissive license. My reading of both licenses would have me believe that a
> > BSD licensed piece of software cannot then permit the linux kernel to be
> > binary only. The BSD licencse does not, per se, prohibit any form of binary
> > redistribution- nor does it require it. The GPL covers the whole kernel, and
> > if a BSD piece of code is directly linked in (not modloaded), it would have to
> > also be under GPL.
> >
> > So pieces of linux-kernel which have BSD copyright are probably just fine.
>
> /* keyspan_usa18x_fw.h
>
>Generated from Keyspan firmware image Wed Jul 5 09:18:29 2000 EST
>This firmware is for the Keyspan USA-18X Serial Adaptor
>
>"The firmware contained herein as keyspan_usa18x_fw.h is
>Copyright (C) 1999-2000 Keyspan, A division of InnoSys Incorporated
>("Keyspan"), as an unpublished work. This notice does not imply
>unrestricted or public access to this firmware which is a trade secret of
>Keyspan, and which may not be reproduced, used, sold or transferred to any
>third party without Keyspan's prior written consent. All Rights Reserved.
>
>This firmware may not be modified and may only be used with the Keyspan
> ^^^
>USA-18X Serial Adapter. Distribution and/or Modification of the
>keyspan.c driver which includes this firmware, in whole or in part,
>requires the inclusion of this statement."
>
> That doesn't look like the BSD license to me.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Sure- that's not BSD. You were speaking about all kinds of firmware, at least I thought you were. Must be too short on sleep. On Thu, 24 May 2001, Aaron Lehmann wrote: On Thu, May 24, 2001 at 10:00:15PM -0700, Matthew Jacob wrote: It is my opinion, such as it is, that a BSD copyright inside of a GPL package does not, per se, weaken the GPL. The BSD copyright is, in fact, the more permissive license. My reading of both licenses would have me believe that a BSD licensed piece of software cannot then permit the linux kernel to be binary only. The BSD licencse does not, per se, prohibit any form of binary redistribution- nor does it require it. The GPL covers the whole kernel, and if a BSD piece of code is directly linked in (not modloaded), it would have to also be under GPL. So pieces of linux-kernel which have BSD copyright are probably just fine. /* keyspan_usa18x_fw.h Generated from Keyspan firmware image Wed Jul 5 09:18:29 2000 EST This firmware is for the Keyspan USA-18X Serial Adaptor The firmware contained herein as keyspan_usa18x_fw.h is Copyright (C) 1999-2000 Keyspan, A division of InnoSys Incorporated (Keyspan), as an unpublished work. This notice does not imply unrestricted or public access to this firmware which is a trade secret of Keyspan, and which may not be reproduced, used, sold or transferred to any third party without Keyspan's prior written consent. All Rights Reserved. This firmware may not be modified and may only be used with the Keyspan ^^^ USA-18X Serial Adapter. Distribution and/or Modification of the keyspan.c driver which includes this firmware, in whole or in part, requires the inclusion of this statement. That doesn't look like the BSD license to me. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - 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/
Copyright for drivers- two SCSI HBA drivers
> As a user of hardware which requires firmware like this, I have mixed > feelings, but feel strongly that requirements of the GPL clearly > override any measure of convenience. Are there any plans to remove the > binary-only firmware from the kernel, and/or eventually from the Linux > source distribution? I am not refering to this USB driver > specifically, but rather the general occurance of firmware embedded in > Linux device trivers. > In the specific instances that I know about, the f/w for the older Qlogic SCSI cards (the drivers *not* supplied by vendors) for qlogicisp (qlogicisp_asm.c) and qlogicpti (qlogicisp_pti.c) is in the Linux source *and has been for years) with no copyright attribution whatsoever. qlogicfc has the BSD style copyright that I partly, but mostly Theo Deraadt of OpenBSD, managed to beat QLogic into doing. Versions of f/w for qlogicisp && qlogicpti can easily also be had with the BSD licence- check any *BSD distribution, or pick 'em up via bitkeeper from my site. -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/
Copyright for drivers- two SCSI HBA drivers
As a user of hardware which requires firmware like this, I have mixed feelings, but feel strongly that requirements of the GPL clearly override any measure of convenience. Are there any plans to remove the binary-only firmware from the kernel, and/or eventually from the Linux source distribution? I am not refering to this USB driver specifically, but rather the general occurance of firmware embedded in Linux device trivers. In the specific instances that I know about, the f/w for the older Qlogic SCSI cards (the drivers *not* supplied by vendors) for qlogicisp (qlogicisp_asm.c) and qlogicpti (qlogicisp_pti.c) is in the Linux source *and has been for years) with no copyright attribution whatsoever. qlogicfc has the BSD style copyright that I partly, but mostly Theo Deraadt of OpenBSD, managed to beat QLogic into doing. Versions of f/w for qlogicisp qlogicpti can easily also be had with the BSD licence- check any *BSD distribution, or pick 'em up via bitkeeper from my site. -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/
Re: /dev/sch0 interface
I think pretty much everyone uses mtx via the sg interface. - 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: /dev/sch0 interface
I think pretty much everyone uses mtx via the sg interface. - 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: Wow! Is memory ever cheap!
On Wed, 9 May 2001, [ISO-8859-1] Gérard Roudier wrote: > > > On Tue, 8 May 2001, Dan Hollis wrote: > > > On Tue, 8 May 2001, Larry McVoy wrote: > > > which is a text version of the paper I mentioned before. The basic > > > message of the paper is that it really doesn't help much to have things > > > like ECC unless you can be sure that 100% of the rest of your system > > > has similar checks. > > > > UDMA has crc, scsi has parity, pci has (i think) parity, tcpip has crc, > > your cpu l1 and l2 have ecc... > > SCSI Ultra-160 has CRC. > > PCI has parity (btw, you think right), but only a few drivers make sure > PCI parity checking is enabled. On the other hand, a PCI parity error Sun's panic if they get SERR or PERR. > should be considered as extremally serious and the system should be > stopped when such happens. > > Btw, it seems (read at the pci list) that the original PCI hadn't parity. > After all, PCI had been designed for PC machines... :) > > > Looks like similar checks are already there. > > > > -Dan > > > Gérard. > > - > 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: Wow! Is memory ever cheap!
On Wed, 9 May 2001, [ISO-8859-1] Gérard Roudier wrote: On Tue, 8 May 2001, Dan Hollis wrote: On Tue, 8 May 2001, Larry McVoy wrote: which is a text version of the paper I mentioned before. The basic message of the paper is that it really doesn't help much to have things like ECC unless you can be sure that 100% of the rest of your system has similar checks. UDMA has crc, scsi has parity, pci has (i think) parity, tcpip has crc, your cpu l1 and l2 have ecc... SCSI Ultra-160 has CRC. PCI has parity (btw, you think right), but only a few drivers make sure PCI parity checking is enabled. On the other hand, a PCI parity error Sun's panic if they get SERR or PERR. should be considered as extremally serious and the system should be stopped when such happens. Btw, it seems (read at the pci list) that the original PCI hadn't parity. After all, PCI had been designed for PC machines... :) Looks like similar checks are already there. -Dan Gérard. - 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: Wow! Is memory ever cheap!
I'll frickin' whine if I want to :-). I still use bitkeeper on a Solaris 2.6 machine with 32MB of memory. On Sat, 5 May 2001, Larry McVoy wrote: > This is a 750Mhz K7 system with 1.5GB of memory in 3 512MB DIMMS. The > DIMMS are not ECC, but we use BitKeeper here and it tells us when we > have bad DIMMS. > > Guess what the memory cost? $396.58 shipped to my door, second day air, > with a lifetime warranty. I got it at www.memory4less.com which I found > using www.pricewatch.com. I have no association with either of those > places other than being a customer (i.e., this isn't advertising spam). > > I'm burning it in right now, I wrote a little program which fills it > with different test patterns and then reads them back to make sure they > don't lose any bits. Seems to be working, it's done about 30 passes. > > 1.5GB for $400. Amazing. No more whining from you guys that BitKeeper > uses too much memory :-) > > $ hinv > Main memory size: 1535.9375 Mbytes > 1 AuthenticAMD processor > 1 1.44M floppy drive > 1 vga+ graphics device > 1 keyboard > IDE devices: > /dev/hda is a ST310211A, 9541MB w/512kB Cache, CHS=1216/255/63 > SCSI devices: > /dev/sda is a 3ware disk, model 3w- 74.541 GB > PCI bus devices: > Host bridge: VIA Technologies VT 82C691 Apollo Pro (rev 2). > PCI bridge: VIA Technologies VT 82C598 Apollo MVP3 AGP (rev 0). > ISA bridge: VIA Technologies VT 82C686 Apollo Super (rev 34). > IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 16). > Host bridge: VIA Technologies VT 82C686 Apollo Super ACPI (rev 48). > Ethernet controller: 3Com 3C905B 100bTX (rev 48). > Ethernet controller: 3Com 3C905B 100bTX (rev 48). > Ethernet controller: 3Com 3C905B 100bTX (rev 48). > Ethernet controller: 3Com 3C905B 100bTX (rev 48). > RAID storage controller: Unknown vendor Unknown device (rev 18). > VGA compatible controller: Matrox Matrox G200 AGP (rev 1). > -- > --- > Larry McVoylm at bitmover.com >http://www.bitmover.com/lm > - > 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: Wow! Is memory ever cheap!
I'll frickin' whine if I want to :-). I still use bitkeeper on a Solaris 2.6 machine with 32MB of memory. On Sat, 5 May 2001, Larry McVoy wrote: This is a 750Mhz K7 system with 1.5GB of memory in 3 512MB DIMMS. The DIMMS are not ECC, but we use BitKeeper here and it tells us when we have bad DIMMS. Guess what the memory cost? $396.58 shipped to my door, second day air, with a lifetime warranty. I got it at www.memory4less.com which I found using www.pricewatch.com. I have no association with either of those places other than being a customer (i.e., this isn't advertising spam). I'm burning it in right now, I wrote a little program which fills it with different test patterns and then reads them back to make sure they don't lose any bits. Seems to be working, it's done about 30 passes. 1.5GB for $400. Amazing. No more whining from you guys that BitKeeper uses too much memory :-) $ hinv Main memory size: 1535.9375 Mbytes 1 AuthenticAMD processor 1 1.44M floppy drive 1 vga+ graphics device 1 keyboard IDE devices: /dev/hda is a ST310211A, 9541MB w/512kB Cache, CHS=1216/255/63 SCSI devices: /dev/sda is a 3ware disk, model 3w- 74.541 GB PCI bus devices: Host bridge: VIA Technologies VT 82C691 Apollo Pro (rev 2). PCI bridge: VIA Technologies VT 82C598 Apollo MVP3 AGP (rev 0). ISA bridge: VIA Technologies VT 82C686 Apollo Super (rev 34). IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 16). Host bridge: VIA Technologies VT 82C686 Apollo Super ACPI (rev 48). Ethernet controller: 3Com 3C905B 100bTX (rev 48). Ethernet controller: 3Com 3C905B 100bTX (rev 48). Ethernet controller: 3Com 3C905B 100bTX (rev 48). Ethernet controller: 3Com 3C905B 100bTX (rev 48). RAID storage controller: Unknown vendor Unknown device (rev 18). VGA compatible controller: Matrox Matrox G200 AGP (rev 1). -- --- Larry McVoylm at bitmover.com http://www.bitmover.com/lm - 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: networked file system
Something like this was presented at OSDI, uh, year before last.. you might check the Usenix webpage about this. On 20 Apr 2001 [EMAIL PROTECTED] wrote: > Suppose that an entry on any filesystem could be replaced by a symlink > which pointed to a URL, and that an appropriate handler was dispatched > for that URL. This would allow, for example, config files to point to > a different machine. > > Right now we can accomplish this by mounting alternative file systems > and symlinking to them, but only if an appropriate file system has > been written. > - > 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: networked file system
Something like this was presented at OSDI, uh, year before last.. you might check the Usenix webpage about this. On 20 Apr 2001 [EMAIL PROTECTED] wrote: Suppose that an entry on any filesystem could be replaced by a symlink which pointed to a URL, and that an appropriate handler was dispatched for that URL. This would allow, for example, config files to point to a different machine. Right now we can accomplish this by mounting alternative file systems and symlinking to them, but only if an appropriate file system has been written. - 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: active after unmount?
Double cool then. > > > On Thu, 19 Apr 2001, Matthew Jacob wrote: > > > > > 'kay, great, thanks.. I'll put it in and see if things show up again > > Guys, it's a known bug, fixed in 2.4.4-pre3. See the change to fs/super.c > between 2.4.4-pre2 and 2.4.4-pre3 - it's quite small. > - 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: active after unmount?
'kay, great, thanks.. I'll put it in and see if things show up again - 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: active after unmount?
On Thu, 19 Apr 2001, Brian J. Watson wrote: > > Unmounting a SCSI disk device succeeded, and yielded: > > > > Red Hat Linux release 6.2 (Zoot) > > Kernel 2.4.3 on a 2-processor i686 > > > > chico login: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have > > a nice day... > > > > > This message comes out of kill_super(). I would guess that somebody's > mismanaging VFS refcounts, but there's not enough info here to diagnose the > problem. What filesystem are you using? Is this reproducible? What do you have > to do between mounting and unmounting to reproduce the problem? >>ext2<<, haven't reproduced it yet, on a 2x686 256MB memory, SCSI midlayer default, with 2.4.3. -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/
Re: active after unmount?
On Thu, 19 Apr 2001, Brian J. Watson wrote: Unmounting a SCSI disk device succeeded, and yielded: Red Hat Linux release 6.2 (Zoot) Kernel 2.4.3 on a 2-processor i686 chico login: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... This message comes out of kill_super(). I would guess that somebody's mismanaging VFS refcounts, but there's not enough info here to diagnose the problem. What filesystem are you using? Is this reproducible? What do you have to do between mounting and unmounting to reproduce the problem? ext2, haven't reproduced it yet, on a 2x686 256MB memory, SCSI midlayer default, with 2.4.3. -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/
Re: active after unmount?
'kay, great, thanks.. I'll put it in and see if things show up again - 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: active after unmount?
Double cool then. On Thu, 19 Apr 2001, Matthew Jacob wrote: 'kay, great, thanks.. I'll put it in and see if things show up again Guys, it's a known bug, fixed in 2.4.4-pre3. See the change to fs/super.c between 2.4.4-pre2 and 2.4.4-pre3 - it's quite small. - 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/
active after unmount?
Unmounting a SCSI disk device succeeded, and yielded: Red Hat Linux release 6.2 (Zoot) Kernel 2.4.3 on a 2-processor i686 chico login: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... - 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/
active after unmount?
Unmounting a SCSI disk device succeeded, and yielded: Red Hat Linux release 6.2 (Zoot) Kernel 2.4.3 on a 2-processor i686 chico login: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... - 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: Intel-e1000 for Linux 2.0.36-pre14
On Mon, 5 Mar 2001, Ofer Fryman wrote: > I meant that if I had the specs I would have finished the driver sooner, > unfortunately I do not have them, but I am eager to get them in order to > improve performance on the card. > > You are right there are no specs on Intel's web site, nor did anyone in > Intel answered any of my e-mails or returned any of my calls. Heh! Well- at least you have it working! Good! - 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: Intel-e1000 for Linux 2.0.36-pre14
On Mon, 5 Mar 2001, Ofer Fryman wrote: I meant that if I had the specs I would have finished the driver sooner, unfortunately I do not have them, but I am eager to get them in order to improve performance on the card. You are right there are no specs on Intel's web site, nor did anyone in Intel answered any of my e-mails or returned any of my calls. Heh! Well- at least you have it working! Good! - 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: [Slightly OT] x86 PROM project
On Sun, 4 Mar 2001, Erik Mouw wrote: > On Sun, Mar 04, 2001 at 12:29:47PM -0600, Matthew Fredrickson wrote: > > What does everybody think of the idea of trying to write a RISC PROM-like > > BIOS for the x86 architecture? > > > > I've been tossing the idea around in my head for a while, and after I got > > my first SGI I realized that something like this would be fairly useful. > > Basically, I'm wondering if anybody is already doing something like this > > (not linuxBIOS, though the code for that could be a useful base). Thanks. > > Have a look at OpenBIOS: > > http://www.freiburg.linux.de/OpenBIOS/ > > The project wants to create an IEEE 1275-1994 compliant firmware, like > used by SUN (for example). > and apple && ibm > - 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: [Slightly OT] x86 PROM project
On Sun, 4 Mar 2001, Erik Mouw wrote: On Sun, Mar 04, 2001 at 12:29:47PM -0600, Matthew Fredrickson wrote: What does everybody think of the idea of trying to write a RISC PROM-like BIOS for the x86 architecture? I've been tossing the idea around in my head for a while, and after I got my first SGI I realized that something like this would be fairly useful. Basically, I'm wondering if anybody is already doing something like this (not linuxBIOS, though the code for that could be a useful base). Thanks. Have a look at OpenBIOS: http://www.freiburg.linux.de/OpenBIOS/ The project wants to create an IEEE 1275-1994 compliant firmware, like used by SUN (for example). and apple ibm - 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: Intel-e1000 for Linux 2.0.36-pre14
On Thu, 1 Mar 2001, Richard B. Johnson wrote: > On Thu, 1 Mar 2001 [EMAIL PROTECTED] wrote: > > > On Thu, 1 Mar 2001, Ofer Fryman wrote: > > > > > I managed to compiled e1000 for Linux 2.0.36-pre14, I can also load it > > > successfully. > > > With the E1000_IMS_RXSEQ bit set in IMS_ENABLE_MASK I get endless interrupts > > > and the computer freezes, without this bit set it works but I cannot receive > > > or send anything. > > > > Intel refuses to provide complete documentation for any of their ethernet > > cards. I recommend purchasing alternative products from vendors like 3com > > and National Semiconduct who are cooperative in providing data needed by > > the development community. > > > > Well Intel has been a continual contributor to Linux and BSD. Somebody > is not getting to the right person. There are lazy people at all > companies. Sorry, I don't believe that that this is correct in this case. I spoke on the telephone with the "Manager for Open Source Systems", and the concept of releasing documents to that a driver could be written whose source would be available was a concept too far. He kept on asking about NDAs- I kept on saying, yes, I'll sign an NDA (presumably so knowledge of advanced features, such as VLAN taggging, e.g., would not be released if they did not want it to be)- but the basic driver source would have to be OPEN! (this was for *BSD, but that's the same as linux in this case- we *all* want the damned source open). No meeting of minds. I have been trying this on and off for two years so that I can properly support the Wiseman && Livengood chipsets in *BSD. No luck, ergo, reverse engineering of what little they release with the Linux driver is the order of the day still. The Linux driver, btw, is pretty clearly a port of an NT driver- which is quite amusing. FWIW.I just think that the overall company policy within Intel, much like that of NetApp and others, is, "Open Source? Well, maybe, err,umm.. "... It's just not that important to them (as a company, they think). That said- if you can get access to said documentation (which I understand comes in a certain notebook that indicates releasing outside of Intel is a firing offense)- more power to you! -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/
Re: Intel-e1000 for Linux 2.0.36-pre14
On Thu, 1 Mar 2001, Richard B. Johnson wrote: On Thu, 1 Mar 2001 [EMAIL PROTECTED] wrote: On Thu, 1 Mar 2001, Ofer Fryman wrote: I managed to compiled e1000 for Linux 2.0.36-pre14, I can also load it successfully. With the E1000_IMS_RXSEQ bit set in IMS_ENABLE_MASK I get endless interrupts and the computer freezes, without this bit set it works but I cannot receive or send anything. Intel refuses to provide complete documentation for any of their ethernet cards. I recommend purchasing alternative products from vendors like 3com and National Semiconduct who are cooperative in providing data needed by the development community. Well Intel has been a continual contributor to Linux and BSD. Somebody is not getting to the right person. There are lazy people at all companies. Sorry, I don't believe that that this is correct in this case. I spoke on the telephone with the "Manager for Open Source Systems", and the concept of releasing documents to that a driver could be written whose source would be available was a concept too far. He kept on asking about NDAs- I kept on saying, yes, I'll sign an NDA (presumably so knowledge of advanced features, such as VLAN taggging, e.g., would not be released if they did not want it to be)- but the basic driver source would have to be OPEN! (this was for *BSD, but that's the same as linux in this case- we *all* want the damned source open). No meeting of minds. I have been trying this on and off for two years so that I can properly support the Wiseman Livengood chipsets in *BSD. No luck, ergo, reverse engineering of what little they release with the Linux driver is the order of the day still. The Linux driver, btw, is pretty clearly a port of an NT driver- which is quite amusing. FWIW.I just think that the overall company policy within Intel, much like that of NetApp and others, is, "Open Source? Well, maybe, err,umm.. "... It's just not that important to them (as a company, they think). That said- if you can get access to said documentation (which I understand comes in a certain notebook that indicates releasing outside of Intel is a firing offense)- more power to you! -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/
Re: aic7xxx (and sym53c8xx) plans
> May-be this is the reason some UNIX vendors seem to love UDI. :) > > If you also use SYMBIOS chips, you may give a try with SYM-2. For the > moment, it replaces only 6 drivers :) as also seems to do, for the moment, > Justin's AIC7XXX-6, by the way. > > The plans seem clear to me. :-) > Btw, I _do_ like a lot better the 'one driver' plan over the '12 or more' > one. Hmm. Well, it's good if it works. The joint Qlogic FC/SCSI driver of mine has it's own plusses && minusses... - 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
May-be this is the reason some UNIX vendors seem to love UDI. :) If you also use SYMBIOS chips, you may give a try with SYM-2. For the moment, it replaces only 6 drivers :) as also seems to do, for the moment, Justin's AIC7XXX-6, by the way. The plans seem clear to me. :-) Btw, I _do_ like a lot better the 'one driver' plan over the '12 or more' one. Hmm. Well, it's good if it works. The joint Qlogic FC/SCSI driver of mine has it's own plusses minusses... - 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
On Wed, 14 Feb 2001, Chip Salzenberg wrote: > According to Matthew Jacob: > > See http://www.freebsd.org/~gibbs/linux. > > Here at VA we're already using Jason's driver -- it works on the Intel > STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). "Justin" not "Jason" > > While we're discussing SCSI drivers, I'd also like to put in a good > word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: > > ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ > > Joe-Bob says: "Check it out." Yes indeed. And he also support FreeBSD too. Very excellent. Maybe the two of *them* can convince Linus to take the !$*!)$*!)$*~$)* patch to scsi_syms.c that exports the add/del timer functions - 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 plans
See http://www.freebsd.org/~gibbs/linux. > Alan Cox wrote: > > > Are there any plans of switching the drivers ? I have tried to patch 2.4.1-acX, > > > but there are rejected hunks and had no time to patch manually and make a > > > diff. > > > > I dont plan to switch them yet a while, and never for 2.2. For 2.5 its a > > total nobrainer that we move to Justins driver or move to Justins driver post > > crudfixing that may be needed to make it clean and Linuxish > > I forget the location, where can I get this patch? I'm running 2.4.1 on an > alpha which has nothing but problems with the aha-2940uw card I have > installed. > > - 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 plans
See http://www.freebsd.org/~gibbs/linux. Alan Cox wrote: Are there any plans of switching the drivers ? I have tried to patch 2.4.1-acX, but there are rejected hunks and had no time to patch manually and make a diff. I dont plan to switch them yet a while, and never for 2.2. For 2.5 its a total nobrainer that we move to Justins driver or move to Justins driver post crudfixing that may be needed to make it clean and Linuxish I forget the location, where can I get this patch? I'm running 2.4.1 on an alpha which has nothing but problems with the aha-2940uw card I have installed. - 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
On Wed, 14 Feb 2001, Chip Salzenberg wrote: According to Matthew Jacob: See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). "Justin" not "Jason" While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." Yes indeed. And he also support FreeBSD too. Very excellent. Maybe the two of *them* can convince Linus to take the !$*!)$*!)$*~$)* patch to scsi_syms.c that exports the add/del timer functions - 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: RFC: Kernel mechanism: Compound event wait/notify + callback chains
Why don't you look at Kqueues (from FreeBSD)? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: Kernel mechanism: Compound event wait/notify + callback chains
Why don't you look at Kqueues (from FreeBSD)? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: No SCSI Ultra 160 with Adaptec Controller
Well, this is all what comes from not spending money on this stuff myself- I guess I just have too many 3 year old drives... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: No SCSI Ultra 160 with Adaptec Controller
Well, this is all what comes from not spending money on this stuff myself- I guess I just have too many 3 year old drives... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: No SCSI Ultra 160 with Adaptec Controller
On Tue, 23 Jan 2001 [EMAIL PROTECTED] wrote: > Hi Tom. Thanks for writing. > > > Since this machine has Quantum drives I guess this is my > > problem. Does anyone > > know if this code is still actually necessary? It seems > > it's been there a > > while. It's disappointing to not get full performance out of > > the hardware you > > have. > > Yes, that code is still necessary. There's a new aic7xxx driver by Justin > Gibbs at Adaptec which is now being beta tested which corrects this issue. > Something to note, however: the media transfer rate for those disks is at > most ~20MB/sec. Actually, aren't a number of newer drives getting upwards of 30MB/s? > Therefore, you only exceed the 80MB/sec bus speed if you > have more than 4 disks all doing maximum I/O at the same time. Since the > PowerApp.web 100 has at most 2 disks internally, you really shouldn't see > any significant performance difference. > > Hope this helps. > Thanks for buying Dell! > Matt Domsch > Dell Linux Systems Group > Linux OS Development > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: No SCSI Ultra 160 with Adaptec Controller
On Tue, 23 Jan 2001 [EMAIL PROTECTED] wrote: Hi Tom. Thanks for writing. Since this machine has Quantum drives I guess this is my problem. Does anyone know if this code is still actually necessary? It seems it's been there a while. It's disappointing to not get full performance out of the hardware you have. Yes, that code is still necessary. There's a new aic7xxx driver by Justin Gibbs at Adaptec which is now being beta tested which corrects this issue. Something to note, however: the media transfer rate for those disks is at most ~20MB/sec. Actually, aren't a number of newer drives getting upwards of 30MB/s? Therefore, you only exceed the 80MB/sec bus speed if you have more than 4 disks all doing maximum I/O at the same time. Since the PowerApp.web 100 has at most 2 disks internally, you really shouldn't see any significant performance difference. Hope this helps. Thanks for buying Dell! Matt Domsch Dell Linux Systems Group Linux OS Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RESEND: [ PATCH ] externalize (new) scsi timer function
I sent this about a month ago. I think it's important. For what it's worth, Doug Gilbert (and Eric Youngdale) thought it was a good idea too. Can you please drop it in? - Late in the game, and possibly questionable, but it would be helpful to have the (new) scsi timer functions externalized so that loadable HBA modules can easily see them. This is needed because, particularly for Fibre Channel, it's only the HBA that knows when a command is actually sent to the device as opposed to being (temporarily) queued up locally while some Fibre Channel or SCSI reset wreckage is being cleared. The time limit for a command should be while it's actually active- not while it's waiting to be started. The alternative of returning commands as having not been queued doesn't work as well because of race conditions. You can, with several type os HBA, get cases of having queued up one or more commands and after returning success to the midlayer, still get an interrupt that says, "that command you thought I started? Ooops... Sorry. I lied. I couldn't get it started, but it's really okay to start it now...". At any rate- it's a minor change, which I've been using for a bit, which really only is an aid to the case that you have a loadable module that wants this symbol (natuarally, resident drivers don't care). The only real downside to any of this is that effectively use the scsi_add_timer to restart a timer is that you have to use a portion of the Scsi_Cmnd that is not marked as public. An alternative could be to change the midlayer to add a function to pause and restart the timer. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RESEND: [ PATCH ] externalize (new) scsi timer function
I sent this about a month ago. I think it's important. For what it's worth, Doug Gilbert (and Eric Youngdale) thought it was a good idea too. Can you please drop it in? - Late in the game, and possibly questionable, but it would be helpful to have the (new) scsi timer functions externalized so that loadable HBA modules can easily see them. This is needed because, particularly for Fibre Channel, it's only the HBA that knows when a command is actually sent to the device as opposed to being (temporarily) queued up locally while some Fibre Channel or SCSI reset wreckage is being cleared. The time limit for a command should be while it's actually active- not while it's waiting to be started. The alternative of returning commands as having not been queued doesn't work as well because of race conditions. You can, with several type os HBA, get cases of having queued up one or more commands and after returning success to the midlayer, still get an interrupt that says, "that command you thought I started? Ooops... Sorry. I lied. I couldn't get it started, but it's really okay to start it now...". At any rate- it's a minor change, which I've been using for a bit, which really only is an aid to the case that you have a loadable module that wants this symbol (natuarally, resident drivers don't care). The only real downside to any of this is that effectively use the scsi_add_timer to restart a timer is that you have to use a portion of the Scsi_Cmnd that is not marked as public. An alternative could be to change the midlayer to add a function to pause and restart the timer. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RESEND: [ PATCH ] externalize (new) scsi timer function
I sent this about a month ago. I think it's important. For what it's worth, Doug Gilbert thought it was a good idea too. Can you please reconsider and drop it in. - Late in the game, and possibly questionable, but it would be helpful to have the (new) scsi timer functions externalized so that loadable HBA modules can easily see them. This is needed because, particularly for Fibre Channel, it's only the HBA that knows when a command is actually sent to the device as opposed to being (temporarily) queued up locally while some Fibre Channel or SCSI reset wreckage is being cleared. The time limit for a command should be while it's actually active- not while it's waiting to be started. The alternative of returning commands as having not been queued doesn't work as well because of race conditions. You can, with several type os HBA, get cases of having queued up one or more commands and after returning success to the midlayer, still get an interrupt that says, "that command you thought I started? Ooops... Sorry. I lied. I couldn't get it started, but it's really okay to start it now...". At any rate- it's a minor change, which I've been using for a bit, which really only is an aid to the case that you have a loadable module that wants this symbol (natuarally, resident drivers don't care). The only real downside to any of this is that effectively use the scsi_add_timer to restart a timer is that you have to use a portion of the Scsi_Cmnd that is not marked as public. An alternative could be to change the midlayer to add a function to pause and restart the timer. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Platform string wrong for AlphaServer 400 4/233
Take it up with Compaq. The platform string value is that which is set in the HWRPB constructed with SRM. > > Hi, > > This is a minor issue, but I thought I'd report it anyway. > > When I do a > > # cat /proc/cpuinfo > > on my AlphaServer 400 4/233 I get the following (IMHO wrong) output: > > cpu : Alpha > cpu model : EV45 > cpu variation : 7 > cpu revision: 0 > cpu serial number : > system type : Avanti > system variation: 0 > system revision : 0 > system serial number: > cycle frequency [Hz]: 24892 est. > timer frequency [Hz]: 1024.00 > page size [bytes] : 8192 > phys. address bits : 34 > max. addr. space # : 63 > BogoMIPS: 229.11 > kernel unaligned acc: 0 (pc=0,va=0) > user unaligned acc : 0 (pc=0,va=0) > platform string : AlphaStation 400 4/233 > cpus detected : 1 > > > > The problem is that the 'Platform string' is set to 'AlphaStation 400 > 4/233' when this machine is quite clearly (it's printed on it) a > 'AlphaServer 400 4/233' ( It is this machine: > http://www5.compaq.com/alphaserver/archive/400/alphaserver400.html ). > > It's nothing important, and it runs Linux just fine. Just thought it > would be nice to see it fixed (if it is at all possible to tell the two > different systems apart from the kernels point of view). > > > Best regards, > Jesper Juhl > [EMAIL PROTECTED] > > > PS. Please CC all replies to me as I am not subscribed to the list. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ PATCH ] against 2.4.0-test13-pre3 - fixes builds for ALPHA
Hmm. Gotta build setup-*.c somehow. Alpha Config defines ALPHA_FOO (Generic or specific model #) but not vanilla alpha. --- linux.orig/arch/alpha/config.in Tue Dec 19 14:54:14 2000 +++ linux/arch/alpha/config.in Tue Dec 19 14:53:05 2000 @@ -4,6 +4,7 @@ # define_bool CONFIG_UID16 n +define_bool CONFIG_ALPHA y mainmenu_name "Kernel configuration of Linux for Alpha machines" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: QLogicFC problems with 2.4.x?
It does, but 2.4 alpha hasn't quite worked for me (the latest matrix of support for LINUX is below- and I haven't passed Michael Declerck's testing yet). I'll be checking the latest alpha bits this week some time and I still also need to finish the kernel thread work that will allow loop events to be down OOB. -- Linux Notes 2.0/2.1/2.3 support dropped. 2.0 support will be added back later, but basically, it'll be 2.0/2.2/2.4 only support. NOTE: SOME CHANGES ARE NOW REQUIRED IN A DEFAULT KERNEL BECAUSE WE NEED NOTE: SOME EXTRA SYMBOLS EXPORTED. SEE LINUX_BUILD INSTRUCTIONS. NOTE: AT THIS TIME YOU MUST BOOT 2.4/i386 WITH nmi_watchdog=0 NOTE: APPENDED TO THE BOOT COMMAND LINE. NOTE: TARGET MODE IS BROKEN IN LINUX RIGHT NOW This release has been tested agains: Alpha 2.2.17 [1] IA-32 2.2.17 2.4.0-test11 PowerPC 2.2.17 [2] Sparc64 2.2.17 2.4.0-test11 There are now patches agains 2.2.17 and 2.4.0-test11 in the linux subdirectory. Or you can build as a module in place in the linux directory. See LINUX_BUILD_INSTRUCTIONS. [1] 2.4.0-test11 panic'd and crashed and burned in readw for me. I think that this is a known alpha arch problem at this time, so I'm going to wait until 'they' fix it. [2] I can't find a complable 2.4 for PPC at the time of test1. -- On Tue, 19 Dec 2000, Robert Read wrote: > > The driver loads for me on 2.4 on Intel, but I don't have access to an > Alpha right now. Have you tried Mathew Jacob's driver? It looks like > it supports Alpha. > > http://www.feral.com/isp.html > > robert > > On Mon, Dec 18, 2000 at 04:24:38PM -0500, Peter Rival wrote: > > Hi, > > > >I was just lent a QLogic ISP2200 FC adapter and have been having a > > bear of a time trying to get it to work on my Alpha ES40 and GS80. I've > > tried both the qlogicfc (with standard kernel) and qla2x00 (from QLogic > > and Compaq) driver both built-in and as modules but neither of them are > > working. Has anyone had success with later (I'm using 2.4.0-test11) 2.4 > > kernels and the QLogic FC adapter? I'm currently plugged into a Brocade > > switch (Plaides I, I believe) which is also attached to two pair of > > HSG80 FC RAID controllers. AFAIK, the 2200 is supposed to work with an > > FC fabric, so this should work, right? Can anyone offer any > > assistance? Thanks! > > > > - Pete > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: QLogicFC problems with 2.4.x?
It does, but 2.4 alpha hasn't quite worked for me (the latest matrix of support for LINUX is below- and I haven't passed Michael Declerck's testing yet). I'll be checking the latest alpha bits this week some time and I still also need to finish the kernel thread work that will allow loop events to be down OOB. -- Linux Notes 2.0/2.1/2.3 support dropped. 2.0 support will be added back later, but basically, it'll be 2.0/2.2/2.4 only support. NOTE: SOME CHANGES ARE NOW REQUIRED IN A DEFAULT KERNEL BECAUSE WE NEED NOTE: SOME EXTRA SYMBOLS EXPORTED. SEE LINUX_BUILD INSTRUCTIONS. NOTE: AT THIS TIME YOU MUST BOOT 2.4/i386 WITH nmi_watchdog=0 NOTE: APPENDED TO THE BOOT COMMAND LINE. NOTE: TARGET MODE IS BROKEN IN LINUX RIGHT NOW This release has been tested agains: Alpha 2.2.17 [1] IA-32 2.2.17 2.4.0-test11 PowerPC 2.2.17 [2] Sparc64 2.2.17 2.4.0-test11 There are now patches agains 2.2.17 and 2.4.0-test11 in the linux subdirectory. Or you can build as a module in place in the linux directory. See LINUX_BUILD_INSTRUCTIONS. [1] 2.4.0-test11 panic'd and crashed and burned in readw for me. I think that this is a known alpha arch problem at this time, so I'm going to wait until 'they' fix it. [2] I can't find a complable 2.4 for PPC at the time of test1. -- On Tue, 19 Dec 2000, Robert Read wrote: The driver loads for me on 2.4 on Intel, but I don't have access to an Alpha right now. Have you tried Mathew Jacob's driver? It looks like it supports Alpha. http://www.feral.com/isp.html robert On Mon, Dec 18, 2000 at 04:24:38PM -0500, Peter Rival wrote: Hi, I was just lent a QLogic ISP2200 FC adapter and have been having a bear of a time trying to get it to work on my Alpha ES40 and GS80. I've tried both the qlogicfc (with standard kernel) and qla2x00 (from QLogic and Compaq) driver both built-in and as modules but neither of them are working. Has anyone had success with later (I'm using 2.4.0-test11) 2.4 kernels and the QLogic FC adapter? I'm currently plugged into a Brocade switch (Plaides I, I believe) which is also attached to two pair of HSG80 FC RAID controllers. AFAIK, the 2200 is supposed to work with an FC fabric, so this should work, right? Can anyone offer any assistance? Thanks! - Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ PATCH ] against 2.4.0-test13-pre3 - fixes builds for ALPHA
Hmm. Gotta build setup-*.c somehow. Alpha Config defines ALPHA_FOO (Generic or specific model #) but not vanilla alpha. --- linux.orig/arch/alpha/config.in Tue Dec 19 14:54:14 2000 +++ linux/arch/alpha/config.in Tue Dec 19 14:53:05 2000 @@ -4,6 +4,7 @@ # define_bool CONFIG_UID16 n +define_bool CONFIG_ALPHA y mainmenu_name "Kernel configuration of Linux for Alpha machines" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Platform string wrong for AlphaServer 400 4/233
Take it up with Compaq. The platform string value is that which is set in the HWRPB constructed with SRM. Hi, This is a minor issue, but I thought I'd report it anyway. When I do a # cat /proc/cpuinfo on my AlphaServer 400 4/233 I get the following (IMHO wrong) output: cpu : Alpha cpu model : EV45 cpu variation : 7 cpu revision: 0 cpu serial number : system type : Avanti system variation: 0 system revision : 0 system serial number: cycle frequency [Hz]: 24892 est. timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 34 max. addr. space # : 63 BogoMIPS: 229.11 kernel unaligned acc: 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : AlphaStation 400 4/233 cpus detected : 1 The problem is that the 'Platform string' is set to 'AlphaStation 400 4/233' when this machine is quite clearly (it's printed on it) a 'AlphaServer 400 4/233' ( It is this machine: http://www5.compaq.com/alphaserver/archive/400/alphaserver400.html ). It's nothing important, and it runs Linux just fine. Just thought it would be nice to see it fixed (if it is at all possible to tell the two different systems apart from the kernels point of view). Best regards, Jesper Juhl [EMAIL PROTECTED] PS. Please CC all replies to me as I am not subscribed to the list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ServerWorks docs?
Two points: > More important to me is ready access to technical documentation to support > machines at work. I come from the era when PDP-11's were shipped with > schematics, the OS, and the source to the OS. Things have been going The only source for the OS that came 'for free' that I can recall for the PDP-11 was RSX-11- but that was only the bare kernel. The filesystem and the utilities's source wwas not available. At that time, as you can probably well recall, the UNIX source licence from WECO was 40K$ for v7 at Sidereal. > downhill ever since. I'm not catching the next plane to the Bay Area > for "eyes only" examination of a document every time a problem arises. > In this regard, companies like IBM Storage and Intel win my kudos, Don't applaud either Intel or IBM too loudly. In particular, Intel. Just *try* and get documentation about their frickin' gigabit ethernet chip out of them. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ServerWorks docs?
Two points: More important to me is ready access to technical documentation to support machines at work. I come from the era when PDP-11's were shipped with schematics, the OS, and the source to the OS. Things have been going The only source for the OS that came 'for free' that I can recall for the PDP-11 was RSX-11- but that was only the bare kernel. The filesystem and the utilities's source wwas not available. At that time, as you can probably well recall, the UNIX source licence from WECO was 40K$ for v7 at Sidereal. downhill ever since. I'm not catching the next plane to the Bay Area for "eyes only" examination of a document every time a problem arises. In this regard, companies like IBM Storage and Intel win my kudos, Don't applaud either Intel or IBM too loudly. In particular, Intel. Just *try* and get documentation about their frickin' gigabit ethernet chip out of them. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
> > I don't know when the /proc stuff will return or what data will be > provided there. At the risk of tooting my own horn, you might put there that which I do for my Qlogic driver- it lists current perio/offset values per target and a list of currently running commands. It's very easy to support and very very useful. The old linux aic driver also had a bunch of stats (binned to size)- I believe I wrote that some years back- but that's not needed if you get Steve Tweedie's sar package. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
I don't know when the /proc stuff will return or what data will be provided there. At the risk of tooting my own horn, you might put there that which I do for my Qlogic driver- it lists current perio/offset values per target and a list of currently running commands. It's very easy to support and very very useful. The old linux aic driver also had a bunch of stats (binned to size)- I believe I wrote that some years back- but that's not needed if you get Steve Tweedie's sar package. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
> > > > On Fri, 8 Dec 2000, Alan Cox wrote: > > > > > > Yes, and I believe that this is what's broken about the SCSI midlayer. The the > > > > io_request_lock cannot be completely released in a SCSI HBA because the flags > > > > > > You can drop it with spin_unlock_irq and that is fine. I do that with no > > > problems in the I2O scsi driver for example > > > > I am (like, I think I *finally* got locking sorta right in my QLogic driver), > > but doesn't this still leave ints blocked for this CPU at least? > > spin_unlock_irq() does a __sti() > spin_unlock() doesn't. Umm. Okay, but you haven't changed your processor priority though, right? (I just don't *get* i386 stuff... I'll go off and ponder SParc code - & I understand). -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
> > I am actually concerned about the following case: > > The add_request ON CPU_1 function calls > spin_lock_irqsave(_request_lock,flags); > > Our I/O Function unlocks the spinlock and goes to sleep. > > Finally, the add_request function, NOW ON CPU_2 calls > spin_unlock_irqrestore(_request_lock,flags); > and restores the flags of CPU_1 on CPU_2. > > What am I missing? Are the flags which we restore valid for all the CPU's > the same? Absolutely not. They're state *for that CPU*. Before I gave up doing my own locking in my HBA, I was using flags in my softc, so I could do things like this in transitioning from an int svc routine to another module (in this case, a SCSI target mode handler): spinlock_irq_save(>isp_lk, isp->isp_lkflags); spinlock_irq_restore(>isp_lk, isp->isp_lkflags); spinlock_irq_save(>isp_lk, isp->isp_lkflags); spinlock_irq_restore(>isp_lk, isp->isp_lkflags); (return from interrupt) So, if you acquire the lock, the flags go with *that* CPU's acquisition of the lock. But that's dangerous in that you're passing the flags around to be possibly 'restored' (incorrectly) in some other context. That's why flags seems to be usually an auto variable construct. But what I still don't get is why it's okay to do a spin_unlock_irq on io_request_lock (because you don't have access to the flags that were locked with it (if any)) and not end up with a system that can deadlock. Well, enlightenment will come some day I'm sure. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
On Fri, 8 Dec 2000, Alan Cox wrote: > > Yes, and I believe that this is what's broken about the SCSI midlayer. The the > > io_request_lock cannot be completely released in a SCSI HBA because the flags > > You can drop it with spin_unlock_irq and that is fine. I do that with no > problems in the I2O scsi driver for example I am (like, I think I *finally* got locking sorta right in my QLogic driver), but doesn't this still leave ints blocked for this CPU at least? -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
> > spin_lock_irq(_request_lock); > > we finish the request and return to the add_request function which calls > > spin_unlock_irqrestore(_request_lock,flags); > > and restores the flags. > > > > Isn't it possible now that the flags which we restore are out of date now? > > Is this idiom the right one to use for 2.2? > > It is fine for 2.2 as well. > > The flags you restore are ok. It restores the interrupt state to the state it > was in when you were called. Think of save_flags/restore_flags as bracketing > regions of code (and being nestable in pairs). The only real bizarre rule is > that you cannot save_flags in one function and restore_flags in another without > upsetting DaveM - as it breaks on the sparc if you do that Yes, and I believe that this is what's broken about the SCSI midlayer. The the io_request_lock cannot be completely released in a SCSI HBA because the flags for that save are way up the stack somewhere. This means that if you need to, for example, sleep on something like loop coming up, you can spin_unlock_irq, but you can't restore flags, so for the UP case, you just hang. To avoid this, I'm having to build a kernel thread to handle all of this kind of stuff in a separate context. What a PITA. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
spin_lock_irq(io_request_lock); we finish the request and return to the add_request function which calls spin_unlock_irqrestore(io_request_lock,flags); and restores the flags. Isn't it possible now that the flags which we restore are out of date now? Is this idiom the right one to use for 2.2? It is fine for 2.2 as well. The flags you restore are ok. It restores the interrupt state to the state it was in when you were called. Think of save_flags/restore_flags as bracketing regions of code (and being nestable in pairs). The only real bizarre rule is that you cannot save_flags in one function and restore_flags in another without upsetting DaveM - as it breaks on the sparc if you do that Yes, and I believe that this is what's broken about the SCSI midlayer. The the io_request_lock cannot be completely released in a SCSI HBA because the flags for that save are way up the stack somewhere. This means that if you need to, for example, sleep on something like loop coming up, you can spin_unlock_irq, but you can't restore flags, so for the UP case, you just hang. To avoid this, I'm having to build a kernel thread to handle all of this kind of stuff in a separate context. What a PITA. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
On Fri, 8 Dec 2000, Alan Cox wrote: Yes, and I believe that this is what's broken about the SCSI midlayer. The the io_request_lock cannot be completely released in a SCSI HBA because the flags You can drop it with spin_unlock_irq and that is fine. I do that with no problems in the I2O scsi driver for example I am (like, I think I *finally* got locking sorta right in my QLogic driver), but doesn't this still leave ints blocked for this CPU at least? -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
I am actually concerned about the following case: The add_request ON CPU_1 function calls spin_lock_irqsave(io_request_lock,flags); Our I/O Function unlocks the spinlock and goes to sleep. Finally, the add_request function, NOW ON CPU_2 calls spin_unlock_irqrestore(io_request_lock,flags); and restores the flags of CPU_1 on CPU_2. What am I missing? Are the flags which we restore valid for all the CPU's the same? Absolutely not. They're state *for that CPU*. Before I gave up doing my own locking in my HBA, I was using flags in my softc, so I could do things like this in transitioning from an int svc routine to another module (in this case, a SCSI target mode handler): interrupt starts spinlock_irq_save(isp-isp_lk, isp-isp_lkflags); get stuff from response queue spinlock_irq_restore(isp-isp_lk, isp-isp_lkflags); call scsi_target_mode_handler spinlock_irq_save(isp-isp_lk, isp-isp_lkflags); reinstruct card spinlock_irq_restore(isp-isp_lk, isp-isp_lkflags); (return from interrupt) So, if you acquire the lock, the flags go with *that* CPU's acquisition of the lock. But that's dangerous in that you're passing the flags around to be possibly 'restored' (incorrectly) in some other context. That's why flags seems to be usually an auto variable construct. But what I still don't get is why it's okay to do a spin_unlock_irq on io_request_lock (because you don't have access to the flags that were locked with it (if any)) and not end up with a system that can deadlock. Well, enlightenment will come some day I'm sure. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: io_request_lock question (2.2)
On Fri, 8 Dec 2000, Alan Cox wrote: Yes, and I believe that this is what's broken about the SCSI midlayer. The the io_request_lock cannot be completely released in a SCSI HBA because the flags You can drop it with spin_unlock_irq and that is fine. I do that with no problems in the I2O scsi driver for example I am (like, I think I *finally* got locking sorta right in my QLogic driver), but doesn't this still leave ints blocked for this CPU at least? spin_unlock_irq() does a __sti() spin_unlock() doesn't. Umm. Okay, but you haven't changed your processor priority though, right? (I just don't *get* i386 stuff... I'll go off and ponder SParc code - that I understand). -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ PATCH ] externalize (new) scsi timer functions (fwd)
Late in the game, and possibly questionable, but it would be helpful to have the (new) scsi timer functions externalized so that loadable HBA modules can easily see them. This is needed because, particularly for Fibre Channel, it's only the HBA that knows when a command is actually sent to the device as opposed to being (temporarily) queued up locally while some Fibre Channel or SCSI reset wreckage is being cleared. The time limit for a command should be while it's actually active- not while it's waiting to be started. The alternative of returning commands as having not been queued doesn't work as well because of race conditions. You can, with several type os HBA, get cases of having queued up one or more commands and after returning success to the midlayer, still get an interrupt that says, "that command you thought I started? Ooops... Sorry. I lied. I couldn't get it started, but it's really okay to start it now...". At any rate- it's a minor change, which I've been using for a bit, which really only is an aid to the case that you have a loadable module that wants this symbol (natuarally, resident drivers don't care). The only real downside to any of this is that effectively use the scsi_add_timer to restart a timer is that you have to use a portion of the Scsi_Cmnd that is not marked as public. An alternative could be to change the midlayer to add a function to pause and restart the timer. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ PATCH ] externalize (new) scsi timer functions (fwd)
Late in the game, and possibly questionable, but it would be helpful to have the (new) scsi timer functions externalized so that loadable HBA modules can easily see them. This is needed because, particularly for Fibre Channel, it's only the HBA that knows when a command is actually sent to the device as opposed to being (temporarily) queued up locally while some Fibre Channel or SCSI reset wreckage is being cleared. The time limit for a command should be while it's actually active- not while it's waiting to be started. The alternative of returning commands as having not been queued doesn't work as well because of race conditions. You can, with several type os HBA, get cases of having queued up one or more commands and after returning success to the midlayer, still get an interrupt that says, "that command you thought I started? Ooops... Sorry. I lied. I couldn't get it started, but it's really okay to start it now...". At any rate- it's a minor change, which I've been using for a bit, which really only is an aid to the case that you have a loadable module that wants this symbol (natuarally, resident drivers don't care). The only real downside to any of this is that effectively use the scsi_add_timer to restart a timer is that you have to use a portion of the Scsi_Cmnd that is not marked as public. An alternative could be to change the midlayer to add a function to pause and restart the timer. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec F940
I believe that this is a precursor to the emerald chipset that Adaptec sold off to JNI. I've asked JNI whether their drivers would drive it but they did not deign to answer. > I looked around for a driver for the Apaptec F940 fibre channel > card... found nothing so far. It looks like the card works with I2O. I2O > requires a I2O motherboard, yes? If there is a web/ftp site that I > missed... please point me in the correct direction. > > ...Jeff > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec F940
I believe that this is a precursor to the emerald chipset that Adaptec sold off to JNI. I've asked JNI whether their drivers would drive it but they did not deign to answer. I looked around for a driver for the Apaptec F940 fibre channel card... found nothing so far. It looks like the card works with I2O. I2O requires a I2O motherboard, yes? If there is a web/ftp site that I missed... please point me in the correct direction. ...Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OnStream SCSI tape driver osst
>(There is a second generation drive, ADR-x0, which has a much more advanced > firmware and does fully comply with SCSI-2 spec, BTW.) 'fully'? Not. This latter drive has had problems too, but it seems to me that the arrival of the ADR-50 should preclude the need to support the ADR-30. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OnStream SCSI tape driver osst
(There is a second generation drive, ADR-x0, which has a much more advanced firmware and does fully comply with SCSI-2 spec, BTW.) 'fully'? Not. This latter drive has had problems too, but it seems to me that the arrival of the ADR-50 should preclude the need to support the ADR-30. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FreeBSD's new zero-copy networking
> > When transferring one or more pages via a page-alligned > > buffer and normal read() or write(), VM tricks will be > > used to avoid copying the data. If you touch the page > > You mean mmap(). You can do that already but it isnt the win you might > think. In fact for some operations mmap is slower just due to the mmu bashing > overhead and TLB misses. > > Its non intuitive that mmu operations cost more than a bulk copy but its > frequently the case. sendfile() works nicely because it is working on data > that isnt user mapped. O_DIRECT raw I/O has overheads too and its not clear > where the break even points are Yup. That's true. Like it's also nonintuitive sometimes that PIO can even beat, in some cases, DMA (some graphics fifo devices, e.g.). > > > They've gotten 960 megabits/sec out of a gigabit Ethernet card > > with this. Not stable yet. > > I think Jes was getting this in Linux TCP/IP without zero copy. What was the CPU utilization? -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FreeBSD's new zero-copy networking
> > > > Also Andrew Gallatin got this speed with Trapeze && GigE cards about a year > > ago as well. > > > > It's not so much the 960Mbit (or better, actually, which you can get depending > > on the card). It's how much CPU you eat up doing so. You of all people should > > know that, Larry :-). > > Yeah, I do know it. I think FreeBSD reinventing what SGI did is stupid. > As soon as you get rid of the copy as the issue the VM maps/unmaps become > the issue. So they are inching closer to the next problem. Take a look at > Stephen Tweedies kio bufs, that's better. You can read a little about them > at ftp.bitmover.com://pub/splice.ps, that's where they came from. Umm. Yes, that argument has merit. But what it does do, which is almost as important as the performance issue itself, is to ready the networking stack for these kind of callout types of tricks. Then you could do something like kiobufs, or the stream head allocator loanout stuff that's been yityatted about for so long. Of course, I also would prefer to use splice! Now *that'd* torpedo this VI foolishness -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FreeBSD's new zero-copy networking
> > They've gotten 960 megabits/sec out of a gigabit Ethernet card > > with this. Not stable yet. > > Didn't daveme get the same speed using Linux almost a year ago? Also Andrew Gallatin got this speed with Trapeze && GigE cards about a year ago as well. It's not so much the 960Mbit (or better, actually, which you can get depending on the card). It's how much CPU you eat up doing so. You of all people should know that, Larry :-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
QLC: Driver Update (fwd)
-- Forwarded message -- Date: Fri, 15 Sep 2000 19:00:06 -0700 From: April Dunbar <[EMAIL PROTECTED]> To: April Dunbar <[EMAIL PROTECTED]> Subject: QLC: Driver Update Good Afternoon, I would like to advise that we have posted the following new driver to our website. Thank you, April Dunbar QLA2x00 REDHAT LINUS v6.2/2.23 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
QLC: Driver Update (fwd)
-- Forwarded message -- Date: Fri, 15 Sep 2000 19:00:06 -0700 From: April Dunbar [EMAIL PROTECTED] To: April Dunbar [EMAIL PROTECTED] Subject: QLC: Driver Update Good Afternoon, I would like to advise that we have posted the following new driver to our website. Thank you, April Dunbar QLA2x00 REDHAT LINUS v6.2/2.23 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, David S. Miller wrote: >Date: Wed, 13 Sep 2000 18:00:02 -0700 (PDT) >From: Matthew Jacob <[EMAIL PROTECTED]> > >This seems to be an artifact of some OBP implementations for PPC- >apples in particular. > >It assigns both I/O and Mem addrs and IRQs, but doesn't enable >either memory or I/O. So you have to do it for it. > > Yeah, but this doesn't belong in the drivers that is for sure. > > It belongs in arch/ppc/kernel/*pci*.c > > This is precisely the kind of compat stuff which should be fixed up in > the arch-specific PCI support code. I couldn't agree more. However- I can only write the bits for my driver and maybe *suggest* stuff to the PPC maintainers (I'm relatively new to having a PPC to play with). -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
This seems to be an artifact of some OBP implementations for PPC- apples in
particular.
It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory
or I/O. So you have to do it for it.
On Wed, 13 Sep 2000, Andre Hedrick wrote:
>
> Okay who can teach me how to force hooks and ram this down the PPC
>
> pci_write_config_word(dev, PCI_COMMAND, 0x05);
>
> I have all the address registered.
> My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> alive. Thus I get some of the most beuatiful lockups ever.
> I suspect that this needs to be handled down in the arch.
>
> ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
>
> Basically I can not get the IO's active, regardless of BIOS on the card.
> Yes this is the old trick that used to work of making ix86 cards run in
> non ix86-pci slots.
>
> Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> under Mac OS, but the IO's are not enable in linux and it crash like a big
> dog also.
>
> Cheers,
>
>
> Andre Hedrick
> The Linux ATA/IDE guy
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, 13 Sep 2000, David S. Miller wrote: Date: Wed, 13 Sep 2000 18:00:02 -0700 (PDT) From: Matthew Jacob [EMAIL PROTECTED] This seems to be an artifact of some OBP implementations for PPC- apples in particular. It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory or I/O. So you have to do it for it. Yeah, but this doesn't belong in the drivers that is for sure. It belongs in arch/ppc/kernel/*pci*.c This is precisely the kind of compat stuff which should be fixed up in the arch-specific PCI support code. I couldn't agree more. However- I can only write the bits for my driver and maybe *suggest* stuff to the PPC maintainers (I'm relatively new to having a PPC to play with). -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
> > > > Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back > > at Auspex in '93. ...Guess the compiler driver has gotten smarter since. > > You know how it goes- you do a trick once- you don't change it for years... > > According to the ChangeLog of the 2.7.2.3 compiler, Doug Evans added it in > March of 1995. ow. ow. ow. Okay. got it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
> > Or use --print-libgcc-file-name: > > `gcc --print-libgcc-file-name` > > where are the options normally used to compile code (ie, for example > on machines that optionally do not have a floating point use, adding > -msoft-float would select the libgcc.a that was compiled with -msoft-float). Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back at Auspex in '93. ...Guess the compiler driver has gotten smarter since. You know how it goes- you do a trick once- you don't change it for years... > > > That is, unless somebody wants to write the support functions (specific to > > gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so.. > > Other than division, most of the 64 bit support functions are fairly easy to > write. Obviously, if you do this and gcc 7.0 changes the interface to call > different functions, you are hosed. That's the point. The support routines are paired with the compiler, not the kernel. And the support routines have to be able to link with the kernel. Having 20 different kernel platforms duplicate code already in libgcc.a is silly unless the code in libgcc.a is so bad for the kernel that you have to do otherwise. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
> On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote: > > So what do you propose to use when a long long division is needed (after > > much thought and considering all alternatives etc.etc.) ? > > Link against libgcc, what else? As also does anyone who does solaris drivers (x86 or sparc) using gcc- the code that gcc emits that requires 64 bit operations is quite nicely available in libgcc.a. Only a minor bit of hackage with gcc -v is needed in a makefile to emit the correct path for the linker to use. That is, unless somebody wants to write the support functions (specific to gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so.. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote: So what do you propose to use when a long long division is needed (after much thought and considering all alternatives etc.etc.) ? Link against libgcc, what else? As also does anyone who does solaris drivers (x86 or sparc) using gcc- the code that gcc emits that requires 64 bit operations is quite nicely available in libgcc.a. Only a minor bit of hackage with gcc -v is needed in a makefile to emit the correct path for the linker to use. That is, unless somebody wants to write the support functions (specific to gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so.. -matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back at Auspex in '93. ...Guess the compiler driver has gotten smarter since. You know how it goes- you do a trick once- you don't change it for years... According to the ChangeLog of the 2.7.2.3 compiler, Doug Evans added it in March of 1995. ow. ow. ow. Okay. got it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
> Some underlying block device subsystems can address that > currently, some others have inherent 512 byte "page_size" > with signed indexes... I think SCSI is in the first camp, > while IDE is in second. (And Ingo has assured us that RAID > code should handle this just fine too.) You can change logical block size on SCSI disk devices such that you won't be limited to a 1TB (512 byte logical blocksize) limit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
