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"
Re: system hangs after logging into gdm
В Mon, 11 Oct 2010 08:37:05 -0700
Garrett Cooper пишет:
> On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon wrote:
> > on 11/10/2010 10:59 Ivan Klymenko said the following:
> >> В Sun, 10 Oct 2010 15:37:55 -0700
> >> Garrett Cooper пишет:
> >>
> >>> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko
> >>> wrote:
> Hi!
>
> My system has an svn r213507
>
> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507:
> Sun Oct 10 22:43:18 EEST 2010
> r...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64
>
> after upgrading to r213666 my system hangs after logging into gdm
>
> had to go back to r213507
> >>>
> >>> What video driver are you using?
> >>> -Garrett
> >>
> >> NVIDIA Driver Version: 260.19.06
> >>
> >> but Xorg successfully starts and GDM login screen appears
> >> system hangs after a few seconds after entering the password ...
> >> I noticed the following: gvfsd does not create a directory of the
> >> form / var/tmp/gvfs-- may hang system due to gvfsd?
>
> That seems a bit interesting.
> The other thing you can do is start running a binary search on the
> breakage because you have a range of good versions vs bad versions to
> look through.
>
> > If you can access the system remotely or quickly switch to console,
> > then you should be able to examine state of your system and get
> > some facts.
>
> If you have ddb compiled into the kernel (and you should) try
> CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead,
> which would require a serial connection (RS-232 or IEEE-1394).
> HTH,
> -Garrett
--I have updated the source code to r213666
--rebuilt and reinstall: world and kernel GENERIC
--reinstall nvidia driver with my patch:
#
--- src/nvidia_os.c.orig2010-09-15 01:26:27.0 +0300
+++ src/nvidia_os.c 2010-09-15 01:27:51.0 +0300
@@ -13,6 +13,67 @@
#include "nv.h"
#include "nv-freebsd.h"
+struct taskqueue {
+STAILQ_HEAD(, task) tq_queue;
+const char *tq_name;
+taskqueue_enqueue_fntq_enqueue;
+void*tq_context;
+struct task *tq_running;
+struct mtx tq_mutex;
+struct thread **tq_threads;
+int tq_tcount;
+int tq_spin;
+int tq_flags;
+};
+
+static void taskqueue_run(struct taskqueue *, struct task **);
+
+static __inline void
+TQ_LOCK(struct taskqueue *tq)
+{
+if (tq->tq_spin)
+ mtx_lock_spin(&tq->tq_mutex);
+else
+mtx_lock(&tq->tq_mutex);
+}
+
+static __inline void
+TQ_UNLOCK(struct taskqueue *tq)
+{
+ if (tq->tq_spin)
+ mtx_unlock_spin(&tq->tq_mutex);
+ else
+ mtx_unlock(&tq->tq_mutex);
+}
+
+static void
+taskqueue_run(struct taskqueue *queue, struct task **tpp)
+{
+ struct task *task;
+ int pending;
+
+ mtx_assert(&queue->tq_mutex, MA_OWNED);
+ while (STAILQ_FIRST(&queue->tq_queue)) {
+ /*
+ * Carefully remove the first task from the queue and
+ * zero its pending count.
+ */
+ task = STAILQ_FIRST(&queue->tq_queue);
+ STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link);
+ pending = task->ta_pending;
+ task->ta_pending = 0;
+ task->ta_running = tpp;
+ *tpp = task;
+ TQ_UNLOCK(queue);
+
+ task->ta_func(task->ta_context, pending);
+
+ TQ_LOCK(queue);
+ *tpp = NULL;
+ wakeup(task);
+ }
+}
+
MALLOC_DEFINE(M_NVIDIA, "nvidia", "NVIDIA memory allocations");
TASKQUEUE_DEFINE_THREAD(nvidia);
@@ -332,7 +393,8 @@
RM_STATUS NV_API_CALL os_flush_work_queue(void)
{
-taskqueue_run(taskqueue_nvidia);
+//taskqueue_run(taskqueue_nvidia);
+taskqueue_run(taskqueue_nvidia, &taskqueue_nvidia->tq_running);
return RM_OK;
}
#
--reboo
--authorization window will appear gdm
--i choose a user, enter a password and press "Enter"
--takes a few seconds and my system hangs
--I press CTRL + ALT + ESC, but nothing happens
:(
Here are some of the messages log at this loading:
Oct 12 01:06:57 nonamehost syslogd: kernel boot file is /boot/kernel/kernel
Oct 12 01:06:57 nonamehost kernel: Copyright (c) 1992-2010 The FreeBSD Project.
Oct 12 01:06:57 nonamehost kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994
Oct 12 01:06:57 nonamehost kernel: The Regents of the University of California.
All rights reserved.
Oct 12 01:06:57 nonamehost kernel: FreeBSD is a registered trademark of The
FreeBSD Foundation.
Oct 12 01:06:57 nonamehost kernel: FreeBSD 9.0-CURRENT #0 r213666: Tue Oct 12
00:23:58 EEST 2010
Oct 12 01:06:57 nonamehost kernel: i...@nonamehost:/usr/obj/usr/src/sys/GENERIC
amd64
Oct 12 01:06:57 nonamehost kernel: WARNING: WITNE
Re: system hangs after logging into gdm
on 12/10/2010 11:35 Ivan Klymenko said the following: > --i choose a user, enter a password and press "Enter" have you switched to text console after the above and before the next? > --takes a few seconds and my system hangs > --I press CTRL + ALT + ESC, but nothing happens You might want to add DEBUG_VFS_LOCKS. -- Andriy Gapon ___ 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: system hangs after logging into gdm
В Tue, 12 Oct 2010 11:51:05 +0300 Andriy Gapon пишет: > on 12/10/2010 11:35 Ivan Klymenko said the following: > > --i choose a user, enter a password and press "Enter" > > have you switched to text console after the above and before the next? After the system hangs - no after a reboot - yes - I went to the console and rebuilt world and kernel version r231507 again ... > > > --takes a few seconds and my system hangs > > --I press CTRL + ALT + ESC, but nothing happens > > You might want to add DEBUG_VFS_LOCKS. > Yes, I can, but this whole procedure takes me many hours ... I have FreeBSD - the only system on the PC and I need it in working order - I'm working on it Surely no one will be able to repeat my steps, that would verify this especially since I've written previously that the cause may be in the vfs ... ___ 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: system hangs after logging into gdm
on 12/10/2010 12:00 Ivan Klymenko said the following: > В Tue, 12 Oct 2010 11:51:05 +0300 > Andriy Gapon пишет: > >> on 12/10/2010 11:35 Ivan Klymenko said the following: >>> --i choose a user, enter a password and press "Enter" >> >> have you switched to text console after the above and before the next? > > After the system hangs - no I specifically asked if you switched to text console right after pressing Enter in the above step. Sorry if that was not clear. > after a reboot - yes - I went to the console and rebuilt world and kernel > version r231507 again ... > >> >>> --takes a few seconds and my system hangs >>> --I press CTRL + ALT + ESC, but nothing happens >> >> You might want to add DEBUG_VFS_LOCKS. >> > > Yes, I can, but this whole procedure takes me many hours ... > I have FreeBSD - the only system on the PC and I need it in working order - > I'm working on it > > Surely no one will be able to repeat my steps, that would verify this > especially since I've written previously that the cause may be in the vfs ... Not sure what your point is. So far you seem to be the only one who has the problem (or has reported it, at least). -- Andriy Gapon ___ 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: system hangs after logging into gdm
On Tue, Oct 12, 2010 at 2:04 AM, Andriy Gapon wrote: > on 12/10/2010 12:00 Ivan Klymenko said the following: >> В Tue, 12 Oct 2010 11:51:05 +0300 >> Andriy Gapon пишет: >> >>> on 12/10/2010 11:35 Ivan Klymenko said the following: --i choose a user, enter a password and press "Enter" >>> >>> have you switched to text console after the above and before the next? >> >> After the system hangs - no > > I specifically asked if you switched to text console right after pressing > Enter > in the above step. Sorry if that was not clear. > >> after a reboot - yes - I went to the console and rebuilt world and kernel >> version r231507 again ... >> >>> --takes a few seconds and my system hangs --I press CTRL + ALT + ESC, but nothing happens >>> >>> You might want to add DEBUG_VFS_LOCKS. >>> >> >> Yes, I can, but this whole procedure takes me many hours ... >> I have FreeBSD - the only system on the PC and I need it in working order - >> I'm working on it >> >> Surely no one will be able to repeat my steps, that would verify this >> especially since I've written previously that the cause may be in the vfs ... > > Not sure what your point is. > So far you seem to be the only one who has the problem (or has reported it, at > least). Could you try disabling some of your modules (fuse, nvidia, etc) in a stepwise manner? fuse is of particular interest for me to see whether or not it resolves the problem. Thanks, -Garrett ___ 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: system hangs after logging into gdm
В Tue, 12 Oct 2010 02:07:01 -0700 Garrett Cooper пишет: > On Tue, Oct 12, 2010 at 2:04 AM, Andriy Gapon wrote: > > on 12/10/2010 12:00 Ivan Klymenko said the following: > >> В Tue, 12 Oct 2010 11:51:05 +0300 > >> Andriy Gapon пишет: > >> > >>> on 12/10/2010 11:35 Ivan Klymenko said the following: > --i choose a user, enter a password and press "Enter" > >>> > >>> have you switched to text console after the above and before the > >>> next? > >> > >> After the system hangs - no > > > > I specifically asked if you switched to text console right after > > pressing Enter in the above step. Sorry if that was not clear. > > > >> after a reboot - yes - I went to the console and rebuilt world and > >> kernel version r231507 again ... > >> > >>> > --takes a few seconds and my system hangs > --I press CTRL + ALT + ESC, but nothing happens > >>> > >>> You might want to add DEBUG_VFS_LOCKS. > >>> > >> > >> Yes, I can, but this whole procedure takes me many hours ... > >> I have FreeBSD - the only system on the PC and I need it in > >> working order - I'm working on it > >> > >> Surely no one will be able to repeat my steps, that would verify > >> this especially since I've written previously that the cause may > >> be in the vfs ... > > > > Not sure what your point is. > > So far you seem to be the only one who has the problem (or has > > reported it, at least). > > Could you try disabling some of your modules (fuse, nvidia, etc) > in a stepwise manner? fuse is of particular interest for me to see > whether or not it resolves the problem. > Thanks, > -Garrett --I have updated the source code to r213666 --rebuilt and reinstall: ONLY kernel GENERIC + options DEBUG_VFS_LOCKS --i NOT reinstall nvidia driver with my patch... --i removed fusefs_enable="YES" in /etc/rc.conf http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: system hangs after logging into gdm
On Tue, Oct 12, 2010 at 4:51 AM, Ivan Klymenko wrote: > В Tue, 12 Oct 2010 02:07:01 -0700 > Garrett Cooper пишет: > >> On Tue, Oct 12, 2010 at 2:04 AM, Andriy Gapon wrote: >> > on 12/10/2010 12:00 Ivan Klymenko said the following: >> >> В Tue, 12 Oct 2010 11:51:05 +0300 >> >> Andriy Gapon пишет: >> >> >> >>> on 12/10/2010 11:35 Ivan Klymenko said the following: >> --i choose a user, enter a password and press "Enter" >> >>> >> >>> have you switched to text console after the above and before the >> >>> next? >> >> >> >> After the system hangs - no >> > >> > I specifically asked if you switched to text console right after >> > pressing Enter in the above step. Sorry if that was not clear. >> > >> >> after a reboot - yes - I went to the console and rebuilt world and >> >> kernel version r231507 again ... >> >> >> >>> >> --takes a few seconds and my system hangs >> --I press CTRL + ALT + ESC, but nothing happens >> >>> >> >>> You might want to add DEBUG_VFS_LOCKS. >> >>> >> >> >> >> Yes, I can, but this whole procedure takes me many hours ... >> >> I have FreeBSD - the only system on the PC and I need it in >> >> working order - I'm working on it >> >> >> >> Surely no one will be able to repeat my steps, that would verify >> >> this especially since I've written previously that the cause may >> >> be in the vfs ... >> > >> > Not sure what your point is. >> > So far you seem to be the only one who has the problem (or has >> > reported it, at least). >> >> Could you try disabling some of your modules (fuse, nvidia, etc) >> in a stepwise manner? fuse is of particular interest for me to see >> whether or not it resolves the problem. >> Thanks, >> -Garrett > > --I have updated the source code to r213666 > --rebuilt and reinstall: ONLY kernel GENERIC + options DEBUG_VFS_LOCKS > --i NOT reinstall nvidia driver with my patch... > --i removed fusefs_enable="YES" in /etc/rc.conf fusefs-kmod-0.3.9.p1.20080208_6 > > system booted fine and I successfully logged on to gdm! :) > > cause system hangs at the entrance to gdm was a module of the ports of fuse.ko Try recompiling the module and load it to see whether or not the module has been broken in your recent CURRENT update. Thanks! -Garrett ___ 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: letting glabel recognise a media change
on 11/10/2010 23:11 Pawel Jakub Dawidek said the following: > Right, but I still wonder if we could execute provider orphan and > retaste on various events like media insertion or removal. If media is I think nobody would disagree with that approach. The issue is to reliably detect those events without interfering with normal usage of the device. Not extremely hard to do, but still has to be done. > removed we orphan provider and recreate it, which will trigger retaste, > and this is fine there will be nothing to read from or write to (we will > simply return errors as we do now, I think). This way we nicely > co-operate with GEOM, but also with other tools that don't require media > to be present (if there is no media devfs entry still exists and handles > ioctls, it just return errors on read requests). > -- Andriy Gapon ___ 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: letting glabel recognise a media change
On Monday, October 11, 2010 4:11:56 pm Pawel Jakub Dawidek wrote: > On Mon, Oct 11, 2010 at 11:03:26AM -0400, John Baldwin wrote: > > With CD drives you are also rather stuck in that the existing ABI for > > controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) are > > done on the /dev/cdX device. Ideally enclosures for removable media would > > be separate devices from the removable media itself, but a lot of existing > > software for CD's would break if this changes now. > > Right, but I still wonder if we could execute provider orphan and > retaste on various events like media insertion or removal. If media is > removed we orphan provider and recreate it, which will trigger retaste, > and this is fine there will be nothing to read from or write to (we will > simply return errors as we do now, I think). This way we nicely > co-operate with GEOM, but also with other tools that don't require media > to be present (if there is no media devfs entry still exists and handles > ioctls, it just return errors on read requests). Oh, I would be fine with that. I was just explaining the legacy reasons for why we can't do the obvious thing and have separate devices for media and media holders. -- John Baldwin ___ 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
Good workaround, still a nasty surprising bug. 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 ___ 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: system hangs after logging into gdm [related but OFFTOPIC]
Try recompiling the module and load it to see whether or not the module has been broken in your recent CURRENT update. Thanks! I think fuse has many problems. I locks when being used by gvfs-fuse-daemon (which I may say is very useful as it avoids the task of manually mounting remote network places when using a non gio-aware application). I tried it with both stable and current, and both i386 and amd64. No luck. Is there any plan to port puffs to freebsd ? I read there was a google summer of code in 2009 to port it, but I'm unable to obtain any info. Best regards, Gus ___ 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" ___ 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 on kthread_exit under INVARIANTS
On 10/12/10, David Xu wrote: > Paul B Mahol wrote: >> Hi, >> >> If kernel threads were created via kproc_kthread_add() >> when last kernel thread exits it will trigger panic. >> >> It panics in queue.h probably introduced with rec > > > I have committed a patch, can you try it ? > http://svn.freebsd.org/changeset/base/213714 Yes, panic doesn't happen any more. ___ 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"
partition types 'freebsd-boot' and (g/ufs)labels
hi there, glabel seems to ignore IDs, if there are proper labels available. e.g. if a partition has a glabel or a ufs label the gptid or ufsid won't get displayed in 'glabel status'. however for partitions of the type 'freebsd-boot' this doesn't seem to be the case: Name Status Components label/boot N/A ada0p1 gptid/e52df583-e446-11de-bb92-000fb58207c8 N/A ada0p1 label/swap N/A ada0p2 ufs/rootfs N/A ada0p3 label/swapfs N/A ada1p1 ufs/varfs N/A ada1p2 ufs/usrfs N/A ada1p3 as you can see ada0p1 has a proper glabel in place, still in addition to that 'glabel status' shows its gptid. is this really necessary? cheers. alex -- a13x ___ 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: partition types 'freebsd-boot' and (g/ufs)labels
On Tue, Oct 12, 2010 at 9:24 PM, Alexander Best wrote: > > as you can see ada0p1 has a proper glabel in place, still in addition to that > 'glabel status' shows its gptid. is this really necessary? > I believe the gptid will only vanish if the partition in question is being used (mounted, part of geom or part of zpool) -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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: recent bge(4) changes causing problems
On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: > > Thanks for the info. I still suspect r213495 might break BCM5704. > Due to lack of BCM5704 I still couldn't test it except guessing. > How about attached one? > Index: sys/dev/bge/if_bge.c > === > --- sys/dev/bge/if_bge.c (revision 213711) > +++ sys/dev/bge/if_bge.c (working copy) > @@ -1736,7 +1736,8 @@ > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); > RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, > - BGE_RCB_FLAG_RING_DISABLED); > + BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, > + BGE_RCB_FLAG_RING_DISABLED)); > RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); > bge_writembx(sc, BGE_MBX_RX_CONS0_LO + > (i * (sizeof(uint64_t))), 0); Unfortunately, this patch does not fix the issue. If I revert r213495 via 'svn merge -r213495:213494 .' in the sys/dev/bge directory, I can build a working kernel. So, I can confirm that r213495 is the source of the problem with a BCM5704 based NIC. -- Steve ___ 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: OpenSSL 1.0
On Sat, Oct 09, 2010 at 11:37:49AM +0200, Roubíček Zdeněk wrote: > I would be also happy to see that coming as I have a problem using current > openssl as ipv6 client for tests, though it is bsd v7.3. > well, you always have security/openssl port. > Sorry for not providing anything more then just my wish. > > regards, zdenek > > From: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] > On Behalf Of Rui Paulo [rpa...@freebsd.org] > Sent: Friday, October 08, 2010 11:42 PM > To: Fabien Thomas > Cc: freebsd-current@freebsd.org > Subject: Re: OpenSSL 1.0 > > On 8 Oct 2010, at 12:40, Fabien Thomas wrote: > > > > > Is there any plan to import OpenSSL 1.0 into the tree? > > You should ask the maintainers. I suspect it's just a matter of available > time (for them). > > Regards, > -- > Rui Paulo > Buki -- PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net pgpjN0HeLUc8O.pgp Description: PGP signature
Re: OpenSSL 1.0
On 8 Oct 2010, at 13:40, Fabien Thomas wrote: > Is there any plan to import OpenSSL 1.0 into the tree? Hey, Yes, the current plan is to have it in 9.0, but when it will be imported I can't say yet as it depends on having a good continuos chunk of time, which I haven't had too much of lately. I had hoped to get around to looking at it during EuroBSDCon 2010, but I didn't. -- Simon L. B. Nielsen Hat: OpenSSL maintainer ___ 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: OpenSSL 1.0
On 9 Oct 2010, at 11:37, Roubíček Zdeněk wrote: > On 8 Oct 2010, at 12:40, Fabien Thomas wrote: > >> Is there any plan to import OpenSSL 1.0 into the tree? > I would be also happy to see that coming as I have a problem using current > openssl as ipv6 client for tests, though it is bsd v7.3. If you need a newer version of OpenSSL in FreeBSD 7 you should try the OpenSSL ports. FreeBSD 7 will probably get the latest 0.9.8 before FreeBSD 7.4, but it won't get OpenSSL 1.0 (and neither will FreeBSD 8 for that matter). -- Simon L. B. Nielsen Hat: OpenSSL maintainer ___ 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: letting glabel recognise a media change
On 10/10/2010, at 22.55, Alexander Motin wrote: > Pawel Jakub Dawidek wrote: >> On Thu, Sep 30, 2010 at 08:46:11PM +0300, Alexander Motin wrote: >>> Andriy Gapon wrote: on 30/09/2010 01:28 Matthew Jacob said the following: > If something like that was in place, I assure you that things would start > to use > it very quickly. I am not sure about this. Because, e.g. I don't see an easy way to know that media is changed in scsi_cd driver. That is, without polling. I don't consider polling to be an easy way for a number of reasons. >>> SATA specification defines concept of Asynchronous Notification. It is >>> already used by port multipliers to report about PHY events. It is also >>> supposed to be used by CD drives to report media change. I haven't seen >>> such devices yet, but hope they may appear sometimes. >>> >>> And even without AN support it would be nice to implement proper >>> handling for SCSI "UA - media changed" errors within CAM. It still won't >>> be perfect without using polling, but probably still something. >> >> I'd like to know the original reason why CD device is represented by >> GEOM provider and not CD media. For my naive thinking CD media should be >> GEOM provider that we taste once the media is inserted and orphan once >> the media is removed. I don't see any reasons for CD device to be useful >> GEOM provider, but maybe I'm overlooking something. >> >> Poul-Henning or Soren, do you remember who made and why this design choice? > > SCSI drivers receive no notification on media insertion. Somebody should > poll device. At this moment it is handled by consumers. Indeed not sure > it is the best idea. If we want driver to bother with this polling - we > may do as you propose. Actually in sdhci(4) driver I am doing this way - > mmcsdX device appears when card inserted and disappears on removal. > > I think first thing that may brake if there will be no cdX device - > loading the media with some commands. Also it may be non-intuitive that > drive is present, but disk is not registered in GEOM. Think burning data on empty media. -Søren "Any sufficiently advanced technology is indistinguishable from magic." -- ___ 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: system hangs after logging into gdm
> > --I have updated the source code to r213666 > > --rebuilt and reinstall: ONLY kernel GENERIC + options > > DEBUG_VFS_LOCKS --i NOT reinstall nvidia driver with my patch... > > --i removed fusefs_enable="YES" in /etc/rc.conf > fusefs-kmod-0.3.9.p1.20080208_6 > > > > system booted fine and I successfully logged on to gdm! :) > > > > cause system hangs at the entrance to gdm was a module of the ports > > of fuse.ko > > Try recompiling the module and load it to see whether or not the > module has been broken in your recent CURRENT update. > Thanks! > -Garrett I updated the kernel source code and the world to r213666 I rebuilt the port fusefs-kmod-0.3.9.p1.20080208_6 everything works fine! In fact, there is no problem! Thank you all! P.S. I am ashamed that I could not find the problem yourself, the more that once during the FreeBSD 5.4 I am on such a problem with fuse.ko already stumbled. : ( ___ 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: OpenSSL 1.0
> From: "Simon L. B. Nielsen" > Date: Mon, 11 Oct 2010 21:37:40 +0200 > Sender: owner-freebsd-curr...@freebsd.org > > On 9 Oct 2010, at 11:37, Roubíèek Zdenìk wrote: > > > On 8 Oct 2010, at 12:40, Fabien Thomas wrote: > > > >> Is there any plan to import OpenSSL 1.0 into the tree? > > I would be also happy to see that coming as I have a problem using > current openssl as ipv6 client for tests, though it is bsd v7.3. > > If you need a newer version of OpenSSL in FreeBSD 7 you should try the > OpenSSL ports. FreeBSD 7 will probably get the latest 0.9.8 before > FreeBSD 7.4, but it won't get OpenSSL 1.0 (and neither will FreeBSD 8 > for that matter). The problem is API differences. I hit ports which work with the port but fail with the base system and other ports that work with the base libssl but fail with the port installed. As a result, I have stuck with the base system. I've had to remove the port version a couple of times and rebuild all of the ports that had linked to it. A real pain. I understand why maintainers make some ports work with the old openssl in the base, but other don't and that road leads to madness. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: recent bge(4) changes causing problems
On Tue, Oct 12, 2010 at 08:24:40AM -0700, Steve Kargl wrote: > On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: > > > > Thanks for the info. I still suspect r213495 might break BCM5704. > > Due to lack of BCM5704 I still couldn't test it except guessing. > > How about attached one? > > > Index: sys/dev/bge/if_bge.c > > === > > --- sys/dev/bge/if_bge.c(revision 213711) > > +++ sys/dev/bge/if_bge.c(working copy) > > @@ -1736,7 +1736,8 @@ > > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); > > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); > > RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, > > - BGE_RCB_FLAG_RING_DISABLED); > > + BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, > > + BGE_RCB_FLAG_RING_DISABLED)); > > RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); > > bge_writembx(sc, BGE_MBX_RX_CONS0_LO + > > (i * (sizeof(uint64_t))), 0); > > Unfortunately, this patch does not fix the issue. > > If I revert r213495 via 'svn merge -r213495:213494 .' > in the sys/dev/bge directory, I can build a working > kernel. So, I can confirm that r213495 is the source > of the problem with a BCM5704 based NIC. > Fix committed to HEAD(r213742). ___ 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: recent bge(4) changes causing problems
On Tue, Oct 12, 2010 at 12:23 PM, Pyun YongHyeon wrote: > On Tue, Oct 12, 2010 at 08:24:40AM -0700, Steve Kargl wrote: >> On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: >> > >> > Thanks for the info. I still suspect r213495 might break BCM5704. >> > Due to lack of BCM5704 I still couldn't test it except guessing. >> > How about attached one? >> >> > Index: sys/dev/bge/if_bge.c >> > === >> > --- sys/dev/bge/if_bge.c (revision 213711) >> > +++ sys/dev/bge/if_bge.c (working copy) >> > @@ -1736,7 +1736,8 @@ >> > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); >> > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); >> > RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, >> > - BGE_RCB_FLAG_RING_DISABLED); >> > + BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, >> > + BGE_RCB_FLAG_RING_DISABLED)); >> > RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); >> > bge_writembx(sc, BGE_MBX_RX_CONS0_LO + >> > (i * (sizeof(uint64_t))), 0); >> >> Unfortunately, this patch does not fix the issue. >> >> If I revert r213495 via 'svn merge -r213495:213494 .' >> in the sys/dev/bge directory, I can build a working >> kernel. So, I can confirm that r213495 is the source >> of the problem with a BCM5704 based NIC. >> > > Fix committed to HEAD(r213742). Could this be a firmware bug? A similar issue has occurred in the past with bce(4) where you have to upgrade the firmware and the driver in tandem in order for things to function properly, so maybe if the firmware was upgraded to the latest version (unfortunately only Linux methods exist I think), this issue would go away? Thanks, -Garrett ___ 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: recent bge(4) changes causing problems
On Tue, Oct 12, 2010 at 01:11:29PM -0700, Garrett Cooper wrote: > On Tue, Oct 12, 2010 at 12:23 PM, Pyun YongHyeon wrote: > > On Tue, Oct 12, 2010 at 08:24:40AM -0700, Steve Kargl wrote: > >> On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: > >> > > >> > Thanks for the info. I still suspect r213495 might break BCM5704. > >> > Due to lack of BCM5704 I still couldn't test it except guessing. > >> > How about attached one? > >> > >> > Index: sys/dev/bge/if_bge.c > >> > === > >> > --- sys/dev/bge/if_bge.c ? ?(revision 213711) > >> > +++ sys/dev/bge/if_bge.c ? ?(working copy) > >> > @@ -1736,7 +1736,8 @@ > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, > >> > - ? ? ? ? ? ? ? BGE_RCB_FLAG_RING_DISABLED); > >> > + ? ? ? ? ? ? ? BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, > >> > + ? ? ? ? ? ? ? BGE_RCB_FLAG_RING_DISABLED)); > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); > >> > ? ? ? ? ? ? bge_writembx(sc, BGE_MBX_RX_CONS0_LO + > >> > ? ? ? ? ? ? ? ? (i * (sizeof(uint64_t))), 0); > >> > >> Unfortunately, this patch does not fix the issue. > >> > >> If I revert r213495 via 'svn merge -r213495:213494 .' > >> in the sys/dev/bge directory, I can build a working > >> kernel. ?So, I can confirm that r213495 is the source > >> of the problem with a BCM5704 based NIC. > >> > > > > Fix committed to HEAD(r213742). > > Could this be a firmware bug? A similar issue has occurred in the > past with bce(4) where you have to upgrade the firmware and the driver > in tandem in order for things to function properly, so maybe if the > firmware was upgraded to the latest version (unfortunately only Linux > methods exist I think), this issue would go away? Not sure whether this is firmware related thing or not. Public data sheet explicitly says that BCM5700 with external SSRAM is the only controller that supports mini ring. So r213475 disabled mini ring for BCM5700 only. Data sheet also says disabling mini ring for all BCM570[0-4] controllers is optional one in its initialization. However that was not true and all BCM570[0-4] seems to require disabling mini ring. > Thanks, > -Garrett ___ 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 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. P.S. Matthew, it seems like you have a really unhelpful mail client program: first, it top-posts :-) second, it doesn't always attribute quoted text. It also doesn't cc in replies the addresses that were in to or cc of original message, which may or may not be a good thing. >> 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 -- Andriy Gapon ___ 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
I am antisocial. Okay, changed it so my replies are above the quotes. Seems to have attributes here. And I usually hit 'reply list' since multiple copies burns bandwidth. On 10/12/2010 1:57 PM, Andriy Gapon wrote: P.S. Matthew, it seems like you have a really unhelpful mail client program: first, it top-posts :-) second, it doesn't always attribute quoted text. It also doesn't cc in replies the addresses that were in to or cc of original message, which may or may not be a good thing. ___ 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: partition types 'freebsd-boot' and (g/ufs)labels
On Tue Oct 12 10, Edho P Arief wrote: > On Tue, Oct 12, 2010 at 9:24 PM, Alexander Best wrote: > > > > as you can see ada0p1 has a proper glabel in place, still in addition to > > that > > 'glabel status' shows its gptid. is this really necessary? > > > > I believe the gptid will only vanish if the partition in question is > being used (mounted, part of geom or part of zpool) thank you very much for the hint. that sounds very reasonable. cheers, alex > > -- > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- a13x ___ 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"
