Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

stable-digest V5 #788

0 views

Skip to first unread message

owner-freebsd...@freebsd.org

unread,

Feb 8, 2003, 1:49:01 PM2/8/03

stable-digest Saturday, February 8 2003 Volume 05 : Number 788

In this issue:
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
Panic during boot under 4.7-STABLE in sbp_get_text_leaf (firewire)
Re: Ęëčåíō - FREEBSD-STABLE
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
HEADS UP: Broken if_dc NICs with MACs like 08:08[...] or 00:00[...]
ĶŽĪJžWĨ[ŠšĪčŠk
Re: OpenSSH_3.5p1 FreeBSD-20030201 crash
ĶŽĪJžWĨ[ŠšĪčŠk
Re: Invalid ps start time values for kernel processes ?
Re: IPSEC problems after upgrade
Come check it out
Re: Invalid ps start time values for kernel processes ?
Re: Invalid ps start time values for kernel processes ?

----------------------------------------------------------------------

Date: Fri, 07 Feb 2003 18:50:42 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

Dave Uhring <duh...@charter.net> writes:
> Before I replaced the binaries with those from the openssh-3.5p1 package and
> disabled PAM this was what my machine reported:
>
> Feb 6 06:59:43 willy sshd[139]: pam_start: malloc failed for pam_conv
> Feb 6 06:59:43 willy sshd[139]: fatal: PAM: initialisation failed

This was fixed very shortly after the upgrade. There's still no
substitute for checking the lists before posting complaints...

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 7 Feb 2003 11:54:36 -0600
From: Mark Nipper <ni...@tamu.edu>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

On Fri, Feb 07, 2003 at 06:50:42PM +0100, Dag-Erling Smorgrav wrote:
> Dave Uhring <duh...@charter.net> writes:
> > Before I replaced the binaries with those from the openssh-3.5p1 package and
> > disabled PAM this was what my machine reported:
> >
> > Feb 6 06:59:43 willy sshd[139]: pam_start: malloc failed for pam_conv
> > Feb 6 06:59:43 willy sshd[139]: fatal: PAM: initialisation failed
>
> This was fixed very shortly after the upgrade. There's still no
> substitute for checking the lists before posting complaints...

This isn't the original problem I reported in this
thread. I don't think it's even related to the "corrupted MAC on
input" error.

- --
Mark Nipper e-contacts:
Computing and Information Services ni...@tamu.edu
Texas A&M University http://ops.tamu.edu/nipsy/
College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617
(979)575-3193 MSN: ni...@tamu.edu

- -----BEGIN GEEK CODE BLOCK-----
GG/IT d- s++:+ a-- C++$ UBL+++$ P--->+++ L+++$ E---
W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+
PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**)
- ------END GEEK CODE BLOCK------

- ---begin random quote of the moment---
"All mail clients suck. This one just sucks less."
-- author of the Mutt e-mail client
- ----end random quote of the moment----

------------------------------

Date: Fri, 07 Feb 2003 19:09:49 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

You could at least have reproduced the error message verbatim
("Corrupted MAC on input."), I would have saved some time trying to
figure out where it came from.

In any case, the message indicates data corruption in the TCP
connection which has gone undetected by the NIC and the network stack.
It's a very unlikely occurrence, but not impossible.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 7 Feb 2003 12:13:15 -0600
From: Dave Uhring <duh...@charter.net>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

On Friday 07 February 2003 11:50 am, Dag-Erling Smorgrav wrote:
> Dave Uhring <duh...@charter.net> writes:
> > Before I replaced the binaries with those from the openssh-3.5p1 package
> > and disabled PAM this was what my machine reported:
> >
> > Feb 6 06:59:43 willy sshd[139]: pam_start: malloc failed for pam_conv
> > Feb 6 06:59:43 willy sshd[139]: fatal: PAM: initialisation failed
>
> This was fixed very shortly after the upgrade. There's still no
> substitute for checking the lists before posting complaints...

That was NOT a complaint. You asked for information regarding sshd on -STABLE
and I was kind enough to provide you with some of that information.

FOAD.

------------------------------

Date: Fri, 07 Feb 2003 18:40:35 +0000
From: Pete French <pfr...@firstcallgroup.co.uk>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

> You could at least have reproduced the error message verbatim
> ("Corrupted MAC on input."), I would have saved some time trying to
> figure out where it came from.

This very interesting - I see these all the time. To the point where an
ssh session to the server is almost unusable at certain times of the day!
I suspect hardware problems and am going to change the hardware for
this reason. If it turns out to be software, however, that would be
very interesting.

I've seen this at least 6 times today already. Next time it happens I will
copy it to the list.

- -pcf.

------------------------------

Date: Fri, 07 Feb 2003 19:47:50 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

Dag-Erling Smorgrav <d...@ofug.org> writes:
> You could at least have reproduced the error message verbatim
> ("Corrupted MAC on input."), I would have saved some time trying to
> figure out where it came from.

I apologize for the tone of this message. I've spent the day getting
angrier and angrier at OpenSSH and pam_ssh and unfairly let this anger
leak out into my email.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 7 Feb 2003 19:53:03 +0000
From: Ollie Cook <ol...@uk.clara.net>
Subject: Panic during boot under 4.7-STABLE in sbp_get_text_leaf (firewire)

Hi,

I am having trouble with firewire on my new laptop (Dell X200). The unit
includes an external CD/DVD drive unit connected via firewire.

The laptop boots fine with a 4.7-STABLE GENERIC kernel (cvsup'd this afternoon
appx 6pm GMT) and also with a GENERIC kernel plus "device firewire".

However, when I include "device sbp", to be able to use the external CD drive,
in the kernel config, the laptop panics during boot.

The lines leading up to the panic are (transcripted, so typos may be present):

firewire0: New S400 device ID:00065b80030f070f
firewire0: Device SBP-II

The instruction pointer where the crash occurs is 0xc01c1896 which is in
sbp_get_text_leaf.

su-2.05b# nm /kernel|sort|grep c01c18
c01c1824 t sbp_get_text_leaf
c01c18e8 t sbp_probe_lun

I have version 1.5.2.10 of src/dev/firewire/sbp.c which contains these
functions.

I recompiled with "options DDB" so was able to get this stack trace from the
kernel debugger (again transcripted so please forgive any typos):

sbp_get_text_leaf
sbp_probe_lun
sbp_probe_target
sbp_post_explore
fw_attach_dev
fw_bus_explore
fw_bus_explore_callback
fw_xfer_done
fw_rcv
fwohci_arcv
fwohci_intr_body
fwochi_intr

I was unable to induce a coredump using 'panic' in the kernel debugger (is it
possible to get a core dump during boot in this way?).

I think I've reached the end of the line in terms of my knowledge and finding
out what is causing this panic. Does anyone have any suggestions on what I can
try next?

I have included the dmesg output from a successful boot with firewire enabled
but no sbp, in case that is useful.

Thanks,

Ollie

- -- dmesg output --
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.7-STABLE #0: Fri Feb 7 18:31:54 GMT 2003
ro...@laptop.olliecook.net:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz
CPU: Intel(R) Pentium(R) III Mobile CPU 800MHz (797.35-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1
Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE>
real memory = 393740288 (384512K bytes)
avail memory = 376844288 (368012K bytes)
Preloaded elf kernel "kernel.works" at 0xc0581000.
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 9 entries at 0xc00fdf30
apm0: <APM BIOS> on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
agp0: <Intel 82830 (i830M GMCH) SVGA controller> mem 0xe0000000-0xe007ffff,0xe80
00000-0xefffffff irq 10 at device 2.0 on pci0
agp0: detected 8060k stolen memory
agp0: aperture size is 128M
pci0: <unknown card> (vendor=0x8086, dev=0x3577) at 2.1
uhci0: <Intel 82801CA/CAM (ICH3) USB controller USB-A> port 0x8c80-0x8c9f irq 10
at device 29.0 on pci0
usb0: <Intel 82801CA/CAM (ICH3) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: <Intel 82801CA/CAM (ICH3) USB controller USB-B> port 0x8ca0-0x8cbf irq 11
at device 29.1 on pci0
usb1: <Intel 82801CA/CAM (ICH3) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: <Intel 82801CA/CAM (ICH3) USB controller USB-C> port 0x8cc0-0x8cdf irq 11
at device 29.2 on pci0
usb2: <Intel 82801CA/CAM (ICH3) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
pcib1: <PCI to PCI bridge (vendor=8086 device=2448)> at device 30.0 on pci0
pci2: <PCI bus> on pcib1
pci_cfgintr_linked: linked (60) to hard-routed irq 10
pci_cfgintr: 2:3 INTA routed to irq 10
pcic0: <Ricoh RL5C475 PCI-CardBus Bridge> irq 10 at device 3.0 on pci2
pcic0: PCI Memory allocated: 0x88000000
pccard0: <PC Card 16-bit bus (classic)> on pcic0
fwohci0: vendor=1180, dev=551
fwohci0: <1394 Open Host Controller Interface> mem 0xe0200000-0xe02007ff irq 11
at device 3.1 on pci2
fwohci0: PCI bus latency was changing to 250.
fwohci0: OHCI version 1.0 (ROM=1)
fwohci0: No. of Isochronous channel is 4.
fwohci0: EUI64 00:06:5b:80:01:0f:73:d3
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xa000-0xa07f mem 0xe0200800-0xe020
087f irq 11 at device 5.0 on pci2
xl0: Ethernet address: 00:06:5b:89:83:f0
miibus0: <MII bus> on xl0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: <PCI to ISA bridge (vendor=8086 device=248c)> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH3 ATA100 controller> port 0x9000-0x900f,0-0x3,0-0x7,0-0x3,0-0
x7 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: <unknown card> (vendor=0x8086, dev=0x2483) at 31.3 irq 10
pcm0: <Intel 82801CA (ICH3)> port 0x80c0-0x80ff,0x8400-0x84ff irq 10 at device 3
1.5 on pci0
pcm0: <Cirrus Logic CS4299D ac97 codec>
pci0: <unknown card> (vendor=0x8086, dev=0x2486) at 31.6 irq 10
orm0: <Option ROMs> at iomem 0xc0000-0xccfff,0xd0000-0xd2fff,0xd3000-0xd3fff,0xd
4000-0xd47ff,0xd4800-0xd4fff on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250
sio1: configured irq 3 not in bitmap of probed irqs 0
fwohci0: BUS reset
fwohci0: node_id = 0xc800ffc1, CYCLEMASTER mode
firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
ad0: 28615MB <IC25N030ATCS04-0> [58140/16/63] at ata0-master UDMA100
Mounting root from ufs:/dev/ad0s3a
firewire0: New S400 device ID:00065b80030f070f
firewire0: Device SBP-II
- -- end dmesg output --

- --
Oliver Cook Systems Administrator, Claranet UK
ol...@uk.clara.net 020 7903 3000

------------------------------

Date: Fri, 7 Feb 2003 23:52:55
From: <oEs...@chat.ru>
Subject: Re: Ęëčåíō - FREEBSD-STABLE

<html><head><title>Ó âāņ íåō įāęāįîâ</title></head><body><div align="center">
<table border="0" width="400" style="font-family: Verdana; font-size: 8pt" cellspacing="0" cellpadding="0">
<tr><td width="100%">Ó âāņ íåō įāęāįîâ? Ïåðåņōāëč
įâîíčōü ęëčåíōû? Î Âāøčõ óņëóãāõ íčęōî
íå įíāåō? Íå õâāōāåō äåíåã íā
ïðîâåäåíčå øčðîęîėāņøōāáíîé ðåęëāėû?
Âņå ýōč ïðîáëåėû ėû ņėîæåė ðåøčōü
âņåãî įā 300$. Įā ýōč äåíüãč ó Âāņ
ïîĸâčōüņĸ âîįėîæíîņōü ðāįîņëāōü ņâîå
ņîîáųåíčå íā 3.800.000 ïîëóũāōåëåé! Ōîëüęî
âäóėāéōåņü â ýōó öčôðó! Ðāņņûëęā
äëčōüņĸ â ōåũåíčč 1 äíĸ. Â áāįó E-Mail
āäðåņîâ ïîïāëč íå ōîëüęî îðãāíčįāöčč č
ïðåäïðčĸōčĸ Ėîņęâû č Ðîņņčč, íî č âņå
ũāņōíûå ëčöā. Âņĸ áāįā íā 100%
âåðčôčöčðîâāííāĸ č ėû äāåė ãāðāíōčþ íā
åļ ęāũåņōâî!
ÏËÞŅ! Įāęāįāâ ó íāņ E-Mail ðāņņûëęó
ņåéũāņ, Âû ņėîæåōå âîņïîëüįîâāōüņĸ
íāøåé íāęîïčōåëüíîé ņčņōåėîé (ïîäðîáíîņōč
ïðč įāęāįå).
Įāęāįāōü ðāņņûëęó Âû
ņėîæåōå <a href="http://64.239.35.244/">įäåņü</a>.<center>Ũōîáû
óäāëčōü ņâîé E-Mail,
íāæėčōå <a href="http://64.239.35.244/cgi-bin/remove.cgi?mail=freebsd...@freebsd.org">įäåņü</a>.(ņ) 2003 DEMETRIUS
Software.</td></tr></table></div></body></html>

------------------------------

Date: Fri, 7 Feb 2003 15:11:47 -0600
From: Mark Nipper <ni...@tamu.edu>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

On Fri, Feb 07, 2003 at 07:09:49PM +0100, Dag-Erling Smorgrav wrote:
> In any case, the message indicates data corruption in the TCP
> connection which has gone undetected by the NIC and the network stack.
> It's a very unlikely occurrence, but not impossible.

Does this imply hardware failure of some kind? The
reason I have to ask of course is that since I have been
experiencing actual crashes on this machine (and I mean real
crashes, not just OpenSSH processes dying on me) and this
machines almost sole purpose in life is as an NFS server, could
the fxp card be causing more trouble than just a randomly bizarre
error message from OpenSSH?

- ---begin random quote of the moment---
"Computer games don't affect kids; I mean if Pac-Man affected us as
kids, we'd all be running around in darkened rooms, munching magic
pills and listening to repetitive electronic music."
-- Kristian Wilson, Nintendo, Inc, 1989
- ----end random quote of the moment----

------------------------------

Date: Fri, 7 Feb 2003 23:48:04 +0100
From: Martin Blapp <m...@imp.ch>
Subject: HEADS UP: Broken if_dc NICs with MACs like 08:08[...] or 00:00[...]

Hi all,

Many if_dc cards are still broken in RELENG_4. Can you please
try this diff if you own such a broken card ?

If you have a Conexant LANfinity MiniPCI 10/100BaseTX card, I'd like
to have feedback if full duplex mode works now too.

Thank you very much for your tests. I'd like to see all these
DEC/Intel 21143 clone cards fixed for 4.8R.

Martin

- -----------------------------------------------------------------

http://people.freebsd.org/~mbr/patches/if_dc.c-MFC.diff

MFC Rev. 1.80, 1.81

Dynamically configure the width of the srom. This code comes from
OpenBSD who got the code (or the idea) from the NetBSD tlp driver.

MFC Rev. 1.67

Fix Conexant chips which always reports carrier lost
on full duplex mode.

Index: if_dc.c
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_dc.c,v
retrieving revision 1.9.2.38
diff -u -r1.9.2.38 if_dc.c
- --- if_dc.c 5 Feb 2003 22:10:04 -0000 1.9.2.38
+++ if_dc.c 7 Feb 2003 19:01:18 -0000
@@ -223,6 +223,7 @@
static void dc_eeprom_getword __P((struct dc_softc *, int, u_int16_t *));
static void dc_eeprom_getword_pnic
__P((struct dc_softc *, int, u_int16_t *));
+static void dc_eeprom_width __P((struct dc_softc *));
static void dc_read_eeprom __P((struct dc_softc *, caddr_t, int,
int, int));

@@ -250,6 +251,7 @@
static int dc_list_rx_init __P((struct dc_softc *));
static int dc_list_tx_init __P((struct dc_softc *));

+static void dc_read_srom __P((struct dc_softc *, int));
static void dc_parse_21143_srom __P((struct dc_softc *));
static void dc_decode_leaf_sia __P((struct dc_softc *,
struct dc_eblock_sia *));
@@ -324,6 +326,70 @@
CSR_READ_4(sc, DC_BUSCTL);
}

+static void dc_eeprom_width(sc)
+ struct dc_softc *sc;
+{
+ int i;
+
+ /* Force EEPROM to idle state. */
+ dc_eeprom_idle(sc);
+
+ /* Enter EEPROM access mode. */
+ CSR_WRITE_4(sc, DC_SIO, DC_SIO_EESEL);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_ROMCTL_READ);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CS);
+ dc_delay(sc);
+
+ for (i = 3; i--;) {
+ if (6 & (1 << i))
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ else
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ }
+
+ for (i = 1; i <= 12; i++) {
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ if (!(CSR_READ_4(sc, DC_SIO) & DC_SIO_EE_DATAOUT)) {
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ break;
+ }
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ }
+
+ /* Turn off EEPROM access mode. */
+ dc_eeprom_idle(sc);
+
+ if (i < 4 || i > 12)
+ sc->dc_romwidth = 6;
+ else
+ sc->dc_romwidth = i;
+
+ /* Enter EEPROM access mode. */
+ CSR_WRITE_4(sc, DC_SIO, DC_SIO_EESEL);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_ROMCTL_READ);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CS);
+ dc_delay(sc);
+
+ /* Turn off EEPROM access mode. */
+ dc_eeprom_idle(sc);
+}
+
static void dc_eeprom_idle(sc)
struct dc_softc *sc;
{
@@ -363,21 +429,24 @@
{
register int d, i;

- - /*
- - * The AN985 has a 93C66 EEPROM on it instead of
- - * a 93C46. It uses a different bit sequence for
- - * specifying the "read" opcode.
- - */
- - if (DC_IS_CENTAUR(sc) || DC_IS_CONEXANT(sc))
- - d = addr | (DC_EECMD_READ << 2);
- - else
- - d = addr | DC_EECMD_READ;
+ d = DC_EECMD_READ >> 6;
+ for (i = 3; i--; ) {
+ if (d & (1 << i))
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ else
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_DATAIN);
+ dc_delay(sc);
+ DC_SETBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ DC_CLRBIT(sc, DC_SIO, DC_SIO_EE_CLK);
+ dc_delay(sc);
+ }

/*
* Feed in each bit and strobe the clock.
*/
- - for (i = 0x400; i; i >>= 1) {
- - if (d & i) {
+ for (i = sc->dc_romwidth; i--;) {
+ if (addr & (1 << i)) {
SIO_SET(DC_SIO_EE_DATAIN);
} else {
SIO_CLR(DC_SIO_EE_DATAIN);
@@ -1572,6 +1641,7 @@

m->dc_next = sc->dc_mi;
sc->dc_mi = m;
+ free(sc->dc_srom, M_DEVBUF);

sc->dc_pmode = DC_PMODE_SIA;

@@ -1630,6 +1700,17 @@
return;
}

+static void dc_read_srom(sc, bits)
+ struct dc_softc *sc;
+ int bits;
+{
+ int size;
+
+ size = 2 << bits;
+ sc->dc_srom = malloc(size, M_DEVBUF, M_NOWAIT);
+ dc_read_eeprom(sc, (caddr_t)sc->dc_srom, 0, (size / 2), 0);
+}
+
static void dc_parse_21143_srom(sc)
struct dc_softc *sc;
{
@@ -1753,13 +1834,17 @@
sc->dc_info = dc_devtype(dev);
revision = pci_read_config(dev, DC_PCI_CFRV, 4) & 0x000000FF;

+ /* Get the eeprom width, but PNIC has no eeprom */
+ if (sc->dc_info->dc_did != DC_DEVICEID_82C168)
+ dc_eeprom_width(sc);
+
switch(sc->dc_info->dc_did) {
case DC_DEVICEID_21143:
sc->dc_type = DC_TYPE_21143;
sc->dc_flags |= DC_TX_POLL|DC_TX_USE_TX_INTR;
sc->dc_flags |= DC_REDUCED_MII_POLL;
/* Save EEPROM contents so we can parse them later. */
- - dc_read_eeprom(sc, (caddr_t)&sc->dc_srom, 0, 512, 0);
+ dc_read_srom(sc, sc->dc_romwidth);
break;
case DC_DEVICEID_DM9009:
case DC_DEVICEID_DM9100:
@@ -1779,6 +1864,7 @@
sc->dc_flags |= DC_TX_USE_TX_INTR;
sc->dc_flags |= DC_TX_ADMTEK_WAR;
sc->dc_pmode = DC_PMODE_MII;
+ dc_read_srom(sc, sc->dc_romwidth);
break;
case DC_DEVICEID_AN985:
case DC_DEVICEID_EN2242:
@@ -1786,6 +1872,7 @@
sc->dc_flags |= DC_TX_USE_TX_INTR;
sc->dc_flags |= DC_TX_ADMTEK_WAR;
sc->dc_pmode = DC_PMODE_MII;
+ dc_read_srom(sc, sc->dc_romwidth);
break;
case DC_DEVICEID_98713:
case DC_DEVICEID_98713_CP:
@@ -1844,7 +1931,7 @@
sc->dc_flags |= DC_TX_INTR_ALWAYS;
sc->dc_flags |= DC_REDUCED_MII_POLL;
sc->dc_pmode = DC_PMODE_MII;
- - dc_read_eeprom(sc, (caddr_t)&sc->dc_srom, 0, 256, 0);
+ dc_read_srom(sc, sc->dc_romwidth);
break;
default:
printf("dc%d: unknown device: %x\n", sc->dc_unit,
@@ -1908,6 +1995,8 @@
break;
case DC_TYPE_AL981:
case DC_TYPE_AN985:
+ bcopy(&sc->dc_srom[DC_AL_EE_NODEADDR], (caddr_t)&eaddr,
+ ETHER_ADDR_LEN);
dc_read_eeprom(sc, (caddr_t)&eaddr, DC_AL_EE_NODEADDR, 3, 0);
break;
case DC_TYPE_CONEXANT:
@@ -2468,13 +2557,13 @@
* the list buffers.
*/

- -static void dc_txeof(sc)
+static void
+dc_txeof(sc)
struct dc_softc *sc;
{
struct dc_desc *cur_tx = NULL;
struct ifnet *ifp;
int idx;
- - u_int32_t errmask;

ifp = &sc->arpcom.ac_if;

@@ -2494,7 +2583,6 @@

if (!(cur_tx->dc_ctl & DC_TXCTL_LASTFRAG) ||
cur_tx->dc_ctl & DC_TXCTL_SETUP) {
- - sc->dc_cdata.dc_tx_cnt--;
if (cur_tx->dc_ctl & DC_TXCTL_SETUP) {
/*
* Yes, the PNIC is so brain damaged
@@ -2511,21 +2599,29 @@
}
sc->dc_cdata.dc_tx_chain[idx] = NULL;
}
+ sc->dc_cdata.dc_tx_cnt--;
DC_INC(idx, DC_TX_LIST_CNT);
continue;
}

- - if (sc->dc_pmode == DC_PMODE_MII) {
- - errmask = DC_TXSTAT_ERRSUM|
- - DC_TXSTAT_NOCARRIER|DC_TXSTAT_CARRLOST;
+ if (DC_IS_CONEXANT(sc)) {
/*
- - * The Conexant chip always reports carrier lost
- - * in full duplex modes.
+ * For some reason Conexant chips like
+ * setting the CARRLOST flag even when
+ * the carrier is there. In CURRENT we
+ * have the same problem for Xircom
+ * cards !
*/
- - if (DC_IS_CONEXANT(sc) && (sc->dc_if_media & IFM_FDX)) {
- - errmask &= ~DC_TXSTAT_CARRLOST;
- - }
- - if ((txstat & 0xFFFF) & ~errmask)
+ if (/*sc->dc_type == DC_TYPE_21143 &&*/
+ sc->dc_pmode == DC_PMODE_MII &&
+ ((txstat & 0xFFFF) & ~(DC_TXSTAT_ERRSUM|
+ DC_TXSTAT_NOCARRIER)))
+ txstat &= ~DC_TXSTAT_ERRSUM;
+ } else {
+ if (/*sc->dc_type == DC_TYPE_21143 &&*/
+ sc->dc_pmode == DC_PMODE_MII &&
+ ((txstat & 0xFFFF) & ~(DC_TXSTAT_ERRSUM|
+ DC_TXSTAT_NOCARRIER|DC_TXSTAT_CARRLOST)))
txstat &= ~DC_TXSTAT_ERRSUM;
}

@@ -2553,11 +2649,13 @@
DC_INC(idx, DC_TX_LIST_CNT);
}

- - if (idx != sc->dc_cdata.dc_tx_cons) {
+ if (idx != sc->dc_cdata.dc_tx_cons) {
+ /* some buffers have been freed */
sc->dc_cdata.dc_tx_cons = idx;
- - ifp->if_flags &= ~IFF_OACTIVE;
- - }
- - ifp->if_timer = (sc->dc_cdata.dc_tx_cnt == 0) ? 0 : 5;
+ ifp->if_flags &= ~IFF_OACTIVE;
+ }
+ ifp->if_timer = (sc->dc_cdata.dc_tx_cnt == 0) ? 0 : 5;
+
return;
}

Index: if_dcreg.h
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_dcreg.h,v
retrieving revision 1.4.2.20
diff -u -r1.4.2.20 if_dcreg.h
- --- if_dcreg.h 5 Feb 2003 22:10:04 -0000 1.4.2.20
+++ if_dcreg.h 7 Feb 2003 19:01:18 -0000
@@ -688,13 +688,14 @@
u_int8_t dc_pmode;
u_int8_t dc_link;
u_int8_t dc_cachesize;
+ int dc_romwidth;
int dc_pnic_rx_bug_save;
unsigned char *dc_pnic_rx_buf;
int dc_if_flags;
int dc_if_media;
u_int32_t dc_flags;
u_int32_t dc_txthresh;
- - u_int8_t dc_srom[1024];
+ u_int8_t *dc_srom;
struct dc_mediainfo *dc_mi;
struct dc_list_data *dc_ldata;
struct dc_chain_data dc_cdata;

Martin Blapp, <m...@imp.ch> <m...@FreeBSD.org>
- ------------------------------------------------------------------
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: <finger -l m...@freebsd.org>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
- ------------------------------------------------------------------

------------------------------

Date: 08 Feb 2003 07:36:42 +0800
From: je...@FreeBSD.ORG
Subject: ĶŽĪJžWĨ[ŠšĪčŠk

<html>
<head>
<title>ĶLķrūũ</title>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
</head>

<body bgcolor="#CC0000" text="#000000">
<div align="center">
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0" width="500" height="380">
<param name=movie value="http://us.greet1.yimg.com/img.greetings.yahoo.com/g/img/ykimo/2000122229371.swf">
<param name=quality value=high>
<embed src="http://us.greet1.yimg.com/img.greetings.yahoo.com/g/img/ykimo/2000122229371.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="500" height="380">
</embed>
</object> 
 ·sĶ~Â§ŠŦ°eązĪ@Ĩx<a href="http://www.pmo.com.tw/entry/document/member/pmd/heart/web/newyearlist88.html">ĶLķrūũ</a><a href="http://www.pmo.com.tw/entry/document/member/pmd/heart/NICK%A4%BD%A8%C6%A5%5D/%B7s%A6%7E%AA%A9%AA%ED%B3%E6.html">
...</a> 
</div>
</body>
</html>

------------------------------

Date: Sat, 08 Feb 2003 00:34:03 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: OpenSSH_3.5p1 FreeBSD-20030201 crash

Mark Nipper <ni...@tamu.edu> writes:
> On Fri, Feb 07, 2003 at 07:09:49PM +0100, Dag-Erling Smorgrav wrote:
> > In any case, the message indicates data corruption in the TCP
> > connection which has gone undetected by the NIC and the network stack.
> > It's a very unlikely occurrence, but not impossible.
> Does this imply hardware failure of some kind?

Not necessarily, it could simply be noise on the cable.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: 08 Feb 2003 08:42:50 +0800
From: je...@FreeBSD.ORG
Subject: ĶŽĪJžWĨ[ŠšĪčŠk

<html>
<head>
<title>ĶLķrūũ</title>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
</head>

------------------------------

Date: Sat, 8 Feb 2003 13:50:33 +1000
From: Paul Koch <paul...@statscout.com>
Subject: Re: Invalid ps start time values for kernel processes ?

On Fri, 7 Feb 2003 11:49 pm, Oliver Fromme wrote:
> Paul Koch <paul...@statscout.com> wrote:
> > The ps output value for STARTED appears to be incorrect for
> > kernel started processes. I found this while writing a tiny ps
> > for our freebsd based network appliance. The start time returned
> > from /proc/{normal pid}/status (man procfs) appears to be in
> > UTC while the start time for a kernel process appears to be
> > localtime (or the other way round). This gave me wild values.
> > Is this correct behaviour ?
>
> Is your CMOS clock running with local time, rather than UTC?
> (i.e. does the file /etc/wall_cmos_clock exist?)
>
> In that case, the kernel will start up with the wrong time
> information, because it doesn't know the timezone you're in
> (the kernel always uses UTC internally). This information
> is corrected by the adjkerntz program in the early stages
> of the boot process.
>
> However, the kernel processes start before that correction
> happens. If you were living east of Greenwich (i.e. positive
> timezone offset), the start time values would even be in the
> future.
>
> If FreeBSD is the only operating system on that machine,
> I suggest that you run the CMOS clock with UTC, avoiding the
> problem alltogether. Of course, you can also just ignore
> the wrong start values. They should not cause any harm.
>
> I don't think there is an easy way to fix the problem.

My development machine was running CMOS time (might change
that because there is no Windows here!) and there is a
/etc/wall_cmos_clock file. Our network appliance platform only
runs in UTC so my ps runs fine on it.

Wouldn't it be more consistant for all process info be stored
in UTC and get ps to convert/display it in localtime ?

=09Paul.

------------------------------

Date: Sat, 08 Feb 2003 18:22:31 +0900
From: Peter Haight <pet...@sapros.com>
Subject: Re: IPSEC problems after upgrade

I figured out what the problem was, so I thought I'd post the solution
because I never found it when I was searching the archives. Basically, there
was a change to the way IPSEC worked and the end result is that the packets
get run through the firewall after they get decrypted and so they look like
they are coming from an internal network on an external interface and so
they get rejected by a firewall rule that was rejecting private network ip
addresses.

The reason the 'inbound packets violated process security policy' counter
was increasing was because the packets were going through NAT and after
that they didn't match the SPD.

Anyway, I've got everything working again. Someone might want to add a note
to the IPSEC handbook docs explaining about this firewall issue and maybe
the NAT thing as well.

> I've now upgraded two machines that I use as IPSEC tunnel endpoints to
> create a VPN. I used to use a script to setup the VPN that I will post
> below, but that script no longer works and I haven't been able to figure out
> why. Before I upgraded, the VPN was working fine. (Though maybe I had some
> security hole that is now caught by FreeBSD and is preventing my VPN from
> working.)
>
> ....

------------------------------

Date: Sat, 08 Feb 2003 17:10:53 -0700
From: <thys...@shaw.ca>
Subject: Come check it out

<a href="http://www.quicklink.bz/smev/cc/">Click He<!h>re to Visit Our Site!</a>

Talk face to face with t<!Na>housands of people that share the
same i<!Hm>nterests as you!

Not Only is it free, if you have a w<!tel>ebcam you can get paid to be online!

4.6 million me<!jq>mbers from more then 100 countries makes iFriends the most diverse online community.

If you just want to chat or need someone to talk to iF<!ka>riends is there for You.

<a href="http://www.quicklink.bz/smev/cc/">Click He<!Yk>re to Visit Our Site!</a>

<a href="http://www.quicklink.bz/smev/cc/">Co<!ruf>me see what its all about!</a>



 <a href="http://www.fasthost.bz/smev/remove/" target="_blank">op<!Yk>t-ou<!ruf>t</a>

------------------------------

Date: Sat, 8 Feb 2003 15:22:38 +0100 (CET)
From: Oliver Fromme <ol...@secnetix.de>
Subject: Re: Invalid ps start time values for kernel processes ?

Paul Koch <paul...@statscout.com> wrote:
> My development machine was running CMOS time (might change
> that because there is no Windows here!) and there is a
> /etc/wall_cmos_clock file. Our network appliance platform only
> runs in UTC so my ps runs fine on it.

That explains it.

> Wouldn't it be more consistant for all process info be stored
> in UTC and get ps to convert/display it in localtime ?

That's already the case. All times are stored in UTC, and
it's only converted to your local timezone for display by
ps, ls, date etc. The kernel does not have any timezone
information at all -- the kernel knows only UTC.

The problem ist that during boot of the kernel, i.e. even
before the root filesystem is mounted, there is no way to
find out your timezone. If the CMOS clock runs in UTC,
then there is no problem -- the kernel just picks it up
and uses it as its internal UTC clock. All process time
information will be correct, right from the start.

However, if the CMOS clock runs in local time, then there
is no way for the kernel to convert it to UTC, because the
kernel does not know what your local timezone is. How
should it know? Those system processes are started before
the root filesystem can be mounted, i.e. there is no
information from /etc/localtime and /etc/wall_cmos_clock.
The kernel has no other choice than interpreting the value
of the CMOS clock as UTC, which results in an error that
amounts to the offset of your local timezone.

Regards
Oliver

- --
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"All that we see or seem is just a dream within a dream" (E. A. Poe)

------------------------------

Date: Sat, 8 Feb 2003 19:47:08 +0100
From: Thomas Seck <tmseck...@netcologne.de>
Subject: Re: Invalid ps start time values for kernel processes ?

* Oliver Fromme (ol...@secnetix.de):

> However, if the CMOS clock runs in local time, then there
> is no way for the kernel to convert it to UTC, because the
> kernel does not know what your local timezone is. How
> should it know?

NetBSD allows you (when I last looked at it, it was 1.5.something) to
set a kernel variable for the difference between CMOS time and UTC at
compile time. You would then need two kernels to reflect DST.

--Thomas

------------------------------

End of stable-digest V5 #788
****************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-stable-digest in the body of the message

0 new messages