dann frazier | 8 Feb 15:33
Gravatar

decommissioning parisc-linux.org

As Paul noted[1], parisc-linux.org was running a vulnerable
apache which got the attention of HP's security audit team. I've been
doing most of the maintenance of the OS on this machine for a while,
but that has just meant apt-get upgrading when cron-apt told me to for
a few years. Turns out apache-ssl was obsolete (an etch version!), so
no amount of upgrading was going to fix that.

At this point I've removed apache-ssl. I tried installing apache2 to
see if any web pages would magically work - it didn't, so right now
the website is 404 farm :( I didn't spend much time trying to handle
that since.....

parisc-linux.org is running the last stable release of Debian that
supported hppa ('lenny'), and its life is now expired. As such, I
think we really need to migrate the site to another maintained
distribution and/or architecture. I'm willing to help migrate services
for the next month or so - let's just say 2012.03.14 for a good round
(heh) date - after which I plan to halt this system and let HP know
the hardware can be put to other uses. From what I can tell, we
originally installed this system almost exactly 9 years ago - ah,
rememember its predecessor dsl2? Good times. Anyway -

*************************************************************************
*** If you need any data off this machine, now's the time to grab it! ***
*************************************************************************

If you'd like to take over longterm hosting the website/domain, please
get in touch with taggart or I. If you'd like to continue using the
machine and/or HP's network to do the hosting, I can probably find a
contact for you there - though I wouldn't bet on it.
(Continue reading)

Paul Bame | 4 Feb 17:52
Gravatar

parisc-linux.org issue


Hey I just got notified that parisc-linux.org has a vulnerable apache
server.  I did an apt-get upgrade but it didn't upgrade the server,
and the vulnerability was fixed in lenny's apache2 but not apache "1".

So one question is whether (and who) to move that server to apache2.

A bigger question is what to do since lenny is at end of life.

And who's watching this machine?

	-p
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Picon
Favicon
Gravatar

Microsoft Forefront Server Security forwarded attachment


The body from the message "[Patch] parisc: include <linux/prefetch.h> in
drivers/parisc/iommu-helpers.h", originally sent to you by linux-kernel-owner <at> vger.kernel.org
(linux-kernel-owner <at> vger.kernel.org), has been forwarded to you from the Microsoft Forefront Server
Security Quarantine area.
This message body may have been re-scanned by Microsoft Forefront Server Security and handled according
to the appropriate scan job's settings.

<<Body of Message>>
Attachment (Body of Message): application/octet-stream, 1029 bytes
Cong Wang | 3 Feb 08:34
Picon

[Patch] parisc: include <linux/prefetch.h> in drivers/parisc/iommu-helpers.h

drivers/parisc/iommu-helpers.h:62: error: implicit declaration of function 'prefetchw'
make[3]: *** [drivers/parisc/sba_iommu.o] Error 1

drivers/parisc/iommu-helpers.h needs to #include <linux/prefetch.h>
where prefetchw is declared.

Cc: Kyle McMartin <kyle <at> mcmartin.ca>
Cc: Helge Deller <deller <at> gmx.de>
Cc: "James E.J. Bottomley" <jejb <at> parisc-linux.org>
Signed-off-by: WANG Cong <xiyou.wangcong <at> gmail.com>

---
diff --git a/drivers/parisc/iommu-helpers.h b/drivers/parisc/iommu-helpers.h
index a9c46cc..460aed9 100644
--- a/drivers/parisc/iommu-helpers.h
+++ b/drivers/parisc/iommu-helpers.h
@@ -1,3 +1,5 @@
+#include <linux/prefetch.h>
+
 /**
  * iommu_fill_pdir - Insert coalesced scatter/gather chunks into the I/O Pdir.
  * @ioc: The I/O Controller.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thibaut VARENE | 30 Jan 02:06

Re: Happy New Year PARISC (take 2)

Reposting as vger is anal about mail format...

On Sun, Jan 29, 2012 at 10:45 PM, John David Anglin
<dave.anglin <at> bell.net> wrote:
>
> I believe both versions fix the minifail bug and some thread related bugs
> seen in the perl, python and git testsuites.  However, there are still more
> thread related bugs to fix.
>
> The minifail bug is fixed by the TLB purge added to ptep_set_wrprotect,
> and flushing the `from' page in copy_user_page (kmap version).  The
> tmpalias version doesn't need this flush, but the `to' page needs to be
> flushed.  So, both versions have about the same flush requirements.
>
> This version fixes the math emulation bug that I reported, but I have
> another one that I haven't tracked down.

That's awesome news!

If you want write access to the wiki to update e.g. this page
http://wiki.parisc-linux.org/TestCases I'd be more than happy to add
your account to the ACL.

> It would be great if someone else could test the change on something other
> than a rp3440.  The cache issues are very subtle.  If the results are positive,
> I will break up the patch and formally submit it.

Well I have an a500-5x (PA8600) that's doing nothing, but I really
don't have time to do any kind of testing now or in the near future.
I'd be happy to provide access to the hardware tho.
(Continue reading)

James Bottomley | 28 Jan 20:56

Hang deconfiguring network interface (in shutdown) on 3.3-rc1

It looks like it might be a tg3 or RCU issue.  When I shut down my
parisc SMP 4 way system, I get an immediate hang here

Deconfiguring network interfaces...Internet Systems Consortium DHCP
Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:30:6e:4b:15:59
Sending on   LPF/eth0/00:30:6e:4b:15:59
Sending on   Socket/fallback
DHCPRELEASE on eth0 to 153.66.140.171 port 67

Followed some seconds later by

[ 5714.268000] INFO: rcu_sched detected stall on CPU 3 (t=15000 jiffies)
[ 5714.268000] Backtrace:
[ 5714.268000]  [<000000004011fdd4>] show_stack+0x14/0x20
[ 5714.268000]  [<000000004011fdf8>] dump_stack+0x18/0x28
[ 5714.268000]  [<00000000401c1fec>] __rcu_pending+0xcc/0x5c8
[ 5714.276000]  [<00000000401c2d60>] rcu_check_callbacks+0x80/0xf8
[ 5714.276000] INFO: rcu_sched detected stalls on CPUs/tasks: { 3}
(detected by 2, t=15002 jiffies)
[ 5714.276000] Backtrace:
[ 5714.276000]  [<000000004011fdd4>] show_stack+0x14/0x20
[ 5714.276000]  [<000000004011fdf8>] dump_stack+0x18/0x28
[ 5714.276000]  [<00000000401c2484>] __rcu_pending+0x564/0x5c8
[ 5714.276000]  [<00000000401c2d60>] rcu_check_callbacks+0x80/0xf8
[ 5714.276000]  [<0000000040155dc8>] update_process_times+0x68/0xd8
(Continue reading)

Bjorn Helgaas | 28 Jan 16:30
Picon
Favicon

c3700 boot failure (protection ID trap)

I'm trying to test some PCI changes on a c3700, but recent kernels
don't seem to work at all.  74ea15d909b311 (current upstream) and v3.2
both fail as shown below.  I'm using c3000_defconfig (attached for
74ea15d909b311).  Should I expect this to work?

v3.0 gets farther, but then gets into a loop of
__find_get_block_slow() messages like this:

        ...
        md: autorun ...
        md: ... autorun DONE.
        __find_get_block_slow() failed. block=0, b_blocknr=1
        b_state=0x00000020, b_size=4096
        device blocksize: 4096
        __find_get_block_slow() failed. block=0, b_blocknr=1
        ...

Linux version 3.3.0-rc1+ (helgaas <at> c3700) (gcc version 4.3.2 (Debian 4.3.2-1.1)
 ) #20 Fri Jan 27 19:52:08 MST 2012
unwind_init: start = 0x1054f000, end = 0x105882c0, entries = 14636
WARNING: Out of order unwind entry! 10550250 and 10550260
WARNING: Out of order unwind entry! 10550260 and 10550270
WARNING: Out of order unwind entry! 10550c40 and 10550c50
WARNING: Out of order unwind entry! 10550c50 and 10550c60
WARNING: Out of order unwind entry! 10550c60 and 10550c70
WARNING: Out of order unwind entry! 10550c70 and 10550c80
WARNING: Out of order unwind entry! 10550c90 and 10550ca0
WARNING: Out of order unwind entry! 10550ca0 and 10550cb0
WARNING: Out of order unwind entry! 10550cb0 and 10550cc0
WARNING: Out of order unwind entry! 10550cc0 and 10550cd0
(Continue reading)

Masanari Iida | 22 Jan 13:05
Picon
Gravatar

[PATCH] [trivial] parisc : Fix typo in eisa_enumerator.c

Correct spelling "confgiuration" to "configuration" in
drivers/parisc/eisa_enumerator.c

Signed-off-by: Masanari Iida <standby24x7 <at> gmail.com>
---
 drivers/parisc/eisa_enumerator.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/parisc/eisa_enumerator.c b/drivers/parisc/eisa_enumerator.c
index caa1531..a656d9e 100644
--- a/drivers/parisc/eisa_enumerator.c
+++ b/drivers/parisc/eisa_enumerator.c
@@ -357,7 +357,7 @@ static int parse_slot_config(int slot,
 		}
 		if (flags & HPEE_FUNCTION_INFO_CFG_FREE_FORM) {
 			/* I have no idea how to handle this */
-			printk("function %d have free-form confgiuration, skipping ",
+			printk("function %d have free-form configuration, skipping ",
 				num_func);
 			pos = p0 + function_len;
 			continue;
--

-- 
1.7.6.5

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

James Bottomley | 17 Jan 22:14
Favicon

Fix compile breakage with kref.h

This set of build failures just started appearing on parisc:

In file included from drivers/input/serio/serio_raw.c:12:
include/linux/kref.h: In function 'kref_get':
include/linux/kref.h:40: error: 'TAINT_WARN' undeclared (first use in this function)
include/linux/kref.h:40: error: (Each undeclared identifier is reported only once
include/linux/kref.h:40: error: for each function it appears in.)
include/linux/kref.h: In function 'kref_sub':
include/linux/kref.h:65: error: 'TAINT_WARN' undeclared (first use in this function)

It happens because TAINT_WARN is defined in kernel.h and this particular
compile doesn't seem to include it (no idea why it's just
manifesting ... probably some #include file untangling exposed it).  Fix
by adding #include <linux/kernel.h> to linux/kref.h

Signed-off-by: James Bottomley <JBottomley <at> Parallels.com>

---

diff --git a/include/linux/kref.h b/include/linux/kref.h
index abc0120..9c07dce 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -17,6 +17,7 @@
 
 #include <linux/bug.h>
 #include <linux/atomic.h>
+#include <linux/kernel.h>
 
 struct kref {
(Continue reading)

Rolf Eike Beer | 17 Jan 11:41
Picon

Boot error using 3.2.1: swapper (pid 1): Illegal instruction (code 8)

Machine is an Apollo 705, previous kernel version was 2.6.28. Any hints 
appreciated. Config attached.

Eike

Linux version 3.2.1 (root <at> apollo) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, 
pie-0.4.5) ) #1 Mon Jan 16 15:48:44 CET 2012
unwind_init: start = 0x1043b000, end = 0x1046b8f0, entries = 12431
FP[0] enabled: Rev 3 Model 0
The 32-bit Kernel has started...
bootconsole [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: Snake.
model 00003020 00000481 00000000 00000000 77aac223 ffffffff 00000004 0000000d 
00000000
vers  00000003
model 9000/705
Total Memory: 64 MB
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: root=/dev/sdb5 console=ttyS0,57600 console=tty0 
palo_kernel=2/vmlinux-3.2.1
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 60612k/65536k available (2558k kernel code, 4924k reserved, 1243k 
data, 236k init)
virtual kernel memory layout:
    vmalloc : 0x00008000 - 0x0f000000   ( 239 MB)
    memory  : 0x10000000 - 0x14000000   (  64 MB)
      .init : 0x104e0000 - 0x1051b000   ( 236 kB)
(Continue reading)


Gmane