ASUS DRW-1608P, doesn't write anything
I have problem with an ASUS DRW-1609P with both 5.3 and 5.4. It won't write any media. Even burncd fails with the following error: (Yes, I know I have test mode on, I got tired of making coasters) burncd -f /dev/acd0 -s max -v -t data file.iso fixate adding type 0x08 file mp3.iso.aa size 72 KB 36 blocks next writeable LBA 2136 addr = 2136 size = 73728 blocks = 36 writing from file mp3.iso.aa size 72 KB written this track 1120 KB (0%) total 1120 KB only wrote -1 of 32768 bytes: Device busy Relevent line from dmesg: acd0: DVDR ASUS DRW-1608P/1.17 at ata1-master PIO4 atapicam doesn't fix it. UDMA doesn't fix it. GENERIC kernel. Reading works fine. Suggestions? -- David E. Cross ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ASUS DRW-1608P, doesn't write anything
I have problem with an ASUS DRW-1609P with both 5.3 and 5.4. It won't write any media. Even burncd fails with the following error: (Yes, I know I have test mode on, I got tired of making coasters) burncd -f /dev/acd0 -s max -v -t data file.iso fixate adding type 0x08 file mp3.iso.aa size 72 KB 36 blocks next writeable LBA 2136 addr = 2136 size = 73728 blocks = 36 writing from file mp3.iso.aa size 72 KB written this track 1120 KB (0%) total 1120 KB only wrote -1 of 32768 bytes: Device busy Relevent line from dmesg: acd0: DVDR ASUS DRW-1608P/1.17 at ata1-master PIO4 atapicam doesn't fix it. UDMA doesn't fix it. GENERIC kernel. Reading works fine. Suggestions? Same with: acd1: ASUS DRW-0402P/D/1.05 DVDR drive at ata1 as slave acd1: read 5511KB/s (5511KB/s) write 2755KB/s (2755KB/s), 2000KB buffer, PIO4 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd1: Writes: CDR, CDRW, DVDR, test write, burnproof acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc I simply use it through ATAPICAM layer with cdrecord - always worked perfectly. Would be interesting to know why these devices don't behave properly. Timestamp: 0x4260B31F [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for FreeBSD status reports
IIRC most of reports should valid from the last call since they wasn't published. Am I right, or we should send them again? rik Max Laier: All, as I wrote last week: Submissions are due on April 15. Thanks a lot, and we are hoping for a big turn-out. As always this is not final, but please get your reports ready by monday and maybe let us know that you are planing to submit. Unfortunately we have a dramatically lower turn-out so far, I hope to see more reports floating in over the weekend. Thanks a lot! http://www.FreeBSD.org/news/status/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ext2 drives under 5.3 not umounting on reboots
I have a ext2 linux partition mounted under /linux via the fstab line: /dev/ad2s1 /linux ext2fs rw 1 2 It will automount on bootup, but if I do a reboot or shutdown -h now, it doesnt get umounted properly. In fact, if this /linux is mounted, then /, /usr, /var, and /tmp (all seperate ufs slices on another hard drive) also get tainted during a reboot. And on the next startup I get the good ole: WARNING: /usr was not properly dismounted, leaving me to fsck the drives in single mode (which sucks, as the fbsd machine is a headless NAT machine). Running fsck in single mode does fix everything. So whats going on here? reboot aint properly umounting partitions, and fsck doesnt seem to be properly running during bootup if it detects tainted filesystems. Any ideas? Freebsd 5.3 SMP kernel. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ext2 drives under 5.3 not umounting on reboots
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 16 Apr 2005, M. Parsons wrote: I have a ext2 linux partition mounted under /linux via the fstab line: /dev/ad2s1 /linux ext2fs rw 1 2 It will automount on bootup, but if I do a reboot or shutdown -h now, it doesnt get umounted properly. In fact, if this /linux is mounted, then /, /usr, /var, and /tmp (all seperate ufs slices on another hard drive) also get tainted during a reboot. And on the next startup I get the good ole: WARNING: /usr was not properly dismounted, leaving me to fsck the drives in single mode (which sucks, as the fbsd machine is a headless NAT machine). Running fsck in single mode does fix everything. So whats going on here? reboot aint properly umounting partitions, and fsck doesnt seem to be properly running during bootup if it detects tainted filesystems. Any ideas? Freebsd 5.3 SMP kernel. Try this line: /dev/ad2s1 /linux ext2fs rw 0 0 But remember the ext2 code has been buggy for a while and is not allways a good choice to try and do writes on it. Might be a better choice to change rw to ro and to also check that drive/partition for errors with its original fsck to fix any errors if there is any then it will most likely mount properly and umount properly. Best of luck, --c0ldbyte - -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB 7E77 B261 50BA F7DF 979F iD8DBQFCYX6asmFQuvffl58RAilFAJ0RPeJHhvEJezh0qcy8lWj9we1IMwCfS7La /SULj+UxXMfIdKv+PYf+vQ4= =JRYg -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ext2 drives under 5.3 not umounting on reboots
c0ldbyte wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 16 Apr 2005, M. Parsons wrote: I have a ext2 linux partition mounted under /linux via the fstab line: /dev/ad2s1 /linux ext2fs rw 1 2 It will automount on bootup, but if I do a reboot or shutdown -h now, it doesnt get umounted properly. In fact, if this /linux is mounted, then /, /usr, /var, and /tmp (all seperate ufs slices on another hard drive) also get tainted during a reboot. And on the next startup I get the good ole: WARNING: /usr was not properly dismounted, leaving me to fsck the drives in single mode (which sucks, as the fbsd machine is a headless NAT machine). Running fsck in single mode does fix everything. So whats going on here? reboot aint properly umounting partitions, and fsck doesnt seem to be properly running during bootup if it detects tainted filesystems. Any ideas? Freebsd 5.3 SMP kernel. Try this line: /dev/ad2s1 /linux ext2fs rw 0 0 But remember the ext2 code has been buggy for a while and is not allways a good choice to try and do writes on it. Might be a better choice to change rw to ro and to also check that drive/partition for errors with its original fsck to fix any errors if there is any then it will most likely mount properly and umount properly. Best of luck, --c0ldbyte Well, I just said screw it, backed up the files I needed, then converted the whole disk to UFS. Time to wash my hands clean of linux anywas. :-) Still sort of worried that reboot wasnt unmounting the linux drive, but oh well, no more worries now. :) Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Determine LD_PRELOAD'ed symbols. (UPDATE)
Hello Hackers!, My first post got stuck waiting for moderator, and after some investigation I'd like to ask a bit more substantial question on the topic anyway: With program A ptrace'ing program B which runs with LD_PRELOAD'ed library libC.so, how can i find from program A where functions from libC are located in B's memory? The dump generated with LD_DUMP_REL_PRE shows only symbols which already were in B, but were masked by LD_PRELOAD'ing libC.so, does it mean that other symbols exported by libC.so are unaccessible from B? If not, where to search for their locations? Will sections in B and libC.so give any hints? Pointers to doc/code (but please something smaller than src/libexec/rtld-elf ;) welcome. -- m. Brain power of a glass of water. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]