Re: [PATCH] note the __sF change in src/UPDATING
M. Warner Losh said: > In message: <[EMAIL PROTECTED]> > "Steven G. Kargl" <[EMAIL PROTECTED]> writes: > : M. Warner Losh said: > : > In message: <[EMAIL PROTECTED]> > : > "Steven G. Kargl" <[EMAIL PROTECTED]> writes: > : > : Could someone add the following patch to UPDATING? > : > : Change the words to whatever suits your fancy. > : > > : > I'm trying to devise a good way to deal with this breakage and hope it > : > is transient. I'm not hopeful :-( I'll consider adding this to UPDATING. > : > > : > : Any user who installed DP1 and a bunch of ports will > : have a unpleasant experience when they update to > : post 20021031 sources. All their ports will stop > : working and it isn't a simple matter to update > : those ports. > > I thought DP1 didn't generate binaries or libraries that contained > __sF. > http://www.freebsd.org/releases/5.0R/schedule.html DP1 was released on 5 Apr 2002. This may have occurred during Peter's last attempt at killing __sF. DP2 is in progress according to the web page and __sF should not be present. There will also be that group of -current users who lag a few weeks behind in their buildworlds. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]> "Steven G. Kargl" <[EMAIL PROTECTED]> writes: : M. Warner Losh said: : > In message: <[EMAIL PROTECTED]> : > "Steven G. Kargl" <[EMAIL PROTECTED]> writes: : > : Could someone add the following patch to UPDATING? : > : Change the words to whatever suits your fancy. : > : > I'm trying to devise a good way to deal with this breakage and hope it : > is transient. I'm not hopeful :-( I'll consider adding this to UPDATING. : > : : Any user who installed DP1 and a bunch of ports will : have a unpleasant experience when they update to : post 20021031 sources. All their ports will stop : working and it isn't a simple matter to update : those ports. I thought DP1 didn't generate binaries or libraries that contained __sF. However, the warning likely is needed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
M. Warner Losh said: > In message: <[EMAIL PROTECTED]> > "Steven G. Kargl" <[EMAIL PROTECTED]> writes: > : Could someone add the following patch to UPDATING? > : Change the words to whatever suits your fancy. > > I'm trying to devise a good way to deal with this breakage and hope it > is transient. I'm not hopeful :-( I'll consider adding this to UPDATING. > Any user who installed DP1 and a bunch of ports will have a unpleasant experience when they update to post 20021031 sources. All their ports will stop working and it isn't a simple matter to update those ports. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: <[EMAIL PROTECTED]> "Steven G. Kargl" <[EMAIL PROTECTED]> writes: : Could someone add the following patch to UPDATING? : Change the words to whatever suits your fancy. I'm trying to devise a good way to deal with this breakage and hope it is transient. I'm not hopeful :-( I'll consider adding this to UPDATING. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why is my -current system Hard Locking?
--On Wednesday, November 06, 2002 9:23 PM -0600 Sean Kelly <[EMAIL PROTECTED]> wrote: . . . snip . . . I just came across this problem for the first time on my -CURRENT from Wed Oct 30. I was in the middle of reading a message in mutt (my MUA) on the console and the system just froze. I was also cvsup'ing ports on another vty at the time. There was no way to get a dump or backtrace. Nothing, including networking, was responding. Here are a few things you might want to try: 1. Check your syslog to get an estimate of when the machine dies. Is itduring high disk activity? Mine did it during a ports cvsup. Could it bedoing it in relation to the /etc/security stuff? Does it happen aroundthe same times every day? The harder I press the system, the greater the odds of the lockup. A buildworld and other stuff will eventually crash. 2. Build a kernel with GDB_REMOTE_CHAT and try a remote gdb session againstthe kernel? Not sure how much information this will provide, since themachine will most likely stop responding to the remote gdb. 3. Figure out when the problem started happening for the first time and seewhat was commit'd around then. I've hooked up a serial console and am going to try forcing a NMI via the ISA IOCHK pin. . . . snip . . . -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: What is user uucp good for?
In message: <[EMAIL PROTECTED]> David Gilbert <[EMAIL PROTECTED]> writes: : > "M" == M Warner Losh <[EMAIL PROTECTED]> writes: : : M> In message: <[EMAIL PROTECTED]> Ceri Davies : M> <[EMAIL PROTECTED]> writes: : For that matter, do we still : M> need xten, a user who has been pushed so far : to the edge of : M> obscurity that it's home directory doesn't even exist on a : : M> freshly installed system (and I'm not talking about /nonexistent). : : M> For a long time I was a devender of xten, but my hardware is dead, : M> and the original author, who is my boss, wouldn't morn the passing : M> of it at all... : : Add to that: recent x10 hardware that I've bought has worked with : standard serial w/o special x10 drivers. Simple python (or perl) : scripts reading the serial port are sufficient to talk to it. : : IIRC, the x10 computer interface was $19.95 or so. That might have : included shipping. It's even fully bidirectional. The drivers in the tree aren't for the serial versions, but these old things that interfaced to the parallel port... I have the newer serial stuff, and it doesn't use the x10 stuff in the tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[current] Re: What is user uucp good for?
> "M" == M Warner Losh <[EMAIL PROTECTED]> writes: M> In message: <[EMAIL PROTECTED]> Ceri Davies M> <[EMAIL PROTECTED]> writes: : For that matter, do we still M> need xten, a user who has been pushed so far : to the edge of M> obscurity that it's home directory doesn't even exist on a : M> freshly installed system (and I'm not talking about /nonexistent). M> For a long time I was a devender of xten, but my hardware is dead, M> and the original author, who is my boss, wouldn't morn the passing M> of it at all... Add to that: recent x10 hardware that I've bought has worked with standard serial w/o special x10 drivers. Simple python (or perl) scripts reading the serial port are sufficient to talk to it. IIRC, the x10 computer interface was $19.95 or so. That might have included shipping. It's even fully bidirectional. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
This is Getting Along31466
If your interested in putting your product or service in front of millions of prospective clients or buyers READ ON! What is the most cost effective form of advertising for the very small all the way up to the largest of companies? Commercial Email! Why? Because there is no charge for paper, printing, mailing or the unbelievabley HIGH COST of putting Ads into Magazines or Papers. Why should most of your advertising dollar go for overhead? There IS a BETTER way! How? By placing your ad directly into the e-mail boxes of consumers who, like you, have an Internet e-mail address. Almost every user of the Internet has a unique e-mail address and we can effectively reach as many of those people as you want FAST and EFFECTIVELY. Every year the number of users increases tremendously creating a huge market. Why not become part of this unlimited market by placing your personal ad in one of the largest consumer databases? We are interested in doing business with you, however, we DO NOT do pornography or schemes of any kind. Please call us with your legitimate product or service. Some of you may not be interested at all, and possibly are agitated by our message. We will respectfully remove you from our list by request. We are responsible commercial e-mailers and don't want to bother those who are not interested. We not only respect you, but also our customers. We do not want our customers spending their advertising dollars on prospects that do not have any interest. (Decline instructions are at the end of this letter.) Below you will find basic mailing options we are offering at this time. Check out our SPECIALS! Commercial Email Gets Results! Untargeted mailings: 1,000,000 E-mails for U.S $500.00 2,000,000 E-mails for U.S $900.00 3,000,000 E-mails for U.S $1200.00 4,000,000 E-mails for U.S $1400.00 For Professional Advertising Campaigns at Affordable Prices Call 818-743-7507 By utilizing our resources and technology we have achieved our goal of making advertising affordable and effective on the Internet. We hope that you will choose our company to help you in attaining your companies goals. This message is an advertisement. We will continue to bring you valuable permission based messages on the products and services that interest you most unless you wish to decline. If you no longer wish to receive our messages send a e-mail to: mailto:mxrly@;yahoo.com?subject=expunge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why is my -current system Hard Locking?
On Mon, Nov 04, 2002 at 07:56:49PM -0800, Joel M. Baldwin wrote: > I'm getting quite frustrated with -current. I've been running it > for years and had relatively few problems. However for quite some > time now I've had a problem with Hard Locks. By Hard Lock I mean > that the system doesn't respond to ether traffic, the keyboard > doesn't respond, the capslock, numlock, and scroll lock keys do > nothing, the corresponding LEDs don't light, and ctrl/alt/del > doesn't reboot the system. The only out is to hit reset. I > don't think this is related to the X FP problem ( although I am > running X11 ). There have been many times when I'd walk in the > morning and find the system had been down for hours. As I > understand the X FP problem, it is a transient that shouldn't take > the system down all night. I just came across this problem for the first time on my -CURRENT from Wed Oct 30. I was in the middle of reading a message in mutt (my MUA) on the console and the system just froze. I was also cvsup'ing ports on another vty at the time. There was no way to get a dump or backtrace. Nothing, including networking, was responding. Here are a few things you might want to try: 1. Check your syslog to get an estimate of when the machine dies. Is it during high disk activity? Mine did it during a ports cvsup. Could it be doing it in relation to the /etc/security stuff? Does it happen around the same times every day? 2. Build a kernel with GDB_REMOTE_CHAT and try a remote gdb session against the kernel? Not sure how much information this will provide, since the machine will most likely stop responding to the remote gdb. 3. Figure out when the problem started happening for the first time and see what was commit'd around then. Incidentally, I've also noticed that my machine freezes on reboots. When I panic or when I issue a system reboot, my kernel never actually manages to reboot the system. It hardlocks after showing the system uptime. I've even tried turning ACPI off in the BIOS and it still does it. My boot messages here: http://www.zombie.org/edgemaster.dmesg My kernel config here: http://www.zombie.org/edgemaster.kernel -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree
On Wed, 2002-11-06 at 18:34, Horen wrote: > > Posted a week ago the question, didn't get any reaction. > > Everything with current from last night works fine but killing > X or logging out ends in a black screen. No way to activate the > display without reboot. Remote login is fine. Typing blind works > too. How long has this been going on? Did it start at any particular point (a specific kernel or XFree86 upgrade)? What video card do you use? Does starting X again not work? -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree
On Wed, Nov 06, 2002 at 09:34:39PM -0500, Horen wrote: > > Posted a week ago the question, didn't get any reaction. > > Everything with current from last night works fine but killing > X or logging out ends in a black screen. No way to activate the > display without reboot. Remote login is fine. Typing blind works > too. > > Is there a fix in sight, would be great help. > I just rebuilt world and XFree86 4.2.1. I killed and restarted X several times while getting my fvwm2 desktop back to normal. I didn't have this black screen problem. How old is your X and desktop? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
Thanks, Juli. After update make, I can build without any trouble. From: Juli Mallett <[EMAIL PROTECTED]> Subject: Re: buildworld failure Date: Wed, 6 Nov 2002 08:07:39 -0800 > Update your make(1). -- Masaaki Kimbara <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
Steve Kargl wrote: > > Any chance we could get rid of all externally visable symbols that > > are not defined as being there by some standard, and not just __sF, > > since we are breaking the FORTRAN compiler and other third party > > code already? > > This isn't restricted to my Fortran 95 problem, which I've > found an acceptable work-around. I just spent the better > part of a day re-installing 122 ports because these ports were > linked against an earlier libc. All of this is 3rd party > software. But, if you have a pre-20021031 world and you > build only a post-20021021 libc, then a whole bunch of > libraries in /usr/lib will becomed unusable. I'm more concerned about this happening again, the next time someone decides another symbol shouldn't be exposed. If we could get the pain over with all at once, that'd be a good thing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree
Posted a week ago the question, didn't get any reaction. Everything with current from last night works fine but killing X or logging out ends in a black screen. No way to activate the display without reboot. Remote login is fine. Typing blind works too. Is there a fix in sight, would be great help. Thanks, -Horen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Updated targ(4) - need testers
I have updated the new scsi_target driver and fixed a bug in -current that now allows it to work as well as the -stable version. I haven't gotten any feedback so I would love it if someone could download this and test it. All comments welcome, even about the included manpages. All you need to test it are a PC and a dual bus (or two single bus) ahc(4) or isp(4) card(s). Versions for -stable and -current at: http://www.root.org/~nate/freebsd/ -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What is user uucp good for?
On Wed, Nov 06, 2002 at 05:57:22PM -0700, Lyndon Nerenberg wrote: > >> Maybe future generations will wonder what it is named after > >> similarly to GCOS field in passwd today :-) > > > >At the very least we should change the shell. But Kris' suggestions > >sound the best. > > I agree. But more importantly, let's make sure that we don't, by > removing the uucp login, make it difficult for people to continue to run > programs that need dialer access. Note that I never suggested removing the uucp login (for precisely this reason). Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
perl5.6.1 wrapper
Can someone explain why the perl wrapper needs to be hardlinked to perl5.6.1? The problem I am seeing is this: USE_PERL5=yes in a port adds the following BUILD_DEPENDS: enigma# make -V BUILD_DEPENDS perl5.6.1:/usr/ports/lang/perl5 However 5.0 has perl5.6.1 in the base system still, so this dependency is always satisfied, the perl port is never added and the port build that relies on it will fail. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What is user uucp good for?
>> Maybe future generations will wonder what it is named after >> similarly to GCOS field in passwd today :-) > >At the very least we should change the shell. But Kris' suggestions >sound the best. I agree. But more importantly, let's make sure that we don't, by removing the uucp login, make it difficult for people to continue to run programs that need dialer access. If we remove uucp from the password file we need to ensure that UUCP, installed from the ports tree, will continue to work with the new device ownerships and permissions. In theory Taylor UUCP will work with only 'dialer' group access to the tty* and cua* devices, but this does need to be verified before nuking the uucp password file entry. OTOH, I don't see a pressing need to nuke the uucp login. Nothing breaks by leaving it in place, and third-party code assumes it exists (things that want to mess with modems, like FAX software). It makes more sense to (perhaps) mention 'uucp' is a deprecated login, but until *BSD defines an "official" interface to the dialer devices, it would be premature to remove the existing de-facto interface to them (think /var/spool/lock, and uu_lock(3)). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Wed, Nov 06, 2002 at 04:38:55PM -0800, Terry Lambert wrote: > "Steven G. Kargl" wrote: > > Could someone add the following patch to UPDATING? > > Change the words to whatever suits your fancy. > > +20021031 > > + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static. > > + This changes the visibility of __sF to a symbol internal to > > + libc. All applications linked against libc or a library that > > + depends on libc that were compiled prior to 31 Oct 2002 will > > + need to be updated after a "make world". An error message that > > + includes "undefined reference to `__sF'" is an indication that > > + that application needs to be recompiled. > > + > > > Any chance we could get rid of all externally visable symbols that > are not defined as being there by some standard, and not just __sF, > since we are breaking the FORTRAN compiler and other third party > code already? > This isn't restricted to my Fortran 95 problem, which I've found an acceptable work-around. I just spent the better part of a day re-installing 122 ports because these ports were linked against an earlier libc. All of this is 3rd party software. But, if you have a pre-20021031 world and you build only a post-20021021 libc, then a whole bunch of libraries in /usr/lib will becomed unusable. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
"Steven G. Kargl" wrote: > Could someone add the following patch to UPDATING? > Change the words to whatever suits your fancy. > +20021031 > + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static. > + This changes the visibility of __sF to a symbol internal to > + libc. All applications linked against libc or a library that > + depends on libc that were compiled prior to 31 Oct 2002 will > + need to be updated after a "make world". An error message that > + includes "undefined reference to `__sF'" is an indication that > + that application needs to be recompiled. > + Any chance we could get rid of all externally visable symbols that are not defined as being there by some standard, and not just __sF, since we are breaking the FORTRAN compiler and other third party code already? It would be nice if this only ever happened *once*. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] note the __sF change in src/UPDATING
Could someone add the following patch to UPDATING? Change the words to whatever suits your fancy. -- Steve http://troutmask.apl.washington.edu/~kargl/ --- UPDATING.orig Wed Nov 6 16:20:05 2002 +++ UPDATINGWed Nov 6 16:27:08 2002 @@ -17,6 +17,15 @@ developers choose to disable these features on build machines to maximize performance. +20021031 + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static. + This changes the visibility of __sF to a symbol internal to + libc. All applications linked against libc or a library that + depends on libc that were compiled prior to 31 Oct 2002 will + need to be updated after a "make world". An error message that + includes "undefined reference to `__sF'" is an indication that + that application needs to be recompiled. + 20021029: The value of IPPROTO_DIVERT has changed. Make sure to keep your kernel, netstat, natd and any third-party DIVERT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why is my -current system Hard Locking?
"Joel M. Baldwin" wrote: > Is there a way in HARDWARE to FORCE a break into ddb? > ^ If you have an open ISA port, a flat-bladed screwdriver, and a Bic lighter, you can cause an NMI that the debugger can trap... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Nov 6 15:09:54 PST 2002 -- >>> Kernel build for GENERIC completed on Wed Nov 6 15:42:19 PST 2002 -- >>> Kernel build for LINT started on Wed Nov 6 15:42:19 PST 2002 -- ===> vinum "Makefile", line 4516: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Upgrade of port audio/id3lib - stdc++ wchar support missing
Hi, there two open PR's (PR 44423 and PR 9) related to a problem with audio/id3lib. I downloaded the new version (3.8.1) and made patches for some files, so they should work fine with FreeBSD 5.0 (4.7 not tested, I think gcc3 is required). But I found out, that the libstdc++ which is installed by `make world` doesn't have wchar-support enabled. I do not have expirience in changing modules within freebsd world, so what do I have to do to add wchar-support? Any help would be nice - I didn't had so much time for C/C++ programming last year and I missed it. So I could do some more, too. Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Some problems with Orinoco card in -CURRENT
(One note on this dmesg output, the detach and following attach is as you might guess me ejecting and reinserting the card. The previous mail and this was sent via the Orinoco card.. :) OLDCARD dmesg will follow tomorrow, gotta hit the sack...) On Wed, 2002-11-06 at 23:45, Frode Nordahl wrote: > Hey, > > On Wed, 2002-11-06 at 23:28, M. Warner Losh wrote: > > Strange. OLDCARD or NEWCARD? Send me a full dmesg for each case, > > since it is likely some resource conflict or another. I do what > > you've described hundreds of times over the past few months, so it has > > to be something weird with your computer. > > My computer might be wierd :) I have a problem with the BIOS not > initializing the memory correctly (I often see dmesg output and post > morten messages from previous boot). > > So I even did a __cold__ reboot (unplug AC, remove battery for a while) > before this dmesg (boot -v). > > I only hav NEWCARD kernel available at this time, will post a OLDCARD > boot -v ASAP. > > (See attachment) > > > Warner. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > Copyright (c) 1992-2002 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #2: Mon Nov 4 14:23:41 CET 2002 > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SAMWISE > Preloaded elf kernel "/boot/kernel/kernel" at 0xc05bc000. > Preloaded elf module "/boot/kernel/snd_via82c686.ko" at 0xc05bc0b4. > Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc05bc168. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05bc214. > Calibrating clock(s) ... TSC clock: 1193637253 Hz, i8254 clock: 1193135 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz > CLK_USE_TSC_CALIBRATION not specified - using old calibration method > Timecounter "TSC" frequency 1193693787 Hz > CPU: Pentium III/Pentium III Xeon/Celeron (1193.69-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 > >Features=0x383f9ff > real memory = 234881024 (229376K bytes) > Physical memory chunk(s): > 0x1000 - 0x0009efff, 647168 bytes (158 pages) > 0x005e3000 - 0x0dee, 227594240 bytes (55565 pages) > 0x0df0 - 0x0dff7fff, 1015808 bytes (248 pages) > avail memory = 221925376 (216724K bytes) > bios32: Found BIOS32 Service Directory header at 0xc00f7290 > bios32: Entry = 0xfd6f0 (c00fd6f0) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xfd6f0+0x11e > pnpbios: Found PnP BIOS data at 0xc00f72f0 > pnpbios: Entry = f:97e0 Rev = 1.0 > Other BIOS signatures found: > Initializing GEOMetry subsystem > null: > random: > mem: > Pentium Pro MTRR support enabled > VESA: information block > 56 45 53 41 00 02 73 80 00 c0 01 00 00 00 22 00 > 00 01 ef 01 00 01 57 79 00 c0 68 79 00 c0 70 79 > 00 c0 00 01 01 01 03 01 05 01 07 01 0e 01 0f 01 > 11 01 12 01 14 01 15 01 17 01 18 01 1a 01 1b 01 > VESA: 39 mode(s) found > VESA: v2.0, 31680k memory, flags:0x1, mode table:0xc04c36a2 (122) > VESA: S3 Incorporated. Twister BIOS > VESA: S3 Incorporated. VBE 2.0 Rev 1.1 > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > pci_open(1): mode 1 addr port (0x0cf8) is 0x80003904 > pci_open(1a): mode1res=0x8000 (0x8000) > pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=06051106) > Using $PIR table, 8 entries at 0xc00fdf40 > PCI-Only Interrupts: none > Location Bus Device Pin Link IRQs > embedded00A 0x56 3 4 5 6 7 9 10 11 12 14 15 > embedded00B 0x56 3 4 5 6 7 9 10 11 12 14 15 > embedded00C 0x57 3 4 5 6 7 9 10 11 12 14 15 > embedded00D 0x55 3 4 5 6 7 9 10 11 12 14 15 > embedded07C 0x56 5 > embedded07D 0x57 11 > embedded04A 0x55 10 > embedded04B 0x56 11 > embedded0 13A 0x56 5 > embedded01A 0x55 10 > embedded10A 0x55 10 > embedded0 16A 0x57 11 > embedded0 16B 0x56 11 > embedded0 17A 0x56 11 > embedded0 17B 0x57 11 > acpi0: power button is handled as a fixed feature programming model. > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > ACPI timer looks GOOD min = 1, max = 2, width = 2 > Timecounter "ACPI-fast" frequency 3579545 Hz > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > acpi_cpu0: on ac
Re: Why is my -current system Hard Locking?
on the keyboard still will make the console go to the debugger, even when console is on another device (e.g. serial port) if that doesn't help, then I have no idea.. On Wed, 6 Nov 2002, Joel M. Baldwin wrote: > > No change, the system is still Hard Locking. It did it > 4 times yesterday. The next steps for me are: > > 1.) Get a serial console working. Maybe I'll get some > indication of what's happening that way. > 2.) When the serial console is working, see if I can > break into ddb after a Hard Lock. > > Is there a way in HARDWARE to FORCE a break into ddb? > ^ > > Maybe I can tell if the system is running, where it is > running, and how it got there. > > > 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
i810 hang: more info
I have found additional information that may be useful regarding the hard hang I have been experiencing. Details were present in a previous message but here is a short summary. I have two of the exact same boxes (even same HD). They are i810 mobos with a Celeron 500 and 128MB ram and a 10GB IDE hard drive. One runs -stable and one runs -current. The -stable box has never crashed but the -current one used to hang every night (power light off, numlock stuck on). I swapped memory, drives, etc. -- same result: only the -current box would crash. I disabled ACPI and the -current box would stay up for a few days to a week before hanging. Now I removed the IDE hard drive and replaced it with a SCSI one and a Adaptec 2940 U2W HBA. Not only is the IO much faster but it has run for weeks without a hang. I would appreciate it if someone could help me look into this further. Are there known problems with this ATA chipset? It was running at UDMA33. * Swapping all hardware with the -stable box doesn't change anything * Disabling ACPI helps it run ~1 week before hanging * Swapping SCSI drive for IDE keeps it from hanging (at least for a few weeks) -Nate Old dmesg: (w/ ATA drive) Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 498486405 Hz CPU: Pentium II/Pentium II Xeon/Celeron (498.49-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 real memory = 133103616 (129984K bytes) avail memory = 124231680 (121320K bytes) pcib0: at pcibus 0 on motherboard pci0: on pcib0 atapci0: port 0x1800-0x180f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 8297MB [16858/16/63] at ata0-master UDMA33 atapci0@pci0:31:1: class=0x010180 card=0x24118086 chip=0x24118086 rev=0x02 hdr=0x00 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard state after ACPI resume
> In message: <010501c285dc$87da1170$[EMAIL PROTECTED]> > "Matthew Emmerton" <[EMAIL PROTECTED]> writes: > : This also happens with my an0 card, so it's probably a larger ACPI + PCCARD > : interoperability issue. > > Its a ACPI issue. We do the right things in the drivers and bridge > drivers. Do the cards detach/attach? If not, then you aren't really > suspending. I don't see them attaching/detaching, so I guess my laptop is just lying to me. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why is my -current system Hard Locking?
No change, the system is still Hard Locking. It did it 4 times yesterday. The next steps for me are: 1.) Get a serial console working. Maybe I'll get some indication of what's happening that way. 2.) When the serial console is working, see if I can break into ddb after a Hard Lock. Is there a way in HARDWARE to FORCE a break into ddb? ^ Maybe I can tell if the system is running, where it is running, and how it got there. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Some problems with Orinoco card in -CURRENT
Hey, On Wed, 2002-11-06 at 23:28, M. Warner Losh wrote: > Strange. OLDCARD or NEWCARD? Send me a full dmesg for each case, > since it is likely some resource conflict or another. I do what > you've described hundreds of times over the past few months, so it has > to be something weird with your computer. My computer might be wierd :) I have a problem with the BIOS not initializing the memory correctly (I often see dmesg output and post morten messages from previous boot). So I even did a __cold__ reboot (unplug AC, remove battery for a while) before this dmesg (boot -v). I only hav NEWCARD kernel available at this time, will post a OLDCARD boot -v ASAP. (See attachment) > Warner. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Mon Nov 4 14:23:41 CET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SAMWISE Preloaded elf kernel "/boot/kernel/kernel" at 0xc05bc000. Preloaded elf module "/boot/kernel/snd_via82c686.ko" at 0xc05bc0b4. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc05bc168. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05bc214. Calibrating clock(s) ... TSC clock: 1193637253 Hz, i8254 clock: 1193135 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 1193693787 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1193.69-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383f9ff real memory = 234881024 (229376K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x005e3000 - 0x0dee, 227594240 bytes (55565 pages) 0x0df0 - 0x0dff7fff, 1015808 bytes (248 pages) avail memory = 221925376 (216724K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f7290 bios32: Entry = 0xfd6f0 (c00fd6f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6f0+0x11e pnpbios: Found PnP BIOS data at 0xc00f72f0 pnpbios: Entry = f:97e0 Rev = 1.0 Other BIOS signatures found: Initializing GEOMetry subsystem null: random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 73 80 00 c0 01 00 00 00 22 00 00 01 ef 01 00 01 57 79 00 c0 68 79 00 c0 70 79 00 c0 00 01 01 01 03 01 05 01 07 01 0e 01 0f 01 11 01 12 01 14 01 15 01 17 01 18 01 1a 01 1b 01 VESA: 39 mode(s) found VESA: v2.0, 31680k memory, flags:0x1, mode table:0xc04c36a2 (122) VESA: S3 Incorporated. Twister BIOS VESA: S3 Incorporated. VBE 2.0 Rev 1.1 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=06051106) Using $PIR table, 8 entries at 0xc00fdf40 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded00A 0x56 3 4 5 6 7 9 10 11 12 14 15 embedded00B 0x56 3 4 5 6 7 9 10 11 12 14 15 embedded00C 0x57 3 4 5 6 7 9 10 11 12 14 15 embedded00D 0x55 3 4 5 6 7 9 10 11 12 14 15 embedded07C 0x56 5 embedded07D 0x57 11 embedded04A 0x55 10 embedded04B 0x56 11 embedded0 13A 0x56 5 embedded01A 0x55 10 embedded10A 0x55 10 embedded0 16A 0x57 11 embedded0 16B 0x56 11 embedded0 17A 0x56 11 embedded0 17B 0x57 11 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 2 Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_cpu0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.PIB_.LNKA irq 10: [ 10] low,level,sharable 0.1.0 \\_SB_.PCI0.PIB_.LNKA irq 10: [ 10] low,level,sharable 0.4.0 \\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.4.1 \\_SB_.PCI0.PIB_.LNKA irq 10: [ 10] low,level,sharable 0.7.0 \\_SB_.PCI0.PIB_.LNKB irq 11: [ 11] low,level,sharable 0.7.1 \\_SB_.PCI0.PIB_.LNKC irq 5: [ 5 9 10 11] low,level,sharable 0.7.2 \\_
Re: pccard state after ACPI resume
In message: <[EMAIL PROTECTED]> Frode Nordahl <[EMAIL PROTECTED]> writes: : On Wed, 2002-11-06 at 23:38, M. Warner Losh wrote: : > : wi0 detaches and reattaches here (both in sleep state 1 and 3). : > : > OK. OLDCARD or NEWCARD? My laptop still doesn't suspend/resume : > correctly, so I've been unable to test patches. : : NEWCARD OK. I'll see if I can get my laptop happy with suspending again. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard state after ACPI resume
On Wed, 2002-11-06 at 23:38, M. Warner Losh wrote: > : wi0 detaches and reattaches here (both in sleep state 1 and 3). > > OK. OLDCARD or NEWCARD? My laptop still doesn't suspend/resume > correctly, so I've been unable to test patches. NEWCARD > Warner Mvh, Frode Nordahl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard state after ACPI resume
In message: <[EMAIL PROTECTED]> Frode Nordahl <[EMAIL PROTECTED]> writes: : On Wed, 2002-11-06 at 23:22, M. Warner Losh wrote: : > In message: <010501c285dc$87da1170$[EMAIL PROTECTED]> : > "Matthew Emmerton" <[EMAIL PROTECTED]> writes: : > : This also happens with my an0 card, so it's probably a larger ACPI + PCCARD : > : interoperability issue. : > : > Its a ACPI issue. We do the right things in the drivers and bridge : > drivers. Do the cards detach/attach? If not, then you aren't really : > suspending. : : wi0 detaches and reattaches here (both in sleep state 1 and 3). OK. OLDCARD or NEWCARD? My laptop still doesn't suspend/resume correctly, so I've been unable to test patches. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
Josef Karthauser wrote: > > On Wed, Nov 06, 2002 at 10:43:50PM +0100, Bernd Walter wrote: > > On Wed, Nov 06, 2002 at 09:33:16PM +, Josef Karthauser wrote: > > > > If it's inside the docking station I would assume that it's powered. > > > > Agreed - I had overread this detail. > > > > > On my machine with an external hub I do get messages about power budget > > > being exceeded so it's probably not that. > > > > That's a design issue. > > Some ports implement overcurrent protection by self healing fuses. > > Others do not even that. > > I've seen many awfull cheap implementations. > > > > Btw.: > > I had seen similar problems with a self build device on some ports. > > It turned out to be a problem with the device oscillator to not > > properly work under some conditions. > > Hmm, ok. Then this is the most likely explanation then. i doubt. both Linux and Windows have no problem with the device. everything else is the *same* (laptop, docking station, etc). do USB dumps make any sense? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard state after ACPI resume
On Wed, 2002-11-06 at 23:22, M. Warner Losh wrote: > In message: <010501c285dc$87da1170$[EMAIL PROTECTED]> > "Matthew Emmerton" <[EMAIL PROTECTED]> writes: > : This also happens with my an0 card, so it's probably a larger ACPI + PCCARD > : interoperability issue. > > Its a ACPI issue. We do the right things in the drivers and bridge > drivers. Do the cards detach/attach? If not, then you aren't really > suspending. wi0 detaches and reattaches here (both in sleep state 1 and 3). > Warner > > 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: Some problems with Orinoco card in -CURRENT
Strange. OLDCARD or NEWCARD? Send me a full dmesg for each case, since it is likely some resource conflict or another. I do what you've described hundreds of times over the past few months, so it has to be something weird with your computer. Warner. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard state after ACPI resume
In message: <010501c285dc$87da1170$[EMAIL PROTECTED]> "Matthew Emmerton" <[EMAIL PROTECTED]> writes: : This also happens with my an0 card, so it's probably a larger ACPI + PCCARD : interoperability issue. Its a ACPI issue. We do the right things in the drivers and bridge drivers. Do the cards detach/attach? If not, then you aren't really suspending. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Wed, Nov 06, 2002 at 10:43:50PM +0100, Bernd Walter wrote: > On Wed, Nov 06, 2002 at 09:33:16PM +, Josef Karthauser wrote: > > If it's inside the docking station I would assume that it's powered. > > Agreed - I had overread this detail. > > > On my machine with an external hub I do get messages about power budget > > being exceeded so it's probably not that. > > That's a design issue. > Some ports implement overcurrent protection by self healing fuses. > Others do not even that. > I've seen many awfull cheap implementations. > > Btw.: > I had seen similar problems with a self build device on some ports. > It turned out to be a problem with the device oscillator to not > properly work under some conditions. Hmm, ok. Then this is the most likely explanation then. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg46190/pgp0.pgp Description: PGP signature
Re: What is user uucp good for?
On Tuesday, 5 November 2002 at 21:57:50 +0100, Marcin Cieslak wrote: > Kris Kennaway ([EMAIL PROTECTED]) napisa?(a): >> On Sat, Nov 02, 2002 at 04:11:39PM +1030, Greg 'groggy' Lehey wrote: >> A number of base system utilities and ports still use it for access to >> the serial port devices (which are owned by the uucp user). Really, >> the uucp user is now misnamed and should be called something like > > Let's leave it like it is. > > Maybe future generations will wonder what it is named after > similarly to GCOS field in passwd today :-) At the very least we should change the shell. But Kris' suggestions sound the best. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Wed, Nov 06, 2002 at 09:33:16PM +, Josef Karthauser wrote: > On Wed, Nov 06, 2002 at 01:00:43PM -0800, Maksim Yevmenkin wrote: > > Bernd, > > > > Who owns USB code in -current? I need an USB expert advice > > > > on the FreeBSD specific USB problem. Basically whenever i > > > > put my laptop into docking station and try to plug Bluetooth > > > > USB dongle i get > > > > > > > > uhub1: device problem, disabling port 1 > > > > > > Is you usb hub really self powered as it claims to be? > > > If it is not the problem you are seeing is not surprising. > > > > the hub (the TI one) is the inside docking station. i've > > no idea if its self powered or not. how can i check it? > > > > If it's inside the docking station I would assume that it's powered. Agreed - I had overread this detail. > On my machine with an external hub I do get messages about power budget > being exceeded so it's probably not that. That's a design issue. Some ports implement overcurrent protection by self healing fuses. Others do not even that. I've seen many awfull cheap implementations. Btw.: I had seen similar problems with a self build device on some ports. It turned out to be a problem with the device oscillator to not properly work under some conditions. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard state after ACPI resume
> Hello, > > Another problem with my Orinoco card is that after a resume from (ACPI) > sleep, the configuration set on the card is lost, so I have to set the > ssid, wepkey etc again before it can operate properly. > > I am not sure if this is a flaw in the wi0 driver (probably not) or > something missing in general for all cards. > > As of right now I do not have any other pccards available to check if > this happens to other cards. > > What should be responsible for reconfiguring cards on resume? Should > this be remembered by each individual driver or some other part of the > kernel, or should this be done by userland programs? (apmd, acpid) This also happens with my an0 card, so it's probably a larger ACPI + PCCARD interoperability issue. Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Wed, Nov 06, 2002 at 01:00:43PM -0800, Maksim Yevmenkin wrote: > Bernd, > > > > Who owns USB code in -current? I need an USB expert advice > > > on the FreeBSD specific USB problem. Basically whenever i > > > put my laptop into docking station and try to plug Bluetooth > > > USB dongle i get > > > > > > uhub1: device problem, disabling port 1 > > > > Is you usb hub really self powered as it claims to be? > > If it is not the problem you are seeing is not surprising. > > the hub (the TI one) is the inside docking station. i've > no idea if its self powered or not. how can i check it? > If it's inside the docking station I would assume that it's powered. On my machine with an external hub I do get messages about power budget being exceeded so it's probably not that. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg46186/pgp0.pgp Description: PGP signature
acpid implementation?
Hello, I have been searching mailing lists and my friend Google for information about a acpid (like apmd) implementation for FreeBSD, but I have found nothing. Does one exist anywhere, or has anyone started out on something without telling anyone? :) Mvh, Frode Nordahl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pccard state after ACPI resume
Hello, Another problem with my Orinoco card is that after a resume from (ACPI) sleep, the configuration set on the card is lost, so I have to set the ssid, wepkey etc again before it can operate properly. I am not sure if this is a flaw in the wi0 driver (probably not) or something missing in general for all cards. As of right now I do not have any other pccards available to check if this happens to other cards. What should be responsible for reconfiguring cards on resume? Should this be remembered by each individual driver or some other part of the kernel, or should this be done by userland programs? (apmd, acpid) Mvh, Frode Nordahl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Some problems with Orinoco card in -CURRENT
Hello, I now have a Orinoco card to play with :) (I have not given up on the CNet yet, though) It works great with the wi0 driver, and they have together provided me with hours of wireless computing! :) However, if the card is inserted before turning on the computer, operations on the card freezes the computer for about a minute and failes. (ifconfig wi0 ssid blah wepmode on wepkey 0xblah) This also happens sometimes after resuming from sleep (ACPI). If the card is inserted after boot-up, there is no problem. Orinoco Gold PC24E-H-FC Apparently it's a 5V 16bit card. I have not tested the behaviour under OLDCARD. wi0 messages: wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: init failed wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0001; event status 0x wi0: timeout in wi_cmd 0x000a; event status 0x wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: timeout in wi_cmd 0x000a; event status 0x wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed wi0: timeout in wi_cmd 0x0002; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: init failed wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0001; event status 0x wi0: timeout in wi_cmd 0x000a; event status 0x wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: timeout in wi_cmd 0x000a; event status 0x wi0: failed to allocate 1594 bytes on NIC wi0: mgmt. buffer allocation failed wi0: timeout in wi_cmd 0x0002; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: init failed wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0121; event status 0x wi0: timeout in wi_cmd 0x0001; event status 0x wi0: timeout in
Re: uuid.h is not C++ safe
Neither is devinfo.h. The attached patch should fix it. - alex --- devinfo.h.orig Wed Nov 6 13:03:22 2002 +++ devinfo.h Wed Nov 6 13:04:37 2002 @@ -27,6 +27,9 @@ * $FreeBSD: src/lib/libdevinfo/devinfo.h,v 1.4 2002/09/20 02:16:33 imp Exp $ */ +#ifndef _DEVINFO_H +#define _DEVINFO_H + #include #include @@ -77,6 +80,8 @@ /* XXX add flags */ }; +__BEGIN_DECLS + /* * Acquire a coherent copy of the kernel's device and resource tables. * This must return success (zero) before any other interfaces will @@ -136,3 +141,6 @@ extern int devinfo_foreach_rman(int (* fn)(struct devinfo_rman *rman, void *arg), void *arg); +__END_DECLS + +#endif /* _DEVINFO_H */
Re: Netgraph and KQUEUE(2)
In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : Ok but there cound be netgraph nodes that have no hardware but could be : called into creation by some external event. : e.g. a netgraph hook on a pseudointerface like gif or tun. : (not at present but a possibility I was looking at last week) There's an API that one could expose that would allow these sorts of things to be passed to devd. If it is a true interface, then one can discover that with routing announcements, iirc. I'd personally like to see all things in the kernel in the device tree, but there's some good reasons that this might be a touch too radical. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netgraph and KQUEUE(2)
On Wed, Nov 06, 2002 at 12:48:07PM -0800, Julian Elischer wrote: > > Ok but there cound be netgraph nodes that have no hardware but could be > called into creation by some external event. > e.g. a netgraph hook on a pseudointerface like gif or tun. > (not at present but a possibility I was looking at last week) ng_gif already exists and is in the tree. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg46180/pgp0.pgp Description: PGP signature
Re: USB problem (Who owns USB code in -current?)
Bernd, > > Who owns USB code in -current? I need an USB expert advice > > on the FreeBSD specific USB problem. Basically whenever i > > put my laptop into docking station and try to plug Bluetooth > > USB dongle i get > > > > uhub1: device problem, disabling port 1 > > Is you usb hub really self powered as it claims to be? > If it is not the problem you are seeing is not surprising. the hub (the TI one) is the inside docking station. i've no idea if its self powered or not. how can i check it? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netgraph and KQUEUE(2)
On Wed, 6 Nov 2002, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Julian Elischer <[EMAIL PROTECTED]> writes: > : > : > : On Wed, 6 Nov 2002, M. Warner Losh wrote: > : > : > : 1) Device driver in Netgraph node. When hardware is > : > :activated new Netgraph node is created and new > : > :kevent sent. devd (or something like devd) listens > : > :for these events and does something (loads firmware, > : > :activates device, etc.) > : > > : > Device drivers are not netgraph nodes. They will have a device_t > : > associated with them, which already sends a message via /dev/devctl to > : > devd. You can do anything you want with the results. There's no need > : > to reinvent the wheel that I'm almost done inventing. There's > : > absolutely no need to bring netgraph into it all, and doing so makes > : > it a less generic implementation. > : > : devices that are netgraph nodes may not have any entry in /dev > : and might only appear in the netgraph namespace.. > : e.g. if_ar.c if_sr.c > > It doesn't matter. *ALL* devices have device_t entries. Recall that > device_t is not dev_t. dev_t appears in /dev/. Hardware devices have > to attach to some bus. That's why devd is done in newbus land rather > than in dev_t land. Ok but there cound be netgraph nodes that have no hardware but could be called into creation by some external event. e.g. a netgraph hook on a pseudointerface like gif or tun. (not at present but a possibility I was looking at last week) > > Warner > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM/libdisk problem on pc98
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>In message: <[EMAIL PROTECTED]>
>Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
>: In message <[EMAIL PROTECTED]>, Takahashi Yoshihiro
>: writes:
>: >The test program for libdisk is a failure in pc98 disks.
>: >
>: >I wonder at why pc98 disks don't have their type ('ty') in the result
>: >of kern.geom.conftxt, but i386 disks have.
>:
>: I still have practically no documentation of the PC98 format and no
>: hardware I can test on, so I am pretty unable to do anything sane.
>
>I have translated some Japanese docs that I was able to find, through
>the kind assistance of kawanobe-san. I took a trip to the local
>technical library, but the articles he pointed me at were unavailable.
>I'll be happy to continue to translate docs that help explain the
>format.
The stuff you sent me was absolutely a big help, despite the fact that
only one or two of the disk-images people have sent me were actually
in compliance with that document, at least it validated what I did
on those.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: machine check on AS2100A
Hi All
OK I completed a new non-SMP kernel (the GENERIC kernel with SMP
commented out)
built using 4.6.2 and ran installkernel KERNCONF=TOMZBOX10. The newer
bootblocks
and loader having been already installed.
The non-smp 5.0-CURRENT kernel chokes at the exact same point as before:
FreeBSD/alpha SRM disk boot, Revision 1.2
([EMAIL PROTECTED], Tue Oct 29 02:44:25 MST 2002)
Memory 262144 k
Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0x44bc70+0x672c0 syms=[0x8+0x5ee90+0x8+0x48e16]
Hit {Enter} to boot immediatly, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Entering /boot/kernel/kernel at 0xfc33e580...
sio1: gdb debugging port
Copyright (c) 1992-2002 The FreeBSD Project
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Wed Nov 6 11:12:40 MST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TOMZBOX10
Preloaded elf kernel "/boot/kernel/kernel" at 0xfc85e000.
DEC AlphaServer 2100A 4/275, 274MHZ
8192 byte page size, 4 processors.
CPU: EV45 (21064A) major=6 minor=2
OSF PAL rev: 0x4000c0002012d
real memory = 266264576 (260024K bytes)
avail memory = 250675200 (244800K bytes)
Initializing GEOMetry subsystem
t20: using interupt type 1 on pci bus 0
t20:
pci0 on pcib0
eisab0: at device 2.0 on pci0
isa0: on eisab0
pcib1: at device 3.0 on pci0
pci2: on pcib1
unexpected machine check:
mces = 0x1
vector = 0x660
param = 0xfc006000
pc = 0xfc64b888
ra = 0xfc64b83c
curproc= 0xfc75fd50
pid= 0, comm = swapper
stopped at t2_pcib_read_config=0x3e8: or zero,s3,v0
0,s3=0x,v0=0x7>
db> trace
t2_pcib_read_config() at t2_pcib_read_config+0x3e8
pcib_read_config() at pcib_read_config+0xcc
pci_read_device() at pci_read_device+0xb4
pci_add_children() at pci_add_children+0xf8
pci_attach() at pci_attach+0xd8
device_probe_and_attach() at device_probe_and_attach+0xc8
bus_generic_attach() at bus_generic_attach+0x28
pcib_attach() at pcib_attach+0x68
device_probe_and_attach() at _device_probe_and_attach+0xc8
bus_generic_attach() at bus_generic_attach+0x28
pci_attach() at pci_attach+0xe4
device_probe_and_attach() at device_probe_and_attach+0xc8
bus_generic_attach() at bus_generic_attach+0x28
device_probe_and_attach() at device_probe_and_attaxh+0xc8
bus_generic_attach() at bus_generic-attach+0x28
t2_attach() at t2_attach+0x6c
device_probe_and-attach() at device_probe_and_attach+0xc8
root_bus_configure() at root_bus_configure+0x38
configure() at configure+0x40
mi_startup() at mi_startup+0x144
locorestart() at locorestart+0x64
--- root of call graph ---
This is almost identical to the SMP kernel
Anything I can do to help just ask!!
Cheers
Tom
Andrew Gallatin wrote:
Tom Ponsford writes:
> Hi All,
>
> I'm getting a machine check on my new-toy: an Alphaserver 2100A 4/275 RM.
>
> It boots and runs 4.6.2 fine with a single cpu. But after I supped the
> current 5.0 sources from
> 10/29/2002 17:39 and did a buildworld and a Generic buildkernel, (plus
> all the
> other steps in UPDATING with the exception of installing world) But after an
> installkernel, I get a machine check, just after the kernel loads and boots.
>
Can you build a non-SMP kernel and see if that boots please?
Nobody has ever run an SMP kernel on a 2100A, AFAIK. The 2100A has
problems with multiple machine checks being reported for each machine
check triggered. I wonder if you're getting a machine check for each
CPU. Hmmm..
Drew
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: Netgraph and KQUEUE(2)
In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : : : On Wed, 6 Nov 2002, M. Warner Losh wrote: : : > : 1) Device driver in Netgraph node. When hardware is : > :activated new Netgraph node is created and new : > :kevent sent. devd (or something like devd) listens : > :for these events and does something (loads firmware, : > :activates device, etc.) : > : > Device drivers are not netgraph nodes. They will have a device_t : > associated with them, which already sends a message via /dev/devctl to : > devd. You can do anything you want with the results. There's no need : > to reinvent the wheel that I'm almost done inventing. There's : > absolutely no need to bring netgraph into it all, and doing so makes : > it a less generic implementation. : : devices that are netgraph nodes may not have any entry in /dev : and might only appear in the netgraph namespace.. : e.g. if_ar.c if_sr.c It doesn't matter. *ALL* devices have device_t entries. Recall that device_t is not dev_t. dev_t appears in /dev/. Hardware devices have to attach to some bus. That's why devd is done in newbus land rather than in dev_t land. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Mon, Nov 04, 2002 at 10:33:24AM -0800, Maksim Yevmenkin wrote: > Dear Hackers, > > Who owns USB code in -current? I need an USB expert advice > on the FreeBSD specific USB problem. Basically whenever i > put my laptop into docking station and try to plug Bluetooth > USB dongle i get > > uhub1: device problem, disabling port 1 Is you usb hub really self powered as it claims to be? If it is not the problem you are seeing is not surprising. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
Josef, > > > > This problem is FreeBSD-specific and seems related to > > > > Bluetooth USB dongles only. I have been contacted by other > > > > people who have the same problem. I do not know what is so > > > > special about Bluetooth USB dongles. USB mouse, for example, > > > > works fine. Can it be power related? Both Windows and > > > > Linux do not have this problem which makes me think that > > > > there is something different about FreeBSD way of doing > > > > things. > > > > > > Compile the kernel with 'option USB_DEBUG' and then tweak the hw.usb > > > sysctls to get debug output for your controller, the usb stack and the > > > uhub. Maybe this will shed some light on the problem. > > > > i *did* compile my kernel with USB_DEBUG and *did* tweak > > sysctl's. i even attached the dump to my previous message. > > I didn't see the dump, just the output of usbdevs. Maybe I missed it. > > > it seems there is some kind of communication error on the > > bus and stack can not get device descriptor. i need to know > > what might cause these communication errors. > > It's got to be a bug in the uhub area. You said that it works ok if the > device is plugged in directly? > > What I'd like to see is the output with: > > hw.*.usb.debug=50 > hw.*.uhub.debug=50 i set all sysctl's to 99 and put the all the dumps at http://www.geocities.com/m_evmenkin/usb/ may be attachment was too big for the list. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netgraph and KQUEUE(2)
On Wed, 6 Nov 2002, M. Warner Losh wrote: > : 1) Device driver in Netgraph node. When hardware is > :activated new Netgraph node is created and new > :kevent sent. devd (or something like devd) listens > :for these events and does something (loads firmware, > :activates device, etc.) > > Device drivers are not netgraph nodes. They will have a device_t > associated with them, which already sends a message via /dev/devctl to > devd. You can do anything you want with the results. There's no need > to reinvent the wheel that I'm almost done inventing. There's > absolutely no need to bring netgraph into it all, and doing so makes > it a less generic implementation. devices that are netgraph nodes may not have any entry in /dev and might only appear in the netgraph namespace.. e.g. if_ar.c if_sr.c > > Warner > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM/libdisk problem on pc98
It seems M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
> : In message <[EMAIL PROTECTED]>, Takahashi Yoshihiro
> : writes:
> : >The test program for libdisk is a failure in pc98 disks.
> : >
> : >I wonder at why pc98 disks don't have their type ('ty') in the result
> : >of kern.geom.conftxt, but i386 disks have.
> :
> : I still have practically no documentation of the PC98 format and no
> : hardware I can test on, so I am pretty unable to do anything sane.
>
> I have translated some Japanese docs that I was able to find, through
> the kind assistance of kawanobe-san. I took a trip to the local
> technical library, but the articles he pointed me at were unavailable.
> I'll be happy to continue to translate docs that help explain the
> format.
Could you mail me a copy as well please ?
It seems that GEOM works on PC98 with the ATA driver, but I'm still
having stability problems so they are not in -current yet...
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GEOM/libdisk problem on pc98
In message: <[EMAIL PROTECTED]>
Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
: In message <[EMAIL PROTECTED]>, Takahashi Yoshihiro
: writes:
: >The test program for libdisk is a failure in pc98 disks.
: >
: >I wonder at why pc98 disks don't have their type ('ty') in the result
: >of kern.geom.conftxt, but i386 disks have.
:
: I still have practically no documentation of the PC98 format and no
: hardware I can test on, so I am pretty unable to do anything sane.
I have translated some Japanese docs that I was able to find, through
the kind assistance of kawanobe-san. I took a trip to the local
technical library, but the articles he pointed me at were unavailable.
I'll be happy to continue to translate docs that help explain the
format.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
Josef, > > This problem is FreeBSD-specific and seems related to > > Bluetooth USB dongles only. I have been contacted by other > > people who have the same problem. I do not know what is so > > special about Bluetooth USB dongles. USB mouse, for example, > > works fine. Can it be power related? Both Windows and > > Linux do not have this problem which makes me think that > > there is something different about FreeBSD way of doing > > things. > > Compile the kernel with 'option USB_DEBUG' and then tweak the hw.usb > sysctls to get debug output for your controller, the usb stack and the > uhub. Maybe this will shed some light on the problem. i *did* compile my kernel with USB_DEBUG and *did* tweak sysctl's. i even attached the dump to my previous message. it seems there is some kind of communication error on the bus and stack can not get device descriptor. i need to know what might cause these communication errors. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
Update your make(1). * De: Masaaki Kimbara <[EMAIL PROTECTED]> [ Data: 2002-11-06 ] [ Subjecte: buildworld failure ] > I cvsup current, but I have trouble building world as followings > Please advice me about building-world. > Thanks. > .. > .. > > c++ -O -pipe -DHAVE_CONFIG_H >-I/usr/src/gnu/usr.bin/groff/src/utils/tfmtodit/../../../../../../contrib/groff/src/include > -I/usr/src/gnu/usr.bin/groff/src/utils/tfmtodit/../../../src/include >-D__FBSDID=__RCSID -fno-rtti -fno-exceptions -static -o tfmtodit tfmtodit.o >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/groff/src/utils/tfmtodit/../../../src/libs/libgroff/libgroff.a > -lm > ===> gnu/usr.bin/groff/tmac > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for >target "-s" ignored > make: don't know how to make doc-common-s. Stop > *** Error code 2 > > Stop in /usr/src/gnu/usr.bin/groff. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > Am I only one person who trouble building world ? > > -- > Masaaki > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld failure
I cvsup current, but I have trouble building world as followings Please advice me about building-world. Thanks. .. .. c++ -O -pipe -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/utils/tfmtodit/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/utils/tfmtodit/../../../src/include -D__FBSDID=__RCSID -fno-rtti -fno-exceptions -static -o tfmtodit tfmtodit.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/groff/src/utils/tfmtodit/../../../src/libs/libgroff/libgroff.a -lm ===> gnu/usr.bin/groff/tmac "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored "/usr/src/gnu/usr.bin/groff/tmac/Makefile", line 2: warning: duplicate script for target "-s" ignored make: don't know how to make doc-common-s. Stop *** Error code 2 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Am I only one person who trouble building world ? -- Masaaki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sshd: double "Last login:" bugfix spammed again
Old bugfix for double "Last login:" was spammed in 3rd time, causing following printout: zzz@xxx's password: Last login: Wed Nov 6 17:12:40 from Last login: Wed Nov 6 17:10:08 2002 from Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 ... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP broken on PPro
Thus spake Glenn Johnson <[EMAIL PROTECTED]>: > > I have had no trouble with UP -STABLE running on a dual PPro system, > > but I'm getting an early panic in UP and SMP -CURRENT on the same > > system. I will post details to current@ soon if I can't figure out > > the problem. > > The problem on -STABLE is with /sys/i386/i386/machdep.c, revision > 1.385.2.26. I am not smart enough to know exactly what is wrong > with the diff but reverting back to revision 1.385.2.25 of > /sys/i386/i386/machdep.c fixes the problem. Aah yes, this is an MFC of revision 1.544, which broke -CURRENT as well. The patch should probably be un-MFC'd until a better solution is found. The old code said: 1) set up some PTEs for the BIOS just before the 640K mark if the BIOS may be using that space 2) call int 15 function E820 to get the memory map from the BIOS The new code reverses the order of these operations, so it causes a segfault in the BIOS interrupt handler. I recall a thread about this change on current@ a little while ago, but I forget exactly what problem it was supposed to solve. As for the fix, I'm not a PC BIOS expert, but I don't see any reason why it's necessary to call 15:E820 *before* good old int12, which ought to work on any BIOS dating back to the original PC-XT. If there's some problem I don't know about, I should note that the machine that triggers this bug for me works fine on the first 15:E820 call but not the second. If other BIOSes behave similarly, one possible fix would be to interpret the return value from the first 15:E820 call specially, e.g. if (smap->base == 0 && smap->length < 640*1024) set up some PTEs for the gap; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: time counter / time ticking or hardware issues
On Wed, Nov 06, 2002 at 01:26:31PM +0100, Sameh Ghane wrote: > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 332755591 Hz > CPU: AMD-K6(tm) 3D processor (332.76-MHz 586-class CPU) > Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 > Features=0x8021bf > AMD Features=0x8800 There seem to be a family of K6 motherboards on which the ACPI timecounter runs fast by a factor of about two. I've been seeing this since ACPI became the default on one motherboard. I get around it by using the TSC instead: sysctl kern.timecounter.hardware=TSC David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Mon, Nov 04, 2002 at 10:33:24AM -0800, Maksim Yevmenkin wrote: > > This problem is FreeBSD-specific and seems related to > Bluetooth USB dongles only. I have been contacted by other > people who have the same problem. I do not know what is so > special about Bluetooth USB dongles. USB mouse, for example, > works fine. Can it be power related? Both Windows and > Linux do not have this problem which makes me think that > there is something different about FreeBSD way of doing > things. > Compile the kernel with 'option USB_DEBUG' and then tweak the hw.usb sysctls to get debug output for your controller, the usb stack and the uhub. Maybe this will shed some light on the problem. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg46163/pgp0.pgp Description: PGP signature
time counter / time ticking or hardware issues
Hi! I experienced (I think it corresponds to the last big phk's changes in the time counter handling) issues with my clock on current. It just ticks twice too fast. To know if it comes from the hardware clock or the kernel, I attached my dmesg.boot. The issue can be shortened to this: core:[~]>time sleep 5 0.000u 0.002s 0:09.96 0.0% 0+0k 0+0io 0pf+0w This might help debugging: core:[~]>sysctl kern.timecounter ; sleep 5 && echo ; sysctl kern.timecounter kern.timecounter.nbinuptime: 157435124 kern.timecounter.nnanouptime: 3 kern.timecounter.nmicrouptime: 0 kern.timecounter.nbintime: 1703138 kern.timecounter.nnanotime: 34 kern.timecounter.nmicrotime: 1703104 kern.timecounter.ngetbinuptime: 0 kern.timecounter.ngetnanouptime: 41327 kern.timecounter.ngetmicrouptime: 15327675 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 15900 kern.timecounter.ngetmicrotime: 49512577 kern.timecounter.hardware: ACPI-safe kern.timecounter.tick: 1 kern.timecounter.nbinuptime: 157436469 kern.timecounter.nnanouptime: 3 kern.timecounter.nmicrouptime: 0 kern.timecounter.nbintime: 1703158 kern.timecounter.nnanotime: 34 kern.timecounter.nmicrotime: 1703124 kern.timecounter.ngetbinuptime: 0 kern.timecounter.ngetnanouptime: 41329 kern.timecounter.ngetmicrouptime: 15327831 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 15900 kern.timecounter.ngetmicrotime: 49513102 kern.timecounter.hardware: ACPI-safe kern.timecounter.tick: 1 I tried 3 different -current kernels since phk's first commit, all having this behavior. I don't remember how old my kernel is, it's Thu Dec 5 23:49:20 CET 2002 here :) If it's hardawre related, where is the best place in the kernel to just slow it down by a factor of 2 ? Cheers, -- Sameh Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #5: Fri Nov 29 06:15:17 CET 2002 [EMAIL PROTECTED]:/var/obj/var/src/sys/CORE Preloaded elf kernel "/boot/kernel/kernel" at 0xc053f000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc053f0a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 332755591 Hz CPU: AMD-K6(tm) 3D processor (332.76-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 real memory = 134201344 (131056K bytes) avail memory = 124436480 (121520K bytes) Initializing GEOMetry subsystem K6-family MTRR support enabled (2 registers) npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 8 entries at 0xc00f0b40 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.0 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.1 \\_SB_.LNKC irq 5: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.2 \\_SB_.LNKD irq 3: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.12.3 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.0 \\_SB_.LNKC irq 5: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.1 \\_SB_.LNKD irq 3: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.2 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.11.3 \\_SB_.LNKC irq 5: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.0 \\_SB_.LNKD irq 3: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.1 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.2 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.10.3 \\_SB_.LNKD irq 3: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.0 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.1 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.2 \\_SB_.LNKC irq 5: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.9.3 \\_SB_.LNKD irq 3: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.0 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.1 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.2 \\_SB_.LNKC irq 5: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.13.3 \\_SB_.LNKE irq 0: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.0 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.1 \\_SB_.LNKB irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.2.2 \\_SB_.LNKC irq 5: [ 1 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Nov 6 03:06:55 PST 2002 -- >>> Kernel build for GENERIC completed on Wed Nov 6 03:36:44 PST 2002 -- >>> Kernel build for LINT started on Wed Nov 6 03:36:45 PST 2002 -- ===> vinum "Makefile", line 4523: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What is user uucp good for?
On Wed, Nov 06, 2002 at 04:23:38AM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Ceri Davies <[EMAIL PROTECTED]> writes: > : For that matter, do we still need xten, a user who has been pushed so far > : to the edge of obscurity that it's home directory doesn't even exist on a > : freshly installed system (and I'm not talking about /nonexistent). > > For a long time I was a devender of xten, but my hardware is dead, and > the original author, who is my boss, wouldn't morn the passing of it > at all... Murder! Ceri [Good sig monster, you have served me well] -- Your destruction awaits! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What is user uucp good for?
In message: <[EMAIL PROTECTED]> Ceri Davies <[EMAIL PROTECTED]> writes: : For that matter, do we still need xten, a user who has been pushed so far : to the edge of obscurity that it's home directory doesn't even exist on a : freshly installed system (and I'm not talking about /nonexistent). For a long time I was a devender of xten, but my hardware is dead, and the original author, who is my boss, wouldn't morn the passing of it at all... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netgraph and KQUEUE(2)
: 1) Device driver in Netgraph node. When hardware is :activated new Netgraph node is created and new :kevent sent. devd (or something like devd) listens :for these events and does something (loads firmware, :activates device, etc.) Device drivers are not netgraph nodes. They will have a device_t associated with them, which already sends a message via /dev/devctl to devd. You can do anything you want with the results. There's no need to reinvent the wheel that I'm almost done inventing. There's absolutely no need to bring netgraph into it all, and doing so makes it a less generic implementation. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the status of devfs(8)?
In message: <[EMAIL PROTECTED]> "Andrew Lankford" <[EMAIL PROTECTED]> writes: : but /dev/devctl is in my /dev (devfs) partition. /dev/devctl has nothing to do with devfs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
In message: <[EMAIL PROTECTED]> Tim Kientzle <[EMAIL PROTECTED]> writes: : Several people have pointed out that FreeBSD has : certain protections against LD_LIBRARY_PATH exploits, : but there are still real questions here. (Kernel : races, possibly?) Privilege elevation is an : interesting idea, but tricky to audit. There are no known issues in this area, and haven't been for a couple of years now. While this isn't proof, it is a compelling argument. This isn't a real question, to be honest. We've had dynamically linked setuid/setgid programs for years. The only issues have been in the setuid/setgid code itself, not the dynamic linker. Bugs of this nature haven't really been a problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
