Hello Trond,
> > [ 227.620134] [ cut here ]
> > [ 227.620152] WARNING: CPU: 0 PID: 197 at fs/proc/generic.c:510
> > remove_proc_entry+0xde/0x159()
> > [ 227.620163] name 'fs/nfsfs'
> > [ 227.620170] Modules linked in: ip6table_filter ip6_tables iptable_filter
> >
Hello Trond,
[ 227.620134] [ cut here ]
[ 227.620152] WARNING: CPU: 0 PID: 197 at fs/proc/generic.c:510
remove_proc_entry+0xde/0x159()
[ 227.620163] name 'fs/nfsfs'
[ 227.620170] Modules linked in: ip6table_filter ip6_tables iptable_filter
ip_tables
Hello everyone,
after I compiled a new kernel 2 days ago and also with current Linus tip
I get:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.17.0-rc1+ (sithglan@mini)
Hello everyone,
after I compiled a new kernel 2 days ago and also with current Linus tip
I get:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.17.0-rc1+ (sithglan@mini)
atory.ro: $(PURGATORY_OBJS) FORCE
> $(call if_changed,ld)
> Can you please try attached single line patch and see if it fixes the
> issue for you.
I tested the same and it works.
Tested-by: Thomas Glanzmann
...
CC arch/x86/purgatory/purgatory.o
AS arch/x86/purgatory/stack.o
Hello Vivek,
* Vivek Goyal [2014-08-20 15:53]:
> A patch is sitting in akpm's tree. That patch puts the new code under
> a new config option CONFIG_KEXEC_FILE. So as long as you don't enable
> CONFIG_KEXEC_FILE=y, you should be fine. This should not impact any of
> the existing functionality.
Hello Vivek,
commit 8fc5b4d introduces a regression that no longer allows to compile
x86_64 kernel under x86_32 userland. TJ on freenode/#kernel did analyze
it:
> (mini) [~/work/linux-2.6] make
> scripts/kconfig/conf --silentoldconfig Kconfig
> CHK include/config/kernel.release
> UPD
Hello,
I used to compile 64 Bit Kernel on 32 Bit Userland and until v3.16 it
worked. But with todays git head from Linus it does not:
(mini) [~/work/linux-2.6] make
Hello,
I used to compile 64 Bit Kernel on 32 Bit Userland and until v3.16 it
worked. But with todays git head from Linus it does not:
(mini) [~/work/linux-2.6] make
Hello Vivek,
commit 8fc5b4d introduces a regression that no longer allows to compile
x86_64 kernel under x86_32 userland. TJ on freenode/#kernel did analyze
it:
(mini) [~/work/linux-2.6] make
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config/kernel.release
UPD
Hello Vivek,
* Vivek Goyal vgo...@redhat.com [2014-08-20 15:53]:
A patch is sitting in akpm's tree. That patch puts the new code under
a new config option CONFIG_KEXEC_FILE. So as long as you don't enable
CONFIG_KEXEC_FILE=y, you should be fine. This should not impact any of
the existing
$(call if_changed,ld)
Can you please try attached single line patch and see if it fixes the
issue for you.
I tested the same and it works.
Tested-by: Thomas Glanzmann tho...@glanzmann.de
...
CC arch/x86/purgatory/purgatory.o
AS arch/x86/purgatory/stack.o
AS arch/x86
Hello Ben,
> > 8777c5c11764d8336d8270f96778158c34c92108 (which is mentioned as the
> > first bad commit above...) is a tiny commit, so I have no idea what
> > you mean by "too large for your taste".
for example I would not export a symbol and do something else in the
same commit, but would split
Hello Ben,
> Are you able to double-check that bisect? I'm not at all sure how
> that particular commit could trigger the issue you're seeing. Some of
> the others, certainly. It might be worth trying a couple of times
> before marking something as "good", in case there's a timing aspect to
>
Hello Ben,
Are you able to double-check that bisect? I'm not at all sure how
that particular commit could trigger the issue you're seeing. Some of
the others, certainly. It might be worth trying a couple of times
before marking something as good, in case there's a timing aspect to
the
Hello Ben,
8777c5c11764d8336d8270f96778158c34c92108 (which is mentioned as the
first bad commit above...) is a tiny commit, so I have no idea what
you mean by too large for your taste.
for example I would not export a symbol and do something else in the
same commit, but would split them up
Hello Ben,
commit
(mini) [~/work/linux-2.6] git bisect bad
8777c5c11764d8336d8270f96778158c34c92108 is the first bad commit
commit 8777c5c11764d8336d8270f96778158c34c92108
Author: Ben Skeggs
Date: Fri Jun 6 18:09:55 2014 +1000
drm/nouveau/dp: probe dpcd to determine connectedness
Hello Ben,
commit
(mini) [~/work/linux-2.6] git bisect bad
8777c5c11764d8336d8270f96778158c34c92108 is the first bad commit
commit 8777c5c11764d8336d8270f96778158c34c92108
Author: Ben Skeggs bske...@redhat.com
Date: Fri Jun 6 18:09:55 2014 +1000
drm/nouveau/dp: probe dpcd to determine
Hallo Jani,
> Hi Thomas, please bisect, it's likely the quickest way to root cause
> this. (Google for "git bisect kernel" for a bunch of guides on the
> topic
> if you're not familiar with bisect.)
I switched my location and no longer have an external monitor with
display port available, if I
Hallo Jani,
Hi Thomas, please bisect, it's likely the quickest way to root cause
this. (Google for git bisect kernel for a bunch of guides on the
topic
if you're not familiar with bisect.)
I switched my location and no longer have an external monitor with
display port available, if I do,
bisect bad 457e77b26428ab4a24998eecfb99f27fa4195397
Than I saw your posting on LKML and tried your fix and your fix resolves
my problem on top of Linus tip.
Tested-by: Thomas Glanzmann
Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
bisect bad 457e77b26428ab4a24998eecfb99f27fa4195397
Than I saw your posting on LKML and tried your fix and your fix resolves
my problem on top of Linus tip.
Tested-by: Thomas Glanzmann tho...@glanzmann.de
Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux
Hello Eric,
> I'll do it tomorrow : Today is President's Day in the US, and I am
> spending the day with my family.
thank you. Enjoy your day.
Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Hello Eric,
> Unfortunately you did not had good results with the MSG_MORE applied
> to the page fragments.
I agree. We should submit only the submit the patch from this message:
Message-ID: <1391886759.10160.114.ca...@edumazet-glaptop2.roam.corp.google.com>
Hello Eric,
may submit your latest patch for upstream? Or do you plan on doing that
yourself?
Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hello Eric,
may submit your latest patch for upstream? Or do you plan on doing that
yourself?
Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hello Eric,
Unfortunately you did not had good results with the MSG_MORE applied
to the page fragments.
I agree. We should submit only the submit the patch from this message:
Message-ID: 1391886759.10160.114.ca...@edumazet-glaptop2.roam.corp.google.com
Hello Eric,
I'll do it tomorrow : Today is President's Day in the US, and I am
spending the day with my family.
thank you. Enjoy your day.
Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
Hello Eric,
> Hmm.. I was not aware of high RTT for some packets.
> Can you spot this on the pcap you provided ?
with the latest patch as in:
(node-62) [~/work/linux-2.6] git diff | pbot
http://pbot.rmdir.de/CQwqI6b7wJProw_xaukmEg
with net.ipv4.tcp_min_tso_segs=2 we had this pcap:
Hello Eric,
> Also please make sure you have this patch :
> http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=4a5ab4e224288403b0b4b6b8c4d339323150c312
I did not have this patch. I apply it, rerun and send you the pcap.
(node-62) [~/work/linux-2.6] wcat
Hello Nab,
> This looks correct to me. Thomas, once your able to confirm please
> include your 'Tested-by' and I'll include for the next -rc3 PULL
> request.
Eric is currently reviewing our latest iteration with MSG_MORE for
kernel_sendmsg and MSG_MORE | MSG_SENDPAGE_NOTLAST for sendpage.
Hello Nab,
This looks correct to me. Thomas, once your able to confirm please
include your 'Tested-by' and I'll include for the next -rc3 PULL
request.
Eric is currently reviewing our latest iteration with MSG_MORE for
kernel_sendmsg and MSG_MORE | MSG_SENDPAGE_NOTLAST for sendpage. However
Hello Eric,
Also please make sure you have this patch :
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=4a5ab4e224288403b0b4b6b8c4d339323150c312
I did not have this patch. I apply it, rerun and send you the pcap.
(node-62) [~/work/linux-2.6] wcat
Hello Eric,
Hmm.. I was not aware of high RTT for some packets.
Can you spot this on the pcap you provided ?
with the latest patch as in:
(node-62) [~/work/linux-2.6] git diff | pbot
http://pbot.rmdir.de/CQwqI6b7wJProw_xaukmEg
with net.ipv4.tcp_min_tso_segs=2 we had this pcap:
Hello Eric,
> 1) Use your own identity as the sender, not impersonate me.
> ( thats standard convention )
sorry about that, will not happen ever again.
> 2) Put following line as first line of the mail
> ( Documentation/SubmittingPatches lines ~565)
> From: Eric Dumazet
> Then I'll add my :
Hello Eric,
1) Use your own identity as the sender, not impersonate me.
( thats standard convention )
sorry about that, will not happen ever again.
2) Put following line as first line of the mail
( Documentation/SubmittingPatches lines ~565)
From: Eric Dumazet eduma...@google.com
Then
Hello Eric,
> Yes, this is much better : 2 frames per request/response, instead of 4.
perfect. I send out the page to the iscsi target list in your name since
you did the work and I added me as signed off I hope that is how it is
handled or should I have added my name to the from line and
Hello Eric,
I took the liberty to test and make your patch compile by adding the
following changeset:
--- a/drivers/target/iscsi/iscsi_target_parameters.c
+++ b/drivers/target/iscsi/iscsi_target_parameters.c
@@ -79,7 +79,7 @@ int iscsi_login_tx_data(
*/
conn->if_marker += length;
Hello Eric,
> I was simply thinking about something like :
> (might need further changes, but I guess this should solve your case)
thank you for your patch. It did not apply on top of Linux tip, so I put
in the changes manually and fixed up another call to tx_data that your
forgot in your
Hello Eric,
> Sure, but if we put this flag to zero, nobody will ever use it and
> find any bug.
I agree.
> If we can add the MSG_MORE at the right place, your workload might gain
> ~20% exec time, and maybe 30% better efficiency, since you'll divide by
> 2 the total number of network segments.
Hello Eric,
> Yep, but the problem (at least on your pcap), is about sending the 48
> bytes headers in TCP segment of its own, then the 512 byte payload in
> a separate segment.
I agree.
> I suspect the sendpage() is only used for the payload. No need for
> MSG_MORE here.
I see.
> The
Hello Eric,
> Note : We did some patches in the MSG_MORE logic for sendpage(), but
> in your case I do not think its related
> (git grep -n MSG_SENDPAGE_NOTLAST ) if you are curious
thank you for the pointer. The iSCSI target code actually uses sendpage
whenever it can.
Cheers,
Thomas
Hello Eric,
> > Disable auto corking by default
> We should let auto corking on during 3.14 development cycle so that we
> can fix the bugs, and thing of some optimizations.
I agree that leaving it enabled helps to find bugs, however I'm not
happy with the round trip time degradation.
> auto
Hello Eric,
> Idea would be to set this flag when calling sendmsg() of the 48 bytes
> of the header, and not set it on the sendmsg() of the 512 bytes of the
> payload.
I see.
> iscsi_sw_tcp_xmit_segment() already adds MSG_MORE, but
> it would be nice to add a new _initial_ flags parameter to
>
Hello Eric,
> > BTW this problem demonstrates there is room for improvement in iCSCI,
> > using MSG_MORE to avoid sending two small segments in separate frames.
> With the fix, new pcap is more explicit about this suboptimal behavior :
> 05:34:16.280900 IP 10.101.0.13.41531 > 10.101.99.5.3260:
Hello Eric,
[RESEND: dropped CC accidently]
> 10.101.99.5 or 10.101.0.13?
10.101.99.5 (iSCSI Target)
tcpdump -i bond0.101 -s 0 -w /tmp/tcp_auto_corking_on_patched.pcap host
esx-03.v101.campusvl.de
Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe
Hello Eric,
> What is your NIC model and driver?
I have four Intel Corporation I350 Gigabit Network Connection (rev 01).
(node-62) [~/work/linux-2.6] lspci -v | pbot
http://pbot.rmdir.de/rgu6yHMBDVQpflMmbcJACg
(node-62) [~/work/linux-2.6] ip a s | pbot
Hello Eric,
> Also make sure you have commit a181ceb501b31b4bf8812a5c84c716cc31d82c2d
> ("tcp: autocork should not hold first packet in write queue")
> in your tree.
confirmed:
(node-62) [~/work/linux-2.6] git show a181ceb501b31b4bf8812a5c84c716cc31d82c2d
| head
commit
Hello Eric,
> > tcp corking kills iSCSI performance
> Here is the combined patch, could you test it?
the patch did not apply, so I edited by hand. Here is the resulting
patch:
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 03d26b8..40d1958 100644
--- a/net/ipv4/tcp_output.c
Hello Eric,
[RESEND: the time it took the VMFS was created was switched between
on/off so with on it took over 2 minutes with off it took less than 4
seconds]
[RESEND 2: The throughput graphs were switched as well ;-(]
> * Thomas Glanzmann [2014-02-07 08:55]:
> > Creating a
Hello Eric,
[RESEND: the time it took the VMFS was created was switched between
on/off so with on it took over 2 minutes with off it took less than 4
seconds]
> * Thomas Glanzmann [2014-02-07 08:55]:
> > Creating a 4 TB VMFS filesystem over iSCSI takes 24 seconds on 3.12
> >
When using auto corking with iSCSI the round trip time at least increases by
factor 25 probably more. Other protocols are very likely also effected.
Signed-off-by: Thomas Glanzmann
---
net/ipv4/tcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net
Hello Eric,
> * Thomas Glanzmann [2014-02-07 08:55]:
> > Creating a 4 TB VMFS filesystem over iSCSI takes 24 seconds on 3.12
> > and 15 minutes on 3.14.0-rc2+.
* Nicholas A. Bellinger [2014-02-07 20:30]:
> Would it be possible to try a couple of different stable kernel
> v
Hello Eric,
* Thomas Glanzmann tho...@glanzmann.de [2014-02-07 08:55]:
Creating a 4 TB VMFS filesystem over iSCSI takes 24 seconds on 3.12
and 15 minutes on 3.14.0-rc2+.
* Nicholas A. Bellinger n...@linux-iscsi.org [2014-02-07 20:30]:
Would it be possible to try a couple of different
When using auto corking with iSCSI the round trip time at least increases by
factor 25 probably more. Other protocols are very likely also effected.
Signed-off-by: Thomas Glanzmann tho...@glanzmann.de
---
net/ipv4/tcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net
Hello Eric,
[RESEND: the time it took the VMFS was created was switched between
on/off so with on it took over 2 minutes with off it took less than 4
seconds]
* Thomas Glanzmann tho...@glanzmann.de [2014-02-07 08:55]:
Creating a 4 TB VMFS filesystem over iSCSI takes 24 seconds on 3.12
Hello Eric,
[RESEND: the time it took the VMFS was created was switched between
on/off so with on it took over 2 minutes with off it took less than 4
seconds]
[RESEND 2: The throughput graphs were switched as well ;-(]
* Thomas Glanzmann tho...@glanzmann.de [2014-02-07 08:55]:
Creating a 4
Hello Eric,
tcp corking kills iSCSI performance
Here is the combined patch, could you test it?
the patch did not apply, so I edited by hand. Here is the resulting
patch:
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 03d26b8..40d1958 100644
--- a/net/ipv4/tcp_output.c
+++
Hello Eric,
Also make sure you have commit a181ceb501b31b4bf8812a5c84c716cc31d82c2d
(tcp: autocork should not hold first packet in write queue)
in your tree.
confirmed:
(node-62) [~/work/linux-2.6] git show a181ceb501b31b4bf8812a5c84c716cc31d82c2d
| head
commit
Hello Eric,
What is your NIC model and driver?
I have four Intel Corporation I350 Gigabit Network Connection (rev 01).
(node-62) [~/work/linux-2.6] lspci -v | pbot
http://pbot.rmdir.de/rgu6yHMBDVQpflMmbcJACg
(node-62) [~/work/linux-2.6] ip a s | pbot
http://pbot.rmdir.de/xJjRT8u-ekC6mrWgl09ZtQ
Hello Eric,
[RESEND: dropped CC accidently]
10.101.99.5 or 10.101.0.13?
10.101.99.5 (iSCSI Target)
tcpdump -i bond0.101 -s 0 -w /tmp/tcp_auto_corking_on_patched.pcap host
esx-03.v101.campusvl.de
Cheers,
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Hello Eric,
BTW this problem demonstrates there is room for improvement in iCSCI,
using MSG_MORE to avoid sending two small segments in separate frames.
With the fix, new pcap is more explicit about this suboptimal behavior :
05:34:16.280900 IP 10.101.0.13.41531 10.101.99.5.3260: Flags
Hello Eric,
Idea would be to set this flag when calling sendmsg() of the 48 bytes
of the header, and not set it on the sendmsg() of the 512 bytes of the
payload.
I see.
iscsi_sw_tcp_xmit_segment() already adds MSG_MORE, but
it would be nice to add a new _initial_ flags parameter to
Hello Eric,
Disable auto corking by default
We should let auto corking on during 3.14 development cycle so that we
can fix the bugs, and thing of some optimizations.
I agree that leaving it enabled helps to find bugs, however I'm not
happy with the round trip time degradation.
auto cork
Hello Eric,
Note : We did some patches in the MSG_MORE logic for sendpage(), but
in your case I do not think its related
(git grep -n MSG_SENDPAGE_NOTLAST ) if you are curious
thank you for the pointer. The iSCSI target code actually uses sendpage
whenever it can.
Cheers,
Thomas
--
Hello Eric,
Yep, but the problem (at least on your pcap), is about sending the 48
bytes headers in TCP segment of its own, then the 512 byte payload in
a separate segment.
I agree.
I suspect the sendpage() is only used for the payload. No need for
MSG_MORE here.
I see.
The MSG_MORE
Hello Eric,
Sure, but if we put this flag to zero, nobody will ever use it and
find any bug.
I agree.
If we can add the MSG_MORE at the right place, your workload might gain
~20% exec time, and maybe 30% better efficiency, since you'll divide by
2 the total number of network segments.
Hello Eric,
I was simply thinking about something like :
(might need further changes, but I guess this should solve your case)
thank you for your patch. It did not apply on top of Linux tip, so I put
in the changes manually and fixed up another call to tx_data that your
forgot in your initial
Hello Eric,
I took the liberty to test and make your patch compile by adding the
following changeset:
--- a/drivers/target/iscsi/iscsi_target_parameters.c
+++ b/drivers/target/iscsi/iscsi_target_parameters.c
@@ -79,7 +79,7 @@ int iscsi_login_tx_data(
*/
conn-if_marker += length;
Hello Eric,
Yes, this is much better : 2 frames per request/response, instead of 4.
perfect. I send out the page to the iscsi target list in your name since
you did the work and I added me as signed off I hope that is how it is
handled or should I have added my name to the from line and
Hello Jesse,
> Do you know what type of devices are being attached to OVS (i.e. tap,
> veth, etc.)?
my e-mail has a link to the debug log which contains that Information.
But from my understanding there are several tap devices: one per host,
4-5 per switch. Tap because it needs layer 2.
There
Hello Jesse,
Do you know what type of devices are being attached to OVS (i.e. tap,
veth, etc.)?
my e-mail has a link to the debug log which contains that Information.
But from my understanding there are several tap devices: one per host,
4-5 per switch. Tap because it needs layer 2.
There are
Hello Jesse,
> This looks like the kernel module included with upstream Linux instead
> of from OVS git, is that correct?
coorect.
> Can you please describe what you are doing instead of just giving your script?
I created 8 hosts. 2 hosts are connected two each switches. That gives
me 4
Hello,
open vswitch git head with Linus tip OOPses for me reproducable when I
load the following mininet topology:
(lenovo) [~/work/linux-2.6] git log | head -1
commit 9b0cd304f26b9fca140de15deeac2bf357d1f388
(lenovo) [~/work/openvswitch] git log | head -1
commit
Hello,
open vswitch git head with Linus tip OOPses for me reproducable when I
load the following mininet topology:
(lenovo) [~/work/linux-2.6] git log | head -1
commit 9b0cd304f26b9fca140de15deeac2bf357d1f388
(lenovo) [~/work/openvswitch] git log | head -1
commit
Hello Jesse,
This looks like the kernel module included with upstream Linux instead
of from OVS git, is that correct?
coorect.
Can you please describe what you are doing instead of just giving your script?
I created 8 hosts. 2 hosts are connected two each switches. That gives
me 4 switches
Hello Ilia,
> > CC [M] drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.o
> > drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c:478:8: error: redefinition
> > of 'struct nvaa_clock_priv'
> Something very funny happened. Are you sure you applied the patch
> correctly? The file should only be 445
Hello Ilia,
> > [7.569394] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac080b1
> > [7.569460] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC)
> > [7.569530] nouveau [ DEVICE][:02:00.0] Family : NV50
> > [7.571151] nouveau [ VBIOS][:02:00.0] checking
Hello Ilia,
[7.569394] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac080b1
[7.569460] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC)
[7.569530] nouveau [ DEVICE][:02:00.0] Family : NV50
[7.571151] nouveau [ VBIOS][:02:00.0] checking PRAMIN for
Hello Ilia,
CC [M] drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.o
drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c:478:8: error: redefinition
of 'struct nvaa_clock_priv'
Something very funny happened. Are you sure you applied the patch
correctly? The file should only be 445 lines
Hello everyone,
the current git HEAD of Linus Torvalds tree breaks Nouveau on my Mac Mini
Model 2010. I get variation of the following kernel panic when booting.
(gateway) [~] nc -u -l -p
[3.796018] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[3.796100] ata2: SATA link up
Hello everyone,
the current git HEAD of Linus Torvalds tree breaks Nouveau on my Mac Mini
Model 2010. I get variation of the following kernel panic when booting.
(gateway) [~] nc -u -l -p
[3.796018] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[3.796100] ata2: SATA link up
Hallo,
> Is there some way you can feed that into Debian please? Why the go
> around through a separate repository? The maintainer of git-core is
> not actively maintaining the package?
it already is. But Debian Etch is stable which means there will no newer
version of git in Debian Etch.
Hallo,
Is there some way you can feed that into Debian please? Why the go
around through a separate repository? The maintainer of git-core is
not actively maintaining the package?
it already is. But Debian Etch is stable which means there will no newer
version of git in Debian Etch. Currently
Hello,
> after having a peek at git-core_1.5.2.1-1.dsc, and then it did build
> just fine immediately.
good point, that makes sense. I have to keep that in mind. Last time I
looked at the failed tests, saw the missing dependency and tried again.
:-)
Thomas
-
To unsubscribe from this
Hello,
* Thomas Glanzmann <[EMAIL PROTECTED]> [070618 23:56]:
> > It seems that this is only for etch (and sarge). I run a mixed
> > Lenny/sid machine here. It doesn't necessarily work when I start to
> > install things for etch. Certainly not once testing upgrades its l
Hello,
> It seems that this is only for etch (and sarge). I run a mixed
> Lenny/sid machine here. It doesn't necessarily work when I start to
> install things for etch. Certainly not once testing upgrades its libc.
> Or?
true. But when you run sid you get a newer version of git automatically.
Hello,
a friend of mine always builds the Debian Packages from unstable for
Debian Etch. I have on all my machines the following line in
/etc/apt/sources.list:
deb http://rmdir.de/~michael/git/ ./
apt-get update; apt-get dist-upgrade
and you're up2speed.
If you don't trust that
Hello Pierre,
> FWIW there is even simpler: I maintain a backport on
> www.backports.org. Which is a semi-official service driven by Debian
> Developers.
good to know, maybe I am going to use backports in the future.
Thomas
-
To unsubscribe from this list: send the line "unsubscribe
Hello Pierre,
FWIW there is even simpler: I maintain a backport on
www.backports.org. Which is a semi-official service driven by Debian
Developers.
good to know, maybe I am going to use backports in the future.
Thomas
-
To unsubscribe from this list: send the line unsubscribe
Hello,
a friend of mine always builds the Debian Packages from unstable for
Debian Etch. I have on all my machines the following line in
/etc/apt/sources.list:
deb http://rmdir.de/~michael/git/ ./
apt-get update; apt-get dist-upgrade
and you're up2speed.
If you don't trust that
Hello,
It seems that this is only for etch (and sarge). I run a mixed
Lenny/sid machine here. It doesn't necessarily work when I start to
install things for etch. Certainly not once testing upgrades its libc.
Or?
true. But when you run sid you get a newer version of git automatically.
Hello,
* Thomas Glanzmann [EMAIL PROTECTED] [070618 23:56]:
It seems that this is only for etch (and sarge). I run a mixed
Lenny/sid machine here. It doesn't necessarily work when I start to
install things for etch. Certainly not once testing upgrades its libc.
Or?
true.
I guess
Hello,
after having a peek at git-core_1.5.2.1-1.dsc, and then it did build
just fine immediately.
good point, that makes sense. I have to keep that in mind. Last time I
looked at the failed tests, saw the missing dependency and tried again.
:-)
Thomas
-
To unsubscribe from this list:
Hello,
> MCE 0
> HARDWARE ERROR. This is *NOT* a software problem!
> Please contact your hardware vendor
> CPU 0 4 northbridge TSC edc587de6e99
> ADDR 1001a
> Northbridge GART error
>bit61 = error uncorrected
> TLB
Hello,
I have two Dual Opteron Machines where I get two MCE errors on. The
first one is:
MCE 0
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 4 northbridge TSC edc587de6e99
ADDR 1001a
Northbridge
Hello,
I have two Dual Opteron Machines where I get two MCE errors on. The
first one is:
MCE 0
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 4 northbridge TSC edc587de6e99
ADDR 1001a
Northbridge
Hello,
MCE 0
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 4 northbridge TSC edc587de6e99
ADDR 1001a
Northbridge GART error
bit61 = error uncorrected
TLB error
Hello Stephen,
> yesterday I pulled from Linus tree because I saw the sky2 updated and I
> tried to break it but it seems that my problems are gone. I let you know
> if anything pops up in the future.
bad news. I today tried the sky2 driver which is in Linus Kernel Tree
(HEAD) on a machine with
Hello Stephen,
yesterday I pulled from Linus tree because I saw the sky2 updated and I
tried to break it but it seems that my problems are gone. I let you know
if anything pops up in the future.
bad news. I today tried the sky2 driver which is in Linus Kernel Tree
(HEAD) on a machine with
1 - 100 of 130 matches
Mail list logo
