From owner-freebsd-mips@FreeBSD.ORG Sat Mar 10 02:53:14 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8F1106564A for ; Sat, 10 Mar 2012 02:53:14 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9208FC0A for ; Sat, 10 Mar 2012 02:53:13 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2518652vcm.13 for ; Fri, 09 Mar 2012 18:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=lvyhp78s/qNvDVX/Mz7QRfLcwJqHs58iOYrWqIoLR3w=; b=Y5QBv5R1vZjCsUTv6GTexHOJ/BeFX+zLX62zu/5MvTRT0dW8/tbe5R5SXB16j9XrCP 5koDCUEZ89IMcYExGktt2smkt3CFEjQfMjrPYUGD2ccaj8fvnrkhdFKlf8YoI5UnAinQ RlItUfcaRtvLwn4UplLpM8tY8lHP/8oa2dHe/zFY5jWxs2WWWyJ4Szs5PYx4kTYHC42i YU27srK0zu6LneVMUiF5Rgq/j8rhbRSPyHqZWZLYgxI2G+Rk+87MfLGE0fNy76KPTJzF DxN4jKc8Os/8JKXWUY7MZLxWsuDJeR2cYWoyOJCOgyipnG28Drk5q/Et5cJKb002Koi3 uF8Q== MIME-Version: 1.0 Received: by 10.52.30.98 with SMTP id r2mr7431127vdh.8.1331347993595; Fri, 09 Mar 2012 18:53:13 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.220.156.83 with HTTP; Fri, 9 Mar 2012 18:53:13 -0800 (PST) Date: Fri, 9 Mar 2012 21:53:13 -0500 X-Google-Sender-Auth: 7UJh4g7hs-sKtpuQ5gDkKlO4ftU Message-ID: From: Patrick Kelsey To: freebsd-mips@freebsd.org Content-Type: multipart/mixed; boundary=20cf3079b89e3b0e4804bada9cb0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [PATCH] Fix for using NFS root with if_arge X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 02:53:14 -0000 --20cf3079b89e3b0e4804bada9cb0 Content-Type: text/plain; charset=ISO-8859-1 This patch fixes an issue I encountered using an NFS root with an ar71xx-based MikroTik RouterBoard 450G on -current where the kernel fails to contact a DHCP/BOOTP server via if_arge when it otherwise should be able to. This may be the same issue that Monthadar Al Jaberi reported against an RSPRO on 6 March, as the signature is the same: %%% DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 . . . DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 arge0: initialization failed: no memory for rx buffers DHCP/BOOTP timeout for server 255.255.255.255 arge0: initialization failed: no memory for rx buffers %%% The primary issue that I found is that the DHCP/BOOTP message that bootpc_call() is sending never makes it onto the wire, which I believe is due to the following: - Last December, a change was made to the ifioctl that bootpc_call() uses to adjust the netmask around the sosend(). - The new ioctl (SIOCAIFADDR) performs an if_init when invoked, whereas the old one (SIOCSIFNETMASK) did not. - if_arge maintains its own sense of link state in sc->arge_link_status. - On a single-phy interface, sc->arge_link_status is initialized to 0 in arge_init_locked(). - sc->arge_link_status remains 0 until a phy state change notification causes arge_link_task to run, notice the link is up, and set it to 1. - The inits caused by the ifioctls in bootpc_call are reinitializing the interface, but not the phy, so sc->arge_link_status goes to 0 and remains there. - arge_start_locked() always sees sc->arge_link_status == 0 and returns without queuing anything. The attached patch changes arge_init_locked() such that in the single-phy case, instead of initializing sc->arge_link_status to 0, it runs arge_link_task() to set it according to the current phy state. This change has allowed my setup to mount an NFS root successfully. I think there is a secondary issue here regarding the "arge0: initialization failed: no memory for rx buffers". I have not dug into it completely yet, but at first blush it seems that arge_stop() leaks mbufs from the rx ring, so after some number of arge_init() calls (in this case triggered by the DHCP/BOOTP message timeouts), all mbufs are exhausted. -Patrick --20cf3079b89e3b0e4804bada9cb0 Content-Type: application/octet-stream; name="if_arge_link_status.diff" Content-Disposition: attachment; filename="if_arge_link_status.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzm26qek0 SW5kZXg6IG1pcHMvYXRoZXJvcy9pZl9hcmdlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL21pcHMvYXRo ZXJvcy9pZl9hcmdlLmMJKHJldmlzaW9uIDIzMjcyNSkKKysrIHN5cy9taXBzL2F0aGVyb3MvaWZf YXJnZS5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMTAsNiArMTEwLDcgQEAKIHN0YXRpYyB2b2lkIGFy Z2VfaW5pdCh2b2lkICopOwogc3RhdGljIHZvaWQgYXJnZV9pbml0X2xvY2tlZChzdHJ1Y3QgYXJn ZV9zb2Z0YyAqKTsKIHN0YXRpYyB2b2lkIGFyZ2VfbGlua190YXNrKHZvaWQgKiwgaW50KTsKK3N0 YXRpYyB2b2lkIGFyZ2VfdXBkYXRlX2xpbmtfbG9ja2VkKHN0cnVjdCBhcmdlX3NvZnRjICpzYyk7 CiBzdGF0aWMgdm9pZCBhcmdlX3NldF9wbGwoc3RydWN0IGFyZ2Vfc29mdGMgKiwgaW50LCBpbnQp Owogc3RhdGljIGludCBhcmdlX21paWJ1c19yZWFkcmVnKGRldmljZV90LCBpbnQsIGludCk7CiBz dGF0aWMgdm9pZCBhcmdlX21paWJ1c19zdGF0Y2hnKGRldmljZV90KTsKQEAgLTY4MywxMyArNjk0 LDIwIEBACiBhcmdlX2xpbmtfdGFzayh2b2lkICphcmcsIGludCBwZW5kaW5nKQogewogCXN0cnVj dCBhcmdlX3NvZnRjCSpzYzsKKwlzYyA9IChzdHJ1Y3QgYXJnZV9zb2Z0YyAqKWFyZzsKKworCUFS R0VfTE9DSyhzYyk7CisJYXJnZV91cGRhdGVfbGlua19sb2NrZWQoc2MpOworCUFSR0VfVU5MT0NL KHNjKTsKK30KKworc3RhdGljIHZvaWQKK2FyZ2VfdXBkYXRlX2xpbmtfbG9ja2VkKHN0cnVjdCBh cmdlX3NvZnRjICpzYykKK3sKIAlzdHJ1Y3QgbWlpX2RhdGEJCSptaWk7CiAJc3RydWN0IGlmbmV0 CQkqaWZwOwogCXVpbnQzMl90CQltZWRpYSwgZHVwbGV4OwogCi0Jc2MgPSAoc3RydWN0IGFyZ2Vf c29mdGMgKilhcmc7Ci0KLQlBUkdFX0xPQ0soc2MpOwogCW1paSA9IGRldmljZV9nZXRfc29mdGMo c2MtPmFyZ2VfbWlpYnVzKTsKIAlpZnAgPSBzYy0+YXJnZV9pZnA7CiAJaWYgKG1paSA9PSBOVUxM IHx8IGlmcCA9PSBOVUxMIHx8CkBAIC03MDcsMTAgKzcyNSwxMCBAQAogCQkJZHVwbGV4ID0gbWlp LT5taWlfbWVkaWFfYWN0aXZlICYgSUZNX0dNQVNLOwogCQkJYXJnZV9zZXRfcGxsKHNjLCBtZWRp YSwgZHVwbGV4KTsKIAkJfQotCX0gZWxzZQorCX0gZWxzZSB7CiAJCXNjLT5hcmdlX2xpbmtfc3Rh dHVzID0gMDsKKwl9CiAKLQlBUkdFX1VOTE9DSyhzYyk7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC04 NDYsNyArODY0LDYgQEAKIAogCiAJaWYgKHNjLT5hcmdlX21paWJ1cykgewotCQlzYy0+YXJnZV9s aW5rX3N0YXR1cyA9IDA7CiAJCW1paSA9IGRldmljZV9nZXRfc29mdGMoc2MtPmFyZ2VfbWlpYnVz KTsKIAkJbWlpX21lZGlhY2hnKG1paSk7CiAJfQpAQCAtODYwLDggKzg3NywxMCBAQAogCWlmcC0+ aWZfZHJ2X2ZsYWdzIHw9IElGRl9EUlZfUlVOTklORzsKIAlpZnAtPmlmX2Rydl9mbGFncyAmPSB+ SUZGX0RSVl9PQUNUSVZFOwogCi0JaWYgKHNjLT5hcmdlX21paWJ1cykKKwlpZiAoc2MtPmFyZ2Vf bWlpYnVzKSB7CiAJCWNhbGxvdXRfcmVzZXQoJnNjLT5hcmdlX3N0YXRfY2FsbG91dCwgaHosIGFy Z2VfdGljaywgc2MpOworCQlhcmdlX3VwZGF0ZV9saW5rX2xvY2tlZChzYyk7CisJfQogCiAJQVJH RV9XUklURShzYywgQVI3MVhYX0RNQV9UWF9ERVNDLCBBUkdFX1RYX1JJTkdfQUREUihzYywgMCkp OwogCUFSR0VfV1JJVEUoc2MsIEFSNzFYWF9ETUFfUlhfREVTQywgQVJHRV9SWF9SSU5HX0FERFIo c2MsIDApKTsK --20cf3079b89e3b0e4804bada9cb0--