summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci/arc.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* adapt to new two-level sensor api; Constantine A. Mureninderaadt2006-12-231-6/+8
|
* always include sensors.hderaadt2006-12-221-2/+2
|
* give scsi controllers a real attach args to fill in when attaching scsibus.dlg2006-11-281-2/+6
| | | | ok miod@ marco@ deraadt@
* query the firmware for the number of volumes, and then iterate through themdlg2006-11-041-28/+41
| | | | to get the right names for sensor creation.
* dont walk the device list looking for our scsibus, it is stashed when wedlg2006-11-011-17/+3
| | | | attach it.
* whitespace fixesdlg2006-11-011-13/+13
|
* first cut at sensorsjolan2006-10-311-2/+116
| | | | help from & ok dlg@
* well, this is embarrassing.dlg2006-09-251-1/+22
| | | | | | | | | | | | it turns out a drivers detach code isnt called when the machine is shutting down, which meant my bits to stop bgrb and sync the cache werent being run. without those bits being run the filesystems on these controllers were never clean on reboot, so we'd always get an fsck. so now we provide a shutdown hook which does get run on shutdown to sync the cache properly. found by claudio@
* enabling interrupts isnt a bug, so dont put XXX next to it.dlg2006-09-251-4/+5
| | | | | only ack the interrupts we deal with in the interrupt handler. use the correct macros when setting the interrupt mask.
* move the firmware messaging under NBIO since it's only used by bio.dlg2006-08-281-3/+4
|
* turns out the volume info contains a bitmap of failed physdisks in it, sodlg2006-08-281-33/+7
| | | | | | i can just check if this is non zero to see if a volume is degraded. this means i dont have to pull the raid info page to find failed disks in the volume inquiry.
* sigh, this is annoying. it appears that the arc firmware doesnt care if adlg2006-08-271-3/+35
| | | | | | | | volume is degraded, just if it is working or not. if a volume is degraded, its still online, so we have to go look for missing disks. if a disk has been replaced, but it is yet to be rebuilt, the firmware kindly tells us that it needs rebuilding. we can figure out if a volume is degraded using these two facts.
* try to get the status of the volume out of the arc firmware and intodlg2006-08-271-12/+32
| | | | | | | bioctl output. this is actually a bit of a struggle since the firmware doesnt represent these states well at all. im only showing the obvious ones: online, init, rebuild, and offline. i have no idea how they tell if a volume is degraded.
* if a disk dissapears out of a raidset, then the raid info will list its iddlg2006-08-271-1/+14
| | | | | | as 0xff, and the command to query that phys disk will fail and cause the ioctl to get stuck. so if the disk id is 0xff, fake an offline disk on another bus since bioctl doesnt know how to show that properly.
* little nitdlg2006-08-271-2/+2
|
* fill in the controllers name in the inq ioctl. spotted by deraadt@dlg2006-08-251-1/+2
|
* show the firmware revision of the disks.dlg2006-08-241-6/+12
|
* report the size of the disks and volumes correctly.dlg2006-08-241-4/+4
|
* too much copy and paste. report raid 1 correctly.dlg2006-08-241-2/+2
|
* ignore passthru volumes, struct bioc_vol isnt smart enough to know whatdlg2006-08-241-5/+9
| | | | they are.
* figure out the raid level of the volume.dlg2006-08-241-2/+30
|
* oops, im unlocking too oftendlg2006-08-241-2/+1
|
* a start at the BIOC INQ, VOL, and DISK ioctls for fetching informationdlg2006-08-241-1/+244
| | | | | | | about the disks that are configured on the controller. so far this fetches the right volumes and disks in each volume, but doesnt properly fill in the status, the size of both the volumes and disks, the type of raid, or the firmware version of the physical disks.
* stash a pointer to the scsibus attached to us. we can use this later todlg2006-08-201-2/+6
| | | | find the names of our volumes.
* definitions of the messages for raid, volume, and physical disksdlg2006-08-201-1/+65
|
* get rid of the horror that was the ARC_FW_MSG macrodlg2006-08-201-11/+1
|
* get rid of the old arc_msgbuf.dlg2006-08-201-109/+8
|
* cut the rest of the bioctl alarm stuff over to the new arc_msgbufdlg2006-08-201-24/+10
|
* because the header on firmware commands causes the rest of the message todlg2006-08-201-21/+169
| | | | | | | | | | | | be unaligned we basically need to bounce the contents of the message in and out of what is submitted to the hardware. rather than have the callers of arc_msgbuf do that, make arc_msgbuf do it for them. while we're here, make arc_msgbuf do the checksumming and length checks so the callers dont have to do that either. this adds an alternative to arc_msgbuf that does the new functionality and cuts arc_bio_alarm_state over to using it. i'll cut the other users of arc_msgbuf over shortly and remove the old implementation.
* oops, debug cruft shouldnt go into the tree.dlg2006-08-181-4/+1
|
* add the sysinfo struct, and then use it to get the current state of thedlg2006-08-181-3/+100
| | | | alarm.
* easy bio bits first. this is is code that should enable, disable, anddlg2006-08-181-2/+72
| | | | | silence the alarm. the hardware can also report the state of the alarm, but its embedded in a really large message im not 100% sure about yet.
* arc, meet bio. bio, meet arc.dlg2006-08-181-1/+26
|
* fix up the arc fw message macros a bit. change a comment while here.dlg2006-08-181-6/+10
|
* a bit more infrastructure for firmware commands.dlg2006-08-181-1/+41
|
* dont need debug in the treedlg2006-08-171-4/+5
|
* man, i wish firmware commands were as easy as scsi io's on thesedlg2006-08-171-4/+154
| | | | | controllers. this is horrible code that is set up to allow a process, (eg and ioctl or the sensor thread) to issue a command and get a response.
* when there's normal sense data i think the command completed ok, there'sdlg2006-08-151-1/+2
| | | | just extra data. say there's no residual if that's the case.
* try to deal appropriate with errors from the io command replydlg2006-08-151-7/+32
|
* start and stop bgrb during attach and detach respectively. as a bonusdlg2006-08-141-5/+32
| | | | | flush the hbas cache on detach as well. writes on my raid5 seem to run fast now.
* firmware commands (as opposed to io commands) are sent to the firmware viadlg2006-08-141-5/+11
| | | | | | | | | | | | | | | | the IOC_WBUF area in bus_space, and replies to it are read from the IOC_RBUF area. the freebsd and linux drivers define these areas to be 32 dwords in length, but it then goes and casts these spaces to a struct that has a 4 byte word at the start with the length of the message in it, followed by a 124 byte buffer which is filled with the actual message in it. rather than screwing around with an extra struct and casts, we can define this header as a register of its own, and the buffer as a separate region in bus_space. this simplifies command submission and the retrieval of the replies (which is yet to be written properly).
* define the size of regions in the register space in terms of bytes, notdlg2006-08-091-4/+4
| | | | dwords
* whitespace fixesdlg2006-08-071-3/+3
|
* from the drivers side of the iop331 there is only one set of interruptdlg2006-08-071-44/+28
| | | | | | registers to deal with, the other set are used on the firmware side of the device. shrink a bit by removing the definitions of the firmwares registers.
* endian fixes. this works on sparc64 now.dlg2006-08-061-3/+3
|
* fill out the interrupt handler. io is now no longer polled, and as a bonusdlg2006-08-061-8/+27
| | | | it's fairly fast :)
* we can support more than one entry in an sgl, so stop lying to bus_dmadlg2006-08-061-3/+3
|
* less magicdlg2006-08-061-9/+4
|
* io commands are the only ones every posted on the queues, so hardcode thedlg2006-08-061-26/+29
| | | | | type into the ccb rather than use void *s and insane casting to get at bits of the command.
* implement reply and post queue handling, but only polled for now. io shoulddlg2006-08-051-25/+134
| | | | work with this, but i cant test without disks.
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.