Re: Kde2pre: is it FreeBSD or Kde fault?
On Sun, Apr 30, 2000 at 09:50:36PM +0200, Jeroen Hogeveen <[EMAIL PROTECTED]> wrote: > You can try to edit the libtool file in the kdelibs > directory to set deplibs="$deplibs -lc -lgcc" (around > line number 2600). > > This will link the __eh_rtime_match. > > I still get a nonworking khtm however.. : > > khtml (cache): CachedImage::ref() > khtml (cache): Cache::notify() > konqueror: KCrash: crashing crashRecursionCounter = 0 > konqueror: KCrash: Appname = 0x8073fb0 apppath = 0x0 > konqueror: Unable to start dr. konqi > DCOP: unregister 'konqueror'kio (KIOConnection): read > kio (kioslave): slavewrapper: Communication with app lost. > Returning to slave pool. Thanks, I'll give it a try when I get time. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage in ng_base.c
hrm, i'm sad to report that it did not work for me.. let me know if you need output from it, i'll see about sending it to you. -- jan On Sun, 30 Apr 2000, Gary Jennejohn wrote: > Here's a simple patch which works for me. > > --- /sys/netgraph/ng_base.c Sun Apr 30 11:32:22 2000 > +++ /sys/netgraph/ng_base.c_mod Sun Apr 30 11:40:24 2000 > @@ -314,11 +314,16 @@ > int error; > > /* Not found, try to load it as a loadable module */ > +#if 0 > snprintf(filename, sizeof(filename), "ng_%s.ko", typename); > if ((path = linker_search_path(filename)) == NULL) > return (ENXIO); > error = linker_load_file(path, &lf); > FREE(path, M_LINKER); > +#else > + snprintf(filename, sizeof(filename), "ng_%s", typename); > + error = linker_load_file(filename, &lf); > +#endif > if (error != 0) > return (error); > lf->userrefs++; /* pretend loaded by the syscall */ > > > > Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > +-/ f. johan beisser /--+ email: jan[at]caustic.org web: http://www.caustic.org/~jan "knowledge is power. power corrupts. study hard, be evil." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage in ng_base.c
"f.johan.beisser" writes: > >hrm, i'm sad to report that it did not work for me.. > >let me know if you need output from it, i'll see about sending it to you. > >-- jan > >On Sun, 30 Apr 2000, Gary Jennejohn wrote: > >> Here's a simple patch which works for me. >> [patch deleted] Well, I only have a simple requirement - PPPoE has to work. ng_socket.ko gets loaded just fine for me, but I'm not really certain that ng_base.c is doing the loading. I think the best thing would be to wait for Peter to finish the commit since he knows what's intended to be used here. However, it might be worth posting your error output to the list as an aid in finding the correct fix :) --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: high CPU usage by xmms
It was working perfectly about 10 days ago. It stopped working right after one or two major commits. And also, it's in 5.0-CURRENT, not 4.0 = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Mon, 1 May 2000, Ted Sikora wrote: > Kenneth Wayne Culver wrote: > > > > Hmm, I don't know then, I'm using that ViBRA 16X which seems to cause > > problems a lot. > > > > > > > On Sun, 30 Apr 2000, Ted Sikora wrote: > > > > > Kenneth Wayne Culver wrote: > > > > > > > > I guess it depends on your soundcard, I'm getting the behavior I'm getting > > > > with a ViBRA 16X and a kernel as of this morning. This didn't start > > > > happening until about 4 days ago with a -CURRENT kernel. Maybe you have an > > > > older -CURRENT. > > > > > > > > > > > I did a make build/installworld and kernel this afternoon after I > > > cvsup'd(current). I have an original non-pnp SB16. > > > (Best sounding sound card on the market IMOP) > > > > > The VibraX used to be the card everyone recommended to stay away from. > It's not full-duplex. Early on it was hard writing for it (mostly due to > lack of specs and noise problems). It seems most problems have been > solved now. Like someone mentioned already > I think it's a 4.0 problem. Xmms worked perfectly under 3.4 for > me too. The eq problem appeared after the upgrades. > > -- > Ted Sikora > Jtl Development Group > [EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: high CPU usage by xmms
On Mon, May 01, 2000 at 10:14:34AM -0400, Kenneth Wayne Culver wrote: > It was working perfectly about 10 days ago. It stopped working right after > one or two major commits. And also, it's in 5.0-CURRENT, not 4.0 I fully agree with this statement ... I am having some of the same weird things ahppening to sound on my GUS MAX since (i think) the first major commit that was supposed to fix some issues with pcm. After that all my wav files seem to skip the first x frames of sound. (where everything has just worked perfectly before that specific commit.) take a soundfile like this: 1234567890 plays as 67890 1234 plays as -- Pascal Hofstee < daeron @ shadowmere . student . utwente . nl > Managers know it must be good because the programmers hate it so much. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: high CPU usage by xmms
Ok, more in the sound department: A current src/sys/dev/sound with a src/sys/dev/sound/pcm/dsp.c from the 22nd does not exhibit the high load problem. Moving dsp.c to the 24th causes the problem to re-appear. Thus, I'm prety convinced tha the big commit on the 23rd to dsp.c is the cause of at least my woes. However, I had major problems is onther areas with running dsp.c out of sync with the rest of the sound dir, so I RERALLY DON'T RECOMEND IT(not that you may care what I think). The workaround that has worked for me on three machines is to revert ALL of sys/dev/sound back to the 20th. If I get really bored in a couple of weeks, I may try to hammer out a patch, but I've got no familiarity with the code, so someone who understands it, or can do it sooner, might want to take a look. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: loader updated to handle module metadata
Loader was updated to handle module metadata which was introduced by recent updates in kernel linker. This is related to a new way of declaration of module dependencies. -- Boris Popov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WaveLan wi0
Now I have it recognized with without the irq and I/O space problem because I
had an irq 9 conflict but now I am getting :
wi0: at port 0x240-0x27f irq 9 slot 0 on pccard0
wi0: Ethernet address: 00:60:1d:03:f4:08
wi0: device timeout
wi0: tx buffer allocation failed
wi0: xmit failed
wi0: device timeout
wi0: tx buffer allocation failed
wi0: xmit failed
It worked fine with this configuration on current for many months. I'm not
sure if I am making progress or not:-)
ed
I'm using 5.0 current as of this morning.
Russell Cattelan wrote:
> Edwin Culp wrote:
>
> > On today's current, I plugged in my WaveLan Card that I haven't used for
> > about a week and it first has a problem with IRQ: wi0: No irq?!I
> > added some others and it responded with: wi0: No I/O space?! Has
> > something changed in the last few days that would cause this? My
> > network card DE-660 just keeps plugging away, thank goodness:-)
> >
> > Thanks for any help,
>
> That card is really sensitive to what base address and what irq is
> used, it can't conflict with anything.
>
> I've had better luck with setting the io to 0x100 in pccard.conf.
> irq 9 has worked, if you aren't using the parallel port disable it
> in the bios then irq 7 will be free.
>
> Now if I can only figure out why after upgrading my 4.0-RELEASE
> to the latest 4.0 the pccardd stops reading any info from the card.
>
> May 1 00:46:19 lupo pccardd[68136]: No card in database for ""("")
>
> >
> >
> > ed
> >
> > 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
kernel panic: swapon
Cvsup'ed this morning and built world. All went swimmingly until reboot. I got this kernel panic: swapon: adding /dev/da0s2b as swap device panic: blst_radix_free: freeing free block The ordering of the swap partions does matter. If /dev/da0s2b is first in /etc/fstab the panic occurs, if it's second no panic. === swapinfo === Device 1024-blocks UsedAvail Capacity Type /dev/rda2s2b 2569120 256912 0%Interleaved /dev/da0s2b 2569120 256912 0%Interleaved Total5138240 513824 0% === /etc/fstab === # DeviceMountpoint FStype Option Dump Pass# #/dev/da0s2bnoneswapsw 0 0 /dev/da0s1a / ufs rw 1 1 /dev/da0s4e /usrufs rw 2 2 /dev/da0s3e /varufs rw 2 2 /dev/da1s1a /u1 ufs rw 2 2 /dev/da2s2b noneswapsw 0 0 /dev/da2s1a /u2 ufs rw 2 2 /dev/cd0c /cdrom cd9660 ro,noauto 0 0 proc/proc procfs rw 0 0 /dev/da0s2b noneswapsw 0 0 #mount -t mfs -o rw,-s131072 /dev/da0s2b /tmp /dev/da0s2b /tmpmfs rw,-s131072 0 0 === dmesg === Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #9: Mon May 1 10:30:11 PDT 2000 sf@mephistopheles:/u2/src/sys/compile/MEPHISTOPHELES Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 451024690 Hz CPU: Pentium II/Pentium II Xeon/Celeron (451.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 268419072 (262128K bytes) avail memory = 257847296 (251804K bytes) Preloaded elf kernel "kernel" at 0xc0318000. VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c09da (c9da) VESA: S3 Incorporated. Trio64V+ Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 4.0 on pci0 isa0: on isab0 pci0: at 4.1 pci0: at 4.2 intpm0: port 0xe800-0xe80f irq 9 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision -1072247040 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped e400 ed0: port 0xd000-0xd01f irq 7 at device 9.0 on pci0 ed0: address 00:00:06:00:0a:79, type NE2000 (16 bit) sym0: <875> port 0xb800-0xb8ff mem 0xe280-0xe2800fff,0xe300-0xe3ff irq 14 at device 10.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking rl0: port 0xb400-0xb4ff mem 0xe200-0xe2ff irq 15 at device 11.0 on pci0 rl0: Ethernet address: 00:e0:29:61:2f:f6 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at 12.0 irq 10 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown0: at iomem 0-0x9,0x10-0xfff,0xe8000-0xe,0xf-0xf3fff,0xf4000-0xf7fff,0xf8000-0xf,0xca000-0xcbfff,0xfffe-0x on isa0 unknown: can't assign resources unknown1: at port 0x40-0x43 irq 0 on isa0 unknown2: at port 0x70-0x71 irq 8 on isa0 unknown: can't assign resources unknown3: at port 0xf0 irq 13 on isa0 unknown4: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown5: at port 0x61 on isa0 unknown6: at port 0xcf8-0xcff on isa0 unknown: can't assign resources esscontrol0: at port 0x800-0x807 on isa0 sbc0: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 pcm0: on sbc0 unknown7: at port 0x201 on isa0 Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a cd0 at sym0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 5.681MB/s transfers (5.681MHz, offset 15) cd0: cd present [68537 x 2048 byte records] da2 at sym0 bus 0 target 4 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da0
Re: HEADS UP: loader updated to handle module metadata
Boris Popov wrote: > Loader was updated to handle module metadata which was introduced > by recent updates in kernel linker. This is related to a new way of > declaration of module dependencies. Not only that, but once we've settled on a versioning scheme, we will be using dependency tags with version numbers in order to detect incompatable interface changes before the kld gets a chance to crash the system. In a nutshell, we have a couple of MODULE_*() macros that create small data structures in linker_set's. The loader now knows *exactly* what is in the static kernel, and *exactly* what is inside a kld file. Remember, a kld can have zero or more "modules", and many do. miibus.ko, for example has about 12 modules and none are actually called "miibus". The key thin here is that if you compile 'device miibus' into your kernel, the loader can see it, and if you try and preload one of the miibus drivers (eg: if_dc, if_vr etc), the loader will now know that it does not need to preload a 'miibus' module from somewhere. How these are packaged has an effect on the overall scheme of things. As a hypothetical example, it would be possible to do this: ld -shared -o netbundle.ko setdef0.o if_dc.kld if_vr.kld if_xl.kld \ miibus.kld setdef1.o If you then preloaded 'netbundle', then you will get a whole stack of modules in one chunk. If you then kldload if_sk (another miibus user), it would automatically become a dependency on netbundle.ko in order to use the miibus code contained within it's internals. If you hand't loaded netbundle.ko (or something else that contained the miibus internals) then it would guess and try and load miibus.ko for you. One thing that I have on my TODO list is an inversion of the kernel build mechanism so that config(8)'s replacement arranges for building all these intermediate .kld file bundles according to your compile options. (eg: SMP, INVARIANTS etc). As a final step, the build process takes these .kld intermediate files and produces a static kernel and/or the final kld packaging you requested. Of course, getting this all finished and working is proving to be 'entertaining' :-). Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Header includes and defines in freebsd 4-Stable [ISC-Bugs#102](bind9)
Greetings all.. It seems that there may be a small socket implementation issue with freebsd 4-Stable. I have been in disscussion with a few people from the isc bind 9 bug tracking department, and it seems that for the macro CMSG_NXTHDR to function in freebsd , the macro ALIGN must be defined. With both freebsd 3.4 as well as 4 that is defined in machine/param.h, but it seems that there is an include trail in releng 3 which makes that header eventually be included. I havent traced the include path yet, but I know that bind 9 compiles on freebsd 3 but not 4. The solution as I saw it (probably wrong ;) is to include either sys/param.h (which includes machine/param.h) or to include machine/param.h directly in the header which seems dependant on it which is sys/socket.h Below is some of the conversation with the developers for bind 9. I don't claim to know the repercussions of including either one in socket.h so go easy ;) just trying to get bind 9 to compile... ISC as decided to include sys/param.h in the bind 9 betas, but they would prefer if we "fixed" the includes because freebsd seems to be the only os with this issue... Thanks for all of the wonderful work everybody! Visigoth Damieon Stark Sr. Unix Systems Administrator [EMAIL PROTECTED] | - M$ Win 2K was built for the internet. | - Unix _BUILT_ the internet.| FreeBSD - The POWER to serve | http://www.freebsd.org your call...| | -- Forwarded message -- Date: Mon, 1 May 2000 11:12:27 -0700 (PDT) From: Michael Graff via RT <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [ISC-Bugs #102] (bind9) Compiling bind 9 b2 on freebsd 4.0-STABLE > grep ALIGN lib/isc/unix/*.c [nothing] > grep ALIGN /usr/include/sys/socket.h (struct cmsghdr *)((caddr_t)(cmsg) + ALIGN((cmsg)->cmsg_len))) That line is from the CMSG_NXTHDR() macro, which is how ipv6 options are set, among other things. If the socket.h file needs it (which it clearly does) it should arrange to have it included. >From "man socket" on FreeBSD, it indicates that: SYNOPSIS #include #include is enough. There is no man page for CMSG_NXTHDR. In any case, FreeBSD needs the ALIGN() macro for socket.h's compiliction if the CMSG_NXTHDR() macro is used. Other OSs include whatever files are necessary. We have added inclusion of for now, but once FreeBSD fixes their files we'll remove that, as it really isn't needed by anything other than FreeBSD. --Michael Visigoth via RT <[EMAIL PROTECTED]> writes: > On Sat, 29 Apr 2000, Michael Graff via RT wrote: > > > (David C Lawrence) via RT <[EMAIL PROTECTED]> writes: > > > > > I concur with Michael that it is a FreeBSD problem. A header file > > > should not depend on another header file having been included; any > > > functionality that the file provides that depends on another file in > > > order to work means the other file should be included. > > > > Not only that, but including a file should never, ever, > > happen from a portable program. > > > I couldn't agree with you more, which is why my patch included > sys/param.h which in turn includes machine/param.h. > > > > > I believe we do include which I was told would fix some > > of this, but really, FreeBSD's socket.h should include that if it > > depends on things in it. > > as of bind9 beta 2 does not include sys/param.h in > lib/isc/unix/socket.c, and I would disagree that defining ALIGN is not > necissary for a proper socket implementation. freebsd's own sys/socket.h > doesn't require support for ALIGN, only your (wonderful new) code does. I > don't mean to turn this into a large issue, but to my (and a few > others) best understanding your socket.c should include sys/param.h. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libstand ext2fs
> > Not sure if this is a silly question or not, but could the kernel somehow > view a specific dir on a ext2fs disk as the freebsd root and boot a > freebsd system from it? Also being able to access the stuff below the I think there's a more general need to have a loader variable which you can set for "chrootdir", that being the subdirectory of the rootfs which becomes "/". Such a feature would be good for a lot more than just hosting a FreeBSD system inside your existing Red Hat installation. :) Booting multiple versions of FreeBSD without having to play partition games comes to mind.. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libstand ext2fs
> > > > Not sure if this is a silly question or not, but could the kernel somehow > > view a specific dir on a ext2fs disk as the freebsd root and boot a > > freebsd system from it? Also being able to access the stuff below the > > I think there's a more general need to have a loader variable which > you can set for "chrootdir", that being the subdirectory of the rootfs > which becomes "/". Such a feature would be good for a lot more than > just hosting a FreeBSD system inside your existing Red Hat > installation. :) Booting multiple versions of FreeBSD without having > to play partition games comes to mind.. What sort of fallback behaviour would you want in case of error here? Calling chroot() inside the kernel before invoking init would be fairly easy, and I think that's all you'd need to get DWIM behaviour. (It might not be perfect, but it'd be pretty damn close.) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Header includes and defines in freebsd 4-Stable [ISC-Bugs#102] (bind9)
If memory serves me right, Visigoth wrote: > It seems that there may be a small socket implementation issue > with freebsd 4-Stable. I have been in disscussion with a few people from > the isc bind 9 bug tracking department, and it seems that for the macro > CMSG_NXTHDR to function in freebsd , the macro ALIGN must be > defined. We went through this exact same issue about six weeks ago, the problem being that pchar (a network measurement utility I wrote) needed the CMSG_* macros and started failing to build under 4.0-CURRENT. (I needed these macros for IPv6.) I lost track of the discussion for several reasons, but you can check the -current mailing list archives (look for CMSG_NXTHDR or some such thing like this). According to a very quick perusal of the CVS repository, it hasn't been solved yet. (i.e. FreeBSD still requires for CMSG_* to work properly.) Yoshinobu Inoue <[EMAIL PROTECTED]> is probably the best person to ask for more information on this. Bruce. PGP signature
Re: kernel panic at boot with 2 printers
On Fri, 28 Apr 2000, Leif Neland wrote: > Sorry not to have details at hand but anyways: > > Current cvsupped today. > > I have 2 parallel ports in use. > > I have had no problems with kernels dated 2 weeks or older, but since a few > days ago, the system crashes at boot while probing the parallel ports. "Page > fault while in supervisor mode", (I seem to remember vaguely) > OK: Here is bootmessages with BUS_DEBUG transcribed by hand: devclass_find_driver_internal:253:ppc in devclass isa device_probe_child:639: Trying ppc ppc0: parallel port found at 0x378 ppc0: SPP ppc0: at port 0x378-0x37f on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode device_add_child_ordered:525:ppbus at ppc with order 0 as unit -1 make_device:455:ppbus at ppc as unit -1 devclass_find_internal:113:looking for ppbus devclass_add_device:400:(null) om devclass ppbus devclass_alloc_unit:343:unit -1 in devclass ppbus devclass_alloc_unit:389:now:unit 0 in devclass ppbus devclass_find_driver_internal:253:ppbus in devclass ppc device_probe_child:639:Trying ppbus device_add_child_ordered:525:ppi at ppbus with order 0 as unit 0 make_device:455:ppi at ppbus as unit 0 devclass_add_device:400:(null) om devclass ppi devclass_alloc_unit:343:unit 0 in devclass ppi devclass_alloc_unit:389:now:unit 0 in devclass ppi device_add_child_ordered:525:lpt at ppbus with order 0 as unit 0 make_device:455:lpt at ppbus as unit 0 devclass_find_internal:113:looking for lpt devclass_add_device:400:(null) in devclass lpt devclass_alloc_unit:343:unit 0 in devclass lpt devclass_alloc_unit:399:now:unit0 in devclass lpt devclass_find_driver_internal:253:ppi in devclass ppbus device_probe_child:639:Trying ppi ppi0: on ppbus0 ppi0:can't allocate irq device_probe_and_attach:ppi0 attach returned 12 devclass_find_driver_internal:253:lpt in devclass ppbus device_probe_child:639:Trying lpt lpt0: on ppbus0 lpt0:polled port devclass_find_driver_internal:253:ppc in devclass isa device_probe_child:639:Trying ppc ppc1: parallel port found at 0x278 ppc1: SPP ppc1: at port 0x278-0x27f irq 5 on isa 0 ppc1:Generic chipset (NIBBLE-only) in COMPATIBLE mode device_add_child_ordered:525:ppbus at ppc with order 0 as unit -1 make_device:455:ppbus at ppc as unit -1 devclass_find_internal:113:looking for ppbus devclass_add_device:400:(null) in devclass ppbus devclass_alloc_unit:343:unit -1 in devclass ppbus devclass_alloc_unit:389:now:unit 1 in devclass ppbus devclass_find_driver_internal:253:ppbus in devclass ppc device_probe_child:639:Trying ppbus Fatal trap 12: page fault while in kernel mode fault virtual adress= 0xf0 ... stopped at bus_generic_probe+0x25: cmpl $0xc02a5cac,0(%ebx) ebx = 0xf0 Here's dmesg.boot for an older kernel which works. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #23: Tue Mar 14 06:08:53 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ARNOLD Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P5 (59.97-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x515 Stepping = 5 Features=0x1bf real memory = 117440512 (114688K bytes) avail memory = 110841856 (108244K bytes) Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 ncr0: port 0xd100-0xd1ff mem 0x2000-0x20ff irq 11 at device 1.0 on pci0 ncr0: driver is using old-style compatability shims isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at 6.0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3b0-0x3cf iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA (mono) <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16450 ppc0: at port 0x378-0x37f on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Polled port ppc1: at port 0x278-0x27f irq 5 on isa0 ppc1: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi1: on ppbus1 lpt1: on ppbus1 lpt1: Interrupt-driven port ed0 at port 0x340-0x35f iomem 0xd8000 irq 10 on isa0 ed0: supplying EUI64: 00:80:c8:ff:fe:18:9c:c2 ed0: address 00:80:c8:18:9c:c2, type NE2000 (16 bit) pca0 at port 0x40 on isa0 isic0: at port 0x200-0x201,0x202-0x203 irq 9 on isa0 i4b-L1-isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4btel: 2 ISDN telephony interface device(s) attached i4brbch: 4 raw B channel access device(s) attached i4btrc: 2 ISDN trace device(s) attached Waiting 5 seconds for SCSI devices to settle da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing
Re: cvs commit: src/lib/libstand ext2fs
> What sort of fallback behaviour would you want in case of error here? Just let chroot() either succeed or fail. It's own "fallback behavior" in such a case should prove adequate. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libstand ext2fs
> > What sort of fallback behaviour would you want in case of error here? > > Just let chroot() either succeed or fail. It's own "fallback behavior" > in such a case should prove adequate. :) Hmm. Failure to chroot == failure to start init? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
auth b614398f subscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hello High School Alumni
Dear High School Alumni, This email is to inform you of a new website that allows you to stay in touch with your high school friends. http://www.tdyalumni.com">www.tdyalumni.com Wouldn't it be great to surprise an old friend with an email. Spark up that old friendship, see what the captain of the football team is up to today, find out if the prom queen is still all that. Go to www.tdyalumni.com and contact them now! This is the number one site for contacting high school alumni. The Digital Yearbook allows you to create your own personal page, which mcan include now and then photos, yearbook pages, group/team photos, or your own collage of photos. With over 25,000 schools listed on The Digital Yearbook you are able to not only stay in touch with friends from your high school, but you are also able to rekindle friendships with people you meet from any other high school in the United States. If you would like to be removed from this automated mailing list please mailto:[EMAIL PROTECTED]?SUBJECT=REMOVE">CLICK HERE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MVP3 problems - current state?
In message <[EMAIL PROTECTED]> Soren Schmidt writes: : Ehm, is that a warning you have written or ?? I certainly havn't : issued this warning as the maintainer/author of the ata driver... I think that I wrote it, and that it is basically wrong. I'll look into correcting it. I think that the warnding should likely be changed to: if you have crappy disks, you'll be beter off in pio mode :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel panic at boot with 2 printers
I've had the opposite problem. ppc0: parallel port not found. for about the same period of time. ed Leif Neland wrote: > On Fri, 28 Apr 2000, Leif Neland wrote: > > > Sorry not to have details at hand but anyways: > > > > Current cvsupped today. > > > > I have 2 parallel ports in use. > > > > I have had no problems with kernels dated 2 weeks or older, but since a few > > days ago, the system crashes at boot while probing the parallel ports. "Page > > fault while in supervisor mode", (I seem to remember vaguely) > > > OK: Here is bootmessages with BUS_DEBUG transcribed by hand: > > devclass_find_driver_internal:253:ppc in devclass isa > device_probe_child:639: Trying ppc > ppc0: parallel port found at 0x378 > ppc0: SPP > ppc0: at port 0x378-0x37f on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > device_add_child_ordered:525:ppbus at ppc with order 0 as unit -1 > make_device:455:ppbus at ppc as unit -1 > devclass_find_internal:113:looking for ppbus > devclass_add_device:400:(null) om devclass ppbus > devclass_alloc_unit:343:unit -1 in devclass ppbus > devclass_alloc_unit:389:now:unit 0 in devclass ppbus > devclass_find_driver_internal:253:ppbus in devclass ppc > device_probe_child:639:Trying ppbus > device_add_child_ordered:525:ppi at ppbus with order 0 as unit 0 > make_device:455:ppi at ppbus as unit 0 > devclass_add_device:400:(null) om devclass ppi > devclass_alloc_unit:343:unit 0 in devclass ppi > devclass_alloc_unit:389:now:unit 0 in devclass ppi > device_add_child_ordered:525:lpt at ppbus with order 0 as unit 0 > make_device:455:lpt at ppbus as unit 0 > devclass_find_internal:113:looking for lpt > devclass_add_device:400:(null) in devclass lpt > devclass_alloc_unit:343:unit 0 in devclass lpt > devclass_alloc_unit:399:now:unit0 in devclass lpt > devclass_find_driver_internal:253:ppi in devclass ppbus > device_probe_child:639:Trying ppi > ppi0: on ppbus0 > ppi0:can't allocate irq > device_probe_and_attach:ppi0 attach returned 12 > devclass_find_driver_internal:253:lpt in devclass ppbus > device_probe_child:639:Trying lpt > lpt0: on ppbus0 > lpt0:polled port > devclass_find_driver_internal:253:ppc in devclass isa > device_probe_child:639:Trying ppc > ppc1: parallel port found at 0x278 > ppc1: SPP > ppc1: at port 0x278-0x27f irq 5 on isa 0 > ppc1:Generic chipset (NIBBLE-only) in COMPATIBLE mode > device_add_child_ordered:525:ppbus at ppc with order 0 as unit -1 > make_device:455:ppbus at ppc as unit -1 > devclass_find_internal:113:looking for ppbus > devclass_add_device:400:(null) in devclass ppbus > devclass_alloc_unit:343:unit -1 in devclass ppbus > devclass_alloc_unit:389:now:unit 1 in devclass ppbus > devclass_find_driver_internal:253:ppbus in devclass ppc > device_probe_child:639:Trying ppbus > > Fatal trap 12: page fault while in kernel mode > fault virtual adress= 0xf0 > ... > stopped at bus_generic_probe+0x25: cmpl $0xc02a5cac,0(%ebx) > > ebx = 0xf0 > > Here's dmesg.boot for an older kernel which works. > > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #23: Tue Mar 14 06:08:53 CET 2000 > [EMAIL PROTECTED]:/usr/src/sys/compile/ARNOLD > Timecounter "i8254" frequency 1193182 Hz > CPU: Pentium/P5 (59.97-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x515 Stepping = 5 > Features=0x1bf > real memory = 117440512 (114688K bytes) > avail memory = 110841856 (108244K bytes) > Intel Pentium detected, installing workaround for F00F bug > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > ncr0: port 0xd100-0xd1ff mem 0x2000-0x20ff irq 11 >at device 1.0 on pci0 > ncr0: driver is using old-style compatability shims > isab0: at device 2.0 on pci0 > isa0: on isab0 > pci0: at 6.0 > atkbdc0: at port 0x60-0x6f on isa0 > atkbd0: irq 1 on atkbdc0 > vga0: at port 0x3b0-0x3cf iomem 0xa-0xb on isa0 > sc0: on isa0 > sc0: VGA (mono) <16 virtual consoles, flags=0x200> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16450 > ppc0: at port 0x378-0x37f on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppi0: on ppbus0 > lpt0: on ppbus0 > lpt0: Polled port > ppc1: at port 0x278-0x27f irq 5 on isa0 > ppc1: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppi1: on ppbus1 > lpt1: on ppbus1 > lpt1: Interrupt-driven port > ed0 at port 0x340-0x35f iomem 0xd8000 irq 10 on isa0 > ed0: supplying EUI64: 00:80:c8:ff:fe:18:9c:c2 > ed0: address 00:80:c8:18:9c:c2, type NE2000 (16 bit) > pca0 at port 0x40 on isa0 > isic0: at port 0x200-0x201,0x202-0x203 irq 9 on isa0 > i4b-L1-isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow > i4b: ISDN call control device attached > i4bisppp: 4 ISDN SyncPPP device(s) attached > i4bctl: ISDN system control port attached > i4bipr: 4 IP over raw HDLC ISDN device(s) attac
