Re: support for mounting md(4) based filesystem at boot [PATCHES]
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Johny Mattsson writes: This archive contains a number of files, including four rc.d scripts, a rc.conf diff, a couple of datafiles and some manpages for said data files. Okay, I probably made that sound a lot worse than it actually is. There is only one new fileformat in there (and it's documented). But I understand where your concern is coming from. I think we need somebody to reconsider how we configure our filesystems in the future, in order to avoid a confusion of config files whose interrelationship users will have no chance of figuring out. Are you referring just to the (currently messy) disk config/attach/whatever order, or a more drastic overhaul of how we configure disk settings? I haven't worked with CCD, Vinum, or GBDE (yet), so I'm not sure if I'll be a good person to tackle it, but I'll certainly give it some thought though. Sounds like an interesting little challenge that I may just be able to find time for :) Cheers, /Johny -- Johny Mattsson - System Designer ,-. ,-. ,-. There is no truth. http://www.earthmagic.org _.' `-' `-' There is only perception. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for mounting md(4) based filesystem at boot [PATCHES]
In message [EMAIL PROTECTED], Johny Mattsson writes: I think we need somebody to reconsider how we configure our filesystems in the future, in order to avoid a confusion of config files whose interrelationship users will have no chance of figuring out. Are you referring just to the (currently messy) disk config/attach/whatever order, or a more drastic overhaul of how we configure disk settings? I haven't worked with CCD, Vinum, or GBDE (yet), so I'm not sure if I'll be a good person to tackle it, but I'll certainly give it some thought though. Sounds like an interesting little challenge that I may just be able to find time for :) I don't know exactly what I am looking for, if I did, I'd just implement it, but I think that we should be able describe our disk configuration with just one single file in a human+program parseable format, rather than having to have one file per gadget. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for mounting md(4) based filesystem at boot [PATCHES]
Poul-Henning Kamp wrote: I don't know exactly what I am looking for, if I did, I'd just implement it, but I think that we should be able describe our disk configuration with just one single file in a human+program parseable format, rather than having to have one file per gadget. Sounds to me like if we indeed do this, we might have to move away from the traditional fstab (in order to deal better with dependencies), which I'm not sure is such a good idea. Then again, prior to 5.2 is probably the best chance we'll have for another couple of years to make such a drastic change. I'll give it some thought and come up with a draft proposal (unless someone else does it first). If anyone has recommendations on manpages, URLs, etc that they think would be useful background info, please let me know - for many of the 'gadgets' I'll be learning as I go. Cheers, /Johny -- Johny Mattsson - System Designer ,-. ,-. ,-. There is no truth. http://www.earthmagic.org _.' `-' `-' There is only perception. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current] Re: ACPI suspending.
In message: [EMAIL PROTECTED] Kevin Oberman [EMAIL PROTECTED] writes: : M S4 works on my fiva, but it seems to have a S4BIOS S4 state because : M the bios does the save to disk... : : I would assume that this requires some form of DOS-like parition? : : Actually, it requires a specially made hibernation partition. This can : be created by a Windows utility and maybe by fdisk on FreeBSD, but you : have to both mark it with the correct partition type and make sure it : is the right size. I'm not sure how it was created. I inherited the setup when I got the laptop. But that fits with hacking I've done in the past. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI issues on ThinkPad T21 + Dock
Stijn Hoop wrote: On Thu, Jun 19, 2003 at 09:33:41AM +0200, Eirik Oeverby wrote: - When booted with ACPI enabled (docked), the machine will at some point simply power itself off. I have seen people complaining about similiar machines powering themselves *on* after a power-off, but in my case it's the opposite. Out of nothing, with no warning (that I can see), it simply powers off. It's not suspend either, or hibernation or anything. Just a shot in the dark, but might it be heat? Most laptops/PCs turn themselves off to prevent them from overheating. Maybe ACPI doesn't turn on the fans when docked or something like that. Nope, since this never happened before 5.1. I've been running 4.8 and OS/2 on this machine before, always docked, and temperature was never an issue. It's possible that ACPI in 5.1 does this - after all it has some kind of thermal support, but I have tried to disable this and it makes no difference. Just to be on the safe side, would the following line in device.hints be correct for disabling the thermal part of acpi? debug.acpi.disable=thermal I think it would be, because replacing thermal with children made my system refuse to boot. No HW was detected ;) /Eirik signature.asc Description: This is a digitally signed message part
Re: write access to dos partition hangs system completely
On Sun, Jun 15, 2003, Andreas Klemm wrote: FreeBSD titan.klemm.apsfilter.org 5.1-RC FreeBSD 5.1-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 i386 When I mount my dos partition read write and copy some data to it it immediately freezes the system. [...] da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 Mounting root from ufs:/dev/ad2s2a ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40 pid 640 (squid), uid 65534: exited on signal 6 pid 674 (squid), uid 65534: exited on signal 6 pid 676 (squid), uid 65534: exited on signal 6 pid 678 (squid), uid 65534: exited on signal 6 pid 680 (squid), uid 65534: exited on signal 6 ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40 ad0: hard error cmd=read fsbn 115471871 status=51 error=40 ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40 ad0: hard error cmd=read fsbn 115471871 status=51 error=40 I don't know which of these devices your DOS partition is on, but the root problem seems to be the hardware. That said, msdosfs does hang when a write error occurs, so that may be your problem. (It gets into a loop in which it retries forever.) I submitted kern/37035 regarding this over a year ago, although I don't know to what extent the original problem or the trivial patch I posted still apply to 5.X. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: terminfo man page
On Wed, Jun 18, 2003 at 02:33:57PM -0400, Guy Middleton [EMAIL PROTECTED] wrote: I put this on comp.unix.bsd.freebsd.misc, but I'll ask here too. Is there any reason for the terminfo man page? It's a good man page, a very stylish and well-written man page, but it's wrong. It says the terminfo files are in /usr/share/misc/terminfo (they're not there). They do get installed into /usr/local/share/misc/terminfo as part of the ncurses port. Could we just remove the man page from the base system? No, please. Better install terminfo database into /usr/share/misc/terminfo and be done with it. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
nfs mounting from localhost
Hi all, is there a possibility to nfs mount a file system from localhost from rcNG? All the NFS server stuff seems to be started after NFS mounting. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
My computer gets stalled when I try to exec the X window system (Itwas can't compile Nvidia driver)
Hello again: It doesn't matter if either I use the /usr/x11/nvidia-driver or I use the normal nv driver, when I run X or kdm or xf86cfg my computer hangs completely. I've got the Nvidia RIVA TNT 64M PCI (I made a question here a cuople of days ago). My computer has an ASUS-SP97 motherboard with a SIS5597 vga chipset and it doesn't have AGP, only PCI and ISA slots. I upgraded my BIOS to make it work with hard-disk bigger than 8G, and also to allow to switch off the onboard VGA chipset. With Linux and Windows it works nice :( I've tried with XFree86-4.2 and XFree86-4.3, but no success. Sometimes, when I lauch X, I see on the screen as if the computer had reboot, I mean that I see the information about the NVidia vga card that I usually see when I switch on the computer for the first time. It's very strange because I've been working with my NVidia card on 5.0-DP1, both with the nv driver and with a driver for FreeBSD-5.0 before nvidia released his own driver. I don't know what I've done during this 2 weeks, but now I don't have X system any more (lol). Im really fed up with this because I was getting used to using KDE (lol again :) If anybody can help meI will give my computer away to him, I swear Thanks :( -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ttyname(3) review requested...
I'm not up to speed on the per thread magic storage thing, so I would
appreciate if somebody could review test this patch:
Index: gen/ttyname.c
===
RCS file: /home/ncvs/src/lib/libc/gen/ttyname.c,v
retrieving revision 1.12
diff -u -r1.12 ttyname.c
--- gen/ttyname.c 1 Feb 2002 01:32:19 - 1.12
+++ gen/ttyname.c 20 Jun 2003 09:44:28 -
@@ -50,7 +50,6 @@
#include pthread.h
#include un-namespace.h
-#include db.h
#include libc_private.h
static char buf[sizeof(_PATH_DEV) + MAXNAMLEN] = _PATH_DEV;
@@ -77,8 +76,6 @@
char *
ttyname_r(int fd, char *buf, size_t len)
{
- struct dirent *dirp;
- DIR *dp;
struct stat dsb;
struct stat sb;
char*rval;
@@ -96,23 +93,7 @@
if (len = sizeof(_PATH_DEV))
return (rval);
- if ((dp = opendir(_PATH_DEV)) != NULL) {
- memcpy(buf, _PATH_DEV, sizeof(_PATH_DEV));
- for (rval = NULL; (dirp = readdir(dp)) != NULL;) {
- if (dirp-d_fileno != sb.st_ino)
- continue;
- minlen = (len - (sizeof(_PATH_DEV) - 1)) (dirp-d_namlen +
1) ?
- (len - (sizeof(_PATH_DEV) - 1)) : (dirp-d_namlen + 1);
- memcpy(buf + sizeof(_PATH_DEV) - 1, dirp-d_name, minlen);
- if (stat(buf, dsb) || sb.st_dev != dsb.st_dev ||
- sb.st_ino != dsb.st_ino)
- continue;
- rval = buf;
- break;
- }
- (void) closedir(dp);
- }
- return (rval);
+ return(devname_r(sb.st_rdev, S_IFCHR, buf, sizeof(buf)));
}
static char *
@@ -151,12 +132,6 @@
{
struct stat sb;
struct termios ttyb;
- DB *db;
- DBT data, key;
- struct {
- mode_t type;
- dev_t dev;
- } bkey;
/* Must be a terminal. */
if (tcgetattr(fd, ttyb) 0)
@@ -165,44 +140,5 @@
if (_fstat(fd, sb) || !S_ISCHR(sb.st_mode))
return (NULL);
- if ( (db = dbopen(_PATH_DEVDB, O_RDONLY, 0, DB_HASH, NULL)) ) {
- memset(bkey, 0, sizeof(bkey));
- bkey.type = S_IFCHR;
- bkey.dev = sb.st_rdev;
- key.data = bkey;
- key.size = sizeof(bkey);
- if (!(db-get)(db, key, data, 0)) {
- bcopy(data.data,
- buf + sizeof(_PATH_DEV) - 1, data.size);
- (void)(db-close)(db);
- return (buf);
- }
- (void)(db-close)(db);
- }
- return (oldttyname(fd, sb));
-}
-
-static char *
-oldttyname(int fd, struct stat *sb)
-{
- struct dirent *dirp;
- struct stat dsb;
- DIR *dp;
-
- if ((dp = opendir(_PATH_DEV)) == NULL)
- return (NULL);
-
- while ( (dirp = readdir(dp)) ) {
- if (dirp-d_fileno != sb-st_ino)
- continue;
- bcopy(dirp-d_name, buf + sizeof(_PATH_DEV) - 1,
- dirp-d_namlen + 1);
- if (stat(buf, dsb) || sb-st_dev != dsb.st_dev ||
- sb-st_ino != dsb.st_ino)
- continue;
- (void)closedir(dp);
- return (buf);
- }
- (void)closedir(dp);
- return (NULL);
+ return(devname_r(sb.st_rdev, S_IFCHR, buf, sizeof(buf)));
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
On 2003-06-19 08:13 -0700, Don Lewis [EMAIL PROTECTED] wrote: In PR kern/46652 I reported, that DEBUG_VFS_LOCKS does never check the **vpp parameters. A patch is included in the PR and it does generate the missing tests. I asked for feedback on the hackers mail list (IIRC), but did not get any replies. Any objections against me committing the patch now ? (A different fix is mentioned in the PR, the patch I suggested was the minimal change to the code which made it work, the alternative seems cleaner to me ...) Please read PR kern/46652 ! I think the alternative fix should be committed. That would do the correct thing if another pointer to a pointer to a vnode argument is ever added. I think this is better than adding magic to vpp. Well, the alternative fix is much more work than I thought ... I spent an hour on it, but the parameter names are assumed to only consist of [a-z]* in a number of places and fixing this would add complexity to the AWK script and make it harder to maintain. Instead, I'm going to commit the trivial fix and add a comment about double indirection as in **vpp requiring special code in the AWK script to vnode_if.src ... This will fix the debug code that is generated and who ever cares for a better solution may back-out my two line fix and implement the clean solution. Any idea if this change turns up more problems? Sorry, no. I found this while looking for some other problem and just opened the PR and sent a note to the hackers mail list ... Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APM problem in 5.1-RELEASE
Jesse Guardiani wrote: Jesse Guardiani wrote: Jesse Guardiani wrote: Darryl Okahata wrote: Jesse Guardiani [EMAIL PROTECTED] wrote: [...] Now, if I can just get that lousy CD-ROM to not crash my system on resume I'll be a VERY happy man... I did some more testing on this last night, and it appears that the atacontrol detach method _does_ work, but only in specialized circumstances. I have modified my /etc/rc.suspend to call 'atacontrol detach 1' _before_ it calls 'apm -z'. I have also modified my /etc/rc.resume to call 'atacontrol attach 1' _after_ syncing the disks. If anyone wants to have a look at these files, just let me know. When it works: -- 1.) I have to be looking at a VTY, not X. (Geez. Just when I thought I got around this with the kernel option SC_NO_SUSPEND_VTYSWITCH...) 2.) The /dev/acd0 device has to be unused, otherwise the kernel panics. This means I have to stop playing any CDs and terminate the CD playing program. I assume this means that the device has to be _not_ open, but I haven't really performed much testing in this area. When it doesn't work: - 1.) If I try to suspend while looking at X, the kernel panics and auto- reboots. 2.) If I try to suspend while anything is accessing the acd0 device the kernel panics and auto-reboots. Those things aside, I can usually suspend my machine within 8 seconds, as long as the hard disk isn't under high load. And it comes back on-line in under 3 seconds. I've tested this 6 or 7 times in a row, swapping back and forth from X before doing the next suspend, so I'm pretty confident that it's reliable. A plus is that the little green drive in use light on the side of my Ultrabay goes off when the machine is in suspend mode, and since I call: atacontrol attach 1 Upon resume from suspend, I could very easily swap out my drives while in suspend mode. I've tested this. Pretty neat! Things I would like to improve upon: 1.) I need to find some way to automatically kill any processes that are using (or have opened) the /dev/acd0 device BEFORE executing apm -z from /etc/rc.suspend. If I can accomplish that, then I will have successfully eliminated the stupid human factor that sometimes causes me to forget I have a program running that uses the /dev/acd0 device. Does anyone have any ideas here? 2.) I'd love to automate (or do away with) the process of switching to a VTY from X before executing 'atacontrol detach 1'. Can anyone give me a _reason_ why I have to do that? It just seems odd to me. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_ntfs causes panic
In [EMAIL PROTECTED] Tim Robbins [EMAIL PROTECTED] wrote: /etc/fstab: /dev/ad0s2 /mnt/winnt ntfsro,noauto 0 0 When mount /mnt/winnt, the system falls into DDB. This looks like a bug in the buffer cache code. I'm working on trying to fix it. Mounting read-write instead of read-only ought to work around the problem, but it's probably not very safe. Thanks for support. I updated the kernel on another PC from yesterday's source (cvsup-ed about Jun 19 14:00 JST) and, what a miracle, mount_ntfs did not get system panic. I'll try the latest kernel on the PC on which I found this problem. -- NAKAJI Hiroyuki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Current kernel Fatal Trap 12
For the past week i have not been able to boot with current kernel. The last kernel that works is from Sat June 14th. When I build and try and boot a current kernel I get: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f6212 stack pointer = 0x10:0xc04b1e24 frame pointer = 0x10:0xc04b1e24 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 = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s Fatal trap 12: page fault while in kernel mode fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f6212 stack pointer = 0x10:0xc04b1cec frame pointer = 0x10:0xc04b1cec 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 = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s This continues to scroll by many times and I can't get to the debugger. The machine is i386 SMP dual pentium-pro overdrive processors. Same thing happens with kernel configured as UNIprocessor. == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APM problem in 5.1-RELEASE
Jesse Guardiani wrote:
Things I would like to improve upon:
1.) I need to find some way to automatically kill any processes that are
using (or have opened) the /dev/acd0 device BEFORE executing apm -z
from /etc/rc.suspend.
OK. The following pipeline does a pretty good job of this:
# Kill any process currently using /dev/acd0
kill -KILL `fstat /dev/acd0 | sed -Ee 's/[[:space:]]+/ /g' | cut -d ' ' -f 3`
It isn't perfect (i.e. if more than one process has /dev/acd0 open, it won't
kill the second process), but I can expand on this to make it fit just about
any need.
[...]
2.) I'd love to automate (or do away with) the process of switching to
a VTY from X before executing 'atacontrol detach 1'.
This from Tobias Roth:
-
to do this automatically, change your /etc/rc.suspend and /etc/rc.resume
like this:
/etc.rc.suspend: insert this line just before the 'logger' line:
vidcontrol -s 2 /dev/ttyv0
/etc/rc.resume: insert this line just before the 'logger' line:
vidcontrol -s 1 /dev/ttyv0
-
This works pretty darn well! Thanks Tobias!
I can now suspend my machine from X without fear of kernel panic!
Thanks for the help everyone!
Here is my rc.suspend, just in case someone else with an IBM Thinkpad A30p
needs it:
-- /etc/rc.suspend --
#!/bin/sh
#
# Copyright (c) 1999 Mitsuru IWASAKI
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/etc/rc.suspend,v 1.4 2000/10/08 19:18:24 obrien Exp $
#
# sample run command file for APM Suspend Event
if [ -r /var/run/rc.suspend.pid ]; then
exit 1
fi
echo $$ /var/run/rc.suspend.pid
# If you have troubles on suspending with PC-CARD modem, try this.
# See also contrib/pccardq.c (Only for PAO users).
# pccardq | awk -F '~' '$5 == filled $4 ~ /sio/ \
# { printf(pccardc power %d 0, $1); }' | sh
logger -t apmd suspend at `date +'%Y%m%d %H:%M:%S'`
# Kill any process currently using /dev/acd0
kill -KILL `fstat /dev/acd0 | sed -Ee 's/[[:space:]]+/ /g' | cut -d ' ' -f 3`
# switch to a TTY
vidcontrol -s 1 /dev/ttyv0
# detach buggy CD-ROM before suspending.
sync sync sync
atacontrol detach 1
sleep 1
sync sync sync
sleep 1
rm -f /var/run/rc.suspend.pid
zzz
exit 0
-- end /etc/rc.suspend --
And here is my /etc/rc.resume:
-- /etc/rc.resume --
#!/bin/sh
#
# Copyright (c) 1999 Mitsuru IWASAKI
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
Re: Current kernel Fatal Trap 12
If you have a version of the kernel in question on disk and with debugging symbols, could you attach gdb -k to it and send us the results of: l *0xc01f6212 That will provide a bit more information about where the panic is occuring. This is likely a NULL pointer dereference. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Fri, 20 Jun 2003, Manfred Antar wrote: For the past week i have not been able to boot with current kernel. The last kernel that works is from Sat June 14th. When I build and try and boot a current kernel I get: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f6212 stack pointer = 0x10:0xc04b1e24 frame pointer = 0x10:0xc04b1e24 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 = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s Fatal trap 12: page fault while in kernel mode fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f6212 stack pointer = 0x10:0xc04b1cec frame pointer = 0x10:0xc04b1cec 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 = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s This continues to scroll by many times and I can't get to the debugger. The machine is i386 SMP dual pentium-pro overdrive processors. Same thing happens with kernel configured as UNIprocessor. == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Current kernel Fatal Trap 12
At 12:21 PM 6/20/2003 -0400, Robert Watson wrote:
If you have a version of the kernel in question on disk and with debugging
symbols, could you attach gdb -k to it and send us the results of:
l *0xc01f6212
That will provide a bit more information about where the panic is
occuring. This is likely a NULL pointer dereference.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Fri, 20 Jun 2003, Manfred Antar wrote:
For the past week i have not been able to boot with current kernel.
The last kernel that works is from Sat June 14th.
When I build and try and boot a current kernel I get:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01f6212
stack pointer = 0x10:0xc04b1cec
frame pointer = 0x10:0xc04b1cec
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 = 0 (swapper)
trap number = 12
panic: page fault
Uptime: 1s
This continues to scroll by many times and I can't get to the debugger.
The machine is i386 SMP dual pentium-pro overdrive processors.
Same thing happens with kernel configured as UNIprocessor.
Here it is:
(src)4998}cd /sys/i386/compile/pro2/
(pro2)4999}gdb -k kernel.debug
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
(kgdb) l *0xc01f6212
0xc01f6212 is in device_shutdown (../../../kern/subr_bus.c:1499).
1494}
1495
1496int
1497device_shutdown(device_t dev)
1498{
1499if (dev-state DS_ATTACHED)
1500return (0);
1501return (DEVICE_SHUTDOWN(dev));
1502}
1503
(kgdb)
==
|| [EMAIL PROTECTED] ||
|| Ph. (415) 681-6235 ||
==
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
lock order reversal (2 different items)
Has anyone come across this before? dc0: promiscuous mode enabled Jun 20 09:56:15 router kernel: dc0: promiscuous mode enabled lock order reversal 1st 0xc05a0100 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:375 2nd 0xc1f5d7bc dc0 (network driver) @ /usr/src/sys/pci/if_dc.c:3543 dc0: promiscuous mode disabled --this happened when I did a tcpdump -nnxXv for my dc0 interface. I also got this one on boot today (gg cable company): Entropy harvesting: interrupts ethernet point_to_point . lock order reversal 1st 0xc1fb65c0 process lock (process lock) @ /usr/src/sys/kern/kern_descrip.c:2112 2nd 0xc200ac34 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:2119 swapon: adding /dev/ad0s1b as swap device --Noticed it on boot, figured it'd be worth a mention It only happens one time per boot (which isnt often). Here's some stats on it: [EMAIL PROTECTED] harm $ uname -a FreeBSD router.XX.com 5.0-RELEASE-p7 FreeBSD 5.0-RELEASE-p7 #6: Sun Jun 15 01:09:07 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/Router i386 CPU: Pentium III/Pentium III Xeon/Celeron (448.80-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs real memory = 201261056 (191 MB) avail memory = 188223488 (179 MB) As you can see, the sources are fairly new (Jun 14th is the last time I grabbed and built them). If anyone has any ideas/suggestions or if you need anything more off of me (Im sorry, Im fresh out of money to give out) ;) I'll be more than happy to provide with what I can. Thanks! Regards, Nick H. [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: APM problem in 5.1-RELEASE
You can create a script like this:
--
#!/bin/sh
for i in `fstat /dev/acd0 | awk '{print $3}'`
do
kill -9 $i
#echo add deny all from any to $i /etc/ipfw.rules
done
---
that will kill all processes that using acd0
Maybe that helps.
aLex
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jesse Guardiani
Sent: Friday, June 20, 2003 11:59 AM
To: [EMAIL PROTECTED]
Subject: Re: APM problem in 5.1-RELEASE
Jesse Guardiani wrote:
Things I would like to improve upon:
1.) I need to find some way to automatically kill any processes that are
using (or have opened) the /dev/acd0 device BEFORE executing apm -z
from /etc/rc.suspend.
OK. The following pipeline does a pretty good job of this:
# Kill any process currently using /dev/acd0
kill -KILL `fstat /dev/acd0 | sed -Ee 's/[[:space:]]+/ /g' | cut -d ' ' -f
3`
It isn't perfect (i.e. if more than one process has /dev/acd0 open, it won't
kill the second process), but I can expand on this to make it fit just about
any need.
[...]
2.) I'd love to automate (or do away with) the process of switching to
a VTY from X before executing 'atacontrol detach 1'.
This from Tobias Roth:
-
to do this automatically, change your /etc/rc.suspend and /etc/rc.resume
like this:
/etc.rc.suspend: insert this line just before the 'logger' line:
vidcontrol -s 2 /dev/ttyv0
/etc/rc.resume: insert this line just before the 'logger' line:
vidcontrol -s 1 /dev/ttyv0
-
This works pretty darn well! Thanks Tobias!
I can now suspend my machine from X without fear of kernel panic!
Thanks for the help everyone!
Here is my rc.suspend, just in case someone else with an IBM Thinkpad A30p
needs it:
-- /etc/rc.suspend --
#!/bin/sh
#
# Copyright (c) 1999 Mitsuru IWASAKI
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/etc/rc.suspend,v 1.4 2000/10/08 19:18:24 obrien Exp $
#
# sample run command file for APM Suspend Event
if [ -r /var/run/rc.suspend.pid ]; then
exit 1
fi
echo $$ /var/run/rc.suspend.pid
# If you have troubles on suspending with PC-CARD modem, try this.
# See also contrib/pccardq.c (Only for PAO users).
# pccardq | awk -F '~' '$5 == filled $4 ~ /sio/ \
# { printf(pccardc power %d 0, $1); }' | sh
logger -t apmd suspend at `date +'%Y%m%d %H:%M:%S'`
# Kill any process currently using /dev/acd0
kill -KILL `fstat /dev/acd0 | sed -Ee 's/[[:space:]]+/ /g' | cut -d ' ' -f
3`
# switch to a TTY
vidcontrol -s 1 /dev/ttyv0
# detach buggy CD-ROM before suspending.
sync sync sync
atacontrol detach 1
sleep 1
sync sync sync
sleep 1
rm -f /var/run/rc.suspend.pid
zzz
exit 0
-- end /etc/rc.suspend --
And here is my /etc/rc.resume:
-- /etc/rc.resume --
#!/bin/sh
#
# Copyright (c) 1999 Mitsuru IWASAKI
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
acpiconf -s4 cannot wake up: ACPI bug, kernel bug, BIOS bug?
Hi, I have a i386 machine with Gigabyte 7ZXR mainboard here (Duron, VIA KT133 chipset, AMI BIOS). acpiconf -s1 and -s5 are apparently working ok, -s2 is refused (OK), -s3 is refused (might be I didn't set the jumper correctly :o) and -s4 puts the machine to some sort of sleep (power LED blinks, screen blanks, ATA hard drives park), but it doesn't properly wake up from S4. It tries to, spins the disks up, I can see a screen, but cannot type anything; the machine goes back into s4 right away, and is in a permanent loop, lay down to S4-sleep and wake up. Pressing NUM LOCK doesn't toggle the NUM LOCK LED. X11 hasn't been started, just text console mode. Any ideas, or questions for more detail? -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Email accounts on FreeBSD 5.1-RELEASE
I got a question, if I want to create an email account on my Freebsd 5.1 box, but not let them have shell access do I just do a adduser and specify /sbin/nologin? Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Email accounts on FreeBSD 5.1-RELEASE
Alex Ayala writes: I got a question, if I want to create an email account on my Freebsd 5.1 box, but not let them have shell access do I just do a adduser and specify /sbin/nologin? If I want an off-road vehicle, do I just buy a Land Rover? It usually comes to quite a lot more than that, depending on what it is you want to do _exactly_. The above will work in certain circumstances, but simple testing will tell you that. What we can't tell is whether you need a Land Rover or a Bulldozer. :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Email accounts on FreeBSD 5.1-RELEASE
Ok, maybe...yes I read what I wrote and didn't quite explain what I really wanted to say. I want to setup accounts on my box so users can retrieve emails by accessing my pop server. Do I need to setup user accounts on my box with the adduser command? I don't want them to be able to have access to the shell by any means. Is like when I wanted to give someone access to my ftp server I just created an account and took out the shell part in the passwd file. Sorry my english is not the greatest. Trying to explain something and can't find the right words. Is that a bit better to understand? A -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Murray Sent: Friday, June 20, 2003 4:51 PM To: Alex Ayala Cc: [EMAIL PROTECTED] Subject: Re: Email accounts on FreeBSD 5.1-RELEASE Alex Ayala writes: I got a question, if I want to create an email account on my Freebsd 5.1 box, but not let them have shell access do I just do a adduser and specify /sbin/nologin? If I want an off-road vehicle, do I just buy a Land Rover? It usually comes to quite a lot more than that, depending on what it is you want to do _exactly_. The above will work in certain circumstances, but simple testing will tell you that. What we can't tell is whether you need a Land Rover or a Bulldozer. :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
acpi patch for dell laptop?
Where can I find the latest, greatest patch that fixes this? ACPI-0293: *** Warning: Buffer created with zero length in AML -0166: *** Error: UtAllocate: Attempt to allocate zero bytes ACPI-0293: *** Warning: Buffer created with zero length in AML -0166: *** Error: UtAllocate: Attempt to allocate zero bytes ACPI-0293: *** Warning: Buffer created with zero length in AML -0166: *** Error: UtAllocate: Attempt to allocate zero bytes Dell Inspiron 3700 Thanks, -Mike -- Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Email accounts on FreeBSD 5.1-RELEASE
Alex Ayala writes: Ok, maybe...yes I read what I wrote and didn't quite explain what I really wanted to say. I want to setup accounts on my box so users can retrieve emails by accessing my pop server. Do I need to setup user accounts on my box with the adduser command? I don't want them to be able to have access to the shell by any means. Is like when I wanted to give someone access to my ftp server I just created an account and took out the shell part in the passwd file. Sorry my english is not the greatest. Trying to explain something and can't find the right words. Is that a bit better to understand? Sort of. But you need to understand how to specify and set up a secure system. What is your threat model? What resources are your (ab)users most likely to throw at you, and what are the consequences if they succeed? How much can you afford to spend to prevent this compared with what you guess they are prepared to spend to attack you? Only you can answer these questions. Once you know the comprehensive answer to these questions, you know what to ask of the software and hardware you investigate to perform the task. While you are asking the questions, _experiment_ with what you have, and look for real-life holes in your setup. Try to think like the attacker you are trying to thwart. Attack yourself. Get paranoid. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi patch for dell laptop?
On Fri, Jun 20, 2003 at 05:29:30PM -0400, Mike Sturdee wrote: Where can I find the latest, greatest patch that fixes this? Try this URL: http://sandcat.nl/~stijn/freebsd/dell.php and let me know if it works. --Stijn -- Man had always assumed that he was more intelligent than dolphins because he had achieved so much... the wheel, New York, wars, and so on, whilst all the dolphins had ever done was muck about in the water having a good time. But conversely the dolphins believed themselves to be more intelligent than man for precisely the same reasons. -- Douglas Adams, The Hitchhikers Guide To The Galaxy pgp0.pgp Description: PGP signature
Re: acpi patch for dell laptop?
I just found that one and was trying it as this mail came in.. It looks to work w/o any side-effects Thanks! -Mike On Sat, 21 Jun 2003, Stijn Hoop wrote: On Fri, Jun 20, 2003 at 05:29:30PM -0400, Mike Sturdee wrote: Where can I find the latest, greatest patch that fixes this? Try this URL: http://sandcat.nl/~stijn/freebsd/dell.php and let me know if it works. --Stijn -- Man had always assumed that he was more intelligent than dolphins because he had achieved so much... the wheel, New York, wars, and so on, whilst all the dolphins had ever done was muck about in the water having a good time. But conversely the dolphins believed themselves to be more intelligent than man for precisely the same reasons. -- Douglas Adams, The Hitchhikers Guide To The Galaxy -- Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi patch for dell laptop?
On Sat, Jun 21, 2003 at 12:13:10AM +0200, Stijn Hoop wrote: On Fri, Jun 20, 2003 at 05:29:30PM -0400, Mike Sturdee wrote: Where can I find the latest, greatest patch that fixes this? Try this URL: http://sandcat.nl/~stijn/freebsd/dell.php and let me know if it works. I was also seeing this errors on a Dell Inspiron 8200, until I followed your instructions. Thank you for making apci (and more importantly the battery level) work again! -- Morten Rodal pgp0.pgp Description: PGP signature
Re: acpi patch for dell laptop?
On Fri, 20 Jun 2003, Mike Sturdee wrote: I just found that one and was trying it as this mail came in.. It looks to work w/o any side-effects Unfortunatly it doesn't work for Inspiron 7500 and 5000 models.. Thanks! -Mike Try this URL: http://sandcat.nl/~stijn/freebsd/dell.php ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ThinkPad T20 with 5.0R wakes up from halt -p
I concur. My T22 also experiences the same problems:- - On transition to ACPI state S3: - LCD backlight stays on (until lid closed) - Drive spins down immediately - On transition to ACPI state S5: - Machine turns on unexpectedly (*probably* 15 minutes later) I am currently experiencing panics which appear to be related to ACPI, although I am actively hacking on the csa(4) driver to fix its suspend/resume functions. These appear to work fine under APM, however, using APM loses Ultrabay 2000 hot swap functinality. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
SMP CPU_SUSP_HLT
Hello gentlemen, it seems CPU_SUSP_HLT does nothing for SMP kernels. i386/i386/machdep.c: #ifdef SMP static int cpu_idle_hlt = 0; #else static int cpu_idle_hlt = 1; #endif It's noted that when enabled it will result in about 4.2% loss in performance while doing buildworld. I haven't checked with that, but I tested single-threaded applications to suffer for about 2%, what shouldn't be a big difference. Beyond power consumption, suspend on HLT may solve some overheating issues common for multiprocessor systems. At least, it does so in my case. I suggest to remove #ifdef SMP, and place a warning into NOTES. Let people decide. --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_ntfs causes panic
On Fri, Jun 20, 2003 at 11:41:57PM +0900, NAKAJI Hiroyuki wrote: In [EMAIL PROTECTED] Tim Robbins [EMAIL PROTECTED] wrote: /etc/fstab: /dev/ad0s2 /mnt/winnt ntfsro,noauto 0 0 When mount /mnt/winnt, the system falls into DDB. This looks like a bug in the buffer cache code. I'm working on trying to fix it. Mounting read-write instead of read-only ought to work around the problem, but it's probably not very safe. Thanks for support. I updated the kernel on another PC from yesterday's source (cvsup-ed about Jun 19 14:00 JST) and, what a miracle, mount_ntfs did not get system panic. I'll try the latest kernel on the PC on which I found this problem. I've committed a fix for this bug to CVS. Thanks for reporting it! Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Software watchdog patch
Greetings. I've been working on a patch which adds software watchdog to the FreeBSD 5.1-CURRENT kernel. Below is an URL to the patch to my work, and I'd appreciate it if anybody interested in this venture would give me their feedback on what I've got and also help debug it. The patch is available here: http://www.sean-kelly.org/watchdog.diff My watchdog patch is two pieces. One half is a kernel patch which adds the watchdog timer checker to hardclock() in sys/kern/kern_clock.c. It also adds a watchdog_fire() function which performs various things on a watchdog timeout. The userland half of the patch adds a watchdogd daemon which periodically wakes up from a sleep to notify the kernel that the userland is still intact. This patch also adds a watchdogd(8) manpage, a watchdog(4) manpage, and an /etc/rc.d/watchdogd startup script. In order to utilize the watchdog, you must build a kernel with options WATCHDOG It is also advised that you enable watchdogd to /etc/rc.conf: watchdogd_enable=YES Three new sysctls are added: debug.watchdog.enabled When this is non-zero, the watchdog is active and hardclock() is verifying that the watchdog timer has not timed out. debug.watchdog.timeout: 20 This is the number of seconds the watchdog can go without a timer update. debug.watchdog.reset: 0 When this sysctl is touched (read/write), it resets the watchdog_ticks kernel variable to the value of ticks. When (ticks - watchdog_ticks) watchdog.timeout seconds, the watchdog fires by calling watchdog_fire(). When the watchdog fires (watchdog_fire()), different things happen depending on the kernel configuration. First, interrupt counts are dumped to the console. Then, if your kernel was built with DDB support, you will get a backtrace and be dropped to the DDB prompt. If your kernel has no DDB support, your kernel will panic and presumably reboot itself. Note that I attempted to stick to style(9). If I did not, please point out my mistakes and I'll be happy to fix them. Also note that this is my first venture writing manpages from scratch, so feel free to tear them apart and mock me. However, I did read mdoc(7) and check them for warnings. I look forward to any feedback, whether positive or negative. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Wi driver has WEP issues on both 5.0 and 5.1
A head up about the wi driver in FreeBSD 5.0 and 5.1. I have a netgear MA-311 card that supports HostAP mode. The issue is that I get a busy bit error. The exact error starts with the following.. THIS ONLY OCCURS WHEN WEP IS ENABLED: wi0: timeout in wi_seek to fc00/0; last status 800b We then move on to : wi0: wi_cmd: busy bit won't clear. This seems to cycle until the next error: wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: mgmt. Buffer allocation failed Then back through the entire error sequence again. Eventually the box will freeze as these errors cycle and then free up again when it starts back at the timeout error. I was hopeful that the new wi driver in 5.1 would address this problem as I know several persons with Prism chipsets that have this very same issue on 5.0 and 5.1. Please respond directly as I am not on -current mailing list. Thanks Ray ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wi driver has WEP issues on both 5.0 and 5.1
Date: Sat, 21 Jun 2003 00:32:45 -0400 From: BSDVault [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] A head up about the wi driver in FreeBSD 5.0 and 5.1. I have a netgear MA-311 card that supports HostAP mode. The issue is that I get a busy bit error. The exact error starts with the following.. THIS ONLY OCCURS WHEN WEP IS ENABLED: wi0: timeout in wi_seek to fc00/0; last status 800b We then move on to : wi0: wi_cmd: busy bit won't clear. This seems to cycle until the next error: wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: mgmt. Buffer allocation failed Then back through the entire error sequence again. Eventually the box will freeze as these errors cycle and then free up again when it starts back at the timeout error. I was hopeful that the new wi driver in 5.1 would address this problem as I know several persons with Prism chipsets that have this very same issue on 5.0 and 5.1. Please respond directly as I am not on -current mailing list. I have seen the same ting, but only when three is an attempt to associate with an AP that has a different WEP key. It can happen with either 40 or 108 bit encryption. As a result, I now build my kernel without the wi driver and only load it when I need it. I don't know if Warner has seen this. Cross-post to FreeBSD lists is frowned upon, but I am tempted to send this to mobile. It's where these issues are most heavily discussed. I'm not sure if I ever saw this with V4.6 or 4.7. I have seen it on V5 since I moved to current late last year. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with USB ulpt0 and CUPS
On Wed, 18 Jun 2003, Thomas T. Veldhouse wrote: I posted this in April and received no response. However, this has been an ongoing issue since at least 2001 (where I found the first reference to this trouble via Google). The problem seems to be that the FreeBSD USB LPT driver (even with no-reset) is somehow dropping the first bits of the data stream, causing a page full of trash to be printed prior to the actual print job. I have no verified this problem with 5.1-RELEASE as well. FWIW, I had similar problems with USB printer and 4.7. Inserting a sleep(1) between opening the device and the first write proved to be a sufficient workaround. $.02, /Mikko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
