Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?

2003-11-08 Thread David Taylor
On Thu, 06 Nov 2003, Aditya wrote:
 On Thu, Nov 06, 2003 at 03:29:21PM -0800, Kris Kennaway wrote:
  On Thu, Nov 06, 2003 at 01:43:43PM -0800, Aditya wrote:
  
 debug1: Connections to local port 8000 forwarded to remote address
 www.freebsd.org:80
 debug1: Local forwarding listening on 127.0.0.1 port 8000.
 bind: Can't assign requested address
 channel_setup_fwd_listener: cannot listen to port: 8000
 Could not request local forwarding.
   
   and I can't see any reason why the binding would fail:
  
  Is something else (e.g. another ssh session) already bound to that port?
 
 nope -- and I've tried all sorts of ports other than 8000 too:

(I'm assuming you do have a lo0 device with 127.0.0.1)

Have you tried binding it to the address on the interface which
your host will send packets to the remote host over?

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?

2003-11-08 Thread David Taylor
On Sat, 08 Nov 2003, David Taylor wrote:
 
 Have you tried binding it to the address on the interface which
 your host will send packets to the remote host over?

Erm, wait, I don't know what I was thinking there.  ssh doesn't let you
specify the local address it binds to.  All I can say is it works here...

However, changing the address on lo0 to 10.9.9.9 results in:

debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 8000.
bind: Can't assign requested address

But:

# ifconfig lo0 inet 127.0.0.1
$ ssh -L8000:www.freebsd.org:80 [host]

gives

[snip]
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 8000.
debug1: fd 5 setting O_NONBLOCK
debug2: fd 5 is O_NONBLOCK
debug1: channel 1: new [port listener]

So, it could be an idea to check the output of ifconfig lo0.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: problems with sysinstall

2003-11-01 Thread David Taylor
On Wed, 29 Oct 2003, Doug White wrote:
 On Wed, 29 Oct 2003, Sergey Matveychuk wrote:
 Doug White wrote:
 This is normal and for your protection. you can't edit the disk you're
 running off of.  If you are running off of ad1, make sure 1) you're root
 when you run sysinstall and b) you aren't mounting any filesystems from
 ad0.

 Well, I understand it for slices. But why I can't create new partition
 in exist slice and newfs it? It was OK in -stable.
 
 yes, this is a change to -current. It is for your own safety.

My own safety?  I can down the system in a million ways, yet can't do
what I actually want?  A major reason I got fed up with Windows (other
than it not working right) was it's insistance of knowing what was best
for me.  I hope FreeBSD doesn't fall down the same path.

Or at least have a kernel option FOOT_SHOOTING, or something, that will
disable all the helpful code protection people from themselves.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Status of SCHED_ULE?

2003-09-30 Thread David Taylor
On Mon, 29 Sep 2003, Jeff Roberson wrote:
 Are you running seti, rc4, etc?  Any programs that sit in the background
 and consume 100% of the cpu?
 

I'm running KDE (using libc_r), and run setiathome and/or dnetc in the
background.  I've also tried killing the background tasks, but it makes
little difference.  I also use moused and /dev/sysmouse for X.  I've even
tried renicing moused to negative nice values, and that doesn't change
much either.

The mouse gets 'sticky' under moderate/heavy load, as other people have
described.  I haven't swapped back to SCHED_4BSD recently to compare, but
I'm sure it was smoother before I switched.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nvidia.ko freezes system in -current

2003-08-28 Thread David Taylor
On Thu, 28 Aug 2003, Christoph Kukulies wrote:
 I cvsuped world and kernel today, built world, installed world,
 did a reinstall (with compilation) of the nvidia module 1.0-4365
 and the kernel module loads fine but when I startx I get
 a few screen flashes and the reboot.
 
 I have agp_load=YES in loader.conf (as I had before).
 I did not choose WITH_FREBSD_AGP as the port makefile
 gives as option.
 
 Need urgent help since I did this (boo boo) on a production server
 Well the server runs (httpd) but I have no X at the moment and
 I cannot afford frequent compiles and reboots at the moment.

