From: Sam Ravnborg [EMAIL PROTECTED]
Date: Fri, 22 Feb 2008 21:32:29 +0100
[SPARC64] fix section mismatchs from dr_cpu_data
Fix following warnings:
WARNING: vmlinux.o(.text+0x4b258): Section mismatch in reference from the
function dr_cpu_data() to the function
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Fri, 22 Feb 2008 21:33:31 +0100
Fix following warnings:
WARNING: vmlinux.o(.text+0x4f980): Section mismatch in reference from the
function kernel_map_range() to the function .init.text:__alloc_bootmem()
WARNING: vmlinux.o(.text+0x4f9cc): Section
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Fri, 22 Feb 2008 21:39:10 +0100
After applying the patches I just sent to you
and a third for hpt366 (sent to Bart) my sparc64
build is section mismatch clean.
Great.
I have not tried different configs neither
allyesconfig etc.
We can get to that
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Wed, 20 Feb 2008 22:50:20 +0100
Full diff of the included changes below.
If you can use this in part or in toal they have my:
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
Looks good, applied. Yes, this stuff is all only user past
__init time if
From: BERTRAND_Joël [EMAIL PROTECTED]
Date: Tue, 19 Feb 2008 10:20:10 +0100
Only one question. For you, where can I find this bug ? In
arch/sparc, in shared code or in ESP driver itself ?
I have to be terse and frank with you, I do not have the
time necessary to sit down and teach
From: Kumar Gala [EMAIL PROTECTED]
Date: Tue, 19 Feb 2008 22:27:48 -0600 (CST)
We introduced a bug in fixing lmb_add_region to handle an initial
region being non-zero. Before that fix it was impossible to insert
a region at the head of the list since the first region always started
at zero.
From: Kumar Gala [EMAIL PROTECTED]
Date: Tue, 19 Feb 2008 23:16:18 -0600
The for loop above the code I added will move all the existing slots
up one. Its just the tail cleanup we are missing.
Aha, I see how this works now, thanks!
I'll add this to my LMB tree.
-
To unsubscribe from this
From: BERTRAND_Joël [EMAIL PROTECTED]
Date: Mon, 18 Feb 2008 22:34:25 +0100
I think I have found a bug in esp_scsi.c. Without this patch, my
SS20/SMP was not able to rebuild its internal raid1 volume due to esp0
DMA errors. With the following patch, same workstation is building a
From: Becky Bruce [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 14:58:22 -0600
Thanks for picking up the patches from Kumar and myself and fitting
them into your series - this is much appreciated. FYI, I applied the
entire patch series to my local tree and test-booted both mpc8641 and
From: Josh Boyer [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 15:24:48 -0600
I plan on actually testing this on Ebony, Walnut, and Bamboo either
later tonight or tomorrow. I don't expect many issues.
Dave, those above boards would cover the build of PowerPC 4xx CPU cores.
Ok.
-
To unsubscribe
As I mentioned to a few ppc folks at LCA08 I plan to use
the LMB code from powerpc as a basis for NUMA support on
sparc64.
There are two changes.
1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
interface bits in include/linux/lmb.h, put arch-specific
bits in asm/lmb.h and add
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Wed, 13 Feb 2008 09:57:35 +0100
Review had been easier if the patch was inlined.
Sorry :)
Can we plase have this changed to use:
config SPARC64
+ select HAVE_LMB
And then in lib/Kconfig have
+config HAVE_LMB
+ bool
So we avoid
From: Kumar Gala [EMAIL PROTECTED]
Date: Wed, 13 Feb 2008 07:12:26 -0600
Does sparc have the concept of a phys_addr_t? We are in the process
of expanding the lmb support to deal with 36-bit physical addresses on
32-bit machines.
On sparc64, where I intend to use this, unsigned long's are
From: Kumar Gala [EMAIL PROTECTED]
Date: Wed, 13 Feb 2008 07:37:27 -0600 (CST)
If we add to an empty lmb region with a non-zero base we will not coalesce
the number of regions done to one. This causes problems on ppc32 for the
memory region as its assumed to only have one region.
We can
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 09:50:42 +1100
On Wed, 2008-02-13 at 16:43 -0600, Becky Bruce wrote:
Convert the lmb code to use phys_addr_t instead of unsigned long for
physical addresses and sizes. This is needed to support large amounts
of RAM on
[LMB]: Make lmb support large physical addressing
Convert the lmb code to use u64 instead of unsigned long for physical
addresses and sizes. This is needed to support large amounts of RAM
on 32-bit systems that support 36-bit physical addressing.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
arch/powerpc/Kconfig|1 +
arch/powerpc/kernel/btext.c |3 +-
arch/powerpc/kernel/crash.c |3 +-
From: Robert P. J. Day [EMAIL PROTECTED]
Date: Sun, 10 Feb 2008 15:05:34 -0500 (EST)
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Robert P. J. Day [EMAIL PROTECTED]
Date: Sun, 10 Feb 2008 15:16:57 -0500 (EST)
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: John Cater [EMAIL PROTECTED]
Date: Thu, 7 Feb 2008 22:10:48 -0500
[15473.014047] sunvdc.c:v1.0 (June 25, 2007)
[15473.031275] sunvdc: VD_OP_GET_VTOC returns error -48
[15473.031319] vdc_port: probe of vdc-port-0-0 failed with error -48
We only support file and full device exports that
From: BERTRAND_Joël [EMAIL PROTECTED]
Date: Fri, 08 Feb 2008 11:53:42 +0100
swapper: page allocation failure. order:1, mode:0x4020
This is harmless and will happen from time to time
under certain kinds of loads.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body
From: BERTRAND_Joël [EMAIL PROTECTED]
Date: Fri, 08 Feb 2008 12:05:43 +0100
Same constatation on U2/SMP. On a 32-threads T1000, I obtain :
BUG: soft lockup - CPU#1 stuck for 11s! [md2_raid1:2736]
Unlike the other message, this might be a real problem.
I'm not sure that both
From: Daniel Smolik [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 21:03:03 +0100
Hi,
I today start compile 2.6.24 and get this warnning:
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x3ffac): Section mismatch: reference to
.init.text:sun4v_ktsb_register (between 'smp_callin' and
From: Daniel Smolik [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 21:24:06 +0100
Hi,
I today work on my E450 and get this :-(. I run vanilla 2.6.20.
There were several TCP bugs fixes in 2.6.20.1 and later,
any one of which could have caused your OOPS.
-
To unsubscribe from this list: send the line
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Sun, 27 Jan 2008 13:56:23 +0100
A few places missed the a specifier for
the __ex_table section. Add these
so we avoid generation an additional
section at link time.
Latest modpost would otherwise complain
like this:
WARNING: vmlinux.o
From: Meelis Roos [EMAIL PROTECTED]
Date: Thu, 24 Jan 2008 16:26:32 +0200 (EET)
Tried to ompile todays 2.6.24-rc8+git on sparc64 and got this:
CC [M] arch/sparc64/solaris/socksys.o
arch/sparc64/solaris/socksys.c: In function 'init_socksys':
arch/sparc64/solaris/socksys.c:192: error:
From: Grant Grundler [EMAIL PROTECTED]
Date: Tue, 22 Jan 2008 23:19:50 -0700
On Mon, Jan 21, 2008 at 11:27:56PM -0800, David Miller wrote:
BTW, I noticed this while reading the DMFE code:
db-buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC *
TX_DESC_CNT + 4
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Mon, 21 Jan 2008 22:50:36 +0100
With a sparc64 defconfig modified to set CONFIG_HOTPLUG=n
the following error happened during link of vmlinux:
local symbol 0: discarded in section `.devexit.text' from drivers/built-in.o
local symbol 1: discarded in
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Wed, 16 Jan 2008 16:54:19 +1100
There are no callers of this on the Sparc platforms.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
Thanks Stephen, I'll apply this.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the
From: Martin Habets [EMAIL PROTECTED]
Date: Sun, 13 Jan 2008 14:51:20 +
It almost works. Reaching the l10 limit does not indicate a
second overflow, but rather 10 milliseconds.
I actually checked in a fixed version which properly
divided by HZ. Thanks.
I can still make it fail on SMP,
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 14 Jan 2008 07:09:22 +0100
But I agree to your suggestion, that will allow us to properly
handle packets with IP options. I'll take care of this.
Thanks a lot Patrick.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
From: David Martin [EMAIL PROTECTED]
Date: Wed, 9 Jan 2008 10:31:45 +0100
Please report sparc problems to the Sparc mailing list,
sparclinux@vger.kernel.org, thanks.
I get the following error compiling latest kernel from git on sparc64
using gcc-4.3:
CC arch/sparc64/kernel/signal.o
From: Martin Habets [EMAIL PROTECTED]
Date: Sun, 6 Jan 2008 22:40:13 +
The microseconds are determined by:
(xtime.tv_nsec / 1000) + (l10_counter 10)
I dumped both variables with a simple kernel module (first 2 attachments),
which shows that xtime is monotonous, but l10_counter looks
From: Mariusz Kozlowski [EMAIL PROTECTED]
Date: Wed, 9 Jan 2008 20:14:16 +0100
So ... am I doing something wrong here or something is broken?
I know that non-8K page sizes are broken but haven't had time
to go fix it, sorry.
-
To unsubscribe from this list: send the line unsubscribe sparclinux
From: Mariusz Kozlowski [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 19:42:16 +0100
Hello,
Got this when doing usual looping over /proc entries on fresh test
kernel:
WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
Call Trace:
[00492704]
From: Ingo Molnar [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 23:56:31 +0100
is this anything the core lockdep code could help improve? Let us know
if any aspect is hindering you.
No, it's a sparc64 issue.
Another problem I ran into are the huge static table sizes
lockdep uses. They really need
From: Andrew Morton [EMAIL PROTECTED]
Date: Sun, 6 Jan 2008 02:15:54 -0800
On Sun, 6 Jan 2008 11:03:02 +0100 Mariusz Kozlowski [EMAIL PROTECTED] wrote:
This is from allnoconfig on sparc64:
LD .tmp_vmlinux1
arch/sparc64/kernel/head.o: In function `kvmap_vmemmap':
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sat, 29 Dec 2007 01:22:56 +0200
At least the sunserial_console_match() one is an obvious Oops
(EXPORT_SYMBOL of an __init function).
The comment in the description of
commit 58d784a5c754cd66ecd4791222162504d3c16c74 the warning was bogus
is
From: David Miller [EMAIL PROTECTED]
Date: Sat, 29 Dec 2007 00:14:11 -0800 (PST)
You can't do that, the FOO_CONSOLE config options depend upon
FOO=y.
That's why I'm not worried about this issue and it's not critical at
all.
Adrian, if you're interested in tackling this fun problem,
have
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sat, 29 Dec 2007 10:48:46 +0200
On Sat, Dec 29, 2007 at 12:14:11AM -0800, David Miller wrote:
That's why I'm not worried about this issue and it's not critical at
all.
If a module calls sunserial_console_match() that's an Oops.
That's true.
I'm
From: Mariusz Kozlowski [EMAIL PROTECTED]
Date: Wed, 26 Dec 2007 13:29:07 +0100
WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to
.init.text:sun4v_ktsb_register (between 'smp_callin' and
'smp_fill_in_sib_core_maps')
Well known and I see them every build and so does everyone
From: Stefan Richter [EMAIL PROTECTED]
Date: Wed, 19 Dec 2007 17:33:05 +0100
Does arch/sparc64/kernel/pci.c fill them in incorrectly or too late?
The problem is that I created indirection that was totally unused, the
operation vectors members for these cases thus didn't get filled in,
and we
From: Joe Perches [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 11:30:22 -0800
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Joe Perches [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 11:30:21 -0800
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Mariusz Kozlowski [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 20:47:55 +0100
[ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
005119b0 Y: Not tainted
[ 145.128940] TPC: kpagecount_read+0x94/0xe0
My suspicion at this point is that with certain RAM
From: Matt Mackall [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 19:06:55 -0600
@@ -707,7 +707,10 @@ static ssize_t kpagecount_read(struct fi
return -EIO;
while (count 0) {
- ppage = pfn_to_page(pfn++);
+ ppage = 0;
+ if
From: Stefan Richter [EMAIL PROTECTED]
Date: Wed, 19 Dec 2007 17:33:05 +0100
drivers/firewire/fw_ohci.c needs them for dma_map_single() +
dma_sync_single_for_device() in the pci_driver.probe(), sometime after
it called pci_enable_device(), before finishing the probe.
I'll take a look at this
From: BERTRAND_Joël [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 09:33:46 +0100
If I restart udev, it is restarted without any timeout. I don't
understand where is the mistake (PCI support ?). It seems to be a bad
interaction between udev and kernel but I don't know the last
configuration
From: Stefan Richter [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 11:38:27 +0100
Also note:
- The very same code did not oops at this point in 2.6.22. It only
started doing so in 2.6.23.
2.6.23 is when the sparc64 IOMMU code started relying upon
the dev_archdata bits being correct.
-
To
From: Stefan Richter [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 11:38:27 +0100
- There has been no other report of this kind for any other
architecture yet. I would expect e.g. the PPC64 folks to report
bugs in our dma mappings eventually.
Irrelevant fact, powerpc handles it's
From: Mikael Pettersson [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 13:06:55 +0100
My main question is: what does the kernel do to the
high 32 bits of the 64-bit integer registers during
context switches?
Only %oX and %gX registers have the full 64-bit preserved across
context switches for
From: Mikael Pettersson [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 13:06:55 +0100
Also, does anyone know what Solaris does to the
high 32 bits during context switches?
Solaris handles things identically to Linux.
These rules are even encoded into places like the
GCC backend for sparc, when
From: Chris Newport [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 02:58:29 + (GMT)
On Tue, 18 Dec 2007, Stefan Richter wrote:
It's a 100% reproducible oops on Sparc (with FireWire controller) for
2.6.23 and 2.6.24 kernels, but not 2.6.22. The reporter confirmed that
the bug also happens
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 17:05:55 +0100
Tested - the patch seems to fix the problem as the machine is still
alive and working well after several hours of running the buggy aptitude
-u in a loop.
I'll leave the kernel running and make sure the machine gets
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 22:17:07 +0100
the v880 (4x US III) here was hit by a stuck process again, after
running fine for some time now. But the machine didn't freeze, one CPU
was running at 100%, but otherwise the machine was responsible.
In your dump all
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sat, 08 Dec 2007 01:14:46 +0100
works well, thanks for fixing!
Thanks a lot for testing.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Andrew Morton [EMAIL PROTECTED]
Date: Sat, 8 Dec 2007 10:22:39 -0800
That's
J_ASSERT_BH(bh, !buffer_jbddirty(bh));
at the end of journal_unmap_buffer().
I don't recall seeing that before and I can't think of anything we've
done recently which could cause it, sorry.
If
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Thu, 06 Dec 2007 13:09:18 +0100
ERROR(0): Cheetah error trap taken afsr[1000]
afar[040001c0] TL1(0)
ERROR(0): TPC[4351dc] TNPC[4351e0] O7[4353b4] TSTATE[80001606]
ERROR(0): TPCinterpret_one_decode_reg+0x0/0xfc
ERROR(0):
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 22:17:07 +0100
The sysrq-g output is attached, I hope you can make sense out of it.
We'll also add some extra workload to the other machines here to try to
trigger the bug on other CPUs, too.
I just got back from my vacation and
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Thu, 06 Dec 2007 11:43:45 +0100
David Miller wrote:
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 22:17:07 +0100
The sysrq-g output is attached, I hope you can make sense out of it.
We'll also add some extra workload
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sat, 01 Dec 2007 13:43:30 +0100
- Systems that boot off qlogic attached disks are not supported, because
there is no working firmware loader in anaconda, and the qlogic driver
needs firmware.
That's very unfortunate, how are qlogic device
From: Joe Perches [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 23:48:36 -0800
On Mon, 2007-11-19 at 23:45 -0800, David Miller wrote:
From: Joe Perches [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:47:58 -0800
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Please check your patches, for trailing
From: Cyrill Gorcunov [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 20:28:33 +0300
From: Cyrill Gorcunov [EMAIL PROTECTED]
This patch adds checking for possible NULL pointer dereference
if of_find_property() failed.
Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
Applied, thanks.
-
To
From: Martin Habets [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 02:10:15 +
This patch against 2.6.23 sparc-2.6.git contains a number of minor cleanups
of the sparc serial drivers.
Initially I fixed this build warning:
WARNING: vmlinux.o(.text+0x107a2c): Section mismatch: reference to
From: Tom \spot\ Callaway [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 13:46:22 -0500
On Tue, 2007-11-06 at 10:12 -0500, Scot P. Floess wrote:
Not sure as icedtea took care of whatever downloads it required...
The only requirement I saw was the latest RH gcj with generics
extension... When
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 22:17:07 +0100
first the good news:
The U60 here still building and working fine, also I didn't hear any bad
news from lebrun.d.o.
the not so good news:
the v880 (4x US III) here was hit by a stuck process again, after
running
From: Joe Perches [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:47:58 -0800
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Please check your patches, for trailing white space.
Adds trailing whitespace.
diff:10:prom_printf(PCIC: Error, cannot map
Adds trailing whitespace.
diff:19:
From: Joe Perches [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:47:59 -0800
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 03:37:55 -0800
: undefined reference to `__xchg_called_with_bad_pointer'
This is sparc64's way of telling you that you can'd do xchg on an s8.
Dave, is that fixable?
I assume not, in which case we either go for some open-coded
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Wed, 07 Nov 2007 15:35:42 +0100
But I did the artificial tests, like running dpkg-query --search libc.so.6
in loops, and this seems to work well. Thanks a lot!
I was running aptitude -u in a loop for half an hour now, and it didn't
crash,
From: Andrew Morton [EMAIL PROTECTED]
Date: Fri, 9 Nov 2007 12:22:08 -0800
I tagged this as needed-in-2.6.23.x. Please let me know if that is not
appropriate.
It is. I have it queued up for -stable already.
I'm just waiting for it Linus to get back from wherever he has been
the past few
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Wed, 07 Nov 2007 15:35:42 +0100
But I did the artificial tests, like running dpkg-query --search libc.so.6
in loops, and this seems to work well. Thanks a lot!
I was running aptitude -u in a loop for half an hour now, and it didn't
crash,
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Tue, 06 Nov 2007 04:51:07 +0100
Here's also some output from apt-get which got stuck in my unstable
chroot while I wanted to retrieve the klibc source to try to debug it...
So the good news is that I started getting the hang seen
on the Debain buildd
[ Bernd, Josip, and Fabio, I think I finally nailed this
cpu hang bug we were all seeing on sparc64. ]
[FUTEX]: Fix address computation in compat code.
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:
(void __user *)entry + futex_offset
From: David Miller [EMAIL PROTECTED]
Date: Tue, 06 Nov 2007 20:34:33 -0800 (PST)
[FUTEX]: Fix address computation in compat code.
Sorry, I just noticed there is a second handle_futex_death()
call in compat_exit_robust_list() which has the same
address computation bug.
Here is an updated patch
From: Lucas Woods [EMAIL PROTECTED]
Date: Tue, 06 Nov 2007 07:15:22 +1100
Signed-off-by: Lucas Woods [EMAIL PROTECTED]
Applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Josip Rodin [EMAIL PROTECTED]
Date: Fri, 2 Nov 2007 17:21:06 +0100
Great. Here you go, three of them, while the load was 3 and this process was
stuck:
buildd 10813 100 0.8 987368 17504 ?RN 14:44 155:49 dpkg-query
--search libpthread.so.0 libdl.so.2 libstdc++.so.6
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sun, 04 Nov 2007 20:55:20 +0100
So I'm not sure if the result is really useful for you - if not just let
me know. I've attached the last ~10-20 sysrq-g outputs - as it was
running in a loop I have a ton of them. In case you're wondering: http
is
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 02 Nov 2007 16:37:25 +0100
I've sent g several times to sysrq, output is attached.
According to top the two hanging aptitude processes were running on CPU
1 + 3.
3204 root 20 0 19552 5088 4072 R 100 0.1 6:54.49 1 aptitude
3203
From: David Miller [EMAIL PROTECTED]
Date: Thu, 01 Nov 2007 15:01:13 -0700 (PDT)
I'm working on a kernel patch for 2.6.23 that will allow you to get
some useful debugging information in situations like this.
I'll try to get you that patch by the end of tonight.
As promised, here is the patch
From: Josip Rodin [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 00:37:13 +0100
I'd try doing a debootstrap of lenny (that's Debian testing),
and then inside it, run one or more of those 'dpkg-query -S libc.so.6'.
Thanks for the info.
While waiting for you to reply I created a lenny buildd
build
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 01:50:30 +0100
What we're missing here is a probably important piece:
If dpkg-query is running during a build, it is running in a fakeroot
environment. I've straced that, see the attachment.
What I find in the strace are at
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 01:47:33 +0100
mount -t devpts none /dev/pts
mount --bind /dev /thechroot/dev
is what I use here, running udev in a chroot is no fun.
Ok.
I'm almost done with a howto which is cutpaste for 95% to debootstrap
and boot a
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 02:54:14 +0100
Ok. Do you have a .deb with a kernel for me? If not - would you like to
have any specific options enabled - I have to build one then.
I usually just cp arch/sparc64/defconfig ./.config in a fresh
vanilla kernel tree
From: Matthias Dellweg [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 18:47:56 +0200
while reviewing the tcp_md5-related code further i came across with another
two of these casts which you probably have missed. I don't actually think
that they impose a problem by now, but as you said we should
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 02:18:30 +0100
But if this bug isn't fixed chances are good that the next Debian
release won't support Sparc at all.
Please don't use pseudo-threats like this, it only deters me even more
from working on this bug.
This explains why
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 03:06:13 +0100
David Miller wrote:
Josip stated explicitly that he has a SunFire280R, which disagrees
with what you're saying here.
Sorry, I mixed something up here. I was somehow sure that they were
using a v440
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sun, 28 Oct 2007 04:03:44 +0100
I think things got worse with 2.6.24...
The machine shoots itself now, I guess by running cron jobs or so.
[29074.766486] TSTATE: 11009600 TPC: 0042f984 TNPC:
0042f928 Y:
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Sat, 27 Oct 2007 20:09:47 +0200
titan:~# [ 2427.313946] BUG: soft lockup - CPU#3 stuck for 11s!
[aptitude:13375]
[ 2427.389128] TSTATE: 11009602 TPC: 0042f93c TNPC:
0042f7d0 Y: Not tainted
[ 2427.506821] TPC:
From: Roel Kluin [EMAIL PROTECTED]
Date: Sat, 27 Oct 2007 17:25:51 +0200
I already posted something on lkml, but it wasn't picked up
in arch/sparc64/kernel/time.c, line 1073 it reads:
if (!mregs !dregs !bregs)
shouldn this be
if (!mregs !dregs !bregs)
Yep,
From: Bernd Zeimetz [EMAIL PROTECTED]
Date: Fri, 26 Oct 2007 14:30:21 +0200
at least it runs with 100% CPU, attaching strace to the pid doesn't give
any results
strace-ing the whole process doesn't result in more useful output, but
the hanging processes were killable when they were
Josip, give this debugging patch a try. It is against 2.6.23.1
but it should apply to most recent kernels.
It should give you debugging messages in the kernel log that
start with FUTEX_BUG if the debugging code triggers.
Please post just a few samples of whatever it spits out.
Thanks!
diff
From: Josip Rodin [EMAIL PROTECTED]
Date: Wed, 24 Oct 2007 23:11:02 +0200
Hi,
Just tried 2.6.24-rc1... but:
arch/sparc64/kernel/iommu_common.c: In function 'prepare_sg':
arch/sparc64/kernel/iommu_common.c:237: error: implicit declaration of
function 'next_sg'
cc1: warnings being
From: Josip Rodin [EMAIL PROTECTED]
Date: Thu, 25 Oct 2007 00:33:32 +0200
We've been having grave issues with a few of our sparc build daemon machines
in Debian. Something causes dpkg-query(8) processes, otherwise harmless, to
run amok and allocate too much memory, but keep running and become
From: Dan Williams [EMAIL PROTECTED]
Date: Wed, 24 Oct 2007 16:49:28 -0700
Hopefully it is as painless to run on sparc as it is on IA:
opcontrol --start --vmlinux=/path/to/vmlinux
wait
opcontrol --stop
opreport --image-path=/lib/modules/`uname -r` -l
It is painless, I use it all the time.
From: Chris Wright [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 15:50:38 -0700
Looks like the MAP_FIXED case is using the wrong address hint. I'd expect
the comment don't mess with it means pass the request straight on through,
not change the address requested to -ENOMEM.
Signed-off-by:
From: David Miller [EMAIL PROTECTED]
Date: Wed, 17 Oct 2007 04:22:29 -0700 (PDT)
From: Michael Ellerman [EMAIL PROTECTED]
Date: Wed, 17 Oct 2007 17:12:27 +1000 (EST)
Use of_get_pci_dev_node() in axon_msi.c. Switch to including linux/of.h
so we get the prototype.
Signed-off
Better late than never...
Ok, I think I nailed this, the simplest test case is:
register unsigned long regval asm(g5);
extern void cond_resched(void);
unsigned int var;
void *expression(unsigned long regval)
{
void *ret;
__asm__( : =r (ret) : 0 (var));
return ret + regval;
}
void
From: BERTRAND_Joël [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 15:29:27 +0200
lot of messages like :
Kernel unaligned access at TPC[1016b334]
set_offset_and_length+0xdc/0x1a0 [iscsi_trgt]
The iSCSI code makes unaligned accesses for the data types
being dereferenced, and needs to be fixed.
I
From: BERTRAND_Joël [EMAIL PROTECTED]
Date: Fri, 12 Oct 2007 09:04:16 +0200
Writing inode tables: Kernel unaligned access at TPC[56004c]
xor_niagara_4+0x5c/0x128
sun4v_data_access_exception: ADDR[0053d354] CTX[]
TYPE[000a], going.
Please try this patch:
diff --git
1 - 100 of 363 matches
Mail list logo
