On May 24, 2007, at 10:51 PM, Andi Kleen wrote:
Do we have a feel for how much performace we're losing on those
systems which _could_ do MSI, but which will end up defaulting
to not using it?
At least on 10GB ethernet it is a significant difference; you usually
cannot go anywhere near line
On May 24, 2007, at 10:51 PM, Andi Kleen wrote:
Do we have a feel for how much performace we're losing on those
systems which _could_ do MSI, but which will end up defaulting
to not using it?
At least on 10GB ethernet it is a significant difference; you usually
cannot go anywhere near line
On Apr 15, 2007, at 10:59 AM, Linus Torvalds wrote:
It's a really good thing, and it means that if somebody shows that
your
code is flawed in some way (by, for example, making a patch that
people
claim gets better behaviour or numbers), any *good* programmer that
actually cares about his
On Apr 15, 2007, at 10:59 AM, Linus Torvalds wrote:
It's a really good thing, and it means that if somebody shows that
your
code is flawed in some way (by, for example, making a patch that
people
claim gets better behaviour or numbers), any *good* programmer that
actually cares about his
audio use.
This is a desktop board, and this is well after boot (hours). Also,
ACPI is disabled in the BIOS.
I suppose I can try to disable SMI via the APIC?
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
use.
This is a desktop board, and this is well after boot (hours). Also,
ACPI is disabled in the BIOS.
I suppose I can try to disable SMI via the APIC?
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
ens at about 5 Hz. And the characteristic
delay on each type of machine seems consistent.
Any ideas of where to look? Other lists to inquire on?
Thanks.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
>assumed that it was sent clear text. Obviously not.
Eudora does leave you one little clue:
At 2:19 AM +0100 2001-07-20, Anton Altaparmakov wrote:
>MIME-Version: 1.0
>Content-Type: MULTIPART/MIXED;
>BOUNDARY="-559023410-1804928587-995591940=:20239"
--
/Jonathan Lundell.
-
To unsubscrib
clear text. Obviously not. Stupid mailers. Grr.
Eudora does leave you one little clue:
At 2:19 AM +0100 2001-07-20, Anton Altaparmakov wrote:
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
BOUNDARY=-559023410-1804928587-995591940=:20239
--
/Jonathan Lundell.
-
To unsubscribe from this list
ng cpio archive layout is OK, but _please_, don't make it dependent
>on GNU cpio.
If size is an issue (and of course it is), presumably the archive
would be compressed. As long as tar can be convinced to pad with
(say) nulls, the padding shouldn't have that much of an impact on
archive size.
-
be compressed. As long as tar can be convinced to pad with
(say) nulls, the padding shouldn't have that much of an impact on
archive size.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
At 10:07 AM +0200 2001-06-27, Martin Wilck wrote:
>On Tue, 26 Jun 2001, Jonathan Lundell wrote:
>
>> I use the hack myself, to implement a record-oriented file where the
>> file position is a record number. I could probably live with
>> PAGE_SIZE, but the current ha
At 10:07 AM +0200 2001-06-27, Martin Wilck wrote:
On Tue, 26 Jun 2001, Jonathan Lundell wrote:
I use the hack myself, to implement a record-oriented file where the
file position is a record number. I could probably live with
PAGE_SIZE, but the current hack works fine with start bigger than
guys were generally attached to
mainframes, IBM or otherwise. Here's a little info:
http://www.digital-interact.co.uk/site/html/reference/media_9trk.html
(but take it with a grain of salt; IBM surely didn't go to nine
tracks because of ASCII!).
--
/Jonathan Lundell.
-
To unsubscribe from this l
if (n == 0) {
> if (retval == 0)
> retval = -EFAULT;
> break;
> }
>
>- *ppos += start < page ? (long)start : n; /* Move down
>the file */
>+ *ppos += (unsigned long)
the White House." Years later, two old-timers claimed they had
>heard Lincoln say it in an 1856 address in Illinois, but a news
>account of the speech didn't mention it. The Fehrenbachers give the
>old-timers' recollections a D. The evidence, the scholars say,
>"suggests th
ln say that? :)
That's the common, but doubtful, attribution.
--
/Jonathan Lundell.
-
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/
, but doubtful, attribution.
--
/Jonathan Lundell.
-
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/
: n; /* Move down
the file */
+ *ppos += (unsigned long) start PAGE_SIZE ?
(unsigned long) start : n; /* Move down the file */
nbytes -= n;
buf += n;
retval += n;
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line
or otherwise. Here's a little info:
http://www.digital-interact.co.uk/site/html/reference/media_9trk.html
(but take it with a grain of salt; IBM surely didn't go to nine
tracks because of ASCII!).
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
' recollections a D. The evidence, the scholars say,
suggests that this is a case of reminiscence echoing folklore or
fiction.
--
/Jonathan Lundell.
-
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
cally routed (eg round-robin).
Where can I find the 5.05 driver?
--
/Jonathan Lundell.
-
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/
and?
There can't, of course, be any blanket prohibition against using
kernel headers in userland. Think about ioctl.h, for example.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
prohibition against using
kernel headers in userland. Think about ioctl.h, for example.
--
/Jonathan Lundell.
-
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
arrive.
The other CPU servicing the interrupt, was the question. cli()
doesn't affect that. This could presumably happen if shutdown() gets
run on a non-interrupt-servicing CPU, or if interrupts are
dynamically routed (eg round-robin).
Where can I find the 5.05 driver?
--
/Jonathan Lundell
ons. At this
>point you get into law and the like and its probably best you read up on it
>from a reputable source not l/k
Though header files don't fall clearly on the interface-definition
side of the line. ctype.h, for example, in userland, or any other
header with #defined or i
and the like and its probably best you read up on it
from a reputable source not l/k
Though header files don't fall clearly on the interface-definition
side of the line. ctype.h, for example, in userland, or any other
header with #defined or inline code.
--
/Jonathan Lundell.
-
To unsubscribe
ion) significantly more expensive than on most other
architectures.
--
/Jonathan Lundell.
-
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 th
expensive than on most other
architectures.
--
/Jonathan Lundell.
-
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/
patch2:
>@@ 10,1 10,2 @@
> #include
>+#include <2.h>
>
>The patch will fail to patch :-). But there is no real conflict between
>the patches.
Problem is, you can't tell automatically. Even if the diffs don't
conflict physically, it's entirely possible that they confl
+#include 2.h
The patch will fail to patch :-). But there is no real conflict between
the patches.
Problem is, you can't tell automatically. Even if the diffs don't
conflict physically, it's entirely possible that they conflict
logically.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send
orced
>to implement it...
That's right, of course. A small problem is that dev->slot_name
becomes ambiguous, since it doesn't have any hose identification. Nor
does it have any room for the hose id; it's fixed at 8 chars, and
fully used (bb:dd.f\0).
--
/Jonathan Lundell.
-
To unsubscribe from
right, of course. A small problem is that dev-slot_name
becomes ambiguous, since it doesn't have any hose identification. Nor
does it have any room for the hose id; it's fixed at 8 chars, and
fully used (bb:dd.f\0).
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe
iferation of ioctls. Sure, it's non-standard
and a mess. But it's semi-documented, easy to use, and v. general.
What's the preferred alternative, to state the first question another
way? For any single small project/driver, creating a new fs simply
isn't going to happen.
--
/Jonathan Lundell.
to use, and v. general.
What's the preferred alternative, to state the first question another
way? For any single small project/driver, creating a new fs simply
isn't going to happen.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
At 1:38 AM +0100 2001-05-31, Joel Becker wrote:
>On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
>> FWIW (perhaps not much in this context), the POSIX way is
>>sysconf(_SC_CLK_TCK)
>>
>> POSIX sysconf is pretty useful for this kind of
in this context), the POSIX way is sysconf(_SC_CLK_TCK)
POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
sysconf is pretty useful for this kind of thing (not just HZ, either).
--
/Jonathan Lundell.
-
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 1:38 AM +0100 2001-05-31, Joel Becker wrote:
On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
FWIW (perhaps not much in this context), the POSIX way is
sysconf(_SC_CLK_TCK)
POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
Well, how
potential
benefit of having the stack at the bottom rather than the top of a
page.
--
/Jonathan Lundell.
-
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-i
of having the stack at the bottom rather than the top of a
page.
--
/Jonathan Lundell.
-
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
At 5:56 PM +0200 2001-05-24, Andi Kleen wrote:
>On Thu, May 24, 2001 at 08:50:04AM -0700, Jonathan Lundell wrote:
> > At 10:31 AM +0200 2001-05-24, Andi Kleen wrote:
>> >reiserfs doesn't, but the HD usually has transparently in its firmware.
>> >So it hits a bad
orted from your disk
>it's long overdue for replacement.
This can't be right. It implies that the drive is returning bogus
data with no error indication. Remapping a bad sector is not the same
as recovering it.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "u
way too much chance that a system
will read the remapped sector and assume that it contains the
original data. That would be hopelessly corrupting.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
it's long overdue for replacement.
This can't be right. It implies that the drive is returning bogus
data with no error indication. Remapping a bad sector is not the same
as recovering it.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
that a system
will read the remapped sector and assume that it contains the
original data. That would be hopelessly corrupting.
--
/Jonathan Lundell.
-
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
At 5:56 PM +0200 2001-05-24, Andi Kleen wrote:
On Thu, May 24, 2001 at 08:50:04AM -0700, Jonathan Lundell wrote:
At 10:31 AM +0200 2001-05-24, Andi Kleen wrote:
reiserfs doesn't, but the HD usually has transparently in its firmware.
So it hits a bad block; you see an IO error and the next
he PCI
>card sniffs the DMA controller setup (as it goes to pci, then when nobody
>claims it on to the isa bridge) then does bus mastering DMA of its own to fake
>the ISA dma
That's sick.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
At 2:02 PM -0700 2001-05-22, Richard Henderson wrote:
>On Tue, May 22, 2001 at 01:48:23PM -0700, Jonathan Lundell wrote:
>> 64KB for 8-bit DMA; 128KB for 16-bit DMA. [...] This doesn't
>> apply to bus-master DMA, just the legacy (8237) stuff.
>
>Would this 8237 be some
the address lives in a non-counting
register). This doesn't apply to bus-master DMA, just the legacy
(8237) stuff. There was also a 24-bit address limitation.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
es saturated in both
directions (all ignoring overhead). Full saturation is not reasonable
for either PCI or Ethernet; I'm just looking at order-of-magnitude
numbers here.
The bottom line is: don't make any hard and fast assumption about the
number of devices connected to a root PCI bus.
--
/Jo
overhead). Full saturation is not reasonable
for either PCI or Ethernet; I'm just looking at order-of-magnitude
numbers here.
The bottom line is: don't make any hard and fast assumption about the
number of devices connected to a root PCI bus.
--
/Jonathan Lundell.
-
To unsubscribe from this list
nobody
claims it on to the isa bridge) then does bus mastering DMA of its own to fake
the ISA dma
That's sick.
--
/Jonathan Lundell.
-
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
At 2:02 PM -0700 2001-05-22, Richard Henderson wrote:
On Tue, May 22, 2001 at 01:48:23PM -0700, Jonathan Lundell wrote:
64KB for 8-bit DMA; 128KB for 16-bit DMA. [...] This doesn't
apply to bus-master DMA, just the legacy (8237) stuff.
Would this 8237 be something on the ISA card
register). This doesn't apply to bus-master DMA, just the legacy
(8237) stuff. There was also a 24-bit address limitation.
--
/Jonathan Lundell.
-
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
this is true for many/most multiple-device cards), has a
bridge, its own internal PCI bus, and four "slots" ("devices" in PCI
terminology).
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
internal PCI bus, and four slots (devices in PCI
terminology).
--
/Jonathan Lundell.
-
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
At 2:16 AM +1200 2001-05-21, Chris Wedgwood wrote:
>On Sat, May 19, 2001 at 10:36:14AM -0700, Jonathan Lundell wrote:
>
> I know from system documentation, or can figure out once and for
> all by experimentation, the correspondence between PCI
> bus/dev/fcn and phy
At 3:37 AM -0600 2001-05-20, Eric W. Biederman wrote:
>Jonathan Lundell <[EMAIL PROTECTED]> writes:
>
>> At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
>> > > Jeff Garzik's ethtool
>> > > extension at least tells me the PCI bus/dev/fcn,
At 3:37 AM -0600 2001-05-20, Eric W. Biederman wrote:
Jonathan Lundell [EMAIL PROTECTED] writes:
At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
Jeff Garzik's ethtool
extension at least tells me the PCI bus/dev/fcn, though, and from
that I can write a userland mapping
At 2:16 AM +1200 2001-05-21, Chris Wedgwood wrote:
On Sat, May 19, 2001 at 10:36:14AM -0700, Jonathan Lundell wrote:
I know from system documentation, or can figure out once and for
all by experimentation, the correspondence between PCI
bus/dev/fcn and physical locations. Jeff's
is to replug correctly, not to change MAC addresses.
--
/Jonathan Lundell.
-
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/
lets you do that.
I know from system documentation, or can figure out once and for all
by experimentation, the correspondence between PCI bus/dev/fcn and
physical locations. Jeff's extension gives me the mapping between
eth# and PCI bus/dev/fcn, which is not otherwise available (outside
the
the MAC address.
If I plug both into the same network segments by accident (because I
can't tell which is which, say), then my configuration is nearly as
broken with different MAC addresses as with identical ones; the fix
is to replug correctly, not to change MAC addresses.
--
/Jonathan Lundell
documentation, or can figure out once and for all
by experimentation, the correspondence between PCI bus/dev/fcn and
physical locations. Jeff's extension gives me the mapping between
eth# and PCI bus/dev/fcn, which is not otherwise available (outside
the kernel).
--
/Jonathan Lundell
he multi-pathing level, seems exactly right. I'm
guessing that provision needs to be made for some
external-device-dependent means of signalling both failure and
recovery. There are potentially side-channel/out-of-band means to
communicate this kind of status from specific devices.
--
/Jonathan L
and
recovery. There are potentially side-channel/out-of-band means to
communicate this kind of status from specific devices.
--
/Jonathan Lundell.
-
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
At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Jonathan Lundell) wrote on 15.05.01 in
><p05100316b7272cdfd50c@[207.213.214.37]>:
>
>> What about:
>>
>> 1 (network domain). I have two network interfaces that I connect to
>> two
At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
[EMAIL PROTECTED] (Jonathan Lundell) wrote on 15.05.01 in
p05100316b7272cdfd50c@[207.213.214.37]:
What about:
1 (network domain). I have two network interfaces that I connect to
two different network segments, eth0 eth1; they're
ally) changed? I'd expect the answer to be: for
all practical purposes never.
--
/Jonathan Lundell.
-
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-inf
At 4:57 PM +0200 2001-05-16, Vojtech Pavlik wrote:
>On Wed, May 16, 2001 at 07:37:45AM -0700, Jonathan Lundell wrote:
>> At 10:02 AM +0200 2001-05-16, Vojtech Pavlik wrote:
>> > > It's also true that some buses simply don't yield up physical
>> >>
)? Removable media from another OS? Shared drives?
Not that this kind of "firm" ID might not be an improvement, or at
least a good sanity check.
[Side question, not original with me: why isn't all this a 2.5 discussion?]
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the l
have to experiment or remove a card and check the jumpering or
some such.
--
/Jonathan Lundell.
-
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
-> bus location <-> physical location <-> MAC address) in a
uniform manner. (Where MAC address might be something else in a
non-Ethernet domain.)
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
be something else in a
non-Ethernet domain.)
--
/Jonathan Lundell.
-
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/
or remove a card and check the jumpering or
some such.
--
/Jonathan Lundell.
-
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
from another OS? Shared drives?
Not that this kind of firm ID might not be an improvement, or at
least a good sanity check.
[Side question, not original with me: why isn't all this a 2.5 discussion?]
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
At 4:57 PM +0200 2001-05-16, Vojtech Pavlik wrote:
On Wed, May 16, 2001 at 07:37:45AM -0700, Jonathan Lundell wrote:
At 10:02 AM +0200 2001-05-16, Vojtech Pavlik wrote:
It's also true that some buses simply don't yield up physical
locations (ISA springs to mind,
ISA is quite fine
to be: for
all practical purposes never.
--
/Jonathan Lundell.
-
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/
text. Or aren't labelled at all. I'm using one
fairly well-known dual-port PCI serial board that silently
interchanged the two ports on a rev change, with no labelling change
at all ('cause there was no label!). Make your ttySx match *that*!
--
/Jonathan Lundell.
-
To unsubscribe from this list
tity
> configure $i
> done
...it's just that right now the connection between eth* and its
physical identity isn't made.
--
/Jonathan Lundell.
-
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/
g a system and *want* to renumber things. (There are
magic ways to do it, though).
That's all Solaris 2.6; not sure about 2.8.
--
/Jonathan Lundell.
-
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/
n/etc paths are not
physical locations; you also need external hardware-specific
knowledge to be able to talk about real physical locations in a way
that does the system operator any good.)
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
ep() asm("movb $0x3,%al; outb %al,$0x61")
Let's please not assume that every i386 implementation has a full set
of legacy PC IO hardware.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
that every i386 implementation has a full set
of legacy PC IO hardware.
--
/Jonathan Lundell.
-
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
-specific
knowledge to be able to talk about real physical locations in a way
that does the system operator any good.)
--
/Jonathan Lundell.
-
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
; not sure about 2.8.
--
/Jonathan Lundell.
-
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/
networking
for i in eth0 eth1 eth2; do
identify device $i
get configuration/config procedure for device $i identity
configure $i
done
...it's just that right now the connection between eth* and its
physical identity isn't made.
--
/Jonathan Lundell.
-
To unsubscribe
PCI serial board that silently
interchanged the two ports on a rev change, with no labelling change
at all ('cause there was no label!). Make your ttySx match *that*!
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
>why creat doesn't end in an "e;" and so forth. I tell the
Some time back, Ken Thompson was asked, if he had it to do over
again, what changes he would make to Unix. The only thing he could
think of: spell it "create()".
--
/Jonathan Lundell.
-
To unsubscribe from t
ion. I assert that ENOIOCTLCMD is
>> redundant, pending a specific counterexample.
>
>On the contrary. I can now no longer force an unsupported response when there
>is a generic routine I dont wish to use
That makes sense. Thanks.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send th
ENOIOCTLCMD/ENOTTY/ (mutatis mutandis)
would result in no loss of function. I assert that ENOIOCTLCMD is
redundant, pending a specific counterexample.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
swim3.cSat May 12 15:22:30 2001
>@@ -848,7 +848,7 @@
> sizeof(struct floppy_struct));
> return err;
> }
>- return -ENOIOCTLCMD;
>+ return -ENOTTY;
> }
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux
floppy_struct));
return err;
}
- return -ENOIOCTLCMD;
+ return -ENOTTY;
}
--
/Jonathan Lundell.
-
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
of function. I assert that ENOIOCTLCMD is
redundant, pending a specific counterexample.
--
/Jonathan Lundell.
-
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
, pending a specific counterexample.
On the contrary. I can now no longer force an unsupported response when there
is a generic routine I dont wish to use
That makes sense. Thanks.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
why creat doesn't end in an e; and so forth. I tell the
Some time back, Ken Thompson was asked, if he had it to do over
again, what changes he would make to Unix. The only thing he could
think of: spell it create().
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line
'you handle it'
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
/
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/
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
t;#define ERESTARTNOINTR 513
>#define ERESTARTNOHAND 514 /* restart if no handler.. */
>#define ENOIOCTLCMD515 /* No ioctl command */
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
1 - 100 of 162 matches
Mail list logo
