Re: expat2 in the base system?

[Ernst de Haan]

On Friday 04 October 2002 04:22, Mike Barcroft wrote:
 Ernst de Haan [EMAIL PROTECTED] writes:
  If most file formats would be XML-based (yes I know XML should not
  replace all file formats, but it comes a great way) then these formats
  would be leveraged by the fact that there are a lot of XML tools
  available, like XML editors and XML transformation processors (XSLT).
  It's easy to convert from one XML format to the other, making the
  generation of DocBook or XHTML documents a /lot/ easier.

 I've always wondered what a Makefile would look like in XML.

Just take a look at Ant and you know it :-)

   http://jakarta.apache.org/ant/

In ports: devel/jakarta-ant/


Kind regards,

Ernst

-- 
Ernst de Haan
Development Team Leader
Wanadoo Nederland B.V.

Come to me all who are weary and burdened
and I will give you rest -- Jesus Christ

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: PCI brokenness

[Mark Murray]

This works, thanks! :-) :-)

Domo Arrigato!

M

 I'm not sure, but my thought was something like following patches.
 
 Thanks
 
 Index: dev/acpica/acpi.c
 ===
 RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
 retrieving revision 1.75
 diff -u -r1.75 acpi.c
 --- dev/acpica/acpi.c 6 Sep 2002 17:01:06 -   1.75
 +++ dev/acpica/acpi.c 3 Oct 2002 10:13:51 -
 @@ -777,6 +777,10 @@
   if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, scopes[i], parent)))
   AcpiWalkNamespace(ACPI_TYPE_ANY, parent, 100, acpi_probe_child, bus, NULL);
  
 +if (devclass_get_device(devclass_find(isa), 0) == NULL) {
 + device_set_flags(BUS_ADD_CHILD(bus, 0, isa, 0), 1);
 +}
 +
  /*
   * Scan all of the child devices we have created and let them probe/attach.
   */
 Index: isa/isa_common.c
 ===
 RCS file: /home/ncvs/src/sys/isa/isa_common.c,v
 retrieving revision 1.31
 diff -u -r1.31 isa_common.c
 --- isa/isa_common.c  30 Sep 2002 07:56:12 -  1.31
 +++ isa/isa_common.c  3 Oct 2002 10:13:04 -
 @@ -1107,6 +1107,60 @@
   1,  /* no softc */
  };
  
 +static int
 +acpi_isa_probe(device_t dev)
 +{
 +
 + if (device_get_flags(dev) == 0) {
 + return (ENXIO);
 + }
 +
 + return (isa_probe(dev));
 +}
 +
 +static device_method_t acpi_isa_methods[] = {
 + /* Device interface */
 + DEVMETHOD(device_probe, acpi_isa_probe),
 + DEVMETHOD(device_attach,isa_attach),
 + DEVMETHOD(device_detach,bus_generic_detach),
 + DEVMETHOD(device_shutdown,  bus_generic_shutdown),
 + DEVMETHOD(device_suspend,   bus_generic_suspend),
 + DEVMETHOD(device_resume,bus_generic_resume),
 +
 + /* Bus interface */
 + DEVMETHOD(bus_add_child,isa_add_child),
 + DEVMETHOD(bus_print_child,  isa_print_child),
 + DEVMETHOD(bus_probe_nomatch,isa_probe_nomatch),
 + DEVMETHOD(bus_read_ivar,isa_read_ivar),
 + DEVMETHOD(bus_write_ivar,   isa_write_ivar),
 + DEVMETHOD(bus_child_detached,   isa_child_detached),
 + DEVMETHOD(bus_driver_added, isa_driver_added),
 + DEVMETHOD(bus_setup_intr,   isa_setup_intr),
 + DEVMETHOD(bus_teardown_intr,isa_teardown_intr),
 +
 + DEVMETHOD(bus_get_resource_list,isa_get_resource_list),
 + DEVMETHOD(bus_alloc_resource,   isa_alloc_resource),
 + DEVMETHOD(bus_release_resource, isa_release_resource),
 + DEVMETHOD(bus_set_resource, isa_set_resource),
 + DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
 + DEVMETHOD(bus_delete_resource,  bus_generic_rl_delete_resource),
 + DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
 + DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
 +
 + /* ISA interface */
 + DEVMETHOD(isa_add_config,   isa_add_config),
 + DEVMETHOD(isa_set_config_callback, isa_set_config_callback),
 + DEVMETHOD(isa_pnp_probe,isa_pnp_probe),
 +
 + { 0, 0 }
 +};
 +
 +static driver_t acpi_isa_driver = {
 + isa,
 + acpi_isa_methods,
 + 1,  /* no softc */
 +};
 +
  /*
   * ISA can be attached to a PCI-ISA bridge or directly to the legacy device.
   */
 @@ -1114,4 +1168,5 @@
  DRIVER_MODULE(isa, eisab, isa_driver, isa_devclass, 0, 0);
  #ifdef __i386__
  DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0);
 +DRIVER_MODULE(isa, acpi, acpi_isa_driver, isa_devclass, 0, 0);
  #endif
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Any users of matcd(4), mcd(4), or scd(4)?

[Hellmuth Michaelis]

On Thu, Oct 03, 2002 at 05:01:07PM -0400, John Baldwin wrote:
 Are there any users who use the matcd(4), mcd(4) or scd(4) drivers?
 These drivers are for rather old non-standard CD-ROM controllers
 most of which only support 1x speeds. :)  There are several changes
 being made to the kernel API's used by device drivers in -current.
 Unless we can find some people who actually use these devices and
 can test patches for these drivers we will have to drop support for
 them.  So, is anyone out there still using this old hardware?  Note
 that if support for these ancient devices was dropped, it wouldn't
 be dropped until 5.0.  4.x. would continue to support these devices
 forever.

To repeat an offer made to a recent announce of phk to axe these
drivers, i have at least two working drives/controllers/docs for the
mcd(4) driver which i am willing to ship to anyone who wants to
maintain this driver in -current to prevent it from being axed out.

One guy said that he'd like to maintain the driver, and i pointed him
to phk.

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Any users of matcd(4), mcd(4), or scd(4)?

[Matthew N. Dodd]

On Fri, 4 Oct 2002, Hellmuth Michaelis wrote:
 To repeat an offer made to a recent announce of phk to axe these
 drivers, i have at least two working drives/controllers/docs for the
 mcd(4) driver which i am willing to ship to anyone who wants to maintain
 this driver in -current to prevent it from being axed out.

I'd rather you just test them yourself.  The mcd(4) driver is out of
jeopardy right now.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

GNOME 2.0 DOES NOT COMPILE

[The Gupta Age]

Hi.

I was trying to compile GNOME 2.0 on a freebsd current
machine on which the world was recently cvsuped, built
and installed. CVSUP-ed on 09/22/2002

the gnome compilation breaks while trying to compile
libgtop2. here is the error:


cc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE
-DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/freebsd -I../../include
-DNEED_GNOMESUPPORT_H -I../../support -I../../support
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O -pipe
-mcpu=pentiumpro -I/usr/X11R6/include
-DGTOPLOCALEDIR=\/usr/local/share/locale\ -DLIBGTOP_VERSION=\2.0.0\
-DLIBGTOP_SERVER_VERSION=\5\ -DLIBGTOP_VERSION_CODE=200
-DLIBGTOP_SERVER=\/usr/local/bin/libgtop_server2\ -I/usr/local/include
-O -pipe -mcpu=pentiumpro -c proctime.c  -fPIC -DPIC -o .libs/proctime.lo
In file included from ../../glibtop.h:33,
 from proctime.c:24:
