install -d -C (was: Re: cvs commit: src/share/man/man5 make.conf.5 src/share/examples/etc make.conf)

2002-07-19 Thread Ruslan Ermilov

On Fri, Jul 19, 2002 at 09:28:09PM +1000, Bruce Evans wrote:
 On Thu, 18 Jul 2002, Ruslan Ermilov wrote:
 
  ru  2002/07/18 05:54:56 PDT
 
Modified files:
  share/man/man5   make.conf.5
  share/examples/etc   make.conf
Log:
To force install(1) to always compare files before installing, one
now needs to set COPY=-C as -C is no longer compatible with the -d
option.  It is also likely to be renamed to INSTALL_COPY soon.
Update documentation to reflect this change.
 
PR: bin/40724
 
 The bug is that -C is no longer compatible with -d.  See also misc/40414.
 
This PR is already closed.

On Fri, Jul 19, 2002 at 09:21:14PM +1000, Bruce Evans wrote:
 On Thu, 18 Jul 2002, Ruslan Ermilov wrote:
 
  ru  2002/07/18 05:07:49 PDT
 
Modified files:
  etc  Makefile
[...]
  usr.sbin/ypserv  Makefile
Log:
s/${INSTALL} -c/${INSTALL} ${COPY}/
 
 Strongly unapproved by: bde.
 
 This change is to help work around the foot-shooting of making -d
 incompatible with -C and -p in install(1)'s flags.  It abuses the old
 poorly named COPY variable which had become a no-op.  Now COPY is still
 poorly named but has different semantics.  All this is like breaking
 cc to reject combinations of flags that don't really go together (e.g.,
 -I doesn't go with linking) instead of just ignoring the flags that
 don't apply to the current operation, and then working around this
 foot-shooting by splitting up CFLAGS and changing many Makefiles to
 only use the part of CFLAGS that is relevant.
 
Since its first revision (install.1,v 1.7 and install.c,v 1.16 they
were incompatible).  Later on, in rev. 1.26, it was made a no-op,
just to support INSTALL=install -C in /etc/make.conf.

OpenBSD merged these changes and since then they still have them
incompatible.

There are two ways to proceed:

1.  Rename COPY to INSTALL_COPY (that was my plan), optionally giving
it by default an empty value.  This shouldn't harm third-party
makefiles as -c is now an effective no-op.  But this would make
us even more compatible with OpenBSD that has:

: INSTALL_COPYThe old usage of this flag is obsolescent since install(1)
: now copies by default.  However, it can also be used to
: specify that a file not be copied unless it is different
: (via the -p option).  See install(1) for details.  This
: is to be used when building our own install script so
: that the entire system can either be installed with copies,
: or copy-if-different using a single knob. [-c]

2.  Make again -C an allowed (ignored) option in the -d case.  This would
make us again incompatible with OpenBSD.

I do not have a technical problem doing either, I'd just like to know
what do others think about this.


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



msg41224/pgp0.pgp
Description: PGP signature


Re: install -d -C (was: Re: cvs commit: src/share/man/man5 make.conf.5 src/share/examples/etc make.conf)

2002-07-19 Thread Ruslan Ermilov

On Fri, Jul 19, 2002 at 03:05:37PM +0300, Ruslan Ermilov wrote:
 On Fri, Jul 19, 2002 at 09:28:09PM +1000, Bruce Evans wrote:
  On Thu, 18 Jul 2002, Ruslan Ermilov wrote:
  
   ru  2002/07/18 05:54:56 PDT
  
 Modified files:
   share/man/man5   make.conf.5
   share/examples/etc   make.conf
 Log:
 To force install(1) to always compare files before installing, one
 now needs to set COPY=-C as -C is no longer compatible with the -d
 option.  It is also likely to be renamed to INSTALL_COPY soon.
 Update documentation to reflect this change.
  
 PR: bin/40724
  
  The bug is that -C is no longer compatible with -d.  See also misc/40414.
  
 This PR is already closed.
 
 On Fri, Jul 19, 2002 at 09:21:14PM +1000, Bruce Evans wrote:
  On Thu, 18 Jul 2002, Ruslan Ermilov wrote:
  
   ru  2002/07/18 05:07:49 PDT
  
 Modified files:
   etc  Makefile
 [...]
   usr.sbin/ypserv  Makefile
 Log:
 s/${INSTALL} -c/${INSTALL} ${COPY}/
  
  Strongly unapproved by: bde.
  
  This change is to help work around the foot-shooting of making -d
  incompatible with -C and -p in install(1)'s flags.  It abuses the old
  poorly named COPY variable which had become a no-op.  Now COPY is still
  poorly named but has different semantics.  All this is like breaking
  cc to reject combinations of flags that don't really go together (e.g.,
  -I doesn't go with linking) instead of just ignoring the flags that
  don't apply to the current operation, and then working around this
  foot-shooting by splitting up CFLAGS and changing many Makefiles to
  only use the part of CFLAGS that is relevant.
  
 Since its first revision (install.1,v 1.7 and install.c,v 1.16 they
 were incompatible).  Later on, in rev. 1.26, it was made a no-op,
 just to support INSTALL=install -C in /etc/make.conf.
 
 OpenBSD merged these changes and since then they still have them
 incompatible.
 
 There are two ways to proceed:
 
 1.  Rename COPY to INSTALL_COPY (that was my plan), optionally giving
 it by default an empty value.  This shouldn't harm third-party
 makefiles as -c is now an effective no-op.  But this would make
 us even more compatible with OpenBSD that has:
 
 : INSTALL_COPYThe old usage of this flag is obsolescent since install(1)
 : now copies by default.  However, it can also be used to
 : specify that a file not be copied unless it is different
 : (via the -p option).  See install(1) for details.  This
 : is to be used when building our own install script so
 : that the entire system can either be installed with copies,
 : or copy-if-different using a single knob. [-c]
 
