Re: geli and SMP problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Setting kern.geom.eli.threads=1 from loader.conf solves the problem. This looks like similar to kern/104669 but not fixed. Krassimir Slavchev wrote: Hi, I have problems with geli and SMP kernel: ... Enter passphrase for md0: GEOM_ELI: Device md0.eli created. GEOM_ELI: Encryption: Blowfish-CBC 128 GEOM_ELI: Crypto: software kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xf9 fault code= supervisor read, page not present instruction pointer = 0x20:0xc0590004 stack pointer = 0x28:0xe7fc1c5c frame pointer = 0x28:0xe7fc1c7c code segment = base 0x0, limit 0x, type0x1b = DPL 0, pres 1, def 32 1, gran 1 processor eflafs = resume, IOPL = 0 current process = 44 (g_eli[1] md0) trap number = 12 panic: page fault cpuid = 0 . If I add these lines to kernel config file: makeoptions DEBUG=-g options DDB options KDB options BREAK_TO_DEBUGGER options ALT_BREAK_TO_DEBUGGER I can't attach the provider at boot: dmesg: Enter passphrase for md0: GEOM_ELI: Cannot decrypt Master Key for md0 (error=22) This is on 6.2-STABLE from Jun/5/2007 g_eli.c version 1.3.2.13 Any ideas how to debug this? Best Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHIZFkxJBWvpalMpkRAj1mAJ0Rzn6eg66BN/+HqxjK94bU2mrnQwCdEm+/ qmkp8i4J0RXPtT8b9FSoN8M= =mkOM -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-BETA1.5 Available...
On Thu, Oct 25, 2007 at 06:27:14PM -0400, Ken Smith wrote: ... Note you will not have been impacted at all if you updated an older machine using cvsup to RELENG_7. This issue only impacts people who had done an install using the 7.0-BETA1 ISOs. Thanks for this information. Last night I did a fresh 7.0-BETA1 install, fetched the RELENG_7 sources and had some installworld fun. Everything wents fine but I wondered how many changes where between 7.0-BETA1 and the latest RELENG_7... hehe :) Everything wents fine. Mergemaster did a great job but I still want to ask if there can be a problem in the future because I switched from 8.0-SUPRISE to 7.0-STABLE... -- Oliver PETER, eMail: [EMAIL PROTECTED], ICQ# 113969174 Worker bees can leave. Even drones can fly away. The Queen is their slave. pgpaHbQJNK7Cm.pgp Description: PGP signature
Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7
Kris Kennaway [EMAIL PROTECTED] writes: Bengt Ahlgren wrote: Esa Karkkainen [EMAIL PROTECTED] writes: On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote: Esa Karkkainen wrote: I get Fatal double fault error when writing to a filesystem mounted from NFS server. I got an offlist reply in which he suggested that the problem might be in nve driver. That was me. I indeed got the same fault when running NFS over nve. Switching to nfe solved the problem for me. The on-screen backtrace reveals the true location of the problem. See: http://www.sics.se/~bengta/FBSD/DSC00585.JPG I do have a dump, but for some reason kgdb is not able to show the same information. If you're using a module you have to do extra (but documented) steps. Or maybe kgdb has forgotten how to decode a double fault. Just for the record: if_nve was compiled into the kernel. Bengt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumpdev question (probably stupid)
Chris H. wrote: Given that the server that I need to create a dumpdev on has has a slice dedicated to /var with *more* than adequate space to accommodate the the resources needed for a dumpdev, as well as everything else in /var. Is it enough to simply: # mkdir /var/crash # chmod 700 /var/crash and set *dumpdev* in */etc/fstab* as such?: No. For the dumpdev in most cases you can use your swap. Also you will need a dumpdir - directory where crash will be saved by the savecore(8). Try this: # cat /etc/rc.conf dumpdev=AUTO dumpdir=/var/crash ^D # /etc/rc.d/dumpon start -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kdump(1) differences between 6.x and 7.x
In May 2006, netchild@ committed some changes to kdump to enhance the decoding of various syscall arguments. Using the example from the commit message: Change kdump to print more useful information, i.e. it changes from 32229 telnet CALL mmap(0,0x8000,0x3,0x1002,0x,0,0,0) 32229 telnet CALL open(0x2807bc28,0,0x1b6) 32229 telnet CALL socket(0x2,0x2,0) to 32229 telnet CALL mmap(0,0x8000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0,0,0) 32229 telnet CALL open(0x2807bc28,O_RDONLY,unused0x1b6) 32229 telnet CALL socket(PF_INET,SOCK_DGRAM,0) Would this change be eligible for an MFC to 6.x? It makes reading kdump output much easier. The only downside is that it might break scripts that people might use to postprocess kdump output. -- Peter Jeremy pgpwSLgLnvhiG.pgp Description: PGP signature
Re: dumpdev question (probably stupid)
Quoting Andrey V. Elsukov [EMAIL PROTECTED]: Chris H. wrote: Given that the server that I need to create a dumpdev on has has a slice dedicated to /var with *more* than adequate space to accommodate the the resources needed for a dumpdev, as well as everything else in /var. Is it enough to simply: # mkdir /var/crash # chmod 700 /var/crash and set *dumpdev* in */etc/fstab* as such?: No. For the dumpdev in most cases you can use your swap. Also you will need a dumpdir - directory where crash will be saved by the savecore(8). Try this: # cat /etc/rc.conf dumpdev=AUTO dumpdir=/var/crash ^D # /etc/rc.d/dumpon start WOW! Thank you Andrey, for the prompt and informative reply! It's just like me sometimes, to make things more difficult than they're intended. :-P OK then. If I understand you correctly, I simply need to create: /var/crash (the default) then correctly set perms: chmod 700 /var/crash add the following to /etc/rc.conf: dumpdev=AUTO dumpdir=/var/crash bounce the server and ensure that /etc/rc.d/dumpon is started immediately after the boot process has completed. Correct? Thanks again! --Chris -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
dumpdev question (probably stupid)
Greetings, Given that the server that I need to create a dumpdev on has has a slice dedicated to /var with *more* than adequate space to accommodate the the resources needed for a dumpdev, as well as everything else in /var. Is it enough to simply: # mkdir /var/crash # chmod 700 /var/crash and set *dumpdev* in */etc/fstab* as such?: # Device MountpointFStype OptionsDump Pass# /dev/ad0s1b none swap sw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1d /var ufs rw 2 2 # dumpdev /dev/ad0s1d /var/crashufs sw 0 0 #cdrom /dev/acd0 /cdromcd9660 ro,noauto 0 0 then bounce the system and *assume* I have a /suitable/ and /useable/ dumpdev available? Sorry if I have made any ridiculous assumptions, and thank you for your time. --Chris -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
loader on Dell INSPIRON 1501: BTX halted
Hello, I have a problem with my notebook Dell INSPIRON 1501, if install FreeBSD-7.0-BETA1-amd64 to USB-HDD. Loader fails with BTX halted, but boot from CD 7.0-BETA1-amd64-bootonly.iso - is good. Any ideas? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumpdev question (probably stupid)
Quoting Andrey V. Elsukov [EMAIL PROTECTED]: Chris H. wrote: OK then. If I understand you correctly, I simply need to create: /var/crash (the default) Yes. Also you need a swap size ram size. swap slice is already 3 times greater than memory. So I'm confident there's enough space. add the following to /etc/rc.conf: dumpdev=AUTO dumpdir=/var/crash bounce the server and ensure that /etc/rc.d/dumpon is started immediately after the boot process has completed. Correct? if you don't want reboot your machine after changing rc.conf you can run `/etc/rc.d/dumpon start`. It will mark your swap as a dumpdev. At the boot time /etc/rc.d/dumpon will be started automatically (if dumpdev is set). After system crash the kernel memory dump will be saved to the dempdev and after reboot dump will be extracted from the swap into dumpdir by the savecore. Yes, That occurred to me immediately after replying to you - dumpdev=AUTO already ensures that. :) Thanks again for all your time and trouble. --Chris -- WBR, Andrey V. Elsukov -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-BETA1.5 Available...
On Fri, 2007-10-26 at 09:55 +0200, Oliver Peter wrote: Everything wents fine. Mergemaster did a great job but I still want to ask if there can be a problem in the future because I switched from 8.0-SUPRISE to 7.0-STABLE... I don't *think* so. Part of why I didn't pick up on the mistake was that HEAD and RELENG_7 were still pretty close. The ctype.h issues introduced symbols (subtlties of using inlined code...) were what caused all the issues with updates and once the system is successfully migrated to RELENG_7 any effects from that should be wiped out. I've been more focused on RELENG_6/RELENG_7 lately but I don't *think* anything has hit HEAD between when RELENG_7 got branched and when I started the builds that would permanently cripple the machine. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: dumpdev question (probably stupid)
Chris H. wrote: OK then. If I understand you correctly, I simply need to create: /var/crash (the default) Yes. Also you need a swap size ram size. add the following to /etc/rc.conf: dumpdev=AUTO dumpdir=/var/crash bounce the server and ensure that /etc/rc.d/dumpon is started immediately after the boot process has completed. Correct? if you don't want reboot your machine after changing rc.conf you can run `/etc/rc.d/dumpon start`. It will mark your swap as a dumpdev. At the boot time /etc/rc.d/dumpon will be started automatically (if dumpdev is set). After system crash the kernel memory dump will be saved to the dempdev and after reboot dump will be extracted from the swap into dumpdir by the savecore. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumpdev question (probably stupid)
Quoting Chris H. [EMAIL PROTECTED]: Quoting Andrey V. Elsukov [EMAIL PROTECTED]: Chris H. wrote: Given that the server that I need to create a dumpdev on has has a slice dedicated to /var with *more* than adequate space to accommodate the the resources needed for a dumpdev, as well as everything else in /var. Is it enough to simply: # mkdir /var/crash # chmod 700 /var/crash and set *dumpdev* in */etc/fstab* as such?: No. For the dumpdev in most cases you can use your swap. Also you will need a dumpdir - directory where crash will be saved by the savecore(8). Try this: # cat /etc/rc.conf dumpdev=AUTO dumpdir=/var/crash ^D # /etc/rc.d/dumpon start WOW! Thank you Andrey, for the prompt and informative reply! It's just like me sometimes, to make things more difficult than they're intended. :-P OK then. If I understand you correctly, I simply need to create: /var/crash (the default) then correctly set perms: chmod 700 /var/crash add the following to /etc/rc.conf: dumpdev=AUTO dumpdir=/var/crash bounce the server and ensure that /etc/rc.d/dumpon is started immediately after the boot process has completed. Correct? OOPS! /etc/rc.d/dumpon is moot, given that dumpdev=AUTO is already set in /etc/rc.conf. Sorry, I should have waited 30 seconds longer before replying. Thanks again. --Chris Thanks again! --Chris -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7.0 BETA1 and Thinkpad T61p : Wireless misadventure
Hi all. So far I've failed to have a working wireless connection with this combination. There are no FreeBSD drivers for the included intel 4965AG card. I've tried to use the ndiswrapper framework without success. The ndisgen wizard runs without issues, but kldloading the driver freezes and reboots the machine. I've also tried two cardbus devices. The Cisco Aironet - AIR CB21AG (ath driver): Oct 26 13:30:27 t61p kernel: cardbus0: Expecting link target, got 0x0 Oct 26 13:30:27 t61p kernel: ath0: Atheros 5212 mem 0xbfeb-0xbfeb irq 16 at device 0.0 on cardbus0 Oct 26 13:30:27 t61p kernel: ath0: [ITHREAD] Oct 26 13:30:27 t61p kernel: ath0: unable to attach hardware; HAL status 13 Oct 26 13:30:27 t61p kernel: device_attach: ath0 attach returned 6 and the Conceptronic C54RC (ral driver): Oct 26 13:40:59 t61p kernel: cardbus0: Expecting link target, got 0x0 Oct 26 13:40:59 t61p kernel: ral0: Ralink Technology RT2560 mem 0xbfeb-0xbfeb1fff irq 16 at device 0.0 on cardbus0 Oct 26 13:40:59 t61p kernel: ral0: MAC/BBP RT2560 (rev 0x00), RF RT2522 Oct 26 13:40:59 t61p kernel: ral0: [ITHREAD] Oct 26 13:41:40 t61p kernel: ral0: could not read from BBP Oct 26 13:41:40 t61p kernel: ral0: could not write to BBP Oct 26 13:41:40 t61p kernel: ral0: could not read from BBP Oct 26 13:41:40 t61p kernel: ral0: could not write to BBP Oct 26 13:41:40 t61p kernel: ral0: could not read from BBP Oct 26 13:41:40 t61p last message repeated 99 times Oct 26 13:41:40 t61p kernel: ral0: timeout waiting for BBP I'm running: uname -a FreeBSD t61p 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Fri Oct 26 13:10:37 WEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 GENERIC kernel with ULE and without debugging. Is there anything I can do to diagnose these issues? Thanks! -- Luis Neves ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure
Yuri Lukin wrote: On Fri, 26 Oct 2007 15:24:40 +0100, Luis Neves wrote FWIW, I have a T61 (not the p version) with 7.0-PRERELEASE from Oct 15th and have an integrated IBM miniPCI card that uses the ath driver without any problems: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: Atheros 5212 mem 0xdf2f-0xdf2f irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: mac 10.3 phy 6.1 radio 10.2 You should have no issues using the CB21AG adapter under FreeBSD. I have several of these and have used them as far back as 6.0-RELEASE on multiple laptops without any issues. In fact, I just dug one up and inserted it into my T61 and it attached to ath1: ath1: Atheros 5212 mem 0x8800-0x8800 irq 16 at device 0.0 on cardbus0 ath1: [ITHREAD] ath1: using obsoleted if_watchdog interface ath1: mac 5.6 phy 4.1 radio 3.6 Huumm... this is similar output to what i had last week, since then I've updated RAM to 4GB (a delicate process, I might have screwed up something) and updated FreeBSD a couple of times to the latest RELENG_7. I'm running: uname -a FreeBSD t61p 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Fri Oct 26 13:10:37 WEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 GENERIC kernel with ULE and without debugging. Is there anything I can do to diagnose these issues? What does dmesg show for ath when you boot? Or can you post pciconf -l -v? cardbus: [EMAIL PROTECTED]:21:0:0: class=0x060700 card=0x20c617aa chip=0x04761180 rev=0xba hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh R/RL/5C476(II)' class = bridge subclass = PCI-CardBus ral card: [EMAIL PROTECTED]:22:0:0: class=0x028000 card=0x3c001948 chip=0x02011814 rev=0x01 hdr=0x00 vendor = 'Ralink Technology, Corp' device = '0x03011814 Zonet ZEW1601 (Ralink Chipset) 802.11b/g WLAN Card' class = network ath card [EMAIL PROTECTED]:22:0:0: class=0x02 card=0xcb2114b9 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet Thanks for your help! -- Luis Neves ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure
On Fri, 26 Oct 2007 15:24:40 +0100, Luis Neves wrote Hi all. So far I've failed to have a working wireless connection with this combination. There are no FreeBSD drivers for the included intel 4965AG card. I've tried to use the ndiswrapper framework without success. The ndisgen wizard runs without issues, but kldloading the driver freezes and reboots the machine. I dont think there's any support for this card in FreeBSD just yet. I've also tried two cardbus devices. The Cisco Aironet - AIR CB21AG (ath driver): Oct 26 13:30:27 t61p kernel: cardbus0: Expecting link target, got 0x0 Oct 26 13:30:27 t61p kernel: ath0: Atheros 5212 mem 0xbfeb- 0xbfeb irq 16 at device 0.0 on cardbus0 Oct 26 13:30:27 t61p kernel: ath0: [ITHREAD] Oct 26 13:30:27 t61p kernel: ath0: unable to attach hardware; HAL status 13 Oct 26 13:30:27 t61p kernel: device_attach: ath0 attach returned 6 FWIW, I have a T61 (not the p version) with 7.0-PRERELEASE from Oct 15th and have an integrated IBM miniPCI card that uses the ath driver without any problems: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: Atheros 5212 mem 0xdf2f-0xdf2f irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: mac 10.3 phy 6.1 radio 10.2 You should have no issues using the CB21AG adapter under FreeBSD. I have several of these and have used them as far back as 6.0-RELEASE on multiple laptops without any issues. In fact, I just dug one up and inserted it into my T61 and it attached to ath1: ath1: Atheros 5212 mem 0x8800-0x8800 irq 16 at device 0.0 on cardbus0 ath1: [ITHREAD] ath1: using obsoleted if_watchdog interface ath1: mac 5.6 phy 4.1 radio 3.6 and the Conceptronic C54RC (ral driver): I have no experience with these. I'm running: uname -a FreeBSD t61p 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Fri Oct 26 13:10:37 WEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 GENERIC kernel with ULE and without debugging. Is there anything I can do to diagnose these issues? What does dmesg show for ath when you boot? Or can you post pciconf -l -v? -Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure
There are no FreeBSD drivers for the included intel 4965AG card. I've tried to use the ndiswrapper framework without success. The ndisgen wizard runs without issues, but kldloading the driver freezes and reboots the machine. This occurs if the Windows driver contains function calls that have not been implemented in the ndiswrapper framework. Often, an older version of the Windows driver solves the issue. For Broadcom cards that use bcmwl5.sys, kernel crash is a frequent problem if the newer drivers are used, but the old drivers solve the issue. I don't know if the card you mention would even work with ndis, but it's a good first step that ndisgen wizard works. Trying an older version of the Windows driver *might* help, but only if this card is compatible with ndis framework in the first place. Good luck. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure
- Original Message From: Luis Neves [EMAIL PROTECTED] To: [EMAIL PROTECTED]; freebsd-stable@freebsd.org Sent: Friday, October 26, 2007 5:24:40 PM Subject: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure Hi all. So far I've failed to have a working wireless connection with this combination. There are no FreeBSD drivers for the included intel 4965AG card. I've tried to use the ndiswrapper framework without success. The ndisgen wizard runs without issues, but kldloading the driver freezes and reboots the machine. I've also tried two cardbus devices. The Cisco Aironet - AIR CB21AG (ath driver): Oct 26 13:30:27 t61p kernel: cardbus0: Expecting link target, got 0x0 Oct 26 13:30:27 t61p kernel: ath0: mem 0xbfeb-0xbfeb irq 16 at device 0.0 on cardbus0 Oct 26 13:30:27 t61p kernel: ath0: [ITHREAD] Oct 26 13:30:27 t61p kernel: ath0: unable to attach hardware; HAL status 13 Oct 26 13:30:27 t61p kernel: device_attach: ath0 attach returned 6 and the Conceptronic C54RC (ral driver): Oct 26 13:40:59 t61p kernel: cardbus0: Expecting link target, got 0x0 Oct 26 13:40:59 t61p kernel: ral0: mem 0xbfeb-0xbfeb1fff irq 16 at device 0.0 on cardbus0 Oct 26 13:40:59 t61p kernel: ral0: MAC/BBP RT2560 (rev 0x00), RF RT2522 Oct 26 13:40:59 t61p kernel: ral0: [ITHREAD] Oct 26 13:41:40 t61p kernel: ral0: could not read from BBP Oct 26 13:41:40 t61p kernel: ral0: could not write to BBP Oct 26 13:41:40 t61p kernel: ral0: could not read from BBP Oct 26 13:41:40 t61p kernel: ral0: could not write to BBP Oct 26 13:41:40 t61p kernel: ral0: could not read from BBP Oct 26 13:41:40 t61p last message repeated 99 times Oct 26 13:41:40 t61p kernel: ral0: timeout waiting for BBP I'm running: uname -a FreeBSD t61p 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Fri Oct 26 13:10:37 WEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 GENERIC kernel with ULE and without debugging. Is there anything I can do to diagnose these issues? Thanks! -- Luis Neves -- Forwarded message -- From: Marcin Simonides [EMAIL PROTECTED] Date: Oct 18, 2007 7:32 PM Subject: Re: NDIS: intel 4965 panic To: [EMAIL PROTECTED] Marcin Simonides wrote: I've tried using an XP ndis wrapper for my intel 4965 wifi adapter. After loading the driver the device is recognized and then kernel panics during driver attachement. [...] Previously I didn't mention that there are some functions missing from the FreeBSD's NDIS api. These are: NdisIMCopySendPerPacketInfo strncat KeQuerySystemTime KeBugCheckEx KeTickCount With the help of NDIS reference and Linux ndiswrapper I have been able to implement all but KeBugCheckEx (they are all rather simple but I can't be 100% sure they're correct and exported appropriately). Now I'm able to load the driver and don't get any of the ntoskrnl dummy called... messages which probably means that there are no missing functions the driver tries to call. Unfortunately I'm still left with the: ndis0: NDIS ERROR: 40001b7c (unknown error) error message and the device doesn't work. ifconfig ndis0 shows: ndis0: flags=8806BROADCAST,DEBUG,SIMPLEX,MULTICAST mtu 1500 ether 00:13:e8:64:aa:f7 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid channel 1 authmode OPEN privacy OFF txpowmax 100 bmiss 7 protmode CTS The LED indicating whether WLAN is on doesn't light up. Calling ifconfig ndis0 up results with the following kernel messages: ndis0: NDIS ERROR: 40001b7c (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x56524457 ndis0: argptr: 0xdd And that's all I have been able to achieve so far :) I'll try to read some more of NDIS specification, locate the source of the aforementioned error message and generally try to blindly find something. Maybe someone has some suggestions? Maybe I should also try to post my questions to some other list? The diff of my changes: http://marcin.studio4plus.com/ndis/ndis.diff All changes are confined to the /usr/src/sys/compat/ndis directory. The functions I have added are implemented in a quick and dirty way :) -- Marcin Simonides --- Check it, it may work for you with ndis. Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: loader on Dell INSPIRON 1501: BTX halted
On Fri, Oct 26, 2007 at 03:29:39PM +0400, Andrey Zonov wrote: Hello, I have a problem with my notebook Dell INSPIRON 1501, if install FreeBSD-7.0-BETA1-amd64 to USB-HDD. Loader fails with BTX halted, but boot from CD 7.0-BETA1-amd64-bootonly.iso - is good. Any ideas? Take patch from http://people.freebsd.org/~kib/realbtx (rev. 2). The new loader is at the same location, but it seems that I did not saved new boot2. You need to install both boot block and loader obtained from the build with the realbtx patch applied, to you USB HDD drive. pgpT8vddMhPLw.pgp Description: PGP signature
Re: 7.0 BETA1 and Thinkpad T61p : Wireless misadventure
On Fri, 26 Oct 2007 16:34:12 +0100, Luis Neves wrote ath card [EMAIL PROTECTED]:22:0:0: class=0x02 card=0xcb2114b9 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet Your output is exactly the same as mine so the driver seemingly attaches and the part appears to be recognized. At which point do you see those messages? Can you build src/tools/tools/ath/athstats, run it and post the output here? -Yuri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Debugging off in 7.0-BETA1 kernel?
Hello, A couple of days ago I csup'd RELENG_7 and I noticed the GENERIC kernel was missing the following options... options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN The GENERIC kernel from BETA1.5 ISO did, however, include these options. Question, is this a feature? What are the preferred settings for testing in the BETA/RC stages of the release cycle? -- Regards, Doug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-BETA1.5 Available...
On Fri, 2007-10-26 at 09:55 +0200, Oliver Peter wrote: Everything wents fine. Mergemaster did a great job That's good to hear. :) Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging off in 7.0-BETA1 kernel?
Doug Poland wrote: Hello, A couple of days ago I csup'd RELENG_7 and I noticed the GENERIC kernel was missing the following options... options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN The GENERIC kernel from BETA1.5 ISO did, however, include these options. Question, is this a feature? What are the preferred settings for testing in the BETA/RC stages of the release cycle? I think for BETA stage we will prefer to have these options (disclaimer: this is only my own $0.02), but for RC stages it will be preferred to use kernel without these stuff. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: any hope for nfe/msk?
On Thu, Oct 25, 2007 at 05:30:32PM +0900, To Oleg Lomaka wrote: [...] tdevil% grep -iE msk|phy /var/run/dmesg.boot pci0: domain=0, physical bus=0 pci2: domain=0, physical bus=2 mskc0: Marvell Yukon 88E8038 Gigabit Ethernet port 0x2000-0x20ff mem 0xd010-0xd0103fff irq 16 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd010 mskc0: MSI count : 2 mskc0: RAM buffer size : 16KB mskc0: Port 0 : Rx Queue 10KB(0x:0x27ff) mskc0: Port 0 : Tx Queue 10KB(0x2800:0x4fff) msk0: Marvell Technology Group Ltd. Yukon FE Id 0xb7 Rev 0x01 on mskc0 msk0: bpf attached msk0: Ethernet address: 00:1b:24:0e:bc:26 miibus0: MII bus on msk0 e1000phy0: Marvell 88E3082 10/100 Fast Ethernet PHY PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ukphy0: Generic IEEE 802.3u media interface PHY 3 on miibus0 ukphy0: OUI 0x001000, model 0x0004, rev. 0 ukphy0: no media present ukphy1: Generic IEEE 802.3u media interface PHY 6 on miibus0 ukphy1: OUI 0x004400, model 0x0011, rev. 0 ukphy1: no media present mskc0: [MPSAFE] mskc0: [FILTER] pci3: domain=0, physical bus=3 pci4: domain=0, physical bus=4 pci5: domain=0, physical bus=5 pci10: domain=0, physical bus=10 Thanks for the info. Would please try attached patch? Any progress here? I guess it's very important to fix the bug as it would affect all Yukon FE based NIC. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