glibtop_machine.h:59:8: warning: extra tokens at end of #endif directive
proctime.c: In function `calcru':
proctime.c:76: structure has no member named `p_kse'
proctime.c:77: structure has no member named `p_kse'
proctime.c:78: structure has no member named `p_kse'
gmake[3]: *** [proctime.lo] Error 1
gmake[3]: Leaving directory
`/usr/ports/devel/libgtop2/work/libgtop-2.0.0/sysdeps/freebsd'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/usr/ports/devel/libgtop2/work/libgtop-2.0.0/sysdeps'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/devel/libgtop2/work/libgtop-2.0.0'
gmake: *** [all-recursive-am] Error 2
*** Error code 2

Stop in /usr/ports/devel/libgtop2.
*** Error code 1

Stop in /usr/ports/x11/gnomeapplets2.
*** Error code 1

Stop in /usr/ports/x11/gnome2.

=

I was wondering if anyone else has tried to compile this
successfully?? or if somebody more familiar with this
error could help me fix it!!

Thanks and best regards to all
Saurabh Gupta


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death(signal 6))

[Bruce Evans]

On Thu, 3 Oct 2002, Daniel Eischen wrote:

 Can you try the patch at:

   http://people.freebsd.org/~deischen/sys.diffs

 I haven't had a chance to compile or test it, but it should
 be easy enough to fix if it doesn't (compile).

It seems a bit fragile.  As I understand it, it loads a clean FP state
if the state in the ucontext is too messed up to use, and changes
some magic numbers to be more magic so that it is easier to detect
messed up states.  But loading a clean FP state is the wrong thing to
do if it wasn't clean to begin with.  I would have thought the current
hack of saving it in the pcb would work better.  Maybe combining these
hacks would work better (load from the pcb, but only if there is no
alternative, and don't load blindly if !PCB_NPXINITDONE).

 I'm still not exactly sure why this causes problems for the
 modula 3 run-time.  I think Bruce may be right in that the
 modula 3 libraries/run-time need to be rebuilt with the
 larger ucontext.

I have no idea about the details.  Rebuilding old binaries to fix
binary compatibility problems is not a solution.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

GEOM changes

[n0g0013]

looking for an overview of the GEOM changes coming into current --
most specifically how they will impact admin.

are there updates in the handbook ?  or another paper somewhere ?

-- 
t
 t
 z

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Please read the message all the way through

[The Gupta Age]

Several months back when I first started playing with
current sent a message on this mailing list to update
the UPDATING file in /usr/src

I just CVSUPED another stable machine with the current
sources to run current on it and guess what
no body updated that info. it is a vital piece of
information for some newbies going from stable to
current (or should I call *BLEEDING EDGE*)

anyways here it is :

while upgrading from stable to current and if going the
cvsup and make world  way
following the instructions in /usr/src/UPDATING. is pretty
much all that is necessary except when the current kernel
is installed and the computer is rebooted it will not
boot up. but will be stuck after the boot blocks.
the fix is to go to
/usr/src/sys/boot/i386/
make all ; make install
reboot ... and it works
reason:the location of kernel is moved from /kernel
to /boot/kernel/kernel by default.
a new kernel and its modules are installed in the
/boot/kernel directory. This can be setup in one of
the boot-conf files also. but why sweat finding it
when make all; make install will do the trick.


=== Thats all folks

IMPORTANT
A few more points for hackers:

device midi

crashes the kernel in the current cvsup-ed 09/22/2002

option IPSEC

will cause the compilation of the kernel to seg fault.
the KPOSIX options and IPSEC are STRANGE BEDFELLOWS
kposix seems to act as an antidote to the seg fault
i.e, the kernel compiles instead of dumping core.

I have no idea about the functionality of IPSEC in
the kernel compiled thus. POSIX seems to be working
fine.

device pcf
device pcfclock

freeze the kernel right around the time it is about
to mount /
removing the following devices works fine!!
device iicbus
device iicbb
device ic
device iic
these two sets seem to be exclusive of each other.
CAN SOMEBODY SHED SOME LIGHT ON THIS PLEASE
THANK YOU


 THE END ==



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))

[John Hay]

   
   Can you try the patch at:
   
 http://people.freebsd.org/~deischen/sys.diffs
   
  
  It works! Already 5 hours without a single signal 6.
 
 Thanks!
 
 Let me test it myself and I'll commit it as a (yet another)
 work around until mini gets a chance to make new syscalls
 to handle this better.

Another me too. With the patch I was finally able to finish a cvsup
session.

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

sym disabling controller LED?

[Michael Nottebrock]

I have a Dawicontrol 2975U SCSI controller, which is handled by the sym 
driver:

sym0: 875 port 0xac00-0xacff mem 
0xe3201000-0xe3201fff,0xe3203000-0xe32030ff irq 10 at device 8.0 on pci0
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking

I have connected the controller's LED-connector to the case hdd-LED and 
it works fine (for example during loading the kernel) until sym takes 
over the controller, then it remains dark.


Regards,
-- 
Michael Nottebrock
And the reasons? There are no reasons.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Any users of matcd(4), mcd(4), or scd(4)?

[Jamie Bowden]

On Thu, 3 Oct 2002, John Baldwin wrote:

:Are there any users who use the matcd(4), mcd(4) or scd(4) drivers?
:These drivers are for rather old non-standard CD-ROM controllers
:most of which only support 1x speeds. :)  There are several changes
:being made to the kernel API's used by device drivers in -current.
:Unless we can find some people who actually use these devices and
:can test patches for these drivers we will have to drop support for
:them.  So, is anyone out there still using this old hardware?  Note
:that if support for these ancient devices was dropped, it wouldn't
:be dropped until 5.0.  4.x. would continue to support these devices
:forever.

I have an old ISA SB16 with the matcd interface on it and the 2x Creative
(Matsushita/Panasonic) CD-ROM drive that goes with it.  I'd be more than
happy to ship these off to the project if the project wants them.  Last
time I bothered to plug them into a machine and check them, they were
still functional.

Jamie Bowden

-- 
It was half way to Rivendell when the drugs began to take hold
Hunter S Tolkien Fear and Loathing in Barad Dur
Iain Bowen [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Ready to connect libbsdxml (nee libexpat) to the build !

[Poul-Henning Kamp]

Ok, I am ready to connect our private brand libexpat to the build
now, any final objections ?

What was the concensus on the xmlwf program, did we want it in
the tree or not ?  Would it be useful to anybody or is it just
a hackers-proof-of-concept thing ?

Poul-Henning



In message [EMAIL PROTECTED], Poul-Henning Kam
p writes:
phk 2002/10/04 04:20:19 PDT

  Modified files:
lib/libexpat Makefile 
  Added files:
lib/libexpat libbsdxml.3 
  Log:
  Ok, concensus was to install libexpat under a private brandname, and after
  some deliberation the name libbsdxml was chosen since it conveys the two
  most important attributes:  Private to FreeBSD and XML.
  
  Add a skeleton man-page to give the credit and point for further
  documentation.  (If somebody wants to write a true mdoc manpage for
  this I am sure both the eXpat people and I will be grateful).
  
  (Still not connected to the build)
  
  Revision  ChangesPath
  1.2   +22 -12src/lib/libexpat/Makefile
  1.1   +59 -0 src/lib/libexpat/libbsdxml.3 (new)


-- 
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: Journaled filesystem in CURRENT

[Alexander Leidinger]

On Fri, 27 Sep 2002 13:06:00 -0400 (EDT)
Garrett Wollman [EMAIL PROTECTED] wrote:

  On Thu, Sep 26, 2002 at 09:13:41PM +0200, Alexander Leidinger wrote:
  Yes, bg-fsck isn't really usable at the moment.
 
  They work fine for me for quite a while.  The last buildworld on my
  server was Sept 15th.
 
 Worked fine for me on my home desktop as well -- but I know that fsck
 had little to do in all of the instances I've seen it work, and there
 was no significant disk activity.

Disk activity was/is the key in this case... I haven't tried it with a
recent kernel yet.

Bye,
Alexander.

-- 
   Speak softly and carry a cellular phone.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Ready to connect libbsdxml (nee libexpat) to the build !

[Marc Recht]

 What was the concensus on the xmlwf program, did we want it in
 the tree or not ?  Would it be useful to anybody or is it just
 a hackers-proof-of-concept thing ?
IMO we don't need it. It only checks if an XML document is well-formed. It even 
doesn't check if it's valid. I don't think we need a tool like that in the 
base-system, there are much better tools in the ports-tree.

Marc



msg43902/pgp0.pgp
Description: PGP signature

Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))

[Giorgos Keramidas]

John Hay [EMAIL PROTECTED] wrote:
: John Polstra [EMAIL PROTECTED] wrote:
:  In article [EMAIL PROTECTED],
:  Andrey A. Chernov [EMAIL PROTECTED] wrote:
:   Additional details: it cause not only cvsupd death, but rarely cvsup
:   signal 6 death too with this diagnostic:
:   
:   ***
:   *** runtime error:
:   ***Value out of range
:   ***file 
:   /tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/Time
:   Stamp.m3, line 63
:  
:  This particular message is usually caused by a very bogus system date
:  setting.
: 
: I also see this on current using cvsup and my machine is synced with
: ntpd, so its time is ok. I have tried a few different versions of
: cvsup, but they all do the same thing. I have not tried to compile my
: own yet. In my case cvsup die everytime I try to use it. It go through
: the src but breaks somewhere in ports/math.

I have rebuilt world some time during Oct 1.  Both cvsup-1.16e and
cvsup-without-gui-1.16f die when updating the ports here.  Is there
some way of providing more useful information than a me too here?
Like, say, a crash dump of cvsup and a stack trace or whatever it
is that m3 uses?

Giorgos.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

[ GEOM tests ] disklabel warnings and vinum drives lost

[n0go013]

rebuilt kernel with GEOM and everything is ok but disklabel now dumps a
warning message for each undefined partition.  should these be manually
initialised to valid entries or is this a bug ?

more importantly vinum can no longer find the drives but i'm not sure
thats related as cvsup was from 2002/09/23 - 2002/10/03


+++ vinum create output +++
eyore# vinum create ./drive
   1: drive snub device /dev/ad0s1h
** 1 Can't initialize drive snub: No such file or directory
   2: drive junk device /dev/ad2s1h
** 2 Can't initialize drive junk: No such file or directory
0 drives:
0 volumes:
0 plexes:
0 subdisks:
--- vinum create output ---


+++ ll /dev/ad?s1? +++
eyore# ll /dev/ad?s1?
crw-r-  1 root  operator4,   6 Oct  4 11:35 /dev/ad0s1b
crw-r-  1 root  operator4,   7 Oct  4 11:35 /dev/ad0s1c
crw-r-  1 root  operator4,   8 Oct  4 11:35 /dev/ad0s1h
crw-r-  1 root  operator4,  17 Oct  4 11:35 /dev/ad1s1a
crw-r-  1 root  operator4,  18 Oct  4 11:35 /dev/ad1s1c
crw-r-  1 root  operator4,  19 Oct  4 11:35 /dev/ad1s1d
crw-r-  1 root  operator4,  20 Oct  4 11:35 /dev/ad1s1e
crw-r-  1 root  operator4,  21 Oct  4 11:35 /dev/ad2s1b
crw-r-  1 root  operator4,  22 Oct  4 11:35 /dev/ad2s1c
crw-r-  1 root  operator4,  23 Oct  4 11:35 /dev/ad2s1h
--- ll /dev/ad?s1? ---


+++ disklabel ad0s1 output +++
[...]
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  b:   1638400  swap# (Cyl.0 - 216*)
  c:  84187530unused0 0 # (Cyl.0 - 11135*)
  h:  8254913   163840 vinum# (Cyl.  216*- 11135*)
Warning, partition a: size 0, but offset 4294967233
partition a: offset past end of unit
partition a: partition extends past end of unit
Warning, partition d: size 0, but offset 4294967233
partition d: offset past end of unit
partition d: partition extends past end of unit
Warning, partition e: size 0, but offset 4294967233
partition e: offset past end of unit
partition e: partition extends past end of unit
Warning, partition f: size 0, but offset 4294967233
partition f: offset past end of unit
partition f: partition extends past end of unit
Warning, partition g: size 0, but offset 4294967233
partition g: offset past end of unit
partition g: partition extends past end of unit
--- disklabel ad0s1 output ---


+++ dislabel ad1s1 output +++
[...]
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a:   43008004.2BSD 1024  8192 46208   # (Cyl.0 - 26*)
  c:  41125770unused0 0 # (Cyl.0 - 255*)
  d:  3252417   8601604.2BSD 1024  8192 46208   # (Cyl.   53*- 255*)
  e:   430080   4300804.2BSD 1024  8192 46208   # (Cyl.   26*- 53*)
Warning, partition b: size 0, but offset 4294967233
partition b: offset past end of unit
partition b: partition extends past end of unit
Warning, partition f: size 0, but offset 4294967233
partition f: offset past end of unit
partition f: partition extends past end of unit
Warning, partition g: size 0, but offset 4294967233
partition g: offset past end of unit
partition g: partition extends past end of unit
Warning, partition h: size 0, but offset 4294967233
partition h: offset past end of unit
partition h: partition extends past end of unit
--- disklabel ad1s1 output ---


-- 
t
 t
 z

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], n0go013 writes:
rebuilt kernel with GEOM and everything is ok but disklabel now dumps a
warning message for each undefined partition.  should these be manually
initialised to valid entries or is this a bug ?

more importantly vinum can no longer find the drives but i'm not sure
thats related as cvsup was from 2002/09/23 - 2002/10/03

I have just a couple of hours ago added the sysctl kern.disks to
the GEOM code.  

I suspect vinum uses this sysctl to get an inventory of disks in
the system, so can I get you to try again making sure you have
rev. 1.20 of src/sys/geom/geom_disk.c ?

-- 
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: Ready to connect libbsdxml (nee libexpat) to the build !

[Sheldon Hearn]

On (2002/10/04 13:26), Poul-Henning Kamp wrote:

 What was the concensus on the xmlwf program, did we want it in
 the tree or not ?  Would it be useful to anybody or is it just
 a hackers-proof-of-concept thing ?

I think it needs to stay out of the base system, so that 3rd party
applications aren't surprised to find a stale binary in the base system
instead of the latest version installed in the LOCALBASE.

I don't like the idea of a renamed version of this utility existing in
the base system, because I feel that folks who want it just for testing
the utilities linked against libbsdxml will have sufficient clue to
build it themselves.

Ciao,
Sheldon.

PS: Thanks for persevering through the rather long thread that got us to
this point, even if it was heavily assisted by your MUA's delete
function. :-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: expat2 in the base system?

[Giorgos Keramidas]

On 2002-10-03 22:22, Mike Barcroft [EMAIL PROTECTED] wrote:
 Ernst de Haan [EMAIL PROTECTED] writes:
  If most file formats would be XML-based (yes I know XML should not
  replace all file formats, but it comes a great way) then these
  formats would be leveraged by the fact that there are a lot of XML
  tools available, like XML editors and XML transformation
  processors (XSLT). It's easy to convert from one XML format to the
  other, making the generation of DocBook or XHTML documents a /lot/
  easier.

 I've always wondered what a Makefile would look like in XML.

You'd be surprised.  There is already such a thing.  The j2ee (Java
Beans, Enteprise Edition) already have something that works this way.
It's called ant, if my memory from my early 2001 work with j2ee,
doesn't fail me.

-- 
[EMAIL PROTECTED] -==- FreeBSD: The Power to Serve
FreeBSD 5.0-CURRENT #3: Wed Oct  2 04:55:42 EEST 2002

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: sym disabling controller LED?

[Christian Weisgerber]

Michael Nottebrock [EMAIL PROTECTED] wrote:

 I have a Dawicontrol 2975U SCSI controller, which is handled by the sym 
 driver:
 
 sym0: 875 port 0xac00-0xacff mem 
 0xe3201000-0xe3201fff,0xe3203000-0xe32030ff irq 10 at device 8.0 on pci0
 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
 
 I have connected the controller's LED-connector to the case hdd-LED and 
 it works fine (for example during loading the kernel) until sym takes 
 over the controller, then it remains dark.

Actually, that's a case of sym(4) failing to actuate the LED rather
than shutting it off.  Later sym chips control the LED in hardware,
but the '875 doesn't and the driver has to blink the LED.  The BIOS
supplied driver does, sym(4) apparently fails to do so for you.  I
seem to recall that there are several GPIO pins that can be used
to drive a LED; possibly this Dawicontrol adapter has the LED wired
to a non-standard port.

In case he doesn't pipe up here, contact sym(4)'s author, Gérard
Roudier [EMAIL PROTECTED].

sym(4) blinks the LED just fine on my equally '875-based Tekram
DC-390F.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Meaning of net.inet.tcp.inflight_debug output?

[Alexander Leidinger]

Hi,

what does this mean? Is it important?
---snip---
kernel: 0xc27b4814 bw 4 rttbest 2735 srtt 2250 bwnd 2803
kernel: 0xc0ef235c bw 23101 rttbest 680 srtt 293056 bwnd 1063153
kernel: 0xc27b435c bw 54061 rttbest 1297 srtt 1756 bwnd 28636
kernel: 0xc27b435c bw 47663 rttbest 1297 srtt 1784 bwnd 25793
kernel: 0xc0ef235c bw 24288 rttbest 680 srtt 305216 bwnd 1163779
kernel: 0xc0ef235c bw 22928 rttbest 680 srtt 306864 bwnd 1104680
kernel: 0xc0ef235c bw 19812 rttbest 680 srtt 311471 bwnd 969203
kernel: 0xc27b435c bw 53468 rttbest 1297 srtt 2014 bwnd 30508
kernel: 0xc27b435c bw 47727 rttbest 1297 srtt 1767 bwnd 25705
---snip---

Bye,
Alexander.

-- 
Where do you think you're going today?

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Junior Kernel Hacker page updated...

[Stefan Farfeleder]

On Thu, Oct 03, 2002 at 04:41:46PM +0200, Poul-Henning Kamp wrote:
 
 Hi Stefan,
 
 I tried this patch and it paniced my (almost-) current machine with
 a pagefault in the kqueue code:  Bravo!
 
 I can see that there is some amount of #ifdef stuff in your patch,

The #ifdefs are already in the code, namely REMOTE and RMT_WILL_WATCH.
Is anybody using them? Building with -DREMOTE doesn't compile and with
-DRMT_WILL_WATCH the linker is complaining about the lack of the
functions Rmt_Ignore(), Rmt_Watch() and Rmt_Wait(). Can't we get rid of
those defines? I understand Juli Mallett wants to rewrite make, so maybe
this effort would be wasted.

 in light of that, would it be possible to make an #ifdef'ed version
 of your patch which we could commit ?

Ok, the new patch is attached. Compile with -DUSE_KQUEUE to use the new
code.

 That way we give the kqueue hackers a good testcase, and we can
 easily enable when they have solved the problem.

After Don Lewis fixed the 'could sleep with' problem (thanks!), I'm
still encountering freezes and panics. Here's one I caught:

[warning: parts are typed in]
%%%
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 
fault virtual address   = 0x8
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01a1212
stack pointer   = 0x10:0xe5226c14
frame pointer   = 0x10:0xe5226ca0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 56525 (make)

kernel: type 12 trap, code = 0

Stopped atkqueue_scan+0x242:  cmpl $0,0x8(%ebx)
db trace
kqueue_scan(c6472bf4,4,bfbfebc0,0,c70ecea0) at kqueue_scan+0x242
kevent(c70ecea0,e5226d10,c0351d80,418,6) at kevent+0x1e1
syscall(2f,2f,2f,818d780,818d960) at syscall+0x2be
%%%

The core file doesn't seem to be particularly helpful, as the
kqueue_scan frame seems to miss:

%%%
(kgdb) bt
#0  doadump () at /freebsd/current/src/sys/kern/kern_shutdown.c:223
#1  0xc01ba92a in boot (howto=260)
at /freebsd/current/src/sys/kern/kern_shutdown.c:355
#2  0xc01babe7 in panic () at /freebsd/current/src/sys/kern/kern_shutdown.c:508
#3  0xc013b1d2 in db_panic () at /freebsd/current/src/sys/ddb/db_command.c:450
#4  0xc013b152 in db_command (last_cmdp=0xc035db20, cmd_table=0x0, 
aux_cmd_tablep=0xc03577dc, aux_cmd_tablep_end=0xc03577e0)
at /freebsd/current/src/sys/ddb/db_command.c:346
#5  0xc013b266 in db_command_loop ()
at /freebsd/current/src/sys/ddb/db_command.c:472
#6  0xc013deca in db_trap (type=12, code=0)
at /freebsd/current/src/sys/ddb/db_trap.c:72
#7  0xc02e9f60 in kdb_trap (type=12, code=0, regs=0xe5226bd4)
at /freebsd/current/src/sys/i386/i386/db_interface.c:166
#8  0xc0302602 in trap_fatal (frame=0xe5226bd4, eva=0)
at /freebsd/current/src/sys/i386/i386/trap.c:841
#9  0xc03022e2 in trap_pfault (frame=0xe5226bd4, usermode=0, eva=8)
at /freebsd/current/src/sys/i386/i386/trap.c:760
#10 0xc0301e0d in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -943606528, tf_esi = -943606488, 
tf_ebp = -450728800, tf_isp = -450728960, tf_ebx = 0, tf_edx = 4, tf_ecx = 1, tf_eax = 
0, tf_trapno = 12, tf_err = 0, tf_eip = -1072033262, tf_cs = 8, tf_eflags = 66050, 
tf_esp = -966356416, tf_ss = 0})
---Type return to continue, or q return to quit---
at /freebsd/current/src/sys/i386/i386/trap.c:446
#11 0xc02eb768 in calltrap () at {standard input}:99
#12 0xc01a0ad1 in kevent (td=0xc70ecea0, uap=0xe5226d10)
at /freebsd/current/src/sys/kern/kern_event.c:470
#13 0xc030299e in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135845760, tf_esi = 135846240, 
tf_ebp = -1077941224, tf_isp = -450728588, tf_ebx = 134831872, tf_edx = 2184, tf_ecx = 
0, tf_eax = 363, tf_trapno = 12, tf_err = 2, tf_eip = 134626551, tf_cs = 31, tf_eflags 
= 514, tf_esp = -1077941348, tf_ss = 47})
at /freebsd/current/src/sys/i386/i386/trap.c:1050
#14 0xc02eb7bd in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
%%%

objdump -dS kern_event.o says the following about kqueue_scan+0x242
[==0xfd2]:

%%%
 fce:   90  nop
 fcf:   90  nop
kn = TAILQ_FIRST(kq-kq_head);
 fd0:   8b 1f   mov(%edi),%ebx
TAILQ_REMOVE(kq-kq_head, kn, kn_tqe); 
 fd2:   83 7b 08 00 cmpl   $0x0,0x8(%ebx)
 fd6:   74 0b   je fe3 kqueue_scan+0x253
 fd8:   8b 53 08mov0x8(%ebx),%edx
 fdb:   8b 43 0cmov0xc(%ebx),%eax
 fde:   89 42 0cmov%eax,0xc(%edx)
 fe1:   eb 06   jmpfe9 kqueue_scan+0x259
 fe3:   8b 43 0cmov0xc(%ebx),%eax
 fe6:   89 47 04mov%eax,0x4(%edi)
 

Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death(signal 6))

[Daniel Eischen]

On Fri, 4 Oct 2002, Bruce Evans wrote:

 On Thu, 3 Oct 2002, Daniel Eischen wrote:
 
  Can you try the patch at:
 
http://people.freebsd.org/~deischen/sys.diffs
 
  I haven't had a chance to compile or test it, but it should
  be easy enough to fix if it doesn't (compile).
 
 It seems a bit fragile.  As I understand it, it loads a clean FP state
 if the state in the ucontext is too messed up to use, and changes
 some magic numbers to be more magic so that it is easier to detect
 messed up states.  But loading a clean FP state is the wrong thing to
 do if it wasn't clean to begin with.  I would have thought the current
 hack of saving it in the pcb would work better.  Maybe combining these
 hacks would work better (load from the pcb, but only if there is no
 alternative, and don't load blindly if !PCB_NPXINITDONE).

I'll try this.

  I'm still not exactly sure why this causes problems for the
  modula 3 run-time.  I think Bruce may be right in that the
  modula 3 libraries/run-time need to be rebuilt with the
  larger ucontext.
 
 I have no idea about the details.  Rebuilding old binaries to fix
 binary compatibility problems is not a solution.

I don't think the modula 3 run-time library is written in
C/C++, so any change in the size of a ucontext may require
a source code change for any modula 3 structures that
correspond to/contain it.

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Parsing route dump treceived by using sysctl

[yatin chalke]

Hi,

I am currently trying to get a route dump in
freebsd4.4 using sysctl with NET_RT_DUMP.

I am running into problems while parsing the returned
rt_msghdr structures.

The sockaddr structures returned after the rt_msghdr
are messed up and it is not giving correct gateway or
netmask.

For ex: when I am parsing the received route dump the
netmask received is nonzero(random value) for a
default route (which it returns as 0.0.0.0) and also
netmask doesnt appear to be a sockaddr structure.

Also for further routes gateway and netmasks are
0.0.0.0.
I am  parsing the received sockaddr structures to get
all the values depending on flag bits set in rt_msghdr
structure.

If anyone can help me in this matter it will be a
great help.

Thanks,
--Yatin


__
Do you Yahoo!?
New DSL Internet Access from SBC  Yahoo!
http://sbc.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[fergus]

On 04.10-14:20, Poul-Henning Kamp wrote:
 I suspect vinum uses this sysctl to get an inventory of disks in
 the system, so can I get you to try again making sure you have
 rev. 1.20 of src/sys/geom/geom_disk.c ?

still in the middle of the build but i don't think so -- it looks like
vinum is using BIO_READ with a fixed offset VINUM_LABEL_OFFSET to
retrieve a raw copy of the disklabel to parse.

i don't have any references but from what you've mentioned in commits
over the last week that's not really going to work.  if there are any
geom design outlines i can read (in a digest or news) then i may be
able to put together a patch.

i'll let you know the test results when i have some.

-- 
t
 t
 z

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death(signal 6))

[Daniel Eischen]

On Fri, 4 Oct 2002, Andrey A. Chernov wrote:

 On Thu, Oct 03, 2002 at 16:37:21 -0400, Daniel Eischen wrote:
  
  Can you try the patch at:
  
http://people.freebsd.org/~deischen/sys.diffs
  
 
 It works! Already 5 hours without a single signal 6.

A slightly different version with bde comments incorporated was
committed.  Please let me know if there are any more problems.
Thanks.

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Vote: lib/libexpat - lib/libbsdxml

[Ruslan Ermilov]

Hi there!

I'd like to rename src/lib/libexpat to src/lib/libbsdxml.
The reason I think it should be done is the output of the
following command (libpam not being an exception here):

cd src/lib; for dir in lib*; do [ $dir != lib`cd $dir; make -V LIB` ]  echo 
$dir; done


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



msg43915/pgp0.pgp
Description: PGP signature

Re: expat2 in the base system?

[Jeroen C . van Gelderen]

On Friday, Oct 4, 2002, at 06:26 US/Eastern, Giorgos Keramidas wrote:

 On 2002-10-03 22:22, Mike Barcroft [EMAIL PROTECTED] wrote:
 Ernst de Haan [EMAIL PROTECTED] writes:
 If most file formats would be XML-based (yes I know XML should not
 replace all file formats, but it comes a great way) then these
 formats would be leveraged by the fact that there are a lot of XML
 tools available, like XML editors and XML transformation
 processors (XSLT). It's easy to convert from one XML format to the
 other, making the generation of DocBook or XHTML documents a /lot/
 easier.

 I've always wondered what a Makefile would look like in XML.

 You'd be surprised.  There is already such a thing.  The j2ee (Java
 Beans, Enteprise Edition) already have something that works this way.
 It's called ant, if my memory from my early 2001 work with j2ee,
 doesn't fail me.

Almost. It's indeed called Ant but has been developed under the 
umbrella of the Apache Jakarta project.

-J
-- 
Jeroen C. van Gelderen - [EMAIL PROTECTED] - +1 242 357 5115

When I'm working on a problem, I never think about beauty. I
think only how to solve the problem. But when I have finished,
if the solution is not beautiful, I know it is wrong.
   -- R. Buckminster Fuller


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: expat2 in the base system?

[Hui]

On Fri, Oct 04, 2002 at 10:24:03AM -0400, Jeroen C. van Gelderen wrote:
 Almost. It's indeed called Ant but has been developed under the 
 umbrella of the Apache Jakarta project.

I used it to build Tomcat tonight and it looks to be a very power
package.

bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GNOME 2.0 DOES NOT COMPILE

[Lars Eggert]

The Gupta Age wrote:
 Hi.
 
 I was trying to compile GNOME 2.0 on a freebsd current
 machine on which the world was recently cvsuped, built
 and installed. CVSUP-ed on 09/22/2002
 
 the gnome compilation breaks while trying to compile
 libgtop2. here is the error:

I ran into the same problem last week. Check the archives for the 
sys/sys/proc.h 1.250 breaks devel/libgtop2 port thread, it has some 
fixes in its replies.

Lars
-- 
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute



smime.p7s
Description: S/MIME Cryptographic Signature

$B!y$?$^$2$?%K%e!<%9!y(J

[watanabe@bb.knet.ne.jp]

EBEKEBEKEBEKEBEKEBEKEBEKEBEKEB
@@  
@@@@@@@@@@@™@‚½‚Ü‚°‚½ƒjƒ…[ƒX@™

@@@@— ƒrƒfƒI”Ì”„E“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu
@@‚`‚u’j—D•åWE‰‡•ŒðÛE‚Žû“üŠmŽÀuo’£ƒzƒXƒgv•åW
@@@@@@@@¦¦¦@‚»‚Ì‘¼— î•ñ–žÚ@¦¦¦

