that I have. Wait up to 1.1s for the card to become ready. Document
what the standards say, and use that to justify the behavior in the
code: PCI standard says that a card must respond to configuration
cycles within 2^25 cycles after reset goes high, which is
approximately 1s. Therefore, give cards a little break and wait for
up to 1.1s for VENDOR to become valid. Only look at the vendor part
of the ID, since only it can't be 0xffff (although in practice
vendor/device will always be != 0xfffffffff). Include detailed
pointers to standards so epople understand why we're doing what we're
doing and why it just might be OK. Make it clear in the timeout
message that it is just a warning, sinc we try to soldier on as best
we can anyway.
This should eliminate an error message that r181453 produced on
certain Atheros cards.
more mappings to the same physical page have different memory types, i.e.,
PAT settings. Consequently, if pmap_change_attr() is applied to a virtual
address range within the kernel map, then the corresponding ranges of the
direct map also need to be changed. Enhance pmap_change_attr() to handle
this case automatically.
Add a comment describing what pmap_change_attr() does.
Discussed with: jhb
and also holds things up, check every 20ms to see if we can read the
vendor of device 0.0. It will be 0xffffffff until the card is out of
reset. Always wait at least 20ms, for safety.
I think this is a better fix to the reset problem. However, I did it
as a separate commit in case something bad happens, people can roll
back to the commit before this one to see if that gives them reliable
behavior. I don't have FreeBSD up on enough machines to do exhaustive
testing on all known bridges...
some bridge + card combinations that take longer for reasons unknown.
Adjust the timeout to be 100ms on all !RICOH bridges, but leave RICOH
at 400ms. The 400ms is "lore" from other open source projects, and
I've never see my ricoh bridge chips take this long. Maybe it is the
same thing? Maybe a bit should be read instead of a hard-wired pause?
After this adjustment, a few cards that I'd insert and get only:
cbb0: card_power: 3V
cbb0: card_power: 0V
with full debugging enabled would actually try to attach.
Reported by: sam@ (I think)
MFC after: 3 days
set the %eflags used during a BIOS call via BTX to 0x202. Previously
the flags field was uninitialized garbage, and thus it was "random" if
interrupts were enabled or not during BIOS calls.
- Use constants from <machine/psl.h> for fields in %eflags.
MFC after: 3 days
- I had errantly assumed that all user requests should run with interrupts
enabled. User requests for software interrupts, however, need to disable
interrupts (and tracing) just like hardware interrupts.
- Disable alignment checking when emulating a hardware interrupt as well
(based on the description of the real mode operation of the 'INT'
instruction in the IA-32 manuals).
- Use constants for fields in %eflags.
Tested by: bz
MFC after: 3 days
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.
The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.
The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.
The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.
Currently only Intel and AMD cpus are supported and were tested.
Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
There is no need to mark this device node to use Giant. The only
architectures that use io(4) (i386 and amd64) only change a flag in
td->td_frame, which is only accessed by curthread.
Apart from this change, I think some fishy things may happen when using
/dev/io in multithreaded applications. I haven't tested, but looking at
the code, the flag doesn't get cleared when close() is called from
another thread, but this may not be this important.
I'm not removing D_NEEDGIANT from mem(4), because this driver isn't
Giant safe at all (it calls GIANT_REQUIRED).
non-matching index lines. This fixes a bug where bogus warnings would
be printed file has the wrong file flags AND has been updated by
FreeBSD Update.
Reported by: Royce Williams
- Fix dates in 2008/2009 for Africa/Mauritius.
- Leap second notification for the end of 2008.
Approved by: bde (mentor, implicit), des
MFC after: 1 week
- Mauritius will have a DST experiment between 2008-11-01 and 2009-03-31.
- Add/Fix historical data for C-Eur, the SovietZone, Germany,
Bahamas, San Luis.
- Add information about West Para (America/Santarem)
- America/Eirunepe and America/Rio_Branco go to UTC-4
Approved by: bde (mentor, implicit), des
MFC after: 1 week
- Mauritius will have a DST experiment between 2008-11-01 and 2009-03-31.
- Add/Fix historical data for C-Eur, the SovietZone, Germany,
Bahamas, San Luis.
- Add information about West Para (America/Santarem)
- America/Eirunepe and America/Rio_Branco go to UTC-4
Approved by: bde (mentor, implicit), des
- Africa/Morocco will have DST in 2008.
- Asia/Choibalsan should be GMT+08:00.
- Asia/Pakistan will have DST in 2008.
Also set all the svn:eol-style properties to native.
Approved by: bde (mentor, implicit), des
MFC after: 1 week
- Africa/Morocco will have DST in 2008.
- Asia/Choibalsan should be GMT+08:00.
- Asia/Pakistan will have DST in 2008.
Also set all the svn:eol-style properties to native.
Approved by: bde (mentor, implicit), des
Remove Theory, which isn't part of the zoneinfo module but came out
of /head/usr.sbin/zic (and isn't installed from there neither).
Approved by: bde (implicit)
MFC after: 1 week
Test case:
random -f some_small_file 10000
(in most cases must be no output)
2) Prevent number of lines > RANDOM_MAX (overflow or nothing may be
choosed) with EFBIG err()
3) After line is found, terminate list loop for -U case too,
since nothing to do in the rest of the loop left.
Remove Makefile, which isn't part of the distributed sources.
Remove Theory, which isn't part of the distributed source but came
out of /vendor/tzcode/.
Approved by: bde (mentor, implicit)
used in randomize_fd.c.
Although the max value is the same currently, RAND_MAX is for rand(),
not for random().
So move RANDOM_MAX const to the common file now, make it UL and
use in randomize_fd.c too.
(in any case its old value was 1 less then must be, as noted in
the prev. commit)
#pragma STDC CX_LIMITED_RANGE ON
the "ON" needs to be in caps. gcc doesn't understand this pragma
anyway and assumes it is always on in any case, but icc supports
it and cares about the case.
no particular reason for them to be implemented in assembler and
having them in C allows easier extension as well as using more C
macros and {d,i}tlb_slot_max rather than hard-coding magic (and
actually spitfire-only) values.
- Fix the compilation of pmap_print_tte().
- Change pmap_print_tlb() to use ldxa() rather than re-rolling it
inline as well as TLB_DAR_SLOT and {d,i}tlb_slot_max rather than
hardcoding magic (and actually spitfire-only) values.
- While at it, suffix the above mentioned functions with "_sun4u" to
underline they're architecture-specific.
- Use __FBSDID and macros instead of magic values in locore.S.
- Remove unused includes and smp_stack in locore.S.
msleep/mtx_sleep or the various cv_*wait*() routines. Currently, the
"unlock" behavior of PDROP and cv_wait_unlock() with Giant is not
permitted as it is will be confusing since Giant is fully unrecursed and
unlocked during a thread sleep.
This is handy for subsystems which wish to allow unlocked drivers to
continue to use Giant such as CAM, the new TTY layer, and the new USB
stack. CAM currently uses a hack that I told Scott to use because I
really didn't want to permit this behavior, and the TTY and USB patches
both have various patches to permit this.
MFC after: 2 weeks
NEC PC-9801N-J02 and PC-9801N-J02R. I can't test the former because
it requires resources that conflict with my laptop. I can't test the
latter because my dog chewed up my -J02R card and it didn't survive
well enough for me to test.
