* Re: [Qemu-devel] Network Performance between Win Host and Linux Guest
From: Kazu @ 2006-03-08 4:52 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <440CAD5B.7070109@helmutauer.de>
[-- Attachment #1: Type: text/plain, Size: 556 bytes --]
Tuesday, March 07, 2006 6:44 AM Helmut Auer wrote:
> vdr@helmutauer.de schrieb:
>> Hello,
>> I just upgraded to qemu 0.8.0 including vlan/tap patch and I noticed that
the network speed is much slower than under 0.7.2 with tap patch ( 300KB/s
vs 1MB/s ).
>> Any hints what I can do to sped this up ?
>> Helmut
>>
> No ideas what can cause this ? I just checked it again with the tapped
> win binaries from the dion page. Net performance is about 15 times
> faster under 0.7.2
>
Attached patch improves the performance against current CVS.
Regards,
Kazu
[-- Attachment #2: qemu-20060307-tap.patch --]
[-- Type: application/octet-stream, Size: 2149 bytes --]
Index: tap-win32.c
===================================================================
RCS file: /sources/qemu/qemu/tap-win32.c,v
retrieving revision 1.2
diff -u -r1.2 tap-win32.c
--- tap-win32.c 19 Feb 2006 12:40:00 -0000 1.2
+++ tap-win32.c 7 Mar 2006 04:18:44 -0000
@@ -642,7 +642,7 @@
}
/* XXX: horrible, suppress this by using proper thread signaling */
-void tap_win32_poll(void)
+int tap_win32_poll(void)
{
TAPState *s = tap_win32_state;
uint8_t *buf;
@@ -650,13 +650,14 @@
int size;
if (!s)
- return;
+ return -1;
size = tap_win32_read(s->handle, &buf, max_size);
if (size > 0) {
qemu_send_packet(s->vc, buf, size);
tap_win32_free_buffer(s->handle, buf);
}
+ return size;
}
int tap_win32_init(VLANState *vlan, const char *ifname)
Index: vl.c
===================================================================
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.165
diff -u -r1.165 vl.c
--- vl.c 20 Feb 2006 00:33:36 -0000 1.165
+++ vl.c 7 Mar 2006 04:18:49 -0000
@@ -3960,8 +3960,11 @@
#ifdef _WIN32
/* XXX: see how to merge it with the select. The constraint is
that the select must be interrupted by the timer */
- if (timeout > 0)
- Sleep(timeout);
+ ret = tap_win32_poll();
+ if (ret <= 0) {
+ if (timeout > 0)
+ Sleep(timeout);
+ }
#endif
/* poll any events */
/* XXX: separate device handlers from system ones */
@@ -4002,9 +4005,6 @@
}
}
}
-#ifdef _WIN32
- tap_win32_poll();
-#endif
#if defined(CONFIG_SLIRP)
/* XXX: merge with the previous select() */
Index: vl.h
===================================================================
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.105
diff -u -r1.105 vl.h
--- vl.h 20 Feb 2006 00:33:36 -0000 1.105
+++ vl.h 7 Mar 2006 04:18:50 -0000
@@ -307,7 +307,7 @@
/* TAP win32 */
int tap_win32_init(VLANState *vlan, const char *ifname);
-void tap_win32_poll(void);
+int tap_win32_poll(void);
/* NIC info */
^ permalink raw reply
* Re: [PATCH] 64bit unaligned access on 32bit kernel
From: Atsushi Nemoto @ 2006-03-08 4:58 UTC (permalink / raw)
To: ralf; +Cc: akpm, linux-mips, linux-kernel
In-Reply-To: <20060307180907.GA13577@linux-mips.org>
>>>>> On Tue, 7 Mar 2006 18:09:07 +0000, Ralf Baechle <ralf@linux-mips.org> said:
ralf> Below's fix results in exactly the same code size on all
ralf> compilers and configurations I've tested it.
ralf> I also have another more elegant fix which as a side effect
ralf> makes get_unaligned work for arbitrary data types but it that
ralf> one results in a slight code bloat:
I tested the patch attached on several MIPS kernel (big/little,
32bit/64bit) with gcc 3.4.5. In most (but not all) case, Ralf's fix
resulted better than the previous fix.
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
Atsushi Nemoto
^ permalink raw reply
* Re: Fw: Re: oops in choose_configuration()
From: Dmitry Torokhov @ 2006-03-08 4:44 UTC (permalink / raw)
To: joe.korty
Cc: Linus Torvalds, Chuck Ebbert, Andrew Morton, Greg KH, Ingo Molnar,
linux-kernel
In-Reply-To: <20060308042841.GA16822@tsunami.ccur.com>
On Tuesday 07 March 2006 23:28, Joe Korty wrote:
> On Tue, Mar 07, 2006 at 04:57:39PM -0800, Linus Torvalds wrote:
>
> > Well, snprintf() should be safe, though. It will warn if the caller is
> > lazy, but these days, the thing does
> >
> > max(buf_size - len, 0)
> >
> > which should mean that the input layer passes in 0 instead of a negative
> > number. And snprintf() will then _not_ print anything.
>
> I assume this is a typo, and you meant scnprintf? AFAIK, snprintf has
> the same ol' bad behavior when #bytes-to-be-written > #bytes-in-buffer.
>
No, we do want to know if output was truncated or not so snprintf is used.
--
Dmitry
^ permalink raw reply
* probably you
From: Aurelia @ 2006-03-08 4:37 UTC (permalink / raw)
To: sparclinux
Hire,
i am here sitting in the internet caffe. Found your email and
decided to write. I might be coming to your place in 14 days,
so I decided to email you. May be we can meet? I am 25 y.o.
girl. I have! a picature if you want. No ne!e!d to reply here as
this is not my email. Write me at ufflh@nicerealmail.info
^ permalink raw reply
* Re: Pulling tags from git.git
From: A Large Angry SCM @ 2006-03-08 4:32 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <440DA82D.3060909@op5.se>
Andreas Ericsson wrote:
> A Large Angry SCM wrote:
>> Andreas Ericsson wrote:
>>
>>> Junio C Hamano wrote:
>>>
>>>> Andreas Ericsson <ae@op5.se> writes:
>>>>
>>>>
>>>>> With the git or git+ssh protocol, tags will be autofollowed
>>>>> when you do a pull (only signed tags, I think). The
>>>>> auto-following is done by detecting tags that are fetched,
>>>>
>>>>
>>>>
>>>> Ah, you are correct. We do not follow lightweight tags; I am
>>>> not sure if we should.
>>>>
>>>
>>> I'm fairly sure we shouldn't. The default update-hook prevents them
>>> (if enabled), and I can't for the life of me think of why anyone
>>> would want to distribute such tags.
>>>
>>> OTOH, preventing unannotated tags from being pushed seems like a
>>> better way than to not have the ability to auto-follow those same
>>> tags. After all, it's better to discourage than to disallow.
>>>
>>
>> Before you do this, please explain why unannotated tags are not
>> useful, and so should not be allowed to be pushed.
>
>
> Imagine Linus, getting his "please pull" emails and doing so only to
> find dozens of temporary tags fetched by the pull. Junio's patch (if I
> read it correctly) unconditionally fetches *ALL* tags reachable from the
> top of the commit-chain, which means there is no longer any way to keep
> temporary tags in a repo from which someone else will pull.
Why is a "pull" bothering with tags? A "fetch" yes, but not a pull.
> I for one riddle my repos with temporary tags whenever I'm trying
> something I'm not so sure of, or find an interesting bug or a design
> decision I'm not 100% sure of. Perhaps I should rather do this with
> branches, but imo branches are for doing work, whereas tags just mark a
> spot in the development so I easily can find them with gitk or some such.
>
> I may be biased by the way we do things at work. In our workflow, all
> tags meant to be distributed have a short note in them which explains
> the rationale of the tag. For example, new versions have a very brief
> changelog that sales-people get on email (a blessing, that, since we
> devs no longer have to update feature-lists and such).
>
> Tags not meant to be distributed are unannotated, and unannotated tags
> are kept out of published repos which are always stored at a central
> server. Everybody synchronize to those central repos, so nobody pulls
> from each other. Perhaps this is how the kernel devs work too, but if it
> ever changes the update hook will no longer be able to safeguard from it
> and the, in my eyes, temporary tags will be distributed in a
> criss-crossing mesh so no-one will ever know where it came from or who
> created it or why. I.e. a Bad Thing.
The distinction here is not annotated tags or temporary tags but _local_
tags. _Your_ workflow conventions treat unannotated tags as local tags
but declaring that unannotated tags can not be pushed is imposing _your_
conventions on other groups. Just as branch names, themselves, can be
meaningful, so can tag names.
^ permalink raw reply
* [PATCH] Fix the NX bit support issue for PAE/64bit guest on x86-64
From: Xin, Xiaohui @ 2006-03-08 4:32 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 398 bytes --]
With this patch, the PAE/64bit guest on x86-64 can support NX bit
successfully.
The PAE guest can run on SMP 64-bit Xen0 now.
And it optimizes the save/restore action for EFER MSR during the context
switch.
Signed-off-by: Jun Nakajima jun.nakajima@intel.com
Signed-off-by: Xiaohui Xin xiaohui.xin@intel.com
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
[-- Attachment #1.2: Type: text/html, Size: 3484 bytes --]
[-- Attachment #2: 0307-3.diff --]
[-- Type: application/octet-stream, Size: 2235 bytes --]
diff -r 583d01868d17 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Mon Mar 6 22:50:30 2006
+++ b/xen/arch/x86/hvm/vmx/vmx.c Tue Mar 7 17:07:50 2006
@@ -223,6 +223,11 @@
switch (regs->ecx){
case MSR_EFER:
+ /* offending reserved bit will cause #GP */
+ if ( msr_content &
+ ~( EFER_LME | EFER_LMA | EFER_NX | EFER_SCE ) )
+ vmx_inject_exception(vc, TRAP_gp_fault, 0);
+
if ((msr_content & EFER_LME) ^
test_bit(VMX_CPU_STATE_LME_ENABLED,
&vc->arch.hvm_vmx.cpu_state)){
@@ -236,18 +241,9 @@
if (msr_content & EFER_LME)
set_bit(VMX_CPU_STATE_LME_ENABLED,
&vc->arch.hvm_vmx.cpu_state);
- /* No update for LME/LMA since it have no effect */
+
msr->msr_items[VMX_INDEX_MSR_EFER] =
msr_content;
- if (msr_content & ~(EFER_LME | EFER_LMA)){
- msr->msr_items[VMX_INDEX_MSR_EFER] = msr_content;
- if (!test_bit(VMX_INDEX_MSR_EFER, &msr->flags)){
- rdmsrl(MSR_EFER,
- host_state->msr_items[VMX_INDEX_MSR_EFER]);
- set_bit(VMX_INDEX_MSR_EFER, &host_state->flags);
- set_bit(VMX_INDEX_MSR_EFER, &msr->flags);
- }
- }
break;
case MSR_FS_BASE:
diff -r 583d01868d17 xen/arch/x86/shadow.c
--- a/xen/arch/x86/shadow.c Mon Mar 6 22:50:30 2006
+++ b/xen/arch/x86/shadow.c Tue Mar 7 17:07:50 2006
@@ -3583,6 +3583,11 @@
ASSERT( d->arch.ops->guest_paging_levels >= PAGING_L3 );
+#if CONFIG_PAGING_LEVELS >= 4
+ if ( (error_code & (ERROR_I | ERROR_P)) == (ERROR_I | ERROR_P) )
+ return 1;
+#endif
+
#if CONFIG_PAGING_LEVELS == 4
if ( d->arch.ops->guest_paging_levels == PAGING_L4 )
{
diff -r 583d01868d17 xen/include/asm-x86/shadow_64.h
--- a/xen/include/asm-x86/shadow_64.h Mon Mar 6 22:50:30 2006
+++ b/xen/include/asm-x86/shadow_64.h Tue Mar 7 17:07:50 2006
@@ -51,8 +51,11 @@
#define READ_FAULT 0
#define WRITE_FAULT 1
-#define ERROR_W 2
+#define ERROR_P 1
+#define ERROR_W 2
#define ERROR_U 4
+#define ERROR_I (1 << 4)
+
#define X86_64_SHADOW_DEBUG 0
#if X86_64_SHADOW_DEBUG
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Fw: Re: oops in choose_configuration()
From: Joe Korty @ 2006-03-08 4:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chuck Ebbert, Dmitry Torokhov, Andrew Morton, Greg KH,
Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0603071648430.32577@g5.osdl.org>
On Tue, Mar 07, 2006 at 04:57:39PM -0800, Linus Torvalds wrote:
> Well, snprintf() should be safe, though. It will warn if the caller is
> lazy, but these days, the thing does
>
> max(buf_size - len, 0)
>
> which should mean that the input layer passes in 0 instead of a negative
> number. And snprintf() will then _not_ print anything.
I assume this is a typo, and you meant scnprintf? AFAIK, snprintf has
the same ol' bad behavior when #bytes-to-be-written > #bytes-in-buffer.
Joe
^ permalink raw reply
* Re: [PATCH] fix kexec asm
From: Eric W. Biederman @ 2006-03-08 4:16 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-kernel, akpm, mmlnx
In-Reply-To: <200603072135.16116.mason@suse.com>
Chris Mason <mason@suse.com> writes:
> From: Michael Matz <matz@suse.de>
>
> While testing kexec and kdump we hit problems where the new kernel would
> freeze or instantly reboot. The easiest way to trigger it was to kexec a
> kernel compiled for CONFIG_M586 on an athlon cpu. Compiling
> for CONFIG_MK7 instead would work fine.
>
> The patch below fixes a few problems with the kexec inline asm.
Thanks. Specifying the stomp of %eax in load_segments is definitely
good. The memory stomp looks excessive and if this was a fast path
I would worry about it. As it is better safe than sorry.
Acked-By: Eric Biederman <ebiederm@xmission.com>
Eric
^ permalink raw reply
* Re: SATA ATAPI AHCI error messages?
From: Jeff Garzik @ 2006-03-08 4:13 UTC (permalink / raw)
To: Gaston, Jason D; +Cc: linux-kernel, linux-ide@vger.kernel.org
In-Reply-To: <26CEE2C804D7BE47BC4686CDE863D0F50660ABA5@orsmsx410>
Gaston, Jason D wrote:
> Hello,
>
> We are seeing the following error messages in dmesg with the 2.6.16-rc5
> kernel. I have also tried to apply the git10 patch and still see the
> same errors. This is seen using a Plextor PX-716SA or PX-712SA SATA
> DVDRW drive when in AHCI mode. I do not see this message when the SATA
> controller is set to IDE mode, in the BIOS. I have reproduced this
> using Intel ICH6R, ICH7R and ICH8 SATA controllers. I have
> atapi_enabled=1 set in the libata-core.c file. These error messages
> continue to be repeatedly logged about every 2 seconds. Can someone
> tell me what is going on and if this will be addressed in the next RC
> release of the 2.6.16 kernel?
>
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> ata2: translated ATA stat/err 0x51/24 to SCSI SK/ASC/ASCQ 0xb/00/00
> sr0: CDROM (ioctl) error, command: <6>Test Unit Ready 00 00 00 00 00 00
> sr: Current [descriptor]: sense key: Aborted Command
> Additional sense: No additional sense information
Probably its just too chatty, since ATAPI throws a lot of errors...
Jeff
^ permalink raw reply
* [KJ] First of several spelling/grammar/typo patches
From: Rocco Stanzione @ 2006-03-08 4:11 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
This is my first post here, so I'm just going to attach the first of a number
of patches I've split up by directory, since there's no real logical
grouping. They all essentially address spelling, grammar and typographical
issues in code comments and documentation. Please let me know if there are
any problems with my patch, the way I'm attaching it, whether it survives
email transfer intact, etc. Also if there are any fundamental problems with
what I'm doing, please let me know before I spam the list with the rest of
the patches.
This one deals with the 'net' directory off the root of the kernel source
tree.
Thanks,
Rocco Stanzione
[-- Attachment #2: net.diff --]
[-- Type: text/x-diff, Size: 10098 bytes --]
diff -Nurp linux-2.6.15.6/net/8021q/vlan.c linux-2.6.15.6.new/net/8021q/vlan.c
--- linux-2.6.15.6/net/8021q/vlan.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/8021q/vlan.c 2006-03-06 20:26:32.000000000 -0600
@@ -523,7 +523,7 @@ static struct net_device *register_vlan_
grp->vlan_devices[VLAN_ID] = new_dev;
- if (vlan_proc_add_dev(new_dev)<0)/* create it's proc entry */
+ if (vlan_proc_add_dev(new_dev)<0)/* create its proc entry */
printk(KERN_WARNING "VLAN: failed to add proc entry for %s\n",
new_dev->name);
diff -Nurp linux-2.6.15.6/net/8021q/vlan.h linux-2.6.15.6.new/net/8021q/vlan.h
--- linux-2.6.15.6/net/8021q/vlan.h 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/8021q/vlan.h 2006-03-06 20:27:03.000000000 -0600
@@ -35,7 +35,7 @@ extern unsigned short vlan_name_type;
#define VLAN_GRP_HASH_MASK (VLAN_GRP_HASH_SIZE - 1)
/* Find a VLAN device by the MAC address of its Ethernet device, and
- * it's VLAN ID. The default configuration is to have VLAN's scope
+ * its VLAN ID. The default configuration is to have VLAN's scope
* to be box-wide, so the MAC will be ignored. The mac will only be
* looked at if we are configured to have a separate set of VLANs per
* each MAC addressable interface. Note that this latter option does
diff -Nurp linux-2.6.15.6/net/ax25/TODO linux-2.6.15.6.new/net/ax25/TODO
--- linux-2.6.15.6/net/ax25/TODO 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/ax25/TODO 2006-03-06 20:18:16.000000000 -0600
@@ -14,7 +14,7 @@ get around the removal of SOCKOPS_WRAP.
implemented.
The ax25_rt_find_route synopsys is pervert but I somehow had to deal with
-the race caused by the static variable in it's previous implementation.
+the race caused by the static variable in its previous implementation.
Implement proper socket locking in netrom and rose.
diff -Nurp linux-2.6.15.6/net/bridge/br_sysfs_br.c linux-2.6.15.6.new/net/bridge/br_sysfs_br.c
--- linux-2.6.15.6/net/bridge/br_sysfs_br.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/bridge/br_sysfs_br.c 2006-03-06 20:27:33.000000000 -0600
@@ -309,7 +309,7 @@ static struct bin_attribute bridge_forwa
*
* Note: the ifobj exists only to be a subdirectory
* to hold links. The ifobj exists in same data structure
- * as it's parent the bridge so reference counting works.
+ * as its parent the bridge so reference counting works.
*/
int br_sysfs_addbr(struct net_device *dev)
{
diff -Nurp linux-2.6.15.6/net/core/pktgen.c linux-2.6.15.6.new/net/core/pktgen.c
--- linux-2.6.15.6/net/core/pktgen.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/core/pktgen.c 2006-03-06 20:20:09.000000000 -0600
@@ -307,9 +307,9 @@ struct pktgen_dev {
* are transmitting the same one multiple times
*/
struct net_device* odev; /* The out-going device. Note that the device should
- * have it's pg_info pointer pointing back to this
+ * have its pg_info pointer pointing back to this
* device. This will be set when the user specifies
- * the out-going device name (not when the inject is
+ * the outgoing device name (not when the inject is
* started as it used to do.)
*/
struct flow_state *flows;
diff -Nurp linux-2.6.15.6/net/ipv4/inet_connection_sock.c linux-2.6.15.6.new/net/ipv4/inet_connection_sock.c
--- linux-2.6.15.6/net/ipv4/inet_connection_sock.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/ipv4/inet_connection_sock.c 2006-03-06 20:21:52.000000000 -0600
@@ -104,7 +104,7 @@ int inet_csk_get_port(struct inet_hashin
goto fail;
/* OK, here is the one we will use. HEAD is
- * non-NULL and we hold it's mutex.
+ * non-NULL and we hold its mutex.
*/
snum = rover;
} else {
diff -Nurp linux-2.6.15.6/net/ipv4/tcp_ipv4.c linux-2.6.15.6.new/net/ipv4/tcp_ipv4.c
--- linux-2.6.15.6/net/ipv4/tcp_ipv4.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/ipv4/tcp_ipv4.c 2006-03-06 20:21:08.000000000 -0600
@@ -1127,7 +1127,7 @@ static int tcp_v4_checksum_init(struct s
}
-/* The socket must have it's spinlock held when we get
+/* The socket must have its spinlock held when we get
* here.
*
* We have a potential double-lock case here, so even when
diff -Nurp linux-2.6.15.6/net/ipv6/addrconf.c linux-2.6.15.6.new/net/ipv6/addrconf.c
--- linux-2.6.15.6/net/ipv6/addrconf.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/ipv6/addrconf.c 2006-03-06 20:23:34.000000000 -0600
@@ -3735,7 +3735,7 @@ int __init addrconf_init(void)
int err = 0;
/* The addrconf netdev notifier requires that loopback_dev
- * has it's ipv6 private information allocated and setup
+ * has its ipv6 private information allocated and setup
* before it can bring up and give link-local addresses
* to other devices which are up.
*
diff -Nurp linux-2.6.15.6/net/ipv6/netfilter/ip6t_dst.c linux-2.6.15.6.new/net/ipv6/netfilter/ip6t_dst.c
--- linux-2.6.15.6/net/ipv6/netfilter/ip6t_dst.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/ipv6/netfilter/ip6t_dst.c 2006-03-06 20:22:41.000000000 -0600
@@ -85,7 +85,7 @@ match(const struct sk_buff *skb,
hdrlen = ipv6_optlen(oh);
if (skb->len - ptr < hdrlen){
- /* Packet smaller than it's length field */
+ /* Packet smaller than its length field */
return 0;
}
diff -Nurp linux-2.6.15.6/net/ipv6/netfilter/ip6t_hbh.c linux-2.6.15.6.new/net/ipv6/netfilter/ip6t_hbh.c
--- linux-2.6.15.6/net/ipv6/netfilter/ip6t_hbh.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/ipv6/netfilter/ip6t_hbh.c 2006-03-06 20:23:05.000000000 -0600
@@ -85,7 +85,7 @@ match(const struct sk_buff *skb,
hdrlen = ipv6_optlen(oh);
if (skb->len - ptr < hdrlen){
- /* Packet smaller than it's length field */
+ /* Packet smaller than its length field */
return 0;
}
diff -Nurp linux-2.6.15.6/net/ipv6/tcp_ipv6.c linux-2.6.15.6.new/net/ipv6/tcp_ipv6.c
--- linux-2.6.15.6/net/ipv6/tcp_ipv6.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/ipv6/tcp_ipv6.c 2006-03-06 20:22:19.000000000 -0600
@@ -1416,7 +1416,7 @@ static int tcp_v6_checksum_init(struct s
return 0;
}
-/* The socket must have it's spinlock held when we get
+/* The socket must have its spinlock held when we get
* here.
*
* We have a potential double-lock case here, so even when
diff -Nurp linux-2.6.15.6/net/irda/irttp.c linux-2.6.15.6.new/net/irda/irttp.c
--- linux-2.6.15.6/net/irda/irttp.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/irda/irttp.c 2006-03-06 20:25:06.000000000 -0600
@@ -1627,7 +1627,7 @@ static void irttp_do_data_indication(str
err = self->notify.data_indication(self->notify.instance, self, skb);
- /* Usually the layer above will notify that it's input queue is
+ /* Usually the layer above will notify that its input queue is
* starting to get filled by using the flow request, but this may
* be difficult, so it can instead just refuse to eat it and just
* give an error back
diff -Nurp linux-2.6.15.6/net/llc/llc_if.c linux-2.6.15.6.new/net/llc/llc_if.c
--- linux-2.6.15.6/net/llc/llc_if.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/llc/llc_if.c 2006-03-06 20:17:36.000000000 -0600
@@ -38,7 +38,7 @@ u8 llc_mac_null_var[IFHWADDRLEN];
* will be locked and received frames and expired timers will be queued.
* Returns 0 for success, -ECONNABORTED when the connection already
* closed and -EBUSY when sending data is not permitted in this state or
- * LLC has send an I pdu with p bit set to 1 and is waiting for it's
+ * LLC has send an I pdu with p bit set to 1 and is waiting for its
* response.
*/
int llc_build_and_send_pkt(struct sock *sk, struct sk_buff *skb)
@@ -75,7 +75,7 @@ out:
* Upper layer calls this to establish an LLC connection with a remote
* machine. This function packages a proper event and sends it connection
* component state machine. Success or failure of connection
- * establishment will inform to upper layer via calling it's confirm
+ * establishment will inform to upper layer via calling its confirm
* function and passing proper information.
*/
int llc_establish_connection(struct sock *sk, u8 *lmac, u8 *dmac, u8 dsap)
diff -Nurp linux-2.6.15.6/net/sctp/sm_statefuns.c linux-2.6.15.6.new/net/sctp/sm_statefuns.c
--- linux-2.6.15.6/net/sctp/sm_statefuns.c 2006-03-05 13:07:54.000000000 -0600
+++ linux-2.6.15.6.new/net/sctp/sm_statefuns.c 2006-03-06 23:36:09.000000000 -0600
@@ -3683,7 +3683,7 @@ sctp_disposition_t sctp_sf_violation(con
* Handle a protocol violation when the chunk length is invalid.
* "Invalid" length is identified as smaller then the minimal length a
* given chunk can be. For example, a SACK chunk has invalid length
- * if it's length is set to be smaller then the size of sctp_sack_chunk_t.
+ * if its length is set to be smaller then the size of sctp_sack_chunk_t.
*
* We inform the other end by sending an ABORT with a Protocol Violation
* error code.
@@ -4460,7 +4460,7 @@ sctp_disposition_t sctp_sf_do_9_2_shutdo
* 2) called when SCTP_EVENT_NO_PENDING_TSN event is issued.
*
* For the case (2), the arg parameter is set to NULL. We need
- * to check that we have a chunk before accessing it's fields.
+ * to check that we have a chunk before accessing its fields.
*/
if (chunk) {
if (!sctp_vtag_verify(chunk, asoc))
@@ -5297,7 +5297,7 @@ static int sctp_eat_data(const struct sc
return SCTP_IERROR_NO_DATA;
}
- /* If definately accepting the DATA chunk, record its TSN, otherwise
+ /* If definitely accepting the DATA chunk, record its TSN, otherwise
* wait for renege processing.
*/
if (SCTP_CMD_CHUNK_ULP == deliver)
[-- Attachment #3: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: [RFC][PATCH] kdump: x86_64 timer interrupt lockup due to pending interrupt
From: Eric W. Biederman @ 2006-03-08 4:04 UTC (permalink / raw)
To: vgoyal
Cc: Andi Kleen, linux kernel mailing list, Fastboot mailing list,
Andrew Morton
In-Reply-To: <20060308012654.GB25543@in.ibm.com>
Vivek Goyal <vgoyal@in.ibm.com> writes:
> On Tue, Mar 07, 2006 at 04:43:07PM -0700, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@in.ibm.com> writes:
>> > On Mon, Mar 06, 2006 at 10:43:32PM +0100, Andi Kleen wrote:
>> >> On Mon, Mar 06, 2006 at 11:40:34AM -0500, Vivek Goyal wrote:
>> >> >
>
> [..]
>> >> >
>> >> > o In this patch, one extra EOI is being issued in check_timer() to unlock
>> > the
>> >> > vector. Please suggest if there is a better way to handle this situation.
>> >>
>> >> Shouldn't we rather do this for all interrupts when the APIC is set up?
>> >> I don't see how the timer is special here.
>> >>
>> >
>> > Timer is a special case here.
>> >
>> > In other cases, the moment interrupts are enabled on cpu, LAPIC pushes
> pending
>> > interrupts to cpu and it is ignored as bad irq using ack_bad_irq(). This
>> > still sends EOI to LAPIC if LPAIC support is compiled in.
>> >
>> > But for timer, the moment pending interrupt is pushed to cpu, it is handled
>> > as valid interrupt and cpu assumes that it came from 8259 and sends ack to
>> > 8259 and not to LAPIC. Hence leads to missing EOI for timer vector and
>> > deadlock.
>> >
>> > But still doing it generic manner for all interrupts while setting up LAPIC
>> > probably makes more sense. Please find attached the patch.
>>
>> A couple of questions.
>>
>> Does this need to be in #ifdef CONFIG_CRASS_DUMP?
>> If this code is truly safe I expect we could run it on every bootup
>> simply to be more robust.
>>
>
> AFAIK, we can run this code safely on every bootup and can get rid of
> CONFIG_CRASH_DUMP. I have simply put it under it because I observed it
> only for crashdump scenarios. But removing this should be good as it
> protectets agains buggy boards. Modified patch is attached.
>
>
>> Why is APIC_ISR_NR a hard code? I think there is an apic register
>> that tells the count.
>>
>
> I did not find any such register. Basically ISR is a 256bit register. We
> are reading 32 bits at a time, so logically we can view it as 8, 32 bit
> registers. I had two options. Either I put a constant number in for()
> loop or #define it. I chose later one.
>
>> Does ack_APIC_irq take an argument? I am confused that we are calling
>> ack_APIC_irq() potentially 8*32 times without passing it anything.
>>
>
> It does not take any argument. Whenever a zero is written to EOI register
> LAPIC resets one ISR register bit corresponding to highest priority
> interrupt. So if all the ISR bits are set, we will call ack_APIC_irq()
> 8*32 times to reset them all.
Ok. That makes sense.
Looks good to me.
Eric
^ permalink raw reply
* Sound userspace drivers (fishing for insight)
From: John Richard Moser @ 2006-03-08 4:02 UTC (permalink / raw)
To: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This isn't really a serious question, but I just encountered some stuff
about userspace sound drivers for Linux and was like O_o so now I'm
curious as to the design aspect here. I can't think of a good way to do
it (where 'good' means something more than 'ugly hack').
So here's my input on this, and if anyone cares to enlighten me maybe
you can bounce some responses back. It'll be a good learning experience
for me.
- General transport and context switches
In general, transporting sound data in and out of kernel space is a
horrid thought. Consider the latencies, which all real-time audio
people will quickly get angry about. Write sound; context switch; sound
in driver; context switch back. This over and over? Now we all know
better than that.
So my first impulse would be using the generic kernel-user transport
facilities like NETLNK. But at a glance this doesn't seem to do
anything for me; this would still be writing to a socket, which causes a
syscall into kernel space. In short, you're stuck with context switches.
On the up-side, in any scheme the user space program has to shift data
into the kernel; with alsa it's written to a /proc interface, which
causes a context switch into kernel space AFAIK because it calls write()
to an fd. Still, we're wasting time copying to another process' memory
space.
- Ring-1, Ring-2
I have heard that these mysterious privilege levels allow bitmaps to
give direct hardware access, i.e. to PCI devices. Through this mystical
magic, a driver could directly access a sound card. This opens up new
possibilities. . or does it?
First off how the heck complex is userspace PCI control, and what gains
do you really get? Won't every syscall() become a sudden context
switch? Or (as I suspect and would like to find out) does the "overhead
of context switching" mainly imply the copy_from_user() function and the
process of rewriting a lot of PTEs into a new privilege level (kernel
instead of user)?
Assuming that you can implement direct hardware access or at least
direct access to memory to avoid the context switch (in the manner I'm
assuming the latency comes from), this may become actually faster.
Still you're copying memory from Ring-3 (user) to Ring-1 or Ring-2, so
there are no gains here.
- Shared mapping?
If my assumption on how this works is correct, then copy_from_user() is
difficult because you have to walk the range of passed VM addresses and
change/copy affected PTEs. The old PTEs become non-writable
(copy-on-write trigger) and the new PTEs are created (non-writable CoW
and of course Ring-3 privilege) for the kernel.
This assumption brings an interesting thought: what about a shared
mapping? An area of memory writable by userspace and readable by the
kernel? This seems silly. Under the assumptions I've made, this would
still require CoWing existing PTEs or flat out copying things over.
Obviously I lack understanding of the problem; none of this solves
anything, and this is typical overhead whenever you allocate memory,
even from userspace.
So we come to an interesting thought: I've found yet another
interesting bit of kernel design that I don't understand, and am curious
of. I understand basic memory management concepts and preemptive
multitasking just because of pestering the LKML from time to time; might
as well go for a little more and see if you guys bite again. Any takers?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRA5XQws1xW0HCTEFAQLr7g//Yqnj5hIbANQR/SsiirkLhYAcM7DC3lGe
vi50fu7YZSwaDNJ/NKWjHVmiuI1UWLehEe6n8BWHYR9tq0JzNzwwpEPUWUxIv7tp
TsKKWR4uP8YYbFoFoNo8zK/kJQiV0ynVvuBCVCYm3OUqBi8hIqKut0GgyZc4qo7M
aOmq3mFlw5zITfYV2pYVq9ttTU2ZJ36pXU4gJJi0+V5KVO51ZuAXDxDB6oaLewq7
csayDae/yy9Aene44fSSuO+bfS6JPNq9uTXS42v0bcYkZm+DppSTaZcPetj1cMcU
qM1d/0jh6bQwVpDRb7A7xumP+TfQM7J8/5rR2TFTpgc63qA1Fyzu5qd/hJ9xz28A
pum/36ZbF/fiLR5qwMB3tlwN9z6f1MrEmEzOKtCap/Mq3IklSnyc429mpTs8smjZ
WzbRaLU2rNxgL2KFDOZvhrfN0PP4nu+DDSauTmYdaSHfdNQ0tlvZAapq8SMQy5LU
VAY3ZDEMP4qAIGMfXTRR49JAuM0OLWpV/fXeE9Uwv0KIyomfw/TJvW20O2vblN06
Ryj4HGwELeaZpc+D8E6eWXSllX/16qp5zgXAFnNgvBAXfRnaKPzSnhNOdEozNhxM
oFk3Kf9PoyEn3fqRFXJi+f9o02VvDAEY/6EOwsALUOAWADqbW+D/ku7MKEMt7pFT
Jo/dyODrxfA=
=YKVj
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Fw: Re: oops in choose_configuration()
From: Linus Torvalds @ 2006-03-08 4:01 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Greg KH, linux-kernel, Ingo Molnar, Andrew Morton,
Dmitry Torokhov
In-Reply-To: <200603072230_MC3-1-BA18-21AC@compuserve.com>
On Tue, 7 Mar 2006, Chuck Ebbert wrote:
>
> [2] The snprintf() and print_modalias() calls don't check for errors and
> thus don't return -ENOMEM when the buffer does fill up. Shouldn't they
> do that instead of returning a truncated env string?
They try to act like the standard says "snprintf()" should act.
And yes, the standard says to return the number of bytes you _would_ have
written, had not the buffer been to small.
(Of course, giving a negative buffer length is not ok, and the kernel
version checking for that is a kernel extension on the standard. In the
standard, the buffer size is a "size_t", which doesn't have the notion of
"negative", since it's an unsigned type. The kernel version is just being
safe and nice).
Linus
^ permalink raw reply
* Fwd: [PATCH] add support for PANJIT TouchSet USB Touchscreen Device
From: Lanslott Gish @ 2006-03-08 3:57 UTC (permalink / raw)
To: linux-kernel, linux-usb-devel, Greg KH
In-Reply-To: <38c09b90603071742i4e1463b8sa332fb79dd67f10d@mail.gmail.com>
---------- Forwarded message ----------
From: Lanslott Gish <lanslott.gish@gmail.com>
Date: Mar 8, 2006 9:42 AM
Subject: Re: [PATCH] add support for PANJIT TouchSet USB Touchscreen Device
To: Dmitry Torokhov <dtor_core@ameritech.net>
yes, i wrote this module from the same source model.
but as i know, there are two products designs from two corps.
or maybe modified a better name avoid mess?
anybody any idea? ;)
best rgds,
Lanslott Gish
On 3/7/06, Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> On Monday 06 March 2006 04:14, Lanslott Gish wrote:
> > hi,
> >
> > this is the first version of the patch from a newbie :)
> > add support for PANJIT TouchSet USB touchscreen device.
> >
>
> Hi,
>
> I am reading this and it looks like twin brother of touchkitusb.c
> Is there any chance we can combine these together?
>
> --
> Dmitry
>
--
L.G, Life is Good~
--
L.G, Life is Good~
^ permalink raw reply
* Power management questions...
From: Tehn Yit Chin @ 2006-03-08 3:55 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
Hi all,
1) suspending/resuming
I am putting some power managment coding into my alsa driver. When I want to
suspend, I inform ALSA via the following two calls.
snd_pcm_suspend_all(card->pcm);
snd_power_change_state(card->card, SNDRV_CTL_POWER_D3cold);
When I am doing a resume, I would have assumed that they is an equivalent to
snd_pcm_suspend_all(), but all I could find snd_pcmd_resume() which is
usually OK, but this is declared as a static as in
static int snd_pcm_resume(snd_pcm_substream_t *substream)
At the moment, all I am doing when I am resuming is to call
snd_power_change_state(card->card, SNDRV_CTL_POWER_D0);
This seems to be working, but I think that I am doing the wrong thing.
2) SND_PCM_TRIGGER_SUSPEND and SND_PCM_TRIGGER_RESUME
If I follow the call tree down for snd_pcm_suspend_call(), it calls a
trigger callback with a command of SND_PCM_TRIGGER_SUSPEND. A similiar thing
occurs for resume where the trigger callback is called with the command of
SND_PCM_TRIGGER_RESUME. Should I handling these two commands in my trigger
callback and manage the DMA transfer accordingly?
any pointers is appreciated.
thanks,
Tehn Yit Chin
[-- Attachment #2: Type: text/html, Size: 1258 bytes --]
^ permalink raw reply
* Re: Memory barriers and spin_unlock safety
From: Linus Torvalds @ 2006-03-08 3:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: David Howells, akpm, linux-arch, bcrl, matthew, linux-kernel,
mingo, linuxppc64-dev, jblunck
In-Reply-To: <17422.19865.635112.820824@cargo.ozlabs.ibm.com>
On Wed, 8 Mar 2006, Paul Mackerras wrote:
>
> Linus Torvalds writes:
>
> > So the rules from the PC side (and like it or not, they end up being
> > what all the drivers are tested with) are:
> >
> > - regular stores are ordered by write barriers
>
> I thought regular stores were always ordered anyway?
For the hw, yes. For the compiler no.
So you actually do end up needing write barriers even on x86. It won't
compile to any actual _instruction_, but it will be a compiler barrier (ie
it just ends up being an empty inline asm that "modifies" memory).
So forgetting the wmb() is a bug even on x86, unless you happen to program
in assembly.
Of course, the x86 hw semantics _do_ mean that forgetting it is less
likely to cause problems, just because the compiler re-ordering is fairly
unlikely most of the time.
> > - PIO stores are always synchronous
>
> By synchronous, do you mean ordered with respect to all other accesses
> (regular memory, MMIO, prefetchable MMIO, PIO)?
Close, yes. HOWEVER, it's only really ordered wrt the "innermost" bus. I
don't think PCI bridges are supposed to post PIO writes, but a x86 CPU
basically won't stall for them forever. I _think_ they'll wait for it to
hit that external bus, though.
So it's totally serializing in the sense that all preceding reads have
completed and all preceding writes have hit the cache-coherency point, but
you don't necessarily know when the write itself will hit the device (the
write will return before that necessarily happens).
> In other words, if I store a value in regular memory, then do an
> outb() to a device, and the device does a DMA read to the location I
> just stored to, is the device guaranteed to see the value I just
> stored (assuming no other later store to the location)?
Yes, assuming that the DMA read is in respose to (ie causally related to)
the write.
> > - MMIO stores are ordered by IO semantics
> > - PCI ordering must be honored:
> > * write combining is only allowed on PCI memory resources
> > that are marked prefetchable. If your host bridge does write
> > combining in general, it's not a "host bridge", it's a "host
> > disaster".
>
> Presumably the host bridge doesn't know what sort of PCI resource is
> mapped at a given address, so that information (whether the resource
> is prefetchable) must come from the CPU, which would get it from the
> TLB entry or an MTRR entry - is that right?
Correct. Although it could of course be a map in the host bridge itself,
not on the CPU.
If the host bridge doesn't know, then the host bridge had better not
combine or the CPU had better tell it not to combine, using something like
a "sync" instruction that causes bus traffic. Either of those approaches
is likely a performance disaster, so you do want to have the CPU and/or
hostbridge do this all automatically for you.
Which is what the PC world does.
> Or is there some gentleman's agreement between the host bridge and the
> BIOS that certain address ranges are only used for certain types of
> PCI memory resources?
Not that I know. I _think_ all of the PC world just depends on the CPU
doing the write combining, and the CPU knows thanks to MTRR's and page
tables. But I could well imagine that there is some situation where the
logic is further out.
> What ordering is there between stores to regular memory and stores to
> non-prefetchable MMIO?
Non-prefetchable MMIO will be in-order on x86 wrt regular memory (unless
you use one of the non-temporal stores).
To get out-of-order stores you have to use a special MTRR setting (mtrr
type "WC" for "write combining").
Or possibly non-temporal writes to an uncached area. I don't think we do.
> If a store to regular memory can be performed before a store to MMIO,
> does a wmb() suffice to enforce an ordering, or do you have to use
> mmiowb()?
On x86, MMIO normally doesn't need memory barriers either for the normal
case (see above). We don't even need the compiler barrier, because we use
a "volatile" pointer for that, telling the compiler to keep its hands off.
> Do PCs ever use write-through caching on prefetchable MMIO resources?
Basically only for frame buffers, with MTRR rules (and while write-through
is an option, normally you'd use "write-combining", which doesn't cache at
all, but write combines in the write buffers and writes the combined
results out to the bus - there's usually something like four or eight
write buffers of up to a cacheline in size for combining).
Yeah, I realize this can be awkward. PC's actually get good performance
(ie they normally can easily fill the bus bandwidth) _and_ the sw doesn't
even need to do anything. That's what you get from several decades of hw
tweaking with a fixed - or almost-fixed - software base.
I _like_ PC's. Almost every other architecture decided to be lazy in hw,
and put the onus on the software to tell it what was right. The PC
platform hardware competition didn't allow for the "let's recompile the
software" approach, so the hardware does it all for you. Very well too.
It does make it somewhat hard for other platforms.
Linus
^ permalink raw reply
* Re: Fw: Re: oops in choose_configuration()
From: Dmitry Torokhov @ 2006-03-08 3:48 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Greg KH, linux-kernel, Ingo Molnar, Andrew Morton, Linus Torvalds
In-Reply-To: <200603072230_MC3-1-BA18-21AC@compuserve.com>
On Tuesday 07 March 2006 22:29, Chuck Ebbert wrote:
> In-Reply-To: <20060308005455.GA23921@kroah.com>
>
> On Tue, 7 Mar 2006 16:54:55 -0800, Greg KH wrote:
>
> > On Tue, Mar 07, 2006 at 04:54:24PM -0500, Chuck Ebbert wrote:
> > > At least one susbsystem rolls its own method of adding env vars to the
> > > uevent buffer, and it's so broken it triggers the WARN_ON() in
> > > lib/vsprintf.c::vsnprintf() by passing a negative length to that function.
> > > Start at drivers/input/input.c::input_dev_uevent() and watch the fun.
> >
> > All of the INPUT_ADD_HOTPLUG_VAR() calls do use add_uevent_var(), so we
> > should be safe there. The other calls also look safe, if not a bit
> > wierd... So I don't see how we could change this to be any safer, do
> > you?
>
> input.c line 747+ was recently added and caused the error message:
>
> [1]=> envp[i++] = buffer + len;
> [2]=> len += snprintf(buffer + len, buffer_size - len, "MODALIAS=");
> [2]=> len += print_modalias(buffer + len, buffer_size - len, dev) + 1;
>
> [1]=> envp[i] = NULL;
> return 0;
>
> [1] What is checking for enough space here? This didn't overflow AFAICT
> but it could.
>
> [2] The snprintf() and print_modalias() calls don't check for errors and
> thus don't return -ENOMEM when the buffer does fill up. Shouldn't they
> do that instead of returning a truncated env string? Only the final
> sanity test in snprintf() keeps them from overrunning the buffer.
> (It was print_modalias_bits() that actually caused the overflow.)
>
I agree with all of the above, it will be fixed.
--
Dmitry
^ permalink raw reply
* Ax25 start up
From: Doug @ 2006-03-08 3:44 UTC (permalink / raw)
To: linux-hams
I have managed to re configure the 2.4 kernel for Ham Radio. The next
problem I must overcome, is the start up of the Ax25 stuff. I loaded
the Ax25,Netrom, and Mkiss as modules. I load these modules using the
etc/rc.d/ rc.local file. However during the boot process, when it comes
to Ax25 it flashes the failed message. When I try to copy packets
using the /usr/bin/ listen command it tells me the ax25 port information
is not configured. If I go into /etc/rc.d/ and run the file rc.ax25 in
a terminal, the listen command then works as it should. It would appear
that the modules are loaded after the initialization of the rc.ax25
file. The question is, how can I start the modules earlier or start
the rc.ax25 after the modules?? All necessary RPMs have been previously
loaded.
I am using RH8 and kernel 2.4.18-14 on a Compaq PII/400.
---------------
I have come up with a work around solution. It appears the error on
the original boot up when the ax25 stuff is being loaded or looked at,
the system was looking for mkiss to set up my ports. mkiss was set to
run via modprobe in the /etc/rd.d/rc.local file along with ax25 and
netrom. I moved the command modprobe mkiss to the top of the
/etc/rc.d/rc.ax25 file and now the system boots up just fine with
no error flag and the listen command works as it should. Can anyone
see a problem with this solution??
Cheers
Doug VE5DA
^ permalink raw reply
* About [PATCH] ptrace/coredump/exit_group deadlock
From: Wu Zhou @ 2006-03-08 3:45 UTC (permalink / raw)
To: andrea; +Cc: linux-kernel
Hi Andrea,
I am recently tracking a problem showing first in kernel 2.6.15 that
ptraced multithreaded exec dies with a spurious SIGKILL (the url is
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177240).
In this case, the child thread calls execve to run a user specified
command. When running in ptraced environment (e.g. strace -f -o log
./threadexec /bin/echo hi), the process dies by SIGKILL immediately
after execing the command (/bin/echo in this example).
After some tracking, I found that it might be related with your patch
in http://marc.theaimsgroup.com/?l=linux-kernel&m=112833915827432&w=2,
titled "ptrace/coredump/exit_group deadlock". After reversing your
patch, the case runs ok.
The SIGKILL is sent in ptrace_untrace when sys_execve call flush_old_exec
to flush the old executable. In that process, signal->flags of threadexec
is set to SIGNAL_GROUP_EXIT by zap_other_threads. And the following code
send the fatal SIGKILL to threadexec, so it dies.
+ if (child->signal->flags & SIGNAL_GROUP_EXIT) {
+ sigaddset(&child->pending.signal, SIGKILL);
+ signal_wake_up(child, 1);
+ }
I am not sure if I understand all these code. But I see that you
mentioned that "The __ptrace_unlink does nothing because the signal->flags
is set to SIGNAL_GROUP_EXIT|SIGNAL_STOP_DEQUEUED". Maybe the above code
should change to something like this:
+ if (child->signal->flags & (SIGNAL_GROUP_EXIT|SIGNAL_STOP_DEQUEUED) ) {
+ sigaddset(&child->pending.signal, SIGKILL);
+ signal_wake_up(child, 1);
+ }
That is just my guess anyway. Forgive me if it is incorrect.
BTW, you mentioned a gdb bug report which can reproduce the deadlock you are
trying to fix. Can you give me a pointer to that? That will be helpful
for me to understand more cleanly about the problem. Thanks in advance.
Appended is the source code of the above mentioned testcase:
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
#include <stdlib.h>
struct args {
char **argv;
char **envp;
};
// Child thread
static void *
exec_args (void *arg)
{
struct args *args = arg;
printf ("this is in child thread\n");
execve (args->argv[1], args->argv + 1, args->envp);
/* Reaching here implies an error. */
perror ("execve");
exit (1);
}
int
main (int argc, char **argv, char **envp)
{
if (argc < 2) {
printf ("Usage: %s command args ...\n", argv[0]);
return 1;
}
struct args args;
args.argv = argv;
args.envp = envp;
pthread_t thread;
if (pthread_create (&thread, NULL, exec_args, &args)) {
perror ("pthread_create");
exit (1);
}
void *retval;
if (pthread_join (thread, &retval)) {
perror ("pthread_join");
exit (1);
}
/* Should this ever be reached? */
exit (1);
}
Just for you reference.
Regards
- Wu Zhou
P.S: please include me in the cc-list. I don't subscribe to the mail list
yet.
^ permalink raw reply
* Re: [PATCH 3/3] Zach's core aio changes to support vectored AIO
From: Benjamin LaHaise @ 2006-03-08 3:37 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Zach Brown, christoph, lkml, linux-fsdevel
In-Reply-To: <1141777459.17095.41.camel@dyn9047017100.beaverton.ibm.com>
On Tue, Mar 07, 2006 at 04:24:19PM -0800, Badari Pulavarty wrote:
> This work is initially done by Zach Brown to add support for
> vectored aio. These are the core changes for AIO to support
> IOCB_CMD_PREADV/IOCB_CMD_PWRITEV.
Please, please, please send patches inline so they can be quoted. In
any case, there's a bug in the PREADV/WRITEV code in that it doesn't
check the selinux security bits for the file.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Automated reply to the submission of abuse incident
From: Covad Network Abuse Team @ 2006-03-08 3:35 UTC (permalink / raw)
To: linux-mm
This is an automated reply to the submission of your network abuse incident. Please take time to read it carefully because it provides insight to your reported incident and guidelines for future submissions to the Covad Network Abuse Team.
Covad's Policy on Network Abuse: We would like to thank you for bringing this matter to our attention. We take network abuse very seriously within the Covad domain, and we apologize for any inconvenience this has caused you. Due to the large number of complaints we receive, we may not provide any further response regarding this incident. However, Covad investigates each reported incident of abuse, and we will take all appropriate action to warn, suspend, and/or terminate a subscriber that has violated Covad's Acceptable Use Policy or Terms of Service.
Covad's Guidelines for Reporting Suspected Network Abuse: When reporting a network abuse incident to Covad's Network Abuse Team you must follow the submission guidelines below to expedite the investigation process. If you fail to follow these guidelines we may not process your request or we may be delayed in processing your request. We process abuse requests on a First-In-First-Out basis, prioritized by the level of network abuse a customer is experiencing. Also, please do not submit more than one request per network abuse incident. This will ensure that each occurrence is addressed in the most efficient manner possible.
Network Abuse Submission Guidelines
1. Provide a brief, general description of the network abuse incident.
2. Include all logs or information relevant to the incident; ensure the logs you're submitting contain:
a. Date of incident
b. Time of incident and time zone
c. Source Internet protocol (IP) address or host name
d. Destination IP addresses or host name
e. Destination port
3. For e-mail abuse (i.e., Spam), include full-unmodified header information and content of the email. Header information is a requirement for reporting e-mail abuse. Without the header information, the Abuse Team cannot determine the true originator of the e-mail and will be unable to take any action. If you are unsure how to extract a full-unmodified header, please visit http://spamcop.net/fom-serve/cache/19.html for instructions to support your mail client.
4. For alleged off topic (non-spam) or commercial Usenet postings, we also need full un-modified headers of the Usenet posting including the body of the offending message. If you are unsure how to view the full-unmodified headers of the Usenet post, consult the help section of your newsreader software or your news provider.
Covad cannot investigate an incident of network abuse without the information requested above. In addition, Covad only investigates incidents of network abuse regarding Covad subscribers. Non-subscribers should be reported to their appropriate ISP for network abuse resolution. Please be advised that Covad does not disclose personally identifiable information about our subscribers except as may be required or permitted by law or authorized by our subscribers. As a result, information pertaining to particular subscriber(s) or specific actions taken in regard to Abuse complaints may not be disclosed. However, Covad is committed to identifying alleged offenders and taking all appropriate action to ensure compliance with our Acceptable Use Policy and other Terms of Service.
Sincerely,
The Covad Network Abuse Team
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Fw: Re: oops in choose_configuration()
From: Chuck Ebbert @ 2006-03-08 3:29 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Ingo Molnar, Andrew Morton, Linus Torvalds,
Dmitry Torokhov
In-Reply-To: <20060308005455.GA23921@kroah.com>
On Tue, 7 Mar 2006 16:54:55 -0800, Greg KH wrote:
> On Tue, Mar 07, 2006 at 04:54:24PM -0500, Chuck Ebbert wrote:
> > At least one susbsystem rolls its own method of adding env vars to the
> > uevent buffer, and it's so broken it triggers the WARN_ON() in
> > lib/vsprintf.c::vsnprintf() by passing a negative length to that function.
> > Start at drivers/input/input.c::input_dev_uevent() and watch the fun.
>
> All of the INPUT_ADD_HOTPLUG_VAR() calls do use add_uevent_var(), so we
> should be safe there. The other calls also look safe, if not a bit
> wierd... So I don't see how we could change this to be any safer, do
> you?
input.c line 747+ was recently added and caused the error message:
[1]=> envp[i++] = buffer + len;
[2]=> len += snprintf(buffer + len, buffer_size - len, "MODALIAS=");
[2]=> len += print_modalias(buffer + len, buffer_size - len, dev) + 1;
[1]=> envp[i] = NULL;
return 0;
[1] What is checking for enough space here? This didn't overflow AFAICT
but it could.
[2] The snprintf() and print_modalias() calls don't check for errors and
thus don't return -ENOMEM when the buffer does fill up. Shouldn't they
do that instead of returning a truncated env string? Only the final
sanity test in snprintf() keeps them from overrunning the buffer.
(It was print_modalias_bits() that actually caused the overflow.)
> Are you still seeing problems now?
Wasn't me, it was Horst Schirmeier <horst@schirmeier.com>
--
Chuck
"Penguins don't come from next door, they come from the Antarctic!"
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers
From: Linus Torvalds @ 2006-03-08 3:30 UTC (permalink / raw)
To: Paul Mackerras
Cc: David Howells, akpm, mingo, linux-arch, linuxppc64-dev,
linux-kernel
In-Reply-To: <17422.19209.60360.178668@cargo.ozlabs.ibm.com>
On Wed, 8 Mar 2006, Paul Mackerras wrote:
>
> Linus explained recently that wmb() on x86 does not order stores to
> system memory w.r.t. stores to stores to prefetchable I/O memory (at
> least that's what I think he said ;).
In fact, it won't order stores to normal memory even wrt any
_non-prefetchable_ IO memory.
PCI (and any other sane IO fabric, for that matter) will do IO posting, so
the fact that the CPU _core_ may order them due to a wmb() doesn't
actually mean anything.
The only way to _really_ synchronize with a store to an IO device is
literally to read from that device (*). No amount of memory barriers will
do it.
So you can really only order stores to regular memory wrt each other, and
stores to IO memory wrt each other. For the former, "smp_wmb()" does it.
For IO memory, normal IO memory is _always_ supposed to be in program
order (at least for PCI. It's part of how the bus is supposed to work),
unless the IO range allows prefetching (and you've set some MTRR). And if
you do, that, currently you're kind of screwed. mmiowb() should do it, but
nobody really uses it, and I think it's broken on x86 (it's a no-op, it
really should be an "sfence").
A full "mb()" is probably most likely to work in practice. And yes, we
should clean this up.
Linus
(*) The "read" can of course be any event that tells you that the store
has happened - it doesn't necessarily have to be an actual "read[bwl]()"
operation. Eg the store might start a command, and when you get the
completion interrupt, you obviously know that the store is done, just from
a causal reason.
^ permalink raw reply
* [PATCH] ftruncate on huge page couldn't extend hugetlb file
From: Zhang, Yanmin @ 2006-03-08 3:24 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: David Gibson, Chen, Kenneth W
In-Reply-To: <1141787660.29825.83.camel@ymzhang-perf.sh.intel.com>
From: Zhang Yanmin <yanmin.zhang@intel.com>
Currently, ftruncate on hugetlb files couldn't extend them. My patch enables it.
This patch is against 2.6.16-rc5-mm3 and on the top of the patch which
implements mmap on zero-length hugetlb files with PROT_NONE.
Thanks for Ken's good idea.
Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
---
diff -Nraup linux-2.6.16-rc5-mm3_huge_check/fs/hugetlbfs/inode.c linux-2.6.16-rc5-mm3_truncate/fs/hugetlbfs/inode.c
--- linux-2.6.16-rc5-mm3_huge_check/fs/hugetlbfs/inode.c 2006-03-08 18:17:15.000000000 +0800
+++ linux-2.6.16-rc5-mm3_truncate/fs/hugetlbfs/inode.c 2006-03-08 18:50:40.000000000 +0800
@@ -308,18 +308,22 @@ static int hugetlb_vmtruncate(struct ino
unsigned long pgoff;
struct address_space *mapping = inode->i_mapping;
- if (offset > inode->i_size)
- return -EINVAL;
-
BUG_ON(offset & ~HPAGE_MASK);
pgoff = offset >> HPAGE_SHIFT;
-
- inode->i_size = offset;
- spin_lock(&mapping->i_mmap_lock);
- if (!prio_tree_empty(&mapping->i_mmap))
- hugetlb_vmtruncate_list(&mapping->i_mmap, pgoff);
- spin_unlock(&mapping->i_mmap_lock);
- truncate_hugepages(inode, offset);
+ if (offset > inode->i_size) {
+ if (hugetlb_extend_reservation(HUGETLBFS_I(inode), pgoff) != 0)
+ return -ENOMEM;
+ inode->i_size = offset;
+ }
+ else {
+
+ inode->i_size = offset;
+ spin_lock(&mapping->i_mmap_lock);
+ if (!prio_tree_empty(&mapping->i_mmap))
+ hugetlb_vmtruncate_list(&mapping->i_mmap, pgoff);
+ spin_unlock(&mapping->i_mmap_lock);
+ truncate_hugepages(inode, offset);
+ }
return 0;
}
^ permalink raw reply
* Re: [patch 2/4] net: percpufy frequently used vars -- struct proto.memory_allocated
From: Andrew Morton @ 2006-03-08 3:22 UTC (permalink / raw)
To: Ravikiran G Thirumalai; +Cc: linux-kernel, davem, netdev, shai
In-Reply-To: <20060308030803.GF9062@localhost.localdomain>
Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>
> On Tue, Mar 07, 2006 at 06:14:22PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> > >
> > > - if (atomic_read(sk->sk_prot->memory_allocated) < sk->sk_prot->sysctl_mem[0]) {
> > > + if (percpu_counter_read(sk->sk_prot->memory_allocated) <
> > > + sk->sk_prot->sysctl_mem[0]) {
> >
> > Bear in mind that percpu_counter_read[_positive] can be inaccurate on large
> > CPU counts.
> >
> > It might be worth running percpu_counter_sum() to get the exact count if we
> > think we're about to cause something to fail.
>
> The problem is percpu_counter_sum has to read all the cpus cachelines. If
> we have to use percpu_counter_sum everywhere, then might as well use plain
> per-cpu counters instead of batching ones no?
I didn't say "use it everywhere" ;)
Just in places like this:
if (percpu_counter_read(something) > something_else)
make_an_application_fail();
in that case it's worth running percpu_counter_sum(). And bear in mind
that once we've done that, the following percpu_counter_read()s become
accurate, so we won't run the expensive percpu_counter_sum() again
for a while. Unless we're really close to or over the limit, in which case
blowing a few cycles is relatively unimportant.
All that should be captured in library code (per_cpu_counter_exceeds(ptr,
threshold), for example) rather than open-coded everywhere.
> sysctl_mem[0] is about 196K and on a 16 cpu box variance is 512 bytes, which
> is OK with just percpu_counter_read I hope.
You mean a 16 CPU box with NR_CPUS=16 as well...
> Maybe, on very large cpu counts,
> we should just change the FBC_BATCH so that variance does not go quadratic.
> Something like 32. So that variance is 32 * NR_CPUS in that case, instead
> of (NR_CPUS * NR_CPUS * 2) currently. Comments?
Sure, we need to make that happen. But it got all mixed up with the
spinlock removal and it does need quite some thought and testing and
documentation to help developers to choose the right settings and
appropriate selection of defaults, etc.
^ 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.