@EBEKEBEKEBEKEBEKEBEKEBEKEBEKEB

@@@@@@
@@@@@@‚¨\ž‚݁E‚²’•¶E¤•iÚ×“™‚́@@@@
@@@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‚­‚¾‚³‚¢B
@@@@@@



¡@ƒAƒƒr‚ª‘å‹™‚ō¢‚Á‚Ä‚¢‚Ü‚·@¡

ƒƒŠ[ƒ^ƒrƒfƒIi‚c‚u‚cjê–å
‚¢‚‚܂ʼnc‹Æ‚Å‚«‚é‚©‚í‚©‚è‚Ü‚¹‚ñB
ƒ}ƒjƒA‚̃€ƒgƒE“X’·‚¾‚©‚ç‚Å‚«‚é•i‘µ‚¦‚̐”XI
Šˆ‚«‚Ì‚¢‚¢‚¤‚¿‚ÉŽ©‘î‚Ö’¼‘—’v‚µ‚Ü‚·B
–ž‘«“x‚P‚Q‚O“‚Ì‚²’•¶‚Í‚¨‘‚߂ɁI
ôì•i—áô@­—“`àE–¼ŒÃ‰®’c’n9E­—‚Ì“¹‘
‚È‚Ç‚È‚Ç‚P‚R‚Qì•i‚ªD•]”­”„’†I

http://video333.com/
@@@@@@@@@@@@@@@@@@@@(@.@)/~ƒƒŠƒƒŠ•“¡

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@“X•Ü”Ì”„‚Å‚È‚¢‚¨lŒ`‚³‚ñ@¡

•ø‚«‚µ‚ß‚½‚­‚È‚é‚悤‚È‚¨lŒ`‚³‚ñ‚ªì‚ê‚Ü‚µ‚½B
‚»‚ê‚à“™g‘å‚Ȃ̂ŁA”š”­“I‘åƒqƒbƒg¤•iI
”‚ɐ§ŒÀ‚ª‚ ‚邽‚߁A‚¨\‚µž‚Ý‚Í‚¨‘‚߂ɁI
ô‚‚¢‚ɐV»•i“oêô
¬Ž­‚̂悤‚ȉ˜‚ê‚È‚«—öl
™‹Ç•”‚Ü‚Å–{•¨‚»‚Á‚­‚è‚ɐ§ì‚µ‚½‚½‚߁A“X“ª”Ì”„‚Å‚«‚Ü‚¹‚ñB

http://a-speed.net/
@@@@@@@@@@@@@@ƒƒfƒBƒJƒ‹ƒAƒsƒAlŒ`H–[ƒfƒUƒCƒ“

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@‹t‰‡•ŒðÛ‚­‚ç‚ԁ@¡

‘f“G‚È’j«‚Æ’©‚Ü‚Å“ñlEEEB
‘f“G‚È’j«‚ð¡‚·‚®‹M—‚ÌŒ³‚ÖŒü‚©‚킹‚Ü‚·B
‘S‘ƒlƒbƒgƒ[ƒN‚Å‚·‚®‚ɏЉî‚n‚jB
Žá‚¢—«‚à‰“—¶‚µ‚È‚¢‚Å—V‚Ñ‚Ü‚­‚낤I
‚P‰ñŒÀ‚èA’·ŠúA‰½‚Å‚à‚ ‚èB
ô—«‚É—D‚µ‚­‚Å‚«‚é’j«ƒXƒ^ƒbƒt‚à“¯Žž•åW’†ô

http://new-pm.com/
@@@@@@@@@@@@@@@@@@@@@@@@@‹t‰‡•‰ï

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@‚r‚d‚wƒtƒŒƒ“ƒh•åW@¡

^Œ•‚ÉSEXƒtƒŒƒ“ƒh‚ð’T‚µ‚Ä‚¢‚él‚¾‚¯W‡B
‘S‘‚Ç‚±‚Å‚à‹ß‚­‚̐l‚ðƒvƒƒtƒB[ƒ‹•t‚Å‚·‚®Ð‰îB
Žá‚¢l‚©‚çn”N‚Ü‚Å‚¢‚Á‚Ï‚¢‚¢‚é‚æB
ƒ_ƒ“ƒi‚É“à‚Ì‚g‚ðŠy‚µ‚à‚¤I

http://www.japan.pinkserver.com/sfriend/
@@@@@@@@@@@@@@@@@@@@@@@ƒŒƒ‚ƒ“ƒNƒ‰ƒu

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@‹M•wl‹äŠy•”@¡

‘f“G‚È’j«‚ðÐ‰î‚µ‚Ü‚·B
ƒ}ƒbƒT[ƒWƒR[ƒX‚àŠJÝB
y‘f“G‚È–é‚ð–ñ‘©‚µ‚Ü‚·z
ô’j«•åWô
ƒŠƒbƒ`‚ȍ‚‹‰•wl‚Æ‚ÌŒðÛ‚ŁAƒAƒiƒ^‚Ì–²‚ðŽÀŒ»B
ŽáŽÒ‚©‚ç’†‚”N‚Ü‚ÅŒ’N‚È’j«‹à–¬El–¬‚Ì‚Ù‚µ‚¢’j«‚ɍœKB
—«‚ÍŒoÏ“I‚ÉŒb‚܂ꂽŽÐ’·•wlEŽÀ‹Æ‰ÆE‘½”...B

http://drop.cc
@@@@@@@@@@@@@@@@@@@@@@@‹M•wlƒNƒ‰ƒu

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@Œg‘єԍ†‹³‚¦‚Ü‚·@¡

‘S‘Še’n‚̏—‚ÌŽq‚ÌŒg‘єԍ†‹³‚¦‚¿‚Ⴄ‚æI
¡ATŠ§Ž‚Řb‘蕦“«I
–{‹C‚ŏo‰ï‚¢‚ð‹‚ß‚Ä‚é—«‚̔ԍ†‚¾‚¯B
ƒTƒNƒ‰A‚â‚点ˆêØ–³‚µB
Œg‘єԍ†‹³‚¦‚éƒVƒXƒeƒ€‚Í“–“X‚ªŒ³‘c‚Å‚·B

http://goo-goo.net/
@@@@@@@@@@@@@@@@@@@@@ƒ}[ƒxƒ‰ƒXƒNƒ‰ƒu

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@ƒ}ƒŠƒtƒ@ƒi‚f‚n‚f‚n@¡

‚±‚̃y[ƒW‚͈êTŠÔ‚ŏÁ–Å‚µ‚Ü‚·B
ƒ}ƒŠƒtƒ@ƒi‚ª‚½‚Ü‚ç‚È‚­D‚«‚ȐlA‚Ç‚¤‚¼A‚±‚±‚ցB
‚ ‚Ô‚È‚¢‚­‚·‚è‚̏î•ñ‚àŽè‚É“ü‚é‚æI
uâ‘΂Ɉ«—p‚µ‚È‚¢‚Å‚­‚¾‚³‚¢Bv

http://www.egao.com/areaegao/0/
@@@@@@@@@@@@@@@@@@@@@@@@@X@³’j

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@¶’Eƒpƒ“ƒeƒB@¡

‚ ‚́AŽg—pÏ‰º’…ê–å“Xu‚Ï‚ñ‚Ä‚¡‚Í‚¤‚·v‚ª‹‚É“oêI
—‚ÌŽq‚ÌŠçŽÊ^‚ðŒ©‚Ä—ŽŽDI
ƒpƒ“ƒeƒBEƒuƒ‹ƒ}[EƒXƒgƒbƒLƒ“ƒOEŒC‰º ‚ðŠ®‘S–§••‚Å‚¨“Í‚¯B
`‚¢‚¢“õ‚¢I`
‘ü¡i-mode‰“oê‹L”OƒI[ƒ‹3000‰~‚Å—ŽŽD‚Å‚«‚é‚æ!

http://love77.to
@@@@@@@@@@@@@@@@@@@@@@ƒpƒ“ƒeƒBƒnƒEƒX

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@V‘•ŠJ“XIŒƒˆÀƒZ[ƒ‹@¡

AV.DVDŒƒˆÀƒZ[ƒ‹
‘¼“X‚Å‚ÍŽè‚É“ü‚ç‚È‚¢‚à‚̂΂©‚µ¥¥
‚â‚Þ‚ð‚¦‚¸‚µ‚΂炭‹x‹Æ‚µ‚Ä‚¢‚Ü‚µ‚½‚ªA
ˆê”N‚Ô‚è‚̉c‹ÆÄŠJ‚Æ‚È‚è‚Ü‚µ‚½B
ˆÈ‘O‚̂悤‚ɁA‚æ‚낵‚­‚¨Šè‚¢‚µ‚Ü‚·B
‘¼“X‚É•‰‚¯‚¸ŒƒˆÀ—¿‹à‚ʼnc‹Æ‚ðÄŠJ’†B

http://cf-boss.to/
@@@@@@@@@@@@@@@@@@@@@@@ƒsƒ“ƒNƒnƒEƒX

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@‘ÛŒð—¬‚ð[‚ß‚éƒ`ƒƒƒ“ƒX@¡

‘Ûo‰ï‚¢‚̍Lê™
¢ŠEŠe‘‚ÌLady‚Æ’m‚荇‚¤ƒ`ƒƒƒ“ƒX!!
‚ ‚È‚½‚àƒXƒeƒL‚È—ö‚µ‚Ü‚¹‚ñ‚©H
“ú–{l’j«‚Æ•t‚«‡‚¢‚½‚¢ŠO‘l—«‚ð•åW‚µ‚½Œ‹‰ÊA
‚È‚ñ‚Æ2516lW‚Ü‚è‚Ü‚µ‚½I
‹CŒy‚ÈŒðÛŠó–]‚Ì•ûA^Œ•‚ɍ‘ÛŒ‹¥‚ðl‚¦‚Ä‚¢‚é•û‚Ç‚¿‚ç‚àOKô
ƒXƒeƒL‚ÈŠO‘l—«‚ðÐ‰î‚µ‚Ü‚·B
ŽÊ^•tƒvƒƒtƒB[ƒ‹‚©‚çƒAƒiƒ^‚̍D‚Ý‚Å‘I‚ñ‚łˁ™

http://u-serf.com/
@@@@@@@@@@@@@@@@@@@@@‚s‚b‚oÐ‰îƒZƒ“ƒ^[

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@AV’j—DE——D•åW@¡

’´‚Žû“ü‚P‚O‚O–œˆÈã!
ŒŽˆê‰ñA‹ó‚¢‚Ă鎞ŠÔ‚ÅŽB‰e‚µ‚Ü‚·‚̂ŁA•›‹Æ‚ɍœKB
—L–¼ŠÄ“‚ª‰SŽÒ‚ɐeØŽw“±

‚Žû“ü‚ð–]‚Þ•û‚Í
http://www.media-0.com/user/allright/
@@@@@@@@@@@@@@@@@@@@@@@@ƒTƒ“ƒvƒŠé‰æ

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@—«‚Ƀ‚ƒeƒ‹‹ÉˆÓ@¡

‚ ‚¢‚‚̓‚ƒeƒ‹‚̂ɁA‚Ç‚¤‚µ‚ăIƒŒ‚̓‚ƒe‚È‚¢‚È‚¢‚ñ‚¾‚낤¥¥¥
‚»‚ê‚Í’j‚Ì”­‚·‚éƒtƒFƒƒ‚ƒ“‚̈Ⴂ‚È‚Ì‚Å‚·B

‚±‚̂ЂƂӂ«‚ŏ—«‚Ì–{”\‚ðƒVƒQƒL‚µA’N‚Å‚àƒ‚ƒeƒ‚ƒeŒN‚É!!!
—‹ü‚æ‚茋‰Ê‚ŁAŽÀŠ´‚µ‚ĉº‚³‚¢B

Re: GNOME 2.0 DOES NOT COMPILE

[Joe Marcus Clarke]

On Fri, 2002-10-04 at 10:39, Lars Eggert wrote:
 The Gupta Age wrote:
  Hi.
  
  I was trying to compile GNOME 2.0 on a freebsd current
  machine on which the world was recently cvsuped, built
  and installed. CVSUP-ed on 09/22/2002
  
  the gnome compilation breaks while trying to compile
  libgtop2. here is the error:
 
 I ran into the same problem last week. Check the archives for the 
 sys/sys/proc.h 1.250 breaks devel/libgtop2 port thread, it has some 
 fixes in its replies.

Okay, I'm back from vacation, here are the patches.  These will be
committed when the ports freeze lifts.  Thanks goes to julian for
pointing me to using a pure libkvm solution.

Joe

 
 Lars
 -- 
 Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


--- sysdeps/freebsd/proctime.c.orig	Mon Jun 10 17:34:42 2002
+++ sysdeps/freebsd/proctime.c	Wed Oct  2 21:18:38 2002
@@ -57,6 +57,7 @@
  * system, and interrupt time usage.
  */
 
+#ifndef __FreeBSD__
 static void
 calcru(p, up, sp, ip)
  struct proc *p;
@@ -66,9 +67,6 @@
 {
 	quad_t totusec;
 	u_quad_t u, st, ut, it, tot;
-#if (__FreeBSD_version  33)
-long sec, usec;
-#endif
 struct timeval tv;
 
 	st = p-p_sticks;
@@ -81,19 +79,10 @@
 		tot = 1;
 	}
 
-#if (defined __FreeBSD__)  (__FreeBSD_version = 33)
-
-	/* This was changed from a `struct timeval' into a `u_int64_t'
-	 * on FreeBSD 3.0 and renamed p_rtime - p_runtime.
-	 */
-
-	totusec = (u_quad_t) p-p_runtime;
-#else
 	sec = p-p_rtime.tv_sec;
 	usec = p-p_rtime.tv_usec;
 
 	totusec = (quad_t)sec * 100 + usec;
-#endif
 
 	if (totusec  0) {
 		/* XXX no %qd in kernel.  Truncate. */
@@ -116,6 +105,7 @@
 		ip-tv_usec = it % 100;
 	}
 }
+#endif
 
 /* Provides detailed information about a process. */
 
@@ -142,25 +132,25 @@
 	/* It does not work for the swapper task. */
 	if (pid == 0) return;
 	
-#if !(defined(__NetBSD__)  (__NetBSD_Version__ = 10400))
+#if (defined(__NetBSD__)  (__NetBSD_Version__ = 10400))
 	if (server-sysdeps.proc_time == 0)
 		return;
 
+#endif
 #ifndef __bsdi__
 	sprintf (filename, /proc/%d/mem, (int) pid);
 	if (stat (filename, statb)) return;
 #endif
-#endif
 
 	/* Get the process information */
 	pinfo = kvm_getprocs (server-machine.kd, KERN_PROC_PID, pid, count);
 	if ((pinfo == NULL) || (count != 1))
 		glibtop_error_io_r (server, kvm_getprocs (%d), pid);
 
-#if (defined __FreeBSD__)  (__FreeBSD_version = 33)
-	buf-rtime = pinfo [0].kp_proc.p_runtime;
+#if (defined __FreeBSD__)  (__FreeBSD_version = 500013)
+	buf-rtime = pinfo [0].ki_runtime;
 #else
-	buf-rtime = tv2sec (pinfo [0].kp_proc.p_rtime);
+	buf-rtime = pinfo [0].kp_proc.p_runtime;
 #endif
 
 	buf-frequency = 100;
@@ -192,6 +182,21 @@
 
 	buf-flags |= _glibtop_sysdeps_proc_time_user;
 #else
+#if __FreeBSD_version = 500013
+#if __FreeBSD_version = 500016
+	if ((pinfo [0].ki_flag  PS_INMEM)) {
+#else
+	if ((pinfo [0].ki_flag  P_INMEM)) {
+#endif
+	buf-utime = pinfo [0].ki_runtime;
+	buf-stime = 0; /* XXX */
+	buf-cutime = tv2sec (pinfo [0].ki_childtime);
+	buf-cstime = 0; /* XXX */
+	buf-start_time = tv2sec (pinfo [0].ki_start);
+	buf-flags = _glibtop_sysdeps_proc_time_user;
+	}
+
+#else
 	glibtop_suid_enter (server);
 
 	if ((pinfo [0].kp_proc.p_flag  P_INMEM) 
@@ -199,29 +204,16 @@
 		   (unsigned long) u_addr-u_stats,
 		   (char *) pstats, sizeof (pstats)) == sizeof (pstats))
 		{
-			/* This is taken form the kernel source code of
-			 * FreeBSD 2.2.6. */
-
-			/* Well, we just do the same getrusage () does ... */
-
-			register struct rusage *rup;
-
-			glibtop_suid_leave (server);
-
-			rup = pstats.p_ru;
-			calcru((pinfo [0]).kp_proc,
-			   rup-ru_utime, rup-ru_stime, NULL);
-
-			buf-utime = tv2sec (pstats.p_ru.ru_utime);
-			buf-stime = tv2sec (pstats.p_ru.ru_stime);
-			
-			buf-cutime = tv2sec (pstats.p_cru.ru_utime);
-			buf-cstime = tv2sec (pstats.p_cru.ru_stime);
-
-			buf-start_time = tv2sec (pstats.p_start);
 
+			buf-utime = tv2sec (pinfo[0].kp_eproc.e_stats.p_ru.ru_utime);
+			buf-stime = tv2sec (pinfo[0].kp_eproc.e_stats.p_ru.ru_stime);
+			buf-cutime = tv2sec (pinfo[0].kp_eproc.e_stats.p_cru.ru_utime);
+			buf-cstime = tv2sec (pinfo[0].kp_eproc.e_stats.p_cru.ru_stime);
+			buf-start_time = tv2sec (pinfo[0].kp_eproc.e_stats.p_start);
 			buf-flags = _glibtop_sysdeps_proc_time_user;
+			glibtop_suid_leave (server);
 		}
+#endif
 
 	glibtop_suid_leave (server);
 #endif


--- sysdeps/freebsd/procmap.c.orig  Mon Jun 10 17:34:42 2002
+++ sysdeps/freebsd/procmap.c   Fri Sep 20 16:10:37 2002
@@ -33,7 +33,11 @@
 #include sys/proc.h
 #include sys/resource.h
 #include vm/vm_object.h
+#if (__FreeBSD_version = 400011)
+#include vm/vm.h
+#else
 #include vm/vm_prot.h
+#endif
 #include vm/vm_map.h
 
 #include sys/vnode.h
@@ -92,7 +96,6 @@
 #if defined __FreeBSD__
struct vnode vnode;
struct inode inode;
-   struct mount mount;
 #endif
int count, i = 0;
  

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[n0go013]

On 04.10-15:40, fergus wrote:
 On 04.10-14:20, Poul-Henning Kamp wrote:
 [...]
  I suspect vinum uses this sysctl to get an inventory of disks in
  the system, so can I get you to try again making sure you have
  rev. 1.20 of src/sys/geom/geom_disk.c ?
[...]
 i'll let you know the test results when i have some.

same results -- can't initialise any drives.  i think the example below
points more directly to the issue but i'm pretty sure it is because the
direct read from the disk does not return a valid disklabel.  without a
'vinum' partition entry vinum spews.

+++ vinum start +++
eyore# vinum start
** no drives found: No such file or directory
--- vinum start ---

-- 
t
 t
 z

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], n0go013 writes
:
On 04.10-15:40, fergus wrote:
 On 04.10-14:20, Poul-Henning Kamp wrote:
 [...]
  I suspect vinum uses this sysctl to get an inventory of disks in
  the system, so can I get you to try again making sure you have
  rev. 1.20 of src/sys/geom/geom_disk.c ?
[...]
 i'll let you know the test results when i have some.

same results -- can't initialise any drives.  i think the example below
points more directly to the issue but i'm pretty sure it is because the
direct read from the disk does not return a valid disklabel.  without a
'vinum' partition entry vinum spews.

I have no idea how vinum does this or something else, but clearly
something is not done the right way in vinum...

-- 
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: GNOME 2.0 DOES NOT COMPILE

[Julian Elischer]

Joe, the libkvm changes should work all the way back to 4.x
(I haven't tested this of course) but 'ps has been using it to 
get this info for years) that would simplify the 
conditionals.
(i.e just remove the old code)

On 4 Oct 2002, Joe Marcus Clarke wrote:

 On Fri, 2002-10-04 at 10:39, Lars Eggert wrote:
  The Gupta Age wrote:
   Hi.
   
   I was trying to compile GNOME 2.0 on a freebsd current
   machine on which the world was recently cvsuped, built
   and installed. CVSUP-ed on 09/22/2002
   
   the gnome compilation breaks while trying to compile
   libgtop2. here is the error:
  
  I ran into the same problem last week. Check the archives for the 
  sys/sys/proc.h 1.250 breaks devel/libgtop2 port thread, it has some 
  fixes in its replies.
 
 Okay, I'm back from vacation, here are the patches.  These will be
 committed when the ports freeze lifts.  Thanks goes to julian for
 pointing me to using a pure libkvm solution.
 
 Joe
 
  
  Lars
  -- 
  Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute
 -- 
 PGP Key : http://www.marcuscom.com/pgp.asc
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: expat2 in the base system?

[Chris Doherty]

On Fri, Oct 04, 2002 at 08:10:57AM -0700, Bill Huey said: 
 On Fri, Oct 04, 2002 at 10:24:03AM -0400, Jeroen C. van Gelderen wrote:
  Almost. It's indeed called Ant but has been developed under the 
  umbrella of the Apache Jakarta project.
 
 I used it to build Tomcat tonight and it looks to be a very power
 package.

it is--it's great for Java development (modulo the verbosity involved with
XML-anything). I'm not sure how suited it is for other languages,
though--AFAICT you'd have to gin up targets from scratch, since the
built-in and add-on target are Java-specific.

chris


---
Chris Doherty
chris [at] randomcamel.net

I think, said Christopher Robin, that we ought to eat
all our provisions now, so we won't have so much to carry.
   -- A. A. Milne
---

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

i386 tinderbox failure

[Dag-Erling Smorgrav]

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Oct  4 09:46:35 PDT 2002
--
 Kernel build for GENERIC completed on Fri Oct  4 10:29:41 PDT 2002
--
 Kernel build for LINT started on Fri Oct  4 10:29:42 PDT 2002
--
=== xe
/local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:480: warning: no previous 
prototype for `AcpiDbDecodeNode'
/local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function 
`AcpiGetSleepTypeData':
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetRegionName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:492: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetEventName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:530: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetTypeName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:610: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined 
but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:274: warning: 
`acpi_pwr_deregister_consumer' defined but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:212: warning: 
`acpi_pwr_deregister_resource' defined but not used
/local0/scratch/des/src/sys/dev/hea/eni_buffer.c: In function `eni_test_memory':
/local0/scratch/des/src/sys/dev/hea/eni_buffer.c:127: warning: passing arg 1 of 
pointer to function makes pointer from integer without a cast
/local0/scratch/des/src/sys/dev/hea/eni_vcm.c: In function `eni_closevcc':
/local0/scratch/des/src/sys/dev/hea/eni_vcm.c:289: warning: passing arg 1 of pointer 
to function makes pointer from integer without a cast
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:779: warning: assignment discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget':

Re: [ GEOM tests ] vinum drives lost

[n0go013]

On 04.10-18:27, Poul-Henning Kamp wrote:
 In message n0go013 writes :
 On 04.10-15:40, fergus wrote:
   On 04.10-14:20, Poul-Henning Kamp wrote:
   [...]
I suspect vinum uses this sysctl to get an inventory of disks in
the system, so can I get you to try again making sure you have
rev. 1.20 of src/sys/geom/geom_disk.c ?
  [...]
   i'll let you know the test results when i have some.
 
  same results -- can't initialise any drives.  i think the example below
  points more directly to the issue but i'm pretty sure it is because the
  direct read from the disk does not return a valid disklabel.  without a
  'vinum' partition entry vinum spews.
 
 I have no idea how vinum does this or something else, but clearly
 something is not done the right way in vinum...

apparently by allocating a bio header via 'geteblk' and calling the
DEV_STRATEGY macro.  not that it means anything to me but probably to
you it does (well i get the idea but . . .).

what is the correct way to read the disklabel ?  i'll hack around and
see if i can't clean up this and the other pieces of direct IO.

-- 
t
 t
 z

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], n0go013 writes
:
On 04.10-18:27, Poul-Henning Kamp wrote:
 In message n0go013 writes :
 On 04.10-15:40, fergus wrote:
   On 04.10-14:20, Poul-Henning Kamp wrote:
   [...]
