* Re: [patch 28/28] posix clocks: Introduce dynamic clocks
From: Thomas Gleixner @ 2011-02-01 22:04 UTC (permalink / raw)
To: john stultz; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <1296596987.3336.83.camel@work-vm>
On Tue, 1 Feb 2011, john stultz wrote:
> On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (posix-clocks-introduce-dynamic-clocks.patch)
> > From: Richard Cochran <richardcochran@gmail.com>
> >
> > This patch adds support for adding and removing posix clocks. The
> > clock lifetime cycle is patterned after usb devices. Each clock is
> > represented by a standard character device. In addition, the driver
> > may optionally implement custom character device operations.
> >
> > The posix clock and timer system calls listed below now work with
> > dynamic posix clocks, as well as the traditional static clocks.
> > The following system calls are affected:
> >
> > - clock_adjtime (brand new syscall)
> > - clock_gettime
> > - clock_getres
> > - clock_settime
> > - timer_create
> > - timer_delete
> > - timer_gettime
> > - timer_settime
> >
> > [ tglx: Adapted to the posix-timer cleanup. Moved clock_posix_dynamic
> > to posix-clock.c and made all referenced functions static ]
>
> I sort of worry about the naming collision with the term posix-clock, as
> this is just one type of posix clock (I suspect most folks think of a
> posix clock as the clockid passed to the existing posix api).
Well that's kernel internal and not the posix-timer syscalls.
> Could we maybe use posix-dynclock or posix-fdclock or something? I know
> its already been changed from clkdev, so sorry for being finicky here
> and not catching this earlier.
I'm fine with the name as is and it's well documented.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH net-2.6] bnx2x: multicasts in NPAR mode
From: David Miller @ 2011-02-01 22:05 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <201102011257.11610.vladz@broadcom.com>
From: "Vlad Zolotarov" <vladz@broadcom.com>
Date: Tue, 1 Feb 2011 12:57:10 +0200
> The chip was erroneously configured to accept all multicast frames
> in a normal (none-promisc) rx mode both on the RSS and on the FCoE L2 rings
> when in an NPAR mode. This caused packet duplication for every received multicast
> frame in this mode.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks Vlad.
^ permalink raw reply
* Re: What's the typical RAID10 setup?
From: Stan Hoeppner @ 2011-02-01 22:05 UTC (permalink / raw)
To: Jon Nelson; +Cc: David Brown, linux-raid
In-Reply-To: <AANLkTin1MPYZGMuL75c=_q+ndeiz0F5+eCRudpDdTwu9@mail.gmail.com>
Jon Nelson put forth on 2/1/2011 7:50 AM:
> The performance will not be the same because. Whenever possible, md
> reads from the outermost portion of the disk -- theoretically the
> fastest portion of the disk (by 2 or 3 times as much as the inner
> tracks) -- and in this way raid10,f2 can actually be faster than
> raid0.
Faster in what regard? I assume you mean purely sequential read, and not random
IOPS. The access patterns of the vast majority of workloads are random, so I
don't see much real world benefit, if what you say is correct. This might
benefit MythTV or similar niche streaming apps.
--
Stan
^ permalink raw reply
* Re: PCI passthrough issue
From: Jean Baptiste Favre @ 2011-02-01 22:06 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <20110201193743.GA18656@dumpdata.com>
Le 01/02/2011 20:37, Konrad Rzeszutek Wilk a écrit :
> On Tue, Feb 01, 2011 at 04:23:09PM +0000, Ian Campbell wrote:
>> On Tue, 2011-02-01 at 15:38 +0000, Jean Baptiste Favre wrote:
>>> OK, just found it:
>>> after domU boot:
>>> - log in
>>> - ping -s 86 10.0.0.1 (fails)
>>> - rmmod sky2
>>> - modprobe sky2 copybreak=0 (no packet copied)
>>> - ping -s 86 10.0.0.1 (works)
>>>
>>> So it's clearly related to that option.
>>
>> Awesome!
>>
>>> Now the question: what am I supposed to do ?
>>
>> I think the next step is to try and reproduce on native 32 bit, with RAM
>> artificially limited via the mem= kernel command in option, this will
>> let us determine if this is a generic issue or is somehow Xen specific.
>>
>> The main difference caused by the copybreak option is that for larger
>> frames (i.e. always when copybreak==0) it hits a code path which uses
>> pci_map_single and pci_map_page to access the received data. When len <
>> copybreak it takes a path which uses pci_dma_sync_single_for_cpu, so it
>> seems like the later path is broken somehow. If the issue does turn out
>
> It could also have gotten the direction reverted (the 3c5XX code had it
> wrong at some point so..). Might make sense to compile the kernel with
> CONFIG_DMA_API_DEBUG which is good at detecting these issues.
>
>> to be related to Xen then I think that points to the swiotlb code.
>
>>
>> I assume you are not seeing "rx mapping error" in your domU dmesg? Did
>> you post a full guest console log at some point? Comparing the logs for
>> the 256MB, 398MB and 512MB guest RAM case might be useful.
>>
>> Konrad, is there some way to force swiotlb use even for native to make
>> the native test cases more relevant? Or is there some other direction we
>
> swiotlb=force will do it.
I already use this option as specified on wiki:
http://wiki.xen.org/xenwiki/XenPCIpassthrough
>> should try first?
>
> <shakes his head> I think we have a good lead.
So let's go for testing that way :)
>>> It seems that adding this options in /etc/modprobe.d/sky2.conf does not
>>> work, neither using /etc/modules
>
> You could just pass as Linux kernel parameter 'sky2.copybreak=0'. But I am
> not sure if that stays if the 'sky2' driver is compiled as module.
According to Ian, this will work only with statically compiled driver.
^ permalink raw reply
* Re: [Patch 0/4] Fix error handling in hfsplus mount failure paths
From: Christoph Hellwig @ 2011-02-01 22:07 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Christoph Hellwig, linux-kernel
In-Reply-To: <20110201162802.2dd07201@katamari>
On Tue, Feb 01, 2011 at 04:28:02PM -0500, Chuck Ebbert wrote:
> hfsplus can generate NULL pointer exceptions when a user attempts
> to mount an invalid filesystem. In some paths it also leaks memory.
>
> This series attempts to fix some of the most obvious problems.
Not in a very nice way, though. The real problem here is that we
a) can still return a failure after sb->s_root is set
b) abuse hfsplus_put_super for error handling, which is totally
ill-suited.
Take a look at the patch in
https://bugzilla.kernel.org/show_bug.cgi?id=27932 for a proper fix.
^ permalink raw reply
* Re: poky-image-sato-sdk failed at do_rootfs
From: Wolfgang Denk @ 2011-02-01 22:08 UTC (permalink / raw)
To: Mark Hatle; +Cc: poky@yoctoproject.org
In-Reply-To: <4D486662.6020403@windriver.com>
Dear Mark,
In message <4D486662.6020403@windriver.com> you wrote:
> The failure indicated in your logs comes from building pseudo-native. This is
> not related to the previous messages you sent.
>
> What is the host system type (Fedora, RHEL, etc), what is your byte size?
> 32-bit or 64-bit kernel... any anything else you can give us to reproduce your
> configuration.
This is a Fedora 14 x86_64 host.
> The error below is fairly obvious.. it tried to build a 32-bit version of the
> pseudo libraries, this build failed due to a lack of 32-bit libgcc.so installed
> on your host.
>
> If I had to guess you have a 64-bit Fedora or RHEL host, and only partial 32-bit
> support installed. Check using rpm or yum if you have the 32-bit libgcc-devel
> package installed. (I'd also check for 32-bit glibc-devel).
$ rpm -qa | grep glibc | sort
arm-gp2x-linux-glibc-2.3.6-8.fc14.noarch
glibc-2.12.90-21.i686
glibc-2.12.90-21.x86_64
glibc-common-2.12.90-21.x86_64
glibc-devel-2.12.90-21.i686
glibc-devel-2.12.90-21.x86_64
glibc-headers-2.12.90-21.x86_64
I am aware that the standard installation of poky-scripts and
poky-depends is not sufficient on Fedora. Additionally, I installed
xmlto-tex, glibc-devel.i686, zlib-devel.i686, and chrpath
This used to satisfy all requirements, at least so far. It used to
work before.
libgcc_s is normally provided by the gcc RPM:
$ rpm -qf /usr/lib/gcc/x86_64-redhat-linux/4.5.1/libgcc_s.so
gcc-4.5.1-4.fc14.x86_64
But there is no gcc-4.5.1-4.fc14.i686 available for installation in a
x86_64 environment.
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@denx.de
The human race has one really effective weapon, and that is laughter.
- Mark Twain
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCHv2] batctl: add raw wifi packet decapsulation support
From: Marek Lindner @ 2011-02-01 22:08 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <1296317807-13584-1-git-send-email-lindner_marek@yahoo.de>
On Saturday 29 January 2011 17:16:47 Marek Lindner wrote:
> Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Applied in revision 1929.
Regards,
Marek
^ permalink raw reply
* Re: [Patch 1/4] hfsplus: Don't leak buffer on error
From: Christoph Hellwig @ 2011-02-01 22:08 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Christoph Hellwig, linux-kernel
In-Reply-To: <20110201164155.1a4c9ff6@katamari>
This one looks good though, I'll put it in.
On Tue, Feb 01, 2011 at 04:41:55PM -0500, Chuck Ebbert wrote:
> hfsplus: Don't leak buffer on error
That's already said in the subject, no need to repeat it in the mail
body.
^ permalink raw reply
* Kernel panic using add_mtd_partitions
From: ANDY KENNEDY @ 2011-02-01 22:13 UTC (permalink / raw)
To: linux-mtd
123456789012345678901234567890123456789012345678901234567890123456789012
I have gotten past the issue of not being able to see the NAND chip and
am working that issue (a symptom of an unrelated issue).
Now I'm attempting to use add_mtd_partitions() to specify the
partitions.
In the original kernel I was using (2.6.29) this worked without any
issue. In 2.6.36.1, the kernel panics. The code I'm attempting to use
to configure the partitions is as follows:
__maybe_unused static struct mtd_partition nand_partition_info[] =
{
{ .name = "Kernel partition",
.offset = 0,
.size = 4 * 1024 * 1024,
},
{ .name = "Root partition",
.offset = MTDPART_OFS_APPEND,
.size = MTDPART_SIZ_FULL,
},
};
add_mtd_partitions(&board_mtd, nand_partition_info,
ARRAY_SIZE(nand_partition_info));
Any help would be great!
Thanks,
Andy
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Junio C Hamano @ 2011-02-01 22:09 UTC (permalink / raw)
To: Jay Soffian; +Cc: Thomas Rast, git
In-Reply-To: <AANLkTi=Y9PBs_jXyCiAL9YLA8Y_jzWwqxw63hKm7fVBO@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Would it make sense to group the pre-1.8 compatibility switches
> together in some way, if there will be several of them? Maybe
>
> [compat]
> fetchUpdateRemoteNamespace = false
> ...
I don't think so.
If these configuration variables are expected to be removed in some
future, such a layout might make sense, but what is proposed is to default
them to a different behaviour from today at 1.8.0 boundary, and we are not
going to remove the ability to invoke the current behaviour with these
variables. It would make it a lot easier to find and understand if the
variables are grouped by functionality like all the other regular
variables, as these new ones are after all regular ones.
Just thinking aloud, too.
^ permalink raw reply
* Re: 2.6.38-rc3 regression on parisc: segfaults
From: James Bottomley @ 2011-02-01 22:12 UTC (permalink / raw)
To: Meelis Roos; +Cc: linux-parisc, Linux Kernel list
In-Reply-To: <alpine.SOC.1.00.1102012342200.25944@math.ut.ee>
On Wed, 2011-02-02 at 00:00 +0200, Meelis Roos wrote:
> I have been testing devel kernels on SMP L1000 successfully until
> 2.6.38-rc2-00324-g70d1f36 included. The testing means booting the new
> kernel and running aptitude to update to current debian unstable.
>
> Now I tried 2.6.38-rc3 and got a crash from aptitude on 2 out of 2
> tries. Maybe aptitude was broken inbetween but it looks like a kernel
> bug. Retried 2.6.38-rc2-00324-g70d1f36 and that seemed to work fine so
> it's more likely a kernel problem.
>
> What additional information can I provide?
Probably a bisection, if you could. There have been no parisc patches
between -rc2 and -rc3, so it's coming from outside the architecture.
Thanks,
James
^ permalink raw reply
* Re: [Patch 3/4] hfsplus: Clear volume header pointers on failure
From: Christoph Hellwig @ 2011-02-01 22:13 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Christoph Hellwig, linux-kernel
In-Reply-To: <20110201164507.3e642bb3@katamari>
On Tue, Feb 01, 2011 at 04:45:07PM -0500, Chuck Ebbert wrote:
> hfsplus: Clear volume header pointers on failure
>
> The next patch will use NULL volume header to determine whether
> to flush the superblock. Also fix two failure cases so they
> clear the headers before exiting.
Can you resend it without the NULLing out, which is not required
with proper error handling?
^ permalink raw reply
* Re: [1.8.0] split largest remaining scripts, gitk and gitweb
From: Junio C Hamano @ 2011-02-01 22:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <m38vxzaa03.fsf_-_@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Two largest files in git repository are gitk and gitweb, see the
> ...
> What do you think?
What does this have to do anything with 1.8.0? Isn't this all internal
implementation that can be brought in without affecting end users?
^ permalink raw reply
* Re: [1.8.0] Remove deprecated commands
From: Junio C Hamano @ 2011-02-01 22:16 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4D4852EE.6080605@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> The following four commands have been marked as deprecated in
> command-list.txt for quite some time[*]:
>
> command deprecated since replaced by
> ---------------- ---------------- ---------------------
> git-lost-found 2007-11-08 git fsck --lost-found
> git-peek-remote 2007-11-24 git ls-remote
> git-repo-config 2008-01-17 git config
> git-tar-tree 2007-11-08 git archive
>
> Let's just remove them. There's a risk that someone is still using the
> old commands, of course, but they have been deprecated long enough now.
Sounds fine.
^ permalink raw reply
* Re: 2.6.38-rc3 regression on parisc: segfaults
From: Carlos O'Donell @ 2011-02-01 22:16 UTC (permalink / raw)
To: Meelis Roos; +Cc: linux-parisc, Linux Kernel list
In-Reply-To: <alpine.SOC.1.00.1102012342200.25944@math.ut.ee>
On Tue, Feb 1, 2011 at 5:00 PM, Meelis Roos <mroos@linux.ee> wrote:
> I have been testing devel kernels on SMP L1000 successfully until
> 2.6.38-rc2-00324-g70d1f36 included. The testing means booting the new
> kernel and running aptitude to update to current debian unstable.
>
> Now I tried 2.6.38-rc3 and got a crash from aptitude on 2 out of 2
> tries. Maybe aptitude was broken inbetween but it looks like a kernel
> bug. Retried 2.6.38-rc2-00324-g70d1f36 and that seemed to work fine s=
o
> it's more likely a kernel problem.
>
> What additional information can I provide?
>
> [ =A0 74.590000]
> [ =A0 74.590000] do_page_fault() pid=3D979 command=3D'aptitude' type=3D=
15 address=3D0x0000002d
> [ =A0 74.590000]
> [ =A0 74.590000] =A0 =A0 =A0YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [ =A0 74.590000] PSW: 00000000000001001111111100001111 Not tainted
> [ =A0 74.590000] r00-03 =A0000000ff0004ff0f 000000004027b5ac 00000000=
405df23b 000000004067e884
> [ =A0 74.590000] r04-07 =A0000000004067c860 000000004067e6d0 00000000=
4067e880 00000000c014b7d0
> [ =A0 74.590000] r08-11 =A00000000000000001 0000000000000001 00000000=
4067c860 0000000041b082c8
> [ =A0 74.590000] r12-15 =A0000000004067e730 000000004067e6d0 00000000=
4067c860 000000004067c860
> [ =A0 74.590000] r16-19 =A0000000004067c860 000000004067e060 00000000=
00000000 000000004067c860
> [ =A0 74.590000] r20-23 =A00000000000000229 0000000000000000 00000000=
00000000 0000000000000000
> [ =A0 74.590000] r24-27 =A0fffffffffffffff5 ffffffffffffffd3 00000000=
4067e730 00000000004227a4
> [ =A0 74.590000] r28-31 =A0000000000000002d 0000000000000000 00000000=
c014b8c0 00000000402688db
> [ =A0 74.590000] sr00-03 =A00000000000228800 0000000000228800 0000000=
000000000 0000000000228800
> [ =A0 74.590000] sr04-07 =A00000000000228800 0000000000228800 0000000=
000228800 0000000000228800
> [ =A0 74.590000]
> [ =A0 74.590000] =A0 =A0 =A0 VZOUICununcqcqcqcqcqcrmunTDVZOUI
> [ =A0 74.590000] FPSR: 00001000001000100010000000000000
> [ =A0 74.590000] FPER1: 00000000
> [ =A0 74.590000] fr00-03 =A00822200000000000 0000000000000000 0000000=
000000000 0000000000000000
> [ =A0 74.590000] fr04-07 =A00000000a00000000 0000000000000000 0000000=
000000000 0000000000000000
> [ =A0 74.590000] fr08-11 =A00000000000000000 00000000406cf120 0000000=
0401563e8 00000000404c59d8
> [ =A0 74.590000] fr12-15 =A0000000000804000f 000000000800000f 0000000=
0401563e8 00000000ffc60460
> [ =A0 74.590000] fr16-19 =A000000000406cf120 0000000040639d54 0000000=
000000046 0000000040599294
> [ =A0 74.590000] fr20-23 =A000000000ffc60348 00000000406dd920 0000000=
000000038 4038000000000000
> [ =A0 74.590000] fr24-27 =A00000000000000000 0000000000000000 3ff0000=
000000000 412e848c00000000
> [ =A0 74.590000] fr28-31 =A00000000040599250 00000000ffc60357 0000000=
0ffc60357 00000000405dfba8
> [ =A0 74.590000]
> [ =A0 74.590000] IASQ: 0000000000228800 0000000000228800 IAOQ: 000000=
00405df25b 00000000405df25f
> [ =A0 74.590000] =A0IIR: 0f80108b =A0 =A0ISR: 0000000000228800 =A0IOR=
: 000000000000002d
> [ =A0 74.590000] =A0CPU: =A0 =A0 =A0 =A00 =A0 CR30: 00000000fe050000 =
CR31: 0000000000008020
> [ =A0 74.590000] =A0ORIG_R28: 0000000000000080
> [ =A0 74.590000] =A0IAOQ[0]: 00000000405df25b
> [ =A0 74.590000] =A0IAOQ[1]: 00000000405df25f
> [ =A0 74.590000] =A0RP(r2): 00000000405df23b
The rp (return pointer) is pointing back into what appears to be a
shared library (always loaded around 0x4???????).
The iir (interrupting instruction register) is instruction "0: 0f 80
10 8b ldw 0(ret0),r11" (you can do this yourself with "disasm"
from http://cvs.parisc-linux.org/build-tools/disasm?revision=3D1.1&view=
=3Dmarkup).
You can see that ret0 is indeed 0x2d (the address of the fault), and
loading 0x0 + 0x2d will cause a fault and kill your program.
However, the failure probably happened earlier.
As James says, you should try to bisect exactly which commit caused the=
failure.
Cheers,
CArlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 2.6.38-rc3 regression on parisc: segfaults
From: Carlos O'Donell @ 2011-02-01 22:16 UTC (permalink / raw)
To: Meelis Roos; +Cc: linux-parisc, Linux Kernel list
In-Reply-To: <alpine.SOC.1.00.1102012342200.25944@math.ut.ee>
On Tue, Feb 1, 2011 at 5:00 PM, Meelis Roos <mroos@linux.ee> wrote:
> I have been testing devel kernels on SMP L1000 successfully until
> 2.6.38-rc2-00324-g70d1f36 included. The testing means booting the new
> kernel and running aptitude to update to current debian unstable.
>
> Now I tried 2.6.38-rc3 and got a crash from aptitude on 2 out of 2
> tries. Maybe aptitude was broken inbetween but it looks like a kernel
> bug. Retried 2.6.38-rc2-00324-g70d1f36 and that seemed to work fine so
> it's more likely a kernel problem.
>
> What additional information can I provide?
>
> [ 74.590000]
> [ 74.590000] do_page_fault() pid=979 command='aptitude' type=15 address=0x0000002d
> [ 74.590000]
> [ 74.590000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [ 74.590000] PSW: 00000000000001001111111100001111 Not tainted
> [ 74.590000] r00-03 000000ff0004ff0f 000000004027b5ac 00000000405df23b 000000004067e884
> [ 74.590000] r04-07 000000004067c860 000000004067e6d0 000000004067e880 00000000c014b7d0
> [ 74.590000] r08-11 0000000000000001 0000000000000001 000000004067c860 0000000041b082c8
> [ 74.590000] r12-15 000000004067e730 000000004067e6d0 000000004067c860 000000004067c860
> [ 74.590000] r16-19 000000004067c860 000000004067e060 0000000000000000 000000004067c860
> [ 74.590000] r20-23 0000000000000229 0000000000000000 0000000000000000 0000000000000000
> [ 74.590000] r24-27 fffffffffffffff5 ffffffffffffffd3 000000004067e730 00000000004227a4
> [ 74.590000] r28-31 000000000000002d 0000000000000000 00000000c014b8c0 00000000402688db
> [ 74.590000] sr00-03 0000000000228800 0000000000228800 0000000000000000 0000000000228800
> [ 74.590000] sr04-07 0000000000228800 0000000000228800 0000000000228800 0000000000228800
> [ 74.590000]
> [ 74.590000] VZOUICununcqcqcqcqcqcrmunTDVZOUI
> [ 74.590000] FPSR: 00001000001000100010000000000000
> [ 74.590000] FPER1: 00000000
> [ 74.590000] fr00-03 0822200000000000 0000000000000000 0000000000000000 0000000000000000
> [ 74.590000] fr04-07 0000000a00000000 0000000000000000 0000000000000000 0000000000000000
> [ 74.590000] fr08-11 0000000000000000 00000000406cf120 00000000401563e8 00000000404c59d8
> [ 74.590000] fr12-15 000000000804000f 000000000800000f 00000000401563e8 00000000ffc60460
> [ 74.590000] fr16-19 00000000406cf120 0000000040639d54 0000000000000046 0000000040599294
> [ 74.590000] fr20-23 00000000ffc60348 00000000406dd920 0000000000000038 4038000000000000
> [ 74.590000] fr24-27 0000000000000000 0000000000000000 3ff0000000000000 412e848c00000000
> [ 74.590000] fr28-31 0000000040599250 00000000ffc60357 00000000ffc60357 00000000405dfba8
> [ 74.590000]
> [ 74.590000] IASQ: 0000000000228800 0000000000228800 IAOQ: 00000000405df25b 00000000405df25f
> [ 74.590000] IIR: 0f80108b ISR: 0000000000228800 IOR: 000000000000002d
> [ 74.590000] CPU: 0 CR30: 00000000fe050000 CR31: 0000000000008020
> [ 74.590000] ORIG_R28: 0000000000000080
> [ 74.590000] IAOQ[0]: 00000000405df25b
> [ 74.590000] IAOQ[1]: 00000000405df25f
> [ 74.590000] RP(r2): 00000000405df23b
The rp (return pointer) is pointing back into what appears to be a
shared library (always loaded around 0x4???????).
The iir (interrupting instruction register) is instruction "0: 0f 80
10 8b ldw 0(ret0),r11" (you can do this yourself with "disasm"
from http://cvs.parisc-linux.org/build-tools/disasm?revision=1.1&view=markup).
You can see that ret0 is indeed 0x2d (the address of the fault), and
loading 0x0 + 0x2d will cause a fault and kill your program.
However, the failure probably happened earlier.
As James says, you should try to bisect exactly which commit caused the failure.
Cheers,
CArlos.
^ permalink raw reply
* Re: [patch 3/7] [PATCH] net,s390: provide architecture specific NET_SKB_PAD
From: David Miller @ 2011-02-01 22:17 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390, horsth
In-Reply-To: <20110201081723.562745244@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Tue, 01 Feb 2011 09:16:50 +0100
> From: Horst Hartmann <horsth@linux.vnet.ibm.com>
>
> NET_SKB_PAD has been increased from 32 to 64 and later to max(32, L1_CACHE_BYTES).
> This led to a 25% throughput decrease for streaming workloads accompanied by a
> 37% CPU cost increase on s390.
> In order to fix this provide an architecture specific NET_SKB_PAD config symbol.
>
> Signed-off-by: Horst Hartmann <horsth@linux.vnet.ibm.com>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Define it in your arch specific header file like it is designed to
be overridden.
Also, even if this Kconfig thing was the right thing to do, you would
need to put a default for it generically in init/Kconfig or
lib/Kconfig or similar. As this is where the central documentation
for the knob would be placed.
Lastly, you failed in your commit message to describe why you wanted
to use this whacky Kconfig mechanism to override instead of using
a straight CPP define in the s390 headers.
You're modifying generic code, so you better explain what you're doing
and exactly why.
I'm not applying this series until you fix up this change, resubmit
the entire series when you have this stuff fixed up.
Thanks.
^ permalink raw reply
* Re: [PATCH] isdn: icn: Fix potentially wrong string handling
From: David Miller @ 2011-02-01 22:18 UTC (permalink / raw)
To: weil; +Cc: isdn, tj, rostedt, netdev, linux-kernel
In-Reply-To: <1296419486-5482-1-git-send-email-weil@mail.berlios.de>
From: Stefan Weil <weil@mail.berlios.de>
Date: Sun, 30 Jan 2011 21:31:26 +0100
> This warning was reported by cppcheck:
> drivers/isdn/icn/icn.c:1641: error: Dangerous usage of 'rev' (strncpy doesn't always 0-terminate it)
>
> If strncpy copied 20 bytes, the destination string rev was not terminated.
> The patch adds one more byte to rev and makes sure that this byte is
> always 0.
>
> Cc: Karsten Keil <isdn@linux-pingi.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 05/18] wl1251: retry power save entry
From: Kalle Valo @ 2011-02-01 22:18 UTC (permalink / raw)
To: David Gnedt
Cc: John W. Linville, linux-wireless, Grazvydas Ignotas,
Denis 'GNUtoo' Carikli
In-Reply-To: <4D45A5AD.4010402@davizone.at>
David Gnedt <david.gnedt@davizone.at> writes:
> Port of the power save entry retry code from wl1251 driver version included
> in the Maemo Fremantle kernel.
> This tries to enable power save mode up to 3 times before failing.
[...]
> + if (wl->psm_entry_retry < WL1251_PSM_ENTRY_RETRIES) {
> + wl->psm_entry_retry++;
> + ret = wl1251_ps_set_mode(wl, STATION_POWER_SAVE_MODE);
> + } else {
> + wl1251_error("Power save entry failed, giving up");
> + wl->psm_entry_retry = 0;
> + }
If firmware fails to send the nullfunc frame, something is wrong with
the connection and we should notify about this to mac80211. At least
wl12xx uses ieee80211_connection_loss(), maybe that's the best option
here?
--
Kalle Valo
^ permalink raw reply
* Re: [patch 1/3] mn10300: Remove stale code
From: john stultz @ 2011-02-01 22:18 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, David Howells, Koichi Yasutake, Mark Salter
In-Reply-To: <20110131131808.822602368@linutronix.de>
On Mon, 2011-01-31 at 13:19 +0000, Thomas Gleixner wrote:
> plain text document attachment (mn10300-remove-stale-code.patch)
> mn10300 implements clocksource and clockevents and selects them
> unconditionally in Kconfig. Remove the stale code which seems to be a
> leftover of the conversion. Cleanup the configuration switches as well.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
> Cc: Mark Salter <msalter@redhat.com>
Acked-by: John Stultz <johnstul@us.ibm.com>
> ---
> arch/mn10300/Kconfig | 15 ------------
> arch/mn10300/kernel/Makefile | 5 +---
> arch/mn10300/kernel/time.c | 53 -------------------------------------------
> 3 files changed, 2 insertions(+), 71 deletions(-)
>
> Index: linux-2.6/arch/mn10300/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/mn10300/Kconfig
> +++ linux-2.6/arch/mn10300/Kconfig
> @@ -53,21 +53,6 @@ config GENERIC_TIME
> config GENERIC_CLOCKEVENTS
> def_bool y
>
> -config GENERIC_CLOCKEVENTS_BUILD
> - def_bool y
> - depends on GENERIC_CLOCKEVENTS
> -
> -config GENERIC_CLOCKEVENTS_BROADCAST
> - bool
> -
> -config CEVT_MN10300
> - def_bool y
> - depends on GENERIC_CLOCKEVENTS
> -
> -config CSRC_MN10300
> - def_bool y
> - depends on GENERIC_TIME
> -
> config GENERIC_BUG
> def_bool y
>
> Index: linux-2.6/arch/mn10300/kernel/Makefile
> ===================================================================
> --- linux-2.6.orig/arch/mn10300/kernel/Makefile
> +++ linux-2.6/arch/mn10300/kernel/Makefile
> @@ -8,7 +8,8 @@ fpu-obj-$(CONFIG_FPU) := fpu.o fpu-low.o
>
> obj-y := process.o signal.o entry.o traps.o irq.o \
> ptrace.o setup.o time.o sys_mn10300.o io.o kthread.o \
> - switch_to.o mn10300_ksyms.o kernel_execve.o $(fpu-obj-y)
> + switch_to.o mn10300_ksyms.o kernel_execve.o $(fpu-obj-y) \
> + csrc-mn10300.o cevt-mn10300.o
>
> obj-$(CONFIG_SMP) += smp.o smp-low.o
>
> @@ -28,5 +29,3 @@ obj-$(CONFIG_MN10300_RTC) += rtc.o
> obj-$(CONFIG_PROFILE) += profile.o profile-low.o
> obj-$(CONFIG_MODULES) += module.o
> obj-$(CONFIG_KPROBES) += kprobes.o
> -obj-$(CONFIG_CSRC_MN10300) += csrc-mn10300.o
> -obj-$(CONFIG_CEVT_MN10300) += cevt-mn10300.o
> Index: linux-2.6/arch/mn10300/kernel/time.c
> ===================================================================
> --- linux-2.6.orig/arch/mn10300/kernel/time.c
> +++ linux-2.6/arch/mn10300/kernel/time.c
> @@ -93,47 +93,6 @@ irqreturn_t local_timer_interrupt(void)
> return IRQ_HANDLED;
> }
>
> -#ifndef CONFIG_GENERIC_TIME
> -/*
> - * advance the kernel's time keeping clocks (xtime and jiffies)
> - * - we use Timer 0 & 1 cascaded as a clock to nudge us the next time
> - * there's a need to update
> - */
> -static irqreturn_t timer_interrupt(int irq, void *dev_id)
> -{
> - unsigned tsc, elapse;
> - irqreturn_t ret;
> -
> - write_seqlock(&xtime_lock);
> -
> - while (tsc = get_cycles(),
> - elapse = tsc - mn10300_last_tsc, /* time elapsed since last
> - * tick */
> - elapse > MN10300_TSC_PER_HZ
> - ) {
> - mn10300_last_tsc += MN10300_TSC_PER_HZ;
> -
> - /* advance the kernel's time tracking system */
> - do_timer(1);
> - }
> -
> - write_sequnlock(&xtime_lock);
> -
> - ret = local_timer_interrupt();
> -#ifdef CONFIG_SMP
> - send_IPI_allbutself(LOCAL_TIMER_IPI);
> -#endif
> - return ret;
> -}
> -
> -static struct irqaction timer_irq = {
> - .handler = timer_interrupt,
> - .flags = IRQF_DISABLED | IRQF_SHARED | IRQF_TIMER,
> - .name = "timer",
> -};
> -#endif /* CONFIG_GENERIC_TIME */
> -
> -#ifdef CONFIG_CSRC_MN10300
> void __init clocksource_set_clock(struct clocksource *cs, unsigned int clock)
> {
> u64 temp;
> @@ -149,9 +108,7 @@ void __init clocksource_set_clock(struct
> cs->shift = shift;
> cs->mult = (u32) temp;
> }
> -#endif
>
> -#if CONFIG_CEVT_MN10300
> void __cpuinit clockevent_set_clock(struct clock_event_device *cd,
> unsigned int clock)
> {
> @@ -168,7 +125,6 @@ void __cpuinit clockevent_set_clock(stru
> cd->shift = shift;
> cd->mult = (u32) temp;
> }
> -#endif
>
> /*
> * initialise the various timers used by the main part of the kernel
> @@ -181,11 +137,7 @@ void __init time_init(void)
> */
> TMPSCNT |= TMPSCNT_ENABLE;
>
> -#ifdef CONFIG_GENERIC_TIME
> init_clocksource();
> -#else
> - startup_timestamp_counter();
> -#endif
>
> printk(KERN_INFO
> "timestamp counter I/O clock running at %lu.%02lu"
> @@ -194,12 +146,7 @@ void __init time_init(void)
>
> mn10300_last_tsc = read_timestamp_counter();
>
> -#ifdef CONFIG_GENERIC_CLOCKEVENTS
> init_clockevents();
> -#else
> - reload_jiffies_counter(MN10300_JC_PER_HZ - 1);
> - setup_jiffies_interrupt(TMJCIRQ, &timer_irq, CONFIG_TIMER_IRQ_LEVEL);
> -#endif
>
> #ifdef CONFIG_MN10300_WD_TIMER
> /* start the watchdog timer */
>
>
^ permalink raw reply
* Re: [patch 2/3] mn10300: Use clocksource_register_hz()
From: john stultz @ 2011-02-01 22:19 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, David Howells, Koichi Yasutake, Mark Salter
In-Reply-To: <20110131131808.916682507@linutronix.de>
On Mon, 2011-01-31 at 13:19 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (mn10300-use-clocksource-register-hz.patch)
> clocksource_register_hz() calculates the shift/mult pair for the
> clocksource. Remove the mn10300 duplicate implementation.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
> Cc: Mark Salter <msalter@redhat.com>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* Re: need help with bouncing emails ...
From: Richard Purdie @ 2011-02-01 22:19 UTC (permalink / raw)
To: Gary Thomas; +Cc: poky@yoctoproject.org
In-Reply-To: <4D48546B.4000503@mlbassoc.com>
On Tue, 2011-02-01 at 11:43 -0700, Gary Thomas wrote:
> On 02/01/2011 11:21 AM, Kamble, Nitin A wrote:
> > _poky@yoctolinux.org_ <mailto:poky@yoctolinux.org>
> Is poky@yoctolinux.org equivalent to poky@yoctoproject.org?
Its not. I think Nitin has resolved this now, thanks!
Richard
^ permalink raw reply
* Re: [patch 3/3] mn10300: Use clockevents_calc_mult_shift()
From: john stultz @ 2011-02-01 22:20 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, David Howells, Koichi Yasutake, Mark Salter
In-Reply-To: <20110131131809.017899070@linutronix.de>
On Mon, 2011-01-31 at 13:19 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (mn10300-use-clockevents_calc_mult_shift.patch)
> Use clockevents_calc_mult_shift() instead of the homebrewn function in
> mn10300/kernel/time.c.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
> Cc: Mark Salter <msalter@redhat.com>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* struct ipt_entry how to
From: Volkan YAZICI @ 2011-02-01 22:23 UTC (permalink / raw)
To: netfilter-devel
Hi,
I know that libiptc is not encouraged[1] for public use, but I'm trying
to figure out how rapidly I can interrupt the traffic on an interface
(if possible) with microsecond granularity; hence I want to issue direct
iptc_insert_entry() and iptc_delete_entry() calls without any strings
attached, e.g., start-up time, parsing, information gathering, table
initialization, etc. I'm reading the iptables sources and lost in the
mazes of generate_entry() stuff for creating a proper ipt_entry struct.
Does anybody have a sample code for that? Or can you point me to some
other relevant resource? Or, the worst, am I on my own on this matter?
Regards.
[1] http://lists.netfilter.org/pipermail/netfilter-devel/2004-June/015844.html
^ permalink raw reply
* RE: XCP PV driver
From: James Harper @ 2011-02-01 22:21 UTC (permalink / raw)
To: Soubir Acharya; +Cc: Paul Durrant, xen-devel
In-Reply-To: <4D484A11.3000909@kubisys.com>
>
> Is the latest GP PV driver, signed and will it install on 2008 without
> requiring "bcdedit driver signing off"?
>
It's test signed. You have to turn testsigning on for 64 bit windows.
James
^ 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.