Failure to do this will result in following ata_pio_read() calls walking
off the end of the read buffer.
This resolves the "memory modified after free" panics common with Thinkpads
and CD/DVD drives.
Submitted by: Nate Lawson <nate AT root.org>
idle the 'mask' variable could be set to 0, resulting in the timeout loop
running for the full 31 seconds.
Handling this case eliminates long hangs on resume on some systems.
Submitted by: Nate Lawson <nate AT root.org>
and the X1034A (quad HME; QFE) cards the X1033A (single HME) don't have a
PCI-PCI-bridge so we can't rely on the PCI slot number being useable as
index for the network address to read from the VPD on the latter. Use
the end tag to determine whether it is a QFE VPD with 4 NAs and only use
the slot number as index in this case.
- Remove a useless check.
Prodded by: joerg
Additional testing by: joerg
MFC after: 1 day
o usb_subr.c, add delta 1.119:
Move usb_get_string() and make it public.
o usbdi.c, bring on par with 1.106, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Whine about not being able to figure out default language if we are debugging.
- Move usb_get_string() and make it public.
o usbdi.h, bring on par with 1.64, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Move usb_get_string() and make it public.
o usbdi_util.c, bring on par with 1.42, this includes:
- Add usbd_get_protocol().
- Use NULL instead of 0.
- Fix (mostly harmless) typo.
- Move utility routine from uirda.c to usbdi_util.c.
o usbdi_util.h, bring on par with 1.31, this includes:
- Add usbd_get_protocol().
- Move utility routine from uirda.c to usbdi_util.c.
MFC after: 3 days
is particularly useful when VESA is available (either `options VESA'
or load the vesa module), as BIOSes in some notebooks may correctly
save and restore LCD panel settings using VESA in cases where calling
the video BIOS POST is not effective. On some systems it may also
be necessary to set the hw.acpi.reset_video sysctl to 0.
yet I only changed one of them. So when we loaded drivers, we'd fail
to allocate resources correct.
This pointed out that we were doing the wrong thing when we failed to
attach a child. We released all the resources and almost deleted the
child. Instead, we should keep the resources allocated so when/if a
driver is loaded, we can go w/o having to allocate them. We use
pci_cfg_save/restore to restore the BARs with these resources.
This seems to fix the problems that we were seeing that I thought
might have magically gone away in the last revision of cardbus.c (but
really didn't).
Noticed by: avatar (nicely done!)
testing it to know whether we should enable the 82503 serial mode...
Move code to the right location and disallow the use of the 82503
serial mode if the sc->revision field is 0 again. This makes fxp(4)
work correctly with ATMEL 350 93C46 cards (3 port 82559 based with a
82555 PHY), as well as with the older ATMEL 220 93C46 (same flavour)
and with the even older 10Mbps-only 82557 cards with the 82503 serial
interface.
Tested by: Andre Albsmeier <andrer@albsmeier.net>, krion
MFC after: 2 weeks
SMP systems. It appears all drivers except ichss should attach to each
CPU and that settings should be performed on each CPU. Add comments about
this. Also, add a guard for p4tcc's identify method being called more than
once.
uart(4) to support the Zilog 8530 SCCs which hang off of a FireHose
bus on Sun E4000/E5000 class machines.
Beside the fact that a puc_fhc.c would just be a copy of puc_sbus.c
with s,sbus,fhc,g the reason why the declaration for fhc(4) was
sticked into puc_sbus.c is that both of these front-ends for puc(4)
will go away once there is a scc(4).
Discussed with: marcel
Tested by: hrs, kris
MFC after: 3 days
both a scc(4) is under way and fhc(4) will be change to use INOs this
shouldn't stay in HEAD for too long but we need a MFC-able solution
for FreeBSD 5.4.
Discussed with: marcel
Tested by: hrs, kris
MFC after: 3 days
for a given device in some circumstances, so move the PDO creation
to the attach routine so we don't end up creating two PDOs.
Also, when we skip the call to ndis_convert_res() in if_ndis.c:ndis_attach(),
initialize sc->ndis_block->nmb_rlist to NULL. We don't explicitly zero
the miniport block, so this will make sure ndis_unload_driver() does
the right thing.
when we create a PDO, the driver_object associated with it is that
of the parent driver, not the driver we're trying to attach. For
example, if we attach a PCI device, the PDO we pass to the NdisAddDevice()
function should contain a pointer to fake_pci_driver, not to the NDIS
driver itself. For PCI or PCMCIA devices this doesn't matter because
the child never needs to talk to the parent bus driver, but for USB,
the child needs to be able to send IRPs to the parent USB bus driver, and
for that to work the parent USB bus driver has to be hung off the PDO.
This involves modifying windrv_lookup() so that we can search for
bus drivers by name, if necessary. Our fake bus drivers attach themselves
as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them
using those names.
The individual attachment stubs now create and attach PDOs to the
parent bus drivers instead of hanging them off the NDIS driver's
object, and in if_ndis.c, we now search for the correct driver
object depending on the bus type, and use that to find the correct PDO.
With this fix, I can get my sample USB ethernet driver to deliver
an IRP to my fake parent USB bus driver's dispatch routines.
- Add stub modules for USB support: subr_usbd.c, usbd_var.h and
if_ndis_usb.c. The subr_usbd.c module is hooked up the build
but currently doesn't do very much. It provides the stub USB
parent driver object and a dispatch routine for
IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at
the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub
compiles, but is not hooked up to the build yet. I'm putting
these here so I can keep them under source code control as I
flesh them out.
