don't matter in usespace.
Update list of intel family 6 model names (all current cpus) to include
everything upto and including sandy bridge and ivy bridge.
My i7 is no longer reported as a random P II.
family' and 'extended model' bits are used to create larger values
than the original 16bit value allowed for.
Calculate and save these values 'up-front' and use them throughout.
Untangle the (backwards) nested switch statement for amd 'model 15' cpus.
Works as badly as ever on my i7.
Based on 4.4BSD-Lite2/luna68k "Stinger" loader revision "Phase-31"
http://svnweb.freebsd.org/csrg/sys/luna68k/stand/
and MI libsa glue stuff are taken from hp300 etc.
Tested on LUNA-I and old DK315C SCSI disk drive.
LUNA's monitor PROM can load only an a.out binary in 4.3BSD FFS partition
(i.e. created by "newfs -O 0") on disks with OMRON's UniOS disklabel,
but now we can load an ELF kernel in root partition via this bootloader.
(See luna68k/disksubr.c for details of UniOS label)
TODO:
- LUNA-II support (check 68040 to adjust cpuspeed for DELAY())
- secondary SCSI support for LUNA-II
- netboot via le(4) (should be trivial)
- support boot options on bootloader prompt
- bootinfo (passing info about booted device and kernel symbols)
- support "press return to boot now, any other key for boot menu" method
like x86 bootloader (needs cnscan() like functions)
- tapeboot (anyone wants it?)
The problem was that ipf_nat_delete wasn't swapping inbound and
outbound hash codes for inbound NAT entries, so it was essentially
always looking in the wrong buckets in those cases. But because of
the way the linked list works, I don't think any NAT entries were
actually leaked. But since all the bucket counters and chain count
were getting messed up, things did start to go bad after a while.
(New NAT entries wouldn't be created, for instance.)
The fix is in the ipf_nat_delete function, itself; the other changes
are a slight refactoring of one method and adding some comments
that helped me figure out how the linked list with pointer-back-pointers
worked.
Also note that I haven't looked through the logic in ipf_nat_rehash;
it's likely that that might miss some things for the same reason.
I also haven't yet looked into the ipf_nat_newrdr problem with mappings
already existing. That'll be next.
into global data.
Fix a stack alignment fubar that would cause a crash on a cirix 486.
Refactor identify code to common setup for normal identify and ucode
identify - which was missing a memset().
jmcneill