Does anyone know if the kernel has any issues running on a platform that
provides SMBIOS v2.5?
Thanks,
Dan Yeisley
-
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.
Sorry, I did not make myself clear.
Linus Torvalds wrote:
On Fri, 25 May 2007, Chris Newport wrote:
Maybe we should take a hint from Solaris.
No. Solaris is shit. They make their decisions based on "we control the
hardware" kind of setup.
Not really a Solaris feature. This is a
On Fri, May 25, 2007 at 09:49:38AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 25 May 2007, Ingo Molnar wrote:
> >
> > ok - then please merge that single hunk into the paravirtops patch - and
> > leave the other 6 hunks in this patch.
>
> Note: I'm actually much more interested in applying the
Casey Schaufler <[EMAIL PROTECTED]> writes:
> --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
>> Casey Schaufler <[EMAIL PROTECTED]> writes:
>>
>> > On Fedora zcat, gzip and gunzip are all links to the same file.
>> > I can imagine (although it is a bit of a stretch) allowing a set
>> > of u
Jeremy Maitin-Shepard <[EMAIL PROTECTED]> writes:
> [snip]
> Well, my point was exactly that App Armor doesn't (as far as I know) do
> anything to enforce the argv[0] convention, nor would it in general
> prevent a confined program from making a symlink or hard link. Even
> disregarding that, it
On Fri, 2007-05-25 at 10:41 +0200, Ingo Molnar wrote:
> * William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> > > yes, that's what i meant under 'slightly async'. Some AMD CPUs are
> > > like that too and sched_clock() now handles that fine. So we should
> > > try my patch.
> >
> > Sorry, then. I
Hi Linus,
These are all some pretty straightforward patches for 2.6.22-rc3.
--Mark
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus
to receive the following updates:
fs/ocfs2/aops.c | 11 ++-
fs
On Fri, 2007-05-25 at 11:16 -0700, Dave Hansen wrote:
> On Fri, 2007-05-25 at 10:41 +0200, Ingo Molnar wrote:
> > * William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> > > > yes, that's what i meant under 'slightly async'. Some AMD CPUs are
> > > > like that too and sched_clock() now handles that f
> If the functionality is completely busted in -stable,
It's not; e.g. it works great on my P4 testbox with 2.6.21
> adding a patch that's
> isolated to that component can't really make things much worse.
> All we've done here is move the breakage.
I don't think stable is the right place for d
On 5/25/07, Daniel Newby <[EMAIL PROTECTED]> wrote:
On 5/24/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
> So far the only example anyone has provided outside of periodic timers or
> hardware reset has been dumping the stack when something gets stuck.
> Softlockup does this already today, using a ti
On Fri, 25 May 2007 20:02:58 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > If the functionality is completely busted in -stable,
>
> It's not; e.g. it works great on my P4 testbox with 2.6.21
>
> > adding a patch that's
> > isolated to that component can't really make things much worse.
>
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.51:
On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote:
> As to the performance - I can see absolutely no reason why the minimal
> version shouldn't perform the same (or better). The kernel codes memset and
> memcpy routines have been heavily tested *and* optimized over the years and
> moving from m
Am Freitag, 25. Mai 2007 18:56 schrieben Sie:
> On Fri, 25 May 2007 16:52:19 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote:
> > I bet your bug is _not_ caused by ssb, but by some other breakage
> > in another subsystem. Maybe ACPI or APIC is broken? Try to boot
> > the machine without ACPI and/or
From: Randy Dunlap <[EMAIL PROTECTED]>
This config symbol name is confusing and unneeded/unwanted, so just
change it to MISC_DEVICES.
*
* Misc devices
*
Misc devices (MISC_STRANGE_DEV) [Y/n] (NEW)
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/misc/Kconfig |6 +++---
1 file cha
> I just tried this on an Altix from the test lab, and ia32 bash just
> started.
I don't have any native x86 binaries on my Madison-based testbox, so my
test case was to compile a simple program that counted total length of
argument strings on an x86 box, and copy it to my ia64 box. So that I
wou
Robert P. J. Day wrote:
> Convert old/obsolete NORET_TYPE and ATTRIB_NORET macros to use the
> newer standard of "__noreturn" as defined in compiler-gcc.h.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> 1) in a function declaration, the "__noreturn" will go at the end of
> the declarat
(sorry my English)
I'm helping Márton Németh in a experimental mail led driver
leds-clevo-mail.c for clevo laptops and I have problems with this
driver:
this files
/sys/class/trigger, /sys/class//dalay_on and
/sys/class//delay_off are created as 644 permissions. Also
ROOT controls the led. I
Am Freitag, 25. Mai 2007 19:28 schrieben Sie:
> On Fri, 25 May 2007 18:01:34 +0200 Takashi Iwai <[EMAIL PROTECTED]> wrote:
> > At Thu, 24 May 2007 13:09:21 -0700,
> >
> > Andrew Morton wrote:
> > > On Thu, 24 May 2007 22:00:52 +0200
> > >
> > > "Uwe Bugla" <[EMAIL PROTECTED]> wrote:
> > > > Hi ever
Convert old/obsolete NORET_TYPE and ATTRIB_NORET macros to use the
newer standard of "__noreturn" as defined in compiler-gcc.h.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
since there were a number of these old macros under the MIPS
directory alone, i thought it would be useful to
This patch updates the Intel ICH9M LPC Controller DID's, due to a
specification change.
Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
--- linux-2.6.22-rc2/include/linux/pci_ids.h.orig 2007-05-25
11:42:11.0 -0700
+++ linux-2.6.22-rc2/include/linux/pci_ids.h2007-05-25 11:43:2
--- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> ...
> Well, my point was exactly that App Armor doesn't (as far as I know) do
> anything to enforce the argv[0] convention,
Sounds like an opportunity for improvement then.
> nor would it in general
> prevent a confined program from making
On Fri, 25 May 2007, H. Peter Anvin wrote:
> Robert P. J. Day wrote:
> > Convert old/obsolete NORET_TYPE and ATTRIB_NORET macros to use the
> > newer standard of "__noreturn" as defined in compiler-gcc.h.
> >
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> > 1) in a function declaratio
On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
>
> Perhaps someone reading this could try to reproduce that problem on his
> machine.
> Now who of the readers owes a Broadcom 4401 NIC and can please try to
> test kernel 2.6.22-rc2-mm1?
>
> Those NICs have been used very very often as onboa
Hi Robert,
On 5/25/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
On Fri, 25 May 2007, Satyam Sharma wrote:
...
> 1. If this is a function _declaration_ (i.e. a prototype in some
> header or some .c file), then remove the NORET_TYPE macro. Also,
> if an ATTRIB_NORET or NORET_AND already exists
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Ingo: to make things easier, the _best_ split-up would be not "this is
> the historical series of patches leading up to CFS v15" or something
> like that, but it would be nice to get that final CFS version as a
> series of patches that do some spec
Considering that Andi has a similar patch, I'm going to assume there
is already justification for this..
What it ends up doing is allows the TSC to be used in cases which
we didn't use it before, and hope it's still mostly accurate.
For instance, when the frequency changes due to cpufreq we updat
Just passing a string to mark_tsc_unstable() doesn't allow real code to change
based on the reason for the instablility. I changed mark_tsc_unstable()
to accept a string and a flag which denotes a general reason why the tsc
is unstable, and can be evaluated in code.
Signed-Off-By: Daniel Walker <[
Hi Daniel,
On 5/26/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote:
> As to the performance - I can see absolutely no reason why the minimal
> version shouldn't perform the same (or better). The kernel codes memset and
> memcpy routines have b
On Fri, 25 May 2007, Arnd Bergmann wrote:
> On Friday 25 May 2007, [EMAIL PROTECTED] wrote:
> > Add a CD/DVD/BD Storage Driver for the PS3:
> > - Implemented as a SCSI device driver
>
> I assume you tried implementing it as a block device driver,
> like you PS3 disk driver does, and failed for s
Robert P. J. Day wrote:
>
>
> f() __attribute__((noreturn)) ;
>
> you get:
>
> warning: data definition has no type or storage class
>
> but gcc doesn't complain if you declare it thusly:
>
> __attribute__((noreturn)) f() ;
>
> that strikes me as a flaw in gcc, no?
>
Doesn't matter.
On Fri, 25 May 2007, Arnd Bergmann wrote:
> On Friday 25 May 2007, [EMAIL PROTECTED] wrote:
> > +static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
> > + struct request *req, int gather)
> > +{
> > + unsigned int sectors = 0, offset = 0;
> > + struct
On Sat, 26 May 2007, Satyam Sharma wrote:
> Hi Robert,
>
> On 5/25/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > On Fri, 25 May 2007, Satyam Sharma wrote:
> > ...
> > > 1. If this is a function _declaration_ (i.e. a prototype in some
> > > header or some .c file), then remove the NORET_TYPE
On Fri, 25 May 2007, Olaf Hering wrote:
> On Fri, May 25, [EMAIL PROTECTED] wrote:
> > Add a Disk Storage Driver for the PS3:
>
> There is no device symlink in /sys/block/ps3da/
Interesting... Do you know how to create it?
Gr{oetje,eeting}s,
Geert
Stefan Richter wrote:
> Auke Kok wrote:
>> +Don't put spaces before tabs or mix them.
>
> Make it "Don't put spaces before tabs."
>
> We do mix them if we combine tabs for indentation with spaces for alignment.
It would probably be good to add a pointer to the cleanfile/cleanpatch
scripts here,
Better DPLL use and calibration
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc2-mm1/drivers/ata/pata_hpt37x.c
linux-2.6.22-rc2-mm1/drivers/ata/pata_hpt37x.c
--- linux.vanilla-2.6.22-rc2-mm1/drivers/ata/pata_hp
If you are using a SiS controller and the BIOS didn't set it up then the
FIFO may be left active when we try and set up the CD. Not convinced this
matters but I'd prefer to be safe
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.va
Am Freitag, 25. Mai 2007 20:48 schrieben Sie:
> On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
> > Perhaps someone reading this could try to reproduce that problem on his
> > machine.
> > Now who of the readers owes a Broadcom 4401 NIC and can please try to
> > test kernel 2.6.22-rc2-mm1?
> >
Ben Collins wrote:
> On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote:
>> Ben Collins <[EMAIL PROTECTED]> writes:
>>
>> Why?
>
> Because there's no other way to make the kernel totally quiet. We've
> been patching this out so that the boot sequence has that "clean look".
>
> Other than that,
On Fri, 25 May 2007, Ingo Molnar wrote:
>
> sure enough, i'll work something sane out - i already have it partly
> split up. It will probably be something along the lines of: 'remove
> stuff that we can remove and still have functional scheduling' followed
> by an 'add minimal CFS patch' and
On Fri, 25 May 2007, Arnd Bergmann wrote:
> On Friday 25 May 2007, [EMAIL PROTECTED] wrote:
> > +static u64 ps3stor_wait_for_completion(u64 devid, u64 tag,
> > + unsigned int timeout)
> > +{
> > + unsigned int retries = 0;
> > + u64 res = -1, status;
> > +
> > +
On Fri, May 25, 2007 at 11:24:46AM -0500, Scott Preece wrote:
> However, it might be phrased more diplomatically in this context, like
> "because you are sacrificing time that could be spent adding features,
> to fix somebody else's mistakes".
Not all Bugs are mistakes of the coder. I still think
On Friday 25 May 2007 19:43, Casey Schaufler wrote:
> [...] but the AppArmor code could certainly check for that in exec by
> enforcing the argv[0] convention. It would be perfectly reasonable for a
> system that is so dependent on pathnames to require that.
Hmm ... that's a strange idea. AppArmor
> Hmm...
> I find in section 6.1:
> > In addition to PCI INTx compatible interrupt emulation, PCI Express
> > requires support of MSI or MSI-X or both.
> Which suggests that INTx support is required.
Unfortunately, this can be equally well read to suggest that MSI/MSI-X is
not required, but tha
Got this BUG_ON twice in a row, just found it by scrolling thru my
dmesg.
BUG: at fs/inotify.c:172 set_dentry_child_flags()
[] set_dentry_child_flags+0x10c/0x1a0
[] remove_watch_no_event+0x53/0x60
[] inotify_destroy+0x50/0xb0
[] inotify_release+0x14/0x60
[] __fput+0x93/0x190
[] filp_close+0x47/0x8
Can someone tell Adrian that he's bouncing with 500 level errors, like
the one attached below, again?
Could you also tell him to start using a different email account for
his vger.kernel.org subscriptions as this is starting to get
rediculious.
I think I've been beyond reasonable trying to help
Hello,
Grepping through the sources I found 500+ occurrences of double
exclamation marks before identifier names (such as !!x -- I took care
to ignore occurrences of !! inside comment blocks, because there
are plenty of that sort too).
!! are to be found even in the definitions of common macros
--- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Friday 25 May 2007 19:43, Casey Schaufler wrote:
> > [...] but the AppArmor code could certainly check for that in exec by
> > enforcing the argv[0] convention. It would be perfectly reasonable for a
> > system that is so dependent on pathna
On May 24, 2007, at 10:51 PM, Andi Kleen wrote:
Do we have a feel for how much performace we're losing on those
systems which _could_ do MSI, but which will end up defaulting
to not using it?
At least on 10GB ethernet it is a significant difference; you usually
cannot go anywhere near line spe
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote:
> Are all these occurrences merely the debris of
> s/something/!notsomething/g kind of patches or is there some
> dark, unknown C / gcc wizardry I have absolutely no clue of?
Try building and running this:
#include
int main()
{
H. Peter Anvin wrote:
Stefan Richter wrote:
Auke Kok wrote:
+Don't put spaces before tabs or mix them.
Make it "Don't put spaces before tabs."
We do mix them if we combine tabs for indentation with spaces for alignment.
It would probably be good to add a pointer to the cleanfile/cleanpatch
On 5/26/07, Russell King <[EMAIL PROTECTED]> wrote:
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote:
> Are all these occurrences merely the debris of
> s/something/!notsomething/g kind of patches or is there some
> dark, unknown C / gcc wizardry I have absolutely no clue of?
Try bu
On Fri, May 25, 2007 at 09:17:35AM -0600, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > Originally I would have thought this would be a good idea, but now that
> > Vista is out, which supports MSI, I don't think we are going to need
> > this in the future. All new chipsets
From: Chris Newport <[EMAIL PROTECTED]>
Date: Fri, 25 May 2007 19:03:51 +0100
> Not really a Solaris feature. This is a feature of the Openboot PROM
> which is also used by several other vendors.
> The Openboot PROM knows how to write to disk. The same should
> apply on Apple hardware and others
On 2007.05.26 01:53:59 +0530, Satyam Sharma wrote:
> Hello,
>
> Grepping through the sources I found 500+ occurrences of double
> exclamation marks before identifier names (such as !!x -- I took care
> to ignore occurrences of !! inside comment blocks, because there
> are plenty of that sort too).
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote:
> Hello,
>
> Grepping through the sources I found 500+ occurrences of double
> exclamation marks before identifier names (such as !!x -- I took care
> to ignore occurrences of !! inside comment blocks, because there
> are plenty of tha
On Friday 25 May 2007, Geert Uytterhoeven wrote:
>
> > I don't really understand what the kthread is needed for. You probably
> > thought about multiple options and ended up with this, but having
> > a comment in front of it might be helpful.
>
> I used a kthread because the request function of a
On Fri, May 25, Geert Uytterhoeven wrote:
> On Fri, 25 May 2007, Olaf Hering wrote:
> > On Fri, May 25, [EMAIL PROTECTED] wrote:
> > > Add a Disk Storage Driver for the PS3:
> >
> > There is no device symlink in /sys/block/ps3da/
>
> Interesting... Do you know how to create it?
No, that was not
Matheus Izvekov wrote:
Got this BUG_ON twice in a row, just found it by scrolling thru my
dmesg.
BUG: at fs/inotify.c:172 set_dentry_child_flags()
http://bugzilla.kernel.org/show_bug.cgi?id=7785
If you can reproduce it, looks like some help diagnosing it would be useful.
Daniel
-
To unsubsc
On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote:
On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote:
> Hello,
>
> Grepping through the sources I found 500+ occurrences of double
> exclamation marks before identifier names (such as !!x -- I took care
> to ignore occurrences of !! inside c
On Fri, May 25, 2007 at 12:53:19PM -0500, Matt Mackall wrote:
> On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote:
> > On 5/25/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > >On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote:
> > >> 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, th
On Fri, 25 May 2007 11:36:22 -0500
Matt Mackall <[EMAIL PROTECTED]> wrote:
> 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't
> matter. Bringing up the interface manually still works, so I suspect
> this is sysfs or HAL related again. Again, Debian unstable so
> userspace is qu
On 5/26/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote:
>
> That's a question for a quiz in introductory course on C:
Ugh ... ok, I've embarrassed myself publicly already, so I'll
also be brave enough to take a C quiz here :-)
Hmmm, and now I seem to
On Friday 25 May 2007, Geert Uytterhoeven wrote:
>
> > What is the problem? Is there infrastructure missing in the
> > CD-ROM layer?
>
> As the CD/DVD/BD part just accepts SCSI/ATAPI commands (except for plain
> read/write), I was suggested to keep it as a SCSI driver.
Ok, so I guess the tradeof
On Fri, May 25, 2007 at 12:32:10PM -0700, Daniel Walker wrote:
> Just passing a string to mark_tsc_unstable() doesn't allow real code to change
> based on the reason for the instablility. I changed mark_tsc_unstable()
> to accept a string and a flag which denotes a general reason why the tsc
> is u
Andrew Morton <[EMAIL PROTECTED]> wrote on 05/22/2007 05:23:05 PM:
> On Tue, 22 May 2007 03:25:48 -0400
> [EMAIL PROTECTED] (Joseph Fannin) wrote:
>
> > This comes a bit after IMA bails out successfully, if that's
relevant:
...
> >
> > [1.708761] ima (ima_init): No TPM chip found(rc = -
> > In addition to PCI INTx compatible interrupt emulation, PCI Express
> > requires support of MSI or MSI-X or both.
> Which suggests that INTx support is required.
>
> I do not find any wording that suggest the opposite.
> I do see it stated that it is intended to EOL support for INTx at
Hi Ingo et al.
It's been quite a while, since last time I've complained about the -rt
kernel patch series. This time I'm afraid I have a nasty specialty I've
been trying to figure out and isolate but to no definitive results.
Fact is, since 2.6.21-rt2 and still on latest -rt8, that I'm facing
tro
Greg KH <[EMAIL PROTECTED]> writes:
>> MSI appears to have enough problems that enabling it in a kernel
>> that is supposed to run lots of different hardware (like a distro
>> kernel) is a recipe for disaster.
>
> Oh, I agree it's a major pain in the ass at times...
>
> But I'm real hesitant to cha
On Fri, 25 May 2007, H. Peter Anvin wrote:
> Robert P. J. Day wrote:
> >
> >
> > f() __attribute__((noreturn)) ;
> >
> > you get:
> >
> > warning: data definition has no type or storage class
> >
> > but gcc doesn't complain if you declare it thusly:
> >
> > __attribute__((noreturn)) f() ;
>
From: "Satyam Sharma" <[EMAIL PROTECTED]>
Date: Sat, 26 May 2007 01:53:59 +0530
WHat is with multiple people asking about "!!" all of a
sudden today?
> Are all these occurrences merely the debris of
> s/something/!notsomething/g kind of patches or is there some
> dark, unknown C / gcc wizardry I
> I think for most of Intel I can reduce my test to:
> If (bus == 0 , device == 0, function == 0 && vendor == Intel &&
> has a pci express capability) {
> Enable msi on all busses().
> }
MSI was working on every Intel PCI-X chipset I ever saw too...
- R.
-
To unsubscribe from this
On Wed, 23 May 2007 00:42:33 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
>
Don't know if it's specific to this kernel, but as I have realized it now...
I booted with idle=poll to check some issues
On Fri, 25 May 2007, Arnd Bergmann wrote:
> On Friday 25 May 2007, Geert Uytterhoeven wrote:
> > > I don't really understand what the kthread is needed for. You probably
> > > thought about multiple options and ended up with this, but having
> > > a comment in front of it might be helpful.
> >
> >
Kok, Auke wrote:
>
> ahh yes, I'll incorporate that.
>
> BTW, would it be possible for cleanfile/cleanpatch to dump warnings to
> stderr for lines exceeding 80 characters? I think that would really be
> useful...
>
Should be trivial enough to do, although it probably should be an option.
Alan Cox wrote:
Better DPLL use and calibration
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
applied
-
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
Plea
On Sat, May 26, 2007 at 02:26:11AM +0530, Satyam Sharma wrote:
> also be brave enough to take a C quiz here :-)
>
> >what type should x have for !!x to be a valid expression?
>
> Any integer type (includes pointers)
Er, no... Pointers are not integer types *and* you can use ! on any
sca
At Fri, 25 May 2007 10:28:06 -0700,
Andrew Morton wrote:
>
> On Fri, 25 May 2007 18:01:34 +0200 Takashi Iwai <[EMAIL PROTECTED]> wrote:
>
> > At Thu, 24 May 2007 13:09:21 -0700,
> > Andrew Morton wrote:
> > >
> > > On Thu, 24 May 2007 22:00:52 +0200
> > > "Uwe Bugla" <[EMAIL PROTECTED]> wrote:
>
On Fri, 2007-05-25 at 23:05 +0200, Andi Kleen wrote:
> On Fri, May 25, 2007 at 12:32:10PM -0700, Daniel Walker wrote:
> > Just passing a string to mark_tsc_unstable() doesn't allow real code to
> > change
> > based on the reason for the instablility. I changed mark_tsc_unstable()
> > to accept a s
On Fri, May 25, 2007 at 10:32:13PM +0100, Al Viro wrote:
> On Sat, May 26, 2007 at 02:26:11AM +0530, Satyam Sharma wrote:
> > also be brave enough to take a C quiz here :-)
> >
> > >what type should x have for !!x to be a valid expression?
> >
> > Any integer type (includes pointers)
>
>
On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote:
On Sat, May 26, 2007 at 02:26:11AM +0530, Satyam Sharma wrote:
> also be brave enough to take a C quiz here :-)
>
> >what type should x have for !!x to be a valid expression?
>
> Any integer type (includes pointers)
Er, no... Pointers are n
On Thu, 2007-05-24 at 01:37 -0400, Dmitry Torokhov wrote:
> Hi Antonino,
>
> I am having the following issues on my Dell Inspiron 8100. They are not
> new but I just got around to report them.
>
> With CONFIG_FB_NVIDIA_I2C I get 1600x1200 resolution but pixels
> "swarming" and it is unuseable. Th
Robert P. J. Day wrote:
>> ... and declare functions as:
>>
>> __noreturn f();
>>
>> ... which is the syntactially sane way of doing it.
>
> that may be, but keep in mind that gcc allows attributes to *follow*
> the parameter list as well, and some people might prefer to do the
> following:
>
>
On Fri, May 25, 2007 at 03:40:18PM -0400, Robert P. J. Day wrote:
> On Sat, 26 May 2007, Satyam Sharma wrote:
>
> > Hi Robert,
> >
> > On 5/25/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > > On Fri, 25 May 2007, Satyam Sharma wrote:
> > > ...
> > > > 1. If this is a function _declaration_ (i
On Fri, May 25, 2007 at 03:06:22PM -0600, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> > It's a trade off, and I'd like to choose the one that over the long
> > term, causes the least ammount of work and maintaiblity. I think the
> > current blacklist meets that goal.
>
> A re
On Sun, May 20, 2007 at 01:04:19PM +0200, Elimar Riesebieter wrote:
> Hi,
>
> FYI, building 2.6.22-rc2 with
> gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
> on my powerbook (PPC) gives:
>
> ...
> arch/powerpc/kernel/pci_32.c: In function 'pcibios_assign_resources':
> arch/powerpc/kernel
Eric W. Biederman wrote:
> @@ -1677,43 +1650,16 @@ static int __devinit msi_ht_cap_enabled(struct
> pci_dev *dev)
> return 0;
> }
>
> -/* Check the hypertransport MSI mapping to know whether MSI is enabled or
> not */
> +/* Enable MSI on hypertransport chipsets supporting MSI */
> stati
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> Hello,
>
> with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> following BUG:
Thanks for letting me know.
Stuart, any help here?
thanks,
greg k-h
> [ 459.800033] BUG: scheduling while atomic: rmmod/0x00
On Fri, 25 May 2007 23:20:25 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> Is idle=poll a quick and dirty way to burn your box in flames ?
yep ;) It makes the CPU(s) busy-wait when they have nothing else to do.
It was originally added as a thing to maybe save a few cycles of latency
in res
On Fri, 25 May 2007 14:40:05 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> > Hello,
> >
> > with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> > following BUG:
>
> Thanks for letting me know.
>
> Stuart, any h
And a few trivial documentation patches.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-scsi.c |5 ++-
drivers/ata/pata_artop.c |2 +-
drivers/ata/pat
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get a few more 2.6.22-rc2 fixes:
Eli Cohe
Herbert Xu wrote:
On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote:
[E1000]: Call netif_poll_enable in e1000_open
Here is a better one.
[E1000]: Restore netif_poll_enable call but make sure IRQs are off
This restores the previously removed netif_poll_enable call in
e1000_open. It'
Hi Peter,
On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Robert P. J. Day wrote:
>> ... and declare functions as:
>>
>> __noreturn f();
>>
>> ... which is the syntactially sane way of doing it.
>
> that may be, but keep in mind that gcc allows attributes to *follow*
> the parameter list a
Satyam Sharma wrote:
>
> But __attribute__((noreturn)) is simply a _function attribute_. Of course,
> it is legal / valid only for functions with return-type void, so it does
> make
> sense to combine both void and __attribute__((noreturn)) in the same
> macro like you say. But that's not syntacti
On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>
> But __attribute__((noreturn)) is simply a _function attribute_. Of course,
> it is legal / valid only for functions with return-type void, so it does
> make
> sense to combine both void and __attribute__((noreturn)) in
On Fri, 2007-05-25 at 10:36 +0200, [EMAIL PROTECTED] wrote:
> -#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE)
> +#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE) || \
> +defined(CONFIG_PS3_FLASH_MODULE) ||
> defined(CONFIG_PS3_FLASH_MODULE)
As I said multiple times, imh
On Friday 25 May 2007, Geert Uytterhoeven wrote:
> On Fri, 25 May 2007, Arnd Bergmann wrote:
>
> > Ok, but why does it call wait_for_completion() then?
> > I thought you could end_that_request_* from the interrupt handler instead.
>
> Actually I tried that first, but I ran into other problems, lik
On Fri, 2007-05-25 at 13:24 +0200, Olaf Hering wrote:
> On Fri, May 25, [EMAIL PROTECTED] wrote:
>
> > +++ b/drivers/scsi/ps3rom.c
>
> > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
>
> linux/highmem.h is not included to get the kmap_* prototypes.
Beside, I don't see the poin
Andi Kleen wrote:
On Tuesday 01 May 2007 20:59:46 Chandramouli Narayanan wrote:
General note on EFI x86_64 support
--
More review. This code unfortunately has some problems.
First this seems to be quite different from what the 32bit EFI
support does (w
1 - 100 of 410 matches
Mail list logo
