History log of /freebsd/sys/cam/cam_periph.c (Results 401 – 412 of 412)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 5a526431 19-Apr-1999 Justin T. Gibbs <gibbs@FreeBSD.org>

cam_periph.c:
Move handling of CAM_AUTOSENSE_FAIL into block dealing with
all other scsi status errors.

cam_queue.c:
cam_queue.h:
Fix 'off by one' heap bug in a more efficient manner. Since
hea

cam_periph.c:
Move handling of CAM_AUTOSENSE_FAIL into block dealing with
all other scsi status errors.

cam_queue.c:
cam_queue.h:
Fix 'off by one' heap bug in a more efficient manner. Since
heap algorithms like to deal with indexes started from 1,
offset our heap array pointer at allocation time to make this
so for a C environment. This makes the implementation of the
algorithm a bit more efficient.

cam_xpt.c:
Use macros for accessing the head of the heap so that code
is isolated from implementation details of the heap.

show more ...


# 0cbbb7bf 06-Apr-1999 Peter Wemm <peter@FreeBSD.org>

Use PHOLD/PRELE rather than P_PHYSIO.


Revision tags: release/3.1.0
# 1c7c3c6a 21-Jan-1999 Matthew Dillon <dillon@FreeBSD.org>

This is a rather large commit that encompasses the new swapper,
changes to the VM system to support the new swapper, VM bug
fixes, several VM optimizations, and some additional revamping of t

This is a rather large commit that encompasses the new swapper,
changes to the VM system to support the new swapper, VM bug
fixes, several VM optimizations, and some additional revamping of the
VM code. The specific bug fixes will be documented with additional
forced commits. This commit is somewhat rough in regards to code
cleanup issues.

Reviewed by: "John S. Dyson" <root@dyson.iquest.net>, "David Greenman" <dg@root.com>

show more ...


Revision tags: release/3.0.0, release/2.2.8
# 0ec81012 14-Jan-1999 John Polstra <jdp@FreeBSD.org>

Replace includes of <sys/kernel.h> with includes of
<sys/linker_set.h> in those files that use only the linker set
definitions.


# ff1fe75f 16-Dec-1998 Kenneth D. Merry <ken@FreeBSD.org>

At Justin's request, limit the size of buffers that can be mapped into
and out of kernel address space (via the pass(4) and xpt(4) peripheral
drivers) to 64K (DFLTPHYS). Some controllers, like the A

At Justin's request, limit the size of buffers that can be mapped into
and out of kernel address space (via the pass(4) and xpt(4) peripheral
drivers) to 64K (DFLTPHYS). Some controllers, like the Adaptec 1542,
don't support more than 64K transactions.

We plan on eventually having the capability of limiting this size based
on min(MAXPHYS, controller max), but since that capability isn't here yet,
limit things to the lowest common denominator.

show more ...


# 79d49a06 16-Dec-1998 Kenneth D. Merry <ken@FreeBSD.org>

