R: ahci timeout
From : nde...@gmail.com On 27 Dec, 2010, at 21:20 , Barbara wrote: As my old PATA hard disk was failing, I had to replace it with a new SATA drive where I moved my FreeBSDs installations, as PATA drives are not easy to find these days. So I had to move one of my data drive from a VIA8237A SATA controller to the last free SATA slot on a Marvell 88SX6121 to make room for the new hd. The hd I moved was working perfectly when connected to the VIA controller. Now, with the Marvell I'm getting messages like the following twos while using the disk: ahcich0: Timeout on slot 10 ahcich0: is cs 3800 ss 3c00 rs 3c00 tfd 50010040 serr ahcich0: Timeout on slot 5 ahcich0: is cs 0180 ss 01e0 rs 01e0 tfd 50040040 serr This doesn't happen regularly. For example downloading from a slow website on it, so few kb/s, is ok. But if I copy files from the disk attacked to the Marvell controller to another another disk, or for example run md5 on some files, it's very likely to happen. The process accessing the disk can not be killed even with -9, ^C does nothing, and umount doesn't exit. If I'm copying files on it from another disk it can't be unmounted too as the unkillable process has it in use. On shutdown many disk doesn't get unmounted, so there are a lot of fsck on boot, and on CURRENT (last built yesterday), FreeBSD enter debugger as it fail flushing disk caches. Relevant part from dmesg: atapci0: Marvell 88SX6121 UDMA133 controller port 0xdc00-0xdc07,0xd880- 0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdffc00- 0xfbdf irq 28 at device 0.0 on pci6 ahci0: Marvell 88SX6121 AHCI SATA controller on atapci0 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ata2: ATA channel 0 on atapci0 atapci1: VIA 8237A SATA150 controller port 0xbc00-0xbc07,0xb880-0xb883, 0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f,0xb000-0xb0ff irq 21 at device 15.0 on pci0 ata3: ATA channel 0 on atapci1 ata4: ATA channel 1 on atapci1 atapci2: VIA 8237A UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170- 0x177, 0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 on atapci2 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST31000528AS CC44 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1 at ata3 bus 0 scbus3 target 0 lun 0 ada1: WDC WD2500KS-00MJB0 02.01C03 ATA-7 SATA 2.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada2 at ata4 bus 0 scbus4 target 0 lun 0 ada2: ST3500320AS SD1A ATA-8 SATA 1.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3 at ata0 bus 0 scbus5 target 0 lun 0 ada3: MAXTOR STM3160212A 3.AAJ ATA-7 device ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada3: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Just to add a me too. I'm running -STABLE but have the same problems with Marvell 88SX6121 giving ahci timeout messages. Regards, Nikolay Nikolay, thanks for the feedback, even if unfortunately it's negative... I see that in both 8-STABLE (8.2-PRERELEASE now) and 9.0-CURRENT, both rebuilt no more than a week ago. I've also tried rebuilding the kernel with: options CAMDEBUG options CAM_DEBUG_BUS=0 options CAM_DEBUG_TARGET=0 options CAM_DEBUG_LUN=0 options CAM_DEBUG_FLAGS=CAM_DEBUG_TRACE (0 is the bus/target/lun of the marvell controller/attached hd) and run a test computing md5 for about 60GB of files. Obviously, as the debug options where active, it run successfully without any problems :) Is there any other info I should provide or any other test that I can do? Thanks Barbara Maybe the attached disk has some problems which aren't handled if it's attached to a 88SE6121 controller? From what I can see, connecting it to the other internal sata controller, which is a VIA 8237A, or to an external PCIe Sil3132 controller using the siis driver, those timeouts aren't happening. Anyway I see something which I don't understand. I tried reading some files (~1 gb) from the same slice (1st one, ~200gb) while looking at gstat. Some files are being read at 100mb/s some others at about 4 mb/s. It seems that a zone of the disk is very slow. The disk is a Seagate 7200.12 and neither smartmontools nor SeaTools (Seagate diagnostic
R: Recent mouse freeze problem with X, different window managers, any browser and flash.
For a week or so, with up to date, current, ports, etc. everytime I open a page that has automatic flash video my mouse freezes and I have to manually kill X and restart. I had worked fine for many months. Yesterday I rebuilt all linux emulation. All ports are up to date as of today. I have no idea where to look. Anyone else seen this or know where to look. thanks, From what I can see, on CURRENT most of the flash objects are triggering a X error. I can see it on the console where I started X, but I don't remember it now. I'll post il later. Anyway Xorg is still working after that. Barbara I think that it could be related to this message: http://lists.freebsd.org/pipermail/freebsd-current/2010-December/021997.html even if I'm on i386 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: Recent mouse freeze problem with X, different window managers, any browser and flash.
On Tue, 11 Jan 2011 22:58:16 +0100 (CET) Barbara barbara.xxx1...@libero.it wrote: For a week or so, with up to date, current, ports, etc. everytime I open a page that has automatic flash video my mouse freezes and I have to manually kill X and restart. I had worked fine for many months. Yesterday I rebuilt all linux emulation. All ports are up to date as of today. I have no idea where to look. Anyone else seen this or know where to look. thanks, From what I can see, on CURRENT most of the flash objects are triggering a X error. I can see it on the console where I started X, but I don't remember it now. I'll post il later. Anyway Xorg is still working after that. Barbara I think that it could be related to this message: http://lists.freebsd.org/pipermail/freebsd-current/2010-December/021997. html even if I'm on i386 Try disabling mtrr, machdep.disable_mtrrs=0 through /boot/loader.conf. If that is the case, you probably want this: http://people.freebsd.org/~ariff/misc/mtrr.diff I'm CCing jkim@ (r215415) -- Ariff Abdullah FreeBSD I solved the problems after a make world. Previous one has been done on Dec. 26th. I'll describe better you what I was seeing: first I noticed that most flash objects were not working, and that when it was happening a crash in Xorg caused somehow by gdk-pixbuf2 were trapped. Then I tried to rebuild graphics/gdk-pixbuf2 but the build was failing and as far as I can remember it was somehow related to endian.h. A required port, devel/gmake was failing too. Then I tried to run portsnap and update the (few) outdated ports and there was an error rebuilding java/openjdk6. No all the problem are gone away. Summarizing it was similar, except that I'm on i386, to the one reported in the same discussion reported before, exactly here: http://lists.freebsd.org/pipermail/freebsd-current/2010-December/022021.html So, from what I can understand, I think that what you are suggesting is not needed for me. Do you think I am correct? What kind of problem should the setting for loader fix? In any case, thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: Recent mouse freeze problem with X, different window managers, any browser and flash.
For a week or so, with up to date, current, ports, etc. everytime I open a page that has automatic flash video my mouse freezes and I have to manually kill X and restart. I had worked fine for many months. Yesterday I rebuilt all linux emulation. All ports are up to date as of today. I have no idea where to look. Anyone else seen this or know where to look. thanks, From what I can see, on CURRENT most of the flash objects are triggering a X error. I can see it on the console where I started X, but I don't remember it now. I'll post il later. Anyway Xorg is still working after that. Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: lockup with vidcontrol VESA_800x600
Hiho! :-) Yesterday I upgraded to FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan 8 17:05:30 CET 2011 and vidcontrol VESA_800x600 stopped working (again). I exchanged emails with jkim about a similar problem in February 2010 (vidcontrol VESA_800x600 would mangle the screen output), there was no definitive resolution, but it started working again sometime around July 2010. Now however, when I try to set VESA_800x600, my machine seems to lockup. It no longer responds to any input, I cannot ping it and I cannot drop to the debugger. I've tried setting other modes, but trying to set them results in: obtaining new video mode parameters: operation not supported by device. graphics card is a: vgap...@pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)' class = display subclass = VGA Any clues what might have changed? I had to gave up with VESA. Before all the changes (feb./mar. 2010) it was working perfectly with MODE_280. Now I have to use MODE_30, because any other higher resolution isn't working or it's crashing the machine, as I've reported yet. I would like to add that yesterday, I left twice my pc running CURRENT turned on while doing other things. And both time on my return it was dead. Not even replying to ping. I had to set blanktime=NO in /etc/rc.conf. I'm not sure if the problem has been introduced recently. Did you noticed that too? Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ahci timeout
From : nde...@gmail.com On 27 Dec, 2010, at 21:20 , Barbara wrote: As my old PATA hard disk was failing, I had to replace it with a new SATA drive where I moved my FreeBSDs installations, as PATA drives are not easy to find these days. So I had to move one of my data drive from a VIA8237A SATA controller to the last free SATA slot on a Marvell 88SX6121 to make room for the new hd. The hd I moved was working perfectly when connected to the VIA controller. Now, with the Marvell I'm getting messages like the following twos while using the disk: ahcich0: Timeout on slot 10 ahcich0: is cs 3800 ss 3c00 rs 3c00 tfd 50010040 serr ahcich0: Timeout on slot 5 ahcich0: is cs 0180 ss 01e0 rs 01e0 tfd 50040040 serr This doesn't happen regularly. For example downloading from a slow website on it, so few kb/s, is ok. But if I copy files from the disk attacked to the Marvell controller to another another disk, or for example run md5 on some files, it's very likely to happen. The process accessing the disk can not be killed even with -9, ^C does nothing, and umount doesn't exit. If I'm copying files on it from another disk it can't be unmounted too as the unkillable process has it in use. On shutdown many disk doesn't get unmounted, so there are a lot of fsck on boot, and on CURRENT (last built yesterday), FreeBSD enter debugger as it fail flushing disk caches. Relevant part from dmesg: atapci0: Marvell 88SX6121 UDMA133 controller port 0xdc00-0xdc07,0xd880- 0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdffc00-0xfbdf irq 28 at device 0.0 on pci6 ahci0: Marvell 88SX6121 AHCI SATA controller on atapci0 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ata2: ATA channel 0 on atapci0 atapci1: VIA 8237A SATA150 controller port 0xbc00-0xbc07,0xb880-0xb883, 0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f,0xb000-0xb0ff irq 21 at device 15.0 on pci0 ata3: ATA channel 0 on atapci1 ata4: ATA channel 1 on atapci1 atapci2: VIA 8237A UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177, 0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 on atapci2 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST31000528AS CC44 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1 at ata3 bus 0 scbus3 target 0 lun 0 ada1: WDC WD2500KS-00MJB0 02.01C03 ATA-7 SATA 2.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada2 at ata4 bus 0 scbus4 target 0 lun 0 ada2: ST3500320AS SD1A ATA-8 SATA 1.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3 at ata0 bus 0 scbus5 target 0 lun 0 ada3: MAXTOR STM3160212A 3.AAJ ATA-7 device ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada3: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Just to add a me too. I'm running -STABLE but have the same problems with Marvell 88SX6121 giving ahci timeout messages. Regards, Nikolay Nikolay, thanks for the feedback, even if unfortunately it's negative... I see that in both 8-STABLE (8.2-PRERELEASE now) and 9.0-CURRENT, both rebuilt no more than a week ago. I've also tried rebuilding the kernel with: options CAMDEBUG options CAM_DEBUG_BUS=0 options CAM_DEBUG_TARGET=0 options CAM_DEBUG_LUN=0 options CAM_DEBUG_FLAGS=CAM_DEBUG_TRACE (0 is the bus/target/lun of the marvell controller/attached hd) and run a test computing md5 for about 60GB of files. Obviously, as the debug options where active, it run successfully without any problems :) Is there any other info I should provide or any other test that I can do? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: ahci timeout
As my old PATA hard disk was failing, I had to replace it with a new SATA drive where I moved my FreeBSDs installations, as PATA drives are not easy to find these days. So I had to move one of my data drive from a VIA8237A SATA controller to the last free SATA slot on a Marvell 88SX6121 to make room for the new hd. The hd I moved was working perfectly when connected to the VIA controller. Now, with the Marvell I'm getting messages like the following twos while using the disk: ahcich0: Timeout on slot 10 ahcich0: is cs 3800 ss 3c00 rs 3c00 tfd 50010040 serr ahcich0: Timeout on slot 5 ahcich0: is cs 0180 ss 01e0 rs 01e0 tfd 50040040 serr This doesn't happen regularly. For example downloading from a slow website on it, so few kb/s, is ok. But if I copy files from the disk attacked to the Marvell controller to another another disk, or for example run md5 on some files, it's very likely to happen. The process accessing the disk can not be killed even with -9, ^C does nothing, and umount doesn't exit. If I'm copying files on it from another disk it can't be unmounted too as the unkillable process has it in use. On shutdown many disk doesn't get unmounted, so there are a lot of fsck on boot, and on CURRENT (last built yesterday), FreeBSD enter debugger as it fail flushing disk caches. Relevant part from dmesg: atapci0: Marvell 88SX6121 UDMA133 controller port 0xdc00-0xdc07,0xd880- 0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdffc00-0xfbdf irq 28 at device 0.0 on pci6 ahci0: Marvell 88SX6121 AHCI SATA controller on atapci0 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ata2: ATA channel 0 on atapci0 atapci1: VIA 8237A SATA150 controller port 0xbc00-0xbc07,0xb880-0xb883, 0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f,0xb000-0xb0ff irq 21 at device 15.0 on pci0 ata3: ATA channel 0 on atapci1 ata4: ATA channel 1 on atapci1 atapci2: VIA 8237A UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177, 0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 on atapci2 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST31000528AS CC44 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1 at ata3 bus 0 scbus3 target 0 lun 0 ada1: WDC WD2500KS-00MJB0 02.01C03 ATA-7 SATA 2.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada2 at ata4 bus 0 scbus4 target 0 lun 0 ada2: ST3500320AS SD1A ATA-8 SATA 1.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3 at ata0 bus 0 scbus5 target 0 lun 0 ada3: MAXTOR STM3160212A 3.AAJ ATA-7 device ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada3: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) I've tried with the following setting in /boot/loader.conf: hw.pci.enable_msix=0 hw.pci.enable_msi=0 kern.cam.ada.default_timeout=60 with no luck. I had to hard reset while playing a video from the hd connected to the Marvell controller as, after running shutdown, it was stuck trying to umount all the partitions. Even ctrl+alt+del or a short pressure of the power button wasn't turning it down. I've also run smartctl -t long on the disk and no error are reported: $ smartctl -l selftest /dev/ada0 # 1 Extended offlineCompleted without error 00% 5542 - $ smartctl -l error /dev/ada0 No Errors Logged Here's my verbose dmesg: http://pastebin.com/sp6Js9Yj Btw, why is the controller identified as 88SX6121? Shouldn't it be 88SE6121 (s/X/E/)??? This is what is reported on ASUS website, mb manual and so on, and even running lshal! There is no 88SX6121 here: http://en.wikipedia.org/wiki/List_of_Marvell_Technology_Group_chipsets Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ahci timeout
As my old PATA hard disk was failing, I had to replace it with a new SATA drive where I moved my FreeBSDs installations, as PATA drives are not easy to find these days. So I had to move one of my data drive from a VIA8237A SATA controller to the last free SATA slot on a Marvell 88SX6121 to make room for the new hd. The hd I moved was working perfectly when connected to the VIA controller. Now, with the Marvell I'm getting messages like the following twos while using the disk: ahcich0: Timeout on slot 10 ahcich0: is cs 3800 ss 3c00 rs 3c00 tfd 50010040 serr ahcich0: Timeout on slot 5 ahcich0: is cs 0180 ss 01e0 rs 01e0 tfd 50040040 serr This doesn't happen regularly. For example downloading from a slow website on it, so few kb/s, is ok. But if I copy files from the disk attacked to the Marvell controller to another another disk, or for example run md5 on some files, it's very likely to happen. The process accessing the disk can not be killed even with -9, ^C does nothing, and umount doesn't exit. If I'm copying files on it from another disk it can't be unmounted too as the unkillable process has it in use. On shutdown many disk doesn't get unmounted, so there are a lot of fsck on boot, and on CURRENT (last built yesterday), FreeBSD enter debugger as it fail flushing disk caches. Relevant part from dmesg: atapci0: Marvell 88SX6121 UDMA133 controller port 0xdc00-0xdc07,0xd880- 0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdffc00-0xfbdf irq 28 at device 0.0 on pci6 ahci0: Marvell 88SX6121 AHCI SATA controller on atapci0 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ata2: ATA channel 0 on atapci0 atapci1: VIA 8237A SATA150 controller port 0xbc00-0xbc07,0xb880-0xb883, 0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f,0xb000-0xb0ff irq 21 at device 15.0 on pci0 ata3: ATA channel 0 on atapci1 ata4: ATA channel 1 on atapci1 atapci2: VIA 8237A UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177, 0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 on atapci2 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST31000528AS CC44 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1 at ata3 bus 0 scbus3 target 0 lun 0 ada1: WDC WD2500KS-00MJB0 02.01C03 ATA-7 SATA 2.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada2 at ata4 bus 0 scbus4 target 0 lun 0 ada2: ST3500320AS SD1A ATA-8 SATA 1.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3 at ata0 bus 0 scbus5 target 0 lun 0 ada3: MAXTOR STM3160212A 3.AAJ ATA-7 device ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada3: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libstc++ (?) problem on CURRENT?
I had a problem running the IcedTea java plugin on CURRENT i386, while it works on 8_STABLE. But maybe it's not a problem related to the port. Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. In the part of the code causing the crash, a std::map is read with an iterator in a for loop, and if a condition is met, an entry is erased. The following is the bt I'm getting: #0 0x29e36247 in kill () from /lib/libc.so.7 #1 0x29e361a6 in raise () from /lib/libc.so.7 #2 0x282424f6 in XRE_LockProfileDirectory () from /usr/local/lib/firefox3/libxul.so #3 signal handler called #4 0x29c8f1b2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #5 0x2ef92402 in IcedTeaPluginUtilities::invalidateInstance () from /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so ... I wrote a patch for the IcedTea plugin, replacing the for loop with a while and increasing the iterator before erasing from the map, and it seems working. Then I wrote a simple program that do something similar to IcedTea, so there is no need to build the whole java/openjdk6 port to do some testing. Running it on 8_STABLE it works, on CURRENT it crashes. You can find more details in this discussion on the freebsd-java ml: http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html You can find the patch and the sample code in the discussion above, anyway I'm reporting them here too: icedtea patch: http://pastebin.com/b2KKFNSG test case: http://pastebin.com/Amk4UJ0g I hope that the crash is not caused by a bad environment, can anyone else test it? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: Re: libstc++ (?) problem on CURRENT?
* Barbara barbara.xxx1...@libero.it, 20101106 10:57: Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. I'm sure you're not worse than me! :) Anyway that's what I was thinking when I wrote the patch. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. So you think that the problem is really in the original source code, but exposed only on CURRENT. That could be an option. Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's
segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above,
anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch
so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
Very nice explanation.
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR kern_sig.c + vm_kern.c
$ uname -a FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09: 10:51 CEST 2010 r...@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO i386 lock order reversal: 1st 0xc6befdd0 process lock (process lock) @ /usr/src/sys/kern/kern_sig.c:3341 2nd 0xc19b60e4 system map (system map) @ /usr/src/sys/vm/vm_kern.c:315 KDB: stack backtrace: db_trace_self_wrapper(c0914c5e,762f7379,6d762f6d,72656b5f,3a632e6e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c065397b,c0917db7,c591d340,c591e110,e83d1764,...) at kdb_backtrace+0x2a _witness_debugger(c0917db7,c19b60e4,c0936364,c591e110,c09366a4,...) at _witness_debugger+0x26 witness_checkorder(c19b60e4,9,c09366a4,13b,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c19b60e4,0,c09366a4,13b,c1995e80,...) at _mtx_lock_flags+0xc4 _vm_map_lock(c19b6088,c09366a4,13b,c09359b5,c6725b40,...) at _vm_map_lock+0x31 kmem_malloc(c19b6088,1000,101,e83d1834,c083e233,...) at kmem_malloc+0x3a page_alloc(c5de4a80,1000,e83d1827,101,c5de4a80,...) at page_alloc+0x27 keg_alloc_slab(c1995e88,4,c09359b5,83b,e83d1874,...) at keg_alloc_slab+0xe3 keg_fetch_slab(101,8,c5e1ef24,e83d18d4,c084008d,...) at keg_fetch_slab+0x17e zone_fetch_slab(c5de4a80,c1995e80,101,7f1,c0663577,...) at zone_fetch_slab+0x4c uma_zalloc_arg(c5de4a80,0,101,e83d1918,c061d135,...) at uma_zalloc_arg+0x5dd ksiginfo_alloc(0,e83d1918,e83d1970,17,c6befd48,...) at ksiginfo_alloc+0x37 sigqueue_add(c6d14aa8,0,c09116ff,81f,2,...) at sigqueue_add+0x175 tdsendsignal(c6befd48,c6bf6000,17,e83d1970,0,...) at tdsendsignal+0x3ce psignal(c6befd48,17,c09116ff,d0d,c5922140,...) at psignal+0x47 pgsigio(c5a7c0e0,17,0,c5a7c000,e83d1a98,...) at pgsigio+0xf1 tty_wakeup(c5a7c000,1,c091a9ec,447,3,...) at tty_wakeup+0x44 ttydisc_rint_done(c5a7c000,7f,0,c0,0,...) at ttydisc_rint_done+0xa4 sysmouse_event(c67064c0,14,2,0,2,...) at sysmouse_event+0x210 sc_mouse_ioctl(c5a7bc00,c014630a,c67064c0,c6725b40,c090ac47,...) at sc_mouse_ioctl+0x2a6 sctty_ioctl(c5a7bc00,c014630a,c67064c0,c6725b40,e83d1bb4,...) at sctty_ioctl+0xa4 consolectl_ioctl(c5c97b00,c014630a,c67064c0,3,c6725b40,...) at consolectl_ioctl+0x29 giant_ioctl(c5c97b00,c014630a,c67064c0,3,c6725b40,...) at giant_ioctl+0x75 devfs_ioctl_f(c67ef000,c014630a,c67064c0,c595a300,c6725b40,...) at devfs_ioctl_f+0x10b kern_ioctl(c6725b40,4,c014630a,c67064c0,13d1cec,...) at kern_ioctl+0x20d ioctl(c6725b40,e83d1cec,e83d1d28,e83d1d80,0,...) at ioctl+0x12f syscallenter(c6725b40,e83d1ce4,e83d1d1c,c089cc06,74a,...) at syscallenter+0x263 syscall(e83d1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281b179b, esp = 0xbfbfe98c, ebp = 0xbfbfeb18 --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR vfs_lookup.c + ffs_softdep.c + vfs_subr.c
$ uname -a FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09: 10:51 CEST 2010 r...@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO i386 lock order reversal: 1st 0xc68ec278 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:501 2nd 0xd995fc70 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11310 3rd 0xc6993278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2111 KDB: stack backtrace: db_trace_self_wrapper(c0914c5e,632e7262,3131323a,a0d31,70656474,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c065397b,c0917dd0,c5921168,c5924b80,e837b320,...) at kdb_backtrace+0x2a _witness_debugger(c0917dd0,c6993278,c0909713,c5924b80,c091f023,...) at _witness_debugger+0x26 witness_checkorder(c6993278,9,c091f023,83f,0,...) at witness_checkorder+0x839 __lockmgr_args(c6993278,80100,c6993298,0,0,...) at __lockmgr_args+0x816 ffs_lock(e837b448,c066428b,c091e452,80100,80100,...) at ffs_lock+0x82 VOP_LOCK1_APV(c0991580,e837b448,c67de91c,c09a9c80,c6993220,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c6993220,80100,c091f023,83f,4,...) at _vn_lock+0x5e vget(c6993220,80100,c67de870,50,0,...) at vget+0xb9 vfs_hash_get(c67a4798,2e00b,8,c67de870,e837b59c,...) at vfs_hash_get+0xe6 ffs_vgetf(c67a4798,2e00b,8,e837b59c,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c68ec220,0,c093400a,144,0,...) at softdep_sync_metadata+0xc92 ffs_syncvnode(c68ec220,1,c67de870,e837b65c,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c68ec220,200,0,880,c595a300,...) at ffs_truncate+0x87b ufs_direnter(c68ec220,c6993220,e837b914,e837bba4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(e837bba4,0,e837bb00,e837ba5c,c08b7b25,...) at ufs_makeinode+0x557 ufs_create(e837bb00,e837bb18,0,0,e837bb78,...) at ufs_create+0x30 VOP_CREATE_APV(c0991580,e837bb00,e837bba4,e837ba98,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e837bb78,e837bc2c,1a4,0,c595a300,...) at vn_open_cred+0x220 vn_open(e837bb78,e837bc2c,1a4,c67f0508,0,...) at vn_open+0x3b kern_openat(c67de870,ff9c,804c608,0,602,...) at kern_openat+0x128 kern_open(c67de870,804c608,0,601,21b6,...) at kern_open+0x35 open(c67de870,e837bcec,e837bd28,c09166de,0,...) at open+0x30 syscallenter(c67de870,e837bce4,e837bce4,0,c09c3210,...) at syscallenter+0x263 syscall(e837bd28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817485b, esp = 0xbfbfec0c, ebp = 0xbfbfec78 --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re:HEADS UP: device name checking on device registration
Since r213526 device names are checked on device registration. That is, if you call a make_dev*() function with an invalid device name, a panic will occur by default. For make_dev_credf(9) or make_dev_p(9) you can specify the MAKEDEV_CHECKNAME flag to get an error return instead of a panic. Invalid names are as follows: - empty name - names longer than SPECNAMELEN - names containing . or .. path component - names ending with '/' - already existing device names So, if you see a bad si_name panic you may have encountered a driver bug. Currently several GEOM classes (notably geom_label) allow to create devices with invalid names. Below is a link to a patch which converts g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not a complete solution and essentially changes the panic to a printf. http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff -- Jaakko Hi, I faced that kind of panic today and now I'm able to boot again into CURRENT after applying the patch and rebuilding kernel. The panic is caused by: g_dev_taste(): make_dev_p() failed (gp-name=ext2fs//, error=22) as I have a linux partition (I swear, it's for my mom!) on the same machine. As I don't care about that partition (being ext4 I can't even mount it), is there any solution other then applying the patch after every csup? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: Re: making dependencies breaks between r210462 and r210495?
On Mon, 26 Jul 2010, David Wolfskill wrote: I don't know if this is likely to bite enough folks htat updating UPDATING is warranted. The window was small, so probably not. Doug Last time I've update the src tree (with csup) and successfully rebuilt world+kernel was on July 25th, so just one day before this problem was reported. I've updated the src tree yesterday and now I'm getting the same exact error. Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
