[parisc-linux] Switch console error.

[parisc-linux] Switch console error.

[Gururaj Ananthateerta]

Built a new kernel and trying to boot with the new one.
the following message appeared .

 ----------error Msg Start------------------
 Branching to kernel entry point 0x00100058.  If this is the last
 message you see, you may need to switch your console.  This is
 a common symptom -- search the FAQ and mailing list at parisc-linux.org


 ---END-------------------------------------------

I guess that I may have ommitted some console drivers during building my
kernel.
Anyine has nay clue about this.

I am using the following machines.
HP-N Class server.
Console is through a lanronix box.
Linux code I am using is linux-latest.tar.gz from ftp.parisc.org

I searched the mailing list, but didn't get anything specific.
Guru

Re: [parisc-linux] Switch console error.

[Matthew Wilcox]

On Tue, Mar 12, 2002 at 11:58:06AM -0800, Gururaj Ananthateerta wrote:
> I guess that I may have ommitted some console drivers during building my
> kernel.
> Anyine has nay clue about this.

I would assume CONFIG_SERIAL_CONSOLE is the option you're missing.
Another option might be CONFIG_SERIAL, but I suspect you turned on
support for your serial ports :-)

> I am using the following machines.
> HP-N Class server.

N class isn't supported.  There are a number of problems which need to
be solved to support N class...

> I searched the mailing list, but didn't get anything specific.

I'm surprised, I thought this was in the FAQ.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Switch console error.

[Gururaj Ananthateerta]

Matthew Wilcox wrote:

> On Tue, Mar 12, 2002 at 11:58:06AM -0800, Gururaj Ananthateerta wrote:
> > I guess that I may have ommitted some console drivers during building my
> > kernel.
> > Anyine has nay clue about this.
>
> I would assume CONFIG_SERIAL_CONSOLE is the option you're missing.
> Another option might be CONFIG_SERIAL, but I suspect you turned on
> support for your serial ports :-)
>

both of them are set to 'y'


>
> > I am using the following machines.
> > HP-N Class server.
>
> N class isn't supported.  There are a number of problems which need to
> be solved to support N class...

Yes I am aware of it.
I am trying to work on some of those problems.


>
> > I searched the mailing list, but didn't get anything specific.
>
> I'm surprised, I thought this was in the FAQ.
>

Yes, this isn't  in the FAQ  yet.


>
> --
> Revolutions do not require corporate support.

Re: [parisc-linux] Switch console error.

[Matthew Wilcox]

On Tue, Mar 12, 2002 at 12:37:24PM -0800, Gururaj Ananthateerta wrote:
> both of them are set to 'y'

OK.  Since this is an N class, the serial ports should be automatically
detected on the Diva card.  Towards the top of arch/parisc/kernel/pdc_cons.c
you'll see:

/* Define EARLY_BOOTUP_DEBUG to debug kernel related boot problems. 
 * On production kernels EARLY_BOOTUP_DEBUG should be undefined. */
#undef EARLY_BOOTUP_DEBUG

Change the #undef to #define and recompile.  Do you see any more output?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Switch console error.

[Gururaj Ananthateerta]

Matthew Wilcox wrote:

> On Tue, Mar 12, 2002 at 12:37:24PM -0800, Gururaj Ananthateerta wrote:
> > both of them are set to 'y'
>
> OK.  Since this is an N class, the serial ports should be automatically
> detected on the Diva card.  Towards the top of arch/parisc/kernel/pdc_cons.c
> you'll see:
>
> /* Define EARLY_BOOTUP_DEBUG to debug kernel related boot problems.
>  * On production kernels EARLY_BOOTUP_DEBUG should be undefined. */
> #undef EARLY_BOOTUP_DEBUG

Apologies folks.
helped a lot. I cud figure out that my kernel was  a32-bit
i got htis hppa-linux-gcc and compiled  a 64-bit kernel.
things are still ugly.

anyone working on supporting N-class.




>
>
> Change the #undef to #define and recompile.  Do you see any more output?
>
> --
> Revolutions do not require corporate support.

Re: [parisc-linux] Switch console error.

[Matt Taggart]

Gururaj Ananthateerta writes...

