* [Linux-ia64] Re: strace improvement patch
From: David Mosberger @ 2003-01-08 23:43 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805650@msgid-missing>
>>>>> On Wed, 8 Jan 2003 14:17:06 -0800, Roland McGrath <roland@redhat.com> said:
Roland> Thanks, David. That original patch was indeed by me. I am
Roland> now doing most of the strace maintenance on the sourceforge
Roland> version directly.
I'm very happy to hear that. Seems like you have made lots of nice
improvements already.
Roland> I was already planning to merge those changes in, along with
Roland> some more clone-related changes I have to handle the 2.5
Roland> threads stuff that I will finish up and merge. I will
Roland> incorporate your fixes and test it on IA64 before I commit
Roland> those changes.
Thanks!
>>>>> On Wed, 8 Jan 2003 14:20:02 -0800, Roland McGrath <roland@redhat.com> said:
>> Also, I'd recommend to use gcc-3.2 for compiling strace. I
>> encountered some strange bugs with gcc-2.96, though I did not try to
>> track them down. With gcc-3.2, those bugs went away and strace now
>> seems to work quite nicely (once again, that is).
Roland> Can you give me at least a clue what to look for?
Sure thing: what happened is that after an execve(), all syscall
result values would come out wrong (usually as 0x8000000000000000 or
-9223372036854775808). It didn't always happen, and the problem
usually went away whenever I tried to track it down by adding printfs.
I think the problem was that strace got out of sync and thought that
the program was returning from a syscall when it was actually entering
it.
--david
^ permalink raw reply
* Re: [PATCH]: Remove PF_MEMDIE as it is redundant
From: Robert Love @ 2003-01-08 23:46 UTC (permalink / raw)
To: Juan Quintela; +Cc: Marcelo Tosatti, Andrea Arcangeli, lkml
In-Reply-To: <m2lm1v6w2g.fsf@demo.mitica>
On Wed, 2003-01-08 at 18:49, Juan Quintela wrote:
> That is a nice theory, and I think that this could be true in the
> past, but in 2.4.2X, PF_MEMDIE only appears in the two places that I
> show, and it is completely redundant, look at the patch, we are just
> |-ing both PF_MEMALLOC and PF_MEMDIE and later we are &-ing against
> the or of the two. Use find & grep yourself if you don't believe me.
I realize this.
The issue is that PF_MEMALLOC can be _cleared_. In that case, if you
only set PF_MEMALLOC, that check can be false when we want it true. So
we need a flag that is more persistent.
PF_MEMDIE, which is not cleared on various allocation paths in the VM,
ensures that the check holds true for all OOM'ed tasks.
I thought the same as you, "hey this thing is worthless let us dump it",
and Rik and Andrew told me otherwise.
I am not saying you are wrong, though - I could be very wrong. But my
point is not what you say above; it is that the flag is needed because
just setting PF_MEMALLOC is insufficient since it can be unset.
Robert Love
^ permalink raw reply
* Subject: Re: Making this list more readable
From: Ian Batterbee @ 2003-01-08 23:37 UTC (permalink / raw)
To: netfilter; +Cc: Athan, Carol Anne Ogdin
>
>
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Wed, Jan 08, 2003 at 08:59:16AM -0800, Carol Anne Ogdin wrote:
>
>
>>> Is there any way to change the listserv so it doesn't convert control
>>> characters (e.g., tabs, quotes and spaces at ends of lines) to '=3Dxx'
>>> form of hex characters. It's hard to read. (I read the digest, so
>>> perhaps the problem lies there, and not in the main listserv?)
>>> Does your listserv software have a conversion table you can set that
>>> will make things more readable?
>>
>>
>
> I don't see this, and I'm getting the list direct. The =3DXX thing is
>"Quoted Printable" encoding. Probably an option on the listserv to turn
>it on/off for the digest.
>
I see the problem as well.. I think it's caused by the fact that many of
the individual messages in the are content-transfer-encoding:
quoted-printable, but the digest has no content-transfer-encoding in the
header, so the quoted-printable data inside the messages included in the
digest is treated as plain text and incorrectly formatted.
If we know that ALL messages contained in the digest are
quoted-printable, then it would just be a matter of changing the
content-type of the digest, but I've noticed the problem doesn't occur
on all messages.. some are fine.. so... I guess people's mailers are
simply posting as quoted-printable, and the digest process is just
including the message body as-is
^ permalink raw reply
* Re: File perforation.
From: Steven Whitehouse @ 2003-01-08 23:36 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-fsdevel
In-Reply-To: <23614.1042067811@passion.cambridge.redhat.com>
Hi,
>
>
> steve@gw.chygwyn.com said:
> > So presumably a suitable advice value FADV_CLEAR (for example) could
> > be used as an addition to the POSIX values ?
>
> Nothing else that fadvise() offers actually changes the file. They're all
> optional -- if the kernel ignores your fadvise() call you can't even prove
> that it's done so. I'm not sure it's a good fit.
>
Yes, I share your misgivings there. Perhaps keeping the interface idea but
giving it a different name. iadvise (for inode-advise) maybe ?
Steve.
^ permalink raw reply
* Re: Subject: Re: OT: curious about eth0/eth1
From: Tommy McNeely @ 2003-01-08 23:36 UTC (permalink / raw)
To: netfilter
In-Reply-To: <3E1CB1E0.1060708@aut.ac.nz>
--On Thursday, January 09, 2003 12:18:56 PM +1300 Ian Batterbee
<ian.batterbee@aut.ac.nz> wrote:
>> On a side note... the case you speak of is easily averted by using
>> different cards :)
>>
>> [root@pickles root]# cat /etc/modules.conf
>> alias parport_lowlevel parport_pc
>> alias eth0 3c59x
>> alias eth1 eepro100
>> alias eth2 tulip
>
>
> I'm probably missing something here, but how does that help ? The
> problem is that if that the eth0 module fails to load for whatever
> reason, then the card that would normally be eth1 would be known as eth0.
>
> If you provide aliases... all that means is that you can do
>
> modprobe eth0
> modprobe eth1
>
> but ... as far as I understand it, those module aliases names have no
> link to the name the kernel allocates to the interface, so if eth0
> failed, it would load eth1 (aliased to eepro100), and the eepro100 would
> be known as eth0 to the kernel.
>
> Or is there some kludgy relationship between module alias names and
> interface names ?
>
I assumed there was a relationship... I can't really test that from here..
but um.. I assume it would load eth1 as eepro100 ?? if you compile your
network devices into the kernel, then you may hafta get a little trickier
Tommy
PS: why doesn't my mail client treat this as a list like redhat's ?
>
>
--
Tommy McNeely -- Tommy.McNeely@Sun.COM
Sun Microsystems - IT Ops - Broomfield Campus Support
Phone: x50888 / 303-464-4888 -- Fax: 720-566-3168
^ permalink raw reply
* Re: [RFC] Change signal used to exit scsi error handlers
From: Mike Anderson @ 2003-01-08 23:36 UTC (permalink / raw)
To: Willem Riede; +Cc: linux-scsi
In-Reply-To: <20030108225302.GE1378@linnie.riede.org>
Willem Riede [wrlk@riede.org] wrote:
> On 2003.01.01 16:05 Willem Riede wrote:
> > I earlier reported, that the error handler for ide-scsi exits prematurely if modprobed
> > from rc.sysinit. I put in some debug prints to apprehend the culprit responsible for
> > sending the SIGHUP signal that causes the exit.
> >
> [snip]
> >
> > Since we want error handlers to survive, IMHO that means that the choice of signal
> > for error handler exit is unfortunate. The source of scsi_error suggests SIGPWR
> > might be a worthy alternative. I think that is true. From inspecting init source,
> > it is not capable of sending SIGPWR. SIGPWR should never be sent by dying processes
> > (its sole use should be from a power daemon _to_ init to shut the system down when
> > the juice is running out).
> >
> So nobody has any comments? But who decides whether to make this change?
> >From the source it appears that the last person to touch scsi_error.c and hosts.c
> is Mike Anderson. Does that make you the defacto maintainer, Mike?
Sorry about no reply I am just back from a very long time out of the
office and I am just catching up.
I do not know if last updates give me maintainership, but I will give
my $.02.
The change looks reasonable to switch to another signal to avoid the
problem. It is unclear why the comment mentioned only SIGPWR as the only
alternative. It would think that SIGUSR1, SIGUSR2, etc. would also work
maybe someone else on this list or linux-kernel would know why.
The logging change looks good.
-andmike
--
Michael Anderson
andmike@us.ibm.com
^ permalink raw reply
* Re: [PATCH]: Remove PF_MEMDIE as it is redundant
From: Juan Quintela @ 2003-01-08 23:49 UTC (permalink / raw)
To: Robert Love; +Cc: Marcelo Tosatti, Andrea Arcangeli, lkml
In-Reply-To: <1042066824.694.3634.camel@phantasy>
>>>>> "robert" == Robert Love <rml@tech9.net> writes:
robert> On Wed, 2003-01-08 at 17:47, Juan Quintela wrote:
>> PF_MEMDIE don't have any use in current kernels. Please
>> remove, we only set it in one place, and there we also set
>> PF_MEMALLOC. And we only test it in other place, and we also
>> test for PF_MEMALLOC. This patch has existed in aa for some
>> quite time.
robert> I independently thought this same thing, and did a patch for 2.5 which
robert> had the same effect.
robert> I was reminded by better-VM-hackers-than-I that PF_MEMALLOC can be
robert> cleared in various paths so the PF_MEMDIE is required to ensure that the
robert> check in page_alloc.c is always true for OOM'ed tasks.
That is a nice theory, and I think that this could be true in the
past, but in 2.4.2X, PF_MEMDIE only appears in the two places that I
show, and it is completely redundant, look at the patch, we are just
|-ing both PF_MEMALLOC and PF_MEMDIE and later we are &-ing against
the or of the two. Use find & grep yourself if you don't believe me.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [2.5.54] Oops generating problem.
From: Ruslan U. Zakirov @ 2003-01-08 23:40 UTC (permalink / raw)
To: linux-kernel
Hello All!
Oops printing mechanism have been broken to me in 2.5.54.
Under 2.5.5[0-3] I've got oops messages, but now it's printing
few first strings of message then printing going to loop with same
strings and after some time machine reboots.
Ruslan.
^ permalink raw reply
* 2.5.54 & 2.5.42 why does make modules_install on most /net/.. Modules ?
From: Rowan Reid @ 2003-01-08 23:35 UTC (permalink / raw)
To: Linux Kernel Mailing List
I'm running SuSE 8.0 I'm trying to utalize the IPSEC feature implimented
in the 2.4.49 and above kernel. See sample error below
depmod: *** Unresolved symbols in
/lib/modules/2.5.54/kernel/net/netlink/netlink_dev.ko
Rowan Reid
Job Captain,
Systems Administrator
STUDIO 3 ARCHITECTS
909 982 1717
^ permalink raw reply
* Re: File perforation.
From: David Woodhouse @ 2003-01-08 23:25 UTC (permalink / raw)
To: Steve Whitehouse; +Cc: linux-fsdevel
In-Reply-To: <200301082336.XAA16402@gw.chygwyn.com>
steve@gw.chygwyn.com said:
> Yes, I share your misgivings there. Perhaps keeping the interface
> idea but giving it a different name. iadvise (for inode-advise) maybe
> ?
Given that madvise and fadvise are both advisory, I'd not be a lot happier
with iadvise, to be honest.
--
dwmw2
^ permalink raw reply
* nfs client using autofs v4
From: devnull @ 2003-01-08 23:24 UTC (permalink / raw)
To: NFS; +Cc: linuxmanagers
Dear Managers,
Apologies for the cross post.
We have some linux clients running on RH 7.3 with 2.4.18, and i am trying
to mount filesystems using NIS from a mixture of
Network Appliance boxes running v2 and v3 NFS(UDP and TCP)
Dell Box running Redhat 7.3 and 2.4.20 v2 and v3(UDP ONLY)
I am running autofsv4-pre10 from www.kernel.org(mainly to get /net).
We would like to default all NFS mounts to use TCP and if not available
use UDP. This way all mounts coming from Network Appliance will be TCP and
the ones from the Linux Box will be UDP.
Does anyone know of a way of doing this.
Adding localoptions='nfsvers=3,tcp,udp' to the local autofs startup script
does not work.
Maybe this is a compile-time option to autofs(i dont see one)
Worst case, i will need to make separate "auto_master" files for the Suns
and the Linux machines(i would like to avoid this)
Many thanks,
Best Regards.
/dev/null
devnull@adc.idt.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Subject: Re: OT: curious about eth0/eth1
From: Ian Batterbee @ 2003-01-08 23:18 UTC (permalink / raw)
To: netfilter; +Cc: Tommy.McNeely
> On a side note... the case you speak of is easily averted by using
> different cards :)
>
> [root@pickles root]# cat /etc/modules.conf
> alias parport_lowlevel parport_pc
> alias eth0 3c59x
> alias eth1 eepro100
> alias eth2 tulip
I'm probably missing something here, but how does that help ? The
problem is that if that the eth0 module fails to load for whatever
reason, then the card that would normally be eth1 would be known as eth0.
If you provide aliases... all that means is that you can do
modprobe eth0
modprobe eth1
but ... as far as I understand it, those module aliases names have no
link to the name the kernel allocates to the interface, so if eth0
failed, it would load eth1 (aliased to eepro100), and the eepro100 would
be known as eth0 to the kernel.
Or is there some kludgy relationship between module alias names and
interface names ?
^ permalink raw reply
* Re: File perforation.
From: Steven Whitehouse @ 2003-01-08 23:17 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-fsdevel
In-Reply-To: <22288.1042065284@passion.cambridge.redhat.com>
Hi,
I would have thought it was the kind of thing that HSM people might be
interested in, perhaps they have some ideas for interfaces ?
Also I thought of an interface like madvise() but for
files: fadvise() and then discovered that it already exists :-)
http://www.opengroup.org/onlinepubs/007904975/functions/posix_fadvise.html
So presumably a suitable advice value FADV_CLEAR (for example) could be
used as an addition to the POSIX values ? unless there is a reason not to
overload it ? I guess preallocation could be done through the same
mechanism too if it was required.
Also I found a thread about fadvise here:
http://www.cs.helsinki.fi/linux/linux-kernel/2002-11/0031.html
Steve.
^ permalink raw reply
* [PATCH] linux-2.4.21-pre3_lost-tick_A0
From: john stultz @ 2003-01-08 23:21 UTC (permalink / raw)
To: marcelo; +Cc: lkml
Marcelo,
Occasionally due to SMIs issued by the service processor, x440s will
lose an interrupt or two. This can cause gettimeofday time
discontinuities as well as clock skew (due to jiffies not being
incremented when needed). This patch uses the cyclone timer to notice
these lost ticks and compensate for them. It only affects systems using
the cyclone timer (x440s only at the moment).
Please apply.
thanks
-john
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Wed Jan 8 11:37:13 2003
+++ b/arch/i386/kernel/time.c Wed Jan 8 11:37:13 2003
@@ -279,6 +279,7 @@
static inline void mark_timeoffset_cyclone(void)
{
int count;
+ unsigned long delta = last_cyclone_timer;
spin_lock(&i8253_lock);
/* quickly read the cyclone timer */
if(cyclone_timer)
@@ -291,6 +292,13 @@
count |= inb(0x40) << 8;
spin_unlock(&i8253_lock);
+ /*lost tick compensation*/
+ delta = last_cyclone_timer - delta;
+ if(delta > loops_per_jiffy+2000){
+ delta = (delta/loops_per_jiffy)-1;
+ jiffies += delta;
+ }
+
count = ((LATCH-1) - count) * TICK_SIZE;
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
}
^ permalink raw reply
* Re: File perforation.
From: David Woodhouse @ 2003-01-08 23:16 UTC (permalink / raw)
To: Steve Whitehouse; +Cc: linux-fsdevel
In-Reply-To: <200301082317.XAA16132@gw.chygwyn.com>
steve@gw.chygwyn.com said:
> So presumably a suitable advice value FADV_CLEAR (for example) could
> be used as an addition to the POSIX values ?
Nothing else that fadvise() offers actually changes the file. They're all
optional -- if the kernel ignores your fadvise() call you can't even prove
that it's done so. I'm not sure it's a good fit.
--
dwmw2
^ permalink raw reply
* Re: File perforation.
From: David Woodhouse @ 2003-01-08 23:14 UTC (permalink / raw)
To: Eli Carter; +Cc: linux-fsdevel
In-Reply-To: <3E1CAC90.6050303@inet.com>
eli.carter@inet.com said:
> On a compressed fs like jffs2, wouldn't a block of 0's compress down
> to next-to-nothing already?
Well, sort of. In fact each page would get zlib-compressed down to about
40-odd bytes of payload and a datanode header of 70-odd bytes.
> Can the fs recognize a big block of 0's and make it sparse on-the-fly
> without needing the user to specify it? (On block-based fs's, that
> might not always be desirable due to out-of-space errors on modifying
> a file, but for a compressed fs, that's not a new issue.)
Yeah -- JFFS2 has a special compression type for a datanode payload which
is all zeroes, but doesn't currently _detect_ that in a write, it only gets
used for holes. I was dubious about adding a check for all zeroes before
falling back to zlib, since it'll slow down the common case where we write
non-zero data. I suppose we could always compare _after_ zlib compression
though :)
The other thing about hole nodes (i.e. nodes with this special compression
type and hence no actual compressed data payload on the medium) is that
they're an exception to the rule that data nodes may not cross a page
boundary. So when we write zeroes to a file, even if we fix the compression
to notice and use JFFS2_COMPR_ZERO instead of zlib hence have no data
payload on the nodes, we still get a 70-odd-byte node header for every
(typ.) 4KiB, whereas with a 'proper' hole we'd write out a single node to
cover the whole range.
I suppose we could also munge the garbage collection to notice adjacent hole
nodes and merge them... on the whole, I think I prefer sys_perforate()
though.
--
dwmw2
^ permalink raw reply
* latest JFFS2 code with kernel 2.4.4
From: Xiaogeng (Shawn) Jin @ 2003-01-08 23:41 UTC (permalink / raw)
To: linux-mtd
Hi,
Anyone succeeded in compiling the latest JFFS2 code from CVS with kernel
2.4.4? What kind of changes should be made? I encountered lots of
compilation errors.
Thanks for any hints.
- Shawn.
^ permalink raw reply
* Re: Status of linuxppc_2.5
From: Paul Mackerras @ 2003-01-08 23:11 UTC (permalink / raw)
To: mlan; +Cc: panto, linuxppc-dev
In-Reply-To: <E18WOU9-00009Z-00@piglet.grunz.lu>
Michel Lanners writes:
> Tried to compile my standard kernel compile a while back, and found the
> following things broken (didn't have time to try fixing yet...):
>
> - 53c94 Mac SCSI
I just pushed a fix (untested) for mac53c94 scsi to linuxppc-2.5.
If you try it out, let me know how it goes.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: SCTP path mtu support needs some ip layer support.
From: David S. Miller @ 2003-01-08 23:06 UTC (permalink / raw)
To: sri; +Cc: kuznet, jgrimm2, netdev
In-Reply-To: <Pine.LNX.4.33.0301081451110.2281-100000@dyn9-47-18-86.beaverton.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST)
1. Add a new argument to ip_queue_xmit() to pass the value of DF bit.
2. Use the __unused field in skb to pass the value of DF bit.
3. Let SCTP call its own routine that fills in the ip header with the
appropriate value in the DF bit, but this duplicates most of the code
in ip_queue_xmit(). Also ip_options_build() needs to be exported.
Which option do you prefer? Or can you suggest any better alternative?
Too bad there's not a 4th option, fix SCTP. This is really broken
that the data stream can get into a state where resegmentation cannot
be performed.
Sigh... I guess the new argument to ip_queue_xmit() is the least
intrusive.
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: John Bradford @ 2003-01-08 23:14 UTC (permalink / raw)
To: John Bradford; +Cc: rddunlap, linux-kernel
In-Reply-To: <200301082303.h08N3bvI003752@darkstar.example.net>
> > > | > > What I was thinking of was a virtual device that allocated
> > > | > > a new sector whenever an old one was overwritten - kind of
> > > | > > like a journaled filesystem, but without the filesystem,
> > > | > > (I.E. just the journal) :-).
> > > | >
> > > | > $ DIR FOO.TXT;*
> > > | > FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
> > > | >
> > > | > VMS-style file versioning, anybody? ;)
> > > |
> > > | Brilliant!
> > >
> > > re-read the archives from 6-8 months ago.
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=101914252421742&w=2
>
> So basically the idea already already exists:
>
> http://www.netcraft.com.au/geoffrey/katie/
>
> Brilliant! :-)
Although I was originally thinking of doing it at sector level, rather
than at filesystem level.
John.
^ permalink raw reply
* Re: linux i386 stack trace
From: george anzinger @ 2003-01-08 22:14 UTC (permalink / raw)
To: Roets, Chris (Tru64&Linux support); +Cc: linux-kernel
In-Reply-To: <224CFA9643B4CE4BA18137CF73DB2F32010F2CD0@broexc01.emea.cpqcorp.net>
"Roets, Chris (Tru64&Linux support)" wrote:
>
> I known nothing about i386 calling conventions, but I would like to analyse a kernel stack.
>
> I have the following stack trace :
It would help a great deal if you turned on frame pointers.
In the 2.5 kernel this is a configure option. In 2.4 you
may have to modify the Makefile.
In general the function arguments are pushed on the stack
(right to left) followed by the call which pushes the return
address. If frame pointers are used, the called function
then pushes ebp and then loads ebp with the current stack
address. This allows you to, given ebp, walk back the the
stack to each function. Locals pushed on the stack after
the ebp reg....
But some functions don't save the frame pointer even if
turned on, notably the interrupt and asm code around
interrupt and trap handling.
-g
>
> STACK TRACE FOR TASK: 0xc4cb6000(vi)
>
> 0 schedule+770 [0xc01130e2]
> 1 schedule_timeout+18 [0xc0112d42]
> 2 do_select+513 [0xc0140a11]
> 3 sys_select+820 [0xc0140db4]
> 4 system_call+44 [0xc0106f14]
> ebx: 00000001 ecx: bffff700 edx: 00000000 esi: bffff680
> edi: 00000000 ebp: bffff798 eax: 0000008e ds: 002b
> es: 002b eip: 4010e0ee cs: 0023 eflags: 00000202
> esp: bffff630 ss: 002b
> ================================================================
>
> >> dump -x 3301670612 40
> 0xc4cb7ed4: c4cb7f00
> c4cb6000
> 00000000
> c29f3000
> 0xc4cb7ee4: c4cb6000
> 00000000
> c0274000
> c02b2540
> 0xc4cb7ef4: 7fffffff
> 7fffffff
> 00000000
> c4cb7f30
> 0xc4cb7f04: c0112d47 schedule_timeout+23
> c29f3000
> cc75e914
> c4cb7f54
> 0xc4cb7f14: 00000000
> c8dde7c4
> 00000001
> c4cb7f90
> 0xc4cb7f24: 00000000
> 00000000
> 7fffffff
> 00000000
> 0xc4cb7f34: c0140a16 do_select+518
> c4cb7f54
> 00000001
> c4cb6000
> 0xc4cb7f44: 7fffffff
> 00000001
> 00000000
> 00000001
> 0xc4cb7f54: 00000000
> c730f000
> 00000001
> bffff684
> 0xc4cb7f64: c17d83ec
> 00000001
> c0140db9 sys_select+825
> 00000001
>
> can anybody point me out where the arguments and the local variables are ?
> take for example
> int do_select(int n, fd_set_bits *fds, long *timeout)
> {
> poll_table table, *wait;
> int retval, i, off;
> long __timeout = *timeout;
>
> ......
> I t has 3 arguments and tree local variable
> I would be nice to have the same for ia64
>
> Chris
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* SCTP path mtu support needs some ip layer support.
From: Sridhar Samudrala @ 2003-01-08 23:04 UTC (permalink / raw)
To: davem, kuznet; +Cc: jgrimm2, netdev
Dave, Alexey,
While working on the SCTP path mtu support, i realized that SCTP needs a
mechanism to set/unset IP DF bit on a per-message basis(let ip_queue_xmit()
know that it is OK to fragment this particular skb).
With TCP, when path mtu discovery is on, DF bit is always set and hence
this information can be maintained on a per socket basis in the inet_opt.
But with SCTP, even when path mtu discovery is on, DF bit may need to be
unset and let ip do fragmenation of certain messages which are already
fragmented by sctp based on the old pmtu. Even when SCTP realizes that the
pmtu is lowered, it cannot re-fragment the already fragmented messages that
have TSNs(Transmission Sequence Nos) assigned. These messages may be waiting
in the transmitted list and may need to be retransmitted later.
I can think of 3 ways to solve this problem.
1. Add a new argument to ip_queue_xmit() to pass the value of DF bit.
2. Use the __unused field in skb to pass the value of DF bit.
3. Let SCTP call its own routine that fills in the ip header with the
appropriate value in the DF bit, but this duplicates most of the code
in ip_queue_xmit(). Also ip_options_build() needs to be exported.
Which option do you prefer? Or can you suggest any better alternative?
Thanks
Sridhar
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: David S. Miller @ 2003-01-08 23:03 UTC (permalink / raw)
To: torvalds; +Cc: levon, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301081502270.7688-100000@penguin.transmeta.com>
From: Linus Torvalds <torvalds@transmeta.com>
Date: Wed, 8 Jan 2003 15:04:05 -0800 (PST)
System binaries match the kernel. It's as easy as that. So what if 90% of
the user binaries use 32-bit mode because it's smaller and faster? We're
talking about a system binary that is _very_ intimate with the kernel.
oprofile can perfectly legitimately be used to monitor 32-bit binaries
running on under a 64-bit kernel environment. In fact I expect such
exercises to be very instructive. Anton Blanchard has done this
already on ppc64.
And being that 64-bit sparc systems run several orders of magnitude
faster than 32-bit ones, I think I'd prefer to oprofile 32-bit
programs on sparc64 boxes :-)
Hey, if this is so distasteful we could just add a
sys_kernel_pointer_size() to sparc64 and ppc64 and be done with it.
The other choice, as mentioned, is to make every platform use u64's
in the tables.
^ permalink raw reply
* Re: File perforation.
From: David Woodhouse @ 2003-01-08 23:02 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-fsdevel
In-Reply-To: <20030108225551.G26554@parcelfarce.linux.theplanet.co.uk>
willy@debian.org said:
> However, I think this is probably the ugliest method available to
> perform this function.
Indeed. That's probably even worse than sendfile() from /dev/zero :)
--
dwmw2
^ permalink raw reply
* disabling module version support
From: ransom . @ 2003-01-08 22:58 UTC (permalink / raw)
To: linux-admin
How does one compile a kernel without version support? [ie- one that won't
complain if a module with a different version number is loaded]
Basically, I want a kernel that allows me to
# insmod ./hello.o
without this:
# insmod hellomodule.o
hellomodule.o: kernel-module version mismatch
hellomodule.o was compiled for kernel version 2.4.18
while this kernel is version 2.4.20.
as described in the first couple of paragraphs in chapter 2 of oreilly's
"Linux device drivers, which can be found here:
http://www.xml.com/ldd/chapter/book/ch02.html
I've tried the following:
# insmod -f hellomodule.o
Warning: kernel-module version mismatch
hellomodule.o was compiled for kernel version 2.4.18
while this kernel is version 2.4.20
Warning: loading hellomodule.o will taint the kernel: no license
See http://www.tux.org/lkml/#export-tainted for information about tainted
modules
Warning: loading hellomodule.o will taint the kernel: forced load
Module hellomodule loaded, with warnings
# rmmod hellomodule
so that's great, EXCEPT I didn't get the messages printed to stdout that I
was supposed to as described in the Linux Device Drivers book
(http://www.xml.com/ldd/chapter/book/ch02.html)
eg-
save
#define MODULE
#include <linux/module.h>
int init_module(void) { printk("<1>Hello, world\n"); return 0; }
void cleanup_module(void) { printk("<1>Goodbye cruel world\n"); }
as hello.c (or whatever name), then
root# gcc -c hello.c
root# insmod ./hello.o
Hello, world
root# rmmod hello
Goodbye cruel world
root#
"Hello, world", as you can see in my ACTUAL output, didn't appear on screen.
Perhaps this is a programming issue? But it seems as though a proper
configuration would allow me to duplicate what's in the book.
Many thanks for you help!
_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.