You should try either:

A)
comment out agp_load=YES
compile nvidia-driver without WITH_FREEBSD_AGP

or

B)
leave agp_loadYES
compile nvidia-driver with WITH_FREEBSD_AGP

I used to run WITH_FREEBSD_AGP / agp_load=YES (because it was unstable
otherwise), but recently cvsuped to -CURRENT, and discovered that the
opposite was now more stable (WITH_FREEBSD_AGP/agp_load=YES now causes
my computer to lockup regularly when in X).

I suggest you try the opposite setting and see if that helps.  Also keep
WITH_FREEBSD_AGP and agp_load in 'sync'.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Fatal trap 12: page fault while in kernel mode with latest-CURRENT

2003-08-14 Thread David Taylor
I've been getting this occasionally (a few times a day) since I upgraded
to -CURRENT yesterday.  I tried installing Bosko's Intel Data Corruption
patch today, to see if that changed anything, but it doesn't appear to
have worked.

I've currently only got access to one dump, as I changed my kernel earlier
today, but if it crashes again I'll add any more information I can get.

Here's the panic message/backtrace:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2006218
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0572ac6
stack pointer   = 0x10:0xd56bc904
frame pointer   = 0x10:0xd56bc91c
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 = 1138 (mutt)
Dumping 256 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224[CTRL-C to abort]  240
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc0452bb5 in db_fncall (dummy1=0x0, dummy2=0x0, dummy3=0x0,
dummy4=0xd56bc6f8 \200\026sÀ\f) at /usr/src/sys/ddb/db_command.c:548
#2  0xc0452902 in db_command (last_cmdp=0xc0730d20, cmd_table=0x0,
aux_cmd_tablep=0xc06e43c0, aux_cmd_tablep_end=0xc06e43c4)
at /usr/src/sys/ddb/db_command.c:346
#3  0xc0452a45 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#4  0xc0455a45 in db_trap (type=0xc, code=0x0) at /usr/src/sys/ddb/db_trap.c:73
#5  0xc067719c in kdb_trap (type=0xc, code=0x0, regs=0xd56bc8c4)
at /usr/src/sys/i386/i386/db_interface.c:172
#6  0xc0688826 in trap_fatal (frame=0xd56bc8c4, eva=0x0)
at /usr/src/sys/i386/i386/trap.c:816
#7  0xc06884f2 in trap_pfault (frame=0xd56bc8c4, usermode=0x0,
eva=0x2006218)
at /usr/src/sys/i386/i386/trap.c:735
#8  0xc06880ad in trap (frame=
  {tf_fs = 0x18, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0xd56bcc00, tf_esi = 
0xc497eb68, tf_ebp = 0xd56bc91c, tf_isp = 0xd56bc8f0, tf_ebx = 0x2006200, tf_edx = 
0x4806, tf_ecx = 0xc497ec64, tf_eax = 0xc42bb000, tf_trapno = 0xc, tf_err = 0x0, 
tf_eip = 0xc0572ac6, tf_cs = 0x8, tf_eflags = 0x10206, tf_esp = 0xc497eb68, tf_ss = 
0xc497eb68}) at /usr/src/sys/i386/i386/trap.c:420
#9  0xc0678b48 in calltrap () at {standard input}:102
#10 0xc0573137 in vfs_cache_lookup (ap=0x0)
at /usr/src/sys/kern/vfs_cache.c:607
#11 0xc062b1a8 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2792
#12 0xc05781f2 in lookup (ndp=0xd56bcbd8) at vnode_if.h:52
#13 0xc0577bde in namei (ndp=0xd56bcbd8) at /usr/src/sys/kern/vfs_lookup.c:183
#14 0xc058a143 in vn_open_cred (ndp=0xd56bcbd8, flagp=0xd56bccd8,
cmode=0x180, cred=0xc47d5980, fdidx=0x0) at /usr/src/sys/kern/vfs_vnops.c:193
#15 0xc0589ed0 in vn_open (ndp=0x0, flagp=0x0, cmode=0x0, fdidx=0x0)
at /usr/src/sys/kern/vfs_vnops.c:93
#16 0xc05833a0 in kern_open (td=0xc47df980, path=0x0, pathseg=UIO_USERSPACE, 
flags=0x1, mode=0x1b6) at /usr/src/sys/kern/vfs_syscalls.c:688
#17 0xc0583250 in open (td=0x0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:654
#18 0xc0688b43 in syscall (frame= 
  {tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0xbfbf002f, tf_edi = 0x4, tf_esi = 
0x2843dae0, tf_ebp = 0xbfbfef88, tf_isp = 0xd56bcd74, tf_ebx = 0x2842b804, tf_edx = 
0x0, tf_ecx = 0x80ba3d7, tf_eax = 0x5, tf_trapno = 0x0, tf_err = 0x2, tf_eip = 
0x283af90f, tf_cs = 0x1f, tf_eflags = 0x202, tf_esp = 0xbfbfef5c, tf_ss = 0x2f}) at 
/usr/src/sys/i386/i386/trap.c:1008
#19 0xc0678b9d in Xint0x80_syscall () at {standard input}:144

