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 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 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
mount --bind is a very nice tool to create multiple / directories for
diskless workstations. Or, well, would be, if knfsd accepted to
export them.
I didn't try with 2.4.3 yet, only with an earlier version, does it
work there? Or is it on womeone's todo? Doesn't seem that
impossible, at least i
On Wed, Jan 17, 2001 at 11:32:35AM -0800, Linus Torvalds wrote:
> However, for socket->socket, we would not have such an advantage. A
> socket->socket sendfile() would not avoid any copies the way the
> networking is done today. That _may_ change, of course. But it might
> not. And I'd rather
On Thu, Jan 18, 2001 at 10:04:28PM +0100, Andrea Arcangeli wrote:
> NAGLE algorithm is only one, CORK algorithm is another different algorithm. So
> probably it would be not appropriate to mix CORK and NAGLE under the name
> "CONTROL_NAGLING", but certainly I agree they could stay together under a
On Fri, Nov 17, 2000 at 03:27:28PM -0500, Richard B. Johnson wrote:
> Then, you read the port as a WORD (16 bits). If nothing responds,
> you get the value of 0x. If somebody is responding, you will
> read something if it's enabled for writes by devices (reads by the CPU).
What guarantees you
On Wed, Nov 29, 2000 at 04:40:29PM +, Tigran Aivazian wrote:
> b) what should be the return of access(W_OK) (or, the same, open() for
> write with switched uid) for devices on a readonly-mounted filesystems?
>
> Should the majority win? I.e. should we say OK, as we do now?
My gut feeling on
On Fri, Dec 01, 2000 at 09:05:23AM -0800, T. Camp wrote:
> Hmm didn't know that, from the user-land portable C perspective I'm in the
> habit of zero'ing everything. - thanks.
It's a requirement of the ISO C standard that all global/static (not
local) variables are initialized to 0 is not initial
I compiled in the support for the 3c985, but, somehow, the kernel does
not seem to see the card.
Dual p3, asus p2b-d motherboard, test9pre7+reiserfs.
OG.
slice cutoff: 731.88 usecs.
Getting VERSION: 40011
Getting VERSION: 40011
Getting ID: 100
Getting ID: e00
Getting LVT0: 8700
Gett
On Sat, Sep 30, 2000 at 11:29:13PM +0100, Alan Cox wrote:
> If you get
> a link error or a module load error about bad_udelay let me know.
insmod pcmcia_core.o from pcmcia 3.1.20 gets the T-shirt.
OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote:
> Why would this not have happened for a module?
>
> I agree that the thing looks fishy. But this is not new code, and it has
> worked previously. What changed?
Maybe nobody ever insmod'ed a module for a scsi device they don't
have?
On Tue, Sep 19, 2000 at 04:11:30PM -0700, David S. Miller wrote:
> Unfortunately, gcc does not make inline functions as cheap as "macros
> with type checking". There are extra costs and often the register
> allocator cannot cope and stuff starts getting spilled to the stack.
It is supposedly on
On Wed, Mar 28, 2001 at 03:04:46PM +0100, Simon Williams wrote:
> I think their point was that a program could only change permissions
> of a file that was owned by the same owner. If a file is owned by a
> different user & has no write permissions for any user, the program
> can't modify the fil
On Wed, Mar 28, 2001 at 04:49:26PM +0100, Simon Williams wrote:
> What I meant was that if a file is owned by root with permissions of,
> say, 555 (r-xr-xr-x), not setuid or setgid, then another executable
> run as a non-root user cannot modify it or change the permissions to
> 7 (rwx).
It's alre
On Tue, Apr 05, 2005 at 03:28:01PM -0400, Jeff Garzik wrote:
> * Most firmwares are a -collection- of images and data. The firmware
> infrastructure should load an -archive- of firmwares and associated data
> values.
Why don't you use multiple firmware loading calls with different
names? Maybe
On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
> Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit :
>
> > Then I would like to exercise my right under the GPL to aquire the source
> > code
> > for the firmware (and the required compilers, starting with genfw.c which
>
On Wed, May 23, 2001 at 07:07:38PM +1000, Keith Owens wrote:
> On Wed, 23 May 2001 09:17:08 +0200 (CEST),
> Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> >On Wed, 23 May 2001, Keith Owens wrote:
> >> Is drivers/char/ser_a2232fw.ax supposed to be included? Nothing uses it.
> >
> >It's the sourc
On Tue, Aug 16, 2005 at 07:04:34PM +0530, Mukund JB. wrote:
> Dear Lennart,
>
> I have bought a "entermultimedia" USB 2.0 21-in-1 card.
> There are no Linux driver support in the CD provided.
> Can u suggest me what is best bug (USB card reader) with Linux driver
> support in the Market.
It does
...or more importantly, is it allowed. Kernel is FC3 2.6.10-1.766.
The latest iscsi driver[1] blows on a 32K-long request for a tape write
which followed this path:
[] iscsi_queuecommand+0x161/0x2f1 [iscsi_tcp]
[] scsi_dispatch_cmd+0x1e9/0x24f [scsi_mod]
[] scsi_request_fn+0x29a/0x310 [scsi_m
On Tue, Apr 19, 2005 at 09:50:08AM +0100, Christoph Hellwig wrote:
> On Tue, Apr 19, 2005 at 10:47:30AM +0200, Olivier Galibert wrote:
> > ...or more importantly, is it allowed. Kernel is FC3 2.6.10-1.766.
>
> Yes, it's allowed.
Thanks. Pages in that case are continuou
If I get a struct page * from a call to alloc_pages with a non-zero
order, how do I get the struct page * of te following pages from the
same allocation in order to use them in calls to tcp_sendpage?
If there a documentation somewhere whcih would answer this kind of
questions? Couldn't find anyth
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote:
> Why doesn't initramfs use tmpfs instead of ramfs, because
> tmpfs is more robust?
>
> I know tmpfs is larger, but at least it should be an option.
>
> Also, tar should be an option instead of cpio for the archiver,
> because tar
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 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 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 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 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
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
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
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
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
s (context change, not contents) in the nfs_do_filldir par
of the dir.c change to account for the dirent addition to apply to
2.6.11. I can update it if useful.
OG.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
fs/nfs/dir.c | 114 ++---
On Mon, Mar 21, 2005 at 12:46:58PM -0500, Trond Myklebust wrote:
> må den 21.03.2005 Klokka 17:21 (+0100) skreiv Olivier Galibert:
>
> > Patch is against a fedora core 3 2.6.10, it requires minor
> > modifications (context change, not contents) in the nfs_do_filldir par
> >
On Mon, Mar 21, 2005 at 07:22:16PM -0500, Trond Myklebust wrote:
> This sort of thing worries me: I think we can do better by hooking
> lseek() on directories. I'll see what I can do.
And the patch is buggy somehow, sometimes loses entries. Keep it on
hold whie I trace the probm and fix it please
On Tue, Mar 22, 2005 at 05:00:07PM +0100, Olivier Galibert wrote:
> On Mon, Mar 21, 2005 at 07:22:16PM -0500, Trond Myklebust wrote:
> > This sort of thing worries me: I think we can do better by hooking
> > lseek() on directories. I'll see what I can do.
>
> And
I'm starting to install some fedora core 3 systems in an environment
where 64bits SGIs are still serving the home directories. They have
the bug/feature that required the 2.4 patch to hack the 64bits
cookies[1]. The 2.6 kernel I just found still can't compensate by
itself for the issue.
Is there
intains the mount/nfs options man
page?
It may fuzz a little, fc3 has a minor patch in another part of dir.c.
OG.
Signed-off-by: Olivier Galibert <[EMAIL PROTECTED]>
fs/nfs/dir.c | 53 +-
fs/nfs/inode.c|1
includ
On Thu, Feb 10, 2005 at 10:20:44AM -0500, Trond Myklebust wrote:
> A permanent fix probably ought to involve removing our current
> dependency on using the server-generated readdir cookies as
> telldir/seekdir offsets.
Remplacing it by? As in, I'm ready to do and test the code if I have
a decent
On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> - autoload programs for usb, scsi, and pci modules. These
> programs determine what module needs to be loaded when the
> kernel emits a hotplug event for these types of devices. This
> works just like the exi
On Mon, Feb 14, 2005 at 04:03:43PM -0800, Larry McVoy wrote:
> And how does the CVS gateway not provide this today?
The CVS gateway does not reach the rest of bkbits.net. For instance
the ipw2200 tree since they miss some of the files in their tarball
distribution.
> And long ago I offered what
On Tue, Feb 15, 2005 at 12:29:06PM -0500, Trond Myklebust wrote:
> lau den 22.01.2005 Klokka 21:34 (+0100) skreiv Andreas Gruenbacher:
> > Solaris nfsacl workaround
>
> NACK. No hacks.
That's the second time I see you refusing an interoperability patch
without bothering to say what would be accep
On Tue, Feb 15, 2005 at 05:43:24PM -0500, Trond Myklebust wrote:
> ty den 15.02.2005 Klokka 21:35 (+0100) skreiv Olivier Galibert:
> > That's the second time I see you refusing an interoperability patch
> > without bothering to say what would be acceptable. Do we need a fo
On Tue, Feb 15, 2005 at 06:37:19PM -0500, Trond Myklebust wrote:
> on den 16.02.2005 Klokka 00:02 (+0100) skreiv Olivier Galibert:
>
> > Resolving the problem and/or cleaning the code, no. Telling what kind
> > of patch would be acceptable is your responsability, yes.
>
&
On Wed, Feb 16, 2005 at 06:45:27PM +0900, Clemens Schwaighofer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/15/2005 09:19 PM, kernel wrote:
>
> > Just catching up on this thread. I guess I'm ultimately surprised that
> > the developers here don't create a system *they* like
On Wed, Jan 26, 2005 at 11:38:15AM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Rik van Riel wrote:
>
> >With some programs the 2.6 kernel can end up allocating memory
> >at address zero, for a non-MAP_FIXED mmap call! This causes
> >problems with some programs and is generally rude to do. This
On Wed, Jan 26, 2005 at 01:20:53PM -0500, linux-os wrote:
> On Wed, 26 Jan 2005, Olivier Galibert wrote:
> >Given that the man page itself says that unless you're using MAP_FIXED
> >start is only a hint and you should use 0 if you don't care things can
> >get real
On Wed, Feb 02, 2005 at 10:18:27PM +1000, [EMAIL PROTECTED] wrote:
> your concerns would be valid if this was impossible to achieve by an
> exploit, sadly, you'd be wrong too, it's possible to force an exploited
> application to call something like dl_make_stack_executable() and then
> execute the
On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote:
> When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed.
> This seems to cause VFS to panic via reiserfs.
>
> Anyone else notice this?
I don't, and I boot on reiserfs.
OG.
-
To unsubscribe from this list: send the
What is the Right Way[tm] as of 2.4.6 to allocate 16Mb as 4K pages and
get the pci bus address for each page? Bonus points is they're
virtually contiguous, but that's not necessary. IIRC, the old
vmalloc-then-walk-the-pagetables trick is considered out-of-bounds
nowadays.
OG.
-
To unsubscrib
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> In other words, if you know the push sequence of your C compiler's
> function calls, you don't need asm("");.
You are very much forgetting _inline_ asm. And if you think that's
unimportant for performance, well, as Al would say, go
A typo prevents the tigon 1 firmware to be included when tigon 1
support is active. Null pointer dereference in
ace_load_firmware->ace_copy as a result.
Patch trivial and even tested (aka, the module loads without oopsing
with a tigon 1 inside).
OG.
--- linux/drivers/net/acenic_firmware.h Tu
On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote:
> You are proposing an interface that will handle easy cases but blow
> up in the user's face in any hard one. That's poor design, frustrating
> the user exactly when he/she most needs help.
Yeah, but what is the current method, vi
On Thu, May 10, 2001 at 08:59:24PM +0200, Jes Sorensen wrote:
> Thanks, I'll put that in the next driver release as well.
Good. The only bad thing is that even with this fix, the card doesn't
work (recieves, but never transmits). I'll have to look into it
later, when I find time.
OG.
-
To u
On Tue, Mar 29, 2005 at 11:00:30AM -0800, David Schwartz wrote:
> Since the GPL permits their removal, removing them cannot be
> circumventing
> the GPL. Since the GPL is the only license and the license permits you to
> remove them, they cannot be a license enforcement mechanism. How can yo
On Tue, Mar 29, 2005 at 12:31:42PM -0400, Horst von Brand wrote:
> Sorry, but an /interfase/ is there to do exactly that. It can be placed
> under copyright protection as code, but /using/ it just can't be considered
> a derived work. It makes no sense that if I get a description (docu,
> example c
On Wed, Mar 30, 2005 at 10:29:43AM -0800, Shankar Unni wrote:
> Jean Delvare wrote:
>
> >v = p->field;
> >if (!p) return;
> >
> >can be seen as equivalent to
> >
> >if (!p) return;
> >v = p->field;
>
> Heck, no.
>
> You're missing the side-effect of a null pointer dereference cra
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 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 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
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
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
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 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 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 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 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 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 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
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
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 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 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 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 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 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: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 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 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 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 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
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
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
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 ++
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
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
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
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
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 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
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
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 ++
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
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
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
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(
1 - 100 of 147 matches
Mail list logo
