buildkernel breakage on Today's kernel
>From >http://current.jp.FreeBSD.org/build/i386/LINT/5.0-CURRENT-20001021-JPSNAP.bad>: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DGPROF -D_KERNEL -include opt_global.h -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg ../../dev/en/midway.c In file included from ../../dev/en/midway.c:160: ../../dev/en/midwayreg.h:13: conflicting types for `bus_space_tag_t' machine/bus_at386.h:110: previous declaration of `bus_space_tag_t' ../../dev/en/midwayreg.h:13: warning: redundant redeclaration of `bus_space_tag_t' in same scope machine/bus_at386.h:110: warning: previous declaration of `bus_space_tag_t' ../../dev/en/midwayreg.h:15: conflicting types for `bus_space_handle_t' machine/bus_at386.h:111: previous declaration of `bus_space_handle_t' ../../dev/en/midwayreg.h:15: warning: redundant redeclaration of `bus_space_handle_t' in same scope machine/bus_at386.h:111: warning: previous declaration of `bus_space_handle_t' ../../dev/en/midwayreg.h:16: redefinition of `bus_size_t' machine/bus_at386.h:96: `bus_size_t' previously declared here ../../dev/en/midwayreg.h:17: conflicting types for `bus_addr_t' machine/bus_at386.h:95: previous declaration of `bus_addr_t' ../../dev/en/midwayreg.h:17: warning: redundant redeclaration of `bus_addr_t' in same scope machine/bus_at386.h:95: warning: previous declaration of `bus_addr_t' *** Error code 1 src/sys/dev/en/midwayreg.h says 'bus_space_tag_t' is 'void *', however, src/sys/i386/include/bus_at386.h says it is 'int'. Sorry, I dunno which is correct. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel PANICS during "make release"
On Sat, 21 Oct 2000, Makoto MATSUSHITA wrote: > Yes, during a newfs. Console shows following messages: > > /mnt: bad dir ino 2 at offset 0: mangled entry > panic: ufs_dirbad: bad dir > > syncing disks... Hmm, I've seen the same panic with pre-SMPng kernel when booting from floppy. Since there was no time to trace this problem I'd just disabled panic() invocation and machine booted fine. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel PANICS during "make release"
jhay> Not that old. 2000-10-05. Hmm. I'll try it later, thank you. *** I've tried with a kernel as of Oct/07/2000, kernel also panics. However, panic point is different: mfsroot: 71.5% <<-- THE POINT OF LAST HUNGUP disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/rvnn1c:2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: <<>> Yes, during a newfs. Console shows following messages: /mnt: bad dir ino 2 at offset 0: mangled entry panic: ufs_dirbad: bad dir syncing disks... Kernel try to sync a disk, but no further messages are found. Going to kernel debugger, and print a process table: syncing disks... Stopped at siointr1+0xf2: movl $0,brk_state1.855 db> ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 76081 cf748640 cfaf30000 76054 62409 004004 2 cp 76054 cce2d500 cf7390000 85717 62409 004084 3wait cce2d500 sh 75301 cf7451c0 cfeab0000 176 75301 004184 3 sbwait cd6541f4 ftpd 40769 cf7474c0 cfb3e000 1011 313 40769 004086 3 kqread c2899000 tail 85717 cf749b40 cf74f0000 62828 62409 004084 3wait cf749b40 make 62828 cf748b80 cf81a0000 62413 62409 004084 3wait cf748b80 sh 62413 cf746c00 cfcdb0000 62409 62409 004084 3wait cf746c00 sh 62409 cf746a40 cfcde0000 62405 62409 004084 3wait cf746a40 sh 62405 cf749280 cf7620000 178 178 84 3 piperd cf6e10c0 cron 51708 cf746500 cfce80000 176 51708 004184 3 sbwait cd65bf74 ftpd 81513 cf747680 cfb3b0000 176 81513 004184 3 sbwait cd65b4f4 ftpd 766 cf7489c0 cfaed0000 176 766 004184 3 sbwait cd64f4f4 ftpd 313 cf749980 cf752000 1011 311 313 2004086 3 pause cf752108 zsh 311 cce2d6c0 cf7360000 181 181 000184 3 select c0283ef0 sshd 230 cce2ddc0 cf71c0000 1 230 004086 3 ttyin c2311a10 getty 229 cce2df80 cf7190000 1 229 004086 3 ttyin c2353710 getty 228 cce2e140 cf710 1 228 004086 3 ttyin c2374310 getty 227 cce2f480 cf6d90000 1 227 004086 3 ttyin c228a610 getty 226 cce2e300 cf70d000 302 221 226 004184 3 select c0283ef0 thttpd 221 cce2f2c0 cf6dc0000 1 6 004086 3wait cce2f2c0 sh 215 cce2e4c0 cf7090000 1 6 86 3 select c0283ef0 snmpd 181 cce2e680 cf7060000 1 181 84 3 select c0283ef0 sshd 178 cce2e840 cf7010000 1 178 84 3 nanslp c026bb84 cron 176 cce2ea00 cf6fe0000 1 176 84 3 select c0283ef0 inetd 153 cce2ebc0 cf6f20000 1 153 84 3 select c0283ef0 ntpd 150 cce2f100 cf6e30000 1 150 84 3 select c0283ef0 named 147 cce2ed80 cf6ef0000 1 147 84 2 syslogd 33 cce2ef40 cf6e60000 133 84 3 mfsidl ce34f520 mount_mfs 5 cce2f640 ce3580000 0 0 000204 3 syncer c0283e68 syncer 4 cce2f800 ce3560000 0 0 100204 3 psleep c026bcf0 bufdaemon 3 cce2f9c0 ce3540000 0 0 000204 3 psleep c0278480 vmdaemon 2 cce2fb80 ce3520000 0 0 100204 3 psleep c025bdf8 pagedaemon 18 cce2fd40 cd64b0000 0 0 000204 6 irq7: ppc0 17 cce2ff00 cd6480000 0 0 000204 6 irq6: fdc0 16 cce300c0 cd6460000 0 0 000204 2 irq10: fxp1 15 cce30280 cd6430000 0 0 000204 6 irq9: intpm0 14 cce30440 cd6410000 0 0 000204 2 irq14: ata0 13 cce30600 cd63f0000 0 0 000204 2 irq12: fxp0 12 cce307c0 cd63c0000 0 0 000204 3 rndslp c0283094 random 11 cce30980 cd63a0000 0 0 00020c 2 softinterrupt 10 cce30b40 cce370000 0 0 00020c 2 idle 1 cce30d00 cce350000 0 1 004284 3wait cce30d00 init 0 c02830c0 c02eb0000 0 0 000204 3 sched c02830c0 swapper db> What's happened to this kernel...? *** Again, not that making a 4-stable distribution works with this kernel. Only 5-current is failed. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: sys/i386/i386/machdep.c:cpu_idle() changes causes this Was:
At 01:21 PM 10/20/2000 -0700, John Baldwin wrote: >On 20-Oct-00 Valentin Chopov wrote: >> I found that if I remove #ifndef SMP /#endif in: > >Errr, this doesn't really make sense, and if anything is probably >hiding the problem. Also, this change will potentially increase >interrupt latency even further on SMP machines. > >-- John Do you have any idea what's causing this ? Oct 20 21:20:36 pozo last message repeated 17 times Oct 20 21:30:00 pozo last message repeated 4 times Oct 20 21:30:00 pozo last message repeated 4 times Oct 20 21:41:26 pozo last message repeated 9 times Oct 20 21:41:26 pozo last message repeated 9 times Oct 20 21:50:01 pozo last message repeated 13 times Oct 20 21:50:01 pozo last message repeated 13 times #dmesg kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled this is a very truncated version there are probably 301 messages like this in a SMP machine that has only been up about 4 hours with very little activity , just a few cvsups and mail. If I build a kernel then the messages really increase. If there is any thing I can do Thanks Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker Task: M_ZERO
In <17100.972069144@critter>, Poul-Henning Kamp wrote: > If anybody is looking for a simple task to perform in the FreeBSD > kernel: this is it. Is it necessary to announce it somewhere, when I want to do that? >Submit changes to the maintainer of the file (if any) or >with send-pr. Even relatively large diffs? It is ok to send them directly to [EMAIL PROTECTED]? -- Robert S. F. Drehmel <[EMAIL PROTECTED]> "Do not ask me; I am the programmer." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fsck not rewriting super block?
Hi, I've run into an interesting problem: ad0: 19473MB [39566/16/63] at ata0-master UDMA33 ad1: 19541MB [39703/16/63] at ata0-slave UDMA33 I have swap and two large partitions on ad1: #size offsetfstype [fsize bsize bps/cpg] b: 104857600 swap# (Cyl.0 - 10402*) c: 400205610unused0 0 # (Cyl.0 - 39702*) e: 25165824 104857604.2BSD 1024 819216 # (Cyl. 10402*-35368*) f: 4368977 356515844.2BSD 1024 819216 # (Cyl. 35368*-39702*) However, the f partition will not fsck correctly: %/sbin/fsck -y /dev/ad1s1f ** /dev/ad1s1f BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE LOOK FOR ALTERNATE SUPERBLOCKS? yes USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 2116933 free (13 frags, 264615 blocks, 0.0% fragmentation) UPDATE STANDARD SUPERBLOCK? yes * FILE SYSTEM WAS MODIFIED * So, running fsck again produces the same identical output. The superblock is not updated. No failures are reported on the console or in the messages file. System is current: FreeBSD 5.0-CURRENT #0: Thu Oct 19 Any ideas on the best way to track this down are appreciated. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: sys/i386/i386/machdep.c:cpu_idle() changes causes this Was:
On 20-Oct-00 Valentin Chopov wrote: > I found that if I remove #ifndef SMP /#endif in: Errr, this doesn't really make sense, and if anything is probably hiding the problem. Also, this change will potentially increase interrupt latency even further on SMP machines. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
On Fri, Oct 20, 2000 at 10:06:37AM -0700, Mark Murray wrote: > > It seems I find the problem area. 4096 bytes written in rc.shutdown are > > not enough for reseeding. When I change them to 16384 bytes, it works! > > I'll commit working rc.shutdown variant. > > This is bogus. > > _Any_ randomness written to /dev/random is good enough to perturb the > sequence. > > Please do _not_ make that commit. Oops, sorry, already commited (I was not thinking it is principal, but it really fix potential security hole). I can back it out if you wish. But anything less then 16384 not reseed it. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sys/i386/i386/machdep.c:cpu_idle() changes causes this Was: Re:kernel trap 12 with interrupts disabled
I found that if I remove #ifndef SMP /#endif in:
sys/i386/i386/machdep.c:
void
cpu_idle(void)
{
#ifndef SMP
if (cpu_idle_hlt) {
disable_intr();
if (procrunnable())
enable_intr();
else {
enable_intr();
__asm __volatile("hlt");
}
}
#endif
}
it works again.
I'm running SMP kernel on Dual PIII machine.
Regards,
Val
On Thu, 19 Oct 2000, Valentin Chopov wrote:
> I got the same with addition that the machine hangs:(
>
> Val
>
> On Wed, 18 Oct 2000, Manfred Antar wrote:
>
> > With current kernel I'm getting alot of :
> > kernel trap 12 with interrupts disabled
> > kernel trap 12 with interrupts disabled
> > kernel trap 12 with interrupts disabled
> > kernel trap 12 with interrupts disabled
> > kernel trap 12 with interrupts disabled
> >
> > Kernel from yesterday did not do this.
> > Everything seems to work fine although I think it hung on a "shutdown -r now"
> > I don't have a monitor hooked up to the machine right now, so I have no further
>info.
> > I'm in process of hooking up a serial console.
> > Manfred
> > ==
> > || [EMAIL PROTECTED] ||
> > || Ph. (415) 681-6235 ||
> > ==
> >
> >
> >
> > 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
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Junior Kernel Hacker Task: M_ZERO
I have introduced the M_ZERO flag to the kernel malloc, which provides the service to bzero() the memory allocted. In the kernel sources, the archetypical change to use this facility looks like this: Old code: databuf = malloc(length, M_DEVBUF, M_WAITOK); bzero(databuf, length); New code: databuf = malloc(length, M_DEVBUF, M_WAITOK | M_ZERO); Short term the benefit is less clutter in the code and a smaller cache footprint of the kernel. Long term, this will allow us to optimize malloc(9) by allocating from a pool of memory which is zero'ed whenever the cpu is idle. If anybody is looking for a simple task to perform in the FreeBSD kernel: this is it. A quick grep tells me that there are at least 91 files in the src/sys tree which could use this flag to simplify and optimize the code. The ground rules for such a cleanup are: Respect the style of the source file. Don't make unrelated changes: If you spot other issues with the code as you read it, make a separate diff for those issues. Bundle the patches at administrative boundaries: a directory at a time, a driver at a time etc etc. Submit changes to the maintainer of the file (if any) or with send-pr. Junior committers are encouraged to review and commit these PR's as they arrive -- 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: I18N Progress, Plans, and Proposals
On Thu, Oct 19, 2000 at 01:16:12PM -0700, Jordan Hubbard scribbled: | > The advantages are : | > A. Easy bug reporting by users. (e.g. "I have error 2398423") | > B. I18N error messages | | Let me just say, as someone who's done "escalation tech support" for | major ISVs (the people who get called whenever front-line tech support | is confronted with a "I have error 2398423" question), that this can | also be a tremendous pain in the butt when done wrong. The format I have in mind is more like: kern.pci.cardbus.insert.ed0 kern.net.tcpip.route.not-responding.gateway.123.233.233.100 kern.pci.pcm.yamaha.ptr.mem.0xfedf8000.irq9.device.9.on-pci0 | Done wrong, a message catalog-using program will emit cryptic numeric | errors whenever a message catalog file cannot be found or is | corrupted. Done right, the program is written in such a way as to | contain a default message which can also be overridden from the | message catalog file if some different text is found in the | appropriate language. I believe this is the way that catgets(3) | currently works, but you'd be amazed how many programmers just skip | providing a default message since the appropriate message catalog is | always found on *their* system. | | There's also nothing more unreadable than code which tests a failure | condition and then calls a message catalog routine with some numeric | constant, the actual text of the error message being an aid to the | programmer as well as the user when reading someone else's code and | trying to figure out what varioups parts of it are trying to do. So can we output the message catalogue name along with the plaintext message? -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new library: libisc
In article <[EMAIL PROTECTED]>, Archie Cobbs <[EMAIL PROTECTED]> wrote: > Absent violent rejection, I'd like to add the ISC utility library > to the FreeBSD build. If you're not familiar, check out the man > pages /usr/src/contrib/bind/lib/isc/*.mdoc. There are several useful > utilities in there. The main thing I'm interested in is the event > library, but there is other useful stuff in there too. Yes please! This is something I've wanted to have in the system for a long time. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I18N Progress, Plans, and Proposals
On Thu, Oct 19, 2000 at 08:38:47PM +0200, Johan Granlund scribbled: | On Thu, 19 Oct 2000, Michael C . Wu wrote: | > At the BSDCon I18N BOF, we discussed several things that could/should | > happen with the future of I18N(internationalization) in FreeBSD. | > We would like some inputs and comments regarding the following: | > 2. Needing a graphics console to display various character sets. | >There should be a kernel or loader option to start | >a graphics console by default. | The magic word is option :) | We have to be careful to not loose the ability to boot a bare-bone system | if / when having problems. Right, it will/should be an option. | I _still_ like VAX/VMS ability to be "talked" up thru the boot process. Er, *meep* too young to know what you are talking about -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current.freebsd.org back up
snapshots are still broken, but you can at least get the previous ones via ftp now. - jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I18N Paper URL
On Thu, Oct 19, 2000 at 02:26:39PM -0500, Michael C . Wu wrote:
> http://www.ece.utexas.edu/~mwu/{presentation.ps,i18n.*}
> This is our paper presented at BSDCon.
Thanks ... Please don't send the wrong version next time. :-)
Oh, could you put pictures about Taiwan Beer on web as well ?
(I think they're legally imported..
SFO, HKG, and TW airport allowed me taking 12 bottles of beer)
--
CirX - This site doesnt' exist.
9c k9o h9 s1bg s1f, 7v .y xqx a sj m8r ffg1 vg5 a6 asox tmul h38 .
ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v ' .a. CirX.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
> It seems I find the problem area. 4096 bytes written in rc.shutdown are > not enough for reseeding. When I change them to 16384 bytes, it works! > I'll commit working rc.shutdown variant. This is bogus. _Any_ randomness written to /dev/random is good enough to perturb the sequence. Please do _not_ make that commit. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
X server setting
Does anyone have X server settings for an ATI Rage pro 128 graphics card & Eizo lcd monitor L661 ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
On Fri, Oct 20, 2000 at 08:27:53PM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote: > On Fri, Oct 20, 2000 at 08:48:46AM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote: > > In very recent -current, my entropy file writted and readed sucessfully, > > but I got the same fortune quote again and again right after reboot! > > > > It means that anything writted to /dev/random not reseed it but _reset_ it > > to the same default state. > > It seems I find the problem area. 4096 bytes written in rc.shutdown are > not enough for reseeding. When I change them to 16384 bytes, it works! BTW, 16384 is _minimal_ value, all lower values _not_ cause reseeding. I don't know, why. -- 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: entropy reseeding is totally broken
On Fri, Oct 20, 2000 at 08:48:46AM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote: > In very recent -current, my entropy file writted and readed sucessfully, > but I got the same fortune quote again and again right after reboot! > > It means that anything writted to /dev/random not reseed it but _reset_ it > to the same default state. It seems I find the problem area. 4096 bytes written in rc.shutdown are not enough for reseeding. When I change them to 16384 bytes, it works! I'll commit working rc.shutdown variant. -- 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: PCI device IDs sourses?
On Fri, Oct 20, 2000 at 05:48:03PM +0400, Andrej Cernov wrote: > Does anybody know PCI devices IDs database on-line (at least for Intel > chips...)? > I have lots of unknown IDs for ASUS CUSL2 card... http://www.yourvote.com/pci/ -- Wilko Bulte [EMAIL PROTECTED] Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCI device IDs sourses?
Does anybody know PCI devices IDs database on-line (at least for Intel chips...)? I have lots of unknown IDs for ASUS CUSL2 card... -- 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: current.freebsd.org problems?
> > $ For now I just went back to an older kernel that works for me. > > How older is your kernel? > My kernel build 2000-09-21 JST. It panic when "make release". Not that old. 2000-10-05. The machine is a dual 266MHz PII. I have no problem building releases using "NODOC=YES WORLD_FLAGS=-j4" when the source is not broken. :-) I'm trying now again after the bktr fix went in. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org problems?
From: John Hay <[EMAIL PROTECTED]> Subject: Re: current.freebsd.org problems? Date: Fri, 20 Oct 2000 10:07:14 +0200 (SAT) $ For now I just went back to an older kernel that works for me. How older is your kernel? My kernel build 2000-09-21 JST. It panic when "make release". --- Masanori Kanaoka [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org problems?
jhay> For now I just went back to an older kernel that works for me. Would you please explain "an older kernel" ? I'm using a kernel as of Sep/30/2000 and it panics. *** Note that this (Sep/30/2000) kernel doesn't panic until Oct/13/2000. Between Oct/14/2000 and Oct/17/2000, "make release" was failed at buildworld. Oct/18/2000, panic. Oct/19/2000, also panic. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
On Fri, 20 Oct 2000, Udo Schweigert wrote: > On Fri, Oct 20, 2000 at 08:48:46 +0400, Andrej Cernov wrote: > > In very recent -current, my entropy file writted and readed sucessfully, > > but I got the same fortune quote again and again right after reboot! > > > > It means that anything writted to /dev/random not reseed it but _reset_ it > > to the same default state. > > > > How do you shutdown your machine: > > a) reboot or halt > b) shutdown -r now C-A-D usually works too, as does 'init 6'. One of the oft-agreed on topics at the con is that we need a _consistent_ schedule of events for all forms of shutdown that are not explicitly "fast" shutdown paths that for whatever reason we don't want to schedule things like rc.shutdown and sync for. Expect to see conversation about this on -arch sometime soon. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org problems?
> $ I'm very interested if current.jp.freebsd.org was hung up when "make > $ release" procedure was running. current.jp.freebsd.org was hung up in > $ these two days, when making a boot floppy (the hungup was occured > $ *exactly* the same point). > > I have same experience.My current-box was hung up when "make release". > then, log is below: > > sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 /R/stage/mfsfd >8000 minimum2 > disklabel: ioctl DIOCWLABEL: Operation not supported by device > Warning: Block size restricts cylinders per group to 6. > Warning: 2432 sector(s) in last cylinder unallocated > /dev/rvnn0c:5760 sectors in 2 cylinders of 1 tracks, 4096 sectors > 2.8MB in 1 cyl groups (6 c/g, 12.00MB/g, 384 i/g) > super-block backups (for fsck -b #) at: > 32 > 3700 blocks > Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on > /dev/vnn0c 2803 1868 71172% 67 31518% /mnt > >>> Filesystem is 2880 K, 711 left > >>> 8000 bytes/inode, 315 left > mfsroot: 71.4% > I have also seen this on my current box when building -current snaps. At the same time I see 10 or so "kernel trap 12 with interrupts disabled" messages on the console before it wedges really good. For now I just went back to an older kernel that works for me. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel breakage on Today's kernel
This should make it build
*** bktr_os_old.c Fri Oct 20 00:37:32 2000
--- bktr_os.c Fri Oct 20 00:43:59 2000
***
*** 464,469
--- 464,471
static int
bktr_detach( device_t dev )
{
+ int unit;
+
struct bktr_softc *bktr = device_get_softc(dev);
/* Disable the brooktree device */
On Fri, Oct 20, 2000 at 03:11:29PM +0900, Makoto MATSUSHITA wrote:
>
> ../../dev/bktr/bktr_os.c: In function `bktr_detach':
> ../../dev/bktr/bktr_os.c:484: `unit' undeclared (first use in this function)
> ../../dev/bktr/bktr_os.c:484: (Each undeclared identifier is reported only once
> ../../dev/bktr/bktr_os.c:484: for each function it appears in.)
>
> More logfile:
>http://current.jp.FreeBSD.org/build/i386/LINT/5.0-CURRENT-20001020-JPSNAP.bad>
>
> -- -
> Makoto `MAR' MATSUSHITA
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
--tcole
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org problems?
kana> I have same experience.My current-box was hung up when "make release". kana> then, log is below: Ya, exactly the same point of current.jp.FreeBSD.org. The same story should be applied to current.FreeBSD.org. We cannot make a -current distribution now. Changes from Oct/10/2000 to now cause this problem. This logfile denotes that some commands (expr, rm, mknod, umount, vnconfig) in src/release/doFS.sh causes kernel hungup. Is there any fatal changes, committers ? -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