OTOH, if we go this way we can get rid of ugly ${COPY} completely.

 2.  Make again -C an allowed (ignored) option in the -d case.  This would
 make us again incompatible with OpenBSD.
 
 I do not have a technical problem doing either, I'd just like to know
 what do others think about this.

I'm not sure what's the better way, please help me out.  :-)


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



msg41225/pgp0.pgp
Description: PGP signature


(Sort of) Solved Re: Current (DP1) on Toshiba 5005

2002-07-19 Thread Rob Hughes

On Tue, 2002-07-16 at 15:04, Anthony Jenkins wrote:
 Rob Hughes wrote:
 
 All,
 
 I have a Toshiba 5005-S504 laptop (a wonderful legacy-free box that's
 I've cussed to no end) that I'm trying to get DP1 to boot on so I can
 cvsup and take a look (and hopefully contribute something). I was able
 to install, but after installation the system soft hangs after
 displaying a message about CPU power states (sorry, going off memory for
 now). I'm able to break to the debugger, so what information from dbg
 would be helpful at this point? Also, I'm pretty sure it's acpi that's
 causing the problem, so would someone point me to the syntax for
 disabling a module preload?
 
 Thanks,
 Rob
 
   
 
 I was tracking down a similar hang and had to disable acpi (turns out 
 I'm an idiot and the apparent hang at boot was because I forgot console 
 was redirected to the serial port of the machine next to it), but I had 
 to jump through hoops to do it it seems.  I believe all you have to do 
 is 'unset acpi_load' at the boot loader prompt.  I had tried 'set 
 acpi_load=NO', and finally 'unset module_path' to keep the kernel from 
 finding /boot/kernel/acpi.ko.
 
 Hope this helps,
 Anthony Jenkins
 
 

After the last couple of days of cvsup's, the system now boots and runs.
I haven't tested much on it yet, as I just got a working kernel config,
based on OLDCARD, late last night. I've attached the output of dmesg for
anyone interested. Some things to note, this system doesn't have a
floppy installed, but uses a usb floppy, has an integrated modem, irda,
bluetooth, and firewire ports, an nvidia geforce 2 go, and is intel
815-based with a regular p3 chip, not the mobile version. Also, again,
it's a legacy-free model, so no serial, game, or parallel ports, just
lots of usb ports.

Also, in sysconfig, since usb mice appear to be supported in the OS,
could sysinstall be patched to allow you to select usm0 as the mouse
port?

Thanks,
Rob

-- 
Remember: the only difference between
being the champ and the chump is u.



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 #3: Thu Jul 18 18:07:42 CDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TOS5K5
Preloaded elf kernel /boot/kernel/kernel at 0xc0664000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc06640a8.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 1096672181 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (1096.67-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x68a  Stepping = 10
  
Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE
real memory  = 536805376 (524224K bytes)
avail memory = 513970176 (501924K bytes)
Pentium Pro MTRR support enabled
Using $PIR table, 8 entries at 0xc00f0190
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: TOSHIB 5000 on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-safe  frequency 3579545 Hz
can't fetch resources for \\_SB_.LNKA - AE_BAD_DATA
can't fetch resources for \\_SB_.LNKB - AE_BAD_DATA
can't fetch resources for \\_SB_.LNKC - AE_BAD_DATA
can't fetch resources for \\_SB_.LNKF - AE_BAD_DATA
can't fetch resources for \\_SB_.LNKH - AE_BAD_DATA
can't fetch resources for \\_SB_.PCI0.FNC0.FSIR - AE_BAD_DATA
acpi_timer0: 24-bit timer at 3.579545MHz port 0xee08-0xee0b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: PCI bus on acpi_pcib0
agp0: Intel 82815 (i815 GMCH) host to PCI bridge mem 0xf800-0xfbff at device 
0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at device 0.0 (no driver attached)
pcib2: PCI-PCI bridge at device 30.0 on pci0
pci2: PCI bus on pcib2
pci2: serial bus, FireWire at device 7.0 (no driver attached)
fxp0: Intel Pro/100 Ethernet port 0xdf40-0xdf7f mem 0xfceff000-0xfcef irq 6 at 
device 8.0 on pci2
fxp0: Ethernet address 00:00:39:83:20:e0
inphy0: i82562ET 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pcic0: chip is in D3 power mode -- setting to D0
pcic0: Toshiba ToPIC100 PCI-CardBus Bridge at device 11.0 on pci2
pcic0: PCI Memory allocated: 0xfce0
pcic0: No PCI interrupt routed, trying ISA.
pcic0: Polling mode
pccard0: PC Card bus (classic) on pcic0
pcic1: chip is in D3 power mode -- setting to D0
pcic1: Toshiba ToPIC100 PCI-CardBus Bridge at device 11.1 on pci2
pcic1: PCI Memory allocated: 0xfce01000
pcic1: No PCI interrupt routed, trying ISA.
pcic1: Polling mode
pccard1: PC Card bus (classic) on pcic1
pci2: base peripheral at device 12.0 (no driver attached)
pci2: base peripheral at device 13.0 (no driver attached)
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH2 ATA100 controller port 

Re: (Sort of) Solved Re: Current (DP1) on Toshiba 5005

2002-07-19 Thread Alexander Kabaev

On 19 Jul 2002 07:33:30 -0500
Rob Hughes [EMAIL PROTECTED] wrote:

 can't fetch resources for \\_SB_.LNKA - AE_BAD_DATA
  can't fetch resources for \\_SB_.LNKB - AE_BAD_DATA
  can't fetch resources for \\_SB_.LNKC - AE_BAD_DATA
  can't fetch resources for \\_SB_.LNKF - AE_BAD_DATA
  can't fetch resources for \\_SB_.LNKH - AE_BAD_DATA
  can't fetch resources for \\_SB_.PCI0.FNC0.FSIR - AE_BAD_DATA

^^^ I had to patch ACPICA sources to make my laptoop to work.
Apparently, folks at ACPI mailing list made exactly the same patch too.
Returning AE_BAD_DATA for empty resource descriptors is wrong.

Index: rsio.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsio.c,v
retrieving revision 1.1.1.7
diff -u -r1.1.1.7 rsio.c
--- rsio.c  9 Jul 2002 17:51:30 -   1.1.1.7
+++ rsio.c  14 Jul 2002 04:02:15 -
@@ -501,12 +501,14 @@
 i++;
 }
 }