If anyone wants any more info from the dump, just ask...

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fatal trap 12: page fault while in kernel mode with latest-CURRENT

2003-08-14 Thread David Taylor
On Tue, 12 Aug 2003, David Taylor wrote:

 I've been getting this occasionally (a few times a day) since I upgraded
 to -CURRENT yesterday.  I tried installing Bosko's Intel Data Corruption
 patch today, to see if that changed anything, but it doesn't appear to
 have worked.
 
[snip]

*sigh*

Now that I've recompiled x11/nvidia-driver _without_ -DWITH_FREEBSD_AGP,
the fatal traps have gone away.  The reason I didn't try this earlier is
that previously, I would see lots of crashes _unless_ -DWITH_FREEBSD_AGP
was specified.

However, after noticing the crashes stopped when I disabled X, I gave it a
try...  And it appears to have worked.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 5.2-RELEASE TODO

2003-06-29 Thread David Taylor
On Sun, 29 Jun 2003, Robert Watson wrote:
   ++
   |Issue|  Status  |   Responsible   | Description |
   |-+--+-+-|
 ^^^

I don't suppose it would be possible to delete a couple of those leading
spaces on each line?

Although it fits into an 80-column display in vim/cat/whatever, mutt ends
up wrapping it, and making it very ugly, but removing a couple of the
spaces would make it fit fine.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 5.2-RELEASE TODO

2003-06-29 Thread David Taylor
On Sun, 29 Jun 2003, David Taylor wrote:
 I don't suppose it would be possible to delete a couple of those leading
 spaces on each line?
 

Bah, ignore me, after deciding it was mutt's fault for wrapping it when it
shouldn't be, I found the 'wrapmargin' setting in my muttrc file...
Reducing that a little fixed the problem.

Sorry about that,

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Signal handling changes

2002-08-29 Thread David Taylor

On Thu, 29 Aug 2002, Tim Robbins wrote:

 It looks like there are still problems with SIGSTOP/SIGCONT signal handling.
 With a kernel/world from August 24 and using csh or sh (choice of shell
 is probably not relevant), running sleep 30 then suspending it with ^Z
 then continuing it with fg causes the sleep process to exit as soon
 as it's continued, instead of sleeping for the remainder of the interval
 as it does on 4.6.2.

I'm seeing the same behaviour on, erm, surprisingly enough a kernel/world
from August 24:

FreeBSD gattaca.yadt.co.uk 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
Sat Aug 24 02:25:26 BST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATTACA i386

However, at least that shows it isn't any local setup issue, I guess.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: different packing of structs in kernel vs. userland ?

2002-07-15 Thread David Taylor