I suspect vinum uses this sysctl to get an inventory of disks in
the system, so can I get you to try again making sure you have
rev. 1.20 of src/sys/geom/geom_disk.c ?
  [...]
   i'll let you know the test results when i have some.
 
  same results -- can't initialise any drives.  i think the example below
  points more directly to the issue but i'm pretty sure it is because the
  direct read from the disk does not return a valid disklabel.  without a
  'vinum' partition entry vinum spews.
 
 I have no idea how vinum does this or something else, but clearly
 something is not done the right way in vinum...

apparently by allocating a bio header via 'geteblk' and calling the
DEV_STRATEGY macro.  not that it means anything to me but probably to
you it does (well i get the idea but . . .).

what is the correct way to read the disklabel ?  i'll hack around and
see if i can't clean up this and the other pieces of direct IO.

I would need to look at the code to be able to tell, I don't have
time for that.


-- 
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: GNOME 2.0 DOES NOT COMPILE

[Joe Marcus Clarke]

On Fri, 2002-10-04 at 12:23, Julian Elischer wrote:
 
 Joe, the libkvm changes should work all the way back to 4.x
 (I haven't tested this of course) but 'ps has been using it to 
 get this info for years) that would simplify the 
 conditionals.
 (i.e just remove the old code)

Yep, my patches cover 4.x as well.  I modeled things after ps a bit.

You're right, I could have just removed all the non-FreeBSD code. 
However, doing it this way will make things easier to get back into the
libgtop tree.

Joe

 
 On 4 Oct 2002, Joe Marcus Clarke wrote:
 
  On Fri, 2002-10-04 at 10:39, Lars Eggert wrote:
   The Gupta Age wrote:
Hi.

I was trying to compile GNOME 2.0 on a freebsd current
machine on which the world was recently cvsuped, built
and installed. CVSUP-ed on 09/22/2002

the gnome compilation breaks while trying to compile
libgtop2. here is the error:
   
   I ran into the same problem last week. Check the archives for the 
   sys/sys/proc.h 1.250 breaks devel/libgtop2 port thread, it has some 
   fixes in its replies.
  
  Okay, I'm back from vacation, here are the patches.  These will be
  committed when the ports freeze lifts.  Thanks goes to julian for
  pointing me to using a pure libkvm solution.
  
  Joe
  
   
   Lars
   -- 
   Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute
  -- 
  PGP Key : http://www.marcuscom.com/pgp.asc
  
 
 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Meaning of net.inet.tcp.inflight_debug output?

[Matthew Dillon]

:Hi,
:
:what does this mean? Is it important?
:---snip---
:kernel: 0xc27b4814 bw 4 rttbest 2735 srtt 2250 bwnd 2803
:kernel: 0xc0ef235c bw 23101 rttbest 680 srtt 293056 bwnd 1063153
:kernel: 0xc27b435c bw 54061 rttbest 1297 srtt 1756 bwnd 28636
:kernel: 0xc27b435c bw 47663 rttbest 1297 srtt 1784 bwnd 25793
:kernel: 0xc0ef235c bw 24288 rttbest 680 srtt 305216 bwnd 1163779
:kernel: 0xc0ef235c bw 22928 rttbest 680 srtt 306864 bwnd 1104680
:kernel: 0xc0ef235c bw 19812 rttbest 680 srtt 311471 bwnd 969203
:kernel: 0xc27b435c bw 53468 rttbest 1297 srtt 2014 bwnd 30508
:kernel: 0xc27b435c bw 47727 rttbest 1297 srtt 1767 bwnd 25705
:---snip---
:
:Bye,
:Alexander.
:
:http://www.Leidinger.net   Alexander @ Leidinger.net
:  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

When you turn the debugging on it will print out various parameters
used to calculate the bandwidth window.  The higher the debug value,
the more often it prints out the stats (assuming a TCP is under load).
Since the stats may reflect any tcp connection you typically only do
this while running a single TCP connection under heavy load.

bw: Calculated bandwidth of connection, bytes/sec.  Note that
if the only connection is you typing in a shell then the
'bw' you get will be the approximate data rate created 
by your typing.

rttbest:The best RTT observed for the connection to date

srtt:   The current smoothed round trip time

bwnd:   The calculated bandwidth window ( which is used to limit
the amount of unacknowledged data being transmitted to
the bandwidth delay product of the connection ).

rttbest and srtt are scaled to hz * 32, I believe (I'm not positive).
So with the default 100 hz it would be scaled to 3200, so an rttbest
of 680 would translate to 212mS.  Sounds like a connection over
a modem.

The bandwidth delay product calculation is used to limit the size of
the transmit window... that is, the number of data packets that can be
inflight (on the wire) without being acknowledged.   This is of particular
use over a modem connection (prevents too many packets from building up
in the send queue) or a GigE link (prevents the interface queue from
being completely blown out of the water and dropping packets when
large TCP buffers have been configured, amoung other things).

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Lars Eggert]

Poul-Henning Kamp wrote:
 
 I would need to look at the code to be able to tell, I don't have
 time for that.

I'd consider not having vinum work under geom a show-stopper... at least 
until geom can stripe.

Lars
-- 
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ GEOM tests ] vinum drives lost

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Lars Eggert writes:
This is a cryptographically signed message in MIME format.

--ms040706010906030302070807
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Poul-Henning Kamp wrote:
 
 I would need to look at the code to be able to tell, I don't have
 time for that.

I'd consider not having vinum work under geom a show-stopper... at least 
until geom can stripe.

Well, the showstopper is in vinum.  The fact that ccd(4) works
seamlessly with GEOM is testament to this.

There are numerous architectural issues which have never been
fixed in vinum, and one or more of these bits now.

Whoever loves vinum will have to chase it/them down and fix it.

If I receive patches or requests for changes to GEOM as result
of this, they will be evaluated in good faith.

Worst case you will have the option to use:

options NOGEOM
options vinum

-- 
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: [Call for testers] acpica-unix-20020918

[Frode Nordahl]

Hello, 

It works fine here, and the battery status works now! 

No lid switch yet though :-/ 

Thanks! 

Mvh, 
Frode Nordahl 

On Tue, 2002-10-01 at 17:27, Mitsuru IWASAKI wrote: 
 [forgot to announce]
 Please try the latest version acpica-unix-20020829, patches for
 FreeBSD at:
 http://people.freebsd.org/~iwasaki/acpi/acpica-20020815-20020918-test20020920.diff
 
 CHANGES.txt can be fould as always at:
 http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt
  
 I'll import this coming weekend.
 
 Thanks
 
 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: [ GEOM tests ] vinum drives lost

[Lars Eggert]

Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Lars Eggert writes:

I'd consider not having vinum work under geom a show-stopper... at least 
until geom can stripe.
 
 
 Well, the showstopper is in vinum.  The fact that ccd(4) works
 seamlessly with GEOM is testament to this.

For some reason I was under the (mis?)impression that ccd was no longer 
being maintained... If it works with geom, we can probably move our 
machines over to ccd. They're all no-frills stripes, so ccd 
functionality is good enough.

Thanks for clearing that up!

Lars
-- 
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ GEOM tests ] vinum drives lost

[Julian Elischer]

On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Lars Eggert writes:
 This is a cryptographically signed message in MIME format.
 
 --ms040706010906030302070807
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Poul-Henning Kamp wrote:
  
  I would need to look at the code to be able to tell, I don't have
  time for that.
 
 I'd consider not having vinum work under geom a show-stopper... at least 
 until geom can stripe.
 
 Well, the showstopper is in vinum.  The fact that ccd(4) works
 seamlessly with GEOM is testament to this.
 
 There are numerous architectural issues which have never been
 fixed in vinum, and one or more of these bits now.
 
 Whoever loves vinum will have to chase it/them down and fix it.

No, it is established principal tha the importer of new features has the
responsibility to make older subsystems work.



 
 If I receive patches or requests for changes to GEOM as result
 of this, they will be evaluated in good faith.
 
 Worst case you will have the option to use:
 
   options NOGEOM
   options vinum
 
 -- 
 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-hackers in the body of the message
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[John Baldwin]

On 04-Oct-2002 Julian Elischer wrote:
 
 
 On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
 
 In message [EMAIL PROTECTED], Lars Eggert writes:
 This is a cryptographically signed message in MIME format.
 
 --ms040706010906030302070807
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Poul-Henning Kamp wrote:
  
  I would need to look at the code to be able to tell, I don't have
  time for that.
 
 I'd consider not having vinum work under geom a show-stopper... at least 
 until geom can stripe.
 
 Well, the showstopper is in vinum.  The fact that ccd(4) works
 seamlessly with GEOM is testament to this.
 
 There are numerous architectural issues which have never been
 fixed in vinum, and one or more of these bits now.
 
 Whoever loves vinum will have to chase it/them down and fix it.
 
 No, it is established principal tha the importer of new features has the
 responsibility to make older subsystems work.

Oh, you mean like KSE on Alpha?

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: PCI problems with today's current

[John Baldwin]

On 03-Oct-2002 Kenneth D. Merry wrote:
 
 I have a Supermicro P3TDE6 motherboard (Serverworks HE-SL chipset) that
 won't boot with today's -current.
 
 -current from August 23rd sources boots fine.
 
 It looks like the PCI bus probe is failing somehow.
 
 I've seen other folks complaining about PCI problems, and I suppose this is
 related, but I don't think I've seen quite the same failure reported.
 
 I've attached dmesg output from the working kernel (August 23rd sources)
 and the broken kernel (sources from ~1500 MDT today).
 
 Any ideas on how to fix this?

