From owner-freebsd-current@FreeBSD.ORG Tue Nov 4 01:44:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97F451065673 for ; Tue, 4 Nov 2008 01:44:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD648FC16 for ; Tue, 4 Nov 2008 01:44:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so152166ana.13 for ; Mon, 03 Nov 2008 17:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WJBm6peupNP04S21gXqRqpsRdJFdfIVaUkX7vpVtojc=; b=RHL4QfnwDCgC6UCyBzzOWgirUzOH8KfvxVjuo39ALECheZcdFDyDpl43KZQgMNwg2H HtmYThSwk6fc7N+0oxJgDdP4XVt/X1rq+eU17KWeURjUk/ampFLozdbsXB8m17L5yDuV Glyvfxum4HU/7Cb982fuhJIF3mjKFBuXVvLtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=gB/4agp+5a0dYUOBIEbDmLkjv0vGYRZauRd5T9xprhdfCr82Y4caQD2nD23pJOAwp2 5M5besdgpJ86pnvy+mptn6/LOgLeNsW5Ib7NbRMPho1XcHDj/URr9u535l1H86uLJdVt mRh4LKhA08Ymi3MnDmi2k+iL9xqThrfXk9Si4= Received: by 10.100.247.13 with SMTP id u13mr357979anh.154.1225763090492; Mon, 03 Nov 2008 17:44:50 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id c1sm451936ana.56.2008.11.03.17.44.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Nov 2008 17:44:49 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mA41gmLZ098507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2008 10:42:48 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mA41gldF098506; Tue, 4 Nov 2008 10:42:47 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 4 Nov 2008 10:42:46 +0900 From: Pyun YongHyeon To: Alexey Shuvaev Message-ID: <20081104014246.GA98154@cdnetworks.co.kr> References: <20081015003745.GG14769@cdnetworks.co.kr> <20081103183556.GA2009@localhost.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081103183556.GA2009@localhost.my.domain> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for testers: fxp(4) WOL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 01:44:51 -0000 On Mon, Nov 03, 2008 at 07:35:56PM +0100, Alexey Shuvaev wrote: > On Wed, Oct 15, 2008 at 09:37:45AM +0900, Pyun YongHyeon wrote: > > I've implemented WOL for fxp(4) and it works ok to me. Because > > there too many variants of fxp(4) hardwares I'd like to hear > > success/failure report before committing attached patch to tree. > > It seems that the following Intel 8255x supports WOL. Apparently > > 82557 lacks WOL capabillity. > > > > 82558 > > 82559 > > 82550 > > 82551 > > > How can one figure out which chip he has? > I have relative old Toshiba notebook with integrated intel network card. > The system is: > > FreeBSD localhost.my.domain 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Oct 27 01:25:54 CET 2008 root@localhost.my.domain:/usr/obj/usr/src/sys/GENERIC i386 > > Here are relevant messages from the verbose boot: > > fxp0: port 0xdf40-0xdf7f mem 0xfceff000-0xfcefffff irq 11 at device 8.0 on pci2 If it's based on ICH controller it would be 82559. > fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfceff000 > fxp0: using memory space register mapping > fxp0: PCI IDs: 8086 1031 1179 0001 0042 > fxp0: Dynamic Standby mode is disabled > miibus0: on fxp0 > fxp0: XXX: driver didn't set ifq_maxlen > ^^^ > Is this something to fix? > fxp(4) didn't set ifq_maxlen and if_attach corrected this with its default value. Normally network device drivers set this queue length to number of Tx descriptors but it's completely up to driver writers and I don't see compeling reason to change that. > fxp0: bpf attached > fxp0: Ethernet address: xx:xx:xx:xx:xx:xx > fxp0: [MPSAFE] > fxp0: [ITHREAD] > > and this is the output from pciconv -lvc: > > fxp0@pci0:2:8:0: class=0x020000 card=0x00011179 chip=0x10318086 rev=0x42 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801CAM (ICH3) PRO/100 VE (LOM) Network Connection' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > > It seems that driver changes something, after boot or 'ifconfig fxp0 wol': > > fxp0: flags=8843 metric 0 mtu 1500 > options=2008 > It indicates your controller supports WOL with magic packet. > and after 'ifconfig fxp0 -wol': > > fxp0: flags=8843 metric 0 mtu 1500 > options=8 > > However the system seems to honors only the BIOS settings, if I enable WOL in > the BIOS the system wakes up from power-down or suspend (to ram) states > regardless of fxp settings and with disabled WOL in BIOS it never > wakes up. > Yes that's an expected behaviour. BIOS option should be changed to enable WOL if you want to wake up your box from power down. If you don't want to wake up your box regardless of BIOS configuration you have to disable WOL with ifconfig before shutting down your box. Likewise even if you enable WOL with ifconfig(8) to wake up your system, BIOS WOL option also should be enabled to make it work. > The worse thing I have noticed is if I send WOL packet while the system is > running it reliably hangs. It does not panic and switching virtual > consoles works (and typing/deleting something in the shell prompt too), > but the cooler runs at full power and you can't do anything else. > This is both with patched fxp and that from -CURRENT. Hmm, I think that was old bebahviour of stock fxp(4). Previously fxp(4) was programmed to accept WOL packets regardless of running state of hardware. With my patch the WOL should be disabled for normal operation and WOL is enabled again when you shutdown your box. If sotck fxp(4) also show the same behaviour it's big security hole. ATM I have no idea how WOL packets can affect running box. :-( > > > If your suspend/resume works on your system you can also wake up > > your system in suspend by WOL. > > > Actually, the system does not wake up from suspended mode properly, either > by power button or by WOL packet, but it tries. > The system I tried didn't resume properly (blank screen) but I could login via network after sending WOL magic packets so I thought resume also works. > > Thanks. > Thank you, if you need something more (debugging output, > testing new patches, digging deeper...) just let me know. Thanks for testing. I'll think again. By chance can you try Linux on your system and check whether it works? -- Regards, Pyun YongHyeon