* Re: patches for fsample/850
From: tony @ 2006-04-09 18:36 UTC (permalink / raw)
To: Brian Swetland; +Cc: linux-omap-open-source
In-Reply-To: <20060408154425.GA24843@localhost.localdomain>
Hi,
Few comments below.
* Brian Swetland <swetland@google.com> [060408 08:45]:
> --- linux-omap-2.6/arch/arm/mach-omap1/clock.h 2006-04-05 10:33:20.000000000 -0700
> +++ linux-omap-fsample/arch/arm/mach-omap1/clock.h 2006-04-06 13:15:34.000000000 -0700
> @@ -101,44 +101,50 @@
> /*-------------------------------------------------------------------------
> * Omap1 MPU rate table
> *-------------------------------------------------------------------------*/
> +#if defined(CONFIG_ARCH_OMAP730)
> + #define CKCTL_RESERVED_1_MASK (0x2000)
> +#else
> + #define CKCTL_RESERVED_1_MASK (0x0000)
> +#endif
This addds yet another extra hurdle compiling 730 in with 15xx and 16xx.
Although we cannot do it because of the interrupt handler, maybe we'll
fix that someday. So let's try not to add more hurdles if we can avoid
it.
How about doing the masking when the CKCTL value is written based on the
cpu_is_omap730()?
> --- linux-omap-2.6/arch/arm/mach-omap1/pm.c 2006-04-05 10:33:20.000000000 -0700
> +++ linux-omap-fsample/arch/arm/mach-omap1/pm.c 2006-04-06 13:15:34.000000000 -0700
> @@ -326,8 +326,10 @@
> /* stop DSP */
> omap_writew(omap_readw(ARM_RSTCT1) & ~(1 << DSP_EN), ARM_RSTCT1);
>
> +#if !defined(CONFIG_ARCH_OMAP730)
> /* shut down dsp_ck */
> omap_writew(omap_readw(ARM_CKCTL) & ~(1 << EN_DSPCK), ARM_CKCTL);
> +#endif
This too would be better with if (!cpu_is_omap730()).
> @@ -189,8 +197,6 @@
> omap_writel(value, OMAP730_IO_CONF_4);
>
> omap_uwire_configure_mode(0,16);
> -
> - omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISOFF, 9, 0,NULL,1);
> omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_SLPIN, 9, 0,NULL,1);
> omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISNOR, 9, 0,NULL,1);
> omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_GSSET, 9, 0,NULL,1);
Is the removal of one of the omap_uwire_data_transfer() calls intended?
Then does it compile and boot for p2 and fsample both selected?
Also, could you please do one patch for the core support, and then
another patch for files that don't touch the omap core files?
That way we can send you patch directly upstream when we merge next
time. Otherwise I have to redo the patch to strip out the drivers when
we merge as not many omap drivers are yet merged with the mainline tree.
Core files being arch/arm/*omap* and include/asm-arm/arch-omap:
arch/arm/mach-omap1/Kconfig
arch/arm/mach-omap1/Makefile
arch/arm/mach-omap1/board-fsample.c
arch/arm/mach-omap1/clock.c
arch/arm/mach-omap1/clock.h
arch/arm/mach-omap1/pm.c
arch/arm/mach-omap1/time.c
arch/arm/plat-omap/devices.c
include/asm-arm/arch-omap/board-fsample.h
include/asm-arm/arch-omap/hardware.h
Regards,
Tony
^ permalink raw reply
* Re: 2.6.17-rc1-mm2: badness in 3w_xxxx driver
From: Andrew Morton @ 2006-04-09 18:32 UTC (permalink / raw)
To: Nick Orlov; +Cc: linux-kernel, axboe, James.Bottomley
In-Reply-To: <20060409182306.GA4680@nickolas.homeunix.com>
Nick Orlov <bugfixer@list.ru> wrote:
>
> The following patch: x86-kmap_atomic-debugging.patch exposed a badness
> in 3w_xxx driver.
Sweet, thanks.
> I'm getting a lot of:
>
> Apr 9 13:00:04 nickolas kernel: kmap_atomic: local irqs are enabled while using KM_IRQn
> Apr 9 13:00:04 nickolas kernel: <c0104103> show_trace+0x13/0x20 <c010412e> dump_stack+0x1e/0x20
> Apr 9 13:00:04 nickolas kernel: <c01159c9> kmap_atomic+0x79/0xe0 <c028b885> tw_transfer_internal+0x85/0xa0
> Apr 9 13:00:04 nickolas kernel: <c028ca7e> tw_interrupt+0x3fe/0x820 <c0143b9e> handle_IRQ_event+0x3e/0x80
> Apr 9 13:00:04 nickolas kernel: <c0143c70> __do_IRQ+0x90/0x100 <c01057a6> do_IRQ+0x26/0x40
> Apr 9 13:00:04 nickolas kernel: <c010396e> common_interrupt+0x1a/0x20 <c0101cdd> cpu_idle+0x4d/0xb0
> Apr 9 13:00:04 nickolas kernel: <c010f2cc> start_secondary+0x24c/0x4b0 <00000000> 0x0
> Apr 9 13:00:04 nickolas kernel: <c214ffb4> 0xc214ffb4
>
> I'm running 32 bit kernel on AMD64x2 w/ HIGHMEM enabled.
> I think this is an old bug since the 3w_xxxx.c has not been changed for
> a long time (at least since 2.6.16-rc1-mm4).
>
> Please let me know if you want me to try some patches.
>
From: Andrew Morton <akpm@osdl.org>
We must disable local IRQs while holding KM_IRQ0 or KM_IRQ1. Otherwise, an
IRQ handler could use those kmap slots while this code is using them,
resulting in memory corruption.
Thanks to Nick Orlov <bugfixer@list.ru> for reporting.
Cc: <linuxraid@amcc.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/scsi/3w-xxxx.c | 3 +++
1 files changed, 3 insertions(+)
diff -puN drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix drivers/scsi/3w-xxxx.c
--- devel/drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix 2006-04-09 11:28:08.000000000 -0700
+++ devel-akpm/drivers/scsi/3w-xxxx.c 2006-04-09 11:29:21.000000000 -0700
@@ -1508,10 +1508,12 @@ static void tw_transfer_internal(TW_Devi
struct scsi_cmnd *cmd = tw_dev->srb[request_id];
void *buf;
unsigned int transfer_len;
+ unsigned long flags = 0;
if (cmd->use_sg) {
struct scatterlist *sg =
(struct scatterlist *)cmd->request_buffer;
+ local_irq_save(flags);
buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
transfer_len = min(sg->length, len);
} else {
@@ -1526,6 +1528,7 @@ static void tw_transfer_internal(TW_Devi
sg = (struct scatterlist *)cmd->request_buffer;
kunmap_atomic(buf - sg->offset, KM_IRQ0);
+ local_irq_restore(flags);
}
}
_
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Brad Campbell @ 2006-04-09 18:35 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443825D8.3080602@win4lin.com>
Leonardo E. Reiter wrote:
> This is by no means a complete patch (do not apply it as it will break
> usb-hid.c), but it adjusts the report descriptor in usb-hid.c to provide
> position in 16-bits, and in absolute coordinates:
>
> Index: usb-hid.c
> ===================================================================
> RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
> retrieving revision 1.1
> diff -a -u -r1.1 usb-hid.c
> --- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1
> +++ usb-hid.c 8 Apr 2006 20:56:02 -0000
> @@ -117,7 +117,7 @@
> 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
> 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
> 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
> + 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02,
> 0xC0, 0xC0,
> };
>
> According to:
> http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1
>
I can't get the existing usb-hid mouse to work in win2k. It sees a device but it marks it as
non-functional. After wrapping my head around this descriptor I can't really seem to reconcile what
is here with the data we are passing in usb_mouse_poll()
I'm sure it works with a linux guest.. has anyone had -usb -usbdevice mouse working under windows ?
This descriptor seems slightly whacky compared to most mouse examples I've seen floating about on
the net.
static const uint8_t qemu_mouse_hid_report_descriptor[] = {
0x05, 0x01, /* Usage Page Generic Desktop */
0x09, 0x02, /* Usage Mouse */
0xA1, 0x01 /* Collection Application */
0x09, 0x01, /* Usage Pointer */
0xA1, 0x00, /* Collection Physical */
0x05, 0x09, /* Usage Page Button */
0x19, 0x01, /* Usage Minimum Button 1 */
0x29, 0x03, /* Usage Maximum Button 3 */
0x15, 0x00, /* Logical Minimum 0 */
0x25, 0x01, /* Logical Maximum 1 */
0x95, 0x03, /* Report Count 3 */
0x75, 0x01, /* Report Size 1 */
0x81, 0x02, /* Input (Data, Var, Abs) */
0x95, 0x01, /* Report Count 1 */
0x75, 0x05, /* Report Size 5 */
0x81, 0x01, /* Input (Cnst, Var, Abs) */
0x05, 0x01, /* Usage Page Generic Desktop */
0x09, 0x30, /* Usage X */
0x09, 0x31, /* Usage Y */
0x15, 0x81, /* Logical Minimum -127 */
0x25, 0x7F, /* Logical Maximum 127 */
0x75, 0x08, /* Report Size 8 */
0x95, 0x02, /* Report Count 2 */
0x81, 0x06, /* Input (Data, Var, Rel) */
0xC0, /* End Collection */
0xC0, /* End Collection */
};
I have recompiled this through a HID compiler and the analysis seems correct.
So we are not describing a Z axis anywhere at all there..
This one passes a parse test and should give X & Y as 0->FFFF ABS while leaving Z as 8 bit relative.
static const uint8_t qemu_mouse_hid_report_descriptor[] = {
0x05, 0x01, /* Usage Page Generic Desktop */
0x09, 0x02, /* Usage Mouse */
0xA1, 0x01 /* Collection Application */
0x09, 0x01, /* Usage Pointer */
0xA1, 0x00, /* Collection Physical */
0x05, 0x09, /* Usage Page Button */
0x19, 0x01, /* Usage Minimum Button 1 */
0x29, 0x03, /* Usage Maximum Button 3 */
0x15, 0x00, /* Logical Minimum 0 */
0x25, 0x01, /* Logical Maximum 1 */
0x95, 0x03, /* Report Count 3 */
0x75, 0x01, /* Report Size 1 */
0x81, 0x02, /* Input (Data, Var, Abs) */
0x95, 0x01, /* Report Count 1 */
0x75, 0x05, /* Report Size 5 */
0x81, 0x01, /* Input (Cnst, Var, Abs) */
0x05, 0x01, /* Usage Page Generic Desktop */
0x09, 0x30, /* Usage X */
0x09, 0x31, /* Usage Y */
0x15, 0x00, /* Logical Minimum 0 */
0x27, 0xFF, 0xFF, 0x00, 0x00, /* Logical Maximum 0xffff */
0x75, 0x32, /* Report Size 32 */
0x95, 0x02, /* Report Count 2 */
0x81, 0x06, /* Input (Data, Var, Rel) */
0x09, 0x32, /* Usage Z */
0x15, 0x81, /* Logical Minimum -127 */
0x25, 0x7F, /* Logical Maximum 127 */
0x75, 0x08, /* Report Size 8 */
0x95, 0x01, /* Report Count 1 */
0xC0, /* End Collection */
0xC0, /* End Collection */
};
I'm beginning to rate HID right up there with ACPI for complete brain melting factor..
(Not even compile tested yet.. still trying to fix the 1st one!)
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-09 18:31 UTC (permalink / raw)
To: Darren Hart
Cc: linux-kernel, Thomas Gleixner, Stultz, John, Peter Williams,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604091025.17518.dvhltc@us.ibm.com>
* Darren Hart <dvhltc@us.ibm.com> wrote:
> > -rt14 tree with this bug fixed - does it fix the failures for you?
>
> I ran the test 100 times, no failures! Looks good to me.
>
> # for ((i=0;i<100;i++)); do ./sched_football 4 10 | grep "Final ball position"
> | tee sched_football_ball.log; sleep 1; done
> Final ball position: 0
> ...
> Final ball position: 0
cool!
> Looking at the patch, it looks like the problem was a race on the
> runqueue lock - when we called double_runqueue_lock(a,b) we risked
> dropping the lock on b, giving another CPU opportunity to grab it and
> pull our next task. The API change to double_runqueue_lock() and
> checking the new return code in balance_rt_tasks() is what fixed the
> issue. Is that accurate?
this was one problem, yes. There was another problem too: the code
checked against rq->curr, while it has to consider the 'next' task (the
current task might just be about to leave the CPU at the point we do the
rebalancing). (A third problem was an efficiency issue: the code
indiscriminately pulled all RT tasks it found eligible - while it should
only have pulled ones that preempt the next CPU.)
> I was doing some testing to see why the RT tasks don't appear to be
> evenly distributed across the CPUs (in my earlier post using the
> output of /proc/stat). [...]
could you explain this in a bit more detailed way? [what is the behavior
you observe, and what would be your expectation.]
> [...] I was wondering if the load_balancing code might be interfering
> with the balance_rt_tasks() code. Should the normal load_balancer
> even touch RT tasks in the presence of balance_rt_tasks() ? I'm
> thinking not.
if there is RT overload then running the highest-prio RT tasks trumps
any other consideration - including load_balance(). Also, same-prio
SCHED_FIFO tasks can starve each other indefinitely, so there's not much
the load-balancer can do.
Ingo
^ permalink raw reply
* Re: [patch][rfc] quell interactive feeding frenzy
From: Mike Galbraith @ 2006-04-09 18:33 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel
In-Reply-To: <200604091944.28954.a1426z@gawab.com>
On Sun, 2006-04-09 at 19:44 +0300, Al Boldi wrote:
> bert hubert wrote:
> > On Sun, Apr 09, 2006 at 01:39:38PM +0200, Mike Galbraith wrote:
> > > Ok, unusable may be overstated. Nonetheless, that bit of code causes
> > > serious problems. It makes my little PIII/500 test box trying to fill
> > > one 100Mbit local network unusable. That is not overstated.
> >
> > If you try to make a PIII/500 fill 100mbit of TCP/IP using lots of
> > different processes, that IS a corner load.
> >
> > I'm sure you can fix this (rare) workload but are you very sure you are
> > not killing off performance for other situations?
>
> This really has nothing to do w/ workload but rather w/ multi-user processing
> /tasking /threading. And the mere fact that the 2.6 kernel prefers
> kernel-threads should imply an overall performance increase (think pdflush).
>
> The reason why not many have noticed this scheduler problem(s) is because
> most hackers nowadays work w/ the latest fastest hw available which does not
> allow them to see these problems (think Windows, where most problems are
> resolved by buying the latest hw).
>
> Real Hackers never miss out on making their work run on the smallest common
> denominator (think i386dx :).
Please don't trim the cc list. I almost didn't see this, and I really
do want to hear each and every opinion.
-Mike
^ permalink raw reply
* Re: NATed packets only enter the default routing table
From: richard lucassen @ 2006-04-09 18:30 UTC (permalink / raw)
To: netfilter
In-Reply-To: <200604091556.02586.jeroen@elebaut.com>
On Sun, 9 Apr 2006 15:56:02 +0200
Jeroen Elebaut <jeroen@elebaut.com> wrote:
> i had a similar problem with our setup. The problem is i think that
> the routing decision on the linux box is made before the address in
> the packet is changed back to 1.2.3.3. So it doesn't use the source
> policy routing entry. I solved this by using the connmark module from
> iptables and then do routing based on the mark. The following should
> work in your setup:
>
> iptables -t mangle -I PREROUTING -m conntrack --ctstate
> ESTABLISHED,RELATED -j CONNMARK --restore-mark
> iptables -t mangle -I PREROUTING -i eth1 -m conntrack --ctstate NEW
> -j CONNMARK --set-mark 1
>
> ip rule add fwmark 1 lookup eth1_up
I already found out this:
iptables -t mangle -A PREROUTING -i eth1 -d 192.168.201.3 \
-j CONNMARK --set-mark 1
iptables -t mangle -A PREROUTING -i eth2 -s 10.0.2.1 \
-j CONNMARK --restore-mark
> This will route everything that entered via eth1 back via eth1.
And indeed that was the solution. Thnx!
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
^ permalink raw reply
* [PATCH] qmail support
From: Morten K. Poulsen @ 2006-04-09 18:27 UTC (permalink / raw)
To: mlmmj
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
Hi,
Attached is the long promised patch for qmail support. It is a diff
against mlmmj-1.2.11.
The changes are:
- listcontrol() is now passed the address extension, not the whole address.
- mlmmj-process now looks for the "envelope from" in
- SENDER environment variable (set by qmail, postfix and exim)
- Return-Path: header (RFC 822 section 4.3.1, set by sendmail and postfix)
- mlmmj-process now looks for the "address extension" in
- EXT environment variable (set by qmail)
- EXTENSION environment variable (set by postfix)
- LOCAL_PART_SUFFIX environment variable (set by exim)
- by parsing the first Delivered-To: header (set by sendmail and postfix)
- by parsing the first To: header (set by most user agents)
This should remove the need for "headers_add = Delivered-To:..." and
"return_path_add" for Exim 4.
I need feedback before committing the patch.
If you are running one of the following configurations, please test the
patch and tell me about it:
- sendmail, vanilla
- sendmail, with the patch in mlmmj/README.sendmail
- qmail
- postfix (1.x and 2.x)
- exim3 (does mlmmj work here at all?)
- exim4, as described in mlmmj/README.exim4
- exim4, without headers_add and return_path_add
Morten
[-- Attachment #2: patch-mlmmj-listcontrol_env.diff --]
[-- Type: text/plain, Size: 9085 bytes --]
diff -urN orig-mlmmj-1.2.11/include/listcontrol.h mlmmj-1.2.11/include/listcontrol.h
--- orig-mlmmj-1.2.11/include/listcontrol.h 2004-06-16 23:11:52.000000000 +0200
+++ mlmmj-1.2.11/include/listcontrol.h 2006-04-09 18:49:20.000000000 +0200
@@ -27,7 +27,7 @@
#include "find_email_adr.h"
int listcontrol(struct email_container *fromemails, const char *listdir,
- const char *controladdr, const char *mlmmjsub,
+ const char *controlstr, const char *mlmmjsub,
const char *mlmmjunsub, const char *mlmmjsend,
const char *mlmmjbounce, const char *mailname);
diff -urN orig-mlmmj-1.2.11/src/listcontrol.c mlmmj-1.2.11/src/listcontrol.c
--- orig-mlmmj-1.2.11/src/listcontrol.c 2006-01-04 20:10:24.000000000 +0100
+++ mlmmj-1.2.11/src/listcontrol.c 2006-04-09 18:39:51.000000000 +0200
@@ -98,15 +98,14 @@
int listcontrol(struct email_container *fromemails, const char *listdir,
- const char *controladdr, const char *mlmmjsub,
+ const char *controlstr, const char *mlmmjsub,
const char *mlmmjunsub, const char *mlmmjsend,
const char *mlmmjbounce, const char *mailname)
{
- char *atsign, *recipdelimsign, *listdelim, *bouncenr, *tmpstr;
- char *controlstr, *param = NULL, *conffilename, *moderatefilename;
+ char *bouncenr, *tmpstr;
+ char *param = NULL, *conffilename, *moderatefilename;
char *c, *archivefilename, *sendfilename;
const char *subswitch;
- size_t len;
struct stat stbuf;
int closedlist, nosubconfirm, tmpfd, noget, i, closedlistsub,
subonlyget = 0;
@@ -126,18 +125,6 @@
else
subswitch = "-C";
- listdelim = getlistdelim(listdir);
- recipdelimsign = strstr(controladdr, listdelim);
- MY_ASSERT(recipdelimsign);
- atsign = index(controladdr, '@');
- MY_ASSERT(atsign);
- len = atsign - recipdelimsign;
-
- controlstr = mymalloc(len);
- MY_ASSERT(controlstr);
- snprintf(controlstr, len, "%s", recipdelimsign + strlen(listdelim));
- myfree(listdelim);
-
#if 0
log_error(LOG_ARGS, "controlstr = [%s]\n", controlstr);
log_error(LOG_ARGS, "fromemails->emaillist[0] = [%s]\n",
@@ -168,7 +155,6 @@
exit(EXIT_SUCCESS);
}
- myfree(controlstr);
break;
}
diff -urN orig-mlmmj-1.2.11/src/mlmmj-process.c mlmmj-1.2.11/src/mlmmj-process.c
--- orig-mlmmj-1.2.11/src/mlmmj-process.c 2006-01-23 18:44:53.000000000 +0100
+++ mlmmj-1.2.11/src/mlmmj-process.c 2006-04-09 18:39:51.000000000 +0200
@@ -299,6 +299,38 @@
}
+static char *recipient_extra(const char *listdir, const char *addr)
+{
+ char *listdelim;
+ char *delim, *atsign, *ret;
+ size_t len;
+
+ if (!addr)
+ return NULL;
+
+ listdelim = getlistdelim(listdir);
+
+ delim = strstr(addr, listdelim);
+ if (!delim) {
+ myfree(listdelim);
+ return NULL;
+ }
+ delim += strlen(listdelim);
+ myfree(listdelim);
+
+ atsign = strrchr(delim, '@');
+ if (!atsign)
+ return NULL;
+
+ len = atsign - delim;
+ ret = (char *)mymalloc(len + 1);
+ strncpy(ret, delim, len);
+ ret[len] = '\0';
+
+ return ret;
+}
+
+
static void print_help(const char *prg)
{
printf("Usage: %s -L /path/to/list -m /path/to/mail [-h] [-P] [-V]\n"
@@ -323,16 +355,16 @@
char *mlmmjsend, *mlmmjsub, *mlmmjunsub, *mlmmjbounce;
char *bindir, *subjectprefix, *discardname, *listaddr, *listdelim;
char *listfqdn, *listname, *fromaddr;
- char *queuefilename, *recipextra, *owner = NULL;
+ char *queuefilename, *recipextra = NULL, *owner = NULL;
char *maildata[2] = { "posteraddr", NULL };
+ char *envstr, *efrom;
struct stat st;
uid_t uid;
struct email_container fromemails = { 0, NULL };
struct email_container toemails = { 0, NULL };
struct email_container ccemails = { 0, NULL };
- struct email_container efromemails = { 0, NULL };
- struct email_container dtoemails = { 0, NULL };
- struct email_container *whichto;
+ struct email_container rpemails = { 0, NULL };
+ struct email_container dtemails = { 0, NULL };
struct strlist *access_rules = NULL;
struct strlist *delheaders = NULL;
struct strlist allheaders;
@@ -473,60 +505,77 @@
if(footfd >= 0)
close(footfd);
- if(readhdrs[0].token) { /* From: addresses */
- for(i = 0; i < readhdrs[0].valuecount; i++) {
- find_email_adr(readhdrs[0].values[i], &fromemails);
- }
+ /* From: addresses */
+ for(i = 0; i < readhdrs[0].valuecount; i++) {
+ find_email_adr(readhdrs[0].values[i], &fromemails);
}
- if(readhdrs[1].token) { /* To: addresses */
- for(i = 0; i < readhdrs[1].valuecount; i++) {
- find_email_adr(readhdrs[1].values[i], &toemails);
- }
+ /* To: addresses */
+ for(i = 0; i < readhdrs[1].valuecount; i++) {
+ find_email_adr(readhdrs[1].values[i], &toemails);
}
- if(readhdrs[2].token) { /* Cc: addresses */
- for(i = 0; i < readhdrs[2].valuecount; i++) {
- find_email_adr(readhdrs[2].values[i], &ccemails);
- }
+ /* Cc: addresses */
+ for(i = 0; i < readhdrs[2].valuecount; i++) {
+ find_email_adr(readhdrs[2].values[i], &ccemails);
}
- if(readhdrs[3].token) { /* Return-Path: (envelope from) */
- for(i = 0; i < readhdrs[3].valuecount; i++) {
- find_email_adr(readhdrs[3].values[i], &efromemails);
- }
- if(efromemails.emailcount == 0) {
- efromemails.emaillist =
- (char **)mymalloc(sizeof(char *));
- efromemails.emaillist[0] = mystrdup("<>");
- }
+ /* Return-Path: addresses */
+ for(i = 0; i < readhdrs[3].valuecount; i++) {
+ find_email_adr(readhdrs[3].values[i], &rpemails);
}
- if(readhdrs[4].token) { /* Delivered-To: (envelope to) */
- for(i = 0; i < readhdrs[4].valuecount; i++) {
- find_email_adr(readhdrs[4].values[i], &dtoemails);
- }
+ /* Delivered-To: addresses */
+ for(i = 0; i < readhdrs[4].valuecount; i++) {
+ find_email_adr(readhdrs[4].values[i], &dtemails);
}
- if(dtoemails.emaillist)
- whichto = &dtoemails;
- else if(toemails.emaillist)
- whichto = &toemails;
- else
- whichto = NULL;
+ /* envelope from */
+ if((envstr = getenv("SENDER")) != NULL) {
+ /* qmail, postfix, exim */
+ efrom = mystrdup(envstr);
+ } else if(rpemails.emailcount >= 1) {
+ /* the (first) Return-Path: header */
+ efrom = mystrdup(rpemails.emaillist[0]);
+ } else {
+ efrom = mystrdup("");
+ }
- listdelim = getlistdelim(listdir);
- if(whichto && whichto->emaillist && whichto->emaillist[0]){
- recipextra = strstr(whichto->emaillist[0], listdelim);
- if (recipextra)
- recipextra += strlen(listdelim);
- } else
+ /* address extension (the "foo" part of "user+foo@domain.tld") */
+ if((envstr = getenv("EXT")) != NULL) {
+ /* qmail */
+ recipextra = mystrdup(envstr);
+ } else if((envstr = getenv("EXTENSION")) != NULL) {
+ /* postfix */
+ recipextra = mystrdup(envstr);
+ } else if((envstr = getenv("LOCAL_PART_SUFFIX")) != NULL) {
+ /* exim */
+ listdelim = getlistdelim(listdir);
+ if (strncmp(envstr, listdelim, strlen(listdelim)) == 0) {
+ recipextra = mystrdup(envstr + strlen(listdelim));
+ } else {
+ recipextra = mystrdup(envstr);
+ }
+ myfree(listdelim);
+ } else if(dtemails.emailcount >= 1) {
+ /* parse the (first) Delivered-To: header */
+ recipextra = recipient_extra(listdir, dtemails.emaillist[0]);
+ } else if(toemails.emailcount >= 1) {
+ /* parse the (first) To: header */
+ recipextra = recipient_extra(listdir, toemails.emaillist[0]);
+ } else {
recipextra = NULL;
- myfree(listdelim);
+ }
+
+ if(recipextra && (strlen(recipextra) == 0)) {
+ myfree(recipextra);
+ recipextra = NULL;
+ }
+ /* Why is this here, and not in listcontrol() ? -- mortenp 20060409 */
if(recipextra) {
owner = concatstr(2, listdir, "/control/owner");
- if(owner && strncmp(recipextra, "owner@", 6) == 0) {
+ if(owner && strcmp(recipextra, "owner") == 0) {
/* strip envelope from before resending */
delheaders->count = 0;
delheaders->strs = NULL;
@@ -559,11 +608,11 @@
unlink(mailfile);
log_oper(listdir, OPLOGFNAME, "mlmmj-recieve: sending"
" mail from %s to owner",
- efromemails.emaillist[0]);
+ efrom);
execlp(mlmmjsend, mlmmjsend,
"-l", "4",
"-L", listdir,
- "-F", efromemails.emaillist[0],
+ "-F", efrom,
"-s", owner,
"-a",
"-m", donemailname, (char *)NULL);
@@ -575,7 +624,7 @@
log_error(LOG_ARGS, "listcontrol(from, %s, %s, %s, %s, %s, %s)\n", listdir, toemails.emaillist[0], mlmmjsub, mlmmjunsub, mlmmjsend, mlmmjbounce);
#endif
unlink(mailfile);
- listcontrol(&fromemails, listdir, whichto->emaillist[0],
+ listcontrol(&fromemails, listdir, recipextra,
mlmmjsub, mlmmjunsub, mlmmjsend, mlmmjbounce,
donemailname);
return EXIT_SUCCESS;
@@ -604,14 +653,14 @@
myfree(delheaders);
- if(efromemails.emailcount != 1) { /* don't send mails with <> in From
+ if(strcmp(efrom, "") == 0) { /* don't send mails with <> in From
to the list */
discardname = concatstr(3, listdir,
"/queue/discarded/",
randomstr);
- log_error(LOG_ARGS, "Discarding %s due to invalid envelope"
- " from email count (was %d, must be 1)",
- mailfile, efromemails.emailcount);
+ errno = 0;
+ log_error(LOG_ARGS, "Discarding %s due to missing envelope"
+ " from address", mailfile);
rename(mailfile, discardname);
unlink(donemailname);
myfree(donemailname);
^ permalink raw reply
* [parisc-linux] [RFC] pselect/ppoll support
From: Kyle McMartin @ 2006-04-09 18:25 UTC (permalink / raw)
To: parisc-linux
First strike at adding TIF_RESTORE_SIGMASK support for the pselect/ppoll
system calls... Doesn't seem to work at all yet...
For instance, signals appear to be completely broken... Dunno why,
seems to work for other architectures...
diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 7c95d76..22e3eed 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -32,6 +32,7 @@
#include <asm/psw.h>
#include <asm/assembly.h> /* for LDREG/STREG defines */
+#include <asm/cache.h>
#include <asm/pgtable.h>
#include <asm/signal.h>
#include <asm/unistd.h>
@@ -479,11 +480,7 @@
bb,>=,n \pmd,_PxD_PRESENT_BIT,\fault
DEP %r0,31,PxD_FLAG_SHIFT,\pmd /* clear flags */
copy \pmd,%r9
-#ifdef CONFIG_64BIT
- shld %r9,PxD_VALUE_SHIFT,\pmd
-#else
- shlw %r9,PxD_VALUE_SHIFT,\pmd
-#endif
+ SHLREG %r9,PxD_VALUE_SHIFT,\pmd
EXTR \va,31-PAGE_SHIFT,ASM_BITS_PER_PTE,\index
DEP %r0,31,PAGE_SHIFT,\pmd /* clear offset */
shladd \index,BITS_PER_PTE_ENTRY,\pmd,\pmd
@@ -962,11 +959,7 @@ intr_return:
/* shift left ____cacheline_aligned (aka L1_CACHE_BYTES) amount
** irq_stat[] is defined using ____cacheline_aligned.
*/
-#ifdef CONFIG_64BIT
- shld %r1, 6, %r20
-#else
- shlw %r1, 5, %r20
-#endif
+ SHLREG %r1, L1_CACHE_SHIFT, %r20
add %r19,%r20,%r19 /* now have &irq_stat[smp_processor_id()] */
#endif /* CONFIG_SMP */
@@ -1071,7 +1064,7 @@ intr_do_preempt:
b intr_restore /* ssm PSW_SM_I done by intr_restore */
#endif /* CONFIG_PREEMPT */
- .import do_signal,code
+ .import do_notify_resume,code
intr_do_signal:
/*
This check is critical to having LWS
@@ -1088,14 +1081,13 @@ intr_do_signal:
CMPIB= 0,%r20,intr_restore /* backward */
nop
- copy %r0, %r24 /* unsigned long in_syscall */
- copy %r16, %r25 /* struct pt_regs *regs */
+ copy %r0, %r25 /* unsigned long in_syscall */
#ifdef CONFIG_64BIT
ldo -16(%r30),%r29 /* Reference param save area */
#endif
- BL do_signal,%r2
- copy %r0, %r26 /* sigset_t *oldset = NULL */
+ BL do_notify_resume,%r2
+ copy %r16, %r26 /* struct pt_regs *regs */
b intr_check_sig
nop
@@ -2028,32 +2020,6 @@ sys32_sigaltstack_wrapper:
nop
#endif
- .export sys_rt_sigsuspend_wrapper
-sys_rt_sigsuspend_wrapper:
- LDREG TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE(%r30), %r1
- ldo TASK_REGS(%r1),%r24
- reg_save %r24
-
- STREG %r2, -RP_OFFSET(%r30)
-#ifdef CONFIG_64BIT
- ldo FRAME_SIZE(%r30), %r30
- b,l sys_rt_sigsuspend,%r2
- ldo -16(%r30),%r29 /* Reference param save area */
-#else
- bl sys_rt_sigsuspend,%r2
- ldo FRAME_SIZE(%r30), %r30
-#endif
-
- ldo -FRAME_SIZE(%r30), %r30
- LDREG -RP_OFFSET(%r30), %r2
-
- LDREG TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE(%r30), %r1
- ldo TASK_REGS(%r1),%r1
- reg_restore %r1
-
- bv %r0(%r2)
- nop
-
.export syscall_exit
syscall_exit:
@@ -2108,11 +2074,7 @@ syscall_check_bh:
ldw TI_CPU-THREAD_SZ_ALGN-FRAME_SIZE(%r30),%r26 /* cpu # */
/* shift left ____cacheline_aligned (aka L1_CACHE_BYTES) bits */
-#ifdef CONFIG_64BIT
- shld %r26, 6, %r20
-#else
- shlw %r26, 5, %r20
-#endif
+ SHLREG %r26, L1_CACHE_SHIFT, %r20
add %r19,%r20,%r19 /* now have &irq_stat[smp_processor_id()] */
#endif /* CONFIG_SMP */
@@ -2264,23 +2226,21 @@ syscall_do_resched:
b syscall_check_bh /* if resched, we start over again */
nop
- .import do_signal,code
+ .import do_notify_resume,code
syscall_do_signal:
/* Save callee-save registers (for sigcontext).
FIXME: After this point the process structure should be
consistent with all the relevant state of the process
before the syscall. We need to verify this. */
LDREG TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE(%r30),%r1
- ldo TASK_REGS(%r1), %r25 /* struct pt_regs *regs */
- reg_save %r25
-
- ldi 1, %r24 /* unsigned long in_syscall */
+ ldo TASK_REGS(%r1), %r26 /* struct pt_regs *regs */
+ reg_save %r26
#ifdef CONFIG_64BIT
ldo -16(%r30),%r29 /* Reference param save area */
#endif
- BL do_signal,%r2
- copy %r0, %r26 /* sigset_t *oldset = NULL */
+ BL do_notify_resume,%r2
+ ldi 1, %r25 /* unsigned long in_syscall */
LDREG TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE(%r30),%r1
ldo TASK_REGS(%r1), %r20 /* reload pt_regs */
diff --git a/arch/parisc/kernel/ptrace.c b/arch/parisc/kernel/ptrace.c
index 413292f..9aa4af0 100644
--- a/arch/parisc/kernel/ptrace.c
+++ b/arch/parisc/kernel/ptrace.c
@@ -36,8 +36,7 @@
#define DBG(x...)
#endif
-#ifdef __LP64__
-
+#ifdef CONFIG_64BIT
/* This function is needed to translate 32 bit pt_regs offsets in to
* 64 bit pt_regs offsets. For example, a 32 bit gdb under a 64 bit kernel
* will request offset 12 if it wants gr3, but the lower 32 bits of
@@ -90,8 +89,8 @@ long arch_ptrace(struct task_struct *chi
case PTRACE_PEEKDATA: {
int copied;
-#ifdef __LP64__
- if (personality(child->personality) == PER_LINUX32) {
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(child)) {
unsigned int tmp;
addr &= 0xffffffffL;
@@ -122,8 +121,8 @@ long arch_ptrace(struct task_struct *chi
case PTRACE_POKETEXT: /* write the word at location addr. */
case PTRACE_POKEDATA:
ret = 0;
-#ifdef __LP64__
- if (personality(child->personality) == PER_LINUX32) {
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(child)) {
unsigned int tmp = (unsigned int)data;
DBG("sys_ptrace(POKE%s, %d, %lx, %lx)\n",
request == PTRACE_POKETEXT ? "TEXT" : "DATA",
@@ -145,8 +144,8 @@ long arch_ptrace(struct task_struct *chi
processes, the kernel saves all regs on a syscall. */
case PTRACE_PEEKUSR: {
ret = -EIO;
-#ifdef __LP64__
- if (personality(child->personality) == PER_LINUX32) {
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(child)) {
unsigned int tmp;
if (addr & (sizeof(int)-1))
@@ -204,8 +203,8 @@ long arch_ptrace(struct task_struct *chi
ret = 0;
goto out_tsk;
}
-#ifdef __LP64__
- if (personality(child->personality) == PER_LINUX32) {
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(child)) {
if (addr & (sizeof(int)-1))
goto out_tsk;
if ((addr = translate_usr_offset(addr)) < 0)
diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
index 05767e8..5a1e21e 100644
--- a/arch/parisc/kernel/signal.c
+++ b/arch/parisc/kernel/signal.c
@@ -4,6 +4,7 @@
*
* Copyright (C) 2000 David Huggins-Daines <dhd@debian.org>
* Copyright (C) 2000 Linuxcare, Inc.
+ * Copyright (C) 2006 Kyle McMartin <kyle@parisc-linux.org>
*
* Based on the ia64, i386, and alpha versions.
*
@@ -60,58 +61,13 @@
* this. */
#define A(__x) ((unsigned long)(__x))
-int do_signal(sigset_t *oldset, struct pt_regs *regs, int in_syscall);
-
/*
* Atomically swap in the new signal mask, and wait for a signal.
*/
-#ifdef __LP64__
+#ifdef CONFIG_64BIT
#include "sys32.h"
#endif
-asmlinkage int
-sys_rt_sigsuspend(sigset_t __user *unewset, size_t sigsetsize, struct pt_regs *regs)
-{
- sigset_t saveset, newset;
-#ifdef __LP64__
- compat_sigset_t newset32;
-
- if(personality(current->personality) == PER_LINUX32){
- /* XXX: Don't preclude handling different sized sigset_t's. */
- if (sigsetsize != sizeof(compat_sigset_t))
- return -EINVAL;
- if (copy_from_user(&newset32, (compat_sigset_t __user *)unewset, sizeof(newset32)))
- return -EFAULT;
- sigset_32to64(&newset,&newset32);
-
- } else
-#endif
- {
- /* XXX: Don't preclude handling different sized sigset_t's. */
- if (sigsetsize != sizeof(sigset_t))
- return -EINVAL;
-
- if (copy_from_user(&newset, unewset, sizeof(newset)))
- return -EFAULT;
- }
-
- sigdelsetmask(&newset, ~_BLOCKABLE);
-
- spin_lock_irq(¤t->sighand->siglock);
- saveset = current->blocked;
- current->blocked = newset;
- recalc_sigpending();
- spin_unlock_irq(¤t->sighand->siglock);
-
- regs->gr[28] = -EINTR;
- while (1) {
- current->state = TASK_INTERRUPTIBLE;
- schedule();
- if (do_signal(&saveset, regs, 1))
- return -EINTR;
- }
-}
-
/*
* Do a signal return - restore sigcontext.
*/
@@ -149,11 +105,11 @@ sys_rt_sigreturn(struct pt_regs *regs, i
sigset_t set;
unsigned long usp = (regs->gr[30] & ~(0x01UL));
unsigned long sigframe_size = PARISC_RT_SIGFRAME_SIZE;
-#ifdef __LP64__
+#ifdef CONFIG_64BIT
compat_sigset_t compat_set;
struct compat_rt_sigframe __user * compat_frame;
- if(personality(current->personality) == PER_LINUX32)
+ if (__is_compat_task(current))
sigframe_size = PARISC_RT_SIGFRAME_SIZE32;
#endif
@@ -163,10 +119,10 @@ sys_rt_sigreturn(struct pt_regs *regs, i
(usp - sigframe_size);
DBG(2,"sys_rt_sigreturn: frame is %p\n", frame);
-#ifdef __LP64__
+#ifdef CONFIG_64BIT
compat_frame = (struct compat_rt_sigframe __user *)frame;
- if(personality(current->personality) == PER_LINUX32){
+ if (__is_compat_task(current)) {
DBG(2,"sys_rt_sigreturn: ELF32 process.\n");
if (__copy_from_user(&compat_set, &compat_frame->uc.uc_sigmask, sizeof(compat_set)))
goto give_sigsegv;
@@ -185,10 +141,10 @@ sys_rt_sigreturn(struct pt_regs *regs, i
spin_unlock_irq(¤t->sighand->siglock);
/* Good thing we saved the old gr[30], eh? */
-#ifdef __LP64__
- if(personality(current->personality) == PER_LINUX32){
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(current)) {
DBG(1,"sys_rt_sigreturn: compat_frame->uc.uc_mcontext 0x%p\n",
- &compat_frame->uc.uc_mcontext);
+ &compat_frame->uc.uc_mcontext);
// FIXME: Load upper half from register file
if (restore_sigcontext32(&compat_frame->uc.uc_mcontext,
&compat_frame->regs, regs))
@@ -297,12 +253,12 @@ setup_rt_frame(int sig, struct k_sigacti
unsigned long rp, usp;
unsigned long haddr, sigframe_size;
int err = 0;
-#ifdef __LP64__
+#ifdef CONFIG_64BIT
compat_int_t compat_val;
struct compat_rt_sigframe __user * compat_frame;
compat_sigset_t compat_set;
#endif
-
+
usp = (regs->gr[30] & ~(0x01UL));
/*FIXME: frame_size parameter is unused, remove it. */
frame = get_sigframe(ka, usp, sizeof(*frame));
@@ -311,11 +267,10 @@ setup_rt_frame(int sig, struct k_sigacti
DBG(1,"setup_rt_frame: frame %p info %p\n", frame, info);
-#ifdef __LP64__
-
+#ifdef CONFIG_64BIT
compat_frame = (struct compat_rt_sigframe __user *)frame;
- if(personality(current->personality) == PER_LINUX32) {
+ if (__is_compat_task(current)) {
DBG(1,"setup_rt_frame: frame->info = 0x%p\n", &compat_frame->info);
err |= copy_siginfo_to_user32(&compat_frame->info, info);
DBG(1,"SETUP_RT_FRAME: 1\n");
@@ -391,8 +346,8 @@ setup_rt_frame(int sig, struct k_sigacti
haddr = A(ka->sa.sa_handler);
/* The sa_handler may be a pointer to a function descriptor */
-#ifdef __LP64__
- if(personality(current->personality) == PER_LINUX32) {
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(current)) {
#endif
if (haddr & PA_PLABEL_FDESC) {
Elf32_Fdesc fdesc;
@@ -406,7 +361,7 @@ setup_rt_frame(int sig, struct k_sigacti
haddr = fdesc.addr;
regs->gr[19] = fdesc.gp;
}
-#ifdef __LP64__
+#ifdef CONFIG_64BIT
} else {
Elf64_Fdesc fdesc;
Elf64_Fdesc __user *ufdesc = (Elf64_Fdesc __user *)A(haddr & ~3);
@@ -426,20 +381,20 @@ setup_rt_frame(int sig, struct k_sigacti
/* The syscall return path will create IAOQ values from r31.
*/
sigframe_size = PARISC_RT_SIGFRAME_SIZE;
-#ifdef __LP64__
- if(personality(current->personality) == PER_LINUX32)
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(current))
sigframe_size = PARISC_RT_SIGFRAME_SIZE32;
#endif
if (in_syscall) {
regs->gr[31] = haddr;
-#ifdef __LP64__
- if(personality(current->personality) == PER_LINUX)
+#ifdef CONFIG_64BIT
+ if (__is_native_task(current))
sigframe_size |= 1;
#endif
} else {
unsigned long psw = USER_PSW;
-#ifdef __LP64__
- if(personality(current->personality) == PER_LINUX)
+#ifdef CONFIG_64BIT
+ if (__is_native_task(current))
psw |= PSW_W;
#endif
@@ -463,8 +418,8 @@ setup_rt_frame(int sig, struct k_sigacti
regs->gr[2] = rp; /* userland return pointer */
regs->gr[26] = sig; /* signal number */
-#ifdef __LP64__
- if(personality(current->personality) == PER_LINUX32){
+#ifdef CONFIG_64BIT
+ if (__is_compat_task(current)) {
regs->gr[25] = A(&compat_frame->info); /* siginfo pointer */
regs->gr[24] = A(&compat_frame->uc); /* ucontext pointer */
} else
@@ -485,12 +440,12 @@ setup_rt_frame(int sig, struct k_sigacti
current->comm, current->pid, frame, regs->gr[30],
regs->iaoq[0], regs->iaoq[1], rp);
- return 1;
+ return 0;
give_sigsegv:
DBG(1,"setup_rt_frame: sending SIGSEGV\n");
force_sigsegv(sig, current);
- return 0;
+ return -EFAULT;
}
/*
@@ -499,22 +454,97 @@ give_sigsegv:
static long
handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka,
- sigset_t *oldset, struct pt_regs *regs, int in_syscall)
+ sigset_t *oldset, struct pt_regs *regs, int in_syscall)
{
+ int ret;
+ unsigned long flags;
+
DBG(1,"handle_signal: sig=%ld, ka=%p, info=%p, oldset=%p, regs=%p\n",
sig, ka, info, oldset, regs);
+
+ /* Restart a system call if necessary. */
+ if (in_syscall) {
+ /* Check the return code */
+ switch (regs->gr[28]) {
+ case -ERESTART_RESTARTBLOCK:
+ current_thread_info()->restart_block.fn = do_no_restart_syscall;
+ case -ERESTARTNOHAND:
+ DBG(1,"ERESTARTNOHAND: returning -EINTR\n");
+ regs->gr[28] = -EINTR;
+ break;
+
+ case -ERESTARTSYS:
+ if (!(ka->sa.sa_flags & SA_RESTART)) {
+ DBG(1,"ERESTARTSYS: putting -EINTR\n");
+ regs->gr[28] = -EINTR;
+ break;
+ }
+ /* fallthrough */
+ case -ERESTARTNOINTR:
+ /* A syscall is just a branch, so all
+ we have to do is fiddle the return pointer. */
+ regs->gr[31] -= 8; /* delayed branching */
+ /* Preserve original r28. */
+ regs->gr[28] = regs->orig_r28;
+ break;
+ }
+ }
/* Set up the stack frame */
- if (!setup_rt_frame(sig, ka, info, oldset, regs, in_syscall))
- return 0;
+ ret = setup_rt_frame(sig, ka, info, oldset, regs, in_syscall);
- spin_lock_irq(¤t->sighand->siglock);
- sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask);
- if (!(ka->sa.sa_flags & SA_NODEFER))
- sigaddset(¤t->blocked,sig);
- recalc_sigpending();
- spin_unlock_irq(¤t->sighand->siglock);
- return 1;
+ if (ret == 0) {
+ spin_lock_irqsave(¤t->sighand->siglock, flags);
+ sigorsets(¤t->blocked, ¤t->blocked, &ka->sa.sa_mask);
+ if (!(ka->sa.sa_flags & SA_NODEFER))
+ sigaddset(¤t->blocked,sig);
+ recalc_sigpending();
+ spin_unlock_irqrestore(¤t->sighand->siglock, flags);
+ }
+
+ return ret;
+}
+
+/* Setup a trampoline to restart the syscall
+ * with __NR_restart_syscall
+ *
+ * 0: <return address (orig r31)>
+ * 4: <2nd half for 64-bit>
+ * 8: ldw 0(%sp), %r31
+ * 12: be 0x100(%sr2, %r0)
+ * 16: ldi __NR_restart_syscall, %r20
+ */
+static void setup_restart_syscall_tramp(struct pt_regs *regs)
+{
+ unsigned int *usp = (unsigned int *)regs->gr[30];
+
+#ifdef CONFIG_64BIT
+ put_user(regs->gr[31] >> 32, &usp[0]);
+ put_user(regs->gr[31] & 0xffffffff, &usp[1]);
+ put_user(0x0fc010df, &usp[2]);
+#else
+ put_user(regs->gr[31], &usp[0]);
+ put_user(0x0fc0109f, &usp[2]);
+#endif
+ put_user(0xe0008200, &usp[3]);
+ put_user(0x34140000, &usp[4]);
+
+ /* Stack is 64-byte aligned, and we only need
+ * to flush 1 cache line.
+ * Flushing one cacheline is cheap.
+ * "sync" on bigger (> 4 way) boxes is not.
+ */
+ asm("fdc %%r0(%%sr3, %0)\n"
+ "sync\n"
+ "fic %%r0(%%sr3, %0)\n"
+ "sync\n"
+ : : "r"(regs->gr[30]));
+
+ regs->gr[31] = regs->gr[30] + 8;
+ /* Preserve original r28. */
+ regs->gr[28] = regs->orig_r28;
+
+ return;
}
/*
@@ -529,130 +559,91 @@ handle_signal(unsigned long sig, siginfo
* us due to the magic of delayed branching.
*/
-asmlinkage int
-do_signal(sigset_t *oldset, struct pt_regs *regs, int in_syscall)
+static void
+parisc_do_signal(struct pt_regs *regs, int in_syscall)
{
siginfo_t info;
+ sigset_t *oldset;
struct k_sigaction ka;
int signr;
DBG(1,"\ndo_signal: oldset=0x%p, regs=0x%p, sr7 %#lx, in_syscall=%d\n",
oldset, regs, regs->sr[7], in_syscall);
- /* Everyone else checks to see if they are in kernel mode at
- this point and exits if that's the case. I'm not sure why
- we would be called in that case, but for some reason we
- are. */
+ if (!user_mode(regs))
+ return;
- if (!oldset)
+ if (test_thread_flag(TIF_RESTORE_SIGMASK))
+ oldset = ¤t->saved_sigmask;
+ else
oldset = ¤t->blocked;
DBG(1,"do_signal: oldset %08lx / %08lx\n",
oldset->sig[0], oldset->sig[1]);
-
/* May need to force signal if handle_signal failed to deliver */
- while (1) {
-
- signr = get_signal_to_deliver(&info, &ka, regs, NULL);
- DBG(3,"do_signal: signr = %d, regs->gr[28] = %ld\n", signr, regs->gr[28]);
+ signr = get_signal_to_deliver(&info, &ka, regs, NULL);
+ DBG(3,"do_signal: signr = %d, regs->gr[28] = %ld\n", signr, regs->gr[28]);
- if (signr <= 0)
- break;
-
- /* Restart a system call if necessary. */
- if (in_syscall) {
- /* Check the return code */
- switch (regs->gr[28]) {
- case -ERESTART_RESTARTBLOCK:
- current_thread_info()->restart_block.fn = do_no_restart_syscall;
- case -ERESTARTNOHAND:
- DBG(1,"ERESTARTNOHAND: returning -EINTR\n");
- regs->gr[28] = -EINTR;
- break;
-
- case -ERESTARTSYS:
- if (!(ka.sa.sa_flags & SA_RESTART)) {
- DBG(1,"ERESTARTSYS: putting -EINTR\n");
- regs->gr[28] = -EINTR;
- break;
- }
- /* fallthrough */
- case -ERESTARTNOINTR:
- /* A syscall is just a branch, so all
- we have to do is fiddle the return pointer. */
- regs->gr[31] -= 8; /* delayed branching */
- /* Preserve original r28. */
- regs->gr[28] = regs->orig_r28;
- break;
- }
- }
+ if (signr > 0) {
/* Whee! Actually deliver the signal. If the
- delivery failed, we need to continue to iterate in
- this loop so we can deliver the SIGSEGV... */
- if (handle_signal(signr, &info, &ka, oldset, regs, in_syscall)) {
+ * delivery failed, we need to continue to iterate in
+ * this loop so we can deliver the SIGSEGV...
+ */
+ if (handle_signal(signr, &info, &ka, oldset, regs, in_syscall) == 0) {
DBG(1,KERN_DEBUG "do_signal: Exit (success), regs->gr[28] = %ld\n",
- regs->gr[28]);
- return 1;
+ regs->gr[28]);
+ if (test_thread_flag(TIF_RESTORE_SIGMASK))
+ clear_thread_flag(TIF_RESTORE_SIGMASK);
+ return;
}
}
- /* end of while(1) looping forever if we can't force a signal */
/* Did we come from a system call? */
if (in_syscall) {
/* Restart the system call - no handlers present */
- if (regs->gr[28] == -ERESTART_RESTARTBLOCK) {
- unsigned int *usp = (unsigned int *)regs->gr[30];
-
- /* Setup a trampoline to restart the syscall
- * with __NR_restart_syscall
- *
- * 0: <return address (orig r31)>
- * 4: <2nd half for 64-bit>
- * 8: ldw 0(%sp), %r31
- * 12: be 0x100(%sr2, %r0)
- * 16: ldi __NR_restart_syscall, %r20
- */
-#ifndef __LP64__
- put_user(regs->gr[31], &usp[0]);
- put_user(0x0fc0109f, &usp[2]);
-#else
- put_user(regs->gr[31] >> 32, &usp[0]);
- put_user(regs->gr[31] & 0xffffffff, &usp[1]);
- put_user(0x0fc010df, &usp[2]);
-#endif
- put_user(0xe0008200, &usp[3]);
- put_user(0x34140000, &usp[4]);
-
- /* Stack is 64-byte aligned, and we only need
- * to flush 1 cache line.
- * Flushing one cacheline is cheap.
- * "sync" on bigger (> 4 way) boxes is not.
+ switch(regs->gr[28]) {
+ case -ERESTART_RESTARTBLOCK:
+ /* Install the restart syscall trampoline on the
+ * userspace stack.
*/
- asm("fdc %%r0(%%sr3, %0)\n"
- "sync\n"
- "fic %%r0(%%sr3, %0)\n"
- "sync\n"
- : : "r"(regs->gr[30]));
-
- regs->gr[31] = regs->gr[30] + 8;
- /* Preserve original r28. */
- regs->gr[28] = regs->orig_r28;
- } else if (regs->gr[28] == -ERESTARTNOHAND ||
- regs->gr[28] == -ERESTARTSYS ||
- regs->gr[28] == -ERESTARTNOINTR) {
+ setup_restart_syscall_tramp(regs);
+ break;
+ case -ERESTARTNOHAND:
+ case -ERESTARTSYS:
+ case -ERESTARTNOINTR:
/* Hooray for delayed branching. We don't
- have to restore %r20 (the system call
- number) because it gets loaded in the delay
- slot of the branch external instruction. */
+ * have to restore %r20 (the system call
+ * number) because it gets loaded in the delay
+ * slot of the branch external instruction.
+ */
regs->gr[31] -= 8;
/* Preserve original r28. */
regs->gr[28] = regs->orig_r28;
+ break;
}
}
DBG(1,"do_signal: Exit (not delivered), regs->gr[28] = %ld\n",
regs->gr[28]);
- return 0;
+ /* If there's no signal to deliver, we just put the saved
+ * sigmask back.
+ */
+ if (test_thread_flag(TIF_RESTORE_SIGMASK)) {
+ clear_thread_flag(TIF_RESTORE_SIGMASK);
+ sigprocmask(SIG_SETMASK, ¤t->saved_sigmask, NULL);
+ }
+
+ return;
+}
+
+void do_notify_resume(struct pt_regs *regs, int in_syscall)
+{
+ /* Hooks go here. */
+ if (test_thread_flag(TIF_SIGPENDING) ||
+ test_thread_flag(TIF_RESTORE_SIGMASK))
+ parisc_do_signal(regs, in_syscall);
+
+ return;
}
diff --git a/arch/parisc/kernel/syscall_table.S b/arch/parisc/kernel/syscall_table.S
index bbeeb61..5744506 100644
--- a/arch/parisc/kernel/syscall_table.S
+++ b/arch/parisc/kernel/syscall_table.S
@@ -283,7 +283,7 @@
* struct from a 32-bit user-space app.
*/
ENTRY_SAME(rt_sigqueueinfo)
- ENTRY_SAME(rt_sigsuspend_wrapper) /* not really SAME -- see the code */
+ ENTRY_COMP(rt_sigsuspend)
ENTRY_SAME(chown) /* 180 */
/* setsockopt() used by iptables: SO_SET_REPLACE/SO_SET_ADD_COUNTERS */
ENTRY_COMP(setsockopt)
@@ -377,8 +377,8 @@
ENTRY_SAME(inotify_init)
ENTRY_SAME(inotify_add_watch) /* 270 */
ENTRY_SAME(inotify_rm_watch)
- ENTRY_SAME(ni_syscall) /* 271 ENTRY_COMP(pselect6) */
- ENTRY_SAME(ni_syscall) /* 272 ENTRY_COMP(ppoll) */
+ ENTRY_COMP(pselect6)
+ ENTRY_COMP(ppoll)
ENTRY_SAME(migrate_pages)
ENTRY_COMP(openat) /* 275 */
ENTRY_SAME(mkdirat)
diff --git a/include/asm-parisc/assembly.h b/include/asm-parisc/assembly.h
index 3ce3440..00e387c 100644
--- a/include/asm-parisc/assembly.h
+++ b/include/asm-parisc/assembly.h
@@ -30,6 +30,7 @@
#define LDREGM ldd,mb
#define STREGM std,ma
#define SHRREG shrd
+#define SHLREG shld
#define RP_OFFSET 16
#define FRAME_SIZE 128
#define CALLEE_REG_FRAME_SIZE 144
@@ -39,7 +40,8 @@
#define LDREGX ldwx,s
#define LDREGM ldwm
#define STREGM stwm
-#define SHRREG shr
+#define SHRREG shrw
+#define SHLREG shld
#define RP_OFFSET 20
#define FRAME_SIZE 64
#define CALLEE_REG_FRAME_SIZE 128
diff --git a/include/asm-parisc/compat.h b/include/asm-parisc/compat.h
index 289624d..cea3c35 100644
--- a/include/asm-parisc/compat.h
+++ b/include/asm-parisc/compat.h
@@ -5,6 +5,7 @@
*/
#include <linux/types.h>
#include <linux/sched.h>
+#include <linux/personality.h>
#define COMPAT_USER_HZ 100
@@ -149,4 +150,19 @@ static __inline__ void __user *compat_al
return (void __user *)regs->gr[30];
}
+static inline int __is_compat_task(struct task_struct *t)
+{
+ return (personality(t->personality) == PER_LINUX32);
+}
+
+static inline int __is_native_task(struct task_struct *t)
+{
+ return (personality(t->personality) == PER_LINUX);
+}
+
+static inline int is_compat_task(void)
+{
+ return __is_compat_task(current);
+}
+
#endif /* _ASM_PARISC_COMPAT_H */
diff --git a/include/asm-parisc/thread_info.h b/include/asm-parisc/thread_info.h
index f2f83b0..5ae7b38 100644
--- a/include/asm-parisc/thread_info.h
+++ b/include/asm-parisc/thread_info.h
@@ -62,6 +62,7 @@ struct thread_info {
#define TIF_POLLING_NRFLAG 4 /* true if poll_idle() is polling TIF_NEED_RESCHED */
#define TIF_32BIT 5 /* 32 bit binary */
#define TIF_MEMDIE 6
+#define TIF_RESTORE_SIGMASK 7 /* restore signal mask in do_signal() */
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
@@ -69,9 +70,10 @@ struct thread_info {
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
#define _TIF_POLLING_NRFLAG (1 << TIF_POLLING_NRFLAG)
#define _TIF_32BIT (1 << TIF_32BIT)
+#define _TIF_RESTORE_SIGMASK (1 << TIF_RESTORE_SIGMASK)
#define _TIF_USER_WORK_MASK (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | \
- _TIF_NEED_RESCHED)
+ _TIF_NEED_RESCHED | _TIF_RESTORE_SIGMASK)
#endif /* __KERNEL__ */
diff --git a/include/asm-parisc/unistd.h b/include/asm-parisc/unistd.h
index c56fccb..452e9cb 100644
--- a/include/asm-parisc/unistd.h
+++ b/include/asm-parisc/unistd.h
@@ -950,6 +950,8 @@ type name(type1 arg1, type2 arg2, type3
#define __ARCH_WANT_SYS_SIGPENDING
#define __ARCH_WANT_SYS_SIGPROCMASK
#define __ARCH_WANT_SYS_RT_SIGACTION
+#define __ARCH_WANT_SYS_RT_SIGSUSPEND
+#define __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND
#endif
/* mmap & mmap2 take 6 arguments */
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply related
* Re: [PATCH 2.6.16] Shared interrupts sometimes lost
From: Lee Revell @ 2006-04-09 18:24 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel
In-Reply-To: <44394EA6.3000309@shaw.ca>
On Sun, 2006-04-09 at 12:12 -0600, Robert Hancock wrote:
> Lee Revell wrote:
> > Isn't a more typical IRQ handler:
> >
> > while (events = read_register(INTERRUPTS) != 0) {
> > ...handle each bit in events and ACK it...
> > }
>
> That would be less efficient, it would read the register twice or more
> if any events have been set, and reading device registers can be
> expensive. In the unlikely event the event was set while inside the
> ISR the interrupt should be asserted again so there is no need to do
> this.
OK. FWIW I am looking at the emu10k1 driver (though I've seen this in
others). The OSS driver has this comment:
/*
** NOTE :
** We do a 'while loop' here cos on certain machines, with both
** playback and recording going on at the same time, IRQs will
** stop coming in after a while. Checking IPND indeed shows that
** there are interrupts pending but the PIC says no IRQs pending.
** I suspect that some boards need edge-triggered IRQs but are not
** getting that condition if we don't completely clear the IPND
** (make sure no more interrupts are pending).
** - Eric
*/
The ALSA driver preserves the while loop but omits the comment :-/
Lee
^ permalink raw reply
* Re: [patch][rfc] quell interactive feeding frenzy
From: Mike Galbraith @ 2006-04-09 18:24 UTC (permalink / raw)
To: bert hubert
Cc: Con Kolivas, lkml, Ingo Molnar, Andrew Morton, Nick Piggin,
Peter Williams
In-Reply-To: <20060409121436.GA28075@outpost.ds9a.nl>
On Sun, 2006-04-09 at 14:14 +0200, bert hubert wrote:
> On Sun, Apr 09, 2006 at 01:39:38PM +0200, Mike Galbraith wrote:
> > Ok, unusable may be overstated. Nonetheless, that bit of code causes
> > serious problems. It makes my little PIII/500 test box trying to fill
> > one 100Mbit local network unusable. That is not overstated.
>
> If you try to make a PIII/500 fill 100mbit of TCP/IP using lots of different
> processes, that IS a corner load.
I'm trying to wrap my head around this statement, and failing. I have
10 tasks, I divide 100mbs/10 (_very_ modest concurrency) , and I can't
even login.
-Mike
^ permalink raw reply
* 2.6.17-rc1-mm2: badness in 3w_xxxx driver
From: Nick Orlov @ 2006-04-09 18:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, Jens Axboe, James Bottomley
The following patch: x86-kmap_atomic-debugging.patch exposed a badness
in 3w_xxx driver. I'm getting a lot of:
Apr 9 13:00:04 nickolas kernel: kmap_atomic: local irqs are enabled while using KM_IRQn
Apr 9 13:00:04 nickolas kernel: <c0104103> show_trace+0x13/0x20 <c010412e> dump_stack+0x1e/0x20
Apr 9 13:00:04 nickolas kernel: <c01159c9> kmap_atomic+0x79/0xe0 <c028b885> tw_transfer_internal+0x85/0xa0
Apr 9 13:00:04 nickolas kernel: <c028ca7e> tw_interrupt+0x3fe/0x820 <c0143b9e> handle_IRQ_event+0x3e/0x80
Apr 9 13:00:04 nickolas kernel: <c0143c70> __do_IRQ+0x90/0x100 <c01057a6> do_IRQ+0x26/0x40
Apr 9 13:00:04 nickolas kernel: <c010396e> common_interrupt+0x1a/0x20 <c0101cdd> cpu_idle+0x4d/0xb0
Apr 9 13:00:04 nickolas kernel: <c010f2cc> start_secondary+0x24c/0x4b0 <00000000> 0x0
Apr 9 13:00:04 nickolas kernel: <c214ffb4> 0xc214ffb4
I'm running 32 bit kernel on AMD64x2 w/ HIGHMEM enabled.
I think this is an old bug since the 3w_xxxx.c has not been changed for
a long time (at least since 2.6.16-rc1-mm4).
Please let me know if you want me to try some patches.
--
With best wishes,
Nick Orlov.
^ permalink raw reply
* Re: [uml-devel] uml_utilities-20060323 fails to build on alpha
From: Mattia Dongili @ 2006-04-09 18:23 UTC (permalink / raw)
To: UML-devel; +Cc: Blaisorblade
In-Reply-To: <20060409180709.GA20099@inferi.kami.home>
On Sun, Apr 09, 2006 at 08:07:09PM +0200, Mattia Dongili wrote:
> Hello,
>
> I hear you say "who cares?" :)
> Well, such failure uncovers a small bug on 64bit arches with __u64 not
> defined as unsigned long long (oh, that "who cares" again :)).
>
> cow.c: At top level:
> cow.c:271: error: conflicting types for 'read_cow_header'
> cow.h:25: error: previous declaration of 'read_cow_header' was here
forgot to tell: full log of the failure is available here
http://buildd.debian.org/fetch.php?&pkg=uml-utilities&ver=20060323-1&arch=alpha&stamp=1144601041&file=log&as=raw
Thanks
--
mattia
:wq!
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: omap git tree inconsistency
From: tony @ 2006-04-09 18:18 UTC (permalink / raw)
To: Komal Shah; +Cc: linux-omap-open-source
In-Reply-To: <20060408153234.54204.qmail@web32901.mail.mud.yahoo.com>
* Komal Shah <komal_shah802003@yahoo.com> [060408 08:32]:
> --- Tony Lindgren <tony@atomide.com> wrote:
>
> >
> > Thanks for noting it! I've synced it with the mainline tree.
> >
>
> Not complete yet !. Check drivers/i2c/chips in our tree and you will
> find x1205.c driver, which is not present in the linus tree, as it was
> moved to new rtc subsystem folder with new name rtc-x1205.c. So I
> believe there will more locations like this...:)
This seemed to be only on source.mvista.com tree for some reason.
Running git diff showed some unmerged changes. No idea how that has
happened, maybe an interrupted push or something.
In any case, I re-cloned the tree and that seems to have taken care
of it.
BTW, I may not have net access until Thursday.
Tony
^ permalink raw reply
* Re: [PATCH 2.6.16] Shared interrupts sometimes lost
From: Robert Hancock @ 2006-04-09 18:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Lee Revell
In-Reply-To: <5ZoDL-3rE-7@gated-at.bofh.it>
Lee Revell wrote:
> On Sat, 2006-04-08 at 14:10 +1000, Neil Brown wrote:
>> To explain what I think is happening, let me start with a very simple
>> case. A number of PCI devices (this one included) have a number of
>> events which can trigger an interrupt. The events which are current
>> are presented as bits in a register, and are ORed together (and
>> possibly masked by another register) to make the IRQ line.
>> When 1's are written to any bits in this register, it acknowledges
>> the event and clears the bit.
>> A typical code fragment is
>> events = read_register(INTERRUPTS);
>> write_register(INTERRUPTS, events);
>> ... handle each 1 bits in events ....
>>
>
> Isn't a more typical IRQ handler:
>
> while (events = read_register(INTERRUPTS) != 0) {
> ...handle each bit in events and ACK it...
> }
That would be less efficient, it would read the register twice or more
if any events have been set, and reading device registers can be
expensive. In the unlikely event the event was set while inside the ISR
the interrupt should be asserted again so there is no need to do this.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply
* Re: A failed-disk-how-to anywhere?
From: Mike Hardy @ 2006-04-09 18:12 UTC (permalink / raw)
To: Brad Campbell; +Cc: Martin Stender, linux-raid
In-Reply-To: <44391806.3000200@wasp.net.au>
Brad Campbell wrote:
> Martin Stender wrote:
>
>> Hi there!
>>
>> I have two identical disks sitting on a Promise dual channel IDE
>> controller. I guess both disks are primary's then.
>>
>> One of the disks have failed, so I bought a new disk, took out the
>> failed disk, and put in the new one.
>> That might seem a little naive, and apparently it was, since the
>> system won't boot up now.
>> It boots fine, when only the old, healthy disk is connected.
> My initial thought would be you have hde and hdg in a raid-1 and nothing
> on the on-board controllers. hde has failed and when you removed it your
> controller tried the 1st disk it could find (hdg) to boot of.. Bingo..
> away we go.
> You plug a new shiny disk into hde and now the controller tries to boot
> off that, except it's blank and therefore a no-go.
>
> I'd either try and force the controller to boot off hdg (which might be
> a controller bios option) or swap hde & hdg.. then it might boot and let
> you create your partitions on hdg and then add it back into the mirror.
I'd add another stab in the dark and guess that you didn't install your
boot loader on both drives.
Not that I've ever done that before (ok, a few times, most recently two
days ago, sigh)
Typically the BIOS will try all hard drives and so it should have rolled
to one that worked, but if only the "failed" drive had the boot loader
then you are of course not bootable.
I solved this by booting rescue mode, starting up the raid arrays,
mounting them, and manually grub installing. Here's a good page for the
grub incantations:
http://gentoo-wiki.com/HOWTO_Gentoo_Install_on_Software_RAID_mirror_and_LVM2_on_top_of_RAID#Bootloader_installation_and_configuration
-Mike
^ permalink raw reply
* Re: [LARTC] Possible kernel bug with routes
From: Sven Anders @ 2006-04-09 18:10 UTC (permalink / raw)
To: lartc
In-Reply-To: <4427B6E4.5020804@anduras.de>
[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]
First of all: Thanks for the answer!!!!
Ard van Breemen schrieb:
> On Mon, Mar 27, 2006 at 11:56:52AM +0200, Sven Anders wrote:
> <snipped a lot>
>>> ip route add 10.100.0.0/24 dev eth0 proto kernel scope link
>> RTNETLINK answers: File exists
>
> s/add/append/
>
>> I thought they are different!?!
>> Is here any difference I did not see?
>> If they are not different, why does the kernel not recognize it
>> (see above) and avoid the duplicate entry?
>
> add prevents duplicates, append just adds.
Ok, this would prevent the error, but it does not explain the error itself. Did
you tried it yourself? All I want to know is, if I did a mistake. If so, please
explain my error...
>> Another question:
>>
>> Why can't I set a route on an interface that is down?
>
> That's by some design. Use patches from linuxvirtualserver.org if
> you want them to exist.
Ok, I will try it... But what's the reason for this design?
I think, this test could be done in user-space and did not have to be in the
kernel.
>
>> PPS: Why is ANYBODY still ignoring this e-mail for over 3 weeks?????
>
> People are busy :-)
Ok, I understand this, but for over three weeks with so many people on this
mailing list?? :-)
Regards
Sven
--
Sven Anders <anders@anduras.de> () Ascii Ribbon Campaign
/\ Support plain text e-mail
ANDURAS service solutions AG
Innstra?e 71 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
[-- Attachment #2: anders.vcf --]
[-- Type: text/x-vcard, Size: 339 bytes --]
begin:vcard
fn:Sven Anders
n:Anders;Sven
org:ANDURAS AG;Research and Development
adr;quoted-printable:;;Innstra=C3=9Fe 71;Passau;Bavaria;94036;Germany
email;internet:anders@anduras.de
title:Dipl. Inf.
tel;work:++49 (0)851 / 490 50 - 0
tel;fax:+49 (0)851 / 4 90 50 - 55
x-mozilla-html:FALSE
url:http://www.anduras.de
version:2.1
end:vcard
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [RFH] Exploration of an alternative diff_delta() algorithm
From: Nicolas Pitre @ 2006-04-09 18:08 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060409175316.GA21455@erlang.gbar.dtu.dk>
On Sun, 9 Apr 2006, Peter Eriksen wrote:
> On Sun, Apr 09, 2006 at 01:40:14PM -0400, Nicolas Pitre wrote:
> ...
> > It also has lots of compilation warnings.
>
> Hm, I don't get any warnings. Would you mind pasting them, so I
> can see what it's about?
gcc -o diff-delta.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' diff-delta.c
diff-delta.c: In function 'diff_delta':
diff-delta.c:123: warning: pointer targets in passing argument 1 of 'init_hash' differ in signedness
diff-delta.c:124: warning: pointer targets in passing argument 1 of 'init_hash' differ in signedness
diff-delta.c:170: warning: pointer targets in passing argument 1 of 'hash' differ in signedness
diff-delta.c:171: warning: pointer targets in passing argument 1 of 'hash' differ in signedness
diff-delta.c:203: warning: pointer targets in passing argument 1 of 'init_hash' differ in signedness
diff-delta.c:204: warning: pointer targets in passing argument 1 of 'init_hash' differ in signedness
Also you should avoid declaring new variables after code in the same
scope, like you do with version_offset for example. This is a feature
that many C compilers don't support.
Nicolas
^ permalink raw reply
* [PATCH] PCI: Use new PCI_CLASS_SERIAL_USB_* defines
From: Jean Delvare @ 2006-04-09 18:07 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-pci
We could use the recently added PCI_CLASS_SERIAL_USB_UHCI,
PCI_CLASS_SERIAL_USB_OHCI and PCI_CLASS_SERIAL_USB_EHCI defines in
more places, for slightly shorter and clearer code.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
arch/powerpc/platforms/powermac/pci.c | 2 +-
drivers/usb/host/ehci-pci.c | 2 +-
drivers/usb/host/ohci-pci.c | 2 +-
drivers/usb/host/uhci-hcd.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/powermac/pci.c 2006-04-03 20:12:30.000000000 +0200
+++ linux-2.6.17-rc1/arch/powerpc/platforms/powermac/pci.c 2006-04-09 19:12:07.000000000 +0200
@@ -1097,7 +1097,7 @@
* (iBook second controller)
*/
if (dev->vendor == PCI_VENDOR_ID_APPLE
- && (dev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x10))
+ && dev->class == PCI_CLASS_SERIAL_USB_OHCI
&& !node) {
printk(KERN_INFO "Apple USB OHCI %s disabled by firmware\n",
pci_name(dev));
--- linux-2.6.17-rc1.orig/drivers/usb/host/ehci-pci.c 2006-04-03 20:13:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/usb/host/ehci-pci.c 2006-04-09 19:12:44.000000000 +0200
@@ -350,7 +350,7 @@
/* PCI driver selection metadata; PCI hotplugging uses this */
static const struct pci_device_id pci_ids [] = { {
/* handle any USB 2.0 EHCI controller */
- PCI_DEVICE_CLASS(((PCI_CLASS_SERIAL_USB << 8) | 0x20), ~0),
+ PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_EHCI, ~0),
.driver_data = (unsigned long) &ehci_pci_hc_driver,
},
{ /* end: all zeroes */ }
--- linux-2.6.17-rc1.orig/drivers/usb/host/ohci-pci.c 2006-04-03 20:13:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/usb/host/ohci-pci.c 2006-04-09 19:12:27.000000000 +0200
@@ -206,7 +206,7 @@
static const struct pci_device_id pci_ids [] = { {
/* handle any USB OHCI controller */
- PCI_DEVICE_CLASS((PCI_CLASS_SERIAL_USB << 8) | 0x10, ~0),
+ PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_OHCI, ~0),
.driver_data = (unsigned long) &ohci_pci_hc_driver,
}, { /* end: all zeroes */ }
};
--- linux-2.6.17-rc1.orig/drivers/usb/host/uhci-hcd.c 2006-04-03 20:13:10.000000000 +0200
+++ linux-2.6.17-rc1/drivers/usb/host/uhci-hcd.c 2006-04-09 19:10:16.000000000 +0200
@@ -861,7 +861,7 @@
static const struct pci_device_id uhci_pci_ids[] = { {
/* handle any USB UHCI controller */
- PCI_DEVICE_CLASS(((PCI_CLASS_SERIAL_USB << 8) | 0x00), ~0),
+ PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_UHCI, ~0),
.driver_data = (unsigned long) &uhci_driver,
}, { /* end: all zeroes */ }
};
--
Jean Delvare
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: andrzej zaborowski @ 2006-04-09 18:07 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44393064.2050300@win4lin.com>
On 09/04/06, Leonardo E. Reiter <lreiter@win4lin.com> wrote:
> Yeah, the min/max value thing would be a pain for sure. The X server
> config method seems to be the best bet.
>
> On another note, I am trying to imagine what would make logical sense
> for say, a touch screen. For example, an LCD panel has a native
> resolution, say 1024x768. It would then emulate (or transparently
> expand) other VESA resolutions, such as 640x480, on the fly. I would
> think that if it had touchscreen capabilities, the coordinates would
> always be reported in native mode. So the guest OS must have to scale
> them down... especially if the device reports the range early on in the
> identification process.
>
As Brad Campbell noted, touchscreens always report absolute
coordinates that need to be scaled by the OS. I have a working
emulation for the TSC2301 touchscreen controller (used in PDAs) in
QEMU and what this chipset does is simply report raw voltage values
from the three wires that connect the touchscreen device and chipset
(through a configurable 12-bit A/D converter). These three signals (X,
Y and pressure) usually take values in the range from about 300 to
about 4000 (while the LCD resolution is 320x320) and contain some
noise, but still the resolution of the touchscreen is much higher than
the LCD's.
Under Linux, userspace can read these values using either evdev or
tsdev (deprecated), both of which report only absolute coordinates. X
compiled with tslib support works really nice with this touchscreen
(both in QEMU and on real devices). Tslib performs the calibration,
noise reduction (averaging) and other tricks.
In QEMU I use parts of Anthony Liguori's WACOM patch for absolute
coordinates, except the cursor hiding, because the guest doesn't know
where the cursor is until it receives the pen-down event (i.e until
you click on QEMU window).
> If this were done in QEMU, we'd have to pick an arbitrary "native"
> resolution - for example, 1600x1200, the max the cirrus device can go.
> We would then have to scale it down automatically based on the set
> resolution, so that the guest OS can scale it up.
>
> I'm just thinking out loud. The good news is that making changes to the
> open source bits on guests (like Xorg) is trivial... it's, as been said,
> the closed source guests that would be the most problematic. So
> sticking to the HID protocol to make this happen would be best.
>
> - Leo
>
> Anthony Liguori wrote:
> > I was looking through the Xorg evdev driver and it doesn't appear to
> > support absolute coordinate reporting. evdev is how the USB mouse would
> > show up to userspace. A little googling confirmed it for me:
> >
> > http://lists.freedesktop.org/archives/xorg/2005-September/010140.html
> >
> > USB wacom still seems the most promising to me but I fear getting it to
> > work under Windows will be a pain.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >
> > Leonardo E. Reiter wrote:
> >
> >> This is by no means a complete patch (do not apply it as it will break
> >> usb-hid.c), but it adjusts the report descriptor in usb-hid.c to
> >> provide position in 16-bits, and in absolute coordinates:
> >>
> >> Index: usb-hid.c
> >> ===================================================================
> >> RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
> >> retrieving revision 1.1
> >> diff -a -u -r1.1 usb-hid.c
> >> --- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1
> >> +++ usb-hid.c 8 Apr 2006 20:56:02 -0000
> >> @@ -117,7 +117,7 @@
> >> 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
> >> 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
> >> 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
> >> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
> >> + 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02,
> >> 0xC0, 0xC0,
> >> };
> >>
> >> According to:
> >> http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1
> >>
> >>
> >> I'm still trying to figure out how the logical min/max apply if we are
> >> to report absolute (unsigned) positions in 16-bits. Obviously 8-bits
> >> is not enough for absolute coordinates. You could theoretically use
> >> only 12-bits per coordinate but that would make life difficult I
> >> think, and probably unnecessarily frugal in a software emulation.
> >>
> >> It's not clear to me [yet] how the scroll wheel comes into play, and
> >> whether or not it (the dz coordinate) can be kept relative for ease of
> >> implementation. Also the code would need to be changed to report
> >> coordinates in 16-bits rather than 8, and of course made to report
> >> absolute coordinates (like from sdl.c, etc.) Still it looks fairly
> >> easy to implement - the USB spec is pretty simple.
> >>
> >> So to reiterate, my patch does virtually nothing - in fact it will
> >> break usb-hid.c so please don't use it. I was just illustrating how
> >> to get it to report the device as providing 16-bit absolute
> >> coordinates instead of 8-bit relative ones. If anyone wants to chime
> >> in with more info, I'd be glad to make this a discussion. *If* using
> >> the USB HID device only, not any real USB devices, can be done without
> >> slowing down QEMU, then I think this is a great way to get a tablet
> >> emulated without having to deal with drivers on either side. Plus, in
> >> the long run, it probably means other neat stuff like being able to
> >> get away from ISA bus emulation, and also it's portable to other
> >> targets (for example, OS-X on PPC would talk to the USB HID device the
> >> same way theoretically), so it's likely the most portable and cleanest
> >> option.
> >>
> >> Regards,
> >>
> >> Leo Reiter
> >>
> >> Brad Campbell wrote:
> >>
> >>> Apparently USB HID supports absolute input devices natively. Given we
> >>> have a HID mouse driver of sorts in qemu I wonder if that is another
> >>> avenue perhaps ?
> >>>
> >>>
> >>
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
> --
> Leonardo E. Reiter
> Vice President of Product Development, CTO
>
> Win4Lin, Inc.
> Virtual Computing from Desktop to Data Center
> Main: +1 512 339 7979
> Fax: +1 512 532 6501
> http://www.win4lin.com
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
Regards,
Andrew
--
balrog 2oo6
Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258
^ permalink raw reply
* Re: [patch][rfc] quell interactive feeding frenzy
From: Mike Galbraith @ 2006-04-09 18:07 UTC (permalink / raw)
To: bert hubert
Cc: Con Kolivas, lkml, Ingo Molnar, Andrew Morton, Nick Piggin,
Peter Williams
In-Reply-To: <20060409121436.GA28075@outpost.ds9a.nl>
On Sun, 2006-04-09 at 14:14 +0200, bert hubert wrote:
> On Sun, Apr 09, 2006 at 01:39:38PM +0200, Mike Galbraith wrote:
> > Ok, unusable may be overstated. Nonetheless, that bit of code causes
> > serious problems. It makes my little PIII/500 test box trying to fill
> > one 100Mbit local network unusable. That is not overstated.
>
> If you try to make a PIII/500 fill 100mbit of TCP/IP using lots of different
> processes, that IS a corner load.
>
> I'm sure you can fix this (rare) workload but are you very sure you are not
> killing off performance for other situations?
Rare? What exactly is rare about a number of tasks serving data? I
don't care if it's a P4 serving gigabit. If you have to divide your
server into pieces (you do, and you know it) you're screwed.
> I get flashbacks to the old days of the VM where we had lots patches around
> that would all solve (more or less) real problems, but never all at the same
> time..
I choose to take the high road here, and will not respond.
-Mike
^ permalink raw reply
* [uml-devel] uml_utilities-20060323 fails to build on alpha
From: Mattia Dongili @ 2006-04-09 18:07 UTC (permalink / raw)
To: UML-devel; +Cc: Blaisorblade
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
Hello,
I hear you say "who cares?" :)
Well, such failure uncovers a small bug on 64bit arches with __u64 not
defined as unsigned long long (oh, that "who cares" again :)).
cow.c: At top level:
cow.c:271: error: conflicting types for 'read_cow_header'
cow.h:25: error: previous declaration of 'read_cow_header' was here
the attached patch fixes it.
Thanks
--
mattia
:wq!
[-- Attachment #2: fix_moo_conflicting_types_for_read_cow_header.diff --]
[-- Type: text/plain, Size: 464 bytes --]
--- tools-20060323/moo/cow.c~clean 2006-04-09 19:10:15.324384228 +0200
+++ tools-20060323/moo/cow.c 2006-04-09 19:10:27.433140978 +0200
@@ -265,7 +265,7 @@
int read_cow_header(int (*reader)(__u64, char *, int, void *), void *arg,
__u32 *version_out, char **backing_file_out,
- time_t *mtime_out, unsigned long long *size_out,
+ time_t *mtime_out, __u64 *size_out,
int *sectorsize_out, __u32 *align_out,
int *bitmap_offset_out)
{
^ permalink raw reply
* Re: net interface renaming issue (+fix?)
From: Andrey Borzenkov @ 2006-04-09 18:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060409192140.73644723@eusebe>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 09 April 2006 21:21, Thomas de Grenier de Latour wrote:
> Hi,
>
> I'm running Gentoo Linux, a 2.6.16-ck kernel, and udev-0.89-r2, and
> have had hard time with network interfaces renaming through udev
> rules. The first thing i've tried were rules like this one:
>
> SUBSYSTEM="net", KERNEL="eth*", SYSFS{address}="00:0d:60:12:75:0a",
> NAME="lan"
>
> Plus this one from the standard early rules:
>
> ACTION="add", SUBSYSTEM="net", WAIT_FOR_SYSFS="address"
>
> It doesn't work when i "modprobe e1000" (my ethernet driver):
> ....
> udevd[21612]: udev_event_run: seq 956 forked, pid [21816], 'add' 'net', 0
> seconds old udevd-event[21816]: wait_for_sysfs: file
> '/sys/class/net/eth0/address' appeared after 0 loops udevd-event[21816]:
> udev_rules_get_name: no node name set, will use kernel name 'eth0' ....
> But if i later do a "echo add > /sys/class/net/eth0/uevent", then
> interface is properly renamed. It also works fine if i start with
> the module initialy not loaded, and then trigger the uevent on the
> corresponding pci device (will load the module, etc.)
>
There appears to be race between creating 'address' and getting (usable)
value. See below.
[...]
>
> So i wonder, maybe such a rule should be added to the standard early
> ones? It should maybe use more checks though, to be sure there is
> actually a driver to wait. Something like ENV{PHYSDEVPATH}="?*"
> and/or ENV{PHYSDEVDRIVER}="?*".
>
You probably get reply that they are obsolete and should not be used in new
rules :)
[...]
> Or is "address" being added to sysfs with no useful value yet the real
> issue, and my rule only an ugly workround?
>
Seems so.
net/core/net-syfs.c:dev_isalive():
return dev->reg_state = NETREG_REGISTERED;
net/core/net-syfs.c:show_address():
if (dev_isalive(net))
ret = format_addr(buf, net->dev_addr, net->addr_len);
net/core/dev.c:netdev_run_todo():
err = netdev_register_sysfs(dev);
if (err)
printk(KERN_ERR "%s: failed sysfs registration
(%d)\n",
dev->name, err);
dev->reg_state = NETREG_REGISTERED;
break;
So basically there is a window between net device appearing in sysfs and
'address' returning usable value. To test you could move dev->reg_state
assignment before netdev_register_sysfs call; if this helps it makes sense
ask on net list if this is safe change.
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEOUvTR6LMutpd94wRAg+nAKCXnI9mrChpQ9TAz4VVQhSaP/MQjgCfbX6n
5lcJ30K1qpTtbxISei6pN9I=Rwsc
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [uml-devel] [PATCH] uml: problem with 2G/2G host address space
From: Jeff Dike @ 2006-04-09 17:01 UTC (permalink / raw)
To: Joris van Rantwijk; +Cc: user-mode-linux-devel
In-Reply-To: <20060409105755.GA24319@xs4all.nl>
On Sun, Apr 09, 2006 at 12:57:55PM +0200, Joris van Rantwijk wrote:
> It soon made sense to me that a 3G/1G configured UML would crash like
> this, but I then found that UML 2.6.16.2 configured for 2G/2G crashed
> in exactly the same way. I think this is due to the fact that STUB_CODE
> and STUB_DATA are fixed at the 3G/1G settings. After changing these
> settings, everything seems to work properly in 2G/2G mode.
Your analysis is correct, and the patch is fine as far as it goes, but
we were talking about this a week or so ago about detecting the host
address space split at runtime. There's a lot more potential
flexibility there than just 3/1 and 2/2.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: net interface renaming issue (+fix?)
From: Sergey Vlasov @ 2006-04-09 17:56 UTC (permalink / raw)
To: Thomas de Grenier de Latour; +Cc: Linux-hotplug-devel, netdev
In-Reply-To: <20060409192140.73644723@eusebe>
[-- Attachment #1: Type: text/plain, Size: 5493 bytes --]
On Sun, 9 Apr 2006 19:21:40 +0200 Thomas de Grenier de Latour wrote:
> Hi,
>
> I'm running Gentoo Linux, a 2.6.16-ck kernel, and udev-0.89-r2, and
> have had hard time with network interfaces renaming through udev
> rules. The first thing i've tried were rules like this one:
>
> SUBSYSTEM=="net", KERNEL=="eth*", SYSFS{address}=="00:0d:60:12:75:0a", NAME="lan"
>
> Plus this one from the standard early rules:
>
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="address"
>
> It doesn't work when i "modprobe e1000" (my ethernet driver):
> ...
> udevd[21612]: udev_event_run: seq 956 forked, pid [21816], 'add' 'net', 0 seconds old
> udevd-event[21816]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21816]: udev_rules_get_name: no node name set, will use kernel name 'eth0'
> ...
> But if i later do a "echo add > /sys/class/net/eth0/uevent", then
> interface is properly renamed. It also works fine if i start with
> the module initialy not loaded, and then trigger the uevent on the
> corresponding pci device (will load the module, etc.)
>
>
> Then i've tried replacing the address match by DRIVER=="e1000", with
> no more success. But i've noticed something interesting in debug
> output, when the rule matcher walks up in parent devices to check
> the driver:
> % grep -i driver /var/tmp/udev-net-debug.log
> ...
> udevd-event[18411]: match_key: key DRIVER value='e1000'
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> ''
> udevd-event[18411]: match_key: DRIVER is false
> udevd-event[18411]: sysfs_device_get: add to cache 'devpath=/devices/pci0000:00/0000:00:1e.0/0000:02:01.0', subsystem='pci', driver=''
> udevd-event[18411]: match_key: key DRIVER value='e1000'
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> ''
> udevd-event[18411]: match_key: DRIVER is false
> ...
> This is weird, because if i latter look in /sys, the "driver" links
> are here. Which made me think it was a race, so i've added this rule:
>
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="device/driver"
>
> And it fixed the problem:
> ...
> udevd[21612]: udev_event_run: seq 950 forked, pid [21790], 'add' 'net', 0 seconds old
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21790]: wait_for_sysfs: wait for '/sys/class/net/eth0/device/driver' for 20 mseconds
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/device/driver' appeared after 1 loops
> udevd-event[21790]: udev_rules_get_name: rule applied, 'eth0' becomes 'lan'
> udevd-event[21790]: rename_net_if: changing net interface name from 'eth0' to 'lan'
> udevd-event[21790]: udev_add_device: renamed netif to 'lan'
> ...
>
> It also fixes the problem with using a SYSFS{address} match btw.
> With no such wait, i can see in debug that "address" is found in sysfs,
> but with no value:
> ...
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21977]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> ...
> Whereas with the wait-for-driver trick, i can see it read with a
> useful value:
> ...
> udevd-event[21954]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21954]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: cache '/sys/class/net/eth0/address' with value '00:0d:60:12:75:0a'
> ...
>
> So i wonder, maybe such a rule should be added to the standard early
> ones? It should maybe use more checks though, to be sure there is
> actually a driver to wait. Something like ENV{PHYSDEVPATH}=="?*"
> and/or ENV{PHYSDEVDRIVER}=="?*".
>
> Btw, using ENV{PHYSDEVDRIVER}=="e1000" in my renaming rule was working
> fine, with no trick (this variables are correctly set, like 'udevmonitor
> --env' shows).
>
>
> So, what do you think, does such a rule makes sense?
> Or is "address" being added to sysfs with no useful value yet the real
> issue, and my rule only an ugly workround?
(quoting the whole message for netdev)
Apparently there is a race there. The "add" uevent for /class/net/eth0
is emitted by class_device_register(), which is called by
netdev_register_sysfs(). Class device attributes (like "address") are
also added by class_device_register() (really class_device_add(), which
is invoked from there), but this is done before generating the uevent,
so at the first glance there is no race here (and waiting for "address"
is unnecessary). However, show_address() does not output anything
unless dev->reg_state == NETREG_REGISTERED - and this state is set by
netdev_run_todo() only after netdev_register_sysfs() returns, so in the
meantime (while netdev_register_sysfs() is busy adding the "statistics"
attribute group) some process may see an empty "address" attribute.
Waiting for "device/driver" ensures that udevd continues to process the
uevent only after the probe function completes, which ensures completion
of the registration (netdev_run_todo() is invoked by rtnl_unlock() at
the end of register_netdev() and processes all pending requests).
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: net interface renaming issue (+fix?)
From: Sergey Vlasov @ 2006-04-09 17:56 UTC (permalink / raw)
To: Thomas de Grenier de Latour; +Cc: Linux-hotplug-devel, netdev
In-Reply-To: <20060409192140.73644723@eusebe>
[-- Attachment #1: Type: text/plain, Size: 5493 bytes --]
On Sun, 9 Apr 2006 19:21:40 +0200 Thomas de Grenier de Latour wrote:
> Hi,
>
> I'm running Gentoo Linux, a 2.6.16-ck kernel, and udev-0.89-r2, and
> have had hard time with network interfaces renaming through udev
> rules. The first thing i've tried were rules like this one:
>
> SUBSYSTEM=="net", KERNEL=="eth*", SYSFS{address}=="00:0d:60:12:75:0a", NAME="lan"
>
> Plus this one from the standard early rules:
>
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="address"
>
> It doesn't work when i "modprobe e1000" (my ethernet driver):
> ...
> udevd[21612]: udev_event_run: seq 956 forked, pid [21816], 'add' 'net', 0 seconds old
> udevd-event[21816]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21816]: udev_rules_get_name: no node name set, will use kernel name 'eth0'
> ...
> But if i later do a "echo add > /sys/class/net/eth0/uevent", then
> interface is properly renamed. It also works fine if i start with
> the module initialy not loaded, and then trigger the uevent on the
> corresponding pci device (will load the module, etc.)
>
>
> Then i've tried replacing the address match by DRIVER=="e1000", with
> no more success. But i've noticed something interesting in debug
> output, when the rule matcher walks up in parent devices to check
> the driver:
> % grep -i driver /var/tmp/udev-net-debug.log
> ...
> udevd-event[18411]: match_key: key DRIVER value='e1000'
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> ''
> udevd-event[18411]: match_key: DRIVER is false
> udevd-event[18411]: sysfs_device_get: add to cache 'devpath=/devices/pci0000:00/0000:00:1e.0/0000:02:01.0', subsystem='pci', driver=''
> udevd-event[18411]: match_key: key DRIVER value='e1000'
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> ''
> udevd-event[18411]: match_key: DRIVER is false
> ...
> This is weird, because if i latter look in /sys, the "driver" links
> are here. Which made me think it was a race, so i've added this rule:
>
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="device/driver"
>
> And it fixed the problem:
> ...
> udevd[21612]: udev_event_run: seq 950 forked, pid [21790], 'add' 'net', 0 seconds old
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21790]: wait_for_sysfs: wait for '/sys/class/net/eth0/device/driver' for 20 mseconds
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/device/driver' appeared after 1 loops
> udevd-event[21790]: udev_rules_get_name: rule applied, 'eth0' becomes 'lan'
> udevd-event[21790]: rename_net_if: changing net interface name from 'eth0' to 'lan'
> udevd-event[21790]: udev_add_device: renamed netif to 'lan'
> ...
>
> It also fixes the problem with using a SYSFS{address} match btw.
> With no such wait, i can see in debug that "address" is found in sysfs,
> but with no value:
> ...
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21977]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> ...
> Whereas with the wait-for-driver trick, i can see it read with a
> useful value:
> ...
> udevd-event[21954]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21954]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: cache '/sys/class/net/eth0/address' with value '00:0d:60:12:75:0a'
> ...
>
> So i wonder, maybe such a rule should be added to the standard early
> ones? It should maybe use more checks though, to be sure there is
> actually a driver to wait. Something like ENV{PHYSDEVPATH}=="?*"
> and/or ENV{PHYSDEVDRIVER}=="?*".
>
> Btw, using ENV{PHYSDEVDRIVER}=="e1000" in my renaming rule was working
> fine, with no trick (this variables are correctly set, like 'udevmonitor
> --env' shows).
>
>
> So, what do you think, does such a rule makes sense?
> Or is "address" being added to sysfs with no useful value yet the real
> issue, and my rule only an ugly workround?
(quoting the whole message for netdev)
Apparently there is a race there. The "add" uevent for /class/net/eth0
is emitted by class_device_register(), which is called by
netdev_register_sysfs(). Class device attributes (like "address") are
also added by class_device_register() (really class_device_add(), which
is invoked from there), but this is done before generating the uevent,
so at the first glance there is no race here (and waiting for "address"
is unnecessary). However, show_address() does not output anything
unless dev->reg_state == NETREG_REGISTERED - and this state is set by
netdev_run_todo() only after netdev_register_sysfs() returns, so in the
meantime (while netdev_register_sysfs() is busy adding the "statistics"
attribute group) some process may see an empty "address" attribute.
Waiting for "device/driver" ensures that udevd continues to process the
uevent only after the probe function completes, which ensures completion
of the registration (netdev_run_todo() is invoked by rtnl_unlock() at
the end of register_netdev() and processes all pending requests).
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ 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.