* Re: Page Migration: Make do_swap_page redo the fault
From: Christoph Lameter @ 2006-04-08 21:39 UTC (permalink / raw)
To: Hugh Dickins; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604082022170.12196@blonde.wat.veritas.com>
On Sat, 8 Apr 2006, Hugh Dickins wrote:
> On Sat, 8 Apr 2006, Christoph Lameter wrote:
> >
> > Hmmm..,. There are still two other checks for !PageSwapCache after
> > obtaining a page lock in shmem_getpage() and in try_to_unuse().
> > However, both are getting to the page via the swap maps. So we need to
> > keep those.
>
> Sure, those are long standing checks, necessary long before migration
> came on the scene; whereas the check in do_swap_page was recently added
> just for a page migration case, and now turns out to be redundant.
Those two checks were added for migration together with the one we
are removing now. Sounds like you think they additionally fix some other
race conditions?
The check we are discussing only becomes unnecessary if the swap ptes are
replaced by regular ptes. The swap pte would refer to the old page from
which the SwapCache bit was cleared. This is dependent on remove_from_swap
always functioning properly which happened pretty late in the 2.6.16
cycle.
Here is the description from V9 of the direct migration patchset which
introduced the 3 checks for PageSwapCache():
Check for PageSwapCache after looking up and locking a swap page.
The page migration code may change a swap pte to point to a different page
under lock_page().
If that happens then the vm must retry the lookup operation in the swap
space to find the correct page number. There are a couple of locations
in the VM where a lock_page() is done on a swap page. In these locations
we need to check afterwards if the page was migrated. If the page was
migrated
then the old page that was looked up before was freed and no longer has
the
PageSwapCache bit set.
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Christoph Lameter <clameter@@sgi.com>
--
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: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Leonardo E. Reiter @ 2006-04-08 21:36 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <4438299F.3010604@wasp.net.au>
Brad Campbell wrote:
> Now it's a long time since I've hacked on it but I wrote a userspace
> touch screen driver for win9x years ago that did just this.. I seem to
> recall having to scale the real touchscreen values to between 0x0 and
> 0xffff before feeding them in to the windows message queue.
> From memory 0,0 was top left and ffff,ffff was bottom right.. as
> applied to the current screen resolution. Windows worked the rest out
> itself.. Like I said.. very hazy memory..
There's actually a GDI call you can make if you are in user space that
will allow you to do absolute cursor addressing. The problem is that
you have be in user space, and you have to be able to talk to the
display. By the time this happens, it's way too late in general - for
example, you already got past the Windows login screen, etc. It's
basically what we do on Win4Lin Pro now, but it's not really adequate
for the long run and it's not too fast. Ideally, a USB HID device would
"just work" with the Windows HID "class" driver, and the rest will be
history. HID device drivers are ubiquotous and work on every major OS,
not just Windows obviously (Linux, *BSD, OS-X, etc.), so it truly would
be the most universal solution. And, keeping with the spirit of QEMU,
this solution would mean not having to modify anything in the guest
either. Not too mention how it's 100 times easier (at least) to hack
QEMU than to code a Windows device driver of any sort (IMHO anyway.)
> I'll have a look in the morning and see if I can dig that code out to
> figure out what I did, but given the way windows mouse events work that
> seems logical and would be relatively easy to do in qemu. As for the
> wheel.. I have no idea. An idea I had a while back was to feed the wheel
> and buttons to the ps2 port and get the positioning info in some other
> fashion. Ugly.. very ugly..
Actually the usb-hid.c already seems to be sending Z axis events (the
wheel most likely)... it's just not clear, from reading the USB HID
spec, how this relates to the data, or how this event is described. I
admit I'm pretty new to deciphering USB, and also I haven't actually
played with QEMU's usb-hid device either. As for the X and Y
coordinate, they would have to be sent in some precision greater than
8-bits because screen resolutions are so high. A touchscreen is an
ideal example of the type of device we need, even more so than a tablet.
Thankfully USB makes us not really care what type of physical device
it actually is, as long as we can describe it properly to the consumer
(Windows/etc.). But anyway, we would want to be able to describe
coordinates up to at least 1600x1200 since that is the max that
cirrus_vga accepts, and that would require at least 11 bits per axis.
You'd have to add 2 padding bits in the descriptor if you did it that
way - easier would be 12-bits per axis. Then [I assume], when you send
the motion packet, you would need to send the 24-bits packed rather than
8 and 8 as is done now. I just am not sure what happens to the dz part,
since it's not really described anywhere that I can see. The code I'm
referring to is in hw/usb-hid.c, in the function usb_mouse_poll(). It
looks like the VM requests the Z axis value selectively, and the code
handles this. I'm starting to believe that your dual-device idea makes
good sense, because for example, a touchscreen doesn't have a Z axis.
It will take some trial and error I suspect.
- Leo
--
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
^ permalink raw reply
* Re: strange behavior when pulling updates / get uptodate with git.git
From: Nicolas Vilz 'niv' @ 2006-04-08 21:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzeveqin.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Most likely it is aborted by the "pu" branch not
> fast-forwarding.
>
> Pull: +refs/heads/pu:refs/heads/pu
>
> or dropping "pu" altogether if you are not interested in it,
> would help.
Thank you, the +-sign helped me out.
Sincerly
Nicolas
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Brad Campbell @ 2006-04-08 21:22 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'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.
From what I have managed to read up on thus far, the absolute coordinates are pretty much fed
directly to the application as mouse move events.
Now it's a long time since I've hacked on it but I wrote a userspace touch screen driver for win9x
years ago that did just this.. I seem to recall having to scale the real touchscreen values to
between 0x0 and 0xffff before feeding them in to the windows message queue.
From memory 0,0 was top left and ffff,ffff was bottom right.. as applied to the current screen
resolution. Windows worked the rest out itself.. Like I said.. very hazy memory..
I'll have a look in the morning and see if I can dig that code out to figure out what I did, but
given the way windows mouse events work that seems logical and would be relatively easy to do in
qemu. As for the wheel.. I have no idea. An idea I had a while back was to feed the wheel and
buttons to the ps2 port and get the positioning info in some other fashion. Ugly.. very ugly..
--
"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: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Leonardo E. Reiter @ 2006-04-08 21:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443825D8.3080602@win4lin.com>
Sorry, the patch is not only incomplete, but totally wrong :( The 0x16
should be 0x10, like this:
> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
> + 0x25, 0x7F, 0x75, 0x10, 0x95, 0x02, 0x81, 0x02,
I must have had a momentary lapse of [radix] reason :)
- Leo Reiter
--
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
^ permalink raw reply
* [PATCH 2.6.16] mmc: Read and parse mmc v4 ext_csd structure
From: Philip Langdale @ 2006-04-08 21:13 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Hi all,
I've recently being investigating adding support for the mmc v4 high speed
and wide bus features, based on some documents I found online (A couple of
samsung ones and the freely available mmc v4.1 application note).
For reference, these are:
v4.1 app note: http://www.mmca.org/compliance/buy_spec/AN_MMCA050419.pdf
samsung datsheet:
http://www.samsung.com/Products/Semiconductor/FlashCard/MMC/HighSpeedMMC/Fu=llSize_MMCplus/MC4GH02GNMCA/ds_HS_MMC_rev03.pdf
samsung app note:
http://www.samsung.com/Products/Semiconductor/Memory/appnote/hs_mmc_applica=tion_note_050111.pdf
I have successfully turned high speed and 4 bit transfers on in conjunction
with an sdhci controller and observed the expected speed increase - to be
about equivalent to an SD card on the same hardware. mmc v4 can go faster
but as you'd expect, the sdhci controller doesn't have an 8 bit bus and
can't run faster than SD speeds.
This proof of concept patch is available here for the curious:
http://intr.overt.org/diff.cgi/diffs/mmcv4.diff
However, turning that into a real mergable patch requires a lot more work;
there is an elaborate dance required to verify that any particular feature
is safe to turn on that includes special commands that spend test patterns
to the card and read them back (to verify 4/8bit suport at the electrical
level!) and a table of current draws at different speeds/bus widths which
have to be confirmed against the specific host controller; I don't have an
example of card that populates this table - my card apparently conforms to
mmc <= v4 power levels at all times, but this is obviously not something
one can presume.
As a tentative first step, this patch simply retrieves and parses the
EXT_CSD structure for v4 cards.
The EXT_CSD is a 512byte block that is transferred as a regular data block
(like the SD SCR). Most of it is unused, so it seems wasteful to cache the
raw block - instead I just pull out the relevant values and store
them explicitly. The EXT_CSD is read using CMD8.
Some fields are writable, but writing is done using a separate command (CMD=6
- not the same as the SD version) as is demonstrated in my proof of
concept patch.
In following changes, which I will develop as time allows, I will use the
EXT_CSD information and the test commands (14 and 19) to properly verify that
high speed and wide bus modes can be activated, and then actually activate them.
This is my first kernel patch in a long time, so I can only hope I get the
format right. Russell, if you have specific preferences on where the many
definitions should live, just let me know - I have merely attempted
to follow the pattern used for the base CSD.
Thanks,
--phil
Signed-off-by: Philip Langdale <philipl@mail.utexas.edu>
---
card.h | 46 +++++++++++++++++++++++
protocol.h | 99 +++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 143 insertions(+), 2 deletions(-)
diff -ur /usr/src/linux/include/linux/mmc/card.h new/include/linux/mmc/card.h
--- /usr/src/linux/include/linux/mmc/card.h 2005-10-30 16:32:45.000000000 -0800
+++ new/include/linux/mmc/card.h 2006-02-12 12:03:17.000000000 -0800
@@ -33,6 +33,48 @@
unsigned int capacity;
};
+struct mmc_ext_csd {
+ unsigned char cmd_set_rev;
+ unsigned char ext_csd_rev;
+ unsigned char csd_structure;
+
+ unsigned char card_type;
+
+ /*
+ * Each power class defines MAX RMS Current
+ * and Max Peak Current in mA.
+ * Each category is of the form:
+ * pwr_cl_<speed/MHz>_<voltage/V>
+ *
+ * Each category encodes the power class for 4
+ * bit transfers in [3:0] and 8 bit transfers
+ * in [7:4]. Use mmc_get_4bit_pwr_cl() and
+ * mmc_get_8bit_pwr_cl() to decode these.
+ */
+ unsigned char pwr_cl_52_195;
+ unsigned char pwr_cl_26_195;
+
+ unsigned char pwr_cl_52_360;
+ unsigned char pwr_cl_26_360;
+
+ /*
+ * Performance classes describe the minimum
+ * transfer speed the card claims to support
+ * for the given bus widths and speeds.
+ */
+ unsigned char min_perf_r_4_26;
+ unsigned char min_perf_w_4_26;
+ unsigned char min_perf_r_8_26_4_52;
+ unsigned char min_perf_w_8_26_4_52;
+ unsigned char min_perf_r_8_52;
+ unsigned char min_perf_w_8_52;
+
+ unsigned char s_cmd_set;
+};
+
+#define mmc_get_4bit_pwr_cl(p) (p & 0x0F)
+#define mmc_get_8bit_pwr_cl(p) (p >> 4)
+
struct sd_scr {
unsigned char sda_vsn;
unsigned char bus_widths;
@@ -56,11 +98,13 @@
#define MMC_STATE_BAD (1<<2) /* unrecognised device */
#define MMC_STATE_SDCARD (1<<3) /* is an SD card */
#define MMC_STATE_READONLY (1<<4) /* card is read-only */
+#define MMC_STATE_HIGHSPEED (1<<5) /* card is in mmc4 highspeed mode */
u32 raw_cid[4]; /* raw card CID */
u32 raw_csd[4]; /* raw card CSD */
u32 raw_scr[2]; /* raw card SCR */
struct mmc_cid cid; /* card identification */
struct mmc_csd csd; /* card specific */
+ struct mmc_ext_csd ext_csd; /* mmc v4 extended card specific */
struct sd_scr scr; /* extra SD information */
};
@@ -69,12 +113,14 @@
#define mmc_card_bad(c) ((c)->state & MMC_STATE_BAD)
#define mmc_card_sd(c) ((c)->state & MMC_STATE_SDCARD)
#define mmc_card_readonly(c) ((c)->state & MMC_STATE_READONLY)
+#define mmc_card_highspeed(c) ((c)->state & MMC_STATE_HIGHSPEED)
#define mmc_card_set_present(c) ((c)->state |= MMC_STATE_PRESENT)
#define mmc_card_set_dead(c) ((c)->state |= MMC_STATE_DEAD)
#define mmc_card_set_bad(c) ((c)->state |= MMC_STATE_BAD)
#define mmc_card_set_sd(c) ((c)->state |= MMC_STATE_SDCARD)
#define mmc_card_set_readonly(c) ((c)->state |= MMC_STATE_READONLY)
+#define mmc_card_set_highspeed(c) ((c)->state |= MMC_STATE_HIGHSPEED)
#define mmc_card_name(c) ((c)->cid.prod_name)
#define mmc_card_id(c) ((c)->dev.bus_id)
diff -ur /usr/src/linux/include/linux/mmc/protocol.h
new/include/linux/mmc/protocol.h
--- /usr/src/linux/include/linux/mmc/protocol.h 2006-01-03
23:48:23.000000000 -0800
+++ new/include/linux/mmc/protocol.h 2006-02-12 12:12:45.000000000 -0800
@@ -33,6 +33,7 @@
#define MMC_SET_RELATIVE_ADDR 3 /* ac [31:16] RCA R1 */
#define MMC_SET_DSR 4 /* bc [31:16] RCA */
#define MMC_SELECT_CARD 7 /* ac [31:16] RCA R1 */
+#define MMC_SEND_EXT_CSD 8 /* adtc R1 */
#define MMC_SEND_CSD 9 /* ac [31:16] RCA R2 */
#define MMC_SEND_CID 10 /* ac [31:16] RCA R2 */
#define MMC_READ_DAT_UNTIL_STOP 11 /* adtc [31:0] dadr R1 */
@@ -229,13 +230,107 @@
#define CSD_STRUCT_VER_1_0 0 /* Valid for system
specification 1.0 - 1.2 */
#define CSD_STRUCT_VER_1_1 1 /* Valid for system
specification 1.4 - 2.2 */
-#define CSD_STRUCT_VER_1_2 2 /* Valid for system
specification 3.1 */
+#define CSD_STRUCT_VER_1_2 2 /* Valid for system
specification 3.1 - 4.1 */
+#define CSD_STRUCT_EXT_CSD 3 /* Version is in
CSD_STRUCTURE in EXT_CSD */
#define CSD_SPEC_VER_0 0 /* Implements system
specification 1.0 - 1.2 */
#define CSD_SPEC_VER_1 1 /* Implements system
specification 1.4 */
#define CSD_SPEC_VER_2 2 /* Implements system
specification 2.0 - 2.2 */
-#define CSD_SPEC_VER_3 3 /* Implements system
specification 3.1 */
+#define CSD_SPEC_VER_3 3 /* Implements system
specification 3.1 - 3.2 - 3.31 */
+#define CSD_SPEC_VER_4 4 /* Implements system
specification 4.0 - 4.1 */
+/*
+ * EXT_CSD fields
+ */
+#define EXT_CSD_BUS_WIDTH 183 /* WO */
+#define EXT_CSD_HS_TIMING 185 /* R/W */
+#define EXT_CSD_POWER_CLASS 187 /* R/W */
+#define EXT_CSD_CMD_SET_REV 189 /* RO */
+#define EXT_CSD_CMD_SET 191 /* R/W */
+#define EXT_CSD_EXT_CSD_REV 192 /* RO */
+#define EXT_CSD_CSD_STRUCTURE 194 /* RO */
+#define EXT_CSD_CARD_TYPE 196 /* RO */
+#define EXT_CSD_PWR_CL_52_195 200 /* RO */
+#define EXT_CSD_PWR_CL_26_195 201 /* RO */
+#define EXT_CSD_PWR_CL_52_360 202 /* RO */
+#define EXT_CSD_PWR_CL_26_360 203 /* RO */
+#define EXT_CSD_MIN_PERF_R_4_26 205 /* RO */
+#define EXT_CSD_MIN_PERF_W_4_26 206 /* RO */
+#define EXT_CSD_MIN_PERF_R_8_26_4_52 207 /* RO */
+#define EXT_CSD_MIN_PERF_W_8_26_4_52 208 /* RO */
+#define EXT_CSD_MIN_PERF_R_8_52 209 /* RO */
+#define EXT_CSD_MIN_PERF_W_8_52 210 /* RO */
+#define EXT_CSD_S_CMD_SET 504 /* RO */
+
+/*
+ * EXT_CSD field definitions
+ */
+
+#define EXT_CSD_BUS_WIDTH_1 0
+#define EXT_CSD_BUS_WIDTH_4 1
+#define EXT_CSD_BUS_WIDTH_8 2
+
+#define EXT_CSD_HS_TIMING_LEGACY 0 /* <= 20MHz */
+#define EXT_CSD_HS_TIMING_FAST 1 /* > 20Mhz */
+
+#define EXT_CSD_CMD_SET_REV_4 0
+
+#define EXT_CSD_CMD_SET_NORMAL (1<<0)
+#define EXT_CSD_CMD_SET_SECURE (1<<1)
+#define EXT_CSD_CMD_SET_CPSECURE (1<<2)
+
+#define EXT_CSD_EXT_CSD_REV_1_0 0
+#define EXT_CSD_EXT_CSD_REV_1_1 1
+
+#define EXT_CSD_CARD_TYPE_26 (1<<0) /* Card can run at 26MHz */
+#define EXT_CSD_CARD_TYPE_52 (1<<1) /* Card can run at 52MHz */
+
+/*
+ * Power classes
+ *
+ * Each class is of the form:
+ * <voltage>_<max RMS current/mA>_<max Peak Current/mA>
+ *
+ */
+#define EXT_CSD_PWR_CL_195_065_130 0
+#define EXT_CSD_PWR_CL_195_070_140 1
+#define EXT_CSD_PWR_CL_195_080_160 2
+#define EXT_CSD_PWR_CL_195_090_180 3
+#define EXT_CSD_PWR_CL_195_100_200 4
+#define EXT_CSD_PWR_CL_195_120_220 5
+#define EXT_CSD_PWR_CL_195_140_240 6
+#define EXT_CSD_PWR_CL_195_160_260 7
+#define EXT_CSD_PWR_CL_195_180_280 8
+#define EXT_CSD_PWR_CL_195_200_300 9
+#define EXT_CSD_PWR_CL_195_250_350 10
+
+#define EXT_CSD_PWR_CL_360_100_200 0
+#define EXT_CSD_PWR_CL_360_120_220 1
+#define EXT_CSD_PWR_CL_360_150_250 2
+#define EXT_CSD_PWR_CL_360_180_280 3
+#define EXT_CSD_PWR_CL_360_200_300 4
+#define EXT_CSD_PWR_CL_360_220_320 5
+#define EXT_CSD_PWR_CL_360_250_350 6
+#define EXT_CSD_PWR_CL_360_300_400 7
+#define EXT_CSD_PWR_CL_360_350_450 8
+#define EXT_CSD_PWR_CL_360_400_500 9
+#define EXT_CSD_PWR_CL_360_450_550 10
+
+#define EXT_CSD_MIN_PERF_CLASS_LEGACY 0x00 /* < 2.4 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_A 0x08 /* 2.4 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_B 0x0A /* 3 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_C 0x0F /* 4.5 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_D 0x14 /* 6 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_E 0x1E /* 9 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_F 0x28 /* 12 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_G 0x32 /* 15 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_H 0x3C /* 18 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_J 0x46 /* 21 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_K 0x50 /* 24 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_M 0x64 /* 30 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_O 0x78 /* 36 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_R 0x8C /* 42 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_T 0xA0 /* 48 MB/s */
/*
* SD bus widths
^ permalink raw reply
* Re: Linux 2.6.17-rc1
From: Hans-Peter Jansen @ 2006-04-08 21:10 UTC (permalink / raw)
To: Ralf Hildebrandt; +Cc: linux-kernel
In-Reply-To: <20060404080529.GM7849@charite.de>
Am Dienstag, 4. April 2006 10:05 schrieb Ralf Hildebrandt:
>
> I added the patch.
>
> [...]
>
> So, no more EIPs, but no conclusive messages either!
Just for the record:
Ralf, if I'm not completely mistaken, EIP just means Extended
Instruction Pointer, which names a single cpu internal register per
core pointing to the next instruction to execute. So better keep it ;-)
Pete
^ permalink raw reply
* Re: [Xenomai-help] Problems using Xenoscope
From: Philippe Gerum @ 2006-04-08 21:10 UTC (permalink / raw)
To: Bernhard Walle; +Cc: xenomai
In-Reply-To: <91clg3-vfp.ln1@domain.hid>
Bernhard Walle wrote:
> Hello,
>
> I have problems using Xenoscope (Xenomai 2.1.0, Xenosim 2.1). The
> simulation works, i.e. text messages are printed on the console. I use
> the example from
> http://www.mail-archive.com/xenomai@xenomai.org.
>
> The problem is that the traces dialog is empty, there are also no items
> in the tree, only
>
> - System
> -RT/Interfaces
>
It's not a bug, it's just that the tracer and some other interface
objects are still missing.
> Debugging with GDB seems to work. I used 6.4 and 5.3. I use Debian
> GNU/Linux 3.1 with gcc 3.x.
>
>
> Regards,
> Bernhard
--
Philippe.
^ permalink raw reply
* man-pages-2.29 is released
From: Michael Kerrisk @ 2006-04-08 21:07 UTC (permalink / raw)
To: linux-kernel; +Cc: michael.kerrisk
In-Reply-To: <5159.1143403544@www006.gmx.net>
Gidday,
I recently released man-pages-2.29, which can be found at the
location in the .sig. A list of some notable changes can be found
further down in this message
*** A request ***
Manual pages for the follwoing system calls are notably absent
from the man-pages set. Contributions would be most welcome.
add_key(2) (new in kernel 2.6.10)
keyctl(2) (new in kernel 2.6.10)
request_key(2) (new in kernel 2.6.10)
See:
Documentation/keys.txt
Documentation/keys-request-key.txt
ioprio_get(2) (new in kernel 2.6.13)
ioprio_set(2) (new in kernel 2.6.13)
See:
Documentation/block/ioprio.txt
restart_syscall(2) (new in kernel 2.6)
kexec_load(2) (new in kernel 2.6.13)
migrate_pages(2) (new in kernel 2.6.16)
See Documentation/vm/page_migration
2.29 Changes
============
Changes in this release that may be of interest to readers
of this list include the following:
New pages
---------
mkdirat.2
mtk
New page describing mkdirat(2), new in 2.6.16.
mknodat.2
mtk
New page describing mknodat(2), new in 2.6.16.
core.5
mtk
New page describing core dump files.
mkfifoat.3
mtk
New page describing mkfifoat(3).
Changes to individual pages
---------------------------
getrlimit.2
mtk
Added BUGS text on 2.6.x handling of RLIMIT_CPU limit
of zero seconds. See
http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2
==========
The man-pages set contains sections 2, 3, 4, 5, and 7 of
the manual pages. These sections describe the following:
2: (Linux) system calls
3: (libc) library functions
4: Devices
5: File formats and protocols
7: Overview pages, conventions, etc.
As far as this list is concerned the most relevant parts are:
all of sections 2 and 4, which describe kernel-userland interfaces;
in section 5, the proc(5) manual page, which attempts (it's always
catching up) to be a comprehensive description of /proc; and
various pages in section 7, some of which are overview pages of
kernel features (e.g., networking protocols).
If you make a change to a kernel-userland interface, or observe
a discrepancy between the manual pages and reality, would you
please send me (at mtk-manpages@gmx.net ) one of the following
(in decreasing order of preference):
1. An in-line "diff -u" patch with text changes for the
corresponding manual page. (The most up-to-date version
of the manual pages can always be found at
ftp://ftp.win.tue.nl/pub/linux-local/manpages or
ftp://ftp.kernel.org/pub/linux/docs/manpages .)
2. Some raw text describing the changes, which I can then
integrate into the appropriate manual page.
3. A message alerting me that some part of the manual pages
does not correspond to reality. Eventually, I will try to
remedy the situation.
Obviously, as we get further down this list, more of my time
is required, and things may go slower, especially when the
changes concern some part of the kernel that I am ignorant
about and I can't find someone to assist.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
^ permalink raw reply
* [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Leonardo E. Reiter @ 2006-04-08 21:06 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44381AE0.1020106@wasp.net.au>
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 ?
>
>
--
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
^ permalink raw reply
* strlen_user and keys
From: Andries.Brouwer @ 2006-04-08 21:06 UTC (permalink / raw)
To: linux-kernel
[faraway from home, not near recent kernel source]
strnlen_user() is documented as returning the string length including
terminating NUL. Probably that was a bad idea - people expect that
if user space and kernel library functions have similar names, they do
similar things. The shouting "INCLUDING" in the description already
shows that also the author expected that bugs would be created by
using this name.
[see, e.g., arch/i386/lib/usercopy.c]
security/keys/keyctl.c does
dlen = strnlen_user(_description, PAGE_SIZE - 1);
description = kmalloc(dlen + 1, GFP_KERNEL);
copy_from_user(description, _description, dlen + 1);
copying one byte too many.
(Thus in some unknown kernel source tree, maybe 2.6.14.
This may have been fixed already.)
Andries
^ permalink raw reply
* Re: [Qemu-devel] -win2k-hack needed to do Windows Update?
From: Brad Campbell @ 2006-04-08 21:05 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <200603262046.25950.andrew.james.barr@gmail.com>
Andrew Barr wrote:
> Hi again. I'm still working on my Windows 2000 SP4 VM, and I've discovered
> that running Windows Update (Internet Explorer 6) causes behavior similar to
> the "disk full" bug encountered during Windows 2000 setup. When it gets to
> the part where it's looking for updates (the green scrolling bar), there is
> excessive disk activity and the VM slows down significantly. This is both
> with and without -kernel-kqemu. I've monitored the size of the disk image
> while the VM thrases away, and it steadily gets larger. I've not let it
> completely fill up, but I've seen it add 2 gigabytes to the disk size in the
> space of fifteen minutes. Just for kicks, I added -win2k-hack to my bootup
> options and tried Windows Update. It's running now--so far so good but the
> disk is working a bit much for my taste. At least it is moving forward,
> albeit a bit slowly. I just thought I'd mention this here because I've not
> seen this behavior documented anywhere else.
I've reproduced this with a vanilla 2kSP4 install (IE 5) and all patches up to the latest and
greatest. I've tried with Leo's win2k-hack patch that only delays every 16th (iirc) irq and that
seems to work also, but perhaps it was not as reliable (I've done so many tests my memory may not be
that flash).
Anyway. -win2k-hack gets windows update working on 2k here also.
--
"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: How to create independent branches
From: Junio C Hamano @ 2006-04-08 21:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060408205747.GT27689@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Wouldn't it be better to separate it to two distinct public repositories
> as well? It's confusing people and encouraging a practice that really
> isn't very feasible and practical in Git.
That's mainly historical. I haven't bothered to check it
recently, but /pub/scm/git was not writable by me on kernel.org
machine, only /pub/scm/git/git.git/ was.
^ permalink raw reply
* Re: How to create independent branches
From: Petr Baudis @ 2006-04-08 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Baumann, git
In-Reply-To: <7vsloneqtb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Apr 08, 2006 at 10:49:04PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Peter Baumann <peter.baumann@gmail.com> writes:
>
> > Another question. I'd like to create a totaly independent branch (like
> > the "todo" branch in git). Is there a more user friendly way than doing
> >
> > git-checkout -b todo
> > rm .git/refs/heads/todo
> > rm .git/index
> > rm <all_files_in_your_workdir>
> >
> > ... hack hack hack ...
> > git-commit -a
> >
> > I looked all over the docs, but can't find anything obvious.
>
> My "todo" branch is not even part of my main git repository. I
> just have two independent repositories (git and todo) locally,
> and push into the same public repository.
Wouldn't it be better to separate it to two distinct public repositories
as well? It's confusing people and encouraging a practice that really
isn't very feasible and practical in Git.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH 1/3] [kernel patch] fixed duration connection
From: Eric Leblond @ 2006-04-08 20:55 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <44381584.4020109@trash.net>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
I followed your recommendation and here's the patch.
Patrick McHardy wrote:
> Eric Leblond wrote:
>
>>Hi,
>>
>>Here's the patch against Linus git tree.
>
>
> I don't have any principle objections against merging this (if
> there are no objections from others), a couple of comments
> on the patch though.
BR and thanks a lot for your help,
- --
Eric Leblond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEOCNKnxA7CdMWjzIRAuVlAJ9v75j2WeEvMAJVqDekgOxzTRmHQwCcDN5B
sdtE712lSkUuG25DMBB9v+w=
=K6vk
-----END PGP SIGNATURE-----
[-- Attachment #2: fixed_timeout-flag.patch --]
[-- Type: text/x-patch, Size: 1942 bytes --]
diff --git a/include/linux/netfilter/nf_conntrack_common.h b/include/linux/netfilter/nf_conntrack_common.h
index 3ff88c8..68d282d 100644
--- a/include/linux/netfilter/nf_conntrack_common.h
+++ b/include/linux/netfilter/nf_conntrack_common.h
@@ -69,6 +69,11 @@ enum ip_conntrack_status {
/* Connection is dying (removed from lists), can not be unset. */
IPS_DYING_BIT = 9,
IPS_DYING = (1 << IPS_DYING_BIT),
+
+ /* Connection has fixed timeout. */
+ IPS_FIXED_TIMEOUT_BIT = 10,
+ IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT),
+
};
/* Connection tracking event bits */
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
index ceaabc1..d9dbe0f 100644
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1130,18 +1130,21 @@ void __ip_ct_refresh_acct(struct ip_conn
write_lock_bh(&ip_conntrack_lock);
- /* If not in hash table, timer will not be active yet */
- if (!is_confirmed(ct)) {
- ct->timeout.expires = extra_jiffies;
- event = IPCT_REFRESH;
- } else {
- /* Need del_timer for race avoidance (may already be dying). */
- if (del_timer(&ct->timeout)) {
- ct->timeout.expires = jiffies + extra_jiffies;
- add_timer(&ct->timeout);
- event = IPCT_REFRESH;
- }
- }
+ /* only update if this is not a fixed timeout */
+ if (! test_bit(IPS_FIXED_TIMEOUT_BIT, &ct->status)){
+ /* If not in hash table, timer will not be active yet */
+ if (!is_confirmed(ct)) {
+ ct->timeout.expires = extra_jiffies;
+ event = IPCT_REFRESH;
+ } else {
+ /* Need del_timer for race avoidance (may already be dying). */
+ if (del_timer(&ct->timeout)) {
+ ct->timeout.expires = jiffies + extra_jiffies;
+ add_timer(&ct->timeout);
+ event = IPCT_REFRESH;
+ }
+ }
+ }
#ifdef CONFIG_IP_NF_CT_ACCT
if (do_acct) {
^ permalink raw reply related
* Re: strange behavior when pulling updates / get uptodate with git.git
From: Junio C Hamano @ 2006-04-08 20:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <4438158C.1080208@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> writes:
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: refs/heads/master:refs/heads/origin
> Pull: refs/heads/todo:refs/heads/todo
> Pull: refs/heads/maint:refs/heads/maint
> Pull: refs/heads/pu:refs/heads/pu
> Pull: refs/heads/man:refs/heads/man
> Pull: refs/heads/next:refs/heads/next
> Pull: refs/heads/html:refs/heads/html
>
> so i suppose, if i try to pull origin, and i am in master, i should be
> able to pull these remote heads each in the correct local head...
>
> But I obviously don't.
Most likely it is aborted by the "pu" branch not
fast-forwarding.
Pull: +refs/heads/pu:refs/heads/pu
or dropping "pu" altogether if you are not interested in it,
would help. My repositories (the ones I fetch/pull from for
testing) have only these:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/next:refs/heads/next
Pull: +refs/heads/pu:refs/heads/pu
Pull: refs/heads/maint:refs/heads/maint
^ permalink raw reply
* [LARTC] iproute v2.6.15 20060110 kernel 2.4.31-gentoo-r1 ip route
From: Andrew Lyon @ 2006-04-08 20:49 UTC (permalink / raw)
To: lartc
I am using policy based routing and I have 3 route tables setup, ADSLLink1,
ADSLLink2, and ADSLLoadBalanced, "ip route show <table>" will show me the
routes that I have added to the first two, but not from ADSLLoadBalanced, it
will show the last route that was added to the table but no others.
There are approx 16 routes added to the table, I know they are there because
they work, I cannot add them again, and I can delete them (but not delete
them again without adding them).
It did work with 4 routes added to the table I seem to recall, but I cannot
test that again as the machine is in use and rather important.
Where does iproute ip read the routes from? Is there a proc entry that I can
read to check if the kernel is exposing them or if the fault lies in
iproute?
Thanks
Andy
Ignore this text, it disables our lame email disclaimer from being appended
to this email: JOSEDV001TAG ;)
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: How to create independent branches
From: Junio C Hamano @ 2006-04-08 20:49 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20060408180244.GA4807@xp.machine.de>
Peter Baumann <peter.baumann@gmail.com> writes:
> Another question. I'd like to create a totaly independent branch (like
> the "todo" branch in git). Is there a more user friendly way than doing
>
> git-checkout -b todo
> rm .git/refs/heads/todo
> rm .git/index
> rm <all_files_in_your_workdir>
>
> ... hack hack hack ...
> git-commit -a
>
> I looked all over the docs, but can't find anything obvious.
My "todo" branch is not even part of my main git repository. I
just have two independent repositories (git and todo) locally,
and push into the same public repository.
^ permalink raw reply
* {PATCH] Audit Filter Performance
From: Steve Grubb @ 2006-04-08 20:46 UTC (permalink / raw)
To: linux-audit, aviro
Hi,
While testing the watch performance, I noticed that selinux_task_ctxid() was
creeping into the results more than it should. Investigation showed that the
function call was being called whether it was needed or not. The below patch
fixes this.
Signed-off-by: Steve Grubb
diff -ur linux-2.6.16.x86_64.orig/kernel/auditsc.c linux-2.6.16.x86_64/kernel/auditsc.c
--- linux-2.6.16.x86_64.orig/kernel/auditsc.c 2006-04-08 16:28:16.000000000 -0400
+++ linux-2.6.16.x86_64/kernel/auditsc.c 2006-04-08 16:33:33.000000000 -0400
@@ -190,9 +190,6 @@
enum audit_state *state)
{
int i, j;
- u32 sid;
-
- selinux_task_ctxid(tsk, &sid);
for (i = 0; i < rule->field_count; i++) {
struct audit_field *f = &rule->fields[i];
@@ -295,11 +292,15 @@
match for now to avoid losing information that
may be wanted. An error message will also be
logged upon error */
- if (f->se_rule)
+ if (f->se_rule) {
+ u32 sid;
+
+ selinux_task_ctxid(tsk, &sid);
result = selinux_audit_rule_match(sid, f->type,
f->op,
f->se_rule,
ctx);
+ }
break;
case AUDIT_ARG0:
case AUDIT_ARG1:
^ permalink raw reply
* Re: blame now knows -S
From: Junio C Hamano @ 2006-04-08 20:39 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Martin Langhoff, git
In-Reply-To: <20060408114240.GA10137@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> There is another possible optimisation with respect to xdiff. Instead
> of producing the diff on the xdiff side and parsing the diff in
> blame.c, we could add another call back which just gets the relevant
> information from the hunk header. I don't know how much we would gain
> from this, but it might be worth a try.
I've tried and then it turned out it did not make much of a
difference.
^ permalink raw reply
* Re: Building a small sparc32 kernel
From: Wolfram Quester @ 2006-04-08 20:38 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20060404151927.GC2358@cassis>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
Hi altogether!
On Sat, Apr 08, 2006 at 04:24:28PM +0200, Ludovic Courtès wrote:
[...snip...]
>
> The machine has two SuperSPARC 390Z50. In your original message you
> mentioned that support for SuperSPARC II was relatively stable, so maybe
> this just means that support for this older SuperSPARC flavor is not yet
> in such a good shape? ;-)
Probably I'm wrong but wasn't there an issue with the 390Z50 not having
cache (in contrast to Z55) an thus not being supported in SMP mode?
With best regards,
Wolfi
>
> Let me know how I can help with this.
>
> Thanks,
> Ludovic.
>
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Serge E. Hallyn @ 2006-04-08 20:28 UTC (permalink / raw)
To: Andi Kleen; +Cc: Serge E. Hallyn, linux-kernel
In-Reply-To: <p73hd549o5u.fsf@bragg.suse.de>
Quoting Andi Kleen (ak@suse.de):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > This patch defines the uts namespace and some manipulators.
> > Adds the uts namespace to task_struct, and initializes a
> > system-wide init namespace which will continue to be used when
> > it makes sense.
>
> So to get this straight - you want to add a new pointer to
> task_struct for each possible virtualized entity?
>
> After you're doing by how many bytes will task_struct be bloated?
> I don't think that's a very good approach because you'll crank
> up the per thread memory overhead which is already far too big
> in Linux. Also it adds cache foot print and generally makes
> things slower.
>
> If anything I would request using a proxy data structure
> that contains all the virtualized namespaces for a set
> of processes. And give each task only has a single pointer
> to one of these.
This is something we've been discussing - whether to use a single
"container" structure pointing to all the namespaces, or put everything
into the task_struct. Using container structs means more cache misses
and refcounting issues, but keeps task_struct smaller as you point out.
The consensus so far has been to start putting things into task_struct
and move if needed. At least the performance numbers show that so far
there is no impact.
iirc container patches have been sent before. Should those be resent,
then, and perhaps this patchset rebased on those?
thanks,
-serge
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Serge E. Hallyn @ 2006-04-08 20:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge E. Hallyn, linux-kernel, Kirill Korotaev, herbert, devel,
sam, xemul, James Morris
In-Reply-To: <m1psjslf1s.fsf@ebiederm.dsl.xmission.com>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > diff --git a/include/asm-i386/elf.h b/include/asm-i386/elf.h
> > index 4153d80..8d455e2 100644
> > --- a/include/asm-i386/elf.h
> > +++ b/include/asm-i386/elf.h
> > @@ -108,7 +108,7 @@ typedef struct user_fxsr_struct elf_fpxr
> > For the moment, we have only optimizations for the Intel generations,
> > but that could change... */
> >
> > -#define ELF_PLATFORM (system_utsname.machine)
> > +#define ELF_PLATFORM (init_utsname()->machine)
> >
> > #ifdef __KERNEL__
> > #define SET_PERSONALITY(ex, ibcs2) do { } while (0)
>
> I think this one needs to be utsname()->machine.
>
> Currently it doesn't matter. But Herbert has expressed
> the desire to make a machine appear like an older one.
Ok.
> > diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
> > index cb8a92f..81db372 100644
...
> > @@ -1479,11 +1479,11 @@ static int __init ip_auto_config_setup(c
> > case 4:
> > if ((dp = strchr(ip, '.'))) {
> > *dp++ = '\0';
> > - strlcpy(system_utsname.domainname, dp,
> > - sizeof(system_utsname.domainname));
> > + strlcpy(init_utsname()->domainname, dp,
> > + sizeof(init_utsname()->domainname));
> > }
> > - strlcpy(system_utsname.nodename, ip,
> > - sizeof(system_utsname.nodename));
> > + strlcpy(init_utsname()->nodename, ip,
> > + sizeof(init_utsname()->nodename));
> > ic_host_name_set = 1;
> > break;
> > case 5:
>
> This also probably makes sense as utsname(). It doesn't
> really matter as this is before init is executed. But logically
> this is a user space or per namespace action.
Right, I was kind of favoring using init_utsname() for anything
__init. But utsname() will of course work just as well there.
> > diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> > index aa8965e..97c8439 100644
> > --- a/net/sunrpc/clnt.c
> > +++ b/net/sunrpc/clnt.c
> > @@ -176,10 +176,10 @@ rpc_new_client(struct rpc_xprt *xprt, ch
> > }
> >
> > /* save the nodename */
> > - clnt->cl_nodelen = strlen(system_utsname.nodename);
> > + clnt->cl_nodelen = strlen(init_utsname()->nodename);
> > if (clnt->cl_nodelen > UNX_MAXNODENAME)
> > clnt->cl_nodelen = UNX_MAXNODENAME;
> > - memcpy(clnt->cl_nodename, system_utsname.nodename, clnt->cl_nodelen);
> > + memcpy(clnt->cl_nodename, init_utsname()->nodename, clnt->cl_nodelen);
> > return clnt;
> >
> > out_no_auth:
>
> Using nodename is practically the definition of something
> that should per namespace I think. Plus it would be really inconsistent
> to use utsname() and the init_utsname for the nfs rpc calls.
>
> Unless I am missing something.
It seemed like this would be happening in any old context, so that
current->uts_ns could be any process'. Tracing it back further,
it seems like nfs+lockd should have the context available. So I'll
switch this as well.
thanks,
-serge
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Al Boldi @ 2006-04-08 20:31 UTC (permalink / raw)
To: Peter Williams; +Cc: linux-kernel
In-Reply-To: <443711EC.7070003@bigpond.net.au>
Peter Williams wrote:
> Al Boldi wrote:
> > Can you try the attached mem-eater passing it the number of kb to be
> > eaten.
> >
> > i.e. '# while :; do ./eatm 9999 ; done'
> >
> > This will print the number of bytes eaten and the timing in ms.
> >
> > Adjust the number of kb to be eaten such that the timing will be less
> > than timeslice (120ms by default for spa). Switch to another vt and
> > start pressing enter. A console lockup should follow within seconds for
> > all spas except ebs.
>
> This doesn't seem to present a problem (other than the eatme loop being
> hard to kill with control-C) on my system using spa_ws with standard
> settings. I tried both UP and SMP. I may be doing something wrong or
> perhaps don't understand what you mean by a console lock up.
Switching from one vt to another receives hardly any response.
This is especially visible in spa_no_frills, and spa_ws recovers from this
lockup somewhat and starts exhibiting this problem as a choking behavior.
Running '# top d.1 (then shift T)' on another vt shows this choking behavior
as the proc gets boosted.
> When you say "less than the timeslice" how much smaller do you mean?
This depends on your machine's performance. On my 400MhzP2 UP 128MB, w/
spa_no_frills default settings, looping eatm 9999 takes 63ms per eat and
causes the rest of the system to be starved. Raising kb to 19999 takes
126ms which is greater than the default 120ms timeslice and causes no system
starvation.
What numbers do you get?
Thanks!
--
Al
^ permalink raw reply
* Re: [LARTC] source routing does not work with extra ip addresses
From: Martin A. Brown @ 2006-04-08 20:31 UTC (permalink / raw)
To: lartc
In-Reply-To: <20060408123017.4a108613.mailinglists@lucassen.org>
Hello again,
: > Does server have one or two IP addresses? Best solution? Use two
: > IP addresses on server.
:
: Hmmm, one for ISP1 and one for ISP2? That would be a nice idea to
: workaround this problem :-)
Only way I have done this myself, although I recall somebody else on
LARTC using connmark with nfmark and/or the ROUTE target to solve
this problem using only a single IP. Perhaps the archive will help
you here....
: > Try changing this (or adding another rule):
: >
: > ip rule add from 10.0.0.2 lookup table_eth1
:
: Nope. I already tried that, but no way.
: No. The packets are returned through ISP1.
:
: > If you would like to handle inbound traffic on both links, then add
: > a secondary IP address to your server, and enter another DNAT rule
: > which specifies another NAT mapping for the secondary IP.
:
: That's a very nice idea, but packets keep on entering the wrong
: table (default), I think it's a bug somewhere in the kernel.
While the kernel certainly has seen bugs before and will see more, I
hope you don't mind if I continue to entertain a bit of skepticism
on this point. :)
: It only works when the ip is direct on the external interface of
: the Linuxbox, but as soon as 1 tcp port is translated, the return
: packets for that translated port get into the wrong (default)
: table.
:
: Even when using fw marks it doesn't work. I mark all packets coming
: from the servers second ip address with '1' and a simple
:
: ip ru a fwmark 1 table t_eth1
:
: should do the job. But no way. Packets keep on getting out
: through ISP1 (t_eth0).
:
: This is the real test:
:
: 10.0.2.1 is the server, 10.0.2.3 is its second ip.
: 10.0.2.1 = external 10.1.3.100
: 10.0.2.3 = external 192.168.201.3
OK, got it!
: # ip r s
: 192.168.201.3 via 10.0.2.3 dev eth2
: 10.1.3.100 via 10.0.2.1 dev eth2
[ snipped main and ancillary routing tables except for unusual and
possibly extraneous routes. ]
Routing tables t_eth0 and t_eth1 look fine, although t_eth0 and main
should be exactly the same. I believe your two host routes (for
192.168.201.3 and 10.1.3.100) are unnecessary and simply complicate
your scenario.
I still think your problem is in the RPDB and addressing of the
packet at routing time. I do not believe (check the KPTD and its
offspring [0] [1]) that the packet's source address has yet been
rewritten. Think about this, and look at your RPDB:
: # ip ru s
: 0: from all lookup local
: 32762: from all fwmark 0x1 lookup t_eth1
: 32764: from 192.168.201.2 lookup t_eth1
: 32765: from 10.1.3.101 lookup t_eth0
: 32766: from all lookup main
: 32767: from all lookup default
The addresses you have entered are the public side addresses. When
the server transmits packets, these packets will have the 10.0.2.1
and 10.0.2.3 addresses for source addresses. The RPDB should
include references to these private addresses instead of the
addresses available on the public side.
: btw: iproute2-ss06011, kernel 2.6.16.2, iptables 1.3.5
I hope this helps, and thanks for the detailed listing of your
configuration. It's always helpful.
Best of luck,
-Martin
[0] http://www.docum.org/docum.org/kptd/
[1] http://linux-ip.net/nf/nfk-traversal.eps
http://linux-ip.net/nf/nfk-traversal.png
--
Martin A. Brown --- Wonderfrog Enterprises --- martin@wonderfrog.net
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ 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.