Skip to contentSkip to conversation

Linux 2.6.21-rc2

PATCH In review Linus Torvalds 49 participants 192 messages Feb 28, 2007 – Mar 21, 2007 1 message not in the archive Page 2 of 2

Subsystems (11)
Networking Network drivers USB Bluetooth drivers +7 more subsystems
lore
Share & tools
lore
#174 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

In reply to Linus Torvalds
Quoted 3 lines · Linus Torvalds

This is just a coding style thing, but I thought I should really point it out, because these kinds of things quite often result in nasty bugs simply because the source code is so hard to read properly:

yeah, agreed. We'll fix this.

Ingo

#175 lore raw

PATCH 1/1 highres: do not run the TIMER_SOFTIRQ after switching to highres mode

In reply to Linus Torvalds
Quoted 3 lines · Linus Torvalds

This is just a coding style thing, but I thought I should really point it out, because these kinds of things quite often result in nasty bugs simply because the source code is so hard to read properly:

/me pleads guilty !

Replacement patch below.

tglx

--------------------->

The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable clocksource and clock event sources are registered. The switch to high resolution mode happens inside of the TIMER_SOFTIRQ, but runs the softirq afterwards. That way the tick emulation timer, which was set up in the switch to highres might be executed in the softirq context, which is a BUG. The rbtree has not to be touched by the softirq after the highres switch.

This BUG was observed by Andres Salomon, who provided the information to debug it.

Return early from the softirq, when the switch was sucessful.

Remove also the superfluid hres_active check on top of hrtimer_switch_to_hres(), as we never get there, once we switched over.

Signed-off-by Thomas Gleixner <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>
Cc Andres Salomon <[email protected]>
kernel/hrtimer.c +9 -8
index de93a81..2e465df 100644
@@ -540,19 +540,18 @@ static inline int hrtimer_enqueue_reprogram(struct hrtimer *timer,
 /*
  * Switch to high resolution mode
  */
-static void hrtimer_switch_to_hres(void)
+static int hrtimer_switch_to_hres(void)
 {
 	struct hrtimer_cpu_base *base = &__get_cpu_var(hrtimer_bases);
 	unsigned long flags;
-
-	if (base->hres_active)
-		return;
+	int err;
 
 	local_irq_save(flags);
 
-	if (tick_init_highres()) {
+	err = tick_init_highres();
+	if (err < 0) {
 		local_irq_restore(flags);
-		return;
+		return err;
 	}
 	base->hres_active = 1;
 	base->clock_base[CLOCK_REALTIME].resolution = KTIME_HIGH_RES;

@@ -565,13 +564,14 @@ static void hrtimer_switch_to_hres(void)
 	local_irq_restore(flags);
 	printk(KERN_INFO "Switched to high resolution mode on CPU %d\n",
 	       smp_processor_id());
+	return 0;
 }
 
 #else
 
 static inline int hrtimer_hres_active(void) { return 0; }
 static inline int hrtimer_is_hres_enabled(void) { return 0; }
-static inline void hrtimer_switch_to_hres(void) { }
+static inline int hrtimer_switch_to_hres(void) { return -EINVAL; }
 static inline void hrtimer_force_reprogram(struct hrtimer_cpu_base *base) { }
 static inline int hrtimer_enqueue_reprogram(struct hrtimer *timer,
 					    struct hrtimer_clock_base *base)

@@ -1173,7 +1173,8 @@ void hrtimer_run_queues(void)
 	 * deadlock vs. xtime_lock.
 	 */
 	if (tick_check_oneshot_change(!hrtimer_is_hres_enabled()))
-		hrtimer_switch_to_hres();
+		if (!hrtimer_switch_to_hres())
+			return;
 
 	hrtimer_get_softirq_time(cpu_base);
author
#176 lore raw

Re: [PATCH] highres: do not run the TIMER_SOFTIRQ after switching to highres mode

Quoted 4 lines · Thomas Gleixner

/me pleads guilty !

Replacement patch below.

Well, I already applied the original one that came through Andrew, so I really just wanted to note the coding style in general, and your fixed patch no longer applied ;)

Also, you do end up testing for "not error" with a

kernel/hrtimer.c void hrtimer_run_queues(void) · line 1177

Quoted 4 lines
kernel/hrtimer.c +2 -1
 	if (tick_check_oneshot_change(!hrtimer_is_hres_enabled()))
-		hrtimer_switch_to_hres();
+		if (!hrtimer_switch_to_hres())
+			return;

which I guess is ok, if only because we simply don't care about what the exact error was. But it means that this particular code sequence ends up having the same problem (which is still fewer places than the original patch, so we're good).

