On 7/13/05, Mikhail Kshevetskiy <[EMAIL PROTECTED]> wrote:
> symptom
> ===
> modprobe e100
> ifconfig eth0 netmask
>
> result:
> ===
> SIOCADDRT: Network is unreachable
>
> There were no such error in 2.6.13-rc2
odd, both e100 and eepro100 are broken? This might indicate something
On 7/13/05, Mikhail Kshevetskiy [EMAIL PROTECTED] wrote:
symptom
===
modprobe e100
ifconfig eth0 ip netmask netmask
result:
===
SIOCADDRT: Network is unreachable
There were no such error in 2.6.13-rc2
odd, both e100 and eepro100 are broken? This might indicate something
wierd
t; bss-drivers_ieee1394_sbp2
> bss-drivers_ieee1394_pcilynx
> bss-drivers_ieee1394_nodemgr
> bss-drivers_ieee1394_ieee1394_core
> sparse-net
> sparse-mm_slab
> sparse-kernel_audit
> sparse-include_net_bluetooth_bluetooth.h
> sparse-fs_reiserfs_fix_node
> sparse-drivers_ieee139
/2.6.13-rc2-kj/
Not Found
The requested URL /kj/2.6.13-rc2-kj/ was not found on this server.
--
Jesse Millan
CNS Unix Team
Portland State University
Phone: (503) 725-9151
Mobile: (503) 453-0748
GPG key: www.system-calls.com/gpg.php
grep --recursive --ignore-case 'SHOULD WORK' /usr/src/linux/* | wc
se. I don't envy
you having to put up with the frequent flamefests...
Jesse
-
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
oduct that could benefit (however slightly). Not sure about other
bridges though.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
bridges though.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
don't envy
you having to put up with the frequent flamefests...
Jesse
-
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 the FAQ at http://www.tux.org
t; which it should not do - it should look like i386/Kconfig...
Yeah, I noticed that too. If you've got a patch to clean it up, we should go
ahead and get it sent off to Tony.
I sent this to linux-ia64 the other day to address these issues.
Jesse
= arch/ia64/Kconfig 1.85 vs edited =
--
. If you've got a patch to clean it up, we should go
ahead and get it sent off to Tony.
I sent this to linux-ia64 the other day to address these issues.
Jesse
= arch/ia64/Kconfig 1.85 vs edited =
--- 1.85/arch/ia64/Kconfig 2005-01-28 15:32:25 -08:00
+++ edited/arch/ia64/Kconfig 2005-03-21 09:38
}
I'll ask Markus to try reverting this since I still don't have a machine
setup. It sounds like a possibility given what he's seeing.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
tion of
> cards and X releases ... anyone with a VIA chipset and Radeon graphics
> card or r128 card.. testing the next -mm would help me a lot..
I'm trying to get ahold of one--so hopefully I'll be able to test and fix this
stuff up when I do.
Jesse
-
To unsubscribe from this list: sen
On Thursday, March 24, 2005 8:54 am, Jesse Barnes wrote:
> On Wednesday, March 23, 2005 10:24 pm, Benjamin Herrenschmidt wrote:
> > While experimenting with framebuffer access performances, we noticed a
> > very significant improvement in write access to it when not setting
> &
aybe it's time for a more generic call to support this stuff, both for
in-kernel mappings and ones that we export to userspace.
Jesse
-
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.ke
call to support this stuff, both for
in-kernel mappings and ones that we export to userspace.
Jesse
-
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
On Thursday, March 24, 2005 8:54 am, Jesse Barnes wrote:
On Wednesday, March 23, 2005 10:24 pm, Benjamin Herrenschmidt wrote:
While experimenting with framebuffer access performances, we noticed a
very significant improvement in write access to it when not setting
the guarded bit on the MMU
with a VIA chipset and Radeon graphics
card or r128 card.. testing the next -mm would help me a lot..
I'm trying to get ahold of one--so hopefully I'll be able to test and fix this
stuff up when I do.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
a machine
setup. It sounds like a possibility given what he's seeing.
Jesse
-
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 the FAQ at http
On Tuesday, March 22, 2005 1:18 am, Adrian Bunk wrote:
> On Mon, Mar 21, 2005 at 04:42:00PM -0800, Jesse Barnes wrote:
> > On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
> > > On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
> > > > On Monday,
On Tuesday, March 22, 2005 1:18 am, Adrian Bunk wrote:
On Mon, Mar 21, 2005 at 04:42:00PM -0800, Jesse Barnes wrote:
On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
On Monday, March 21, 2005 2:51 am, Andrew Morton wrote
On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
> On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
> > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc
> > >1/2. 6
e tree, and it uses those functions.
Thanks,
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
, why does ACPI now depend on PM? On some platforms it has very little to
do with power management, and this breaks the build for sn2...
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
very little to
do with power management, and this breaks the build for sn2...
Jesse
-
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 the FAQ at http
, and it uses those functions.
Thanks,
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc
1/2. 6.12-rc1-mm1/
Andrew, please drop
On Friday, March 18, 2005 7:48 pm, Jesse Barnes wrote:
> On Friday, March 18, 2005 7:40 pm, Jesse Barnes wrote:
> > What does your patch look like? Markus might like to try it out as he
> > narrowed his problem down to something AGP related recently too:
> > http://bugme.osd
On Friday, March 18, 2005 7:48 pm, Jesse Barnes wrote:
On Friday, March 18, 2005 7:40 pm, Jesse Barnes wrote:
What does your patch look like? Markus might like to try it out as he
narrowed his problem down to something AGP related recently too:
http://bugme.osdl.org/show_bug.cgi?id=4337
On Friday, March 18, 2005 7:40 pm, Jesse Barnes wrote:
> What does your patch look like? Markus might like to try it out as he
> narrowed his problem down to something AGP related recently too:
> http://bugme.osdl.org/show_bug.cgi?id=4337
duh, ignore me. At least Markus can give
blem down to something AGP related recently too:
http://bugme.osdl.org/show_bug.cgi?id=4337
Thanks,
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
Thanks,
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
On Friday, March 18, 2005 7:40 pm, Jesse Barnes wrote:
What does your patch look like? Markus might like to try it out as he
narrowed his problem down to something AGP related recently too:
http://bugme.osdl.org/show_bug.cgi?id=4337
duh, ignore me. At least Markus can give it a try.
Jesse
tatus on these? Last I heard, some cleanup was going to
happen to make kgdb suitable for the mainline, did that ever happen? Also,
it would be nice if I could connect to a remote kernel running the kgdb stubs
w/o having to run gdb on the same ethernet segment. Would that be difficult
to fi
erspace should take care of misordered
> messages.
> I personally prefer such mechanism.
Yep, I agree. Hopefully Guillaume will too :)
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
ork very well on a large CPU count system.
cn_fork_lock will be taken by each CPU everytime it does a fork, meaning that
forks will be very slow if lots of CPUs are doing them at the same time. Is
there a more scalable way to ensure message delivery?
Jesse
-
To unsubscribe from this l
will be taken by each CPU everytime it does a fork, meaning that
forks will be very slow if lots of CPUs are doing them at the same time. Is
there a more scalable way to ensure message delivery?
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
of misordered
messages.
I personally prefer such mechanism.
Yep, I agree. Hopefully Guillaume will too :)
Jesse
-
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
for the mainline, did that ever happen? Also,
it would be nice if I could connect to a remote kernel running the kgdb stubs
w/o having to run gdb on the same ethernet segment. Would that be difficult
to fix?
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
esses. Ken, are you sure you need to make these changes at all?
Does Xen break w/o them?
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
on all those platforms. The
biggest problem with virt_to_bus (well, depending on who you talk to) is that
it can't handle systems where the address translation must be done
differently depending on *which* bus we're getting a bus address for. Not
sure what makes sense in this case though...
lt;[EMAIL PROTECTED]>
Ugg, if we're messing with these drivers we may as well fix them properly
rather than adding in more uses of the broken virt_to_bus interface...
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
with these drivers we may as well fix them properly
rather than adding in more uses of the broken virt_to_bus interface...
Jesse
-
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
to) is that
it can't handle systems where the address translation must be done
differently depending on *which* bus we're getting a bus address for. Not
sure what makes sense in this case though... is the DMA mapping interface
appropriate?
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux
the code actually makes sense.
Converting to the DMA mapping API doesn't make sense at all in this context
then, since we're basically programming the GATT (an IOMMU type table) with
physical addresses. Ken, are you sure you need to make these changes at all?
Does Xen break w/o them?
Jesse
On Tuesday, March 15, 2005 11:25 am, Andrew Morton wrote:
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I'd be happy to test and fix things, but the page table walker patches
> > broke ia64... Once that's cleared up I can go digging.
>
> We're hoping that davem's fix
at's cleared up I can go digging.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
;
> Why can't you solve this without making sal_console_uart global?
I think that would mean moving some of the structure initializaiton into an
init function somewhere. But the compiler knows the addrs of these
structures, so there must be a better way to do it, I just don't know it.
Any suggestions
?
I think that would mean moving some of the structure initializaiton into an
init function somewhere. But the compiler knows the addrs of these
structures, so there must be a better way to do it, I just don't know it.
Any suggestions?
Jesse
-
To unsubscribe from this list: send the line
.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
On Tuesday, March 15, 2005 11:25 am, Andrew Morton wrote:
Jesse Barnes [EMAIL PROTECTED] wrote:
I'd be happy to test and fix things, but the page table walker patches
broke ia64... Once that's cleared up I can go digging.
We're hoping that davem's fix (committed yesterday) fixed
definition
of sal_console_uart is marked 'static'. This patch just removes the static
qualifier from sal_console_uart to avoid the inconsistency. Does it look ok
to you, Pat?
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
= drivers/serial/sn_console.c 1.12 vs
On Monday, March 14, 2005 9:54 am, Nishanth Aravamudan wrote:
> On Mon, Mar 14, 2005 at 09:45:44AM -0800, Jesse Barnes wrote:
> > On Sunday, March 6, 2005 2:36 pm, [EMAIL PROTECTED] wrote:
> > > Any comments would be, as always, appreciated.
> >
> > I don't h
On Sunday, March 6, 2005 2:36 pm, [EMAIL PROTECTED] wrote:
> Any comments would be, as always, appreciated.
I don't have a problem with this change, but the maintainer probably should
have been Cc'd. Greg, does this change look ok to you? Note that it's
already been committed to the upstream
g real errors better and keeping the junk
to a minimum.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
rusade out of removing
unneeded and unjustified printks from the kernel before it really gets better
though...
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
before it really gets better
though...
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
On Sunday, March 6, 2005 2:36 pm, [EMAIL PROTECTED] wrote:
Any comments would be, as always, appreciated.
I don't have a problem with this change, but the maintainer probably should
have been Cc'd. Greg, does this change look ok to you? Note that it's
already been committed to the upstream
On Monday, March 14, 2005 9:54 am, Nishanth Aravamudan wrote:
On Mon, Mar 14, 2005 at 09:45:44AM -0800, Jesse Barnes wrote:
On Sunday, March 6, 2005 2:36 pm, [EMAIL PROTECTED] wrote:
Any comments would be, as always, appreciated.
I don't have a problem with this change
definition
of sal_console_uart is marked 'static'. This patch just removes the static
qualifier from sal_console_uart to avoid the inconsistency. Does it look ok
to you, Pat?
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
Thanks,
Jesse
= drivers/serial/sn_console.c 1.12 vs edited
Roland, Daniel,
I was the one that reported the ptrace problems which caused all that
hoopla in Nov and Dec. I have tested your new patches and find that
there are no new regressions.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
I reported but now on x86-64. Could I get the patches from your
tree so they can be tested?
Jesse
-
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
. Could I get the patches from your
tree so they can be tested?
Jesse
-
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 the FAQ at http://www.tux.org
Roland, Daniel,
I was the one that reported the ptrace problems which caused all that
hoopla in Nov and Dec. I have tested your new patches and find that
there are no new regressions.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
pped the ball.
> I still have the patch in my queue though, so I can push that along.
>
> Are those headers in mainline yet ?
Yeah, I think it's all there now. Looks like Linus did a pull from ia64
recently, so it *should* all build.
Thanks,
Jesse
-
To unsubscribe from this list: send t
the patch in my queue though, so I can push that along.
Are those headers in mainline yet ?
Yeah, I think it's all there now. Looks like Linus did a pull from ia64
recently, so it *should* all build.
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Friday, March 11, 2005 10:04 am, James Simmons wrote:
> > > Oh, and by the way, I have 3D working relatively well on my G5 with a
> > > 64-bit kernel (and 32-bit X server and clients), which is why I care
> > > about AGP 3.0 support. :)
> >
> > I have a system in my office with several gfx
think Mike posted it but hasn't submitted it to Dave yet since it needed
another change that only just made it into the ia64 tree.
Jesse
-
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.ke
; you can mmap them and do simple programming that way.
As for the idea of userland drivers in general, I'm not sure I like it. I'm
afraid it will just encourage more undebuggable, x86 binary blobs (or big
source code blobs with their own bridge drivers like X) that people are
forced to run to get
On Thursday, March 10, 2005 8:30 pm, Benjamin Herrenschmidt wrote:
> On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote:
> > On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
> > > That one is even worse... from what I see in your lspci output, you
> > &
On Thursday, March 10, 2005 8:30 pm, Benjamin Herrenschmidt wrote:
On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote:
On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
That one is even worse... from what I see in your lspci output, you
have no bridge with AGP
of userland drivers in general, I'm not sure I like it. I'm
afraid it will just encourage more undebuggable, x86 binary blobs (or big
source code blobs with their own bridge drivers like X) that people are
forced to run to get their hardware to work...
Jesse
-
To unsubscribe from this list: send the line
submitted it to Dave yet since it needed
another change that only just made it into the ia64 tree.
Jesse
-
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
On Friday, March 11, 2005 10:04 am, James Simmons wrote:
Oh, and by the way, I have 3D working relatively well on my G5 with a
64-bit kernel (and 32-bit X server and clients), which is why I care
about AGP 3.0 support. :)
I have a system in my office with several gfx pipes on
agp slots hooked up to
host to agp bridges.
> Are you sure there is any real AGP slot in there ?
Yes :)
Jesse
-
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
On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote:
> What is the relationship in the PCI device tree between the video
> cards and their bridges? Is there for instance only one AGP bridge
> per host bridge?
I *think* a TIO (numalink<->agp & numalink<->pci) has two AGP busses coming
off
in my office with several gfx pipes on different AGP busses,
and I'd like that to work well too! :)
Jesse
-
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/majordom
on different AGP busses,
and I'd like that to work well too! :)
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote:
What is the relationship in the PCI device tree between the video
cards and their bridges? Is there for instance only one AGP bridge
per host bridge?
I *think* a TIO (numalink-agp numalink-pci) has two AGP busses coming
off of it...
hooked up to
host to agp bridges.
Are you sure there is any real AGP slot in there ?
Yes :)
Jesse
-
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
nside"
> interrupt disabled sections.
That was oprofile output, but on ia64, 'NMI's are maskable due to the way irq
disabling works. Here's a very hackish patch that changes the kernel to use
cr.tpr instead of psr.i for interrupt control. Making oprofile use real ia64
NMIs is left as an
inside"
> interrupt disabled sections.
Oh, and there are other ways of doing interrupt off profiling by using the
PMU. q-tools can do this I think.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
space is the whole I/O window of a given bus or PCI domain
(granularity defined by the platform--some will only have one I/O space), and
the arbiter's job is to arbitrate access to subsets of each window. I think
the the VGA stuff here complements the legacy interface rather than
conflicting with it
one I/O space), and
the arbiter's job is to arbitrate access to subsets of each window. I think
the the VGA stuff here complements the legacy interface rather than
conflicting with it.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
off profiling by using the
PMU. q-tools can do this I think.
Jesse
-
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 the FAQ at http://www.tux.org
are maskable due to the way irq
disabling works. Here's a very hackish patch that changes the kernel to use
cr.tpr instead of psr.i for interrupt control. Making oprofile use real ia64
NMIs is left as an exercise for the reader :)
Jesse
= arch/ia64/Kconfig.debug 1.2 vs edited =
--- 1.2
eccasery because we want it to be done before /sbin/init is ran, AKA hide
> the kernel messages :)
You can already hide the kernel messages by booting with the 'quiet' option.
It works pretty well and it seems like this stuff should be in userspace
anyway (console support in general that is).
before /sbin/init is ran, AKA hide
the kernel messages :)
You can already hide the kernel messages by booting with the 'quiet' option.
It works pretty well and it seems like this stuff should be in userspace
anyway (console support in general that is).
Jesse
-
To unsubscribe from this list
be hung off from the bridge they are on?
Probably, though no one in their right mind is going to put anything like that
on these machines (sn2 btw) :). VGA cards will hopefully be the only devices
of this type that we'll have installed.
Jesse
-
To unsubscribe from this list: send the line
from the bridge they are on?
Probably, though no one in their right mind is going to put anything like that
on these machines (sn2 btw) :). VGA cards will hopefully be the only devices
of this type that we'll have installed.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux
t I/O.
> For DMA problems, driver probably has its own, timer-based,
> "something is wrong" timer, anyway, no?
The idea is to allow them to do something like that, or consolidate such
threads in a platform specific error handling thread or interrupt handler
that can call a driver'
something like that, or consolidate such
threads in a platform specific error handling thread or interrupt handler
that can call a driver's -dma_error(dev) routine (or -error(dev, ERROR_DMA)
or whatever) routine.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wednesday, March 2, 2005 3:30 pm, Linas Vepstas wrote:
> Put it another way: a device driver author should have the opportunity
> to poll the pci bus status if they so desire. Polling for bus status
> on ppc64 is real easy. Given what Jesse Barnes was saying, it sounded
> l
transaction occur in
different contexts, in addition to the PIO transaction interface already
proposed.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
since there would just be one set of
calls, and data reporting could be driven by userspace (whether it's in
old-style sys_acct format, or new-style data that CSA/ELSA defines).
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
d
> seriously, in the case that the fork connector is disabled.
But if it *is* enabled, it takes a global lock on every fork. That can't
scale on a big multiprocessor if lots of CPUs are doing lots of forks...
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
. That can't
scale on a big multiprocessor if lots of CPUs are doing lots of forks...
Jesse
-
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 the FAQ at http
be one set of
calls, and data reporting could be driven by userspace (whether it's in
old-style sys_acct format, or new-style data that CSA/ELSA defines).
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
interface already
proposed.
Jesse
-
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 the FAQ at http://www.tux.org/lkml/
On Wednesday, March 2, 2005 3:30 pm, Linas Vepstas wrote:
Put it another way: a device driver author should have the opportunity
to poll the pci bus status if they so desire. Polling for bus status
on ppc64 is real easy. Given what Jesse Barnes was saying, it sounded
like a simple (optional
1001 - 1100 of 1411 matches
Mail list logo
