* ipset command ipporthash anormal behavior
From: Clist @ 2006-04-04 12:46 UTC (permalink / raw)
To: netfilter
Hi
I have ipsets 2.2.8
All commands using iphash run fine but, all comands from other sets return
error, (ipporthas, nethash etc..)
Example:
The set clients does not exist, so it is ok to create one,
Shell Command:
ipset -N clients ipporthash --from 192.168.153.206 --to 192.168.153.207
--hashsize 1024 --probes 4 --resize 50 || echo "failure .."
it prints :
"failure .."
But the set got created!!.
This is confusing and make my script run bad, if the commnad ran sucessfully,
Why it returns error code !=0 to the OS??
--
---------------------------------------------
Clister UAH
---------------------------------------------
^ permalink raw reply
* Re: [PATCH] ahci: do not fail softreset if PHY reports no device
From: Jeff Garzik @ 2006-04-04 12:44 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide@vger.kernel.org
In-Reply-To: <20060402165806.GO13172@htj.dyndns.org>
Tejun Heo wrote:
> All softreset methods are responsible for detecting device presence
> and succeed softreset in such cases. AHCI didn't use to check for
> device presence before proceeding with softreset and this caused
> unnecessary reset retrials during probing. This patch adds presence
> detection to AHCI softreset.
>
> Signed-off-by: Tejun Heo <htejun@gmail.com>
>
> ---
>
> This makes AHCI act like all other softresets and new EH already
> handles false successes properly. So, I think this should do the
> trick.
applied
^ permalink raw reply
* Re: [PATCH] libata: convert ATAPI_ENABLE_DMADIR to module parameter
From: Jeff Garzik @ 2006-04-04 12:44 UTC (permalink / raw)
To: albertl; +Cc: Tejun Heo, Jonathan Blake Benson, linux-ide, Doug Maxey
In-Reply-To: <4431E08E.8040108@tw.ibm.com>
Albert Lee wrote:
> Convert the ATAPI_ENABLE_DMADIR compile time option needed
> by some SATA-PATA bridge to runtime module parameter.
>
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
> Before we can detect the bridge chips which need the ATAPI DMADIR workaround
> automatically, maybe using a module parameter is easier for the end users to
> turn on this option.
agreed, applied
^ permalink raw reply
* Re: [parisc-linux] 2.6.17-rc1-pa0 attempt to build for 64bit ;-)
From: Matthew Wilcox @ 2006-04-04 12:44 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
In-Reply-To: <IX76T0$9C06EC779069A908914854C520DF80D1@scarlet.be>
On Tue, Apr 04, 2006 at 01:31:48PM +0100, Joel Soete wrote:
> Matthew,
>
> Very sorry but as I haven't any more access to cvs (i can just grab snapshot
> ;-( ), so I missed your patch.
But you asked about it yesterday, and I told you the patch was already
committed. Helge comimtted a -pa1 bump, so the -pa1 snapshot won't have
this problem.
In general, the -pa0 snapshot has *not* been built for any config, is
generally untested, and isn't worth wasting any time on.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: 2.6.17-rc1: collie -- oopsen in pccardd?
From: Russell King @ 2006-04-04 12:43 UTC (permalink / raw)
To: Pavel Machek; +Cc: rpurdie, lenz, kernel list
In-Reply-To: <20060404122212.GG19139@elf.ucw.cz>
On Tue, Apr 04, 2006 at 02:22:12PM +0200, Pavel Machek wrote:
> I'm getting some oopses when inserting/removing pccard (on collie,
> oopses in pccardd). It does not break boot, so it is not immediate
> problem, but I wonder if it also happens on non-collie machines?
No idea what so ever. Not even any clues as to what might be going wrong
due to the lack of oops dump. (Not that I even look after PCMCIA anymore.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [PATCH] fix mfn check of gnttab_transfer()
From: Keir Fraser @ 2006-04-04 12:43 UTC (permalink / raw)
To: Isaku Yamahata; +Cc: Xen-devel
In-Reply-To: <20060404110652.GD25732%yamahata@valinux.co.jp>
On 4 Apr 2006, at 12:06, Isaku Yamahata wrote:
> fix mfn check of gnttab_transfer().
What's wrong with the mfn check? mfn_valid() will return false for
INVALID_MFN so there's no need to check for it explicitly.
-- Keir
^ permalink raw reply
* Re: [PATCH] libata-dev: irq-pio minor fix
From: Jeff Garzik @ 2006-04-04 12:42 UTC (permalink / raw)
To: albertl; +Cc: Tejun Heo, alan, linux-ide
In-Reply-To: <4430EE3C.9050608@tw.ibm.com>
Albert Lee wrote:
> irq-pio minor fix:
> - remove the redundant hsm_task_state = HSM_ST_IDLE
> - add devno to printk() as done in upstream
>
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
applied both minor-fix patches
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Use rtas query-cpu-stopped-state in smp spinup
From: Anton Blanchard @ 2006-04-04 12:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20060404112459.C9170679EB@ozlabs.org>
Hi,
> Currently we use a cpumask called of_spin_map to keep track of which threads
> have been spun up. We basically guess that OF has spun up all even numbered
> threads, and so all the odd numbered threads need to be brought up.
>
> That's a bit of a dicey assumption at best, and is totally incorrect for
> kexec. Luckily we have an rtas call which can tell us whether a cpu is up
> or not, so let's use it?
I have a bad feeling its broken on some older (POWER3) machines.
Anton
^ permalink raw reply
* Re: xm info showing too much free ram
From: Keir Fraser @ 2006-04-04 12:41 UTC (permalink / raw)
To: Hans-Christian Armingeon; +Cc: xen-devel, Ewan Mellor
In-Reply-To: <200604041244.39536.johnny@wh-netz.de>
On 4 Apr 2006, at 11:44, Hans-Christian Armingeon wrote:
> Hello Keir,
>
> is it difficult to fix that?
>
> Maybe this is only a two liner.
I'm not sure. I doubt anyone's going to look at it right now so the
best thing is to open a bug report so that the issue can be tracked.
-- Keir
^ permalink raw reply
* Re: [Bluez-devel] how to compile and install bluez
From: Mayank Batra @ 2006-04-04 12:37 UTC (permalink / raw)
To: bluez-devel
In-Reply-To: <BAY112-F8C1E5AD573AAD1E9BC73FA5CA0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]
Jose,
Try the fol links
http://www.homewirelessconnection.com/bluez.php
http://www.fuschlberger.net/bluetooth/
And by the way are you using the Video Distribution Profile for streaming
the video?
If yes which codec are you using?
Mayank
On 4/4/06, Jose Antonio Rodríguez Pérez <jarodri30@hotmail.com> wrote:
>
> Hello,
>
> i'm doing a project for my university that consist in transmit video
> streaming between two PDAs with bluetooth. For making this i have to change
> some parameters from the bluez souce code, but i don't know how to compile
> and install it, when i do the instructions of the README text file, gcc
> never found the bluetooth/bluetooth.h, and never is comipiled ok.
>
> Can anyone send me a list of steps about how to compile and install it
> correctly.
>
> Thanks for all
> ------------------------------------------------------- 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_______________________________________________ Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
[-- Attachment #2: Type: text/html, Size: 2405 bytes --]
^ permalink raw reply
* Re: It seems I've found why conntrack blocks some packets
From: Carlos Pastorino @ 2006-04-04 12:36 UTC (permalink / raw)
To: Steven M Campbell; +Cc: netfilter
In-Reply-To: <442F4E53.9060501@SCampbell.net>
Hi Steven,
> To see how many you are using at a given moment
>
> # wc -l /proc/net/ip_conntrack
> 16 /proc/net/ip_conntrack
I checked the conntrack table. I setup a cron job to look at it every
minute, for 24 hours. You'll be surprised: the top number, around peak
time, is:
255 /proc/net/ip_conntrack
So, it can't be the limit on the conntrack table.
I've found another clue though. When I first configured this firewall,
I enabled rp_filter, with the command below:
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
And I've found this text on the Internet about it:
"If instead you decide to enable forwarding, you will also be able to
modify the rp_filter setting; something which is often misunderstood
by network administrators. The rp_filter can reject incoming packets
if their source address doesn't match the network interface that
they're arriving on, which helps to prevent IP spoofing. Turning this
on, however, has its consequences: If your host has several IP
addresses on different interfaces, or if your single interface has
multiple IP addresses on it, you'll find that your kernel may end up
rejecting valid traffic. It's also important to note that even if you
do not enable the rp_filter, protection against broadcast spoofing is
always on. Also, the protection it provides is only against spoofed
internal addresses; external addresses can still be spoofed.. By
default, it is disabled."
And that's what's been happening: The firewall has been rejecting a
few valid packets.
I'll disable it and see what happens, and then I'll let you know.
By the way, do you keep rp_filter enabled or disabled?
^ permalink raw reply
* [PATCH] Solaris needs strings.h when using index().
From: Peter Eriksen @ 2006-04-04 12:36 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Tue Apr 4 14:33:14 2006 +0200
Subject: [PATCH] Solaris needs strings.h when using index().
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
832067e6e16ae6c1ac3bd043ddeb56daa993e682
diff --git a/blame.c b/blame.c
index 396defc..1a08434 100644
--- a/blame.c
+++ b/blame.c
@@ -6,6 +6,7 @@ #include <assert.h>
#include <time.h>
#include <sys/time.h>
#include <math.h>
+#include <strings.h>
#include "cache.h"
#include "refs.h"
--
1.3.0.rc1.gfc99-dirty
^ permalink raw reply related
* Re: [linux-lvm] Shrinking what part of a PV a VG uses, Is it possible?
From: gwood @ 2006-04-04 12:35 UTC (permalink / raw)
To: sverre, LVM general discussion and development
In-Reply-To: <44326388.90001@tiscali.nl>
On Tue, Apr 04, 2006 at 02:16:08PM +0200, Sverre Rabbelier wrote:
> My first choice would be to partition a part of the VG as
> Windows-readable, but I didn't think that's possible (if it is, please
> tell me!).
You might want to look at 'explore2fs'.
http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm
It claims to support LVM, and will give windows sort of access to the
data - it can't treat it as a normal drive, but you get an explorer type
front end to it
^ permalink raw reply
* [PATCH] http-fetch: add optional DAV-based pack list
From: Nick Hengeveld @ 2006-04-04 12:33 UTC (permalink / raw)
To: git
If git is not built with NO_EXPAT, this patch changes git-http-fetch to
attempt using DAV to get a list of remote packs and fall back to using
objects/info/packs if the DAV request fails.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Makefile | 7 +
http-fetch.c | 278 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 284 insertions(+), 1 deletions(-)
9aef9577cabbd96de20562902d2958108616a7e4
diff --git a/Makefile b/Makefile
index c79d646..19ce42c 100644
--- a/Makefile
+++ b/Makefile
@@ -510,6 +510,11 @@ git$X git.spec \
exec_cmd.o: exec_cmd.c
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+ifdef NO_EXPAT
+http-fetch.o: http-fetch.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
+endif
+
git-%$X: %.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
@@ -532,7 +537,7 @@ git-imap-send$X: imap-send.o $(LIB_FILE)
git-http-fetch$X: fetch.o http.o http-fetch.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIBS) $(CURL_LIBCURL)
+ $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
git-http-push$X: revision.o http.o http-push.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
diff --git a/http-fetch.c b/http-fetch.c
index dc67218..71a7daf 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -4,6 +4,35 @@ #include "pack.h"
#include "fetch.h"
#include "http.h"
+#ifndef NO_EXPAT
+#include <expat.h>
+
+/* Definitions for DAV requests */
+#define DAV_PROPFIND "PROPFIND"
+#define DAV_PROPFIND_RESP ".multistatus.response"
+#define DAV_PROPFIND_NAME ".multistatus.response.href"
+#define DAV_PROPFIND_COLLECTION ".multistatus.response.propstat.prop.resourcetype.collection"
+#define PROPFIND_ALL_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:propfind xmlns:D=\"DAV:\">\n<D:allprop/>\n</D:propfind>"
+
+/* Definitions for processing XML DAV responses */
+#ifndef XML_STATUS_OK
+enum XML_Status {
+ XML_STATUS_OK = 1,
+ XML_STATUS_ERROR = 0
+};
+#define XML_STATUS_OK 1
+#define XML_STATUS_ERROR 0
+#endif
+
+/* Flags that control remote_ls processing */
+#define PROCESS_FILES (1u << 0)
+#define PROCESS_DIRS (1u << 1)
+#define RECURSIVE (1u << 2)
+
+/* Flags that remote_ls passes to callback functions */
+#define IS_DIR (1u << 0)
+#endif
+
#define PREV_BUF_SIZE 4096
#define RANGE_HEADER_SIZE 30
@@ -15,6 +44,7 @@ static struct curl_slist *no_pragma_head
struct alt_base
{
char *base;
+ int path_len;
int got_indices;
struct packed_git *packs;
struct alt_base *next;
@@ -56,8 +86,32 @@ struct alternates_request {
struct buffer *buffer;
struct active_request_slot *slot;
int http_specific;
+};
+
+#ifndef NO_EXPAT
+struct xml_ctx
+{
+ char *name;
+ int len;
+ char *cdata;
+ void (*userFunc)(struct xml_ctx *ctx, int tag_closed);
+ void *userData;
};
+struct remote_ls_ctx
+{
+ struct alt_base *repo;
+ char *path;
+ void (*userFunc)(struct remote_ls_ctx *ls);
+ void *userData;
+ int flags;
+ char *dentry_name;
+ int dentry_flags;
+ int rc;
+ struct remote_ls_ctx *parent;
+};
+#endif
+
static struct object_request *object_queue_head = NULL;
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
@@ -500,6 +554,7 @@ static void process_alternates_response(
int serverlen = 0;
struct alt_base *newalt;
char *target = NULL;
+ char *path;
if (data[i] == '/') {
serverlen = strchr(base + 8, '/') - base;
okay = 1;
@@ -540,6 +595,13 @@ static void process_alternates_response(
newalt->base = target;
newalt->got_indices = 0;
newalt->packs = NULL;
+ path = strstr(target, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ newalt->path_len = strlen(path);
+ }
+
while (tail->next != NULL)
tail = tail->next;
tail->next = newalt;
@@ -608,9 +670,212 @@ #endif
got_alternates = -1;
free(data);
+ free(url);
+}
+
+#ifndef NO_EXPAT
+static void
+xml_start_tag(void *userData, const char *name, const char **atts)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ int new_len;
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ new_len = strlen(ctx->name) + strlen(c) + 2;
+
+ if (new_len > ctx->len) {
+ ctx->name = xrealloc(ctx->name, new_len);
+ ctx->len = new_len;
+ }
+ strcat(ctx->name, ".");
+ strcat(ctx->name, c);
+
+ if (ctx->cdata) {
+ free(ctx->cdata);
+ ctx->cdata = NULL;
+ }
+
+ ctx->userFunc(ctx, 0);
+}
+
+static void
+xml_end_tag(void *userData, const char *name)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ char *ep;
+
+ ctx->userFunc(ctx, 1);
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ ep = ctx->name + strlen(ctx->name) - strlen(c) - 1;
+ *ep = 0;
+}
+
+static void
+xml_cdata(void *userData, const XML_Char *s, int len)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ if (ctx->cdata)
+ free(ctx->cdata);
+ ctx->cdata = xcalloc(len+1, 1);
+ strncpy(ctx->cdata, s, len);
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData);
+
+static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
+{
+ struct remote_ls_ctx *ls = (struct remote_ls_ctx *)ctx->userData;
+
+ if (tag_closed) {
+ if (!strcmp(ctx->name, DAV_PROPFIND_RESP) && ls->dentry_name) {
+ if (ls->dentry_flags & IS_DIR) {
+ if (ls->flags & PROCESS_DIRS) {
+ ls->userFunc(ls);
+ }
+ if (strcmp(ls->dentry_name, ls->path) &&
+ ls->flags & RECURSIVE) {
+ ls->rc = remote_ls(ls->repo,
+ ls->dentry_name,
+ ls->flags,
+ ls->userFunc,
+ ls->userData);
+ }
+ } else if (ls->flags & PROCESS_FILES) {
+ ls->userFunc(ls);
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
+ ls->dentry_name = xmalloc(strlen(ctx->cdata) -
+ ls->repo->path_len + 1);
+ strcpy(ls->dentry_name, ctx->cdata + ls->repo->path_len);
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
+ ls->dentry_flags |= IS_DIR;
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_RESP)) {
+ if (ls->dentry_name) {
+ free(ls->dentry_name);
+ }
+ ls->dentry_name = NULL;
+ ls->dentry_flags = 0;
+ }
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData)
+{
+ char *url = xmalloc(strlen(repo->base) + strlen(path) + 1);
+ struct active_request_slot *slot;
+ struct slot_results results;
+ struct buffer in_buffer;
+ struct buffer out_buffer;
+ char *in_data;
+ char *out_data;
+ XML_Parser parser = XML_ParserCreate(NULL);
+ enum XML_Status result;
+ struct curl_slist *dav_headers = NULL;
+ struct xml_ctx ctx;
+ struct remote_ls_ctx ls;
+
+ ls.flags = flags;
+ ls.repo = repo;
+ ls.path = strdup(path);
+ ls.dentry_name = NULL;
+ ls.dentry_flags = 0;
+ ls.userData = userData;
+ ls.userFunc = userFunc;
+ ls.rc = 0;
+
+ sprintf(url, "%s%s", repo->base, path);
+
+ out_buffer.size = strlen(PROPFIND_ALL_REQUEST);
+ out_data = xmalloc(out_buffer.size + 1);
+ snprintf(out_data, out_buffer.size + 1, PROPFIND_ALL_REQUEST);
+ out_buffer.posn = 0;
+ out_buffer.buffer = out_data;
+
+ in_buffer.size = 4096;
+ in_data = xmalloc(in_buffer.size);
+ in_buffer.posn = 0;
+ in_buffer.buffer = in_data;
+
+ dav_headers = curl_slist_append(dav_headers, "Depth: 1");
+ dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
+
+ slot = get_active_slot();
+ slot->results = &results;
+ curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.size);
+ curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
+
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (results.curl_result == CURLE_OK) {
+ ctx.name = xcalloc(10, 1);
+ ctx.len = 0;
+ ctx.cdata = NULL;
+ ctx.userFunc = handle_remote_ls_ctx;
+ ctx.userData = &ls;
+ XML_SetUserData(parser, &ctx);
+ XML_SetElementHandler(parser, xml_start_tag,
+ xml_end_tag);
+ XML_SetCharacterDataHandler(parser, xml_cdata);
+ result = XML_Parse(parser, in_buffer.buffer,
+ in_buffer.posn, 1);
+ free(ctx.name);
+
+ if (result != XML_STATUS_OK) {
+ ls.rc = error("XML error: %s",
+ XML_ErrorString(
+ XML_GetErrorCode(parser)));
+ }
+ } else {
+ ls.rc = -1;
+ }
+ } else {
+ ls.rc = error("Unable to start PROPFIND request");
+ }
+
+ free(ls.path);
free(url);
+ free(out_data);
+ free(in_buffer.buffer);
+ curl_slist_free_all(dav_headers);
+
+ return ls.rc;
}
+static void process_ls_pack(struct remote_ls_ctx *ls)
+{
+ unsigned char sha1[20];
+
+ if (strlen(ls->dentry_name) == 63 &&
+ !strncmp(ls->dentry_name, "objects/pack/pack-", 18) &&
+ !strncmp(ls->dentry_name+58, ".pack", 5)) {
+ get_sha1_hex(ls->dentry_name + 18, sha1);
+ setup_index(ls->repo, sha1);
+ }
+}
+#endif
+
static int fetch_indices(struct alt_base *repo)
{
unsigned char sha1[20];
@@ -632,6 +897,12 @@ static int fetch_indices(struct alt_base
if (get_verbosely)
fprintf(stderr, "Getting pack list for %s\n", repo->base);
+
+#ifndef NO_EXPAT
+ if (remote_ls(repo, "objects/pack/", PROCESS_FILES,
+ process_ls_pack, NULL) == 0)
+ return 0;
+#endif
url = xmalloc(strlen(repo->base) + 21);
sprintf(url, "%s/objects/info/packs", repo->base);
@@ -947,6 +1218,7 @@ int main(int argc, char **argv)
{
char *commit_id;
char *url;
+ char *path;
int arg = 1;
int rc = 0;
@@ -987,6 +1259,12 @@ int main(int argc, char **argv)
alt->got_indices = 0;
alt->packs = NULL;
alt->next = NULL;
+ path = strstr(url, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ alt->path_len = strlen(path);
+ }
if (pull(commit_id))
rc = 1;
--
1.3.0.rc1.gd4df-dirty
^ permalink raw reply related
* Re: Fw: [KJ][Patch] fix kbuild warning in pm2fb.o
From: Antonino A. Daplas @ 2006-04-04 12:30 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: Darren Jenkins
In-Reply-To: <20060403203515.4204b459.akpm@osdl.org>
Andrew Morton wrote:
> Maybe pm2fb_set_par() should be __devinit?
No, Darren's patch is correct.
Tony
-------------------------------------------------------
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
^ permalink raw reply
* Re: IDE CMD 64x PCI driver
From: Komuro @ 2006-04-04 12:30 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1143848776.16133.0.camel@localhost.localdomain>
Hello,
> >
> > >I am having difficultly getting the IDE CMD 64x PCI driver to work for the
> > >CMD PCI-648 device. I have decided to dig through kernel and driver code
> > >to find out why and hopefully correct the problem.
> >
> >
> >
> > It seems nobody maintains the CMD64x driver.
>
> I've been working on CMD648 support for the libata PATA set. I don't
> have a CMD648 so testers would be most welcome.
Thanks for your information.
Best Regards
Komuro
^ permalink raw reply
* 2.6.17-rc1: collie -- oopsen in pccardd?
From: Pavel Machek @ 2006-04-04 12:22 UTC (permalink / raw)
To: rpurdie, lenz, kernel list, Russell King
Hi!
I'm getting some oopses when inserting/removing pccard (on collie,
oopses in pccardd). It does not break boot, so it is not immediate
problem, but I wonder if it also happens on non-collie machines?
Pavel
--
Picture of sleeping (Linux) penguin wanted...
^ permalink raw reply
* [Qemu-devel] VLAN inside qemu
From: octane indice @ 2006-04-04 12:15 UTC (permalink / raw)
To: qemu-devel
Hello,
I'm trying to experiment VLAN networking with qemu but the doc doesn't help
me at all.
I want to setup a LAN composed by qemu host, each guest communicating
with each other.
It's for testing etherboot.
I want to have a host e.g. 172.16.12.1 acting as a DHCP/TFTP/nfs server
and several clients (at least 2) connecting with it.
What could be the command line to launch these qemu? Is tun/tap
unavoidable?
Thanks
"Ce Caillou-là" un conte en téléchargement gratuit sur http://www.Manuscrit.com
^ permalink raw reply
* [linux-lvm] Shrinking what part of a PV a VG uses, Is it possible?
From: Sverre Rabbelier @ 2006-04-04 12:16 UTC (permalink / raw)
To: linux-lvm
Heya,
I've got two Harddisks, a 250GB (hdb) and a 120GB (hda).
HDB is fully in use by only one VG (unknowingly named "lvg").
Which consists of threre LV, being:
lvm> lvscan
ACTIVE '/dev/lvg/root' [117.19 GB] inherit
ACTIVE '/dev/lvg/home' [78.12 GB] inherit
ACTIVE '/dev/lvg/swap' [4.06 GB] inherit
Also, it's not fully in use (the VG):
lvm> vgs
VG #PV #LV #SN Attr VSize VFree
lvg 1 3 0 wz--n 233.66G 34.28G
The trouble is, that on hda I have a Windows XP installation.. (you know
what's going to be next right?).
Indeed, I want to have the data on hdb (or at least, some 20GB of it) to
be readable by Windows.
I know of only one way to do that, which would be to format a part of
hdb as FAT, which is OK by me.
Point being, all of hdb is LVG partitioned, so how am I going to format
any of it as FAT?
My first choice would be to partition a part of the VG as
Windows-readable, but I didn't think that's possible (if it is, please
tell me!).
My second choice would be to shrink the VG 'lvg', making it not use all
of the disk, and partition the remainder (the 34.28G), as FAT.
But when reading the help files, I ran into:
lvm> help pvresize
pvresize: Resize a physical volume in use by a volume group
Not implemented. Use pvcreate options.
But reading 'info pvcreate' didn't point me in the right direction... at
all!
My last option would be to remove LVM from hdb, but I have no idea how
to do that without losing all my data...
So my question is, how do I achieve my goal? How do I get Windows to be
able to read some (or all?!) of hdb?
Thanks in advance,
Sverre Rabbelier.
^ permalink raw reply
* Re: [PATCH] tx49_blast_icache32_page_indexed fix
From: Ralf Baechle @ 2006-04-04 12:22 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20060404.173414.108982133.nemoto@toshiba-tops.co.jp>
On Tue, Apr 04, 2006 at 05:34:14PM +0900, Atsushi Nemoto wrote:
> Fix an index value in tx49_blast_icache32_page_indexed().
> This is a damage by 13acfa3fdef15edaa4f5444c68e28e05978afa08 commit.
Applied on master and linux-2.6.16-stable.
Ralf
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 12:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060404100035.GM27689@pasky.or.cz>
On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:
> Well, what is the actual advantage of DAV compared to
> git-update-server-info? Why would I prefer enabling DAV?
In theory, things should work the same either way. It seems that in
practice though, the server info files continue to surface as a source
of fetch problems.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: build error about current git
From: Ralf Baechle @ 2006-04-04 12:22 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20060404204847.6244de31.yoichi_yuasa@tripeaks.co.jp>
On Tue, Apr 04, 2006 at 08:48:47PM +0900, Yoichi Yuasa wrote:
> ROCKHOPPER, TB0226 and TB0287 are only base board(CPU is not included in these boards).
> These configs don't need "select SYS_HAS_CPU_VR41XX" and "select SYS_SUPPORTS_32BIT_KERNEL".
All right, applied.
Ralf
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Benjamin Herrenschmidt @ 2006-04-04 12:05 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, paulus
In-Reply-To: <44316705.1040202@us.ibm.com>
> Basically, kexec-tools looks the platform property to determine whether
> to read tce-base, tce-size and htab-* properties. The attached patch
> find out the platform info based on /proc/device-tree/chosen/htab-base
> property. Not tested yet.
You should just test if the properties exist ...
> Kumar, kexec-tools completely depends on device-tree. Not sure whether
> the embedded system exports the device-tree.
With arch=powerpc, they do
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Benjamin Herrenschmidt @ 2006-04-04 12:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <1078253E-4B9E-4432-86E3-82B01A4B68D1@kernel.crashing.org>
> uugh, can we make kexec not depend on something that embedded systems
> would also have.
Embedded systems will have hypertas ? ugh ..
Ben.
^ permalink raw reply
* Re: [parisc-linux] Strange newest LAB msg?
From: James Bottomley @ 2006-04-04 12:05 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux, Helge Deller
In-Reply-To: <20060403012831.GB12037@colo.lackof.org>
On Sun, 2006-04-02 at 19:28 -0600, Grant Grundler wrote:
> Unfortunately not. Not unless you want to disable IO Port space access.
> Each PCI bus controller routes 64MB of GMMIO space to 64KB of IO port space.
> The first 4 bytes of each page maps to a unique 4 byte in IO Port space.
>
> On Astro platforms, we can use 64KB in LMMIO space to access
> IO Port space for all busses. The difference is Astro only
> has one SBA and IOC. N-class has two. There's more to this
> and I'm not sure of all the details at the moment.
>
> 240MB is clearly not going to be enough on that machine.
> Even on a "normal" machine, a couple of graphics cards
> would exhaust the 240MB. A single infiniband card could
> exhaust the 240MB space we have now.
OK, could someone explain what we're trying to do and why?
The original PA implementation of ioremap actually had I/O space and
memory space separated (this is almost essential on 32 bit machines with
lots of memory).
The new implementation is trying to map our I/O space directly into
memory. Because of the way PA is implemented: no highmem, entire memory
offset mapped at 0x1000000; that means the only space we have for kernel
VM is 0-0x10000000 (On 32 bits, this offset mapping loses us the top
256k on 4GB machines, but that's f space anyway). However, our vmalloc
space is very squeezed at 240k (remember, all modules have to be in
vmalloc space), so trying to share it with I/O mappings looks to be a
bit of a non-starter.
I suggest that on 32 bits, we really shouldn't alter the current scheme
(i.e. keep the separated I/O and memory mappings). On 64 bits, we
could allocate a far different VM range to vmalloc (somewhere up beyond
the maximum possible physical memory) and thus make it far bigger, which
would allow us to keep a mapped ioremap implementation.
Oh, and just before anyone suggests it, we'd have incredible difficulty
moving __PAGE_OFFSET because of the absolute<->virtual equivalence
requirements.
James
^ 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.