I personally hate the

	if (hrtimer_switch_to_hres() == SUCCESS)
		return;

kind of syntax (it's just too long, and it's *not* obvious at all that SUCCESS is zero and that this is a "negative error or zero" kind of function, so it's actually *worse* than just doing what you did, but some projects seem to have that kind of approach.

We could encourage people to do

	if (hrtimer_switch_to_hres() >= 0)
		return;

which is fairly obviously a "success" case for a negative error value, but I'm not sure the extra typing really is worth it. Does anybody have any smart ideas that people might even be ok with following (just making things more cumbersome is anti-productive, so I don't want to have some stupid rule that everybody really hates)?

Linus

#177 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

In reply to Linus Torvalds
Quoted 60 lines · On Tue, 6 Mar 2007 08:44:43 -0800 (PST) Linus Torvalds wrote:

This is just a coding style thing, but I thought I should really point it out, because these kinds of things quite often result in nasty bugs simply because the source code is so hard to read properly:

kernel/hrtimer.c static inline int hrtimer_enqueue_reprog · line 543

Quoted 3 lines · Ingo Molnar
kernel/hrtimer.c +1 -1
-static void hrtimer_switch_to_hres(void)
+static int hrtimer_switch_to_hres(void)

Ok, so here's the quiz: does this function return "true on success, false on failure", or does it return "zero on success, negative on failure"?

kernel/hrtimer.c static inline int hrtimer_enqueue_reprog · line 549

Quoted 3 lines
kernel/hrtimer.c +1 -1
 	if (base->hres_active)
-		return;
+		return 1;

Ahh, it must be "true on success", right?

kernel/hrtimer.c static inline int hrtimer_enqueue_reprog · line 555

