It appears that some PCI-E bridges do the wrong thing in the presense of
CRS Software Visibility and MMCONFIG. In particular, it looks like an
ATI bridge (device ID 7936) will return 0001 in the vendor ID field of
any bridged devices indefinitely.
Not enabling CRS SV avoids the problem, and as we currently do not
really make good use of the feature anyway (we just time out rather than
do any threaded discovery as suggested by the CRS specs), we're better
off just not enabling it.
This should fix a slew of problem reports with random devices (generally
graphics adapters or fairly high-performance networking cards, since it
only affected PCI-E) not getting properly recognized on these AMD systems.
If we really want to use CRS-SV, we may end up eventually needing a
whitelist of systems where this should be enabled, along with some kind
of "pcibios_enable_crs()" query to call the system-specific code.
Suggested-by: Loic Prylli <loic@myri.com>
Tested-by: Kai Ruhnau <kai@tragetaschen.dyndns.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/proc/acpi/alarm can't be set correctly, here is a sample:
[root@localhost /]# echo "2006 09" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
2007-12-09 09:09:09
[root@localhost /]# echo "2006 04" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
2007-12-04 04:04:04
[root@localhost /]#
Obviously, it is wrong, it should consider it as an invalid input.
after this patch:
[root@localhost /]# echo "2008 09" > /proc/acpi/alarm
-bash: echo: write error: Invalid argument
[root@localhost /]#
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
In function acpi_system_write_alarm in file drivers/acpi/sleep/proc.c,
big sec, min, hr, mo, day and yr are counted twice to get reasonable
values, that is very superfluous, we can do that only once.
In additon, /proc/acpi/alarm can set a related value which can be
specified as YYYY years MM months DD days HH hours MM minutes SS
senconds, it isn't a date, so you can specify as +0000-00-00 96:00:00
, that means 3 days later, current code can't handle such a case.
This patch removes unnecessary code and does with the aforementioned
situation.
Before applying this patch:
[root@localhost /]# cat /proc/acpi/alarm
2007-12-00 00:00:00
[root@localhost /]# echo "0000-00-00 96:180:180" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
0007-12-02 **:**:**
[root@localhost /]#
After applying this patch:
[root@localhost ~]# echo "2007-12-00 00:00:00" > /proc/acpi/alarm
[root@localhost ~]# cat /proc/acpi/alarm
2007-12-00 00:00:00
[root@localhost ~]# echo "0000-00-00 96:180:180" > /proc/acpi/alarm
[root@localhost ~]# cat /proc/acpi/alarm
0007-12-04 03:03:00
[root@localhost ~]#
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The xcryptecb instruction always processes an even number of blocks so
we need to ensure th existence of an extra block if we have to process
an odd number of blocks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Move veth.h from net/ to linux/ since it is a user api, and add it to
user header processing Kbuild.
[ Use header-y as suggested by Sam Ravnborg. -DaveM ]
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a trivial fix of debug message.
When a persist flag is set, the message should say "enabled".
Signed-off-by: Toyo Abe <tabe@miraclelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When creating a new volume, do not forget to increment the
vol_count variable.
Also, users are not interested in internal volumes, so do not show
them in the volumes_count sysfs file.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
UBI allows to specify MTD device name or number when the module is being
loaded. When parsing MTD device identity string, it first tries to treat
it as device NAME, and if that fails, it treats it as device number.
Make it vice-versa as this is more logical and makes less troubles when
you have an MTD device named "1" and try to load mtd1 which has different
name. This is especially easy to hit when gluebi is enabled.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Introduce a separate mutex which serializes volumes checking,
because we cammot really use volumes_mutex - it cases reverse
locking problems with mtd_tbl_mutex when gluebi is used -
thanks to lockdep.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Prepare the attach and detach functions to by used outside of
module initialization:
* detach function checks reference count before detaching
* it kills the background thread as well
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This is one more step on the way to "removable" UBI devices. It
adds reference counting for UBI devices. Every time a volume on
this device is opened - the device's refcount is increased. It
is also increased if someone is reading any sysfs file of this
UBI device or of one of its volumes.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This patch is a preparation to make UBI devices dynamic. It
adds an UBI control device which has dynamically allocated
major number and registers itself as "ubi_ctrl". It does not
do anything so far. The idea is that this device will allow
to attach/detach MTD devices from userspace.
This is symilar to what the Linux device mapper has.
The next things to do are:
* Fix UBI, because it now assumes UBI devices cannot go away
* Implement control device ioctls which will attach/detach MTD
devices
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
The flush function should finish all the pending jobs. But if
somebody else is doing a work, this function should wait and let
it finish.
This patche uses rw semaphore for synchronization purpose - it
just looks quite convinient.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
When the WL worker is moving an LEB, the volume might go away
occasionally. UBI does not handle these situations correctly.
This patch introduces a new mutex which serializes wear-levelling
worker and the the 'ubi_wl_put_peb()' function. Now, if one puts
an LEB, and its PEB is being moved, it will wait on the mutex.
And because we unmap all LEBs when removing volumes, this will make
the volume remove function to wait while the LEB movement
finishes.
Below is an example of an oops which should be fixed by this patch:
Pid: 9167, comm: io_paral Not tainted (2.6.24-rc5-ubi-2.6.git #2)
EIP: 0060:[<f884a379>] EFLAGS: 00010246 CPU: 0
EIP is at prot_tree_del+0x2a/0x63 [ubi]
EAX: f39a90e0 EBX: 00000000 ECX: 00000000 EDX: 00000134
ESI: f39a90e0 EDI: f39a90e0 EBP: f2d55ddc ESP: f2d55dd4
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process io_paral (pid: 9167, ti=f2d54000 task=f72a8030 task.ti=f2d54000)
Stack: f39a95f8 ef6aae50 f2d55e08 f884a511 f88538e1 f884ecea 00000134 00000000
f39a9604 f39a95f0 efea8280 00000000 f39a90e0 f2d55e40 f8847261 f8850c3c
f884eaad 00000001 000000b9 00000134 00000172 000000b9 00000134 00000001
Call Trace:
[<c0105227>] show_trace_log_lvl+0x1a/0x30
[<c01052e2>] show_stack_log_lvl+0xa5/0xca
[<c01053d6>] show_registers+0xcf/0x21b
[<c0105648>] die+0x126/0x224
[<c0119a62>] do_page_fault+0x27f/0x60d
[<c037dd62>] error_code+0x72/0x78
[<f884a511>] ubi_wl_put_peb+0xf0/0x191 [ubi]
[<f8847261>] ubi_eba_unmap_leb+0xaf/0xcc [ubi]
[<f8843c21>] ubi_remove_volume+0x102/0x1e8 [ubi]
[<f8846077>] ubi_cdev_ioctl+0x22a/0x383 [ubi]
[<c017d768>] do_ioctl+0x68/0x71
[<c017d7c6>] vfs_ioctl+0x55/0x271
[<c017da15>] sys_ioctl+0x33/0x52
[<c0104152>] sysenter_past_esp+0x5f/0xa5
=======================
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Make the code more consistent by requiring the caller to lock the
ubi->volume_mutex, because this is what we do for updates.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Add ref_count field to UBI volumes and remove weired "vol->removed"
field. This way things are better understandable and we do not have
to do whold show_attr operation under spinlock.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
If we fail halfway through sysfs file creation, we may just call
sysfs remove function and it will delete all the files we created.
For non-existing files it will also be OK - the remove functions
just return -ENOENT.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This patch fixes error codes of the functions - if the device number
is out of range, -EINVAL should be returned. It also removes unneeded
try_module_get call from the open by name function.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Error path in volume creation is bogus. First of, it ovverrides the
'err' variable and returns zero to the caller. Second, ubi_assert()
in the release function is wrong.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
When a volume is opened, get its kref via get_device() call.
And put the reference when closing the volume. With this, we
may have a bit saner volume delete.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Pass volume description object to the EBA function which makes
more sense, and EBA function do not have to find the volume
description object by volume ID.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Similarly to ltree_entry_slab, it makes more sense to create
and destroy ubi_wl_entry slab on module initialization/exit.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Since the ltree_entry slab cache is a global entity, which is
used by all UBI devices, it is more logical to create it on
module initialization time and destro on module exit time.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This patch silences the following warning :
drivers/mtd/ubi/vmt.c:73: warning: 'ret' may be used uninitialized in this function
gcc can't see that we always initialize ret in all situations where it is
actually used. The one case where it's not initialized is when we BUG(),
but gcc doesn't know that we won't then continue and use an uninitialized
'ret'.
This patch results in code that does exactely the same as before, but it
also makes gcc shut up, so we generate one less line of warning noise.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
The idea of this interface belongs to Adrian Hunter. The
interface is extremely useful when one has to have a guarantee
that an LEB will contain all 0xFFs even in case of an unclean
reboot. UBI does have an 'ubi_leb_erase()' call which may do
this, but it is stupid and ineffecient, because it flushes whole
queue. I should be re-worked to just be a pair of unmap,
map calls.
The user of the interfaci is UBIFS at the moment.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
First allocate the necessary eraseblocks, then the optional ones.
Otherwise it allocates all PEBs for bad EB handling, and fails
on then following EBA LEB allocation.
Reported-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
When NAND detects an ECC error, it returns -EBADMSG. It does not
stop reading requested data if one page has an ECC error, it keeps
going and reads all the requested data. If it fails to read all
the data, it does not return -EBADMSG, but returns the error code
which reflects the reason of the failure.
But some drivers may have bugs (e.g., OneNAND had) and stop reading
after the first ECC error, so it returns -EBADMSG. In turn, UBI
propagates this up to the caller. The caller will treat this as
"all the requested data was read, but there was an ECC error".
So we change the error code to -EIO if it is -EBADMSG and the read
length is less then the requested length. We also add an assertion,
so if UBI debugging is enabled, UBI will bug.
Pointed-to-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
commit 528a572dae ("ide: add ->chipset field
to ide_pci_device_t") broke hwif->chipset setup (it is now set to ide_cmd646
for CMD648 instead of CMD646). It seems that the breakage happend while
I was moving patches around (cmd64x_chipsets[] entries for CMD646 and CMD648
are identical except for 'name' field). Fix it and bump driver version.
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Mask 'ireason' variable so only the valid interrupt reason bits
will be reported on "drive appears confused" error.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Mask 'ireason' variable with 0x3 so the valid interrupt reason value
is passed to cdrom_write_check_ireason() for checking.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
