Re: ULE nice bugs are fixed.
On Wed, 18 Jun 2003, Wiktor Niesiobedzki wrote: > On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: > > > > I am still not able to reproduce this. Can you update your sources? I > > commited some code just now that removed an external dependency from > > sched_nice(). This should make it more robust. > > > With the new code, I'm also unable to reproduce the panic :) With LAZY_SWITCH enabled? > > Thanks :) > > Cheers, > > Wiktor Niesiobedzki > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is rogue?
Kris Kennaway writes: > > I installed freebsd-games, and it has most of the games I remember, but n= > ot > > rogue. > > Well, hrumph, it's supposed to be in that port. Mark, it looks like > rogue wasn't added for some reason. Oops. Fix coming later today. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE nice bugs are fixed.
On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: > > I am still not able to reproduce this. Can you update your sources? I > commited some code just now that removed an external dependency from > sched_nice(). This should make it more robust. > With the new code, I'm also unable to reproduce the panic :) Thanks :) Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with pcmcia on 5.1-RELEASE
"M. Warner Losh" <[EMAIL PROTECTED]> writes: > In message: <[EMAIL PROTECTED]> > Christian Laursen <[EMAIL PROTECTED]> writes: > : "M. Warner Losh" <[EMAIL PROTECTED]> writes: > : > : > In message: <[EMAIL PROTECTED]> > : > Christian Laursen <[EMAIL PROTECTED]> writes: > : > : pccard0: (manufacturer=0x, product=0x) at > function 0 > : > : pccard0:CIS info: FREECOM, PCCARD-IDE, REV836 > : > > : > Looks like we need another entry in ata-card.c for this device. > : > > : > I've added this to the kernel list. Please recvsup and make sure you > : > have sys/dev/pccard/pccarddevs 1.53, pccarddevs.h 1.53 and > : > sys/dev/ata/ata-card.c 1.14. > : > : Thank you very much. > : > : Unfortunately, like the patch Matthew N. Dodd posted, this gives me > : an extra ata channel, but no devices are found on it. > : > : I have tried various commands to atacontrol, but nothing seems to > : help. > : > : I'm not sure how to help debug this further. > > I have a stupid question: Are you sure that your cdrom is turned on? > I have some that need an aux power connection before they work. Yes, I am. There is a switch that I can use to change between external power or power from the machine to which it is connected. When I insert the card, the light on the drive comes on, and if a cd is inserted, it spins up. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple cardbus devices? (RFI)
> : xl0: <3Com 3c575B Fast Etherlink XL> port 0x1000-0x107f mem > : 0x8800-0x887f,0x8880-0x88ff irq 11 at device 0.0 on > : cardbus0 > > That's not 4k! :-( Ok, if I'm reading this right: rman_reserve_resource: request: [0x8880, 0x88ff], length 0x80, flags 12288, device xl0 considering [0x5400, 0x] truncated region: [0x88001000, 0x88001080]; size 0x81 (requested 0x80) candidate region: [0x88001080, 0x88001000], size 0x81 splitting region in three parts: [0x5400, 0x88000fff]; [0x88001000, 0x880010 7f]; [0x88001080, 0x] xl0: using memory mapped I/O rman_reserve_resource: request: [0x8800, 0x887f], length 0x80, flags 12288, device xl0 considering [0x5400, 0x88000fff] truncated region: [0x8800, 0x8880]; size 0x81 (requested 0x80) candidate region: [0x8880, 0x8800], size 0x81 splitting region in three parts: [0x5400, 0x87ff]; [0x8800, 0x88 7f]; [0x8880, 0x88000fff] It looks like the patch is indeed working and changing the alignment of stuff, but xl0 is getting handed 88001000-88001080 for the second memory range but lying about it in dmesg (and doesn't appreciate having its memory split up). I tried moving the alignment flags thing to cardbus_alloc_resources() in cardbus_cis.c. That gave me pretty much the same results as my previous hack -- each separate device starts out on a 4k boundary (though the sizes are correct now). It works fine for a while but eventually both devices just stop working. Putting heavy load on the NIC seems to make it happen much sooner. So far I haven't managed to find any clues as to why it behaves that way. Forcing xl0 to use the I/O port range instead of memory mapped I/O seems to make it last longer before it dies, but it still eventually gives up and starts timing out. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
On 17 Jun, Chris Shenton wrote:
> Don Lewis <[EMAIL PROTECTED]> writes:
>
>> If you have another machine and a null modem cable you can redirect the
>> system console of the machine to be debugged to a serial port and run
>> some comm software on the other machine so that you can capture all the
>> output from ddb.
>
> OK, I'll give that a shot, probably tomorrow.
>
>
>> At the ddb prompt, you can do a "tr" command to get a stack trace,
>> which is likely to be very helpful in pointing out the offending
>> code.
>
> Just saw it again, did a tr. From chicken-scratch notes, the last
> bits are:
>
> VOP_GETVOBJECT(...)
> do_sendfile(...)
> sendfile(...)
> syscall(...)
> Xint0x80_syscall...
> --- syscall( 393, FreeBSD ELF32, sendfile) ...
>
> The next time it dropped into ddb, same "sendfile" thing.
Try the very untested patch below ...
> The main services I'm running are qmail, apache, and NFS. Also
> tftp, rarpd, lpd, sshd, bootparamd ... oh, well, I guess I'm running
> a bunch of stuff here. :-( Not sure which one, if any, this would be.
>
> Unless sendfile() is something in the OS?
It's a system call, and I believe apache uses it.
>
> I'll have to dig up a nullmodem and grab console output. I realise
> I'm not giving enough detailed info to be very helpful here.
It's good enough to squash one bug. I don't know if it will solve your
problem, though.
>> If you are running the NFS *client* code on this machine, there is one
>> lock assertion that is easy to trigger.
>
> In my kernel config I have this, because a diskless box uses the same
> kernel, but my /etc/fstab doesn't mount anyone else's NFS exports.
You won't trigger the the lock violation in the NFS client code unless
you actually mount a file system from another machine using NFS and
actually do some I/O on it.
Here's the patch:
Index: uipc_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.150
diff -u -r1.150 uipc_syscalls.c
--- uipc_syscalls.c 12 Jun 2003 05:52:09 - 1.150
+++ uipc_syscalls.c 18 Jun 2003 03:14:42 -
@@ -1775,10 +1775,13 @@
*/
if ((error = fgetvp_read(td, uap->fd, &vp)) != 0)
goto done;
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (vp->v_type != VREG || VOP_GETVOBJECT(vp, &obj) != 0) {
error = EINVAL;
+ VOP_UNLOCK(vp, 0, td);
goto done;
}
+ VOP_UNLOCK(vp, 0, td);
if ((error = fgetsock(td, uap->s, &so, NULL)) != 0)
goto done;
if (so->so_type != SOCK_STREAM) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Giant pushdown in kern_descrip.c rev 1.128
On 17 Jun, Alfred Perlstein wrote: > * Don Lewis <[EMAIL PROTECTED]> [030617 13:06] wrote: >> On 17 Jun, Alfred Perlstein wrote: >> > * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote: >> >> It's not legal to attempt to aquire Giant in fdrop_locked(), while >> >> FILE_LOCK() is held. The problem is that FILE_LOCK uses the mutex pool, >> >> which should only be used for leaf mutexes. >> >> >> >> It also looks like there is a potential for a lock order reversal if >> >> some callers aquire Giant before FILE_LOCK() and fdrop_locked() does the >> >> opposite. >> >> >> >> It also appears that witness ignores the mutex pool ... >> > >> > Yes, but I think the fix is as simple as just dropping the FILE_LOCK >> > after the decrement as we're the last holders of it, can you try >> > this: >> >> I like simple fixes, especially when the code shrinks ;-) >> >> Unfortunately, I think your point about this only happening because this >> process is the last holder of the file means that this doesn't explain >> Peter's deadlock. > > You can still deadlock because another file's mutex may hash to the same > location. ... or some other user of the mutex pool that happens to hold Giant. I'm in favor of committing your patch, though I think it should be commented to indicate why it is safe to play with fp after the mutex has been unlocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
Don Lewis <[EMAIL PROTECTED]> writes: > If you have another machine and a null modem cable you can redirect the > system console of the machine to be debugged to a serial port and run > some comm software on the other machine so that you can capture all the > output from ddb. OK, I'll give that a shot, probably tomorrow. > At the ddb prompt, you can do a "tr" command to get a stack trace, > which is likely to be very helpful in pointing out the offending > code. Just saw it again, did a tr. From chicken-scratch notes, the last bits are: VOP_GETVOBJECT(...) do_sendfile(...) sendfile(...) syscall(...) Xint0x80_syscall... --- syscall( 393, FreeBSD ELF32, sendfile) ... The next time it dropped into ddb, same "sendfile" thing. The main services I'm running are qmail, apache, and NFS. Also tftp, rarpd, lpd, sshd, bootparamd ... oh, well, I guess I'm running a bunch of stuff here. :-( Not sure which one, if any, this would be. Unless sendfile() is something in the OS? I'll have to dig up a nullmodem and grab console output. I realise I'm not giving enough detailed info to be very helpful here. > If you are running the NFS *client* code on this machine, there is one > lock assertion that is easy to trigger. In my kernel config I have this, because a diskless box uses the same kernel, but my /etc/fstab doesn't mount anyone else's NFS exports. options NFSCLIENT #Network Filesystem Client [EMAIL PROTECTED]<101> ps -axww|grep nfs 42 ?? IL 0:00.00 (nfsiod 0) 43 ?? IL 0:00.00 (nfsiod 1) 44 ?? IL 0:00.00 (nfsiod 2) 45 ?? IL 0:00.00 (nfsiod 3) 428 ?? Is 0:00.03 nfsd: master (nfsd) 429 ?? I 0:00.09 nfsd: server (nfsd) 430 ?? I 0:00.00 nfsd: server (nfsd) 431 ?? I 0:00.00 nfsd: server (nfsd) 432 ?? I 0:00.00 nfsd: server (nfsd) 35366 p0 R+ 0:00.00 grep nfs > At the ddb prompt you should be able to use the write command tweak a > couple of variables to modify this behavior. If you set the > vfs_badlock_panic variable to zero, the kernel will no longer drop into > DDB when one of these lock violations occurs. If you set the > vfs_badlock_print variable to zero, the kernel will stop printing the > warnings. OK, I've done a examine vfs_badlock_panic which shows it zero, then write vfs_badlock_panic 0 at least for now. Thanks again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI suspending.
I have a Dell D800 laptop (as I've mentioned a few times here) and I've gone so far as to upgrade the BIOS to A03 and fetch new ACPI DSDT code from the linux site. Before fetching the code, most ACPI functions were broken ... including the amount of battery remaining. After updating, most functions are fixed ... the battery interface is picking up the batteries and the expected runtime and the 'S1' suspend appears to be working correctly. The 'S1' suspend is where the processor clock is halted. I assume that other things turn off ... but the laptop still generates enough heat to need it's fan ... especially if I try to put it in my laptop bag. What I'd like to know is how much work (and possibly pointers to where I'd look) to fix the S3 level suspension. S3 is suppsoed to only leave RAM power on ... which makes it sound an awful lot like the APM suspend I was used to on my last laptop. Is this a matter of fixing some more of the DSDT ... or is there some grovelling in the FreeBSD code that's appropriate? Is someone already working on this? Dave. -- |David Gilbert, Velocet Communications. | 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: __thread support in -current..
On Tue, 17 Jun 2003, Julian Elischer wrote: > I guess the support is in gcc as Linux and solaris use it, but > is our linker close enough to what they use to be able to benefit at all > from them? We'll need an updated GCC at the very least; I see some stuff in binutils regarding TLS. I think we're going to get updated binutils anway. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
EHCI USB on _top_ of UHCI?
I'm running 5.1-RELEASE and have USB2.0 ports in my Dell D800 laptop. I also have a USB2.0 drive encloseure with a 120G drive in it... so I'm very motivated to get this to work :). To start, I posted briefly about this before... and some people suggested that this may have a bad interaction with ACPI. I have ruled that out ... disabling ACPI or fixing ACPI (by obtaining fixed ACPI code) doesn't change the EHCI behaviour. So ... some datapoints. USB 1.1 (UHCI) works. If EHCI isn't in the kernel all manner of USB devices work. I have tested the drive, an external DVD enclosure and a mouse. This is good. However, if EHCI is in the kernel, attaching the drive gives the following messages: Jun 13 22:15:46 canoe kernel: usb3: unrecoverable error, controller halted Jun 13 22:15:46 canoe kernel: usb3: blocking intrs 0x10 Jun 13 22:16:05 canoe kernel: uhub3: device problem, disabling port 3 Jun 13 22:16:48 canoe kernel: usb3: port reset timeout Jun 13 22:16:48 canoe kernel: uhub3: port 1 reset failed ... and then usb doesn't work thereafter. Is this something that's fixable? I'm willing to do some work on this, but I'm a little at a loss on where to start. I intend to track -CURRENT with this laptop, but my attempt to move from 5.1-RELEASE to -CURRENT was stymied by source that wouldn't compile. For reference, here are all the USB related probe lines with EHCI compiled into the kernel: Jun 13 21:51:04 canoe kernel: uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 Jun 13 21:51:04 canoe kernel: usb0: on uhci0 Jun 13 21:51:04 canoe kernel: usb0: USB revision 1.0 Jun 13 21:51:04 canoe kernel: uhci1: port 0xbf40-0xbf5f irq 11 at device 29.1 on pci0 Jun 13 21:51:04 canoe kernel: usb1: on uhci1 Jun 13 21:51:04 canoe kernel: usb1: USB revision 1.0 Jun 13 21:51:04 canoe kernel: uhci2: port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 Jun 13 21:51:04 canoe kernel: usb2: on uhci2 Jun 13 21:51:04 canoe kernel: usb2: USB revision 1.0 Jun 13 21:51:04 canoe kernel: ehci0: mem 0xf4fffc00-0xf4ff irq 11 at device 29.7 on pci0 Jun 13 21:51:04 canoe kernel: ehci_pci_attach: companion usb0 Jun 13 21:51:04 canoe kernel: ehci_pci_attach: companion usb1 Jun 13 21:51:04 canoe kernel: ehci_pci_attach: companion usb2 Jun 13 21:51:04 canoe kernel: usb3: EHCI version 1.0 Jun 13 21:51:04 canoe kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 Jun 13 21:51:04 canoe kernel: usb3: on ehci0 Jun 13 21:51:04 canoe kernel: usb3: USB revision 2.0 Dave. -- |David Gilbert, Velocet Communications. | 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: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
On 17 Jun, Chris Shenton wrote:
> Don Lewis <[EMAIL PROTECTED]> writes:
>
>> I doubt it. I checked in a fix for this problem today so you should get
>> the fix when you next cvsup.
>
> Yup, many thanks.
>
>> Can you break into ddb and do a ps to find out what state all the
>> processes are in?
>
> I'm a newbie to ddb. Was able to get a ps from a hung system but
> didn't know how to capture it to send to you. Any hints?
If you have another machine and a null modem cable you can redirect the
system console of the machine to be debugged to a serial port and run
some comm software on the other machine so that you can capture all the
output from ddb.
Lacking that, there's the pencil and paper method that I used for far
too long.
>
>> You might want to try adding the DEBUG_VFS_LOCKS options to your
>> kernel config to see if that turns up anything.
>
> Oh, man, I'm getting killed here now. Rebuilt the kernel with that
> option (not found in GENERIC or other examples in /usr/src/sys/i386/conf/).
>
> Now the system is dropping into ddb ever minute or so with complaints
> like the following on the screen, and in /var/log/messages:
>
> Jun 17 21:06:08 PECTOPAH kernel: VOP_GETVOBJECT: 0xc584eb68 is not locked but should
> be
> Jun 17 21:08:04 PECTOPAH last message repeated 3 times
> ...
> Jun 17 21:18:55 PECTOPAH kernel: VOP_GETVOBJECT: 0xc59346d8 is not locked but should
> be
> Jun 17 21:18:59 PECTOPAH last message repeated 5 times
>
> Lots 'n' lots of 'em, with a few of the same hex value then another
> set for a different hex value.
Been there, but that was quite a while ago. I run this way all the time
and hardly ever see problems these days. You must be exercising some
file system code that I don't. At the ddb prompt, you can do a "tr"
command to get a stack trace, which is likely to be very helpful in
pointing out the offending code.
If you're getting a lot of VFS lock violation reports, the underlying
locking violations could be the reason that your machine deadlocks.
Post some representative stack traces. These problems are generally
easy to fix.
>> There is also ddb command to list the locked vnodes "show
>> lockedvnods".
>
> After I type "cont" at ddb a few times the system runs for a while
> again, only to repeat. When it drops to ddb again that show command
> doesn't list anything.
>
> I may have to remove that option from my kernel just to get to run a
> bit, even tho eventually the system will hang. It's (of course) my
> main box which the other systems NFS off, mail server, etc. :-(
At the ddb prompt you should be able to use the write command tweak a
couple of variables to modify this behavior. If you set the
vfs_badlock_panic variable to zero, the kernel will no longer drop into
DDB when one of these lock violations occurs. If you set the
vfs_badlock_print variable to zero, the kernel will stop printing the
warnings.
If you are running the NFS *client* code on this machine, there is one
lock assertion that is easy to trigger. The stack trace will show the
nfsiod process calling nfssvc_iod(), which calls nfs_doio(), which
complains about a lock not being held. If you run into that problem,
just comment out the line:
ASSERT_VOP_LOCKED(vp, "nfs_doio");
in nfs_doio(), in the file sys/nfsclient/nfs_bio.c. I haven't been able
to figure out the correct fix for this problem, and so far I haven't
encountered any problems with the problem being unfixed.
>
>> Are you using nullfs or unionfs which are a bit fragile?
>
> Nope. I'd be happy to mail you my kernel config if you want. I've
> posted it to http://chris.shenton.org/PECTOPAH but if the system's
> hung again, naturally it won't be available :-(
>
>
> Thanks for your help. Any other things I might try?
>
> Dunno if this matters, but I'm using an DELL CERC ATA RAID card with
> disks showing up as amrd* if that matters. Was flawless at
> 5.0-{CURRENT,RELEASE}.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SCSI CD mount problems
I have a Yamaha CRW4416S CD drive as /dev/cd0. When I try to mount a disk, it says "cd9660: /dev/cd0: Invalid argument", and this in the log file: (cd0:ahc0:0:3:0): READ(10). CDB: 28 0 0 0 0 10 0 0 1 0 (cd0:ahc0:0:3:0): CAM Status: SCSI Status Error (cd0:ahc0:0:3:0): SCSI Status: Check Condition (cd0:ahc0:0:3:0): ILLEGAL REQUEST asc:21,0 (cd0:ahc0:0:3:0): Logical block address out of range (cd0:ahc0:0:3:0): Unretryable error (cd0:ahc0:0:3:0): cddone: got error 0x16 back I know the drive works, I can write good disks with it. What's happening here? This is on 5.1-RELEASE. -Guy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is rogue?
On Tue, Jun 17, 2003 at 06:52:26PM -0700, Kris Kennaway wrote: > On Tue, Jun 17, 2003 at 09:31:39PM -0400, Guy Middleton wrote: > > On Tue, Jun 17, 2003 at 06:17:01PM -0700, Kris Kennaway wrote: > > > On Tue, Jun 17, 2003 at 09:11:16PM -0400, Guy Middleton wrote: > > > > What happened to /usr/games/rogue in 5.1-RELEASE? It's not in > > > > /usr/ports/games either. > > > > > > Install the freebsd-games port. This is documented in the release > > > notes. > > > > Ok, now I'm confused. > > > > I installed freebsd-games, and it has most of the games I remember, but not > > rogue. > > Well, hrumph, it's supposed to be in that port. Mark, it looks like > rogue wasn't added for some reason. I looked again, and it's in the cvs directory there, but not mentioned in the Makefile. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is rogue?
On Tue, Jun 17, 2003 at 09:31:39PM -0400, Guy Middleton wrote: > On Tue, Jun 17, 2003 at 06:17:01PM -0700, Kris Kennaway wrote: > > On Tue, Jun 17, 2003 at 09:11:16PM -0400, Guy Middleton wrote: > > > What happened to /usr/games/rogue in 5.1-RELEASE? It's not in > > > /usr/ports/games either. > > > > Install the freebsd-games port. This is documented in the release > > notes. > > Ok, now I'm confused. > > I installed freebsd-games, and it has most of the games I remember, but not > rogue. Well, hrumph, it's supposed to be in that port. Mark, it looks like rogue wasn't added for some reason. Kris > > # pwd > /usr/ports/games/freebsd-games/work/freebsd-games-5.0 > # ls > Makefilebattlestar hackpiano snake > Makefile.incbs hangman pig trek > adventure canfieldlarnquizvar.mtree > arithmetic cribbagemille robots worm > atc cvs newdist.sh sailwump > backgammon fishphantasia share.mtree > # > # grep rogue pkg-plist > # > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" pgp0.pgp Description: PGP signature
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
Oh, FWIW, I did a cvsup and rebuilt the OS and kernel then did a mergemaster about 30 minutes ago in order to get your fix to my qmail issue. So I'm running about as CURRENT as possible. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
Don Lewis <[EMAIL PROTECTED]> writes:
> I doubt it. I checked in a fix for this problem today so you should get
> the fix when you next cvsup.
Yup, many thanks.
> Can you break into ddb and do a ps to find out what state all the
> processes are in?
I'm a newbie to ddb. Was able to get a ps from a hung system but
didn't know how to capture it to send to you. Any hints?
> You might want to try adding the DEBUG_VFS_LOCKS options to your
> kernel config to see if that turns up anything.
Oh, man, I'm getting killed here now. Rebuilt the kernel with that
option (not found in GENERIC or other examples in /usr/src/sys/i386/conf/).
Now the system is dropping into ddb ever minute or so with complaints
like the following on the screen, and in /var/log/messages:
Jun 17 21:06:08 PECTOPAH kernel: VOP_GETVOBJECT: 0xc584eb68 is not locked but should be
Jun 17 21:08:04 PECTOPAH last message repeated 3 times
...
Jun 17 21:18:55 PECTOPAH kernel: VOP_GETVOBJECT: 0xc59346d8 is not locked but should be
Jun 17 21:18:59 PECTOPAH last message repeated 5 times
Lots 'n' lots of 'em, with a few of the same hex value then another
set for a different hex value.
> There is also ddb command to list the locked vnodes "show
> lockedvnods".
After I type "cont" at ddb a few times the system runs for a while
again, only to repeat. When it drops to ddb again that show command
doesn't list anything.
I may have to remove that option from my kernel just to get to run a
bit, even tho eventually the system will hang. It's (of course) my
main box which the other systems NFS off, mail server, etc. :-(
> Are you using nullfs or unionfs which are a bit fragile?
Nope. I'd be happy to mail you my kernel config if you want. I've
posted it to http://chris.shenton.org/PECTOPAH but if the system's
hung again, naturally it won't be available :-(
Thanks for your help. Any other things I might try?
Dunno if this matters, but I'm using an DELL CERC ATA RAID card with
disks showing up as amrd* if that matters. Was flawless at
5.0-{CURRENT,RELEASE}.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is rogue?
On Tue, Jun 17, 2003 at 06:17:01PM -0700, Kris Kennaway wrote: > On Tue, Jun 17, 2003 at 09:11:16PM -0400, Guy Middleton wrote: > > What happened to /usr/games/rogue in 5.1-RELEASE? It's not in > > /usr/ports/games either. > > Install the freebsd-games port. This is documented in the release > notes. Ok, now I'm confused. I installed freebsd-games, and it has most of the games I remember, but not rogue. # pwd /usr/ports/games/freebsd-games/work/freebsd-games-5.0 # ls Makefilebattlestar hackpiano snake Makefile.incbs hangman pig trek adventure canfieldlarnquizvar.mtree arithmetic cribbagemille robots worm atc cvs newdist.sh sailwump backgammon fishphantasia share.mtree # # grep rogue pkg-plist # ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Don Lewis <[EMAIL PROTECTED]> writes: > Thanks for doing the testing. I just committed this patch. Seems fine here too -- many thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is rogue?
On Tue, Jun 17, 2003 at 06:17:01PM -0700, Kris Kennaway wrote: > On Tue, Jun 17, 2003 at 09:11:16PM -0400, Guy Middleton wrote: > > What happened to /usr/games/rogue in 5.1-RELEASE? It's not in > > /usr/ports/games either. > > Install the freebsd-games port. This is documented in the release > notes. Duh. Silly me. Thanks. -Guy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is rogue?
On Tue, Jun 17, 2003 at 09:11:16PM -0400, Guy Middleton wrote: > What happened to /usr/games/rogue in 5.1-RELEASE? It's not in > /usr/ports/games either. Install the freebsd-games port. This is documented in the release notes. Kris pgp0.pgp Description: PGP signature
where is rogue?
What happened to /usr/games/rogue in 5.1-RELEASE? It's not in /usr/ports/games either. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mount_ntfs causes panic
I updated my laptop kernel to 5.1-CURRENT and got into trouble.
FreeBSD mebius 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun 17 09:36:21 JST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
This laptop also runs Windows 2000 whose filesystem is NTFS and this
NTFS part is mounted from FreeBSD with read-only.
/etc/fstab:
/dev/ad0s2 /mnt/winnt ntfsro,noauto 0 0
When "mount /mnt/winnt", the system falls into DDB.
Here is a backtrace.
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc030f113 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc030f483 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc01631b2 in db_panic () at /usr/src/sys/ddb/db_command.c:449
#4 0xc0163132 in db_command (last_cmdp=0xc052a9f0, cmd_table=0x0,
aux_cmd_tablep=0xc0521848, aux_cmd_tablep_end=0xc0521860)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0163246 in db_command_loop () at /usr/src/sys/ddb/db_command.c:471
#6 0xc0165fda in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc048ab75 in kdb_trap (type=3, code=0, regs=0xcb48637c)
at /usr/src/sys/i386/i386/db_interface.c:172
#8 0xc049c21c in trap (frame=
{tf_fs = -1067581416, tf_es = -884473840, tf_ds = -1070596080, tf_edi = 1,
tf_esi = -1068469573, tf_ebp = -884448312, tf_isp = -884448344, tf_ebx = 0, tf_edx =
0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068978668, tf_cs =
8, tf_eflags = 642, tf_esp = -1068390229, tf_ss = -1068493137})
at /usr/src/sys/i386/i386/trap.c:595
#9 0xc048c4c8 in calltrap () at {standard input}:96
#10 0xc030f41c in panic (
fmt=0xc05072bb "bundirty: buffer %p still on queue %d")
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc0354331 in bundirty (bp=0xc5b85830) at /usr/src/sys/kern/vfs_bio.c:1126
#12 0xc0354e61 in brelse (bp=0xc5b85830) at /usr/src/sys/kern/vfs_bio.c:1441
---Type to continue, or q to quit---
#13 0xc0353c01 in bwrite (bp=0xc5b85830) at /usr/src/sys/kern/vfs_bio.c:884
#14 0xc0356b82 in getblk (vp=0xc2943000, blkno=13504625, size=1024, slpflag=0,
slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2516
#15 0xc03535e2 in breadn (vp=0xc2943000, blkno=0, size=0, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at /usr/src/sys/kern/vfs_bio.c:702
#16 0xc035358c in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0)
at /usr/src/sys/kern/vfs_bio.c:684
#17 0xc2977f9b in ntfs_readntvattr_plain (ntmp=0xc22dc000, ip=0xc22dc200,
vap=0xc2692a00, roff=0, rsize=0, rdata=0x0, initp=0xcb4866ac, uio=0x0)
at /usr/src/sys/fs/ntfs/ntfs_subr.c:1555
#18 0xc2978382 in ntfs_readattr_plain (ntmp=0xc22dc000, ip=0xc22dc200,
attrnum=128, attrname=0x0, roff=480, rsize=160, rdata=0xcb4867cc,
initp=0xcb48674c, uio=0x0) at /usr/src/sys/fs/ntfs/ntfs_subr.c:1646
#19 0xc29788a4 in ntfs_readattr (ntmp=0xc22dc000, ip=0xc22dc200, attrnum=128,
attrname=0x0, roff=480, rsize=160, rdata=0xcb4867cc, uio=0x0)
at /usr/src/sys/fs/ntfs/ntfs_subr.c:1760
#20 0xc297374d in ntfs_mountfs (devvp=0xc2943000, mp=0xc2691400,
argsp=0xcb4868e8, td=0xc2026e40) at /usr/src/sys/fs/ntfs/ntfs_vfsops.c:405
#21 0xc297325d in ntfs_mount (mp=0xc2943000, path=0xc2317d80 "/mnt/winnt",
data=0x0, ndp=0x3, td=0xc2026e40) at /usr/src/sys/fs/ntfs/ntfs_vfsops.c:235
#22 0xc03613db in vfs_mount (td=0xc2026e40, fstype=0xc2026e40 "t7",
fspath=0xc2317d80 "/mnt/winnt", fsflags=-1030475776, fsdata=0x0)
at /usr/src/sys/kern/vfs_mount.c:1091
---Type to continue, or q to quit---
#23 0xc0360b48 in mount (td=0x0, uap=0xcb486d10)
at /usr/src/sys/kern/vfs_mount.c:847
#24 0xc049cafe in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077937176, tf_esi = -1077936859,
tf_ebp = -1077937152, tf_isp = -884445836, tf_ebx = -1077938936, tf_edx = -1077936849,
tf_ecx = -1077936849, tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134520903,
tf_cs = 31, tf_eflags = 518, tf_esp = -1077938980, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1023
#25 0xc048c51d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
--
NAKAJI Hiroyuki
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nvidia, TLS and __thread keyword -- an observation
On Tue, 17 Jun 2003, Marcel Moolenaar wrote: > On Tue, Jun 17, 2003 at 03:02:20PM -0700, Julian Elischer wrote: > > > > > > On Tue, 17 Jun 2003, Marcel Moolenaar wrote: > > > > > Guys, > > > > > > In short: Don't bash Nvidia. What they do is not uncommon. Well, > > > maybe in Open Source environments. So please end this thread, > > > unless people get constructive. > > > > I think its already ended.. > > > > basically: > > We should alwasy be able to use (on i386) the sam amethods outlined for > > solaris. > > Not quite as quick as those for Linux but more general. > > I'm not sure you understand the issue (I can easily be wrong, I just > don't see the evidence in your statement). I understand what is needed from the thread library. I am asking for input from people who understand the toolchain :-) > To support the __thread > keyword, our thread library needs to create the TLS as defined in the > binary and its dependent shared libraries by virtue of the .tdata and > .tbss sections/segments, based on the image of the TLS as constructed > by the RTLD for the initial set of modules (created for the initial > thread) and amended by TLS space defined in the dynamicly loaded > libraries; and the TLS has to be created for every new thread at the > time the thread itself is created. Geez considerred writing shorter sentences? :-) there is no reason that all our thread libraries cannot set up TLS sections associated with each modile linked. (Assuming there is a good description as to how it should be done) The ammending need not be done up front if the dynamic model is used.. > This TLS allocation has to be made > accessable in accordance with runtime specifications for the supported > architectures (libthr: i386 & ia64; libkse: i386 currently -- more to > follow) and in line with the access sequences created by the compiler, > and using the static relocations known to the static linker and dynamic > relocations of which the support needs to be added to RTLD. exactly. Though, I might add that we don't need to follow the spec exactly. In the same way that Solaris has an "excepmtion" and has its own version of the spec we could do so too. It turns out however that the solaris-x86 spec is very close to what we want and need anyhow. Libthr and libkse (i386) can be modified to both have the same support. The spec requires that %gs:0 is the address of a pointer to the thread control block (TCB). In kse this is easily achieved by puting such a pointer at the front of the KSE mailbox. (where %gs points), and in libthr the pointer points directly to the TCB itself (as far as I see) and there could be a pointer to itself set there. for libc_r we could set up %gs to be anything we want as we don't use it as such.. anyway. the three libraries would stay binarily compatible. We obviously would need to add code to do teh initialisation of the .tdata and .tbss segments as indicated in the doc. but it all looks doable. (though rather hacky). > > The static TLS model requires the least amount of work: add support > to allocate the TLS image for every thread creation and point the > thread pointer to it in a way compatible with the runtime spec. yes We can do this. I disagree however that it requires the LEAST amount of work.. > > The dynamic TLS model requires more substantial changes and involves > RTLD as well. This is the model that requires __tls_get_addr(). By my reading of it, you can't use the static model alone. If you have dynamically loaded modules you need to be able to use the dynamic model. Anyway that's why I'm asking.. we need to have people who understand the rtld in on the discussion because we will need to do this. > > -- > Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-threads 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: __thread support in -current..
see my answer to you there..
On Tue, 17 Jun 2003, Marcel Moolenaar wrote:
> On Tue, Jun 17, 2003 at 03:34:15PM -0700, Julian Elischer wrote:
> >
> > Ok, so having thrashed out what is required on the threads list
> > (and severely strained (but hopefully not permanently) our relations
> > with the OpenGL folks) we've figured out that we do need to support
> > __thread (if we don't we'll miss out on alot).
> >
> > I have basicaly worked out what we need to do
> > (Generarlly we do the same as solaris does) to support this..
> > The question is, what do we need to do for gcc and the loader
> > to support this..?
> >
> > I guess the support is in gcc as Linux and solaris use it, but
> > is our linker close enough to what they use to be able to benefit at all
> > from them?
>
> >From my posting to threads@:
>
> \begin{quote}
> ... To support the __thread
> keyword, our thread library needs to create the TLS as defined in the
> binary and its dependent shared libraries by virtue of the .tdata and
> .tbss sections/segments, based on the image of the TLS as constructed
> by the RTLD for the initial set of modules (created for the initial
> thread) and amended by TLS space defined in the dynamicly loaded
> libraries; and the TLS has to be created for every new thread at the
> time the thread itself is created. This TLS allocation has to be made
> accessable in accordance with runtime specifications for the supported
> architectures (libthr: i386 & ia64; libkse: i386 currently -- more to
> follow) and in line with the access sequences created by the compiler,
> and using the static relocations known to the static linker and dynamic
> relocations of which the support needs to be added to RTLD.
>
> The static TLS model requires the least amount of work: add support
> to allocate the TLS image for every thread creation and point the
> thread pointer to it in a way compatible with the runtime spec.
>
> The dynamic TLS model requires more substantial changes and involves
> RTLD as well. This is the model that requires __tls_get_addr().
> \end{quote}
>
> HTH,
>
> --
> Marcel Moolenaar USPA: A-39004 [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]"
Re: ACPI testing/debugging guide?
On Tue, Jun 17, 2003 at 03:54:13PM -0700, Hiten Pandya wrote: > On Tue, Jun 17, 2003 at 04:29:59PM -0600, M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > Dan Nelson <[EMAIL PROTECTED]> writes: > > : ACPI records temperature in tenths of a Kelvin, if you can believe it :) > > > > I don't believe that. 369.2K is 96.2C, which is over 200F. That seems > > to hot to me. My laptop says 2982, which is either about 30C or > > 15.2C. Given how warm it is on my leg at the moment, I'd guess it is > > centi-Celcius. Maybe converted internally? > > Why not the use http://people.freebsd.org/~hmp/acpi_temp.c 19:07:39 Tue Jun 17 $ ./acpi_temp System temperature = 333.2 K 60.0 C 140.0 F hw.acpi.thermal.tz0.temperature: 3332 but all that program does is read the oid and do the math just like I did on my TI-85. -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
On Tue, Jun 17, 2003 at 03:54:34PM -0700, Kevin Oberman wrote: > > I am also seeing the same thing on my T30 when I run ACPI. It's the > temperature, not any of the others. It was reading 3186 and that seems > about right for centi-degrees C. (31.86C) Kelvin simply does not > compute. According to the spec, it does. Google for acpi - the official spec is at the first entry. Anyway, 318.6 - 273.2 = 45.4C, which is perfectly reasonable. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
On Tue, Jun 17, 2003 at 06:40:26PM -0400, Barney Wolff wrote: > On Tue, Jun 17, 2003 at 04:29:59PM -0600, M. Warner Losh wrote: > > : > > : ACPI records temperature in tenths of a Kelvin, if you can believe it :) > > > > I don't believe that. 369.2K is 96.2C, which is over 200F. That seems > > to hot to me. My laptop says 2982, which is either about 30C or > > 15.2C. Given how warm it is on my leg at the moment, I'd guess it is > > centi-Celcius. Maybe converted internally? > > Reading the source, it really is tenths Kelvin. Is the 3692 the actual > temp, or the CRT, which I assume is the critical temp? In the output > of sysctl hw.acpi.thermal.tz0 there are a bunch of values, only one of > which is the current temp. The rest are thresholds - AC appears to mean > active cooling (aka fan), PSV seems to mean passive. I was shocked at the dK values. However, combined with the fact that this thing is often too hot to touch with bare skin, I am temped to believe in dK. It is definately too hot. Hence, my desire for the ability to keep the fan on all the time. :-) Last night it was: hw.acpi.thermal.tz0.temperature: 3352 (62.05C 143.69F) Current values: hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 30 hw.acpi.thermal.tz0.temperature: 3302 (57.05C 134.69F) hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3692 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3702 hw.acpi.thermal.tz0._ACx: 3692 3692 -1 -1 -1 -1 -1 -1 -1 -1 -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
> Date: Tue, 17 Jun 2003 18:40:26 -0400 > From: Barney Wolff <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > On Tue, Jun 17, 2003 at 04:29:59PM -0600, M. Warner Losh wrote: > > : > > : ACPI records temperature in tenths of a Kelvin, if you can believe it :) > > > > I don't believe that. 369.2K is 96.2C, which is over 200F. That seems > > to hot to me. My laptop says 2982, which is either about 30C or > > 15.2C. Given how warm it is on my leg at the moment, I'd guess it is > > centi-Celcius. Maybe converted internally? > > Reading the source, it really is tenths Kelvin. Is the 3692 the actual > temp, or the CRT, which I assume is the critical temp? In the output > of sysctl hw.acpi.thermal.tz0 there are a bunch of values, only one of > which is the current temp. The rest are thresholds - AC appears to mean > active cooling (aka fan), PSV seems to mean passive. I am also seeing the same thing on my T30 when I run ACPI. It's the temperature, not any of the others. It was reading 3186 and that seems about right for centi-degrees C. (31.86C) Kelvin simply does not compute. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
On Tue, Jun 17, 2003 at 04:29:59PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Dan Nelson <[EMAIL PROTECTED]> writes: > : In the last episode (Jun 17), Scott Lambert said: > : > Is there some list of actions to preform and data to collect that > : > would assist with getting the ACPI stuff lined out? > : > > : > I've read the acpiconf man page but don't know that it gives me any > : > way to test for any specific functionality. I've been gradually > : > piecing together the meaning of S1, S2, S3, S4, and S5 and figuring > : > out that the *_(button|switch)_state sysctl oids specify which state > : > to go to on activation of that button rather than being a descriptor > : > of the current state of the buttons. > : > > : > I haven't figured out if the hw.acpi.thermal oids. I think maybe > : > ACPI doesn't recognize the hardware. Is a thermal oid value of 3692 > : > actually 36.92 celcius or some scale from 0x to 0x? > : > : ACPI records temperature in tenths of a Kelvin, if you can believe it :) > > I don't believe that. 369.2K is 96.2C, which is over 200F. That seems > to hot to me. My laptop says 2982, which is either about 30C or > 15.2C. Given how warm it is on my leg at the moment, I'd guess it is > centi-Celcius. Maybe converted internally? Why not the use http://people.freebsd.org/~hmp/acpi_temp.c -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __thread support in -current..
On Tue, Jun 17, 2003 at 03:34:15PM -0700, Julian Elischer wrote:
>
> Ok, so having thrashed out what is required on the threads list
> (and severely strained (but hopefully not permanently) our relations
> with the OpenGL folks) we've figured out that we do need to support
> __thread (if we don't we'll miss out on alot).
>
> I have basicaly worked out what we need to do
> (Generarlly we do the same as solaris does) to support this..
> The question is, what do we need to do for gcc and the loader
> to support this..?
>
> I guess the support is in gcc as Linux and solaris use it, but
> is our linker close enough to what they use to be able to benefit at all
> from them?
>From my posting to threads@:
\begin{quote}
... To support the __thread
keyword, our thread library needs to create the TLS as defined in the
binary and its dependent shared libraries by virtue of the .tdata and
.tbss sections/segments, based on the image of the TLS as constructed
by the RTLD for the initial set of modules (created for the initial
thread) and amended by TLS space defined in the dynamicly loaded
libraries; and the TLS has to be created for every new thread at the
time the thread itself is created. This TLS allocation has to be made
accessable in accordance with runtime specifications for the supported
architectures (libthr: i386 & ia64; libkse: i386 currently -- more to
follow) and in line with the access sequences created by the compiler,
and using the static relocations known to the static linker and dynamic
relocations of which the support needs to be added to RTLD.
The static TLS model requires the least amount of work: add support
to allocate the TLS image for every thread creation and point the
thread pointer to it in a way compatible with the runtime spec.
The dynamic TLS model requires more substantial changes and involves
RTLD as well. This is the model that requires __tls_get_addr().
\end{quote}
HTH,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __thread support in -current..
On Tue, 17 Jun 2003 15:34:15 -0700 (PDT) Julian Elischer <[EMAIL PROTECTED]> wrote: > > I guess the support is in gcc as Linux and solaris use it, but > is our linker close enough to what they use to be able to benefit at > all from them? > The __thread support is available in GCC 3.3+ only. The new compiler is likely to enter the tree at the end of this month/first week of June. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
On Tue, Jun 17, 2003 at 04:29:59PM -0600, M. Warner Losh wrote: > : > : ACPI records temperature in tenths of a Kelvin, if you can believe it :) > > I don't believe that. 369.2K is 96.2C, which is over 200F. That seems > to hot to me. My laptop says 2982, which is either about 30C or > 15.2C. Given how warm it is on my leg at the moment, I'd guess it is > centi-Celcius. Maybe converted internally? Reading the source, it really is tenths Kelvin. Is the 3692 the actual temp, or the CRT, which I assume is the critical temp? In the output of sysctl hw.acpi.thermal.tz0 there are a bunch of values, only one of which is the current temp. The rest are thresholds - AC appears to mean active cooling (aka fan), PSV seems to mean passive. How come xmbmon can't interpret acpi temps? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
__thread support in -current..
Ok, so having thrashed out what is required on the threads list (and severely strained (but hopefully not permanently) our relations with the OpenGL folks) we've figured out that we do need to support __thread (if we don't we'll miss out on alot). I have basicaly worked out what we need to do (Generarlly we do the same as solaris does) to support this.. The question is, what do we need to do for gcc and the loader to support this..? I guess the support is in gcc as Linux and solaris use it, but is our linker close enough to what they use to be able to benefit at all from them? Julian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple cardbus devices? (RFI)
In message: <[EMAIL PROTECTED]> Craig Boston <[EMAIL PROTECTED]> writes: : On Tue, 2003-06-17 at 08:21, M. Warner Losh wrote: : > Does the following, untested, patch help any better than your gross : > kludges? : : Hrm, actually it seems to have made it worse... Now they don't attach : at all. : : xl0: <3Com 3c575B Fast Etherlink XL> port 0x1000-0x107f mem : 0x8800-0x887f,0x8880-0x88ff irq 11 at device 0.0 on : cardbus0 That's not 4k! :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
In message: <[EMAIL PROTECTED]> Dan Nelson <[EMAIL PROTECTED]> writes: : In the last episode (Jun 17), Scott Lambert said: : > Is there some list of actions to preform and data to collect that : > would assist with getting the ACPI stuff lined out? : > : > I've read the acpiconf man page but don't know that it gives me any : > way to test for any specific functionality. I've been gradually : > piecing together the meaning of S1, S2, S3, S4, and S5 and figuring : > out that the *_(button|switch)_state sysctl oids specify which state : > to go to on activation of that button rather than being a descriptor : > of the current state of the buttons. : > : > I haven't figured out if the hw.acpi.thermal oids. I think maybe : > ACPI doesn't recognize the hardware. Is a thermal oid value of 3692 : > actually 36.92 celcius or some scale from 0x to 0x? : : ACPI records temperature in tenths of a Kelvin, if you can believe it :) I don't believe that. 369.2K is 96.2C, which is over 200F. That seems to hot to me. My laptop says 2982, which is either about 30C or 15.2C. Given how warm it is on my leg at the moment, I'd guess it is centi-Celcius. Maybe converted internally? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with pcmcia on 5.1-RELEASE
In message: <[EMAIL PROTECTED]> Christian Laursen <[EMAIL PROTECTED]> writes: : "M. Warner Losh" <[EMAIL PROTECTED]> writes: : : > In message: <[EMAIL PROTECTED]> : > Christian Laursen <[EMAIL PROTECTED]> writes: : > : pccard0: (manufacturer=0x, product=0x) at function 0 : > : pccard0:CIS info: FREECOM, PCCARD-IDE, REV836 : > : > Looks like we need another entry in ata-card.c for this device. : > : > I've added this to the kernel list. Please recvsup and make sure you : > have sys/dev/pccard/pccarddevs 1.53, pccarddevs.h 1.53 and : > sys/dev/ata/ata-card.c 1.14. : : Thank you very much. : : Unfortunately, like the patch Matthew N. Dodd posted, this gives me : an extra ata channel, but no devices are found on it. : : I have tried various commands to atacontrol, but nothing seems to : help. : : I'm not sure how to help debug this further. I have a stupid question: Are you sure that your cdrom is turned on? I have some that need an aux power connection before they work. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple cardbus devices? (RFI)
On Tue, 2003-06-17 at 08:21, M. Warner Losh wrote: > Does the following, untested, patch help any better than your gross > kludges? Hrm, actually it seems to have made it worse... Now they don't attach at all. xl0: <3Com 3c575B Fast Etherlink XL> port 0x1000-0x107f mem 0x8800-0x887f,0x8880-0x88ff irq 11 at device 0.0 on cardbus0 xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: eeprom failed to come ready xl0: failed to read station address device_probe_and_attach: xl0 attach returned 6 Please excuse any typos -- had to copy by hand as my NIC isn't working at the moment :) It used to map the second memory range starting at 88000100 > One might be able to share the 4k range between devices if > one had, say, two xl cards (I'd have to look hard at the code to be > sure), but very few machines are so memory constrained as to make that > a big win for the hair it would add to the code. I'm not sure that will work, at least not without special handling on the xl (or whatever device) driver's part. I have two xl cards and when they are mapped into the same 4k range the second one doesn't attach and the first stops working. They're not identical though -- one is a 575BT and the other is a 575CT. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Giant pushdown in kern_descrip.c rev 1.128
* Don Lewis <[EMAIL PROTECTED]> [030617 13:06] wrote: > On 17 Jun, Alfred Perlstein wrote: > > * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote: > >> It's not legal to attempt to aquire Giant in fdrop_locked(), while > >> FILE_LOCK() is held. The problem is that FILE_LOCK uses the mutex pool, > >> which should only be used for leaf mutexes. > >> > >> It also looks like there is a potential for a lock order reversal if > >> some callers aquire Giant before FILE_LOCK() and fdrop_locked() does the > >> opposite. > >> > >> It also appears that witness ignores the mutex pool ... > > > > Yes, but I think the fix is as simple as just dropping the FILE_LOCK > > after the decrement as we're the last holders of it, can you try > > this: > > I like simple fixes, especially when the code shrinks ;-) > > Unfortunately, I think your point about this only happening because this > process is the last holder of the file means that this doesn't explain > Peter's deadlock. You can still deadlock because another file's mutex may hash to the same location. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA DMA broken/kernel panic with 5.1-R/5.1-C and VIA 82C586B
Tuesday, June 17, 2003, 11:24:53 PM, you wrote: > Hi > I installed 5.1-RELEASE from the CD images, and have problems using DMA > on my ATA discs. I get the same problem on several discs, both several > years old and brand new, across several vendors. 4.6-RELEASE handles the > discs fine. Relevant excepts from the boot messages are below, the > entire thing can be seen at http://www.esperi.org/nicolai/misc/dmesg.eriador [...] > Is this a known problem, perhaps specific to the 82C586B ATA controller? Had the same kind of bug on a quite old motherboard with an intel controller : atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 Kernel and world are a bit older : FreeBSD cragganmore.lacave.local 5.1-BETA2 FreeBSD 5.1-BETA2 #0: Thu May 22 16:18:16 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CRAGGANMORE i386 (The bug did happen with the first boot on the generic kernel.) Currently, I run it in PIO mode ; the machine is in use, I can't afford much downtime. If I can provide other information with the machine running, I'd be glad to help. > Thanks > Nicolai Fred Who had forgotten about this bug... :) -- And you run and you run to catch up with the sun, but it's sinking And racing around to come up behind you again The sun is the same in the relative way, but you're older Shorter of breath and one day closer to death (Pink Floyd, Time) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA DMA broken/kernel panic with 5.1-R/5.1-C and VIA 82C586B
It seems Nicolai E M Plum wrote: > Hi > > I installed 5.1-RELEASE from the CD images, and have problems using DMA > on my ATA discs. I get the same problem on several discs, both several > years old and brand new, across several vendors. 4.6-RELEASE handles the > discs fine. Relevant excepts from the boot messages are below, the > entire thing can be seen at http://www.esperi.org/nicolai/misc/dmesg.eriador > > FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > ... > atapci0: port 0xfcd0-0xfcdf mem > 0xfbffe000-0xfbff at device 7.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > ... > Timecounters tick every 10.000 msec > ad0: 114473MB [232581/16/63] at ata0-master UDMA33 > ad0: READ command timeout tag=0 serv=0 - resetting > ata0: resetting devices .. > done > ... [ this repeats ] > ad1: trying fallback to PIO mode > ata0: resetting devices .. > done > Mounting root from ufs:/dev/ad0s1a > > I noticed some ATA problems solved in -current recently, so I tried > compiling a kernel from sources about 2 days ago. Booting from that > (GENERIC) kernel, I do not get "Mounting root..", instead I get > (approximately, can't cut/paste that console): > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xdeadc0de > fault code = supervisor read, page not present > instruction pointer = 0x8:0xdeadcode > stack pointer = 0x10:0xc736bc38 > frame pointer = 0x19:0xc736bc50 > > current process = 21 (irc14: ata0) > kernel: type 12 trap, code=0 > > Is this a known problem, perhaps specific to the 82C586B ATA controller? This looks strange, I dont have semilar HW here to verify the problem so I'm a bit in the dark. Is it possible you can build a kernel with ddb in it so we can get a traceback of the panic ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE nice bugs are fixed.
On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: > > I am still not able to reproduce this. Can you update your sources? I > commited some code just now that removed an external dependency from > sched_nice(). This should make it more robust. Got it - its LAZY_SWITCH, without it - all is working fine, but when this option is set, I get panics. Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATA DMA broken/kernel panic with 5.1-R/5.1-C and VIA 82C586B
Hi I installed 5.1-RELEASE from the CD images, and have problems using DMA on my ATA discs. I get the same problem on several discs, both several years old and brand new, across several vendors. 4.6-RELEASE handles the discs fine. Relevant excepts from the boot messages are below, the entire thing can be seen at http://www.esperi.org/nicolai/misc/dmesg.eriador FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ... atapci0: port 0xfcd0-0xfcdf mem 0xfbffe000-0xfbff at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ... Timecounters tick every 10.000 msec ad0: 114473MB [232581/16/63] at ata0-master UDMA33 ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. done ... [ this repeats ] ad1: trying fallback to PIO mode ata0: resetting devices .. done Mounting root from ufs:/dev/ad0s1a I noticed some ATA problems solved in -current recently, so I tried compiling a kernel from sources about 2 days ago. Booting from that (GENERIC) kernel, I do not get "Mounting root..", instead I get (approximately, can't cut/paste that console): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code= supervisor read, page not present instruction pointer = 0x8:0xdeadcode stack pointer = 0x10:0xc736bc38 frame pointer = 0x19:0xc736bc50 current process = 21 (irc14: ata0) kernel: type 12 trap, code=0 Is this a known problem, perhaps specific to the 82C586B ATA controller? Thanks Nicolai ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI mailling list?
>To: [EMAIL PROTECTED] >From: Jesse Guardiani <[EMAIL PROTECTED]> >Date: Tue, 17 Jun 2003 16:42:22 -0400 >Subject: ACPI mailling list? >Reply-To: [EMAIL PROTECTED] [I will Cc: -current despite that request.] >Is there an ACPI mailling list I can join >to help debug/test ACPI? See http://www.jp.freebsd.org/acpi/ for furtehr information on this. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Based on what I have seen to date, the use of Microsoft products is not consistent with reliability. I recommend FreeBSD for reliable systems. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI mailling list?
Howdy list, Is there an ACPI mailling list I can join to help debug/test ACPI? I'm a decent C programmer, and I'd really like to get ACPI support working on my IBM Thinkpad A30p. Unfortunately, no-one has responded to my questions about ACPI on this laptop. Is anyone actively working on ACPI support? Thanks. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fdrop_locked() and FILE_LOCK() vs. Giant
On 17 Jun, Robert Watson wrote: > > On Tue, 17 Jun 2003, Don Lewis wrote: > >> The FILE_LOCK() implementation uses "pool mutex" under the hood, which >> means it should only be used as a leaf level mutex. The fdrop_locked() >> code wants to be called with FILE_LOCK() held, but the fdrop_locked() >> implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK(). In >> addition to violating the proper usage of the "pool mutex", there is >> also the potential for a lock order violation. The close() >> implementation grabs Giant and eventually calls fdrop(), which calls >> FILE_LOCK() immediately before calling fdrop_locked(). If another >> caller of fdrop_locked() calls FILE_LOCK() without grabbing Giant first, >> then the lock order will be reversed when fdrop_locked() grabs Giant. >> >> It looks like fdrop_locked() should require that Giant be grabbed by the >> caller before fdrop_locked() is called. > > I've also noticed that the file descriptor lock is held over per-object > calls to fo_poll(), which currently isn't a big deal for most objects, but > may be in the future if we have to grab other locks in order to test the > poll status inside the object. I run into this problem with the MAC work > because the vnode label is protected by the vnode lock, which is a > sleepable lock. We may want to change label locking in the future to > avoid this, but in the mean time I get a lot of witness warnings, and > using a pool mutex for the fd lock may cause lock order problems if there > is more complex locking. Does witness even keep track of the pool mutex stuff? It doesn't seem to report any lock order problems in the fdrop_locked() case. I'm attempting to debug a deadlock problem for someone, and one process is hung on FILE_LOCK() in fdrop(), but "show witness" in ddb doesn't mention any "pool mutex" holders. The process hung in fdrop() got there by calling close(), which grabs Giant. Once it wedge, then everything else on the system stacked up waiting for Giant. Alfred mentioned that fdrop_locked() can be easily fixed by dropping the file lock a bit sooner. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Giant pushdown in kern_descrip.c rev 1.128
On 17 Jun, Alfred Perlstein wrote:
> * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
>> It's not legal to attempt to aquire Giant in fdrop_locked(), while
>> FILE_LOCK() is held. The problem is that FILE_LOCK uses the mutex pool,
>> which should only be used for leaf mutexes.
>>
>> It also looks like there is a potential for a lock order reversal if
>> some callers aquire Giant before FILE_LOCK() and fdrop_locked() does the
>> opposite.
>>
>> It also appears that witness ignores the mutex pool ...
>
> Yes, but I think the fix is as simple as just dropping the FILE_LOCK
> after the decrement as we're the last holders of it, can you try
> this:
I like simple fixes, especially when the code shrinks ;-)
Unfortunately, I think your point about this only happening because this
process is the last holder of the file means that this doesn't explain
Peter's deadlock.
> Index: kern_descrip.c
> ===
> RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
> retrieving revision 1.199
> diff -u -r1.199 kern_descrip.c
> --- kern_descrip.c11 Jun 2003 00:56:55 - 1.199
> +++ kern_descrip.c17 Jun 2003 19:07:01 -
> @@ -2003,6 +2003,7 @@
> FILE_UNLOCK(fp);
> return (0);
> }
> + FILE_UNLOCK(fp);
> mtx_lock(&Giant);
> if (fp->f_count < 0)
> panic("fdrop: count < 0");
> @@ -2012,10 +2013,8 @@
> lf.l_len = 0;
> lf.l_type = F_UNLCK;
> vp = fp->f_data;
> - FILE_UNLOCK(fp);
> (void) VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &lf, F_FLOCK);
> - } else
> - FILE_UNLOCK(fp);
> + }
> if (fp->f_ops != &badfileops)
> error = fo_close(fp, td);
> else
>
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fdrop_locked() and FILE_LOCK() vs. Giant
On Tue, 17 Jun 2003, Don Lewis wrote: > The FILE_LOCK() implementation uses "pool mutex" under the hood, which > means it should only be used as a leaf level mutex. The fdrop_locked() > code wants to be called with FILE_LOCK() held, but the fdrop_locked() > implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK(). In > addition to violating the proper usage of the "pool mutex", there is > also the potential for a lock order violation. The close() > implementation grabs Giant and eventually calls fdrop(), which calls > FILE_LOCK() immediately before calling fdrop_locked(). If another > caller of fdrop_locked() calls FILE_LOCK() without grabbing Giant first, > then the lock order will be reversed when fdrop_locked() grabs Giant. > > It looks like fdrop_locked() should require that Giant be grabbed by the > caller before fdrop_locked() is called. I've also noticed that the file descriptor lock is held over per-object calls to fo_poll(), which currently isn't a big deal for most objects, but may be in the future if we have to grab other locks in order to test the poll status inside the object. I run into this problem with the MAC work because the vnode label is protected by the vnode lock, which is a sleepable lock. We may want to change label locking in the future to avoid this, but in the mean time I get a lot of witness warnings, and using a pool mutex for the fd lock may cause lock order problems if there is more complex locking. 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: ULE nice bugs are fixed.
On Tue, 17 Jun 2003, Wiktor Niesiobedzki wrote: > On Tue, Jun 17, 2003 at 02:53:36AM -0400, Jeff Roberson wrote: > > > > > > The sources are from today. I also noticed, that 5.1-BETA (build around 9th of > > > May) is working correctly. > > > > > > Also: I've noticed a strange behaviour - if I do nice -n -15 some_prog, it > > > will get a nice of -10, and similiar with any other nice values (it +5 from > > > what it suposed to be). > > > > > > > I shouldn't have spoke so soon. I am not able to reproduce this. Is it > > on SMP or UP? Are you using either libthr or libkse? If you're not sure > > what I'm talking about, you're using neither of them. > Machine is UP (Athlon XP 1600). Currently, I use libc_r. > > > > > Is there anything unusual about your environment? What are you using to > > read the nice values? > My simple test, is to do following: > boot into single mode > nice -n -15 sleep 300 & > I use ps -l to get nice level. > > renice -n -20 [pid of the sleep process] cause the panic. > > Previously I was using CPUTYPE=athlon-xp to build the kernel, but after > switching to i686 the panic persists. > > I'm attaching the full backtrace and result of call kseq_print(0). > I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Xft-2.1.2 fails to build under 5.1 release
On 17 Jun 2003 12:31:58 -0700, Eli K. Breen <[EMAIL PROTECTED]> wrote: Xft-2.1.2 fails to build under 5.1 release - Any hints or should I try and get a hold of the Xft port maintainer? I installed Xft/XFree86-4 on the very fresh 5.1-CURRENT (/usr/local/ and /usr/X11R6/ were empty) and they built success this morning. Are you sure, you have everything update such as freetype, XFree86 and etc? If no, then use the portupgrade. P.S. It's wrong list, which should be -ports and -gnome (this is maintainer) list, so I am cc'ing to -gnome list. Cheers, Mezz cd /usr/ports/x11-fonts/Xft && make ...results in... [...] cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include -O -pipe -mcpu=pentiumpro -MT xftdpy.lo -MD -MP -MF .deps/xftdpy.Tpo -c xftdpy.c -fPIC -o .libs/xftdpy.o xftdpy.c: In function `XftDefaultSubstitute': xftdpy.c:484: `FC_RGBA_UNKNOWN' undeclared (first use in this function) xftdpy.c:484: (Each undeclared identifier is reported only once xftdpy.c:484: for each function it appears in.) gmake[1]: *** [xftdpy.lo] Error 1 gmake[1]: Leaving directory `/usr/ports/x11-fonts/Xft/work/xft-2.1.2' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/x11-fonts/Xft. -EKB- -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Xft-2.1.2 fails to build under 5.1 release
On Tue, 2003-06-17 at 15:31, Eli K. Breen wrote: > Xft-2.1.2 fails to build under 5.1 release - Any hints or should I try and get a > hold of the Xft port maintainer? You need XFree86-4.3.0 to build Xft-2.1.2. If you don't want to upgrade X, then don't upgrade Xft. The older version should get you by. Joe > > > > cd /usr/ports/x11-fonts/Xft && make > > ...results in... > > [...] > cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include > -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include > -I/usr/X11R6/include -O -pipe -mcpu=pentiumpro -MT xftdpy.lo -MD -MP -MF > .deps/xftdpy.Tpo -c xftdpy.c -fPIC -o .libs/xftdpy.o > xftdpy.c: In function `XftDefaultSubstitute': > xftdpy.c:484: `FC_RGBA_UNKNOWN' undeclared (first use in this function) > xftdpy.c:484: (Each undeclared identifier is reported only once > xftdpy.c:484: for each function it appears in.) > gmake[1]: *** [xftdpy.lo] Error 1 > gmake[1]: Leaving directory `/usr/ports/x11-fonts/Xft/work/xft-2.1.2' > gmake: *** [all] Error 2 > *** Error code 2 > > Stop in /usr/ports/x11-fonts/Xft. > > -EKB- > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Xft-2.1.2 fails to build under 5.1 release
Xft-2.1.2 fails to build under 5.1 release - Any hints or should I try and get a hold of the Xft port maintainer? cd /usr/ports/x11-fonts/Xft && make ...results in... [...] cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include -O -pipe -mcpu=pentiumpro -MT xftdpy.lo -MD -MP -MF .deps/xftdpy.Tpo -c xftdpy.c -fPIC -o .libs/xftdpy.o xftdpy.c: In function `XftDefaultSubstitute': xftdpy.c:484: `FC_RGBA_UNKNOWN' undeclared (first use in this function) xftdpy.c:484: (Each undeclared identifier is reported only once xftdpy.c:484: for each function it appears in.) gmake[1]: *** [xftdpy.lo] Error 1 gmake[1]: Leaving directory `/usr/ports/x11-fonts/Xft/work/xft-2.1.2' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/x11-fonts/Xft. -EKB- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Broken make release
Make release using sources from yesterday (June 16) seems to be broken. These two commands are failing: umount: unmount of /mnt failed: Device busy umount: unmount of /dev failed: Device busy I'll include a bigger snippet of the output below. My src/release/Makefile is standard except for these additions: > BUILDNAME=5.1-20030616-SNAP > CHROOTDIR=/a/release > CVSROOT= /home/ncvs > MAKE_ISOS=YES > NODOC=YES > NOPORTS= YES I built a release on May 7 without any problems. Here's a bigger piece of the log: [...] Copying nfsclient.ko to /R/stage/driversfd Copying ips.ko to /R/stage/driversfd Copying plip.ko to /R/stage/driversfd Copying if_tx.ko to /R/stage/driversfd Copying if_an.ko to /R/stage/driversfd rmdir: /R/stage/driversfd: Directory not empty *** Error code 1 (ignored) *** Error code 1 (ignored) if [ -d /R/stage/driversfd ]; then sh -e /usr/src/release/scripts/doFS.sh bsdlabel "" /R/stage/floppies/drivers.flp /R/stage /mnt 1440 /R/stage/driversfd 4 fd1440; cd /R/stage/driversfd && awk -f /usr/src/release/scripts/driver-desc.awk *.dsc > > /R/stage/floppies/DRIVERS.TXT; fi + export BLOCKSIZE=512 + DISKLABEL=bsdlabel + shift + MACHINE= + shift + FSIMG=/R/stage/floppies/drivers.flp + shift + RD=/R/stage + shift + MNT=/mnt + shift + FSSIZE=1440 + shift + FSPROTO=/R/stage/driversfd + shift + FSINODE=4 + shift + FSLABEL=fd1440 + shift + [ -f /R/stage/trees/base/boot/boot ] + BOOT=-B -b /R/stage/trees/base/boot/boot + deadlock=20 + uname -r + dofs_md + true + rm -f /R/stage/floppies/drivers.flp + [ x != x ] + dd of=/R/stage/floppies/drivers.flp if=/dev/zero count=1440 bs=1k + mdconfig -a -t vnode -f /R/stage/floppies/drivers.flp + MDDEVICE=md0 + [ ! -c /dev/md0 ] + trap umount /mnt; mdconfig -d -u md0 EXIT + bsdlabel -w -B -b /R/stage/trees/base/boot/boot md0 fd1440 + newfs -O1 -i 4 -o space -m 0 /dev/md0c fstab: /etc/fstab:0: No such file or directory /dev/md0c: 1.4MB (2880 sectors) block size 4096, fragment size 512 using 2 cylinder groups of 1.22MB, 312 blks, 32 inodes. super-block backups (for fsck -b #) at: 32, 2528 + mount /dev/md0c /mnt + [ -d /R/stage/driversfd ] + set -e + cd /R/stage/driversfd + find . -print + cpio -dump /mnt 2550 blocks + df -ki /mnt Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/md0c 1391 13365596% 59 3 95% /mnt + df -ki /mnt + tail -1 + set /dev/md0c 1391 1336 55 96% 59 3 95% /mnt + echo *** Filesystem is 1440 K, 55 left *** Filesystem is 1440 K, 55 left + echo *** 4 bytes/inode, 3 left *** 4 bytes/inode, 3 left + break + umount /mnt + mdconfig -d -u md0 sh -e /usr/src/release/scripts/doFS.sh bsdlabel "" mfsroot /R/stage /mnt 4320 /R/stage/mfsfd 8000 minimum3 + export BLOCKSIZE=512 + DISKLABEL=bsdlabel + shift + MACHINE= + shift + FSIMG=mfsroot + shift + RD=/R/stage + shift + MNT=/mnt + shift + FSSIZE=4320 + shift + FSPROTO=/R/stage/mfsfd + shift + FSINODE=8000 + shift + FSLABEL=minimum3 + shift + [ -f /R/stage/trees/base/boot/boot ] + BOOT=-B -b /R/stage/trees/base/boot/boot + deadlock=20 + uname -r + dofs_md + true + rm -f mfsroot + [ x != x ] + dd of=mfsroot if=/dev/zero count=4320 bs=1k + mdconfig -a -t vnode -f mfsroot + MDDEVICE=md0 + [ ! -c /dev/md0 ] + trap umount /mnt; mdconfig -d -u md0 EXIT + bsdlabel -w -B -b /R/stage/trees/base/boot/boot md0 minimum3 + newfs -O1 -i 8000 -o space -m 0 /dev/md0c fstab: /etc/fstab:0: No such file or directory /dev/md0c: 4.2MB (8640 sectors) block size 4096, fragment size 512 using 4 cylinder groups of 1.06MB, 271 blks, 160 inodes. super-block backups (for fsck -b #) at: 32, 2200, 4368, 6536 + mount /dev/md0c /mnt + [ -d /R/stage/mfsfd ] + set -e + cd /R/stage/mfsfd + find . -print + cpio -dump /mnt 6080 blocks + df -ki /mnt Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/md0c 4175 3100 107574% 95 543 15% /mnt + df -ki /mnt + tail -1 + set /dev/md0c 4175 3100 1075 74% 95 543 15% /mnt + echo *** Filesystem is 4320 K, 1075 left *** Filesystem is 4320 K, 1075 left + echo *** 8000 bytes/inode, 543 left *** 8000 bytes/inode, 543 left + break + umount /mnt umount: unmount of /mnt failed: Device busy *** Error code 1 Stop in /usr/src/release. + umount /dev umount: unmount of /dev failed: Device busy + true *** Error code 1 Stop in /a/src/release. John -- John Polstra John D. Polstra & Co., Inc.Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Giant pushdown in kern_descrip.c rev 1.128
* Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
> It's not legal to attempt to aquire Giant in fdrop_locked(), while
> FILE_LOCK() is held. The problem is that FILE_LOCK uses the mutex pool,
> which should only be used for leaf mutexes.
>
> It also looks like there is a potential for a lock order reversal if
> some callers aquire Giant before FILE_LOCK() and fdrop_locked() does the
> opposite.
>
> It also appears that witness ignores the mutex pool ...
Yes, but I think the fix is as simple as just dropping the FILE_LOCK
after the decrement as we're the last holders of it, can you try
this:
Index: kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.199
diff -u -r1.199 kern_descrip.c
--- kern_descrip.c 11 Jun 2003 00:56:55 - 1.199
+++ kern_descrip.c 17 Jun 2003 19:07:01 -
@@ -2003,6 +2003,7 @@
FILE_UNLOCK(fp);
return (0);
}
+ FILE_UNLOCK(fp);
mtx_lock(&Giant);
if (fp->f_count < 0)
panic("fdrop: count < 0");
@@ -2012,10 +2013,8 @@
lf.l_len = 0;
lf.l_type = F_UNLCK;
vp = fp->f_data;
- FILE_UNLOCK(fp);
(void) VOP_ADVLOCK(vp, (caddr_t)fp, F_UNLCK, &lf, F_FLOCK);
- } else
- FILE_UNLOCK(fp);
+ }
if (fp->f_ops != &badfileops)
error = fo_close(fp, td);
else
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Gdk-Warning
On Tue, 2003-06-17 at 14:48, Blaise Takoudjou wrote: > Hello, > how can i resolv this warning ? > Gdk-WARNING **: Missing charsets in FontSet creation > > i have starting and reciving message with "gaim" This really isn't appropriate to the current@ mailing list. However, this might be fixed by updating the latest libiconv. Without further details like gaim version, locale, GTK+ version, etc. I cannot offer any other advice. Joe > thanks ! > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Linksys Wireless USB adapter
On Tue, Jun 17, 2003 at 02:42:30PM +, administrator wrote: > Anyone know if Linksys wireless usb adapter works under Freebsd 5.1? I see > a msg saying it recognizes the adapter but it uses ugen0, how do you get > an ip or have it work? USB wireless adaptors are not supported. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Gdk-Warning
Hello, how can i resolv this warning ? Gdk-WARNING **: Missing charsets in FontSet creation i have starting and reciving message with "gaim" thanks ! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout with 5.1BETA2
Hi, On Fri, Jun 13, 2003 at 10:37:26AM +0200, Markus Wennrich wrote: > UPDATE: If I make an SMP-kernel this issue is completely solved for me. > Everythings works as before, both fxp's share the same irq (together > with uhci), both are working, with sio, usb, etc ... like as before the > evil cvsup :-) Did you investigate it a little more? I updated -current today and fxp0 is at the moment unusable. But anyway I will try to build the kernel with SMP. -Kirill pgp0.pgp Description: PGP signature
Linksys Wireless USB adapter
Anyone know if Linksys wireless usb adapter works under Freebsd 5.1? I see a msg saying it recognizes the adapter but it uses ugen0, how do you get an ip or have it work? Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI testing/debugging guide?
Is there some list of actions to preform and data to collect that would assist with getting the ACPI stuff lined out? I've read the acpiconf man page but don't know that it gives me any way to test for any specific functionality. I've been gradually piecing together the meaning of S1, S2, S3, S4, and S5 and figuring out that the *_(button|switch)_state sysctl oids specify which state to go to on activation of that button rather than being a descriptor of the current state of the buttons. I haven't figured out if the hw.acpi.thermal oids. I think maybe ACPI doesn't recognize the hardware. Is a thermal oid value of 3692 actually 36.92 celcius or some scale from 0x to 0x? Is battery.time supposed to be -1 when on AC? My resume from suspend doesn't work and I don't know how to tell where that is going wrong. I have no serial interface so I can't use a serial console when the LCD doesn't come on. I can live without suspend/resume functionality. You can't miss something you have never had. :-) I would like to be able to tell the fan to stay on anytime it has AC power since it is gradually cooking my lap. How can I help others improve the ACPI support without investing hours I don't have in learning enough reading the source to be useful finding and reporting problems? -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
On Tue, Jun 17, 2003 at 01:16:49PM -0500, Dan Nelson wrote: > > > My resume from suspend doesn't work and I don't know how to tell where > > that is going wrong. I have no serial interface so I can't use a serial > > console when the LCD doesn't come on. I can live without suspend/resume > > functionality. You can't miss something you have never had. :-) > > My Dell laptop doesn't bring the display back on, but I can manually > re-enable it with the Fn-CRT/LCD key. Have you tried waiting? I thought the same on my I5000, but discovered that if I waited 30-60 seconds, the display did come back by itself. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI testing/debugging guide?
In the last episode (Jun 17), Scott Lambert said: > Is there some list of actions to preform and data to collect that > would assist with getting the ACPI stuff lined out? > > I've read the acpiconf man page but don't know that it gives me any > way to test for any specific functionality. I've been gradually > piecing together the meaning of S1, S2, S3, S4, and S5 and figuring > out that the *_(button|switch)_state sysctl oids specify which state > to go to on activation of that button rather than being a descriptor > of the current state of the buttons. > > I haven't figured out if the hw.acpi.thermal oids. I think maybe > ACPI doesn't recognize the hardware. Is a thermal oid value of 3692 > actually 36.92 celcius or some scale from 0x to 0x? ACPI records temperature in tenths of a Kelvin, if you can believe it :) > Is battery.time supposed to be -1 when on AC? That may depend on the laptop. Some estimate the time by extrapolating from the battery drain rate, and if it's not draining, it can't guess. > My resume from suspend doesn't work and I don't know how to tell where > that is going wrong. I have no serial interface so I can't use a serial > console when the LCD doesn't come on. I can live without suspend/resume > functionality. You can't miss something you have never had. :-) My Dell laptop doesn't bring the display back on, but I can manually re-enable it with the Fn-CRT/LCD key. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with pcmcia on 5.1-RELEASE
"M. Warner Losh" <[EMAIL PROTECTED]> writes: > In message: <[EMAIL PROTECTED]> > Christian Laursen <[EMAIL PROTECTED]> writes: > : pccard0: (manufacturer=0x, product=0x) at function 0 > : pccard0:CIS info: FREECOM, PCCARD-IDE, REV836 > > Looks like we need another entry in ata-card.c for this device. > > I've added this to the kernel list. Please recvsup and make sure you > have sys/dev/pccard/pccarddevs 1.53, pccarddevs.h 1.53 and > sys/dev/ata/ata-card.c 1.14. Thank you very much. Unfortunately, like the patch Matthew N. Dodd posted, this gives me an extra ata channel, but no devices are found on it. I have tried various commands to atacontrol, but nothing seems to help. I'm not sure how to help debug this further. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI problems on 5.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On a Compaq Armada V300 notebook, if I load the acpi module, boot fails after the kernel prints about half a dozen "acpi_bus_number: can't get _ADR", fails to detect any of the hardware and panics because of failure to mount root. With the acpi module disabled, the machine is able to boot up. This same machine used to be able to run 5.0-CURRENT with ACPI enabled and I think the ACPICA merge at around May 2003 could be responsible. Should I try to get a old copy of the acpica parts or does 5.1 depend on new stuff in it? I am thinking of getting src/sys/dev/acpica and src/sys/contrib/dev/acpica from around 1 April 2003 - -- Antony T Curtis BSc Unix Analyst Programmer http://homepage.ntlworld.com/antony.t.curtis/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+7zIGql7dp2cddmIRAkXzAKDJqDoXikYCVPmUxaTaM3IVi43KBACgqNie uzODS8XCBODHy8ZRwOVnIDg= =y3on -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LG 5350 cell phone
Are you volunteering? ;-) Honestly, I'm not entirely sure. I did try to add entry but it is certainly possible I botched it somehow (due to unfamiliarity). The behavior I saw suggested to me that usbdevs was assigning a generic driver to the phone. As long as I didn't also have the umodem module loaded up it seemed fine -- other than being unavailable as a modem of course. When I loaded it up it looked as though the modem was trying to claim the device and usbdevs was "taking" it back somehow... or umodem was segfaulting when trying to allocate the driver. (Again, I claim ignorance here) The result was a generic allocation followed by a failed umodem allocation followed by a reset of the phone -- then all over again. This continued until unplugging the phone or unloading the umodem module. If someone could enlighten me on this I could certainly work on it a bit more. At the very least I could try things for someone else and maybe help fine tune it. I currently have 4.7, 4.8, and -Current (dated April 12 of this year) loaded on my laptop. I could upgrade the -Current install this weekend if that is where we want to work on this. Sean ---Original Message--- From: David Yeske <[EMAIL PROTECTED]> Sent: 06/17/03 02:52 AM To: Josef Karthauser <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: LG 5350 cell phone > > Should this get a new vendor entry in usbdevs? --- Josef Karthauser <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2003 at 01:05:00PM -0500, Sean Welch wrote: > > I have this phone myself. I have two adapters for it -- one is > > a serial cable the other a "true" (as in no serial to usb > > conversion box in the middle) usb cable. > > > > The phone works great under FreeBSD on the serial cable (normal > > Hayes modem type at commands work fine), but no version of > > FreeBSD has worked with the usb cable so far. I tried 4.8, > > 5.0-RELEASE, and a few versions of 5.x-CURRENT. The phone is > > quite usable from my iBook so the cable isn't the issue (the > > iBook reports it as a Qualcomm -- which is what the sticker > > says too). I see the message you do, but when I try to use > > umodem with it the phone continuously "reboots" itself until > > detached. > > > > I tried something along the lines of what you did to usbdevs > > a while back but didn't get any improvement. > > > > The connection is appreciably faster over the usb port with > > the "true" cable when compared to the serial cable; it would > > be very nice to use it this way on FreeBSD... > > > >Sean > > Maybe the phone doesn't identify itself as a usb modem class, instead > relying on a vendor driver. > > An easy project for someone would be to write a general usb querying > tool for displaying the classes, etc that a usb device supports. > I've got code kicking around, mostly from Nick Hibma, but I never got > around to finishing it off. > > Joe > -- > Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ > FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ > Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ > An eclectic mix of fact and theory. = __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple cardbus devices? (RFI)
Does the following, untested, patch help any better than your gross kludges? It forces 12 bit aligment of the allocations for CardBus devices as well as for 'R2' 16-bit devices (which were already forced). One might be able to share the 4k range between devices if one had, say, two xl cards (I'd have to look hard at the code to be sure), but very few machines are so memory constrained as to make that a big win for the hair it would add to the code. Warner Index: pccbb.c === RCS file: /home/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.78 diff -u -r1.78 pccbb.c --- pccbb.c 12 Jun 2003 06:06:14 - 1.78 +++ pccbb.c 17 Jun 2003 13:18:30 - @@ -1543,6 +1550,9 @@ start = cbb_start_mem; if (end < start) end = start; + if (RF_ALIGNMENT(flags) < CBB_MEMALIGN_BITS) + flags = (flags & ~RF_ALIGNMENT_MASK) | + rman_make_alignment_flags(CBB_MEMALIGN); break; } Index: pccbbreg.h === RCS file: /home/ncvs/src/sys/dev/pccbb/pccbbreg.h,v retrieving revision 1.12 diff -u -r1.12 pccbbreg.h --- pccbbreg.h 23 Nov 2002 23:09:45 - 1.12 +++ pccbbreg.h 17 Jun 2003 13:18:31 - @@ -75,7 +75,9 @@ #defineCBBR_IOBASE10x34/* len=4 */ #defineCBBR_IOLIMIT1 0x38/* len=4 */ #defineCBB_MEMALIGN4096 +#define CBB_MEMALIGN_BITS 12 #defineCBB_IOALIGN 4 +#define CBB_IOALIGN_BITS 2 #defineCBBR_INTRLINE 0x3c/* len=1 */ #defineCBBR_INTRPIN0x3d/* len=1 */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple cardbus devices? (RFI)
: I've tried an awful hack of forcing a minimum size of 0x1000 for all : resource allocations made by cardbus devices to make sure they're : page-aligned and it seems to be working. There are occasional : watchdog timeouts on the xl device, but it is at least functioning at : the same time as the USB. Reading the spec tells me that all memory allocation needs to be on a 4k boundary. Looks like the code fails to enforce that. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Need acpi-event-d?
In message: <[EMAIL PROTECTED]> "Simon L. Nielsen" <[EMAIL PROTECTED]> writes: : On 2003.06.16 07:07:36 -0400, David Gilbert wrote: : > First, I must say that it's cool that ACPI code can be examined and : > rewritten. In my laptop's case, this was key to make things fairly : > happy. : > : > Anyways, after a resume, it would appear I need to kill and restart : > moused. Under 4.x, apmd was used for this purpose ... but this new : > laptop doesn't support apm at all. /dev/apm seemed to be emulated by : > acpi for the benifit of battery monitors, but apmd won't run. : > : > Is there a facility to run things on resume, or is this reset : > something better done inside the kernel? : : I think devd(8) should be used for this, but I havn't tried. devd does not (currently) get events for suspend/resume. Maybe it should. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem on installing BSD 5.x on laptop ...
In message: <[EMAIL PROTECTED]> Damien Touraine <[EMAIL PROTECTED]> writes: : How could I get my 3CCFEM556BI work during the install process of FreeBSD ? I don't think that you can. I've not been able to get that card working locally on a non-install kernel (well, a similar card). There's some code in the NetBSD kernel that's fussy about the I/O range it will accept due to what comments claim are bugs in the silicon, but I've not had time to pursue the matter. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with pcmcia on 5.1-RELEASE
In message: <[EMAIL PROTECTED]> Christian Laursen <[EMAIL PROTECTED]> writes: : pccard0: (manufacturer=0x, product=0x) at function 0 : pccard0:CIS info: FREECOM, PCCARD-IDE, REV836 Looks like we need another entry in ata-card.c for this device. I've added this to the kernel list. Please recvsup and make sure you have sys/dev/pccard/pccarddevs 1.53, pccarddevs.h 1.53 and sys/dev/ata/ata-card.c 1.14. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Patch review
There's no need to add an extra parameter. I like Matt Dodd's proposed patch better. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with wi in CURRENT (and 5.1)
Hello. On Tue, Jun 17, 2003 at 11:48:13AM +0100, Robert Hulme wrote: > I'm having some problems with wi in 5-CURRENT and 5.1 in general. The problem came up between June 7 and June 15 in -CURRENT. > I'm using a Proxim Skyline 802.11b PC Card (which I believe uses the > Prism 2 chipset). The PC Card is using the 0.3.0 primary and 0.8.3 > secondary firmware (which I believe is the latest). I have a Dell > Inspiron 8200. I have an Orinoco Gold Card. HP Omnibook 500. ACPI disabled (the notebook has APM, with ACPI I don't see battery capacity). I tried with and without WEP. The network works fine for some time, then blocks for a while and starts working again. > wi0: timeout in wi_cmd 0x0002; event status 0x8000 > wi0: wi_cmd: busy bit won't clear. Looks similar at my Notebook: wi0: at port 0x100-0x13f irq 10 function 0 config 1 on pccard0 wi0: 802.11 address: 00:02:2d:51:a2:35 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.10.1) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wi0: bad alloc 21e != 207, cur 0 nxt 0 wi0: bad alloc 24b != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 26a != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 283 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 29a != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 2b1 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 2c8 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 2df != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 2f6 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 30d != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 324 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 33b != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 352 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 369 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 380 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 397 != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 3ae != 234, cur 0 nxt 0 wi0: device timeout wi0: bad alloc 3c5 != 234, cur 0 nxt 0 wi0: device timeout [and further] complete dmesg, debugging output and stuff will be sent on request. I was silently hoping that others have this problem too and somebody cares, because I do not have any time to do anything at the moment. But at least I offer my help in giving hints. Thanx, Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE nice bugs are fixed.
On Tue, Jun 17, 2003 at 02:53:36AM -0400, Jeff Roberson wrote:
> > I'm seeing quite similar panic, when I do renice to lower (negative) value:
> > ("Negative nice count.")
> >
> > (kgdb) bt
> > #0 doadump () at ../../../kern/kern_shutdown.c:240
> > #1 0xc018b374 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
> > #2 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
> > #3 0xc01926a3 in mi_switch () at ../../../kern/kern_synch.c:481
> > #4 0xc018b022 in boot (howto=256) at ../../../kern/kern_shutdown.c:312
> > #5 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
> > #6 0xc019dbe8 in kseq_nice_rem (kseq=0xc0312be0, nice=-10) at
> > ../../../kern/sched_ule.c:324
> > #7 0xc019e2b5 in sched_nice (kg=0xfff6, nice=-20) at
> > ../../../kern/sched_ule.c:809
> > #8 0xc0188eac in donice (td=0xc25fc850, p=0xc26c0790, n=-20) at
> > ../../../kern/kern_resource.c:296
> > #9 0xc0188b43 in setpriority (td=0xc25fc850, uap=0xcdd65d14) at
> > ../../../kern/kern_resource.c:205
> > #10 0xc0298b11 in syscall (frame=
> > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 87, tf_esi = -10, tf_ebp =
> > -1077937064, tf_isp = -841589388, tf_ebx = -20, tf_edx = 0, tf_ecx = -1077937080,
> > tf_eax = 96, tf_trapno = 12, tf_err = 2, tf_eip = 671874691, tf_cs = 31, tf_eflags
> > = 659, tf_esp = -1077937108, tf_ss = 47}) at ../../../i386/i386/trap.c:1023
> > #11 0xc0288d9d in Xint0x80_syscall () at {standard input}:138
> > ---Can't read userspace from dump, or kernel process---
> >
> > The sources are from today. I also noticed, that 5.1-BETA (build around 9th of
> > May) is working correctly.
> >
> > Also: I've noticed a strange behaviour - if I do nice -n -15 some_prog, it
> > will get a nice of -10, and similiar with any other nice values (it +5 from
> > what it suposed to be).
> >
>
> I shouldn't have spoke so soon. I am not able to reproduce this. Is it
> on SMP or UP? Are you using either libthr or libkse? If you're not sure
> what I'm talking about, you're using neither of them.
Machine is UP (Athlon XP 1600). Currently, I use libc_r.
>
> Is there anything unusual about your environment? What are you using to
> read the nice values?
My simple test, is to do following:
boot into single mode
nice -n -15 sleep 300 &
I use ps -l to get nice level.
renice -n -20 [pid of the sleep process] cause the panic.
Previously I was using CPUTYPE=athlon-xp to build the kernel, but after
switching to i686 the panic persists.
I'm attaching the full backtrace and result of call kseq_print(0).
Cheers,
Wiktor Niesiobedzki
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: -E flag in /etc/rc.d/ipfilter causes warnings
> I believe it's harmless, and while not aesthetically pleasing, it's a necessary
> work-around. The stop command to rc.d/ipfilter uses -D to disable ipfilter, so
> it's necessary to use -E with the start command because there's no way to know
> how/when/why/in-what-environment it's being called. If I'm wrong or you have a
> better alternative to this please let me know.
Yes, you understood the manpage right and no, I don't think there's a
better way to detect that. This is something I've thought about and
couldn't come up with a better solution, either. But there's another
"issue" about /etc/rc.d/ipfilter that has a work-around: IPv6 support.
The current script just fires ipf and then ipf -6, whether you have
IPv6 support or not.
I don't know the purpose of this, since grepping /etc/rc* and
/etc/rc.d/* for it doesn't return anything, but there's this line in
/etc/defaults/rc.conf:
ipv6_enable="NO"# Set to YES to set up for IPv6.
So, assuming there *is* a reason for that variable, I changed my
/etc/rc.d/ipfilter a bit so it respects that (although only in
ipfilter_start()):
case ${OSTYPE} in
FreeBSD)
${ipfilter_program:-/sbin/ipf} -Fa
if [ -r "${ipfilter_rules}" ]; then
${ipfilter_program:-/sbin/ipf} \
-f "${ipfilter_rules}" ${ipfilter_flags}
fi
case ${ipv6_enable} in
[Yy][Ee][Ss])
${ipfilter_program:-/sbin/ipf} -6 -Fa
if [ -r "${ipv6_ipfilter_rules}" ]; then
${ipfilter_program:-/sbin/ipf} -6 \
-f "${ipv6_ipfilter_rules}" ${ipfilter_flags}
fi
;;
esac
;;
Should that be the default, or am I missing anything here?
Fred
--
"They're only trying to make me LOOK paranoid!"
pgp0.pgp
Description: PGP signature
Problem with wi in CURRENT (and 5.1)
Hi, I'm having some problems with wi in 5-CURRENT and 5.1 in general. I'm using a Proxim Skyline 802.11b PC Card (which I believe uses the Prism 2 chipset). The PC Card is using the 0.3.0 primary and 0.8.3 secondary firmware (which I believe is the latest). I have a Dell Inspiron 8200. The card works fine in Windows XP and FreeBSD 5.0, but in 5.1 if I use ifconfig to bring up the card (for example during boot) it locks my laptop up for about a minute while I get loads of error messages appear on screen. Eventually I get a 'init failed' and 'tx buffer allocation failed (error 12)' error, and although ifconfig says the interface is up it doesn't actually work. I'm using 128bit wep in case that's relevant. I would really appreciate some help as I've spent hours (like about 20) now sitting here recompiling the kernel, updating to the current branch and trying that, etc... Please help! My boot.dmesg is as follows: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #3: Tue Jun 17 11:08:39 BST 2003 root@:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc06f3000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc06f30a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1695004748 Hz CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 1.70GHz (1695.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebf9ff real memory = 536748032 (511 MB) avail memory = 513839104 (490 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fbb90 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci_cfgintr: 0:29 INTA BIOS irq 11 pci_cfgintr: 0:29 INTC BIOS irq 11 pci_cfgintr: 0:31 INTB BIOS irq 11 pci_cfgintr: 0:31 INTB BIOS irq 11 agp0: mem 0xe800-0xebff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci_cfgintr: 1:0 INTA BIOS irq 11 pci1: at device 0.0 (no driver attached) uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft Wheel Mouse Optical\M-., rev 1.10/1.21, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 pci_cfgintr: 2:0 INTA BIOS irq 11 pci_cfgintr: 2:1 INTA BIOS irq 11 pci_cfgintr: 2:1 INTA BIOS irq 11 pci_cfgintr: 2:1 INTA BIOS irq 11 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec80-0xecff mem 0xf8fffc00-0xf8fffc7f irq 11 at device 0.0 on pci2 xl0: Ethernet address: 00:08:74:e5:b9:b3 miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cbb0: irq 11 at device 1.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 11 at device 1.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fwohci0: mem 0xf8ff8000-0xf8ffbfff,0xf8fff000-0xf8fff7ff irq 11 at device 1.2 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 32:4f:c0:00:3a:98:48:10 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 if_fwe0: on firewire0 if_fwe0: Fake Ethernet address: 32:4f:c0:98:48:10 sbp0: on firewire0 fwohci0: Initiate bus reset isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xbfa0-0xbfaf,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.5 (no driver attached) pci0: at device 31.6 (no driver attached) orm0: at iomem 0xcf800-0xc,0xc-0xcf7ff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't
fdrop_locked() and FILE_LOCK() vs. Giant
The FILE_LOCK() implementation uses "pool mutex" under the hood, which means it should only be used as a leaf level mutex. The fdrop_locked() code wants to be called with FILE_LOCK() held, but the fdrop_locked() implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK(). In addition to violating the proper usage of the "pool mutex", there is also the potential for a lock order violation. The close() implementation grabs Giant and eventually calls fdrop(), which calls FILE_LOCK() immediately before calling fdrop_locked(). If another caller of fdrop_locked() calls FILE_LOCK() without grabbing Giant first, then the lock order will be reversed when fdrop_locked() grabs Giant. It looks like fdrop_locked() should require that Giant be grabbed by the caller before fdrop_locked() is called. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems tuning kmem_map on 5.1-REL box.
Hi - If this sort of question is better asked on a more specialized list @freebsd.org, please let me know. (Since 5.1 is still considered a developmental release, one doesn't know if either -current or -stable would be more appropriate. So I am sending it to -current. So, I recently put a Quad-Xeon server (w/ 4GB of RAM) into production as primarily as a master FTP server for ISC as well as for FreeBSD (US/IPv6 side of ftp.freebsd.org). All has been going well for the past couple of weeks until 5.1 was released. Traffic spiked, and the server started panicking every 12 hours: > panic: kmem_malloc(4096): kmem_map too small: 377487360 total allocated So after looking at the archives, I read that FreeBSD had issues with installed memory above 2GB, so I set the sysctl kern.maxvnodes=13, but to no effect: > panic: kmem_malloc(16384): kmem_map too small: 293519360 total allocated I have since removed my NMBCLUSTER setting in the kernel, so it would be set automatically, I have even set VM_KMEM_SIZE_SCALE="2" (I haven't messed with the other KMEM kernel options, as I was hoping to avoid it) And a couple of hours ago I updated the kernel with the latest kern_malloc.c file in the RELENG_5_1 branch. Are there any other options I should be pursuing in resolving this issue? (5.1 has been running almost flawlessly on our other SMP systems for over a week now, but then again, this system gets by far more load and traffic than all of them combined.) Thanks in advance for any tips you can provide. Best Wishes - Peter -- [EMAIL PROTECTED] | ISC | OpenPGP 0xE8048D08 | "The bits must flow" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
