| MR.WOOD |
| Dec 13, 12:55 pm 2010 |
| Mark Kettenis | Re: MCLGETI for dc(4)
Whoa there. Please stop for a moment. We have converted a small
number to MCLGETI, and in almost all cases we've run into bugs.
Subtle driver bugs, hardware bugs that need workarounds, etc. etc. If
a driver is used a lot or if the number of chip variants is very
limited, we eventaully find those bugs and fix them. But if the
hardware is rare or there are a lot of weird, buggy variants of a
chip, finding and fixing those bugs becomes a lot harder. Effectively
this means we're likely to ship a ...
| Dec 13, 12:41 pm 2010 |
| Loganaden Velvindron | MCLGETI for dc(4)
First of all, big thanks to Christian `naddy` who sent me a dc(4). I also managed to get my hands on a PNIC. This diff add mclgeti support plus 2 bug fixes that suppress idle timeouts, and autonegocation which is broken on the PNIC. As usual, you know who to complain to.
Index: src/sys/dev/ic/dc.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/dc.c,v
retrieving revision 1.121
diff -u -p -r1.121 dc.c
--- src/sys/dev/ic/dc.c 7 Sep 2010 16:21:42 ...
| Dec 13, 11:51 am 2010 |
| Stuart Henderson | Re: MCLGETI for dc(4)
Please could you split out the PNIC parts of the diff? They would
definitely be a separate commit whatever happens with MCLGETI, and
| Dec 13, 2:41 pm 2010 |
| Thomas Pfaff | pf: ugly error message when probability value out of range.
When specifying a probability attribute on a rule and the value is out of
range, pfctl reports the problem using the internal probability value, an
unsigned greater than UINT_MAX, rather than what you actually specified.
The accepted range is either a number between 0 and 1 or between 0 and 100
if followed by a % character (to specify the value in percent).
The pfctl rule output already display the probability value in percent:
# pfctl -sr | grep prob
pass in on em0 inet proto icmp ...
| Dec 13, 10:24 am 2010 |
| Ted Unangst |
| Dec 13, 1:32 pm 2010 |
| Chris Kuethe |
| Dec 13, 1:08 pm 2010 |
| Ted Unangst | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
On Mon, Dec 13, 2010 at 3:27 PM, Mark Kettenis <mark.kettenis@xs4all.nl>
Surely there is something on the disk that can be used to formuate
one? I mean, people have to write hotplug scripts that figure this
out, don't they? Why make it so hard?
| Dec 13, 1:43 pm 2010 |
| Ted Unangst | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
On Mon, Dec 13, 2010 at 7:41 AM, Mark Kettenis <mark.kettenis@xs4all.nl>
I think the solution to that is to make adding the duid to fstab work.
At boot, if the duid exists, it's mounted. If it doesn't, it doesn't
mount but also doesn't error out. This may already work even, I
haven't tried it.
For example, network interfaces plugged in at boot just work without
hotplug support. If the device is present, hostname.if is run. If
not, no error. I think disks should work the same way.
| Dec 13, 11:17 am 2010 |
| MERIGHI Marcus | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
See below. Commit message suggestion: "document behaviour change: no
more queueing before open to avoid problems when both attach and detach
Index: share/man/man4/hotplug.4
===================================================================
RCS file: /cvs/src/share/man/man4/hotplug.4,v
retrieving revision 1.3
diff -u -r1.3 hotplug.4
--- share/man/man4/hotplug.4 31 May 2007 19:19:50 -0000 1.3
+++ share/man/man4/hotplug.4 13 Dec 2010 11:29:30 -0000
@@ -31,7 +31,8 @@
.Nm
...
| Dec 13, 4:48 am 2010 |
| MERIGHI Marcus |
| Dec 13, 6:28 am 2010 |
| Ted Unangst | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
I can agree there's a problem here, but the fact that you're using
hotplug to mount disks that aren't hotplugged indicates the problem is
elsewhere. :) I don't think hotplug was supposed to be the "do random
stuff a little bit but not too long after boot" utility.
| Dec 13, 1:04 pm 2010 |
| Todd T. Fries | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
Softraid cryptoraid disks are hotplug'ed whenever someone issues
bioctl, whether it is in /etc/rc, /etc/rc.local.local, or elsewhere.
It is not presently possible to have them created prior to init,
but then again, usb disks (read: cameras) can be done prior to init.
I can insert a usb disk and create a softraid crypto volume after
hotplugd starts, and let the attach script worry about duid and fsck
and mount, but I can't do this if it happens to show up before
hotplugd starts.
Whether ...
| Dec 13, 1:13 pm 2010 |
| Mark Kettenis |
| Dec 13, 1:27 pm 2010 |
| Todd T. Fries |
| Dec 13, 3:19 pm 2010 |
| Todd T. Fries | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
I echo Mark's sentiments, though for a different reason.
Softraid crypto volumes take time to fsck, yet are useful to use.
In my case I can wait 20+min for my personal laptop to be useful, or I
can wait 5min and let the rest fsck while I get to be productive. The
laptop has /usr, /var, /tmp, /home, /usr/obj, /usr/src, /usr/ports
amongst other partitions. I've marked all but the first four as
'noauto' and then use the hotplug attach routine to fsck and mount the
rest, which are not necessary ...
| Dec 13, 12:48 pm 2010 |
| Mark Kettenis | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
A bit late to the game, but I don't really agree with Tedu that the
changed behaviour is an improvement. Say I have configured
hotplugd(8) such that it automatically mounts things when I plug in my
camera. Now I reboot my machine, without unplugging the camera.
Previously hotplugd(8) would remount things upon boot. Now suddenly
But this just seems to change the wording without actually changing
Adding comments like this, describing historical behaviour really
isn't such a good idea.
| Dec 13, 5:41 am 2010 |
| Jonathan Armani | Re: hotplug(4) r1.10 ignoring hotplug_put_event() prior ...
On Mon, 13 Dec 2010 14:28:42 +0100, MERIGHI Marcus
Maybe a bit aggressive, but why not something like this in put_event :
if (!opened && event.type == DETACH) {
foreach (ev in event_queue)
if (ev.type == ATTACH && ev.devclass == event.devclass &&
ev.devname == event.devname)
remove(ev);
}
So we remove all attached then detached devices before hotplugd is
| Dec 13, 7:51 am 2010 |
| MERIGHI Marcus |
| Dec 13, 2:23 am 2010 |