> Apologies folks.
> helped a lot. I cud figure out that my kernel was  a32-bit
> i got htis hppa-linux-gcc and compiled  a 64-bit kernel.

You need hppa64-linux-gcc to build a 64 bit kernel. You can get compilers 
from the ftp.parisc-linux.org site.

-- 
Matt Taggart        Linux Development Lab
taggart@fc.hp.com   HP Linux Systems Operation

Re: [parisc-linux] Switch console error.

[Gururaj Ananthateerta]

Matt Taggart wrote:

> Gururaj Ananthateerta writes...
>
> > Apologies folks.
> > helped a lot. I cud figure out that my kernel was  a32-bit
> > i got htis hppa-linux-gcc and compiled  a 64-bit kernel.
>
> You need hppa64-linux-gcc to build a 64 bit kernel. You can get compilers
> from the ftp.parisc-linux.org site.

I did that, but the kernel panic during  boot and the following was the
message
on the screen.

--------------------------------Start Msg -------------------------
29. Prelude W+ 540 (0) at 0xfffffffffed65000 [101], versions 0x5d3, 0x0, 0x4

CPU(s): 6 x PA8600 (PCX-W+) at 550.000000 MHz
SBA found Ike rev 2 at 0xfffffffffed00000
SBA found Ike rev 2 at 0xfffffffffed40000
lba version TR2.2 (0x3) found at 0xffffffffbffe0000
lba range[2] : ignoring GMMIO (0xfffffff004000000)
lba version TR2.2 (0x3) found at 0xffffffffbffe2000
lba range[2] : ignoring GMMIO (0xfffffff084000000)
lba version TR3.0 (0x4) found at 0xffffffffbffe4000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff104000000)
lba version TR3.0 (0x4) found at 0xffffffffbffe8000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff204000000)
lba version TR3.0 (0x4) found at 0xffffffffbffea000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff284000000)
lba version TR3.0 (0x4) found at 0xffffffffbfff0000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff404000000)
lba version TR3.0 (0x4) found at 0xffffffffbfff4000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff504000000)
lba version TR3.0 (0x4) found at 0xffffffffbfff8000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff604000000)
lba version TR3.0 (0x4) found at 0xfffffffffece0000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff804000000)
lba version TR3.0 (0x4) found at 0xfffffffffece4000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffff904000000)
lba version TR3.0 (0x4) found at 0xfffffffffece8000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffffa04000000)
lba version TR3.0 (0x4) found at 0xfffffffffecf0000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffffc04000000)
lba version TR3.0 (0x4) found at 0xfffffffffecf4000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffffd04000000)
lba version TR3.0 (0x4) found at 0xfffffffffecf8000
kernel BUG at lba_pci.c:1250!
kernel BUG at lba_pci.c:1285!
lba range[2] : ignoring GMMIO (0xfffffffe04000000)
POSIX conformance testing by UNIFIX
FP[1] enabled: Rev 1 Model 16
FP[2] enabled: Rev 1 Model 16
FP[3] enabled: Rev 1 Model 16
FP[4] enabled: Rev 1 Model 16
FP[5] enabled: Rev 1 Model 16
SMP: Total 6 of 6 processors activated (6586.37 BogoMIPS noticed).
Waiting on wait_init_idle (map = 0x3e)
All processors have done init_idle
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Performance monitoring counters enabled for Prelude W+ 540
Starting kswapd
Journalled Block Device driver loaded
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
Redundant entry in serial pci_table.  Please send the output of
lspci -vv, this message (103c,1048,103c,1049)
and the manufacturer and name of serial board or modem board
to serial-pci-info@lists.sourceforge.net.
ttyS00 at iomem 0xffffffff80000000 (irq = 132) is a 16550A
ttyS01 at iomem 0xffffffff80000008 (irq = 132) is a 16550A
ttyS02 at iomem 0xffffffff80000010 (irq = 132) is a 16550A
Redundant entry in serial pci_table.  Please send the output of
lspci -vv, this message (103c,1048,103c,104a)
and the manufacturer and name of serial board or modem board
to serial-pci-info@lists.sourceforge.net.
ttyS03 at iomem 0xffffffff80003000 (irq = 133) is a 16550A
ttyS04 at iomem 0xffffffff80003008 (irq = 133) is a 16550A
lp: driver loaded but no devices found
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
block: 128 slots per queue, batch=32
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
loop: loaded (max 8 devices)
Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 0061.
eth0: Digital DS21143 Tulip rev 65 at 0x80, 00:10:83:F5:85:5B, IRQ 128.
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 0, device 2, function 0
sym53c8xx: 53c875 detected
sym53c8xx: at PCI bus 0, device 2, function 1
sym53c8xx: 53c875 detected
sym53c8xx: at PCI bus 0, device 1, function 0
sym53c8xx: 53c895 detected
sym53c875-0: rev 0x14 on pci bus 0 device 2 function 0 irq 130
sym53c875-0: ID 7, Fast-20, Parity Checking
sym53c875-1: rev 0x14 on pci bus 0 device 2 function 1 irq 131
sym53c875-1: ID 7, Fast-20, Parity Checking
sym53c895-2: rev 0x1 on pci bus 0 device 1 function 0 irq 129
sym53c895-2: ID 7, Fast-10, Parity Checking
sym53c895-2: SCSI bus mode change from 80 to 80.
scsi0 : sym53c8xx-1.7.3c-20010512
scsi1 : sym53c8xx-1.7.3c-20010512
scsi2 : sym53c8xx-1.7.3c-20010512
  Vendor: SEAGATE   Model: ST39103LC         Rev: HP01
  Type:   Direct-Access                      ANSI SCSI revision: 02
  Vendor: HP        Model: DVD-ROM 305       Rev: 1.01
  Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi disk sda at scsi1, channel 0, id 6, lun 0