Turn off ACPI for now (set hint.acpi.0.disabled=1).  Iwasaki-san has a fix
for this that I guess he should commit.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Ju
lian Elischer writes:

No, it is established principal tha the importer of new features has the
responsibility to make older subsystems work.

I'm _so_ glad to hear _you_ say that:

When will you have made KSE work on sparc64 and ia64 ?

-- 
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

ccd striping ?? [Was: vinum disks lost]

[n0go013]

On 04.10-12:45, Lars Eggert wrote:
[...]
 For some reason I was under the (mis?)impression that ccd was no longer 
 being maintained... If it works with geom, we can probably move our 
 machines over to ccd. They're all no-frills stripes, so ccd 
 functionality is good enough.
[...]

i'm not contesting the point -- i can run happily without vinum
(especially because it appears to be leaking a wad of kernel memory
through vfs/inode functions -- which is what i was going to look at
before got side tracked on this) but ccd doesn't stripe does it?

-- 
t
 t
 z

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Daniel Holmes]

Lars Eggert wrote:

 For some reason I was under the (mis?)impression that ccd was no longer 
 being maintained... If it works with geom, we can probably move our 
 machines over to ccd. They're all no-frills stripes, so ccd 
 functionality is good enough.

From the man page of ccd:

  ccd has an option for a parity disk, but does not currently implement it.

and

  In an event of a disk failure, you can use dd(1) to recover the failed
  disk.

As I understand vinum  ccd (please correct me if I am wrong), this will
keep ccd from ever achieving the performance and ease of use of vinum.
I use vinum for a simple mirror, and found it easier to configure than
ccd.  Keeping it from running in 5.0 would probably kill a lot of setups.

Thanks,
Dan
--
Daniel D Holmes, N7NKR  I'net:  [EMAIL PROTECTED]
Standard disclaimers apply wherever you can find a sticky spot.
I'm betting that I'm just abnormal enough to survive. -- The Tick

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Daniel Holmes write
s:

As I understand vinum  ccd (please correct me if I am wrong), this will
keep ccd from ever achieving the performance and ease of use of vinum.

I don't think anybody advocated ccd as a wholesale replacement for
vinum.  That being said, I have lost more data on vinum RAID5
volumes than on striped ccd parititions, and not becaue of hardware
failures.

-- 
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: [ GEOM tests ] vinum drives lost

[Julian Elischer]

On Fri, 4 Oct 2002, John Baldwin wrote:

 
 On 04-Oct-2002 Julian Elischer wrote:
  
  
  On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
  
  In message [EMAIL PROTECTED], Lars Eggert writes:
  This is a cryptographically signed message in MIME format.
  
  --ms040706010906030302070807
  Content-Type: text/plain; charset=us-ascii; format=flowed
  Content-Transfer-Encoding: 7bit
  
  Poul-Henning Kamp wrote:
   
   I would need to look at the code to be able to tell, I don't have
   time for that.
  
  I'd consider not having vinum work under geom a show-stopper... at least 
  until geom can stripe.
  
  Well, the showstopper is in vinum.  The fact that ccd(4) works
  seamlessly with GEOM is testament to this.
  
  There are numerous architectural issues which have never been
  fixed in vinum, and one or more of these bits now.
  
  Whoever loves vinum will have to chase it/them down and fix it.
  
  No, it is established principal tha the importer of new features has the
  responsibility to make older subsystems work.
 
 Oh, you mean like KSE on Alpha?

What existing functionality on the alpha does KSE stop?


 
 -- 
 
 John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
 Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

HEADSUP: acpica-unix-20021002 imported (Re: cvs commit:src/sys/contrib/dev/acpica - Imported sources)

[Mitsuru IWASAKI]

I've imported Intel acpica-unix-20021002 which is the latest version.
It seems that some problems related with ACPI namespace parsing are
solved from 20020815.

Detailed info. about changes is available at:
http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt

If you have any problems with the new version, please report to
[EMAIL PROTECTED]

Thanks!

From: Mitsuru IWASAKI [EMAIL PROTECTED]
Subject: cvs commit: src/sys/contrib/dev/acpica - Imported sources
Date: Fri, 4 Oct 2002 13:07:58 -0700 (PDT)
Message-ID: [EMAIL PROTECTED]

 iwasaki 2002/10/04 13:07:58 PDT
 
   src/sys/contrib/dev/acpica - Imported sources
   Update of /home/ncvs/src/sys/contrib/dev/acpica
   In directory freefall.freebsd.org:/d/home/iwasaki/tmp/acpica/acpi_ca_destination
   
   Log Message:
   Vendor import of the Intel ACPI CA 20021002 drop.
   
   Status:
   
   Vendor Tag: INTEL
   Release Tags:   r20021002

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Junior Kernel Hacker page updated...

[Juli Mallett]

* De: Stefan Farfeleder [EMAIL PROTECTED] [ Data: 2002-10-04 ]
[ Subjecte: Re: Junior Kernel Hacker page updated... ]
 On Thu, Oct 03, 2002 at 04:41:46PM +0200, Poul-Henning Kamp wrote:
  
  Hi Stefan,
  
  I tried this patch and it paniced my (almost-) current machine with
  a pagefault in the kqueue code:  Bravo!
  
  I can see that there is some amount of #ifdef stuff in your patch,
 
 The #ifdefs are already in the code, namely REMOTE and RMT_WILL_WATCH.
 Is anybody using them? Building with -DREMOTE doesn't compile and with
 -DRMT_WILL_WATCH the linker is complaining about the lack of the
 functions Rmt_Ignore(), Rmt_Watch() and Rmt_Wait(). Can't we get rid of
 those defines? I understand Juli Mallett wants to rewrite make, so maybe
 this effort would be wasted.
 
  in light of that, would it be possible to make an #ifdef'ed version
  of your patch which we could commit ?
 
 Ok, the new patch is attached. Compile with -DUSE_KQUEUE to use the new
 code.
 
  That way we give the kqueue hackers a good testcase, and we can
  easily enable when they have solved the problem.
 
 After Don Lewis fixed the 'could sleep with' problem (thanks!), I'm
 still encountering freezes and panics. Here's one I caught:
 
 [warning: parts are typed in]
 %%%
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; lapic.id = 
 fault virtual address   = 0x8
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc01a1212
 stack pointer   = 0x10:0xe5226c14
 frame pointer   = 0x10:0xe5226ca0
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 56525 (make)
 
 kernel: type 12 trap, code = 0
 
 Stopped atkqueue_scan+0x242:  cmpl $0,0x8(%ebx)
 db trace
 kqueue_scan(c6472bf4,4,bfbfebc0,0,c70ecea0) at kqueue_scan+0x242
 kevent(c70ecea0,e5226d10,c0351d80,418,6) at kevent+0x1e1
 syscall(2f,2f,2f,818d780,818d960) at syscall+0x2be
 %%%

Run the kqueue source file through gcc with -fverbose-asm -S and then
look at the resulting .s file, grep for cmpl.*0x8( and look for
what's being dereferenced without being checked for NULL.

 The core file doesn't seem to be particularly helpful, as the
 kqueue_scan frame seems to miss:
 
 %%%
 (kgdb) bt
 #0  doadump () at /freebsd/current/src/sys/kern/kern_shutdown.c:223
 #1  0xc01ba92a in boot (howto=260)
 at /freebsd/current/src/sys/kern/kern_shutdown.c:355
 #2  0xc01babe7 in panic () at /freebsd/current/src/sys/kern/kern_shutdown.c:508
 #3  0xc013b1d2 in db_panic () at /freebsd/current/src/sys/ddb/db_command.c:450
 #4  0xc013b152 in db_command (last_cmdp=0xc035db20, cmd_table=0x0, 
 aux_cmd_tablep=0xc03577dc, aux_cmd_tablep_end=0xc03577e0)
 at /freebsd/current/src/sys/ddb/db_command.c:346
 #5  0xc013b266 in db_command_loop ()
 at /freebsd/current/src/sys/ddb/db_command.c:472
 #6  0xc013deca in db_trap (type=12, code=0)
 at /freebsd/current/src/sys/ddb/db_trap.c:72
 #7  0xc02e9f60 in kdb_trap (type=12, code=0, regs=0xe5226bd4)
 at /freebsd/current/src/sys/i386/i386/db_interface.c:166
 #8  0xc0302602 in trap_fatal (frame=0xe5226bd4, eva=0)
 at /freebsd/current/src/sys/i386/i386/trap.c:841
 #9  0xc03022e2 in trap_pfault (frame=0xe5226bd4, usermode=0, eva=8)
 at /freebsd/current/src/sys/i386/i386/trap.c:760
 #10 0xc0301e0d in trap (frame=
   {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -943606528, tf_esi = -943606488, 
tf_ebp = -450728800, tf_isp = -450728960, tf_ebx = 0, tf_edx = 4, tf_ecx = 1, tf_eax 
= 0, tf_trapno = 12, tf_err = 0, tf_eip = -1072033262, tf_cs = 8, tf_eflags = 66050, 
tf_esp = -966356416, tf_ss = 0})
 ---Type return to continue, or q return to quit---
 at /freebsd/current/src/sys/i386/i386/trap.c:446
 #11 0xc02eb768 in calltrap () at {standard input}:99
 #12 0xc01a0ad1 in kevent (td=0xc70ecea0, uap=0xe5226d10)
 at /freebsd/current/src/sys/kern/kern_event.c:470
 #13 0xc030299e in syscall (frame=
   {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135845760, tf_esi = 135846240, 
tf_ebp = -1077941224, tf_isp = -450728588, tf_ebx = 134831872, tf_edx = 2184, tf_ecx 
= 0, tf_eax = 363, tf_trapno = 12, tf_err = 2, tf_eip = 134626551, tf_cs = 31, 
tf_eflags = 514, tf_esp = -1077941348, tf_ss = 47})
 at /freebsd/current/src/sys/i386/i386/trap.c:1050
 #14 0xc02eb7bd in Xint0x80_syscall () at {standard input}:141
 ---Can't read userspace from dump, or kernel process---
 %%%
 
 objdump -dS kern_event.o says the following about kqueue_scan+0x242
 [==0xfd2]:
 
 %%%
  fce:   90  nop
  fcf:   90  nop
 kn = TAILQ_FIRST(kq-kq_head);
  fd0:   8b 1f   mov(%edi),%ebx
 TAILQ_REMOVE(kq-kq_head, kn, kn_tqe); 
  fd2:   83 7b 08 00 cmpl   $0x0,0x8(%ebx)
  fd6:   74 0b   

Re: [ GEOM tests ] vinum drives lost

[Daniel Eischen]

On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Ju
 lian Elischer writes:
 
 No, it is established principal tha the importer of new features has the
 responsibility to make older subsystems work.
 
 I'm _so_ glad to hear _you_ say that:
 
 When will you have made KSE work on sparc64 and ia64 ?

Those are Tier2 platforms :-)

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[John Baldwin]

On 04-Oct-2002 Julian Elischer wrote:
 
 
 On Fri, 4 Oct 2002, John Baldwin wrote:
 
 
 On 04-Oct-2002 Julian Elischer wrote:
  
  
  On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
  
  In message [EMAIL PROTECTED], Lars Eggert writes:
  This is a cryptographically signed message in MIME format.
  
  --ms040706010906030302070807
  Content-Type: text/plain; charset=us-ascii; format=flowed
  Content-Transfer-Encoding: 7bit
  
  Poul-Henning Kamp wrote:
   
   I would need to look at the code to be able to tell, I don't have
   time for that.
  
  I'd consider not having vinum work under geom a show-stopper... at least 
  until geom can stripe.
  
  Well, the showstopper is in vinum.  The fact that ccd(4) works
  seamlessly with GEOM is testament to this.
  
  There are numerous architectural issues which have never been
  fixed in vinum, and one or more of these bits now.
  
  Whoever loves vinum will have to chase it/them down and fix it.
  
  No, it is established principal tha the importer of new features has the
  responsibility to make older subsystems work.
 
 Oh, you mean like KSE on Alpha?
 
 What existing functionality on the alpha does KSE stop?

So you agree that requiring vinum users to turn off GEOM is ok?  Part
of adding a new feature is providing proof of concept that it works
for more than just one tiny case.  Also, if you actually have to make
it work on multiple cases, then you have to learn enough about other
cases to better enable you to make better-informed design decisions
that take other cases into account.  One KSE works on i386, what are
multithreaded ports like, oh, X, supposed to do when compiling with
-lpthread doesn't work?

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Junior Kernel Hacker page updated...

[John Baldwin]

On 04-Oct-2002 Juli Mallett wrote:
 * De: Stefan Farfeleder [EMAIL PROTECTED] [ Data: 2002-10-04 ]
   [ Subjecte: Re: Junior Kernel Hacker page updated... ]
 On Thu, Oct 03, 2002 at 04:41:46PM +0200, Poul-Henning Kamp wrote:
  
  Hi Stefan,
  
  I tried this patch and it paniced my (almost-) current machine with
  a pagefault in the kqueue code:  Bravo!
  
  I can see that there is some amount of #ifdef stuff in your patch,
 
 The #ifdefs are already in the code, namely REMOTE and RMT_WILL_WATCH.
 Is anybody using them? Building with -DREMOTE doesn't compile and with
 -DRMT_WILL_WATCH the linker is complaining about the lack of the
 functions Rmt_Ignore(), Rmt_Watch() and Rmt_Wait(). Can't we get rid of
 those defines? I understand Juli Mallett wants to rewrite make, so maybe
 this effort would be wasted.
 
  in light of that, would it be possible to make an #ifdef'ed version
  of your patch which we could commit ?
 
 Ok, the new patch is attached. Compile with -DUSE_KQUEUE to use the new
 code.
 
  That way we give the kqueue hackers a good testcase, and we can
  easily enable when they have solved the problem.
 
 After Don Lewis fixed the 'could sleep with' problem (thanks!), I'm
 still encountering freezes and panics. Here's one I caught:
 
 [warning: parts are typed in]
 %%%
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; lapic.id = 
 fault virtual address   = 0x8
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc01a1212
 stack pointer   = 0x10:0xe5226c14
 frame pointer   = 0x10:0xe5226ca0
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 56525 (make)
 
 kernel: type 12 trap, code = 0
 
 Stopped atkqueue_scan+0x242:  cmpl $0,0x8(%ebx)
 db trace
 kqueue_scan(c6472bf4,4,bfbfebc0,0,c70ecea0) at kqueue_scan+0x242
 kevent(c70ecea0,e5226d10,c0351d80,418,6) at kevent+0x1e1
 syscall(2f,2f,2f,818d780,818d960) at syscall+0x2be
 %%%
 
 Run the kqueue source file through gcc with -fverbose-asm -S and then
 look at the resulting .s file, grep for cmpl.*0x8( and look for
 what's being dereferenced without being checked for NULL.

Even better, pop up gdb on kernel.debug and do
'l *kqueue_scan+0x242' to look at the offending line of code.
addr2line can also be useful here similarly.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Junior Kernel Hacker page updated...

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Stefan Farfeleder writes:


I have committed your patch, but left it #undef'ed until we get
the kernel straightened out.

On behalf of the FreeBSD project I have to warn you that if you
persist in doing work of this kind over and over again, you will
eventually be subjected to a commit bit.  You have been warned :-)

Thank you very much for you work! :-)

Poul-Henning

The #ifdefs are already in the code, namely REMOTE and RMT_WILL_WATCH.
Is anybody using them? Building with -DREMOTE doesn't compile and with
-DRMT_WILL_WATCH the linker is complaining about the lack of the
functions Rmt_Ignore(), Rmt_Watch() and Rmt_Wait(). Can't we get rid of
those defines? I understand Juli Mallett wants to rewrite make, so maybe
this effort would be wasted.

I belive the RMT/REMOTE stuff is part of an earlier attempt at putting
in some kind of cluster functionality.

If it is useful in any capacity, even as hint of what/how to do such
a thing, I think we should leave it.  If it is just old junk we
should boot it.

-- 
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: Junior Kernel Hacker page updated...

[Juli Mallett]

* De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2002-10-04 ]
[ Subjecte: Re: Junior Kernel Hacker page updated... ]
 In message [EMAIL PROTECTED], Stefan Farfeleder writes:
 
 
 I have committed your patch, but left it #undef'ed until we get
 the kernel straightened out.
 
 On behalf of the FreeBSD project I have to warn you that if you
 persist in doing work of this kind over and over again, you will
 eventually be subjected to a commit bit.  You have been warned :-)
 
 Thank you very much for you work! :-)
 
 Poul-Henning
 
 The #ifdefs are already in the code, namely REMOTE and RMT_WILL_WATCH.
 Is anybody using them? Building with -DREMOTE doesn't compile and with
 -DRMT_WILL_WATCH the linker is complaining about the lack of the
 functions Rmt_Ignore(), Rmt_Watch() and Rmt_Wait(). Can't we get rid of
 those defines? I understand Juli Mallett wants to rewrite make, so maybe
 this effort would be wasted.
 
 I belive the RMT/REMOTE stuff is part of an earlier attempt at putting
 in some kind of cluster functionality.
 
 If it is useful in any capacity, even as hint of what/how to do such
 a thing, I think we should leave it.  If it is just old junk we
 should boot it.

NetBSD has it working.  I don't recall anymore if the diffs were enough
to dissuade me from making ours work, or if I just had no interest.

It's gone from my local tree simply because I got tired of grepping for
things to debug, and running into ifdef's cruft.
-- 
Juli Mallett [EMAIL PROTECTED]   | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/  | Support my FreeBSD hacking!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Julian Elischer]

