Re: big change to devfs rules path matching
On 2013-03-28, Andriy Gapon wrote: > > Would like to ask for opinions on this topic... > > Please read this PR for context: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > > So I would like to commit the following patch sooner rather than later: I have revised the patch slightly: http://people.freebsd.org/~jh/patches/devfs-rule-fullpath.3.diff There is no functional change. I intend to commit the patch soon. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: poweroff (shutdown -p) is broken
On 2013-04-03, Andriy Gapon wrote: > on 03/04/2013 02:15 deeptech71 said the following: > > As of r248872, my system, when ordered to power off, stalls at the "Uptime: > > [...]" message. Before that revision, the "Uptime" message would be > > followed by > > several additional messages -- something related to "usb controllers" -- > > before > > powering off. > > You need to break into the ddb and examine where exactly the shutdown thread > is > stuck. I can confirm the problem. It hangs while trying to spin down an ada(4) disk. Tracing pid 1 tid 12 td 0xc72bbc00 sched_switch(c72bbc00,0,104,1b5,c6946188,...) at sched_switch+0x456/frame 0xc6ec4a98 mi_switch(104,0,c0f36d00,1f5,5c,...) at mi_switch+0x20b/frame 0xc6ec4ac8 sleepq_switch(c72bbc00,0,c0f36d00,26b,0,...) at sleepq_switch+0x1a5/frame 0xc6ec4af0 sleepq_wait(c72b573c,5c,c0d92504,0,0,...) at sleepq_wait+0x6b/frame 0xc6ec4b0c _sleep(c72b573c,c732c974,5c,c0d92504,0,...) at _sleep+0x3f0/frame 0xc6ec4b64 cam_periph_getccb(c72b5700,480,c0d94762,c0,ea,...) at cam_periph_getccb+0xd7/frame 0xc6ec4b9c adaspindown(c6ec4c2c,c0a130b6,0,4008,c0f306e7,...) at adaspindown+0xf1/frame 0xc6ec4bcc adashutdown(0,4008,c0f306e7,1bc,c09e261a,...) at adashutdown+0x29/frame 0xc6ec4bd4 kern_reboot(4008,0,c0f306e7,be,bfbfd9a0,...) at kern_reboot+0x706/frame 0xc6ec4c2c sys_reboot(c72bbc00,c6ec4ccc,c72bbcb4,c12164a0,202,...) at sys_reboot+0x6c/frame 0xc6ec4c4c syscall(c6ec4d08) at syscall+0x2ab/frame 0xc6ec4cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc6ec4cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805c0a7, esp = 0xbfbfd86c, ebp = 0xbfbfd948 --- -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: big change to devfs rules path matching
On 2013-03-28, Andriy Gapon wrote: > > Would like to ask for opinions on this topic... > > Please read this PR for context: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > > Especially Jaakko's insightful description of the problem. > > So I would like to commit the following patch sooner rather than later: > http://people.freebsd.org/~avg/devfs_rule.diff > The only difference from the Jaakko's patch in the PR is FNM_PATHNAME. > > Please review and test. Good to see this moving forward! Maybe the change warrants an UPDATING entry? -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after r244584
On 2013-01-23, Vitalij Satanivskij wrote: > VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff > VS> > VS> Ok that patch work's too. > > Is there any chance, that one of this patches will be merged to head? Committed as r245891. Thanks for reporting and testing! -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after r244584
On 2013-01-23, Vitalij Satanivskij wrote: > VS> Jaakko Heinonen wrote: > VS> JH> > I see two possible solutions for the problem. > VS> JH> > > VS> JH> > 1) Replace non-printable, space and '/' characters for example with > '_'. > VS> JH> >'/' should be replaced anyway. > VS> JH> > > VS> JH> > 2) Apply the patches in > VS> JH> > > http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html > VS> JH> >to allow spaces again. I haven't committed the patches because I > VS> JH> >think that there isn't full consensus that it's right thing to > do and > VS> JH> >also I personally prefer not to have spaces in device names. > VS> JH> > VS> JH> Here's a patch to implement 1: > VS> JH> > VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff > VS> > VS> Ok that patch work's too. > > Is there any chance, that one of this patches will be merged to head? Yes. Alexander and Justin: what do you think about this patch? http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after r244584
On 2013-01-19, Jaakko Heinonen wrote: > On 2013-01-18, Alexander Motin wrote: > > At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are > > impossible there, as previous name components are unique. Special > > characters haven't yet seen, but I think theoretically possible. > > I see two possible solutions for the problem. > > 1) Replace non-printable, space and '/' characters for example with '_'. >'/' should be replaced anyway. > > 2) Apply the patches in >http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html >to allow spaces again. I haven't committed the patches because I >think that there isn't full consensus that it's right thing to do and >also I personally prefer not to have spaces in device names. Here's a patch to implement 1: http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after r244584
On 2013-01-18, Alexander Motin wrote: > At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are > impossible there, as previous name components are unique. Special > characters haven't yet seen, but I think theoretically possible. I see two possible solutions for the problem. 1) Replace non-printable, space and '/' characters for example with '_'. '/' should be replaced anyway. 2) Apply the patches in http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html to allow spaces again. I haven't committed the patches because I think that there isn't full consensus that it's right thing to do and also I personally prefer not to have spaces in device names. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after r244584
On 2013-01-18, Alexander Motin wrote: > > AM> > V> panic: make_dev_alias_v: bad si_name (error=22 > > si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) > > AM> The panic is triggered by the check added by the recent r244584 change. > > AM> The space in device name came from the enclosure device, and I guess it > > AM> may be quite often situation. Using human readable name supposed to help > > AM> system administrators, but with spaces banned that may be a problem. > > > > That's was not created by human, it was generated (I think so) by system. > > These strings are flashed into enclosure firmware by manufacturer. You can't rely on that any string can be safely used as a device name even if spaces were allowed. Consider for example duplicate names and "../". Where these names are generated? The original report didn't contain a backtrace. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pw keeps setting /etc/group to 0600
On 2012-11-19, Mateusz Guzik wrote:
> First, pw should not fail if other instance is running, it should wait
> instead (think of parallel batch scripts adding some users/groups).
>
> Second, current code has a race:
> lockfd = open(group_file, O_RDONLY, 0);
> if (lockfd < 0 || fcntl(lockfd, F_SETFD, 1) == -1)
> err(1, "%s", group_file);
> if (flock(lockfd, LOCK_EX|LOCK_NB) == -1) {
> [..]
> gr_copy(pfd, tfd, gr, old_gr); /* copy from groupfile to tempfile */
> [..]
> rename(tempfile,groupfile);
Hmm, could using the O_EXLOCK flag for open() instead of flock() help here?
> Now let's consider threads A and B:
>
> A: open()
> A: lock();
> A: gr_copy
> B: open()
>
> Now B has file descriptor to /etc/group that is about to be removed.
>
> A: rename()
> A: unlock()
> B: lock()
>
> Now B has a lock on unlinked file.
>
> B: gr_copy()
> B: rename()
>
> ... and stores new content losing modifications done by A
--
Jaakko
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 2011-09-29, Craig Rodrigues wrote:
> On Wed, Sep 28, 2011 at 1:15 AM, Jaakko Heinonen wrote:
> > I think that using the FEATURE() macro and feature_present(3) might be
> > more appropriate for this.
>
> Oh, OK. I was unfamiliar with these API's because they are new in FreeBSD 8.
> :)
> How about the attached patch?
Looks mostly OK to me.
> Index: usr.sbin/burncd/burncd.c
> ===
> --- usr.sbin/burncd/burncd.c (revision 225368)
> +++ usr.sbin/burncd/burncd.c (working copy)
> @@ -82,6 +82,15 @@
> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
> const char *dev, *env_speed;
>
> + if (feature_present("ata_cam")) {
> + printf("\nATA_CAM option is enabled in kernel.\n"
> + "Install the sysutils/cdrtools port and use cdrecord "
> + "instead.\n\n"
> + "Please refer to:\n"
> +
> "http://www.freebsd.org/doc/handbook/creating-cds.html#CDRECORD\n";);
> + exit(1);
> + }
> +
Why do you use printf() + exit() here and errx() in atacontrol? Is there
reason to not use errx() also here?
> + if (feature_present("ata_cam")) {
> + errx(1, "ATA_CAM option is enabled in kernel.\n"
> + "Please use camcontrol instead.\n");
> + }
errx(3) adds a newline character to the output. Thus the latter '\n' is
redundant.
burncd(8) manual page date should be bumped.
Thanks.
--
Jaakko
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ia64 r225789 panic during "make installworld": Bad buffer logic, remain = 0
On 2011-09-28, Anton Shterenlikht wrote: > KDB: stack backtrace: > getenv with the following non-sleepable locks held: > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > (0xe00011950488) locked @ /usr/src/sys/fs/devfs/devfs_vnops.c:406 > > etc. until a hang, requiring cold reset via MP. Someone is calling getenv with a vnode interlock held. You need to figure out the caller. Unfortunately the backtrace is missing above. As a temporary workaround you could comment the WITNESS_WARN() line in getenv() (sys/kern/kern_environment.c) but it is not a real fix. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 2011-09-27, Craig Rodrigues wrote: > I think we need something like the following patch. > +#ifdef ATA_CAM > +SYSCTL_INT(_hw_ata, OID_AUTO, ata_cam_enabled, > + CTLFLAG_RD, &ata_cam_enabled, 1, > + "ATA devices are accessed through the cam(4) driver"); > +#endif I think that using the FEATURE() macro and feature_present(3) might be more appropriate for this. Thanks. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bug: devfs is sure to have the bug.
On 2011-08-03, Kostik Belousov wrote:
> On Wed, Aug 03, 2011 at 02:44:23PM +0900, Kohji Okuno wrote:
> > > devfs_populate(), and the context holds only "dm->dm_lock" in
> > > devfs_populate().
> > >
> > > On the other hand, "devfs_generation" is incremented in devfs_create()
> > > and devfs_destroy() the context holds only "devmtx" in devfs_create()
> > > and devfs_destroy().
> > >
> > > If a context executes devfs_create() when other context is executing
> > > (***), then "dm->dm_generation" is updated incorrect value.
> > > As a result, we can not open the last detected device (we receive ENOENT).
>
> I think the problem you described is real, and suggested change is right.
> Initially, I thought that we should work with devfs_generation as with
> the atomic type due to unlocked access in the devfs_populate(), but then
> convinced myself that this is not needed.
>
> But also, I think there is another half of the problem. Namely,
> devfs_lookup() calls devfs_populate_vp(), and then does lookup with the
> help of devfs_lookupx(). We will miss the generation update
> happen after the drop of the dm_lock in devfs_populate_vp() to reacquire
> the directory vnode lock.
I don't understand this. devfs_generation is not protected with dm_lock
in devfs_create() and devfs_destroy(). On the other hand if you mean
that another thread calls devfs_populate() while we drop dm_lock in
devfs_populate_vp(), isn't the mount point up to date when we re-lock
dm_lock?
> @@ -630,13 +630,15 @@ devfs_populate_loop(struct devfs_mount *dm, int cleanup)
> void
> devfs_populate(struct devfs_mount *dm)
> {
> + unsigned gen;
>
> sx_assert(&dm->dm_lock, SX_XLOCKED);
> - if (dm->dm_generation == devfs_generation)
> + gen = devfs_generation;
> + if (dm->dm_generation == gen)
> return;
> while (devfs_populate_loop(dm, 0))
> continue;
> - dm->dm_generation = devfs_generation;
> + dm->dm_generation = gen;
> }
After this change dm->dm_generation may be stale although the mount
point is up to date? This is probably harmless, though.
--
Jaakko
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysctl -a is slow
On 2010-09-20, David Xu wrote:
> I redirect all output to a disk file, and it still needs 1 second to
> complete, this machine is dual-core pentium E5500, faster than previous
> one which is a dual-core AMD 5000+ machine, the 5000+ needs 2
> seconds to complete.
>
> $/usr/bin/time sysctl -b kern.geom.confdot > sysctl_geom_confdot.txt
> 1.00 real 0.00 user 0.00 sys
I couldn't reproduce the problem myself but I bet that it's a lost
wakeup in g_waitfor_event(). Can you try this patch?
%%%
Index: sys/geom/geom_event.c
===
--- sys/geom/geom_event.c (revision 214048)
+++ sys/geom/geom_event.c (working copy)
@@ -220,11 +220,12 @@ one_event(void)
mtx_lock(&g_eventlock);
TAILQ_REMOVE(&g_events, ep, events);
ep->flag &= ~EV_INPROGRESS;
- mtx_unlock(&g_eventlock);
if (ep->flag & EV_WAKEUP) {
ep->flag |= EV_DONE;
wakeup(ep);
+ mtx_unlock(&g_eventlock);
} else {
+ mtx_unlock(&g_eventlock);
g_free(ep);
}
g_topology_unlock();
@@ -365,11 +366,14 @@ g_waitfor_event(g_event_t *func, void *a
va_end(ap);
if (error)
return (error);
- do
- tsleep(ep, PRIBIO, "g_waitfor_event", hz);
- while (!(ep->flag & EV_DONE));
+
+ mtx_lock(&g_eventlock);
+ while (!(ep->flag & EV_DONE))
+ msleep(ep, &g_eventlock, PRIBIO, "g_waitfor_event", hz);
if (ep->flag & EV_CANCELED)
error = EAGAIN;
+ mtx_unlock(&g_eventlock);
+
g_free(ep);
return (error);
}
%%%
--
Jaakko
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: device name checking on device registration
On 2010-10-12, Andriy Gapon wrote: > on 12/10/2010 16:36 Matthew Jacob said the following: > > Good workaround, still a nasty surprising bug. > > Yeah. I also would prefer ignoring such a partition or somehow sanitizing its > name or etc. panic(9) on bad internal state of a kernel sounds appropriate, > panic(9) on bad input sounds like trouble. I am working on a change for GEOM. I will post a patch to -geom for comments shortly. I want just to note that previously bad names could cause erratic behavior (including panics) deep in devfs code instead of catching them early. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: device name checking on device registration
On 2010-10-11, barbara wrote: > The panic is caused by: > g_dev_taste(): make_dev_p() failed (gp->name=ext2fs//, error=22) > as I have a linux partition (I swear, it's for my mom!) on the same machine. > As I don't care about that partition (being ext4 I can't even mount > it), is there any solution other then applying the patch after every > csup? If you don't need ext2fs labels you can put the following line to /boot/loader.conf as a workaround: kern.geom.label.ext2fs.enable=0 -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
HEADS UP: device name checking on device registration
Since r213526 device names are checked on device registration. That is, if you call a make_dev*() function with an invalid device name, a panic will occur by default. For make_dev_credf(9) or make_dev_p(9) you can specify the MAKEDEV_CHECKNAME flag to get an error return instead of a panic. Invalid names are as follows: - empty name - names longer than SPECNAMELEN - names containing "." or ".." path component - names ending with '/' - already existing device names So, if you see a "bad si_name" panic you may have encountered a driver bug. Currently several GEOM classes (notably geom_label) allow to create devices with invalid names. Below is a link to a patch which converts g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not a complete solution and essentially changes the panic to a printf. http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFR] devfs improvements
Hi, I have been working on some devfs improvements and I am now posting the patch for wider review and testing. Especially testing from people using multiple devfs mounts and/or symbolic links would be useful. The patch: http://people.freebsd.org/~jh/patches/devfs.7.diff Notable changes: - Automatically remove empty directories. - Allow user created symbolic links to cover device files and directories if the device file appears after the link creation. - It's now possible to report if the device file already exists or is invalid to make_dev_credf(9) and make_dev_p(9) callers. There is a new flag MAKEDEV_CHECKNAME to indicate that the caller is prepared to handle such error. If the flag is not specified and the device name is invalid, a panic will occur. This code is not yet enabled because there are some driver issues which need to be sorted out before. (See "#ifdef notyet" in make_dev_credv().) In addition the patch should fix these bugs: - kern/114057 - fstat(2) could return stale information through open file descriptors. My main motivation for these changes was erratic handling of duplicate and invalid device names. For example currently you can crash the system through geom_label by inserting a specially crafted CD. Driver bugs causing duplicate device registrations weren't detected either. Most of the ideas implemented in the patch are from Kostik Belousov. Special thanks for him providing help and reviews during the development. Additional patches: A patch for GEOM to convert g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag instead of make_dev(). http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff Enable panicking on invalid device names: http://people.freebsd.org/~jh/patches/make_dev-checkname.diff -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs panic
On 2010-06-23, ben wilber wrote: > > > panic: _sx_xlock_hard: recursed on non-recursive sx > > > buf_hash_table.ht_locks[i].ht_lock @ > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c > > > ommon/fs/zfs/arc.c:1626 > > > > Any chance to obtain a backtrace for the panic? > > >From r209229: > > db:0:kdb.enter.default> bt > Tracing pid 3233 tid 100396 td 0xff013600f000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x1c8 > _sx_xlock_hard() at _sx_xlock_hard+0x93 > _sx_xlock() at _sx_xlock+0xaa > arc_buf_remove_ref() at arc_buf_remove_ref+0x7b > dbuf_rele() at dbuf_rele+0x15d > zfs_freebsd_reclaim() at zfs_freebsd_reclaim+0xe1 > VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xe8 > vgonel() at vgonel+0x186 > vnlru_free() at vnlru_free+0x2f4 > vfs_lowmem() at vfs_lowmem+0x31 I believe that this has been fixed in r209260. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] BSDL iconv in base system
Hi, On 2010-06-15, Gabor Kovesdan wrote: > - The iconv.h header files is supposed to be compatible with the GNU > version, i.e. sources should build with base iconv.h and GNU libiconv. > I've just did a very quick test and it seems ports can safely link to > GNU libiconv, there's no conflict. > The rather big patch (42,5M) is available here: > http://www.kovesdan.org/patches/iconv_base_integrate.diff iconv(3) prototype doesn't conform to POSIX.1-2008. Is it a well-considered decision? -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Switchover to CAM ATA?
On 2010-04-23, Scott Long wrote: > My advice is to retrain your fingers to use cdrecord. Burncd is > highly specific to the old ata driver, and "adding SCSI support" to it > would likely involve a complete rewrite. Well, I did that by porting parts of acd(4) to user space. -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Switchover to CAM ATA?
On 2010-04-23, Alexander Best wrote: > has anybody thought about adding scsi support to burncd(8)? i've been using > ATA CAM for quite a while now and really love it. however i miss burncd(8). I have thought about it. The mail I posted in December didn't generate any interest. http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
