Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote: I hate this whole direction. I think it's an incredibly bad idea that we are not going to be able to reproduce what went onto any given CDROM in ten years. The source will be on the CDROM. Nor is there any major importance to DP1. Are you also upset that you cannot reproduce the July 17th, 1998 -CURRENT snapshot CD from WC? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sat, 2002-03-16 at 21:53, David O'Brien wrote: On Sat, Mar 16, 2002 at 04:43:47PM +0200, Maxim Sobolev wrote: primary goals in all of this are (1) to provide a usable preview of the 5.0-CURRENT code, and (2) to minimize the impact on -CURRENT developers. After evaluating several different options, using Perforce was deemed the best tool for the job. Could we have commit logs from the commits into that branch be sent to cvs-all, because otherwise most of the developers would be unable to see what's going on there, which IMO is not a good thing. Why do we care? I already see the logs for -current. I don't really care what the RE's have to do in their branch to add the release-related things. To see exactly what features and added into/removed from release. -Maxim signature.asc Description: This is a digitally signed message part
problems with perl
The perl upgrade seems to be having problems. I got this twice towday making buildworld from 4.5: thanx, brad [...] cc -O -pipe -I/usr/obj/5.0/usr/src/gnu/usr.bin/perl/miniperl -I/5.0/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5 -DPERL_EXTERNAL_GLOB -DPERL_CORE -DAPPLLIB_EXP=\/usr/libdata/perl/BSDPAN\ -L/usr/obj/5.0/usr/src/gnu/usr.bin/perl/miniperl/../libperl -static -o miniperl miniperlmain.o perl.o gv.o toke.o perly.o op.o regcomp.o dump.o util.o mg.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o universal.o xsutils.o globals.o perlio.o -lm -lcrypt -lutil pp_sys.o: In function `Perl_pp_fteread': pp_sys.o(.text+0x5f57): undefined reference to `eaccess' pp_sys.o: In function `Perl_pp_ftewrite': pp_sys.o(.text+0x6023): undefined reference to `eaccess' pp_sys.o: In function `Perl_pp_fteexec': pp_sys.o(.text+0x60ef): undefined reference to `eaccess' *** Error code 1 Stop in /5.0/usr/src/gnu/usr.bin/perl/miniperl. *** Error code 1 Stop in /5.0/usr/src. *** Error code 1 Stop in /5.0/usr/src. *** Error code 1 Stop in /5.0/usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote: I think it's an incredibly bad idea that we are not going to be able to reproduce what went onto any given CDROM in ten years. I agree that it is very important to be able to reproduce official releases of FreeBSD N years down the road. However, that has never been a requirement of snapshot CDs. We have never even tagged the tree for previous snapshots. We are actually moving more in the direction you advocate by at least moving the snapshot production into Perforce so that more developers can participate. The release engineers would prefer to do this in CVS, but that is not advisable for the reasons Peter outlined in his mail. The source distribution is included in the output of make release for a reason. If you have a technical solution to the problems that Peter raised, then I'm sure [EMAIL PROTECTED] would like to hear about them. - Murray msg36234/pgp0.pgp Description: PGP signature
Re: ACPI autoload failed -- unable to install
Folks, the autoload failed message is just telling you that you have ACPI, but there is no ACPI KLD on the floppy. It has absolutely nothing whatsoever to do with your problem. By the sound of it, you've got a corrupted floppy image. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: web Browsers (Re: gcc -O broken in CURRENT)
David O'Brien wrote:
| On Sat, Mar 16, 2002 at 06:05:13AM +0100, Dag-Erling Smorgrav wrote:
| Garrett Wollman [EMAIL PROTECTED] writes:
| What problems do you have with it?
|
| Slow. Eats memory. Crashes all the time. Does not save state
| between sessions. Does not render HTML 4 properly. Does not support
| CSS properly. Does not zoom. Does not display PNG properly.
| Incorrectly ignores cache-control headers on images. The list goes
|
| What brower available on FreeBSD does do all these things?
| Mozilla 0.9.8 was a disaster. Opera 6 is such a disaster that I went
| back to 5.05. [linux-]Netscape6 was marked BROKEN for a long time.
| konquor... well requires a lot of KDE bits to be installed.
Mozilla in all the variants I have tried is incapable of even
reliably downloading a file -- sometimes it works and sometimes
it turns it into complete junk, usually 20 Mbytes bigger than
the original. Useless.
Many of the secure sites I need to use (banks, universities,
etc.) refuse to allow access from any release 6 browser.
Linux-netscape-4.7{6,9} handles everything I want, sometimes
with minor glitches, but well enough. And I can leave it
running for weeks at a time without problems. That's good
enough for me. The alternatives that I have tried either don't
build or don't work and that means they are worse.
Greg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: web Browsers (Re: gcc -O broken in CURRENT)
On Sun, 2002-03-17 at 09:56, Greg Black wrote: Joerg Wunsch wrote: | David O'Brien [EMAIL PROTECTED] wrote: | | Slow. Eats memory. Crashes all the time. Does not save state | between sessions. Does not render HTML 4 properly. Does not support | CSS properly. Does not zoom. Does not display PNG properly. | Incorrectly ignores cache-control headers on images. The list goes | | What brower available on FreeBSD does do all these things? | | Galeon. Yeah right. Galeon wouldn't even build on the last FreeBSD box I tried it on when somebody told me to try it. It compiles/works here like a charm, however, if you do have problems with it please send a problem report to maintainers ([EMAIL PROTECTED]) and we will try to help you. -Maxim signature.asc Description: This is a digitally signed message part
Re: HEADS UP: -CURRENT Feature Slush is OVER
David O'Brien wrote: On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote: I hate this whole direction. I think it's an incredibly bad idea that we are not going to be able to reproduce what went onto any given CDROM in ten years. The source will be on the CDROM. Nor is there any major importance to DP1. Are you also upset that you cannot reproduce the July 17th, 1998 -CURRENT snapshot CD from WC? I have to say that I feel incredibly strongly about this issue, and so I'm going to argue passionately. Please bear with me... Taking your example, yes. ISO images by date should be reproducible using the date stamp. If the July 17th, 1998 -CURRENT snapshot CD from WC has things on it that didn't come as a result of merely a straight build as of a datestamp, then we've lost some of our history. In that case of that version, it's likely that if anything was done in a Mickey Mouse way, it was that the X11 distribution or some of the DOS programs or whatever were copied from another CDROM. That is, at least in theory, reproducible, though a heck of a lot more inconvenient than a list of what was done in the README.CDROM file in / on the thing would have made it. In the transient Perforce branch case, when the branch goes away, it's unreproducible completely. Any of the changes that were necessary to make the thing compile, or to back out broken code are lost. It's now inpossible to identify, from records, what the release engineers found to be broken enough that it had to be backed out or patched around, and it loses the back out and the patches. I'm not entirely sure that the resulting image will in fact be on the cdrome; even if it were, the results are not diff'able against the repository without a huge amount of manual effort. Basically, we're losing history, and, unlike the July 17th, 1998 -CURRENT snapshot CD from WC case, which is barely acceptable to lose, since it is repo + reproducible deltas, it becomes repo + unreproducible deltas. I would have liked it if a tag had been laid down immediately after the BSDCon Developer's Summit, and then moved forward or backware on a filed basis, with a branch tag at freeze equal to the moving tag, checked out, with any additional changes after the freeze done in the context of the branch tag, so that they're recoverable. It seems to me that, at worst, this is being done to prove to the heathens that use of Perforce is a bad idea. It certainly is, if history is going to be lost, but that's not a result of the tool, here, it's a result of intention. At best, Perforce is being used because the release engineers have less power over branching in the CVS repository than the core team *should* be loaning them. Either way, it's bad news when it won't be possible to reproduce an official code cut -- even if it's not a release -- from the repository. What is a repository good for, if you can't recover your history from it? The way Linux is developed, they release code that's not recoverable from a repository, ony from the release materials themselves. They have no repository because they *intentionally* have no perception of history. Actually, it's possible to lay down a tag in the past: do a checkout of the sources as of the day after the BSDCon Developer's Summit (or whatever feature freeze date is right for the preview), and then lay down a tag on the code checked out as of that timestamp. I don't understand the use of Perforce, in this case, unless it's as a strawman to try and prove all fish are trout because one fish is a trout (Perforce is a bad idea in all cases because it's a bad idea in this case). If my position is unsupportable in everyone's opinion, so be it: I would like an official policy statement on what will, guaranteed, be reproducible from the repository, when it comes to officially sanctioned distributions, like a -RELEASE CDROM, or like a Developer's Preview. In that case, I'll basically ignore anything that isn't in that list. This developer's preview, if it's not reproducible, isn't going to be delta-able, and so won't be improvable: if I have a problem with it, and fix the problem, there's not going to be a delta against the repository from which I can derive a patch for inclusion in FreeBSD going forward. If the purpose of this release is to get developers hacking on the code and fixing problems prior to 5.0-RELEASE, it *really* needs to be hackable for it to be hacked on. Otherwise, all it's going to do is be confusing when things work in the developer's pre-release because they were fixed in a now non-existant branch, and don't work in -current... NOT because the were broken in -current between the pre-release and the time they were attempted in -current, but because they NEVER worked in -current in the first place. If that's going to be the case, then I have to say that everyone will be better off if they ignore the CDROM of the Developer's pre-release, and stick with -current, since
Re: web Browsers (Re: gcc -O broken in CURRENT)
Maxim Sobolev wrote: | On Sun, 2002-03-17 at 09:56, Greg Black wrote: | Yeah right. Galeon wouldn't even build on the last FreeBSD box | I tried it on when somebody told me to try it. | | It compiles/works here like a charm, however, if you do have problems | with it please send a problem report to maintainers ([EMAIL PROTECTED]) | and we will try to help you. Thank you for the offer. At present, I don't much care whether Galeon works or not -- linux-netscape works well enough for my needs. I did not submit a problem report about galeon because I had much more serious problems on the machine in question and they needed (and still need) to be resolved first. If I can ever get anybody interested in making a version of FreeBSD later than 4.3 work on my laptop, then I'll have another look at the Galeon question, as it was for the laptop that I was trying to get it going. As it stands, 4.4, 4.5 and current all have badly broken PCMCIA support which makes them unusable. Fortunately, 4.3 does not have this breakage, but it would be a waste of time to play with galeon on such an old release. Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
Murray Stokely wrote: On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote: I think it's an incredibly bad idea that we are not going to be able to reproduce what went onto any given CDROM in ten years. I agree that it is very important to be able to reproduce official releases of FreeBSD N years down the road. However, that has never been a requirement of snapshot CDs. We have never even tagged the tree for previous snapshots. We are actually moving more in the direction you advocate by at least moving the snapshot production into Perforce so that more developers can participate. The release engineers would prefer to do this in CVS, but that is not advisable for the reasons Peter outlined in his mail. The source distribution is included in the output of make release for a reason. If you have a technical solution to the problems that Peter raised, then I'm sure [EMAIL PROTECTED] would like to hear about them. Minimally, pick a date, and then do a CVS diff against that date, and include it on the CDROM. Max wants the commit messages to the developers pre-release to go to an archived mailing list for similar reasons, it seems to me. Without the deltas against something that is fixed in the repository going forward, it's simply not going to be a useful exercise, since it's not going to be possible to make changes without a crib-sheet of how to wave the dead chicken over the source code. Erasing the crib-sheet is a really bad idea. Imagine that you have the developer's prerelease, and you have a bug (because you're a developer who's using the pre-release). Now say you have become involved in the process, because the pre-release has done it's job. You want to fix the bug. In order to do this, you are going to need the delta against the developer's prerelease source tree. To get this, the process is: 1) Before you make any changes, copy /usr/src to /usr/src.org OR mv /usr/src/usr/src.new reinstall /usr/src using /stand/sysinstall mv /usr/src /usr/src.org mv /usr/src.new /usr/src 2) Make your changes 3) Run diff -cr /usr/src/org /usr/src 4) Now, figure out how to apply these diffs to the CVSup image of the -current CVS tree for some checked-out version of -current AND Pray to God that the code your changes are in are not in code where changes were backed out or made by the release engineers for the developer's pre-release OR Install -current somewhere, with -current sources, hoping that it runs at all, and the release engineering work for the developer's prerelease was useless in your case, so that -current runs for you without trouble so that you can make your changes against -current, instead, so that it's possible to submit them back to the project and have them have meaning, in the larger scheme of things. It's really, really not happy for the CDROM to have no relevence to the developement process, if the entire purpose of the CDROM is to get more people involved in the developement process. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote: Minimally, pick a date, and then do a CVS diff against that date, and include it on the CDROM. I would be happy to do this. I checked out a copy of the CVS tree right before we made the Perforce branch so that we could tag it later if absolutely necessary. Max wants the commit messages to the developers pre-release to go to an archived mailing list for similar reasons, it seems to me. I have emailed Peter about this. I don't think the messages should go to cvs-all, because I don't think most people want to see them. But I do think that they should be available for people like Max. Max was CCed on my message to Peter. Now say you have become involved in the process, because the pre-release has done it's job. You want to fix the bug. In order to do this, you are going to need the delta against the developer's prerelease source tree. To get this, the process is: 1) Mount your DP1 CD, and view the diff. - Murray msg36241/pgp0.pgp Description: PGP signature
Re: HEADS UP: -CURRENT Feature Slush is OVER
From the keyboard of Murray Stokely: tree for previous snapshots. We are actually moving more in the direction you advocate by at least moving the snapshot production into Perforce so that more developers can participate. Not taking into account (good) technical reasons, i am quite a bit concerned about the increasing tendency to a) use private repositories instead of the one and only repository every committer is able to see and use and b) and/or use other version control systems instead of the one and only every committer is able to use. Just my 0.0002 EUR .. hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problems with perl
The perl upgrade seems to be having problems. I got this twice towday making buildworld from 4.5: Please test the enclosed patch. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn Index: config.SH-elf.alpha === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.alpha,v retrieving revision 1.24 diff -u -d -r1.24 config.SH-elf.alpha --- config.SH-elf.alpha 16 Mar 2002 21:36:07 - 1.24 +++ config.SH-elf.alpha 17 Mar 2002 09:38:49 - -138,7 +138,7 d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define' Index: config.SH-elf.i386 === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.i386,v retrieving revision 1.22 diff -u -d -r1.22 config.SH-elf.i386 --- config.SH-elf.i386 16 Mar 2002 21:36:07 - 1.22 +++ config.SH-elf.i386 17 Mar 2002 09:38:55 - -138,7 +138,7 d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define' Index: config.SH-elf.ia64 === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.ia64,v retrieving revision 1.5 diff -u -d -r1.5 config.SH-elf.ia64 --- config.SH-elf.ia64 16 Mar 2002 21:36:07 - 1.5 +++ config.SH-elf.ia64 17 Mar 2002 09:39:01 - -138,7 +138,7 d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define' Index: config.SH-elf.sparc64 === RCS file: /home/ncvs/src/gnu/usr.bin/perl/libperl/config.SH-elf.sparc64,v retrieving revision 1.6 diff -u -d -r1.6 config.SH-elf.sparc64 --- config.SH-elf.sparc64 16 Mar 2002 21:36:07 - 1.6 +++ config.SH-elf.sparc64 17 Mar 2002 09:39:07 - -138,7 +138,7 d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define'
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, 17 Mar 2002, David O'Brien wrote: On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote: I hate this whole direction. I think it's an incredibly bad idea that we are not going to be able to reproduce what went onto any given CDROM in ten years. The source will be on the CDROM. Nor is there any major importance to DP1. Are you also upset that you cannot reproduce the July 17th, 1998 -CURRENT snapshot CD from WC? If a tag was laid down can't it be retrieved indefinitely? A non-branching tag? What am I missing? Annelise -- Annelise Anderson Author of: FreeBSD: An Open-Source Operating System for Your PC Available from: BSDmall.com and amazon.com Book Website:http://www.bittreepress.com/FreeBSD/introbook/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: strange apm/acpi message on CPQ Armada E700
On Fri, Mar 15, 2002 at 11:11:45PM +0100, Wilko Bulte wrote: Never mind.. this was due to the fact that device.hints had APM disabled. Looks a lot better now: APM version: 1.2 APM Managment: Enabled AC Line status: on-line Battery status: charging Remaining battery life: 62% Remaining battery time: unknown Number of batteries: 4 Battery 0: Battery status: charging Remaining battery life: 62% Remaining battery time: 0:01:27 Battery 1: Battery status: not present Battery 2: Battery status: not present Battery 3: Battery status: not present APM Capacities: global standby state global suspend state resume timer from standby resume timer from suspend Hi I just went -current with my Compaq Armada E700 laptop. Coming from -stable. I'm a bit puzzled by: WKB ~: apm APM version: 1.2 APM Managment: Enabled AC Line status: off-line Battery status: charging Remaining battery life: invalid value (0x) Remaining battery time: unknown Number of batteries: 0 APM Capacities: unknown dmesg also has some strange things it appears Rebooting... 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: Fri Mar 15 22:48:40 CET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WILKLT Preloaded elf kernel /boot/kernel/kernel at 0xc0436000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04360a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 498669634 Hz CPU: Pentium III/Pentium III Xeon/Celeron (498.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268369920 (262080K bytes) avail memory = 256614400 (250600K bytes) Pentium Pro MTRR support enabled Using $PIR table, 268435454 entries at 0xc00f0970 npx0: math processor on motherboard npx0: INT 16 interface acpi0: COMPAQ RSDTBL on motherboard ACPI-1305: *** Error: Method execution failed, AE_AML_REGION_LIMIT acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_acad0: AC adapter on acpi0 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcic0: TI PCI-1450 PCI-CardBus Bridge mem 0x4110-0x41100fff irq 11 at device 4.0 on pci0 pcic0: TI12XX PCI Config Reg: [speaker enable][pwr save][CSC serial isa irq] pccard0: PC Card bus (classic) on pcic0 pcic1: TI PCI-1450 PCI-CardBus Bridge mem 0x4118-0x41180fff irq 11 at device 4.1 on pci0 pcic1: TI12XX PCI Config Reg: [speaker enable][pwr save][CSC serial isa irq] pccard1: PC Card bus (classic) on pcic1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0x3420-0x342f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x3400-0x341f irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pcm0: ESS Technology Maestro-2E port 0x3000-0x30ff irq 11 at device 8.0 on pci0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0x3440-0x347f mem 0x4120-0x4121,0x4128-0x41280fff irq 11 at device 9.0 on pci0 fxp0: Ethernet address 00:d0:59:0b:f3:c2 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: simple comms, UART at device 9.1 (no driver attached) orm0: Option ROMs at iomem 0xd-0xd17ff,0xc-0xc on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: enhanced floppy controller (i82077, NE72065
Re: web Browsers (Re: gcc -O broken in CURRENT)
* Greg Black ([EMAIL PROTECTED]) wrote: Joerg Wunsch wrote: Galeon. Yeah right. Galeon wouldn't even build on the last FreeBSD box I tried it on when somebody told me to try it. Tried Skipstone? Gecko based GTK browser. -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - When in charge ponder, When in doubt mumble, When in trouble delegate. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, Mar 17, 2002 at 02:13:16AM -0800, Annelise Anderson wrote: If a tag was laid down can't it be retrieved indefinitely? A non-branching tag? What am I missing? The tag will create a point in time in the CVS repository that cannot be ever changed. This is a restriction that we've always assumed does not exist on the HEAD until a .0 release. We have always been free to do repository reorganizing until the .0 release. A tag that should always produce the same thing, breaks our SOP[*] and was one of the concerns of [EMAIL PROTECTED] -- David [*] standard operating procedure To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lock warning...
* Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote: PS. I got another message that happend when I ^C'ed a buildworld earlier, with same kernel. May be it should go to Alfred Perlstein? lock order reversal 1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779 2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716 I think there's a place where the pipe can fault on an address while copying, I'll take a look at this. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote: Imagine that you have the developer's prerelease, and you have a bug (because you're a developer who's using the pre-release). Now say you have become involved in the process, because the pre-release has done it's job. You want to fix the bug. In order to do this, you are going to need the delta against the developer's prerelease source tree. To get this, the process is: 1)Before you make any changes, copy /usr/src to /usr/src.org OR mv /usr/src/usr/src.new reinstall /usr/src using /stand/sysinstall mv /usr/src /usr/src.org mv /usr/src.new /usr/src 2)Make your changes 3)Run diff -cr /usr/src/org /usr/src 4)Now, figure out how to apply these diffs to the CVSup image of the -current CVS tree for some checked-out version of -current And just HOW is this different from previous snapshot CD's? You have the source tarball w/no CVS/ directories. To fix your bug, you have to do these SAME exact steps. I see ZERO difference. You imply that maybe RE's fixed some bug in only the code for the CD and not in the CVS tree. Maybe you don't know that only pieces of bits that are CVS will be in the src tarball. Thus just like any snapshot CD source, you have to figure out if someone in has backed out a change in the CVS repo, etc.. Again, NO change from the past. Geez people. It was nice in the past when the snapshot CD's were done by a private company where none of us got to see how it was produced. Now that the process is more open, people want to try to railroad the effort. And people wonder why many companies and organization have real concerns about opening up source bases and procedures To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, Mar 17, 2002 at 12:56:42AM -0800, Terry Lambert wrote: It seems to me that, at worst, this is being done to prove to the heathens that use of Perforce is a bad idea. It certainly is, if history is going to be lost, but that's not a result of the tool, here, it's a result of intention. At best, Perforce is being used because the release engineers have less power over branching in the CVS repository than the core team *should* be loaning them. So you would like to screw the project just out of principle? I know you know enough about CVS to know the limitations that laying down this tag would have on the ability to do repository surgery. Either way, it's bad news when it won't be possible to reproduce an official code cut -- even if it's not a release -- from the repository. What is a repository good for, if you can't recover your history from it? The way Linux is developed, they release code that's not recoverable from a repository, ony from the release materials themselves. They have no repository because they *intentionally* have no perception of history. Thanks for your input. If this will be the result of DP snapshots, you've now convinced me to strongly object to them. I had reservations about us doing such an official snapshot and the impact it has on the CVS repo and developer code slush restrictions. Next time I will voice them. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel build failure in amr
Hi, Without -DNO_WERROR, i sometimes get a build failure on CURRENT sources, as shown below. However, this does not always occur, maybe 30% of the compiles succeed. Why would it sometimes compile fine? I've deleted my /usr/obj and /usr/src, and even my cvs repositry, without success.# Gavin cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundary=2 -Werror /usr/src/sys/dev/amr/amr.c cc1: warnings being treated as errors /usr/src/sys/dev/amr/amr.c: In function `amr_bio_command': /usr/src/sys/dev/amr/amr.c:817: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. epsilon# To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lock warning...
On Sun, 17 Mar 2002, Alfred Perlstein wrote: * Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote: PS. I got another message that happend when I ^C'ed a buildworld earlier, with same kernel. May be it should go to Alfred Perlstein? lock order reversal 1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779 2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716 I think there's a place where the pipe can fault on an address while copying, I'll take a look at this. Are there any assertions that should be in place for copyin/copyout requring fault handling? It sounds like somewhere we need to assert that Giant is held... Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lock warning...
* Robert Watson [EMAIL PROTECTED] [020317 09:08] wrote: On Sun, 17 Mar 2002, Alfred Perlstein wrote: * Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote: PS. I got another message that happend when I ^C'ed a buildworld earlier, with same kernel. May be it should go to Alfred Perlstein? lock order reversal 1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779 2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716 I think there's a place where the pipe can fault on an address while copying, I'll take a look at this. Are there any assertions that should be in place for copyin/copyout requring fault handling? It sounds like somewhere we need to assert that Giant is held... No, you need to assert that no other mutex other than Giant is held. It would be nice... :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
subscribe _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.hsrc/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c
I have no idea what the frig you guys are doing in vm_map.c. I would recommend that all the changes be backed out. Then I would recommend that the following be done: * change the lockmgr vm_map lock to be exclusive-only * test commit * change the lockmgr vm_map lock to an exclusive SX lock * test commit * Then work on re-optimizing the vm_map locks You guys are trying to bite off too much all at once. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c
Hi, Sorry to unwantedly butt in, but the patch supplied by Seigo actually solved the vm_map.c locking problems which used to come up on my system. Just some info. :) Regards, -- Hiten Pandya -- [EMAIL PROTECTED] --- Matthew Dillon [EMAIL PROTECTED] wrote: I have no idea what the frig you guys are doing in vm_map.c. I would recommend that all the changes be backed out. Then I would recommend that the following be done: * change the lockmgr vm_map lock to be exclusive-only * test commit * change the lockmgr vm_map lock to an exclusive SX lock * test commit * Then work on re-optimizing the vm_map locks You guys are trying to bite off too much all at once. __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: problems with perl
The perl upgrade seems to be having problems. I got this twice towday making buildworld from 4.5: Please test the enclosed patch. That patch allows perl to compile. Unfortunatly, I'm still unable to make a 5.0 kernel from 4.5, so I cant test it. cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes - Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions - ansi -g -nostdinc -I- -I. -I/5.0/usr/src/sys -I/5.0/usr/src/sys/dev -I/5.0/usr /src/sys/contrib/dev/acpica -I/5.0/usr/src/sys/contrib/ipfilter -I/5.0/usr/src/ sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundary=2 -Werror /5.0/usr/src/sys/dev/amr/amr.c cc1: warnings being treated as errors /5.0/usr/src/sys/dev/amr/amr.c: In function `amr_bio_command': /5.0/usr/src/sys/dev/amr/amr.c:817: warning: unsigned int format, different typ e arg (arg 3) *** Error code 1 Stop in /scratch/obj/5.0/usr/src/sys/GENERIC. *** Error code 1 Stop in /5.0/usr/src. *** Error code 1 Stop in /5.0/usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-C KERNEL (Was: Re: problems with perl)
cc1: warnings being treated as errors # make NO_WERROR=yes ... M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: bwrite: buffer is not busy???
I tried upgrading the bento cluster to 5.x so I can actually get 5.0
packages built (eaccess problems), and 5 of them blew up in about 10
minutes with this (I think this is going to be an .. uh .. interesting
test of the stability of 5.0-CURRENT):
IdlePTD at phsyical address 0x004a6000
initial pcb at physical address 0x003e9040
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x58
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0204b92
stack pointer = 0x10:0xcf0fac2c
frame pointer = 0x10:0xcf0fac34
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 10095 (umount)
trap number = 12
panic: page fault
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 5m52s
dumping to dev ad0b, offset 1575424
dump ata0: resetting devices .. done
254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234
233 232 231 230 229
228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208
207 206 205 204 20
3 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182
181 180 179 178 1
77 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156
155 154 153 152
151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131
130 129 128 127 126
125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105
104 103 102 101 10
0 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72
71 70 69 68 67 66
65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38
37 36 35 34 33 32
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
505 ../../../kern/kern_shutdown.c: No such file or directory.
(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
#1 0xc020cd48 in boot (howto=260) at ../../../kern/kern_shutdown.c:337
#2 0xc020d1e7 in panic (fmt=0xc0375b4b bwrite: buffer is not busy???)
at ../../../kern/kern_shutdown.c:647
#3 0xc02425e3 in bwrite (bp=0xc7740920) at ../../../kern/vfs_bio.c:747
#4 0xc02438da in vfs_bio_awrite (bp=0xc7740920) at ../../../kern/vfs_bio.c:1604
#5 0xc01e453c in spec_fsync (ap=0xcf0faae8) at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01e40f9 in spec_vnoperate (ap=0xcf0faae8) at ../../../fs/specfs/spec_vnops.c:121
#7 0xc02e7420 in ffs_sync (mp=0xc25ca600, waitfor=2, cred=0xc0e40980, td=0xc03b1de0)
at vnode_if.h:441
#8 0xc024fb95 in sync (td=0xc03b1de0, uap=0x0) at ../../../kern/vfs_syscalls.c:669
#9 0xc020c994 in boot (howto=256) at ../../../kern/kern_shutdown.c:246
#10 0xc020d1e7 in panic (fmt=0xc0393e1e %s) at ../../../kern/kern_shutdown.c:647
#11 0xc03324a0 in trap_fatal (frame=0xcf0fabec, eva=88) at
../../../i386/i386/trap.c:851
#12 0xc03321c9 in trap_pfault (frame=0xcf0fabec, usermode=0, eva=88) at
../../../i386/i386/trap.c:765
#13 0xc0331c53 in trap (frame={tf_fs = -822542312, tf_es = -821100528, tf_ds =
-1071382512,
tf_edi = 4, tf_esi = -1023860940, tf_ebp = -821056460, tf_isp = -821056488,
tf_ebx = -822490624, tf_edx = 0, tf_ecx = 2, tf_eax = 2, tf_trapno = 12, tf_err
= 0,
tf_eip = -1071625326, tf_cs = 8, tf_eflags = 65606, tf_esp = -1023860992, tf_ss
= -822498560})
at ../../../i386/i386/trap.c:433
#14 0xc0204b92 in _mtx_lock_sleep (m=0xc2f91f34, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:370
#15 0xc024f55c in checkdirs (olddp=0xcf1814c0, newdp=0xcf1815a0) at
../../../kern/vfs_syscalls.c:457
#16 0xc024f87b in dounmount (mp=0xc2e20c00, flags=524288, td=0xcef9ca00)
at ../../../kern/vfs_syscalls.c:583
#17 0xc024f73e in unmount (td=0xcef9ca00, uap=0xcf0fad20) at
../../../kern/vfs_syscalls.c:543
#18 0xc0332770 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
134809160,
tf_esi = 134914149, tf_ebp = -1077938936, tf_isp = -821056140, tf_ebx =
134914150, tf_edx = 0,
tf_ecx = -1077937306, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip =
134523171, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077939044, tf_ss = 47}) at
../../../i386/i386/trap.c:1049
#19 0xc0323dad in syscall_with_err_pushed ()
Kris
P.S. Yes, I'm only swapping onto a device once this time :-)
msg36262/pgp0.pgp
Description: PGP signature
Re: HEADS UP: -CURRENT Feature Slush is OVER
At 1:15 AM -0800 3/17/02, Murray Stokely wrote: On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote: Minimally, pick a date, and then do a CVS diff against that date, and include it on the CDROM. I would be happy to do this. I checked out a copy of the CVS tree right before we made the Perforce branch so that we could tag it later if absolutely necessary. I think this is a good and useful idea. Thanks. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bwrite: buffer is not busy???
On Sun, Mar 17, 2002 at 12:49:58PM -0800, Kris Kennaway wrote: I tried upgrading the bento cluster to 5.x so I can actually get 5.0 packages built (eaccess problems), and 5 of them blew up in about 10 minutes with this (I think this is going to be an .. uh .. interesting test of the stability of 5.0-CURRENT): I forgot to mention that they were running -current as of about a week ago. I upgraded to the CVS head, and 4 of the machines wedged solid in 2 minutes of load. I suspect greenvm :-) Kris msg36264/pgp0.pgp Description: PGP signature
Re: HEADS UP: -CURRENT Feature Slush is OVER
At 8:35 AM -0800 3/17/02, David O'Brien wrote: My earlier concerns about the use of Perforce were when a developers expected other developers to use Perforce for _shared_ development. Or that tried to claim that their code was published if it was in the Perforce depot on Freefall. Exactly my concerns, too. In this use of Perforce for a -CURRENT snapshot; I don't see how people can bitch and bitch about it. No committer or developer has EVER had CVS access or sight of the source used in previous snapshot CDROMs. So people are loosing nothing. Perforce is just a tool to assist Murray and Co. in making this snapshot CD. I agree completely. I have no concerns about them using perforce in this manner. Whatever makes their lives easier in getting out this developer's preview is fine by me. The other reason to NOT do this in the CVS repository is that it will help deemphasize that the DP is NOT a RELEASE. People should not be CVSup'ing hoping to get just that point in time, To speak about my own bias on this process, I agree completely with this sentiment. Four weeks from now, no one should care about the particular second in time they used to create this rough snapshot. I see this as more of a dry run for the *process* of creating a release of 5.0. It will give us a convenient bootstrap CD for those who want to try out 5.0, and who also want a bootable CD to do a clean install of something in 5.0, because they want to play with it a little. Anyone who thinks they are going to start tracking current had better *track* current, and not depend on this particular CD. It is not a release. That describes my opinion on what I expect from this developer's preview. I admit that I am not comfortable with using perforce (or subversion, or etc) in some other situations, but I think it is perfectly reasonable in this situation. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lock warning...
Apparently, On Sun, Mar 17, 2002 at 09:17:22AM -0800, Alfred Perlstein said words to the effect of; * Robert Watson [EMAIL PROTECTED] [020317 09:08] wrote: On Sun, 17 Mar 2002, Alfred Perlstein wrote: * Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote: PS. I got another message that happend when I ^C'ed a buildworld earlier, with same kernel. May be it should go to Alfred Perlstein? lock order reversal 1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779 2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716 I think there's a place where the pipe can fault on an address while copying, I'll take a look at this. Are there any assertions that should be in place for copyin/copyout requring fault handling? It sounds like somewhere we need to assert that Giant is held... No, you need to assert that no other mutex other than Giant is held. It would be nice... :) You can do this like at the bottom of syscall and trap, with witness_list(). It'll even print out what the other locks are and where they were acquired. But yeah, if you're going to access pageable memory in kernel mode you pretty much have to have no other locks held. Good work on pipe locking btw. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
In message p05101511b8bab342dc49@[128.113.24.47], Garance A Drosihn writes: At 8:35 AM -0800 3/17/02, David O'Brien wrote: My earlier concerns about the use of Perforce were when a developers expected other developers to use Perforce for _shared_ development. Or that tried to claim that their code was published if it was in the Perforce depot on Freefall. Exactly my concerns, too. I have just started two days ago using P4 to track the sparc64 stuff and confidently say that contrary to the ill effects I hear people complain about I have yet to see any signs of hair-loss, lack of sleep, early aging, republicanism or uncontrollable urges to go to Tenerife. I can think of many things wrong with P4 and with having a parallel environment to our CVS tree. But I also think having a P4 tree where people can colaborate beats not having it by a large margin. So could I suggest that the people who are so much against P4 tell us what the alternative they want us to use is ? -- 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: panic: bwrite: buffer is not busy???
On Sun, Mar 17, 2002 at 12:49:58PM -0800, Kris Kennaway wrote: I tried upgrading the bento cluster to 5.x so I can actually get 5.0 packages built (eaccess problems), and 5 of them blew up in about 10 minutes with this (I think this is going to be an .. uh .. interesting test of the stability of 5.0-CURRENT): IdlePTD at phsyical address 0x004a6000 initial pcb at physical address 0x003e9040 panicstr: bwrite: buffer is not busy??? panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x58 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0204b92 stack pointer = 0x10:0xcf0fac2c frame pointer = 0x10:0xcf0fac34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 10095 (umount) trap number = 12 panic: page fault As Peter pointed out to me, this is the actual panic; the bwrite: buffer is not busy??? is spurious and caused by the kernel trying to sync after the first panic. All of the problems I'm currently seeing are in umount. Kris msg36268/pgp0.pgp Description: PGP signature
Re: Patch to fix the build of the smbfs.ko kernel module
Hajimu UMEMOTO wrote: Hi, On Sat, 16 Mar 2002 01:32:04 -0800 Maxime Henrion [EMAIL PROTECTED] said: mux Since the addition of optimized 3DES encryption for x86, the build of the mux smbfs kernel module has been broken (on all platforms). This is because mux new files are now needed (des_enc.S for x86, des_enc.c for other mux archs). The attached patch fixes this problem. Oops, I've forgot about smbfs.ko. It seems fine to me. Actually, this patch is wrong because it won't ever compile des_enc.S. Whatever I do, des_enc.c gets compiled and I can't figure out how to compile a .S file with bsd.kmod.mk. If someone with more make(1) clue than me could help out, that would be appreciated. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c
: :Hi, : :Sorry to unwantedly butt in, but the patch supplied by Seigo actually :solved the vm_map.c locking problems which used to come up on my system. :Just some info. :) : :Regards, : : -- Hiten Pandya : -- [EMAIL PROTECTED] It fixed some things, it broke some things. Pretty much standard fare for anyone who has ever done work on the vm_map lock, including yours truely. John Dyson couldn't get it right, David Greenman couldn't get it right, I couldn't get it completely right... getting it to do the right thing even under -stable is difficult, which is why I am suggesting that it simply be made into an exclusive lock in -current. -Matt Matthew Dillon [EMAIL PROTECTED] :--- Matthew Dillon [EMAIL PROTECTED] wrote: : I have no idea what the frig you guys are doing in vm_map.c. I would : recommend that all the changes be backed out. Then I would recommend : that the following be done: : : * change the lockmgr vm_map lock to be exclusive-only : * test commit : * change the lockmgr vm_map lock to an exclusive SX lock : * test commit : * Then work on re-optimizing the vm_map locks : : You guys are trying to bite off too much all at once. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
Garance A Drosihn wrote: At 1:15 AM -0800 3/17/02, Murray Stokely wrote: On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote: Minimally, pick a date, and then do a CVS diff against that date, and include it on the CDROM. I would be happy to do this. I checked out a copy of the CVS tree right before we made the Perforce branch so that we could tag it later if absolutely necessary. I think this is a good and useful idea. Thanks. Yes, thanks, Murray. Without something like this, I think the CDROM will be worse than useless. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
On Sun, 17 Mar 2002, Terry Lambert wrote: Garance A Drosihn wrote: At 1:15 AM -0800 3/17/02, Murray Stokely wrote: On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote: Minimally, pick a date, and then do a CVS diff against that date, and include it on the CDROM. I would be happy to do this. I checked out a copy of the CVS tree right before we made the Perforce branch so that we could tag it later if absolutely necessary. I think this is a good and useful idea. Thanks. Yes, thanks, Murray. Without something like this, I think the CDROM will be worse than useless. One reason for deciding to abandon the original CVS idea was that the release engineering team was informed that there were on-going repocopies/removes/renames that would result in tagging causing long term problems. I.e., there's stuff in the repository that is destined to magically disappear since it's never hit a stable branch (beta versions of compilers and so on. In tagging the tree, we'd be (in essence) asserting that those transient bits of history would stick around to make the tag useful later. I don't mind tagging the tree with the understanding that if you check it out later, it will be known not to build due to a missing compiler, as long as people understand that. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c
On Sun, 17 Mar 2002, Matthew Dillon wrote: It fixed some things, it broke some things. Pretty much standard fare for anyone who has ever done work on the vm_map lock, including yours truely. John Dyson couldn't get it right, David Greenman couldn't get it right, I couldn't get it completely right... getting it to do the right thing even under -stable is difficult, which is why I am suggesting that it simply be made into an exclusive lock in -current. Hmm. Ok, so right now the code that has been branched for DP1 makes use of Brian's recent locking commits. My original thought was we'd simply back it out of that branch to make sure that the DP is reliable. How hard would it be for us to switch to what you propose (just convert all slocks into xlocks, and simplify out the upgrade semantics), in particular, before we cut the DP? It sounds to me like the right approach is simply to fall back to lockmgr for the DP, and get these fixes into the main tree and they'll be there for the next DP in a few months. Can you take ownership of the task since you clearly know what's going on? Can I stick your name in the smp web page saying so? :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c
:Hmm. Ok, so right now the code that has been branched for DP1 makes use :of Brian's recent locking commits. My original thought was we'd simply :back it out of that branch to make sure that the DP is reliable. How hard :would it be for us to switch to what you propose (just convert all slocks :into xlocks, and simplify out the upgrade semantics), in particular, :before we cut the DP? It sounds to me like the right approach is simply :to fall back to lockmgr for the DP, and get these fixes into the main tree :and they'll be there for the next DP in a few months. : :Can you take ownership of the task since you clearly know what's going on? :Can I stick your name in the smp web page saying so? :-) : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :[EMAIL PROTECTED] NAI Labs, Safeport Network Services I think the developers currently working on it have the expertise to clean it up. My recommendation is that developer who committed the SX lock stuff back it out (fall back to the lockmgr locks), and then that same developer scan the code and determine if the lockmgr lock can just be made exclusive for all cases and, if so, to test and commit that. If the exclusive-only lockmgr lock works then that is what should go into the DP, else the original lockmgr stuff should go in. Until the critical_*() function issue is resolved I do not want to make extensive modifications or updates to my -current tree so I couldn't do this stuff in the time frame you are talking about even if I wanted to. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bwrite: buffer is not busy???
Kris Kennaway [EMAIL PROTECTED] writes: [...] up 14 followed by p *m would be nice; making the dump and the debugging kernel available on freefall would be even nicer. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to fix the build of the smbfs.ko kernel module
Hi,
On Sun, 17 Mar 2002 15:38:48 -0800
Maxime Henrion [EMAIL PROTECTED] said:
mux Actually, this patch is wrong because it won't ever compile des_enc.S.
mux Whatever I do, des_enc.c gets compiled and I can't figure out how to
mux compile a .S file with bsd.kmod.mk. If someone with more make(1) clue
mux than me could help out, that would be appreciated.
Did you make sure to do make depend after changing your Makefile?
I tried it and I could reproduce your problem with `make buildkernel
NOCLEAN=YES NO_KERNELDEPEND=YES'. Then, I tried with `make
buildkernel NOCLEAN=YES', and the problem was gone.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
zlib breakage(was cvs commit: src/share/man/man4 ng_pptpgre.4)
This bug affects everything that uses libz of course. It also breaks zgrep. Try cd /home/ncvs/C*/*logs; zgrep foo *. On Sun, 17 Mar 2002, Bruce Evans wrote: On Sun, 17 Mar 2002, I wrote: That may be, but ispell is not man's best friend: $ man ispell Segmentation fault (core dumped) The bug seems to be in libz. Upgrading to the previous version of libz fixes it. The following patch (obtained from the upgrade) fixes man ispell (but may break libz). %%% Index: infcodes.c === RCS file: /home/ncvs/src/lib/libz/infcodes.c,v retrieving revision 1.3 diff -u -2 -r1.3 infcodes.c --- infcodes.c11 Mar 2002 22:36:26 - 1.3 +++ infcodes.c17 Mar 2002 02:41:53 - @@ -201,5 +201,5 @@ case COPY: /* o: copying bytes in window, waiting for space */ f = q - c-sub.copy.dist; - while (f s-window) /* modulo window size-while instead */ + if (f s-window)/* modulo window size-while instead */ f += s-end - s-window;/* of if handles invalid distances */ while (c-len) %%% The while loop caused some pointer to become invalid. I think the bug is really in gcc. The register hildng 's' seemed to get clobbered to (s-end - s-window) so 's' was invalid after 1 iteration. With an if instead of a while, gcc generates simpler code with line numbers that are actually correct and without the register clobber. Compiling the unpatched version with -O0 also unbreaks man ispell. Bruce Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bwrite: buffer is not busy???
Kris Kennaway [EMAIL PROTECTED] writes:
#14 0xc0204b92 in _mtx_lock_sleep (m=0xc2f91f34, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:370
(kgdb) up 14
#14 0xc0204b92 in _mtx_lock_sleep (m=0xc2f91f34, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:370
370 td1 = mtx_owner(m);
(kgdb) p *m
$1 = {mtx_object = {lo_class = 0x0, lo_name = 0x0, lo_flags = 0, lo_list = {
stqe_next = 0x0}, lo_witness = 0x0}, mtx_lock = 2, mtx_recurse = 0,
mtx_blocked = {tqh_first = 0x0, tqh_last = 0x0}, mtx_contested = {
le_next = 0x0, le_prev = 0x0}}
The mutex is uninitialized (destroyed, actually), because...
#15 0xc024f55c in checkdirs (olddp=0xcf1814c0, newdp=0xcf1815a0) at
../../../kern/vfs_syscalls.c:457
(kgdb) up
#15 0xc024f55c in checkdirs (olddp=0xcf1814c0, newdp=0xcf1815a0)
at ../../../kern/vfs_syscalls.c:457
457 FILEDESC_LOCK(fdp);
(kgdb) p *fdp
$2 = {fd_ofiles = 0xc2f91200, fd_ofileflags = 0xc2f91f00 , fd_cdir = 0x0,
fd_rdir = 0x0, fd_jdir = 0x0, fd_nfiles = 0, fd_lastfile = 0,
fd_freefile = -1024110592, fd_cmask = 0, fd_refcnt = 0, fd_knlistsize = 4,
fd_knlist = 0x11, fd_knhashmask = 0, fd_knhash = 0xdb, fd_mtx = {
mtx_object = {lo_class = 0x0, lo_name = 0x0, lo_flags = 0, lo_list = {
stqe_next = 0x0}, lo_witness = 0x0}, mtx_lock = 2, mtx_recurse = 0,
mtx_blocked = {tqh_first = 0x0, tqh_last = 0x0}, mtx_contested = {
le_next = 0x0, le_prev = 0x0}}}
...the process has no open files at all, because...
(kgdb) p p-p_pid
$4 = 10099
(kgdb) p p-p_comm
$5 = wc\000oot, '\000' repeats 13 times
(kgdb) p p-p_stat
$6 = 3
(kgdb) p/x p-p_flag
$7 = 0x6000
...it's exiting, and fdfree() has already run.
Solution: p-p_fd must be protected by p's proc lock; fdfree() must
set it to NULL immediately after freeing it; checkdirs() must lock
each process before examining its fd list.
Other problem spotted while investigating this: fdfree() can fail
silently; fdfree() should panic if fdp-fd_refcnt is non-zero.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: bwrite: buffer is not busy???
* Dag-Erling Smorgrav [EMAIL PROTECTED] [020317 19:27] wrote:
...the process has no open files at all, because...
(kgdb) p p-p_pid
$4 = 10099
(kgdb) p p-p_comm
$5 = wc\000oot, '\000' repeats 13 times
(kgdb) p p-p_stat
$6 = 3
(kgdb) p/x p-p_flag
$7 = 0x6000
...it's exiting, and fdfree() has already run.
Solution: p-p_fd must be protected by p's proc lock; fdfree() must
set it to NULL immediately after freeing it; checkdirs() must lock
each process before examining its fd list.
Other problem spotted while investigating this: fdfree() can fail
silently; fdfree() should panic if fdp-fd_refcnt is non-zero.
Please let me know if this works for you.
Index: vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.231
diff -u -r1.231 vfs_syscalls.c
--- vfs_syscalls.c 12 Mar 2002 04:00:10 - 1.231
+++ vfs_syscalls.c 18 Mar 2002 06:23:41 -
@@ -451,10 +451,14 @@
return;
sx_slock(allproc_lock);
LIST_FOREACH(p, allproc, p_list) {
+ PROC_LOCK(p);
fdp = p-p_fd;
- if (fdp == NULL)
+ if (fdp == NULL) {
+ PROC_UNLOCK(p);
continue;
+ }
FILEDESC_LOCK(fdp);
+ PROC_UNLOCK(p);
if (fdp-fd_cdir == olddp) {
VREF(newdp);
fdp-fd_cdir = newdp;
Index: kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.128
diff -u -r1.128 kern_descrip.c
--- kern_descrip.c 15 Mar 2002 08:03:46 - 1.128
+++ kern_descrip.c 18 Mar 2002 06:23:39 -
@@ -1321,19 +1321,26 @@
fdfree(td)
struct thread *td;
{
- register struct filedesc *fdp = td-td_proc-p_fd;
+ register struct filedesc *fdp;
struct file **fpp;
register int i;
+ PROC_LOCK(td);
+ fdp = td-td_proc-p_fd;
/* Certain daemons might not have file descriptors. */
- if (fdp == NULL)
+ if (fdp == NULL) {
+ PROC_UNLOCK(td);
return;
+ }
FILEDESC_LOCK(fdp);
if (--fdp-fd_refcnt 0) {
FILEDESC_UNLOCK(fdp);
+ PROC_UNLOCK(td);
return;
}
+ td-td_proc-p_fd = NULL;
+ PROC_UNLOCK(td);
/*
* we are the last reference to the structure, we can
* safely assume it will not change out from under us.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: bwrite: buffer is not busy???
On Sun, Mar 17, 2002 at 10:17:39PM -0800, Alfred Perlstein wrote: * Dag-Erling Smorgrav [EMAIL PROTECTED] [020317 19:27] wrote: ...the process has no open files at all, because... (kgdb) p p-p_pid $4 = 10099 (kgdb) p p-p_comm $5 = wc\000oot, '\000' repeats 13 times (kgdb) p p-p_stat $6 = 3 (kgdb) p/x p-p_flag $7 = 0x6000 ...it's exiting, and fdfree() has already run. Solution: p-p_fd must be protected by p's proc lock; fdfree() must set it to NULL immediately after freeing it; checkdirs() must lock each process before examining its fd list. Other problem spotted while investigating this: fdfree() can fail silently; fdfree() should panic if fdp-fd_refcnt is non-zero. Please let me know if this works for you. Thanks, will test once the current run is finished. Kris msg36280/pgp0.pgp Description: PGP signature
utmp and current
Hi, I updated to current 5.0 several weeks back and just noticed that the utmp logging for people users logged in is missing. The wtmp is populated very strangely too. None of the ttyv* are logged logging of ttyp* is selective ( on what ? I havent been able to figure it out). All the listings in last are also incomplete. The last login entry for any ttyv* is the last day I ran 4.4 stable.. What gives? Have you guys have had any experience similar to this Thanks a bunch Saurabh Gupta To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bwrite: buffer is not busy???
Alfred Perlstein [EMAIL PROTECTED] writes: Please let me know if this works for you. [...] + PROC_LOCK(td); *cough* *cough* :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bwrite: buffer is not busy???
* Dag-Erling Smorgrav [EMAIL PROTECTED] [020317 22:55] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: Please let me know if this works for you. [...] + PROC_LOCK(td); *cough* *cough* :) It was untested. :) I'm sure you can fix it, I've got to get some sleep, let me know if it works for you. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
World on -stable is busted
cc -O -pipe -I/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl -I/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5 -DPERL_EXTERNAL_GLOB -DPERL_CORE -DAPPLLIB_EXP=\/usr/libdata/perl/BSDPAN\ -L/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl/../libperl -static -o miniperl miniperlmain.o perl.o gv.o toke.o perly.o op.o regcomp.o dump.o util.o mg.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o universal.o xsutils.o globals.o perlio.o -lm -lcrypt -lutil pp_sys.o: In function `Perl_pp_fteread': pp_sys.o(.text+0x5f57): undefined reference to `eaccess' pp_sys.o: In function `Perl_pp_ftewrite': pp_sys.o(.text+0x6023): undefined reference to `eaccess' pp_sys.o: In function `Perl_pp_fteexec': pp_sys.o(.text+0x60ef): undefined reference to `eaccess' *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Bad fix for -current breakage
Note, a real fix would be applied to all the config.* files, and would depend on the BOOTSTRAP symbol that we define during the early stages of the build. This is my wimpy fix for people that want a quick fix to the problem of building -current on -stable. Now, to the next breakage in the tree :-) Warner Index: config.SH-elf.i386 === RCS file: /home/imp/FreeBSD/CVS/src/gnu/usr.bin/perl/libperl/config.SH-elf.i386,v retrieving revision 1.22 diff -u -r1.22 config.SH-elf.i386 --- config.SH-elf.i386 16 Mar 2002 21:36:07 - 1.22 +++ config.SH-elf.i386 18 Mar 2002 07:54:02 - @@ -138,7 +138,7 @@ d_dosuid='define' d_drand48proto='define' d_dup2='define' -d_eaccess='define' +d_eaccess='undefine' d_endgrent='define' d_endhent='define' d_endnent='define' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