On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Ju
 lian Elischer writes:
 
 No, it is established principal tha the importer of new features has the
 responsibility to make older subsystems work.
 
 I'm _so_ glad to hear _you_ say that:
 
 When will you have made KSE work on sparc64 and ia64 ?

When it works on i386.  In case you  haven't noticed, KSE
is not a legacy facility.

love you too.
XXX

 
 -- 
 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: [ GEOM tests ] vinum drives lost

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Daniel E
ischen writes:
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Ju
 lian Elischer writes:
 
 No, it is established principal tha the importer of new features has the
 responsibility to make older subsystems work.
 
 I'm _so_ glad to hear _you_ say that:
 
 When will you have made KSE work on sparc64 and ia64 ?

Those are Tier2 platforms :-)

And ?  Vinum is a tier2 feature.

-- 
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: [ GEOM tests ] vinum drives lost

[Julian Elischer]

On Fri, 4 Oct 2002, John Baldwin wrote:

 
  
  Oh, you mean like KSE on Alpha?
  
  What existing functionality on the alpha does KSE stop?
 
 So you agree that requiring vinum users to turn off GEOM is ok?  Part
 of adding a new feature is providing proof of concept that it works
 for more than just one tiny case.  Also, if you actually have to make
 it work on multiple cases, then you have to learn enough about other
 cases to better enable you to make better-informed design decisions
 that take other cases into account.  One KSE works on i386, what are
 multithreaded ports like, oh, X, supposed to do when compiling with
 -lpthread doesn't work?

I'm not making KSE the default. The discussion is about default
settings.

The ports of KSE to other architectures will be rather minor
but it's pointless to do it until the MI parts settle down.


It's not worth more discussion than this. If we ned to turn off GEOM
to run vinum then ok, it's not a major problem. I think it's the GEOM
author's job to make it work, but if core doesn't tjink he needs to
bother, that's just a reflection on FreeBSD, not me.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Terry Lambert]

Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Ju
 lian Elischer writes:
 No, it is established principal tha the importer of new features has the
 responsibility to make older subsystems work.
 
 I'm _so_ glad to hear _you_ say that:
 
 When will you have made KSE work on sparc64 and ia64 ?

What does KSE break, which used to work on these platforms?

It's not like CAM (to pick an older example that has less emotion
bound up in it), where every SCSI driver that hadn't already been
CAM-ified at the time of the import, broke.  When KSE doesn't work,
you lose only new features, not old ones, right?

Isn't complaining about this on sparc64/ia64/alpha kind of like
complaining about someone adding 4M page support to i386, but not
adding the same thing to other platforms?


-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Daniel Eischen]

On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Daniel E
 ischen writes:
 On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
 
  In message [EMAIL PROTECTED], Ju
  lian Elischer writes:
  
  No, it is established principal tha the importer of new features has the
  responsibility to make older subsystems work.
  
  I'm _so_ glad to hear _you_ say that:
  
  When will you have made KSE work on sparc64 and ia64 ?
 
 Those are Tier2 platforms :-)
 
 And ?  Vinum is a tier2 feature.

I make no judgement about vinum.  Just the comment about
KSE working on sparc64 and ia64.

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RC_NG for local rc scripts

[Scot W. Hetzel]

I was looking at how the RC_NG base scripts work, and decide to try changing 
a few ports rc scripts to RC_NG.  The process was simple enough to convert
the security/cyrus_sasl{,2} (pwcheck.sh, saslauthd{1,}.sh), mail/cyrus_imapd{,2}
(imapd.sh), net/openldap{,2} (slapd.sh) and databases/mysql323-{client,server}
(mysql-client.sh, mysql-server.sh) scripts to RC_NG.

One problem I found with in /etc/rc.subr is that load_rc_config can only get it's
configuration data from /etc/{default/,}rc.conf and /etc/rc.conf.d/*.  While
local rc scripts should also be able to get their configuration data from
${prefix}/etc/rc.conf.d/*.

At a minimum a local rc script would be:

 cat example.sh
#!/bin/sh
#

# PROVIDE: what we provide
# REQUIRE: LOGIN, DAEMON
# BEFORE: [start before service]
# KEYWORD: FreeBSD shutdown
#
# NOTE for FreeBSD 5.0+:
# If you want this script to start with the base rc scripts
# copy example.sh-sample to /etc/rc.d/example, otherwise
# copy example.sh-sample to example.sh.

prefix=%%PREFIX%%

if [ -f /etc/rc.subr ]; then
. /etc/rc.subr

name=example
rcvar`set_rcvar`
command=${prefix}/sbin/${name}
pidfile=/var/run/${name}.pid

load_local_rc_config ${name}
run_rc_command ${name}
else
if [ -f ${prefix}/etc/rc.conf.d/${name} ]; then
. ${prefix}/etc/rc.conf.d/${name}
fi

: old startup script
fi

Attached is a patch to /etc/rc.subr, that provides the load_local_rc_config routine.
Ths routine loads the configuration data in the following order:

${prefix}/etc/rc.conf.d/*
/etc/default/rc.conf
/etc/rc.conf
/etc/rc.conf.d/*

This routine also checks the *_enable variable to see if it has been set, if not
then the routine will set it to YES.  This is only for compatibilty with the old
local scripts. This check could be removed if compatiblity is not necessary.

Scot Hetzel

Index: rc.subr
===
RCS file: /home/ncvs/src/etc/rc.subr,v
retrieving revision 1.6
diff -u -r1.6 rc.subr
--- rc.subr 12 Sep 2002 17:27:36 -  1.6
+++ rc.subr 3 Oct 2002 18:44:50 -
@@ -833,6 +833,45 @@
 }
 
 #
+# load_local_rc_config
+#  Source in the configuration file for a given local command.
+#
+#   The following globals are used:
+#
+#  NameNeeded  Purpose
+#  --  ---
+#  prefix  y   Base directory that script is located in (i.e 
+/usr/local)
+#
+#  rcvar   y   Name of variable used to enable the service. If the 
+enable
+#  variable is unset, then set it to YES.
+#
+load_local_rc_config()
+{
+   _command=$1
+   if [ -z $_command ]; then
+   err 3 USAGE: load_local_rc_config command
+   fi
+
+   if [ -f ${prefix}/etc/rc.conf.d/$_command ]; then
+debug Sourcing ${prefix}/etc/rc.conf.d/${_command}
+. ${prefix}/etc/rc.conf.d/$_command
+fi
+
+   # Let either /etc/rc.conf or /etc/rc.conf.d/$_command
+   # override ${prefix}/etc/rc.conf.d/$_command
+   load_rc_config $_command
+
+   # Used for compatibilty with old behavior of local rc scripts.
+   if [ -n $rcvar ]; then
+   eval _value=\$${rcvar}
+   if [ -z ${_value} ]; then
+   debug load_local_rc_config: setting ${rcvar} to YES
+   eval ${rcvar}=YES
+   fi
+   fi
+}
+
+#
 # rc_usage commands
 #  Print a usage string for $0, with `commands' being a list of
 #  valid commands.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Peter Wemm]

Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], n0go013 writ
es
 :
 On 04.10-15:40, fergus wrote:
  On 04.10-14:20, Poul-Henning Kamp wrote:
  [...]
   I suspect vinum uses this sysctl to get an inventory of disks in
   the system, so can I get you to try again making sure you have
   rev. 1.20 of src/sys/geom/geom_disk.c ?
 [...]
  i'll let you know the test results when i have some.
 
 same results -- can't initialise any drives.  i think the example below
 points more directly to the issue but i'm pretty sure it is because the
 direct read from the disk does not return a valid disklabel.  without a
 'vinum' partition entry vinum spews.
 
 I have no idea how vinum does this or something else, but clearly
 something is not done the right way in vinum...

vinum is so much unbelievable stuff in it.  Consider this stuff:

sys/dev/vinum/vinumio.c:

/* Find the device */
if (bcmp(dname, ad, 2) == 0)  /* IDE disk */
devmajor = 116;
else if (bcmp(dname, wd, 2) == 0) /* IDE disk */
devmajor = 3;
else if (bcmp(dname, da, 2) == 0)
devmajor = 13;
else if (bcmp(dname, vn, 2) == 0)
devmajor = 43;
else if (bcmp(dname, md, 2) == 0)
devmajor = 95;
else if (bcmp(dname, ar, 2) == 0)
devmajor = 157;
else if (bcmp(dname, amrd, 4) == 0) {
devmajor = 133;
dname += 2;
} else if (bcmp(dname, mlxd, 4) == 0) {
devmajor = 131;
dname += 2;
} else if (bcmp(dname, idad, 4) == 0) {
devmajor = 109;
dname += 2;
} else if (bcmp(dname, twed, 4) == 0) {   /* 3ware raid */
  devmajor = 147;
  dname += 2;
} else
  return ENODEV;
dname += 2; /* point past */

It goes *way* downhill from there. :-(

Guess what happens when a new driver is added to the kernel?

Guess what happens if somebody doesn't use the official naming in /dev?

This crud has *got* to be taken out and shot, then reworked to do it
properly.

Oh, and lets not talk about trying to run vinum on partition schemes that
do not even *have* disklabels.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Vote: lib/libexpat - lib/libbsdxml

[Garance A Drosihn]

At 5:56 PM +0300 10/4/02, Ruslan Ermilov wrote:
Hi there!

I'd like to rename src/lib/libexpat to src/lib/libbsdxml.
The reason I think it should be done is the output of the
following command (libpam not being an exception here):

cd src/lib; for dir in lib*; do [ $dir != lib`cd $dir; make -V 
LIB` ]  echo $dir; done

Isn't Poul-Henning already going to do this?
(rename it, I mean)

See the thread
 Ready to connect libbsdxml (nee libexpat) to the build !

(renaming the directory seems like a fine idea to me, but I think
you should check with PHK first, seeing that he is very actively
working there)

-- 
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: Vote: lib/libexpat - lib/libbsdxml

[Poul-Henning Kamp]

In message p0511171ab9c3b45a7bdf@[128.113.24.47], Garance A Drosihn writes:

(renaming the directory seems like a fine idea to me, but I think
you should check with PHK first, seeing that he is very actively
working there)

My initial thought was that leaving the directory called libexpat
was a nice way of paying homage, and if we decide to reverse
the naming decision later it would save us trouble.

That's why I didn't ask for a repo-move/copy.

If the concensus is that the directory should be renamed, I have
no objections to that, I'll just go with the flow.

-- 
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: [ GEOM tests ] disklabel warnings and vinum drives lost

[Emiel Kollof]

* Peter Wemm ([EMAIL PROTECTED]) wrote:

 vinum is so much unbelievable stuff in it.  Consider this stuff:
 
 sys/dev/vinum/vinumio.c:
 

[Big ugly if/else fallthrough snipped]

Ick... Which sick person wrote that? switch() and cpp macros usually do 
wonders in cases like these in terms of readability/maintainability at
least. 

 It goes *way* downhill from there. :-(

And I stay away from vinum just a little longer after having seen and
verified this... 

[snip]

 This crud has *got* to be taken out and shot, then reworked to do it
 properly.

Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but there
are limits to what crud I touch)

Cheers,
Emiel
-- 
When the English language gets in my way, I walk over it.
-- Billy Sunday

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

(forw) CryptoGraphic Disk.

[Emiel Kollof]

Hi folks,

Seems that the NetBSD-current people have a cool new toy. Any chance of 
getting this into FreeBSD CURRENT in the future? See forward.

Cheers,
Emiel

- Forwarded message from Roland Dowdeswell [EMAIL PROTECTED] -

Date: Fri, 04 Oct 2002 15:09:22 -0400
From: Roland Dowdeswell [EMAIL PROTECTED]
Organization: The Fall of Imrryr
User-Agent: nmh-1.0.4 (NetBSD/alpha)
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: CryptoGraphic Disk.

I've just committed cgd, the CryptoGraphic Disk.

The cgd is basically a pseudo-disk which encrypts blocks on their
way to the disk that it is attached to.  Currently it supports 3
crypto algorithms:  aes-cbc, blowfish-cbc and 3des-cbc.  The IV is
chosen by the ``IV generation method'', the only one that is
implemented is ``encblkno'', i.e. encrypted block number.

For more information about how to use and configure cgds please
refer to the provided documentation, cgd(4) and cgdconfig(8).

--
Roland Dowdeswell  http://www.Imrryr.ORG/~elric/

- End forwarded message -

-- 
To be trusted is a greater compliment than to be loved.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: (forw) CryptoGraphic Disk.

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Emiel Kollof writes:
Hi folks,

Seems that the NetBSD-current people have a cool new toy. Any chance of 
getting this into FreeBSD CURRENT in the future? See forward.

We already have much the same in the GEOM_AES module, although the
configuration is not as slick since it was mostly a proof-of-concept
thing for data transformations in GEOM.

On its way to -current is an industry-strength disk-encryption, but
it is not commit ready yet.

-- 
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: (forw) CryptoGraphic Disk.

[Emiel Kollof]

* Poul-Henning Kamp ([EMAIL PROTECTED]) wrote:
 In message [EMAIL PROTECTED], Emiel Kollof writes:
 Seems that the NetBSD-current people have a cool new toy. Any chance of 
 getting this into FreeBSD CURRENT in the future? See forward.
 
 We already have much the same in the GEOM_AES module, although the
 configuration is not as slick since it was mostly a proof-of-concept
 thing for data transformations in GEOM.

Nifty! All configurable from userspace I trust, which is the BSD way of
doing things elegantly :)

 On its way to -current is an industry-strength disk-encryption, but
 it is not commit ready yet.

Ah, that's all right. I'm sure it'll pop up when it's ready. Thanks for
the feedback. Maybe the GEOM people could glean some userspace configuration
details from the NetBSD solution. Having a cgdconfig(1) equivalent tool to 
set such a beast up would be tres cool. 

Keep up the good work anyways. GEOM is pretty cool. 

Cheers,
Emiel
-- 
Surely you can't be serious.
I am serious, and stop calling me Shirley.
-- Airplane

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Terry Lambert]

Emiel Kollof wrote:
 * Peter Wemm ([EMAIL PROTECTED]) wrote:
  vinum is so much unbelievable stuff in it.  Consider this stuff:
 
  sys/dev/vinum/vinumio.c:

[ ... ]

  This crud has *got* to be taken out and shot, then reworked to do it
  properly.
 
 Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but there
 are limits to what crud I touch)


FWIW:

The comment right before that code is:

/*
 * Yes, Bruce, I know this is horrible, but we
 * don't have a root file system when we first
 * try to do this.  If you can come up with a
 * better solution, I'd really like it.  I'm
 * just putting it in now to add ammuntion to
 * moving the system to devfs.
 */

...basically, when devfs became default, the person who made it
default did not maintain this code, when they converted everything
else over to using it.

The assumption here is that the devfs will be available to the
system before the root is mounted transparently over it.  This is
also doable with an unmounted instance of the backing devfs, not
yet mounted on /dev, if a transparent mount of / over top of a
preexiting / - /dev is not supported (i.e. devfs is mounted on
/dev on the root FS, rather than the root FS being mounted on a
backing node on which defvfs is already mounted on /, and the
devices showing through as if they were on /).

I think the major problem with the Vinum code is that it isn't
very readable in an 80 column editor window with 8 column tabs,
but that's pretty much the worst you can say about it, other than
the code has not been maintained by the people changing subsystems
out from under it.

Another alternative is to disable support for mounting vinum
plexes as the root filesystem, which is what this code supposedly
supports.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] vinum drives lost

[Garance A Drosihn]

At 9:02 PM +0200 10/4/02, Poul-Henning Kamp wrote:
There are numerous architectural issues which have never been
fixed in vinum, and one or more of these bits now.

Whoever loves vinum will have to chase it/them down and fix it.

If I receive patches or requests for changes to GEOM as result
of this, they will be evaluated in good faith.

Worst case you will have the option to use:

   options NOGEOM
   options vinum

I know nothing about vinum and only a little about GEOM, so I have
no opinion on which should be fixed to work with the other, and
I'm reluctant to get drawn into that battle anyway.

However, I do think that if it isn't easy to get the two of them to
work together nicely, then we should enforce the above options in
the source code.  Ie, if someone tries to compile a kernel with
both GEOM and vinum turned on, then the compile should fail with
some suitable error message.

-- 
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

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Oct  4 15:17:36 PDT 2002
--
 Kernel build for GENERIC completed on Fri Oct  4 15:48:12 PDT 2002
--
 Kernel build for LINT started on Fri Oct  4 15:48:12 PDT 2002
--
=== vinum
cc1: warnings being treated as errors
/h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach':
/h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant 
conversion
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Peter Wemm]

Terry Lambert wrote:
 Emiel Kollof wrote:
  * Peter Wemm ([EMAIL PROTECTED]) wrote:
   vinum is so much unbelievable stuff in it.  Consider this stuff:
  
   sys/dev/vinum/vinumio.c:
 
 [ ... ]
 
   This crud has *got* to be taken out and shot, then reworked to do it
   properly.
  
  Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but the
re
  are limits to what crud I touch)
 
 
 FWIW:
 
 The comment right before that code is:
 
 /*
  * Yes, Bruce, I know this is horrible, but we
  * don't have a root file system when we first
  * try to do this.  If you can come up with a
  * better solution, I'd really like it.  I'm
  * just putting it in now to add ammuntion to
  * moving the system to devfs.
  */
 
 ...basically, when devfs became default, the person who made it
 default did not maintain this code, when they converted everything
 else over to using it.

 The assumption here is that the devfs will be available to the
 system before the root is mounted transparently over it.

