Re: Allegations regarding OpenBSD IPSEC
On 12/23/2010 06:39 AM, Marsh Ray wrote: On 12/22/2010 03:49 PM, Clint Pachl wrote: Salvador Fandiqo wrote: Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, How is it different than any other installation file then? because it is accessible *before* any filesystem is mounted, from second 0 of the boot process. - Salva
Re: Allegations regarding OpenBSD IPSEC
Salvador Fandiqo wrote: On 12/23/2010 06:39 AM, Marsh Ray wrote: On 12/22/2010 03:49 PM, Clint Pachl wrote: Salvador Fandiqo wrote: Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, How is it different than any other installation file then? because it is accessible *before* any filesystem is mounted, from second 0 of the boot process. This reminds me of something. The last time I installed FreeBSD about 5 years ago, it asked me to pound on the keyboard for like 60 seconds during installation (or at first boot, can't remember) in order to build up some randomness. I wonder what kind of entropy that provided?
Re: Allegations regarding OpenBSD IPSEC
On 2010-12-23 09:44, Clint Pachl wrote: Salvador Fandiqo wrote: On 12/23/2010 06:39 AM, Marsh Ray wrote: On 12/22/2010 03:49 PM, Clint Pachl wrote: Salvador Fandiqo wrote: Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, How is it different than any other installation file then? because it is accessible *before* any filesystem is mounted, from second 0 of the boot process. This reminds me of something. The last time I installed FreeBSD about 5 years ago, it asked me to pound on the keyboard for like 60 seconds during installation (or at first boot, can't remember) in order to build up some randomness. I wonder what kind of entropy that provided? It was only the first time sshd starts to generate enough entropy for the ssh-key generation. http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/sshd?rev=1.14;content-type=text%2Fplain
Re: Allegations regarding OpenBSD IPSEC
On Thu, Dec 23, 2010 at 10:43:49AM +0100, olli hauer wrote: On 2010-12-23 09:44, Clint Pachl wrote: Salvador Fandiqo wrote: On 12/23/2010 06:39 AM, Marsh Ray wrote: On 12/22/2010 03:49 PM, Clint Pachl wrote: Salvador Fandiqo wrote: Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, How is it different than any other installation file then? because it is accessible *before* any filesystem is mounted, from second 0 of the boot process. This reminds me of something. The last time I installed FreeBSD about 5 years ago, it asked me to pound on the keyboard for like 60 seconds during installation (or at first boot, can't remember) in order to build up some randomness. I wonder what kind of entropy that provided? It was only the first time sshd starts to generate enough entropy for the ssh-key generation. http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/sshd?rev=1.14;content-type=text%2Fplain In our case, the aim is to use the entropy collected during install by the various entropy sources (tty, disk io, network io and more) to generate a random seed that's being saved to disk so the first real boot is able to stir the random pool with that and have enough entropy to generate good hostkeys. -Otto
Re: Allegations regarding OpenBSD's PRNG
On 12/22/2010 02:34 PM, Theo de Raadt wrote: Which is why I'm wondering what exactly, this 'multi-consumer' design feature is all about. Is it simply that more userland stuff is pinging the kernel at unpredictable times resulting in more timestamps feeding into the central entropy pool? It seems like you could accomplish that with any syscall. Or is there some other effect being claimed? Holy cow, you are dense. How to tell when someone wants to avoid certain questions... I am going to throw out estimates here because (a) it has been a long time since we tested, and (b) so much can vary machine to machine. Without a hardware RNG device, a typical i386 desktop machine can provide (based on interrupt sources) around 1800 bytes of base entropy to the MD5 thrasher -- per minute. Finally something concrete to discuss. That ought to be enough for anybody once it gets going. Of course, keeping one going is no great claim. Meanwhile, OpenBSD is consuming about 80 KB of arc4random output per minute. Is that supposed to sound like a lot? I mean modern CSPRNGs generate hundreds of MB per second, per core. What do you mean exactly by OpenBSD is consuming? Are you referring to the kernel or userland arc4random? Probably you think these are ridiculous questions. HMM PERHAPS I'LL GO LOOK AT THE SOURCE CODE AND FIND OUT FOR MYSELF. Back. I was wondering how this was supposed to work because other posters had implied that OpenBSD's many consumers of arc4random were (through some mechanism no one could explain) contributing so much entropy back into the system pool that this design was categorically better. So if all 80KB per minute were being consumed by one instance of lib/libc/crypt/arc4random.c in one user process, it would 'stir' about once every 20 minutes, adding about two or three nanotimes' worth of uncertainty. But of course there are many user processes and if you meant this 80KB were divided among them and it probably happens less often than that. The reseeding of the kernel arc4random is on a fixed 10 minute timeout. Since it's obviously broken to ask a kernel timeout to generate unpredictable bits from its own clock, the timeout just sets a flag so it stirs on the next request for data. Ironically, this has the effect of making the bits from nanotime more predictable the more often that data is queried from the kernel. So the many consumers of random data are not feeding back significant entropy by making unpredictable requests. Probably the main contribution from the typical consumer is the one-time seeding after fork. The other way in which the many consumers theory is said to be justified is the idea that these consumers are reading varying-sized segments from the kernel, and so the unpredictable bits of the size parameter will embody sufficient entropy to thwart RC4-PRNG attacks. Well? Has anyone looked at the statistical distribution? How entropic do he be? Oh wait, I'm not supposed to ask dumb questions. I'LL GO LOOK AT THE CODE INSTEAD. Callers of KERN_ARND sysctl: ld.so/util.c: sizeof(unsigned int) lib/libc/sys/stack_prot.c:sizeof(long[8]) lib/libc/crypt/arc4random.c: always 128 stdlib/random.c: sizeof(int_32)*(1 or 31) per srandom setup I'll just venture a guess that the stack_prot and ld.so are likely to be called in the same way on every process startup. Plus, anything that uses malloc will be initializing his arc4random pretty quickly too. Probably most user processes will be consuming three fixed sized blocks in the same order. Perhaps two or three common apps call stdlib's srandom, resulting in another call of one of two sizes. So I'm not seeing much of this many consumers entropy coming from userspace. True, every newly-forked process will generate some. But a local attacker can watch the process list and probably get a decent estimate on the nanotime values that the kernel will register. From the kernel side, it may be another story. There may be zillions of interrupts happening. But what about their lengths? Well, almost 3/4 of the call sites request four bytes. The next most common is probably 16 or 'sizeof(iv)'. Of course, there will be some variation. But my guess is that the great majority of calls to arc4random originating within the kernel itself will come from a few locations and come in even fewer sizes. Most likely I'm missing something, it needs real measurement. Possibly the worst-case scenario would be something exactly like an IPsec VPN deployment. Little or no new process creation, little or no disk activity. Most interrupts coming from network events which are visible (if not actively influenced) by an attacker. If, in fact, an attacker did manage to get some analysis or a state compromise on the kernel's arc4random, he could [never you mind]. Now, by knowing the skipped distance he learns something about the number and type of events that he missed and can
Re: Allegations regarding OpenBSD IPSEC
2010/12/23 Clint Pachl pa...@ecentryx.com: The last time I installed FreeBSD about 5 years ago, it asked me to pound on the keyboard for like 60 seconds during installation (or at first boot, can't remember) in order to build up some randomness. I wonder what kind of entropy that provided? run it through a hash function and it's a good value. Patch that value into the kernel and it's available from the start of the kernel. Then use that value as a key for a HMAC, to hash time values (and other entropy). Do all that and you have a good seed for a PRNG. Unpredictable, different every time, different on all systems. Regards Kurt Knochner http://knochner.com
Re: Allegations regarding OpenBSD IPSEC
On 12/23/2010 04:39 AM, Kurt Knochner wrote: 2010/12/22 Marsh Rayma...@extendedsubset.com: In any case, generic statistical tests might detect really horrible brokenness but they're are not the thing to certify CSRNGs with. Really? So, how do you certify the IMPLEMENTATION (bold, not shouting) of a CSRNG, (not the theoretical design)? 'Certify' means different things to different people of course. Most professionals don't insist on having the implementations that they use formally certified, but some do. For example, Firefox has a 'FIPS Mode' https://developer.mozilla.org/en/NSS/FIPS_Mode_-_an_explanation But I've never heard of anybody using it unless they have to. It's a really good question: how do you prove that something is unpredictable? In the US, it is the agency NIST. They coordinate and adopt standards for deterministic and non-det pseudorandom number generation. (There are some really fascinating documents on that site.) NIST ran the competition which chose AES and are currently running one to select SHA-3. They have some people who know a bit about the subject: http://csrc.nist.gov/staff/rolodex/kelsley_john.html NIST publishes some stuff about random generation from their statistical engineering division: http://itl.nist.gov/div898/pubs/ar/ar1998/node6.html http://www.itl.nist.gov/div898/pubs/ar/ar2000/node9.html But the computer security division covers the cryptographic side: http://csrc.nist.gov/groups/ST/toolkit/random_number.html http://csrc.nist.gov/groups/ST/toolkit/rng/index.html They are careful to point out the distinction between statistical testing and cryptanalysis: These tests may be useful as a first step in determining whether or not a generator is suitable for a particular cryptographic application. However, no set of statistical tests can absolutely certify a generator as appropriate for usage in a particular application, i.e., statistical testing cannot serve as a substitute for cryptanalysis. It looks like the FIPS standards are what cover the certification of an actual cryptographic module implementation. http://csrc.nist.gov/groups/STM/cmvp/inprocess.html So the process would involve an approved design and you would have to submit your implementation to a NIST-approved Cryptographic Security and Testing laboratory for testing. You can probably find some war stories about that process if you search around on line. - Marsh
dhcpd sync.c cleanup
dhcpd has own logging functions so use those instead of the syslog_r()
calls. With this -d will actually work as expected. Appart from that add
additional warning messages if the sendmsg() call fails.
OK?
--
:wq Claudio
Index: sync.c
===
RCS file: /cvs/src/usr.sbin/dhcpd/sync.c,v
retrieving revision 1.9
diff -u -p -r1.9 sync.c
--- sync.c 27 Mar 2010 14:11:38 - 1.9
+++ sync.c 23 Dec 2010 15:00:03 -
@@ -40,7 +40,6 @@
#include string.h
#include unistd.h
#include sha1.h
-#include syslog.h
#include netdb.h
@@ -111,9 +110,8 @@ sync_addhost(const char *name, u_short p
LIST_INSERT_HEAD(sync_hosts, shost, h_entry);
if (sync_debug)
- syslog_r(LOG_DEBUG, sdata, added dhcp sync host %s
- (address %s, port %d)\n, shost-h_name,
- inet_ntoa(shost-sh_addr.sin_addr), port);
+ note(added dhcp sync host %s (address %s, port %d)\n,
+ shost-h_name, inet_ntoa(shost-sh_addr.sin_addr), port);
return (0);
}
@@ -285,8 +283,7 @@ sync_recv(void)
goto trunc;
if (sync_debug)
- syslog_r(LOG_DEBUG, sdata,
- %s(sync): received packet of %d bytes\n,
+ note(%s(sync): received packet of %d bytes\n,
inet_ntoa(addr.sin_addr), (int)len);
p = (u_int8_t *)(hdr + 1);
@@ -324,16 +321,12 @@ sync_recv(void)
sizeof(lp-ip_addr));
memcpy(lp-hardware_addr, lv-hardware_addr,
sizeof(lp-hardware_addr));
- syslog_r(LOG_DEBUG, sdata,
- DHCP_SYNC_LEASE from %s for hw %s - ip %s,
+ note(DHCP_SYNC_LEASE from %s for hw %s - ip %s,
start %d, end %d,
inet_ntoa(addr.sin_addr),
print_hw_addr(lp-hardware_addr.htype,
- lp-hardware_addr.hlen,
- lp-hardware_addr.haddr),
- piaddr(lp-ip_addr),
- lp-starts,
- lp-ends);
+ lp-hardware_addr.hlen, lp-hardware_addr.haddr),
+ piaddr(lp-ip_addr), lp-starts, lp-ends);
/* now whack the lease in there */
if (lease == NULL) {
enter_lease(lp);
@@ -365,8 +358,7 @@ sync_recv(void)
trunc:
if (sync_debug)
- syslog_r(LOG_INFO, sdata,
- %s(sync): truncated or invalid packet\n,
+ note(%s(sync): truncated or invalid packet\n,
inet_ntoa(addr.sin_addr));
}
@@ -386,21 +378,21 @@ sync_send(struct iovec *iov, int iovlen)
if (sendmcast) {
if (sync_debug)
- syslog_r(LOG_DEBUG, sdata,
- sending multicast sync message\n);
+ note(sending multicast sync message\n);
msg.msg_name = sync_out;
msg.msg_namelen = sizeof(sync_out);
- sendmsg(syncfd, msg, 0);
+ if (sendmsg(syncfd, msg, 0) == -1)
+ warning(sending multicast sync message failed: %m);
}
LIST_FOREACH(shost, sync_hosts, h_entry) {
if (sync_debug)
- syslog_r(LOG_DEBUG, sdata,
- sending sync message to %s (%s)\n,
+ note(sending sync message to %s (%s)\n,
shost-h_name, inet_ntoa(shost-sh_addr.sin_addr));
msg.msg_name = shost-sh_addr;
msg.msg_namelen = sizeof(shost-sh_addr);
- sendmsg(syncfd, msg, 0);
+ if (sendmsg(syncfd, msg, 0) == -1)
+ warning(sending sync message failed: %m);
}
}
@@ -449,12 +441,9 @@ sync_lease(struct lease *lease)
memcpy(ld.ip_addr, lease-ip_addr, sizeof(ld.ip_addr));
memcpy(ld.hardware_addr, lease-hardware_addr,
sizeof(ld.hardware_addr));
- syslog_r(LOG_DEBUG, sdata,
- sending DHCP_SYNC_LEASE for hw %s - ip %s, start %d, end %d,
+ note(sending DHCP_SYNC_LEASE for hw %s - ip %s, start %d, end %d,
print_hw_addr(ld.hardware_addr.htype, ld.hardware_addr.hlen,
- ld.hardware_addr.haddr),
- piaddr(lease-ip_addr),
- ntohl(ld.starts),
+ ld.hardware_addr.haddr), piaddr(lease-ip_addr), ntohl(ld.starts),
ntohl(ld.ends));
iov[i].iov_base = ld;
iov[i].iov_len = sizeof(ld);
Re: dhcpd sync.c cleanup
On Thu, Dec 23, 2010 at 04:12:43PM +0100, Claudio Jeker wrote: dhcpd has own logging functions so use those instead of the syslog_r() calls. With this -d will actually work as expected. Appart from that add additional warning messages if the sendmsg() call fails. OK? ok. Tested with dhcpd -Y iface -y iface between 2 machines.
7 Estrategias de marketing rentables
[IMAGE] [IMAGE] Buenos dmas, en esta oportunidad queremos compartir con usted siete nuevas estrategias para maximizar la visibilidad de su empresa minimizando su inversisn , lo cual le puede ser de gran utilidad. A continuacisn podra observar los 7 puntos de los que vamos a hablar en nuestro sitio web en forma gratuita: 1. Marketing viral. 2. Bases de datos empresas. 3. Email marketing. 4. El telemarketing. 5. Blogging. 6. Publicar artmculos en Internet. 7. Marketing Msvil. Para leer el artmculo completo con las descripciones de cada una de las estrategias haga click aqum Esperamos que les sirva para poder empezar con la publicidad de su empresa a un bajo costo, aclaramos que el articulo es para que tengan una idea de lo que pueden hacer para dar a conocer su empresa. (3655) Sino desea recibir mas informacisn envmenos un email a bases.email...@gmail.com con el asunto R E M O V E R, si le causamos alguna molestia le pedimos disculpas, nuestra intencisn es dar a conocer en forma gratuita los diferentes medios que existen para hacer publicidad invirtiendo poco dinero. (1395)
Re: New acpi challenges! New Dell XPS blows up in acpivideo!
On Thu, Dec 23, 2010 at 07:02:47AM +, Jordan Hargrave wrote: Bad AML. Looks like it is trying to do an AML Load of a memory block, and that is failing. Usually that's because the checksum is incorrect. Look at dsdt.c:aml_load() and put printf's at both goto fails', to see what is failing. Not much I can do about it now as I am in Palau. :) -jordan It does seem to be a failing checksum. acpi_maptable() fails in acpi_load(), in the Load SSDT from memory section. A bit of memory 228 bytes long. Ken
Re: Allegations regarding OpenBSD IPSEC
How much did you get? Is it safe for the boot process to generate keys now? If you can only read.
Re: Allegations regarding OpenBSD's PRNG
What do you mean exactly by OpenBSD is consuming? Are you referring to the kernel or userland arc4random? Probably you think these are ridiculous questions. HMM PERHAPS I'LL GO LOOK AT THE SOURCE CODE AND FIND OUT FOR MYSELF. Back. Haven't you done this already? So you don't know what you are accusing someone off something. No... I didn't read it also, but i'm not entering this discusion with my 'believe'
Re: usb wireless detach
I will test this patch with my Linksys rum(4) AP tonight and report back
to you.
-luis
On 12/22/10 18:36, Jacob Meuser wrote:
no feedback yet. anyone care to comment on this?
On Thu, Dec 16, 2010 at 12:28:56AM +, Jacob Meuser wrote:
the following diff tries to make sure that no other processes/threads
are or will be using the drivers software context when the driver is
detached.
this diff covers rum(4), run(4), ural(4) and urtw(4). without the
diff, I can get the kernel to crash by starting a scan with
the deice, then ejecting it while the scan is running. with this
diff, I cannot get a crash.
normally, usb device detach happens in the usb_task thread. the sole
exception is when the usb bus itself is being detached. this happens
with cardbus devices, and in that case, the usb device detach happens
in the generic workq thread.
this adds a simple reference counting/waiting mechanism. this is
definitely needed for ioctl(2), which can sleep then start using the
driver again. it may not be needed for timeout(9)s now, but maybe
someday it will. another possible process using the device is the
usb_task thread. in the normal case, this is the same process that
is detaching, so there is no concurrency issue. there is already
usb_rem_wait_task() to deal with detaches from other processes,
because the bus driver needs it.
this also adds more uses of usbd_is_dying() to check if the device
has been detached:
* before adding timeouts
* when entering timeouts, usb_tasks, and ioctl
also of note is the order things are done in the detach routines:
1) remove pending timeouts
2) remove (and possibly wait for) pending usb_tasks
3) wait for other processes
4) detach from the network stack
5) cleanup/free usb resources
thoughts? ok?
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: if_ral.c
===
RCS file: /cvs/src/sys/dev/usb/if_ral.c,v
retrieving revision 1.117
diff -u -p -r1.117 if_ral.c
--- if_ral.c6 Dec 2010 04:41:39 - 1.117
+++ if_ral.c15 Dec 2010 02:58:35 -
@@ -363,17 +363,20 @@ ural_detach(struct device *self, int fla
s = splusb();
- if (ifp-if_softc != NULL) {
- ieee80211_ifdetach(ifp);/* free all nodes */
- if_detach(ifp);
- }
-
- usb_rem_task(sc-sc_udev,sc-sc_task);
if (timeout_initialized(sc-scan_to))
timeout_del(sc-scan_to);
if (timeout_initialized(sc-amrr_to))
timeout_del(sc-amrr_to);
+ usb_rem_wait_task(sc-sc_udev,sc-sc_task);
+
+ usbd_ref_wait(sc-sc_udev);
+
+ if (ifp-if_softc != NULL) {
+ ieee80211_ifdetach(ifp);/* free all nodes */
+ if_detach(ifp);
+ }
+
if (sc-amrr_xfer != NULL) {
usbd_free_xfer(sc-amrr_xfer);
sc-amrr_xfer = NULL;
@@ -547,8 +550,15 @@ ural_next_scan(void *arg)
struct ieee80211com *ic =sc-sc_ic;
struct ifnet *ifp =ic-ic_if;
+ if (usbd_is_dying(sc-sc_udev))
+ return;
+
+ usbd_ref_incr(sc-sc_udev);
+
if (ic-ic_state == IEEE80211_S_SCAN)
ieee80211_next_scan(ifp);
+
+ usbd_ref_decr(sc-sc_udev);
}
void
@@ -559,6 +569,9 @@ ural_task(void *arg)
enum ieee80211_state ostate;
struct ieee80211_node *ni;
+ if (usbd_is_dying(sc-sc_udev))
+ return;
+
ostate = ic-ic_state;
switch (sc-sc_state) {
@@ -574,7 +587,8 @@ ural_task(void *arg)
case IEEE80211_S_SCAN:
ural_set_chan(sc, ic-ic_bss-ni_chan);
- timeout_add_msec(sc-scan_to, 200);
+ if (!usbd_is_dying(sc-sc_udev))
+ timeout_add_msec(sc-scan_to, 200);
break;
case IEEE80211_S_AUTH:
@@ -1324,6 +1338,11 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
struct ifreq *ifr;
int s, error = 0;
+ if (usbd_is_dying(sc-sc_udev))
+ return ENXIO;
+
+ usbd_ref_incr(sc-sc_udev);
+
s = splnet();
switch (cmd) {
@@ -1387,6 +1406,8 @@ ural_ioctl(struct ifnet *ifp, u_long cmd
splx(s);
+ usbd_ref_decr(sc-sc_udev);
+
return error;
}
@@ -2147,7 +2168,8 @@ ural_amrr_start(struct ural_softc *sc, s
i--);
ni-ni_txrate = i;
- timeout_add_sec(sc-amrr_to, 1);
+ if (!usbd_is_dying(sc-sc_udev))
+ timeout_add_sec(sc-amrr_to, 1);
}
void
@@ -2157,6 +2179,11 @@ ural_amrr_timeout(void *arg)
usb_device_request_t req;
int s;
+ if (usbd_is_dying(sc-sc_udev))
+ return;
+
+ usbd_ref_incr(sc-sc_udev);
+
s = splusb();
/*
@@ -2174,6 +2201,8 @@ ural_amrr_timeout(void *arg)
(void)usbd_transfer(sc-amrr_xfer);
splx(s);
+
+ usbd_ref_decr(sc-sc_udev);
}
void
@@ -2203,7 +2232,8 @@
Merry XxXMass
[IMAGE] [IMAGE] [IMAGE] [IMAGE] This offer is reserved to adults. By clicking on any of the links in this mail, you certify that you are over 18.
working hotplug for busy devices on mpii(4)
hi guys,
this makes mpii properly detach devices, which helps a lot if they
have commands in flight. to relevant changes are:
- call the activate(DVACT_DEACTIVATE) function against all the luns
on the target that is going away.
- issue the target reset BEFORE detaching the children devices.
this is needed now tha the midlayer will sleep until all outstanding
commands on a device come back from the adapter before calling the
child devices attach routine.
i have tested this on straight disks, but not on raid volumes. i
need someone to test disk removal behind a raid set before i can
commit it.
assuming testing goes well, can i get oks too?
dlg
Index: mpii.c
===
RCS file: /cvs/src/sys/dev/pci/mpii.c,v
retrieving revision 1.35
diff -u -p -r1.35 mpii.c
--- mpii.c 23 Aug 2010 00:53:36 - 1.35
+++ mpii.c 24 Dec 2010 05:46:34 -
@@ -3417,6 +3417,8 @@ mpii_event_sas(struct mpii_softc *sc, st
mpii_remove_dev(sc, dev);
if (sc-sc_scsibus) {
SET(dev-flags, MPII_DF_DETACH);
+ scsi_activate(sc-sc_scsibus, dev-slot, -1,
+ DVACT_DEACTIVATE);
if (scsi_task(mpii_event_defer, sc,
dev, 0) != 0)
printf(%s: unable to run device
@@ -3529,27 +3531,19 @@ mpii_event_defer(void *xsc, void *arg)
struct mpii_softc *sc = xsc;
struct mpii_device *dev = arg;
- /*
-* SAS and IR events are delivered separately, so it won't hurt
-* to wait for a second.
-*/
- tsleep(sc, PRIBIO, mpiipause, hz);
-
- if (!ISSET(dev-flags, MPII_DF_HIDDEN)) {
- if (ISSET(dev-flags, MPII_DF_ATTACH))
- scsi_probe_target(sc-sc_scsibus, dev-slot);
- else if (ISSET(dev-flags, MPII_DF_DETACH))
- scsi_detach_target(sc-sc_scsibus, dev-slot,
- DETACH_FORCE);
- }
-
if (ISSET(dev-flags, MPII_DF_DETACH)) {
mpii_sas_remove_device(sc, dev-dev_handle);
+ if (!ISSET(dev-flags, MPII_DF_HIDDEN)) {
+ scsi_detach_target(sc-sc_scsibus, dev-slot,
+ DETACH_FORCE);
+ }
free(dev, M_DEVBUF);
- return;
- }
- CLR(dev-flags, MPII_DF_ATTACH);
+ } else if (ISSET(dev-flags, MPII_DF_ATTACH)) {
+ CLR(dev-flags, MPII_DF_ATTACH);
+ if (!ISSET(dev-flags, MPII_DF_HIDDEN))
+ scsi_probe_target(sc-sc_scsibus, dev-slot);
+ }
}
void
@@ -4547,9 +4541,12 @@ mpii_scsi_cmd_done(struct mpii_ccb *ccb)
case MPII_IOCSTATUS_BUSY:
case MPII_IOCSTATUS_INSUFFICIENT_RESOURCES:
+ xs-error = XS_BUSY;
+ break;
+
case MPII_IOCSTATUS_SCSI_IOC_TERMINATED:
case MPII_IOCSTATUS_SCSI_TASK_TERMINATED:
- xs-error = XS_BUSY;
+ xs-error = XS_RESET;
break;
case MPII_IOCSTATUS_SCSI_INVALID_DEVHANDLE:
@@ -4559,6 +4556,7 @@ mpii_scsi_cmd_done(struct mpii_ccb *ccb)
default:
xs-error = XS_DRIVER_STUFFUP;
+ break;
}
if (sie-scsi_state MPII_SCSIIO_ERR_STATE_AUTOSENSE_VALID)
timeout io on mpii(4)
i can reliably produce a situation where an io on a disk attached
to mpii(4) never completes. this implements timeouts on scsi io so
we can recover from this situation.
ok?
Index: mpii.c
===
RCS file: /cvs/src/sys/dev/pci/mpii.c,v
retrieving revision 1.35
diff -u -p -r1.35 mpii.c
--- mpii.c 23 Aug 2010 00:53:36 - 1.35
+++ mpii.c 24 Dec 2010 06:04:38 -
@@ -1757,7 +1757,8 @@ struct mpii_ccb {
volatile enum {
MPII_CCB_FREE,
MPII_CCB_READY,
- MPII_CCB_QUEUED
+ MPII_CCB_QUEUED,
+ MPII_CCB_TIMEOUT
} ccb_state;
void(*ccb_done)(struct mpii_ccb *);
@@ -1822,6 +1823,15 @@ struct mpii_softc {
struct mpii_ccb_listsc_ccb_free;
struct mutexsc_ccb_free_mtx;
+ struct mutexsc_ccb_mtx;
+ /*
+* this protects the ccb state and list entry
+* between mpii_scsi_cmd and scsidone.
+*/
+
+ struct mpii_ccb_listsc_ccb_tmos;
+ struct scsi_iohandler sc_ccb_tmo_handler;
+
struct scsi_iopool sc_iopool;
struct mpii_dmamem *sc_requests;
@@ -1894,6 +1904,10 @@ int mpii_alloc_queues(struct mpii_softc
void mpii_push_reply(struct mpii_softc *, struct mpii_rcb *);
void mpii_push_replies(struct mpii_softc *);
+void mpii_scsi_cmd_tmo(void *);
+void mpii_scsi_cmd_tmo_handler(void *, void *);
+void mpii_scsi_cmd_tmo_done(struct mpii_ccb *);
+
intmpii_alloc_dev(struct mpii_softc *);
intmpii_insert_dev(struct mpii_softc *, struct mpii_device *);
intmpii_remove_dev(struct mpii_softc *, struct mpii_device *);
@@ -4035,7 +4049,11 @@ mpii_alloc_ccbs(struct mpii_softc *sc)
int i;
SLIST_INIT(sc-sc_ccb_free);
+ SLIST_INIT(sc-sc_ccb_tmos);
mtx_init(sc-sc_ccb_free_mtx, IPL_BIO);
+ mtx_init(sc-sc_ccb_mtx, IPL_BIO);
+ scsi_ioh_set(sc-sc_ccb_tmo_handler, sc-sc_iopool,
+ mpii_scsi_cmd_tmo_handler, sc);
sc-sc_ccbs = malloc(sizeof(*ccb) * (sc-sc_request_depth-1),
M_DEVBUF, M_NOWAIT | M_ZERO);
@@ -4448,6 +4466,7 @@ mpii_scsi_cmd(struct scsi_xfer *xs)
DNPRINTF(MPII_D_CMD, %s: Offset0: 0x%02x\n, DEVNAME(sc),
io-sgl_offset0);
+ timeout_set(xs-stimeout, mpii_scsi_cmd_tmo, ccb);
if (xs-flags SCSI_POLL) {
if (mpii_poll(sc, ccb) != 0) {
xs-error = XS_DRIVER_STUFFUP;
@@ -4459,10 +4478,66 @@ mpii_scsi_cmd(struct scsi_xfer *xs)
DNPRINTF(MPII_D_CMD, %s:mpii_scsi_cmd(): opcode: %02x
datalen: %d\n, DEVNAME(sc), xs-cmd-opcode, xs-datalen);
+ timeout_add_msec(xs-stimeout, xs-timeout);
mpii_start(sc, ccb);
}
void
+mpii_scsi_cmd_tmo(void *xccb)
+{
+ struct mpii_ccb *ccb = xccb;
+ struct mpii_softc *sc = ccb-ccb_sc;
+
+ printf(%s: mpii_scsi_cmd_tmo\n, DEVNAME(sc));
+
+ mtx_enter(sc-sc_ccb_mtx);
+ if (ccb-ccb_state == MPII_CCB_QUEUED) {
+ ccb-ccb_state = MPII_CCB_TIMEOUT;
+ SLIST_INSERT_HEAD(sc-sc_ccb_tmos, ccb, ccb_link);
+ }
+ mtx_leave(sc-sc_ccb_mtx);
+
+ scsi_ioh_add(sc-sc_ccb_tmo_handler);
+}
+
+void
+mpii_scsi_cmd_tmo_handler(void *cookie, void *io)
+{
+ struct mpii_softc *sc = cookie;
+ struct mpii_ccb *tccb = io;
+ struct mpii_ccb *ccb;
+ struct mpii_msg_scsi_task_request *stq;
+
+ mtx_enter(sc-sc_ccb_mtx);
+ ccb = SLIST_FIRST(sc-sc_ccb_tmos);
+ if (ccb != NULL) {
+ SLIST_REMOVE_HEAD(sc-sc_ccb_tmos, ccb_link);
+ ccb-ccb_state = MPII_CCB_QUEUED;
+ }
+ /* should remove any other ccbs for the same dev handle */
+ mtx_leave(sc-sc_ccb_mtx);
+
+ if (ccb == NULL) {
+ scsi_io_put(sc-sc_iopool, tccb);
+ return;
+ }
+
+ stq = tccb-ccb_cmd;
+ stq-function = MPII_FUNCTION_SCSI_TASK_MGMT;
+ stq-task_type = MPII_SCSI_TASK_TARGET_RESET;
+ stq-dev_handle = htole16(ccb-ccb_dev_handle);
+
+ tccb-ccb_done = mpii_scsi_cmd_tmo_done;
+ mpii_start(sc, tccb);
+}
+
+void
+mpii_scsi_cmd_tmo_done(struct mpii_ccb *tccb)
+{
+ mpii_scsi_cmd_tmo_handler(tccb-ccb_sc, tccb);
+}
+
+void
mpii_scsi_cmd_done(struct mpii_ccb *ccb)
{
struct mpii_msg_scsi_io_error *sie;
@@ -4470,6 +4545,14 @@ mpii_scsi_cmd_done(struct mpii_ccb *ccb)
struct scsi_xfer*xs = ccb-ccb_cookie;
struct mpii_ccb_bundle *mcb = ccb-ccb_cmd;
bus_dmamap_tdmap = ccb-ccb_dmamap;
+
+
