* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-19 21:25 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <200908192307.22112.rene.mayrhofer@gibraltar.at>
Am Mittwoch, 19. August 2009 23:07:21 schrieb Rene Mayrhofer:
> In this state, rmmod sky2 / modprobe
> sky2 gives:
>
> [ 718.502717] sky2 0000:01:00.0: unsupported chip type 0xff
> [ 718.510517] sky2: probe of 0000:01:00.0 failed with error -95
> [ 718.517900] sky2 0000:02:00.0: unsupported chip type 0xff
> [ 718.524408] sky2: probe of 0000:02:00.0 failed with error -95
> [ 718.531617] sky2 0000:03:00.0: unsupported chip type 0xff
> [ 718.538104] sky2: probe of 0000:03:00.0 failed with error -95
> [ 718.545344] sky2 0000:04:00.0: unsupported chip type 0xff
> [ 718.551818] sky2: probe of 0000:04:00.0 failed with error -95
Just for the sake of completeness, I get this during bootup (i.e. before
networking restart):
[ 1.637607] sky2 driver version 1.24
[ 1.637665] sky2 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ
16iled with error -95 3:00.0: unsupported chi[ 1.637686]
sky2 0000:01:00.0: setting latency timer to 64rror -95
[ 1.637718] sky2 0000:01:00.0: Yukon-2 EC chip revision 2 0xff
[ 1.637832] sky2 0000:01:00.0: irq 28 for MSI/MSI-X
[ 1.638395] sky2 eth0: addr 00:90:0b:09:55:42
[ 1.638418] sky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 1.638431] sky2 0000:02:00.0: setting latency timer to 64
[ 1.638458] sky2 0000:02:00.0: Yukon-2 EC chip revision 2
[ 1.638567] sky2 0000:02:00.0: irq 29 for MSI/MSI-X
[ 1.639117] sky2 eth1: addr 00:90:0b:09:55:43
[ 1.639140] sky2 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 1.639152] sky2 0000:03:00.0: setting latency timer to 64
[ 1.639180] sky2 0000:03:00.0: Yukon-2 EC chip revision 2
[ 1.639289] sky2 0000:03:00.0: irq 30 for MSI/MSI-X
[ 1.639869] sky2 eth2: addr 00:90:0b:09:55:44
[ 1.639894] sky2 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 1.639906] sky2 0000:04:00.0: setting latency timer to 64
[ 1.639934] sky2 0000:04:00.0: Yukon-2 EC chip revision 2
[ 1.680096] sky2 0000:04:00.0: irq 31 for MSI/MSI-X
[ 1.680786] sky2 eth3: addr 00:90:0b:09:55:45
[ 106.751517] sky2 wan: enabling interface
[ 107.404801] sky2 gibsrv: enabling interface
[ 107.631583] sky2 dmz: enabling interface
[ 107.869878] sky2 lan: enabling interface
[ 109.225106] sky2 wan: Link is up at 1000 Mbps, full duplex, flow control
both
[ 109.232519] sky2 gibsrv: Link is up at 100 Mbps, full duplex, flow control
both
[ 109.983861] sky2 dmz: Link is up at 1000 Mbps, full duplex, flow control rx
[ 110.453276] sky2 lan: Link is up at 1000 Mbps, full duplex, flow control rx
Then, at some point the interfaces get disabled (most probably by the
networking restart):
[ 224.652146] sky2 lan: disabling interface
[ 224.684483] sky2 0000:04:00.0: PCI INT A disabled
[ 224.700164] sky2 dmz: disabling interface
[ 224.736502] sky2 0000:03:00.0: PCI INT A disabled
[ 224.760219] sky2 gibsrv: disabling interface
[ 224.812491] sky2 0000:02:00.0: PCI INT A disabled
[ 224.832221] sky2 wan: disabling interface
[ 224.904479] sky2 0000:01:00.0: PCI INT A disabled
best regards,
Rene
--
-------------------------------------------------
Gibraltar firewall http://www.gibraltar.at/
^ permalink raw reply
* Re: [RFC PATCH V2] lib/vsprintf.c: Add struct sockaddr * "%pN<foo>" output
From: Chuck Lever @ 2009-08-19 23:00 UTC (permalink / raw)
To: Joe Perches; +Cc: jens, brian.haley, David Miller, netdev
In-Reply-To: <1250721391.3407.103.camel@Joe-Laptop.home>
On Aug 19, 2009, at 6:36 PM, Joe Perches wrote:
> On Wed, 2009-08-19 at 18:20 -0400, Chuck Lever wrote:
>> On Aug 19, 2009, at 4:44 PM, Joe Perches wrote:
>>> I'm not too sure there's much value in ever more formatters for
>>> relatively simple things or in printing something like port or
>>> scope without the ip address.
>>>
>>> %hu ntohs(sa6->sin6_port)
>>> or
>>> %d or 0x%x ntohl(sa6->sin6_flowinfo)
>>>
>>> seem pretty straightforward to me.
>>
>> It's the same issue for port numbers as it is for addresses: though
>> the port field is the same size in each, it's at different offsets in
>> AF_INET and AF_INET6 addresses, so extra logic is still needed to
>> sort
>> that at each call site.
I should add that the scope ID and flowinfo tag are IPv6 only, so they
really don't have the same problem. If you have to print a scope ID,
you pretty much know you are dealing only with sockaddr_in6.
>> As an example, an rpcbind query cares about the port number result,
>> but usually not the address. A human-readable message could show the
>> returned port number, but leave out the address. Without a separate
>> formatter, you would still need extra logic around each debugging
>> message (for example) to choose how to print the port number.
>>
>> You could probably argue, though, that this is a less common need
>> than
>> printing addresses.
>
> I suppose an address exclude could be added to %pN
> if really needed. Maybe "%pNx(specifiers)"
>>> Here's another tentative patch that does both using square
>>> brackets around IPv6 addresses with a port number and
>>> allows selection of the port number style ":dddd" or ":hi.lo"
>>
>> The "hi.lo" form is always separated from the address by a dot, not
>> by
>> a colon, and square brackets are never used in that case. The hi.lo
>> format is probably enough of a special case that a separate specifier
>> for that one is unnecessary.
>
> Is the RPC code never used with a ipv6_addr_v4mapped address?
> ::192.168.0.1.1.1 would look pretty ugly
As I understand it, TI-RPC does not ever use mapped v4 addresses on
the wire (only pure IPv4 and IPv6). So they shouldn't actually appear
in the universal address format, in practice.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [RFC PATCH V2] lib/vsprintf.c: Add struct sockaddr * "%pN<foo>" output
From: Joe Perches @ 2009-08-19 22:36 UTC (permalink / raw)
To: Chuck Lever; +Cc: jens, brian.haley, David Miller, netdev
In-Reply-To: <6EE37F10-4354-49FE-9FF1-BB38BDD10E6E@oracle.com>
On Wed, 2009-08-19 at 18:20 -0400, Chuck Lever wrote:
> On Aug 19, 2009, at 4:44 PM, Joe Perches wrote:
> > I'm not too sure there's much value in ever more formatters for
> > relatively simple things or in printing something like port or
> > scope without the ip address.
> >
> > %hu ntohs(sa6->sin6_port)
> > or
> > %d or 0x%x ntohl(sa6->sin6_flowinfo)
> >
> > seem pretty straightforward to me.
>
> It's the same issue for port numbers as it is for addresses: though
> the port field is the same size in each, it's at different offsets in
> AF_INET and AF_INET6 addresses, so extra logic is still needed to sort
> that at each call site.
>
> As an example, an rpcbind query cares about the port number result,
> but usually not the address. A human-readable message could show the
> returned port number, but leave out the address. Without a separate
> formatter, you would still need extra logic around each debugging
> message (for example) to choose how to print the port number.
>
> You could probably argue, though, that this is a less common need than
> printing addresses.
I suppose an address exclude could be added to %pN
if really needed. Maybe "%pNx(specifiers)"
> > Here's another tentative patch that does both using square
> > brackets around IPv6 addresses with a port number and
> > allows selection of the port number style ":dddd" or ":hi.lo"
>
> The "hi.lo" form is always separated from the address by a dot, not by
> a colon, and square brackets are never used in that case. The hi.lo
> format is probably enough of a special case that a separate specifier
> for that one is unnecessary.
Is the RPC code never used with a ipv6_addr_v4mapped address?
::192.168.0.1.1.1 would look pretty ugly
> Having a hexadecimal port number option
> might be more useful. The hexadecimal form is also used by the
> kernel's RPC implementation, fwiw.
Easy enough. %pNhp or some such.
> > It also adds a "pI6n" form for IPv6 addresses with 7 colons
> > and no leading 0's.
> What would the 7 colons form be used for?
Shorter output requiring colon parsing, no :: parsing.
It's easier for humans to visually scan than the
leading 0 form.
^ permalink raw reply
* Re: [PATCH] ibm_newemac: emac_close() needs to call netif_carrier_off()
From: Petri Gynther @ 2009-08-19 22:32 UTC (permalink / raw)
To: shemminger; +Cc: David Miller, benh, netdev
In-Reply-To: <fc21faff0908191440p5db84f79h8bb8a73501facae1@mail.gmail.com>
Stephen,
I think your suggestion of adding netif_running() check to
bond_check_dev_link() is valid and a good fix to the bonding driver.
We can do this in a separate patch.
However, I think that the change to ibm_newemac: emac_close() is
needed as well. ibm_newemac netdevs should not return
netif_carrier_ok() == TRUE when they have been shut down.
On Wed, Aug 19, 2009 at 2:40 PM, Petri Gynther<pgynther@google.com> wrote:
> I agree with David. And, that's why I propose this diff for
> ibm_newemac driver as well.
>
> On Wed, Aug 19, 2009 at 2:34 PM, David Miller<davem@davemloft.net> wrote:
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Wed, 19 Aug 2009 14:11:36 -0700
>>
>>> On Wed, 19 Aug 2009 14:00:00 -0700 (PDT)
>>> Petri Gynther <pgynther@google.com> wrote:
>>>
>>>> When ibm_newemac netdev instance is shutdown with "ifconfig down",
>>>> the netdev interface does not go properly down. netif_carrier_ok()
>>>> keeps returning TRUE even after "ifconfig down".
>>>>
>>>> The problem can be seen when ibm_newemac instances are slaves of
>>>> a bonding interface. The bonding interface code uses netif_carrier_ok()
>>>> to determine the link status of its slaves. When ibm_newemac slave is
>>>> shutdown with "ifconfig down", the bonding interface won't detect any
>>>> link status change because netif_carrier_ok() keeps returning TRUE.
>>>
>>> Bonding should be testing for netif_running() && netif_carrier_ok().
>>>
>>> In many devices state of carrier is undefined when device is down.
>>
>> But if you check all of the drivers, ethernet in particular, the
>> convention is to call netif_carrier_off() in foo_close().
>>
>
^ permalink raw reply
* Re: [RFC PATCH V2] lib/vsprintf.c: Add struct sockaddr * "%pN<foo>" output
From: Chuck Lever @ 2009-08-19 22:20 UTC (permalink / raw)
To: Joe Perches; +Cc: jens, brian.haley, David Miller, netdev
In-Reply-To: <1250714657.3407.77.camel@Joe-Laptop.home>
On Aug 19, 2009, at 4:44 PM, Joe Perches wrote:
> On Wed, 2009-08-19 at 10:26 -0400, Chuck Lever wrote:
>> On Aug 16, 2009, at 12:10 AM, Joe Perches wrote:
>
>> I think having at least a generic socket address formatter would be
>> very helpful. The kernel RPC code can use that immediately for
>> generating debugging messages, generating "universal
>> addresses" (patches already accepted for 2.6.32) and for generating
>> presentation addresses to pass to user space (lockd does this now).
>
>>> Use style:
>>> * - 'N' For network socket (sockaddr) pointers
>>> * if sa_family is IPv4, output is %pI4; if IPv6, output is
>>> %pI6c
>>> * May be used with any combination of additional specifiers
>>> below
>>> * 'p' decimal socket port number for IPv[46]: ":12345"
>>> * 'f' decimal flowinfo for IPv6: "/123456789"
>>> * 's' decimal scope_id number for IPv6: "%1234567890"
>>> * so %pNp will print if IPv4 "1.2.3.4:1234", if IPv6:
>>> "1::c0a8:a:1234"
>>>
>>> I think using ":" as the separator for the port number, while
>>> common,
>>> and already frequently used in kernel source (see bullet 2 in):
>>> http://www.ietf.org/id/draft-kawamura-ipv6-text-
>>> representation-03.txt
>>> "Section 6: Notes on Combining IPv6 Addresses with Port Numbers".
>>> is not good for readability.
>>>
>>> Perhaps this style should be changed to the "[ipv6]:port" described
>>> in the draft above.
>>
>> I agree that the port number convention is tricky, and some kernel
>> areas handle it differently than others. Perhaps having a separate
>> family-agnostic formatter for printing the port number (or scope ID,
>> etc.) might allow greatest flexibility.
>
> I'm not too sure there's much value in ever more formatters for
> relatively simple things or in printing something like port or
> scope without the ip address.
>
> %hu ntohs(sa6->sin6_port)
> or
> %d or 0x%x ntohl(sa6->sin6_flowinfo)
>
> seem pretty straightforward to me.
It's the same issue for port numbers as it is for addresses: though
the port field is the same size in each, it's at different offsets in
AF_INET and AF_INET6 addresses, so extra logic is still needed to sort
that at each call site.
As an example, an rpcbind query cares about the port number result,
but usually not the address. A human-readable message could show the
returned port number, but leave out the address. Without a separate
formatter, you would still need extra logic around each debugging
message (for example) to choose how to print the port number.
You could probably argue, though, that this is a less common need than
printing addresses.
>> The RPC code, for example, displays port numbers in decimal and in
>> "hi.lo" format (the high byte is printed in decimal, then the low
>> byte
>> is printed in decimal. The two values are separated by a dot. For
>> example, port 2049 is displayed as "8.1").
>
> Here's another tentative patch that does both using square
> brackets around IPv6 addresses with a port number and
> allows selection of the port number style ":dddd" or ":hi.lo"
The "hi.lo" form is always separated from the address by a dot, not by
a colon, and square brackets are never used in that case. The hi.lo
format is probably enough of a special case that a separate specifier
for that one is unnecessary. Having a hexadecimal port number option
might be more useful. The hexadecimal form is also used by the
kernel's RPC implementation, fwiw.
> It also adds a "pI6n" form for IPv6 addresses with 7 colons
> and no leading 0's.
What would the 7 colons form be used for?
> lib/vsprintf.c: Add '%pN' print formatted struct sock_addr *
>
> Use styles:
> * - 'N' For network socket (sockaddr) pointers
> * if sa_family is IPv4, output is %pI4; if IPv6, output is %pI6c
> * May be used with any combination of additional specifiers
> below
> * 'p' decimal socket port number for IPv[46]: ":12345"
> * 'P' decimal socket port number for IPv6: ":1.255" (hi.lo)
> * if IPv6 and port number is selected, square brackets
> * will surround the IPv6 address for 'p' and 'P'
> * 'f' decimal flowinfo for IPv6: "/123456789"
> * 's' decimal scope_id number for IPv6: "%1234567890"
> * %pNp will print IPv4: "1.2.3.4:1234"
> * IPv6: "[1::c0a8:a]:1234"
> * %pNP will print IPv4: "1.2.3.4:1.255
> * IPv6: "[1::c0a8:a]:1.255"
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index cb8a112..139f310 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -647,22 +647,73 @@ static char *mac_address_string(char *buf,
> char *end, u8 *addr,
> return string(buf, end, mac_addr, spec);
> }
>
> -static char *ip4_string(char *p, const u8 *addr, bool leading_zeros)
> +static char *u8_to_dec(char *p, u8 val, bool leadingzeros)
> +{
> + char temp[3]; /* holds val in reverse order */
> + int digits = put_dec_trunc(temp, val) - temp;
> +
> + if (leadingzeros) {
> + if (digits < 3)
> + *p++ = '0';
> + if (digits < 2)
> + *p++ = '0';
> + }
> + /* reverse the digits */
> + while (digits--)
> + *p++ = temp[digits];
> +
> + return p;
> +}
> +
> +static char *u16_to_hex(char *p, u16 word, bool leadingzeros)
> +{
> + u8 hi = word >> 8;
> + u8 lo = word & 0xff;
> + if (leadingzeros) {
> + p = pack_hex_byte(p, hi);
> + p = pack_hex_byte(p, lo);
> + } else {
> + if (hi) {
> + if (hi > 0x0f)
> + p = pack_hex_byte(p, hi);
> + else
> + *p++ = hex_asc_lo(hi);
> + }
> + if (hi || lo > 0x0f)
> + p = pack_hex_byte(p, lo);
> + else
> + *p++ = hex_asc_lo(lo);
> + }
> +
> + return p;
> +}
> +
> +static char *u32_dec_val(char *p, u32 val)
> +{
> + char temp[9]; /* holds val in reverse order */
> + int digits;
> + char *pos;
> +
> + if (val < 100000)
> + pos = put_dec_trunc(temp, val);
> + else {
> + pos = put_dec_trunc(temp, val % 100000);
> + pos = put_dec_trunc(pos, val / 100000);
> + }
> + digits = pos - temp;
> + /* reverse the digits */
> + while (digits--)
> + *p++ = temp[digits];
> +
> + return p;
> +}
> +
> +static char *ip4_string(char *p, const u8 *addr, bool leadingzeros)
> {
> int i;
>
> for (i = 0; i < 4; i++) {
> - char temp[3]; /* hold each IP quad in reverse order */
> - int digits = put_dec_trunc(temp, addr[i]) - temp;
> - if (leading_zeros) {
> - if (digits < 3)
> - *p++ = '0';
> - if (digits < 2)
> - *p++ = '0';
> - }
> - /* reverse the digits in the quad */
> - while (digits--)
> - *p++ = temp[digits];
> + p = u8_to_dec(p, addr[i], leadingzeros);
> if (i < 3)
> *p++ = '.';
> }
> @@ -679,9 +730,6 @@ static char *ip6_compressed_string(char *p,
> const struct in6_addr *addr)
> unsigned char zerolength[8];
> int longest = 1;
> int colonpos = -1;
> - u16 word;
> - u8 hi;
> - u8 lo;
> bool needcolon = false;
> bool useIPv4 = ipv6_addr_v4mapped(addr) || ipv6_addr_is_isatap(addr);
>
> @@ -721,20 +769,7 @@ static char *ip6_compressed_string(char *p,
> const struct in6_addr *addr)
> *p++ = ':';
> needcolon = false;
> }
> - /* hex u16 without leading 0s */
> - word = ntohs(addr->s6_addr16[i]);
> - hi = word >> 8;
> - lo = word & 0xff;
> - if (hi) {
> - if (hi > 0x0f)
> - p = pack_hex_byte(p, hi);
> - else
> - *p++ = hex_asc_lo(hi);
> - }
> - if (hi || lo > 0x0f)
> - p = pack_hex_byte(p, lo);
> - else
> - *p++ = hex_asc_lo(lo);
> + p = u16_to_hex(p, ntohs(addr->s6_addr16[i]), false);
> needcolon = true;
> }
>
> @@ -751,9 +786,10 @@ static char *ip6_compressed_string(char *p,
> const struct in6_addr *addr)
> static char *ip6_string(char *p, const struct in6_addr *addr, const
> char *fmt)
> {
> int i;
> + bool leadingzeros = !(fmt[0] == 'I' && fmt[2] == 'n');
> +
> for (i = 0; i < 8; i++) {
> - p = pack_hex_byte(p, addr->s6_addr[2 * i]);
> - p = pack_hex_byte(p, addr->s6_addr[2 * i + 1]);
> + p = u16_to_hex(p, ntohs(addr->s6_addr16[i]), leadingzeros);
> if (fmt[0] == 'I' && i != 7)
> *p++ = ':';
> }
> @@ -785,6 +821,102 @@ static char *ip4_addr_string(char *buf, char
> *end, const u8 *addr,
> return string(buf, end, ip4_addr, spec);
> }
>
> +static char *port_string(char *p, u16 port, const char *fmt)
> +{
> + if (*fmt == 'p')
> + p = u32_dec_val(p, port);
> + else {
> + p = u8_to_dec(p, port >> 8, false);
> + *p++ = '.';
> + p = u8_to_dec(p, port & 0xff, false);
> + }
> +
> + return p;
> +}
> +
> +static char *socket_addr_string(char *buf, char *end,
> + const struct sockaddr *sa,
> + struct printf_spec spec, const char *fmt)
> +{
> + char baddress[sizeof("[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:
> 255.255.255.255]"
> + ":255.255" /* port # or :12345 */
> + "%1234567890" /* IPv6 scope id */
> + "/123456789")]; /* IPv6 flow mask */
> + char *p;
> + char *addr;
> + struct sockaddr_in *sa4 = (struct sockaddr_in *)sa;
> + struct sockaddr_in6 *sa6 = (struct sockaddr_in6 *)sa;
> +
> + /* Start with a bracket in case the address is IPv6 with a port # */
> + baddress[0] = '[';
> + addr = &baddress[1]; /* address without leading '[' */
> + p = addr;
> +
> + switch (sa->sa_family) {
> + case AF_INET:
> + p = ip4_string(addr, (const u8 *)&sa4->sin_addr.s_addr, false);
> + break;
> + case AF_INET6:
> + p = ip6_compressed_string(addr, &sa6->sin6_addr);
> + break;
> + default: {
> + struct printf_spec num_spec = {
> + .base = 16,
> + .precision = -1,
> + .field_width = 2 * sizeof(void *),
> + .flags = SPECIAL | SMALL | ZEROPAD,
> + };
> + size_t msglen;
> +
> + p = strcpy(baddress, "Bad socket address: ");
> + msglen = strlen(p);
> + p = number(p + msglen, p + sizeof(baddress) - msglen,
> + (unsigned long)sa, num_spec);
> + break;
> + }
> + }
> +
> + while (isalpha(*++fmt)) {
> + switch (*fmt) {
> + case 'p':
> + case 'P':
> + switch (sa->sa_family) {
> + case AF_INET:
> + *p++ = ':';
> + p = port_string(p, ntohs(sa4->sin_port), fmt);
> + break;
> + case AF_INET6:
> + /* Use the initial bracket */
> + if (addr > baddress)
> + addr--;
> + *p++ = ']';
> + *p++ = ':';
> + p = port_string(p, ntohs(sa6->sin6_port), fmt);
> + break;
> + }
> + break;
> + case 's':
> + switch (sa->sa_family) {
> + case AF_INET6:
> + *p++ = '%';
> + p = u32_dec_val(p, sa6->sin6_scope_id);
> + }
> + break;
> + case 'f':
> + switch (sa->sa_family) {
> + case AF_INET6:
> + *p++ = '/';
> + p = u32_dec_val(p, ntohl(sa6->sin6_flowinfo &
> + IPV6_FLOWINFO_MASK));
> + }
> + break;
> + }
> + }
> +
> + *p = '\0';
> + return string(buf, end, addr, spec);
> +}
> +
> /*
> * Show a '%p' thing. A kernel extension is that the '%p' is followed
> * by an extra set of alphanumeric characters that are extended format
> @@ -808,6 +940,15 @@ static char *ip4_addr_string(char *buf, char
> *end, const u8 *addr,
> * IPv4 uses dot-separated decimal with leading 0's
> (010.123.045.006)
> * - 'I6c' for IPv6 addresses printed as specified by
> * http://www.ietf.org/id/draft-kawamura-ipv6-text-representation-03.txt
> + * - 'I6n' IPv6: colon separated network-order 16 bit hex without
> leading 0's
> + * - 'N' For network socket (sockaddr) pointers
> + * if sa_family is IPv4, output is %pI4; if IPv6, output is
> %pI6c
> + * May be used with any combination of additional specifiers
> below
> + * 'p' decimal socket port number for IPv[46]: ":12345"
> + * 'P' decimal socket port numbers using hi/lo u8: ":0.255"
> + * 's' decimal scope_id number for IPv6: "%123456789"
> + * 'f' decimal flowinfo for IPv6: "/123456789"
> + * so %pNp will print if IPv4 "1.2.3.4:1234", if IPv6:
> "[1::c0a8:a]:1234"
> * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
> * function pointers are really function descriptors, which contain a
> * pointer to the real address.
> @@ -834,6 +975,7 @@ static char *pointer(const char *fmt, char *buf,
> char *end, void *ptr,
> * 4: 1.2.3.4
> * 6: 0001:0203:...:0708
> * 6c: 1::708 or 1::1.2.3.4
> + * 6n: 1:2:3:0:0:0:789:abcd
> */
> case 'i': /* Contiguous:
> * 4: 001.002.003.004
> @@ -846,7 +988,10 @@ static char *pointer(const char *fmt, char
> *buf, char *end, void *ptr,
> return ip4_addr_string(buf, end, ptr, spec, fmt);
> }
> break;
> + case 'N':
> + return socket_addr_string(buf, end, ptr, spec, fmt);
> }
> +
> spec.flags |= SMALL;
> if (spec.field_width == -1) {
> spec.field_width = 2*sizeof(void *);
>
>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: configfs/sysfs
From: Joel Becker @ 2009-08-19 22:16 UTC (permalink / raw)
To: Avi Kivity
Cc: Nicholas A. Bellinger, Ingo Molnar, Anthony Liguori, kvm,
alacrityvm-devel, linux-kernel, netdev, Michael S. Tsirkin,
Ira W. Snyder
In-Reply-To: <4A8C5CBB.10605@redhat.com>
On Wed, Aug 19, 2009 at 11:12:43PM +0300, Avi Kivity wrote:
> On 08/19/2009 09:23 PM, Nicholas A. Bellinger wrote:
> >Anyways, I was wondering if you might be interesting in sharing your
> >concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
>
> My concerns aren't specifically with configfs, but with all the text
> based pseudo filesystems that the kernel exposes.
Phew! It's not just me :-)
> My high level concern is that we're optimizing for the active
> sysadmin, not for libraries and management programs. configfs and
> sysfs are easy to use from the shell, discoverable, and easily
> scripted. But they discourage documentation, the text format is
> ambiguous, and they require a lot of boilerplate to use in code.
I don't think they "discourage documentation" anymore than any
ioctl we've ever had. At least you can look at the names and values and
take a good stab at it (configfs is better than sysfs at this, by virtue
of what it does, but discoverability is certainly not as good as real
documentation).
With an ioctl() that isn't (well) documented, you have to go
read the structure and probably even read the code that uses the
structure to be sure what you are doing.
> You could argue that you can wrap *fs in a library that hides the
> details of accessing it, but that's the wrong approach IMO. We
> should make the information easy to use and manipulate for programs;
> one of these programs can be a fuse filesystem for the active
> sysadmin if someone thinks it's important.
You are absolutely correct that they are a boon to the sysadmin,
where in theory programs can do better with binary interfaces. Except
what programs? I can't do an ioctl or a syscall from a shell script
(no, using bash's network capabilities to talk to netlink does not
count). Same with perl/python/whatever where you have to write
boilerplate to create binary structures.
These interfaces have two opposing forces acting on them. They
provide a reasonably nice way to cross the user<->kernel boundary, so
people want to use them. Programmatic things, like a power management
daemon for example, don't want sysadmins touching anything. It's just
an interface for the daemon. Conversely, some things are really knobs
for the sysadmin. There's nothing else to it. Why should they have to
code up a C program just to turn a knob? Configfs, as its name implies,
really does exist for that second case. It turns out that it's quite
nice to use for the first case too, but if folks wanted to go the
syscall route, no worries.
I've said it many times. We will never come up with one
over-arching solution to all the disparate use cases. Instead, we
should use each facility - syscalls, ioctls, sysfs, configfs, etc - as
appropriate. Even in the same program or subsystem.
> - atomicity
>
> One attribute per file means that, lacking userspace-visible
> transactions, there is no way to change several attributes at once.
> When you read attributes, there is no way to read several attributes
> atomically so you can be sure their values correlate. Another
> example of a problem is when an object disappears while reading its
> attributes. Sure, openat() can mitigate this, but it's better to
> avoid introducing problem than having a fix.
configfs has some atomicity capabilities, but not full
atomicity. It's not the right too for that sort of thing.
> - ambiguity
>
> What format is the attribute? does it accept lowercase or uppercase
> hex digits? is there a newline at the end? how many digits can it
> take before the attribute overflows? All of this has to be
> documented and checked by the OS, otherwise we risk regressions
> later. In contrast, __u64 says everything in a binary interface.
Um, is that __u64 a pointer to a userspace object? A key to a
lookup table? A file descriptor that is padded out? It's no less
ambiguous.
> - lifetime and access control
>
> If a process brings an object into being (using mkdir) and then
> dies, the object remains behind. The syscall/ioctl approach ties
> the object into an fd, which will be destroyed when the process
> dies, and which can be passed around using SCM_RIGHTS, allowing a
> server process to create and configure an object before passing it
> to an unprivileged program
Most things here do *not* want to be tied to the lifetime of one
process. We don't want our cpu_freq governor changing just because the
power manager died.
> You may argue, correctly, that syscalls and ioctls are not as
> flexible. But this is because no one has invested the effort in
> making them so. A struct passed as an argument to a syscall is not
> extensible. But if you pass the size of the structure, and also a
> bitmap of which attributes are present, you gain extensibility and
> retain the atomicity property of a syscall interface. I don't think
> a lot of effort is needed to make an extensible syscall interface
> just as usable and a lot more efficient than configfs/sysfs. It
> should also be simple to bolt a fuse interface on top to expose it
> to us commandline types.
Your extensible syscall still needs to be known. The
flexibility provided by configfs and sysfs is of generic access to
non-generic things. It's different.
The follow-ups regarding the perf_counter call are a good
example. If you know the perf_counter call, you can code up a C program
that asks what attributes or things are there. But if you don't, you've
first got to find out that there's a perf_counter call, then learn how
to use it. With configfs/sysfs, you notice that there's now a
perf_counter directory under a tree, and you can figure out what
attributes and items are there.
But this is not the be-all-end-all. Our syscalls should be more
flexible in the perf_counter way. Not everything really needs to be
listable by some yokel sysadmin.
> configfs is more maintainable that a bunch of hand-maintained
> ioctls. But if we put some effort into an extendable syscall
> infrastructure (perhaps to the point of using an IDL) I'm sure we
> can improve on that without the problems pseudo filesystems
> introduce.
Oh, boy, IDL :-) Seriously, if you can solve the "how do I just
poke around without actually writing C code or installing a
domain-specific binary" problem, you will probably get somewhere.
> I can't really fault a project for using configfs; it's an accepted
> and recommented (by the community) interface. I'd much prefer it
> though if there was an effort to create a usable fd/struct based
> alternative.
Oh, and configfs was explicitly designed to be interface
agnostic to the client. The filesystem portions, to the best of my
ability, are not exposed to client drivers. So you can replace the
configfs filesystem interface with a system call set that does the same
operations, and no configfs user will actually need to change their
code (if you want to change from text values to non-text, that would
require changing the show/store operation prototypes, but that's about
it).
Joel
--
A good programming language should have features that make the
kind of people who use the phrase "software engineering" shake
their heads disapprovingly.
- Paul Graham
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: configfs/sysfs
From: Gregory Haskins @ 2009-08-19 22:15 UTC (permalink / raw)
To: Avi Kivity
Cc: Nicholas A. Bellinger, Ingo Molnar, Anthony Liguori, kvm,
alacrityvm-devel, linux-kernel, netdev, Michael S. Tsirkin,
Ira W. Snyder, Joel Becker
In-Reply-To: <4A8C5CBB.10605@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 11227 bytes --]
Avi Kivity wrote:
> On 08/19/2009 09:23 PM, Nicholas A. Bellinger wrote:
>> Anyways, I was wondering if you might be interesting in sharing your
>> concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
>>
>
> My concerns aren't specifically with configfs, but with all the text
> based pseudo filesystems that the kernel exposes.
>
> My high level concern is that we're optimizing for the active sysadmin,
> not for libraries and management programs. configfs and sysfs are easy
> to use from the shell, discoverable, and easily scripted. But they
> discourage documentation, the text format is ambiguous, and they require
> a lot of boilerplate to use in code.
>
> You could argue that you can wrap *fs in a library that hides the
> details of accessing it, but that's the wrong approach IMO. We should
> make the information easy to use and manipulate for programs; one of
> these programs can be a fuse filesystem for the active sysadmin if
> someone thinks it's important.
>
> Now for the low level concerns:
>
> - efficiency
>
> Each attribute access requires an open/read/close triplet and
> binary->ascii->binary conversions. In contrast an ordinary
> syscall/ioctl interface can fetch all attributes of an object, or even
> all attributes of all objects, in one call.
I can only speak for vbus, but *fs access efficiency is not a problem.
Its all slow-path anyway.
>
> - atomicity
>
> One attribute per file means that, lacking userspace-visible
> transactions, there is no way to change several attributes at once.
Actually, I do think configfs has some rudimentary, but incomplete IIUC,
support for transactional commits of updates. In lieu of formal
support, this is also not generally a problem: You can just put your
own transaction in by the form of an explicit attribute. For instance,
see the "enabled" attribute in venet-tap. This lets you set all the
parameters and then hit "enabled" to turn it act on the other settings
atomically.
For sysfs kernel updates, I think you can update the values under a
lock. For sysfs userspace updates, I suppose you could do a similar
"explicit commit" attribute if it was needed.
> When you read attributes, there is no way to read several attributes
> atomically so you can be sure their values correlate.
This isn't a valid concern for configfs, unless you have multiple
userspace applications updating concurrently. IIUC, configfs is only
changed by userspace, not the kernel. So I suppose if you were
concerned about supporting this, you could use an advisory flock or
something.
For sysfs, this is a valid concern. Generally, I do not think *fs
interfaces are a good match if you need that type of behavior (atomic
read of rapidly changing attributes), however. FWIW, vbus does not need
this (the parameters do not generally change once established).
> Another example
> of a problem is when an object disappears while reading its attributes.
> Sure, openat() can mitigate this, but it's better to avoid introducing
> problem than having a fix.
Again, that can only happen if another userspace app did that to you.
Possible solutions might be advisory locking.
>
> - ambiguity
>
> What format is the attribute? does it accept lowercase or uppercase hex
> digits? is there a newline at the end? how many digits can it take
> before the attribute overflows? All of this has to be documented and
> checked by the OS, otherwise we risk regressions later. In contrast,
> __u64 says everything in a binary interface.
I don't think this is a legit concern. I would thing you have to
understand the ABI to use the interface regardless, no matter the
transport. And either way, the kernel has to validate the input.
>
> - lifetime and access control
>
> If a process brings an object into being (using mkdir) and then dies,
> the object remains behind.
This is one of the big problems with configfs, I agree. I guess you
could argue that the ioctl approach has the opposite problem (resource
goes if the owner goes), which is to say it requires the app to hang
around. Syscall is kind of in the middle, since it doesn't expressly
have a policy against a given resource if a task dies. You can
certainly modify kernel/exit.c to add such a policy, I suppose. But
ioctl has a distinct advantage in this regard.
All in all, I think ioctl wins here.
> The syscall/ioctl approach ties the object
> into an fd, which will be destroyed when the process dies, and which can
> be passed around using SCM_RIGHTS, allowing a server process to create
> and configure an object before passing it to an unprivileged program
>
> - notifications
>
> It's hard to notify users about changes in attributes. Sure, you can
> use inotify, but that limits you to watching subtrees.
Whats worse, inotify doesn't seem to work very well against *fs from
what I hear.
> Once you do get
> the notification, you run into the atomicity problem. When do you know
> all attributes are valid? This can be solved using sequence counters,
> but that's just gratuitous complexity. Netlink type interfaces are much
> more robust and flexible.
>
> - readdir
>
> You can either list everything, or nothing. Sure, you can have trees to
> ease searching, even multiple views of the same data, but it's painful.
I do not see the problem here. *fs structures dirs as objects, and
files as attributes. A logical presentation of the data from that
perspective ensues. Why is "readdir" a problem? It gets all the
attributes of an "object" (sans potential consistency problems, as you
point out above).
>
> You may argue, correctly, that syscalls and ioctls are not as flexible.
> But this is because no one has invested the effort in making them so. A
> struct passed as an argument to a syscall is not extensible. But if you
> pass the size of the structure, and also a bitmap of which attributes
> are present, you gain extensibility and retain the atomicity property of
> a syscall interface. I don't think a lot of effort is needed to make an
> extensible syscall interface just as usable and a lot more efficient
> than configfs/sysfs. It should also be simple to bolt a fuse interface
> on top to expose it to us commandline types.
I think the strongest argument about having *fs like models, is its a
way to keep the "management tool" coupled with the kernel that
understands it. This is quite nice in practice.
Its true that the interface exposed by *fs could be construed as an
"ABI", but that is generally more of an issue for userspace tools that
would turn around and read it, as opposed to a human sitting at the
shell. So therefore, both *fs and syscall/ioctl approaches suffer from
ABI mis-sync issues w.r.t. tools. But the *fs wins here because
generally a human can adapt dynamically to the change (e.g. by running
'tree' and looking for something recognizable), whereas syscall/ioctl
have no choice...they are hosed.
It's true you could make an extensible syscall/ioctl interface, but do
note you can use similar techniques (e.g. only add new attributes to
existing objects) on the *fs front as well. So to me it comes down to
more or less the lifetime question (ioctl wins), vs the
auto-synchronized tool (*fs wins) benefit. I am honestly not sure what
is better.
>
>> As you may recall, I have been using configfs extensively for the 3.x
>> generic target core infrastructure and iSCSI fabric modules living in
>> lio-core-2.6.git/drivers/target/target_core_configfs.c and
>> lio-core-2.6.git/drivers/lio-core/iscsi_target_config.c, and have found
>> it to be extraordinarly useful for the purposes of a implementing a
>> complex kernel level target mode stack that is expected to manage
>> massive amounts of metadata, allow for real-time configuration, share
>> data structures (eg: SCSI Target Ports) between other kernel fabric
>> modules and manage the entire set of fabrics using only intrepetered
>> userspace code.
>>
>> Using the 10000 1:1 mapped TCM Virtual HBA+FILEIO LUNs<-> iSCSI Target
>> Endpoints inside of a KVM Guest (from the results in May posted with
>> IOMMU aware 10 Gb on modern Nahelem hardware, see
>> http://linux-iscsi.org/index.php/KVM-LIO-Target), we have been able to
>> dump the entire running target fabric configfs hierarchy to a single
>> struct file on a KVM Guest root device using python code on the order of
>> ~30 seconds for those 10000 active iSCSI endpoints. In configfs terms,
>> this means:
>>
>> *) 7 configfs groups (directories), ~50 configfs attributes (files) per
>> Virtual HBA+FILEIO LUN
>> *) 15 configfs groups (directories), ~60 configfs attributes (files per
>> iSCSI fabric Endpoint
>>
>> Which comes out to a total of ~220000 groups and ~1100000 attributes
>> active configfs objects living in the configfs_dir_cache that are being
>> dumped inside of the single KVM guest instances, including symlinks
>> between the fabric modules to establish the SCSI ports containing
>> complete set of SPC-4 and RFC-3720 features, et al.
>>
>
> You achieved 3 million syscalls/sec from Python code? That's very
> impressive.
>
> Note with syscalls you could have done it with 10K syscalls (Python
> supports packing and unpacking structs quite well, and also directly
> calling C code IIRC).
>
>> Also on the kernel<-> user API interaction compatibility side, I have
>> found the 3.x configfs enabled code adventagous over the LIO 2.9 code
>> (that used an ioctl for everything) because it allows us to do backwards
>> compat for future versions without using any userspace C code, which in
>> IMHO makes maintaining userspace packages for complex kernel stacks with
>> massive amounts of metadata + real-time configuration considerations.
>> No longer having ioctl compatibility issues between LIO versions as the
>> structures passed via ioctl change, and being able to do backwards
>> compat with small amounts of interpreted code against configfs layout
>> changes makes maintaining the kernel<-> user API really have made this
>> that much easier for me.
>>
>
> configfs is more maintainable that a bunch of hand-maintained ioctls.
> But if we put some effort into an extendable syscall infrastructure
> (perhaps to the point of using an IDL) I'm sure we can improve on that
> without the problems pseudo filesystems introduce.
>
>> Anyways, I though these might be useful to the discussion as it releates
>> to potental uses of configfs on the KVM Host or other projects that
>> really make sense, and/or to improve the upstream implementation so that
>> other users (like myself) can benefit from improvements to configfs.
>>
>
> I can't really fault a project for using configfs; it's an accepted and
> recommented (by the community) interface. I'd much prefer it though if
> there was an effort to create a usable fd/struct based alternative.
Yeah, doing it manually with all the CAP bits gets old, fast, so I agree
that improvement here is welcome.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Mike McCormack @ 2009-08-19 22:05 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <200908192307.22112.rene.mayrhofer@gibraltar.at>
2009/8/20 Rene Mayrhofer <rene.mayrhofer@gibraltar.at>:
> Pulling the latest sky2.c and sky2.h from net-next-2.6 and applying the patch
> rids me of the oops - it is unreproducible right now. However, a networking
> restart (i.e. all interfaces attached to sky2) leaves the devices in a state
> where they no longer receive any network packets (at least nothing visible in
> tcpdump). In this state, rmmod sky2 / modprobe sky2 gives:
After you've got it into that state, does "rmmod sky2; modprobe sky2"
change anything?
thanks,
Mike
^ permalink raw reply
* Re: AX.25 devices on USB ?
From: Alan Cox @ 2009-08-19 21:48 UTC (permalink / raw)
To: Matti Aarnio; +Cc: linux-ax25, netdev, linux-usb
In-Reply-To: <20090819204125.GB30210@mea-ext.zmailer.org>
> I do think that it needs to be some sort of "Communications Device Class"
> thing, but what kind of ? I really do not want to put virtual serial ports
> and KISS encapsulation in there... (Those not familar with Radio Amateur
> protocols, KISS is variation of SLIP with a hook to handle couple link-layer
> control functions, plus multiplexing multiple devices on single serial port.)
The KISS serial interface is also used for all sorts of configuration
functions on some devices. Assuming the congestion algorithms are done in
the USB device then you'd need a control interface and a network
interface of some sort.
> On USB CDC specification part 4.7 there is a table of "Data Interface Class
> Protocol Codes" -- and there code 31h: "HDLC" would probably be what engineer
> orders for all manner of radio amateur data protocols.
> (That use packets to begin with.)
AX.25 is basically LAP-B over HDLC but the bitstuffing is generally done
by the controller (hence the use of KISS etc). Not all amateur protocols
are HDLC - the Karn FEC encodings (Viterbi etc) for example.
> Any ideas ?
I would use ethernet. There are semi-standards for AX.25 over Ethernet
frames (BPQ) which Linux can talk. If you dump everything but BPQ protocol
frames and perhaps purloin another protocol id for control frames that
should give you everything you need without a line of Linux side kernel
code.
If you wanted to be really crazy then you could teach your firmware to
also re-encap/de-cap IP frames in ethernet format to/from AX.25 UI
headers and likewise for ARP, at which point it might even work on
Windows without a driver - at least for IP ;)
Alan
^ permalink raw reply
* Re: mlx4 2.6.31-rc5: SW2HW_EQ failed.
From: Roland Dreier @ 2009-08-19 21:42 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev, Yevgeny Petrilin
In-Reply-To: <alpine.DEB.1.10.0908191135110.32015@gentwo.org>
I took another look at the patch I sent and found a couple of bugs in it
(seems original authors didn't really test on a system with 32 CPUs).
Anyway the patch below seems to work on a test system with 32 possible
CPUs (including unloading).
Let me know how it works for you.
Thanks,
Roland
commit 75e8522a04e982623d67b959d2e545974f36c323
Author: Eli Cohen <eli@mellanox.co.il>
Date: Wed Aug 19 14:15:59 2009 -0700
mlx4_core: Allocate and map sufficient ICM memory for EQ context
The current implementation allocates a single host page for EQ context
memory, which was OK when we only allocated a few EQs. However, since
we now allocate an EQ for each CPU core, this patch removes the
hard-coded limit and makes the allocation depend on EQ entry size and
the number of required EQs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
diff --git a/drivers/net/mlx4/eq.c b/drivers/net/mlx4/eq.c
index c11a052..fffe1ea 100644
--- a/drivers/net/mlx4/eq.c
+++ b/drivers/net/mlx4/eq.c
@@ -529,31 +529,46 @@ int mlx4_map_eq_icm(struct mlx4_dev *dev, u64 icm_virt)
{
struct mlx4_priv *priv = mlx4_priv(dev);
int ret;
+ int host_pages;
+ unsigned off;
- /*
- * We assume that mapping one page is enough for the whole EQ
- * context table. This is fine with all current HCAs, because
- * we only use 32 EQs and each EQ uses 64 bytes of context
- * memory, or 1 KB total.
- */
+ host_pages = PAGE_ALIGN(min_t(int, dev->caps.num_eqs, num_possible_cpus() + 1) *
+ dev->caps.eqc_entry_size) >> PAGE_SHIFT;
+ priv->eq_table.order = order_base_2(host_pages);
priv->eq_table.icm_virt = icm_virt;
- priv->eq_table.icm_page = alloc_page(GFP_HIGHUSER);
- if (!priv->eq_table.icm_page)
- return -ENOMEM;
+ priv->eq_table.icm_page = alloc_pages(GFP_HIGHUSER, priv->eq_table.order);
+ if (!priv->eq_table.icm_page) {
+ ret = -ENOMEM;
+ goto err;
+ }
priv->eq_table.icm_dma = pci_map_page(dev->pdev, priv->eq_table.icm_page, 0,
- PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ PAGE_SIZE << priv->eq_table.order,
+ PCI_DMA_BIDIRECTIONAL);
if (pci_dma_mapping_error(dev->pdev, priv->eq_table.icm_dma)) {
- __free_page(priv->eq_table.icm_page);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_free;
}
- ret = mlx4_MAP_ICM_page(dev, priv->eq_table.icm_dma, icm_virt);
- if (ret) {
- pci_unmap_page(dev->pdev, priv->eq_table.icm_dma, PAGE_SIZE,
- PCI_DMA_BIDIRECTIONAL);
- __free_page(priv->eq_table.icm_page);
+ for (off = 0; off < PAGE_SIZE << priv->eq_table.order; off += MLX4_ICM_PAGE_SIZE) {
+ ret = mlx4_MAP_ICM_page(dev, priv->eq_table.icm_dma + off,
+ icm_virt + off);
+ if (ret)
+ goto err_unmap;
}
+ return 0;
+
+err_unmap:
+ if (off)
+ mlx4_UNMAP_ICM(dev, priv->eq_table.icm_virt, off / MLX4_ICM_PAGE_SIZE);
+ pci_unmap_page(dev->pdev, priv->eq_table.icm_dma,
+ PAGE_SIZE << priv->eq_table.order,
+ PCI_DMA_BIDIRECTIONAL);
+
+err_free:
+ __free_pages(priv->eq_table.icm_page, priv->eq_table.order);
+
+err:
return ret;
}
@@ -561,10 +576,11 @@ void mlx4_unmap_eq_icm(struct mlx4_dev *dev)
{
struct mlx4_priv *priv = mlx4_priv(dev);
- mlx4_UNMAP_ICM(dev, priv->eq_table.icm_virt, 1);
- pci_unmap_page(dev->pdev, priv->eq_table.icm_dma, PAGE_SIZE,
- PCI_DMA_BIDIRECTIONAL);
- __free_page(priv->eq_table.icm_page);
+ mlx4_UNMAP_ICM(dev, priv->eq_table.icm_virt,
+ (PAGE_SIZE / MLX4_ICM_PAGE_SIZE) << priv->eq_table.order);
+ pci_unmap_page(dev->pdev, priv->eq_table.icm_dma,
+ PAGE_SIZE << priv->eq_table.order, PCI_DMA_BIDIRECTIONAL);
+ __free_pages(priv->eq_table.icm_page, priv->eq_table.order);
}
int mlx4_alloc_eq_table(struct mlx4_dev *dev)
diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
index 5c1afe0..474d1f3 100644
--- a/drivers/net/mlx4/main.c
+++ b/drivers/net/mlx4/main.c
@@ -207,6 +207,7 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
dev->caps.max_cqes = dev_cap->max_cq_sz - 1;
dev->caps.reserved_cqs = dev_cap->reserved_cqs;
dev->caps.reserved_eqs = dev_cap->reserved_eqs;
+ dev->caps.eqc_entry_size = dev_cap->eqc_entry_sz;
dev->caps.mtts_per_seg = 1 << log_mtts_per_seg;
dev->caps.reserved_mtts = DIV_ROUND_UP(dev_cap->reserved_mtts,
dev->caps.mtts_per_seg);
diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h
index 5bd79c2..34bcc11 100644
--- a/drivers/net/mlx4/mlx4.h
+++ b/drivers/net/mlx4/mlx4.h
@@ -210,6 +210,7 @@ struct mlx4_eq_table {
dma_addr_t icm_dma;
struct mlx4_icm_table cmpt_table;
int have_irq;
+ int order;
u8 inta_pin;
};
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index ce7cc6c..8923c9b 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -206,6 +206,7 @@ struct mlx4_caps {
int max_cqes;
int reserved_cqs;
int num_eqs;
+ int eqc_entry_size;
int reserved_eqs;
int num_comp_vectors;
int num_mpts;
^ permalink raw reply related
* Re: [PATCH] ibm_newemac: emac_close() needs to call netif_carrier_off()
From: Petri Gynther @ 2009-08-19 21:40 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, benh, netdev
In-Reply-To: <20090819.143403.27319428.davem@davemloft.net>
I agree with David. And, that's why I propose this diff for
ibm_newemac driver as well.
On Wed, Aug 19, 2009 at 2:34 PM, David Miller<davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 19 Aug 2009 14:11:36 -0700
>
>> On Wed, 19 Aug 2009 14:00:00 -0700 (PDT)
>> Petri Gynther <pgynther@google.com> wrote:
>>
>>> When ibm_newemac netdev instance is shutdown with "ifconfig down",
>>> the netdev interface does not go properly down. netif_carrier_ok()
>>> keeps returning TRUE even after "ifconfig down".
>>>
>>> The problem can be seen when ibm_newemac instances are slaves of
>>> a bonding interface. The bonding interface code uses netif_carrier_ok()
>>> to determine the link status of its slaves. When ibm_newemac slave is
>>> shutdown with "ifconfig down", the bonding interface won't detect any
>>> link status change because netif_carrier_ok() keeps returning TRUE.
>>
>> Bonding should be testing for netif_running() && netif_carrier_ok().
>>
>> In many devices state of carrier is undefined when device is down.
>
> But if you check all of the drivers, ethernet in particular, the
> convention is to call netif_carrier_off() in foo_close().
>
^ permalink raw reply
* Re: [PATCH] ibm_newemac: emac_close() needs to call netif_carrier_off()
From: David Miller @ 2009-08-19 21:34 UTC (permalink / raw)
To: shemminger; +Cc: pgynther, benh, netdev
In-Reply-To: <20090819141136.74f5c266@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 19 Aug 2009 14:11:36 -0700
> On Wed, 19 Aug 2009 14:00:00 -0700 (PDT)
> Petri Gynther <pgynther@google.com> wrote:
>
>> When ibm_newemac netdev instance is shutdown with "ifconfig down",
>> the netdev interface does not go properly down. netif_carrier_ok()
>> keeps returning TRUE even after "ifconfig down".
>>
>> The problem can be seen when ibm_newemac instances are slaves of
>> a bonding interface. The bonding interface code uses netif_carrier_ok()
>> to determine the link status of its slaves. When ibm_newemac slave is
>> shutdown with "ifconfig down", the bonding interface won't detect any
>> link status change because netif_carrier_ok() keeps returning TRUE.
>
> Bonding should be testing for netif_running() && netif_carrier_ok().
>
> In many devices state of carrier is undefined when device is down.
But if you check all of the drivers, ethernet in particular, the
convention is to call netif_carrier_off() in foo_close().
^ permalink raw reply
* Re: [Bugme-new] [Bug 14002] New: WARNING: at net/ipv4/af_inet.c:154 inet_sock_destruct+0x164/0x1c0()
From: Andrew Morton @ 2009-08-19 21:21 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, ralf.hildebrandt
In-Reply-To: <bug-14002-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 18 Aug 2009 12:37:27 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14002
>
> Summary: WARNING: at net/ipv4/af_inet.c:154
> inet_sock_destruct+0x164/0x1c0()
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.31-rc4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: low
> Priority: P1
> Component: Netfilter/Iptables
> AssignedTo: networking_netfilter-iptables@kernel-bugs.osdl.org
> ReportedBy: ralf.hildebrandt@charite.de
> Regression: No
I suspect this _is_ a regression. I'll mark it as such and will snitch
to Rafael.
>
> from dmesg:
>
> Aug 17 17:02:31 vpn-gw-int kernel: [507940.695531] ------------[ cut here
> ]------------
> Aug 17 17:02:31 vpn-gw-int kernel: [507940.695558] WARNING: at
> net/ipv4/af_inet.c:154 inet_sock_destruct+0x164/0x1c0()
In my 2.6.31-rc4 that is
WARN_ON(sk->sk_forward_alloc);
> Aug 17 17:02:31 vpn-gw-int kernel: [507940.695589] Hardware name: ProLiant
> DL360 G4p
> Aug 17 17:02:31 vpn-gw-int kernel: [507940.695607] Modules linked in: ipt_LOG
> xt_multiport tun xt_tcpudp xt_state iptable_nat nf_nat iptable_filter ip_tables
> x_tables
> nf_conntrack_ipv4 nf_defrag_ipv4 ipv6 psmouse nf_conntrack_ftp nf_conntrack tg3
> libphy
> Aug 17 17:02:31 vpn-gw-int kernel: [507940.695697] Pid: 2314, comm: openvpn Not
> tainted 2.6.31-rc4 #1
> Aug 17 17:02:31 vpn-gw-int kernel: [507940.695715] Call Trace:
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695734] [<c1269d64>] ?
> inet_sock_destruct+0x164/0x1c0
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695756] [<c103252b>] ?
> warn_slowpath_common+0x6f/0xcd
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695777] [<c1269d64>] ?
> inet_sock_destruct+0x164/0x1c0
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695796] [<c10325a9>] ?
> warn_slowpath_null+0x20/0x3c
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695817] [<c1269d64>] ?
> inet_sock_destruct+0x164/0x1c0
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695838] [<c12889eb>] ?
> _spin_lock_bh+0x16/0x40
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695857] [<c12889eb>] ?
> _spin_lock_bh+0x16/0x40
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695877] [<c1219148>] ?
> __sk_free+0x21/0xd6
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695896] [<c1219311>] ?
> sk_common_release+0x5b/0x97
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695917] [<c1269815>] ?
> inet_release+0x39/0x66
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695936] [<c121639a>] ?
> sock_release+0x22/0x8d
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695954] [<c1216421>] ?
> sock_close+0x1c/0x42
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695975] [<c10a097c>] ?
> __fput+0xd6/0x1e0
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.695993] [<c109d454>] ?
> filp_close+0x41/0x72
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.696012] [<c109d4fa>] ?
> sys_close+0x75/0xc0
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.696032] [<c1002ecf>] ?
> sysenter_do_call+0x12/0x26
> Aug 17 17:02:32 vpn-gw-int kernel: [507940.696049] ---[ end trace
> a2930464345011de ]---
> Aug 17 17:03:01 vpn-gw-int kernel: [507970.165477] 172.28.33.133IN=tun0
> OUT=eth0 SRC=172.28.33.133 DST=141.80.40.193 LEN=67 TOS=0x00 PREC=0x00 TTL=127
> ID=23900 PROTO=UDP
> SPT=1026 DPT=53 LEN=47
Is it reproducible? Still happening in current mainline?
Thanks.
^ permalink raw reply
* Re: configfs/sysfs
From: Nicholas A. Bellinger @ 2009-08-19 21:19 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, Anthony Liguori, kvm, alacrityvm-devel, linux-kernel,
netdev, Michael S. Tsirkin, Ira W. Snyder, Joel Becker
In-Reply-To: <4A8C5CBB.10605@redhat.com>
On Wed, 2009-08-19 at 23:12 +0300, Avi Kivity wrote:
> On 08/19/2009 09:23 PM, Nicholas A. Bellinger wrote:
> > Anyways, I was wondering if you might be interesting in sharing your
> > concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
> >
>
> My concerns aren't specifically with configfs, but with all the text
> based pseudo filesystems that the kernel exposes.
>
<nod>
> My high level concern is that we're optimizing for the active sysadmin,
> not for libraries and management programs. configfs and sysfs are easy
> to use from the shell, discoverable, and easily scripted. But they
> discourage documentation, the text format is ambiguous, and they require
> a lot of boilerplate to use in code.
>
> You could argue that you can wrap *fs in a library that hides the
> details of accessing it, but that's the wrong approach IMO. We should
> make the information easy to use and manipulate for programs; one of
> these programs can be a fuse filesystem for the active sysadmin if
> someone thinks it's important.
>
> Now for the low level concerns:
>
> - efficiency
>
> Each attribute access requires an open/read/close triplet and
> binary->ascii->binary conversions. In contrast an ordinary
> syscall/ioctl interface can fetch all attributes of an object, or even
> all attributes of all objects, in one call.
>
I agree that syscalls/ioctls can, given enough coding effort, use a
potentially much smaller amount of total syscalls than a pseudo
filesystem such as configfs. In the case of the configfs enabled
generic target engine, I have not found this to be particularly limiting
in terms of management on modern x86_64 virtualized hardware inside of
KVM Guests with my development so far..
> - atomicity
>
> One attribute per file means that, lacking userspace-visible
> transactions, there is no way to change several attributes at once.
> When you read attributes,
Actually, something like this can be done in struct
config_item_type->ct_attrs[] by changing the attributes you want, but
not making them active until pulling a seperate configfs item 'trigger'
in the group to make the changes take effect.
I am doing something similar to this now during fabric bringup while
each iSCSI Target module is configured, and then a enable trigger throw
to allow iSCSI Initiators to actually login to the endpoint, and to
prevent endpoints from being active before all of the Ports and ACLs
have been configured for each configured iSCSI endpoint.
This logic is not built into ConfigFS of course, but it does give the
same effect.
> there is no way to read several attributes
> atomically so you can be sure their values correlate.
In this case, even though adding multiple values per attribute is
discouraged per the upstream sysfs layout, using a single configfs
attribute to read multiple values of another individual attributes that
need to be read atomically is primary option today wrt existing code.
Not ideal with configfs, but it is easy to do.
> Another example
> of a problem is when an object disappears while reading its attributes.
> Sure, openat() can mitigate this, but it's better to avoid introducing
> problem than having a fix.
>
<not sure on this one..>
> - ambiguity
>
> What format is the attribute? does it accept lowercase or uppercase hex
> digits? is there a newline at the end? how many digits can it take
> before the attribute overflows? All of this has to be documented and
> checked by the OS, otherwise we risk regressions later. In contrast,
> __u64 says everything in a binary interface.
>
Yes, you need to make strict_str*() calls on the configfs attribute
store() functions with casts to locally defined variable types. Using
strtoul() and strtoull() have been working fine for me in the context of
the generic target engine, but point taken about the usefulness in
having access to the format metadata of a given attribute.
> - lifetime and access control
>
> If a process brings an object into being (using mkdir) and then dies,
> the object remains behind.
I think this depends on how the struct configfs_item_grops->make_group()
and ->drop_item() are being used. For example, I typically allocate a
TCM related data structure during the make_group() call containing a
struct config_group member that is registered with
config_group_init_type_name() upon a successful mkdir(2) call.
When drop_item() is called via rmdir(2), that references the struct
config_group, the original data structure containing the struct
config_group is released with config_item_put(), and the TCM allocated
data structure released.
While in use, the registered struct config_group can be pinned with
configfs_depend_item(), which has some interesting limitiations of its
own.
> The syscall/ioctl approach ties the object
> into an fd, which will be destroyed when the process dies, and which can
> be passed around using SCM_RIGHTS, allowing a server process to create
> and configure an object before passing it to an unprivileged program
>
<nod> I have not personally had this requirement so I can't add much
here..
> - notifications
>
> It's hard to notify users about changes in attributes. Sure, you can
> use inotify, but that limits you to watching subtrees. Once you do get
> the notification, you run into the atomicity problem. When do you know
> all attributes are valid? This can be solved using sequence counters,
> but that's just gratuitous complexity. Netlink type interfaces are much
> more robust and flexible.
>
nor the notifiy case either..
> - readdir
>
> You can either list everything, or nothing. Sure, you can have trees to
> ease searching, even multiple views of the same data, but it's painful.
>
> You may argue, correctly, that syscalls and ioctls are not as flexible.
> But this is because no one has invested the effort in making them so.
I think that new syscalls are great when you can get them merged (as KVM
is quite important, that means not a problem), and I am sure you guys
can make an ioctl contort into all manner of positions.
Perhaps it is just that I think that the code to manage complex ioctl
interaction can get quite ugly from my experience, and doing backwards
compat with interpreted code makes life for easier, at least for me.
> A
> struct passed as an argument to a syscall is not extensible. But if you
> pass the size of the structure, and also a bitmap of which attributes
> are present, you gain extensibility and retain the atomicity property of
> a syscall interface. I don't think a lot of effort is needed to make an
> extensible syscall interface just as usable and a lot more efficient
> than configfs/sysfs.
Good point, however in terms of typical mangement scenarios in my
experience with TCM/LIO 3.x, I have not found the lost efficiently of
using configfs compared to legacy IOCTL for controlling the fabric in
typical usage cases.
That said, I am sure there must be particular cases in the
virtualization world where having those syscalls is critical, for which
a configfs enabled generic target does not make sense.
> It should also be simple to bolt a fuse interface
> on top to expose it to us commandline types.
>
That would be interesting..
> > As you may recall, I have been using configfs extensively for the 3.x
> > generic target core infrastructure and iSCSI fabric modules living in
> > lio-core-2.6.git/drivers/target/target_core_configfs.c and
> > lio-core-2.6.git/drivers/lio-core/iscsi_target_config.c, and have found
> > it to be extraordinarly useful for the purposes of a implementing a
> > complex kernel level target mode stack that is expected to manage
> > massive amounts of metadata, allow for real-time configuration, share
> > data structures (eg: SCSI Target Ports) between other kernel fabric
> > modules and manage the entire set of fabrics using only intrepetered
> > userspace code.
> >
> > Using the 10000 1:1 mapped TCM Virtual HBA+FILEIO LUNs<-> iSCSI Target
> > Endpoints inside of a KVM Guest (from the results in May posted with
> > IOMMU aware 10 Gb on modern Nahelem hardware, see
> > http://linux-iscsi.org/index.php/KVM-LIO-Target), we have been able to
> > dump the entire running target fabric configfs hierarchy to a single
> > struct file on a KVM Guest root device using python code on the order of
> > ~30 seconds for those 10000 active iSCSI endpoints. In configfs terms,
> > this means:
> >
> > *) 7 configfs groups (directories), ~50 configfs attributes (files) per
> > Virtual HBA+FILEIO LUN
> > *) 15 configfs groups (directories), ~60 configfs attributes (files per
> > iSCSI fabric Endpoint
> >
> > Which comes out to a total of ~220000 groups and ~1100000 attributes
> > active configfs objects living in the configfs_dir_cache that are being
> > dumped inside of the single KVM guest instances, including symlinks
> > between the fabric modules to establish the SCSI ports containing
> > complete set of SPC-4 and RFC-3720 features, et al.
> >
>
> You achieved 3 million syscalls/sec from Python code? That's very
> impressive.
Well, that is dumping the running configfs for everything. In more
typical usage cases of the TCM/LIO configfs fabric, specific Virtual
HBAs+LUNs and iSCSI Fabric endpoints would be changing individually, as
each Virtual HBA and iSCSI endpoint are completely independent of each
other and are intended to be administrated that way.
You can even run multiple for loops from different shell procceses to
create the endpoints in parallel using UUID and iSCSI WWN naming for
doing multithreaded configfs fabric bringup.
>
> Note with syscalls you could have done it with 10K syscalls (Python
> supports packing and unpacking structs quite well, and also directly
> calling C code IIRC).
>
> > Also on the kernel<-> user API interaction compatibility side, I have
> > found the 3.x configfs enabled code adventagous over the LIO 2.9 code
> > (that used an ioctl for everything) because it allows us to do backwards
> > compat for future versions without using any userspace C code, which in
> > IMHO makes maintaining userspace packages for complex kernel stacks with
> > massive amounts of metadata + real-time configuration considerations.
> > No longer having ioctl compatibility issues between LIO versions as the
> > structures passed via ioctl change, and being able to do backwards
> > compat with small amounts of interpreted code against configfs layout
> > changes makes maintaining the kernel<-> user API really have made this
> > that much easier for me.
> >
>
> configfs is more maintainable that a bunch of hand-maintained ioctls.
<nod>
> But if we put some effort into an extendable syscall infrastructure
> (perhaps to the point of using an IDL) I'm sure we can improve on that
> without the problems pseudo filesystems introduce.
>
Understood, while I think configfs is grand for a number of purposes, I
am certainly not foolish enough to think it is perfect for everything
> > Anyways, I though these might be useful to the discussion as it releates
> > to potental uses of configfs on the KVM Host or other projects that
> > really make sense, and/or to improve the upstream implementation so that
> > other users (like myself) can benefit from improvements to configfs.
> >
>
> I can't really fault a project for using configfs; it's an accepted and
> recommented (by the community) interface. I'd much prefer it though if
> there was an effort to create a usable fd/struct based alternative.
>
Thanks for your great comments Avi!
--nab
^ permalink raw reply
* Re: [PATCH] ibm_newemac: emac_close() needs to call netif_carrier_off()
From: Stephen Hemminger @ 2009-08-19 21:11 UTC (permalink / raw)
To: Petri Gynther; +Cc: benh, davem, netdev
In-Reply-To: <20090819210000.D56AB254211@localhost>
On Wed, 19 Aug 2009 14:00:00 -0700 (PDT)
Petri Gynther <pgynther@google.com> wrote:
> When ibm_newemac netdev instance is shutdown with "ifconfig down",
> the netdev interface does not go properly down. netif_carrier_ok()
> keeps returning TRUE even after "ifconfig down".
>
> The problem can be seen when ibm_newemac instances are slaves of
> a bonding interface. The bonding interface code uses netif_carrier_ok()
> to determine the link status of its slaves. When ibm_newemac slave is
> shutdown with "ifconfig down", the bonding interface won't detect any
> link status change because netif_carrier_ok() keeps returning TRUE.
Bonding should be testing for netif_running() && netif_carrier_ok().
In many devices state of carrier is undefined when device is down.
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-19 21:07 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <392fb48f0908190800j508456d6h9c520e82bc7f51e0@mail.gmail.com>
Hi Mike,
Am Mittwoch, 19. August 2009 17:00:31 schrieb Mike McCormack:
> * try the latest sky2 code from net-next-2.6
> * try adding an msleep(1) after sky2_rx_stop() in sky2_down()
> * try adding a check for rx_ring and tx_ring being NULL in
> sky2_status_intr(), and disable napi while freeing the buffers in
> sky2_down()
>
> I've got an untested, ad-hoc patch against net-next-2.6 for the last
> two bits ...
Pulling the latest sky2.c and sky2.h from net-next-2.6 and applying the patch
rids me of the oops - it is unreproducible right now. However, a networking
restart (i.e. all interfaces attached to sky2) leaves the devices in a state
where they no longer receive any network packets (at least nothing visible in
tcpdump). In this state, rmmod sky2 / modprobe sky2 gives:
[ 718.502717] sky2 0000:01:00.0: unsupported chip type 0xff
[ 718.510517] sky2: probe of 0000:01:00.0 failed with error -95
[ 718.517900] sky2 0000:02:00.0: unsupported chip type 0xff
[ 718.524408] sky2: probe of 0000:02:00.0 failed with error -95
[ 718.531617] sky2 0000:03:00.0: unsupported chip type 0xff
[ 718.538104] sky2: probe of 0000:03:00.0 failed with error -95
[ 718.545344] sky2 0000:04:00.0: unsupported chip type 0xff
[ 718.551818] sky2: probe of 0000:04:00.0 failed with error -95
I will now try the net-next-2.6 version without your patch again but was under
the impression that it still oopsed when I tried it initially. Better to
double-check before I give erroneous debugging results, though...
best regards,
Rene
--
-------------------------------------------------
Gibraltar firewall http://www.gibraltar.at/
^ permalink raw reply
* Re: [Alacrityvm-devel] [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Hollis Blanchard @ 2009-08-19 21:05 UTC (permalink / raw)
To: Avi Kivity
Cc: Ira W. Snyder, Michael S. Tsirkin, Gregory Haskins, kvm, netdev,
linux-kernel, alacrityvm-devel, Anthony Liguori, Ingo Molnar,
Gregory Haskins, Stefan Hajnoczi
In-Reply-To: <4A8C2A87.5060305@redhat.com>
On Wed, 2009-08-19 at 19:38 +0300, Avi Kivity wrote:
> On 08/19/2009 07:29 PM, Ira W. Snyder wrote:
> >
> >
> >> virtio-$yourhardware or maybe virtio-dma
> >>
> >>
> > How about virtio-phys?
> >
>
> Could work.
>
> > Arnd and BenH are both looking at PPC systems (similar to mine). Grant
> > Likely is looking at talking to an processor core running on an FPGA,
> > IIRC. Most of the code can be shared, very little should need to be
> > board-specific, I hope.
> >
>
> Excellent.
>
> >>> That said, I'm not sure how qemu-system-ppc running on x86 could
> >>> possibly communicate using virtio-net. This would mean the guest is an
> >>> emulated big-endian PPC, while the host is a little-endian x86. I
> >>> haven't actually tested this situation, so perhaps I am wrong.
> >>>
> >>>
> >> I'm confused now. You don't actually have any guest, do you, so why
> >> would you run qemu at all?
> >>
> >>
> > I do not run qemu. I am just stating a problem with virtio-net that I
> > noticed. This is just so someone more knowledgeable can be aware of the
> > problem.
> >
> >
>
> Ah, it certainly doesn't byteswap. Maybe nobody tried it. Hollis?
I've never tried it. I've only used virtio with matching guest/host
architectures.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] ibm_newemac: emac_close() needs to call netif_carrier_off()
From: Petri Gynther @ 2009-08-19 21:00 UTC (permalink / raw)
To: benh, davem; +Cc: netdev
When ibm_newemac netdev instance is shutdown with "ifconfig down",
the netdev interface does not go properly down. netif_carrier_ok()
keeps returning TRUE even after "ifconfig down".
The problem can be seen when ibm_newemac instances are slaves of
a bonding interface. The bonding interface code uses netif_carrier_ok()
to determine the link status of its slaves. When ibm_newemac slave is
shutdown with "ifconfig down", the bonding interface won't detect any
link status change because netif_carrier_ok() keeps returning TRUE.
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ibm_newemac/core.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index beb8421..f0f8908 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1305,6 +1305,8 @@ static int emac_close(struct net_device *ndev)
free_irq(dev->emac_irq, dev);
+ netif_carrier_off(ndev);
+
return 0;
}
--
1.5.4.3
^ permalink raw reply related
* [PATCH]: quelch ppp generic warnings...
From: David Miller @ 2009-08-19 20:56 UTC (permalink / raw)
To: netdev
I just commited this to net-next-2.6
ppp_generic: Help GCC see that 'flen' is always initialized.
It's too stupid to see that we always set flen to something
before we use it in ppp_mp_explode():
drivers/net/ppp_generic.c: In function 'ppp_push':
drivers/net/ppp_generic.c:1314: warning: 'flen' may be used uninitialized in this function
drivers/net/ppp_generic.c:1314: note: 'flen' was declared here
This started warning after commit a53a8b56827cc429c6d9f861ad558beeb5f6103f
("ppp: fix lost fragments in ppp_mp_explode() (resubmit)")
So just put an explicit unconditional initialization there to
hush it up.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ppp_generic.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 7dd0868..35be2e8 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1431,6 +1431,7 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)
*otherwise divide it according to the speed
*of the channel we are going to transmit on
*/
+ flen = len;
if (nfree > 0) {
if (pch->speed == 0) {
flen = totlen/nfree ;
--
1.6.3.4
^ permalink raw reply related
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Ingo Molnar @ 2009-08-19 20:53 UTC (permalink / raw)
To: Avi Kivity
Cc: Gregory Haskins, kvm, alacrityvm-devel, linux-kernel, netdev,
Michael S. Tsirkin, Patrick Mullaney
In-Reply-To: <4A8C627C.70001@redhat.com>
* Avi Kivity <avi@redhat.com> wrote:
>>> IIRC we reuse the PCI IDs for non-PCI.
>>>
>>
>> You already know how I feel about this gem.
>
> The earth keeps rotating despite the widespread use of
> PCI IDs.
Btw., PCI IDs are a great way to arbitrate interfaces
planet-wide, in an OS-neutral, depoliticized and
well-established way.
It's a bit like CPUID for CPUs, just on a much larger
scope.
Ingo
^ permalink raw reply
* Re: configfs/sysfs
From: Avi Kivity @ 2009-08-19 20:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, Nicholas A. Bellinger, Anthony Liguori, kvm,
alacrityvm-devel, linux-kernel, netdev, Michael S. Tsirkin,
Ira W. Snyder, Joel Becker
In-Reply-To: <20090819204821.GA27292@elte.hu>
On 08/19/2009 11:48 PM, Ingo Molnar wrote:
>
> FYI, an example of such a syscall design and
> implementation has been merged upstream in the .31 merge
> window, see:
>
> <big snip>
>
>
Exactly. It's beautiful.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: configfs/sysfs
From: Ingo Molnar @ 2009-08-19 20:48 UTC (permalink / raw)
To: Avi Kivity, Peter Zijlstra
Cc: Nicholas A. Bellinger, Anthony Liguori, kvm, alacrityvm-devel,
linux-kernel, netdev, Michael S. Tsirkin, Ira W. Snyder,
Joel Becker
In-Reply-To: <4A8C5CBB.10605@redhat.com>
* Avi Kivity <avi@redhat.com> wrote:
> You may argue, correctly, that syscalls and ioctls are
> not as flexible. But this is because no one has
> invested the effort in making them so. A struct passed
> as an argument to a syscall is not extensible. But if
> you pass the size of the structure, and also a bitmap
> of which attributes are present, you gain extensibility
> and retain the atomicity property of a syscall
> interface. I don't think a lot of effort is needed to
> make an extensible syscall interface just as usable and
> a lot more efficient than configfs/sysfs. It should
> also be simple to bolt a fuse interface on top to
> expose it to us commandline types.
FYI, an example of such a syscall design and
implementation has been merged upstream in the .31 merge
window, see:
kernel/perf_counter.c::sys_perf_counter_open()
SYSCALL_DEFINE5(perf_counter_open,
struct perf_counter_attr __user *, attr_uptr,
pid_t, pid, int, cpu, int, group_fd, unsigned long, flags)
We embedd a '.size' field in struct perf_counter_attr. We
copy the attribute from user-space in an
'auto-extend-to-zero' way:
ret = perf_copy_attr(attr_uptr, &attr);
if (ret)
return ret;
where perf_copy_attr() extends the possibly-smaller
user-space structure to the in-kernel structure and
zeroes out remaining fields.
This means that older binaries can pass in older
(smaller) versions of the structure.
This syscall ABI design works very well and has a lot of
advantages:
- is extensible in a flexible way
- it is forwards ABI compatible
- the kernel is backwards compatible with applications
- extensions to the ABI dont uglify the interface.
- new applications can fall back gracefully to older ABI
versions if they so choose. (the kernel will reject
overlarge attr.size) So full forwards and backwards
compatibility can be implemented, if an app wants to.
- 'same version' ABI uses dont have any interface quirk
or performance penalty. (i.e. there's no increasingly
complex maze of add-on ABI details for the syscall to
multiplex through)
- the system call stays nice and readable
We've made use of this property of the perfcounters ABI
and extended it in a compatible way several times
already, with great success.
Ingo
^ permalink raw reply
* [RFC PATCH V2] lib/vsprintf.c: Add struct sockaddr * "%pN<foo>" output
From: Joe Perches @ 2009-08-19 20:44 UTC (permalink / raw)
To: Chuck Lever; +Cc: jens, brian.haley, David Miller, netdev
In-Reply-To: <2D3306C4-4DF4-4E3E-BBC2-2032058FA673@oracle.com>
On Wed, 2009-08-19 at 10:26 -0400, Chuck Lever wrote:
> On Aug 16, 2009, at 12:10 AM, Joe Perches wrote:
> I think having at least a generic socket address formatter would be
> very helpful. The kernel RPC code can use that immediately for
> generating debugging messages, generating "universal
> addresses" (patches already accepted for 2.6.32) and for generating
> presentation addresses to pass to user space (lockd does this now).
> > Use style:
> > * - 'N' For network socket (sockaddr) pointers
> > * if sa_family is IPv4, output is %pI4; if IPv6, output is %pI6c
> > * May be used with any combination of additional specifiers
> > below
> > * 'p' decimal socket port number for IPv[46]: ":12345"
> > * 'f' decimal flowinfo for IPv6: "/123456789"
> > * 's' decimal scope_id number for IPv6: "%1234567890"
> > * so %pNp will print if IPv4 "1.2.3.4:1234", if IPv6:
> > "1::c0a8:a:1234"
> >
> > I think using ":" as the separator for the port number, while common,
> > and already frequently used in kernel source (see bullet 2 in):
> > http://www.ietf.org/id/draft-kawamura-ipv6-text-representation-03.txt
> > "Section 6: Notes on Combining IPv6 Addresses with Port Numbers".
> > is not good for readability.
> >
> > Perhaps this style should be changed to the "[ipv6]:port" described
> > in the draft above.
>
> I agree that the port number convention is tricky, and some kernel
> areas handle it differently than others. Perhaps having a separate
> family-agnostic formatter for printing the port number (or scope ID,
> etc.) might allow greatest flexibility.
I'm not too sure there's much value in ever more formatters for
relatively simple things or in printing something like port or
scope without the ip address.
%hu ntohs(sa6->sin6_port)
or
%d or 0x%x ntohl(sa6->sin6_flowinfo)
seem pretty straightforward to me.
> The RPC code, for example, displays port numbers in decimal and in
> "hi.lo" format (the high byte is printed in decimal, then the low byte
> is printed in decimal. The two values are separated by a dot. For
> example, port 2049 is displayed as "8.1").
Here's another tentative patch that does both using square
brackets around IPv6 addresses with a port number and
allows selection of the port number style ":dddd" or ":hi.lo"
It also adds a "pI6n" form for IPv6 addresses with 7 colons
and no leading 0's.
lib/vsprintf.c: Add '%pN' print formatted struct sock_addr *
Use styles:
* - 'N' For network socket (sockaddr) pointers
* if sa_family is IPv4, output is %pI4; if IPv6, output is %pI6c
* May be used with any combination of additional specifiers below
* 'p' decimal socket port number for IPv[46]: ":12345"
* 'P' decimal socket port number for IPv6: ":1.255" (hi.lo)
* if IPv6 and port number is selected, square brackets
* will surround the IPv6 address for 'p' and 'P'
* 'f' decimal flowinfo for IPv6: "/123456789"
* 's' decimal scope_id number for IPv6: "%1234567890"
* %pNp will print IPv4: "1.2.3.4:1234"
* IPv6: "[1::c0a8:a]:1234"
* %pNP will print IPv4: "1.2.3.4:1.255
* IPv6: "[1::c0a8:a]:1.255"
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index cb8a112..139f310 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -647,22 +647,73 @@ static char *mac_address_string(char *buf, char *end, u8 *addr,
return string(buf, end, mac_addr, spec);
}
-static char *ip4_string(char *p, const u8 *addr, bool leading_zeros)
+static char *u8_to_dec(char *p, u8 val, bool leadingzeros)
+{
+ char temp[3]; /* holds val in reverse order */
+ int digits = put_dec_trunc(temp, val) - temp;
+
+ if (leadingzeros) {
+ if (digits < 3)
+ *p++ = '0';
+ if (digits < 2)
+ *p++ = '0';
+ }
+ /* reverse the digits */
+ while (digits--)
+ *p++ = temp[digits];
+
+ return p;
+}
+
+static char *u16_to_hex(char *p, u16 word, bool leadingzeros)
+{
+ u8 hi = word >> 8;
+ u8 lo = word & 0xff;
+ if (leadingzeros) {
+ p = pack_hex_byte(p, hi);
+ p = pack_hex_byte(p, lo);
+ } else {
+ if (hi) {
+ if (hi > 0x0f)
+ p = pack_hex_byte(p, hi);
+ else
+ *p++ = hex_asc_lo(hi);
+ }
+ if (hi || lo > 0x0f)
+ p = pack_hex_byte(p, lo);
+ else
+ *p++ = hex_asc_lo(lo);
+ }
+
+ return p;
+}
+
+static char *u32_dec_val(char *p, u32 val)
+{
+ char temp[9]; /* holds val in reverse order */
+ int digits;
+ char *pos;
+
+ if (val < 100000)
+ pos = put_dec_trunc(temp, val);
+ else {
+ pos = put_dec_trunc(temp, val % 100000);
+ pos = put_dec_trunc(pos, val / 100000);
+ }
+ digits = pos - temp;
+ /* reverse the digits */
+ while (digits--)
+ *p++ = temp[digits];
+
+ return p;
+}
+
+static char *ip4_string(char *p, const u8 *addr, bool leadingzeros)
{
int i;
for (i = 0; i < 4; i++) {
- char temp[3]; /* hold each IP quad in reverse order */
- int digits = put_dec_trunc(temp, addr[i]) - temp;
- if (leading_zeros) {
- if (digits < 3)
- *p++ = '0';
- if (digits < 2)
- *p++ = '0';
- }
- /* reverse the digits in the quad */
- while (digits--)
- *p++ = temp[digits];
+ p = u8_to_dec(p, addr[i], leadingzeros);
if (i < 3)
*p++ = '.';
}
@@ -679,9 +730,6 @@ static char *ip6_compressed_string(char *p, const struct in6_addr *addr)
unsigned char zerolength[8];
int longest = 1;
int colonpos = -1;
- u16 word;
- u8 hi;
- u8 lo;
bool needcolon = false;
bool useIPv4 = ipv6_addr_v4mapped(addr) || ipv6_addr_is_isatap(addr);
@@ -721,20 +769,7 @@ static char *ip6_compressed_string(char *p, const struct in6_addr *addr)
*p++ = ':';
needcolon = false;
}
- /* hex u16 without leading 0s */
- word = ntohs(addr->s6_addr16[i]);
- hi = word >> 8;
- lo = word & 0xff;
- if (hi) {
- if (hi > 0x0f)
- p = pack_hex_byte(p, hi);
- else
- *p++ = hex_asc_lo(hi);
- }
- if (hi || lo > 0x0f)
- p = pack_hex_byte(p, lo);
- else
- *p++ = hex_asc_lo(lo);
+ p = u16_to_hex(p, ntohs(addr->s6_addr16[i]), false);
needcolon = true;
}
@@ -751,9 +786,10 @@ static char *ip6_compressed_string(char *p, const struct in6_addr *addr)
static char *ip6_string(char *p, const struct in6_addr *addr, const char *fmt)
{
int i;
+ bool leadingzeros = !(fmt[0] == 'I' && fmt[2] == 'n');
+
for (i = 0; i < 8; i++) {
- p = pack_hex_byte(p, addr->s6_addr[2 * i]);
- p = pack_hex_byte(p, addr->s6_addr[2 * i + 1]);
+ p = u16_to_hex(p, ntohs(addr->s6_addr16[i]), leadingzeros);
if (fmt[0] == 'I' && i != 7)
*p++ = ':';
}
@@ -785,6 +821,102 @@ static char *ip4_addr_string(char *buf, char *end, const u8 *addr,
return string(buf, end, ip4_addr, spec);
}
+static char *port_string(char *p, u16 port, const char *fmt)
+{
+ if (*fmt == 'p')
+ p = u32_dec_val(p, port);
+ else {
+ p = u8_to_dec(p, port >> 8, false);
+ *p++ = '.';
+ p = u8_to_dec(p, port & 0xff, false);
+ }
+
+ return p;
+}
+
+static char *socket_addr_string(char *buf, char *end,
+ const struct sockaddr *sa,
+ struct printf_spec spec, const char *fmt)
+{
+ char baddress[sizeof("[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:255.255.255.255]"
+ ":255.255" /* port # or :12345 */
+ "%1234567890" /* IPv6 scope id */
+ "/123456789")]; /* IPv6 flow mask */
+ char *p;
+ char *addr;
+ struct sockaddr_in *sa4 = (struct sockaddr_in *)sa;
+ struct sockaddr_in6 *sa6 = (struct sockaddr_in6 *)sa;
+
+ /* Start with a bracket in case the address is IPv6 with a port # */
+ baddress[0] = '[';
+ addr = &baddress[1]; /* address without leading '[' */
+ p = addr;
+
+ switch (sa->sa_family) {
+ case AF_INET:
+ p = ip4_string(addr, (const u8 *)&sa4->sin_addr.s_addr, false);
+ break;
+ case AF_INET6:
+ p = ip6_compressed_string(addr, &sa6->sin6_addr);
+ break;
+ default: {
+ struct printf_spec num_spec = {
+ .base = 16,
+ .precision = -1,
+ .field_width = 2 * sizeof(void *),
+ .flags = SPECIAL | SMALL | ZEROPAD,
+ };
+ size_t msglen;
+
+ p = strcpy(baddress, "Bad socket address: ");
+ msglen = strlen(p);
+ p = number(p + msglen, p + sizeof(baddress) - msglen,
+ (unsigned long)sa, num_spec);
+ break;
+ }
+ }
+
+ while (isalpha(*++fmt)) {
+ switch (*fmt) {
+ case 'p':
+ case 'P':
+ switch (sa->sa_family) {
+ case AF_INET:
+ *p++ = ':';
+ p = port_string(p, ntohs(sa4->sin_port), fmt);
+ break;
+ case AF_INET6:
+ /* Use the initial bracket */
+ if (addr > baddress)
+ addr--;
+ *p++ = ']';
+ *p++ = ':';
+ p = port_string(p, ntohs(sa6->sin6_port), fmt);
+ break;
+ }
+ break;
+ case 's':
+ switch (sa->sa_family) {
+ case AF_INET6:
+ *p++ = '%';
+ p = u32_dec_val(p, sa6->sin6_scope_id);
+ }
+ break;
+ case 'f':
+ switch (sa->sa_family) {
+ case AF_INET6:
+ *p++ = '/';
+ p = u32_dec_val(p, ntohl(sa6->sin6_flowinfo &
+ IPV6_FLOWINFO_MASK));
+ }
+ break;
+ }
+ }
+
+ *p = '\0';
+ return string(buf, end, addr, spec);
+}
+
/*
* Show a '%p' thing. A kernel extension is that the '%p' is followed
* by an extra set of alphanumeric characters that are extended format
@@ -808,6 +940,15 @@ static char *ip4_addr_string(char *buf, char *end, const u8 *addr,
* IPv4 uses dot-separated decimal with leading 0's (010.123.045.006)
* - 'I6c' for IPv6 addresses printed as specified by
* http://www.ietf.org/id/draft-kawamura-ipv6-text-representation-03.txt
+ * - 'I6n' IPv6: colon separated network-order 16 bit hex without leading 0's
+ * - 'N' For network socket (sockaddr) pointers
+ * if sa_family is IPv4, output is %pI4; if IPv6, output is %pI6c
+ * May be used with any combination of additional specifiers below
+ * 'p' decimal socket port number for IPv[46]: ":12345"
+ * 'P' decimal socket port numbers using hi/lo u8: ":0.255"
+ * 's' decimal scope_id number for IPv6: "%123456789"
+ * 'f' decimal flowinfo for IPv6: "/123456789"
+ * so %pNp will print if IPv4 "1.2.3.4:1234", if IPv6: "[1::c0a8:a]:1234"
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
* pointer to the real address.
@@ -834,6 +975,7 @@ static char *pointer(const char *fmt, char *buf, char *end, void *ptr,
* 4: 1.2.3.4
* 6: 0001:0203:...:0708
* 6c: 1::708 or 1::1.2.3.4
+ * 6n: 1:2:3:0:0:0:789:abcd
*/
case 'i': /* Contiguous:
* 4: 001.002.003.004
@@ -846,7 +988,10 @@ static char *pointer(const char *fmt, char *buf, char *end, void *ptr,
return ip4_addr_string(buf, end, ptr, spec, fmt);
}
break;
+ case 'N':
+ return socket_addr_string(buf, end, ptr, spec, fmt);
}
+
spec.flags |= SMALL;
if (spec.field_width == -1) {
spec.field_width = 2*sizeof(void *);
^ permalink raw reply related
* AX.25 devices on USB ?
From: Matti Aarnio @ 2009-08-19 20:41 UTC (permalink / raw)
To: linux-ax25-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
On Linux there is support for special Radio Amateur radio network protocol
called AX.25 (and couple more or less related ones).
My pondering is: What kind of USB device class profile specification to bend
so that I could make a packet oriented radio data modem connectable to these
network layers ?
I do think that it needs to be some sort of "Communications Device Class"
thing, but what kind of ? I really do not want to put virtual serial ports
and KISS encapsulation in there... (Those not familar with Radio Amateur
protocols, KISS is variation of SLIP with a hook to handle couple link-layer
control functions, plus multiplexing multiple devices on single serial port.)
On USB CDC specification part 4.7 there is a table of "Data Interface Class
Protocol Codes" -- and there code 31h: "HDLC" would probably be what engineer
orders for all manner of radio amateur data protocols.
(That use packets to begin with.)
This is one of "ISDN device" subclasses, which may cause interesting mixup
when plugged in..
Another could be to bend "CDC ECM" -- to treat the devices as if they are
Ethernet.
Third possibility is to bend the specification called "CDC WMC1.1";
"Wireless Mobile Communications device", which these sort of are...
Pick either "LAN frame", or some "MDLM".
What I would prefer to avoid like a plague is using "this is proprietary"
type tagging.
Any ideas ?
/Matti Aarnio
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
From: Rafael J. Wysocki @ 2009-08-19 20:40 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Francis Moreau, netdev
In-Reply-To: <xDf-7eSwYsC.A.-6B.klIjKB@chimera>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-05-03 16:22 (109 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox