- 12 Jan, 2005 2 commits
-
-
Marcelo Tosatti authored
It seems to be general consensus that its safer to require all do_brk() callers to grab mmap_sem, and have do_brk to warn otherwise. This is what the following patch does. Similar version has been changed to in v2.4. Signed-off-by:Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
We had all the locking right, but we didn't check whether one of the threads now no longer needed to expand, so we could incorrectly _shrink_ the stack in the other thread instead (not only causing segfaults, but since we didn't do a proper unmap, we'd possibly leak pages too). So re-check the need for expand after getting the lock. Noticed by Paul Starzetz.
-
- 11 Jan, 2005 38 commits
-
-
Andi Kleen authored
Fix a long standing bug: numa=off only worked as last argument on the command line. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Fix K8 node discovery after nodemask changes. Signed-off-by:
-
Andi Kleen authored
Fix fallout from the recent nodemask_t changes. The node ids assigned in the SRAT parser were off by one. I added a new first_unset_node() function to nodemask.h to allocate IDs sanely. Signed-off-by:
-
Linus Torvalds authored
-
Hisashi Hifumi authored
I found bugs on error handlings in the functions arround the ext3 file system, which cause inadequate completions of synchronous write I/O operations when disk I/O failures occur. Both 2.4 and 2.6 have this problem. I carried out following experiment: 1. Mount a ext3 file system on a SCSI disk with ordered mode. 2. Open a file on the file system with O_SYNC|O_RDWR|O_TRUNC|O_CREAT flag. 3. Write 512 bytes data to the file by calling write() every 5 seconds, and examine return values from the syscall. from write(). 4. Disconnect the SCSI cable, and examine messages from the kernel. After the SCSI cable is disconnected, write() must fail. But the result was different: write() succeeded for a while even though messages of the kernel notified SCSI I/O error. By applying following modifications, the above problem was solved. Signed-off-by:Hisashi Hifumi <hifumi.hisashi@lab.ntt.co.jp> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Ingo Molnar authored
Make PREEMPT_BKL depend on PREEMPT alone - doesnt make sense to enable it on SMP && !PREEMPT kernels. (other than testing.) Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Dominik Brodowski authored
From: Manfred Spraul One bios assigns a small window for i/o access to yenta bridges. But there are Cardbus cards that needs lots of i/o ports. yenta usually honors the bios selected values, except if the bios choice is clearly invalid. The patch allows an override from the command line. Signed-Off-By:
Manfred Spraul <manfred@colorfullife.com> Signed-Off-By:
Dominik Brodowski <linux@brodo.de> Signed-off-by:
-
Dominik Brodowski authored
Also lock the ->exit() function in rsrc_nostatic Signed-off-by:
-
Dominik Brodowski authored
Remove the typedef'ing of struct resource_map. Signed-off-by:
-
Dominik Brodowski authored
Move the resource databases and the "mem_probe" flag into a struct specific to rsrc_nonstatic, as it is not needed for the SS_CAP_STATIC_MAP case. Saves a few bytes, and makes code clearer (in my opinion) Signed-off-by:
-
Dominik Brodowski authored
Make rsrc_nonstatic an independent module. Signed-off-by:
-
Dominik Brodowski authored
Move all the "nonstatic" code to a new file, and link it into pcmcia_core.ko Signed-off-by:
-
Dominik Brodowski authored
re-direct calls to adjust_resource_info for MEM and IO. Signed-off-by:
-
Dominik Brodowski authored
Calls to adjust_mem_region only happen if !SS_CAP_STATIC_MAP. Signed-off-by:
-
Dominik Brodowski authored
Calls to find_io_region only happen if !SS_CAP_STATIC_MAP. Signed-off-by:
-
Dominik Brodowski authored
Calls to adjust_io_region only happen if !SS_CAP_STATIC_MAP. Signed-off-by:
-
Dominik Brodowski authored
validate_mem() does only make sense for !SS_CAP_STATIC_MAP sockets. Therefore, re-direct validate_mem() calls only for those. The newly added redirection layer will allow for a "library" module named "rsrc_nonstatic" which contains the resource database handling code, and it will only need to be loaded for the drivers which need it. Signed-off-by:
-
Dominik Brodowski authored
Make the io and mem db per-socket, as different sockets may have different requirements or may not even need the resource db at all (SS_CAP_STATIC_MAP). Updated to make rsrc_mem_probe per-socket and to remove unnecessary and even broken check for empty list as per Russell King's suggestions. Signed-off-by:
-
Dominik Brodowski authored
Instead of "memory_cs", BIND_MTD, {FIRST,NEXT}_REGION, 2.6. kernels use the "pcmciamtd" driver which doesn't need these functions. Cardmgr still calls it in default configuration, so warn the user about changes necessary to /etc/pcmcia/config , and remove the now unused code. Signed-off-by: -
Dominik Brodowski authored
Remove the dev_info - contained name from struct client_t Signed-off-by:
-
Dominik Brodowski authored
Remove the no longer used "name" parameter from alloc_io_space, find_{io,mem}_region. Signed-off-by: -
Dominik Brodowski authored
Remove the "Attributes" entry of struct client_t -- _all_ in-kernel drivers did set it to INFO_IO_CLIENT | INFO_CARD_SHARE anyway, and the pcmcia core didn't care at all what this value was set to. Also, remove the setting of the respective request field in all in-kernel drivers -- the request structure is kept the same, though, to keep external drivers compiling. Signed-off-by:
-
Dominik Brodowski authored
PendingEvents is unused, so remove it Signed-off-by:
-
Dominik Brodowski authored
Remove the code marked as obsolete -- nobody complained. Signed-off-by:
-
Dominik Brodowski authored
From: Komuro <komurojun-mbn@nifty.com> Allow for ISA interrupt routing on pd6729 pcmcia sockets. This is necessary for correct operation of (certain?) PCI card readers. Signed-off-by:
-
Dominik Brodowski authored
From: Komuro <komurojun-mbn@nifty.com> line length fixes and x = x | y => x |= y cleanups Signed-off-by:
-
Dominik Brodowski authored
From: Komuro <komurojun-mbn@nifty.com> e-mail update Signed-off-by:
-
Dominik Brodowski authored
As per the default usage in the driver model, don't embed the bus name into the device name Signed-off-by:
-
Hirofumi Ogawa authored
I received report that transmission of Realtek 8139 doesn't work. The cause of this problem was CLKRUN protocols of laptop's TI 12xx CardBus bridge. CLKRUN is used for controlling the PCI clock by PCI devices (for power saving). If device has bug, probably it becomes the cause of stopping the PCI clock at an unexpected timing. In the problem of realtek 8139 case, the TX packet which the driver set to the device was not sent out (still pending state in device). If "disable_clkrun" is enabled, the problem of TX stopped occurring. So, I thought the cause is CLKRUN, and is hardware bug of Cardbus or realtek 8139. (8139 seems only can control by rewriting EEPROM) And looks like also http://support.microsoft.com/default.aspx?scid=kb;en-us;q294465 http://support.microsoft.com/default.aspx?scid=kb;en-us;182591 has the problem of CLKRUN. And I remember that this problem had happened on Thinkpad before. In the case, problem seems solved by similar workaround of sound/oss/cs46xx.c. This patch adds "disable_clkrun" option as workaround of problem to yenta_socket. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Dominik Brodowski authored
Reduce stack usage from 696 (0x2b8) to 24 (0x18) (on x86-32). Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
Dominik Brodowski <linux@broro.de> Signed-off-by:
-
Dominik Brodowski authored
This patch updates pcmcia wireless drivers so that their class devices are linked to the correct physical device. Based on an patch by Adam Belay, but adapted to a different pcmcia driver model implementation. Signed-off-by:
-
Dominik Brodowski authored
This patch updates pcmcia network drivers so that their class devices are linked to the correct physical device. Based on an patch by Adam Belay, but adapted to a different pcmcia driver model implementation. Signed-off-by:
-
Dominik Brodowski authored
Use driver_find() in ds.c instead of legacy implementation, and make use of its reference counting awareness. Signed-off-by:
-
Dominik Brodowski authored
Move the struct client_t inside struct pcmcia_device. This means it gets proper reference counting as well. The clients list inside struct pcmcia_socket can be removed now. Signed-off-by:
-
Dominik Brodowski authored
BUG if the socket's list of clients is not empty on shutdown and/or removal. Signed-off-by:
-
Dominik Brodowski authored
All in-kernel PCMCIA devices do unregister their client in their respective ->detach() function after a REMOVAL event. So, AFAICS, the dev_list iteration should always be false. Signed-off-by:
-
Dominik Brodowski authored
Restructure unbind_request(): Before, unbind_request was called by cardmgr on the following occasions: a) if the CS_EVENT_CARD_INSERTION event failed b) during do_remove(), which is called on 1) when cardmgr is informed of a CS_EVENT_CARD_REMOVAL event 2) when cardmgr is informed of a CS_EVENT_EJECTION_REQUEST event, if do_check() succeeds 3) cardmgr exit (SIGINT/SIGTERM), if do_check() succeeds We can ignore a), as the user is informed of the problem anyway, and can take appropriate action then (eject the card, update config, write new driver, insert card...). b1) can be done directly, even before the userspace cardmgr is informed. This speeds up the call to ->detach(). b2) All drivers I checked were based on the assumption that a CS_EVENT_CARD_REMOVAL event is received _first_, before a call to ->detach(). Most notably, some drivers issue first a call to their release() function [which else is called during EVENT_CARD_REMOVAL] during ->detach() if it hasn't been issued before. So, it doesn't hurt if unbind is only called during the EVENT_CARD_REMOVAL step, and not during EJECTION_REQUEST. The REMOVAL step is only called anyway if EJECTION_REQUEST succeeds, and the latter can only succeed if do_check() succeeds. b3) If cardmgr exits from daemon mode, ds_release() is called. I can't see a reason why this is good behaviour, especially as cards don't need cardmgr while running, only for setup. Consequences: - call unbind_request during CARD_REMOVAL handling, even before userspace is informed. - return "0" if UNBIND_REQUEST is called from userspace. - the driver's event handler is called with CARD_REMOVAL _always_ before ->detach() is called. Signed-off-by:
-
