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:
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 -- somethi
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 so
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!
--
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
> '_'.
&g
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 theo
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) Re
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 en
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_SETF
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
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 rese
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
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_destro
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.g
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 approp
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 solutio
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.
Inval
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 change
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?
>
> >Fr
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.
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
_
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
22 matches
Mail list logo
