Hi,
I have discovered that my previous problem with immediate lockups of all
kernels versioon >2.4.3 is USB and/or sound-related. My computer currently
has onte internal soundcard (awe64) that is not used, and an external USB
D/A. Playing a sound with the internal soundcard (cat whatever >
/dev/s
Jonathan Morton <[EMAIL PROTECTED]>:
> I'm going to assume for now that CML2 saves two files - one storing a
> relatively small number of symbols (which is strictly limited to those
> explicitly set by the user), and one containing the full set for
> consumption by the Makefiles.
No, that's not t
Hi,
I searched the lkml for previous reports of this error, and I've found a few
questions asked, but no real answer given. I'm not looking for a quick
answer, but this just seems to be an issue that hasn't been touched on much.
Any thoughts (and solutions) would be greatly appreciated.
I'm cc'
> They are entirely different. Too different sets of operations.
Maybe you didnt understand what I meant.
both bdev and cdev take care of the correspondence
device number <---> struct with operations.
The operations are different, but all bdev/cdev code is identical.
So the choice is between tw
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, or something on
the old pc mainboards? I'm wondering if we can
Hi!
> > > [..] Even sparc64's fancy
> > > iommu-based pci_map_single() always succeeds.
> >
> > Whatever sparc64 does to hide the driver bugs you can break it if you
> > pci_map 4G+1 bytes of phyical memory.
>
> Which is an utterly stupid thing to do.
>
> Please construct a plausable sit
Hi!
> > I've seen this question several times in this thread. I haven't seen the
> > obvious answer, though.
> >
> > Have a new system call:
> >
> > ctlfd = open_device_control_fd(fd);
> >
> > If fd is something that doesn't have a control interface (say, it already
> > is a control fileha
Hello All,
I will be using Linux as the OS for an embedded system.
I was looking into 2.4.4 kernel code and saw the dcache implementation
in VFS which is pretty neat and fast by itself.
My question is, will I gain any considerable efficiency in file system
access
if I can move this "pathn
[EMAIL PROTECTED] wrote:
>
> > They are entirely different. Too different sets of operations.
>
> Maybe you didnt understand what I meant.
> both bdev and cdev take care of the correspondence
> device number <---> struct with operations.
>
> The operations are different, but all bdev/cdev code
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
Rather than starting to propogate these fixes to other drivers I'd be
greatful if they would audit the changes (especially the so
In article <[EMAIL PROTECTED]> you wrote:
> On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
>> Before you give up on the xircom thing, try the -ac kernel and set the box
>> up to use xircom_cb not xircom_tulip_cb
>>
>> That might help a lot
> It doesn't, it still p
Martin Dalecki writes:
> I fully agree with you.
Good.
Unfortunately I do not fully agree with you.
> Most of the places where there kernel is passing kdev_t
> would be entierly satisfied with only the knowlendge of
> the minor number.
My kdev_t is a pointer to a structure with device data
an
I have an analog joystick plugged into the gameport of a Soundblaster
AWE64. In 2.4.4-ac12 this was recognized and worked just fine. Under
ac13 the recognition is incomplete - it seems to identify that there
is a NS558 gameport device present, but not that there is a joystick
plugged into it (un
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > I fully agree with you.
>
> Good.
>
> Unfortunately I do not fully agree with you.
>
> > Most of the places where there kernel is passing kdev_t
> > would be entierly satisfied with only the knowlendge of
> > the minor number.
>
> My
Alan Cox <[EMAIL PROTECTED]> écrit :
[...]
> o Add missing locking to stradis driver (me)
- unbalanced returns after down();
- 1770: if the initial version isn't racy with saa7146_irq (line 534), this
one is equivalent and shorter.
init_saa7146:2185
if ((saa->dmadebi = km
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
> This sounds like a bug I have heard before: some switches don't work with
> the xircom card (well, our drivers for it) when doing full duplex.
> Could you try the latest driver from
>
> http://people.redhat.com/arjanv
>
> which forces the card to
Martin Dalecki writes:
> Erm... I wasn't talking about the DESIRED state of affairs!
> I was talking about the CURRENT state of affairs. OK?
Oh, but in 1995 it was quite possible to compile the kernel
with kdev_t a pointer type, and I have done it several times since.
The kernel keeps growing,
I'm trying to call ioremap fairly early on in kernel init (and it
doesn't work ;-) )
What setup functions have to run before ioremap() will work?
I can debug exactly what it's doing now if I have to, but I
don't suspect it'll tell me much ... I'm calling from aroung
console_init in start_kernel
On Mon, 21 May 2001, Xuan Baldauf wrote:
> That is annoying, because it heavily slows down bulk transfers of small
> writes, like automatically unzipping a new mozilla build from the linux box to
> the windows box. Every write of say 100 bytes is implemented as
>
> send write req
> recv write ac
Ashok wrote:
> Is there a method to schedule user mode code from
> kernel agent? ...
> windows 2000 offers 2 such facilities. (APC or async
> procedure calls) where a thread can block and when
> ready will be woken via the kernel agent and can run a
> user supplied function.
>
> or a method to bin
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > Erm... I wasn't talking about the DESIRED state of affairs!
> > I was talking about the CURRENT state of affairs. OK?
>
> Oh, but in 1995 it was quite possible to compile the kernel
> with kdev_t a pointer type, and I have done it severa
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in the kernel
> (ii) have a union at the point where the struct operations
> is
On 21 May 2001, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:"Martin.Knoblauch" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Hi,
> >
> > while trying to enhance a small hardware inventory script, I found that
> > cpuinfo is missing the details of L
And if we are at the topic... Those are the places where blk_size[]
get's
abused, since it's in fact a property of a FS in fact and not the
property of
a particular device... blksect_size is the array describing the physical
access limits of a device and blk_size get's usually checked against it.
Urban Widmark wrote:
> On Mon, 21 May 2001, Xuan Baldauf wrote:
>
> > That is annoying, because it heavily slows down bulk transfers of small
> > writes, like automatically unzipping a new mozilla build from the linux box to
> > the windows box. Every write of say 100 bytes is implemented as
>
On Wed, 23 May 2001, Xuan Baldauf wrote:
> Urban Widmark wrote:
>
> > The only other way I have found so far to get it to return the right file
> > size is to do a "seek-to-end". That still means an extra SMB but it avoids
> > the very painful "sync to disk".
> >
> > Fortunately the seek is only
Hi folks,(cc me, as i'm not on the list)
[1.] One line summary of the problem:
Kernel 2.4.4 oopses during boot
[2.] Full description of the problem/report:
Kernel 2.4.4 oopses during boot on RH 7.1 system, seems when it's
running kudzu or something (maybe I saw it wrong)
Afte
I tried to give you some pointers in a personal email. So it's not true
you didn't receive any response. Also reminded you of the best place to
look for info, namely, that driver's mailing list. You don't seem to
have made any additional attempts at resolving it yourself since you
reposted your or
On Wed, 23 May 2001, Tomas Telensky wrote:
> > Any particular reason this needs to be done in the kernel, as opposed
> It is already done in kernel, because it's displaying :)
> So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes
> sense and gives it things in order.
Displa
On Tue, 22 May 2001, Linus Torvalds wrote:
> I would much prefer a union of pointers over a pointer to a union.
>
> So I'd much rather have the inode have a
>
> union {
> struct block_device *block;
> struct char_device *char;
struct pipe_ino
Tomas Telensky wrote:
>
> On 21 May 2001, H. Peter Anvin wrote:
>
> > Followup to: <[EMAIL PROTECTED]>
> > By author:"Martin.Knoblauch" <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > Hi,
> > >
> > > while trying to enhance a small hardware inventory script, I found that
From [EMAIL PROTECTED] Wed May 23 00:39:23 2001
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in t
"H. Peter Anvin" wrote:
>
> "Martin.Knoblauch" wrote:
> >
> > After some checking, I could have made the answer a bit less terse:
> >
> > - it would require that the kernel is compiled with cpuid [module]
> > support
> > - not everybody may want enable this, just for getting one or two
> >
IMHO it would be nice to (for 2.4) create wrappers for accessing the
block arrays, so that we can more easily dispose of the arrays when 2.5
rolls around...
--
Jeff Garzik | "Are you the police?"
Building 1024| "No, ma'am. We're musicians."
MandrakeSoft |
-
To unsubscribe from this
> Do we really want a separate queue for each partition?
No.
> I have a half-baked patch
Me too. (Not half-baked but brewed.) In principle the change
is trivial, but there are a few IDE issues that are presently
solved in a very low-level way (and incorrectly).
This makes the patch larger than
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> I am not sure whether we agree or differ in opinion. I wouldn't mind
>
> /* pairing for dev_t to bd_op/cd_op */
> struct bc_device {
> struct list_headbd_hash;
> atomic_tbd_count;
> dev_t
Martin Knoblauch wrote:
> >
> > If so, then that's their problem. We're not here to solve the problem of
> > stupid system administrators.
> >
>
> They may not be stupid, just mislead :-( When Intel created the "cpuid"
> Feature some way along the P3 line, they gave a stupid reason for it and
>
Alexander Viro wrote:
> Do we really want a separate queue for each partition? I'd rather have
> disk_struct created when driver sees the disk and list of partitions
> (possibly represented by struct block_device) anchored in disk_struct
> and populated by grok_partitions().
Alan recently straigh
On Tue, May 22 2001, Jeff Garzik wrote:
> so... why not implement partitions as simply doing block remaps to the
> lower level device? That's what EVMS/LVM/md are doing already.
That is indeed the plan, having partitions simply being 'just another'
sector remap when submitting I/O
--
Jens Axbo
On Tue, May 22 2001, Jeff Garzik wrote:
> IMHO it would be nice to (for 2.4) create wrappers for accessing the
> block arrays, so that we can more easily dispose of the arrays when 2.5
> rolls around...
Agreed, in fact I have a lot of stuff that could be included in the
kcompat files for 2.4 (of
On Tue, 22 May 2001, H. Peter Anvin wrote:
> Martin Knoblauch wrote:
> > >
> > > If so, then that's their problem. We're not here to solve the problem of
> > > stupid system administrators.
> > >
> >
> > They may not be stupid, just mislead :-( When Intel created the "cpuid"
> > Feature some
> why not implement partitions as simply doing block remaps
Everybody agrees.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
> IMHO it would be nice to create wrappers for accessing the block arrays
Last year Linus didnt like that at all. Maybe this year.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
>> dev_t rdev;
> Reasonable.
Good. We all agree.
(But now you see what I meant in comments about mknod.)
>> kdev_t dev;
> Useless. If you hope that block_device will help to solve rmmod races
Yes. Why am I mistaken?
Andries
-
To unsubscribe from this list: send the line "unsubscrib
[EMAIL PROTECTED] wrote:
>
> > IMHO it would be nice to create wrappers for accessing the block arrays
>
> Last year Linus didnt like that at all. Maybe this year.
Well... the attached patch lines up into this effort and fixes
some abuses, removes redundant code and so on. Please have a second
What is wrong with this picture ?
I2O Printer port detects , then
0x378 detects too
but both are parport0 ?
Intel 815 M Board
PIII 800
265mb ram
Parallel Port is a
Bus 1, device 9, function 0:
Network controller: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 1).
IRQ 9.
Non
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> >>dev_t rdev;
>
> > Reasonable.
>
> Good. We all agree.
> (But now you see what I meant in comments about mknod.)
>
> >>kdev_t dev;
>
> > Useless. If you hope that block_device will help to solve rmmod races
>
> Yes. Why am I mistaken?
Si tiene una empresa en marcha, un proyecto o una idea registre su dominio en Internet
AHORA,
tal vez mañana sea demasiado tarde. Proteja su nombre en Internet. Si tiene ya dominio
y ha de renovarlo proximamente transfiera el dominio por solo 20$ lo tendra un año
renovado (esta operacion no af
On Wed, 23 May 2001, Tomas Telensky wrote:
> Yes. Recently I tried to transform whole cpuid code to a userspace
> utility. Not easy, not clean... but it worked.
See http://www.sourceforge.net/projects/x86info
or ftp://ftp.suse.com/pub/people/davej/x86info/
regards,
Dave.
--
| Dave Jones.
On Wed, 23 May 2001, Martin Knoblauch wrote:
> They may not be stupid, just mislead :-( When Intel created the "cpuid"
> Feature some way along the P3 line, they gave a stupid reason for it and
> created a big public uproar. As silly as I think that was (on both
> sides), the term "cpuid" is tai
On Tue, 22 May 2001 11:24:54 +0200,
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>> # Not a real dependency, this checks for hand editing of .config.
>> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
>> @echo Your .confi
Is drivers/char/ser_a2232fw.ax supposed to be included? Nothing uses 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.t
On Tue, 22 May 2001, Alexander Viro wrote:
> >which populate the "inode->dev" union pointer, which in turn is _only_
> >a cache of the lookup. Right now we do this purely based on "dev_t",
> >and I think that is bogus. We should never pass a "dev_t" around
> >without an inode, I
On Tue, 22 May 2001, Jeff Garzik wrote:
>
> Alan recently straightened me out with "EVMS/LVM is partitions done
> right"
>
> so... why not implement partitions as simply doing block remaps to the
> lower level device? That's what EVMS/LVM/md are doing already.
Because we still need the partit
On Tue, 22 May 2001, Jeff Garzik wrote:
>
> IMHO it would be nice to (for 2.4) create wrappers for accessing the
> block arrays, so that we can more easily dispose of the arrays when 2.5
> rolls around...
No.
We do not create wrappers "so that we can easily change the implementation
when xxx ha
On Tue, 22 May 2001 22:52:47 +1000, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Carlos Laviola wrote:
> >
> > invalid operand:
[ ... oops here ... ]
> > Segmentation fault
> >
> > This seems to be a bug in the kernel, maybe because the file is too big,
> > and VFAT partitions don't like tha
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > why not implement partitions as simply doing block remaps
>
> Everybody agrees.
No they don't.
Look at the cost of lvm. Function calls, buffer head remapping, the
works. You _need_ that for a generic LVM layer, but you sure as hell don't
need
Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Jeff Garzik wrote:
> >
> > Alan recently straightened me out with "EVMS/LVM is partitions done
> > right"
> >
> > so... why not implement partitions as simply doing block remaps to the
> > lower level device? That's what EVMS/LVM/md are doing alread
> May 23 02:46:24 localhost kernel: Process kudzu (pid: 219,
> stackpage=c7845000)
> May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400
> c73aa000 c122a060 c122a05c c122a058 c88fbb20
> May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80
> c73aa3f1 c7845f9c
Jeff Garzik wrote:
> /dev/sda <-> partition_blkdev <-> /dev/disk{0,1,2,3,4}
> /dev/hda <-> partition_blkdev <-> /dev/disk{5,6,7}
I also point out that handling disk partitions as a -tiny- remapping
blkdev also has the advantage of making it easy to have a single request
device per hardware device
Linus, since we have sane kill_super() now, the long-promised
cleanups are coming ;-) I'm going to feed them in small incremental
chunks, so if you see something unacceptable - yell. It may turn out
to be a result of bad choice of chunk boundaries, so...
OK, here comes the chunk #
Hi,
I've got a tyan s2520 motherboard (dual PIII + i840) which is having a
problem with APIC errors. I tried running with noapic, but there were
still errors, although fewer. Does anyone have any idea what is going
on? I'm running 2.4.4 and software raid5, which generates a lot of
interrupts.
He
OK, here's chunk #2.
* two helper functions added: attach_mnt() and detach_mnt().
attach_mnt() adds leaf to mount tree, detach_mnt() - removes.
Locking rules: both require mount_sem and dcache_lock being
held by callers.
The rest of stuff doing manipulations of mou
Alexander Viro wrote:
>
> Locking rules: both require mount_sem and dcache_lock being
> held by callers.
>
It would help a lot if locking rules were commented in
the source, rather than on linux-kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Wed, 23 May 2001, Andrew Morton wrote:
> Alexander Viro wrote:
> >
> > Locking rules: both require mount_sem and dcache_lock being
> > held by callers.
> >
>
> It would help a lot if locking rules were commented in
> the source, rather than on linux-kernel.
They will change in th
Hi ,
I have a proposition at hand to optimize getting system time by
avoiding
the system call(gettimeofday()) overhead. This can be implemented by
keeping a read-only page of kernel memory mapped into user processes
for reading quickly. A kernel process can keep that page up-to-date.
I di
Hi everybody,
I'd like to offer my $0.02 to the ongoing discussion.
IIRC we already have some OOB-data channels - ioctl, setsockopt, fcntl ...
to name only a few.
But: we already have a side-band: send with MSG_OOB!
And, as I just saw in the sources, there are some flags free.
So how about de
OK, chunk #3: beginnings of garbage collection for vfsmounts
and cleanup of do_umount() path.
* kill_super() had always been conditional on the
list_empty(&s->s_mounts). Check had been pulled inside kill_super(),
if we still have other mounts of that superblock kill_super() simply
I am not sure if it should be classified as a bug, that's why I am calling it a
problem. Here is the description:
If the filesystem is full, obviously, I can't write anything to that any
longer. But if I open a file with O_TRUNC flag set, the file will be truncated.
Any program that opens a file
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > why not implement partitions as simply doing block remaps
>
> Everybody agrees.
No they don't.
We had this discussion already. We all agree.
Maybe you read in "remap" something other than a simple addition
but I don't.
On Tuesday 22 May 2001 20:20, David N. Lombard wrote:
> Rik van Riel wrote:
> > On Tue, 22 May 2001, Daniel Phillips wrote:
> > > On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
> > > > http://nl.linux.org/~phillips/htree
> > >
> > > Oops, nl.linux.org was down for 'unscheduled maintainance
Hi
I am comfronting with a macro __asm__ . What is the meaning of
this. I cannot find the definition of this. I need the meaning of this line
__asm__("and 1 %%esp.%0; ":"=r" (current) : "0" (~8191UL));
This is defined inside the get_current() in current.h
An email sent to you was identified to contain a virus.
Here are the information in this mail:
Date: Tue, 22 May 2001 09:29:17
From: "Mayank Vasa" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Mawanella
Our virus filter has blocked this email and notified the sender.
This message is
Dave Jones wrote:
>
> On Wed, 23 May 2001, Martin Knoblauch wrote:
>
> > They may not be stupid, just mislead :-( When Intel created the "cpuid"
> > Feature some way along the P3 line, they gave a stupid reason for it and
> > created a big public uproar. As silly as I think that was (on both
>
On Wed, 23 May 2001, Keith Owens wrote:
> Is drivers/char/ser_a2232fw.ax supposed to be included? Nothing uses it.
It's the source for the firmware hexdump in ser_a2232fw.h, provided as a
reference.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven
Richard Gooch wrote:
> Dave sent a message out a week or two ago saying he was going to do it
> soon. And back in January he said he'd be doing it in February. The
> kernel list FAQ has stated this right at the top, in big, bright red
> letters. Yesterday, after I saw Dave's announcement, I update
On Tue, May 22, 2001 at 08:49:04AM +0100, Alan Cox wrote:
> > For _devices_, though? I don't expect my mouse to work if gpm and xfree
> > both try to consume device events from the same filp. Heck, it doesn't
> > even work when they try to consume events from the same inode :-) I think
> > this
Tony Hoyle writes:
> Richard Gooch wrote:
>
> > In fact, hopefully he's still in a dark mood, and he may take up the
> > suggestion to bounce mails of the following type:
> > - MIME encoded
> > - HTML encoded
> > - quoted printables (those stupid "=20" things are particuarly hard to
> > read).
Hi all
Find enclosed a tiny patch to the CREDITS file - I have moved house. It's
against the 2.2.19 CREDITS file, but is also relevant for the 2.4.x series.
jonathan
--- CREDITS-2.2.19 Thu May 10 09:43:35 2001
+++ CREDITS Thu May 10 09:44:15 2001
@@ -2398,8 +2398,8 @@
E: [EMAIL PROTE
On Tue, 22 May 2001, Jan Harkes wrote:
>
> something like,
>
> ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen,
> void *outbuf, size_t outlen);
>
> As far as functionality and errors it works like read/write in a single
> call, pretty much what Richard
> I veto, the whole point of moving to ECN was to make a statement and
> get people to fix their kit.
>
Isn't this a problem though because the messge saying that ECN was enabled
was set after ECN was enabled? Thus these people have no idea what is
going on and they probably won't know what to fi
On Tue, May 22, 2001 at 06:51:57AM -0500, Brent D. Norris wrote:
> > I veto, the whole point of moving to ECN was to make a statement and
> > get people to fix their kit.
> >
> Isn't this a problem though because the messge saying that ECN was enabled
> was set after ECN was enabled? Thus these p
Matti Aarnio writes:
> I am contemplating to periodically turn off the ECN bit to
> let email out, but DaveM has veto there.
I veto, the whole point of moving to ECN was to make a statement and
get people to fix their kit.
We will remove these people, that's all.
Later,
David S. Miller
[EMAI
On Tue, May 22, 2001 at 04:31:37PM +0100, Alan Cox wrote:
> > `the class of devices in question' was cryptographic devices, and possibly
> > other transactional DSPs. I don't consider audio to be transactional.
> > in any case, you can do transactional things with two threads, as long
> > as they
David S. Miller writes:
> What are these "devices", and what drivers "just program the cards to
> start the dma on those hundred mbyte of ram"?
Hmmm, I have a few cards that are used that way. They are used
for communication between nodes of a cluster.
One might put 16 cards in a system. The ca
> Matti Aarnio writes:
> > I am contemplating to periodically turn off the ECN bit to
> > let email out, but DaveM has veto there.
>
> I veto, the whole point of moving to ECN was to make a statement and
> get people to fix their kit.
>
> We will remove these people, that's all.
Since HTML em
Not to mention, not everyone on the list runs their own mailservers.
-Original Message-
From: Steve Modica [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 22, 2001 12:28
To: Rogier Wolff
Cc: Richard Gooch; Brent D. Norris; David S. Miller;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTEC
> `the class of devices in question' was cryptographic devices, and possibly
> other transactional DSPs. I don't consider audio to be transactional.
> in any case, you can do transactional things with two threads, as long
> as they each have their own fd on the device. Think of the fd as your
>
> I have an analog joystick plugged into the gameport of a Soundblaster
> AWE64. In 2.4.4-ac12 this was recognized and worked just fine. Under
> ac13 the recognition is incomplete - it seems to identify that there
> is a NS558 gameport device present, but not that there is a joystick
> plugged i
FOLKS, I HAVE ALL THE TIME USED 'Reply-To:' HEADER POINTING
TO linux-kernel -- INSTEAD OF ALL THE LISTS...
If you want to continue this, do it there.
(Before I decide to taboo "Re: ECN is on!" subject line..)
On Tue, May 22, 2001 at 12:23:29PM -0400, Richard Gooch wrote:
...
> Well, wh
On Tue, May 22, 2001 at 09:40:19AM -0700, Ryan Cumming wrote:
> On Tue, 22 May 2001, Alan Cox wrote:
>
> > If __linux__ is not defined by the cross compiler, then the cross compiler
> > is broken. A cross compiler has the same environment as the native compiler
> > for the target. The only stuff
Hi,
On Tue, May 22, 2001 at 11:54:55AM -0500, Oliver Xymoron wrote:
> > > > That's probably the right thing to add.
> > >
> > > I'd vote for an async flag instead.
> >
> > Why??? Why change the default behaviour to be something much slower?
>
> I was suggesting an async flag _in addition_ to t
On Mon, 21 May 2001, Paul Mackerras wrote:
>
> As for the `to' argument, yes it is redundant since it is just kmap(page).
And why not let "clear_page()" just do that itself?
The only place that doesn't already do "kmap(page)" is basically
get_zeroed_page(), and the only reason it doesn't do th
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> On Mon, 21 May 2001, Daniel Phillips wrote:
> > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > What I'd like to see:
> > >
> > > - An interface for registering an array of related devices
> > > (almost always two: raw and ctl) and the
In KDE and sometimes also seen in netscape, I get displays in italics
which I don't in any non-ac kernels. All KDE menus now show up in
discontinuous italics that are not really readable. I'm using
XFree86-4.0.3, KDE-2.1.1 and an NVidia 32Meg TNT2 M64 card, but I've had
the same with much
Looks ok. General comment: the code to search through the list of PCI
devices and drivers to find the one associated with our minor should be
in a separate function, if that code appears more than once.
esssolo_find_minor or somesuch...
--
Jeff Garzik | "Are you the police?"
Building 102
On Mon, May 21, 2001 at 03:10:32PM -0700, Linus Torvalds wrote:
> That, in turn, might be as simple as changing the ioctl incoming arguments
> of into a structure like .
At least make sure that the 'kioctl' returns the number of bytes placed
into the output buffer, as userspace doesn't necessari
On Tue, 22 May 2001, Daniel Phillips wrote:
> > I don't think it's likely to be even workable. Just consider the
> > directory entry for a moment - is it going to be marked d or [cb]?
>
> It's going to be marked 'd', it's a directory, not a file.
Are we talking about the same proposal? The one
>> What is the communication between user space and kernel
>> that transports device identities?
> It doesn't change, the same symbolic names still work.
But today, unless you think of devfs or so, device identities
are not transported by symbolic names. They are given by
device numbers.
[Yes,
On Wed, 23 May 2001, Edgar Toernig wrote:
> And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl):
> This _may_ work for some kind of devices. But serial ports are one
> example where it simply will _not_. It requires that you know the
That's quite funny, you know...
--
101 - 200 of 248 matches
Mail list logo
