* Re: [PATCH] git log [diff-tree options]...
From: Linus Torvalds @ 2006-04-09 19:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bgmbm8b.fsf@assigned-by-dhcp.cox.net>
On Sun, 9 Apr 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Well, on the other hand, the new "git log --diff" should get the revision
> > counting right even if it's _not_ done by the caller.
>
> Not if the user uses --diff-filter and/or --pickaxe, and after
> we start omitting the log message part when no diff is output.
Fair enough. At that point the counting does have to be done in the
caller, I guess.
> A merge commit touching a path but not actually changing the contents of
> the path from parents might be a significant event.
Yes. The fact that git-whatchanged happens to ignore such things right now
is just a implementation detail, not a "good thing". The new git log seems
to be better in pretty much all respects.
The bigger conceptual difference is actually that once you do revision
pruning based on the pathname limiter, we prune away parents of merges
that seem "uninteresting". So before, when you had the same change come
through two different branches, "git-whatchanged" would actually show it
twice, while the new "git log" approach would tend to show it just once
(because it would pick one of the histories and ignore the other).
I think that's fine (and probably even preferable), but it's another
example of something where we might want to have an option to not
simplify the merge history. It's likely that nobody will ever care, but
who knows..
Linus
^ permalink raw reply
* [LARTC] tc counters "problem"
From: Francisco @ 2006-04-09 19:24 UTC (permalink / raw)
To: lartc
Hi, I'm using tc and HTB to shape my outgoing ADSL traffic. I was trying to
make some graphs on the classes by meassuring the "sent bytes" of each class
using rrdtool to store the data (as kbps after conversion). I expected that
meassuring the root class I would get values similar that the ones I get
measuring the interface counters but they differ by a large amount.
Is there something obvious I'm missing here?, is this approach correct?
Thank you.
Francisco
kaori ~ # tc -s class show dev ppp0
class htb 1:1 root rate 200000bit ceil 200000bit burst 6Kb/8 mpu 0b overhead
0b cburst 1699b/8 mpu 0b overhead 0b level 7
Sent 378286130 bytes 2185057 pkt (dropped 0, overlimits 0 requeues 0)
rate 182312bit 29pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 168756 ctokens: -13270
class htb 1:10 parent 1:1 leaf 10: prio 1 rate 200000bit ceil 200000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0
Sent 115548283 bytes 1520567 pkt (dropped 0, overlimits 0 requeues 0)
rate 1848bit 4pps backlog 0b 0p requeues 0
lended: 1520567 borrowed: 0 giants: 0
tokens: 250020 ctokens: 67994
class htb 1:20 parent 1:1 leaf 20: prio 2 rate 180000bit ceil 180000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1689b/8 mpu 0b overhead 0b level 0
Sent 262755089 bytes 664505 pkt (dropped 0, overlimits 0 requeues 0)
rate 180456bit 25pps backlog 0b 15p requeues 0
lended: 664490 borrowed: 0 giants: 0
tokens: 113243 ctokens: -89463
class htb 1:30 parent 1:1 leaf 30: prio 3 rate 1000bit ceil 120000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1659b/8 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 50331648 ctokens: 113321
class htb 1:40 parent 1:1 leaf 40: prio 4 rate 1000bit ceil 60000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1629b/8 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 50331648 ctokens: 222548
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Krzysztof Halasa @ 2006-04-09 19:23 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: linux list
In-Reply-To: <44379AB8.6050808@superbug.co.uk>
James Courtier-Dutton <James@superbug.co.uk> writes:
> 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.
Interesting idea.
I think the most trivial and reliable way would be to solder some
I^2 or similar EEPROM chip to, for example, parallel port connector.
Most motherboards have an internal I^2C bus / SMBus (for reading RAM
types and for other things) and I think it could be used to connect
the EEPROM instead of external port.
There are 512 Kbit (64 KB) and 1 Mbit (128 KB) EEPROMs available -
there is plenty of space not only for crash dump but for whole dmesg.
--
Krzysztof Halasa
^ permalink raw reply
* Re: 2.6.17-rc1-mm2: badness in 3w_xxxx driver
From: Arjan van de Ven @ 2006-04-09 19:21 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Morton, Nick Orlov, linux-kernel, axboe, James.Bottomley
In-Reply-To: <44395C98.7010208@garzik.org>
> > Cc: <linuxraid@amcc.com>
> > ---
> >
> ACK.
>
> Though please make sure the active maintainer is CC'd on this... There
> is even a helpful MAINTAINERS entry for this driver.
I'd say it is ;-)
^ permalink raw reply
* Re: [OOPS] related to swap?
From: Ian Kumlien @ 2006-04-09 19:31 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linux-kernel
In-Reply-To: <44339031.4040307@yahoo.com.au>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Wed, 2006-04-05 at 19:38 +1000, Nick Piggin wrote:
> Ian Kumlien wrote:
> > As i said, i really doubt that the memory is at fault here, it has done
> > several passes over the memory but not all tests. I can give it a go
> > though, but i really doubt it'll find anything.
>
> If it doesn't cost you much time (ie. do it overnight) it could save some
> developers a lot of time.
Well, the memory passes test 1-5 and 8. The 32 bit thingies all fail on
4 dimms, so either 4 dimms are broken or the test is broken for amd64.
Anyways, i noticed that the memory clocking got skewed when all the
memory was in the machine, so i've removed 1gb of memory.
> > The kernel i run is a plain 2.6.16.1 from kernel.org (i have heard that
> > you can actually compile gentoos own these days)
>
> OK, good.
2.6.16.2 now... And a new nvidia driver...
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Brad Campbell @ 2006-04-09 19:22 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44395575.1040303@austin.rr.com>
Lonnie Mendez wrote:
> Please see the patch posted yesterday to this mailing list:
>
> http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
Ta for that.. not sure how I missed it.
Now to try and get it to work..
Sprinkling printf's around the place it inits the usb controller and mouse, registers that mouse as
the mouse handler.. then promptly registers the ps2 mouse over the top.. so it's not working in any
case. Having disabled the ps2 mouse in windows.. I need to get friendly with keyboard navigation of
the device manager again ;)
--
"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
* PRAMFS
From: Antonio Di Bacco @ 2006-04-09 19:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
anyone knows if pramfs for kernel 2.4 is stable, anyone used it? When
downloading it I saw that the date is very old (2004). I saw people using
jffs2 on pram, but I think there is a big waste of memory in using it, isn't
it? My pram is only 512KB.
Bye,
Antonio.
^ permalink raw reply
* Re: [PATCH] i386/x86-64: Return defined error value for bad PCI config space accesses
From: Jeff Garzik @ 2006-04-09 19:17 UTC (permalink / raw)
To: Andi Kleen, Andrew Morton; +Cc: Linux Kernel Mailing List
In-Reply-To: <200604091900.k39J0uVn013016@hera.kernel.org>
Linux Kernel Mailing List wrote:
> - if (!value || (bus > 255) || (devfn > 255) || (reg > 255))
> + if (!value || (bus > 255) || (devfn > 255) || (reg > 255)) {
> + *value = -1;
> return -EINVAL;
> + }
>
> spin_lock_irqsave(&pci_config_lock, flags);
>
> diff --git a/arch/i386/pci/mmconfig.c b/arch/i386/pci/mmconfig.c
> index 2002c74..f77d7f8 100644
> --- a/arch/i386/pci/mmconfig.c
> +++ b/arch/i386/pci/mmconfig.c
> @@ -80,8 +80,10 @@ static int pci_mmcfg_read(unsigned int s
> unsigned long flags;
> u32 base;
>
> - if (!value || (bus > 255) || (devfn > 255) || (reg > 4095))
> + if (!value || (bus > 255) || (devfn > 255) || (reg > 4095)) {
> + *value = -1;
> return -EINVAL;
> + }
>
> base = get_base_addr(seg, bus, devfn);
> if (!base)
> diff --git a/arch/x86_64/pci/mmconfig.c b/arch/x86_64/pci/mmconfig.c
> index d4e25f3..b493ed9 100644
> --- a/arch/x86_64/pci/mmconfig.c
> +++ b/arch/x86_64/pci/mmconfig.c
> @@ -75,8 +75,10 @@ static int pci_mmcfg_read(unsigned int s
> char __iomem *addr;
>
> /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> - if (unlikely(!value || (bus > 255) || (devfn > 255) || (reg > 4095)))
> + if (unlikely(!value || (bus > 255) || (devfn > 255) || (reg > 4095))) {
> + *value = -1;
As the code check indicates, value might be NULL.
Please fix.
Jeff
^ permalink raw reply
* Re: A failed-disk-how-to anywhere?
From: Martin Stender @ 2006-04-09 19:16 UTC (permalink / raw)
To: Mike Hardy; +Cc: Brad Campbell, linux-raid
In-Reply-To: <44394EAB.5090309@h3c.com>
I'm sorry - I replied to Brad's email a few hours ago, but I was a
bit too fast, and didn't notice I was replying to his personal account.
Here's my reply - as you can see, all is fine now! Thank you both!
(doing a '#cat /proc/mdstat', show that everything went well)
Martin
<reply>
Hello Brad
You got very close ... :-)
Thank you! I swapped the IDE-cables, and the thing booted nicely!
So from within webmin (I know ... but it's easy to use) I created
three new linux raid partitions on the new drive, and - also from
webmin - added those to the array.
Running a #top - I can see some re-syncing is going on - so I guess
everything is fine!
Big thanks!
Martin
</reply>
On 09/04/2006, at 20.12, Mike Hardy wrote:
>
> Brad Campbell wrote:
>> Martin Stender wrote:
>>
>>> Hi there!
>>>
>>> I have two identical disks sitting on a Promise dual channel IDE
>>> controller. I guess both disks are primary's then.
>>>
>>> One of the disks have failed, so I bought a new disk, took out the
>>> failed disk, and put in the new one.
>>> That might seem a little naive, and apparently it was, since the
>>> system won't boot up now.
>>> It boots fine, when only the old, healthy disk is connected.
>
>
>> My initial thought would be you have hde and hdg in a raid-1 and
>> nothing
>> on the on-board controllers. hde has failed and when you removed
>> it your
>> controller tried the 1st disk it could find (hdg) to boot of..
>> Bingo..
>> away we go.
>> You plug a new shiny disk into hde and now the controller tries to
>> boot
>> off that, except it's blank and therefore a no-go.
>>
>> I'd either try and force the controller to boot off hdg (which
>> might be
>> a controller bios option) or swap hde & hdg.. then it might boot
>> and let
>> you create your partitions on hdg and then add it back into the
>> mirror.
>
>
> I'd add another stab in the dark and guess that you didn't install
> your
> boot loader on both drives.
>
> Not that I've ever done that before (ok, a few times, most recently
> two
> days ago, sigh)
>
> Typically the BIOS will try all hard drives and so it should have
> rolled
> to one that worked, but if only the "failed" drive had the boot loader
> then you are of course not bootable.
>
> I solved this by booting rescue mode, starting up the raid arrays,
> mounting them, and manually grub installing. Here's a good page for
> the
> grub incantations:
> http://gentoo-wiki.com/
> HOWTO_Gentoo_Install_on_Software_RAID_mirror_and_LVM2_on_top_of_RAID#B
> ootloader_installation_and_configuration
>
> -Mike
>
^ permalink raw reply
* Help: Can't resume an Abit NF7 (nForce2) from S3
From: Andreas Saur @ 2006-04-09 19:15 UTC (permalink / raw)
To: linux-acpi
Dear list.
I've got three Abit NF7 (nForce2) boards here, and hope I can make S3
work for them. I've tried a lot of patches and Vanilla (and -mm)
Kernels. I've also published a bug report at Bugzilla
(http://bugzilla.kernel.org/show_bug.cgi?id=6326).
The last kernel I've tried was 2.6.17-rc1-mm2 (at the very moment the
most recent one). But nothing worked yet. My problem isn't a
non-returning VGA screen, my whole box is dead after invoking '#echo -n
mem > /sys/power/state' from the single user mode. After waking the
mashine up, the CPU-Fan and the HDD come up, but the keyboard is dead,
and all logs are empty after reset. And that is the bad part of it, I
can't offer you a logging entry, because there is none.
Question 1: How can I get some logs out of my box? ( e.g. CONFIG_DEBUG_??? )
Question 2: Is anybody out there with a working 'resume from S3' on an
Abit NF7?
Question 3: If NF7 is a notorious no go board for ACPI, could i at least
get mental assistence? ;-)
Thank's for support in advance.
Andreas
P.S.: detailled informations about my system see:
http://bugzilla.kernel.org/show_bug.cgi?id=6326
^ permalink raw reply
* Re: 2.6.17-rc1-mm2: badness in 3w_xxxx driver
From: Jeff Garzik @ 2006-04-09 19:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: Nick Orlov, linux-kernel, axboe, James.Bottomley
In-Reply-To: <20060409113240.630b9a24.akpm@osdl.org>
Andrew Morton wrote:
> Nick Orlov <bugfixer@list.ru> wrote:
>> The following patch: x86-kmap_atomic-debugging.patch exposed a badness
>> in 3w_xxx driver.
>
> Sweet, thanks.
>
>> I'm getting a lot of:
>>
>> Apr 9 13:00:04 nickolas kernel: kmap_atomic: local irqs are enabled while using KM_IRQn
>> Apr 9 13:00:04 nickolas kernel: <c0104103> show_trace+0x13/0x20 <c010412e> dump_stack+0x1e/0x20
>> Apr 9 13:00:04 nickolas kernel: <c01159c9> kmap_atomic+0x79/0xe0 <c028b885> tw_transfer_internal+0x85/0xa0
>> Apr 9 13:00:04 nickolas kernel: <c028ca7e> tw_interrupt+0x3fe/0x820 <c0143b9e> handle_IRQ_event+0x3e/0x80
>> Apr 9 13:00:04 nickolas kernel: <c0143c70> __do_IRQ+0x90/0x100 <c01057a6> do_IRQ+0x26/0x40
>> Apr 9 13:00:04 nickolas kernel: <c010396e> common_interrupt+0x1a/0x20 <c0101cdd> cpu_idle+0x4d/0xb0
>> Apr 9 13:00:04 nickolas kernel: <c010f2cc> start_secondary+0x24c/0x4b0 <00000000> 0x0
>> Apr 9 13:00:04 nickolas kernel: <c214ffb4> 0xc214ffb4
>>
>> I'm running 32 bit kernel on AMD64x2 w/ HIGHMEM enabled.
>> I think this is an old bug since the 3w_xxxx.c has not been changed for
>> a long time (at least since 2.6.16-rc1-mm4).
>>
>> Please let me know if you want me to try some patches.
>>
>
>
> From: Andrew Morton <akpm@osdl.org>
>
> We must disable local IRQs while holding KM_IRQ0 or KM_IRQ1. Otherwise, an
> IRQ handler could use those kmap slots while this code is using them,
> resulting in memory corruption.
>
> Thanks to Nick Orlov <bugfixer@list.ru> for reporting.
>
> Cc: <linuxraid@amcc.com>
> Cc: James Bottomley <James.Bottomley@SteelEye.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> drivers/scsi/3w-xxxx.c | 3 +++
> 1 files changed, 3 insertions(+)
>
> diff -puN drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix drivers/scsi/3w-xxxx.c
> --- devel/drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix 2006-04-09 11:28:08.000000000 -0700
> +++ devel-akpm/drivers/scsi/3w-xxxx.c 2006-04-09 11:29:21.000000000 -0700
> @@ -1508,10 +1508,12 @@ static void tw_transfer_internal(TW_Devi
> struct scsi_cmnd *cmd = tw_dev->srb[request_id];
> void *buf;
> unsigned int transfer_len;
> + unsigned long flags = 0;
>
> if (cmd->use_sg) {
> struct scatterlist *sg =
> (struct scatterlist *)cmd->request_buffer;
> + local_irq_save(flags);
> buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
> transfer_len = min(sg->length, len);
> } else {
> @@ -1526,6 +1528,7 @@ static void tw_transfer_internal(TW_Devi
>
> sg = (struct scatterlist *)cmd->request_buffer;
> kunmap_atomic(buf - sg->offset, KM_IRQ0);
> + local_irq_restore(flags);
ACK.
Though please make sure the active maintainer is CC'd on this... There
is even a helpful MAINTAINERS entry for this driver.
Jeff
^ permalink raw reply
* [ALSA - driver 0001944]: 0001491: Onboard sound of HP Kayak workstation isn't detected properly
From: bugtrack @ 2006-04-09 19:12 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1944>
======================================================================
Reported By: axion
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1944
Category: ISA - ad1816a
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: slackware
Kernel Version: 2.6.16
======================================================================
Date Submitted: 03-20-2006 13:56 CET
Last Modified: 04-09-2006 21:12 CEST
======================================================================
Summary: 0001491: Onboard sound of HP Kayak workstation isn't
detected properly
Description:
Detection of AD1816AJS chip contained on the board of HP Kayak workstation
(chipset i440LX) is not detected by ALSA - tested in both PnP and non-PnP
mode. With legacy OSS driver it works fine in non-PnP mode (PnP probably
doesn't work), but there's need to hard-write all parameters like io, irq,
dma and so...
======================================================================
----------------------------------------------------------------------
axion - 03-20-06 13:58
----------------------------------------------------------------------
alsa version is 1.0.11rc2 ( builtinto kernel 2.6.16 )
----------------------------------------------------------------------
axion - 04-09-06 21:12
----------------------------------------------------------------------
also tried driver version rc4
Issue History
Date Modified Username Field Change
======================================================================
03-20-06 13:56 axion New Issue
03-20-06 13:56 axion Distribution => slackware
03-20-06 13:56 axion Kernel Version => 2.6.16
03-20-06 13:58 axion Note Added: 0008720
04-09-06 21:12 axion Note Added: 0009184
======================================================================
-------------------------------------------------------
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: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Eric W. Biederman @ 2006-04-09 19:08 UTC (permalink / raw)
To: Andi Kleen; +Cc: Serge E. Hallyn, linux-kernel
In-Reply-To: <200604090800.57814.ak@suse.de>
Andi Kleen <ak@suse.de> writes:
> On Saturday 08 April 2006 22:28, Serge E. Hallyn wrote:
>
>> 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.
>
> Performance is not the only consider consideration here. Overall
> memory consumption is important too.
>
> Sure for a single namespace like utsname it won't make much difference,
> but it likely will if you have 10-20 of these things.
The highest estimate I have seen is 10, including the current
mount namespace.
Basically it looks like: mounts, uts, sysvipc, net, pid, uid.
Not very many.
Even in your worst cast estimate of 20. That puts
us at. 8*20 = 160. 160 vs 10K. or about a 1% size increase.
Not terribly noticeable.
And I think 20 - 40 bytes of increase not 160 is a lot
closer to where we will be in the short term.
>> iirc container patches have been sent before. Should those be resent,
>> then, and perhaps this patchset rebased on those?
>
> I think so.
That is premature optimization, and it ties the implementations
together. Which makes implementing this that much harder,
and we do want separate sharing of these things.
Once we have something working I don't have a problem going back
and revisiting what it takes to optimize the size of the
implementation. But while we still have correctness issues
to worry about such a small optimization before we can
even measure the benefit or have a good feel of the users
does not make sense.
If you really think this is a beneficial approach to reducing
size you can already apply it to all of the thread pointers.
Where the gain is immediately noticeable, and the count is
similar.
We will be happy to follow the best current practices.
Eric
^ permalink raw reply
* Re: [PATCH] dc395x: dynamically map scatter-gather for PIO (take 2)
From: Guennadi Liakhovetski @ 2006-04-09 19:10 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi, Sebastian Frei, Fredrik Roubert, lenehan
In-Reply-To: <Pine.LNX.4.60.0604022004520.17410@poirot.grange>
On Sun, 2 Apr 2006, Guennadi Liakhovetski wrote:
> Hello all,
>
> This time I really mean it:-)
>
> The current dc395x driver uses PIO to transfer up to 4 bytes which do not
> get transferred by DMA (under unclear circumstances). For this the driver
> uses page_address() which is broken on highmem. Apart from this the
> actual calculation of the virtual address is wrong (even without highmem).
> So, e.g., for reading it reads bytes from the driver to a wrong address
> and returns wrong data, I guess, for writing it would just output random
> data to the device.
It's been a week since the patch submission. James, Jamie, I'd really like
to hear some feedback.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH] git log [diff-tree options]...
From: Junio C Hamano @ 2006-04-09 19:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604091158310.9504@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Well, on the other hand, the new "git log --diff" should get the revision
> counting right even if it's _not_ done by the caller.
Not if the user uses --diff-filter and/or --pickaxe, and after
we start omitting the log message part when no diff is output.
> So I'd suggest:
> - drop git-whatchanged entirely
> - keep it - for historical reasons - as a internal shorthand, and just
> turn it into "git log --diff -cc"
>
> and everybody will be happy (yeah, it will show a few merge commits
> without diffs, because the diffs end up being uninteresting, but that's
> _fine_, even if it's not 100% the same thing git-whatchanged used to do)
I tend to agree. A merge commit touching a path but not
actually changing the contents of the path from parents might be
a significant event.
^ permalink raw reply
* Re: git ident
From: sean @ 2006-04-09 19:02 UTC (permalink / raw)
To: Jeremy English; +Cc: git
In-Reply-To: <44395711.7000902@jeremyenglish.org>
On Sun, 09 Apr 2006 13:48:49 -0500
Jeremy English <jhe@jeremyenglish.org> wrote:
> I keep a local project in a git archive. After the last upgrade I get a
> ident error when trying to commit. It works after I set the environment
> variables. What I don't like is that the error comes up after I have
> typed in my comment, then my comment is lost, that's frustrating. The
> other thing is I don't care if the commit is coming from a valid person,
> why require this?
Believe it is required to reduce the number of commits made in the
kernel project with incorrect attribution. To remove the need to
set environment variables, use the repo-config command to set some
defaults:
$ git repo-config user.email "you@email.com"
$ git repo-config user.name "your name"
HTH,
Sean
^ permalink raw reply
* Re: [PATCH] git log [diff-tree options]...
From: Linus Torvalds @ 2006-04-09 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqvabn8f.fsf@assigned-by-dhcp.cox.net>
On Sun, 9 Apr 2006, Junio C Hamano wrote:
>
> Also, I might have to rethink --max-count logic -- I think it is
> reasonable to skip the commit when doing limiting by diff like
> "whatchanged" does, but one thing I find suboptimal with the
> current whatchanged is that it does not count commits that are
> actually shown (it counts what the upstream rev-list feeds
> diff-tree). With the "git log --diff" based whatchanged, it
> becomes trivial to skip the revs->max_count limiting and have
> the caller count the commits it actually does something
> user-visible to, instead of counting the commits it pulled out
> of get_revision().
Well, on the other hand, the new "git log --diff" should get the revision
counting right even if it's _not_ done by the caller.
Really, the only reason "git-whatchanged" exists at all is that it used to
be originally impossible, and later on too expensive to do the commit-
limiting by pathname. With the new incremental path-limiting, the reason
for "git-whatchanged" simply goes away.
So I'd suggest:
- drop git-whatchanged entirely
- keep it - for historical reasons - as a internal shorthand, and just
turn it into "git log --diff -cc"
and everybody will be happy (yeah, it will show a few merge commits
without diffs, because the diffs end up being uninteresting, but that's
_fine_, even if it's not 100% the same thing git-whatchanged used to do)
Linus
^ permalink raw reply
* Re: git ident
From: Junio C Hamano @ 2006-04-09 19:01 UTC (permalink / raw)
To: Jeremy English; +Cc: git
In-Reply-To: <44395711.7000902@jeremyenglish.org>
Jeremy English <jhe@jeremyenglish.org> writes:
> What I don't like is that the error comes up
> after I have typed in my comment, then my comment is lost, that's
> frustrating.
Sympathizable, but presumably a new user needs to be burned only
once (set them either in $HOME/.profile or .git/config if you
want to use separate identity per project).
> .... The other thing is I don't care if the commit is coming
> from a valid person, why require this?
Because public projects like the kernel wants to prevent
otherwise good commits from a misconfigured repository to
propagate into them. We could have a separate per-repository
configuration to say "broken identity is not a problem for this
project", but if the user has to set that in the configuration,
she would be better off setting her identity there.
And making it the default not to require the identity is going
backwards. Our primary focus is to support public, multi-person,
distributed development project.
^ permalink raw reply
* RE: [Qemu-devel] Unified device model
From: Stanislav Shwartsman @ 2006-04-09 19:56 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060409160822.GA6354@jbrown.mylinuxbox.org>
Hello All,
I'll try to answer to everybody in single mail and explain my vision of
unified plugin API and why I see them essential.
Yes, I am Bochs developer, but I am more CPU expert and only learning the
devices subsystem and dynamic translation subjects so Bochs is a right place
for me ;) I am pretty understand all the Bochs code including devices and
also have some vision of highly portable and extendable simulator.
Now I'll try to explain how I see the plugin architecture and why I think it
essential.
- I am not talking about binary level plugins support and maintenance or
sources level.
- I am not talking about open source or closed source, commercial and
freeware devices for emulator, but I think the plugin architecture should
support both.
- I not think the plugin API should be C++, actually Bochs plugin API is
pure-C based. The device itself is written in C++ but it has something like
C++ -> C proxy implemented as a part of plugin API. I think here we are
agree.
- It is doesn't matter if the plugin is shared or static library, the code
size of Bochs or QEMU is so small and I don't think it is important feature
to "share" devices in memory.
The keyword is expendability. Now if you would like to write a new device
for Bochs or QEMU you cannot open a separate project on SF.net and start
development. Even if you need to add some exotic experimental device which
is not exists in real life you should interfere with simulator code.
Moreover, if you need to add this device to Bochs, QEMU and Xen you
basically have to do the work three times !
I hope I am not disclose any secret if I say that HiPEAC beginning a new
project of open source full-system simulator, something that could be
alternative to SimpleScalar and also have full-system emulation capabilities
(platform + power + performance in single box). The simulator would reuse
the devices from some existent open source emulator, Bochs or QEMU. But as
any academia model it should be highly extendable and super-modular. The
ability to add a new device to the system without touching the main
simulator kernel is a MUST.
I believe it is right direction too. Somebody could establish a new project
of developing new device and when contribute the device when it will be
done. In my opinion, it is even not important if the device written in C/C++
or any other language, if it is distributed with sources or not, under
commercial license or not. If I could download device binary, plug it in to
the simulator and get new capabilities, which were not available before -
why not ?
I could provide more and more examples, more and more advantages of this
arch and almost no disadvantages. There are a lot of successful examples of
products with extendable user plugins where functionality of the product as
a very small piece near the variety of plugins written by users.
Now the advantages of making every device separate library (shared or
static). When every device is separate library you try to build your
emulated system by yourself choosing the CPU core emulator + chipset plugin
+ devices plugins you want. If some set of plugins distributed as single
library - they are not separatable one from another. This is only a
disadvantage which could simply avoided, so again, why not ?
I am already not talking about devices maintenance. The best example is
Brendan BIOS. Brendan started a new project of writing new ACPI-compatible
BIOS for open source emulators. His BIOS require ACPI compatibility changes
in the device models and CPU emulator and Bochs already started to support
his requirements. Currently, when his BIOS will be done, QEMU will remain
behind it and not be able to run with it. Anyway, to support the
requirements the work should be done 2-3 times, from the beginning for each
simulator.
The Bochs will start from some PCI device and try to separate it from the
simulator code, compile it stand-alone and make it pluginable in run-time.
Why PCI device ? Just because it has more functionality than PC-speaker card
and require more interference with core simulator. Actually might be several
device models for core plugins (chipset, PCI bus, AGP bus), ISA/PCI cards
and COM devices, everything is open. During the separation work I hope to
figure out requirements from devices and simulator core for new plugin
architecture. In Bochs, a lot of changes required to make it happen, and we
believe we'll make it possible until next Bochs 2.3 release.
Thanks,
Stanislav
-----Original Message-----
From: qemu-devel-bounces+stl=fidonet.org.il@nongnu.org
[mailto:qemu-devel-bounces+stl=fidonet.org.il@nongnu.org] On Behalf Of Jim
C. Brown
Sent: Sunday, April 09, 2006 6:08 PM
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Unified device model
On Sun, Apr 09, 2006 at 04:21:42PM +0100, Paul Brook wrote:
> > > I'm not a fan of binary plugins (for the same reasons I'm don't like
> > > binary kernel modules), and don't think there's any real need to them.
> >
> > A binary plugin API and a source plugin API (one that requires each
driver
> > device to be recompiled for each of the platforms (Xen, qemu, bochs,
etc.)
> > would probably be equally hard to design and maintain.
>
> You've missed my point. The only reason I can see for wanting binary
plugins
> is so that people can distribute proprietary closed-source device
emulation.
I agree that proprietary or closed-source device emulation is a bad thing
and
should not be supported.
>
> A stable source API is a prerequisite for any sort of binary plugins.
>
In that case, perhaps a stable source API would be best.
Like I said before, the type of API/sharing (source vs binary API, and
static
vs shared libraries) is a separate issue from the one we are discussing
(should
we have or support a unified plugin API?).
> > > I can't see
> > > any good reasons why open source devices would need to be broken out
into
> > > a separate shared library.
> >
> > I think the case was already made for this.
> >
> > Xen's hardware emulation, while based on qemu's, is already ahead in
> > several aspects. A separate library would make it more convenient for
these
> > changes to be shared back with qemu. Or with E/OS.
>
> I don't buy that. We either share the same drivers (in which case keeping
the
> two in sync is trivial) or we don't. All of the systems under
consideration
> are [L]GPL licences. We can easily copy the source, so I don't think being
> able to copy bits of binary goo gains us anything.
A) Makes it simpler for end users to move devices over (they don't have to
know
how to cut-and-paste C code)
B) Bochs is not related to qemu at all code-wise, so the cut-and-paste
senario
doesn't work here. If we want to share drivers with Bochs we'd need at least
a
source API. (The starter of this thread is a Bochs developer I believe...
but correct me if I'm wrong here. :) The alternative is to rewrite Bochs
drivers for qemu from scratch (possbly using the Bochs code as a guide) but
that is even harder than the qemu-xen case.
C) If they are in a special library (say maintained by a 3rd party group
that
consists of developers from all the major projects) then maintainance is
greatly
simplified over time.
>
> I don't think executable size is a valid argument either. Device emulation
> code generally isn't that big so the overhead of breaking it up into
multiple
> shared libraries would outweigh the benefits of not loading the bits
you're
> not using.
Perhaps you are right about that. The size of having even 4 or 5 copies of
complete PC hardware emulation code isn't so large as to be a problem except
on systems that are either embedded or ancient (in which case you probably
have
no business running 4 different PC emulators anyways).
Personally, it just seems inelegant to have such code duplication.
>
> Paul
>
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply
* git ident
From: Jeremy English @ 2006-04-09 18:48 UTC (permalink / raw)
To: git
I keep a local project in a git archive. After the last upgrade I get a
ident error when trying to commit. It works after I set the environment
variables. What I don't like is that the error comes up after I have
typed in my comment, then my comment is lost, that's frustrating. The
other thing is I don't care if the commit is coming from a valid person,
why require this?
^ permalink raw reply
* Re: [PATCH] git log [diff-tree options]...
From: Junio C Hamano @ 2006-04-09 18:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604090950590.9504@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I wonder... This all looks fine, but there are actually two different
> "diffs" that can be shown for "git log --diff <pathlimiter>":
>
> - the whole diff for a commit
> - the path-limited diff
Yes, exactly the same way sometimes you would want just pickaxe,
sometimes you would want it with --pickaxe-all.
Also, I might have to rethink --max-count logic -- I think it is
reasonable to skip the commit when doing limiting by diff like
"whatchanged" does, but one thing I find suboptimal with the
current whatchanged is that it does not count commits that are
actually shown (it counts what the upstream rev-list feeds
diff-tree). With the "git log --diff" based whatchanged, it
becomes trivial to skip the revs->max_count limiting and have
the caller count the commits it actually does something
user-visible to, instead of counting the commits it pulled out
of get_revision().
BTW I think I could remove the log message generation part of
"git log" and have it use the one in log-tree (which I will
probably rewrite not to format the message into the static
this_header[] buffer when it is not shown).
Another thing that might be useful is to teach diff-* to do the
diffstat part internally. After that is in place we could
introduce --pretty=patch to have "git log" produce format-patch
compatible output.
^ permalink raw reply
* [LARTC] Conntrack, nat and multipath - what is wrong here?
From: Erik S. Johansen @ 2006-04-09 18:42 UTC (permalink / raw)
To: lartc
[-- Attachment #1.1: Type: text/plain, Size: 34035 bytes --]
I have a gentoo 2.6.14 box with 4 nics, LAN/DMZ/PUB1/PUB2
LAN and DMZ have a 1918 /22 each, PUB1 and PUB2 have a /29 each of which 5 ips
are assigned.
Using the mangle table, I give all packets a mark (according to local
policies) in the range 1-10. Using ip rule, i pass marks 1-5 through the pub1
route table, and marks 6-10 through the pub2 routing table. Using the nat
table, I SNAT to one of the 10 IPs assigned from the two /29's.
1) Now, if i remove the default route (via PUB1 gw) from the main table,
everything halts. Why?
2) If I pass a forwarded tcp syn packet out on the PUB2 interface, with the
correct SNAT ip, I can see the syn+ack returning from the external server.
Logging then indicates that this packet gets passed through
mangle/PREROUTING, after which it appears to simply be lost. It's definitely
not going out on any of the 4 NICs. This contrasts with packets being passed
out on PUB1, where everything works fine, conntrack recognizes the syn+ack
and the reply gets correctly forwarded to the LAN box i'm using to test. It
*seems* like conntrack simply is not able to match the incoming syn+ack with
the outgoing syn. BUT, if i try to connect to the dsl router on PUB2,
everything's fine. I suspect i got something very wrong with my routing
rules/tables, but I can't figure out what.
Addresses shown are sanitized, 1.1.1.136/29 is PUB1, 2.2.2.116/29 is PUB2,
3.3.3.* is the external server i've been testing against.
eth0: LAN
eth1: DMZ
eth2: PUB2
eth3: PUB1
eos ~ # ip rule show
0: from all lookup local
30000: from all fwmark 0x1 lookup pub1
30000: from all fwmark 0x2 lookup pub1
30000: from all fwmark 0x3 lookup pub1
30000: from all fwmark 0x4 lookup pub1
30000: from all fwmark 0x5 lookup pub1
30000: from all fwmark 0x6 lookup pub2
30000: from all fwmark 0x7 lookup pub2
30000: from all fwmark 0x8 lookup pub2
30000: from all fwmark 0x9 lookup pub2
30000: from all fwmark 0xa lookup pub2
31000: from 1.1.1.139 lookup pub1
31000: from 1.1.1.140 lookup pub1
31000: from 1.1.1.141 lookup pub1
31000: from 1.1.1.142 lookup pub1
31000: from 1.1.1.137 lookup pub1
31000: from 2.2.2.218 lookup pub2
31000: from 2.2.2.219 lookup pub2
31000: from 2.2.2.220 lookup pub2
31000: from 2.2.2.221 lookup pub2
31000: from 2.2.2.222 lookup pub2
33000: from all lookup main
eos ~ # ip route show table pub1
1.1.1.136/29 dev eth3 scope link src 1.1.1.139
2.2.2.216/29 dev eth2 scope link src 2.2.2.218
192.168.4.0/22 dev eth1 scope link src 192.168.4.1
192.168.0.0/22 dev eth0 scope link src 192.168.0.1
127.0.0.0/8 dev lo scope link
default via 1.1.1.138 dev eth3
eos ~ # ip route show table pub2
1.1.1.136/29 dev eth3 scope link src 1.1.1.139
2.2.2.216/29 dev eth2 scope link src 2.2.2.218
192.168.4.0/22 dev eth1 scope link src 192.168.4.1
192.168.0.0/22 dev eth0 scope link src 192.168.0.1
127.0.0.0/8 dev lo scope link
default via 2.2.2.217 dev eth2
eos ~ # ip route show table main
1.1.1.136/29 dev eth3 proto kernel scope link src 1.1.1.139
2.2.2.216/29 dev eth2 proto kernel scope link src 2.2.2.218
192.168.4.0/22 dev eth1 proto kernel scope link src 192.168.4.1
192.168.0.0/22 dev eth0 proto kernel scope link src 192.168.0.1
127.0.0.0/8 dev lo scope link
default via 1.1.1.138 dev eth3
eos ~ # iptables -t filter -nvL
Chain INPUT (policy ACCEPT 5314 packets, 2615K bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `filter/INPUT:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `filter/INPUT:'
Chain FORWARD (policy ACCEPT 184K packets, 162M bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `filter/FORWARD:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `filter/FORWARD:'
Chain OUTPUT (policy ACCEPT 2261 packets, 277K bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `filter/OUTPUT:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `filter/OUTPUT:'
eos ~ # iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 188K packets, 165M bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/PREROUTING:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/PREROUTING:'
2 468 MARK14 all -- * * 0.0.0.0/0
192.168.4.0/22 state NEW
2903 2444K MARK13 all -- * * 0.0.0.0/0
192.168.0.0/22 state NEW
60 6098 MARK12 all -- * * 0.0.0.0/0
1.1.1.136/29 state NEW
1692 136K MARK11 all -- * * 0.0.0.0/0
2.2.2.216/29 state NEW
0 0 MARK6 tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 state NEW
109 5232 MARK6 tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0
tcp dpt:119 state NEW
54 2592 MARK6 tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0
tcp dpt:119 state NEW
0 0 MARK2 all -- * * 192.168.1.20
213.239.111.0/29 state NEW
3223 243K MARK10 all -- eth1 * 0.0.0.0/0 0.0.0.0/0
state NEW
1054 66052 MARK1 all -- eth0 * 0.0.0.0/0 0.0.0.0/0
state NEW
Chain INPUT (policy ACCEPT 5409 packets, 2648K bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/INPUT:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/INPUT:'
Chain FORWARD (policy ACCEPT 188K packets, 165M bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/FORWARD:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/FORWARD:'
Chain OUTPUT (policy ACCEPT 2302 packets, 283K bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/OUTPUT:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/OUTPUT:'
Chain POSTROUTING (policy ACCEPT 190K packets, 165M bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/POSTROUTING:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/POSTROUTING:'
Chain MARK1 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK1:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK1:'
1054 66052 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x1
1054 66052 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK10 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK10:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK10:'
3223 243K MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0xa
3223 243K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK11 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK11:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK11:'
1692 136K MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0xb
1692 136K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK12 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK12:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK12:'
60 6098 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0xc
60 6098 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK13 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK13:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK13:'
2903 2444K MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0xd
2903 2444K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK14 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK14:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK14:'
2 468 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0xe
2 468 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK2 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK2:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK2:'
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x2
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK3 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK3:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK3:'
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x3
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK4 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK4:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK4:'
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x4
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK5 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK5:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK5:'
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x5
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK6 (3 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK6:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK6:'
163 7824 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x6
163 7824 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK7 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK7:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK7:'
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x7
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK8 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK8:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK8:'
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x8
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain MARK9 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `mangle/MARK9:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `mangle/MARK9:'
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x9
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
eos ~ # iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 5623 packets, 453K bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/PREROUTING:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/PREROUTING:'
Chain POSTROUTING (policy ACCEPT 10 packets, 607 bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/POSTROUTING:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/POSTROUTING:'
1053 66000 SNAT_1 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x1
0 0 SNAT_2 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x2
0 0 SNAT_3 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x3
0 0 SNAT_4 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x4
0 0 SNAT_5 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x5
168 8064 SNAT_6 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x6
0 0 SNAT_7 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x7
0 0 SNAT_8 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x8
0 0 SNAT_9 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0x9
2606 211K SNAT_10 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0xa
0 0 SNAT_11 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0xb
0 0 SNAT_12 all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match 0xc
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/OUTPUT:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/OUTPUT:'
Chain SNAT_1 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_1:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_1:'
1053 66000 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:1.1.1.139
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_10 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_10:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_10:'
2606 211K SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:2.2.2.222
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_11 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_11:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_11:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:2.2.2.218
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_12 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_12:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_12:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:1.1.1.139
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_13 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_13:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_13:'
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_14 (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_14:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_14:'
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_2 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_2:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_2:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:1.1.1.140
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_3 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_3:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_3:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:1.1.1.141
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_4 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_4:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_4:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:1.1.1.142
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_5 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_5:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_5:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:1.1.1.137
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_6 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_6:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_6:'
168 8064 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:2.2.2.218
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_7 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_7:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_7:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:2.2.2.219
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_8 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_8:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_8:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:2.2.2.220
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain SNAT_9 (1 references)
pkts bytes target prot opt in out source
destination
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:25 LOG flags 0 level 4 prefix `nat/SNAT_9:'
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:25 LOG flags 0 level 4 prefix `nat/SNAT_9:'
0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0
to:2.2.2.221
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Logging/tcpdump from an attempt to connect to port 25 on a remote server:
Apr 9 21:55:47 eos mangle/PREROUTING:IN=eth0 OUT=
MAC=00:40:f4:6b:6c:c1:00:01:02:1c:6f:29:08:00 SRC=192.168.1.20 DST=3.3.3.228
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=41341 DF PROTO=TCP SPT=53218 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:47 eos mangle/MARK6:IN=eth0 OUT=
MAC=00:40:f4:6b:6c:c1:00:01:02:1c:6f:29:08:00 SRC=192.168.1.20 DST=3.3.3.228
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=41341 DF PROTO=TCP SPT=53218 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:47 eos nat/PREROUTING:IN=eth0 OUT=
MAC=00:40:f4:6b:6c:c1:00:01:02:1c:6f:29:08:00 SRC=192.168.1.20 DST=3.3.3.228
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=41341 DF PROTO=TCP SPT=53218 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:47 eos mangle/FORWARD:IN=eth0 OUT=eth2 SRC=192.168.1.20
DST=3.3.3.228 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=41341 DF PROTO=TCP
SPT=53218 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:47 eos filter/FORWARD:IN=eth0 OUT=eth2 SRC=192.168.1.20
DST=3.3.3.228 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=41341 DF PROTO=TCP
SPT=53218 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:47 eos mangle/POSTROUTING:IN= OUT=eth2 SRC=192.168.1.20
DST=3.3.3.228 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=41341 DF PROTO=TCP
SPT=53218 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:47 eos nat/POSTROUTING:IN= OUT=eth2 SRC=192.168.1.20
DST=3.3.3.228 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=41341 DF PROTO=TCP
SPT=53218 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:47 eos nat/SNAT_6:IN= OUT=eth2 SRC=192.168.1.20 DST=3.3.3.228
LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=41341 DF PROTO=TCP SPT=53218 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:55:48 eos mangle/PREROUTING:IN=eth2 OUT=
MAC=00:08:a1:90:aa:a1:00:14:7f:03:e5:1c:08:00 SRC=3.3.3.228 DST=2.2.2.218
LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=25 DPT=53218
WINDOW=5792 RES=0x00 ACK SYN URGP=0
Apr 9 21:55:52 eos mangle/PREROUTING:IN=eth2 OUT=
MAC=00:08:a1:90:aa:a1:00:14:7f:03:e5:1c:08:00 SRC=3.3.3.228 DST=2.2.2.218
LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=25 DPT=53218
WINDOW=5792 RES=0x00 ACK SYN URGP=0
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
21:55:47.998524 IP (tos 0x10, ttl 63, id 41341, offset 0, flags [DF], proto:
TCP (6), length: 60) 2.2.2.218.53218 > 3.3.3.228.25: S, cksum 0x6efb
(correct), 2404082705:2404082705(0) win 5840 <mss 1460,sackOK,timestamp
2365113708 0,nop,wscale 2>
21:55:48.179397 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: TCP
(6), length: 60) 3.3.3.228.25 > 2.2.2.218.53218: S, cksum 0x0b36 (correct),
58918797:58918797(0) ack 2404082706 win 5792 <mss 1452,sackOK,timestamp
1736175970 2365113708,nop,wscale 0>
21:55:52.175813 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: TCP
(6), length: 60) 3.3.3.228.25 > 2.2.2.218.53218: S, cksum 0xfb9a (correct),
58918797:58918797(0) ack 2404082706 win 5792 <mss 1452,sackOK,timestamp
1736179965 2365113708,nop,wscale 0>
21:55:58.175073 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: TCP
(6), length: 60) 3.3.3.228.25 > 2.2.2.218.53218: S, cksum 0xe42a (correct),
58918797:58918797(0) ack 2404082706 win 5792 <mss 1452,sackOK,timestamp
1736185965 2365113708,nop,wscale 0>
21:55:58.775150 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: TCP
(6), length: 60) 3.3.3.228.25 > 2.2.2.218.53217: S, cksum 0xc92d (correct),
4258850729:4258850729(0) ack 2314333557 win 5792 <mss 1452,sackOK,timestamp
1736186565 2365030295,nop,wscale 0>
21:56:10.177052 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: TCP
(6), length: 60) 3.3.3.228.25 > 2.2.2.218.53218: S, cksum 0xb54a (correct),
58918797:58918797(0) ack 2404082706 win 5792 <mss 1452,sackOK,timestamp
1736197965 2365113708,nop,wscale 0>
Logging/tcpdump from an attempt to connect to port 25 on the PUB2 dsl router,
this works:
Apr 9 21:56:52 eos mangle/PREROUTING:IN=eth0 OUT=
MAC=00:40:f4:6b:6c:c1:00:01:02:1c:6f:29:08:00 SRC=192.168.1.20 DST=2.2.2.217
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=34524 DF PROTO=TCP SPT=55398 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos mangle/MARK11:IN=eth0 OUT=
MAC=00:40:f4:6b:6c:c1:00:01:02:1c:6f:29:08:00 SRC=192.168.1.20 DST=2.2.2.217
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=34524 DF PROTO=TCP SPT=55398 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos nat/PREROUTING:IN=eth0 OUT=
MAC=00:40:f4:6b:6c:c1:00:01:02:1c:6f:29:08:00 SRC=192.168.1.20 DST=2.2.2.217
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=34524 DF PROTO=TCP SPT=55398 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos mangle/FORWARD:IN=eth0 OUT=eth2 SRC=192.168.1.20
DST=2.2.2.217 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=34524 DF PROTO=TCP
SPT=55398 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos filter/FORWARD:IN=eth0 OUT=eth2 SRC=192.168.1.20
DST=2.2.2.217 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=34524 DF PROTO=TCP
SPT=55398 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos mangle/POSTROUTING:IN= OUT=eth2 SRC=192.168.1.20
DST=2.2.2.217 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=34524 DF PROTO=TCP
SPT=55398 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos nat/POSTROUTING:IN= OUT=eth2 SRC=192.168.1.20
DST=2.2.2.217 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=34524 DF PROTO=TCP
SPT=55398 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos nat/SNAT_11:IN= OUT=eth2 SRC=192.168.1.20 DST=2.2.2.217
LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=34524 DF PROTO=TCP SPT=55398 DPT=25
WINDOW=5840 RES=0x00 SYN URGP=0
Apr 9 21:56:52 eos mangle/PREROUTING:IN=eth2 OUT=
MAC=00:08:a1:90:aa:a1:00:14:7f:03:e5:1c:08:00 SRC=2.2.2.217 DST=2.2.2.218
LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=46172 PROTO=TCP SPT=25 DPT=55398 WINDOW=0
RES=0x00 ACK RST URGP=0
Apr 9 21:56:52 eos mangle/FORWARD:IN=eth2 OUT=eth0 SRC=2.2.2.217
DST=192.168.1.20 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=46172 PROTO=TCP SPT=25
DPT=55398 WINDOW=0 RES=0x00 ACK RST URGP=0
Apr 9 21:56:52 eos filter/FORWARD:IN=eth2 OUT=eth0 SRC=2.2.2.217
DST=192.168.1.20 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=46172 PROTO=TCP SPT=25
DPT=55398 WINDOW=0 RES=0x00 ACK RST URGP=0
Apr 9 21:56:52 eos mangle/POSTROUTING:IN= OUT=eth0 SRC=2.2.2.217
DST=192.168.1.20 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=46172 PROTO=TCP SPT=25
DPT=55398 WINDOW=0 RES=0x00 ACK RST URGP=0
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
21:56:52.306357 IP (tos 0x10, ttl 63, id 34524, offset 0, flags [DF], proto:
TCP (6), length: 60) 2.2.2.218.55398 > 2.2.2.217.25: S, cksum 0xaa49
(correct), 2474919495:2474919495(0) win 5840 <mss 1460,sackOK,timestamp
2365178011 0,nop,wscale 2>
21:56:52.306836 IP (tos 0x0, ttl 64, id 46172, offset 0, flags [none], proto:
TCP (6), length: 40) 2.2.2.217.25 > 2.2.2.218.55398: R, cksum 0x7679
(correct), 0:0(0) ack 2474919496 win 0
21:57:22.589506 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: TCP
(6), length: 60) 3.3.3.228.25 > 2.2.2.218.53218: S, cksum 0x9a78 (correct),
58918797:58918797(0) ack 2404082706 win 5792 <mss 1452,sackOK,timestamp
1736270366 2365113708,nop,wscale 0>
--E.S. Johansen
[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Lonnie Mendez @ 2006-04-09 18:41 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443953D7.3060109@wasp.net.au>
Brad Campbell wrote:
> Leonardo E. Reiter wrote:
>
>> This is by no means a complete patch (do not apply it as it will
>> break usb-hid.c), but it adjusts the report descriptor in usb-hid.c
>> to provide position in 16-bits, and in absolute coordinates:
>>
>> Index: usb-hid.c
>> ===================================================================
>> RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
>> retrieving revision 1.1
>> diff -a -u -r1.1 usb-hid.c
>> --- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1
>> +++ usb-hid.c 8 Apr 2006 20:56:02 -0000
>> @@ -117,7 +117,7 @@
>> 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
>> 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
>> 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
>> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
>> + 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02,
>> 0xC0, 0xC0,
>> };
>>
>> According to:
>> http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1
>>
>
>
> I can't get the existing usb-hid mouse to work in win2k. It sees a
> device but it marks it as non-functional. After wrapping my head
> around this descriptor I can't really seem to reconcile what is here
> with the data we are passing in usb_mouse_poll()
>
> I'm sure it works with a linux guest.. has anyone had -usb -usbdevice
> mouse working under windows ?
>
> This descriptor seems slightly whacky compared to most mouse examples
> I've seen floating about on the net.
Please see the patch posted yesterday to this mailing list:
http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
^ permalink raw reply
* Re: [2.6 patch] dvb/bt8xx/bt878.c: don't export static variables
From: Manu Abraham @ 2006-04-09 18:41 UTC (permalink / raw)
To: Adrian Bunk; +Cc: v4l-dvb-maintainer, linux-kernel
In-Reply-To: <20060409174846.GJ8454@stusta.de>
Adrian Bunk wrote:
> Static variables mustn't be EXPORT_SYMBOL'ed.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> drivers/media/dvb/bt8xx/bt878.c | 2 --
> 1 file changed, 2 deletions(-)
>
> --- linux-2.6.17-rc1-mm2-full/drivers/media/dvb/bt8xx/bt878.c.old 2006-04-09 18:43:28.000000000 +0200
> +++ linux-2.6.17-rc1-mm2-full/drivers/media/dvb/bt8xx/bt878.c 2006-04-09 18:44:26.000000000 +0200
> @@ -54,26 +54,24 @@
> static unsigned int bt878_verbose = 1;
> static unsigned int bt878_debug;
>
> module_param_named(verbose, bt878_verbose, int, 0444);
> MODULE_PARM_DESC(verbose,
> "verbose startup messages, default is 1 (yes)");
> module_param_named(debug, bt878_debug, int, 0644);
> MODULE_PARM_DESC(debug, "Turn on/off debugging, default is 0 (off).");
>
> int bt878_num;
> struct bt878 bt878[BT878_MAX];
>
> -EXPORT_SYMBOL(bt878_debug);
> -EXPORT_SYMBOL(bt878_verbose);
> EXPORT_SYMBOL(bt878_num);
> EXPORT_SYMBOL(bt878);
>
> #define btwrite(dat,adr) bmtwrite((dat), (bt->bt878_mem+(adr)))
> #define btread(adr) bmtread(bt->bt878_mem+(adr))
>
> #define btand(dat,adr) btwrite((dat) & btread(adr), adr)
> #define btor(dat,adr) btwrite((dat) | btread(adr), adr)
> #define btaor(dat,mask,adr) btwrite((dat) | ((mask) & btread(adr)), adr)
>
> #if defined(dprintk)
> #undef dprintk
>
> -
>
Ack'd-by: Manu Abraham <manu@linuxtv.org>
^ permalink raw reply
* Re: patches for fsample/850
From: tony @ 2006-04-09 18:36 UTC (permalink / raw)
To: Brian Swetland; +Cc: linux-omap-open-source
In-Reply-To: <20060408154425.GA24843@localhost.localdomain>
Hi,
Few comments below.
* Brian Swetland <swetland@google.com> [060408 08:45]:
> --- linux-omap-2.6/arch/arm/mach-omap1/clock.h 2006-04-05 10:33:20.000000000 -0700
> +++ linux-omap-fsample/arch/arm/mach-omap1/clock.h 2006-04-06 13:15:34.000000000 -0700
> @@ -101,44 +101,50 @@
> /*-------------------------------------------------------------------------
> * Omap1 MPU rate table
> *-------------------------------------------------------------------------*/
> +#if defined(CONFIG_ARCH_OMAP730)
> + #define CKCTL_RESERVED_1_MASK (0x2000)
> +#else
> + #define CKCTL_RESERVED_1_MASK (0x0000)
> +#endif
This addds yet another extra hurdle compiling 730 in with 15xx and 16xx.
Although we cannot do it because of the interrupt handler, maybe we'll
fix that someday. So let's try not to add more hurdles if we can avoid
it.
How about doing the masking when the CKCTL value is written based on the
cpu_is_omap730()?
> --- linux-omap-2.6/arch/arm/mach-omap1/pm.c 2006-04-05 10:33:20.000000000 -0700
> +++ linux-omap-fsample/arch/arm/mach-omap1/pm.c 2006-04-06 13:15:34.000000000 -0700
> @@ -326,8 +326,10 @@
> /* stop DSP */
> omap_writew(omap_readw(ARM_RSTCT1) & ~(1 << DSP_EN), ARM_RSTCT1);
>
> +#if !defined(CONFIG_ARCH_OMAP730)
> /* shut down dsp_ck */
> omap_writew(omap_readw(ARM_CKCTL) & ~(1 << EN_DSPCK), ARM_CKCTL);
> +#endif
This too would be better with if (!cpu_is_omap730()).
> @@ -189,8 +197,6 @@
> omap_writel(value, OMAP730_IO_CONF_4);
>
> omap_uwire_configure_mode(0,16);
> -
> - omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISOFF, 9, 0,NULL,1);
> omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_SLPIN, 9, 0,NULL,1);
> omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISNOR, 9, 0,NULL,1);
> omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_GSSET, 9, 0,NULL,1);
Is the removal of one of the omap_uwire_data_transfer() calls intended?
Then does it compile and boot for p2 and fsample both selected?
Also, could you please do one patch for the core support, and then
another patch for files that don't touch the omap core files?
That way we can send you patch directly upstream when we merge next
time. Otherwise I have to redo the patch to strip out the drivers when
we merge as not many omap drivers are yet merged with the mainline tree.
Core files being arch/arm/*omap* and include/asm-arm/arch-omap:
arch/arm/mach-omap1/Kconfig
arch/arm/mach-omap1/Makefile
arch/arm/mach-omap1/board-fsample.c
arch/arm/mach-omap1/clock.c
arch/arm/mach-omap1/clock.h
arch/arm/mach-omap1/pm.c
arch/arm/mach-omap1/time.c
arch/arm/plat-omap/devices.c
include/asm-arm/arch-omap/board-fsample.h
include/asm-arm/arch-omap/hardware.h
Regards,
Tony
^ permalink raw reply
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.