* Re: [Xen-users] Re: Xen document day (Oct 12 or 26)
From: Florian Heigl @ 2011-10-30 20:58 UTC (permalink / raw)
To: Lars Kurth
Cc: xen-devel@lists.xensource.com, Ian Campbell,
Konrad Rzeszutek Wilk, Andrew Bobulsky, Joseph Glanville,
xen-users@lists.xensource.com
In-Reply-To: <4EAAA467.2030503@xen.org>
Hi Lars,
2011/10/28 Lars Kurth <lars.kurth@xen.org>:
> There may be a few more. Will need to work on these a little more. It may
> also mean that the MediWiki instance is set up that pages must have a
> category and that only a subset of users can create new ones. Otherwise we
> get into the same mess again.
I think the main issues (mess) with the old wiki were:
- not being able to contact someone if information is incorrect / outdated
- noone looking into pages that had become outdated
- not looking for pages that might be outdated
- most of the pages being immutable so you couldn't even fix stuff.
So if we limit edit rights to certain user groups that is not a
problem, as long as the groups are big enough to maintain the
categories.
Also it might be helpful to use a release mechanism - if any
registered user can create pages, but they stay invisible until
approval then this would save a lot of time for the regular authors
and still keep up quality. (Thats working really well in my
experience)
Greetings
Florian
^ permalink raw reply
* Re: Broken link in /sys/class/net/ [was: [GIT] Networking]
From: Jiri Slaby @ 2011-10-30 20:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jiri Slaby, Greg KH, Linus Torvalds, David Miller,
Mikulas Patocka, akpm, netdev, linux-kernel
In-Reply-To: <m11utvytg4.fsf@fess.ebiederm.org>
On 10/30/2011 05:49 AM, Eric W. Biederman wrote:
> Jiri Slaby <jslaby@suse.cz> writes:
>
>> On 10/25/2011 03:13 PM, Greg KH wrote:
>>> On Tue, Oct 25, 2011 at 01:46:11PM +0200, Linus Torvalds wrote:
>>>> Anyway, after that rant about really bad practices, let me say that I
>>>> did fix up the conflict and I think it's right. But I won't guarantee
>>>> it, so please check the changes to fs/sysfs/dir.c.
>>>
>>> I think it looks ok, I've booted the merge result, and am typing and
>>> sending this from the new kernel, and it hasn't crashed yet :)
>>
>> Hi, maybe this was not caused by the merge, but the patch[1] causes this
>> mess in /sys/class/net/ for me:
>> l????????? ? ? ? ? ? eth1
>>
>> This happens after one renames a net device -- the new name is eth1 here.
>>
>> [1] 4f72c0cab40 (sysfs: use rb-tree for name lookups)
>
> This looks pretty fixable but today sysfs_rename does not do anything
> with the to move a renamed entry to a different position in the rbtree.
>
> If the directory itself changes sysfs_rename should be fine, and it
> looks like a trivial patch to always apply the directory rename logic
> in sysfs_rename.
>
> I think all we need is something like the untested patch below to fix
> the network device rename problem.
Looks like it works. Thanks.
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index 48ffbdf..a294068 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -865,14 +865,13 @@ int sysfs_rename(struct sysfs_dirent *sd,
> sd->s_name = new_name;
> }
>
> - /* Remove from old parent's list and insert into new parent's list. */
> - if (sd->s_parent != new_parent_sd) {
> - sysfs_unlink_sibling(sd);
> - sysfs_get(new_parent_sd);
> - sysfs_put(sd->s_parent);
> - sd->s_parent = new_parent_sd;
> - sysfs_link_sibling(sd);
> - }
> + /* Move to the appropriate place in the appropriate directories rbtree. */
> + sysfs_unlink_sibling(sd);
> + sysfs_get(new_parent_sd);
> + sysfs_put(sd->s_parent);
> + sd->s_parent = new_parent_sd;
> + sysfs_link_sibling(sd);
> +
> sd->s_ns = new_ns;
>
> error = 0;
>
--
js
suse labs
^ permalink raw reply
* [U-Boot] [PATCH 12/18] GCC4.6: Squash warnings in smsc95xx.c
From: Marek Vasut @ 2011-10-30 20:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110301637.29795.vapier@gentoo.org>
> On Tuesday 25 October 2011 05:39:58 Marek Vasut wrote:
> > --- a/drivers/usb/eth/smsc95xx.c
> > +++ b/drivers/usb/eth/smsc95xx.c
> >
> > - addr_lo = cpu_to_le32(*((u32 *)eth->enetaddr));
> > + addr_lo = cpu_to_le32(*eth->enetaddr);
>
> pretty sure this is wrong. enetaddr is a uchar[], so your code now reads
> only 1 byte instead of 4.
>
> that said, this code also seems to not be endian safe ...
> -mike
It's good anyone actually cares to properly review. Anyway, why does noone
actually care to fix all the damn warnings in their drivers before submitting
them in the first place ?!
^ permalink raw reply
* Re: [PATCH v2] GIO bus support for SGI IP22/28
From: Joshua Kinard @ 2011-10-30 20:43 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, linux-fbdev, ralf, FlorianSchandinat
In-Reply-To: <20111020221928.0C2191DA27@solo.franken.de>
On 10/20/2011 18:19, Thomas Bogendoerfer wrote:
> SGI IP22/IP28 machines have GIO busses for adding graphics and other
> extension cards. This patch adds support for GIO driver/device
> handling and converts the newport console driver to a GIO driver.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Does this handle any glue logic for add-on NIC cards found for Indy and I2?
I have a G130 Phobus and a rare ThunderLAN card in my Indy. The Phobus has
an Altera GIO/PCI glue chip. Not sure about the ThunderLAN. Both have
normal driver support in the kernel (Phobus is just a Tulip chip).
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* Re: [PATCH v2] GIO bus support for SGI IP22/28
From: Joshua Kinard @ 2011-10-30 20:43 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, linux-fbdev, ralf, FlorianSchandinat
In-Reply-To: <20111020221928.0C2191DA27@solo.franken.de>
On 10/20/2011 18:19, Thomas Bogendoerfer wrote:
> SGI IP22/IP28 machines have GIO busses for adding graphics and other
> extension cards. This patch adds support for GIO driver/device
> handling and converts the newport console driver to a GIO driver.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Does this handle any glue logic for add-on NIC cards found for Indy and I2?
I have a G130 Phobus and a rare ThunderLAN card in my Indy. The Phobus has
an Altera GIO/PCI glue chip. Not sure about the ThunderLAN. Both have
normal driver support in the kernel (Phobus is just a Tulip chip).
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* Re: hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
From: David Fries @ 2011-10-30 20:43 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel, netdev, Rafael J. Wysocki, linux-pm
In-Reply-To: <20111030201618.GA7696@google.com>
On Sun, Oct 30, 2011 at 01:16:18PM -0700, Tejun Heo wrote:
> (cc'ing Rafael and linux-pm)
>
> On Sat, Oct 29, 2011 at 11:48:21PM -0500, David Fries wrote:
> > I saw the write up on this on lwn.net, pretty creative by the way, and
> > it got me thinking about a different checkpoint/restart problem I've
> > been running into. Specifically in hibernating to disk. In the
> > hibernate case active TCP connections hang after resuming, while an
> > idle TCP connection will continue after the system is back up. My
> > observation is the kernel checkpoints itself to memory, enables
> > devices, writes out that checkpoint image to storage, then powers off.
> > The problem is if TCP packets are received while writing to storage,
> > the kernel will continue to queue and ack those TCP packets, but the
> > running kernel and it's network state is shortly lost. When the
> > computer resumes, those TCP byte sequences hang the TCP connection for
> > an extended period of time while the resumed computer refuses to
> > acknowledge the data that was received after checkpointing and the now
> > running kernel knew nothing about, and the other computer tries in
> > vain to resend any data that hadn't yet been acknowledged, which is
> > always after the data that was lost, until one of them eventually
> > gives up.
> >
> > I've been wondering if it was safe or possible to leave any network
> > interfaces down after the checkpoint, or what the right solution would
> > be. I didn't think marking every TCP connection with a ZOMBIE_KERNEL
> > bit just after the kernel checkpoint (for the kernel is walking dead
> > and won't remember anything that happens), and then prevent any TCP
> > acks from being sent for those connections would be the right
> > solution. I've taken to unplugging the physical lan cable,
> > hibernating to disk, and plugging it back in after the system is down,
> > to avoid the problem. Any ideas?
>
> Hmmm... sounds like taking down network interfaces before starting
> hibernation sequence should be enough, which shouldn't be too
> difficult to implement from userland. Rafael, what do you think?
What I observe is the kernel prints out "Preallocating image memory",
then when the screen goes blank the network link light also goes out,
then the screen comes back on with "Compressing and saving" along with
the link light comes on, until it has been saved and the system shuts
down. So the kernel is already brining the network down, it just
needs to keep it there until the original check pointed kernel is back
up.
Userspace bringing the network interfaces down is problematic. As an
example one of my systems is running hostapd as an access point and
bridging that to the wired ethernet, that's not a trivial task to
setup and take down (the Debian ifup can set it up, but I've not
figured out yet how to get ifdown to take everything down cleanly, and
I sometimes manually run hostapd if I'm troubleshooting). Any
manually added routes would go away, good luck in setting everything
back up the way it was before for all the different configurations out
there in userspace. Add to those issues programs would now have a
time when networking is down that they wouldn't have otherwise seen.
--
David Fries <david@fries.net> PGP pub CB1EE8F0
http://fries.net/~david/
^ permalink raw reply
* Re: hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
From: David Fries @ 2011-10-30 20:43 UTC (permalink / raw)
To: Tejun Heo; +Cc: netdev, linux-pm, linux-kernel
In-Reply-To: <20111030201618.GA7696@google.com>
On Sun, Oct 30, 2011 at 01:16:18PM -0700, Tejun Heo wrote:
> (cc'ing Rafael and linux-pm)
>
> On Sat, Oct 29, 2011 at 11:48:21PM -0500, David Fries wrote:
> > I saw the write up on this on lwn.net, pretty creative by the way, and
> > it got me thinking about a different checkpoint/restart problem I've
> > been running into. Specifically in hibernating to disk. In the
> > hibernate case active TCP connections hang after resuming, while an
> > idle TCP connection will continue after the system is back up. My
> > observation is the kernel checkpoints itself to memory, enables
> > devices, writes out that checkpoint image to storage, then powers off.
> > The problem is if TCP packets are received while writing to storage,
> > the kernel will continue to queue and ack those TCP packets, but the
> > running kernel and it's network state is shortly lost. When the
> > computer resumes, those TCP byte sequences hang the TCP connection for
> > an extended period of time while the resumed computer refuses to
> > acknowledge the data that was received after checkpointing and the now
> > running kernel knew nothing about, and the other computer tries in
> > vain to resend any data that hadn't yet been acknowledged, which is
> > always after the data that was lost, until one of them eventually
> > gives up.
> >
> > I've been wondering if it was safe or possible to leave any network
> > interfaces down after the checkpoint, or what the right solution would
> > be. I didn't think marking every TCP connection with a ZOMBIE_KERNEL
> > bit just after the kernel checkpoint (for the kernel is walking dead
> > and won't remember anything that happens), and then prevent any TCP
> > acks from being sent for those connections would be the right
> > solution. I've taken to unplugging the physical lan cable,
> > hibernating to disk, and plugging it back in after the system is down,
> > to avoid the problem. Any ideas?
>
> Hmmm... sounds like taking down network interfaces before starting
> hibernation sequence should be enough, which shouldn't be too
> difficult to implement from userland. Rafael, what do you think?
What I observe is the kernel prints out "Preallocating image memory",
then when the screen goes blank the network link light also goes out,
then the screen comes back on with "Compressing and saving" along with
the link light comes on, until it has been saved and the system shuts
down. So the kernel is already brining the network down, it just
needs to keep it there until the original check pointed kernel is back
up.
Userspace bringing the network interfaces down is problematic. As an
example one of my systems is running hostapd as an access point and
bridging that to the wired ethernet, that's not a trivial task to
setup and take down (the Debian ifup can set it up, but I've not
figured out yet how to get ifdown to take everything down cleanly, and
I sometimes manually run hostapd if I'm troubleshooting). Any
manually added routes would go away, good luck in setting everything
back up the way it was before for all the different configurations out
there in userspace. Add to those issues programs would now have a
time when networking is down that they wouldn't have otherwise seen.
--
David Fries <david@fries.net> PGP pub CB1EE8F0
http://fries.net/~david/
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Marc Dietrich @ 2011-10-30 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173EDAB4C7@HQMAIL01.nvidia.com>
On Friday 28 October 2011 09:49:49 Stephen Warren wrote:
> Marc Dietrich wrote at Friday, October 28, 2011 4:30 AM:
> > Am Donnerstag, 27. Oktober 2011, 09:50:03 schrieb Stephen Warren:
> > > Marc Dietrich wrote at Wednesday, October 26, 2011 1:59 PM:
> > > > This adds a dts file for paz00. As a side effect, this also
> > > > enables
> > > > the embedded controller which controls the keyboard, touchpad,
> > > > power,
> > > > leds, and some other functions.
> > >
> > > ...
> > >
> > > > +++ b/arch/arm/boot/dts/tegra-paz00.dts
> > > > @@ -0,0 +1,70 @@
> > > > +/dts-v1/;
> > > > +
> > > > +/memreserve/ 0x1c000000 0x04000000;
> > > > +/include/ "tegra20.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "Toshiba AC100 / Dynabook AZ";
> > > > + compatible = "compal,paz00", "nvidia,tegra20";
> > > > +
> > > > + chosen {
> > > > + bootargs = "mem=448 at 0 console=ttyS0,115200n8
> > > > root=/dev/mmcblk1p1";
> > >
> > > You shouldn't need the mem= parameter here; it wasn't in your first
> > > patch set.>
> > that's because I forgot it. Sorry, I didn't mentioned it in the
> > changelog. I wonder why mem= is still needed.
>
> I wonder if this is some conflict between ATAGs and the DT-specified
> memory node.
>
> As far as I can tell, the kernel's memory information typically comes
> from ATAGs. Some boards override what's in the ATAGs in their machine
> descriptor's fixup routine, e.g. see tegra_paz00_fixup(). Presumably,
> this is because of buggy bootloaders sending incorrect memory information
> in the ATAGs. Do you have any way to check the ATAGs that the bootloader
> is sending? Probably, you could enable DEBUG_LL and using the low-level
> debugging functions to dump some of that information to the UART early
> during boot.
I got the ATAGS from /proc/atags and there is no memory entry there, only
initrd and cmdline (which is the one from nvflash).
The machine also has a fixup routine, but it also boots without (I'm sure it
was necessary in the past),
> When boards boot from DT, there is no fixup function to override the
> bootloader's ATAGs.
... so I guess this is why it also works with DT.
> I also see a bunch of code to set up the memory
> information from DT e.g. setup_machine_fdt()'s call to:
>
> of_scan_flat_dt(early_init_dt_scan_memory, NULL);
>
> ... but I assume that happens before the ATAGs are processed, and the
> buggy ATAGs end up overriding the information in the DT file. And further,
> I assume that specifying "mem=" on the command-line overrides that, thus
> solving the problem.
>
> It'd be awesome if you could validate this; the simplest way is probably
> to:
>
> a) Remove mem= from the command-line
I tested several variations. Without DT, the fixup can compensate a missing
mem entry in the kernel command line, but with a mem= from the kernel command
line, a fixup is not needed.
With DT, the command line specified from nvflash is ignored and the one from
DT comes into the game. If it is also missing there, system detects 512 MB
(which is physical right, but we cannot reserve memory for the gpu). The fixup
is indeed ignored in this case.
> b) Modify arch/arm/kernel/setup.c:parse_tag_mem32() to do nothing;
> comment out the call to arm_add_memory()
I leave this out because the bootloader does not send memory info in the
ATAGS.
> c) Test booting, and check what RAM size the kernel thinks you have.
see above. RAM detection works, but it's not what we want ...
> If that works, then ATAGs are the problem. We probably need to modify the
> core ARM code not to use memory ATAGs when there is a DT?
>
> I'm mainly pushing on this because adding "mem=" to the command-line in
> the DT file isn't a great solution; when people start using bootloaders
> that rewrite the DT to include the user-specified command-line, then every
> user is going to have to start specifying "mem=" in their command-lines.
Well, I see two options for our case:
a) use the mem=448M at 0 in the DT so the gpu can get its memory
b) upstream the chromeos changes to reserve gpu memory "on the fly" from
the autodetected 512M (as it should be IMHO).
> > I've seen patches on the chromeos tree which try to reserve the gpu
> > memory on demand. While we are at it, what is the vmalloc=192M used
> > by most other boards for?
>
> I'm not sure what vmalloc= does exactly. I somewhat doubt it's necessary
> until we have code that uses the GPU in mainline. The same goes for the
> /memreserve/ DT entries. I've been thinking of submitting a patch to
> remove this cruft, but haven't gotten around to it yet.
^ permalink raw reply
* Re: [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Marc Dietrich @ 2011-10-30 20:39 UTC (permalink / raw)
To: Stephen Warren
Cc: Grant Likely (grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org),
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Olof Johansson, Colin Cross,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173EDAB4C7-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On Friday 28 October 2011 09:49:49 Stephen Warren wrote:
> Marc Dietrich wrote at Friday, October 28, 2011 4:30 AM:
> > Am Donnerstag, 27. Oktober 2011, 09:50:03 schrieb Stephen Warren:
> > > Marc Dietrich wrote at Wednesday, October 26, 2011 1:59 PM:
> > > > This adds a dts file for paz00. As a side effect, this also
> > > > enables
> > > > the embedded controller which controls the keyboard, touchpad,
> > > > power,
> > > > leds, and some other functions.
> > >
> > > ...
> > >
> > > > +++ b/arch/arm/boot/dts/tegra-paz00.dts
> > > > @@ -0,0 +1,70 @@
> > > > +/dts-v1/;
> > > > +
> > > > +/memreserve/ 0x1c000000 0x04000000;
> > > > +/include/ "tegra20.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "Toshiba AC100 / Dynabook AZ";
> > > > + compatible = "compal,paz00", "nvidia,tegra20";
> > > > +
> > > > + chosen {
> > > > + bootargs = "mem=448@0 console=ttyS0,115200n8
> > > > root=/dev/mmcblk1p1";
> > >
> > > You shouldn't need the mem= parameter here; it wasn't in your first
> > > patch set.>
> > that's because I forgot it. Sorry, I didn't mentioned it in the
> > changelog. I wonder why mem= is still needed.
>
> I wonder if this is some conflict between ATAGs and the DT-specified
> memory node.
>
> As far as I can tell, the kernel's memory information typically comes
> from ATAGs. Some boards override what's in the ATAGs in their machine
> descriptor's fixup routine, e.g. see tegra_paz00_fixup(). Presumably,
> this is because of buggy bootloaders sending incorrect memory information
> in the ATAGs. Do you have any way to check the ATAGs that the bootloader
> is sending? Probably, you could enable DEBUG_LL and using the low-level
> debugging functions to dump some of that information to the UART early
> during boot.
I got the ATAGS from /proc/atags and there is no memory entry there, only
initrd and cmdline (which is the one from nvflash).
The machine also has a fixup routine, but it also boots without (I'm sure it
was necessary in the past),
> When boards boot from DT, there is no fixup function to override the
> bootloader's ATAGs.
... so I guess this is why it also works with DT.
> I also see a bunch of code to set up the memory
> information from DT e.g. setup_machine_fdt()'s call to:
>
> of_scan_flat_dt(early_init_dt_scan_memory, NULL);
>
> ... but I assume that happens before the ATAGs are processed, and the
> buggy ATAGs end up overriding the information in the DT file. And further,
> I assume that specifying "mem=" on the command-line overrides that, thus
> solving the problem.
>
> It'd be awesome if you could validate this; the simplest way is probably
> to:
>
> a) Remove mem= from the command-line
I tested several variations. Without DT, the fixup can compensate a missing
mem entry in the kernel command line, but with a mem= from the kernel command
line, a fixup is not needed.
With DT, the command line specified from nvflash is ignored and the one from
DT comes into the game. If it is also missing there, system detects 512 MB
(which is physical right, but we cannot reserve memory for the gpu). The fixup
is indeed ignored in this case.
> b) Modify arch/arm/kernel/setup.c:parse_tag_mem32() to do nothing;
> comment out the call to arm_add_memory()
I leave this out because the bootloader does not send memory info in the
ATAGS.
> c) Test booting, and check what RAM size the kernel thinks you have.
see above. RAM detection works, but it's not what we want ...
> If that works, then ATAGs are the problem. We probably need to modify the
> core ARM code not to use memory ATAGs when there is a DT?
>
> I'm mainly pushing on this because adding "mem=" to the command-line in
> the DT file isn't a great solution; when people start using bootloaders
> that rewrite the DT to include the user-specified command-line, then every
> user is going to have to start specifying "mem=" in their command-lines.
Well, I see two options for our case:
a) use the mem=448M@0 in the DT so the gpu can get its memory
b) upstream the chromeos changes to reserve gpu memory "on the fly" from
the autodetected 512M (as it should be IMHO).
> > I've seen patches on the chromeos tree which try to reserve the gpu
> > memory on demand. While we are at it, what is the vmalloc=192M used
> > by most other boards for?
>
> I'm not sure what vmalloc= does exactly. I somewhat doubt it's necessary
> until we have code that uses the GPU in mainline. The same goes for the
> /memreserve/ DT entries. I've been thinking of submitting a patch to
> remove this cruft, but haven't gotten around to it yet.
^ permalink raw reply
* [U-Boot] [PATCH 12/18] GCC4.6: Squash warnings in smsc95xx.c
From: Mike Frysinger @ 2011-10-30 20:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319535604-20831-13-git-send-email-marek.vasut@gmail.com>
On Tuesday 25 October 2011 05:39:58 Marek Vasut wrote:
> --- a/drivers/usb/eth/smsc95xx.c
> +++ b/drivers/usb/eth/smsc95xx.c
>
> - addr_lo = cpu_to_le32(*((u32 *)eth->enetaddr));
> + addr_lo = cpu_to_le32(*eth->enetaddr);
pretty sure this is wrong. enetaddr is a uchar[], so your code now reads only
1 byte instead of 4.
that said, this code also seems to not be endian safe ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111030/e9c7082c/attachment.pgp
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd: tests: annotate as DANGEROUS in Kconfig
From: Wolfram Sang @ 2011-10-30 20:37 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-mtd
In-Reply-To: <1320006895.2126.61.camel@koala>
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
On Sun, Oct 30, 2011 at 10:34:53PM +0200, Artem Bityutskiy wrote:
> On Sun, 2011-10-30 at 17:28 +0100, Wolfram Sang wrote:
> > + WARNING: Some of the tests will ERASE THE CONTENT of mtd devices!
> > + Do not use these tests unless you are sure you really need to.
>
> Thanks, I've pushed this patch but amended the above text a bit:
> + WARNING: some of the tests will ERASE entire MTD device which they
> + test. Do not use these tests unless you really know what you do.
OK, thanks! Seems we now finally have it :)
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [regression] CD-ROM polling blocks suspend on some machines (Re: [PATCH 1/2] cdrom: always check_disk_change() on open)
From: Tejun Heo @ 2011-10-30 20:35 UTC (permalink / raw)
To: Matthijs Kooijman
Cc: Gaudenz Steinlin, linux-kernel, Jameson Graef Rollins,
Jonathan Nieder, Jens Axboe, Amit Shah, David Zeuthen,
Martin Pitt
In-Reply-To: <20111028134743.GU14392@login.drsnuggles.stderr.nl>
Hello,
On Fri, Oct 28, 2011 at 03:47:43PM +0200, Matthijs Kooijman wrote:
> I'm not sure if the FRAME_POINTER option actually works, though, since I
> couldn't find any obvious differences in the format of the stack traces?
The lines w/o leading "?" are from stack frames discovered by
following frame pointer. The ones w/ "?" are from dumb stack
scanning. w/o FP, it wouldn't be possible to tell between the actual
ones from the spurious ones.
So, the following kworker is what the scsi_id is waiting for in
flush_work().
kworker/2:1 D ffff880206054830 0 10775 2 0x00000000
ffff880206067aa0 0000000000000046 ffff880206067a50 ffffffff8105476d
ffff88022ed58140 ffff880206067fd8 ffff880206067fd8 0000000000012f40
ffff880206054830 ffff88022ed58140 ffff880200000002 0000000000000286
Call Trace:
[<ffffffff8134c996>] schedule+0x55/0x57
[<ffffffff8134cc9f>] schedule_timeout+0xa2/0xd9
[<ffffffff8134c832>] wait_for_common+0x9e/0x115
[<ffffffff8134c925>] wait_for_completion_timeout+0xe/0x10
[<ffffffff8119c502>] blk_execute_rq+0xb7/0xf9
[<ffffffffa0043044>] scsi_execute+0xf5/0x14d [scsi_mod]
[<ffffffffa004311e>] scsi_execute_req+0x82/0xb4 [scsi_mod]
[<ffffffffa00bb2d9>] sr_check_events+0x92/0x21e [sr_mod]
[<ffffffffa009d04b>] cdrom_check_events+0x14/0x29 [cdrom]
[<ffffffffa00bb696>] sr_block_check_events+0x14/0x16 [sr_mod]
[<ffffffff8119ea7b>] disk_events_workfn+0x3b/0xd7
[<ffffffff8105dcc9>] process_one_work+0x165/0x27a
[<ffffffff8105ed4f>] worker_thread+0xce/0x152
[<ffffffff81061f6c>] kthread+0x7f/0x87
[<ffffffff81355034>] kernel_thread_helper+0x4/0x10
The kworker submitted request but it got lost during queue destruction
and blk_execute_rq() hangs. There have been a number of recent
changes in block devel tree to address this issue. Can you please
test the following branch?
git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git block-ref
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] document 'T' status from git-status
From: Mark Dominus @ 2011-10-30 20:34 UTC (permalink / raw)
To: git; +Cc: Mark Dominus
In-Reply-To: <7vmxcjro5t.fsf@alter.siamese.dyndns.org>
On 10/30/2011 02:25 AM, Junio C Hamano wrote:
> Mark Dominus<mjd@plover.com> writes:
>
>
>> +* 'T' = file type changed
>> + (typically from plain file to symlink, or vice versa)
>>
>> Ignored files are not listed, unless `--ignored` option is in effect,
>> in which case `XY` are `!!`.
>> @@ -134,9 +136,11 @@ in which case `XY` are `!!`.
>> D [ M] deleted from index
>> R [ MD] renamed in index
>> C [ MD] copied in index
>> + T [ MD] file type changed in index
>> [MARC] index and work tree matches
>> [ MARC] M work tree changed since index
>> [ MARC] D deleted in work tree
>> + [ MARC] T file type changed in work tree
> The current organization of this table may need to be rethought, but if we
> were to keep it, then this change is far from sufficient. For example, you
> do not explain what XY = TT means.
Thanks for your response.
I did not try to document that because in my experimenting I was not
able to produce that situation. T occurs when the filetype (as reported
by the IS_FMT macro) is different between the two files. On systems I
have available, there are essentially five filetypes: plain file,
symlink, directory, block and character devices. Directories are
handled separately and are not reported by git-status. Device files
cannot be added to the index at all. That leaves only two possible
filetypes, so of the three files (the committed version, the cached
version, and the working tree version) two must be the same.
I am aware that on some systems other filetypes may exist. For example,
HPUX has an 'H' filetype that is a variant of a directory. But git
would treat this as a directory. Since I was not aware of any situation
in which TT could arise, I did not try to document it.
Will you be applying the alternative patch you suggested, or would you
prefer that I try to produce one along those lines?
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd: tests: annotate as DANGEROUS in Kconfig
From: Artem Bityutskiy @ 2011-10-30 20:34 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-mtd
In-Reply-To: <1319992129-13588-1-git-send-email-w.sang@pengutronix.de>
On Sun, 2011-10-30 at 17:28 +0100, Wolfram Sang wrote:
> + WARNING: Some of the tests will ERASE THE CONTENT of mtd devices!
> + Do not use these tests unless you are sure you really need to.
Thanks, I've pushed this patch but amended the above text a bit:
+ WARNING: some of the tests will ERASE entire MTD device which they
+ test. Do not use these tests unless you really know what you do.
^ permalink raw reply
* [Buildroot] Some topics for the Buildroot Developer Day
From: Thomas Petazzoni @ 2011-10-30 20:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111024173815.2277c6dd@skate>
Le Mon, 24 Oct 2011 17:38:15 +0200,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :
> As discussed on IRC, I am posting below a list of topics that might be
> discussed during the developer day. Note that this is just _my_ list
> of topics, note the one of the Buildroot project as a whole. Moreover,
> it's very likely that not all topics will be covered during our
> meeting day. However, feel free to add your opinion and/or your
> additional topics, especially if you can't make it to the Developer
> day.
For information, the developer day took place on Saturday, as expected.
I am currently writing a detailed report of what has been said, it'll
be sent to the mailing list after review by other participants (in
order to make it as complete and accurate as possible). Hopefully
should be within this week.
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] pxa: fixes for next
From: Arnd Bergmann @ 2011-10-30 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO-SM88yeaQMG27MODCHCxDM3U=7=JDP0uphb_w-nfWAkQ@mail.gmail.com>
On Tuesday 25 October 2011, Eric Miao wrote:
> With that specific patch queued, see the updated request as below:
>
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
> Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
> git://github.com/ycmiao/pxa-linux.git fix
Merged into next/fixes.
Thanks a lot!
Arnd
^ permalink raw reply
* [Buildroot] [Bug 4399] Unable to use Ubuntu 11.10 arm cross compiler
From: bugzilla at busybox.net @ 2011-10-30 20:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4399-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4399
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 2011-10-30 20:27:21 UTC ---
I had the same problem trying to use the Ubuntu ARM cross-compiler.
Unfortunately, while it allows to go a bit further, it doesn't fix the fact
that the Ubuntu ARM cross-compiler is not a *pure* toolchain: it contains many
more libraries and utilities compiled for the target than a normal toolchain,
and this doesn't play well with build systems, including Buildroot.
For that reason, we do not support building with the Ubuntu ARM cross-compiler
at the moment. Either build your toolchain with Buildroot or Crosstool-NG, or
get a pre-compiled one from CodeSourcery (which offers pure toolchains).
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 1/2] batman-adv: Fix style changes reported by cppcheck
From: Marek Lindner @ 2011-10-30 20:24 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <1319988980-3548-1-git-send-email-siwu@hrz.tu-chemnitz.de>
On Sunday, October 30, 2011 16:36:20 Simon Wunderlich wrote:
> cppcheck reported some style issues this patch fixes.
>
> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
> ---
> bat_iv_ogm.c | 2 +-
> routing.c | 2 +-
> soft-interface.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
Do you mind saying what cppcheck reported ?
What happened to patch 2/2 ?
Regards,
Marek
^ permalink raw reply
* [U-Boot] [PATCH v6 4/4] usb: add USB support for Efika
From: Stefano Babic @ 2011-10-30 20:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110302118.18343.marek.vasut@gmail.com>
On 10/30/2011 09:18 PM, Marek Vasut wrote:
>> This commit adds USB support for EfikaMX and EfikaSB.
>>
>> Signed-off-by: Jana Rapava <fermata7@gmail.com>
>> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
>> Cc: Remy Bohmer <linux@bohmer.net>
>> Cc: Stefano Babic <sbabic@denx.de>
>>
>> Acked-by: Marek Vasut <marek.vasut@gmail.com>
>> ---
>> Changes for v2:
>> - introduce temporary variable in ulpi_write
>> - whitespace changes
>> Changes for v3:
>> - add protection against multiple inclusion of efika.h
>> Changes for v4:
>> - rename multiple inclusion protection macro in efika.h
>> Changes for v5:
>> - fix unterminated #ifndef in efika.h
>> Changes for v6:
>> - add Acked-by
>> - no changes
>>
>
> Guys, there's been no update on this for a month.
>
> Stefano, can you apply please? I see no negative comments.
I do not have seen any open issues, too. If nobody argues and because
they are related to USB for i.MX boards, I will apply them to u-boot-imx.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [GIT PULL] pxa: feature patches for next
From: Arnd Bergmann @ 2011-10-30 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO8A3OgzdKB_1t5ddY_JBtGvPUjphYYBs7zob0ik9he=Lw@mail.gmail.com>
On Tuesday 25 October 2011, Eric Miao wrote:
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
> Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
> git://github.com/ycmiao/pxa-linux.git feature
Hi Eric,
The code looks reasonable, but you sent the patches after the merge window
has already been opened. Please don't do that, you had enough time during the
3.1-rc cycle to send them. I'll take the patches this time because there
is just one functional change, but try to improve this next time.
See you tomorrow in Orlando,
Arnd
^ permalink raw reply
* [U-Boot] [PATCH] tx25: re-add MACH_TYPE_TX25
From: Wolfgang Denk @ 2011-10-30 20:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EADB0D2.8010000@denx.de>
Dear Stefano,
In message <4EADB0D2.8010000@denx.de> you wrote:
>
> Thanks for reporting, but....
>
> ..I have already sent a fix for this last week, using also the standard
> mechanism in arch/arm/lib/board.c to set the mach-id:
Sorry, I missed that. Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The Gates in my computer are AND, OR and NOT; they are not Bill.
^ permalink raw reply
* [U-Boot] [PATCH v6 4/4] usb: add USB support for Efika
From: Marek Vasut @ 2011-10-30 20:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1317314665-31835-1-git-send-email-fermata7@gmail.com>
> This commit adds USB support for EfikaMX and EfikaSB.
>
> Signed-off-by: Jana Rapava <fermata7@gmail.com>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Remy Bohmer <linux@bohmer.net>
> Cc: Stefano Babic <sbabic@denx.de>
>
> Acked-by: Marek Vasut <marek.vasut@gmail.com>
> ---
> Changes for v2:
> - introduce temporary variable in ulpi_write
> - whitespace changes
> Changes for v3:
> - add protection against multiple inclusion of efika.h
> Changes for v4:
> - rename multiple inclusion protection macro in efika.h
> Changes for v5:
> - fix unterminated #ifndef in efika.h
> Changes for v6:
> - add Acked-by
> - no changes
>
Guys, there's been no update on this for a month.
Stefano, can you apply please? I see no negative comments.
^ permalink raw reply
* [U-Boot] [PATCH] tx25: re-add MACH_TYPE_TX25
From: Stefano Babic @ 2011-10-30 20:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319980721-6615-1-git-send-email-wd@denx.de>
On 10/30/2011 02:18 PM, Wolfgang Denk wrote:
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> cc: Stefano Babic <sbabic@denx.de>
> ---
> include/configs/tx25.h | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/tx25.h b/include/configs/tx25.h
> index 8cb57ff..39d551e 100644
> --- a/include/configs/tx25.h
> +++ b/include/configs/tx25.h
> @@ -29,6 +29,10 @@
> #define CONFIG_MX25_CLK32 32000 /* OSC32K frequency */
> #define CONFIG_SYS_HZ 1000
>
> +#ifndef MACH_TYPE_TX25
> +#define MACH_TYPE_TX25 2177
> +#endif
> +
> #define CONFIG_SYS_MONITOR_LEN (256 << 10) /* 256 kB for U-Boot */
>
Thanks for reporting, but....
..I have already sent a fix for this last week, using also the standard
mechanism in arch/arm/lib/board.c to set the mach-id:
http://patchwork.ozlabs.org/patch/122357/
As a fix, I have already applied it and I inserted it in my pull-request
ro Albert. The patch is already in u-boot-arm and as far as I have
tested, there should be no broken IMX boards due to missing mach type.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
From: Tejun Heo @ 2011-10-30 20:16 UTC (permalink / raw)
To: David Fries; +Cc: linux-kernel, netdev, Rafael J. Wysocki, linux-pm
In-Reply-To: <20111030044821.GA23741@spacedout.fries.net>
(cc'ing Rafael and linux-pm)
On Sat, Oct 29, 2011 at 11:48:21PM -0500, David Fries wrote:
> I saw the write up on this on lwn.net, pretty creative by the way, and
> it got me thinking about a different checkpoint/restart problem I've
> been running into. Specifically in hibernating to disk. In the
> hibernate case active TCP connections hang after resuming, while an
> idle TCP connection will continue after the system is back up. My
> observation is the kernel checkpoints itself to memory, enables
> devices, writes out that checkpoint image to storage, then powers off.
> The problem is if TCP packets are received while writing to storage,
> the kernel will continue to queue and ack those TCP packets, but the
> running kernel and it's network state is shortly lost. When the
> computer resumes, those TCP byte sequences hang the TCP connection for
> an extended period of time while the resumed computer refuses to
> acknowledge the data that was received after checkpointing and the now
> running kernel knew nothing about, and the other computer tries in
> vain to resend any data that hadn't yet been acknowledged, which is
> always after the data that was lost, until one of them eventually
> gives up.
>
> I've been wondering if it was safe or possible to leave any network
> interfaces down after the checkpoint, or what the right solution would
> be. I didn't think marking every TCP connection with a ZOMBIE_KERNEL
> bit just after the kernel checkpoint (for the kernel is walking dead
> and won't remember anything that happens), and then prevent any TCP
> acks from being sent for those connections would be the right
> solution. I've taken to unplugging the physical lan cable,
> hibernating to disk, and plugging it back in after the system is down,
> to avoid the problem. Any ideas?
Hmmm... sounds like taking down network interfaces before starting
hibernation sequence should be enough, which shouldn't be too
difficult to implement from userland. Rafael, what do you think?
Thanks.
--
tejun
^ permalink raw reply
* Re: hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
From: Tejun Heo @ 2011-10-30 20:16 UTC (permalink / raw)
To: David Fries; +Cc: netdev, linux-pm, linux-kernel
In-Reply-To: <20111030044821.GA23741@spacedout.fries.net>
(cc'ing Rafael and linux-pm)
On Sat, Oct 29, 2011 at 11:48:21PM -0500, David Fries wrote:
> I saw the write up on this on lwn.net, pretty creative by the way, and
> it got me thinking about a different checkpoint/restart problem I've
> been running into. Specifically in hibernating to disk. In the
> hibernate case active TCP connections hang after resuming, while an
> idle TCP connection will continue after the system is back up. My
> observation is the kernel checkpoints itself to memory, enables
> devices, writes out that checkpoint image to storage, then powers off.
> The problem is if TCP packets are received while writing to storage,
> the kernel will continue to queue and ack those TCP packets, but the
> running kernel and it's network state is shortly lost. When the
> computer resumes, those TCP byte sequences hang the TCP connection for
> an extended period of time while the resumed computer refuses to
> acknowledge the data that was received after checkpointing and the now
> running kernel knew nothing about, and the other computer tries in
> vain to resend any data that hadn't yet been acknowledged, which is
> always after the data that was lost, until one of them eventually
> gives up.
>
> I've been wondering if it was safe or possible to leave any network
> interfaces down after the checkpoint, or what the right solution would
> be. I didn't think marking every TCP connection with a ZOMBIE_KERNEL
> bit just after the kernel checkpoint (for the kernel is walking dead
> and won't remember anything that happens), and then prevent any TCP
> acks from being sent for those connections would be the right
> solution. I've taken to unplugging the physical lan cable,
> hibernating to disk, and plugging it back in after the system is down,
> to avoid the problem. Any ideas?
Hmmm... sounds like taking down network interfaces before starting
hibernation sequence should be enough, which shouldn't be too
difficult to implement from userland. Rafael, what do you think?
Thanks.
--
tejun
^ 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.