) then I'm able to close GIMP without any problems but it
seems to get stuck in exactly the same way as it happened the first time.
My system kernel: Linux manuelspc 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7
08:44:05 CET 2015 x86_64 GNU/Linux
On 02/20/2015 06:13 PM, Manuel Reimer wrote:
Hello,
Hello,
today, I had the following problem:
I was editing a few photos in GIMP and after I finished with that, I
tried to close GIMP which failed. KDE offered me to terminate the
application which also didn't work.
So I opened a terminal and tried "killall -9 gimp" --> No success
Next I
Hello,
today, I had the following problem:
I was editing a few photos in GIMP and after I finished with that, I
tried to close GIMP which failed. KDE offered me to terminate the
application which also didn't work.
So I opened a terminal and tried killall -9 gimp -- No success
Next I tried
able to close GIMP without any problems but it
seems to get stuck in exactly the same way as it happened the first time.
My system kernel: Linux manuelspc 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7
08:44:05 CET 2015 x86_64 GNU/Linux
On 02/20/2015 06:13 PM, Manuel Reimer wrote:
Hello,
today, I
On 07/07/2014 09:42 PM, Guenter Roeck wrote:
I tracked the problem down to the following patch:
diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts
b/arch/arm/boot/dts/imx23-olinuxino.dts
index d107c4a..993da2e 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++
On 07/07/2014 09:14 PM, Guenter Roeck wrote:
Are you sure this did not just happen when you booted the new kernel
for the first time ? I have seen similar behavior with some distributions.
I did some more tries and found out that I had disabled some of my
patches until I reached 3.15.4
Hello,
maybe someone can help me to find the reason for this problem:
If I run my iMX233 development board with an 3.15.3 kernel, then the
performance is much better as with an 3.15.4 kernel.
I have the first significant "hanging" here:
[7.91] sd 0:0:0:0: [sda] Attached SCSI
Hello,
maybe someone can help me to find the reason for this problem:
If I run my iMX233 development board with an 3.15.3 kernel, then the
performance is much better as with an 3.15.4 kernel.
I have the first significant hanging here:
[7.91] sd 0:0:0:0: [sda] Attached SCSI removable
On 07/07/2014 09:14 PM, Guenter Roeck wrote:
Are you sure this did not just happen when you booted the new kernel
for the first time ? I have seen similar behavior with some distributions.
I did some more tries and found out that I had disabled some of my
patches until I reached 3.15.4
On 07/07/2014 09:42 PM, Guenter Roeck wrote:
I tracked the problem down to the following patch:
diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts
b/arch/arm/boot/dts/imx23-olinuxino.dts
index d107c4a..993da2e 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++
Jan Engelhardt wrote:
Ugh, 250 W was a safe^[0] minimum even back in '98 when harddisks were
like 4.3GB and a dual-speed CD-RW drive was like $400 and up. You
seriously need to replace that.
[0] e.g. suited for 2 CD drives and 2 harddisks, 2 PCI and 1 AGP
I replaced with an 400 Watt one for
Alan Cox wrote:
Yes, or dodgy connectors or other problems. The CRC itself is computed by
the hardware each end so a BadCRC error really means the two ends
disagree about the data.
I'll have a closer look at the connectors, but as I replaced the whole
cable for the fourth time, today, I
Ray Lee wrote:
Oy. Just know that without CC:ing people, I'm having to add Jeff back
in by hand, and we may not notice your messages. Please, with whatever
you're using to send email, CC: people that you want to read your
messages, okay? LKML gets a lot of messages, and it's easy to miss
some.
Ray Lee wrote:
Oy. Just know that without CC:ing people, I'm having to add Jeff back
in by hand, and we may not notice your messages. Please, with whatever
you're using to send email, CC: people that you want to read your
messages, okay? LKML gets a lot of messages, and it's easy to miss
some.
Ray Lee wrote:
Oy. Just know that without CC:ing people, I'm having to add Jeff back
in by hand, and we may not notice your messages. Please, with whatever
you're using to send email, CC: people that you want to read your
messages, okay? LKML gets a lot of messages, and it's easy to miss
some.
Ray Lee wrote:
Oy. Just know that without CC:ing people, I'm having to add Jeff back
in by hand, and we may not notice your messages. Please, with whatever
you're using to send email, CC: people that you want to read your
messages, okay? LKML gets a lot of messages, and it's easy to miss
some.
Alan Cox wrote:
Yes, or dodgy connectors or other problems. The CRC itself is computed by
the hardware each end so a BadCRC error really means the two ends
disagree about the data.
I'll have a closer look at the connectors, but as I replaced the whole
cable for the fourth time, today, I
Jan Engelhardt wrote:
Ugh, 250 W was a safe^[0] minimum even back in '98 when harddisks were
like 4.3GB and a dual-speed CD-RW drive was like $400 and up. You
seriously need to replace that.
[0] e.g. suited for 2 CD drives and 2 harddisks, 2 PCI and 1 AGP
I replaced with an 400 Watt one for
Ray Lee wrote:
(Please always do a reply-to-all for this email list.)
Currently I don't have a SMTP server configured. As soon as my system is
trustworthy, again, I'll do that.
Bad or almost bad power supplies can cause lots of unhappy problems
such as these. If you have another power
Jeff Garzik wrote:
If your IDE interface is complaining about BadCRC errors, then it's
complaining about hardware problems (bad cable, etc.)
The cable already has been replaced three times. I even got sure to
*not* bend the cable. This all doesn't help.
May a bad cable really cause
Hello,
anything started with a try to burn Slackware 12.0 from the original DVD
to an new medium with different boot settings. I always got corrupted
results and didn't know why.
So I started with an "md5sum -c CHECKSUMS.md5" directly on the original
media. This resulted in "anything OK".
Hello,
anything started with a try to burn Slackware 12.0 from the original DVD
to an new medium with different boot settings. I always got corrupted
results and didn't know why.
So I started with an md5sum -c CHECKSUMS.md5 directly on the original
media. This resulted in anything OK.
Now
Jeff Garzik wrote:
If your IDE interface is complaining about BadCRC errors, then it's
complaining about hardware problems (bad cable, etc.)
The cable already has been replaced three times. I even got sure to
*not* bend the cable. This all doesn't help.
May a bad cable really cause
Ray Lee wrote:
(Please always do a reply-to-all for this email list.)
Currently I don't have a SMTP server configured. As soon as my system is
trustworthy, again, I'll do that.
Bad or almost bad power supplies can cause lots of unhappy problems
such as these. If you have another power
Hello,
Shame on me, but I didn't look carefully at the patch. The patch, of
course, tries to get rid of root privileges and doesn't try to get them.
As I also posted to the wrong list, by accident, lets assume this topic
as closed.
Yours
Manuel Reimer
--
To unsubscribe from this list
Hi,
I found this one today:
http://securitytracker.com/alerts/2007/Oct/1018782.html
In the git changelog:
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commit;h=ebbeb2c7ac1b00b608390595783
7a271e80b187e
noone leaves any word about privilege escalation.
Is it really
Hi,
I found this one today:
http://securitytracker.com/alerts/2007/Oct/1018782.html
In the git changelog:
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commit;h=ebbeb2c7ac1b00b608390595783
7a271e80b187e
noone leaves any word about privilege escalation.
Is it really
Kay Sievers wrote:
ATTRS{idVendor}=="0dda", ATTRS{idProduct}=="2005", SUBSYSTEM=="scsi",
ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
It's fine. $id, like some other values too, is a value of the device
where all keys successful matched while walking up the chain of
devices.
But the
Kay Sievers wrote:
ATTRS{idVendor}==0dda, ATTRS{idProduct}==2005, SUBSYSTEM==scsi,
ACTION==add, PROGRAM+=/usr/bin/test.sh %b %p
It's fine. $id, like some other values too, is a value of the device
where all keys successful matched while walking up the chain of
devices.
But the SUBSYSTEM
Andreas Schwab wrote:
Manuel Reimer <[EMAIL PROTECTED]> writes:
For me, this looks like a bug, or am I wrong?
It's a feature. It's documented.
man udev says:
| The name of the device matched while searching the devpath upwards
| for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS.
What e
Andreas Schwab wrote:
As I would prefer to use the USB device information (idVendor, idProduct)
to detect the device, I also tried this one:
ATTRS{idVendor}=="0dda", ATTRS{idProduct}=="2005", SUBSYSTEM=="scsi",
ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
Now this version returns the USB
Hello,
I'm trying to write a UDEV rule, which has to hand over the SCSI device
ID in the format $HOST:$CHANNEL:$ID:$LUN to a shellscript.
My first try was:
ATTR{vendor}=="", ATTR{model}=="", SUBSYSTEM=="scsi",
ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
This returns the SCSI
Manuel Reimer wrote:
Today I'll visit someone, who has a Windows PC. I've already removed the
bt878 card from my PC. I'll try at his PC, if I get the same problem
with the original driver and TV watching software. If this works, I'll
boot Knoppix from his PC to get sure, that I also get
Manuel Reimer wrote:
Today I'll visit someone, who has a Windows PC. I've already removed the
bt878 card from my PC. I'll try at his PC, if I get the same problem
with the original driver and TV watching software. If this works, I'll
boot Knoppix from his PC to get sure, that I also get
Hello,
I'm trying to write a UDEV rule, which has to hand over the SCSI device
ID in the format $HOST:$CHANNEL:$ID:$LUN to a shellscript.
My first try was:
ATTR{vendor}==, ATTR{model}==, SUBSYSTEM==scsi,
ACTION==add, PROGRAM+=/usr/bin/test.sh %b %p
This returns the SCSI device ID
Andreas Schwab wrote:
As I would prefer to use the USB device information (idVendor, idProduct)
to detect the device, I also tried this one:
ATTRS{idVendor}==0dda, ATTRS{idProduct}==2005, SUBSYSTEM==scsi,
ACTION==add, PROGRAM+=/usr/bin/test.sh %b %p
Now this version returns the USB device ID
Andreas Schwab wrote:
Manuel Reimer [EMAIL PROTECTED] writes:
For me, this looks like a bug, or am I wrong?
It's a feature. It's documented.
man udev says:
| The name of the device matched while searching the devpath upwards
| for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS.
What exactly does
Hello,
I want to view teletext using my bt878 card.
I tried with mtt, but I always had missing lines in the teletext
display. As I have been unsure, which is the reason, I also downloaded
and compiled alevt. Here, the same lines are missing.
Now I used the test tools from the zvbi library,
Hello,
I want to view teletext using my bt878 card.
I tried with mtt, but I always had missing lines in the teletext
display. As I have been unsure, which is the reason, I also downloaded
and compiled alevt. Here, the same lines are missing.
Now I used the test tools from the zvbi library,
Mauro Carvalho Chehab wrote:
If your board have an unique PCI ID, we may add it to the driver,
avoiding this need. For this, we will need the results of the following
command:
lspci -vv -nn
I'm using card=65 to use my card. I never tried the tuner (don't need
it) but the composite-in works
Mauro Carvalho Chehab wrote:
If your board have an unique PCI ID, we may add it to the driver,
avoiding this need. For this, we will need the results of the following
command:
lspci -vv -nn
I'm using card=65 to use my card. I never tried the tuner (don't need
it) but the composite-in works
lue gets auto-loaded?
Thanks in advance
Yours
Manuel Reimer
-
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/
Yours
Manuel Reimer
-
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/
At first: Thank you very much for the detailled information!
Alan Cox wrote:
Bad CRC indicates a data transfer problem between the drive and the
controller. The CRC is computed one end and verified the other. The OS
isn't directly involved.
This usually means either
#1 A 40 wire cable in use
At first: Thank you very much for the detailled information!
Alan Cox wrote:
Bad CRC indicates a data transfer problem between the drive and the
controller. The CRC is computed one end and verified the other. The OS
isn't directly involved.
This usually means either
#1 A 40 wire cable in use
Hello,
after my problems with my DVD drive, I've unplugged this device and
jumpered my burning device as master, to start my linux setup from there.
Now I don't longer get those silly DVD errors, but now I get something,
which is much more worrying for me:
http://pastebin.com/f6fc7552f
Hello,
after my problems with my DVD drive, I've unplugged this device and
jumpered my burning device as master, to start my linux setup from there.
Now I don't longer get those silly DVD errors, but now I get something,
which is much more worrying for me:
http://pastebin.com/f6fc7552f
Robert Hancock wrote:
It's not entirely clear to me whether the kernel is doing any retries or
not. It likely should be, but somebody more familiar with the block
layer would likely have to answer whether it will be or not..
Would be pretty great to get answer of someone, who knows if the
Robert Hancock wrote:
It's not entirely clear to me whether the kernel is doing any retries or
not. It likely should be, but somebody more familiar with the block
layer would likely have to answer whether it will be or not..
Would be pretty great to get answer of someone, who knows if the
Hello,
I tried to reproduce this bug by mounting/unmounting the drive several
times.
It seems like this problem is caused, if the drive is at speed 0 after
some time without access. In this situation, sometimes the drive seems
to take a bit longer to speed up. Whenever it takes a bit
Robert Hancock wrote:
I don't think this is a bug, the drive was told to read a sector and
returned error SK=03, ASC=02, ASCQ=00 which is "NO SEEK COMPLETE", in
other words it couldn't find that sector. Could be that the disc is
marginally readable and only sometimes causes read errors.
The
Robert Hancock wrote:
I don't think this is a bug, the drive was told to read a sector and
returned error SK=03, ASC=02, ASCQ=00 which is NO SEEK COMPLETE, in
other words it couldn't find that sector. Could be that the disc is
marginally readable and only sometimes causes read errors.
The
Hello,
I tried to reproduce this bug by mounting/unmounting the drive several
times.
It seems like this problem is caused, if the drive is at speed 0 after
some time without access. In this situation, sometimes the drive seems
to take a bit longer to speed up. Whenever it takes a bit
Hello,
today I've tried to install Slackware 12.0
As the installer just "skipped" some install steps, I tried to find the
error.
The problem seems to be unreadable parts on the DVD:
http://pastebin.com/f381e8a88
But the DVD is OK. I've checked the MD5sum directly from disc on the
same
Hello,
today I've tried to install Slackware 12.0
As the installer just skipped some install steps, I tried to find the
error.
The problem seems to be unreadable parts on the DVD:
http://pastebin.com/f381e8a88
But the DVD is OK. I've checked the MD5sum directly from disc on the
same
my
friends, who regularly compiled new kernels, lost files that way).
If 2.6.16 is the "real stable" branch, then I'd vote for using this one.
But it's not my decision. Anything I needed to know is that there will
be definetly no more security updates for 2.6.17.
Yours
Manuel Reim
to 2.6.16.
Thank you very much in advance
Yours
Manuel Reimer
-
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/
.
Thank you very much in advance
Yours
Manuel Reimer
-
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/
, lost files that way).
If 2.6.16 is the real stable branch, then I'd vote for using this one.
But it's not my decision. Anything I needed to know is that there will
be definetly no more security updates for 2.6.17.
Yours
Manuel Reimer
-
To unsubscribe from this list: send the line unsubscribe
59 matches
Mail list logo
