Re: USB no proper work
19.08.2013 22:57, Hans Petter Selasky пишет: > On 08/19/13 21:54, Alexander Panyushkin wrote: >> 18.08.2013 01:04, Hans Petter Selasky пишет: >>> On 08/17/13 23:55, Alexander Panyushkin wrote: >>>> 17.08.2013 19:41, Alexander Motin пишет: >>>>> On 17.08.2013 09:22, Hans Petter Selasky wrote: >>> >>>> >>>> On USB device FAT-32 file system. When I removed flash drive, the >>>> file >>>> system has been unmounted. >>> >>> Hi, >>> >>> The problem might be in the GELI module then. Did you test that >>> Alexander ? >>> >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli >>> created. >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 >>> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software >>> >>> Hint: You can set the following knob to disable the USB waiting at >>> reboot. >>> >>> hw.usb.no_shutdown_wait=1 >>> >> If set hw.usb.no_shutdown_wait = 1 >> Reboot successful, but if detach and attach again, USB device not >> detecting. > > This test is an indication that the USB stack is waiting for the CAM > layer to finish detaching its clients. Maybe you can turn on cam > debugging to figure out who is leaking a ref. Alexander Motin knows how. > > --HPS > Hi This is debug information ugen3.4: at usbus3 umass0: on usbus3 da0 at umass-sim0 bus 0 scbus8 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7580MB (15523840 512 byte sectors: 255H 63S/T 966C) da0: quirks=0x2 (noperiph:umass-sim0:0:0:0): debugging flags now 1 (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (da0:umass-sim0:0:0:0): Error 22, Unret
i915kms.ko not loading
*uname -a* FreeBSD iskander.advancedhosters.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue Aug 27 23:53:04 EEST 2013 r...@iskander.advancedhosters.com:/usr/obj/usr/src/sys/Kernel amd64 in *make.conf* X_WINDOW_SYSTEM=xorg WITH_NEW_XORG=true WITH_KMS=true xorg-* ports rebuild After *Xorg -configure* system is going to reboot problem in load module i915kms.ko if *kldload i915kms.ko* system is going to reboot *pciconf -lvb* vgapci0@pci0:0:2:0: class=0x03 card=0x844d1043 chip=0x01528086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xf780, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0xf000, size 64, enabled error in */var/log/messages* Aug 28 16:09:26 iskander dbus[1185]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper) Aug 28 16:09:26 iskander dbus[1185]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) Aug 28 16:09:26 iskander dbus[1185]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Aug 28 16:09:26 iskander dbus[1185]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Aug 28 16:09:26 iskander console-kit-daemon[1206]: WARNING: kvm_getenvv failed: How to fix this problem? ___ 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: i915kms.ko not loading
29.08.2013 12:24, Jean-Sébastien Pédron пишет: > On 28.08.2013 21:42, Alexander Panyushkin wrote: >> problem in load module i915kms.ko >> if *kldload i915kms.ko* system is going to reboot > Are you able to obtain a kernel core dump? They're saved in /var/crash > during the next boot. > > If you have one, could you please send the last core.txt? This file > contains a trace of the crash, the state of the computer at the time of > the crash and dmesg's output. > in sysctl: kern.coredump: 1 kern.corefile: /var/coredumps/%U.%N.%P.core but coredump files not created. How to set for creating core files? ___ 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: i915kms.ko not loading
29.08.2013 18:39, Jean-Sébastien Pédron пишет: > On 29.08.2013 17:35, Alexander wrote: >> in sysctl: >> kern.coredump: 1 >> kern.corefile: /var/coredumps/%U.%N.%P.core >> >> but coredump files not created. >> >> How to set for creating core files? > You must add the following line to your /etc/rc.conf: > dumpdev="AUTO" > > Also add this line to your /etc/sysctl.conf: > debug.debugger_on_panic=0 > > The core dump is written to the swap device when the crash occurs. > During the next boot, it's written to the specified kern.corefile path. > I have swapinfo on zfs partition swapinfo -h Device512-blocks UsedAvail Capacity /dev/zvol/zroot/swap 16777216 0B 8.0G 0% ls -la /dev/zvol/zroot/swap crw-r- 1 root operator 0x8b 29 авг 23:27 /dev/zvol/zroot/swap in /etc/rc.conf dumpdev="AUTO" dumpon_enable="YES" in /etc/sysctl.conf # CoreDump kern.coredump=1 kern.corefile=/var/coredumps/%U.%N.%P.core kern.sugid_coredump=1 When system booting, on console No suitable dump device was found. During the next boot, coredump not created. :( ___ 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: i915kms.ko not loading
30.08.2013 20:11, John-Mark Gurney пишет: > Jean-Sbastien Pdron wrote this message on Fri, Aug 30, 2013 at 15:50 +0200: >> On 29.08.2013 19:51, Alexander wrote: >>> I have swapinfo on zfs partition >> I always heard that swap on ZFS is asking for trouble, because ZFS loves >> to use memory. So when the system is using swap space, ZFS has more work >> and therefore wants more RAM, whici is unavailable. >> >> Furthermore, I'm not sure if kernel core dumping on swap on ZFS is >> supported at all. The following discussion on the forum suggests it's >> not possible: >> http://forums.freebsd.org/showthread.php?t=37958 >> >> Can you plug another driver and setup swap on it? A USB drive/key should >> be fine. > You don't need to use a swap device to dump to it... You can just set > up the USB drive as the dump device only... > Hi I created the coredump files after create swap on new disk. But size very large. Where can I upload these files. ls -lah /var/crash ... -rw-r--r-- 1 root wheel 2B Aug 30 20:27 bounds -rw--- 1 root wheel 480B Aug 30 20:27 info.0 lrwxr-xr-x 1 root wheel 6B Aug 30 20:27 info.last -> info.0 -r--r--r-- 1 root wheel 5B Jul 19 2010 minfree -rw--- 1 root wheel 450M Aug 30 20:27 vmcore.0 lrwxr-xr-x 1 root wheel 8B Aug 30 20:27 vmcore.last -> vmcore.0 ___ 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: i915kms.ko not loading
30.08.2013 22:32, Jean-Sébastien Pédron пишет: > reat! Could you please run: > kgdb /boot/kernel/kernel /var/crash/vmcore.0 > > And, at gdb prompt: > bt > > Then send the whole output (from the moment you run "kgdb" to the end > of "bt" output) and your /var/log/messages file? Hi kgdb /boot/kernel/kernel /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0x80458f75 in doadump () (kgdb) bt #0 0x80458f75 in doadump () #1 0x80458d80 in kern_reboot () #2 0x80459107 in panic () #3 0x8062886a in trap_fatal () #4 0x8062851e in trap () #5 0x806120a3 in calltrap () #6 0x81040276 in ?? () #7 0xfe011f2da3a0 in ?? () #8 0x802f4f6e in acpi_pci_read_ivar () #9 0x8102ba4f in ?? () #10 0xf80005a717c0 in ?? () #11 0xf8012f89b000 in ?? () #12 0xfed100010005 in ?? () #13 0xfe000a71f000 in ?? () #14 0xfe011f2da470 in ?? () #15 0x0048 in ?? () #16 0xfe000a71f000 in ?? () #17 0x80462700 in sysctl_move_oid () #18 0x80319070 in drm_attach () #19 0x804837e6 in device_attach () #20 0x80484c09 in bus_generic_driver_added () #21 0x804819ea in devclass_driver_added () #22 0x8048194c in devclass_add_driver () #23 0x8044663b in module_register_init () #24 0x8043c835 in linker_load_module () #25 0x8043d9f7 in kern_kldload () #26 0x8043dbcb in sys_kldload () #27 0x80628ea3 in amd64_syscall () #28 0x8061238b in Xfast_syscall () #29 0x0008027d0dfa in ?? () Previous frame inner to this frame (corrupt stack?) ___ 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: i915kms.ko not loading
02.09.2013 14:42, Jean-Sébastien Pédron пишет: > On 02.09.2013 12:00, Alexander wrote: >> (...) >> #17 0x80462700 in sysctl_move_oid () >> #18 0x80319070 in drm_attach () >> (...) > The kernel is missing debug symbols. Could you please rebuild your > kernel with the following option: > makeoptions DEBUG=-g > (also found in GENERIC) > > Then reproduce the problem and send the output of kgdb again? > > Thanks! > I rebuild the kernel with debug-g kgdb /boot/kernel/kernel /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: drmn0: on vgapci0 iicbus0: on iicbb0 addr 0xff iicsmb0: on iicbus0 smbus1: on iicsmb0 smb1: on smbus1 iic0: on iicbus0 iicsmb1: on iicbus1 smbus2: on iicsmb1 smb2: on smbus2 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iicsmb2: on iicbus2 smbus3: on iicsmb2 smb3: on smbus3 iic2: on iicbus2 iicsmb3: on iicbus3 smbus4: on iicsmb3 smb4: on smbus4 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iicsmb4: on iicbus4 smbus5: on iicsmb4 smb5: on smbus5 iic4: on iicbus4 iicsmb5: on iicbus5 smbus6: on iicsmb5 smb6: on smbus6 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iicsmb6: on iicbus6 smbus7: on iicsmb6 smb7: on smbus7 iic6: on iicbus6 iicsmb7: on iicbus7 smbus8: on iicsmb7 smb8: on smbus8 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iicsmb8: on iicbus8 smbus9: on iicsmb8 smb9: on smbus9 iic8: on iicbus8 iicsmb9: on iicbus9 smbus10: on iicsmb9 smb10: on smbus10 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iicsmb10: on iicbus10 smbus11: on iicsmb10 smb11: on smbus11 iic10: on iicbus10 iicsmb11: on iicbus11 smbus12: on iicsmb11 smb12: on smbus12 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iicsmb12: on iicbus12 smbus13: on iicsmb12 smb13: on smbus13 iic12: on iicbus12 iicsmb13: on iicbus13 smbus14: on iicsmb13 smb14: on smbus14 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iicsmb14: on iicbus14 smbus15: on iicsmb14 smb15: on smbus15 iic14: on iicbus14 iicsmb15: on iicbus15 smbus16: on iicsmb15 smb16: on smbus16 iic15: on iicbus15 Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer= 0x20:0x810402a6 stack pointer= 0x28:0xfe011f2f8360 frame pointer= 0x28:0xfe011f2f83e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process= 1408 (kldload) trap number= 9 panic: general protection fault cpuid = 2 Uptime: 1m30s Dumping 449 out of 7118 MB:..4%..11%..22%..33%..43%..54%..61%..72%..82%..93% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/if_re.ko.symbols...done. Loaded symbols for /boot/kernel/if_re.ko.symbols Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. Loaded symbols for /boot/kernel/snd_hda.ko.symbols Reading symbols from /boot/kernel/umodem.ko.symbols...done. Loaded symbols for /boot/kernel/umodem.ko.symbols Reading symbols from /boot/kernel/ucom.ko.symbols...done. Loaded symbols for /boot/kernel/ucom.ko.symbols Reading symbols from /boot/kernel/u3g.ko.symbols...done. Loaded symbols for /boot/kernel/u3g.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/fuse.ko.symbols...done. Loaded symbols for /boot/kernel/fuse.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ether.ko.symbols Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for
Re: i915kms.ko not loading
04.09.2013 18:58, John Baldwin wrote: > On Wednesday, September 04, 2013 11:01:03 am Alexander wrote: >> 02.09.2013 14:42, Jean-Sébastien Pédron пишет: >>> On 02.09.2013 12:00, Alexander wrote: >>>> (...) >>>> #17 0x80462700 in sysctl_move_oid () >>>> #18 0x80319070 in drm_attach () >>>> (...) >>> The kernel is missing debug symbols. Could you please rebuild your >>> kernel with the following option: >>> makeoptions DEBUG=-g >>> (also found in GENERIC) >>> >>> Then reproduce the problem and send the output of kgdb again? >>> >>> Thanks! >>> >> I rebuild the kernel with debug-g >> >> kgdb /boot/kernel/kernel /var/crash/vmcore.0 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> drmn0: on vgapci0 >> iicbus0: on iicbb0 addr 0xff >> iicsmb0: on iicbus0 >> smbus1: on iicsmb0 >> smb1: on smbus1 >> iic0: on iicbus0 >> iicsmb1: on iicbus1 >> smbus2: on iicsmb1 >> smb2: on smbus2 >> iic1: on iicbus1 >> iicbus2: on iicbb1 addr 0xff >> iicsmb2: on iicbus2 >> smbus3: on iicsmb2 >> smb3: on smbus3 >> iic2: on iicbus2 >> iicsmb3: on iicbus3 >> smbus4: on iicsmb3 >> smb4: on smbus4 >> iic3: on iicbus3 >> iicbus4: on iicbb2 addr 0xff >> iicsmb4: on iicbus4 >> smbus5: on iicsmb4 >> smb5: on smbus5 >> iic4: on iicbus4 >> iicsmb5: on iicbus5 >> smbus6: on iicsmb5 >> smb6: on smbus6 >> iic5: on iicbus5 >> iicbus6: on iicbb3 addr 0xff >> iicsmb6: on iicbus6 >> smbus7: on iicsmb6 >> smb7: on smbus7 >> iic6: on iicbus6 >> iicsmb7: on iicbus7 >> smbus8: on iicsmb7 >> smb8: on smbus8 >> iic7: on iicbus7 >> iicbus8: on iicbb4 addr 0xff >> iicsmb8: on iicbus8 >> smbus9: on iicsmb8 >> smb9: on smbus9 >> iic8: on iicbus8 >> iicsmb9: on iicbus9 >> smbus10: on iicsmb9 >> smb10: on smbus10 >> iic9: on iicbus9 >> iicbus10: on iicbb5 addr 0xff >> iicsmb10: on iicbus10 >> smbus11: on iicsmb10 >> smb11: on smbus11 >> iic10: on iicbus10 >> iicsmb11: on iicbus11 >> smbus12: on iicsmb11 >> smb12: on smbus12 >> iic11: on iicbus11 >> iicbus12: on iicbb6 addr 0xff >> iicsmb12: on iicbus12 >> smbus13: on iicsmb12 >> smb13: on smbus13 >> iic12: on iicbus12 >> iicsmb13: on iicbus13 >> smbus14: on iicsmb13 >> smb14: on smbus14 >> iic13: on iicbus13 >> iicbus14: on iicbb7 addr 0xff >> iicsmb14: on iicbus14 >> smbus15: on iicsmb14 >> smb15: on smbus15 >> iic14: on iicbus14 >> iicsmb15: on iicbus15 >> smbus16: on iicsmb15 >> smb16: on smbus16 >> iic15: on iicbus15 >> >> >> Fatal trap 9: general protection fault while in kernel mode >> cpuid = 2; apic id = 02 >> instruction pointer= 0x20:0x810402a6 >> stack pointer= 0x28:0xfe011f2f8360 >> frame pointer= 0x28:0xfe011f2f83e0 >> code segment= base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags= interrupt enabled, resume, IOPL = 0 >> current process= 1408 (kldload) >> trap number= 9 >> panic: general protection fault >> cpuid = 2 >> Uptime: 1m30s >> Dumping 449 out of 7118 MB:..4%..11%..22%..33%..43%..54%..61%..72%..82%..93% >> >> Reading symbols from /boot/kernel/zfs.ko.symbols...done. >> Loaded symbols for /boot/kernel/zfs.ko.symbols >> Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. >> Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols >> Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. >> Loaded symbols for /boot/kernel/opensolaris.ko.symbols >> Reading symbols from /boot/kernel/if_re.ko.symbols...done. >> Loaded symbols for /boot/kernel/if_re.ko.symbols >> Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. >> Loaded symbols for /boot/kernel/snd_hda.ko.symbols >> Reading symbols f
Re: i915kms.ko not loading
04.09.2013 21:40, John Baldwin пишет: > On Wednesday, September 04, 2013 2:16:35 pm Alexander wrote: >> 04.09.2013 18:58, John Baldwin wrote: >>> On Wednesday, September 04, 2013 11:01:03 am Alexander wrote: >>>> 02.09.2013 14:42, Jean-Sébastien Pédron пишет: >>>>> On 02.09.2013 12:00, Alexander wrote: >>>>>> (...) >>>>>> #17 0x80462700 in sysctl_move_oid () >>>>>> #18 0x80319070 in drm_attach () >>>>>> (...) >>>>> The kernel is missing debug symbols. Could you please rebuild your >>>>> kernel with the following option: >>>>> makeoptions DEBUG=-g >>>>> (also found in GENERIC) >>>>> >>>>> Then reproduce the problem and send the output of kgdb again? >>>>> >>>>> Thanks! >>>>> >>>> I rebuild the kernel with debug-g >>>> >>>> kgdb /boot/kernel/kernel /var/crash/vmcore.0 >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and you > are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" for > details. >>>> This GDB was configured as "amd64-marcel-freebsd"... >>>> >>>> Unread portion of the kernel message buffer: >>>> drmn0: on vgapci0 >>>> iicbus0: on iicbb0 addr 0xff >>>> iicsmb0: on iicbus0 >>>> smbus1: on iicsmb0 >>>> smb1: on smbus1 >>>> iic0: on iicbus0 >>>> iicsmb1: on iicbus1 >>>> smbus2: on iicsmb1 >>>> smb2: on smbus2 >>>> iic1: on iicbus1 >>>> iicbus2: on iicbb1 addr 0xff >>>> iicsmb2: on iicbus2 >>>> smbus3: on iicsmb2 >>>> smb3: on smbus3 >>>> iic2: on iicbus2 >>>> iicsmb3: on iicbus3 >>>> smbus4: on iicsmb3 >>>> smb4: on smbus4 >>>> iic3: on iicbus3 >>>> iicbus4: on iicbb2 addr 0xff >>>> iicsmb4: on iicbus4 >>>> smbus5: on iicsmb4 >>>> smb5: on smbus5 >>>> iic4: on iicbus4 >>>> iicsmb5: on iicbus5 >>>> smbus6: on iicsmb5 >>>> smb6: on smbus6 >>>> iic5: on iicbus5 >>>> iicbus6: on iicbb3 addr 0xff >>>> iicsmb6: on iicbus6 >>>> smbus7: on iicsmb6 >>>> smb7: on smbus7 >>>> iic6: on iicbus6 >>>> iicsmb7: on iicbus7 >>>> smbus8: on iicsmb7 >>>> smb8: on smbus8 >>>> iic7: on iicbus7 >>>> iicbus8: on iicbb4 addr 0xff >>>> iicsmb8: on iicbus8 >>>> smbus9: on iicsmb8 >>>> smb9: on smbus9 >>>> iic8: on iicbus8 >>>> iicsmb9: on iicbus9 >>>> smbus10: on iicsmb9 >>>> smb10: on smbus10 >>>> iic9: on iicbus9 >>>> iicbus10: on iicbb5 addr 0xff >>>> iicsmb10: on iicbus10 >>>> smbus11: on iicsmb10 >>>> smb11: on smbus11 >>>> iic10: on iicbus10 >>>> iicsmb11: on iicbus11 >>>> smbus12: on iicsmb11 >>>> smb12: on smbus12 >>>> iic11: on iicbus11 >>>> iicbus12: on iicbb6 addr 0xff >>>> iicsmb12: on iicbus12 >>>> smbus13: on iicsmb12 >>>> smb13: on smbus13 >>>> iic12: on iicbus12 >>>> iicsmb13: on iicbus13 >>>> smbus14: on iicsmb13 >>>> smb14: on smbus14 >>>> iic13: on iicbus13 >>>> iicbus14: on iicbb7 addr 0xff >>>> iicsmb14: on iicbus14 >>>> smbus15: on iicsmb14 >>>> smb15: on smbus15 >>>> iic14: on iicbus14 >>>> iicsmb15: on iicbus15 >>>> smbus16: on iicsmb15 >>>> smb16: on smbus16 >>>> iic15: on iicbus15 >>>> >>>> >>>> Fatal trap 9: general protection fault while in kernel mode >>>> cpuid = 2; apic id = 02 >>>> instruction pointer= 0x20:0x810402a6 >>>> stack pointer= 0x28:0xfe011f2f8360 >>>> frame pointer= 0x28:0xfe011f2f83e0 >>>> code segment= base 0x0, limit 0xf, type 0x1b >>>> = DPL 0, pres 1, long 1,
Re: i915kms.ko not loading
05.09.2013 18:57, John Baldwin пишет:
> On Thursday, September 05, 2013 11:46:13 am Alexander wrote:
>> 05.09.2013 17:30, John Baldwin wrote:
>>> On Thursday, September 05, 2013 10:08:21 am Alexander wrote:
>>> [ ..cut ..]
>>>>> Hmm, 'p *dev'?
>>>>>
>>>>>
>>>> (kgdb) p *dev
>>>> No symbol "dev" in current context.
>>> Please go back to frame 6 first and then run 'p *dev'.
>>>
>> (kgdb) frame 6
>> #6 0x810402a6 in intel_parse_bios (dev=0xf80005dca800) at
>> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_bios.c:287
>> 287switch (INTEL_INFO(dev)->gen) {
>> (kgdb) p *dev
>> = 0x0, sg = 0x0, ctx_bitmap = 0x0, dev_private = 0xf80005dca840,
> dev_private isn't NULL at least. INTEL_INFO is this:
>
> i915_drv.h:#define INTEL_INFO(dev) (((struct drm_i915_private *) (dev)-
>> dev_private)->info)
> Can you stay at frame 6 and do:
>
> 'set $dp = (struct drm_i915_private *)dev->dev_private'
> 'p *$dp'
> 'p *$dp->info'
>
(kgdb) frame 6
#6 0x810402a6 in intel_parse_bios (dev=0xf80005dca800) at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_bios.c:287
287switch (INTEL_INFO(dev)->gen) {
(kgdb) set $dp = (struct drm_i915_private *)dev->dev_private
(kgdb) p *$dp
$1 = {dev = 0x806d3a7d, gmbus_bridge = 0x103, bbbus_bridge =
0x0, gmbus = 0x4, bbbus = 0x0, gmbus_sx = {lock_object = {lo_name = 0x0,
lo_flags = 0, lo_data = 0, lo_witness = 0x0}, sx_lock =
18446744071569226358}, has_gem = 16973824, relative_constants_mode = 0,
sarea = 0x0,
mmio_map = 0x4, gt_fifo_count = 2154642031, forcewake_count =
4294967295, gt_lock = {lock_object = {
lo_name = 0x103 , lo_flags =
0, lo_data = 0, lo_witness = 0x1}, mtx_lock = 18446744071569226372},
sarea_priv = 0x103, rings = {{name = 0x0, id = 4, mmio_base = 0,
virtual_start = 0x0, dev = 0xa, obj = 0x1, head = 2, tail = 3,
space = 4,
size = 5, effective_size = 9, status_page = {page_addr =
0xc000b, gfx_addr = 0, obj = 0x0}, last_retired_head = 0, irq_lock =
{lock_object = {
lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness = 0x0},
mtx_lock = 0}, irq_refcount = 0, irq_mask = 0, irq_seqno = 0,
trace_irq_seqno = 0,
waiting_seqno = 0, sync_seqno = {0, 0}, irq_get =
0xf80005dca968, irq_put = 0, init = 0, write_tail = 0, flush = 0,
add_request = 0,
get_seqno = 0, dispatch_execbuffer = 0, cleanup = 0, sync_to = 0,
semaphore_register = {0, 0, 0}, signal_mbox = {0, 0}, active_list =
{next = 0x0,
prev = 0x0}, request_list = {next = 0x0, prev = 0x0},
gpu_write_list = {next = 0x0, prev = 0x0}, outstanding_lazy_request = 0,
map = {offset = 0,
size = 0, type = _DRM_FRAME_BUFFER, flags = 0, handle = 0x0,
mtrr = 0, rid = 0, virtual = 0x0, bsr = 0x0, bst = 0, bsh = 0, dmah =
0x0, link = {
tqe_next = 0x0, tqe_prev = 0x0}}, private = 0x0}, {name =
0xf800056ccb80 "", id = 91016144, mmio_base = 4294965248,
virtual_start = 0xf801a46097c0, dev = 0x0, obj = 0x0, head =
0, tail = 0, space = 0, size = 0, effective_size = 0, status_page = {
page_addr = 0x0, gfx_addr = 0, obj = 0x0}, last_retired_head =
0, irq_lock = {lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0,
lo_witness = 0xf80001ac3d80}, mtx_lock = 0}, irq_refcount
= 0, irq_mask = 0, irq_seqno = 0, trace_irq_seqno = 0, waiting_seqno = 0,
sync_seqno = {0, 0}, irq_get = 0x10, irq_put = 0, init = 0,
write_tail = 0, flush = 0x2, add_request = 0, get_seqno = 0,
dispatch_execbuffer = 0,
cleanup = 0, sync_to = 0, semaphore_register = {0, 0, 0},
signal_mbox = {0, 0}, active_list = {next = 0xf80005dca840, prev =
0x0},
request_list = {next = 0x0, prev = 0xf801a483bd80},
gpu_write_list = {next = 0x3, prev = 0x0}, outstanding_lazy_request =
87252704, map = {
offset = 0, size = 0, type = _DRM_FRAME_BUFFER, flags = 0,
handle = 0x0, mtrr = 0, rid = 0, virtual = 0x0, bsr = 0x0, bst = 0, bsh
= 0, dmah = 0x0,
link = {tqe_next = 0x0, tqe_prev = 0x0}}, private = 0x0}, {name
= 0x0, id = RCS, mmio_base = 0, virtual_start = 0x0, dev = 0x0, obj = 0x0,
head = 0, tail = 0, space = 0, size = 0, effective_size = 0,
status_page = {page_addr = 0x0, gfx_addr = 0, obj = 0x0},
last_retired_head = 0,
irq_lock = {lock_object = {lo_name = 0x , lo_flags = 0, lo_data = 0, lo_witness = 0x0},
mtx_lock = 0},
irq_refcount = 0, irq_mask = 0, irq_seqno = 0, trace_irq_seqno =
0, waiting_seqno = 0, sync_seqno = {0, 0}, irq_get = 0, irq_put = 0,
init = 0,
write_tail = 0, flush = 0, add_request = 0, get_seqno = 0,
dispatch_execbuffer = 0, cleanup = 0, sync_to = 0, semaphore_register =
{0, 0, 0},
signal_mbox = {0, 0}, active_li
Re: i915kms.ko not loading
05.09.2013 17:30, John Baldwin wrote:
> On Thursday, September 05, 2013 10:08:21 am Alexander wrote:
> [ ..cut ..]
>>> Hmm, 'p *dev'?
>>>
>>>
>> (kgdb) p *dev
>> No symbol "dev" in current context.
> Please go back to frame 6 first and then run 'p *dev'.
>
(kgdb) frame 6
#6 0x810402a6 in intel_parse_bios (dev=0xf80005dca800) at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_bios.c:287
287switch (INTEL_INFO(dev)->gen) {
(kgdb) p *dev
$1 = {driver = 0x810796a0, id_entry = 0x81079cd8,
pci_device = 338, pci_vendor = 32902, pci_subdevice = 0, pci_subvendor =
0, unique = 0x0,
unique_len = 0, device = 0xf80001a0ba00, devnode =
0xf801a476a400, if_version = 0, flags = 0, dma_lock = {lock_object = {
lo_name = 0x806d3a7d "drmvbl", lo_flags = 16973824,
lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, irq_lock = {lock_object =
{lo_name = 0x0,
lo_flags = 0, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0},
dev_lock = {lock_object = {lo_name = 0x806d3a76 "drmirq",
lo_flags = 16973824,
lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, dev_struct_lock =
{lock_object = {lo_name = 0x806d3a6f "drmdev", lo_flags = 16973824,
lo_data = 0, lo_witness = 0x0}, sx_lock = 1}, drw_lock =
{lock_object = {lo_name = 0x806d3a84 "drmdrw", lo_flags =
16973824, lo_data = 0,
lo_witness = 0x0}, mtx_lock = 4}, open_count = 0, buf_use = 0,
counters = 10, types = {_DRM_STAT_LOCK, _DRM_STAT_OPENS, _DRM_STAT_CLOSES,
_DRM_STAT_IOCTLS, _DRM_STAT_LOCKS, _DRM_STAT_UNLOCKS, _DRM_STAT_IRQ,
_DRM_STAT_PRIMARY, _DRM_STAT_SECONDARY, _DRM_STAT_DMA, _DRM_STAT_LOCK,
_DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK},
counts = {0 }, files = {tqh_first = 0x0,
tqh_last = 0xf80005dca968}, magiclist = {{head = 0x0, tail =
0x0} }, maplist = {tqh_first = 0xf800056ccb80,
tqh_last = 0xf800056ccbd0}, map_unrhdr = 0xf801a46097c0,
context_sareas = 0x0, max_context = 0, lock = {hw_lock = 0x0, file_priv
= 0x0,
lock_queue = 0, lock_time = 0}, dma = 0x0, irq = 0, irq_enabled = 0,
msi_enabled = 0, irqrid = 0, irqr = 0x0, irqh = 0x0, pcir =
{0xf80001ac3d80,
0x0, 0x0, 0x0, 0x0, 0x0}, pcirid = {16, 0, 0, 0, 0, 0}, pci_domain =
0, pci_bus = 0, pci_slot = 2, pci_func = 0, context_flag = 0,
last_context = 0,
num_crtcs = 0, buf_sigio = 0x0, sysctl = 0x0, sysctl_node_idx = 0, agp
= 0x0, sg = 0x0, ctx_bitmap = 0x0, dev_private = 0xf80005dca840,
agp_buffer_token = 0, agp_buffer_map = 0x0, control =
0xf801a483bd80, primary = 0x3, drm_ttm_bdev = 0x0, drw_unrhdr =
0xf80005335ee0, drw_head = {
rbh_root = 0x0}, vblank_disable_allowed = 0, _vblank_count = 0x0,
_vblank_time = 0x0, vblank_time_lock = {lock_object = {lo_name = 0x0,
lo_flags = 0,
lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, vbl_lock =
{lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness =
0x0}, mtx_lock = 0},
vblank_refcount = 0x0, last_vblank = 0x0, vblank_enabled = 0x0,
vblank_inmodeset = 0x0, last_vblank_wait = 0x0, vblank_disable_callout =
{c_links = {
le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, tqe =
{tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_precision = 0, c_arg =
0x0,
c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0}, max_vblank_count
= 4294967295, vblank_event_list = {next = 0x0, prev = 0x0}, event_lock = {
lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness
= 0x0}, mtx_lock = 0}, mode_config = {mutex = {lock_object = {lo_name =
0x0,
lo_flags = 0, lo_data = 0, lo_witness = 0x0}, sx_lock = 0},
crtc_names = {lock = {lock_object = {lo_name = 0x0, lo_flags = 0,
lo_data = 0,
lo_witness = 0x0}, mtx_lock = 0}, names_hash = 0x0, hash_mask
= 0, unr = 0x0}, num_fb = 0, fb_list = {next = 0x0, prev = 0x0},
num_connector = 0,
connector_list = {next = 0x0, prev = 0x0}, num_encoder = 0,
encoder_list = {next = 0x0, prev = 0x0}, num_plane = 0, plane_list =
{next = 0x0,
prev = 0x0}, num_crtc = 0, crtc_list = {next = 0x0, prev = 0x0},
property_list = {next = 0x0, prev = 0x0}, min_width = 0, min_height = 0,
max_width = 0, max_height = 0, funcs = 0x0, fb_base = 0,
poll_enabled = false, output_poll_task = {q = 0x0, t = {ta_link =
{stqe_next = 0x0},
ta_pending = 0, ta_priority = 0, ta_func = 0, ta_context = 0x0},
c = {c_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next =
0x0},
tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0,
c_precision = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0,
c_cpu = 0}, f = 0},
property_blob_list = {next = 0x0, prev = 0x0}, edid_property = 0x0,
dpms_property = 0x0, dvi_i_subconnector_property = 0x0,
dvi_i_select_subconnector_property = 0x0, tv_subconnector_property =
0x0, tv_select_subconnector_property = 0x0, tv_mode_property = 0x0,
Problems with getting a crash dump
Hello, I am currently using FreeBSD 14.0-CURRENT and I found a bug that triggers a kernel panic. I wanted to make a kernel crash dump to further investigate the issue, but after a few tries I still did not manage to do it. I started by following the instructions in the FreeBSD Handbook. I checked that /dev/nvd0p2.eli is an active swap device and I configured it to be used as a dump device like this: # dumpon -v /dev/nvd0p2.eli # sysctl debug.kdb.panic=1 Then I booted into single user mode to extract the core dumb: # savecore -vC /dev/nvd0p2 checking for kernel dump on device /dev/nvd0p2 mediasize = 2147483648 bytes sectorsize = 512 bytes magic mismatch on last dump header on /dev/nvd0p2 No dump exists A you can see the core dump was not written to the device. Later I also tried using /dev/nvd0p2 (with out the "eli" part), because /dev/nvd0p2.eli is only available after I enable it using swapon, but the handbook states the I should first extract the dump, before I use the device as swap again. But the result was the same. /dev/nvd0p2 is only 2gb in size and it's an encrypted swap device, so I thought that: 1) Maybe the size of the device is to small even for a minidump. 2) Perhaps using encrypted swap as a dump device is not supported. Because of those complications I decided to use an external 8gb USB drive as my dump device. # gpart create -s gpt /dev/da0 # gpart add -t freebsd-swap /dev/da0 # swapoff -a # swapon /dev/da0p1 # dumpon -v /dev/da0p1 kernel dumps on priority: device 0: da0p1 I have 8gb of RAM so a 8gb dump device should be big enough for a minidump. I used `sysctl debug.kdb.panic=1` to crash the kernel and rebooted the system. I also waited for 10 minutes to ensure the the kernel finished writing the core dump to the device. # savecore -vC /dev/da0p1 checking for kernel dump on device /dev/da0p1 mediasize = 7744741376 bytes sectorsize = 512 bytes magic mismatch on last dump header on /dev/da0p1 No dump exists As you can see I still did not manage to get a kernel crash dump. Any ideas? Here is a picture of the output I get after running `sysctl debug.kdb.panic=1`: https://forums.freebsd.org/attachments/img_20211108_163313-jpeg.11936/ PS yes kern.coredump is set to 1.
Re: Problems with getting a crash dump
Thanks for the replies! I finally managed to solve the issue. For some reason when I get a panic while i915kms is active I am unable to write `continue` in KDB. Also the KDB prompt was not even displayed so I had no idea that I should write that command. After I added debug.debugger_on_panic=0 to /etc/sysctl.conf the kernel automatically starts writing the crash dump and I do not have to write anything manually, which solves the issue for me. Dumping screenshot: https://forums.freebsd.org/attachments/img_20211109_230340-jpg.11963/
Re: this of interest to anyone?
Thus spake Matthew Jacob ([EMAIL PROTECTED]): > panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking I got this very often the last days, too. Actually I try do downgrade to 3.2, because my machines reboots 3 times a day because of either this error or other things. -CURRENT actually is VERY unstable here. Alex -- ** I doubt, therefore I might be. ** *** Send email to <[EMAIL PROTECTED]> to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
Thus spake Nick Hibma ([EMAIL PROTECTED]): Hello again! > If you are still running current, please cvsup the newest sources. This > problem has been solved in the past few days. It showed up on saturday > evening after a commit on McKusick and most of the problem area's have > been identified and tracked down. The kernel that made the problem is 2 days old. (From Wednesday). Actually, I even can´t compile a new kernel/world, cause it reboots and hangs all the time. Nice. I´ll try further Alex -- ** I doubt, therefore I might be. ** *** Send email to <[EMAIL PROTECTED]> to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"w" date
Hi! bash-2.02# w 2:26PM up 30 days, 4:13, 4 users, load averages: 2.85, 2.25, 2.09 USER TTY FROM LOGIN@ IDLE WHAT root v0 -Mon07PM 2:14 (bash) root v1 -18Jul99 16days (bash) alex v2 -Tue05PM 6days (bash) root p0 0.10 04Nov35 - (w) bash-2.02# date Tue Aug 3 14:26:47 CEST 1999 Take a look at the last one: p0. I logged in ~5 min before. The date confuses me. It´s a FreeBSD neutron.cichlids.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sun Jul 4 12:04:20 CEST 1999 root@:/usr/src/current/src/sys/compile/neutron i386 it doesn´t matter for me, maybe it´s already fixed. I was just wondering. Alex -- ** I doubt, therefore I might be. ** *** Send email to <[EMAIL PROTECTED]> to get PGP-Key *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "w" date
Thus spake Alexander Langer ([EMAIL PROTECTED]):
> root p0 0.10 04Nov35 - (w)
> bash-2.02# date
> Tue Aug 3 14:26:47 CEST 1999
> Take a look at the last one: p0. I logged in ~5 min before.
> The date confuses me.
I took a further look into the sources. usr.bin/w/* is not the
problem, I´d say. It probably read the time wrong from /var/run/utmp
if ((ut = fopen(_PATH_UTMP, "r")) == NULL)
err(1, "%s", _PATH_UTMP);
for (nusers = 0; fread(&utmp, sizeof(utmp), 1, ut);) {
...
I don´t know, which daemon writes to /var/run/utmp.
Maybe I should notice, that I´m logged in via ssh.
Any ideas?
BTW: My machine, that is some newer, told me a login @ 01Jan71 (or
72 or 70? I forgot, but it doesn´t matter. it´s wrong at all)
just a minute ago. That´s also wrong but exactly the opposite of year
2035.
Now, it tells me something wrong, AGAIN. But not so worse at all:
I typed the following without any breaks, it took only ~5 seconds.
bash-2.02# ssh cichlids
root@cichlids's password:
You have mail.
bash-2.02# date
Do 5 Aug 1999 12:02:59 CEST
bash-2.02# w
12:02pm up 1:29, 2 users, load averages: 1.13, 1.11, 1.08
USER TTY FROM LOGIN@ IDLE WHAT
alex v7 -10:36am 1:26 -bash (bash)
ttyp4 -12:00pm 1:28 -
bash-2.02#
Strange. the login is at 12:02 and not at 12:00 !
What´s wrong with /var/run/utmp?
Alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
date(1) and -v-1m
Hello! The behaviour of date(1) is probably specified by POSIX, but I think, date -v-1m should at least return a date a month _before_ the current month. Example: Mi 1 Dez 1999 15:06:47 CET (Dez. has 31, so it should be Nov 30, I think). More confusing is something like: alex:~ $ date -v-1m +%Y-%m 1999-12 what I wanted to use to create backup folders for my mail-system (all mails of the last month are moved to a folder of the last month). That's weird, somehow. Is this a bug or a feature? Is this POSIX-compilant? Do we want an additional option? (I want :-)) Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: date(1) and -v-1m
Thus spake Brian Somers ([EMAIL PROTECTED]): > > Do we want an additional option? (I want :-)) > I certainly wouldn't object to -V doing the same as -v but rounding > down this could also decide how to behave when a -v adjusts the > time onto a non-existent time (say 1:30 when the clocks go forward). Ok. I start work :-) Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
Thus spake Alexander Langer ([EMAIL PROTECTED]): > Here are the messages regarding ata and hdd's: > > ata-pci0: at device 7.1 on pci0 > ata-pci0: Busmastering DMA supported > ata0 at 0x01f0 irq 14 on ata-pci0 > ata1 at 0x0170 irq 15 on ata-pci0 > ... > ad0: ATA-3 disk at ata0 as master > ad0: 6197 MB (12692736 sectors), 12592 cyls, 16 heads, 63 S/T, 512 B/S > ad0: 16 secs/int, 1 depth queue, UDMA33 After I have now posted the boot-messages. Can you see any reason for it? Alex -- I doubt, therefore I might be. PGP signature
Re: HEADS UP! wormcontrol and sys/dvdio.h users
Thus spake Soren Schmidt ([EMAIL PROTECTED]): > The DVD ioctl's has changed numbers, so those using that > should recompile thier apps. > Wormcontrol and related files will be removed soon. I saw changes for the ioctl for the ata*, but not for the wd* stuff. Could wormcontrol at least stay as the wd* drivers stay? ata* doesn't work for me at the moment, thus I'm using the wd drivers. Or am I wrong? Can I use burncd with the wd drivers? Thank you. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! wormcontrol and sys/dvdio.h users
Thus spake Soren Schmidt ([EMAIL PROTECTED]): > > Could wormcontrol at least stay as the wd* drivers stay? > Sure, I dont se why not, but it adds to the confusion... ok. nice. > > ata* doesn't work for me at the moment, thus I'm using the wd drivers. > What is your problem ?? I posted this to the -current ml 3 weeks ago, when I wanted to switch. See the "ata: Mount root failure: 6"-thread. I just don't know, what's wrong. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: 4.0 slower than 3.4?
Jason Young wrote: Saturday, January 08, 2000 9:02 AM > It probably isn't the best of all ideas to have BOTH IP firewalling > solutions installed and running at once. This will add some > overhead. Pick one and stick with it. And why do you have DUMMYNET > running? > > There is a new version of IPFilter in -CURRENT if I recall > correctly, and this may be related to your timing issues. Really > you ought to just take IPFILTER out of your configuration. To my understanding, both IPFW (ipfw.ko) and IPFILTER (ipl.ko) can be built as modules. I have made some lmbench tests and they show that ipfilter actually adds more latency than ipfw. Here are some lmbench results taken on a P3-500, -current (2 days old) First, plain (no module loaded): UDP latency using localhost: 65 microseconds TCP latency using localhost: 67 microseconds RPC/udp latency using localhost: 111 microseconds RPC/tcp latency using localhost: 139 microseconds TCP/IP connection cost to localhost: 119 microseconds Socket bandwidth using localhost: 71.97 MB/sec Now, ipl.ko loaded (ipfilter), no rulesets UDP latency using localhost: 80 microseconds TCP latency using localhost: 85 microseconds RPC/udp latency using localhost: 129 microseconds RPC/tcp latency using localhost: 155 microseconds TCP/IP connection cost to localhost: 145 microseconds Socket bandwidth using localhost: 67.72 MB/sec The following is for ipfw.ko loaded (default policy to accept, no other rules). UDP latency using localhost: 68 microseconds TCP latency using localhost: 73 microseconds RPC/udp latency using localhost: 115 microseconds RPC/tcp latency using localhost: 143 microseconds TCP/IP connection cost to localhost: 127 microseconds Socket bandwidth using localhost: 70.11 MB/sec And finally, both ipl.ko and ipfw.ko loaded (rather stupid imho, I think they're supposed to work as an either-or solution :) ). UDP latency using localhost: 84 microseconds TCP latency using localhost: 90 microseconds RPC/udp latency using localhost: 132 microseconds RPC/tcp latency using localhost: 160 microseconds TCP/IP connection cost to localhost: 152 microseconds Socket bandwidth using localhost: 66.04 MB/sec -- /"\ / \ / ASCII RIBBON CAMPAIGN /For every single problem you can X AGAINST HTML MAIL/ find a solution, which is simple, / \ AND POSTINGS/ neat and wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: 4.0 slower than 3.4?
Garrett Wollman [mailto:[EMAIL PROTECTED]] wrote: Sent: Saturday, January 08, 2000 7:27 PM > You should also try it with `options COMPAT_IPFW=0' in your config > file. Hm, what's this option for? When I put it into my kernel config, the config program complained about an "unknown option". A quick grep over the kernel sources also didn't find it anywhere. Anyway, since I'am using ipfilter as a module, I still have IPFILTER_LKM in my config file (it is required, otherwise the ipl.ko kernel module will not load and complain about a undefined function). This option is still in the source (ip_input.c and ip_output.c), but is missing in the configuration files (even in LINT) for some (?) reason. After removing IPFILTER_LKM, I ran the bench again and got following results. UDP latency using localhost: 63 microseconds TCP latency using localhost: 66 microseconds RPC/udp latency using localhost: 109 microseconds RPC/tcp latency using localhost: 139 microseconds TCP/IP connection cost to localhost: 119 microseconds Socket bandwidth using localhost: 72.63 MB/sec - To make comparing easier, here are the results I already posted yesterday. First, plain (no module loaded): UDP latency using localhost: 65 microseconds TCP latency using localhost: 67 microseconds RPC/udp latency using localhost: 111 microseconds RPC/tcp latency using localhost: 139 microseconds TCP/IP connection cost to localhost: 119 microseconds Socket bandwidth using localhost: 71.97 MB/sec Now, ipl.ko loaded (ipfilter), no rulesets UDP latency using localhost: 80 microseconds TCP latency using localhost: 85 microseconds RPC/udp latency using localhost: 129 microseconds RPC/tcp latency using localhost: 155 microseconds TCP/IP connection cost to localhost: 145 microseconds Socket bandwidth using localhost: 67.72 MB/sec The following is for ipfw.ko loaded (default policy to accept, no other rules). UDP latency using localhost: 68 microseconds TCP latency using localhost: 73 microseconds RPC/udp latency using localhost: 115 microseconds RPC/tcp latency using localhost: 143 microseconds TCP/IP connection cost to localhost: 127 microseconds Socket bandwidth using localhost: 70.11 MB/sec And finally, both ipl.ko and ipfw.ko loaded (rather stupid imho, I think they're supposed to work as an either-or solution :) ). UDP latency using localhost: 84 microseconds TCP latency using localhost: 90 microseconds RPC/udp latency using localhost: 132 microseconds RPC/tcp latency using localhost: 160 microseconds TCP/IP connection cost to localhost: 152 microseconds Socket bandwidth using localhost: 66.04 MB/sec -- /"\ / \ / ASCII RIBBON CAMPAIGN /For every single problem you can X AGAINST HTML MAIL/ find a solution, which is simple, / \ AND POSTINGS/ neat and wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __sigisempty() undefined if "cc -g" used.
On 10 Jan, Bruce Evans wrote:
>> Better yet: DEBUG_FLAGS=-g
>
> Except it only supported in bsd.prog.mk and bsd.lib.mk, but not in
> bsd.kmod.mk, kernel Makefiles, or if no bsd .mk files are included
> A few verbose module makefiles add it explicitly. You can also use
> COPTS, but it is only supported in bsd.prog.mk, bsd.kmod.mk and kernel
> Makefiles.
Didn´t we have "makeoptions DEBUG=-g" as a kernel option to compile the
kernel with debug information? What about "config -g MYKERNEL"?
Do we really need a global debug option which covers everything?
If I read it correcly we have DEBUG_FLAGS for the userland (if it uses a
bsd.{prog,lib}.mk) and DEBUG for the kernel (and COPTS for KLD's),
right? So we only have to make the KLD's consistent to the kernel (or am
I missing something):
bsd.kmod.mk:
---snip---
92c92
< CFLAGS+= ${COPTS} -D_KERNEL ${CWARNFLAGS}
---
> CFLAGS+= ${DEBUG} -D_KERNEL ${CWARNFLAGS}
---snip---
Bye,
Alexander.
--
Happy new year and no Y2K-crash to everyone.
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: __sigisempty() undefined if "cc -g" used.
On 11 Jan, Bruce Evans wrote:
>> Didn´t we have "makeoptions DEBUG=-g" as a kernel option to compile the
>> kernel with debug information? What about "config -g MYKERNEL"?
>
> DEBUG is a private variable in kernel Makefiles. "config -g MYKERNEL"
If I set DEBUG in make.conf it should work, right? So what's private
about it?
> is the only correct way to set it. "makeoptions DEBUG=-g" is a hackish
> way to set it. It depends on knowing the the Makefiles' internals.
>
>> Do we really need a global debug option which covers everything?
>
> It's simpler to have the same global debug option for everything.
We have CFLAGS (userland) and COPTFLAGS (kernel) in make.conf, shouldn´t
we also have e.g. DEBUG_FLAGS and DEBUG_KERNEL (renamed DEBUG from
above)?
Together with CFLAGS and COPTFLAGS it would make more sense, IMO.
And what about those people who want to compile only the kernel and the
KLD's with debug information, but not the userland?
>> If I read it correcly we have DEBUG_FLAGS for the userland (if it uses a
>> bsd.{prog,lib}.mk) and DEBUG for the kernel (and COPTS for KLD's),
>> right?
>
> No. DEBUG is quite different.
Sorry, but I didn´t get the point. Is it a semantic difference or a
technical one?
>> So we only have to make the KLD's consistent to the kernel (or am
>> I missing something):
>>
>> bsd.kmod.mk:
>> ---snip---
>> 92c92
>> < CFLAGS+= ${COPTS} -D_KERNEL ${CWARNFLAGS}
>> ---
>> > CFLAGS+= ${DEBUG} -D_KERNEL ${CWARNFLAGS}
>> ---snip---
>
> This would break COPTS :-). All places should use something more like:
>
> CFLAGS+= [-D_KERNEL] ${CWARNFLAGS} ${COPTS} ${DEBUG_FLAGS}
What about renaming "DEBUG" in the kernel makefile to DEBUG_KERNEL and
use DEBUG_KERNEL instead of DEBUG_FLAGS in bsd.kmod.mk?
Bye,
Alexander.
--
Happy new year and no Y2K-crash to everyone.
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: freezing... update to 1.45 of ffs_softdep.c
In article <[EMAIL PROTECTED]> you wrote: > In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >>I would like to know if the person reporting the getblk lockup (I think >>it was Poul) sees that problem solved with the vinum fix that Alfred >>posted in regards to or whether we still have an open issue. > I don't use vinum and -current as cvsup'ed right now has the problem. I just saw the same: two processes got frozen in getblk (tin and mutt). No makeworld, no activity on the system at all -- just reading news and mail. After a minute or so the whole system froze. It's with version 1.46 of ffs_softdep.c > -- > 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! --- "Nuclear war can ruin your whole compile." -- Karl Lehenbauer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
building GNATS with recent current
Hello! I have a recent current: FreeBSD cichlids.cichlids.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Jan 11 13:18:21 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/cichlids i386 I cannot build the CVS version of GNATS with this. This is kinda strange, because with a kernel from Dec 18th I could do this. something must have changed. Can one reproduce this, too? I can. Please check out: cvs "gnats" from :pserver:[EMAIL PROTECTED]:/cvs/gnats type ./configure --with-full-gnats (ignore the error for etc/ that stop the script and then type "make" I stop at: [...] test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include strerror.c -o pic/strerror.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include strerror.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include strsignal.c -o pic/strsignal.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include strsignal.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xatexit.c -o pic/xatexit.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xatexit.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xexit.c -o pic/xexit.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xexit.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xmalloc.c -o pic/xmalloc.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xmalloc.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xstrdup.c -o pic/xstrdup.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xstrdup.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xstrerror.c -o pic/xstrerror.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include xstrerror.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include basename.c -o pic/basename.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include basename.c test x"no" != xyes || gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include insque.c -o pic/insque.o gcc -c -DHAVE_CONFIG_H -g -O2 -W -Wall -I. -I./../include insque.c rm -f libiberty.a ar rc libiberty.a argv.o choose-temp.o concat.o cplus-dem.o fdmatch.o fnmatch.o getopt.o getopt1.o getruntime.o hex.o floatformat.o objalloc.o obstack.o pexecute.o spaces.o splay-tree.o strerror.o strsignal.o xatexit.o xexit.o xmalloc.o xstrdup.o xstrerror.o basename.o insque.o ranlib libiberty.a now it just _hangs_. I can now SIGINT it. I can SIGINT a further call. I can do nothing with a third call. I EVEN cannot SIGKILL it!! gdb tells me, that it stops at wait4(). Now it becomes strange. I "cd" into the same dir, and now a "ls" hangs, too. when I do a cd dir ; ls on 3 further consoles, the SYSTEM just hangs. It _just_ hangs. no error, it only hangs. Please test, if this is the same case for you. As said, this was not the case with a kernel from Dec. 18th, therefore (same config-file) I'll not include the kernel-config here. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: building GNATS with recent current
Stuff seems to compile now without problems (updated kernel) Strange. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fix for apm.4
Hi,
the patch makes apm.4 consistent with LINT ("isa?"->"nexus?").
Bye,
Alexander.
--
Withdrawal is for quitters.
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
21c21
< .Cd device apm0 at isa?
---
> .Cd device apm0 at nexus?
Re: crash with ffs_softdep.c 1.52
On 15 Jan, Alfred Perlstein wrote:
>> >> > unfortunally no core dump, but I'm able to reproduce it (I just have to
>> >> > enable softupdates).
>> >>
>> >> how? It looks like splbio is not up but the softdep lock is held.
>>
>>
>>I just have to enable softupdates on /home, /var, /usr, /usr/obj to
>> get a panic at "Additional daemons: syslogd" while booting.
>> If I disable softupdates at /var I'm able to log in (X11) and dial out
>> -> panic (because of fetchnews/fetchmail/whatever are accessing
>> something).
With only softupdates for /var I'm also able to reproduce the panic at
reboot.
>> > The best thing is to look at this global variable for lkt_held:
>> > static struct lockit {
>> > int lkt_spl;
>> > pid_t lkt_held;
>> > } lk;
>> >
>> > and see which process held the lock. Do a traceback on that process as well..
[HowTo DDB?]
> http://www.freebsd.org/handbook/kerneldebug.html
---snip---
db> x/ld,2 lk
lk: 0 161
db> ps
pid proc addr uid ppid pgrp flag stat wmesg wchancmd
161 d7cebg00 d86bd000 0 160 161 04 3getbuf c3361ccb syslogd
160 d7cec500 d86a5000 0 66 004086 3wait d7cec500 syslogd
[...]
6waitsh
[...]
---snip---
How do I do a traceback on PID 161? "trace/u" outputs the same as
"trace" and I haven't found anything related except "trace/u" in ddb(4).
I'm still not able to get a core dump of this, perhaps a
misconfiguration?
fstab:
---snip---
/dev/da0s1b noneswapsw 0 0
---snip---
rc.conf:
---snip---
dumpdev="/dev/da0s1b"
---snip---
(104) netchild@ttyp2 > ll /dev/da0s1b
crw-r- 1 root operator 13, 0x00020001 1 Dez 12:41 /dev/da0s1b
Kernel config and output of dmesg attached.
Bye,
Alexander.
--
Where do you think you're going today?
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
machine i386
ident WORK
maxusers40
makeoptions DEBUG=-g
makeoptions CONF_CFLAGS=-fno-builtin
#
# Allow user-mode programs to manipulate their local descriptor tables.
# This option is required for the WINE Windows(tm) emulator, and is
# not used by anything else (that we know of).
#
#optionsUSER_LDT#allow user-level control of i386 ldt
# Options for the VM subsystem
#optionsPQ_NOOPT# No coloring
options PQ_LARGECACHE # color for 512k/16k cache
#optionsPQ_HUGECACHE# color for 1024k/16k cache
cpu I686_CPU# aka Pentium Pro(tm)
options CPU_FASTER_5X86_FPU
options CPU_SUSP_HLT
options "NO_F00F_HACK"
options COMPAT_43
options SYSVSHM
options SYSVSEM
options SYSVMSG
options MD5
options DDB
options GDB_REMOTE_CHAT
options KTRACE #kernel tracing
#optionsPERFMON
options UCONSOLE
options USERCONFIG #boot -c editor
options VISUAL_USERCONFIG #visual boot -c editor
options INET#Internet communications protocols
pseudo-device ether #Generic Ethernet
pseudo-device sppp#Generic Synchronous PPP
pseudo-device loop#Network loopback device
pseudo-device bpf #Berkeley packet filter
#pseudo-device disc#Discard device
pseudo-device streams
options PPP_BSDCOMP #PPP BSD-compress support
options PPP_DEFLATE #PPP zlib/deflate/gzip support
options PPP_FILTER #enable bpf filtering (needs bpfilter)
options MROUTING# Multicast routing
options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE #print information about
# dropped packets
options IPFIREWALL_FORWARD #enable transparent proxy support
options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
#optionsIPDIVERT#divert sockets
#optionsIPSTEALTH #support for stealth forwarding
options TCP_RESTRICT_RST#restrict emission of TCP RST
options ICMP_BANDLIM
options FFS #Fast filesystem
options CD9660 #ISO 9660 filesystem
options KERNFS #Kernel filesystem
options MSDOSFS #MS DOS File System
options PROCFS #Proces
Solved(?): crash with ffs_softdep.c 1.52
Hi, I've successfully booted with ffs_softdep.c 1.54, I'm doing now a full buildworld to stress the system. If you didn't hear from me it works (or my system had a crash and I'm not able to recover ;) ). Bye, Alexander. -- Too many freaks, not enough circuses. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gimp 1.1.15 & -current
Hi, I've build gimp-1.1.15 (some minutes ago) on -current (cvsuped yesterday) and I'm getting sigsegv's after the parsing of the plug-in's. Anyone seeing this too? ---snip--- (150) netchild@ttyp0 > gimp gimp: fatal error: sigsegv caught gimp (pid:90581): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0x28380840 in g_on_error_stack_trace () from /usr/local/lib/libglib12.so.3 #1 0x28380762 in g_on_error_query () from /usr/local/lib/libglib12.so.3 #2 0x80bd953 in gimp_fatal_error () #3 0x811be25 in main () #4 0xbfbfffac in ?? () #5 0x28296a51 in gtk_item_factory_parse_path () #6 0x28296cc7 in gtk_item_factory_create_item () #7 0x811e986 in menus_last_opened_add () #8 0x811d82f in menus_create_item_from_full_path () #9 0x81519ae in plug_in_set_menu_sensitivity () #10 0x814f12c in plug_in_init () #11 0x80712e8 in app_init () #12 0x807031b in gimp_init () #13 0x811bd5e in main () #14 0x8101826 in install_verify () #15 0x811bd27 in main () #16 0x806a2f9 in _start () ---snip--- It's build with CFLAGS= -Os -march=pentiumpro -pipe -Wall -fexpensive-optimizations \ -funroll-loops -fschedule-insns2 could this be the cause (I'm going to try it with "-O -pipe")? Bye, Alexander. P.S.: The helpbrowser gets installed and "pkg_delete gimp-1.1.15" complains about it not being in PLIST (I've removed it because of the mail from cvs-all). -- Closet extrovert. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sigisempty?
Thus spake Satoshi - Ports Wraith - Asami ([EMAIL PROTECTED]):
> Langer. It has a nice feature of working for both -current and
> -stable without any additional #ifdef's. I hope it's ok.
I now saw Garret Wollman's function.
I like the use of the static-vars.
The use of sigemptyset makes it more transparenter for later changes,
that I hope won't occur, but at the moment it doesn't matter since
sigemptyset is
int
sigemptyset(set)
sigset_t *set;
{
int i;
for (i = 0; i < _SIG_WORDS; i++)
set->__bits[i] = 0;
return (0);
}
I attached a patch against patch-lo anyways (sorry ;-)
Alex
--
I doubt, therefore I might be.
--- /tmp/xview/patches/patch-lo Thu Jan 20 04:38:25 2000
+++ patch-loMon Jan 24 17:14:58 2000
@@ -20,15 +20,17 @@
union wait status;/* Return value from wait3 */
#else SVR4
int status; /* Return value from wait3 */
-@@ -188,7 +197,12 @@
+@@ -188,7 +197,14 @@
#define sigisempty(s) (!(((s)->__sigbits[0]) | ((s)->__sigbits[1]) \
| ((s)->__sigbits[2]) | ((s)->__sigbits[3])))
#else
-#define sigisempty(s) (!(*(s)))
+static int
+sigisempty (sigset_t *s) {
-+ sigset_t n;
-+ bzero(&n, sizeof(sigset_t));
++ static sigset_t n;
++ static int emptied = 0;
++ if (!emptied)
++ sigemptyset(&n), emptied++;
+ return (! memcmp(&n, s, sizeof(sigset_t)));
+}
#endif
Re: 4.0-release (ports) schedule
Thus spake David O'Brien ([EMAIL PROTECTED]): > I would be happy to look review fixes or consult the maintainers. Hello David, compiler-maintainer ;-) I noticed that many ports are broken because the compiler handles ANSI-C++ violations too strict. That means, if you do, as an example: const fubar = 10; the build _FAILS_. Other compilers implicy type "int" here, that's why many ports are broken for -current only. Just FYI, maybe you can do something against this strict handling. Or not, I don't know. Somehow, it's very good that the compiler does this... Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-release (ports) schedule
Thus spake Michael VanLoon ([EMAIL PROTECTED]): > What would you do about it? The C++ standard says that's an error. So, > it's an error. It's not "too strict" -- it's exactly the right amount of > strictness to conform to the standard. Yes. That's what I meant with "Somehow, it's very good ...". BUT: Other compilers don't treat this as an error, that's why many ports fail. Ok, so far it's just the porter's thing to make stuff compile. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-release (ports) schedule
Thus spake David O'Brien ([EMAIL PROTECTED]): > > I noticed that many ports are broken because the compiler handles > > ANSI-C++ violations too strict. > Not too strict -- to the ratified ISO-C++ specification. Yes. Ok :-) > Nope. Those programs that aren't buildable aren't C++. I will not break > the C++ compiler to support them. Ok, I understand this. Probably I wouldn't do this, too. Though: Often a simple change from char *stuff; [..] stuff = mmap()... (fails) to stuff = (char *) mmap()... (works) does the trick. Enough on this topic. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release failure
Thus spake Rajappa Iyer ([EMAIL PROTECTED]): > That's certainly possible, although it might be a good idea to use a > variable to point to a make.conf file. This way "make release" does > not have to be too aware of what "make world" requires in > /etc/make.conf. though a make release in any case should contain sendmail, as an example, and so far if you have NO_SENDMAIL in your /etc/make.conf it's somehow bad. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
On 25 Jan, Alex Zepeda wrote:
> I haven't been able to mount an msdos (FAT16) formattted zip disk (well
> any FAT16 formatted zip disk) for quite a while. Currently I'm trying to
> mount afd0s4, but no such luck (I think the latest error is something
> about reading the partition table). The wd driver used to grok the same
> disks. Any thoughts?
As a workaround use mtools (it's faster than msdosfs anyway [at least I
noticed this with wfd]).
mtools.conf:
---snip---
drive z: file="/dev/afd0s4" partition=4
---snip---
^^^
This is important.
Bye,
Alexander.
--
A PBS mind in an MTV world.
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
For the archive of this ml: Some of the commits over the time since I got this error solved the problem silently. I'm now using ata this machine w/o any problem. On another machine that had problems with DMA with the old wd drivers UDMA33 now works ok, too. Nice. Thanks! Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: GNU grep 2.4d
Thus spake Max Khon ([EMAIL PROTECTED]): > > > It was a local FreeBSD feature; now it is part of the official GNU grep. > > Any chance of -R coming back too? > it is already there (-r) Hmm. Somehow I dislike name-changes of params. :-( Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: GNU grep 2.4d
Thus spake Ruslan Ermilov ([EMAIL PROTECTED]): > > I agree with Alex Langer, though. -R -> -r gets on my nerves. But I suppose > > it is consistent with `rm`, just not `cp`.. hmm, consistency. > In fact, it is consistent with GNU grep ;=) > Old -a and -R were FreeBSD extensions that have gone now. That's why we all don't like the GNU folks *duck* ;-) Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make_sigset and split_sigset
Hello! How does a -current guy implement the following two macros today: #define make_sigset(maskp, hi, lo) (*maskp=((hi)<<24)|(lo)) /* Not a procedure: */ #define split_sigset(mask, hip, lop) \ ((*(hip)=(mask>>24)&0xff), \ (*(lop)=(mask&0xff))) for make_sigset the stuff is easy: #define make_sigset(maskp, hi, lo) (sigemptyset(maskp), \ sigaddset(maskp, hi), \ sigaddset(maskp, low);) But... how could I extract two sigs of a sigset_t and save these? Thanks! Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Error message from CAM layer
Hi, today I've got (da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 44, SEQADDR == 0x113 (da0:ahc0:0:0:0): BDR message in message buffer (da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 54, SEQADDR == 0x113 (da0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 16 SCBs aborted -current from Jan, 30. At this time I did a "tar -xzf mozilla-FreBSD3x.M13.tar.gz" (btw: the M13 binary from mozilla.org segfaults with -current). I'm using this hardware since 2 years now and it's the first time I see this (the computercase isn't opened for 2 months now, so nothing changed recently). Is this something I should worry about? ---snip--- ahc0: port 0xb000-0xb0ff mem 0xd980-0xd9800fff irq 9 at device 6.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs [...] da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 4100MB (8398656 512 byte sectors: 255H 63S/T 522C) cd0 at ahc0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 2 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present ---snip--- Bye, Alexander. -- Do I look like a freakin' people person? http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ANSI C++ Violations in g++ include files? (see bento)
Please see: http://bento.freebsd.org/errorlogs/4-full/gma-0.5.log I can reproduce this error. What I wonder is, if this is problem of this port, or of the include files. David? g++ is yours, you should know this better. Is this a bug of the port? Thanks Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.4->4.0 ... *almost* ...
Thus spake The Hermit Hacker ([EMAIL PROTECTED]): > ===> lib/libcom_err/doc > install-info --quiet --defsection="Programming & development tools." --defentry="* >libcom_err: (com_err).A Common Error Description Library for UNIX." >com_err.info /usr/share/info/dir > install-info: unrecognized option `--defsection=Programming & development tools.' > Try `install-info --help' for a complete list of options. > *** Error code 1 > Source tree is as of Feb 1st, so only 24hrs old, but I don't recall seeing > anything go throughthe list concerning the above ... > Help? :) As obrien suggested: cd /usr/src make -k installworld make installworld works. For short: The old install-info didn't know this new option. go to /usr/src/gnu/usr.bin/texinfo/install-info and install the new isntall-info (make clean all install) and then restart make installworld. Everything is fine then. I suggested Warner to add this to UPDATING, but I got no response. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.4->4.0 ... *almost* ...
Thus spake Glendon M. Gross ([EMAIL PROTECTED]): > What does the -k switch do? --Glen Gross Read the manpage. Manpages have a very high grade of information. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.4->4.0 ... *almost* ...
Thus spake The Hermit Hacker ([EMAIL PROTECTED]):
> > The old install-info didn't know this new option.
> > go to
> > /usr/src/gnu/usr.bin/texinfo/install-info
> > and install the new isntall-info (make clean all install)
> I wasn't sure where ot find install-info, so I went to
> /usr/obj/usr/src/.. and did a 'find . -name install-info -print', and it
> found one:
Hello?
I said /usr/src/gnu/usr.bin/texinfo/install-info.
You'll find it THERE. That's why I said this.
> And copied that in place (thinking your logic above), and that didn't
> work...this was before emailing the list, which was before the reminder
> about -k
If you had done this the-right-way(tm), it would have worked.
> primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
How do you come to a freebsd.org address?
Alex
--
I doubt, therefore I might be.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Error message from CAM layer
On 2 Feb, Kenneth D. Merry wrote: >> I'm using this hardware since 2 years now and it's the first time I see >> this (the computercase isn't opened for 2 months now, so nothing changed >> recently). Is this something I should worry about? > > This is likely a cabling or termination problem. It could also be that > you've got your cable too close to the power supply. I thinks it's too close to the power supply (da0 terminates the bus). > In any case, check your hardware. Thanks, Alexander. -- I've given up trying to change the world. I'm going to toilet train it so that I never have to change it again. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/lib/lib*.so.* no symbols
Hi, after an installworld (cvsup Feb 4, ~4 pm CET) my libs didn't have symbols anymore: ---snip--- (107) netchild@ttyp2 > nm /usr/lib/libc_r.so.4 /usr/lib/libc_r.so.4: no symbols (108) netchild@ttyp2 > nm /usr/lib/libncurses.so.5 /usr/lib/libncurses.so.5: no symbols (109) netchild@ttyp2 > file /usr/lib/libncurses.so.5 /usr/lib/libncurses.so.5: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), stripped ---snip--- Is this something strange (only in my system) or is this a bug in installworld (/usr/obj/usr/src/lib/libncurses/libncurses.so.5 isn't stripped)? Bye, Alexander. -- Sarcasm is just one of the many services we offer. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.x to 4.0 upgrade problems
Thus spake Josef Karthauser ([EMAIL PROTECTED]): > Not much luck today. Now I've got: > install-info --quiet --defsection="Programming & development tools." --defentry="* >libcom_err: (com_err).A Common Error Description Library for UNIX." >com_err.info /usr/share/info/dir > install-info: unrecognized option `--defsection=Programming & development tools.' I thought we already had this. install install-info from /usr/src/gnu/usr.bin/texinfo/install-info first. (make clean all install) Or do the make -k installworld thing first. Or add install-info to bootstrap-tools (or whatever), as Bill F. suggested. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.x to 4.0 upgrade problems
Thus spake Amancio Hasty ([EMAIL PROTECTED]): > Is it possible to checkin a file called something like "/usr/src/FLASH" to hold > temporary information on the current status of how to build the system? That is mentioned in UPDATING already. e.g. "update genassym" or similar stuff. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Doc on setting up NATd under 4.0-CURRENT ..
Thus spake The Hermit Hacker ([EMAIL PROTECTED]): > And/or, is it the same as 3.x? We've already got one box up, but I seem > to recall there being changes to the FIREWALL and whatnot ... but might be > remembering the wrong thread :( Switch from 3.3 to 4.0 didn't change stuff for me. Everything works as before. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dummy ethernet interface.
On 10 Feb, Archie Cobbs wrote:
> If you want an interface that discards everthing, you can create
> a netgraph interface ("ngctl mkpeer iface foo inet") and leave it
> unconnected.
Or just add "pseude-device disc" to your kernel.
Bye,
Alexander.
--
Everything you know is wrong. But some of it is a useful first approximation.
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/x11/XFree86 is missing XF86Setup
On 11 Feb, Kai Großjohann wrote: > I installed a minimal 3.1 from CD (without X11), then made the > -CURRENT world, then installed the above mentioned ports. All of this > a week or so ago; I forgot the exact date. XF86Setup needs tcl/tk. tcl/tk needs XFree86. If there's no tcl/tk XF86Setup isn't compiled. After installing tcl/tk and rebuilding XFree86 there should be a XF86Setup binary. Try xf86config instead. Bye, Alexander. -- Speed kills. Slow infuriates. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make_sigset/split_sigset in -current
Hello!
Again. I wondered if the following patches could do stuff.
scsh compiles/works now, but I really don't know if the following
replacements can be done for the existing macros.
Can they? I could not reproduce a situation where they are called, so.
I just don't know.
Please, tell me :-)
Unfortunately, Martin (maintainer) did not response.
Alex
--
I need a new ~/.sig.
--- scsh/bsd/sigset.h.old Tue Feb 1 16:04:42 2000
+++ scsh/bsd/sigset.h Fri Feb 4 14:54:18 2000
@@ -2,9 +2,18 @@
** These macros are OS-dependent, and must be defined per-OS.
*/
-#define make_sigset(maskp, hi, lo) (*maskp=((hi)<<24)|(lo))
+#define make_sigset(maskp, hi, lo) sigemptyset(maskp),\
+ sigaddset(maskp, hi), \
+ sigaddset(maskp, lo);
-/* Not a procedure: */
-#define split_sigset(mask, hip, lop) \
- ((*(hip)=(mask>>24)&0xff), \
-(*(lop)=(mask&0xff)))
+static void
+split_sigset(sigset_t mask, int * hip, int * lop) {
+ int seen = 0;
+ int n;
+ for (n = 1; n <= _SIG_MAXSIG; n++) {
+ if (sigismember(&mask, n))
+ (seen ? *hip : *lop) = n, seen++;
+ }
+ if (seen == 1)
+ *hip = 0;
+}
ssh-askpass & OpenSSH
Hi, after building 4-current (cvsupped yesterday) I'm using OpenSSH now. I'm starting my X11 session with ssh-agent and using ssh-add in my .xsession. Unfortunally there's no ssh-askpass build in 4-current (and ssh-add is build with '#define SSH_ASKPASS_DEFAULT "/usr/X11R6/bin/ssh-askpass"') so I'm not able to add my identity to the ssh agent at login time, I have to do it manually from a xterm. At the moment I'm starting everything ssh related with absolute paths (ssh 1.2.27), but I'm not satisfied with this solution (and I didn't want to put /usr/local/bin in front of my $PATH, I prefer to have it at the end). Does someone plan to fix this (e.g. build ssh-askpass conditionally on the presence of libX11 / of a variable in make.conf)? Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patch for usr.sbin/ntp/... (adds pcfclock)
Hi,
attached is a patch for usr.sbin/ntp/config.h and
usr.sbin/ntp/ntpd/Makefile. It adds reflock_pcf to the compiled in
drivers (current has support in the kernel for it).
Bye,
Alexander.
--
Secret hacker rule #11: hackers read manuals.
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
Index: config.h
===
RCS file: /big/FreeBSD-CVS/src/usr.sbin/ntp/config.h,v
retrieving revision 1.3
diff -u -r1.3 config.h
--- config.h2000/01/28 15:05:49 1.3
+++ config.h2000/02/27 16:09:54
@@ -173,7 +173,7 @@
#define CLOCK_PARSE 1
/* Conrad parallel port radio clock */
-/* #undef CLOCK_PCF */
+#define CLOCK_PCF
/* PCL 720 clock support */
/* #undef CLOCK_PPS720 */
Index: ntpd/Makefile
===
RCS file: /big/FreeBSD-CVS/src/usr.sbin/ntp/ntpd/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- ntpd/Makefile 2000/01/01 23:57:59 1.3
+++ ntpd/Makefile 2000/02/27 16:12:16
@@ -19,10 +19,10 @@
refclock_hpgps.crefclock_irig.c refclock_jupiter.c \
refclock_leitch.c refclock_local.crefclock_msfees.c \
refclock_mx4200.c refclock_nmea.c refclock_oncore.c \
- refclock_palisade.c refclock_parse.crefclock_pst.c \
- refclock_ptbacts.c refclock_shm.c refclock_tpro.c \
- refclock_trak.c refclock_true.c refclock_usno.c \
- refclock_wwvb.c version.c
+ refclock_palisade.c refclock_parse.crefclock_pcf.c \
+ refclock_pst.c refclock_ptbacts.c refclock_shm.c \
+ refclock_tpro.c refclock_trak.c refclock_true.c \
+ refclock_usno.c refclock_wwvb.c version.c
CFLAGS+= -I${.CURDIR}/../../../contrib/ntp/include -I${.CURDIR}/../
Re: annoying problem with ncurses, acs_chars and xterm
On 15 Feb, Jose M. Alcaide wrote: > I found an annoying problem: the line drawing chars are not drawn > in xterms. This can be tested with talk(1), grdc(6), or simply > with a command like "dialog --yesno Test 5 15". However, it works > from the system console, using TERM=cons25 and TERM=cons25l1. > > If using TERM=xterm-color from an xterm, the background color of the > line drawing character boxes is correct, but the character itself > does not appear. Works here without problems (TERM = xterm & xterm-color). Wild guess: Does your shell support 8bit-chars? > Something appears to be broken in 4.0's ncurses... Not here (cvsupped + new world: yesterday). Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
how to write kernel modules with newbus?
Hello!
I wanted to write a device driver as kernelmodule, using newbus.
Since there is almost no documentation, I've read some source.
It seems, that I have to do something like:
static device_method_t zivads_methods[] = {
/* interface */
DEVMETHOD(device_identify, zivads_identify),
DEVMETHOD(device_probe, zivads_probe),
DEVMETHOD(device_attach,zivads_attach),
{ 0, 0 }
};
and to use zivads_* functions then.
But this fails because I don't know the right include files - DEVMETHOD
is expanded to unknown funtions
What I'm searching for is some info on how to do this.
Can anyone point me to a SIMPLE device driver module, that does this?
Or any documentation?
Or summarize how exactly stuff is done, e.g. which include files are
needed for the above?
It's very hard to find this things out when starting from scratch :)
When I will have got this working, I would even write a small
manual/introduction, that can be used as an example/manual for other
people, e.g. third party vendors, that want to write drivers for
newbus.
TIA
Alex
--
I need a new ~/.sig.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: feedback on CD install of 4.0-RC2
On 17 Feb, Jordan K. Hubbard wrote:
[Cc stripped]
>> o Finally, again, it seems to me that the skeleton .cshrc, .profile,
>> etc. files that are used for accounts creating during install should have the
>> following variables set:
>>
>>setenv LC_ALL en_US.ISO_8859-1
>>setenv LC_CTYPE en_US.ISO_8859-1
>>setenv LANG en_US.ISO_8859-1
>
> This is a question for the I18N folks; I don't even try to puzzle out
> the various quirks of locale settings these days. :)
IMHO sysinstall or motd should print a little note about the possibility
to set those variables, so Jordan hasn't to mess with them (e.g. for
de_DE one wants to add LC_NUMERIC=C because every lazy script/program
which asks for floats and processes them would break [123.4 -> 123,4]).
^^
Bye,
Alexander.
--
Been there, done that, can't remember why...
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
On 21 Feb, Kenneth D. Merry wrote: >> It crashes for me a lot. There's some deal about fonts, oddly enough, which >> causes it to crash right away- see the installation instructions that come out >> when you install communicator-47- it said something about mkfontdir. >> >> It still crashes or wedges for me a lot, though. I tried mozilla, and that was >> worse. > > For me at least, slashdot seems to make netscape crash eventually. With Javascript+CSS enabled: Go to /., dig into an article (read more), hit the back button -> crash (most of the time). Turn of Javascript (this disables CSS too), repeat above algorithm -> no crash (most of the time). Bye, Alexander. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
On 22 Feb, Steve Hocking wrote: > There was some discussion of this over on the XFree mailing lists, and it > transpired that netscape was using a pointer to some memory that had been > freed some time back. This showed up in cases where you open up a stack of > windows and then close them at random. There was a patch to work around this > for libXt (I think). But this didn't solve the crash at exit. But... rm -rf /usr/lib/compat/* cd /usr/src/lib/compat/compat22/ make all install clean cd ../compat3x.i386/ make all install clean solved this for me (YMMV). Together with disabling Java* and using those ---snip--- Netscape*dragInitiatorProtocolStyle:XmDRAG_NONE Netscape*dragReceiverProtocolStyle: XmDRAG_NONE ---snip--- Xresources I have a more stable Netscape. Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Two queries [ KDE / XFree86 ]
On 28 Feb, Cliff Rowley wrote: > to site.def... Since posting my last mail, I've also encountered a > similar message, thie time reported by Imlib. It's not the exact same > message, but it's the same meaning. They are both having trouble getting > a handle on shared memory (at least, this is my interpretation). I've got > SYSV* in my kernel, so it's not that... Add "options SHMMAXPGS=8192" to your kernel-config to get rid of the errors from imlib (perhaps you have to increase the number if you still get errors after adding it). Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Two queries [ KDE / XFree86 ]
On 29 Feb, Donn Miller wrote: > What was the previous default value of SHMMAXPGS? Why was it > changed? (Just curious, not slamming anybody...) 1024. I'm using 8k right now and I didn't encounter an error from imlib anymore (depends on what's used/screen resolution/resolution of pictures loaded by imlib). Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Two queries [ KDE / XFree86 ]
On 1 Mar, Donn Miller wrote: > It looks like SHMMAXPGS has to be a power of two + 1. (The original No. > config file says > > options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" > options SHMMAXPGS=1025 Thats from LINT. > So, it looks like SHMMAXPGS has to be a power of two + 1. That's why I > chose 4097 instead of 4096 LINT increases the default value by one (I think LINT didn't want to make useless modifications). See /sys//include/vmparam.h. Bye, Alexander. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in cvs ...
At 17:16 09.03.2000 -0800, Kris Kennaway wrote: > > the variable being defined and not its value. You might try removing > > your object directory and doing a make cleandir twice to make sure > > nothing is left in source tree that shouldn't be there. > >Yes, thats a likely candidate. Can you try blowing away /usr/obj and see >if the problem persist? Testa aslfdj slkdflaskdf lksflskf laksdflkas dflskf sldkfjsl lskdfj laskdjf lksdlks fskdjfls slkdfjs dlkasldk sjdlfkjs fskdjfl sdlfjslf sldjf sldfjs ldkfj To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0?
Thus spake Bill Fumerola ([EMAIL PROTECTED]): > (4) The developers all dropped FreeBSD and are now running Redhat. That's it, I believe. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc -Os optimisation broken (RELENG_4)
On 16 Mar, Doug Barton wrote:
> In the interests of providing another datapoint, I tried my old, boring
> P5 machine, and with -Os -march=pentium buildworld bombed trying to
> compile cc1plus in the build tools phase. Backing off to -O worked. The
> kernel was ok with -Os -march=pentium.
As it seems everyone is posting his/her C{,OPT}FLAGS:
I'm using
-Os -march=pentiumpro -pipe -Wall -funroll-loops -fschedule-insns2
since months (~ a half year ore more) without a problem (at least I
didn't notice one) on a Celeron.
Bye,
Alexander.
--
The dark ages were caused by the Y1K problem.
http://www.Leidinger.net Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re[2]: "The Matrix" screensaver, v.0.2
On 27.08.1999, 10:52, Jordan K. Hubbard wrote: > Sorry, I've lived in Europe, you can't pull that one on me. :) > In Germany, for example, it's possible to sue someone simply for > sticking their finger against their forehead. The myth that only the > U.S. is litigious is just that, a myth. Europeans sue the crap out of > one another all the time, and for issues just as silly. :) True. A well known german lawyer is currently about to sue a few webhosters for using the name "Webspace" in their ads. (Yes, some silly - or maybe not-so-silly - dude has registered the word "Webspace" as a trademark). In this case, the problem are not the lawyers, but the fact that you can actually register trademarks like this one. Others have been threatened with lawsuits for using the word "Triton" in mainboard advertisments a few years ago, because "Triton" sounds very similar to the registered trademark "Tricon". -- # My PGP public key (ID=7A2AFB8F): http://darkstar.psa.at/aspgp.txt# # According to rumours, MS finally decided to delay the release of the # # long-awaited Windows 2000 until the first quarter of 1901. # To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
On 23 Sep, Sheldon Hearn wrote: >> well, I just did -O3 -mpentium, and it both compiled cleanly, and appears >> to be running okay, so is -O the max that makes a difference, or...? > > Or... > > Try build world with that kernel running. :-) Just to let you know: -Os works for me (since egcs hit the repository). Bye, Alexander. -- http://netchild.home.pages.de A.Leidinger @ WJPServer.CS.Uni-SB.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel broken? (pcm)
On 11 Oct, Bill Fumerola wrote: >> #makeoptions CONF_CFLAGS=-fno-builtin > > We have enough breakages with the _documented_ kernel options that we As Bruce Evans already said, It's documented. > don't need to go hunting down oddities. :> Have you seen the '#' in "#makeoptions"? I assume a '#' in the config file means: "Hey config, don't look at this!". Please correct me if I'm wrong. I've tested both variants with and without '#'. After editing the file I did a 'config -r CONFIG', 'cd ../../compile/CONFIG', 'make depend', 'make'. I get the error independently of CONF_FLAGS. Back at home I do it again if you want. Bye, Alexander. -- http://netchild.home.pages.de A.Leidinger @ WJPServer.CS.Uni-SB.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is it just me or is sys/signal.h just completely screwed up now?
On 18 Oct, Jordan K. Hubbard wrote: >> See the mails from October 15th, esp. the ones from Marcel Moolenaar >> and Sheldon Hearn. > > I did, but they don't fix the XFree86 3.3.5 build problem. I build 3.3.5 at Oct 16th (~8pm CET, cvsup & world ~3pm?), no 3rd-party patches applied. Bye, Alexander. -- http://netchild.home.pages.de A.Leidinger @ WJPServer.CS.Uni-SB.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reply to field
Thus spake Amancio Hasty ([EMAIL PROTECTED]): > it easier to reply to postings to the mailing lists so people don't > get multiple copies of the same message. I don't have such > problem because I have a mail filter which delete duplicate > messages. Reply-To: also destroys private Reply-To:'s. You can use a MUA, that supports "group reply", as Mutt does. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
On 9 Nov, Archie Cobbs wrote:
>> (101) netchild@ttyp2 > man -k adadadad
>> cat: /etc/isdn/connect.parameters: Permission denied
>> adadadad: nothing appropriate
>>
>> (102) netchild@ttyp2 > grep cat /etc/rc.conf.local
>> spppconfig_isp0="`cat /etc/isdn/connect.parameters`"
>>
>> Is this just my system or is man really reading rc.conf(.local)?
>
> ktrace(1) would tell for sure..
Yes, but I'm shure it reads it without using ktrace. rc.conf.local is
the only place where I have a "cat /etc/isdn/" (I've looked into
/etc/defaults/{rc,man}.conf and /etc/{rc,man}.conf{,.local}).
I will try ktrace later (back at home), if someone wants to see the
output request it please.
Bye,
Alexander.
--
Actually, a more important date is January 1, 2000, when many computer
programs across the world could break.
Richard W. Stevens, Advanced Programming in the UNIX Environment, _1993_
http://netchild.home.pages.de A.Leidinger @ WJPServer.CS.Uni-SB.de
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
On 10 Nov, Oliver Fromme wrote:
> Using command substitution in /etc/rc.conf{,.local} is NOT
> officially supported. I think it should have always been
> clear that there should _only_ be plain variable assignments.
But with i4b you have to specify a username-password pair in rc.conf
(spppconfig_isp0) and I didn´t want to show it to every user (rc.conf is
u+rw,g+r,o+r for reasons you mention).
> That's probably just because you never know which programs
> try to read them.
Ok, so we (root of machine xxx) have either a security hole
(dial-in-passwd visible to everyone) or we have to forget the
recommended way of doing it.
> > Is this just my system or is man really reading rc.conf(.local)?
>
> I think that's perfectly legal.
Yes, but is it necessary?
Bye,
Alexander.
--
Columbus had a fourth ship. It sailed over the edge.
http://netchild.home.pages.de A.Leidinger+Home @ WJPServer.CS.Uni-SB.de
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
On 11 Nov, Daniel C. Sobral wrote: >> >> (102) netchild@ttyp2 > grep cat /etc/rc.conf.local >> >> spppconfig_isp0="`cat /etc/isdn/connect.parameters`" >^^^ > Calling programs from any of the rc.conf files is considered evil > and it's looked down on. It´s there to hide login/passwd information for i4b. [apropos sourcing rc.conf] >> Do we have to live with this or is it subject to change (it gives me >> bad taste to have rc.conf sourced everytime apropos is used)? What >> about making it an environment variable (just set it in login.conf) >> or enhancing /etc/manpath.config (BTW: everithing is named *.conf >> except manpath.config)? > > Apropos is not the fastest of the programs. Sourcing rc.conf most > likely takes a very small time compared to it's total execution > time. I hadn´t execution time in mind. It´s more a "There´s manpath.config, why didn´t we use it for this?". Bye, Alexander. -- There is no seeing eye dog for blind faith. http://netchild.home.pages.de A.Leidinger+Home @ WJPServer.CS.Uni-SB.de Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
On 10 Nov, [EMAIL PROTECTED] wrote: >> Ok, so we (root of machine xxx) have either a security hole >> (dial-in-passwd visible to everyone) or we have to forget the >> recommended way of doing it. > > It looks to me as though the recommended way of doing it needs to > be changed. How about putting the sppp setup in a separate script > in /usr/local/etc/rc.d ? Or, put the script in /etc/isdn and add > that directory to the local_startups variable in rc.conf ? There´s already rc.isdn, we just have to find a name for the config file (I´ve no problem to do it in my setup, I just want to have a official way to close this security hole). >>>> Is this just my system or is man really reading rc.conf(.local)? >>> I think that's perfectly legal. >> Yes, but is it necessary? > > The whole rc setup isn't 'necessary'. But it's damned useful > and convienient. And so is the ability for arbitrary programs > and scripts to read and easily parse rc.conf to obtain system > wide defaults. Sorry, I didn´t object to the rc setup, I just want to know why we didn´t use manpath.config (yes, "man_locales" isn´t realy a path-specifier, but it´s relatet to man & localized man-pages which are stored in ´ManPathElement´/LocalePart/). And I didn´t say it has to be changed (but we have to change the startup of i4b). Bye, Alexander. -- Dead men tell no tales, unless you're in forensics. http://netchild.home.pages.de A.Leidinger+Home @ WJPServer.CS.Uni-SB.de Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i4b & security (Re: "man" reads /etc/rc.conf?)
On 11 Nov, Harold Gutch wrote:
>> > Using command substitution in /etc/rc.conf{,.local} is NOT
>> > officially supported. I think it should have always been
>> > clear that there should _only_ be plain variable assignments.
>>
>> But with i4b you have to specify a username-password pair in rc.conf
>> (spppconfig_isp0) and I didn´t want to show it to every user (rc.conf
>> is u+rw,g+r,o+r for reasons you mention).
>
> What about /etc/start_if.isp0?
Yes, with permissions of u+r,go-rwx it´s more secure than the currently
recommended way.
Hellmuth? Will this be the new official way of configuring i4b?
Bye,
Alexander.
--
Intel: where Quality is job number 0.9998782345!
http://netchild.home.pages.de A.Leidinger+Home @ WJPServer.CS.Uni-SB.de
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
On 12 Nov, Robert Watson wrote: >> >> >> (102) netchild@ttyp2 > grep cat /etc/rc.conf.local >> >> >> spppconfig_isp0="`cat /etc/isdn/connect.parameters`" >> >^^^ >> > Calling programs from any of the rc.conf files is considered evil >> > and it's looked down on. >> >> It´s there to hide login/passwd information for i4b. > > But it seems like the end up as arguments to ifconfig at a later date, ^^ s/if/spp/ > where a user can pull them out of ps, /proc, etc. The window there > is clearly shorter than keeping it in /etc/rc.conf, but still not It will only be in /proc (ps, etc.) at execution-/boot-time or am I missing something? Bye, Alexander. -- Been there, done that, can't remember why... http://netchild.home.pages.de A.Leidinger+Home @ WJPServer.CS.Uni-SB.de Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: i4b & security (Re: "man" reads /etc/rc.conf?)
Also sprach Alexander Leidinger ([EMAIL PROTECTED]): > > What about /etc/start_if.isp0? > Yes, with permissions of u+r,go-rwx it´s more secure than the currently > recommended way. > Hellmuth? Will this be the new official way of configuring i4b? A second advantage: You can sh /etc/start_if.isp0 while the machine is running for changing username/pass. I sometimes do this when using a call-by-call ISP and currently I run spppcontrol by hand. With a script you could add some automatic stuff. I can think of other advantages that go in the same direction. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current and grabbing audio: .wav's too slow
Hello! I use dagrab from the ports to grab audio CD's. On -stable this is no problem, but last week I switched back to -current, and there is something wrong. The "speed" of the grabbed .wav-files is approx. twice too slow. Ok, it sound's nice (slow voices have this very deep sound :), but it's not what I want. As i said, it works on -stable. Does one have the same problems? I have a: wdc1 at port 0x170-0x177 irq 15 flags 0xb0ffb0ff on isa0 [..] wdc1: unit 1 (atapi): , removable, intr, dma, iordis wcd1: drive speed 5511KB/sec, 120KB cache wcd1: supported read types: CD-DA wcd1: Audio: play, 255 volume levels wcd1: Mechanism: ejectable tray wcd1: Medium: no/blank disc inside, unlocked Strange. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to upgrade from 3.3 to 4
Thus spake Vadim Chekan ([EMAIL PROTECTED]): > Is my problem known or I should post more logs? Yes. Probably you've not built/booted a -current kernel before you build world. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to upgrade from 3.3 to 4 - Clarification please!
Thus spake Jag ([EMAIL PROTECTED]): > I'm in almost the same situation as mr Chekan. I have a 3.3-STABLE (SMP) > system and I want to move to CURRENT. I have modified my cvs-scripts and > updated the sources a few times the last couple of weeks. The problem is > when I try to do buildworld. It crashes with things like: Hmm. in some of these days the cc should change (to egcs or such, don't know exaclty). See the last HEADS-UP mail to -current. > Alexander Langer wrote: > > Yes. Probably you've not built/booted a -current kernel before you build world. > > Do you mean that I should build a new kernel *before* I do buildworld? > Is that possible? Yes. It will boot with some warnings but you can build everything. Only xdm didn't work for me, I had to startx manually. BTW: Thas has been on -current a while ago, see the archives for the reasons why you need this. Search for some "HEADS UP" mails. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "man" reads /etc/rc.conf?
On 18 Nov, William R. Somsky wrote: > Hmm... aside from whether or not apropos should be reading in rc.conf, > isn't this code fragment doing the wrong thing in regards to the way > we have /etc/defaults/rc.conf and /etc/rc.conf setup nowadays? No, look at the last lines of /etc/defaults/rc.conf and also search for rc_conf_files in it. Bye, Alexander. -- Actually, a more important date is January 1, 2000, when many computer programs across the world could break. Richard W. Stevens, Advanced Programming in the UNIX Environment, _1993_ http://netchild.home.pages.de A.Leidinger @ WJPServer.CS.Uni-SB.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to upgrade from 3.3 to 4
Thus spake Vadim Chekan ([EMAIL PROTECTED]): > > Are you SURE you're prepaired to run -CURRENT? > Yes, Im shure. No, you are _not_. > Maybe I miss somesing, but I didn't found any hint "how to jump from 3 > to 4" in /usr/src/UPDATING The second one: 19990929: The sigset_t datatype has been changed from an integral type to a compound type and can hold 128 signals. Syscalls directly or indirectly using the new sigset_t have been added as to maintain compatibility with existing binaries. A new kernel must be made and installed and booted with before a make world can be done. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: observations with the ata-driver (hd and zip drive)
On 26 Nov, Soren Schmidt wrote: >> trying to mount the zip-drive gives: >> msdos: /dev/afd0s4: Invalid argument > > This has appeared before IIRC, I've no idea why this doesn't work, > but I can rig up my ZIP drive, but I dont have DOS nor WINDOWS, > do it fail also if the disk is formatted under FreeBSD ?? I didn´t tried to reproduce this recently, but you could try to format the ZIP-disc with mtools: mformat -t 96 -h 64 -s 32 -H 32 z: Fritz: could you post the output of "minfo z:" (ata-controller)? Here´s the one with wd (perhaps a diff between them gives someone a hint): ---snip--- (101) netchild@ttyp2 > minfo z: device information: === filename="/dev/rwfd0s4" sectors per track: 32 heads: 64 cylinders: 96 mformat command line: mformat -t 96 -h 64 -s 32 -H 32 z: bootsector information == banner:"(?6;1IHC" sector size: 512 bytes cluster size: 4 sectors reserved (boot) sectors: 1 fats: 2 max available root directory slots: 512 small size: 0 sectors media descriptor byte: 0xf8 sectors per fat: 192 sectors per track: 32 heads: 64 hidden sectors: 32 big size: 196576 sectors physical drive id: 0x80 reserved=0x0 dos4=0x29 serial number: 39BC1102 disk label="ZIP-100" disk type="FAT16 " ---snip--- And here the boot-message: ---snip--- wdc0: unit 1 (atapi): , removable, intr, iordis wfd0: medium type unknown (no disk) wfd0: buggy Zip drive, 64-block transfer limit set ---snip--- Søren, I assume the ata-controller knows about the last line, right? Bye, Alexander. -- I'll be damned if I can't win when I'm keeping score. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More newpcm breakage
Thus spake Timo Geusch ([EMAIL PROTECTED]): > I don't if DES did, but I did. Turns out from his dmesg that he has a very > similar hardware config (which is why I don't include a copy of my dmesg) > and I am seeing *exactly* the same problems - suddenly my AWE32 is not > recognized any more. Same here, AWE64. I already told one of the sound-guys on IRC when it happened: alex:~ $ uname -a FreeBSD cichlids.cichlids.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sat Nov 27 19:11:37 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/cichlids i386 alex:~ $ dmesg | grep unknown unknown0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new MAKEDEV and the second CDROM
On 1 Dec, F. Heinrichmeyer wrote: > On a freebsd-current box there is a second scsi-cdrom (a cd-writer > working fine with cdrecord). I remade the devices with MAKEDEV, > everything is new, but there is nothing new like cd1c ... Looking at the > source the minor number of cd0c has to be increased by 8. With a second CD-ROM try "/dev/MAKEDEV cd2" (=> "make 2 cd devices"). Bye, Alexander. -- I thought I wanted a career, turns out I just wanted paychecks. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
On 2 Dec, John Baldwin wrote: >> It is interesting. Seems like it is not only VESA modes bug. Strange >> that nobody >> else observed this misbehaviour. > I have seen it in 132 x anything on both -stable and -current but just > haven't been bothered enough by it to complain. I´ve seen this once (but normaly I use a xterm): - current - 132x60 If I remember correcly switching virtual consoles didn´t helped me. Bye, Alexander. -- Slower than a herd of turtles stampeding through peanut butter. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Initio SCSI driver
Thus spake Blaz Zupan ([EMAIL PROTECTED]): > http://www.initio.com/drivers/BSD3sourc91xx.zip) is not part of the > FreeBSD source tree? good question. A Friend of mine has already asked me if the initio-controllers are supported. It's the only stone in his way to FreeBSD (yet) Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On 8 Dec, Sheldon Hearn wrote: >> In a few days time the wd driver will be retired from FreeBSDs >> i386 architecture. > > I know there are issues that make it awkward to support both drivers, > but it's probably a good idea to keep the wd driver available for those > who need it, even if it requires more work to get it going than it does > to get the ata driver going. > > That said, this is one way to get the folks who're having trouble with > the ata driver to get off their butts and provide Soren with feedback, > so maybe it's not a bad idea to nuke wd after all. :-) It isn´t only a matter of providing feedback... the maintainer also has to work on it. I offered feedback in every mail regarding my problem with ata & msdos-ZIPs (they aren´t accessible), but most of the time I havn´t got a reply (Søren replied recently to Fritz Heinrichmeyer, he has the same problem). I´m not able to test it at the moment, but I havn´t seen a cvs-all message which said "Problems with MSDOS formated ZIPs fixed". I assume it isn´t fixed and I want to use the wd driver until it´s fixed. Poul-Henning: please wait until Søren fixed the problems some users have (we didn´t want to loose features, right?). Søren: I didn´t want to flame you, I only want to convince Paul-Henning to wait until you have time to fix those bugs. Bye, Alexander. -- We are what we eat; I'm cheap, fast, and easy. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On 8 Dec, Soren Schmidt wrote: >> Søren: I didn´t want to flame you, I only want to convince Paul-Henning >> to wait until you have time to fix those bugs. > > Welcome to the real world, I've promised to look at this and I will, > but a day has only so many hours. I asumed this, and because of this I made my statement above. > Instead of complaining, help the project, when have you last closed a PR ?? Am I allowed to repeat your "real world" statement? Bye, Alexander. -- Withdrawal is for quitters. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is there any way to use ATAPI CD-R?
Thus spake Andrey A. Chernov ([EMAIL PROTECTED]): > As I see by quick check, CD-related soft from ports understand SCSI only. > Does anybody use new ATAPI CD-R (acd)? If yes, please tell me how. Take a look at /usr/share/examples/atapi/burn* Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On 9 Dec, Maxim Sobolev wrote: > Excuse me for possible off-topic, but I have what is seems for me fresh idea > about this question. Why do not remove from wd driver support for chipsets > already implemented/tested in ata driver? Thus both clans would satisfied > i.e. users with unsupported by ata chips still will have a chance, while all > other will be encouraged to use and test better (IMHO) ata... Eventually at There also exist cases where the chipset is supported but a particular functionality isn´t supported yet (in my case it´s the possibility to access MS-DOS formated ZIP-disks, harddisk access works well, and I´m not the only one with this problem (not counting the people which have not tried to use the ata driver but need to access MS-DOS-ZIPs too)). And I think it´s better to spend someones time with other issues than with digging into the wd driver. Bye, Alexander. -- Go fascinate someone else. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On 9 Dec, Mike Smith wrote:
>> There also exist cases where the chipset is supported but a particular
>> functionality isn´t supported yet (in my case it´s the possibility to
>> access MS-DOS formated ZIP-disks, harddisk access works well, and I´m
>> not the only one with this problem (not counting the people which have
>> not tried to use the ata driver but need to access MS-DOS-ZIPs too)).
>
> I'm completely at a loss as to how the ata driver could be responsible
> for your inability to read these disks. I don't have a copy of your
> original problem report to hand, but since I have all the hardware here
> I'd appreciate it if you could be a little more explicit about your
> problem.
>
> The ata driver just moves bytes; it doesn't give a damn what they are.
Try to mount a MS-DOS formatted ZIP-disk (or to access it with mtools).
With wfd I´m able to access it, with afd I can´t access it.
- Yes, I´m used the right /dev entries and remade them with the
newest MAKEDEV, everytime I tested it.
- Yes, I´m used the right fstab/mtools.conf entries ({,r}{a,w}fd0s4).
If you need more info (dmesg of boot -v with ata and/or wd driver,
{g,b}zipped image of an empty, unaccessible ZIP-disk, ...) just ask.
Bye,
Alexander.
--
The best things in life are free, but the
expensive ones are still worth a look.
http://netchild.home.pages.de Alexander+Home @ Leidinger.net
Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Vibra 16 doesn't recognised anymore
On 11 Dec, Maxim Sobolev wrote: > Some time ago my soundcard (Vibra 16C), which worked just fine > previously, stopped being recognised/attached. Following is relevant > pieces of dmesg and pnpinfo: last cvsup: Dec, 9. sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm0: on sbc0 Same pnpinfo. Works well here. Relevant cut&paste from my kernel-config: ---snip--- device pcm0 device sbc0 ---snip--- Bye, Alexander. -- What we really need is a moment of science in public schools. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Thus spake Don 'Duck' Harper ([EMAIL PROTECTED]): > fires up XFree86's VGA server. And it fits all this on one floppy. They > do have two floppies, one for local CD/disk installs, and another for > NFS/FTP/HTTP/SMB installs. > So, I know it can be done. Is it worth the effort? I donno. Maybe they gzip the binaries and gunzip them into MFS before using them. gunzip has approx 106 kb, but you save about 50% per executeable. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Also sprach Oliver Fromme ([EMAIL PROTECTED]): > > gunzip has approx 106 kb, but you save about 50% per executeable. > -r-xr-xr-x 1 root wheel 4648 Jan 28 1999 /usr/bin/minigzip ok, even better :-) Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Thus spake Peter Jeremy ([EMAIL PROTECTED]): > -rwxr-xr-x 1 jeremyp inplat 96509 Dec 17 08:08 minigzip > % cc -O -o minigzip minigzip.c /usr/lib/libz.a What about stripping? root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 96921 17 Dez 12:35 minigzip root:/usr/src/usr.bin/minigzip $ strip minigzip root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 90044 17 Dez 12:35 minigzip root:/usr/src/usr.bin/minigzip $ cc -O -o minigzip minigzip.o /usr/lib/libz.a root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 48699 17 Dez 12:36 minigzip root:/usr/src/usr.bin/minigzip $ strip minigzip root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 45240 17 Dez 12:36 minigzip Alex -- I doubt, therefore I might be. PGP signature
