On Dec 7, 2007 9:58 AM, Neil Horman <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
> > On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
> > > On Dec 7, 2007 12:50 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Dec 6, 2007 4:33 PM,
On Dec 7, 2007 9:58 AM, Neil Horman [EMAIL PROTECTED] wrote:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman
On 10/16/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007 21:51:13 +0200 Thomas Meyer wrote:
>
> [adding kexec mailing list]
>
>
> > Hi.
> >
> > Look at this:
> >
> > $ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1)
> > arch/x86/boot/bzImage: Linux
On 10/16/07, Randy Dunlap [EMAIL PROTECTED] wrote:
On Tue, 16 Oct 2007 21:51:13 +0200 Thomas Meyer wrote:
[adding kexec mailing list]
Hi.
Look at this:
$ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1)
arch/x86/boot/bzImage: Linux kernel x86 boot
On 5/11/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Pavel Machek wrote:
>
> I do not think OLPC is using linuxBIOS these days. What they have
> certainly looks like Sun's ROM monitor.
>
That would be OpenFirmware, then.
current kernel for x86 support OFW boot patch?
YH
-
To unsubscribe
On 5/11/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
I do not think OLPC is using linuxBIOS these days. What they have
certainly looks like Sun's ROM monitor.
That would be OpenFirmware, then.
current kernel for x86 support OFW boot patch?
YH
-
To unsubscribe from this
On 5/9/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
Refine SCREEN_INFO sanity check for vgacon initialization.
Checking video mode field only to see whenever SCREEN_INFO is
initialized is not enougth, in some cases it is zero although
a vga card is present. Lets additionally check cols and
On 5/9/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
We can look in /proc/ioports and see what has reserved
the video resources. That should give us a reasonable
estimate of the video adapter. We can do an ioctl to
the console and see how many
On 5/9/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
H. Peter Anvin [EMAIL PROTECTED] writes:
We can look in /proc/ioports and see what has reserved
the video resources. That should give us a reasonable
estimate of the video adapter. We can do an ioctl to
the console and see how many lines
On 5/9/07, Gerd Hoffmann [EMAIL PROTECTED] wrote:
Refine SCREEN_INFO sanity check for vgacon initialization.
Checking video mode field only to see whenever SCREEN_INFO is
initialized is not enougth, in some cases it is zero although
a vga card is present. Lets additionally check cols and
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
H. Peter Anvin wrote:
Of course, one could argue that since all of those were obsolete by the
time Linux was first created, that it probably doesn't matter and that
isVGA == 0 pretty much means the more obvious thing.
MDA/HGC stuck around for
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to find if there is support vga console.
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
besides elf-x86_64, still need --args-linux to pass sth? but how
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
I believe YH is asking how we setup real_mode_data in /sbin/kexec.
pxelinux:
SCREEN_INFO.orig_video_mode = 3
SCREEN_INFO.orig_x = 0
SCREEN_INFO.orig_y = 24
x86_boot_params[] :
: 00 18
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
You might try a git-bisect, or if it is just these patches
walking through them one-by-one.
f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
Author: Gerd Hoffmann <[EMAIL
the mkelfImage 2.7 patch is at
https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console works well.
the mkelfImage 2.7 patch is
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
setup.S is never executed while doing kexec (unless somebody chooses to
do a real mode entry) and these patches don't change this beahviour.
Tomorrow I will test VGA behaviour on my machine. Are you using some
special frame buffer mode etc?
I
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Yes. setup.S has always been skipped by bzImage via the kexec path
unless you explicitly tell /sbin/kexec to use the 16bit entry point.
Is not having a VGA console a new thing, or it something you just noticed?
Eric
before the
On 5/2/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>> >
>> > So the bzImage structure is currently:
>> >
>> >1. old-style boot sector
>> >2.
On 5/2/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
So the bzImage structure is currently:
1. old-style boot sector
2. old-style boot info,
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Yes. setup.S has always been skipped by bzImage via the kexec path
unless you explicitly tell /sbin/kexec to use the 16bit entry point.
Is not having a VGA console a new thing, or it something you just noticed?
Eric
before the changes,
On 5/8/07, Vivek Goyal [EMAIL PROTECTED] wrote:
setup.S is never executed while doing kexec (unless somebody chooses to
do a real mode entry) and these patches don't change this beahviour.
Tomorrow I will test VGA behaviour on my machine. Are you using some
special frame buffer mode etc?
I
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console works well.
the mkelfImage 2.7 patch is
the mkelfImage 2.7 patch is at
https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj
YH
-
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 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
You might try a git-bisect, or if it is just these patches
walking through them one-by-one.
f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
Author: Gerd Hoffmann [EMAIL PROTECTED]
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
H. Peter Anvin [EMAIL PROTECTED] writes:
I believe YH is asking how we setup real_mode_data in /sbin/kexec.
pxelinux:
SCREEN_INFO.orig_video_mode = 3
SCREEN_INFO.orig_x = 0
SCREEN_INFO.orig_y = 24
x86_boot_params[] :
: 00 18 ff ff
On 5/8/07, Vivek Goyal [EMAIL PROTECTED] wrote:
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
besides elf-x86_64, still need --args-linux to pass sth? but how to
let it load
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to find if there is support vga console.
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
H. Peter Anvin wrote:
Of course, one could argue that since all of those were obsolete by the
time Linux was first created, that it probably doesn't matter and that
isVGA == 0 pretty much means the more obvious thing.
MDA/HGC stuck around for
On 12/2/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Please yank the direct out of the filename if you are making something
like this out of it. That was my note I was going direct to hardware
which is pretty much assumed if you are in LinuxBIOS.
Yes, I adapted the code to used in
On 12/2/06, Eric W. Biederman [EMAIL PROTECTED] wrote:
Please yank the direct out of the filename if you are making something
like this out of it. That was my note I was going direct to hardware
which is pretty much assumed if you are in LinuxBIOS.
Yes, I adapted the code to used in
thanks
YH
On 8/17/05, Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> fyhlu wrote:
> > Me too. If use latest kernel mouse is dead.
> >
> > By the way, did you solve the battery problem in Linux. "Can not read
> > battery status"
>
> Yes. It's a
Me too. If use latest kernel mouse is dead.
By the way, did you solve the battery problem in Linux. "Can not read
battery status"
YH
On 8/16/05, Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Christoph Lameter wrote:
> > On Tue, 16 Aug 2005,
Me too. If use latest kernel mouse is dead.
By the way, did you solve the battery problem in Linux. Can not read
battery status
YH
On 8/16/05, Jeff Mahoney [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Lameter wrote:
On Tue, 16 Aug 2005, jerome lacoste
thanks
YH
On 8/17/05, Jeff Mahoney [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
fyhlu wrote:
Me too. If use latest kernel mouse is dead.
By the way, did you solve the battery problem in Linux. Can not read
battery status
Yes. It's a problem with the
last year some time, I have manually the patch from 2.4 to 2.6. my
patch result is the same as 2.4. It only works when bios doesn't do
the init. Then if the BIOS do the init, it will hang there. I assume
something only can be done once.
YH
On 8/15/05, James Simmons <[EMAIL PROTECTED]> wrote:
>
last year some time, I have manually the patch from 2.4 to 2.6. my
patch result is the same as 2.4. It only works when bios doesn't do
the init. Then if the BIOS do the init, it will hang there. I assume
something only can be done once.
YH
On 8/15/05, James Simmons [EMAIL PROTECTED] wrote:
james,
I remember that xlinit in 2.6 kernel only works when BIOS option-rom
really init fb.
It can not work if the BIOS option rom is not executed.
For 2.4, it reversed, it can not work if BIOS opton-rom is executed.
Only work if BIOS don't excute the option rom.
YH
On 8/12/05, James Simmons
I played a while with atyfb in LinuxBIOS. move the xl_init.c into LinuxBIOS.
there is one patch call xlinit.c that can be used even ati fb is not
inited in BIOS to make kernel still can use atyfb.
I wonder if James put that in mainstream, he already sent one patch
for 2.6.5
please refer to
why matrin need to make apic id to be greater than 0x10 when system is
only 2way?
too much io-apic in system?
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 09:37:11AM -0700, yhlu wrote:
> > So MPTABLE do not have problem with it, only acpi relate
Oh.
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 09:18:07AM -0700, yhlu wrote:
> > good, I will produce one patch next week.
>
> I already did it in my tree.
>
> -Andi
>
-
To unsubscribe from this list: send the line "un
So MPTABLE do not have problem with it, only acpi related...?
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote:
> > I wrote:
> >
> > >>How so? The XAPIC version check should work there.
> > >
> > >ACPI: LAPIC (acpi_id[0x11]
good, I will produce one patch next week.
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 11, 2005 at 11:59:21PM -0700, yhlu wrote:
> > andi,
> >
> > is it possible for
> > after the AP1 call_in is done and before AP1 get in tsc_s
* Allow the master to continue.
*/
cpu_set(cpuid, cpu_callin_map);
On 8/11/05, yhlu <[EMAIL PROTECTED]> wrote:
> andi,
>
> is it possible for
> after the AP1 call_in is done and before AP1 get in tsc_sync_wait
> The AP2 call_in done. and then AP1 get
On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
> > Yes, I mean more aggressive
> >
> > static void __init smp_init(void)
> > {
> > unsigned int i;
> >
> >
On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
Yes, I mean more aggressive
static void __init smp_init(void)
{
unsigned int i;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(i
the master to continue.
*/
cpu_set(cpuid, cpu_callin_map);
On 8/11/05, yhlu [EMAIL PROTECTED] wrote:
andi,
is it possible for
after the AP1 call_in is done and before AP1 get in tsc_sync_wait
The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
done, AP2 get
good, I will produce one patch next week.
YH
On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Aug 11, 2005 at 11:59:21PM -0700, yhlu wrote:
andi,
is it possible for
after the AP1 call_in is done and before AP1 get in tsc_sync_wait
The AP2 call_in done. and then AP1 get
So MPTABLE do not have problem with it, only acpi related...?
YH
On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote:
I wrote:
How so? The XAPIC version check should work there.
ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21]
Oh.
On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Fri, Aug 12, 2005 at 09:18:07AM -0700, yhlu wrote:
good, I will produce one patch next week.
I already did it in my tree.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
why matrin need to make apic id to be greater than 0x10 when system is
only 2way?
too much io-apic in system?
YH
On 8/12/05, Andi Kleen [EMAIL PROTECTED] wrote:
On Fri, Aug 12, 2005 at 09:37:11AM -0700, yhlu wrote:
So MPTABLE do not have problem with it, only acpi related...?
It's only
I played a while with atyfb in LinuxBIOS. move the xl_init.c into LinuxBIOS.
there is one patch call xlinit.c that can be used even ati fb is not
inited in BIOS to make kernel still can use atyfb.
I wonder if James put that in mainstream, he already sent one patch
for 2.6.5
please refer to
james,
I remember that xlinit in 2.6 kernel only works when BIOS option-rom
really init fb.
It can not work if the BIOS option rom is not executed.
For 2.4, it reversed, it can not work if BIOS opton-rom is executed.
Only work if BIOS don't excute the option rom.
YH
On 8/12/05, James Simmons
So boot_cpu_id is apic id of BSP.
Anyway sync_tsc(...) there is master and MASTER..., but value are all 0.
YH
On 8/11/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ok being impatient not wanting this tiny bug to be forgotten for
> 2.6.13. Linus please apply this micro patch.
>
> > >
So boot_cpu_id is apic id of BSP.
Anyway sync_tsc(...) there is master and MASTER..., but value are all 0.
YH
On 8/11/05, Eric W. Biederman [EMAIL PROTECTED] wrote:
Ok being impatient not wanting this tiny bug to be forgotten for
2.6.13. Linus please apply this micro patch.
static void
gt; On Wed, Aug 10, 2005 at 05:23:31PM -0700, yhlu wrote:
> > I wonder if you can make the bsp can start the APs callin in the same
> > time, and make it asynchronous, So you make spare 2s or more.
>
> The setting of cpu_callin_map in the AP could be moved earlier yes.
> B
I wonder if you can make the bsp can start the APs callin in the same
time, and make it asynchronous, So you make spare 2s or more.
YH
On 8/10/05, yhlu <[EMAIL PROTECTED]> wrote:
> In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
> 8x to 2.1x for 8 ways system
In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G
will take 20s.
for TSC_SYNC asynchronous maybe you can get back 0.1s...
YH
On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > So my patch still can be
04:14:19PM -0700, Mike Waychison wrote:
> > YhLu wrote:
> > >andi,
> > >
> > >please refer the patch, it will move cpu_set(, cpu_callin_map) from
> > >smi_callin to start_secondary.
> >
> >
> > This patch fixes an apparent race / lockup o
:
YhLu wrote:
andi,
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
This patch fixes an apparent race / lockup on our 2-way dual cores (when
applied against 2.6.12.3). The machine was locking up after
Initializing CPU#2.
The real
In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G
will take 20s.
for TSC_SYNC asynchronous maybe you can get back 0.1s...
YH
On 8/10/05, Andi Kleen [EMAIL PROTECTED] wrote:
So my patch still can be used
I wonder if you can make the bsp can start the APs callin in the same
time, and make it asynchronous, So you make spare 2s or more.
YH
On 8/10/05, yhlu [EMAIL PROTECTED] wrote:
In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
8x to 2.1x for 8 ways system. 1x mean 5s
, 2005 at 05:23:31PM -0700, yhlu wrote:
I wonder if you can make the bsp can start the APs callin in the same
time, and make it asynchronous, So you make spare 2s or more.
The setting of cpu_callin_map in the AP could be moved earlier yes.
But it's not entirely trivial because there are some
<[EMAIL PROTECTED]> wrote:
> On Tue, Aug 09, 2005 at 11:50:53AM -0700, yhlu wrote:
> > anyone is working on add driver for ati xpress 200m?
> >
> > without that My turion notebook, can not work read the battery status.
>
> Normally this should be done in ACPI batter
anyone is working on add driver for ati xpress 200m?
without that My turion notebook, can not work read the battery status.
I guess sbs-cm need that driver in kernel.
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
[EMAIL PROTECTED] wrote:
On Tue, Aug 09, 2005 at 11:50:53AM -0700, yhlu wrote:
anyone is working on add driver for ati xpress 200m?
without that My turion notebook, can not work read the battery status.
Normally this should be done in ACPI battery.c
-Andi
-
To unsubscribe from this list
anyone is working on add driver for ati xpress 200m?
without that My turion notebook, can not work read the battery status.
I guess sbs-cm need that driver in kernel.
YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
In LinuxBIOS internal structure for resource, We have index member in resource.
So the resource will be count from 0, 7 or etc, but index member
will point to real BAR position.
I would like to see Kernel has simmliar definintion.
in LinuxBIOS
typedef uint64_t resource_t;
struct resource {
In LinuxBIOS internal structure for resource, We have index member in resource.
So the resource will be count from 0, 7 or etc, but index member
will point to real BAR position.
I would like to see Kernel has simmliar definintion.
in LinuxBIOS
typedef uint64_t resource_t;
struct resource {
I remember last year when I used IBGOLD 0.5 with PCI-X IB card, it
seems that it could support 64 bit pref mem.
I will try IBGOLD 1.7 .
YH
On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
>yhlu> Roland, what is the -16 mean?
>
>yhlu> is it /* Attempt to
Roland,
what is the -16 mean?
is it
/* Attempt to modify a QP/EE which is not in the presumed state: */
MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10,
YH
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> You are right. CONG_SPECIAL_QP
>
> ib_mthca: Mellanox InfiniBand HCA dri
In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the
mellanox Infiniband card. Some range above 4G. So the mmio below 4G
is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
used, the mmio will be 2G. For new opteron E stepping, We could use
hareware memhole support.
please check the patch for fix overwrite upper 32bit
YH
--- drivers/pci/setup-res.c.orig2005-08-05 10:08:45.0 -0700
+++ drivers/pci/setup-res.c 2005-08-05 13:25:06.0 -0700
@@ -33,6 +33,18 @@
u32 new, check, mask;
int reg;
+if (resno < 6) {
+
ng region "
"%s/%d (high %08x != %08x)\n",
pci_name(dev), resno, new, check);
}
}
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> pci_restore_bars cause that.
> it didn't restore that according to if resource
return;
+ }
+
+ for (i = 0; i < numres; i ++)
+ pci_update_resource(dev, >resource[i], i);
+}
+
+/**
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> before I do the cg-update this morning, it didn't mask out the upper 8 bit.
>
> YH
>
> On 8/5/05, Roland Dreier <[EMAIL
before I do the cg-update this morning, it didn't mask out the upper 8 bit.
YH
On 8/5/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> yhlu> ps. some kernel pci code patch broke sth yesterday night.
> yhlu> it mask out bit [32-39]
>
> Is it possible that all your
On 8/5/05, yhlu <[EMAIL PROTECTED]> wrote:
> You are right. CONG_SPECIAL_QP
>
> ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
> ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex
> (Tavor compatibility mode) (:04:00.0)
> ib_mthca
You are right. CONG_SPECIAL_QP
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex
(Tavor compatibility mode) (:04:00.0)
ib_mthca :04:00.0: FW version 000400060002, max commands 64
ib_mthca :04:00.0: FW
You are right. CONG_SPECIAL_QP
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex
(Tavor compatibility mode) (:04:00.0)
ib_mthca :04:00.0: FW version 000400060002, max commands 64
ib_mthca :04:00.0: FW
On 8/5/05, yhlu [EMAIL PROTECTED] wrote:
You are right. CONG_SPECIAL_QP
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
ib_mthca: Initializing Mellanox Technologies MT25208 InfiniHost III Ex
(Tavor compatibility mode) (:04:00.0)
ib_mthca :04:00.0: FW version
before I do the cg-update this morning, it didn't mask out the upper 8 bit.
YH
On 8/5/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu ps. some kernel pci code patch broke sth yesterday night.
yhlu it mask out bit [32-39]
Is it possible that all your problems are coming from the PCI
;
+ }
+
+ for (i = 0; i numres; i ++)
+ pci_update_resource(dev, dev-resource[i], i);
+}
+
+/**
On 8/5/05, yhlu [EMAIL PROTECTED] wrote:
before I do the cg-update this morning, it didn't mask out the upper 8 bit.
YH
On 8/5/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu ps. some kernel
%s/%d (high %08x != %08x)\n,
pci_name(dev), resno, new, check);
}
}
On 8/5/05, yhlu [EMAIL PROTECTED] wrote:
pci_restore_bars cause that.
it didn't restore that according to if resource is 64 bit or not. So
it overwirte
please check the patch for fix overwrite upper 32bit
YH
--- drivers/pci/setup-res.c.orig2005-08-05 10:08:45.0 -0700
+++ drivers/pci/setup-res.c 2005-08-05 13:25:06.0 -0700
@@ -33,6 +33,18 @@
u32 new, check, mask;
int reg;
+if (resno 6) {
+
In LinuxBIOS, We can allocate 64 bit region ( 0xfc000) to the
mellanox Infiniband card. Some range above 4G. So the mmio below 4G
is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
used, the mmio will be 2G. For new opteron E stepping, We could use
hareware memhole support.
Roland,
what is the -16 mean?
is it
/* Attempt to modify a QP/EE which is not in the presumed state: */
MTHCA_CMD_STAT_BAD_QPEE_STATE = 0x10,
YH
On 8/5/05, yhlu [EMAIL PROTECTED] wrote:
You are right. CONG_SPECIAL_QP
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23
I remember last year when I used IBGOLD 0.5 with PCI-X IB card, it
seems that it could support 64 bit pref mem.
I will try IBGOLD 1.7 .
YH
On 8/5/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu Roland, what is the -16 mean?
yhlu is it /* Attempt to modify a QP/EE which
400 for eqn 3
ib_mthca: probe of :04:00.0 failed with error -16
On 8/4/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> yhlu> i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y I didn't get any
> yhlu> more debug info, is that depend other setting?
>
> It shouldn't dep
Yes.
On 8/3/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting r. yhlu <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes
> >
> > Roland,
> >
> > In LinuxBIOS, If I enable the prefmem64 to use r
i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y
I didn't get any more debug info, is that depend other setting?
YH
On 8/4/05, yhlu <[EMAIL PROTECTED]> wrote:
> The mellanox can use prefmem64, but the BIOS could only allocate the
> some range below 4G, So 32 bit OS still can use
YES.
I will send you the output message later about "CONFIG_INFINIBAND_MTHCA_DEBUG=y"
YH
On 8/3/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> yhlu> In LinuxBIOS, If I enable the prefmem64 to use real 64
> yhlu> range. the IB driver in Kernel can not be lo
back if Opteron don't have hardware memhole
support).
YH
On 8/4/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> >>>>> "yhlu" == yhlu <[EMAIL PROTECTED]> writes:
>
> yhlu> YES. I will send you the output message later about
>
back if Opteron don't have hardware memhole
support).
YH
On 8/4/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu == yhlu [EMAIL PROTECTED] writes:
yhlu YES. I will send you the output message later about
yhlu CONFIG_INFINIBAND_MTHCA_DEBUG=y
Thanks. In the meantime, can you
YES.
I will send you the output message later about CONFIG_INFINIBAND_MTHCA_DEBUG=y
YH
On 8/3/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu In LinuxBIOS, If I enable the prefmem64 to use real 64
yhlu range. the IB driver in Kernel can not be loaded.
What does it mean to enable
i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y
I didn't get any more debug info, is that depend other setting?
YH
On 8/4/05, yhlu [EMAIL PROTECTED] wrote:
The mellanox can use prefmem64, but the BIOS could only allocate the
some range below 4G, So 32 bit OS still can use the IB cards
Yes.
On 8/3/05, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting r. yhlu [EMAIL PROTECTED]:
Subject: Re: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes
Roland,
In LinuxBIOS, If I enable the prefmem64 to use real 64 range. the IB
driver in Kernel can not be loaded
for eqn 3
ib_mthca: probe of :04:00.0 failed with error -16
On 8/4/05, Roland Dreier [EMAIL PROTECTED] wrote:
yhlu i enable CCONFIG_INFINIBAND_MTHCA_DEBUG=y I didn't get any
yhlu more debug info, is that depend other setting?
It shouldn't depend on anything. mthca_dbg() gets turned
1 - 100 of 155 matches
Mail list logo
