> it's a compatibility hack only. Threaded handlers are a different type
> of flow, but often the fasteoi handler is not changed to the threaded
> handler so i changed it to be a threaded handler too.
>
> threaded handlers need a mask() + an ack(), because that's the correct
> model to map the
Would be nice if it used atl_ not at_ so its less likely to cause
namespace clashes.
You have various macros for swaps that are pretty ugly - we have
cpu_to and le/be_to_cpu functions for most swapping cases and these are
generally optimised assembler (eg bswap on x86)
AT_DESC_USED/UNUSED would b
Adrian Bunk wrote:
On Sun, Nov 19, 2006 at 04:12:31PM -0800, Randy Dunlap wrote:
make xconfig is segfaulting on me in 2.6.19-rc6 and later
when I do ^F (find/search).
Works fine in 2.6.19-rc5 and earlier.
The only message log I get is:
qconf[5839]: segfault at 0008 rip 0042
On Sun, 19 Nov 2006 15:55:03 -0500
Dave Jones <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 19, 2006 at 11:24:08AM -0800, David Rientjes wrote:
> > The cs5530A will be able to go into active idle (PWRSVE) so its PCI class
> > revision should be accurately stored.
>
> Already queued in cpufreq.git f
On Sun, Nov 19, 2006 at 04:12:31PM -0800, Randy Dunlap wrote:
> make xconfig is segfaulting on me in 2.6.19-rc6 and later
> when I do ^F (find/search).
> Works fine in 2.6.19-rc5 and earlier.
>
> The only message log I get is:
>
> qconf[5839]: segfault at 0008 rip 004289bc rsp
On 2006-11-19, David Woodhouse wrote:
[]
> I don't see either of those connection attempts in the logs for
> canuck.infradead.org. Canuck is on GMT-5, and I've looked in its logs
> for a few minutes around 08:27 and around 06:49. Nothing seems to match
> your sender address.
Yes. I've told about D
On Fri, Nov 17, 2006 at 05:19:30PM +0100, Rafael J. Wysocki wrote:
> On Friday, 17 November 2006 01:50, David Chinner wrote:
> > On Thu, Nov 16, 2006 at 09:12:49AM +0100, Rafael J. Wysocki wrote:
> > Hi,
> > >
> > > The following two patches introduce a mechanism that should allow us to
> > > avo
Hello Jiri,
Monday, November 20, 2006, 1:45:51 AM, you wrote:
> Paul Sokolovsky wrote:
>> But alas, the commit message is not as good as some others are, and
>> doesn't mention what should be used instead. So, if find_bus() is
>> "unused", what should be used instead?
> You should probably men
make xconfig is segfaulting on me in 2.6.19-rc6 and later
when I do ^F (find/search).
Works fine in 2.6.19-rc5 and earlier.
The only message log I get is:
qconf[5839]: segfault at 0008 rip 004289bc rsp
7fffa08ccf10 error 4
I don't see any changes in scripts/kconfig/* in
On Mon, Nov 20, 2006 at 12:45:51AM +0100, Jiri Slaby wrote:
> Paul Sokolovsky wrote:
> > But alas, the commit message is not as good as some others are, and
> > doesn't mention what should be used instead. So, if find_bus() is
> > "unused", what should be used instead?
>
> You should probably me
Evgeniy Polyakov wrote:
Possible solution:
a) it would be possible to have a "used" flag in each ring buffer entry.
That's too expensive, I guess.
b) kevent_wait needs another parameter which specifies the which is the
last (i.e., least recently added) entry in the ring buffer.
Everyth
On Sunday 19 November 2006 21:30, Jay Cliburn wrote:
> This patch contains the main C file for the Attansic L1 gigabit ethernet
> adapter driver.
Just a few style comments:
> + /* PCI config space info */
> + hw->vendor_id = pdev->vendor;
> + hw->device_id = pdev->device;
> + hw->
On Thu, 16 Nov 2006 23:12:09 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> The RTC framework has an irq_set_freq() method that should be used to
> manage the periodic IRQ frequency, but the current ioctl logic doesn't
> know how to do that. This patch teaches it how.
>
> This means that driv
On Thu, 16 Nov 2006 23:09:31 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> This updates the RTC documentation to summarize the two APIs now available:
> the old PC/AT one, and the new RTC class drivers. It also updates the
> included "rtctest.c" file to better meet Linux style guidelines, and
On Sat, 2006-11-18 at 13:06 -0600, Larry Finger wrote:
> Chris Wright wrote:
> > -stable review patch. If anyone has any objections, please let us know.
> > --
> >
> > From: Michael Buesch <[EMAIL PROTECTED]>
> >
> > Drain the Microcode TX-status-FIFO before we enable IRQs.
> > T
On Thu, 16 Nov 2006 23:27:37 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> I got a lockdep warning when running "rtctest" so I though it'd be good
> to see what was up.
>
> - The warning was for rtc->irq_task_lock, gotten from rtc_update_irq()
>by irq handlerss ... but in a handful of ot
Paul Sokolovsky wrote:
> But alas, the commit message is not as good as some others are, and
> doesn't mention what should be used instead. So, if find_bus() is
> "unused", what should be used instead?
You should probably mention what for?
regards,
--
http://www.fi.muni.cz/~xslaby/
On some of our systems (Linux 2.6, 4-way SMP), we have found a race where
occasionally recv() can detect a shutdown before the last bytes written to
the socket, and will exhibit the odd behavior where recv() will return 0
to indicate a shutdown socket, and a subsequent call will return the last
bi
On Sun, 19 Nov 2006 14:29:15 -0600 Jay Cliburn wrote:
> From: Jay Cliburn <[EMAIL PROTECTED]>
>
> This patch contains the build files for the Attansic L1 gigabit ethernet
> adapter driver.
>
> Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
> ---
>
> Kconfig | 12
> Makefil
On Sun, 19 Nov 2006, Rafael J. Wysocki wrote:
> > concept works anywhere that has a CMOS chip, so if somebody were to spend
> > a few minutes testing it on x86-64 and others, it would work elsewhere
> > too..
>
> I can do that if someone gives me the code.
Well, I actually _think_ it works al
On Sun, 2006-11-19 at 19:55 +0100, Rafael J. Wysocki wrote:
> On Sunday, 19 November 2006 19:21, Linus Torvalds wrote:
> >
> > On Sun, 19 Nov 2006, Rafael J. Wysocki wrote:
> > >
> > > In fact that's up to 30 seconds on a modern box, usually less than that.
> >
> > Right. If the machine boots qui
Hello linux-kernel,
We here at Handhelds.org upgrading our drivers to 2.6.18 and I just
caught a case of find_bus() being undefined during link. Quickly
traced this to
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e4ef085ea4b00cfc34e854edf448c729de8a0a5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
> On Sun, Nov 19, 2006 at 11:04:33AM -0800, Randy Dunlap wrote:
>> Andi Kleen wrote:
> I would copy a relatively simple C implementation, like
> arch/h8300/lib/checksum.c
As long as the h8300 version has the same output as
On 11/19, Paul E. McKenney wrote:
>
> On Mon, Nov 20, 2006 at 12:17:31AM +0300, Oleg Nesterov wrote:
> >
> > It will wait for xxx_read_unlock() on reader's side. And for this reason
> > this idx in fact is not exactly wrong :)
>
> I am not seeing this.
>
> Let's assume sp->completed starts out z
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Thu, 16 Nov 2006 10:30:41 + (UTC)
> Oleg Verych <[EMAIL PROTECTED]> wrote:
>
>> [ Adding e-mail of Andrew Morton, he may have clue about who to ping ;]
>> [ MAINTAINERS.smbfs seems to be emply ]
>
> smbfs is unmaint
On Mon, Nov 20, 2006 at 12:50:53AM +0300, Oleg Nesterov wrote:
> On 11/19, Paul E. McKenney wrote:
> >
> > On Sun, Nov 19, 2006 at 11:55:16PM +0300, Oleg Nesterov wrote:
> > > So synchronize_xxx() should do
> > >
> > > smp_mb();
> > > idx = sp->completed++ & 0x1;
> > >
> > > for (;;) { ... }
Linus Torvalds <[EMAIL PROTECTED]> writes:
> I never use SOFTWARE_SUSPEND, and I think the whole concept is totally
> broken.
>
> Sane people use suspend-to-ram, and that's when you need the suspend and
> resume debugging.
>
> Software-suspend is silly. I want my machine back in three seconds,
Alan Stern wrote:
> On Sun, 19 Nov 2006, Stefan Richter wrote:
>> @@ -1873,8 +1873,19 @@ static void nodemgr_remove_host(struct h
...
>> if (hi) {
>> +/* up(&host->device.sem); --- apparently not required */
>> +if (host->device.parent)
>> +up(
On Mon, Nov 20, 2006 at 12:17:31AM +0300, Oleg Nesterov wrote:
> On 11/19, Alan Stern wrote:
> > On Sun, 19 Nov 2006, Oleg Nesterov wrote:
> >
> > > > What happens if synchronize_xxx manages to execute inbetween
> > > > xxx_read_lock's
> > > >
> > > > idx = sp->completed & 0x1;
> >
>+char at_driver_name[] = "atl1";
>+static const char at_driver_string[] = "Attansic(R) L1 Ethernet Network
>Driver";
>+const char at_driver_version[] = DRV_VERSION;
>+static const char at_copyright[] =
>+"Copyright(c) 2005-2006 Attansic Corporation.";
>+
>+extern s32 at_read_mac_addr(struct
On 11/19, Paul E. McKenney wrote:
>
> On Sun, Nov 19, 2006 at 11:55:16PM +0300, Oleg Nesterov wrote:
> > So synchronize_xxx() should do
> >
> > smp_mb();
> > idx = sp->completed++ & 0x1;
> >
> > for (;;) { ... }
> >
> > > You see, there's no way around using synchronize_sc
On Sat, Nov 18, 2006 at 04:00:35PM -0500, Alan Stern wrote:
> On Sat, 18 Nov 2006, Paul E. McKenney wrote:
>
> > > > @@ -94,7 +112,8 @@ void cleanup_srcu_struct(struct srcu_str
> > > > WARN_ON(sum); /* Leakage unless caller handles error. */
> > > > if (sum != 0)
> > > >
On Nov 19 2006 14:30, Jay Cliburn wrote:
>+
>+#define LBYTESWAP( a ) ( ( ( (a) & 0x00ff00ff ) << 8 ) | ( ( (a) &
>0xff00ff00 ) >> 8 ) )
>+#define LONGSWAP( a ) ( ( LBYTESWAP( a ) << 16 ) | ( LBYTESWAP( a )
>>> 16 ) )
>+#define SHORTSWAP( a ) ( ( (a) << 8 ) | ( (a) >> 8 ) )
Hi Linus.
On Sun, 2006-11-19 at 09:33 -0800, Linus Torvalds wrote:
>
> On Sun, 19 Nov 2006, Chuck Ebbert wrote:
> >
> > When doing 'make oldconfig' we should ask about suspend/resume
> > debug features when SOFTWARE_SUSPEND is not enabled.
>
> That's wrong.
>
> I never use SOFTWARE_SUSPEND, and
On Sunday, 19 November 2006 20:54, Linus Torvalds wrote:
>
> On Sun, 19 Nov 2006, Rafael J. Wysocki wrote:
> >
> > > because people point to the suspend-to-disk instead.
> >
> > Who they?
>
> Like you _just_ did.
No, I didn't. It was referred to in the message that started this thread.
I don
On Sat, Nov 18, 2006 at 10:34:26PM +0300, Oleg Nesterov wrote:
> On 11/18, Paul E. McKenney wrote:
> >
> > On Sat, Nov 18, 2006 at 11:15:27AM -0500, Alan Stern wrote:
> > > > + smp_processor_id())->c[idx]++;
> > > > + smp_mb();
> > > > + preempt
On Sun, 2006-11-19 at 12:49 +0100, Pavel Machek wrote:
> +int set_mixer_volume(int mixer_vol)
> {
> - int retVal;
> + /* FIXME: Alsa has mixer_vol in 0-100 range, while SX1 needs
> 0-9 range */
Untrue. ALSA uses whatever range you define in the info callback for
the mixer element. I
On Sat, Nov 18, 2006 at 10:02:17PM +0300, Oleg Nesterov wrote:
> On 11/17, Paul E. McKenney wrote:
> >
> > int srcu_read_lock(struct srcu_struct *sp)
> > {
> > int idx;
> > + struct srcu_struct_array *sap;
> >
> > preempt_disable();
> > idx = sp->completed & 0x1;
> > - barrier();
On Sun, Nov 19, 2006 at 11:55:16PM +0300, Oleg Nesterov wrote:
> On 11/19, Alan Stern wrote:
> >
> > On Sun, 19 Nov 2006, Oleg Nesterov wrote:
> >
> > > int xxx_read_lock(struct xxx_struct *sp)
> > > {
> > > int idx;
> > >
> > > idx = sp->completed & 0x1;
> > > ato
Hi!
> > Needs space between if and (, but lets use if (is_user_space() !=
> > freeze_user_space) trick here, too.
>
> OK
>
> New version of the patch follows.
>
> ---
> Move the loop from freeze_processes() to a separate function and call it
> independently for user space processes and kernel t
On 11/19, Alan Stern wrote:
> On Sun, 19 Nov 2006, Oleg Nesterov wrote:
>
> > > What happens if synchronize_xxx manages to execute inbetween
> > > xxx_read_lock's
> > >
> > > idx = sp->completed & 0x1;
> > > atomic_inc(sp->ctr + idx);
> > >
> > > statements?
> >
> > Oops. I
Hi!
> Ah, good idea. In fact I prefer if (is_user_space(p) == !thaw_user_space),
> because it will work even if thaw_user_space is different to 1 and 0.
>
> Revised patch follows.
>
> ---
> Move the loop from thaw_processes() to a separate function and call it
> independently for kernel threads
* Karsten Wiese <[EMAIL PROTECTED]> wrote:
> Call Trace:
> [] do_page_fault+0x2b9/0x552
> [] work_resched+0x6/0x20
> The [] work_resched+0x6/0x20 corresponds to
> mov$0xf000,%ebp
> 0x01c1 :call 0x1c2
> 0x01c6 :mov$0xf000,%ebp
no, it's the call's r
On Sat, Nov 18, 2006 at 09:46:24PM +0300, Oleg Nesterov wrote:
> On 11/17, Paul E. McKenney wrote:
> >
> > Oleg, any thoughts about Jens's optimization? He would code something
> > like:
> >
> > if (srcu_readers_active(&my_srcu))
> > synchronize_srcu();
> > else
> >
On Sun, 19 Nov 2006, Oleg Nesterov wrote:
> > What happens if synchronize_xxx manages to execute inbetween
> > xxx_read_lock's
> >
> > idx = sp->completed & 0x1;
> > atomic_inc(sp->ctr + idx);
> >
> > statements?
>
> Oops. I forgot about explicit mb() before sp->complet
> I'm not sure it's feasible. The idea behind level/edge flows is to
> eliminate the interrupt priority I think. That's why they EOI ASAP (with the
> level handler masking IRQ before that) -- this way the other interrupts may
> come thru.
Well, the idea behind the level/edge flow is not ex
Andrew Morton wrote:
> On Sun, 19 Nov 2006 18:13:45 +0100
> Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Looks very much like eth1394's sysfs interface is getting
>> in the way. And since it is entirely handled by the ieee1394 core, it
>> means ieee1394 needs the class_dev to dev treatment. I think
On Sun, 19 Nov 2006 20:57:11 + Al Viro wrote:
> On Sun, Nov 19, 2006 at 11:04:33AM -0800, Randy Dunlap wrote:
> > Andi Kleen wrote:
> > >>>I would copy a relatively simple C implementation, like
> > >>>arch/h8300/lib/checksum.c
> > >>As long as the h8300 version has the same output as the x86
On Sun, Nov 19, 2006 at 11:04:33AM -0800, Randy Dunlap wrote:
> Andi Kleen wrote:
> >>>I would copy a relatively simple C implementation, like
> >>>arch/h8300/lib/checksum.c
> >>As long as the h8300 version has the same output as the x86 version.
> >
> >The trouble is that the different architectu
Am Sonntag, 19. November 2006 14:43 schrieb Ingo Molnar:
>
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> > work_resched:
> > DISABLE_INTERRUPTS
> > call __schedule
> > # make sure we don't miss an interrupt
> > # s
On 11/19, Alan Stern wrote:
>
> On Sun, 19 Nov 2006, Oleg Nesterov wrote:
>
> > int xxx_read_lock(struct xxx_struct *sp)
> > {
> > int idx;
> >
> > idx = sp->completed & 0x1;
> > atomic_inc(sp->ctr + idx);
> > smp_mb__after_atomic_inc();
> >
On Sun, Nov 19, 2006 at 11:24:08AM -0800, David Rientjes wrote:
> The cs5530A will be able to go into active idle (PWRSVE) so its PCI class
> revision should be accurately stored.
Already queued in cpufreq.git for .20
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from
On Sun, Nov 19, 2006 at 12:09:22PM -0500, Jeff Mahoney wrote:
> > I would copy a relatively simple C implementation, like
> > arch/h8300/lib/checksum.c
>
> As long as the h8300 version has the same output as the x86 version.
As the matter of fact, h8300 version is severely broken and no, it
defi
but doesn't depends on NET (Networking).
drivers/built-in.o: In function `ipath_free_pddata':
(.text.ipath_free_pddata+0x155): undefined reference to `kfree_skb'
drivers/built-in.o: In function `ipath_alloc_skb':
(.text.ipath_alloc_skb+0x28): undefined reference to `__alloc_skb'
drivers/built-in.o
Hello.
Benjamin Herrenschmidt wrote:
EOI is a more "high level" thing that some "intelligent" PICs that
automatically raise the priority do to restore the priority to what it
was before the interrupt occured.
Thank you, I know. Even 8259 has the notion of priority and EOI works the
same w
> Sorry, it's the same for x86 version of OpenPIC according to spec. I
> meant
> the PPC implementation here.
Same OpenPIC.. it can deal with both INTACK cycles and reading from an
INTACK register. On some PPC's, we actually have logic in the bridge to
generate the INTACK cycle (which exist
On Sun, 2006-11-19 at 21:23 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > > dont worry, it's -rt only stuff.
> >
> > Still, I'm curious :-) Besides, there have been people talking about
> > having -rt work on ppc64 so ...
>
> ok :)
>
> > What do you need
Hello.
Sergei Shtylyov wrote:
On MPIC or XICS, this is implicit by reading the vector. On some more
dumb controllers, this has to be done explicitely.
This is not implicit -- CPU has to read INTACK reg. on OpenPIC. Really
Sorry, it's the same for x86 version of OpenPIC according to
>Yeah, that's what the threaded versions of flow handlers are doing. Except
> they're calling ack() to actually EOI an IRQ.
Ok well, them the fix is to fix them not the PIC code :-)
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hello.
Benjamin Herrenschmidt wrote:
The fasteoi flow seem to only had been used for x86 IOAPIC in the RT patch
only *before* PPC took to using them in the mainline...
I don't think so, I asked for the fasteoi to be created while porting
ppc to genirq :-)
Oh, I was unaware of such det
On Sun, 19 Nov 2006 18:13:45 +0100
Stefan Richter <[EMAIL PROTECTED]> wrote:
> Mattia Dongili wrote:
> > the winner is... gregkh-driver-network-device.patch
That was a fair bet - that patch has caused a mountain of grief.
> Interesting. Looks very much like eth1394's sysfs interface is getting
>
From: Jay Cliburn <[EMAIL PROTECTED]>
This patch contains auxiliary C files for the Attansic L1 gigabit ethernet
adapter driver.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
atl1_ethtool.c | 530 +++
atl1_hw.c | 840
++
> This is not implicit -- CPU has to read INTACK reg. on OpenPIC.
Which is what I meant... "implicit by reading the vector".
> Really implicit method is in action on x86 where CPU issues dual ACK bus
> cycle to get
> the vector form 8259...
Which you can do on OpenPIC too. It's the same i
From: Randy Dunlap <[EMAIL PROTECTED]>
With I2O_CONFIG=y and I2O_EXT_ADAPTEC=n, kernel build gets:
drivers/message/i2o/i2o_config.c:1115: error: 'i2o_cfg_compat_ioctl' undeclared
here (not in a function)
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/message/i2o/i2o_config.c |
Hello.
Benjamin Herrenschmidt wrote:
I must not that this whole ack() vs eoi() stuff is misleading. For example,
in 8259 driver, mask_ack() method actually sends EOI to PIC, not ACK's an IRQ
-- the actual ACK is implicit on x86 and is used to read the interrupt vector
form 8259 on PPC. So,
On Sun, 2006-11-19 at 23:31 +0300, Sergei Shtylyov wrote:
>The fasteoi flow seem to only had been used for x86 IOAPIC in the RT patch
> only *before* PPC took to using them in the mainline...
I don't think so, I asked for the fasteoi to be created while porting
ppc to genirq :-)
> > threade
On Sun, 19 Nov 2006 11:34:27 -0500
Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> Hej Linus,
>
> Please pull from
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-fixes-2.6.git/
>
> ...
>
> pcmcia: fix 'rmmod pcmcia' with leftover devices
Is this the patch about wh
On Sun, 2006-11-19 at 23:26 +0300, Sergei Shtylyov wrote:
> I must not that this whole ack() vs eoi() stuff is misleading. For
> example,
> in 8259 driver, mask_ack() method actually sends EOI to PIC, not ACK's an IRQ
> -- the actual ACK is implicit on x86 and is used to read the interrupt v
From: Jay Cliburn <[EMAIL PROTECTED]>
This patch contains the build files for the Attansic L1 gigabit ethernet
adapter driver.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
Kconfig | 12
Makefile |1 +
atl1/Makefile | 30 ++
3 fil
Hello.
Ingo Molnar wrote:
What do you need an ack() for on fasteoi ? On all fasteoi controllers
I have, ack is implicit by obtaining the vector number and all there
is is an eoi...
it's a compatibility hack only. Threaded handlers are a different type
of flow, but often the fasteoi handler
Based upon feedback from Stephen Hemminger and Francois Romieu, please
consider this resubmitted patchset that provides support for the Attansic
L1 gigabit ethernet adapter. This patchset is built against 2.6.19-rc6.
The original patchset was submitted 20060927.
The monolithic version of this
From: Jay Cliburn <[EMAIL PROTECTED]>
This patch contains the header files needed by the Attansic L1 gigabit
ethernet adapter driver.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
atl1.h | 251 ++
atl1_hw.h| 991
++
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > dont worry, it's -rt only stuff.
>
> Still, I'm curious :-) Besides, there have been people talking about
> having -rt work on ppc64 so ...
ok :)
> What do you need an ack() for on fasteoi ? On all fasteoi controllers
> I have, ack is i
Hello.
Benjamin Herrenschmidt wrote:
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
Wait wait wait Can somebody (Ingo ?) explain me why the fasteoi
handler is being changed and what is the rationale for adding an ack
that was not necessary before ?
dont worry, it's -rt only stu
Here's Linux 2.4.34-pre6.
Location: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/testing/
Mostly cleanupts this time, as well as fixes for a few "&& 0xff"
typos. As I receivedthe RAM for my Alpha, I could attempt a few
builds with gcc-4.1 and fix 4 obvious problems (lvalue casts).
However, there ar
On Sun, 19 Nov 2006, Oleg Nesterov wrote:
> On 11/17, Jens Axboe wrote:
> >
> > It works for me, but the overhead is still large. Before it would take
> > 8-12 jiffies for a synchronize_srcu() to complete without there actually
> > being any reader locks active, now it takes 2-3 jiffies. So it's
>
On Sun, 2006-11-19 at 21:06 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > Wait wait wait Can somebody (Ingo ?) explain me why the fasteoi
> > handler is being changed and what is the rationale for adding an ack
> > that was not necessary before ?
>
>
On Sunday 19 November 2006 13:07, Stefan Richter wrote:
>Gene Heskett wrote:
>> If this has anything to do with kino segfaulting and going away when
>> trying to make use of the on-screen camera motion controls, please see
>> to it that it gets incorporated into the next FC6 kernel release, its
>>
On Sun, 19 Nov 2006, Oleg Nesterov wrote:
> > Put it this way: If the missing memory barrier in srcu_read_lock() after
> > the atomic_inc call isn't needed, then neither is the existing memory
> > barrier after the per-cpu counter gets incremented.
>
> I disagree. There is another reason for mb()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andi Kleen wrote:
>>> I would copy a relatively simple C implementation, like
>>> arch/h8300/lib/checksum.c
>> As long as the h8300 version has the same output as the x86 version.
>
> The trouble is that the different architecture have different outp
Hello.
Benjamin Herrenschmidt wrote:
As fasteoi type chips never had to define their ack() method before the
recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler
in thread resulted in the kernel crash. So, define their ack() methods to be
the same as their eoi() ones...
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Wait wait wait Can somebody (Ingo ?) explain me why the fasteoi
> handler is being changed and what is the rationale for adding an ack
> that was not necessary before ?
dont worry, it's -rt only stuff.
Ingo
-
To unsubscribe fr
On Mon, 2006-11-20 at 07:00 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2006-11-19 at 22:43 +0300, Sergei Shtylyov wrote:
> > As fasteoi type chips never had to define their ack() method before the
> > recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler
> > in thread res
Hi !
Here's linux-2.4.33.4, which adds a few fixes on top of 2.4.33.3.
All of those are pretty minimal. Nothing critical here, there is
no reason to hurry an upgrade for people running 2.4.33.3, unless
they're hit by one of those bugs of course. It also fixes two
vulnerabilities :
- CVE-2006-51
On Sun, 2006-11-19 at 22:43 +0300, Sergei Shtylyov wrote:
> As fasteoi type chips never had to define their ack() method before the
> recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler
> in thread resulted in the kernel crash. So, define their ack() methods to be
> the sam
On Sun, 19 Nov 2006, Rafael J. Wysocki wrote:
>
> > because people point to the suspend-to-disk instead.
>
> Who they?
Like you _just_ did.
> > - enable PM_DEBUG, and PM_TRACE
>
> This only works on i386, no?
Right now the trivial functions are only available on i386, yes. The
concept wor
On Sun, 19 Nov 2006, Mike Galbraith wrote:
>
> Thanks for the tip, but it didn't work. It suspended instantly, and got
> my hopes up (manually, SuSE says "not supported, go away"), but resume
> still left me with an utterly dead box (minus flashing crud on display).
Right. That's why we have PM
On Sun, 19 Nov 2006, Stefan Richter wrote:
> I wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=6706 :
> ...
> > Right now I don't see a sane fix but I will have a few nights sleep over
> > it...
>
> A couple of reboots and a slightly charred pizza later I found out the
> following:
>
> 1.
On Sun, 2006-11-19 at 19:58 +0100, Rafael J. Wysocki wrote:
> On Sunday, 19 November 2006 18:52, Mike Galbraith wrote:
> > On Sun, 2006-11-19 at 09:33 -0800, Linus Torvalds wrote:
> > >
> > > On Sun, 19 Nov 2006, Chuck Ebbert wrote:
> > > >
> > > > When doing 'make oldconfig' we should ask about s
On Thu, Nov 09, 2006 at 07:49:28PM +0300, Kirill Korotaev wrote:
> MAJOR CHANGES in v6 (see details below):
> - configfs interface instead of syscalls (as wanted by CKRM people...)
> - added numfiles resource accounting
> - added numtasks resource accounting
>
> numfiles and numtasks controllers d
On Sun, Nov 19, 2006 at 09:08:47AM -0800, Roland Dreier wrote:
> looks weird to me. AFAIK the C standard says that offsetof() comes
> from plain old .
Yes, sorry.
Fixed in my tree, will be send to mainline shortly.
Jeff
--
Work email - jdike at linux dot intel d
As fasteoi type chips never had to define their ack() method before the
recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler
in thread resulted in the kernel crash. So, define their ack() methods to be
the same as their eoi() ones...
Signed-off-by: Sergei Shtylyov <[EMAIL P
On Sun, Nov 19, 2006 at 04:58:47PM +0100, Olaf Hering wrote:
> How do you get _STDDEF_H defined in
> /usr/lib/gcc///include/stddef.h ?
> For me _STDDEF_H remains undefined, and /usr/include/linux/stddef.h has
> offsetof inside __KERNEL__.
I guess that the __KERNEL__ is your problem. I don't see t
On Sun, Nov 19, 2006 at 08:15:31PM +0100, Jan Engelhardt wrote:
>
> On Nov 19 2006 19:44, Willy Tarreau wrote:
> >On Sun, Nov 19, 2006 at 07:25:34PM +0100, Jan Engelhardt wrote:
> >> > [~]>./scsifmt /dev/sdd fmt
> >> > scsifmt: non-sense ioctl error
> >> >
> >> > Didn't work too well, too. Any ide
The cs5530A will be able to go into active idle (PWRSVE) so its PCI class
revision should be accurately stored.
Cc: Hiroshi Miura <[EMAIL PROTECTED]>
Cc: Dave Jones <[EMAIL PROTECTED]>
Cc: Zwane Mwaikambo <[EMAIL PROTECTED]>
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
arch/i386/kernel/
Hi All,
The following patches are in the linux-2.6-watchdog-mm git tree:
diffstat:
drivers/char/watchdog/Kconfig | 32 +
drivers/char/watchdog/Makefile |4
drivers/char/watchdog/iTCO_vendor_support.c | 307 +
drivers/char/watchdog/iTCO_wdt.c
On Nov 19 2006 19:44, Willy Tarreau wrote:
>On Sun, Nov 19, 2006 at 07:25:34PM +0100, Jan Engelhardt wrote:
>> > [~]>./scsifmt /dev/sdd fmt
>> > scsifmt: non-sense ioctl error
>> >
>> > Didn't work too well, too. Any ideas?
>>
>>
>> Does not mkfs suffice?
>
>No, he's talking about low-level form
Andi Kleen wrote:
I would copy a relatively simple C implementation, like
arch/h8300/lib/checksum.c
As long as the h8300 version has the same output as the x86 version.
The trouble is that the different architecture have different output
for csum_partial. So you already got a bug when someon
On Sunday, 19 November 2006 18:52, Mike Galbraith wrote:
> On Sun, 2006-11-19 at 09:33 -0800, Linus Torvalds wrote:
> >
> > On Sun, 19 Nov 2006, Chuck Ebbert wrote:
> > >
> > > When doing 'make oldconfig' we should ask about suspend/resume
> > > debug features when SOFTWARE_SUSPEND is not enabled.
On Sun, 2006-11-19 at 10:25 -0800, Linus Torvalds wrote:
>
> On Sun, 19 Nov 2006, Mike Galbraith wrote:
> >
> > Here I am wishing I had the _opportunity_ to be sane. With my ATI X850
> > AGP card, I have no choices except swsusp or reboot.
>
> Try using regular VGA console, and letting X re-ini
1 - 100 of 165 matches
Mail list logo
