HEADS UP: at_shutdown going away
That's right, systems will never shut down. 8) Seriously though, I'm in the process of replacing a number of the ad-hoc event handler callout lists in the kernel (most notably the at_shutdown and apm* lists) with a generic implementation. The upshot of this is that at_shutdown will go away. The old calls: at_shutdown(func, arg, queue) at_shutdown_pri(func, arg, queue, priority) will be replaced with EVENTHANDLER_REGISTER(queue, func, arg, priority) Due to the way the event handler works, this means that event handler functions which were originally void func(int howto, void *arg) will become void func(void *arg, int howto) This is unfortunate but more or less unavoidable. I will be converting all users of at_shutdown in the kernel to the new mechanism, but it's of some concern to me that there may be external code using the old at_shutdown* interfaces that may benefit from a compatibility interface (which could be done relatively easily). Is there significant interest in having this implemented? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
: you can do a 'quick erase' of the media using 'cdrecord blank=fast'. : This does not actually erase the data, so if you have used say 100MB : you will only have 550MB left. You can actually erase the media using : 'cdrecord blank=all', which takes a while. : :In my experience, this is not true. I have used blank=fast on a CDRW :that has over 500 MB written, and then written another 500 MB without :a problem. Really? I'll have to mess with it some more. Maybe I had tried to write more data then I thought in my last test. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
: you can do a 'quick erase' of the media using 'cdrecord blank=fast'. : This does not actually erase the data, so if you have used say 100MB : you will only have 550MB left. You can actually erase the media using : 'cdrecord blank=all', which takes a while. : :In my experience, this is not true. I have used blank=fast on a CDRW :that has over 500 MB written, and then written another 500 MB without :a problem. Really? I'll have to mess with it some more. Maybe I had tried to write more data then I thought in my last test. I just happen to be writing another cd 8) mkisofs -R /mount/cdrom | cdrecord -blank=fast -v fs=10m speed=3 - Track 01: 597 MB written (fifo 100%).Total extents actually written = 311018 Total translation table size: 0 Total rockridge attributes bytes: 1076001 Total directory bytes: 3112960 Path table size(bytes): 15778 Max brk space used 84a29c 311018 extents written (607 Mb) Track 01: 607 MB written (fifo 100%). Track 01: Total bytes read/written: 636964864/636964864 (311018 sectors). Writing time: 2190.437s Fixating... Fixating time: 129.090s cdrecord: fifo had 10034 puts and 10034 gets. cdrecord: fifo was 0 times empty and 9713 times full, min fill was 89%. This is like the third time that I writing pretty much the same image to the CD. Enjoy -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PnP probe croaks in boot...
Mike, the PnP probe you added panics my HP800CT during boot. With -v it prints (typed from barely legible notes:) PnPbios: Found PnPBiosdata 0xc00ff000 PnPbios: Entry e8000:33e1 rev 1.0 PnPbios: eventflag at e801b OEM ID 1826744e and then panics with a pagefault at EIP: %058:0x343e, fault address 0x100e. Adding some debugging showed me that this happens on the very first call to bios16_call(). The funny thing is, this happens after a cold boot (hard reset), and goes on until I have booted my /kernel.good (from before your change) just once. After that, and until next hard reset a -current kernel boots just fine. Smells like som unitialized data or something to me... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [fwd] [fm/news] newsletter for Aug 18th 1999, 23:59
On Thu, Aug 19, 1999 at 09:31:48AM +0300, Hristo Grigorov wrote: [EMAIL PROTECTED] ??? Well, somebody should probably contact freshmeat and let them know that it's not an "official" release as such. Unless, of course, we want the ability to submit daily snapshots to freshmeat. :-) -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator "Finally, when replying to messages only quote the parts of the message your will be discussing or that are relevant. Quoting whole messages and adding two lines at the top is not good etiquette." -- Elias Levy ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Bug with malloc_options
Hi, -current from ~3 days ago. from malloc(3): ---snip--- To specify in the source that a program does no return value checking on calls to these functions: extern char *malloc_options; malloc_options = "X"; ---snip--- my source: ---snip--- #include sys/types.h #include stdio.h #include stdlib.h /* malloc() */ #include stddef.h /* offsetof(...) */ #include unistd.h /* get?id() */ #include signal.h #include errno.h #if defined(__FreeBSD__) defined(DEBUG) extern char *malloc_options; /* Line 22 */ malloc_options = "JX"; /* Line 23 */ #endif ---snip--- The output of gcc: ---snip--- 23: warning: type defaults to `int' in declaration of `malloc_options' 23: conflicting types for `malloc_options' 22: previous declaration of `malloc_options' 23: warning: initialization makes integer from pointer without a cast 23: warning: data definition has no type or storage class ---snip--- The output of gcc -E: ---snip--- extern char *malloc_options; malloc_options = "JX"; ---snip--- Should I go to bed or is this a bug in FreeBSD? Bye, Alexander. -- 99% of lawyers give the rest a bad name. http://netchild.home.pages.de A.Leidinger+Home @ WJPServer.CS.Uni-SB.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug with malloc_options
hi, there! On Thu, 19 Aug 1999 [EMAIL PROTECTED] wrote: -current from ~3 days ago. from malloc(3): ---snip--- To specify in the source that a program does no return value checking on calls to these functions: extern char *malloc_options; malloc_options = "X"; ---snip--- my source: ---snip--- #include sys/types.h #include stdio.h #include stdlib.h /* malloc() */ #include stddef.h /* offsetof(...) */ #include unistd.h /* get?id() */ #include signal.h #include errno.h #if defined(__FreeBSD__) defined(DEBUG) extern char *malloc_options; /* Line 22 */ malloc_options = "JX"; /* Line 23 */ #endif ---snip--- The output of gcc: ---snip--- 23: warning: type defaults to `int' in declaration of `malloc_options' 23: conflicting types for `malloc_options' 22: previous declaration of `malloc_options' 23: warning: initialization makes integer from pointer without a cast 23: warning: data definition has no type or storage class ---snip--- The output of gcc -E: ---snip--- extern char *malloc_options; malloc_options = "JX"; ---snip--- Should I go to bed or is this a bug in FreeBSD? first. 'malloc_options = "JX";' should be be within function body /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
On Wed, Aug 18, 1999 at 07:39:04PM -0700, Amancio Hasty wrote: Or does tosha work with CAM? Tosha works fine with CAM, provided you built it post-CAM. There was also a change to CAM between 3.mumble and 3.mumble+1 which required a rebuild of tosha (but no source changes). Try building a fresh tosha, if it's older than your world. -- Matthew Hunt [EMAIL PROTECTED] * Science rules. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange notebook boot misbehaviour.
Hi all, I have a notebook (toshiba satellite pro 445) with WinNT and FreeBSD installed and discovered that when I'm booting FreeBSD directly from power-down state or rebooting after FreeBSD then it boots ok, but when I doing reboot from NT it hangs just before mounting / (probably "hang" is not quite correct term because it still responds to ctrl-alt-del). Any ideas of where I should look? Following is my dmesg (with hang point highlited): FreeBSD 4.0-CURRENT #0: Mon Aug 16 15:44:57 EEST 1999 root@home:/usr/src/sys/compile/NOTEBOOK Timecounter "i8254" frequency 1193135 Hz CPU: Pentium/P55C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 33685504 (32896K bytes) avail memory = 30208000 (29500K bytes) Preloaded elf kernel "kernel" at 0xc0294000. Intel Pentium detected, installing workaround for F00F bug npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: APM BIOS version 0102 apm: Code16 0xc00f, Data 0xc00f apm: Code entry 0xf91a, Idling CPU disabled, Management enabled apm: CS_limit=0x, DS_limit=0x apm: Engaged control enabled apm: found APM BIOS v1.2, connected at v1.2 apm: Slow Idling CPU disabled Add hook "default suspend" Add hook "default resume" pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 vga-pci0: Chips Technologies model 00e4 VGA-compatible display device at device 4.0 on pci0 chip1: NEC uPD 9210 USB controller irq 11 at device 11.0 on pci0 isa0: ISA bus on motherboard ata0 at port 0x1f0 irq 14 on isa0 ... try to identify the yamaha pcm0 at port 0x530 irq 5 drq 1 flags 0x10 on isa0 Add hook "pcm resume handler" Add hook "pcm suspend handler" mss_attach mss0 at 0x530 irq 5 dma 1:0 flags 0xc110 setting up yamaha registers set yamaha master volume to max fdc0: NEC 765 or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 ata1 at port 0x170 irq 15 on isa0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 Add hook "PS/2 mouse" psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus 0 PC-Card Intel 82365 (5 mem 2 I/O windows) Add hook "Intel 82365" Add hook "Intel 82365" pcic: controller irq 3 Add hook "Intel 82365" Add hook "Intel 82365" Initializing PC-card drivers: ed ad0: TOSHIBA MK1403MAV/D3.06 A ATA-? disk at ata0 as master ad0: 1376MB (2818368 sectors), 2796 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=-1 ad0: 16 secs/int, 0 depth queue, PIO mode atapi: piomode=3, dmamode=1, udmamode=-1 atapi: PIO transfer mode set acd0: TOSHIBA CD-ROM XM-1502BN/1001 CDROM drive at ata1 as master acd0: drive speed 1722KB/sec, 128KB cache acd0: supported read types: CD-R, CD-DA, packet track acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked changing root device to wd0s1a Card inserted, slot 1 ^ - Hangs after this message!!! APM ioctl: cmd = 0x20005005 called apm_event_enable() Received APM Event: PMEV_POWERSTATECHANGE -Max -- "We believe in the Power and the Might!" (Manowar, 1996) Maxim V. Sobolev, Financial Analyst, Vega International Capital Phone: +380-(44)-246-6396 Fax: +380-(44)-220-8715 E-mail: [EMAIL PROTECTED] ICQ: #42290709 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
This does not actually erase the data, so if you have used say 100MB you will only have 550MB left. You can actually erase the media using 'cdrecord blank=all', which takes a while. In my experience, this is not true. I have used blank=fast on a CDRW that has over 500 MB written, and then written another 500 MB without I think there's a little confusion here and I don't want to add to it. But... I thought it the case that a CDRW that is fully reformatted (taking 30 minutes; equivalent to blank=all?) can hold 650MB, while a CDRW that is quickly reformatted (to packet writing aka DirectCD-formatting; is this what blank=fast does?) can hold only about 500 MB. It doesn't matter how is on the disk before the quick format happens. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
As Amancio Hasty wrote ... Or does tosha work with CAM? It does for me... (3.2-stable). -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
As Bruce Albrecht wrote ... Matthew Dillon writes: And to head off another question: When you are recording to a CD-RW you can do a 'quick erase' of the media using 'cdrecord blank=fast'. This does not actually erase the data, so if you have used say 100MB you will only have 550MB left. You can actually erase the media using 'cdrecord blank=all', which takes a while. In my experience, this is not true. I have used blank=fast on a CDRW that has over 500 MB written, and then written another 500 MB without a problem. I have the same experience. Maybe someone into the physics of the media can explain what the pros-cons are as far as the media itself is concerned? Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
Matthew Hunt wrote... On Wed, Aug 18, 1999 at 07:39:04PM -0700, Amancio Hasty wrote: Or does tosha work with CAM? Tosha works fine with CAM, provided you built it post-CAM. There was also a change to CAM between 3.mumble and 3.mumble+1 which required a rebuild of tosha (but no source changes). Try building a fresh tosha, if it's older than your world. Also, if you're running -current, you'll have to recompile. Justin made some kernel changes on Monday that will require all userland applications be rebuilt. (you'll want to do a make world first, to make sure you've got the right headers installed before you rebuild various ports) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Panic at boot with -CURRENT (last 2-3 days)
Background: --- Work recently assigned me a Gateway GP7-500 (PIII-500mhz, 96M RAM) to replace my older 333mhz PII that's been running FreeBSD 3.2.. Of course, as my testing machine, I wanted to run FreeBSD 4.0-CURRENT on it, and installed the 19990806 snapshot without a problem, and then cvsupped it to -CURRENT. Problem: This was on 17AUG, my kernel panic'd, I just assumed I left something out, but then I saw that GENERIC panic'd as well, and has panic'd since 17AUG, and continues to do so with the -CURRENT snapshot of an hour ago. However, GENERIC from 19990806 works just fine. I decided that after 3 days of kernel panics that it's a real problem and not just some little -CURRENT breakage. I decided yesterday that maybe I need to make world first, so I did. No dice there. And an hour ago, I also rm -Rf'd /usr/src, cvsupped to -CURRENT, made world again, and attempted to rebuild the kernel. Boot Sequence: -- If you want to see dmesg.boot from the 4.0-19990806-CURRENT snapshot, it's at http://haloblack.org/misc/dmesg.boot FreeBSD 4.0-CURRENT #0: thu Aug 19 12:44:12 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC+DDB Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III (498.67-MHz 686-class CPU) Origin = "Genuine Intel" Id = 0x672 Stepping = 2 Features = blah blah blah real memory = 100663296 (98304K bytes) config di lnc0 config di le0 .. .. config q avail memory = 93708288 (91512K bytes) Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x58:0xbc28 stack pointer = 0x10:0xed4 frame pointer = 0x10:0xf20 code segment= base 0xc00f, limit 0x, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam kernel: type 9 trap, code=0 Stopped at 0xbc28: repeat, DDB? -- Med vanlig halsingar, thomas stromberg [TRS40/SM0VVW]: smtp([EMAIL PROTECTED]) systems guru / asst. is manager: http(www.afterthought.org) research triangle consultants, inc : pots(919.380.9771 x3210) http://www.rtci.com: fax(919.380.1727) FreeBSD: The Power to Serve! : icq(17468041) BeOS Developer ID: 18330 : efnet(Mithra) : "if you do nothing enough, something's bound to happen.." : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic at boot with -CURRENT (last 2-3 days)
See my earlier post today, it is due to the PnP probe. If you boot a kernel which is older than Mikes commit, you can boot the new kernel after a soft reboot... Poul-Henning In message [EMAIL PROTECTED], Thomas Stromberg writes: Background: --- Work recently assigned me a Gateway GP7-500 (PIII-500mhz, 96M RAM) to replace my older 333mhz PII that's been running FreeBSD 3.2.. Of course, as my testing machine, I wanted to run FreeBSD 4.0-CURRENT on it, and installed the 19990806 snapshot without a problem, and then cvsupped it to -CURRENT. Problem: This was on 17AUG, my kernel panic'd, I just assumed I left something out, but then I saw that GENERIC panic'd as well, and has panic'd since 17AUG, and continues to do so with the -CURRENT snapshot of an hour ago. However, GENERIC from 19990806 works just fine. I decided that after 3 days of kernel panics that it's a real problem and not just some little -CURRENT breakage. I decided yesterday that maybe I need to make world first, so I did. No dice there. And an hour ago, I also rm -Rf'd /usr/src, cvsupped to -CURRENT, made world again, and attempted to rebuild the kernel. Boot Sequence: -- If you want to see dmesg.boot from the 4.0-19990806-CURRENT snapshot, it's at http://haloblack.org/misc/dmesg.boot FreeBSD 4.0-CURRENT #0: thu Aug 19 12:44:12 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC+DDB Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III (498.67-MHz 686-class CPU) Origin = "Genuine Intel" Id = 0x672 Stepping = 2 Features = blah blah blah real memory = 100663296 (98304K bytes) config di lnc0 config di le0 .. .. config q avail memory = 93708288 (91512K bytes) Fatal trap 9: general protection fault while in kernel mode instruction pointer= 0x58:0xbc28 stack pointer = 0x10:0xed4 frame pointer = 0x10:0xf20 code segment = base 0xc00f, limit 0x, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process= Idle interrupt mask = net tty bio cam kernel: type 9 trap, code=0 Stopped at 0xbc28: repeat, DDB? -- Med vanlig halsingar, thomas stromberg [TRS40/SM0VVW]: smtp([EMAIL PROTECTED]) systems guru / asst. is manager: http(www.afterthought.org) research triangle consultants, inc : pots(919.380.9771 x3210) http://www.rtci.com: fax(919.380.1727) FreeBSD: The Power to Serve! : icq(17468041) BeOS Developer ID: 18330 : efnet(Mithra) : "if you do nothing enough, something's bound to happen.." : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
:On Thu, Aug 19, 1999 at 07:50:13AM -0700, Peter Wemm wrote:
: peter 1999/08/19 07:50:13 PDT
:
: Modified files:
: sys/nfs nfsm_subs.h xdr_subs.h
: Log:
: Convert all the nfs macros to do { blah } while (0) to ensure it
: works correctly in if/else etc. egcs had probably picked up most of the
: problems here before with "ambiguous braces" etc, but this should
: increase the robustness a bit. Based on an idea from Eivind Eklund.
:
:When I tested this, I got significant binary changes after changing
:the macros to be . Writing a couple of test programs, I was not able
:to get binary changes without actual semantic changes - the optimizer
:optimize away do { ... } while(0); just fine. I didn't have any
:testbed for NFS, which was why I didn't commit similar changes myself.
:
:Interpretation: NFS is likely to be different now than it was before
:these commits. This hopefully mean less bugs, but we might also have
:had bugs cancelling each other and 'mystery fixes' that no longer
:work. If you get strange effects in NFS in the upcoming time, you
:might try flipping this commit.
:
:I still think the change is a good and necessary one.
:
:Eivind.
The compiler optimizes differently, that's all. The same thing happened
when we fixed the macros in vm_map.h. In that case we also found a bug
in i386/include/globals.h --- the inline assembly macros are missing
the "memory" side effect specification and the code was trying to optimize
global references across subroutine calls! I'll send Luoqi another email.
In the case of the NFS stuff, the changes have been pretty well tested
so I think we are in the clear.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
As Amancio Hasty wrote ... Or does tosha work with CAM? It does for me... (3.2-stable). Hi, I think is that tosha does not know how to read audio tracks with my Yamaha cd recorder. The Yamaha have a slightly weird way of reading the audio tracks . I have cdda2wav as an example on how to read audio tracks on Yamaha CDs. The only gotcha is that is for linux so I will have to translate the linux scsi commands to CAM. Writing audio tracks is no problem with "cdrecord". Cheeers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
Today Amancio Hasty wrote: I think is that tosha does not know how to read audio tracks with my Yamaha cd recorder. The Yamaha have a slightly weird way of reading the audio tracks . I have cdda2wav as an example on how to read audio tracks on Yamaha CDs. The only gotcha is that is for linux so I will have to translate the linux scsi commands to CAM. cdrecord-1.8a22 includes cdda2wav, no translation necessary. :) -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
Hi!
I am totally full of joy to be able to read audio CDs in FreeBSD .
pwd
/mnt/ports/sysutils/cdrecord/work/cdrecord-1.8/cdda2wav/OBJ/i386-freebsd-cc
{root} ./cdda2wav -D0,1,0 -B
266240 bytes buffer memory requested, 4 buffers, 27 sectors
Read TOC CD Text failed (probably not supported).
#Cdda2wav version schily0.4_freebsd_4.0-current_i386_i386 real time sched.
soundcard support
AUDIOtrack pre-emphasis copy-permitted tracktype channels
1-12 no no audio2
Table of Contents: total tracks:12, (total time 55:27.43)
1.( 4:37.09), 2.( 4:38.97), 3.( 5:17.63), 4.( 3:50.24), 5.( 4:11.23)
6.( 5:28.77), 7.( 4:40.96), 8.( 3:55.51), 9.( 4:57.36), 10.( 4:45.71)
11.( 3:40.87), 12.( 5:21.09),
Table of Contents: starting sectors
1.( 0), 2.( 20782), 3.( 41705), 4.( 65527), 5.( 82795)
6.( 101637), 7.( 126295), 8.( 147367), 9.( 165030), 10.( 187332)
11.( 208760), 12.( 225325), lead-out( 249407)
CDDB discid: 0xb80cfd0c
Tnks A Lot!
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
On Thu, 19 Aug 1999, Matthew Dillon wrote:
:On Thu, Aug 19, 1999 at 07:50:13AM -0700, Peter Wemm wrote:
: peter 1999/08/19 07:50:13 PDT
:
: Modified files:
: sys/nfs nfsm_subs.h xdr_subs.h
: Log:
: Convert all the nfs macros to do { blah } while (0) to ensure it
: works correctly in if/else etc. egcs had probably picked up most of the
: problems here before with "ambiguous braces" etc, but this should
: increase the robustness a bit. Based on an idea from Eivind Eklund.
:
:When I tested this, I got significant binary changes after changing
:the macros to be . Writing a couple of test programs, I was not able
:to get binary changes without actual semantic changes - the optimizer
:optimize away do { ... } while(0); just fine. I didn't have any
:testbed for NFS, which was why I didn't commit similar changes myself.
:
:Interpretation: NFS is likely to be different now than it was before
:these commits. This hopefully mean less bugs, but we might also have
:had bugs cancelling each other and 'mystery fixes' that no longer
:work. If you get strange effects in NFS in the upcoming time, you
:might try flipping this commit.
:
:I still think the change is a good and necessary one.
:
:Eivind.
The compiler optimizes differently, that's all. The same thing happened
when we fixed the macros in vm_map.h. In that case we also found a bug
in i386/include/globals.h --- the inline assembly macros are missing
the "memory" side effect specification and the code was trying to optimize
global references across subroutine calls! I'll send Luoqi another email.
In the case of the NFS stuff, the changes have been pretty well tested
so I think we are in the clear.
On a somewhat similar note, what do you think about converting a lot
of the NFS macros to functions, yes i know it will be difficult, but
there is so much forced inlining it just seems like it would reduce
the codesize signifigantly and play nicer with the CPU cache.
It would also make the code a lot more readable.
Worthwhile exercise?
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
systems administrator and programmer
Wintelcom - http://www.wintelcom.net/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
Mike Smith writes: I will be converting all users of at_shutdown in the kernel to the new mechanism, but it's of some concern to me that there may be external code using the old at_shutdown* interfaces that may benefit from a compatibility interface (which could be done relatively easily). Is there significant interest in having this implemented? We (ie, Whistle) has some "external code" that uses at_shutdown but it would be trivial to update it for the new interface, so I say go ahead! This sounds like a good change. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
Matthew Dillon [EMAIL PROTECTED] wrote: Finally, when you pipe mkisofs to cdrecord directly it is possible to fall behind enough that an error may occur. The CD writer needs a continuous stream. There are two solution to this if it occurs: First, write at a slower rate (speed=1 or speed=2 rather then the default 4), or you need to mkisofs to an image file and then cdrecord from the image file. Another possibility, if you have the RAM, is to use the team(1) program (it's in the ports) to buffer the data as it goes to the burner. You basically put it into the pipeline between mkisofs and cdrecord, and it buffers up to 5MB in memory (default, adjustable). Of course, you've got to have enough RAM to not go into swap during the operation. It's a very nice program, and I've been told that, with enough memory (32-64MB), you can be running X11 and compiling programs while the CD is burning (this is with a 2X burner, though). -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
: global references across subroutine calls! I'll send Luoqi another email. : : In the case of the NFS stuff, the changes have been pretty well tested : so I think we are in the clear. : :On a somewhat similar note, what do you think about converting a lot :of the NFS macros to functions, yes i know it will be difficult, but :there is so much forced inlining it just seems like it would reduce :the codesize signifigantly and play nicer with the CPU cache. : :It would also make the code a lot more readable. : :Worthwhile exercise? : :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Well, the issue with converting many of the macros to inline functions is with the embedded goto's and references to variables defined outside the macros. Converting them to functions would basically require rewriting a huge chunk of NFS code. This is one of those "If it ain't broke, don't fix it" scenarios, I'm afraid. It would take too long to redo it all (and remember, I'm the guy who usually *likes* rewriting code!). As much as I would like to make NFS more readable, it just isn't worth the effort. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
: Another possibility, if you have the RAM, is to use the team(1) :program (it's in the ports) to buffer the data as it goes to the burner. :You basically put it into the pipeline between mkisofs and cdrecord, and :it buffers up to 5MB in memory (default, adjustable). Of course, you've :got to have enough RAM to not go into swap during the operation. It's a :very nice program, and I've been told that, with enough memory :(32-64MB), you can be running X11 and compiling programs while the CD is :burning (this is with a 2X burner, though). : :-- : Darryl Okahata : [EMAIL PROTECTED] It should be noted that the 'cdrecord' program implements a FIFO itself, and you can specify the size. The default is 2MB. cdrecord uses a shared memory segment and forks so the process buffering the data is made independant of the buffer draining it. Modern CD writers usually have 1-2MB of buffer internally. The newer Yamahas, for example, have 2MB. So right off the bat we have around 4MB. Still, when you are writing at 600KB/sec it is possible to get behind if the filesystem you are building has lots of small files. Apart from writing the mkisofs output to a file, the easiest solution is to tell cdrecord to burn at a slower rate - e.g. 1x or 2x instead of 4x or 6x. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon writes: :On a somewhat similar note, what do you think about converting a lot :of the NFS macros to functions, yes i know it will be difficult, but :there is so much forced inlining it just seems like it would reduce :the codesize signifigantly and play nicer with the CPU cache. : :It would also make the code a lot more readable. : :Worthwhile exercise? : :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Well, the issue with converting many of the macros to inline functions is with the embedded goto's and references to variables defined outside the macros. Converting them to functions would basically require rewriting a huge chunk of NFS code. This is one of those "If it ain't broke, don't fix it" scenarios, I'm afraid. It would take too long to redo it all (and remember, I'm the guy who usually *likes* rewriting code!). As much as I would like to make NFS more readable, it just isn't worth the effort. It still might be a "worthwhile exercise", if your goal is simply to increase your understanding of the NFS code. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
Please Matt "burn" a summary document ... (Gosh I have been burning too many CDs 8) ) -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _KPOSIX_PRIORITY_SCHEDULING and cdda2wav
Arno J. Klaassen wrote: Hi, just a quick note: on a -current of this morning I recompiled the cdrecord port; kernel compiled with the options: options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L launching cdda2wav immediately panics with: panic: setrunqueue: invalid rtprio type outcommenting _KPOSIX_PRIORITY_SCHEDULING and _KPOSIX_VERSION=199309L makes everything work again I think I've fixed this (and a few other things), can you please re-check after updateing to current kernel source please? You need at least rev 1.3 of kern/kern_switch.c. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
there was external code at TRW but I don't know if it is still in use.. We have uses of it here at whistle too. (that's why I wrote it..) but I guess I can handle them... why the change? If you re-aranged the arguments you'd have EVENTHANDLER_REGISTER == at_shutdown_pri. :-) what are the selectabel (available) event queues? On Thu, 19 Aug 1999, Mike Smith wrote: That's right, systems will never shut down. 8) Seriously though, I'm in the process of replacing a number of the ad-hoc event handler callout lists in the kernel (most notably the at_shutdown and apm* lists) with a generic implementation. The upshot of this is that at_shutdown will go away. The old calls: at_shutdown(func, arg, queue) at_shutdown_pri(func, arg, queue, priority) will be replaced with EVENTHANDLER_REGISTER(queue, func, arg, priority) Due to the way the event handler works, this means that event handler functions which were originally void func(int howto, void *arg) will become void func(void *arg, int howto) This is unfortunate but more or less unavoidable. I will be converting all users of at_shutdown in the kernel to the new mechanism, but it's of some concern to me that there may be external code using the old at_shutdown* interfaces that may benefit from a compatibility interface (which could be done relatively easily). Is there significant interest in having this implemented? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
As Amancio Hasty wrote ... As Amancio Hasty wrote ... Or does tosha work with CAM? It does for me... (3.2-stable). To qualify that a bit more: it works on my Toshiba XM-5701TA (surprise..) and also on my Philips CDD-3600 CDRW drive. I think is that tosha does not know how to read audio tracks with my Yamaha cd recorder. The Yamaha have a slightly weird way of reading the audio tracks . I have cdda2wav as an example on how to read audio tracks on Yamaha CDs. The only gotcha is that is for linux so I will have to translate the linux scsi commands to CAM. Maybe a check on the xmcd source code is of interest. It has a number of vendor-unique support files with interesting info. Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
Hi, I am all set . cdrecord-1.8a22 includes cdda2wav as [EMAIL PROTECTED] pointed out and it does work with my Yamaha cd recorder . In summary using FreeBSD-current of about two weeks ago , I am now able to : 1. to burn iso 9660 with mkisofs + cdrecord 2. extract CD audio tracks with cdda2wav 3. Burn audio cds with cdrecord . No other external program is necessary to burn the Audio CD. A bit more work is needed to make the creation of CDs on FreeBSD user friendly and the responsibilty for that falls more on the authors of the CD tools. With FreeBSD-current as of this morning, [EMAIL PROTECTED] (Arno J. Klaassen just reported having problems with cdd2wav panicking the system with: launching cdda2wav immediately panics with: panic: setrunqueue: invalid rtprio type Cheers As Amancio Hasty wrote ... As Amancio Hasty wrote ... Or does tosha work with CAM? It does for me... (3.2-stable). To qualify that a bit more: it works on my Toshiba XM-5701TA (surprise..) and also on my Philips CDD-3600 CDRW drive. I think is that tosha does not know how to read audio tracks with my Yamaha cd recorder. The Yamaha have a slightly weird way of reading the audio tracks . I have cdda2wav as an example on how to read audio tracks on Yamaha CDs. The only gotcha is that is for linux so I will have to translate the linux scsi commands to CAM. Maybe a check on the xmcd source code is of interest. It has a number of vendor-unique support files with interesting info. Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic at boot with -CURRENT (last 2-3 days)
This appears to be due to our PnP BIOS invocation not being sufficiently bug-compatible with some BIOSsen. I'm going to need to do some more work on this, and if you have time I'd like to get you involved in the testing process. Meanwhile I'll be disabling the PnP BIOS scan which should get you back on the rails. Boot Sequence: -- If you want to see dmesg.boot from the 4.0-19990806-CURRENT snapshot, it's at http://haloblack.org/misc/dmesg.boot FreeBSD 4.0-CURRENT #0: thu Aug 19 12:44:12 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC+DDB Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III (498.67-MHz 686-class CPU) Origin = "Genuine Intel" Id = 0x672 Stepping = 2 Features = blah blah blah real memory = 100663296 (98304K bytes) config di lnc0 config di le0 .. .. config q avail memory = 93708288 (91512K bytes) Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x58:0xbc28 stack pointer = 0x10:0xed4 frame pointer = 0x10:0xf20 code segment = base 0xc00f, limit 0x, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask= net tty bio cam kernel: type 9 trap, code=0 Stopped at0xbc28: repeat, DDB? -- Med vanlig halsingar, thomas stromberg [TRS40/SM0VVW]: smtp([EMAIL PROTECTED]) systems guru / asst. is manager: http(www.afterthought.org) research triangle consultants, inc : pots(919.380.9771 x3210) http://www.rtci.com: fax(919.380.1727) FreeBSD: The Power to Serve! : icq(17468041) BeOS Developer ID: 18330 : efnet(Mithra) : "if you do nothing enough, something's bound to happen.." : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
there was external code at TRW but I don't know if it is still in use..
We have uses of it here at whistle too. (that's why I wrote it..)
but I guess I can handle them...
why the change?
If you re-aranged the arguments you'd have EVENTHANDLER_REGISTER ==
at_shutdown_pri.
It has to do with the way that I deal with arbitrary arguments to the
called-out functions, in order to save all the crap that the caller
might have to perform with constructing an argument structure and then
passing a pointer to it.
It's easier to explain like this (backslashes elided):
#define EVENTHANDLER_DECLARE(name, type)
struct eventhandler_entry_ ## name
{
struct eventhandler_entry ee;
typeeh_func;
};
#define EVENTHANDLER_INVOKE(name, args...)
{
struct eventhandler_list *el;
struct eventhandler_entry *ep;
if ((el = eventhandler_find_list(#name)) != NULL) {
for (ep = TAILQ_FIRST((el-el_entries));
ep != NULL;
ep = TAILQ_NEXT(ep, ee_link)) {
((struct eventhandler_entry_ ## name *)ep)-
eh_func(ep-ee_arg , ## args);
}
}
}
ie. the called-out function isn't forced to be of any particular type
other than that it can't return anything and it's first argument must
be void *. Unfortunately, the way that macro varargs works makes it
hard to put the variable arguments _first_ (and I wouldn't want to do
that since it would make calling out to a real varargs function
impossible).
what are the selectabel (available) event queues?
That's one of the nicer features of this mechanism; you can create them
more or less on the fly. There are actually two implementations; one
optimised for speed which requires the queue to be present in the linked
objects (effectively it does the name-list translation using the
linker), the other optimised for convenience which just requires the
queue to be defined somewhere in a shared header (to get the queue entry
type into scope). This latter mechanism means that eg. I can say
EVENTHANDLER_REGISTER(pwrmgmt_suspend, foosuspend, foo_softc, 0)
from within a driver, even if the code that's going to invoke this
handler hasn't been loaded yet. By tying events to named queues rather
than to implementations, it helps soften the boundaries - in this
example the caller that eventually invokes the pwrmgmt_suspend handlers
will initially be APM, but it may later be ACPI, or something totally
different on eg. the Alpha, or an OpenFirmware system.
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ [EMAIL PROTECTED]
\\-- Joseph Merrick \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Weird X problem
very weird X problem, I can only load an X server if I have a ppp connection upi and running... Xfree86 3.4, -CURRENT(made world today) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
At 10:34 am -0700 19/8/99, Amancio Hasty wrote: As Amancio Hasty wrote ... Or does tosha work with CAM? It does for me... (3.2-stable). Hi, I think is that tosha does not know how to read audio tracks with my Yamaha cd recorder. The Yamaha have a slightly weird way of reading the audio tracks[etc] tosha works here on a Yamaha and -current; but I did find that you need one more (or less) byteswap than the various documentation would lead me to believe. I'm not sure which doc is wrong though... -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange notebook boot misbehaviour.
On Thursday, 19 August 1999 at 17:34:28 +0300, Maxim Sobolev wrote: Hi all, I have a notebook (toshiba satellite pro 445) with WinNT and FreeBSD installed and discovered that when I'm booting FreeBSD directly from power-down state or rebooting after FreeBSD then it boots ok, but when I doing reboot from NT it hangs just before mounting / (probably "hang" is not quite correct term because it still responds to ctrl-alt-del). Any ideas of where I should look? Following is my dmesg (with hang point highlited): [snip] acd0: Medium: CD-ROM 120mm data disc loaded, unlocked changing root device to wd0s1a Card inserted, slot 1 ^ - Hangs after this message!!! On Thursday, 19 August 1999 at 14:55:15 -0500, Matt Crawford wrote: On the Sony 505 mailing list, this was noted and said to be due to Windows leaving the ethernet chip in some APM-related suspended state. Interesting. I see similar behaviour. It also happens in the opposite direction: if I reboot from FreeBSD and select Microsoft, Microsoft hangs during boot. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
The Matrix screensaver
Hi, This is my poor attempt at reproducing the screens on the movie... Sure, there is much room for improvement, and the whole thing would look cool in VESA, if someone has more spare time... http://www.freebsd.org/~abial/matrix.tgz Unpack it in /sys/modules/syscons. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cc -O broken in -current for Alpha KLDs
On Thu, 19 Aug 1999, Andrew Gallatin wrote: I do most of my development on alphas I just turned some local code into a loadable kernel module. It works fine when compiled into the kernel statically, but fails miserably when loaded into an alpha kernel as a module. This alpha is running -current from monday or so. After a day or so of debugging, I decided to run it on an x86 -- it ran just fine. I've narrowed the problem down to one involving optimization and have extracted a simple, reproducable test case. When the test module is loaded without optimization (CFLAGS += -g -O0), it prints the following (which is correct): It looks like we aren't handling the relocations correctly. When I get a chance, I will try to look at it. If you want to have another look, the code at fault is probably in alpha/alpha/elf_machdep.c and you can get a list of relocations in the module with 'objdump --dynamic-reloc foo.ko'. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird X problem
Tomer Weller wrote: very weird X problem, I can only load an X server if I have a ppp connection upi and running... Xfree86 3.4, -CURRENT(made world today) You might want to check your resolv.conf, having an ip that you cant access in there could be causing some things to load extremely slowly as they have to wait for a query to timeout or something - running ppp obviously lets you access your ISP's name server providing you have resolv.conf setup for that ip - you could always run your own caching only name server for that and chuck the boxes own ip into resolv.conf. Mebe upgrading /etc to be inline with -CURRENT you overwrote a few name resolution related files.. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
