* Re: Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)
From: Ewan Mellor @ 2006-04-05 15:47 UTC (permalink / raw)
To: John D. Ramsdell; +Cc: xen-devel
In-Reply-To: <ogt8xqk2fzc.fsf@divan.mitre.org>
On Wed, Apr 05, 2006 at 11:34:47AM -0400, John D. Ramsdell wrote:
> Furthermore, a use of "xm top" asks me to report a bug to this list.
Could you open a bug in Bugzilla, please, and run xen-bugtool to attach your
logs to it?
Thanks,
Ewan.
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Al Viro @ 2006-04-05 15:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <9e4733910604050843h3f6d0cdai8bfa3888b645c9b3@mail.gmail.com>
On Wed, Apr 05, 2006 at 11:43:15AM -0400, Jon Smirl wrote:
> > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
^^^^^^^^^^^^^^^^^
> > of your own? ~20 lines for all of it, not counting #include...
>
> Sysfs attributes allow full read/write on their file handles. But
^^^^^^^^^^^^^^^^
> GregKH has been discouraging that.
^ permalink raw reply
* 2.6.17-rc1 perfmon2 new code base + libpfm available
From: Stephane Eranian @ 2006-04-05 15:43 UTC (permalink / raw)
To: perfmon; +Cc: linux-ia64, linux-kernel, oprofile-list, perfctr-devel
Hello,
I have released another version of the perfmon new code base package.
This release is relative to 2.6.17-rc1
There were, once again, new system calls added. As such a new libpfm is
necessary.
This new kernel patch includes several changes:
- Merged i386 and x86_64 perfmon.c architecture specific codes
- Merged PMU description modules for em64t and p4.
- support for automatic loading of PMU description modules if
CONFIG_KMOD=y. Make sure you run make modules_install
- MIPS patches are back and are applied onto the mainline kernel
This release uses the new/mod patch breakdown for all architectures.
To apply, you can simply do:
cat ../perfmon-new-base-060405/*.diff | patch -p1
The new version of the library, libpfm, includes the following changes:
- updated to match 2.6.17-rc1 new system call numbers
- modified pfmlib.h to use 64-bit integer for generic PMC register
(submitted by Kevin Corry from IBM)
I have finally created a minimal home page for the project. So now
you can access the latest news and files from:
http://perfmon2.sf.net
I received notification from SF.net, that the libpfm package has been installed
into our CVS repository. It should become visible fairly quickly now. Once this
happens, I will update the tree to include this new version of the library.
Enjoy,
--
-Stephane
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Jon Smirl @ 2006-04-05 15:43 UTC (permalink / raw)
To: Al Viro; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <20060405153957.GI27946@ftp.linux.org.uk>
On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 11:38:06AM -0400, Jon Smirl wrote:
> > On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > > This will break the "color_map" sysfs file for framebuffers -
> > > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > > for a colormap with 256 entries. In fact, the original patch which
> > > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> > >
> > > ... cheerfully assuming that nobody assumes NUL-termination and
> > > everyone (sysfs patch writers!) certainly uses the length argument.
> > > Fscking brilliant, that.
> > >
> > > Are you willing to audit all sysfs ->show() in the kernel? Original
> > > author of that turd had not been.
> > >
> > > FWIW, "color_map" is a blatant abuse of interface. Doesn't get
> > > any more borderline...
> >
> > The firmware interface is worse. You write the ROM image line by line
> > to the attribute and a hidden counter tracks how far your are into the
> > image.
> >
> > There needs to be a standardized way to transfer larger pieces of data
> > via sysfs or we should go back to IOCTLs.
>
> How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
> of your own? ~20 lines for all of it, not counting #include...
Sysfs attributes allow full read/write on their file handles. But
GregKH has been discouraging that.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: hald and kded in status D with 2.6.16{-rc[456],,.1}
From: Hesse, Christian @ 2006-04-05 15:31 UTC (permalink / raw)
To: linux-acpi
In-Reply-To: <200604040855.22085.mail@earthworm.de>
[-- Attachment #1: Type: text/plain, Size: 4006 bytes --]
On Tuesday 04 April 2006 08:55, Hesse, Christian wrote:
> Hello everybody,
>
> hald and kded sometimes are in status D after supend. This is independent
> from whether I use the in kernel implementation or suspend2.
>
> Nothing is written to the logs, but I generated a trace with this command:
> $ echo t > /proc/sysrq-trigger; dmesg -s 1000000 > foo
> here's the result:
>
> hald D E0B50480 0 7791 1 7797 10654 7609 (NOTLB)
> cc6cbccc e0b50480 000f4428 e0b50480 000f4428 c6c9605c c14dce00 c14dce00
> e0b50480 000f4428 cc3df530 dff6e5c0 cc3df530 00000296 dff6e5c8
> c046f202 00000001 cc3df530 c0115680 d7ea1ce0 dff6e5c8 00000003 00000001
> 00000000 Call Trace:
> [<c046f202>] __down+0x62/0xc0
> [<c0115680>] default_wake_function+0x0/0x20
> [<c046dd3f>] __down_failed+0x7/0xc
> [<c0288bbf>] .text.lock.osl+0x13/0x3c
> [<c0292678>] acpi_ex_system_wait_semaphore+0x34/0x48
> [<c028d5da>] acpi_ev_acquire_global_lock+0x67/0x6c
> [<c0293fdc>] acpi_ex_acquire_global_lock+0x14/0x3b
> [<c028f578>] acpi_ex_read_data_from_field+0x114/0x14b
> [<c029475b>] acpi_ex_resolve_node_to_value+0x123/0x1ac
> [<c028fdc2>] acpi_ex_resolve_to_value+0x5e/0x69
> [<c02923df>] acpi_ex_resolve_operands+0x277/0x4dc
> [<c028a4fd>] acpi_ds_exec_end_op+0xab/0x36e
> [<c0298fe6>] acpi_ps_parse_loop+0x5ba/0x8bc
> [<c0298881>] acpi_ps_parse_aml+0x4e/0x1f9
> [<c02998fb>] acpi_ps_execute_pass+0x72/0x83
> [<c0299824>] acpi_ps_execute_method+0x54/0x7d
> [<c0296c5f>] acpi_ns_execute_control_method+0x5a/0x67
> [<c0296bee>] acpi_ns_evaluate_by_handle+0x73/0x8a
> [<c0296aee>] acpi_ns_evaluate_relative+0xaa/0xc6
> [<c0296375>] acpi_evaluate_object+0x139/0x1fb
> [<c024e2e2>] copy_to_user+0x42/0x60
> [<c02a0107>] acpi_battery_get_status+0x6b/0x11c
> [<c02a056b>] acpi_battery_read_state+0x52/0x185
> [<c01832d8>] seq_read+0xe8/0x2f0
> [<c0162dba>] vfs_read+0xaa/0x1a0
> [<c01631d1>] sys_read+0x51/0x80
> [<c0102b5f>] sysenter_past_esp+0x54/0x75
>
> Any chance to get this fixed?
> Please cc me if you answer as I'm not subscribed to the list.
If I disable CONFIG_ACPI_BATTERY in kernel config only hald hangs in status D
and kded keeps working normally. Here is hald's new trace:
hald D 51220800 0 7430 1 7435 7781 7356 (NOTLB)
db12fcd0 51220800 000f4396 51220800 000f4396 c10a0a40 00000000 c01914a9
51220800 000f4396 db0ee030 dff6e5c0 db0ee030 00200292 dff6e5c8 c0477572
00000001 db0ee030 c0115520 dff6e5c8 dff6e5c8 00000003 00000001 00000000
Call Trace:
[<c01914a9>] proc_alloc_inode+0x49/0x70
[<c0477572>] __down+0x62/0xc0
[<c0115520>] default_wake_function+0x0/0x20
[<c047609f>] __down_failed+0x7/0xc
[<c029241f>] .text.lock.osl+0x13/0x3c
[<c029bed8>] acpi_ex_system_wait_semaphore+0x34/0x48
[<c0296e3a>] acpi_ev_acquire_global_lock+0x67/0x6c
[<c029d83c>] acpi_ex_acquire_global_lock+0x14/0x3b
[<c0298dd8>] acpi_ex_read_data_from_field+0x114/0x14b
[<c029dfbb>] acpi_ex_resolve_node_to_value+0x123/0x1ac
[<c0299622>] acpi_ex_resolve_to_value+0x5e/0x69
[<c029bc3f>] acpi_ex_resolve_operands+0x277/0x4dc
[<c0293d5d>] acpi_ds_exec_end_op+0xab/0x36e
[<c02a2846>] acpi_ps_parse_loop+0x5ba/0x8bc
[<c02a20e1>] acpi_ps_parse_aml+0x4e/0x1f9
[<c02a315b>] acpi_ps_execute_pass+0x72/0x83
[<c02a3084>] acpi_ps_execute_method+0x54/0x7d
[<c02a04bf>] acpi_ns_execute_control_method+0x5a/0x67
[<c02a044e>] acpi_ns_evaluate_by_handle+0x73/0x8a
[<c02a034e>] acpi_ns_evaluate_relative+0xaa/0xc6
[<c029fbd5>] acpi_evaluate_object+0x139/0x1fb
[<c01845ab>] single_open+0x5b/0xa0
[<c024f002>] copy_to_user+0x42/0x60
[<c0292704>] acpi_evaluate_integer+0x70/0x96
[<c02a9530>] acpi_ac_get_state+0x20/0x39
[<c02a955c>] acpi_ac_seq_show+0x13/0x58
[<c0183dc8>] seq_read+0xe8/0x2f0
[<c016379a>] vfs_read+0xaa/0x1a0
[<c0163bb1>] sys_read+0x51/0x80
[<c0102b5f>] sysenter_past_esp+0x54/0x75
BTW, this is a Samsung X10 1.4GHz.
--
Regards,
Christian
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] [IPSEC] Avoid null pointer dereference in xfrm4_rcv_encap
From: Dave Kleikamp @ 2006-04-05 15:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <1144249178.10340.5.camel@kleikamp.austin.ibm.com>
Never mind. Somehow I missed Herbert's patch for this in the netdev
archives.
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Al Viro @ 2006-04-05 15:39 UTC (permalink / raw)
To: Jon Smirl; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <9e4733910604050838g339d48cao4e0f8582f6d90187@mail.gmail.com>
On Wed, Apr 05, 2006 at 11:38:06AM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > This will break the "color_map" sysfs file for framebuffers -
> > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > for a colormap with 256 entries. In fact, the original patch which
> > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> >
> > ... cheerfully assuming that nobody assumes NUL-termination and
> > everyone (sysfs patch writers!) certainly uses the length argument.
> > Fscking brilliant, that.
> >
> > Are you willing to audit all sysfs ->show() in the kernel? Original
> > author of that turd had not been.
> >
> > FWIW, "color_map" is a blatant abuse of interface. Doesn't get
> > any more borderline...
>
> The firmware interface is worse. You write the ROM image line by line
> to the attribute and a hidden counter tracks how far your are into the
> image.
>
> There needs to be a standardized way to transfer larger pieces of data
> via sysfs or we should go back to IOCTLs.
How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
of your own? ~20 lines for all of it, not counting #include...
^ permalink raw reply
* Re: Can't mount /dev/md0 after stopping a synchronization
From: Mike Garey @ 2006-04-05 15:39 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4433E073.8040502@fnuck.dk>
On 4/5/06, Troels Bang Jensen <marvin@fnuck.dk> wrote:
> This isn't quite what you asked about, but the rootraiddoc97 document is
> kinda obsolete by now
>
> -Debian Sarge has a new partitioner which can set up pretty advanced
> RAID configurations when installing. Just create RAID auto partitions on
> the disks and then create the arrays afterwards in the partitioner -
> it's far easier, and I've set up quite a few boot-on-RAID1 systems that way.
Thanks for the suggestion Troels, I didn't realize the rootraiddoc was
obsolete (although it is about 2 years old now it seems). In the
future, I think I'll try using the debian partitioner, but at the
moment, I'd still like to find out why I can't mount /dev/md0, as it's
rather disturbing, given the fact that if this happens in a production
system and I can't recover from it, I'm screwed.
I tried booting from /dev/hdc1 (as /dev/md0 in grub) using a 2.6.15
kernel with md and raid1 support built in and this is what I now get:
md: autodetecting raid arrays
md: autorun ...
md: considering hdc1 ...
md: adding hdc1 ...
md: created md0
md: bind:<hdc1>
raid1: RAID set md0 active with 1 out of 2 mirrors
md: ...autrun done.
Warning: unable to open an initial console
Input: AT translated set 2 keyboard as /class/input/input0
and then at this point, the system just hangs and nothing happens. So
I seem to be getting closer.. If I try booting from a kernel without
raid1 and md support, but using an initrd with raid1/md modules, then
I get the "ALERT! /dev/md0 does not exist. Dropping to a shell!"
message. I can't understand why there would be any difference between
using a kernel with raid1/md support, or using an initrd image with
raid1/md support, but apparently there is. If anyone else has any
suggestions, please keep them coming.
Regards,
Mike
^ permalink raw reply
* [U-Boot-Users] MPC8349EMDS port
From: Kumar Gala @ 2006-04-05 15:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <2FE9D542-933A-46D0-AACD-7EC1F3B582BB@kernel.crashing.org>
Any update on this?
- k
On Mar 30, 2006, at 11:20 AM, Kumar Gala wrote:
> Wolfgang,
>
> I was looking at merging the EMDS and ADS ports for MPC834x and was
> wondering about a few things:
>
> * EMDS has TEXT_BASE @ 0xFE000000, and ADS at 0xFE700000 where do
> you end up programming u-boot at? (for example what is the flash
> command you use to reprogram a u-boot image on the board).
>
> * I had to rework the BATs to be able to cover everything properly
> which also meant moving a few things around.
> CFG_BCSR 0xF8000000 -> 0xE2400000
> CFG_INIT_RAM_ADDR 0xE8000000 -> 0xFD000000
>
> This is so we can fit everything into the 8 BATS and maintain
> proper WIMG settings.
>
> If you can explain the TEXT_BASE difference and how that works out
> and are ok with the changing of CFG_BCSR and CFG_INIT_RAM_ADDR then
> I'll push some patches to merge ADS & MDS, remove ADS, and we get
> PCI support on EMDS out of it.
>
> let me know.
>
> - kumar
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply
* Re: qmail policy
From: Christopher J. PeBenito @ 2006-04-05 15:38 UTC (permalink / raw)
To: Petre Rodan; +Cc: SELinux List
In-Reply-To: <20060404165027.GA6245@peter.sunspire.org>
On Tue, 2006-04-04 at 19:50 +0300, Petre Rodan wrote:
> attached you'll find the qmail policy and a small patch needed to
> integrate it into serefpol.
Merged, with some reordering. I renamed some interface names, and
removed qmail_var_run_t, which was unused.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Jon Smirl @ 2006-04-05 15:38 UTC (permalink / raw)
To: Al Viro; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <20060405152123.GH27946@ftp.linux.org.uk>
On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > This will break the "color_map" sysfs file for framebuffers -
> > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > for a colormap with 256 entries. In fact, the original patch which
> > changed PAGE_SIZE - 1 to PAGE_SIZE:
>
> ... cheerfully assuming that nobody assumes NUL-termination and
> everyone (sysfs patch writers!) certainly uses the length argument.
> Fscking brilliant, that.
>
> Are you willing to audit all sysfs ->show() in the kernel? Original
> author of that turd had not been.
>
> FWIW, "color_map" is a blatant abuse of interface. Doesn't get
> any more borderline...
The firmware interface is worse. You write the ROM image line by line
to the attribute and a hidden counter tracks how far your are into the
image.
There needs to be a standardized way to transfer larger pieces of data
via sysfs or we should go back to IOCTLs.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Update: Patch-o-matic cleanup
From: Patrick McHardy @ 2006-04-05 15:37 UTC (permalink / raw)
To: Carl-Daniel Hailfinger; +Cc: Netfilter Development Mailinglist
In-Reply-To: <4433E035.2010504@gmx.net>
Carl-Daniel Hailfinger wrote:
> Hi Patrick,
>
> Patrick McHardy schrieb:
>
>>After receiving multiple "please keep this patch" mails, it seems I
>>started the wrong way.
>>
>>Removing old patches is part of a greater plan to reduce the content of
>>pom to only those things the netfilter team has an interest in
>>maintaining, and most of these things will be merged in not too long
>>time. _All_ other patches will be removed and the "runme" tool will
>>be enhanced by an apt-get like mechanism to download patches from
>>external sources[...]
>
>
> But why keep a few patches in pom and throw out the rest? Wouldn't it
> make sense to reduce pom to a simple script and throw out all patches?
> The few patches maintained by the netfilter team could be moved to a
> separate pom-hotfix package and be automatically downloaded by the
> pom script.
We could do that, but currently we want to keep a few patches while
minimizing our effort, the easiest way to do that is to just keep
them where they are.
> OTOH, having a pom-ng that can be applied without a network connection
> was very helpful for me in the past. So if you are really going to
> discontinue pom-ng as is, I offer to take over maintenance. Fetching
> the different packages from locations in a list and assembling them
> into one pom-full package automatically can't be that difficult.
I'm not sure if we want to discontinue official pom-releases entirely,
but you are of course free to maintain and release version which
include external patches.
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Randal L. Schwartz @ 2006-04-05 15:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0604051131010.2550@localhost.localdomain>
>>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
>> IIRC bsdiff is used by Firefox to distribute binary software updates.
>> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
>> supposedly offers worse compression (bigger diffs).
Nicolas> We already have our own delta code for pack storage.
I think the issue is related to being able to cherry-pick and merge
when binaries are involved. I've been worried about that myself.
How well are binaries supported these days for all the operations
we're taking for granted? When is a "diff" expected to be a real
"diff" and not just "binary files differ"?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Power management for au1000_eth.c
From: Rodolfo Giometti @ 2006-04-05 15:47 UTC (permalink / raw)
To: Linux MIPS; +Cc: ppopov
Hello,
I'm trying to add power management support to au1000_eth.c driver.
In order to to it I 've added these two functions:
static int au1000_eth_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct net_device *ndev = dev_get_drvdata(dev);
struct au1000_private *aup = (struct au1000_private *) ndev->priv;
if (!ndev)
return 0;
switch (level) {
case SUSPEND_DISABLE :
if (netif_running(ndev))
netif_device_detach(ndev);
break;
case SUSPEND_SAVE_STATE :
/* bring the device out of reset, otherwise accessing to mii
* will hang */
*aup->enable = MAC_EN_CLOCK_ENABLE;
au_sync_delay(2);
*aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 |
MAC_EN_RESET2 | MAC_EN_CLOCK_ENABLE;
au_sync_delay(2);
if (aup->phy_ops->phy_suspend)
aup->phy_ops->phy_suspend(ndev, aup->phy_addr, level);
del_timer_sync(&aup->timer); /* FIXME: REMOVED??? */
reset_mac(ndev);
netif_stop_queue(ndev);
free_irq(ndev->irq, dev);
break;
case SUSPEND_POWER_DOWN :
break;
}
return 0;
}
static int au1000_eth_resume(struct device *dev, u32 level)
{
struct net_device *ndev = dev_get_drvdata(dev);
struct au1000_private *aup = (struct au1000_private *) ndev->priv;
u32 flags;
int ret;
if (!ndev)
return 0;
switch (level) {
case RESUME_RESTORE_STATE :
/* bring the device out of reset, otherwise accessing to mii
* will hang */
*aup->enable = MAC_EN_CLOCK_ENABLE;
au_sync_delay(2);
*aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 |
MAC_EN_RESET2 | MAC_EN_CLOCK_ENABLE;
au_sync_delay(2);
if (aup->phy_ops->phy_resume)
aup->phy_ops->phy_resume(ndev, aup->phy_addr, level);
aup->phy_ops->phy_init(ndev, aup->phy_addr);
/* au1000_init() expects that the device is in reset state.
*/
reset_mac(ndev); /* au1000_init() expects the device in reset */
au1000_init(ndev);
ret = request_irq(ndev->irq, &au1000_interrupt, 0, ndev->name, ndev);
if (ret) {
printk(KERN_ERR "%s: unable to get IRQ %d\n",
ndev->name, ndev->irq);
return ret; //FIXME
}
init_timer(&aup->timer); /* used in ioctl() */
aup->timer.expires = RUN_AT((3*HZ));
aup->timer.data = (unsigned long) ndev;
aup->timer.function = &au1000_timer; /* timer handler */
add_timer(&aup->timer);
break;
case RESUME_ENABLE :
if (netif_running(ndev))
netif_device_attach(ndev);
break;
}
return 0;
}
The problem is that after wakeup the system hangs or returns lots of
errors like:
Reserved instruction in kernel code in arch/mips/kernel/traps.c::do_ri, line 706[#169]:
Note that if I compile the driver as a module and removing it before
sleeping and reinstalling it after wake up the system (and the
ethernet) works correctly...
Suggestions? :)
Thanks in advance,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
^ permalink raw reply
* Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)
From: John D. Ramsdell @ 2006-04-05 15:34 UTC (permalink / raw)
To: xen-devel
I'm running on a 32-bit x86 machine with Fedora Core 5. There is a
problem that causes a compilation failure when building mini-os from
its sources. An integer in xenbus/xenbus_xs.c should be unsigned.
Furthermore, a use of "xm top" asks me to report a bug to this list.
John
$ diff -ur oxen-3.0.1 xen-3.0.1
Only in xen-3.0.1/extras/mini-os: events.o
Only in xen-3.0.1/extras/mini-os: hypervisor.o
Only in xen-3.0.1/extras/mini-os/include: xen
Only in xen-3.0.1/extras/mini-os: kernel.o
Only in xen-3.0.1/extras/mini-os/lib: math.o
Only in xen-3.0.1/extras/mini-os/lib: printf.o
Only in xen-3.0.1/extras/mini-os/lib: string.o
Only in xen-3.0.1/extras/mini-os/lib: xmalloc.o
Only in xen-3.0.1/extras/mini-os: mini-os.elf
Only in xen-3.0.1/extras/mini-os: mini-os.gz
Only in xen-3.0.1/extras/mini-os: mm.o
Only in xen-3.0.1/extras/mini-os: sched.o
Only in xen-3.0.1/extras/mini-os: time.o
Only in xen-3.0.1/extras/mini-os: traps.o
Only in xen-3.0.1/extras/mini-os: x86_32.o
Only in xen-3.0.1/extras/mini-os/xenbus: xenbus_comms.o
diff -ur oxen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c xen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c
--- oxen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c 2006-03-01 17:38:57.000000000 -0500
+++ xen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c 2006-04-05 10:56:21.000000000 -0400
@@ -335,7 +335,7 @@
const char *dir, const char *node)
{
char **d;
- int dir_n;
+ unsigned int dir_n;
d = xenbus_directory(t, dir, node, &dir_n);
if (IS_ERR(d))
Only in xen-3.0.1/extras/mini-os/xenbus: xenbus_xs.c~
Only in xen-3.0.1/extras/mini-os/xenbus: xenbus_xs.o
Only in xen-3.0.1/extras/mini-os/xenbus: xenstored.h
[ramsdell@goo mini-os]$ su
Password:
[root@goo mini-os]# pwd
/home/ramsdell/src/xen-3.0.1/extras/mini-os
[root@goo mini-os]# /usr/sbin/xm create domain_config
Using config file "domain_config".
Started domain Mini-OS
[root@goo mini-os]# /usr/sbin/xm top
Unexpected error: exceptions.OSError
Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
File "/usr/sbin/xm", line 10, in ?
main.main(sys.argv)
File "/usr/lib/python2.4/site-packages/xen/xm/main.py", line 1021, in main
rc = cmd(args)
File "/usr/lib/python2.4/site-packages/xen/xm/main.py", line 654, in xm_top
os.execvp('xentop', ['xentop'])
File "/usr/lib/python2.4/os.py", line 341, in execvp
_execvpe(file, args)
File "/usr/lib/python2.4/os.py", line 379, in _execvpe
func(fullname, *argrest)
OSError: [Errno 2] No such file or directory
[root@goo mini-os]# /usr/sbin/xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1416 1 r----- 41.9
Mini-OS 1 32 1 ------ 8.6
[root@goo mini-os]# /usr/sbin/xm destroy Mini-OS
[root@goo mini-os]# /usr/sbin/xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1416 1 r----- 46.2
[root@goo mini-os]#
^ permalink raw reply
* Re: H.323 conntrack/NAT helper update for 2.6.17-rc1
From: Jing Min Zhao @ 2006-04-05 15:32 UTC (permalink / raw)
To: Harald Welte, netfilter-devel
In-Reply-To: <20060405152112.GF20558@sunbeam.de.gnumonks.org>
I sent it first in plain text the day before yesterday, but it didn't show up.
I thought it was too big to be processed, so I sent it compressed again. Now it
seems just because it was slow. I'm sorry I didn't know this.
----- Original Message -----
From: "Harald Welte" <laforge@netfilter.org>
To: <netfilter-devel@lists.netfilter.org>
Sent: Wednesday, April 05, 2006 11:21 AM
Subject: Re: H.323 conntrack/NAT helper update for 2.6.17-rc1
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Nicolas Pitre @ 2006-04-05 15:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e10mn9$cjs$1@sea.gmane.org>
On Wed, 5 Apr 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > It _might_ make sense to adopt a well-defined binary patch
> > format (or if there is no prior art, introduce our own) and
> > support that format with both git-diff-* brothers and git-apply,
> > but that would be a bit longer term project.
>
> bsdiff? http://www.daemonology.net/bsdiff/
> EDelta? http://www.diku.dk/~jacobg/edelta/
> Xdelta? http://xdelta.blogspot.com/
>
> IIRC bsdiff is used by Firefox to distribute binary software updates.
> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
> supposedly offers worse compression (bigger diffs).
We already have our own delta code for pack storage.
Nicolas
^ permalink raw reply
* Re: Re: Patch to xm create search domU config in /etc/xen/auto
From: Mark Williamson @ 2006-04-05 15:31 UTC (permalink / raw)
To: xen-devel; +Cc: Molle Bestefich, Itamar Reis Peixoto
In-Reply-To: <62b0912f0604040706q3ebfc58bv6e8a255b131d35ba@mail.gmail.com>
> What's preventing you from storing all your domU configurations in
> /etc/xen?
>
> You can link to them if you want them started automatically:
> # cd /etc/xen
> # ln -s mydomU auto/mydomU
This is the way I envisioned people using the auto directory.
> Also makes it easier to stop a domain from starting automatically
> without nuking the domain configuration:
> # rm /etc/xen/auto/mydomU
And that's why ;-)
I'd suggest just using the symlink approach rather than extending xm... But I
don't really think either way matters that much.
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
* Re: Regarding LIBIPQ problem
From: Harald Welte @ 2006-04-05 15:31 UTC (permalink / raw)
To: Vasantha Kumar Puttappa; +Cc: netfilter-devel, David Vogt
In-Reply-To: <4854.10.12.25.5.1143978508.squirrel@gpo.iitb.ac.in>
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]
On Sun, Apr 02, 2006 at 05:18:28PM +0530, Vasantha Kumar Puttappa wrote:
> Hi David,
> Thanx for your response.
> Actually I did use "ntohs" in the actual code.
> Anyhow I tested same code in kernel-2.6.11-6mdk and it's working fine,
> although i am receiving multiple copies at the receiver.
>
> Do you have any idea of kernel version in which "libipq" works properly
> withoug any problem.
I'm not aware of any libipq/kernel versions that have problems.
Also, try using libnetfilter_queue / nf_queue for new code, rather than
ip_queue, which has already been in feature-removal-schedule for quite
some time.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Jon Smirl @ 2006-04-05 15:30 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <20060405190928.17b9ba6a.vsu@altlinux.ru>
On 4/5/06, Sergey Vlasov <vsu@altlinux.ru> wrote:
> On Tue, 4 Apr 2006 16:59:47 -0700 gregkh@suse.de wrote:
>
> > No one should be writing a PAGE_SIZE worth of data to a normal sysfs
> > file, so properly terminate the buffer.
> >
> > Thanks to Al Viro for pointing out my stupidity here.
> >
> > CVE-2006-1055 has been assigned for this.
> >
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> >
> > ---
> > fs/sysfs/file.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- linux-2.6.16.1.orig/fs/sysfs/file.c
> > +++ linux-2.6.16.1/fs/sysfs/file.c
> > @@ -183,7 +183,7 @@ fill_write_buffer(struct sysfs_buffer *
> > return -ENOMEM;
> >
> > if (count >= PAGE_SIZE)
> > - count = PAGE_SIZE;
> > + count = PAGE_SIZE - 1;
> > error = copy_from_user(buffer->page,buf,count);
> > buffer->needs_read_fill = 1;
> > return error ? -EFAULT : count;
>
> This will break the "color_map" sysfs file for framebuffers -
> drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> for a colormap with 256 entries. In fact, the original patch which
> changed PAGE_SIZE - 1 to PAGE_SIZE:
>
> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d9d27fb651a7c95a46f276bacb4329db47470a6
>
> was done exactly for use with that "color_map" file.
>
> This patch also does not completely guarantee that the buffer will be
> null-terminated. A program may first call read() on the sysfs file,
> which will allocate buffer->page and invoke ->show to fill that page;
> then subsequent write() on the same file will reuse buffer->page. To
> get really bad results, you need to have ->store which assumes
> null-terminated buffer together with ->show which writes to the last
> byte of the page (which is probably rare, but show_cmap() does exactly
> that).
>
That is correct, that the color_map attribute will break. Color_map is
not in general use outside the Mesa development community.
The whole scheme of using sysfs instead of IOCTLs is not working out
very well for framebuffer. The original idea was to let you control
your framebuffer with simple scripts or from the keyboard. But since
the attributes don't strip \n and blanks, it has made them more
complex to use from the keyboard.
The one attribute per file model doesn't work well when the attributes
need to be changed in a transaction. For example you want to change
your display to 1024x768 16bit color. As you set the attributes one
at a time the display has to change since there is not guarantee that
you will complete the sequence. The framebuffer sysfs interface breaks
the one attribute per file rule and uses strings for grouped
attributes.
Ultimately I expect framebuffer will switch back to a helper app and
binary IOCTLs. Mainly because the help app can signal begin/end around
a change to a group of attributes.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Fix ia64 bit ops: Full barriers for bit operations returning
From: Zoltan Menyhart @ 2006-04-05 15:30 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0604031129510.21064@schroedinger.engr.sgi.com>
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
Christoph Lameter wrote:
> Could you come up with a patch? Currently, I do not seem to be able to
> spend enough time on it.
Please have a look at this patch.
Temporary solution while we are waiting for:
test_and_set_bit (int nr, volatile void *addr, MODE_BARRIER)
& co.
Changing the temp. variables to be 64 bit wide was not a good idea => alignment faults.
In order to eliminate the extra "zxt4", I hanged the type of the return values of my
intrinsic macros to be 32 bit wide. Here is what I get (NOP-s removed):
reserve_bootmem_core+240: [MMI] mf;;
reserve_bootmem_core+241: and r10=31,r18
reserve_bootmem_core+257: extr r11=r18,5,27;;
reserve_bootmem_core+272: [MFI] shladd r16=r11,2,r16
reserve_bootmem_core+274: shl r17=r19,r10;;
reserve_bootmem_core+288: [MMI] ld4.bias.nta r20=[r16];;
reserve_bootmem_core+289: or r22=r17,r20
reserve_bootmem_core+305: mov.m ar.ccv=r20;;
reserve_bootmem_core+320: [MMI] cmpxchg4.acq.nta r21=[r16],r22,ar.ccv;;
reserve_bootmem_core+322: cmp4.eq p14,p15=r20,r21
reserve_bootmem_core+336: [BBB] (p15) br.cond.dptk.few reserve_bootmem_core+288
BTW why do all the intrinsic macros return 64 bit wide values, independently of
their actual operand width? E.g.:
#define ia64_cmpxchg4_acq(ptr, new, old)
...
__u64 ia64_intri_res;
Thanks,
Zoltan
Signed-off-by: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 5780 bytes --]
--- old/include/asm-ia64/bitops.h 2006-04-04 18:19:50.000000000 +0200
+++ linux-2.6.16/include/asm-ia64/bitops.h 2006-04-05 16:49:12.000000000 +0200
@@ -7,6 +7,19 @@
*
* 02/06/02 find_next_bit() and find_first_bit() added from Erich Focht's ia64 O(1)
* scheduler patch
+ * 06/04/05 Cache hints added:
+ * For loads before the atomic operations:
+ * "bias" is a hint to acquire exclusive ownership.
+ * "nta" is a hint to allocate the cache line only in L2
+ * and to bias it to be replaced.
+ * For the atomic operations (as they are handled exclusively by L2):
+ * "nta" is a hint not to allocate the cache line else than in L2,
+ * to bias it to be replaced and not to write it back into L3.
+ * Added full fencing semantics to the atomic bit operations returning
+ * values.
+ * Note that it is a temporary solution while we are waiting for explicitly
+ * indicated fencing behavior, e.g.:
+ * test_and_set_bit (int nr, void *addr, MODE_BARRIER)
*/
#include <linux/compiler.h>
@@ -42,9 +55,9 @@ set_bit (int nr, volatile void *addr)
bit = 1 << (nr & 31);
do {
CMPXCHG_BUGCHECK(m);
- old = *m;
+ old = ia64_ld4_bias_nta(m);
new = old | bit;
- } while (cmpxchg_acq(m, old, new) != old);
+ } while (ia64_cmpxchg4_acq_nta(m, new, old) != old);
}
/**
@@ -89,9 +102,9 @@ clear_bit (int nr, volatile void *addr)
mask = ~(1 << (nr & 31));
do {
CMPXCHG_BUGCHECK(m);
- old = *m;
+ old = ia64_ld4_bias_nta(m);
new = old & mask;
- } while (cmpxchg_acq(m, old, new) != old);
+ } while (ia64_cmpxchg4_acq_nta(m, new, old) != old);
}
/**
@@ -100,14 +113,12 @@ clear_bit (int nr, volatile void *addr)
static __inline__ void
__clear_bit (int nr, volatile void *addr)
{
- volatile __u32 *p = (__u32 *) addr + (nr >> 5);
- __u32 m = 1 << (nr & 31);
- *p &= ~m;
+ *((__u32 *) addr + (nr >> 5)) &= ~(1 << (nr & 31));
}
/**
* change_bit - Toggle a bit in memory
- * @nr: Bit to clear
+ * @nr: Bit to change
* @addr: Address to start counting from
*
* change_bit() is atomic and may not be reordered.
@@ -122,17 +133,17 @@ change_bit (int nr, volatile void *addr)
CMPXCHG_BUGCHECK_DECL
m = (volatile __u32 *) addr + (nr >> 5);
- bit = (1 << (nr & 31));
+ bit = 1 << (nr & 31);
do {
CMPXCHG_BUGCHECK(m);
- old = *m;
+ old = ia64_ld4_bias_nta(m);
new = old ^ bit;
- } while (cmpxchg_acq(m, old, new) != old);
+ } while (ia64_cmpxchg4_acq_nta(m, new, old) != old);
}
/**
* __change_bit - Toggle a bit in memory
- * @nr: the bit to set
+ * @nr: the bit to change
* @addr: the address to start counting from
*
* Unlike change_bit(), this function is non-atomic and may be reordered.
@@ -160,13 +171,14 @@ test_and_set_bit (int nr, volatile void
volatile __u32 *m;
CMPXCHG_BUGCHECK_DECL
+ ia64_mf();
m = (volatile __u32 *) addr + (nr >> 5);
bit = 1 << (nr & 31);
do {
CMPXCHG_BUGCHECK(m);
- old = *m;
+ old = ia64_ld4_bias_nta(m);
new = old | bit;
- } while (cmpxchg_acq(m, old, new) != old);
+ } while (ia64_cmpxchg4_acq_nta(m, new, old) != old);
return (old & bit) != 0;
}
@@ -192,7 +204,7 @@ __test_and_set_bit (int nr, volatile voi
/**
* test_and_clear_bit - Clear a bit and return its old value
- * @nr: Bit to set
+ * @nr: Bit to clear
* @addr: Address to count from
*
* This operation is atomic and cannot be reordered.
@@ -205,19 +217,20 @@ test_and_clear_bit (int nr, volatile voi
volatile __u32 *m;
CMPXCHG_BUGCHECK_DECL
+ ia64_mf();
m = (volatile __u32 *) addr + (nr >> 5);
mask = ~(1 << (nr & 31));
do {
CMPXCHG_BUGCHECK(m);
- old = *m;
+ old = ia64_ld4_bias_nta(m);
new = old & mask;
- } while (cmpxchg_acq(m, old, new) != old);
+ } while (ia64_cmpxchg4_acq_nta(m, new, old) != old);
return (old & ~mask) != 0;
}
/**
* __test_and_clear_bit - Clear a bit and return its old value
- * @nr: Bit to set
+ * @nr: Bit to clear
* @addr: Address to count from
*
* This operation is non-atomic and can be reordered.
@@ -237,7 +250,7 @@ __test_and_clear_bit(int nr, volatile vo
/**
* test_and_change_bit - Change a bit and return its old value
- * @nr: Bit to set
+ * @nr: Bit to change
* @addr: Address to count from
*
* This operation is atomic and cannot be reordered.
@@ -250,13 +263,14 @@ test_and_change_bit (int nr, volatile vo
volatile __u32 *m;
CMPXCHG_BUGCHECK_DECL
+ ia64_mf();
m = (volatile __u32 *) addr + (nr >> 5);
bit = (1 << (nr & 31));
do {
CMPXCHG_BUGCHECK(m);
- old = *m;
+ old = ia64_ld4_bias_nta(m);
new = old ^ bit;
- } while (cmpxchg_acq(m, old, new) != old);
+ } while (ia64_cmpxchg4_acq_nta(m, new, old) != old);
return (old & bit) != 0;
}
--- old/include/asm-ia64/gcc_intrin.h 2006-04-04 18:19:50.000000000 +0200
+++ linux-2.6.16/include/asm-ia64/gcc_intrin.h 2006-04-05 17:07:29.000000000 +0200
@@ -221,6 +221,14 @@ register unsigned long ia64_r13 asm ("r1
asm volatile ("stf.spill [%0]=%1" :: "r"(x), "f"(__f__) : "memory"); \
})
+#define ia64_ld4_bias_nta(ptr) \
+({ \
+ __u32 ia64_intri_res; \
+ asm volatile ("ld4.bias.nta %0=[%1]": \
+ "=r"(ia64_intri_res) : "r"(ptr) : "memory"); \
+ ia64_intri_res; \
+})
+
#define ia64_fetchadd4_acq(p, inc) \
({ \
\
@@ -350,6 +358,15 @@ register unsigned long ia64_r13 asm ("r1
ia64_intri_res; \
})
+#define ia64_cmpxchg4_acq_nta(ptr, new, old) \
+({ \
+ __u32 ia64_intri_res; \
+ asm volatile ("mov ar.ccv=%0;;" :: "rO"(old)); \
+ asm volatile ("cmpxchg4.acq.nta %0=[%1],%2,ar.ccv": \
+ "=r"(ia64_intri_res) : "r"(ptr), "r"(new) : "memory"); \
+ ia64_intri_res; \
+})
+
#define ia64_cmpxchg8_acq(ptr, new, old) \
({ \
__u64 ia64_intri_res; \
^ permalink raw reply
* Re: Update: Patch-o-matic cleanup
From: Harald Welte @ 2006-04-05 15:29 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist
In-Reply-To: <4433CA75.9040607@trash.net>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
Thanks Patrick, for taking care of this long-over-due issue.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] ip_conntrack section mismatch warning fix
From: Patrick McHardy @ 2006-04-05 15:28 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel, Stephen Hemminger
In-Reply-To: <20060405152306.GG20558@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> On Wed, Apr 05, 2006 at 04:30:46PM +0200, Patrick McHardy wrote:
>
>>I think this might still fail without forced inlining. Our init
>>functions look like crap anyway, and the reason mostly seems to
>>be mass-registration of hooks, so I guess I'll clean that up
>>with a small helper function and then just split them.
>
>
> still I actually think of the shared init/cleanup functions as a big
> feature rather than something that needs to be 'cleaned up'.
I think they make the cleanup code quite unreadable because the
heavy mix with labels. I'm already half way through and the
seperated cleanup functions really are a lot more readable.
Besides that the split also allows to throw the init part away
after initializing, so it makes the binary smaller.
^ permalink raw reply
* Re: VMX status report 9532:5baf152d63ef
From: Dave Feustel @ 2006-04-05 15:27 UTC (permalink / raw)
To: xen-devel; +Cc: Mark Williamson
In-Reply-To: <200604051459.22248.mark.williamson@cl.cam.ac.uk>
On Wednesday 05 April 2006 08:59, Mark Williamson wrote:
> > Are any status reports for testing xen on AMD Pacifica being published
> > yet?
>
> Yes, IBM publish them for Linux and Windows XP guests (with other Windows OSes
> to follow once the tests are automated. I forget who's responsible, though,
> sorry.
Are IBM's test results published to this list? I don't remember having seen them.
Thanks,
Dave
--
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"
^ permalink raw reply
* Re: Trivial connlimit and IPMARK patch for 2.6.16
From: Harald Welte @ 2006-04-05 15:26 UTC (permalink / raw)
To: Grzegorz Janoszka; +Cc: netfilter-devel, Patrick McHardy
In-Reply-To: <Pine.GSO.4.63.0604040002220.15645@galaxy.agh.edu.pl>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
On Tue, Apr 04, 2006 at 12:09:52AM +0200, Grzegorz Janoszka wrote:
>
> Hello,
>
> Due to move of some targets from iptables to xtables, some patches turned to "not applyable", becouse
> their Makefile.ladd files
> tried to add iptables entries just after a target, that had been moved from iptables to xtables.
>
> Attached patch solves this problem, it only modifies Makefile.ladd files of connlimit and IPMARK. The
> patch is to patch-o-matic-ng-20060401 but it should apply clearly on any latest pom-ng.
I'm not really in the mood of manually adding such patches to svn.
I'm not really sure on the future of patch-o-matic as a whole. At least
I haven't really used any of the patches from there or updated anything
or tested whether it applies for at least half a year.
So unless somebody actually wants to become patch-o-matic maintainer
(yes, we once had somebody for that job), I think it's going to die.
Patrick, any news on that 'patch o matic remote repositories' idea?
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.