[parisc-linux] Status report - B132L and 725/100

[parisc-linux] Status report - B132L and 725/100

[Andy Walker]

Hi folks,

This is stock 0.9.3.

Over the weekend I was using the B132L with an original HP keyboard.
No sign of the LASI PS/2 keyboard timeouts that were bugging me on
thursday night. Whether that's because the HP keyboard differs from
the generic PS/2 keyboard I was using before, or just because I wasn't
hitting the cdrom hard for data at the same time I don't know. I'll
report back if I see the problem again.

Fired up the 725/100 I was talking about last week. Works like a charm.
Initially I used the builtin framebuffer (HPA208LC1280 - 1280-1024-8).
Then I stuck in a Coral GSC (HPA4071B_LZ) in GSC slot 2.

Both work fine, but the same weird thing with the frame buffer ordering
occurred with the 725/100 as it did with the B132L last week. With the
console set in the PDC to the built-in fb, the kernel starts to boot
on that device, then finds the Coral first and continues to boot
on that, calling it fb0. Setting the console in PDC to the Coral makes
everything work properly - the system boots all the way on the Coral.

I had to pull the Bluefish F/W-Diff card (or at least disconnect the
disk) but it may have been termination problems causing the timeouts/
resets. Something else to test :-)

Here's the dmesg from the 725/100. The unknown scancode, 7f, is
less-than/greater-than on a Norwegian PS/2 keyboard. I imagine that
can be fixed :-)

-Andy

Linux version 2.4.9-32 (root@paer) (gcc version 3.0.2 (Debian)) #1 Fri Nov 30 
19:36:30 MST 2001
FP[0] enabled: Rev 1 Model 13
The 32-bit Kernel has started...
Determining PDC firmware type: Snake.
model	000060d0 00000481 00000000 00000000 77ec54a0 00000000 00000004 00000072 
00000072
vers	0000000b
CPUID	vers 0 rev 0
model	9000/725
Total Memory: 320 Mb
pagetable_init
On node 0 totalpages: 81920
zone(0): 81920 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda2 HOME=/ console=tty0 sti=0 sti_font=VGA8x16 
TERM=linux
Console: colour dummy device 160x64
Calibrating delay loop... 99.73 BogoMIPS
Memory: 319540k available
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Searching for devices...
Found devices:
1. Coral SGC Graphics (10) at 0xf4000000 [0], versions 0x4, 0x0, 0x77
2. Electra GSC Builtin Graphics (10) at 0xf8000000 [1], versions 0x14, 0x0, 0x85
3. Electra Core BA (11) at 0xf0100000 [2], versions 0x2a, 0x0, 0x81
4. Electra Core SCSI (10) at 0xf0106000 [2/0/1], versions 0x2a, 0x0, 0x82
5. Electra Core LAN (802.3) (10) at 0xf0107000 [2/0/2], versions 0x2a, 0x0, 0x8a
6. Electra Core RS-232 (10) at 0xf0105000 [2/0/4], versions 0x2a, 0x0, 0x8c
7. Electra Core Centronics (10) at 0xf0102000 [2/0/6], versions 0x2a, 0x0, 0x74
8. Electra Audio (10) at 0xf0104000 [2/0/8], versions 0x2a, 0x0, 0x7b
9. Electra Core PC Floppy (10) at 0xf010a000 [2/0/10], versions 0x2a, 0x0, 0x83
10. Electra Core PS/2 Port (10) at 0xf0108000 [2/0/11], versions 0x2a, 0x0, 0x84
11. Electra Core PS/2 Port (10) at 0xf0108100 [2/0/12], versions 0x2a, 0x0, 0x84
12. Electra Wax EISA BA (11) at 0xfc000000 [4], versions 0x2a, 0x0, 0x90
13. Electra Wax BA (11) at 0xf0200000 [5], versions 0x14, 0x0, 0x8e
14. Electra Wax HIL (10) at 0xf0201000 [5/0/1], versions 0x14, 0x0, 0x73
15. Electra Wax RS-232 (10) at 0xf0202000 [5/0/2], versions 0x14, 0x0, 0x8c
16. Electra 100 (0) at 0xfffbe000 [8], versions 0x60d, 0x0, 0x4
17. Electra 100 (1) at 0xfffbf000 [9], versions 0x4d, 0x0, 0x9
CPU(s): 1 x PA7100LC (PCX-L) at 100.000000 MHz
Lasi version 0 at 0xf0100000 found.
LED display at f00e0000 registered
Wax at 0xf0200000 found.
Wax: HIL Keyboard-NMI registered.
Wax EISA Adapter found at 0xfc000000
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xf0102800, irq 88 [PCSPP,TRISTATE]
STI byte mode ROM at f4000000, hpa=f4000000
STI byte mode ROM, id 2bcb015a-9a02587, conforms to spec rev. 8.04
STI device: HPA4071B_LZ
STI word mode ROM at f0024000, hpa=f8000000
STI word mode ROM, id 2b4ded6d-40a00499, conforms to spec rev. 8.04
STI device: HPA208LC1280
Console: switching to colour frame buffer device 160x64
fb0: stifb 1280x1024-32 frame buffer device, id: 2bcb015a, mmio: 0xf4100000
fb1: stifb 1280x1024-8 frame buffer device, id: 2b4ded6d, mmio: 0xf8100000
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI 
enabled
ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A
ttyS01 at iomem 0xf0202800 (irq = 121) is a 16550A
PS/2 keyboard port at 0xf0108000 (irq 69) found, device attached.
PS/2 psaux port at 0xf0108100 (irq 69) found, device attached.
Found HIL at 0xf0201000, IRQ 126
HIL: no keyboard present.
Warning : device (10, 0x14, 0x0, 0x73) NOT claimed by HIL
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
block: 128 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize
loop: loaded (max 8 devices)
Found i82596 at 0xf0107000, IRQ 87
eth0: 82596 at 0xf0107000, 08 00 09 0A 0C 6B IRQ 87.
82596.c $Revision: 1.26 $
SCSI subsystem driver Revision: 1.00
53c700: Version 2.6 By James.Bottomley@HansenPartnership.com
scsi0: 53c710 rev 2 
scsi0 : LASI SCSI 53c700
scsi0: (3:0) Synchronous at offset 8, period 200ns
  Vendor: HP        Model: HP35480A          Rev: 1109
  Type:   Sequential-Access                  ANSI SCSI revision: 02
