* RE: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Narendra_K @ 2011-01-10 18:48 UTC (permalink / raw)
To: jbarnes
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110107142750.21ea39f0@jbarnes-desktop>
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Saturday, January 08, 2011 3:58 AM
> To: K, Narendra
> Cc: Domsch, Matt; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; Hargrave, Jordan;
> Rose, Charles; Nijhawan, Vijay
> Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number
> and string name to sysfs
>
> On Thu, 23 Dec 2010 11:24:36 -0800
> <Narendra_K@Dell.com> wrote:
>
> > On Thu, Dec 23, 2010 at 08:02:03PM +0530, Domsch, Matt wrote:
> > > On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@Dell.com
> wrote:
> > > > Hello,
> > > >
> > > > This patch exports ACPI _DSM provided firmware instance number
> and
> > > > string name to sysfs.
> > > >
> > > > Please review -
> > >
> > > There are now two different meanings for the 'index' file:
> > >
> > > 1) SMBIOS-provided "type instance" value, which I've only seen in
> > > range [1..N] for N devices, monotonically stepwise increasing.
> > >
> > > 2) ACPI-provided "index" value, which per spec only needs to be a
> > > "sort key", not starting at 0 or 1, and while monotonically
> > > increasing, not necessarily stepwise. It's perfectly valid for
> the
> > > values to be (12, 16, 27, 29) if that's convenient for BIOS to
> > > generate.
> > >
> > > Therefore, a consumer of this value (such as biosdevname) must know
> > > which of the two it's dealing with, and either accept the value as-
> is,
> > > or sort the value list. While I suppose it could sort the value
> list
> > > in either case, I'd prefer the ACPI value to be exposed in its own
> > > file, perhaps 'acpi_index', to make this explicit rather than
> > > implicit.
> > >
> > > 'label' is fine for either case, with ACPI taking priority over
> > > SMBIOS if both happen to be present.
> > >
>
> Applied, thanks.
Jesse,
Thank you.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Jesse Barnes @ 2011-01-10 19:13 UTC (permalink / raw)
To: Narendra_K
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <E31FB011129F30488D5861F3839049151D10F8EF9D@BLRX7MCDC201.AMER.DELL.COM>
On Mon, 10 Jan 2011 10:48:26 -0800
<Narendra_K@Dell.com> wrote:
> > > > 'label' is fine for either case, with ACPI taking priority over
> > > > SMBIOS if both happen to be present.
> > > >
> >
> > Applied, thanks.
>
> Jesse,
>
> Thank you.
Not sure if you saw it yet, but the patch caused a build breakage. Can
you send me a replacement patch with a fix asap?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: panic in tg3 driver
From: Matt Carlson @ 2011-01-10 19:22 UTC (permalink / raw)
To: Stephen Clark
Cc: Linux Kernel Network Developers, Michael Chan, Matthew Carlson
In-Reply-To: <4D2A371A.40103@earthlink.net>
On Sun, Jan 09, 2011 at 02:30:50PM -0800, Stephen Clark wrote:
> On 01/04/2011 09:54 AM, Stephen Clark wrote:
> > Hello,
> >
> >
> > The hardware is an Acrosser AR-M0898B micro box.
> > lspci
> > 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
> > 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> > Host Bridge
> > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
> > 00:0f.0 IDE interface: VIA Technologies, Inc. VT8251 Serial ATA
> > Controller (rev
> > 20)
> > 00:0f.1 IDE interface: VIA Technologies, Inc.
> > VT82C586A/B/VT82C686/A/B/VT823x/A/
> > C PIPC Bus Master IDE (rev 07)
> > 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller
> > (rev 91)
> > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
> > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
> > 00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
> > 00:13.0 Host bridge: VIA Technologies, Inc. VT8251 Host Bridge
> > 00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
> > 02:08.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
> > (rev 02)
> > 02:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
> > (rev 02)
> > 80:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
> > 80:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
> > 81:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
> > Fast Ethernet
> > PCI Express (rev 02)
> > 82:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
> > Fast Ethernet
> > PCI Express (rev 02)
> >
> > Kernel 2.6.36-2.el5.elrepo on an i686
> >
> > When I try to ifconfig either of the BCM5906M ports the system panics.
> >
> > Ideas, fixes ?
> >
> > [root@Z1010 ~]# modprobe tg3
> > [root@Z1010 ~]# ifconfig eth2 2.2.2.2/24
> > ------------[ cut here ]------------
> > kernel BUG at drivers/net/tg3.c:4365!
> > invalid opcode: 0000 [#1] PREEMPT SMP
> > last sysfs file: /sys/class/net/eth3/address
> > Modules linked in: tg3 xt_tcpudp ipt_LOG xt_limit xt_state
> > iptable_mangle af_ke]
> >
> > Pid: 20303, comm: kworker/0:2 Not tainted 2.6.36-2.el5.elrepo #1
> > CN700-8251/
> > EIP: 0060:[<e1c62f19>] EFLAGS: 00010202 CPU: 0
> > EIP is at tg3_tx_recover+0x1e/0x53 [tg3]
> > EAX: deece4c0 EBX: dfa9c000 ECX: deece4c0 EDX: ffffffff
> > ESI: deece4c0 EDI: deece500 EBP: c1801f38 ESP: c1801f30
> > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > Process kworker/0:2 (pid: 20303, ti=c1801000 task=df0105d0
> > task.ti=dee62000)
> > Stack:
> > dfa9c000 00000000 c1801f6c e1c630be c1801f6c deece4c0 00000840 00000000
> > <0> df251cc0 00000005 00000000 df979800 deece500 deece4c0 00000040
> > c1801f94
> > <0> e1c661e5 00000000 00000040 c1801f88 e09df1d2 00000000 deece500
> > dfab4000
> > Call Trace:
> > [<e1c630be>] ? tg3_tx+0x157/0x1a2 [tg3]
> > [<e1c661e5>] ? tg3_poll_work+0x2b/0x10b [tg3]
> > [<e09df1d2>] ? ssb_write32+0x11/0x14 [b44]
> > [<e1c662f9>] ? tg3_poll+0x34/0x9a [tg3]
> > [<c0674058>] ? net_rx_action+0x7e/0x11c
> > [<c04409c9>] ? __do_softirq+0x85/0x10c
> > [<c0440944>] ? __do_softirq+0x0/0x10c
> > <IRQ>
> > [<c04404ef>] ? _local_bh_enable_ip+0x68/0x87
> > [<c044051b>] ? local_bh_enable_ip+0xd/0xf
> > [<c046593b>] ? __raw_spin_unlock_bh+0x1c/0x1e
> > [<c06fa4f2>] ? _raw_spin_unlock_bh+0xd/0xf
> > [<e1c6281f>] ? spin_unlock_bh+0xd/0xf [tg3]
> > [<e1c62cbe>] ? tg3_full_unlock+0x10/0x12 [tg3]
> > [<e1c664c7>] ? tg3_reset_task+0xd7/0xe3 [tg3]
> > [<c044ec37>] ? process_one_work+0x10b/0x1bc
> > [<e1c663f0>] ? tg3_reset_task+0x0/0xe3 [tg3]
> > [<c044fd41>] ? worker_thread+0x77/0xf9
> > [<c0453048>] ? kthread+0x60/0x65
> > [<c044fcca>] ? worker_thread+0x0/0xf9
> > [<c0452fe8>] ? kthread+0x0/0x65
> > [<c040337e>] ? kernel_thread_helper+0x6/0x10
> > Code: f0 e8 88 ff ff ff 8d 65 f8 5b 5e 5d c3 55 89 e5 56 53 0f 1f 44
> > 00 00 f6 8
> > EIP: [<e1c62f19>] tg3_tx_recover+0x1e/0x53 [tg3] SS:ESP 0068:c1801f30
> > ---[ end trace 82381e9b93e397ad ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Pid: 20303, comm: kworker/0:2 Tainted: G D
> > 2.6.36-2.el5.elrepo #1
> > Call Trace:
> > [<c043b3cd>] panic+0x62/0x15d
> > [<c06fb7d1>] oops_end+0x99/0xa8
> > [<e1c62f19>] ? tg3_tx_recover+0x1e/0x53 [tg3]
> > [<c0405a62>] die+0x58/0x5e
> >
> > Thanks,
> > Steve
> >
> Additonal info I compiled the latest kernel 2.6.37-rc8+ and still have the problem.
> Also boot with noapic I see this in the dmesg log and interrupts are increasing
> like crazy:
> tg3.c:v3.115 (October 14, 2010)
> tg3 0000:81:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
> tg3 0000:81:00.0: setting latency timer to 64
> tg3 0000:81:00.0: PCI: Disallowing DAC for device
> tg3 0000:81:00.0: eth2: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
> ress 00:02:b6:36:d1:39
> tg3 0000:81:00.0: eth2: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
> [0])
> tg3 0000:81:00.0: eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> tg3 0000:81:00.0: eth2: dma_rwctrl[76180000] dma_mask[32-bit]
> tg3 0000:82:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
> tg3 0000:82:00.0: setting latency timer to 64
> tg3 0000:82:00.0: PCI: Disallowing DAC for device
> tg3 0000:82:00.0: eth3: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
> ress 00:02:b6:36:d1:3a
> tg3 0000:82:00.0: eth3: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
> [0])
> tg3 0000:82:00.0: eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> tg3 0000:82:00.0: eth3: dma_rwctrl[76180000] dma_mask[32-bit]
> tg3 0000:81:00.0: irq 40 for MSI/MSI-X
> tg3 0000:81:00.0: eth2: No interrupt was generated using MSI. Switching to INTx
> mode. Please report this failure to the PCI maintainer and include system chipse
> t information
> ADDRCONF(NETDEV_UP): eth2: link is not ready
> [root@Z1010 ~]# cat /proc/interrupts
> CPU0
> 0: 162 XT-PIC-XT-PIC timer
> 1: 2 XT-PIC-XT-PIC i8042
> 2: 0 XT-PIC-XT-PIC cascade
> 3: 1 XT-PIC-XT-PIC
> 4: 4863 XT-PIC-XT-PIC serial
> 6: 2 XT-PIC-XT-PIC floppy
> 7: 5 XT-PIC-XT-PIC ehci_hcd:usb1, uhci_hcd:usb3
> 8: 0 XT-PIC-XT-PIC rtc0
> 9: 0 XT-PIC-XT-PIC acpi
> 10: 2334234 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>
> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
> 10: 18388914 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
> 10: 18901627 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>
> --
>
> "They that give up essential liberty to obtain temporary safety,
> deserve neither liberty nor safety." (Ben Franklin)
>
> "The course of history shows that as a government grows, liberty
> decreases." (Thomas Jefferson)
I think drivers/net/tg3.c:4365 is at the line that reads
"spin_lock(&tp->lock);" in tg3_tx_recover. Can you verify?
^ permalink raw reply
* RE: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Narendra_K @ 2011-01-10 19:35 UTC (permalink / raw)
To: jbarnes
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110110111300.58e6bbea@jbarnes-desktop>
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Tuesday, January 11, 2011 12:43 AM
> To: K, Narendra
> Cc: Domsch, Matt; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; Hargrave, Jordan;
> Rose, Charles; Nijhawan, Vijay
> Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number
> and string name to sysfs
>
> On Mon, 10 Jan 2011 10:48:26 -0800
> <Narendra_K@Dell.com> wrote:
> > > > > 'label' is fine for either case, with ACPI taking priority over
> > > > > SMBIOS if both happen to be present.
> > > > >
> > >
> > > Applied, thanks.
> >
> > Jesse,
> >
> > Thank you.
>
> Not sure if you saw it yet, but the patch caused a build breakage. Can
> you send me a replacement patch with a fix asap?
>
> Thanks,
Just saw it now. Sorry for the inconvenience. I took the patch against linux-2.6 where I did not see the failure. I am pulling the linux-next now, will get this resolved first thing tomorrow.
With regards,
Narendra K
^ permalink raw reply
* [Bug 24592] Re: 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2011-01-10 20:09 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, maciej.rutecki, florian, akpm, torvalds,
kernel-testers, netdev, linux-acpi, linux-pm, linux-scsi,
linux-wireless, dri-devel
In-Reply-To: <20110110.000813.173856001.davem@davemloft.net>
On Monday, January 10, 2011, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET)
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
> > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
> > Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
> > Date : 2010-12-08 21:09 (22 days old)
>
> This bug is intended to be fixed by:
>
> commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb
> Author: David S. Miller <davem@davemloft.net>
> Date: Wed Jan 5 15:38:53 2011 -0800
>
> af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks.
>
> unix_release() can asynchornously set socket->sk to NULL, and
> it does so without holding the unix_state_lock() on "other"
> during stream connects.
>
> However, the reverse mapping, sk->sk_socket, is only transitioned
> to NULL under the unix_state_lock().
>
> Therefore make the security hooks follow the reverse mapping instead
> of the forward mapping.
>
> Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2011-01-10 20:11 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, maciej.rutecki, florian, akpm, torvalds,
kernel-testers, netdev, linux-acpi, linux-pm, linux-scsi,
linux-wireless, dri-devel
In-Reply-To: <20110110.000813.173856001.davem@davemloft.net>
On Monday, January 10, 2011, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET)
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
> > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
> > Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
> > Date : 2010-12-08 21:09 (22 days old)
> > Message-ID : <4CFFF3F3.90100@goop.org>
> > References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
>
> This bug is intended to be fixed by:
>
> commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb
> Author: David S. Miller <davem@davemloft.net>
> Date: Wed Jan 5 15:38:53 2011 -0800
>
> af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks.
>
> unix_release() can asynchornously set socket->sk to NULL, and
> it does so without holding the unix_state_lock() on "other"
> during stream connects.
>
> However, the reverse mapping, sk->sk_socket, is only transitioned
> to NULL under the unix_state_lock().
>
> Therefore make the security hooks follow the reverse mapping instead
> of the forward mapping.
>
> Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
OK, thanks for the info, closing.
Rafael
^ permalink raw reply
* Re: [PATCH V8 12/13] ptp: Added a clock driver for the IXP46x.
From: Krzysztof Halasa @ 2011-01-10 20:24 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20110107170752.GB8666-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> But before that, I have a big favor to ask you. Can you please look at
> the TODO in my patch and give me a hint? I don't know how to relate
> the port instance (NPE A,B,C) to the two time stamping channels.
I assume you mean this:
+ * PHYSICAL_ID(p->id) ?
+ * TODO - Figure out correct mapping.
Unfortunately I can's find this information in the devel manual. I think
there are 3 channels (not two), each for one Ethernet port. IXP465 can
have a port on each NPE.
PHYSICAL_ID etc. are described at the start of the file:
* logical port 0x00 0x10 0x20
* NPE 0 (NPE-A) 1 (NPE-B) 2 (NPE-C)
* physical PortId 2 0 1
This means the first port (usually "eth0") is connected to NPE-B, the
second port to NPE-C, and the third port to NPE-A (not available on
IXP42x).
Also, the manual says NPE-B can serve 3 additional Ethernet ports
(6 total).
I only have access to IXP425 (and 421) hardware. I think someone with
the actual IXP465 has to check the details.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: Kuwahara,T. @ 2011-01-10 20:45 UTC (permalink / raw)
To: john stultz
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <1294678145.3068.6.camel@work-vm>
On Tue, Jan 11, 2011 at 1:49 AM, john stultz <johnstul-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> Leapsecond processing is done via an absolute hrtimer. Thus when the
> time offset is set, the hrtimers that should have expired will fire
> (just like with settimeofday) and the adjustment will then be made.
How do you convert relative time to absolute time? It's not trivial
because TAI offset is also a variable.
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: Kuwahara,T. @ 2011-01-10 20:47 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <20110110071759.GA4864-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
On Mon, Jan 10, 2011 at 4:17 PM, Richard Cochran
<richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> the PTP Hardware Clocks for which this whole patch
> set was created in the first place will keep their time as TAI.
Are you sure of that? I don't have the standard handy (it's non-free,
right?) but it seems that the Annex B states differently. But that's
not the point anyway. My concern is that your patch not only adds the
useless (and broken) feature to the existing syscall but also makes a
permanent change to the public interface for your own use. That's
what I'm against. So if you stop touching the struct timex, I won't
complain anymore.
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-01-10 21:06 UTC (permalink / raw)
To: Kuwahara,T.
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <AANLkTikdg4Pb5c4wcCU3d3Eku=mpiW_TEkBz0A2VPdVp-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2011-01-11 at 05:45 +0900, Kuwahara,T. wrote:
> On Tue, Jan 11, 2011 at 1:49 AM, john stultz <johnstul-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> > Leapsecond processing is done via an absolute hrtimer. Thus when the
> > time offset is set, the hrtimers that should have expired will fire
> > (just like with settimeofday) and the adjustment will then be made.
>
> How do you convert relative time to absolute time? It's not trivial
> because TAI offset is also a variable.
I don't believe I understand what you're getting at.
The proposed interface is almost identical in functionality to a
userland application doing the following:
offset = my_calculate_offset();
clock_gettime(CLOCK_REALTIME, &now);
newtime = my_add_ts(now, offset);
settimeofday(&newtime, 0);
The only difference is that you avoid the error from the delay between
the gettime call and the settime call. It just adds the offset directly
to the CLOCK_REALTIME.
thanks
-john
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-01-10 21:11 UTC (permalink / raw)
To: Kuwahara,T.
Cc: Richard Cochran, linux-kernel, linux-api, netdev, Alan Cox,
Arnd Bergmann, Christoph Lameter, David Miller, Krzysztof Halasa,
Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <AANLkTimS0-ih=WZ_GvPi9NFjbYMT4OctWV943ri4GuTD@mail.gmail.com>
On Tue, 2011-01-11 at 05:47 +0900, Kuwahara,T. wrote:
> On Mon, Jan 10, 2011 at 4:17 PM, Richard Cochran
> <richardcochran@gmail.com> wrote:
> > the PTP Hardware Clocks for which this whole patch
> > set was created in the first place will keep their time as TAI.
>
> Are you sure of that? I don't have the standard handy (it's non-free,
> right?) but it seems that the Annex B states differently. But that's
> not the point anyway. My concern is that your patch not only adds the
> useless (and broken) feature to the existing syscall but also makes a
> permanent change to the public interface for your own use. That's
> what I'm against. So if you stop touching the struct timex, I won't
> complain anymore.
You still haven't explained *why* you're so protective of the timex and
adjtimex interfaces. While I do want to keep compatible the
functionality where possible, I don't see why Linux should be limited by
what other OSes do.
Injecting an offset to the system time seems like a reasonable thing for
adjtimex to do (rather then adding a new syscall). Further utilizing a
new mode bit for this functionality seems reasonable and cleaner then
your suggestions for utilizing existing mode bits in combined with other
magic bits. If there is a compelling reason why not to do this, do
please let us know! We might just agree with you after hearing it. :)
thanks
-john
^ permalink raw reply
* Re: panic in tg3 driver
From: Stephen Clark @ 2011-01-10 20:04 UTC (permalink / raw)
To: Matt Carlson; +Cc: Linux Kernel Network Developers, Michael Chan
In-Reply-To: <20110110192216.GA23741@mcarlson.broadcom.com>
On 01/10/2011 02:22 PM, Matt Carlson wrote:
> On Sun, Jan 09, 2011 at 02:30:50PM -0800, Stephen Clark wrote:
>
>> On 01/04/2011 09:54 AM, Stephen Clark wrote:
>>
>>> Hello,
>>>
>>>
>>> The hardware is an Acrosser AR-M0898B micro box.
>>> lspci
>>> 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
>>> 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
>>> Host Bridge
>>> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
>>> 00:0f.0 IDE interface: VIA Technologies, Inc. VT8251 Serial ATA
>>> Controller (rev
>>> 20)
>>> 00:0f.1 IDE interface: VIA Technologies, Inc.
>>> VT82C586A/B/VT82C686/A/B/VT823x/A/
>>> C PIPC Bus Master IDE (rev 07)
>>> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>>> Controller
>>> (rev 91)
>>> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
>>> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
>>> 00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
>>> 00:13.0 Host bridge: VIA Technologies, Inc. VT8251 Host Bridge
>>> 00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
>>> 02:08.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
>>> (rev 02)
>>> 02:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
>>> (rev 02)
>>> 80:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
>>> 80:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
>>> 81:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
>>> Fast Ethernet
>>> PCI Express (rev 02)
>>> 82:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
>>> Fast Ethernet
>>> PCI Express (rev 02)
>>>
>>> Kernel 2.6.36-2.el5.elrepo on an i686
>>>
>>> When I try to ifconfig either of the BCM5906M ports the system panics.
>>>
>>> Ideas, fixes ?
>>>
>>> [root@Z1010 ~]# modprobe tg3
>>> [root@Z1010 ~]# ifconfig eth2 2.2.2.2/24
>>> ------------[ cut here ]------------
>>> kernel BUG at drivers/net/tg3.c:4365!
>>> invalid opcode: 0000 [#1] PREEMPT SMP
>>> last sysfs file: /sys/class/net/eth3/address
>>> Modules linked in: tg3 xt_tcpudp ipt_LOG xt_limit xt_state
>>> iptable_mangle af_ke]
>>>
>>> Pid: 20303, comm: kworker/0:2 Not tainted 2.6.36-2.el5.elrepo #1
>>> CN700-8251/
>>> EIP: 0060:[<e1c62f19>] EFLAGS: 00010202 CPU: 0
>>> EIP is at tg3_tx_recover+0x1e/0x53 [tg3]
>>> EAX: deece4c0 EBX: dfa9c000 ECX: deece4c0 EDX: ffffffff
>>> ESI: deece4c0 EDI: deece500 EBP: c1801f38 ESP: c1801f30
>>> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>>> Process kworker/0:2 (pid: 20303, ti=c1801000 task=df0105d0
>>> task.ti=dee62000)
>>> Stack:
>>> dfa9c000 00000000 c1801f6c e1c630be c1801f6c deece4c0 00000840 00000000
>>> <0> df251cc0 00000005 00000000 df979800 deece500 deece4c0 00000040
>>> c1801f94
>>> <0> e1c661e5 00000000 00000040 c1801f88 e09df1d2 00000000 deece500
>>> dfab4000
>>> Call Trace:
>>> [<e1c630be>] ? tg3_tx+0x157/0x1a2 [tg3]
>>> [<e1c661e5>] ? tg3_poll_work+0x2b/0x10b [tg3]
>>> [<e09df1d2>] ? ssb_write32+0x11/0x14 [b44]
>>> [<e1c662f9>] ? tg3_poll+0x34/0x9a [tg3]
>>> [<c0674058>] ? net_rx_action+0x7e/0x11c
>>> [<c04409c9>] ? __do_softirq+0x85/0x10c
>>> [<c0440944>] ? __do_softirq+0x0/0x10c
>>> <IRQ>
>>> [<c04404ef>] ? _local_bh_enable_ip+0x68/0x87
>>> [<c044051b>] ? local_bh_enable_ip+0xd/0xf
>>> [<c046593b>] ? __raw_spin_unlock_bh+0x1c/0x1e
>>> [<c06fa4f2>] ? _raw_spin_unlock_bh+0xd/0xf
>>> [<e1c6281f>] ? spin_unlock_bh+0xd/0xf [tg3]
>>> [<e1c62cbe>] ? tg3_full_unlock+0x10/0x12 [tg3]
>>> [<e1c664c7>] ? tg3_reset_task+0xd7/0xe3 [tg3]
>>> [<c044ec37>] ? process_one_work+0x10b/0x1bc
>>> [<e1c663f0>] ? tg3_reset_task+0x0/0xe3 [tg3]
>>> [<c044fd41>] ? worker_thread+0x77/0xf9
>>> [<c0453048>] ? kthread+0x60/0x65
>>> [<c044fcca>] ? worker_thread+0x0/0xf9
>>> [<c0452fe8>] ? kthread+0x0/0x65
>>> [<c040337e>] ? kernel_thread_helper+0x6/0x10
>>> Code: f0 e8 88 ff ff ff 8d 65 f8 5b 5e 5d c3 55 89 e5 56 53 0f 1f 44
>>> 00 00 f6 8
>>> EIP: [<e1c62f19>] tg3_tx_recover+0x1e/0x53 [tg3] SS:ESP 0068:c1801f30
>>> ---[ end trace 82381e9b93e397ad ]---
>>> Kernel panic - not syncing: Fatal exception in interrupt
>>> Pid: 20303, comm: kworker/0:2 Tainted: G D
>>> 2.6.36-2.el5.elrepo #1
>>> Call Trace:
>>> [<c043b3cd>] panic+0x62/0x15d
>>> [<c06fb7d1>] oops_end+0x99/0xa8
>>> [<e1c62f19>] ? tg3_tx_recover+0x1e/0x53 [tg3]
>>> [<c0405a62>] die+0x58/0x5e
>>>
>>> Thanks,
>>> Steve
>>>
>>>
>> Additonal info I compiled the latest kernel 2.6.37-rc8+ and still have the problem.
>> Also boot with noapic I see this in the dmesg log and interrupts are increasing
>> like crazy:
>> tg3.c:v3.115 (October 14, 2010)
>> tg3 0000:81:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
>> tg3 0000:81:00.0: setting latency timer to 64
>> tg3 0000:81:00.0: PCI: Disallowing DAC for device
>> tg3 0000:81:00.0: eth2: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
>> ress 00:02:b6:36:d1:39
>> tg3 0000:81:00.0: eth2: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
>> [0])
>> tg3 0000:81:00.0: eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> tg3 0000:81:00.0: eth2: dma_rwctrl[76180000] dma_mask[32-bit]
>> tg3 0000:82:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
>> tg3 0000:82:00.0: setting latency timer to 64
>> tg3 0000:82:00.0: PCI: Disallowing DAC for device
>> tg3 0000:82:00.0: eth3: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
>> ress 00:02:b6:36:d1:3a
>> tg3 0000:82:00.0: eth3: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
>> [0])
>> tg3 0000:82:00.0: eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> tg3 0000:82:00.0: eth3: dma_rwctrl[76180000] dma_mask[32-bit]
>> tg3 0000:81:00.0: irq 40 for MSI/MSI-X
>> tg3 0000:81:00.0: eth2: No interrupt was generated using MSI. Switching to INTx
>> mode. Please report this failure to the PCI maintainer and include system chipse
>> t information
>> ADDRCONF(NETDEV_UP): eth2: link is not ready
>> [root@Z1010 ~]# cat /proc/interrupts
>> CPU0
>> 0: 162 XT-PIC-XT-PIC timer
>> 1: 2 XT-PIC-XT-PIC i8042
>> 2: 0 XT-PIC-XT-PIC cascade
>> 3: 1 XT-PIC-XT-PIC
>> 4: 4863 XT-PIC-XT-PIC serial
>> 6: 2 XT-PIC-XT-PIC floppy
>> 7: 5 XT-PIC-XT-PIC ehci_hcd:usb1, uhci_hcd:usb3
>> 8: 0 XT-PIC-XT-PIC rtc0
>> 9: 0 XT-PIC-XT-PIC acpi
>> 10: 2334234 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>>
>> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
>> 10: 18388914 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
>> 10: 18901627 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
>>
>> --
>>
>> "They that give up essential liberty to obtain temporary safety,
>> deserve neither liberty nor safety." (Ben Franklin)
>>
>> "The course of history shows that as a government grows, liberty
>> decreases." (Thomas Jefferson)
>>
> I think drivers/net/tg3.c:4365 is at the line that reads
> "spin_lock(&tp->lock);" in tg3_tx_recover. Can you verify?
>
>
tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &phy2);
in static void tg3_serdes_parallel_detect(struct tg3 *tp)
The driver version is:
#define DRV_MODULE_NAME "tg3"
#define TG3_MAJ_NUM 3
#define TG3_MIN_NUM 115
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: [PATCH 1/5] netdev: bfin_mac: clean up printk messages
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-1-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:29 -0500
> Use netdev_* and pr_* helper funcs for output rather than printk.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/5] netdev: bfin_mac: mark setup_system_regs as static
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-2-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:30 -0500
> No need for this to be exported since it is only used in this driver.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 3/5] netdev: bfin_mac: drop unused Mac data
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-3-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:31 -0500
> We don't use this local "Mac" data anywhere (since we rely on the
> netdev's storage), so punt it.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 4/5] netdev: bfin_mac: let boards set vlan masks
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1294664073-1950-4-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:32 -0500
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 5/5] netdev: bfin_mac: disable hardware checksum if writeback cache is enabled
From: David Miller @ 2011-01-10 21:31 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, sonic.zhang
In-Reply-To: <1294664073-1950-5-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 Jan 2011 07:54:33 -0500
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> With writeback caches, corrupted RX packets will be sent up the stack
> without any error markings.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] qlcnic: fix flash fw version read
From: David Miller @ 2011-01-10 21:35 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1294654523-3085-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 10 Jan 2011 02:15:21 -0800
> Driver is reading flash fw version from defined address, this address
> may be invalid. Indeed Driver should read address for fw version through
> flash layout table. Flash layout table has defined region and address for
> fw version address should be read from fw image region.
>
> Driver has check for old firmware, this bug can cause driver load fail.
> This patch will try to read fw version from flash image region, if that fails,
> read from defined address.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] qlcnic: fix ethtool diagnostics test
From: David Miller @ 2011-01-10 21:35 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, sony.chacko
In-Reply-To: <1294654523-3085-3-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 10 Jan 2011 02:15:22 -0800
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> IRQ diag test was getting executed only when both register test
> and link test passed. The test should get executed if ETH_TEST_FL_OFFLINE
> flag is set.
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] qlcnic: change module parameter permissions
From: David Miller @ 2011-01-10 21:35 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1294654523-3085-4-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 10 Jan 2011 02:15:23 -0800
> o Updating module parameter after driver load is not supported
> except auto_fw_reset parameter. Changing these parameter after
> driver load, can have weird result.
>
> o Update driver version to 5.0.15.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] net/dummy: add device group parameter
From: David Miller @ 2011-01-10 21:37 UTC (permalink / raw)
To: ddvlad; +Cc: netdev, hadi, opurdila
In-Reply-To: <1294659524-22509-3-git-send-email-ddvlad@rosedu.org>
From: Vlad Dogaru <ddvlad@rosedu.org>
Date: Mon, 10 Jan 2011 13:38:43 +0200
> When inserting the dummy module, the user can specify the group of the
> dummy devices. This avoids manually moving the newly created pseudo
> devices to a different group.
>
> Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
The amount of hacks people wish to add to the dummy driver is one step
away from amazing.
Just use the standard APIs to add dummy devices to the group you want,
instead of these ad-hoc device specific module parameters.
Thanks.
^ permalink raw reply
* [PATCH net-26] cxgb4vf: fix mailbox data/control coherency domain race
From: Casey Leedom @ 2011-01-10 21:51 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
For the VFs, the Mailbox Data "registers" are actually backed by
T4's "MA" interface rather than PL Registers (as is the case for
the PFs). Because these are in different coherency domains, the
write to the VF's PL-register-backed Mailbox Control can race in
front of the writes to the MA-backed VF Mailbox Data "registers".
So we need to do a read-back on at least one byte of the VF Mailbox
Data registers before doing the write to the VF Mailbox Control
register.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/t4vf_hw.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4vf/t4vf_hw.c b/drivers/net/cxgb4vf/t4vf_hw.c
index e4bec78..0f51c80 100644
--- a/drivers/net/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/cxgb4vf/t4vf_hw.c
@@ -147,9 +147,20 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
/*
* Write the command array into the Mailbox Data register array and
* transfer ownership of the mailbox to the firmware.
+ *
+ * For the VFs, the Mailbox Data "registers" are actually backed by
+ * T4's "MA" interface rather than PL Registers (as is the case for
+ * the PFs). Because these are in different coherency domains, the
+ * write to the VF's PL-register-backed Mailbox Control can race in
+ * front of the writes to the MA-backed VF Mailbox Data "registers".
+ * So we need to do a read-back on at least one byte of the VF Mailbox
+ * Data registers before doing the write to the VF Mailbox Control
+ * register.
*/
for (i = 0, p = cmd; i < size; i += 8)
t4_write_reg64(adapter, mbox_data + i, be64_to_cpu(*p++));
+ t4_read_reg(adapter, mbox_data); /* flush write */
+
t4_write_reg(adapter, mbox_ctl,
MBMSGVALID | MBOWNER(MBOX_OWNER_FW));
t4_read_reg(adapter, mbox_ctl); /* flush write */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-26] cxgb4vf: fix mailbox data/control coherency domain race
From: David Miller @ 2011-01-10 21:56 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <1294696261-21209-1-git-send-email-leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 10 Jan 2011 13:51:01 -0800
> For the VFs, the Mailbox Data "registers" are actually backed by
> T4's "MA" interface rather than PL Registers (as is the case for
> the PFs). Because these are in different coherency domains, the
> write to the VF's PL-register-backed Mailbox Control can race in
> front of the writes to the MA-backed VF Mailbox Data "registers".
> So we need to do a read-back on at least one byte of the VF Mailbox
> Data registers before doing the write to the VF Mailbox Control
> register.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] UDPCP Communication Protocol
From: Hagen Paul Pfeifer @ 2011-01-10 22:28 UTC (permalink / raw)
To: Stefani Seibold; +Cc: Eric Dumazet, linux-kernel, akpm, davem, netdev
In-Reply-To: <1293918016.28646.3.camel@wall-e>
* Stefani Seibold | 2011-01-01 22:40:16 [+0100]:
>> > I cannot fix it, because the information is still lost, and i need it.
>> >
>>
>> You can fix it. Really. If not, you can pay me and I'll fix it for you.
>>
>
>I am a poor girl, so i did it by me self. Hope you like the new
>approach.
Stefani, Eric try to support your effort and helps you the whole time. You
should trust him and align your effort more on his tips and the way the
kernel is developed.
^ permalink raw reply
* Re: [PATCH] UDPCP Communication Protocol
From: Jesper Juhl @ 2011-01-10 22:53 UTC (permalink / raw)
To: stefani; +Cc: linux-kernel, akpm, davem, netdev
In-Reply-To: <1293787785-3834-1-git-send-email-stefani@seibold.net>
stefani@seibold.net wrote:
+static int udpcp_xmit(struct sock *sk, struct udpcp_dest *dest)
+{
+ struct udpcp_sock *usk = udpcp_sk(sk);
+ int ret;
+
+ ret = _udpcp_xmit(sk, dest);
+
+ if (dest->xmit_wait) {
+ dest->tx_time = jiffies;
+
+ if (!timer_pending(&usk->timer))
+ udpcp_timer(sk, dest->tx_time + usk->tx_timeout);
+ }
+ return ret;
+}
Wouldn't this be slightly nicer as
static int udpcp_xmit(struct sock *sk, struct udpcp_dest *dest)
{
int ret = _udpcp_xmit(sk, dest);
if (dest->xmit_wait) {
struct udpcp_sock *usk = udpcp_sk(sk);
dest->tx_time = jiffies;
if (!timer_pending(&usk->timer))
udpcp_timer(sk, dest->tx_time + usk->tx_timeout);
}
return ret;
}
??
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ 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