headers
Danny ter Haar | 1 Jul 2004 01:01

problems with SATA: 2.6.7 working, -bk12/13/-mm4 not

1U 19" server supermicro with ICH5 & P4.

runs 2.6.7 vanilla without problems.

tried -bk12/-bk13/-mm4 which won't work
Machine is on serial console and captures output looks  like
this:

Using local APIC timer interrupts.                                              
calibrating APIC timer ...                                                      
..... CPU clock speed is 2595.0172 MHz.                                         
..... host bus clock speed is 199.0628 MHz.                                     
checking TSC synchronization across 2 CPUs: passed.                             
Brought up 2 CPUs                                                               
NET: Registered protocol family 16                                              
PCI: PCI BIOS revision 2.10 entry at 0xfb1b0, last bus=2                        
PCI: Using configuration type 1                                                 
mtrr: v2.0 (20020519)                                                           
ACPI: Subsystem revision 20040326                                               
ACPI: Interpreter enabled                                                       
ACPI: Using IOAPIC for interrupt routing                                        
ACPI: PCI Root Bridge [PCI0] (00:00)                                            
PCI: Probing PCI hardware (bus 00)                                              
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2                             
PCI: Transparent bridge - 0000:00:1e.0                                          
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 7 9 10 11 12 14 15)                
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11 12 14 15)                
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15)                
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 *9 10 11 12 14 15)                
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Mackerras | 1 Jul 2004 01:07
Picon
Favicon

Re: [PATCH] PPC64: lockfix for rtas error log

Linas,

> Too many kernel trees.  Someone must have whacked the ameslab tree
> by accident, or on purpose, because they got sick of seeing rtas 
> messages.  I don't find the RTAS messages to be pleasent, but simply
> whacking them is not the right solution.  The following diff is 
> between an older tree and the current tree.  If you could re-add 
> these lines, that would be great.

As far as I can see, the ameslab tree has _never_ contained those
lines.  The last change to chrp_setup.c was on 1 May 2004, and neither
that version nor any of the earlier versions that I looked at have
those lines.  Are you sure you don't have that as a local change in
your copy?  Do a bk sfiles -i and a bk push -n and see if it shows up.

In any case the #ifdef is redundant, because chrp_setup.o is only
linked in if CONFIG_PPC_PSERIES is set.

As for the RTAS messages being printk'd, the only possible
justification would be if there was a userspace tool to analyse them.
I don't know if such a thing exists, and if it does, I certainly don't
have a copy.  Is anyone working on that?

Paul.
Permalink | Reply | 1 comment |
headers
Tobias Diedrich | 1 Jul 2004 01:17
Picon

Re: [PATCH] restore floppy boot image

Joshua wrote:

> +	 * Previous versions copied the param table.
> +	 * We are just going to tweak it. It is in ram anyway

The DPT can be in the BIOS ROM (and probably is in a lot of cases).

--

-- 
Tobias						PGP: http://9ac7e0bc.2ya.com
Any sufficiently advanced bug is indistinguishable from a feature.
  -- Rich Kulawiec
Permalink | Reply | 0 comments |
headers
Paul Mackerras | 1 Jul 2004 01:14
Picon
Favicon

Re: [PATCH] PPC64: (resend) Janitor signature of rtas_call() routine

Linas,

> Well, your patch is not in the ameslab tree :( at least as of friday 
> night.  I'm working off of ameslab, is there a different tree I should
> follow at this time?

We should all be working from the upstream kernel.org tree as much as
possible.  In the past we have used ameslab as a repository for the
ppc64 changes that were ready to go but which hadn't got upstream yet.
Now that our patches are going into the upstream BK repository quickly
and reliably there is much less need for ameslab.

If you have something you're working on that isn't ready to go
upstream just yet, post the patch periodically to linuxppc64-dev
and/or linux-kernel.  If other developers want to try your stuff
before it's quite ready they should be applying your patches to their
local trees.

Paul.
Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Jul 2004 01:17
Picon
Favicon

Re: problems with SATA: 2.6.7 working, -bk12/13/-mm4 not

Danny ter Haar wrote:
> 1U 19" server supermicro with ICH5 & P4.
> 
> runs 2.6.7 vanilla without problems.
> 
> tried -bk12/-bk13/-mm4 which won't work
> Machine is on serial console and captures output looks  like
> this:
> 
> Using local APIC timer interrupts.                                              
> calibrating APIC timer ...                                                      
> ..... CPU clock speed is 2595.0172 MHz.                                         
> ..... host bus clock speed is 199.0628 MHz.                                     
> checking TSC synchronization across 2 CPUs: passed.                             
> Brought up 2 CPUs                                                               
> NET: Registered protocol family 16                                              
> PCI: PCI BIOS revision 2.10 entry at 0xfb1b0, last bus=2                        
> PCI: Using configuration type 1                                                 
> mtrr: v2.0 (20020519)                                                           
> ACPI: Subsystem revision 20040326                                               
> ACPI: Interpreter enabled                                                       
> ACPI: Using IOAPIC for interrupt routing                                        
> ACPI: PCI Root Bridge [PCI0] (00:00)                                            
> PCI: Probing PCI hardware (bus 00)                                              
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2                             
> PCI: Transparent bridge - 0000:00:1e.0                                          
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 7 9 10 11 12 14 15)                
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11 12 14 15)                
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15)                
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 *9 10 11 12 14 15)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jamie Lokier | 1 Jul 2004 01:30