On Tue, 16 Jul 2002, David Taylor wrote:

Bah, ignore me, it appears you've already admitted your post was rather
less than clear :)

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



urio driver

2002-02-12 Thread David Taylor

The urio driver appears to call make_dev, discarding the returned dev_t,
and never bothers to call destroy_dev.

Although this is presumably broken, it did _work_ previously.  however,
there is now a 'panic(don't do that);' call in make_dev (and
destroy_dev) to prevent duplicate calls, thus the machine will crash if
you attach/detach/re-attach a rio.  This has been happing for quite a
while now, but I've never been bothered enough to actually try to fix it,
until now. :)

I have approximately no experience with FreeBSD device drivers, but I'm
currently attempting to see if I can figure out how the other u*.c files
handle detaching... any hints would be appreciated :)

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: urio driver

2002-02-12 Thread David Taylor

On Tue, 12 Feb 2002, David Taylor wrote:
 I have approximately no experience with FreeBSD device drivers, but I'm
 currently attempting to see if I can figure out how the other u*.c files
 handle detaching... any hints would be appreciated :)
 

Well.  I managed to create a patch which _works_.  I have some serious
doubts about its correctness, however.

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be


--- urio.c.old  Tue Feb 12 22:31:14 2002
+++ urio.c  Tue Feb 12 22:02:03 2002
@@ -160,6 +160,8 @@
int sc_refcnt;
 #if defined(__NetBSD__) || defined(__OpenBSD__)
u_char sc_dying;
+#elif defined(__FreeBSD__)
+dev_t dev;
 #endif
 };
 
@@ -271,8 +273,7 @@
 
 #if defined(__FreeBSD__)
  #if (__FreeBSD__ = 4)
-   /* XXX no error trapping, no storing of dev_t */
-   (void) make_dev(urio_cdevsw, device_get_unit(self),
+   sc-dev = make_dev(urio_cdevsw, device_get_unit(self),
UID_ROOT, GID_OPERATOR,
0644, urio%d, device_get_unit(self));
  #endif
@@ -633,22 +634,25 @@
}
return (0);
 }
+#endif
 
 USB_DETACH(urio)
 {
USB_DETACH_START(urio, sc);
-   struct urio_endpoint *sce;
-   int i, dir;
-   int s;
+   struct vnode *vp;
+
 #if defined(__NetBSD__) || defined(__OpenBSD__)
-   int maj, mn;
+   struct urio_endpoit *sce;
+   int i, dir;
+   int s;
+   int maj, mn;
 
DPRINTF((urio_detach: sc=%p flags=%d\n, sc, flags));
+   sc-sc_dying = 1;
 #elif defined(__FreeBSD__)
DPRINTF((urio_detach: sc=%p\n, sc));
 #endif
 
-   sc-sc_dying = 1;
/* Abort all pipes.  Causes processes waiting for transfer to wake. */
 #if 0
for (i = 0; i  USB_MAX_ENDPOINTS; i++) {
@@ -668,7 +672,7 @@
usb_detach_wait(USBDEV(sc-sc_dev));
}
splx(s);
-#else
+/* #else */
if (sc-sc_pipeh_in) 
usbd_abort_pipe(sc-sc_pipeh_in);   
 
@@ -692,25 +696,20 @@
/* Nuke the vnodes for any open instances (calls close). */
mn = self-dv_unit * USB_MAX_ENDPOINTS;
vdevgone(maj, mn, mn + USB_MAX_ENDPOINTS - 1, VCHR);
-#elif defined(__FreeBSD__)
-   /* XXX not implemented yet */
-#endif
 
-   usbd_add_drv_event(USB_EVENT_DRIVER_DETACH, sc-sc_udev,
-  USBDEV(sc-sc_dev));
+   usbd_add_drv_event(USB_EVENT_DRIVER_DETACH, sc-sc_udev,
+  USBDEV(sc-sc_dev));
+#elif defined(__FreeBSD__)
+   device_set_desc(self, NULL);
+   vp = SLIST_FIRST(sc-dev-si_hlist);
+   if (vp)
+   VOP_REVOKE(vp, REVOKEALL);
 
-   return (0);
+   destroy_dev(sc-dev);
+#endif
+   return (0);
 }
