My only disagreement here would be putting it in the ia64 paths. If
someone does the same for x86-32 (and this is EFI so it'll presumbly
smell the same on all platforms) then we'll want the same.
Better I think to generically catch the 0/0 case.
Alan
--
To UNSUBSCRIBE, email to debian-bugs-dis
> Should this device be blacklisted from i2o_core? Are there likely other
> MegaRAID devices that use the I2O PCI class but don't work with this
> generic driver?
I²O will probe I²O class devices. How well it works depends upon the
firmware version of the specific board.
The fix in this case is
On Tue, 19 Apr 2011 13:50:12 +0200
Bartlomiej Zolnierkiewicz wrote:
> On Tue, Apr 19, 2011 at 12:08 PM, Alan Cox wrote:
> >> From: Bartlomiej Zolnierkiewicz
> >> Subject: [PATCH v2] pata_cmd64x: add enablebits checking
> >>
> >> Fixes IDE -> libata r
> From: Bartlomiej Zolnierkiewicz
> Subject: [PATCH v2] pata_cmd64x: add enablebits checking
>
> Fixes IDE -> libata regression.
And causes a regression too
With the check for parent bridge not being a split bridge I think however
it'll do the job nicely.
Alan
--
To UNSUBSCRIBE, email to d
> Before we do suspend, pick few random sectors from the media, run that
> through some hash function, thus creating some sort of watermark.
Statistically speaking the chances are you'll catch zero sectors and
lose. You'll also not detect the suspend, move to other box, use, put
back error. That i
> You do not cater for having more than one slot e.g. N900 has two:
> one internal non-removable and one external that is removable.
>
> What about a sysfs entry instead e.g.
>
> /sys/class/mmc-host/mmc*/nonremovable
That continues the assumption that the user will somehow ever know about
this
> I'm afraid that's insufficient. What it would need to do is to is
> flush everything (to make sure what's on disk matches what's in
> memory), but also read back the filesystem on resume to verify that
> nothing else modified it (i.e. making sure what's on disk still matches
> what's in memory).
On Wed, 18 Jun 2008 12:14:02 +0200
Gaudenz Steinlin <[EMAIL PROTECTED]> wrote:
> Hi
>
> The kernel modules for Mac on Linux (MOL) need handle_mm_fault.
> MOL is a GPL licensed virtual machine to run MacOS(X) on PPC Linux.
>
> The export for handle_mm_fault was removed with commit
> 41f9dc5c8716
> if (m5229_revision <= 0x20) {
> return 0;
> } else if ((m5229_revision < 0xC2) &&
So 0xC1 takes this path
> Looking back at the equivalent code in 2.4.27 (the previous kernel
> this machine ran), that's rather different:
>
> if (m5229_revision < 0xC1) {
> The drive is clearly broken. Adding blacklist to drivers/ide/ide-dma.c
> for this model ("CD-912E/ATK") fixes this problem.
That may be the case but knowing if th drive is the problem is more
tricky.
Firstly try it on a different controller
Secondly check for other firmware revisions
10 matches
Mail list logo
