Re: fusefs-kmod broken?
On Monday 23 August 2010 10:57:40 Ian FREISLICH wrote: > Ian FREISLICH wrote: > > So, in this case is the fusefs module broken? I'm guessing it is. > > I don't like the way fuse_fileops is initialised in fuse4bsd. I > > would prefer for the struct to be zeroed and then the fo_xxx > > implimented bits set as appropriate. That way when the struct is > > changed, you don't get stung again. > > I am an idiot - that will have no effect. This patch needs to be > included in sysutils/fusefs-kmod/files Would you file a PR with the patch accounting for the correct __FreeBSD_version__? Thanks, -- Anish Mistry signature.asc Description: This is a digitally signed message part.
Re: fusefs-kmod broken?
Ian FREISLICH wrote:
> So, in this case is the fusefs module broken? I'm guessing it is.
> I don't like the way fuse_fileops is initialised in fuse4bsd. I
> would prefer for the struct to be zeroed and then the fo_xxx
> implimented bits set as appropriate. That way when the struct is
> changed, you don't get stung again.
I am an idiot - that will have no effect. This patch needs to be
included in sysutils/fusefs-kmod/files
--
Ian Freislich
patch-fuse_module__fuse_main.c
--- fuse_module/fuse_main.c.orig2010-08-23 16:52:20.0 +0200
+++ fuse_module/fuse_main.c 2010-08-23 16:48:17.0 +0200
@@ -108,6 +108,7 @@
switch (what) {
case MOD_LOAD:/* kldload */
+ fuse_fileops.fo_truncate = vnops.fo_truncate;
fuse_fileops.fo_ioctl= vnops.fo_ioctl;
fuse_fileops.fo_poll = vnops.fo_poll;
fuse_fileops.fo_kqfilter = vnops.fo_kqfilter;
___
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: fusefs-kmod broken?
On Mon, Aug 23, 2010 at 04:32:58PM +0200, Ian FREISLICH wrote: > Kostik Belousov wrote: > > > > --7hK5U8dVDlZxii7z > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote: > > > * Kostik Belousov wrote: > > > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > > > > * Kostik Belousov wrote: > > > > > > Which most likely means that fusesfs filled its own struct fileops > > > > > > without properly initializing fo_truncate member. > > > > >=20 > > > > > It's a bit misleading that cdevs automatically patch the table, while > > > > > the fileops don't. Maybe it would be a good idea to patch finit() to > > > > I do not understand your first sentence. Would you please elaborate ? > > >=20 > > > Say, you create a cdev, if you don't implement all ops, it will check > > > for null pointers and return error codes accordingly. This doesn't > > > happen for fileops, which is probably one of the reasons why people > > > sometimes forget to implement them. > > >=20 > > > Wouldn't it be better to prevent this form of footshooting by adding > > > assertions? This will add some overhead for any file descriptor created, > > > but a kernel with INVARIANTS isn't meant to be fast. > > Thanks, I see it now. > > > > The cdev interface definitely falls into the public kernel interface. > > Having to fill all cdevsw methods for a random driver is too much > > burden put on the several dozens maintainers. > > > > On the other hand, file level is not much widely used by third-party > > components, and even in-tree code implements only ten different file > > types. > > > > I would not object loudly if someone put such checks as proposed > > under INVARIANTS, but also I do not see a real point in having them. > > Might be slightly better to put the checks, again under INVARIANTS, > > in the fo_XXX() wrappers. > > So, in this case is the fusefs module broken? I'm guessing it is. > I don't like the way fuse_fileops is initialised in fuse4bsd. I > would prefer for the struct to be zeroed and then the fo_xxx > implimented bits set as appropriate. That way when the struct is > changed, you don't get stung again. > > Patch attached to that makes fusefs-kmod not blowup kernels post this change. > > Ian > > -- > Ian Freislich > > Index: files/patch-fuse_module__fuse_vnops.c > === > RCS file: > /home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_vnops.c,v > retrieving revision 1.4 > diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c > --- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 - > 1.4 > +++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 - > +@@ -214,6 +214,7 @@ > + * following fields are filled from vnops, but "vnops.foo" is not > + * legitimate in a definition, so we set them at module load time > + */ > ++.fo_truncate = NULL, > + .fo_ioctl= NULL, > + .fo_poll = NULL, > + .fo_kqfilter = NULL, Did you tested this ? I suppose that it would not change anything. Fuse, most likely, lacks real implementation of .fo_truncate method. The implementation was required for long time, otherwise file truncation would not work. pgp6NZTNqf4rm.pgp Description: PGP signature
Re: fusefs-kmod broken?
Kostik Belousov wrote:
>
> --7hK5U8dVDlZxii7z
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote:
> > * Kostik Belousov wrote:
> > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
> > > > * Kostik Belousov wrote:
> > > > > Which most likely means that fusesfs filled its own struct fileops
> > > > > without properly initializing fo_truncate member.
> > > >=20
> > > > It's a bit misleading that cdevs automatically patch the table, while
> > > > the fileops don't. Maybe it would be a good idea to patch finit() to
> > > I do not understand your first sentence. Would you please elaborate ?
> >=20
> > Say, you create a cdev, if you don't implement all ops, it will check
> > for null pointers and return error codes accordingly. This doesn't
> > happen for fileops, which is probably one of the reasons why people
> > sometimes forget to implement them.
> >=20
> > Wouldn't it be better to prevent this form of footshooting by adding
> > assertions? This will add some overhead for any file descriptor created,
> > but a kernel with INVARIANTS isn't meant to be fast.
> Thanks, I see it now.
>
> The cdev interface definitely falls into the public kernel interface.
> Having to fill all cdevsw methods for a random driver is too much
> burden put on the several dozens maintainers.
>
> On the other hand, file level is not much widely used by third-party
> components, and even in-tree code implements only ten different file
> types.
>
> I would not object loudly if someone put such checks as proposed
> under INVARIANTS, but also I do not see a real point in having them.
> Might be slightly better to put the checks, again under INVARIANTS,
> in the fo_XXX() wrappers.
So, in this case is the fusefs module broken? I'm guessing it is.
I don't like the way fuse_fileops is initialised in fuse4bsd. I
would prefer for the struct to be zeroed and then the fo_xxx
implimented bits set as appropriate. That way when the struct is
changed, you don't get stung again.
Patch attached to that makes fusefs-kmod not blowup kernels post this change.
Ian
--
Ian Freislich
Index: files/patch-fuse_module__fuse_vnops.c
===
RCS file:
/home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_vnops.c,v
retrieving revision 1.4
diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c
--- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 -
1.4
+++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 -
+@@ -214,6 +214,7 @@
+ * following fields are filled from vnops, but "vnops.foo" is not
+ * legitimate in a definition, so we set them at module load time
+*/
++ .fo_truncate = NULL,
+ .fo_ioctl= NULL,
+ .fo_poll = NULL,
+ .fo_kqfilter = NULL,
+@@ -799,8 +800,11 @@
struct vnode *vp = ap->a_vp;
struct vattr *vap = ap->a_vap;
struct ucred *cred = ap->a_cred;
@@ -13,7 +21,7 @@
struct fuse_dispatcher fdi;
struct timespec uptsp;
int err = 0;
-@@ -871,7 +874,11 @@
+@@ -871,7 +875,11 @@
fuse_access(ap)
struct vop_access_args /* {
struct vnode *a_vp;
@@ -25,7 +33,7 @@
struct ucred *a_cred;
struct thread *a_td;
} */ *ap;
-@@ -886,7 +893,13 @@
+@@ -886,7 +894,13 @@
else
facp.facc_flags |= FACCESS_DO_ACCESS;
@@ -40,7 +48,7 @@
}
/*
-@@ -946,7 +959,11 @@
+@@ -946,7 +960,11 @@
/* We are to do the check in-kernel */
if (! (facp->facc_flags & FACCESS_VA_VALID)) {
@@ -53,7 +61,7 @@
if (err)
return (err);
facp->facc_flags |= FACCESS_VA_VALID;
-@@ -1929,7 +1946,11 @@
+@@ -1929,7 +1947,11 @@
* It will not invalidate pages which are dirty, locked, under
* writeback or mapped into pagetables.")
*/
@@ -65,7 +73,7 @@
fufh->flags |= FOPEN_KEEP_CACHE;
}
-@@ -3005,8 +3026,11 @@
+@@ -3005,8 +3027,11 @@
struct vattr *vap = ap->a_vap;
struct vnode *vp = ap->a_vp;
struct ucred *cred = ap->a_cred;
___
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: fusefs-kmod broken?
* Kostik Belousov wrote: > I would not object loudly if someone put such checks as proposed > under INVARIANTS, but also I do not see a real point in having them. > Might be slightly better to put the checks, again under INVARIANTS, > in the fo_XXX() wrappers. Well, the entire point is to put them in finit(), because that way you as a programmer will get punished as soon as possible, namely when you implement the new type of file descriptor. Putting them in the fo_XXX() wrappers makes little sense, because that will only cause a panic 1 microsecond before it would have crashed on the null pointer anyway. -- Ed Schouten WWW: http://80386.nl/ pgpZiWUF2pFRF.pgp Description: PGP signature
Re: fusefs-kmod broken?
On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote: > * Kostik Belousov wrote: > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > > * Kostik Belousov wrote: > > > > Which most likely means that fusesfs filled its own struct fileops > > > > without properly initializing fo_truncate member. > > > > > > It's a bit misleading that cdevs automatically patch the table, while > > > the fileops don't. Maybe it would be a good idea to patch finit() to > > I do not understand your first sentence. Would you please elaborate ? > > Say, you create a cdev, if you don't implement all ops, it will check > for null pointers and return error codes accordingly. This doesn't > happen for fileops, which is probably one of the reasons why people > sometimes forget to implement them. > > Wouldn't it be better to prevent this form of footshooting by adding > assertions? This will add some overhead for any file descriptor created, > but a kernel with INVARIANTS isn't meant to be fast. Thanks, I see it now. The cdev interface definitely falls into the public kernel interface. Having to fill all cdevsw methods for a random driver is too much burden put on the several dozens maintainers. On the other hand, file level is not much widely used by third-party components, and even in-tree code implements only ten different file types. I would not object loudly if someone put such checks as proposed under INVARIANTS, but also I do not see a real point in having them. Might be slightly better to put the checks, again under INVARIANTS, in the fo_XXX() wrappers. pgp3IhHedgsuI.pgp Description: PGP signature
Re: fusefs-kmod broken?
* Kostik Belousov wrote: > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > * Kostik Belousov wrote: > > > Which most likely means that fusesfs filled its own struct fileops > > > without properly initializing fo_truncate member. > > > > It's a bit misleading that cdevs automatically patch the table, while > > the fileops don't. Maybe it would be a good idea to patch finit() to > I do not understand your first sentence. Would you please elaborate ? Say, you create a cdev, if you don't implement all ops, it will check for null pointers and return error codes accordingly. This doesn't happen for fileops, which is probably one of the reasons why people sometimes forget to implement them. Wouldn't it be better to prevent this form of footshooting by adding assertions? This will add some overhead for any file descriptor created, but a kernel with INVARIANTS isn't meant to be fast. -- Ed Schouten WWW: http://80386.nl/ pgpM8zdFvppwk.pgp Description: PGP signature
Re: fusefs-kmod broken?
On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > * Kostik Belousov wrote: > > Which most likely means that fusesfs filled its own struct fileops > > without properly initializing fo_truncate member. > > It's a bit misleading that cdevs automatically patch the table, while > the fileops don't. Maybe it would be a good idea to patch finit() to I do not understand your first sentence. Would you please elaborate ? > check whether under INVARIATIONS all fileops are set? > > -- > Ed Schouten > WWW: http://80386.nl/ pgpgzReOqeOyy.pgp Description: PGP signature
Re: fusefs-kmod broken?
* Ed Schouten wrote: > check whether under INVARIATIONS all fileops are set? INVARIANTS, that is. -- Ed Schouten WWW: http://80386.nl/ pgp0MtaoWCOzp.pgp Description: PGP signature
Re: fusefs-kmod broken?
* Kostik Belousov wrote: > Which most likely means that fusesfs filled its own struct fileops > without properly initializing fo_truncate member. It's a bit misleading that cdevs automatically patch the table, while the fileops don't. Maybe it would be a good idea to patch finit() to check whether under INVARIATIONS all fileops are set? -- Ed Schouten WWW: http://80386.nl/ pgprc8w11HVSV.pgp Description: PGP signature
Re: fusefs-kmod broken?
Ian FREISLICH wrote:
> John Baldwin wrote:
> > The uart thing is a red herring, notice the actual PC value is '0'. Someth
ing
> > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35'
in
> > kgdb would be a good start of where to look.
>
> (kgdb) l *kern_open+0x35
> 0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040).
> 1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int fl
ags,
> 1036int mode)
> 1037{
> 1038
> 1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode)
);
> 1040}
> 1041
> 1042int
> 1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg paths
eg,
> 1044int flags, int mode)
>
> That's what my reading seemed indicate. I had to downgrade the
> system back to 8.0-STABLE at around 21 April 2010, to get the system
> working.
>
> I'm currently doing a binary search to find offending commit, since
> CURRENT and STABLE panic reliably, and in the same way I'm sure
> that the problem is common to both.
>
> I'm down to a window of 9 hours. My money is currently on:
>
> Working file: sys/kern/vfs_syscalls.c
> Approved by:re (bz)
>
> revision 1.487.2.7
> date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
> SVN rev 207270 on 2010-04-27 10:47:54Z by kib
>
> MFC r206547:
> Handle a case in kern_openat() when vn_open() change file type from
> DTYPE_VNODE.
>
Confirmed.
1.487.2.6 doesn't panic, 1.487.2.7 does. This is the change that
results in the panic.
--- sys/kern/vfs_syscalls.c 16 Apr 2010 08:32:08 - 1.487.2.6
+++ sys/kern/vfs_syscalls.c 27 Apr 2010 10:47:54 - 1.487.2.7
@@ -35,7 +35,7 @@
*/
#include
-__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.6 2010/04/16
08:32:08 kib Exp $");
+__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.7 2010/04/27
10:47:54 kib Exp $");
#include "opt_compat.h"
#include "opt_kdtrace.h"
@@ -1047,8 +1047,6 @@
struct filedesc *fdp = p->p_fd;
struct file *fp;
struct vnode *vp;
- struct vattr vat;
- struct mount *mp;
int cmode;
struct file *nfp;
int type, indx, error;
@@ -1141,7 +1139,7 @@
}
VOP_UNLOCK(vp, 0);
- if (flags & (O_EXLOCK | O_SHLOCK)) {
+ if (fp->f_type == DTYPE_VNODE && (flags & (O_EXLOCK | O_SHLOCK)) != 0) {
lf.l_whence = SEEK_SET;
lf.l_start = 0;
lf.l_len = 0;
@@ -1158,18 +1156,7 @@
atomic_set_int(&fp->f_flag, FHASLOCK);
}
if (flags & O_TRUNC) {
- if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0)
- goto bad;
- VATTR_NULL(&vat);
- vat.va_size = 0;
- vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
-#ifdef MAC
- error = mac_vnode_check_write(td->td_ucred, fp->f_cred, vp);
- if (error == 0)
-#endif
- error = VOP_SETATTR(vp, &vat, td->td_ucred);
- VOP_UNLOCK(vp, 0);
- vn_finished_write(mp);
+ error = fo_truncate(fp, 0, td->td_ucred, td);
if (error)
goto bad;
}
mount:
/dev/fuse0 on /1-wire (fusefs, local, synchronous)
Something about it has a write
echo -n 192 > /1-wire/29.A52A0300/PIO.BYTE
Panic. But not like:
echo -n 192 >> /1-wire/29.A52A0300/PIO.BYTE
I suspect the truncate is not safe. Or, at least this fuse presented
fite cannot be truncated.
Ian
--
Ian Freislich
___
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: fusefs-kmod broken?
On Mon, Aug 23, 2010 at 02:58:59PM +0200, Ian FREISLICH wrote:
> John Baldwin wrote:
> > The uart thing is a red herring, notice the actual PC value is '0'.
> > Something
> > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35'
> > in
> > kgdb would be a good start of where to look.
>
> (kgdb) l *kern_open+0x35
> 0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040).
> 1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int
> flags,
> 1036int mode)
> 1037{
> 1038
> 1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags,
> mode));
> 1040}
> 1041
> 1042int
> 1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg
> pathseg,
> 1044int flags, int mode)
>
> That's what my reading seemed indicate. I had to downgrade the
> system back to 8.0-STABLE at around 21 April 2010, to get the system
> working.
>
> I'm currently doing a binary search to find offending commit, since
> CURRENT and STABLE panic reliably, and in the same way I'm sure
> that the problem is common to both.
>
> I'm down to a window of 9 hours. My money is currently on:
>
> Working file: sys/kern/vfs_syscalls.c
> Approved by:re (bz)
>
> revision 1.487.2.7
> date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
> SVN rev 207270 on 2010-04-27 10:47:54Z by kib
>
> MFC r206547:
> Handle a case in kern_openat() when vn_open() change file type from
> DTYPE_VNODE.
>
Which most likely means that fusesfs filled its own struct fileops
without properly initializing fo_truncate member.
pgpD99OIXMmOv.pgp
Description: PGP signature
Re: fusefs-kmod broken?
John Baldwin wrote:
> The uart thing is a red herring, notice the actual PC value is '0'. Something
> in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in
> kgdb would be a good start of where to look.
(kgdb) l *kern_open+0x35
0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040).
1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int
flags,
1036int mode)
1037{
1038
1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode));
1040}
1041
1042int
1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg pathseg,
1044int flags, int mode)
That's what my reading seemed indicate. I had to downgrade the
system back to 8.0-STABLE at around 21 April 2010, to get the system
working.
I'm currently doing a binary search to find offending commit, since
CURRENT and STABLE panic reliably, and in the same way I'm sure
that the problem is common to both.
I'm down to a window of 9 hours. My money is currently on:
Working file: sys/kern/vfs_syscalls.c
Approved by:re (bz)
revision 1.487.2.7
date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
SVN rev 207270 on 2010-04-27 10:47:54Z by kib
MFC r206547:
Handle a case in kern_openat() when vn_open() change file type from
DTYPE_VNODE.
Ian
--
Ian Freislich
___
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: fusefs-kmod broken?
On Friday, August 20, 2010 12:11:00 pm Ian FREISLICH wrote: > Hi > > I have a system that relies on Fuse and OWFS to manage the power > at my house. I get the following panic when writing to to one of > the PIO devices: > > The panic isn't really helpful because it looks like the stack frame > has been broken. > > Have others seen this? I've tried rebuilding everything from a > clean slate but it doesn't help. The machine used to be -STABLE, > which worked until 21 April 2010, but no kernel since has worked. > > brane.freislich.nom.za dumped core - see /var/crash/vmcore.7 > > Fri Aug 20 16:07:17 SAST 2010 > > FreeBSD brane.freislich.nom.za 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Fri Aug 20 > 13:53:55 SAST 2010 i...@brane.freislich.nom.za:/usr/obj/usr/src/sys/BRANE i386 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code= supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xe75d3b50 > frame pointer = 0x28:0xe75d3c14 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 56578 (sh) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at > kdb_backtrace+0x29 > panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf > trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 > trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b > trap(e75d3b10) at trap+0x423 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- > uart_z8530_class(c784ab00,ff9c,284052c4,0,402,...) at 0 > kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 > open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 > syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at syscallenter+0x343 > syscall(e75d3d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, ebp > = 0xbfbfea28 --- > Uptime: 1h49m31s > Physical memory: 2007 MB > Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 The uart thing is a red herring, notice the actual PC value is '0'. Something in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in kgdb would be a good start of where to look. -- 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: fusefs-kmod broken?
Hans Petter Selasky wrote:
> Do you have all the drivers you need in the kernel?
>
> ./uart/uart.h:extern struct uart_class uart_z8530_class __attribute__((weak))
;
> ./uart/uart_bus_scc.c: sc->sc_class = &uart_z8530_class;
> ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class;
> ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class;
> ./uart/uart_cpu_sparc64.c: class = &uart_z8530_class;
> ./uart/uart_dev_z8530.c:struct uart_class uart_z8530_class = {
> ./uart/uart_subr.c: &uart_z8530_class,
What drivers do you sugest? These are what's configured.
device ucom
device uplcom
device uart# 8250, 16[45]50 based serial ports
device puc
The 2 DS2480 (1-wire bus masters) are on 2 PL2303 usb serial ports.
Reading the devices works fine:
[brane] /1-wire # ls
10.0ADC53010800 10.AB2D4C010800 26.1D82B500 bus.0 structure
10.174637010800 10.BD4437010800 26.2882B500 bus.1 system
10.19D24C010800 10.E32C4C010800 29.83290300 settingsuncached
10.4A6237010800 1D.33F00D00 29.A52A0300 simultaneous
10.725A4C010800 1D.6A560B00 alarm statistics
[brane] /1-wire # cat 10.0ADC53010800/temperature
22.1875
It's writing to the 29.A52A0300 or 29.83290300 PIO registers
that results in the panic.
[brane] /1-wire # ls 29.A52A0300
LCD_H PIO.ALL latch.4 r_address sensed.7
LCD_M PIO.BYTElatch.5 r_idsensed.ALL
PIO.0 address latch.6 r_locator sensed.BYTE
PIO.1 crc8latch.7 sensed.0set_alarm
PIO.2 family latch.ALL sensed.1strobe
PIO.3 id latch.BYTE sensed.2type
PIO.4 latch.0 locator sensed.3
PIO.5 latch.1 por sensed.4
PIO.6 latch.2 power sensed.5
PIO.7 latch.3 present sensed.6
Ian
--
Ian Freislich
___
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"