-#endif /* defined(__NetBSD__) || defined(__OpenBSD__) */
-
 #if defined(__FreeBSD__)
-Static int
-urio_detach(device_t self)
-{   
-   DPRINTF((%s: disconnected\n, USBDEVNAME(self)));
-   device_set_desc(self, NULL);
-   return 0;
-}
 
 #if (__FreeBSD__ = 4)
 DRIVER_MODULE(urio, uhub, urio_driver, urio_devclass, usbd_driver_load, 0);



msdosfs_lookup returns EINVAL, not ENOENT

2001-12-30 Thread David Taylor

Whilst poking around on my msdosfs (trying to find an MP3 I thought I had),
I discovered that, if there are no files matching foo*, ls foo* will
return the wrong error.

msdosfs:

$ ls foo* 
ls: foo*: Invalid argument

ufs:
$ ls foo*
ls: foo*: No such file or directory

Using strace tracked this down to lstat of foo* returning EINVAL, which
would appear to be incorrect, as EINVAL is not listed as a possible error
for lstat.

Now, since I'm not familar with the innards of freebsd's fs code, here is
where I get a little bit lost.

I _think_ I've tracked down the source of the error to the point where
unix2dosfn is called in msdosfs_lookup, which would be expected, since '*'
is an invalid character in msdos filenames, but is fine for ufs.

The call on line 152 of msdosfs_lookup.c appears to be the one causing the
current problem, but I'm not sure if simply replacing EINVAL with ENOENT
would affect things other than lstat.

However, I'm also not sure if the behaviour of the other two calls is correct.

OTOH, I'm not sure what syscalls are supposed to return in the case of an
invalid character in a filename.

e.g. touch foo\\ fails with EINVAL currently, yet open(2) states EINVAL
means you have used an invalid combination of O_RDONLY, O_WRONLY, and
O_RDWR.  But no error is listed in the manpage for an invalid filename,
other than ENAMETOOLONG, which is clearly inappropriate.

Perhaps the correct fix would just be to document the use of EINVAL?

-- 
David Taylor
[EMAIL PROTECTED]
The future just ain't what it used to be



msg33327/pgp0.pgp
Description: PGP signature


Re: Add USB mouse to sysinstall

2001-12-24 Thread David Taylor

On Mon, 24 Dec 2001, William Ward wrote:
 A.  Thanks for the answer.
 
 /William

You know, replying below the quoted post makes it a lot easier to reply to
both peoples replies, without having to be adept at reading backwards...
 
 On Mon, Dec 24, 2001 at 12:27:52PM -0800, Eric Melville wrote:
   Is /dev/ums0 ommitted from sysinstall for any particular reason?  This patch
   adds /dev/ums0 to sysinstall::Configure-Mouse-Port.
  
  This is intentional. In the case of a usb mouse, usbd is responsible for
  starting moused.

However, perhaps sysinstall should tell the user that if they have a USB
mouse, they need do nothing, insetad of think 'Uhh, I don't recognise any of
these, lets try this one'  and getting it wrong.

-- 
David Taylor
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ntfs panic (lockmgr: not exclusive lock holder 470 unlocking)

2001-10-04 Thread David Taylor

On Thu, 04 Oct 2001, Jun Kuriyama wrote:
 I tried to use mount_ntfs, but it panic'ed.
 
 
 % sudo mount -t ntfs /dev/ad0s1 /mnt
 % cd /mnt
 % ls -la
 panic: lockmgr: pid 551, not exclusive lock holder 470 unlocking
 Debugger(panic)
 Stopped at Debugger+0x44:  pushl%ebx
 db t
 Debugger() at Debugger+0x44
 panic(c02ef100,227,c02ef0e0,1d6,cab5f740) at panic+0x70
 lockmgr(cb5f7dc,6,cab5f7ac,ca376404,caad4bf4) at lockmgr+0x369
 vop_stdunlock(caad4be4,cab5f740,ca376404,c031dbc0,cab5f740) at vop_stdunlock+0x22
 ntfs_inactive(caad4c08,cab5f740,0,c031db00,cab5f740) at ntfs_inactive+0x54

