This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 963873 - kernel-3.9.1-301.fc19 is unstable on Highbank
kernel-3.9.1-301.fc19 is unstable on Highbank
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
arm Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jon Masters
Fedora Extras Quality Assurance
AcceptedFreezeException
: Reopened
: 956831 (view as bug list)
Depends On:
Blocks: F19Beta-accepted/F19BetaFreezeException 901848
  Show dependency treegraph
 
Reported: 2013-05-16 13:11 EDT by Paul Whalen
Modified: 2013-05-20 20:57 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-20 20:57:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Paul Whalen 2013-05-16 13:11:23 EDT
Description of problem:
kernel-3.9.1-301.fc19 which is being used in F18 Beta is unstable on Calxeda Highbank systems. 

Version-Release number of selected component (if applicable):
kernel-3.9.1-301.fc19 

How reproducible:
Most of the time. 

Steps to Reproduce:
1. Boot to kernel-3.9.1-301.fc19 
2. 'dmesg | fpaste'
  
Actual results:
System will crash.


Expected results:
Url for the fpaste. 

Additional info:
This is resolved in kernel-3.9.2-301.fc19.
Comment 1 Josh Boyer 2013-05-16 13:14:08 EDT
(In reply to comment #0)
> Description of problem:
> kernel-3.9.1-301.fc19 which is being used in F18 Beta is unstable on Calxeda
> Highbank systems. 
> 
> Version-Release number of selected component (if applicable):
> kernel-3.9.1-301.fc19 
> 
> How reproducible:
> Most of the time. 
> 
> Steps to Reproduce:
> 1. Boot to kernel-3.9.1-301.fc19 
> 2. 'dmesg | fpaste'
>   
> Actual results:
> System will crash.
> 
> 
> Expected results:
> Url for the fpaste. 
> 
> Additional info:
> This is resolved in kernel-3.9.2-301.fc19.

Then why did you file a bug against the kernel?
Comment 2 Josh Boyer 2013-05-16 13:14:15 EDT
*** Bug 956831 has been marked as a duplicate of this bug. ***
Comment 3 Adam Williamson 2013-05-16 13:24:54 EDT
"Then why did you file a bug against the kernel?"

To mark it as a Freeze Exception issue for Beta. The FE / blocker tracking process relies on bugs.
Comment 4 Adam Williamson 2013-05-16 13:26:19 EDT
https://admin.fedoraproject.org/updates/FEDORA-2013-8162/kernel-3.9.2-301.fc19 is the update for this. +1 FE as a major issue on a secondary arch (ARM).
Comment 5 Josh Boyer 2013-05-16 13:51:18 EDT
(In reply to comment #3)
> "Then why did you file a bug against the kernel?"
> 
> To mark it as a Freeze Exception issue for Beta. The FE / blocker tracking
> process relies on bugs.

Great.  I'm going to just guess that it doesn't rely on bugs being in a non-closed state, and that kernel is already headed to stable.
Comment 6 Adam Williamson 2013-05-16 13:59:29 EDT
You could ask me, rather than just guessing, so we don't have to play this game of ping pong.

It does rely on the bugs being in a non-closed state, because otherwise how do we distinguish between a bug that's not a blocker, a bug that's a blocker that we've dealt with, and a bug that's a blocker that we haven't dealt with? And F19 is in freeze for Beta, so nothing goes to stable automatically. What I'm trying to do here, and you're trying as hard as possible to stop me doing, is _to get your kernel into stable_. It won't go there for Beta unless you leave this bug open.
Comment 7 Dennis Gilmore 2013-05-16 14:08:53 EDT
im +1 to including this in Beta
Comment 8 Kevin Fenzi 2013-05-16 14:10:36 EDT
+1 FE
Comment 9 Josh Boyer 2013-05-16 14:32:30 EDT
(In reply to comment #6)
> You could ask me, rather than just guessing, so we don't have to play this
> game of ping pong.
> 
> It does rely on the bugs being in a non-closed state, because otherwise how
> do we distinguish between a bug that's not a blocker, a bug that's a blocker
> that we've dealt with, and a bug that's a blocker that we haven't dealt
> with? And F19 is in freeze for Beta, so nothing goes to stable
> automatically. What I'm trying to do here, and you're trying as hard as
> possible to stop me doing, is _to get your kernel into stable_. It won't go
> there for Beta unless you leave this bug open.

No, what I'm trying to do is avoid having a second (yes second) pointless bug open in the kernel for an issue that is already fixed.  I realize you have no other tool at the moment other than bugzilla to use for your process, but if you can't read the contents of the bug to determine the answer to your 3 possible states then I would be disappointed.

Now, had people just gone with the original bug I marked as duplicate in comment #2, then maybe that would have made sense.  But opening another identical bug against an already stale kernel when there's already a kernel that is known to be fixed is just pointless.  MORE BUGS is not better.
Comment 10 Adam Williamson 2013-05-16 14:45:37 EDT
Well, you marked the old bug as a dupe of this one. If you'd marked this bug as a dupe of the old one, I would've used that one as the blocker/FE bug. I figured closing the old one as a dupe of this one meant you preferred us to use this one.

"if you can't read the contents of the bug to determine the answer to your 3 possible states then I would be disappointed"

that doesn't scale to dozens of proposed/accepted blockers/FEs. We have a page that gives us an overview of the blocker/FE bug set:

http://qa.fedoraproject.org/blockerbugs/current

which we use extensively. If a bug is CLOSED, it does not appear on that list.

And note that the Fedora policy is that bugs in Branched/Stable releases are closed *when the fix goes to stable*, not before. So per policy, this bug should be open until the kernel actually goes into stable anyway.
Comment 11 Jaroslav Reznik 2013-05-16 14:50:46 EDT
+1 FE

Josh, I can agree that Bugzilla is probably not a best fit for this process, especially voting there is pretty nasty and we are aware of it (it really helps speed up spinning composes closer to the release) but it's what we have now. I'd expect QA would be happy to hear any ideas how to improve it or tools proposals.
Comment 12 Adam Williamson 2013-05-16 14:53:06 EDT
Tim has a plan for pulling all the nomination / voting stuff into the blocker bug app, he just needs time to do it. But even if we do that, I don't see that we can stop relying on the actual open/closed state of the bug in Bugzilla. Really, I don't see that there's a problem here at all: it is correct that we CLOSE bugs when the fix is actually pushed stable, and not before. I don't think you can really argue with that.
Comment 13 Josh Boyer 2013-05-16 15:04:13 EDT
(In reply to comment #10)
> Well, you marked the old bug as a dupe of this one. If you'd marked this bug
> as a dupe of the old one, I would've used that one as the blocker/FE bug. I
> figured closing the old one as a dupe of this one meant you preferred us to
> use this one.

There was no clue this bug was being used for some kind of blocker process until after I'd made my comment and closed it originally.  Nothing in the comments, etc.

> 
> And note that the Fedora policy is that bugs in Branched/Stable releases are
> closed *when the fix goes to stable*, not before. So per policy, this bug
> should be open until the kernel actually goes into stable anyway.

We have no insight into whether a secondary arch includes a particular build in their version of stable.

Anyway, let's do this.  Let's assign it to the people that are actually responsible for this bug, and they can close it whenever they think is appropriate.  Nobody on kernel-maint is looking at this at all.
Comment 14 Josh Boyer 2013-05-16 15:06:39 EDT
(In reply to comment #12)
> Really, I don't see that there's a problem here at all: it
> is correct that we CLOSE bugs when the fix is actually pushed stable, and
> not before. I don't think you can really argue with that.

I can, because it's a secondary arch.  The tooling _we_ have (bodhi) does not mean that when the primary build gets pushed to stable, it's in ARM stable too.  They are completely decoupled by the very nature of it being a secondary arch.

Anyway, I'm done arguing.  My request for the future would be:

1) Don't file pointless duplicate bugs for the sake of process.  Use the original ones.

2) Assign secondary arch stuff to people that care about the secondary arches.
Comment 15 Adam Williamson 2013-05-16 15:17:15 EDT
Josh: I wasn't talking about ARM stable, I was talking about primary arch stable. The update is not yet in primary arch stable and will not go there until we are unfrozen unless it is explicitly pushed through the freeze.
Comment 16 Adam Williamson 2013-05-16 17:31:34 EDT
That's 4 +1s, setting acceptedFE.
Comment 17 Adam Williamson 2013-05-20 20:57:19 EDT
Update has now been pushed stable, closing.

Note You need to log in before you can comment on or make changes to this bug.