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
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
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/
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/
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/
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
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
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)
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
-- 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,
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
(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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
'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
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
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
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
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
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
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 @@
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
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 "J
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_
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"
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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/
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/
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...
> >
>
'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
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
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
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
>
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
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
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
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
> 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
> 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
>
> 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
> >
> > 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
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
-- 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,
> > 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
> >
> > 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 :-).
> > 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
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
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 @@
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
> > 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
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
>
> 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
>
> >
> > 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
>
> 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
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
>(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
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
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
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
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)
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
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
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).
&
> 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,
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"
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
> 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
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
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
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
> 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
> > 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
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
> 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
>
100 matches
Mail list logo