I reported the same panic a while ago.  It appears to have been caused by
the last large KSE commit.

-- 
David Taylor
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: testig request for your code..

2001-09-18 Thread David Taylor

On Mon, 17 Sep 2001, Julian Elischer wrote:
 
 If you find a module that worked in a kernel from before September 11
 but does not work on -current, please let [EMAIL PROTECTED] know.
  

NTFS was working correctly in a kernel from sometime in August, it now fails
with an easily reproducable panic about locks.  Unfortunately, I never wrote
down the trace since I was planning on using gdb -k to debug it.. but:

# gdb -k kernel.6 vmcore.6
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd...
(no debugging symbols found)...
IdlePTD 4620288
initial pcb at 370340
panicstr: bremfree: bp 0xc8977ba0 not locked
panic messages:
---
panic: lockmgr: pid 943, not exclusive lock holder 942 unlocking

dumping to dev ad0s4b, offset 584197
dump ata0: resetting devices .. done
256 [snip] 1
---
Bus error (core dumped)

So, I guess I'll need to copy it down by hand next time I'm prepared to
crash my system.. (A simple cd /mnt/w2k/; ls; crashes the box.  Oddly
enough, it didn't seem to have the same effect in single-user mode, not sure
why...)

-- 
David Taylor
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: testig request for your code..

2001-09-18 Thread David Taylor

On Tue, 18 Sep 2001, Julian Elischer wrote:
 If you can try a kernel from JUST before the KSE integration..
 
 that migh talso be a good test..
 

A kernel from cvs up -D2001-09-10 works perfectly,
A kernel from after the KSE milestone 2 produces various panics
like the following:

(find .; running on ntfs partition)
  |  (sleep; god knows where)
  |  (   it came from   )
  vv
panic: lockmgr: pid 30856, not exclusive lock holder 30814 unlocking.

backtrace:

panic
lockmgr
vop_stdunlock
ntfs_inactive
vput
lstat

Unfortunately, gdb -k kernel.X vmcore.X is still coring on startup, so I
can't get any more info, unless someone has something they want me to do at
the DDB prompt.

-- 
David Taylor
[EMAIL PROTECTED]

 PGP signature


Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' panic

2001-06-01 Thread David Taylor

On Thu, 31 May 2001, Bruce Evans wrote:
 On Wed, 30 May 2001, David Taylor wrote:
 
  When trying to profile ircd-hybrid-7 on -CURRENT (I tried using a pre-vm
  madness version first, then tried a version cvsuped today), I reliably get
  lots of:
  
  kernel trap 12 with interrupts disabled
  
  messages on the console (one every 5-10 seconds, when the ircd is reasonably
  loaded).
 
 This is because ast() calls addupc_task() with sched_lock held.
 addupc_task() calls copyin() and copyin() sometimes traps to fault in the
 profiling buffer.
 
 This seems to be just a bug in ast().  userret() is missing the bug.
 Untested fix:
 
 ---
 Index: trap.c
 ===
 RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
 retrieving revision 1.189
 diff -u -1 -r1.189 trap.c
 --- trap.c2001/05/23 22:58:09 1.189
 +++ trap.c2001/05/31 13:09:02
 @@ -1285,5 +1341,6 @@
   mtx_lock(Giant);
 - mtx_lock_spin(sched_lock);
   addupc_task(p, p-p_stats-p_prof.pr_addr,
   p-p_stats-p_prof.pr_ticks);
 + mtx_lock_spin(sched_lock);
 + /* XXX why not unlock Giant? */
   }
 ---

