Re: Sarge on J5000 workstation report
On Sat, Mar 19, 2005 at 01:22:22AM +0000, David Pye wrote:
> Hi there,
>
> I'm rather new to the hppa linux scene, so please forgive me if I overlook
> anything in my notes below. Of course, thanks to everyone that works on the
> hppa port - things generally went very well.
welcome - and thanks for posting the report - well done.
> Here's what I found:
>
> The woody cd doesnt boot at all on these for me (palo doesn't load, etc).
>
> The sarge full cd kernel DOES boot, but then panics (invalid write errors)
> regarding the initrd. (Media and iso seem good.)
>
> The sarge netinst cd does boot and installed correctly for me.
ah good. IIRC, the netinst CDs are the most current and what most of us test.
> The 2.4 SMP kernel that is installed automatically by d-i off the sarge rc2
> cd does not work properly on the J5000 - boots, but shortly after mounting
> the initrd, the system crashes with a Runway bus error).
2.4 kernel isn't supported anymore and I've previously asked
the install CDs install a 2.6 kernel for other reasons.
> 1) The message:
>
> Freeing unused kernel memory: Badness in smp_call_function at
> arch/parisc/kernel/smp.c:342
> Backtrace:
> [<1011963c>] smp_call_function+0x408/0x410
> [<101088dc>] flush_data_cache+0x24/0x40
> [<10107a38>] free_initmem+0x78/0x38c
> [<10103d30>] init+0x304/0x410
> [<10110c5c>] ret_from_kernel_thread+0x1c/0x24
>
> This doesn't seem to affect normal operation, however, but I thought I'd
> report it.
Correct - known problem. I forgot the root cause though.
> 2) Rebooting the system, or powering it off doesn't succeed always.
> It sits
> with a message on the fb console, saying "Please power off this system".
> Occasionally, it does restart correctly, however.
Hrm. That's a real bug that I haven't seen in more recent 2.6 kernels
when testing on j6k or c3600.
> The sticon video support ONLY works on the EG graphics card if you have
> selected the 1024x768 mode from the HP firmware beforehand
Not exactly true. I've used mine at both 1600x1200 and 1280x1024.
The trick is to tell X11 to only use one mode which has to match
what the data reported by "fbset -i". fbset basically reports what
one selected at powerup time.
> - the default
> 1280x1024 (I think) sticon mode means the linux display output is purple,
> screwed up, and pushed over to the left, and therefore unusable.
>
> The 2.6.8-2-32-smp kernel doesn't boot properly on the FX6 graphics card
> based systems - even with video=sticon on the kernel command line, it
> appears to freeze shortly after saying "sym1: No NVRAM". I may try to
> debug further via the serial console to see if it really does hang,
> or just that the sticon output ceases at that point.
> Is there any way to make these FX6 cards work
> properly in console mode? I don't care about X.
I would expect STICON to "just work". This sounds like a real bug.
> I'm also having two minor issues with the FWSCSI drives.
>
> 1) Performance didn't seem too good. dd'ing from one drive to another (9.1GB
> 10K RPM drives) took 1699 seconds according to time, with dd reporting a rate
> of 5355740 bytes/sec. Is that normal?
No. 5MB/s is async/minimum data rate. Expect 20-40MB/s transfer rate between
two disks on the same SCSI bus depending on platform. There have been issues
with the SDTR negotiations and recently some minor confusion about when
PPR negotiation can be used.
I have also seen U320 drives that report incorrect values for SDTR
negotiation and correct values when using PPR negotiation. So I can't
rule out a driver firmware bug in your case either. You want to visit
the HP support center and look up the latest available firmware for
the drives you have.
> I was itching for a 'hdparm -d1' equivalent for scsi!
"lsscsi" is the next best thing.
The maintainer is looking into displaying data available from:
grundler <505>cat /sys/class/spi_transport/target1\:0\:15/*
cat: /sys/class/spi_transport/target1:0:15/device: Is a directory
0
0
15
50
0
cat: /sys/class/spi_transport/target1:0:15/revalidate: Permission denied
1
in a more human readable form. IIRC, then "echo newval > /sys/.../period" and
"echo 1 > /sys/.../revalidate" should cause a new negotiation to occur.
> 2) I can hotswap in a new drive, using scsiadd -a, and it's detected, and
> mountable fine. Using scsiadd -r, I can 'remove' it, but once it's
> physically removed and reinserted in the same slot, scsiadd -a doesn't 'see'
> it any more.
Known bug still open against the current release. Our valiant sym2 driver
maintainer has the right HW at home to test this and I trust will someday
squash this bug. He's been working on syncing the parisc-linux.org source
tree with linus' tree and been quite successful.
> If I put it in a different unused slot, and scsiadd -a it, it's
> then detected fine. So, it seems I cannot use a hotswap bay more than once!
Ah...I don't think I tried that when I reported the bug.
But that's good to know since it will narrow down where the
problem might be.
> Sorry for the long email, but I thought I'd mention all my issues in one go.
no problem - thanks again!
Note that it's usually better to report kernel bugs (e.g. SCSI driver
issues) to parisc-linux@lists.parisc-linux.org mailing list.
We've sort of divied the debian-hppa into userspace and the parisc-linux
list into kernel stuff - not mutually exclusive of course.
> Overall, I'm fairly pleased with the results of my install, but a couple of
> the above issues I'd love to be able to resolve.
>
> If there is any additional debug information/steps/testing you'd like me to
> do, please ask. I currently have 5 J5000s, so am in a position to play with
> them a bit!
awesome...sym2 maintainer may contact you to help test changes!
thanks,
grant
Reply to: