Administrative tag a possibility?

2001-05-17 Thread Stewart Morgan


> 
> Mike Smith wrote:
> > 
> > > ...
> > > Say introducing a convention like '$!$' to denote an always to be
> > > acceptable change?
> > 
> > No, not acceptable.
> > 
> > In this case, mergemaster should be smart enough to notice that the
> > file in question was unchanged before the merge, and just 
> not irritate
> > you in the first place.
> 
> You've just won my vote! Nonetheless I think a simple pattern
> match like "$!$" could've been implemented long ago - thus 
> saving me uncounted q+i keypresses, whereas introducing 
> smartness into a program might take a tad longer.
> 

Wasn't there a discussion on something like this ages ago?
I seem to recall somebody suggesting MD5 checksums to see if a file
has changed or not and acting acordingly.

If you're worried about maintaining a database of checksums,
why not place it in the file itself.  Of course somebody'll mention
recursion: if you grep -v CHECKSUM | md5 and compare with grep CHECKSUM,
you've got something that works and is easy to maintain.

Just my 2p worth :)


Stewart.

--
Stewart Morgan MEng AMIEEE
Technical Director, Nameless-UK

T: +44 117 974 55 44| A: The Production House
F: +44 870 168 02 10|147a St. Michael's Hill
E: [EMAIL PROTECTED]  |Bristol
W: www.nameless-uk.com  |BS2 8DB



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



HELP! MII problem

2000-10-26 Thread Stewart Morgan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

Please find attached the dmesg output from a "boot -v".

I've got an Aztel PCI NIC-Hub Adapter.  FreeBSD seems to find
it and configure it for the most part:

wb0:  port 0xec00-0xec7f mem
0xffafef80-0xffafefff irq 11 at device 15.0 on pci0
wb0: Ethernet address: 00:00:e8:21:8b:11

... but then fails with:

device_probe_and_attach: wb0 attach returned 6

I've done some investigation (see my own debug lines in the dmesg)
and have tracked it down to a failure in MII to initalise the PHY.

Can anybody shed any light on why FreeBSD finds the card but not
the PHY and also how to fix it!

Stewart.

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.3 for non-commercial use 

iQA/AwUBOfgdjzBV3dfs1c5kEQIz2QCgyOPDBd+Ej3jdTExZP3CZMDDMpaMAn3G9
xnNkh70PPYBzKcqRQmE/cVof
=ooAF
-END PGP SIGNATURE-


Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.1.1-STABLE #6: Thu Oct  5 18:31:44 BST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/ALPHAD
Calibrating clock(s) ... TSC clock: 350751170 Hz, i8254 clock: 1193031 Hz
Timecounter "i8254"  frequency 1193031 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (350.75-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
  
Features=0x183fbff
real memory  = 67108864 (65536K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00357000 - 0x03ff5fff, 63565824 bytes (15519 pages)
avail memory = 61923328 (60472K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00fdb40
bios32: Entry = 0xfdb50 (c00fdb50)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xdb71
pnpbios: Found PnP BIOS data at 0xc00f7330
pnpbios: Entry = f:66e4  Rev = 1.0
Other BIOS signatures found:
ACPI: 
Preloaded elf kernel "kernel" at 0xc033e000.
Pentium Pro MTRR support enabled
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71a08086)
pcib-: pcib0 exists, using next available unit number
npx0:  on motherboard
npx0: INT 16 interface
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71a08086)
pcib0:  on motherboard
found-> vendor=0x8086, dev=0x71a0, revid=0x00
class=06-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[10]: type 1, range 32, base f800, size 26
found-> vendor=0x8086, dev=0x71a1, revid=0x00
class=06-04-00, hdrtype=0x01, mfdev=0
subordinatebus=1secondarybus=1
found-> vendor=0x8086, dev=0x7110, revid=0x02
class=06-01-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
found-> vendor=0x8086, dev=0x7111, revid=0x01
class=01-01-80, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[20]: type 1, range 32, base ffa0, size  4
found-> vendor=0x8086, dev=0x7112, revid=0x01
class=0c-03-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=d, irq=10
map[20]: type 1, range 32, base ef80, size  5
found-> vendor=0x8086, dev=0x7113, revid=0x02
class=06-80-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[90]: type 1, range 32, base 0440, size  4
found-> vendor=0x9005, dev=0x005f, revid=0x00
class=01-00-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
intpin=a, irq=0
map[10]: type 1, range 32, base ff00, size  8
map[14]: type 1, range 64, base f000, size 12
found-> vendor=0x9005, dev=0x005f, revid=0x00
class=01-00-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
intpin=a, irq=0
map[10]: type 1, range 32, base ff00, size  8
map[14]: type 1, range 64, base f000, size 12
found-> vendor=0x8086, dev=0x1229, revid=0x08
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=10
map[10]: type 1, range 32, base ffaff000, size 12
map[14]: type 1, range 32, base ef00, size  6
map[18]: type 1, range 32, base ff90, size 20
found-> vendor=0x1050, dev=0x0840, revid=0x00
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base ec00, size  7
map[14]: type 1, range 32, base ffafef80, size  7
pci0:  on pcib0
pcib2:  at device 1.0 on pci0
pci1:  on pcib2
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xffa0-0xffaf at device 7.1 on pci0
ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xffa0
ata0