Re: A question about PROT_NONE on ARM and ARM26

Russell King wrote:
> > Here's the potential improvement to current 32-bit ARM.  It's
> > 4 instructions instead of 8 and one less load, in the common case:
> > 
> > __get_user_4:
> > 	cmp	r0, #TASK_SIZE-4
> > 4:	ldrlet	r1, [r0]
> > 	movle	r0, #0
> > 	movle	pc, lr
> > 	bic	r1, sp, #0x1f00
> > 	bic	r1, r1, #0x00ff
> > 	ldr	r1, [r1, #TI_ADDR_LIMIT]
> > 	sub	r1, r1, #4
> > 	cmp	r0, r1
> > 14:	ldrlet	r1, [r0]
> > 	movle	r0, #0
> > 	movle	pc, lr
> > 	b	__get_user_bad
> 
> Ok, this could work, but there's one gotcha - TASK_SIZE-4 doesn't fit
> in an 8-bit rotated constants, so we need 2 extra instructions:
> 
> __get_user_4:
> 	mov	r1, #TASK_SIZE
> 	sub	r1, r1, #4
> 	cmp	r0, r1
> 4:	ldrlet	r1, [r0]
> 	movle	r0, #0
> 	movle	pc, lr
> 	...
(Continue reading)

Permalink | Reply | 10 comments |
headers
Dave Hansen | 1 Jul 2004 01:31
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> Hi,
> 
> this is an updated version of my memory hotremoval patch.
> I'll only include the main patch which contains page remapping code.
> The other two files, which haven't changed much from April, can be
> found at http://people.valinux.co.jp/~iwamoto/mh.html .

I tried your code and it oopsed pretty fast:

NUMA - single node, flat memory mode, but broken in several blocks
Rounding down maxpfn 950265 -> 949248
node 0 start 0
node 1 start 65536
node 2 start 131072
node 3 start 196608
node 4 start 262144
node 5 start 327680
node 6 start 393216
node 7 start 458752
physnode_map 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Warning only 1920MB will be used.
Use a HIGHMEM enabled kernel.
1892MB LOWMEM available.
min_low_pfn = 1080, max_low_pfn = 484352, highstart_pfn = 0
Low memory ends at vaddr f6400000
node 0 will remap to vaddr f6400000 -
High memory starts at vaddr 80000000
found SMP MP-table at 0009e1d0
On node 0 totalpages: 65536
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Molton | 1 Jul 2004 01:48

Re: A question about PROT_NONE on ARM and ARM26

On Thu, 1 Jul 2004 00:30:14 +0100
Jamie Lokier <jamie <at> shareable.org> wrote:

> "ge" is a signed comparison, and unsigned is needed here, unless I
> missed something subtle.  So "bge" and "ldrge" should be "bhi" and "ldrhi".

technically, I think you're right here.

in practise, the arm26 address space is too small (64MB) for this to
ever cause a problem.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
Permalink | Reply | 2 comments |
headers
Dave Hansen | 1 Jul 2004 02:11
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> Due to struct page changes, page->mapping == NULL predicate can no
> longer be used for detecting cancellation of an anonymous page
> remapping operation.  So the PG_again bit is being used again.
> It may be still possible to kill the PG_again bit, but the priority is
> rather low.

But, you reintroduced it everywhere, including file-backed pages, not
just for anonymous pages?  Why was this necessary?

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
Permalink | Reply | 8 comments |
headers
Serge E. Hallyn | 1 Jul 2004 02:14
Favicon

Re: per-process namespace?

> The per-process namespace concept comes in handy here except for the
> static nature of the namespace. In the sense, any changes to the system
> namespace do not reflect in the children namespace.

Static?

It's not static!  It's private, as advertised.

It sounds like you're asking (or your customer is asking) for
copy-on-write namespaces  :)
Permalink | Reply | 1 comment |

Gmane