* Re: [Qemu-devel] Translation cache sizes
From: Johannes Schindelin @ 2006-04-08 10:27 UTC (permalink / raw)
To: a_mulyadi, qemu-devel
In-Reply-To: <200604081330.28503.a_mulyadi@softhome.net>
Hi,
On Sat, 8 Apr 2006, Mulyadi Santosa wrote:
> > With those changes in place, the same boot-to-kdm process
> > requires only about 570000 translations to be made, and 2
> > cache flushes to happen. Of course the cost is an extra
> > 48M of memory use.
>
> Good to hear! Wow! Maybe we should made those constants configurable
> (using ./configure script)?
It might be an even better idea to make command line options out of it. I
know, I know, these are #define'd, and thus the buffer would have to be
malloc()ed, but it'd be nice to have the same binary running on several
computers (even those which cannot afford another 48M).
Ciao,
Dscho
^ permalink raw reply
* [LARTC] source routing does not work with extra ip addresses
From: richard lucassen @ 2006-04-08 10:30 UTC (permalink / raw)
To: lartc
I set up this config:
+------+
-+ ISP1 +--+
+------+ | +-------+
+--+ linux |
+------+ | +-------+
-+ ISP2 +--+
+------+
No problem. Standard setup with two ISP's. Both routed subnets. Default
gateway is ISP1. No magic here.
Now I put a server behind the Linux box. I want the server to be
reachable on an /extra/ IP in the routed subnet of ISP2.
+------+
-+ ISP1 +--+
+------+ | +-------+ +-----------------+
+--+ linux +--+ server 10.0.0.2 |
+------+ | +-------+ +-----------------+
-+ ISP2 +--+
+------+
router ISP2: 1.2.3.1/24
dev ISP2: eth1
Linux box eth1: 1.2.3.2/24
external ip ISP2 for server 10.0.0.2: 1.2.3.3
arp -s 1.2.3.3 aa:bb:cc:dd:ee:ff pub
ip route add 1.2.3.3 via 10.0.0.2
iptables -t nat -A PREROUTING -i eth1 -d 1.2.3.3 -j DNAT --to 10.0.0.2
When pinging 1.2.3.3, the packets get in through eth1 (ok), but the
replies are following the default route through eth0 (wrong)
Even a
ip rule add from 1.2.3.3 lookup table_eth1
doesn't change this behaviour. It is working ok when I add the address
1.2.3.3 directly to eth1:
ip a a 1.2.3.3 dev eth1
Why is this?
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 |
+------------------------------------------------------------------+
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [LARTC] Tocken Bucket with priority?
From: Emanuele Colombo @ 2006-04-08 10:37 UTC (permalink / raw)
To: lartc
In-Reply-To: <e67264960604050618t481a1f79uffe3065ac2ebe56f@mail.gmail.com>
2006/4/7, Martin A. Brown <martin-lartc@wonderfrog.net>:
>
> Hi there Emanuele,
>
> I realize I'm jumping in a bit late on this item, but I don't quite
> understand why HTB as below should not work for you. Have you tried
> a configuration like the below? You must know your available
> bandwidth for this trick to work, but the following configuration
> approximates a PRIO qdisc, but gives you the benefit of shaping.
>
> class $parent, rate $MAX, ceil $MAX
> |
> +- class $voip, rate ( 0.95 * $MAX), ceil $MAX
> |
> +- class $other, rate ( 0.05 * $MAX), ceil $MAX
>
> Remember that all the shaping and prioritizing in the world will not
> help you if you are not the bottleneck. Your shaping/prioritizing
> device must be the choke point.
I've already tried this way... with VoIP traffic this solution doesn't
work very well, because data traffic tries to use as much bandwidth as
possible, and it creates some jitter and delay on voice data...
> While I don't have any direct experience with VoIP, I can imagine
> that you might see an increased latency as a result of queuing delay
> in your VoIP class. To limit latency induced by queuing delay, you
> could create a child of the $voip class with bfifo or pfifo qdisc of
> a specified depth/size. If, however, this is necessary, you may
> simply need more bandwidth.
don't need more bandwidth, I need that data bandwith is reduced!
> And, as an attempt to answer your question above....perhaps you
> could try fiddling with the quantum setting on a given class. When
> a given class has exceeded its rate, it can only transmit quantum
> bytes per dequeue opportunity.
I tried changing quantum and r2q parameters of HTB, but I can't solve
this problem... setting a low value of quantum results in decreasing
real throughput, and it also introduces dependence on packet size...
Another test I've done is to create only a prio qdisc (without HTB)
and make the phisical layer slower than incoming traffic. It appears
to be a problem of prio, because the same problem of queuing in high
priority queue happens.
Emanuele
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [lm-sensors] hwmon/pc87360 as a platform driver
From: Jean Delvare @ 2006-04-08 10:40 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4436BE3B.7090306@gmail.com>
Hi Jim,
> Ive just made a rough pass thru pc87360, and have converted it
> to a non-working, but non-crashing platform_driver that does
> at least a little of what it should:
>
> soekris:~# modprobe pc87360
> [ 964.952000] pc87360: Device 0x09 not activated
> [ 966.576000] pc87360 pc87360.26144: VLM conversion set to 1s period,
> 160us delay
> soekris:~#
> (...)
> so far so good, but:
>
> soekris:~# sensors -s
> No sensors found!
> soekris:~#
> soekris:~# sensors
> No sensors found!
>
> my libsensors is unstable debian package: libsensors 1:2.10.0-3
> That version number looks to contain 2.10.0
>
> Frankly, Im hoping that with 2.10, the user-side just works, but this is
> not the case here.
>
> Any guesses / suggestions as to whats wrong ?
First of all, Juerg's answer is correct, 2.10.0 doesn't play fair with
platform hwmon drivers unless an i2c driver is also present.
Secondly, your driver must have a "name" attribute containing the chip
name (such as "pc87360" or "pc87366" etc. in your case) else libsensors
won't be able to use it. That's probably what you're missing here.
BTW, I don't want to discourage you from working on this, as this will
be needed at some point in time, but remember that I do not plan to
accept any i2c-isa -> platform conversion before next year, because we
need a widely deployed base of working libsensors before we do, and
unfortunately even 2.10.0 doesn't qualify, as Juerg and you found out.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Funny repack behaviour
From: Johannes Schindelin @ 2006-04-08 10:41 UTC (permalink / raw)
To: git
Hi,
I just accidentally reran "git-repack -a -d" on a repository, where I just
had run it. And I noticed a funny thing: Of about 4000 objects, it reused
all but 8. So I reran it, and it reused all but 2. I ran it once again,
and it reused all.
The really funny thing is: it created the same pack every time!
It is not critical, evidently, but I'd like to know what is causing this
rather undeterministic behaviour. (Before you ask: no, I did not make a
backup before running the tests, so I unfortunately cannot reproduce it).
Ciao,
Dscho
P.S.: This is the output:
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3391), reused 4241 (delta 3379)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4257 (delta 3391)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4259 (delta 3393)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
^ permalink raw reply
* Re: [patch] ipv4: initialize arp_tbl rw lock
From: Heiko Carstens @ 2006-04-08 10:42 UTC (permalink / raw)
To: David S. Miller
Cc: shemminger, jgarzik, akpm, netdev, linux-kernel, fpavlic, davem
In-Reply-To: <20060408.031404.111884281.davem@davemloft.net>
> We could make inet_init() a subsystem init but I vaguely recall
> that we were doing that at one point and it broke things for
> some reason.
>
> Perhaps fs_initcall() would work better. Or if that causes
> problems we could create a net_initcall() that sits between
> fs_initcall() and device_initcall().
>
> Or any other ideas?
Just tried fs_initcall() and net_initcall(). Both seem to have some
side effects:
Symptom is that console output sometimes hangs for several seconds at:
"NET: Registered protocol family 2" while all cpus are in cpu_idle().
Heiko
^ permalink raw reply
* Re: [LARTC] Tocken Bucket with priority?
From: Emanuele Colombo @ 2006-04-08 10:43 UTC (permalink / raw)
To: lartc
In-Reply-To: <e67264960604050618t481a1f79uffe3065ac2ebe56f@mail.gmail.com>
2006/4/7, Jason Boxman <jasonb@edseek.com>:
> One thing you may try is to recompile sch_htb with HTB_HYSTERESIS[1] set to 0.
>
> You'll get improved performance on slower links where you need the accurancy.
>
> [1] http://edseek.com/~jasonb/articles/traffic_shaping/buildkernel.html
Ok, I'll try, thanks!
Emanuele
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* proposals for grub2 (i think 3rd email)
From: adrian15 @ 2006-04-08 10:35 UTC (permalink / raw)
To: grub-devel
So that we don't forget:
http://lists.nongnu.org/archive/html/grub-devel/2005-08/msg00163.html
1) fexists FILE functions. Gives OK if the file exists. Gives ERROR if
the file not exists.
2) Being able to mount tar.gz files.
3) Being able to mount loopback devices.
4) Mapping partitions directly to Grub partitions. Is it possible ?
5) dd equivalent command.
That's all.
I'm seeing that you've advanced a lot on scripting support and there're
some beginnings on graphics area.
Great work!
adrian15
P.S.: I think I sent another mail but I do not find it.
^ permalink raw reply
* Linux does not correctly implement the ACPI specification
From: Peter Wainwright @ 2006-04-08 10:52 UTC (permalink / raw)
To: linux-acpi
In-Reply-To: <971FCB6690CD0E4898387DBF7552B90E04970A19@orsmsx403.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]
Reference:
http://bugzilla.kernel.org/show_bug.cgi?id=5534
There has been no significant movement on this bug for months.
I can only conclude that the problem is only triggered by a few
very sophisticated DSDTs (the HP nx6125 among them) or has remained
unrecognized on other platforms. Nonetheless it seems to me that
Linux does not correctly implement the ACPI spec.
Therefore, I propose a solution with the patch attached.
Interpretation of control methods called in response to GPE events or
Notify events is confined to one single-threaded workqueue.
It is true that the AML interpreter is essentially single-threaded,
because it is protected by a mutex and therefore only one kernel thread
can be executing AML code at one time. However, this does NOT mean that
the execution of different control methods should not overlap. The ACPI
spec allows for the transfer of control between one method and another
when the AML calls Sleep, Acquire, Wait etc. (see the ACPI-CA
reference).
The way Sleep() is implemented in Linux, it calls schedule() and transfers
control to other kernel threads: but any other control method which is queued
in the kacpid thread itself will not be able to run until the currently
executing control method is finished.
On the HP nx6125 laptop this is essential, otherwise the ACPI subsystem
will block, thermal events will not be processed, and the system will
overheat. http://bugzilla.kernel.org/show_bug.cgi?id=5534
So, if any of you have an nx6125, or an ACPI bug which you think may be
caused by the mechanism I have described, please try this patch.
This is my first attempt at a serious kernel hack, so please forgive
the state of it: this is work in progress. At least it should show one
approach to the problem. I'm sure it has loads of problems with respect
to locking, SMP, etc. which you will point out.
In order to enable the new behaviour you need to write a positive
integer (e.g. 10) to /proc/acpi/poolsize.
Instead of executing all the GPE and Notify handlers in the single
kacpid thread, we create a pool of worker threads and hand over the
work to them. These can now execute concurrently, though access to the
interpreter is still serialized by the use of a mutex. The thread pool
is allowed to grow dynamically up to the maximum size which is set by
the user by writing an integer to /proc/acpi/poolsize. If this integer
is 0 the thread pool is not used at all and the old behaviour is used.
You can also read /proc/acpi/poolsize to see the maximum pool size and
the currently allocated threads. There is a field "jiffies" in the
thread pool entry structure which is written when a thread finishes
execution of a control method. My intention is that in future this will
be used to reap unused threads.
Of course, the user-configurable pool size may not be necessary. We
might hard-code it. Or even allow the AML to create as many threads as
necessary (assuming we trust the BIOS).
Peter Wainwright (P.S. not the Apache/Perl expert).
[-- Attachment #2: acpi-osl.patch --]
[-- Type: text/x-patch, Size: 7137 bytes --]
diff -U3 -r linux-2.6.16-prw11-old/drivers/acpi/bus.c linux-2.6.16-prw11/drivers/acpi/bus.c
--- linux-2.6.16-prw11-old/drivers/acpi/bus.c 2006-01-03 03:21:10.000000000 +0000
+++ linux-2.6.16-prw11/drivers/acpi/bus.c 2006-04-08 08:25:09.000000000 +0100
@@ -664,6 +664,7 @@
int result = 0;
acpi_status status = AE_OK;
extern acpi_status acpi_os_initialize1(void);
+ extern acpi_status acpi_os_initialize2(void);
ACPI_FUNCTION_TRACE("acpi_bus_init");
@@ -727,6 +728,8 @@
*/
acpi_root_dir = proc_mkdir(ACPI_BUS_FILE_ROOT, NULL);
+ status = acpi_os_initialize2();
+
return_VALUE(0);
/* Mimic structured exception handling */
diff -U3 -r linux-2.6.16-prw11-old/drivers/acpi/osl.c linux-2.6.16-prw11/drivers/acpi/osl.c
--- linux-2.6.16-prw11-old/drivers/acpi/osl.c 2006-04-08 07:50:57.000000000 +0100
+++ linux-2.6.16-prw11/drivers/acpi/osl.c 2006-04-08 09:10:05.000000000 +0100
@@ -46,6 +46,10 @@
#include <linux/efi.h>
+#include <linux/kthread.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+
#define _COMPONENT ACPI_OS_SERVICES
ACPI_MODULE_NAME("osl")
#define PREFIX "ACPI: "
@@ -76,6 +80,165 @@
static void *acpi_irq_context;
static struct workqueue_struct *kacpid_wq;
+/* This parameter may be configured at runtime by writing to
+ /proc/acpi/poolsize */
+static int max_thread_pool_size = 0;
+
+/* Hopefully we need no special locking here, since this always
+ executes in one thread: kacpid */
+static int thread_pool_size = 0;
+static struct list_head thread_pool = LIST_HEAD_INIT(thread_pool);
+
+struct thread_pool_entry {
+ struct task_struct *thread;
+ int id;
+ int active;
+ acpi_osd_exec_callback function;
+ void *context;
+ unsigned long jiffies;
+ wait_queue_head_t more_work;
+ wait_queue_head_t work_done;
+ struct list_head list;
+};
+
+static int acpi_osl_poolsize_read(struct seq_file *seq, void *offset)
+{
+ struct list_head *l;
+
+ ACPI_FUNCTION_TRACE("acpi_osl_poolsize_read");
+
+ seq_printf(seq, "poolsize=%d\n", max_thread_pool_size);
+ /* FIXME: Need lock? */
+ list_for_each(l, &thread_pool) {
+ struct thread_pool_entry *e = list_entry(l, struct thread_pool_entry, list);
+ seq_printf(seq, "entry=(%p,%d,%p,%p)\n",
+ e->thread, e->active, e->function, e->context);
+ }
+ return_VALUE(0);
+}
+
+static int acpi_osl_poolsize_open_fs(struct inode *inode, struct file *file)
+{
+ return single_open(file, acpi_osl_poolsize_read, PDE(inode)->data);
+}
+
+static ssize_t
+acpi_osl_poolsize_write(struct file *file,
+ const char __user * buffer,
+ size_t count, loff_t * ppos)
+{
+ char *size_string;
+
+ ACPI_FUNCTION_TRACE("acpi_osl_poolsize_write");
+
+ size_string = kmalloc(4096, GFP_KERNEL);
+ if (!size_string)
+ return_VALUE(-ENOMEM);
+
+ memset(size_string, 0, 4096);
+
+ if (copy_from_user(size_string, buffer, count)) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid data\n"));
+ count = -EFAULT;
+ goto end;
+ }
+
+ size_string[count] = '\0';
+ max_thread_pool_size = simple_strtol(size_string, NULL, 10);
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "Poolsize now %d\n", max_thread_pool_size));
+
+end:
+ kfree(size_string);
+ return_VALUE(count);
+}
+
+static struct file_operations acpi_osl_poolsize_ops = {
+ .open = acpi_osl_poolsize_open_fs,
+ .read = seq_read,
+ .write = acpi_osl_poolsize_write,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+/* This is based on workqueue worker_thread */
+static int acpi_os_execute_worker(void *context)
+{
+ struct thread_pool_entry *e = (struct thread_pool_entry *)context;
+ DECLARE_WAITQUEUE(wait, current);
+
+ set_user_nice(current, -5);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] before loop\n", e->id, e));
+ while (!kthread_should_stop()) {
+ /* Wait until there is work to do in this thread */
+ add_wait_queue(&e->more_work, &wait);
+ if (!e->function) {
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] sleeping\n", e->id, e));
+ schedule();
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] waking (function=%p)\n", e->id, e, e->function));
+ }
+ else {
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] running (function=%p)\n", e->id, e, e->function));
+ __set_current_state(TASK_RUNNING);
+ }
+ try_to_freeze();
+ remove_wait_queue(&e->more_work, &wait);
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] ready (function=%p)\n", e->id, e, e->function));
+ if (e->function) {
+ acpi_osd_exec_callback function = e->function;
+ void *context = e->context;
+ e->function = NULL;
+ e->context = NULL;
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] executing function=%p context=%p\n",
+ e->id, e, function, context));
+ function(context);
+
+ e->active = 0;
+ e->jiffies = jiffies;
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] function=%p context=%p exit at %lx\n",
+ e->id, e, function, context, e->jiffies));
+
+ }
+ set_current_state(TASK_INTERRUPTIBLE);
+ }
+
+ return 0;
+}
+
+static struct thread_pool_entry *get_pool_thread(void)
+{
+ struct list_head *l;
+ list_for_each(l, &thread_pool) {
+ struct thread_pool_entry *e = list_entry(l, struct thread_pool_entry, list);
+ if (!e->active) {
+ e->active = 1;
+ return e;
+ }
+ }
+ /* N.B. For the time being we have a user-configurable limit
+ on the thread_pool_size. We don't want a bad BIOS to create
+ unlimited kthreads. */
+ if (thread_pool_size < max_thread_pool_size) {
+ struct thread_pool_entry *e;
+ e = kmalloc(sizeof(struct thread_pool_entry), GFP_KERNEL);
+ list_add_tail(&e->list, &thread_pool);
+ e->id = thread_pool_size;
+ init_waitqueue_head(&e->more_work);
+ init_waitqueue_head(&e->work_done);
+ e->function = NULL;
+ e->context = NULL;
+ e->active = 1;
+ /* kthread_run does kthread_create and wake_up_process */
+ e->thread = kthread_run(acpi_os_execute_worker, e, "kacpid-work-%d",
+ thread_pool_size);
+ thread_pool_size++;
+ return e;
+ }
+ return NULL;
+}
+
acpi_status acpi_os_initialize(void)
{
return AE_OK;
@@ -98,6 +261,16 @@
return AE_OK;
}
+/* enable poolsize modification by /proc filesystem */
+acpi_status acpi_os_initialize2(void)
+{
+ struct proc_dir_entry *entry;
+ entry = create_proc_entry("poolsize", S_IRUSR|S_IWUSR, acpi_root_dir);
+ if (entry)
+ entry->proc_fops = &acpi_osl_poolsize_ops;
+ return AE_OK;
+}
+
acpi_status acpi_os_terminate(void)
{
if (acpi_irq_handler) {
@@ -661,6 +834,7 @@
static void acpi_os_execute_deferred(void *context)
{
struct acpi_os_dpc *dpc = NULL;
+ struct thread_pool_entry *e = NULL;
ACPI_FUNCTION_TRACE("os_execute_deferred");
@@ -670,8 +844,18 @@
return_VOID;
}
- dpc->function(dpc->context);
-
+ if (max_thread_pool_size > 0 && (e = get_pool_thread())) {
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] function=%p context=%p\n",
+ e->id, e, dpc->function, dpc->context));
+ e->context = dpc->context;
+ e->function = dpc->function;
+ wake_up(&e->more_work);
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "[%d:%p] wake finished\n", e->id, e));
+ }
+ else {
+ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "(now) function=%p context=%p\n", dpc->function, dpc->context));
+ dpc->function(dpc->context);
+ }
kfree(dpc);
return_VOID;
^ permalink raw reply
* Re: patches for fsample/850
From: Komal Shah @ 2006-04-08 11:00 UTC (permalink / raw)
To: Brian Swetland, linux-omap-open-source
In-Reply-To: <20060407220658.GA19801@localhost.localdomain>
--- Brian Swetland <swetland@google.com> wrote:
>
> Attached is a set of patches to start support for the omap850
> and specifically the f-sample development board from TI.
>
> Features:
>
> - machine ID 970 as registered with the arm machine registery:
> http://www.arm.linux.org.uk/developer/machines/?action=list&id=970
> - initial support for the FPGA on fsample
> - adjustment to the 'p2' lcd driver so that it correctly initializes
> the display on fsample (which involves using the FPGA interface)
> - some adjustment to clock.h/clock.c to avoid disabling the baseband
> side of the world on 730/850 as a sideeffect of other clock changes
Are you using u-boot as bootloader and where you will make it
available?
Better place to put it is linux.omap.com.
> +obj-$(CONFIG_MACH_OMAP_FSAMPLE) += board-fsample.o
Your patch is not having board-fsample.c.
---Komal Shah
http://komalshah.blogspot.com/
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [ANNOUNCE] qgit-1.2rc1
From: Marco Costalba @ 2006-04-08 11:07 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <e5bfff550604080244y40b36292ja5cfecac28e1e749@mail.gmail.com>
On 4/8/06, Marco Costalba <mcostalba@gmail.com> wrote:
> qgit is a very fast git GUI viewer with a lot of features .
>
> The biggest new feature this time is *code range filtering*
>
Before hitting the warning pop-up about git version compatibility at
qgit launch,please note that a git with --boundary option support
is required.
git-rev-list --boundary has been merged after git-1.3.0.rc1, so better
upgrade git to latest upstream snapshot git-1.3.0rc3
Of course final qgit-1.2 will be out only _after_ released git-1.3.0
Marco
^ permalink raw reply
* Re: nasm / code distance
From: Thiago Silva @ 2006-04-08 11:09 UTC (permalink / raw)
To: linux-assembly
In-Reply-To: <20060408094752.GA5931@wintermute>
Well...the code is really a big one.
To clarify, I made simple test:
On the entry point, I read some data in the .data section (such as "mov eax,
dword [_r]"). Running valgrind, this read is not shown on the error
reporting.
Then, I copied this same read code and pasted it on a function in the end of
the file (is a pretty big source file). Then, valgrind complained that this
was an invalid read!!
So I though there might be something I'm missing...
The same goes for the jmp instructions getting the "short jump out of range".
On Saturday 08 April 2006 09:47, you wrote:
> On Fri, Apr 07, 2006 at 06:47:32PM +0000, Thiago Silva wrote:
> > Hello, I'm having some troubles with an asm application.
>
> It's hard to say anything specific without you showing the problematic
> parts of your code.
>
> Leslie
--
+Thiago Silva
^ permalink raw reply
* Black box flight recorder for Linux
From: James Courtier-Dutton @ 2006-04-08 11:12 UTC (permalink / raw)
To: linux list
Hi,
I have had an idea for a black box flight recorder type feature for
Linux. Before I try to implement it, I just wish to ask here if anyone
has already tried it, and whether the idea works or not.
Description for feature:
Stamp the dmesg output on RAM somewhere, so that after a reset (reset
button pressed, not power off), the RAM can be read and details of
oopses etc. can be read.
Now, the question I have is, if I write values to RAM, do any of those
values survive a reset? If any did survive, one could use them to store
oops output in. I am currently only interested in Intel CPU and AMD CPU
based motherboards. If only some values survived, one could use some
sort of redundant encoding so the good values could be recovered.
The main advantage of something like this would be for newer
motherboards that are around now that don't have a serial port.
If no one has tried this, I will spend some time testing.
James
^ permalink raw reply
* Re: Serial console problem with Xen 3.0
From: Keir Fraser @ 2006-04-08 11:15 UTC (permalink / raw)
To: Keir Fraser; +Cc: Don Zickus, Michael Paesold, xen-devel Devel, Jan Beulich
In-Reply-To: <de3822336c97e6557905ec7d53b35388@cl.cam.ac.uk>
On 7 Apr 2006, at 17:51, Keir Fraser wrote:
>> I just wanted to confirm that pnpacpi=off solves my problem and give
>> me full access over the serial console.
>>
>> Should this get an issue in the bugtracker?
>
> Yes, it's probably a good thing to gather all this stuff in one place.
> By the way, I have some fixes already for the IO-APIC checking routine
> that I mentioned. We're just going to give it a shakedown in Cambridge
> before putting it in the public repository.
I can confirm that my patch at least fixes the pnpacpi problem that
you've been seeing. I've also enabled CONFIG_PNP_ACPI by default in our
-xen0 and -xen defconfig files, so we should get wider feedback on
issues relating to that config option now.
I've also backported my io_apic.c changes to the 3.0-testing tree so
they should be in 3.0.2-1 (the next rolling release of 3.0.2).
-- Keir
^ permalink raw reply
* Re: proposals for grub2 (i think 3rd email)
From: Marco Gerards @ 2006-04-08 11:16 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <443791E0.8050007@raulete.net>
adrian15 <adrian15@raulete.net> writes:
> 1) fexists FILE functions. Gives OK if the file exists. Gives ERROR if
> the file not exists.
This will be implemented like in bash.
> 2) Being able to mount tar.gz files.
Why?
> 3) Being able to mount loopback devices.
This is possible already.
> 4) Mapping partitions directly to Grub partitions. Is it possible ?
Huh?
> 5) dd equivalent command.
I personally would like something like this, combined with networking
support.
--
Marco
^ permalink raw reply
* Re: [LARTC] u32 and iptables do not work together
From: Nataniel Klug @ 2006-04-08 11:21 UTC (permalink / raw)
To: lartc
In-Reply-To: <4436AEB8.1070300@cnett.com.br>
Jody,
I think it worked fine... This is my new script (below the text). I just
dont know how can I know if this traffic is relly going to the class I
send it... hehehehe... I am marking Skype packages using L7-Filter like
this:
$IPT -t mangle -A PREROUTING -m layer7 --l7proto skypetoskype -j MARK
--set-mark 10
Att,
Nataniel Klug
--------------------------------
#!/bin/sh
#------
# Script de QoS Cyber Nett
#------
# Nataniel Klug
# suporte@cnett.com.br
#------
TC="/sbin/tc"
IPT="/usr/local/sbin/iptables"
DL="eth3"
#------
# Apagando regras antigas de QoS
#------
$TC qdisc del dev $DL root 2> /dev/null > /dev/null
$TC qdisc del dev $DL ingress 2> /dev/null > /dev/null
#------
# Regras para a placa eth1
#------
$TC qdisc add dev $DL root handle 1: htb default 50
CLASS="/sbin/tc class add dev $DL parent"
$CLASS 1: classid 1:1 htb rate 3072Kbit
$CLASS 1:1 classid 1:10 htb rate 384Kbit prio 1
$CLASS 1:1 classid 1:20 htb rate 1024Kbit ceil 2048Kbit prio 2
$CLASS 1:1 classid 1:30 htb rate 512Kbit ceil 512Kbit prio 3
$CLASS 1:1 classid 1:40 htb rate 512Kbit ceil 512Kbit prio 4
$CLASS 1:1 classid 1:50 htb rate 640Kbit ceil 640Kbit prio 5
QDISC="/sbin/tc qdisc add dev $DL parent"
$QDISC 1:10 handle 10: sfq perturb 10
$QDISC 1:20 handle 20: sfq perturb 10
$QDISC 1:30 handle 30: sfq perturb 10
$QDISC 1:40 handle 40: sfq perturb 10
$QDISC 1:50 handle 50: sfq perturb 10
FILTER="/sbin/tc filter add dev $DL parent 1:0 protocol"
$FILTER ip prio 11 u32 match ip protocol 1 0xff flowid 1:10
$FILTER ip prio 12 u32 match ip sport 22 0xffff flowid 1:10
$FILTER ip prio 12 u32 match ip sport 23 0xffff flowid 1:10
$FILTER ip prio 12 u32 match ip sport 2202 0xffff flowid 1:10
$FILTER ip prio 13 u32 match ip sport 6121 0xffff flowid 1:10
$FILTER ip prio 13 u32 match ip sport 5121 0xffff flowid 1:10
$FILTER ip prio 14 handle 10 fw classid 1:10
$FILTER ip prio 21 u32 match ip sport 80 0xffff flowid 1:20
$FILTER ip prio 21 u32 match ip sport 443 0xffff flowid 1:20
$FILTER ip prio 21 u32 match ip sport 3128 0xffff flowid 1:20
$FILTER ip prio 22 u32 match ip src 200.189.176.206/32 flowid 1:20
$FILTER ip prio 22 u32 match ip src 200.189.176.205/32 flowid 1:20
$FILTER ip prio 22 u32 match ip sport 5065 0xffff flowid 1:20
$FILTER ip prio 22 u32 match ip sport 5070 0xffff flowid 1:20
$FILTER ip prio 31 u32 match ip sport 53 0xffff flowid 1:30
$FILTER ip prio 32 u32 match ip sport 25 0xffff flowid 1:30
$FILTER ip prio 32 u32 match ip sport 110 0xffff flowid 1:30
$FILTER ip prio 41 u32 match ip sport 21 0xffff flowid 1:40
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: MacOS X on Xen
From: Mark Williamson @ 2006-04-08 11:22 UTC (permalink / raw)
To: xen-devel; +Cc: Jun OKAJIMA
In-Reply-To: <200604071102.AA01007@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
> Somebody know feasiblity of MacOS X on Xen?
Ehhhhh, perhaps feasible in a number of ways but it's not terribly obvious to
me which will actually work...
> Of course, it is possible if you have VT, but I think DomU kernel
> ( a Xen kernel you dont have to use VT with) is also possible.
> It comes with a source code of the core part ( Mach micro kernel),
> so I believe that it is not impossible to run MacOS X as DomU of Xen,
> without VT.
Difficult. Firstly, it's hard because Apple have done something to prevent
OSX from booting on anything but real Apple hardware. I'm not clear exactly
how this scheme works, so it's not clear to me if you can circumvent it in a
legal-looking way in a VT virtual machine.... You could probably apply the
hacks used to get VMware hosting MacOS already, but that's not really the
Right Way legally or technically.
Secondly, if you wanted to actually *port* Darwin you'd have another obstacle.
standard x86 Darwin is not compatible with MacOS/x86 Darwin :-( Apple have
broken driver compatibility here (userspace should still work) for some
reason. Therefore I understand it's not possible to recompile your kernel
for MacOS as was possible on the PPC platform (in fact at one point there was
a plan to make OSX run on PPC Xen, but I don't know if that's been scuppered
by the switch to Intel)
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
^ permalink raw reply
* [PATCH] trivial fs/select.c compiler warning fix
From: Horst Schirmeier @ 2006-04-08 11:28 UTC (permalink / raw)
To: Alexander Viro; +Cc: linux-kernel, trivial
This trivial patch fixes
fs/select.c: In function `core_sys_select':
fs/select.c:339: warning: assignment from incompatible pointer type
fs/select.c:376: warning: comparison of distinct pointer types lacks a cast
by casting to (char *) when accessing stack_fds.
Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
---
diff --git a/fs/select.c b/fs/select.c
index 071660f..3025cec 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -336,7 +336,7 @@ static int core_sys_select(int n, fd_set
ret = -ENOMEM;
size = FDS_BYTES(n);
if (6*size < SELECT_STACK_ALLOC)
- bits = stack_fds;
+ bits = (char *) stack_fds;
else
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
@@ -373,7 +373,7 @@ static int core_sys_select(int n, fd_set
ret = -EFAULT;
out:
- if (bits != stack_fds)
+ if (bits != (char *) stack_fds)
kfree(bits);
out_nofds:
return ret;
--
PGP-Key 0xD40E0E7A
^ permalink raw reply related
* Re: blame now knows -S
From: Fredrik Kuivinen @ 2006-04-08 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git, Fredrik Kuivinen
In-Reply-To: <7v1ww9loon.fsf@assigned-by-dhcp.cox.net>
On Fri, Apr 07, 2006 at 02:28:40AM -0700, Junio C Hamano wrote:
> I've made a few changes to "git blame" myself:
>
> - fix breakage caused by recent revision walker reorganization;
> - use built-in xdiff instead of spawning GNU diff;
> - implement -S <ancestry-file> like annotate does.
>
> Depending on the density of changes, it now appears that blame
> is 10%-30% faster than annotate. I thought CVS emulator might
> be interested to give it a whirl..
>
Nice work!
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.
- Fredrik
^ permalink raw reply
* [PATCH 2.4.33-pre2] 2.4 nfs cache consistency problem with mmap'ed files
From: Jeff Layton @ 2006-04-08 11:43 UTC (permalink / raw)
To: nfs; +Cc: linux-kernel, marcelo.tosatti
A customer of Red Hat reported a problem with cache invalidation when
using mmapped files over NFS with the 2.4 kernel. The steps to reproduce
this are a bit convoluted, so hopefully I'm explaining this well enough.
Let me know if you need clarification:
1) on a server create a file in an exported directory with some data in
it:
$ echo 1 > testfile
2) on an NFS client have a program mmap the file and access the data via
the mmap (effectively loading the pagecache with data from the server),
then have the program go to sleep indefinitely.
3) on the server, make a change to the file:
$ echo 2 > testfile
4) on the client, have another process cause a read:
$ cat /nfs/mounted/directory/testfile
You'll get the originally cached data (the 1), since the file is still
mmap'ed. This is expected.
5) on the client, kill the program that has the file mmap'ed and cat the
file again. You will still get the original file contents (the "1"
here).
The file is no longer mmap'ed, the data in the file and the mtime has
changed since the last on the wire read, but the client will not
invalidate the cache for subsequent reads.
What's happening is that in step 4, the __nfs_refresh_inode function
updates NFS_CACHE_MTIME. But, because the file is still mmap'ed,
invalidate_inode_pages is not completely successful. So on the next pass
through, it assumes the cached data is up to date when it isn't.
This patch fixes this by checking whether the clean_pages list
for the inode is empty after invalidate_inode_pages is called. If it's
not then we set a flag so on the next pass through it automatically
flags the data as invalid.
Signed-off-by: Jeff Layton <jtlayton@poochiereds.net>
--- linux-2.4/fs/nfs/inode.c.nfs-cache-fix
+++ linux-2.4/fs/nfs/inode.c
@@ -1047,6 +1047,13 @@ __nfs_refresh_inode(struct inode *inode,
invalid = 0;
}
+ /* set the invalid flag if the last attempt at invalidating
+ * the inode didn't empty the clean_pages list */
+ if ( NFS_FLAGS(inode) & NFS_INO_MAPPED) {
+ NFS_FLAGS(inode) &= ~NFS_INO_MAPPED;
+ invalid = 1;
+ }
+
/*
* If we have pending writebacks, things can get
* messy.
@@ -1092,6 +1099,12 @@ __nfs_refresh_inode(struct inode *inode,
NFS_ATTRTIMEO(inode) = NFS_MINATTRTIMEO(inode);
NFS_ATTRTIMEO_UPDATE(inode) = jiffies;
invalidate_inode_pages(inode);
+ if (! list_empty(&inode->i_mapping->clean_pages)) {
+ dfprintk(PAGECACHE,
+ "NFS: clean_pages for %x/%d is not empty\n",
+ inode->i_dev, inode->i_ino);
+ NFS_FLAGS(inode) |= NFS_INO_MAPPED;
+ }
memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode)));
} else if (time_after(jiffies, NFS_ATTRTIMEO_UPDATE(inode)+NFS_ATTRTIMEO(inode))) {
if ((NFS_ATTRTIMEO(inode) <<= 1) > NFS_MAXATTRTIMEO(inode))
--- linux-2.4/include/linux/nfs_fs_i.h.nfs-cache-fix
+++ linux-2.4/include/linux/nfs_fs_i.h
@@ -85,6 +85,7 @@ struct nfs_inode_info {
#define NFS_INO_REVALIDATING 0x0004 /* revalidating attrs */
#define NFS_IS_SNAPSHOT 0x0010 /* a snapshot file */
#define NFS_INO_FLUSH 0x0020 /* inode is due for flushing */
+#define NFS_INO_MAPPED 0x0040 /* page invalidation failed */
/*
* NFS lock info
^ permalink raw reply
* [PATCH 2.4.33-pre2] 2.4 nfs cache consistency problem with mmap'ed files
From: Jeff Layton @ 2006-04-08 11:43 UTC (permalink / raw)
To: nfs; +Cc: linux-kernel, marcelo.tosatti
A customer of Red Hat reported a problem with cache invalidation when
using mmapped files over NFS with the 2.4 kernel. The steps to reproduce
this are a bit convoluted, so hopefully I'm explaining this well enough.
Let me know if you need clarification:
1) on a server create a file in an exported directory with some data in
it:
$ echo 1 > testfile
2) on an NFS client have a program mmap the file and access the data via
the mmap (effectively loading the pagecache with data from the server),
then have the program go to sleep indefinitely.
3) on the server, make a change to the file:
$ echo 2 > testfile
4) on the client, have another process cause a read:
$ cat /nfs/mounted/directory/testfile
You'll get the originally cached data (the 1), since the file is still
mmap'ed. This is expected.
5) on the client, kill the program that has the file mmap'ed and cat the
file again. You will still get the original file contents (the "1"
here).
The file is no longer mmap'ed, the data in the file and the mtime has
changed since the last on the wire read, but the client will not
invalidate the cache for subsequent reads.
What's happening is that in step 4, the __nfs_refresh_inode function
updates NFS_CACHE_MTIME. But, because the file is still mmap'ed,
invalidate_inode_pages is not completely successful. So on the next pass
through, it assumes the cached data is up to date when it isn't.
This patch fixes this by checking whether the clean_pages list
for the inode is empty after invalidate_inode_pages is called. If it's
not then we set a flag so on the next pass through it automatically
flags the data as invalid.
Signed-off-by: Jeff Layton <jtlayton@poochiereds.net>
--- linux-2.4/fs/nfs/inode.c.nfs-cache-fix
+++ linux-2.4/fs/nfs/inode.c
@@ -1047,6 +1047,13 @@ __nfs_refresh_inode(struct inode *inode,
invalid = 0;
}
+ /* set the invalid flag if the last attempt at invalidating
+ * the inode didn't empty the clean_pages list */
+ if ( NFS_FLAGS(inode) & NFS_INO_MAPPED) {
+ NFS_FLAGS(inode) &= ~NFS_INO_MAPPED;
+ invalid = 1;
+ }
+
/*
* If we have pending writebacks, things can get
* messy.
@@ -1092,6 +1099,12 @@ __nfs_refresh_inode(struct inode *inode,
NFS_ATTRTIMEO(inode) = NFS_MINATTRTIMEO(inode);
NFS_ATTRTIMEO_UPDATE(inode) = jiffies;
invalidate_inode_pages(inode);
+ if (! list_empty(&inode->i_mapping->clean_pages)) {
+ dfprintk(PAGECACHE,
+ "NFS: clean_pages for %x/%d is not empty\n",
+ inode->i_dev, inode->i_ino);
+ NFS_FLAGS(inode) |= NFS_INO_MAPPED;
+ }
memset(NFS_COOKIEVERF(inode), 0, sizeof(NFS_COOKIEVERF(inode)));
} else if (time_after(jiffies, NFS_ATTRTIMEO_UPDATE(inode)+NFS_ATTRTIMEO(inode))) {
if ((NFS_ATTRTIMEO(inode) <<= 1) > NFS_MAXATTRTIMEO(inode))
--- linux-2.4/include/linux/nfs_fs_i.h.nfs-cache-fix
+++ linux-2.4/include/linux/nfs_fs_i.h
@@ -85,6 +85,7 @@ struct nfs_inode_info {
#define NFS_INO_REVALIDATING 0x0004 /* revalidating attrs */
#define NFS_IS_SNAPSHOT 0x0010 /* a snapshot file */
#define NFS_INO_FLUSH 0x0020 /* inode is due for flushing */
+#define NFS_INO_MAPPED 0x0040 /* page invalidation failed */
/*
* NFS lock info
-------------------------------------------------------
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
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH] trivial fs/select.c compiler warning fix
From: Horst Schirmeier @ 2006-04-08 11:46 UTC (permalink / raw)
To: Alexander Viro, linux-kernel, trivial
In-Reply-To: <20060408112859.GS2335@quickstop.soohrt.org>
Whoops. Looks like Russell King already created a more elaborate patch
for this problem yesterday (20060407153715.GA31458@flint.arm.linux.org.uk).
On Sat, 08 Apr 2006, Horst Schirmeier wrote:
> This trivial patch fixes
> fs/select.c: In function `core_sys_select':
> fs/select.c:339: warning: assignment from incompatible pointer type
> fs/select.c:376: warning: comparison of distinct pointer types lacks a cast
> by casting to (char *) when accessing stack_fds.
>
> Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
>
> ---
>
> diff --git a/fs/select.c b/fs/select.c
> index 071660f..3025cec 100644
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -336,7 +336,7 @@ static int core_sys_select(int n, fd_set
> ret = -ENOMEM;
> size = FDS_BYTES(n);
> if (6*size < SELECT_STACK_ALLOC)
> - bits = stack_fds;
> + bits = (char *) stack_fds;
> else
> bits = kmalloc(6 * size, GFP_KERNEL);
> if (!bits)
> @@ -373,7 +373,7 @@ static int core_sys_select(int n, fd_set
> ret = -EFAULT;
>
> out:
> - if (bits != stack_fds)
> + if (bits != (char *) stack_fds)
> kfree(bits);
> out_nofds:
> return ret;
>
--
PGP-Key 0xD40E0E7A
^ permalink raw reply
* Re: Fw: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295
From: Patrick McHardy @ 2006-04-08 11:51 UTC (permalink / raw)
To: dmb; +Cc: Andrew Morton, netdev, Netfilter Development Mailinglist
In-Reply-To: <20060407142331.26e6b653.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]
Andrew Morton wrote:
>
> Begin forwarded message:
>
> Date: Fri, 7 Apr 2006 06:12:07 -0700
> From: bugme-daemon@bugzilla.kernel.org
> To: bugme-new@lists.osdl.org
> Subject: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295
>
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6349
>
> Summary: iptables DNAT returns unknown error 4294967295
> Kernel Version: 2.6.17-rc1
> Status: NEW
> Severity: blocking
> Owner: laforge@gnumonks.org
> Submitter: dmb@pochta.ru
>
>
> Problem Description:
> When I try to add the rule with target DNAT to the OUTPUT chain I get the error
> message:
> [root@dbagrii:~]# iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport 119 -j
> DNAT --to-destination 192.168.1.10:8119
> iptables: Unknown error 4294967295
>
> No rule is added, and the kernel says the message to the syslog:
> Apr 7 15:20:05 dbagrii kernel: ip_tables: DNAT target: bad hook_mask 8
>
> This error appears with iptables tool version 1.3.3 and 1.3.5 i tried to use.
>
> Steps to reproduce:
> Run the iptables tool with this arguments:
> $ iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport 119 -j DNAT
> --to-destination 192.168.1.10:8119
Please try if this patch helps.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 973 bytes --]
[NETFILTER]: Fix DNAT in LOCAL_OUT
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 0fc7ff57191de5c09afe7db3932009963bba44d6
tree 02bc033088605bfd51fa4ea7ceb57d0aae1db65e
parent 8cc24d7ca2ffc6d9d70e1d94dc8dffbdf677e58f
author Patrick McHardy <kaber@trash.net> Sat, 08 Apr 2006 13:52:18 +0200
committer Patrick McHardy <kaber@trash.net> Sat, 08 Apr 2006 13:52:18 +0200
net/ipv4/netfilter/ip_nat_rule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/netfilter/ip_nat_rule.c b/net/ipv4/netfilter/ip_nat_rule.c
index efba8c4..250b8ed 100644
--- a/net/ipv4/netfilter/ip_nat_rule.c
+++ b/net/ipv4/netfilter/ip_nat_rule.c
@@ -279,7 +279,7 @@ static struct ipt_target ipt_dnat_reg =
.target = ipt_dnat_target,
.targetsize = sizeof(struct ip_nat_multi_range_compat),
.table = "nat",
- .hooks = 1 << NF_IP_PRE_ROUTING,
+ .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT,
.checkentry = ipt_dnat_checkentry,
};
^ permalink raw reply related
* Re: 2.6.16.1 lost cpu, was: 2.6.16-rc5 'lost' cpu
From: Zwane Mwaikambo @ 2006-04-08 11:55 UTC (permalink / raw)
To: Ashok Raj; +Cc: jensmh, linux-kernel
In-Reply-To: <20060407132206.A27131@unix-os.sc.intel.com>
On Fri, 7 Apr 2006, Ashok Raj wrote:
> On Fri, Apr 07, 2006 at 06:45:36PM +0200, jensmh@gmx.de wrote:
>
> Oh well, seems like that CPU has trouble booting, per message below
> we seemed to start it, but processor didnt run startup code... Suspect its a
> failing part probably..
>
> > CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
> > CPU1: Thermal monitoring enabled
> > CPU1: Intel(R) Xeon(TM) CPU 2.80GHz stepping 09
> > Booting processor 2/6 eip 2000
> > CPU 2 irqstacks, hard=c04b8000 soft=c04b0000
> > Not responding.
> > Inquiring remote APIC #6...
> > ... APIC #6 ID: failed
> > ... APIC #6 VERSION: failed
> > ... APIC #6 SPIV: failed
> > CPU #6 not responding - cannot use it.
Ok i've seen that about 2years ago on a similar Xeon system, it was hard
to reproduce as it only happened on the occassional boot i was thinking of
making the processor startup delays longer but could never get it to
reliably fail. The system is still running today.
^ permalink raw reply
* Re: Fw: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295
From: Patrick McHardy @ 2006-04-08 11:58 UTC (permalink / raw)
To: dmb; +Cc: Andrew Morton, netdev, Netfilter Development Mailinglist
In-Reply-To: <4437A3B9.8000000@trash.net>
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]
Patrick McHardy wrote:
> Please try if this patch helps.
>
> + .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT,
I shouldn't send patches before getting out of bed .. :)
Please try this one instead.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 976 bytes --]
[NETFILTER]: Fix DNAT in LOCAL_OUT
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 2ceefa038e908d5da21aefedae02da4eab1b2787
tree 417f03eca3b97b16a78321ace1556e57f5c60351
parent 8cc24d7ca2ffc6d9d70e1d94dc8dffbdf677e58f
author Patrick McHardy <kaber@trash.net> Sat, 08 Apr 2006 13:59:53 +0200
committer Patrick McHardy <kaber@trash.net> Sat, 08 Apr 2006 13:59:53 +0200
net/ipv4/netfilter/ip_nat_rule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/netfilter/ip_nat_rule.c b/net/ipv4/netfilter/ip_nat_rule.c
index efba8c4..1aba926 100644
--- a/net/ipv4/netfilter/ip_nat_rule.c
+++ b/net/ipv4/netfilter/ip_nat_rule.c
@@ -279,7 +279,7 @@ static struct ipt_target ipt_dnat_reg =
.target = ipt_dnat_target,
.targetsize = sizeof(struct ip_nat_multi_range_compat),
.table = "nat",
- .hooks = 1 << NF_IP_PRE_ROUTING,
+ .hooks = (1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_LOCAL_OUT),
.checkentry = ipt_dnat_checkentry,
};
^ permalink raw reply related
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.