Bug 105607 - [modules] modules on sparc64 don't work with >= 4GB
Summary: [modules] modules on sparc64 don't work with >= 4GB
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: sparc64 (show other bugs)
Version: 6.2-BETA2
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-sparc64 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-16 16:10 UTC by Aled Morris
Modified: 2008-09-08 23:29 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aled Morris 2006-11-16 16:10:01 UTC
This problem existed in 6.1-RELEASE also.

Tried loading the IPFW module and it causes an immediate panic:

(on serial console)
# kldload ipfw
panic: trap: fast data access mmu miss
cpuid = 0
Uptime: 9m7s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort


system is 420R with 2x450MHz UltraSPARC-II processors, 4GB RAM

I can make this system available on the Internet with remote serial console if anyone wants to try it.

Fix: 

none
How-To-Repeat: kldload ipfw
Comment 1 Kris Kennaway 2006-11-16 16:12:12 UTC
Do you have 4GB or >4GB?  Modules do not work on sparc systems with
more than 4GB, but I thought 4 was OK.  You can confirm by

a) making sure your modules are in sync with your kernel (i.e. not
compiled from different sources)

b) Trying some other modules to see if they work too.

Kris
Comment 2 Aled Morris 2006-11-16 16:25:08 UTC
On 16 Nov 2006, at 16:12, Kris Kennaway wrote:

> Do you have 4GB or >4GB?  Modules do not work on sparc systems with
> more than 4GB, but I thought 4 was OK.  You can confirm by
>
> a) making sure your modules are in sync with your kernel (i.e. not
> compiled from different sources)
>
> b) Trying some other modules to see if they work too.


(a) The system is a clean install from the ISO image, GENERIC kernel  
etc. straight off the CD.

Here's the boot message:

Sun Enterprise 420R (2 X UltraSPARC-II 450MHz), No Keyboard
OpenBoot 3.23, 4096 MB memory installed, Serial #15737032.
Ethernet address 8:0:20:f0:20:c8, Host ID: 80f020c8.

(b) I just tried a couple of other modules (sound, fdc) and they  
cause the same panic.  doh!

so my labelling this as a IPFW problem wasn't quite right.

I'll try a new kernel build.

Thanks for your help.

Aled
Comment 3 Aled Morris 2006-11-16 20:38:26 UTC
I tried.  The problem is in loading kernel modules.  Panic every time.

IPFW compiled-in to the kernel works fine.

Now what do I do?  submit a new PR for the KLD problem?

Cheers,

Aled
Comment 4 Kris Kennaway 2006-11-16 20:48:05 UTC
No, it's not really a bug, but a design limitation in the way things
are compiled on sparc.

Kris
Comment 5 Aled Morris 2006-11-16 22:03:07 UTC
KLD isn't expected to work on sparc64?

There should be a note about this in the release notes or on the website 
or something (maybe I missed it?)

Aled
Comment 6 Kris Kennaway 2006-11-16 23:01:03 UTC
> KLD isn't expected to work on sparc64?

As I said, not if you have too much memory.  Apparently =4GB is
already too much, but lesser amounts do work.

> There should be a note about this in the release notes or on the website 
> or something (maybe I missed it?)

Not sure if/where it's documented, so yeah, maybe it could be more
prominent.

Kris
Comment 7 Marius Strobl freebsd_committer freebsd_triage 2008-05-08 21:52:02 UTC
State Changed
From-To: open->feedback


This should be fixed in FreeBSD 7.0 and later. Could you please 
confirm?
Comment 8 Florian Smeets 2008-09-08 21:24:53 UTC
This pr can indeed be closed.

real memory  = 6442450944 (6144 MB)
avail memory = 6286655488 (5995 MB)

flo@280r:~ 17 > kldstat
Id Refs Address            Size     Name
  1    3 0xc0000000 58f4a0   kernel (/boot/kernel/kernel)
  2    1 0xc0590000 139ab0   geom_mirror.ko (/boot/kernel/geom_mirror.ko)

This is 8-CURRENT btw.

Cheers,
Florian
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2008-09-08 23:29:19 UTC
State Changed
From-To: feedback->closed

Confirmed fixed in 7.0 and later.  Thanks for the response.