scsi0: (6:0) Synchronous at offset 8, period 100ns
  Vendor: SEAGATE   Model: ST31055N          Rev: 0532
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 6, lun 0
scsi0: (6:0) Enabling Tag Command Queuing
SCSI device sda: 2069860 512-byte hdwr sectors (1060 MB)
Partition check:
 sda: sda1 sda2 sda3 sda4
Lasi Harmony Audio rev. 18 at 0xf0104000, using IRQ 82
sticonsole_init: searching for STI ROMs
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
IP: routing cache hash table of 2048 buckets, 16Kbytes
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.
Adding Swap: 195384k swap-space (priority -1)
eth0: link ok.
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored
keyboard: unrecognized scancode (7f) - ignored



------------------------------------------------------------
Få din egen @start.no-adresse gratis på http://www.start.no/

Re: [parisc-linux] Status report - B132L and 725/100

[Andy Walker]

Quoting Andy Walker <squawker@start.no>:

> I had to pull the Bluefish F/W-Diff card (or at least disconnect the
> disk) but it may have been termination problems causing the timeouts/
> resets. Something else to test :-)

Okay, checked termination. Tried a different disk. Booted HP-UX on
that disk. No luck with Linux.

Relevant part of the dmesg is:

...
18. Bluefish Add-on FW-SCSI (4) at 0xfff8c000 [11], versions 0x13, 0x0, 0x89
...
zalon_scsi_callback: Zalon vers field is 0x1, IRQ 34
ncr53c8xx: 53c720 detected
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
scsi0 : ncr53c8xx-3.4.3b-20010512

-Andy

------------------------------------------------------------
Få din egen @start.no-adresse gratis på http://www.start.no/

Re: [parisc-linux] Status report - B132L and 725/100

[Matthew Wilcox]

On Mon, Dec 17, 2001 at 12:47:23PM +0100, Andy Walker wrote:
> Both work fine, but the same weird thing with the frame buffer ordering
> occurred with the 725/100 as it did with the B132L last week. With the
> console set in the PDC to the built-in fb, the kernel starts to boot
> on that device, then finds the Coral first and continues to boot
> on that, calling it fb0. Setting the console in PDC to the Coral makes
> everything work properly - the system boots all the way on the Coral.

OK, we need to figure out how to order the fb devices properly.  Right
now, they're initialised in IO tree order.  On a gecko with a graphics
card in the expansion slot, the expansion grahics gets device 0 and the
inbuilt is device 1.  Clearly similar problems exist on other machines.

So could everyone who has two (or more!) graphics cards in their machine
send the two lines of dmesg which describe their graphics card in the
inventory / buswalk section, their machine type (B132, Gecko, etc)
and indicate whether or not it gets them in the right order currently.

Example (made up!):

4. Frobnitz Ultra Graphics (10) at 0xf8000000 [8/1], versions 0xa, 0x0, 0x77
13. Thunder II graphics GSA form (10) at 0xf4000000 [10/8], versions 0xa, 0x0, 0x77
J282, works

Thanks.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Status report - B132L and 725/100

[Helge Deller]

On Monday 17 December 2001 15:35, Matthew Wilcox wrote:
> On Mon, Dec 17, 2001 at 12:47:23PM +0100, Andy Walker wrote:
> > Both work fine, but the same weird thing with the frame buffer ordering
> > occurred with the 725/100 as it did with the B132L last week. With the
> > console set in the PDC to the built-in fb, the kernel starts to boot
> > on that device, then finds the Coral first and continues to boot
> > on that, calling it fb0. Setting the console in PDC to the Coral makes
> > everything work properly - the system boots all the way on the Coral.
>
> OK, we need to figure out how to order the fb devices properly.  Right
> now, they're initialised in IO tree order.  On a gecko with a graphics
> card in the expansion slot, the expansion grahics gets device 0 and the
> inbuilt is device 1.  Clearly similar problems exist on other machines.

Hi Matthew, List,

I think a better solution would be to sort the found graphic devices by the hpa.
Acording to the sti documentation the only allowed hpa's (at least for GSC 
and SGCsystems) are 0xf8000000, 0xf4000000, 0xfa000000 and 0xf6000000.
0xf8000000 is always the build-in graphic device (e.g. Artist) and should be by default fb0,
0xf4000000 is described in the 712 memory map as  second Artist (second gfx card)
and should be fb1, and equally  0xfa000000 and 0xf6000000 should be used as
 fb2 and fb3 (or vice versa - I didn't checked those last two).
In case the user wants to override with the sti= parameter the kernel should now
select this entry (e.g. sti=1 should select the card at 0xf4000000).

I didn't looked at the implementation really hard yet, but I think this shouldn't be 
that hard to code.

Helge

Re: [parisc-linux] Status report - B132L and 725/100

[Thomas Bogendoerfer]

On Mon, Dec 17, 2001 at 11:21:01PM +0100, Helge Deller wrote:
> I think a better solution would be to sort the found graphic devices by the hpa.
[...]
> In case the user wants to override with the sti= parameter the kernel should now
> select this entry (e.g. sti=1 should select the card at 0xf4000000).

the big problem is, that stifb completly ignores sti= from the commandline
and video=map doesn't seem to work (I need to reconfigure a machine to test
that myself, which I hadn't time yet). The best thing would be to use
the console path from pdc, no idea how hard that is.

It's probably not a big deal to use the default sti (sti=) for stifb, but
I'd prefer either a video="???" solution or the pdc console path. If we 
decide on a solution, I'm going to implement it (if nobody else wants
to do it :-)).

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] Status report - B132L and 725/100

[Andy Walker]

Quoting Thomas Bogendoerfer <tsbogend@alpha.franken.de>:

> On Mon, Dec 17, 2001 at 11:21:01PM +0100, Helge Deller wrote:
> > I think a better solution would be to sort the found graphic devices
> by the hpa.
> [...]
> > In case the user wants to override with the sti= parameter the kernel
> should now
> > select this entry (e.g. sti=1 should select the card at 0xf4000000).
> 
> the big problem is, that stifb completly ignores sti= from the
> commandline
> and video=map doesn't seem to work (I need to reconfigure a machine to
> test
> that myself, which I hadn't time yet). The best thing would be to use
> the console path from pdc, no idea how hard that is.

I agree with Thomas here. The PDC console path should always be mapped to
fb0 if possible. How we order the other frambuffers is of less importance,
but the average user shouldn't need to play around with kernel parameters
to make the machine boot sensibly.

> It's probably not a big deal to use the default sti (sti=) for stifb,
> but I'd prefer either a video="???" solution or the pdc console path. If we
> decide on a solution, I'm going to implement it (if nobody else wants
> to do it :-)).
> 
> Thomas.