sym53c875-1-<6,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 15)
SCSI device sda: 17783112 512-byte hdwr sectors (9105 MB)
Partition check:
 sda: sda1 sda2 sda3 sda4
Attached scsi CD-ROM sr0 at scsi2, channel 0, id 2, lun 0
sym53c895-2-<2,*>: FAST-10 SCSI 10.0 MB/s (100.0 ns, offset 16)
sr0: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
sticonsole_init: searching for STI ROMs
BUG: Skipping previously registered driver: sti (native)
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
   8regs     :  2536.400 MB/sec
   8regs_prefetch:  1966.400 MB/sec
   32regs    :  2071.600 MB/sec
   32regs_prefetch:  1935.600 MB/sec
raid5: using function: 8regs (2536.400 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 96Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
NOT FREEING INITMEM (488k)
INIT: version 2.84 booting

************* SYSTEM ALERT **************
SYSTEM NAME: hpntc660
DATE: 03/12/2002 TIME: 23:39:32
ALERT LEVEL: 7 = reserved

REASON FOR ALERT
SOURCE: 0 = unknown, no source stated
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: FF
PROBLEM DETAIL: 0 = no problem detail

LEDs:  RUN      ATTENTION     FAULT     REMOTE     POWER
       FLASH    FLASH         FLASH     ON         ON

0x0000407000FF6292 00000000 00000000 - type  0 = Data Field Unused
0x5800487000FF6292 00006602 0C172720 - type 11 = Timestamp 03/12/2002
23:39:32
A: ack read of this entry - X: Disable all future alert messages
Anything else skip redisplay the log entry
->Choice:Timeout!
*****************************************

----------------------End Msg---------------------------

Re: [parisc-linux] Switch console error.

[Matthew Wilcox]

On Tue, Mar 12, 2002 at 03:08:31PM -0800, Gururaj Ananthateerta wrote:
> I did that, but the kernel panic during  boot and the following was the
> message
> on the screen.

> VFS: Mounted root (ext2 filesystem) readonly.
> NOT FREEING INITMEM (488k)
> INIT: version 2.84 booting

So, the kernel runs fine, until it starts executing userspace.  Here's
what we _think_ is going on:

The kernel has its own mappings for pages so it can take advantage of
16MB pages.  These are not coherent with the pages that are mapped into
user space.  By (ab)using the kmap() functionality, this problem can be
solved and may even result in a performance increase for all machines.
No real time to work on this...

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Switch console error.

[Grant Grundler]

Matthew Wilcox wrote:
> The kernel has its own mappings for pages so it can take advantage of
> 16MB pages.  These are not coherent with the pages that are mapped into
> user space. 

And this would cause an HPMC?
(iirc, chassis codes indicated HPMC)
If someone could decode the Gururaj's HPMC data ("ser pim" from BCH prompt)
and post the results.  At worst, it would confirm this theory.

> By (ab)using the kmap() functionality, this problem can be
> solved and may even result in a performance increase for all machines.
> No real time to work on this...

Sorry, I'm not VM clueful enough to understand why this would be a
problem on N-class and not other boxes.  I know coherency works differently
here (Merced Bus is "central" vs Runway for most other boxes).
Someplace to look for more clues?
just curious...

thanks,
grant

Re: [parisc-linux] Switch console error.

[Matthew Wilcox]

On Tue, Mar 12, 2002 at 06:42:06PM -0700, Grant Grundler wrote:
> Matthew Wilcox wrote:
> > The kernel has its own mappings for pages so it can take advantage of
> > 16MB pages.  These are not coherent with the pages that are mapped into
> > user space. 
> 
> And this would cause an HPMC?

Yes, indirectly, see below.

> If someone could decode the Gururaj's HPMC data ("ser pim" from BCH prompt)
> and post the results.  At worst, it would confirm this theory.

Yes, that would certainly help.  As I said, it is only a theory...

> Sorry, I'm not VM clueful enough to understand why this would be a
> problem on N-class and not other boxes.  I know coherency works differently
> here (Merced Bus is "central" vs Runway for most other boxes).
> Someplace to look for more clues?

It's not to do with the bus (AFAIK...).  It's to do with Stretch (the
memory controller).  We've got away with using non-equivalent aliases (see
the PA 2.0 book [1]) up until now, but it seems that Stretch doesn't let
us get away with it any more.  So we have to be sure to use equivalent
aliases when accessing a page.  It's been suggested to me that Stretch
has its own tags for a page and if it gets writes to different tags on
the same physical page, it generates an HPMC.