Actually no, this is only used *after* root is mounted.

 This is
 also doable with an unmounted instance of the backing devfs, not
 yet mounted on /dev, if a transparent mount of / over top of a
 preexiting / - /dev is not supported (i.e. devfs is mounted on
 /dev on the root FS, rather than the root FS being mounted on a
 backing node on which defvfs is already mounted on /, and the
 devices showing through as if they were on /).
 
 I think the major problem with the Vinum code is that it isn't
 very readable in an 80 column editor window with 8 column tabs,
 but that's pretty much the worst you can say about it, other than
 the code has not been maintained by the people changing subsystems
 out from under it.
 
 Another alternative is to disable support for mounting vinum
 plexes as the root filesystem, which is what this code supposedly
 supports.

Nope.  Vinum doesn't support booting with a plex as a root file system. I
can't quite say that I understand what this is for though.  namei() etc
are perfectly usable at this point.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Matthew N. Dodd]

On Fri, 4 Oct 2002, Terry Lambert wrote:
 I think the major problem with the Vinum code is that it isn't
 very readable in an 80 column editor window with 8 column tabs,
 but that's pretty much the worst you can say about it, other than
 the code has not been maintained by the people changing subsystems
 out from under it.

This changing APIs out from under WORKING subsystems is something I'd like
to have a ruling on -CORE from.  Calling it bit-rot is how people have
gotten away with stuff like that in the past but it really has to stop.
If your new super nifty kernel code is so wonderful then you can take the
time to not break existing code and to update it properly to your new API.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [ GEOM tests ] disklabel warnings and vinum drives lost

[Long, Scott]

 
 Terry Lambert wrote:
  Emiel Kollof wrote:
   * Peter Wemm ([EMAIL PROTECTED]) wrote:
vinum is so much unbelievable stuff in it.  Consider this stuff:
   
sys/dev/vinum/vinumio.c:
  
  [ ... ]
  
This crud has *got* to be taken out and shot, then 
 reworked to do it
properly.
   
   Amen! (and no, I'm not volunteering. I don't mind 
 cleaning up code, but the
 re
   are limits to what crud I touch)
  
  
  FWIW:
  
  The comment right before that code is:
  
  /*
   * Yes, Bruce, I know this is horrible, but we
   * don't have a root file system when we first
   * try to do this.  If you can come up with a
   * better solution, I'd really like it.  I'm
   * just putting it in now to add ammuntion to
   * moving the system to devfs.
   */
  
  ...basically, when devfs became default, the person who made it
  default did not maintain this code, when they converted everything
  else over to using it.
 
  The assumption here is that the devfs will be available to the
  system before the root is mounted transparently over it.
 
 Actually no, this is only used *after* root is mounted.
 
  This is
  also doable with an unmounted instance of the backing devfs, not
  yet mounted on /dev, if a transparent mount of / over top of a
  preexiting / - /dev is not supported (i.e. devfs is mounted on
  /dev on the root FS, rather than the root FS being mounted on a
  backing node on which defvfs is already mounted on /, and the
  devices showing through as if they were on /).
  
  I think the major problem with the Vinum code is that it isn't
  very readable in an 80 column editor window with 8 column tabs,
  but that's pretty much the worst you can say about it, other than
  the code has not been maintained by the people changing subsystems
  out from under it.
  
  Another alternative is to disable support for mounting vinum
  plexes as the root filesystem, which is what this code supposedly
  supports.
 
 Nope.  Vinum doesn't support booting with a plex as a root 
 file system. I
 can't quite say that I understand what this is for though.  
 namei() etc
 are perfectly usable at this point.
 
 Cheers,
 -Peter

Gee, RAIDframe supports using an array as the root filesystem, and it
didn't need a goofy list like that.  Autoconfiguration works with
any disk subsystem that registers properly with the disk layer (of
course, this is in the non-GEOM world).  shrug  Read the Developer's
Status Report.  Coming soon to a cvs mirror near you.

Scott

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Robert Watson]

On Fri, 4 Oct 2002, Terry Lambert wrote:

 The assumption here is that the devfs will be available to the system
 before the root is mounted transparently over it.  This is also doable
 with an unmounted instance of the backing devfs, not yet mounted on
 /dev, if a transparent mount of / over top of a preexiting / - /dev is
 not supported (i.e. devfs is mounted on /dev on the root FS, rather than
 the root FS being mounted on a backing node on which defvfs is already
 mounted on /, and the devices showing through as if they were on /). 

Actually, no -- Vinum doesn't know how to do that--the device name used in
this code originates in a userland ioctl() configuration call for Vinum. 
However, here's a patch that makes Vinum use namei() to rely on devfs to
locate requested devices instead of parsing the device name and guessing
the device number (incorrectly with GEOM).  Unfortunately, I almost
immediately run into a divide by zero due to a zero sector size.  Jeff
Roberson mentioned to me he had a fix for this bug that he sent to Greg,
but that was never committed.

Index: vinumio.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinumio.c,v
retrieving revision 1.75
diff -u -r1.75 vinumio.c
--- vinumio.c   21 Aug 2002 23:39:51 -  1.75
+++ vinumio.c   5 Oct 2002 00:03:09 -
@@ -50,92 +50,25 @@
 int
 open_drive(struct drive *drive, struct thread *td, int verbose)
 {
-int devmajor;  /* major devs for disk 
device */
-int devminor;  /* minor devs for disk 
device */
-int unit;
-char *dname;
+struct nameidata nd;
 struct cdevsw *dsw;/* pointer to 
cdevsw entry */
+int error;
 
-if (bcmp(drive-devicename, /dev/, 5))   /* device name doesn't 
start with /dev */
-   return ENOENT;  /* give up */
 if (drive-flags  VF_OPEN)/* open already, */
return EBUSY;   /* don't do it again */
 
-/*
- * Yes, Bruce, I know this is horrible, but we
- * don't have a root filesystem when we first
- * try to do this.  If you can come up with a
- * better solution, I'd really like it.  I'm
- * just putting it in now to add ammuntion to
- * moving the system to devfs.
- */
-dname = drive-devicename[5];
-drive-dev = NULL; /* no device yet */
-
-/* Find the device */
-if (bcmp(dname, ad, 2) == 0) /* IDE disk */
-   devmajor = 116;
-else if (bcmp(dname, wd, 2) == 0)/* IDE disk */
-   devmajor = 3;
-else if (bcmp(dname, da, 2) == 0)
-   devmajor = 13;
-else if (bcmp(dname, vn, 2) == 0)
-   devmajor = 43;
-else if (bcmp(dname, md, 2) == 0)
-   devmajor = 95;
-else if (bcmp(dname, ar, 2) == 0)
-devmajor = 157;
-else if (bcmp(dname, amrd, 4) == 0) {
-   devmajor = 133;
-   dname += 2;
-} else if (bcmp(dname, mlxd, 4) == 0) {
-   devmajor = 131;
-   dname += 2;
-} else if (bcmp(dname, idad, 4) == 0) {
-   devmajor = 109;
-   dname += 2;
-} else if (bcmp(dname, twed, 4) == 0) {   /* 3ware raid */
-  devmajor = 147;
-  dname += 2;
-} else
-  return ENODEV;
-dname += 2;/* point past */
-
-/*
- * Found the device.  We can expect one of
- * two formats for the rest: a unit number,
- * then either a partition letter for the
- * compatiblity partition (e.g. h) or a
- * slice ID and partition (e.g. s2e).
- * Create a minor number for each of them.
- */
-unit = 0;
-while ((*dname = '0') /* unit number */
-(*dname = '9')) {
-   unit = unit * 10 + *dname - '0';
-   dname++;
+NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, drive-devicename,
+curthread);
+error = namei(nd);
+if (error)
+   return (error);
+if (!vn_isdisk(nd.ni_vp, error)) {
+   NDFREE(nd, 0);
+   return (error);
 }
+drive-dev = udev2dev(nd.ni_vp-v_rdev-si_udev, 0);
+NDFREE(nd, 0);
 
-if (*dname == 's') {   /* slice */
-   if (((dname[1]  '1') || (dname[1]  '4'))  /* invalid slice */
-   ||((dname[2]  'a') || (dname[2]  'h')))   /* or invalid partition */
-   return ENODEV;
-   devminor = ((unit  31)  3)   /* unit */
-   +(dname[2] - 'a')   /* partition */
-   +((dname[1] - '0' + 1)  16)   /* slice */
-   +((unit  ~31)  16);  /* high-order unit bits */
-} else {   /* 

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Greg 'groggy' Lehey]

On Friday,  4 October 2002 at 14:11:57 -0700, Peter Wemm wrote:
 Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], n0go013 writ
 es
 :
 On 04.10-15:40, fergus wrote:
 On 04.10-14:20, Poul-Henning Kamp wrote:
 [...]
 I suspect vinum uses this sysctl to get an inventory of disks in
 the system, so can I get you to try again making sure you have
 rev. 1.20 of src/sys/geom/geom_disk.c ?
 [...]
 i'll let you know the test results when i have some.

 same results -- can't initialise any drives.  i think the example below
 points more directly to the issue but i'm pretty sure it is because the
 direct read from the disk does not return a valid disklabel.  without a
 'vinum' partition entry vinum spews.

 I have no idea how vinum does this or something else, but clearly
 something is not done the right way in vinum...

 vinum is so much unbelievable stuff in it.  Consider this stuff:

 sys/dev/vinum/vinumio.c:

 /* Find the device */
 if (bcmp(dname, ad, 2) == 0)  /* IDE disk */
 devmajor = 116;

You missed the lines in front:

/*
 * Yes, Bruce, I know this is horrible, but we
 * don't have a root filesystem when we first
 * try to do this.  If you can come up with a
 * better solution, I'd really like it.  I'm
 * just putting it in now to add ammuntion to
 * moving the system to devfs.
 */

 It goes *way* downhill from there. :-(

Really?  I thought that was the worst of the lot.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Greg 'groggy' Lehey]

On Friday,  4 October 2002 at 16:03:24 -0700, Peter Wemm wrote:
 Terry Lambert wrote:
 Emiel Kollof wrote:
 * Peter Wemm ([EMAIL PROTECTED]) wrote:
 vinum is so much unbelievable stuff in it.  Consider this stuff:

 sys/dev/vinum/vinumio.c:

 [ ... ]

 This crud has *got* to be taken out and shot, then reworked to do it
 properly.

 Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but the
 re
 are limits to what crud I touch)


 FWIW:

 The comment right before that code is:

 /*
  * Yes, Bruce, I know this is horrible, but we
  * don't have a root file system when we first
  * try to do this.  If you can come up with a
  * better solution, I'd really like it.  I'm
  * just putting it in now to add ammuntion to
  * moving the system to devfs.
  */

 ...basically, when devfs became default, the person who made it
 default did not maintain this code, when they converted everything
 else over to using it.

 The assumption here is that the devfs will be available to the
 system before the root is mounted transparently over it.

 Actually no, this is only used *after* root is mounted.

Now.  Vinum supported the root file system years ago, but there were
objections to the code.  This was a temporary hack which was supposed
to go away quickly, but then there was some pressure for me to give up
maintainership, so I did, and Vinum has had very little maintenance
since.

 Another alternative is to disable support for mounting vinum plexes
 as the root filesystem, which is what this code supposedly
 supports.

 Nope.  Vinum doesn't support booting with a plex as a root file
 system. I can't quite say that I understand what this is for though.
 namei() etc are perfectly usable at this point.

It did.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

ACPI errors and then panic

[Nate Lawson]

My laptop appears to work ok without ACPI but of course I don't get
suspend, resume, etc.  I have never been able to get ACPI to work with it,
including with a -current as of 2 hours ago.  If ACPI is enabled, I get a
spew of:

ACPI-0412 *** Error: NsSearchAndEnter: Bad character in ACPI name

and then a panic from acpi_attach.

Here are the appropriate files...
  http://www.root.org/~nate/acpi/ibm.aml
  http://www.root.org/~nate/acpi/ibm.dsdt
  http://www.root.org/~nate/acpi/ibm.dmesg  (from a working boot)

Let me know if you need more info.

-Nate



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Robert Watson]

On Fri, 4 Oct 2002, Robert Watson wrote:

 On Fri, 4 Oct 2002, Terry Lambert wrote:
 
  The assumption here is that the devfs will be available to the system
  before the root is mounted transparently over it.  This is also doable
  with an unmounted instance of the backing devfs, not yet mounted on
  /dev, if a transparent mount of / over top of a preexiting / - /dev is
  not supported (i.e. devfs is mounted on /dev on the root FS, rather than
  the root FS being mounted on a backing node on which defvfs is already
  mounted on /, and the devices showing through as if they were on /). 
 
 Actually, no -- Vinum doesn't know how to do that--the device name used
 in this code originates in a userland ioctl() configuration call for
 Vinum. However, here's a patch that makes Vinum use namei() to rely on
 devfs to locate requested devices instead of parsing the device name and
 guessing the device number (incorrectly with GEOM).  Unfortunately, I
 almost immediately run into a divide by zero due to a zero sector size. 
 Jeff Roberson mentioned to me he had a fix for this bug that he sent to
 Greg, but that was never committed. 

On the general topic of access to devices before a root has been found,
Maxime Henrion [EMAIL PROTECTED] has done some interesting work on
'rootfs', a pseudofs used to bootstrap support for devfs, etc.  In such an
environment, Vinum and other consumers of devices would be able to rely on
devfs access prior to the real root mount process.  I'm not sure which
pivotroot-like trick he's using, or whether he's doing the union thing to
do the root re-mount.  Presumably he has to be careful not to deadfs the
devfs nodes in place before the real root turns up, etc. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Greg 'groggy' Lehey]

On Friday,  4 October 2002 at 20:07:11 -0400, Robert Watson wrote:

 On Fri, 4 Oct 2002, Terry Lambert wrote:

 The assumption here is that the devfs will be available to the system
 before the root is mounted transparently over it.  This is also doable
 with an unmounted instance of the backing devfs, not yet mounted on
 /dev, if a transparent mount of / over top of a preexiting / - /dev is
 not supported (i.e. devfs is mounted on /dev on the root FS, rather than
 the root FS being mounted on a backing node on which defvfs is already
 mounted on /, and the devices showing through as if they were on /).

 Actually, no -- Vinum doesn't know how to do that--the device name used in
 this code originates in a userland ioctl() configuration call for Vinum.
 However, here's a patch that makes Vinum use namei() to rely on devfs to
 locate requested devices instead of parsing the device name and guessing
 the device number (incorrectly with GEOM).  Unfortunately, I almost
 immediately run into a divide by zero due to a zero sector size.  Jeff
 Roberson mentioned to me he had a fix for this bug that he sent to Greg,
 but that was never committed.

FWIW, I've never seen this code.  The dates on the patch suggest that
it was made in the last quarter of an hour:

 --- vinumio.c 21 Aug 2002 23:39:51 -  1.75
 +++ vinumio.c 5 Oct 2002 00:03:09 -

However:

  RCS file: /home/ncvs/src/sys/modules/vinum/Makefile,v
  revision 1.18
  date: 2000/04/16 00:17:46;  author: grog;  state: Exp;  lines: +1 -3
  Remove MAINTAINER.

Since that point, this particular file has had 5 updates, only one
from me.  Jeff's a committer; he can commit it himself if he wants.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Peter Wemm]

Greg 'groggy' Lehey wrote:
 On Friday,  4 October 2002 at 16:03:24 -0700, Peter Wemm wrote:
  Terry Lambert wrote:
  Emiel Kollof wrote:
  * Peter Wemm ([EMAIL PROTECTED]) wrote:
  vinum is so much unbelievable stuff in it.  Consider this stuff:
 
  sys/dev/vinum/vinumio.c:
 
  [ ... ]
 
  This crud has *got* to be taken out and shot, then reworked to do it
  properly.
 
  Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but t
he
  re
  are limits to what crud I touch)
 
 
  FWIW:
 
  The comment right before that code is:
 
  /*
   * Yes, Bruce, I know this is horrible, but we
   * don't have a root file system when we first
   * try to do this.  If you can come up with a
   * better solution, I'd really like it.  I'm
   * just putting it in now to add ammuntion to
   * moving the system to devfs.
   */
 
  ...basically, when devfs became default, the person who made it
  default did not maintain this code, when they converted everything
  else over to using it.
 
  The assumption here is that the devfs will be available to the
  system before the root is mounted transparently over it.
 
  Actually no, this is only used *after* root is mounted.
 
 Now.  Vinum supported the root file system years ago, but there were
 objections to the code.  This was a temporary hack which was supposed
 to go away quickly, but then there was some pressure for me to give up
 maintainership, so I did, and Vinum has had very little maintenance
 since.

I had a look around and couldn't find any real traces of it in the
cvs history.  I recall a patch being posted somewhere but do not remember
it being committed for some reason (bootblock issues?).

  Another alternative is to disable support for mounting vinum plexes
  as the root filesystem, which is what this code supposedly
  supports.
 
  Nope.  Vinum doesn't support booting with a plex as a root file
  system. I can't quite say that I understand what this is for though.
  namei() etc are perfectly usable at this point.
 
 It did.

.. but not committed to FreeBSD as far as I can tell.


Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Greg 'groggy' Lehey]

On Friday,  4 October 2002 at 20:21:29 -0400, Robert Watson wrote:

 On Fri, 4 Oct 2002, Robert Watson wrote:

 On Fri, 4 Oct 2002, Terry Lambert wrote:

 The assumption here is that the devfs will be available to the system
 before the root is mounted transparently over it.  This is also doable
 with an unmounted instance of the backing devfs, not yet mounted on
 /dev, if a transparent mount of / over top of a preexiting / - /dev is
 not supported (i.e. devfs is mounted on /dev on the root FS, rather than
 the root FS being mounted on a backing node on which defvfs is already
 mounted on /, and the devices showing through as if they were on /).

 Actually, no -- Vinum doesn't know how to do that--the device name used
 in this code originates in a userland ioctl() configuration call for
 Vinum. However, here's a patch that makes Vinum use namei() to rely on
 devfs to locate requested devices instead of parsing the device name and
 guessing the device number (incorrectly with GEOM).  Unfortunately, I
 almost immediately run into a divide by zero due to a zero sector size.
 Jeff Roberson mentioned to me he had a fix for this bug that he sent to
 Greg, but that was never committed.

 On the general topic of access to devices before a root has been found,
 Maxime Henrion [EMAIL PROTECTED] has done some interesting work on
 'rootfs', a pseudofs used to bootstrap support for devfs, etc.  In such an
 environment, Vinum and other consumers of devices would be able to rely on
 devfs access prior to the real root mount process.  I'm not sure which
 pivotroot-like trick he's using, or whether he's doing the union thing to
 do the root re-mount.  Presumably he has to be careful not to deadfs the
 devfs nodes in place before the real root turns up, etc.