I'll certainly help with any testing I can - can't promise too many programming
hours right now though, unfortunately :(

-Andy

------------------------------------------------------------
Få din egen @start.no-adresse gratis på http://www.start.no/

Re: [parisc-linux] Status report - B132L and 725/100

[Richard Hirst]

On Mon, Dec 17, 2001 at 02:15:58PM +0100, Andy Walker wrote:
> Quoting Andy Walker <squawker@start.no>:
> 
> > I had to pull the Bluefish F/W-Diff card (or at least disconnect the
> > disk) but it may have been termination problems causing the timeouts/
> > resets. Something else to test :-)
> 
> Okay, checked termination. Tried a different disk. Booted HP-UX on
> that disk. No luck with Linux.
> 
> Relevant part of the dmesg is:
> 
> ...
> 18. Bluefish Add-on FW-SCSI (4) at 0xfff8c000 [11], versions 0x13, 0x0, 0x89
> ...
> zalon_scsi_callback: Zalon vers field is 0x1, IRQ 34
> ncr53c8xx: 53c720 detected
> ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
> scsi0 : ncr53c8xx-3.4.3b-20010512

Don't know why that is failing; does it always fail, or is it an
intermittant problem?  e.g. Are the disks detected at boottime?

You might try booting with something like

ncr53c8xx=sync:255,burst:0,verb:2

which slows it down and might help if it is intermittant (just guessing though)

Richard

Re: [parisc-linux] Status report - B132L and 725/100

[Andy Walker]

Quoting Richard Hirst <rhirst@linuxcare.com>:
> > 
> > ...
> > 18. Bluefish Add-on FW-SCSI (4) at 0xfff8c000 [11], versions 0x13,
> 0x0, 0x89
> > ...
> > zalon_scsi_callback: Zalon vers field is 0x1, IRQ 34
> > ncr53c8xx: 53c720 detected
> > ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
> > scsi0 : ncr53c8xx-3.4.3b-20010512
> 
> Don't know why that is failing; does it always fail, or is it an
> intermittant problem?  e.g. Are the disks detected at boottime?
> 
> You might try booting with something like
> 
> ncr53c8xx=sync:255,burst:0,verb:2
> 
> which slows it down and might help if it is intermittant (just guessing
> though)
> 
> Richard
> 

Hi Richard,

Yep, it always fails. If there's a disk on the bus (I've tried a couple
of different ones) it will always hang on boot with timeouts and bus
resets when trying to find the disk.

To triple check the termination, I installed the terminator packs on
the card and moved the cable from the internal connector to the
external one. No difference there, even with your kernel parameter
suggestion.

Here's the verbose output from a boot without a disk connected:

zalon_scsi_callback: Zalon vers field is 0x1, IRQ 34
ncr53c8xx: 
setup=disc:y,specf:3,tags:8,sync:255,burst:0,wide:y,diff:0,revprob:n,buschk:0x1
ncr53c8xx: 
setup=mpar:y,spar:y,fsn=n,verb:2,debug:0x0,led:n,settle:2,irqm:0x0,nvram:0x1,pci
fix:0x0
ncr53c8xx: 53c720 detected
ncr53c720-0: using memory mapped IO at virtual address 0xfff8c800
ncr53c720-0: ID 7, Fast-10, Parity Checking, Differential
ncr53c720-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/00/20/00/80/00
ncr53c720-0: final   SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 03/00/20/00/88/00
ncr53c720-0: resetting, command processing suspended for 2 seconds
ncr53c720-0: restart (scsi reset).
scsi0 : ncr53c8xx-3.4.3b-20010512
ncr53c720-0: command processing resumed

I'm gonna try one more disk, one that I've tested with Linux on the B132,
but that won't be until tomorrow.

-Andy



------------------------------------------------------------
Få din egen @start.no-adresse gratis på http://www.start.no/

Re: [parisc-linux] Status report - B132L and 725/100

[Grant Grundler]

Andy Walker wrote:
> To triple check the termination, I installed the terminator packs on
> the card and moved the cable from the internal connector to the
> external one. No difference there, even with your kernel parameter
> suggestion.

Couple more things:
o make sure your disks are *not* terminated - just both ends of the bus.
o double check all connectors to make sure there are no bent pins.
o replace any cables you can - especially external ones.
o verify the disks are the correct type. For c720, I expect
  *differential* SCSI.  Single Ended disks were used with LASI based
  machines (53c710) and built-in fast/wide on a few of the BXXX/CXXX
  workstations.

