- 26 Apr, 2010 5 commits
-
-
Oleg Nesterov authored
commit b95c35e7 upstream. proc_oom_score(task) has a reference to task_struct, but that is all. If this task was already released before we take tasklist_lock - we can't use task->group_leader, it points to nowhere - it is not safe to call badness() even if this task is ->group_leader, has_intersects_mems_allowed() assumes it is safe to iterate over ->thread_group list. - even worse, badness() can hit ->signal == NULL Add the pid_alive() check to ensure __unhash_process() was not called. Also, use "task" instead of task->group_leader. badness() should return the same result for any sub-thread. Currently this is not true, but this should be changed anyway. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Nikolaus Schulz authored
commit 30d1872d upstream. When using the string representation of a random counter as part of the base name, ensure that it is no longer than 4 bytes. Since we are repeatedly decrementing the counter in a loop until we have found a unique base name, the counter may wrap around zero; therefore, it is not enough to mask its higher bits before entering the loop, this must be done inside the loop. [hirofumi@mail.parknet.co.jp: use snprintf()] Signed-off-by:
Nikolaus Schulz <microschulz@web.de> Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Zhao Yakui authored
commit 72539832 upstream. Now the EDID property will be updated when the corresponding EDID can be obtained from the external display device. But after the external device is plugged-out, the EDID property is not updated. In such case we still get the corresponding EDID property although it is already detected as disconnected. https://bugs.freedesktop.org/show_bug.cgi?id=26743Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 338e2b1d upstream. This should go to 2.6.33 stable as well. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Ben Skeggs authored
commit 44fef224 upstream. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
- 01 Apr, 2010 35 commits
-
-
Greg Kroah-Hartman authored
-
Sachin Prabhu authored
commit 720e7749 upstream. gfs2_lock() will skip locks on file which have mode set to 02666. This is a problem in cases where the mode of the file is changed after a process has obtained a lock on the file. Such a lock will be skipped and will result in a BUG in locks_remove_flock(). gfs2_lock() should skip the check for mandatory locks when unlocking a file. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
Dimitri Sivanich authored
commit 14be1f74 upstream. On UV systems, the TSC is not synchronized across blades. The sched_clock_cpu() function is returning values that can go backwards (I've seen as much as 8 seconds) when switching between cpus. As each cpu comes up, early_init_intel() will currently set the sched_clock_stable flag true. When mark_tsc_unstable() runs, it clears the flag, but this only occurs once (the first time a cpu comes up whose TSC is not synchronized with cpu 0). After this, early_init_intel() will set the flag again as the next cpu comes up. Only set sched_clock_stable if tsc has not been marked unstable. Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Acked-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <20100301174815.GC8224@sgi.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Lars-Peter Clausen authored
commit c212808a upstream. If no platform_data was givin to the device it's going to use it's default platform data struct which has all fields initialized to zero. As a result the driver is going to try to request gpio0 both as write protect and card detect pin. Which of course will fail and makes the driver unusable Previously to the introduction of no_wprotect and no_detect the behavior was to assume that if no platform data was given there is no write protect or card detect pin. This patch restores that behavior. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: Ben Dooks <ben-linux@fluff.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Martin K. Petersen authored
block: Backport of various I/O topology fixes from 2.6.33 and 2.6.34 The stacking code incorrectly scaled up the data offset in some cases causing misaligned devices to report alignment. Rewrite the stacking algorithm to remedy this. (Upstream commit 9504e086) The top device misalignment flag would not be set if the added bottom device was already misaligned as opposed to causing a stacking failure. Also massage the reporting so that an error is only returned if adding the bottom device caused the misalignment. I.e. don't return an error if the top is already flagged as misaligned. (Upstream commit fe0b393f) lcm() was defined to take integer-sized arguments. The supplied arguments are multiplied, however, causing us to overflow given sufficiently large input. That in turn led to incorrect optimal I/O size reporting in some cases. Switch lcm() over to unsigned long similar to gcd() and move the function from blk-settings.c to lib. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Michael Buesch authored
commit 96869a39 upstream The TKIP key update callback is called from the RX path, where the driver mutex is already locked. This results in a circular locking bug. Avoid this by removing the lock. Johannes noted that there is a separate bug: The callback still breaks on SDIO hardware, because SDIO hardware access needs to sleep, but we are not allowed to sleep in the callback due to mac80211's RCU locking. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-by: kecsa@kutfo.hit.bme.hu Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
commit 319c2cc7 upstream. Signed-off-by:
Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com> Signed-off-by:
Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Andrei Emeltchenko authored
commit c2c77ec8 upstream. Added very simple check that req buffer has enough space to fit configuration parameters. Shall be enough to reject packets with configuration size more than req buffer. Crash trace below [ 6069.659393] Unable to handle kernel paging request at virtual address 02000205 [ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT ... [ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap] [ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap] ... [ 6070.030303] Backtrace: [ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from [<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap]) [ 6070.043823] r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200 [ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from [<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap]) [ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from [<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth]) [ 6070.072631] r6:dc647700 r5:00000001 r4:df2ab740 [ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from [<c006b9fc>] (tasklet_action+0x78/0xd8) [ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>] Signed-off-by:
Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Acked-by:
Gustavo F. Padovan <gustavo@padovan.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Marcel Holtmann authored
commit 101545f6 upstream. When creating a high number of Bluetooth sockets (L2CAP, SCO and RFCOMM) it is possible to scribble repeatedly on arbitrary pages of memory. Ensure that the content of these sysfs files is always less than one page. Even if this means truncating. The files in question are scheduled to be moved over to debugfs in the future anyway. Based on initial patches from Neil Brown and Linus Torvalds Reported-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Tejun Heo authored
commit 9deb3431 upstream. HP is recycling both DMI_PRODUCT_NAME and DMI_BIOS_VERSION making ahci_broken_suspend() trigger for later products which are not affected by the original problems. Match BIOS date instead of version and add references to bko's so that full information can be found easier later. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=15462Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by: tigerfishdaisy@gmail.com Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Jan Kara authored
commit 0a5a9c72 upstream. If a delayed-allocation write happens before quota is enabled, the kernel spits out a warning: WARNING: at fs/quota/dquot.c:988 dquot_claim_space+0x77/0x112() because the fact that user has some delayed allocation is not recorded in quota structure. Make dquot_initialize() update amount of reserved space for user if it sees inode has some space reserved. Also make sure that reserved quota space does not go negative and we warn about the filesystem bug just once. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Dmitry Monakhov authored
commit c469070a upstream. Since we implemented generic reserved space management interface, then it is possible to account reserved space even when quota is not active (similar to i_blocks/i_bytes). Without this patch following testcase result in massive comlain from WARN_ON in dquot_claim_space() TEST_CASE: mount /dev/sdb /mnt -oquota dd if=/dev/zero of=/mnt/test bs=1M count=1 quotaon /mnt # fs_reserved_spave == 1Mb # quota_reserved_space == 0, because quota was disabled dd if=/dev/zero of=/mnt/test seek=1 bs=1M count=1 # fs_reserved_spave == 2Mb # quota_reserved_space == 1Mb sync # ->dquot_claim_space() -> WARN_ON Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Anton Vorontsov authored
commit 0493a4ff upstream. The driver wrongly sets default state for LEDs that don't specify default-state property. Currently the driver handles default state this way: memset(&led, 0, sizeof(led)); for_each_child_of_node(np, child) { state = of_get_property(child, "default-state", NULL); if (state) { if (!strcmp(state, "keep")) led.default_state = LEDS_GPIO_DEFSTATE_KEEP; ... } ret = create_gpio_led(&led, ...); } Which means that all LEDs that do not specify default-state will inherit the last value of the default-state property, which is wrong. This patch fixes the issue by moving LED's template initialization into the loop body. Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
Richard Purdie <rpurdie@linux.intel.com> Signed-off-by:
-
Vivek Natarajan authored
commit e15276a4 upstream. The current mac80211 implementation enables power save if there is no Tx traffic for a specific timeout. Hence, PS is triggered even if there is a continuous Rx only traffic(like UDP) going on. This makes the drivers to wait on the tim bit in the next beacon to awake which leads to redundant sleep-wake cycles. Fix this by restarting the dynamic ps timer on receiving every data packet. Signed-off-by:
Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Vivek Natarajan authored
commit 05df4986 upstream. Signed-off-by:
-
Vivek Natarajan authored
commit 375177bf upstream. Even if the null data frame is not acked by the AP, mac80211 goes into power save. This might lead to loss of frames from the AP. Prevent this by restarting dynamic_ps_timer when ack is not received for null data frames. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Senthil Balasubramanian authored
commit 3f7c5c10 upstream. The TIM timer interrupt is enabled even before the ACK of nullqos is received which is unnecessary. Also clean up the CONF_PS part of config callback properly for better readability. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Daniel T Chen authored
commit 950200e2 upstream. BugLink: https://bugs.launchpad.net/bugs/418627 The original reporter states that this quirk is necessary to obtain reasonable gain for playback. Without it, sound is inaudible. Tested with playback (spkr and hp) and capture. Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Daniel T Chen authored
commit e1f7f02b upstream. BugLink: https://launchpad.net/bugs/303789 This model needs both 'Headphone Jack Sense' and 'Line Jack Sense' muted for audible audio, so just add its SSID to the blacklist and don't enumerate the controls. Signed-off-by:
-
Daniel Chen authored
commit 5cd165e7 upstream. BugLink: https://launchpad.net/bugs/481058 The OR has verified that both 'Headphone Jack Sense' and 'Line Jack Sense' need to be muted for sound to be audible, so just add the machine's SSID to the ac97 jack sense blacklist. Reported-by: Richard Gagne Tested-by: Richard Gagne Signed-off-by:
-
Daniel T Chen authored
commit 9ec8ddad upstream. BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575669 The OR states that position_fix=1 is necessary to work around glitching during volume adjustments using PulseAudio. Reported-by:
Carlos Laviola <claviola@debian.org> Tested-by:
-
Dean Nelson authored
commit 4d7a5644 upstream. Add missing newline to dev_warn() message string. This is more of an issue with older kernels that don't automatically add a newline if it was missing from the end of the previous line. Signed-off-by:
Dean Nelson <dnelson@redhat.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Andreas Herrmann authored
commit 035a02c1 upstream. Currently c1e_idle returns true for all CPUs greater than or equal to family 0xf model 0x40. This covers too many CPUs. Meanwhile a respective erratum for the underlying problem was filed (#400). This patch adds the logic to check whether erratum #400 applies to a given CPU. Especially for CPUs where SMI/HW triggered C1e is not supported, c1e_idle() doesn't need to be used. We can check this by looking at the respective OSVW bit for erratum #400. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20100319110922.GA19614@alberich.amd.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Jan Beulich authored
commit ff30a054 upstream. Ever for 32-bit with sufficiently high NR_CPUS, and starting with commit 789d03f5 also for 64-bit, the statically allocated early fixmap page tables were not covering FIX_OHCI1394_BASE, leading to a boot time crash when "ohci1394_dma=early" was used. Despite this entry not being a permanently used one, it needs to be moved into the permanent range since it has to be close to FIX_DBGP_BASE and FIX_EARLYCON_MEM_BASE. Reported-bisected-and-tested-by:
Justin P. Mattock <justinmattock@gmail.com> Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=14487Signed-off-by:
Jan Beulich <jbeulich@novell.com> LKML-Reference: <4B9E15D30200007800034D23@vpn.id2.novell.com> Signed-off-by:
-
Patrick McHardy authored
commit ef169150 upstream. Commit 8ccb92ad (netfilter: xt_recent: fix false match) fixed supposedly false matches in rules using a zero hit_count. As it turns out there is nothing false about these matches and people are actually using entries with a hit_count of zero to make rules dependant on addresses inserted manually through /proc. Since this slipped past the eyes of three reviewers, instead of reverting the commit in question, this patch explicitly checks for a hit_count of zero to make the intentions more clear. Reported-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Tested-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Chris Wilson authored
commit 1f2b1013 upstream. Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=15527 NULL pointer dereference in i915_gem_object_save_bit_17_swizzle BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f82b5d2b>] i915_gem_object_save_bit_17_swizzle+0x5b/0xc0 [i915] Call Trace: [<f82aea55>] ? i915_gem_object_put_pages+0x125/0x150 [i915] [<f82aeb71>] ? i915_gem_object_get_pages+0xf1/0x110 [i915] [<f82b0de8>] ? i915_gem_object_bind_to_gtt+0xb8/0x2a0 [i915] [<c02db74d>] ? drm_mm_get_block_generic+0x4d/0x180 [<f82b11cd>] ? i915_gem_mmap_gtt_ioctl+0x16d/0x240 [i915] [<f82ae786>] ? i915_gem_madvise_ioctl+0x86/0x120 [i915] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reported-by: maciej.rutecki@gmail.com Cc: stable@kernel.org Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Colin Ian King authored
commit 8c2eb480 upstream. Ensure additions on touch_ts do not overflow. This can occur when the top 32 bits of the TSC reach 0xffffffff causing additions to touch_ts to overflow and this in turn generates spurious softlockup warnings. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Eric Dumazet <eric.dumazet@gmail.com> LKML-Reference: <1268994482.1798.6.camel@lenovo> Signed-off-by:
-
Miao Xie authored
commit 5ab116c9 upstream. cpuset_mem_spread_node() returns an offline node, and causes an oops. This patch fixes it by initializing task->mems_allowed to node_states[N_HIGH_MEMORY], and updating task->mems_allowed when doing memory hotplug. Signed-off-by:
Miao Xie <miaox@cn.fujitsu.com> Acked-by:
David Rientjes <rientjes@google.com> Reported-by:
Nick Piggin <npiggin@suse.de> Tested-by:
-
Felix Fietkau authored
commit 4fdec031 upstream. When I initially stumbled upon sequence number problems with PAE frames in ath9k, I submitted a patch to remove all special cases for PAE frames and let them go through the normal transmit path. Out of concern about crypto incompatibility issues, this change was merged instead: commit 6c8afef5 Author: Sujith <Sujith.Manoharan@atheros.com> Date: Tue Feb 9 10:07:00 2010 +0530 ath9k: Fix sequence numbers for PAE frames After a lot of testing, I'm able to reliably trigger a driver crash on rekeying with current versions with this change in place. It seems that the driver does not support sending out regular MPDUs with the same TID while an A-MPDU session is active. This leads to duplicate entries in the TID Tx buffer, which hits the following BUG_ON in ath_tx_addto_baw(): index = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno); cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1); BUG_ON(tid->tx_buf[cindex] != NULL); I believe until we actually have a reproducible case of an incompatibility with another AP using no PAE special cases, we should simply get rid of this mess. This patch completely fixes my crash issues in STA mode and makes it stay connected without throughput drops or connectivity issues even when the AP is configured to a very short group rekey interval. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Ben Hutchings authored
John Halton wrote in <http://bugs.debian.org/575726>: > Whenever wpa_supplicant is deactivated (whether by killing the process or > during a normal shutdown) I am getting a kerneloops that prevents the > computer from completing shutdown. Here is the relevant syslog output: The backtrace points to an incorrect call from RTMPFreeTxRxRingMemory() into linux_pci_unmap_single(). This appears to have been fixed in Linux 2.6.33 by this change: commit ca97b838 Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Tue Sep 22 20:44:07 2009 +0200 Staging: rt28x0: updates from vendor's V2.1.0.0 drivers For stable-2.6.32, just fix this one function call. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Dean Nelson authored
commit 7c9e2b1c upstream. pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if successful, or an appropriate error value, if not. Distinguishing errors from correct values and understanding the meaning of an error can be somewhat confusing in that: correct values: 512, 1024, 2048, 4096 errors: -EINVAL -22 PCIBIOS_FUNC_NOT_SUPPORTED 0x81 PCIBIOS_BAD_VENDOR_ID 0x83 PCIBIOS_DEVICE_NOT_FOUND 0x86 PCIBIOS_BAD_REGISTER_NUMBER 0x87 PCIBIOS_SET_FAILED 0x88 PCIBIOS_BUFFER_TOO_SMALL 0x89 The PCIBIOS_ errors are returned from the PCI functions generated by the PCI_OP_READ() and PCI_OP_WRITE() macros. In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values returned from pci_read_config_[word|dword]() and pci_write_config_word(). Following pcix_get_max_mmrbc()'s example, the following patch simply returns -EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL or -EIO for those encountered by pcix_set_mmrbc(). This simplification was chosen in light of the fact that none of the current callers of these functions are interested in the specific type of error encountered. In the future, should this change, one could simply create a function that maps each PCIBIOS_ error to a corresponding unique errno value, which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and pcix_set_mmrbc(). Additionally, this patch eliminates some unnecessary variables. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Dean Nelson authored
commit bdc2bda7 upstream. An e1000 driver on a system with a PCI-X bus was always being returned a value of 135 from both pcix_get_mmrbc() and pcix_set_mmrbc(). This value reflects an error return of PCIBIOS_BAD_REGISTER_NUMBER from pci_bus_read_config_dword(,, cap + PCI_X_CMD,). This is because for a dword, the following portion of the PCI_OP_READ() macro: if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; expands to: if (pos & 3) return PCIBIOS_BAD_REGISTER_NUMBER; And is always true for 'cap + PCI_X_CMD', which is 0xe4 + 2 = 0xe6. ('cap' is the result of calling pci_find_capability(, PCI_CAP_ID_PCIX).) The same problem exists for pci_bus_write_config_dword(,, cap + PCI_X_CMD,). In both cases, instead of calling _dword(), _word() should be called. Signed-off-by:
-
Dean Nelson authored
commit 25daeb55 upstream. For the PCI_X_STATUS register, pcix_get_max_mmrbc() is returning an incorrect value, which is based on: (stat & PCI_X_STATUS_MAX_READ) >> 12 Valid return values are 512, 1024, 2048, 4096, which correspond to a 'stat' (masked and right shifted by 21) of 0, 1, 2, 3, respectively. A right shift by 11 would generate the correct return value when 'stat' (masked and right shifted by 21) has a value of 1 or 2. But for a value of 0 or 3 it's not possible to generate the correct return value by only right shifting. Fix is based on pcix_get_mmrbc()'s similar dealings with the PCI_X_CMD register. Signed-off-by:
-
OGAWA Hirofumi authored
commit 8e0cc811 upstream. Smaller size than a minimum blocksize can't be used, after all it's handled like 0 size. For extended partition itself, this makes sure to use bigger size than one logical sector size at least. Signed-off-by:
-
Daniel Taylor authored
commit 3fbf586c upstream. In order to use disks larger than 2TiB on Windows XP, it is necessary to use 4096-byte logical sectors in an MBR. Although the kernel storage and functions called from msdos.c used "sector_t" internally, msdos.c still used u32 variables, which results in the ability to handle XP-compatible large disks. This patch changes the internal variables to "sector_t". Daniel said: "In the near future, WD will be releasing products that need this patch". [hirofumi@mail.parknet.co.jp: tweaks and fix] Signed-off-by:
Daniel Taylor <daniel.taylor@wdc.com> Signed-off-by:
-
