PR: 4486
Submitted by: tegge@idi.ntnu.no (Tor Egge)
Implement a function is_adapter_memory() in order to determine what
should nto be dumped at all. Currently, only populated with the ``ISA
memory hole''. Adapter regions of other busses should be added.
Change sd_open, sd_close and sd_ioctl to use this lock to ensure
serialization of some critical operations, thus avoiding some
race conditions. Ideas picked from NetBSD (ccd and sd devices).
This fixes one of the problems noted in PR kern/3688.
Reviewed by: "Justin T. Gibbs" <gibbs@plutotech.com>
These commands are required for the "Disk-At-Once" write process:
WORMIOCREADSESSIONINFO returns the length of the lead-in and lead-out areas
and WORMIOCWRITESESSION is used to send the table of contents of the disk.
PR: kern/3629: /sys/scsi/pt.c doesn't...
Submitted by: simokawa@sat.t.u-tokyo.ac.jp (Hidetoshi Shimokawa)
Add a catch-all record for removable SCSI devices to default them to
only one LUN.
PR: kern/3580: Bad LUN probes on Xyratex...
- remove all calls to scsi_stop_unit(). Some drives refuse commands when
stopped. This will fix the 'device not configured' message which was
cleared after opening/closing the tray.
- Never set the logical block address in the scsi_cmd struct when writing.
The computation was bogus for block sizes not a multiple of DEV_BSIZE.
(the bug is still there in the READ case)
- reset the block size to the 2048 bytes in finalize_track() track to avoid
an error when mounting a disk after an audio write.
- remove the WORMIOCQUIRKSELECT ioctl. Quirks are now recorded at probe time
(see scsiconf.c)
- change and expand the argument to the WORMIOCPREPTRACK ioctl. It now possible
to select more track options (copy bits, ISRC codes, track type,
track number)
- add an error handler to catch false errors (warnings in fact) and record
the error type.
- add an ioctl call (WORMIOERROR) to get more information on the nature of the
error when a command or a write failed.
- add an ioctl call (WORMIOCFINISHTRACK) to finalize a track without closing
the device (closing the device still finalize the track if the command was
not performed)
Approved by: joerg
the work is silly, and all this will be a moot point with Justin's CAM
driver, and there are still many ioctls missing -- but i need these
right now. It's silly to need to move the CD-R back to the other
drive in order to determine the session start info when burning multi-
session CD-Rs.
. It makes cd9660 root f/s working again.
. It makes CD9660 a new-style option.
. It adds support to mount an ISO9660 multi-session CD-ROM as the root
filesystem (the last session actually, but that's what is expected
behaviour).
Sigh. The CDIOREADTOCENTRYS did a copyout() of its own, and thus has
been unusable for me for this work. Too bad it didn't simply stuff
the max 100 entries into the struct ioc_read_toc_entry, but relied on
a user supplied data buffer instead. :-( I now had to reinvent the
wheel, and created a CDIOREADTOCENTRY ioctl command that can be used
in a kernel context.
While doing this, i noticed the following bogosities in existing CD-ROM
drivers:
wcd: This driver is likely to be totally bogus when someone tries
two succeeding CDIOREADTOCENTRYS (or now CDIOREADTOCENTRY)
commands with requesting MSF format, since it apparently
operates on an internal table.
scd: This driver apparently returns just a single TOC entry only for
the CDIOREADTOCENTRYS command.
I have only been able to test the CDIOREADTOCENTRY command with the
cd(4) driver. I hereby request the respective maintainers of the
other CD-ROM drivers to verify my code for their driver. When it
comes to merging this CD-ROM multisession stuff into RELENG_2_2 i will
only consider drivers where i've got a confirmation that it actually
works.
I got tired of not seeing my worm stats show up during a burn. :)
[Joerg, I just stapled in 1MB/sec for a bogus xfer rate and left seek = 1,
as suggested - I'm not going to dynamically calculate the xfer rate from
a known device spectable, OK? :-)]
Reviewed by: joerg
caller is scsi_done which the controller interrupt handlers call. In the
case of a non-buffer based transaction, the xs structure is freed by the
process that initiated the transfer in scsi_scsi_cmd. In this case, an
explicit splbio/splx pair around the call to free_xs is required. Without
the splbio protection, the xs free list could be corrupted, and the type
driver's start routine might run without spl protection.
Submitted by: Tor Egge <Tor.Egge@idt.ntnu.no>
Obtained from: PR kern/2891
and fixed everything that depended on getting it from the wrong
place. Most of the broken things actually only depended on getting
the declaration of their interrupt handler from "ioconf.h".
Many things have been changing in the kernel since mid-1996, so there's
quite some amount of diffs here already. It compiles, but i cannot
test it anywhere here.
2.2 candidate?
Closes PR # 1201.
changes, so don't expect to be able to run the kernel as-is (very well)
without the appropriate Lite/2 userland changes.
The system boots and can mount UFS filesystems.
Untested: ext2fs, msdosfs, NFS
Known problems: Incorrect Berkeley ID strings in some files.
Mount_std mounts will not work until the getfsent
library routine is changed.
Reviewed by: various people
Submitted by: Jeffery Hsu <hsu@freebsd.org>
from last time. Some people have pointed out that there were some odd
side-effects in the changes I made. Two things are different:
- sc_print_addr() will print 'foodev0:' (i.e. sd0:, st0:, cd0:, etc...)
if the device name is known. If it's not known, it'll use a longer
notation. This shortens error messages back to a sane length.
- Added a small function called sc_print_init() to set the sc_printing
flag so that sc_print_addr() will know that we want it to print a
linefeed. Used this in scsi_device_attach() to restore proper carriage
return printing behavior which I broke.
Remaining bogons: the NCR SCSI driver prints out information while the
device-specific attach routine is running with its own linefeeds. This
breaks up the individual messages emitted by the subdriver modules and
causes at least one message to appear on a line by itself without a
device spec prefix. I'm not sure of the correct way to fix this, and
I don't have any NCR SCSI hardware to test with anyway.
There's probably more, but I gather that a rewrite of the SCSI subsystem
is pending anyway, so I'll leave the rest to Those Who Know More About
This Than I (tm).
