Bug#623059: Data corruption when sendfile is used on atl1c Atheros NIC.
Package: linux-2.6 Version: 2.6.32-33 Severity: grave File: /lib/modules/2.6.32-5-686-bigmem/kernel/drivers/net/atl1c/atl1c.ko Hello, As far as I can tell it there is the bug occuring when combination of sendfile(2) and module atl1c is used. The result of the bug is data corruption. Examples of data corruption are in attached files: - orig.txt - the original file, output of command seq 1 600 | xargs printf '%04d\n' - apache.dat - result of wget http://the.server/orig.txt -O apache.dat - sendfile.dat - file sent from the same server using attached program and netcat The mentioned server has a multiple interfaces and this problem appears only on Atheros interface. After spotting the problem on Apache first I finally nailed it to sendfile function. The problem appears only for files longer than some specific value. For Apache it was 2600 bytes (I suppose it's because of headers added by webserver). For my test program the minimal size of file where the problem appears is 2896 bytes. I also found a similar problem on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/slide-webdavclient/+bug/651004 The common factor is Atheros AR8131. Best regards Artur -- Package-specific info: ** Version: Linux version 2.6.32-5-686-bigmem (Debian 2.6.32-33) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Apr 4 22:36:24 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-686-bigmem root=UUID=88e830fa-51a6-4d5f-bac5-26e00210b525 ro quiet ** Not tainted ** Kernel log: [1.109796] uhci_hcd :00:1d.3: UHCI Host Controller [1.109803] uhci_hcd :00:1d.3: new USB bus registered, assigned bus number 5 [1.109828] uhci_hcd :00:1d.3: irq 16, io base 0xfb00 [1.109850] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 [1.109853] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.109855] usb usb5: Product: UHCI Host Controller [1.109856] usb usb5: Manufacturer: Linux 2.6.32-5-686-bigmem uhci_hcd [1.109858] usb usb5: SerialNumber: :00:1d.3 [1.109903] usb usb5: configuration #1 chosen from 1 choice [1.109924] hub 5-0:1.0: USB hub found [1.109929] hub 5-0:1.0: 2 ports detected [1.110627] libata version 3.00 loaded. [1.112917] ata_piix :00:1f.2: version 2.13 [1.112934] ata_piix :00:1f.2: PCI INT B - GSI 19 (level, low) - IRQ 19 [1.112938] ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] [1.112973] ata_piix :00:1f.2: setting latency timer to 64 [1.113039] scsi0 : ata_piix [1.113148] scsi1 : ata_piix [1.113687] ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf800 irq 14 [1.113689] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xf808 irq 15 [1.172748] atl1c :02:00.0: version 1.0.0.2-NAPI [1.279888] ata1.00: HPA detected: current 976771055, native 976773168 [1.279894] ata1.00: ATA-8: WDC WD5002AALX-00J37A0, 15.01H15, max UDMA/133 [1.279897] ata1.00: 976771055 sectors, multi 16: LBA48 NCQ (depth 0/32) [1.292662] ata1.00: configured for UDMA/133 [1.292765] scsi 0:0:0:0: Direct-Access ATA WDC WD5002AALX-0 15.0 PQ: 0 ANSI: 5 [1.298826] sd 0:0:0:0: [sda] 976771055 512-byte logical blocks: (500 GB/465 GiB) [1.298887] sd 0:0:0:0: [sda] Write Protect is off [1.298890] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [1.298912] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [1.299039] sda: sda1 sda2 sda3 sda4 [1.317839] sd 0:0:0:0: [sda] Attached SCSI disk [1.570230] device-mapper: uevent: version 1.0.3 [1.570459] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-de...@redhat.com [1.592994] kjournald starting. Commit interval 5 seconds [1.592998] EXT3-fs: mounted filesystem with ordered data mode. [2.002170] udev[405]: starting version 164 [2.082367] ACPI: SSDT 7f5ed720 0022A (v01 PmRef Cpu0Ist 3000 INTL 20040311) [2.082589] processor LNXCPU:00: registered as cooling_device0 [2.082764] ACPI: SSDT 7f5edbe0 00152 (v01 PmRef Cpu1Ist 3000 INTL 20040311) [2.082964] processor LNXCPU:01: registered as cooling_device1 [2.083163] ACPI: SSDT 7f5edd40 00152 (v01 PmRef Cpu2Ist 3000 INTL 20040311) [2.083407] processor LNXCPU:02: registered as cooling_device2 [2.083716] ACPI: SSDT 7f5edea0 00152 (v01 PmRef Cpu3Ist 3000 INTL 20040311) [2.083981] processor LNXCPU:03: registered as cooling_device3 [2.113596] input: PC Speaker as /devices/platform/pcspkr/input/input1 [2.149526] udev[430]: renamed network interface eth2 to eth2-eth0 [2.184981] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2 [2.185019] ACPI: Power Button [PWRB] [2.185079] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [2.185099] ACPI: Power Button [PWRF] [2.186831] udev[418]: renamed network interface eth1 to eth2 [
Bug#344481: Need other to be fixed
severity 344481 important block 330197 by 344481 thanks I see no reason to keep #344481 as serious until there is no known reason of #330197. -- Nasz bohater często siada przed komputerem i myśli recenzja http://czat.zlotemysli.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344481: Mysterious crash in php4-rrdtool
On Thu, Dec 22, 2005 at 10:21:52PM -0800, Steve Langasek wrote: I'd rather see some analysis to show where the bug actually belongs instead of guessing and reassigning. Well, some analysis you asked for. I use glibc-2.3.5-11 with libc6-dbg installed. export LD_LIBRARY_PATH=/usr/lib/debug gdb /usr/sbin/apache br _getopt_internal_r (it is called from getopt_long, here is the logic) r -X (breakpoint activated some times due to apache parameters) I run the script calling rrd_graph and I'm inside: #0 _getopt_internal_r (argc=22, argv=0x8141b78, optstring=0xb78dcb10 s:e:x:y:v:w:h:iu:l:rb:oc:n:m:t:f:a:I:zgjFYAMEX:L:S:T:NR:B:, longopts=0xb78f1a20, longind=0xbf81f324, long_only=0, d=0xb7d54400) at getopt.c:398 I set display for following expressions: argv[d-optind], d-optind, d-optarg, optarg. Stepping by next until getopt.c:451. Some iteration of: while (d-optind argc NONOPTION_P) d-optind++; and I have: d-optind = 2 d-optarg = 0x0 optarg=0x0 argv[d-optind] = 0x8141be4 --start Some steps inside the code. And, after getopt.c:679: d-optarg = argv[d-optind++]; I have: 3: d-optarg = 0x8141bfc -2d 2: d-optind = 4 1: argv[d-optind] = 0x8141c14 --x-grid So far it's OK. Still stepping. Back to: _getopt_internal (argc=22, argv=0x8141b78, optstring=0xb7928b10 s:e:x:y:v:w:h:iu:l:rb:oc:n:m:t:f:a:I:zgjFYAMEX:L:S:T:NR:B:, longopts=0xb793da20, longind=0xbfa6a7c4, long_only=0) at getopt.c:1169 There are three lines: optind = getopt_data.optind; optarg = getopt_data.optarg; optopt = getopt_data.optopt; After executing those lines I have: (gdb) print getopt_data.optind $1 = 4 (gdb) print getopt_data.optarg $2 = 0x8141bfc -2d and (sic!): (gdb) print optind $4 = 4 (gdb) print optarg $5 = 0x0 So, the question is: why the assignment in getopt.c:1170: optarg = getopt_data.optarg; does not work? I would like to remind you that getopt_long from libc works correctly (details in this buglog) in most cases. But combination of apache, php4, rrdtool and php4-rrdtool makes it unworking. Regards Artur -- zjadłam ruskie i barszcz ukraiński. ciekawe czy od tego dostanę automatycznie złotych zębów /majaka/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344481: Mysterious crash in php4-rrdtool
On Thu, Dec 22, 2005 at 10:21:52PM -0800, Steve Langasek wrote: Break on rrd_graph_options, step into getopt_long, run bt to see what lib it says it's in. Well, I should tell it earlier. It looks like getopt_long comes from glibc, backtrace follows. Breakpoint 1, 0xb7d085b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7d085b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 #1 0xb78d839c in rrd_graph_options () from /usr/lib/librrd.so.2 #2 0xb78d8fda in rrd_graph () from /usr/lib/librrd.so.2 #3 0xb7c1e64b in zif_rrd_graph () from /usr/lib/php4/20050606/rrdtool.so #4 0xb72bbe82 in execute () from /usr/lib/apache/1.3/libphp4.so #5 0xb72a27f5 in zend_execute_scripts () from /usr/lib/apache/1.3/libphp4.so That does not bring me any closer to the solution. Especially because the example from my previous e-mail works correctly with exactly the same getopt_long: (gdb) r --letter-a -2 Starting program: /tmp/g/gol --letter-a -2 Breakpoint 2 at 0xb7f3c5b6 Pending breakpoint getopt_long resolved Breakpoint 2, 0xb7f3c5b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7f3c5b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 #1 0x0804844b in main () Because only apache/php4(module) is a problematic combination I suspect an apache. If it is sufficient for you I have no objections against reassigning this bug to apache package. I'd rather see some analysis to show where the bug actually belongs instead of guessing and reassigning. That's understandable. But this case exceeds my knowledge. Regards Artur -- Czesiu: Dlaczego wypiłaś cały dzbanek herbaty? Croolik: Bo był. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344481: Mysterious crash in php4-rrdtool
On Thu, Dec 22, 2005 at 04:45:25PM -0800, Steve Langasek wrote:
On Fri, Dec 23, 2005 at 01:09:31AM +0100, Artur R. Czechowski wrote:
The rrd_graph_options() gets a string with parameters. The begin if this
string is (at least in my case, but this is common value in rrdtools):
--start -2d
The rrd_graph_options calls getopt_long to split parameters into tokens.
You can see the code in rrdtool's sources, file rrd_graph.c, line 2965.
getopt_long reckognises the --start parameter correctly and, according to
struct option returns opt as s. But, for some strange reasons, it sets
optarg for NULL.
Erm, don't you need to write --start=-2d if you want an optarg that begins
with a hyphen?
No. The s: in optstring and 1 as a second value in {start,1,0,'s'} always
makes next token a parameter.
Try to compile and run following example:
#include stdio.h
#include getopt.h
struct option opt[] = {
{letter-a,1,0,'a'},
{letter-b,1,0,'b'},
{0,0,0,0}
};
int main(int argc,char **argv) {
int idx,c;
while((c=getopt_long(argc,argv,a:b:,opt,idx))!=EOF)
printf(option: %c, optarg: %s\n,c,optarg);
};
It gives:
[EMAIL PROTECTED]:/tmp/g$ ./gol --letter-a -2d
option: a, optarg: -2d
[EMAIL PROTECTED]:/tmp/g$ ./gol -a -2d
option: a, optarg: -2d
Anyway, I don't see where any of the other packages you've mentioned are
providing a broken implementation of getopt_long. Shouldn't you check where
this broken function is coming from, and file the bug there?
Wish I know how to do it. Simple grep in sources gives no results.
That's why it is so mysterious to me and I am asking for help at wider
auditorium.
Because only apache/php4(module) is a problematic combination I suspect
an apache. If it is sufficient for you I have no objections against
reassigning this bug to apache package.
Best regards
Artur
--
Beowulf here http://www.messagelabs.com/home/default.asp they say that
spam is more than 50% of email...
Beowulf let's start some flames in -devel!
* Beowulf writes something about Sarge not being released
/from #debian-devel/
signature.asc
Description: Digital signature
apache is segfaulting under some circumstances
Hello,
I notified, that my apache (1.3.33-8) segfaults since some days.
when I try to generate a PNG image from php4-rrdtool extension.
Backtrace shows nothing interesting:
(gdb) run -X
Starting program: /usr/sbin/apache -X
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1988)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1988)]
0xb7ce7453 in strlen () from /usr/lib/debug/libc.so.6
(gdb) bt
#0 0xb7ce7453 in strlen () from /usr/lib/debug/libc.so.6
#1 0xb77c267b in parsetime () from /usr/lib/librrd.so.2
#2 0xb77d087a in rrd_graph_options () from /usr/lib/librrd.so.2
#3 0xb77d0f6a in rrd_graph () from /usr/lib/librrd.so.2
#4 0xb799166b in zif_rrd_graph () from /usr/lib/php4/20050606/rrdtool.so
#5 0xb735da32 in execute () from /usr/lib/apache/1.3/libphp4.so
#6 0xb73444d5 in zend_execute_scripts () from /usr/lib/apache/1.3/libphp4.so
#7 0xb731573d in php_execute_script () from /usr/lib/apache/1.3/libphp4.so
#8 0xb73629ae in apache_php_module_main () from /usr/lib/apache/1.3/libphp4.so
#9 0xb73634c5 in apache_php_module_main () from /usr/lib/apache/1.3/libphp4.so
#10 0xb73637d1 in apache_php_module_main () from /usr/lib/apache/1.3/libphp4.so
#11 0x080549ae in ap_invoke_handler ()
#12 0x0806611b in ap_update_mtime ()
#13 0x08066869 in ap_process_request ()
#14 0x0805e6ca in ap_update_child_status ()
#15 0x0805eacd in ap_update_child_status ()
#16 0x0805ebbe in ap_update_child_status ()
#17 0x0805fa8a in ap_update_child_status ()
#18 0x08060893 in main ()
strlen segfaults because it receives a NULL as a parameter, but the problem
lies somewhere else.
Frame #2, rrd_graph_options() from librrd. This procedure parses given
arguments. It uses getopt_long to parse data. Quote from
src/rrd_graph.c::rrd_graph_options():
static struct option long_options[] =
{
{start, required_argument, 0, 's'},
...
};
/* some other code */
opt = getopt_long(argc, argv,
s:e:x:y:v:w:h:iu:l:rb:oc:n:m:t:f:a:I:zgjFYAMEX:L:S:T:NR:B:,
long_options, option_index);
I've added code to add to syslog:
a) whole argv;
b) opt and (if NULL) optarg.
First, I run rrdtool graph from CLI with a set of parameters:
LC_CTYPE=pl_PL rrdtool graph plik.png --start -2d --x-grid
HOUR:1:HOUR:6:HOUR:3:0:%H:%M --vertical-label B/s -h 200 -w 650 --color
'GRID#E0E0E0' --color 'MGRID#A03000' --title 'Obciążenie łącza'
DEF:inb=/home/arturcz/rrd/blabluga-eth0.rrd:in:AVERAGE
DEF:outb=/home/arturcz/rrd/blabluga-eth0.rrd:out:AVERAGE
'AREA:inb#40E040:Średni ruch przychodzący (5 minut)' 'LINE1:outb#007000:Średni
ruch wychodzący (5 minut)'
Then I run a function from php4-rrdtool extension. All parameters (as
shown in syslog) are identical. But this time getopt_long reckognises
--start as -s, but sets optarg to NULL for this option. This error happens
only when I pass the arguments to librrd from php4/apache. Everything works
good for php4/apache2. That's why I suspect apache as a source of the problem.
Have you any insights about nature of this bug?
Regards
Artur
--
windows jest jak Odie - głupi jak but, cały czas się uśmiecha, a linux jak
Garfield - może i by coś zrobił, ale trzeba go najpierw do tego zmusić.
/yacoob/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247011: Broken dependency - apache requires perl 5.8.4-0 which is unavailable
Package: apache Version: 1.3.29.0.2-5 Severity: serious Tags: sid The apache package has dependency on perl 5.8.4-0 but perl 5.8.4-1 hit unstable today. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.5arc Locale: LANG=C, LC_CTYPE=pl_PL Versions of packages apache depends on: ii apache-common 1.3.29.0.2-5 Support files for all Apache webse ii debconf 1.4.25 Debian configuration management sy ii dpkg1.10.21 Package maintenance system for Deb ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an ii libdb4.24.2.52-16Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-20 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-3 Larry Wall's Practical Extraction -- debconf information excluded -- - God, root, what's the difference? - God has mercy /Illiad, User friendly/
