Re: Crash in g_dev_strategy / CURRENT as of yesterday.
In message <[EMAIL PROTECTED]>, Eivind Olsen writes:
>--On 12. august 2003 20:39 +0100 Peter Edwards
><[EMAIL PROTECTED]> wrote:
>>> # 10 0xc04f3c65 in trap (frame=
>>> {tf_fs = -1059913704, tf_es = -890109936, tf_ds = -1070268400,
>>> tf_edi
>>> = -1040540480, tf_esi = -978597456, tf_ebp = -890095148, tf_isp =
>>> -890095220, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 16343040,
>>> tf_trapno = 12, tf_err = 2, tf_eip = -1070560519, tf_cs = 8, tf_eflags
>>> =
>>> 66054, tf_esp = -978597456, tf_ss = -1067143852}) at
>>> /usr/src/sys/i386/i386/trap.c:420
>> Look at tf_eip: -1070560519 = 0xc0308af9
>> What does "list *0xc0308af9" show in gdb?
>
>(kgdb) list *0xc0308af9
>0xc0308af9 is in g_dev_strategy (/usr/src/sys/geom/geom_dev.c:401).
>396 KASSERT(cp->acr || cp->acw,
>397 ("Consumer with zero access count in g_dev_strategy"));
>398
>399 bp2 = g_clone_bio(bp);
>400 KASSERT(bp2 != NULL, ("XXX: ENOMEM in a bad place"));
>401 bp2->bio_offset = (off_t)bp->bio_blkno << DEV_BSHIFT;
>402 KASSERT(bp2->bio_offset >= 0,
>403 ("Negative bio_offset (%jd) on bio %p",
>404 (intmax_t)bp2->bio_offset, bp));
>405 bp2->bio_length = (off_t)bp->bio_bcount;
>(kgdb)
Ohh, damn, I still have that stuff uncommitted. Will fix!
--
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: [acpi-jp 2583] ACPI sleep_delay caused reboot
On Mon, 11 Aug 2003, Anish Mistry wrote: > I cvsup'd over the weekend and my laptop started to reboot after the second > resume. I checked the hw.acpi.sleep_delay and the default value seems to be > changed to 5. This would happen with earlier ACPI imports, but the default > was zero, so it would be fine. Can't seem to get and crash dumps since it > just restarts. I'll send the dmesg and acpidump info when I'm back at home. > - -- > Anish Mistry For a workaround, do: echo hw.acpi.sleep_delay=0 >> /etc/sysctl.conf Unfortunately, we can't have it both ways and the delay helps some users so you'll have to use this until we find what's wrong. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAN disk with freebsd?
< said: >> - Windows on the same loop as anything else > Liberal use of zoning should help that. Each Windows HBA should be in a > seperate zone. This is from personal experience and also assumes you are > using a switched fabric. I said ``loop'' for a reason. The configuration that we were sold is pure FC-AL. No fabrics. Don't do that, it's bad for your sanity. If you can't afford a switch, you can't afford Fibre Channel. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird reboots from bootmgr or loader
Hi, I also got the same BTX error during boot up. :( I used 4.8-RELEASE CD to boot till loader starts up, changed currdev/loaddev/kernel etc to the -CURRENT setting and let system boot. From: "Florian Smeets" <[EMAIL PROTECTED]> Date: Wed, 6 Aug 2003 09:43:18 +0200 (CEST) :: ::> On Tue, 5 Aug 2003, John-Mark Gurney wrote: ::> ::>> Are you running -current w/ a kernel from the last 24 hrs? (After ::>> phk's mass swap check in?) If so, make sure your swap isn't at the ::>> start of your disk. If it is, phk was nice enough to only blow away ::>> your boot blocks instead of your disk label too. :) Swap currently ::>> uses all but the first page (4k on i386). ::> ::> Argl, YES, swap _is_ the first partition: :: ::Yes same here! Same here, as well. :( ::> ::> Does that mean I have to rearranged or never build world again? :: ::Yeah good question, what can we do ? May be, we have to run 'bsdlabel -B' just before shutting down system, everytime, until it gets fixed. :( Regards, Haro =--- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Kubota Graphics Technology Inc. /|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dual P4 2.4Ghz Xeon With Hyperthreading enabled...
No doubt this has been answered before, but I have an asus p4pe with a 3.06 p4. Naturally, it is enabled in the bios. To enable hyperthreading do I need to recompile my kernel with smp support, and if so...does this apply to freebsd 5.1 release as well? (my friend wants to know). Additionally does changing the machdep.cpu_idle_hlt to zero make it faster? Thanks in advance. David R. Colyer On Wednesday 13 August 2003 10:52 am, John Baldwin wrote: > On 13-Aug-2003 Dr. Richard E. Hawkins wrote: > > On Wed, Aug 13, 2003 at 11:35:14AM -0400, John Baldwin wrote: > >> On 13-Aug-2003 Dr. Richard E. Hawkins wrote: > >> > On Tue, Aug 12, 2003 at 08:33:57PM -0500, Cagle, John (ISS-Houston) wrote: > >> >> I think the valid settings are only 0 or 1, with the default being 1 > >> >> which will disable all logical CPUs. If you want to enable the extra > >> >> logical CPUS, then set it to 0 (zero). They will come online > >> >> immediately. > >> > > >> > That can't be right. I've never done anything to configure the > >> > logical cpus on mine; they just showed up unexpectedly when i switched > >> > from stable to current. Now I have: > >> > > >> > slytherin ttyp1:hawk>sysctl -a | grep cpu > >> > kern.threads.virtual_cpu: 4 > >> > kern.ccpu: 1948 > >> > kern.smp.cpus: 4 > >> > hw.ncpu: 4 > >> > machdep.cpu_idle_hlt: 1 > >> > machdep.hlt_cpus: 10 > >> > machdep.hlt_logical_cpus: 1 > >> > machdep.logical_cpus_mask: 10 > >> > > >> > It launches four logical cpus all on it's own. It did panic during > >> > shutdown yesterday; If I read the messages right as it flashed by, it > >> > was because cpu#2 got the shutdown order. > >> > >> Your logical CPU's aren't doing anything though, even though they are > >> started up. John's explanation is correct. > > > > I've also got the report in dmesg, > > > > SMP: AP CPU #1 Launched! > > SMP: AP CPU #2 Launched! > > SMP: AP CPU #3 Launched! > > > > > > Doesn't this mean that they *are* active? > > No, it means the kernel has started them up. CPU's whose bits are set > in machdep.hlt_cpus don't execute any user tasks. Instead, they just > sit in a loop executing the 'hlt' instruction doing nothing but servicing > interrupts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dual P4 2.4Ghz Xeon With Hyperthreading enabled...
On Thu, Aug 14, 2003 at 09:59:58AM -0600, David R. Colyer wrote: > No doubt this has been answered before, but I have an asus p4pe with a 3.06 > p4. Naturally, it is enabled in the bios. To enable hyperthreading do I > need to recompile my kernel with smp support, and if so...does this apply to > freebsd 5.1 release as well? (my friend wants to know). Additionally does > changing the machdep.cpu_idle_hlt to zero make it faster? Thanks in advance. Yes, you need SMP support in all releases. As to your second question, define faster. It depends heavily on your appliction mix. My guess is that on a UP system which is doing something other then running a single compute bound process it's going to be a minor win, but only measurement will tell you anything. -- Brooks pgp0.pgp Description: PGP signature
Re: HEADSUP: pca driver being retired.
Well I'm not too happy about this.. It's the only audio I have on my TI-810 laptop. That is however not running -current yet. I'm also not pleased from the perspective that this is the only major example in the tree of how to use the clock-speedup code in i386/isa/clock.c. A very nice piece of functionality I use quite often. What is youir reason for shooting a working piece of code? (well it works in 4.x.. I haven't tried it in 5.x?) (other than it offends you in some way) On Wed, 13 Aug 2003, Poul-Henning Kamp wrote: > > I plan to remove the pca driver in about a week. > > Protest only from actual users respected. > > If you don't know what pca is or what it does, do not even send email. > > Thank you! > > -- > 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]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
I just noticed a problem with periodic scripts inside a jail. I'm getting:
Local system status:
tee: /dev/stderr: Operation not supported
Mail in local queue:
tee: /dev/stderr: Operation not supported
Mail in submit queue:
tee: /dev/stderr: Operation not supported
in the periodic daily, weekly, monthly and security reports. But if I mount
the fdescfs on the jail, then these errors go away.
So we need to add the following to the new jail script
jail_start()
{
:
eval jail_devfs=\"\$jail_${_jail}_devfs\"
[ -z ${jail_devfs} ] && jail_devfs="NO":
eval jail_fdescfs=\"\$jail_${_jail}_fdescfs\"
[ -z ${jail_fdescfs} ] && jail_fdescfs="NO"
:
if checkyesno jail_devfs ; then
mount -t devfs dev ${jail_devdir}
if checkyesno jail_fdescfs ; then
mount -t fdescfs fdesc ${jail_devdir}/fd
fi
:
fi
:
}
jail_stop()
{
:
eval jail_devfs=\"\$jail_${_jail}_devfs\"
[ -z ${jail_devfs} ] && jail_devfs="NO":
eval jail_fdescfs=\"\$jail_${_jail}_fdescfs\"
[ -z ${jail_fdescfs} ] && jail_fdescfs="NO"
:
if checkyesno jail_devfs ; then
if [ -d ${jail_devdir} ] ; then
if checkyesno jail_fdescfs; then
umount -f ${jail_devdir}/fd >/dev/null 2>&1
fi
umount -f ${jail_devdir} >/dev/null 2>&1
fi
fi
:
}
The only decsion we need to make is wheter to always mount the fdescfs when
devfs is mounted on the jail, or have a variable to enable mounting of the
fdescfs (jail_*_fdescfs).
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ffsinfo missing in 5.1-RELEASE
On Wed, 13 Aug 2003, Robert Watson wrote: > The only problem with this patch is that we lose the ability to do the > "START BLOCK SUMMARY AND POSITION TABLE" display for UFS1. I'm not sure > this is a big issue; I will go ahead and commit it with those #ifdef'd > out (rather than removed as is the case in the patch) and look for advice > on reintroducing them from someone with more UFS expertise than me. Robert, I'll have a look at it once it's back in the tree, maybe I find out what to do about it. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel hangs at serial port during boot (solved)
walt wrote: > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > I changed the Plug-n-Play BIOS setting and now it works normally again. I also changed the ACPI-aware-OS BIOS setting to YES and I notice that the acpi.ko module is now loading at boot, which it didn't before. I think this is an old thing that I didn't notice until today, however. What surprised me is that the machine has been working for years with the 'wrong' BIOS setting and just now stopped working. Were there some kernel changes recently which would account for this? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
clock works slowly when I change CPU speed
I have a problem about clock when I change CPU speed (hw.acpi.cpu). The default hw.acpi.cpu status of my ThinkPad A22e is # sysctl hw.acpi.cpu hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 8 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 and, the clock value of "top" tool updates per 2 seconds normally, like as "01:21:45", "01:21:47", "01:21:49",... (because the default delay between updates is 2 seconds) When I change CPU speed as sysctl -w hw.acpi.cpu.performance_speed=4 the clock value of "top" tool updates by 1, per 2 seconds, like as "01:22:45", "01:22:46", "01:22:47",..., but per 2 seconds. So, the clock of "top" tool works on half speed of the real world. (I compare the clock value of "top" tool and the clock value of my video recorder. The problem also occur when I restart "top" tool after changing CPU speed) This problem occurs not only to using "top" tool, but to executing "while :; do date; sleep 1; done" on bash prompt, (When CPU speed is 4, the time value updates by 1 per 2 seconds) and to executing "kldload snd_ich" by hand after booting. (When CPU speed is not 8, the result of link rate is wrong. The normal value is about 48000 Hz, but when CPU speed is 4, it gets double value of normal link rate) This problem did not exist when I did cvsup on Aug 2. This problem exists since when I did cvsup on Aug 9. I did cvsup on Aug 13 again, but this problem still exists. And, when I use backuped kernel of Aug 2, by changing value of "module_path" on boot prompt, this problem does not occur. (So I do not think my ThinkPad A22e has broken) -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TESTERS WANTED for ATAng preview 1
Hi, I've just compiled ATAng into my kernel, and I'm currently running it - but I had to rip out my CD-ROM to make it work. I wasn't able to grab the exact wording of the error, but it was something along the lines of a failure to identify ata1-slave - which I suppose is my CD-ROM player. It then retries and gets an error (error=0), then freezes. This is a IBM ThinkPad T21, so taking out the CD-ROM is a trivial task, but at some point I'm gonna need it again (it's actually a DVD/CD-RW combodrive)... Otherwise the driver seems to work with the 60gb IBM drive I have in my laptop. No funny behaviour so far. ;) Best regards, /Eirik pgp0.pgp Description: PGP signature
Re: FreeBSD 5.1-R kernel panic
On Thu, Aug 14, 2003 at 10:57:07AM -0600, Stephane Raimbault wrote: > Hi Bosko, > > This is the output of sysctl vm.zone about 2 minutes before the crash > occured. let me know if there is anything else I can provide you for this > crashing problem. H. I don't know, maybe you really do have a machine too loaded for the KVA you have configured... I have to re-iterate that it's extremely important that you double-check that you are in fact in sync with the latest -current and _NOT_ RELENG_5_1. Make sure you're building at least version 1.73 of src/sys/vm/uma_core.c (grep FBSDID src/sys/vm/uma_core.c). With that said, you can try the following: options KVA_PAGES=400 in your kernel configuration file. Following that, you can do this: kern.vm.kmem.size=4 In your /boot/loader.conf Make sure to not set NMBCLUSTERS too high. Around 8K is probably more than enough, but you should look at how much you're using on average with `netstat -m' and then set the number to roughly 3 times that. If following this your crash persists, even if after a longer time, then I would suspect (another?) race. Again, I have to re-iterate that you really need to make sure you're supping to HEAD: *default release=cvs tag=. Regards, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ffsinfo missing in 5.1-RELEASE
On Thu, 14 Aug 2003, Lukas Ertl wrote: > On Wed, 13 Aug 2003, Robert Watson wrote: > > > The only problem with this patch is that we lose the ability to do the > > "START BLOCK SUMMARY AND POSITION TABLE" display for UFS1. I'm not sure > > this is a big issue; I will go ahead and commit it with those #ifdef'd > > out (rather than removed as is the case in the patch) and look for advice > > on reintroducing them from someone with more UFS expertise than me. > > I'll have a look at it once it's back in the tree, maybe I find out what > to do about it. It's in my commit queue for today, so hopefully that opportunity will come quickly :-). I haven't managed to track down much about cg_blks() yet -- it disappeared with UFS2 coming in, so it will probably just take checking out an older tree and pushing it forward again for UFS1 dumping. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: M_NOTIFICATION in ?
While trying to port the SCTP-KAME code to CURRENT, I noticed that M_NOTIFICATION is missing from in CURRENT, but it is present in the KAME version of this file. Any reason not to apply this patch? --- sys/sys/mbuf.h.orig Sat Sep 13 19:34:07 2003 +++ sys/sys/mbuf.h Sat Sep 13 19:34:14 2003 @@ -164,6 +164,8 @@ #defineM_FIRSTFRAG 0x1000 /* packet is first fragment */ #defineM_LASTFRAG 0x2000 /* packet is last fragment */ +#define M_NOTIFICATION 0x8000 /* notification event */ + /* * External buffer types: identify ext_buf type. */ I don't know what M_NOTIFICATION is used for but if it's applied sparingly it might be better to use an m_tag instead. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: LOR: sigacts vs Giant
On 13-Aug-2003 Marcel Moolenaar wrote: > Gang, > > When the copyout() in sendsig() fails and we call sigexit(), we get > into the following LOR: > > lock order reversal > 1st 0xe000300ffca8 sigacts (sigacts) @ kern/subr_trap.c:260 > 2nd 0xe0b75250 Giant (Giant) @ kern/kern_sig.c:2407 > Stack backtrace: > witness_lock > Stopped at Debugger+0x31:nop.m 0x0 > db> trace > Debugger(0xe0a41340, 0xe078abe0, 0xea3, 0x1) at Debugger+0x30 > witness_lock(0xe0b75250, 0x8, 0xe0a3cdc9, 0x967) at > witness_lock+0xf60 > _mtx_lock_flags(0xe0b75250, 0x0, 0xe0a3cdc0, 0x967, > 0xe0747470, 0x30d, > 0xe0a5c661) at _mtx_lock_flags+0x130 > sigexit(0xe0002fa4c000, 0xb, 0xe0002f94afc8, 0xe09ebfe0) at > sigexit+0x140 > sendsig(0x4005fbf0, 0x2, 0xa0002308d360, 0x0) at sendsig+0x520 > postsig(0x2, 0xe0002fa4c000, 0xe000300ff000, 0xe0002f94afc8) at > postsig+0x7f0 > ast(0xa0002308d400) at ast+0x820 > : > > FYI, sendsig() on ia64 drops the lock around the copyout, see line 921 in machdep.c. It is not reacquired again until the very end of the function. You could change the assert at the top of the function to say that sigacts is not recursed, but sigacts is already a non recursive lock. Do you have local diffs to HEAD? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ffsinfo missing in 5.1-RELEASE
On Wed, 13 Aug 2003, Ulrich Spoerlein wrote: > I just used growfs (nice tool btw) and noticed that growfs(8) has a > reference to ffsinfo(8). But neither ffsinfo(8) nor the binary are > present on my 5.1 System. I already submitted a PR bin/53517, which has a patch that repairs ffsinfo on -CURRENT. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about porting KAME IPv6 to CURRENT
Craig Rodrigues wrote: > Is anyone actively working on importing the latest IPv6 implementation > from KAME to CURRENT? Not offically anyway, it seems. SUZUKI Shinsuke <[EMAIL PROTECTED]> mentioned his plans on KAME synchronisation: http://www.freebsd.org/cgi/getmsg.cgi?fetch=577922+582433+/usr/local/www/db/text/2003/freebsd-current/20030608.freebsd-current yet he does consider SCTP to be a late addition. -- Dean C. Strik Eindhoven University of Technology [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dual P4 2.4Ghz Xeon With Hyperthreading enabled...
No doubt this has been answered before, but I have an asus p4pe with a 3.06 p4. Naturally, it is enabled in the bios. To enable hyperthreading do I need to recompile my kernel with smp support, and if so...does this apply to freebsd 5.1 release as well? (my friend wants to know). Additionally does changing the machdep.cpu_idle_hlt to zero make it faster? Thanks in advance. David R. Colyer On Wednesday 13 August 2003 10:52 am, John Baldwin wrote: > On 13-Aug-2003 Dr. Richard E. Hawkins wrote: > > On Wed, Aug 13, 2003 at 11:35:14AM -0400, John Baldwin wrote: > >> On 13-Aug-2003 Dr. Richard E. Hawkins wrote: > >> > On Tue, Aug 12, 2003 at 08:33:57PM -0500, Cagle, John (ISS-Houston) wrote: > >> >> I think the valid settings are only 0 or 1, with the default being 1 > >> >> which will disable all logical CPUs. If you want to enable the extra > >> >> logical CPUS, then set it to 0 (zero). They will come online > >> >> immediately. > >> > > >> > That can't be right. I've never done anything to configure the > >> > logical cpus on mine; they just showed up unexpectedly when i switched > >> > from stable to current. Now I have: > >> > > >> > slytherin ttyp1:hawk>sysctl -a | grep cpu > >> > kern.threads.virtual_cpu: 4 > >> > kern.ccpu: 1948 > >> > kern.smp.cpus: 4 > >> > hw.ncpu: 4 > >> > machdep.cpu_idle_hlt: 1 > >> > machdep.hlt_cpus: 10 > >> > machdep.hlt_logical_cpus: 1 > >> > machdep.logical_cpus_mask: 10 > >> > > >> > It launches four logical cpus all on it's own. It did panic during > >> > shutdown yesterday; If I read the messages right as it flashed by, it > >> > was because cpu#2 got the shutdown order. > >> > >> Your logical CPU's aren't doing anything though, even though they are > >> started up. John's explanation is correct. > > > > I've also got the report in dmesg, > > > > SMP: AP CPU #1 Launched! > > SMP: AP CPU #2 Launched! > > SMP: AP CPU #3 Launched! > > > > > > Doesn't this mean that they *are* active? > > No, it means the kernel has started them up. CPU's whose bits are set > in machdep.hlt_cpus don't execute any user tasks. Instead, they just > sit in a loop executing the 'hlt' instruction doing nothing but servicing > interrupts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic while browsing with Opera 7
Hi,
Using PR/55509 I installed (native) Opera 7.2B3 on my -current as
of 2 days ago. I had 3 panics in only a couple of hours while using
Opera 7: 2 times with a GENERIC kernel, 1 time with a custom kernel.
They all look similar:
phys9911# cat /usr/crash/info.9
Good dump found on device /dev/ad0s2b
Architecture: i386
Architecture version: 1
Dump length: 259461120B (247 MB)
Blocksize: 512
Dumptime: Wed Aug 13 13:51:35 2003
Hostname: phys9911.phys.tue.nl
Versionstring: FreeBSD 5.1-CURRENT #4: Tue Aug 12 09:44:08 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KAYJAY
Panicstring: witness_warn
Bounds: 9
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc020c69c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc020ca27 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc02322c4 in witness_warn (flags=2, lock=0x0,
fmt=0xc03becc5 "System call %s returning")
at /usr/src/sys/kern/subr_witness.c:1076
#4 0xc03656cd in syscall (frame=
{tf_fs = 158072879, tf_es = -1078001617, tf_ds = -1078001617, tf_edi = 31,
tf_esi = 681549252, tf_ebp = -1079140596, tf_isp = -701428364, tf_ebx = 681557420,
tf_edx = 681549252, tf_ecx = 681271324, tf_eax = 9, tf_trapno = 22, tf_err = 2, tf_eip
= 681402736, tf_cs = 31, tf_eflags = 643, tf_esp = -1079140656, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1076
#5 0xc03554cd in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb)
Something useful in there? Or more info needed?
Karel.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Change to kernel+modules build approach
John Baldwin writes: > > On 14-Aug-2003 Ruslan Ermilov wrote: > > On Thu, Aug 14, 2003 at 02:10:19AM -0600, Scott Long wrote: > >> Luoqi Chen wrote: > > [...] > >> >On the other hand, all modules should create all the opt_*.h files > >> >it needs when built individually. Add opt_ddb.h to nullfs's Makefile > >> >should fix the breakage. > >> > > >> Our kernel build system isn't set up to handle passing config options > >> to modules. Various solutions to this have been proposed, but nothing > >> has appeared yet. In 5.x, we document that modules will not work with > >> PAE. > >> > > How does the below look? This is basically a more generic implementation > > of Luoqi's idea, but for -CURRENT: > > I would prefer something far more radical that would involve moving > all the module metadata to sys/conf (i.e. removing sys/modules) and > building all the modules based on a single kernel config file. Would this tie modules to that kernel config? If so, would it mean the end of the ability of 3rd party developers to ship binary drivers and expect them to work with any kernel? Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: M_NOTIFICATION in ?
On Wed, Aug 13, 2003 at 07:47:01PM -0400, Matthew Emmerton wrote: > > KAME guys have it here: > > http://orange.kame.net/dev/cvsweb.cgi/kame/freebsd5/sys/sys/mbuf.h?rev=1.5 > > The KAME snapshot of our source tree is 3 months out of date. The most > recent version of mbuf.h is here: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/mbuf.h?rev=1.122&content-type=text/plain > > We already have 0x8000 assigned, and the only free flags value is 0x4000 -- > but it conflicts with other private usages in the kernel (as per the CVS > comments.) > > Does SCTP-KAME really need a special flag value? OK, I am looking at the FreeBSD-4 source tree for KAME and found this: http://orange.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/sys/mbuf.h.diff?r1=1.18&r2=1.19 CVS comment: "sctp for freebsd4 - again, not ready for daily use yet" It looks like M_NOTIFICATION was added specifically for SCTP. I'll try to find out more about this. Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: howto: LiveCD FBSD question
Il Gio, 2003-08-14 alle 01:09, Usher Abraham ha scritto: > Does anyone have a howto on how to create a custom LiveCD (FreeBSD) > CDROM in English? http://www.freesbie.org/?section=doc-en Best Regards -- Rionda aka Matteo Riondato G.U.F.I Staff Member (http://www.gufi.org) BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda) GPG key at: http://www.riondabsd.net/riondagpg.asc Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: clock works slowly when I change CPU speed
Between Aug 2 and 9, there were no significant changes to ACPI. I imported the userland tools, added tunable access to an existing variable, and increased the default sleep delay from 0 to 5. The last one is the only functional change and can be undone by doing: sysctl hw.acpi.sleep_delay=0 Please try with an Aug. 2 kernel but load the latest acpi.ko to be sure this is not an acpi problem. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fbsd 4.8 make release question ?
How can the values for BIGBOOT image can be changed so if there is source patch for the system like ssp make release won;t fail when buidling release.9 stage ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
twe driver, 1+ terabyte array, fdisk and disklabel
So I'm having some problems with 5.1-RELEASE. I'm not sure if these have already been addressed but as I have found no mention of any of these problems on the mailing lists (web searchable anyway) or deja and google, I've subscribed myself to current and am looking for possible answers. :) I have a 3ware 7500-8. I also have 8 Western Digital "Special Edition" 250GB drives attached to said RAID card. I currently have one RAID-5 array configured for a total of 1.75T. There seem to be no real issues on the hardware side of this equation. I just grabbed the 5.1-RELEASE ISO and tried to install. No dice, although I have had mixed results. The disk geometry as reported (guessed actually, as it tells me the geometry reported by BIOS is obviously wrong and continues to remind me it's guessing every single time I move lines) in fdisk is 212808/255/63, for a grand total of 3418760520 sectors (again, as reported by fdisk). If I, at this point, say "use entire disk" it gives me roughly: --- offset size(st) endnameftype descsubtype flags 0 63 62 - 12unused 0 63 3418760457 3418760519 twed0s1 8 freebsd 165 -876206776 4536 3418765055 - 12unused 0 Obvious problems there. And also, why do there appear to be more sectors listed here than in the sectors reported at the top of the screen (3418765055 versus 3418760520)? And the negative offset. Riiight... :) So then I try to do dangerously dedicated mode. I eventually give up on the CLI and switch to wizard mode. I'm finally able to make it dedicated. So now I have: --- offset size(st) endnameftype descsubtype flags 0 3418765056 3418765055 twed0s1 8 freebsd 165 Yay. Now on to disklabel, right? Well, at this point, regardless of whether my fdisk looks like example 1 above or example 2, I get this in disklabel: --- Fatal Error: Partitions are larger than actual chunk?? - PRESS ANY KEY TO REBOOT Haha. There are only two ways I've found to make this work so far, and I'm not happy with either really. One is simple. Use RAID-10, and my disk array drops to 1T. Fast, but not what I'm looking for. The second is to use "create slice" in fdisk, and it puts the default number of 3.4 billion sectors in the field for the size of the slice I want to create. When I hit enter, it actually only ends up using 2 billion some odd sectors, and then I can create a second slice of the remaining drive. At that point, disklabel at least runs without dying right away, but then I have an approximately 1T slice followed by a 600 something gigabyte slice. Again, not what I'm looking for. Any advice? Are the disk tools just not 64 bit clean or something? Or is this a kernel, device driver or fs layer problem? -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas A&M Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a-- C++$ UBL+++$ P--->+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- This sentence no verb. end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help! 5.1 doesn't do the rc thing?
On Thu, 7 Aug 2003, Scot W. Hetzel wrote: > From: "Charlie Schluting" <[EMAIL PROTECTED]> > > OMG. > > So anyways, does anyone have a link to info about how the heck I start > > stuff in 5.1? > > Most important: > > -my lo0 interface doesn't have the 127.0.0.1 address.. it just comes up > > with no addy. > > -rc.conf didn't get run :( no named, no nothing :( > > -my firewall rules (rc.firewall) and sysctl.conf didn't seem to be read. > > > > Links, hints appreciated. > > > Do you have an /etc/rc.d directory and is it populated with files? > > If not, then run run mergemaster to update your /etc. > > Scot Yes, I do have that. I'm stupmed as to why the network interface didn't start though. I think that's the reason all my stuff in /usr/local/etc/rc.d didn't start as well, becuase they couldn't bind to a port. Also, it didn't read rc.firewall :( Heck, I even had to manually assign 127.0.0.1 to lo0. Strange. still stumped.. but I will work on it later tonight. I have another box that I did a clean install of 5.1 on so I can compare startup scripts. Should 5.1 read my /etc/rc.firewall ? --Charlie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TESTERS WANTED for ATAng preview 1
The first preview release of ATAng is now available on: ftp://ftp.deepcore.dk/pub/ATAng >From the README there: ATAng preview 1 release Before these rather radical changes to the ATA driver hits the tree, here is the opportunity to test them out, give usefull feedback and for the depending subsytems to adjust to the new ways of things (burncd & atapicam are good examples). Now why all these changes suddenly ? 1. Get GIANT out of the ATA driver. This was pretty tedious in the old version (I tried that long ago and found it way too painfull). With this new structure it was a walk in the park since handling of ATA commands/requests are now split up in a "queue" part and a "lowlevel" part. This makes the places where locks are needed a lot more obvious to locate, making it easier to implement and maintain. 2. Provide the framework for supporting new ATA controllers that has facilities for chaining commands and HW XOR's etc. This called for some radical changes to the basic framework which fitted nicely with item 1 above. Most of the hooks needed for "exotic" HW are now present, and the next step will be for drivers to use this to get an edge over conventional ATA controllers. Promise Inc. has kindly provided HW and documentation for their latests chips that has lots of interesting features that we can now start to use. Much more on this when these basic bits has settled.. 3. Merge of ATA and ATAPI code. As an effect of the new framework there is now a single entrypoint for ATA/ATAPI commands. This will extend to userland where it will be possible to issue both ATA and ATAPI commands just as before with just ATAPI ones. This will add the ability to do all kinds of stuff from userland, like SMART etc, however it will also provide a nice way of trashing your system :) The code for this is not included in this preview as I still need to settle on the API for this. 4. During all this lots of bugs and problems in the old code has been found and fixed. 5. The way ATA RAID support works today need to change as well to make full use of fx Promise's new chips. This is NOT done yet, in fact the ata-raid.? driver is still the same, bugs and all. To try this out you need to apply the "conf-patch" file to your sys tree then delete the contents of dev/ata and put the contents of the ATAng-.tgz in there instead. You might want to include "device ataraid" in your kernel config file if you use ATA RAID's. Config & make your kernel as usual. Now, some things are not completly done yet, some things will not be done at all and there are bound to be bugs lurking, so use protective measures for safe engagement, you have been warned 8) Constructive feedback as always very welcome!! Enjoy! -Søren -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PCM freezes the box
Dear Sirs, I have problems with my 5.1-Release and 5.1-STABLE boxes: they freeze if I play anything different from audio CDs. The cards are ESS 1938, options pcm is in the kernel. If I try to run xmms/mpg123/KDE or any other application related with artsd/esound/audiofile, the machines freeze, leaving not a single chance to escape to shell and kill the process. I have been beating my head for more than two weeks without success. Please give any hints if possible. TIA, DVV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Warning with loader Makefile?
On Fri, Aug 08, 2003 at 11:25:49AM +1200, Andrew Turner wrote:
[...]
> I found this patch worked by removing the secound ${PROG} target if
> there was already one there.
>
> --- /usr/src/share/mk/bsd.prog.mk Mon Jun 30 06:16:26 2003
> +++ /usr/share/mk/bsd.prog.mk Mon Aug 4 17:54:22 2003
> @@ -31,11 +31,13 @@
>
> OBJS+= ${SRCS:N*.h:R:S/$/.o/g}
>
> +.if !target(${PROG})
> ${PROG}: ${OBJS}
> .if defined(PROG_CXX)
> ${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
> .else
> ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
> +.endif
> .endif
>
> .else !defined(SRCS)
No, thanks. If a makefile has a
${PROG}: foo
line, just to add an additional dependency, this patch will break
building the ${PROG}.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: warnpassword and warnexpire in 5.1 login.conf
On Tue, Aug 05, 2003, Mats Larsson wrote: > Sure, run cap_mkdb on every edit on login.conf > > The values im trying to use there are the following: > :warnexpire=28d:\ > :warnpassword=14d:\ > > And with pw i use the following to test with: (also with -e option) > pw usermod user -p +10d > > The only thing im getting now is i warning in messages when i try to login > into a locked account. > > Aug 5 12:14:39 marvin sshd[55256]: error: PAM: user accound has expired This looks reasonable. > And the following varning when password is old: > Aug 5 12:27:38 marvin sshd[55386]: error: PAM: OK > Aug 5 12:27:40 marvin sshd[55390]: fatal: PAM: chauthtok not supprted with > privsep > > Is there perhaps a better PAM way of doing this things now?? Hmm... Apparently you can't change an expired password with a privilege-separated OpenSSH. I don't know whether that can be fixed, but perhaps des@ has some insight. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 2003-08-08 at 15:41, Nate Lawson wrote:
> On Fri, 8 Aug 2003, Andrew Thompson wrote:
> > On Fri, 2003-08-08 at 03:13, Nate Lawson wrote:
> > > On Fri, 8 Aug 2003, Andrew Thompson wrote:
> > > > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
> > >
> > > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in
> > > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's
> > > also possible that the problem is "NO_SYNC_CACHE" in
> > > sys/cam/scsi/scsi_da.c.
> >
> > I have tried RS_NO_CLEAR_UA, NO_GETMAXLUN, NO_START_STOP,
> > NO_TEST_UNIT_READY, DA_Q_NO_SYNC_CACHE and DA_Q_NO_6_BYTE without any
> > luck.
> >
> > Any other quirks to try?
>
> Let's see the new dmesg. As per my previous reply, I'm not confident your
> quirk was having any effect.
>
> -Nate
I had out a printf after the match function, and it was having an effect
for the quirks above.
I have applied Kevins DA_Q_NO_PREVENT patch and now the device is
working perfectly, here is the diff and new dmesg.
Thanks Nate and Kevin for your help. Should I send a PR?
dmesg:
umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
umass0: Get Max Lun not supported (IOERROR)
Enabling quirks for device
da0 at umass-sim0 bus 0 target 0 lun 0
da0: Removable Direct Access SCSI-4 device
da0: 1.000MB/s transfers
da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C)
scsi_da.c.diff:
-- sys/cam/scsi/scsi_da.c.orig Sat Aug 9 12:18:35 2003
+++ sys/cam/scsi/scsi_da.c Sat Aug 9 18:59:58 2003
@@ -94,7 +94,8 @@
typedef enum {
DA_Q_NONE = 0x00,
DA_Q_NO_SYNC_CACHE = 0x01,
- DA_Q_NO_6_BYTE = 0x02
+ DA_Q_NO_6_BYTE = 0x02,
+ DA_Q_NO_PREVENT = 0x04
} da_quirks;
typedef enum {
@@ -228,6 +229,10 @@
{T_DIRECT, SIP_MEDIA_FIXED, quantum, "VIKING 2*", "*"},
/*quirks*/ DA_Q_NO_6_BYTE
},
+ {
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "SigmaTel*", "MSCN*",
"*"},
+ /*quirks*/
DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE|DA_Q_NO_PREVENT
+ },
#ifdef DA_OLD_QUIRKS
/* Below a list of quirks for USB devices supported by umass. */
@@ -484,7 +489,8 @@
}
if (error == 0) {
- if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0)
+ if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0
+ && (softc->quirks & DA_Q_NO_PREVENT) == 0)
daprevent(periph, PR_PREVENT);
} else {
softc->flags &= ~DA_FLAG_OPEN;
@@ -562,6 +568,7 @@
}
if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0) {
+ if ((softc->quirks & DA_Q_NO_PREVENT) == 0)
daprevent(periph, PR_ALLOW);
/*
* If we've got removeable media, mark the blocksize as
@@ -978,9 +985,10 @@
sizeof(da_quirk_table)/sizeof(*da_quirk_table),
sizeof(*da_quirk_table),
scsi_inquiry_match);
- if (match != NULL)
+ if (match != NULL) {
softc->quirks = ((struct da_quirk_entry
*)match)->quirks;
- else
+ printf("Enabling quirks for device\n");
+ } else
softc->quirks = DA_Q_NONE;
/* Check if the SIM does not want 6 byte commands */
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird reboots from bootmgr or loader
[EMAIL PROTECTED] wrote this message on Wed, Aug 06, 2003 at 19:43 +0900: > I also got the same BTX error during boot up. :( > I used 4.8-RELEASE CD to boot till loader starts up, > changed currdev/loaddev/kernel etc to the -CURRENT setting > and let system boot. > > From: "Florian Smeets" <[EMAIL PROTECTED]> > Date: Wed, 6 Aug 2003 09:43:18 +0200 (CEST) > :: > ::> On Tue, 5 Aug 2003, John-Mark Gurney wrote: > ::> > ::>> Are you running -current w/ a kernel from the last 24 hrs? (After > ::>> phk's mass swap check in?) If so, make sure your swap isn't at the > ::>> start of your disk. If it is, phk was nice enough to only blow away > ::>> your boot blocks instead of your disk label too. :) Swap currently > ::>> uses all but the first page (4k on i386). > ::> > ::> Argl, YES, swap _is_ the first partition: > :: > ::Yes same here! > > Same here, as well. :( > > ::> > ::> Does that mean I have to rearranged or never build world again? > :: > ::Yeah good question, what can we do ? > > May be, we have to run 'bsdlabel -B' just before shutting down > system, everytime, until it gets fixed. :( Simply move the swap start to 16, and reduce the swap length by 16.. Do this in single user, or comment out swap temporarily and reboot, you can't have swap mounted for this change. This will cause swap to skip the disklabel, and you should be happy again. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with nvidia graphics card and -current
there may have been a problem over the last few days. check with a version of sys_machdep.c from a few weeks ago and the newest one.. (It may have been fixed yesterday) On Mon, 4 Aug 2003, Glenn Johnson wrote: > On Sun, Aug 03, 2003 at 11:48:56PM -0500, wrote: > > > I was setting up a system today with an nvidia Geforce4-MX 440 > > graphics card. I am not at the system at the moment but the -current > > sources were from about 2:00 PM CDT. I installed the nvidia-driver > > port (1.0.4365) trying various combinations of WITH_FREEBSD_AGP, > > FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I get the same result. The > > first time an X server is started, everything works fine, including > > glx loading. After exiting the X session and shutting down the > > server and then at some point later starting the X server again, the > > system will freeze. No messages, no panic, nothing. The only thing > > to do is hit the reset button. > > I played with this a bit more tonight. I rebuilt the kernel (fresh > cvsup) and the nvidia-driver bits. I even tried loading without glx. > I still have the same problem. At this point I do not know if this is > a problem with the nvidia-driver port, a problem with -current, or > something I am doing wrong. Does anybody have a functioning nvidia card > with FreeBSD -current at this time? > > -- > Glenn Johnson > [EMAIL PROTECTED] > ___ > [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]"
Specifying default alternate sound device?
Is there any easy way to specify a default alternate sound device (eg, /dev/dsp1). I have both onboard sound (/dev/dsp) and a SB Live card (/dev/dsp1), but I don't use the onboard sound. It's really frustrating to try to configure every single application (that uses sound) to use /dev/dsp1 instead. Is there some safe/easy trick to set a general rule that all/most apps will follow, so that they use /dev/dsp1 instead? I'm using 5.1-RELEASE. Thanks, -- Adam <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird reboots from bootmgr or loader
Lukas Ertl wrote: I saw _exactly_ the same problem on one of my boxes today: it was shutdowned correctly yesterday, and today it wouldn't boot, but panic right after boot0. The only thing I could see were some hex numbers and "BTX halted" for a split second, then immediately reboot. It's a -current box from Sunday evening CEST. I managed to fix it by booting from floppies and running the Fixit floppy, writing a new disklabel, which seems to have become corrupted somehow. Yes this really did the trick! :-) thanks Lukas! regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: openpam_load_module():no pam_wheel.so found
On Sun, Aug 10, 2003 at 10:08:15AM -0400, Robert Watson wrote: > > On Sun, 10 Aug 2003, Christoph Kukulies wrote: > > > When I do an su command from a normal user on my 5.1-current of > > yesterday I'm getting a segfault/core dump. > > > > /var/log/messages then shows: > > Aug 10 15:27:44 kukuboo2k su: in openpam_load_module(): no pam_wheel.so found > > Aug 10 15:27:44 kukuboo2k kernel: pid 54586 (su), uid 0: exited on signal 10 (core > > dumped) > > > > I also get this when I try to do a sh /etc/periodic/weekly/310.locate. > > > > I almost there again with 5.1-current and X on my notebook after a disk > > crash and data loss. Compiled the XFree86-4.3.1 tree and NVIDIA drivers > > today after a complete cvsup and kernel build yesterday. > > Did you mergemaster when updating last? pam_wheel has, I believe, been > replaced with pam_group. A coredump is an undesirable result, of course, > but I suspecft that this is the trigger. If you want to follow up on the > core dump, build a copy of su with debugging symbols, and enable > kern.sugid_coredump to get a coredump and stack tracfe from su (turn it > off again when done). How can I find out which module is using pam_wheel.so? It is annoying not to have a functioning 'su'. Since locate updatedb uses su also I'm additionally impeded since I cannot locate libs and stuff efficiently. -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with nvidia graphics card and -current
On Tue, Aug 05, 2003 at 01:28:58PM +1000, Alastair G. Hogge wrote: > On Tuesday, 05 August 2003 13:07, Glenn Johnson wrote: > > > On Sun, Aug 03, 2003 at 11:48:56PM -0500, wrote: > > > > > I was setting up a system today with an nvidia Geforce4-MX 440 > > > graphics card. I am not at the system at the moment but the > > > -current sources were from about 2:00 PM CDT. I installed the > > > nvidia-driver port (1.0.4365) trying various combinations of > > > WITH_FREEBSD_AGP, FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I > > > get the same result. The first time an X server is started, > > > everything works fine, including glx loading. After exiting the X > > > session and shutting down the server and then at some point later > > > starting the X server again, the system will freeze. No messages, > > > no panic, nothing. The only thing to do is hit the reset button. > > > > I played with this a bit more tonight. I rebuilt the kernel (fresh > > cvsup) and the nvidia-driver bits. I even tried loading without > > glx. I still have the same problem. At this point I do not know > > if this is a problem with the nvidia-driver port, a problem with > > -current, or something I am doing wrong. Does anybody have a > > functioning nvidia card with FreeBSD -current at this time? > > Yes I do. > > I posted to the list a few days with a glx problem. However the > problem was solved when I did an update one day ago. I didn't have to > changed anything either. I didn't know what was wrong for some reason > X would about with sig 10 or 11 when the glx module was loaded. Well, after much hair pulling and trying various troubleshooting steps I had one last idea. I had the vesa kernel module loaded and thought "maybe that is causing the hangup." I disabled the loading of the vesa kernel module in /boot/loader.conf and rebooted. Sure enough, everything worked. I now have the nvidia card working and can proceed with the rest of the setup for this machine. Thanks for your reply stating that it works for you. It gave me the incentive to try "one more time". Question for the developers: Is there someway to avoid having the combination of vesa and nvidia cause a total lockup of the machine? I have a feeling I may not be the last person to try the nvidia driver with vesa enabled, either as a module, or compiled in the kernel. Thanks. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-R kernel panic
I updated to 5.1-CURRENT this weekend and my kernel panic'd this morning.
Here is what I have from the trace
panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c0538a46,0,c054e317,e91c4b6c,100) at Debugger+0x55
panic(c054e317,1000,1068,e91c4b98,0) at panic+0x15f
kmem_malloc(c082f0b0,1000,2,e91c4bf0,c0490f22) at kmem_malloc+0x100
page_alloc(c083ad80,1000,e91c4be3,2,c053b88d) at page_alloc+0x27
slab_zalloc(c083ad80,102,c058f30c,60b,c0630c80) at slab_zalloc+0xc2
uma_zone_slab(c083ad80,102,167,c058f30c,c083ae44) at uma_zone_slab+0xe8
uma_zalloc_bucket(c083ad80,102,c054fb50,599,167) at uma_zalloc_bucket+0x185
uma_zalloc_arg(c083ad80,0,102,fe,d70cb400) at uma_zalloc_arg+0x369
malloc(80,c058f960,102,0,e91c4ce0) at malloc+0xd3
crget(bfbffa70,d70cb414,8,cb0017fc,1) at crget+0x25
setgroups(cafff130,e91c4d10,c0554758,3ee,2) at setgroups+0x58
syscall(2f,2f,bfbf002f,0,bfbffa70) at syscall+0x273
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (80, FreeBSD ELF32, setgroups), eip = 0x282d208f, esp =
0xbfbffa4c, ebp = 0xbfbffab8 ---
Let me know if there is other data you need from me.
Thanks again,
Stephane.
- Original Message -
From: "Stephane Raimbault" <[EMAIL PROTECTED]>
To: "Bosko Milekic" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 30, 2003 11:02 AM
Subject: Re: FreeBSD 5.1-R kernel panic
> Hi Bosko,
>
> Thank you for your suggestion. I am a little un-easy about upgrading my
> system from -RELEASE to -CURRENT. Did you mean, simply upgrading the
kernel
> to -CURRENT, or the entire system?
>
> I'll think of a way I can continue this testing with you so that we can
make
> sure this problem is resolved. It might take me a couple days for me to
> safeguard my data and come up with a backup plan for my system should
> upgrading to -current blows up my system :)
>
> If it's just a question of upgrading the kernel, then I can probably
> implement that sooner rather then later, so let me know if it's just the
> kernel, or the entire /usr/src system you would like me to upgrade.
>
> Thanks,
> Stephane.
>
> - Original Message -
> From: "Bosko Milekic" <[EMAIL PROTECTED]>
> Newsgroups: mailing.freebsd.current
> Sent: Wednesday, July 30, 2003 9:35 AM
> Subject: Re: FreeBSD 5.1-R kernel panic
>
>
> >
> > On Wed, Jul 30, 2003 at 09:25:34AM -0600, Stephane Raimbault wrote:
> > > Hi Bosko,
> > >
> > > My kernel panic'd again this morning. I had removed all the USB
devices
> > > from my kernel and had set my /etc/rc.conf to usbd_enable="NO" and the
> > > kernel panic'd again.
> > >
> > > I have attached both my kernel config file and the trace of the panic.
> Let
> > > me know if I can provide any further information to help analyze this
> > > problem.
> > >
> > > Thanks,
> > > Stephane Raimbault.
> >
> >Hmmm. For what it's worth, I've seen both of these panics before.
> >
> >Have you tried to cvsup to the latest -current (with all of those UMA
> >fixes?)
> >
> >Also, try grabbing
> >http://people.freebsd.org/~bmilekic/uma_races.patch and applying
> >that to a fresh -current. I'm not sure that it's related, but at
> >this point it's worth a shot.
> >
> >It's worth noting that a small chunk of the above patch may fail as I
> >just committed a part of it. You should be able to safely ignore
> >that.
> >
> >Let me know how it works out.
> >
> > Regards,
> > --
> > Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
> > TECHNOkRATIS Consulting Services * http://www.technokratis.com/
> > ___
> > [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: SAN disk with freebsd?
> - Windows on the same loop as anything else Liberal use of zoning should help that. Each Windows HBA should be in a seperate zone. This is from personal experience and also assumes you are using a switched fabric. -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smp in 5.1
At 6:16 PM -0400 8/11/03, Eriq Lamar wrote: Is there any advantage in 5.1 over 4.8 for two amd mp's. and if so could someone tell what they are. I am interested in building dual system using mp's but not sure which version would be better. I run 5.x on a dual-Althon 2000 machine. I have no idea if that gives me much of a benefit as far as *smp* is concerned, but it certainly works fine. And there are other aspects to 5.x which are very attractive to me, such as no more MAKEDEV, and the inclusion of filesystem-snapshots. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mdconfig feature request
On Thu, Aug 07, 2003 at 12:32:56AM -0400, James Quick wrote: > > On Wednesday, August 6, 2003, at 05:24 AM, Poul-Henning Kamp wrote: > > >In message <[EMAIL PROTECTED]>, Tobias Roth > >writes: > >>would it be possible to add the currently attached vnode (or the > >>complete path to it) to the output of > >> > >> mdconfig -l -u > >> > >>that would simplify some things for me. > > > >That is actually somewhat tricky because the file might have been > >renamed or have multiple names. > > What about just wrapping stuff up in a shell function. of course i thought of this, and while it's possible it it still not very elegant. the reason is that i cannot write a pid file because / is not (yet) mounted rw. i can work around that with an additional rc.d/ script but i'd rather avoid that. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI battery state and resume not working on Inspiron 5150
> "Kevin" == Kevin Oberman <[EMAIL PROTECTED]> writes: Kevin> Sorry, Joe. By the way, are you suspending with "acpiconf -s3"? Kevin> Have you tried creating a hibernation partition (slice) and Kevin> using -s4? That appears to work better than suspend on most Kevin> platforms that support it at all. -- R. Kevin Oberman, Network Kevin> Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Kevin> Berkeley National Laboratory (Berkeley Lab) E-mail: Kevin> [EMAIL PROTECTED] Phone: +1 510 486-8634 What does a hibernation partition look like? My dell has a 31 meg partition that I havn't touched and my FreeBSD partition. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 04.08.2003 01:04, Mike Makonnen wrote: On Sun, Aug 03, 2003 at 04:11:12PM +0200, Jens Rehsack wrote: the patch works for me very well. I've checked what's been done and had only small recommendations: - Wouldn't it be better to configure the devfs rules by /etc/devfs.conf or is it impossible? - Even it would be a good thing, if I could specify a ruleset for each jail, and fallback to devfs_ruleset_jail if no jail_example_devfs_ruleset is specified? Ok. Here's a retooled patch. It now includes a devfs rule specification format that we can even use in the general case (i.e. - for /dev). The default rules for a jail are included in it. It's in etc/defaults/devfs.rules and should be self-explanatory. I also put back Scott's code in rc.d/jail for handlind rulesets for individual jails. But I kept the default jail ruleset hard-coded. I don't see the poing of creating yet another knob for it. If a user doesn't want the default that's what the individual knobs for the jails are there for :) Let me know how it goes. On 04.08.2003 01:09, Mike Makonnen wrote: > the patch is attached this time. Hi Mike, sorry that testing took a while, but it failed completely first time on my machine I didn't find the time to debug. 1st: you have a typo in etc/rc.d/jail sed "/\[-z/\[ -z/" 2nd: you include the 'devfs_ruleset_hide' several times, and each time the devfs call for it hides all previous unhidden. So you have to remove the 'add include $devfs_ruleset_hide' from the unhiding rulesets. 3rd: I don't know why, but I had your etc/default/devfs.rules content 5 times in my etc/defaults/debfs.rules The parsing subr fails with this content and so the jails didn't came up. So it was my fault (even I cannot explain, 'cause I removed /usr/src/etc before I cvsup'ed and applied the patch). By the way, now it works. Great step for flexible jails!!! Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bootstrapping network (bcm) on Dell D800
On Wed, 6 Aug 2003, Dr. Richard E. Hawkins wrote: > On Wed, Aug 06, 2003 at 08:48:20AM -0400, David Gilbert wrote: > > I finally figureed out that the removable floppy (which works both as an > external usb and internall) is treated as a scsi device, not /dev/fd0. > So I tried moving the drivers from the up to date machine. No dice; > they depend on another changed function. > > So I borrowed a usb zip drive, and found that a bzip2'd source tree is > only 83M. I've moved that, and have a new kernel compiling from a > source tree updated this morning. Am I going to have to do anything > else to get the bge device detected, or will it just kernel installation > and reboot take care of this? If you've compiled the driver into the kernel, all you'll have to do is configure the IP settings for the device. If you intend on using the kernel loadable module, you'll have to kldload it before you configure the network settings. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
MADWIFI Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for the lame post, but here goes. Madwifi works fine on linux laptops, but need support in Freebsd. The post I read I seem to remember saying that it (madwifi) was native in current? I took a new hd in a Dell laptop. Did an ftp install of 5.1 stable. Cvsuped to current for source and ports. Did a buildworld, recompiled the kernel and did a installworld. Everything seemed to work fine. Stuck in a 11a card (works fine with madwifi in linux) and looked for an ath0 interface. Found nothing. Looked in modules and found the ath_hal module. Installed it with kld, but there's got to be another supporting module somewhere for the interface? The answer isn't to grab the ported linux tarball off of sf.net, is it? If it is, I am really missing something here. Any and all help would be great. thankz gm -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.3 wkUEARECAAYFAj8xmwMACgkQcINCEeyS3ly74QCglTaoiyKEq8plRmZjhPVWTNJBT6EA l0cj1+64GU8C0DGHw6mPk+57RS0= =g0gE -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: spin lock sched lock held for > 5 seconds
On 08-Aug-2003 Lars Eggert wrote:
> John Baldwin wrote:
>> On 01-Aug-2003 Lars Eggert wrote:
>>
>>>Hi,
>>>
>>>got the following panic overnight running with all debugging options on
>>>(WITNESS, MUTEX_DEBUG, DIAGNOSTIC, INVARIANTS; WITNESS_SKIPSPIN off):
>>>
>>>panic: spin lock sched lock held by 0xc658e130 for > 5 seconds
>>>cpuid = 0; lapic.id =
>>>Stack backtrace:
>>>backtrace(c031d030,0,c031c4c5,df0dab8c,100) at backtrace+0x17
>>>panic(c031c4c5,c031c62e,c658e130,c036f160,18b) at panic+0x13d
>>>_mtx_lock_spin(c036f160,2,c031a229,18b,c21b2ab0) at _mtx_lock_spin+0x83
>>>_mtx_lock_spin_flags(c036f160,2,c031a229,18b,df0dac0c) at
>>>_mtx_lock_spin_flags+0xb9
>>>statclock(df0dac00,df0dac44,c02d8a9c,0,c2198d00) at statclock+0x39
>>>rtcintr(0) at rtcintr+0x4f
>>>Xfastunpend8(df0dacb8,c02d1f05,8,608,c0372e60) at Xfastunpend8+0x1c
>>>call_fast_unpend(8,608,c0372e60,ffc00034,0) at call_fast_unpend+0xd
>>>i386_unpend(c036f160,c21b0790,df0dacd0,c01b1ae0,df0dacec) at
>>>i386_unpend+0x8d
>>>cpu_unpend(df0dacec,c01a2534,c036f160,1,c031c2e2) at cpu_unpend+0x2d
>>>critical_exit(c036f160,1,c031c2e2,1bc,1) at critical_exit+0x2d
>>>_mtx_unlock_spin_flags(c036f160,0,c031ac9f,7c,c21b2ab0) at
>>>_mtx_unlock_spin_flags+0xbb
>>>idle_proc(0,df0dad48,c031ab89,312,c21b2ab0) at idle_proc+0xb0
>>>fork_exit(c0199972,0,df0dad48) at fork_exit+0xc3
>>>fork_trampoline() at fork_trampoline+0x1a
>>>--- trap 0x1, eip = 0, esp = 0xdf0dad7c, ebp = 0 ---
>>>Debugger("panic")
>>>timeout stopping cpus
>>>Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0
>>>db>
>>>
>>>The machine is still in ddb, let me know if I can provide additional info.
>>
>> Try updating to a more recent current. I recently added some extra
>> debugging here that will attempt to better show who owns the lock and
>> where it was acquired.
>
> Same panic string, but a different call chain:
>
> spin lock sched lock held by 0xc21b2d10 for > 5 seconds
> exclusive spin mutex sched lock r = 0 (0xc036efc0) locked @
> /usr/src/sys/kern/kern_mutex.c:512
> panic: spin lock held too long
> cpuid = 3; lapic.id = 0300
> Stack backtrace:
> backtrace(c031ce60,300,c031c305,df0d0c30,100) at backtrace+0x17
> panic(c031c305,c21b2d10,c21b2d10,c036efc0,bc) at panic+0x13d
> _mtx_lock_spin(c036efc0,2,c031a037,bc,c21b2720) at _mtx_lock_spin+0xb4
> _mtx_lock_spin_flags(c036efc0,2,c031a037,bc,c21b2720) at
> _mtx_lock_spin_flags+0xb9
> hardclock_process(df0d0ca0,df0d0ce4,c02d7062,0,c0390018) at
> hardclock_process+0x3c
> forwarded_hardclock(0) at forwarded_hardclock+0x11
> Xhardclock(df0d0d10,c01998d7,c036f000,2,c031aaad) at Xhardclock+0x52
> cpu_idle(c036f000,2,c031aaad,5f,c21b2720) at cpu_idle+0x8
> idle_proc(0,df0d0d48,c031a997,30e,0) at idle_proc+0x45
> fork_exit(c0199892,0,df0d0d48) at fork_exit+0xc3
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xdf0d0d7c, ebp = 0 ---
> Debugger("panic")
> timeout stopping cpus
> Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0
> db>
>
> Machine is still in ddb, in case you'd like me to poke around some more.
do 'show pcpu' for each CPU. If this is a dual machine, then it might
be rather easy to figure out which CPU you are on ('show pcpu') then do
a 'show pcpu x' of the other CPU, find the it's curthread, and do a
'trace XXX' on it's PID to see where it is at. That might not work but
it's worth a shot I guess. Also, you can try 'option ADAPTIVE_MUTEXES'
and see if that helps.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACLS on UFS2 from FreeBSD 5.1-RELEASE install.
Terry Lambert wrote: "Daniel C. Sobral" wrote: You'll also notice I'm not questioning the _existence_ of ACL. My point is that FreeBSD is Unix (no matter what the lawyers say), and people don't usually think of ACL when they think of Unix. Ergo, enabling ACL by defautl violates POLA. Not if you never *set* an ACL on anything. It's only when there are ACL's set on things that POLA may be violated. Which is fine if there's no one else on the machine... :-) One presumes that an ACL has to be set on purpose... By _someone_, at at any rate. :-) And, in FreeBSD, POLA is king. (Or so we used to believe, no matter what we actually did. :) I'd be astonished if that weren't true. 8-) 8-). -- Terry -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hoffer's Discovery: The grand act of a dying institution is to issue a newly revised, enlarged edition of the policies and procedures manual. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help! 5.1 doesn't do the rc thing?
On Thu, 7 Aug 2003, Mike Bristow wrote: > On Thu, Aug 07, 2003 at 11:49:00AM -0700, Charlie Schluting wrote: > > Yes, of course :) > > That's why I'm perplexed. I let it install the files it wanted to, > > except for obvious things I didn't want overwritten: passwd file, > > sendmail config, etc. > > > > Just to verify: my old rc.conf should be read (and honored) right? > > Yes. But it may contain bogosity; what does ". /etc/rc.conf" do? > What's in /etc/rc.conf? > Thanks for the response: . /etc/rc.conf produces no output. Here it is: (the missing line numbers are comments) You can see that I'm setting the hostname and IP here... but when it booted, it knew nothing of the sort :( /etc/rc.conf: 9 defaultrouter="131.252.214.4" 10 hostname="cheshire.cat.pdx.edu" 11 ifconfig_fxp0="inet 131.252.214.57 netmask 255.255.255.0" 12 inetd_enable="YES" 13 kern_securelevel_enable="YES" 14 kern_securelevel="0" 15 linux_enable="YES" 16 nfs_server_enable="YES" 17 nfs_server_flags="-u -t -n 4" 18 mountd_flags="-r" 21 rpcbind_enable="YES" 22 quota_enable="YES" 23 check_quotas="YES" 24 firewall_enable="YES" 25 firewall_type="OPEN" 26 firewall_quiet="NO" # note: I manually edited rc.firewall, that's why I just left "OPEN" as-is. 27 xntpd_enable="YES" 28 xntpd_program="/usr/sbin/ntpd" 29 xntpd_flags="-p /var/run/ntpd.pid" 30 # 31 named_enable="YES" 32 named_program="/usr/local/sbin/named" 33 named_flags="-c /usr/local/etc/named.conf -u bind" 34 # 35 router_enable="YES" 36 router="/sbin/routed -s" 40 sendmail_enable="YES" 41 sendmail_flags="-bd" 42 sendmail_outbound_enable="NO" 43 sendmail_submit_enable="NO" 44 sendmail_msp_queue_enable="NO" 45 sshd_enable="YES" 46 usbd_enable="NO" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usbd does not use detach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 07 August 2003 11:19 am, you wrote: > On Wed, 2003-08-06 at 16:42, Anish Mistry wrote: > > Do you know if the usbd actually recieves the detach signal? If it does then > > it should be fairly simple to add the detach to the code. > > > > usbd: driver-detach event cookie=3217029340 devname=ucom0 > > > > USB_EVENT_DRIVER_DETACH > > This looks like usbd receices the event, doesn't it? > > Jan > > > Apply the attached patch and send me the debug output again. - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/MzO2xqA5ziudZT0RAtVLAJ9cHlAHhsvhu7SzW2hTprr5aEIZlQCgyhth 5pboSNz/5nND/+OeK4jP7nA= =F22L -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient problem with xl0
Argl, of course the patch was wrong. Ok, this should work
now ...
--- contrib/isc-dhcp/client/dhclient.c.orig Thu Aug 7 16:58:46 2003
+++ contrib/isc-dhcp/client/dhclient.c Sat Aug 9 21:47:14 2003
@@ -3288,19 +3288,24 @@
return (HAVELINK);
}
}
+ /*
+* If dhclient.conf contains media settings, we cannot
+* abort if the interface is not set to active mode.
+*/
+ if (ip -> havemedia && ip -> client -> state != S_BOUND)
+ return (HAVELINK);
+ } else {
+ /*
+* IFM_AVALID is not set. We cannot check
+* the link state. Assume HAVELINK.
+*/
+ return (HAVELINK);
}
-
- /*
-* If dhclient.conf contains media settings, we cannot
-* abort if the interface is not set to active mode.
-*/
- if (ip -> havemedia && ip -> client -> state != S_BOUND)
- return (HAVELINK);
-
/*
* We really have no link.
*/
return (NOLINK);
+
#else /* ifdef __FreeBSD__ */
/*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACLS on UFS2 from FreeBSD 5.1-RELEASE install.
Scott M. Likens wrote: Has anyone noticed the ACLS being disabled? tunefs -p /dev/da1s1c shows that ACLS are disabled on every partition I have, i've gone through them all. any reason why? ACL is not the standard unix permission. Why enable something most people don't even know is there? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "I argue very well. Ask any of my remaining friends. I can win an argument on any topic, against any opponent. People know this, and steer clear of me at parties. Often, as a sign of their great respect, they don't even invite me." -- Dave Barry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem using USB 2.0 device under -CURRENT (long)
As a data point, here's what happens with mine (this is on current cvsupped this morning). Lots of output that probably isn't very useful. I'm pretty baffled as to why the controller suddenly decides that it doesn't want to work. Guess it's time to try to find the EHCI spec... usb_event_thread: woke up usb_discover ehci_root_ctrl_control type=0xa3 request=00 ehci_root_ctrl_control type=0xa3 request=00 ehci_root_ctrl_control type=0xa3 request=00 ehci_root_ctrl_control type=0xa3 request=00 ehci_root_ctrl_control type=0x23 request=01 ehci_root_ctrl_control type=0x23 request=03 ehci_root_ctrl_transfer: reset port 4 ehci after reset, status=0x1005 ehci port 4 reset, status = 0x1005 usbd_reset_port: port 4 reset done, error=NORMAL_COMPLETION ehci_root_ctrl_control type=0xa3 request=00 ehci_root_ctrl_control type=0x23 request=01 ehci_root_ctrl_control type=0xa3 request=00 usbd_new_device bus=0xc2da4800 port=4 depth=1 speed=3 usbd_setup_pipe: dev=0xc301e680 iface=0 ep=0xc301e6a4 pipe=0xc301e684 ehci_open: pipe=0xc301e600, addr=0, endpt=0 (1) ehci_add_qh: QH(0xc2d9af80) at 0x0028ef80: link=0x0028efc2 endp=0x80082000 addr=0x00 inact=0 endpt=0 eps=2 dtc=0 hrecl=0 mpl=0x8 ctl=0 nrl=8 endphub=0x4000 smask=0x00 cmask=0x00 huba=0x00 port=0 mult=1 curqtd=0x0001 Overlay qTD: next=0x0001 altnext=0x0001 status=0x: toggle=0 bytes=0x0 ioc=0 c_page=0x0 cerr=0 pid=0 stat=0x0 buffer[0]=0x buffer[1]=0x buffer[2]=0x buffer[3]=0x buffer[4]=0x ehci_device_control type=0x80, request=0x06, wValue=0x0100, wIndex=0x len=8, addr=0, endpt=0 ehci_alloc_sqtd: allocating chunk usb_allocmem: large alloc 4096 ehci_alloc_sqtd_chain: start len=8 ehci_alloc_sqtd_chain: dataphys=0x002c0e80 dataphyslastpage=0x002c len=8 cur len=8 ehci_device_request: QH(0xc2d9af80) at 0x0028ef80: link=0x0028efc2 endp=0x80082000 addr=0x00 inact=0 endpt=0 eps=2 dtc=0 hrecl=0 mpl=0x8 ctl=0 nrl=8 endphub=0x4000 smask=0x00 cmask=0x00 huba=0x00 port=0 mult=1 curqtd=0x0001 Overlay qTD: next=0x0001 altnext=0x0001 status=0x: toggle=0 bytes=0x0 ioc=0 c_page=0x0 cerr=0 pid=0 stat=0x0 buffer[0]=0x buffer[1]=0x buffer[2]=0x buffer[3]=0x buffer[4]=0x QTD(0xc2fd7fc0) at 0x0b86bfc0: next=0x0b86bf40<> altnext=0x0b86bf40<> status=0x00080e80: toggle=0 bytes=0x8 ioc=0 c_page=0x0 cerr=3 pid=2 stat=0x80 buffer[0]=0x002c0ec0 buffer[1]=0x buffer[2]=0x buffer[3]=0x buffer[4]=0x QTD(0xc2fd7f40) at 0x0b86bf40: next=0x0b86bf80<> altnext=0x0b86bf80<> status=0x00088d80: toggle=0 bytes=0x8 ioc=1 c_page=0x0 cerr=3 pid=1 stat=0x80 buffer[0]=0x002c0e80 buffer[1]=0x buffer[2]=0x buffer[3]=0x buffer[4]=0x QTD(0xc2fd7f80) at 0x0b86bf80: next=0x0001 altnext=0x0001 status=0x8c80: toggle=0 bytes=0x0 ioc=1 c_page=0x0 cerr=3 pid=0 stat=0x80 buffer[0]=0x buffer[1]=0x buffer[2]=0x buffer[3]=0x buffer[4]=0x usb3: unrecoverable error, controller halted usb3: blocking intrs 0x10 ehci_pcd_able: on=1 ehci_timeout: exfer=0xc2d49600 usbd_dump_pipe: pipe=0xc301e600 usbd_dump_iface: iface=0 usbd_dump_device: dev=0xc301e680 bus=0xc2da4800 default_pipe=0xc301e600 address=0 config=0 depth=1 speed=3 self_powered=0 power=0 langid=-1 usbd_dump_endpoint: endp=0xc301e6a4 edesc=0xc301e6ac refcnt=1 bEndpointAddress=0x00 (usbd_dump_pipe:) refcnt=1 running=1 aborting=0 intrxfer=0, repeat=0, interval=-1 usb_add_task: task=0xc2d4966c usb_task_thread: woke up task=0xc2d4966c ehci_timeout_task: xfer=0xc2d49600 ehci_abort_xfer: xfer=0xc2d49600 pipe=0xc301e600 ehci_sync_hc: enter ehci_sync_hc: cmd=0x00080060 sts=0xb000 ehci_sync_hc: cmd=0x00080060 sts=0xb000 ehci_sync_hc: exit ehci_check_intr: ex=0xc2d49600 ehci_abort_xfer: no hit ehci_ctrl_done: length=0 ehci_device_control type=0x80, request=0x06, wValue=0x0100, wIndex=0x len=8, addr=0, endpt=0 ehci_alloc_sqtd_chain: start len=8 ehci_alloc_sqtd_chain: dataphys=0x002c0e80 dataphyslastpage=0x002c len=8 cur len=8 ehci_device_request: QH(0xc2d9af80) at 0x0028ef80: link=0x0028efc2 endp=0x80082000 addr=0x00 inact=0 endpt=0 eps=2 dtc=0 hrecl=0 mpl=0x8 ctl=0 nrl=8 endphub=0x4000 smask=0x00 cmask=0x00 huba=0x00 port=0 mult=1 curqtd=0x<> Overlay qTD: next=0x0b86bfc0<> altnext=0x0001 status=0x0040: toggle=0 bytes=0x0 ioc=0 c_page=0x0 cerr=0 pid=0 stat=0x40 buffer[0]=0x buffer[1]=0x buffer[2]=0x buffer[3]=0x buffer[4]=0x QTD(0xc2fd7f80) at 0x0b86bf80: next=0x0b86bfc0<> altnext=0x0b86bfc0<> status=0x00080e80: toggle=0 bytes=0x8 ioc=0 c_page=0x0 cerr=3 pid=2 stat=0x80 buffer[0]=0x002c0ec0 buffer[1]=0x buffer[2]=0x buffer[3]=0x buffer[4]=0x000
Re: new panic during buildworld -j4
Duplicate free from the (32) zone. I'll retype the rest in a few hours when I have time. On Thu, 7 Aug 2003, Bosko Milekic wrote: > On Wed, Aug 06, 2003 at 11:13:41PM -0500, Mike Silbersack wrote: > > > > I suppose a coredump would be nice here, but I didn't have that enabled... > > > > And it turns out that I'm too lazy to actually type in all of the > > arguments, but I'll leave the machine sitting at the backtrace. If anyone > > wants any more info, please ask. > > > > panic > > uma_dbg_free > > uma_zfree_arg > > free > > workitem_free > > free_diradd > > handle_written_filepage > > softdep_disk_write_complete > > bufdone > > bufdonebio > > biodone > > g_dev_done > > biodone > > g_io_schedule > > g_up_procbody > > fork_exit > > fork_trampoline > > --- trap 0x1, eip = 0, esp = 0xd23a5d7c, ebp = 0 --- > > How about the panic message? There are 4 different panics that could > have occured from uma_dbg_free(). Arguments would also be nice, I > guess. > > -- > Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] > TECHNOkRATIS Consulting Services * http://www.technokratis.com/ > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: -current want't boot this morning
> On Thu, 7 Aug 2003, Gordon Bergling wrote: > >> I tried to boot my -current this morning but the boot process only >> goes to bootmgr. She shows normal >> >> F1 FreeBSD >> F2 Other (not sure if this is (Other||Unknown) >> >> After pressing F1-Key the computer resets himself. I tried to wait but >> on autoboot the same thing happens. > > Let me guess: your swap partition is the first partition? > >> The -current was build yesterday with recent sources. > > You need to boot a fixit floppy and re-write your bootblocks. Then > cvsup to the very latest -current. This problem should be fixed > already. > shouldn't we mention this in UPDATING, since this is geting an FAQ ? regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 fonts ugly
Hello, There is a howto: XFree86 Font De-uglification HOWTO http://feenix.burgiss.net/ldp/fdu/ Also consider setting minimum font size in Mozilla font preferences. (And this question should have been sent to the ports list, not here on current.) On Sun, Aug 10, 2003 at 04:09:41PM +0200, Christoph Kukulies wrote: > I compiled XFree86/4.3.1 and installed mozilla 1.4 as package > and when I start mozilla fonts show up unevenly weighted (rounding > problems?) > > I wonder if this is a problem with the installed fonts themselves, > or with X11? > > XF86Config looks like this (regarding fontpath): > > Section "Files" > > RgbPath "/usr/X11R6/lib/X11/rgb" > #FontPath "unix/:-1" > FontPath"/usr/X11R6/lib/X11/fonts/local/" > FontPath"/usr/X11R6/lib/X11/fonts/misc/" > FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" > FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" > FontPath"/usr/X11R6/lib/X11/fonts/Type1/" > FontPath"/usr/X11R6/lib/X11/fonts/CID/" > FontPath"/usr/X11R6/lib/X11/fonts/Speedo/" > FontPath"/usr/X11R6/lib/X11/fonts/75dpi/" > FontPath"/usr/X11R6/lib/X11/fonts/100dpi/" > EndSection > > I read somewhere of antialiasing can be switched on or of > but I forgot whether it was with X11, mozilla or NVIDIA driver > compilation. > > > -- > Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Anders. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAN disk with freebsd?
On Sun, Aug 10, 2003 at 06:53:09AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes: > >Anyone using a storage area network with freebsd (or linux)? Anything to > >recommend as working well or to stay way from? > > I have a customer doing that. Is this your customer running the DEC^WCompaq^WHP HSG80 raid array? > Works ok. > > You need qlogic 2300 cards and the isp driver which Matt Jacob maintains. Qlogic 2200 should also work (but is 1Gbit only) Wilko -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: makemap problem in virtusertable.
Mark Sergeant wrote: > I'm running current as of two weeks ago I get the following problem when > doing a make in /etc/mail ... > > makemap: virtusertable.db: line 206: key [EMAIL PROTECTED]: put error: > Operation not permitted > *** Error code 74 > > This line contains ... > > [EMAIL PROTECTED] [EMAIL PROTECTED] > > As far as I am concerned this line should be valid, does anyone have any > idea why this would be an issue ? #define EPROGUNAVAIL74 /* RPC prog. not avail */ ??? Maybe you are doing this over NFS? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PATCH: Disable 6 byte commands for USB, firewire, ATAPICAM
On Wed, 30 Jul 2003, John Baldwin wrote: > On 25-Jul-2003 Nate Lawson wrote: > > Please test devices such as USB keys, USB cameras, Firewire hard disks, > > and ATAPICAM cd drives to be sure they still work with this patch. > > Especially if you've needed a quirk before, it is important to see if this > > patch does not break your device. I hope to get this into the tree early > > so there is plenty of testing before 5.2. > > You should remove the 6 to 10 translation that is already in umass(4) > for UFI and ATAPI devices. I didn't do it for SCSI devices because > the SCSI transport was supposed to work ok with 6 byte commands. Not > all devices properly report their transport though. Done. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Specifying default alternate sound device?
On Tue, 2003-08-05 at 13:25, Adam wrote: > Thanks! Is there a similar trick for specifying mixer1 instead of the > default mixer? Nevermind, this command takes care of everything. Nice trick! Glad I registered to current@ just to ask this question. Saved me a lot of hassle. ;p -- Adam <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with nvidia graphics card and -current
On Sun, Aug 03, 2003 at 11:48:56PM -0500, wrote: > I was setting up a system today with an nvidia Geforce4-MX 440 > graphics card. I am not at the system at the moment but the -current > sources were from about 2:00 PM CDT. I installed the nvidia-driver > port (1.0.4365) trying various combinations of WITH_FREEBSD_AGP, > FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I get the same result. The > first time an X server is started, everything works fine, including > glx loading. After exiting the X session and shutting down the > server and then at some point later starting the X server again, the > system will freeze. No messages, no panic, nothing. The only thing > to do is hit the reset button. I played with this a bit more tonight. I rebuilt the kernel (fresh cvsup) and the nvidia-driver bits. I even tried loading without glx. I still have the same problem. At this point I do not know if this is a problem with the nvidia-driver port, a problem with -current, or something I am doing wrong. Does anybody have a functioning nvidia card with FreeBSD -current at this time? -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any patch for ICMP in a jail?
"Jacques A. Vidrine" wrote: > On Mon, Aug 04, 2003 at 10:53:03AM -0700, Terry Lambert wrote: > > You would either lose or overexpose root-restricted functionality, > > such as flood-ping. > > Eh? Why? pingd can know your credentials. Through the credential passing? I thought that wasn't reliable for this type of thing. Specifically, the jail would be in an untrusted protection domain; if you just accepted the credential blindly, then anyone could be root in the jail, and you could not trust it. If you didn't accept it blindly, then regular root loses existing functionality. I'm pretty sure that, at least the last time I looke at it, the credential passing code didn't pass information about jail status. Yeah, it's doable, but it's not as small amount of work as this discussion so far has implied. Mostly, certain capabilities are going to end up lost. BTW: the main reason for a pingd when dealing with jails isn't about increased security, it's about routing the responses to the appropriate sender. The way Novell dealt with this in IPX was to define an internal network interface that was routed from other internal network interfaces: in effect, they added an internal router hop. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 2003-08-08 at 03:13, Nate Lawson wrote: > On Fri, 8 Aug 2003, Andrew Thompson wrote: > > Hi Nate, > > > > I have just purchased a usb pendrive/mp3 player and I am having a bit of > > trouble. > > > > I built a fresh kernel today as I saw you have been working with the da > > quirks. When I insert the drive I get: > > > > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3 > > umass0: Get Max Lun not supported (IOERROR) > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-4 device > > da0: 1.000MB/s transfers > > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) > > umass0: BBB reset failed, IOERROR > > umass0: BBB bulk-in clear stall failed, IOERROR > > umass0: BBB bulk-out clear stall failed, IOERROR > > umass0: BBB reset failed, IOERROR > > umass0: BBB bulk-in clear stall failed, IOERROR > > umass0: BBB bulk-out clear stall failed, IOERROR > > and so on > > Looks pretty standard. Here is more info on the possible quirks: > http://www.root.org/~nate/freebsd/quirks.html > > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's > also possible that the problem is "NO_SYNC_CACHE" in > sys/cam/scsi/scsi_da.c. I have tried RS_NO_CLEAR_UA, NO_GETMAXLUN, NO_START_STOP, NO_TEST_UNIT_READY, DA_Q_NO_SYNC_CACHE and DA_Q_NO_6_BYTE without any luck. Any other quirks to try? Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ntop broken?
On Wed, 6 Aug 2003, Kris Kennaway wrote: > On Wed, Aug 06, 2003 at 08:57:53AM -0700, Charlie Schluting wrote: > > > > Howdy, > > Running 5.0. > > cvsup to 5.1 and retry. The package currently builds on a clean 5.1 system. > > Kris Ok, done, and still: * crypt() in -lc...no -lcrypt...no makes it fail. I cvsuped the ports with tag=. Any ideas? su-2.05b# uname -a FreeBSD cheshire 5.1-RELEASE FreeBSD 5.1-RELEASE #1: Wed Aug 6 19:00:32 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SPOOGESMP-Q-FW i386 :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1, Data Corruption, Intel, Oh my! [patch] - Fatal trap 12
Peter Edwards wrote: > > ... He might also want to look for any function pointer > > that takes 5 arguments; > > Nice tactic, but misleading in this case, methinks. > > I assume your basing this on the 5 arguments shown in the backtrace. > The 5 arguments passed to the "function" at 0x5949 is probably just > defaulted; I doubt it has any significance. > > Long version: > > ddb tries to work out the number of arguments passed to a function at a > particular stack frame first based on symbolic information for the > function itself (obviously not an option here), then based on the > instruction at the return address in that frame. This works at best > sporadically in the face of -O compiled C code. The fact that there's no > function under the "(null)" would strongly suggest that ddb got confused > with the frame pointer here and didn't get any useful information with > which to work out the argument count. I don't know how accurate this assumption is. I don't thing DDB is confused, because the NULL is consistent with the reported fault address. Even if we assume that it's confused, the PC is enough information to locate the function pointer dereference that is occurring. I also have to assume that the function pointer is in scope, since it's able to call through it to fault the kernel. > In the face of failure, ddb just wildly prints out the 5 words under the > stack pointer. I did suggest that the correct thing to do would be to decode what those words were pointing at, and thereby what types the arguments were... > Given that there's no real function at 0x5949, the stack frame won't > have been set up at all, the frame pointer is still pointing to the > caller's frame, which could be foobar anyway. The stack frame is set up, since you don't run at all without a stack, period. The stack may be corrupt, in this case, but that's an incredibly rare failure mode recently, and mostly this still looks like a NULL pointer dereference to me. > What can be useful is to print out the values on the stack symbolically. > (in gdb, p/a ((void **)$sp)[EMAIL PROTECTED] I'm sure ddb can do something > similar, but no idea how...). And hope to find the caller's return > address lying in the output. The best way would be to take a system dump, and then use GDB. It turns out that, for the most part, you can rebuild a kernel with the symbols, even if you didn't have one, and the names you will get back will be "nearby"; hopefully, though, there's a kernel.debug lying around for this thing. In general, we'd be seeing people reporting this all over the place, loudly, if it wasn't a custom kernel in the first place, so I'd probably start there. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bootstrapping network (bcm) on Dell D800
> "Richard" == Richard E Hawkins writes: Richard> I finally figureed out that the removable floppy (which works Richard> both as an external usb and internall) is treated as a scsi Richard> device, not /dev/fd0. So I tried moving the drivers from the Richard> up to date machine. No dice; they depend on another changed Richard> function. Richard> So I borrowed a usb zip drive, and found that a bzip2'd Richard> source tree is only 83M. I've moved that, and have a new Richard> kernel compiling from a source tree updated this morning. Am Richard> I going to have to do anything else to get the bge device Richard> detected, or will it just kernel installation and reboot take Richard> care of this? The bge device is in the kernel by default... so as long as you didn't delete it, you'll be fine. I forgot to mention that the system appears to be PXE compatible... so you could PXE boot a newly compiled kernel (you need pxeboot and kernel.GENERIC with new drivers on the boot server. You can even have a kernel with the mfsroot compiled into it on the boot server). Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: PATCH: Disable 6 byte commands for USB, firewire, ATAPICAM
On Wed, 30 Jul 2003, John Baldwin wrote: > On 25-Jul-2003 Nate Lawson wrote: > > Please test devices such as USB keys, USB cameras, Firewire hard disks, > > and ATAPICAM cd drives to be sure they still work with this patch. > > Especially if you've needed a quirk before, it is important to see if this > > patch does not break your device. I hope to get this into the tree early > > so there is plenty of testing before 5.2. > > You should remove the 6 to 10 translation that is already in umass(4) > for UFI and ATAPI devices. I didn't do it for SCSI devices because > the SCSI transport was supposed to work ok with 6 byte commands. Not > all devices properly report their transport though. I'll be looking into that and streamlining any other translation code. I just removed some extraneous calls to cmd6workaround(). -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
reproducible deadlock...
I am still able to reproduce a deadlock by running a "make -j 21 buildworld"
on a 48MB physmem configuration.
The first LOR is a false positive according to Alan Cox.
Interestingly, gstat(8) over an ssh session continues to run, so Giant
is presumably not involved.
I can reproduce it with both SCHED_ULE and SCHED_4BSD.
I've left the machine hanging in case anybody has any requests for further
DDB probing.
Poul-Henning
syv# sh t82.sh
lock order reversal
1st 0xc135db90 vm object (vm object) @ vm/vm_object.c:434
2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:328
Stack backtrace:
backtrace(c038747a,c082f110,c0392feb,c0392feb,c0392e93) at 0xc01fe7a7 = backtrace+0x17
witness_lock(c082f110,8,c0392e93,148,c1455130) at 0xc02239f2 = witness_lock+0x672
_mtx_lock_flags(c082f110,0,c0392e8a,148,3) at 0xc01f496a = _mtx_lock_flags+0xba
_vm_map_lock(c082f0b0,c0392e8a,148,2b3,c03e61e0) at 0xc02ef006 = _vm_map_lock+0x36
kmem_malloc(c082f0b0,1000,101,c5616ac4,c02fef72) at 0xc02ee1da = kmem_malloc+0x3a
page_alloc(c083a1c0,1000,c5616ab7,101,c03dfc98) at 0xc02ff1e7 = page_alloc+0x27
slab_zalloc(c083a1c0,101,c039477e,682,c1244c54) at 0xc02fef72 = slab_zalloc+0xc2
uma_zone_slab(c083a1c0,101,c0394775,682,0) at 0xc0300138 = uma_zone_slab+0xe8
uma_zalloc_internal(c083a1c0,0,101,706,0) at 0xc030045f = uma_zalloc_internal+0x4f
uma_zfree_arg(c1244c40,c54498a0,0,773,0) at 0xc03007e2 = uma_zfree_arg+0x2c2
swp_pager_meta_free_all(c135db90,c039278c,c03926f5,20f) at 0xc02e9482 =
swp_pager_meta_free_all+0xf2
swap_pager_dealloc(c135db90,1,c039472e,104,0) at 0xc02e769a = swap_pager_dealloc+0x11a
vm_pager_deallocate(c135db90,0,c039391c,261,c0394775) at 0xc02fdbed =
vm_pager_deallocate+0x3d
vm_object_terminate(c135db90,0,c039391c,1b2,c01f4a50) at 0xc02f5953 =
vm_object_terminate+0x1f3
vm_object_deallocate(c135db90,c1205654,c135db90,c1205654,c5616c64) at 0xc02f5701 =
vm_object_deallocate+0x371
vm_map_entry_delete(c16bc100,c1205654,c0393059,897,0) at 0xc02f186b =
vm_map_entry_delete+0x3b
vm_map_delete(c16bc100,0,bfc0,c16bc100,c125c000) at 0xc02f1c70 =
vm_map_delete+0x3e0
vm_map_remove(c16bc100,0,bfc0,11d,c0382132) at 0xc02f1ce8 = vm_map_remove+0x58
exit1(c164e260,0,c0382132,65,c5616d40) at 0xc01e6f36 = exit1+0x686
sys_exit(c164e260,c5616d10,c039884a,3ee,1) at 0xc01e68a1 = sys_exit+0x41
syscall(2f,2f,2f,bfbff8dc,0) at 0xc033e213 = syscall+0x273
Xint0x80_syscall() at 0xc032d6bd = Xint0x80_syscall+0x1d
--- syscall (1), eip = 0x80b2d63, esp = 0xbfbff85c, ebp = 0xbfbff878 ---
Debugger("witness_lock")
Stopped at 0xc032bf34 = Debugger+0x54: xchgl %ebx,0xc0431044 = in_Debugger.0
db> cont
load: 0.00 cmd: sh 26559 [ufs] 0.00u 0.00s 0% 32k
load: 0.00 cmd: sh 26559 [ufs] 0.00u 0.00s 0% 32k
load: 0.00 cmd: sh 26559 [ufs] 0.00u 0.00s 0% 32k
Stopped at 0xc031845c = siointr1+0xdc: jmp 0xc0318590 = siointr1+0x210
db> ps
pid proc addruid ppid pgrp flag stat wmesgwchan cmd
26559 c12f6000 c58090000 26251 498 0004002 [SLP]ufs 0xc149fd48] sh
26558 c13843c8 c57e50000 26546 498 402 [SLP]ufs 0xc140b1e0] sh
26557 c195fd3c c59cc0000 26545 498 402 [SLP]ufs 0xc1773670] sh
26556 c12e1000 c57730000 26251 498 0004002 [SLP]ufs 0xc149fd48] sh
26555 c12e13c8 c57750000 26251 498 0004002 [SLP]ufs 0xc149fd48] sh
26554 c16b9000 c56b40000 26251 498 0004002 [SLP]ufs 0xc149fd48] sh
26553 c13583c8 c59e40000 26251 498 0004002 [SLP]ufs 0xc14b1d48] sh
26552 c12a23c8 c576d0000 26543 498 402 [SLP]thrd_sleep 0xc09820ec] sh
26551 c12e05ac c56fe0000 26251 498 0004002 [SLP]ufs 0xc149fd48] sh
26550 c195d3c8 c59690000 26251 498 0004002 [SLP]ufs 0xc14b8304] sh
26549 c14b51e4 c5880 26251 498 0004002 [SLP]ufs 0xc14b1b00] sh
26548 c12f6b58 c580f0000 26539 498 402 [SLP]thrd_sleep 0xc09820ec] sh
26547 c164dd3c c563b0000 26544 498 402 [SLP]ufs 0xc1773670] sh
26546 c195d790 c596b0000 26251 498 0004002 [SLP]wait 0xc195d790] sh
26545 c14b5000 c587f0000 26251 498 0004002 [SLP]wait 0xc14b5000] sh
26544 c13725ac c590d0000 26251 498 0004002 [SLP]wait 0xc13725ac] sh
26543 c1372b58 c5910 26251 498 0004002 [SLP]wait 0xc1372b58] sh
26542 c19583c8 c59610000 1 498 0004002 [SLP]ufs 0xc1773670] cc
26540 c1491000 c58290000 26535 498 0004002 [SLP]ufs 0xc1773670] cc
26539 c12a2974 c5770 26251 498 0004002 [SLP]wait 0xc12a2974][SWAP] sh
26537 c14915ac c587a0000 26536 498 0004002 [SLP]ufs 0xc1773670] cc
26536 c139b3c8 c5a3f0000 26531 498 0004002 [SLP]wait 0xc139b3c8][SWAP] sh
26535 c12e1b58 c57790000 26251 498 0004002 [SLP]wait 0xc12e1b58][SWAP] sh
26534 c1958974 c59640000 26532 498 0004002 [SLP]ufs 0xc1773670] cc
26533 c195dd3c c596e0000 26530 498 0004002 [SLP]ufs 0xc1773670] cc
26532 c12a2b58 c57710000 26251 498 0004002 [SLP]wait 0xc12a2b58][SWAP] sh
26531 c12eed3c c58080000 26397 498 0004002 [CV]select 0xc04024b4] make
26530 c13705ac c59050000 2625
[current tinderbox] failure on amd64/amd64
TB --- 2003-08-09 17:33:02 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-08-09 17:33:02 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-09 17:34:35 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpiosxf.h:246: error: previous declaration of `AcpiOsMapMemory' /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/osunixxf.c: In function `AcpiOsMapMemory': /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/osunixxf.c:458: warning: cast to pointer from integer of different size /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/osunixxf.c: At top level: /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/osunixxf.c:482: error: conflicting types for `AcpiOsUnmapMemory' /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpiosxf.h:251: error: previous declaration of `AcpiOsUnmapMemory' /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/osunixxf.c:503: error: conflicting types for `AcpiOsAllocate' /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpiosxf.h:236: error: previous declaration of `AcpiOsAllocate' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/acpi/iasl. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/acpi. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-08-09 18:35:01 - /usr/bin/make returned exit code 1 TB --- 2003-08-09 18:35:01 - ERROR: failed to build world TB --- 2003-08-09 18:35:01 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ntop broken?
On Wed, Aug 06, 2003 at 03:39:47PM -0700, Charlie Schluting wrote: > 5BOn Wed, 6 Aug 2003, Kris Kennaway wrote: > > > On Wed, Aug 06, 2003 at 08:57:53AM -0700, Charlie Schluting wrote: > > > > > > Howdy, > > > Running 5.0. > > > > cvsup to 5.1 and retry. The package currently builds on a clean 5.1 system. > > > > Kris > > Interesting. So, I tried, and it deleted all my ports. No, update your FreeBSD system to 5.1. Besides, as you have found out, the ports collection isn't branched. Look at the sample cvsupfiles in /usr/share/examples/cvsup to see how to update your system. Kris pgp0.pgp Description: PGP signature
Re: "got bad cookie" warnings/errors?
David Malone wrote: On Sat, Aug 09, 2003 at 09:15:45PM -0700, Lars Eggert wrote: I can only say that (1) I've been getting these forever, on both -stable and -current, and (2) I personally have never lost any data. However, I have no clue as to why you and I get them, or what they signify. I have a vague feeling they are related to a directory changing while it is being read, and might mean that the NFS client sees an inconsistent version of the directory. It's been a long time since I looked at it though. Sounds reasonable, but I'm not sure if is the case for me: My home directory is NFS mounted from a Solaris box, and gets modified only from a single client (my desktop) at a time. I get these "cookie" messages whenever I log out of X, when a lot of things get read and written to that mount. Since all those reads and writes originate on my FreeBSD desktop, I would expect its NFS client to keep its cache consitent in that case. But maybe not. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: [HEADSDOWN] swap_pager.c calming down...
Hello Poul, Can you please look into problems reported on current@ list, the thread with subject "Weird reboots from bootmgr or loader", as it seems to related with your recent changes for the swap code. Thank you, Haro PS. As always, thank you for your greate work. From: Poul-Henning Kamp <[EMAIL PROTECTED]> Date: Wed, 06 Aug 2003 14:35:08 +0200 :: ::I'm through with my first level of changes to swap_pager.c and the ::results are better than even I had hoped. :: ::The new per-device round-robin allocation performs a tad _better_ ::than the old striping when it comes to distribution of I/O requests ::over multiple devices, given that there now is no upper limit on ::the number of swap devices, this is a clear win-win. :: ::For systems with less than the (previously) hardconfigured NSWAPDEV ::limit, kernel malloc usage is lower, now we only allocate that space ::which we need. :: ::The next level of changes will be to go directly to GEOM for disk ::devices, rather than take the detour over vnodes and specfs. ::This will not happen in the first couple of weeks I suspect. =--- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Kubota Graphics Technology Inc. /|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bootstrapping network (bcm) on Dell D800
> "Andre" == Andre Guibert de Bruet <[EMAIL PROTECTED]> writes: Andre> I'm under the impression that pretty much all of the 8xx-series Andre> Latitudes have DB9 ports (Including C800, C820 and friends). That may entirely be, but many of my local UN*X friends have ended up with laptops from major vendors that don't include serial ports. Several, running NetBSD, get serial from USB devices. I don't know the status of FreeBSD's USB-serial support. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: warnpassword and warnexpire in 5.1 login.conf
David Schultz <[EMAIL PROTECTED]> writes: > On Tue, Aug 05, 2003, Mats Larsson wrote: >> And the following varning when password is old: >> Aug 5 12:27:38 marvin sshd[55386]: error: PAM: OK >> Aug 5 12:27:40 marvin sshd[55390]: fatal: PAM: chauthtok not supprted with >> privsep >> >> Is there perhaps a better PAM way of doing this things now?? > > Hmm... Apparently you can't change an expired password with a > privilege-separated OpenSSH. I don't know whether that can be > fixed, but perhaps des@ has some insight. It can be done, but not without cheating. You have to have the PAM support code do chauthtok as part of the authentication sequence. I've been meaning to do it for a while but haven't gotten around to it yet. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Deadlock [PATCH]
On Sun, 10 Aug 2003, Peter Holm wrote:
> I have tracked down, what I belive to be the cause of several
> deadlock situations I have encountered, like
> http://people.freebsd.org/~pho/stress/cons40.html.
>
> The problem seems to be the 4bsd scheduler, that does not preempt correctly.
>
> I've included a patch that fixes the problem for me.
% --- sched_4bsd.c~ Sun Jun 15 16:57:17 2003
% +++ sched_4bsd.c Sun Aug 10 08:41:06 2003
% @@ -448,7 +448,8 @@
%
% ke->ke_sched->ske_cpticks++;
% kg->kg_estcpu = ESTCPULIM(kg->kg_estcpu + 1);
% - if ((kg->kg_estcpu % INVERSE_ESTCPU_WEIGHT) == 0) {
% + if (((kg->kg_estcpu + 1) % INVERSE_ESTCPU_WEIGHT) == 0) {
% + curthread->td_flags |= TDF_NEEDRESCHED;
% resetpriority(kg);
% if (td->td_priority >= PUSER)
% td->td_priority = kg->kg_user_pri;
I wonder how this makes much difference. Setting of the rescheduling
flag is supposed to be handled by resetpriority(), so the above at
most works around bugs in resetpriority(). There are plenty of bugs
in resetpriority(), but they are minor and mostly overcome by larger
bugs AFAIK.
resetpriority() was first broken in rev.1.48 of kern_synch.c 1999/03/04)
and the bugs have moved around a bit since then. The main point of
kern_synch.c rev.1.48 was to prevent excessive context switches for
non-PRI_TIMESHARE scheduling classes so that POSIX roundrobin and fifo
scheduling classes could be implemented using these clasess. This has
been broken in -current by context switching even more excessively to
switch to interrupt tasks. The main bugs in kern_synch.c were that
it broke the PRI_TIMESHARE case by not passing the new priority to
maybe_resched() (still broken), and it didn't get the logic for the
non-PRI_TIMESHARE case right (now fixed). The excessive context
switching in -current makes these bugs mostly moot -- we normally
reschedule on the next (non-clock) interrupt, so rescheduling is just
delayed a bit. The delay is normally quite small too, at least in the
case that the rescheduling is triggered by sched_clock(). roundrobin()
is supposed to cause rescheduling every quantum (default 1/10 seconds).
sched_clock() calls resetpriority() every 1/16 seconds on i386's and
rescheduling 16 times per second isn't much different from rescheduling
10 time per second. But sched_clock() should never cause rescheduling
since it should only decrease (numerically increase) the priority of
the current thread.
I think your deadlock must be related to roundrobin() never running,
which might be caused by the bugfeature that userret() doesn't consider
rescheduling. roundrobin() is just a timeout routine, and its current
implementation depends on excessive context switching. All timeout
routines are called from a low priority task, and switching to this
task causes roundrobin scheduling of user processes as a side effect.
roundrobin() just ensures that there is a timeout every quantum in
case the system doesn't otherwise generate timeouts frequently enough,
The bugfeature lets processes return to user mode even though their
user priority is much lower (numerically higher) than that of other
user tasks or perhaps even some kernel tasks. They effectively run
with a high kernel priority until they give up control or are kicked
by an interrupt. Normally there are enough interrupts to prevent
problems. But -current has the curious behaviour of forcibly rescheduling
on almost all interrupts _except_ the clock (scheduling) one. Clock
interrupts are fast, so they don't cause context switches. Hardclock
interrupts schedule timeouts every quantum, but your bug apparently
blocks timeouts. Softclock interrupts are not supposed to cause
rescheduling (that is roundrobin()'s job). Your change does forcible
rescheduling for statclock interrupts.
In my version of FreeBSD, clock interrupt handlers are non-fast so they
do forcible context switching as a side effect and I probably wouldn't
notice this problem. My clock interrupt tasks have a much higher
priority than the timeout task so deadlocks are less likely and would
be more obvious.
I'll try running your stress test.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
busdma/scsi trm(4) related panic
Hi, I've been getting what appears to be a busdma / scsi related panic for the past couple of days. This is based solely on what little info I get when it drops to the debugger - I haven't been able to get a core dump. It panics during the boot process immediately after it tries to probe my scsi devices (just a cdrom) attached to my Tekram DC-315U adapter. If I remove trm(4) from my kernel, I can boot without a panic, but if I load the trm module, and then issue `camcontrol rescan all` it will panic. Reverting /usr/src/sys/i386/i386/busdma_machdep.c to version 1.52 lets me boot and use my scsi devices without panics. Version 1.53 will panic too. This is with -current sources as of 5:57am MST (12:47UTC) on Aug. 5. FreeBSD jonnyv.kwsn.lan 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Tue Aug 5 21:09:50 MST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JONNYV i386 Here's what little info I have (apologies for typos, I had to transcribe this by hand): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc35682f stack pointer = 0x10:0xd68fbb94 frame pointer = 0x10:0xd68fbbd8 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 = 12 (swi7: tty:sio clock) kernel: type 12 trap, code = 0 Stopped at _bus_dmamap_load_buffer+0x3ff: movl %ecx,0(%edx,%eax,8) $ nm -n /boot/kernel/kernel | grep c03568 c03568e0 T bus_dmamap_load If there's anything you'd like me to type at the "db>" prompt, just ask and I'll send the output. Thanks, Jon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw feature request
Hello - I apologize in advance if this feature is already implemented. Is there anyway for ipfw to automatically get the IP from the interface? In OpenBSD's PF, putting ()'s around the interface name will cause that rule to be refreshed on an IP change, such as DHCP, making reloading the rules manually unnecessary. Thanks David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
uwi in current
Hello, I have heard that the Prism2 USB Wireless driver uwi is in current however I can't seem to find where it is. Where can I find it? Thanks! __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 8 Aug 2003, Andrew Thompson wrote:
> On Fri, 2003-08-08 at 15:13, Nate Lawson wrote:
> > On Fri, 8 Aug 2003, Andrew Thompson wrote:
> > > da0 at umass-sim0 bus 0 target 0 lun 0
> > > da0: Removable Direct Access SCSI-4 device
> > > da0: 1.000MB/s transfers
> > > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C)
> >
> > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in
> > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's
> > also possible that the problem is "NO_SYNC_CACHE" in
> > sys/cam/scsi/scsi_da.c. I'm adding Kevin Oberman. He's submitted some
> > quirks before. The idea is to try a few similar to the surrounding ones
> > until something works.
>
> Whats the format of the quirk matching string? I put this in (with a
> printf) but it doesnt match the device.
>
> --- scsi_da.c Fri Aug 8 14:36:33 2003
> +++ /usr/src/sys/cam/scsi/scsi_da.c Fri Aug 8 15:38:47 2003
> @@ -364,6 +364,13 @@
> {T_DIRECT, SIP_MEDIA_REMOVABLE, "MITSUMI", "USB FDD",
> "*"},
> /*quirks*/ DA_Q_NO_SYNC_CACHE
> },
> +{
> +/*
> + * SigmaTel Pen Drives
> + */
> +{T_DIRECT, SIP_MEDIA_REMOVABLE, "SigmaTel", "MSCN
> 0001", "*"},
> +/*quirks*/ DA_Q_NO_SYNC_CACHE
> +},
> #endif /* DA_OLD_QUIRKS */
> };
Try "SigmaTel", "MSCN", "*". The 0001 is the version number, not part of
the product name. Also, the "#endif" shows that you are putting your test
quirk under the #ifdef. Instead it should come after the #endif so it
won't matter whether you're using "options DA_OLD_QUIRKS" or not.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird reboots from bootmgr or loader
Lukas Ertl wrote: On Tue, 5 Aug 2003, Florian Smeets wrote: Lukas Ertl wrote: I managed to fix it by booting from floppies and running the Fixit floppy, writing a new disklabel, which seems to have become corrupted somehow. Yes this really did the trick! :-) May I ask if you boot from a vinum volume? No i don't use vinum on any of the boxes. regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GEOM/vinum compatibility (was: vinum lock panic at startup-current)
On Sat, Aug 09, 2003 at 06:38:51AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey" > writes: > > >> and it seems that vinum does not respect the D_NOGIANT flag which > >> GEOM recently started setting. > > > >Probably because it didn't know about it. As I've said before, it > >would be nice to be informed about the changes you're making, > >particularly given your stated intention of doing no work on Vinum. > > I had the choice between supporting sos@ effort to de-Giantize ATA > or wait for the non-maintainer of vinum to possibly react to his email Come on.. a bit of politeness goes a long way.. > so I chose the former as being more beneficial to the project. W/ -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird reboots from bootmgr or loader
Mensaje citado por Florian Smeets <[EMAIL PROTECTED]>: | | > On Tue, 5 Aug 2003, John-Mark Gurney wrote: | > | >> Are you running -current w/ a kernel from the last 24 hrs? (After | >> phk's mass swap check in?) If so, make sure your swap isn't at the | >> start of your disk. If it is, phk was nice enough to only blow away | >> your boot blocks instead of your disk label too. :) Swap currently | >> uses all but the first page (4k on i386). | > | > Argl, YES, swap _is_ the first partition: | | Yes same here! | | > | > Does that mean I have to rearranged or never build world again? | | Yeah good question, what can we do ? I've got the same or a similar problem on my laptop with a new world and kernel from yesterday. I can't even boot into freebsd, only windows:-(. With F3 for FreeBSD it immediately reboots with no visible message. Windows is the first partition in this case. Anyone else seeing this? Maybe I'm just lucky and have another problem ;-) Thanks for any suggestions, ed -- - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw - default to accept + bootp = confusion.
* James Quick <[EMAIL PROTECTED]> [ Date: 2003-08-07 ] [ w.r.t. Re: ipfw - default to accept + bootp = confusion. ] > > On Thursday, August 7, 2003, at 12:22 AM, Juli Mallett wrote: > > > Does someone have any idea what approach to take for the following > > scenario? I'm leaning towards a compile time failure, or an > > informative > > panic at the beginning of bootp... > > > > You have IPFIREWALL, but not the default to accept option, and you have > > BOOTP. The BOOTP stuff will fail in sosend with EACCESS (informatively > > printed as "13"), because of IPFW, and this may be slightly non-obvious > > to people who haven't dealt with early ipfw interference before. > > > > If not compile time failure / panic, I'd say probably we want some way > > to notify a user in general of ipfw stopping pre-init operation, but I > > don't want to add the concept of runlevels, and don't know if there's > > anything there currently to do detection of if we've hit that point > > yet. > > If the default rule controlled by IPFIREWALL_DEFAULT_TO_ACCEPT, > default_rule.cmd[0].opcode, were made accessible via a sysctl. > then bootp could check it and produce an informative message. > Or, if possible try to insert a rule into the kernel restrictive enough > to > be safe. On the one hand it's a firewall, and you don't want to be > making assumptions about trust on behalf of the user. On the other > hand, we just accepted a kernel from someone, and now want > to get some data for a root partition, so if we cannot trust the host > we're > booting from, what's the point? > > Given the above, would it be possible, to embed a small function > taking just a pair of addresses and masks, and use that to add a rule > so that > this process could continue? After using sysctl to verify the > predicament, > you could then try installing one (or a few) rules to trust the machines > that are booting us. Trust the server running bootpd, trust the dchp > and > nfs server, or just trust the network+submask in a single rule. > > the following is just a rough guess from looking at ip_fw.c. > I don't know how far off it is to being valid. > > s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); > if (s < 0) > err(EX_UNAVAILABLE, "socket"); > memset(&rule, 0, sizeof rule); > rule.fw_flg |= IP_FW_F_ACCEPT; > rule.fw_prot = IPPROTO_IP; > rule.fw_src = /* the bootp servers address > rule.fw_smsk = ~0; /* Does all 1s mean just from that host? */ > rule.fw_dst = /* Is our addr known yet? */ > rule.fw_dmsk = ??; > rule.fw_flg |= (IP_FW_F_OUT|IP_FW_F_IN); /* you could do both > directions */ > i = sizeof(rule); > if (getsockopt(s, IPPROTO_IP, IP_FW_ADD, &rule, &i) == -1) > err(EX_UNAVAILABLE, "getsockopt(%s)", "IP_FW_ADD"); > > Is any of this reasonable or I am just being naive? (I'm new here.) It's entirely easy/possible to add such, but I'd rather not have a dumb sysadmin blame me for their firewall supposedly getting punctured. If you have BOOTP on a box, defaulting to DENY is insane. Does that mean I want to just *change* things at runtime? No. I'd rather prevent any foot-shooting of any form. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata; i have lost my way home early - i don't care cause i won't stay there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum lock panic at startup -current
On Thursday, 7 August 2003 at 18:23:10 -0600, Aaron Wohl wrote: > I just cvsuped -current this afternoon to get about 1 weeks updates. > After that the kernel panics booting starting vinum. I removed the one > vinum volume (reformated as UFS2) I had for testing. And it still panics. > I changed the /etc/rc.conf > start_vinum="YES" to NO and can start ok now. > > Anyone else seeing this? Is there a fix for it? This panic actually happens in GEOM. I believe there were some questions about GEOM recently, but I haven't had any reply yet from phk to my last question on the issue. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: openpam_load_module():no pam_wheel.so found
On Mon, 11 Aug 2003, Christoph P. Kukulies wrote: > > Did you mergemaster when updating last? pam_wheel has, I believe, been > > replaced with pam_group. A coredump is an undesirable result, of course, > > but I suspecft that this is the trigger. If you want to follow up on the > > core dump, build a copy of su with debugging symbols, and enable > > kern.sugid_coredump to get a coredump and stack tracfe from su (turn it > > off again when done). > > How can I find out which module is using pam_wheel.so? It is annoying > not to have a functioning 'su'. Since locate updatedb uses su also I'm > additionally impeded since I cannot locate libs and stuff efficiently. grep pam_wheel /etc/pam.d/* | grep -v '^#' should show you the list. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Several panics during unload of netgraph related klds
Hi all, I've just noticed that I cannot unload 81 0xc4226000 4000 if_tap.ko (panics) 93 0xc435 12000netgraph.ko (unloads, but is still there) 101 0xc4222000 4000 ng_ether.ko (reports busy) 111 0xc41a7000 5000 ng_bridge.ko (works) 121 0xc421e000 4000 ng_socket.ko (reports busy) A bogus message is also available: kernel: kldunload: attempt to unload file that was loaded by the kernel If a network module is loaded before these module, the system panics if one tries to unload the kernel module. Unfortunatly I cannot provide panic dumps, something in savecore seems broken since yesterday. Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bootstrapping network (bcm) on Dell D800
On Tue, 5 Aug 2003, Dr. Richard E. Hawkins wrote: > If I'm reading the recent messages correctly, the bcm driver won't work > unless updated to approximately July 17. > > I burned 5.1 iso's, and installed most of it successfully. How do I > bootstrap the network. I saw Bill Paul's references to testing a patch > prior to committing it. Is this something I can apply singly to the > source that comes on the ISO (and if so, just where do I grab it?), and > then build a kernel, reboot, and update the rest of the source? > > thanks > > hawk, anxious to play with his new toy Does this new toy have a 32-bit pci slot available? If so, pop in a nic (temporarily), cvsup and/or grab the needed patches and rebuild away! Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with dhclient & wi0 on resume.
In message: <[EMAIL PROTECTED]> Mark Sergeant <[EMAIL PROTECTED]> writes: : wi0: Lucent Firmware: Station (6.14.1) There are some known issues with lucent cards and the new wi driver. A work around would be to upgrade firmware to the latest available. This problem is poorly understood, so little progress has been made in finding and killing it. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with dhclient & wi0 on resume.
On Tue, 2003-08-12 at 21:10, Martin Blapp wrote: > Hi, > > > Unfortunately this system hasn't worked for me. As it is I have a script > I've put the sleep command in rc.suspend and the wake in rc.resume but they didn't help. I also tried to use these commands manually and again no luck. Killing dhclient and restarting manually works though. > Have you tested it and included theses commands in rc.resume and rc.suspend ? > > > which lives in rc.d which starts up dhclient with the appropriate > > wireless options. Unfortunately after each suspend and resume this is > > what I have to use. > > > > If anyone comes up with a solution to this it'd be much appreciated. > > Which "script" do you use ? The dhclient script in /etc/rc.d ? > The script I use is a "homemade" one, after looking at /etc/rc.d/dhclient it seems that this will do the job nicely enough, thanks for this tip. My main problem now comes back to the wi driver spitting up a whole lot of errors, it's now quite often freezing up entirely with the following ... wi0: timeout in wi_cmd 0x0002; event status 0x8080 wi0: timeout in wi_cmd 0x0121; event status 0x8080 wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: failed to allocate 2372 bytes on NIC wi0: tx buffer allocation failed (error 12) wi0: interface not running wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. The machine then has to be hard reset when this happens. > Martin -- Mark Sergeant <[EMAIL PROTECTED]> SNSOnline Technical Services ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum lock panic at startup -current
On Fri, Aug 08, 2003 at 10:22:06AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes: > >I just cvsuped -current this afternoon to get about 1 weeks updates. > >After that the kernel panics booting starting vinum. I removed the one > >vinum volume (reformated as UFS2) I had for testing. And it still panics. > > I changed the /etc/rc.conf > >start_vinum="YES" to NO and can start ok now. > > What was the actual panic message ? > Would http://people.freebsd.org/~erwin/koala.trace2 be related ? This happens after a couple of hours of activity, things are fine again after reboot (for a while) on 5-1-RELEASE. -- _._ _,-'""`-._ Erwin Lansing (,-.`._,'( |\`-/|[EMAIL PROTECTED] http://droso.org `-.-' \ )-`( , o o)[EMAIL PROTECTED] -bf- `-\`_`"'- pgp0.pgp Description: PGP signature
vinum lock panic at startup -current
I just cvsuped -current this afternoon to get about 1 weeks updates.
After that the kernel panics booting starting vinum. I removed the one
vinum volume (reformated as UFS2) I had for testing. And it still panics.
I changed the /etc/rc.conf
start_vinum="YES" to NO and can start ok now.
Anyone else seeing this? Is there a fix for it?
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc030e4d2 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc030e828 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc030535c in _mtx_assert (m=0xc05f5820, what=0, file=0xc052eb22
"/usr/src/sys/geom/geom_dev.c", line=198)
at /usr/src/sys/kern/kern_mutex.c:855
#4 0xc02d613f in g_dev_open (dev=0xc6, flags=-1068307678, fmt=0, td=0x0)
at /usr/src/sys/geom/geom_dev.c:198
#5 0xc763d3b6 in open_drive (drive=0xc05f5820, td=0xc75f85f0, verbose=0)
at /usr/src/sys/dev/vinum/vinumio.c:69
#6 0xc763d61b in init_drive (drive=0xc6, verbose=-1068307678) at
/usr/src/sys/dev/vinum/vinumio.c:138
#7 0xc763da62 in read_drive_label (drive=0xc6, verbose=0) at
/usr/src/sys/dev/vinum/vinumio.c:291
#8 0xc763dbf4 in check_drive (devicename=0x0) at
/usr/src/sys/dev/vinum/vinumio.c:341
#9 0xc763e8d6 in vinum_scandisk (devicename=0xc75ea2f0 "ad2 ad1 ad0") at
/usr/src/sys/dev/vinum/vinumio.c:787
#10 0xc763f58e in vinum_super_ioctl (dev=0xc7614700, cmd=0,
data=0xc73f8000 "") at /usr/src/sys/dev/vinum/vinumioctl.c:309
#11 0xc763eef6 in vinumioctl (dev=0x0, cmd=3288352331, data=0xc73f8000
"", flag=3, td=0xc75f85f0)
at /usr/src/sys/dev/vinum/vinumioctl.c:80
#12 0xc02d404e in spec_ioctl (ap=0xc73f8000) at
/usr/src/sys/fs/specfs/spec_vnops.c:346
#13 0xc02d3698 in spec_vnoperate (ap=0x0) at
/usr/src/sys/fs/specfs/spec_vnops.c:122
#14 0xc0375fe1 in vn_ioctl (fp=0xc760c198, com=3288352331,
data=0xc73f8000, active_cred=0xc21cc280, td=0xc75f85f0)
at vnode_if.h:503
#15 0xc0335f05 in ioctl (td=0xc75f85f0, uap=0xe4cd5d10) at
/usr/src/sys/sys/file.h:261
#16 0xc04d4f73 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 1, tf_ebp
= -1077938088, tf_isp = -456303244, tf_ebx = -1077938032, tf_edx =
135189408, tf_ecx = 11, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134704511, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077939172, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1008
#17 0xc04c535d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB 2.0 ehci umass problems
Hi, I've a usb 2.0 disc enclosure for 2.5 inch disk. It works great using the standard usb stuff (1.x), but fails to use ehci (2.0). When i plug the usb 2.0 device i get the following output ( hw.usb.ehci.debug=2 hw.usb.ohci.debug=2 ) Aug 12 11:39:04 bifur kernel: ehci_pcd: change=0x02 Aug 12 11:39:05 bifur kernel: ehci after reset, status=0x1005 Aug 12 11:39:05 bifur kernel: ehci port 1 reset, status = 0x1005 Aug 12 11:39:05 bifur kernel: usbd_new_device bus=0xc405d800 port=1 depth=1 speed=3 Aug 12 11:39:05 bifur kernel: ehci_open: pipe=0xc46d7600, addr=0, endpt=0 (1) Aug 12 11:39:05 bifur kernel: ehci_alloc_sqtd_chain: start len=8 Aug 12 11:39:05 bifur kernel: ehci_alloc_sqtd_chain: start len=2 Aug 12 11:39:05 bifur kernel: ehci_alloc_sqtd_chain: start len=8 Aug 12 11:39:10 bifur kernel: ehci_timeout: exfer=0xc3ffd500 Aug 12 11:39:10 bifur kernel: usbd_dump_pipe: pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: usbd_dump_iface: iface=0 Aug 12 11:39:10 bifur kernel: usbd_dump_device: dev=0xc46d7800 Aug 12 11:39:10 bifur kernel: bus=0xc405d800 default_pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: address=0 config=0 depth=1 speed=3 self_powered=0 power=0 langid=-1 Aug 12 11:39:10 bifur kernel: usbd_dump_endpoint: endp=0xc46d7824 Aug 12 11:39:10 bifur kernel: edesc=0xc46d782c refcnt=1 Aug 12 11:39:10 bifur kernel: bEndpointAddress=0x00 Aug 12 11:39:10 bifur kernel: (usbd_dump_pipe:) Aug 12 11:39:10 bifur kernel: refcnt=1 running=1 aborting=0 Aug 12 11:39:10 bifur kernel: intrxfer=0, repeat=0, interval=-1 Aug 12 11:39:10 bifur kernel: ehci_timeout_task: xfer=0xc3ffd500 Aug 12 11:39:10 bifur kernel: ehci_abort_xfer: xfer=0xc3ffd500 pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080061 sts=0xa000 Aug 12 11:39:10 bifur kernel: ehci_intr1: door bell Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080021 sts=0xa000 Aug 12 11:39:10 bifur kernel: ehci_idone: aborted xfer=0xc3ffd500 Aug 12 11:39:10 bifur kernel: ehci_abort_xfer: no hit Aug 12 11:39:10 bifur kernel: ehci_alloc_sqtd_chain: start len=8 Aug 12 11:39:10 bifur kernel: ehci_alloc_sqtd_chain: start len=2 Aug 12 11:39:10 bifur kernel: usbd_new_device: addr=2, getting first desc failed Aug 12 11:39:10 bifur kernel: usbd_remove_device: 0xc46d7800 Aug 12 11:39:10 bifur kernel: ehci_device_ctrl_close: pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080061 sts=0x8000 Aug 12 11:39:10 bifur kernel: ehci_intr1: door bell Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080021 sts=0x8000 Aug 12 11:39:10 bifur kernel: uhub_explore: usb_new_device failed, error=STALLED Aug 12 11:39:10 bifur kernel: uhub2: device problem, disabling port 1 Is there some hints or patches available to get this working? with usb 1.x output no debug... Aug 8 11:14:09 bifur kernel: umass0: Acer Labs USB 2.0 Storage Device, rev 2.00/1.03, addr 3 Aug 8 11:14:10 bifur kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug 8 11:14:10 bifur kernel: da0: Fixed Direct Access SCSI-0 device Aug 8 11:14:10 bifur kernel: da0: 1.000MB/s transfers Aug 8 11:14:10 bifur kernel: da0: 19077MB (39070080 512 byte sectors: 255H 63S/T 2432C) And works ofcourse. Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: buildworld breaks
On Thu, 7 Aug 2003, Lukas Ertl wrote: > buildworld is current broken: > > ===> sys/boot/i386/libi386 > cc -O -pipe -mcpu=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600 > -DTERM_EMU -I/usr/src/sys/boot/i386/libi386/../../common > -I/usr/src/sys/boot/i386/libi386/../btx/lib > -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica > -I/usr/src/sys/boot/i386/libi386/../../.. -I. > -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding > -mpreferred-stack-boundary=2 -c /usr/src/sys/boot/i386/libi386/biosacpi.c > In file included from /usr/src/sys/contrib/dev/acpica/acfreebsd.h:165, > from /usr/src/sys/boot/i386/libi386/biosacpi.c:33: > /usr/obj/usr/src/i386/usr/include/ctype.h:88: error: syntax error before "int" > *** Error code 1 > > Stop in /usr/src/sys/boot/i386/libi386. > *** Error code 1 I think I found the error: Rev. 1.18 of sys/contrib/dev/acpica/acfreebsd.h introduced an '#include ', which has a declaration of isascii(). The problem is that biosacpi.c includes stand.h, which defines isascii() already, and you end up with this (from the preprocessor output): int _tolower(int); int _toupper(int); int (((int) & ~0x7F) == 0); int toascii(int); So either remove the inclusion if ctype.h in acfreebsd.h or remove the inclusion of stand.h in biosacpi.c. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: busdma/scsi trm(4) related panic
On Wed, 2003-08-06 at 06:42, Scott Long wrote: > I know what the problem is and I'm working on a patch right now. > > Scott Excellent. I'll be happy to test it if needed. Jon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAN disk with freebsd?
Hi Aaron, On Sun, 2003-08-10 at 10:10, Aaron Wohl wrote: > Anyone using a storage area network with freebsd (or linux)? Anything to > recommend as working well or to stay way from? I've had FreeBSD 4.6-RELEASE with a QLA2200 card connected to an IBM ESS (Shark) through IBM 2109-S16 switches (Brocade 3800) working very well. You have to tell the Shark to only use 1 interface for that host (we have 3 per Shark) as there is no dual pathing code yet for FreeBSD. Carl. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DEVFS related message
Hi All, I just got following DEVFS related message with this mornings current. DEVFS Overflow table with 32768 entries allocated when 925 in use Anybody seen this? Thanks, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., Kubota Graphics Technologies Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient problem with xl0
Hi, Adapted to the newst source-version, the patch will look like this. After I got home, I'll test it. Martin Index: client/dhclient.c === RCS file: /home/ncvs/src/contrib/isc-dhcp/client/dhclient.c,v retrieving revision 1.30 diff -u -r1.30 dhclient.c --- client/dhclient.c 7 Aug 2003 14:58:46 - 1.30 +++ client/dhclient.c 9 Aug 2003 16:20:22 - @@ -3288,19 +3288,21 @@ return (HAVELINK); } } - } - /* -* If dhclient.conf contains media settings, we cannot -* abort if the interface is not set to active mode. -*/ - if (ip -> havemedia && ip -> client -> state != S_BOUND) - return (HAVELINK); + /* +* If dhclient.conf contains media settings, we cannot +* abort if the interface is not set to active mode. +*/ + if (ip -> havemedia && ip -> client -> state != S_BOUND) + return (HAVELINK); - /* -* We really have no link. -*/ - return (NOLINK); + /* +* We really have no link. +*/ + return (NOLINK); + } + + return (HAVELINK); #else /* ifdef __FreeBSD__ */ /* @@ -3310,6 +3312,7 @@ return (HAVELINK); #endif /* Other OSs */ } + #ifdef __FreeBSD__ void Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: pca driver being retired.
In message <[EMAIL PROTECTED]>, Mark Murray wr ites: >Would it be a useful exercise for the minority(?) of users who use this >driver to either see if it can be effectively newbussed or turned into >a port or both? The main problem is the code which hi-jacks the i8254 and kicks off up to 2 interrupts per second. -- 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]"
Questions about stability of snapshots and vinum in 5.1
My goal is to have a box, with 2 drives, each of which is identically configured. Slice 1, and Slice 2, will be smallish FreeBSD partitions 4-8 GB each. 1 will be treated as a production environment. The other will be used for building and testing new environments. The bulk of the space will be used for data. Each pair of production and test slices will be periodically mirrored to it's twin to provide a measure of fault tolerance. The box currently has one of the two new large drives installed, and 3 smaller aging (and ailing) drives. I was hoping to use vinum for all the rest, as it would give me far more flexibility. Based on recent posts it sounds like I should wait on that, and will leave enough unconfigured space at the top so that I can migrate from manually created partitions to vinum once I feel that geom+vinum have stabilized a bit. I am seeking feedback on the status of vinum, and whether the following plan makes sense as an upgrade plan for a host with a light load but whose downtime windows are short. I am curious if my planned use of snapshots is risky in 5.1, I have used them in under a much older 5.0 version with no problems, but a lot has changed. I have not migrated my data onto the first of these drive since I need to configure one, migrate from 2 old drives, then put in the second new drive before continuing. I also need to do as much of this work as possible without interruption. My plan is, to build out the first set of partitions, then create a queue of jobs for each disk controller: 1. create a snapshot on the destination drive. 2. use dump+restore or tar at a decent nice value, to copy from source to the new dest. 3. Then when I can shutdown production, and all the old data has completed a full (though aged) copy, get rid of the old mirrors. Use rsync to copy the changes to the destination. 4. Create snapshots on the new system volumes, boot into the new environment for testing. 5. If that goes well, swap out one of the old drives for the second new one, build out the OS copies, and copies of critical user data. 6. I can then get rid of, or fool around with the old disks at my leisure. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ntop broken?
On Thu, Aug 07, 2003 at 07:21:49PM -0700, Charlie Schluting wrote: > On Wed, 6 Aug 2003, Kris Kennaway wrote: > > > On Wed, Aug 06, 2003 at 08:57:53AM -0700, Charlie Schluting wrote: > > > > > > Howdy, > > > Running 5.0. > > > > cvsup to 5.1 and retry. The package currently builds on a clean 5.1 system. > > > > Kris > > Ok, done, and still: > * crypt() in -lc...no -lcrypt...no > makes it fail. > > I cvsuped the ports with tag=. > > Any ideas? It's likely you have stale files lying around that are confusing the build. ntop builds successfully on a clean 5.x system. Kris pgp0.pgp Description: PGP signature
