Re: [PATCH] fully support linker generated .eh_frame_hdr section
>>> Jan Engelhardt <[EMAIL PROTECTED]> 05.12.06 20:52 >>> > Now that binutils' ld is able to properly populate .eh_frame_hdr in the Linux kernel case, here's a patch to add some functionality to the Dwarf2 unwinder to actually be able to make use of this (applies on firstfloor tree with the previously sent patch to add debug output, but not on plain 2.6.19). >>> >>>Requires what version of binutils / ld? >> >>mainline - the second of the required patches went in just yesterday. > >Which means people using distros will have it in some 6 months, unless >vendors give an earlier update. That's not the point here - the point is that the kernel should be ready to take advantage of this whenever somebody tries to build with newer binutils. Also, the patch adds a previously missing check that would result in not creating a runtime allocated table (assuming the linker created one is usable), but failing to read from that table during later lookups (resulting in the originally observed long boot time due to lockdep making heavy use of this code). Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] Update Documentation/pci.txt
On Thu, Nov 23, 2006 at 10:12:17PM -0700, Grant Grundler wrote:
> On Fri, Nov 24, 2006 at 09:38:00AM +0900, Hidetoshi Seto wrote:
> > Grant Grundler wrote:
> > >Hidetoshi,
> > >I have a nearly finished rewrite of Documentation/pci.txt.
> > >Can you drop this patch for now on my promise to integrate
> > >your proposed text?
> >
> > No problem at all.
>
> Thanks - I've posted pci.txt-05 on:
> http://www.parisc-linux.org/~grundler/pci.txt-05
>
> and appended it below.
>
> pci.txt-03 is the last version I posted.
> pci.txt-04 contains all feedback from Andi Kleen and Randi Dunlap
>(plus a few other minor changes)
> pci.txt-05 reverts pci_enable_device/pci_request_resource ordering to
> reflect current reality. But I've added a comment to remind us
> about the issue. Also added Section 10/11 from Hidetoshi-san.
> A few minor other changes as well.
>
> If this looks good, I'll post a diff for gregkh.
This looks very good, thanks for doing this work. I do have a few minor
comments:
> 1. pci_register_driver() call
> ~
> PCI device drivers call pci_register_driver() during their
> initialization with a pointer to a structure describing the driver
> (struct pci_driver):
>
> field name Description
> -- --
> id_tablePointer to table of device ID's the driver is
> interested in. Most drivers should export this
> table using MODULE_DEVICE_TABLE(pci,...).
>
> probe This probing function gets called (during execution
> of pci_register_driver() for already existing
> devices or later if a new device gets inserted) for
> all PCI devices which match the ID table and are not
> "owned" by the other drivers yet. This function gets
> passed a "struct pci_dev *" for each device whose
> entry in the ID table matches the device. The probe
> function returns zero when the driver chooses to
> take "ownership" of the device or an error code
> (negative number) otherwise.
> The probe function always gets called from process
> context, so it can sleep.
>
> remove The remove() function gets called whenever a device
> being handled by this driver is removed (either during
> deregistration of the driver or when it's manually
> pulled out of a hot-pluggable slot).
> The remove function always gets called from process
> context, so it can sleep.
>
> save_state Save a device's state before it is suspended.
There is no such callback. We have "suspend", "suspend_late",
"resume_early", and "resume". You might want to update this.
>
> suspend Put device into low power state.
>
> resume Wake device from low power state.
>
> enable_wake Enable device to generate wake events from a low power
> state.
>
> (Please see Documentation/power/pci.txt for descriptions
> of PCI Power Management and the related functions.)
>
>
> The ID table is an array of struct pci_device_id entries ending with an
> all-zero entry. Each entry consists of:
>
> vendor,device Vendor and device ID to match (or PCI_ANY_ID)
>
> subvendor, Subsystem vendor and device ID to match (or PCI_ANY_ID)
> subdevice,
>
> class Device class, subclass, and "interface" to match.
> See Appendix D of the PCI Local Bus Spec or
> include/linux/pci_ids.h for a full list of classes.
> Most drivers do not need to specify class/class_mask
> as vendor/device is normally sufficient.
>
> class_mask limit which sub-fields of the class field are compared.
> See drivers/scsi/sym53c8xx_2/ for example of usage.
>
> driver_data Data private to the driver.
> Most drivers don't need to use driver_data field.
> Best practice is to use driver_data as an index
> into a static list of equivalent device types,
> instead of using it as a pointer.
Perhaps mention the PCI_DEVICE() and PCI_DEVICE_CLASS() macros to set
these fields properly?
> Have a table entry {PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID}
PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID) is a bit smaller :)
> to have probe() called for every PCI device known to the system.
>
> New PCI IDs may be added to a device driver pci_ids table at runtime
> as shown below:
>
> echo "vendor
Re: [PATCH] mm: D-cache aliasing issue in cow_user_page
On 12/5/06, David Miller <[EMAIL PROTECTED]> wrote: From: "Matt Reimer" <[EMAIL PROTECTED]> Date: Tue, 5 Dec 2006 16:57:12 -0800 > Right, but isn't he declaring that each architecture needs to take > care of this? So, say, on ARM we'd need to make kunmap() not a NOP and > call flush_dcache_page() ? No. He is only solving a problem that occurs on HIGHMEM configurations on systems which can have D-cache aliasing issues. Ok. Thanks for the clarification. Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Change x86 prefix order
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and LOCKREP_PREFIX isn't fixed. Currently, gas generates LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX I will check in a patch: http://sourceware.org/ml/binutils/2006-12/msg00054.html tomorrow and change gas to generate SEG_PREFIX ADDR_PREFIX DATA_PREFIX LOCKREP_PREFIX H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + cpei-gets-warning-at-kernel-irq-migrationc27-move_masked_irq.patch added to -mm tree
On Tue, 2006-12-05 at 22:44 -0800, [EMAIL PROTECTED] wrote: > It works, the warning disappeared and irqbalance still runs well. > > Signed-off-by: Hidetoshi Seto <[EMAIL PROTECTED]> > Cc: Arjan van de Ven <[EMAIL PROTECTED]> > Cc: Ingo Molnar <[EMAIL PROTECTED]> > Cc: Thomas Gleixner <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Good catch. Acked-by: Thomas Gleixner <[EMAIL PROTECTED]> > > kernel/irq/proc.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff -puN > kernel/irq/proc.c~cpei-gets-warning-at-kernel-irq-migrationc27-move_masked_irq > kernel/irq/proc.c > --- > a/kernel/irq/proc.c~cpei-gets-warning-at-kernel-irq-migrationc27-move_masked_irq > +++ a/kernel/irq/proc.c > @@ -54,7 +54,8 @@ static int irq_affinity_write_proc(struc > unsigned int irq = (int)(long)data, full_count = count, err; > cpumask_t new_value, tmp; > > - if (!irq_desc[irq].chip->set_affinity || no_irq_affinity) > + if (!irq_desc[irq].chip->set_affinity || no_irq_affinity || > + CHECK_IRQ_PER_CPU(irq_desc[irq].status)) > return -EIO; > > err = cpumask_parse_user(buffer, count, new_value); > _ > > Patches currently in -mm which might be from [EMAIL PROTECTED] are > > cpei-gets-warning-at-kernel-irq-migrationc27-move_masked_irq.patch > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ownership/permissions of cpio initrd
Jeffrey Hundstad <[EMAIL PROTECTED]> writes on Tue, 05 Dec 20 06 14:17:22 CST > You can also use fakeroot(1). > > Start fakeroot. > Change all of your permissions as you see fit. > make your cpio > exit fakeroot. > > > ThanksI got it running on fedora4 pretty easily... Looks like its what I want/need -- marty - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + ocfs2-relative-atime-support-tweaks.patch added to -mm tree
On Tue, Dec 05, 2006 at 10:43:11PM -0800, Andrew Morton wrote: > The logic I have there is the same (I hope)... > > + if (timespec_compare(>i_mtime, > + >i_atime) < 0 && > + timespec_compare(>i_ctime, > + >i_atime) < 0) > + return; Oh ok, yeah I didn't notice that the arguments to timespec_compare() had been changed! --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6.19 and RealTek RTL8139 interrupt
On Tue, 05 Dec 2006 21:36:37 +0300 Oleg Mikheev <[EMAIL PROTECTED]> wrote: > Hi guys, > > I'm using FC5 with vanilla kernels. > Everything worked great until 2.6.19 was released. > Not each time I'm trying to up my eth0 kernel produces this: > > > eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 > irq 18: nobody cared (try booting with the "irqpoll" option) > [] __report_bad_irq+0x36/0x7d > [] note_interrupt+0x188/0x1c3 > [] handle_IRQ_event+0x1a/0x3f > [] handle_fasteoi_irq+0x61/0x73 > [] do_IRQ+0x6b/0x83 > [] sys_rt_sigprocmask+0x80/0x93 > [] common_interrupt+0x1a/0x20 > === > handlers: > [] (rtl8139_interrupt+0x0/0x3aa) > Disabling IRQ #18 > > > I'm posting it here b/c I don't think it's a normal behavior. > Here is the diff of dmesg output between 2.6.18.3 and 2.6.19: > > > 140,142c141,143 > < 8139too Fast Ethernet driver 0.9.27 > < ACPI: PCI Interrupt :01:06.0[A] -> GSI 20 (level, low) -> IRQ 20 > < eth0: RealTek RTL8139 at 0xf8806c00, 00:40:45:28:2c:ae, IRQ 20 > --- > > 8139too Fast Ethernet driver 0.9.28 > > ACPI: PCI Interrupt :01:06.0[A] -> GSI 20 (level, low) -> IRQ 18 > > eth0: RealTek RTL8139 at 0xf8806c00, 00:40:45:28:2c:ae, IRQ 18 > 147c148 > < ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 > --- > > ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 19 This looks like http://bugzilla.kernel.org/show_bug.cgi?id=7601 Please see http://bugzilla.kernel.org/show_bug.cgi?id=7601#c10 for a possible fix. That fix is in mainline now, so testing Linus's current tree would suit too, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + ocfs2-relative-atime-support-tweaks.patch added to -mm tree
On Tue, 5 Dec 2006 22:28:09 -0800
Mark Fasheh <[EMAIL PROTECTED]> wrote:
> > if (vfsmnt->mnt_flags & MNT_RELATIME) {
> > - if ((timespec_compare(>i_atime, >i_mtime) < 0) ||
> > - (timespec_compare(>i_atime, >i_ctime) < 0))
> > + if ((timespec_compare(>i_atime, >i_mtime) <= 0) ||
> > + (timespec_compare(>i_atime, >i_ctime) <= 0))
> > return 1;
> Hmm, should we fix up touch_atime() to use "<=" as well? Maybe I didn't read
> it correctly...
The logic I have there is the same (I hope)...
+ if (timespec_compare(>i_mtime,
+ >i_atime) < 0 &&
+ timespec_compare(>i_ctime,
+ >i_atime) < 0)
+ return;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re[2]: More ARM binutils fuckage
Hello Lennert, Wednesday, December 6, 2006, 3:08:13 AM, you wrote: [] > (These > days I build all kernels in EABI mode with old-ABI compat.) I have > not run into any code generation issues with this compiler yet. I wonder, if OABI-compat is known to actually work on OABI userspace, I mean, on something real, like xserver-kdrive ;-). Because I'd really like to build single kernel for both old and new userspace too, but afraid to try that, fearing to be put down by another broken feature ;-). -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.19 + highmem = BUG at do_wp_page
On Tue, 5 Dec 2006 19:25:13 +0200 Sami Farin <[EMAIL PROTECTED]> wrote: > [1.] PROBLEM: 2.6.19 + highmem = BUG at do_wp_page Can you send the .config please? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CPEI gets warning at kernel/irq/migration.c:27/move_masked_irq()
> It'd be nice if we could just teach the userspace balancer to not try to > move perpcu IRQs? > > otoh, the patch is super-cheap. Arjan? I can fix irqbalance no problem, however I like the kernel approach as well, since it's not just irqbalance that moves irqs, sysadmins tend to do it as well so how about both? One thing we probably should do, and that would help irqbalance immensely, is to export a bitmask for which cpus an interrupt CAN go to, next to where the current binding interface is. I'll check into that Hidetoshi: would it be possible to send me a /proc/interrupts file of that machine? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + ocfs2-relative-atime-support-tweaks.patch added to -mm tree
On Tue, Dec 05, 2006 at 10:12:45PM -0800, [EMAIL PROTECTED] wrote:
> --
> Subject: ocfs2-relative-atime-support-tweaks
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> methinks...
Yeah, all good tweaks - thanks for catching those. And thanks for carrying
the ocfs2 patch in -mm.
Acked-by: Mark Fasheh <[EMAIL PROTECTED]>
> diff -puN fs/ocfs2/file.c~ocfs2-relative-atime-support-tweaks fs/ocfs2/file.c
> --- a/fs/ocfs2/file.c~ocfs2-relative-atime-support-tweaks
> +++ a/fs/ocfs2/file.c
> @@ -153,16 +153,15 @@ int ocfs2_should_update_atime(struct ino
> ((vfsmnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)))
> return 0;
>
> - now = CURRENT_TIME;
> -
> if (vfsmnt->mnt_flags & MNT_RELATIME) {
> - if ((timespec_compare(>i_atime, >i_mtime) < 0) ||
> - (timespec_compare(>i_atime, >i_ctime) < 0))
> + if ((timespec_compare(>i_atime, >i_mtime) <= 0) ||
> + (timespec_compare(>i_atime, >i_ctime) <= 0))
> return 1;
Hmm, should we fix up touch_atime() to use "<=" as well? Maybe I didn't read
it correctly...
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in pata_pdc2027x
On Wed, 06 Dec 2006 14:10:15 +0800 Albert Lee <[EMAIL PROTECTED]> wrote: > > Where could I download the patched kernel source? There are two > POWER5 9110-51A boxes here. Maybe I could try to reproduce the problem > on these boxes. You can just use Linus' current tree - it exhibits the same problem (and the powerpc tree has been merged into it). -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpDAy1nVgwn5.pgp Description: PGP signature
Re: [PATCH] CPEI gets warning at kernel/irq/migration.c:27/move_masked_irq()
On Tue, 05 Dec 2006 16:35:06 +0900
Hidetoshi Seto <[EMAIL PROTECTED]> wrote:
> Hi,
>
> While running my MCA test (hardware error injection) on 2.6.19,
> I got some warning like following:
>
> > BUG: warning at kernel/irq/migration.c:27/move_masked_irq()
> >
> > Call Trace:
> > [] show_stack+0x40/0xa0
> > sp=e0006b2578d0 bsp=e0006b2510b0
> > [] dump_stack+0x30/0x60
> > sp=e0006b257aa0 bsp=e0006b251098
> > [] move_masked_irq+0xb0/0x240
> > sp=e0006b257aa0 bsp=e0006b251070
> > [] move_native_irq+0xe0/0x180
> > sp=e0006b257aa0 bsp=e0006b251040
> > [] iosapic_end_level_irq+0x30/0xe0
> > sp=e0006b257aa0 bsp=e0006b251020
> > [] __do_IRQ+0x170/0x400
> > sp=e0006b257aa0 bsp=e0006b250fd8
> > [] ia64_handle_irq+0x1b0/0x260
> > sp=e0006b257aa0 bsp=e0006b250fa8
> > [] ia64_leave_kernel+0x0/0x280
> > sp=e0006b257aa0 bsp=e0006b250fa8
> > [] _spin_unlock_irqrestore+0x30/0x60
> > sp=e0006b257c70 bsp=e0006b250f90
>
> It comes from:
>
> [kernel/irq/migration.c]
> 26 if (CHECK_IRQ_PER_CPU(desc->status)) {
> 27 WARN_ON(1);
> 28 return;
> 29 }
>
> By putting some printk in kernel, I found that irqbalance is trying to
> move CPEI which is handled as PER_CPU irq. That's why.
>
> CPEI(Corrected Platform Error Interrupt) is ia64 specific irq, is
> allowed to pin to particular processor which selected by the platform, and
> even it is PER_CPU but it has set_affinity handler (=iosapic_set_affinity)
> as same as other IO-SAPIC-level interrupts. (I don't know why, but
> I guess that there would be typical situation where the handler for
> migration is needed, such as hotplug - the processor going to be
> offline/hot-removed.)
>
> To shut up this warning, there are 2 way at least:
> a) fix CPEI stuff
> b) prohibit setting affinity to PER_CPU irq
>
> I'm not sure what stuff of CPEI need to be fixed, but I think that
> returning error to attempting move PER_CPU irq is useful for all
> applications since it will never work.
>
> Following small patch takes b) style.
> It works, the warning disappeared and irqbalance still runs well.
>
> Thanks,
> H.Seto
>
> Signed-off-by: Hidetoshi Seto <[EMAIL PROTECTED]>
>
> ---
> kernel/irq/proc.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.19/kernel/irq/proc.c
> ===
> --- linux-2.6.19.orig/kernel/irq/proc.c
> +++ linux-2.6.19/kernel/irq/proc.c
> @@ -54,7 +54,8 @@ static int irq_affinity_write_proc(struc
> unsigned int irq = (int)(long)data, full_count = count, err;
> cpumask_t new_value, tmp;
>
> - if (!irq_desc[irq].chip->set_affinity || no_irq_affinity)
> + if (!irq_desc[irq].chip->set_affinity || no_irq_affinity ||
> + CHECK_IRQ_PER_CPU(irq_desc[irq].status))
> return -EIO;
It'd be nice if we could just teach the userspace balancer to not try to
move perpcu IRQs?
otoh, the patch is super-cheap. Arjan?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Relative atime (was Re: What's in ocfs2.git)
On Tue, 5 Dec 2006 14:20:27 -0800
Mark Fasheh <[EMAIL PROTECTED]> wrote:
> Update ocfs2_should_update_atime() to understand the MNT_RELATIME flag and
> to test against mtime / ctime accordingly.
>
> ...
>
> --- a/fs/ocfs2/file.c
> +++ b/fs/ocfs2/file.c
> @@ -154,6 +154,15 @@ int ocfs2_should_update_atime(struct ino
> return 0;
>
> now = CURRENT_TIME;
> +
> + if (vfsmnt->mnt_flags & MNT_RELATIME) {
> + if ((timespec_compare(>i_atime, >i_mtime) < 0) ||
> + (timespec_compare(>i_atime, >i_ctime) < 0))
> + return 1;
> +
> + return 0;
So if atime == mtime == ctime, we don't update the atime.
I think we should. It seems risky to leave them all equal.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 5 Dec 2006 21:00:20 -0800 (PST) Luben Tuikov <[EMAIL PROTECTED]>
> > wrote:
> > --- Michael Reed <[EMAIL PROTECTED]> wrote:
> > > Luben Tuikov wrote:
> > > ...snip...
> > > > This statement in scsi_io_completion() causes the infinite retry loop:
> > > >if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> > > > return;
> > >
> > > The code in 2.6.19 is "result==0", not "!!result", which is logically
> > > the same as "result!=0". Did you mean to change the logic here?
> > > Am I missing something?
> >
> > Hmm, I think my trees have !!result from an earlier patch I posted.
> >
> > In this case it would appear that the second chunk of the patch
> > wouldn't be necessary, since result==0 would be false, and it
> > wouldn't retry.
> >
>
> I fixed things up. The below is as-intended, yes?
Yes, thanks!
Luben
>
>
> diff -puN
> drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
> drivers/scsi/scsi_error.c
> ---
> a/drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
> +++ a/drivers/scsi/scsi_error.c
> @@ -359,6 +359,11 @@ static int scsi_check_sense(struct scsi_
> return SUCCESS;
>
> case MEDIUM_ERROR:
> + if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> + sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> + sshdr.asc == 0x14) { /* RECORD NOT FOUND */
> + return SUCCESS;
> + }
> return NEEDS_RETRY;
>
> case HARDWARE_ERROR:
> diff -puN
> drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
> drivers/scsi/scsi_lib.c
> --- a/drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
> +++ a/drivers/scsi/scsi_lib.c
> @@ -871,7 +871,8 @@ void scsi_io_completion(struct scsi_cmnd
>* are leftovers and there is some kind of error
>* (result != 0), retry the rest.
>*/
> - if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> + if (good_bytes &&
> + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> return;
>
> /* good_bytes = 0, or (inclusive) there were leftovers and
> _
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in pata_pdc2027x
Stephen Rothwell wrote: > Hi all, > > I get an oops during initialisation of the pata_pdc2027x module on a > POWER 285 machine. This is on a very recent Linus kernel tree > (ff51a98799931256b555446b2f5675db08de6229) with Paulus' powerpc tree > (that has now been merged). The oops looks like this: > Hi Stephen, Where could I download the patched kernel source? There are two POWER5 9110-51A boxes here. Maybe I could try to reproduce the problem on these boxes. -- albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device naming randomness (udev?)
Greg KH wrote: On Mon, Dec 04, 2006 at 12:12:06AM +0100, Bj?rn Steinbrink wrote: On 2006.12.03 14:39:44 -0800, Martin J. Bligh wrote: This PC has 1 ethernet interface, an e1000. Ubuntu Dapper. On 2.6.14, my e1000 interface appears as eth0. On 2.6.15 to 2.6.18, my e1000 interface appears as eth1. In both cases, there are no other ethX interfaces listed in "ifconfig -a". There are no modules involved, just a static kernel build. Is this a bug in udev, or the kernel? I'm presuming udev, but seems odd it changes over a kernel release boundary. Any ideas on how I get rid of it? Makes automatic switching between kernel versions a royal pain in the ass. Just a wild guess here... Debian's (and I guess Ubuntu's) udev rules contain a generator for persistent interface name rules. Maybe these start working with 2.6.15 and thus the switch (ie. the kernel would call it eth0, but udev renames it to eth1). The generated rules are written to /etc/udev/rules.d/z25_persistent-net.rules on Debian, not sure if its the same for Ubuntu. Editing/removing the rules should fix your problem. Yes, I'd place odds on this one. Huh. Somehow there was this entry in /etc/iftab: eth0 mac 00:0d:61:44:90:12 arp 1 But that's not my mac address. Damned if I know how that got there, but if the persistent rules only work on later kernels, that'd explain it. And indeed ... removing that entry makes it work more normally. Thanks for the pointers - most helpful. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
On Tue, Dec 05, 2006 at 04:03:08PM -0800, David Brownell wrote: > On Tuesday 05 December 2006 2:01 am, Marco d'Itri wrote: > > On Dec 05, David Brownell <[EMAIL PROTECTED]> wrote: > > > > > The pushback on $SUBJECT patch. Which amounts to wanting to break hotplug > > > for several busses, unless someone (NOT the folk promoting the breakage!) > > > > Please explain in more details how hotplugging would be broken, possibly > > with examples. > > First, for reference, I refer to hotplugging using the trivial ASH scripts > from [1], updated by removing no-longer-needed special cases for platform_bus > (that original logic didn't work sometimes) and pcmcia. See the (short) > contemporary thread [2] discussing platform_bus support, and some of issues > related to why its hotplug support works the way it does now. (Looks like > some messages are not archived, but the key points are there.) > > Those scripts have supported hotplug and coldplug on several embedded boards > for some time now. The ancient "runs on 2.4" scripts would have been way > too slow to justify using hotplug and udev to replace devfs, and also needed > all sorts of extra crap that's regularly not found with embedded Linuxes. > Plus of course they never understood platform_bus, which is the main way > those PCI-less systems are hooked together. Ah, so for the platform devices, doing a modprobe /sys/devices/platform/* would load all of the proper modules for the specific platform devices that are already present due to the MODULE_ALIAS() stuff? Interesting, I didn't know that. > Second, note that you're asking me to construct a straw man for you and > then break it down, since nobody arguing with the $SUBJECT patch has ever > provided a complete counter-proposal (much less respond to the points > I've made about legacy driver bugginess -- which is suggestive). Well, no, I just thought the patch in $SUBJECT was very ugly, and hence, didn't like it :) > That said, the common thread in that pushback is that $MODALIAS (and also > modalias files) "should" have some value other than platform_device.name ... > which name is conventionaly also the name of the driver's module. That goes > along with a (weak) rationale that requires spi_bus and KMOD to change, plus > (presumably, pending a code audit) other kernel subsystems. > > > That should make it clear how accepting that pushback would break hotplug: > "modprobe $MODALIAS" would no longer load the right module. Likewise > the more significant case of coldplug; "modprobe $(cat modalias)" would > likewise no longer work. But, I don't understand why a module would have an alias with the same name as itself? What is that achieving here? Shouldn't redundancy like that be eliminated? > The $SUBJECT patch makes those legacy drivers NOT use the $MODALIAS > mechanism ... you seem to be overlooking that. No, I'm not overlooking that, I think it's a good thing. I'm just wondering if it could be done a different way. Perhaps in the platform device itself instead of the driver core code? > And "udev" was from day one supposed to solve a different problem > than "loading modules". There was to be a clear and strong separation > of roles between hotplug (load modules, don't rely on sysfs, use other > components for the rest of device setup) and udev (make /dev nodes, > ok to rely on sysfs). That is, "udev" wouldn't do any loading. Well, things evolve and change over time. In the beginning, Linux was only supposed to run on one CPU type and merely display ABABABAB on a console properly :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 32/36] driver core: Introduce device_move(): move a device to a new parent.
On Tue, Dec 05, 2006 at 04:26:11PM +0100, Marcel Holtmann wrote:
> Hi Greg,
>
> > > > > > Provide a function device_move() to move a device to a new parent
> > > > > > device. Add
> > > > > > auxilliary functions kobject_move() and sysfs_move_dir().
> > > > > > kobject_move() generates a new uevent of type KOBJ_MOVE, containing
> > > > > > the
> > > > > > previous path (DEVPATH_OLD) in addition to the usual values. For
> > > > > > this, a new
> > > > > > interface kobject_uevent_env() is created that allows to add further
> > > > > > environmental data to the uevent at the kobject layer.
> > > > >
> > > > > has this one been tested? I don't get it working. I always get an
> > > > > EINVAL
> > > > > when trying to move the TTY device of a Bluetooth RFCOMM link around.
> > > >
> > > > I relied on Cornelia to test this. I think some s390 patches depend on
> > > > this change, right?
> > >
> > > my pre-condition is that the TTY device has no parent and then we move
> > > it to a Bluetooth ACL link as child. This however is not working or the
> > > TTY change to use device instead of class_device has broken something.
> >
> > Hm, I don't think the class_device stuff has broken anything, but if you
> > think so, please let me know.
>
> I was checking why device_move() fails and it seems that the check for
> is_registered is the problem here.
>
> if (!device_is_registered(dev)) {
> error = -EINVAL;
> goto out;
> }
>
> The ACL link has been attached to the Bluetooth bus, but for some reason
> it still thinks that it is unregistered. Is this check really needed. I
> think it should be possible to also move devices that are not part of a
> bus, yet. And removing that check makes it work for me.
>
> And btw. I can't see any s390 patches that are using device_move() at
> the moment.
>
> > > > > And shouldn't device_move(dev, NULL) re-attach it to the virtual
> > > > > device
> > > > > tree instead of failing?
> > > >
> > > > Yes, that would be good to have.
> > >
> > > Cornelia, please fix this, because otherwise we can't detach a device
> > > from its parent. Storing the current virtual parent looks racy to me.
> >
> > You can always restore the previous "virtual" parent from the
> > information given to you in the device itself. That is what the code
> > does when it first registers the device.
> >
> > And yes, I too think it should be fixed.
>
> My knowledge of the driver model is still limited. Can you fix that
> quickly. This is really needed.
As Cornelia wrote this portion of code, I will wait a bit to recieve a
patch...
Cornelia?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.19: OOPS upon boot (not always)
> On Mon, 4 Dec 2006 23:14:13 +0100 Philippe Gramoullé <[EMAIL PROTECTED]> > wrote: > Kernel oops upon boot, but not always. When it boots ok, then PC's working > fine. > > [2.] Full description of the problem/report: > > Following the release of the 2.6.19 kernel, i installed it and after few > reboots , i caught this oops: > > Picture's here : http://philou.org/2.6.19/2.6.19.crash.at.boot.jpg Boy, that's one obscure oops trace. Do they all look like that? If not, please send some more. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device naming randomness (udev?)
On Mon, Dec 04, 2006 at 12:12:06AM +0100, Bj?rn Steinbrink wrote: > On 2006.12.03 14:39:44 -0800, Martin J. Bligh wrote: > > This PC has 1 ethernet interface, an e1000. Ubuntu Dapper. > > > > On 2.6.14, my e1000 interface appears as eth0. > > On 2.6.15 to 2.6.18, my e1000 interface appears as eth1. > > > > In both cases, there are no other ethX interfaces listed in > > "ifconfig -a". There are no modules involved, just a static > > kernel build. > > > > Is this a bug in udev, or the kernel? I'm presuming udev, > > but seems odd it changes over a kernel release boundary. > > Any ideas on how I get rid of it? Makes automatic switching > > between kernel versions a royal pain in the ass. > > Just a wild guess here... Debian's (and I guess Ubuntu's) udev rules > contain a generator for persistent interface name rules. Maybe these > start working with 2.6.15 and thus the switch (ie. the kernel would call > it eth0, but udev renames it to eth1). > The generated rules are written to > /etc/udev/rules.d/z25_persistent-net.rules on Debian, not sure if its > the same for Ubuntu. Editing/removing the rules should fix your problem. Yes, I'd place odds on this one. Martin, any followup? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] New firewire stack
On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote: > Alexey Dobriyan wrote: > > On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote: > >> I'm announcing an alternative firewire stack that I've been working on > >> the last few weeks. > > > > Is mainline firewire so hopeless, that you've decided to rewrite it? Could > > you show some ugly places in it? > > Yes. I'm not doing this lightheartedly. It's a lot of work and it will > introduce regressions and instability for a little while. > > My main point about ohci1394 (the old stacks PCI driver) is, that if you > really want to fix the issues with this driver, you have to shuffle the code > around so much that you'll introduce as many regressions as a clean rewrite. > The big problems in the ohci1394 drivers is the irq_handler, bus reset > handling and config rom handling. These are some of the strong points of > fw-ohci.c: My main concern is that when I picked up ieee1394 maint myself, it was because it was not big-endian or 64-bit friendly. I spent the better part of 3 months getting this right on PPC and UltraSPARC. Not because it's hard to fix these issues, but because the hardware is not well defined for a lot of these cases (I know you've seen the ohci1394 code to handle endianness). So while I can understand that ieee1394 doesn't have much man power right now, and that there are some hard to find bugs in the current tree, I can't see how starting from scratch alleviates this. The tree is years old, and a lot of work has been put into it (lots of my work, I'll admit I'm being a little protective). I'm not sure that "replacing" it is wise, or even needed. Fork it, clean it up, but rewriting just doesn't make sense. Granted, this is your time, and you can spend it how you want, I just don't want to see the ieee1394 stack take a step backwards in the hopes that it will be better a year down the road. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
On Tue, 2006-12-05 at 20:40 -0700, Matthew Wilcox wrote: > On Tue, Dec 05, 2006 at 02:56:41PM -0800, Ian Romanick wrote: > > I don't know about SiS, but this is certainly *not* true for Via. There > > are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. > > Yes, but they don't have VIA *AGP*. At least, that's what I've been > told by people who know those architectures. Yeah, I don't know of any VIA AGP chipset used on ppc... Pegasos has a VIA southbridge but no AGP. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Add the ability to template irq handlers in the generic irq code
On parisc, we have the issue that function call pointers are hugely
expensive, so we'd like to minimise their use in the interrupts.
Unfortunately, this involves directly calling the ack/eoi functions
instead of indirecting. To permit this without losing the advantages of
centrally managed irq code, I introduced template builders for irq
handlers. This allows us to construct special handlers on parisc that
don't indirect through function call pointers.
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Some fixes by Andrew Morton and Matthew Wilcox due to rapid code flux
in this area.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
kernel/irq/chip.c | 163 ++---
1 files changed, 104 insertions(+), 59 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index ebfd24a..1b18c5c 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -17,6 +17,87 @@
#include "internals.h"
+/* Helpers for constructing IRQ handlers */
+
+#ifdef CONFIG_SMP
+#define HANDLE_PERCPU_IRQ(NAME, ACK, EOI) \
+void fastcall \
+handle_percpu_irq##NAME(unsigned int irq, struct irq_desc *desc) \
+{ \
+ irqreturn_t action_ret; \
+ \
+ kstat_this_cpu.irqs[irq]++; \
+ \
+ ACK(desc, irq); \
+ \
+ action_ret = handle_IRQ_event(irq, desc->action); \
+ if (!noirqdebug)\
+ note_interrupt(irq, desc, action_ret); \
+ \
+ EOI(desc,irq); \
+}
+#else
+#define HANDLE_PERCPU_IRQ(NAME, ACK, END)
+#endif /* CONFIG_SMP */
+
+#define HANDLE_LEVEL_IRQ(NAME, MASK, UNMASK) \
+void fastcall \
+handle_level_irq##NAME(unsigned int irq, struct irq_desc *desc)
\
+{ \
+ unsigned int cpu = smp_processor_id(); \
+ struct irqaction *action; \
+ irqreturn_t action_ret; \
+ \
+ spin_lock(>lock); \
+ MASK(desc, irq);\
+ \
+ if (unlikely(desc->status & IRQ_INPROGRESS))\
+ goto out_unlock;\
+ desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);\
+ kstat_cpu(cpu).irqs[irq]++; \
+ \
+ /* \
+* If its disabled or no action available \
+* keep it masked and get out of here \
+*/ \
+ action = desc->action; \
+ if (unlikely(!action || (desc->status & IRQ_DISABLED))) { \
+ desc->status |= IRQ_PENDING;\
+ goto out_unlock;\
+ } \
+ \
+ desc->status |= IRQ_INPROGRESS; \
+ desc->status &= ~IRQ_PENDING; \
+ spin_unlock(>lock); \
+ \
+ action_ret = handle_IRQ_event(irq, action); \
+ if (!noirqdebug)\
+ note_interrupt(irq, desc, action_ret); \
+ \
+ spin_lock(>lock); \
+ desc->status &= ~IRQ_INPROGRESS;\
+ UNMASK(desc,irq); \
+out_unlock:
[PATCH 1/3] Delete unused irq functions on powerpc
The ack_irq macro is unused and conflicts with James' work to template
the generic irq code. mask_irq and unmask_irq are also unused, so delete
those macros too.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
include/asm-powerpc/hw_irq.h | 19 ---
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/include/asm-powerpc/hw_irq.h b/include/asm-powerpc/hw_irq.h
index d604863..9e4dd98 100644
--- a/include/asm-powerpc/hw_irq.h
+++ b/include/asm-powerpc/hw_irq.h
@@ -107,25 +107,6 @@ static inline void local_irq_save_ptr(un
#endif /* CONFIG_PPC64 */
-#define mask_irq(irq) \
- ({ \
- irq_desc_t *desc = get_irq_desc(irq); \
- if (desc->chip && desc->chip->disable) \
- desc->chip->disable(irq); \
- })
-#define unmask_irq(irq)\
- ({ \
- irq_desc_t *desc = get_irq_desc(irq); \
- if (desc->chip && desc->chip->enable) \
- desc->chip->enable(irq);\
- })
-#define ack_irq(irq) \
- ({ \
- irq_desc_t *desc = get_irq_desc(irq); \
- if (desc->chip && desc->chip->ack) \
- desc->chip->ack(irq); \
- })
-
/*
* interrupt-retrigger: should we handle this via lost interrupts and IPIs
* or should we not care like we do now ? --BenH.
--
1.4.3.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Convert parisc to generic irq handling
Also make use of the specific ability to template interrupts for the
timer and IPI interrupts.
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Updated for pt_regs changes
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
arch/parisc/kernel/irq.c | 23 ++-
drivers/parisc/iosapic.c |7 +++
include/asm-parisc/irq-handlers.h | 15 +++
include/asm-parisc/irq.h | 21 +++--
4 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/arch/parisc/kernel/irq.c b/arch/parisc/kernel/irq.c
index b39c5b9..2a929a2 100644
--- a/arch/parisc/kernel/irq.c
+++ b/arch/parisc/kernel/irq.c
@@ -35,9 +35,6 @@
#undef PARISC_IRQ_CR16_COUNTS
-extern irqreturn_t timer_interrupt(int, void *);
-extern irqreturn_t ipi_interrupt(int, void *);
-
#define EIEM_MASK(irq) (1UL<<(CPU_IRQ_MAX - irq))
/* Bits in EIEM correlate with cpu_irq_action[].
@@ -88,7 +85,7 @@ static unsigned int cpu_startup_irq(unsi
void no_ack_irq(unsigned int irq) { }
void no_end_irq(unsigned int irq) { }
-void cpu_ack_irq(unsigned int irq)
+void cpu_ack_irq(struct irq_desc *dummy, unsigned int irq)
{
unsigned long mask = EIEM_MASK(irq);
int cpu = smp_processor_id();
@@ -105,7 +102,7 @@ void cpu_ack_irq(unsigned int irq)
mtctl(mask, 23);
}
-void cpu_end_irq(unsigned int irq)
+void cpu_end_irq(struct irq_desc *dummy, unsigned int irq)
{
unsigned long mask = EIEM_MASK(irq);
int cpu = smp_processor_id();
@@ -155,8 +152,6 @@ static struct hw_interrupt_type cpu_inte
.shutdown = cpu_disable_irq,
.enable = cpu_enable_irq,
.disable= cpu_disable_irq,
- .ack= cpu_ack_irq,
- .end= cpu_end_irq,
#ifdef CONFIG_SMP
.set_affinity = cpu_set_affinity_irq,
#endif
@@ -253,8 +248,8 @@ int cpu_claim_irq(unsigned int irq, stru
return -EBUSY;
if (type) {
- irq_desc[irq].chip = type;
- irq_desc[irq].chip_data = data;
+ set_irq_chip(irq, type);
+ set_irq_chip_data(irq, data);
cpu_interrupt_type.enable(irq);
}
return 0;
@@ -377,7 +372,7 @@ void do_cpu_irq_mask(struct pt_regs *reg
goto set_out;
}
#endif
- __do_IRQ(irq);
+ generic_handle_irq(irq);
out:
irq_exit();
@@ -406,15 +401,17 @@ static struct irqaction ipi_action = {
static void claim_cpu_irqs(void)
{
int i;
- for (i = CPU_IRQ_BASE; i <= CPU_IRQ_MAX; i++) {
- irq_desc[i].chip = _interrupt_type;
- }
+ for (i = CPU_IRQ_BASE; i <= CPU_IRQ_MAX; i++)
+ set_irq_chip_and_handler(i, _interrupt_type,
+handle_level_irq_chip);
irq_desc[TIMER_IRQ].action = _action;
irq_desc[TIMER_IRQ].status |= IRQ_PER_CPU;
+ set_irq_handler(TIMER_IRQ, handle_specific_irq_timer);
#ifdef CONFIG_SMP
irq_desc[IPI_IRQ].action = _action;
irq_desc[IPI_IRQ].status = IRQ_PER_CPU;
+ set_irq_handler(IPI_IRQ, handle_specific_irq_ipi);
#endif
}
diff --git a/drivers/parisc/iosapic.c b/drivers/parisc/iosapic.c
index 12bab64..4e9f660 100644
--- a/drivers/parisc/iosapic.c
+++ b/drivers/parisc/iosapic.c
@@ -686,13 +686,13 @@ printk("\n");
* i386/ia64 support ISA devices and have to deal with
* edge-triggered interrupts too.
*/
-static void iosapic_end_irq(unsigned int irq)
+void iosapic_end_irq(struct irq_desc *dummy, unsigned int irq)
{
struct vector_info *vi = iosapic_get_vector(irq);
DBG(KERN_DEBUG "end_irq(%d): eoi(%p, 0x%x)\n", irq,
vi->eoi_addr, vi->eoi_data);
iosapic_eoi(vi->eoi_addr, vi->eoi_data);
- cpu_end_irq(irq);
+ cpu_end_irq(NULL, irq);
}
static unsigned int iosapic_startup_irq(unsigned int irq)
@@ -729,8 +729,6 @@ static struct hw_interrupt_type iosapic_
.shutdown = iosapic_disable_irq,
.enable = iosapic_enable_irq,
.disable = iosapic_disable_irq,
- .ack = cpu_ack_irq,
- .end = iosapic_end_irq,
#ifdef CONFIG_SMP
.set_affinity = iosapic_set_affinity_irq,
#endif
@@ -819,6 +817,7 @@ int iosapic_fixup_irq(void *isi_obj, str
vi->eoi_data = cpu_to_le32(vi->txn_data);
cpu_claim_irq(vi->txn_irq, _interrupt_type, vi);
+ set_irq_handler(vi->txn_irq, handle_level_irq_iosapic);
out:
pcidev->irq = vi->txn_irq;
diff --git a/include/asm-parisc/irq-handlers.h
b/include/asm-parisc/irq-handlers.h
new file mode 100644
index 000..95a9d1b
--- /dev/null
+++ b/include/asm-parisc/irq-handlers.h
@@ -0,0 +1,8 @@
+HANDLE_LEVEL_IRQ(_chip, cpu_ack_irq, cpu_end_irq)
+HANDLE_SPECIFIC_IRQ(_timer, cpu_ack_irq, cpu_end_irq, timer_interrupt)
+#ifdef CONFIG_SMP
+HANDLE_SPECIFIC_IRQ(_ipi, cpu_ack_irq, cpu_end_irq, ipi_interrupt)
+#endif
+#ifdef
Re: Infinite retries reading the partition table
> On Tue, 5 Dec 2006 21:00:20 -0800 (PST) Luben Tuikov <[EMAIL PROTECTED]>
> wrote:
> --- Michael Reed <[EMAIL PROTECTED]> wrote:
> > Luben Tuikov wrote:
> > ...snip...
> > > This statement in scsi_io_completion() causes the infinite retry loop:
> > >if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> > > return;
> >
> > The code in 2.6.19 is "result==0", not "!!result", which is logically
> > the same as "result!=0". Did you mean to change the logic here?
> > Am I missing something?
>
> Hmm, I think my trees have !!result from an earlier patch I posted.
>
> In this case it would appear that the second chunk of the patch
> wouldn't be necessary, since result==0 would be false, and it
> wouldn't retry.
>
I fixed things up. The below is as-intended, yes?
diff -puN
drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
drivers/scsi/scsi_error.c
--- a/drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
+++ a/drivers/scsi/scsi_error.c
@@ -359,6 +359,11 @@ static int scsi_check_sense(struct scsi_
return SUCCESS;
case MEDIUM_ERROR:
+ if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
+ sshdr.asc == 0x13 || /* AMNF DATA FIELD */
+ sshdr.asc == 0x14) { /* RECORD NOT FOUND */
+ return SUCCESS;
+ }
return NEEDS_RETRY;
case HARDWARE_ERROR:
diff -puN
drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
+++ a/drivers/scsi/scsi_lib.c
@@ -871,7 +871,8 @@ void scsi_io_completion(struct scsi_cmnd
* are leftovers and there is some kind of error
* (result != 0), retry the rest.
*/
- if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
+ if (good_bytes &&
+ scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
return;
/* good_bytes = 0, or (inclusive) there were leftovers and
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Michael Reed <[EMAIL PROTECTED]> wrote: > Luben Tuikov wrote: > ...snip... > > This statement in scsi_io_completion() causes the infinite retry loop: > >if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) > > return; > > The code in 2.6.19 is "result==0", not "!!result", which is logically > the same as "result!=0". Did you mean to change the logic here? > Am I missing something? Hmm, I think my trees have !!result from an earlier patch I posted. In this case it would appear that the second chunk of the patch wouldn't be necessary, since result==0 would be false, and it wouldn't retry. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Relative atime (was Re: What's in ocfs2.git)
> On Mon, 4 Dec 2006 16:36:20 -0800 Valerie Henson <[EMAIL PROTECTED]> wrote:
> Add "relatime" (relative atime) support. Relative atime only updates
> the atime if the previous atime is older than the mtime or ctime.
> Like noatime, but useful for applications like mutt that need to know
> when a file has been read since it was last modified.
That seems like a good idea.
I found touch_atime() to be rather putrid, so I hacked it around a bit. The
end result:
void touch_atime(struct vfsmount *mnt, struct dentry *dentry)
{
struct inode *inode = dentry->d_inode;
struct timespec now;
if (IS_RDONLY(inode))
return;
if (inode->i_flags & S_NOATIME)
return;
if (inode->i_sb->s_flags & MS_NOATIME)
return;
if ((inode->i_sb->s_flags & MS_NODIRATIME) && S_ISDIR(inode->i_mode))
return;
/*
* We may have a NULL vfsmount when coming from NFSD
*/
if (mnt) {
if (mnt->mnt_flags & MNT_NOATIME)
return;
if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))
return;
if (mnt->mnt_flags & MNT_RELATIME) {
/*
* With relative atime, only update atime if the
* previous atime is earlier than either the ctime or
* mtime.
*/
if (timespec_compare(>i_mtime,
>i_atime) < 0 &&
timespec_compare(>i_ctime,
>i_atime) < 0)
return;
}
}
now = current_fs_time(inode->i_sb);
if (timespec_equal(>i_atime, ))
return;
inode->i_atime = now;
mark_inode_dirty_sync(inode);
}
Does it still look right?
Note the reordering to avoid the current_fs_time() call if poss.
That's the easy part. How are we going to get mount(8) patched?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] saa7134: add support for the Encore ENL-TV
This patch adds a board definition for the Encore ENL-TV card, and
adds its PCI subdevice to the ID table. Patch is output from
git-format-patch against Linus' git tree.
Please let me know if there are any deficiencies in this submission.
--
-Steven Walter <[EMAIL PROTECTED]>
From c976999abbe1393dfa511a43cab145c17103bbdf Mon Sep 17 00:00:00 2001
From: Steven Walter <[EMAIL PROTECTED]>
Date: Tue, 5 Dec 2006 23:41:55 -0500
Subject: [PATCH] [PATCH] Add support for the Encore ENL-TV to saa7134
Create a board definition for the ENL-TV, and add its subdevice ID to the
table.
Signed-off-by: Steven Walter <[EMAIL PROTECTED]>
---
drivers/media/video/saa7134/saa7134-cards.c | 24
drivers/media/video/saa7134/saa7134.h |1 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 51f0cfd..dd3758a 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -3022,6 +3022,24 @@ struct saa7134_board saa7134_boards[] =
.amux = LINE1,
},
},
+ [SAA7134_BOARD_ENCORE_ENLTV] = {
+ /* Steven Walter <[EMAIL PROTECTED]> */
+ .name = "Encore ENLTV",
+ .tuner_type = TUNER_TNF_5335MF,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = LINE2,
+ .tv = 1,
+ },{
+ .name = name_svideo,
+ .vmux = 6,
+ .amux = LINE1,
+ }},
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -3631,6 +3649,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0x4860,
.driver_data = SAA7134_BOARD_ASUS_EUROPA2_HYBRID,
},{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7130,
+ .subvendor= PCI_VENDOR_ID_PHILIPS,
+ .subdevice= 0x2342,
+ .driver_data = SAA7134_BOARD_ENCORE_ENLTV,
+ },{
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
diff --git a/drivers/media/video/saa7134/saa7134.h
b/drivers/media/video/saa7134/saa7134.h
index 7cf96b4..8ee165a 100644
--- a/drivers/media/video/saa7134/saa7134.h
+++ b/drivers/media/video/saa7134/saa7134.h
@@ -227,6 +227,7 @@ #define SAA7134_BOARD_FLYDVBS_LR300 97
#define SAA7134_BOARD_PROTEUS_2309 98
#define SAA7134_BOARD_AVERMEDIA_A16AR 99
#define SAA7134_BOARD_ASUS_EUROPA2_HYBRID 100
+#define SAA7134_BOARD_ENCORE_ENLTV 101
#define SAA7134_MAXBOARDS 8
#define SAA7134_INPUT_MAX 8
--
1.4.1
Re: [PATCH 21/35] Unionfs: Inode operations
On Tue, 5 Dec 2006 13:50:17 -0800 Andrew Morton wrote: > On Tue, 5 Dec 2006 22:27:10 +0100 (MET) > Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > > Someone refresh me: what's the correct[preferred] kdoc style? > > This isn't part of kernel-doc, if that's what you mean. > > > (A) > > /* Lorem ipsum dolor sit amet, consectetur > > * adipisicing elit, sed do eiusmod tempor > > * incididunt ut labore et dolore magna aliqua. */ > > > > (B) > > /* Lorem ipsum dolor sit amet, consectetur > >adipisicing elit, sed do eiusmod tempor > >incididunt ut labore et dolore magna aliqua. */ > > > > (C) > > /* Lorem ipsum dolor sit amet, consectetur > > adipisicing elit, sed do eiusmod tempor incididunt > > ut labore et dolore magna aliqua. */ > > You forgot (D), (E), (F), (G) and a whole lot more besides. > > It doesn't matter a lot what we do, but we should do it one way and not 38 > ways. > > Documentation/CodingStyle doesn't mention commenting at all (eyes roll > heavenwards). I have several (probably 5-6) Doc/CodingStyle changes in my WIP (work-in-progress) folder that I will do in the next few days. > This > > /* >* Lorem ipsum dolor sit amet, consectetur >* adipisicing elit, sed do eiusmod tempor >* incididunt ut labore et dolore magna aliqua. >*/ > > is probably the most common, and is what I use when forced to descrog > comments. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ata/kconfig: Re: Why SCSI module needed for PCI-IDE ATA only disks ?
On Tue, 05 Dec 2006 21:46:54 -0500 Ed Sweetman wrote: -ETOOMANYWORDS && -ENOPATCH, so here is one to consider. Help text can also be added. This is similar to what USB storage already does. --- From: Randy Dunlap <[EMAIL PROTECTED]> Provide more clues about SCSI config options that are needed for libata (SATA/PATA) drivers. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/ata/Kconfig |9 + 1 file changed, 9 insertions(+) --- linux-2.6.19-git7.orig/drivers/ata/Kconfig +++ linux-2.6.19-git7/drivers/ata/Kconfig @@ -17,6 +17,15 @@ config ATA that "speaks" the ATA protocol, also called ATA controller), because you will be asked for it. +comment "NOTE: ATA enables basic SCSI support; *however*," + depends on ATA +comment "+ 'SCSI disk support', 'SCSI tape support', or '" + depends on ATA +comment "+ 'SCSI CDROM support' may also be needed," + depends on ATA +comment "+ depending on your hardware configuration." + depends on ATA + if ATA config SATA_AHCI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Hi, On Tue, 05 Dec 2006, Roman Zippel wrote: > On Mon, 4 Dec 2006, Andrew Morton wrote: > > kbuild-dont-put-temp-files-in-the-source-tree.patch > > actually-delete-the-as-instr-ld-option-tmp-file.patch > > Andi had objections about the mktemp usage and I agree with him. > The proposed patch in bugzilla didn't have this and no further > justification was given for why it's needed. > Below is a replacement patch with some improvements: > - kbuild doesn't use $(AS), so use $(CC) > - tmp dir needs only to be calculated once > - reformat a bit to keep it under 80 columns and to be more readable > > bye, Roman > > Signed-off-by: Roman Zippel <[EMAIL PROTECTED]> This patch looks good to me, and I'd prefer it over the (twice corrected) one currently in -mm. - It's close to what Daniel Drake proposed recently [1] (main difference: corrects the very same problem for ld-option, which might otherwise bite us later) and what's already in Gentoo's patchkernel, - it abstains from using mktemp, hopefully making Andi happy ;), - resolves the current Gentoo sandbox issues without touching more kbuild code than necessary. Kind regards, Horst [1]Message-Id: <[EMAIL PROTECTED]> -- PGP-Key 0xD40E0E7A signature.asc Description: Digital signature
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
On Tue, Dec 05, 2006 at 02:56:41PM -0800, Ian Romanick wrote: > I don't know about SiS, but this is certainly *not* true for Via. There > are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. Yes, but they don't have VIA *AGP*. At least, that's what I've been told by people who know those architectures. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
> On Wed, 6 Dec 2006 03:59:41 +0100 (CET) Roman Zippel <[EMAIL PROTECTED]> > wrote: > Hi, > > On Mon, 4 Dec 2006, Andrew Morton wrote: > > > [dyntick] > > > > Shall merge, I guess. My confidence is low, but it's Kconfigurable and it > > needs to get sorted out. > > IMO it least at needs one more iteration to address the comments that > were made (not just mine), in the short term the less it touches > unconditionally the less I care right now. I don't have a clue which review comments remain unaddressed - do you recall? I never saw an item-by-item accounting of my own (extensive) review comments, actually. And then an avalanche of new stuff got sent and I didn't have time to go through it all at the same level of detail. So yeah, I don't have a lot of confidence from that POV either. But otoh, I'm confident that Ingo and Thomas will competently and promptly address regressions, so the risk factor isn't too bad. And changing APIC and timekeeping code sure is risky. Yes, I too am wobbly about a 2.6.20 merge. But otoh I doubt if much will get changed if it sits in -mm for another two months. As long as it's heading in the right direction and doesn't break things when it is configged-off then OK. > In the long term IMO this might need a major rework, the basic problem I > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how > to dynamically manage multiple timer. I'm not sure I understand that. Are you referring to multiple, concurrently-operating hardware clock sources? If so, that's more a clocksource thing than a dynticks/hrtimer thing, isn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git Which contains: Jamie Lenehan (1): sh: sh775x/titan fixes for irq header changes. Mark Glaisher (1): sh: dma-api channel capability extensions. Paul Mundt (29): sh: SE7206 build fixes. sh: Fixup entry-common path breakage for SH-3. sh: Configurable timer IRQ. sh: Drop CPU subtype IRQ headers. sh: Hook SH7785 in to the build system. sh: Preliminary support for SH-X2 MMU. sh: p3map_sem sem2mutex conversion. sh: Explicit endian selection support. sh: generic push-switch framework. sh: R7780RP push-switch support. sh: dma-sysfs fixes. sh: Make dma-isa depend on ISA_DMA_API. sh: Drop name overload in dma-sh. sh: Fixup 4K irq stacks. sh: Fixup various PAGE_SIZE == 4096 assumptions. sh: More flexible + SH7780 earlyprintk SCIF support. sh: Fix store queue bitmap end. sh: Get the PGD right in oops case with 64-bit PTEs. sh: Turn off IRQs around get_timer_offset() calls. sh: Clock framework tidying. sh: dyntick infrastructure. sh: Fixup movli.l/movco.l atomic ops for gcc4. sh: stacktrace/lockdep/irqflags tracing support. sh: platform_pata support for R7780RP sh: show held locks in stack trace with lockdep. sh: set KBUILD_IMAGE to something sensible. sh: Fixup pte_mkhuge() build failure. sh: compile fixes for header cleanup. sh: update r7780rp defconfig. Stuart Menefy (7): sh: gcc4 support. sh: Set up correct siginfo structures for page faults. sh: Use MMU.TTB register as pointer to current pgd. sh: pmd rework. sh: TLB miss fast-path optimizations. sh: KSTK_EIP/KSTK_ESP consistency. sh: Fix syscall tracing ordering. Yoshinori Sato (5): sh: Add support for SH7206 and SH7619 CPU subtypes. sh: Wire up division and address error exceptions on SH-2A. sh: Exception vector rework and SH-2/SH-2A support. sh: Add SH-2A platform headers. sh: Add support for Solution Engine 7206 and 7619 boards. arch/sh/Kconfig | 100 +++ arch/sh/Kconfig.debug | 22 arch/sh/Makefile| 26 arch/sh/boards/renesas/r7780rp/Makefile |4 arch/sh/boards/renesas/r7780rp/irq.c|1 arch/sh/boards/renesas/r7780rp/psw.c| 122 arch/sh/boards/renesas/r7780rp/setup.c | 29 + arch/sh/boards/se/7206/Makefile |7 arch/sh/boards/se/7206/io.c | 123 arch/sh/boards/se/7206/irq.c| 139 + arch/sh/boards/se/7206/led.c| 57 ++ arch/sh/boards/se/7206/setup.c | 79 ++ arch/sh/boards/se/7619/Makefile |5 arch/sh/boards/se/7619/io.c | 102 +++ arch/sh/boards/se/7619/setup.c | 43 + arch/sh/boards/titan/setup.c| 27 - arch/sh/boot/compressed/misc.c |3 arch/sh/configs/r7780rp_defconfig | 69 +- arch/sh/configs/se7206_defconfig| 826 +++ arch/sh/drivers/Kconfig |9 arch/sh/drivers/Makefile|2 arch/sh/drivers/dma/Makefile|4 arch/sh/drivers/dma/dma-api.c | 274 +++--- arch/sh/drivers/dma/dma-sh.c|9 arch/sh/drivers/dma/dma-sysfs.c | 23 arch/sh/drivers/pci/ops-titan.c | 24 arch/sh/drivers/pci/pci-sh7780.c| 14 arch/sh/drivers/push-switch.c | 138 + arch/sh/kernel/Makefile |3 arch/sh/kernel/cpu/Makefile | 11 arch/sh/kernel/cpu/clock.c | 27 - arch/sh/kernel/cpu/init.c |2 arch/sh/kernel/cpu/irq/Makefile |3 arch/sh/kernel/cpu/irq/imask.c |5 arch/sh/kernel/cpu/irq/intc2.c | 25 arch/sh/kernel/cpu/irq/ipr.c| 93 --- arch/sh/kernel/cpu/sh2/Makefile |3 arch/sh/kernel/cpu/sh2/clock-sh7619.c | 81 +++ arch/sh/kernel/cpu/sh2/entry.S | 341 arch/sh/kernel/cpu/sh2/ex.S | 46 + arch/sh/kernel/cpu/sh2/probe.c | 16 arch/sh/kernel/cpu/sh2/setup-sh7619.c | 53 ++ arch/sh/kernel/cpu/sh2a/Makefile| 10 arch/sh/kernel/cpu/sh2a/clock-sh7206.c | 85 +++ arch/sh/kernel/cpu/sh2a/probe.c | 39 + arch/sh/kernel/cpu/sh2a/setup-sh7206.c | 58 ++ arch/sh/kernel/cpu/sh3/Makefile |2 arch/sh/kernel/cpu/sh3/clock-sh7709.c |2 arch/sh/kernel/cpu/sh3/entry.S | 693 ++ arch/sh/kernel/cpu/sh4/Makefile |3 arch/sh/kernel/cpu/sh4/clock-sh4-202.c |4 arch/sh/kernel/cpu/sh4/clock-sh7780.c |2 arch/sh/kernel/cpu/sh4/fpu.c| 25 arch/sh/kernel/cpu/sh4/probe.c | 19 arch/sh/kernel/cpu/sh4/setup-sh7750.c | 70 ++
Re:can't boot : Spurious ACK with kernel 2.6.19
Based on the email "xtables/iptables and atkbd.c Spurious ACK on isa0060/serio0" from >[EMAIL PROTECTED] I checked my configuration. And yes, I have >CONFIG_NETFILTER_XTABLES=m and CONFIG_IP_NF_IPTABLES=m as well. -- Bernd If you try a recompile without xtables and iptables,will everything work? I'm hoping the next patch will resolve this issue. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Hi, On Mon, 4 Dec 2006, Andrew Morton wrote: > [dyntick] > > Shall merge, I guess. My confidence is low, but it's Kconfigurable and it > needs to get sorted out. IMO it least at needs one more iteration to address the comments that were made (not just mine), in the short term the less it touches unconditionally the less I care right now. In the long term IMO this might need a major rework, the basic problem I have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how to dynamically manage multiple timer. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why SCSI module needed for PCI-IDE ATA only disks ?
Robert Hancock wrote: Ed Sweetman wrote: What's not a legitimate configuration is libata drivers, no low level scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is the configuration the kernel currently gives you. How is that more correct than any of the 3 solutions I have suggested? You can't build libata without low-level SCSI drivers. CONFIG_ATA automatically selects CONFIG_SCSI. config scsi isn't low level. There are no scsi controllers selected by selecting config_ata. Mening, that the user hasn't bothered going into the SCSI section. In effect you have a system that detects the ata controllers but nothing that can use the drives on them. How is that a valid system, a system where no drives are usable, but having some mention of the configuration in the Help of libata or automatically selecting those scsi_sd, sr, and sg drivers and letting the user deselect them as needed instead of the other way around Not a valid are more correct system? No matter what when you select a scsi controller or libata controller you are going to need to select one or more of those scsi device drivers (sr,sg,sd) the issue is that when you are only using libata, you have no reason to bother with the scsi section so it's not readily apparent that you would need those block device drivers. I'm not saying we should auto select them, but I am saying that auto selecting is way better than keeping the kernel configuration the way it is and selecting none. In the end the problem is in the layout of the config. SCSI is _THE_ device interface protocol but most people dont have scsi physical interfaces. The kernel differentiates between the two inside the SCSI section. This made sense before ide was marked for eventual replacement by libata. Now everything uses that scsi top level for block device access. That effectively makes those scsi block devices generic block devices. SCSI and LIBATA sections should have configuration options that are relevant to those physical devices and interfaces and not require options from eachother's sections to get drivers in their own sections to work. Massively shared config options shouldn't be stuck in some sub menu below where all the things that use it are located. But that's for some much later version of the kernel to deal with (when ide is removed and such). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
In-Reply-To: <[EMAIL PROTECTED]> On Tue, 05 Dec 2006 22:11:11 +, David Howells wrote: > > I only have 32-bit userspace. When I run your program against > > a directory on a JFS filesystem (msdos ioctls not supported) > > I get this on vanilla 2.6.19: > > Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit > kernel, but with a completely 32-bit userspace? It's FC5 i386 so there's no way any 64-bit userspace code is in there. (I have a cross-compiler only for building kernels.) Having a pure 32-bit userspace lets me switch between i386 and x86_64 kernels without having to maintain two separate Linux installs. > A question for you: Why is userspace assuming that it'll get ENOTTY rather > than EINVAL? I'm not sure it is, but that's what it used to get. Kasper, what problems (other that the annoying message) are you having? -- Chuck "Even supernovas have their duller moments." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Convert pxaficp_ir.c to platform_driver
Hello linux-kernel,
drivers/ner/irda/pxaficp_ir.c was not converted to platform_driver,
which in 2.6.19 ( after commit
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=386415d88b1ae50304f9c61aa3e0db082fa90428;hp=bb84c89f94851161f387285d0a449b4a3f29f4df
) leads to random memory corruption, resume problems, etc. We
specifically face issues with HP iPaq hx4700 device, which has
nondeterministic resume problems depending on the changes to kernel
config options (not directly related to pxaficp_ir). More info on the
issue: http://lkml.org/lkml/2006/10/25/73 .
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: drivers/net/irda/pxaficp_ir.c
===
RCS file: /cvs/linux/kernel26/drivers/net/irda/pxaficp_ir.c,v
retrieving revision 1.3
diff -u -r1.3 pxaficp_ir.c
--- drivers/net/irda/pxaficp_ir.c 2 Dec 2006 02:18:04 - 1.3
+++ drivers/net/irda/pxaficp_ir.c 6 Dec 2006 02:00:32 -
@@ -704,9 +704,9 @@
return 0;
}
-static int pxa_irda_suspend(struct device *_dev, pm_message_t state)
+static int pxa_irda_suspend(struct platform_device *_dev, pm_message_t state)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev && netif_running(dev)) {
@@ -718,9 +718,9 @@
return 0;
}
-static int pxa_irda_resume(struct device *_dev)
+static int pxa_irda_resume(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev && netif_running(dev)) {
@@ -746,9 +746,8 @@
return io->head ? 0 : -ENOMEM;
}
-static int pxa_irda_probe(struct device *_dev)
+static int pxa_irda_probe(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(_dev);
struct net_device *dev;
struct pxa_irda *si;
unsigned int baudrate_mask;
@@ -822,9 +821,9 @@
return err;
}
-static int pxa_irda_remove(struct device *_dev)
+static int pxa_irda_remove(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
if (dev) {
struct pxa_irda *si = netdev_priv(dev);
@@ -840,9 +839,10 @@
return 0;
}
-static struct device_driver pxa_ir_driver = {
- .name = "pxa2xx-ir",
- .bus= _bus_type,
+static struct platform_driver pxa_ir_driver = {
+ .driver = {
+ .name = "pxa2xx-ir",
+ },
.probe = pxa_irda_probe,
.remove = pxa_irda_remove,
.suspend= pxa_irda_suspend,
@@ -851,12 +851,12 @@
static int __init pxa_irda_init(void)
{
- return driver_register(_ir_driver);
+ return platform_driver_register(_ir_driver);
}
static void __exit pxa_irda_exit(void)
{
- driver_unregister(_ir_driver);
+ platform_driver_unregister(_ir_driver);
}
module_init(pxa_irda_init);
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why SCSI module needed for PCI-IDE ATA only disks ?
Ed Sweetman wrote: What's not a legitimate configuration is libata drivers, no low level scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is the configuration the kernel currently gives you. How is that more correct than any of the 3 solutions I have suggested? You can't build libata without low-level SCSI drivers. CONFIG_ATA automatically selects CONFIG_SCSI. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nbd: show nbd client pid in sysfs
This simple patch allows nbd to expose the nbd-client daemon's PID in
/sys/block/nbd/pid. This is helpful for tracking connection status of
a device and for determining which nbd devices are currently in use.
Tested against 2.6.19.
Thanks,
Paul
--- ./drivers/block/nbd.c Wed Nov 29 16:57:37 2006
+++ ./drivers/block/nbd.c Tue Nov 28 16:09:31 2006
@@ -355,14 +389,30 @@ harderror:
return NULL;
}
+static ssize_t pid_show(struct gendisk *disk, char *page)
+{
+ return sprintf(page, "%ld\n",
+ (long) ((struct nbd_device *)disk->private_data)->pid);
+}
+
+static struct disk_attribute pid_attr = {
+ .attr = { .name = "pid", .mode = S_IRUGO },
+ .show = pid_show,
+};
+
static void nbd_do_it(struct nbd_device *lo)
{
struct request *req;
BUG_ON(lo->magic != LO_MAGIC);
+ lo->pid = current->pid;
+ sysfs_create_file(>disk->kobj, _attr.attr);
+
while ((req = nbd_read_stat(lo)) != NULL)
nbd_end_request(req);
+
+ sysfs_remove_file(>disk->kobj, _attr.attr);
return;
}
--- ./include/linux/nbd.h Wed Nov 29 16:57:37 2006
+++ ./include/linux/nbd.h Mon Dec 4 23:28:30 2006
@@ -64,6 +64,7 @@ struct nbd_device {
struct gendisk *disk;
int blksize;
u64 bytesize;
+ pid_t pid; /* pid of nbd-client, if attached */
};
#endif
Re: Why SCSI module needed for PCI-IDE ATA only disks ?
Robert Hancock wrote: Ed Sweetman wrote: Jeff Garzik wrote: Bernard Pidoux wrote: I am asking why need to compile the following modules while I do not have any SCSI device ? libata uses SCSI to provide a lot of infrastructure that it would otherwise have to recreate. Also, using SCSI meant that it automatically worked in existing installers. Jeff This confusion could easily be remedied by explaining the requirement in the Help output for libata drivers/section. Also, making a dependency in the menu (since there is one) or automatically selecting the required scsi items when you select a libata driver would seem logical. As it is, nothing is said of scsi requirements in menuconfig. Trying to boot a machine without compiling the scsi drivers (something you're allowed to do) results in a system that boots and initializes the ata busses but can't communicate to any of the drives on them, (useless). You can't select libata drivers without the SCSI core. However, you can select libata drivers without the SCSI disk (sd) or the SCSI CD (sr) drivers. However, that's a legitimate configuration as you may have only hard disks, only CD drives, etc. and there would be no need to build the other module. This isn't a major problem for most standard configurations as those drivers are needed to handle things like USB and FireWire flash drives, external HDs/optical drives, etc. anyway. What's not a legitimate configuration is libata drivers, no low level scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is the configuration the kernel currently gives you. How is that more correct than any of the 3 solutions I have suggested? The point is there is nothing in the help section in libata to tell you that these "scsi" drivers are needed for disk / cdrom / generic device access in libata. Indeed, there is no obvious connection to the two. Either configuration options need to be put in the libata directory that would just select the drivers (libata disk, cdrom, generic configuration options which would just enable the appropriate config variable, in other words in the menu config have two config directives which would enable the same drivers but be under different submenus to avoid confusion), or a short description in the help dialog to tell users that they have to enable those scsi drivers under the scsi section to use their drivers under the libata section. It's not safe to assume people will have those drivers compiled because of usb or firewire or flash drives. Assuming that situation is 10 times more problematic than any possible argument against just selecting those scsi drivers automatically and letting the user deselect them as needed when they select a libata driver. Personaly, I prefer a help dialog blurb explaining that the user has to enable certain scsi drivers to actually use their libata driven devices.That, at the very least, I believe is necessary and not asking much. I've made patches before that impliment these trivial features in menuconfig. In the grand scheme of things this isn't that important to kernel development, but it's going to get more and more feedback as more people move to libata and eventually it will be fixed in some manner similar to those i've mentioned, I think it would just be better to do it now than wait until the mailing list is filled with end users asking why they need scsi when they obviously only have sata/ide and want to use libata. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [openib-general] [PATCH v2 04/13] Connection Manager
If you require more details on how this all works - it was fully explored in the IETF RDDP workgroup - may I suggest a reading of the RDMA Security Considerations draft which goes through many of the issues on how one relates to a host stack. This complements the MPA spec and supports much of what Steve has already responded to during this string of e-mails. We took a great deal of time and debate to insure this can work efficiently and without confusion in terms of who owns what and when. Mike At 10:09 AM 12/5/2006, Evgeniy Polyakov wrote: On Tue, Dec 05, 2006 at 11:51:40AM -0600, Steve Wise ([EMAIL PROTECTED]) wrote: > > Almost - except the case about where those skbs are coming from? > > It looks like they are obtained from network, since it is ethernet > > driver, and if they match some set of rules, they are considered as valid > > MPA negotiation protocol. > > They come from the Ethernet driver, but that driver manages multiple HW > queues and these packets come from an offload queue, not the NIC queue. > So the HW demultiplexes. Ok, thanks for explaination. -- Evgeniy Polyakov ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] linux-fbdev-devel is subscribers-only
From: Randy Dunlap <[EMAIL PROTECTED]> Update linux-fbdev mailing list to subscribers-only. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- MAINTAINERS | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) --- linux-2.6.19-git6.orig/MAINTAINERS +++ linux-2.6.19-git6/MAINTAINERS @@ -677,7 +677,7 @@ S: Supported CIRRUS LOGIC GENERIC FBDEV DRIVER P: Jeff Garzik M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Odd Fixes CIRRUS LOGIC CS4280/CS461x SOUNDDRIVER @@ -784,7 +784,7 @@ S: Maintained CYBLAFB FRAMEBUFFER DRIVER P: Knut Petersen M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained CYCLADES 2X SYNC CARD DRIVER @@ -1115,7 +1115,7 @@ S:Supported FRAMEBUFFER LAYER P: Antonino Daplas M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) W: http://linux-fbdev.sourceforge.net/ S: Maintained @@ -1466,7 +1466,7 @@ S:Maintained IMS TWINTURBO FRAMEBUFFER DRIVER P: Paul Mundt M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained INFINIBAND SUBSYSTEM @@ -1499,13 +1499,13 @@ S: Maintained INTEL FRAMEBUFFER DRIVER (excluding 810 and 815) P: Sylvain Meyer M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained INTEL 810/815 FRAMEBUFFER DRIVER P: Antonino Daplas M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained INTEL APIC/IOAPIC, LOWLEVEL X86 SMP SUPPORT @@ -1951,7 +1951,7 @@ S:Odd Fixes for 2.4; Maintained for 2.6 MATROX FRAMEBUFFER DRIVER P: Petr Vandrovec M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained MEGARAID SCSI DRIVERS @@ -2197,7 +2197,7 @@ S:Maintained NVIDIA (rivafb and nvidiafb) FRAMEBUFFER DRIVER P: Antonino Daplas M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained OPENCORES I2C BUS DRIVER @@ -2474,13 +2474,13 @@ S: Maintained RADEON FRAMEBUFFER DISPLAY DRIVER P: Benjamin Herrenschmidt M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained RAGE128 FRAMEBUFFER DISPLAY DRIVER P: Paul Mackerras M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained RAYLINK/WEBGEAR 802.11 WIRELESS LAN DRIVER @@ -2550,7 +2550,7 @@ S:Orphan S3 SAVAGE FRAMEBUFFER DRIVER P: Antonino Daplas M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) S: Maintained S390 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More ARM binutils fuckage
On 12/5/06, Russell King <[EMAIL PROTECTED]> wrote: There is no such thing as soft VFP. Patches have been floating around for quite some time that implement soft float with VFP parameter passing conventions (which notably implies native endianness, unlike FPA). They all seem to derive from Nicolas Pitre's patch at http://lists.arm.linux.org.uk/pipermail/linux-arm/2003-October/006436.html , which is said to have some bugs but to supply the majority of the needed functionality. (See, for instance, http://www.busybox.net/cgi-bin/viewcvs.cgi/branches/buildroot.mjn3/toolchain/gcc/3.4.6/arm-softfloat.patch.conditional?rev=14854=auto.) I assume that I'm not the first to fix it up for gcc 4.1.1. I can only talk from the requirements of the kernel. gcc 3.4.3 is the minimum for ARM, which with binutils 2.17 will allow you to build the kernel as OABI in *any* configuration. No patches required for either. It would be nice if this appeared prominently in Documentation/arm/whatever so that vendors who are stuck on gcc 3.3 (and binutils so old that they comment things out in vmlinux.lds) can be encouraged to move forward. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] let WARN_ON() output the condition
On Wed, 6 Dec 2006 01:51:01 +0100 (CET)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> [PATCH] let WARN_ON() output the condition
>
> It is possible, in some cases, that the output of WARN_ON() is ambiguous
> and can't be properly used to identify the exact condition which caused
> the warning to trigger. This happens whenever there is a macro that
> contains multiple WARN_ONs inside. Notable example is spin_lock_mutex().
> If any of the two WARN_ONs trigger, we are not able to say which one was
> the cause (as we get only line number, which however belongs to the place
> where the macro was expanded).
>
> This patch lets WARN_ON() to output also the condition and fixes the
> DEBUG_LOCKS_WARN_ON() macro to pass the condition properly to WARN_ON. The
> possible drawback could be when someone passes a condition which has
> sideeffects. Then it would be evaluated twice, instead of current one
> evaluation. On the other hand, when anyone passes expression with
> sideeffects to WARN_ON(), he is asking for problems anyway.
>
> Patch against 2.6.19-rc6-mm2.
>
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
>
> ---
>
> include/asm-generic/bug.h |4 ++--
> include/linux/debug_locks.h |2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index a06eecd..af7574e 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -35,8 +35,8 @@ #ifndef HAVE_ARCH_WARN_ON
> #define WARN_ON(condition) ({
> \
> typeof(condition) __ret_warn_on = (condition); \
> if (unlikely(__ret_warn_on)) { \
> - printk("WARNING at %s:%d %s()\n", __FILE__, \
> - __LINE__, __FUNCTION__);\
> + printk("WARNING (%s) at %s:%d %s()\n", #condition, \
> + __FILE__,__LINE__, __FUNCTION__); \
> dump_stack(); \
> } \
> unlikely(__ret_warn_on);\
> diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
> index 952bee7..1c2b682 100644
> --- a/include/linux/debug_locks.h
> +++ b/include/linux/debug_locks.h
> @@ -25,7 +25,7 @@ ({
> \
> \
> if (unlikely(c)) { \
> if (debug_locks_off()) \
> - WARN_ON(1); \
> + WARN_ON(c); \
> __ret = 1; \
> } \
> __ret; \
Give me an additional 5k of text with distro config. Is it worth it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why SCSI module needed for PCI-IDE ATA only disks ?
Ed Sweetman wrote: Jeff Garzik wrote: Bernard Pidoux wrote: I am asking why need to compile the following modules while I do not have any SCSI device ? libata uses SCSI to provide a lot of infrastructure that it would otherwise have to recreate. Also, using SCSI meant that it automatically worked in existing installers. Jeff This confusion could easily be remedied by explaining the requirement in the Help output for libata drivers/section. Also, making a dependency in the menu (since there is one) or automatically selecting the required scsi items when you select a libata driver would seem logical. As it is, nothing is said of scsi requirements in menuconfig. Trying to boot a machine without compiling the scsi drivers (something you're allowed to do) results in a system that boots and initializes the ata busses but can't communicate to any of the drives on them, (useless). You can't select libata drivers without the SCSI core. However, you can select libata drivers without the SCSI disk (sd) or the SCSI CD (sr) drivers. However, that's a legitimate configuration as you may have only hard disks, only CD drives, etc. and there would be no need to build the other module. This isn't a major problem for most standard configurations as those drivers are needed to handle things like USB and FireWire flash drives, external HDs/optical drives, etc. anyway. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't boot : Spurious ACK with kernel 2.6.19
On Tue, Dec 05, 2006 at 05:53:17PM -0500, Bernd Prager wrote: > I'm trying to upgrade to kernel 1.6.19. > The boot process immediatly locks in a loop with the message: > "atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access > hardware directly." > > The box is running fine with kernel 1.6.18.4. > > It's an iDEQ200V box with a BioStar motherboar, VIA KM400 + VT8237 chipset. > Here's my BIOS information based on dmidecode: > > BIOS Information > Vendor: Phoenix Technologies, LTD > Version: 6.00 PG > Release Date: 08/19/2003 > Address: 0xE > Runtime Size: 128 kB > ROM Size: 512 kB > Characteristics: > ISA is supported > PCI is supported > PNP is supported > APM is supported > BIOS is upgradeable > BIOS shadowing is allowed > ESCD support is available > Boot from CD is supported > Selectable boot is supported > BIOS ROM is socketed > EDD is supported > 5.25"/360 KB floppy services are supported (int 13h) > 5.25"/1.2 MB floppy services are supported (int 13h) > 3.5"/720 KB floppy services are supported (int 13h) > 3.5"/2.88 MB floppy services are supported (int 13h) > Print screen service is supported (int 5h) > 8042 keyboard services are supported (int 9h) > Serial services are supported (int 14h) > Printer services are supported (int 17h) > CGA/mono video services are supported (int 10h) > ACPI is supported > USB legacy is supported > AGP is supported > LS-120 boot is supported > ATAPI Zip drive boot is supported > > ( .. more info available if useful ..) > > Did anybody discovered similar issues or have any ideas on how to solve that? > Based on the email "xtables/iptables and atkbd.c Spurious ACK on isa0060/serio0" from [EMAIL PROTECTED] I checked my configuration. And yes, I have CONFIG_NETFILTER_XTABLES=m and CONFIG_IP_NF_IPTABLES=m as well. -- Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Display class
On Tue, 5 Dec 2006 18:03:39 + (GMT) James Simmons wrote:
> This is the pass at a display class to meet the needs of the output class
> of Mr. Yu for acpi. Also this class could in time replace the lcd class
> located in the backlight directory since a lcd is a type of display.
> The final hope is that the purpose auxdisplay could fall under this
> catergory.
>
> P.S
>I know the edid parsing would have to be pulled out of the fbdev layer.
Hi,
Where is "struct display_properties" defined?
CC [M] drivers/acpi/video.o
drivers/acpi/video.c:183: error: field 'acpi_display_properties' has incomplete
type
make[2]: *** [drivers/acpi/video.o] Error 1
Lots of style issues (see below).
> diff -urN -X fbdev-2.6/Documentation/dontdiff linus-2.6/drivers/acpi/video.c
> fbdev-2.6/drivers/acpi/video.c
> --- linus-2.6/drivers/acpi/video.c2006-11-07 05:38:34.0 -0500
> +++ fbdev-2.6/drivers/acpi/video.c2006-12-04 10:40:48.0 -0500
> @@ -30,6 +30,9 @@
> #include
> #include
> #include
> +#if defined(CONFIG_DISPLAY_DDC)
> +#include
> +#endif
>
> #include
>
> @@ -154,6 +157,20 @@
> int *levels;
> };
>
> +#if defined(CONFIG_DISPLAY_DDC)
> +static int
> +acpi_display_get_power(struct display_device *dev)
Combine those 2 lines into 1 line.
> +{
> + return 0;
> +}
> +
> +static int
> +acpi_display_set_power(struct display_device *dev)
Ditto.
> +{
> + return 0;
> +}
> +#endif
> +
> struct acpi_video_device {
> unsigned long device_id;
> struct acpi_video_device_flags flags;
> @@ -162,6 +179,10 @@
> struct acpi_video_bus *video;
> struct acpi_device *dev;
> struct acpi_video_device_brightness *brightness;
> +#if defined(CONFIG_DISPLAY_DDC)
> + struct display_properties acpi_display_properties;
> + struct display_device *display;
> +#endif
> };
>
> /* bus */
> @@ -399,6 +420,27 @@
> return status;
> }
>
> +#if defined(CONFIG_DISPLAY_DDC)
> +static void*
> +acpi_display_get_EDID(struct acpi_video_device *dev)
Combine and place '*' immediately before the function name,
not immediately after "void".
> +{
> + union acpi_object *edid = NULL;
> + void *data = NULL;
> + int status;
> +
> + status = acpi_video_device_EDID(dev, , 128);
> + if (ACPI_FAILURE(status))
> + status = acpi_video_device_EDID(dev, , 256);
> +
> + if (ACPI_SUCCESS(status)) {
> + if (edid && edid->type == ACPI_TYPE_BUFFER) {
> + data = edid->buffer.pointer;
No braces for one-statement "blocks".
> + }
> + }
> + return data;
> +}
> +#endif
> +
> /* bus */
>
> static int
> diff -urN -X fbdev-2.6/Documentation/dontdiff
> linus-2.6/drivers/video/display/display-ddc.c
> fbdev-2.6/drivers/video/display/display-ddc.c
> --- linus-2.6/drivers/video/display/display-ddc.c 1969-12-31
> 19:00:00.0 -0500
> +++ fbdev-2.6/drivers/video/display/display-ddc.c 2006-12-03
> 05:27:00.0 -0500
> @@ -0,0 +1,45 @@
> +/*
> + * display-ddc.c - EDID paring code
typo: parsing
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +int probe_edid(struct display_device *dev, void *data)
> +{
> + struct fb_monspecs spec;
> + ssize_t size = 45;
Where does the magic # 45 come from?
Can you use a #define or sizeof(X) for it instead?
> +
> + dev->name = kzalloc(size, GFP_KERNEL);
> + fb_edid_to_monspecs((unsigned char *) data, );
> + strcpy(dev->name, spec.manufacturer);
> + return snprintf(dev->name, size, "%s %s %s\n", spec.manufacturer,
> spec.monitor, spec.ascii);
Try to limit source lines to < 80 columns.
> +}
> +EXPORT_SYMBOL(probe_edid);
> +
> +MODULE_DESCRIPTION("Display Hardware handling");
> +MODULE_AUTHOR("James Simmons <[EMAIL PROTECTED]>");
> +MODULE_LICENSE("GPL");
> diff -urN -X fbdev-2.6/Documentation/dontdiff
> linus-2.6/drivers/video/display/display-sysfs.c
> fbdev-2.6/drivers/video/display/display-sysfs.c
> --- linus-2.6/drivers/video/display/display-sysfs.c 1969-12-31
> 19:00:00.0 -0500
> +++ fbdev-2.6/drivers/video/display/display-sysfs.c 2006-12-04
> 07:48:34.0 -0500
> @@ -0,0 +1,164 @@
> +#include
> +#include
> +#include
> +#include
> +
> +struct display_device *display_device_register(struct display_driver *driver,
> + struct device *dev, void
> *devdata)
> +{
> + struct display_device *new_dev;
> + int ret = -ENOMEM, i;
> +
> + if (unlikely(!driver))
> + return ERR_PTR(-EINVAL);
> +
> + new_dev = kzalloc(sizeof(struct display_device), GFP_KERNEL);
> + if (likely(new_dev)) {
> + driver->probe(new_dev, devdata);
> +
> + mutex_init(_dev->lock);
> + new_dev->driver = driver;
> + new_dev->class_dev.class = _class;
> + new_dev->class_dev.dev = dev;
> + sprintf(new_dev->class_dev.class_id, "display%d", index++);
Re: More ARM binutils fuckage
On Wed, Dec 06, 2006 at 12:22:26AM +, Russell King wrote: > Enabling EABI needs a compiler which supports EABI. That's where I > get fuzzy but recent gcc 4 should be suitable. I have had it suggested > to me that EABI support in the toolchain isn't all that stable at the > moment. I use a bog-standard gcc 4.1.0 to cross-compile all my ARM kernels with, which allows me to build both old-ABI and EABI kernels. (These days I build all kernels in EABI mode with old-ABI compat.) I have not run into any code generation issues with this compiler yet. On the ARM I am running an EABI userland with glibc 2.5, and build stuff natively with vanilla binutils 2.17.50.0.5 (2.17.5.0.3 is 'too old', as it doesn't understand the two argument form of the .movsp directive which one of the gcc ICE fix patches emits), and gcc 4.1.1 with some patches from gcc bugzilla to fix an ICE or two. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
-rt tsc frequency check
I'm not sure about this code. It's checking the PM timer, and
doesn't seem to touch the TSC, then it marks the TSC unstable
based on the stability of the PM timer.
The reason that this caught my attention is that it
marks my (AFAIK stable) tsc as unstable when it first
runs.
Is there something in here that I'm missing?
---
arch/i386/kernel/tsc.c | 23 +--
1 files changed, 5 insertions(+), 18 deletions(-)
Index: linux-2.6.19/arch/i386/kernel/tsc.c
===
--- linux-2.6.19.orig/arch/i386/kernel/tsc.c
+++ linux-2.6.19/arch/i386/kernel/tsc.c
@@ -402,40 +402,30 @@ static struct dmi_system_id __initdata b
#define TSC_FREQ_CHECK_INTERVAL (10*MSEC_PER_SEC) /* 10sec in MS */
static struct timer_list verify_tsc_freq_timer;
-static unsigned long pm_multiplier;
/* XXX - Probably should add locking */
static void verify_tsc_freq(unsigned long unused)
{
static u64 last_tsc;
- static unsigned long last_jiffies, last_pm;
+ static unsigned long last_jiffies;
u64 now_tsc, interval_tsc;
- unsigned long now_jiffies, interval_jiffies, pm, pm_delta;
+ unsigned long now_jiffies, interval_jiffies ;
if (check_tsc_unstable())
return;
rdtscll(now_tsc);
now_jiffies = jiffies;
- pm = acpi_pm_read_early();
if (!last_jiffies)
goto out;
interval_jiffies = now_jiffies - last_jiffies;
- if (pm == last_pm) {
- interval_tsc = now_tsc - last_tsc;
- interval_tsc *= HZ;
- do_div(interval_tsc, cpu_khz*1000);
- } else {
- if (pm < last_pm)
- pm += ACPI_PM_OVRRUN;
- pm_delta = pm - last_pm;
- interval_tsc = (((u64) pm_delta) * pm_multiplier) >> 22;
- do_div(interval_tsc, TICK_NSEC);
- }
+ interval_tsc = now_tsc - last_tsc;
+ interval_tsc *= HZ;
+ do_div(interval_tsc, cpu_khz*1000);
if (interval_tsc < (interval_jiffies * 3 / 4)) {
printk("TSC appears to be running slowly. "
@@ -446,7 +436,6 @@ static void verify_tsc_freq(unsigned lon
out:
last_tsc = now_tsc;
last_jiffies = now_jiffies;
- last_pm = pm;
/* set us up to go off on the next interval: */
mod_timer(_tsc_freq_timer,
jiffies + msecs_to_jiffies(TSC_FREQ_CHECK_INTERVAL));
@@ -500,8 +489,6 @@ static int __init init_tsc_clocksource(v
if (!pmtmr_ioport || !clocksource_tsc.rating)
clocksource_tsc.is_continuous = 0;
- pm_multiplier = clocksource_hz2mult(PMTMR_TICKS_PER_SEC, 22);
-
init_timer(_tsc_freq_timer);
verify_tsc_freq_timer.function = verify_tsc_freq;
verify_tsc_freq_timer.expires =
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] optimize o_direct on block device - v2
On Mon, 4 Dec 2006 20:55:50 -0800
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
> This patch implements block device specific .direct_IO method instead
> of going through generic direct_io_worker for block device.
>
> direct_io_worker is fairly complex because it needs to handle O_DIRECT
> on file system, where it needs to perform block allocation, hole detection,
> extents file on write, and tons of other corner cases. The end result is
> that it takes tons of CPU time to submit an I/O.
>
> For block device, the block allocation is much simpler and a tight triple
> loop can be written to iterate each iovec and each page within the iovec
> in order to construct/prepare bio structure and then subsequently submit
> it to the block layer. This significantly speeds up O_D on block device.
>
Looks reasonable to me. A few musings:
>
> -static int
> -blkdev_get_blocks(struct inode *inode, sector_t iblock,
> - struct buffer_head *bh, int create)
> +int blk_end_aio(struct bio *bio, unsigned int bytes_done, int error)
> {
> - sector_t end_block = max_block(I_BDEV(inode));
> - unsigned long max_blocks = bh->b_size >> inode->i_blkbits;
> + struct kiocb* iocb = bio->bi_private;
> + atomic_t* bio_count = (atomic_t*) >private;
This atomic_t-in-a-void* thing is rather unpleasing.
It could be a new member of `struct kiocb', perhaps.
Please use " *" rather than "* ".
> + long res;
> +
> + if ((bio->bi_rw & 1) == READ)
bio_data_dir()
> + bio_check_pages_dirty(bio);
> + else {
> + bio_release_pages(bio);
> + bio_put(bio);
> + }
>
> - if ((iblock + max_blocks) > end_block) {
> - max_blocks = end_block - iblock;
> - if ((long)max_blocks <= 0) {
> - if (create)
> - return -EIO;/* write fully beyond EOF */
> - /*
> - * It is a read which is fully beyond EOF. We return
> - * a !buffer_mapped buffer
> - */
> - max_blocks = 0;
> - }
> + if (error)
> + iocb->ki_left = -EIO;
> +
> + if (atomic_dec_and_test(bio_count)) {
> + res = (iocb->ki_left < 0) ? iocb->ki_left : iocb->ki_nbytes;
> + aio_complete(iocb, res, 0);
> }
>
> - bh->b_bdev = I_BDEV(inode);
> - bh->b_blocknr = iblock;
> - bh->b_size = max_blocks << inode->i_blkbits;
> - if (max_blocks)
> - set_buffer_mapped(bh);
> return 0;
> }
>
> +#define VEC_SIZE 16
> +struct pvec {
> + unsigned short nr;
> + unsigned short idx;
> + struct page *page[VEC_SIZE];
> +};
Do we actually need this? afaict all it does is saves an additional
function arg in a couple of places.
I guess it doesn't hurt though.
> +
> +struct page *blk_get_page(unsigned long addr, size_t count, int rw,
> + struct pvec *pvec)
Does this need kernel-wide scope?
A nice introductory comment explaining what it does would be, err, nice.
> +{
> + int ret, nr_pages;
> + if (pvec->idx == pvec->nr) {
> + nr_pages = (addr + count + PAGE_SIZE - 1) / PAGE_SIZE -
> + addr / PAGE_SIZE;
> + nr_pages = min(nr_pages, VEC_SIZE);
> + down_read(>mm->mmap_sem);
> + ret = get_user_pages(current, current->mm, addr, nr_pages,
> + rw==READ, 0, pvec->page, NULL);
> + up_read(>mm->mmap_sem);
> + if (ret < 0)
> + return ERR_PTR(ret);
> + pvec->nr = ret;
> + pvec->idx = 0;
> + }
> + return pvec->page[pvec->idx++];
> +}
hm, if get_user_pages() returns zero, badness ensues.
It won't do that, unless perhaps we passed it a zero nr_pages in the first
place. We shouldn't do that.
Has this code been tested with zero-length writes? And with iovecs which
contain a zero-length segment?
> static ssize_t
> blkdev_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
> - loff_t offset, unsigned long nr_segs)
> + loff_t pos, unsigned long nr_segs)
> {
> - struct file *file = iocb->ki_filp;
> - struct inode *inode = file->f_mapping->host;
> + struct inode *inode = iocb->ki_filp->f_mapping->host;
> + unsigned blkbits = blksize_bits(bdev_hardsect_size(I_BDEV(inode)));
> + unsigned blocksize_mask = (1<< blkbits) - 1;
> + unsigned long seg, nvec, cur_off, cur_len;
> +
> + unsigned long addr;
> + size_t count, nbytes = iocb->ki_nbytes;
> + loff_t size;
> + struct bio * bio;
> + atomic_t *bio_count = (atomic_t *) >private;
> + struct page *page;
> + struct pvec pvec = {.nr = 0, .idx = 0, };
Please use one declaration per line (no commas). That leaves you room for
a little comment alongside each local, explaining its operation.
This function needs little
Re: [PATCH] mm: D-cache aliasing issue in cow_user_page
From: "Matt Reimer" <[EMAIL PROTECTED]> Date: Tue, 5 Dec 2006 16:57:12 -0800 > Right, but isn't he declaring that each architecture needs to take > care of this? So, say, on ARM we'd need to make kunmap() not a NOP and > call flush_dcache_page() ? No. He is only solving a problem that occurs on HIGHMEM configurations on systems which can have D-cache aliasing issues. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: D-cache aliasing issue in cow_user_page
On 12/5/06, David Miller <[EMAIL PROTECTED]> wrote: From: "Matt Reimer" <[EMAIL PROTECTED]> Date: Mon, 4 Dec 2006 23:38:13 -0800 > In light of James Bottomsley's commit[1] declaring that kmap() and > friends now have to take care of coherency issues, is the patch "mm: > D-cache aliasing issue in cow_user_page"[2] correct, or could it > potentially cause a slowdown by calling flush_dcache_page() a second > time (i.e. once in an architecture-specific kmap() implementation, and > once in cow_user_page())? kmap() is a NOP unless HIGHMEM is configured. Therefore, it cannot possibly take care of D-cache aliasing issues across the board. Right, but isn't he declaring that each architecture needs to take care of this? So, say, on ARM we'd need to make kunmap() not a NOP and call flush_dcache_page() ? Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] let WARN_ON() output the condition
[PATCH] let WARN_ON() output the condition
It is possible, in some cases, that the output of WARN_ON() is ambiguous
and can't be properly used to identify the exact condition which caused
the warning to trigger. This happens whenever there is a macro that
contains multiple WARN_ONs inside. Notable example is spin_lock_mutex().
If any of the two WARN_ONs trigger, we are not able to say which one was
the cause (as we get only line number, which however belongs to the place
where the macro was expanded).
This patch lets WARN_ON() to output also the condition and fixes the
DEBUG_LOCKS_WARN_ON() macro to pass the condition properly to WARN_ON. The
possible drawback could be when someone passes a condition which has
sideeffects. Then it would be evaluated twice, instead of current one
evaluation. On the other hand, when anyone passes expression with
sideeffects to WARN_ON(), he is asking for problems anyway.
Patch against 2.6.19-rc6-mm2.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
---
include/asm-generic/bug.h |4 ++--
include/linux/debug_locks.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index a06eecd..af7574e 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -35,8 +35,8 @@ #ifndef HAVE_ARCH_WARN_ON
#define WARN_ON(condition) ({ \
typeof(condition) __ret_warn_on = (condition); \
if (unlikely(__ret_warn_on)) { \
- printk("WARNING at %s:%d %s()\n", __FILE__, \
- __LINE__, __FUNCTION__);\
+ printk("WARNING (%s) at %s:%d %s()\n", #condition, \
+ __FILE__,__LINE__, __FUNCTION__); \
dump_stack(); \
} \
unlikely(__ret_warn_on);\
diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
index 952bee7..1c2b682 100644
--- a/include/linux/debug_locks.h
+++ b/include/linux/debug_locks.h
@@ -25,7 +25,7 @@ ({
\
\
if (unlikely(c)) { \
if (debug_locks_off()) \
- WARN_ON(1); \
+ WARN_ON(c); \
__ret = 1; \
} \
__ret; \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SAK and screen readers
On December 05 at 18:50 EST, Samuel Thibault hastily scribbled: > The problem comes when using SAK: brltty gets killed because it owns an > fd on /dev/tty0. This is a problem since the blind user then just can't > use her computer any more... > > Could there be a solution for brltty yet not being killed by SAK? (like > letting brltty just nicely close his fd for the current VT, and then > re-open it later) How about this? brltty launches a child process that opens the VT and pipes data back and forth to the parent process via pipes or fifos. When the SAK is pressed, the child process will die, and the parent process will simply relaunch it. It seems like any solution that involves the kernel not killing brltty will compromise the (admittedly rudimentary) security that the SAK offers. Hope this helps, Thomas Tuttle pgpqKt5QkLY0v.pgp Description: PGP signature
Re: More ARM binutils fuckage
On Tue, Dec 05, 2006 at 07:33:57PM +, Russell King wrote: > There's not much to say about this, other than scream and go hide in the > corner. ARM toolchains are just basically fscked. > > arm-linux-ld -EL -p --no-undefined -X -o .tmp_vmlinux1 -T > arch/arm/kernel/vmlinux.lds arch/arm/kernel/head.o > arch/arm/kernel/init_task.o init/built-in.o --start-group > usr/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o > arch/arm/common/built-in.o arch/arm/mach-versatile/built-in.o > arch/arm/nwfpe/built-in.o arch/arm/vfp/built-in.o kernel/built-in.o > mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o > crypto/built-in.o block/built-in.o arch/arm/lib/lib.a lib/lib.a > arch/arm/lib/built-in.o lib/built-in.o drivers/built-in.o > sound/built-in.o net/built-in.o --end-group > > Produces no error, but: > > $ arm-linux-nm ../build/versatile/.tmp_vmlinux1 |grep ' U ' > U __divdi3 > U __udivdi3 > U __umoddi3 > > Duh. I'm lead to believe that these are due to gcc issuing .globl directives for these symbols, but not actually referencing them. Hence the symbol is marked undefined in the symbol table, but no reloations actually exist. Hence why the linker (correctly) doesn't fail. Ergo, no problem. Please ignore the previous mail. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][Trivial] scsi: Fix 'unused variable' warning in scsi.c
From: John Daiker <[EMAIL PROTECTED]>
This patch applies cleanly to 2.6.19-git7
Fixes the following warning:
CC drivers/scsi/scsi.o
drivers/scsi/scsi.c: In function ‘scsi_device_put’:
drivers/scsi/scsi.c:874: warning: unused variable ‘module’
Signed-off-by: John Daiker <[EMAIL PROTECTED]>
---
drivers/scsi/scsi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index c59f315..780d6dc 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -871,9 +871,9 @@ EXPORT_SYMBOL(scsi_device_get);
*/
void scsi_device_put(struct scsi_device *sdev)
{
+#ifdef CONFIG_MODULE_UNLOAD
struct module *module = sdev->host->hostt->module;
-#ifdef CONFIG_MODULE_UNLOAD
/* The module refcount will be zero if scsi_device_get()
* was called from a module removal routine */
if (module && module_refcount(module) != 0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: More ARM binutils fuckage
On Tue, Dec 05, 2006 at 03:29:22PM -0800, Michael K. Edwards wrote: > On 12/5/06, Russell King <[EMAIL PROTECTED]> wrote: > >There's not much to say about this, other than scream and go hide in the > >corner. ARM toolchains are just basically fscked. > > And while we're on the topic of ARM linux toolchain fsckage, it would > be nice to know what patches and incantations are currently > recommended when configuring gcc for building various modern ARM > kernel/ABI configurations (OABI + soft VFP, EABI, etc.). There is no such thing as soft VFP. I can only talk from the requirements of the kernel. gcc 3.4.3 is the minimum for ARM, which with binutils 2.17 will allow you to build the kernel as OABI in *any* configuration. No patches required for either. Enabling EABI needs a compiler which supports EABI. That's where I get fuzzy but recent gcc 4 should be suitable. I have had it suggested to me that EABI support in the toolchain isn't all that stable at the moment. As for userspace... and NPTL, that's a different matter. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] timers, pointers to functions and type safety
On Mon, Dec 04, 2006 at 12:22:44PM +, David Howells wrote: > Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > the question is: which is more important, the type safety of a > > container_of() [or type cast], which if we get it wrong produces a > > /very/ trivial crash that is trivial to fix The hell it is. You get wrong fields of a big struct read and modified. Silently. Besides, I can show you fsckloads of cases when we do *NOT* pass a pointer to struct the timer is embedded into. Some of them called directly (and no, the thing they get as argument doesn't point to anything that would contain a timer_list). > > structure size all around the kernel? I believe the latter is more > > important. > > Indeed yes. Guys, please, look at actual users of that stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cd: Handle strange interrupt on the Intel ESB2
Alan wrote: > On Wed, 6 Dec 2006 00:23:03 +0100 > "Bartlomiej Zolnierkiewicz" <[EMAIL PROTECTED]> wrote: > >> Looks good but aren't this trying to fix the same ICH >> issue that is fixed in libata by ap->ops->irq_clear(ap)? >> >> [ please see Tejun's mail: http://lkml.org/lkml/2006/11/15/94 ] >> >> If so shouldn't we apply this fix for all ICH5/6/7/8 chipsets? > > Possibly. Thats one reason I made it a quirk bit. I'd certainly expect it > to be a group of related chipsets. > >> Also shouldn't the fix be in IRQ handler? Currently the fix is limited >> to ide-cd driver which seems to be the wrong place as the problem >> is supposed to happen also when using other IDE device drivers >> or/and other ATA/ATAPI devices? > > The problem has only be observed with CD devices doing PIO ATAPI > commands. I am not aware of an Intel errata document that characterises > this errata so anything else so cannot guess further. Perhaps Intel can > advise ? FWIW, on my ICH7, the IRQ storm does occur on ATA devices. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
On Wed, 6 Dec 2006 00:55:29 +0100 Alessandro Guido <[EMAIL PROTECTED]> wrote: > Sorry, I didn't find in your list the patches regarding the sony_acpi > driver that were present in 2.6.19-rc6-mm2. I'm talking about: > > 2.6-sony_acpi4.patch > sony_apci-resume.patch > acpi-add-backlight-support-to-the-sony_acpi.patch > acpi-add-backlight-support-to-the-sony_acpi-v2.patch > > What is the future of these? > I spose I need to talk Len into merging the sony-acpi driver. Before that I need to work out why /sys/class/backlight/sony/brightness magically vanished on me after a suspend-to-ram operation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 14:19 +, David Howells wrote:
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > Here is a patch to reverse that. Kasper, can you test it?
> > (Your filesystem is on a FAT/VFAT volume, I assume.)
I do have a fat32 filesystem mounted using the vfat driver (the msdos
one arent compiled in), however the chroot in no way has access to this,
and i dont see how ANY 32bit apps can have attempted to access it, ill
go so far as say im certain they havent.
>
> Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
okay, i will not.
>
> Can you compile and run the attached program as both 32-bit and 64-bit?
Yes, i will conduct tests, however it will have to wait till atleast
tomorow (cant garantuee anything though, i have lots of work to do).
>
> On my x86_64 test box, I did:
>
> [EMAIL PROTECTED] ~]# mkfs.vfat /dev/sda5
> [EMAIL PROTECTED] ~]# mount /dev/sda5 /mnt
> [EMAIL PROTECTED] ~]# mkdir /mnt/a
> [EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 32-bit
> 268 : 82187201, 82187202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> Calling VFAT_IOCTL_READDIR_BOTH
> [EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 64-bit
> 280 : 82307201, 82307202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> ioctl: Inappropriate ioctl for device
> Calling VFAT_IOCTL_READDIR_BOTH
>
> Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
> function). Tracing the 64-bit version shows that the right numbers are being
> given to the syscall, though strace decodes them as the same symbol if not in
> raw mode:
>
> [EMAIL PROTECTED] ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
> 280 : 82307201, 82307202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> ioctl(0x3, 0x82187201, 0x7fff9cec36c0) = -1 (errno 25)
> ioctl: Inappropriate ioctl for device
> Calling VFAT_IOCTL_READDIR_BOTH
> ioctl(0x3, 0x82307201, 0x7fff9cec3490) = 0x1
> Process 3410 detached
>
> Applying the attached patch to the kernel produces the following elements in
> the log for the 32-bit compilation:
>
> ==> fat_compat_dir_ioctl(82187201,ffa803b8)
> ==> fat_dir_ioctl(82307201,810036a97ca8)
> <== fat_dir_ioctl() = 1
> <== fat_compat_dir_ioctl() = 1
> ==> fat_compat_dir_ioctl(82187201,ffa801a0)
> ==> fat_dir_ioctl(82307201,810036a97ca8)
> <== fat_dir_ioctl() = 1
> <== fat_compat_dir_ioctl() = 1
>
> and this for the 64-bit compilation:
>
> ==> fat_dir_ioctl(82187201,7fff031f69f0)
> call fat_generic_ioctl()
> <== fat_dir_ioctl() = -25
> ==> fat_dir_ioctl(82307201,7fff031f67c0)
> <== fat_dir_ioctl() = 1
>
> Which is entirely what I'd expect.
>
> However, it's possible that the 64-bit kernel interface used to allow the
> 32-bit calls. If that's the case could you be running a 64-bit program
> somewhere in your 32-bit chroot?
I am basically positive that i am not running 64bit stuff within my
32bit chroot, however i will check to make absolutely sure.
>
> | i have only tested with >=rc5, thw folling, as an example, appears in
> | dmesg:
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
>
> How do you get that? I don't see anything like that. I've tried:
all i did was run wine's regedit inside my 32bit chroot.
>
> echo 1 >/proc/sys/kernel/compat-log
>
> But that doesn't seem to do anything.
>
> David
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
On Tuesday 05 December 2006 2:01 am, Marco d'Itri wrote:
> On Dec 05, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > The pushback on $SUBJECT patch. Which amounts to wanting to break hotplug
> > for several busses, unless someone (NOT the folk promoting the breakage!)
>
> Please explain in more details how hotplugging would be broken, possibly
> with examples.
First, for reference, I refer to hotplugging using the trivial ASH scripts
from [1], updated by removing no-longer-needed special cases for platform_bus
(that original logic didn't work sometimes) and pcmcia. See the (short)
contemporary thread [2] discussing platform_bus support, and some of issues
related to why its hotplug support works the way it does now. (Looks like
some messages are not archived, but the key points are there.)
Those scripts have supported hotplug and coldplug on several embedded boards
for some time now. The ancient "runs on 2.4" scripts would have been way
too slow to justify using hotplug and udev to replace devfs, and also needed
all sorts of extra crap that's regularly not found with embedded Linuxes.
Plus of course they never understood platform_bus, which is the main way
those PCI-less systems are hooked together.
Second, note that you're asking me to construct a straw man for you and
then break it down, since nobody arguing with the $SUBJECT patch has ever
provided a complete counter-proposal (much less respond to the points
I've made about legacy driver bugginess -- which is suggestive).
That said, the common thread in that pushback is that $MODALIAS (and also
modalias files) "should" have some value other than platform_device.name ...
which name is conventionaly also the name of the driver's module. That goes
along with a (weak) rationale that requires spi_bus and KMOD to change, plus
(presumably, pending a code audit) other kernel subsystems.
That should make it clear how accepting that pushback would break hotplug:
"modprobe $MODALIAS" would no longer load the right module. Likewise
the more significant case of coldplug; "modprobe $(cat modalias)" would
likewise no longer work.
> > There are really two issues here:
> >
> > - The "real one", as (yes!) fixed by the $SUBJECT patch. Troublesome
> > legacy
> >drivers, like "i82365", written so they can't hotplug ... but the kernel
> >hasn't previously known that.
> >
> > - The confusion, caused by a false identification of the "i82365" issue
> >being a problem related to module aliasing ... instead of being rooted in
> >the fact that it's a "legacy style" non-hotpluggable driver, since it
> >creates its own device node.
>
> Nonsense. The purpose of $MODALIAS is to allow automatically loading
> modules using the information provided by the bus driver.
Without using sysfs. And that's exactly what it does _today_ for the
platform_bus.
Modulo the real issue, which is that legacy/ISA style drivers like i82365 will
never support hotplugging ("automatically loading modules ..." plus consequent
device configuration), without first being split into separate bus support
(making the device nodes) and driver module (the thing $MODALIAS supports).
Hotplug depends on that split in a fundamental manner.
So ... on what point were you disagreeing with me??
> Because of this reason there is no point for a driver to provide a
> $MODALIAS referring to itself. It will only waste resources causing udev
> to try loading it again.
The $SUBJECT patch makes those legacy drivers NOT use the $MODALIAS
mechanism ... you seem to be overlooking that.
And "udev" was from day one supposed to solve a different problem
than "loading modules". There was to be a clear and strong separation
of roles between hotplug (load modules, don't rely on sysfs, use other
components for the rest of device setup) and udev (make /dev nodes,
ok to rely on sysfs). That is, "udev" wouldn't do any loading.
- Dave
[1] http://marc.theaimsgroup.com/?l=linux-hotplug-devel=111903647518255=2
[2] http://marc.theaimsgroup.com/?t=11189588981=1=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 3:50 PM >If you will not reps is negative. Roughly it is a loop >that will timeout eventually if a usb debug cable is not present. >Putting some deliberate delays in there so I could be certain >of timing out after a second or two would probably be better, but >I don't have anything that resembles a good timer at that point. You have dbgp_mdelay in your code. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Sorry, I didn't find in your list the patches regarding the sony_acpi driver that were present in 2.6.19-rc6-mm2. I'm talking about: 2.6-sony_acpi4.patch sony_apci-resume.patch acpi-add-backlight-support-to-the-sony_acpi.patch acpi-add-backlight-support-to-the-sony_acpi-v2.patch What is the future of these? Thanks. Alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, December 05, 2006 3:01 AM
>
>>+static int ehci_wait_for_port(int port)
>>+{
>>+ unsigned status;
>>+ int ret, reps;
>>+ for (reps = 0; reps >= 0; reps++) {
>>+ status = readl(_regs->status);
>>+ if (status & STS_PCD) {
>>+ ret = ehci_reset_port(port);
>>+ if (ret == 0)
>>+ return 0;
>>+ }
>>+ }
>>+ return -ENOTCONN;
>>+}
>>+
>
> What do you mean by
> + for (reps = 0; reps >= 0; reps++) {
> ?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
Putting some deliberate delays in there so I could be certain
of timing out after a second or two would probably be better, but
I don't have anything that resembles a good timer at that point.
The problem is you have to wait until the ehci notices your usb
debug cable before you reset it and get it going and that can be a
non-trivial amount of time. So the loop is 100% necessary.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Export current_is_keventd() for libphy
> Ah. The point is that the phy code doesn't want to flush _all_ pending > callbacks. It only wants to flush its own one. And its own one doesn't > take rtnl_lock(). OK, got it. You're absolutely correct. > Maybe the lesson here is that flush_scheduled_work() is a bad function. > It should really be flush_this_work(struct work_struct *w). That is in > fact what approximately 100% of the flush_scheduled_work() callers actually > want to do. I think flush_this_work() runs into trouble if it means "make sure everything up to has completed" because it still syncs with everything before , which has the same risk of deadlock. And I'm not totally sure everyone who does flush_scheduled_work() really means "cancel my work" -- they might mean "finish up my work". For example I would have to do some archeology to remember exactly what I needed flush_scheduled_work() when I wrote drivers/infiniband/ulp/ipoib - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cd: Handle strange interrupt on the Intel ESB2
On Wed, 6 Dec 2006 00:23:03 +0100 "Bartlomiej Zolnierkiewicz" <[EMAIL PROTECTED]> wrote: > Looks good but aren't this trying to fix the same ICH > issue that is fixed in libata by ap->ops->irq_clear(ap)? > > [ please see Tejun's mail: http://lkml.org/lkml/2006/11/15/94 ] > > If so shouldn't we apply this fix for all ICH5/6/7/8 chipsets? Possibly. Thats one reason I made it a quirk bit. I'd certainly expect it to be a group of related chipsets. > Also shouldn't the fix be in IRQ handler? Currently the fix is limited > to ide-cd driver which seems to be the wrong place as the problem > is supposed to happen also when using other IDE device drivers > or/and other ATA/ATAPI devices? The problem has only be observed with CD devices doing PIO ATAPI commands. I am not aware of an Intel errata document that characterises this errata so anything else so cannot guess further. Perhaps Intel can advise ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SAK and screen readers
Hi, BrlTTY is a screen reader: it is a deamon run as root on machines used by blind users for getting the content of the screen via braille or speech. BrlTTY, like other screen readers (susebl, yasr, ...) needs to open /dev/tty0 for performing various actions, namely: - VT_ACTIVATE - GIO_UNISCRNMAP - GIO_UNIMAP - KDFONTOP - VT_GETHIFONTMASK - VT_GETSTATE - KDGETMODE - TIOCSTI - KDGKBMETA - KDGKBMODE The problem comes when using SAK: brltty gets killed because it owns an fd on /dev/tty0. This is a problem since the blind user then just can't use her computer any more... Some of the actions above are not directly related to the current VT, so these could use a generic VT handle ; but at least KD* and TIOCSTI need to be directed to the current VT, so brltty really needs to have an fd on the current VT tty. Could there be a solution for brltty yet not being killed by SAK? (like letting brltty just nicely close his fd for the current VT, and then re-open it later) Samuel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Export current_is_keventd() for libphy
> But running flush_scheduled_work() from within dev_close() is a very > sensible thing to do, and dev_close is called under rtnl_lock(). I can't argue with that -- this has actually bitten me in the past. Hmm, I'll try to understand why we need rtnl_lock() to cover dev_close... - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there way to reserve more MMIO resource for PCIE-hotplug-capable slot?
Zhao Forrest wrote: Hi, Sometimes we could hotplug a PCIE device, which require more MMIO resource than that reserved by BIOS. My question is: is there a way for kernel to reserved more MMIO resource for a PCIE-hotplug-capable slot? I searched the kernel-parameters.txt, but didn't find any related information. If you need 32-bit MMIO, no, because it requires chipset-specific reprogramming. 64-bit MMIO should be readily available. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xtables/iptables and atkbd.c Spurious ACK on isa0060/serio0
Hi. I have posted this on a few forums,and some people suggested that I post it here to see if I could get any help. I recently complied a 2.6.19 kernel. I realized that I needed to compile in support for iptables,so I put in xtables and iptables. However,when I booted up the kernel,I got the repeating message "atkbd.c Spurious ACK on isa0060/serio0" and the system hung. This can be fixed if I take out xtables support. I was wondering if anyone knew why xtables was causing this,I don't want to go online without having iptables. Thanks for your help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] New firewire stack
Marcel Holtmann wrote: Hi Erik, can you please use drivers/firewire/ if you want to start clean or aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in the directory path is not really helpful. Yes, that's probably a better idea. Do you see a problem with using fw_* as a prefix in the code though? I don't see anybody using that prefix, but Stefan pointed out to me that it's often used to abbreviate firmware too. So what about fiwi_*? If that's too close to wifi_*, try frwr_. please don't. These kind of abbreviations make my brain tilt. For the directory name you basically should use the full name. In this case it will be drivers/ieee1394/ or drivers/firewire/. Nothing else is really acceptable and if you look at other subsystems, you will see that they always use the long name. For the exported public functions you might wanna use abbreviations, but in general I don't recommend it. And normally we only talk about a limited functions that are needed to be exposed via EXPORT_SYMBOL. I think I'll stick with my fw_* prefix for now, it's nice and short and not too cryptic. I'm only exporting a small set of functions anyway, and they're all only used inside the firewire stack. Kristian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] New firewire stack
Ray Lee wrote: On 12/4/06, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: Ok... I was planning to make big-endian versions of the structs so that the endian issue would be solved. But if the bit layout is not consistent, I guess bitfields are useless for wire formats. I didn't know that though, I thought the C standard specified that the compiler should allocate bits out of a word using the lower bits first. The C standard explicitly allows it to be implementation defined. Having been bit by this exact problem, I can also recommend never using bitfields for anything other than things kept solely in local memory. Yeah, I just read that paragraph in K sigh. Bitfields make the code so readable, though :) Anyway, I'll rewrite it to use good old shifting and masking. Kristian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More ARM binutils fuckage
On 12/5/06, Russell King <[EMAIL PROTECTED]> wrote: There's not much to say about this, other than scream and go hide in the corner. ARM toolchains are just basically fscked. And while we're on the topic of ARM linux toolchain fsckage, it would be nice to know what patches and incantations are currently recommended when configuring gcc for building various modern ARM kernel/ABI configurations (OABI + soft VFP, EABI, etc.). There has been some discussion on the crossgcc mailing list, especially around recent compilers and NPTL/TLS, and crosstool has accumulated some of the relevant patches. If an expert (i. e., someone who has built their own toolchain and gotten an ARM EABI/NPTL system all the way up) were to reply to this message with some details, we might be able to coax chip vendors off of hard-float gcc-3.3/glibc-2.3.x/linuxthreads toolchains. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
On Tue, 5 Dec 2006, Mel Gorman wrote: > There are times you want to reclaim just part of a zone - specifically > satisfying a high-order allocations. See sitations 1 and 2 from elsewhere > in this thread. On a similar vein, there will be times when you want to > migrate a PFN range for similar reasons. This is confusing reclaim with defragmentation. I think we are in conceptually unclean territory because we mix the two. If you must use reclaim to get a portion of contiguous memory free then yes we have this problem. If you can migrate pages then no there is no need for reclaiming a part of a zone. You can occasionally shuffle pages around to get a large continous chunk. If there is not enough memory then an independent reclaim subsystem can take care of freeing a sufficient amount of memory. Marrying the two seems to be getting a bit complex and maybe very difficult to get right. The classification of the memory allocations is useful to find a potential starting point to reduce the minimum number of pages to move to open up that hole. > > Why would one want to allocate from the 1/4th of a zone? (Are we still > > discussing Mel's antifrag scheme or what is this about?) > Because you wanted contiguous blocks of pages. This is related to anti-frag > because with anti-frag, reclaiming memory or migration memory will free up > contiguous blocks. Without it, you're probably wasting your time. I am still not sure how this should work. Reclaim in a portion of the reclaimable/movable portion of the zone? Or pick a huge page and simply reclaim all the pages in that range? This is required for anti-frag regardless of additonal zones right? BTW If one would successfully do this partial reclaim thing then we also have no need anymore DMA zones because we can free up memory in the DMA area of a zone at will if we run short on memory there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM
>+static int ehci_wait_for_port(int port)
>+{
>+ unsigned status;
>+ int ret, reps;
>+ for (reps = 0; reps >= 0; reps++) {
>+ status = readl(_regs->status);
>+ if (status & STS_PCD) {
>+ ret = ehci_reset_port(port);
>+ if (ret == 0)
>+ return 0;
>+ }
>+ }
>+ return -ENOTCONN;
>+}
>+
What do you mean by
+ for (reps = 0; reps >= 0; reps++) {
?
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] New firewire stack
On Tue, Dec 05, Kristian Høgsberg wrote: > I'm announcing an alternative firewire stack that I've been working on I suggest you hash out the most obvious bugs in -mm. Once it you have it in a reasonable shape, replace the drivers in drivers/ieee1394 in one go. Its just not worth the pain to switch from module a.ko to module b.ko, keep the name a.ko because its the very same functionality after all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] New firewire stack
Alexey Dobriyan wrote: On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote: I'm announcing an alternative firewire stack that I've been working on the last few weeks. Is mainline firewire so hopeless, that you've decided to rewrite it? Could you show some ugly places in it? Yes. I'm not doing this lightheartedly. It's a lot of work and it will introduce regressions and instability for a little while. My main point about ohci1394 (the old stacks PCI driver) is, that if you really want to fix the issues with this driver, you have to shuffle the code around so much that you'll introduce as many regressions as a clean rewrite. The big problems in the ohci1394 drivers is the irq_handler, bus reset handling and config rom handling. These are some of the strong points of fw-ohci.c: - Rock solid handling of generations and node IDs around bus resets. The only way to handle this atomically is to pass the generation count along all the way to the transmit function in the low-level driver. The linux1394 low level driver API is broken in this respect. - Better handling of self ID receive and possible recursive bus resets. Successive bus resets could overwrite the self ID DMA buffer, while we read out the contents. The OHCI specification recommends a method similiar to linux/seqlock.h for reading out self IDs, to ensure we get a consistent result. - Much simpler bus reset handling; we only subscribe to the selfIDComplete interrupt and don't use the troublesome busReset interrupt. Rely on async transmit context to not send data while busReset event bit is set. - Atomic updates of config rom contents as specified in section 5.5.6 in the OHCI specification. The contents of the ConfigROMheader, BusOptions and ConfigROMmap registers are updated atomically by the controller after a reset. The OHCI specification describes a number of the techniques to ensure race free operation for the above cases, but the ohci1394 driver generally doesn't use any of these. If you want to see ugly code look at the ohci1394 irq handler. Much of the uglyness comes from trying to handle the busReset interrupt, so that the mid-level linux1394 stack can fail I/O while the bus reset takes place. Now, OHCI hardware already reliably fails I/O during bus reset, so there is no need to complicate the core stack with this extra state, and the OHCI driver becomes much simpler and more reliable, since we now just need to know when a bus reset has successfully completed. Fixing this problem requires significant changes to the ohci1394 driver and the mid-level stack, and will destabilize things until we've figure out how to work around the odd flaky device out there. Similar problems exists related to sending packets without bus reset races, updating the config rom, and reporting self ID packets and all require significant changes to the core stack and ohci1394. All taken together the scale tips towards a rewrite. Another point is the various streaming drivers. There used to be 5 different userspace streaming APIs in the linux1394: raw1394, video1394, amdtp, dv1394 and rawiso. Recently, amdtp (audio streaming) has been removed, since with the rawiso interface, this can be done in userspace. However the remaining 4 interfaces have slightly disjoint feature sets and can't really be phased out. In the long run, supporting 4 different interfaces that does almost the same thing isn't feasible. The streaming interface in my new stack (only transmission implemented at this point) can replace all of these interfaces. Finally, some parts aren't actually rewritten, just ported over and refactored. This is the case for the SBP-2 driver. Functionally, my fw-sbp2.c is identical to sbp2.c in the current stack, but I've changed it to work with the new interfaces and cleaned up some of the redundancy. We can end up with two not quite working sets of firewire drivers your way. You can patch up the current stack to be less flaky, and Stefan has been doing a great job at that lately, but it's still fundamentally broken in the ways described above. While my stack may less stable for the first couple of weeks, these are transient issues, such as, say, lack of big endian testing, that are easily fixed. In the long run this new stack is much more maintainable and has a bigger potential for stability. Kristian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cd: Handle strange interrupt on the Intel ESB2
[ added Jeff and Tejun to cc: ]
On 12/4/06, Alan <[EMAIL PROTECTED]> wrote:
The ESB2 appears to emit spurious DMA interrupts when configured for
native mode and handling ATAPI devices. Stratus were able to pin this bug
down and produce a patch. This is a rework which applies the fixup only
to the ESB2 (for now). We can apply it to other chips later if the same
problem is found.
Looks good but aren't this trying to fix the same ICH
issue that is fixed in libata by ap->ops->irq_clear(ap)?
[ please see Tejun's mail: http://lkml.org/lkml/2006/11/15/94 ]
If so shouldn't we apply this fix for all ICH5/6/7/8 chipsets?
This code has been tested and confirmed to fix the problem on the tested
systems.
Also shouldn't the fix be in IRQ handler? Currently the fix is limited
to ide-cd driver which seems to be the wrong place as the problem
is supposed to happen also when using other IDE device drivers
or/and other ATA/ATAPI devices?
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
(Most of the hard work done by Stratus however)
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.19-rc6-mm1/drivers/ide/ide-cd.c
linux-2.6.19-rc6-mm1/drivers/ide/ide-cd.c
--- linux.vanilla-2.6.19-rc6-mm1/drivers/ide/ide-cd.c 2006-11-24
13:58:06.0 +
+++ linux-2.6.19-rc6-mm1/drivers/ide/ide-cd.c 2006-12-01 19:24:58.0
+
@@ -687,8 +687,15 @@
static int cdrom_decode_status(ide_drive_t *drive, int good_stat, int
*stat_ret)
{
struct request *rq = HWGROUP(drive)->rq;
+ ide_hwif_t *hwif = HWIF(drive);
int stat, err, sense_key;
+ /* We may have bogus DMA interrupts in PIO state here */
+ if (HWIF(drive)->dma_status && hwif->atapi_irq_bogon) {
+ stat = hwif->INB(hwif->dma_status);
+ /* Should we force the bit as well ? */
+ hwif->OUTB(stat, hwif->dma_status);
+ }
/* Check for errors. */
stat = HWIF(drive)->INB(IDE_STATUS_REG);
if (stat_ret)
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.19-rc6-mm1/drivers/ide/pci/piix.c
linux-2.6.19-rc6-mm1/drivers/ide/pci/piix.c
--- linux.vanilla-2.6.19-rc6-mm1/drivers/ide/pci/piix.c 2006-11-24
13:58:29.0 +
+++ linux-2.6.19-rc6-mm1/drivers/ide/pci/piix.c 2006-12-01 19:20:46.0
+
@@ -473,6 +473,10 @@
/* This is a painful system best to let it self tune for now */
return;
}
+ /* ESB2 appears to generate spurious DMA interrupts in PIO mode
+ when in native mode */
+ if (hwif->pci_dev->device == PCI_DEVICE_ID_INTEL_ESB2_18)
+ hwif->atapi_irq_bogon = 1;
hwif->autodma = 0;
hwif->tuneproc = _tune_drive;
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.19-rc6-mm1/include/linux/ide.h
linux-2.6.19-rc6-mm1/include/linux/ide.h
--- linux.vanilla-2.6.19-rc6-mm1/include/linux/ide.h2006-11-24
13:58:12.0 +
+++ linux-2.6.19-rc6-mm1/include/linux/ide.h2006-12-01 19:16:27.0
+
@@ -796,6 +796,7 @@
unsignedsg_mapped : 1; /* sg_table and sg_nents are ready */
unsignedno_io_32bit : 1; /* 1 = can not do 32-bit IO ops */
unsignederr_stops_fifo : 1; /* 1=data FIFO is cleared by an
error */
+ unsignedatapi_irq_bogon : 1; /* Generates spurious DMA
interrupts in PIO mode */
struct device gendev;
struct completion gendev_rel_comp; /* To deal with device release() */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] New firewire stack
Benjamin Herrenschmidt wrote: (bitfields as accessors to on-the-wire data) ... > relies on the fact that it -seems- that by luck, gcc only has two > representations around and they match little/big endian archs (though > have we verified that is always correct, especially between 32 and 64 > bits archs ?) As you perhaps noticed, this is already used on very basic packets (the selfIDs which are the first ones generated by PHYs after each bus reset). Therefore I suppose that it works also on 64bit architectures even though they are certainly less extensively tested than 32bit ones. But since there are no guarantees for it to work as intended,... > It's still wrong to do. ...I added it to my list of things to fix. Thanks, -- Stefan Richter -=-=-==- ==-- --==- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage
On Tue, Dec 05, 2006 at 02:49:13PM -0800, Andrew Morton wrote: > On Tue, 5 Dec 2006 17:38:07 -0500 > Josef Sipek <[EMAIL PROTECTED]> wrote: > > > > When your patches are queued in -mm please do test them there, and review > > > others' changes to them, and raise patches against them. Raising patches > > > against one's private tree and not testing the code which is planned to be > > > merged can introduce errors. > > > > Sorry about that. I noticed your fix, and the one by Adrian. And I did add > > them to my fsstack queue. > > you don't have an fsstack queue any more ;) Good point :) > Please, I really do want developers to test their code in -mm once I've > merged it. What happens if there's some nasty interaction between your > patch and someone else's? We'll not find out about it and it'll get > merged. Point taken. Josef "Jeff" Sipek. -- I already backed up the box once, I can do it again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
On Tue, 05 Dec 2006 14:56:41 -0800 Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Matthew Wilcox wrote: > > There's no point in troubling the Alpha, IA-64, PowerPC and PARISC > > people with SiS and VIA options. Andrew thinks it helps find bugs, > > but there's no evidence of that. > > > > Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> > > > > diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig > > index c603bf2..a9f9c48 100644 > > --- a/drivers/char/agp/Kconfig > > +++ b/drivers/char/agp/Kconfig > > @@ -86,7 +86,7 @@ config AGP_NVIDIA > > > > config AGP_SIS > > tristate "SiS chipset support" > > - depends on AGP > > + depends on AGP && X86 > > help > > This option gives you AGP support for the GLX component of > > X on Silicon Integrated Systems [SiS] chipsets. > > @@ -103,7 +103,7 @@ config AGP_SWORKS > > > > config AGP_VIA > > tristate "VIA chipset support" > > - depends on AGP > > + depends on AGP && X86 > > help > > This option gives you AGP support for the GLX component of > > X on VIA MVP3/Apollo Pro chipsets. > > I don't know about SiS, but this is certainly *not* true for Via. There > are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. > My config-fu isn't quite what it should be, so this may be a dumb > question. Does the "& X86" requirement exclude x86-64? No, X86 includes both X86_32 and X86_64. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
David Brownell <[EMAIL PROTECTED]> writes: > On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote: >> >> My driver should be sufficient to work with any EHCI in a realatively >> clean state, and needs no special BIOS support just the hardware. >> This appears to be different than the way the windows drivers are >> using these debug devices. > > I'm glad to see someone finally got progress on this ... :) > > Separately, I forwarded some stuff I did last year ... maybe it'll help. > You seem to have gotten further. Have you also observed that the > NetChip device seems to have polarity issues, such that only one > end behaves properly? I haven't yet. But I don't think I have actually tried turning the cable around in a very meaningful way yet either. Possibly this is something that has been fixed. I know there are some odd issues that I have encountered. Like occasionally I would need to stop the software on one side, or I would need to unplug it when things got sufficiently confused. > Note that this should **NOT** be specific to x86_64, since pretty > much any PCI based EHCI can do this. I wouldn't be able to use > this on my NForce2 box, for example ... So I took a quick look what it would take to do this truly generically and even initializing this generally when console code typically is registered looks like a problem. Although only because we don't get around to setting up pci_config space access helpers in a timely manner. To some extent that still sucks because you are still being initialized before the general ehci-hcd code. Regardless an arch specific i386 variant was easy to throw together. It still needs a bit of work but it basically worked. > As for EHCI registers, if this really _needs_ to live outside > of drivers/usb/host, then I'd suggest for > the relevant declarations ... the headers are > provided exactly for sharing such declaration between otherwise > unrelated parts of the tree. Yep that sounds like the right thing to do. I think I at least need to be called from something outside of drivers/usb and may need the code there. Doing this in a truly generic fashion looks like a major pain. Because all of the infrastructure needs to be fixed. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VIA and SiS AGP chipsets are x86-only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Wilcox wrote: > There's no point in troubling the Alpha, IA-64, PowerPC and PARISC > people with SiS and VIA options. Andrew thinks it helps find bugs, > but there's no evidence of that. > > Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> > > diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig > index c603bf2..a9f9c48 100644 > --- a/drivers/char/agp/Kconfig > +++ b/drivers/char/agp/Kconfig > @@ -86,7 +86,7 @@ config AGP_NVIDIA > > config AGP_SIS > tristate "SiS chipset support" > - depends on AGP > + depends on AGP && X86 > help > This option gives you AGP support for the GLX component of > X on Silicon Integrated Systems [SiS] chipsets. > @@ -103,7 +103,7 @@ config AGP_SWORKS > > config AGP_VIA > tristate "VIA chipset support" > - depends on AGP > + depends on AGP && X86 > help > This option gives you AGP support for the GLX component of > X on VIA MVP3/Apollo Pro chipsets. I don't know about SiS, but this is certainly *not* true for Via. There are some PowerPC and, IIRC, Alpha motherboards that have Via chipsets. My config-fu isn't quite what it should be, so this may be a dumb question. Does the "& X86" requirement exclude x86-64? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdfkpX1gOwKyEAw8RAmh9AJ42g79Q9isQ0mzy87ILFn8pyW9AjACfWFdu DvPS3GGDJyFfYfaf/8b5H4Y= =NlmP -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Ok due to popular demands here is the slightly fixed patch that works
on both i386 and x86_64. For the i386 version you must not have
HIGHMEM64G enabled.
I just rolled it all into one patch as I'm to lazy to transmit all
3 of them.
Eric
arch/i386/kernel/head.S |8 +
arch/x86_64/kernel/early_printk.c | 580 +
arch/x86_64/kernel/head.S | 11 +-
drivers/usb/host/ehci.h |8 +
include/asm-i386/fixmap.h |1 +
include/asm-x86_64/fixmap.h |1 +
6 files changed, 608 insertions(+), 1 deletions(-)
diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index ca31f18..f683565 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -135,6 +135,12 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
jb 10b
movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
+ /* Do an early initialization of the fixmap area */
+ movl $(swapper_pg_dir - __PAGE_OFFSET), %edx
+ movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax
+ addl $0x007, %eax /* 0x007 = PRESENT+RW+USER */
+ movl %eax, 4092(%edx)
+
#ifdef CONFIG_SMP
xorl %ebx,%ebx /* This is the boot CPU (BSP) */
jmp 3f
@@ -477,6 +483,8 @@ ENTRY(_stext)
.section ".bss.page_aligned","w"
ENTRY(swapper_pg_dir)
.fill 1024,4,0
+ENTRY(swapper_pg_pmd)
+ .fill 1024,4,0
ENTRY(empty_zero_page)
.fill 4096,1,0
diff --git a/arch/x86_64/kernel/early_printk.c
b/arch/x86_64/kernel/early_printk.c
index d4050a5..71f2f88 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
+#include
+#include
+#include
+#define EARLY_PRINTK
+#include "../../../drivers/usb/host/ehci.h"
+
/* Simple VGA output */
@@ -155,6 +165,564 @@ static struct console early_serial_console = {
.index =-1,
};
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE 0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+ x) ^ DBGP_DATA_TOGGLE) & 0x00) | ((tok) & 0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF0xa5
+#define USB_PID_SETUP 0x2d
+/* handshake */
+#define USB_PID_ACK0xd2
+#define USB_PID_NAK0x5a
+#define USB_PID_STALL 0x1e
+#define USB_PID_NYET 0x96
+/* data */
+#define USB_PID_DATA0 0xc3
+#define USB_PID_DATA1 0x4b
+#define USB_PID_DATA2 0x87
+#define USB_PID_MDATA 0x0f
+/* Special */
+#define USB_PID_PREAMBLE 0x3c
+#define USB_PID_ERR0x3c
+#define USB_PID_SPLIT 0x78
+#define USB_PID_PING 0xb4
+#define USB_PID_UNDEF_00xf0
+
+#define USB_PID_DATA_TOGGLE0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG 0xa
+
+#define HUB_ROOT_RESET_TIME50 /* times are in msec */
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME200
+#define HUB_RESET_TIMEOUT 500
+
+#define DBGP_MAX_PACKET8
+
+static int dbgp_wait_until_complete(void)
+{
+ unsigned ctrl;
+ for (;;) {
+ ctrl = readl(_debug->control);
+ /* Stop when the transaction is finished */
+ if (ctrl & DBGP_DONE)
+ break;
+ }
+ /* Now that we have observed the completed transaction,
+* clear the done bit.
+*/
+ writel(ctrl | DBGP_DONE, _debug->control);
+ return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+ int i;
+ while (ms--) {
+ for (i = 0; i < 1000; i++)
+ outb(0x1, 0x80);
+ }
+}
+
+static void dbgp_breath(void)
+{
+ /* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+ unsigned pids, lpid;
+ int ret;
+
+retry:
+ writel(ctrl | DBGP_GO, _debug->control);
+ ret = dbgp_wait_until_complete();
+ pids = readl(_debug->pids);
+ lpid = DBGP_PID_GET(pids);
+
+ if (ret < 0)
+ return ret;
+
+ /* If the port is getting full or it has dropped data
+* start pacing ourselves, not necessary but it's friendly.
+*/
+ if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+ dbgp_breath();
+
+ /* If I get a NACK reissue the transmission */
+ if (lpid == USB_PID_NAK)
+
can't boot : Spurious ACK with kernel 2.6.19
I'm trying to upgrade to kernel 1.6.19. The boot process immediatly locks in a loop with the message: "atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly." The box is running fine with kernel 1.6.18.4. It's an iDEQ200V box with a BioStar motherboar, VIA KM400 + VT8237 chipset. Here's my BIOS information based on dmidecode: BIOS Information Vendor: Phoenix Technologies, LTD Version: 6.00 PG Release Date: 08/19/2003 Address: 0xE Runtime Size: 128 kB ROM Size: 512 kB Characteristics: ISA is supported PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/360 KB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 KB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported LS-120 boot is supported ATAPI Zip drive boot is supported ( .. more info available if useful ..) Did anybody discovered similar issues or have any ideas on how to solve that? Thanks for any help, -- Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] scsi updates for 2.6.19
This is quite a mixed bag. The usual driver updates, plus asynchronous scanning and the new target infrastructure. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git the shortlog is: Adrian Bunk: ipr: Make ipr_ioctl static megaraid_sas: make 2 functions static qla2xxx: make some functions static Alan Stern: Reduce polling in sd.c Andrew Morton: tgt: fix undefined flush_dcache_page() problem ips: fix soft lockup during reset initialization revert "[SCSI] ips soft lockup during reset/initialization" Andrew Vasquez: qla2xxx: add asynchronous scsi scanning support. qla2xxx: defer topology discovery to DPC thread during initialization. Brian King: ipr: Driver version 2.3.0 ipr: Reduce default error log size ipr: Add support for logging SAS fabric errors ipr: Remove debug trace points from dump code ipr: Remove ipr_scsi_timed_out ipr: Set default ipr Kconfig values ipr: PCI IDs for new SAS adapters ipr: Stop issuing cancel all to disk arrays ipr: SATA reset - wait for host reset completion Christoph Hellwig: kill scsi_assign_lock untangle scsi_prep_fn use one-element sg list in scsi_send_eh_cmnd Darrick J. Wong: aic94xx: delete ascb timers when freeing queues aic94xx: handle REQ_DEVICE_RESET aic94xx: handle REQ_TASK_ABORT libsas: add sas_abort_task libsas: modify error handler to use scsi_eh_* functions David C Somayajulu: qla4xxx: fix for timing issue for nvram accesses. qla4xxx: add support for qla4032 qla4xxx: bug fix: driver hardware semaphore needs to be grabbed before soft reset Ed Lin: stex: version update stex: change wait loop code stex: add new device type support stex: update device id info stex: adjust default queue length stex: add value check in hard reset routine stex: fix controller_info command handling stex: fix biosparam calculation FUJITA Tomonori: scsi tgt: IBM eServer i/pSeries virtual SCSI target driver scsi tgt: SCSI RDMA Protocol library functions scsi-ml: Makefile and Kconfig changes for tgt scsi tgt: scsi target user and kernel communication interface scsi tgt: scsi target lib functionality export scsi-ml functions needed by tgt_scsi_lib and its LLDs Hannes Reinecke: block: convert jiffies to msecs in scsi_ioctl() Henne: scsi: t128 scsi_cmnd convertion Ingo Molnar: fix module unload induced compile warning James Bottomley: libsas: better error handling in sas_expander.c 53c700: brown paper bag fix for auto request sense aic94xx: fix pointer to integer conversion warning James Smart: lpfc 8.1.11 : Change version number to 8.1.11 lpfc 8.1.11 : Misc Fixes lpfc 8.1.11 : Add soft_wwnn sysfs attribute, rename soft_wwn_enable lpfc 8.1.11 : Removed decoding of PCI Subsystem Id lpfc 8.1.11 : Add MSI (Message Signalled Interrupts) support lpfc 8.1.11 : Adjust LOG_FCP logging lpfc 8.1.11 : Fix Memory leaks lpfc 8.1.11 : Fix lpfc_multi_ring_support lpfc 8.1.11 : Discovery Fixes Jeff Garzik: megaraid: fix MMIO casts minor bug fixes and cleanups SCSI/aha1740: handle SCSI API errors Kai Makisara: st: log message changes Luben Tuikov: sd: clearer output of disk cache state Mark Haverkamp: aacraid: Driver version update aacraid: Abort management FIBs aacraid: Detect Blinkled at startup Matthew Wilcox: Make scsi_scan_host work for drivers which find their own targets fix missing check for no scanning Add Kconfig option for asynchronous SCSI scanning Add ability to scan scsi busses asynchronously Randy Dunlap: qla2xxx: use NULL instead of 0 initio: fix section mismatches with HOTPLUG=n Salyzyn, Mark: aic79xx: Add ASC-29320LPE ids to driver and the diffstat: Documentation/kernel-parameters.txt |5 Documentation/scsi/scsi_mid_low_api.txt | 31 - block/scsi_ioctl.c |2 drivers/scsi/53c700.c |7 drivers/scsi/BusLogic.c | 12 drivers/scsi/Kconfig| 59 + drivers/scsi/Makefile |7 drivers/scsi/NCR53c406a.c |5 drivers/scsi/aacraid/aacraid.h |4 drivers/scsi/aacraid/commsup.c | 23 drivers/scsi/aha1740.c | 10 drivers/scsi/aic7xxx/aic79xx_osm_pci.c |1 drivers/scsi/aic7xxx/aic79xx_pci.c |8 drivers/scsi/aic7xxx/aic79xx_pci.h |1 drivers/scsi/aic94xx/aic94xx_init.c |9 drivers/scsi/aic94xx/aic94xx_scb.c | 120 +++- drivers/scsi/fd_mcs.c |2 drivers/scsi/hosts.c|8
Re: [patch] add ignore_loglevel boot option
On Tue, 5 Dec 2006 13:09:54 +0100 Ingo Molnar wrote:
> Subject: [patch] add ignore_loglevel boot option
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> sometimes the kernel prints something interesting while userspace
> bootup keeps messages turned off via loglevel. Enable the printing
> of /all/ kernel messages via the "ignore_loglevel" boot option.
> Off by default.
Hi,
Is this equivalent to using the "debug" kernel parameter
except that userspace (init scripts) cannot muck it up (modify
the setting)?
I've seen init scripts modify the loglevel, much to my
dismay.
I'd say that this is useful, but it's really userspace
that needs to be fixed.
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> Documentation/kernel-parameters.txt |4
> kernel/printk.c | 14 +-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> Index: linux/kernel/printk.c
> ===
> --- linux.orig/kernel/printk.c
> +++ linux/kernel/printk.c
> @@ -352,13 +352,25 @@ static void __call_console_drivers(unsig
> touch_critical_timing();
> }
>
> +static int __read_mostly ignore_loglevel;
> +
> +int __init ignore_loglevel_setup(char *str)
> +{
> + ignore_loglevel = 1;
> + printk(KERN_INFO "debug: ignoring loglevel setting.\n");
> +
> + return 1;
> +}
> +
> +__setup("ignore_loglevel", ignore_loglevel_setup);
> +
> /*
> * Write out chars from start to end - 1 inclusive
> */
> static void _call_console_drivers(unsigned long start,
> unsigned long end, int msg_log_level)
> {
> - if (msg_log_level < console_loglevel &&
> + if ((msg_log_level < console_loglevel || ignore_loglevel) &&
> console_drivers && start != end) {
> if ((start & LOG_BUF_MASK) > (end & LOG_BUF_MASK)) {
> /* wrapped write */
> -
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage
On Tue, 5 Dec 2006 17:38:07 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote: > > When your patches are queued in -mm please do test them there, and review > > others' changes to them, and raise patches against them. Raising patches > > against one's private tree and not testing the code which is planned to be > > merged can introduce errors. > > Sorry about that. I noticed your fix, and the one by Adrian. And I did add > them to my fsstack queue. you don't have an fsstack queue any more ;) Please, I really do want developers to test their code in -mm once I've merged it. What happens if there's some nasty interaction between your patch and someone else's? We'll not find out about it and it'll get merged. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon] 2.6.19 new perfmon code base + libpfm + pfmon
On Tue, Dec 05, 2006 at 12:24:36PM -0500, William Cohen wrote: > Some of the ptrace functions (e.g. ptrace_may_attach in perfmon_syscall.c) > being used in the perfmon kernel patches will go away with the utrace > patches: http://people.redhat.com/roland/utrace/ At least for ptrace_may_attach that's not true in the lastest version from Roland - in fact it's the last unconditional function in ptrace.c in that version. I suggested to him to rename and move it in my review, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] IPMI: add poll delay
On 05/12/06, Corey Minyard <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> On Fri, 1 Dec 2006 22:35:20 -0600
> Corey Minyard <[EMAIL PROTECTED]> wrote:
>
>
>> Make sure to delay a little in the IPMI poll routine so we can pass in
>> a timeout time and thus time things out.
>>
>> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>>
>> Index: linux-2.6.19-rc6/drivers/char/ipmi/ipmi_si_intf.c
>> ===
>> --- linux-2.6.19-rc6.orig/drivers/char/ipmi/ipmi_si_intf.c
>> +++ linux-2.6.19-rc6/drivers/char/ipmi/ipmi_si_intf.c
>> @@ -807,7 +807,12 @@ static void poll(void *send_info)
>> {
>> struct smi_info *smi_info = send_info;
>>
>> -smi_event_handler(smi_info, 0);
>> +/*
>> + * Make sure there is some delay in the poll loop so we can
>> + * drive time forward and timeout things.
>> + */
>> +udelay(10);
>> +smi_event_handler(smi_info, 10);
>> }
>>
>
> I don't understand what this patch is doing. It looks fishy. More
> details, please?
>
Yeah, it does look a little fishy. This is a poll routine that is only
called at panic
time; it is used to force things to happen in the driver without
scheduling or
timers. The driver does this so it can set watchdog parameters and store
panic information in the event log at panic time.
Without this change, if something goes wrong in the BMC the driver will
never
time out the operation since it doesn't see time being driven forward.
So this
makes sure the driver sees time advancing as it should.
Hmm, I wonder if this could explain why some of my IBM servers become
unreachable via IPMI after a kernel crash.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage
On Tue, Dec 05, 2006 at 02:28:31PM -0800, Andrew Morton wrote: > On Tue, 5 Dec 2006 14:22:32 -0500 > Josef Sipek <[EMAIL PROTECTED]> wrote: > > > Fix up a stray ecryptfs_copy_attr_all call and remove prototypes for > > ecryptfs_copy_* as they no longer exist. > > > > Signed-off-by: Josef "Jeff" Sipek <[EMAIL PROTECTED]> > > --- > > fs/ecryptfs/dentry.c |2 +- > > fs/ecryptfs/ecryptfs_kernel.h |4 +--- > > 2 files changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/fs/ecryptfs/dentry.c b/fs/ecryptfs/dentry.c > > index 52d1e36..b0352d8 100644 > > --- a/fs/ecryptfs/dentry.c > > +++ b/fs/ecryptfs/dentry.c > > @@ -61,7 +61,7 @@ static int ecryptfs_d_revalidate(struct > > struct inode *lower_inode = > > ecryptfs_inode_to_lower(dentry->d_inode); > > > > - ecryptfs_copy_attr_all(dentry->d_inode, lower_inode); > > + fsstack_copy_attr_all(dentry->d_inode, lower_inode, NULL); > > I fixed that two weeks ago. > > When your patches are queued in -mm please do test them there, and review > others' changes to them, and raise patches against them. Raising patches > against one's private tree and not testing the code which is planned to be > merged can introduce errors. Sorry about that. I noticed your fix, and the one by Adrian. And I did add them to my fsstack queue. I must have dropped it accidentally. Josef "Jeff" Sipek. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19: OOPS in cat /proc/fs/nfs/exports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > There is a place where a failed kstrdup could lead to this, but that > is rather unlikely and wouldn't be as reproducible as this seems to > be. > If you boot up and then immediately shutdown does this error trigger, > it does it have to be up for a while? It happens right after booting. I've since disabled the NFS server on that box, and just tried to manually start it, and it gives me this: # /usr/sbin/exportfs -r bigred:/video/rec: Cannot allocate memory That is the first and only export: # cat /etc/exports # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). /video/rec bigred(rw,sync) strace on exportfs shows this:nfsservctl(0x3, 0xbf875824, 0) = - -1 ENOMEM After that, /proc/fs/nfs/export exists and gives the Oops, while /proc/fs/nfsd/export doesn't exist. I don't think however this box is particularly short on memory: MemTotal: 248704 kB MemFree:102780 kB Buffers: 20520 kB Cached: 50692 kB SwapCached: 0 kB Active: 81712 kB Inactive:25160 kB SwapTotal: 0 kB SwapFree:0 kB Dirty:1516 kB Writeback: 0 kB AnonPages: 35672 kB Mapped: 13104 kB Slab: 6960 kB SReclaimable: 3104 kB SUnreclaim: 3856 kB PageTables:692 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:124352 kB Committed_AS: 124528 kB VmallocTotal: 786136 kB VmallocUsed: 7568 kB VmallocChunk: 778508 kB (this is right after booting, DVB drivers loaded and VDR running.) Will try your patch tomorrow. Olaf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdfNoGPw4gdAdiZ0RAjDdAJ4yPltxWuJe21yB9nc2zBooLWJ2TwCaAg1I tNsnDshD1gVpW/FYJ5P9J28= =1zag -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage
On Tue, 5 Dec 2006 14:22:32 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote: > Fix up a stray ecryptfs_copy_attr_all call and remove prototypes for > ecryptfs_copy_* as they no longer exist. > > Signed-off-by: Josef "Jeff" Sipek <[EMAIL PROTECTED]> > --- > fs/ecryptfs/dentry.c |2 +- > fs/ecryptfs/ecryptfs_kernel.h |4 +--- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/fs/ecryptfs/dentry.c b/fs/ecryptfs/dentry.c > index 52d1e36..b0352d8 100644 > --- a/fs/ecryptfs/dentry.c > +++ b/fs/ecryptfs/dentry.c > @@ -61,7 +61,7 @@ static int ecryptfs_d_revalidate(struct > struct inode *lower_inode = > ecryptfs_inode_to_lower(dentry->d_inode); > > - ecryptfs_copy_attr_all(dentry->d_inode, lower_inode); > + fsstack_copy_attr_all(dentry->d_inode, lower_inode, NULL); I fixed that two weeks ago. When your patches are queued in -mm please do test them there, and review others' changes to them, and raise patches against them. Raising patches against one's private tree and not testing the code which is planned to be merged can introduce errors. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