grant

Re: [parisc-linux] Status report - B132L and 725/100

[Michael S.Zick]

On Wednesday 19 December 2001 10:56 am, Grant Grundler wrote:
- - - snip - - -
> o verify the disks are the correct type. For c720, I expect
>   *differential* SCSI.  Single Ended disks were used with LASI based
>   machines (53c710) and built-in fast/wide on a few of the BXXX/CXXX
>   workstations.

My 9000/720/50 has factory labels on the external disk connectors specifing 
the type of disk to use ("Warning, use single ended disks only").

Perhaps the 725/100 has similar labels (inside or outside the box).

Mike

Re: [parisc-linux] Status report - B132L and 725/100

[Andy Walker]

From: "Grant Grundler" <grundler@dsl2.external.hp.com>

> Andy Walker wrote:
> > To triple check the termination, I installed the terminator packs on
> > the card and moved the cable from the internal connector to the
> > external one. No difference there, even with your kernel parameter
> > suggestion.
>
> Couple more things:
> o make sure your disks are *not* terminated - just both ends of the bus.

Already checked. The internal cable has a terminator built into the end. The
disks are definitely not terminated.
In the original configuration the internal was attached to the internal
connector. There wer no terminator packs on the card itself, and there was
a terminator attached to the external connector.
In the second configuration, I hung the internal cable on the external
connector, and installed the terminator packs on the card. Same results.

> o double check all connectors to make sure there are no bent pins.
> o replace any cables you can - especially external ones.

I'll double check all this tomorrow, but the fact that I can boot HP-UX
off of these disks suggests that the hardware is intact. At the moment
I'm only using a single internal cable - I'll swap it and see what
happens.

> o verify the disks are the correct type. For c720, I expect
>   *differential* SCSI.  Single Ended disks were used with LASI based
>   machines (53c710) and built-in fast/wide on a few of the BXXX/CXXX
>   workstations.

Well, one of the disks in question is the original HP-UX boot disk for
this machine, and its a Seagate WD prefix disk. The other disk I tried
is also a WD disk, taken from a C110. The Bluefish is reported as diff
by the 53c8xx driver, it says differential on the external connector -
there can't be any doubt, can there? This should all work together.

Obviously, my initial thoughts went to the know problems with the c720
on 735's. The problem does seem very similar - I understood that the
735 problem was caused by some weirdo HP glue logic chip. Could this
not be a similar case?

Anyway, I'll take an known good disk with me tomorrow and try that with
a different internal cable. I'll also double check that everything is
still working with HP-UX. More news as it breaks.........

-Andy

Re: [parisc-linux] Status report - B132L and 725/100

[Grant Grundler]

"Andy Walker" wrote:
> by the 53c8xx driver, it says differential on the external connector -
> there can't be any doubt, can there? This should all work together.