Quoted 6 lines
kernel/hrtimer.c +1 -1
 	local_irq_save(flags);
 
 	if (tick_init_highres()) {
 		local_irq_restore(flags);
-		return;
+		return 0;

Ohh-oh! This is clearly a failure schenario! And indeed, "tick_init_highres()" will do the "negative on failure, zero on success" thing.

BUT! That means that you're testing the return value WRONG!

A function that returns a negative error value should be tested with

	if (tick_init_highres() < 0) {
		local_irq_restore(flags);
		return 0;
	}

because now you *see* that it's a failure.

So here's the coding style:

- "true on success, false on failure" should be tested by just doing the implicit test against zero (because that's how C booleans work!)

   Example:

	if (everything_is_done())
		return;

   Or:

	if (!something_worked_ok()) {
		printk("Aiee! Bug!\n");
		return;
	}

- "negative error values" should preferably always be tested as such

Quoted 9 lines
	if (tick_init_highres() < 0) {
		printk("Aieee! Couldn't init!\n");
		return 0;
	}

or, much better, actually use a temporary variable called "err" or "error" or something, at which point "!error" is suddenly readable again:

[1b]

Quoted 3 lines
	err = tick_init_highres();
	if (!err)
		return;

So this one above and [2] below lose the obvious "negative error" information, and also prevent such functions from returning a positive value (> 0), e.g., to indicate a successful amount of work done (like bytes read or written). The second version above [1b] also does not quite agree with your statement:
- "negative error values" should preferably always be tested as such

so in the interest of CodingStyle, can you be even clearer?

Quoted 5 lines

I know this sounds stupid, but we've long since come to the point where source code readability on a *local* scale is damn important, simply because that's how people look at code: they may not always remember whether "zero is success" or "zero is false".

Quoted 7 lines

In general, I would suggest:

- ALWAYS use "negative means error". If you had done that in this case, then hrtimer_switch_to_hres() would have been a lot more readable, *and* it could actually have returned the error code that it got to the caller. In general, it's just more information when you see

[2]

Quoted 54 lines
	error = some_function();
	if (error)
		return error;

because even if it may generate basically *exactly* same code as the reversed "positive" version:

	if (!some_version_is_true())
		return 0;

it simply has more semantic information for *humans*.

And when you do this, *test it as such*. Either use an explicit "< 0" so that you *see* that you're testing an error value, or use that "retval/error = xyzzy()" pattern that is already showing "it's more than just true/false"

- use "true/false" only for things where it's *really* obvious that the answer is never an error, and always a "was it true"?

Yeah, even so, the true/false kind of thing may be more common (especially with small helper functions that are literally *designed* to be used just as a conditional), but I think in this case, you really should have done it as a "returns error" function. Partly because now it was throwing away an error code, partly simply because in this case, it really wasn't about true/false as much as about "did something error out and keep it from succeeding?".

Maybe I'm just getting anal in my old age. I at one time tried to make sparse check for these things, but there was no really sane thing I could come up with (way way WAAY too much manual annotation).

I might have to break down and suggest people use

	bool somefunction(..)
	{
		if (... < 0)
			return false;
		...
		return true;
	}

just to (a) eventually have sparse check for these things but more importantly (b) have people see more at a glance whether a function is supposed to return "negative or success" or "true or false".

I've not generally been a huge fan of "boolean", especially in the traditional C kind of sense (capital screaming letters, and really just an "int" with lipstick). But with modern C, and "bool" defined as really holding just 0/1 (in practice - "unsigned char"), we could actually check these things (and verify with sparse that you never assign any integer except for 0/1 to a boolean, and otherwise always have to use a real boolean construct).

Quoted 3 lines

Thus endeth my overly long coding style rant.

Linus

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

#178 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

In reply to Michael S. Tsirkin
Quoted 22 lines · Michael S. Tsirkin
Quoted 14 lines

Quoting Ingo Molnar <[email protected]>:
Subject: Re: [5/6] 2.6.21-rc2: known regressions

Quoted 8 lines · Michael S. Tsirkin
Quoted 3 lines

Quoting Linus Torvalds <[email protected]>:

Ok, it does indeed solve the problem for me.

Not yet for me unfortunately, although this seems to help. Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445

Quoted 7 lines
Quoted 4 lines

With this applied, on resume I get *some* screen output soon after resume (e.g. with s2ram I get several characters on VGA, X starts drawing some windows) but then the crescent symbol starts blinking again and the system hangs.

could you try this via s2ram on a text console, to see whether the kernel spits out any warning before it locks up?

Quoted 6 lines

Yes, that's what I did. Unfortunately only a couple of characters were shown before it locked up.

I still need to check what does this do in the NO_HZ configuration.

BTW, Ingo, can you suspend/resume any number of times with this patch?

well I could at least two times in a row in my minimalistic setup (config attached) however using the full kernel config it still hangs ... (config also attached in case you watn to compare it).

Soeren

Signature · 2 lines
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
#179 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

Quoted 6 lines · Soeren Sonnenburg
Quoted 2 lines

BTW, Ingo, can you suspend/resume any number of times with this patch?

well I could at least two times in a row in my minimalistic setup (config attached) however using the full kernel config it still hangs ... (config also attached in case you watn to compare it).

i can confirm that with your full config i see a hang too. This is most likely the ACPI problem - we are debugging this now and will come up with a patch.

Ingo

#180 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

Quoted 13 lines

Quoting Ingo Molnar <[email protected]>:
Subject: Re: [5/6] 2.6.21-rc2: known regressions

Quoted 6 lines · Soeren Sonnenburg
Quoted 2 lines

BTW, Ingo, can you suspend/resume any number of times with this patch?

well I could at least two times in a row in my minimalistic setup (config attached) however using the full kernel config it still hangs ... (config also attached in case you watn to compare it).

Quoted 5 lines

i can confirm that with your full config i see a hang too. This is most likely the ACPI problem - we are debugging this now and will come up with a patch.

Ingo

Here's mine too, in case someone's interested.

Signature · 1 line
MST
#181 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

In reply to Ingo Molnar
Quoted 10 lines · Ingo Molnar
Quoted 6 lines
Quoted 2 lines

BTW, Ingo, can you suspend/resume any number of times with this patch?

well I could at least two times in a row in my minimalistic setup (config attached) however using the full kernel config it still hangs ... (config also attached in case you watn to compare it).

i can confirm that with your full config i see a hang too. This is most likely the ACPI problem - we are debugging this now and will come up with a patch.

update: this only happens with simulation, and even then it's not a full hang but 'hangs until i hit a key'. With real resume i'm hitting a real key anyway so it doesnt hang.

Ingo

#182 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

Quoted 12 lines

Quoting Ingo Molnar <[email protected]>:
Subject: Re: [5/6] 2.6.21-rc2: known regressions

Quoted 7 lines · Ingo Molnar
Quoted 6 lines
Quoted 2 lines

BTW, Ingo, can you suspend/resume any number of times with this patch?

well I could at least two times in a row in my minimalistic setup (config attached) however using the full kernel config it still hangs ... (config also attached in case you watn to compare it).

Quoted 7 lines
Quoted 3 lines

i can confirm that with your full config i see a hang too. This is most likely the ACPI problem - we are debugging this now and will come up with a patch.

update: this only happens with simulation, and even then it's not a full hang but 'hangs until i hit a key'. With real resume i'm hitting a real key anyway so it doesnt hang.

How 'bout my .config?

Signature · 1 line
MST
#183 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

Quoted 5 lines · Michael S. Tsirkin
Quoted 3 lines

update: this only happens with simulation, and even then it's not a full hang but 'hangs until i hit a key'. With real resume i'm hitting a real key anyway so it doesnt hang.

How 'bout my .config?

your config works fine here too - did full suspend/resume twice without any problems. Maybe it's the ACPI related regression Thomas is seeing.

Ingo

#184 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

In reply to Ingo Molnar
Quoted 9 lines · Ingo Molnar
Quoted 7 lines · Ingo Molnar
Quoted 6 lines
Quoted 2 lines

BTW, Ingo, can you suspend/resume any number of times with this patch?

well I could at least two times in a row in my minimalistic setup (config attached) however using the full kernel config it still hangs ... (config also attached in case you watn to compare it).

Quoted 7 lines
Quoted 3 lines

i can confirm that with your full config i see a hang too. This is most likely the ACPI problem - we are debugging this now and will come up with a patch.

update: this only happens with simulation, and even then it's not a full hang but 'hangs until i hit a key'. With real resume i'm hitting a real key anyway so it doesnt hang.

Hmm. The key is consumed in the BIOS, so there should be no interrupt. /me digs deeper.

tglx

#185 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

In reply to Soeren Sonnenburg
Quoted 3 lines · Soeren Sonnenburg
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

Not yet for me unfortunately, although this seems to help. Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445

Same problem for me on 2.6.21-rc2/rc1 on IBM X60s. I've applied this patch and Ingo Molnar's patch and s2ram still can't suspend. I tried turning off CONFIG_KVM as well, but makes no difference.

Will try turning off CONFIG_NO_HZ to see if this makes any difference. 2.6.20 works fine.
Jeff.

#186 lore raw

Re: [5/6] 2.6.21-rc2: known regressions

In reply to Michael S. Tsirkin

Hi!

Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 3 lines

Quoting Linus Torvalds <[email protected]>:

Ok, it does indeed solve the problem for me.

Not yet for me unfortunately, although this seems to help. Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445

With this applied, on resume I get *some* screen output soon after resume (e.g. with s2ram I get several characters on VGA, X starts drawing some windows) but then the crescent symbol starts blinking again and the system hangs.

Quoted 5 lines
Quoted 2 lines

could you try this via s2ram on a text console, to see whether the kernel spits out any warning before it locks up?

Yes, that's what I did. Unfortunately only a couple of characters were shown before it locked up.

Was it 'Linu'? That's different debugging hack.

Anyway, I suspect yout problem is debuggable with printk+mdelay...

Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#187 lore raw

PATCH 6/6 2.6.21-rc2: known regressions

In reply to Linus Torvalds

This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : sparc64 compile error due to GENERIC_ISA_DMA removal
References : http://bugzilla.kernel.org/show_bug.cgi?id€97
Submitter : Horst H. von Brand <[email protected]>

Caused-By David S. Miller <[email protected]>
             commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44

Status : unknown

Subject : mmc reader no longer works
References : http://lkml.org/lkml/2007/2/27/91
Submitter : Pavel Machek <[email protected]>

Caused-By Oliver Neukum <[email protected]>

Status : problem is being debugged

Subject : usb-serial broken
(ftdi serial device shows up as ttyUSB140 instead of ttyUSB0)
Submitter : Craig Schlenter <[email protected]>

Caused-By Oliver Neukum <[email protected]>
             commit 34ef50e5b1f96c2d8c0f3d28b7d407743806256c
Handled-By Oliver Neukum <[email protected]>

Status : patch available

Subject : Oops in rtc_cmos
References : http://lkml.org/lkml/2007/3/4/112

             http://lkml.org/lkml/2007/2/18/172

Submitter : Paul Rolland <[email protected]>
Rafael J. Wysocki <[email protected]>

Caused-By David Brownell <[email protected]>
             commit 7be2c7c96aff2871240d61fef508c41176c688b5

Patch : http://lkml.org/lkml/2007/2/23/184
Status : patch available

maintainer
#188 lore raw

Re: [6/6] 2.6.21-rc2: known regressions

From: Adrian Bunk <[email protected]>
Date: Mon, 5 Mar 2007 02:50:45 +0100

Quoted 6 lines

Subject : sparc64 compile error due to GENERIC_ISA_DMA removal
References : http://bugzilla.kernel.org/show_bug.cgi?id€97
Submitter : Horst H. von Brand <[email protected]>

Caused-By David S. Miller <[email protected]>
             commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44

Status : unknown

Fixed in current GIT.

commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10

Author: David S. Miller <[email protected]>
Date:   Wed Feb 28 13:09:34 2007 -0800

[SPARC64]: Fix parport_pc build.

Signed-off-by David S. Miller <[email protected]>
#189 lore raw

Re: [6/6] 2.6.21-rc2: known regressions

Quoted 12 lines · David Miller

From: Adrian Bunk <[email protected]>
Date: Mon, 5 Mar 2007 02:50:45 +0100

Quoted 6 lines

Subject : sparc64 compile error due to GENERIC_ISA_DMA removal
References : http://bugzilla.kernel.org/show_bug.cgi?id€97
Submitter : Horst H. von Brand <[email protected]>

Caused-By David S. Miller <[email protected]>
             commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44

Status : unknown

Fixed in current GIT.

Quoted 7 lines

commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10

Author: David S. Miller <[email protected]>
Date:   Wed Feb 28 13:09:34 2007 -0800

[SPARC64]: Fix parport_pc build.

Signed-off-by David S. Miller <[email protected]>

Horst's problem is with the floppy driver and claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h .

cu
Adrian

Signature · 4 lines
       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed
maintainer
#190 lore raw

Re: [6/6] 2.6.21-rc2: known regressions

From: Adrian Bunk <[email protected]>
Date: Mon, 5 Mar 2007 03:26:02 +0100

Quoted 17 lines · David Miller
Quoted 16 lines

From: Adrian Bunk <[email protected]>
Date: Mon, 5 Mar 2007 02:50:45 +0100

Quoted 6 lines

Subject : sparc64 compile error due to GENERIC_ISA_DMA removal
References : http://bugzilla.kernel.org/show_bug.cgi?id€97
Submitter : Horst H. von Brand <[email protected]>

Caused-By David S. Miller <[email protected]>
             commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44

Status : unknown

Fixed in current GIT.

commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10

Author: David S. Miller <[email protected]>
Date:   Wed Feb 28 13:09:34 2007 -0800
Quoted 6 lines
Quoted 3 lines

[SPARC64]: Fix parport_pc build.

Signed-off-by David S. Miller <[email protected]>

Horst's problem is with the floppy driver and claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h .

Thanks for the clarification, I was thinking of the parport problem reported by Meelis Roos.

I'll look into this.

maintainer
#191 lore raw

Re: [6/6] 2.6.21-rc2: known regressions

In reply to Adrian Bunk

From: Adrian Bunk <[email protected]>
Date: Mon, 5 Mar 2007 03:26:02 +0100

Quoted 17 lines · David Miller
Quoted 16 lines

From: Adrian Bunk <[email protected]>
Date: Mon, 5 Mar 2007 02:50:45 +0100

Quoted 6 lines

Subject : sparc64 compile error due to GENERIC_ISA_DMA removal
References : http://bugzilla.kernel.org/show_bug.cgi?id€97
Submitter : Horst H. von Brand <[email protected]>

Caused-By David S. Miller <[email protected]>
             commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44

Status : unknown

Fixed in current GIT.

commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10

Author: David S. Miller <[email protected]>
Date:   Wed Feb 28 13:09:34 2007 -0800
Quoted 6 lines
Quoted 3 lines

[SPARC64]: Fix parport_pc build.

Signed-off-by David S. Miller <[email protected]>

Horst's problem is with the floppy driver and claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h .

Here is the fix I will send to Linus for this, thanks:

commit 08414aa2516da65ae7a522c6834b8ea576f38c4b

Author: David S. Miller <[email protected]>
Date:   Sun Mar 4 20:36:18 2007 -0800

[SPARC64]: Fix floppy build failure.

Just define a local {claim,release}_dma_lock() implementation for the floppy driver to use so we don't need to define and export to modules the silly dma_spin_lock.

Signed-off-by David S. Miller <[email protected]>
include/asm-sparc64/dma.h +0 -11
index 1bf4f7a..a9fd061 100644
@@ -15,17 +15,6 @@
 #include <asm/delay.h>
 #include <asm/oplib.h>
 
-extern spinlock_t  dma_spin_lock;
-
-#define claim_dma_lock() \
-({	unsigned long flags; \
-	spin_lock_irqsave(&dma_spin_lock, flags); \
-	flags; \
-})
-
-#define release_dma_lock(__flags) \
-	spin_unlock_irqrestore(&dma_spin_lock, __flags);
-
 /* These are irrelevant for Sparc DMA, but we leave it in so that
  * things can compile.
  */
include/asm-sparc64/floppy.h +11 -0
index dbe033e..331013a 100644
@@ -854,4 +854,15 @@ static unsigned long __init sun_floppy_init(void)
 
 #define EXTRA_FLOPPY_PARAMS
 
+static DEFINE_SPINLOCK(dma_spin_lock);
+
+#define claim_dma_lock() \
+({	unsigned long flags; \
+	spin_lock_irqsave(&dma_spin_lock, flags); \
+	flags; \
+})
+
+#define release_dma_lock(__flags) \
+	spin_unlock_irqrestore(&dma_spin_lock, __flags);
+
 #endif /* !(__ASM_SPARC64_FLOPPY_H) */
#192 lore raw

Re: [6/6] 2.6.21-rc2: known regressions

In reply to Adrian Bunk
Quoted 8 lines · Adrian Bunk

Subject : usb-serial broken
(ftdi serial device shows up as ttyUSB140 instead of ttyUSB0)
Submitter : Craig Schlenter <[email protected]>

Caused-By Oliver Neukum <[email protected]>
             commit 34ef50e5b1f96c2d8c0f3d28b7d407743806256c
Handled-By Oliver Neukum <[email protected]>

Status : patch available

Patch is queued up in my tree and will go to Linus in a few days.

But I think there is another usb-serial patch that Oliver needs to send me to fix another problem with the usb-serial core...

thanks,

greg k-h