+#if 0
 if (i == 0)
 {
 /* Zero channels is invalid! */
 
 return_ACPI_STATUS (AE_BAD_DATA);
 }
+#endif
 OutputStruct-Data.Dma.NumberOfChannels = i;
 
 
Index: rsirq.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsirq.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 rsirq.c
--- rsirq.c 9 Jul 2002 17:51:30 -   1.1.1.9
+++ rsirq.c 14 Jul 2002 03:30:02 -
@@ -190,12 +190,14 @@
 }
 }
 
+#if 0
 if (i == 0)
 {
 /* Zero interrupts is invalid! */
 
 return_ACPI_STATUS (AE_BAD_DATA);
 }
+#endif
 OutputStruct-Data.Irq.NumberOfInterrupts = i;
 
 /*
-- 
Alexander Kabaev

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



Re: (Sort of) Solved Re: Current (DP1) on Toshiba 5005

2002-07-19 Thread Rob Hughes

On Fri, 2002-07-19 at 07:42, Alexander Kabaev wrote:
 On 19 Jul 2002 07:33:30 -0500
 Rob Hughes [EMAIL PROTECTED] wrote:
 
  can't fetch resources for \\_SB_.LNKA - AE_BAD_DATA
   can't fetch resources for \\_SB_.LNKB - AE_BAD_DATA
   can't fetch resources for \\_SB_.LNKC - AE_BAD_DATA
   can't fetch resources for \\_SB_.LNKF - AE_BAD_DATA
   can't fetch resources for \\_SB_.LNKH - AE_BAD_DATA
   can't fetch resources for \\_SB_.PCI0.FNC0.FSIR - AE_BAD_DATA
 
 ^^^ I had to patch ACPICA sources to make my laptoop to work.
 Apparently, folks at ACPI mailing list made exactly the same patch too.
 Returning AE_BAD_DATA for empty resource descriptors is wrong.
 
 Index: rsio.c
 ===
 RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsio.c,v
 retrieving revision 1.1.1.7
 diff -u -r1.1.1.7 rsio.c
 --- rsio.c9 Jul 2002 17:51:30 -   1.1.1.7
 +++ rsio.c14 Jul 2002 04:02:15 -
 @@ -501,12 +501,14 @@
  i++;
  }
  }
 +#if 0
  if (i == 0)
  {
  /* Zero channels is invalid! */
  
  return_ACPI_STATUS (AE_BAD_DATA);
  }
 +#endif
  OutputStruct-Data.Dma.NumberOfChannels = i;
  
  
 Index: rsirq.c
 ===
 RCS file: /home/ncvs/src/sys/contrib/dev/acpica/rsirq.c,v
 retrieving revision 1.1.1.9
 diff -u -r1.1.1.9 rsirq.c
 --- rsirq.c   9 Jul 2002 17:51:30 -   1.1.1.9
 +++ rsirq.c   14 Jul 2002 03:30:02 -
 @@ -190,12 +190,14 @@
  }
  }
  
 +#if 0
  if (i == 0)
  {
  /* Zero interrupts is invalid! */
  
  return_ACPI_STATUS (AE_BAD_DATA);
  }
 +#endif
  OutputStruct-Data.Irq.NumberOfInterrupts = i;
  
  /*
 -- 
 Alexander Kabaev
 

Thanks! I'll give this a shot when I get home tonight. Gotta get to the
customer site right now, though.

Rob


-- 
Remember: the only difference between
being the champ and the chump is u.



signature.asc
Description: This is a digitally signed message part


Re: install -d -C (was: Re: cvs commit: src/share/man/man5 make.conf.5src/share/examples/etc make.conf)

2002-07-19 Thread Bruce Evans

On Fri, 19 Jul 2002, Ruslan Ermilov wrote:

 On Fri, Jul 19, 2002 at 03:05:37PM +0300, Ruslan Ermilov wrote:
  ...
  On Fri, Jul 19, 2002 at 09:21:14PM +1000, Bruce Evans wrote:
   On Thu, 18 Jul 2002, Ruslan Ermilov wrote:
  
ru  2002/07/18 05:07:49 PDT
   
  Modified files:
etc  Makefile
  [...]
usr.sbin/ypserv  Makefile
  Log:
  s/${INSTALL} -c/${INSTALL} ${COPY}/
  
   Strongly unapproved by: bde.
  
   This change is to help work around the foot-shooting of making -d
   incompatible with -C and -p in install(1)'s flags.  It abuses the old
   ...
  Since its first revision (install.1,v 1.7 and install.c,v 1.16 they
  were incompatible).  Later on, in rev. 1.26, it was made a no-op,

I think this makes -c vs -d moot.

  just to support INSTALL=install -C in /etc/make.conf.

-C is not really like -c.  It really means unbreak the default of !-c,
and preserve certain metadata.  Preserving the metadata is the main
point of this option, but IIRC it was made as much like -c as possible
just as a first attempt to kill -c.

  OpenBSD merged these changes and since then they still have them
  incompatible.

That was probably a mistake.  Certainly merging it all back was.  -C
is our (half my) flag, so we should know its intended use :-).

  There are two ways to proceed:
 
  1.  Rename COPY to INSTALL_COPY (that was my plan), optionally giving
  it by default an empty value.  This shouldn't harm third-party
  makefiles as -c is now an effective no-op.  But this would make
  us even more compatible with OpenBSD that has:
 
  : INSTALL_COPYThe old usage of this flag is obsolescent since install(1)
  : now copies by default.  However, it can also be used to
  : specify that a file not be copied unless it is different
  : (via the -p option).  See install(1) for details.  This
  : is to be used when building our own install script so
  : that the entire system can either be installed with copies,
  : or copy-if-different using a single knob. [-c]
 
 OTOH, if we go this way we can get rid of ugly ${COPY} completely.

I'd like to get rid of it too.  But not in RELENG_4.  -c has been the default
for long enough now in -current.  As you know, there are various problems
in using the correctly named variable for install(1)'s flags (INSTALLFLAGS)
to actually hold install's flags in a general way (mainly, this variable
already exists and is used in a non-general way).  However, the old hack
of putting the flags in the same variable as the command still works well
except for the -[Cp] vs -d conflict.  This depends on the flags not being
order-dependent.

  2.  Make again -C an allowed (ignored) option in the -d case.  This would
  make us again incompatible with OpenBSD.
 
  I do not have a technical problem doing either, I'd just like to know
  what do others think about this.

 I'm not sure what's the better way, please help me out.  :-)

I've complained to you before about this :-).  Now I'm interested in getting
other ideas about it.

Bruce


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