[1] I would have given a reference here, but
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,959,00.html
gives me a Redirection Limit exceeded error... hopefully this will get
fixed soon.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Switch console error.

[Randolph Chung]

> [1] I would have given a reference here, but
> http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,959,00.html
> gives me a Redirection Limit exceeded error... hopefully this will get
> fixed soon.

until it gets fixed, you can get the PDF version

it's in appendix F, in the dead-tree book format it's on page F-5.
Here's the PDF:

http://h21007.www2.hp.com/dspp/files/unprotected/parisc20/PA_F_TLB_cache.pdf

not that i know what it means after i read the section... :-)

randolph
-- 
Debian Developer <tausq@debian.org>
http://www.TauSq.org/

Re: [parisc-linux] Switch console error.

[Matthew Wilcox]

On Tue, Mar 12, 2002 at 04:03:59PM -0800, Gururaj Ananthateerta wrote:
> well, this whole exercise was to contribute to parisc linux developement.
> well I got something to work on then.  Can u help me with sime jumpstarters.

sure.  here's the plan i had.  you may disagree...

The architecture guarantees us that pages which are mapped at the same
address, modulo 4MB, will be cache coherent.  We already take advantage
of this (see get_shared_area in arch/parisc/kernel/sys_parisc.c, called
via arch_get_unmapped_area from the mmap path).  So all user mappings of a
page are coherent.  What isn't coherent is the kernel's view of the page.

Before the kernel accesses a page which is in the page cache (all pages
which can be mmaped live in the page cache), it calls kmap() and after
it has finished accessing this page, it calls kunmap().  This scheme was
invented for the benefit of architectures which support more physical
memory then it has address lines for (eg PAE36 on x86).

So if we reserve a large chunk of the kernel's address space to map
page cache pages into temporarily with kmap, we can provide the kernel
with a coherent view of the page.  Superdome only supports 128GB ram,
so by reserving a 128TB chunk of address space (hey, we have plenty of
address space..)  we give each 4k page a 4MB space to be mapped in.

The obvious way to do it, which I've described to everyone up until
now is to do something like:

void *kmap(struct *page) {
	struct vm_area_struct *vma = page->mapping->i_mmap_shared;
	if (!vma)
		return page->virtual;
	return (void *) ((unsigned long) page->virtual << 10 | vma->vm_pgoff);
}

