On Tue, Jan 09, 2001 at 08:29:02PM +0100, Trond Myklebust wrote:
Al has mentioned that he wants us to move towards a *BSD-like system
of credentials (i.e. struct ucred) that could be used here, but that's
in the far future. In the meantime, we cache RPC credentials in the
struct file...
On Wed, Jan 10, 2001 at 07:31:52PM +, Alan Cox wrote:
struct ucred is also needed to get LinuxThreads POSIX compliant (sharing
credentials between threads, but still keeping system calls atomic in
relation to credential changes)
That is extremely undesirable behaviour. setuid()
On Wed, Jan 10, 2001 at 07:40:49PM +, Alan Cox wrote:
Of course not by default, it would be a new clone flag (with default to on in
linuxthreads though, to not cause security holes in ported programs like today)
I've seen exactly nil cases where there are any security holes in apps
On Wed, Jan 10, 2001 at 07:48:04PM +, Alan Cox wrote:
As the thread started it's not only only needed for pthreads, but also for NFS
and setuid (actually NFS already implements it privately), and probably other
network
file systems too. So it's far from being only a "bad standard
On Wed, Jan 10, 2001 at 03:40:50PM -0500, Jonathan Earle wrote:
Where do I go from here? Is there info somewhere to help with this? Is
this a bigger job than it looks on the surface?
Try http://www.firstfloor.org/~andi/softnet
-Andi
-
To unsubscribe from this list: send the line
On Wed, Jan 10, 2001 at 04:37:06PM -0500, Dennis wrote:
At 03:01 PM 01/10/2001, Hans Grobler wrote:
On Wed, 10 Jan 2001, Dennis wrote:
At 02:57 PM 01/09/2001, Dennis wrote:
Where might one find the definitive document on porting device drivers to
2.4 kernels?
should I assume that
On Thu, Jan 11, 2001 at 11:05:55AM +0100, Udo A. Steinberg wrote:
Linus Torvalds wrote:
Mind trying it with the "HAVE_FXSR" and "HAVE_XMM" macros in
linux/include/asm-i386/processor.h
fixed? They _should_ be just
#define HAVE_FXSR (cpu_has_fxsr)
On Thu, Jan 11, 2001 at 10:24:01AM +, Danny ter Haar wrote:
Version number of the driver is the same but it doesn't work.
Any thoughts anyone ?
"Doesn't work" isn't a very useful bug report. What happens exactly?
Do the RX/TX/error counters increase when you try to send packets?
-Andi
On Thu, Jan 11, 2001 at 07:34:01AM +, Russell King wrote:
1. Yucky code in the NFS layers to copy a nfs_fh from userspace to kernel
space, translating it into something sane.
2. Yucky code in the NFS layers to manually handle the nfs_fh to knfs_fh
translation.
3. Accept the
On Thu, Jan 11, 2001 at 07:10:27AM -0500, Manfred wrote:
Zitiere Russell King [EMAIL PROTECTED]:
The API changed:
struct nfs_mount_data {
int version;/* 1 */
int fd; /* 1 */
- struct nfs_fh root;
On Thu, Jan 11, 2001 at 12:56:04PM +, Stephen C. Tweedie wrote:
Hi,
On Wed, Jan 10, 2001 at 12:11:16PM -0800, Linus Torvalds wrote:
That said, we can easily support the notion of CLONE_CRED if we absolutely
have to (and sane people just shouldn't use it), so if somebody wants to
On Sat, Jan 13, 2001 at 10:11:42PM +0100, Krzysztof Rusocki wrote:
Hi,
Since 2.4.0 (from XFS CVS source tree) i get such things from kernel:
Jan 13 20:55:48 main kernel: reset_xmit_timer sk=c299b9a0 1 when=0x6061,
caller=c0218f88
It's harmless. Just ignore them or comment out the
On Sun, Jan 14, 2001 at 01:17:54AM -0800, David S. Miller wrote:
Igmar Palsenberg writes:
we might want to consider changing the error the call gives in case
MULTIPLE_TABLES isn't set. -EINVAL is ugly, -ENOSYS should make the error
more clear..
How do I tell the difference
On Sun, Jan 14, 2001 at 02:55:28AM -0800, David S. Miller wrote:
Andi Kleen writes:
In my opinion (rt)netlink would benefit a lot from introducing 5-10
new errnos and possibly a new socket option to get a string/number
with the exact error.
Introducing 5-10 new errnos just
On Sun, Jan 14, 2001 at 01:13:16PM +0100, Igmar Palsenberg wrote:
On Sun, 14 Jan 2001, Andi Kleen wrote:
On Sun, Jan 14, 2001 at 03:36:55AM -0800, David S. Miller wrote:
Andi Kleen writes:
How would you pass the extended errors? As strings or as to be
defined new numbers? I
On Sun, Jan 14, 2001 at 05:15:53AM -0800, David S. Miller wrote:
Andi Kleen writes:
David's /proc/errno_strings
David put a smiley at the end of that sentence, he was kidding and was
trying to show you how rediculious keeping errno strings in the kernel
is.
You think it is less
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
this is a safe, very fast [ O(1) ] object-permission model. (it's a
variation of a former idea of yours.) A process can pass object
fingerprints and kernel pointers to other processes too - thus the other
process can access the
On Tue, Jan 16, 2001 at 12:26:12PM +0100, Ingo Molnar wrote:
On Tue, 16 Jan 2001, Andi Kleen wrote:
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
this is a safe, very fast [ O(1) ] object-permission model. (it's a
variation of a former idea of yours.) A process can
On Tue, Jan 16, 2001 at 01:04:22PM +0100, Ingo Molnar wrote:
- a less radical solution would be to still map file structures to an
integer range (file descriptors) and usage-maintain files per processes,
but relax the 'allocate first non-allocated integer in the range' rule.
I'm not sure
On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote:
don't assume that the way your system gets booted is the way everybody's does,
particularly those on platforms other than the x86.
I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do
get tired of
On Wed, Jan 17, 2001 at 05:15:54PM -, Tony Gale wrote:
On 17-Jan-2001 Jussi Hamalainen wrote:
On Wed, 17 Jan 2001, Tony Gale wrote:
It looks like this is due to the odd way in which ipchains handles
fragments. Try:
echo 1 /proc/sys/net/ipv4/ip_always_defrag
Thanks, this
On Wed, Jan 17, 2001 at 05:44:30PM -, Tony Gale wrote:
On 17-Jan-2001 Andi Kleen wrote:
Connection tracking always defrags as needed.
masquerading/NAT/iptables
with connection tracking uses that.
This means that if any of these are enabled and your machine acts
On Wed, Jan 17, 2001 at 06:04:33PM +0100, Werner Almesberger wrote:
(See also ftp://icaftp.epfl.ch/pub/people/almesber/slides/tmp-tc.ps.gz
The bitching starts on slide 11, some ideas for fixing the problem on
slide 16, but heed the warning on slide 15.)
Thanks for the pointer.
Besides
On Wed, Jan 17, 2001 at 02:17:36PM -0800, Rick Jones wrote:
How does CORKing interact with ACK generation? In particular how it
might interact with (or rather possibly induce) standalone ACKs?
It doesn't change the ACK generation. If your cork'ed packets gets sent
before the delayed ack
On Thu, Jan 18, 2001 at 02:06:46PM +0100, Ingo Molnar wrote:
On Wed, 17 Jan 2001, Rick Jones wrote:
i'd heard interesting generalities but no specifics. for instance,
when the send is small, does TCP wait exclusively for the app to
flush, or is there an "if all else fails" sort of
On Thu, Jan 18, 2001 at 10:20:16AM -0800, Rick Jones wrote:
Andi Kleen wrote:
On Wed, Jan 17, 2001 at 02:17:36PM -0800, Rick Jones wrote:
How does CORKing interact with ACK generation? In particular how it
might interact with (or rather possibly induce) standalone ACKs
On Fri, Jan 19, 2001 at 01:26:16AM +0100, Andrea Arcangeli wrote:
I remeber the O(1) scheduler from Davide Libenzi was beating the mainline O(N)
scheduler with over 7 tasks in the runqueue (actually I'm not sure if the
number was 7 but certainly it was under 10). So if you also use a O(1)
On Thu, Jan 18, 2001 at 08:00:16PM -0500, Mark Hahn wrote:
microseconds/yield
# threads 2.2.16-22 2.42.4-multi-queue
- ---
16 18.7404.603 1.455
On Fri, Jan 19, 2001 at 02:40:23AM +0100, Jens Axboe wrote:
On Fri, Jan 19 2001, Andrea Arcangeli wrote:
On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
Jens, can be the -blk patch the reason for the slowdown I'm seeing?
This heuristic is way too aggressive:
On Fri, Jan 19, 2001 at 02:35:02AM +0100, Andrea Arcangeli wrote:
On Thu, Jan 18, 2001 at 08:00:16PM -0500, Mark Hahn wrote:
microseconds/yield
# threads 2.2.16-22 2.42.4-multi-queue
-
On Fri, Jan 19, 2001 at 02:47:45AM +0100, Jens Axboe wrote:
On Fri, Jan 19 2001, Andi Kleen wrote:
Yes I agree, that values should probably be tweaked a bit. I'll
try and squeeze some testing in to generate the best possible
values.
Please also add a sysctl. I always feel
On Fri, Jan 19, 2001 at 09:30:55AM -0500, Bill Hartner wrote:
(3) For the i386 arch :
My observations were made on an 8-way 550 Mhz PIII Xeon 2MB L2 cache.
The task structures are page aligned. So when running the benchmark
you may see what I *suspect* are L1/L2 cache
On Fri, Jan 19, 2001 at 09:39:13AM -0700, Ian S. Nelson wrote:
is this a bug?
We have a number of machines running 2.4.0 and /proc/meminfo says we're
sharing no memory. top says that also, probably because it just reads
/proc/meminfo, or at least I assume that's how it works.All the
On Sat, Jan 20, 2001 at 04:58:56PM -0500, Sandy Harris wrote:
I suspect that I've misunderstood some constraint here. Perhaps the more complex
code you posted is necessary, but I'd like to know why.
strtok is not reentrant and cannot be nested this way without
saving __strtok. strsep would
On Mon, Jan 22, 2001 at 02:23:05PM -0500, Bill Hartner wrote:
Mike K, wrote :
If the above is accurate, then I am wondering what would be a
good scheduler benchmark for these low task count situations.
I could undo the optimizations in sys_sched_yield() (for testing
purposes only!),
On Tue, Jan 23, 2001 at 01:50:27AM +0100, Bernd Eckenfels wrote:
Another option is to ifconfig -arp the eth0 interface. I browsed through the
IPv4 code and did not find any other goto out which can be configured besides
the input FIB, which messing with is a bad thing since it wont accept the
On Tue, Jan 23, 2001 at 03:50:36PM -0800, Pete Elton wrote:
Is there something that the arp_filter can do that will mirror this
functionality? The modification that you made to the documentation
was pretty straight forward in that the arp_filter was BOOLEAN, so
I think I implemented it
On Tue, Jan 23, 2001 at 04:27:21PM -0800, Pete Elton wrote:
Any ideas on how I can turn off the arping? I guess the thing that I
I explained it in my last mail how to do it using arpfilter. I do not claim
that it is an elegant solution.
It's probably not worse a hack than hidden is in the
On Wed, Jan 24, 2001 at 11:03:34PM +0300, [EMAIL PROTECTED] wrote:
Hello!
I read through the tcpdump, and it seems that Linux completely ignores
packets with out-of-window sequence numbers:
Yes, Linux is __very__ not right doing this. RFC requires to accept
ACK, URG and RST on any
On Thu, Jan 25, 2001 at 12:24:11PM +, Studierende der Universitaet des Saarlandes
wrote:
Andi wrote:
Basically it would accept the acks with the data in most
cases except when the application has totally stopped
reading and in that case it doesn't harm to ignore the
acks.
But it
On Thu, Jan 25, 2001 at 03:32:44AM -0800, David S. Miller wrote:
Andi Kleen writes:
It's mostly for security to make it more difficult to nuke connections
without knowing the sequence number.
Remember RFC is from a very different internet with much less DoS attacks.
Andi, one
On Thu, Jan 25, 2001 at 03:44:07AM -0800, David S. Miller wrote:
Andi Kleen writes:
BSD and Solaris both make these kinds of packets, therefore it is must
to handle them properly. So we will fix Linux, there is no argument.
How do you propose to handle them? Queue the data
On Thu, Jan 25, 2001 at 08:40:16AM -0800, David S. Miller wrote:
James H. Cloos Jr. writes:
What exaclty were the issues with the intel cards and sg+csum?
Any idea how much work it'd require to surmount them?
Getting Intel to release full specs on how to make use of
TX hardware
On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote:
What is missing here is a good authoritative web ressource that tells
people which NIC to buy.
I have a tulip NIC because a few years ago that apparently was the NIC
of choice. It has good multicast (which is important to
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
The internet is a form of organized chaos, sometimes you gotta make
these type of decisions to get things done. Imagine the joy _most_
people would get flogging all firewall admins who block all ICMP.
Blocking out ICMP
On Mon, Jan 29, 2001 at 03:46:42AM +0100, Albert D. Cahalan wrote:
John Fremlin writes:
When the IP address of an interface changes, TCP connections with the
old source address are useless. Applications are not notified of this
and time out ordinarily, just as if nothing had happened.
On Mon, Jan 29, 2001 at 11:01:31AM -0600, Timur Tabi wrote:
What makes it more frustrating is that some people on this list talk as if
things things are common knowledge. I've been following this mailing list for
months, and until today I had no idea sleep_on was bad. All the documentation
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
You still miss wakeups. :)
And there was another race in it, I know. The first __set_task_state
has to be set_task_state to get the right memory write order on SMP.
-Andi
-
To unsubscribe from this list: send the line
On Mon, Jan 29, 2001 at 07:31:36PM +0100, Jamie Lokier wrote:
The important thing is that the tunnel is destroyed and recreated (it
has to be, it is over different underlying link addresses). I do not
want that to destroy the connections from the tunnelled address.
Just do not set
Alan Cox [EMAIL PROTECTED] writes:
Someone in .de (Alas I forget their name now) actually did port BSD net/2 to
Linux.
Matthias Urlichs iirc
He also later implemented a minimal STREAMS clone on Linux for his
ISDN stack.
[and today Linux is reinventing non shouted streams with netfilter..]
On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote:
If that happens, and the socket uses GFP_ATOMIC allocation, the while (1)
loop in sock_alloc_send_skb() will endlessly spin, without ever calling
schedule(), and all the time holding the kernel lock ...
If the socket is using
On Thu, May 10, 2001 at 11:13:00PM +0200, Andrea Arcangeli wrote:
On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote:
On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote:
If that happens, and the socket uses GFP_ATOMIC allocation, the while (1)
loop in sock_alloc_send_skb
On Fri, May 11, 2001 at 12:23:09AM +0200, Daniel Podlejski wrote:
ext2:
root@witch:/mobile:# time tar xzf /arc/test.tar.gz
If /arc is not on a different hd it is probably a good idea to make
sure test.tar.gz is small enough to fit into memory and has been read
at least once to be cache
On Thu, May 10, 2001 at 11:32:25PM +0200, Andrea Arcangeli wrote:
you said interrupt won't call that function so I don't see the
GFP_ATOMIC issue.
I said interrupts should not call it, but apparently somebody tries to
call it with GFP_ATOMIC and I'm suspecting that caller is broken (whatever
On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote:
I was just wondering if anybody had an idea which nic card might be a better
choice for me; I have a pci 3c590 and a pci smc that uses the tulip driver.
I don't have the card number for the smc with me handy, however I know both
cards
On Fri, May 11, 2001 at 10:01:50PM -0700, Jonathan Lundell wrote:
Can somebody explain the use of ENOIOCTLCMD? There are order of 170
uses in the kernel, but I don't see any guidelines for that use (nor
what prevents it from being seen by user programs).
The idea with ENOIOCTLCMD is that
On Fri, May 11, 2001 at 12:21:59PM +, Petr Vandrovec wrote:
When I was updating VMware's vmnet, I decided to use
#ifdef skb_shinfo
Yes I forgot that RedHat already shipped it :-(
This gives you maximal backward compatibility, as all public zerocopy
patches contain this macro. Only
On Fri, May 11, 2001 at 12:39:29PM +0200, Rogier Wolff wrote:
But it's always been said that source code compatiblity would be
maintained. I'm a bit pissed that people just go about changing public
source-level interfaces.
2.4.4 is basically like 2.5.0 as far as networking is concerned, it
On Fri, May 11, 2001 at 05:39:40PM +0300, Alexey Vyskubov wrote:
Hello!
I read net/ipv4/ipip.c. It seems to me that ipip_rcv() function after
unwrapping tunelled IP packet creates virtual Ethernet header and submit
corresponding sk_buff to netif_rx().
Is there a some reason to do things
On Sun, May 13, 2001 at 01:07:03AM -0700, Philip Wang wrote:
Hello!
I'm Philip, from Professor Dawson Engler's Meta-Compilation Group at
Stanford University.
This simple and obvious bug fix makes sure that vmalloc() does not return
NULL. My addition of returning -1 is consistent with
On Sun, May 13, 2001 at 05:45:13PM +0100, Matt wrote:
I'm having some major headaches trying to get a timer working in my
driver.
The timer is started when the device node is opened, and deleted when it's
closed. The timer code itself calls mod_timer to add itself back in
again. At the
On Mon, May 14, 2001 at 05:09:52PM +0900, root wrote:
Basically, it appears that Don Becker praised the Tulip chipset the most.
How much important is zero copy TX and hardware checksumming?
Zero copy TX is not that important yet except if you use samba or Tux or
proftpd or anything else that
On Mon, May 14, 2001 at 01:29:51PM -0700, Linus Torvalds wrote:
Big device numbers are _not_ a solution. I will accept a 32-bit one, but
no more, and I will _not_ accept a manage by hand approach any more. The
time has long since come to say No. Which I've done. If you can't make
it manage
On Mon, May 14, 2001 at 04:15:12PM -0500, Samuel Meder wrote:
I'm seeing a similar effect myself. When I use all my available sdsl
bandwidth (say doing a bulk data transfer), DNS lookups will often
time out. This is with the default buffer settings/2.4.4.
The problem is that the DNS resolver
On Mon, May 14, 2001 at 08:32:33AM -0400, Michal Ostrowski wrote:
Having looked at the code for locking sockets I am concerned that the
locking procedures for tcp may be wrong. __release_sock releases the
socket spinlock before calling sk-backlog_rcv() (== tcp_v4_do_rcv),
however the
On Fri, May 11, 2001 at 02:56:35AM -0700, David S. Miller wrote:
Rogier Wolff writes:
It seems that in 2.4.4 suddenly the function skb_cow no longer
returns the modified skb, but it retuns and integer for
succes/failure.
This means that for networking modules requiring this
On Sun, May 20, 2001 at 07:33:15PM +0200, David Osojnik wrote:
the system with problem is using kernel 2.4.2 on an P200 with 64mb ram. It
has about 20 users that use the box... (ftp, telnet, lynx, bitchx,...).
the problem is when the parameter tcp_mem HIGH gets exeded after about a day
of
On Wed, May 23, 2001 at 12:26:49PM +0200, Aviv Greenberg wrote:
Hi,
Is it possible to enter into sleep mode
( current-state = !RUNNING schedule(_timeout))
from a softirq ?
No.
It is not a real hardware interrupt after all, but it still runs in
the context of a running process
On Wed, May 23, 2001 at 04:16:54PM +0200, christophe barbé wrote:
Hi all,
I'm trying to figure out how to use the destructor function in the skbuff
object.
I've read (the source code and) the alan cox's article from linuxjournal
but it refers to linux 2.0.
Perhaps someone can tell me
On Wed, May 23, 2001 at 04:28:01PM +0200, sebastien person wrote:
Is it bad to do the following call ?
mod_timer(timer, jiffies+(0.1*HZ));
Yes very bad. gcc will generate a floating point add for that, corrupting
the user process' floating point context.
-Andi
-
To unsubscribe from
On Wed, May 23, 2001 at 04:37:58PM +0200, christophe barbé wrote:
It seems to not be the case, because my destructor is called.
It is called, but you overwrote the kernel destructor and therefore
broke the socket memory accounting completely; causing all kinds of
problems.
Could you point me
On Wed, May 23, 2001 at 04:50:28PM +0200, christophe barbé wrote:
I don't know about socket but I allocate myself the skbuff and I set the
destructor (and previously the pointer value is NULL). So I don't overwrite
a destructor.
That just means you didn't test all cases; e.g. not TCP or UDP
On Wed, May 23, 2001 at 05:02:15PM +0200, christophe barbé wrote:
I believe you and It's sure that I have not tested all cases.
So do you see a way to use a private data buffer ?
The only way I know currently is to keep skb-users = 1 and use a timer
that collects such buffers from a global
On Wed, May 23, 2001 at 06:59:02PM +0100, Ben Mansell wrote:
Hi all,
Is there any mechanism in Linux for refusing incoming TCP connections?
I'd like to be able to fetch the next incoming connection on a listen
queue, and selectively accept or reject it based on the IP address of the
EIP; c0237bc4 ipv6_addr_type+4/e0 =
Problem is already fixed in the latest pre kernels.
-Andi
-
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
On Wed, May 23, 2001 at 03:56:35PM -0400, David Gordon (LMC) wrote:
EIP; c0237bc4 ipv6_addr_type+4/e0 =
What exactly was the problem that was fixed in the latest pre kernel ?
A coding mistake was fixed.
Here is the patch if you're interested (cut'n'pasted so not applicable)
RCS
On Thu, May 24, 2001 at 12:58:14AM -0600, Andreas Dilger wrote:
Well reiserfs is probably a very bad choice at this point. It
does not have any bad blocks support (yet), so as soon as you have
a bad block you are stuck.
reiserfs doesn't, but the HD usually has transparently in its firmware.
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 time you hit
the block the firmware has mapped
On Thu, May 24, 2001 at 12:15:44PM -0700, David Ford wrote:
Is there an example somewhere of this?
I don't have one handy, but basically you have to hack libpcap a bit
to push the generated filters using SO_ATTACH_FILTER onto a socket.
The format (LPF) understood by the kernel is a superset of
On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote:
I'm curious about this stack checker. Does it check for a single
stack allocation = 1024 bytes, or does it also check for several
individual, smaller allocations which total = 1024 bytes inside
a single function? That would be
On Wed, May 09, 2001 at 04:25:40PM -0500, Steve Lord wrote:
XFS is very fast most of the time (deleting a file is so slow its like us
ing
old BSD systems). Im not familiar enough with its behaviour under Linux yet.
Hmm, I just removed 2.2 Gbytes of data in 3 files in 37
On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
Actually, you will never get a stack fault exception, since with a flat
stack segment you can never get a limit violation. All you will do is
corrupt the data in task struct and cause an oops later on when the
kernel tries to use
On Mon, May 21, 2001 at 03:34:50AM -0700, David S. Miller wrote:
Andi Kleen writes:
[BTW, the 2.4.4 netstack does not seem to make any attempt to handle the
pagecache 4GB case on IA32 for sendfile, as the pci_* functions are dummies
here. It probably needs bounce buffers
On Mon, May 21, 2001 at 02:30:09AM -0700, David S. Miller wrote:
Andi Kleen writes:
On the topic of to the PCI DMA code: one thing I'm missing
are pci_map_single()/pci_map_sg() that take struct page * instead of
of direct pointers. Currently I don't see how you would implement IO-MMU
On Fri, May 25, 2001 at 06:25:57PM +1000, Keith Owens wrote:
Nothing in arch/i386/kernel/traps.c uses a task gate, they are all
interrupt, trap, system or call gates. I guarantee that kdb on ix86
and ia64 uses the same kernel stack as the failing task, the starting
point for the kdb
On Fri, May 25, 2001 at 04:53:47PM +1000, Keith Owens wrote:
The only way to avoid those problems is to move struct task out of the
kernel stack pages and to use a task gate for the stack fault and
double fault handlers, instead of a trap gate (all ix86 specific).
Those methods are expensive,
On the topic of to the PCI DMA code: one thing I'm missing
are pci_map_single()/pci_map_sg() that take struct page * instead of
of direct pointers. Currently I don't see how you would implement IO-MMU IO
on a 32bit box with more than 4GB of memory, because the address won't
fit into the pointer.
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
Nathan Paul Simons wrote:
As for the argument of putting it in the kernel being more robust and
idiot-proof, well, if someone can't keep three files and one directory
straight for each different configuration of the
On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
I don't see the advantage over Alan's proposal of simply adding the
config data to the bzImage or whatever is the most common format on
the respective platform. You still have the same fundamental problem
to solve (i.e.
On Thu, Aug 31, 2000 at 09:50:35PM -0700, Richard Henderson wrote:
On Fri, Sep 01, 2000 at 12:16:38AM +0300, Matti Aarnio wrote:
Also (I recall) because GCC's 'long long' related operations
and optimizations have been buggy in past, and there is no
sufficient experience to
On Fri, Sep 01, 2000 at 04:01:43PM +0300, Matti Aarnio wrote:
On Fri, Sep 01, 2000 at 02:44:04PM +0200, Andi Kleen wrote:
To my knowlege it's only been speed related issues, not
correctness issues, that have been the cause for the
fear and loathing of long long.
There are several
On Fri, Sep 01, 2000 at 03:06:52PM -0700, Linus Torvalds wrote:
Good that _somebody_ actually looked at the code. I'll make some more
modifications to handle blocked signals correctly (ie handling the case
where the signal is blocked in all threads and then unblocked in one of
them _after_
On Fri, Sep 01, 2000 at 05:50:04PM -0700, Ulrich Drepper wrote:
"Andi Kleen" [EMAIL PROTECTED] writes:
I've been thinking about how to best get rid of the thread manager for
thread creation in LinuxThreads. It is currently needed to do the wait.
If you get rid of the mana
On Fri, Sep 01, 2000 at 06:15:52PM -0700, Linus Torvalds wrote:
if (!has_done_this_before) {
pid_t tid;
has_done_this_before = 1;
tid = clone(CLONE_PID);
I'm not sure this will work very well
On Sat, Sep 02, 2000 at 04:01:24PM -0600, Jeff V. Merkey wrote:
Andi Kleen wrote:
On Sat, Sep 02, 2000 at 03:34:47PM -0600, Jeff V. Merkey wrote:
KDB is putrid. Can it debug double faults? NO. Can it debug complex
register and numeric evaluation statements like IF ((EAX == 1
On Sun, Sep 03, 2000 at 10:18:50AM +0200, Ingo Molnar wrote:
On 2 Sep 2000, Jes Sorensen wrote:
You can't DMA directly from a file cache page unless you have a
network card that does scatter/gather DMA and surprise surprise,
80-90% of the cards on the market don't support this. [...]
On Sun, Sep 03, 2000 at 05:22:44AM +0200, Jamie Lokier wrote:
I just thought I'd mention that you can do zero copy TCP in and out
*without* any page marking schemes. All you need is a network card with
quite a lot of RAM and some intelligence. An Alteon could do it, with
extra RAM or an
On Mon, Sep 04, 2000 at 10:22:42AM +0800, Andrey Savochkin wrote:
Andi, there may be two reasons of this behavior:
1. skb that triggered ARP request had a.b.c.1 source, either because
a) the socket had been bound to that address, or
b) preferred source in the routing table is wrong;
2.
On Mon, Sep 04, 2000 at 05:06:15PM +0800, Andrey Savochkin wrote:
So, I think that we have to be sure that we use the "best" address for this
destination.
What about an unconditional use of inet_select_addr() or fib_select_addr()
based on prefsrc with inet_select_addr() fallback?
It looks
On Mon, Sep 04, 2000 at 10:57:44AM +0100, Matthew Kirkwood wrote:
With both interfaces up, it's impossible to apply anti-martian
rules to the interfaces, since it's hard to predict which card
will answer an ARP request.
/proc/sys/net/ipv4/.../hidden
So when lightning fries the
1 - 100 of 19746 matches
Mail list logo
