The following commit introduced a compile error since it removed
the implementation of smp_85xx_basic_setup:
commit 77c0a700c1
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri Aug 28 14:25:04 2009 +1000
powerpc: Properly start decrementer on BookE secondary CPUs
Make it so that smp_ops probe() and setup_cpu() can be set to NULL.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The OF helpers look like nanodoc but are missing the header. Fix this and a
typo (s/nad/and/) while we are here.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Currently we are not including randomized stack size when calculating
mmap_base address in arch_pick_mmap_layout for topdown case. This might
cause that mmap_base starts in the stack reserved area because stack is
randomized by 1GB for 64b (8MB for 32b) and the minimum gap is 128MB.
If the stack really grows down to mmap_base then we can get silent mmap
region overwrite by the stack values.
Let's include maximum stack randomization size into MIN_GAP which is
used as the low bound for the gap in mmap.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
LKML-Reference: <1252400515-6866-1-git-send-email-mhocko@suse.cz>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Stable Team <stable@kernel.org>
As reported in <http://bugs.debian.org/511703> and
<http://bugs.debian.org/515982>, kernels with paravirt-alternatives
enabled crash in text_poke_early() on at least some 486-class
processors.
The problem is that text_poke_early() itself uses inline functions
affected by paravirt-alternatives and so will modify instructions that
have already been prefetched. Pentium and later processors will
invalidate the prefetched instructions in this case, but 486-class
processors do not.
Change sync_core() to limit prefetching on 486-class (and 386-class)
processors, and move the call to sync_core() above the call to the
modifiable local_irq_restore().
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
LKML-Reference: <1252547631.3423.134.camel@localhost>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
With all the other lid pieces in place, it's easy to generate a uevent
for the LVDS connector just like we do for other outputs. Should make
lid open/close fit in with the rest of a userland based output
reconfiguration scheme.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
We can't load or hotplug detect LVDS like we can other outputs, but if
there's a lid device present we can use it as a proxy. This allows the
LFP state to be determined at ->detect time, making configurations
requiring manual intervention today "just work" assuming the lid device
status is correct.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Some laptop platforms will disable pipes and/or planes at lid close time
and not restore them when the lid is opened again. So catch the lid
event, and if the lid was opened, force a mode restore.
Fixes fdo bug #21230.
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Some drivers need to know when a lid event occurs and get the current
status. This can be useful for when a platform firmware clobbers some
hardware state at lid time, and a driver needs to restore things when
the lid is opened again.
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Commit b8313b6da7 ("dm log: remove incorrect
field from userspace table output") added a call to strstr() with a
single-character "needle" string parameter.
Unfortunately some versions of gcc replace such calls to strstr() by calls
to strchr() behind our back. This causes linking errors if strchr() is
defined as an inline function in <asm/string.h> (e.g. on m68k):
| WARNING: "strchr" [drivers/md/dm-log-userspace.ko] undefined!
Avoid this by explicitly calling strchr() instead.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This avoids updating the superblock write time when we are mounting
the root file system read/only but we need to replay the journal; at
that point, for people who are east of GMT and who make their clock
tick in localtime for Windows bug-for-bug compatibility, and this will
cause e2fsck to complain and force a full file system check.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The dynamic function tracer relys on the macro P6_NOP5 always being
an atomic NOP. If for some reason it is changed to be two operations
(like a nop2 nop3) it can faults within the kernel when the function
tracer modifies the code.
This patch adds a comment to note that the P6_NOPs are expected to
be atomic. This will hopefully prevent anyone from changing that.
Reported-by: Mathieu Desnoyer <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Small error in the "dd" command example, "out=" should be "of=".
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This weird perf trace output:
cc1-9943 [001] 2802.059479616: sched_stat_wait: task: as:9944 wait: 2801938766276 [ns]
Is caused by setting one component field of the delta to zero
a bit too early. Move it to later.
( Note, this does not affect the NEW_FAIR_SLEEPERS interactivity bug,
it's just a reporting bug in essence. )
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Nikos Chantziaras <realnc@arcor.de>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <4AA93D34.8040500@arcor.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Split __phys_addr out into its own file so we can disable
-fstack-protector in a fine-grained fashion. Also it doesn't
have terribly much to do with the rest of ioremap.c.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Nikos Chantziaras and Jens Axboe reported that turning off
NEW_FAIR_SLEEPERS improves desktop interactivity visibly.
Nikos described his experiences the following way:
" With this setting, I can do "nice -n 19 make -j20" and
still have a very smooth desktop and watch a movie at
the same time. Various other annoyances (like the
"logout/shutdown/restart" dialog of KDE not appearing
at all until the background fade-out effect has finished)
are also gone. So this seems to be the single most
important setting that vastly improves desktop behavior,
at least here. "
Jens described it the following way, referring to a 10-seconds
xmodmap scheduling delay he was trying to debug:
" Then I tried switching NO_NEW_FAIR_SLEEPERS on, and then
I get:
Performance counter stats for 'xmodmap .xmodmap-carl':
9.009137 task-clock-msecs # 0.447 CPUs
18 context-switches # 0.002 M/sec
1 CPU-migrations # 0.000 M/sec
315 page-faults # 0.035 M/sec
0.020167093 seconds time elapsed
Woot! "
So disable it for now. In perf trace output i can see weird
delta timestamps:
cc1-9943 [001] 2802.059479616: sched_stat_wait: task: as:9944 wait: 2801938766276 [ns]
That nsec field is not supposed to be that large. More digging
is needed - but lets turn it off while the real bug is found.
Reported-by: Nikos Chantziaras <realnc@arcor.de>
Tested-by: Nikos Chantziaras <realnc@arcor.de>
Reported-by: Jens Axboe <jens.axboe@oracle.com>
Tested-by: Jens Axboe <jens.axboe@oracle.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <4AA93D34.8040500@arcor.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
When the output device is LVDS, maybe the pixel clock of adjusted_mode will be
less than that in mode. In such case it will set the incorrect multipler factor
in DPLL_MD register.
So the dpll_md_reg will be reset when the output type is non-SDVO
https://bugs.freedesktop.org/show_bug.cgi?id=22761
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewd-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
When the sdvo device is detected as SDVO-LVDS, we will check whether the
brightness is supported by issue SDVO enhancement command.
If it is supported, we will add the brightness property and then brightness
can be adjusted.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
When the sdvo device is detected as SDVO-TV, we will check whether the
sepecific picture enhancement is supported. If it is supported, we will
add the corresponnding property for SDVO-TV. We will add the following
property for the SDVO-TV enhancements if they are supported:
* Contrast/Brightness/Saturation/Hue.
* left/right/top/bottom margin: This is implemented by using the
horizontal/vertical overscan enhancements. When the overscan
enhancements are supported, the above properties will be added. This is
to be compatible with what we have done in integrated-TV.
* horizontal pos/vertical pos.
http://bugs.freedesktop.org/show_bug.cgi?id=22891
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
A new ring implementation and the addition of raid functionality
constitutes a bump in the driver major version number.
Signed-off-by: Maciej Sosnowski <maciej.sosnowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This fixes one cause of an occational problem when unloading
libfc where the exchange manager pool doesn't have all items freed.
The existing WARN_ON(mp->total_exches <= 0) isn't hit.
However, note that total_exches is decremented when the
exchange is completed, and it can be held with a refcnt
for a while after that.
I'm not sure what the offending exchange is, but I suspect
it is an incoming request, because outgoing state machines
should be all stopped at this point.
Note that although receive is stopped before the exchange
manager is freed, there could still be active threads
handling received frames.
This patch flushes the queues by allocating a new skb
and sending it through, and have the thread handle
this new skb specially. This is similar to the way the work
queues are flushed now by putting work items in them and waiting
until they make it through the queue.
An skb->destructor function is used to inform us of
the completion of the flush, and the fr_dev() is left
NULL to indicate to fcoe_percpu_receive_thread() that
the skb should be just freed. There's already a check
for the lp being NULL which prints a message.
We skip printing the message if the destructor is for flushing.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
I saw an lport debug message from the exchange manager saying:
"lport 70500: Received response for out of range oxid:ffff"
A trace showed this was a BA_RJT sent due to an incoming ABTS
which arrived on an unknown exchange. So, the sender of the
BA_RJT was in error, but in this case, both the initiator and
responder were the same machine.
The OX_ID and RX_ID should not have been reversed in this case.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
When an RSCN indicates changes to individual remote ports,
don't blindly log them out and then back in. Instead, determine
whether they're still in the directory, by doing GPN_ID.
If that is successful, call login, which will send ADISC and reverify,
otherwise, call logoff. Perhaps we should just delete the rport,
not send LOGO, but it seems safer.
Also, fix a possible issue where if a mix of records in the RSCN
cause us to queue disc_ports for disc_single and then we decide
to do full rediscovery, we leak memory for those disc_ports queued.
So, go through the list of disc_ports even if doing full discovery.
Free the disc_ports in any case. If any of the disc_single() calls
return error, do a full discovery.
The ability to fill in GPN_ID requests was added to fc_ct_fill().
For this, it needs the FC_ID to be passed in as an arg.
The did parameter for fc_elsct_send() is used for that, since the
actual D_DID will always be 0xfffffc for all CT requests so far.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The local port facility has been replying to ADISC requests without
looking to see if the remote port is logged in. This is incorrect.
An ADISC request requires PLOGI first. It should be rejected if
the sending remote port is not logged in.
This is like other incoming requests that require login, all of
which should be handled in the remote port module.
Move the ADISC request handling from fc_lport.c to fc_rport.c.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
When rport_login is called on an rport that is already thought
to be logged in, use ADISC. If that fails, redo PLOGI.
This is less disruptive after fabric changes that don't affect
the state of the target.
Implement the sending of ADISC via fc_els_fill.
Add ADISC state to the rport state machine. This is entered from READY
and returns to READY after successful completion. If it fails, the rport
is either logged off and deleted or re-does PLOGI.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
fc_rport_logo_resp() had a call to fc_rport_enter_rtv() if the
LOGO was accepted. This must've been a copy/paste mistake, but
it didn't matter since we don't stay in the LOGO state long enough
to hit this code.
Change fc_rport_logo_resp() to just enter the delete state
no matter what.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
After a quick link flap, a target was seen to send us a LOGO.
Apparently, it saw an RSCN reporting that we had dropped out of the
fabric after we had logged back into it.
This is likely in larger fabrics (more than 2 FC switches) after
a quick link flap at the initiator. Each link transition causes
an port-specific RSCN to the target. After the link comes back up,
the initiator successfully discovers and does a PLOGI to the target
before the target sees the first RSCN reporting the initiator is gone,
and it sends a LOGO. The target may see a subsequent RSCN saying the
port is back, but probably wouldn't send a PLOGI and leaves it
up to the initiator to re-login.
An RSCN can be delayed by the switches due to software layers but a
PLOGI is forwarded in hardware causing the PLOGI to beat the RSCN.
If a remote port is in the discovered set and sends a LOGO, re-login to it.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
When receiving an ELS request, if the request isn't recognized,
the unsupported operation error should be given even if the port
is not found or not logged in.
Also, the LOGO request shouldn't give the login-required explanation.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
libfc receives PLOGIs from switches which are trying to discover what
kind of devices are present, and from other initiators to find out
if we're a target.
As an initiator, some argue we don't need to handle incoming PLOGI
requests, and we currently reject them from unknown remote ports,
but accept them is we're in the middle of a PLOGI to the remote port.
For eventual target implementations, we want to handle them always.
For incoming PLOGI, don't fail if the rport_priv doesn't exist.
Just create it and go become READY without going through PRLI. If
PRLI occurs, then our roles will be set and we'll become READY again.
Also, allow incoming PRLI in RTV state.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Improve lport and rport debug messages to indicate whether
the response is LS_ACC, LS_RJT, closed, or timeout.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The rport_lookup function must be called while holding the disc_mutex.
Otherwise, the rdata could be deleted just after that by another thread.
All callers now check the state after grabbing the rdata rp_mutex.
Even though rport_lookup skips ports in DELETE state, it does that
without holding the rdata rp_mutex, so that the state may change.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
This moves the remote port lookup for incoming ELS requests into
fc_rport.c, in preparation for handing PLOGI and LOGO from
unknown rports.
This changes the arg to rport_recv_req from an rdata to an lport.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Don't trust previous roles, reset them when we receive a PRLI.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Currently these values are initialized by the callers. This was exposed
by a later patch that adds PLOGI request support. The patch failed to
initialize the new remote port's roles and it caused problems. This patch
has the rport_create routine initialize the identifiers and then the
callers can override them with real values.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
It's possible to "restart" discovery before it was started if
an RSCN is received early enough. We were jumping to 0
due to the disc_callback function pointer not getting set.
Don't restart discovery if disc_callback is NULL.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
The discovery code had a special-case for the point-to-point mode,
which used a bunch of code that wasn't really needed.
Now that rport_create adds the rport to the discovery list,
completely skip discovery for the point-to-point case.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
In fc_disc_gpn_ft_parse(), after fc_disc_done() is called, the
disc state is changed by setting buf_len = 0. This is wrong
since the discovery may have restarted. Instead, return
after calling fc_disc_done.
Also, return an error on memory allocation failure.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Currently fc_disc_timeout() restarts discovery only if it is not pending.
When the timer is scheduled, the discovery is left pending, so the
timeout never restarts it.
Fix by not checking for pending in the timeout handler.
If discovery is stopped and restarted in the meantime, the timeout will
be canceled.
Also, when a new discovery is started, the retry count wasn't cleared.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
On some switches, an empty zone causes GPN_FT to be rejected
with reason 9 (unable) explanation 7 (FC-4 types not registered),
which causes discovery to be retried endlessly. Treat this as
just an empty response and consider discovery complete.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Abhijeet Joglekar wrote: "In gpn_ft_resp, if the payload is short,
or unexpected response or out of sequence frame, then we just
return and do nothing. We should either enter fc_disc_done()
with DISC_EV_FAIL which will then restart any queued discovery
requests or call lport module which will reset local port,
or we should call fc_disc_error() so that the gpn_ft is retried.
The situation as is causes discovery to remain pending and never
get restarted, in these rare cases. We saw this due to a coding
bug in fc_disc before. The only ways it could happen would be
bugs, packet corruption or an FC fabric problem.
Change it to fail discovery. The local port will restart
discovery, although it probably should just give up until
the next link flap.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Code cleanup for fc_disc_gpn_ft_resp().
Some of the fc_disc.c code was poorly formatted. For example, some lines
in fc_disc.c were unnecessarily truncated and the buf variable could
be eliminated.
Also moved the increment of seq_count into fc_disc_gpn_ft_parse(), to
avoid doing it separately before each call.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
When an RSCN is received during fabric discovery, it restarts.
After the restart, disc->seq_count was incremented, so when
the first frame was received, it was considered "out of sequence".
That left the state disc->active, preventing further discoveries.
Change to advance the sequence count before parsing, so that it
won't be changed after a potential restart.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
When receiving an RSCN, do not log off all rports. This is
extremely disruptive. If, after the GPN_FT response, some
rports haven't been listed, delete them.
Add field disc_id to structs fc_rport_priv and fc_disc.
disc_id is an arbitrary serial number used to identify the
rports found by the latest discovery. This eliminates the need
to go through the rport list when restarting discovery.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Move the libfc remote port lookup function into fc_rport.c.
This seems like the best place for it.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Since the rport list maintenance is now done in the rport module,
the callback (and ops) are usually not necessary.
Allow rdata->ops to be left NULL if nothing needs
to be done in an event callback.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
