Re: Fast forward bug and newpcm (again)
On Tue, 30 Nov 1999 02:30:41 -0500 (EST), Donn Miller [EMAIL PROTECTED] said: sbc driver does not probe ESS1868 at this moment. Donn Question: will the ESS 1868 bridge driver be incorporated into the sbc Donn driver, or should we devise a whole new bridge driver for the ess? I.e., Donn we would have: Donn device ess0 # ESS bridge driver I prefer ess0. ESS is the name of soundcards as well, so the name of the driver matches those of the cards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ESS1879, pnp_id patch and illegal probe about ESS1888
But kernel probed ESS1888 as pcm0 and ESS1879 as pcm1. I think this NOTE-PC only has ESS1879 sound chip and I only use pcm1. I don't want to probe ESS1888. How can I solve below problem? In retrospect, the es1888 probe code I added for alphas was a mistake. I will disable that code and work on a better solution for alphas. Thanks. ESS1879 can probe as pcm0 sound driver and don't probe ES1888(ess?) anymore in my NOTE-PC. But does someone add pnpid of my sound card to dev/sound/isa/sb.c. or do I need to send-pr this patch ? --- MIHIRA Sanpei Yoshiro Yokohama, Japan. --- dev/sound/isa/sb.c.org Sat Nov 27 23:29:44 1999 +++ dev/sound/isa/sb.c Sat Nov 27 23:29:57 1999 @@ -1277,6 +1277,10 @@ s = "ESS1869"; break; + case 0x79187316: /* ESS1879 */ + s = "ESS1879"; + break; + case 0x88187316: /* ESS1888 */ s = "ESS1888"; break; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More newpcm breakage
On Tue, Nov 30, 1999 at 10:30:28AM +0900, [EMAIL PROTECTED] wrote: On 29 Nov 1999 19:19:24 +0100, Dag-Erling Smorgrav [EMAIL PROTECTED] said: Dag-Erling My SB32 PnP, which had so far worked nicely with newpcm except for the Dag-Erling "fast forward" bug, stopped working after the newmidi import. This Dag-Erling means that none of my sound cards (except for the GUS PnP, which I Dag-Erling haven't tested) work any more, and I am seriously losing faith in the Dag-Erling authors' ability to maintain a device driver. Did you add sbc into your kernel configuration? Maybe I should add a warning in sb.c... I don't if DES did, but I did. Turns out from his dmesg that he has a very similar hardware config (which is why I don't include a copy of my dmesg) and I am seeing *exactly* the same problems - suddenly my AWE32 is not recognized any more. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ESS1879, pnp_id patch and illegal probe about ESS1888
On Tue, 30 Nov 1999, MIHIRA Sanpei Yoshiro wrote: But kernel probed ESS1888 as pcm0 and ESS1879 as pcm1. I think this NOTE-PC only has ESS1879 sound chip and I only use pcm1. I don't want to probe ESS1888. How can I solve below problem? In retrospect, the es1888 probe code I added for alphas was a mistake. I will disable that code and work on a better solution for alphas. Thanks. ESS1879 can probe as pcm0 sound driver and don't probe ES1888(ess?) anymore in my NOTE-PC. Good. But does someone add pnpid of my sound card to dev/sound/isa/sb.c. or do I need to send-pr this patch ? I just committed the patch, thanks. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sbc and pcm
On Tue, 30 Nov 1999 [EMAIL PROTECTED] wrote: On Tue, 23 Nov 1999 04:22:39 +0800, Peter Wemm [EMAIL PROTECTED] said: Mostly, sbc.c is handling PnP ID matching in a totally bogus manner. Peter Yes, it's quite bogus and is incompatible with motherboard devices. There Peter should be no vendor ID references in there at all, that's for card ID, not Peter device id. I am now working to tidy up the sbc probe. Would it be enough for the sound chips on motherboards to check the logical device ID of 0x??008c0e? How does the result of pnpinfo(1) for a motherboard chip look like? I think a lot of motherboard chips don't show up at all and are only detected using PNPBIOS. Unfortunately, there is no userland tool for querying pnpbios. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
On Mon, 29 Nov 1999, Matthew Dillon wrote: : : : makeoptions DEBUG="-g" : :Easier option.. :config -g Actually no. How many people remember to type options after 'config' ? Especially if you are juggling more then one kernel config, trying to remember which ones you intend to compile -g and which ones you don't generally results in forgetting to type -g half the time even on the ones you want it on. If it is in the kernel config, you don't have to remember anything, you simply 'config FILENAME' and you are done. For my development kernels, I normally just build everything for debugging. Its simpler that way. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More newpcm breakage
On Tue, 30 Nov 1999, Timo Geusch wrote: On Tue, Nov 30, 1999 at 10:30:28AM +0900, [EMAIL PROTECTED] wrote: On 29 Nov 1999 19:19:24 +0100, Dag-Erling Smorgrav [EMAIL PROTECTED] said: Dag-Erling My SB32 PnP, which had so far worked nicely with newpcm except for the Dag-Erling "fast forward" bug, stopped working after the newmidi import. This Dag-Erling means that none of my sound cards (except for the GUS PnP, which I Dag-Erling haven't tested) work any more, and I am seriously losing faith in the Dag-Erling authors' ability to maintain a device driver. Did you add sbc into your kernel configuration? Maybe I should add a warning in sb.c... I don't if DES did, but I did. Turns out from his dmesg that he has a very similar hardware config (which is why I don't include a copy of my dmesg) and I am seeing *exactly* the same problems - suddenly my AWE32 is not recognized any more. Sounds like a missing pnp id. What does the output from pnpinfo look like? -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report - Nov.
On Tue, 30 Nov 1999, Mitsuru IWASAKI wrote: 5. AML interpreter implementation We've just started based on Doug Rabson's acpitest program, but parsing AML and managing objects in the name space are almost finished. We're going to make configuration utility first with AML interpreter in the userland, then move it to kernel space after brush it out. Please see http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/util/acpiconf?cvsroot=freebsd-jp This sounds very promising. I will check out the code soon and try to give feedback. Creating the ACPI namespace is a necessary first step before its possible to do full AML interpreting. In the beginning of this project, we thought merging them to 4.0-RELEASE would be very much exciting, but it seems the codes are still young to merge and 4.0-RELEASE feature freeze is comming soon. We will try another chance, hopefully we have AML interpreter in kernel space at that time. I think we should aim to do most of the work in 5.0 after we branch off 4.0. Perhaps some of it can be back-ported after it become stable in 5.0. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
trigraph in IPV6?
../../netinet6/in6.c: warning: 1 trigraph(s) encountered haven't seen one of THOSE for a while To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel: -mpreferred-stack-boundary=2 ??
When did this come in? (I have been seeing it for a while but.. I thought this was to save space on the bootblocks, not the entire kernel?) Do we really want shorts being pushed onto the stack as shorts? (This is what this implies) Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Julian Elischer [EMAIL PROTECTED] writes: When did this come in? (I have been seeing it for a while but.. I thought this was to save space on the bootblocks, not the entire kernel?) Do we really want shorts being pushed onto the stack as shorts? (This is what this implies) No, the units are actually powers-of-two and that overrides the default of aligning for doubles (which would be useless in the kernel). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overflow in banner(1)
On Wed, 24 Nov 1999, David O'Brien wrote: On Wed, Nov 24, 1999 at 09:58:51AM +0200, John Hay wrote: Well the original line is plain wrong if Brian's patch is being used, because there message is a pointer and the size of a pointer is 4. Yes, yes, yes. Warner and I are *not* that stupid WRT C. We were both commenting on the *original* proposed patch. Geez. Now rather than try to call us stupid, Kris (and only Kris) could say, "well, I've decided to go with a dynamically allocated buffer, so of course I can't use sizeof() any more". Hey, hey, I'm also not stupid, but thanks for implying that :P If I had intended to commit what I whipped up quickly, I would be checking it pretty carefully. It seems I'm catching a lot of flak on not having "audited" what was basically a "proof of concept", showing the kind of thing I'd rather have. I like the precomputed one (add all argv[] strlen's and malloc that) better, anyway. -- -- David([EMAIL PROTECTED]) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Ville-Pertti Keinonen wrote: No, the units are actually powers-of-two and that overrides the default of aligning for doubles (which would be useless in the kernel). What about commercial and/or third party KLDs? They fail to work if they don't also set -preferred-stack-boundry=2, right? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Julian Elischer wrote: When did this come in? (I have been seeing it for a while but.. I thought this was to save space on the bootblocks, not the entire kernel?) Shortly after setting it for the bootblock. It breaks backward compatibility and bogusly applies to the tools (xxx_genassym) as well. As you can tell, I'm not quite happy with it... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trigraph in IPV6?
On Tue, 30 Nov 1999, Julian Elischer wrote:
../../netinet6/in6.c: warning: 1 trigraph(s) encountered
haven't seen one of THOSE for a while
A warning, or a proper trigraph?
{"/usr/src/sys/netinet6"}$ grep '??.' in6.c
* SIOCGLIFADDR: get first address. (???)
I think the way this has been fixed before is to change it to something
like (?!?) =)
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
What about commercial and/or third party KLDs? They fail to work if they don't also set -preferred-stack-boundry=2, right? Oops, I accidentally replied to this privately. Anyhow, I'll repeat it here - stack alignment does *not* break link-compatibility. It does not change calling conventions, it just adds padding after the args to ensure that local variables can be predictably aligned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crash under high exec() loads.. (vm_map_insert?)
:If you notice, both times it crashed on vm_map_insert. Try bumping up PMAP_SHPGPERPROC. From LINT: # # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". # # The value below is the one more than the default. # options PMAP_SHPGPERPROC=201 Try bumping it up to 1000 and see if that solves your crashes. If that doesn't work, and there's any chance of getting a kernel dump, try getting a kernel dump. Make sure you use a debug (compiled -g) kernel. While I can't say I truly see the correlation, you definitely know more about how it works then me. I've cvsupp'd and upped it to 1000. One question I have, is what exactly -are- pv's? The machine itself isn't under too much load during the testing, and definitely does not used a lot of shared memory. During one of the tests yesterday (c89) it was doing ~8000 execs per minute, with a load of 0.23. I've also got plenty of RAM left over. Here is what it currently looks like: last pid: 7121; load averages: 0.75, 0.31, 0.15 up 0+00:16:15 09:21:55 59 processes: 3 running, 56 sleeping CPU states: 36.0% user, 0.0% nice, 63.2% system, 0.8% interrupt, 0.0% idle Mem: 57M Active, 8412K Inact, 16M Wired, 2292K Cache, 9628K Buf, 8280K Free Swap: 786M Total, 22M Used, 764M Free, 2% Inuse This is basically X, Netscape, and 5800 exec()'s a minute. I've got debugging in my kernel, and I'll send you full results if and when it crashes again. -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
semi-HEADS-UP (dumpon now wants raw disk device)
While this was mentioned in the commit log for dumpon.c by phk, I figure I'd save you the loss of a kernel core to find out like the one I lost this morning. In rc.conf (or wherever you load dumpon) make sure you change it to using a raw device. dumpon no longer accepts block devices, as they were just cleaned out of -CURRENT. This relates to the heads up that Brian Somers sent on Sunday. You need to make world first or at least rebuild savecore/dumpon, as ache made some commits to it this morning. IE, old dumpdev in /etc/rc.conf:dumpdev="/dev/wd0s1b" Should be changed to: dumpdev="/dev/rwd0s1b" -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
In message [EMAIL PROTECTED] Nick Hibma writes: : The system freezes on powering down a PCCARD slot. From memory the : location is putb1 called from pcic_disable. The freeze is easy to : reproduce, just remove the card. When stepping through the code, even : the debugger prompt does not return after the outb for PCIC_POWER on : line 698 of pcic.c. My first guess was that the driver was getting interrupts at this point. This is true as far as it goes. This likely means that the driver hasn't detached by this point. You might try looking down that path to see if the device_delete_children is really being called, and if so on what. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
In message [EMAIL PROTECTED] Nick Hibma writes: : pcic: polling, can't alloc 0 : pcic: polling, can't alloc 0 This isn't your problem, but you might want to assign an interrupt line to these devices. Another problem is that I didn't implement the logic in the right way for the nbk. In many places I treat things as having one pccard device, when there is one per child. The pcic should tell the pccard child that an eject/socket power off has occurred and the pccard child should then detach all its children at that point. I was in a hurry and didn't do this like I should have. That might be an easier road to a fix as well. I'm *STILL* waiting for the returned laptop to come back. Grump. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: semi-HEADS-UP (dumpon now wants raw disk device)
On Tue, Nov 30, 1999 at 09:37:41AM -0500, Thomas Stromberg wrote: You need to make world first or at least rebuild savecore/dumpon, as ache made some commits to it this morning. IE, old dumpdev in /etc/rc.conf: dumpdev="/dev/wd0s1b" Should be changed to: dumpdev="/dev/rwd0s1b" I see no needs of this change. I have -current dumpon/savecore work with old entrly like /dev/wd0... savecore understand both character and old block devices now. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
How do I get a USB mouse working in todays -CURRENT ?
What's involved in getting a USB mouse working in -CURRENT ? I have a Micro$oft USB IntelliMouse 1.1A. I have added everything USB to my kernel (as I'm not using any USB klds) and have set usbd_enable to YES in /etc/rc.conf. My kernel and world are up to date as of about 3 hours ago and I have updated my /etc files (and hence have the latest /etc/usbd.conf). I disabled moused in /etc/rc.conf as usbd starts moused when attaching mice. This is what I see in the kernel probes (non-verbose boot with all the USB debugging options): uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 12 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision unknown, not supported 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 IntelliMouse, rev 1.00/1.04, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ums_attach: sc=0xc0921c00 ums_attach: X 8/8 ums_attach: Y 16/8 ums_attach: Z 24/8 ums_attach: B1 0/1 ums_attach: B2 1/1 ums_attach: B3 2/1 ums_attach: size=4, id=0 The problem is that the mouse doesn't work (its not a hardware problem), all I get whenever I move the mouse are lots of the following messages on the console: Discarded 7 bytes in queue Do I need to change /etc/usbd.conf in some way ? Any help greatly appreciated as all my PS/2 and serial mice are dead (luckily I read mail on my dumb terminal with PINE!). -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trigraph in IPV6?
From: [EMAIL PROTECTED]
Date: Tue, 30 Nov 1999 23:02:21 +0900
../../netinet6/in6.c: warning: 1 trigraph(s) encountered
haven't seen one of THOSE for a while
Could you tell me which line was that? I don't see any...
Indeed. The only line I see (as of the 1.1 version of the file, dated
1999/11/22 02:44:59) that has 2 consecutive '?' characters at all (which
sequence introduces all trigraphs) is line 892, which reads
* SIOCGLIFADDR: get first address. (???)
And my copy of the May 13, 1988 DpANS C states (section 2.2.1.1):
2.2.1.1 Trigraph sequences
All occurrences in a source file of the following sequences of
three characters (called trigraph sequences(5)) are replaced
with the corresponding single charcacter.
??= #
??( [
??/ \
??) ]
??' ^
?? {
??! |
?? }
??- ~
No other trigraph sequences exist. Each ? that does not begin
one of the trigraphs listed above is not changed. [Example
footnote elided -- dhw]
KR, 2nd ed., p. 229 appears to agree with the above.
I suspect a bogus warning from gcc's lexical analyzer.
Cheers,
david
--
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: semi-HEADS-UP (dumpon now wants raw disk device)
" I see no needs of this change. I have -current dumpon/savecore work with old entrly like /dev/wd0... savecore understand both character and old block devices now. While I see your commit in cvsweb to savecore, I still run into this (just cvsupp'd off of cvsup6.freebsd.org and rebuilt it): [root@karma] dumpon grep \$FreeBSD dumpon.c "$FreeBSD: src/sbin/dumpon/dumpon.c,v 1.8 1999/11/28 16:24:46 phk Exp $"; [root@karma] dumpon dumpon /dev/wd0s1b dumpon: /dev/wd0s1b: must specify a block device [root@karma] dumpon dumpon /dev/rwd0s1b [root@karma] dumpon Bug or Feature? FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Nov 30 09:03:33 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386 -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: semi-HEADS-UP (dumpon now wants raw disk device)
On Tue, Nov 30, 1999 at 10:49:57AM -0500, Thomas Stromberg wrote: [root@karma] dumpon dumpon /dev/wd0s1b dumpon: /dev/wd0s1b: must specify a block device [root@karma] dumpon dumpon /dev/rwd0s1b [root@karma] dumpon Bug or Feature? This message is confusing and means just opposite. I'll fix dumpon to accept both device types (to work with older kernels too) The bug is that you not rebuild your /dev -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trigraph in IPV6?
"David" == David Wolfskill [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED]
Date: Tue, 30 Nov 1999 23:02:21 +0900
../../netinet6/in6.c: warning: 1 trigraph(s) encountered
haven't seen one of THOSE for a while
Could you tell me which line was that? I don't see any...
David Indeed. The only line I see (as of the 1.1 version of the file, dated
David 1999/11/22 02:44:59) that has 2 consecutive '?' characters at all (which
David sequence introduces all trigraphs) is line 892, which reads
David * SIOCGLIFADDR: get first address. (???)
David And my copy of the May 13, 1988 DpANS C states (section 2.2.1.1):
David 2.2.1.1 Trigraph sequences
David All occurrences in a source file of the following sequences of
David three characters (called trigraph sequences(5)) are replaced
David with the corresponding single charcacter.
David ??= #
David ??( [
David ??/ \
David ??) ]
David ??' ^
David ?? {
David ??! |
David ?? }
David ??- ~
David No other trigraph sequences exist. Each ? that does not begin
David one of the trigraphs listed above is not changed. [Example
David footnote elided -- dhw]
David KR, 2nd ed., p. 229 appears to agree with the above.
David I suspect a bogus warning from gcc's lexical analyzer.
Why is the ??) not a trigraph? ie. (???) = (?]
Martin
--
Martin Hopkins | [EMAIL PROTECTED]
Insignia Solutions Plc, | [EMAIL PROTECTED]
The Mercury Centre, Wycombe Lane| Tel: (+44) 1628 539537
Wooburn Green, Bucks, HP10 0HH, UK. | Fax: (+44) 1628 539501
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: trigraph in IPV6?
{"/usr/src/sys/netinet6"}$ grep '??.' in6.c
* SIOCGLIFADDR: get first address. (???)
I think the way this has been fixed before is to change it to something
like (?!?) =)
I adopted the fix, thanks.
Yoshinobu Inoue
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
"Daniel C. Sobral" wrote: Marcel Moolenaar wrote: Julian Elischer wrote: When did this come in? (I have been seeing it for a while but.. I thought this was to save space on the bootblocks, not the entire kernel?) Shortly after setting it for the bootblock. It breaks backward compatibility and bogusly applies to the tools (xxx_genassym) as well. As you can tell, I'm not quite happy with it... That's why we made world first and kernel later for so long, y'know. And isn't it just a load of bollocks :-) Changing userland "tools" to depend on new syscalls has always been a far more rare happening than changing kernel to depend on new userland tools. Just remove the artificial dependencies, change building to suit the somewhat more restricted environment of cross-building and make some (in)significant adjustments in general and the problem is solved. It's not hard to do, you just need heavy boots and a strong mind :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
"Daniel C. Sobral" wrote: Marcel Moolenaar wrote: Julian Elischer wrote: When did this come in? (I have been seeing it for a while but.. I thought this was to save space on the bootblocks, not the entire kernel?) Shortly after setting it for the bootblock. It breaks backward compatibility and bogusly applies to the tools (xxx_genassym) as well. As you can tell, I'm not quite happy with it... That's why we made world first and kernel later for so long, y'know. Changing userland "tools" to depend on new syscalls has always been a far more rare happening than changing kernel to depend on new userland tools. -mpreferred-stack-boundary=2 is only picked up after a 'make world'. There's nothing stopping you building a -current kernel on an older world or older gcc. It's the world build that activates the option when bsd.kern.mk is installed in /usr/share/mk. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: semi-HEADS-UP (dumpon now wants raw disk device)
On Tue, 30 Nov 1999, Thomas Stromberg wrote: " I see no needs of this change. I have -current dumpon/savecore work with old entrly like /dev/wd0... savecore understand both character and old block devices now. While I see your commit in cvsweb to savecore, I still run into this (just cvsupp'd off of cvsup6.freebsd.org and rebuilt it): [root@karma] dumpon grep \$FreeBSD dumpon.c "$FreeBSD: src/sbin/dumpon/dumpon.c,v 1.8 1999/11/28 16:24:46 phk Exp $"; [root@karma] dumpon dumpon /dev/wd0s1b dumpon: /dev/wd0s1b: must specify a block device [root@karma] dumpon dumpon /dev/rwd0s1b [root@karma] dumpon Do you have the correct devices in /dev? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crash under high exec() loads.. (vm_map_insert?)
: that doesn't work, and there's any chance of getting a kernel dump, : try getting a kernel dump. Make sure you use a debug (compiled -g) : kernel. : : :While I can't say I truly see the correlation, you definitely know more :about how it works then me. I've cvsupp'd and upped it to 1000. One :question I have, is what exactly -are- pv's? PV's are a mistake, but nobody has figured out a better way to do it. PV's are essentially FreeBSD's way of managing page tables. They associated a physical page with an entry in a process's page table and allow the VM system to track which physical pages are mapped (and where), and which are not. This in turn reduces the overhead of many of the algorithms in the VM system and allows the system to scale. However, it costs memory to do this and it has an achilles heel - shared address spaces can exhaust the pool without exhausting physical memory. :The machine itself isn't under too much load during the testing, and :definitely does not used a lot of shared memory. During one of the tests :yesterday (c89) it was doing ~8000 execs per minute, with a load of :0.23. I've also got plenty of RAM left over. Here is what it currently :looks like: Yah. I don't know if that's it or not, but whenever systems crash that deep into the VM system the first thing we try is to up the number of PV's. :Free :Swap: 786M Total, 22M Used, 764M Free, 2% Inuse : :This is basically X, Netscape, and 5800 exec()'s a minute. : :I've got debugging in my kernel, and I'll send you full results if and :when it crashes again. :thomas r. stromberg smtp:[EMAIL PROTECTED] Both X and netscape have large run sizes. Any fork/exec from either of those programs will create a temporary spike in resource use. I could be totally wrong but it's definitely suspect and worth trying. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD
On Tue, 30 Nov 1999, Dan Langille wrote: FWIW, I just fetched the tarball from the website and started a compile. It gets further than the previous attempt. My suggestion to Davec is that he try the instructions at: http://www.freebsddiary.org/freebsd/ipfilter333.htm I know they work for 3.3-stable and hopefully they will work for him under -current. Yup tried it, didn't work. Got the same error messages (refer to the [LONG] email I sent a few days past. Thanks for the suggestion though. Dave -- [EMAIL PROTECTED] PS. I'm about giving up on this. Probably going to just go with ipfw and live with it, or go back to the Oct. 10 snap of -CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
From some very brief testing here, the problem is that the card's interrupt handler hasn't yet been disconected. When you power the card down, you get an edge on the interrupt pin, and then the driver interrupt handler spins madly because the card hardware is gone and thus doesn't behave. If you have an ethernet card, try suspending with just it in the slot and then break into DDB; I'll warrant that you end up inside the relevant driver's interrupt handler. If I'm correct, this is just an ordering issue; the driver has to be shut down _before_ the slot, not afterwards. The system freezes on powering down a PCCARD slot. From memory the location is putb1 called from pcic_disable. The freeze is easy to reproduce, just remove the card. When stepping through the code, even the debugger prompt does not return after the outb for PCIC_POWER on line 698 of pcic.c. This is on CURRENT as of yesterday evening, but other CURRENTs of the last month have the same problem. I've not been able to find a possible culprit in recent commits to pcic.c or pccard.c. Do you have any hint on how to debug this or what version of pcic.c I should take to get rid of this problem? pcic-pci0: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 pcic-pci1: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.1 on pci0 ... pcic: polling, can't alloc 0 pcic: polling, can't alloc 0 pcic0: VLSI 82C146 on isa0 pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 Thanks for the work being done. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: block devices dumpon.
"Andrey A. Chernov" wrote:
On Tue, Nov 30, 1999 at 10:49:57AM -0500, Thomas Stromberg wrote:
[root@karma] dumpon dumpon /dev/wd0s1b
dumpon: /dev/wd0s1b: must specify a block device
[root@karma] dumpon dumpon /dev/rwd0s1b
[root@karma] dumpon
Bug or Feature?
This message is confusing and means just opposite.
I'll fix dumpon to accept both device types (to work with older kernels too)
The bug is that you not rebuild your /dev
I thought all I needed to do was "./MAKEDEV all" in /dev after a
mergemaster (I also tried MAKEDEV drive) However, I guess this is not
the case. Evidentally if I makedev a drive or all, it does not MAKEDEV
the slices. I could of sworn it was supposed to.. alas! Learn something
new every day.
In any case the new 1.9 commit still acts strange (imho), I put some
output on the bottom. Thanks for your help btw! Nothing teaches you
better then a good screwup :)
[root@karma] /dev uname -a
FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue
Nov 30 09:03:33 EST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
[root@karma] /dev ./MAKEDEV all
[root@karma] /dev ls wd0s*
crw-r- 1 root operator3, 0x00020002 Nov 30 12:09 wd0s1
brw-r- 1 root operator0, 0x0002 Nov 16 11:09 wd0s1a
brw-r- 1 root operator0, 0x00020001 Nov 29 18:06 wd0s1b
brw-r- 1 root operator0, 0x00020002 Aug 17 11:40 wd0s1c
brw-r- 1 root operator0, 0x00020003 Nov 16 16:48 wd0s1d
brw-r- 1 root operator0, 0x00020004 Nov 16 11:09 wd0s1e
brw-r- 1 root operator0, 0x00020005 Nov 16 11:09 wd0s1f
brw-r- 1 root operator0, 0x00020006 Nov 16 11:09 wd0s1g
brw-r- 1 root operator0, 0x00020007 Nov 16 11:09 wd0s1h
crw-r- 1 root operator3, 0x00030002 Nov 30 12:09 wd0s2
crw-r- 1 root operator3, 0x00040002 Nov 30 12:09 wd0s3
crw-r- 1 root operator3, 0x00050002 Nov 30 12:09 wd0s4
[root@karma] /dev ./MAKEDEV wd0s1b
[root@karma] /dev ./MAKEDEV wd0s1a
[root@karma] /dev ls -la wd0s*
crw-r- 1 root operator3, 0x00020002 Nov 30 12:09 wd0s1
crw-r- 1 root operator3, 0x0002 Nov 30 12:09 wd0s1a
crw-r- 1 root operator3, 0x00020001 Nov 30 12:09 wd0s1b
crw-r- 1 root operator3, 0x00020002 Nov 30 12:09 wd0s1c
crw-r- 1 root operator3, 0x00020003 Nov 30 12:09 wd0s1d
crw-r- 1 root operator3, 0x00020004 Nov 30 12:09 wd0s1e
crw-r- 1 root operator3, 0x00020005 Nov 30 12:09 wd0s1f
crw-r- 1 root operator3, 0x00020006 Nov 30 12:09 wd0s1g
crw-r- 1 root operator3, 0x00020007 Nov 30 12:09 wd0s1h
crw-r- 1 root operator3, 0x00030002 Nov 30 12:09 wd0s2
crw-r- 1 root operator3, 0x00040002 Nov 30 12:09 wd0s3
crw-r- 1 root operator3, 0x00050002 Nov 30 12:09 wd0s4
Output of the new 1.9 dumpon on block slices:
---
[root@karma] /dev ls -la wd0s1b
brw-r--r-- 1 root wheel0, 0x00020001 Nov 30 12:17 wd0s1b
[root@karma] /dev dumpon /dev/wd0s1b
dumpon: sysctl: kern.dumpdev: Device not configured
[root@karma] /dev ./MAKEDEV wd0s1b
[root@karma] /dev dumpon /dev/wd0s1b
[root@karma] /dev sysctl -a|grep kern.dump
kern.dumpdev: { major = 3, minor = 131073 }
Still burps a wee bit. But after I looked at it again it's easy to tell
why. I guess a sysctl gets put into place (I'm still not sure from
where?) called kern.dumpdev that records the original device data
specified from /etc/rc.conf .. of course, when I last booted, mine was
set to /dev/rwd0s1b, which has those properties ..
I'm just wondering why it checks those properties rather then using the
properties of the specified file (/dev/wd0s1b in that case)..
--
==
thomas r. stromberg smtp:[EMAIL PROTECTED]
assistant is manager / systems guru http://thomas.stromberg.org
research triangle commerce, inc.finger:[EMAIL PROTECTED]
'om mani pedme hung'pots://1.919.380.9771:3210
[eof]=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Matthew Dillon wrote: : Anyhow, I'll repeat it here - stack alignment does *not* break : link-compatibility. It does not change calling conventions, it just : adds padding after the args to ensure that local variables can be : predictably aligned. : : So, how does aligning stackframes affect the inherently static property : of code size then? : :Instructions are inserted to perform that alignment (add padding). :When the alignment is 2 (i.e. on 4-byte boundaries), no padding is :required in typical cases. I can't think of a single case where the stack isn't inherently 4-byte aligned already, whether you use the option or not. It's more a case of overriding the new behaviour of gcc to align the stack on 16-byte boundaries by default (for performance reasons for the PIII SIMD instructions, IIRC) To whomever added the option: Did you actually test to see that this option resulted in an improvement? If not, I recommend removing it. It sounds like unnecessary extra junk to me. For the bootcode the option is necessary. It does remove a lot of "subl $..,%esp" instructions that bloated the code, which in turn prevented boot2 to build. It's not necessary for kernel/module builds. But the option does prevent a lot of unnecessary alignment instructions in the code... Maybe -mpreferred-stack-boundary=2 should be the default so that we don't need the option in the general case. Overriding this in certain cases, can be considered an optimisation... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: semi-HEADS-UP (dumpon now wants raw disk device)
On Tue, 30 Nov 1999, Thomas Stromberg wrote:
[ache wrote]:
"
I see no needs of this change. I have -current dumpon/savecore work with
old entrly like /dev/wd0...
savecore understand both character and old block devices now.
You must not have a very current -current :-). /dev/wd0 is a character
device (with the same major/minor and character as /dev/rwd0) in -current:
crw-r- 1 root operator3, 0x00010002 Dec 1 04:34 rwd0
crw-r- 1 root operator3, 0x00010002 Dec 1 04:34 wd0
[root@karma] dumpon grep \$FreeBSD dumpon.c
"$FreeBSD: src/sbin/dumpon/dumpon.c,v 1.8 1999/11/28 16:24:46 phk Exp
$";
[root@karma] dumpon dumpon /dev/wd0s1b
dumpon: /dev/wd0s1b: must specify a block device
[root@karma] dumpon dumpon /dev/rwd0s1b
[root@karma] dumpon
Bug or Feature?
Bug in dumpon. The error message no longer matches the code. I use the
following "fix". I changed the code too. dumpon(8) shouldn't be checking
whether the file supports the dumpon sysctl. All it needs is a valid
st_rdev to pass to the dumpon sysctl.
diff -c2 dumpon.c~ dumpon.c
*** dumpon.c~ Mon Nov 29 20:09:29 1999
--- dumpon.cMon Nov 29 20:16:40 1999
***
*** 85,91
}
! if (!S_ISCHR(stab.st_mode)) {
! errx(EX_USAGE, "%s: must specify a block device",
!argv[0]);
}
} else {
--- 85,90
}
! if (!S_ISBLK(stab.st_mode) !S_ISCHR(stab.st_mode)) {
! errx(EX_USAGE, "%s: must specify a device", argv[0]);
}
} else {
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: block devices dumpon.
In message [EMAIL PROTECTED], Frank Mayhar writes: Thomas Stromberg wrote: I thought all I needed to do was "./MAKEDEV all" in /dev after a mergemaster (I also tried MAKEDEV drive) However, I guess this is not the case. Evidentally if I makedev a drive or all, it does not MAKEDEV the slices. I could of sworn it was supposed to.. alas! Learn something new every day. Personally, I think this is a needed enhancement for MAKEDEV. IMHO, it violates the POLA that a "MAKEDEV all" doesn't make _all_ the necessary devices to run one's system. I agree (patches accepted), although it is hard to figure out just exactly what is needed to "run one's system". Maybe a "remake" entry in MAKEDEV which remakes all current entries if possible. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: block devices dumpon.
Thomas Stromberg wrote: I thought all I needed to do was "./MAKEDEV all" in /dev after a mergemaster (I also tried MAKEDEV drive) However, I guess this is not the case. Evidentally if I makedev a drive or all, it does not MAKEDEV the slices. I could of sworn it was supposed to.. alas! Learn something new every day. Personally, I think this is a needed enhancement for MAKEDEV. IMHO, it violates the POLA that a "MAKEDEV all" doesn't make _all_ the necessary devices to run one's system. (_I_ keep forgetting, since it's usually at least months between one system install and another, and always end up having to go back and do a "MAKEDEV da0s1a" or whatever, usually in single-user mode when the system refused to mount filesystems because of missing /dev entries. Sigh.) Or at the very _least_, "MAKEDEV da1" should make the slice devs too. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MDF_ACTIVE overloading still there.
Hi, MDF_ACTIVE in /sys/pccard/cardinfo has another meaning (and value) than /sys/sys/memrange.h: cardinfo.h:#define MDF_ACTIVE 0x40 /* Context active (read-only) */ memrange.h:#define MDF_ACTIVE (127) /* currently active */ This breaks kdump (YMMV. In this case it's a -current source tree on a -stable machine with nonstandard Makefiles). It has been mentioned before. It has even be fixed (or so it is claimed). Has it reappeared or has the fix just been a workaround? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
In message [EMAIL PROTECTED] Mike Smith writes: : If I'm correct, this is just an ordering issue; the driver has to be shut : down _before_ the slot, not afterwards. Right. The code that is doing the shutdown is trying to shutdown the driver, but that doesn't seem to be happening. The other possibility is that it is happening, but the interrupt handler isn't getting removed due to a bug in that code. I sure miss my laptop.. :-. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: block devices dumpon.
On Tue, Nov 30, 1999 at 12:27:53PM -0500, Thomas Stromberg wrote: I thought all I needed to do was "./MAKEDEV all" in /dev after a mergemaster (I also tried MAKEDEV drive) However, I guess this is not the case. Evidentally if I makedev a drive or all, it does not MAKEDEV the slices. I could of sworn it was supposed to.. alas! Learn something new every day. Yes, MAKEDEV all do not create slices, they m8ust be created by hand. [root@karma] /dev dumpon /dev/wd0s1b dumpon: sysctl: kern.dumpdev: Device not configured It is proper message this time. New kernel not support old block devices. But in case you MAKEDEV slices, it will work. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc_r.so.3 and compat3x
"Chris D. Faulhaber" wrote: I am in the midst of updating one of my ports, net/elsa, and have found that it requires libc_r.so.3; unfortunately, compat3x does not contain this lib. Any chance of having it added to compat3x? Yes. The PR is assigned to me, but David already has it on his TODO list. Compat3x is updated late to make sure the latest libraries are in... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
: I can't think of a single case where the stack isn't inherently : 4-byte aligned already, whether you use the option or not. : :It's more a case of overriding the new behaviour of gcc to align the :stack on 16-byte boundaries by default (for performance reasons for the :PIII SIMD instructions, IIRC) : : To whomever added the option: Did you actually test to see that : this option resulted in an improvement? If not, I recommend removing : it. It sounds like unnecessary extra junk to me. : :For the bootcode the option is necessary. It does remove a lot of "subl :$..,%esp" instructions that bloated the code, which in turn prevented :boot2 to build. It's not necessary for kernel/module builds. But the :option does prevent a lot of unnecessary alignment instructions in the :code... : :Maybe -mpreferred-stack-boundary=2 should be the default so that we :don't need the option in the general case. Overriding this in certain :cases, can be considered an optimisation... : :-- :Marcel Moolenaarmailto:[EMAIL PROTECTED] SIMD? It sounds like they are trying to enforce alignment against the cache line size in general. I can sorta see how it might help, but it's a huge waste of space! -rwxr-xr-x 1 root wheel 2051069 Nov 29 17:59 kernel EGCS -rwxr-xr-x 1 root wheel 2081364 Nov 30 10:18 kernel NEW GCC -rwxr-xr-x 1 root wheel 2008468 Nov 30 10:15 kernel NEW GCC w/ -m The new GCC does a better job verses the old EGCS if you use the option to limit alignment to 4 bytes. If you do not use the option the 16 byte alignment adds 70K to the size of the kernel. All I can say to that is "bleh". The real question is whether performance is actually improved significantly or not. If not, I'd sent a nasty email to the gcc folks :-) The extra subl's are not going to cost anything in regards to cpu so the real question is whether the cache line alignment boosts performance. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Matthew Dillon wrote: All I can say to that is "bleh". The real question is whether performance is actually improved significantly or not. If not, I'd sent a nasty email to the gcc folks :-) I guess only if you do have a PIII and are using the new instructions. In most cases this has no effect whatsoever. Not counting the significant code size increase. From the GCC manual (reproduced without explicit permission :-) -mpreferred-stack-boundary=num Attempt to keep the stack boundary aligned to a 2 raised to num byte boundary. If `-mpreferred-stack-boundary' is not specified, the default is 4 (16 bytes or 128 bits). The stack is required to be aligned on a 4 byte boundary. On Pentium and PentiumPro, double and long double values should be aligned to an 8 byte boundary (see `-malign-double') or suffer significant run time performance penalties. On Pentium III, the Streaming SIMD Extention (SSE) data type __m128 suffers similar penalties if it is not 16 byte aligned. To ensure proper alignment of this values on the stack, the stack boundary must be as aligned as that required by any value stored on the stack. Further, every function must be generated such that it keeps the stack aligned. Thus calling a function compiled with a higher preferred stack boundary from a function compiled with a lower preferred stack boundary will most likely misalign the stack. It is recommended that libraries that use callbacks always use the default setting. This extra alignment does consume extra stack space. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to `-mpreferred-stack-boundary=2'. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report - Nov.
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Hi, here is the Nov. progress report from ACPI project in Japan. Cool. This is indeed good news. Keep up the good reports. iwasaki-san to acpi-jp wa domo arigato gozaimasu. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
On Tue, 30 Nov 1999, Marcel Moolenaar wrote: Matthew Dillon wrote: All I can say to that is "bleh". The real question is whether performance is actually improved significantly or not. If not, I'd sent a nasty email to the gcc folks :-) I guess only if you do have a PIII and are using the new instructions. In most cases this has no effect whatsoever. Not counting the significant code size increase. It's also useful for properly aligning doubles on the stack. I would have expected the most generally efficient way to align doubles and the new PIII obkects to be aligning the stack only in functions that have such objects on the stack. This requires at most one extra instruction: andl $~0xf,$esp 16-byte alignment Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: block devices dumpon.
In message [EMAIL PROTECTED] Frank Mayhar writes: : Personally, I think this is a needed enhancement for MAKEDEV. IMHO, it : violates the POLA that a "MAKEDEV all" doesn't make _all_ the necessary : devices to run one's system. That's one of the reasons that there is a strong desire to have devfs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
can't use vat (and only vat) with newpcm
I'm having problems running vat with newpcm: after opening the device the sound begins for a fraction of a second, then stops. Maybe this has to do with the fact that vat uses /dev/audio and not /dev/dsp; I've tried to open /dev/dsp instead and change the device format but the result is the same. Or maybe this has to do with the non-blocking opening done by vat (I've changed this too, same result). But strangely enough, a cat /dev/audio, amp or mpg123 all work ok. The chip is the following. The kernel is configured with just "device pcm0". From a ktrace, vat does nothing but writes to the device. pcm0: CS4236B at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 unknown0: Game at port 0x3a0-0x3a7 on isa0 unknown1: Ctrl at port 0xf00-0xf07 on isa0 unknown2: MPU at port 0x330-0x331 on isa0 -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
I just went to the Oct. 7th snap of -CURRENT (right before IP Filter was removed from FreeBSD 4.0-CURRENT's source tree). Would this warning have anything to do with ipl not working in the latest snap? WARNING: driver ipl should register devices with make_dev() (dev_t = "#ipl/1") As I recall, there was a time when make_dev() was being outmoded? Davec -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
With freeze I meant, freeze. Rock solid. Nothing to be done. Stepping through the code the laptop freezes in the second putb in pcic_disable. As in stepping the assembler to that outb does never return the prompt. Nick From some very brief testing here, the problem is that the card's interrupt handler hasn't yet been disconected. When you power the card down, you get an edge on the interrupt pin, and then the driver interrupt handler spins madly because the card hardware is gone and thus doesn't behave. If you have an ethernet card, try suspending with just it in the slot and then break into DDB; I'll warrant that you end up inside the relevant driver's interrupt handler. If I'm correct, this is just an ordering issue; the driver has to be shut down _before_ the slot, not afterwards. The system freezes on powering down a PCCARD slot. From memory the location is putb1 called from pcic_disable. The freeze is easy to reproduce, just remove the card. When stepping through the code, even the debugger prompt does not return after the outb for PCIC_POWER on line 698 of pcic.c. This is on CURRENT as of yesterday evening, but other CURRENTs of the last month have the same problem. I've not been able to find a possible culprit in recent commits to pcic.c or pccard.c. Do you have any hint on how to debug this or what version of pcic.c I should take to get rid of this problem? pcic-pci0: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 pcic-pci1: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.1 on pci0 ... pcic: polling, can't alloc 0 pcic: polling, can't alloc 0 pcic0: VLSI 82C146 on isa0 pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 Thanks for the work being done. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD
On Tue, 30 Nov 1999, Davec wrote: On Tue, 30 Nov 1999, Dan Langille wrote: FWIW, I just fetched the tarball from the website and started a compile. It gets further than the previous attempt. My suggestion to Davec is that he try the instructions at: http://www.freebsddiary.org/freebsd/ipfilter333.htm I know they work for 3.3-stable and hopefully they will work for him under -current. Yup tried it, didn't work. Got the same error messages (refer to the [LONG] email I sent a few days past. Thanks for the suggestion though. Dave -- [EMAIL PROTECTED] PS. I'm about giving up on this. Probably going to just go with ipfw and live with it, or go back to the Oct. 10 snap of -CURRENT. --- /\/\artin hong /\/etwork /\dministrator email: [EMAIL PROTECTED] --- "They will make cemetaries their Cathedralsand tombs your cities." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
In message [EMAIL PROTECTED] Christopher Masto writes: : I noticed that the "new" code does the power off before the : reset.. dunno if this is significant. Shouldn't be... I gotta get a bouncer system that I can plug a bridge into to see if I can get this problem to happen for me (which i think I will). Damn. I miss my laptop. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep driver troubles
After playing around with the configuration program for a little bit, if I set the card back to ISA mode (fixed address/irq), the patched driver now detects the card. As soon as I set the card to PnP, the driver doesn't see it. Based on the pnpinfo output, I assume this must be something to do with the way my system is configured. I looked at my BIOS settings, and saw that all IRQs were marked available for PnP, and that it was set to use BIOS PnP. Is this the problem? Should this option have been set to "PnP OS"? I'm (obviously) not too familiar with the PnP architecture, so I have no real clue what the difference between the two settings are... Eric On Tue, 30 Nov 1999, Matthew N. Dodd wrote: On Mon, 29 Nov 1999, Eric Ogren wrote: Already there (I can attach my entire config file / dmesg output to anyone who wants to see it, but I didn't want to dump the whole thing to the list). How about the output of 'pnpinfo'? Apply this patch: ftp://ftp.jurai.net/users/winter/patches/if_ep.patch -- | 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 | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep driver troubles
On Tue, 30 Nov 1999, Matthew N. Dodd wrote: On Mon, 29 Nov 1999, Eric Ogren wrote: Already there (I can attach my entire config file / dmesg output to anyone who wants to see it, but I didn't want to dump the whole thing to the list). How about the output of 'pnpinfo'? Apply this patch: ftp://ftp.jurai.net/users/winter/patches/if_ep.patch Well, after applying the patch, I don't see anything about a PnP card detected- in fact, dmesg | grep -i ep now shows nothing. Pnpinfo seems to indicate that it's not seeing the card either. Maybe I just configured it wrong? [will play around in the dos cfg program and see what I can find] Eric [pnpinfo result below]: Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID ADS7181 (0x81719304), Serial Number 0x PnP Version 1.0, Vendor Version 32 Device Description: Analog Devices AD1816A Logical Device ID: ADS7180 0x80719304 #0 Device supports I/O Range Check TAG Start DF Good Configuration IRQ: 5 7 - only one type (true/edge) DMA: channel(s) 1 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4 [16-bit addr] I/O Range 0x500 .. 0x560, alignment 0x10, len 0x10 [16-bit addr] TAG Start DF IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4 [16-bit addr] I/O Range 0x500 .. 0x560, alignment 0x10, len 0x10 [16-bit addr] TAG Start DF IRQ: 5 7 9 10 11 15 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F I/O Range 0x220 .. 0x2e0, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x3b8, alignment 0x8, len 0x4 [16-bit addr] I/O Range 0x500 .. 0x560, alignment 0x10, len 0x10 [16-bit addr] TAG Start DF Sub-optimal Configuration IRQ: 5 7 9 10 11 15 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 8-bit, not a bus master, count by byte, , Type F I/O Range 0x220 .. 0x2e0, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x3b8, alignment 0x8, len 0x4 [16-bit addr] I/O Range 0x500 .. 0x560, alignment 0x10, len 0x10 [16-bit addr] TAG End DF Logical Device ID: ADS7181 0x81719304 #1 Device supports I/O Range Check Compatible Device ID: PNPb006 (06b0d041) TAG Start DF Good Configuration IRQ: 5 7 9 11 - only one type (true/edge) I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] TAG Start DF IRQ: 5 7 9 10 11 15 - only one type (true/edge) I/O Range 0x300 .. 0x420, alignment 0x30, len 0x2 [16-bit addr] TAG End DF Logical Device ID: ADS7182 0x82719304 #2 Device supports I/O Range Check Compatible Device ID: PNPb02f (2fb0d041) TAG Start DF Good Configuration I/O Range 0x200 .. 0x200, alignment 0x8, len 0x8 [16-bit addr] TAG Start DF I/O Range 0x200 .. 0x208, alignment 0x8, len 0x8 [16-bit addr] TAG End DF End Tag Successfully got 48 resources, 3 logical fdevs -- card select # 0x0001 CSN ADS7181 (0x81719304), Serial Number 0x Logical device #0 IO: 0x0220 0x0220 0x0220 0x0220 0x0220 0x0220 0x0220 0x0220 IRQ 5 0 DMA 1 0 IO range check 0x00 activate 0x01 Logical device #1 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 7 0 DMA 4 4 IO range check 0x00 activate 0x01 Logical device #2 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : I found that the only message printed was "ready to power off". bingo. looks like we're not deleting the child. Try replacing that for loop with something like: pccarddev = devclass_get_device(pccard_devclass, slt-slot); device_get_children(pccarddev, kids, nkids) for (i = 0; i nkids; i++) device_delete_child(pccarddev, kid[0]); It isn't quite right, but if it works then I know the right fix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep driver troubles
On Nov 30, Eric Ogren wrote: After playing around with the configuration program for a little bit, if I set the card back to ISA mode (fixed address/irq), the patched driver now detects the card. As soon as I set the card to PnP, the driver doesn't see it. Based on the pnpinfo output, I assume this must be something to do with the way my system is configured. I looked at my BIOS settings, and saw that all IRQs were marked available for PnP, and that it was set to use BIOS PnP. Is this the problem? Should this option have been set to "PnP OS"? Hi, If the symptoms are that the device doesn't probe in PNP mode (or even appear as an unknown device) then try kern/14962. Hope this helps, --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : I found that the only message printed was "ready to power off". bingo. looks like we're not deleting the child. Try replacing that for loop with something like: pccarddev = devclass_get_device(pccard_devclass, slt-slot); device_get_children(pccarddev, kids, nkids) for (i = 0; i nkids; i++) device_delete_child(pccarddev, kid[0]); It isn't quite right, but if it works then I know the right fix. Hey, we're getting somewhere. It works, in that it stops the panic. I get the "ed0: unloaded" message, and the machine doesn't panic, but there are still some problems. It seems that device_delete_child is failing (I forgot to print the return code, but it is not zero), and reinserting the card results in "ed0 already exists, using next available unit number", and then the dreaded "driver allocation failed" (presumably the resources have not been freed). Putting in a different kind of card ends up with two children, so it seems that the only part of the delete actually happens. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
Christopher Masto wrote: On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : I found that the only message printed was "ready to power off". bingo. looks like we're not deleting the child. Try replacing that for loop with something like: pccarddev = devclass_get_device(pccard_devclass, slt-slot); device_get_children(pccarddev, kids, nkids) for (i = 0; i nkids; i++) device_delete_child(pccarddev, kid[0]); It isn't quite right, but if it works then I know the right fix. Hey, we're getting somewhere. It works, in that it stops the panic. I get the "ed0: unloaded" message, and the machine doesn't panic, but there are still some problems. It seems that device_delete_child is failing (I forgot to print the return code, but it is not zero), I'll bet Warner meant device_delete_child(pccarddev, kid[i]); up there, and not device_delete_child(pccarddev, kid[0]); Did you try that? -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Bruce Evans wrote: I would have expected the most generally efficient way to align doubles and the new PIII obkects to be aligning the stack only in functions that have such objects on the stack. This requires at most one extra instruction: andl $~0xf,$esp 16-byte alignment I think, it's not that simple in the usual case when the object is accessed via (%ebp-someconstant). Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : Hey, we're getting somewhere. It works, in that it stops the panic. : I get the "ed0: unloaded" message, and the machine doesn't panic, but : there are still some problems. It seems that device_delete_child : is failing (I forgot to print the return code, but it is not zero), : and reinserting the card results in "ed0 already exists, using : next available unit number", and then the dreaded "driver allocation : failed" (presumably the resources have not been freed). : : Putting in a different kind of card ends up with two children, so : it seems that the only part of the delete actually happens. Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 02:54:28PM -0800, Frank Mayhar wrote:
On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote:
pccarddev = devclass_get_device(pccard_devclass, slt-slot);
device_get_children(pccarddev, kids, nkids)
for (i = 0; i nkids; i++)
device_delete_child(pccarddev, kid[0]);
I'll bet Warner meant
device_delete_child(pccarddev, kid[i]);
up there, and not
device_delete_child(pccarddev, kid[0]);
Did you try that?
Yes, the actual code I used is:
pccarddev = devclass_get_device(pccard_devclass, slt-slotnum);
device_get_children(pccarddev, kids, nkids);
printf("pccard: %d kids\n", nkids);
for (i = 0; i nkids; i++) {
printf("pccard: deleting kid %d\n", i);
if (ret=device_delete_child(pccarddev, kids[i]))
printf("pccard: delete kid %d failed: %d\n", i, ret);
}
It's not quite working. I think I got away ok with the ethernet card
because it wasn't being accessed, but my CDPD card with a running PPP
session pretty reliably still freezes up. Hrm. No, it's not freezing
up, it's a panic, but I'm running X and can't get to it.
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Frank Mayhar writes: : I'll bet Warner meant : device_delete_child(pccarddev, kid[i]); : up there, and not : device_delete_child(pccarddev, kid[0]); : : Did you try that? Yes. He did. Likely won't make a difference here because we don't add more than one child to the pccard slot child. I'll have to take a close look at this when I can get to a system I can crash a few dozen times to see what's going on. The delete_child should remove the instance of the child. Also, when I was having delete_child problems in the past (when I the first few iterations of the pccard code) I was able to ifconfig ed1 when ed0 would go away... Warner "Sir, as of Nov 30, your laptop is still in our Repair facility with not shipment ET, thank you for calling...A" Losh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : It's not quite working. I think I got away ok with the ethernet card : because it wasn't being accessed, but my CDPD card with a running PPP : session pretty reliably still freezes up. Hrm. No, it's not freezing : up, it's a panic, but I'm running X and can't get to it. Then don't do that :-) This sounds like the usual driver access driver memory that isn't there anymore problem. The driver's softc is blown away with the delete, even if it is sleeping somewhere and there is no way to tell it about it. At least that's my wild-ass guess not having the hardware to test it with here at work. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 04:04:40PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : Hey, we're getting somewhere. It works, in that it stops the panic. : I get the "ed0: unloaded" message, and the machine doesn't panic, but : there are still some problems. It seems that device_delete_child : is failing (I forgot to print the return code, but it is not zero), : and reinserting the card results in "ed0 already exists, using : next available unit number", and then the dreaded "driver allocation : failed" (presumably the resources have not been freed). : : Putting in a different kind of card ends up with two children, so : it seems that the only part of the delete actually happens. Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? I added a check of the return value. It seemed to be returning 12 (ENOMEM), but I'm not sure if that's real or garbage, since I'm having trouble finding a code path that would return that. And further data on the CDPD card.. removing it while PPP is still running just paniced in sioioctl. However, the delete_child didn't fail for sio, unlike with ed. I'm going to reboot and see if I can successfully remove and reinsert the card if I make sure nothing has sio open at the time. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : I added a check of the return value. It seemed to be returning 12 : (ENOMEM), but I'm not sure if that's real or garbage, since I'm having : trouble finding a code path that would return that. You might want to make ed_pccard_detach return an int and have it return 0. That's likely the problem. : And further data on the CDPD card.. removing it while PPP is still : running just paniced in sioioctl. However, the delete_child didn't : fail for sio, unlike with ed. I'm going to reboot and see if I can : successfully remove and reinsert the card if I make sure nothing has : sio open at the time. Hmmm. The sioioctl tells me that there is the memory problem I alluded to in the previous message.. At least that's my hunch... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
I'm on my way out for dinner, just thought I'd mention the latest experiment results. On Tue, Nov 30, 1999 at 04:19:18PM -0700, Warner Losh wrote: : And further data on the CDPD card.. removing it while PPP is still : running just paniced in sioioctl. However, the delete_child didn't : fail for sio, unlike with ed. I'm going to reboot and see if I can : successfully remove and reinsert the card if I make sure nothing has : sio open at the time. Hmmm. The sioioctl tells me that there is the memory problem I alluded to in the previous message.. At least that's my hunch... I just tried it without the device in use, and it froze solid after: pccard: 1 kids pccard: deleting kid 0 sio3: unload,gone pccard: delete kid 0 failed: 18 pccard: ready to power off pccard: card removed, slot 0 Ho hum. sio_pccard_detach also needs to be fixed to return 0, but I don't think that explains the freeze. Unfortunately, while I can sometimes squeeze in a few minutes to try quick fixes, my current job doesn't leave me with time to get enough clue to really work on this. If you lived in New York, I'd lend you my laptop. :-/ Good luck getting yours back. I have the same model, and desperately hoping I won't also have to deal with Sony's famous customer disservice. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Mike Smith writes: : You should definitely check the delete result, yes. : : Also, are you calling bus_generic_detach() after deleting the child? : I got the impression from Doug that this is required... In the child? device_delete_child() already calls device_detach(child). I can't call anything on the child device after delete_child becuase it is gone (and the memory is freed). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
modules building...
I tried to rebuild the linux kernel module, but it doesn't work: Warning: Object directory not changed from original /usr/src/sys/modules/linux cc -c -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/linux -I/usr/src/sys/modules/linux/@ -mpreferred-stack-boundary=2 -UKERNEL /usr/src/sys/modules/linux/../../i386/linux/linux_genassym.c cc -static -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/linux -I/usr/src/sys/modules/linux/@ -mpreferred-stack-boundary=2 -o linux_genassym linux_genassym.o ./linux_genassym linux_assym.h make: don't know how to make opt_linux.h. Stop several other modules exhibit similar behavior... = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : Ho hum. sio_pccard_detach also needs to be fixed to return 0, but I : don't think that explains the freeze. Unfortunately, while I can : sometimes squeeze in a few minutes to try quick fixes, my current : job doesn't leave me with time to get enough clue to really work : on this. I think i know what is going on. I'll have to see if I can get that bouncer box up tonight. It has -stable on it right now due to previous contracts, but I need -current on it shortly for the newcard code testing (since I think that I'm a few code walk throughs away from hardware testing). It would help me if you could send me your patches... : If you lived in New York, I'd lend you my laptop. :-/ Good luck : getting yours back. I have the same model, and desperately hoping : I won't also have to deal with Sony's famous customer disservice. Nope. I'm in Boulder. If I have trouble getting the bouncer going tonight I'll hit my boss up to borrow his laptop. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules building...
I tried to rebuild the linux kernel module, but it doesn't work: This is -current. You need to stay up to date. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules building...
I just cvsupped about 2 hours ago... = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Tue, 30 Nov 1999, Mike Smith wrote: I tried to rebuild the linux kernel module, but it doesn't work: This is -current. You need to stay up to date. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules building...
That's not what I said. I just cvsupped about 2 hours ago... On Tue, 30 Nov 1999, Mike Smith wrote: I tried to rebuild the linux kernel module, but it doesn't work: This is -current. You need to stay up to date. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Please check missing logical IDs for SB
If you have an SB card not probed since the import of the bridge
dirvers, could you please apply the following patch, add the logical
ID of your card into sbc_ids[] and see how it works?
(I have asked peter to review the PnP part of the patch)
Index: sbc.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sbc.c,v
retrieving revision 1.2
diff -u -r1.2 sbc.c
--- sbc.c 1999/11/27 06:33:27 1.2
+++ sbc.c 1999/11/30 06:28:19
@@ -82,125 +82,42 @@
static devclass_t sbc_devclass;
-#if NISA 0 NPNP 0
-static int
-sbc_probe(device_t dev)
-{
- u_int32_t vend_id, logical_id, vend_id2;
- char *s;
- struct sndcard_func *func;
- vend_id = isa_get_vendorid(dev);
- vend_id2 = vend_id 0xff00;
- logical_id = isa_get_logicalid(dev);
- s = NULL;
+#if NISA 0 NPNP 0
- switch (logical_id) {
+static struct isa_pnp_id sbc_ids[] = {
#if notdef
- case 0x630e: /* Crystal Semiconductor */
- if (vend_id2 ==0x3600630e) /* CS4236 */
- s = "CS4236";
- else if (vend_id2 ==0x3200630e) /* CS4232 */
- s = "CS4232";
- else if (vend_id2 ==0x3500630e) /* CS4236B */
- s = "CS4236B";
- break;
-#endif /* notdef */
- case 0x01008c0e: /* Creative ViBRA16C */
- if (vend_id2 == 0x70008c0e)
- s = "Creative ViBRA16C PnP";
- break;
- case 0x43008c0e: /* Creative ViBRA16X */
- if (vend_id2 == 0xf0008c0e)
- s = "Creative ViBRA16C PnP";
- break;
- case 0x31008c0e: /* Creative SB */
- if (vend_id2 == 0x26008c0e)
- s = "Creative SB16 PnP";
- else if (vend_id2 == 0x42008c0e)
- s = "Creative SB32 (CTL0042)";
- else if (vend_id2 == 0x44008c0e)
- s = "Creative SB32 (CTL0044)";
- else if (vend_id2 == 0x48008c0e)
- s = "Creative SB32 (CTL0048)";
- else if (vend_id2 == 0x49008c0e)
- s = "Creative SB32 (CTL0049)";
- else if (vend_id2 == 0xf1008c0e)
- s = "Creative SB32 (CTL00f1)";
- break;
- case 0x42008c0e: /* Creative SB AWE64 (CTL00c1) */
- if (vend_id2 == 0xc1008c0e)
- s = "Creative SB AWE64 (CTL00c1)";
- break;
- case 0x45008c0e: /* Creative SB AWE64 (CTL0045) */
- if (vend_id2 == 0xe4008c0e)
- s = "Creative SB AWE64 (CTL0045)";
- break;
+ {0x630e, "CS423x"},
+#endif
+ {0x01008c0e, "Creative ViBRA16C PnP"},
+ {0x43008c0e, "Creative ViBRA16X PnP"},
+ {0x31008c0e, "Creative SB16 PnP/SB32"},
+ {0x42008c0e, "Creative SB AWE64"}, /* CTL00c1 */
+ {0x45008c0e, "Creative SB AWE64"}, /* CTL0045 */
#if notdef
- case 0x0121: /* Avance Logic */
- if (vend_id2 == 0x20009305)
- s = "Avance Logic ALS120";
- break;
- case 0x0111: /* Avance Asound */
- if (vend_id2 == 0x10009305)
- s = "Avance Asound 110";
- break;
- case 0x68187316: /* ESS1868 */
- if (vend_id2 == 0x68007316)
- s = "ESS ES1868 Plug and Play AudioDrive";
- break;
- case 0x79187316: /* ESS1879 */
- if (vend_id2 == 0x79007316)
- s = "ESS ES1879 Plug and Play AudioDrive";
- break;
- case 0x2100a865: /* Yamaha */
- if (vend_id2 == 0x2000a865)
- s = "Yamaha OPL3-SA2/SAX Sound Board";
- break;
- case 0x80719304: /* Terratec */
- if (vend_id2 == 0x1114b250)
- s = "Terratec Soundsystem Base 1";
- break;
- case 0x0300561e: /* Gravis */
- if (vend_id2 == 0x0100561e)
- s = "Gravis UltraSound Plug Play";
- break;
-#endif /* notdef */
- }
-
- if (s != NULL) {
- device_set_desc(dev, s);
-
- /* PCM Audio */
- func = malloc(sizeof(struct sndcard_func), M_DEVBUF, M_NOWAIT);
- if (func == NULL)
- return (ENOMEM);
- bzero(func, sizeof(*func));
- func-func = SCF_PCM;
- device_add_child(dev, "pcm", -1, func);
+ {0x0121, "Avance Logic ALS120"},
+ {0x0111, "Avance Asound 110"},
+ {0x68187316, "ESS ES1868 Plug and Play AudioDrive"}, /* ESS1868 */
+ {0x79187316, "ESS ES1879 Plug and Play AudioDrive"}, /* ESS1879 */
+ {0x2100a865, "Yamaha OPL3-SA2/SAX Sound Board"},
+ {0x80719304, "Terratec Soundsystem
Re: Route table leaks
In article [EMAIL PROTECTED], Garrett Wollman [EMAIL PROTECTED] wrote: On Fri, 26 Nov 1999 17:41:49 -0800 (PST), John Polstra [EMAIL PROTECTED] said: The route disappears from the routing table, but it is not freed. (The Leak.) Actually, no. Now cause some packets to travel on the connection. A new cloned route is created and added to the routing table. Here is where the leak happens, as demonstrated by your patch. By "The Leak" I meant the moment when a routing table entry becomes unreferenced without being freed. But it's not worth arguing about. (Great detective work, BTW.) Thanks! I definitely learned a lot about the routing code. :-) 1. Do I really need the splnet calls around RTFREE? I don't think so. All calls into the routing code should already be protected by splnet. Good -- that's what I was hoping you'd say. I'll go over all the calls, and if I'm reasonably convinced that they're already at splnet then I'll test it for awhile without the hopefully-redundant splnet calls. I ran it that way here at home on a very lightly loaded system for a day or so without problems. But that doesn't prove much. We may have to revisit this in the future for finer-grained locking. Good point. 2. To eliminate all the duplicated code, shall I make rtalloc just call rtalloc_ign(ro, 0UL)? I assume that was avoided originally for performance reasons, but now there's more code than before. Actually, it was avoided originally because it was easier to just cut and paste. There is no inherent reason for the duplication, although Matt's suggestion of topologically sorting the routines so that GCC will have a chance at inlining is not a bad one. Thanks, that makes me feel better. (I'd actually like to find all the calls to rtalloc() and simply add an extra argument to them. I can't fathom why I didn't do that five years ago) I'm just wondering how much of a "standard" kernel API rtalloc() is. I.e., might 3rd-party drivers call it? The only one I have a copy of is the driver from ET Inc., and it doesn't call any of the routing functions. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
: I guess only if you do have a PIII and are using the new instructions. : In most cases this has no effect whatsoever. Not counting the : significant code size increase. : :It's also useful for properly aligning doubles on the stack. I would have :expected the most generally efficient way to align doubles and the new PIII :obkects to be aligning the stack only in functions that have such objects :on the stack. This requires at most one extra instruction: : : andl $~0xf,$esp 16-byte alignment : :Bruce It would be better for GCC to force alignment only within those procedures that need it rather then force all procedures to guarentee alignment. Then we could have the best of both worlds. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 04:52:33PM -0700, Warner Losh wrote:
It would help me if you could send me your patches...
Well, here's all I've got. It's basically just a sloppy version of
what you suggested.
Index: pccard.c
===
RCS file: /usr/local/ncvs/freebsd/src/sys/pccard/pccard.c,v
retrieving revision 1.93
diff -u -r1.93 pccard.c
--- pccard.c1999/11/20 05:01:59 1.93
+++ pccard.c1999/12/01 02:33:52
@@ -177,8 +177,10 @@
disable_slot(struct slot *slt)
{
device_t pccarddev;
+ device_t *kids;
+ int nkids;
struct pccard_devinfo *devi;
- int i;
+ int i, ret;
/*
* Unload all the drivers on this slot. Note we can't
@@ -191,14 +193,26 @@
* driver is accessing the device and it is removed, then
* all bets are off...
*/
- pccarddev = devclass_get_device(pccard_devclass, 0);
- for (devi = slt-devices; devi; devi = devi-next) {
- if (devi-isahd.id_device != 0) {
- device_delete_child(pccarddev, devi-isahd.id_device);
- devi-isahd.id_device = 0;
- }
+ pccarddev = devclass_get_device(pccard_devclass, slt-slotnum);
+ device_get_children(pccarddev, kids, nkids);
+ printf("pccard: %d kids\n", nkids);
+ for (i = 0; i nkids; i++) {
+ printf("pccard: deleting kid %d\n", i);
+ if (ret=device_delete_child(pccarddev, kids[i]))
+ printf("pccard: delete kid %d failed: %d\n", i, ret);
}
+ /* for (devi = slt-devices; devi; devi = devi-next) {
+ printf("pccard: considering delete\n");
+ if (devi-isahd.id_device != 0) {
+ printf("pccard: doing the delete\n");
+ if (device_delete_child(pccarddev, devi-isahd.id_device))
+ printf("pccard: device_delete_child failed\n");
+ devi-isahd.id_device = 0;
+ }
+ }
+ */
+ printf("pccard: ready to power off\n");
/* Power off the slot 1/2 second after removal of the card */
slt-poff_ch = timeout(power_off_slot, (caddr_t)slt, hz / 2);
slt-pwr_off_pending = 1;
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : On Tue, Nov 30, 1999 at 04:52:33PM -0700, Warner Losh wrote: : It would help me if you could send me your patches... : : Well, here's all I've got. It's basically just a sloppy version of : what you suggested. OK. This should help. I'll see if I can make it suck less. I'm not sure what to do about drivers that are sleeping in some routine or another when they are ejected, but at least I'll make sure taht teh detach happens at spl0, if it isn't already... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc_r.so.3 and compat3x
that it requires libc_r.so.3; unfortunately, compat3x does not contain this lib. Any chance of having it added to compat3x? Yes. The PR is assigned to me, but David already has it on his TODO list. Compat3x is updated late to make sure the latest libraries are in. Until 3.4-REL (when libc*.so.3 will be added to compat3x), you can download the bin.?? files from a 3-STABLE snapshot and grab them. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new MAKEDEV and the second CDROM
On a freebsd-current box there is a second scsi-cdrom (a cd-writer working fine with cdrecord). I remade the devices with MAKEDEV, everything is new, but there is nothing new like cd1c ... Looking at the source the minor number of cd0c has to be increased by 8. -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://ES-i2.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
On Wed, 1 Dec 1999, Dmitrij Tejblum wrote: Bruce Evans wrote: I would have expected the most generally efficient way to align doubles and the new PIII obkects to be aligning the stack only in functions that have such objects j on the stack. This requires at most one extra instruction: andl $~0xf,$esp 16-byte alignment % I think, it's not that simple in the usual case when the object is accessed via (%ebp-someconstant). %ebp would have to be aligned relative to %esp, but this would require an unusal function prologue with possible complications in debuggers, and seems to require 2 or 3 more extra instructions to recover the original %esp: pushl %ebp movl %esp,%eax # extra andl $0xf,%esp # extra movl %esp,%ebp pushl %eax # extra ... # worst case: no registers saved, no local space ... # allocated, and no alloca() allowance movl -4(%ebp),%esp # extra popl %ebp ret If the caller has passed a double, then the stack alignment can be determined at compile time and the current subl-type adjustment can be used. If alloca() is not allowed for, then %esp-relative accesses can be used for auto and temporary variables, and %ebp-relative accesses for args. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Christopher Masto writes: : Well, here's all I've got. It's basically just a sloppy version of : what you suggested. I've cleaned this up, worked it around, and managed to insert and eject my ep card 5 times in a row on my desktop kludge environment. It even appeared to be working. Don't know if this will work on a real laptop, but it is better than nothing. I specifically didn't set the suspend/resume code, and it is a different code path. I suspect to still see some hangs, but in the 1-2% range not the 100+% range on suspend due to the racing nature of things. I found another problem with the ep/ed driver's detach routines. They called if_down rather than if_detach. This left them in the list of interfaces, but they were really really gone for good at this point, so when the automatic ifconfig that I have on my machine ran, it paniced the system. I've not tried to fix the sc-gone functionality in the drivers that need it. Nor have I tested anything except the pccard ep driver. I'm too tired for that, and I hope I haven't made anything worse. I've committed these changes to -current for your enjoyment. Please let me know if you have problems with them on real hardware. Warner "Pining for the Fjords[*]" Losh [*] This norse word is pronounced "Sony VAIO" around here :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
