Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?
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?
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
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?
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
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
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
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
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
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
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 ?
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
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
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
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
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)
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..
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..
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
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)
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
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