[PATCH] POWER 4 fails to boot with NUMA
From: Mike Kravetz <[EMAIL PROTECTED]>
If CONFIG_NUMA is set, some POWER 4 systems will fail to boot. This is
because of special processing needed to handle invalid node IDs (0x)
on POWER 4. My previous patch to handle memory 'holes' within nodes
forgot to add this special case for POWER 4 in one place.
In reality, I'm not sure that configuring the kernel for NUMA on POWER 4
makes much sense. Are there POWER 4 based systems with NUMA characteristics
that are presented by the firmware? But, distros want one kernel for all
systems so NUMA is on by default in their kernels. The patch handles those
cases.
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
diff -urN linux-2.6/arch/ppc64/mm/numa.c g5-ppc64/arch/ppc64/mm/numa.c
--- linux-2.6/arch/ppc64/mm/numa.c 2005-06-24 13:38:52.0 +1000
+++ g5-ppc64/arch/ppc64/mm/numa.c 2005-08-01 15:15:55.0 +1000
@@ -647,7 +647,12 @@
new_range:
mem_start = read_n_cells(addr_cells, _buf);
mem_size = read_n_cells(size_cells, _buf);
- numa_domain = numa_enabled ?
of_node_numa_domain(memory) : 0;
+ if (numa_enabled) {
+ numa_domain = of_node_numa_domain(memory);
+ if (numa_domain >= MAX_NUMNODES)
+ numa_domain = 0;
+ } else
+ numa_domain = 0;
if (numa_domain != nid)
continue;
-
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: percpu_modalloc oops when loading netfilter modules
On Sat, 2005-07-30 at 00:48 +0100, Daniel Drake wrote:
> Pete, Rusty,
>
> I found a snippet of a previous discussion of yours here:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/2901.html
> http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html
>
> Did anything become of this issue?
>
> A Gentoo user has reported what appears to be the same problem on 2.6.12:
> http://bugs.gentoo.org/show_bug.cgi?id=97006
Name: Module per-cpu alignment cannot always be met.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> (authored)
The module code assumes noone will ever ask for a per-cpu area more
than SMP_CACHE_BYTES aligned. However, as these cases show, gcc asks
sometimes asks for 32-byte alignment for the per-cpu section on a
module, and if CONFIG_X86_L1_CACHE_SHIFT is 4, we hit that BUG_ON().
This is obviously an unusual combination, as there have been few
reports, but better to warn than die.
See:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html
And more recently:
http://bugs.gentoo.org/show_bug.cgi?id=97006
Index: linux-2.6.13-rc4-git3-Netfilter/kernel/module.c
===
--- linux-2.6.13-rc4-git3-Netfilter.orig/kernel/module.c2005-08-01
14:58:44.0 +1000
+++ linux-2.6.13-rc4-git3-Netfilter/kernel/module.c 2005-08-01
15:21:30.0 +1000
@@ -250,13 +250,18 @@
/* Created by linker magic */
extern char __per_cpu_start[], __per_cpu_end[];
-static void *percpu_modalloc(unsigned long size, unsigned long align)
+static void *percpu_modalloc(unsigned long size, unsigned long align,
+const char *name)
{
unsigned long extra;
unsigned int i;
void *ptr;
- BUG_ON(align > SMP_CACHE_BYTES);
+ if (align > SMP_CACHE_BYTES) {
+ printk(KERN_WARNING "%s: per-cpu alignment %li > %i\n",
+ name, align, SMP_CACHE_BYTES);
+ align = SMP_CACHE_BYTES;
+ }
ptr = __per_cpu_start;
for (i = 0; i < pcpu_num_used; ptr += block_size(pcpu_size[i]), i++) {
@@ -348,7 +353,8 @@
}
__initcall(percpu_modinit);
#else /* ... !CONFIG_SMP */
-static inline void *percpu_modalloc(unsigned long size, unsigned long align)
+static inline void *percpu_modalloc(unsigned long size, unsigned long align,
+ const char *name)
{
return NULL;
}
@@ -1644,7 +1650,8 @@
if (pcpuindex) {
/* We have a special allocation for this section. */
percpu = percpu_modalloc(sechdrs[pcpuindex].sh_size,
-sechdrs[pcpuindex].sh_addralign);
+sechdrs[pcpuindex].sh_addralign,
+mod->name);
if (!percpu) {
err = -ENOMEM;
goto free_mod;
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
-
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: git-net-fixup.patch added to -mm tree
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sun, 31 Jul 2005 22:21:25 -0700 > Actually, that patch is just a fixup for a patch reject from the net-2.6.14 > diff. I do that sometimes when I get sick of fixing up the same reject > each time I pull the various trees. > > (I'm not sure _why_ I'm getting a reject applying that diff. Nothing else > touches that file. git is not quite yet generating the linus->davem diff > which I want..) There is a tiny bit of conflicts between linux-2.6 and net-2.6.14, because of some bug fixes that went into Linus's tree over the past week. I'll try to rebuild the net-2.6.14 tree if I get a chance before heading off to the UK tomorrow. That should help things out for you. - 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: topology api confusion
Anton Blanchard wrote: > > Hi, > > > We need some clarity on how asm-generic/topology.h is intended to be > > used. I suspect that it's supposed to be unconditionally included at > > the end of the architecture's topology.h so that any elements which > > are undefined by the arch have sensible default definitions. Looking > > at 2.6.13-rc3, this is what ppc64, ia64, and x86_64 currently do, > > however i386 does not (i386 pulls in the generic version only when > > !CONFIG_NUMA). > > > > The #ifndef guards around each element of the topology api > > cannot serve their apparent intended purpose when the architecture > > implements a given bit as a function instead of a macro > > (e.g. cpu_to_node in ppc64): > > Since it doesnt look like this will be resolved by 2.6.13 and NUMA is > currently completely broken on ppc64, how does this patch look? Yes, this change is the least risk for now, thanks. > > -- > > Dont include asm-generic/topology.h unconditionally, we end up > overriding all the ppc64 specific functions when NUMA is on. > > Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]> > > Index: linux-2.6.git-work/include/asm-ppc64/topology.h > === > --- linux-2.6.git-work.orig/include/asm-ppc64/topology.h 2005-07-30 > 23:49:56.0 +1000 > +++ linux-2.6.git-work/include/asm-ppc64/topology.h 2005-08-01 > 14:43:49.0 +1000 > @@ -33,6 +33,7 @@ > return first_cpu(tmp); > } > > +#define pcibus_to_node(node)(-1) > #define pcibus_to_cpumask(bus) (cpu_online_map) > > #define nr_cpus_node(node) (nr_cpus_in_node[node]) > @@ -59,8 +60,10 @@ > .nr_balance_failed = 0,\ > } > > -#endif /* CONFIG_NUMA */ > +#else > > #include > > +#endif /* CONFIG_NUMA */ > + > #endif /* _ASM_PPC64_TOPOLOGY_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: git-net-fixup.patch added to -mm tree
"David S. Miller" <[EMAIL PROTECTED]> wrote:
>
> From: [EMAIL PROTECTED]
> Date: Sun, 31 Jul 2005 22:03:47 -0700
>
> > From: Andrew Morton <[EMAIL PROTECTED]>
> >
> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ...
> > /* decrement reference count on a conntrack */
> > -extern void ip_conntrack_put(struct ip_conntrack *ct);
> > +static inline void
> > +ip_conntrack_put(struct ip_conntrack *ct)
> > +{
> > + IP_NF_ASSERT(ct);
> > + nf_conntrack_put(>ct_general);
> > +}
>
> You can instead just kill the EXPORT_SYMBOL_GPL() in
> ip_conntrack_standalone.c as that's the only reference outside of
> ip_conntrack_core.c
>
> Harald?
Actually, that patch is just a fixup for a patch reject from the net-2.6.14
diff. I do that sometimes when I get sick of fixing up the same reject
each time I pull the various trees.
(I'm not sure _why_ I'm getting a reject applying that diff. Nothing else
touches that file. git is not quite yet generating the linus->davem diff
which I want..)
-
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: git-net-fixup.patch added to -mm tree
From: [EMAIL PROTECTED]
Date: Sun, 31 Jul 2005 22:03:47 -0700
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
...
> /* decrement reference count on a conntrack */
> -extern void ip_conntrack_put(struct ip_conntrack *ct);
> +static inline void
> +ip_conntrack_put(struct ip_conntrack *ct)
> +{
> + IP_NF_ASSERT(ct);
> + nf_conntrack_put(>ct_general);
> +}
You can instead just kill the EXPORT_SYMBOL_GPL() in
ip_conntrack_standalone.c as that's the only reference outside of
ip_conntrack_core.c
Harald?
-
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: topology api confusion
Hi, > We need some clarity on how asm-generic/topology.h is intended to be > used. I suspect that it's supposed to be unconditionally included at > the end of the architecture's topology.h so that any elements which > are undefined by the arch have sensible default definitions. Looking > at 2.6.13-rc3, this is what ppc64, ia64, and x86_64 currently do, > however i386 does not (i386 pulls in the generic version only when > !CONFIG_NUMA). > > The #ifndef guards around each element of the topology api > cannot serve their apparent intended purpose when the architecture > implements a given bit as a function instead of a macro > (e.g. cpu_to_node in ppc64): Since it doesnt look like this will be resolved by 2.6.13 and NUMA is currently completely broken on ppc64, how does this patch look? -- Dont include asm-generic/topology.h unconditionally, we end up overriding all the ppc64 specific functions when NUMA is on. Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]> Index: linux-2.6.git-work/include/asm-ppc64/topology.h === --- linux-2.6.git-work.orig/include/asm-ppc64/topology.h2005-07-30 23:49:56.0 +1000 +++ linux-2.6.git-work/include/asm-ppc64/topology.h 2005-08-01 14:43:49.0 +1000 @@ -33,6 +33,7 @@ return first_cpu(tmp); } +#define pcibus_to_node(node)(-1) #define pcibus_to_cpumask(bus) (cpu_online_map) #define nr_cpus_node(node) (nr_cpus_in_node[node]) @@ -59,8 +60,10 @@ .nr_balance_failed = 0,\ } -#endif /* CONFIG_NUMA */ +#else #include +#endif /* CONFIG_NUMA */ + #endif /* _ASM_PPC64_TOPOLOGY_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: IBM HDAPS, I need a tip.
On Sun, 2005-07-31 at 22:56 -0600, Alejandro Bonilla Beeche wrote: > Second Try... ;-) > > Anyone? You're obviously getting different values because "moving the laptop left to right" will produce a different acceleration every time. So in order to calibrate it you need a readily available source of constant acceleration, preferably with a known value. Hint: -9.8 m/sec^2. Lee - 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: IBM HDAPS, I need a tip.
Second Try... ;-) Anyone? .Alejandro On Sun, 2005-07-31 at 19:53 -0600, Alejandro Bonilla Beeche wrote: > Hi Guys, > > I hope you all aren't sick about the topic. I have a quick question... > > Thanks to development of the driver from some nice guys, we are able to > get data from the accelerometer. There is one problem. How do we > calibrate the values that are outputed from the userspace? All PC's get > a different value, and we can't really find the best solution. What is > the scientific and smartest way to do this? > > i.e. of the driver output from the userspace. > [EMAIL PROTECTED]:~/hdaps/hdaps-dave-0.02 > $ ./ibm_hdaps_userspace /dev/ibm_hdaps > x_accel: 409 > y_accel: 528 >temp: 47 > temp2: 47 > unknown: 7 > > If I move the PC 45 deg right.(Looking from front the left side is > higher) > > km_activity (keybd) = 0 > km_activity (mouse) = 0 > x_accel: 396 > y_accel: 579 >temp: 47 > temp2: 47 > unknown: 7 > > > The thing is, people have different values, and I think they are also > different depending on where they are. > > Another question for this kernel inclusion (heh) Should we use Sysfs or > should we use the userspace that outputs this data, else what is > recomended? > > Thanks in advance, > > .Alejandro - 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: revert yenta free_irq on suspend
On Sun, 31 Jul 2005 [EMAIL PROTECTED] wrote: > > We either need to change every driver to free irqs or "harden" each > of them. No. No "either". Drivers need to be safe from the hw going away, whether it be physically or because it got shut down. > Freeing irqs obviously seems easier. No. Freeing irq's DOES NOT HELP. Listen to me. You need the hardening of the driver anyway for the hotplug case. Freeing irq's doesn't do anything for it, it's just shuffling the real problem under the carpet. So fix the damn problem _right_, and suddenly freeing the irq doesn't make any difference at all. It's just unnecessary and incorrect complexity. Linus - 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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote: > ok - i've uploaded the -52-04 patch, does that fix it for you? Has anyone found their PS2 keyboard rather sluggish with this kernel? I'm not sure whether it's an -RT problem, I'll have to try rc4. Lee - 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 patch] remove support for gcc < 3.2
Adrian Bunk <[EMAIL PROTECTED]> writes: > This patch removes support for gcc < 3.2 . Go away. -miles -- "Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit?" [George Carlin] - 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: [git patches] net driver fixes
Linus Torvalds <[EMAIL PROTECTED]> writes: > Ugh. It's not like we want people saying "Hi there" in our changelogs. Well the _occasional_ friendly greeting might be kinda nice... -miles hi mom! -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. fnord. - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On 08/01/05 12:36:16AM +0200, Pavel Machek wrote: > > If the kernel defaults are irrelevant, then it would make more sense to > > leave the default HZ as 1000 and not to enable the cpufreq and ACPI in > > order to keep with the principle of least surprise for people who do use > > kernel.org kernels. > > Well, I'd say you want ACPI enabled. New machine do not even boot > without that. Default config should be usefull; set ACPI off, and > you'll not be able to even power machine down. And there are older machines that won't boot with it enabled. The machine I'm typing this on has a really shitty ACPI implementation, I don't remember the details because it's been so long but I know that I have to disable ACPI for it to work right. I'm not saying defconfig should never be changed, but changing what can and will cause noticeable breakage should be avoided if possible. And in this case it doesn't seem to me that the benefits of changing HZ in the middle of a "stable" series outweigh the added latency. > Pavel Jim. - 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: SCSI tape problems: 2.6.12, DLT 7000, Adaptec AIC7xxx controller
At 7/31/2005 22:35 -0400, John Stoffel wrote: I don't know if this is a problem with the AIC7xxx driver, the tape in the drive, or the DLT7000 drive itself. Run the DLTsage/Xtalk diagnostics found at http://tinyurl.com/dn7xn [which redirects to http://www.quantum.com/ServiceandSupport/SoftwareandDocumentationDownloads/DLT7000/Index.aspx#Diagnostics ]. Note: They have a Linux version there, but I have no personal experience with it. -- Jeff Woods <[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: revert yenta free_irq on suspend
- Original Message - From: Linus Torvalds <[EMAIL PROTECTED]> Date: Sunday, July 31, 2005 9:07 pm Subject: Re: revert yenta free_irq on suspend > > > On Mon, 1 Aug 2005, Dave Airlie wrote: > > > > You said earlier we only should fix drivers that need fixing, but > they> all need fixing > > I think you're still talking from a theoretical standpoing, while > all my > arguments are practical. > > In _practice_, I hope that > > (a) we don't see that very much (ie the people for whom things > work > already are a strong argument that this is less of a problem in > practice than people try to make it appear) They may not always be triggered, but they are real bugs. We can't ensure stable PM until they are fixed. If they weren't a real issue, then calling free_irq() in pcmcia probably wouldn't have broken the sound driver we saw in this case. > > (b) drivers, _especially_ on notebooks, are already able to handle > an > incoming interrupt with the device in D3 state and returning 0xff > for all reads. > > In particular, this is exactly the same thing that you get on > a > surprise device removal too. > > iow it really _really_ shouldn't matter that a shared interrupt > comes in > after (or before) a device has gone to sleep. Because a driver that > can'thandle that schenario is buggy for totally unrelated reasons, > and doing a > "free_irq()/request_irq()" pair at suspend time is _not_ the solution! I understand this. But calling free_irq()/request_irq() still seems to make sense. It's the cleanest and most straightforward approach. It's the easiest way we can ensure there will not be race conditions. An interrupt could be triggered during the device's power transition when it's in between on and off. More importantly, we need this change for runtime power management anyway. > > > This has nothing to do with the issues with highlevel PM interfaces > > for shutting down hardware, this is do with fixing the drivers in > the> kernel currently and what the correct way to do it is without > breaking> someone elses hardware > > ... and I don't think this has _anything_ to do with > free_irq/request_irq, > and everything to do with the fact that we can try to make at least > the > common drivers "hardened" for unexpected interrupts coming in when > the hw > might not be ready for them. We either need to change every driver to free irqs or "harden" each of them. Freeing irqs obviously seems easier. I propose we make this change in -mm in one pass to avoid bugs like this. Also, as I said earlier, the better we support OSPM initiated power management, the more likely APM will break. This may be technically unavoidable on some isolated boxes without quirks. I agree with Pavel that "do nothing" may make sense, but it seems some devices may still need to be disabled by the OS. As a real world example, we currently can't turn off cardbus bridges because it breaks APM on a couple of older laptops. Thanks, Adam - 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 patch] remove support for gcc < 3.2
On Mon, Aug 01, 2005 at 12:26:07AM +0200, Adrian Bunk took 109 lines to write: > This patch removes support for gcc < 3.2 . > > The advantages are: > - reducing the number of supported gcc versions from 8 to 4 [1] > allows the removal of several #ifdef's and workarounds > - my impression is that the older compilers are only rarely > used, so miscompilations of a driver with an old gcc might > not be detected for a longer amount of time > > My personal opinion about the time and space a compilation requires is > that this is no longer that much of a problem for modern hardware, and > in the worst case you can compile the kernels for older machines on more > recent machines. Environments that require kernel compilation, often multiple times, testing, benefit from shorter compile times. It can be the difference between, say, completing a test suite overnight instead of having to wait until tomorrow afternoon. Keeping 2.95, at least, has some value in such environments. Kurt -- A chubby man with a white beard and a red suit will approach you soon. Avoid him. He's a Commie. - 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/
SCSI tape problems: 2.6.12, DLT 7000, Adaptec AIC7xxx controller
Hi All, I've just a Dell Precision 610 dual CPU Xeon workstation, with 550mhz CPUs and 768mb of RAM. I'm running 2.6.12 right now, and using two different SCSI busses on the system to run some disks and a DLT 7000 tape drive on it's own bus. I'm using Bacula (www.bacula.org) as my backup software. The aic7xxx and st, sd drivers are all compiled into the kernel. I'll be trying 2.6.13-rc4 as well, but I don't know what will happen here. I don't know if this is a problem with the AIC7xxx driver, the tape in the drive, or the DLT7000 drive itself. I've gotten the following oops/crash, which kills the tape drive completely. I can't get it back without a power cycle of the tape drive. Doing 'scsiadd' or 'sg_scan' sometimes works, but not often. I've had some sucess with doing a 'scsiadd -r' first to remove the DLT entry, then doing a 'scsiadd -a' to bring it back online, but only if I power cycle the tape drive. Here's the oops/crash info: scsi1:0:6:0: Attempting to queue an ABORT message CDB: 0xa 0x0 0x0 0xfc 0x0 0x0 scsi1: At time of recovery, card was not paused >> Dump Card State Begins < scsi1: Dumping Card State in Command phase, at SEQADDR 0x156 Card was paused ACCUM = 0x80, SINDEX = 0xac, DINDEX = 0xc0, ARG_2 = 0x0 HCNT = 0x0 SCBPTR = 0x0 SCSISIGI[0x84]:(BSYI|CDI) ERROR[0x0] SCSIBUSL[0xc0] LASTPHASE[0x80]:(CDI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0x2]:(SELWIDE) SCSIRATE[0x88]:(WIDEXFER) SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x0] SSTAT0[0x7]:(DMADONE|SPIORDY|SDONE) SSTAT1[0x2]:(PHASECHG) SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x6d]:(FIFOEMP|DFTHRESH|HDONE|FIFOQWDEMP|DFCACHETH) STACK: 0x37 0x0 0x150 0x191 SCB count = 4 Kernel NEXTQSCB = 3 Card NEXTQSCB = 3 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Sequencer SCB Info: 0 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x67] SCB_LUN[0x0] SCB_TAG[0x2] 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Pending list: 2 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x67] SCB_LUN[0x0] Kernel Free SCB list: 1 0 Untagged Q(6): 2 < Dump Card State Ends >> scsi1:0:6:0: Device is active, asserting ATN Recovery code sleeping Recovery code awake Timer Expired aic7xxx_abort returns 0x2003 scsi1:0:6:0: Attempting to queue a TARGET RESET message CDB: 0xa 0x0 0x0 0xfc 0x0 0x0 aic7xxx_dev_reset returns 0x2003 Recovery SCB completes scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 6 lun 0 st0: Error 1 (sugg. bt 0x0, driver bt 0x0, host bt 0x1). -- Here's the cat /proc/scsi/aic7xxx/1 info: jfsnew:~> cat /proc/scsi/aic7xxx/1 Adaptec AIC7xxx driver version: 6.2.36 Adaptec aic7880 Ultra SCSI adapter aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs Allocated SCBs: 4, SG List Length: 128 Serial EEPROM: 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x0378 0x10a4 0x1c1e 0x2807 0x0010 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x
Re: revert yenta free_irq on suspend
On Sun, 2005-07-31 at 19:06 -0700, Andrew Morton wrote: > Shaohua Li <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > In general, I think that calling free_irq is the right behavior. > > > Although irqs changing after suspend is rare, there are also some > > > more serious issues. This has been discussed in the past, and a > > > summary is as follows: > > > > irqs actually isn't changed after suspend currently, it's a considering > > for future usage like hotplug. > > Calling free_irq actually isn't a complete ACPI issue, but ACPI requires > > it to solve nasty 'sleep in atomic' warning. > > Is that the only problem? If so, then surely we can make free_irq() run > happily with interrupts disabled: unlink the IRQ handler synchronously, > defer the /proc teardown or something like that. The problem is we are going to use ACPI interpreter with interrupt disabled. The interpreter itself might use kmalloc, semaphore, iomap, msleep and etc, depends on BIOS. Fixing interpreter is hard. Originally we think to introduce a new system state for suspend/resume to avoid warning, but later we found drivers calling pci_disable_irq/free_irq is better and safer not just for the issue at hand. We might reconsider previous option (a new system state) if free_irq is rejected. Thanks, Shaohua - 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 guide to space (updated)
Jan Engelhardt <[EMAIL PROTECTED]> writes:
>>3i. if/else/do/while/for/switch
>> space between if/else/do/while and following/preceeding
>> statements/expressions, if any
>
> Why this? if(a) {} is not any worse than if (a).
Well it's harder to read (because it makes control constructs look more
like function calls). And a bit uglier.
But anyway, coding styles are rarely about "worse" versus "better",
they're about keeping things consistent so that it's easier to read
code.
-Miles
--
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR]
-
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: revert yenta free_irq on suspend
Shaohua Li <[EMAIL PROTECTED]> wrote: > > Hi, > > In general, I think that calling free_irq is the right behavior. > > Although irqs changing after suspend is rare, there are also some > > more serious issues. This has been discussed in the past, and a > > summary is as follows: > > irqs actually isn't changed after suspend currently, it's a considering > for future usage like hotplug. > Calling free_irq actually isn't a complete ACPI issue, but ACPI requires > it to solve nasty 'sleep in atomic' warning. Is that the only problem? If so, then surely we can make free_irq() run happily with interrupts disabled: unlink the IRQ handler synchronously, defer the /proc teardown or something like that. > You will find such break > with swsusp without ACPI. Could we revert the ACPI change in Linus's > tree but keep it in -mm tree? So we get a chance to fix drivers. That depends on the amount of brokenness involved: if it's significant then I'll get a ton of bug reports concerning something which we already know is broken and we'll drive away our long-suffering testers. - 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] Re: 2.6.13-rc4-mm1
> Date: Sun, 31 Jul 2005 16:02:44 -0700
> From: Greg KH <[EMAIL PROTECTED]>
>
> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> > I think that "continuing" codepath came from someone at Phoenix, FWIW;
> > the problem is that I see the PCI quirks code has evolved even farther
> > from the main copy of the init code in the USB tree. Sigh.
>
> I don't like that either, but can't think of a way to make it easier to
> keep them in sync. Can you?
Sure. The problem as I see it is that there are two copies, and one
of them isn't in the USB part of the tree. So just move it, and cope
with the consequences during the 2.6.14 cycle:
(a) Move the USB quirks out of the generic PCI drivers directory
into the USB HCD directory (see the attached patch);
(b) foreach HCD in (ehci ohci uhci) do:
(1) Merge the two different routines: HCD internal init/reset
and the PCI quirk code are identical in intent, but they
each address different sets of quirks.
(2) Then the HCD reset() and PCI quirk() code will call those
single shared routine.
At OLS, Vojtech mentioned wanting to make "usb-handoff" be the default.
That's seem plausible (USB has more than its fair share of BIOS issues!)
but should only kick in sometime after we merge the two different sets
of quirk handling logic.
- Dave
This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory.
Follow-on patches will need to remove code duplication, and probably
make "usb-handoff" be the system default.
Compile-tested only so far.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- g26.orig/drivers/usb/host/Makefile 2005-06-28 19:23:13.0 -0700
+++ g26/drivers/usb/host/Makefile 2005-07-31 18:41:35.0 -0700
@@ -1,8 +1,9 @@
#
-# Makefile for USB Host Controller Driver
-# framework and drivers
+# Makefile for USB Host Controller Drivers
#
+obj-$(CONFIG_PCI) += pci-quirks.o
+
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/drivers/usb/host/pci-quirks.c 2005-07-31 17:33:38.0 -0700
@@ -0,0 +1,279 @@
+/*
+ * This file contains work-arounds for many known PCI hardware and BIOS
+ * quirks relating to USB host controllers.
+ *
+ * There are a lot of those, especially on hardware that needs to work
+ * with USB mice and keyboard for booting. And this code needs to fire
+ * early; before the input subsystem gets initialized, and while BIOS
+ * (or SMI) code has few problems running.
+ *
+ * They're collected here since USB host controller drivers need to use
+ * the same code as part of hardware initialization.
+ *
+ * Copyright (c) 1999 Martin Mares <[EMAIL PROTECTED]>
+ * (and others)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+// #include "pci.h"
+
+/*
+ * PIIX3 USB: We have to disable USB interrupts that are
+ * hardwired to PIRQD# and may be shared with an
+ * external device.
+ *
+ * Legacy Support Register (LEGSUP):
+ * bit13: USB PIRQ Enable (USBPIRQDEN),
+ * bit4: Trap/SMI On IRQ Enable (USBSMIEN).
+ *
+ * We mask out all r/wc bits, too.
+ */
+static void __devinit quirk_piix3_usb(struct pci_dev *dev)
+{
+ u16 legsup;
+
+ pci_read_config_word(dev, 0xc0, );
+ legsup &= 0x50ef;
+ pci_write_config_word(dev, 0xc0, legsup);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_2,
quirk_piix3_usb );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_2,
quirk_piix3_usb );
+
+
+/* FIXME this should be the same code that the USB controllers use...
+ * the hcd->reset() method basically does this.
+ */
+
+#define UHCI_USBLEGSUP 0xc0/* legacy support */
+#define UHCI_USBCMD0 /* command register */
+#define UHCI_USBSTS2 /* status register */
+#define UHCI_USBINTR 4 /* interrupt register */
+#define UHCI_USBLEGSUP_DEFAULT 0x2000 /* only PIRQ enable set */
+#define UHCI_USBCMD_RUN(1 << 0)/* RUN/STOP bit */
+#define UHCI_USBCMD_GRESET (1 << 2)/* Global reset */
+#define UHCI_USBCMD_CONFIGURE (1 << 6)/* config semaphore */
+#define UHCI_USBSTS_HALTED (1 << 5)/* HCHalted bit */
+
+#define OHCI_CONTROL 0x04
+#define OHCI_CMDSTATUS 0x08
+#define OHCI_INTRSTATUS0x0c
+#define OHCI_INTRENABLE0x10
+#define OHCI_INTRDISABLE 0x14
+#define OHCI_OCR (1 << 3)/* ownership change request */
+#define OHCI_CTRL_IR (1 << 8)/* interrupt routing */
+#define OHCI_INTR_OC (1 << 30) /* ownership change */
+
+#define EHCI_HCC_PARAMS0x08/* extended
capabilities
Re: [PATCH] speed up on find_first_bit for i386 (let compiler do the work)
> static inline int new_find_first_bit(const unsigned long *b, unsigned size)
> {
> int x = 0;
> do {
> unsigned long v = *b++;
> if (v)
> return __ffs(v) + x;
> if (x >= size)
> break;
> x += 32;
> } while (1);
> return x;
> }
Wait a minute... suppose that size == 32 and the bitmap is one word of all
zeros. Dynamic execution will overflow the buffer:
int x = 0;
unsigned long v = *b++; /* Zero */
if (v) /* False, v == 0 */
if (x >= size) /* False, 0 < 32 */
x += 32;
} while (1);
unsigned long v = *b++; /* Buffer overflow */
if (v) /* Random value, suppose non-zero */
return __ffs(v) + x;/* >= 32 */
That should be:
static inline int new_find_first_bit(const unsigned long *b, unsigned size)
int x = 0;
do {
unsigned long v = *b++;
if (v)
return __ffs(v) + x;
} while ((x += 32) < size);
return size;
}
Note that we assume that the trailing long is padded with zeros.
In truth, it should probably be either
static inline unsigned new_find_first_bit(u32 const *b, unsigned size)
int x = 0;
do {
u32 v = *b++;
if (v)
return __ffs(v) + x;
} while ((x += 32) < size);
return size;
}
or
static inline unsigned
new_find_first_bit(unsigned long const *b, unsigned size)
unsigned x = 0;
do {
unsigned long v = *b++;
if (v)
return __ffs(v) + x;
} while ((x += CHAR_BIT * sizeof *b) < size);
return size;
}
Do we actually store bitmaps on 64-bit machines with 32 significant bits
per ulong?
-
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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Jul 31, 2005, at 18:32:47, Pavel Machek wrote: and cpufreq is usefull to keep your desktop cold, too. But I don't want my desktop cold!!! That would ruin its usefulness as a 400W dorm space-heater!!! :-D *starts boinc client running in the background* Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - 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: revert yenta free_irq on suspend
Hi, > In general, I think that calling free_irq is the right behavior. > Although irqs changing after suspend is rare, there are also some > more serious issues. This has been discussed in the past, and a > summary is as follows: irqs actually isn't changed after suspend currently, it's a considering for future usage like hotplug. Calling free_irq actually isn't a complete ACPI issue, but ACPI requires it to solve nasty 'sleep in atomic' warning. You will find such break with swsusp without ACPI. Could we revert the ACPI change in Linus's tree but keep it in -mm tree? So we get a chance to fix drivers. Thanks, Shaohua - 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/
IBM HDAPS, I need a tip.
Hi Guys, I hope you all aren't sick about the topic. I have a quick question... Thanks to development of the driver from some nice guys, we are able to get data from the accelerometer. There is one problem. How do we calibrate the values that are outputed from the userspace? All PC's get a different value, and we can't really find the best solution. What is the scientific and smartest way to do this? i.e. of the driver output from the userspace. [EMAIL PROTECTED]:~/hdaps/hdaps-dave-0.02 $ ./ibm_hdaps_userspace /dev/ibm_hdaps x_accel: 409 y_accel: 528 temp: 47 temp2: 47 unknown: 7 If I move the PC 45 deg right.(Looking from front the left side is higher) km_activity (keybd) = 0 km_activity (mouse) = 0 x_accel: 396 y_accel: 579 temp: 47 temp2: 47 unknown: 7 The thing is, people have different values, and I think they are also different depending on where they are. Another question for this kernel inclusion (heh) Should we use Sysfs or should we use the userspace that outputs this data, else what is recomended? Thanks in advance, .Alejandro - 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/
GOT IT WORKING - Problem with SMP and NCCH-DL motherboard
Hi, In case anyone has the same problem I got it solved. I basically disabled everything that was on the motherboard such as the promise sata, sound, usb, etc. It then seemed to work except it choked on loading the AACRAID driver so I set the pci=usepirqmask and it then got it. I then tried reenabling USB and it gave the same problem again so I disabled the USB legacy support and left USB 2.0 on and tried again, this time it worked. Now why would USB legacy support prevent linux from detecting the other cpus and make it reboot? Not that I'm too worried about it but it might be something a kernel hacker might want to look at... Pedro Pedro Pla wrote: >Hi Again, > >I've done some further tests disabling hyperthreading which then lets me >disable apic on the motherboard and when I disable these I can boot a >kernel compiled with smp, however it boots detecting only 1 cpu rather >than the 2 on the motherboard. If I then reenable APIC in the bios with >hyperthreading still disabled it fails in the same way, so the problem >seems to be with APIC. Any ideas what more I can try? > >Thanks in advance!! >Pedro > >Pedro Pla wrote: > > > >>Hello, >> >>I'm running a system with an Asus NCCH-DL motherboard with dual Nocona >>Xeon 3.2 GHZ cpu's, when I boot the system with a single cpu kernel with >>acpi not compiled in it works fine, however when I try to boot a kernel >>with smp it gives a timeout detecting the cpus and then the machine >>reboots after I think trying to work out the irq tables, I say I think >>because it happens so fast that I can barely see what is on the screen >>before it reboots. >> >>I've tried recompiling the kernel with many different options both in >>and out and the only one that lets me boot is a single cpu without acpi, >>apic and hpet, I tried googling for similar problems but haven't been >>able to find anything that applies. I've also tried using an EM64T >>kernel in case it had to do with the Nocona being incompatible with smp >>in 32bit mode but that didn't seem to work and gave the same error. >> >>Is it a kernel problem or a hardware issue? I tried swapping cpu's in >>case one was broken but that didn't help, I also tried flashing the bios >>to the latest one from Asus in case there was some issue with that but >>no luck either. >> >>Also in case this is helpful in locating the problem, when I get it to >>boot a single cpu 2.6.12.1 kernel without acpi or apic I get the >>following errors with the PCI: >> >>NET: Registered protocol family 16 >>PCI: PCI BIOS revision 2.10 entry at 0xf1d30, last bus=4 >>PCI: Using configuration type 1 >>SCSI subsystem initialized >>PCI: Probing PCI hardware >>PCI: Probing PCI hardware (bus 00) >>PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 >>Boot video device is :01:00.0 >>PCI: Transparent bridge - :00:1e.0 >>PCI: Using IRQ router PIIX/ICH [8086/25a1] at :00:1f.0 >>PCI: IRQ 0 for device :00:1f.1 doesn't match PIRQ mask - try >>pci=usepirqmask >>PCI: Found IRQ 11 for device :00:1f.1 >>PCI: Cannot allocate resource region 0 of device :01:00.0 >> >>Any ideas or advice would be greatly appreciated. >> >>Best regards, >>Pedro >> >> >>- >>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/ >> >> >> >> >> > >- >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/ > > > - 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.13-rc3-mm3
On Thu, 2005-07-28 at 02:58 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/ I'm seeing a problem on ARM with -rc3-mm3 and -rc4-mm1. -rc3-mm2 and -rc4 are fine and looking for the problem reveals the problems start after these patches are applied: > +page-fault-patches-optional-page_lock-acquisition-in.patch > +page-fault-patches-optional-page_lock-acquisition-in-tidy.patch The system appears to be ok and boots happily to a console but if you load any graphical UI, the screen will blank and the process stops working (tested with opie and and xserver+GPE). You can kill -9 the process but you can't regain the console without a suspend/resume cycle which performs enough of a reset to get it back. chvt and the console switching keys don't respond. I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it makes no difference. Richard - 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: revert yenta free_irq on suspend
On Mon, 1 Aug 2005, Dave Airlie wrote: > > You said earlier we only should fix drivers that need fixing, but they > all need fixing I think you're still talking from a theoretical standpoing, while all my arguments are practical. In _practice_, I hope that (a) we don't see that very much (ie the people for whom things work already are a strong argument that this is less of a problem in practice than people try to make it appear) (b) drivers, _especially_ on notebooks, are already able to handle an incoming interrupt with the device in D3 state and returning 0xff for all reads. In particular, this is exactly the same thing that you get on a surprise device removal too. iow it really _really_ shouldn't matter that a shared interrupt comes in after (or before) a device has gone to sleep. Because a driver that can't handle that schenario is buggy for totally unrelated reasons, and doing a "free_irq()/request_irq()" pair at suspend time is _not_ the solution! > I'm trying to see which way they should be fixed, either the PM people > say we need request/free irq pairs or say we need to put support code in > the interrupt handlers, And I say that's not true. See (b) above. As far as I can tell, the "interrupt when in D3" really looks _exactly_ the same as "interrupt when device was just removed by the user", and nobody will hopefully argue that free_irq/request_irq can protect against forced removal? > This has nothing to do with the issues with highlevel PM interfaces > for shutting down hardware, this is do with fixing the drivers in the > kernel currently and what the correct way to do it is without breaking > someone elses hardware ... and I don't think this has _anything_ to do with free_irq/request_irq, and everything to do with the fact that we can try to make at least the common drivers "hardened" for unexpected interrupts coming in when the hw might not be ready for them. Linus - 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] sonypi, kernel 2.6.12.3
Newer Sony VAIO models (VGN-S480, VGN-S460, VGN-S3XP etc) use a new method to
initialize the SPIC device. The new way to initialize (and disable) the device
comes directly from the AML code in the _CRS, _SRS and _DIS methods from the
DSDT table. This patch against 2.6.12.3 adds support for the new models.
-- Erik Waling <[EMAIL PROTECTED]>
--- linux-2.6.12.3/drivers/char/sonypi.c2005-07-15 16:18:57.0
-0500
+++ linux/drivers/char/sonypi.c 2005-07-31 16:55:41.0 -0500
@@ -98,12 +98,13 @@
#define SONYPI_DEVICE_MODEL_TYPE1 1
#define SONYPI_DEVICE_MODEL_TYPE2 2
+#define SONYPI_DEVICE_MODEL_TYPE3 3
/* type1 models use those */
#define SONYPI_IRQ_PORT0x8034
#define SONYPI_IRQ_SHIFT 22
-#define SONYPI_BASE0x50
-#define SONYPI_G10A(SONYPI_BASE+0x14)
+#define SONYPI_TYPE1_BASE 0x50
+#define SONYPI_G10A(SONYPI_TYPE1_BASE+0x14)
#define SONYPI_TYPE1_REGION_SIZE 0x08
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
@@ -114,6 +115,13 @@
#define SONYPI_TYPE2_REGION_SIZE 0x20
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
+/* type3 series specifics */
+#define SONYPI_TYPE3_BASE 0x40
+#define SONYPI_TYPE3_GID2 (SONYPI_TYPE3_BASE+0x48) /* 16 bits */
+#define SONYPI_TYPE3_MISC (SONYPI_TYPE3_BASE+0x6d) /* 8 bits */
+#define SONYPI_TYPE3_REGION_SIZE 0x20
+#define SONYPI_TYPE3_EVTYPE_OFFSET 0x12
+
/* battery / brightness addresses */
#define SONYPI_BAT_FLAGS 0x81
#define SONYPI_LCD_LIGHT 0x96
@@ -159,6 +167,10 @@
{ 0x0, 0x0 }
};
+/* same as in type 2 models */
+static struct sonypi_ioport_list *sonypi_type3_ioport_list =
+ sonypi_type2_ioport_list;
+
/* The set of possible interrupts */
struct sonypi_irq_list {
u16 irq;
@@ -180,6 +192,9 @@
{ 0, 0x00 }/* no IRQ, 0x00 in SIRQ in AML */
};
+/* same as in type2 models */
+static struct sonypi_irq_list *sonypi_type3_irq_list = sonypi_type2_irq_list;
+
#define SONYPI_CAMERA_BRIGHTNESS 0
#define SONYPI_CAMERA_CONTRAST 1
#define SONYPI_CAMERA_HUE 2
@@ -223,6 +238,7 @@
#define SONYPI_MEYE_MASK 0x0400
#define SONYPI_MEMORYSTICK_MASK0x0800
#define SONYPI_BATTERY_MASK0x1000
+#define SONYPI_WIRELESS_MASK 0x2000
struct sonypi_event {
u8 data;
@@ -305,6 +321,13 @@
{ 0, 0 }
};
+/* The set of possible wireless events */
+static struct sonypi_event sonypi_wlessev[] = {
+ { 0x59, SONYPI_EVENT_WIRELESS_ON },
+ { 0x5a, SONYPI_EVENT_WIRELESS_OFF },
+ { 0, 0 }
+};
+
/* The set of possible back button events */
static struct sonypi_event sonypi_backev[] = {
{ 0x20, SONYPI_EVENT_BACK_PRESSED },
@@ -391,6 +414,12 @@
{ SONYPI_DEVICE_MODEL_TYPE2, 0x41, SONYPI_BATTERY_MASK,
sonypi_batteryev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x31, SONYPI_PKEY_MASK, sonypi_pkeyev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0, 0x, sonypi_releaseev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x21, SONYPI_FNKEY_MASK, sonypi_fnkeyev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x31, SONYPI_WIRELESS_MASK, sonypi_wlessev
},
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x31, SONYPI_MEMORYSTICK_MASK,
sonypi_memorystickev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x41, SONYPI_BATTERY_MASK,
sonypi_batteryev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x31, SONYPI_PKEY_MASK, sonypi_pkeyev },
{ 0 }
};
@@ -558,6 +587,23 @@
udelay(10);
}
+static void sonypi_type3_srs(void)
+{
+ u16 v16;
+ u8 v8;
+
+ /* This model type uses the same initialiazation of
+* the embedded controller as the type2 models. */
+ sonypi_type2_srs();
+
+ /* Initialization of PCI config space of the LPC interface bridge. */
+ v16 = (sonypi_device.ioport1 & 0xFFF0) | 0x01;
+ pci_write_config_word(sonypi_device.dev, SONYPI_TYPE3_GID2, v16);
+ pci_read_config_byte(sonypi_device.dev, SONYPI_TYPE3_MISC, );
+ v8 = (v8 & 0xCF) | 0x10;
+ pci_write_config_byte(sonypi_device.dev, SONYPI_TYPE3_MISC, v8);
+}
+
/* Disables the device - this comes from the AML code in the ACPI bios */
static void sonypi_type1_dis(void)
{
@@ -582,6 +628,13 @@
printk(KERN_WARNING "ec_write failed\n");
}
+static void sonypi_type3_dis(void)
+{
+ sonypi_type2_dis();
+ udelay(10);
+ pci_write_config_word(sonypi_device.dev, SONYPI_TYPE3_GID2, 0);
+}
+
static u8 sonypi_call1(u8 dev)
{
u8 v1, v2;
@@ -1066,10 +1119,17 @@
static void sonypi_enable(unsigned int camera_on)
{
- if (sonypi_device.model == SONYPI_DEVICE_MODEL_TYPE2)
- sonypi_type2_srs();
- else
+ switch (sonypi_device.model) {
+ case SONYPI_DEVICE_MODEL_TYPE1:
Re: 2.6.13-rc4-mm1
Jesus Delgado <[EMAIL PROTECTED]> wrote: > > Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems > is the boot hang: >my test is different combinations the acpi=off , noacpi, pci=noirq, > etc.etc both have is the same error not boot. > > The only information is simple: > > .. > > Uncompressiong Linux... Ok. booting the kernel. > _ > > Not more information. You should check basic .config things such as the CPU type. Also ensure that you have `earlyprintk=vga' on the kernel boot command line. The only thing I can think of which would cause such an early failure is the kexec changes. Does 2.6.13-rc1 work OK? It had kexec. If 2.6.13-rc1 fails then please try these patches, against 2.6.12: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.12-git7.gz ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.12-git8.gz If 2.6.12-git7 works and 2.6.12-git8 fails then we'll know where to start looking, 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/
spca5xx webcam driver not compiling on 2.6.13-rc4-RT-V0.7.52-07
the spca5xx webcam driver module compiles/installs/runs fine (a few
compilation warnings, but nothing much) on vanilla 2.6.x kernels, but
won't succeed on one patched with ingo's realtime pre-emption patches.
*
[EMAIL PROTECTED] spca5xx-20050701]# make
Building SPCA5XX driver for 2.5/2.6 kernel.
Remember: you must have read/write access to your kernel source tree.
make -C /lib/modules/`uname -r`/build
SUBDIRS=/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701
modules
make[1]: Entering directory
`/home/mrmachine/my_documents/applications/linux/system+admin/linux-2.6.12'
CC [M]
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/spca5xx.o
In file included from
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/spca5xx.c:763:
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/mr97311.h:
In function `pcam_start':
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/mr97311.h:391:
warning: ISO C90 forbids mixed declarations and code
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/spca5xx.c:
In function `spca5xx_probe':
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/spca5xx.c:8663:
error: `SPIN_LOCK_UNLOCKED' undeclared (first use in this function)
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/spca5xx.c:8663:
error: (Each undeclared identifier is reported only once
/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/spca5xx.c:8663:
error: for each function it appears in.)
make[2]: ***
[/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701/drivers/usb/spca5xx.o]
Error 1
make[1]: ***
[_module_/home/mrmachine/my_documents/applications/linux/video/spca5xx-20050701]
Error 2
make[1]: Leaving directory
`/home/mrmachine/my_documents/applications/linux/system+admin/linux-2.6.12'
make: *** [default] Error 2
**
all the warnings up to the error occur on a vanilla kernel compilation,
but installs anyway ... i know "SPIN_LOCK_UNLOCKED" has something to do
with ingo's patch, so i emailed the spca5xx author to see if he knew
what to do:
Shayne,
Try to change 'SPIN_LOCK_UNLOCKED' by some thing to initialize the spin :)
regards
i'm guessing it's these lines in spca5xx.c that i have to change:
*
if (!spca50x_configure (spca50x))
{
spca50x->user = 0;
init_MUTEX (>lock); /* to 1 == available */
init_MUTEX (>buf_lock);
spca50x->v4l_lock = SPIN_LOCK_UNLOCKED;
spca50x->buf_state = BUF_NOT_ALLOCATED;
}
else
{
err ("Failed to configure camera");
goto error;
}
i've looked through the archives for some clue as to what to change it
to, but being a bit on the newbie side, haven't had any luck ...
please CC me on any replies!
thanx
shayne
-
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: realtime-preempt-2.6.13-rc4-RT-V0.7.52-07
Daniel Walker wrote: You can resolve it if you enable SMP . Daniel thanx - that's done it. shayne On Mon, 2005-08-01 at 08:18 +1000, Shayne O'Connor wrote: trying to compile 2.6.13.rc4 with ingo's RT patch (realtime-preempt-2.6.13-rc4-RT-V0.7.52-07) but keep getting this error near the end of compilation: GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o(.text+0x2220c): In function `rt_check_expire': : undefined reference to `__bad_spinlock_type' net/built-in.o(.text+0xe): In function `rt_check_expire': : undefined reference to `__bad_spinlock_type' net/built-in.o(.text+0x22321): In function `rt_run_flush': : undefined reference to `__bad_spinlock_type' net/built-in.o(.text+0x22339): In function `rt_run_flush': : undefined reference to `__bad_spinlock_type' net/built-in.o(.text+0x22593): In function `rt_garbage_collect': : undefined reference to `__bad_spinlock_type' net/built-in.o(.text+0x225c1): more undefined references to `__bad_spinlock_type' follow make: *** [.tmp_vmlinux1] Error 1 [EMAIL PROTECTED] linux-2.6.12]$ i am trying to compile it with PREEMPT_DESKTOP (please CC me on any replies!) shayne - 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/ - 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: revert yenta free_irq on suspend
> On Mon, 1 Aug 2005, Dave Airlie wrote: > > > > That still doesn't handle the case where a device has an interrupt > > handler on a shared IRQ and another device on the chain interrupts it > > after it has suspended its device, > > I don't know why people bother arguing about this. Face the facts: we have > to do things incrementally. Any design that breaks unmodified drivers is > by _definition_ broken. You can't fix all drivers, and anybody who starts > their arguments with "we should just fix drivers" is living in la-la-land. > > I'm not arguing at all I agree with you, but I think you are missing the point I'm trying to make, You said earlier we only should fix drivers that need fixing, but they all need fixing, I'm trying to see which way they should be fixed, either the PM people say we need request/free irq pairs or say we need to put support code in the interrupt handlers, I fail to see how I can fix this very well incrementally, on my hardware I have a yenta, my patch fixes it to work, on Hughs hardware he has his yenta sharing IRQs with another driver which doesn't do the request/free and it breaks, it isn't the yenta drivers fault the other driver causes the issue, so therefore in order to apply the yenta fix I need to go around and fix all the other drivers that might share an interrupt with it before I can get patch accepted so that I don't break someones machine? this is irrelevant to whether the ACPI link change is in or not, adding the request/free pairs to one driver can show up issues in other drivers that share that IRQ.. This has nothing to do with the issues with highlevel PM interfaces for shutting down hardware, this is do with fixing the drivers in the kernel currently and what the correct way to do it is without breaking someone elses hardware Dave. - 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: inter_module_get and __symbol_get
On Sul, 2005-07-31 at 00:27 -0400, D. ShadowWolf wrote: > On this topic I have to weigh in that I just subscribed to the kernel list > because I have had to undo a modification made to the kernel around version > 2.6.10 that stopped the export of 'inter_module_get'. To me it appears that > some kernel developers forget that there are those of us out there who do not > have broadband connections and are shafted with low-end hardware. inter_module_* are going away. It was always a badly designed interface and the new module code no longer requires it. 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/
Re: 2.6.13-rc4-mm1
Hi all: Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems is the boot hang: my test is different combinations the acpi=off , noacpi, pci=noirq, etc.etc both have is the same error not boot. The only information is simple: .. Uncompressiong Linux... Ok. booting the kernel. _ Not more information. anex dmesg the kernel 2.6.12-ck3. Linux version 2.6.12-ck3 ([EMAIL PROTECTED] (gcc version 4.0.1 20050720 (Red Hat 4.0.1-4)) #1 Mon Jul 25 00:14:40 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 4fef (usable) BIOS-e820: 4fef - 4fefb000 (ACPI data) BIOS-e820: 4fefb000 - 4ff0 (ACPI NVS) BIOS-e820: 4ff0 - 5000 (reserved) BIOS-e820: fffe - 0001 (reserved) 382MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 327408 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 98032 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f8410 ACPI: RSDT (v001 Arima 161Fh0x0604 LTP 0x) @ 0x4fef6b5d ACPI: FADT (v001 Arima 161Fh0x0604 PTL_ 0x000f4240) @ 0x4fefae66 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x4fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x4fefafb0 ACPI: DSDT (v001 Arima 161Fh0x0604 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x4008 Allocating PCI resources starting at 5000 (gap: 5000:affe) Built 1 zonelists Kernel command line: ro root=LABEL=/ early-login quiet vga=788 Initializing CPU#0 CPU 0 irqstacks, hard=c047 soft=c046f000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1804.747 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1292408k/1309632k available (2620k kernel code, 16076k reserved, 680k data, 188k init, 392128k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3571.71 BogoMIPS (lpj=1785856) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff e1d3fbff CPU: After vendor identify, caps: 078bfbff e1d3fbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: After all inits, caps: 078bfbff e1d3fbff 0010 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Mobile AMD Athlon(tm) 64 Processor 3000+ stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0400 (from 0e00) checking if image is initramfs... it is Freeing initrd memory: 1086k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd8cc, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *9, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 23) *11, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *10, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *10, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *9 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 11 12 14 15) *10 ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: Embedded Controller [EC] (gpe 1) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 8 devices usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:05: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:05: ioport range 0xf510-0xf511 could not be reserved pnp: 00:05: ioport range 0xf500-0xf500 has been reserved pnp: 00:05: ioport range 0x4000-0x407f could not be reserved pnp: 00:05: ioport range 0x8100-0x811f has been reserved apm: BIOS
Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)
On Sad, 2005-07-30 at 22:36 +0100, Russell King wrote: > Since PCMCIA cards are detected and drivers bound at boot time, we no > longer get hotplug events to setup networking for PCMCIA network cards > already inserted. Consequently, if you are relying on /sbin/hotplug to > setup your PCMCIA network card at boot time, triggered by the cardmgr > startup binding the driver, it won't happen. So eth0 now randomly changes between on board and PCMCIA depending upon whether the PCMCIA card was inserted or not, and your disks re-order themselves in the same situation. That'll be funny if anyone does a mkswap to share their swap between Linux and Windows. Gosh look there goes the root partition. I'm hoping thats not what you are implying. Especially for disks, network is much much less of an 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: Drivers for Ricoh SD Card Reader
On Iau, 2005-07-28 at 13:08 +0200, Tomàs Núñez Lirola wrote: > Obviously, this answer is useless, but I don't know what to do now... Do > you know if Ricoh has released specs before? Do you think IBM should have > them? > > What would you do in my place? Which should be the next step? IBM like to be Linux friendly when its in their interest, not always merely when its in yours. Thinkpads can be really problematic in this area. SD is even messier because SD is supposed to be very proprietary and secret and other such garbage. Intel have published enough that where the low level h/w interface is known we can do SD. I'd say the chances of you gettig the SD on the thinkpad working are probably very low unless its connected via the internal USB 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/
kernels 2.6.13-rc4 and 2.6.13-rc4-mm1 boot hang in laptop emachines M6897
Hi all: Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems is the boot hang: my test is different combinations the acpi=off , noacpi, pci=noirq, etc.etc both have is the same error not boot. The only information is simple: .. Uncompressiong Linux... Ok. booting the kernel. _ Not more information. anex dmesg the kernel 2.6.12-ck3. Linux version 2.6.12-ck3 ([EMAIL PROTECTED] (gcc version 4.0.1 20050720 (Red Hat 4.0.1-4)) #1 Mon Jul 25 00:14:40 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 4fef (usable) BIOS-e820: 4fef - 4fefb000 (ACPI data) BIOS-e820: 4fefb000 - 4ff0 (ACPI NVS) BIOS-e820: 4ff0 - 5000 (reserved) BIOS-e820: fffe - 0001 (reserved) 382MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 327408 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 98032 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f8410 ACPI: RSDT (v001 Arima 161Fh0x0604 LTP 0x) @ 0x4fef6b5d ACPI: FADT (v001 Arima 161Fh0x0604 PTL_ 0x000f4240) @ 0x4fefae66 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x4fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x4fefafb0 ACPI: DSDT (v001 Arima 161Fh0x0604 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x4008 Allocating PCI resources starting at 5000 (gap: 5000:affe) Built 1 zonelists Kernel command line: ro root=LABEL=/ early-login quiet vga=788 Initializing CPU#0 CPU 0 irqstacks, hard=c047 soft=c046f000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1804.747 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1292408k/1309632k available (2620k kernel code, 16076k reserved, 680k data, 188k init, 392128k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3571.71 BogoMIPS (lpj=1785856) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff e1d3fbff CPU: After vendor identify, caps: 078bfbff e1d3fbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: After all inits, caps: 078bfbff e1d3fbff 0010 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Mobile AMD Athlon(tm) 64 Processor 3000+ stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0400 (from 0e00) checking if image is initramfs... it is Freeing initrd memory: 1086k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd8cc, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *9, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 23) *11, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *10, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *10, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *9 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 11 12 14 15) *10 ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: Embedded Controller [EC] (gpe 1) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 8 devices usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:05: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:05: ioport range 0xf510-0xf511 could not be reserved pnp: 00:05: ioport range 0xf500-0xf500 has been reserved pnp: 00:05: ioport range 0x4000-0x407f could not be reserved pnp: 00:05: ioport range 0x8100-0x811f has been reserved apm: BIOS
Re: "seeing minute plus hangs during boot" - 2.6.12 and 2.6.13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg KH wrote:
Now, I'm thinking it could be something like the udev hang which
disapeared with udev update to 058.
I don't know what can be happening. I think it is because of some type
of timeout.
If you think there is something else I can do, please let me know.
>>>
>>>
>>>Greg said in another thread: "older versions of udev (< 058) can work
>>>_really slow_ with 2.6.12. Please upgrade your version of udev and see if
>>>that solves the issue or not.".
>>>
>>>What version are you running? Looks like 058, yes?
>>
>>
>>Yeap. It is 058.
>
>
> Hm, odd. Well, as this is a udev issue, care to try 064? We've fixed a
> lot of little bugs since 058 that might have caused this.
>
> thanks,
>
Hi Greg.
No luck. I installed 0.64 and I get the same hang on mounting
filesystems message.
Here is what I get with dmesg with 0.64:
dmesg
4 (L-TLB)
df56bf98 0046 df56bf88 0002 0001 c0476004 df56a000 c012f2dd
c03a9380 c03a9480 c13fd020 c13fd04c c012335b
c13fb520
0001 0971 2d819d9f c146e520 c146a020 c146a148
0246
Call Trace:
[] rcu_process_callbacks+0x5d/0x69
[] tasklet_action+0x63/0xc2
[] ksoftirqd+0xc0/0xc2
[] ksoftirqd+0x0/0xc2
[] kthread+0xba/0xf0
[] kthread+0x0/0xf0
[] kernel_thread_helper+0x5/0xb
events/0 R running 0 6 1 7 5 (L-TLB)
events/1 S 0002 0 7 1 8 6 (L-TLB)
df47bf38 0046 df47bf28 0002 0001 c0126abd c13fbf60 c13fd118
0286 0001 df503a00 01f5 df503aa4 df503aa0
c13fb520
0001 0ccd 0df51400 0003 c146e520 df595a20 df595b48
0082
Call Trace:
[] __mod_timer+0xa9/0xc3
[] worker_thread+0x15d/0x264
[] cache_reap+0x0/0x1e1
[] default_wake_function+0x0/0x12
[] default_wake_function+0x0/0x12
[] worker_thread+0x0/0x264
[] kthread+0xba/0xf0
[] kthread+0x0/0xf0
[] kernel_thread_helper+0x5/0xb
khelper S 0002 0 8 1 9 7 (L-TLB)
df573f38 0046 df573f24 0002 0001 0001 c17b7de8 0001
df573f10 df301520 c13f3520 df301520 c13fbe80
c13fb520
0001 0204 17a8ee41 0002 df301520 df6cf520 df6cf648
0001
Call Trace:
[] worker_thread+0x15d/0x264
[] __call_usermodehelper+0x0/0x61
[] default_wake_function+0x0/0x12
[] default_wake_function+0x0/0x12
[] worker_thread+0x0/0x264
[] kthread+0xba/0xf0
[] kthread+0x0/0xf0
[] kernel_thread_helper+0x5/0xb
kthread S 0002 0 9 112 147 8 (L-TLB)
df5bdf38 0046 df5bdf28 0002 0001 0001 df393f40 0001
df5bdf10 c0119b91 df42a020 0003 df59f824 df59f820
c13fb520
0001 019f f4136c6b c146e520 df595520 df595648
0082
Call Trace:
[] __wake_up_common+0x3f/0x5e
[] worker_thread+0x15d/0x264
[] keventd_create_kthread+0x0/0x71
[] default_wake_function+0x0/0x12
[] default_wake_function+0x0/0x12
[] worker_thread+0x0/0x264
[] kthread+0xba/0xf0
[] kthread+0x0/0xf0
[] kernel_thread_helper+0x5/0xb
kacpidS 0002 012 9 101 (L-TLB)
df5bff38 0046 df5bff28 0002 0002 df507e8c c147cd40
df507e80 df473a00 df473a24 df473a20
c13f3520
1003 46a6eae8 0001 c03a4bc0 df6cf020 df6cf148
0082
Call Trace:
[] worker_thread+0x15d/0x264
[] acpi_os_execute_deferred+0x0/0x1b
[] default_wake_function+0x0/0x12
[] default_wake_function+0x0/0x12
[] worker_thread+0x0/0x264
[] kthread+0xba/0xf0
[] kthread+0x0/0xf0
[] kernel_thread_helper+0x5/0xb
kblockd/0 S 0002 0 101 9 10212 (L-TLB)
c1605f38 0046 c1605f24 0002 0002 052afe93
0001 df69ba20 c13fb520 df69ba20 c13f3e80
c13f3520
0171 052b5d95 df69ba20 df595020 df595148
0002
Call Trace:
[] worker_thread+0x0/0x264
[] worker_thread+0x15d/0x264
[] default_wake_function+0x0/0x12
[] default_wake_function+0x0/0x12
[] worker_thread+0x0/0x264
[] kthread+0xba/0xf0
[] kthread+0x0/0xf0
[] kernel_thread_helper+0x5/0xb
kblockd/1 S 0002 0 102 9 145 101 (L-TLB)
c1607f38 0046 c1607f28 0002 0001 052b66d1
0001 0100 c047fd4c
c13fb520
0001 0174 052b992c c146e520 df69ba20 df69bb48
df69be94
Call Trace:
[] worker_thread+0x0/0x264
[] worker_thread+0x15d/0x264
[] default_wake_function+0x0/0x12
[] default_wake_function+0x0/0x12
[] worker_thread+0x0/0x264
[] kthread+0xba/0xf0
[] kthread+0x0/0xf0
[] kernel_thread_helper+0x5/0xb
pdflush S 0002 0 145 9 146 102 (L-TLB)
c1609f78 0046 c1609f64 0002 0002 c13fbe80 0001 c1609f38
df5956e0 df69b520 c13fb520 df69b520
Re: revert yenta free_irq on suspend
On Mon, 1 Aug 2005, Dave Airlie wrote: > > That still doesn't handle the case where a device has an interrupt > handler on a shared IRQ and another device on the chain interrupts it > after it has suspended its device, I don't know why people bother arguing about this. Face the facts: we have to do things incrementally. Any design that breaks unmodified drivers is by _definition_ broken. You can't fix all drivers, and anybody who starts their arguments with "we should just fix drivers" is living in la-la-land. Anyway. My original PM suggestion handled that case perfectly well. The rule was to make "go to sleep" be a two-phase operation: - phase 1: save state, and possibly return errors - phase 2: turn off where the second stage was done with interrupts disabled and atomically. And the first phase was done without actually changing the state of the device at all (so that if some device said "I can't do that, Dave", there is no need to go back and wake anything up at all), and we could allocate memory freely, because the disk was still working etc etc. For some totally inexplicable reason, the PM people never liked this, and ended up doing a single "power off" setup. Which was always known to be broken, and caused tons of problems, like the fact that save-to-disk had to wake up a device that had already been shut off etc. So the fact that the PM layer was "simplified" to a single-phase setup causes a lot of problems, but hey, stupid is as stupid does. I've given up worrying about what crazy things the PM list comes up with, and instead I now have a hard rule: a patch that breaks some machine gets reverted. Is that too hard to understand? I'll repeat it again: A patch that breaks some machine gets reverted. and maybe somebody on the PM list will one day understand what it means to have slow and steady progress instead of dicking around with the idea of the week. Linus - 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: Fw: sigwait() breaks when straced
> > However, there is in fact no bug here. The test program is just wrong. > sigwait returns zero or an error number, as POSIX specifies. Conversely, > sigtimedwait and sigwaitinfo either return 0 or set errno and return -1. > It is odd that the interfaces of related functions differ in this way, > but they do. The someone should fix the manpage, it explicitly says "The sigwait function never returns an error." Which is clearly wrong if it can return EINTR... Dave. - 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: revert yenta free_irq on suspend
Dave Jones wrote: > On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote: > > > gringo:~ # fdisk -l /dev/hda > > > > Disk /dev/hda: 80.0 GB, 80026361856 bytes > > 255 heads, 63 sectors/track, 9729 cylinders > > Units = cylinders of 16065 * 512 = 8225280 bytes > > > >Device Boot Start End Blocks Id System > > /dev/hda11 244 1959898+ 83 Linux > > /dev/hda2 245 488 1959930 82 Linux swap / Solaris > > /dev/hda3 489 732 1959930 82 Linux swap / Solaris > > /dev/hda4 733 972972268402+ 5 Extended > > /dev/hda5 733 976 1959898+ 82 Linux swap / Solaris > > /dev/hda6 977 972970308441 88 Linux plaintext (*) > > > > (*) dm-crypt :-) > > Your swap partitions are outside of your lv's. Right, then this could be the problem you encountered. However the swap partitions are set up with dm-crypt including the partition I do resume from so I'm using device mapper to resume which is quite close to LVM. -- Andreas Steinmetz SPAMmers use [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: revert yenta free_irq on suspend
On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote: > gringo:~ # fdisk -l /dev/hda > > Disk /dev/hda: 80.0 GB, 80026361856 bytes > 255 heads, 63 sectors/track, 9729 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > >Device Boot Start End Blocks Id System > /dev/hda11 244 1959898+ 83 Linux > /dev/hda2 245 488 1959930 82 Linux swap / Solaris > /dev/hda3 489 732 1959930 82 Linux swap / Solaris > /dev/hda4 733 972972268402+ 5 Extended > /dev/hda5 733 976 1959898+ 82 Linux swap / Solaris > /dev/hda6 977 972970308441 88 Linux plaintext (*) > > (*) dm-crypt :-) Your swap partitions are outside of your lv's. Dave - 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: Fw: sigwait() breaks when straced
The problem is not really "when straced", but when strace attaches. In fact, it's not even "when PTRACE_ATTACH'd". It's actually the implicit SIGSTOP that PTRACE_ATTACH causes. If you simply suspend and resume the program (with SIGSTOP or C-z), you get the same result. So this report is more properly identified as "signal stop breaks sigwait". However, there is in fact no bug here. The test program is just wrong. sigwait returns zero or an error number, as POSIX specifies. Conversely, sigtimedwait and sigwaitinfo either return 0 or set errno and return -1. It is odd that the interfaces of related functions differ in this way, but they do. Thanks, Roland - 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: revert yenta free_irq on suspend
Dave Jones wrote: > On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote: > > > But that believe would be total fantasy -- supsend/resume is not > > working on a large number of machines, and no distro is currently > > able to support it. (I'm talking about S3 suspend to RAM primarily, > > suspend to disk is less interesting -- though Red Hat doesn't > > even support _that_) > > After the 'swsusp works just fine' lovefest at OLS, I spent a little > while playing with the current in-tree swsusp implementation last week. > > The outcome: I'm no more enthusiastic about enabling this in Red Hat > kernels than I ever was before. It seems to have real issues with LVM > setups (which is default on Red Hat/Fedora installs these days). > After convincing it where to suspend/resume from by feeding it > the major/minor of my swap partition, it did actually seem > to suspend. And resume (though it did spew lots of 'sleeping whilst > atomic warnings, but thats trivial compared to whats coming up next). > > I rebooted, and fsck found all sorts of damage on my / partition. > After spending 30 minutes pressing 'y', to fix things up, it failed > to boot after lots of files were missing. > Why it wrote anything to completely different lv to where I told it > (and yes, I did get the major:minor right) I have no idea, but > as it stands, it definitly isn't production-ready. > > I'll look into it again sometime soon, but not until after I've > reinstalled my laptop. (I'm just thankful I had the sense not to > try this whilst I was at OLS). Hmm, I'm using swsusp on my x86_64 laptop with lvm and dm-crypt. Works just fine except for nasty spontaneous reboots from time to time caused by yenta_socket (I do get these since I started to access my pcmcia flash disk from initrd to retrieve the dm-crypt swap key). It does work since at least 2.6.11 up to 2.6.13-rc4 and if the yenta_socket caused spontaneous reboots after resume could be fixed I'd call it production ready. gringo:~ # fdisk -l /dev/hda Disk /dev/hda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda11 244 1959898+ 83 Linux /dev/hda2 245 488 1959930 82 Linux swap / Solaris /dev/hda3 489 732 1959930 82 Linux swap / Solaris /dev/hda4 733 972972268402+ 5 Extended /dev/hda5 733 976 1959898+ 82 Linux swap / Solaris /dev/hda6 977 972970308441 88 Linux plaintext (*) (*) dm-crypt :-) gringo:~ # vgdisplay --- Volume group --- VG Name rootvg System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 27 VG Access read/write VG Status resizable MAX LV0 Cur LV8 Open LV 8 Max PV0 Cur PV1 Act PV1 VG Size 67.05 GB PE Size 4.00 MB Total PE 17165 Alloc PE / Size 14464 / 56.50 GB Free PE / Size 2701 / 10.55 GB VG UUID oHluq0-H5Nd-90dU-psLn-ygNT-u4GJ-D8aJhG All filesystems are ext3 as I did have nasty experiences with reiserfs on lvm+raid on another 2.6 system without ever using swsusp there. -- Andreas Steinmetz SPAMmers use [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: revert yenta free_irq on suspend
> > If an interrupt is screaming due to lack of initialization and gets turned > off, just make sure it gets re-enabled when it is being initialized. > That still doesn't handle the case where a device has an interrupt handler on a shared IRQ and another device on the chain interrupts it after it has suspended its device, we need to either fix *for all drivers* (otherwise people sharing IRQs will have breakages that people not sharing them won't see ... ) a) add request/free irq sets b) add code to the interrupt handlers to make sure we aren't in a powerdown state... I don't really mind which is the recommended one I'd just prefer we do it the same way everwhere... so I still believe the yenta_irq patch is correct if we are doing a, or if not we need to do b Dave. - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Mon, 2005-08-01 at 01:29 +0200, Pavel Machek wrote: > Hi! > > > > I'm pretty sure at least one distro will go with HZ<300 real soon now > > > ;-). > > > > > > > Any idea what their official recommendation for people running apps that > > require the 1ms sleep resolution is? Something along the lines of "Get > > bent"? > > So you busy wait for 1msec, big deal. Which requires changing all those apps. I thought we tried not to break userspace with minor kernel version upgrades. > Some machines can't even keep time properly with HZ=1000. If your workaround for broken hardware involves screwing over people with good hardware, it might be the wrong workaround. > Official recommendation is likely "help us > with CONFIG_NO_IDLE_HZ" or "get over it". IOW, "if you don't like it, get another distro, or compile your own kernel". Lee - 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: [git patches] net driver fixes
On Sun, 31 Jul 2005, Jeff Garzik wrote: > > Please pull from the 'upstream-fixes' branch of > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git > > to obtain the fixes described in the attached diffstat/changelog/patch. Could you please try to edit the emails you apply to something prettier than this: [PATCH] Fix OMAP specific typo in smc91x.h --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeff, Here's a little patch fixing a typo in smc91x.h. Regards, Tony --ReaqsoxgOBHFXBhH Content-Type: text/x-chdr; charset=us-ascii Content-Disposition: inline; filename="patch-fix-typo-smc91x.h" Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> Ugh. It's not like we want people saying "Hi there" in our changelogs. Linus - 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Sun, 31 Jul 2005 13:42:45 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > Booting linux-2.6.13-rc4 with the "usb-handoff" option gives me > > a working keyboard everytime now. > > But 2.6.12 did not require this workaround, yes? > I still have linux-2.6.12.3 on my machine and the "usb-handoff" option fixes things for that version also. Linux-2.6.12.3 does need this option with my hardware. Frank Peters - 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: revert yenta free_irq on suspend
On Mon, 1 Aug 2005, Pavel Machek wrote: > > > > Why do it _ever_? There is _zero_ upside to doing it, I don't see why you > > want to. > > Being able to turn off your soundcard at runtime when you are not > using it was one of examples... I meant the "ACPI restores irq controller state" thing. Just leave it in. There's never any downside. If all the drivers end up doing free_irq/request_irq(), restoring the irq controller state still won't have any negative effect, and it solves the case where you have drivers that don't do it. > > Just make ACPI restore the dang thing. It's the right thing to do. > > Requires interpretter running with interrupts disabled => ugly :-(. I don't see that. What's ugly? I agree that ACPI is ugly, but I do _not_ agree that it's ugly to restore irq controller state with interrupts disabled. It MakesSense(tm) to do so. The fact that ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry obviously makes running it at _any_ point pretty damn ugly. And the fact that MB vendors don't test it with anything else than Windows (and sometimes you wonder whether they do even that) doesn't help. So hell yes, it's ugly, and nasty. But interrupts disabled has nothing to do with any of it. Besides, there's no real reason why you'd even have to do it with interrupts disabled. I personally think that it makes _sense_ to try to restore the irq controller state with irq's off, but as I made clear earlier in this flame-fest, there's no real reason why you couldn't just run with interrupts on. If an interrupt is screaming due to lack of initialization and gets turned off, just make sure it gets re-enabled when it is being initialized. Linus - 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/
that sk98lin suspend/resume patch
hello, i run 2.6.13-rc4-git2, and i am experiencing problems with sk98lin, suddenly it just stops working, and i need to reboot to get network up again, does this fix 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 patch] libata fix
Please pull from the 'upstream-fixes' branch of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git to obtain the damnable-annoying[1] fix described in the attached diffstat/changelog/patch. Jeff [1] the option is truly a boolean, that enables or disables a menu (not any code). But it won't work as a boolean apparently :/ Roman doesn't have any better suggestions, so oh well. drivers/scsi/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) commit faa725332f39329288f52b7f872ffda866ba5b09 Author: Adrian Bunk <[EMAIL PROTECTED]> Date: Wed Jul 27 01:06:35 2005 -0700 [PATCH] SCSI_SATA has to be a tristate SCSI=m must disallow static drivers. The problem is that all the SATA drivers depend on SCSI_SATA. With SCSI=m and SCSI_SATA=y this allows the static enabling of the SATA drivers with unwanted effects, e.g.: - SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y -> SCSI_ATA_ADMA is built statically but scsi/built-in.o is not linked into the kernel - SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y, SCSI_SATA_AHCI=m -> SCSI_ATA_ADMA and libata are built statically but scsi/built-in.o is not linked into the kernel, SCSI_SATA_AHCI is built modular (unresolved symbols due to missing libata) Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -424,7 +424,7 @@ config SCSI_IN2000 source "drivers/scsi/megaraid/Kconfig.megaraid" config SCSI_SATA - bool "Serial ATA (SATA) support" + tristate "Serial ATA (SATA) support" depends on SCSI help This driver family supports Serial ATA host controllers
Re: Power consumption HZ100, HZ250, HZ1000: new numbers
Hi! > > I'm pretty sure at least one distro will go with HZ<300 real soon now > > ;-). > > > > Any idea what their official recommendation for people running apps that > require the 1ms sleep resolution is? Something along the lines of "Get > bent"? So you busy wait for 1msec, big deal. Some machines can't even keep time properly with HZ=1000. Official recommendation is likely "help us with CONFIG_NO_IDLE_HZ" or "get over it". Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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: revert yenta free_irq on suspend
Hi! > > Ok, so we'll keep adding those free_irq/request_irq pairs > > I would suggest doing so only if you have a case where it can matter. > > > and re-introduce that ACPI change when we are ready? > > Why do it _ever_? There is _zero_ upside to doing it, I don't see why you > want to. Being able to turn off your soundcard at runtime when you are not using it was one of examples... > Just make ACPI restore the dang thing. It's the right thing to do. Requires interpretter running with interrupts disabled => ugly :-(. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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: revert yenta free_irq on suspend
On Mon, 1 Aug 2005, Pavel Machek wrote: > > Ok, so we'll keep adding those free_irq/request_irq pairs I would suggest doing so only if you have a case where it can matter. > and re-introduce that ACPI change when we are ready? Why do it _ever_? There is _zero_ upside to doing it, I don't see why you want to. Just make ACPI restore the dang thing. It's the right thing to do. Linus - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Mon, 2005-08-01 at 00:47 +0200, Pavel Machek wrote: > I'm pretty sure at least one distro will go with HZ<300 real soon now > ;-). > Any idea what their official recommendation for people running apps that require the 1ms sleep resolution is? Something along the lines of "Get bent"? Lee - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
In article <[EMAIL PROTECTED]> you wrote: > No, I'm saying that 99% users enable ACPI and cpufreq. ACPI is needed > on new machines, and cpufreq is usefull to keep your desktop cold, > too. And with the recent ongoing packing of CPU cores into racks, it is even more so important for Servers. Gruss 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: revert yenta free_irq on suspend
> > > > In general, I think that calling free_irq is the right behavior. > > I DO NOT CARE! > > It breaks hundreds of drivers. End of discussion. > > You can do the free_irq() and request_irq() changes _without_ breaking > hundreds of drivers by just doing one driver at a time. > So are driver writers supposed to start accepting patches to free/request irqs? in a sense of making it all go forward so at some point we can switch over to doing the correct thing? but my patch for yenta breaks setups for some strange reason. (maybe just APM ones..) If so we should put the patch to break links into -mm and then start fixing up drivers... Dave. - 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 patch] remove support for gcc < 3.2
Hi. On Mon, 2005-08-01 at 08:36, David S. Miller wrote: > Many people still use 2.95 because it's still the fastest > way to get a kernel build done and that's important for > many people. Yes, please don't remove 2.95 support. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - 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: revert yenta free_irq on suspend
Hi! > > In general, I think that calling free_irq is the right behavior. > > I DO NOT CARE! > > It breaks hundreds of drivers. End of discussion. > > You can do the free_irq() and request_irq() changes _without_ breaking > hundreds of drivers by just doing one driver at a time. > > And if ACPI then restores the irq controller state, the drivers that > _don't_ do this will _also_ continue to work. > > Let me re-iterate: the ACPI changes provably BROKE REAL PEOPLES SETUPS. > > For absolutely _zero_ gain. Drivers that want to free and re-aquire an > interrupt can do so _regardless_ of whether ACPI restores irq routings > automatically or not. > > And that's my argument. We don't do stupid things that break peoples > existing setups in ways that nobody can debug. Ok, so we'll keep adding those free_irq/request_irq pairs, and re-introduce that ACPI change when we are ready? It would be helpfull to keep the "right thing" in -mm, so there's real motivation to add free_irq/request_irq. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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] Re: 2.6.13-rc4-mm1
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote: > I think that "continuing" codepath came from someone at Phoenix, FWIW; > the problem is that I see the PCI quirks code has evolved even farther > from the main copy of the init code in the USB tree. Sigh. I don't like that either, but can't think of a way to make it easier to keep them in sync. Can you? 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: revert yenta free_irq on suspend
On Sun, 31 Jul 2005 [EMAIL PROTECTED] wrote: > > In general, I think that calling free_irq is the right behavior. I DO NOT CARE! It breaks hundreds of drivers. End of discussion. You can do the free_irq() and request_irq() changes _without_ breaking hundreds of drivers by just doing one driver at a time. And if ACPI then restores the irq controller state, the drivers that _don't_ do this will _also_ continue to work. Let me re-iterate: the ACPI changes provably BROKE REAL PEOPLES SETUPS. For absolutely _zero_ gain. Drivers that want to free and re-aquire an interrupt can do so _regardless_ of whether ACPI restores irq routings automatically or not. And that's my argument. We don't do stupid things that break peoples existing setups in ways that nobody can debug. Linus - 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/
[2.6 patch] remove sound/oss/skeleton.c
We do no longer need a template for OSS drivers.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Jul 2005
sound/oss/skeleton.c | 219 ---
1 files changed, 219 deletions(-)
--- linux-2.6.13-rc3-mm1-full/sound/oss/skeleton.c 2005-06-17
21:48:29.0 +0200
+++ /dev/null 2005-04-28 03:52:17.0 +0200
@@ -1,219 +0,0 @@
-/*
- * PCI sound skeleton example
- *
- * (c) 1998 Red Hat Software
- *
- * This software may be used and distributed according to the
- * terms of the GNU General Public License, incorporated herein by
- * reference.
- *
- * This example is designed to be built in the linux/drivers/sound
- * directory as part of a kernel build. The example is modular only
- * drop me a note once you have a working modular driver and want
- * to integrate it with the main code.
- * -- Alan <[EMAIL PROTECTED]>
- *
- * This is a first draft. Please report any errors, corrections or
- * improvements to me.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "sound_config.h"
-
-/*
- * Define our PCI vendor ID here
- */
-
-#ifndef PCI_VENDOR_MYIDENT
-#define PCI_VENDOR_MYIDENT 0x125D
-
-/*
- * PCI identity for the card.
- */
-
-#define PCI_DEVICE_ID_MYIDENT_MYCARD1 0x1969
-#endif
-
-#define CARD_NAME "ExampleWave 3D Pro Ultra ThingyWotsit"
-
-#define MAX_CARDS 8
-
-/*
- * Each address_info object holds the information about one of
- * our card resources. In this case the MSS emulation of our
- * ficticious card. Its used to manage and attach things.
- */
-
-static struct address_info mss_data[MAX_CARDS];
-static int cards;
-
-/*
- * Install the actual card. This is an example
- */
-
-static int mycard_install(struct pci_dev *pcidev)
-{
- int iobase;
- int mssbase;
- int mpubase;
- u8 x;
- u16 w;
- u32 v;
- int i;
- int dma;
-
- /*
-* Our imaginary code has its I/O on PCI address 0, a
-* MSS on PCI address 1 and an MPU on address 2
-*
-* For the example we will only initialise the MSS
-*/
-
- iobase = pci_resource_start(pcidev, 0);
- mssbase = pci_resource_start(pcidev, 1);
- mpubase = pci_resource_start(pcidev, 2);
-
- /*
-* Reset the board
-*/
-
- /*
-* Wait for completion. udelay() waits in microseconds
-*/
-
- udelay(100);
-
- /*
-* Ok card ready. Begin setup proper. You might for example
-* load the firmware here
-*/
-
- dma = card_specific_magic(ioaddr);
-
- /*
-* Turn on legacy mode (example), There are also byte and
-* dword (32bit) PCI configuration function calls
-*/
-
- pci_read_config_word(pcidev, 0x40, );
- w&=~(1<<15);/* legacy decode on */
- w|=(1<<14); /* Reserved write as 1 in this case */
- w|=(1<<3)|(1<<1)|(1<<0);/* SB on , FM on, MPU on */
- pci_write_config_word(pcidev, 0x40, w);
-
- /*
-* Let the user know we found his toy.
-*/
-
- printk(KERN_INFO "Programmed "CARD_NAME" at 0x%X to legacy mode.\n",
- iobase);
-
- /*
-* Now set it up the description of the card
-*/
-
- mss_data[cards].io_base = mssbase;
- mss_data[cards].irq = pcidev->irq;
- mss_data[cards].dma = dma;
-
- /*
-* Check there is an MSS present
-*/
-
- if(ad1848_detect(mssbase, NULL, mss_data[cards].osp)==0)
- return 0;
-
- /*
-* Initialize it
-*/
-
- mss_data[cards].slots[3] = ad1848_init("MyCard MSS 16bit",
- mssbase,
- mss_data[cards].irq,
- mss_data[cards].dma,
- mss_data[cards].dma,
- 0,
- 0,
- THIS_MODULE);
-
- cards++;
- return 1;
-}
-
-
-/*
- * This loop walks the PCI configuration database and finds where
- * the sound cards are.
- */
-
-int init_mycard(void)
-{
- struct pci_dev *pcidev=NULL;
- int count=0;
-
- while((pcidev = pci_find_device(PCI_VENDOR_MYIDENT,
PCI_DEVICE_ID_MYIDENT_MYCARD1, pcidev))!=NULL)
- {
- if (pci_enable_device(pcidev))
- continue;
- count+=mycard_install(pcidev);
- if(count)
- return 0;
- if(count==MAX_CARDS)
- break;
-
Re: [patch] ucb1x00: touchscreen cleanups
Hi! > > As this isn't the only chip of this sort (i.e. a > > multi-function chip not on the CPU bus) maybe we > > should store the bus driver in a common place. If > > needed we could have a very simple bus driver > > subsystem (this might already be in the kernel, I > > haven't looked at the bus stuff) in which you register > > a bus driver and client drivers register with the bus > > driver. Just an idea :-). > > This was the idea with the drivers/soc suggestion although I think that > name is perhaps misleading. > > How about drivers/mfd where mfd = Multi Functional Devices? > > I think it would be acceptable (and in keeping with the other drivers > e.g. pcmcia) to seeing the arch and platform specific modules with the > main driver as long as the naming reflected it (like the existing mcp > and ucb code does) i.e.: > > mcp-core.c > mcp-sa1100.c > ucb1x00-code.c > ucb1x00-assabet.c > ucb1x00-collie.c > > If code can be separated out into subsystems, I'm not so sure where they > should go though. The existing policy would suggest > drivers/input/touchscreen and sound/xxx for these... > > ucb1x00-ts.c > ucb1x00-audio.c > > Opinions/Comments? drivers/mfd sounds good, and yes, touchscreen and audio should go where they belong. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Hi! > >Then the second test was probably flawed, possibly because we have > >some more work to do. No display is irrelevant, HZ=100 will still save > >0.5W with running display. Spinning disk also does not produce CPU > >load (and we *will* want to have disk spinned down). No daemons... if > >some daemon wakes every msec, we want to fix the daemon. > > I was talking about percentage saved; That 5.2% easily drops below 2% > once other things start sucking up power. I was thinking that way since > the percentage saved is what determines the overall battery life > increase. You're right in that the absolute power draw difference > should stay the same, and that seems to be the case is Marc's tests > (ignoring the brokenness of artsd). You are right at that, but .5W is still about as much as hard disk spinning. And newer CPUs are likely to benefit more from HZ=100. > >Kernel defaults are irelevant; distros change them anyway. [But we > >probably want to enable ACPI and cpufreq by default, because that > >matches what 99% of users will use.] > > True, but I think a lot of distros treat the values as recommendations. > I guess we'll find out what they do with this option soon enough. I'm pretty sure at least one distro will go with HZ<300 real soon now ;-). Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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: QoS scheduler
Indeed I didn't specify what my project is about... My goal is to benchmark several QoS process schedulers, comparing them to the native kernel scheduler. I didn't, however, decided how will the benchmarking be done. Any sugestions? On 7/29/05, Stephen Pollei <[EMAIL PROTECTED]> wrote: > On 7/29/05, Vitor Curado <[EMAIL PROTECTED]> wrote: > > You assumed right, Stephen: I'm interested in QoS process scheduling, > > sorry for not specifying it... > > > > I'm taking a deeper look at the qlinux, ckrm and the plugsched > > schedulers, if you have any more links, please send them to me... > Also you didn't specify what kind of clustering you are doing and for > what ultimate purpose. > > http://www.beowulf.org/ > http://www-unix.mcs.anl.gov/mpi/implementations.html > http://www.csm.ornl.gov/pvm/pvm_home.html > http://www.open-mpi.org/ > > http://openmosix.sourceforge.net/ > http://www.mosix.org/ > > http://www.remote-dba.cc/teas_aegis_rac06.htm > http://www.dba-oracle.com/bp/bp_book1_rac.htm > Oracle DB Real Application Clusters (RAC) > transparent application failover (TAF) > > http://pgcluster.projects.postgresql.org/feature.html > http://dev.mysql.com/doc/mysql/en/replication.html > > High Availability (HA) > High Performance Computing (HPC) > > That can strongly effect what solutions you would want to look at. > For instance if you were running a render farm, or a scientific > compute beowulf cluster, then > your "scheduling" will be handled more in the MPI or PVM code perhaps. > The running processes themselves would most likely be using something > like SCHED_BATCH, with larger than usual time-slices. Maybe you > monitor how many mips actually get consumed and then adjust which > nodes get scheduled with what, or how many work units get handed out > to get back to fairness. > > clock_t times(struct tms *buf); > int getrusage(int who, struct rusage *usage); > to track system and user time is about on track, but I think someone > might be able to fool you, if thats all you could use to account for > cpu time taken from another userland process. > > So maybe you just need better reporting/accounting hooks and then you > can do the rest in userland? > > > On 7/28/05, Wes Felter <[EMAIL PROTECTED]> wrote: > > > Vitor Curado wrote: > > > > I'm working on a research about QoS schedulers for Linux clusters. > > > > Moreover, the ideal would be that the scheduler is implemented > > > > altering the native kernel scheduler. I'm kind of having trouble to > > > > find such schedulers, can anybody help me out? > > > > > > http://lass.cs.umass.edu/software/qlinux/ > > > http://ckrm.sourceforge.net/ > > That qlinux one is new to me. I notice that the 2.6 kernel has support > for modular plugable disk I/O and network schedulers now. > So a Hierarchical Start Time Fair Queuing (H-SFQ) network packet > scheduler module could be made. > > I wonder how that Cello scheduler would stack-up to AS, Deadline, cfq, > noop, etc etc. > > The qlinux cpu scheduler would be best to use plugsched for use with 2.6.x > > -- > http://dmoz.org/profiles/pollei.html > http://sourceforge.net/users/stephen_pollei/ > http://www.orkut.com/Profile.aspx?uid=2455954990164098214 > http://stephen_pollei.home.comcast.net/ > - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Mon, 2005-08-01 at 00:36 +0200, Pavel Machek wrote: > Hi! > > > > > I really like having 250HZ as an _option_, but what I don't see is why > > > > it should be the _default_. I believe this is Lee's position as > > > > Last I checked, ACPI and CPU speed scaling were not enabled by default; > > > > > > Kernel defaults are irelevant; distros change them anyway. [But we > > > probably want to enable ACPI and cpufreq by default, because that > > > matches what 99% of users will use.] > > > > > > > If the kernel defaults are irrelevant, then it would make more sense to > > leave the default HZ as 1000 and not to enable the cpufreq and ACPI in > > order to keep with the principle of least surprise for people who do use > > kernel.org kernels. > > Well, I'd say you want ACPI enabled. New machine do not even boot > without that. Default config should be usefull; set ACPI off, and > you'll not be able to even power machine down. While it's good to be future proof, I don't think it's valid to assume that new kernels usually run on new hardware. Lee - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Hi! > > > I really like having 250HZ as an _option_, but what I don't see is why > > > it should be the _default_. I believe this is Lee's position as > > > Last I checked, ACPI and CPU speed scaling were not enabled by default; > > > > Kernel defaults are irelevant; distros change them anyway. [But we > > probably want to enable ACPI and cpufreq by default, because that > > matches what 99% of users will use.] > > > > If the kernel defaults are irrelevant, then it would make more sense to > leave the default HZ as 1000 and not to enable the cpufreq and ACPI in > order to keep with the principle of least surprise for people who do use > kernel.org kernels. Well, I'd say you want ACPI enabled. New machine do not even boot without that. Default config should be usefull; set ACPI off, and you'll not be able to even power machine down. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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 patch] remove support for gcc < 3.2
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Mon, 1 Aug 2005 00:26:07 +0200 > - my impression is that the older compilers are only rarely > used, so miscompilations of a driver with an old gcc might > not be detected for a longer amount of time Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people. And with 4.0 being a scary regression in the compile time performance area compared to 3.4, this becomes even more important to keep around. - 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] ucb1x00: touchscreen cleanups
On Sun, 2005-07-31 at 23:11 +0100, Mark Underwood wrote: > As this isn't the only chip of this sort (i.e. a > multi-function chip not on the CPU bus) maybe we > should store the bus driver in a common place. If > needed we could have a very simple bus driver > subsystem (this might already be in the kernel, I > haven't looked at the bus stuff) in which you register > a bus driver and client drivers register with the bus > driver. Just an idea :-). This was the idea with the drivers/soc suggestion although I think that name is perhaps misleading. How about drivers/mfd where mfd = Multi Functional Devices? I think it would be acceptable (and in keeping with the other drivers e.g. pcmcia) to seeing the arch and platform specific modules with the main driver as long as the naming reflected it (like the existing mcp and ucb code does) i.e.: mcp-core.c mcp-sa1100.c ucb1x00-code.c ucb1x00-assabet.c ucb1x00-collie.c If code can be separated out into subsystems, I'm not so sure where they should go though. The existing policy would suggest drivers/input/touchscreen and sound/xxx for these... ucb1x00-ts.c ucb1x00-audio.c Opinions/Comments? Richard - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Hi! > > [But we > > probably want to enable ACPI and cpufreq by default, because that > > matches what 99% of users will use.] > > Sorry, this is just ridiculous. You're saying 99% of Linux > installations are laptops? Bullshit. No, I'm saying that 99% users enable ACPI and cpufreq. ACPI is needed on new machines, and cpufreq is usefull to keep your desktop cold, too. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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/
[2.6 patch] include/linux/dcookies.h: dummy functions must be "static inline"
We don't want these to be global functions.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Jul 2005
--- linux-2.6.13-rc3-mm1-full/include/linux/dcookies.h.old 2005-07-26
11:15:22.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/linux/dcookies.h 2005-07-26
11:15:38.0 +0200
@@ -48,12 +48,12 @@
#else
-struct dcookie_user * dcookie_register(void)
+static inline struct dcookie_user * dcookie_register(void)
{
return NULL;
}
-void dcookie_unregister(struct dcookie_user * user)
+static inline void dcookie_unregister(struct dcookie_user * user)
{
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: revert yenta free_irq on suspend
On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote: > But that believe would be total fantasy -- supsend/resume is not > working on a large number of machines, and no distro is currently > able to support it. (I'm talking about S3 suspend to RAM primarily, > suspend to disk is less interesting -- though Red Hat doesn't > even support _that_) After the 'swsusp works just fine' lovefest at OLS, I spent a little while playing with the current in-tree swsusp implementation last week. The outcome: I'm no more enthusiastic about enabling this in Red Hat kernels than I ever was before. It seems to have real issues with LVM setups (which is default on Red Hat/Fedora installs these days). After convincing it where to suspend/resume from by feeding it the major/minor of my swap partition, it did actually seem to suspend. And resume (though it did spew lots of 'sleeping whilst atomic warnings, but thats trivial compared to whats coming up next). I rebooted, and fsck found all sorts of damage on my / partition. After spending 30 minutes pressing 'y', to fix things up, it failed to boot after lots of files were missing. Why it wrote anything to completely different lv to where I told it (and yes, I did get the major:minor right) I have no idea, but as it stands, it definitly isn't production-ready. I'll look into it again sometime soon, but not until after I've reinstalled my laptop. (I'm just thankful I had the sense not to try this whilst I was at OLS). Dave - 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/
[2.6 patch] "extern inline" -> "static inline"
"extern inline" doesn't make much sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Jul 2005
include/linux/reiserfs_fs.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.13-rc3-mm1-full/include/linux/reiserfs_fs.h.old 2005-07-26
13:42:59.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/linux/reiserfs_fs.h 2005-07-26
13:43:37.0 +0200
@@ -2097,7 +2097,7 @@
b_blocknr_t, int for_unformatted);
int reiserfs_allocate_blocknrs(reiserfs_blocknr_hint_t *, b_blocknr_t *, int,
int);
-extern inline int reiserfs_new_form_blocknrs(struct tree_balance *tb,
+static inline int reiserfs_new_form_blocknrs(struct tree_balance *tb,
b_blocknr_t * new_blocknrs,
int amount_needed)
{
@@ -2113,7 +2113,7 @@
0);
}
-extern inline int reiserfs_new_unf_blocknrs(struct reiserfs_transaction_handle
+static inline int reiserfs_new_unf_blocknrs(struct reiserfs_transaction_handle
*th, struct inode *inode,
b_blocknr_t * new_blocknrs,
struct path *path, long block)
@@ -2130,7 +2130,7 @@
}
#ifdef REISERFS_PREALLOCATE
-extern inline int reiserfs_new_unf_blocknrs2(struct reiserfs_transaction_handle
+static inline int reiserfs_new_unf_blocknrs2(struct reiserfs_transaction_handle
*th, struct inode *inode,
b_blocknr_t * new_blocknrs,
struct path *path, long block)
-
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/
[2.6 patch] include/asm-i386/: "extern inline" -> "static inline"
"extern inline" doesn't make much sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Jul 2005
include/asm-i386/div64.h |2 +-
include/asm-i386/processor.h |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.13-rc3-mm1-full/include/asm-i386/div64.h.old 2005-07-26
01:38:12.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/asm-i386/div64.h 2005-07-26
01:38:20.0 +0200
@@ -35,7 +35,7 @@
*/
#define div_long_long_rem(a,b,c) div_ll_X_l_rem(a,b,c)
-extern inline long
+static inline long
div_ll_X_l_rem(long long divs, long div, long *rem)
{
long dum2;
--- linux-2.6.13-rc3-mm1-full/include/asm-i386/processor.h.old 2005-07-26
01:38:28.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/asm-i386/processor.h 2005-07-26
01:38:57.0 +0200
@@ -665,7 +665,7 @@
However we don't do prefetches for pre XP Athlons currently
That should be fixed. */
#define ARCH_HAS_PREFETCH
-extern inline void prefetch(const void *x)
+static inline void prefetch(const void *x)
{
alternative_input(ASM_NOP4,
"prefetchnta (%1)",
@@ -679,7 +679,7 @@
/* 3dnow! prefetch to get an exclusive cache line. Useful for
spinlocks to avoid one state transition in the cache coherency protocol. */
-extern inline void prefetchw(const void *x)
+static inline void prefetchw(const void *x)
{
alternative_input(ASM_NOP4,
"prefetchw (%1)",
-
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/
[2.6 patch] include/linux/bio.h: "extern inline" -> "static inline"
"extern inline" doesn't make much sense.
This patch was already ACK'ed by Jens Axboe.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 26 Jul 2005
include/linux/bio.h |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
--- linux-2.6.13-rc3-mm1-full/include/linux/bio.h.old 2005-07-26
13:40:47.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/linux/bio.h 2005-07-26
13:41:13.0 +0200
@@ -314,9 +314,8 @@
* bvec_kmap_irq and bvec_kunmap_irq!!
*
* This function MUST be inlined - it plays with the CPU interrupt flags.
- * Hence the `extern inline'.
*/
-extern inline char *bvec_kmap_irq(struct bio_vec *bvec, unsigned long *flags)
+static inline char *bvec_kmap_irq(struct bio_vec *bvec, unsigned long *flags)
{
unsigned long addr;
@@ -332,7 +331,7 @@
return (char *) addr + bvec->bv_offset;
}
-extern inline void bvec_kunmap_irq(char *buffer, unsigned long *flags)
+static inline void bvec_kunmap_irq(char *buffer, unsigned long *flags)
{
unsigned long ptr = (unsigned long) buffer & PAGE_MASK;
@@ -345,7 +344,7 @@
#define bvec_kunmap_irq(buf, flags)do { *(flags) = 0; } while (0)
#endif
-extern inline char *__bio_kmap_irq(struct bio *bio, unsigned short idx,
+static inline char *__bio_kmap_irq(struct bio *bio, unsigned short idx,
unsigned long *flags)
{
return bvec_kmap_irq(bio_iovec_idx(bio, idx), flags);
-
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/
[2.6 patch] remove support for gcc < 3.2
This patch removes support for gcc < 3.2 . The advantages are: - reducing the number of supported gcc versions from 8 to 4 [1] allows the removal of several #ifdef's and workarounds - my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time My personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines. This patch does not yet remove all the #ifdef's and other things that are now no longer required, it only let's the compilation #error for older gcc versions and updates the documentation. I'd like to see this patch in the next -mm, and if noone will tell a strong reason for keeping support for these gcc versions I'll send the cleanups that are now. [1] support removed: 2.95, 2.96, 3.0, 3.1 still supported: 3.2, 3.3, 3.4, 4.0 Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Documentation/Changes| 23 ++- README |6 +++--- include/linux/compiler.h |4 +--- 3 files changed, 6 insertions(+), 27 deletions(-) --- linux-2.6.13-rc4-mm1/include/linux/compiler.h.old 2005-07-31 19:07:34.0 +0200 +++ linux-2.6.13-rc4-mm1/include/linux/compiler.h 2005-07-31 19:08:24.0 +0200 @@ -40,10 +40,8 @@ #error no compiler-gcc.h file for this gcc version #elif __GNUC__ == 4 # include -#elif __GNUC__ == 3 +#elif (__GNUC__ == 3 && __GNUC_MINOR__ >= 2) # include -#elif __GNUC__ == 2 -# include #else # error Sorry, your compiler is too old/not recognized. #endif --- linux-2.6.13-rc4-mm1/README.old 2005-07-31 19:11:01.0 +0200 +++ linux-2.6.13-rc4-mm1/README 2005-07-31 19:11:38.0 +0200 @@ -174,9 +174,9 @@ COMPILING the kernel: - - Make sure you have gcc 2.95.3 available. - gcc 2.91.66 (egcs-1.1.2), and gcc 2.7.2.3 are known to miscompile - some parts of the kernel, and are *no longer supported*. + - Make sure you have gcc >= 3.2 available. + Older versions of gcc are *no longer supported*. + Also remember to upgrade your binutils package (for as/ld/nm and company) if necessary. For more information, refer to Documentation/Changes. --- linux-2.6.13-rc4-mm1/Documentation/Changes.old 2005-07-31 19:11:56.0 +0200 +++ linux-2.6.13-rc4-mm1/Documentation/Changes 2005-07-31 19:12:48.0 +0200 @@ -48,7 +48,7 @@ hardware, for example, you probably needn't concern yourself with isdn4k-utils. -o Gnu C 2.95.3 # gcc --version +o Gnu C 3.2 # gcc --version o Gnu make 3.79.1 # make --version o binutils 2.12# ld -v o util-linux 2.10o # fdformat --version @@ -75,26 +75,7 @@ --- The gcc version requirements may vary depending on the type of CPU in your -computer. The next paragraph applies to users of x86 CPUs, but not -necessarily to users of other CPUs. Users of other CPUs should obtain -information about their gcc version requirements from another source. - -The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it -should be used when you need absolute stability. You may use gcc 3.0.x -instead if you wish, although it may cause problems. Later versions of gcc -have not received much testing for Linux kernel compilation, and there are -almost certainly bugs (mainly, but not exclusively, in the kernel) that -will need to be fixed in order to use these compilers. In any case, using -pgcc instead of plain gcc is just asking for trouble. - -The Red Hat gcc 2.96 compiler subtree can also be used to build this tree. -You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build -the kernel correctly. - -In addition, please pay attention to compiler optimization. Anything -greater than -O2 may not be wise. Similarly, if you choose to use gcc-2.95.x -or derivatives, be sure not to use -fstrict-aliasing (which, depending on -your version of gcc 2.95.x, may necessitate using -fno-strict-aliasing). +computer. Make - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Lee Revell wrote: On Sun, 2005-07-31 at 23:10 +0200, Pavel Machek wrote: defconfig on i386 is Linus' configuration. Maybe server-config and laptop-config would be good idea... Um, what about those things called "desktops"? They're like a laptop but with reasonable hard drive speeds and adult-sized keyboards? Pavel picked up that (incomplete) list up from my email, and I was just assuming defconfig to be the desktop config. If that feature were done cleanly though, we could have any number of blah-configs, and maybe even split desktops into low-latency or low-resources options. It'd be neat to get preempt and everything on just by saying: make desktop-lowlatency-config Then again, maybe that idea will fly like pigs; we'll see. - Jim Bruce - 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: "drive appears confused" and "irq 18: nobody cared!"
Michael Thonke wrote: Hello Alexander, do you run A.) SATA in Enhanced Mode B.) SATA+PATA or PATA operation mode? This problem I can reproduce when I set A.)+B.) in bios I exactly get the same behavior of confused cd - drives. Yes, I'm running SATA in enhanced mode with SATA+PATA operation mode and I have to. Running it in compatibility mode (PATA+SATA) I cannot boot from the SATA drive. Regards, Alexander - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Pavel Machek wrote: Then the second test was probably flawed, possibly because we have some more work to do. No display is irrelevant, HZ=100 will still save 0.5W with running display. Spinning disk also does not produce CPU load (and we *will* want to have disk spinned down). No daemons... if some daemon wakes every msec, we want to fix the daemon. I was talking about percentage saved; That 5.2% easily drops below 2% once other things start sucking up power. I was thinking that way since the percentage saved is what determines the overall battery life increase. You're right in that the absolute power draw difference should stay the same, and that seems to be the case is Marc's tests (ignoring the brokenness of artsd). Kernel defaults are irelevant; distros change them anyway. [But we probably want to enable ACPI and cpufreq by default, because that matches what 99% of users will use.] True, but I think a lot of distros treat the values as recommendations. I guess we'll find out what they do with this option soon enough. I have a fixed-framerate app that had to busywait in the days of 2.4.x. It was nice in 2.6.x to not have to busywait, but with 250HZ that code will be coming back again. And unfortunately this app can't be made variable-framerate, as it is simulating video hardware. The same goes for apps playing movies/animations; Sometimes programs just need a semi-accurate sleep, and can't demand root priveledges to get it. I really don't think default HZ in kernel config is such a big deal. You'll want to support HZ=100 on 2.6.X, anyway... Yeah, but if its only the default value for servers and laptops they won't normally be running my app. I'll be truly happy the day I can delete all the busy-waiting code, as I think its about the ugliest workaround in modern computing. defconfig on i386 is Linus' configuration. Maybe server-config and laptop-config would be good idea... Well maybe if we can get enough people who agree then it could happen. I think a "laptop-config" and "server-config" file could fit nicely into the current arch/*/config/ directory structure. I'm not sure how those defconfig files are kept up to date though. - Jim - 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] ucb1x00: touchscreen cleanups
--- Russell King <[EMAIL PROTECTED]> wrote: > On Sat, Jul 30, 2005 at 10:46:58PM +0200, Pavel > Machek wrote: > > Hi! > > > > > > > Note that I'm maintaining the code and will > be > > > > > publishing a new set > > > > > of patches for it based upon Pavel's fixes. > > > > > > > > Thanks. I'll check them out then. > > > > > > Since there appears to be some interest in > these, I'll set about > > > converting the audio bits to ALSA rather than > Nico's SA11x0 audio > > > driver. I thought no one was using these chips > anymore, and the > > > driver was dead! > > > > > > I've recently edited the mcp structure which may > make things less > > > awkward for others, and I'll continue moving in > that direction > > > with this driver. > > > > > > You can get the updated patches at: > > > > > > http://zeniv.linux.org.uk/pub/people/rmk/ucb/ > > > > Okay, what's the plan with mainstreaming those? Do > they stay in > > drivers/misc? > > Let me put the second question a slightly different > way: can anyone > think of a better way to organise the files which > makes more sense > and doesn't end up with just a couple of files for > the core UCB > and MCP support in some random directory elsewhere? > > Arjan? hch? any comments / good ideas? As this isn't the only chip of this sort (i.e. a multi-function chip not on the CPU bus) maybe we should store the bus driver in a common place. If needed we could have a very simple bus driver subsystem (this might already be in the kernel, I haven't looked at the bus stuff) in which you register a bus driver and client drivers register with the bus driver. Just an idea :-). Mark > > -- > Russell King > Linux kernel2.6 ARM Linux - > http://www.arm.linux.org.uk/ > maintainer of: 2.6 Serial core > - > 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/ > ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.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: Power consumption HZ100, HZ250, HZ1000: new numbers
On 07/31/05 11:10:20PM +0200, Pavel Machek wrote: > > > I really like having 250HZ as an _option_, but what I don't see is why > > it should be the _default_. I believe this is Lee's position as > > Last I checked, ACPI and CPU speed scaling were not enabled by default; > > Kernel defaults are irelevant; distros change them anyway. [But we > probably want to enable ACPI and cpufreq by default, because that > matches what 99% of users will use.] > If the kernel defaults are irrelevant, then it would make more sense to leave the default HZ as 1000 and not to enable the cpufreq and ACPI in order to keep with the principle of least surprise for people who do use kernel.org kernels. Jim. - 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: Where's the list of needed hardware for donating?
On 7/30/05, Pavel Machek <[EMAIL PROTECTED]> wrote: -snip-snip- > > The hardware I have may outdated/esoteric. I take it that there is > > no such list then? > > Maybe it's better not to support esoteric hardware. > > Post a list somewhere... Ok, here's the list: Adaptec AHA-1510A (ISA, centronix-style external connector with terminator, one internal ribbon cable, I probably have some centronix-style external cables around too, this card doesn't have it's own boot ROM) Gravis UltraSound a.k.a. GUS (ISA, fully loaded with memory, 1megabyte (I think)) Pertec MyTape 800 (I think this is a QIC tape drive that connects via the floppy interface) TEAC 1.44 3.5 inch Floppy FDR (FD-235HF) Rocket Port 8-port serial board (ISA, 8 - RJ11 jacks, made by Comtrol, brand-new in-box) - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Sun, 2005-07-31 at 23:10 +0200, Pavel Machek wrote: > defconfig on i386 is Linus' configuration. Maybe server-config and > laptop-config would be good idea... Um, what about those things called "desktops"? They're like a laptop but with reasonable hard drive speeds and adult-sized keyboards? Lee - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Lee Revell wrote: > On Sun, 2005-07-31 at 23:10 +0200, Pavel Machek wrote: >>[But we >>probably want to enable ACPI and cpufreq by default, because that >>matches what 99% of users will use.] > > Sorry, this is just ridiculous. You're saying 99% of Linux > installations are laptops? Bullshit. I believe he's talking about the future (he did said "will"). All the new AMD64 desktop chips have powersaving now, and Intel chips either have it now or will soon. With the power that desktop chips draw nowadays (some are 80+ watts at idle), it is an important consideration. As for uptake, a realistic number would be probably be 90% in three years. Of course regardless of that I'd still like to keep the 1msec sleep resolution... - Jim - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Sun, 2005-07-31 at 23:10 +0200, Pavel Machek wrote: > > I really like having 250HZ as an _option_, but what I don't see is why > > it should be the _default_. I believe this is Lee's position as > > Last I checked, ACPI and CPU speed scaling were not enabled by default; > > Kernel defaults are irelevant; distros change them anyway. OK, so HZ should be left at 1000 so "make oldconfig" continues to do the right thing. It is supposed to give me my old config, right? Lee - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Sun, 2005-07-31 at 23:10 +0200, Pavel Machek wrote: > [But we > probably want to enable ACPI and cpufreq by default, because that > matches what 99% of users will use.] Sorry, this is just ridiculous. You're saying 99% of Linux installations are laptops? Bullshit. Lee - 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.13-rc3-mm3
Le dimanche 31 juillet 2005 à 11:25 -0700, Linus Torvalds a écrit : > - The SonyPI driver just allocates IO regions in random areas. Those are not really random, the list of IO regions available is given in the ACPI SPIC device specification. The list is hardcoded here because the driver does not (yet ?) use the ACPI services for initializing the device, and experience has shown that the list does not vary with different models. > and I think the real bug here is the SonyPI driver. > > It should either use an IO port in the legacy motherboard resource area > (ie allocate itself somewhere in IO ports 0x100-0x3ff), this cannot be done, because the regions are already defined, and are not in the legacy area. > _or_ it should > play well as a PCI device, and actually try to work with the PCI IO port > allocation layer. sure, but the SPIC device is not really tied to a specific PCI device (it is for the 'type1' models, but not for the 'type2' ones). That's why the sonypi driver is not a PCI driver but relies on a DMI ident to detect each and every Vaio laptop out there. Stelian. -- Stelian Pop <[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: Acer Aspire 1691WCLi no boot problem
On Fri, Jul 29, 2005 at 12:01:26PM -0500, Jesus Delgado wrote: > Iam have is the same problems with emachines M6807. > On 7/29/05, Brad Barnett <[EMAIL PROTECTED]> wrote: > > I have a very odd problem with an Acer Aspire 1691WCLi. This laptop will > > simply not boot with any Debian precompiled kernel, with the exception of > > Debian's 2.4.27-2 initrd kernel. I have compiled my own kernels, using a > > vast array of options, 2.6.11, 2.6.12, 2.6.12.3, 2.6.13-rc4 and 2.4.27, > > they also all fail in exactly the same way. I have tried with and without > > initrd, acpi, 386 or other processor options, as well as very lean, > > stripped down kernels. I have tried with both lilo and grub, but both > > result in the same hang. > > > > Lilo or grub boots the kernel, and I see the classic: > > > > boot: vmlinuz > > Loading vmlinuz. > > BIOS data check successful > > Uncompressiong Linux... Ok. booting the kernel. I've filed a bug at kernel bugzilla, so yours reports won't be lost. See http://bugzilla.kernel.org/show_bug.cgi?id=4975 You can register at http://bugme.osdl.org/createaccount.cgi and add yourself to CC list. - 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: revert yenta free_irq on suspend
Hi! > Also I'd like to point out that this patch broke APM suspend-to-ram, > not ACPI S3. IMO, it may not be possible to support both APM and ACPI > on every system, as their specs are not intended to be compatible. > Progress toward proper suspend-to-ram support will, in many cases, be > a small setback for APM. This really can't be avoided. Actually, for APM, OS theoretically does *not* need to FREEZE the devices (or do anything else). "Doing nothing" should be easy... Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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: sysfs abuse in recent i2o changes
On Sun, Jul 31, 2005 at 05:40:29PM +0200, Markus Lidel wrote: > Hello, > > Christoph Hellwig wrote: > >So folks, this is still in 2.6.13-rc4, shouldn't we pull it out so we > > Yep, sorry... I'll try to send the patch during next week... > > >don't add an interface soon to be removed again to 2.6.13? > > The interface will still be available, because IMHO it fits better then > the old ioctl based one... But until the necessary functions for the > interface are available, i'll provide a separate patch, which could be > downloaded at the I2O website... What "necessary functions for the interface"? Remember, you are not using sysfs properly, so please fix your code to not do that anymore. 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Hi! > >First numbers were 0.5W on idle system; that shows what kind of > >powersaving can be done. Powersaving is no longer possible when artsd > >is not running, but that should not be used as argument against it. > > It was an idle system with no display, zero daemons running, and the > hard drive off. In other words, a machine that nobody could use which > might as well be hibrinating. While it was an important test to find > out the most one could hope to save, its unrealistic for an actual usage > case. The later test was more realistic, and not suprisingly showed > quite a bit less power savings. Then the second test was probably flawed, possibly because we have some more work to do. No display is irrelevant, HZ=100 will still save 0.5W with running display. Spinning disk also does not produce CPU load (and we *will* want to have disk spinned down). No daemons... if some daemon wakes every msec, we want to fix the daemon. > I really like having 250HZ as an _option_, but what I don't see is why > it should be the _default_. I believe this is Lee's position as > Last I checked, ACPI and CPU speed scaling were not enabled by default; Kernel defaults are irelevant; distros change them anyway. [But we probably want to enable ACPI and cpufreq by default, because that matches what 99% of users will use.] > I have a fixed-framerate app that had to busywait in the days of 2.4.x. > It was nice in 2.6.x to not have to busywait, but with 250HZ that code > will be coming back again. And unfortunately this app can't be made > variable-framerate, as it is simulating video hardware. The same goes > for apps playing movies/animations; Sometimes programs just need a > semi-accurate sleep, and can't demand root priveledges to get it. I really don't think default HZ in kernel config is such a big deal. You'll want to support HZ=100 on 2.6.X, anyway... > In a sense I feel this whole thing boils down to the fact that we don't > have something like "make laptop-config" and "make server-config". I'm > glad we could save 5.2% of the power for a laptop user by changing > the defconfig on i386 is Linus' configuration. Maybe server-config and laptop-config would be good idea... Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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] (10/11) hwmon vs i2c, second round
Hi Alexey, > > I see very little reason why vid_from_reg and vid_to_reg are > > inlined. The former is not exactly short, > > 1) > and their arguments aren't known at > compile time, > > [Compiler can optimise them away _completely_ if both arguments are > known at compile time or significantly of only one is known.] Good point, I'll try to remember that. It doesn't apply here though except for lm78 I think, and maybe lm93 when it gets ported. That's not the majority of users though, so I still believe uninlining is the correct decision. > > and they are never called in speed critical areas. Uninlining them > > should cause little performance loss if any, and saves a signficant > > space and compilation time as well. > > 2) VID_FROM_REG is asking for removal from lm85. True, I wrote a patch doing this already: http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013148.html Just wait for Greg to pick it and it'll show in -mm. > 3) vid_to_reg is used only by atxp1. That's right. Do you suggest that it should be kept inlined then? Similar drivers may be written in the future, causing vid_to_reg to gain users and possibly grow larger (to support more VRM/VRD standards), then we'll certainly want to uninline it anyway - but I agree that this ain't the case at the moment. I'll change that patch to only uninline vid_from_reg and not vid_to_reg if a majority prefers me to do so. Thanks for your comments :) -- Jean Delvare - 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] (10/11) hwmon vs i2c, second round
One nitpicking comment and two observations: On Sun, Jul 31, 2005 at 10:02:24PM +0200, Jean Delvare wrote: > I see very little reason why vid_from_reg and vid_to_reg are inlined. > The former is not exactly short, 1) and their arguments aren't known at compile time, [Compiler can optimise them away _completely_ if both arguments are known at compile time or significantly of only one is known.] > and they are never called in speed critical areas. Uninlining them should > cause little performance loss if any, and saves a signficant space and > compilation time as well. 2) VID_FROM_REG is asking for removal from lm85. 3) vid_to_reg is used only by atxp1. - 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
Frank Peters <[EMAIL PROTECTED]> wrote: > > On Sun, 31 Jul 2005 20:45:32 +0200 > Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > > > > > > > During a failed boot, when the keyboard was unresponsive, I managed > > > to capture a kernel log of this failure. Here are the lines that caught > > > my attention: > > > > > > kernel: i8042.c: Can't read CTR while initializing i8042. > > > kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing > > > disabled > > > kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > > > kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A > > > kernel: ACPI: PCI Interrupt :02:0a.0[A] -> GSI 22 (level, low) -> IRQ > > > 16 > > > kernel: ttyS2 at I/O 0xb800 (irq = 16) is a 16550A > > > > > > > Please try 'usb-handoff' on the kernel command line. This looks like an > > usual symptom on machines that need it. > > > > > > > > It works! :-))) > > Booting linux-2.6.13-rc4 with the "usb-handoff" option gives me > a working keyboard everytime now. But 2.6.12 did not require this workaround, yes? - 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: revert yenta free_irq on suspend
- Original Message - From: Linus Torvalds <[EMAIL PROTECTED]> Date: Sunday, July 31, 2005 11:53 am Subject: Re: revert yenta free_irq on suspend > > > On Sun, 31 Jul 2005, Pavel Machek wrote: > > > > Well, on some machines interrupts can change during suspend (or > so I > > was told). I did not like the ACPI change at one point, but it > is very > > wrong to revert PCMCIA fix without also fixing ACPI interpretter. > > We _are_ going to fix the ACPI interpreter. > > As to irq's changing during suspend - I'll believe that when I see > it, not > when some chicken little runs around worrying about it. I doubt > anybody > has ever seen it, and I'm 100% sure that we have serious breakage > right > now on machines where it definitely doesn't happen. > > > And it indeed seems that ACPI interpretter is hard to fix in the > right> way. > > We'll revert to the behaviour that it has traditionally had, and > start > working forwards in a more careful manner. Where we don't break > working > setups. > > Linus Hi Linus, In general, I think that calling free_irq is the right behavior. Although irqs changing after suspend is rare, there are also some more serious issues. This has been discussed in the past, and a summary is as follows: 1.) race conditions: Consider the case where several PCI devices are sharing a single PCI interrupt. One device is suspended, but doesn't call free_irq. Now another properly behaving device on the same interrupt line generates an interrupt. Let's say the suspended device had its handler registered first, and therefore is called first. The handler will attempt to access registers on the physically-off device to determine if it generated the interrupt. The PCI bus will issue a master abort. The driver's interrupt handler will likely interpret the read incorrectly. Every interrupt handler could be modified to check if the device is available, but it would be cleaner and more efficient to unregister the interrupt. Either way, every driver has to be changed to support PM correctly. 2.) runtime power management: We don't want to leave stale interrupt handlers registered when only suspending a specific device. As we move toward supporting runtime power management it will be important to ensure every driver calls free_irq() in its suspend() (or whatever we're using at that point) routine. This avoids interrupt handler bugs and extra interrupt overhead. Also I'd like to point out that this patch broke APM suspend-to-ram, not ACPI S3. IMO, it may not be possible to support both APM and ACPI on every system, as their specs are not intended to be compatible. Progress toward proper suspend-to-ram support will, in many cases, be a small setback for APM. This really can't be avoided. There are, however, some things we can do to mitigate the breakage toward APM. Specifically, we should indicate the type of suspend state, including if it's an ACPI or APM state, for each driver's ->suspend() routine. This will give drivers the opportunity to act differently for APM when necessary. I'm currenlty working on this issue. APM is useful for legacy hardware and systems with blacklisted ACPI support. I don't think we should attempt to support APM on any system with working ACPI suspend/resume. Thanks, Adam - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Pavel Machek wrote: First numbers were 0.5W on idle system; that shows what kind of powersaving can be done. Powersaving is no longer possible when artsd is not running, but that should not be used as argument against it. It was an idle system with no display, zero daemons running, and the hard drive off. In other words, a machine that nobody could use which might as well be hibrinating. While it was an important test to find out the most one could hope to save, its unrealistic for an actual usage case. The later test was more realistic, and not suprisingly showed quite a bit less power savings. I really like having 250HZ as an _option_, but what I don't see is why it should be the _default_. I believe this is Lee's position as well. Last I checked, ACPI and CPU speed scaling were not enabled by default; If users are willing to change all those other options, why can't we expect them to select 250HZ/100HZ? Instead, we are quadrupling latency for desktop users (for little or no power savings), just so that laptop users can save enabling one option out of the many they already need to change. I have a fixed-framerate app that had to busywait in the days of 2.4.x. It was nice in 2.6.x to not have to busywait, but with 250HZ that code will be coming back again. And unfortunately this app can't be made variable-framerate, as it is simulating video hardware. The same goes for apps playing movies/animations; Sometimes programs just need a semi-accurate sleep, and can't demand root priveledges to get it. I remember that 1000HZ was chosen in part so that fewer people would complain about the need for the Posix highres timers. Well now that 1000HZ is going away, can we have our highres timers or not? My guess is no. Thus we've predictably come back out here to complain. All we're asking is that the default value be left alone until tick-skipping approaches and/or highres timers are given a chance to work. That way we can see if we can find a solution that truly makes everyone happy. In a sense I feel this whole thing boils down to the fact that we don't have something like "make laptop-config" and "make server-config". I'm glad we could save 5.2% of the power for a laptop user by changing the defaults (as long as you remember to change other options too). However I'm not sure it should come at the expense of those doing video or audio on a desktop. Right now with the one-size-fits-all defaults, we end up having to make that tradeoff. - Jim Bruce - 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.6] (11/11) hwmon vs i2c, second round
Use the common vid_from_reg function in lm78 rather than
reimplementing it.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
drivers/hwmon/Kconfig |1 +
drivers/hwmon/lm78.c | 10 ++
2 files changed, 3 insertions(+), 8 deletions(-)
--- linux-2.6.13-rc4.orig/drivers/hwmon/lm78.c 2005-07-31 16:59:10.0
+0200
+++ linux-2.6.13-rc4/drivers/hwmon/lm78.c 2005-07-31 20:55:46.0
+0200
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -106,13 +107,6 @@
return val * 1000;
}
-/* VID: mV
- REG: (see doc/vid) */
-static inline int VID_FROM_REG(u8 val)
-{
- return val==0x1f ? 0 : val>=0x10 ? 5100-val*100 : 2050-val*50;
-}
-
#define DIV_FROM_REG(val) (1 << (val))
/* There are some complications in a module like this. First off, LM78 chips
@@ -457,7 +451,7 @@
static ssize_t show_vid(struct device *dev, struct device_attribute *attr,
char *buf)
{
struct lm78_data *data = lm78_update_device(dev);
- return sprintf(buf, "%d\n", VID_FROM_REG(data->vid));
+ return sprintf(buf, "%d\n", vid_from_reg(82, data->vid));
}
static DEVICE_ATTR(cpu0_vid, S_IRUGO, show_vid, NULL);
--- linux-2.6.13-rc4.orig/drivers/hwmon/Kconfig 2005-07-31 16:59:30.0
+0200
+++ linux-2.6.13-rc4/drivers/hwmon/Kconfig 2005-07-31 20:55:46.0
+0200
@@ -207,6 +207,7 @@
tristate "National Semiconductor LM78 and compatibles"
depends on HWMON && I2C && EXPERIMENTAL
select I2C_ISA
+ select HWMON_VID
help
If you say yes here you get support for National Semiconductor LM78,
LM78-J and LM79.
--
Jean Delvare
-
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: revert yenta free_irq on suspend
On Sunday, 31 of July 2005 01:09, Rafael J. Wysocki wrote:
> On Sunday, 31 of July 2005 00:24, Hugh Dickins wrote:
> > On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
> > > On Saturday, 30 of July 2005 23:32, Hugh Dickins wrote:
> > > > On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
> > > > >
> > > > > Could you please send the /proc/interrupts from your box?
> > > >
> > > > 11: 57443 XT-PIC yenta, yenta, eth0
> > >
> > > Thanks. It looks like eth0 gets a yenta's interrupt and goes awry.
> > > Could you please tell me what driver the eth0 is?
> >
> > CONFIG_VORTEX drivers/net/3c59x.c:
> > :02:00.0: 3Com PCI 3c905C Tornado at 0xec80. Vers LK1.1.19
>
> Thanks again. From the first look the suspend/resume routines of the driver
> are missing some calls. In particular, with the IRQ-freeing patch for yenta
> it is
> likely to get an out-of-order interrupt as I suspected.
>
> Linus has apparently dropped that patch for yenta, but in case it is
> reintroduced in the future you will probably need a patch to make the network
> driver cooperate. I'll try to prepare one tomorrow, if I can, but I have no
> hardware
> to test it.
The patch follows. It compiles and should work, though I haven't tested it.
Greets,
Rafael
Index: linux-2.6.13-rc4-git3/drivers/net/3c59x.c
===
--- linux-2.6.13-rc4-git3.orig/drivers/net/3c59x.c
+++ linux-2.6.13-rc4-git3/drivers/net/3c59x.c
@@ -973,6 +973,11 @@ static int vortex_suspend (struct pci_de
netif_device_detach(dev);
vortex_down(dev, 1);
}
+ pci_save_state(pdev);
+ pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
+ free_irq(dev->irq, dev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
}
return 0;
}
@@ -980,8 +985,19 @@ static int vortex_suspend (struct pci_de
static int vortex_resume (struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
+ struct vortex_private *vp = netdev_priv(dev);
- if (dev && dev->priv) {
+ if (dev && vp) {
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_device(pdev);
+ pci_set_master(pdev);
+ if (request_irq(dev->irq, vp->full_bus_master_rx ?
+ _interrupt : _interrupt,
SA_SHIRQ, dev->name, dev)) {
+ printk(KERN_WARNING "%s: Could not reserve IRQ %d\n",
dev->name, dev->irq);
+ pci_disable_device(pdev);
+ return -EBUSY;
+ }
if (netif_running(dev)) {
vortex_up(dev);
netif_device_attach(dev);
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
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/