I tested this, and it works!

No more `kernel trap 12 with interrupts disabled' messages, and also,
thankfully, no more panics.  (Related to this anyway, I'm still getting
freelist corruption related things).
 
 I think this is caused by the same bug.
 
 kernel trap almost any with interrupts disabled
 
 should be fatal (the case of trap 12 (only) _is_ fatal in my version),
 but the kernel attempts to fix the problem and continue.  This sort
 of worked when things were locked by disabling interrupts.  Now, things
 may be locked by a spinlock as well as by disabling interrupts, and
 the corresponding fixup would be to release the spinlock.  But this
 is more obviously wrong.
 
 Bruce
 

Yeah, just trying to cover up the problem and march on usually doesn't work
out very well in computing.. or anywhere else, really..

-- 
David Taylor
[EMAIL PROTECTED]

 PGP signature


Re: Possible Install bug for the following hardware in FreeBSD Stable (4.3)

2001-05-31 Thread David Taylor

On Thu, 31 May 2001, Darian Lanx wrote:
 
  I had this problem after I enabled the '4092-cylinder limit' jumper on my
  Maxtor drive, because my BIOS (at that point) hung with a drive over 4092
  cylinders.  I flashed the BIOS afterwards, but forgot about the jumper,
  because windows/linux both (somehow) saw the full geometry of the drive.
  FreeBSD only saw 2014MB until I removed the jumper.  Perhaps your drive has
  a similar jumper? check the manual.

 Thank you David for the tip. None the less, has this issue witht he driver 
 been addressed? The driver should not bother about that, because the Hard 
 disk reporst the correct size back. On the other, my drive does not have such 
 a jumper, I just checked, so I am really at my wits ends.
 

I'm not a hardware guru either, and I know very little about the internals
of FreeBSD's IDE drivers, so I'm not sure how windows/linux are detecting
the correct geometry, and FreeBSD isn't...

Unfortunately, if your drive doesn't have a jumper like that, I've no idea
what could be wrong...

-- 
David Taylor
[EMAIL PROTECTED]

 PGP signature


Re: problem building linux kernel module in current

2001-04-08 Thread David Taylor

On Fri, 06 Apr 2001, John Carlson wrote:
 Hi, 
 
 I cvsupped today to -CURRENT, thinking to upgrade my -STABLE installation
 (4.3-BETA). I followed the instructions in the UPDATING file, but ran into 
 a persistent problem when trying to compile the kernel after a successful
 buildworld. The kernel compilation dies while making the modules at this
 point: 
 
 cc -O -pipe   -D_KERNEL -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I-   -I.
 -I@ -I@/dev -I@/../include  -mpreferred-stack-boundary=2 -c linux_sysent.c
 linux_sysent.c:21: sizeof applied to an incomplete type
 linux_sysent.c:21: warning: built-in function `exit' used without
 declaration
 linux_sysent.c:21: warning: cast discards qualifiers from pointer target
 type
 *** Error code 1
 
 Anyone else noticed this problem or is it just me doing something wrong?
 Any help would be appreciated.
 


Hmm... I also noticed this problem, after following the UPDATING
instructions to get from 4.3-RC - 5.0-CURRENT...

I managed to get the kernel to build successfully by hacking at the
linux_sysent.c file...

For some reason, the sys_exit line in linux_sysent.c in /usr/src gets
changed to something which breaks when it gets copied into /usr/obj...

(IIRC, I don't have both copies of the file available any more)

{ AS(sys_exit_args), (sy_call_t *)sys_exit },   /* 1 = exit */  

was changed to something like
{ AS(rexit), (sy_call_t *)exit },   /* 1 = exit */
 ^

The 'underlined' (^^^) bits are definately right, I'm not sure about the
cast...

Any one have any ideas what would cause that?

(presumably linux_sysent.c is getting regenerated, incorrectly, somewhere?)

-- 
David Taylor
[EMAIL PROTECTED]

 PGP signature