- 31 1月, 2008 15 次提交
-
-
由 FUJITA Tomonori 提交于
This adds get_data_transfer_info helper function that get lha and sectors for READ_* and WRITE_* commands (and XDWRITEREAD_10 later). Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: NDouglas Gilbert <dougg@torque.net> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 James Bottomley 提交于
With the sg table code, every SCSI driver is now either chain capable or broken (or has sg_tablesize set so chaining is never activated), so there's no need to have a check in the host template. Also tidy up the code by moving the scatterlist size defines into the SCSI includes and permit the last entry of the scatterlist pools not to be a power of two. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Kiyoshi Ueda 提交于
Signed-off-by: NKiyoshi Ueda <k-ueda@ct.jp.nec.com> Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Boaz Harrosh 提交于
At the block level bidi request uses req->next_rq pointer for a second bidi_read request. At Scsi-midlayer a second scsi_data_buffer structure is used for the bidi_read part. This bidi scsi_data_buffer is put on request->next_rq->special. Struct scsi_cmnd is not changed. - Define scsi_bidi_cmnd() to return true if it is a bidi request and a second sgtable was allocated. - Define scsi_in()/scsi_out() to return the in or out scsi_data_buffer from this command This API is to isolate users from the mechanics of bidi. - Define scsi_end_bidi_request() to do what scsi_end_request() does but for a bidi request. This is necessary because bidi commands are a bit tricky here. (See comments in body) - scsi_release_buffers() will also release the bidi_read scsi_data_buffer - scsi_io_completion() on bidi commands will now call scsi_end_bidi_request() and return. - The previous work done in scsi_init_io() is now done in a new scsi_init_sgtable() (which is 99% identical to old scsi_init_io()) The new scsi_init_io() will call the above twice if needed also for the bidi_read command. Only at this point is a command bidi. - In scsi_error.c at scsi_eh_prep/restore_cmnd() make sure bidi-lld is not confused by a get-sense command that looks like bidi. This is done by puting NULL at request->next_rq, and restoring. [jejb: update to sg_table and resolve conflicts also update to blk-end-request and resolve conflicts] Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Boaz Harrosh 提交于
In preparation for bidi we abstract all IO members of scsi_cmnd, that will need to duplicate, into a substructure. - Group all IO members of scsi_cmnd into a scsi_data_buffer structure. - Adjust accessors to new members. - scsi_{alloc,free}_sgtable receive a scsi_data_buffer instead of scsi_cmnd. And work on it. - Adjust scsi_init_io() and scsi_release_buffers() for above change. - Fix other parts of scsi_lib/scsi.c to members migration. Use accessors where appropriate. - fix Documentation about scsi_cmnd in scsi_host.h - scsi_error.c * Changed needed members of struct scsi_eh_save. * Careful considerations in scsi_eh_prep/restore_cmnd. - sd.c and sr.c * sd and sr would adjust IO size to align on device's block size so code needs to change once we move to scsi_data_buff implementation. * Convert code to use scsi_for_each_sg * Use data accessors where appropriate. - tgt: convert libsrp to use scsi_data_buffer - isd200: This driver still bangs on scsi_cmnd IO members, so need changing [jejb: rebased on top of sg_table patches fixed up conflicts and used the synergy to eliminate use_sg and sg_count] Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com> Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Boaz Harrosh 提交于
If we export scsi_init_io()/scsi_release_buffers() instead of scsi_{alloc,free}_sgtable() from scsi_lib than tgt code is much more insulated from scsi_lib changes. As a bonus it will also gain bidi capability when it comes. [jejb: rebase on to sg_table and fix up rejections] Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com> Acked-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 FUJITA Tomonori 提交于
CC [M] drivers/scsi/aic7xxx/aic7xxx_osm_pci.o drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:148: warning: 'ahc_linux_pci_dev_suspend' defined but not used drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:166: warning: 'ahc_linux_pci_dev_resume' defined but not used This moves aic7xxx_pci_driver struct, removes some forward declarations, and adds some ifdef CONFIG_PM. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 FUJITA Tomonori 提交于
CC [M] drivers/scsi/aic7xxx/aic79xx_osm_pci.o drivers/scsi/aic7xxx/aic79xx_osm_pci.c:101: warning: 'ahd_linux_pci_dev_suspend' defined but not used drivers/scsi/aic7xxx/aic79xx_osm_pci.c:121: warning: 'ahd_linux_pci_dev_resume' defined but not used This moves aic79xx_pci_driver struct, removes some forward declarations, and adds some ifdef CONFIG_PM. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 David Milburn 提交于
The driver only needs to check the SCB_ACTIVE flag if the SCB is not in the untagged queue. If the driver is in error recovery, you may end panic'ing on a TUR that is in the untagged queue. Attempting to queue an ABORT message CDB: 0x0 0x0 0x0 0x0 0x0 0x0 SCB 3 done'd twice This patch is included in Adaptec's 6.3.11 driver on their website. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Thomas Bogendoerfer 提交于
SGI IP28 machines would need special treatment (enable adding addtional wait states) when accessing memory uncached. To avoid this pain I changed the driver to use only cached access to memory. Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 FUJITA Tomonori 提交于
The commit de25deb1 changed scsi_cmnd.sense_buffer from a static array to a dynamically allocated buffer. We can't access to sense_buffer in '&cmd->sense_buffer' way. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: NChristof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 FUJITA Tomonori 提交于
The commit de25deb1 changed scsi_cmnd.sense_buffer from a static array to a dynamically allocated buffer. We can't access to sense_buffer in '&cmd->sense_buffer' way. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 FUJITA Tomonori 提交于
The commit de25deb1 changed scsi_cmnd.sense_buffer from a static array to a dynamically allocated buffer. We can't access to sense_buffer in '&cmd->sense_buffer' way. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 FUJITA Tomonori 提交于
&cmnd->sense_buffer now zeroes the wrong thing. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Nathan Lynch 提交于
On a big powerpc box I got the following oops with 2.6.24-git2: sym0: <1010-66> rev 0x1 at pci 0000:d0:01.0 irq 215 sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) scsi 0:0:8:0: Direct-Access IBM ST318305LC C509 PQ: 0 ANSI: 3 target0:0:8: tagged command queuing enabled, command queue depth 16. target0:0:8: Beginning Domain Validation target0:0:8: asynchronous target0:0:8: wide asynchronous target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31) Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc000000000038460 cpu 0x25: Vector: 300 (Data Access) at [c00000000f567840] pc: c000000000038460: .memcpy+0x60/0x280 lr: d000000000050280: .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] sp: c00000000f567ac0 msr: 8000000000009032 dar: 0 dsisr: 42000000 current = 0xc000006d1e0af0a0 paca = 0xc0000000004afc00 pid = 0, comm = swapper enter ? for help [link register ] d000000000050280 .sym_set_cam_result_error+0xfc/0x1e0 [sym53c8xx] [c00000000f567ac0] c00000000f567b80 (unreliable) [c00000000f567b80] d0000000000552b8 .sym_complete_error+0x12c/0x1bc [sym53c8xx] [c00000000f567c20] d0000000000561a4 .sym_int_sir+0xaa4/0x1718 [sym53c8xx] [c00000000f567d00] d000000000057e8c .sym_interrupt+0x4e4/0x6ec [sym53c8xx] [c00000000f567dc0] d00000000004fdf4 .sym53c8xx_intr+0x6c/0xdc [sym53c8xx] [c00000000f567e50] c0000000000a83e0 .handle_IRQ_event+0x7c/0xec [c00000000f567ef0] c0000000000aa344 .handle_fasteoi_irq+0x130/0x1f0 [c00000000f567f90] c00000000002a538 .call_handle_irq+0x1c/0x2c [c000004d5e0b3a90] c00000000000c320 .do_IRQ+0x108/0x1d0 [c000004d5e0b3b20] c000000000004790 hardware_interrupt_entry+0x18/0x1c The memset() in sym_set_cam_result_error() would appear to be trashing the scsi_cmnd struct instead of clearing sense_buffer. Signed-off-by: NNathan Lynch <ntl@pobox.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 30 1月, 2008 24 次提交
-
-
由 Linus Torvalds 提交于
Both the old e1000 driver and the new e1000e driver can drive some PCI-Express e1000 cards, and we should avoid ambiguity about which driver will pick up the support for those cards when both drivers are enabled. This solves the problem by having the old driver support those cards if the new driver isn't configured, but otherwise ceding support for PCI Express versions of the e1000 chipset to the newer driver. Thus allowing both legacy configurations where only the old driver is active (and handles all chips it knows about) and the new configuration with the new driver handling the more modern PCIE variants. Acked-by: NJeff Garzik <jeff@garzik.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Bernhard Kaindl 提交于
This patch adds a new configuration option, which adds support for a new early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch() to decide wether OHCI-1394 FireWire controllers should be initialized and enabled for physical DMA access to allow remote debugging of early problems like issues ACPI or other subsystems which are executed very early. If the config option is not enabled, no code is changed, and if the boot paramenter is not given, no new code is executed, and independent of that, all new code is freed after boot, so the config option can be even enabled in standard, non-debug kernels. With specialized tools, it is then possible to get debugging information from machines which have no serial ports (notebooks) such as the printk buffer contents, or any data which can be referenced from global pointers, if it is stored below the 4GB limit and even memory dumps of of the physical RAM region below the 4GB limit can be taken without any cooperation from the CPU of the host, so the machine can be crashed early, it does not matter. In the extreme, even kernel debuggers can be accessed in this way. I wrote a small kgdb module and an accompanying gdb stub for FireWire which allows to gdb to talk to kgdb using remote remory reads and writes over FireWire. An version of the gdb stub fore FireWire is able to read all global data from a system which is running a a normal kernel without any kernel debugger, without any interruption or support of the system's CPU. That way, e.g. the task struct and so on can be read and even manipulated when the physical DMA access is granted. A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt and I've put a copy online at ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt It also has links to all the tools which are available to make use of it another copy of it is online at: ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diffSigned-Off-By: NBernhard Kaindl <bk@suse.de> Tested-By: NThomas Renninger <trenn@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Ingo Molnar 提交于
Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Thomas Gleixner 提交于
The set_memory_* and set_pages_* family of API's currently requires the callers to do a global tlb flush after the function call; forgetting this is a very nasty deathtrap. This patch moves the global tlb flush into each of the callers Signed-off-by: NArjan van de Ven <arjan@linux.intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Arjan van de Ven 提交于
This patch converts various users of change_page_attr() to the new, more intent driven set_page_*/set_memory_* API set. Signed-off-by: NArjan van de Ven <arjan@linux.intel.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Yi Yang 提交于
The function __cpufreq_set_policy in file drivers/cpufreq/cpufreq.c has a very obvious error: if (policy->min > data->min && policy->min > policy->max) { ret = -EINVAL; goto error_out; } This condtion statement is wrong because it returns -EINVAL only if policy->min is greater than policy->max (in this case, "policy->min > data->min" is true for ever.). In fact, it should return -EINVAL as well if policy->max is less than data->min. The correct condition should be: if (policy->min > data->max || policy->max < data->min) { The following test result testifies the above conclusion: Before applying this patch: [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 2394000 1596000 [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@yangyi-dev /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq -bash: echo: write error: Invalid argument [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@yangyi-dev /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# After applying this patch: [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 2394000 1596000 [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@localhost /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq -bash: echo: write error: Invalid argument [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@localhost /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq -bash: echo: write error: Invalid argument [root@localhost /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq -bash: echo: write error: Invalid argument [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@localhost /]# echo "1596000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@localhost /]# echo "2394000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 2394000 [root@localhost /] Signed-off-by: NYi Yang <yi.y.yang@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Yinghai Lu 提交于
Signed-off-by: NYinghai Lu <yinghai@sun.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Bernhard Walle 提交于
the previous patch in the old RTC driver. It also removes the direct rtc_interrupt() call from arch/x86/kernel/hpetc.c so that there's finally no (code) dependency to CONFIG_RTC in arch/x86/kernel/hpet.c. Because of this, it's possible to compile the drivers/char/rtc.ko driver as module and still use the HPET emulation functionality. This is also expressed in Kconfig. Signed-off-by: NBernhard Walle <bwalle@suse.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Cc: Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Robert Picco <Robert.Picco@hp.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Ingo Molnar 提交于
Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Andi Kleen 提交于
The ACPI code currently disables TSC use in any C2 and C3 states. But the AMD Fam10h BKDG documents that the TSC will never stop in any C states when the CONSTANT_TSC bit is set. Make this disabling conditional on CONSTANT_TSC not set on AMD. I actually think this is true on Intel too for C2 states on CPUs with p-state invariant TSC, but this needs further discussions with Len to really confirm :-) So far it is only enabled on AMD. Cc: lenb@kernel.org Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Andrew Morton 提交于
drivers/pnp/pnpbios/bioscalls.c:64: warning: (near initialization for 'bad_bios_desc.<anonymous>') Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Venki Pallipadi 提交于
Aviod TLB flush IPIs during C3 states by voluntary leave_mm() before entering C3. The performance impact of TLB flush on C3 should not be significant with respect to C3 wakeup latency. Also, CPUs tend to flush TLB in hardware while in C3 anyways. On a 8 logical CPU system, running make -j2, the number of tlbflush IPIs goes down from 40 per second to ~ 0. Total number of interrupts during the run of this workload was ~1200 per second, which makes it ~3% savings in wakeups. There was no measurable performance or power impact however. [ akpm@linux-foundation.org: symbol export fixes. ] Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Parag Warudkar 提交于
People with HP Desktops (including me) encounter couple of DMI errors during boot - dmi_save_oem_strings_devices: out of memory and dmi_string: out of memory. On some HP desktops the DMI data include OEM strings (type 11) out of which only few are meaningful and most other are empty. DMI code religiously creates copies of these 27 strings (65 bytes each in my case) and goes OOM in dmi_string(). If DMI_MAX_DATA is bumped up a little then it goes and fails in dmi_save_oem_strings while allocating dmi_devices of sizeof(struct dmi_device) corresponding to these strings. On x86_64 since we cannot use alloc_bootmem this early, the code uses a static array of 2048 bytes (DMI_MAX_DATA) for allocating the memory DMI needs. It does not survive the creation of empty strings and devices. Fix this by detecting and not newly allocating empty strings and instead using a one statically defined dmi_empty_string. Also do not create a new struct dmi_device for each empty string - use one statically define dmi_device with .name=dmi_empty_string and add that to the dmi_devices list. On x64 this should stop the OOM with same current size of DMI_MAX_DATA and on x86 this should save a good amount of (27*65 bytes + 27*sizeof(struct dmi_device) bootmem. Compile and boot tested on both 32-bit and 64-bit x86. Signed-off-by: NParag Warudkar <parag.warudkar@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
There's no need for the *_MASK flags (TF_MASK, IF_MASK, etc), found in processor.h (both _32 and _64). They have a one-to-one mapping with the EFLAGS value. This patch removes the definitions, and use the already existent X86_EFLAGS_ version when applicable. [ roland@redhat.com: KVM build fixes. ] Signed-off-by: NGlauber de Oliveira Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Ingo Molnar 提交于
replace outb_p() with udelay(2). This is a real ISA device so it likely needs this particular delay. Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
This patch unifies struct desc_ptr between i386 and x86_64. They can be expressed in the exact same way in C code, only having to change the name of one of them. As Xgt_desc_struct is ugly and big, this is the one that goes away. There's also a padding field in i386, but it is not really needed in the C structure definition. Signed-off-by: NGlauber de Oliveira Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Ingo Molnar 提交于
tons of style cleanup in drivers/char/rtc.c - no code changed: text data bss dec hex filename 6400 384 32 6816 1aa0 rtc.o.before 6400 384 32 6816 1aa0 rtc.o.after since we seem to have a number of open breakages in this code we might as well start with making the code more readable and maintainable. Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 H. Peter Anvin 提交于
This changes size-specific register names (eip/rip, esp/rsp, etc.) to generic names in the thread and tss structures. Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Thomas Gleixner 提交于
No users, just ballast Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Balaji Rao 提交于
Looks like IRQ 31 is assigned to timer 3, even without the patch! I wonder who wrote the number 31. But the manual says that it is zero by default. I think we should check whether the timer has been allocated an IRQ before proceeding to assign one to it. Here is a patch that does this. Signed-off-by: NBalaji Rao <balajirrao@gmail.com> Tested-by: NYinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Balaji Rao 提交于
The userspace API for the HPET (see Documentation/hpet.txt) did not work. The HPET_IE_ON ioctl was failing as there was no IRQ assigned to the timer device. This patch fixes it by allocating IRQs to timer blocks in the HPET. arch/x86/kernel/hpet.c | 13 +++++-------- drivers/char/hpet.c | 45 ++++++++++++++++++++++++++++++++++++++------- include/linux/hpet.h | 2 +- 3 files changed, 44 insertions(+), 16 deletions(-) Signed-off-by: NBalaji Rao <balajirrao@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Linus Torvalds 提交于
The new e1000e driver is apparently not yet suitable for general use, so mark it experimental, and re-instate all the PCI-Express device IDs in the old and stable e1000 driver so that people (namely me) can continue to use a driver that actually works. Auke & co have been appraised of the situation. Cc: Auke Kok <auke-jan.h.kok@intel.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: David Miller <davem@davemloft.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jens Axboe 提交于
For BLOCK_PC requests, we need that length for completing the request. Andrew Vasquez <andrew.vasquez@qlogic.com> reported the following oops Hitting a consistent BUG() with recent Linus' linux-2.6.git: [ 12.941428] ------------[ cut here ]------------ [ 12.944874] kernel BUG at drivers/block/cciss.c:1260! [ 12.944874] invalid opcode: 0000 [1] SMP [ 12.944874] CPU 0 [ 12.944874] Modules linked in: [ 12.944874] Pid: 0, comm: swapper Not tainted 2.6.24 #43 [ 12.944874] RIP: 0010:[<ffffffff8039e43d>] [<ffffffff8039e43d>] cciss_softirq_done+0xbc/0x1bf [ 12.944874] RSP: 0018:ffffffff8063aed0 EFLAGS: 00010202 [ 12.944874] RAX: 0000000000000001 RBX: ffff8100cf800010 RCX: ffff81042f1253b0 [ 12.944874] RDX: ffff81042de398f0 RSI: ffff81042de398f0 RDI: 0000000000000001 [ 12.944874] RBP: ffff81042daa0000 R08: ffff81042f1253b0 R09: 0000000000000001 [ 12.944874] R10: 00000000000000fe R11: 0000000000000000 R12: 0000000000000002 [ 12.944874] R13: 0000000000000001 R14: ffff8100cf800000 R15: ffff81042de398f0 [ 12.944874] FS: 0000000000000000(0000) GS:ffffffff805bb000(0000) knlGS:0000000000000000 [ 12.944874] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b [ 12.944874] CR2: 00002afed7eea340 CR3: 000000042dbba000 CR4: 00000000000006e0 [ 12.944874] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 12.944874] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 12.944874] Process swapper (pid: 0, threadinfo ffffffff805f4000, task ffffffff805624a0) [ 12.944874] Stack: 0000000000000000 ffffffff8063af10 0000000000000001 ffffffff80632d60 [ 12.944874] 0000000000000000 000000000000000a ffffffff805bb900 ffffffff8032038f [ 12.944874] ffffffff8063af10 ffffffff8063af10 ffffffff805bb940 ffffffff802346b4 [ 12.944874] Call Trace: [ 12.944874] <IRQ> [<ffffffff8032038f>] blk_done_softirq+0x69/0x78 [ 12.944874] [<ffffffff802346b4>] __do_softirq+0x6f/0xd8 [ 12.944874] [<ffffffff8020c45c>] call_softirq+0x1c/0x30 [ 12.944874] [<ffffffff8020e347>] do_softirq+0x30/0x80 [ 12.944874] [<ffffffff8020e409>] do_IRQ+0x72/0xd9 [ 12.944874] [<ffffffff8020a50a>] mwait_idle+0x0/0x46 [ 12.944874] [<ffffffff8020a3da>] default_idle+0x0/0x3d [ 12.944874] [<ffffffff8020b7e1>] ret_from_intr+0x0/0xa [ 12.944874] <EOI> [<ffffffff8020a54c>] mwait_idle+0x42/0x46 [ 12.944874] [<ffffffff8020a481>] cpu_idle+0x6a/0xae [ 12.944874] [ 12.944874] [ 12.944874] Code: 0f 0b eb fe 48 8d 85 d8 c0 00 00 48 89 04 24 48 89 c7 e8 e5 [ 12.944874] RIP [<ffffffff8039e43d>] cciss_softirq_done+0xbc/0x1bf [ 12.944874] RSP <ffffffff8063aed0> [ 12.944903] ---[ end trace e9c631603f90d22f ]--- which is caused by blk_end_request() returning 'not done' for a request, since it gets asked to complete zero bytes. Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
由 Jens Axboe 提交于
In ace_fsm_dostate(), the variable 'i' was used only for passing sector size of the request to end_that_request_first(). So I removed it and changed the code to pass the size in bytes directly to __blk_end_request() Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
- 29 1月, 2008 1 次提交
-
-
由 Stephen Hemminger 提交于
Fix a bunch of warnings in PPP and related drivers. Mostly because sparse doesn't like it when the the function is only marked private in the forward declaration. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-