Wouldn't the time taken by an easy syscall like getuid be a clear indicator?
OG.
On Thu, Jan 11, 2018 at 8:17 PM, Dave Hansen
wrote:
> On 01/11/2018 11:07 AM, Borislav Petkov wrote:
>> On Thu, Jan 11, 2018 at 10:57:51AM -0800, Dave Hansen wrote:
>>> I'd love to have a tool that tells you for
Wasn't/Isn't the 4G/4G memory layout for 32 bits essentially KPTI?
OG.
On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek wrote:
> Hi!
>
>> The one thing I want to do now that Meltdown and Spectre are public,
>> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
>> particular
On Tue, Oct 3, 2017 at 5:22 AM, Adam Borowski wrote:
> Well, what about just \n then? Unlike all the others which are relatively
> straightforward, \n requires -print0 which not all programs implement, and
> way too many people consider too burdensome to use.
If you don't use -print0, you're vul
On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman
wrote:
> Bringing up SCM_RIGHTS means that this is not going to be a bus system
> at all. One principal design goal is to _not_ have peer-to-peer
> connections between all communicating parties, but rather one connection
> to a central componen
Hi,
Beware that could be opening the door to information leaks for a very
small gain (most syscalls are not getuid).
Best,
OG.
On Sat, Mar 28, 2015 at 1:34 AM, Denys Vlasenko
wrote:
> On Fri, Mar 27, 2015 at 9:00 PM, Linus Torvalds
> wrote:
>> On Fri, Mar 27, 2015 at 7:25 AM, Denys Vlase
On Wed, Jul 9, 2014 at 7:49 PM, Sebastian Andrzej Siewior
wrote:
> + * The lock assumption made here is none because runtime-pm suspend/resume
> + * callbacks should not be invoked there is any operation performed on the
> port.
I think there's a missing "if"?
Best,
OG.
--
To unsubscribe fro
On Tue, Jul 16, 2013 at 9:32 AM, David Lang wrote:
> On Mon, 15 Jul 2013, Sarah Sharp wrote:
>
>> The people who want to work together in a civil manner should get
>> together and create a "Kernel maintainer's code of conduct" that
>> outlines what they expect from fellow kernel developers. The p
On Sat, Jul 14, 2012 at 12:33:51AM +0200, Jesper Juhl wrote:
> How about we start cutting down on the options and start saying "a Linux
> system will provide feature x and y - always ...".
> Stuff like (and I'm just pulling random stuff out here) - ASLR, seccomp,
> 250HZ minimum etc etc.. We coul
On Mon, Feb 04, 2008 at 05:57:47PM -0500, Jeff Garzik wrote:
> iSCSI and NBD were passe ideas at birth. :)
>
> Networked block devices are attractive because the concepts and
> implementation are more simple than networked filesystems... but usually
> you want to run some sort of filesystem on
On Sun, Feb 03, 2008 at 09:02:08PM +, Al Viro wrote:
> On ppc64 relocs => r/w, AFAICS. On other targets we might have any number
> of other rules.
And -fpic/PIC => (relocs => r/w) because of the DT_TEXTREL crap. Not
of immediate interest to the kernel though.
OG.
--
To unsubscribe from th
On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] wrote:
> The malloc attribute is exactly about this : giving the compiler the
> indication that no other pointer aliases this object, allowing for
> better optimizations.
If you put a malloc attribute on the allocator and no free attribut
On Thu, Jan 17, 2008 at 09:02:44PM -0800, David Schwartz wrote:
> 3) It is most useful for 'kfree' to be non-const because destroying an
> object through a const pointer can easily be done in error. One of the
> reasons you provide a const pointer is because you need the function you
> pass the poi
On Fri, Jan 18, 2008 at 08:53:44AM -0500, Andy Lutomirski wrote:
> I'd say this implies the exact opposite. It almost sounds like the
> compiler is free to change:
>
> void foo(const int *x);
> foo(x);
> printf("%d", x);
>
> to:
>
> void foo(const int *x);
> printf("%d", x);
> foo(x);
That's
On Fri, Jan 04, 2008 at 11:38:29AM -0500, Alan Stern wrote:
> How about changing it to say "unavailable"? That doesn't imply
> permanence.
How about not changing a userland-visible interface gratuitously?
OG.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On Mon, Dec 17, 2007 at 06:08:59PM +0200, Boaz Harrosh wrote:
> Below fixes a deadly typo. Might as well be included in 2.6.24
You're sure ? scsi_for_each_sg includes a (sg)++ already...
> scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) {
> sg->data = cpu_to_l
On Mon, Nov 26, 2007 at 05:17:18PM +0100, Jan Engelhardt wrote:
> rpm -b does not work in opensuse anymore (redirects you to use rpmbuild), and
> I
> bet fedora will do the same, so if you don't have rpm-build, tough luck for
> make rpm.
The point, if I understand it correctly, was that when rpmb
Original thread btw:
http://www.ussg.indiana.edu/hypermail/linux/kernel/9907.0/0132.html
OG.
-
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 th
On Thu, Nov 22, 2007 at 07:17:14PM +0100, Jan Kara wrote:
> Hi,
>
> I guess subject says it all - why is FIBMAP ioctl restricted only to
> root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any
> special capabilities so we are inconsistent here too...
> Would anyone mind if
T'was done as a21101c46ca5b4320e31408853cdcbf7cb1ce4ed. The system is
a latitude x300 (i855GM). With '1', the old default, I can close and
re-open the lid and have nothing happening. With '0' the screen turns
black with the mouse cursor left frozen on top of it and the computer
crashed.
Closing
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote:
> Totally unrelated indeed so why are spouting crap? If the kohab list has a
> problem take it up with them but keep ALSA out of it. alsa-devel has only
> ever moderated out spam -- nothing else.
That is incorrect. Hopefully it is the
On Wed, Oct 24, 2007 at 03:38:04PM +0200, Jens Axboe wrote:
> (please don't drop cc lists)
Sorry. Reactions of people to Cc vary...
> That doesn't make any sense. Both sg_set_buf() and sg_set_page() set the
> same thing in the sg entry, the input is just different. It has nothing
> to do with s
On Wed, Oct 24, 2007 at 11:12:42AM +0200, Jens Axboe wrote:
> sg_set_buf() also sets length and offset, sg_set_page() is just a mirror
> of that. So I'd prefer to keep the naming.
Hmmm, sg_set_phys/sg_set_virt to be more symmetrical to
sg_phys/sg_virt?
OG.
-
To unsubscribe from this list: send
On Tue, Oct 02, 2007 at 11:49:04PM +0200, Jimmy wrote:
> Also, how about a list of PROS, explain to me whats so cool about it?
People who do binary-only drivers have a much better chance of not
doing a derivative work when they only use non-EXPORT_GPL exports, and
as a result not being in the wron
On Mon, Oct 01, 2007 at 09:04:44AM -0700, Linus Torvalds wrote:
> For example, you security guys still debate "inodes" vs "pathnames", as if
> that was an either-or issue.
>
> Quite frankly, I'm not a security person, but I can tell a bad argument
> from a good one. And an argument that says "in
On Wed, Sep 26, 2007 at 08:43:44PM +0930, David Newall wrote:
> Olivier Galibert wrote:
> >chroot does not allow you to walk out if you're in.
>
> You're mistaken. Or more properly, further use of chroot lets you walk
> out. This really has been said be
On Wed, Sep 26, 2007 at 07:57:38PM +0930, David Newall wrote:
> As has been said, there are thousands of ways to break out of a chroot.
> It's just that one of them should not be that chroot lets you walk out.
chroot does not allow you to walk out if you're in. It only allows
you to walk outs
On Fri, Aug 24, 2007 at 05:43:47AM -0700, SL Baur wrote:
> Who uses code like this, by the way?
People who think Posix is an example to follow maybe? Not sure if it
would go past the maintainers though :-)
# define PTHREAD_MUTEX_INITIALIZER \
{ { 0, 0, 0, 0, 0, { 0 } } }
# ifdef __USE_GNU
# d
On Mon, Jun 25, 2007 at 02:58:02PM +0200, Takashi Iwai wrote:
> Hm... I don't agree much with the virtual relay device solution.
> I once experimentally implemented an ALSA-OSS virtual kernel driver.
> But, it just gives more complexity.
So instead you move the complexity in the library where it
On Mon, Jun 25, 2007 at 02:40:23PM +0200, Jan Engelhardt wrote:
>
> On Jun 25 2007 14:31, Takashi Iwai wrote:
> >> It was started in time when most cheap sound cards was without hw mixer.
> >> And .. when today you use ALSA on sound card without hw mixer still all
> >> this (past ?) problems are
On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote:
> So, do you mean the soft-mixing is the biggest issue? That's just a
> part of a design issue, and if we want to go to that way, the
> impelemtation would be trivial, regardless on ALSA or not. Totally
> irrelevant argument regarding
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio
On Thu, Jun 14, 2007 at 09:20:35PM -0400, Rob Landley wrote:
> Why do you keep saying "upgraded" to GPLv3? How is it an improvement to move
> from a small, simple, elegant, and tested implementation to something that's
> more complicated, less elegant, less coherent, totally untested, and full o
On Tue, May 29, 2007 at 10:03:32PM -0600, Robert Hancock wrote:
> -Validate that the area is reserved even if we read it from the
> chipset directly and not from the MCFG table. This catches the case
> where the BIOS didn't set the location properly in the chipset and
> has mapped it over other thi
On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote:
> On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
> > Ehh. Even for PCIe, why not use the normal accesses for the first 256
> > bytes? Problem solved.
>
> Ok, this patch also works. We still need to enable mmconfig space for
On Wed, May 02, 2007 at 11:52:36AM +0200, Andi Kleen wrote:
> On Wednesday 02 May 2007 02:50:11 Olivier Galibert wrote:
> > On i945, a mmconfig range hitting the f000- zone conflicts
> > with the APIC registers and others. Consider it invalid.
> >
> > On
On i945, a mmconfig range hitting the f000- zone conflicts
with the APIC registers and others. Consider it invalid.
On E7520, values and f000 for the window register are defined
invalid in the documentation.
---
I haven't seen a bios use these values, but who trusts biosen thes
On Sun, Apr 29, 2007 at 08:14:37PM -0600, Robert Hancock wrote:
> -Validate that the area is reserved even if we read it from the
> chipset directly and not from the MCFG table. This catches the case
> where the BIOS didn't set the location properly in the chipset and
> has mapped it over other thi
On Thu, Apr 26, 2007 at 03:49:51PM -0700, David Lang wrote:
> swap partitions are limited to 2G (or at least they were a couple of months
> ago when I last checked). I also don't want to run the risk of having a box
> try to _use_ 16G worth of swap. I'd rather have the box hit OOM first.
They ar
On Fri, Apr 27, 2007 at 06:50:56AM +1000, Nigel Cunningham wrote:
> I'm perfectly willing to think through some alternate approach if you
> suggest something or prod my thinking in a new direction, but I'm afraid
> I just can't see right now how we can achieve what you're after.
Ok, what about thi
On Thu, Apr 26, 2007 at 01:09:53PM +0200, Pavel Machek wrote:
> #define SNAPSHOT_SET_IMAGE_SIZE _IOW(SNAPSHOT_IOC_MAGIC, 6,
> unsigned long)
So I'm not supposed to be able to suspend the 16Gb-ram, 32bits servers
I have here?
OG.
-
To unsubscribe from this list: send the line "uns
On Wed, Apr 25, 2007 at 11:50:45AM -0700, Linus Torvalds wrote:
> .. but if the alternative is a feature that just isn't worth it, and
> likely to not only have its own bugs, but cause bugs elsewhere? (And yes,
> I believe STD is both of those. There's a reason it's called "STD". Go
> to google
On Wed, Apr 25, 2007 at 08:16:51PM +0100, Matt Sealey wrote:
> > +#define ata_id_has_AN(id) \
> > + ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \
> > + ((id)[78] & (1 << 5)) )
>
> ??
>
> > --- 2.6-git.orig/include/linux/libata.h
> > +++ 2.6-git/include/linux/libata.h
> > @@ -136,6
On Tue, Apr 24, 2007 at 04:41:58PM -0700, Linus Torvalds wrote:
> How many different magic ioctl's does the thing introduce? Is it really
> just *two* entry-points (and how simple are they, interface-wise), and
> nothing else?
Aren't you a little late to the party here? The userland version is
On Tue, Apr 24, 2007 at 01:53:27PM -0700, Kristen Carlson Accardi wrote:
> Check to see if an ATAPI device supports Asynchronous Notification.
> If so, enable it.
>
> changes from last version:
> * fix typo in ata_id_has_AN and make word 76 test more clear
> * If we fail to set the AN feature, ju
On Tue, Apr 24, 2007 at 08:49:04AM -0700, Kristen Carlson Accardi wrote:
> On Tue, 24 Apr 2007 12:23:04 +0200
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
>
> > Sorry for replying to Alan's reply, I missed the original mail.
> >
> > > > +#define ata_
Sorry for replying to Alan's reply, I missed the original mail.
> > +#define ata_id_has_AN(id) \
> > + ((id[76] && (~id[76])) & ((id)[78] & (1 << 5)))
(a && ~a) & (b & 32)
I don't think that does what you think it does, because at that point
it's a funny way to write 0 ((0 or 1) binary-and (0
On Wed, Apr 04, 2007 at 07:15:32PM +0100, Russell King wrote:
> *However* you still run into the issue that you do not know how many
> serial ports you will need to register a tty driver with the tty layer.
> Solve that technical problem and the idea of having a single namespace
> for chosen serial
On Wed, Apr 04, 2007 at 12:14:34PM +0100, Alan Cox wrote:
> > If you want hierarchy, create it:
> >
> > /sys/blah/serial/controllerX/portY
> >
> > and keeping them all under the ttyS? major keeps the simple
> > cases working sanely too.
>
> Currently yes you could do that, but that would break a
On Thu, Mar 22, 2007 at 02:33:14PM +, Al Viro wrote:
> Correction: current ABI is crap. To set the thing up you need to open
> it and issue an ioctl. Which is a bloody bad idea, for obvious reasons...
Agreed. What would be a right way? Global device ala ptmx/tun/tap?
New syscall? Somethin
On Tue, Feb 13, 2007 at 10:57:24PM +0100, Ingo Molnar wrote:
>
> * Davide Libenzi wrote:
>
> > > Open issues:
>
> > If this is going to be a generic AIO subsystem:
> >
> > - Cancellation of pending request
>
> How about implementing aio_cancel() as a NOP. Can anyone prove that the
> kernel d
On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
> I agree that making strxxx() family special is not a good idea. So what
> do we do for a random foo(char*) called with an 'unsigned char*'
> argument? Silence? Hmmm... It's not immediately obvious that it's indeed
> harmless. Yet ano
On Wed, Feb 14, 2007 at 02:35:15AM +0900, Ian Kent wrote:
> On Tue, 2007-02-13 at 16:54 +0100, Olivier Galibert wrote:
> > Don't they require autofs5 to be of any use though? That's not going
> > to be in fc until it's out of beta I guess.
>
> Not really?
On Tue, Feb 13, 2007 at 09:07:27AM -0500, Chuck Ebbert wrote:
> Olivier Galibert wrote:
> > On Tue, Feb 13, 2007 at 09:52:39AM +0900, Ian Kent wrote:
> >> Indeed.
> >> Which kernel can you use?
> >> I believe that 2200 had another problem so can you us
On Tue, Feb 13, 2007 at 09:52:39AM +0900, Ian Kent wrote:
> Indeed.
> Which kernel can you use?
> I believe that 2200 had another problem so can you use an fc5 kernel
> later than that?
I've ported your patch to 2257 (nothing special, only moved lines),
and it seems to work beautifully. I'm enlar
On Mon, Feb 12, 2007 at 03:43:14PM +0900, Ian Kent wrote:
> On Thu, 2007-02-08 at 11:33 +0900, Ian Kent wrote:
> > On Wed, 2007-02-07 at 19:18 +0100, Olivier Galibert wrote:
> > > On Thu, Feb 08, 2007 at 03:07:41AM +0900, Ian Kent wrote:
> > > > It may be better to
On Thu, Feb 08, 2007 at 03:07:41AM +0900, Ian Kent wrote:
> It may be better to update to a later kernel so I don't have to port the
> patch to several different kernels. Is that possible?
Sure, 2.6.20 or -git?
OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, Jan 18, 2007 at 03:08:46PM +0100, Olivier Galibert wrote:
> On Mon, Jan 15, 2007 at 11:14:52PM +, Alan wrote:
> > > Both smart and the internal blade diagnostics say "everything is a-ok
> > > with the drive, there hasn't been any error ever except a bu
The setup:
/people is a NIS automount. /people/gadda points to m179:/disk05/disk11/gadda
/hosts is a two-level automount, /hosts/xx/yy points to xx:/yy using:
in auto.master:
/hosts file:/etc/auto.hosts
in /etc/auto.hosts:
* -fstype=autofs,-Dhost=& file=/etc/auto.hosts.sub
in /etc/auto.
On Tue, Jan 30, 2007 at 01:26:31AM -0800, Andrew Morton wrote:
> Len, what was in that merge anyway? Lots of renaming and shuffling things
> around - the sorts of things which are safe as long as they compile OK. But
> was there much substantive material in there as well?
It seems heavy in gener
On Mon, Jan 29, 2007 at 08:45:28PM -0800, Andrew Morton wrote:
> -x86_64-mm-share-whats-shareable.patch
> -x86_64-mm-only-call-unreachable_devices-when-type-1-is-available.patch
> -x86_64-mm-only-map-whats-necessary.patch
> -x86_64-mm-detect-and-support-the-e7520-and-the-945g-gz-p-pl.patch
> -x86_6
On Mon, Jan 15, 2007 at 11:14:52PM +, Alan wrote:
> > Both smart and the internal blade diagnostics say "everything is a-ok
> > with the drive, there hasn't been any error ever except a bunch of
> > corrected ECC ones, and no more than with a similar drive in another
> > working blade". Hence
On Mon, Jan 08, 2007 at 01:27:15PM -0800, Jesse Barnes wrote:
> On Monday, January 8, 2007 12:45 pm, Olivier Galibert wrote:
> > On Sun, Jan 07, 2007 at 11:44:16AM -0800, Jesse Barnes wrote:
> > > For reference, here's the probe routine I tried for 965, probably
> > &
On Sun, Jan 14, 2007 at 06:27:18AM +0900, OGAWA Hirofumi wrote:
> This rejects a broken MCFG tables on Asus etc.
> Arjan and Andi suggest this.
And I agree completely with the principle. If you don't know the
chipset on a first-name basis, trash the MCFG unless it's squeaky
clean (or you don't ha
On Tue, Jan 16, 2007 at 03:47:52PM +, Alan wrote:
> The drives do that automatically, and the SCSI verify did it for him too
> if there were any other problems.
The SCSI verify didn't see a thing, I'm gonna do the disk swapping
dance.
OG.
-
To unsubscribe from this list: send the line "uns
On Mon, Jan 15, 2007 at 11:14:52PM +, Alan wrote:
> If you pull the drive and test it in another box does it show the same ?
I'm going to try that. The prolem requires 3-7 days to appear, so I
won't know immediatly.
> And what does a scsi verify have to say ?
Running, looks like it's gonna
On Tue, Jan 16, 2007 at 12:27:17AM +0100, Stefan Richter wrote:
> On 15 Jan, Olivier Galibert wrote:
> > sd 0:0:0:0: SCSI error: return code = 0x0802
> > sda: Current: sense key: Hardware Error
> > ASC=0x42 ASCQ=0x0
>
> The Additional Sense Code means "pow
On Mon, Jan 15, 2007 at 06:45:40PM +, Alan wrote:
> On Mon, 15 Jan 2007 18:16:02 +0100
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
>
> > sd 0:0:0:0: SCSI error: return code = 0x0802
> > sda: Current: sense key: Hardware Error
> > ASC=0x42 ASCQ=0
sd 0:0:0:0: SCSI error: return code = 0x0802
sda: Current: sense key: Hardware Error
ASC=0x42 ASCQ=0x0
Info fld=0x400802c
end_request: I/O error, dev sda, sector 202369
Aborting journal on device sda1.
journal commit I/O error
ext3_abort called.
EXT3-fs error (device sda1): ext3_journal_sta
er chips. But since I didn't have platforms
> to test such additions on, they're left out for now.
>
> Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
Andrew, you sent me a series of emails to tell me the patches h
On Sun, Jan 07, 2007 at 11:44:16AM -0800, Jesse Barnes wrote:
> For reference, here's the probe routine I tried for 965, probably something
> dumb wrong with it that I'm not seeing atm.
It shouldn't have mattered in your case, but base_address is limited
to 32bits. There is a 32 bits reserved zo
On Sun, Jan 07, 2007 at 11:42:09AM -0800, Jesse Barnes wrote:
> This patch updates Oliver's MMConfig bridge detection patches with support
> for 915G bridges. It seems to work ok on my 915GM laptop.
Looks ok to me.
> I also tried adding 965 support, but it doesn't work (at least not on my
> G96
Sorry I missed the original email, but what is the chipset (name, pci
ID) of the board(s) with the problematic bios?
OG.
-
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/majordo
On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote:
> 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> before link is seen can easily take upto 45 seconds already.
> That's a network topology/hardware issue (spanning tree fun) that
> software or even the hardwa
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> [1] What kind of latency would be allowed? Would an implementation be
> allowed to power up the phy say once per minute or once per 5 minutes to
> see if there is link? The implementation could do this progressively;
> first poll e
Is there a way to know if there has been I/O error(s) on a specific
disk or partition since boot other than parsing dmesg and hoping it's
both still there and in the expected format?
Of course that's if the error didn't kill the system in the first
place :-)
OG.
-
To unsubscribe from this list
;
}
}
*offset += size;
return size;
}
case MODE_MAILBOX: {
size_t cur_size = size;
for(;;) {
unsigned int val;
if(get_user(val, (unsigned int *)buf))
return -EFAULT;
iiadc64_mailbox_write(is.access_mbox, val);
buf += sizeof(unsigned int
On Thu, Dec 14, 2006 at 11:11:33AM -0500, Dave Jones wrote:
> On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
> > If a kernel developer or a competitor sends a cease&desist letter to
> > such a distribution, the situation changes from a complicated "derived
> > work" discussion to
On Thu, Dec 14, 2006 at 10:56:03AM +0100, Hans-Jürgen Koch wrote:
> A small German manufacturer produces high-end AD converter cards. He sells
> 100 pieces per year, only in Germany and only with Windows drivers. He would
> now like to make his cards work with Linux. He has two driver programmers
>
On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote:
> When I said hibernate, I did mention it was to disk, not to ram.
Suspend to disk is not trustable on Linux, and does not look like it
will be any time soon. Suspend to ram has a better chance of becoming
reliable, but at that poin
On Sat, Dec 09, 2006 at 01:58:29PM -0800, Andrew Morton wrote:
> On Sat, 9 Dec 2006 22:44:53 +0100
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
> > Hmmm, I don't understand. Which is the bug, having a sysfs file
> > creation fail or going on if it happens?
>
>
On Sat, Dec 09, 2006 at 12:38:17PM -0800, Andrew Morton wrote:
> On Sun, 10 Dec 2006 06:59:10 +1100
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > Why would I prevent the framebuffer from initializing (and thus a
> > console to be displayed at all on many machines) just because for some
>
On Sat, Dec 09, 2006 at 01:18:30AM +, Alan wrote:
> On Fri, 8 Dec 2006 20:05:07 -0500
> koan <[EMAIL PROTECTED]> wrote:
>
> > ata4: status=0x50 { DriveReady SeekComplete }
> > ata4: error=0x01 { AddrMarkNotFound }
>
> That looks like a genuine drive problem.
Is a disk driver supposed to BUG(
Add the stupid sco fixup quirk to yet another Broadcom/Kensington
device.
---
drivers/bluetooth/hci_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
index fdea58a..aeefec9 100644
--- a/drivers/bluetooth/hci_usb
It seems that the only way to reliably support mmconfig in the
presence of funky biosen is to detect the hostbridge and read where
the window is mapped from its registers. Do that for the E7520 and
the 945G/GZ/P/PL for a start.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arc
i386 and x86-64 pci mmconfig code have a lot in common. So share
what's shareable between the two.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/i386/pci/Makefile |2 +-
arch/i386/pci/mmconfig-shared.c | 86 +++
ar
The x86-64 mmconfig code always map a range of MMCONFIG_APER_MAX
bytes, i.e. 256MB, whatever the number of accessible busses is. Fix
it, and add the end of the zone in the printk while we're at it.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/x86_64/pci/mmconf
unreachable_devices compares between the results of pci configuration
accesses through type1 and mmconfig, so it should be called only if
type1 actually works in the first place.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/i386/pci/mmconfig-shared.c |3 ++-
1 files c
Put back the resource reservation as per
4c6e052adfe285ede5884e4e8c4d33af33932c13 but use it *only* when the
range(s) come from a chipset probe instead of the bios.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/i386/pci/mmconfig-shared.c | 33 ++
I'll try to be less messy this time.
OG.
1/5: PCI MMConfig: Share what's shareable.
Share code between i386 and x86-64
2/5: PCI MMConfig: Only call unreachable_devices() when type 1 is available.
Trivial fix.
3/5: PCI MMConfig: Only map what's necessary.
Trivial fix too.
4/5: PCI MM
On Thu, Dec 07, 2006 at 06:03:17PM +0200, Muli Ben-Yehuda wrote:
> On Thu, Dec 07, 2006 at 04:53:36PM +0100, Olivier Galibert wrote:
>
> > # git grep '//' -- '*.c' |fgrep -v 'http://' |wc -l
> > 14333
> >
> > You lost that war ages
On Thu, Dec 07, 2006 at 05:35:06PM +0200, Muli Ben-Yehuda wrote:
> arch/i386/pci/pci.h seems the least-inappropriate.
Ok, will do.
> Also, forgot to mention, please get rid of C++ style comments in the
> code.
# git grep '//' -- '*.c' |fgrep -v 'http://' |wc -l
14333
You lost that war ages ago
On Thu, Dec 07, 2006 at 05:00:23PM +0200, Muli Ben-Yehuda wrote:
> On Thu, Dec 07, 2006 at 03:49:53PM +0100, Olivier Galibert wrote:
>
> > +void __init pci_mmcfg_init(int type)
> > +{
> > + extern int pci_mmcfg_arch_init(void);
>
> Please put this in a suit
unreachable_devices compares between the results of pci configuration
accesses through type1 and mmconfig, so it should be called only if
type1 actually works in the first place.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/i386/pci/mmconfig-shared.c |3 ++-
1 files c
It seems that the only way to reliably support mmconfig in the
presence of funky biosen is to detect the hostbridge and read where
the window is mapped from its registers. Do that for the E7520 and
the 945G/GZ/P/PL for a start.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arc
i386 and x86-64 pci mmconfig code have a lot in common. So share
what's shareable between the two.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/i386/pci/Makefile |2 +-
arch/i386/pci/mmconfig-shared.c | 88 +++
ar
Put back the resource reservation as per
4c6e052adfe285ede5884e4e8c4d33af33932c13 but use it *only* when the
range(s) come from a chipset probe instead of the bios.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/i386/pci/mmconfig-shared.c | 33 ++
The x86-64 mmconfig code always map a range of MMCONFIG_APER_MAX
bytes, i.e. 256MB, whatever the number of accessible busses is. Fix
it, and add the end of the zone in the printk while we're at it.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
---
arch/x86_64/pci/mmconf
Done in 5 steps, at Andi's very reasonable request:
1/5: PCI MMConfig: Share what's shareable.
Share code between i386 and x86-64
2/5: PCI MMConfig: Only call unreachable_devices() when type 1 is available.
Trivial fix.
3/5: PCI MMConfig: Only map what's necessary.
Trivial fix too.
4/5: P
On Mon, Nov 27, 2006 at 09:24:06PM +0100, Olivier Galibert wrote:
> On Mon, Nov 27, 2006 at 08:07:48PM +0100, Andi Kleen wrote:
> > Is that with just the code movement patch or your feature patch
> > added too? If the later can you test it with only code movement
> > (and co
On Mon, Nov 27, 2006 at 08:07:48PM +0100, Andi Kleen wrote:
> Is that with just the code movement patch or your feature patch
> added too? If the later can you test it with only code movement
> (and compare against vanilla kernel). at least code movement
> only should behave exactly the same as unp
1 - 100 of 147 matches
Mail list logo