Probable fix for the "cdda2wav" panics that various people have been
reporting since this past summer. (I think Daniel O'Conner was the first.)

The problem appears to have been something like this:

Probable fix for the "cdda2wav" panics that various people have been
reporting since this past summer. (I think Daniel O'Conner was the first.)

The problem appears to have been something like this:

- cdda2wav by default passes in a buffer that is close to the 128K MAXPHYS
limit.
- many times, the buffer is not page aligned
- vmapbuf() truncates the address, so that it is page aligned
- that causes the total size of the buffer to be greater than MAXPHYS,
which of course is a bad thing.

Here's a quote from the PR (kern/9067):

==================
In particular, note bp->b_bufsize = 0x0001f950 and bp->b_data = 0xf2219960
(which does not start on a page boundary). vunmapbuf() loops through all
the pages without any difficulty until addr reaches 0xf2239000, and then
the panic occurs. This seems to indicate that we are exceeding MAXPHYS
since we actually started from the middle of a page (the data is being
transfered to a non page aligned location).

To complete the description, note that the system call originates from
ReadCddaMMC12() (in scsi_cmds.c of cdda2wav) with a request to read 55
audio sectors of 2352 bytes (which is calculated to fall under MAXPHYS).
This in turn ends up calling scsi_send() (in scsi-bsd.c) which calls
cam_fill_csio() and cam_send_ccb(). This results in a CAMIOCOMMAND ioctl
with a ccb function code of XPT_SCSI_IO.
==================

The fix is to change the size check in cam_periph_mapmem() so that it is
like the one in minphys(). In particular, it is something like:

if ((buffer_length + (buf_ptr & PAGE_MASK)) > MAXPHYS)
buffer is too big

My fix is based on the one in the PR, but I cleaned up a fair number of
things in cam_periph_mapmem(). The checks for each buffer to be mapped
are now in a separate loop from the actual mapping operation. With the new
arrangement, we don't have to bother with unmapping any previously mapped
buffers if one of the checks fails.

Many thanks to James Liu for tracking this down. I'd appreciate it if some
vm-savvy folks would look this over. I believe this fix is correct, but I
could be wrong.

PR: kern/9067 (also, kern/8112)
Reviewed by: gibbs
Submitted by: "James T. Liu" <jtliu@phlebas.rockefeller.edu>

show more ...


# ee9c90c7 23-Oct-1998 Kenneth D. Merry <ken@FreeBSD.org>

Fix a problem with the way we handled device invalidation when attaching
to a device failed.

In theory, the same steps that happen when we get an AC_LOST_DEVICE async
notification should have been t

Fix a problem with the way we handled device invalidation when attaching
to a device failed.

In theory, the same steps that happen when we get an AC_LOST_DEVICE async
notification should have been taken when a driver fails to attach. In
practice, that wasn't the case.

This only affected the da, cd and ch drivers, but the fix affects all
peripheral drivers.

There were several possible problems:
- In the da driver, we didn't remove the peripheral's softc from the da
driver's linked list of softcs. Once the peripheral and softc got
removed, we'd get a kernel panic the next time the timeout routine
called dasendorderedtag().
- In the da, cd and possibly ch drivers, we didn't remove the
peripheral's devstat structure from the devstat queue. Once the
peripheral and softc were removed, this could cause a panic if anyone
tried to access device statistics. (one component of the linked list
wouldn't exist anymore)
- In the cd driver, we didn't take the peripheral off the changer run
queue if it was scheduled to run. In practice, it's highly unlikely,
and maybe impossible that the peripheral would have been on the
changer run queue at that stage of the probe process.

The fix is:
- Add a new peripheral callback function (the "oninvalidate" function)
that is called the first time cam_periph_invalidate() is called for a
peripheral.

- Create new foooninvalidate() routines for each peripheral driver. This
routine is always called at splsoftcam(), and contains all the stuff
that used to be in the AC_LOST_DEVICE case of the async callback
handler.

- Move the devstat cleanup call to the destructor/cleanup routines, since
some of the drivers do I/O in their close routines.

- Make sure that when we're flushing the buffer queue, we traverse it at
splbio().

- Add a check for the invalid flag in the pt driver's open routine.

Reviewed by: gibbs

show more ...


# 11021a1a 15-Oct-1998 Kenneth D. Merry <ken@FreeBSD.org>

Clean up some unused variables.

Reviewed by: ken
Submitted by: phk


# 60a899a0 13-Oct-1998 Kenneth D. Merry <ken@FreeBSD.org>

Fix a bug in the error recovery code. It was possible to have more than
one error recovery action oustanding for a given peripheral.

This is bad for several reasons. The first problem is that the

Fix a bug in the error recovery code. It was possible to have more than
one error recovery action oustanding for a given peripheral.

This is bad for several reasons. The first problem is that the error
recovery actions would likely be to fix the same problem. (e.g., we
queue 5 CCBs to a disk, and the first one comes back with 0x04,0x02. We
start error recovery, and the second one comes back with the same status.
Then the third one comes back, and so on. Each one causes the drive to get
nailed with a start unit, when we really only need one.)

The other problem is that we only have space to store one CCB while we're
doing error recovery. The subsequent error recovery actions that got
started were over-writing the CCBs from previous error recovery actions,
but we still tried to call the done routine N times for N error recovery
actions. Each call to dadone() was done with the same CCB, though. So on
the second one, we got a "biodone: buffer not busy" panic, since the buffer
in question had already been through biodone().

In any case, this fixes things so that any any given time, there's only one
error recovery action outstanding for any given peripheral driver.

Reviewed by: gibbs
Reported by: Philippe Regnauld <regnauld@deepo.prosa.dk>
[ Philippe wins the "bug finder of the week" award ]

show more ...


# 2e8bf209 29-Sep-1998 Bruce Evans <bde@FreeBSD.org>

Fixed printf format errors. u_long is not necessarily suitable for casting
pointers to, and %d is not suitable for printing uint32_t's.


# e471e974 20-Sep-1998 Justin T. Gibbs <gibbs@FreeBSD.org>

cam_xpt.c:
Add quirk entry for a Samsung drive that doesn't like experiencing
the queue full condition.

Bump the timeouts for all probe activities to 60s. We don't know
what the seletion timeou

cam_xpt.c:
Add quirk entry for a Samsung drive that doesn't like experiencing
the queue full condition.

Bump the timeouts for all probe activities to 60s. We don't know
what the seletion timeout (or equivelent on other mediums) is
for controllers, which can make the transactions at the tail
end of a parallel probe take a while to complete. The DPT
seems to be a card that takes a long time to see a selection timeout.

cam_periph.c:
Don't call a device "gone" after a single selection timeout. We
need to come up with a better policy. Until that time, you'll
have to manually re-scan a bus via camcontrol for the system to
decide that a device is really gone. This should give devices
experiencing temporary insanity to escape death.

show more ...


# 8b8a9b1d 15-Sep-1998 Justin T. Gibbs <gibbs@FreeBSD.org>

CAM Transport Layer (XPT).

Submitted by: The CAM Team


1...<<11121314151617