It sounds like it should all just work. Especially if HPUX works.
But HPUX sometimes cripples the bus speed or *wideth* based
on what PDC tells it. Perhaps you need to do the same. I really
don't expect any issues with bus speed on differential SCSIs.
Possibly a wide vs narrow bus issue (Chip thinks it's wide and the cabling
is narrow). We see that on C3k still and I started (but didn't finish)
the code to query PDC about Host SCSI ID, bus speed, and width.

> Anyway, I'll take an known good disk with me tomorrow and try that with
> a different internal cable. I'll also double check that everything is
> still working with HP-UX. More news as it breaks.........

Yeah - if HPUX boots/talks to the devices, they are basically ok.
It's a matter of getting the linux driver the right parameters then.

grant

Re: [parisc-linux] Status report - B132L and 725/100

[Richard Hirst]

On Wed, Dec 19, 2001 at 01:40:48PM -0700, Grant Grundler wrote:
> "Andy Walker" wrote:
> > by the 53c8xx driver, it says differential on the external connector -
> > there can't be any doubt, can there? This should all work together.
> 
> It sounds like it should all just work. Especially if HPUX works.
> But HPUX sometimes cripples the bus speed or *wideth* based
> on what PDC tells it. Perhaps you need to do the same. I really
> don't expect any issues with bus speed on differential SCSIs.
> Possibly a wide vs narrow bus issue (Chip thinks it's wide and the cabling
> is narrow). We see that on C3k still and I started (but didn't finish)
> the code to query PDC about Host SCSI ID, bus speed, and width.
> 
> > Anyway, I'll take an known good disk with me tomorrow and try that with
> > a different internal cable. I'll also double check that everything is
> > still working with HP-UX. More news as it breaks.........
> 
> Yeah - if HPUX boots/talks to the devices, they are basically ok.
> It's a matter of getting the linux driver the right parameters then.

Re: [parisc-linux] Status report - B132L and 725/100

[Richard Hirst]

On Mon, Dec 17, 2001 at 12:47:23PM +0100, Andy Walker wrote:
> Here's the dmesg from the 725/100. The unknown scancode, 7f, is
> less-than/greater-than on a Norwegian PS/2 keyboard. I imagine that
> can be fixed :-)

I have a UK keyboard here with 7f generated by the bar+backslash key.
Turns out that to make it works I have to use dumpkeys to discover
that the keycode I want is 86 (decimal), and then running
"setkeycodes 7f 86" makes the key work.  And yes, that is a hex 7f
with no '0x' followed by a decimal 86!

Before this will work with a PS/2 keyboard, you need a new kernel,
2.4.16-pa21 or better, as there was a bug in the set/getkeycode code.

Richard

Re: [parisc-linux] Status report - B132L and 725/100

[Andy Walker]

Quoting Richard Hirst <rhirst@linuxcare.com>:

> On Wed, Dec 19, 2001 at 01:40:48PM -0700, Grant Grundler wrote:
> > "Andy Walker" wrote:
> > > by the 53c8xx driver, it says differential on the external connector
> -
> > > there can't be any doubt, can there? This should all work
> together.
> > 
> > It sounds like it should all just work. Especially if HPUX works.
> > But HPUX sometimes cripples the bus speed or *wideth* based
> > on what PDC tells it. Perhaps you need to do the same. I really
> > don't expect any issues with bus speed on differential SCSIs.
> > Possibly a wide vs narrow bus issue (Chip thinks it's wide and the
> cabling
> > is narrow). We see that on C3k still and I started (but didn't
> finish)
> > the code to query PDC about Host SCSI ID, bus speed, and width.
> > 
> > > Anyway, I'll take an known good disk with me tomorrow and try that
> with
> > > a different internal cable. I'll also double check that everything
> is
> > > still working with HP-UX. More news as it breaks.........
> > 
> > Yeah - if HPUX boots/talks to the devices, they are basically ok.
> > It's a matter of getting the linux driver the right parameters then.
> 
> >From drivers/scsi/README.ncr53c8xx, you can force narrow by booting
> with
> 
> ncr53c8xx=wide:0
> 
> and disable tagged commands with
> 
> ncr53c8xx=wide:0,tags:0
> 
> and force async with
> 
> ncr53c8xx=wide:0,tags:0,sync:255
> 
> and disable dma burst with
> 
> ncr53c8xx=wide:0,tags:0,sync:255,busrt:0
> 
> and disable disconnect with
> 
> ncr53c8xx=wide:0,tags:0,sync:255,burst:0,disc:n
> 
> 
> Richard

Absolutely no luck at all :-( Different disk, different cable - same
results. Tried Richard's parameter settings - nothing helps. Tried
ncr53c8xx=safe:y, still no joy.

But if I hang an HPUX bootdisk on the card, I can boot happily from
it. Bah!

Do we know of anybody who has one of these cards working?

-Andy

------------------------------------------------------------
Få din egen @start.no-adresse gratis på http://www.start.no/

Re: [parisc-linux] Status report - B132L and 725/100

[Richard Hirst]

On Thu, Dec 20, 2001 at 11:06:09AM +0100, Andy Walker wrote:
> Do we know of anybody who has one of these cards working?

bluefish cards are working on some machines - B180, Cxxx, for example,
but I'm not aware of anyone running one in a 725/100.  The linux driver requires
coherent memory to work (typically non-cached), and that feature isn't
provided across all PARISC CPU flavours.  In theory your 725/100 supports that
and so should work.  fwiw, the CPU in 735 doesn't support coherent memory, which
is why my attempt to add support for 53c720 on 735 (outfield) failed.

Richard

Re: [parisc-linux] Status report - B132L and 725/100

[Grant Grundler]

Andy Walker wrote:
> But if I hang an HPUX bootdisk on the card, I can boot happily from
> it. Bah!
> Do we know of anybody who has one of these cards working?

Yes. And it really shouldn't be any different than the
built-in 53c720 on other systems of the same vintage.
I can't pursue this...but getting a SCSI trace or driver
debug info would be the next step.

grant