Re: FreeBSD-CURRENT kernel hangs on starting KDE
You can use ident(1) to extract the CVS version numbers of the files that were used to compile your respective kernels. Try this for a list of files and their respective versions: 'ident /boot/kernel/kernel /boot/kernel.old/kernel | sort' Seeya...Q On Sun, 2003-11-02 at 08:07, Tamás R. wrote: I'm sorry for my previous e-mail, I hope it will look better :) Some months ago I installed a FreeBSD-current system on my desktop computer. I use the KDE desktop environment and I compiled really everything from ports. I periodically maintain it so my system is up-to-date. I have been experiencing a problem with FreeBSD-current kernel all the time. Some months ago I tried to compile a custom kernel based on GENERIC commenting out the not necessary hardwares from my config, like RAID and most of NICs, etc. (I think it is a general thing when customizing). Although I haven't tested it too much the kernel booted properly and everything worked good in console. Trying to start KDE caused system crash (I guess in kernel level). I have spent long days to find the reason trying almost all combination of kernel config settings without luck. Ok, but GENERIC is worked with some custom lines added to it (but I couldn't remove anything except debugging). Since 25th of September something changed in the current kernel source tree because I am not able to compile any kernel, even GENERIC, with which KDE would start without freezing the whole machine partly or completely. Unfortunately I did not preserve any earlier source tree version, I just upgraded it with cvsup before the compilations. Now I use a newer base system than the kernel, which results in an unstable operation (it is normal I guess), because I only preserved the lastest goog-working /boot/kernel binaries I compiled before. KDE freezing in detail -- System: FreeBSD 5.1-CURRENT i386 Relevant hardware config: Mainboard : ASUS P4S533-E (SIS645DX north, SIS962/L south bridges) Memory : PC2700 512MB DDR RAM (memtest86 tested) VGA card : ATI RADEON 9000 PRO Very recent FreeBSD-current GENERIC kernel (was compiled exaclty as described in the handbook) completely freezes some seconds later after starting KDE. Input peripherials/ACPI button become unusable and the machine does not respond to ICMP on LAN so it completely hangs. It is not thought a hardware failure because earlier kernel with the same config (synced with cvsup on 25th Sept. 2003) works very good. KDE and XFree86 were compiled from the lastest ports so they are up-to-date. Logs does not show any usable information related to this freezing so I think there is no point to attach any of them here (XFree86 just stops logging before some radeondrm messages would be logged in normal case). I guess so it is closely an ATI-driver related problem because when I tested the same base system/kernel with an S3Trio VGA card that worked and the ATI did not. This ATI is a common card (with dual head+tv output) and not a cheap one at all (I currently use it on other OS-es on the same machine without experiencing any problems). Since I have been experiencing these problems I sync my source tree more times a week and I'm trying to compile a working kernel without luck. Note: If I switch back to console immediately after X server started and before KDE begins to initialize then KDE starts up properly. When I go back to X again I see the desktop as everything would be right. Some seconds later the same freezing takes place. First the keyboard blocks, then the mouse starts clogging and the whole machine totally hangs. I would appreciate any help in connection with this problem's solution. Thanks in advance, Tamás R. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binaries installed mult. times / no symlinks ?
If you had checked the link count you would have seen that the binaries you mentioned are actually not installed multiple times, but are hard linked under multiple names, and therefore only take up the space of a single instance of the file. If these binary files are located on the same filesystem it is preferable to hardlink rather than symlink them. I'm not sure if you noticed, but deleting a file with a link count greater than one will not free up any space, so deleting them is fruitless unless to plan to delete all of the references. If you want something really small, check out the picobsd project on the freebsd website. Seeya...Q On Sun, 2003-10-19 at 18:52, Bjoern A. Zeeb wrote: Hi, I had been going through /usr/bin to see what I would need for a very small installation and noticed that there are binaries installed multiple times with different names of course. My question now would be if symlinking wouldn't suffice ? From those that I had not deleted I remember the following duplicates that most likely are not all of those exist... Mail - mail Mail - mailx less - more awk - nawk nvi - nview cksum - sum reset - tset nvi - vi nvi - view ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NVIDIA nForce MCP network driver - now supports CURRENT
To those of you using motherboards based on the NVIDIA nForce chipsets, I have recently added support for CURRENT to my nForce MCP ethernet driver. The details can be found here: http://www.onthenet.com.au/~q/nvnet -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _ / Quinton Dolan [EMAIL PROTECTED] __ __/ / / __/ / / /__ / _// / Gold Coast, QLD, Australia __/ __/ __/ / / - / Ph: +61 419 729 806 ___ / _\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA nForce MCP network driver - now supports CURRENT
Actually there are two ways of doing this. One is to use a Wake-On-Lan Magic Packet(tm), which I have never tested, but I believe should be taken care of by the systems BIOS. Technically it is possible to have the device driver set the ACPI state level the machine should be woken up from, but I haven't investigated if it works. You probably need to have ACPI enabled for this to work. These is another feature the hardware appears to support that is generally called OnNow (wake on packet), which allows you to wake the machine from any arbitrary packet based on a 128byte mask. However up until now nobody has expressed any interest in either feature. How do you plan to use such a feature? Do any other device drivers support it yet? Seeya...Q On Fri, 2003-10-17 at 11:29, TAKANO Yuji wrote: Hello. My name is TAKANO. from Japan. From: Q [EMAIL PROTECTED] : To those of you using motherboards based on the NVIDIA nForce chipsets, I have recently added support for CURRENT to my nForce MCP ethernet driver. The details can be found here: http://www.onthenet.com.au/~q/nvnet With 5-CURRENT Allowed to use NVIDIA nForce MCP network driver Thank you. This driver Although it seems that it does not correspond to WakeUpOnLAN, does it support from now on? TAKANO Yuji --- Mail and Web : [EMAIL PROTECTED]: http://www.running-dog.net/ : [EMAIL PROTECTED] : [EMAIL PROTECTED] : http://www.icmpv6.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
OT Re: bikeshed
On Fri, Sep 12, 2003 at 10:43:22AM +0200, Brad Knowles wrote: At 5:10 AM +0200 2003/09/12, Poul-Henning Kamp wrote: You can use the no bikeshed logo for anything you want, anywhere you want, anytime you want with the following simple exception: Okay, the t-shirt is back, although now it's white instead of ash grey. See http://www.cafeshops.com/cp/prod.aspx?p=cmvp.6951805. snip Strange ppl here riding on a bike like that... Why not lay down and use a real bike, a recumbent or short a bent? Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: My acpi-errant laptop will be at the 'con
Doug, We have already posted some info about the N610c here in the mailing list. I've got a acpi code uploadable from the bootloader to bios available: http://www.guldan.cistron.nl/acpi_dsdt.dsl This code can be compiled using iasl from the acpicatools port. This produces a aml code which could be loaded into memory at boot, using the /boot/loader.conf. acpi_dsdt_load=YES acpi_dsdt_name=/boot/acpi_dsdt.aml Hope this will reduce your problems with acpi on your 610c, please also update your bios to the F15 release (some bug fixes and support issues are fixed) Robert On Mon, Sep 08, 2003 at 01:10:46AM -0700, Doug Barton wrote: The Compaq Evo N610c that I'm having all these acpi problems with will be at bsdcon, if anyone wants to take a look. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: My acpi-errant laptop will be at the 'con
Hi, It's a lot ... 9666 lines... so i put it up on de site. plus the acpi code from current running bios. working patched version: http://www.guldan.cistron.nl/acpi_dsdt.dsl in bios version: http://www.guldan.cistron.nl/acpi_dsdt_orig.dsl and the diff -u http://www.guldan.cistron.nl/acpi_dsdt.diff Robert On Mon, Sep 08, 2003 at 09:33:19AM -0700, Nate Lawson wrote: Could you post a diff -u of this against the original ASL so I can know what issues it had? Thanks, Nate On Mon, 8 Sep 2003, Robert [unknown-8bit] Blacquire wrote: Doug, We have already posted some info about the N610c here in the mailing list. I've got a acpi code uploadable from the bootloader to bios available: http://www.guldan.cistron.nl/acpi_dsdt.dsl This code can be compiled using iasl from the acpicatools port. This produces a aml code which could be loaded into memory at boot, using the /boot/loader.conf. acpi_dsdt_load=YES acpi_dsdt_name=/boot/acpi_dsdt.aml Hope this will reduce your problems with acpi on your 610c, please also update your bios to the F15 release (some bug fixes and support issues are fixed) Robert On Mon, Sep 08, 2003 at 01:10:46AM -0700, Doug Barton wrote: The Compaq Evo N610c that I'm having all these acpi problems with will be at bsdcon, if anyone wants to take a look. Doug -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: My acpi-errant laptop will be at the 'cony
Hi, now i have put a recompiled version on the website. this looks much better. http://www.guldan.cistron.nl/acpi_dsdt.diff Robert On Mon, Sep 08, 2003 at 11:01:30AM -0700, Nate Lawson wrote: The reason why it's so different is that acpidump has been changed between when you dumped and patched it and now. The best way around this is to compile your modified ASL using iasl(8) and then disassemble it again using acpidump -f acpi_dsdt.dsl -d acpi_dsdt_new.dsl and then diff that output against *orig. -Nate snip -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: ACPI problems with Compaq Evo N610c
I don't seem to have these problems. I use xbattbar without problem. I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl On Sun, Aug 31, 2003 at 07:50:03PM -0700, Doug Barton wrote: I got interested in this recently because I inherited one of these laptops from work. On Wed, 30 Jul 2003, Cagle, John (ISS-Houston) wrote: I just updated to F.15, and it does indeed fix the windows bit in the output of 'acpidump -d'. However, even with Tony's recommendation of removing the acquire/release of _GL in methods C12C and C12D, I still can't get xbatt or wmbattery to run, even with the very latest -current (which has had at least one acpi stack upgrade since 7/30). When I run either command, it locks the box tight. If I ever get a cursor back, I have to Ctrl-Alt-Backspace to get out of X, since I can't actually type anything. I have a feeling that my acpi table didn't actually get overridden though, due to the following from dmesg: ACPI: DSDT was overridden. -0424: *** Error: UtAllocate: Could not allocate size 6e49202a ACPI-0428: *** Error: Could not allocate table memory for [/* ] length 6e49202a ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY Also, the before and after acpidump's don't show anything different. So, I'm curious if wmbatt is still working for Tony and Robert or not with the latest -current. The other problem I'm having is that doing 'sysctl -a', or just 'sysctl hw.acpi' locks the system tight for a couple minutes, and never completes. The last line that's printed to the screen is: hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Any ideas on that one? Thanks, Doug -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: ACPI problems with Compaq Evo N610c
Oeps I've put the old one up... Now ik have the new one. I don't load the VESA modules, it seems these are loaded before acpi code is replaced? Robert On Mon, Sep 01, 2003 at 01:49:42AM -0700, Doug Barton wrote: On Mon, 1 Sep 2003, Robert [unknown-8bit] Blacquire wrote: I don't seem to have these problems. I use xbattbar without problem. Argh. How recent is your -current? I compile regularly, and I was up to date as of this afternoon. I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl Thanks for the suggestion... I tried that one, but got the same error about not enough memory to load the override file. I attached a verbose dmesg, just in case someone wants to take a look. Doug -- -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: problems with wi driver.
Mmhh, must have been blind... i was looking for it a very long time (without my eyes .) Thanks !!! Robert On Thu, Aug 14, 2003 at 11:21:36PM -0600, M. Warner Losh wrote: : Is there a better way to toggle the start address for 16 bit and 32 bit : cards with sysctl?? u_long cbb_start_16_io = CBB_START_16_IO; TUNABLE_INT(hw.cbb.start_16_io, (int *)cbb_start_16_io); SYSCTL_ULONG(_hw_cbb, OID_AUTO, start_16_io, CTLFLAG_RW, cbb_start_16_io, CBB_START_16_IO, Starting ioport for 16-bit cards); so hw.cbb.start_16_io Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
USB 2.0 ehci umass problems
Hi, I've a usb 2.0 disc enclosure for 2.5 inch disk. It works great using the standard usb stuff (1.x), but fails to use ehci (2.0). When i plug the usb 2.0 device i get the following output ( hw.usb.ehci.debug=2 hw.usb.ohci.debug=2 ) Aug 12 11:39:04 bifur kernel: ehci_pcd: change=0x02 Aug 12 11:39:05 bifur kernel: ehci after reset, status=0x1005 Aug 12 11:39:05 bifur kernel: ehci port 1 reset, status = 0x1005 Aug 12 11:39:05 bifur kernel: usbd_new_device bus=0xc405d800 port=1 depth=1 speed=3 Aug 12 11:39:05 bifur kernel: ehci_open: pipe=0xc46d7600, addr=0, endpt=0 (1) Aug 12 11:39:05 bifur kernel: ehci_alloc_sqtd_chain: start len=8 Aug 12 11:39:05 bifur kernel: ehci_alloc_sqtd_chain: start len=2 Aug 12 11:39:05 bifur kernel: ehci_alloc_sqtd_chain: start len=8 Aug 12 11:39:10 bifur kernel: ehci_timeout: exfer=0xc3ffd500 Aug 12 11:39:10 bifur kernel: usbd_dump_pipe: pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: usbd_dump_iface: iface=0 Aug 12 11:39:10 bifur kernel: usbd_dump_device: dev=0xc46d7800 Aug 12 11:39:10 bifur kernel: bus=0xc405d800 default_pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: address=0 config=0 depth=1 speed=3 self_powered=0 power=0 langid=-1 Aug 12 11:39:10 bifur kernel: usbd_dump_endpoint: endp=0xc46d7824 Aug 12 11:39:10 bifur kernel: edesc=0xc46d782c refcnt=1 Aug 12 11:39:10 bifur kernel: bEndpointAddress=0x00 Aug 12 11:39:10 bifur kernel: (usbd_dump_pipe:) Aug 12 11:39:10 bifur kernel: refcnt=1 running=1 aborting=0 Aug 12 11:39:10 bifur kernel: intrxfer=0, repeat=0, interval=-1 Aug 12 11:39:10 bifur kernel: ehci_timeout_task: xfer=0xc3ffd500 Aug 12 11:39:10 bifur kernel: ehci_abort_xfer: xfer=0xc3ffd500 pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080061 sts=0xa000 Aug 12 11:39:10 bifur kernel: ehci_intr1: door bell Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080021 sts=0xa000 Aug 12 11:39:10 bifur kernel: ehci_idone: aborted xfer=0xc3ffd500 Aug 12 11:39:10 bifur kernel: ehci_abort_xfer: no hit Aug 12 11:39:10 bifur kernel: ehci_alloc_sqtd_chain: start len=8 Aug 12 11:39:10 bifur kernel: ehci_alloc_sqtd_chain: start len=2 Aug 12 11:39:10 bifur kernel: usbd_new_device: addr=2, getting first desc failed Aug 12 11:39:10 bifur kernel: usbd_remove_device: 0xc46d7800 Aug 12 11:39:10 bifur kernel: ehci_device_ctrl_close: pipe=0xc46d7600 Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080061 sts=0x8000 Aug 12 11:39:10 bifur kernel: ehci_intr1: door bell Aug 12 11:39:10 bifur kernel: ehci_sync_hc: cmd=0x00080021 sts=0x8000 Aug 12 11:39:10 bifur kernel: uhub_explore: usb_new_device failed, error=STALLED Aug 12 11:39:10 bifur kernel: uhub2: device problem, disabling port 1 Is there some hints or patches available to get this working? with usb 1.x output no debug... Aug 8 11:14:09 bifur kernel: umass0: Acer Labs USB 2.0 Storage Device, rev 2.00/1.03, addr 3 Aug 8 11:14:10 bifur kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug 8 11:14:10 bifur kernel: da0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device Aug 8 11:14:10 bifur kernel: da0: 1.000MB/s transfers Aug 8 11:14:10 bifur kernel: da0: 19077MB (39070080 512 byte sectors: 255H 63S/T 2432C) And works ofcourse. Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: problems with wi driver.
On Wed, Aug 13, 2003 at 01:44:15PM +0200, Robert Blacquière wrote: Hi, I have some problems getting wi cards working. I've traced the behavour of it. It assigns the first io memory 0x100-0x13f and the card fails to work. I plugin a second wi card and it gets 0x180-0x1bf and the card works. I've 2 different cards one ASUS spacelink Prism 2.5 card and a Lucent Orinoco Gold card. It does not matter which sequence i follow the first card will fail but the second works. some debug info: snip Hi, I fixed it somehow illegal by changing the src/sys/dev/pccbb/pccbb.c line 121: #define CBB_START_16_IO 0x100 to #define CBB_START_16_IO 0x140 And now my wireless cards work. Is there a better way to toggle the start address for 16 bit and 32 bit cards with sysctl?? dmesg output with debug info: CBB EVENT 0x6 Waking up thread Status is 0x3510 cbb0: card inserted: event=0x, state=3510 cbb_pcic_socket_enable: cbb0: cbb_power: 5V start (3000) sc-membase (4000) end () sc-memlimit (403f) pcib2: device pccard0 requested decoded memory range 0x3000-0x pccard0: CIS version PC Card Standard 5.0 pccard0: CIS info: Lucent Technologies, WaveLAN/IEEE, Version 01.01, pccard0: Manufacturer code 0x156, product 0x2 pccard0: function 0: network adapter, ccr addr 3e0 mask 1 pccard0: function 0, config table entry 1: I/O card; irq mask ; iomask 6, io space 0-3f; io16 irqpulse irqlevel pcib2: device pccard0 requested decoded I/O range 0x140-0x cbb_pcic_socket_enable: cbb0: cbb_power: 0V cbb0: cbb_power: 5V start (3000) sc-membase (4000) end () sc-memlimit (403f) pcib2: device pccard0 requested decoded memory range 0x3000-0x wi0: Lucent Technologies WaveLAN/IEEE at port 0x180-0x1bf irq 11 function 0 co nfig 1 on pccard0 pcib2: device wi0 requested decoded I/O range 0x180-0x1bf pcib2: device pccard0 requested decoded I/O range 0x180-0x1bf pcib2: device wi0 requested decoded I/O range 0x180-0x1bf wi0: 802.11 address: 00:02:2d:03:69:67 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (6.6.1) wi0: bpf attached wi0: bpf attached wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wi0: bad alloc 3e6 != ff, cur 0 nxt 0 acpi_acad0: acline initialization done, tried 7 times acpi_tz0: _AC2: temperature 53.0 = setpoint 40.0 acpi_tz0: switched from NONE to _AC2: 53.0C Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
problems with wi driver.
Hi, I have some problems getting wi cards working. I've traced the behavour of it. It assigns the first io memory 0x100-0x13f and the card fails to work. I plugin a second wi card and it gets 0x180-0x1bf and the card works. I've 2 different cards one ASUS spacelink Prism 2.5 card and a Lucent Orinoco Gold card. It does not matter which sequence i follow the first card will fail but the second works. some debug info: Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x6 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:45 bifur kernel: Status is 0x3910 Aug 12 22:23:45 bifur kernel: cbb1: card inserted: event=0x, state=3910 Aug 12 22:23:45 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:45 bifur kernel: cbb1: cbb_power: 3V Aug 12 22:23:45 bifur kernel: start (3000) sc-membase (4000) Aug 12 22:23:45 bifur kernel: end () sc-memlimit (403f) Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded memory ran ge 0x3000-0x Aug 12 22:23:45 bifur kernel: pccard1: CIS version PC Card Standard 5.0 Aug 12 22:23:45 bifur kernel: pccard1: CIS info: ASUS, 802_11b_PC_CARD_25, Versi on 01.00, Aug 12 22:23:45 bifur kernel: pccard1: Manufacturer code 0x2aa, product 0x2 Aug 12 22:23:45 bifur kernel: pccard1: function 0: network adapter, ccr addr 3e0 mask 1 Aug 12 22:23:45 bifur kernel: pccard1: function 0, config table entry 1: I/O card; irq mask ; iomask 6, iospace 0-3f; io16 irqpulse irqlevel Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded I/O range 0x100-0x Aug 12 22:23:45 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:45 bifur kernel: cbb1: cbb_power: 0V Aug 12 22:23:45 bifur kernel: cbb1: cbb_power: 3V Aug 12 22:23:45 bifur kernel: start (3000) sc-membase (4000) Aug 12 22:23:45 bifur kernel: end () sc-memlimit (403f) Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded memory range 0x3000-0x Aug 12 22:23:45 bifur kernel: wi0: ASUS 802_11b_PC_CARD_25 at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 Aug 12 22:23:45 bifur kernel: pcib2: device wi0 requested decoded I/O range 0x10 0-0x13f Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded I/O range 0x100-0x13f Aug 12 22:23:45 bifur kernel: pcib2: device wi0 requested decoded I/O range 0x10 0-0x13f Aug 12 22:23:45 bifur kernel: wi0: timeout in wi_cmd 0x0021; event status 0x8000 Aug 12 22:23:45 bifur kernel: wi0: 802.11 address: 00:e0:18:bd:78:7e Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: using Unknown Lucent chipwi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: Aug 12 22:23:45 bifur kernel: wi0: Lucent Firmware: Station (0.0.0) Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: WI_RID_OWN_CHNL failed, using first channel! Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: bpf attached Aug 12 22:23:45 bifur kernel: wi0: bpf attached Aug 12 22:23:45 bifur kernel: wi0: 11b rates: Aug 12 22:23:48 bifur kernel: CBB EVENT 0x6 Aug 12 22:23:48 bifur kernel: Waking up thread Aug 12 22:23:51 bifur kernel: Status is 0x3510 Aug 12 22:23:51 bifur kernel: cbb0: card inserted: event=0x, state=3510 Aug 12 22:23:51 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:51 bifur kernel: cbb0: cbb_power: 5V Aug 12 22:23:51 bifur kernel: start (3000) sc-membase (4000) Aug 12 22:23:51 bifur kernel: end () sc-memlimit (403f) Aug 12 22:23:51 bifur kernel: pcib2: device pccard0 requested decoded memory range 0x3000-0x Aug 12 22:23:51 bifur kernel: pccard0: CIS version PC Card Standard 5.0 Aug 12 22:23:51 bifur kernel: pccard0: CIS info: Lucent Technologies, WaveLAN/IEEE, Version 01.01, Aug 12 22:23:51 bifur kernel: pccard0: Manufacturer code 0x156, product 0x2 Aug 12 22:23:51 bifur kernel: pccard0: function 0: network adapter, ccr addr 3e0 mask 1 Aug 12 22:23:51 bifur kernel: pccard0: function 0, config table entry 1: I/O card; irq mask ; iomask 6, iospace 0-3f; io16 irqpulse irqlevel Aug 12 22:23:51 bifur kernel: pcib2: device pccard0 requested decoded I/O range 0x100-0x Aug 12 22:23:51 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:51 bifur kernel: cbb0: cbb_power: 0V Aug 12 22:23:51 bifur kernel: cbb0: cbb_power: 5V Aug 12 22:23:51 bifur kernel: start (3000) sc-membase
Re: USB KVM/Keyboard vs. FreeBSD.....
I think to enable the usb keyboard you need something like: kbdcontrol -i /dev/kbd1 where /dev/kbd1 is the usb keyboard... Robert On Wed, Aug 13, 2003 at 08:29:28PM -0700, Jeff Jonze wrote: I have a small issue with my KVM/keyboard. It's a IOGear Miniport (all USB). Has no problem with switching, detaches fine, and sees the KVM, keyboard, and mouse. It recognizes them all. But the keyboard (Logitech Elite corded) doesn't work. It has power (LEDs), but no typing. It works fine under windows 2K, and the mouse is recognized (IntelliMouse) and works under X. Is this a known issue with FreeBSD, my KVM, keyboard, or all three? Jeff Jones = Your ad here __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: Compaq Evo N610c
Great this works ;-) even with the drive bay battery removed and inserted ;-) Only thing stil acts weird is the pcmcia (wireless) stuff... It seems the first memory ports can't be used zo 0x100-0x13f but the second card gets a other pool 0x180 i think and works ... maybe i can overrule or block the first block ? Robert On Wed, Jul 30, 2003 at 09:19:31PM +1000, Tony Maher wrote: Update on Compaq Evo N610c Thanks to an email from Simon in the UK I now have battery support in my N610c. /boot/loader.conf is now hw.pci.allow_unsupported_io_range=1 acpi_dsdt_load=YES acpi_dsdt_name=/boot/acpi_dsdt.aml A patch for acpi_dsdt is attached. Now xbatt (and apm) works perfectly. Now all I need is another unexpected email that details how to solve the suspending problem (actually the resumption) and the switching between X and vga screen sync problem and I'd be completely set ;-) Thanks again to Simon! cheers -- tonym -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: Compaq Evo N610c
Hi, It seems some things are getting some where... pcmcia cards work only (at least one) if you put more than one card in the pcmcia slots. So inserting a Lucent orinoco wireless fails but the second ASUS wireless card gets working ... And also the reverse can be done.. It's strange but it gives a working wireless connection. I have a dmesg verbose on my website: http://www.guldan.cistron.nl/dmesg_output2.txt the older version is: http://www.guldan.cistron.nl/dmesg_output.txt Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: Compaq Evo N610c
Hi, It seems some things are getting some where... pcmcia cards work only (at least one) if you put more than one card in the pcmcia slots. So inserting a Lucent orinoco wireless fails but the second ASUS wireless card gets working ... And also the reverse can be done.. It's strange but it gives a working wireless connection. I have a dmesg verbose on my website: http://www.guldan.cistron.nl/dmesg_output2.txt the older version is: http://www.guldan.cistron.nl/dmesg_output.txt Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: Compaq Evo N610c
On Fri, Jul 18, 2003 at 08:59:56PM +1000, Tony Maher wrote: Hello, I recently installed FreeBSD 5-1-Release onto a Compaq Evo N610c and upgraded to -Current. FreeBSD k9.home 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Wed Jul 16 08:26:32 EST 2003 [EMAIL PROTECTED]:/var/obj/space/usr/src/sys/GENERIC i386 With the following in /boot/loader.conf these problem appear to to have been resolved. hw.pci.allow_unsupported_io_range=1 debug.acpi.disable=cmbat hw.acpi.verbose=1 I did this today, mmm seems something is working (work around). But battery stats an apm like monitoring of the battery is not working any more. So what happens if the battery is empty? just system shutdown without saving of the memory and so? Testing card insertion/removal: aic1: Adaptec, Inc. APA-1460 SCSI Host Adapter at port 0x340-0x35f irq 11 function 0 config 9 on pccard0 aic1: AIC6360, dma, disconnection, parity check, fast SCSI aic1: detached Again i can use any of the wireless cards and ata card i own. One is a Lucent Orinoco Gold card and the other is a ASUS wl100 card (prism2.5) and both seem to be enabled but fail init state. Even the ASUS is being detected as a Lucent chip which is of course false it's a Prism 2.5 chipset. I have only done insertion and removal, I havent actually tried to use device yet. Minor glitches: Switching to and from X can result in screen not being properly sync'd. Switching back and forth beween X and console or closing lid often fixes it but not always. Those glitches are known it seems older ComPaQ laptops had the same issues long time ago. From boot -v vga0: vga: WARNING: video mode switching is not fully supported on this adapter so this is a known problem. Any fixes? Suspending works - resumption does not :-( Any ideas? Under 4.8 all works with my setup. I have to use 4.8 at home because of wireless access thanks -- tonym Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Current Cardbus/pcmcia problems
Hi, I have a ComPaq EVO N610c laptop. It runs FreeBSD 4.8S and Current. I've some problems with the newcard/oldcard stuff. With acpi disabled the TI 1420 cardbus can't alloc any memory/irqs. With acpi enabled it looks if it could work but cards fail to get memory address. I also tried using hw.pci.allow_unsupported* but that only helps the cardbus - pci adaptor. With newcard disabled and oldcard enabled it fails to locate the cardbus-bridges and no pccard slots are available. Is this a known bug or is this related to some of the acpi problems? http://www.guldan.cistron.nl/n610c_2.dsl http://www.guldan.cistron.nl/dmesg_output.txt (done with cardbus and acpi) Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: Compaq N610c ACPI
Ok i've been a morron... updated the wrong web site with the dmesg and ACPI code... The code is located at: http://www.guldan.cistron.nl/dmesg_output.txt http://www.guldan.cistron.nl/n610c_2.dsl Robert On Thu, Jun 19, 2003 at 09:42:00PM +0200, Robert Blacquière wrote: Hi, I've a ComPaq n610c with FreeBSD 5.1-Current running. With the latest bios/RomPaq i was able to install Current/5.1-Release. Previous RomPaq was completely broken for ACPI. But now is more or less works. I have still some problems with acpi and without acpi. With acpi i got some warnings and short/mid freezes during boot and sysctl -A. I've already did some digging in ACPI asl/aml code but can't do the tricks like removing a simple * from the Name (_HID, *PNPsomething) . Has any one any good leads to help or docs without having to spend 2 years of college? I've made a dmesg and a ACPI dump available at: http://www.guldan.demon.nl/dmesg_output.txt http://www.guldan.demon.nl/n610c_2.dsl Booting 5.1 Current without acpi leaves this machine totally broken devices can't be found and drivers seem to locate the cardbus controller multiple times. Having up to 17 cardbus adaptors reported in my system... mmmhh Sounds cool ;-) Robert PS: Compaq released this week a new RomPaq for this machine F.14 A -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Compaq N610c ACPI
Hi, I've a ComPaq n610c with FreeBSD 5.1-Current running. With the latest bios/RomPaq i was able to install Current/5.1-Release. Previous RomPaq was completely broken for ACPI. But now is more or less works. I have still some problems with acpi and without acpi. With acpi i got some warnings and short/mid freezes during boot and sysctl -A. I've already did some digging in ACPI asl/aml code but can't do the tricks like removing a simple * from the Name (_HID, *PNPsomething) . Has any one any good leads to help or docs without having to spend 2 years of college? I've made a dmesg and a ACPI dump available at: http://www.guldan.demon.nl/dmesg_output.txt http://www.guldan.demon.nl/n610c_2.dsl Booting 5.1 Current without acpi leaves this machine totally broken devices can't be found and drivers seem to locate the cardbus controller multiple times. Having up to 17 cardbus adaptors reported in my system... mmmhh Sounds cool ;-) Robert PS: Compaq released this week a new RomPaq for this machine F.14 A -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
If we are talking about something like a network interface that needs to be preloaded, then I would be inclined to see a port install the module into /usr/local/modules (which is what 'rtc' uses) and have a pkg-install message that states the need to do a 'cp /usr/local/modules/if_??.ko /boot/kernel' and add 'if_??_load=YES' to loader.conf so the network interface can be initialised on boot. This way the port isn't installing anything outside $PREFIX, and isn't directly altering /boot/loader.conf. Seeya...Q On Wed, 2003-05-28 at 15:54, Daniel O'Connor wrote: On Wed, 28 May 2003 14:22, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : The only downside is that there are no hooks into the build process so : you have to be VERY careful when you update your kernel, or you get : panics :( This is true. I'd thought that MODULES_OVERRIDE would help, but ports builds and kernel builds are different enough to make this not easy to do. Wanna test a patch? Add a 'makeoptions PORTS_MODULES=comms/ltmdm' to your config file and apply the following patch. Lemme know how well (or poorly) it works. There's likely some hidden assumptions that make it appear to work for me. I don't see how it can work properly.. You need 'FORCE_PKG_REGISTER=' in the install target. I don't think how the patch is structured is sensible though :) 1) If the port is updated between builds you end up with two version of the port installed. 2) You can't control where the module gets put - arguably this isn't a calamity, but I think it makes more sense for the modules to end up in /boot/modules, or some analog to it that is in $PREFIX. IMHO a standard should be set WRT item 2 so future ports writers know what the proper way to do it is :) I guess the problem with mandating somewhere in $PREFIX is that the loader can't load it, so that's no good. I guess the only choice left is /boot/modules. Any comments? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _ / Quinton Dolan - [EMAIL PROTECTED] __ __/ / / __/ / / /__ / _// / Gold Coast, QLD, Australia __/ __/ __/ / / - / Ph: +61 419 729 806 ___ / _\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Don't overreact. I'm not suggesting taking the linux approach of versioning every module. But rather allowing the loader or a module (most likely a 3rd part or from a port) the ability to make a decision based on some internal revision/date based version as to whether it is safe to proceed to load. I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. Seeya...Q On Wed, 2003-05-28 at 13:13, Scott Long wrote: Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q For the love of god, no! This creates a support nightmare. What happens when a user installs his system and recompiles the kernel without changing the source at all? His modules won't work, but there is no reason why they shouldn't. What if one of those now non-working modules is a driver for his hard drive? Scott On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel module inconsistency was policy on GPL'd drivers?
You could achieve the same result without breaking a bunch of cardinal rules by taking an MD5 hash of the kernel when the port is first installed, then modify the rc.d script that loads the module to only run if that MD5 hash matches the current kernel. If a mismatch occurs it should spew out an error saying the port should be reinstalled. This would most definitely work, although I'm not sure if this is the best way of resolving the issue in the longer term. Seeya...Q On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: * Scott Long [EMAIL PROTECTED] [030527 23:51]: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel module inconsistency was policy on GPL'd drivers?
Yes, I'm aware of the implications.. I was merely proposing a ports legal way of achieving the same result that Mike put forward without stuffing a foreign module into /boot. Although, like I said, this is not really a long term solution to the problem. All the port's originating kernel modules I am aware of use /usr/local/etc/rc.d scripts to load the module, and would therefore work with my suggested approach. If you manually loaded it using /boot/loader.conf you would need to put the module into /boot/kernel anyway, which would get moved out the next time you installed a new kernel. I guess the real question is which is more acceptable to the average user. Reinstalling a couple of ports each time you install a new kernel, or risking a kernel panic by not doing it? Obviously it would be better if you only needed to reinstall something only IF it was really required, but unless their is some alternative way of knowing this before loading the module it's hard to determine when that might be without causing a kernel panic. Seeya...Q On Wed, 2003-05-28 at 14:25, Scott Long wrote: Q wrote: You could achieve the same result without breaking a bunch of cardinal rules by taking an MD5 hash of the kernel when the port is first installed, then modify the rc.d script that loads the module to only run if that MD5 hash matches the current kernel. If a mismatch occurs it should spew out an error saying the port should be reinstalled. This would most definitely work, although I'm not sure if this is the best way of resolving the issue in the longer term. Don't forget that some modules need to be loaded at boot time. Also, if I recompile my kernel to trim down an unused driver, the MD5 will change. Scott Seeya...Q On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: * Scott Long [EMAIL PROTECTED] [030527 23:51]: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
By doing that aren't you assuming that the kernel will be installed on the machine that built it, and not potentially somewhere else? What about sysinstall upgrades that don't require src? Seeya...Q On Wed, 2003-05-28 at 15:17, Daniel O'Connor wrote: On Wed, 28 May 2003 14:41, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for : things to build or something.. YUCK! *WHY?* I have asked this before BTW, and I haven't been told why it sucks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Do any of the 1.4.x jdks work reasonably well?
On 2002-12-07-15-29-55 James Satterfield wrote: I've tried the sun and blackdown jdk14 ports on -stable and had no success in running even the demos that come with the jdk. Is this a just me problem or do those jdks just not work? what errors did you get? if you are running the demos as user, and have linux_base-7 installed, try running the demos as root, or switch to linux_base-6 user + linux_base-7 + linux-jdk == core dump (at least for me) this patch works for me: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/40611 msg48418/pgp0.pgp Description: PGP signature
Header files not ISO conform?
Hello, i cvsupped -current yesterday, rebuilt the whole XFree86-port and noticed _tons_ of warnings from gcc in one header file /usr/include/sys/time.h:133 (and :150) ISO C89 forbids long long integer constant if C89 is from 1989, how come that gcc is complaing about such an old standard? there sure is a newer version which allows long long integer constants? not? why is gcc so noisy then? msg48326/pgp0.pgp Description: PGP signature
Nvidia on current: sleeping with dev.mtx_api
Hello, cvsupped to current yesterday and tried to give the nvidia drivers another shot on my current installation (-stable works fine). but it looks like it can't set the right AGP mode (didn't try the freebsd-native AGP driver, but will try that one too). this is a snippet from my XFree.log on stable ... (==) NVIDIA(0): Write-combining range (0xd50c,0x1000) was already clear (==) NVIDIA(0): Write-combining range (0xd5682000,0x1000) was already clear (==) NVIDIA(0): Write-combining range (0xd5603000,0x1000) was already clear (==) NVIDIA(0): Write-combining range (0xd5683000,0x1000) was already clear (II) NVIDIA(0): AGP 2X successfully initialized (II) NVIDIA(0): Setting mode 1440x1080 (II) NVIDIA(0): Using XFree86 Acceleration Architecture (XAA) ... and this is on current: ... (==) NVIDIA(0): Write-combining range (0xd5681000,0x1000) was already clear (==) NVIDIA(0): Write-combining range (0xd50c,0x1000) was already clear (==) NVIDIA(0): Write-combining range (0xd5682000,0x1000) was already clear (==) NVIDIA(0): Write-combining range (0xd5603000,0x1000) was already clear (==) NVIDIA(0): Write-combining range (0xd5683000,0x1000) was already clear [EOF] there it stops, the monitor is still displaying the console, but nothing works. nevertheless was able to ctrl-alt-bkspc the X-server and issue a 'reboot'. then the console came back to life, and i noticed thousands of kernel error messages: Dec 6 20:57:27 roadrunner kernel: nvidia0: GeForce2 MX/MX 400 mem 0xd800-0xdfff,0xd500-0xd5ff irq 11 at device 0.0 on pci1 Dec 6 21:05:10 roadrunner kernel: /usr/src/sys/kern/kern_synch.c:152: sleeping with dev.mtx_api locked from /root/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 Dec 6 21:05:10 roadrunner kernel: lock order reversal Dec 6 21:05:10 roadrunner kernel: 1st 0xc3a57d98 dev.mtx_api (dev.mtx_api) @ /root/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 Dec 6 21:05:10 roadrunner kernel: 2nd 0xc03d69e0 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:314 Dec 6 21:05:10 roadrunner kernel: /usr/src/sys/kern/kern_synch.c:152: sleeping with dev.mtx_api locked from /root/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 Dec 6 21:05:10 roadrunner kernel: /usr/src/sys/kern/kern_synch.c:152: sleeping with dev.mtx_api locked from /root/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 [2000 identical lines snipped] i'm aware, that the drivers aren't supported on current yet, and i'm pretty sure that it will work with one of the other AGP Modes. but if these error messages indicate an error in the nvidia-driver or in the freebsd-kernel, maybe someone should take a look at it. remember, once 5.0 goes final, a lot of people will try to get the nvidia- drivers running on their boxes. msg48328/pgp0.pgp Description: PGP signature
Re: WIne freezes -current for half a year
On Sun, 3 Nov 2002 18:26:50 -0800 Alex Zepeda [EMAIL PROTECTED] wrote: Actually, I think he's complaining that WINE isn't working in -current. Yup. That's about right. Last time I tried Wine (sometime within the past three or four months) I was trying to install either Free Agent or WinMX. The thing caused my 'puter to just reboot. I haven't felt like trying it since (especially now that current isn't hanging nearly as often otherwise). i have similar problems on -stable. the last Wine snapshot that ran Forte Agent fine was 2002.05.09, all newer Wine versions crash/hang when i try to reply to someone (Agent creates a new window/thread(??) and then wine goes nuts :( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Building -CURRENT with 4.5-RELEASE
On Tue, 22 Oct 2002 04:25:23 +0200, you wrote: Is it possible, or do I need to use a more recent installation to be able to build -CURRENT? it was possible for me, but i had to go through a lot of hassles installing -CURRENT from within -STABLE. i used the DESTDIR-switch to install everything to /mnt/ (where my -current partition was mounted). but mergemaster failed due to a system call lacking (can't remember which one, i think it tried to start a programm in /mnt/bin which failed because it was linked against libc.so.5 i fixed that by linking libc.so.4 to libc.so.5 temporarily). the next pitfall is mergemaster NOT creating files/directories necessary, thus using it on a clean partition (only installworld'd and installkernel'd) will fail and you have to create some files/directories by hand. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: filesystem corruption ?
On Tue, 17 Sep 2002 00:42:13 +0200 (CEST), you wrote: I and Michael can kill CURRENT quite simple with cd /usr/ports/www/mozilla make clean make patch make clean after 7-10 times we crash. This is on IDE disks. And I even turned softupdates of. The panic trace is then similar, but not the same as with softupdates enabled. did this on my Celeron2 on a 440BX and a Samsung SpinPoint 80GB drive (limited to UDMA33). softupdates enabled and no errors after hours of patching/cleaning. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
$BFMA3$N%a!<%k<:NiCW$7$^$9(B$B!#K\Ev$K$*F@$J>pJs$G$9!#(B
$B=i$a$^$7$F%5%/%;%9%+%s%Q%K!<$H?=$7$^$9!#(B
$BFMA3!"<:Ni$+$H;W$$$^$7$?$,0lEY$@$1$N%a!<%k$H8@$&$3$H$G!"$I$&$+$*5v$72<(B
$B$5$$!#(B
$B$3$N%a!<%k$,FO$$$?$3$H$,!"2?$+$N1o$@$H;W$C$FD:$1$l$P9,$$$G$9!#(B
$B6=L#$,L5$1$l$P!"$*<j?t$G$9$,:o=|$7$F2<$5$$!#(B
$B!zD9$$J8>O$G$9$,!"$7$C$+$jFI$s$GM}2r$7$F$/$@$5$$!#(B
$B$"$J$?$N?M@8$K$*$$$F0l$D$N%A%c%s%9$G$"$k$3$H$O!"4V0c$$$"$j$^$;$s!#(B
$B$3$N%a!<%k$rFI$b$&$H$7$F$$$k$"$J$?$O!"K\Ev$K6/1?$N;}$A<g$G$9!#(B
$B2h4|E*$J$*6bLY$1$N%7%9%F%`$r$4>R2p$7$^$9!#$3$N%S%8%M%9$O!">pJs$rGd$k$H(B
$B$$$&4JC1$G%j%9%/$b$J$/9b<}F~$,K>$a$k%S%8%M%9$G$9!#(B
$B;d$O?.Mj$G$-$kJ}$+$i$N>R2p$G$3$N%S%8%M%9$rCN$j$^$7$?!#(B
$B$b$A$m$s:G=i$OH>?.H>5?$G$7$?$,!"$9$0$K7k2L$,8=$l$F(B
$BDLD"$rKhF|8+$F$S$C$/$j$7$F$$$^$9!#(B
$BFbMF$r$7$C$+$j8+$F$$$?$@$1$?$i!"$d$i$J$$$h$j$d$C$?J}$,$3$H$,(B
$B$o$+$k$H;W$$$^$9!#@'Hs;O$a$F$_$F$/$@$5$$!#(B
**
$B!!(B $B#E%a!<%k$rAw$C$FI{<}F~#1#8#0#0K|1_$r2T$0!*!*!*(B
**
$B#E%a!<%k$rAw$k$3$H$K$h$C$F!":#$+$i#2!"#3%v7n8e$K$O#2#0#0K|0J>e$NI{(B
$B<}F~$rF@$k$3$H$,$G$-$k!"L5M}$@$H;W$$$^$9$+!)!!>\:Y$r$*FI$_$/$@$5$$!#(B
-
$B!V:G6aJ|Aw$5$l$?%"%a%j%+$N%F%l%SHVAH$+$i!W(B
$B$3$N%a!<%k$K$D$$$F!":rG/=U:"!"El5~#1#2%A%c%s%M%k$N%K%e!<%9$GCN$C$?J}$b(B
$B$"$k$+$HB8$8$^$9!#(B
$B%$%s%?!<%M%C%H>e$G?M5$$,9b$^$k$K=>$$!"%"%a%j%+$G$bA49q%M%C%H$NLk$N%K%e(B
$B!<%9HVAH$GFC=8$rAH$_!"$3$l$GK\Ev$K$*6b$,LY$+$k$+$I$&$+$K$D$$$F!":G6a!"(B
$BD4::$7$^$7$?!#(B
$B$3$NHVAH$G$O!"$3$N$*6bLY$17W2h$,9gK!$+$I$&$+$K$D$$$F$bD4::$7$^$7$?!#(B
$BD4::$N7k2L!"$3$N7W2h$K;22C$9$k$3$H$r6X$8$kK!N'$O$^$C$?$/$J$$$3$H$,H=L@(B
$B$7$^$7$?!#(B
$B$3$NHVAH$N$*$+$2$G!"$3$N7W2h$O!"4JC1$+$DL532$J!"$*$b$7$m$$:_BpI{<}(B
$BF~3MF@K!$G$"$k$3$H$,$o$+$j$^$7$?!#(B
$B$3$NHVAH$,$b$?$i$7$?7k2L$O<B$KL\$r8+D%$k$b$N$G$7$?!#(B
$BHs>o$KB?$/$N3'$5$s$,;22C$5$l$k$h$&$K$J$j!"0JA0$KA}$7$F3hF0$,$O$k$+$K@9(B
$B$s$K$J$j$^$7$?!#(B
$B$h$jB?$/$N?M$,;22C$9$k$K=>$$!"F@$i$l$k6b3[$,$=$l$K$D$l$FBg$-$/$J$j$^$9(B
$B$+$i!":G6a;22C$7$??M$O$H$F$b%(%-%5%$%F%#%s%0$J7P83$r$5$l$F$$$^$9!#(B
$B$"$J$?$b0lEY;22C$5$l$l$P!"$*$o$+$j$K$J$k$G$7$g$&!#(B
$B%5%/%;%9%+%s%Q%K!&6H2=$rLH$l$?9-9p<jCJ$rMxMQ$9(B
$B$k$N$O:#$G$9!#(B
$B@h1d$P$7$K$7$F$$$k$H!"B>$N?M$?$A$,$I$s$I$s#E%a!<%k$r;H$C$F%S%8%M%9$r;O(B
$B$a$^$9!#$3$l$r9TF0$K0\$7$F$/$@$5$$!#(B
$BB?CJ<0%^!<%1%F%#%s%0!J#M#L#M!K$O$D$$$K<R2qE*CO0L$rF@$k$K;j$j$^$7$?!#(B
$B%&%)!<%k%9%H%j!<%H%8%c!<%J%k$,;f>e$G=R$Y$?$H$3$m$K$h$l$P!"(B1990$BG/BeKv$^(B
$B$G$K$O!"A4>!&%5!<%S%9$N#5#0!<#6#0!s$,B?CJJ}<0$K$h$C$FHNGd$5$l$k$h(B
$B$&$K$J$k!#(B
$B$3$l$O?t==2/%I%k5,LO$N;:6H$G$"$j!"%"%a%j%+$K$*$$$F2a5n?tG/4V$K%_%j%*%M(B
$B%"!<$H$J$C$?#5#0K|?MCf!"#2#0!s$KAjEv$9$k#1#0K|?M$,B?CJ<0(B
$B%^!<%1%F%#%s%0$K$h$C$F:b$r@.$7!"$5$i$K!"E}7W$K$h$k$H!"B?CJ<0%^!<%1%F%#(B
$B%s%0$K$h$j!"KhF|#4#5?M$N%_%j%*%M%"!<$,CB@8$7$F$$$^$9!#(B
$B$J%I%J%k%I(B
$B%H%i%s%W;a!J2/K|D9<T!"@$3&$NBgIY9k$N0l?M!K$,%G%S%C%I(B $B%l%?!<%^%s%7%g!<(B
$B$K(B
$B=P1i$7$?:]!"$b$7A4:b;:$r<:$C$F!"%<%m$+$i$d$jD>$9$3$H$K$J$C$?$i!"$I$&$9(B
$B$k(B
$B$H<ALd$5$l$^$7$?!#(B
$B%H%i%s%W;a$O$?$a$i$o$:B(:B$K!"M%$l$?%M%C%H%o!<%/2q<R$r8+$D$1$F!"1D6H3+(B
$B;O$9$k$HEz$($^$7$?!#$=$N>l$K$$$?D0=0$O!"AaB.!"%V!<%$%s%0$7$FH`$rHsFq$7(B
$B$^$7$?!#$9$k$H!"H`$OD0=0$r8+EO$7!"??LLL\$J4i$G$3$&8@$$$^$7$?!#(B
$B!V$@$+$i;d$O$3$N$H$*$j!J%2%9%H$H$7$F!K$3$A$i$K:B$j!"$"$J$?J}$O!JD0=0$H(B
$B$7$F!K3'$=$C$A$NJ}$K:B$C$F$$$k$N$G$9$h!*!W(B
$B%M%C%H%o!<%/%^!<%1%F%#%s%0$K$*$$$F$O!"#2DL$j$N<}F~$,$"$j$^$9!#$"$J$?<+(B
$B?H$N%;!<%k%9$K$h$kD>@\%3%_%C%7%g%s$H$"$J$?$,>R2p$7$??M$N%;!<%k%9$+$i@8(B
$B$8$k%3%_%C%7%g%s$G$9!#(B
$B;DB8<}F~!"$3$l$3$=$,$*6b;}$A$NHkL)$G$9!#$D$^$j!";~4V$H$*6b$r0lEYEj;q$9(B
$B$k$3$H$K$h$j!"Js=7$r7+$jJV$72?EY$b2?EY$bF@$k$H$$$&$3$H$G$9!#%M%C%H%o!<(B
$B%/%^!<%1%F%#%s%0$K$*$$$F$O!"B>$N?M$,$7$?;E;v$KBP$7$FJs=7$,;YJ'$o$l$k$H(B
$B$$$&$3$H$b0UL#$7$^$9!#(B
$B$?$@!"$3$A$i$+$i$*EO$7$9$k7G<(HD%j%9%H$K=q$-9~$s$G$$$/$@$1$G$N$G$9(B
$B=q$-9~$_Be9T6H<T$b$"$j!"0B2A$G?MNO$N?tG\$NB.$5$G=q$-9~$s$G$/$l$^$9!#(B
$BH?6A$KBP$7$F@bL@=q$r#E%a!<%k$GAw$k$@$1!#(B
$B%S%8%M%9$N;22C4uK><T$+$i8}:B$KF~6b$7$F$$$?$@$1$^$9!#(B
$B8e$O!"DLD"$r3NG'$7$FCmJ8$N%U%!%$%k$r#E%a!<%k$GAw