But I wonder whether it might not be feasible to simply adjust
page->virtual when changing the mapping of a page into userspace.
Something to investigate further.

This is the easy part of the solution.  The part I haven't even attempted
to describe is, what if we get a TLB miss?  See the assembly code for the
TLB miss handler in arch/parisc/kernel/entry.S, starting at dtlb_miss_20w:
You'd probably want to modify dtlb_check_alias_20w to check for this case
rather than insert a huge number of TLB entries.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Switch console error.

[Christoph Plattner]

First of all, have you really waited for a long time, when the machines
hangs on that "last" console output. I have made the experience, that
sometimes (I have not found a systematic behind that, yet) the machine
delays for a longer while (up to half a minute) and suddenly it
continoues
booting perfectly.

Second, you may play around with the PDC console driver for linux
(/dev/ttyB0 at major 60). If this driver is configured
(CONFIG_PDC_CONSOLE,
under "Non-standard serial port support"), then you have the same
effect as activating macro "EARLY_BOOTUP_DEBUG", but you can use
non-supported serial consoles (PDC console) as full console device
including login, etc.....

See the HELP button of CONFIG_PDC_CONSOLE for more details on setup.

With friendly regards
Christoph Plattner



Matthew Wilcox wrote:
> 
> On Tue, Mar 12, 2002 at 12:37:24PM -0800, Gururaj Ananthateerta wrote:
> > both of them are set to 'y'
> 
> OK.  Since this is an N class, the serial ports should be automatically
> detected on the Diva card.  Towards the top of arch/parisc/kernel/pdc_cons.c
> you'll see:
> 
> /* Define EARLY_BOOTUP_DEBUG to debug kernel related boot problems.
>  * On production kernels EARLY_BOOTUP_DEBUG should be undefined. */
> #undef EARLY_BOOTUP_DEBUG
> 
> Change the #undef to #define and recompile.  Do you see any more output?
> 
> --
> Revolutions do not require corporate support.
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

-- 
-------------------------------------------------------
private:	christoph.plattner@gmx.at
company:	christoph.plattner@alcatel.at

[parisc-linux] TOC on B180L

[Gururaj Ananthateerta]

anyone has any clue to generate a TOC on B180L

Re: [parisc-linux] TOC on B180L

[Matthew Wilcox]

On Wed, Mar 13, 2002 at 07:31:21PM -0800, Gururaj Ananthateerta wrote:
> anyone has any clue to generate a TOC on B180L

Little button on the back, press it with a pen tip.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] TOC on B180L

[Gururaj Ananthateerta]

tried , that button is not present.
there is a place holder but.




Matthew Wilcox wrote:

> On Wed, Mar 13, 2002 at 07:31:21PM -0800, Gururaj Ananthateerta wrote:
> > anyone has any clue to generate a TOC on B180L
>
> Little button on the back, press it with a pen tip.
>
> --
> Revolutions do not require corporate support.

Re: [parisc-linux] TOC on B180L

[Grant Grundler]

Gururaj Ananthateerta wrote:
> tried , that button is not present.
> there is a place holder but.

uhm...it's possible the machine is locked up in a way
where TOC is not effective...IIRC, it's a recessed, blue button
about 1mm is diameter. I expect (but haven't checked)
the B180 owners guide to be on docs.hp.com and it should
describe where TOC button is.

grant

[parisc-linux] TOC on B180L

[joel.soete]

Hi Grant,

On my B180L the TOC blue button is located (on the back of the 'server') just
between the keyboard connector and the video connector. (On all we have here,
the button is located at the same place).

Joel

PS: Is this interrupt will be consider as a hardware reset by linux kernel? (I
never try it because LKCD is not yet available)
 

-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] TOC on B180L

[Grant Grundler]

joel.soete@freebel.net wrote:
> On my B180L the TOC blue button is located (on the back of the 'server') just
> between the keyboard connector and the video connector. (On all we have here,
> the button is located at the same place).

thanks - should be the same place for all B-xxx machines.

> PS: Is this interrupt will be consider as a hardware reset by linux kernel?

I don't know...I expect it be treated like an HPMC (or NMI)...which
depending on how the HW has locked up...