* [PATCH] ethtool always report port is TP on tg3
From: Karsten Keil @ 2006-05-12 10:05 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev, Andrew Morton
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
---
drivers/net/tg3.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
5ed8e79c778ee803e44a325a1e15c0cb3f52d0ff
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index beeb612..0b5bc93 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7653,21 +7653,23 @@ static int tg3_get_settings(struct net_d
cmd->supported |= (SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full);
- if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES))
+ if (!(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES)) {
cmd->supported |= (SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_MII);
- else
+ cmd->port = PORT_TP;
+ } else {
cmd->supported |= SUPPORTED_FIBRE;
+ cmd->port = PORT_FIBRE;
+ }
cmd->advertising = tp->link_config.advertising;
if (netif_running(dev)) {
cmd->speed = tp->link_config.active_speed;
cmd->duplex = tp->link_config.active_duplex;
}
- cmd->port = 0;
cmd->phy_address = PHY_ADDR;
cmd->transceiver = 0;
cmd->autoneg = tp->link_config.autoneg;
--
Karsten Keil
SuSE Labs
ISDN development
^ permalink raw reply related
* Re: [PATCH 1/4] Vectorize aio_read/aio_write methods
From: Andrew Morton @ 2006-05-12 10:03 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linux-kernel, hch, bcrl, cel
In-Reply-To: <1147361939.12117.12.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> drivers/usb/gadget/inode.c | 71 +++++++++++++++++++++++++++-----------
The changes in this file don't even approximately vaguely have the
remotest chance of compiling. Please send fix.
^ permalink raw reply
* [PATCH/rfc] schedule /sys/device/.../power for removal
From: Pavel Machek @ 2006-05-12 10:05 UTC (permalink / raw)
To: Andrew Morton, kernel list, Linux-pm mailing list; +Cc: Patrick Mochel
It is very ugly, and we really should use names instead.
Signed-off-by: Pavel Machek <pavel@suse.cz>
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 421bcff..dfcfc47 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -6,6 +6,16 @@ be removed from this file.
---------------------------
+What: /sys/device/.../power
+When: July 2007
+Files:
+Why: Because it takes integers, and different userland applications
+ expect different numbers to mean different things.
+ (Pcmcia expect 2 for off, some other code expects 3 for off).
+Who: Pavel Machek <pavel@suse.cz>
+
+---------------------------
+
What: devfs
When: July 2005
Files: fs/devfs/*, include/linux/devfs_fs*.h and assorted devfs
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply related
* Re: how to mount /dev/ram0 to /
From: Wolfgang Denk @ 2006-05-12 10:09 UTC (permalink / raw)
To: tony; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <44645CBD.00AAC3.19405>
In message <44645CBD.00AAC3.19405> you wrote:
>
> after boot up,excute df to see the mount point:
> ~ # df
> Filesystem 1k-blocks Used Available Use% Mounted on
> ~ #
> nothing was mounted.
Your rc scripts probably did not care to update /etc/mtag as needed.
Check what "cat /proc/mounts" gives.
> the fatab in /etc is like this:
> /dev/ram0 / ext2 defaults 1 1
> none /proc proc defaults 0 0
>
> anything wrong?
Probably no part of your rc scripts did anything with the information
in /etc/fstab ...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Perl itself is usually pretty good about telling you what you
shouldn't do. :-) - Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply
* Re: [PATCH -mm] swsusp: support creating bigger images (rev. 2)
From: Pavel Machek @ 2006-05-12 10:09 UTC (permalink / raw)
To: Nathan Scott
Cc: Nigel Cunningham, Rafael J. Wysocki, Andrew Morton, linux-kernel,
nickpiggin
In-Reply-To: <20060512101754.A2182805@wobbly.melbourne.sgi.com>
Hi!
On Pá 12-05-06 10:17:54, Nathan Scott wrote:
> On Fri, May 12, 2006 at 09:45:48AM +1000, Nigel Cunningham wrote:
> > On Thursday 11 May 2006 23:20, Rafael J. Wysocki wrote:
> > > On Thursday 11 May 2006 02:11, Nigel Cunningham wrote:
> > > > On Thursday 11 May 2006 09:38, Andrew Morton wrote:
> > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > On Wednesday 10 May 2006 00:27, Andrew Morton wrote:
> > > > >
> > > > > There can be situations where we won't be waiting on this IO at all.
> > > > > Network zero-copy transmit, for example.
> > > > >
> > > > > Or maybe there's some async writeback going on against pagecache -
> > > > > we'll end up looking at the page's LRU state within interrupt context
> > > > > at IO completion. (A sync would prevent this from happening).
> > > >
> > > > I believe more than a sync is needed in at least some cases. I've seen
> > > > XFS continue to submit I/O (presumably on the sb or such like) after
> > > > everything else has been frozen and data has been synced. Freezing bdevs
> > > > addressed this.
>
> [just came across this, missed it before, sorry]
>
> The above is correct - sync means get current state safe ondisk, it
> doesn't mean flush all dirty metadata to its final resting place
> (subtle difference). XFS will flush and wait on its journal on
> sync, which means theres a reconstructable state for all of the
> currently-incore-dirty-metadata ondisk, so it does not also flush
> and wait on that currently-incore-dirty-metadata. It doesn't need
> to, it has already ensured thats written elsewhere on disk, in the
> journal. And should the unthinkable happen, that metadata will be
> correctly recovered on the next mount when the journal is replayed.
>
> Block device freeze, unmount and/or remount,ro will all ensure that
> all incore-dirty-metadata is also flushed and waited on.
Who does the background writing? I'd prefer not to do blockdev
freezing in swsusp (and we do not currently do it).
Simple fix is probably to put proper refrigerator support into that
particular background writing thread.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH/rfc] schedule /sys/device/.../power for removal
From: Andrew Morton @ 2006-05-12 10:11 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-pm, linux-kernel
In-Reply-To: <20060512100544.GA29010@elf.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Pavel Machek <pavel@ucw.cz> wrote:
>
> It is very ugly, and we really should use names instead.
>
> Signed-off-by: Pavel Machek <pavel@suse.cz>
>
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index 421bcff..dfcfc47 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -6,6 +6,16 @@ be removed from this file.
>
> ---------------------------
>
> +What: /sys/device/.../power
> +When: July 2007
> +Files:
> +Why: Because it takes integers, and different userland applications
> + expect different numbers to mean different things.
> + (Pcmcia expect 2 for off, some other code expects 3 for off).
> +Who: Pavel Machek <pavel@suse.cz>
> +
> +---------------------------
What will be impacted by this?
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: ext3 metadata performace
From: Dieter Stüken @ 2006-05-12 10:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Helge Hafting, hzhong
In-Reply-To: <44642CBD.4000305@aitel.hist.no>
Helge Hafting wrote:
> Dieter Stüken wrote:
>> Would it be make sense for ext3, to disable synchronous writes even
>> for metadata (similar to the "data=writeback" option)?
>
> Turning off synchronous writes like this won't work!
> The battery-backed cache can help you in that you can consider
> data "written" once it is transferred to that cache. Metadata must still
> go synchronously into the cache though, or you get a broken fs
> if ever your machine crash in the middle of a transaction. (Leaving
> an update halfway in that battery cache, and halfway in main memory.
> Then main memory dies from the power cut / reboot.)
>
> The caching controller should report back to the linux device driver
> that "data is committed" as soon as it hits the cache - no need to
> wait for it to actually hit the platters. This can help performance with
> bursty writes tremendously - but it won't help you with long-lasting writes
> as you will then be limited by platter speed as soon as the battery cache
> is completely full.
The battery buffered cache is about 100Mb compared to 8k or 16k of the
disk buffer cache itself. So it won't become full that fast...
I just tested the same with my other controller (a 3ware 9550SX) which
has an option to configure explicitly if a write is acknowledged as
soon as the data is saved to the (buffered) memory or if it will delay
the acknowledge until data got written to disk. So this is similar to
enabling/disabling the disk cache on a plain disk. I did not found a
way to configure this on my older 3ware 9500S controller, even if it
has a battery backup, too (will ask 3ware about this).
Hua Zhong wrote:
>> If you mean the disk cache is reliable with the battery, then it
>> should be done by the block layer that a write barrier doesn't
>> translate into a SYNC (or whatever it is called). Instead, data is
>> considered synced to disk as soon as it hits the cache.
>>
>> It's really nothing to do with EXT3. It's doing the right thing.
I read something about "write barriers", but I don't know if these are
already used by my current 2.6.15 (I may try to use the actual kernel
tomorrow). Is there a difference between a SATA disk and a SCSI disk?
(which is emulated by my 3Ware controllers).
Dieter.
^ permalink raw reply
* Re: Trouble with setexeccon/setcon
From: Thomas Bleher @ 2006-05-12 10:11 UTC (permalink / raw)
To: Mario Fanelli; +Cc: SeLinux Mailing List
In-Reply-To: <44643eb7.025ecbeb.7447.326d@mx.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
* Mario Fanelli <mario.fanelli@gmail.com> [2006-05-12 10:10]:
> Hello, my name is Mario and I have a trouble with selinux's api. My goal is
> to modify the suPhp apache module, but the function setcon and function
> setexeccon don't work.
>
> My apache process runs in dummy_t domain and suPhp file has a security
> context "user_u:object_r:dummy_exec_t"; in the policy file I write:
>
> "domain_trans(dummy_t,dummy_exec_t,dummy_change_context_t)"
>
> "domain_trans(dummy_t,dummy_exec_t,dummy_change1_context_t)"
>
> And before calling apr_create_process in mod_suphp, I use
> setexeccon("user_u:object_r:dummy_change_context_t") but the function return
^^^^^^^^
> always -1
You need user_r instead of object_r. I've never used this api so I can't
comment further, but at least you need to change this.
Thomas
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] Vectorize aio_read/aio_write methods
From: Andrew Morton @ 2006-05-12 10:08 UTC (permalink / raw)
To: pbadari, linux-kernel, hch, bcrl, cel
In-Reply-To: <20060512030309.3a94bea8.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> Please send fix.
On second thoughts, I'll drop them all. Too many fixups, this code needs
more work.
Please ensure that the next version passes allmodconfig without adding any
new warnings on both 32-bit and 64-bit compilers, thanks.
^ permalink raw reply
* Re: [patch] smbus unhiding kills thermal management
From: Carl-Daniel Hailfinger @ 2006-05-12 10:13 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, kernel list, trenn, thoenig, stable
In-Reply-To: <20060512095343.GA28375@elf.ucw.cz>
Hi!
Pavel Machek wrote:
> Do not enable the SMBus device on Asus boards if suspend
> is used. We do not reenable the device on resume, leading to all sorts
> of undesirable effects, the worst being a total fan failure after
> resume on Samsung P35 laptop.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
> Signed-off-by: Pavel Machek <pavel@suse.cz>
This is probably also -stable material.
Regards,
Carl-Daniel
> ---
> commit f14c852a8cb7483ce0e1e0e05ef49fed2f67103b
> tree ab0cbe41b344a62bc81dd5cb093e3b6062c12556
> parent 392dbe84f1e484b1e48036ca266cb826fd34f8da
> author <pavel@amd.ucw.cz> Fri, 12 May 2006 11:50:00 +0200
> committer <pavel@amd.ucw.cz> Fri, 12 May 2006 11:50:00 +0200
>
> drivers/pci/quirks.c | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 19e2b17..9c5509f 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -895,6 +895,7 @@ static void __init k8t_sound_hostbridge(
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237, k8t_sound_hostbridge);
>
> +#ifndef CONFIG_ACPI_SLEEP
> /*
> * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
> * is not activated. The myth is that Asus said that they do not want the
> @@ -906,8 +907,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
> * bridge. Unfortunately, this device has no subvendor/subdevice ID. So it
> * becomes necessary to do this tweak in two steps -- I've chosen the Host
> * bridge as trigger.
> + *
> + * Actually, leaving it unhidden and not redoing the quirk over suspend2ram
> + * will cause thermal management to break down, and causing machine to
> + * overheat.
> */
> -static int __initdata asus_hides_smbus = 0;
> +static int __initdata asus_hides_smbus;
>
> static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
> {
> @@ -1050,6 +1055,8 @@ static void __init asus_hides_smbus_lpc_
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, asus_hides_smbus_lpc_ich6 );
>
> +#endif
> +
> /*
> * SiS 96x south bridge: BIOS typically hides SMBus device...
> */
>
--
http://www.hailfinger.org/
^ permalink raw reply
* Re: [PATCH/rfc] schedule /sys/device/.../power for removal
From: Andrew Morton @ 2006-05-12 10:11 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, linux-pm, mochel
In-Reply-To: <20060512100544.GA29010@elf.ucw.cz>
Pavel Machek <pavel@ucw.cz> wrote:
>
> It is very ugly, and we really should use names instead.
>
> Signed-off-by: Pavel Machek <pavel@suse.cz>
>
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index 421bcff..dfcfc47 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -6,6 +6,16 @@ be removed from this file.
>
> ---------------------------
>
> +What: /sys/device/.../power
> +When: July 2007
> +Files:
> +Why: Because it takes integers, and different userland applications
> + expect different numbers to mean different things.
> + (Pcmcia expect 2 for off, some other code expects 3 for off).
> +Who: Pavel Machek <pavel@suse.cz>
> +
> +---------------------------
What will be impacted by this?
^ permalink raw reply
* Re: ata_piix resume from S3 on T43P failed
From: Jens Axboe @ 2006-05-12 10:17 UTC (permalink / raw)
To: zhao, forrest; +Cc: Tejun Heo, linux-ide
In-Reply-To: <1147413106.7273.70.camel@forrest26.sh.intel.com>
On Fri, May 12 2006, zhao, forrest wrote:
> On Thu, 2006-05-11 at 12:55 +0200, Jens Axboe wrote:
> > run dmesg prior to suspending, then it'll be cached and can be run after
> > resume even if the disk doesn't want to talk to you.
> >
>
> Don't know why the mails with attached files were not sent to mailing
> list, so I put them at
> http://www.infradead.org/~forrest/suspend-resume-dmesg/
The key is the 0xef timeout, then the device is offlined and you see a
lot of io errors due to that.
Try this:
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index bd14720..f120839 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -4288,6 +4288,7 @@ int ata_device_resume(struct ata_port *a
{
if (ap->flags & ATA_FLAG_SUSPENDED) {
ap->flags &= ~ATA_FLAG_SUSPENDED;
+ mdelay(2000);
ata_set_mode(ap);
}
if (!ata_dev_present(dev))
--
Jens Axboe
^ permalink raw reply related
* Re: Update: Patch-o-matic cleanup
From: Carl-Daniel Hailfinger @ 2006-05-12 10:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist
In-Reply-To: <44642357.3000308@trash.net>
Hi,
Patrick McHardy wrote:
>
> I've now removed all patches that didn't find a new maintainer or
> which already have an external repository. I'll keep the ones where
> people are still setting up the repository for a couple more days,
> these are:
would it be possible for you to generate a list of the patches which
didn't find a new maintainer and have no external repository in sight?
Apologies if I overlooked such a list.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* Re: [PATCH/rfc] schedule /sys/device/.../power for removal
From: Pavel Machek @ 2006-05-12 10:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-pm, linux-kernel
In-Reply-To: <20060512031151.76a9d226.akpm@osdl.org>
On Pá 12-05-06 03:11:51, Andrew Morton wrote:
> Pavel Machek <pavel@ucw.cz> wrote:
> >
> > It is very ugly, and we really should use names instead.
> >
> > Signed-off-by: Pavel Machek <pavel@suse.cz>
> >
> > diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> > index 421bcff..dfcfc47 100644
> > --- a/Documentation/feature-removal-schedule.txt
> > +++ b/Documentation/feature-removal-schedule.txt
> > @@ -6,6 +6,16 @@ be removed from this file.
> >
> > ---------------------------
> >
> > +What: /sys/device/.../power
> > +When: July 2007
> > +Files:
> > +Why: Because it takes integers, and different userland applications
> > + expect different numbers to mean different things.
> > + (Pcmcia expect 2 for off, some other code expects 3 for off).
> > +Who: Pavel Machek <pavel@suse.cz>
> > +
> > +---------------------------
>
> What will be impacted by this?
Some obscure place PCMCIA utils, IIRC. There was one more user, but I
do not remember who it was. Plus there may be few people doing echo
manually.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [Xenomai-core] [BUG] kernel oops on registry duplicate names
From: Ignacio García Pérez @ 2006-05-12 10:19 UTC (permalink / raw)
To: xenomai-core
The subject pretty much explains it all.
Just try to create a task named "foo" and a queue also named "foo".
Tested in 2.1.1 and svn HEAD.
Nacho.
^ permalink raw reply
* Re: [PATCH/rfc] schedule /sys/device/.../power for removal
From: Pavel Machek @ 2006-05-12 10:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-pm, mochel
In-Reply-To: <20060512031151.76a9d226.akpm@osdl.org>
On Pá 12-05-06 03:11:51, Andrew Morton wrote:
> Pavel Machek <pavel@ucw.cz> wrote:
> >
> > It is very ugly, and we really should use names instead.
> >
> > Signed-off-by: Pavel Machek <pavel@suse.cz>
> >
> > diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> > index 421bcff..dfcfc47 100644
> > --- a/Documentation/feature-removal-schedule.txt
> > +++ b/Documentation/feature-removal-schedule.txt
> > @@ -6,6 +6,16 @@ be removed from this file.
> >
> > ---------------------------
> >
> > +What: /sys/device/.../power
> > +When: July 2007
> > +Files:
> > +Why: Because it takes integers, and different userland applications
> > + expect different numbers to mean different things.
> > + (Pcmcia expect 2 for off, some other code expects 3 for off).
> > +Who: Pavel Machek <pavel@suse.cz>
> > +
> > +---------------------------
>
> What will be impacted by this?
Some obscure place PCMCIA utils, IIRC. There was one more user, but I
do not remember who it was. Plus there may be few people doing echo
manually.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [patch] smbus unhiding kills thermal management
From: Pavel Machek @ 2006-05-12 10:20 UTC (permalink / raw)
To: Carl-Daniel Hailfinger; +Cc: Andrew Morton, kernel list, trenn, thoenig, stable
In-Reply-To: <44645FC2.80500@gmx.net>
On Pá 12-05-06 12:13:22, Carl-Daniel Hailfinger wrote:
> Hi!
>
> Pavel Machek wrote:
> > Do not enable the SMBus device on Asus boards if suspend
> > is used. We do not reenable the device on resume, leading to all sorts
> > of undesirable effects, the worst being a total fan failure after
> > resume on Samsung P35 laptop.
> >
> > Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
> > Signed-off-by: Pavel Machek <pavel@suse.cz>
>
> This is probably also -stable material.
Yes, I'd like to see it go into -stable. (But IIRC stable rules were
"mainline first").
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [RFC, PATCH] cond_resched() added to close_files()
From: Ingo Molnar @ 2006-05-12 10:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: dada1, linux-kernel
In-Reply-To: <20060512024446.00a0b407.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org> wrote:
> Makes my machine hang early during the startup of init.
>
> The last process to pass through close_file() is `hostname', presuably
> parented by init. `hostname' exits then everything stops. init is
> left sleeping in select().
>
> All very strange.
weird. This really shouldnt cause a hang - i think there must be a bug
hiding elsewhere, this cond_resched() ought to be fine.
Ingo
^ permalink raw reply
* [patch] xen bridged network setup fixes
From: Gerd Hoffmann @ 2006-05-12 10:24 UTC (permalink / raw)
To: Xen devel list
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
Hi,
The attached patch fixes the setup of the bridge ports and the bridge
itself. Changes:
* move some functions to xen-network-common.sh, so both vif-bridge
and network-bridge can use them.
* add a new function to configure bridge ports and use it.
* make sure arp requests, ipv6 autoconfiguration and ipv6 router
solicitations are disabled for the bridge ports and also for the
bridge itself.
cheers,
Gerd
--
Gerd Hoffmann <kraxel@suse.de>
Erst mal heiraten, ein, zwei Kinder, und wenn alles läuft
geh' ich nach drei Jahren mit der Familie an die Börse.
http://www.suse.de/~kraxel/julika-dora.jpeg
[-- Attachment #2: xen-netconf.diff --]
[-- Type: text/x-patch, Size: 3977 bytes --]
--- /etc/xen/scripts/vif-bridge.ipv6 2006-05-11 17:23:16.000000000 +0200
+++ /etc/xen/scripts/vif-bridge 2006-05-12 09:12:12.000000000 +0200
@@ -48,16 +48,8 @@
case "$command" in
online)
- if brctl show | grep -q "$vif"
- then
- log debug "$vif already attached to a bridge"
- exit 0
- fi
-
- brctl addif "$bridge" "$vif" ||
- fatal "brctl addif $bridge $vif failed"
-
- ifconfig "$vif" up || fatal "ifconfig $vif up failed"
+ setup_bridge_port "$vif"
+ add_to_bridge "$bridge" "$vif"
;;
offline)
--- /etc/xen/scripts/network-bridge.ipv6 2006-05-11 17:23:30.000000000 +0200
+++ /etc/xen/scripts/network-bridge 2006-05-12 10:27:04.000000000 +0200
@@ -137,29 +137,6 @@
}
-# Usage: create_bridge bridge
-create_bridge () {
- local bridge=$1
-
- # Don't create the bridge if it already exists.
- if [ ! -e "/sys/class/net/${bridge}/bridge" ]; then
- brctl addbr ${bridge}
- brctl stp ${bridge} off
- brctl setfd ${bridge} 0
- fi
- ip link set ${bridge} up
-}
-
-# Usage: add_to_bridge bridge dev
-add_to_bridge () {
- local bridge=$1
- local dev=$2
- # Don't add $dev to $bridge if it's already on a bridge.
- if [ ! -e "/sys/class/net/${bridge}/brif/${dev}" ]; then
- brctl addif ${bridge} ${dev}
- fi
-}
-
# Set the default forwarding policy for $dev to drop.
# Allow forwarding to the bridge.
antispoofing () {
@@ -220,15 +197,14 @@
ifdown ${netdev}
ip link set ${netdev} name ${pdev}
ip link set ${vdev} name ${netdev}
- ip link set ${pdev} down arp off
- ip link set ${pdev} addr fe:ff:ff:ff:ff:ff
- ip addr flush ${pdev}
+
+ setup_bridge_port ${pdev}
+ setup_bridge_port ${vif0}
ip link set ${netdev} addr ${mac} arp on
- add_to_bridge ${bridge} ${vif0}
ip link set ${bridge} up
- ip link set ${vif0} up
- ip link set ${pdev} up
+ add_to_bridge ${bridge} ${vif0}
add_to_bridge2 ${bridge} ${pdev}
+
ip link set ${netdev} up
ifup ${hwddev}
else
@@ -286,6 +262,7 @@
local maxtries=10
echo -n "Waiting for ${dev} to negotiate link."
+ ip link set ${dev} up
for i in `seq ${maxtries}` ; do
if ifconfig ${dev} | grep -q RUNNING ; then
break
--- /etc/xen/scripts/xen-network-common.sh.ipv6 2006-05-12 08:58:19.000000000 +0200
+++ /etc/xen/scripts/xen-network-common.sh 2006-05-12 10:41:47.000000000 +0200
@@ -67,3 +67,57 @@
{
first_file -x /etc/init.d/{dhcp3-server,dhcp,dhcpd}
}
+
+# configure interfaces which act as pure bridge ports:
+# - make quiet: no arp, no ipv6 autoconf
+# - set mac address to fe:ff:ff:ff:ff:ff
+setup_bridge_port() {
+ local dev="$1"
+
+ # take interface down ...
+ ip link set ${dev} up # creates ipv6 conf dir
+ ip link set ${dev} down
+
+ # ... and configure
+ if test -f /proc/sys/net/ipv6/conf/${dev}/autoconf; then
+ echo 0 > /proc/sys/net/ipv6/conf/${dev}/autoconf
+ echo 0 > /proc/sys/net/ipv6/conf/${dev}/router_solicitations
+ fi
+ ip link set ${dev} arp off
+ ip link set ${dev} addr fe:ff:ff:ff:ff:ff
+ ip addr flush ${dev}
+}
+
+# Usage: create_bridge bridge
+create_bridge () {
+ local bridge=$1
+
+ # Don't create the bridge if it already exists.
+ if [ ! -e "/sys/class/net/${bridge}/bridge" ]; then
+ brctl addbr ${bridge}
+ brctl stp ${bridge} off
+ brctl setfd ${bridge} 0
+ ip link set ${bridge} arp off
+ ip link set ${bridge} up # creates ipv6 conf dir
+ if test -f /proc/sys/net/ipv6/conf/${bridge}/autoconf; then
+ echo 0 > /proc/sys/net/ipv6/conf/${bridge}/autoconf
+ echo 0 > /proc/sys/net/ipv6/conf/${bridge}/router_solicitations
+ fi
+ else
+ ip link set ${bridge} up
+ fi
+}
+
+# Usage: add_to_bridge bridge dev
+add_to_bridge () {
+ local bridge=$1
+ local dev=$2
+
+ # Don't add $dev to $bridge if it's already on a bridge.
+ if [ -e "/sys/class/net/${bridge}/brif/${dev}" ]; then
+ return
+ fi
+ brctl addif ${bridge} ${dev}
+ ip link set ${dev} up
+}
+
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Linux v2.6.17-rc4
From: Erik Mouw @ 2006-05-12 10:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <Pine.LNX.4.64.0605111640010.3866@g5.osdl.org>
On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote:
> Ok, I've let the release time between -rc's slide a bit too much again,
> but -rc4 is out there, and this is the time to hunker down for 2.6.17.
>
> If you know of any regressions, please holler now, so that we don't miss
> them.
I got assertion failures in the bcm43xx driver:
bcm43xx: Chip ID 0x4318, rev 0x2
bcm43xx: Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243, enabled
bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243, disabled
bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243, enabled
bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243, enabled
bcm43xx: PHY connected
bcm43xx: Detected PHY: Version: 3, Type 2, Revision 7
bcm43xx: Detected Radio: ID: 8205017f (Manuf: 17f Ver: 2050 Rev: 8)
bcm43xx: Radio turned off
bcm43xx: Radio turned off
bcm43xx: PHY connected
bcm43xx: Radio turned on
bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair()
bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair()
bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair()
bcm43xx: Chip initialized
bcm43xx: DMA initialized
bcm43xx: 80211 cores initialized
bcm43xx: Keys cleared
ADDRCONF(NETDEV_UP): eth2: link is not ready
bcm43xx: ASSERTION FAILED (radio_attenuation < 10) at: drivers/net/wireless/bcm43xx/bcm43xx_phy.c:1485:bcm43xx_find_lopair()
ieee80211_crypt: registered algorithm 'WEP'
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Mix audio at different frequencies
From: Juan Zapatero @ 2006-05-12 10:25 UTC (permalink / raw)
To: alsa-devel
Hello,
I need to mix in playback two different audio streams, one coming from
an ogg player, which is at 44100Hz, and the other one, coming out of a
VoIP application, in this case, at 8000Hz. As I am using the dmix plugin
for mixing, I can't find out how to implement the resampling operations
needed.
Thanks.
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: Update: Patch-o-matic cleanup
From: Patrick McHardy @ 2006-05-12 10:26 UTC (permalink / raw)
To: Carl-Daniel Hailfinger; +Cc: Netfilter Development Mailinglist
In-Reply-To: <446460C4.5050806@gmx.net>
Carl-Daniel Hailfinger wrote:
> Hi,
>
> Patrick McHardy wrote:
>
>>I've now removed all patches that didn't find a new maintainer or
>>which already have an external repository. I'll keep the ones where
>>people are still setting up the repository for a couple more days,
>>these are:
>
>
> would it be possible for you to generate a list of the patches which
> didn't find a new maintainer and have no external repository in sight?
Unfortunately I just deleted my list together with the patches.
But anything is better than cleaning up ipt_recent, so here is
a new one :)
- account
- ACCOUNT
- comment
- connrate
- conntrack_locking
- cuseeme-nat
- dropped-table
- expire
- fuzzy
- goto
- h323-conntrack-nat
- ip_queue_vwmark
- MARK-operations
- mport
- nat-reservations
- netfilter-docbook
- NETLINK
- NETMAP
- nth
- osf
- owner-socketlookup
- pool
- pptp-conntrack-nat
- psd
- quota
- random
- TCPLAG
- tproxy
- TRACE
- unclean
- XOR
Some of these are already in mainline (or something comparable) or will
be soon:
- comment
- goto
- h323
- ip_queue_vwmark
- MARK-operations
- mport
- nth
- random
- quota
- pptp
The tproxy guys will probably set up their own repository, at least
thats what they said at the last workshop.
^ permalink raw reply
* Re: [PATCH/rfc] schedule /sys/device/.../power for removal
From: Andrew Morton @ 2006-05-12 10:27 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-pm, linux-kernel
In-Reply-To: <20060512101916.GC28232@elf.ucw.cz>
Pavel Machek <pavel@suse.cz> wrote:
>
> On Pá 12-05-06 03:11:51, Andrew Morton wrote:
> > Pavel Machek <pavel@ucw.cz> wrote:
> > >
> > > It is very ugly, and we really should use names instead.
> > >
> > > Signed-off-by: Pavel Machek <pavel@suse.cz>
> > >
> > > diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> > > index 421bcff..dfcfc47 100644
> > > --- a/Documentation/feature-removal-schedule.txt
> > > +++ b/Documentation/feature-removal-schedule.txt
> > > @@ -6,6 +6,16 @@ be removed from this file.
> > >
> > > ---------------------------
> > >
> > > +What: /sys/device/.../power
> > > +When: July 2007
> > > +Files:
> > > +Why: Because it takes integers, and different userland applications
> > > + expect different numbers to mean different things.
> > > + (Pcmcia expect 2 for off, some other code expects 3 for off).
> > > +Who: Pavel Machek <pavel@suse.cz>
> > > +
> > > +---------------------------
> >
> > What will be impacted by this?
>
> Some obscure place PCMCIA utils, IIRC. There was one more user, but I
> do not remember who it was. Plus there may be few people doing echo
> manually.
What will it be replaced with, and how will we communicate the need to
migrate to the various application developers? We can't just rip it out
next year and point at some obscure entry in a kernel file and say "but we
told you".
Some five-times-per-reboot printk which tells people they should be using
/sys/device/.../whatever-it-will-be-called might be appropriate.
^ permalink raw reply
* Re: [PATCH/rfc] schedule /sys/device/.../power for removal
From: Andrew Morton @ 2006-05-12 10:27 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, linux-pm, mochel
In-Reply-To: <20060512101916.GC28232@elf.ucw.cz>
Pavel Machek <pavel@suse.cz> wrote:
>
> On Pá 12-05-06 03:11:51, Andrew Morton wrote:
> > Pavel Machek <pavel@ucw.cz> wrote:
> > >
> > > It is very ugly, and we really should use names instead.
> > >
> > > Signed-off-by: Pavel Machek <pavel@suse.cz>
> > >
> > > diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> > > index 421bcff..dfcfc47 100644
> > > --- a/Documentation/feature-removal-schedule.txt
> > > +++ b/Documentation/feature-removal-schedule.txt
> > > @@ -6,6 +6,16 @@ be removed from this file.
> > >
> > > ---------------------------
> > >
> > > +What: /sys/device/.../power
> > > +When: July 2007
> > > +Files:
> > > +Why: Because it takes integers, and different userland applications
> > > + expect different numbers to mean different things.
> > > + (Pcmcia expect 2 for off, some other code expects 3 for off).
> > > +Who: Pavel Machek <pavel@suse.cz>
> > > +
> > > +---------------------------
> >
> > What will be impacted by this?
>
> Some obscure place PCMCIA utils, IIRC. There was one more user, but I
> do not remember who it was. Plus there may be few people doing echo
> manually.
What will it be replaced with, and how will we communicate the need to
migrate to the various application developers? We can't just rip it out
next year and point at some obscure entry in a kernel file and say "but we
told you".
Some five-times-per-reboot printk which tells people they should be using
/sys/device/.../whatever-it-will-be-called might be appropriate.
^ permalink raw reply
* Re: [PATCH -mm] swsusp: support creating bigger images (rev. 2)
From: Pavel Machek @ 2006-05-12 10:30 UTC (permalink / raw)
To: Nigel Cunningham
Cc: Rafael J. Wysocki, Andrew Morton, linux-kernel, nickpiggin
In-Reply-To: <200605120949.47046.ncunningham@cyclades.com>
> > Too much uncertainity for 10% speedup, I'm afraid. Yes, it was really
> > clever to get this fundamental change down to few hundred lines, but
> > design complexity remains. Could we drop that patch?
>
> Could you provide justification for your claim that the speedup is
> only 10%?
10% was number Rafael provided, IIRC.
> Please also remember that you are introducing complexity in other ways, with
> that swap prefetching code and so on. Any comparison in speed should include
> the time to fault back in pages that have been discarded.
Well, swap prefetching is useful for other workloads, too; so it gets
developed/tested outside swsusp.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ 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.