As I say, it was working in early 2000.  Some details needed changing,
and the work never got finished, but it wasn't very much work.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Robert Watson]

On Sat, 5 Oct 2002, Greg 'groggy' Lehey wrote:

 FWIW, I've never seen this code.  The dates on the patch suggest that
 it was made in the last quarter of an hour:

I didn't claim that this was his code.  This was code I just wrote to
address Vinum not finding the devices due to major/minor number changes.

I was referring to a separate problem involving a zero'd sectorsize
resulting in a divide by zero in the kernel, which Jeff reported
experiencing and fixing previously.

  --- vinumio.c   21 Aug 2002 23:39:51 -  1.75
  +++ vinumio.c   5 Oct 2002 00:03:09 -
 
 However:
 
   RCS file: /home/ncvs/src/sys/modules/vinum/Makefile,v
   revision 1.18
   date: 2000/04/16 00:17:46;  author: grog;  state: Exp;  lines: +1 -3
   Remove MAINTAINER.
 
 Since that point, this particular file has had 5 updates, only one from
 me.  Jeff's a committer; he can commit it himself if he wants. 

Hmm.  Funny, I was paying more attention to the line in the MAINTAINER's
file which seems to suggest you are the maintainer.  :-)

Given that you appear to have read this patch -- may I commit it since it
appears to resolve the first of the nits I ran into using Vinum with GEOM? 
There appear to be more problems in the tubes, but this one seemed
straight-forward enough, especially since the functionality this patch
replaces seems not to be in the tree. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: PCI problems with today's current

[Kenneth D. Merry]

On Fri, Oct 04, 2002 at 16:03:08 -0400, John Baldwin wrote:
 
 On 03-Oct-2002 Kenneth D. Merry wrote:
  
  I have a Supermicro P3TDE6 motherboard (Serverworks HE-SL chipset) that
  won't boot with today's -current.
  
  -current from August 23rd sources boots fine.
  
  It looks like the PCI bus probe is failing somehow.
  
  I've seen other folks complaining about PCI problems, and I suppose this is
  related, but I don't think I've seen quite the same failure reported.
  
  I've attached dmesg output from the working kernel (August 23rd sources)
  and the broken kernel (sources from ~1500 MDT today).
  
  Any ideas on how to fix this?
 
 Turn off ACPI for now (set hint.acpi.0.disabled=1).  Iwasaki-san has a fix
 for this that I guess he should commit.

With the older loader I'm using with the newer kernel (until I do an
installworld), it was acpi_load=NO.

That did the trick, thanks!

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Julian Elischer]

On Fri, 4 Oct 2002, Robert Watson wrote:

 On the general topic of access to devices before a root has been found,
 Maxime Henrion [EMAIL PROTECTED] has done some interesting work on
 'rootfs', a pseudofs used to bootstrap support for devfs, etc.  In such an
 environment, Vinum and other consumers of devices would be able to rely on
 devfs access prior to the real root mount process.  I'm not sure which
 pivotroot-like trick he's using, or whether he's doing the union thing to
 do the root re-mount.  Presumably he has to be careful not to deadfs the
 devfs nodes in place before the real root turns up, etc. 

The original devfs supported access from within the kernel before
mounting root and devfs..
It's not rocket science.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Greg 'groggy' Lehey]

On Friday,  4 October 2002 at 20:29:51 -0400, Robert Watson wrote:

 On Sat, 5 Oct 2002, Greg 'groggy' Lehey wrote:

 FWIW, I've never seen this code.  The dates on the patch suggest that
 it was made in the last quarter of an hour:

 I didn't claim that this was his code.  This was code I just wrote to
 address Vinum not finding the devices due to major/minor number
 changes.

Ah, then I misunderstood.  Sorry.

 I was referring to a separate problem involving a zero'd sectorsize
 resulting in a divide by zero in the kernel, which Jeff reported
 experiencing and fixing previously.

Ah, yes, I recall seeing that one, I think.

 --- vinumio.c   21 Aug 2002 23:39:51 -  1.75
 +++ vinumio.c   5 Oct 2002 00:03:09 -

 However:

   RCS file: /home/ncvs/src/sys/modules/vinum/Makefile,v
   revision 1.18
   date: 2000/04/16 00:17:46;  author: grog;  state: Exp;  lines: +1 -3
   Remove MAINTAINER.

 Since that point, this particular file has had 5 updates, only one from
 me.  Jeff's a committer; he can commit it himself if he wants.

 Hmm.  Funny, I was paying more attention to the line in the MAINTAINER's
 file which seems to suggest you are the maintainer.  :-)

No, I just suggest that people bounce things off me before committing:

vinum   grogRecommends pre-commit review.

 Given that you appear to have read this patch -- may I commit it
 since it appears to resolve the first of the nits I ran into using
 Vinum with GEOM?

Sure, you don't need my permission.  But let me look at it more
carefully.  As I said, I have a number of changes which also get rid
of this mess, and which were never committed.  Let me take a look and
get back to you.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: ACPI errors and then panic

[Mitsuru IWASAKI]

Hi,
# ACPI CA related problem should be sent to [EMAIL PROTECTED]
# so that Intel folks can be aware of the problem.

From: Nate Lawson [EMAIL PROTECTED]
Subject: ACPI errors and then panic
Date: Fri, 4 Oct 2002 17:14:31 -0700 (PDT)
Message-ID: [EMAIL PROTECTED]

 My laptop appears to work ok without ACPI but of course I don't get
 suspend, resume, etc.  I have never been able to get ACPI to work with it,
 including with a -current as of 2 hours ago.  If ACPI is enabled, I get a
 spew of:
 
 ACPI-0412 *** Error: NsSearchAndEnter: Bad character in ACPI name
 
 and then a panic from acpi_attach.

First several lines of DDB backtrace would be very helpful
to track the problem down.
Also having following lines in your loader.conf would be
helpful to determine which object causes the ACPI CA Eroor.

debug.acpi.layer=ACPI_ALL_COMPONENTS ACPI_BUS
debug.acpi.level=ACPI_LV_WARN ACPI_LV_ERROR ACPI_LV_OBJECTS

BTW, what's model name?  Some ThinkPad's are blacklisted such as
IBM 600E.  And may I add your ACPI data to our repo. (in Japan) ?

 Here are the appropriate files...
   http://www.root.org/~nate/acpi/ibm.aml
   http://www.root.org/~nate/acpi/ibm.dsdt
   http://www.root.org/~nate/acpi/ibm.dmesg  (from a working boot)
 
 Let me know if you need more info.
 
 -Nate
 
 
 
 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: [ GEOM tests ] disklabel warnings and vinum drives lost

[Juli Mallett]

* De: Julian Elischer [EMAIL PROTECTED] [ Data: 2002-10-04 ]
[ Subjecte: Re: [ GEOM tests ] disklabel warnings and vinum drives lost ]
 
 
 On Fri, 4 Oct 2002, Robert Watson wrote:
 
  On the general topic of access to devices before a root has been found,
  Maxime Henrion [EMAIL PROTECTED] has done some interesting work on
  'rootfs', a pseudofs used to bootstrap support for devfs, etc.  In such an
  environment, Vinum and other consumers of devices would be able to rely on
  devfs access prior to the real root mount process.  I'm not sure which
  pivotroot-like trick he's using, or whether he's doing the union thing to
  do the root re-mount.  Presumably he has to be careful not to deadfs the
  devfs nodes in place before the real root turns up, etc. 
 
 The original devfs supported access from within the kernel before
 mounting root and devfs..
 It's not rocket science.

A rootfs has many other ideal uses.  Like spinning bits of the kernel off
to userland, and having procfs exist, too.
-- 
Juli Mallett [EMAIL PROTECTED]   | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/  | Support my FreeBSD hacking!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: PCI problems with today's current

[Kenneth D. Merry]

On Fri, Oct 04, 2002 at 18:39:08 -0600, Kenneth D. Merry wrote:
 On Fri, Oct 04, 2002 at 16:03:08 -0400, John Baldwin wrote:
  
  On 03-Oct-2002 Kenneth D. Merry wrote:
   
   I have a Supermicro P3TDE6 motherboard (Serverworks HE-SL chipset) that
   won't boot with today's -current.
   
   -current from August 23rd sources boots fine.
   
   It looks like the PCI bus probe is failing somehow.
   
   I've seen other folks complaining about PCI problems, and I suppose this is
   related, but I don't think I've seen quite the same failure reported.
   
   I've attached dmesg output from the working kernel (August 23rd sources)
   and the broken kernel (sources from ~1500 MDT today).
   
   Any ideas on how to fix this?
  
  Turn off ACPI for now (set hint.acpi.0.disabled=1).  Iwasaki-san has a fix
  for this that I guess he should commit.
 
 With the older loader I'm using with the newer kernel (until I do an
 installworld), it was acpi_load=NO.

Oops, actually it was 'set hint.acpi.0.disable=1' that fixed it.  Setting
acpi_load=NO doesn't seem to do anything.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: HEADSUP! GEOM as default in 5 days...

[Eric Hodel]

Poul-Henning Kamp ([EMAIL PROTECTED]) wrote:

 In message [EMAIL PROTECTED], Eric Hodel writes:
 
 the bit that I cant figure out is that my CD-ROM won't mount the
 CD I've got in it now, (an 80 minute CDR) but it has pre-geom.
 
 Yes, there is a problem with SCSI-CD devices.
 
 Can you please try this patch:
   http://phk.freebsd.dk/patch/scsi_cd.c.patch

That patch does not work, sources from Oct 3


-- 
Eric Hodel - [EMAIL PROTECTED] - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04




msg43987/pgp0.pgp
Description: PGP signature

Re: [ GEOM tests ] disklabel warnings and vinum drives lost

[Ian Dowse]

In message [EMAIL PROTECTED], Robe
rt Watson writes:
However, here's a patch that makes Vinum use namei() to rely on devfs to
locate requested devices instead of parsing the device name and guessing
the device number (incorrectly with GEOM).  Unfortunately, I almost
immediately run into a divide by zero due to a zero sector size.  Jeff
Roberson mentioned to me he had a fix for this bug that he sent to Greg,
but that was never committed.

The divide by zero problem seems to be caused by an interaction
between two bugs: GEOM refuses to return the sector size because
the flags passed to d_open in vinum's open_drive() do not include
FREAD. Then vinum clobbers the ioctl's non-zero error code by calling
close_drive() from init_drive(), so the latter ends up returning
zero even though it failed.

The next failure I get is:

Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)

Ian

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: PCI problems with today's current

[Kenneth D. Merry]

On Fri, Oct 04, 2002 at 16:03:08 -0400, John Baldwin wrote:
 
 On 03-Oct-2002 Kenneth D. Merry wrote:
  
  I have a Supermicro P3TDE6 motherboard (Serverworks HE-SL chipset) that
  won't boot with today's -current.
  
  -current from August 23rd sources boots fine.
  
  It looks like the PCI bus probe is failing somehow.
  
  I've seen other folks complaining about PCI problems, and I suppose this is
  related, but I don't think I've seen quite the same failure reported.
  
  I've attached dmesg output from the working kernel (August 23rd sources)
  and the broken kernel (sources from ~1500 MDT today).
  
  Any ideas on how to fix this?
 
 Turn off ACPI for now (set hint.acpi.0.disabled=1).  Iwasaki-san has a fix
 for this that I guess he should commit.

The new ACPI drop that went in today partially fixes my problem.  The PCI
bus with my SCSI and network controllers on it is now probed, so I can
boot.

The PCI bus with my gigabit ethernet board isn't probed, though, with ACPI
turned on.  It is with ACPI turned off.

I've attached dmesg output with and without ACPI turned on.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]


Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Fri Oct  4 20:03:56 MDT 2002

[EMAIL PROTECTED]:/usr/home/ken/perforce/FreeBSD-ken/src/sys/i386/compile/gondolin
Preloaded elf kernel /boot/kernel/kernel at 0xc0568000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc05680a8.
Timecounter i8254  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (1266.07-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6b1  Stepping = 1
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 2684289024 (2621376K bytes)
avail memory = 2602598400 (2541600K bytes)
Programming 16 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
Programming 16 pins in IOAPIC #1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  4, version: 0x000f0011, at 0xfec0
 io1 (APIC): apic id:  5, version: 0x000f0011, at 0xfec01000
Pentium Pro MTRR support enabled
ACPI-0623: *** Warning: Type override - [DEB_] had invalid type (Integer) for 
Scope operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [MLIB] had invalid type (Integer) for 
Scope operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [IO__] had invalid type (Integer) for 
Scope operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [DATA] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [SIO_] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [SB__] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [PM__] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [ICNT] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [ACPI] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [OSB4] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [PM__] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [BIOS] had invalid type (Integer) for 
Scope operator, changed to (Scope)
ACPI-0623: *** Warning: Type override - [CMOS] had invalid type (Integer) for 
Scope operator, changed to (Scope)
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: RCCRCCNILE  on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-safe  frequency 3579545 Hz
Using $PIR table, 10 entries at 0xc00f52e0
acpi_timer0: 32-bit timer at 3.579545MHz port 0x508-0x50b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_cpu2: CPU on acpi0
acpi_cpu3: CPU on acpi0
acpi_button0: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
IOAPIC #1 intpin 10 - irq 2
IOAPIC #1 intpin 11 - irq 5
IOAPIC #1 intpin 15 - irq 9
pcib1: ACPI PCI-PCI bridge at device 0.1 on pci0
pci1: ACPI PCI bus on pcib1
IOAPIC #1 intpin 14 - irq 11
pci1: display, VGA at device 0.0 (no driver attached)
ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 
0xfeafc000-0xfeafcfff irq 2 at device 5.0 on pci0
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem 
0xfeaff000-0xfeaf irq 5 at device 5.1 on pci0
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 

Re: PCI problems with today's current

[Mitsuru IWASAKI]

Hi,

From: John Baldwin [EMAIL PROTECTED]
Subject: RE: PCI problems with today's current
Date: Fri, 04 Oct 2002 16:03:08 -0400 (EDT)
Message-ID: [EMAIL PROTECTED]

 On 03-Oct-2002 Kenneth D. Merry wrote:
  
  I have a Supermicro P3TDE6 motherboard (Serverworks HE-SL chipset) that
  won't boot with today's -current.
  
  -current from August 23rd sources boots fine.
  
  It looks like the PCI bus probe is failing somehow.
  
  I've seen other folks complaining about PCI problems, and I suppose this is
  related, but I don't think I've seen quite the same failure reported.
  
  I've attached dmesg output from the working kernel (August 23rd sources)
  and the broken kernel (sources from ~1500 MDT today).
  
  Any ideas on how to fix this?
 
 Turn off ACPI for now (set hint.acpi.0.disabled=1).  Iwasaki-san has a fix
 for this that I guess he should commit.

OK, just committed.  Also imported the latest version of ACPI CA.

Ken, if your problem still remains with acpi enabled, I'll report this
to Intel folks.  So, please let me know the result.

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: PCI problems with today's current

[Kenneth D. Merry]

On Sat, Oct 05, 2002 at 11:22:58 +0900, Mitsuru IWASAKI wrote:
 Hi,
 
 From: John Baldwin [EMAIL PROTECTED]
 Subject: RE: PCI problems with today's current
 Date: Fri, 04 Oct 2002 16:03:08 -0400 (EDT)
 Message-ID: [EMAIL PROTECTED]
 
  On 03-Oct-2002 Kenneth D. Merry wrote:
   
   I have a Supermicro P3TDE6 motherboard (Serverworks HE-SL chipset) that
   won't boot with today's -current.
   
   -current from August 23rd sources boots fine.
   
   It looks like the PCI bus probe is failing somehow.
   
   I've seen other folks complaining about PCI problems, and I suppose this is
   related, but I don't think I've seen quite the same failure reported.
   
   I've attached dmesg output from the working kernel (August 23rd sources)
   and the broken kernel (sources from ~1500 MDT today).
   
   Any ideas on how to fix this?
  
  Turn off ACPI for now (set hint.acpi.0.disabled=1).  Iwasaki-san has a fix
  for this that I guess he should commit.
 
 OK, just committed.  Also imported the latest version of ACPI CA.
 
 Ken, if your problem still remains with acpi enabled, I'll report this
 to Intel folks.  So, please let me know the result.

Looks like your mail crossed mine on the wire. :)

I'm having trouble with the latest ACPI drop still, but I don't have the
patches you just checked in.

Will the patches you just checked in possibly fix the problem?  If so, I'll
cvsup and try them out.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: signal 6 to XFree86 (Re: cvs commit: src/tools/tools...)

[Kris Kennaway]

On Fri, Oct 04, 2002 at 06:30:09PM -0700, Lars Eggert wrote:
 Wesley Morgan wrote:
 I had one today, they have decreased significantly since removing the
 Type1 module from my server configuration.
 
 I've also found that disabling xscreensaver/xlockmore helps - or just 
 set it to blank screen only. (Some of those graphical modules use 
 beziers.)

My XFree86 crashes pretty much every time I turn my back on my PC for
a few minutes and let xscreensaver kick in.

Kris




msg43992/pgp0.pgp
Description: PGP signature