ectors, lba48
Is this a known problem? Is there anything in particular I should try?
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
Ple
exact same place, right after announcing the first
> device.
>
> Try booting with noapic.
Thanks a lot, noapic worked. I guess that means this is a generic IRQ
routing or setup issue, rather than something SATA specific?
Jesse
-
To unsubscribe from this list: send the line "unsubs
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
wie
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
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
> > &
there; 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
f
I 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
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
d dropped 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:
t 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.
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
personal crusade 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/
bout that--reporting 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/
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 t
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
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.
;
> 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 s
. Once that'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/
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 th
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 PRO
mean it makes sense 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
physical addresses. 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/
I mentioned before, this won't work 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
-
nd of course userspace 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]
M
est status 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
try it out as he
narrowed his problem 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/
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
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
, 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
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
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,
f
_PAGE_GUARDED?
Maybe 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 majordom
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
> &
s fine for a combination 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 unsubscri
->dev, VIA_GARTCTRL, temp);
}
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 t
cpi/Kconfig,
> > 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/Kconfi
in both drivers to KERN_INFO
and describes the situation a bit more accurately.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
P.S. Jon, I think the pci_map_rom code is buggy--if the option ROM signature
is missing or indicates that there's no ROM, the routine still retur
would turn into return
NULLs (though the code should probably be refactored to make that a little
clearer) along with an iounmap?
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
On Thursday, February 17, 2005 8:29 am, Jon Smirl wrote:
> On Wed, 16 Feb 2005 16:00:47 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > It looks like it's trying to verify all the ROMs on a given PCI device
> > rather than just the one we just ioremap'd above.
omething different?
Shouldn't it return NULL if the signature is invalid?
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, February 17, 2005 9:32 am, Jon Smirl wrote:
> > Shouldn't it return NULL if the signature is invalid?
>
> But then you couldn't get to your non-standard ROMs
Ok, I'll fix up the callers then.
Jesse
-
To unsubscribe from this list: send the line "unsub
On Thursday, February 17, 2005 9:32 am, Jon Smirl wrote:
> On Thu, 17 Feb 2005 09:29:53 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Thursday, February 17, 2005 8:33 am, Jon Smirl wrote:
> > > > No, pci_map_rom shouldn't test the signature IMHO. While
rgument. It would check the
> > signature, and iterate all "partitions" til it finds the proper
> > architecture (or none).
>
> The spec allows for it but has anyone actually seen a ROM with
> multiple images in it? I haven't but I only work on x86.
I haven&
my next set of patches.
Keep in mind that the interface above is probably specific to PCI to PCI
bridges since there's a spec for that. Host to PCI bridges may implement
their own methods for VGA routing and legacy port access.
> > Jesse can comment on the specific support needed for
tup_irq,
> + .shutdown = sn_shutdown_irq,
> + .enable = sn_enable_irq,
> + .disable = sn_disable_irq,
> + .ack = sn_ack_irq,
> + .end = sn_end_irq,
> + .set_affinity = sn_set_affinity_irq
> };
>
> unsigned int sn_local_vector_to_irq(u8 vector)
Looks fine.
Acked-by:
now what to do.
> Also is the legacy IO space mapped to IO Memory on the other side of the
> bridge?
How do you mean? Legacy I/O port accesses just become strongly ordered memory
transactions, afaik, and legacy memory accesses are dealt with the same way.
Jesse
-
To unsubscribe from
On Monday, February 28, 2005 4:13 pm, Adam Belay wrote:
> On Mon, 2005-02-28 at 15:38 -0800, Jesse Barnes wrote:
> > On Monday, February 28, 2005 3:27 pm, Adam Belay wrote:
> > > How can we specify which bus to target?
> >
> > Maybe we could have a list of legacy (
fb drivers can be easily loaded and unloaded if the fb devices
aren't in use.
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/
s, while the inline ioerr_clear/ioerr_check API could
potentially deal with errors as they happen (probably in the case of PIO
related errors), when the additional context may allow us to be smarter about
recovery.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-k
cted
> 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 l
ction 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
he end of the 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/
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
during that 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
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
t; neccasery 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 gene
pace 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 w
ile "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
le "inside"
> 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
e a system 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.kern
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
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
Rage IIC Video Controller with 4MB Video Memory
9.1 GB Wide Ultra2 (7200 rpm) 1"
Any pointers or help would be appreciated.
-Jesse Noller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
l quote) and then copying it back without the alternate stream(s).
--
-----
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe li
w/ the 2.4 kernel)
- Note, if anyone has any pointers, please let me know.
-Jesse
-Original Message-
From: Marty Fouts [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 07, 2000 5:30 PM
To: [EMAIL PROTECTED]
Subject: RE: Scalability Efforts
FWIW, large system scalability, especial
zed
tty being used as a printer (serial dot matrix printers make
excellent trace logs).
--
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
please copy netdev, or better yet [EMAIL PROTECTED] in
the future for e1000 issues like this. Feel free to move the
conversation there, if you would like.
On 4/19/07, David Ford <[EMAIL PROTECTED]> wrote:
I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and see
6:00.0
IO window: disabled.
MEM window: a100-a2ff (32M)
PREFETCH window: disabled.
PCI: Bridge: :00:1e.0
IO window: 1000-1fff
MEM window: a100-a30f (~32M)
PREFETCH window: a000-a0ff
...
And these bridges got more space somehow... Greg who's in charge of o
even without taking alignment
> requirements into account. Then, if some window is too small, we just
> let the pci_assign_unassigned_resources to take care of that.
Sounds good, hopefully reassigning the bridge resources won't cause too
much trouble. Do you have time to hack this up? If not, I could give
it a t
On Friday, April 20, 2007 11:28 am Linus Torvalds wrote:
> On Fri, 20 Apr 2007, Jesse Barnes wrote:
> > Sounds good, hopefully reassigning the bridge resources won't cause
> > too much trouble. Do you have time to hack this up? If not, I
> > could give it a try, as
but I remember arguing with davem about
this stuff in the past...
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/
needs it, and of course there are i386 and
x86_64 machines that need it to, so it makes sense that it be generic.
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.or
get us a lot of things:
o robust suspend/resume support
o some more independence from X for complex gfx setups
o a good mode at early boot time
and several others I'm leaving out at the moment. On the downside, the
modesetting layer will be a chunk of new code, and require enhanced
On Monday, March 19, 2007 1:05 pm David Miller wrote:
> From: Jesse Barnes <[EMAIL PROTECTED]>
> Date: Mon, 19 Mar 2007 12:54:36 -0700
>
> > Kernel based modesetting should get us a lot of things:
>
> But for panics you're ignoring what Peter and I are saying.
>
ROTECTED]>
Yay! I'm glad we can finally get rid of this in favor of the new pata
drivers. Don't forget to kill the stuff in
Documentation/kernel-parameters.txt though.
Acked-by: Jesse Barnes <[EMAIL PROTECTED]>
Jesse
-
To unsubscribe from this list: send the line "
John wrote:
> Jesse Brandeburg wrote:
>> What would you like to do? At this stage I would like e100 to work
>> better than it is, but I'm not sure what to do next.
>
> Hello everyone,
>
> I'm resurrecting this thread because it appears we'll need t
le tested, *but* I couldn't test this patch to make sure it worked
because I couldn't boot 2.6.20-git due to it not finding my RAID0 + lvm
disk.
[PATCH] e1000: fix shared interrupt warning message
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jesse Brandeburg <[
I see the other mmconfig stuff is upstream now, can we get this added
too? The Asus bug Olivier mentioned also appears to be fixed, so this
patch should be safe.
Thanks,
Jesse
On Wednesday, January 10, 2007 6:53 pm Jesse Barnes wrote:
> This is a resend of the patch I sent earlier to Oli
Keep reading...
On Wednesday, April 25, 2007 4:07 pm Andrew Morton wrote:
> On Wed, 25 Apr 2007 15:35:15 -0700 Jesse Barnes
<[EMAIL PROTECTED]> wrote:
> > I see the other mmconfig stuff is upstream now, can we get this
> > added too? The Asus bug Olivier mentioned also ap
x27;s recent
cleanup patches.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..1339d31 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@ -72,6 +72,26 @
a rom file should be created due to a shadow resource, which is also
moved to a little later in the boot cycle so it will occur after the
video fixup. Tested and works on my i386 test box.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff -Napur -X /home/jbarnes/dontdiff linux-2.6.21
On 3/26/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue <0>
TDH
22 should be ok. I've only heard one
complaint about this bug so far, and that was caused by some code still
in development.
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
Roberto Nibali wrote:
>>> Sounds sane to me. My overall opinion on eepro100 removal is that
>>> we're not there yet. Rare problem cases remain where e100 fails
>>> but eepro100 works, and it's older drivers so its low priority for
>>> everybody.
>>>
>>> Needs to happen, though...
>>
>> It seem
ees only 4 cards that are misnumbered and one is missing.
what does 'ip link' or 'ifconfig -a' show?
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 8/11/05, Stephen D. Williams <[EMAIL PROTECTED]> wrote:
> The chipset is an Intel 8x0 something. Unfortunately, there is a
> heatsink semi-permanently installed over everything. Is there a /proc
> pseudofile that will give me good identifying chipset info to report here?
you can show the chip
quot;volatile" or "asm("eieio")" or whatever method your platform
> requires.)
writel() ensures ordering? Only from one CPU, another CPU issuing a
write at some later time may have its write arrive first. See
Documentation/io_ordering.txt for some documentati
ll readX is a
> relatively expensive operation.
>
Yeah, wrote that too :). io_ordering.txt should probably just get folded
into deviceiobook at some point... Or we could just replace both with
URL pointers to LDD vol. 3. ;)
Jesse
-
To unsubscribe from this list: send the line "unsubscribe
On 12/20/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> Yeah, I guess that's a problem. From a user perspective, the
> functionality is only really useful if the latency is very small. I
> think where possible we'd want to power down the chip while keeping the
> phy up, but it would be nice t
; option.
(Note that this has no effect on a normal boot, which is ridiculously
verbose these days.)
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
diff --git a/arch/i386/pci/mmconfig.c b/arch/i386/pci/mmconfig.c
index e2616a2..b95e7f3 100644
--- a/arch/i386/pci/mmco
On Tuesday, January 2, 2007 2:36 am, Alan wrote:
> On Mon, 1 Jan 2007 21:01:38 -0800
>
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > Using MMCONFIG for PCI config space access is simply an
> > optimization, not a requirement. Therefore, when it can't be used,
e
> word out in case someone else is testing this kernel on this nic chipset.
Upon some further investigation with Allen, I got this info, and it
appears that his system is not freeing MSI irq's correctly.
from our discussion:
Allen wrote:
Jesse Brandeburg wrote:
I believe you may hav
added Linux-pci
Jesse Brandeburg wrote:
> On 1/16/07, Allen Parker <[EMAIL PROTECTED]> wrote:
>> Allen Parker wrote:
>>> I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
>>> under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier
&g
interfaces could be supported on other platforms (iirc benh has
been planning to add legacy_* support to ppc for awhile). It would be
great if they were supported everywhere to provide userspace with a
fairly sane way to get at this stuff on all Linux systems...
Should be trivial on i386
t; chipsets. BIOSen suck.
Ouch. It doesn't seem like there's a sane general way to fix this up,
aside from some sort of blacklist. Maybe it's best to leave this
particular bridge unsupported for now...
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscrib
on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv
just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.
On 8/30/05, Daniel Drake <[EMAIL PROTECTED]> wrote:
> Forwarding on, please reply-to-all in future.
>
> Ste
sense on other platforms
too, with weird ISA I/O and memory space mapping requirements.
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, January 3, 2007 5:53 am, Arjan van de Ven wrote:
> On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
> > Using MMCONFIG for PCI config space access is simply an
> > optimization, not a requirement. Therefore, when it can't be used,
> > there's no
On Wednesday, January 3, 2007 5:53 am, Arjan van de Ven wrote:
> On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
> > Using MMCONFIG for PCI config space access is simply an
> > optimization, not a requirement. Therefore, when it can't be used,
> > there's no
401 - 500 of 756 matches
Mail list logo
