Re: The cbus driver for pc98
In message <[EMAIL PROTECTED]>, Takahashi Yoshihiro writes: >In article <[EMAIL PROTECTED]> >"M. Warner Losh" <[EMAIL PROTECTED]> writes: > >> Cbus is to ISA as CardBus is to PCI in many ways. Cbus is very much >> like ISA in all but a few details. CardBus is pci with a few twists >> and turns that differ. If you look at how we've implemented cardbus, >> you'll see that we've tried to do it as a 'subclass' of the pci bus. >> We implement the PCI interfaces in the cardbus bus code, even though >> it is not really a pci bus. I'd propose that cbus implements the ISA >> interfaces in a similar manner. > >If my understanding is not a mistake, the CardBus specifications is >derived from the PCI. Therefore, I can understand that the cardbus >driver depend on the pci driver. But, the Cbus is NOT derived from >the ISA. So, I think that the cbus driver should not depend on the >isa driver. This increasingly sounds like an emotional thing rather than a technical thing :-( -- 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
Wavelan problems
Since I deleted the original email of Michael Bretterklieber, I can't actually reply anymore :( This is what I would have replied: I can say nothing more than "me too", with a Lucent pC24E-H-ET, a generic lucent silver card. Dmesg info: wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:02:2d:0c:e1:24 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (7.28.1) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps And exact the same wicontrol output. I would like to add that, on enabeling the card (ifconfig wi0 up), my machine practically freezes, and when I pull the card out, I got my machine back most of the time... Dmesg info after doing "ifconfig wi0 up": wi0: timeout in wi_cmd 0x0002; event status 0x0080 wi0: timeout in wi_cmd 0x; event status 0x0080 wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: init failed wi0: timeout in wi_seek to fc00/0 wi0: timeout in wi_seek to fc81/0 wi0: timeout in wi_seek to fc0c/0 wi0: timeout in wi_seek to fc02/0 wi0: timeout in wi_seek to fc03/0 wi0: timeout in wi_seek to fc04/0 wi0: timeout in wi_seek to fc01/0 wi0: timeout in wi_seek to fc09/0 wi0: timeout in wi_seek to fc07/0 wi0: timeout in wi_seek to fc83/0 wi0: timeout in wi_seek to fc06/0 wi0: timeout in wi_seek to fc25/0 wi0: timeout in wi_seek to fc84/0 wi0: timeout in wi_seek to fc0e/0 wi0: timeout in wi_seek to fc85/0 wi0: timeout in wi_seek to fc20/0 wi0: timeout in wi_seek to fc80/0 wi0: wi_cmd: busy bit won't clear. wi0: failed to allocate 2372 bytes on NIC wi0: tx buffer allocation failed (error 12) wi0: interface not running wi0: wi_cmd: busy bit won't clear. wi0: detached (got this after unplugging the wi-card, to un-freeze the card. Kind regards, Maikel Verheijen Kind regards, Maikel Verheijen USER, n.: The word computer professionals use when they mean "idiot." -- Dave Barry, "Claw Your Way to the Top" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Optimizing "universe" somewhat
On Wed, Feb 19, 2003 at 07:40:19AM -0800, Ruslan Ermilov wrote:
> ru 2003/02/19 07:40:19 PST
>
> Modified files:
> .Makefile
> Log:
> Fixed universe.
>
> Folded pc98 into the common case.
> Retired ${JFLAG} (``make -jX universe'' should work).
>
> Revision ChangesPath
> 1.276 +30 -34src/Makefile
>
Would it be too bad (in anyone's opinion) if we optimize this
a bit to build modules only once for each architecture, with
buildworld (-DMODULES_WITH_WORLD)? That would speed-up the
creation of universe somewhat, but has one bad side effect of
polluting userland build with kernel stuff, but is easiest
to implement.
Another option would be to build modules only for the first
kernel for a given arch, whatever it happens to be. This is
still not quite good as kernel/modules may or may not be
independently broken.
Yet another option would be to still build modules once for
a given architecture, but independently of kernels and world.
Before I go for implementing this or that, I'd like people's
opinion on that.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg52758/pgp0.pgp
Description: PGP signature
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Feb 20 03:10:07 EST 2003 -- ===> unionfs touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/unionfs/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/unionfs. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimizing "universe" somewhat
In message <[EMAIL PROTECTED]>, Ruslan Ermilov writes:
>
>--/9DWx/yDrRhgMJTb
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Wed, Feb 19, 2003 at 07:40:19AM -0800, Ruslan Ermilov wrote:
>> ru 2003/02/19 07:40:19 PST
>>=20
>> Modified files:
>> .Makefile=20
>> Log:
>> Fixed universe.
>> =20
>> Folded pc98 into the common case.
>> Retired ${JFLAG} (``make -jX universe'' should work).
>> =20
>> Revision ChangesPath
>> 1.276 +30 -34src/Makefile
>>=20
>Would it be too bad (in anyone's opinion) if we optimize this
>a bit to build modules only once for each architecture, with
>buildworld (-DMODULES_WITH_WORLD)? That would speed-up the
>creation of universe somewhat, but has one bad side effect of
>polluting userland build with kernel stuff, but is easiest
>to implement.
I think we should build the modules as specified by the kernels.
Nothing prevents you from adding
makeoptions MODULES_OVERRIDE="acpi linux"
or similar to your kernels.
Universe just takes time, and that's it. Don't try to optimize it
if the result is less coverage.
--
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: top-of-tree alpha kernel panics during boot
Andrew Gallatin <[EMAIL PROTECTED]> writes: > Do you preload any/all of the things you've marked as klds? No... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimizing "universe" somewhat
On Thu, Feb 20, 2003 at 10:44:50AM +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Ruslan Ermilov writes:
> >
> >--/9DWx/yDrRhgMJTb
> >Content-Type: text/plain; charset=us-ascii
> >Content-Disposition: inline
> >Content-Transfer-Encoding: quoted-printable
> >
> >On Wed, Feb 19, 2003 at 07:40:19AM -0800, Ruslan Ermilov wrote:
> >> ru 2003/02/19 07:40:19 PST
> >>=20
> >> Modified files:
> >> .Makefile=20
> >> Log:
> >> Fixed universe.
> >> =20
> >> Folded pc98 into the common case.
> >> Retired ${JFLAG} (``make -jX universe'' should work).
> >> =20
> >> Revision ChangesPath
> >> 1.276 +30 -34src/Makefile
> >>=20
> >Would it be too bad (in anyone's opinion) if we optimize this
> >a bit to build modules only once for each architecture, with
> >buildworld (-DMODULES_WITH_WORLD)? That would speed-up the
> >creation of universe somewhat, but has one bad side effect of
> >polluting userland build with kernel stuff, but is easiest
> >to implement.
>
> I think we should build the modules as specified by the kernels.
>
> Nothing prevents you from adding
>
> makeoptions MODULES_OVERRIDE="acpi linux"
>
> or similar to your kernels.
>
> Universe just takes time, and that's it. Don't try to optimize it
> if the result is less coverage.
>
Okay, and this _is_ the easiest to implement, though I've found
some bogons with putting ``makeoptions NO_MODULES=yes'' that
need to be addressed.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg52762/pgp0.pgp
Description: PGP signature
ACPI: -dp2 vs. -release
I installed the DP2 release of current on my Toshiba laptop when it was released and acpi worked very well. When the powercable was disconected the profile changed to economic _and_ the screen was dimmed a little bit to save power. But with every other iso release or cvsup from head since, acpi doesn't dim the screen anymore when running on batteries? what has changed or what can I do to make this work again(besides reverting back t -dp2)? /Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Adding std::wstring and wchar_t support to GCC on -CURRENT
Hi, I posted to the GCC mailing list recently, mentioning that GCC under FreeBSD does not have std::wstring/wchar_t support. Alexander Kabaev posted a list of problems under FreeBSD, and some possible workarounds: http://gcc.gnu.org/ml/gcc/2003-02/msg01291.html Hopefully some of the FreeBSD header file problems will be resolved soon. For example, Mike Barcroft has mentioned an approach for adding WCHAR_MIN and WCHAR_MAX macros to by creating a new private header file. I followed Alex's instructions for creating a workaround, to enable wchar_t support in libstdc++, so I am posting my patches for those who may be interested. I think the wchar.h patch will be unnecessary once the fix is integrated in FreeBSD. I just rebuilt the world, and don't seem to have any problems yet! --- src/include/wchar.h.origWed Feb 19 17:21:14 2003 +++ include/wchar.h Thu Feb 20 03:20:32 2003 @@ -100,6 +100,14 @@ #defineWEOF((wint_t)-1) #endif +#ifndef WCHAR_MIN +#define WCHAR_MIN (-2147483647l - 1l) +#endif + +#ifndef WCHAR_MAX +#define WCHAR_MAX (2147483647l) +#endif + struct __sFILE; struct tm; --- src/gnu/lib/libstdc++/c++config.h.orig Wed Feb 19 13:35:27 2003 +++ src/gnu/lib/libstdc++/c++config.h Wed Feb 19 13:36:25 2003 @@ -108,6 +108,7 @@ // Define if code specialized for wchar_t should be used. /* #undef _GLIBCPP_USE_WCHAR_T */ +#define _GLIBCPP_USE_WCHAR_T 1 // Define if using setrlimit to limit memory usage during 'make check'. /* #undef _GLIBCPP_MEM_LIMITS */ --- src/contrib/libstdc++/include/c_std/std_cwchar.h.orig Wed Feb 19 13:37:36 2003 +++ src/contrib/libstdc++/include/c_std/std_cwchar.hWed Feb 19 13:38:05 2003 @@ -173,7 +173,7 @@ using ::wcsrtombs; using ::wcsspn; using ::wcstod; - using ::wcstof; + //using ::wcstof; using ::wcstok; using ::wcstol; using ::wcstoul; -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: -dp2 vs. -release
On Thu, Feb 20, 2003 at 02:45:27PM +0100, Peter Gade Jensen wrote: > I installed the DP2 release of current on my Toshiba laptop when it was > released and acpi worked very well. When the powercable was disconected > the profile changed to economic _and_ the screen was dimmed a little > bit to save power. But with every other iso release or cvsup from head > since, acpi doesn't dim the screen anymore when running on batteries? > what has changed or what can I do to make this work again(besides > reverting back t -dp2)? > I have the same feature on my Dell laptop. The screen's brightness (or dim if you want) will go down when the computer is running on batteries. It is however possible to change this back to normal with the "Fn" key (you probably have something similiar on your Toshiba) so that the brightness back to "normal." Dell laptops remember this, so the next time I run the computer on batteries it will restore the brightness to the level I had last time I used it on batteries. If the Toshiba is simliar in this way all you have to do is adjust the brightness level (can be done in the BIOS of Dell too) down to a desired level and it will remember it. I do not think this has anything to do with ACPI implimentation in FreeBSD. -- Morten Rodal msg52765/pgp0.pgp Description: PGP signature
Ethernet (xl) will not transmit or receive
I updated my 5.0 system built in late January to RELENG_5_0 on Sunday and the Ethernet was not working. I tried again last night with no change in behavior. The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B Ethernet which had been working fine on a kernel built in late January. The dmesg is not too meaningful, but the system shows no errors. It simply never receives a packet. ARPs are all incomplete and no packets are transmitted although netstat -in indicates that they are. The packets never actually reach the wire, though. I can't believe that no one else has this card, but I didn't find anything in the archives on it. Any idea what needs to be rolled back and how far? I'm suspicious that it might be an mii problem. Maybe even an interrupt issue. I an suspicious of the second, empty xlphy0: line in the dmesg, but the reported MAC is right and my old kernel that works seems to generate a similar empty line. Any clues or suggestions appreciated. Thanks, R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 --[[application/octet-stream Content-Disposition: attachment; filename="dmesg.boot"][7bit]] Copyright (c) 1992-2003 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-RELEASE-p1 #2: Wed Feb 19 22:47:50 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KZIN Preloaded elf kernel "/boot/kernel/kernel" at 0xc04a. Preloaded userconfig_script "/boot/kernel.conf" at 0xc04a00a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04a00f8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 451024032 Hz CPU: AMD-K6(tm) 3D+ Processor (451.02-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 Features=0x8021bf AMD Features=0x8800 real memory = 100646912 (95 MB) avail memory = 92729344 (88 MB) Initializing GEOMetry subsystem K6-family MTRR support enabled (2 registers) VESA: v2.0, 16384k memory, flags:0x1, mode table:0xc00c6974 (c0006974) VESA: Matrox Graphics Inc. npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 Using $PIR table, 8 entries at 0xc00f0ca0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 3.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pcm0: port 0xd800-0xd83f irq 9 at device 9.0 on pci0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xde00-0xde7f irq 10 at device 11.0 on pci0 xl0: Ethernet address: 00:50:da:80:4b:43 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: atapci0: port 0xd000-0xd00f at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 13031MB [26476/16/63] at ata0-master UDMA33 ad2: 13029MB [26473/16/63] at ata1-master UDMA33 acd0: CDROM at ata1-slave UDMA33 Mounting root from ufs:/dev/ad0s1a cd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
Kevin, I experienced similar issues yesterday when just installing release 5 from ftp (floppy boot). I essentially had to ifconfig the device down and then back up and it then seemed to continue ok... but I think there most likely something odd going on :/ Cheers, Andrew On Thu, 20 Feb 2003, Kevin Oberman wrote: :I updated my 5.0 system built in late January to RELENG_5_0 on Sunday :and the Ethernet was not working. I tried again last night with no :change in behavior. : :The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B :Ethernet which had been working fine on a kernel built in late :January. : :The dmesg is not too meaningful, but the system shows no errors. It :simply never receives a packet. ARPs are all incomplete and no packets :are transmitted although netstat -in indicates that they are. The :packets never actually reach the wire, though. : :I can't believe that no one else has this card, but I didn't find :anything in the archives on it. : :Any idea what needs to be rolled back and how far? I'm suspicious that :it might be an mii problem. Maybe even an interrupt issue. I an :suspicious of the second, empty xlphy0: line in the dmesg, but the :reported MAC is right and my old kernel that works seems to generate a :similar empty line. : :Any clues or suggestions appreciated. : :Thanks, : :R. Kevin Oberman, Network Engineer :Energy Sciences Network (ESnet) :Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) :E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 :--[[application/octet-stream :Content-Disposition: attachment; filename="dmesg.boot"][7bit]] :Copyright (c) 1992-2003 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-RELEASE-p1 #2: Wed Feb 19 22:47:50 PST 2003 :[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KZIN :Preloaded elf kernel "/boot/kernel/kernel" at 0xc04a. :Preloaded userconfig_script "/boot/kernel.conf" at 0xc04a00a8. :Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04a00f8. :Timecounter "i8254" frequency 1193182 Hz :Timecounter "TSC" frequency 451024032 Hz :CPU: AMD-K6(tm) 3D+ Processor (451.02-MHz 586-class CPU) : Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 : Features=0x8021bf : AMD Features=0x8800 :real memory = 100646912 (95 MB) :avail memory = 92729344 (88 MB) :Initializing GEOMetry subsystem :K6-family MTRR support enabled (2 registers) :VESA: v2.0, 16384k memory, flags:0x1, mode table:0xc00c6974 (c0006974) :VESA: Matrox Graphics Inc. :npx0: on motherboard :npx0: INT 16 interface :acpi0: on motherboard :ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 :ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 :Using $PIR table, 8 entries at 0xc00f0ca0 :acpi0: power button is handled as a fixed feature programming model. :Timecounter "ACPI-safe" frequency 3579545 Hz :acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 :acpi_cpu0: on acpi0 :pcib0: port 0xcf8-0xcff on acpi0 :pci0: on pcib0 :pcib1: at device 1.0 on pci0 :pci1: on pcib1 :pci1: at device 0.0 (no driver attached) :pci0: at device 3.0 (no driver attached) :isab0: at device 7.0 on pci0 :isa0: on isab0 :pcm0: port 0xd800-0xd83f irq 9 at device 9.0 on pci0 :xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xde00-0xde7f :irq 10 at device 11.0 on pci0 :xl0: Ethernet address: 00:50:da:80:4b:43 :miibus0: on xl0 :xlphy0: <3Com internal media interface> on miibus0 :xlphy0: :atapci0: port 0xd000-0xd00f at device 15.0 on pci0 :ata0: at 0x1f0 irq 14 on atapci0 :ata1: at 0x170 irq 15 on atapci0 :fdc0: port 0x3f7,0x3f2-0x3f5 :irq 6 drq 2 on acpi0 :fdc0: FIFO enabled, 8 bytes threshold :fd0: <1440-KB 3.5" drive> on fdc0 drive 0 :ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 :ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode :ppc0: FIFO with 16/16/7 bytes threshold :lpt0: on ppbus0 :lpt0: Interrupt-driven port :ppi0: on ppbus0 :sio0 port 0x3f8-0x3ff irq 4 on acpi0 :sio0: type 16550A :sio1 port 0x2f8-0x2ff irq 3 on acpi0 :sio1: type 16550A :atkbdc0: port 0x64,0x60 irq 1 on acpi0 :atkbd0: flags 0x1 irq 1 on atkbdc0 :kbd0 at atkbd0 :psm0: irq 12 on atkbdc0 :psm0: model Generic PS/2 mouse, device ID 0 :orm0: at iomem 0xc-0xc7fff on isa0 :pmtimer0 on isa0 :sc0: at flags 0x100 on isa0 :sc0: VGA <16 virtual consoles, flags=0x300> :vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 :Timecounters tick every 10.000 msec :ad0: DMA limited to UDMA33, non-ATA66 cable or device :ad0: 13031MB [26476/16/63] at ata0-master UDMA33 :ad2: 13029MB [26473/16/63] at ata1-master UDMA33 :acd0: CDROM at ata1-slave UDMA33 :Mounting root from ufs:/dev/ad0s1a :cd0 at ata1 bus 0 target 1 lun 0 :cd0: Removable CD-ROM SCSI-0 device :cd0: 33.000MB/s transfers :cd0: Attempt to query device size failed: NOT READY, Medium not present : :To Unsubs
Re: Page fault on disk-less machine
Terry Lambert wrote: Scott Long wrote: Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. This one, I imagine. Thanks! http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+current/cvs-all It wasn't clear that this was the same problem, with the other recent potentially destabilizing commits. I guess PHK, Lars, and Craig should try applying this, and seeing if it fixes things for them... Tried it, and it does not fix the panic for me. There must be another problem. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ethernet (xl) will not transmit or receive
Hi, On Thu, Feb 20, 2003 at 11:32:04AM -0500, Andrew R. Reiter wrote: > I experienced similar issues yesterday when just installing release 5 from > ftp (floppy boot). I essentially had to ifconfig the device down and then > back up and it then seemed to continue ok... but I think there most likely > something odd going on :/ > > On Thu, 20 Feb 2003, Kevin Oberman wrote: > :I updated my 5.0 system built in late January to RELENG_5_0 on Sunday > :and the Ethernet was not working. I tried again last night with no > :change in behavior. > : > :The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B > :Ethernet which had been working fine on a kernel built in late > :January. > : > :The dmesg is not too meaningful, but the system shows no errors. It > :simply never receives a packet. ARPs are all incomplete and no packets > :are transmitted although netstat -in indicates that they are. The > :packets never actually reach the wire, though. > : > :I can't believe that no one else has this card, but I didn't find > :anything in the archives on it. > : > :Any idea what needs to be rolled back and how far? I'm suspicious that > :it might be an mii problem. Maybe even an interrupt issue. I an > :suspicious of the second, empty xlphy0: line in the dmesg, but the > :reported MAC is right and my old kernel that works seems to generate a > :similar empty line. I have had the same problem with a "3Com 3c905B-COMBO". But the system was a 4.7-RELEASE. If you used the the media-Option in /etc/rc.conf it doesn't work. It was necessary to boot the system with a wrong media type, mark the interface down and mark the interface up with the correct media type. Than it works. But at that time I had no time to analyse this behaviour. Jan Here are the old boot messages (no errors): FreeBSD 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 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 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: AMD Duron(tm) Processor (756.74-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 Features=0x183f9ff AMD Features=0xc044<,AMIE,DSP,3DNow!> real memory = 134135808 (130992K bytes) avail memory = 125349888 (122412K bytes) Preloaded elf kernel "kernel" at 0xc050f000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc050f09c. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 9 entries at 0xc00f1720 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 pci1: on pcib2 pci1: at 0.0 irq 11 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xb400-0xb41f irq 9 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 9 at device 4.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered pci0: (vendor=0x1106, dev=0x3057) at 4.4 xl0: <3Com 3c905B-COMBO Fast Etherlink XL> port 0x9400-0x947f mem 0xdd00-0xdd7f irq 5 at device 10.0 on pci0 xl0: Ethernet address: 00:01:02:2f:42:0a miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0x7800-0x783f,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 mem 0xdc80-0xdc81 irq 10 at device 17.0 on pci0 ata2: at 0x9000 on atapci1 ata3: at 0x8400 on atapci1 pcib1: on motherboard pci2: on pcib1 orm0: at iomem 0xc-0xc97ff,0xcc000-0xc,0xd-0xd1fff on isa0 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: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 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: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 ... -- [ gpg key: http://nl3.physik.tu-berlin.de/~jan/jschlesn.gpg ] [ key fingerprint: 4236 3497 C4CF 4F3A 274F B6E2 C4F6 B639 1DF4 CF0A ] -- It's better to reign in hell, than to serve in heaven... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP! ATA driver changes committed.
The first round of ATA updates/fixes has been committed, please let me know if you find any problems with it... The commitlog say: This moves all chipset specific code to a new file 'ata-chipset.c'. Extensive use of tables and pointers to avoid having the same switch on chipset type in several places, and to allow substituting various functions for different HW arch needs. Added PIO mode setup and all DMA modes. Support for all known SiS chipsets. Thanks to Christoph Kukulies for sponsoring a nice ASUS P4S8X SiS648 based board for this work! Tested on: i386, PC98, alpha and sparc64 -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: -dp2 vs. -release
On Thu, Feb 20, 2003 at 04:49:56PM +0100, Morten Rodal wrote: > I have the same feature on my Dell laptop. The screen's brightness > (or dim if you want) will go down when the computer is running on > batteries. yes this happens with a 5.0-DP2 kernel. BUT not with a never kernel. > It is however possible to change this back to normal with > the "Fn" key (you probably have something similiar on your Toshiba) so > that the brightness back to "normal." Dell laptops remember this, so > the next time I run the computer on batteries it will restore the > brightness to the level I had last time I used it on batteries. The Fn-keys for turning the brightness up/down doesn't work with 5.0 on my laptop. > I do not think this has anything to do with ACPI implimentation in > FreeBSD. Since the brightness was turned down because the machine was put into economy-mode and the powermanagment is handled by the ACPI subsystem, I would believe that has. So the real question is: Can you configure the economy-profile to start doing it again? /peter -- If you hold a Unix shell to your ear, do you hear the C? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
Ive run into the exact same problem on about 8 machines now, all running different network cards. The network will just simply not work if I have IPFILTER built into the kernel. On some of the machines, I started getting "No route to host". This has happened on the following network cards: 3COM 3C905C 3COM 3C450 *yes, 450* Linksys LNE100TX v4 Linksys LNE100TX v5 NETGEAR Fast 100 Intel Pro 10/100+ Intel Pro 10/100/1000 (gigabit over copper) Im going to assume that since it's not on a specific card, it's not something with the drivers for that card. The only thing I could do was deinstall IPFILTER. I tried wiping the ARP tables (showed incomplete arp entries for all hosts) and even redoing the routing table. The only thing that I could get that would fix it was removing ipfiter. I have another 5.0-CURRENT machine (FreeBSD 5.0-CURRENT #2: Wed Jan 29 17:55:34 CST 2003 root@edge:/usr/obj/usr/src/sys/edge i386) that is NOT having this problem. It's something done fairly recently that has caused this. Im going to go through and see if I cant find some differences between the source for that version and this one: 5.0-CURRENT #1: Wed Feb 19 10:28:49 GMT 2003 root@ender:/usr/obj/usr/src/sys/ender i386 The second one (last one I gave uname for) is the most recent to have the problems. As you can see, it's source from earlier this week. There's no errors on dmesg nor are there any errors anywhere. It just seems that if IPFILTER is enabled, the network devices are completely inoperable. I know you're going to ask how I have the rules setup, and I have tried many variations. The first I tried is a DEFAULT_BLOCK using a working ruleset from a 4.7-R-p3 machine. After that failed, I tried doing a default allow, and it still did it. The only feasible way to get the machine online with that source is to rip out IPFILTER. Anyone having similiar issues? Any comments/suggestions would be more than welcome, as having boxes on the network with no firewall is just asking for trouble ;) Regards, Nick H. [EMAIL PROTECTED] - Original Message - From: "Jan Schlesner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 20, 2003 12:44 PM Subject: Re: Ethernet (xl) will not transmit or receive : Hi, : : On Thu, Feb 20, 2003 at 11:32:04AM -0500, Andrew R. Reiter wrote: : > I experienced similar issues yesterday when just installing release 5 from : > ftp (floppy boot). I essentially had to ifconfig the device down and then : > back up and it then seemed to continue ok... but I think there most likely : > something odd going on :/ : > : > On Thu, 20 Feb 2003, Kevin Oberman wrote: : > :I updated my 5.0 system built in late January to RELENG_5_0 on Sunday : > :and the Ethernet was not working. I tried again last night with no : > :change in behavior. : > : : > :The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B : > :Ethernet which had been working fine on a kernel built in late : > :January. : > : : > :The dmesg is not too meaningful, but the system shows no errors. It : > :simply never receives a packet. ARPs are all incomplete and no packets : > :are transmitted although netstat -in indicates that they are. The : > :packets never actually reach the wire, though. : > : : > :I can't believe that no one else has this card, but I didn't find : > :anything in the archives on it. : > : : > :Any idea what needs to be rolled back and how far? I'm suspicious that : > :it might be an mii problem. Maybe even an interrupt issue. I an : > :suspicious of the second, empty xlphy0: line in the dmesg, but the : > :reported MAC is right and my old kernel that works seems to generate a : > :similar empty line. : : I have had the same problem with a "3Com 3c905B-COMBO". But the system : was a 4.7-RELEASE. If you used the the media-Option in /etc/rc.conf it : doesn't work. It was necessary to boot the system with a wrong media : type, mark the interface down and mark the interface up with the correct : media type. Than it works. But at that time I had no time to analyse : this behaviour. : : Jan : : Here are the old boot messages (no errors): : : FreeBSD 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 : 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 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 : [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC : Timecounter "i8254" frequency 1193182 Hz : CPU: AMD Duron(tm) Processor (756.74-MHz 686-class CPU) : Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 : Features=0x183f9ff : AMD Features=0xc044<,AMIE,DSP,3DNow!> : real memory = 134135808 (130992K bytes) : avail memory = 125349888 (122412K bytes) : Preloaded elf kernel "kernel" at 0xc050f000. : Preloaded userconfig_script "/boot/kernel.conf" at 0xc050f09c. : Pentium Pro MTRR support enabled : md0: Malloc disk : Using $PIR table, 9 entries at
Re: Ethernet (xl) will not transmit or receive
Nick H. -- Technical Support Engineer wrote: > Ive run into the exact same problem on about 8 machines now, all running > different network cards. The network will just simply not work if I have > IPFILTER built into the kernel. On some of the machines, I started getting > "No route to host". This has happened on the following network cards: > > 3COM 3C905C > 3COM 3C450 *yes, 450* > Linksys LNE100TX v4 > Linksys LNE100TX v5 > NETGEAR Fast 100 > Intel Pro 10/100+ > Intel Pro 10/100/1000 (gigabit over copper) > > Im going to assume that since it's not on a specific card, it's not > something with the drivers for that card. The only thing I could do was > deinstall IPFILTER. I tried wiping the ARP tables (showed incomplete arp > entries for all hosts) and even redoing the routing table. The only thing > that I could get that would fix it was removing ipfiter. I have another > 5.0-CURRENT machine (FreeBSD 5.0-CURRENT #2: Wed Jan 29 17:55:34 CST 2003 > root@edge:/usr/obj/usr/src/sys/edge i386) that is NOT having this problem. > It's something done fairly recently that has caused this. Im going to go > through and see if I cant find some differences between the source for that > version and this one: 5.0-CURRENT #1: Wed Feb 19 10:28:49 GMT 2003 > root@ender:/usr/obj/usr/src/sys/ender i386 > > The second one (last one I gave uname for) is the most recent to have the > problems. As you can see, it's source from earlier this week. There's no > errors on dmesg nor are there any errors anywhere. It just seems that if > IPFILTER is enabled, the network devices are completely inoperable. I know > you're going to ask how I have the rules setup, and I have tried many > variations. The first I tried is a DEFAULT_BLOCK using a working ruleset > from a 4.7-R-p3 machine. After that failed, I tried doing a default allow, > and it still did it. The only feasible way to get the machine online with > that source is to rip out IPFILTER. Anyone having similiar issues? > > Any comments/suggestions would be more than welcome, as having boxes on the > network with no firewall is just asking for trouble ;) Are you sure the ipfilter version of your kernel is in sync with your userland ipfilter utility? ipf -V will show you both versions. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
I am absolutely sure, as its on a completely fresh system. ipf: IP Filter: v3.4.29 (336) Kernel: IP Filter: v3.4.29 - Original Message - From: "Maxime Henrion" <[EMAIL PROTECTED]> To: "Nick H. -- Technical Support Engineer" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, February 20, 2003 3:11 PM Subject: Re: Ethernet (xl) will not transmit or receive : Nick H. -- Technical Support Engineer wrote: : > Ive run into the exact same problem on about 8 machines now, all running : > different network cards. The network will just simply not work if I have : > IPFILTER built into the kernel. On some of the machines, I started getting : > "No route to host". This has happened on the following network cards: : > : > 3COM 3C905C : > 3COM 3C450 *yes, 450* : > Linksys LNE100TX v4 : > Linksys LNE100TX v5 : > NETGEAR Fast 100 : > Intel Pro 10/100+ : > Intel Pro 10/100/1000 (gigabit over copper) : > : > Im going to assume that since it's not on a specific card, it's not : > something with the drivers for that card. The only thing I could do was : > deinstall IPFILTER. I tried wiping the ARP tables (showed incomplete arp : > entries for all hosts) and even redoing the routing table. The only thing : > that I could get that would fix it was removing ipfiter. I have another : > 5.0-CURRENT machine (FreeBSD 5.0-CURRENT #2: Wed Jan 29 17:55:34 CST 2003 : > root@edge:/usr/obj/usr/src/sys/edge i386) that is NOT having this problem. : > It's something done fairly recently that has caused this. Im going to go : > through and see if I cant find some differences between the source for that : > version and this one: 5.0-CURRENT #1: Wed Feb 19 10:28:49 GMT 2003 : > root@ender:/usr/obj/usr/src/sys/ender i386 : > : > The second one (last one I gave uname for) is the most recent to have the : > problems. As you can see, it's source from earlier this week. There's no : > errors on dmesg nor are there any errors anywhere. It just seems that if : > IPFILTER is enabled, the network devices are completely inoperable. I know : > you're going to ask how I have the rules setup, and I have tried many : > variations. The first I tried is a DEFAULT_BLOCK using a working ruleset : > from a 4.7-R-p3 machine. After that failed, I tried doing a default allow, : > and it still did it. The only feasible way to get the machine online with : > that source is to rip out IPFILTER. Anyone having similiar issues? : > : > Any comments/suggestions would be more than welcome, as having boxes on the : > network with no firewall is just asking for trouble ;) : : Are you sure the ipfilter version of your kernel is in sync with your : userland ipfilter utility? ipf -V will show you both versions. : : Cheers, : Maxime : : To Unsubscribe: send mail to [EMAIL PROTECTED] : with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
> From: "Nick H." <[EMAIL PROTECTED]> > Date: Thu, 20 Feb 2003 15:33:21 -0600 > Sender: [EMAIL PROTECTED] > > I am absolutely sure, as its on a completely fresh system. > > ipf: IP Filter: v3.4.29 (336) > Kernel: IP Filter: v3.4.29 > > > > - Original Message - > From: "Maxime Henrion" <[EMAIL PROTECTED]> > To: "Nick H. -- Technical Support Engineer" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, February 20, 2003 3:11 PM > Subject: Re: Ethernet (xl) will not transmit or receive > > > : Nick H. -- Technical Support Engineer wrote: > : > Ive run into the exact same problem on about 8 machines now, all running > : > different network cards. The network will just simply not work if I > have > : > IPFILTER built into the kernel. On some of the machines, I started > getting > : > "No route to host". This has happened on the following network cards: > : > > : > 3COM 3C905C > : > 3COM 3C450 *yes, 450* > : > Linksys LNE100TX v4 > : > Linksys LNE100TX v5 > : > NETGEAR Fast 100 > : > Intel Pro 10/100+ > : > Intel Pro 10/100/1000 (gigabit over copper) > : > > : > Im going to assume that since it's not on a specific card, it's not > : > something with the drivers for that card. The only thing I could do was > : > deinstall IPFILTER. I tried wiping the ARP tables (showed incomplete > arp > : > entries for all hosts) and even redoing the routing table. The only > thing > : > that I could get that would fix it was removing ipfiter. I have another > : > 5.0-CURRENT machine (FreeBSD 5.0-CURRENT #2: Wed Jan 29 17:55:34 CST > 2003 > : > root@edge:/usr/obj/usr/src/sys/edge i386) that is NOT having this > problem. > : > It's something done fairly recently that has caused this. Im going to > go > : > through and see if I cant find some differences between the source for > that > : > version and this one: 5.0-CURRENT #1: Wed Feb 19 10:28:49 GMT 2003 > : > root@ender:/usr/obj/usr/src/sys/ender i386 > : > > : > The second one (last one I gave uname for) is the most recent to have > the > : > problems. As you can see, it's source from earlier this week. There's > no > : > errors on dmesg nor are there any errors anywhere. It just seems that > if > : > IPFILTER is enabled, the network devices are completely inoperable. I > know > : > you're going to ask how I have the rules setup, and I have tried many > : > variations. The first I tried is a DEFAULT_BLOCK using a working > ruleset > : > from a 4.7-R-p3 machine. After that failed, I tried doing a default > allow, > : > and it still did it. The only feasible way to get the machine online > with > : > that source is to rip out IPFILTER. Anyone having similiar issues? > : > > : > Any comments/suggestions would be more than welcome, as having boxes on > the > : > network with no firewall is just asking for trouble ;) > : > : Are you sure the ipfilter version of your kernel is in sync with your > : userland ipfilter utility? ipf -V will show you both versions. This may be a different problem from mine. I do not use IPFILTER. It is possible that it is triggered by different things. In my case I can confirm that NO packets were ether sent or received. IF it is happening with several different cards, I might start to suspect an mii problem. That would fit the symptoms pretty well. (I think all of the referenced interfaces use mii.) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
In arved.freebsd.current, you wrote: > I updated my 5.0 system built in late January to RELENG_5_0 on Sunday > and the Ethernet was not working. I tried again last night with no > change in behavior. > > The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B > Ethernet which had been working fine on a kernel built in late > January. > > The dmesg is not too meaningful, but the system shows no errors. It > simply never receives a packet. ARPs are all incomplete and no packets > are transmitted although netstat -in indicates that they are. The > packets never actually reach the wire, though. > > I can't believe that no one else has this card, but I didn't find > anything in the archives on it. > > Any idea what needs to be rolled back and how far? I'm suspicious that > it might be an mii problem. Maybe even an interrupt issue. I an > suspicious of the second, empty xlphy0: line in the dmesg, but the > reported MAC is right and my old kernel that works seems to generate a > similar empty line. Check out the Errata http://www.freebsd.org/releases/5.0R/errata.html There is an item for the xl0 driver, although your problem looks different then mine. regards tilman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
On Thu, 20 Feb 2003, Nick H. wrote: :I am absolutely sure, as its on a completely fresh system. : :ipf: IP Filter: v3.4.29 (336) :Kernel: IP Filter: v3.4.29 Maxime, FWIW, my troubles were with the 5.0-RELEASE boot floppies (booted off them to install -RELEASE on my blazing speed demon dual ppro 200). Cheers, Andrew : : : :- Original Message - :From: "Maxime Henrion" <[EMAIL PROTECTED]> :To: "Nick H. -- Technical Support Engineer" <[EMAIL PROTECTED]> :Cc: <[EMAIL PROTECTED]> :Sent: Thursday, February 20, 2003 3:11 PM :Subject: Re: Ethernet (xl) will not transmit or receive : : :: Nick H. -- Technical Support Engineer wrote: :: > Ive run into the exact same problem on about 8 machines now, all running :: > different network cards. The network will just simply not work if I :have :: > IPFILTER built into the kernel. On some of the machines, I started :getting :: > "No route to host". This has happened on the following network cards: :: > :: > 3COM 3C905C :: > 3COM 3C450 *yes, 450* :: > Linksys LNE100TX v4 :: > Linksys LNE100TX v5 :: > NETGEAR Fast 100 :: > Intel Pro 10/100+ :: > Intel Pro 10/100/1000 (gigabit over copper) :: > :: > Im going to assume that since it's not on a specific card, it's not :: > something with the drivers for that card. The only thing I could do was :: > deinstall IPFILTER. I tried wiping the ARP tables (showed incomplete :arp :: > entries for all hosts) and even redoing the routing table. The only :thing :: > that I could get that would fix it was removing ipfiter. I have another :: > 5.0-CURRENT machine (FreeBSD 5.0-CURRENT #2: Wed Jan 29 17:55:34 CST :2003 :: > root@edge:/usr/obj/usr/src/sys/edge i386) that is NOT having this :problem. :: > It's something done fairly recently that has caused this. Im going to :go :: > through and see if I cant find some differences between the source for :that :: > version and this one: 5.0-CURRENT #1: Wed Feb 19 10:28:49 GMT 2003 :: > root@ender:/usr/obj/usr/src/sys/ender i386 :: > :: > The second one (last one I gave uname for) is the most recent to have :the :: > problems. As you can see, it's source from earlier this week. There's :no :: > errors on dmesg nor are there any errors anywhere. It just seems that :if :: > IPFILTER is enabled, the network devices are completely inoperable. I :know :: > you're going to ask how I have the rules setup, and I have tried many :: > variations. The first I tried is a DEFAULT_BLOCK using a working :ruleset :: > from a 4.7-R-p3 machine. After that failed, I tried doing a default :allow, :: > and it still did it. The only feasible way to get the machine online :with :: > that source is to rip out IPFILTER. Anyone having similiar issues? :: > :: > Any comments/suggestions would be more than welcome, as having boxes on :the :: > network with no firewall is just asking for trouble ;) :: :: Are you sure the ipfilter version of your kernel is in sync with your :: userland ipfilter utility? ipf -V will show you both versions. :: :: Cheers, :: Maxime :: :: 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 : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reboot(8) when fsck_ufs is running ?
Date: Sat, 15 Feb 2003 00:50:01 +0100 (CET) From: Martin Blapp <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Kirk McKusick <[EMAIL PROTECTED]> Subject: Reboot(8) when fsck_ufs is running ? Hi all, I don't know what the behaviour should be, but when I try to reboot a box which has fsck_ufs is running, it doesn't reboot and I have to powercycle it. Looks also like it just hangs. Do you experience the same at your side ? Shouln't we abort the fsck_ufs and reboot ? Martin Assuming that you are running fsck_ufs as part of a background fsck, the problem is probably that the fsck_ufs is in the midst of creating a snapshot. At the moment, snapshot creation is not interruptable, so the reboot is waiting for it to finish. I am presently investigating a bug which causes snapshots of filesystems bigger than about 250Gb to hang the kernel due to buffer starvation. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet (xl) will not transmit or receive
> Date: Thu, 20 Feb 2003 22:41:11 +0100 > From: Tilman Linneweh <[EMAIL PROTECTED]> > > Check out the Errata > http://www.freebsd.org/releases/5.0R/errata.html There is an item > for the xl0 driver, although your problem looks different then mine. Not the problem. First, the interface was working fine with 5.0-Release. The problem occurred after updating to RELENG_5_0. Second, I just have a broken xl0, no panics. Thanks. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck deadlocks with ufs2 and big disk
Vallo Kallaste <[EMAIL PROTECTED]> wrote: > I'll second Brad's statement about vinum and softupdates > interactions. My last experiments with vinum were more than half a > year ago, but I guess it still holds. BTW, the interactions showed > up _only_ on R5 volumes. I had 6 disk (SCSI) R5 volume in Compaq > Proliant 3000 and the system was very stable before I enabled > softupdates.. and of course after I disabled softupdates. In between > there were crashes and nasty problems with filesystem. Unfortunately > it was production system and I hadn't chanche to play. Did you believe that the crashes were caused by enabling softupdates on an R5 vinum volume, or were the crashes unrelated to vinum/softupdates? I can see how crashes unrelated to vinum/softupdates might trash vinum filesystems. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
As Kevin Oberman wrote: > > Can you suspend from within graphics mode? > Have you tried using APMD to put the display into text mode when > suspending? Tried it, but didn't get that to work. I. e., it seems apmd never calls /etc/rc.suspend (i can't see any syslog entry from that logger call either). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck deadlocks with ufs2 and big disk
At 2:28 PM -0800 2003/02/20, Darryl Okahata wrote: Did you believe that the crashes were caused by enabling softupdates on an R5 vinum volume, or were the crashes unrelated to vinum/softupdates? I can see how crashes unrelated to vinum/softupdates might trash vinum filesystems. Using RAID-5 under vinum was always a somewhat tricky business for me, but in many cases I could get it to work reasonably well most of the time. But if I enabled softupdates on that filesystem, I was toast. Softupdates enabled on filesystems that were not on top of vinum RAID-5 logical devices seemed to be fine. So, the interaction that I personally witnessed was specifically between vinum RAID-5 and softupdates. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unable to do a clean reboot
Thank you, Tony! I certainly have SCHED_ULE in my kernel config - that explains it. Grateful, David On Thu, Feb 20, 2003 at 09:34:47AM +0200, Tony Harverson wrote: > Hey There.. > > I would guess you're using SCHED_ULE in your Kernel config? It seems to > cause shutdown problems that haven't been addressed yet.. > > Tony > > -Original Message- > From: David Kleiner [mailto:[EMAIL PROTECTED]] > Sent: 20 February 2003 05:45 > To: [EMAIL PROTECTED] > Subject: Unable to do a clean reboot > > > Hi, > > Since I went to -current by way of 5.0-Rel, I was unable to > do a clean shutdown or reboot. No matter how I tried it, > 2-8 buffers always remain there during sync'ing. > > It goes like this: > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > Waiting (max 60 seconds) for system process `bufdaemon' to > stop...stopped Waiting (max 60 seconds) for system process `syncer' to > stop...stopped > > syncing disks, buffers remaining... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 > 2 2 giving up on 2 buffers > > > wallaby# uname -a > FreeBSD wallaby.pacbell.net 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Tue Feb > 18 21:06:18 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/W > i386 > > It's a PCGR505-TE Sony Vaio laptop with this disk: > > ad0: 38154MB [77520/16/63] at ata0-master UDMA100 > > Any suggestions? > > Thank you, > > David > > 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
Unable to shutdown cleanly
Hello, I'm unable to shutdown cleanly. What happens is I get the message the following message and the system freezes. I've used GENERIC as well as a custom kernel. If I shutdown to single user then umount everything but / I still get the same problems. The system runs a background fsck after rebooting. Last message I see : Waiting (max 60 seconds) for system process `vnlru' to stop...stopped To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
config files and includes.
I have just gone through the process of upgrading or installing several hundred machines, and Thst includes altering or editing many config files in /etc. I like the way that rc.conf is handled, in that defaults/rc.comf can be updated and only the local changes live in r.conf. I wish that more files had this capability. For example syslogd.conf or newsyslog.conf are updated between releases but they are also prime candidates for local additions. What would be really cool is if more config files could do 'includes' so that you could have a syslogd.local.conf wher eall your local entries could be. In addition you could make it look in /usr/local/etc/syslogd.conf for loging requirments for packages. To do this for every config file would be a lot of work. I do wonder however whether there couldn't be some "config-file reader" library routine that could be used to pre-pass files and do inclusions.. if the interface was very similar to what is usually used (people tend to either use open/read/close or fopen/fscanf (etc). equivalent calls could be made that use a stream of data that is pre-processed to do inclusions etc. That would making retrofitting relatively easy. Programs that use yacc/lex ar emore difficult, but I haven't looked into it.. anyhow, that was just a thought. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unable to shutdown cleanly
On Thu, Feb 20, 2003 at 09:31:39PM -0500, Scott Dodson wrote: > Hello, I'm unable to shutdown cleanly. What happens is I get the > message the following message and the system freezes. I've used > GENERIC as well as a custom kernel. If I shutdown to single user > then umount everything but / I still get the same problems. The system > runs a background fsck after rebooting. > > Last message I see : > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > I get the same thing on a DeLL 4100 with an Intel 845 chipset. It is in all likelihood related to ACPI, check the list archive for info on how to disable acpi.ko from loading. something about loader.conf. I've been accepting this behavior just so I can test the background fsck every time I boot into -CURRENT. --clark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
config files and includes.
< said: > What would be really cool is if more config files could > do 'includes' so that you could have a syslogd.local.conf > wher eall your local entries could be. In addition you could make it > look in /usr/local/etc/syslogd.conf for loging requirments for > packages. Well, it's a trivial part of XML but the syntax is twisted. The problem is that, particularly in the case of something like syslog.conf, you need to change the defaults, not just supplement them. Right now syslog has no concept of this (and changing the notation doesn't help without a complete rethink of the syslog.conf semantics). Worthwhile, but a lot of work for which nobody will be grateful (instead they will all complain that you changed the format of the file). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config files and includes.
- Julian Elischer's Original Message -
>
> I have just gone through the process of upgrading or installing several
> hundred machines, and Thst includes altering or editing many config
> files in /etc. I like the way that rc.conf
> is handled, in that defaults/rc.comf can be updated and only the
> local changes live in r.conf. I wish that more files had this
> capability.
This is not exactly what you are asking for, but this is from
a petty much a been-there/done-that many years ago. Typing in
the logic from memory:
rcfiles="/etc/inetd.conf /etc/syslog.conf /etc/newsyslog.conf"
for rcf in $rcfiles; do
if [ -f ${rcf}.local ]; then
if [ ! -f ${rcf}.base ]; then
if diff ${rcf} ${rcf}.base > /dev/null; then
cp -p ${rcf} ${rcf}.base
fi
fi
cat ${rcf}.base ${rcf}.local > ${rcf}
fi
done
I think you can get the idea.
-John
> For example syslogd.conf or newsyslog.conf are updated between releases
> but they are also prime candidates for local additions.
> What would be really cool is if more config files could
> do 'includes' so that you could have a syslogd.local.conf
> wher eall your local entries could be. In addition you could make it
> look in /usr/local/etc/syslogd.conf for loging requirments for
> packages.
>
> To do this for every config file would be a lot of work. I do wonder
> however whether there couldn't be some "config-file reader" library
> routine that could be used to pre-pass files and do inclusions..
>
> if the interface was very similar to what is usually used
> (people tend to either use open/read/close or
> fopen/fscanf (etc).
>
> equivalent calls could be made that use a stream of data that is
> pre-processed to do inclusions etc. That would making retrofitting
> relatively easy. Programs that use yacc/lex ar emore difficult,
> but I haven't looked into it..
>
> anyhow, that was just a thought.
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
--
As said by Napolean Bonaparte:
"Never ascribe to malice, that which is adequately explained by incompetence"
After being embraced by MS:
"When accused of malice, always hide behind incompetence".
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: config files and includes.
On Thu, 20 Feb 2003, Garrett Wollman wrote: > < >said: > > > What would be really cool is if more config files could > > do 'includes' so that you could have a syslogd.local.conf > > wher eall your local entries could be. In addition you could make it > > look in /usr/local/etc/syslogd.conf for loging requirments for > > packages. > > Well, it's a trivial part of XML but the syntax is twisted. The > problem is that, particularly in the case of something like > syslog.conf, you need to change the defaults, not just supplement > them. Right now syslog has no concept of this (and changing the > notation doesn't help without a complete rethink of the syslog.conf > semantics). Worthwhile, but a lot of work for which nobody will be > grateful (instead they will all complain that you changed the format > of the file). of course.. New functionality vs POLA. An age old conflict. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config files and includes.
On Thu, 20 Feb 2003, John De Boskey wrote:
> - Julian Elischer's Original Message -
> >
> > I have just gone through the process of upgrading or installing several
> > hundred machines, and Thst includes altering or editing many config
> > files in /etc. I like the way that rc.conf
> > is handled, in that defaults/rc.comf can be updated and only the
> > local changes live in r.conf. I wish that more files had this
> > capability.
>
> This is not exactly what you are asking for, but this is from
> a petty much a been-there/done-that many years ago. Typing in
> the logic from memory:
>
> rcfiles="/etc/inetd.conf /etc/syslog.conf /etc/newsyslog.conf"
>
> for rcf in $rcfiles; do
>if [ -f ${rcf}.local ]; then
> if [ ! -f ${rcf}.base ]; then
> if diff ${rcf} ${rcf}.base > /dev/null; then
> cp -p ${rcf} ${rcf}.base
> fi
> fi
> cat ${rcf}.base ${rcf}.local > ${rcf}
>fi
> done
>
> I think you can get the idea.
yeah but we don't distribute our files like that..
you get a new syslogd.conf when you upgrade, not a syslogd.conf.base
(unfortunartly)
I considered this possibilty. especially as many daemons etc.
have an argument that they can take for a config file, and the argument
is often changeable from rc.conf.
e.g.
. /usr/local/concatfiles
syslogd_flags="-s -f/etc/syslogd.local"
[...]
where
/usr/local/concatfiles does:
cat /etc/syslogd.conf /usr/local/etc/syslogd.conf >/etc/syslogd.local
or in some cases:
if ! grep -q "already patched" etc/login.conf.diff
patch
> -John
>
> > For example syslogd.conf or newsyslog.conf are updated between releases
> > but they are also prime candidates for local additions.
> > What would be really cool is if more config files could
> > do 'includes' so that you could have a syslogd.local.conf
> > wher eall your local entries could be. In addition you could make it
> > look in /usr/local/etc/syslogd.conf for loging requirments for
> > packages.
> >
> > To do this for every config file would be a lot of work. I do wonder
> > however whether there couldn't be some "config-file reader" library
> > routine that could be used to pre-pass files and do inclusions..
> >
> > if the interface was very similar to what is usually used
> > (people tend to either use open/read/close or
> > fopen/fscanf (etc).
> >
> > equivalent calls could be made that use a stream of data that is
> > pre-processed to do inclusions etc. That would making retrofitting
> > relatively easy. Programs that use yacc/lex ar emore difficult,
> > but I haven't looked into it..
> >
> > anyhow, that was just a thought.
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
>
> --
> --
> As said by Napolean Bonaparte:
> "Never ascribe to malice, that which is adequately explained by incompetence"
>
> After being embraced by MS:
>
> "When accused of malice, always hide behind incompetence".
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: config files and includes.
> On Thu, 20 Feb 2003, Garrett Wollman wrote: > > > < said: > > > > > What would be really cool is if more config files could > > > do 'includes' so that you could have a syslogd.local.conf > > > wher eall your local entries could be. In addition you could make it > > > look in /usr/local/etc/syslogd.conf for loging requirments for > > > packages. > > > > Well, it's a trivial part of XML but the syntax is twisted. The > > problem is that, particularly in the case of something like > > syslog.conf, you need to change the defaults, not just supplement > > them. Right now syslog has no concept of this (and changing the > > notation doesn't help without a complete rethink of the syslog.conf > > semantics). Worthwhile, but a lot of work for which nobody will be > > grateful (instead they will all complain that you changed the format > > of the file). > > of course.. > > New functionality vs POLA. An age old conflict. Isn't POLA the reason why people gave up trying to extend the old standards (like syslogd and inetd) and decided to build new feature-rich daemons like msyslog and xinetd? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config files and includes.
At 6:39 PM -0800 2/20/03, Julian Elischer wrote: I have just gone through the process of upgrading or installing several hundred machines, and that includes altering or editing many config files in /etc. ... For example syslogd.conf or newsyslog.conf are updated between releases but they are also prime candidates for local additions. Note that I'm in the middle of some newsyslog changes, so I'm willing to think about it from that side of things. And Wes has some syslogd changes coming, so maybe he'll be interested. What would be really cool is if more config files could do 'includes' so that you could have a syslogd.local.conf where all your local entries could be. [...] To do this for every config file would be a lot of work. I do wonder however whether there couldn't be some "config-file reader" library routine that could be used to pre-pass files and do inclusions.. I've thought about this a little, and I felt it was tricky to get right. Sometimes you want to just add a line, sometimes you want to delete one line and add a different one, and sometimes you need to modify the line (ie, remove lpd-errs from a line in syslog.conf, but do not disturb whatever else is on the same line). I think you'd pretty much need to go to a new format for all the config files, and that's too big of a change (IMO) to quickly do. There's also the question of overhead. Why do all of this processing every time newsyslog runs, instead of doing it once as a part of mergemaster? So, I was thinking of writing some addition to mergemaster which could handle this. Then it's just a matter of writing one program that knows how to massage config files, without having to understand the specifics of any particular config file. Something like: if there is a line: /var/log/lpd-errs in: /etc/newsyslog.conf then: change '644 7' to '644 12' This strikes me as pretty simple (at least for the changes I want to propagate). It's just a change to mergemaster, which could then be MFC'ed to any release. That was my thinking on it. I don't know how well it would scale up for hundreds of machines though. [...] In addition you could make it look in /usr/local/etc/syslogd.conf for logging requirements for packages. However, I hadn't been thinking about this part. Certainly it would be nice to have something that also handled these issues. I've futzed around some with some of the uber-flexible config options on redhat, and I can see how that would be helpful. -- 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: config files and includes.
Matthew Emmerton wrote: > > On Thu, 20 Feb 2003, Garrett Wollman wrote: > > of course.. > > > > New functionality vs POLA. An age old conflict. > > Isn't POLA the reason why people gave up trying to extend the old standards > (like syslogd and inetd) and decided to build new feature-rich daemons like > msyslog and xinetd? People apparently keep confusing "POLA" with "PONA" -- the "Principle Of No Astonishment". The purpose of POLA is to suppress unnecessary changes, not suppress necessary changes. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: cd(4) and da(4) changes
I've (finally) checked in the cd(4) mode sense/select patches, along with a number of related fixes. Note that the 6 byte sysctl for the da(4) driver has changed. It is now kern.cam.da.%d.minimum_cmd_size. i.e. there is a separate sysctl for each da unit, since you could have different drives with different requirements in one system. The sysctl for the cd(4) driver follows the same pattern: kern.cam.cd.%d.minimum_cmd_size. For the cd(4) driver it only affects mode sense and mode select. For CDROM devices, 10 byte reads and writes are the only commands that are mandated by the spec, so that's generally what it uses anyway. Also, all sysctls in the da(4) and cd(4) drivers are accessible as loader tunables now. For the rest, see the commit message below. Let me know if you see any problems resulting from this commit. Ken - Forwarded message from "Kenneth D. Merry" <[EMAIL PROTECTED]> - From: "Kenneth D. Merry" <[EMAIL PROTECTED]> Date: Thu, 20 Feb 2003 22:19:38 -0800 (PST) To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.c src/sys/cam/scsi scsi_all.c scsi_all.h scsi_cd.c scsi_cd.h scsi_da.c ken 2003/02/20 22:19:38 PST Modified files: sys/dev/ata atapi-cam.c sys/dev/usb umass.c sys/cam/scsi scsi_all.c scsi_all.h scsi_cd.c scsi_cd.h scsi_da.c Log: Fix ATAPI/USB/Firewire CDROM drive handling in cd(4) and hopefully fix a number of related problems along the way. - Automatically detect CDROM drives that can't handle 6 byte mode sense and mode select, and adjust our command size accordingly. We have to handle this in the cd(4) driver (where the buffers are allocated), since the parameter list length is different for the 6 and 10 byte mode sense commands. - Remove MODE_SENSE and MODE_SELECT translation removed in ATAPICAM and in the umass(4) driver, since there's no way for that to work properly. - Add a quirk entry for CDROM drives that just hang when they get a 6 byte mode sense or mode select. The reason for the quirk must be documented in a PR, and all quirks must be approved by [EMAIL PROTECTED] This is to make sure that we fully understand why each quirk is needed. Once the CAM_NEW_TRAN_CODE is finished, we should be able to remove any such quirks, since we'll know what protocol the drive speaks (SCSI, ATAPI, etc.) and therefore whether we should use 6 or 10 byte mode sense/select commands. - Change the way the da(4) handles the no_6_byte sysctl. There is now a per-drive sysctl to set the minimum command size for that particular disk. (Since you could have multiple disks with multiple requirements in one system.) - Loader tunable support for all the sysctls in the da(4) and cd(4) drivers. - Add a CDIOCCLOSE ioctl for cd(4) (bde pointed this out a long time ago). - Add a media validation routine (cdcheckmedia()) to the cd(4) driver, to fix some problems bde pointed out a long time ago. We now allow open() to succeed no matter what, but if we don't detect valid media, the user can only issue CDIOCCLOSE or CDIOCEJECT ioctls. - The media validation routine also reads the table of contents off the drive. We use the table of contents to implement the CDIOCPLAYTRACKS ioctl using the PLAY AUDIO MSF command. The PLAY AUDIO TRACK INDEX command that we previously used was deprecated after SCSI-2. It works in every SCSI CDROM I've tried, but doesn't seem to work on ATAPI CDROM drives. We still use the play audio track index command if we don't have a valid TOC, but I suppose it'll fail anyway in that case. - Add _len() versions of scsi_mode_sense() and scsi_mode_select() so that we can specify the minimum command length. - Fix a couple of formatting problems in the sense printing code. MFC after: 4 weeks Revision ChangesPath 1.39 +31 -4 src/sys/cam/scsi/scsi_all.c 1.22 +17 -0 src/sys/cam/scsi/scsi_all.h 1.72 +925 -264 src/sys/cam/scsi/scsi_cd.c 1.7 +54 -31src/sys/cam/scsi/scsi_cd.h 1.127 +89 -8 src/sys/cam/scsi/scsi_da.c 1.13 +0 -30 src/sys/dev/ata/atapi-cam.c 1.76 +0 -27 src/sys/dev/usb/umass.c - End forwarded message - -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent CVSup on a P4S8X mainboard.
Hello list, I've been using Current for some time now, and have in the last 2 or so weeks updated my box a little. I installed an ASUS P4S8X main board with all the options. Most things were running fine until today..my most recent CVSup. I think it may be the audio that causing my problem I now have no sound from my SBLive. I've tried disabling the Sigmatel AC97 chip thru the BIOS, but this changes nothing. Everytime I try to play something I get a constant beep. And kernel messages of "pcm0: pci error" Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #5: Fri Feb 21 16:27:46 EST 2003 agh@nova:/usr/obj/usr/src/sys/NOVA Preloaded elf kernel "/boot/kernel/kernel" at 0xc04df000. Preloaded elf module "/boot/kernel/if_ppp.ko" at 0xc04df0a8. Preloaded elf module "/boot/kernel/if_tun.ko" at 0xc04df154. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04df200. Preloaded elf module "/boot/kernel/if_rl.ko" at 0xc04df2ac. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04df358. Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc04df404. Preloaded elf module "/boot/kernel/ugen.ko" at 0xc04df4b4. Preloaded elf module "/boot/kernel/uhid.ko" at 0xc04df560. Preloaded elf module "/boot/kernel/ukbd.ko" at 0xc04df60c. Preloaded elf module "/boot/kernel/ums.ko" at 0xc04df6b8. Preloaded elf module "/boot/kernel/umass.ko" at 0xc04df760. Preloaded elf module "/boot/kernel/agp.ko" at 0xc04df80c. Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04df8b4. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04df964. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2533060308 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.53GHz (2533.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff real memory = 536854528 (511 MB) avail memory = 516120576 (492 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00f1720 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd000-0xd7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.3 (no driver attached) atapci0: port 0xa400-0xa40f,0xa800-0xa803,0xb000-0xb007,0xb400-0xb403,0xb800-0xb807 irq 11 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 2.7 (no driver attached) ohci0: mem 0xce00-0xce000fff irq 9 at device 3.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xcd80-0xcd800fff irq 9 at device 3.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xcd00-0xcd000fff irq 9 at device 3.2 on pci0 usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.14, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. pci0: at device 3.3 (no driver attached) pci0: at device 4.0 (no driver attached) pcm0: port 0x8400-0x841f irq 5 at device 10.0 on pci0 pcm0: atapci1: port 0x7000-0x707f,0x7400-0x740f,0x7800-0x783f mem 0xcb00-0xcb01,0xcb80-0xcb800fff irq 11 at device 14.0 on pci0 atapci1: Busmastering DMA not configured ata2: at 0x7800 on atapci1 speaker0 port 0x61 on acpi0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppi0: on ppbus0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atk
Re: top-of-tree alpha kernel panics during boot
Dag-Erling Smorgrav writes: > Andrew Gallatin <[EMAIL PROTECTED]> writes: > > Do you preload any/all of the things you've marked as klds? > > No... Damn. I'm sorry then, I think I've done all I can to try to duplicate it. Would you mind doing a binary search to find out when your problem started? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top-of-tree alpha kernel panics during boot
Dag-Erling Smorgrav wrote: > Andrew Gallatin <[EMAIL PROTECTED]> writes: > > Damn. I'm sorry then, I think I've done all I can to try to duplicate > > it. Would you mind doing a binary search to find out when your problem > > started? > > I'd rather not, the machine is essential to my home network and > downtime affects not only me but also my SO. And the segfaults seem > to have gone away as well... I am now running a ToT kernel w/o pcm, > and it's already gone halfway through a buildworld without a single > segfault. If all you are replacing is the kernel, you should be able to do a single test in an hour. If you are willing to spend 8 hours on this, then you should be able to go back 32 days, for a 1 day increment. If you are willing to spend 4 hours on it, and you pick a 4 day increment, you can go back 64 days (2 months). Do you have a bounding range? This may not take that much time, or you can put your SO in a bubble bath on two occasions (8-)), etc., and get it solved. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimizing "universe" somewhat
Ruslan Ermilov <[EMAIL PROTECTED]> writes: > Okay, and this _is_ the easiest to implement, though I've found > some bogons with putting ``makeoptions NO_MODULES=yes'' that > need to be addressed. makeoptions MODULES_OVERRIDE="" should work fine. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimizing "universe" somewhat
On Thu, Feb 20, 2003 at 10:33:21PM +0100, Dag-Erling Smorgrav wrote: > Ruslan Ermilov <[EMAIL PROTECTED]> writes: > > Okay, and this _is_ the easiest to implement, though I've found > > some bogons with putting ``makeoptions NO_MODULES=yes'' that > > need to be addressed. > > makeoptions MODULES_OVERRIDE="" should work fine. > I haven't looked in-depth (yet), but I recall that NO_MODULES passed in makeoptions doesn't have the immediate effect (i.e., it still causes ``make obj'' to be run for modules). I'm likely to look at this now, if I don't fall asleep before. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: top-of-tree alpha kernel panics during boot
Andrew Gallatin <[EMAIL PROTECTED]> writes: > Damn. I'm sorry then, I think I've done all I can to try to duplicate > it. Would you mind doing a binary search to find out when your problem > started? I'd rather not, the machine is essential to my home network and downtime affects not only me but also my SO. And the segfaults seem to have gone away as well... I am now running a ToT kernel w/o pcm, and it's already gone halfway through a buildworld without a single segfault. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
