Re: Link failure in ata driver

2002-12-06 Thread GuRU
Out of da blue Kris Kennaway aka ([EMAIL PROTECTED]) said:
 Kernels with the following configuration do not link:
 
 # ATA and ATAPI devices
 device  ata
 device  atapicd # ATAPI CDROM drives
 
 linking kernel.debug
 ata-all.o: In function `ata_boot_attach':
 ata-all.o(.text+0x1590): undefined reference to `ata_raid_attach'
 ata-all.o(.text+0x1594): undefined reference to `ata_raid_attach'
 *** Error code 1
 1 error
Not sure what the exact fix is, but I've had to add atadisk in order to get
the kernel to link:

device  atadisk # ATA disk drives


 
 Kris

./i'khala
-- 
Consider a spherical bear, in simple harmonic motion...
-- Professor in the UCB physics department
bush doctor
[EMAIL PROTECTED]

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



PPP problems in -CURRENT

1999-04-08 Thread GuRu
cvsupped, built CURRENT as of April 8th, upgrading a 3.1-STABLE system to
4.0. A reboot later, all seems fine, except that I'm experiencing severe
problems connecting to my ISP. Everything goes well till after the login
phase, when entering the lcp negotiation phase, then things get FUBARed. 

(passwords have been deliberately blanked, of course. :P)

I believe that both peers are attempting to negotiate an IP address, but
are failing to do so as shown by the repeated negotiation attempts. The
same PPP configuration file worked as of 24 hours ago on 3.1-STABLE. Any
insight would be greatly appreciated. 

Apr  8 21:15:56 Tasha ppp[294]: Phase: Using interface: tun0 
Apr  8 21:15:56 Tasha ppp[294]: Phase: deflink: Created in closed state 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: default: set device /dev/cuaa1 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: default: set speed 115200 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: default: deny lqr 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: default: set dial ABORT BUSY
ABORT NO\sCARRIER TIMEOUT 5  AT
OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: default: alias enable yes 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set phone xxx 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set login ABORT
NO\sCARRIER TIMEOUT 5 ogin:--ogin: 
login word: word
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set server 
 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Phase: Listening at port 4040. 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set timeout 0 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set ifaddr
10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 
Apr  8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: add default HISADDR 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Phase: PPP Started (background mode). 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Phase: bundle: Establish 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Phase: deflink: closed - opening 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Phase: deflink: Connected! 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Phase: deflink: opening - dial 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Phase: Phone: xxx  
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: deflink: Dial attempt 1 of 1 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Send: AT^M 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Expect(5): OK 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: AT^M^M 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: OK^M 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Send: ATE1Q0^M 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Expect(5): OK 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: ATE1Q0^M^M 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: OK^M 
Apr  8 21:15:56 Tasha ppp[295]: tun0: Chat: Send: ATDT^M 
Apr  8 21:15:58 Tasha ppp[295]: tun0: Chat: Expect(40): CONNECT 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: ATDT^M^M 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: CONNECT
33600/ARQ/V34/LAPM/V42BIS^M 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Phase: deflink: dial - login 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Expect(5): ogin: 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: ^M 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: login: 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Send: login^M 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Expect(5): word: 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: Password: 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Chat: Send: password^M 
Apr  8 21:16:13 Tasha ppp[295]: tun0: Phase: deflink: login - lcp 
Apr  8 21:16:13 Tasha ppp[295]: tun0: LCP: FSM: Using deflink as a
transport 
Apr  8 21:16:13 Tasha ppp[295]: tun0: LCP: deflink: State change Initial
-- Closed 
Apr  8 21:16:13 Tasha ppp[295]: tun0: LCP: deflink: State change Closed --
Stopped 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP: deflink: LayerStart 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP: deflink: SendConfigReq(1) state
= Stopped 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP:  ACFCOMP[2] 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP:  PROTOCOMP[2] 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP:  ACCMAP[6] 0x 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP:  MRU[4] 1500 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP:  MAGICNUM[6] 0x49e522ff 
Apr  8 21:16:14 Tasha ppp[295]: tun0: LCP: deflink: State change Stopped
-- Req-Sent 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP: deflink: RecvConfigReq(6) state
= Req-Sent 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP:  ACCMAP[6] 0x000a 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP:  MAGICNUM[6] 0x987dd166 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP:  PROTOCOMP[2] 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP:  ACFCOMP[2] 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP: deflink: SendConfigAck(6) state
= Req-Sent 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP:  ACCMAP[6] 0x000a 
Apr  8 21:16:16 Tasha ppp[295]: tun0: LCP:  MAGICNUM[6] 0x987dd166 
Apr  8 

Re: PPP problems in -CURRENT

1999-04-10 Thread GuRu
At 09:24 4/9/99 +0100, Brian Somers wrote:
Does anything different happen if you

  set accmap 000a

in your ppp.conf ?  If not, you're going to have to approach your ISP 
and ask them why their ppp implementation is ignoring our requests 
(which needless to say violates the rfc).

It would appear that a few more things are wrong, because the setting
doesn't help on my 4.0-CURRENT box, but downgrading to 3.1-RELEASE fixes
the problem. With this in mind, I copied and gzipped the 3.1-RELEASE ppp
binaries (known to work) to a safe place, upgraded to 4.0-CURRENT once
more, and attempted to use the 3.1-REL binaries with 4.0. The strange thing
is that it doesn't work. I'm retreating to the relative sanity of
3.1-STABLE, will let you know what happens. 

--
K



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



kdelibs-kde4 is marked as broken on FreeBSD 13.0: incompatible with base SSL ...

2018-12-24 Thread guru

Hello,

I know that KDE4 will be removed from ports by the end of the year,
that's why I wanted to update my CURRENT and ports right now before
this. I now find that one of the fundamental ports (x11/kdelibs-kde4) is
marked as broken...

Is there a fix for this (for example using SSL from ports and not from
base). The alternative would be reset my poudriere oven to a 19 of
September (my last build with KDE4).

Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, 
Druschba
instead of Nazis, to live instead of to survive.


signature.asc
Description: PGP signature